TDDBC 大阪 2.0 参加してきた #tddbc

開発ライフサイクル テスト TDD

待ちに待った念願の TDDBCに参加することができました！

主催者の皆様のおかげで、今回は、 6/2　土曜日、6/3　日曜日の二日同じ内容をやっていただいていました。なぜなら、人気がありすぎて、すぐに 満席になってしまうくらいに人気で、それだけこの勉強会に参加したい方が多いって事でしょうね。

募集ページ
みんなのポジションペーパー

タイムテーブル

0930〜1000 受付
1000〜1010 会場説明
1010〜1040 和田さん講演
1040〜1110 吉岡さん or 咳さん講演
1110〜1120 休憩
1120〜1200 デモペアプロ
〜1300 ご飯食べながらペア決めしながらアイスブレイク
1300〜1530 演習と休憩
1540〜1610 関さんの講演
1620〜1650 テーブルレビュー
1700〜1730 講師・TAトークセッション
1730〜1740 KPT
1740〜1750 和田さん振り返り
1750〜1800 おわりに

和田さん（@t_wada）講演

ここでは、TDDに関する基本の考え方について学びました。TDD自体は聞きかじった程度で、ちゃんと人のお話を聞くのは初めてでした。ここで学んだことを以下に列挙します。
  • ソフトウェア開発の３本柱：バージョン管理、テスティング、自動化
  • テストに関する感覚は皆違う。
  • TDDの「黄金の回転： Red、 Green、リファクタリング、のサイクル。
  • プログラムを作成する時は、自分が最初のユーザーである事を意識すること。
  • テストを書いて、自分のコードに自信を持とう。
  • 「CleanCode」の著者、Robert C. Martin さんは、 グリーンバンドを見て、やる気を奮い立たせているそうだ。
参考：@t_wadaさんの事がよくわかるインタビュー記事

吉岡さん（@hyoshiok）講演

資料
楽天に勤めていらっしゃる吉岡さんの発表は、TDDとか自動ビルド等の歴史が分かる発表でした。
  • １９８０年とか、それくらいからTDDとか、継続的インテグレーションの始まりのような開発をされていたと聞いて、ビックリ。
  • チェックアウト→コード修正→他の方のレビュー→チェックイン：レビューは大事ですね。
  • デイリービルド：ビルド専用のマシンが複数台あり、その日のチェックインをビルド、エラー時は即時ロールバックした。
  • テストプログラムは、他人の作ったコードのテストだけやるようにした。
  • 吉岡さんが会ったハッカーは、高い技術と、コミュニティをを大事にする心、を持つプロフェッショナルである。
  • テストのないコードはレガシーコードだ！

デモペアプロ

ペアプロは@t_wadaさんと@irofさんによって行われました。お二人とも楽しそうにペアプロされていました。

ワークショップ

私のペアプロのお相手は、@yoshi_naoyukiさん。若くてやる気のある方でした。今回私は、Groovy希望で受けさせていただいたのですが、当日@kyon_mmさんが「Groovy(Spock)でやりたい人？Javaが書けるならGroovy(Spock)で楽しくできるはずですよ〜」って呼びかけしたら、およそ10人くらいの方が手をあげられていました。これが「Javaと仲良くやっていくGroovyの力」なのか？呼びかけした@kyon_mmさんのカリスマ性なのか？ おそらくは両方でしょう。

ペアプロの前に、まずは環境設定をしました。今回はIntelliJidea + Spockでペアプロを行いました。PCは、@yoshi_naoyukiさんがお持ちのパソコンの方が、画面が広かったので、お借り致しました。@yoshi_naoyukiさん、ありがとうございました。

実際にペアプロをやってみると、まず事前にやったはずのSpockの構文を私が すっかり忘れてしまい思ったように進みませんでした。結局、@kyon_mmさんにお教えいただき、分かるようになりましたが、少し時間をロスしてしまいました。@kyon_mmさんありがとうございます。この反省点は二つです。
  1. 予習するなら、要求される環境でちゃんとやっておく。
    2. 今回、IntelliJもちゃんとやっておくべきだったなと思いました。
  2. ワークショップ中であっても、落ち着いて行動する。
    3. 私が忘れてしまった内容はSpockのトップページを見れば一目瞭然の内容で、その時冷静にググってれば割と早くSpockで始められたと思います。
目の前にいた@hideokuさんにも質問させていただきました。ありがとうございました。

今回の演習課題
Spockについて@kyon_mmさんに教えて頂いたおかげで、TDDBCに集中できました。用意されていた課題は、「飲み物自動販売機」プログラムをTDDを用いて書いていくものでした。二人でしながらプログラムを作っていると、これが 「楽しい」と純粋に思えました。それぞれが個人の主張を貫き通すわけではなく、議論しいい方を採用しながらプログラムを作る、こういう経験はなかなかできません。とてもいい経験になりました。TDDについては、最初はテストファーストを意識していましたが、途中から「最初からグリーンバーが見える書き方」に移行してしまった私に対し、ペアプロ相手の@yoshi_naoyukiさんは冷静に「テストファースト」を考えておられました。これは、 @yoshi_naoyukiさんの長所ですね。

私たちはステップ２の途中で、タイムアップになりました。あまり進みませんでしたが、とにかくあっという間に感じるほど、集中できたし、楽しい時間でした。

関さん（@m_seki）講演

