Life is beautiful

Twitterを使ったブクマを格段に簡単にするTiny Quote

　興味深い記事やブログエントリーをネットに見つけた時に、それにひと言コメントを付けて投稿、というのはTwitterで良く見かける行動パターンの一つ。それも他の誰かのためにというよりは自分自身への備忘録という意図の場合もしばしばあるので、ある意味で「ソシアル・ブックマーク」的な使いかたに近づいてきているとも言える。

　ただ、そんな時に１４０文字の中に記事中で気になった文章を引用しつつ自分の意見を述べてかつURLを詰め込む、というのはなかなか難しい。

　そこで、先日の Tiny Message のバックエンドをこの問題の解決に使えないかと作ったのが、Tiny Quoteというブックマークレット。それなりに動き始めたのでここで公開する。

TinyQuote （←このリンクはクリックせずにブックマークバーにDrag&DropもしくはCopy&Pasteして登録してください）

　このブックマークレットをブラウザーのブックマーク・バーに登録しておけば、ワンクリックで（１）自分のコメント＋（２）引用文章＋（３）記事のURLを１４０文字制限に縛られずに投稿できる（現在のところSafariとFirefoxの最新版のみで動作確認済み）。

　ページの一部を引用したい場合は、あらかじめその部分をマウスで選択してからブックマークレットをクリックする。ただし、あまり長い文章を引用しようとするとURLの長さ制限にひっかかってしまうので（ブラウザーにURLが長すぎると文句を言われる）、英文で１０行程度、５行程度が限界のようだ。

　ちなみに、ここで使っている Tiny Message のAPIは後日正式に公開する予定である。このブックマークレットのソースを読めば使い方は分かると思うので、それまで待てない人はどうぞ。

Google App Engine入門：フレームワークの選択

　Google App Engine向けのアプリを作る際に最初に悩んだのはフレームワークの選択。Google App Engineにはwebappという最低限の機能を持ったフレームワークが付いて来るが、Python使いの人たちの間では、DJangoというフレームワークが広く使われているらしいし。かといって、あまり大きなフレームワークを使うと、パフォーマンスのチューニングとかもしにくくなるし、フレームワークそのもののバグや制限に悩ませられる可能性もある。

　そんな中で増井君が見つけてくれてまず試したのが、Junoというフレームワーク。DJangoと比べると遥かに小さく、WebappよりもURLのルーティングのメカニズムとかが充実している。

　そこで一旦はアプリをJunoの上で作り始めたのだが、Junoのソースコードを見ているうちにいろいろと気に入らないところが出て来た。不必要にオプションが多いし、同じことをする方法を何通りも用意している点が気に入らない。そしてどうしても我慢ができなかったのが、レスポンスをグローバル変数を通して行っていること。ちょっとこれでは使えない。

　そこで着目したのが、JunoにあってWebappに不足しているのはURLルーティングのローカルな記述だけだという点。Webappの場合、URLのルーティングの規則を以下のように一カ所に固めて書かねばならないのだが、

class LoginHandler(webapp.RequestHandler):

    def post(self):

    ... loginの実装
 

class LogoutHandler(webapp.RequestHandler):

    def get(self):

    ... logoutの実装

application = webapp.WSGIApplication([('/login', LoginHandler),

                                        ('/logout', LogoutHandler),

                                        ... URLからHandlerへのマッピングリスト

                                        ])

wsgiref.handlers.CGIHandler().run(application)

Junoの場合は以下のように、処理をするファンクションにデコレータの形でURLを記述できるのである。

@juno.post('/login')

def process_login_form(web):

    ... loginの実装
 

@juno.route('/logout')

def logout(web):

    ... logoutの実装

juno.run()

　そこで思いついたのが、同じような仕組みをwebappでできるようにするモジュールを作るということ。それさえできれば余計なフレームワークなしでwebapp上でアプリを作ることができる。

　そして試行錯誤の作ったのが、gdispatchというモジュール。使い方はほぼJunoと同じで、

@gdispatch.route(lambda:('/login', LoginHandler))

class LoginHandler(webapp.RequestHandler):

    def post(self):

    ... loginの実装

@gdispatch.route(lambda:('/logout', LogoutHandler))

class LogoutHandler(webapp.RequestHandler):

    def get(self):

    ... logoutの実装

gdispatch.run()

とするだけの話。これがあれば、RequestHandlerの数が増えて複数のファイルまたがったとしても、関連するURLマッピングのルールはそれぞれのRequestHandlerと一緒に記述できるのでとても便利である。

