この12月は、WACATEとTDD Boot Campという両方のイベントでスタッフとして参加させていただきました。ご参加の皆様、本当にありがとうございました。

• WACATE 2009冬 〜基礎・おぼえていますか〜
• TDD Boot Camp

WACATEもTDD Boot Campも既に多くの方が、Blogなどでフィードバックを寄せてくださっています。ありがたい限りです。

WACATE 2009冬 〜基礎・おぼえていますか〜

WACATEには今回から実行委員として参加させていただくことになりました。今回は基礎がテーマということで、ソフトウェアテストとは直接関係があるわけではないのですが、「情報探索キホンのキ」というタイトルで話させていただきました。

内容は、第3バイオリンさんがレポートしてくださっています。ありがとうございます。

• ＠IT 自分戦略研究所:「WACATE 2009 冬」参加レポート

このセッション、既存の方法論や決まった答えを発表するのを目的としていたわけではなく、参加したワカテの皆さんと一緒に、日々のインプットについて、さらにもう一歩考えていくためのキッカケを作るのを目的としていました。

今後もワカテから一歩成長するために必要なことを、色々考えていければなーと思っています。

TDD Boot Camp

TDD Boot Campでは、Pythonを選択された方々とxUnitの未経験者の方々の担当をさせていただきました。Python島は1ペアでした。他の言語を選択され方どおしでは複数のペアが作られていて、おたいがいにコードレビューをすることができました。しかし、Python他のペアのコードをみて触発をうけることが出来ない状況になっていました。そこで、参考になるか分からないけれども少しでも比較の対象になればということで、休憩時間にモリモリとPythonで課題をやっていました。休憩時間しか使えなかったので当日は途中までしか出来ませんでしたが、家で宿題として何とか完成させました（スレッドセーフ対応はしていません）。

• テストコード: lru_cache_test.py
• プロダクトコード: lru_cache.py

一応、コメントとしてToDoを次のようなToDoを記載しておきました。

• テストコード: 他のテストに内包されているテストを削除する
• プロダクトコード: さらに仕様が複雑になる場合は、例えば、ステートパターンなどを導入することでクラスを分割する

特に、TDDをリズム良く回すためには不要なテストの削除など、テストコード側も変更していくことが必要となります。はじめの一歩を進むために必要になったテストも private にすべきアトリビュート（フィールド、メソッド）にアクセスしていると、その後のリファクタリングの足かせになってしまいます。

今回も仕様の全体をまかなうテストを書くのは第一歩目として大きすぎるということで、一歩目として内部のロジックに踏み込んだテストを書いています。しかし、要件としては、その内部ロジックを使用することを定めている分けではないので、後から、さらに良いロジックにリファクタリングすることも考えられます。もしくは、もっと単純に、コードの解り易さのためにメソッド名を変更したくなったりするかもしれません。この場合には、二歩目として書いた本来の要件を満たすためのテストがあるので、一歩目として書いたテストは削除するのが良いのではと思います。

先ほどの自分が書いたコードの例で言えば、 test_find_oldest_key() を一歩目に書きましたが、本当に書きたかったのは、二歩目に書いた test_delete_older_data_for_unused_cache() で、この二歩目には一歩目でやっていることも内包されているので消した方が良いということになるでしょうか。

ケントベックの「テスト駆動開発入門」で、はじめインスタンス変数の currency にテストコードからアクセスしていた部分を getCurrency() を使って書き換えたり、Dollar と Franc を Money にしていく過程で重複するテストを消していったりするところなどが、この辺のリズムの参考になるかもしれません。

また、この辺のテストコードのリファクタリングを micro coverage という道具を使って補助できないかというご提案を和田さんがされています。今後の動向に要注目ですね！

• 札幌Ruby会議02: USTREAM sprk02-5

（52分くらいから和田さんのLightning Talkがはじまります）

# 本題とは関係ないですが、キャッシュの上限を表すのに “size” という言葉を使ったのはあまり良くなかった気がしています。Lasseさんは “capacity” という言葉を使われていました。そっちの方が誤解が無くて良い命名ですよね。もう少し始めの段階で名前にこだわっておけば良かった……。

なお、当日のお題は和田さんのご講演のスライドの最後で紹介してくださっています。

