wrong, rogue and log

Google Refineは神ツールである

Google Refine 2.0

http://code.google.com/p/google-refine/

Googleのデータクレンジングツール。ローカルwebサーバーで動作するアプリである。なぜローカルで動作するwebサーバにしているかというと、それには理由があるのだ。ほんと、ビックリ。

公開しているデータはタイトルやデータ形式がマチマチで、それを自分のところで統計解析するには、データレンジングをかなりやらなければいけなかった。そのためには、いままでgrepだとかfindだとかのコマンドやPythonスクリプトで半狂乱になって汚れ落としをしていたけれど、このGoogle Refineを使うとそういう問題がアホみたいに簡単に解決する。

例えば、カテゴリカルデータがセルに割り当てられているとする。記入者によってそれが略語だったりフルの名称だったりマチマチである。これを全て一つの文字列に置き換えたいとする。このGoogle Refineを使えばクラスタリングアルゴリズムが複数の行や列をまたいで似たような文字列を探してきてくれてサジェスチョンしてくれる。そして、その文字列を一気通巻で検索、置換できるのだ。

以下のビデオを見れば一目瞭然。こういうムチャクチャ有用なツールの作者は例によってインド訛りだ。ただ、この英語はとてもキレイ。

Google Refine 2.0 - Introduction (1 of 3)
http://www.youtube.com/watch?v=yNccGtn3Wb0&feature=player_embedded



また、webに公開されているテーブルをデータとして使いたいのだけれど、複雑怪奇なHTMLテーブルで人生が嫌になることがある。これもGoogle Refineを利用すれば、テキストファセッティング機能やテキストフィルタリングを屈指して、きちんとしたデータテーブルに整序することができるのだ。しかも、すべての操作はJython/Pythonの辞書として記録されているので、これを自動スクリプトとして別のデータにも適用できるのだ。まさに神ツール。つまり、ここにローカルで動作するwebサーバーである意義があるのだ。

更には、このGoogle Refineに読み込まれたオブジェクトは全てJython(またはClojureまたはGoogle Refine Expression Language (GREL))オブジェクトとして扱うことができるので、それをWeb Service APIに載せることも簡単だ。例えば、住所が入力されているカラムがあるとして、そのカラムを丸ごとGoogle Maps APIにJSON経由で食わせて、セルごとの位置情報を取得することもできる。Python（やClojure）のちょっとした知識があり、JavaScriptやJSONやRESTの仕様とWeb APIの利用方法を知っているだけで、データ整理を外部Webサービスに外注することができるのだ！

これはもう神ツールとしかいいようがない。これからは、これなしでは生きていけないな。

Heroku

Heroku
http://heroku.com/

Rubyにプラットフォームを限定したクラウドサービスである。

Heroku (pronounced her-OH-koo) is a cloud application platform for Ruby – a new way of building and deploying web apps.

Google App EngineのRuby版であるといってもよい。特にRuby On Railsで威力を発揮する。とにかく便利このうえない。RubyとGitがインストールしてあれば、以下のコマンドですぐにクラウドで自分のアプリが立ち上がる。

$ sudo gem install heroku
$ heroku keys:add
$ cd /home/aaa/sandbox/1stapp/
$ git init
$ git add .
$ git commit -m "1st commit"
$ heroku create
$ git push heroku master
$ heroku rake db:migrate

価格体系は極めてシンプル。DBの容量とHTTPのプロセス数、そしてジョブキューの処理ワーカー数である。

http://heroku.com/pricing

とにかく、クリーンで使い勝手がよいクラウドサービスで、なるほど、これは流行りますな。

このHerokuを見ていると、かつてはメジャーの道が見えたはずだったZopeやPloneがただのマイナーフレームワークに急速に転落した理由がよくわかるよ。もう、サービスとしてホスティング込みでできないとだめなんだよ、Webフレームワークは。

ちなみに、ZopeやPloneのホスティングサービスは無いことは無く、例えば、quintagroupのZopeホスティングが老舗として知られている。

