■1 以下は7/8(木)の記述。記述を一日間違えてしまったが、画像をputしなおすのも面倒なのでそのまま。

■2 見学

いよいよ30週突入と納期も近づきいてきたことと、少し前に前置胎盤のリスクが高まっていたこともあって、妻の診察に同伴。

中の人エコーのライブ中継を見学。面白い。心音も聞けた。

結果としては、既に前置胎盤は問題ないのだが、塩分の摂取量が多いようで、このままでは妊娠中毒症になる危険性があるとのこと。言われてみて、よくよく考えると我が家の食事は塩分が多いかもしれない。

■3 すみた新メニュー制覇

亀戸まで行ったので、ついでにすみたでお昼。新メニューが登場したとのことなので、早速すべてに挑戦。

• 肉玉ぶっかけ
• 梅おろしぶっかけ
• いよかんシャーベット
• ざるうどん++

これからの季節、いよかんシャーベットはさっぱりしていていいね。ぱっと見以上に手間がかかっている(と思う)。

■1 「Mocks Are'nt Stubs」

Fowlerタンの新着記事。久びさに更新して「キター」だけでは申し訳ないので(というのだけでもないが)Fowlerタンに「DI記事と同様に翻訳して公開しちゃいますけどいいですか」メールを出した。

「これは是非ともやりたい!!」と思って脊髄反射でメールを出しちゃったんだけど、既に取り掛かってる人がいたらどうしよう。まあ、個人で訳す分には勝手だからやっちゃうけど。

■2 オブジェクト倶楽部納涼イベント＠7/9

(書くのが一日ズレちゃった)クリスマス会に続いての第2弾イベント。今回は前回よりも人前に出る要素がより強くなったので、達人プログラマTシャツ「テストとともに往け」バージョンを着用で臨んだ。

私のロール

今回の担当は:

1. 受付でモギリ
2. ライトニングトークスの露払いというか噛ませ犬

の2点。 受付は、準備側のオペレーション改善により、前回よりもマトモにこなせたと思う。

一方、ライトニングトークスは「ほんとうに怖いのは人間」という特撮の王道で話を進めるつもりだったが、明らかに準備不足。しかし、私と同様に準備時間が少なかったはずのマキノ氏はバッチリ5分以内で収めていた。ツカミの写真も洋風プレゼンで良かった。彼我との差は何だったのだろうなあ。

言い分を殴り書きしておくと:

• はるか昔の話とはいえ、5分でまとめて話せるほど整理できていなかった
• ドラは鳴るためにある(単なる開き直り)

けれど、せっかく与えられた機会を活かせなかったことは事実。猛省。今後の教訓にする。

ワークショップ

• 「要求開発」と「システム開発」：山岸耕二氏
• DOAを知っておこう ：渡辺幸三氏

と、アダルト指定の部屋に常駐。「要求開発」という言葉はキャッチーでいいな、と思った。詳細と売り込み方については今後の活動に期待。渡辺さんの講演はDOAに対する態度と認識を改めざるを得ない内容だった。「モデリングとはテキスト情報をベースに似顔絵をホワイトボードに描く作業である」。これを「WKのモデリング第一原則」と呼びたい。

■1 考えるヒント (1),(2)

いずれもarton師父のエントリ。「メモ未満」と書かれているが、ここに鉱脈があると私のダウジング・ロッドは反応しているのであった。MDB(with JCA)、JMS1.1で非同期分散がルールエンジンでLightweight Languageなのだ(この文は私の電波ゆんゆん)。

『屠殺場5号』以外のヴォネガットなら個人的には『猫のゆりかご』だなあ。ボコノンボコノン。

■1 プロジェクトで一緒に作業している人のはてなダイアリーがアンテナに入っている罠。……ああ。さらに発見。プロジェクトのウェブロ率75%(?)

■2 CruiseControl

ま た I S O - 8 8 5 9 - 1 か !!

■3 「Mocks Aren't Stus」(2)

うっかり「訳します」とか書いてしまったばっかりにkdさんとこやmarsさんとこで晒されてちょっとビビる。やっちまった後なら晒し上等なのだが、やる前からだとやはりビビる。ざっくり読んだ感じでの予防線を張っておくと、今回は:

• Dependency Injectionほどの重要記事ではない
• 勇ましいタイトルとは裏腹にFowlerタン弱気