• t-wadaの日記: TDD Boot Camp を開催させていただきました

WACATE も TDD Boot Camp も、どちらも参加者、他のスタッフの皆さんのおかげで、とても楽しいイベントとなりました。これからさらに加速していきたいと思いますので、皆さんどうかよろしくお願いいたします。

「レガシーコード改善ガイド」を献本して頂きました。レビューに参加させて頂き、訳者あとがきにも名前を入れていただきました。とてもとても思い入れのある本だけに限りなく嬉しいです。翻訳者、編集者の皆さま、本当にありがとうございます。

まず、まえがきから引用。

訳者あとがきからも引用。

本書の魅力について様々語ることができると思います。ただ、著者からも訳者からもこんな熱意を感じ取ることができる。それがこの本の一番の魅力なのではないかなと感じています。現場の苦悩の原因を追究し、著者は「レガシーコード＝テストのないコード」という発見に至った。その発見を元に現実世界で闘う人々にエールを送ってくれる本であると言えるのではないでしょうか。

最後に第24章「もうウンザリです。何も改善できません」から。

新規開発だけではなく、保守開発、派生開発をおこなっているあなたも仕事に誇りがもてるかもしれません。明日からレガシーに負けない仕事をするために、是非手に取ってみることをお勧めします。この本が「レガシー本」「レガ本」などと呼ばれ親しまれるようになると良いなと思っています。発売日は14日。一部書店にはすでに並んでいるらいしです。

最近なかなかBlogにまで気が回らなくて更新が滞っていました。というわけで、いまさらになってしまいましたが、御礼の意味も込めて最近化させて頂いたイベントを並べてみたいと思います。

• 2009年5月28日: 第2回 すくすくスクラム
• 2009年5月29日: 第4回 原因結果グラフ＆デシジョンテーブル勉強会
• 2009年6月13日: WACATE Short Short vol.3 (WACATE前夜祭)
• 2009年6月13-14日: WACATE 2009夏
• 2009年6月14日: WACATE Short Short vol.4 (WACATE後夜祭)
• 2009年6月16日: Python Code Reading 10
• 2009年6月22日: DevLOVE 世界のすべてをテストせよ。
• 2009年6月27日: xUnit Test Patterns読書会 #3
• 2009年7月2日: ソフトウェアインスペクション・ワークショップ 2009
• 2009年7月7日: オブジェクト倶楽部2009夏イベント

どのイベントからも、とても良い刺激をいただきました！これからもよろしくお願いいたします。

ソフトウェアテストのワークショップであるWACATEの次回開催「はじめてみようテストレビュー WACATE 2009夏」の残席がわずかになっているそうです。前回は、申し込み開始後、早いうちに満員になってしまったこのイベント、今回は、申し込み殺到のため定員を増やしましたが、もう残席もわずかになってしまったとの事です。

参加をご検討されている方は、早めに申し込まれることをおススメします！

• WACATE 2009 夏　〜はじめてみようテストレビュー〜　参加受付のご案内

---

再度の定員増のうえに満席となったようです。申し込みを逃された方はまたの機会に是非。

またまた前のことになってしまいましたが、 xUnit Test Patterns (xUTP)の読書会に参加してきました。今回は前回よりも参加されている方々も多く、とても充実した内容でした。

• xUnit Test Patterns読書会

今回読んだ部分は、xUnitのテストコードのリファクタリングとテスト自動化(自働化)の原則の部分。テストコードのリファクタリングに関しては、実際に例を挙げながら、徐々にテストコードをリファクタリングして可読性を良くしていくリズムについて書かれていました。自動化の原則に関しては、開発者テスト(Developer Testing)の考え方に的を絞って、その上でテストコードの価値を挙げるための原則について説明されていました。

今回の読書会に参加して変わったのは、テストのリファクタリングを積極的にするようになったこと。読書会では「これほんとにするんですか?」的な質問をしていましたが、改めてxUnitのテストコードに向かい合ってみるとリファクタリングする余地が沢山ありました。特に、テスト対象(SUT)のオブジェクトを生成して状態を設定する部分であるフィクスチャの組み立て部分をメソッド(関数)として抽出するリファクタリングがとても強力であることを実感しました。

xUTPという本自体の内容も、読書会での議論もとても楽しく有益でした。幹事のせとさんをはじめ、参加者の皆さん、本当にありがとうございました。

