雑誌が出てもすぐに読まずに積み上がっていき、突然読み始めます。と言うことで、今ごろ、WEB+DB Press Vol.45(今年の6月に発売)を読んでいます。

「iKnow!構築ノウハウ」という記事の開発スタイルについて書かれた部分に興味をひかれました。

iKnow!の開発サイクルは2週間のようです。このサイクルでリリースするとは随分短いサイクルだな、と驚いたのですが、更に驚いたのが、テスターによる最終テストが2日間しかないという記述です。しかも、UIの最終調整もこの最後の2日間に行うと書いてあります。それまでに充分に単体テストが終わっているようですが、それでも、画面の動作確認がたった2日間で終わるのは信じられません。「その2日の間にテスターが動作確認やバグの発見を行い、リリースを承認します」と書いてあるので、形式的なチェックではなく、バグを見つけるテストなのだと思います。画面周りの細かいバグが修正も込みでたった2日間で収束するのは驚きです。アリエルとは、何か根本的に前提が違うのでしょうか。

facebookアプリは、その内部動作の違いで、FBMLタイプとiframeタイプのふたつに分類できます。

FBMLタイプは内部的にはfacebookのサーバがreverse proxyとして動作します。ユーザサイドにあるfacebookアプリのレスポンスはfacebookサーバを経由して、エンドユーザのブラウザに届きます。FBMLはfacebook固有のカスタムタグです。HTML(正確にはXHTML)内に<fb:name uid="12345"/>のように記述しておくと、reverse proxyの過程で、タグがfacebookのユーザ名に置き換わります。iframeタイプは、名前から想像できるように、facebookのサイトの中にiframeでユーザサイドのアプリ(ページ)を表示します。

ふたつの動作の違いは、後述する記事(http://www.ccheever.com/blog/?p=10)の図を見ると分かりやすいと思います。

以前(http://dev.ariel-networks.com/Members/inoue/salesforce)、salesforce.comの動作を説明しました。FBMLタイプは、独自カスタムタグがあり、サーバサイドで処理される点はsalesforce.comと同じです。ただし、salesforce.comの方は、アプリの実体がsalesforce.com上にあるのに対し、facebookアプリはユーザサイドに実体がある点が異なります。

salesforce.comの記事で、同じ仕組みを動作させること自体は難しくないと書きました。facebookアプリの方も、同じ仕組みを動作させることだけなら難しくありません。reverse proxy自体はApacheをはじめオープンソースのソフトが既にありますし、reverse proxyする過程でコンテンツ(XHTML)を書き換える処理をいれることは難しくありません(必要なカスタムタグをすべて実装するのは大変ですが、技術的な難易度と言うよりは面倒さによる大変さです)。一方で、salesforce.comと同じで、安全かつスケーラブルかつ安定に動作させることは容易ではありません。単に同じ仕組みで動作させることと、安定運用させることには大きな差があるのです。これはfacebookアプリでも同じです。

実は、ここまでは前振りです。

以下、FBMLタイプとiframeタイプのアプリをそれぞれFBMLアプリとiframeアプリと呼ぶことにします。

従来、世間的にはFBMLアプリが推奨されていました。実際に作ってみると、FBMLアプリの方が素直な作りになります。例えば、画面にユーザ名を出す場合を考えるとよく分かります。FBMLアプリの場合、前述したようにFBMLアプリのレスポンス(XHTML)内に<fb:user/>のタグを書いておくだけです。カスタムタグの処理はfacebookサーバがキャッシュするなどして高速に処理してくれることが期待できます。一方、iframeアプリで同じことをするには、iframeアプリがfacebookサーバにWeb APIベースでユーザ名を取得して、レスポンス(X)HTML内に出力する必要があります。毎回、Web APIを呼ぶオーバーヘッドが嫌ならば、iframeアプリが自前でキャッシュする必要があります。本来facebookサーバが管理しているデータをこういう風にキャッシュするのは不毛に感じます。

では、FBMLアプリで決まりなのかと言うと、そうでも無いのが困りものでした。FBMLアプリはJavaScriptと相性が悪いのです。使えないことはないのですが、色々と制約があります。その点、iframeアプリには何も制約がありません。iframeアプリであれば、元々、facebookを意識せずに作ったWebアプリを簡単に動かせます。特に、AJAXを使うアプリの場合、FBMLアプリでは、facebook用にコードを書き換える必要があります。iframeアプリならそのままのコードで動作します。

結局、facebookと心中する気ならFBMLアプリでいいですが、そうでも無ければ、現実的な解はiframeアプリ、というのが個人的な結論でした。

ここで、iframeアプリ推奨という別の動きがでてきました。

• http://www.ccheever.com/blog/?p=10
• http://developers.facebook.com/news.php?blog=1&story=152

技術的なポイントはXFBMLです。

• http://wiki.developers.facebook.com/index.php/XFBML

XFBMLは一見するとカスタムタグですが、従来カスタムタグと呼ばれていたものがサーバサイドで処理されていたのに対し、XFBMLのカスタムタグはブラウザのJavaScriptが処理をします。他の同種の技術があるのが寡聞にして知らなかったので、これには驚きました。

XFBMLを活用すると、iframeアプリはレスポンスをブラウザに直接返し、facebookの情報(ユーザ名など)はブラウザのJavaScriptがfacebookサーバに問い合わせる形になります。実は、この動作原理は、後発のOpenSocialと同じです。

OpenSocialは(その他多くのJavaScriptベースの技術同様)、伝統的なAPIベースです。クラスライブラリ的と呼んでもいいですし、RPC的と呼んでもいいです。もし(SNSサーバ上の)ユーザ名を取得したければ、JavaScriptのAPIを呼んで、AJAXで取得したユーザ名を表示HTMLに反映させる処理を書きます。一方、XFBMLの場合、XHTML内にカスタムタグを書いておけば、JavaScriptのライブラリコードがAJAXでユーザ名を取得してXFBMLのカスタムタグの部分を置き換えてくれます。

この動作の技術的なポイントは下記の「Cross Domain Communication」です。

• http://wiki.developers.facebook.com/index.php/Cross_Domain_Communication

facebookの技術は馬力はあるけどエレガンスさは無いと侮っていましたが、やられました(もっとも、XFBMLをまだ使っていないので、使ってみたらアラが見つかるかもしれないことは付記しておきます)。

C++0x(次期C++標準仕様)の使い道で一番役に立つのは、プログラマの採用活動でしょう。C++を完璧に使いこなす人はプログラマとして外れがありません。更に、非同期処理(イベントドリブン)とマルチスレッドを組み合わせたC++プログラムでメモリリークを起こさず書けるプログラマなら他の欠点に目をつぶってでも採りにいくべきです。

ちなみに、C++を褒めているわけではありません。C++は難しすぎます。動くだけのプログラムならそうでもないですが、例外やコピー周りで、ちょっとしたことを知らないだけで、メモリリークの起きるコードを書いてしまうのが恐いです。かと言って、ガベージコレクションがあるぐらいなら、C++でなくてもいいや、という気分になります。