である。しかし、TDDを実践する者にとっては非常に重要。日々TDDを実践している人は、(いつ出てくるかわからない)私のウソ翻訳を待つよりも、とっとと原文を読むべし。

書き殴りついでに記しておくと、今回はFowlerタンが弱気なことも、MockとStubの問題の根深さ(あるいは区別のどうでもよさ)をあらわしているとも言えるかも。

ちなみに、今回の私の翻訳動機は、記事中に'tortoise(リクガメ)'という単語が出てくるからなので期待しないでネ！

■1 [映画] 『マッハ!!!!!!!』、というか『オンバク(ONG-BAK)』＠九段会館

村から盗まれた、みんなの心の拠り所である石仏オンバクの首をムエタイの達人である青年(お寺育ちで天涯孤独の身)が取り戻しにバンコクに行くお話。

『マッスルヒート』みたいになっちゃったらどうしようと思ったら、トゥクトゥクが『ブルース・ブラザーズ』を経由して『千里眼』風味(ムエタイのがすごいわけだが)。

だが、タイ映画としての落とし前も忘れられてはいない。仏罰ドーン!!

■2 Eclipse, Groovy, Seasar

ダウジング・ロッドが反応しました。

■3 『逃亡者』

阿部チャン! 水野美紀! というわけで俄かに期待しているわけだが。

■1 作戦会議

takaiさんと品川の韓国料理店で作戦会議。これがいわゆる謎めき系ってやつか。勇気をもらいました。がんばろう。

■2 Maven 1.0

ついに胸を張って使えるようになった——のか？ Mavenはちょっと行き詰るとplugin.jellyを読まないといけないのがキビシイ。Maven-Groovyってないのかなあ。

で。日本人としてのMavenの発音は「めいばん」でいいんですかね？ 私は「生きてま」の中の人の影響でそう呼んでいるのだが。

■3 酔っ払って帰宅するとバートホールドが血まみれなわけだが。

事故？ 左脚の爪が取れちゃったよ……応急処置でカットバンを貼る。明日、妻に病院へ連れて行ってもらおう。

■1 『スチームボーイ』

拝啓大友センセイ。大友センセイがこのプロジェクトを発表してから、今日この日までに私は大学を留年したもののどうにか就職・上京し、映画秘宝ライターから落ちこぼれ、結婚し、2回の引越を経て会社を変え、いまや程なくして父親になろうとしています。

センセイ。私の待ち焦がれていたスチームパンクがこれなのでしょうか。確かにスチームではありましたけれど……。

■2 『バリスティック』

ルーシー流のレイ・パーク対決だけを楽しみにしていた身にとっては辛すぎる一作であった。

■1 「Lightweight Language Weekend」で発表することに

縁あって、よりによってこの私が発表することになりました。初日。Language Update。Groovy。

他の言語の発表者の方がたがすごすぎてブルってます。よもや発売初日にチケットを調達したイベントで自分がしゃべることになるとは思わなんだ……。

■1 Spring Pad - J2EE Development Without EJBについて

いろんなところで話題になっている。素晴らしすぎるまとめで、こんなの公開しちゃっていいんですか?!——こういう内容なら邦訳待ちというか、読まなくていいかも。我われには日本のロッド・ジョンソンがいるしネ!

とはいいつつも、吼えっぷりは相変わらず頼もしく、邦訳が出たら読んでみて溜飲を下げてみたくもある。

IoCDI,AOP,TDD,OOPは私にとっても既定路線。粛々と進んでいくだけで、ここに足りないものがあるとすれば、Lightweight Languageと非同期メッセージングだな。

メッセージ駆動Beanに対応する軽量なソリューションについては今後に。

というのは、少々ズルい気もするが(ザッツ・エンタープライズな環境ではwithout EJBできないじゃん!)、無理矢理無くさなくってもいいかもね。MDBは使うにしても極力Thinにして、onMessageの先でDIすればいいんだし。

■1 「Development of Further Patterns of Enterprise Application Architecture」

大物が来た! kdさん、どうします？(と振ってみたり)

ちなみにモックとスタブの話はまだまだ途中も途中です(誰にともなく言ってみる)。Fowlerタンからメールの返事も来ないので、よしんば完了していたとしても公開はできないんですが。返事が来ないのは英文が意味不明すぎたからではないことを願うばかり。

■2 [映画] 『カンフー・ハッスル』、というか『功夫』特報

