本 日 の h o g e

■ [日記] あー

寝ながら Rage の Soundchaser が頭の中でぐりぐり回ってたらしい．末期だ．

■ [小ネタ] ばく

ふだん僕達が使っているものについて良いところや悪いところを振り返りながら、「どうせならこれとこれが一緒になったら便利なのに」という発想で新しいものを考え出してみよう、という主旨で作られました

ドライヤーと服，と言えば Back to the Future2 だよね．

from お空の上のブサイク人形

■ [日記] PrintStream の怪

PrintStream (System.out など) に org.w3c.dom.Node を print すると

ローカル実行

その Node を最上位ノードとして子ノードまで (属性含む) 全て XML 文書として出力

サーブレットで実行

[ノード名: ノードの値] という形で出力．子は無視

Node の toString() が変な感じにオーバーライドされちゃってるのかこれは？ つーかサーブレットってこんなとこ wrap してんの？ まじで？

XML 文書の発行がアホみたいにめんどくなっちゃうよ．いい加減にして下さい．

ダメだ

やっぱそれしか考えられん．かと言って DOM ツリーから文書を再構築する処理なんか絶対書きたくねえ．無駄すぎる．

とりあえず明日 K 玉さんあたりに訊きに行くとしよう．

いけた

transform，お前か！ お前を使うんか！ お前が必要なんか！ あ，あいウオンチューアイニーヂュー？

これで K 玉さんとこ行く必要がなくなった．……しかし TransformerException って何かいいな．

throw new TransformerException("コンボイの謎");

■ [Gentoo][Linux][日記] ふむ

デスクトップの方の X を落としたついでにカーネル入れ替え．しかし 2.6 系列は distcc 使えるからいいものの，依然として 2.4 系列は distcc 使うとコンパイルに失敗することがある (絶対ではないところがまた微妙) ので時間がかかる．

しかし最近 gentoo{-dev,}-sources のアップデートが割と激し目なのでいちいち入れ替えるのがめんどくさい．2.6 でも 2.4 でも nvidia-kernel は再 emerge だし，2.4 の方は alsa もだし．何より，ゴミの残った /boot，/lib/modules，/usr/src を掃除して SLOT のせいで clean されない古いカーネルを unmerge するのがめんどい．

どうせ使ってないんだから 2.4 は unmerge しちゃおうかなあ．

アナタの Gentoo Box も，

$ emerge -Cp your-kernel-sources

やってみるとすごいことになってるかも知れませんよ？(わら

■ あれま

しばらく見ないうちにいつの間にか Hermes 終わってた．

■ [日記] む

激しく今更だがまたふっと思い出した．

酔ってないことをアピールするためには二次方程式の解の公式を言うのが効果的らしい．

酔ってなくても自信ないぞ．

芋蔓的に

酒を飲むとダンシングフラワーになれるらしい．

■ [日記] イカン

最近なんだか些細なことでイライラする気がする．ストレス溜まってんのかな．体調よろしくないからという説も捨てがたい．

■ [Gentoo] 航海日誌にコメントスパム

わんさか来るのでまた削除．めんどくせー．何か根本的な解決策ないんかなあ．

■ [日記] 飯日記

• 13時頃：学食にて定食
• 19時頃：学食にて定食

てか一体いつまでコレ続けるんだ？

■ [日記] 飯日記

• 08時頃：サンドイッチ
• 12時頃：ラーメン
• 20時頃：冷やし中華

■ [戯言] あぁ

俺の睡眠時間が……．

■ [戯言] てか

今日は変な日だ．千客万来．

■ [戯言] あー

可搬性に優れた API のテストは簡単に書ける (とはいえパターンは多いのでとてもだるい) けれど，実際には API を作ることが目的なわけではないケースが殆どで，実際には用意した API を使って specific な要求を満たすことが最重要なわけ．

可搬性に優れた API を使っても，specific な要求を満たすために書いたコードそのものは可搬性をある程度犠牲にする．

可搬性を犠牲にしたコードというのは，往々にしてテストを書きにくい． よく「テストを書きにくいコードは設計がクソ」と言われるけれども，specific な要求を満たすためのコードとはそういうもののような気がする．

そしたら，specific な要求を満たすためのコードのテストはどう書けば良いのか？ 例えば「192.168.0.1 の負荷状況を取得」とか「http://hoge/ を表示」とか．

最初に戻ると，重要なのは specific な要求を満たすことなので，念入りにテストしておかなければならない場所というのは specific な要求を満たすためのコードということになる．

もちろん，この時点ではもう単体テストの範疇を越えている場合も多い． けど，コードを書く目的が API を作ることじゃない場合，単体テストなんてあくまで通過点でしかないはずだろ．

単体テストも結合テストも，結局のところはバグを出さないためのツール，あるいは手順でしかなくて，使い所によってはとても便利に使えるのは分かるんだけれど，これさえやっとけば安心！とか，それが全てのように語られてるのを見るとうんざりする．

■ [日記] 某所にて

大昔に遊びで作った，所属していた研究室のポスター (?) がいまだに貼られている (というか放置してるだけだろうけれど) さまを見てなごむ． まあ，作ったといっても，画像を生成してくれる Web サイトでざっくり作って微調整しただけの数分モノなんだけれど．

それにしても一体いつ作ったんだっけと思って調べてみたら，どうも 2002 年 10 月あたりくさい． そうかそういえば確かに I 研とか書いてないから再編前だよね． しかし 8 年近く貼られてることになるのか... 時の涙が見える．

ちなみにアレを作ってから 3 年後の 2005 年 7 月頃，更に不真面目の粋を極め，数枚の当たり障りないポスターと 1 枚の闇に葬られしポスターを製造してしまうわけだが，それはまた別のお話．

2002 年に作った方はマスターデータがもう手元に残っていないので，誰かがデータをバックアップしていなければ現物のみということになる． 再生成は難しくないだろうけど，もったいなかったかもなぁ． 2005 年の方は全部残してあるんだけど．

ちなみに上記を調べる過程でついでに分かったのだけれど，謎の rogue メッセージファイルは更に古く，初出は 2002 年 4 月頃らしい．

てか俺大学でホントろくでもねーことしかしてないな．