クラウドマップ開発ブログ

情報可視化エンジン「クラウドマップ」の説明ではよく、「本屋さんで本を探すようなイメージ」ですと言っているのですが、最近のFlashの3D技術を見て、そのイメージの延長線上に何かありそうな気がしてる今日この頃です。

例えば、次のFlashのデモは、ゲームの飛行船のように、地図を鳥瞰的に見ながら移動するというものです：

http://clockmaker.jp/blog/2009/01/springcamera3d/

これはPapervision3Dというライブラリを基に作られているそうです。Flashでも3D表現がうまくできそうという期待が持てます。

今のところクラウドマップは、真上から俯瞰するようなビューですが、このような鳥瞰的なビューも面白そうです。”情報の距離感”みたいなものがより直感的に表現できかもしれません。

また、この絵を見てよりセカンドライフ的なものに近づけたらいいなと思いました。究極的には、コンテンツの情報空間の中を人が行きかう、そう、本屋さんのように。

お知らせ：

弊社サービスの「ビビープラネット」がリニューアルしました。

http://it.bbplanet.jp/

会員制の受発注者マッチングサービスです。これまでのご意見ご要望を受け、大幅な改良が行われました(プログラミング言語も変わりました)。私は直接開発に関与してないですが、アジャイルな開発のもと、より完成度の高いシステムに仕上がっていると思います。

先日のエントリーにあるようにgoogle app engine をいじっているのですが、そこで、 RatingPropertyという独自のデータ型があるのを知りました。これは、テストの点のような0~100の整数値を表現するクラスです。普段全然気にしていなかったのですが、プログラムをやっていると0~100って少し違和感を感じますね。全部で101個の要素があるわけなんで。プログラム的には0~99点か、1~100点のほうがしっくりきます。テストで100点とったときは、実は101番目にいい得点だったんですね。

ちなみにこの手の問題、Flexのdate型を使うときは本当に効いてきます。この型では、1月は0、２月は1として表します。これがpythonのdatetime型になると、1月は1、２月は2として表します。これにはまったときもありました。

また、ほとんどのプログラム言語では基本0スタートですが、愛用するMathematicaでは基本1スタートです。

いずれにせよ、0~99か、1~100であり、0~100は特殊ですね。

追記：ただ0~100は複数の教科の合計の時、0点と満点(5教科のテストなら500点)がはっきり分かり、その差をとりやすいという特徴がありますね。0~99では、合計したとき0点のみがはっきり分かり、1~100では合計したとき満点のみがはっきり分かるだけです。

クラウドマップのAPI化を推し進めるための選択肢として、今日はGoogle App Engine (GAE)に挑戦しました。ひとまず、所感や最初の手続き、はまった点などをblogにまとめてみます。

１．GAEの登録。

数ヶ月前に発表された当時は、登録が定員に達していたので使用をあきらめていたのですが、今回はすんなり登録できました。基本、携帯認証です。登録すると、固有のアプリケーション(ウェブサイト)が(現時点で)最大10個まで使用できます。

２．チュートリアルを一通りこなす。

GAEの開発は少し特殊です。まずSDKをインストールして、それでできたフォルダ上に、プロジェクトを作成します。そのプロジェクトのフォルダ内でいろいろファイルを作成します。ローカルサーバーで行う場合は、dev_appserver.pyでサーバーを立ち上げれば、すぐにプロジェクトのアプリケーションを見ることができます。ファイルを変更すれば動的にアプリケーションも変更します。本番サーバーで行う場合は、appcfg.pyを使います。これを実行するとプロジェクトのフォルダが独自にアップロードされます。更新されたファイルだけがアップロードされます。通常のFTPアップロードが(おそらく)ないところが、興味深いです。また、バージョンを分けることでき、テストと本番を使い分けることができるみたいです（参照）。

GAEのプログラムは、既存のwebフレームワークに慣れていればすんなり利用できるのではないかと思います。特に、pythonのDjangoとかなり似たものになっています。Djangoの機能も利用できます(simplejson等)。特殊な点としては、独自のユーザークラスによって、Googleのアカウント機能が利用できることや、様々な独自のデータタイプがあることなどがあることです。また、独自のSQL文（GQL）が利用できます。しかしこれは、join文などは使用できません。基本はORマッパーで操作し、リレーションはReferencePropertyによって設定するようです。

３． Bulk uploadにはまる。GAEを用いる上で確認しておきたかったのが、Bulk upload(データベースに一括アップロード)です。CSV形式のファイルをBulk uploadできるようです。

