アーカイブ
このサイトは?
本サイトでは、チームの技術調査の成果を(いささかの遊びごころを盛り込みつつ)順次掲載していきます。 現在、WordPress等のブログ/CMSと連携する、新世代の分散webサイト(Java/.NETを含む)の構築に関する調査及び、次世代のプログラミング教育環境に関する調査を展開中です。
東北楽天ゴールデンイーグルスファン在籍。
お問い合わせ先
supportあっとwordprogress.org (担当・赤坂)
ランダムリンク集
RandomLinks@bit.ly
以下、実験中 :
クラウドの実サービスは、2010年末くらいでいいだろうとタカをくくって、2009年末からクラウドのお勉強を開始した本シリーズ。
=======================
[追記]
本エントリとあんま関係ないが、ホットエントリな、こちらの 「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」&「ウェブ業界の15年、これからの10年」のエントリにほぼ全面賛同。
『 中規模(おおよそ、1000万PV/月程度?)までは1台でがんばる覚悟を決める。ある程度以上の規模になると思ったら、コンパイル言語を使ってアプリを書く&必要に応じ十分なスペックのマルチコアマシンを速攻買える予算を用意しておく。』が、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 {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
repeated PhoneNumber phone = 4;
}
message AddressBook {
repeated Person person = 1;
}
ん~、protobuf-net、ぜんぜん、ドキュメントが整備されてないなぁ。とりあえず、protogen –helpしてコマンドの打ち方をクリア。
で、生成されたcsファイルからdllを生成。お試し用の以下のような.projファイルを作って、msbuildする。
<!-- ======== MsBuild .projファイル(文字コードはutf-8) ========= --> <Project DefaultTargets="build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <!-- =========== プロパティ ========== --> <PropertyGroup> <ProjectName>MyProtoBuf</ProjectName> </PropertyGroup> <!-- ======= アイテムグループ ======== --> <ItemGroup> <CSFile Include="**\*.cs"/> <Reference Include="*.dll"/> </ItemGroup> <!-- =========== ターゲット ========== --> <Target Name="build" > <CSC Sources="@(CSFile)" References="@(Reference)" OutputAssembly="$(ProjectName).dll" TargetType="library" /> </Target>< /Project>
.\protobufsrc\test>msbuild msbuild.proj
Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework, Version 2.0.50727.4200]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
2009/12/27 18:24:15 にビルドを開始しました。
ビルドに成功しました。
0 警告
0 エラー
よし,MyProtoBuf.dllがでけた。ということで、いよいよBooでいじくってみる。まずは、REPLなbooishで
.\protobufsrc\test>booish -resource MyProtoBuf.dll protobuf-net.dll
Welcome to booish, an interactive interpreter for the boo programming language.
Running boo 0.9.2.3383 on CLR 2.0.50727.4200.
Enter boo code in the prompt below (or type /help).
Adding reference to ‘MyProtoBuf.dll’
Adding reference to ‘protobuf-net.dll’
・・・あれ、これ、・・・といろいろ悩むがもはやドキュメントはあてにせず、protobuf-netのソースをたどりつつ、以下の感じで、まずはProtocol Bufferベースのシリアライズ・デシリアライズができた。
import tutorial
import System.IO
person = Person()
person.id = 1234
person.name = "My name is Hige."
person.email = "hige@example.com"
#バイナリで書き出し
file = File.Create("person.bin")
ProtoBuf.Serializer.Serialize(file, person)
file.Close()
#バイナリからオブジェクトを復元
f2 = File.OpenRead("person.bin")
newPerson = ProtoBuf.Serializer.Deserialize[of Person](f2)
print newPerson.name
その後は、これとほぼ同様に、
- インタプリタ環境で実行
#booi -r:ProtoBuf.dll -r:protobuf-net.dll person.boo - コンパイルして実行
#booc -r:ProtoBuf.dll -r:protobuf-net.dll -r:Boo.Lang.dll person.boo
おおっはじめて、booでexeを作った。
ということで、
「[4] いよいよsilverlightでProtocolBuffer」、クラウドとsilverlightでバイナリ通信するぜ・・・といくところなのだが、まともなアプリにするには一晩かかりそうな気がするので、このあたりで、いったん休憩。
今回の成果 :
C#とBooの関係は、予想通り、JavaとScalaの関係に近い。≒まぁ、なんとかなる。
問題は、C#やBooを扱っているブロガーな人々がだいぶ少ないこと。
ん~、自分が人柱になれってことかぁ。まぁ、2010年の楽しみができたと。
=====================
[おまけ]
気力がつきた時のあいまにやった。PythonでProtocol Bufferについて。実行ログだけ。ほとんど、こちらの方のいいなりでできた。多謝。
まぁ、Boo版と比較してみると、Python v.s. Booぽくなってちょっといいかも。
$ cd protobuf-2.2.0a
$ ./configure –prefix=/opt/google
$ make
$ sudo make install
$ cd python
$ export PATH=/opt/google/bin:$PATH
$ sudo python setup.py install
$ protoc -I=. –python_out=. addressbook.proto
$sudo easy_install ipython
以下、ipythonでしばしばホゲる。
$ipython -cl
import addressbook_pb
person = addressbook_pb.Person()
person.id = 1234
person.name = "My name is Hige."
person.email = "hige@example.com"
phone = person.phone.add()
phone.number = "555-4321"
phone.type = addressbook_pb.Person.HOME
#書き込み
f= open('adr.pb','w')
f.write(person.SerializeToString())
f.close() #()はpythonでは省略不可
#読み出し
str = open('adr.pb').read()
tmp = addressbook_pb.Person()
tmp.ParseFromString(str)
当然ながら、PythonでもProtocolBufferのシリアライズ・デシリアライズできた、と。
1件のコメント for 「本気クラウド勉」その2 BooなsilverlightでprotocolBufferをホゲるまで
Windows AzureでもGAEでも、もちろんVPSでも動作する・・ @ 「本気クラウド勉」その3 - Go towards a Word-Progress | 2010年1月13日 at 12:09 AM


[...] 年末に、Booをいじくってたころ時のエントリから思っていたことなのだが、少なくともこれから数年はけっこういけてるサービスをVPSで提供してるぜぇという話には事欠かないと思う。江島氏の「スケールアウトからスケールアップへの回帰」を読んで、けっこうな数の人がこのことを再確認したと思う。 [...]