こちらも結構前のこととなってしまいましたが、4月23日に「すくすくスクラム」のvol.1に参加させていただきました。今回のきっかけはebackyさんのつぶやき。つぶやきを見て何気なく申しこませていただきましたが、快くOKしてくださって助かりました。

内容としては、認定SCRUMマスターであるessenceさんの講義のあとに、ワークショップ形式で朝会(デイリースクラム)を体験。その後、みんなで気づきを共有するというもの。講義で、わかりやすくSCRUMの基礎を教えていただき、その後、実際に体を動かしてみるというのが、とても良いリズムでした。

なによりも、みんなで気づきを共有できたことが何よりの収穫だと思います。講師として話していただいた皆さん、主催者の皆さん、本当にありがとうございました。予定が合えば次回以降も是非参加させていただきたいなと思いました。

それから、開催前に久しぶりにスクラムの教科書を2冊復習してみました。読み返してみると気づきが沢山。たまに基本にかえるのってとても大事ですね。

だいぶ前のことになってしまいましたが、4月22日にAgile Japanに参加してきました！

• Agile Japan 2009

今回のキーノートセッションは、メアリー・ポッペンティークさん黒岩さん、平鍋さんによる「アジャイル・リーン、トヨタ生産方式」の話。当日の内容については公式サイトからスライドをダウンロードすることができますので、ご興味のある方は是非。

このキーノートセッションの内容で自分の中で特に興味深かったのが、大野耐一の「標準」の話でした。「標準づくり」「誰が標準を決める?」「標準の決め方」ということが紹介されていましたが、今、自分が抱えている課題のヒントがちりばめられていて感動ものでした。

現場で起きていることを標準としてまとめ、それを現場で実際にやってみて、どんどん改善していく。そのような標準化のリズムが感じられたのが良かったです。標準化っていうと堅苦しいものを考えがちだったのですが、そうではなくて、要は、改善のための見える化のことだということを、ここで言っているのだと思いました。

現在、現場で起きていることを見えるようにしないと改善はできない。なので、肩肘はらずに現在やっていることを標準としてまとめる。そして、みんなが見えるようになったら、それをみんなで改善していけば良い。今後、自分のかかわる仕事の中で、この標準化のリズム、改善のリズムを活かしていけるようになりたいなと思います。

その他、ライトニングトークス、事例セッション、チームビルディングの話題などとても楽しく勉強になりました。とても良いイベントで、刺激になり帰りに思わず本屋に立ち寄り本を何冊かかって帰ることになりました。登壇者の皆様、主催者の皆様、スタッフの皆様、本当にありがとうございました。

GW中にWACATE-Magazineのvol.5が発刊されています。今回も充実の内容。是非、ご覧になってみてください。

• WACATE-Magazine

# 様々、イベントに参加させていただいたりと書きたいことがたまっているのですが、なかなか書けていませんー。おいおい書いていきたいと思います。

今週頭に、TEFの「第2回原因結果グラフ＆デシジョンテーブル勉強会」に参加してきました。第1回に引き続き、とても有意義な勉強会でした。

今回は、今までの復習。分かりづらかった部分をかなり丁寧に説明していただきました。不明点が明確になってきて、とても有意義な勉強会でした。あとは、これをどう実践に活かせるかというのが自分としての課題です。

講師、モデレータの秋山さん、鈴木さん、加瀬さん、そして会場ご提供くださったミラクル・リナックス様、本当にありがとうございました。

先日4月18日に、若手エンジニア向けのソフトウェアワークショップであるWACATEのオフ会イベントであるWACATE Short Short vol.1を無事に開催することができました。

記念すべき第1回目はライトニングトークス大会。当日は、ゴングを元に進行しました。しかもゴングはこだわりの真鍮製。響きが違います。ワカテの方々からセンパイの方々まで集まって頂き、さまざまなトークが繰り広げられました。

当日の模様は組み込みネットに掲載して頂いています。

• 組み込みネット: WACATE Short Short vol.1

充実した一日を過ごすことができました。皆様、本当にありがとうございました。今回はLT大会でしたが自由に何でもやっていこうということですので、どんどん企画を上げて頂いて盛り上げていきましょう。

