第16回 G*ワークショップ（Groovy勉強会）に参加してきました。

Groovy 勉強会・セミナー

大震災の影響もあるのか、前回（JGGUGの勉強会（G*ワークショップ）に初めて参加してきました - 達人プログラマーを目指して）と少し間が開いていますが、昨日、JGGUGさん主催のG*ワークショップというGroovy勉強会に参加してきました。場所は、東京の勉強会ではおなじみの外苑前のオラクル青山センターです。
やはり、今回の注目ポイントは４月に正式リリースされたGroovy1.8とそれに対応した待望の日本語書籍プログラミングGROOVYの出版が間近に迫っているということがあげられますね。
なお、詳しいレポートは、既に、以下でまとめられています。
第16回 G*ワークショップ＋JGGUG総会に参加してきた - Diary of absj31
第16回 G*ワークショップ＋JGGUG総会に行ってみた - 日々常々
mike、mikeなるままに…: 第16回 G*ワークショップ＋JGGUG総会に行ってきました。
また、勉強会中のTwitterのつぶやきのまとめも以下にあります。
2011/06/17_第16回 G*ワークショップ＋JGGUG総会 - Togetter
今回の勉強会に参加して、非常によかったと感じたのは、
株式会社メソッドのMANIC活用法－2chや業界での評判まとめ
のサービスを利用して、参加者全員にTwitterのアイコンとIDの入った名刺が配布されたことですね。普段、Twitter上でお話をしている相手でも、初対面で顔がわからないとなかなか話しかけにくいものですが、これがあれば隣に座った人などが一目で識別できます。主催者の方々のお心配りに感謝いたします。今回はこの名刺のおかげで、ミケネコさん（@mike_neck）、きょんさん（id:kyon_mm、@kyon_mm）、irofさん（@irof、id:irof）キムコウさん（@kimukou_26）、スズキさん（id:suzukij、@suzukij）、ちゅうきさん（id:tyuki39、@tyuki39）など、普段Twitterでフォローさせていただいている方々を簡単に見つけることができ、ご挨拶させていただくことができました。今回は時間の関係で参加者同士で自由に歓談する時間が少なかったところはありますが、これは非常によい試みだと思います。（私もそうですが、初対面の人に話しかけるのが苦手な人にとっては助かるアイテムですね。）

2010年度JGGUG総会（山田正樹氏）

まず、最初に山田正樹氏（@yamadamasaki）の司会でJGGUGの総会が滞りなく執り行われました。詳細はid:absj31さんのレポートに詳しく書かれていますが、私としては特に以下に興味がありましたね。

  • 吉田健太郎/ふも(id:fumokmm)さんが新たに執行役人に就任
  • 活動計画として日本Springユーザ会や日本Javaユーザ会と連携を予定
  • 月1回程度のチャットミーティングが必須のサポートスタッフを募集中
  • 個人サポータ制度として任意の金額をJGGUGに寄付できる。（詳しくはsupporters@jggug.orgまで）

特に、他のJava関連のユーザグループとの連携については期待していますし、私も仕事上Java関連で開発をしているという関係上、今後何らかの形で貢献できたらと思いました。Groovyはプログラミング言語そのものの研究というだけでなく、実用技術として、既存のプラットフォームやフレームワークとの親和性を生かしてこそ力を発揮するというところがあると思います。

「レッツゴーデベロッパー2011」レポート（Takuma Watabiki氏）

続いて、 Watabiki氏（id:bikisuke、@bikisuke）より、仙台で先月開催された「レッツゴーデベロッパー2011」というクロスコミュニティイベントの活動報告がありました。クロスコミュニティイベントとは言え、全セッションのうち以下の二つがGroovy関連という、Groovyファンにとっては実に楽しいイベントだったようですね。

これは、もともと計画されていた「G*ワークショップ in 仙台」が、あの大震災の影響で実施できない状態になっていたという事情があったようですね。それにしても、震災であのような大きな被害を受けた東北で多くの困難がありながらも敢えてイベントを計画し、また、そのイベントに多くの開発者が集まって成功裏に終了するとは、本当に熱いものを感じました。自分も日ごろから業界や会社の仕事環境がよくないとか不平を言っているだけではだめですね。こうした活動の話を聞いて、自分もできるところから、少しずつでも行動を起こしていかなくてはいけないとあらためて思いました。

「今日からはじめるGPars」（吉田健太郎/ふも氏）

