海外で今話題になってる英語のニュース記事を、世界中のユーザからのコメントとともに紹介するだけのシンプルなサービスを作りました。一応スマホの各種ブラウザにも対応してます。^*1

できるだけ日本語ネイティブの人が英語のニュースを咀嚼しやすいように、

• 日本語の（正確にはダブルバイトの）コメントを優先的に表示したり
• 記事のタイトルを機械翻訳したタイトルを併記したり

という工夫をして、英語だけのニュースサイトよりも興味を持ちやすいように作ってみました。

ニュースの収集元はこんな感じです。ソーシャルブックマークサイトのTOP5サイト^*2を中心に、できるだけ有名どころから話題のニュースを収集するようにしています。

元々自分用に作ってたんですが、作ってるうちにこういう情報に他の人がどれだけ興味を持ってるのか気になりだしたので、試しに1ヶ月間公開してみることにします。興味のある人がいれば使ってみてください。今月の様子を見て、もし反響があれば来月以降も公開を続けるかもしれません。

注意：エンジニア向けのニュースを中心に配信しています

ニュースの収集元にredditやhacker newsを使っていることと、単にソーシャルブックマークサイトにエンジニア方面の人が集まりやすいという2つの事情から、今のところニュースの内容はエンジニア向けのものが少し多めです。本当は技術以外の情報も多く配信したい（というかもっと自分が読みたい）と思ってるので、もし次アップデートするとしたらそのあたりを考えたいと思ってます。

ちなみに、エンジニアの皆様向けにもう少し踏み込んでニュースのランキングロジックを説明しておくと、「話題になってるかどうか」の判定にはdelicousとはてなブックマーク上でのブックマーク数を使っています。1ヶ月以内に公開された記事で、これらの値が高ければ話題であり、低ければ話題ではないと単純に判定している感じです。

日本発の情報がいつ出てくるかワクワクしてる

最近だと、MobiRubyのニュースが開発中のbuco.meに掲載されてたりして面白かったりしたんですけど、こういう日本発の情報が世界でどう評価されてるかが少し見やすくなるところが、buco.meの一番面白いところかなと思ってます。海外にもRubyを好きな人が多くいることとか、PHPは海外でも批判されやすいこととかが、肌感覚で理解できていく感覚は新鮮です。

気になったニュースがあれば、元記事についてtweetしたりニュースソースに直接コメントを書き込んでみると、もう1段階別の世界が見えてくるかもしれません。ですが、まずはそこまでいかなくても、一旦このサイトをROMってるだけでも、海外の異文化理解の敷居が少し下がると思うし、そうなったらいいなと思ってます。おしまい。^*3

今年の1月に転職活動をしていた時のこと。ある企業で面接中に、仕事以外でどんなプログラミングをしてきたか説明する場面がありました。そこでPHPMatsuriに参加した事を少し話すと、「それって、晴海グランドホテルでやってたイベントですか。ああ、なるほど。スポンサーしてて、少し参加もしてきたので知ってます。」と返されました。その面接官だった方は、今の僕の上司です。

PHPMatsuriが転職に効く！とか、そんな安易なことを言いたいわけではありません（そんなに簡単だったらいいのですが）。言いたいのは、人と人はどこでつながるかわからないということ。人と会って話すことだけがつながることじゃないし、twitterで気になる人をフォローしたり挨拶したりすることでもまだ足りません。会場に足を踏み入れた瞬間から、人とのつながりは始まっています。もっと言えば、チケットを購入した瞬間から、いや、このブログを読んだときから、つながりは始まっているのかもしれません。例えば理由があって今回は参加できない人が当日ハッシュタグで情報を追うことなんかも、大事なつながりの一つの形だと思います。

人とつながることで、Matsuriでつながることで、エンジニアの世界は確実に広がります。今年6月にNIJIBOXで主催した勉強会に駆けつけてLTをしてくれて、7月からのアジャイルサムライ渋谷道場を主催してくれた@hirocastさんのことを初めて知ったのも去年のMatsuriに参加したおかげでした。去年Matsuriで見かけて一方的に存じ上げていた@koyhogeさんや@hnwさん、@sizuhikoさんなど大先輩方とは、PHP Conference Japan 2011やLLPlanetsの懇親会でお話させてもらえる機会に恵まれました。今回のこのリレーブログのバトンを渡してくれた@lllnorikolllさんとも去年初めてお会いできたし、ここには挙げ切れませんがMatsuriの最中やその後でMatsuriを共通点として知り合いになっていった人が本当に沢山います。

いまこの瞬間のつながりが明日どう変化するかは誰にもわからないけれど、つながった瞬間から全ての可能性が始まります。今年は大阪でどんな可能性と出会えるのか、楽しみにしているところです。

つながることの意味とか、肩に力の入った話はそれくらいにして、ハッカソンは純粋に楽しく、かつ学びの多い時間になることは確実なので、チャンスがあれば参加するに限ります。特に、最近めっきりソースコードを書かなくなったマネージャ/リーダーの方には、多少無理してでも参加することをお勧めしたいです。技術面で高い成果を挙げるリーダーを目指している場合、ソースコードを書かずに流されるままリーダーをやり続けてしまうと、次第に成長の限界を感じるようになるからです。（去年までの僕の体験談）

