同じ画面をシェアして、作業する機会があった。これが中々おもしろくて、相手の作業が刻々と見えるから、何をしようとしているかわかりやすいし、口では伝えきれない事まで伝わるので、素早い問題解決ができる。口でどこがまずいか、ということを説明できない初心者には最適だろうし、上級者同士なら、よりよい議論ができるはずである。これは、ペアプログラミングの利点そのものである。ペアプログラミングでは、同じ画面をのぞき込んで対話しながら作業するわけだが、マウスの動きやキーボードの叩きかたなんて見ることはないので、実際には画面だけみている。ようなソフトで再現できるわけだ。操作の排他制御をもうちょっと手軽にできるとよいな、と思った。今回は、babieさんの取り計らいで「ポジションペーパー」方式が導入され、自己紹介がスムーズに。自己紹介だけじゃなくて、十数人くらいの単位で何か議論する際に、固定的なメディアである紙の上に各自のスタンスを述べることで、議論すべきポイントが明確になりそうだ。以外にも、こういう点で期待している。自己紹介も終わり、勉強会の方針について決める。京都の勉強会が存続してよかった。以外はちょうど使ったばかりなのでタイムリー。ストヤンさんが、会社でのサーバ構成、デプロイ環境を発表して勉強会は終わり。部屋を片付け、懇親会へ。懇親会では、babieさん、高木さんに挟まれ、向かいにはcuzicさんという恵まれた環境で、rails話で盛り上がったりした。読み倒している感じで、何か言うと「ああそれは、320ページくらいに書いてあった」といって周りを驚きの渦に。言えばポンというテンポのいいレスポンスはこういう集まりならでは。ページごとにキーワードをメモっておくのはいいな。取り入れたいけど、本に書き込むのは気が引ける。これ以上書くと日記になってしまうのでこの辺でやめ。眺めていたら、こんなページ(TDDinRails)を発見。風の機能を追加するという小技が紹介されている。要は、テストクラスのメソッド名を説明的に書いて(test_should....)、テストを書くと同時にクラスの仕様のリストまで作成してしまおう、というやり方のようだ。login...という使い方ができるようになる。これならテスト駆動開発が楽しいものになりそうだ、と心の中でわくわくした。test_ログインに成功したらsessionにuserが保存される。...endともできる。これは良さそうということで、早速後輩に勧めたら、テストコードが書きたくてしょうがなくなったようだ。テスト駆動開発定着までの近道として参考になる。