スコアは5。おおっ。

鋭意開発中の画像付きblog検索エンジン「もぶろげっと」にランダム表示機能を付けました。登録されているすべての記事の中から、ランダムに一定件数を取りだして表示します。

　普通にランダム
　http://mobloget.jp/?mode=search&sort=random

　画像だけ表示でランダム
　http://mobloget.jp/?mode=image&sort=random

RSSのランダムな出力には対応していません。

去年の秋口からにょろにょろと作ってきた「もぶろげっと」というblog検索エンジンを先の木曜日に公開しました。ありがたいことに予想以上の反応があり、制作者としても驚いています。 まだ不完全な箇所も多く、機能としても弱いんですが、 何はともあれ公開してみるものだなと思いました。

この二日間で頂いた反応をまとめてみました。

(1) ニュースサイト

• 電通大、Blog 画像情報検索エンジンのβ版公開 (internet.com)
  
• 電通大、検索結果に画像も表示するブログ検索エンジン「もぶろげっと」(internet watch)
• 電通大、検索結果に画像も表示するブログ検索エンジン「もぶろげっと」（bloadband watch, 上のものと同一の内容）
• 電通大、検索結果に画像を表示できるブログ検索エンジン (デジカメwatch)
• Blog内の画像情報検索を実現、「もぶろげっと」ベータ公開 (it media)
• 電通大情報工学科尾内研究室、画像情報統合型ブログ検索エンジン“もぶろげっと”のβ版を公開 (ascii24)

(2) コンタクト

• 電話取材が２件。今後の展開とか事業化の予定はあるのかとかgoogleイメージ検索とどこがどう違うのかとか聞かれる。
• ２つのblogサービスの中の人からメールを頂戴する。「やあやあ宜しく。ところで良かったらうちも巡回先に入れてよ」みたいな内容。どうもありがとうございます。
• 「自分のblogを登録してほしい」旨のメールを合計１０通くらい頂く。

(3) blog・個人サイト

褒められたり貶されたりしている。全体的に好意的なものが多くて嬉しい限り。リファラ等から辿ってなるべく読んでいます。ご批判やご要望は大いに参考させていただきます。

(4) アクセス数

• 初日　　 8,863PageView (1,669Unique IP)
• 二日目　20,315PageView (3,657Unique IP)

初日→二日目で倍以上に増えているのは良い傾向だろう。比較対象がないので、これがどれくらいの数字なのかが分からない。すごいのかしょぼいのか。

ついでにASP.NETも喰いすぎです。２つ合わせて500MBというのは何というかもうちょっと何とかならないんでしょうか。ただでさえ現状のもぶろげっとはアホほどメモリを使うシステムになっちゃっているっていうのに。

チューニングによって多少は何とかなるとおもうので、そのあたりを調べて見ようとおもいます。改善するようならそのやり方をここで報告したいなと。

RSSを吐かせてみたところ（クリックでpopup）

対応というか、プリミティブなデータ型としてRSS2.0を使うことにした。

今までは、namazuのCGIを直接使って検索結果をブラウザに送っていた。

これからは、namazuのCGIはRSS2.0を出力するものとし、ASP.NETでこれをフックしてHTMLに整形し、ブラウザに送るようになる予定。namazuのCGIをにょろにょろと弄くって、RSS2.0を吐かせるところまではできた。

なぜこんな変更をするのかだが、利点はいくつもある。先ず第一に、やはりblogを対象とした検索エンジンであるので、RSSリーダとの親和性を考え、RSSを出す機能は必要だろうということがある。現在提供されているblog検索エンジンはRSSの出力に対応しているものが多い。実際にRSSで検索結果を受け取るというのがどれだけ使われているのかはよく分からないが、個人的には自分のblog名の検索結果をRSSリーダに登録するという使い方をしており、重宝している。自分のblogがどこかで取り上げられれば、トラックバックを送ってもらっていなくても補足できるというわけで、なかなか便利だ。RSSリーダというアプリケーションがこれから普及していくであろうことも考え、RSSに対応しておくことが望ましいだろう。

また、間に一段噛ますことによって、表現の自由度が格段に上がる。もしあなたがnamazuを使ったことがあるならご存じのとおり、namazuのCGIは表現の自由度が低く、検索結果のHTMLをいくつものファイルに分割して記述するため、メンテナンス性も悪い。これをそのまま使うのはあまり面白くない。ASP.NETを間に挟むことによって、ASP.NETの表現力や、優秀で使い慣れた.NET Frameworkを使うことができる。