10/15-16に大阪で開催される今年のPHPMatsuri、参加チケットの購入は明日までとのこと。参加される人はぜひ。参加されない方も、ハッシュタグを追ったりブログを読んだり、思い思いにつながっていきましょう。お祭りは楽しんだもの勝ちです。

しかし、何で夜を徹してやるんだろうね。眠れないのか、眠らないのか。

まだ起きてるんですか 何が君をそうさせるのですか
眠れないのですか 眠らないのですか なにもせずにボーっとして

笑えないのですか 笑わないのですか たった一人その部屋の中で
もがきながら手探りで捜す 僕らが眠らない理由
（僕らが眠らない理由/GAKU-MC）

9月19日から5日間、車で関西方面に行って、ぶらぶらしてきたことを雑にまとめてみた。

どうでもいい割には長いから、暇な人以外には読むことをお勧めしない。

いつも持っていく旅行リュックに着替えだけつめて家を出て、近所のパン屋でやきそばパンと、オリジン弁当で作りたてのおにぎりを買って、近所のツタヤでイージュ★ライダー/奥田民生なんて借りちゃって出発した。

ちょうど台風15号が来てて、普通に観光したり景色が良いところに行くことは諦めざるをえなかった。名古屋付近が特に土砂降りで、掛川あたりだったかな、雨で前が見えなくて高速なのに30km/hしか出ないくらいだったから、妥当な判断だったと思う。

今回の旅行は、そんな風にして、おいしい食べ物をひたすら食べてくる旅行になった。

それでも、旅の後半になると天気が回復してきたから、ふらりと海を目指して

高知の西端にある宿毛湾に行って

夕日が沈むのを見てああってなったり

してきた。とても良かった。

今回の旅のテーマのこと

大体僕の旅行は仕事とか、普段考えてることを忘れるために行くことが多い。忘れたくなるくらい仕事とか普段の思考に浸ってるというのは、つまり疲れてる状態なので、いきおい旅のテーマなんて非常に適当に設定される。旅のことを十分に考える力が残ってることなんて滅多にないのだ。

去年イスラエルに行ったときは「バスで国内を南下して歴史のある砂漠を見てくる」がテーマだったし、今年1月にタイに行ったときは「英語が通じない国でバスとタクシーを使って、予約なしで飛び込みで宿を探す」ことだった。どこが面白いのかピンぼけしてるような、要領を得ないテーマ設定ばかりだけど、つまりそういうことなのだ。その土地その場所でしかできなさそうなことの中で、普段あまりやらなそうなことを、脳みそに負担をかけすぎない範囲で探した結果がテーマになる。

今回はというと、ふらっと立ち寄った本屋で見つけたこの本がテーマになった。

まずサブタイトルがいい。"The Visual Encyclopedia of SHIMA"ですよ。"ISLAND"ではなくて"SHIMA"と言い切るあたりが、実に男らしいです。帯もとても良いですね。釣りバカ日誌の北見けんいち氏絶賛！！っていう帯の本を、釣りに行く気なんてさらさらない、釣りバカ日誌のファンでもない僕が買っていくっていう構図は、つまり僕のケースで言えば帯のマーケティングは見事に外したわけだけども、この外れ方やいかに。とても良くないですか。どうでもいいですか。

とりあえず、日本の有人島443島が紹介されてるこの島図鑑、いい本です。全ページカラーですよ。

今回行くことができたのは、立ち寄りも含めると
・淡路島（兵庫県）
・与島（香川県）
・直島（香川県）
・坂手島（三重県）
の4島。

淡路島から鳴門海峡を眺む。

淡路島のSAで買ったトマトはもぎたてでおいしかった。

坂手島。の商店。外国の商店だよって言われても騙されちゃいそうですけど、こんな日本の商店もあるんですね。

坂手島の家屋の距離感。車が入ることは基本考えないんだろうなあ。

家を出たら海が見える生活はちょっと憧れる。

直島の（多分）メインストリート。坂手島に比べると、直島は交通整備しっかりしてたなあ。人口500人と3000人の差なのかな。

直島って美術館が多くてアート好きな人が訪れるみたいで、島のいたるところにこんな展示があって

それはそれで楽しめたのだけど、僕はどちらかというと、こんな無造作な風景の方に、大いに島を感じたりしてきたのでした。

直島にはレンタルサイクルがあって、楽に島を回れた。一日かけてゆっくり島一周とかしてみても、楽しめるんじゃないでしょうか。

高知のおいしいパン屋のこと

一人旅って、当たり前だけど、旅行中は5日間全てが自由行動なので、食事も好きなタイミングでとることができる。そして車を運転しているとお腹が空いてくるので、車で通りかかった場所で、めぼしいところがあればちょくちょく車を停めて買い食いしながら運転してた。これはけっこう車の旅の醍醐味だったかも。

そして、例えば高知のパン屋がものすっごくおいしかったわけです。どうでもいいですけどね。もうね、この外見からして

外れないでしょ。しかも店の名前書いてないっていうね。

この陳列。おいしいでしょ絶対ー。

田中ロール。名前のセンス最高。おいしいです。店長さんが田中さんていう名前なのかどうか、考えるとちょっとドキドキする。

B.B。って何か知らなくて、店の人に聞いてみたら、「昔のパンの名前じゃけんねえ」って言ってた。エクレアっぽいパンでしたよ。結局、B.Bが何の略かはわからなかったけど、これもおいしいです。

