Rango。このブログに書くと、一見、名前的にGoのフレームワークのように思ってしまうかもしれないが、ruby 1.9の新フレームワーク。
で、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 = [...]

Ruby Hide

Go上で実装された最初の言語はどうやらForthっぽい。
http://github.com/ArtemTitoulenko/GoForth/
マイノリティ言語好きのくせにForthはノーチェックだったのでちょっとググってみる。
日本語をForthにコンパイルする日本語プログラミング言語Mindという先達が今も気を吐いているのに驚いた(Mindで書かれた商用の全文検索がばりばり現役)
・・・ので、せっかくだから「擬似日本語=>Forth =>Goコード」というものをやってみようかと。
日本語は簡単な文字列の置換でそこそこforthコードを吐き出せるらしい。試しに書いてみた
—-(日本語コード)—#ループカウンタ「i」は事前定義とのこと
変数sum
0をsumに代入
50以下について、
      「sumを参照し、iと足して、sumに代入する。」
というループ。
—-(自動変換後のForthコード)—

variable sum
0 sum !
50 0 do     
  sum @  i +   sum !    
   loop 
———————————————-
 
単発ネタのつもりだったが、日本語で並列処理を書けたら面白いかもしれないので、
もう少し追いかけてみようかな。
アセンプラとの親和性が売りらしいForth、果たして、Goとどう組み合わせるべきか。
 

Forth, Go Hide

・・・なんと、Golangのアップデートについて書いた投稿を更新時に、WordPressのアップデートの影響によってか消えてしまった。。。 まぁ、golangの公式アップデートは半月に一回ぐらいで、以下のようやるんだけれどけっこう時間がかかるねぇというお話だった。
$ cd $GOROOT/src
$ hg pull
$ hg update release
$ make all
 
で、問題はWindowsでGolang MLでもちょこちょこ議論されているところなんだけど、書いたことが消えちゃったし、問題は解決できるわけでもないので、取り急ぎ。ここまで(汗)。。。

Go Hide

年末に、Booをいじくってたころ時のエントリから思っていたことなのだが、少なくともこれから数年はけっこういけてるサービスをVPSで提供してるぜぇという話には事欠かないと思う。江島氏の「スケールアウトからスケールアップへの回帰」を読んで、けっこうな数の人がこのことを再確認したと思う。
少なくとも、特定のクラウドに依存しすぎちゃうと危険かもよというハナシには説得力がある。
てなわけで、クラウド勉などといいつつも、年末年始に主にいじくっていたのは、快適になりすぎてる感のある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との組み合わせで、一通り動いているなぁ、と思いつつ惰眠する。

Django, SproutCore Hide

クラウドの実サービスは、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

12月に入ってから、開発が続けられているGolangのSinatra風フレームワーク(?)web.go。
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 これからもけっこう変化するんだろうけれど、これからに期待ということで。

Go Hide

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

Python Hide

2009年後半はまさしくBuzzwordとして盛り上がったクラウド。
コンサルの人々などが精一杯語った後で訪れるであろう失望期にこそ、真の普及が始まる(・・・かもしれないし、Web2.0のような末路をたどるかもしれない)。
自分としては、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 ???

Boo, Google App Engine, Python, 涼宮ハルヒの驚愕 Hide

先程VPSにyumを入れた目的は、golangを入れて、近時のアップデートについていって、ちょっくらGoのwebフレームワークを使ってみようと言うこと。
ということで、自分の場合をメモ書き (叩いたコマンドのみ):
yum install python-setuptools
easy_install mercurial
yum -y install bison gcc libc6-dev ed
cd;mkdir bin
export GOROOT=$HOME/go
export GOOS=linux
export GOARCH=386
export PATH=$PATH:$HOME/bin
source .bashrc
hg clone -r release https://go.googlecode.com/hg/ $GOROOT
cd ./go/src
./all.bash
・・・し、しまったと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もできるから、クロスコンパイル環境になったということかな。

No tags Hide

まぁ、定番のお話なのだが、備忘録ということで。
自分の場合 :
こちらの方とほぼ同一で、
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.rpm
wget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/python-iniparse-0.2.3-4.el5.noarch.rpm
wget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/python-sqlite-1.1.7-1.2.1.x86_64.rpm
wget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/python-urlgrabber-3.1.0-5.el5.noarch.rpm
wget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/yum-fastestmirror-1.1.16-13.el5.centos.noarch.rpm
wget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/m2crypto-0.16-6.el5.3.x86_64.rpm
wget http://ftp.riken.jp/Linux/centos/5.3/os/x86_64/CentOS/yum-metadata-parser-1.1.2-2.el5.x86_64.rpm
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 *

No tags Hide