我らが周星馳の最新作の「予告篇」がかかっていると聞いて、SPE配給作品に突撃したらば、15秒ぐらいの特報だった……。『映画秘宝』の写真のほうが情報量が多いという罠。2005/1/15公開、だっけ？

■3 『スパイダーマン2』＠錦糸町楽天地シネマ8

というわけでSPE配給作品。上に書いた通り、私の目的は15秒で終わってしまったので、オマケの127分……と思っていたのだが、ダニー・エルフマン節全開でアメコミ風に「これまでのあらすじ」が背景で展開されるオープニングクレジットから目を奪われてしまい——

泣いちゃった。私の妄想していた『ゼブラーマン』はこんな感じだった。気高く生きろ。そして死ね!

とはいえ、だ。前作でもそうだったのだが、CGムービーアクションシーンになるとどうしても興醒めしてしまう。編集やカット割で頑張ってはいるのはわかる。わかるのだがしかし。『マッハ!!!!!!!』を体験してしまった今となっては尚のこと、退屈してしまうのだなあ。罪な映画だ。オンバク!!

■1 ほげほげ駆動開発

流行していると思うのだな。KentBシリーズ第2弾の 『User Stories Applied: For Agile Software Development』にも「story-driven agile process」という言葉が出てくる。

ちなみに本書は、アジャイル開発スタックの上から2番目を攻略する、極めて実践的で有用な、KentB＆Fowlerタンによる『XPエクストリーム・プログラミング実行計画』(緑本)の全面改稿アップデート版、といった趣。目下、ここに書いてある通りに本当にプロジェクトは回るのかを検証中。バーンダウン!!

■2 バーンダウン!!

バーンダウン・チャートについては、『アジャイルソフトウェア開発スクラム』に詳しいようなのだが、スクラム本は積読。私がこの概念をはじめて知ったのは『リーンソフトウエア開発』にて、だった。

バーンダウン・チャートは非常に興味深い——プロジェクトの進捗が一目瞭然なのでシャレにならない。激オススメのプラクティスである。

■3 バーンダウン!!!

tpircsさんにびびびと反応していただいたので、もう少し実例を交えて説明したいと思います。ただし、私ははぶさんでもなければkdさんでもないので、さっくりサクサクとは説明できません。明日も休みではなく出撃予定。でも、せっかくの機会なので書いてみようとは思ってます。いましばらくお待ちください……。

追記

http://www.kakutani.com/articles/XPmatsuri2004-LT.kakutani.pdf

ひとまずこれで勘弁してください。まとまった見解はまたいずれ、機会があれば。

■1 「オブジェクト指向スクリプト言語Groovyの紹介」

上原さんによる、いとすさまじかりけるドキュメント。

7章が!! 7章が!!!! うわああああああああああああああああああああああああああ!!!!!!!!!(AA略)

(Groovyラボ経由)

■2 『どうも、いまのところDependency Injectionには「依存性の注入」という訳をあてるのが普通なようです。でも、すごくわかりづらくないですか？』

わかりづらさの犯人は誰だ？　私かなぁ……。たぶん私だと思う。

たどたどしく弁明すると、ここでの「依存」は「依存物」というよりは「依存性(依存関係)」の意味合いが強い。モノが他のモノに対して持つ(持たざるをえない)依存性、とでも言おうか。そして、

• オブジェクト間の結合は可能な限り疎にしたい(依存性は薄くしたい)
• しかし、オブジェクト達は実行時には結合されなければならない(必要な依存性を満たさなければならない)

このジレンマに対する解決策のひとつ(one of them)がDependency Injectionパターンである、と。

……ここまで書いていて、WRさんによる「依存性を(インスタンスに)注入する」という丁寧な解説エントリに遭遇。なるほど。ただ、ツッコミで書かれているような「依存性＝良くないもの」という認識は私とは異なるけれど。グレガグラムの人が、「システム間の結合を疎にする最善の方法は、結合しないことだ」と言っていた(要旨)と思う。けだし名言。

でも、私は「の」とか「に」とか「を」とかは書いてませんので為念

Dependency Injection(依存性注入)とは書いているけれど。Dependency InjectionはあくまでDependency Injectionですもの。

■1 「Lightweight Language Weekend」懇親会

参加予定です。

■1 XP祭り2004で身を切ってバーンダウンチャートを紹介してみた

行ってきた。面白かったー。忍者テスト!! I like too!