ミニ・ボウシはボウシっぽいつばがついてるからそういう名前だそう。「うちのはつばが短いけん、ボウシじゃないってよう言われるんよ」って、店の人が笑って説明してくれた。

気になるこのすっごいおいしいパン屋の場所は。ここ。ここ。

きっとこの文章を読んでる人の誰もが簡単には行けない場所にある気がするし、このパン屋のことを書いてどうするのって自分でも思うんだけど、ここはインターネットの可能性を信じて、いつか誰かが行けることを願って書いてみる。営業時間もわからないけど、僕が行ったのは平日の夕方だったので、平日の日中行けばやってるんじゃないでしょうか。多分。

ついに忘れ切れなかったこと

そんな風にして、色々なことを忘れるべくして過ごしたけど、結局忘れ切れなかった言葉がありました。それは、7月の最後のRubyKaigiで@kakutaniが「The Gate」というセッションの資料1枚目で使っていた、こんな言葉です。

"It's only after you've lost everything that you're free to do anything" （映画Fight Clubからの引用）

雑に日本語にするなら「全てを失った後にだけ、いかなることでもできる自由が訪れる」のような言葉になるのかな。

この言葉が、今も頭から離れないんですよね。僕は、僕たちは、この半年で、1年で、数年で、何を失って、どんな自由を手に入れたんだろう。みなさんは失ったり自由を感じたりする瞬間はありますか？

僕はこれからも、ちょいちょいこのフレーズを思い出していく気がします。

とにかくパーティを続けよう、これからもずっとずっとその先も

っていうわけで、ごくごくふつうの日記おわり。読んで下さったのは、きっと暇な方だと思いたいですが、ありがとうございます。こういうふつうの日記を、ここ半年くらい全然書けていなかったので、時間をとって簡単にでも書けて個人的には満足しています。

最後に、日本の無人島の売買のサイト例なんかを載せて終わり。うっかり買える値段でもないけど、もし自分が買ったらと考えて妄想を膨らませてみるのは、少し楽しいかもしれないし、どうでもいいかもしれない。

Lightweight Language Planetsに参加して、LT発表させてもらいました。

VBAユーザにとって、涙なくしては語れないLTができたと思います（←。僕今はもうVBAユーザでも何でもないんですけどね。学生時代の思い出が詰まった、思い入れの強いプログラミング言語です。

ちなみに今回はこんな会場で

満員御礼になってました。会場、沢山人がいて萎縮しましたが、楽しいイベントでした。

学んだこととか本当はしっかり書いていきたいところだけど、時間がとれそうにないので今日は一旦資料と写真だけ置いておきます。この後時間がとれたらまとめていきたいなー。

スタッフの皆様、来て頂いたみなさん、お疲れさまでした＆ありがとうございました！

発売前から著名な方々から好評を博していて、読書会も既に企画されてる話題の「アジャイルサムライ」だけど、読みやすさがとんでもないことになってるのでお知らせしておくよ。

ポイント１・・・図・表・コード・挿絵の挿入率が95%

明日から書店にも並ぶので、ぜひ本を手にとってパラパラめくってみてほしいです。2p-287pまでの見開きページ中、図・表・コード・挿絵が挿入されていない見開きがわずか3見開きページのみ。読み手を飽きさせない原著者Jonathanの配慮に、ぜひ胸を熱くしてください。

ポイント２・・・4ページに1回の割合で出てくる訳注

本文2p～287pの中に訳注の数が70個記されていて（@remore調べ）、4ページに1回は訳注が見つかる計算になります。@kakutaniと@nawotoや訳者のお二人が力強く読み手の理解をサポートしてくれます。

普通の本だと、訳注には出典や情報のソースが記されているだけということが多いけど、アジャイルサムライの訳注はそれにとどまらずに、監訳者たちがよく使うモックフレームワークの紹介（p241）とか、2011年6月現在のTDDを学ぶためのオススメ本について一言書いてあったり（p270）などなど、本書を読み解く手助けに留まらずに、そのあと羽ばたけるところまでのサポートまで考えて作られている本です。

読まない理由が見つからない

ソフトウェア開発をする側の人、開発成果物を受け取る顧客の側の人、その他全てのソフトウェア開発に携わる人に一読してほしい本になってます。アジャイル開発にあまり馴染みのない方がこの本を読むと、アジャイルソフトウェア開発宣言に書かれている内容がどういう意味や意義を持っているのか、その深さをうかがい知ることになるはずです。

ちゃんとした書評は、ちゃんとした人たちのレビューを読んでみてください（@kakutaniさんの書評、@nawotoさんの書評、@ryuzeeさんの書評、@kaorun55さんの書評）。勢いづいてamazonで今すぐ買ってもおｋ（※アフィリエイトリンクじゃないです。念のため）

参考までに、目次も載せておきますね。

目次