　ということで、結論としては「フレームワークとしては、Google App Engineに標準で付いて来るwebappに必要最小限の手を加えて使うのが一番良い」というのが私なりの結論である。

　ちなみに、gdispatchはgithubに公開しておいたので試したい方はどうぞ（http://github.com/snakajima/gdispatch）。

「リニアにスケールするように作れる」からこそのGoogle App Engine

　Google App Engineを使った最初の作品 Tiny Message （http://tinymsg.appspot.com）をリリースしてまだ２０時間経っていないが、設計の過程でいろいろと学べたことがある。

　その中でも一番収穫として大きいのは、「Google App Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。

　もちろん、Google App Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Entity Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。

　リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデータモデルから設計する必要もあるし、プログラムも丁寧に書く必要がある。場合によっては、アプリの仕様から見直さなければならないケースもある。しかし、そういったいくつかの約束事さえきちんと守って作れば、いくらユーザーが増えようとデータベース上のEntity数が増えようとアクセス数に応じてCPUの使用時間と通信量が直線的に増えるだけの「リニアなスケーラビリティ」を持ったアプリケーションを作ることができる、ということは脅威的である。

　mixiにしろ、Twitterにしろ、リレーショナル・データベース上に作られたウェブサービスは、ユーザーが増えるにつれてデータベースの構成を変更しながらスケーラビリティを確保しなければならない、という宿命を背負っている。ユーザーの数が１００万人から１０００万人に増えた時には、単にマシンの台数を１０倍にすれば良いという話ではなく、それに応じてデータベースを新たにクラスタリングさせたり、スケーラビリティの確保のために新たなデータキャッシュの仕組みを導入したり、ということがどうしても必要になる。その結果、マシンの数が１０倍ではなく２０倍必要になったり、スケーラビリティのことだけを専任で担当するエンジニアが何人も必要になったりする。

　今回 Tiny Message を作ることによってはっきり分かったのは、App EngineのDatastoreの特性を活かしたアプリを作れば、その手のことを一切心配せずに、１００万ユーザーにでも１０００万ユーザーにでも自動的にスケールすることができるようにサービスを作ることが可能だ、ということ。それも、私のように片手間でサービスを立ち上げて、ほとんど手間もお金もかけずに運営して行くことが可能だということ。

　Tiny Messageは、まだリリースしたばかりのとても小さなアプリだが、万が一ユーザー数が大爆発したときに備えて、ユニークなURLを生成する際に必要なトランザクションによるスレッド間のコンフリクトを最小限にするように２４万個のEntity Groupを（オンデマンドで）作ってそれぞれにカウンターを持たせて個別にトランザクションさせる、という設計にしてある。Entity Groupが２４万個あれば、相当な同時接続数になったとしても二つのHTTPリクエストが同時に同じEntity Groupを使ってユニークなURLを生成しようとする可能性は限りなくゼロに近い。

　そこも含めて （というかそこが一番難しかったのだが）、Tiny Message はすべてのコードパスがユーザー数やエントリー数には関係なく固定時間で終わるように設計してあるので、トラフィックが１０倍に増えれば単にCPUの使用量が１０倍に増えるだけ、というリニアなスケーラビリティが確保できているのだ。

　そんな設計のため、わずか２０時間走らせただけで、今後トラフィックが増えて来た時にどうスケールするかが、おおよそ予測できる。現在、一番時間がかかっているのがデータベースへの書込みが必要なメッセージの投稿で、平均して400メガサイクル強のCPUを使っている。そこから予想するに、１日あたり１〜２万メッセージの投稿までは「無料Quota」の範囲でやっていける、と予想できるのだ。

　もちろん、その予想は「GoogleのDatastoreがリニアにスケールする」という前提のもとのものなので１００％確実な話ではないが、少なくとも「確実にどこかで限界が来る」ことが見えているリレーショナル・データベースの上で作るのとは大きな違いがある。

Twitterに140文字以上つぶやきたい時のためのサービス、Tiny Message

　Google App Engineでプログラムを書き始めて１週間ほど経つが、ようやくDatastoreの基本が分かってきたので、サービス運営の経験値を積むためにもアプリを一つリリースしてみることにした。

　サービス名は、Tiny Message。Tiny URLはTwitterに書くURLを短くしてくれるサービスだが、こちらはTwitterに書くメッセージそのものを短くするサービス。

　使い方はいたって簡単。Tiny Messageのホームページ（http://tinymsg.appspot.com/）でメッセージを書き、"make my tweet"というボタンを押すとTwitter投稿用の要約（最初の１００文字）＋URLが表示されるので、それをコピペしてTwitterでつぶやけば良いという仕組みである（メッセージの全文を読みたい人にはURLをクリックしてもらう）。