昼休みに天野さんに「ライトニングトークスの人数が足りないから出ろ。景品あげるから(要旨)」と言われて、急遽出場することに。で。この日記のネタにするつもりだったバーンダウンチャートについて、近棟さんの発表の合間にOOoにて資料を無理矢理作成、PDF化。発表にあたって自分に課した発表でのゴールは:

1. とにかくウケを取ること
2. ドラを鳴らされないこと

以上2点。結果としては会場としてはそれなりにウケた(と思う)が、またしてもドラは喰らってしまった。OOoの最後のスライドをきちんと見せられなくて口惜しかったので、ちょっと修正した完全版(?)を自分のサーバに置いておきます(PDF:616KB)。「祭」終了後にお客様からの了解はとりつけました(ありがとうございます)。

教訓: ライトニングトークスではネタは早め早めに出す。

ともあれ、発表でのいちばんの懸念点は、Rubyistの端くれとして、咳さんやたださんにウケたかな？ということだ。

懇親会は事情(後述)により不参加。なので、月間JavaWorld2004年9月号の記事に「や、やられた!!」と感じいったIBMの太田さんにイベント終了後、ご挨拶(ライトニングトークス参加者つながり)。関心領域が近い(同じではないことが重要)ので、少し意見交換など。箱崎での発表には、都合をつけて参加したいなー、と思っている。21世紀のプログラミングモデルはTDDがtest firstというかassert firstなDependency InjectionでMockとStubをTell, Don't Askなのだ。

■2 畏友と半年ぶりに再開

たまたま両国に来ていたので、晩飯を一緒に。無難に牛角。出世頭の話は面白い。こんどはきったんも誘って一緒に呑もう、と。ていうか、きったんはLightweight Language Weekendに来ないのか。私の晴れ舞台 :-p なのに。

■1 『リーンソフトウエア開発〜アジャイル開発を実践する22の方法〜』

ついに実物を手に取る。訳者あとがきであっても、書籍に自分の名前が印刷されているというのは感慨深い。

ジム・ハイスミスの「まえがき」のすぐ後ろの「まえがき」でケン・シュエイバーが「アジャイルシステム開発は、複雑適応系のような難解な理論や科学なしでも説明することができる」と書いてあって、ちょっとドキドキしますね。

■2 身を切ったバーンダウン:その後

昨日の発表は血を流してウケを取ったが、今日は現実に戻る。顧客と定例ミーティング。現状をありのままに報告し、今イテレーションを収束(convergence)させるべくタスクを調整。うっかり従来型の思考に傾きそうになったところで、コーチに「正直に」と諭される(実際にはもっとスマートな方法だったけど)。

manholeさんからは「数字は嘘をつかない。私は数字を信じる(要旨)」と目の醒める一言。

また、開発タイムにちょっとハプニング発生私はソロで作業することに。で、うっかりカウボーイに逆戻りしちゃっていたところ、戻ってきたJa-Jakartaの偉い人がさりげなくペアになって助けてくれた。今日はこれまで以上にXPの厳しさ・難しさ・素晴らしさを感じた一日。

■3 「バーンダウンチャートという名前を言わずに使ってみようと思います。」

私は名を捨てて実を取る、という視点をうっかり忘れがち。肝に銘じておこう。まあ、私は多分に「バーンダウン!!」という語感に惹かれているとはいえ、それにしてもバーンダウン、バーンダウン、とわめきすぎではある。

■1 被害妄想ギミ

自分が、初歩の初歩である『Effective Java』の内容をきちんと把握していなかったことに打ちのめされるている。以下、被害妄想ギミ:

1. 「かくたにさんの資料だけじゃよく分からない」
2. 「バーンダウンチャートの紹介。いまいちよくわかってないけど・・」
3. 「デザインパターンは日本語に訳した方がいい、と思う」

あうあう。1.については後日補足予定(またそれか)。

■1 BPR: Build Process Reengineering

でも、思い起こすとたいしたことできなかったなぁ。CVSの導入とか、ビルドの自動化とか、テストプロセスの改善とか…それすらかなり骨を折ったんだけど。プロセス改善がメインでアーキテクチャレベルの介入はまったくできず。

とdotタンはおっしゃるが、SCM*1やビルドプロセス、テスティングといった地歩固めをせずにアーキテクチャを云々するような人の設計判断なんて信用できない。dotタンの場合は、状況や時間の問題もあったと推測するのだがいかがか。