日本の読者の皆さんへ
謝辞
お目にかかれて光栄です
第I部「アジャイル」入門
　第1章 ざっくりわかるアジャイル開発
　第2章 アジャイルチームのご紹介
第II部 アジャイルな方向づけ
　第3章 みんなをバスに乗せる
　第4章 全体像を捉える
　第5章 具現化させる
第III部 アジャイルな計画づくり
　第6章 ユーザーストーリーを集める
　第7章 見積り：当てずっぽうの奥義
　第8章 アジャイルな計画づくり：現実と向きあう
第IV部 アジャイルなプロジェクト運営
　第9章 イテレーションの運営: 実現させる
　第10章 アジャイルな意思疎通の作戦
　第11章 現場の状況を目に見えるようにする
第V部 アジャイルなプログラミング
　第12章 ユニットテスト：動くことがわかる
　第13章 リファクタリング：技術的負債の返済
　第14章 テスト駆動開発
　第15章 継続的インテグレーション：リリースに備える
第VI部 付録
　付録A アジャイルソフトウェア開発の原則
　付録B オンラインリソース
　付録C 参考資料
監訳者あとがき
索引
著者・監訳者・訳者について

どこよりも早いブログ！・・を書こうと思ってたものの、@shinyaa31さんのブログとか@tomy_kairaさんのブログとか内容てんこもりでお届け済みなことを確認したので、僕の方は写真メインでTDD Boot Camp in Tokyo 1.5に参加してきた感想などまとめていきます。（USTの録画はこちら。@brtrvierさんありがとうございます！）

大事なことを最初に

・渋谷の会場に集まれた皆さん、ustでサテライト参加されていた皆さん、お話を熱心に聞いて頂いてありがとうございました！失敗談を交えてお話して少しでも背中を押すことができればとLTを申し出ましたが、話しているうちにやっぱり、こちらが勇気づけられているように感じました。

・@t_wadaさん、講演ありがとうございました！いつも講演の内容を勉強させてもらっているのですが、ロジックと想いが伝わってくる話し方も凄く勉強になります。今回も多々ご指導いただきありがとうございました。

・スタッフの皆さん、LT発表者の皆さん、ありがとうございました＆お疲れ様でした！そして@hirocastさん、主催おつかれさまでした〜！（先月の勉強会から引き続きで色々とお世話になってます。拙い内容だったにも関わらず、LTのお時間を頂けたことも大変嬉しかったです。アジャイルサムライ読書会でもよろしくお願いします）

TDDでつまづきやすい（と思うところ）を話してきたよ

TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ

View more presentations from remore

バッドノウハウ満載だと思うので良識のある人以外は見ちゃいけない資料になっちゃってるんですが、なんていうか、TDDを実際に実践してみると、本や演習とかで培った理論や知識、ロジックが通用しない場面がいくつもあることがわかってきたんです。

その事がTDDを続けていくときにかなり大きな障害になると感じたので、その経験をお話させてもらうことで、これからTDDを始めようとしてる人や、TDDをチームで使っていこうとしている人が同じところでハマらないように、ハマっても早く抜け出せるようになるといいなと思ってお話しました。

写真で超〜ざっくり今日を振り返る！

細かく書く体力が残っていないので、写真で雰囲気を伝える作戦で今日の流れを超〜ざっくりまとめます！

朝の様子

@t_wadaさんの講演

ランチのお弁当おいしかったです。

午後のLTの様子

ペアプロでTDDのワークショップ

一日の終わりに、KPTで振り返り

夜ご飯

ビール！！！

最後にもう１度、TDD Boot Camp 1.5の皆さんお疲れ様でした！

また近々（来週のRubyKaigiや、近々始まるアジャイルサムライ読書会や、その他の機会に）皆さんとお会いできることを楽しみにしています。

今週末に食べる地元札幌、大心のラーメンが楽しみで楽しみで震える@remoreです。 ※本文と写真は関係ありません

昨日GREEのセミナールームで行われた「PHPでTDD&CIワークショップ」に参加させて頂いて、本当に光栄にも@t_wadaのFizzBuzzを書くデモのペアプロパートナーをやらせて頂きました。帰宅したけどまだ手を洗えない状態です。※握手はしていません ※オーラか何かがまだ残ってる

さて、会場でRedbullをうっかり2本も飲んだせいで色々と学びの多かった勉強会だったので興奮が覚めず寝れそうにないので、今日学んだことを書き残しておきます。内容はいまTDDを勉強している人向け。

テストコードをテストできる。仮実装の付加価値

仮実装ってご存知でしょうか。こんな感じのコードの事です。

function func_plus($a, $b){
  return 10; // 仮実装：一旦定数を返しておく
}

class MyTest extends PHPUnit_Framework_TestCase
{
    public function test_テストコードの例(){
      $this->assertEquals(10, func_plus(3, 7));
    }
}

「仮実装」という言葉はケント・ベックの「テスト駆動開発入門」に出てきて、昨日@t_wadaも使っていたので、TDDをする人の間では使われる用語なんだと思います。

さてこの仮実装ですが、「テスト駆動開発入門」ではレッド・グリーン・リファクタリングのTDDのリズムを素早く刻むための戦略として紹介されているのですが、@t_wadaは「仮実装は同時にテスト駆動開発の重要なトリックをもたらす」、と紹介していたのが大変勉強になりました。

それは、仮実装によってテストコード自体をテストできるという付加価値が生まれるという言及です。つまり、一旦定数を返す仮の実装を行うことでテストコードに対して完全に正しい振る舞いをするようにした上で、xUnitを動かしてグリーンにする（テストをパスさせる）というプロセスを経ることで、振る舞いを検証しているテストコード自体が正しく書けていることを検証できる、そしてこれはテストを実行可能なコードの形で書いているからこそ得られるメリットであると解説していました。

