AsakusaFWをScalaで記述するライブラリー（不確定名：AfwHS）をちょこちょこ改造したので、公開。
WordCountの作り方を書いて、現状で使える演算子（foldを追加した。それでも少ないけど＾＾；）の説明も一応書いた。
これ、面白そうってだけでとりあえず作ってみたけど、真面目にやったらけっこう便利かもしれない。
AsakusaFWへの変換が等価であれば、Scala上でテストが通ればAsakusaFWでの動作が（基本的な部分は）保証できるわけだよね。
いくらScalaのコンパイルや起動が（Javaと比べて）遅いと言っても、Hadoopを起動するよりは断然速いわけだから、テスト（動作確認）が素早く出来ることになる。
AsakusaFWがWindowsに正式には対応していないという点が問題として挙がっているらしいけど、Scalaだけで動かせるなら、Windowsでも全然問題ないわけだし。（DMDLからのモデルクラス生成はAsakusaFWの機能を使っているけど、ここも別にプラットフォームは関係ないし）
（というか、Hadoopを起動せずに自前で実行するというやり方自体は、別にJavaでも出来るな…）
記述のしやすさもScalaならではという気がする。
表面上はあまり意識しないけど、実は関数を渡しているというのが便利。
（同じ事をJavaでやろうと思ったら、インターフェースを定義して継承して実装して…と、見た目がすごくクドくなる(苦笑) それなら処理だけ記述するクラスを作る方が分かりやすい…となると、つまり現状のAsakusa DSLのOperatorのやり方ですなぁ）
あと、普通にScalaプログラムとして記述しているので、EclipseのF3キー（定義へのジャンプ）が出来るのも便利。Asakusa DSLの場合、ジョブフロークラスからはOperatorFactoryのメソッドを使うので、Operatorへ直接ジャンプすることが出来ないんだよね。
（昔、EJBを使ったプログラムでもそういう問題があったので、Javadocの@seeとか@linkでクラス名やメソッド名を記述しておいて、そこからF3キーでジャンプできるようにした事があったがｗ）
まぁ、AfwHSの一番の問題は、一番肝心なJava（Hadoop）からScalaの関数を呼び出す部分が怪しいってことだけどね(爆)
Scalaの関数は自分の関数の外にある変数にアクセスする書き方が出来るので、そのインスタンスはどうするんじゃい？（というか外側へアクセスしていることをどうやって判別するんだろう？）
ここら辺は（深くは追ってないけど）Sparkはある程度対処しているみたいなので、本格的にはSparkを使う方が良いのだろうｗ
