クラウドの実サービスは、2010年末くらいでいいだろうとタカをくくって、2009年末からクラウドのお勉強を開始した本シリーズ。
=======================
[追記]
本エントリとあんま関係ないが、ホットエントリな、こちらの 「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」&「ウェブ業界の15年、これからの10年」のエントリにほぼ全面賛同。
『 中規模(おおよそ、1000万PV/月程度？)までは１台でがんばる覚悟を決める。ある程度以上の規模になると思ったら、コンパイル言語を使ってアプリを書く&必要に応じ十分なスペックのマルチコアマシンを速攻買える予算を用意しておく。』が、2010年代のCOST-EFFECTIVEな考え方なのでは、と。で、それ以上になる or 負荷の変動がかなり大きいと見込まれる場合には、クラウドというソリューションを採用することになるかと。(おそらく、大多数のweb案件ではクラウド対応が必須となることは当面ない。なので、コスト面にあまり差がなければ、当座、普通のサーバかクラウドかは気分で選んでいいくらい、かと)。
なんだかんだいって、cpuのマルチコア化やバス周りの高速化はまだまだ進むわけで、、2015年くらいになると、中途半端な複数台構成技術は、「滅多に必要とならない」のかなと思う。。その頃になると、Map-ReduceやNOSQLを使いこなす技術もそこそこ枯れてきて、「自分好みのクラウドを、大きく外さず使うテクニック」が、大多数のWeb屋にとって普通のスキルとなるんだろうな。
・・・もちろん、クラウドなんて自前でもっといいの作るぜ、とか「普通な奴らをぶっ飛ばせ」とかいう勢いのあるWeb屋がいちばんかっこいいんだけど。
=======================
2010年末に「まぁ、あり」だと思われるサービスの提供形態のひとつが、
サーバ側Google App Engine で、クライアントがsilverlightというRIA型クラウドアプリ。
(Windows Azureの話はそのうちに。)
これを、Google App Engine for Python + silverlight on Booで組むと、だいたいスクリプトっぽいし、実行速度もそこそこでいけるのではと狸の皮算用中。
ついでに、両者の通信プロトコルは、Google protocol Bufferにしておけば、他の言語への取替えもきいていい感じかなと
＊あと、もちろん、SOAPなんかを使う場合と比べて、実用上十分に早いぞ、と。
ということで、今回ははじめてまともに触るBooでSilverlight&Protocol Bufferしてみた。
大きくはまることはなかったが、寄り道・脱線しまくりで半日かかってしまった。。
[1] BooとPythonの違い
Python激似と、たまに話題となる.Net上のコンパイル言語Boo。とりあえず、Booのチュートリアルなんかをヒントにbooiでいろいろ試してみる。
# Booのスライス 日本語の扱いを除くとPythonと完全互換
str =”こんにちは。Hello, World”
print str[0:6]
print str[6:11]
print str[:-5]
# BooのmutableかつAnyなリスト AddはC#風
lst = [1, 'two', 3.0, "four"]
lst.Add(5)
lst.Add(“six”)
for c in lst:
print c
わかったこと :
Pythonと命令や関数なんかはかなり似ている。
が、Booは静的型付けな言語なので、関数の引数やジェネリックへの対応は必要である他、メソッドがC#風(例、appendでなくAdd)。
Python使いな人はここでBooにいらつくんだろうか(個人的にも、pythonと同様のメソッド名も採用してほしい・・・)。
とはいえ、C#より圧倒的にスクリプト風味なBoo。もしかするとPython以外のスクリプト言語ユーザーにおすすめかもしれない。
[2] Boo+NAntでSilverlight
日本語プログで唯一、Booをきちんと書いているのではと思われるこちらの方のエントリで、速攻動いた。
NAntも勉強させてもらったので、感謝。ただ、NAmtは今では、完全にMSBuildにくわれてしまったのかなぁ。。
[3] Boo+protobuf-netでProtocol Buffer
Google謹製のProtocol BufferにC#界隈の人々がけっこう熱心に取り組んでいるのは前からしっていた。ので、C#がわかれば、あとは、protobuf-netあたりを使えば、そっこうBooでもProtocol Bufferできるだろうと思ったのだが、、、Boo言語入門をまともにしていないので、ちまちまはまった・・・が、なんとかなった。。。
はじめに、protobuf-netについてくるprotogen.exeをつかって、以下の.protoファイルからC#ソースを生成
package tutorial;
message Person [...]
Boo, Protocol Buffer
Hide
「Gmailを作っているJavaScriptライブラリを公開」(後藤氏のちょっと扇情的な解説記事)。
なるほど、こう言われると、Google謹製JavaScript開発ライブラリ「closure」、気になるわな。でも、ほんとに 「Gmailを作っているJavaScriptライブラリを公開」なのか？
ということで、google codeからソースコードををダウンロード・・・jsライブラリなのに126MBもある。
中身 をチェックする前に、これだけ大物だと・・ライブラリAPI文書を読んだ方がよさそうだ。
個人的には、
proto.Serializer Extends goog.json.Serializer
が，かなり気になる。そう、jsonのしりあらいざーを拡張して、JavaScriptでGoolge Protocol Bufferを使えるようにしてくれている、と。
ソースを斜め読みするかぎり、
まず、goog.json.Serializer側でJsのobjectをArrayに直して、
次にArrayからProtocolBuffer向けの文字列を生成するっぽい。
ProtocolBuffer向けの文字列を生成のところは３０行もない。Protocol Bufferの仕組みを理解して復習しなきゃだけれど、これだけシンプルな作りなら使いどころがあるかもしれない。
closure, Protocol Buffer
Hide