ここでまず軽くはまったのがcookieの処理です。こちらを参照にしたがうまくいかず、別のこちらの方法があり試すもなぜか無理でした。結局、後者にて、–cookie=‘ACSID=AJKiYcE[...]1Hh4′のところでシングルクォーテーションをはずして–cookie=ACSID=AJKiYcE[...]1Hh4としたらうまくいきました。windowsのコマンドラインの問題でしょうか？

次に、結構はまったのが日本語処理です。現状、GAEのBulk uploadはasciiしか対応していないので、パッチを当てるしかありません。幾つか方法が載っていたのですが、結局、こちらを参照しました。ただし、一つ落とし穴があって、本番サーバーで使用するとき、修正した__init__.pyをbulkload.pyとしてプロジェクトフォルダに置き、アップローダーのfrom google.appengine.ext import bulkloadをimport bulkloadとする必要があります（こちらを参照）。pythonで、日本語処理はいつも悩まされていたのでまたかという感じです。とりあえず、めでたく日本語でアップロードできました。

全体として、日本語の問題はありましたが、必要そうなものはひととおりそろっている感じです。すでにGAEを利用したアプリケーションも多数出ており(例１、例２、gallery)かなり使えそうです。

※追記1：

GAEにはやはりそれなりに制約がありました。ただこの制約は、ノーフリーランチというか、スケールすることを最大限に考慮した結果でもあると思います。この点に関して、以下のブログ記事が非常に参考になりました。

http://highscalability.com/google-appengine-second-look

※追記２：

現時点で、決定的な問題点はバルクアップロードの遅さです。

http://sprovoost.nl/2008/06/17/google-app-engine-on-uploading-serious-bulk-data/

このブログでは、これまで1分だったところが3日かかったと書いてあります。ローカルではさらに遅いです。これは致命的な気がしてきました…

※追記３：

データエクスポート(backup/restore)の別なソリューションが提案されています(こちらを参照)。

“データを小さな Python code に分割して保存し、うまく GAE の制限を切り抜けているようです。 “  （ただあまり進展はないようです）

※追記４：

GAE関連のデータベース設計に関して、弊社の技術勉強会で発表したネタです：

セマンティックウェブ時代のデータベース設計

こちらも参考までに。

抜粋（追記1）：

“Yes, this means that everything that we think we know about building web applications is suddenly wrong. But this is actually a good thing. Having been on the wrong side of trying to scale up web app code, Ican honestly say it is better to push the requirements of scaling into the face of us developers so that we do the right thing from the beginning. It’s easier to solve the issues at the start, than try and retrofit hacks at the end of the development cycle.

A truly excellent explanation of the differences between MySQL thinking and GAE thinking.

…

RedMonk Clouds Rolling In: The Google App Engine Q&A gives covers a lot of GAE territory. List some of the cons: Python only, not database export, lock-in, and no cron. “…all of the current offerings have limitations that throttle their usage. Many of which are related to the lack of open standards. Apart from the mostly standard Python implementation, App Engine is decidedly non-standard.

…

Groovy: Google Datastore and the shift from a RDBMS. An excellent comparison of how BigTable differs from a RDBMS. The conclusion: The end result of this, is that the standard way a developer writes out the table schema for a RDBMS should be dumped almost entirely when considering an app using Google Datastore.”

抜粋（追記2）：

“It is possible to test your application offline, before uploading it; the SDK comes with an offline data store. Of course, the offline data store is not the real thing. After 10 hours, it had only inserted about 10% of 1 tile. I also noticed that after each insert, the next insert would take longer.

So I skipped ahead and tried the real thing online. The good news is that the slowdown effect had disappeared, as I expected. The bad news is that I could only insert about 100 points each time. Any more and the server would kick me. This means I would need to send an HTTP POST request 15.000 times to upload 1 tile. That would take roughly 3 days with my current connection (remember: 1 minute with Postgres). In addition, even though I used small chunks , the connection got broken by the server after a while. That means starting over again, because the bulk upload script does not have a resume function.”

クラウドマップを開発していると否が応でもはてなブックマーク(はてブ)の動向に詳しくなる今日この頃です…

