で、Djangoにヒントを得たフレームワークで・・・と聞くと今度はバッタモンのように思えてしまうかもしれないが、なかなかどうして優れものな感じ。Rack/Bundle/Tilt対応、といったあたりでピンとくるひとまだ少ないかもしれないが、これ、rails 3.0キラーとなりうる実力を持っているのかも(すまない、しばし解説略)。

気になった方はRango rubyあたりでググッてくだされ。(かなり)個人的には、web.goと同様にmustacheを使えるのが気に入った。

mustacheテンプレートを例に、Tiltだけご紹介(といってもTiltのテストコードをカンニングしたもの):
gem install tilt mustacheして、irbにて、以下を叩こう。
※スマンソ　コード整形のプラグインが壊れてる模様なので、ただ文字列を羅列

require 'tilt'

require 'mustache'

template = Tilt::MustacheTemplate.new { |t| "Hello World!" }
template.render

template = Tilt::MustacheTemplate.new { "<p>Hey {{name}}!</p>" }
template.render(nil, :name => 'Joe')

#このyieldはちょっとかっこいい

template = Tilt::MustacheTemplate.new { "<p>Hey {{yield}}!</p>" }
template.render { 'Joe' }

#ビューのロジックと見た目の分離・・とのこと

  module Views
      class Foo < Mustache
           attr_reader :foo
      end
  end

template = Tilt::MustacheTemplate.new('foo.mustache') { "<div>Hey {{foo}}!</div>" }
scope = Object.new
scope.instance_variable_set(:@foo, 'Jane!')
template.render(scope)

実行結果は、地味に一瞬で得られるので、自らお試しを～

http://github.com/ArtemTitoulenko/GoForth/

マイノリティ言語好きのくせにForthはノーチェックだったのでちょっとググってみる。
日本語をForthにコンパイルする日本語プログラミング言語Mindという先達が今も気を吐いているのに驚いた(Mindで書かれた商用の全文検索がばりばり現役)
・・・ので、せっかくだから「擬似日本語=>Forth =>Goコード」というものをやってみようかと。

日本語は簡単な文字列の置換でそこそこforthコードを吐き出せるらしい。試しに書いてみた

—-(日本語コード)—#ループカウンタ「i」は事前定義とのこと

変数sum
0をsumに代入
50以下について、
      「sumを参照し、iと足して、sumに代入する。」
というループ。

—-(自動変換後のForthコード)—

$ cd $GOROOT/src

$ hg pull

$ hg update release

$ make all

少なくとも、特定のクラウドに依存しすぎちゃうと危険かもよというハナシには説得力がある。

てなわけで、クラウド勉などといいつつも、年末年始に主にいじくっていたのは、快適になりすぎてる感のあるNginx(webサーバ)とRedis-db(KVS)。こいつらがいると只のクラウドじゃ勝ち目がないんでは。。
ということで、クラウドのお勉強も、Windows AzureでもGAEでも、もちろんVPSでも動作するwebフレームワークにしたい。。。

即答で、それってDjangoでいいんじゃね、とのささやきが。Djangoくらいになると、たいていの情報に事欠かないものねぇ。(RailsだとGAEあたりで逆に苦労しそうと・・・偏見かもしれないが思っている)。

NginxもRedis-dbも実績あるみたいだし、GAEならKayでいけばいいし、Windows AzureならNWSGI経由で何とかなるかもしらんなど、クラウド対応もばっちり。
・・・すまん、長門Compojure、涙目でこっちを見ないでくれ。
後は、フロントエンドをHTML5対応のSproutCoreにすれば、本気クラウド勉の体をなす。
そのうえで、管理系やらなにやらをSproutCOreからSilverlight+ PureMVCあたりにおきかえてみたり・・・と妄想してみる今日この頃。

まぁ、Nginx+Redis-db+SproutCoreあたりで、Django on VPS、まずは来月くらいに動作させませう。
で、クラウドにする時に何をどう置き換えるのかといったあたりから、クラウド勉。
・・・とはいえ、平行してAzureでもいじくっておくかと思ったが、VS2010β2&マニュアルのダウンロード時間があまりに長すぎて、やる気が失せた。
・・・なので、そういやNginx+Redis-db+SproutCore、こいつら、golangとの組み合わせで、一通り動いているなぁ、と思いつつ惰眠する。

　　なんだかんだいって、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;
}

で、生成された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のシリアライズ・デシリアライズできた、と。

http://github.com/hoisie/web.go

ビルドには、最新版のgolangが必要。特徴は、バイナリにコンパイルして実行するから高速とのこと。クリスマスイブの夜に、VPSでいきなり80番開放してテストしてみる。
今晩はハローワールドのみ。

package main

import (
    "fmt"
    "web"
)

func hello(val string) string {
 return fmt.Sprintf("こんにちは、世界 %s", val)
}

func main() {
    web.Get("/(.*)", hello)
    web.Run("0.0.0.0:80")
}

キモは、「web.Get(“/(.*)”, hello)」のところで、関数helloにurlの/以下のユーザーが入力した値が渡される。

• Golang開発チームからのクリスマスプレゼントで、プログラム中にセミコロンを書かかなくとも良くなった(ほとんどの場合)。省略ルールの詳細は押さえていないが、「スクリプト風言語」にいよいよGolangも仲間入りした気がするなぁ。

実行結果は以下の通り :
[入力]

http://MyDomain.jp/。メリークリスマス!!

[出力]
こんにちは、世界 。メリークリスマス!!