http://quintagroup.com/services/zope-hosting

基本普通のVPSの上にZope/Ploneインスタンスを載せただけなんで、使い勝手も悪く、パフォーマンスもあまりよくない…。これならさくらインターネットのVPSを使って自分でZopeを構成したほうがいいと思う。

こういったWebフレームワークの外部性の問題は、フレームワークにコミットする開発者の獲得にこれからは決定的に重要になるだろう。

ただ、もっと根深い生得的な問題がZopeにはあって、こんなグチを言うのもなんだけれど、結局AppleのWebObjectsやZopeが世の中に普及することに失敗した理由というのは、それらのフレームワークが世界の有り様の全てを、オブジェクトオリエンティッドに写し取ろうとした点にあるよね。なんというか、パーシステントなデータをオブジェクトオリエンテッドな形式で持つのを許容するほど、世の中は寛容というか悠長でなかったんだよな。

結局、WebObjectsではRDBとOOPをつなぐEnterprise Objectsのパフォーマンスと効率性が常に問題だったし、ZopeはZODBのパフォーマンスが世の中の要求する速度と処理能力に対応できなかったと言ってもいいと思う。世の中の複雑な模様をそのままオブジェクトオリエンテッドにパーシステントな形で保存するのは、更新にも参照にもコストがかかりすぎるのだ。リレーショナルデータベースやキーバリューストアのパフォーマンスに比べたら、オブジェクトデータベースのパフォーマンスはあまりに悪すぎたのだ。

しかし、世の中はそういう屍を超えてドンドン進歩をしている。最近で言えば、Clojureもいいし、Rubyもいいね。ただ、実際問題として、僕自身は言語やフレームワークなんてなんでもよくなってきたというのも事実だな。

ECリコメンデーションシステムへの憂鬱

なぜAmazonのリコメンデーションはあんなにも使えないんだろうか？これは個人的な事情によるものなのだろうか？僕は上のキャプチャー画像にあるようにかなりの数の本を持っているとAmazonに申告し、そして評価をしているのだけれど、以前として自分の好みとはかなり外れるゴミのようなリコメンドしか返してこない。

Amazonが使っているリコメンデーションロジックは協調フィルタリングと言われていて、ユーザベースとアイテムベースの二つの方法でリコメンデーションをしていると思われる。たとえばユーザベースの場合、リコメンド対象のユーザの所持品目とその評価ポイントより他のユーザとの隣接度を計算し、例えばそれは階層モデルだったらcophen行列からピアソンの相関係数をもとめたり、非階層モデルだったらk-meansだったりするのだろうが、ニアレストネイバーのユーザを見つけたらそのユーザが持っていてかつリコメンド対象のユーザが持っていないアイテムを提示するという手順になると思う。

720以上のアイテムを申告し、そのうち430を評価し、更に570以上のアイテムを興味がないとしている。つまり一応は1300くらいのアイテムの情報をAmazonに教えているのだ。しかし、それでも自分の好みに照らして、依然としてロクなリコメンデーションを返さないというのは、Amazonでは僕のニアレストネイバーが見つからないということなのだろうか。つまり、Amazonが持っているユーザ母集団とは外れた選好傾向を持つ特異なユーザであるということだ。まあ、その可能性は十分ある。

ただ、そういった特異ユーザかどうかを置いておいても、Amazonのリコメンデーションシステムにはどうかと思うことがある。例えばスキャナーを買ったとしたら、別のスキャナーをリコメンドしてくることがあるのだ。スキャナー二台はスグにはいらねえ。もちろん、スキャナーを買うと裁断機もリコメンドするのは正しいのだが、裁断機は他で買ったからいらねえというつもりで「興味がない」評価をしても、Amazonセンセイは別の裁断機をリコメンドしてきやがるのだ。いい加減にしてくれ、というカンジ。これは、Amazonのアイテム評価の仕組みが個別アイテムごとの評価になっていて、カテゴリや著者やメーカーでの評価ができないためだろうと推測されるが。