正直なところ、今回G*ワークショップに参加する最大の目的が、実はリアルで一度ふもさん（id:fumokmm、@fumokmm）にお会いしたいということがあったのですが、今回初めて達成されました。今回はこの勉強会のために名古屋から東京にお越しいただきました。ふもさんは、はてなのスターフレンドとして、GroovyやClojure関連でお世話になっております。残念ながら個人的にじっくりとお話する時間がなかったのですが、想像していたとおり、大変気さくで話しかけやすく、また研究熱心なプログラマーという印象の方でした。
今回は、4月に正式版がリリースされたGroovy1.8に正式に含まれるようになったGParsという並列処理ライブラリーについてのお話でした。GPars（ジーバーズ）の名前はそのまま、Groovy Parallel Systemsの略のようです。*1

The GPars project offers Java developers intuitive and safe ways to handle Java or Groovy tasks concurrently. Leveraging the enormous flexibility of the Groovy programing language and building on proven Java technologies, we aim to make concurrent programming for multi-core hardware intuitive, robust and enjoyable.

GParsプロジェクトはJava開発者に直感的で安全な方法でJavaやGroovyのタスクを並行処理する方法を提供します。Groovy言語の途方もない柔軟性と実績のあるJavaの技術を活用することで、マルチコアハードウェアに対する並行プログラミングを直感的で信頼性があり、そして、楽しいものにします。

実際、講義ではふもさんお得意の「ハロワ」*2の実演を交えながら、

  • 非同期コレクション（並列コレクション）
  • アクター
  • エージェント
  • データフロー

を使ったプログラミングについて説明されました。確かに、概念的にこれらの並行処理の概念をきちんと理解する必要があるのですが、実演で示されるサンプルプログラムは、ハロワの名前にふさわしく、どれも一画面に収まってしまうくらい非常に短いもので、あっけにとられる程簡単なものばかりでした。しかも、1.8からは標準添付なので、別途ライブラリーを追加する手間もいらないのです。
従来、Java言語でこれらの処理を実現しようとしたら、Java並行処理プログラミング ―その「基盤」と「最新API」を究める―などで説明されているjava.util.concurrentなどのライブラリーを駆使してかなりの分量のコードを記述する必要があり、ただでさえ敷居が高い並列処理がますます難しくなるという印象だったのですが、GParsを使えば少なくともコード自体は非常に簡単に記述できるのですね。たとえば、

import static groovyx.gpars.GParsPool.*

def numbers = [1, 2, 3, 4, 5, 6]
def squares = [1, 4, 9, 16, 25, 36]

withPool { 
    assert squares == numbers.collectParallel { it * it }
}

この記述だと、実際あまりにも簡単すぎて何が行われているのかわからない感じですが、CPUのコア数に応じてスレッドのプールが自動的に割り当てられ*3、クロージャーで示される各計算処理（上記の例だと二乗）が複数のスレッドで同時に処理されるようになるとのことです。また、これはJSR166、JSR166yなどのJavaのライブラリーに対するDSLとなっているそうですが、信頼性の高いJava言語の基盤の上に使いやすいGroovyのAPIをかぶせたという感じでしょうか。Java言語やJavaのライブラリーをいったん完全に否定するところからスタートするのではなく、伝統的なJavaの資産を活用しつつ、その上で使いやすさを提供するという、もともとのGroovyの思想を並列処理でも利用できるようになるということですね。
並列コレクション以外に、ScalaやErlangで有名なアクターを使ったプログラミングやClojureのようなエージェントを使った可変な状態の同期、データフローを使った依存関係による計算順序の並列化の話などがありました。
もちろん、記述は簡単ですが、適切に利用するためには背景となる並列処理に関する知識が必要になると思われます。上記の例でもcollectParallelに渡すクロージャーが純粋な関数となっておらず、副作用があるとおかしな動作になってしまいますし、そもそも、どういった場合に並列化すると高速になるかといったことを実際には考慮する必要があると思います。
従来、並列処理は難しいものとして敬遠していたところがあったのですが、このような使い勝手のよいライブラリーが利用できるのであれば、今後、業務でも真剣に応用することを考えていきたいと思いました。複数のリクエストを同時に複数スレッドで処理するオンラインのアプリケーションとは異なり、バッチプログラムやテストプログラムの高速化などに特に有用かもしれません。
なお、ふもさんを中心として、現在GParsのユーザーガイドの翻訳中とのことでした。（翻訳協力者募集中@fumokmmまで）
講義スライドは以下に上がっています。