# ライトニングトークスだけで参加費一万円と聞くと一瞬えげつない気がしますが、昼食代と飲み代だけで結構な額になってしまうので、実際は、会場代＋ゴング代を割り勘というような感じになっています。

“X Tests are not X Tests” とは、"Working Effectively with Legacy Code” の著者である Micheal Feathers  が最近叫んだ言葉です。

• Object Mentor: X Tests are not X Tests

この意味は、あなたが「XXXテスト」と呼んでいるテストは、他の人の言う「XXXテスト」とは限らないということでしょう。テストに関する言葉が混乱していて大変だという趣旨の投稿です。この混乱の理由のひとつとして、コミュニティーごとに、テストに関する方言があるということが挙げられています。また、この記事では、Stephen Waltherの “TDD Tests are not Unit Tests” というブログの記事についても言及されています。この記事には詳しくは触れませんが、要は「TDDでのテストは、いわゆる『ユニットテスト』ではない」ということが主張されています。

• Stephen Walther: TDD Tests are not Unit Tests

さて、今回は、この言葉の混乱という問題について「『開発者テストの道具』と『テストのレベル』の言葉の使い分け」というアプローチで考えてみたいと思います。

最近は、同じ「テスト」という言葉を使っていても、TDDで書くテストなど開発を推し進めるための開発者テスト（Developers Testing, Development Test）と、品質のためのテスト（QA Testingなどと呼ばれることも多くなってきています）は違うということが広く認識されるようになってきました。この開発者テストで使われている言葉には、もともと「テストレベル」を表す言葉として使われていたものがあります。

ここで、テストレベルとは、テストの階層のことです。ISTQB(JSTQB)の定義によると、テストのレベルはV字の下からコンポーネントテスト、統合テスト、システムテスト、受け入れテストとなっています。なお、コンポーネントテストの別名としてユニットテスト、モジュールテスト、プログラムテストという言葉もある旨が説明されています。

• ISTQBテスト技術者資格制度 Foundation Levelシラバス日本語版Ver.1.1.0

例えば、ユニットテスト（単体テスト）という言葉。これは、もともとテストレベルの一番下の階層、つまりISTQBでいうコンポネントテストを指す言葉に由来しているのだと思います。しかし、TDDで書くテスト、xUnitを使って書くテストは、コンポーネントテストのレベルのテストとは限りません。特にリファクタリングを取り入れている場合は、コンポーネントテストのレベルに当たるようなテストを、統合テストに当たるようなテストに書き換えていくということも多くあるでしょう。こうなってくると、そもそも開発者テストをテストレベルによって分類するということ自体が無意味になってきてくるような気がしてきます。

このことは、Martin Fowler の以下の言葉に端的に表れているのではないかと思います。

• artima developer: Test-Driven Development - A Conversation with Martin Fowler, Part V

こうして、開発者テストの道具としてのユニットテストという言葉と、テストレベルの最下層としてのユニットテスト（コンポーネントテスト）という言葉の使い分けが必要になってくるわけです。

受け入れテストという言葉もそうでしょう。受け入れテストは、ISTQBでは最上位に位置するテストレベルとして紹介されていますが、この言葉も違う意味で使われることが多いです。

例えば、ユーザストーリについて扱っている “User Stories Applied” という書籍では、「受け入れテストはストーリの実装が何を満たせばよいかを示すテスト」というような意味で受け入れテストという言葉を使っています。FITやCucumberも、このような意味での受け入れテストのための道具なのだと思います。もちろんプロセスによっては、テストベースがストーリであったりユースケースであったりするかもしれませんが。

なお、受け入れテストという言葉はさらに色々な側面で使われていて、テスト開始前に開始条件を満たしているかどうかを検査するためのテストを受け入れテストと呼ぶ場合もあります。つまり前工程からソフトウェアを受け入れる時におこなうテストを受け入れテストと呼ぶこともあるということですね。「基本から学ぶソフトゥエアテスト」では、「最終受け入れテスト」という言葉を用いて、各工程の開始条件としてのテストとユーザの受け入れテストを使い分けています。

このように、同じ「XXXテスト」という言葉でも、開発者テストの文脈で語られる場合と、テストレベルなど従来の使い方で語られる場合では、意味が異なってくる言葉があります。これらは、ルーツが同じだったりして、お互い無関係というわけではありませんので、厳密に使い分けなくても良い場合もあります。しかし、細かい話をするときは、どちらの意味で使っているのかを意識しないと話が通じない場合も良くあるでしょう。

