コードを共有する為のリポジトリを作る目的は2つあります。まずは、リポジトリ本来の目的であるコードの共有です。TDDでは適宜リファクタリングもしていくので、安全に作業をすすめる為に、きちんと作業を記録するのが大事。もう1つはお互いに慣れた開発環境で開発をするためです。1台のマシンだと、OSからキーボード配列から様々な好みが違っていると開発効率が落ちてしまう(最悪宗教戦争に発展する)ので。

ペアプログラミングを行う（ドライバ編）

自分がこれから何をするかをナビゲータに「宣言する」
目の前の課題解決に集中する

何をするかを宣言するのは、ナビゲータの方が「この進路で間違ってないよね？」を考えやすくする為です。この宣言があるとナビゲータの方から有益なフィードバックが得られやすくなるはず。「このテストケースをパスするように、テスト対象クラスにｘｘｘのような変更を加えます」とか。

目の前の課題解決に集中するのは、キーボードを持っている自分が「やります」と宣言した事を解決できるのは自分だけですし、プロダクト全体の処理を破壊しないか等の全体を見るのはキーボードを持っていないナビゲータ側の方が適しています。ナビゲータの方を信頼して、目の前の課題解決だけに集中しましょう。

ペアプログラミングを行う（ナビゲータ編）

ドライバに意見を言う時は、具体的手段ではなく目指すゴールを伝える
ディティール(コンパイラが指摘してくれるようなタイポとか)は見ない

目指すゴールを伝えるのは、さっきのドライバ編とも同じ気がするのですが――例えば、実装中のクラスがイミュータブルにできるのにミュータブルになってしまっているのを発見した時に、「インスタンスフィールド全部にfinalつけてください」というよりも「このクラスをイミュータブルにしましょう」の方が意図が相手に伝わりやすいですよね。

ディティールは見ないのは、遅かれ早かれ画面を見ているドライバが気づくような問題(IDEがコンパイルエラーを出すとか)に二人がかりでやるのは旨みがないので…。ドライバが見ていない全体的な部分を見ましょう。「intがIntになってますよ」とか言われたらイラッとする気持ちもありますしｗ。

＃さすがに、変数名にhogeとか使いだしたらおいおいって言っていいと思いますけどｗ

お互いに相手を信頼して、別の役割を任せている、を意識するのが良いかと。

ペアプログラミングの終わりに

最後の挨拶

ペアプログラミングの終わりには、相手とのご挨拶を忘れずに(今回のパートナーとまたペアプロしたいなーと思ってもらえるようなのがベストかも)。

まとめ

色々書きましたが、こういう辺りに気をつければよいのではの箇条書きを全部まとめ。

相手へのリスペクトを持つ
自分へのリスペクトも持つ
パートナとの挨拶
ドライバ・ナビゲータの入れ替えタイミングを決める
コードを共有する為のリポジトリを作る
自分がこれから何をするかをナビゲータに「宣言する」
目の前の課題解決に集中する
ドライバに意見を言う時は、具体的手段ではなく目指すゴールを伝える
ディティール(コンパイラが指摘してくれるようなタイポとか)は見ない
最後の挨拶

10個か〜。もう少しコンパクトにまとめたかったような

2013-11-10

TDDBC 横浜3rd スタッフ振り返り

10月23日(水)に、TDDBC横浜3rdのスタッフさん＋t_wadaさんが品川に集まってスタッフの振り返りを行いました。

事前のスタッフ打合せも品川に集まる事が多くってその時から冗談交じりに「打合せ場所はアンミラ？」というやり取りがありつつも、別のファミレスを使っていたのですが「振り返りはアンミラで開催します！」と主催者様の鶴の一声でアンミラに。

2013-11-06

Jenkinsでハマったりした

今、職場でビルドサーバを再構築しています。(これまで使っていたビルドサーバ用PCのレンタル期限が切れてしまうので、別のマシンにお引越し。レンタル期限切れって…ｗ)

FlashやAndroidアプリもビルドできるようにして、Macのスレーブを使ってiOSアプリのビルドもできるようにもしたので、旧JenkinsサーバからJobを移植。

こういう時はJobImporterプラグイン便利だよなーと思いつつ、事件発生。

ローカル環境でも旧Jenkinsサーバでも動いていたジョブが、新サーバだけで失敗するのです。失敗しているのはDBまわりのテスト。

JUnit実践入門で書かれているDBテストの仕組みを参考にして作っていたテストが「スキーマが見つかりません」というエラーを出して失敗。

