Kenji Okimoto（a.k.a okkez）さん「バグを修正する方法」

Rubyリファレンスマニュアル刷新計画(るりま)の中の人であり，CRubyコミッタ，Hikiのコミッタとして活躍されている，株式会社クリアコードのokkez（おっきー）さんのセッションです（スライド等はこちら⁠）⁠。

バグの直し方

今日の内容は「よく知らないプログラム」のバグの直し方です。バグを直す際の手順として以下の項目を挙げました。

• バグに気づく
• 再現方法を記録する
• 問題箇所を記録する
• 問題箇所を絞り込む
• 問題を修正する
• 修正できたことを確認する
• 壊していないことを確認する

まず，バグに気づかないとバグをなおすことはできません。次に問題を再現できるようにします。テストプログラムの作成，操作のメモ，データ作成などの方法があり，お薦めは何度も動かすことのできるテストコードを作成することと言います。

それから，問題箇所の絞り込みを行います。対象のプログラムをよくしっている場合は，怪しい部分の目星をつけることができますが，よく知らない場合には地道に作業をして，問題箇所の特定することになります。やり方はプログラムを少し変更して，再現方法を実行するというのを，バグが特定出来るまで繰り返します（特定できなかったら変更を戻します⁠）⁠。

この時のポイントは，一度に大きな変更をしないこと，プログラムの変更を行うたびに「今回の変更では何を調べたいのか」を意識して作業することです。問題箇所を特定できたら問題を修正し，修正できたことを確認して完了です。

実例紹介

実例としてCRubyのコミッタになったきっかけでもある，Rubyのメモリリークを修正した時のことをデモをしながら説明しました。このバグはspawnメソッドを繰り返し呼ぶとメモリリークするというのが気づいたきっかけでした。

fork( exit! )

上記の処理を繰り返し行うと，メモリリークが発生するので，forkメソッドの定義，rb_f_forkの定義，rb_forkと読み進めていきます。するとrb_forkでrb_fork_errという関数を呼んでいました。また，spawnメソッドからも同じ関数を呼んでいたので，これを詳しく見ていけば良いということが分かります。

次に，rb_fork_errの先頭で"return -1"とすることでリークがなくなれば，問題がrb_fork_errにあることがわかり，切り分けができます。問題があることが分かったら，さらに中身を見ていきます。今回の問題に関係ないであろう処理を除いたり，処理の塊ごとに"return -1"を設定するなどして，対象を絞り込んでいきます。

実際にはこの問題の解決には数日がかりだったとのことです。最終的にはpthread_createのパラメタにNULLをいれると，デフォルト値がロードされるというのがmanに書いているのをみて，それを試した結果そこに入っている変数に問題があるというのを特定できました。その変数の後始末をするコードを1行追加して解決しました。

まとめ

「問題箇所は一歩づつ着実にやること，問題箇所を特定できたら8割できたようなもの。似たようなバグがあるかもしれないので水平展開をすることも大切だ」と述べてセッションを締めくくりました。

設樂洋爾さん「おやすみシャワーができるまで」

フィーチャーフォン対応用Railsプラグインであるjpmobileの開発などで有名な設樂洋爾（しだらようじ）さんの発表です（スライド等はこちら⁠）⁠。このセッションでは設樂さんが先日参加したクックパッド株式会社主催の第3回開発コンテスト24（出題に沿ったアプリケーションを24時間で作る）での経験を通して感じた，24時間という限られた時間のコンテストを楽しむコツ，そして日々を楽しむコツを共有しました。

おやすみシャワー

設樂さんは4人のチームでこのコンテストに参加し，コンテストの課題"一日の終わりを楽しくするもの"に対し，おやすみシャワーというiPhoneアプリケーションを開発し特別賞を受賞しました。おやすみシャワーは"おやすみ"を共有するiPhoneアプリケーションで，"おやすみ"は従来親しい間柄の人だけで共有されるものでしたが，このアプリケーションによって"おやすみ"体験を時空を超えて広く共有されるものにすることができるといいます。

"悪ノリはアイディアの源"

アプリケーション紹介の後，どうやって24時間という決められた時間で作っていったかを話しました。

そもそもこのおやすみシャワーのアイディアはチーム内での"悪ノリ"によって着想を得たものとのことです。チームのメンバーは東京と札幌という離れた場所にいてビデオチャットなどで会話をしていました。アイディアを話し合っている時，電車で移動中にイヤホンでビデオチャットでの会話を聞いていたメンバーを笑わせようとしていたそうです。電車内のメンバーには他のメンバーの会話が，他のメンバーには雑踏の音が臨場感たっぷりに聞こえてきて，音というのが面白いというものだということに気づいたのが発端でした。

一日の終わりに交換する音，"おやすみ"を知らない誰かと交換するアイディアはここから生まれました。設樂さんは"僕らは笑っている間に面白いアイディアを選別しているのです"と述べていました。

"ちょうどいい挑戦をする"

おやすみを交換するというアイディアが固まった後，それを使うシーンを考えiPhoneアプリケーションという形に決定したそうです。彼らの中にiPhoneアプリケーションを作ったことがあるメンバーはいなかったため，この決定は挑戦でしたが設樂さんは"簡単そうに思えることはワクワクしない"と言います。

このあと彼らは実現可能性を調査することで，そのまま進めそうだという感触を得たため，続けてプロトタイピングの開発を行っていきました。一方フロント側であるiPhoneアプリケーションとは別にバックエンド側の開発では彼らはメンバーが慣れていたSinatraを使用しました。ここで慣れていない道具の使い方を調べながらの作業を行なっていたら，間に合わなかったのではないかとのことでした。挑戦するためにはそうでない部分をきちんと済ませること，そのために"手に馴染んだ道具を道具箱に入れておくこと"が大事だと指摘しました。