一昔前は、QAの世界でのテストの方が一般的でしたが、近年は開発者テストもかなり体系化されて、テストという言葉に初めて触れるのが開発者テストの文脈の中でというケースも増えてきているのではないでしょうか。というわけで、この辺りの方言の違いの認識がもっと広まって、おかしな誤解が減ってくれれば嬉しいなと考えています。

いまさらながら、WEB+DB PRESS vol.49を読み終えました。今回の目玉は何と言っても、DRY原則に関する記事。とても役に立ちました。

DRY とは Don’t repeat yourself の略であり、DRY原則とは繰り返し、重複の排除を目指した原則。分かったような気になっているけれども、意外と具体的に分かっていなかったりするのがこのDRY原則だと思います。この特集では、コンピュータの歴史を振り返りながらDRYについて考えたり、Excelを使った実践例、様々な言語での実践例が載っていたりと、今までより深くDRYを考えるためのきっかけが盛りだくさんです。

この記事を読んでから、仕事でもプライベートでもDRYについて以前より、様々な局面でDRYを意識するようになりました。頭の中でDRYを意識する部分が増殖した感じです。まだ読まれてない方は、読んでみると良いと思います。

# はてなの話やレコメンドエンジンの話も面白かったです。

著者の柴田さんのつぶやきにで、「大きな書店では，金曜くらいにフライング販売が始まっているかも 」という情報を手に入れたので、発売日の前夜に早速「みんなのPython 改訂版」を購入しました。

まず、一番初めの印象は「これは、みんなのPythonの改訂版ではない」ということ。何を言いたいかは追々明らかにしていきたいと思います。

この本の特徴として、プログラミング言語が初めての方、Pythonが初めての方にも、細かい配慮がされて書かれているということが挙げられるとおもいます。これは初版の時に自分もおせわになりました。特に、日本語の設定の部分は他に丁寧に書いてある文献があまりなかったので、良く参照したのを覚えています。

今回の改定版でもこの辺は健在。健在というより、配慮の仕方がパワーアップしていると思います。適宜、他のプログラミング言語にも言及されているのも好ポイント。プログラミングの様々な概念を学ぶのにも優れていると思います。

それから、素晴らしい感じで章の構成が変わっています。初版は、連続した内容が離れた章に分かれていたりしました。これにより、説明の分かりやすさのために、後から辞書的に使用する時の使いやすさが犠牲にされていたような気がしていました。今回はこの辺も絶妙に整理されていて、すごく使いやすくなっているという印象です。つまり初めてPytyonを使い始める時だけでなく、Pythonを使い続ける時のことも考えられているという気がしました。

という訳で、この本は「改訂版」というよりも、新しい素敵なPython本という感じがしています。「みんなのPython」という本の改訂版ではなく、「みんなのPython改訂版」という名の新しいPython本。初版持ってるけど改訂版買って良かったです。

プログラミングが初めての方には、素敵なエンジニアが丁寧に教えてくれるプログラミング入門書として、Pythonが初めての方には日本有数のPythonistaが書いたPythonの本格的な入り口の書として、現役Pythonistaの方にもちょっと困ったときのふりかえりの書として、おススメな一冊です。

# ただ、やはり特殊メソッドなどの少し高度なところの記述は、駆け足気味な感じがしました。それからメタクラスなどには触れられていません。この辺りは入門書としては、正しい作りだと思うのですが、この部分はPythonで珍しく分かりづらい部分であることも確かだと思います。自分も始めは苦労しました。という訳で、続編として、「まにあっくPython」のような本を書いていただけないかなと思ってみたりしています。

幹事を名乗り出たイベントが何とか形になってきました。その名もWACATE Short Short。

WACATEとは、年2回開催されている、若手テストエンジニアによる、若手テストエンジニアのための、若手エンジニア向けワークショップ。

そのWACATEの新企画でShort Shortというイベントを開催することになりました。Short Shortは、ワカテどうしの交流を目的としていて、年2回のWACATEの間にも集まろうというのが事の始まり。

テストに興味のあるワカテの皆さんは是非ご参加ください。

