TDD BootCamp 北陸1日目

Mar 13, 2010

※ 2日目もあります

イベントに行ってきた

去年の年末にあったTDD読書会＆ふりかえり（実はその日記書いてない;）からの流れも含めて、なんと！

あの！ t_wada が！

とか書いておくと follower がやってきてくれるかもしれないので名前出しを先にやってしまうけど、

に参加してきました。トラックバックセンターは

TDD Boot Camp 北陸に登壇させていただきました - t-wadaの日記

かな？

会場

白山里のウェブサイト/白山麓の自然に囲まれた天然温泉の宿、体験・研修交流館

で、分かる人は「バードハミング鳥越を越えて花ゆうゆうのもうちょい先」で分かります。ものすごい山奥を想像してたけど、地元民からすればある程度は想定の範囲内。ただし電波的にはかなり孤島で、

docomo, au	OK
SoftBank, WILLCOM, e-mobile	NG

です。施設の回線も弱く、イベント参加者の tweets が一部の人に偏っていたのはそういう理由からです。

小松駅集合

イベント自体には何も手を出していなかったので、送迎と酒の準備だけしました。朝に高速乗ったらどしゃ降りで前なんにも見えなくなって焦ったけど、洗車しなくてよかったなとか違うことを思ったりしていた。

小松駅で目印のために MacBook を広げてお迎え。なぜかこの瞬間、カバンの紐をまとめていたゴムがちぎれてしまった。まぁもう12年目だもんな、これ。

誰一人面識もないうえに場所もよく知らなかったけど、なんとかなるもんです。Google と Twitter があればボクらはもう平気。なのかもしれない。

内容

レクチャー
Workshop 1
Workshop 2

レクチャー

t_wada 節の初歩¹。

現代の開発において

バージョン管理
テスティング
自動化

以上は

三本柱である。

「三種の神器では切実さが足りない」とも仰ってまして、あーなるほどなぁと。

三本あって初めて自立できる

のだな。

以降は個人的に刺さった部分だけ箇条書きメモ。

