先週のScalaのお勉強は、主にアノテーションとスレッド関連。
synchronizedはかっちょえぇなぁ(笑)
Javaだとsynchronizedブロックを作る方法とメソッドに指定する方法があり、さらにそれがインスタンスメソッドの場合とクラスメソッドの場合でロックオブジェクトが異なるけど、Scalaのはsynchronizedメソッドとして定義するだけで、それっぽく見える書き方は全部他の文法によるものになってる。
Futureも便利そう。他スレッドで計算して結果だけくれっていうの。
一定時間経つまで待つalarm()も地味に便利そう。
さて、この辺りでScalaの基礎勉強（Scalaを知る為の色々な調査）は一旦終了。
（カリー化だの継続だのと、理解できてない事はまだいっぱいあるけど(苦笑)）
次は「こんな事をするにはScalaではどう書けばいいのか？」というのを考えてみたい。
昨日『Ashigelコンパイラの勉強会』に参加してきました。
スライド：Inside of Asakusa DSL
Togetter：#ashigel Ashigelコンパイラの勉強会
自分が書いてきたメモはほとんどスライドの写しなので、今回は感想だけ書きます。（というか全部理解できたとは言いがたいので、感想しか書けないというか(苦笑)）
まず「DSL」という言葉について。
自分は最近Scalaを勉強していてScalaの本でよく「DSLの例」を見かけていた。Scala上に新しい構文っぽいものを作り上げ、それを使って目的の記述を行う形式。
なので漠然とAsakusa DSLもそんな感じかと思っていたんだけど、全然違った＾＾；
Asakusa DSLは大きく三層に分かれていて、大きな粒度から順にBatch DSL・Flow DSL・Operator DSL。
まだ公開されておらず初めて見る記述だけに、最初に簡単な実例があると分かりやすかったんじゃないかと思う。まぁ、自分は実際にコーディングしてみないと理解できない人間だからかもしれないが＾＾；（HadoopもScalaもそうだった）
という訳で、実際の実装を見たわけではないので、以下、「こんな仕組みなんだろう」という想像に基づいて書く。
で、Operator DSLは「演算子」と呼ばれていたけれども、自分の感覚では、これは「関数」だなー。（CascadingのFunctionに相当すると思われる）
たぶんどんなパターンの演算を行いたいか（1クラスを受け取って1クラスを出力する、あるいは複数クラスを受け取って…とかのパターン）に応じてテンプレートが用意されていて、そのテンプレート（クラス）を継承したクラスをプログラマーが作り、メソッドをオーバーライドして処理を記述してゆく。具体的にどんなクラスを入出力としているのかは、アノテーションで指定する（Ashigelコンパイラはこのアノテーションを読み取って、OperatorFactoryを生成する）。
（スライドのp.24）
その処理が演算（関数）で、演算を記述しているものだから演算子。…あぁ、演算子でいいのか(爆)
自分は「演算子」と聞くと「+」とか「==」とかのもっと細かいものを思い浮かべちゃうけど、まぁ上位粒度であるFlow DSLから見れば粒度の細かい「演算子」という事なんだろう。
Operator DSLはJavaプログラマーが記述し、実際のHadoop実行時にMap・Reduceから呼ばれる。これ重要。
アノテーションで情報を指定してコンパイラーで処理するのはSlim3とかでもやってる常套手段なので、特に違和感は無い。（これをDSLと呼ぶのかどうか？とは思わなくもないけど＾＾；）
次いでFlow DSL。
「演算子」を組み合わせる層。ある演算子の出力を別の演算子に渡す、という順序を記述する。
（スライドのp.25・95～96）
この記述方法が曲者。
あくまで「前後関係の記述」を「Javaのメソッド呼び出し」を利用して表記しているだけ。
だから、Javaソースとして書くけれども、実際に実行される事は無いんだと思う（コンパイル時点で解釈されるだけ？）。ここがOperator DSLとは全く異なる。
たぶん、Operator DSLでUpdateHogeというクラスを作ったら、OperatorFactoryクラスにupdateHoge()というメソッド（UpdateHogeを返す）が作られるんだと思う。
そのUpdateHoge演算子の出力をoutフィールドで表し、次の演算子クラスのメソッドの引数として渡す“ように記述する”ことによって、演算子の実行順序を表す。
だからこの場所でのUpdateHogeクラスの変数には、「Javaを利用して書いているから、何らかの変数が必要」という以上の意味が無いんだろう。
（Javaの文法に沿っていないとコンパイルエラーになる。Ashgelコンパイラはapt（スライドp.94）を利用してJavaソースとして解析するから、記述内容はJavaの文法に則っている必要がある）
（※ここら辺、具体的にはやはり違うようです。コメント欄参照）
うーん、分かりにくいｗ 黒魔術だと言われる訳だ(笑)
演算子が「語彙」であるというのも最初は分からなかったけど。演算子クラスはその業務で使うロジックだから、「在庫を更新する」とか「金額を計算する」とかの名前になると思う。
実際には在庫とか金額がもっと業務寄りの名前になるはずで、担当者はその単語（語彙）を使って会話しているだろう。逆に言えば、業務で使う用語が演算子クラスに現れる。だから「語彙」。
「語彙としてプログラムする」（スライドp.100）っていうのは、Factoryで使えるメソッドが、定義された語彙（演算子）のみで、それを使ってプログラムする、という意味だろうか。
ちなみに、Flow DSLでは演算子から演算子へ順次処理していくので、その記述から「在庫を更新してから金額を計算する」とかの文章が作れそうな気がする。
うはー、色々考えられているなぁ。
それにしても、フローはやはりGUIで描きたくなるよね(笑) 会場からも質問があったし自分もそう思ったしスライドp.100にも100万回言われたって書いてあるし(爆)
GUIツール上だけで全てを操作しようとすると不便だけど、ベタテキスト（XMLでもいいけど）と相互に切り替えられれば便利だと思う。
（自分が今の仕事で使っているStrutsのFormクラスを生成するGUIツールは不便。大規模なコピーや名称置換はテキストベースの方がやりやすい）
とりあえず、Cascadingのフロー図出力機能のようなものなら比較的簡単に作れるんじゃない？
まぁOSSなので、誰かがやってくれるだろう(笑)
DSLの最後がBatch DSL。（スライドのp.27・108）
これもafterとかのメソッド呼び出しの形式で、処理順序を記述する。
Cascadingならコンストラクターにパイプを渡してたけど、これはAsakusa DSLの方が分かりやすい（書きやすい）かも。
（というか、このレベルのものは無理してJavaで書かなくても…と思わなくも無い(苦笑)が、かと言ってXMLに書くんじゃ、かつて来た道を逆戻り…。あれ、Oozieはそういうものだったかも？）
Asakusa DSL全般を通して、Javaを利用しているというのが面白い。
というのは、間違ったクラスを使おうとするとJavaコンパイラーがエラーを出してくれるので、IDE上でそのまま開発できることになる。
つまり自作コンパイラーを作る上で、そういった面は自作しなくてもよいことになる。
なお、@asami224さんが作っているAsakusa Scala DSLはまた違った形らしいので、楽しみ＾＾
その他。
やはりMapReduceは複数データの結合（join）が一番の鬼門というか肝だなー。
CascadingだとCoGroup、Asakusa Frameworkだと直和型（スライドp.42・83）かな。
実行計画の作成（スライドp.61）とか最適化（p.117～）の考え方も面白かった。ほんと色々な事をやっている。
なぜそれが有効なのかはHadoopに詳しくないと分からないが、逆に言うとHadoopを使う上での注意点にもなってくる。
（ちなみに、スライドp.74の「分断」は何で有効なんだろう？？）
Ashigelコンパイラのコンパイル時間の例で、多めでも2分くらいというのは、速いな。
自分が今の仕事でやってるのは、最低15分はかかるし。（くたばれEJB）
あとは、生産性か。100倍というのは言葉の綾だけど、今Asakusa Frameworkを使っている現場では手書きのMapReduceではとても出来なかったというのはその通りなんだろうな～。
（Asakusa Frameworkを使って1～4人でやっている、素のHadoopなら40人は必要なんじゃないかとのこと）
まだ未完成でこれからという面も多いようだけど、このスピードで開発・公開したという所がポイントなんだろう。（2010年9月から開発開始って、半年経ってない！）
最後に。
@ashigeruさん、ずっと立ったまましゃべり続けて（休憩中も質問に答えていて休めてない＾＾；）お疲れ様でした。ありがとうございました！
（4部構成で今日中に全部終わるか、って話も冒頭にあったけど、終わって良かった(笑)）
先週のScalaのお勉強は、先々週に引き続いてコレクション。
Seqの主な不変クラスであるList・Vector・StreamとArrayのどれが速いかと言うと、やはり一概には言えないという結論になる＾＾；
呼び出すメソッドによって当然異なるし、保持している要素数によっても異なる。
今回は実行速度にしか着目しなかったが、メモリー使用量も異なるだろうし。
とりあえず重要なのは、ScalaのVectorはJavaのVectorとは何の関係もない、ということ。
JavaのVectorはArrayList（やCopyOnWriteArrayList）に取って代わられて要らない子扱いだが、ScalaのVectorは2.8から導入されたというだけあって、なかなか優秀な感じ。
『星を継ぐもの』シリーズを読んだ。
NW（ナイトウィザード）の『星を継ぐ者』じゃなくて、SF（セブンフォートレスじゃなくてサイエンスフィクション）の『星を継ぐもの』（J・P・ホーガン）ね(笑)
月で宇宙服を着た遺体が発見されたが、死後5万年経っていた…っていうやつ。
謎が解決しそうだと思ったら別の謎が出てきて上手くいかなかったり、これで順調に進むかと思ったら断ち切られたり、なかなかハラハラさせてくれる(笑)
作者が引っぱっている謎が、途中で「こういう真相なんだな」って分かってしまう部分も1～2点あるけれどね＾＾；
きちんとハッピーエンドで終わるところが好感が持てる。読後感がいいのはそういう話だし（ザンスシリーズとか）。
『ガニメデの優しい巨人』のラストの返信には涙が出そうになった。
一方で『巨人たちの星』での再会シーンは面白かったｗ
作者が持っている（人類への）楽観的見通しが反映されてるんだろうなぁ。
先週のScalaのお勉強。
XMLリテラルは、CDATAセクションやコメントも入れられる（本で紹介されているのは見たことなかった）とか、意外と高機能だ。
XHTMLも扱えるようなので、簡単なWebサーバーならこれだけで作れそう。
Scalaのコレクション（ListとかMapとか）については、どんなメソッドがあるのか、前から見てみようとは思っていた。んだけど。
多いのは分かってたけど、多すぎじゃー！(笑) 休日まるまる1日使ってしまったよ(苦笑) 終盤はホントに目眩がして危なかったぜぃ(爆)
こんだけ多いと覚えきれないので、何度も見直さないとなー。しかもこれでまだ全部じゃないし。
