第17回 G*ワークショップに参加してきた #jggug

勉強会 Groovy


(写真：品川駅)

この日の前日に2chで出された『東京駅で17:30に大量殺人します』予告がどれほど影響あったのかは定かでは無いですが(自分は最寄り駅が東京駅だったので少なからず心配してました。結局何事も無く普通に東京駅から山手線で品川へ向かいました)、予定通り開始時間前に到着。

会場はNTTソフトウェア品川本社。Jenkins勉強会やこれまでのGroovy関連のイベントで良く使われている場所ですね。

では早速参戦メモ。

関連Togetter：

1.4.0.M1 !? 2.0.0.M1 -更新メモ-

セッション講演者の都合により、こちらのセッションからの開催となりました。

@tyamaさんはGrailsのリリース直後にブログで翻訳版を書いておられるそうで、今日がそのリリース日でもあり(写真はちょうど数時間後になされるであろうリリースのビルド実行背景。Jenkinsでは無くHudsonである事に多くのツッコミが入っていました(笑)

概要
  • 7月前半のイベント
    • 諸々あったが、何と言っても目玉はプログラミングgroovy発売！
    • そして、7月は@tyamaさんの誕生月でもあった。
  • Grails
    • ある程度の最新のアーキテクチャを追うことが出来る。
    • 最先端、流行のJava開発を知る事ができる。
    • Grailsでの開発
      • 開発効率の追求
      • シンプル且つ柔軟。
      • DDD
    • ただし！
      • 柔軟すぎて室の悪いアプリも構築出来る。
    • 1.4.0 ? To 2.0!
      • 1.4にしておくにはもったいない。→2.0 M1になった。
    • まだM1です！
  • Gralis2.0での更新(予定)内容

  • はじめに！
    • Grailsリリース時に、いつも気になること。
      • Upgradeで更新するとき、大抵メジャーバージョンUPを壊す。
      • 今回もいきなりエラ−。しかしすぐ治った。
      • 単純なものは問題無しなようです。

Grails2.0更新内容詳細

コア＋その他の更新
  • Groovy 1.8：超強化されたGrovyをバンドル。
  • Spring3.1：SpringプロファイルとGrails環境のブリッジ
  • Servlet3.0：Asyncとか個人的に注目
  • Tomcat7.0
  • hibernate
  • 開発時のリロード改善
    • Javaエージェントの実装により、未サポートだった静的型のサービス、ドメインクラス等のリロードが可能に。
  • パフォーマンス強化・速度向上。
    • GSPが再度最適化された！

  • 賛否両論ありますが･･･。
    • 開発モードで1.3.7より10倍以上遅くなっている？
    • プロダクションモードなら問題ないっぽい？

  • スカッフォルドUI(HTML5に対応)に。
  • コンソールUI
    • コンソール表示が1行で表示されるように！
  • コンソール

  • エラーレポートとスタックトレース表示
    • 前はさみしい状態
    • 今回からは賑やかに。
    • 見やすくなった。
  • Grailsｿｰｽの構成改良
    • ソースツリーお掃除！
    • Gradle使ってる人は参考になると思う。オススメ！
リソース
  • ドキュメント追記されていると思うが、使い方がわかりにくかったので･･･
  • 簡易resourcesプラグイン講座
    • スライド参照。
DB,GORM
  • 基本ｄｂをh2へ変更
  • DBコンソールの改良
  • 複数データソースサポート

マイグレーション/riba-su エンジニアリング
GORM API 大幅改良・機能強化
  • GORMでの抽象クラス継承のサポート
    • (※詳しくは話が長くなるので割愛。)
    • OrCreate/OrSaveクエリーの実装追加
    • 名前付きクエリ
      • 名前付きクエリがドメインクラスのリレーションを含んでいる場合、
      • そのリレーション先の名前付きクエリを使用する事が可能に。
    • 共有制約とコマンドオブジェクト
テスト
  • Unitテストが大幅改善！
    • フィルタ、URLマッピング、ファイルアップロード、・・・
    • mixinベースのunitテスト
    • Spockもサポート
    • Unitテストスカッフォルディング(デモ実演)
      • Mockとか
    • コントローラーテストの方法
      • 公式ドキュメントの9.1に詳細。
    • テストの表示が見やすくなった！
      • コンソール上ではpowerAssert表示。
      • ブラウザ上でも同様。
      • 結果もインタラクティブモードで開けるように。
    • 本気でテストは向上している。
プラグイン
その他
  • アクションがメソッドに
    • 今まではアクションがクロージャで実装されていた。
      • 今後はメソッドで実装を推奨します！
      • (もちろんクロージャもサポートしています)
    • メソッドにする事によっての利点
      • メモリ効率
      • ステートレスコントローラーの使用
        • Grails徹底入門突然のプレゼント！
      • ･･･気付いちゃった。
    • 検証していくうちに『メソッドが良いよね』となった
  • アクションのメソッドに引数を指定
    • アクションメソッドに引数を指定してバインド。
    • 指定した型に変換されます。

  • Servlet3.0 Async
    • 非同期処理。AsyncContext
      • BuildConfigにサーブレットバージョン指定
      • 使用方法：def ctx = startAsync()
    • フィルターの除外定義
      • data-mappingの名前が変更された
      • さらにその他
        • 依存ライブラリ・プラグインにSNAPSHOTがある場合の自動更新
        • JSonBUilderは非推奨、等。
  • (QAタイムへ突入･･･)

QAタイムに入ってからの時間内で、突如書籍『プログラミングGroovy』等書籍のプレゼントコーナーが開催され、最終的には『Groovyじゃんけん』というルールでプレゼント対象者を決めていました。Groovyじゃんけんは、声をだして行うじゃんけんなので少し恥ずかしいです(笑)

うさみみとJenkinsとG*な開発環境

当初は19:00からの一発目セッションの予定だったのですが、都合により合流が遅れたためセッション順序を入れ替えて実施。こちらの順番/時間にギリギリ間に合う形で始まりました。

※エントリ冒頭でも述べた『東京駅17:30大量殺人予告』の件ですが、実は予告を書いた人のハンドルネームがまさかの『KYON』。

名前見たときに『ちょっw まさか…』とも(ほんの)一瞬思いましたが、当然の事ながら違いまして(笑)本人にその旨聞いてみた所『知らなかった。自分ならもっと(うさみみに)ちなんだ平和的な事をやる』と言ってました(笑)


前回LTで初お目見えとなった『うさみみ』ですが、今回のセッションでもそれは健在。セッション開始と同時に『うさみみモード』へ。

  • 7/20に行われたAgileConferenceTokyoにて、ファウラー氏の発した『花金』という単語に反応出来てなかった…
  • うさみみの日常＝G*な開発環境
    • 去年の10月にExcel仕様書からソースコード自動生成しなきゃならんという状況に
    • Groovyの存在を知ったが『楽しそうだけど今は無理だな…』
    • 調べてみた→今がある。
きっかけ
G*の導入
  • Groovyをやりたい理由
    • Javaだと複雑な処理をGroovyでは短く書ける
    • スクリプトで簡単に試せる
      • ex)GroovyConsole.etc
      • 無名クラスを書くと『何これキモい』
      • 自分で試すよりも、人に見せる
      • そのためには3秒で見せて分からせなければ。

  • Groobyをやれない理由
    • 新しい言語は学習コストがかかる
    • 安定しているのか不安

  • Groovyはprivateにアクセス出来るJava。
  • GroovyはjavaというUNIX哲学の言語をモダンにラップした唯一の言語。
    • Scalaとかは全然違う概念。
  • Groovy導入の説得材料
    • Spring SourceのOSSプロジェクト
    • テストコードで使う
    • dump()メソッドなどでデバッグしやすい
    • プロダクトではよっぽど複雑なものを簡単に書けるとき
      • 例)XMLのネストしたキーバリュー構造、Javaでは300行掛かった処理がGroovyでは遙かに少ない行数で実現。
    • Groovyはいろんなものに柔軟に使える
      • 面倒な日付フォルダの作成とか...
