先週の金曜日はGoogleデベロッパー交流会に行ってきました。今回のテーマはGoogle Gearsだったんですが、実は事前まで知っていたのは名前と概要ぐらいで実際に触ったことはありませんでした。パネルディスカッションできちんとしたことが言えるようにチュートリアルなどいくつかドキュメントはなんとか読むことができたので、あまり的外れなことはいわなかっただろうと思っています (^^ゞ
さて、チュートリアル等いくつかドキュメントを読むことはできたものの、実際にサンプルを動かしたり自分でプログラムを作るところのレベルまでは準備ができなかったので、どちらかというとGearsを使った場合にシステム全体のアーキテクチャがどうなるだろうかということを中心に考えていました。まず一つ目は既存のWebアプリケーションとどのようにアーキテクチャ上、融合していくかです。現状のWebアプリケーションは、分け方は様々であるにしても、HTMLを生成する層、ビジネスロジックを処理する層、データを管理しておく層など幾つかの層に分けて設計することが一般的です。ここではCore J2EE Patternsで紹介されているように次のような層を想定しておきましょう。

• クライアント層 ... ブラウザなどユーザとのインタフェース
• プレゼンテーション層 ... JSPやPHP等を使って画面を生成する
• ビジネス層 ... ビジネスロジックやトランザクションの処理等
• インテグレーション層 ... リソース層との橋渡しをする層。JDBCやJMS等で通信手続きなどを抽象化する
• リソース層 ... データの管理を行うデータベースやERPなどのシステム

ここでGearsを使ったアプリケーションのことを思い浮かべてみることにしましょう。GearsはFirefoxやIE、Safariといったブラウザに導入するプラグインで、上記で言うクライアント層をターゲットとしているのは間違いありません。ただ、Gearsはそのアーキテクチャの説明にもあるように、クライアント層の中でもアプリケーションUIとデータを分離するために層をもうけるべきだとしています。

これらの層をふまえてアプリケーションを設計する場合、多くの点では今までと同じように設計をして、Gearsを活用したリッチなユーザエクスペリエンスを提供するようにJavaScriptを駆使することになると思います。まとめるとだいたい次のようなアーキテクチャになるでしょうか。

おそらくGearsを使った場合、結果的にはだいたいこのようなアーキテクチャになると思いますが、今回は「考えてみる」とまで題しているのでもう少し話を進めてみたいと思います。Gearsにしても、それ以外の技術が出てくるにしても、Webアプリケーションのユーザエクスペリエンスの改善という点から考察すると、クライアント側のデータベースや非同期処理、キャッシュといった技術は欠かせない要素です。では、最もアグレッシブにGearsの機能を使った場合を考えてみます。Gearsには指定したURLのデータをキャッシュする機能、ローカルに持つことができるデータベース、また主にオフライン／オンラインきり代わり時などにデータをサーバに同期させることを目的としたワーカプールというスレッド管理の機能があります。このワーカプールを使えば、ある意味で何でも処理ができてしまう訳で、場合によってはビジネスロジックまで記述することができるかもしれません。それ以外にもローカルのデータベースに何でもかんでもデータを記録してしまうということもできるでしょう。
ただ、一方ではローカルだけでは処理できないビジネス処理はいくつかあると思います。例えば、ショッピングサイトの買い物確定はローカルだけでは処理できないでしょう。ローカル側で確定した、ということを記録しておいてオンライン化した際に買い物の確定データを同期するという手段で、見せかけ上ローカル側で処理したようにすることもできるかもしれませんが、オフライン化している間に在庫や価格など条件が変わってしまうことがあることを考えればそこまで踏み込んだロジックをGears等を使って実装することはやや非現実的です。また一方、データベースに関しても、お店側の在庫データや価格データをすべてクライアント側に持っておくことはナンセンスです。 それらを考えれば、クライアント側で処理すべき部分と、サーバ側で処理すべき部分は依然としてある程度明確に分類することができそうです。

上図はそれらの分類を基にもう少し考えを進めてみたアーキテクチャです。今までのアーキテクチャと違い、プレゼンテーション層(この場合、名前は もう少しかえた方がいいかもしれません)はサーバとクライアントをまたいで存在するようになり、プレゼンテーション層内部でも役割別にある程度機能をグループ化することができるようになると思います。ここであえてクライアント／サーバをまたいで層を描いてみた理由は、クライアント側で実行されるJavaScriptのロジックも結局はサーバ側で生成しているためです。また、さらにあえてその辺りを意識しなくてもアプリケーションが設計できるようにjMakiのようなラッパーライブラリはこれからもどんどん成長していくと思います。
さて、処理の役割に注目していきます。たとえばクライアント側で処理すべき役割はユーザインタフェースそのものの実現や、表示用のデータの管理です。一方、サーバ側では画面遷移や画面自体の生成が主な役割になります。画面遷移や画面生成をクライアント側に持っていくこともできなくはないですが、システムによっては画面要素に対してそれぞれ権限のチェックなどが必要だったりすることとから考えてサーバ側に置かれているべきでしょう。
データベースはGearsを使えばローカル側にも設置される訳ですが、保存されるデータは表示用のキャッシュデータや、ユーザ自信が作成しする未確定のデータに限られると思います。ユーザ自身が作成する未確定のデータとはSNS上での自分自身のプロフィールや書きかけの日記などです(当然ながらそれらのデータを常にサーバ側に同期することは必要に応じて実施する)。一方、確定済みのトランザクションやデータはすべてサーバ側で管理されているべきでしょう。
さて、以上のように少し自分の中ではGearsの位置づけがようやくすっきりしました。こういった話もこの間のデベロッパー交流会でしようかと思っていましたが、どちらかというと交流会ではどう使っていくか、がメインだったので今回はあきらめました。また、どこかでディスカッションする機会があればいいなと思います。

最近あんまりテクニカルな話題がないことをお許しください。またもやテクニカルではないお話、というか単なる写真紹介です。ガジェットオタクとしては自分でもよく写真を撮るようになると、周りの人の持っているカメラが気になってきます。そういえば、この間発売されたばかりのハイエンドカメラNikon D3を買われた方も。自分がカメラをガジェットの部類として認識しだしたのは去年の1月にNikon D50を買ってからです。この前からもデジタル一眼には興味があったものの高いし、使いこなせるかわからんので要らないと。思っていました。ところが、一生分の運を使い切って(使い切った今だからいえますが) そのデジタル一眼が買えてしまうぐらいの賞が一昨年の年末ジャンボであたり、ふらふらと電気屋さんに行って買ってしまったのがカメラオタク化の始まりです。
とはいってもまだまだレンズをたくさん持っていたり、専門用語をたくさん知っているわけではありません。去年からの写真の枚数はflickr.comにアップロードしてあるので22,000枚(非公開含む)ぐらい、シャッターを押した回数で言うとだいたいその2倍ぐらいだと思います。写真は質より量派(?)なので、あまり一枚一枚は脚光を浴びることはありませんがたまには一枚一枚紹介してみることにしてみます。今回のテーマはエビです。ではご覧ください。

コガラシエビ (Nikon D50, Sea & Sea DX-D50, YS-110, Sigma MACRO 105mm F2.8 EX DG), Kapalai, Malaysia.
残念ながら目にピントが合っていません。TTLコンバータを持っていないので、ストロボがTTL発光できていないのですが、もう少し絞ってストロボを強めにしたらよかったなあと今更思う一枚。

オトヒメエビ(?) (Nikon D50, Sea & Sea DX-D50, YS-110, Sigma 30mm F1.4 EX DG HSM), Kapalai, Malaysia.
これも目にピントがきてませんね。わりとどこにでもいそうなエビ。

アカスジカクレエビ(?) (Nikon D50, Sea & Sea DX-D50, YS-110, Sigma MACRO 105mm F2.8 EX DG), Kapalai, Malaysia.
これも目にピントがきていません。失敗ばかりです。透明でちっこい、かつよく動くエビにフォーカスを当てるのは涙ものです。プロの人って本当にすごいと思います。

ベンテンコモンエビ, (Nikon D50, Sea & Sea DX-D50, YS-110, Sigma MACRO 105mm F2.8 EX DG), Kapalai, Malaysia.
こいつも透明で、かつふわふわ浮いていたのでさらに大変でした。映っただけでも奇跡的です。

オシャレカクレエビ, (Nikon D50, Sea & Sea DX-D50, YS-110, Sigma MACRO 105mm F2.8 EX DG), Kapalai, Malaysia.
透明なやつらはPCで確認するまで映っているかどうか自信が持てません。

オシャレカクレエビの隣にいたエビ。名前わからん・・ (Nikon D50, Sea & Sea DX-D50, YS-110, Sigma MACRO 105mm F2.8 EX DG), Kapalai, Malaysia.
エビの種類とか全然名前が覚えられません。こういう名前がぱっぱと出てくる人たちはすごいと思います。

Periclemenes kororensis, (Nikon D50, Sea & Sea DX-D50, YS-110, Sigma MACRO 105mm F2.8 EX DG), Kapalai, Malaysia.
こいつは珍しくフォーカスも露出もいけてる気がします。

何エビかわかりません・・。ごちそうさまでした。(Ricoh Caplio GX100), Palo Alto, California.

そういえば、新しくブログをはじめられた鈴木さんのエントリをみて思い出しました(?)が、昨年ぐらいからブログのプロフィール欄に本業はIdentityだ、と書いておりましたが2ヶ月ほど前よりSOAあるいはSun Java CAPSの担当になりました。同じチームでSun Java CAPSを担当されている方いうと、ナニエバ奮闘記でおなじみの輪崎さん、まい・はうすの竹村さん、あるいは谷本さんと同じです。SOAとIdentity、違うようで関連は結構あったりするのでたまには両方やるかもしれませんがよろしくお願いいたします。

早いものでもうすぐ今年も終わろうとしていますね。まあ、あと3週間すこしあるわけですが早めに来年に向けて今年の反省をしておくことにします。今年は年の初め頃に、よくありがちな頭文字を並べた標語を自分の中で掲げました。ABCSです。

• A = Aggressive(挑戦的な)
• B = Balanced(バランスのとれた)
• C = Controllable(制御可能な)
• S = Sustainable(持続可能な)

自分の行動をこれらの形容詞と照らし合わせて適切かどうか、著しく外れていないかどうかをもう一度自分に問いかけることにしたのです。このABCSを思い浮かべたときに、細かくみれば年間を通してだいたいうまく満たしていたかもしれません。ところが、よく振り返ってみると自分の自由な時間(含、勉強時間)はかなり減っていましたし、たとえばセミナーの準備や告知も直前までどたばたしていてとてもControllableではなく、Sustainableとはいえなかったと思いますし、ほかのBalancedやAggressiveといった形容詞もうまく当てはまらないケースが年間を通じてとてもではないけれど「満たしていた」とはいえないレベルだったと思います。

原因はいろいろあったと思いますが、一つには目標が高すぎた、あるいは多すぎたことがあげられると思います。一つの仕事に対してだけでもこれらABCSを満たすのはとても大変なことなのに、仕事は次から次へと山積みになる。そうすると、次の仕事は満足にそれらの対策をする時間がなくなってしまう。「品質」を確保しようとすると自由時間や睡眠時間を削ることになり、「時間」を確保しようとするとABCSのどれにも当てはまらない仕事になってしまうという悪循環に陥ってしまったと反省しています。
ABCSは気に入っているので、これからも心の奥底では意識して行くにしても、ひとまずはこの状況を変えていきたいので、来年、というか今週あたりからは別のもう少しシンプルな目標を目指していくことにしました。その目標が表題の「ストップ・ザ・これっきりシンドローム」です。
これっきりシンドローム、とはJavaOne Tokyo 2005での川口耕介さんのセッション「定時退社のためにJava」で覚えた言葉ですが、このプレゼン資料を見たときから自分の中で心の中によく響く言葉になっていました。

今年、ABCSを満たせなかった原因を別の視点から観察すると、「コレさえ乗り越えればあとは・・・」という気持ちでした。まさに「これっきりシンドローム」。セミナーにしても、(本業の)プリセールスのお仕事も、それぞれ大変で、多くの場合、すでにお断りできない状況になっていたりして、後は根性で乗り切る。というような気持ちに支配されていました。こっぴどくおしかりを受けるようなことはあまりなかったのは運がよかったとしても、大きな失敗をしてしまいそうなのはもう目に見えています。
今週からはこれっきりシンドロームを終わらせることを最優先事項として解決していこうと思います（たとえば、いま10時間必要な作業にまるまる10時間かけるのではなくて、9時間はその仕事、残り1時間は今後同じ作業が9時間でできるようになるための勉強や準備。とか）

最近飲み会が多くなったことと、あまり運動しなくなったことによって体重は激増。おかげさまで、会うひと会う人に「太ったね」って言われるようになりました orz
今月はいよいよ忘年会シーズン突入ですが、このままの勢いで突入すれば間違いなく今持っているズボンはすべて買い替えなければならなくなりそうです。かといって「○○ブートキャンプ」は自分にはオーバースペックすぎるということもよくわかっていますし、エクササイズのDVDも買ってしばらくするとやらなくなるのは実証済みです。
体脂肪はおおよそ1kgあたり7200kcal程度だと聞いたことがありますが、仮に「○○ブートキャンプ」が500kcal/時間の運動量だったとして(あのハイレベルな運動についていけないならもっと低めかも・・)、体脂肪を1kg減らすには約15時間もあの大変な運動を必要とします。自分のように数キロ減らしたい場合(現在の体重 × 現在の体脂肪率 - 20歳の頃の体重 × 20歳の頃の体脂肪率)にはそれこそ数週間、仕事を休んでブートキャンプ状態でなければ達成できない訳です。
そういった激しい運動はあきらめて、地道に夏頃は週末に自転車で運動をしていたんですが、今月の週末にはすべて飲み会の予定が入っていてほぼ不可能。早起きして運動するにも寒すぎるのと、飲み会等で夜遅いとそもそも早起きできないという条件がすべて揃ってしまいました。

そんな中、12月1日の昼頃に新宿でご飯を食べてそろそろかえろうかと思っていたところ、たまたま目の前の人が発売されたばかりのWii Fitを抱えてエスカレーターを下りているのを見かけました。ここ数年、めっきりゲームもやらなくなり、ゲームの発売日なんて全然しらないし、そもそもどんなゲームがあるのかもよくわからないぐらい。それでもWiiとWii Fitはかすかに何かのニュースでみて何となくどういうものか記憶があったので、急激に欲しくなり衝動買いしてしまいました。
Wiiはなかなか手に入らないというニュースをよく目にしていたので、無かったら多分急激に欲しい熱が冷めて1年経っても買わなかったかもしれませんが、たまたまそのとき新宿にいたことによって大量に入荷していた量販店で簡単にWiiもWii Fitも手に入りました(家の近所の電気やに行ってみたら見事に売り切れでした)。
さて、そのWii Fitですがまだ2日しかやっていませんが、全体的によくできていると感心しました。Wii Fitには体重計のようなコントローラ(ウィーボ?)がついてくるのですが、これは体重を量ったり、体の重心が検出できるようなコントローラで、エクササイズはだいたいの場合このウィーボの上で行います。自分の体重で壊れてしまわないか心配でしたが、136kgまで耐えられるとのことだったのでひとまずその点はクリアできました。

さてWii Fitのソフトにはヨガとか筋トレなどのメニューが入っていて、トレーナーが指導してくれるような構成になっています。エクササイズDVDを買ってしばらくするとやらなくなるのは、DVDの指示通りにうまく自分ができているのかどうかがよくわからない(DVDだけではなくて、ジムのトレーナーでも一方的な指導をされるトレーナーの方だと同じ)、というのが原因で飽きてしまいます。一方、Wii Fitでは重心のふらつき等からトレーナーが背筋を伸ばすように指導したり、良ければ良いとフィードバックをくれるので自分の動作に自信が持てるようになります。また、おそらくしきい値がうまく設定されていて、あまり何度も何度も指摘をされるということもありません。
エクササイズの他にも日々の体重や重心バランス年齢などが記録されていきます。体重を日々メモすることは、前々から何回もやろうとしては挫折していたのですがこのように自動的に記録される仕組みは、おそらく自分の無精さをカバーしてくれると思います。また、その日の計測を終えるとはんこを押す、というメニューがあるのですが、これによって一定の達成感を与えることで継続させる気持ちを後押ししているのでしょう。
少し気になったのは、この手のシステムであれば通常、運動によって消費されたカロリーの推計値が表示されたりすることが多いのですが(例えばカラオケとかでも)、Wii Fitの場合は(まだ説明書を読んでいないので知らないだけかもしれませんが)そういった指標は使用せず、主に運動時間だけを指標としている点です。これほどよくできたソフトですから、おそらく、実現しようと思えばさほど難しくはないのだろうと思いますが、あえてそうしていないのも、昨日たくさん運動したから今日はいっか。という気持ちを発生させなくしようという考えなのかもしれません(特に「○○ブートキャンプ」のように過激な運動で短期間で減量しようというスタンスを否定したいのかもしれません)。

このようなユーザに自信を持たせたり、継続を促すインタフェースや仕組みはソフトウエア関連の仕事をしている者として大変勉強になりました。あとはこれで目標の通りに脂肪燃焼ができれば言うことなしです。

スラッシュドットにも出ていますが、yarri.comからの招待状メッセージに注意！せよ、との騒ぎが起こっています。うちのところにもメールが来て、yaari.comからの招待状を無視してください(recompile.net)の

ことの経緯は、次の通りです。私がある人からyaari.comからの招待状をうけとりました。その人は海外の動向にも詳しく、何か面白いサービスを見つけたのだろうと考え、yaari.comで入会の手続きをしました。

と同じような経緯で、あまり気にせず登録をしようとしてしまいました。登録画面で、Gmail、Hotmail、Yahooのいずれかのメールアドレスでなければならない、というような聞いたことの無い制約があったものの、あまり気にしないで登録をしようとしたら、Yahoo! Japanのメールアドレスはだめで登録できず。あと、気乗りはしなかったもののGmailでも試そうかと思ったらエラー。その辺りでもう面倒くさくなってきて、結局登録は成功しなかったものの、後でスラッシュドットとか複数のニュースを見て、危なかったなあとヒヤヒヤしました。
結局、エラーとなったのはパスワードを入れるところで、てっきりこれから登録するSNSのパスワードを入力するのだろうと思っていたところが、実はGmail等メール用のパスワードを入れることになっていたのがエラーの原因。普段よく使うGmailとかYahoo! Mailと、このようなSNSとかその他のサービスではパスワードは共有しないように気をつけていたので、今回はぎりぎりセーフでしたが、あまりよく読まずに入力したのは反省すべきところでした。

---

P.S. 個人的にはYarri.comへの登録は失敗したので今回はなんとかセーフだったと思っているのですが、万が一招待状が届いているようでしたらお知らせください。