「テスト駆動開発入門」を一回読んだ限りの理解ですが、僕は今日勉強会に参加するまで、TDDの仮実装のプロセスにこんな付加価値があることに気付いていなかったので、大変勉強になったという次第です。（本の中でこの事に言及した節はなかったような気がするのですが、実は書かれていたのかな。ご存知の方いらっしゃったら、@でmention頂けると助かります）

例外処理のプラクティス

昨日のペアプロのソースコードレビューの時に出た話題で、PHPUnitのマニュアルでも丁寧に解説してくれていますが、例外処理の2種類の書き方って、try～catchを使う方法と、アノテーションを使う方法の2種類あるじゃないですか。（setExpectedException()を使うやり方もありますが、読み易さを重視して一旦アノテーションで紹介）

これまでお好みでどっち使っても良いと思ってたけど、@t_wadaから上手な使い分けのプラクティスを紹介してもらって目から鱗だったので、こちらも紹介しておきますよ。

テストコードが複数行にわたっている場合に、try〜catchでかなり的を絞った書き方ができる

例えばこんな感じで、例外が発生すると思われる箇所をテストコードで明示できるというところがコツ。

class MyTest extends PHPUnit_Framework_TestCase
{
    public function test_例外が起こるテストケース(){
      init();
      validate($something);
      // ここまでは例外が発生しないはず。次から例外をチェック
      try{
        func_hoge();
        $this->fail();
      } catch (InvalidArgumentException $e) {
        $this->assertEquals("error message", $e->getMessage());
      }
    }
}

また、@expectedExceptionアノテーションとは違って例外の中身までチェックできるというメリットもある。

シンプルな例外発生確認であれば、@expectedExceptionアノテーションがベター

@expectedExceptionアノテーションはtry〜catchの方法とは違って例外発生の的を絞れないものの、テストコードを簡潔に書けるので、可読性がとても高い。可能な場合は（例外発生の的を絞る必要がない場合、つまりテストコードが１行で収まるなどの場合は）こちらで書いた方が後から見通しがよくなる。

class MyTest extends PHPUnit_Framework_TestCase
{
    /**
    * @expectedException OutOfRangeException
    */
    public function test_例外が起こるテストケース(){
      func_hoge();
    }
}

２通りの方法のメリット・デメリットを理解して上手に使うべきとのことでした。

Jenkins CIのコツ：困ったらJenkins wikiを調べる。

帰り道で、@cactusmanに教えていた秘伝の技です。Jenkinsで困ってgoogle調べてもなかなか情報少ないんですよねー、ってぼやいてたらJenkins wikiにけっこう情報が書いてあります、と教えて頂きました。で、アドバイスに従って実際業務で困っていた内容を調べたら簡単に見つかったという。こういうコツってネット見てるだけだとわからないので、本当に助かりました！

というわけで、とても充実した時間を過ごさせて頂いた勉強会でした。主催の@tsuyoshikawaさん、講師をして頂いた@t_wadaさん、@cactusmanさん、@yamashiroさん、参加者の皆さんお疲れ様でした＆ありがとうございました！！

またTDDBC in Tokyoやその後のイベントでお会いできるのを楽しみにしています。

昨日、2か月前から企画をあたためていた勉強会を無事終えました。大小、直接間接、さまざまな形で協力してくれた皆さん、皆さんお忙しい中、どうもありがとうございました！ほんのわずかでも、参加された方が何か持って帰っていってもらえるような場が作れていたら嬉しいです。

※昨日のミニワークショップで使用した、PHPでTDDにトライする課題をgithubにアップロードしてあります。興味のある方はご覧ください（そしてぜひ試してみてください！）

アンケートや皆さんからの感想をもとに個人的に小さな振り返りをしてみたので、報告を兼ねてこちらに書き込んでおきます。

良かったこと

今日までにアンケートに記入して頂いた13名中、10名の方から「アジャイル開発に関するLT」を次回も開催してほしい、という声を頂きました。Woohooooo! Big thanks to @shirokappa and @hirocast (and surely @kakutani too!)

次いで「ミニワークショップ」を次回も開催してほしい、と言って頂いた方が9名。ありがたいです。次回機会をつくれたら、ぜひ講師つきで開催したいです。でも何より昨日は、@kakutani の語りが全てだったなーと個人的には。言葉にしてしまうと意味が絶対に伝わらない自信があるので、ここには書かないことにしますが。

反省点

長くなるので箇条書きで。

• 今回、ワークショップと読書会を同時に進行させるっていうウルトラCに挑戦したんですが、見事に失敗しました。読書会を回すことに集中してしまい、ワークショップでつまづいて壁を突破できなかった方のサポートがほとんどできなかった。
• あと、開発環境として何をどこまで準備してくればよいかも不明確だった。本気でワークショップをやるなら、この辺をはっきりさせないといけない。
• 懇親会を開催したらもっと良かった。
• 時間の管理がルーズだった。終わる時間が30分以上ズレ込んだので、ご迷惑をかけてしまった方が多かったはず。

これがただのぼやきにならないように、次回はもっと良くしたいな。

最後に

くどいようですが、本当に皆さんありがとうございました。ありがとうございました。何回でも言わせてほしいです。ありがとうございました！！