　こんなサービスがチャチャッとすぐにリリースできてしまうところがApp Engineのすばらしさ（このアプリに使った時間は全部で５時間ぐらい）。私みたいに「プログラムを書くことだけに集中したい」人にはたまらない魅力だ。

　まだできたてホヤホヤなので、私自身のテストで把握しきれていないバグがあるかも知れないので、テストの意味も含めてぜひともたくさんの方々にお試しいただきたいと思う。もし不具合が見つかった場合には教えていただけるととても助かる。

１２月３日にAndroidに関して講演します

　久しぶりに日本で講演をすることになったので、ここで告知させていただく。詳しくは日経エレクトロニクスのアナウンスメントを見ていただくのが良いと思うが、今回は「Android家電の衝撃」というテーマのいくつかの講演＋パネルディスカション。

　技術的に突っ込んだ話というよりは、ビジネス上の意味だとか、Googleの戦略という話になるとは思うが、UIEvolutionの創設者としてモバイル・組み込み業界でいろいろとビジネスをして来た経験や、iPhoneディベロッパーとしてiPhoneアプリを開発・販売して来た経験を通したいろいろな話ができると思う。

　それにしても、最近は色々と試したいもの・勉強したいものが多くて困る。ここ一年ばかりどっぷりと浸かって来たのがiPhone SDK、それに最近はHTML5、CSS3、Google App Engine、Pythonが加わり忙しくてしかたがない。

　まあ、この業界にいるかぎりこうやって日進月歩の技術を勉強しては、誰もいない領域に踏み出して、失敗を繰り返しながらちょっとずつそれを先に進める、ということを繰り返して行くしかないし、それが楽しくてこの業界にいるのだから文句を言う筋合いのものでもないのだが、新しい言語や開発環境をマスターするにはそれなりの時間がかかるし、そこで何か意味のあるもの・価値を生み出すものを作ろうとしたらもっと時間がかかる。

　そんな中で、無視できない存在になって来たAndroidというプラットフォーム。携帯電話向けのOSというだけでなく、さまざまなネット端末の共通プラットフォームとしてAndroidの可能性という話から、Google が Chromeの延長として位置づける Chrome OS まで、ものの価値がどんどんとクライド側に移動していくこの時代にデバイスビジネスというものがどうあるべきか、という話はとても悩ましい話である。

　先日も日本の家電メーカー向けの経営コンサルタントをしている知り合いと話していたのだが、彼に言わせると日本の大企業の一番の弱点は、経営陣（＝お抱え運転手付きの待遇を受けるレベルになった執行役員たち）がこの手の新しい技術だとかの勉強を若い人たちに任せてきりにしてしまって、そういうものを理解してこそ初めてできる経営判断のようなものがまったく出来ていない点にあるという。

　欧米の企業に主要な知的所有権をがっちりと握られ、アジアのメーカーに価格競争で追い上げられ、さらにクラウドに価値が移るにつれデバイスのコモディティ化が加速する、という今の日本の家電メーカー・デバイスメーカーの危機的状況を考えれば、まずは「お抱え運転手の全面廃止」「執行役員たちの意識革命」から始めなければならないのにも関わらず、あと３〜４年後に定年を迎える執行役員たちが問題を先送りにして、「少なくとも自分が執行役員を勤める間だけはなんとか会社が存続してくれればあとの問題は後継者に任せられる」という当事者意識の欠如、が一番の問題だと彼は言う。

　という意味では、今回の話なんかは、そんな執行役員たちに一番聞かせたい話ではあるんだが、お抱え運転手付きの執行役員が日経エレのセミナーに来るとはどうも想像しにくいんだが、どうなんだろう。

Python入門：デコレータとは

　前から常々思っていることだが、何かについて勉強する一番効率的な方法はそれを誰かに教えること。人に教えようとすると、それなりに準備をしなければならないし、自分の頭の中を整理しなければならない。また教える過程でするどい質問をされたり間違いを指摘されて、さらに勉強を強いられることもある。

　私がこの手の「入門編エントリー」を書くのは、ほとんどの場合「自分自身の理解をより深めたい」ことが一番の目的であるが、ブログの場合、教室などと違って「その道の達人」みたいな人たちがツッコミを入れてくれるケースもしばしばあるので、そのメリットは何倍にもなる。

　先日のクロージャに関するエントリーなどは良い例で、「そんな用途にはmemoizeというデコレータが便利」などの指摘がいただけだけであれを書いた価値があるというもの。