リコメンデーションシステムの実装で一番高度だと言われているAmazonであっても斯くの如しなので、ECサイトでマトモにリコメンデーションを行うシステムは、まだまだ夢物語だなあと思わせられる。やはり、普段定期的にウォチングしている「目利き」の人の書評や商品評をアリアドネの糸とするべきなんだろうな、しばらくは。

Twitter白痴化論再論

最近行きつけのワイン屋でもコーヒー屋でも世間話にTwitterの話がでてくるようになってきた。へえ、商店街レベルでも認知されているのか、と少し面食らっている。これは二年前にこのブログで言ったような現象がやっぱりお約束のように実現しているんだろうね。

wrong, rogue and log : Twitterと協調問題、そして共通知識
http://bit.ly/cMEIjn

wrong, rogue and log : 共通知識とカスケード現象
http://bit.ly/9szlUR

「容易に考えられるのは、日本人はもともと均質化するような民族体質があるので、Twitterと非常に相性がよいということだ。今後Twitterのインタフェースがパンピー向けになったり携帯端末から気軽に利用できるようになったら大流行するだろうな、ということは予想できそうだ。」

それと同じ現象だと思うのだが、最近僕のタイムラインの中でやたらとTwitterを持ち上げ、個人と社会の関わりがドラスティックに変化するとか、個人が賢くなるとかの夢語りをするような日本語のtweetがretweetされてくるので、かなりウンザリしている。まあ、Twitterを初めて一年未満、だいたい数ヶ月程度のマーケ屋や広告屋ばかりなんだけどさ、もちろんのこと。それに対して、もう2年以上Twittererでいるベテランの人達は、そんな幻想は一切持っていないのも常識だけれど。

それで思うのだけれど、やはり2年前にこのブログ言っているように、Twitterは協調問題を解決する共通知識醸成のためのプラットフォームには成り得るけれど、そんな均質された場所からは、イノベーションや新しいアイディアは生まれてくる訳ないと再度言いたくなるのだ。オリジナリティやイノベーションは、均質に敢えて背をむけ、日常の生活習慣をベースに、個人の内奥にひそむ無謀で独善ともいえるアイディアの萌芽を、一人または数少ない集団で育て続けることでしか得られない果実なのだ。

協調問題とは、「私が知っている○○を、あなたが知っていることを、私は知っている」という状況を作ることで、「他の人が××をするなら、自分も××する」というふうに考える集団に対して、協調してひとつの行動をおこさせるようにする問題なんだよね。まさにこれはTwitterで解決しやすい問題だよね。例えば、「この本面白い」とtweetしたときに自分のfollowerがretweetすれば、「この本が面白いと私が知っていることを、followerが知ったということを、私が知っている」状況になるわけだ。これによって、その情報が共通知識になり、その共通知識を元にカスケード的な行動が起きやすくなる、というのがポイントだ。

共通知識による社会的カスケード現象は、東ドイツのベルリンの壁崩壊もそうだったし、イランの選挙騒動もそうだった。イランなどはまさにTwitterが大活躍だったよね。最近ではタイのデモ騒動もそうだよね。こちらは携帯掲示板とブログが主役だった。中国がオンラインにおける言説をコントロールしているのも社会的なカスケード現象が起き社会が不安定になるのを防ぐためだ。

このように、政治的な行動を起こすために必要なソーシャル・キャピタルのプラットフォームとして、Twitterやモバイルの掲示板は非常に有効に働くのは、ソーシャルwebが絡んだ人間行動を研究している研究者には常識と言っていいんじゃないか。vox.euを検索したり、Google Scholarで検索すれば、アホみたいな量の論文が見つかるよ。

