サテライト #tddbc 佐賀に参加

イベント Groovy TDD

TDDBC in Tokyo 1.5の佐賀サテライトに参加しましたよ。
というわけで、いつもどーりざざっとした感想をば。

午前中

まず集まったメンバーの誰もが言語を考えてきていないというのが既に色々と大丈夫なのか、みたいな状態からスタート。
まぁそこまではいいとして、ノリで「じゃあGroovyで！」と言っていたら全員Groovyでやることになるという・・・まさにカオス。
他のメンバーはGroovyでコードを書いたことがないようだったので、Ust見ながら環境構築などをしていたようです。


ちなみに

に吹きそうになった。そんな私も今のところreset派。

お昼休憩中

のんびりと1.6の募集開始。
抽選方式のほうがいいのはわかっているのですが・・・何しろSCMBCとの掛け持ち*1で色々と厳しいので、今回はご容赦ください。
1.5と1.6両方に参加される方は・・・きっと1.7とか1.8とか1.9を開催してくださるのですね！！(無茶振り)

演習雑感

Groovy+Spock、ついでにGradle、Emacs、Gitで挑みました。
今回の隣の人はid:naokirin氏、いつもお世話になっております。


隣の人感想：サテライト #TDDBC 佐賀 に参加してきました - What is it, naokirin?
コード：https://github.com/pocketberserker/tddbc_saga


さて、彼の感想を見ると

  • Groovyのクロージャ辺りで苦しむ
  • TDDのリズムが悪かった
  • 設計の時間を取るべきだった

とあるので、そのあたりについて個人的なことを書いてみる。

クロージャ

eachに渡すクロージャ中にretrun書いてもそりゃeachの処理自体は終了しないよね、と翌日気がついた。
ああいう時はfor使いますよねはい。
(grepなんて書いたのは誰だ・・・私だ！)

TDDのリズム

私からすれば問題ないスピードかな、と思っていたり。
というのもGradleやGitの操作が入っていたのと、Gradleについては--daemonなんてあったのね、と知ったのが翌日あたりだったから。
Gitについては私のgit nowのタイミングが他の人と結構違ったりする影響もあるかも。
Gradleは・・・テスト失敗のときにどうやって詳細結果をコンソールに表示させるのだろう？
(そこからかよ！)

設計に時間を取る

これはわりと同感だったかなと。
ただ、やりすぎると作業時間自体が減りかねないので、今回は別にいいやと思っていたのも事実。

個人的になんとかしたいところ

Spockの記述がJUnitみたいになってしまった・・・

全体雑感

別ペアはGroovy+JUnitだったらしい。
「よくわからなかったらJavaっぽく！」でいけるのがいいですね！
あと、「Groovyイン・アクション」と「プログラミングGROOVY」を持っていって正解だったと感じた。
この２冊があるだけで気持ちがいくらか楽・・・な気がする。

反省点

寝不足の影響で作業効率がかなり低下していた。
だめ、ぜったい。

最後に

id:cubeonさん、naokirinさん、Hyuutaさん、いつもありがとうございます。
TDDBC in Tokyo主催者の@HIROCASTさんや参加者の皆様、サテライト中はありがとうございました。遠隔地でtddbcを見るというのもなかなか新鮮ですね。

*1:あまり手伝えていないけど