色々調べていたらローカル環境では毎回h2サーバがデフォルトの9092ポートで起動していたのに、サーバ環境では毎回起動するh2サーバのポートが違っている。

これを手がかりに調べていくと、サーバ環境では9092ポートを別のプロセスが使っていることが判明。

で、ついに原因を特定。新ビルドサーバを構築するドサクサに紛れて動かしていたgitbucketが内部でh2データベースサーバを使用していました。gitbucketを止めてみると9092ポートが未使用の状態に戻り、テストも成功するようになりました。

こういうトコでも実行環境に依存して成否が変わってしまう脆弱なテストが生まれるんだな〜と学びました。

2013-10-26

第2回ゆるぎー初めての構成管理 #yuru_gee

10月22日(火)に渋谷の21Cafeさんで開催された第2回ゆるぎーに参加しました。

「初めての構成管理」のお題で高安厚思さんのお話＆実際にバージョン管理ツール(SubversionとGit)を使ってみるハンズオン。

お話

資料は、こちら。

20101022 構成管理勉強会資料 from Atsushi Takayasu

SubversionやGitのようなソフトウェア構成管理ツールと構成管理プロセスは表裏一体の関係があって話が混ざりやすいので、プロセスの話か、ツールの話かを区別しなきゃダメとの事。

プロセス(目的)とツール(手段)を混同する、って自分もよくしてしまうのでとても大事。

ハンズオン

TortoiseSVN/Gitを使うとのことだったのでVirtualBox上のWindows7にTortoiseSVN/Gitをインストールしていってたのですが、重たかったのでMacのコマンドラインから操作しようとして手が止まる。

そうか、svnをコマンドラインから扱えないのは…ずっとTortoiseSVNさんに甘やかされてきてたからなんやな(；´Д｀) #yuru_gee
— あさの (@uasano) 2013, 10月 22

振り返り

職場のリポジトリ(Subversion)のコミットログを見ていると、他の方のコミットが不思議(複数のEclipseプロジェクトにまたがるコミットをしていたり、コミットコメントが3日の間ずっと同じだったり)で、この場でその不思議感を解消するヒントが得られたらな〜と思っていました。で、私が「こう使うんだ」と思っているSCM像と、他の方が「こう使うんだ」と思っているSCM像が何の会話もせずに一致するわけないよねと気づいたので他の方の思いを教えてもらおうと思った次第。

参考