しかし、この共通知識が成立した結果にカスケード現象が起きるということは、人間を一つの無個性な粒子にまで還元してしまう、ということであり、とてもそんな均質な場からは新しい知識やイノベーティブなアイディアなんて生まれるはずが無いというのが、僕の長年の主張だ。むしろ、タイムライン上のつまらないジャンクな情報に爆撃される機会が増えて、数少ない考える時間もそれに囚われちゃっているひとが続出なのじゃないのか？たしかに、Twitterをやるようになってテレビを観る時間が減ったとか主張する人はいるだろうけれど、その分、オンライン上の飲み屋話や床屋談義のシャワーを浴びてばかりいるんじゃないのか？まあ、確からしいのは、Twitterによる情報はS/Nが極度に低いので、Twitterで賢くなるのはナカナカ難しいだろうな、ということだね。

Google container data center tour

Google container data center tour
http://www.youtube.com/watch?v=zRwPSFpLX8I

「データーセンター」といったときにラックだとか1Uサーバーだとかをイメージしているようでは、もう既にその人は時代に取り残されているのかもしれない。

Googleの最新データセンターは、マシン本体があたかもプロセッサのように扱われているし、巨大なマシンコンテナがあたかも今までのラックのようだ。電力は自前の超高効率な変電所から分配されてくるものだし、冷却もセンター全体を冷やすよりも、冷媒をコンテナ内に引き込んだほうが効率が良いことから、コンテナとデータセンター全体をパイプでつないで冷媒を循環させる。結果として見かけは化学プラント工場のようになる。

一見するとマシンコンテナ自体はモジュール構造だ。しかし、エネルギー効率を高めるためにデータセンター全体としては擦り合わせで構成されている。この設計には圧倒されるが、その一方でこれにはなんだか既視感がある。そう、これは日本の得意分野じゃないか。こういったハイブリッドな擦り合わせから、日本のものつくり神話って出ているのじゃなかったか？

僕らに必要なのは、ものつくりのノウハウや経験を利用して実装することじゃなくて、一見途方もないバカにみえるこういうぶっ飛んだアイディアなんだ。今は実装なんて後からどうにでもなると割り切る方が、ものつくり神経症の国にはちょうど良いと思う。

Google Docsの進化

Google Docsがとんでもなく進化していて、自分達が利用するドキュメント作成もこれだけでいいし、社外へのドキュメント共有ツールもこれだけでいいと思ってきた。

機能として最近追加されたドロー機能と検索＆置換のハイライト機能は特にオススメだ。バージョン管理機能も充実しているし、最近のブラウザのJavaScript対応の進化の具合と歩調を合わせてユーザーインタフェースにおけるもたつきや不具合も極端に少なくなった。もうすでに実用十分なところまで成熟度が行き着いたと思う。現在、合理的に思考するテックサビーな人たちがMTAとメイルクライアントソフトの利用を止め、ほとんどがGmailに移行したように、デスクトップのOffice系アプリを使用しなくなる日はもうすぐだろう。

また、ドキュメント作成系の機能に加えて、検索の精度はもちろん素晴らしいし、簡単なフォーム機能、そして投票・集計もお手軽にできてしまう。更には、チームでのドキュメントの共有機能は見事な域まで達していると思う。つまり、イントラ系のドキュメントマネジメントシステム、コンテンツマネジメントシステムはGoogle Docs/Appsを利用すればもう十分なレベルにあるのだ。Gmailの添付ファイルになっているOfficeドキュメントからシームレスにドキュメント管理ができるのも実に便利だ。Zopeに関わってきた人間としては悲しい現実だけれど、CMSはこのGoogle Docs（およびApps)とtumblrのようなコンテンツタイプ別に記述できるマイクロブロギングシステムがあれば、それで十分というのが結論になりつつある。開発者としてもGoogle App Engineの上で簡単にGoogle AppsのAPIを使用できるから、既にi18nが施された超高機能なドキュメントリトリーバーを持ったCMSがすぐに実装できてしまう。これはBob Dylanが"Blowin' In The Wind"[www.youtube.com/watch?v=ced8o50G9kg]で歌っているヒューリスティックスを使うべき時だと思う。

The answer is blowin' in the wind.

テクノロジーの風の流れというか大局観を判断すると、現在は独自のCMSやドキュメント管理サービスを作るような時代ではないのだ、少なくともスモールスタートのビジネスとしては。