　そこで、今日はPythonのデコレータに関して。デコレータがPythonという言語に導入された経緯に関してはここに詳しい経緯が書いてあるが、ひと言で言えば、それまでのPythonでクラスメソッドを定義するには、

def foo(self):

    メソッドの本体

    ...

foo = classmethod(foo) #ここで実はクラスメソッドだと宣言

としなければならなかったのだが、これでいかにも後付けで言語として格好が悪い（手紙の冒頭に「あなたは美しい、あなたが好きだ、あなた無しでは生きて行けない」とさんざん書いておいて、最後に「これはあなた向けに書いたものではなく、単なる『詩』です」と追記するようなもの）、ということで導入されたのが以下のデコレータである（最初に『詩』だと宣言しておけば、ラブレターと誤解されることもない）。

@classmethod

def foo(cls):

    メソッドの本体

    ...

　興味深いことに、Pythonの言語を定義している人たちは、この@classmethodというデコレータを特別扱いせず、一般化してだれにでもデコレータを作れるように言語を拡張した。そのおかげで、それ以来色々なデコレータが作られ、さまざまなところで活用されている。先に出て来たmemoizeもその一つである。

　簡単な例として、「俳句を返す関数」を「短歌を返す関数」に変更してしまう haiku_to_tanka デコレータを実装してみよう。例えば、

def furuike():

    return u"古池や蛙飛びこむ水の音"

　という俳句を返す関数があった場合、それが短歌を返すようにデコレーションするには、

def haiku_to_tanka(original_func):

    def decorated_func(*args):

        return original_func(*args) + u"　それにつけても金の欲しさよ"

    return decorated_func

というデコレータを前もって定義しておき、

@haiku_to_tanka

def furuike():

    return u"古池や蛙飛びこむ水の音"

としてあげるだけでよい。先のclassmethodデコレータを同じく、これは実質的には

def furuike():

    return u"古池や蛙飛びこむ水の音"
furuike = haiku_to_tanka(furuike)

と等価である。 

　なのでその後に関数furuike()を呼ぶと、オリジナルのfuruike()ではなく、デコレータによって再定義された関数(decorated_func)が呼ばれ、それがオリジナルのfuruike()が返した俳句に下の句を追加した上で短歌として返すことになるのだ。

　haiku_to_tanka関数内部で定義されているdecirated_funcはhaiku_to_tankaに渡されたoriginal_funcを参照している点に注目して欲しい。これにより、haiku_to_tankaに渡された（つまりデコレートされた）関数（オリジナルのfuruike）が再定義される関数の中に閉じ込められる形（つまりクロージャ）になっているのだ。

　ちなみに、先日教わったばかりのmemoizeというデコレータ。すでに何通りかの実装がされているのだが（例１、例２）、どれもここで見せるサンプルとしてはいまいち分かりにくいので、クロージャを使って出来る限りシンプルに実装してみたのがこれ。

def memoize(original_func):

    cache = {}

    def decorated_func(*args):

        try:

            return cache[args]

        except KeyError:

            cache[args] = original_func(*args)

            return cache[args]

    return decorated_func

　このデコレータは、先の kaiku_to_tanka デコレータと同じく、オリジナルの関数 original_func をクロージャの形で閉じ込めた新たな関数を作り出す。同じクロージャ内には、関数へのパラーメータをキーとしたcacheというディクショナリを用意しておき、キャッシュ済みであればそれを返すし、そうでなければ（except KeyError: でキャッチしている）オリジナルの関数を呼び出した上でその値をキャッシュしてから返す。

Google App Engine入門：Datastore上で「ユニーク制限」を実現する方法

　Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。

　Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。

　もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。

　App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エンティティグループをあまり大きくしてはいけないということ。

　すべてのEmailAddressエンティティを一つのエンティティグループに入れてしまえば、トランザクションは簡単に実現できるが、それだとユーザー数が増えたときにエンティティグループが巨大になってしまい、そこがボトルネックになりかねない。

　半日ほどいろいろと調査をしたりプロトタイプを作ったりした結果私がたどりついたのが、Model.get_or_insert()を使った手法。大きなエンティティグループを作る必要がないので、スケーラビリティが良いし、とてもシンプル。実際のコードはこんな感じになる。

class EmailAddress(db.Model):

    salt = db.StringProperty(required=True)

    @classmethod

    def insert_or_fail(cls, email):

        salt = str(time.time())+str(random.random())

        email = cls.get_or_insert(key_name=email, salt=salt)

        return email.salt == salt and email or None

