2011年06月
2011年06月13日
【2011.7.1追記】
私が（半分）担当した、OSC2011Hokkaidoの公式レポートが公開されました。
OSC2011 Hokkaido！ご来場ありがとうございました！！
オープンソースカンファレンス2011Hokkaidoに参加した。私にとっては今年で4年目のオープンソースカンファレンス(OSC)である。
念のため概要を
オープンソースソフトウェア(OSS)に関する技術を扱うイベントで、OSSを作成する/扱う企業やコミュニティが参加する。札幌では2005年から毎年開催されている。
今回は以下の数の出展があった。
今年やったこと
- OSCスタッフとして活動
今まで、OSC北海道の主催団体・LOCALに加入していなかったこともあり、OSCにスタッフとしては参加していなかった。
今年は「OSC2011Hokkaidoではスタッフとして活動したい！」と考えていたため、これを機にLOCALのメーリングリストに加入した。 - 札幌C++勉強会としての出展
昨年12月に発足した勉強会・札幌C++勉強会。
ここで「OSCに冊子配布やセミナーで出たい」という話が挙がり、私も準備に加わることに。
なお冊子については、上記公式サイトをご覧下さい。 ※冊子は近日中にPDFで公開予定です。
今年やらなかったこと
- 展示会場に来た一般参加者との交流
スタッフの中でも、一般参加者との交流をあまりしていられない仕事を引き受けたため、今年は参加者との交流はほとんど懇親会のみになった。 - 北海道開発オフとしての出展
昨年も一昨年もこちらのメンバーとして参加し、ブース展示の担当の一人として参加していたのだが、今年はスタッフと札幌C++勉強会に時間を取られたこと、また北海道開発オフがブースにて行う仕事が減ったことから、北海道開発オフのメンバーとしてはMLで意見を出したりする以外の活動はしなかった。
感想
一スタッフとして、このような大きなイベントが作り上げられていく過程を見ながら参加できたのが楽しかった。一般参加者のように「会場で他の来場者と交流を図る」ということは今年は出来なかったが、それは仕方ないことで、ただ今までとは違う関わり方でOSCに参加できたのは意義があったと思っている。
それと、聴講した各セミナーについての感想は、事情があって省略します。後日告知します。
【2011.7.1追記】
私は公式レポートの担当をしており、それに向けて記事を書いていたため、セミナーに関する感想をここに上げていなかったのです。
私が（半分）担当したOSC2011Hokkaidoの公式レポートはこちらです。 OSC2011 Hokkaido！ご来場ありがとうございました！！
最後に
来場者の皆様、ありがとうございました。お楽しみ頂けましたでしょうか。
スタッフの皆様、札幌C++勉強会の皆様、お疲れ様でした。
※2011.6.18 3:12追記：自己紹介に使ったLT資料を公開しました。
TDD（Test-Driven Development、テスト駆動開発）を実習形式で学ぶ会「TDD Bootcamp」が、2週間前のTDD Bootcamp 1.5に続いて開催されたので参加した。
今回は「お題はJavaかRubyで出題、ただし参加者側で事前準備が可能なら他の言語での実施も可」となったため、お題をC++に移植し、さらに私が最近使い始めたCppUnit（C++向け単体テストツール）の準備をした。
で、事前準備万端なつもりで会場入りしたら、@sumimさんから「C++のお題コード、VisualStudioでコンパイル出来ないよ」と言われた。焦ったが、コーディング開始までの時間でよく調べてみると、一旦VisualStudioで編集したものをUnix環境に持ち込んで編集したため、改行コードがCRLFからLFに変わってたのが原因だった(*1)。
まず、主催の@shuji_w6eさんからTDDの概要について説明があり、その後各言語担当者が自己紹介。そして今回の招待講演者・@t_wadaさんからTDDについていくつかポイントの説明があり、その後実習に移った。
C++班になったのは私を含め3人（他は@hotwatermorningさん、@asari755さん）。ちなみに全体の人数は以下の通りでした。
| 言語 | 担当スタッフ | 班数 | 人数 |
|---|---|---|---|
| Java | @irasallyさん | 5班 | 19人 |
| Ruby | @niku_nameさん | 2班 | 6人 |
| Python | @nakayoshixさん @giginetさん | 2班 | 7人 |
| Smalltalk | @sumimさん | 1班 | 6人 |
| C++ | @h_hiro_ | 1班 | 3人 |
お題として出された事例は、「ファイルにデータを一定のフォーマットで書き出す/読み込む」というコードであった。（※コードはこちら：maraigue / tddbc-sap02-legacy-cpp – Bitbucket）このコードにはテストコードがないため、テストコードを書いた上で内部実装の変更や機能の拡張を行おうというものである。
我々の班で、一つ失敗したと感じたのは、テストコードを適切に書かなかったために、後でバグが検出されたことである。
- まず我々の班では、「"データを書き込む"メソッドを利用してから"データを読み込む"メソッドを利用することで、データが正しく取り出せること」を単体テストとして記述し、処理が問題ないことを確認した。
- さてお題として出されたコードでは、データベースとして利用するファイルのファイル名が、コード中に定数として記述されていた。このため我々の班では、これを引数として与えられるように修正した。
→ そのときの単体テストとして追加したものは、「データベースアクセス用のインスタンスを、引数を与えて生成した場合、インスタンスに格納されたファイル名を正しく取り出せること」であった。 - またお題として出されたコードでは、「データベースのデータを取り出す/書き込むにあたって、毎回ファイルアクセスを行っている」という実装になっていた。このため我々の班では、「データベースを開いた際に、ファイル中のデータをすべてメモリ上に格納する」「データベースを閉じる際のみに、メモリ上のデータをファイルに書き込む」という実装に変更することにした。
→ そのときの単体テストとして追加したものは、「データベースを開いてから変更を加えて閉じ、改めて開くと、閉じたときの状態が復元される」であった。
→ しかし、他の単体テストが通る一方で、いま追加した単体テストだけは通らなかった。
→ 調べてみた結果、先程の「ファイル名を引数で与えられるようにする」修正において、ファイル名に「引数で与えたものを使う部分」と「元のコードのまま定数を使う部分」が混在していた（定数を使う部分を変換し忘れていた部分があった）ことが原因だった。
これは今考えると、2項目め（データベースとして利用するファイルのファイル名を、引数で与えられるようにする）を実装したときのテストケースが問題だったのであって、本来であれば、「データベースを開いてから変更を加えて閉じ、改めて開くと、閉じたときの状態が復元される」というテストをこの段階で書かなければならないのだろう。この場合、引数のファイル名を変えたことが、実際のファイルアクセスに反映されていることをテストする方が重要なので。
また一瞬困ったのは、テストコードを実行するとSegmentation Faultで落ちて、どこが問題なのか切り分けるのが大変だったこと。まあこれはC++だから仕方ないのですが…。@hotwatermorningさんがgdbで問題の箇所を調べて下さったので助かった。
…と面倒なこともありましたが、メンバー3人で「テストコードがあったおかげで、内部実装の変更を思い切って出来た！」ということを感じられて、楽しくTDDの実践を終えることができた。
また今回、TDDについて多くの重要なポイントが見えた。私がTwitterで実況したものを抜粋する。（主に、@t_wadaさんの講演内容や説明からです）
- "テストが命綱"、*緊急時に命綱を編むことはできない"
- 「自分が完璧なプログラマではないことを、TDDをすればするほどわかる」
- 「もし、テストコードなしで大幅な修正を加えるとしたら、信じられないほどのスキルと明確な理解が必要になる」
- 「静的言語の場合は、影響範囲を調べるためにコンパイルエラーを積極的に使う」「動的言語の場合はそれが使えないというデメリットはある。一方で、継ぎ目（コードを介入させる場所）を作りやすいというメリットがある」
- 「技術書の「写経」の方法。 1.ローカルで使える SCM を用意 2.「ほんたった」などで対象の本を固定 3.ひたすらサンプルコードを写して実行 4.実行するたびにコミット(コミットログにページ番号を含める) 5.疑問点があったらコミットログや本に書き込む 6.章ごとにタグを打つ」
- 「TDDは練習することで上手くなる（＝才能ではない）」
- 乱数を含むコードに対するテストの書き方。(1)乱数の選択肢が1つしかない場合のテストを書くことで、乱数の影響以外の部分をテストする。(2)乱数のパターンを固定したテストを書きテストする。
- Rubyチームは２つとも三脚の足を揃えられていた（バージョン管理、テスティング、自動化）。文化とツールの充実を感じる。と絶賛してみる(@sandinistさん)
特に今回実習して、上記のうち「TDDは練習することで上手くなる（＝才能ではない）」というのが重要なのかと感じた。「こういう場合にはこういうコードを書けばよい」というのを学べば学ぶほど、適切な単体テストが書けるようになるのだな、と感じられた。
最後に、主催の@shuji_w6eさん、北海道に来て下さった@t_wadaさん、拙作のC++コードにお付き合い頂いた@hotwatermorningさん・@asari755さん、またその他皆様ありがとうございました。
おまけ：自己紹介LT資料
(*1)例えば「// ここはコメントです[LF]x = y + z;」のようなコードを書くと、VisualStudioのエディタは[LF]を改行と扱う一方で、コンパイラ（厳密にはプリプロセッサ）は改行がないものと扱うのである。困った仕様です。