本当にくどいので、最後に。昨日オススメのアジャイル関係の本の紹介し合う読書会をしたのですが、紹介された本を順不同で（というか紹介された順か）紹介。

• 実践アジャイルテスト
• @heroween推薦。読書会も各地で進行中のようです。
• アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
• @aic0o推薦。一番共感したプラクティスは「人ではなくアイデアを批判する」、とのこと。
• アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング
• @kakutaniと@shirokappaのお二人大絶賛。褒められすぎて表紙まで絶賛されてた。読んでみるつもり。
• アジャイルサムライ（近々、日本で発売予定）
• @kakutaniのイチオシ。僕も（翻訳文をレビューさせて頂いて）一足先に読ませて頂きましたが、読み進めていくうちに、アジャイル開発の広範な知識が流れるようにつながって理解できて、良書だと思いました。オススメ。（この辺のことは多分別のブログ記事でまた書きます）
• アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
• @hirocast推薦。僕も今読んでます。エンジニア以外の人にもぜひ読んでほしい、っていう@hirocastの言葉が印象に残ってます。

あと、僕のLT資料を晒しておきます。今回の勉強会が開催されるまでについて書いてみました。

という流れで、次は来週伺う勉強会（PHPでTDD&CIワークショップ）と来月のTDD Boot Camp in Tokyoへ参加します。また皆さんにお会いできるのを楽しみにしています！

2011/06/21追記：
@shirokappaさんの参加感想ブログ
@norry_gogoさんの参加感想ブログ

　
巷で噂のケント・ベックの「テスト駆動開発入門」読みました。めっっっちゃ良かったので、今日はその内容と実践してみた事なんかをずらずらずらずら書いていきます。独断と偏見に基づいてまとめていくよ。

めっっっちゃ良い本なのでTDDに興味のある人は全員買うが吉です。写経して手を動かしながら学べるこの内容で3150円は破格。
※言い回しが複雑な事があって、人によってはケントベックの文章がちょっと読みづらく感じるかもしれませんが、内容は確かです。

テストコードの書き方のルール４つ

「テスト駆動開発入門」を読んで一番響いた＆実際に役に立ったテストコードの書き方たちを、4つのルールにまとめてみました。

1. 無駄なテストコードは書かない

何をテストすべきかについて、ケントベックは以下の4つをテストすればよいと答えています。（p190）

• 条件分岐
• ループ
• 操作（データクラスのメソッド呼び出しとか）
• 多相性（ポリモーフィズム）

2. 壊れにくく、独立したテストをつくる

xUnitであればsetUp()やtearDown()メソッドを活用しながらテストコードを書く。

壊れにくいこと - 「予想外に失敗するテストは、アプリケーションの一部が予想外の方法で別の部分に影響していることを示す」（p190）

DBや各種設定ファイルの内容、サーバやネットワークの状態によらずにテストが期待通りに成功するようにテストコードを書きましょう。

独立していること - 「テストの実行は、テスト間で決して影響すべきではない。」(p123)

例えば、テストスイート全体を実行しなくても、一部のテストメソッドだけ抽出して実行してもテストが期待通りに成功するようにテストコードを書くこと。

3. メソッド名は後から読みやすいものを

テストコードに書いたメソッド名は、自分で呼び出して利用することはない（テストスイートが実行される時だけ使われるだけ）。なので例えば、テストメソッド名は超長くなってもOK。これはコメントやドキュメントの記述量削減にもつながる。

class MyTest extends PHPUnit_Framework_TestCase
{
    // こういうメソッド名でも良いけど
    public function testGetUserName(){
    	$this->assertEquals( "tarou", GetUserName(1));
    }

    // 少し長くてもちゃんと説明してる方が分かりやすい
    public function testGetUserName_Invalid_null(){
    	$this->assertEquals( "tarou", GetUserName(null));
    }

    // ちなみにPHPUnitなら、使いたければメソッド名に日本語を使って書いても大丈夫
    public function testGetUserName_正常系_100を入力(){
    	$this->assertEquals( "tarou", GetUserName(100));
    }
}

4. assertは具体的に

良い例悪い例を書いておきます。

class MyTest extends PHPUnit_Framework_TestCase
{
    // 悪い例：null以外を返せばテストを満たしてしまう
    public function testArea_Bad(){
    	$this->assertTrue(rectangle->area() != 0);
    }

    // 良い例：具体的な期待値を指定している
    public function testArea_Better(){
    	$this->assertTrue(rectangle->area() == 50);
    }
}

実際にテストコードを書く上でのコツ５つ

異論や個人差もあると思うけど、このおかげでテストコードがグンと書きやすくなったコツを経験談を交えながら書いておきます。

1. テストリスト作りは効果高い

ケントベックが本でかなり丁寧に解説しているテストリストですが、実際作ってみると効率的にテストコードを書けました。リストの書き方は自由ですが、ケントベックは実装する必要のある操作の例やリファクタリングを書くべきと指南しています。僕の場合は、操作の例を引数つきで書くことが多いです。やってみた効果の感想としては、

・頭が整理される

頭が整理されて無駄な手戻りが少なくなります

・集中力を持続しやすくなる

作業中に別観点でのテストが思いついても、リストに書き残しておけるので安心して作業に戻れる

・進み具合が見える

実装が終わったテストコードの項目を二重線で消したりすると進捗を可視化できる