　アプリケーション側では、

email = EmailAddress.insert_or_fail("foo@bar.com")

のように使う。"foo@bar.com"がまだ登録されていなければ新しく作ったエンティティが返されるし（すでにput()済みのもの）、そうでなければNoneが返される。

　この仕組みがちゃんとマルチスレッド環境で動くのは、Model.get_or_insert()自身が内部でトランザクション処理をしており、すでに同じkey_nameのものがデータベース上に存在する場合はそのエンティティを返し（その場合は、与えたプロパティの初期値は無視される）、そうでない場合は指定したプロパティの初期値を持つエンティティをデータベース上にput()した上で返してくれるように作られているからだ。

　get_or_insert()を呼ぶ際に、salt=として十分にユニークな文字列を与えておけば（この場合は現在の時間と乱数）、返って来たエンティティのsaltプロパティが与えた文字列と一致しているかどうかを見れば、自分が作ったエンティティなのかすでにもともと存在したエンティティなのかが判別できる。

　一つ注意して欲しいのは、この仕組みが使えるのは key_name というプライマリーキーのみであり、他のプロパティには使えない点。そのため、一つのエンティティに二つ以上のユニークなプロパティを持たせたい場合（例えば各ユーザーのメアドとハンドルネームの両方がユニークでなければならない場合）、プライマリーキーにできないプロパティ値を key_name として持つ別の Model を作り、それを使ってユニークな値を保証した上で、メインの Model のプロパティとして使う、ということをしなければならない。

Google App Engine入門：Entity Groupとトランザクション処理

　今週に入ってから、ようやく少し本気でGoogle App Engineでプログラムを書き始めている私だが、ようやく Entity Group の使い方が分かって来たので簡単に解説してみる。

　Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。

　イメージとしては、まず「一つのハノイの塔を三人で同時に遊んでいる姿」を思い浮かべると分かりやすいかも知れない。全くのルールなしで皆で同時に遊ぼうとすると、腕が交錯してぐちゃぐちゃになってしまう。

　そこで、「ある時点でハノイの塔ボード（三つの棒を支えている水平に置かれた板）に触ることが出来る人は常に一人。一度ボードに触った人はすべての円盤をいずれかの棒の位置に置いた状態にしてからしか手を離してはいけない。もし自分がハノイの塔に触りたい時に、すでに誰かが触っている場合にはその人の後ろに列を作って順番を待たなければいけない」というルールを定めて混乱を避ける。

　App EngineのEntity Groupとはまさにそんな感じ。同じEntity Groupに属するEntityのいずれか（つまり同じハノイの塔に属する円盤のどれか）を操作する際には、db.run_in_transaction() という仕組みを使って一連の操作をAtomicに行う（つまり、ボードから手を離さずに一連の操作を行う）。一つのスレッドがトランザクションから抜ける時に（つまり、だれかがボードから手を離すときに）常にデータの整合性が取れた形になっていること（つまり、ハノイの塔のルールに従ってすべての円盤がいずれかの場所に順番に積まれている状態）を保証することにより、スレッドやマシンが何台に増えようと（プレーヤーが何人に増えようと）破綻することなくサービスを運営することが可能になるのだ。

　これだけだと一般的なリレーショナル・データベースのトランザクションと違いはないが、Google App Engineの特徴は、このEntity Groupを自由な形でいくつでも作ることができる点。そして、データベースそのものが巨大になって複数のマシンにまたがってしまっても問題なくスケールする点。それぞれのEntity Groupに対してトランザクション処理ができるため、全体のスループットを落とさずに同時期に大量のトランザクション処理を行うことが可能になるのだ。

　これを理解するには、１０００個のハノイの塔ボードの間を３０００人のプレーヤーが自由に歩き回って遊んでいる姿を想像すると良いかもしれない。一見カオス状態に見えるかもしれないが、それぞれのハノイの塔ボード上の円盤は個別のEntity Groupに属するため、先の「ある時点でハノイの塔に触ることが出来る人は常に一人。一度触った人は...」というルールはボードがいくつになろうとプレーヤーの数が何人に増えようと変わらず適用される。

　この仕組みのすぐれたところは、それぞれのハノイの塔ボードに載っている円盤の数さえ同じであれば、ボードの数がどんなに増えようとそれに応じてプレーヤーの数さえ増やして行けばスループットは落ちない（つまり、リニアにスケールする）という点である。それどころか、すべてのボードが同じ会場にある必要すらなく、東京に１０００個、ニューヨークに１０００個、ロンドンに１０００個あってもかまわない。