開発環境概要
  • TestCode 4 Groovy
    • Javaとほどんと変わらない文法で書ける。
    • privateにダイレクトアクセス(privateアクセスのコードは捨てる前提)
    • dump()メソッドでオブジェクトの内部状態を簡単に表示
    • PowerAssertによる綺麗な表示
      • hamcrestというjavaライブラリを利用
      • Spockとか使わないのであれば...
      • JUnitを使うのであれば、有用!
    • TDDの障害：パッケージプライベート
      • とりあえずパッケージプライベート・・・本当は良くない。
      • Groovyのprivateアクセスのテストコードは毎回捨てている。すぐさま消す前提で。
  • ProductCode 4 Groovy
    • Javbaとほどんと変わらない文法で書ける
    • Javaからもjavaクラスのようにアクセス出来る
    • Javaのinterfaceを継承するようにすればjavaからはgroovyからというのを意識しなくてもいい
  • Gradle Test
    • 対象テストをパラメータで渡してそれぞれ実行。
    • テストパッケージをtdd,unittest,systemtestと分けておき、
    • タスクを分割する事でjenkinsで並行処理をしやすくする
    • ※jenkinsでどうなのか、並列処理出来るのか、という所には気を遣う。
  • Gradle Analyze
    • テストとコンパイル以外の設定は全て別のGradleスクリプトにする。
    • findbugs.gradle, checkstyle.gradle
    • 外だしにする事でプロダクトに依存している部分を分けて書ける
    • ビルドツールだって読みやすくなる


  • ローカルリポジトリ：開発機
  • プライベート：サーバー
  • セントラル：サーバー
  • 手順
    • 1.ローカルでコミットし続ける
    • 2.プライベートリポジトリにpush
    • 3.プライベートリポジトリがhookしてjenkinsジョブ実行
    • 4.失敗したらメールで通知
    • 5.成功したらjenkinsがセントラルにpush
    • 6.セントラルリポジトリがhookしてjenkinsジョブを実行
  • 使用したプラグイン
    • win32mbcs
    • eol（コミットする度に改行コードを修正）
    • bookmarks, mq（個人的に）
      • GITのタグに似てるような/歴史改変
  • Mercurialを何故使ったか
    • Linuxサーバを1台も買い与えられず、自分のWinマシンだけでやらなければならなかった
    • →Jenkins等分散バージョン管理環境以外はまぁ動いてた。
    • →Git環境を一から入れる気力は無かった、Mercurialならその点は簡単！
      • やりやすさ、という点ではMercurialは良い。

  • Jenkins Plugin
    • Gradleのビルドをパラメータを変えながら多数のジョブを実行
    • 簡単なUI！
    • 実行するだけなら簡単。
  • 作成したもの：Redmineのチケットを自動発行するプラグイン
    • Twitterプラグインをお手本に作成
      • 実装したいクラスを継承して作成。比較的簡単。
    • チケット発行がプレッシャーにならないようにSystemTestのジョブのみで発行されるように設定
      • ↑目的はQA。
        • BTS使う：いかにexcel大好きな人を納得させるか
        • 自分でやるならどうするか
        • システムテスト失敗時にチケット発行すればよい？→それ以前だとプレッシャーに。
        • (効果)特定のプロダクトコードのみ失敗するように。
          • わかりにくい記述になっていた。
          • 悪い所が見えてきた。改善案もみえやすくなる。
  • 今後挑戦したいこと
    • Mercurialの歴史改変？（コミットコメントの変更）
      • gitとかでは出来るらしい
    • Jenkinsをもっと日常ルーチンワークで使いたい
      • 複数サーバで稼働させたい

