アジャイルサムライ読書会 横浜道場 特別編「ワールドカフェ再び」 に参加して来ました #agilesamurai #横浜道場

アジャイルサムライ読書会　横浜道場　特別編「ワールドカフェ再び」
http://yokohama-dojo.doorkeeper.jp/events/2148

2013/01/22 アジャイルサムライ読書会　横浜道場　特別編「ワールドカフェ再び」#agilesamurai #横浜道場
http://togetter.com/li/443871

はじめに

今年はじめてのアジャイルサムライ読書会に参加して来ました。

第一回目もワールドカフェだったのですが、それ以降何度か体験して面白かったので、このメンバーでやるとどうなるのか楽しみでした。

ディスカッション

ディスカッションのテーマはいろいろあったのですが、意見を出しやすいテーマを選んでみました。
選んだテーマは、「アジャイルのプラクティスで外せないものは何か」でした。
その結果は以下のような感じになりました。


それぞれで外せないものは、あるのですがいろいろと関連性が見えてくるのが興味深い内容でした。

次のテーブルでは、型を破るタイミングとどう破るのかについて話し合ってました。


チームのスキルセットによっては、型を形作るまでの過程が険しいのだと感じました。

おわりに

やはり横浜道場はホームなのだなと改めて思った。今年もよろしくお願いします。 #agilesamurai #横浜道場
— とーますさん (@grimrose) 2013年1月22日

今年は、ハッカソンを中心に手を動かすような勉強会に参加して行こうと思います。
聴講形式では、知った気になって何も身につかないのは、この一年で実感したので減らしてみます。

横浜道場のスタッフの皆様、参加者の皆様、会場を提供してくださった株式会社アットウェア様ありがとうございました。

今年もよろしくお願いします。

Yokohama.groovy #11 に参加して来ました #yokohamagroovy

Yokohama.groovy #11
http://connpass.com/event/1604/

2013/01/20 Yokohama.groovy #11 #yokohamagroovy
http://togetter.com/li/442240

はじめに

今回から、もくもく会形式になったYokohama.groovyに行って来ました。
去年までは、「プログラミングGROOVY」の青い本の読書・写経会だったのですが、ひと通り終えてしまったので、これまで学んできた事を自分で課題を見つけてやっていこうということになりました。

もくもくと

Gradle、JPA、JAX-RS、Gebを採用してRESTの勉強をしてみようと思ったので、課題としてみました。
途中まではJavaで書いていたものがあったので、すべてGroovyで書きなおしてそれから始めました。
レポジトリはこちら→https://github.com/grimrose/gradle-jetty-jndi-sample

次の目標は、jettyの設定ファイルをgroovyで生成できるようなのを作ってみたいと思います。
その後は、CDIの参照実装であるweldを試してみようと思います。

おわりに

これまでで参加者が一番多かったYokohama.groovyでした。
今後もいろいろな人が参加してもらえるような場所にしていきたいなと思っているので、今年もYokohama.groovyをよろしくお願いします。

主催の@shinyaa31さん、参加者の皆様、横浜タネマキさん、ありがとうございました。

次回も、よろしくお願いします。

『JUnit実践入門』写経・実践会 in 横浜 #2 に参加してきました #junitbook

『JUnit実践入門』写経・実践会 in 横浜 #2
http://connpass.com/event/1557/

2013/01/12 『JUnit実践入門』写経・実践会 in 横浜 #2 #junitbook
http://togetter.com/li/437795

はじめに

前回の写経・実践会のレポートはこちら→『JUnit実践入門』写経・実践会 in 横浜 #1 に参加してきました。 #junitbook

前回に引き続き参加して来ました。
今回は、「Part.2 JUnitの機能と拡張」が対象でした。
初めの方の参加条件として写経のレポジトリを登録するというのがあったので、
年末にやってみましたが第8章までしか出来ませんでした。
出来れば全てこなしたかったので、残念です。

写経のレポジトリはこちら→https://github.com/grimrose/junit-boost-camp

JUnit Boost Camp

第6章のディスカッションの時にうまく説明出来なかったので、この場を借りて言いたかった事を説明してみます。

対象のクラスのメソッドに対するテストと対象のクラスの状態をテストするためのテストが混ざっているような場合があると思います。
そんな場合@Enclosedを使うことで、テストを構造化出来るようになりました。
static classにすることで、明示的にお互いに依存しないように記述出来るようになります。
例えば、JUnit4.xの形式で書かれていたテストを構造化するのであれば、以下のような手順で出来ます。

• 「@RunWith(Enclosed.class)」を追加する。(import句も)
• 「public static class コンテキストの名称など {}」を追加する。
• 内容をそのままstatic classに移動する。

このように新しいstatic classを作ってテストを追加することで、今までのテストも構造化することが出来ます。
新しいフィクスチャが必要になった場合も、新しいメソッドに対してテストを追加する場合も、必要に応じて追加することが出来ます。

JUnit3.xの場合は、TestCaseを継承しただけのテストであれば、setUpとtearDownなどをそれぞれ修正することで対応出来ますが、TestCaseを継承したテスト用の基底クラスを使っている場合は、いろいろと対応しなければならないことが多いので、優先順位とコストなどで判断してください。

もくもくと

後半はGroovyで書かれたテストにJUnitとSpockが同居することが出来るのか試してみました。
参考にさせて頂いたのは、@irofさんのこちらの記事です。→GroovyでJUnitなテストを書くときの注意点……なんて無かった #gadvent2012
同居させるために、Spockのversionを0.6から1.0へ上げました。
0.6では出来ないということに気づいたのは終盤だったので、ちょっと勿体無かったです。

おわりに

今回は、対象範囲が広かった為か終盤はスタミナ切れしてました。
次回は、適度につまめるような何かしらスイーツを用意して見たいと思います。

一番の収穫としては現場でも使えそうな@Ruleや@RunWith(Categories.class)を知ることが出来たので、活かして行きたいと思います。

主催の@shinyaa31さん、参加者の皆様、横浜タネマキさんありがとうございました。
次回もよろしくお願いします。