天使やカイザーと呼ばれて » Groovy

この浮気心は本気なのか誰か教えてください

yoichiro — Sun, 09 Dec 2007 07:19:31 +0000

やばい、IntelliJ、欲しくなってきた。一度使うと熱狂的ファンになるみたいだし、購入を考えてみようかな。。。
IntelliJ IDEA7がGroovyとGrailsサポートを追加 – InfoQ

「Project Zero ナイトセミナーvol2@秋葉原」に参加してきました

yoichiro — Tue, 16 Oct 2007 01:00:06 +0000

稚北ナイトセミナー「Project Zero」の第２回に，先週の木曜日に行ってきた。僕の指名は「Ustream配信係」。200万画素の新しいカメラも買って，ノリノリで参加をした。講師はアークランプのゆーすけ氏。

今回の内容はGroovyの紹介。Rubyが流行ってしまった今日では，Groovyをやってみよう！という人は残念ながら減少傾向。つまりProject Zeroを知るためには，そんなGroovyをまずはちゃんと知らないといけないため，今回はGroovyの基礎編という内容となっていた。Groovyの文法面が中心だったため，「え，Rubyでいいじゃん」的な感想を持った人も多かった模様。Groovyには，Javaとの親和性という点で（主に実行時に）有利な点が他のLLを採用した場合と比べていくつか存在する。GroovyがJavaにおける「糊（のり）」として威力を発揮するものであることを，もう少し強調して説明するのもいいのかもしれない。
さて，上記のUstreamの録画，実は途中で終わっている。Project Zeroのデモを実際に見せる直前という，一番面白そうなところが録画されていない。
講師のPCがなぜかプロジェクターと相性が悪く，外部出力に失敗。急きょ備え付けのPCにプレゼン資料を移して対処したのだが，デモ関連の移行は時間が足りずにできなかった。その際に講師から僕は「デモ環境作っておいて」と頼まれていたのだが，大勘違いをして構築なんぞせずにのんびり聞いていたのだが，あと30分で終わりというところに突然「デモいける？」と聞かれ，大慌て。大急ぎでProject Zeroの環境をダウンロードし，ExampleをPlug-inに生成させて，なんとか時間内に間に合う。で，Ustreamの配信を止めて，僕のmacでデモをした，という事態だったというわけだ。
以前Project Zeroの環境構築はやったことがあるとはいえ，Project ZeroのダウンロードからExampleの実行まで，たぶん15分かかってない。「○○分でできる何とか」とか一時期流行ったけど，まさにそれをProject Zeroでやってみせた瞬間。来てくれた人にもっとアピールすれば良かったなぁ，と後日反省。
そんなこんなで，僕にとっては，ワクワクドキドキ，なかなか面白いセミナーになった。次回はハンズオン形式でProject Zeroのかなり突っ込んだところまで解説・実践があるので，もし興味があればドシドシ応募してみて欲しい。

「Project Zero ナイトセミナーvol1@秋葉原」に参加してきました

yoichiro — Wed, 03 Oct 2007 00:45:53 +0000

先週の金曜日（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で配信しようよ。やって。」って頼まれてたんだった。。。

クロージャの再帰処理

yoichiro — Tue, 08 May 2007 01:53:26 +0000

最近始めたGroovy。LLちっくな文法やメソッドが多く盛り込まれていて，非常に面白い。RubyかPythonに走ろうと思っていたが，やはり長年Javaをやってきた僕にとっては，Groovyが手に馴染みやすいのかもしれない。

さて，Groovyの文法において，Javaと比べて最も特徴的なものが，やはりクロージャではないかと思う。JavaSE7からクロージャがJava言語にも入るとか入らないとか議論されているが，Groovyではそんなクロージャをいち早く体感することができる。クロージャにより，LLならではの書き方が可能になる。ついネストが深くなりがちなコーディングになるような気がするが，非常にスマートな記述を様々な処理で実現することが可能だ。

クロージャの説明はこことかここに任せるとして，今日Groovyでコーディングしていて直面した問題，それは「クロージャを再帰でコールする」処理の書き方である。関数として記述してしまえば書けることはもちろんわかっていたのだが，無名関数と言えるクロージャでも再帰処理を書けるんじゃないか，と思って試行錯誤してみた。

最初に試したのはこれだ。

def func = { x -> ・・・ func.call(x) }

結果はあえなくNG。funcなんて知らねーぜ，というエラーメッセージ。確かに，定義の中で定義対象をそのまま記述しているので，未定義なものになってしまうことは良く考えれば当然。

では，先に定義しておけばいいんだろ，と考えて次に試したのはこれ。

def func = {} func = { x -> ・・・ func.call(x) }

これは見事に成功。ちゃんと再帰処理が行われるようになった。処理内容を持たないクロージャを定義して変数に代入しておき，その変数の内容を再定義してあげれば既に定義されたものを参照することになるため，自分自身を呼びだすことが解決されるようになる，という感じである。

しかし，何かスマートじゃなく，ちょっとトリッキーな記述な感じを受けてしまう。別に実現できる記述方法があるんじゃないかと思い，さらに試行錯誤を繰り返した。

クロージャは，それ自身がオブジェクトであり，callメソッドを持っている。つまり，以下のような記述を行っても，再帰処理を実現できた。

def func = { x -> ・・・ call(x) }

あっけないくらいにcall()メソッドで再帰処理を記述することが可能。

各クロージャはそれぞれClosureクラス（のサブクラス）が内部的に生成され，そのインスタンスがクロージャの処理を担当する。つまり，クロージャ内でthisを記述した場合，そのクロージャのインスタンス自身を参照することができるような気がしてしまう。しかし，

def func = { x -> ・・・ this.call(x) }

という記述を行ってみたが，結果はNG。thisはクロージャのインスタンスを参照しているのではなく，クロージャを持っているインスタンス（上記がTest.groovyファイルで書かれていれば，Testクラスのインスタンスが該当）を参照しているようである。よって，this.call()をしても，クロージャのcall()メソッドが呼び出されるわけではないことに注意しなければならない。

さらに，ネストされたクロージャ内で外側のクロージャを再帰で呼ぶ，ということを試してみた。

def func = {} func = { x -> ・・・ x.each { y -> ・・・ func.call(y) } }

外側のクロージャを予め空処理で定義しておく最初に紹介したテクニックを応用している。つまり，クロージャを何らかの変数に入れておければ，それに対してcall()メソッドを呼び出すことで再帰処理は実現できるということだ。

ちなみに，上記の動作はgroovy-1.1-BETA1で確認を行った。1.0系とかの古いバージョンでは，クロージャ内のthisの解釈が異なるなど，動作結果がかなり異なってくるので，注意が必要である。