お互いをよく知る仲間との開発

設樂さんはこの時の開発がスムーズに進んだ要因のひとつに，彼らのチームが古くからの友人だったことを挙げていました。このため彼らができること，好きなことをお互い知っており，これが良い判断をするのに役立っていたと感じているそうです。また，作業の割り振りも特別打ち合わせることなしに適切なメンバーが担当することになり，今考えると"自然"な開発だったと感じているそうです。

また，開発の時は離れた3拠点間をSkypeやPS3のビデオチャットでつないでいました。セッション後の，離れた場所をつないでの開発の場合すぐにやり取りできる環境が必要か，という質問に対して，こういった常にメンバーがつながっている環境は大事で，これがなければ開発の中で色々なロスが生じていたのではないかと話していました。

どうやって日々を楽しむか

どうやって24時間でアプリケーションを作り上げていったのか，という話の後で，コンテストというお祭りと日常との境目だという写真，アプリケーションを投稿した後にメンバーと撮ったというビデオチャット画面の写真を紹介しました。写真の中で彼らはとても幸せそうな顔で写っているように見えました。

設樂さんはこの開発コンテストのような幸せな時間と日常の日々との間の境目を埋めたいと言います。そして，日々というのは24時間の連なりなのだから，24時間の楽しみかたを考えることは日々を楽しむことを考えるということにつながっているのではないか，と問いかけます。

最後に設樂さんは"どういうふうにコードを書いていくかというのは どのように生きていくかということに違いない 私たちはプログラマだから"（How we code is how we live, for us, programmers.）という言葉でセッションを締めくくりました。

諸橋恭介さん「テストに開発を駆動させたい!」

Rails3レシピブックや，達人出版会から出版されているはじめる！Cucumberの著者として知られている，永和システムマネジメントの諸橋恭介さんの発表です（スライド等はこちら⁠）⁠。

本セッションでは，どうしてテスト駆動開発が良いのかについてを話すとはじめに述べました。次に札幌Ruby会議2012がとても楽しいので，スタッフ，参加者のみなさんに感謝したいと言う言葉とともに，本セッションが始まりました。

なぜテストを書くのか

テストを書くのは開発を駆動させたいからであり，テストを書きたいからではないと話します。

Ruby界隈でテストが話題になることが多くなりましたが，テストを書く恩恵がわからないという声もあります。テストを書く理由として，まわりのみんながテストを書くのがいいよと言っているからや，将来的にリグレッションした時に分かるように，というような理由が挙げられることがあります。しかし，テストはメンツや将来のために，書きたくないのを我慢して書くものではなく，開発をドライブする，開発をやりやすくするものだというのが諸橋さんの主張です。

プログラムを書くときに，どのようなことをしているのかというと3つのサイクルがあります。code，run，thinkというサイクルです。

書いたソフトウェアというものは，実行しなければ本当に動作するかわかりません。Rubyの場合であれば，rubyコマンドで実行した際のみ動作するコードを記述する方法やirb, Railsであれば rails console を用いることで，実行することができます。

ですが，規模が大きくなるに連れて，これらの方法だけでは難しくなります。データを変更した後に掃除を処理が大きくなってしまいますし，人間の目でアサーションするのが難しくなってくる，テスト間の依存関係が肥大化するなどということが起きてきます。そして，早晩テストが破綻してしまいます。

そこで，Testing Frame Workを使うことを勧められました。諸橋さんはRSpecが好きで用いていると言います。例えば，テストデータを任意のタイミングで作成したり，後処理を自動で行なってくれます。また，結果の確認もひと目で行うことができます。このようにTesting Frameworkはうまい具合に構造化を行なって，コードをrun（実行）することを助けてくれるのです。

考える

例えば，Railsにおいて，絞り込み検索フォームを実装したいときに，プログラマは何をしているでしょうか。それは「考えている」のです。どのように実装すれば良いのかを考えているのです。

この考えることの内容には，次のようなものがあります。

• Railsにもっといい機能はないか，もっといいgemはないか
• 検索するということは，どういう条件になるのか
• どういうメソッドやAPIを提供すればよいのか

この考えている内容をテストで表してみましょう。例えばデータベース上にPerson（人⁠）⁠，Hobby（趣味）の一覧があったとします。Personが持つHobbyを最低一つ存在するかを調べるスコープを.has_at_least_one_hobbyとして，作成したとします。そして実際にテストを書いてみると，この名前は非常に長いことに気がつきます。そこで，一旦interestという関連を作成したらいいのではないか，ということやRubyには"#any?"というメソッドがあるということなどを考えます。そしてテストを書いて，読みながら良いかどうか考えます。例えばinterest_in_anyというスコープを作成するのはどうだろう，という具合です。

最低限のテストを作ったら，それを動かせるように実装するのが最初のゴールです。テストを書く中で，どこまでテストを書けばよいのか，というのはよく疑問に思うことです。諸橋さんは「あなたが今こういう風に動かしたい」というのを満足させるテストコードを書いて，それが動くように書く，というのがひとつの答えではないでしょうか，と述べていました。

大事なこと

テストコードは"実際にこういうふうに動かしたい"というのを雄弁に語り，そしてTesting Frameworkが実行を助け，実際に動かしてフィードバックを得ることができるのです。

繰り返しになりますが，今回一番大事なこととして，諸橋さんが伝えたいことは「デベロッパーテストというものは，開発をドライブするためにある」ということです。今「あなたが」行いたいプログラムを「実行」すること，「⁠考える」ことを助けてくれる，引っ張ってくれるいいやつが「テスト」である，と力強くまとめました。