SQL Serverとの連携が容易になるというのも大きい。もぶろげっとはバックエンドにMicrosoftのSQL Serverを使っている。namazuのCGIはpureなC言語で書かれており、これに手を加えてSQL Serverとやりとりをさせようとすると非常に面倒でやりたくない。.NET FrameworkにはDBを容易に扱うためのクラス群が用意されており、これを使うことでSQL Serverのデータを検索結果に反映させることが容易になる。

問題は検索結果の出力に時間が掛かるようになることで、どれくらいになるかは作ってみないとちょっと分からないが、これがコンスタントに１秒を超えるようなら考えなくてはならないかもしれない。プロセス間通信のやり方やサーバのチューニングなどをうまくやれば、そんなに処理速度が大きくなることはないとおもうのだけど、どうだろう。ASP.NETを使うとなると、環境が完全に Windows + IIS に固定されるというのも問題としてはある。これまでの構成なら、サーバ部分だけを切り離して、Linux環境に置くと言うことも（やや手間は掛かるにしろ）可能だったのだが。なんというか、WebサーバにIISを使うと言ったらM2の森本さんあたりに「おまえIIS使うなんてばかじゃないの」的な反応をされたのがアレだ。IISもちゃんと使ってやればそんなに駄目ではないですよ、たぶん。

ASP.NETではなくphpを使うという選択肢もあったが、ASP.NETのほうが楽しそうだったのでASP.NETを使う方向で逝こうと思う。VS.NETの開発環境に飼い慣らされているのでそれを使いたいし。いずれにせよ、Webアプリケーション周りの知識はかなり貧しいので、適当に本を仕入れてお勉強したいところ。

スクリーンショット（クリックでpopup）

作り始めたときには「こんなシステム３日もあればできるぜ。わはは」とか思ってたんだけど今日に至ってもあんましできていない。そろそろ弄くり始めて３週間くらいか。かなり洗練されてちゃんと動くようにはなってきているけど、まだまだ直さなくちゃならない点は多い。実際に実装しようとするといろんな壁にぶち当たるな。今までいつもそうだったような気もするけど。

このうんこシステムときたらもう、ちょっと油断すると止まるし落ちるしゾンビ化したプロセスが３０くらいうようよしてるしで非常にアレだったのだが、そろそろほったらかしにしておいてもちゃんと動いてくれるようになっていて、一時間に2,000くらいのペースでせっせとモブログ記事を蒐集してくれるようになっている。えらい。一時間に2,000というのは数字としてはちょっと小さくおもえるが、蒐集してきた記事のなかで画像の含まれないものは捨てており一定数が使えないことになるのと、本文を抽出したり画像をダウンロードしてサムネイルを作ったり云々の処理が入るので、まあ妥当なところだろう。できれば複数台のPCで分散して処理ができれば良いのだが、そのギミックを組み込むのはかなりの手間だろうからやるとしても最後の最後になる。

得られた教訓。複数の外部プログラムを提携させたり、ネットワーク経由でデータを蒐集したりといった不確定な要素が多いシステムを作るときには、最初からシステムのすべての要素を完璧に動作させようとするのではなく、どこかで何かがちゃんと動かないことがあっても、それがちゃんと動いていないことを補足してそれを切り捨ててやったほうがはるかにうまくいく。個々の処理を小さなタスクに分割してお互いの結合を疎にしてやって、あとはそれを管理する側に状態監視の機能を入れておいて、たとえば異常に時間が掛かるようなタスクがあればそれを削除して次に進むように作るというわけ。あとはロギングと、状態を監視するためのインターフェースの重要性を改めて知った。システムとしての機能には関わってこないくせに実装は面倒だけど、丁寧に作っておいたほうが後々ハッピーになれる感じ。そういえばJSpiderがやってることと一緒だが、やっぱりJSpiderは良くできてる。

今月中には公開に漕ぎ着けたいなあ。

もぶろげっとの公開に向けてドメインを取得した。８文字もある上に一般的な単語でないだけに取り放題だ。

• mobloget.jp


• mobloget.com


• mobloget.net


• mobloget.org