詳しくは以下のサイトで。

• WACATE Short Short vol.1 〜青年テストエンジニアの主張：ライトニングトークス大会〜

ついに、TestLinkの新バージョン。TestLink 1.8.1がリリースされました。
先行してリリースされた1.8.0はマルチバイト関連の対応を行う前のパッケージでしたが、今回は、それらの問題が解決され、まさに1.8系の正式リリースとなります。

TestLink 1.8.1は以下からダウンロードすることが出来ます。

• SourceForge.net: TestLink 1.8.1

インストールおよびアップグレードの方法は、付属のinstallation_manual.pdfをご参照してみてください。

ただし、1.8.1でグラフに日本語を表示する場合にはフォントを設定する必要があります。設定方法を以下に掲載しています。

• TestLinkJP.org: Tips

なお、TestLink 1.7.2以降からアップグレードする場合は、付属のインストーラが自動でおこなってくれますが、データベースのバックアップをとってから作業をすることをお勧めします。

xUnit Test Patterns (xUTP)読書会。この読書会は、前身のWorking Effectively with Legacy Code (WEwLC)読書会に引き続き、書籍xUTPをみんなで読もうというものです。

• xUnit Test Patterns読書会

個人的には、この本はしばらく前にxUnitで書くテストの粒度などの参考にするために買い、全ページをパラパラめくっただけで、棚に積んでありました。この分厚い本を一緒に読んでくださるということで、とても心強いものがあります。

この本は、ただのテストコード（テストスクリプト）の書き方の手引きといったものではなくて、開発者テストの考え方、「テスト」という言葉のとらえ方など、深くまで突っ込んだ内容になっています。まさに、アジャイルプラクティスの一点を深く掘り下げた一冊。パターンというのは、パターン化する対象（今回は開発者テスト）についてはもちろんのこと、それに関わる人についての深い洞察から生まれてきてるんだなーと思わされました。

読書会の内容は、参加者の方々が既に報告して下さいっています。以下、気づいた限りでリンクを張らせていただきました。

• 不悔必省: xUnit Test Patterns読書会
• m-takagiの日記: xUnit Test Patterns読書会
• ただぶろぐ: xUnit Test Patterns 読書会 #1 参加 (3月28日)
• 逃走航路@hatena: xUnit Test Patterns読書会 #1 - 読書会は一人で読み切らない人のための難民キャンプである
• 千里霧中: 第一回xUnit Test Patterns読書会参加

今回は、第3章を発表させていただきました。第3章の主題はGoals of Test Automation。TDDなど開発者テストの導入というのは銀の弾丸でなくて、導入にあたって、悲しい結果になる時と、嬉しい結果になる時の両方がある。開発者テストを上手く導入するためには、何を目指していくべきかということについて書かれた章です。

この「目標」というものを語るときには、開発者テストとQAテストの立場の違い、考え方の違いなどを意識するのが重要かと思いました。ともすると、そんなのテストではない、といった勘違いの原因になってしまいますので。例えば、同じJUnitを使う場合であっても、開発者のロールとしてテストを書く時と、テスト担当者のロールとしてテストを書く時では、使い方が違うということです。どちらの立場としての目標を述べているのかというのを意識するのが大事でしょう。
ここ一年ほど、TDDで何をして、その後のコンポーネントテスト（単体テスト）フェーズで何をすべきなのかということを考えてきたつもりなのですが、大分頭がすっきりしてきた気がします。

この辺りについては、t-wadaさんの以前のご講演資料に詳しいです。講演の動画も見れますので、ご参考にしてみてください。

• t-wadaの日記: 「第一回チキチキ 日本ペアプログラミングの会java-ja支部会」当日資料

# そういえば、この日記のエントリ、WEwLC読書会の淵源となった、炎上エントリと同じ日のエントリですね。

そういえば、読書会の当日に少しだけ紹介させて頂いた参考文献は「TestGoal」と「自動ソフトウェアテスト」の2冊。こちらはQAテストの方に焦点をあてた書籍です。

読書会では、いままでに知っているようで知らなかったことなど、沢山の気付きがありとても有意義でした。得られた気づきは今度どこかにまとめられればと思っています。幹事を務めてくださっているせとさんをはじめ、皆さん、本当にありがとうございました。次回もよろしくお願い致します。