関さんのお話は、TDDをより進化させるお話でした。
  • 手動テストもいいよ？
  • たまには、デストロイしてみては？
  • レガシーコード改善ガイドを読もう。

TAさん達のパネルディスカッション

  • TDD行う上でよく詰まるところは？他のコードやライブラリが必要な時の対処。
  • DB接続周りの対処。本物の環境を使ったり、もしくはDBスキーマの変更が激しい場合はmockでできるだけがんばるという意見も。
  • ログを吐き出すコードを書き、そのログを自動で評価する。
  • テストの効果の見える化が大事！

まとめ

Twitterのまとめ:TDDBC大阪 1.0 & 2.0
いやー、勉強になりました。主催、講師のみなさん、ありがとうございました。グリーンバンドを購入したので、新しい職場の机の上に置きました。この経験を元に、テストファーストの考え方を考えながら仕事をしていきたいと思います。 「acts_as_professional」

関連書籍

JGGUG名古屋Groovy DSL勉強会　参加してきた #jggug

Groovy 勉強会 DSL

５月３０日に 株式会社ニューキャスト様で行われた JGGUG名古屋Groovy DSL勉強会に参加してきました。

事の始まり

この勉強会は、以前モスクワにて行われた Cloud Foundry Open Tour 2012のモスクワ開催*1で、Groovyのproject managerであるGuillaume Laforgeさんが発表された、「Going to Mars with Groovy Domain-Specific Languages」について読み、考えたり、コードを作成してみたりする会でした。ニューキャストの方達は、数人でモスクワまで言ってお話を聞かれたみたいですね。 すごい行動力です。

スライド

Going to Mars with Groovy Domain-Specific Languages

DSLについて

まず、私に取っては 「DSLとは何か？」からスタートしなくてはなりませんでした。今まで何回かネットで調べたことはあったのですが、何となくなイメージしかつかめておりませんでした。ですが、上記のスライドと、@tyamaさんにいろいろと教えて頂いたおかげで、DSLについてある程度の理解をすることができました。まず、それを説明します。

DSLを一言で言うと、 ある環境（ドメイン）で利用される、記述者の理解しやすい形で記述できる固有言語と言えます。その中にはいくつかのポイントがあります。
  • プログラムの都合で書かなくてはならない記述をできるだけ排除する。*2。
  • 自然言語や音符など、中身にはこだわらない。
  • 場合によっては必要のない部分にアクセスできない様に、セキュリティ対策を行う。
そうやって考えると、私たちプログラマの回りにはDSLが多くあります。SQLやHTML、XMLなんかもその類でしょう。おもしろかったのは、音楽で使う楽譜もDSLといえるようです。*3上記のスライドの例では、 「火星を探索するロボットに対するDSL」について話がされています。その中でも、 「プログラム上必要なコード」を徹底的に排除し 「DSLとして必要なコード」だけに徹底的に絞っていくお話になっています。「Groovyのこんな機能を使ってこういったDSLを動かせるプログラムを作成できますね。」というスライドになっています。

DSLを実現するためのGroovyのテクニック

  • GroovyShell
    • 上記の資料の４７スライド目あたりに解説がありますが、DSLを読み込んで実行する際に、GroovyShellを使って、あらかじめ必要な関数等をバインドしておき、DSLであるGroovyスクリプトを実行する事ができるようです。
  • Compilatoin customizer
    • コードのコンパイル時に様々な事を織り込んで動作させる仕組みの様です。大きく分けて以下の３つに分かれます。
    1. Import customizer
      2. 上記スライドの５３スライド目あたりに説明がありますが、コンパイル時に使用するimport対象のクラス等をimportする書式を外に出せるようですね。
    2. AST transformation customizer
      3. 上記スライドの５４スライド目に説明があります。GroovyにはもともとAST変換という機能が備わっていますが、その機能をコンパイル時に織り込む事ができる様ですね。例では、Loggerを織り込んでいます。
    3. Secure AST customizer
      4. 上記スライドの５９スライド目あたりに説明があります。これは、すでにあげた 「場合によっては必要のない部分にアクセスできない様に、セキュリティ対策を行う。」に値します。５９スライド目の例では、Groovyの言語仕様の一部である closureの使用を制限しています。また、演算子や使用できるクラスを制限したりして、DSLとして使用で切る部分だけに絞ることができています。 必要な機能ですね。
  • Command chain
    • 上記スライドの１１２スライド目あたりに説明がありますが、Groovy1.8からできるようになった、 ドットや括弧を省いて、オブジェクト.メソッドのような構造を表すことができる機能の様ですね。この説明では、スピードを指定する際に使用し、DSLとしては不要なドットや括弧を省いています。
スライドはまだまだ続きますが、以降はスライドの説明に移譲します。

まとめ

何よりDSLの考え方がはっきりしたのが、私にとってはありがたい話でした。なんとレベルの低いことか^^;集まられていた皆さんに聞いて見たところ、DSL自体は何かのプログラムの書籍などから生まれた物ではなく、一般常識と言えるレベルの様です。*4また、Groovyの柔軟さもよく分かりました。

参考

*1:直リンク張りたかったけど、ページが４０４エラーになっている。20120531現在

*2:そういった記述がなくても動くようにする

*3:コンピュータ的には、midiの方が理解しやすいかもしれません。

*4:自分、まだまだっす。

継続的デリバリー読書会２ 参加してきた #CDStudy

勉強会 開発ライフサイクル

2012年5月20日に行われた、 継続的デリバリー読書会２に参加してきました。