とりあえず、web.go、UTF-8でソースを書けば、日本語込みで動作するよ、との報告まで。
Sinatra風か・・・どうかはこれから検証予定(POSTも動作している模様)
・・・おそらく、web.go これからもけっこう変化するんだろうけれど、これからに期待ということで。

Windowsユーザーの場合、いまのとこ、ちょっと古めのPython2.5系を強制するGAEと組み合わせるなら、ちょっと古めのPyScripterがいいのではと思っていたり。2006年で開発止まっているのが若干不安だが、インデントさくさく補完は快感。Pythonのコードは・・・自分がさらすまでもなくWebに良いコードが一杯転がってるね。いや、かなりメジャーだぜPython(世界的には)。

Python3.xにGAEが対応するとかがあったら、その時にIDEはまた考えよう。

自分としては、2010年末のクラウドは、少なくともオードリー春日よりも売れているのではと思っているので、そろそろクラウド・アプリの構築を開始しようかと。

• オードリーは嫌いでないというかむしろ好きだし、レイザーラモンHG同様、長く応援したいのだが・・・2011年頃には、「消失」映画化後に角川がブレークさせようとするであろう「佐々木」よりマイナーキャラとなっているのではと思う今日この頃。佐々木祭りは2010年のイブに期待。

ということで、調べたもの :

◆Google App Engine(GAE)
・for Python　　　・・(1)
・for JavaVM　　　・・(2)
◆Windows Azure　　　・・(3)

ずばり、今の自分なら(1)のPythonを使う。(2)でScalaやClojureも魅力なのだが、自前でフレームワークを作る暇がなさげなので、ちょっと断念(Scalaは従来型で使い続ける)。
以下、Google App Engine for Pythonを選んだ理由を少しだけ。
まずは、永遠のパソコン少年中島氏のさすがのエントリ『Google App Engine入門：実行効率を犠牲にせずに開発効率だけを上げるテクニック』がある。Google謹製の簡易フレームワークに必要なものだけを付け加えるというセンスがlazyで素敵。・・・といって結局Djangoなんかを使うのかもだけれど。
加えて、クラウドで業務アプリに近いものを開発しようと思った場合、リッチクライアントとの組み合わせが不可欠となるのだが、この1～2年くらいでは、自分的に最高のリッチクライアント開発環境は、Boo on Silverlightであることが判明していることが大きい。

• 前もどっかで書いたけど、Booは、.NET(CLR)上のPython激似のコンパイル言語。でもって、NAntなんかと組み合わせて、さくっとSilverlight開発ができる。・・・あんま勉強していないが、コンパイル言語だけあって、Booはけっこう速い(Scala並みというか、少なくともC#並み？)のでは、とも思っている。・・・勝手に最強実用言語かもしらんと思っていたり。

『Python やっちゃうけどイイよね？』とかを参考に、PythonとBooを同時に入門しちゃえば効率いいでしょ的なノリ。GAEでPythonした後、2010年の下期くらいには、AzureでBooできるならばなお良し、と。

=============

[追記] 　あ、本エントリは、クラウドの「本気のお勉強」にGAE for Pythonを使うといっているだけ。本気でアプリ実装するときが来た時には、その場で一番いけてるフレームワークを採用する予定・・・ひょっとして、GAE for Golang ???

ということで、自分の場合をメモ書き (叩いたコマンドのみ):

・・・し、しまったとx64のOSに386の環境を作ってしまった。。この場合でも、当然コンパイル&リンクまではできるのね。
どうする？

(補充)
.bash_profileあたりに
export GOROOT=$HOME/go
export GOOS=linux
export GOARCH=amd64
export PATH=$PATH:$HOME/bin
と記して、
./all.bashし直すだけで無事x64環境が構築できた。
[go@gouser gosrc]$ 6g hello.go
[go@gouser gosrc]$ 6l hello2.6
[go@gouser gosrc]$ ./6.out

8gもできるから、クロスコンパイル環境になったということかな。

自分の場合 :

こちらの方とほぼ同一で、

OSのディストリビューション
[root@ user]# cat /etc/redhat-release
CentOS release 5.3 (Final)

OSは何ビットか

[root@user]# uname -a
Linux 2.6.18-028stab059.6 #1 SMP Fri Nov 14 14:01:22 MSK 2008 x86_64 x86_64 x86_64 GNU/Linux

RPMの置き場

http://ftp.riken.jp/Linux/centos/

はじめに、yumのRPMを入手[root@user]#cd /usr/local/src
[root@user]#mkdir yumrpm
[root@user]#cd yumrpm
[root@yumrpm]# wget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/yum-3.2.19-18.el5.centos.noarch.rpm

んで、rp、m -ihv *にて足りないと言われたもの　をwgetしていく。自分の場合 :

wget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/python-elementtree-1.2.6-5.x86_64.rpmwget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/python-iniparse-0.2.3-4.el5.noarch.rpmwget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/python-sqlite-1.1.7-1.2.1.x86_64.rpmwget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/python-urlgrabber-3.1.0-5.el5.noarch.rpmwget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/yum-fastestmirror-1.1.16-13.el5.centos.noarch.rpmwget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/m2crypto-0.16-6.el5.3.x86_64.rpmwget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/yum-metadata-parser-1.1.2-2.el5.x86_64.rpm

入手し終えたところで :

[root@yumrpm]# rpm -ihv *

yum 入れた後、どんなことがあってもやってはいけないこと・・・

全てのアップデート
#yum update

MySQLなんかが壊れたりと、えらいめにあうとのこと。