　Google App Engine上でEntity Groupを作るには、一つGroupのルートとなるEntityを定め、他のEntityをその子孫（子供、孫、ひ孫、...）として関連づければ良い。ハノイの塔の場合だと、ボードをルートとし、その上の三本の棒と１０枚の円盤をその子供と定めることに相当する。

　そんな親子関係を作っておくと、それらの（同じEntity Groupに属する）Entityを実際にディスク上で近いところに格納することにより高速なトランザクション処理を可能にする、というのもApp Engineのすぐれた所だ。

　なんだか言葉ばかりならべた抽象的な話になってしまったが、まずはこのあたりの「概念」からしっかりと把握した上でGoogle App Engine上のアプリを作ることをおすすめする。結局のところ、スケーラブルなウェブサービスが作れるかどうかは、Datastore上のデータ構造をどう設計するかにかかっているのだから。

Python Hack : 噛めば噛むほどおいしくなるクロージャの話

　最近 JavaScript を書く機会が増えているが、それに従って自分のコーディングスタイルが少しづつだが変化してきているのが分かる。もともと「コードの読みやすさ」や「実行効率」にとことんこだわるタイプだが、（JavaやC++になくて）JavaScriptやRubyにあるクロージャや無名関数が私のコーディングスタイルにとてもマッチしているからだと思う。

　簡単な例を紹介しよう。Pythonで書かれた config.py というモジュール。config.yamlという設定ファイルを読み込んで Dictionary として返す config.get() という関数。普通に実装すると、以下のような感じになる。

import yaml

_config = None
def get():
    global _config
    if not _config:
        data = open('config.yaml').read().decode('utf8')
        _config = yaml.load(data)
    return _config

　config.yaml という設定ファイルがプログラムの実行中には変化しない点を利用して、一度読み込んだデータをグローバル変数 _config にキャッシュしておき、次からはそれを返す、というものだ。

　よくあるコーディングスタイルだが、私はどうも好きになれない。まずは、_configというグローバル関数が気にいらない。モジュールの外からアクセスできないとは言え（Pythonの場合、"_"で始まる変数や関数はプライベート扱いになる）、このモジュール内の他のプログラムからは見えており、後々モジュールが大きくなって複数のプログラマーが関わって来た時に「同じモジュール内だし、get()関数を呼ぶより_configに直接アクセスした方が早いじゃん」という誘惑に負けてしまう人がいないとは限らない。

　もう一つは、「if not _config:」という条件分岐を毎回毎回実行しなければならないこと。一つ一つは小さな話でも、何百回も何千回も呼ぶ必要がある場合、このオーバーヘッドも馬鹿にならない（人間だったらすぐに気がついてチェックを辞めるが、プログラムの場合は素直に何度でもチェックしてしまうから）。

　クロージャと無名関数を使うと、こんな風に実装することができる。

import yaml

def _get_from_disk():
     data = open('config.yaml').read().decode('utf8')
     config = yaml.load(data)　＃ クロージャ内に隠蔽・保持されるローカル変数
     global get
     get = lambda : config   # 二回目からはconfigを返す無名関数を呼ぶ様に変更
     return get()

get = _get_from_disk   # 初回のみローダーを実行

　わずかな違いだが、私にはこのスタイルの方がずっとすっきりくる。キャッシュした値を覚えている config はローカル変数なのでモジュール外だけでなくモジュール内の他の部分からも完璧に隠蔽されているし、二回目からは "lambda: config" (JavaScriptだと "function() { return config; }" という無名関数に相当)を実行するだけなので効率が良い。

　小さな話と言えば小さな話だが、こんな風に「メンテナンスのしやすさ」や「実行効率」にこだわりつつ作ったプログラムとそうでなプログラムでは、出来上がった時に大きな違いが出る。

　唯一の難点は、「クロージャがなんであるか」が直感的に理解しにくいために、初心者にとっては、決して「読みやすいプログラム」にはなっていないこと（C++やJavaにしか触れていない人たちには上のサンプルは理解しがたい）。あまりクロージャを駆使すると、一部の人しか理解できない黒魔術になってしまうので、そこは気をつけなければいけない。

ブラウザー上で動く iPhone-style トグルスイッチ

　ここのところ「iPhoneアプリのUIの大半（ひょっとしたらアプリすべて）をHTML+JavaScript+CSSで作ることはできないか？」に挑戦している私。

　そのためにまずは部品作りからとりかかっているのだが、昨日から今日にかけて作ったのは、プログレス・バー、スライダー、トグルスイッチなどの「連続値・不連続値」を表示・入力用UIコントロールをウェブページ上で実現するためのJavaScriptライブラリ。

