KAI_REPORT

気持ちいいテニス、2日目。

このところほんとに最高のテニス日和。にもかかわらず隣のコートが空いている。なんとももったいないことよ。

ま、そんなことはほっておいて、こう言う気持ちいい天気のときは、全然負ける気がしません。結果も6-0、2-6、7-5の2勝1敗。

このラストゲーム、6-5で相手サーブ。キープされるとタイブレークにもつれ込むと言う危ないところで、相手方のボレーミスに救われる。最後はこちらの強気のボレーに相手が打ったボールはあえなくネット。7-5となって、この2勝目は大きかった。

こんなテニスの話ばかりしている間に、毎日順送りになっている話をそろそろ片づけなくっちゃ。

一つがグーグルギアに関して。

このグーグルギアがなんなのかは、このITProの記事Webアプリをオフラインで使える「Google Gears」を使ってみたを参照。

マイクロソフトもXAML（ザムル）で一生懸命このオフライン問題を克服しようとしているけれど、グーグル含めてみなことの本質が理解できていません。

アプリケーションがネットで動作するときは、これは有償無償関係なくサービスです。

しかしこれがオフラインで動作するときは、そのアプリケーションのリソースはユーザー側にあり、これをオンライン同様サービスとするには無理があります。結果グーグルギアが、その昔のロータスノーツ同様のアーキテクチャーの迷路に迷い込むのもむべなるかなです。

そもそもオフラインとはなんぞやを考えれば、これは単なる通信断ではないのです。オフラインとは空間であり、オンライン空間と対をなすものです。つまりオフライン空間もオンライン空間同様のアクセス可能として、両者の同期を取る必要のない独自空間として定義すればいいのです。

具体的には、テラレベルの通信で実現される世界になりますが、オフライン空間はオンライン空間接続時に自動的に構築される空間で、これ独自で動作するWebアプリの空間として用意されたものになります。

当然オンライン空間に接続するための標準APIも準備されていますが、これは決して両者の同期をとるためのものではなく、互いの空間のWebサービス同士が連携しあうためだけの機能として存在します。

これが前掲の記事で取り上げられているGoogle Readerでどうなるか。きわめて乱暴な議論をすると、オフライン空間上にオフライン空間専用Google Reader環境がまるごと構築されます。

これをオフラインで利用する状況はほぼ前掲の記事と同じになります。違うのは、再びネットに接続する時です。グーグルギアでは自動的に同期がとられますが、オフライン空間用Webアプリはそうはなりません。オフライン空間には、必ずオンライン空間へデータを反映させるためのボタンが用意されていて、これを操作するかガイダンスに従って反映させるか、いずれにせよ明示的に指示する必要があります。

これはGmailをオフライン空間で動作させることを考えると明らかで、オンライン空間上のGmailをそのままオフライン空間に持ってきても正常に動作しません。クライアントインストール型のメーラーと同じくオフラインモードで動作する必要があるからです。

しかもオンラインに復帰しても一部のアドレス帳の情報以外は別にオンライン空間上のGmailと同期を取る必要はまったくありません。Gmailのデータとしてのメールの情報そのものはアプリケーションの機能それ自身によって自動的に最新の状態に更新されるからです。

Gmailの例でわかりにくければ、SaaS形式の販売管理アプリケーションを考えるとこれは明白で、営業マンがネットに繋がらないところで顧客の指定する商品の在庫を見ながら注文を入力することを考えてみてください。

オンライン空間上のアプリケーションは、まったくそのまま使用はできません。オフライン空間上のアプリケーションには、オフラインモードでの在庫照会と受注入力機能が必要で、オンラインに復帰した時にその注文を送信し、万一在庫切れの場合在庫引当から発注引当に切り替える機能が必要になります。この環境をオンライン空間に接続中に、自動的に構築すると言うのが、KAIの考えるオフライン問題を解決するアーキテクチャになります。

そしてもう一つ取り残してきた話題が、満足せる豚。眠たげなポチ。さんが作ったConcepts + Principles - プログラミングの原則と言うwiki。

長くなったので簡単に触れますが、こういったwikiが充実してくると劇的にプログラマの作業環境が改善してくるものとKAIは考えます。今までであればこういった知の情報は、1企業の中に閉じられていました。

なにかしら力になれないか考えますが、成功するまであきらめないで頑張ってほしいと思います。　KAI