2. モチベーションが命

テストファーストで開発していて、うっかり自分で書いたコードでハマって抜けるまで時間がかかったりすると、いろいろいたたまれない気分になることがあります。というか、よくなります。自分のスキルを疑い始めたり、お客さんに申し訳ない気分になったりと、これがけっこうつらい。そうなることを全力で避けるための3つのポイント。

・レッド（テストコードの記述）、グリーン（コードを実装）、リファクタリング（重複したコードを取り除いていく）のリズム感が全て

自分で書いたテストコードでハマってもヘコむことがあると腹をくくっておくこと。

・テストスイートの実行に時間がかかりすぎないように

テストスイートの実行に10分以上かかっていないことを確認する。実行に長時間要するテストは頻繁には実行されなくなり、しばらく実行しないと、おそらく動作しなくなる。（p190）

・無駄な時間は使わない

例えば失敗することがわかっているなら、作成したテストを実行しなくてもよい（p122）

3. テストコードは可読性がクソ重要

コードは書くよりも読まれるケースの方が多い。常に読みやすいコードを心がけること。読みやすい最小限のコード行数は3行（p160）

4. 一つのテストメソッドの中でのassertは少なめに

一つのテストメソッド内で呼び出すassertの数は、経験で言うと通常1、2個、最大でも4～5個程度におさえます。1つがベスト（@t_wada談）。理由は、2つ以上assertを書くと、エラーが発生した場合にその後のassert文が実行されず、いくつのassertが通っていないか、一回のxUnitの実行で見通しが悪くなってしまうため。なお、assertを複数書く場合は、それぞれのassertの目的が重複していないことを確認した上で追加する。

5. 既存のコード資産にTDDを導入するときは心してかかる

既に動いているソフトウェアのソースコードの中身がいかに汚くても、実際に動作しているので正義という考え方があります。いろんな面で正論なのでこれはこれで良いと思うけど、中長期的に運用していくソフトウェアであれば技術的負債を早期に返済していくことのメリットもやっぱり大きいですよね。既存のコードにTDDを導入することについてケントベックは、「難問で、執筆すれば一冊の本になる。」(p196)と前置きをしながらも、スコープを絞って、劇的にシンプルにしたくなる衝動を抑えながら部分的にTDDを導入していくべき、とアドバイスしています。

TDDの更なる普及のためにいろいろな疑問に答えます（ケントベックが）

いわゆるFAQコーナー。後々役に立つことになりそうなtipsたちを本文中から拾い集めました。

Q：自動テストの使用をどのように普及させればよいか

A：テストを用いた説明を求め、提供すべき。面と向かってTDDを押し付けることはしない。(p134)

Q：欠陥が報告されたらどうすればよいか

A：失敗する最小のテストを作成し、実行した後で修正する。回帰テストは、完全な先見があれば、最初のコーディング時に作成していたテストである。回帰テストを作成するたびに、どうすれば、最初にそのテストを作成できていたかを考えよう。（p136）

Q：一日の作業の終え方は？

A：チームで開発する場合、一日の終わりにはグリーンの状態で終える。（でないと、次の日の始めに別の人がビルドできなくなる）また、一人で開発する場合、最後のテストを失敗のままにして終えることで、次の日に作業を再開するときの手がかりとすることができる。（p146, 147）

Q：いつテストを削除すべきか。

A：削除しても自信が持てること、他のテストが同じストーリーを表現できていることの2点を満たせているなら、削除してよいとのこと（p194）

言語別のノウハウも必要

上記では書ききれなかったのですが、例えばPHPでテストコードを書くときには変数の型を意識して書く必要があったりと、言語別に必要なノウハウもあります。来月のTDD Boot Camp in Tokyo #tddbcではその辺りの事とかTDDの普及についてとかをLTのテーマにさせてもらうことになりそうです。

本で紹介されていたケントベックのテストコードを素早く書くための戦略（仮実装、三角測量、明白な実装）をやってみた感想なんかも、機会があれば書いていきたいなー。

ざっくり言うと、継続的インテグレーションの最大の利点はリスクが軽減されることにある。以前に経験したことがあるプロジェクトでは、長期のプロジェクトの終わりの段階になっても、実際に終わってみるまで、それがどれくらいの長さになるのか見当もつかなかった。（出典：Continuous Integration / Martin Fowler）

今週雨が続いて「もう梅雨かあ」とボケボケな事を考える程度には田舎者の@remoreですこんばんは。もうこっちで暮らして10年は経つんですけどね。

さて、この前「アジャイルプラクティス」を読了して、アジャイルの魅力に取りつかれ始めています。2ヶ月前にまとめたPHPのテスティングフレームワークとBDD（ビヘイビア駆動開発）について調べた。で少し取り上げたJenkins CIですが、試してみたい一心で実際にインストールしてみると、期待通りちょー簡単にCI（継続的インテグレーション）を行う環境が構築できました。

ちょー簡単なので、おひとりさまの開発環境をお持ちのそこのあなたも使ってしまえば良いと思います。今日はWindows上(XAMPP環境)でJenkinsをセットアップする時に注意しないといけない点を簡単にまとめておきます。

大体の流れ

@ryuzeeさんのPHPでもHudson使うべしの内容そのまんまでインストールができます。大体の流れは以下です。(XAMPPインストール済みの環境を想定しています)

