あらまし

5月28日に開催される Typetalk Hack Fukuoka というイベントに参加する予定なのです。で、何を作ろうかなと思案して、 RubyGems を作ってみようと思いつきました。あったら簡単に Typetalk 使えて便利だろうなと。しかし、イベント内で完成させる自信がありません。参加しておいて何も成果がないのも嫌なので準備を始めました。ウォーミングアップがてらコーディングしていると、勢い余って公開できそうなレベルまで完成してしまいました。寝かせておいても意味がないので、フライングして RubyGems.org にて公開することにします。

• GitHub
• RubyGems.org

Typetalk って何？

Typetalk （タイプトーク）はパソコンやスマホで簡単にメッセージのやりとりができるコミュニケーションツールです。 nulab さんがサービスを提供しています。

なにができるの？

Typetalk API を全てラップして使えるようにしてます。例えば次のようにして、トピックにメッセージを送れます。素でコーディングするよりは簡単に Typetalk を使えるはずです。

require 'typetalk'
Typetalk.configure do |config|
  config.client_id = '...'
  config.client_secret = '...'
end
topic_id = ...
Typetalk::Api.new.post_message(topic_id, 'メッセージ')

ドキュメントは今のところ README.md に記したものが全てです。ひと通りメソッドは紹介していますが、まだまだ不備がありますので、今後、整備していきます。

今後のこととか

今のバージョンは単に API をラップしただけのライブラリになっていますので、もう少し抽象化して扱えるようにします。

感想

RubyGems を公開するのも初めてだったので、いろいろと勉強になりました。Bundler を使えば、とても簡単に Gem 化して公開できるので、みんなもどしどし公開するといいと思うよ。あと、Faraday と WebMock 、 VCR はマジ便利。

Typetalk Hack Fukuoka 向けのネタがなくなったので、何か新しいアイディアを考えねば…

参加にあたって

独学でテスト駆動開発（TDD）をやってみたりしているけど、今ひとつメリットが分からないときがある。 なので、結局、コード本体を書き切ったあとに、テストコードを書くという慣れた開発方法に戻ってしまう．．． やっぱり書籍だけだと細かいニュアンスがわかりづらいし、本格的にTDDで開発している人の、血の通った情報を手に入れたい！ どうせだったら体験もしてみたい！
ということで、2013年6月15、16日に開催されたTDDBC Fukuoka 2013に参加してきました。

イベント中に感じたこと

一日目

• TDDと黄金の回転についての４象限モデルを初めて見たが、すごくTDDの概念が伝わる良い図だなと思った。
• デモは開発環境に関する知識がない状態で聴くと、理解しにくいのではないかと思った。 特にGuardによる自動テスト実行とかは伝わっていないのでは？と感じた。 デモ中に説明するのはポイントがずれて難しいだろうから、もう少しデモ前か後に環境に関する解説があっても良いんじゃないだろうか。
• スケルトンがクイックスタートすぎて凄い。特にTDDにはGuardは必須だなと感じた。
• GitHubのコラボレーションを初めて使えて嬉しかった。とともに孤独な開発をしてるなと寂しくなった。
• GitHub経由でペアプロすると、コミット忘れがなくて済む。が、少し切り替えのタイムラグがあることが気になった。
• RSpecのexpect記法で書こうとするが、上手く動かずにハマった。結局、should記法に戻してしまった。RSpec力が足りない．．．
• @kisさんのLTがウケた。TDDは開発手法であり、技能ではないのだ。
• @shimesaba_type0さんと書いたコード
  • zip.rb
  • zip_spec.rb

二日目

• 一日目にペアプロの切り替えタイムラグが気になったので、１台のパソコンを共有する方式に変えてみた。 タイムラグはなくなったが、今度はコミットを忘れるようになってしまった。
• ペア相手の開発環境がRubyMineだったので、初めて触れた。が、良し悪しが判断できるほどは扱えなかった。
• Wikiエンジンを実装するという課題で、頭が大混乱を起こす。おそらく次の五重苦が原因。
  • TDDに慣れていない。
  • ペアプロに慣れていない。
  • Gitでの細かい単位のコミットに慣れていない。（Subversion脳）
  • ペアになった人の開発環境（Ubuntu、RubyMine、Vimとか）に慣れていない。
  • RSpecは分かっているつもりだったが、実は分かってなかった。
• コードレビューのプレゼンをしたが、下手すぎて死にたくなった。もう少し落ち着いて、順序を追って話さないと。
• やっぱりLTの準備をしとくべきだった。
• @MnrUchidaさんと書いたコード
  • wiki_parser.rb
  • wiki_parser_spec.rb

イベントをふりかえって

今までは、テストコードを書くとき、まずは期待値をわざと失敗するようにしておいて、テストコード自体のテストを行い、その後、期待値を書きなおして、コード本体のテストをするという方法で実装していた。 またある時には、コーディングにおける問題を切り分けたくて、小さなモックアップを作ったりして、テストをしていた。
こういうやり方も上手く行くときは効率的なんだろうけど、下手をうったときには泥沼にハマってしまうことが多い。 TDDを導入すると、少しずつテストできるから、泥沼にハマる確率はかなり低く抑えられるだろうと思った。 また、モックアップはたいてい捨ててしまうので、テストコードとして利用し続けられるのは効率的だ。

あと、以前の方法では、コード本体とテストコードでそれぞれ分けて考えることができるため、特定の問題に集中して実装を進めることができた。
しかし、TDDでは、コード本体とテストコードの両方の視点を頻繁に切り替えながら、実装を進めていくため、集中して作業できないと感じた。 イベントなんで時間が限られていて迷うくらいなら実装を優先したという事情もあるだろうし、慣れの問題もあるだろうけど。
もう少し落ち着いて考えるべき状況もあると思うので、今後TDDを実践しながらベストなサイクルペースを探ったほうが良さそうだ。

結局、TDDはコーディングにおけるPDCAサイクルだったんだ。日ごろPDCAサイクルを回していくことが、生産管理・品質管理で有効だと言い聞かせながら業務を進めている。しかし、従来のシステム開発では、設計->コーディング->レビューという大きな単位でしかサイクルを回せないことが多い。そこで、TDDを導入するとPDCAサイクルを細かく回すことができる。

今後のこととか

キーノートによると、いろいろ足りてなさそうなので、次のことをやりたい。

• TDDやる。テストのないコードはレガシーコードだ！
• ペアプロやる。お相手募集します。
• SubversionからGitへ本格移行する。GitLab入れたい。
• インストールしただけで放ったらかしのJenkinsを本格的に使う。

これからはグリーンバンドを身につけて、自分を戒めながら、テストを書いて行きます。

謝辞

@Spring_MTさん、素晴らしいイベントを開催していただきありがとうございます。
@t_wadaさん、大変お世話になりました。素敵なキーノートをありがとうございます。
@sue445さん、@a_suenamiさん、TAとしてご指導いただきありがとうございます。
AIPさん、ご支援いただきありがとうございます。
そして、参加者の皆さん色々とありがとうございました。