『ムームードメイン』のダンピングっぷりが素晴らしいこともあって４つも取った。やや無駄遣いだが４つ合わせてたったの7k弱である。安いものだ。懸念なのはサービスの公開までこぎ着ける前におれがもぶろげっとを作るのに飽きてしまうことだが、いまのところやる気に溢れている感じなのでこれを持続できれば何とかなるとおもうのでがんばろうとおもう。

(いずれもクリックでpopup）

こんなものを作ってます。

まだ肝心の記事データがぜんぜん集まっていないのですが、或る程度蒐集できたところで公開したいなっと。

『MyBlogSearch(仮』のことを書くのは久しぶりだ。

gnmzというソフトを使ってクラスタリングをしてみたというのを以前に書いたが、これを自分でやってみようと、クラスタリングプログラムを書いてみた。以前に使ったのと同じデータを使って、自前のプログラムで処理した結果はこんな感じ。

　自前プログラムによるクラスタリング結果

比較対象として、gnmzによる結果を再掲。

　gnmzによるクラスタリング結果

……んー。比較すると、自前で書いたほうは精度が落ちる感じがする。一番最後のクラスタだけは卒論関連のエントリが固まっていてよく分類できているが、あとはいまいちクラスタリングされてる感が無い。困ったものだ。

gnmzでは各クラスタに振られるエントリの数が概ね一定であるのに対し、自前プログラムでは最小で１エントリ、最大で２００エントリ近くと偏りが大きい。これは自前プログラムが「階層クラスタリング（初期状態をすべての要素がクラスタであるとし、そこからもっとも距離の近いクラスタ同士を統合していくことによってクラスタリングを行うやりかた）」と言われる手法を使っているからであるとおもわれる。階層クラスタリングだと、他のどの要素からも距離の遠い、離れ小島的な要素が最後まで統合されず、最後まで１要素１クラスタとして残ってしまう。これは一概に良い悪いといえるものではなく、用途によって良かったり悪かったりするアルゴリズムとしての特性であるが、ぼくの要求としてはgnmzのように各クラスタにだいたい均等にエントリを割り振ってほしいのだ。できれば階層クラスタリングは捨てたいな。K-meansのほうが良いのだろうか。

自前プログラムで１エントリ＝１クラスタとなっているエントリを見ると、リンクを貼って、それに短いコメントを添えたものであることが分かる。たとえばこんな感じだ。

Teddy http://www-ui.is.s.u-tokyo.ac.jp/~takeo/teddy/teddy-j.htm
http://www-ui.is.s.u-tokyo.ac.jp/~takeo/java/smoothteddy/index.html
こりゃおもろい。デモ＆デモ２は必見。

リンクはこちら。

んで、なんでコレが１エントリで１クラスタになっちまうのかを考察してみる。namazuのインデックスでは、URIを１単語として扱っている。また、単語のスコアリングにはtf-idfを使っている（らしい）。tf-idfの性質上、上のような記事では、URIに高いスコアが付与される。URIってのは多くのケースでそのエントリにしか登場しないし、短い記事だと単語数が少ないのでtfの値もでかくなる。加えて、上の引用では反映されてないが、URIにはaタグでリンクが貼られており、一つの記事の中に御丁寧に２回も登場してやがる。よってスコアはさらに高くなる。で、まあ、ああ、もう書くのが面倒になってきたけどとにかくそういうことだ。上のやつみたいに「URIコピペ＆短いコメント」という体裁のエントリだと、どうしても離れ小島になってしまいやすくクラスタリングアルゴリズムで扱いづらい。そしてblogにはそういう記事がすげー多いんだよな。頭痛い。前処理でURIのスコアをゼロにするとかやってしまおうか。

現段階の自前プログラムはとりあえず書いてみようって書いたうんこアルゴリズムなんで、まあ精度が悪いのは当たり前。これからの改善点としてはこんなところ。

• K-meansを実装してみる
• 距離の算出に単純なコサイン角度を使っているが、これをもうちょっと賢そうなものに買えてみる(D-L情報量とか)
• etc...

いつまでもクラスタリングの部分をいじってるわけにはいかないので、今夜でひとまずこれをいじるのは終わりにして、次に進もうとおもう。つーか進捗がやばいです。なんとかしてください。

新宿ヨドバシでゲット。さっそく『MyBlogSearch(仮』に組み入れていきたい。財政がますますやばい状況になってしまったが気にしないことにしよう。わはははは。

Informaの力を借りて、MyBlogSearch crawler(もといJSpider）のRSS対応が完了。

　１．RSSをダウンロード
　２．ダウンロードしたRSSをパース
　３．URLの一覧をゲット
　４．新着記事かどうか（まだダウンロードされていないか）をチェック
　５．新着記事をダウンロード

……という流れ。あとはスケジューリングして、定期的に登録されたblogをチェックしに行くようにすれば、クローラまわりはとりあえず完成かな。

残りのToDo：

ぜんぜん完璧ではないのだが、とりあえずこんなもんだろ。あとはヒューリスティックなルールを積み重ねていったり、ceekz氏に倣ってN-gramを使ったりすることでさらに削って行けると思うが、そこまでやるかは分からない。

処理例：
処理前１(17,132byte)　処理後１(2,267byte)
処理前２(8,938byte)　処理後２(2,447byte)
処理前３(52,965byte)　処理後３(7,526byte)

気付いたら７時半になってたので、ぼくはもう寝ます。おやすみなさい。

追記

gnmzでクラスタリングしてみた

『MyBlogSearch(仮』作りの続き。ceekz氏に教えてもらったgnmzという文書クラスタリングソフトを使ってみた。

いま『MyBlogSearch(仮』のぼくのアカウントには１０個のblogが登録されているのだが、このgnmz、計算量が非常に大きく、そのままでは計算に時間が掛かる。とりあえず、「今日の井原」と「井原のメモ」の２つにインデックスを絞ってクラスタリングさせてみた。「今日の井原」と「井原のメモ」には現在421のエントリがある。これらを20のクラスタに分類させた結果、こんなふうになった。

クラスタリング結果

どうだろう。「意外とうまくいくな」、というのがぼくの感想。「PTT」,「クローラ」,「randommixi」,「萌」といったような、特徴的な単語をうまく取り出せており、人間の感覚に近いクラスタリングが出来ていると感じる。namazuがインデクシングにTF/IDFを使っていることが大きいのだろう。

ただ、見て分かるとおり、「今日の井原」と「井原のメモ」の記事が完全に分かれてしまっている。ぼくとしてはこれが混ざっていて欲しいわけで、このままでは『MyBlogSearch(仮』に組み込んでいくことは出来ないなという感じ。これはダウンロードしたHTMLをそのままnamazuに喰わせてしまっていることが原因なのだろう。つまりHTMLから本文だけを抜き出してくる処理が必要になるわけだ。さて、どうしたものか。

HTMLからの本文抽出というのはそこそこ汎用的に必要とされる処理だとおもうので、既に公開されているソースコードがないかどうか探してみようとおもう。見つからなかったらまた考えよう。

……う～ん、どこまで出来るのやら。

戯れにMyBlogSearch(仮というのを作っている。自分の購読しているblogや、友達のblogのリストを登録し、そのリストのなかで全文検索ができるというサービスだ。

昨日あたりから作り始めて、いちおう動くところまで来たので、このblogの右上に設置してみた。検索フォームになにか検索したいキーワードを入れてボタンを押すと、ぼくの自宅サーバで動いている『MyBlogSearch(仮』が検索結果を提示するのを見られるとおもう。

いまのところ、以下の10個のblogがリストに登録されている。

打ち込むキーワードとしては、いろいろなblogの記事が入り混じったところが見られる「ネットワーク」「システム」あたりがお薦め。ここで間違って「うんこ」などと入れてしまうと、切込隊長BLOGの記事ばかり表示されてしまうので注意してほしい。

で。これをどのあたりまで作り込んでいくか、またサービスとして一般に公開するかどうかを迷っている。これを提供したとして、みんなが使ってくれるなら良いのだが、これがどれくらい受けるネタなのかがいまいち分からない。仲間内のblogだけでの検索機能を提供するという点では、多少は需要がありそうにおもえる。ねとげのギルドとか、そのいった結合の強いコミュニティで、仲間内のblogをまとめて検索できるというと受けないかなあ。どうなんだろう。友達にこれのことを話したら「ちっとニッチがなさそう」と言われてしまったのだが、正しい指摘だとおもう。というわけで、何か御意見があれば、コメントを付けてやっていただけるとこのアホが喜びます。

あと、MSNメッセンジャでいろいろと教えてくれたceekz氏、どうもありがとう。