kanazawa.rb meetup #16 に参加しました

12/21にkanazawa.rb meetup#16が開催されました。 今回のテーマは「意識高いもくもく会 in DMM.com Labo 金沢事業部」でした。 さらっと途中参加(と若干の遅刻)しましたが、ちゃんと発表もしてきたのでレポートを書きます。

発表した内容

前回レポートを書いた GDCR in Fukui 2013に参加した感想 を軸に話してきました。スライドよりもレポートの方が資料性が高いのでそちらを参照してください。

今回の発表で伝えたかった内容は次の3つです。

  1. Coderetreat面白い
  2. ぶつかり稽古でTDDを始めよう
  3. 一緒にペアプロやりましょう

Coderetreat面白い & ぶつかり稽古でTDDを始めよう

ブログに書いた内容です。Coderetreatとは何かということろから始めて、当日のセッションの様子と得られた学びについて話しました。twitterの反応的には、そんなに伝わらなかったのかな… 自分の学びを話すだけじゃなくて、聞き手に伝わりやすいCoderetreatの面白さを盛り込んだ方が良かったのかも、と思いました。

一緒にペアプロやりましょう

今回一番発信したかったコトです。Coderetreatの経験から、もっと色んな人とペアプロを通じて学びたいという気持ちがあります。 これはkanazawa.rbの先輩エンジニアの胸を借りるしかないなと。(ぶつかり稽古的な意味で)

それから、前回のmeetupで@wtnabeさんが「それぞれの思うkanazawa.rbの良さにコミットする」ということをおっしゃっていました。僕はkanazawa.rbでRubyを書く人がもっと増えて欲しいなと思っています。「Rubyらしい」コードとは何だろう、どうやったら書けるんだろうということに関心があります。kanazawa.rbでペアプロすることで、Rubyを書く人が増えて、Rubyらしいコードについて議論できたらいいなと考えています。

マジメな感じになっちゃいましたが、もっとカジュアルにペアプロ出来たら、それはとっても嬉しいなって、思います。もっとも、まず自分が"ペアプロ慣れ"しなきゃイケナイんですが!

途中参加だったのもあって残念ながらmeetup#16では叶いませんでした。次回は誰か捕まえたいと思います!

印象に残った話

@izawaさんのimap-notifyの話

izawa/imap-notify

メールをfilterしてtriggerでactionする。DSLの使いどころがカッコいいなって思いました。 IFTTT使ってたんですが自由度が低くて困っていました。自分でDSL書くっていうのもありですね!

@mi35coくんのK.I.Toolsの話

tknhs/K.I.Tools

金沢工業大学の学生生活を便利にするChrome拡張の話。ちゃんとchrome storeで公開していて、顔の見えないユーザーに使ってもらっているというのは素晴らしいこと思います。 あと、会場のウケがかなり良くて、やっぱエンジニアコミュニティだなって思いました。

Global Day of Coderetreat in Fukui 2013 に参加しました

12/14に福井で行われたイベント「Global Day of Coderetreat in Fukui 2013」に参加してきました。 kanazawa.rb meetup#15に参加されていた@kompiroさんがファシリテーターをされているイベントです。 あの永和システムマネジメントさんが会場ということで、中に入れるのも楽しみでした!

Coderetreatってなに

Coderetreatとは、ざっくり以下のようなルールでペアプログラミングを行うイベントです。

  • コンウェイのライフゲームを実装する。
  • 45分/1セッションで、複数回のセッションをやる。セッション毎に成果物(コード、メモ)は破棄する。セッション毎に必ず異なるペアを作ること。
  • 1セッション毎に15分の振り返りを行う。
  • よいコード、よい設計を作る練習をするのが目的。かならずしも完成させる必要はない。

Global Day

昨年のCoderetreat in Fukuiは単独イベントだったようです。今回はGlobal Dayということで、世界中の都市で同時開催している会場のひとつになっていました。 海外の会場とハングアウトを繋いで手を振り合ったりして、Coderetreatの空気を共有している感がすごく良かったです。

参加するにあたっての目標

CoderetreatではTDDが推奨されています。テストの重要性は理解しつつも、テストファーストと言われるとなかなか実践出来ていない現状があるので、次3つの目標を立ててから参加しました。 経験者の方教えてくれくれちゃんです。

  1. TDDなコーディングと、普段のコーディングの両方やってみる
  2. がっつりTDDやってる人にナビゲーションして貰う
  3. TDDのメリットを実感する

当日

セッションでやったこと

session#1

TDD未経験な金大の学生さんと組みました。初回なので普段のコーディングスタイルでやろうということに。こんなインターフェースが必要だよね、内部表現は二次元配列にしようか、フィールドのはじっこの扱いどうしよう、みたいな話をしてざっくり設計、8割くらい実装したところで終わり。お互いライフゲームについてあまり予習していなかったため、問題を整理するためのセッションとして有意義だったと思います。