…という感じで、実際の環境についての説明・解説が成されていきました。ツール・環境選定の基準はとても明確であり、且つ説明も非常に分かり易い。『ゆとり』の一言で笑いに変えてはいましたが、『わかりやすい』『早い』という点を最優先にした判断・構築ノウハウは素晴らしいものがあるなぁと思いました。また、Gradleの簡単さにも驚き。これは使ってみたいな〜と思わせるだけの可能性は秘めてます。

Q&A

質疑応答では、技術環境的なものよりもまず最初にこの質問が投げ掛けられました。

これに対しての本人の答え。

  • Twitterイラストアイコンを書いてもらってた
    • で、その時の注文がこんな感じ。
      • めがね
      • 髪型
      • うさぎ大好き
      • 服装に関する指定
    • で、それをうけて『今度は実写だよね！』でこうなったらしい。

ようやく明かされた、きょんさんの『うさみみ』の謎、という感じでしょうか(笑)

その他、メモ取れた内容としてはYukei Wachi(TwitterID:@digitalsoul0124)さんから以下の2質問が。

  • TDDフォルダとUnittestフォルダを分ける基準は？（わちさん）
    • TDDで作ったテストコードを元に、Unittestコードを作成。
    • そのためにフォルダを分ける
    • きょんさんのTDDはやりやすさ重視。

お知らせ

勉強会終了前に2つのお知らせが。とその前に…書籍『プログラミングGroovy』の表紙中央にあるこのマーク(写真参照)、実は…

正体はこうなっていたのだそうです。Javaと親和性の高いGroovyらしいトリビアでした。

お知らせは以下2点。

#1：『プログラミングgroovy』オリジナルポロシャツ制作決定！
#2：JGGUG合宿2011、開催の方向へ(ほぼ決定)


日付はほぼ確定で、希望によれば前日の11/4からの参加も可能だそうです。興味のある方は以下のGroupに参加を。

今週は

と2日連続参戦、そして週末に

と3連戦…1週間に5個の勉強会に参加するというちょっと無謀なスケジュールを立ててしまいました。(^_^;)
しかもラスト2つは全日対象のBoot Camp。今日で3/5が終了しましたが、大きな山場、BootCamp2連戦で体力が持つかどうか心配です…。

こんな酔狂な事する奴もそうは居ないだろう…と思ったら、全く同じスケジュールで臨む方が他に3人も。

@pocketberserkerさん、@irofさんとは今回初めての御挨拶＆顔合わせとなり、同じ3連戦に臨む者同士でエールを送り合いました(笑)

さて、明日はAM10:00からの開始。早めに寝て備えることにしたいと思います。