■
(以下、単に「テスト」といった場合、ユニット・テストのことを指す。そう断っておかないとNaHiさんに叱られる。)
CppUnitってありますけど
あんなもん、ほんとにみんな使ってるの？
CPPUNIT_ASSERT(condition) CPPUNIT_FAIL(message) CPPUNIT_ASSERT_EQUAL(expected, actual)
なにこれ？
こんなんでテスト中毒なんかになれるわけないでしょ？
assertメソッドっていうのはテストの主役で
一番使われるメソッドでしょ？
それなのになんでこんなクソ長ったらしい名前
タイプしなきゃいけないの？
しかも全部大文字だし。
キャプスロック使えって？ バカ？
こういうのを見ると、ほんとにXPというか
test firstは形だけしか理解されてないんだなと思う。
テストは頻繁にやるわけ。
そのためにはテストは簡単に書けないといけないわけ。
でもって、テストには邪道はないわけ。
テストに王道があるとすれば、テストを頻繁にやる
ということだけなの。
だったら、そういうふうに作らないとダメじゃん。
それがhumane interfaceと呼ばれるのか
easy-to-use APIと呼ばれるのか何なのかしらないけど。
もとからC++にリフレクションがないんだったら、
AwkでもPerlでも何でも使って楽にテストできるように
しなきゃダメじゃん。
C++で全部解決したいんなら、C++のパーザ書くとか
そういう方向に行かなきゃダメじゃん。
みんなが大好きな静的な型情報はそのためにあるんじゃないの？
なんでユーザに苦痛を与えるCPPUNIT_ASSERTなんて
安易な方向に流れるの？
自分としてはAspectC++が使えないか考えてるんですけど。
- -
まぁ、それは置いといて。
あのさ、JUnitがさ、junit.framework.Assertだけ
切り出してる理由、わかってる？
それはさ、「JUnitが状況に合わないんだったら
自分でテスティング・フレームワーク書きなさい。
でも、Assertは使えるでしょ？」ってことなわけ。
ユニット・テストだったらxUnit使うのは当たり前だけど、
それは「テストを頻繁にやる」ということの前には
必須じゃないわけ。
xUnit使うと頻繁にテストができないんだったら、
xUnitは捨てて、自分でフレームワークを
書かなきゃいけないわけ。
テストの王道は「頻繁にやる」ということにしか
ないんだから。
- -
話が飛ぶけど、テスティング・フレームワークなんて
言語ごとに違って当たり前じゃん。
何もバカみたいにJUnitのマネする必要なんてないじゃん。
っていうか、多分、それは間違ってる。
■
ちっ。ページを改めたいけどギリギリ日付が変わらねぇ。
ordinary powerの続き。
ordinary powerってそんなに難しい話とは
思ってないんですよね。
そのモデルは日本だから。
日本が米国を抜いたとはいわないけど、
米国の鼻をあかすことはできたでしょ。
それはBest and Brightestじゃなくって
ordinary powerだったんじゃないかって
思うわけですよ。
だから、agileの連中がトヨタとか騒ぐのは
ある意味、必然だと思うんですよ。
実際にトヨタで働いたことはいですけど
(日産ならあるけど)
彼らがBest and Brightestなんてことは
ないでしょう。おそらくはordinaryな
人が集まってるわけでしょう。
もちろん、自分らは、ソフトウェアという特殊な
分野にいるわけですけど、だからといって
ordinary powerがダメということはないんじゃ
ないかと思ってるんですよ。
- -
ああ、どうもデジカメは試したことがあるらしいです。
でも、定着しなかったらしいです。
そもそも、ホワイトボードというのは、出来上がった
結果には意味がないのかもしれません。
つまり、そこに描かれる過程こそが重要なのではないかと。
静的なホワイトボードに意味がないならば、
ホワイトボードは動的な存在といえます。
- -
ああ、もうJISキーボードには戻れない身体なのかも。
引用符とかは意識してるから平気なんだけど
左カッコがね。どうしても右カッコ入れちゃう。
ノンビリ入力してるんならそうでもないんだけど、
スピードが上がってくるとダメ。
でも、自前のだとIBMのヤツくらいしか余ってないんだよな。
あの人を撲殺できるといわれてるヤツ。
- -
ああ、何もovercommitしろっていってるんじゃ
ないですよ。
自分の能力や責任を超えてまで約束するんじゃ
なくって。
overcommitするというのと、
勇気を持つというのとは
紙一重のところがあるかもしれませんけど。
でも、失敗したっていいんだし (Failure)
仲間だっているし (Whole Team)
だったら、もっと勇気を持てるんじゃないの？
- -
artonさんとこからたどった：
http://perlcabal.org/~autrijus/tokyo/vb.xul
なんですけど、XULってのはすごいですね。
マウスをタブの近くにもってくと、ツールバー
みたいなのが出てくる。そこにスライダーが
あって、ページを行き来できる。
XULだから、もちろんMozilla系じゃないと
見れないんでしょうけど。
- -
よく考えてみたら、おかしい。
会議のとき、ホワイトボード使うじゃん？
でさ、書いたのをコピーできたりするのもあるじゃん？
バーがガーっと左右に動くヤツとか、
書くところがクルクル回ったりするヤツとか。
なんでデジカメで撮らないの？ うまく撮れないのかな。
ガッコじゃないんだから、別にフラッシュ炊いても
いいだろうし。
- -
でさ、うまく撮れたとして、その場でコメント
入れたいじゃん？ せめてファイル名くらいは
ヒントになるようにしたいじゃん？
まぁ、これくらいはノートPCでなくっても最近の
PDAだったらできるかもしんないけど。
だったら、画像をWikiに上げるのは？
だからさ、結局ブーストなわけ。私物PCはダメだとか
そんなこといってる場合じゃないでしょ？
■
はてなアンテナ、新規ページを追加できなくなってる。
- -
- -
季節ということもあって、新人に読んでほしい
ページをポツポツ書いていきます。
http://www.radiumsoftware.com/
自分の巡回先の中でも質はピカイチ。これから
読みはじめるといいと思う。いわゆるモデル。
http://japanese.joelonsoftware.com/
いきなりXPとかagileとか持ち出すと拒否反応を
起こすかもしれない。だから、Joelのほうが
勧めやすい。
ちょっとどう紹介したらいいか難しいのが：
どう読めばいいかが難しい。英語だしね。
自分はRecentChangesをチェックして、気になる
ページを見てるんだけど。
だったら、Fowler氏のほうから読んでみるのもいい：
http://capsctrl.que.jp/kdmsnr/wiki/bliki/
あとは仕事の内容に左右されるんだけど、
たとえば：
http://www-06.ibm.com/jp/developerworks/
は、扱う話題も幅広い。
オープンソースでWeb系なら：
とか
とか。
Javaだったら：
http://www.artima.com/index.jsp
とか
http://www.theserverside.com/tss
とか。
Windows系のページは知らない。っていうか
教えてほしい。
あ、忘れてた。
/.J読むくらいなら、yendotのほうがいい。
/.Jも最近ほんのちょっと質が上がったような
気がしないでもないけど、基本的にはスルーで
大丈夫。
大事なものを忘れてた：
http://practical-scheme.net/index-j.html
ここから読めるP.Graham氏の文章群。
「技術に人生を賭ける」という
意気込みみたいなものを自分は学んだ。
Joel on Software同様、こっちも書籍化されてるんで
それを読んでもいいけどね。
- -
Whole Teamには２つ意味がある。
１つは「ほしいものがすべてあるチーム」ということ：
Include on the team people with all the skills and perspectives necessary
for the project to succeed.
もう１つは「チームの一体感が大切だ」ということ：
People need a sense of "team":
* We belong.
* We are in this together.
* We support each others: work, growth, and learning.
- -
自分は、オシム流にいえば、価値観を共有したいわけです。
その価値観の多くはXPに根付くものです。
でも、それ以外にも、オープン・ソースや、
Webや、バカといったものも含まれています。
そういったものすべてをひっくるめて自分の価値観なわけで。
それをみんなと共有したいと。
もちろん、みんなの価値観から影響を受けることもあるでしょうしね。
■
自分が「Googleの鼻をあかしたい」って
いってるのは本気ですよ。
だって、あいつらの"Best and Brightest"って
いうのはeXtremeじゃないですから。
XPっていうのはordinary powerなわけですよ。
プロセスっていうのはみんなそういうもんですけど、
いかにordinaryな人たちで成果を上げるかって
いう話でしょ。
XPでいえば、価値、原則、実践の3つで、
ordinary powerを集めて
excellentなチームになるってことです。
- -
結局、メンバ一人一人の向上がないと
チーム全体の向上も望めないんですよね。
仕事の中でもその一人が向上できることは
できるんですけど、もっと劇的に
向上できるんじゃないかと思うんですよ。
その鍵がインターネットだと思ってるわけで。
これも高速道路理論のひとつですけど。
だからね、向上、向上ってシャカリキに
なるんじゃなくってね。
たとえば、ブログ読むとか、2ch読むとか、
そういうことが向上につながるんだと。
もちろん、ブログとかはきっかけに過ぎない
かもしれませんけど。誰かのブログで見かけた
本を買ってきて読むとかね。まだまだネットに
乗ってる情報は限られてますから。
だからね、「私的インターネットの利用を
禁止する」とかね。バカ？っていうか、
ほんっとにお前ら頭悪いだろと。
■
なんかちょっと引っかかってはいたんですけど。
あれ、やっぱおかしいですよ。
初期見積もり (early estimation) って
外れていいわけでしょ？
だったらもっと攻撃的にならないと
いけないんじゃないですか？
Play to winってそういうことでしょ？
チャレンジでしょ？
まぁ、先が見えてないからビビるのは
わからないでもないですけど、そこは
開き直るっつーか。
そこにcourageがあるわけでしょ。
Fuck Fear!ってストンコならいうと思いますよ。
だから、そこにXPの精神がなければ、
The Planning Gameっていったって、
旧来の見積もりと変わらないでしょ？
バッファ取ってなんてやってるんじゃ。
いや、バッファが悪いとかはいいませんけど、
それが本当にバッファなのか、
それとも単なる逃げなのかじゃ、
雲泥の差じゃないですか。
- -
それはそれで正しい意見だとは思うんですけど、
抽象度が上がりすぎると、Joel氏自身のいう
アストロノーツ症候群に陥ってしまうんじゃ
ないでしょうか。
つまり、顧客との距離が離れてしまう。
ソフトウェア開発のマネジメントというのは、
顧客と開発者の距離を縮めるのもひとつの
仕事なんじゃないかと思うわけです。
もちろん、この距離には「適正な距離」という
ものがあるんでしょうけど、それはみんなが
思ってるよりグッと近いんじゃないでしょうか。
逆にいえば、我々プログラマはもっと顧客に
近づかないといけないんじゃないでしょうか。
これはXPのon-site cutomerのことばかりを
いってるんじゃなくって、もっと漠然とした、
あるいは広範な、「態度」といったものです。
顧客に近づくということを別の角度から
見れば、「どうすれば売れるか？」を考えると
いうことです。
機能ひとつひとつについて、それが顧客が
望むものなのか、それが売れるものなのか、
そういったことを本気で考えないとダメ
なんじゃないでしょうか。
そういうことの例で、Joel氏は後方互換性を
あげていますよね。後方互換性は開発者に
とっては煩わしいものなんですけど、それを
顧客が望み、それが売れるキーならば、
他に選択の余地はありません。
- -
もうちょっとはてなにお世話になるかも。
向こうにもアップロードできるんだけど、
いろいろと不便なのだ。
- -
Meadow3が新しいEmacsをベースにしているからか
VCの操作が変わったみたい。
前はC-x C-qでチェックイン／チェックアウトしてたんだけど、
Meadow3のVCだと、C-x v vでチェックイン／チェックアウト
するらしい。
- -
結局、.emacsに：
(add-hook 'shell-mode-hook '(lambda() (set-default-font "MS Gothic 12")))
と書くことにしました。M-x shellでフォントが変わります。
苦肉の策すぎ。
(ms-font-jaパッケージを入れた上での話ね)