• PHP側のセットアップ
• PEAR経由でPHPUnit, Phingをインストール
• PHPUnitのインストールはこちらの記事を参照
• Jenkinsのセットアップ
• Jenkins.jarをダウンロード。後は"java -jar jenkins.jar"で実行すればlocalhost:8080でアクセス可能。
• プラグインを追加（PhingプラグインとxUnitプラグイン）
• タスクを作成

これだけ。慣れてる人は10分くらいでセットアップ終わると思います。↓完成イメージ

Jenkinsが使うフォルダ構成（ver.1.412を使用）

Windows7上で"java -jar jenkins.war"で動作させた時のフォルダ構成はこんな感じになります。（Note: @ryuzeeさんのマニュアルに従うと、linuxサーバ上でのJenkinsのJobsのフォルダは/var/lib/jenkins/jobs/になりますが、ここではwindowsにインストールした場合の事を書いていきます）

・C:\Users\[ログインユーザ名]\.jenkins\
　⇒jenkinsが使う全てのデータが記録されるっぽい
　
・C:\Users\[ログインユーザ名]\.jenkins\jobs\[ジョブ名]\workspace
　⇒各ジョブでユーザが使うファイルが格納される。

ここから先は、@ryuzeeさんのマニュアルからカスタマイズする必要があった部分や補足。

build.xmlに記述する内容

workspace直下に以下のbuild.xmlを用意するだけで動く。カンタン。ちなみに、このbuild.xmlの内容はHudsonでPHPのユニットテストの記述を参考に作成しました

<?xml version="1.0" encoding="utf-8" ?>
<project name="TestProject" basedir="." default="test">
 <target name="testtarget">
   <delete dir="reports" includeemptydirs="true" />
   <mkdir dir="reports" />
   <phpunit haltonfailure="false" printsummary="true">
     <formatter todir="reports" type="xml" outfile="unitreport.xml" />
     <batchtest>
       <fileset dir="trunk/php/test">
         <include name="**/test_*.php" />
       </fileset>
     </batchtest>
   </phpunit>
 </target>
</project>

各自でカスタマイズが必要なのは、

• filesetタグのdirプロパティ
• includeタグのnameプロパティ

の2つ。ここにテスト対象としたいPHPUnitのテストコードを指定します。dirプロパティはworkspaceフォルダをベースに記述します。上記のbuild.xmlの例は"C:\Users\[ログインユーザ名]\.jenkins\jobs\[ジョブ名]\workspace\trunk\php\test"フォルダ以下にテストコードを格納している場合の例。

jenkinsの設定

・「設定」＞ビルド＞「ビルド手順の追加」より「Phingの呼び出し」を選択して、
　「ターゲット」欄にtargetタグに設定したname属性("testtarget")を記入。
　更に、「高度な設定」の「ビルドファイル」には"build.xml"と記述

・「設定」＞ビルド後の処理＞"Public testing tools result report"にチェックを入れた上で
　Pattern文字列の欄に"reports/unitreport.xml"と記述
　（Phingがビルド時にPHPUnitのテスト結果をreports/unitreport.xmlに吐き出すので）

XAMPP環境で起こるエラー

上記の設定を終えてjenkinsでビルドを実行すると、"BUILD FAILED"とか"Can't load default task list"っていうエラーが出るはずです。（windows環境の場合）

エラー文言で調べると、こちらやこちらの記事に同じ現象の報告があったので参照して解決。僕の場合は、php.iniを以下のように書き換えました。
include_path = ".;\xampp\php\PEAR"
　↓
include_path = ".;\xampp\php\PEAR;\xampp\php\PEAR\data"

感想

• セットアップでつまづいた人向けに、他に参考になりそうな資料をいくつか
• HudsonでPHPのユニットテスト
• CentOS5.5でHudsonでPhingでPHPUnitでCloverな生活
• PHPでビルドツール（Phing）を使う感覚がめっちゃ新鮮で良かった。
• Jenkinsいろいろできて面白そう。下記で紹介されてるコードの自動解析（phpmdやphpcpd）なんかもやってみたいなあ。
• Hudson+phpmdでPHPコードの問題を自動検出する方法
• Hudson+phpcpdで継続的に重複コードをチェックする

2011/9/15追記：Amazon EC2環境でJenkinsを使うときにハマるポイント - If you encounter an error when you install jenkins to your amazon EC2 instance

windows環境っていうテーマからは離れちゃうけど、Amazon EC2環境でJenkinsをインストールして%service jenkins startコマンドで動かしてたら、以下のエラーが出て、グラフ画像の生成に失敗していた。(I simply encountered following error.)

Graphics N/A
Unable to access X. You need to run the web container in the headless
mode. Add -Djava.awt.headless=true to VM.

この現象、ほかの人もハマってたみたい。公式wikiにも現象が報告されてるけどどれもうまく動かない。(Other folks seems encountered same error. Official wiki has some information about this, however, it didn't work to me.)

で、色々試したけど、結局デフォルトで使われるOpenJDKではなくSun SDKを使うことで解決しました。ちなみに、Sun JDKのインストールはここからrpmファイルを落としてきたのでメモ。(And finally, this post took me to the goal, which just use Sun SDK instead of OpenJDK to run Jenkins. Btw, this is the link where you will find latest Sun JDK binary. FYI.)