今日からはじめるGPars
View more presentations from fumokmm

「Groovy 1.8の新機能 〜ま、まさか、今までのGroovyが予告だったとでも言うのか…〜」（上原潤二氏）

講義の後半はプログラミングGroovyの著者の一人でもあり、また、groovyservの開発者としても知られる上原さん（id:uehaj、@uehaj）から、たくさんあるGroovy1.8の新機能のうち特に重要なものについての紹介がありました。

  • 文法の拡張
  • AST変換強化
  • クロージャまわりの強化（メモ化による高速化など）
  • 効率向上（int型の最適化など）
  • ライブラリー強化
  • その他

タイトルにあるように、いままでのGroovyの存在が単なる予告編だったのかと思わせるくらい、魅力的な数多くの新機能が実現されており、今回のリリースは「Groovy史上、十指に入る良い出来」で、全機能を説明したら1日がかりになるということをおっしゃっていました。
講義スライドは以下。

Groovy 1.8の新機能について
View more presentations from Junji Uehara
これは、LTコーナーの最後にid:nobeans氏によって行われたデモの内容とも重なるのですが、私として、もっとも興味深かった内容はAST（抽象構文木）変換によるソースコードのさらなる簡易化の話ですね。AST変換などと聞くととても難しそうに響くのですが、Groovyのソースコードを解析した結果を途中で加工してしまうテクニックで、実用上はプリプロセッサによるマクロ展開に近い感じで使えるようです。それで、1.8では数多くのAST変換を行うアノテーションが標準で利用可能なのですが、それらを

  • ボイラープレート割り
  • 巨人の肩
  • 言語機能の補修・拡張

といった観点から分類し、非常に上手に説明されていました。ボイラープレート（boilerplate）コードというのは洋書を読んでいると時々出くわす表現ですが、お決まりの鋳型コードを指す用語です。Javaでいえばgetter、setterやtry-catch-finallyなどいたるところで見られます。もともとGroovyではこれらのボイラープレートはJavaに比べてはるかに少なかったのですが、AST変換の活用でさらに削除可能ということですね。巨人の肩は@WithReadLockと@WithWriteLockなどのようにコーディングイディオムを実現するための定型コードを生成します。最後の分類では、もともとJava言語のキーワードとして足りていないような機能を言語機能自体を変更することなく拡張する手段として使えるということを示しています。なお、AST変換については、1.8からGroovyConsoleに標準搭載されているASTブラウザの機能を利用することで、簡単に変換結果を表示できるということも便利ですね。
その他、クロージャーの呼び出し結果をキャッシュして再利用するメモ化やint型による大幅な高速化などGParsとの関連すると思いますが、関数型ライクなプログラミングを強化する機能がいくつか追加されているようです。

その他

その他、今回はオラクルでJavaエバンジェリストをされている、寺田佳央さん（@yoshioterada）が、今後全国各地で開催される予定のJava SE7のLaunchイベントの紹介ということで飛び入り参加されており、個人的にご挨拶する機会がありました。また、懇親会兼LT大会では10人の方々から発表がありました。
平日の夕方の限られた時間でしたが、全体的に非常に密度の濃い充実した勉強会で、有意義な時間を過ごさせていただきました。
他の新しい言語と違い、Groovy言語については、JavaプラットフォームやJava言語を作り直すのではなく、より使いやすく自然に拡張するというところがあると思います。Javaプログラマーにとってはいったん過去の知識を忘れてゼロから出直すという必要がないというところに優しさと親しみを感じますね。ですから、私のようにSI開発の現場でJavaで開発している場合でも、ツールやテストケース作成など、段階的に便利な機能から活用してくことが十分に可能だと思います。自分の会社の周りでは、いまいち認知度や利用実績が低いようですが、
日本でGroovyの知名度がいまいちな理由 - Togetter
もうすぐ、オリジナルの日本語書籍も出版されますし、自分の周りでもファンを徐々に増やしていければと思いました。

*1:一般的にはconcurrent=並行、parallel=並列と訳されるようです。両者は厳密に区別される場合もあるようですが、混同して使われているケースもあるようです。並列と並行の違い - 氷雪の備忘録

*2:もちろん、この場合ハローワークでなくてHello Worldの略。新しい言語やライブラリの実行環境を確認するための最短のプログラムのこと。

*3:デフォルトではコア数+1。もちろん、明示的にプールサイズの指定も可能。