ちなみにtumblrだが、これはユーザーインタフェースが良くできた簡易CMSで、とても気軽に利用できるところが素晴らしい。以前からexblogのおそらくIISのセキュリティ要件由来と思われる無意味な制限、objectタグ等が利用できない、Windowsマシンでないと正常にwisiwygエディタが正常に動作しない、に頭にきているので、ついついexblogに書かずにtumblrに書いてしまいがちになる。

Google Docsを利用する上での懸念はGmailと同様にデータのストア場所がGoogleになってしまうということ、Googleの寡占化を一層進めるということなのだが、個人利用や僕らのようなスタートアップの利用を考える限り、データ保全の品質や可用性そしてデータを集約することによる正の外部性の意味から、むしろ好都合だったりする。友人の中には、自分には重要な情報がないのにもかかわらず過度にGoogleにデータを貯めることに拒否反応を起こす人もいる。でもそういう人に限って、自分が管理するMTAを二重化せずにクラッシュにより数週間分のメイルアーカイブを消失させてしまったり、メイルを平文で送るは、sshではなくtelnetだったり、鍵を使わずパスワードを平文で送ったりという、頭隠して尻隠さず状態だったりするんだよね。このようなむやみな拒否反応は論外だが、Googleに過度に依存することなく、使える機能は最大利用させてもらうというのが正しい態度なのだろうと思う。

YoutubeがHDに対応

ああっ、ここでもGoogleの快進撃が…。

http://www.youtube.com/watch?v=zlfKdbWwruY&fmt=22


Youtubeがハイディフィニションに対応である。こいつは、だいぶインパクト大きいと思う。なにせ、Youtubeが本格的な商用動画やCM・プロモーションを乗せることができるプラットフォームになっちゃたからだ。ケーブルテレビ局や地方放送局や動画ネット配信会社の目論見が目の前で崩れていくのが目に浮かぶ。

何より肝に銘じるべきは、現在絶好調のGoogleと同じサービスドメインで勝負しちゃ駄目だ、ということだ。

Google Flu Trends

うー、またGoogleに先超されちゃったよ。



