この浮気心は本気なのか誰か教えてください
やばい、IntelliJ、欲しくなってきた。一度使うと熱狂的ファンになるみたいだし、購入を考えてみようかな。。。
IntelliJ IDEA7がGroovyとGrailsサポートを追加 – InfoQ
- Posted:
- 12.09.2007
- Category:
- Groovy
「Project Zero ナイトセミナーvol2@秋葉原」に参加してきました
稚北ナイトセミナー「Project Zero」の第２回に，先週の木曜日に行ってきた。僕の指名は「Ustream配信係」。200万画素の新しいカメラも買って，ノリノリで参加をした。講師はアークランプのゆーすけ氏。
- Posted:
- 10.16.2007
- Category:
- Groovy
「Project Zero ナイトセミナーvol1@秋葉原」に参加してきました
先週の金曜日（9月28日）に，「Wakhok Night Seminar」の「Project Zeroコース」の第1回に参加をしてきた。Project ZeroはIBMが始めたアプリケーション開発用のプラットフォーム。話の流れは，Project Zeroの背景として，Web1.0からWeb2.0への移り変わり，Webサービスの変革，そしてRESTという流れの紹介と整理が前半。後半はProject Zero自体の紹介という構成だった。
前半の背景の話は，想定している聞き手の想定が「RESTって何？」ってレベルなのか，直球での説明ではなく，免許センターに例えて説明がなされていた。正直，変に例えられてしまったために，個人的には直感的に頭に入ってこない説明だった。また，RESTと言えば，リソースに着目した設計論という，今までのWebアプリケーション設計とは異なる捉え方が求められると思うので，その辺の紹介を期待していたのだが，残念ながらRESTに関する説明はほとんどされず。
後半のProject Zeroの紹介は，Project Zeroのインストールから，アプリケーションの動作確認までを実演してくれたため，前の日に実際に自分でやってみていたものの，やはりちゃんとした説明付きでデモを見ると違うなぁ，と。自分でやったときは半信半疑で試したのだが，IBMの方のデモの手順を見ると，Project ZeroはやっぱりRuby on Railsに見えてきてしまう。Ruby on Railsでも，URLマッピング次第でREST的な実装も可能だし，Zeroアプリケーションのディレクトリ構造も何となくRoRに似ている。うーん，聞いてみるしかない。
me「Ruby on Railsにとても似ていると思ってしまうのですが，Project Zeroが狙っている層はどういうところなのでしょうか？」
IBMの中の人「Ruby on Railsはデータエントリ機能を大量に低コストで作ることを狙ったものですが，Project ZeroはWebサービスをマッシュアップしてアプリケーションを構築することを狙っています。」
なるほど，確かにProject Zeroでは，Yahoo Pipeに似たマッシュアップ用のリッチなフローエディタ（Webブラウザ上で結線しながらWebサービスの呼び出しやフローを定義できる）が付いていたり，簡易ESBが搭載されていたりすることからも，マッシュアッププラットフォームという位置づけのものであることが見てとれる。ただし，IBMの中の人も認めていたが，Ruby on Railsとかぶっている点も多々ある。「RoRに巻かれたくないけど，Pythonはなぁ」と考えている人には，うってつけの環境かもしれない。
今回の話を総合すると，Project Zeroの特徴としては，
- いろんなサービスをマッシュアップすることにフォーカスしている。
- スレッドモデルではなく，軽量プロセスモデルな仕組みである。
- RESTfulな設計が求められるけど，RoR的でもあることは確か。
- IBMは本気だ。
という理解で個人的には妥当だと思っている。特に，2点目は興味深い。マルチコアなCPUは，スレッドモデルをいかに効率的に捌くか，にチューニングされたものだと思っていたので，「え？プロセスっすか」という印象を持ってしまった。Project Zero向けの軽量VMを開発しているらしく，そのVMは起動スピードがめっちゃ速いらしい。つまり，プロセスの生成＆初期化処理をできるだけ軽くしてプロセスの欠点を減らしたほうが，マルチコアでマルチプロセスの方が性能がでる，ということなのか。うーん，知識が足りなくて，どっちがいいのかわからない。。。
第２回目以降は，Project Zeroの実践に入っていくそうなので，次回も参加するつもり。あ，丸山先生に「Ustreamで配信しようよ。やって。」って頼まれてたんだった。。。
- Posted:
- 10.03.2007
- Category:
- Groovy
クロージャの再帰処理
最近始めたGroovy。LLちっくな文法やメソッドが多く盛り込まれていて，非常に面白い。RubyかPythonに走ろうと思っていたが，やはり長年Javaをやってきた僕にとっては，Groovyが手に馴染みやすいのかもしれない。
さて，Groovyの文法において，Javaと比べて最も特徴的なものが，やはりクロージャではないかと思う。JavaSE7からクロージャがJava言語にも入るとか入らないとか議論されているが，Groovyではそんなクロージャをいち早く体感することができる。クロージャにより，LLならではの書き方が可能になる。ついネストが深くなりがちなコーディングになるような気がするが，非常にスマートな記述を様々な処理で実現することが可能だ。
クロージャの説明はこことかここに任せるとして，今日Groovyでコーディングしていて直面した問題，それは「クロージャを再帰でコールする」処理の書き方である。関数として記述してしまえば書けることはもちろんわかっていたのだが，無名関数と言えるクロージャでも再帰処理を書けるんじゃないか，と思って試行錯誤してみた。
最初に試したのはこれだ。
結果はあえなくNG。funcなんて知らねーぜ，というエラーメッセージ。確かに，定義の中で定義対象をそのまま記述しているので，未定義なものになってしまうことは良く考えれば当然。
では，先に定義しておけばいいんだろ，と考えて次に試したのはこれ。
これは見事に成功。ちゃんと再帰処理が行われるようになった。処理内容を持たないクロージャを定義して変数に代入しておき，その変数の内容を再定義してあげれば既に定義されたものを参照することになるため，自分自身を呼びだすことが解決されるようになる，という感じである。
しかし，何かスマートじゃなく，ちょっとトリッキーな記述な感じを受けてしまう。別に実現できる記述方法があるんじゃないかと思い，さらに試行錯誤を繰り返した。
クロージャは，それ自身がオブジェクトであり，callメソッドを持っている。つまり，以下のような記述を行っても，再帰処理を実現できた。
あっけないくらいにcall()メソッドで再帰処理を記述することが可能。
各クロージャはそれぞれClosureクラス（のサブクラス）が内部的に生成され，そのインスタンスがクロージャの処理を担当する。つまり，クロージャ内でthisを記述した場合，そのクロージャのインスタンス自身を参照することができるような気がしてしまう。しかし，
という記述を行ってみたが，結果はNG。thisはクロージャのインスタンスを参照しているのではなく，クロージャを持っているインスタンス（上記がTest.groovyファイルで書かれていれば，Testクラスのインスタンスが該当）を参照しているようである。よって，this.call()をしても，クロージャのcall()メソッドが呼び出されるわけではないことに注意しなければならない。
さらに，ネストされたクロージャ内で外側のクロージャを再帰で呼ぶ，ということを試してみた。
外側のクロージャを予め空処理で定義しておく最初に紹介したテクニックを応用している。つまり，クロージャを何らかの変数に入れておければ，それに対してcall()メソッドを呼び出すことで再帰処理は実現できるということだ。
ちなみに，上記の動作はgroovy-1.1-BETA1で確認を行った。1.0系とかの古いバージョンでは，クロージャ内のthisの解釈が異なるなど，動作結果がかなり異なってくるので，注意が必要である。
- Posted:
- 05.08.2007
- Category:
- Groovy