　見た目（Look&Feel）はCSSを使って自由に指定できるように作りつつ、シンプルでありながらいろいろな場面で使い回しがきくライブラリを作りたかったので、何度もリファクタリングを繰り返してしまったが、なんとか形になってきた。

　ということで、そのライブラリ（jTouchControl version 0.10）を使ったiPhone風トグルスイッチを公開。一応、Safari (4.0), mobile Safari, Firefox(3.5), Chrome(4.0), Opera(9.0), IE (8.0)での動作確認済み。ただし、微妙なグラディエーションやアニメーションは、webkit-base のブラウザーでしか見えない。

　iPhone向けのアプリの開発に作ったのだからmobile Safariでさえ動けば十分だったのだが、「せっかく公開するのだから、せめてIE8で動く様にしよう」と欲を出したのが苦労の始まり。半日つぶれてしまった。

　ソースコードは http://widgetpad.com/954/ からアクセス可能。アプリ側のJavaScriptは基本的に以下の２行。最初の行がそれぞれのトグルスイッチを初期化し、次でその二つを連携させている（下のスイッチを変更すると上のスイッチが変更される）。

1.      $('.switch').jTControl("slider", { padding:20, steps:1 });
        $('#switch2').bind("valuechanged", function() { $('#switch1')[0].setValue(this.getValue(), 0.2, true); });
   