最近、気になるニュースといえばはてブに関連エントリーがついたことでしょうか。クラウドマップ等のサイトのはてブをチェックしているとなにやらリンクが増えていて、「結構引用されてきたのかな」と思ったら、そうではなく、関連エントリーが表示されていました。よく見るとenhanced by Preferred Infrastructureの文字が。Preferred Infrastructure (PFI)とは東大系のベンチャーで、スーパープログラマーの精鋭が集う会社であると認識しています。これは面白そうな事業提携です。いちユーザーとして、非常に期待します。

関連エントリーの精度はなかなかだと思います。

クラウドマップでは、5個の推薦の以下の3つが特に地図検索という意味で関連が深かったです。
地図上を歩くようにウェブを探検できる『Walk 2 Web』
Goo Labのキーワード地図：BLOGRANGER TG
タグマップがあるquintura

（残り2つはリンク切れと、GooLabの5W1H検索でした。また、ブックマークがあまりついてないエントリーだとまだ精度は低いようですが、これはしょうがない気がします。）

開発者ブログ（１，２）によると、「結局ページとタグの関係を用いるのが一番精度が良いというのに行きつきました。」とあるように、エントリー文章内のキーワードを基にするのでもなく、通常のユーザーベースの連想検索（連想検索はおそらく協調フィルタリングやベイジアンセットのようなものでしょうか…）でもなく、タグベースの連想検索を用いているようです。この点はクラウドマップと同じで、入力データとしてはページ×タグの疎行列データになっている気がします…。やはり「タグ」というのはかなり特殊(かつ有用)なデータ構造を有していると感じます。

レコメンドエンジンは日本では、NTTや野村総研、ALBERTやチームラボなども開発しており今後の展開が気になるところです。

ソーシャルブックマーク（SBM）の研究や動向に関するセミナー「SBM研究会」が東工大にて先日行われたようです。存在を知ったときは、すでに定員が埋まってしまっていたので参加できませんでした。ただ研究会の資料が公開されており、また、様々なブログで当日の様子が書かれていたので、大体の内容は把握することができました。これは、主催者が「SBM研究会の感想をBlogで書いて頂き、[SBM研究会]というタグでSBMでブックマークする」ことを促されたおかげでもあります。

ちなみに、クラウドマップでも[SBM研究会]というタグが現れています。

[sbm]や[ソーシャルブックマーク]というったタグと近いのが分かります。（なぜかwindowsタグも近くにありますが…これは周りのタグとのバランスでたまたまそうなってしまったと考えられます）。この領域が全体のマップのどの部分にあるかを示したのが次の図です。

大きくは、[web]や[はてな]といったタグの近くに、[SBM研究会]や[SBM]タグがあります。最近発売されたiphoneは右上のほうにあってそれなりの領域を占めています。

研究の話では、東工大の方々のプレゼン資料がよくまとまっていて興味深かったです。面白そうな論文が多数紹介されています。もともと私は違う分野(脳関係)出身なので、この分野のいいレビューになりました。関係ないですが、SBMに脳研究を絡めると面白そうな気がします。ちなみに、プレゼンの中で、タグの多義性(Polysemy)と同義性(Synonymy)という問題が取り上げられていますが、クラウドマップでは、タグをマップ上の複数の点で表すことによって多義性を考慮し、似たタグが近くに来ることによって同義性を考慮しています。アルゴリズムとしては因子分析を発展させた感じです。

まだまだ奥が深いSBM。今後も動向に目が離せません。

(one of the biggest/beautiful bookstore)

「クラウドマップの説明」にも書いたように、クラウドマップは「本屋さん」に例えると共通点が多いです。特に、本屋さんをぶらぶら散策するような感覚をWEB上で実現できるものと捉えています。個人的になぜ本屋にこだわるかというと、本屋が好きだからです。暇があるとよく行ってしまいます。理系の専門書などを探すことが多いです。

現状、やはりネットで探すより、実際の本屋に行って探すほうが、はるかに興味のあるものにたどり着くことができます。ネット上にもデータとしては興味のある本があるのでしょうが、キーワード検索や、「この商品を買った人はこんな商品も買っています」といったレコメンド機能では、なかなか見つけ出せないものです。また、カテゴリ別に分類されてあっても、なんとなく本屋さんでの散策の感覚がありません。なんだか選んだカテゴリにすごく縛られているような感じです。

クラウドマップはこのような不利点を打破する要素を持っていると期待しています。なんとなく思い描いているのですが、都内にある大型の本屋さんのレベルのものが、ネット上で実現できたら面白いなと思っています。地方に住んでいたとき、都内の大きな本屋さんがすごい魅力的と感じていたからです。これができれば本当に「イノベーション」かなと思います。