バグの発見は早ければ早いほどいい
- （最近、自分はこの言葉を自明として端折る傾向がある）
テストパス率を計るとか、そういうんじゃないんだ。一つずつ進むんだ。
TDD の「黄金の回転」
- （JOJO成分が足りなかった。一瞬分からなかった。）
テスト手法の観点から「書くべきテスト」を挙げることはできるのだが、TDDのテストはまず「不安」の部分をテストすることが大事
スピリチュアルプログラミング(笑)
- 祈ることでなく確かめることが大事
「デバッガではダメです。再現できないから。」
書籍売り込みモード(違
Fragile Tests （一部の変更でドガーンとコケるテスト）
- 内部構造に依存しちゃダメ。（同じことがプロダクトコードの結合にも言えるな。）
FakeIt
- テストコード自体の間違いを生まないために、無駄っぽいテストを軽視しちゃダメ
- （テストファーストに徹しきれていないので、ときどきポカをやっちゃうんだよな）
三角測量
- GREEN のテストにテストを足して RED になることを確認して、コードを書く
Obvious Implementation
- （「えいや」）
TDDに才能は必要ない
- 「オレのは『技術（ワザ）』だ」

小さい単位

小さい単位に分割すること自体はスキルであり、慣れが必要であるという点が個人的には実はとても共感できるポイントだった。自分のコードが testable になってきたと感じられるまでに恐らく1年くらいは掛かっているから。

ちなみに読めるものは以下のものが該当するので、もしかしたら2年掛かっているかもしれません。

テストの書き方

assertEquals( expect, actual )

実は、この書き方、今まで逆にしていた。確認したい動作を先に書いて、期待する結果を後に書いていた。考え方次第なのかもしれないけど、

ゴールを先に書く

ということが大事だと、急に目が覚めた。反省した。

Feedback 重要

「決まっているものを変えない」「動いてるコードに触れるな」は No Feedbacks だよなと思った。そうか、そうだな、Feedback があることも安心感に繋がるんだ。

Workshop1 - 簡単なワードフィルタ実装

ワードフィルタの実装をペアプロ & TDD で行う。

Ruby で憧れの @ukstudio たんとペアだお。でへへ。と思ったけど、ここでいきなり宗教戦争勃発。Ruby というキーワードが同じだけで、Emacs vs Vim、日本語キーボード vs 英語キーボード、Test::Unit vs RSpec、もう何もかも違う。がーん、uk たんとは分かり合えないお。

ということで、あんまりよくないんだろうなと思いながら全面的に @ukstudio さんにおんぶにだっこ。rspec を丁寧に教えてもらう。

rspec すげぇ！絶対使う！レポート見やすい！ pending 超ステキ！
普段テストの名前に頓着がないことが発覚

これまでも TDD ライクではあったんだけど、入り口が「とにかくユニットテストを行う」だったので、まずは網羅的にメソッドのテストを書くということしか意識できていなかった。単純に「test_目的のメソッド()」という形で作ってゴリゴリテストするというスタイルで、実際、プロダクトコードの読みやすさには気を使っていたけどテストコード自体はお世辞にも読みやすいとは言えない状態だった。

またこの形では確実にテストしにくいメソッドが出てくるのも気になっていた。普段は敢えて private などは作っていないのでテストできるが、でもこいつだけテストしても仕方ないよな、というメソッドは出てくる。このとき、単純にプロダクトのメソッドとテストメソッドの関係を 1:1 にするのではなく、意図とテストコードの関係を 1:1 にして記述できていればよいのではないかと思い至った。実際には他のペアを含めたペアプロ後の発表を聞いていて思ったんだけど。

この気づきは大きかった。すぐに活かすことはできないけれど、徐々にテストコード自体、あるいはテストの実行結果を設計書として読み下せる状態を目指したいと思う。

Workshop2 - 大変だ！仕様変更だ！

ペアを変えて仕様変更に取り組む。

Ruby組4人のうち、@mitukiii と @wtnabe は両刀だったこと、PHP組が2人しかおらず、ペアの変更ができなかったこともあり、このセッションは PHP にスイッチした。

今度は逆に自分の方が TDD のスタイルに慣れていたのでいつもの SimpleTest + Terminal 上のテスト実行の形で引っ張る。Workshop1 の C# ペアだったかがやっていたのを真似して git に突っ込みながらやることに。

ただ、説明しながら書きながら思ったのは、やっぱり自分はテストファーストじゃないんだなぁって辺り。事情があって急いでいたのもあって、いつもの要領でプロダクトのメソッド2つ書いてテストメソッド2つ書いて、みたいなこともやってしまった。悪い例を見せてしまったかもしれない。ごめんなさい。

この仕様変更ではある程度何をどう実現するのかは自由だったので、ペアで設計を議論した。これもやりたいやりたいと思いながらも普段なかなかできなくなっていたことなので、とてもよかった。インターフェイスをどう決めるかによってステップの大きさが変わるケースだったので、より小さいステップになる方法を選ぼう、と言えた自分を誉めたい。そういう発想ができる程度にはイテレーティブにやれているんだなと振り返れた。

※ ところで、この仕様変更では「NG ワードを複数設定できるようにする」という変更があったのですが、他の組の発表で、filter そのものはいじらず、filter を複数に増やすという方法を採用しているところがあって、こーれはやられたなと思いました。

発表の際にちょっと勝手なことを言ったんだけど、もう一度まとめておこう。

PHP は標準でテスティングフレームワークが付属していない
「Java にとっての eclipse」のような絶対的な環境がない
（フルスタックフレームワークが個別にテストツールも持っている²）

ため、「Terminal でテストを動かすのはあまりやらないんじゃないか」という旨のことを言った。これはやっているところが「ない」という意味じゃないんだけど、一般的な「PHPのコードを書いている人」にとってはテスティングフレームワーク自体があまり馴染みがないのかなということは感じている。

BootCamp 会場では Rubyist, Pythonista に比べて PHPer が少なかったわけだけど、いわゆる「現場」で PHPer の方が少ないっていうのはかなり考えにくいことで、その比率だけ見ても違和感はあるし、このセッションでペアを組んだ方も ZendFramework は使っているがテスティングフレームワークは使っていない様子だったし、これまで PHP の仕事を発注した経験からも、TDD というかユニットテストを揃えて早期に自動テストを回し始めるスタイルでやっているところはかなり少ないんじゃないか。他の言語での開発を発注したことはないので、PHP だけの特徴かどうかは分からないけど。

こうした話とはまた別な理由で PHP ではテストのやりにくさを感じているんだけど、これはまた後日書けたら書きます。

合宿 - 新たな「黄金の回転」の誕生

ご飯と自己紹介。仕事で GAE ! Python ! 何それ都会ってすげぇ！

持ち込みました。「白山」とふぐのぬか漬け。概ね好評でした。白山とぬか漬けの回転、ビールとビーバーの回転。回る回る。

自分はこの夜の部ではもう一切機械には触れず、酒を飲みながら @yuuitiro さんと酒談義したり、どうしても生で聞きたかった @ukstudio さんの職業プログラマ観を聞いたり、最後の方はなんか愚痴ったりしていました。おっさんにはきつい時間でしたが、とても楽しく、またためになる時間を過ごせました。ありがとうございます。

2日目に続くよ。

@nagise 談 ↩
これは当日言わなかった ↩

人生初指圧

Mar 13, 2009

日々

整体行ってきた。人生初整体。と思ったけど正確には接骨／指圧だった。

というわけでゴキゴキやられるでもなく、ぐいぐいマッサージされるでもなく、なんかあっためてちょっと触って様子を見て、あとなんか体操を教えてもらってきた。正味30分ほど。まぁ安いからいいんだけど、なんかちょっと拍子抜け。

ただ自分があえて言わなかった悪いところも指摘されたので、分かってるんだなぁと思う。続けて行けないとあんま意味ないんだろうけど、どうなるかな。

News って内向けに使えるかも

Mar 13, 2007

スラッシュドットジャパン｜京都大学のネットニュースサービスが3月を持って終了

を見かけて思いついたこと。

一斉に配信可能
- っていうか、購読させる必要があって配信とは言わないけど
サーバ側でネタごとに分類可能
- 個々人のスキルに依存するメールのフォルダ分けよりも絶対に確実

っていうのは、こまごましたメールアドレスの管理をしなくてよく、参加者のスキルに依存しない分、内部向けでメーリングリスト代わりに気軽に使うのに向いている仕組みじゃなかろうか。コントロールメール投げなくてもアーカイブもそのまま共有できるし、人の出入りに強そう。

ただし、リモートからアクセスする必要があるケースはちょっと考えなきゃいけないのと、添付ファイルに相当するのは今でも uuencode なのかな？ってのが気になるかな。

あと特定の人たち”だけ”に配信したいという要求には応えられないので、そういう用途には使えないな。（もしかして認証掛けることで可能？）基本、オープンでいきましょうよという身軽な組織なら結構使えそうな気がする。News Reader 機能付きのメールソフトも多いし、プロジェクトごとにカテゴリを作っていけばなかなかいい感じにならないだろうか。例えば Trac が News と連動できたら面白くない？

独自実装の部分は断って書いてくれないと勘違いしかねないよ

Mar 13, 2007

【コラム】そろそろきっちりJavaScript 第2回無名関数についてもう少し考える (MYCOMジャーナル)

せっかく最近の事情を反映してきっちり保全されそうで、まとまりがあって日本語で書かれている JavaScript の記事が Web 上にできるのかと思っていたんだけど、ミスなのか気づいてないのか、

/* dollar関数 .. $() は document.getElementById() の別名として利用できる */
/* 引数は配列でも受け取れる。多用されるため、覚えておいて損は無い */
>>> document.write('<h1 id=\'myHeader\'>Hello!</h1>');
>>> $('myHeader').style.color='red';
"red"

なんてことをサンプルとして書いちゃってる。

これは困る。

純真な子¹は $() がどこでも使えると思っちゃうでしょ。これはこの場合は Firebug の独自実装なので他の環境では使えない。あるいは有名どころのフレームワークを調査してこれこれでは使える、って書いてくれるなら親切だけど、それはクレクレ言いすぎかな。

とにかくこの連載では Firebug で動作確認していくってのはまぁ一応断りがあるんだけど、サンプルのコードが Firebug 依存なのかどうかくらいは明確にしておいてほしいな。この記事のターゲットは当然バリバリの JavaScript 使いじゃないわけだから。

あと細かいけど

さて、JavaScriptでのオブジェクトはJSON(JavaScript Object Notation)という表記法によって表現することができる。

なんか卵が鶏を生んでるような。

うーん。

で、今頃気づいたけど、MYCOM のコラムにはトラックバックできないのね。

そりゃ含む意味もあるさ ↩

なるほど prototype.js って便利かも

Mar 13, 2006

実際の活用についてはよく分かっていないんだけど、javascript のオブジェクトの定義はどうにか書きやすくなんねーのか、と思ってあれこれ調べて試行錯誤したのちに prototype.js の中身と、サンプルとして Validator を覗いてみたら、結構感動した。なるほどねー、確かにこれは書きやすい。

初期化子っていうやつを使うのがクールらしい
JSON もおんなじだ

何をしていたのかって言うと、JsUnit でテストが書きたかっただけなんだけど、なかなか勉強になりましたマル

いやね、javascript って慣れてくると書きやすくて面白いんだけど、オブジェクトの定義と動かして確認するのがだりーなと前々から思っていたのね。その辺の鬱陶しさが昨日、今日とあちこち調べてだいぶスッキリしましたよ、ということです。今までは一発勝負の関数くらいしか書いてなかったけど、もうちょっと複雑なものも今後は書けるように…なったらいいな。なれるかな…。

携帯電話のサブスクライバIDの送出は off れる。はず。

Mar 13, 2006

トラッキングcookieがスパイウェアなら、EZwebの携帯電話は100％がスパイウェア入り

100% じゃないよ、という重箱の隅つつきなので Trackback せずにひっそりと。

2005年4月14日以降、サブスクライバID は EZ番号という呼び名に変わり、ユーザーの端末操作にて送出の可否を設定できます。らしいです。

EZ番号 (サブスクライバ ID) の通知設定機能追加について (auからのお知らせ 2005年4月4日版) を参照されたし。

ちなみになぜ au だけ取り上げられているのか分からない人のために補足。携帯電話にはユーザーエージェントとは別に本当に個体を識別するための ID があります。docomo はユーザーに本物の個体識別番号を要求する際は警告メッセージが出るはず。vodafone は知らない。au のこれがセキュリティーの文脈で取り上げられるのは、上の機能追加以前は公式サイトでも何でもないどんなサイトでも、ユーザーに何の断りもなしにこの情報が取れるようになっていたから。

と言っても、個人情報を収集していない限り同じサブスクライバ ID の「端末」がアクセスしてきているということしか分からないので、どこの誰がどんなことしてるということは分からない。

ただまぁ、普通に考えて、普段 off にしといて必要なサイトに当たった場合だけこんな面倒くさい操作を経て on に切り替える、なんてことはやらないわなぁ。それこそキーロック並みにワンアクションで切り替えられるとか、docomo みたいにその都度ダイアログで選択するとかでない限り。

無印丸紙管ラックはもうなくなります

Mar 13, 2005

電話台をどうしようかなと実は結構長いこと悩んだ。市販の電話台とか FAX 台ってのは上に電話か FAX を置いて下は電話帳とかが入るのが基本の形なんだけど、この電話帳の入る部分にサーバを置こうと思っているので、下手に仕切りとかついているのはとても使いにくいし、そもそもケーブルの引き回しのできるものが非常に少ない。

じゃー組むかということなんだけど、ワイヤーシェルフはなんか学生の一人暮らし風な感じがして避けたい¹ということで、今回はもっと学生風じゃないのかというツッコミを軽く流しながら無印の丸紙管ラックでいこうということになった。天板耐荷重10kg もありゃ電話には十分だ。サーバはどうせ床に置くし。

muji.net で品揃えを調べて、モノは店で買おうと思って買いに行ったらなんとこの春のカタログからも店頭からも消えているではないか！またか。またおれの目のつけたものが一つこの世から姿を消すか。

ということで muji.net での販売が終了したらたぶんなくなります、丸紙管ラック。角管のものは同じ無印のクリアケースを収納しやすい規格になっているんだけど、逆に丸よりラインナップが少ないので、なんか作ろうかなと思っている人は早めに muji.net でおさえた方がいいですよ。送料500円がちょっとシャクだけど。