WACATE-Magazineの第4号が発行されたようです。今回も無料とは考えられないほどの充実ぶり。ソフトウェアテストに興味のある方は、是非、一読あれ！

• WACATE-Magazine

先日、Testing Engineer’s Forum (TEF)の「第2回原因結果グラフ＆デシジョンテーブル勉強会」に参加してきました。第1回に引き続き、とても有意義な勉強会でした。

前回は原因結果グラフそのものを記述する部分を教えて頂きましたが、今回は、さらに発展し、原因結果グラフからデシジョンテーブルを作成するところまでを教えて頂きました。原因結果グラフは、独学で習得するのはなかなか難しいと思いますが、とても丁寧に説明していただき、理解に向けて一歩前進することができました。

講師、モデレータの秋山さん、鈴木さん、加瀬さん、そして会場ご提供くださったミラクル・リナックス様、本当にありがとうございました。

ケントベックの「実装パターン」を読み終わりました。サンプルコードはJavaで書いてありますが、他の言語でも共通する内容だったと思います。実際、自分は普段、C言語でコードを書くことが多いですが、それでも実際に使えそうなパターンがたくさんありました。

それから、何よりこの本の一番最後の結論に書かれているケントベックのメッセージに感銘を受けました。

すごい！この一言がこの本の価値をすべて表わしている気がします。他の人とのコミュニケーションがしやすいようにコードを書く。プログラミング言語は「言語」であるので、伝わることだ大事ですね。どのように書いたら伝わるかを常に考えながら書くこと。それが実装パターンに従って書くことなんだなと感じさせらました。

最後にまえがきから。

自己中コーディングをのり越えて、読んで気持ちの良いコードが書けるように精進していきたいと思います。現実は、まだまだですが……。

先週末は、Seasar Conference 2009 White に参加してきました。特に、t-wadaさんの「テスト駆動開発のこころ」とcactusmanさんの「HudsonによるOSS開発」を楽しみしていきました。

• Seasar Conference 2009 White

結論は、「行って得した！」です。正直はじめはアウェー感の漂う感じで怖じ気づきそうになりましたが、TDDのセッションとCIのセッションはとても良かったです。

TDDのセッションは、ご本人が「この部分はリピータの方もお得」と講演で仰っていたとおり、とても良い話を伺えました。TDDのこころ――これは肝に銘じておくようにしよう。資料がt-wadaさんの日記に公開されているので、TDDを志すならば是非ご覧ください。個人的には、「勇気か蛮勇か」という問いかけが一番ささりました。確かに、必要なのは勇気であって、蛮勇ではない。自分の行動であっても他人の行動であっても、それが勇気なのか蛮勇なのかを見極めながら前進する力って大事だなと思いました。勘違いしがちなので。
あと、バージョン絵巻物は圧巻でした。ブランチ戦略についてももう一度見直そうと思いました。

• t-wadaの日記: Seasar Conference 2009 White にて 「テスト駆動開発のこころ」というタイトルで登壇させていただきました

Hudsonセッションも、とても勉強になりました。Continuous Integration (CI)の基礎からHudsonの紹介と実例という感じで分かりやすかったです。実際に運用しているときの話ってあまり聞けるチャンスってないのではないかなと思います。
cactusmanさんの日誌には、今回の資料はアップされていないようですがデブサミでの資料がアップされいるようですので、CIを志すならば是非。特に、「チェックアウト」から始まり、「チェックアウト」に戻ってくるCIループのスライドはみておくべきだと思います。
それから、講演後の空き時間に、JIRAとの連携している画面を見せて頂いたのも良かったです。あと、HudsonのWeb APIについても少しだけ伺いました。今までやりたくてもでき中田事が、できるかも知れないというワクワク感を持って帰ることができました。プラグインも作ってみよう。あと、楽しい開発のためには、エモーショナルプラグインは入れた方が良いという事が分かりました……。

• cactusman日誌: Seasar Conference 2009 White

そういえば、確か、生でt-wadaさんのTDDのセッションを聞くのも、Hudsonの話を聞くのも初めてだな…….。資料や映像は読み込んでるのに不思議です。

他にも例えば、S2Swingのセッションなど素敵な話題が沢山でした。S2Swing惚れそうです。