ルーペ機能を実装しました。
タグor背景をダブルクリックするとルーペが現れます。
もう一度クリックorダブルクリックするとルーペが消えます （ドラッグ機能はルーペ中そのまま使えます）。
ルーペ内では奥で見えなかったタグが拡大して表示されます。
（うまくいかない場合は、古いキャッシュが残っている可能性があります）
この機能を設けた理由は、最初に表示される地図だけではどこになにがあるかがやや分かりづらかった点を解消したかったからです。この問題はクラウドマップにおいて今後も課題となると思いますが、その一つの打開策としてこのルーペ機能をつけました。ルーペを用いることによって、個々をズームして見るのに比べ、高速に深いタグの分布まで見ることができます。ぼーっと無目的で眺める場合と、検索で一発でたどりつく場合の中間くらいの目的の時に有用なものと考えています。
クラウドマップに新しい道順表示機能を追加しました。地図上でクリックしたタグやサイトの訪問履歴を線でつないで表示する機能です。今まで、地図を深くたどると自分の居場所が分からなくなることが多かったのですが、これで多少は改善されたかと思います。また、グローバルマップにも道順が表示されるので、どこにいって、どこにいってないかを把握することができます。これは、マップを包括的に見たい場合に便利かと思います。（マップ上にミステリーサークルのように絵を描いて遊ぶこともできます）。ただし、いまのところキャッシュ機能はつけていないので、一度、ページを閉じるとリセットされます。デザインもまだシンプルです（見せ方を工夫すればかっこよくなる気がします）。この機能に名前をつけるとしたら、見た目的に”contrail”（コントレイル:飛行機雲）機能といったところでしょうか。
Adobe AIR コンテストに兼ねてより応募していたJUKING AIRが、「Flex賞」に選ばれました！！このような受賞を頂くのは、今回が初めてで大変嬉しく、光栄に思います。今後の活動にも大きな励みになります。
http://www.adobe.com/jp/events/aircon2008/awards/
授賞式が先日あって、サービスの内容と開発Tipsについてプレゼンしてきました：
ここでJUKING AIRのアーティストマップはクラウドマップを利用しています。
審査員の方もJUKING AIRを愛用していただいていたようで、さらに、クラウドマップのコンセプトである直感的な「ゆるい検索」を体験し、その意義を理解していただいていたのは非常によかったです。プレゼンで伝えきれていなかった部分を、審査員のコメントで補完していただいた感じです。
皆様、本当にありがとうございました。
(one of the biggest/beautiful bookstore)
「クラウドマップの説明」にも書いたように、クラウドマップは「本屋さん」に例えると共通点が多いです。特に、本屋さんをぶらぶら散策するような感覚をWEB上で実現できるものと捉えています。個人的になぜ本屋にこだわるかというと、本屋が好きだからです。暇があるとよく行ってしまいます。理系の専門書などを探すことが多いです。
現状、やはりネットで探すより、実際の本屋に行って探すほうが、はるかに興味のあるものにたどり着くことができます。ネット上にもデータとしては興味のある本があるのでしょうが、キーワード検索や、「この商品を買った人はこんな商品も買っています」といったレコメンド機能では、なかなか見つけ出せないものです。また、カテゴリ別に分類されてあっても、なんとなく本屋さんでの散策の感覚がありません。なんだか選んだカテゴリにすごく縛られているような感じです。
クラウドマップはこのような不利点を打破する要素を持っていると期待しています。なんとなく思い描いているのですが、都内にある大型の本屋さんのレベルのものが、ネット上で実現できたら面白いなと思っています。地方に住んでいたとき、都内の大きな本屋さんがすごい魅力的と感じていたからです。これができれば本当に「イノベーション」かなと思います。
前記した「Flashの速度向上に関して」で、マップ上のコンポーネントの生成をなるべく抑えるようにしたと書きました。具体的にはこれは、描画するコンポーネントを使いまわすことで実現しています。今日はその点について解説します。
クラウドマップでは現在、大きいもので1万件ほどのコンテンツをマップ上に配置しています。もちろん、それと同数の描画コンポーネントを作るのは非効率です。そこで、位置情報だけ先に読み込んでおいて、見ている部分だけ、コンポーネントを作成すればよいと思われます。
このとき、見終わったコンポーネントを削除して、新たに描画領域に入ってくるコンポーネントを作成するという方法があります。しかし、これはコンポーネント作成の負荷が描画の度にかかってしまうので遅いです（旧バージョンではそうしていました）。
よりよい方法は、見終わったコンポーネントを削除せずプールしておいて、新規のコンポーネントでパラメタだけ変えて再利用させることです。つまり、deleteとnewの操作から、親コンポーネントのremoveChild(*)とaddChild(*)の操作だけで済ませるようにすることです。実際に、この方法で処理速度が向上したことを確認しました。
おそらく、このような方法は常套手段とは思いますが…。
先日、Infinity Ventures Summit 2008 Spring という会議に参加し、クラウドマップのサービスについて発表してきました。有望ベンチャー経営者が数百人集う会議で、すごく活気があふれていました。
会議は、パネルディスカッションが2日間にわたってあり、ラウンチパッドという新規サービス発表イベントがその間、1回あります。クラウドマップはこのラウンチパッドで発表しました。ここで発表されたサービスは、どれもレベルが高く、興味深いものが多かったです。
発表の様子です（こちらを参照）。
（思わぬハプニングが…）
今回の発表で、いくつかの企業からコンタクトを受けることができました。このように直ぐに事業展開の話が進むのは、経営者が集う会議ならではのことではないかと思います。個人的には、会議前日に、まだできていないプログラムの箇所があって徹夜で開発して、この会議に臨んでいたので、苦労の甲斐がありました。もう少し準備する時間があればよかったのですが、目的としては果たせたのではないかと思います。
Flash(flex)を始めてかれこれ1年近くたちました。この間、何段階か大幅なリファクタリングが行われました。マップ上のコンポーネントの生成をなるべく抑えるようにしたり、アニメーションの最中には簡略的に描画したり、データを分割して渡したりと。その甲斐あって、初期のプロトタイプに比べると大幅に速度向上しています。
思うに、FlexBuilderのリファクタリング機能は最高です（ある程度マシン性能が必要ですが）。簡単に名前を変更できたり、コンパイルが通るかどうかを動的に逐一チェックしてくれます。「発生をマーク」する機能も非常に便利で、変数のありかをすばやくチェックできます。
また、FlexBuilderのプロファイラーを使うと、ボトルネックの把握に便利です。速度だけでなく、メモリ使用量もチェックできます。私もこれで、見落としていた無駄な処理を発見したことがあります。
処理速度でよく問題になるなのは、使うマシンによって速度が異なることです。たいてい開発用のマシンは速いのですが、ノートパソコンで使うなど、一般的にはもっと遅いものです。なので、遅いマシンでチェックしておいたほうがいいです。
今日、はてなを見ていたら気になる面白いサービスがありました。
Hatenar Map
はてなダイアリーのユーザーを地図的に表現しているとのことです。俯瞰的に見れるところや、ズームして拡大するところなど、クラウドマップと共通するところがあります。ネタとして作ったということですが、かなり完成度が高いです。
どのような技術が使われているかも開発者のブログで述べられています。
http://d.hatena.ne.jp/kaiseh/20080609/1212980260
非階層クラスタ(k-means)→階層クラスタ→ボロノイ図作成という手順となっているようです。個人的に、ボロノイ図作成に関しては疎いのですが、k-meansや階層クラスタは昔いろいろ格闘した覚えがあります。基本的に、これらのクラスタ手法は入力ベクトル同士の「全体的な類似度」（例えばユークリッド距離など）を基に似たもの同士をまとめるものです。ちなみに、クラウドマップは「全体的な類似度」ではなく「部品要素毎の類似度」でまとめています。一つの入力ベクトルは部品的に分解されて、マップ上の複数の点として表現されます。本屋さんで例えると、一つの本が複数の書棚にあるようなものです。この特性によって、より多様なデータ構造がマップ上に表現されます。
このサービスに対する反響にあるように（例えば：http://d.hatena.ne.jp/qaze00/20080609/1213024037）、WEBを全貌できるサービスは望まれている思います。クラウドマップでそのような理想が実現できればと思っています。
現在、クラウドマップのプログラムはFlash、Python、C++で書かれています。クライアントサイドは、FlashかJavascriptかの選択肢がありますが、ここでは処理速度の速いFlashを選びました。クラウドマップではマップ上に多数のコンポーネントを表示する必要があるためです。
サーバーサイドは主にPythonを使用しています。Pythonと対をなす言語としてRubyがありますが、ここではPythonを選びました。主な理由は科学計算と相性がいいことです。特に、数値計算ライブラリのNumpyとScipy、Matlab風の数値プロットができるMatplotlib、行列データをHDFファイルとして保存できるpytables、などの科学系ライブラリは完成度が高く、非常に便利です。クラウドマップでは様々な統計処理が行われますが、その要所要所でこれらのライブラリを使用しています。
また、科学計算のコアな部分は処理が高速なC++で実装しています。ただやはり開発のしやすさは動的言語のPythonにはかないません。そこで本当にコアな部分だけC++で実装し、pythonのctypesモジュールを用いて連携をとったうえで、開発を進めています。
はじめまして。クラウドマップ開発者の細田です。今日から、クラウドマップの開発ブログをスタートします！
開発の進捗報告をはじめ、開発を通して得たプログラムTipsや、クラウドマップの仕組み等について書いていきたいと思います。
よろしくお願いします。