Gitの操作練習に良いと思っている BitBucket 無償利用の範囲でプライベートリポジトリが作れるので、白鳥が人知れず水面下で(ry のような感じで使えます。
GitのGUIクライアント SourceTree Windows7以降、Macに対応したクライアント。

べっ、別にatlassianさんのステマとかじゃないんだからねっ！

2013-10-13

TDDBC 仙台 the 3rd に参加しました。#tddbc

先週のTDDBC横浜3rdの熱狂も冷め切らぬうちに(あれがまだ1週間前の出来事とは思えない)、TDDBC仙台 the 3rd に一般参加者として参加させてもらいました。

場所は違えどTDDBCはやはり大変熱いイベントで、楽しかったです。スタッフの皆様、参加者の皆様、会場を提供してくださったデータコム株式会社様ありがとうございました。

横浜3rdとの違い(言語編)

横浜3rdは、需要？人気？のある言語(JavaとRuby)の参加者さんが多かった印象(全体の1/3がJava, 1/3がRubyくらい)だったのですが、仙台 the 3rdは、色々な言語にバランスよく分散した感じでした(C#, Ruby, PHP, Java, Python, Objective-C,Groovy, Kotlinだっけ？漏れてたらすみません...)。

なので、コードレビューは「いろんな言語でのユニットテストの作り方」が眺められる感じの内容でした。横浜ではサポートできなかった言語の話が聞けたのは良かったです。特に興味深かったのはObjective-Cチームのコードレビューでした。(多分9月に)新たに公開されたXCode5.0系でサポートされたテストフレームワークを使ってテストを書かれていて、1つのテストメソッドの中で複数のassertを記述した時の挙動が興味深かったです。xUnit系の伝統？では何か1つのassertが失敗したら、以降のassertは評価せずに「テスト失敗」と扱われていたのが、このテストフレームワークでは全てのassertが評価されてその上で失敗していたassertが何か表示されるようになっているそう。

横浜3rdとの違い(課題編)

課題はすでに公開されているので興味のある方は devtesting を覗いてみてください(10月14日にメンテが入るそうなのでしばらく繋がらないかも)。

この課題のミソは、最初は課題1しか公開されておらず、課題1をクリアしたら課題2が公開されて…というスタイルを取っていたことでした。そうすることで課題1だけでの最小限の実装と、課題2に取り組む際の最低限の実装に相違と重複が発生するのでそれによってリファクタリングが必要になってくる、という非常に良い課題でした。 Rangeオブジェクトをサポートする言語ではRange使用禁止の縛り、の前提があったとはいえ、実によく考えられて作られていた課題だな〜と感心することしきり。

自ペアが取り組んだ事

今回は、Groovyで参加することになりました。で、同じく首都圏から参加を表明していた @terahide27 さんとTDDBC仙台 the 3rd 前々日にお会いした時に「プロダクトコードはJavaで書いて、テストコードはGroovyで書くと、会場にいらっしゃるJavaで参加されている方にGroovyの魅力が伝わるんではないですかね〜」のような会話をしていました。

まさか本当にペアプロするとは思ってなかったのですが(w)、そうなったので実際にプロダクトコードをJavaで書いて、テストコードはSpockで書いていました。

JavaのコードのテストがGroovyで書けるよ！を実践したのは良かったと思うのですが、反省点としてはGradleを使ってテストを実行していたことです。今、Javaのプロダクトコードにテストが無くて困っている・書こうとしている環境ってきっと、AntやMavenを使っている環境の方が圧倒的な気がするので…。

共有したコードは github にUPしました。(次にペアプロする時は開発中からgithub使おう…）

今回の反省

二度寝してしまって、新幹線の時間に間に合わんくなってしまった(´Д⊂ヽ
— あさの (@uasano) 2013, 10月 11

3連休初日の午前中で指定席が空いていなかったから、朝早い時間のはやぶさグリーン車の切符買ったのに！

2013-10-08

TDDBC 横浜3rd に参加しました #tddbc

2013年10月5日(土)に開催されたTDDBC横浜 3rdにスタッフとして参加しました。

togetterまとめ：

2013/10/05 TDD Boot Camp 横浜 3rd #tddbc - Togetter

内容は他の方が既にたくさんポストしてくださってますし、自分自身

会場にいるのにエア参加の勢いですみません(´Д⊂ヽ #tddbc
— あさの (@uasano) 2013, 10月 5

な感じだったので、チラシの裏チラシの裏。

裏方の舞台裏(それなんて表？)

TDDBC横浜3rdでは会計を任せてもらっていて、お金の出入りがありそうなトコには大体関与していました。予算案立てたり、お弁当屋さんに宅配を依頼したり、細々した買い物したり、当日はみなさんから参加費をいただいて、それまでの出費から懇親会のピザにどれだけ使えるか決めたり。当日の朝から午後ペアプロの1回目のチームの発表があるあたりまではそっち方面の仕事だけやってました。

唯一悩んだのは、当日のお弁当の発注数です。当日の天気が悪いらしいという情報で「当日キャンセル増えそう…大量キャンセルでたらどうしようgkbr」って思ってたら、大量にお弁当が余る悪夢を見たくらいですｗ

チラシの裏に何を書きたかったか

私は、TDDBC横浜2ndの卒業生で終わった直後に「次回はスタッフで協力したいけど、自分の技術力で何か協力できるかな？」と思った口です。それが、1年後のTDDBC横浜3rdでスタッフとして仕事を任せてもらえたわけです。

つまりはTDDBC横浜3rdに参加された方で、去年の私のような気持ちになった方がいらっしゃればぜひ手を上げてください。貢献できる場は絶対あります。(ペアプロデモを担当されたお二人もTDDBC横浜2nd卒業生でしたね)

TDDBCをスケールアウトさせるということ

裏方経験者もTDDBCをスケールアウトさせる為には必要ですよ！

最後に

spockのデータテーブル使ったテストは @Unrollアノテーション使うと、失敗した時のメッセージがわかりやすくなって良いですよ！。

G*ワークショップZ May 2013 - Spockハンズオンの資料が日本語でわかりやすいので興味を持った方(みなさん興味持ちましたよね？)はこちらのリンクをどうぞ→ yamkazu/spock-workshop · GitHub へ

本当の最後に(本当に大事なことを書き忘れてしまっていたので追記しました)

参加してくださったみなさん、主宰のせとさん、スタッフのみなさん、そして会場を提供してくださったアジャイル開発 | Enterprise Java | 株式会社アットウェアさん、楽しい時間をありがとうございました！

ケロSE

ケロいSEが日々思う事を書きます

第三回ゆるぎー　はじめてのTDD に参加しました

余談

ペアプログラミングのやり方

ペアプログラミングって何？

ペアプログラミングを始める前の心構え

ペアプログラミングを始める時