2. 　JTControlに渡す最初のパラメターは、コントロールの種類。現時点では、"slider"と"progressBar"のみをサポートしている。二番目のパラメターはオプションで、スライド範囲をwidthよりせばめるための"padding", 非連続値の場合の段階を指定する "steps" (１でトグルスイッチになる、デフォールトは非連続）、ドラッグするものを指定する "thumb" (省略すると空のDIVが挿入される）などを指定することができる。

Cloud Computing考：Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた

　Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。

　すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいのトラフィックが来るのかを予測するのが不可能な場合（一般ユーザー向けのネットサービスのほとんどがそう）、「需要を予測した上で、それに見合うだけの初期投資が必要」なモデルはどう考えてもありえなかった。

　そんな理由で Amazon のウェブサービスを選択したわけだが、結果から見れば正しい判断だったと言える。特にサービス開始時のトラフィックが予想しにくい時期に、モバイルビジネスに良くある「はやって地獄（予想以上にユーザーが集まったためにサーバーが足らなくて四苦八苦すること）、はやらないで地獄（多大なトラフィックを想定してそれなりの初期投資をしたにもかかわらず、実際にはトラフィックが予想を遥かに下回り、初期投資の回収がままならなくなること）」というジレンマに陥らずに済んだことは大きい。

　しかし、実際に１年以上PhotoShareを運営して来て、Amazon のウェブサービスに足らない部分もいくつか見えては来ているので、ここに書いてみる。

　まず一つ目は、ec2はバーチャル・サーバーと呼ばれてはいるが、私が期待していたレベルのバーチャル・サーバーではないこと。Amazonはバーチャル・サーバーの仕組みを、「一つのパワフルなサーバーを複数のバーチャル・サーバーとして小分けしてレンタルする」ことに使ってはいるものの、「サーバーを完全にバーチャルにしてハードウェアと切り離し、ハードウェアに問題があってもサービスには一切支障をきたさない」というレベルまでは使っていない。バーチャル・サーバーと呼ぶのであれば、「ハードの問題」とか「特定のCPUから別のCPUへの引っ越し」とかを見えなくしてほしい。

　二つ目はAmazonの問題ではないのだが、ec2を使っても「データベースのお守り」は自分でしなければならないこと。PhotoShareはMySQLを使っているので、Oracleほどのチューニングは必要ないとは言え、バックアップとか修復とか、それなりの手間はかかる。そして当然だが、データベースのスケーラビリティの問題を解決するのもサーバーの借り手の責任である。一つのデータベースで足りているうちは良いが、ユーザーが増えて複数のデータベースに分けなければならない段階になると、パーティショニングやリプリケーションやらといろいろと複雑な問題を解決しなければならない。

　つまり簡単にまとめると、Amazon のウェブサービス（ec2）は、自分のサーバーを持つことや通常のレンタルサーバーを借りることと比べると、（１）初期投資が少なくかつ安い、（２）トラフィックの量が急激に変動したときに柔軟に対応できる、という利点があるが、（３）ハードの故障からは完全にはプロテクトされない、（４）データベースのスケーラビリティの問題は自分で解決しなければならない、という点は十分認識しておく必要がある。

　そんなことを頭に置いた上で、先週少し Google の App Engine について調べてみた。私がもっとも気に入ったのは、Amazonが解決してくれなかった、（３）ハードの故障問題から解放、と（４）データベースのスケーラビリティ問題からの解放、という部分。

　クラウドコンピューティングを「サーバー運営のアウトソース」という意味で見た時に、Amazon と Google では、セルフサービスの学食とフルサービスのレストランの違いぐらいがある。「ハードウェアの故障にどう対応しよう」「ユーザーが増えた時にデータベースをどう分けよう」などのことは心配せずに、サービス作り・ソフトウェア作りに１００％集中したいのであれば、Google App Engineの方が格段の「おもてなし」である。

　とは言え、Google App Engineにまったくマイナス面がないわけではない。自分でOSのインストールまでできるAmazonと比べると以下のような制限がある：

1. Goolgle App Engine上のアプリケーションはサンドボックスの中で走る。OSのインストールはもちろんだめだが、それだけでなく、さまざまなリソースへのアクセスはかなり制限される（例：「ファイル」を作ることができない、デーモン・プロセスを起動したり、TCP/IPソケットを開きっぱなしにすることもできない）。基本的に、「入って来たHTTPリクエストを高速にステートレスに処理する」ことしか出来ないと思って間違いない。

2. データベースはGoogleのDatastore（Big Table）を使わなければならない。MySQLやOracleのようなリレーショナル・データベースとは違い、スキーマレスのオブジェクト・データベースなので、リレーショナル・データベースに関するノウハウはほとんど使えない。作ったアプリケーションを他の環境（例えばAmazon ec2）に大きな変更を加えずに持って行くことは不可能。

3. 公式にサポートされている言語は、PythonとJava（Javaの上でRubyやPHPなどの他の言語を動かすことは可能）。

　以上が、私から見たAmazon・Google二社のクラウドコンピューティング・サービスの違いである。App Engineに関しては、実際に商用サービスを運用した経験があるわけでもないので、どこかに見えない落とし穴があるかも知れないが、私から見れば「商用サービスを試してみる価値のある」レベルには十分に達していると思う。ちょうど一つ（ひょっとすると二つ）、新しいサービスで良い候補があるので、試してみようと考えている。

　ちなみに、私はPythonは初めてだったが、とても簡単な言語なのでそれほど悩まずに１日ぐらいでそれなりに書けるようになったので、皆さんにもおすすめする（特にJavaScript使いにはおすすめ）。Datastoreも初めはとっつきにくいかも知れないが、一度その中身がどうなっているかを理解すれば（つまり、慣れ親しんだリレーショナルデータベースとの違いをはっきりと認識できれば）それほど難しいものではない。

「RESTful MVC」なアーキテクチャの話

　最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。

　もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。

　そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）。

　クライアント側でJavaScriptが実行できないようなブラウザーに対しては、サーバー側にControllerをおいてView TemplateとModelの結合を行って生成したHTMLを返す。JavaScriptが実行できるブラウザーに対しては、あえてサーバー側にはControllerをおかず（もしくは最小限のものにとどめ）、JavaScriptで記述されたControllerをブラウザーに送り込み、HTMLで記述されたView TemplateとJSONの形で送られて来たデータとの結合はクライアント側で行う（先日のjQBinder参照）。

　こんな風に作る一番の利点は、Modelへのインターフェイス作りをさぼることが絶対にできなくなること。ブラウザーのタイプによって二つの異なるView/Controllerペアとやりとりをしなければならないのでインターフェイスの明確な定義は必須だし、Statelessで非同期なインターフェイスなので、データの整合性を守るための複数のテーブルにまたがったトランザクションは絶対にModel側でしなければならないことはプロジェクトに関わる全員に自明となる。

　また、Modelはデータベースやサーバー側のハードコアなプログラミングに慣れたエンジニアが担当し、View/Controllerは見た目やユーザーインターフェイスにこだわるエンジニアが担当する、など作業分担もしやすくなる。

　それに加えて、Modelのインターフェイスが特定の言語に依存しないため、ModelはJavaで（サーバー側の）ControllerはPHPでとか、各モジュールのモックアップをRailsでアジャイルに作ってから本来の言語で本実装をする、などのテクニックが使えるのも利点だ。

　もちろん、これもデザイン・パターンの一つでしかないので、どんな場合にも適用できる話ではないが、少なくとも私が関わっているプロジェクトのほとんどすべてにこのアーキテクチャが適用できそうだな、と思っている今日この頃である。