session#2

愛知から来られた社会人の方と組みました。休憩時間中にRubyでやりたい人居ませんかと声をあげたところ乗っていただけました。TDDでコーディングしてみたい旨を伝えると、RSpecでのTDDをナビゲートしてもらえることに。RSpecの書き方やrubyのゆるふわいい感じなコーディングが勉強になりました。

セルの生死を表す定数を定義するのに、Stringオブジェクトを拡張するというアイディアが面白かったです。最初はSymbolをひも付けていてエラーが出たのも、なるほどsingletonだからかという気づきになりました。

Alive = 'alive' # :alive x
Dead  = 'dead'  # :daed  x

def Alive.alive?; true;  end
def Dead.alive?;  false; end

もうひとつ、まずはGemfileから書こうとしたらbundle gem使えばいいんじゃない?と言われて、確かにと思いました。git initしてくれるし-tすればRSpecも入るし、細かいファイル生成してくれるし(README)、小さなコードでも使うようにしようと思います。pry or bundle gemみたいな。

session#3

おやつスポンサーでもある(ありがとうございます!)ナンバーフォーの方と組みました。session#2で書いたコードを手に馴染ませたくて、破棄したコードを思い出しながらコーディングしていました。あとは、世代交代のルールをシンプルに定義しなおしました。Javaメインの方に、ruby面白いですねと言ってもらえたのが嬉しかったです。

世代交代のルールは、注目しているセルの状態、その周囲の生きているセル数をパラメータとするとこんな風に書けます。

def rule(alive_neighbours_count, current_state)
  case alive_neighbours_count
  when 2
    current_state # Alive or Dead
  when 3
    Alive
  else
    Dead
end

session#4

@kompiroさんと組みました! 実装する役とテストを書く役でやろうと提案していただき、実装役をやりました。このペアプロ手法は、ping-pong(ピンポン)または「ぶつかり稽古」と呼ばれているらしいです。具体的には以下のステップでやっていました。

  1. 全体の設計(クラス、オブジェクトの関係)をざくっと共有する.
  2. 実装するクラスのインターフェースを話し合って決める.
  3. テストコードを書く. 実装役はナビゲーター.
  4. テストを通す実装をする. テスト役はナビゲーター.
  5. 2に戻る

これがかなり面白かったです。役割が分かれたことで、TDDをやる上で大きな負荷になる(と思っている)「実装する時とテストを書く時の頭の切り替え」がそんなに要らなくなることが大きいんじゃないかと感じました。 実装役とテスト書く役を交互にやっていくうちに一人で回せるようになるならば、こんなに良い方法は無いと思います。

ともかく、ストレスなくTDDできてるということと、一人では辿りつけないところにいる感じとがあって、ペアプロ最高!って言いたくなるセッションでした。

session#5, 6

金大の学生さんたちとひたすらping-pongしていました。テスト役をやったり、Gitを使って並列で作業してみたり。ここら辺でかなり疲労がきていてgdり感あったかも...

まとめ

  • bundle gem使おう
  • RSpecちょっと書けるようになった. contextとletでDRY.
  • ping-pongかなり良い!

感想

6回のセッションで、2つの目標は達成できました。

  1. TDDなコーディングと、普段のコーディングの両方やってみる
  2. がっつりTDDやってる人にナビゲーションして貰う

で、その実践を元に「TDD(テストファースト)のメリットを実感できたかどうか」というと少し弱い手応えです。 ストレスなくテストファーストで書けるようになれば、コーディングミスをした場合の問題の切り分けが楽(細かくテストするため)だろうなとは思います。セッション中にあまりリファクタリングする機会がなかったのもあるかもしれません。

それから「TDDな設計ってなんだろう」という疑問が残っています。あくまで正しい実装を保障するためにテストを書くのであって、正しい設計がテストによって導かれる(?)というのはよくわかりません。今回だって一回目にテストなしのコードを書き捨てながら問題を整理して、それからでなければTDDできなかったように思います。

今回のCoderetreatではping-pong (a.k.a ぶつかり稽古) の良さを知る事ができたのが一番の収穫だと思っています。実感が得られないというのもまだまだバットを振った回数が少ないんだろうなと。kanazawa.rbでは先輩エンジニアにぶつかり、学校では部活の後輩にぶつかられながらTDDを学んでいこうと思います。

おわりに

主催して下さった@kompiroさん、スポンサー企業の方々、ありがとうございました。次の機会に福井で参加できるかはわかりませんが、Coderetreatの面白さを周囲に伝えていきたいと思います!

おまけ

お寿司おいしかったです。これで参加費無料って、チェンジビジョンさん(ランチスポンサー)太っ腹! お寿司