角谷HTML化計画(07-31[長年日記])

2001-07-31(Tue) [Edit]

■1 『千里眼の瞳』(松岡圭祐)

2001/09/28刊行予定とのこと。いつまで続くのか、千里眼シリーズ。「著者独特のリーダビリティ」というよりは賞味期限を刊行後半年ぐらいに設定、読み棄てられるのを承知で書き飛ばしているような気がしてならないのだが、結局買って読んでしまうのだろう、今回も。

Tags: 書籍 |

| Permalink

[ツッコミを入れる]

2003-07-31(Thu) [Edit]

■1 大量破壊兵器は見つかりません

PragDave経由。

Googleに行く
"weapons of mass destruction"を検索語に入れる
"I’m feeling lucky"を押す

google.co.jpだと「Web全体から検索」しないと一発では出ないみたい。

Tags: 時事 |

| Permalink

■2 アジャイルとフリーソフトウェアは手をつないで行く

セロニアス・モンクの向こうを張って。Agile and Freesoft go hand in hand.

社内のMLにメール出した後に思い至る。『ASD』も残すはあと第12章と参考文献のみ。盛りだくさんすぎて消化不良気味。

追記: 「Lightweight」は正しいのだが、そこには思想が足りない」

なのでAgileと呼ぶことにした。……ってのはアジャイルプロセス協議会設立記念セミナーで誰が言ってたんだっけ。そういう意味ではLightweight Language Saturdayも、Agile Language Saturday でどうか。Perl,PHP,Python,Ruby。こっちのほうがしっくりくるような。あくまで個人的な印象だけど。

Tags: 業界 |

| Permalink

■3 オブジェクト指向

まつもとさんの「オブジェクト指向は難しい」、その2の波紋で色んなところで色んな方が色んなことを言っている。やはり皆さん一家言あるのだなあ、ということを再認識。調子に乗って私もなんか書いてみよう:

オブジェクト指向とは世界観である。
オブジェクト指向とは截拳道である。
オブジェクト指向では名前が大事なのに、自身を示す「オブジェクト指向」という名前が良くない。
オブジェクト指向はなぜ難しいのか。それは難しく考えてしまうからだ。

Tags: OO |

| Permalink

本日のツッコミ(全1件) [ツッコミを入れる]

○ kdmsnr [考えずに感じればよいわけですな。]

2004-07-31(Sat) [Edit]

■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でもいいけど)からのバッチ実行＆レポート生成ができないと、代替品としての捺印ナビリティはお話にならない。今後に期待しつつ、生温かく見守りたい。

| Permalink

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

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

| Permalink

■3 隅田川花火大会

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

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

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

| Permalink

本日のツッコミ(全2件) [ツッコミを入れる]

○ kakeda [xSpecは私の考えで、フライパン氏に聞いたのはjBehaveのほうでした。なのでADC2004をいくら探してもxS..]

○ かくたに [いっぱい食わされたー。でも、Mockのペーパー見つけられたからいいです(w]

2005-07-31(Sun) [Edit]

■1 PofEAA読書会:第5回

「トラックバックするまでが読書会」……やっと私のPofEAA読書会:第5回が終わるよ。今日何曜日だっけ*1。

Java/PHP/Ruby/.NETな感じの人びとが目立つ感じで集まって「エンタープライズ」なアプリケーションのアーキテクチャについて云々する会合の第5回。今回は30名近い参加者。もはや私が音頭を取るのは限界な気も。今回も私は準備不足だった。

ポジションペーパー発表

毎回混乱する時間。その混乱が簡単なアイスブレイクにもなってると思うので、個人的には楽しい。とはいえ、発表者のペーパーの検索に時間がかかるのはもったいない。書式を指定してはどうか、という意見が「ふりかえり」で出ていた。ふりかえりでは他にも「名札が欲しい」という意見も出ていた。確かに必要かも。

ポジションペーパー発表は、本来の意図からちょっと外れた自己紹介タイムとなっているのだが、これもまたよし。

今日の失敗は、ポジションペーパー発表のタイムキープ用のキッチンタイマーを紛失(!!)したことに当日気づいたこと。あわてて山手線でカウントダウン用Rubyスクリプトを書いた。

Chapter6. 「Session State」

ステートは遍在する。マトリックスのように……。

Session Stateはレコードデータじゃないよ。キャッシュでもないよ。Business Transactionに結びつくよ
AJAX/リッチクライアントの波が来るとステートの持ち方も揺り戻しが来る
Session Migrationするか、Afinity(Sticky)にするかもコンテキストに依るんだなあ
LL界ではとりあえずMySQL。Session StateもMySQLに。MySQL Session State。

Chapter7. 「分散ストラテジー」

あなたはすぐに分散をさせたがる
あたしは何時も其れを厭がるの
だってリモートになっちゃえば　呼び出しが遅くなるじゃない

あなたはすぐに透過性などと云う
あたしは何時も其れを厭がるの
だって開発者が意識してしまっちゃえば　其れすら嘘になるじゃない

ｄｏｎ’　Ｕ　θｉｎｋ？　ｉ　罠　Ｂ　ｗｉθ　Ｕ

此処に居て
ずっと
明日のことは判らない
だから同一プロセスにしていてね　ダーリン

あなたはすぐにブロックを渡して見せたがる
あたしは何時も其れを喜ぶの
だってファウラーみたいだから　あたしがシンディじゃない
...