Google Flu Trends [http://www.google.org/flutrends/]

仕掛けは、インフルエンザ関連の検索語、"flu"だとか"flu vaccine"だとか、の頻度とCDCのFlu Serveyの相関が高いことに注目し、インフルエンザ流行のインジケーターに使うというもの。そして、そのアイディアの実装がGoogleらしく、かしこくすばらしいものになっている。

もちろん、条件としては、広くみんながGoogleを検索エンジンとして利用しているという状況、そしてきちんとしたインフルエンザサーベイが存在していること、という二つが必要だ。その意味で北米での展開は正しい。日本やアジアではちょっと難しいかも。

http://www.google.org/about/flutrends/how.html

インフルエンザ以外の疾病にも応用できるのはもちろんだ。今となっては負け惜しみに過ぎないけれど、Google Trendsが導入された直後から、このアイディアは僕も周りには話していたのですよ。

半導体娘計画にみるイノベーションの埋没

半導体娘計画　　[http://www.nicovideo.jp/watch/sm5042812]

ニコ動コンテンツで初めてオオッと感じた。

会社員としてハードウェア記述言語(HDL)で回路設計をしているヨメにコレを見せたのだが、知り合いだったらヤダなあーと言っていた。彼女の会社は古くからの一部上場の通信機器製造メーカーで、こういう専用チップの回路設計技術をもったハードウェア技術者がゴロゴロいるのだ。彼ら技術者は、終身雇用だけれど安月給で、残業しまくりなのに好きな仕事だからと黙々と会社員で居続けるのだ。ちなみにコンピュータ技術者と大きく括った場合、日本の場合60%がハードウェア技術者で、40%がソフトウェア技術者である。ハードウェア技術者のほうが割合が多いのだ。

たしかに、以前はハードウェア設計やハードウェアの製造には、プロトタイプ製造であっても、それなりの設備が必要で、大きな会社組織でないとできないことも多かった。しかし、このニコ動をみてもわかるように、FPGAを利用すれば個人でも専用回路を持ったハードウェアを実装することができてしまう世の中になっているのだ。ちょっと、根性が必要だけれど。それに加えてだ、昨日のThe Economistの記事紹介(http://kashino.exblog.jp/7602086/)でもあるのだけれど、これからいろいろな情報サービスがcloudコンピューティングになっていき、そのサービスを受け取るクライアントサイドには、PCや携帯以外にも多様なハードウェアデバイスが登場してきている。そして、チップの処理性能と省電力性能が年々上がっているから、もっと奇抜なアイディアのハードウェアであっても実現可能になる素地を持っているのだ。

勤勉で優秀なハードウェア技術者を多数抱えていること、世界に冠たるブロードバンド網を持っていること、Amazon Web Serviceを初めとしたcloudコンピューティング環境がガチで揃っていること、オープンソースソフトウェアがここまで浸透して高品質なソフトウェアに容易にアクセスできること、そして昨今の金融危機の影響を直接受けていない金融機関が多数存在すること、これらの日本が置かれている条件を考えた場合、コンピュータ技術における日本人技術者のグローバルチャレンジは今が旬で、もしかするとこの機を逃すと二度と日本の目の前には現れないかもしれない。

いや本当に、今やらないと全部台湾に持って行かれちゃうよ、マザーボードを端緒として、液晶や携帯端末、ノートパソコンを根こそぎ持っていたように。この半導体娘計画の人がどのような人であるかはわからないけれど、ヨメの会社の技術者のようにハードウェア実装のかなり高度な技術はあるのだが、それをビジネス的に活かすことが出来ない技術者は、それこそ1万人くらいはいるのだ。余暇としてニコ動や他の趣味を箱庭的に遊ぶのも悪くはないが、そういった技術者は、自分が優秀なハードウェア技術者だと思うなら、自分の技術を活かしてビジネス的なチャレンジをするほうが、もっとでっかく遊べるのじゃないかと思うのだ。

Google Street View is on "Fire".

火事だ！

どうなんだろうな，こういう写真までMapの付属機能として掲載するのは．やっぱり多少の倫理的な検閲処理っていうのが必要なんじゃないかと思う．

まあ，Google Street Viewにはいろいろな見解があるとは思うが，一番問題なのは，彼らがどこまでやるかという明確なルールを未だにまともな形で提示していない点なんだよね．ジャーナリストにはジャーナリストのルールというのがあって，それ以上踏み込まないという一線を引くものだ．"Don't be evil"とブルシッティングするのは一向に構わないが，なにがevilであるかという定義を提示しないから，みんなが不安を持っているのだ．ピュアに技術志向でムチャクチャ賢いからこそ，その制限を自ら規定しない集団に対しては，誰でも恐怖心がある．だって，純テッキーって，"When all you have is a hammer everything looks like a nail."じゃないですか．

その結果，こんな妄想だって考えられる：そのうちGoogle Home SecurityとかGoogle Personal Viewなんてものが出てきて，自分の3D MRI画像のウォークスルーができたり，プライベートの全てを動画で記録されたり，DNA解析の結果を含めて全個人情報がアーカイブされ，検索されたりするのだ．オーウェルの1984だとか，未来世紀ブラジルの世界のように．そうなると我々は"thoughtcrime"とか"crimethink"とかを避けるためにGoogspeakという新しい言葉でしか公的な会話ができなくなったりして，最後はBig Brother Sergey とBig Brother Larryの元にひれ伏すしかないのだ．なんちゃって．

ルールを提示しないことでますます暗黒面に陥っているように感じられるGoogleに対して，かつて暗黒卿と呼ばれたWilliam Henry Gates IIIが僕には対置されるように思う．そしてMr. Gatesは現在，マラリア撲滅を含めた慈善活動を通じて，前人未踏の規模で世界を救っている真っ最中なのはなんとも皮肉な現実だと思う．まさに"Fact is stranger than fiction."