また、すでに開発が走っているアーキテクチャの改善は納期とのチキンレースでもある*2。忍者式テストを導入したとしても、一人前の忍者になるまえにタイムアウトということにもなりかねない。……ともあれ、お疲れ様でした。

で。ビルドといえば——と我田引水すると、いまのチームでは Mavenが制式ビルドツール。Mavenの威力は、multiprojectで JAR + EJB(+ doclet) + WAR + EAR のフルセットを体感するのが一番。multiprojectで一度、強烈な体験をしてしまうと、ツールをチームのビルドプロセスに合わせてカスタマイズするのではなく、チームのビルドプロセスをツールに合わせたくなるし、合わせたほうが効率的。これをうちのチームではBPR(Build Process Reengineering)と呼びならわしている。ちなみに、名付け親はコーチだ。

Mavenについてはもうちょっと書きたいこともあるけど、今日はこれぐらいで。

■1 『Version Control With Subversion』

我われには「Book」があるわけだが、表紙がウミガメなのがイイ。

■2 safarieclipse: Eclipse 2.3.1 Safari Search Plug-in

Eclipseからsafariの検索ができる。まだ3.0には対応していないのが残念だが「「will soon be available in version 3.0.」とはある(でもこの「soon」に過度な期待を持ってはいけないんだよな)。

■1 xSpecとjBehave

ま た c o d e h a u s か ! ! !

xSpecという考え方がある(らしい)。xUnitによる単体テスト、あれはテストではない、仕様だ。なのに「テスト」と呼んでしまっている。だから、従来からの伝統的なテストの概念やQA部門と開発チームとのあいだに混乱と軋轢が生じる。名前重要。

テストケースと呼ぶから、プロダクトコードの後にユニットテスト書くような輩が絶えない。テストではなくスペック(仕様)と呼べばよい。仕様をプロダクトコードの前に書くのはフツウだ。これまでだってそうしていたはず。

で。このxSpec的概念を実装していると思しきライブラリが、jBehave 。テストメソッドはtest[DoSomething]ではなく、should[DoSomething]。assertEqualsではなくVerify.equal。

——と、脊髄反射的に書いてしまったが、そもそもフライパン氏のxSpecの話って私は機会がなくてちゃんと聞けてなかったり。軽くググってみたけど、よくわからない。

verify? should?

Specの発想は全く同じだよ。shouldとverifyの感覚は逆だ(xSpecではverify?がテストメソッド)。

とあるけれど、いまやってるプロジェクトではテストメソッド名は「testShuoldDoSomething」となっていることが多い。テストメソッド本体のいわゆるassertの部分では、Mockをたくさん使っているところはmock.verifyになっている(なってしまう)。メソッド名で表明(should〜)して、本体で検証(verify)する、というのはそんなにおかしい話でもないと思うのだがいかがか。ご参考まで。

jBehave、使用上の注意

jBehave は現在、安定した1.0版リリースに向けて、ガリガリ開発中。なので、いまのところは本番プロジェクトでの採用はオススメしません。けれど、開発版やスナップショット版を試して、フィードバックをもらえるととても嬉しいです。α版、β版、そして最終リリースのアナウンスはメーリングリストに流します。

JUnitからのスイッチングコストが気になる。いまやEclipseからの手軽な実行と、Maven(Antでもいいけど)からのバッチ実行＆レポート生成ができないと、代替品としての捺印ナビリティはお話にならない。今後に期待しつつ、生温かく見守りたい。

■2 「Don't Mock Me: Design Considerations for Mock Objects」

xSpecの話題がADC2004のサイトのどこから辿れるかと思ったのだが、果たせず。その過程でExperience Reportsの中に、上述タイトルのペーパーを発見。PDFをざっと眺めたら、きわめて実践的(当たり前か)な印象だったので、近いうちに読んでみよう。

■3 隅田川花火大会

今年も自宅から。義母が料理を色いろ用意してくれて充実の鑑賞体制。妻の友人が赤子を連れて遊びにきたが、生後1年に満たない彼は花火にはまだ興味は持てない様子。

今年はプログラムを見ながら、第1会場のコンクール作品を堪能してみた。が、やはりヤケクソな感じの第2会場のほうが好みだ。

ポケモン花火は、どこらへんがポケモンなのか微妙だった……。縁取りが黄色っぽいのはとりあえずピカチュウなんだろうな、とは思うが。