日々の破片

_ ２人の女をもつ者は魂を失い、２つの家をもつ者は理性を失う

という諺がおフランスにはあるらしい。ってのは、ロメールの満月の夜の諺がそれだからだが。

リベットの北の橋では幻想のドラゴンに挑む空手使いだったパスカルオジェが、ここではデザイナーかな（忘れちゃった）、何かおしゃれな職業婦人（っていつの言葉だ）の役をやっている。で、郊外に家を持つのだが、夫はそれで満足らしいがパスカルは満足できない。ナイトクラビング（これも死語かな）が好きだからだ。というわけで、パリにもアパルトメント（アパートじゃないな）を借りることになる。かくして、2つの家の喜劇が生まれるんだけど、本当に喜劇なんだろうか。

この映画でびっくりしたのは、それまで映像と無関係な音を使っているのを見たことがなかったロメールの映画で（バルトークを弾けばバルトークが鳴るわけだが、北京のバイオリンみたいに幻想の交響曲が鳴るわけではなく、話せば話した声、車が通れば車の音、音に関してはストイックというかリアリストというか、なのだ）、（僕が見た中では）はじめて音楽が鳴ったことだ。だからそのシーンは非常に鮮明に覚えている。ロジェバデムの息子になんぱされて、タンデムでパリを走るシーンだ。レナートベルタの青い青い映像（ロビンミューラーも青い青いが）がとってもきれいなのだ。しかし、満月の夜に眠れない人々には平和な夜明けはやっては来ない。結局彼女はもうひとつの家を失うことになる。結構意地が悪い映画なのだが、それも含めてロメールの映画というのはそんなものだ。比較的現代的な風俗描写が多いことと色の青さから、まるでナイルの娘みたいな異色作かもな、とか思ったりもしたけど。突然、「市長さんお話があるの」、というニャンクン（家庭内方言で小生意気な小僧――タイニーチューンに出てくるめがねをかけたトゥイーティーみたいな小鳥をなぜかそう呼ぶが、ここでは単に生意気な口をきくかわいい女の子の意味）の台詞を脈絡なしに思い出したが、それは別の物語だな。

困ったことに、僕にも2つの家があることに最近気づいた。というか、わかっていたのだが、それをうまく両立させることがいかに困難化ということにやっと気づいたというべきか。

1つは普段使っているWindows2000のマイドキュメントで、もう1つはPowerBookの/Users/の下のやつだ。っていうか、/homeの下じゃないから家とは言えないかも。

ちょっと前にはそれでもうまく両立していたのは、どこに行くにもPowerBookを持ち歩いていたからだが、ここ1ヶ月で本来の状態に戻ったため、PowerBookを開く頻度が確実に減ってしまった。で、何がまずいかというと、PowerBook用のメールアカウントと、Windows2000用のメールアカウントを分けていたことだ。そのため、PowerBook用に設定したメールに全然目を通していなかったり。

どうしようかな。（というか結論は決まりきっているのだが）

_ キャレット

Windows3.0a（とか昔のことを言い出したり）には、カーソルが2つあった。っていうか、今もあるけど。というわけで、単にカーソルというとわけがわからないよなぁ、と思っていたら、WindowsAPIを見ると、どうも今までカーソルと呼んでいたコンソール上で点滅している四角いやつ（Windowsのデフォルトだと縦棒だけど）のことをキャレットと呼ぶようになっていて、おなじみの言葉のカーソルはマウス用になっていて、かつそれは混乱の元だからと、マウスカーソルと接頭詞を付けた呼び方も書いてあったり。CreateCaretとかHideCaretとかが、そのAPIだ。

で、なるほど、よくわからんが今までカーソルと呼んでいたものは、これからはキャレットと呼ぶのですな、と素直に育ってここまできたが、今日、はじめてキャレットの意味がわかったぜ。

極東ブログに、すごくわかりやすい図付きで書いてあった。校正で使うあれのことなのか。……なんか違和感があるんだが。でも、挿入点を示すという意味では正当なんだろうな。では、カーソルとはなんだろう？ （と疑問に思ってもそのまんまなわけだが）

_ 実行モード

今のモードはあまり外部へのアウトプットが無いモードのようだ。

それはそれとして、Wiki＋陣取り合戦（しろとりという遊びがあったな、そういえば）＋4色問題みたいなのってできないかな。

_ 3月3日はひなまつり

桃の節句か。このへんじゃ梅や桜にくらべて桃ってのはあまり(というか全く)見ないな。

で、今日はいまいち調子が悪いが立ち仕事なんだが。

_ Commons Chain

ひがさんのコメント

DIContainerを使えば、POJOで組めるので、いまさらCommons Chainは必要ないと思いますが、世の中の流れとして、ロジックをアトミックになるまでばらして、それを後から柔軟に繋いでいくという方向に向かっているのかもしれません。

頭がくらくらしているので、深く考えずにいい加減なことを書いてみる。

発散と収縮は交互に起きるものだと前提する。

構造化プログラミングというのは収縮、オブジェクト指向プログラミングというのは発散（拡散かな？）。これはロジックの位置の問題だ。

今、ある分野(ようはビジネスアプリケーションの世界だ)においては、オブジェクト指向プログラミングのままでロジックの収縮に向かっているのかも。それは業務ロジックが分散しているととってもメンテナス性が低くなることに起因している。だから、ロジックをアトミックになるまでばらすという、それは構造化ですね、という方向が見えているのだ(追記：っていうか、僕にはユースケースがオブジェクトに見えるんですが)。というか、ビジネスアプリケーションというジャンルが、あまりにもそこらに転がっているうえに、一見して面白くもなんともない分野のせいで、まっとうな研究対象とならなかったから一種のブラックホールになっていたからかも知れない。そのため、その分野に特化したうまい方法論というものがきちんと出て来ず、そのため個々の開発者(研究者ではなく。実務者と呼んでも良い)のビジョンが先導するかたちで模索されているからだ。従来であれば、それは企業の枠内でおさえられていたわけだが、そこに一家言ある人たちのオープンな取り組み（ファウラーとかロッドとかを想像すればよろしい。もちろんコンサルとしての宣伝効果とかが裏にはあるわけだろうが、そういった個々の事情とは無関係に、とてもありがたいことである）が姿を現し、それに触発されてより特化した方向での別の取り組みが生まれたり（ひがさんたちのSeasarとか）、そんな状況である。というわけで、考え方としては収縮フェーズに入っているのだが、実装としては拡散フェーズということだ。

そのために、いろんな方法で、それをどううまく片付けるかが現時点でのホットスポットとなっている。AOPをどう適用するかなんていうのがまさにそうだし、DIだってそうだ。コンポーネントの粒度とか、コンポーネントの組み立て（というのはコンテナだ）、全体の枠組みをどう構成するか、配備技術、いろいろだ。したがって、今の時点でたとえばSpringで決まりとか、決めてはいけないわけで、いろいろある考え方のあくまでも現時点での1つの実装例として捉えて、それをどう現実のアプリケーションに適用するかを考えるための手段として見ておいたほうが良いだろう。実装はうつろいやすく、考え方はあまりうつろわない。くだらない個人的経験で言えば、もうCOMを使ってどうこうということはしそうもないが（実装はうつろったわけだ）、そこで得た数々の知見は未だに役に立っている（考え方はなかなかうつろわない）。

どっかで誰かが、リフレクションというのは難しかったらしくてAOPと呼び直したら流行の兆しあり、みたいなことを書いていた。その意味では、オブジェクト指向プログラミングでは、クラスとインスタンスを別物と考える方法より、クラスもオブジェクトな世界のほうが良さそうでもある。というか、メタデータの重要性が確立したということだろう。（この段落はまた全然別のことだな）

_ ふむふむ

としか、今は場所が悪いので書けない。特に反論すべきことはないが、誤読されたままだとおもしろくないので、後でここを埋める予定。

_ 中断

と書いたもののあらためて、では構造とは何かを調べなおしているうちに別の方向によれてしまったので発酵させてからにします。最初に書かれているようにどうも言葉の解釈が違うのかも知れないし。

#この（構造の）話とは別に（いろいろ考えているうちにふと気付いたので）、層間の通信をどう考えているのかにちょっと興味を覚えた。間にリモート呼び出しが入らない限りは、論理的には層があっても物理的には所詮メソッド呼び出しなので、フラットという考えなのかなぁ。（と書いてから誤解を招きそうなので僕のスタンスを明らかにしておくと、リモート呼び出しはいかに巧妙にシームレスに見えても、危険極まりないから防御をいっぱい張っておくべき＝どう見えようと別扱い、だから「間に……限りは」という前提を置いています。ここは別の考え方もありうるので無視してください）

_ YARV 0.2.0

引き続き、PowerPC（入れ物はPowerBook）でやるつもりだけど、今、すごーく時間がかかる変換作業中なので、終わり次第。っていうか、すごーく時間がかかるので結構、後悔していたり（iTunesの音量調整）。ちなみに時間がかかるのは、ライブラリのサイズが大きいからだけど。

_ 嵐のように

どんくさい親父だと思うし、本来全く性に合わないはずの泥臭いアメリカのロックなんだが、それでもいいものはいいんだ。

と、ライクアハリケーンがiPodから流れてきたので思わず聴き入り、思わず心が動かされ、とりあえず貼ってみたり。こんなすごい音楽を聴かないで生きているのはつまらんぞ。

しかしとても不思議なのは、こういう魂を揺すぶられるという決り文句がぴったり来る音楽ってのはなんなんだろうか？ 声なんだろうか、その人にまつわるエピソードから想起されるさまざまな想念（それは自省だったり希望だったり共感だったり同情だったり絶望だったりいろいろだ）なんだろうか、それとも音響そのものが鼓膜を揺らしそれが神経を伝っていき脳の中で何かの分泌物を通常と異なる方法で回したりするんだろうか？ いったいどうして音楽を聴いて心が震えるんだろう。まったく理解できないのだが。

ひとつわかることは、僕にとってこのライブのライクアハリケーンはすばらしく響くということだ。

_ シャッフル

偶然にしろ、iPod Shuffleの今回の選曲はすさまじく良いなぁ。

このあと、ストラングラーズのダッチェスが来て、電気グルーブのシャングリラで、今はキュアの（う、名前がわからない）。でも、どれもニールヤングには敵わないな。

_ 突如マーラー大人買い+1

いろいろ見て回ってるうちに、バーンスタインがベルリンを振ったマーラーの9番にぶち当たって、そのままずるずるとはまりこんでしまった。

この人は、イスラエルでの大地の歌とか、ウィーンでの大地の歌とか、ニューヨークフィルだけではあきたらず、いろいろそこらで名演を残すが、ベルリンにも行っていたのか（ちょうど僕がクラシックというか後期ロマン派だけどを聴かなかったころなのか）。ベルリンフィル、マーラー、第9番と言えば、何よりもバルビローリなのだが、それにしてもAmazonでの評価は低いな。録音ってそんなに重要か? 針音がするマジーテイトとか戦前のヴァルターとかのエンジェルのGR（だっけかな？）とかでも全然問題ないんだが。どっちにしたって演奏会には勝てない（たとえば咳の音とか入って無いじゃん）のだが。でも、まあそれはそれとして、これは買うだろうな、今となっては。

と見ていくと、うあー、いっぱいあるな。一番マーラーを聴いてたころは、クーベリックとバーンスタインのほかは、クレンペラーとバルビローリとヴァルターがそれぞれちょっと(とは言え、それぞれ圧倒的な存在でもあるわけだが)、あとはオーマンディの復活ってくらいだったのに。

というわけで当然のようにアバードだ。この人には本当に驚かされた。えらーくゆったりとして硬質（だってことはその後に良くわかった）なクレンペラーでしか聴いたことがなくて（ただしソプラノがシュヴァルツコップだから傑作ではある）、その結果、当然のようにつまらないとるに足らない曲の代表として記憶された4番だ。NHKのFM聴いてたら、アバードが（たしかウィーンだ。カセットはどっかにあるだろうけど聴くためのハードは無いし、大体覚えているからいまさら聴く必要もないから確認はしないけど）なんかの音楽祭(っていうか、音楽祭の名前を全然覚えてないな。バイロイトじゃないし、ダルムシュタットじゃないし、なんだろう？ さっきからウッドストックというカタカナが出てきてるんだがもちろん全然違うし――ヨーロッパと音楽祭で検索したら思い出した。ザルツブルグだな )で振った4番が流れてきて（幸い、エアチェック――きっと死語だろうな――してたのでそのあとうんざりするまで聴き返せたのだが）、これは驚いた。歌ってのはこういうことか。なんというかとにかく馬鹿でかい樹木が生えていて緑が青々しているのだが、その個々の葉っぱのかげにいろんな色の花は咲いているわ、虫はいるは、木漏れ日が風にそよぐは、ちょうどそんな感じだ。つまり、すごく鮮明なのだ。ビジュアルという言葉を今なら使うだろうけど、当時はそんなカタカナを知らなかったから、とにかく歌だ、歌だ、これは歌だ、そうか、だから交響曲4番は大いなる喜びの賛歌なのか、と思い知った。でも、それがアバードの才能で、4番っていう曲の魅力じゃないってことは、クレンペラーを聴き返すとくっきりはっきりわかるわけで、結局、クレンペラーは売り飛ばし、マーラーは9番以外は聴く事がほとんどなくなってしまった。で、アバードの9番がどんなものかそれは知りたいものではないか。っていうか、これもベルリンか。ウィーンが良いのだけど（追記：おれはCDを買いすぎてる上にちゃんと管理できてない。アバードのウィーンの第9番と第10番のCDを持っていた。これについて言えばあまり好きではない。で、さらに思い出したがオーマンディと言えば10番(も出てたというか唯一のLPだった)が素晴らしかったな）。

で、さらに、Amazonで見ていると妙にブーレーズの評価が高い。嘘だろ？

プリスロンプリのライナーノートに柴田南雄が「あのくだらないグルッペンで、聴衆がブレーズの番だけを楽しみにしてた、と聞いたが、シュトックハウゼンはともかくプロのロスバウトより上ってことは無いだろうと思ったが、いや、これはしたり、ブーレーズは指揮者としてのほうがすごい」（そうとういい加減な記憶で書いているし、柴田南雄はこういうニュアンスでは書くはずはないな）というようなことを書いていたくらいだから、指揮者としての腕は確かだろうし（でも、僕は春の祭典ならアバードやマゼルのほうが好きだし）、でもなんか妙に評価が高いな。そうか、録音が良いのか、ということもありそうだな、とか考え合わせるとさすがに、ブーレーズでまで第９番を買うのはまずかろうと自省したが自制がきかず、ついついこっちをクリック。

マーラー:交響曲「大地の歌」(ブーレーズ(ピエール))

大地の唄は、ヴィーンを振ったバーンスタインと、ウィーンを振ったヴァルターの戦前のと戦後の2枚、ウィーンで3種類を死ぬほど聴いた。一番好きなのはヴァルターの戦後版だが、一番良く聴いたのはヴァルターの戦前版だ。音はひどく悪いがテノールがすごく陰惨で好きだったんだな。で、これもウィーンだ。歌手がまったくわからんがまあ、いいか。

それにしても、いつでも買うのは第9はベルリンで、大地の唄はウィーンか。妙な符牒だなぁ。

で、おまけにバルトーク。もちろん、僕の一番好きな作曲家だし。ブーレーズでピアノ協奏曲はずっと聴きたかったんで、ついでに買っちまえ。

ピアノ協奏曲は、1と2はアバードとポリーニのやつを死ぬほど聴いた。何しろカーステレオのCDチェンジャーの2番目の定位置だ。しかし、車の中では夜の音楽がまったく聴こえないのが問題だ。でも、パーパパパパパーとかは車の中でも良く響く。あれいいな。2番の出だしも好きだ。パカパカパンパ、パッパパパパパーはどうでもいいんだけど、次のパララッパーパラパラヒャララとピアノが駆け下りてくるところがすごく好き。それに比べると3番は有名過ぎて敬遠するといういかにも中学生の頃の聴き方のせいであまり印象に残っていないが、なんか結構良い演奏のLPを持っていたな。オケがリスボンだからポルトガルの録音だが、指揮がミトロープスかあのあたりで、ピアノもブレーズのソナタとか弾いていた人だと思ったが悪くない演奏だった。でも、何しろ有名な曲だからあまり聴かなかったのでほとんど記憶にないのだな。っていうか、晩年の悲しい曲だし。

で、3つ全部入っているってのは良いことだ。しかしピアノは全然知らない……と思うけど1番だけは知ってそうなんだが妙だな。どう見てもジンメルマンなんだがまるで自殺した作曲家みたいな表記になってる。亡命でもしたのかなぁ。この人、ショパンコンクールで優勝したはずだけど、個性（良く言えば。悪く言えばクセ）が感じられないかわりにすごく透明で明確な演奏で、良い曲を良い指揮者と一緒に演奏したらそれは良いだろうな、と思っていたから良い選択だな。もう全然若くはないけど。

_ Commons-Chains by Ruby

Rubyで実装したONJava.comの解説記事の焼き直し。

ああ、るびまに送れば良かったかも。ま、いいか。っていうか、ONJava.comから文句が来るかも。っていうか、再実装は……

しかし、こういうのって、Javaな人にもRubyな人にも役に立たないような気がするな。っていうか、Rubyは楽だな。

_ unless

慣れの問題かも知れないが、素直だと思う書き方の

unless foo.nil?
  bar
end

よりも

if !foo.nil?
  bar
end

のほうが書きやすい。というか、習慣で最初にifと書いてしまうから、foo.nil?の否定で!foo.nil?と書くことになるからだな。

で、unlessで書き直すと、どうもしっくり来ない(と感じるのは慣れなんだろうけど)から結局また!foo.nil?で書き直す羽目になるようだ。

慣れだとわかっていれば四の五を四の五の言わずに使って慣れればいいような気がする反面、C#でもJavaでもC++でもサポートしていないから積極的に慣れようとも思えないわけだし。

変換されないのでふと気になってGoogleにかけたら、「しのごを言わず」が5件、「四の五を言わず」が192件。死んだ日本語だな。死んだのはおれだ。

_ yarv-0.2.0

pbk-15:~/devl/yarv-0.2.0 $ ruby -v
ruby 1.9.0 (2005-01-12) [powerpc-darwin7.7.0]
pbk-15:~/devl/yarv-0.2.0 $ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)
pbk-15:~/devl/yarv-0.2.0 $ grep CFLAGS Makefile
CFLAGS   =  -fno-common -g -O2 -pipe -fno-common 

_ 熊はすごいな

狼は絶滅したのに、たとえば日本、ドイツやフランスあたりだとどうなんだろう、でも熊は生き延びている。たとえばイギリスでは熊いじめなんてひどい扱いを受けたりしてたのに。

と、絶滅した動物の本を読みながら思った。

しかし、熊いじめについて『こうした清教徒の娯楽観を、一種の偏見や倒錯だと皮肉ったT.B.マコーレー（19世紀イギリスの評論家）の指摘は，次の通りである。すなわち，清教徒が熊いじめなどの娯楽を禁止したのは，それが動物に与える苦痛のためでなく，見る者に楽しみを与えるからである。』なんて書いてあるのを読むと、暗澹たる気持ちになるな。黒くて2本足で立つし毛むくじゃらだから悪魔の一種として扱ってたんだろうか？

_ WinFS

よみがえるとか。

なんか、どんどん焦点がぼやけているように見えるな。

もっとちょろくてもおもしろそうなものをしこたま作れるはずなんだから、そういうのをじゃかすか出してくればいいのに。ちょうどGoogleがやってるようなことのデスクトップからの逆襲って感じで。でも、後先考えずにじゃかすか出すと、セキュリティが危ないってこともあるわけだし。で、逆に萎縮してしまったのかなとか。

_ よく寝た

先に寝たやつ相手を起こすの原理により、わりと早く起きしてしまった。

_ ローレライ

お、ひさびさに『ただ、風のために』が更新だと思ったら切実さが昇華されていた。

_ 失踪日記を買っちゃった

ふたりと5人とか（あんまり面白いと思ってたわけじゃないけど、っていうかエイトビートってあったなぁと読んだ記憶は思い出したが中身はさっぱり思い出せない）リアルタイムに読んでたわけだし、それ以上に、劇画アリス（思い起こせば自分の小遣いで定期的に買った最初の雑誌のような。なんだかなぁ）の連載はおもしろかったわけだし、まるこっいマンガで書かれた極北なわけだし、まあ、なんていうかやっぱり買って読まなきゃならんだろうということで。それにつけてもアマゾンのランキングがすさまじい(isbn取りに見に行ったら19位だった：追記：僕はうかつというか鈍いところがあるのでここでisbnを拾いに行ったおかげで思わぬプレゼントも得られたのだった。って気付くのが普通なのかなぁと疑問に思わないでもないけど)が、アマゾン利用者って絶対に偏ってるな。

でそれはそれとして別の本も買ってそれも読んでるけど、そっちはそのうち。

#おおおおおおお思い出したぞ。ガンダムの首がごろんごろんと転がってくる画を。あれは、諸星大二郎ネタだけど、ガンダム＋諸星大二郎っていうのを劇画アリスでやるってのが、なんていうかただものじゃないですね。

#さらに、まっかなトマトになっちゃいな(トマトジュースのCMを大友克洋が利用したのをさらに利用)、もあったような気がするけど、これは記憶違いかなぁ。

(衝撃の真っ赤なトマトになっちゃいな）

#あそこそこのアージャノンもリアルタイムになぜか読んでるんだよな。全然思い出せないけど。

#（追記：6回で打ち切られたっていうネコ娘のマンガが、どうもおもしろかったような記憶の方向で引っ掛かってるんだが、どんなんだっけな）

_ 家のテレビ事情

僕個人はまったくテレビを見ないので（ここ1年で言えば、白熊ピース君を録画した最初の10分くらいを見たのと、ふたつのスピカの最初の回を録画したのを見たのくらいか。後、冬休み特番のフェニックスのやつを子供と見たか）、ビデオレコーダが壊れてから10年以上たつけど、まったく買う気はなかったのだが。

それにしても、ATI All-In-Wonder 128Proはいい加減にうんざりするくらい失敗したり（XPが悪いのかも知れないけど、それにしたってボードがいささか古過ぎるしな）するのと、妻がPC部屋以外の場所での録画と再生可能なものを欲しがっているってのもあって、買うことにする。

とは言え、今更テープメディアってこたないな、と、いろいろ見たけど、5万円以上は出したくは無いな、とか、やっぱHDDのテンポラリ性って重要だよね、とかから結局パイオニアのDVD&HDDのやつを選択。どうせVHFしか今のところ用は無いし（多分）。アマゾンの評を見るとゴーストが……とか書いてあるけど、まあ、それほど気にしない（というか、もともと良く幽霊が出る心霊スポットだし）。

で、注文して気付いたけど、これまで蓄積してきたテープはどうなるよ？ とか。まあ、10年見なかったんだから今後も見ないだろうけど、でも、学生の頃録りだめして見まくった(昼間の80分枠でばかばか流れていたのだ)大映や日活の映画群（田宮二郎の犬シリーズとか、二谷英明の流れ星シリーズとか）わけで、結構、無駄な知識の元ネタになっていたりするから、折角再生可能にできるかも知れないチャンス（ってのはテープメディアを購入するって選択肢があったわけで――と思ったらアマゾンにはそんなカテゴリーがそもそも存在しないんだな）なんてハナから無かったのか。

FDとかLPとかVHSとかLDとかどうにもならないメディアが蓄積されていくってのは寂しいことだな。たとえば、1900年なんてテープとLDで持ってるわけだがどっちもレガシー（というかLDプレイヤーは年末に買ったから当分は平気だろうけど）、でも映画そのものも人類の文化遺産。今だってDVDだCDだとか買ってるけど、20年後、さて余生は映画でも見まくって送りましょうかと思った時には、すでにレガシー化して見られなくなってんだろうな。

ちなみに、本来の映画の時間をまったく無視してばさばさ切ってCM入れるためにズタズタにして、しかもトリムしまくるってどうよ、と思ったものだが（上で書いた12チャンネルの昼間の邦画の時間帯では120分の大作だろうが100分だろうが90分だろうがとにかくCM込みで80分という時間枠で放映するわけだ。トリムってのは、シネスコをスタンダードにするために脇をちょん切ることで、最悪の例は『悪名』に見られる。ふすまが映ったシーンで、勝新太郎と田宮二郎がなんかおもしろそうな会話をしているんだが（ここに中村玉緒がからんだり）、なんだかさっぱりわからない――でも、池袋の日勝かどっか地下のオールナイトの5本立てでホンモノを見たらびっくり、シネスコの両端に陣取って差しで呑んでるシーンだったんだとか）、考えてみれば今見られるオーソンウェルズだってフォードだって、ザナックとかがズタズタにちょん切って適当に編集しているわけで、残った映画がやっぱり映画だからそれで良いのだと納得していたり。

_ 上

もう届いたが、以前はプレイヤー（蓋が貝みたいに開くレコードプレイヤーは別格として）の上にテレビとか別の機器とか割と置けるようになってたのに、今はだめなのか。そういや、コンピュータも以前はモニターをそのまま置くのが普通だったのに、最近は置くなとか書いてあるし。しかし、重たいCRTは消えつつあるし。

そういや、以前、名前は忘れたけどどっかのエッセイスト（多分、同世代人）が、僕らの子供のころはモノが増える＝豊かになることを実感した世代であると書いてた、というとこまで書いて泉麻人だと思い出した、が、確かに、テレビが来て、カラーテレビに交換されて、ステレオがコンポ式になって、手回し洗濯機が（ここは順不同だな。ステレオより前だ）2槽式になって、冷蔵庫のドアが増えていって……とか。と考えると交換だったように思えるが、エアコンのタイプは増える方向だったけど。

でも、今も同じように、手回し式洗濯機がCRTやテープに置き換わっただけで、あまり変わってもないようだ。

っていうか、ある年代になると（20代後半から30代ってことだ）は確定したインフラとしばらく付き合うってことなのかも。で、子供が目を見開いている時期になると、いろいろ交換がまた始まるとかかな。

_ StrutsとJSF

StrutsでWebアプリケーションを作っていると、どうにも気になる点がある。

アクションとJSPでシンコペーションみたくなることだ。

クライアントから見て、検索条件の入力→検索結果の表示 という2つの画面からなるアプリケーションがあるとする。

JSPの名前は、search.jspとdispaly.jspの2つで、まあ決まりとする。

で、この時のアクション名がすごく悩ましい。

JSP中心に考えると、search.jspが呼び出すのは、（最終的にdisplay.jspになるわけだから）display.doかな、と一瞬思う。が、実際にはそのアクションから呼ばれるモデルの役回りはsearchなのだから、なんか妙だ。

これが、2画面でもこうなんだから、検索条件の入力→結果のリスト表示→詳細表示の対象の選択→詳細表示というように、遷移が増えると、齟齬がますます気になってくる。

struts-configには、アクションとフォームを主体に記述する。JSPのほうはforwardで書くだけだ。だから、上のJSP中心主義の命名だとますます奇妙になる。アクションはdisplay、フォームはsearch、フォワード先はdisplay。かといって、アクションをsearch、フォームもsearch、フォワード先はdisplayとすると、こんどはsearch.jspに記述する遷移先がsearch.doで、なんかループしてるみたく感じてしまう。

ここらへんについては、ASP.NETとかJSFみたく、自分へのポストバックで駆動するんだ、ということを明確に打ち出しているフレームワークのほうが素直な感じだ。

_ 絵馬網

ブラウザーでアクセスすると、wema風なっていうか、wemaとは何をさしてるんだか、ここではJavascriptでポップアップされた箱のことだけど、がもちろん繋がって出てくる。で、メインのウィンドウ自体は消えてなくなるか、とにかく邪魔にならないようにどこかへ行ってくれる。

つまり、リンクの可視表現というか、ネットワーク構造がそのままデスクトップ上に表示されるということだ。

で、箱自体には、名前忘れたけど、ページのサムネイルか、あるいはなんらかのカテゴリー別の色をつける。頻出語彙かな。

で、箱をクリックすると、そのページが開くわけだが、その時点でネットワーク構造は今度はそのページを起点としたものに変化する。ってことは、ページが提供するんじゃなくて外部から与えなきゃならないな。

リンクページを踏むととんでもないことになる。

どこからもリンクされていないページを踏むとゲームオーバー。

箱と箱の間隔は実際のホップを元に計算するってのはばかくさいから、ホスト、ディレクトリ、程度でいいか。自己言及が多いと真っ黒の固まりとなる。

はてなのお隣さん表示のJavaアプレットがあったが、あれとは違うのは、ループがあることだな。

っていうか、実用性を考えたから、クリックしてページが表示とかになるんだが、単にネットワーク構造を表示するだけでも、それなりにおもしろいかも知れなくも無い。

つまり、ネットワーク構造が見たい。っていうか、好きだ。

#プログラムより先に言葉が出てくるのは老化の証拠だ。非常にまずい。

ever more

ちなみに、never moreは大鴉。

#サイトマップはあるんだな。

#追記：……

$options['hiki.uri']が抜けてるのと、トップレベルディレクトリがちょっと妙みたいだな。

_ Kazzの「JとNの狭間で」

なるほど、というタイトル。

別に誉められたからというわけではなく、AppDomainとかデリゲートとかスレッドとかの.NETで技術的におもしろいところをやっているので、リンク。

仕事で、このあたりをいろいろ調べながらやるのは実におもしろい（もしかしたら、それがMSのエサなのかなぁとか）ので、なんかすごくわかるなぁと好感をもったり。

_ NET

Encoding.getEncoding(string);をVS.NET2003付属のMSDNで見ると

プラットフォームによっては、特定のコード ページがサポートされていない場合があります。たとえば、日本の shift-jis コード ページ (コード ページ 932) は、Windows 98 の米国版ではサポートされていない場合があります。この場合、次に示す C# コードが実行されると、 GetEncoding メソッドは NotSupportedException をスローします。

と書いてある。で、信じてるとなんか妙な動きをする。で、結局、

ハンドルされていない例外 : System.ArgumentException: 8859_1 はサポートされたエンコード名ではありません。
パラメータ名 : name
  at System.Globalization.EncodingTable.internalGetCodePageFromName(String name)
  at System.Globalization.EncodingTable.GetCodePageFromName(String name)
  at System.Text.Encoding.GetEncoding(String name)

というのを捕まえた。MSDNを信じると例外を捕捉できないってのは、実にたまらん。

#というか、8859_1を与えられないってのもなかなかしびれるのだが。

_ とっても便利なIllegalArgumentException

とは言うもののMSDNの.NET Frameworkの解説は良く書けているから、ふと思ったのだが（というのは、試す気がないから試してないってこと）、Windowsの正規のコードページ名で、かつ、そのWindowsがサポートしていない場合（というのは、記述されている例そのものだ）はNotSupportedExceptionで、それ以外のわけがわからない文字列はアンドキュメンテッドなIllegalArgumentExceptionということなのかも。

もしそうだと仮定すると、2種類の例外を見なければならず、かつ同じ処理をすることになるので相当いやだな。

頻出するイヤなパターン

try { // 行数を稼ぐためにJavaの記述
    foo();
} catch (BarException e) {
    // 長い処理
} catch (BazExcetpion e) {
    // 長い処理
} catch (GooException e) {
    // 長い処理
}

長い処理がイヤならそこをメソッドにすれば良いのだが、気分的に例外処理からメソッドを呼ぶのはあまり良くない気がする。

でも、それは妙だな。多分、C++での経験から、例外処理に来たときはスタックとかヒープとかがいかれている可能性があって関数呼び出しでもっととんでもないことになることがあったから、本能的に忌避反応を起こしているだけかも。どう考えてもJavaや.NETではそういうことは無さそうだから安心してメソッドとして切り出すべきなんだろう。

でも、本当に欲しいのは次のような記述が認められることだ。

try {
    foo();
} catch (BarException, BazException e) {
    // 通常は、#messageとか#stackTraceとかの基底クラスのメソッド
    // 呼び出しとなるので、型の違いは重要ではない。
} catch (GooException e) {
    // GooExceptionキャッチ時に固有の記述
}

まあ、Exceptionで取って中で判定するという方法もあるわけだが。

#追記

違うな。むちゃくちゃだ。上のようにやりたければ、

...
} catch (GooException e) {
    ,,,
} catch (Exception e) {
    ,,,
}

と書けばよいだけの話なのだが、多分、上の例でBarExceptionとBazExceptionに継承関係がないため、いやでもExceptionのようなくそみそ一緒なスーパークラスしか記述できない点だな。

いやんな例：リフレクション。ネットワークがらみ（IOException＋アルファみたいなやつ）。JNDIみたいなの。

あるいは、単純に型名を書くのがうれしい病気に罹患しているだけかも。というか強い型付けがある言語でプログラムを書いていると、どうしても型名を指定したくなってくるのであるな。それは一概に悪いこととは言えず（というか言ってしまうと強い型付け言語って、単にコンパイラが最適化しやすいだけの仕組みですか、というようなとこに落ちてしまうかも）、あと、文化的宗教的な理由からか。

というわけで、継承関係を必ずしも無視するわけではない（上の例ではカンマで区切って並記した例外の共通のスーパークラスにeはなるはずだし、ならざるを得ない）、しかし複数の型を指定可能なcatch節の記述があるといいな、というような感じ。

_ WEB+DB PRESS特別総集編

僕も執筆させていただいた経緯から見本誌をいただきました。Vol1から24までのPDFがCDになって入ってくるという総集編ですね。しかし、こういうのを見るとつくづく良い時代になったものだな。1990年代にMSDNJJがこうだったらなぁ。

まあ、なんていうか時事ネタものが多いのは実用的な技術雑誌ならではで、その意味では今となってはそんなに役に立たない記事も多いとは思いますが（ワシのことかとおれカネ……とか言いたくなるよね）、やはりなんと言っても目玉は、既に出版社完売分(1〜11、13〜16)の中での、Vol.11の『RDBMS再入門』じゃないでしょうか（と言っても1〜9は読んでないからあくまでも僕の知ってる中では、と限定付きで）。もちろん、Vol.21の『データベース設計の基礎知識』もいいんですけど、こちらはまだ本誌を買えるわけだし。っていうか、1880円で1〜24がPDFで入っていてノートパソコンでいつでも読めるってのは大きいんだけど。

実際、僕は、Vol.11の『RDBMS再入門』読んで、羽生さんすげーと思ったわけだし。ここで、すげーと思ったのは記事を読んで目からうろこがぼろぼろという意味ではなくて、WEB+DB PRESSというズブの初心者対象ではなく、かといって遠く現場を離れてな人が対象でもない、まさに今、仕事をしている人を対象とした雑誌で、なんか人から言われたりそのへんから情報つまみ食いしてなんとなくわかったような気に1番なりやすい（というか陥りやすいというか）分野について、背景からあり方まできちんと説明されていたことでした。こういうのって、雑誌の記事として読みやすくしかも限られたページできっちりとまとめるってのはとても難しいわけで、しかもそれがアカデミックな方向でもなければ特定製品へのティップという形でもなく、実用的でいて、それでいてまさに『再入門』っていうタイトルの内容でまとめているってこと、それができているってことは、本当にこの分野のことを理解されているということでもあるわけだから、これは、すげー、脱帽だ、と思いました。本当、世の中にはいろいろすごい人がいっぱいいるな。

というわけでどうぞ。

あと、古びたとか書いてるけど、JSFやらStrutsのタグやらリファレンス系の記事って、PDFをPCに入れておくと結構嬉しいと思うから、その意味でもお買い得だと思います。

ちなみにVol2には、修吾さん、とみたさん、よしだむさんによるRubyでWebアプリケーション構築術とかもあったり。でも、LL系の本じゃないのでVol2という最初の頃の試行錯誤時代だけみたいだけど。

_ Form#MouseHover

リセットするにはPInvoke使え。

がーん。じゃあ、MouseHoverってなんのためにあるんだ？

どー考えたって、イメージマップみたいなウィンドウでツールチップみたいなものの表示に使いたくなるじゃん。っていうか、それ以外の使い道はなんだろう。

ところが、出て行くまではもう2度とイベントがファイアーされないとは。

……ってことはマウスの下に新しいウィンドウ（ツールチップ）を表示して消せば、再度エンターするからOKってことかな？ というところまでメモ。

_ 転載――SQLでのNULLとPreparedStatement

Oracleで利用できないというのはあれな感じだが、いろんな意味で覚えておきたい(イディオムとなりそうなものを作って公開するという意気込みが好きだし、読んだ限り役に立ちそうだ)ので保存しておく。

NULL と UNKNOWN を積極的に活用するSQLの書き方

元は2005年のはぶにっきのコメント欄。

_ EverMore

エバモー。

プログラミング的なトピックとしては非同期WebRequestとかかな。(追記：MTで動いているってわかっているのにまじめに排他制御してなかったのでSMPだとあっという間に死にます。ひどいので、後で修正予定）

問題としてキャッシュすりゃいいのにしてないとか、いろいろハードコードとか(GoogleやAmazonきめ打ちでリンクをたどらないとか)してるけど。とりあえず動くことは動く。

_ アマゾン

すべての道はアマゾンへ通ずとか思ったり。

_ インナークラスは好きだ

// ErrorHandling.java
public class ErrorHandling {
    public interface Handler {
        void execute();
    }
 
    public static void handle(Handler h) {
        try {
            h.execute();
        } catch (Exception e) {
            System.out.println(e.getMessage());
        }
    }
}

//Handler.java
public class Handler {
    public static void main(String[] args) {
        ErrorHandling.handle(new ErrorHandling.Handler() {
                public void execute() {
                    int result = 10 / 2;
                    System.out.println("result=" + result);
                }
            });
        ErrorHandling.handle(new ErrorHandling.Handler() {
                public void execute() {
                    int result = 10 / 0;
                    System.out.println("result=" + result);
                }
            });
    }
}

C:\Home\test\eh>javac *.java
C:\Home\test\eh>java -cp . Handler
result=5
/ by zero
C:\Home\test\eh>

_ デリゲートとインナークラス

なんか、Visual J++の頃の話題のような気もするが、単なる関数ポインタとしての利用方法としても、どうもインナークラスのほうが使い勝手が良い気がする。これは、結局インターフェイスとしてメソッドを束ねられるからのようだ。一方のデリゲートはメソッド単位での宣言となるから、まとめることができない。もっともIDEから作成する場合は、イベントと1対1となるからむしろデリゲートのほうが全体を囲むインターフェイス定義自体が不要となるからすっきりするのだが。

とういわけで、両方あると良い感じかも。……でもどちらか1つということならデリゲートかも知れないなと前言を否定してみたり。つまりどっちでもいいのか。

_ ポールグラハム

別にLispプログラマとして成長したいとは思わないが、すごい量（訳業も）なのでリンクしておく。質はまだ読んでないからわからないけど、それはやっぱりポールグラハムが言ってるくらいだからきっと良いのだろう。

On Lisp。

via ちくわプログラマの作業履歴@はてな。

_ コールバックとしてのインナークラス

find . -name \*.zip -exec echo "{}" \;

相当の処理を実装することを想定する。もちろん一発勝負なら簡単なわけだが、find相当の処理を実装したら、それは使い回しを想定したほうが良い。となると、次のようなクラスにするのが良いかな、となる。

public class Finder {
    public static void find(String root, String pattern, Exec exec);
    public interface Exec {
        /**
         * @return findと同じく0なら継続ということにしてみたり。
         */
        int exec(String currentFileName);
    }
}
あるいは、
public class Finder {
    public Finder(String root);
    public void find(String pattern, Exec exec);
    public interface Exec {
        int exec(String currentFileName);
    }
}

このクラスに対する最初の例に相当する呼び出しは次のようになるだろう。

 Finder.find(".", "*.zip", new Finder.Exec() {
         public int exec(String file) {
             System.out.println(file);
             return 0;
         }
     });

実際にJ2SEには、Arrays.binarySearchやArrays.sortのように、Comaparatorのようなインターフェイスを取るメソッドがある。したがって、こういう形で無名インナークラスを利用するのは比較的頻度が高いと想定されてるんじゃないのかな、と思う反面、それほど一般には見かけないような気もする（GUIアプリケーションだとイベントハンドラで結構出てくるが）。というか、内部クラス使うなルールのようなへなちょこ規約を見かけてなんじゃこりゃと思ったというのがあるのだが。

ちなみにArrays.sortは次のように利用する。

public class Sort {
    static class Foo {
        Foo(String initX, int initY) { x = initX; y = initY; }
        public String toString() { return "x=" + x + ", y=" + y; }
        String x;
        int y;
    }
    public static void main(String[] args) {
        Foo[] ary = {
            new Foo("B", 8), new Foo("A", 31), new Foo("A", 8), new Foo("C", 5),
        };
        java.util.Arrays.sort(ary, new java.util.Comparator() {
                public int compare(Object o1, Object o2) {
                    Foo f1 = (Foo)o1; // APIでClassCastExceptionを認めているのでこれで良い
                    Foo f2 = (Foo)o2;
                    int n = f1.x.compareTo(f2.x);
                    if (n == 0) {
                        n = f1.y - f2.y;
                    }
                    return n;
                }
// 追記(るいもさんのコメント参照)：こんなことをしてはいけない
//  Note that it is always safe not to override Object.equals(Object). 
// と書いてあるくらいだ。
// Java2の実装によっては、Comparatorのキャッシュか何かを利用する可能性があるってことなんじゃなかろうか。
// たとえば、既にソートした配列をキャッシュしておいてComparatorを見て
// 同じモノを返すとか。本当かなぁ？
// 更に追記：戯さんの指摘通り、Comparatorの
// JavadocにコレクションそのものがSerializableを実装している場合について
// の記述があるけど、TreeMap#comparatorをコンストラクタで設定した場合に
// 生きてくるようだ。というか、TreeMapのJavadocを参照。
// ちなみにTreeMap#putAllで実際に呼び出している。
//
// public boolean equals(Object o) {
//                    return this == o;
//                }
            });
        for (int i = 0; i < ary.length; i++) {
            System.out.println(ary[i]);
        }
    }
}

結果は次のようになる。

$ javac Sort.java
$ java Sort
x=A, y=8
x=A, y=31
x=B, y=8
x=C, y=5
$ 

もちろん、この例であれば、あらかじめclass FooにComparableを実装しておけば良いのだが、ソート方法などが1種類では不足する場合があるため、結局、Comparatorを与えることも必要となる。しかも、その場合は、その比較方法自体が呼び出し時点に特化していたりする。したがって、その特化した処理でのソート方法を一番読みやすい位置に記述するとしたら（最悪なのはComparatorの実装を別ファイルにすることだったりするのだが）結局、無名内部クラスとして記述するのが良いだろう。つまりsortの呼び出し時点に比較方法が示されるからだ。ただし別解としてこの例であればclass Fooのstaticな内部クラスとして複数のComparatorを用意するという方法もあるかも知れない。その場合はsort時点のコードから比較処理の実装自体は距離的に遠くなるが、あるクラスの比較方法の記述位置としては意味のある場所に収まるのだからそれほど悪くはない。ただし、いずれにしろ独立したトップレベルのクラスにしてはならないだろう。

ここで重要なことは次の点だ。

無名内部クラスの記述方法は確かに一見、ごちゃごちゃしているし、それに概念的にはほんのちょっぴり高度かも知れない。

でも、そんなことは全然関係ないってことだ。プログラムの可読性っていうのは、開発時には問題にならない。だからクソみたいなコードが生産されるってことは知ってる人は知っている。開発している人間にとっては第3者がどう思おうが、とりあえずそのコードを書いてしまえるし、かつテストまでしてしまうものだ。

可読性が重要となるのは、メンテナンスする時だ。それは大抵、最初に書いた人間ではない誰か別の人間がコードを読むことから始まる。その時に始めて可読性っていうのはものを言うのだ。

わかるかな？ ばりばり書いている時は、多少の読みにくさとかはそんなに重要ではないってことだ。だから、内部クラスが難しいとか、ごちゃごちゃしているかなんてことは、どうでも良い。重要なのは、ある処理を読み下しているときに、はるか離れたところをいちいち参照しなければならないようなコードを書くなってことだ。おお、この配列をソートするのですか。で、Comparatorを指定しているってことですな。で、どういう比較をしてるんだ？ それはどこだ？ となるのは最低だということ。ここで例を示したように、おお、この配列をソートするのですか。で、Comparatorではこういう比較をしているのですね、なるほど。――やっぱりこうあるべきだ。

さらに付け加えると、世に出ているコーディング規約は、1に間違いを入れないように、2に単純に、3にどうでも良い機能だけを利用するように制限（これは1や2とは直交してると思うんだけど。たとえば上であげた無名内部クラスが良い例だ。比較がその場にあるんだから間違いにくいし、単純だ。しかし、どうでも良くない優れた機能だから使うなと3がのさばるわけだね）、となっているように思える。でも、重要なのは、1でも無い。大抵、初回リリース時はうんざりするほど受け入れテストとかすると思うんだけど。そうでなければそれは御愁傷様としか言いようがないけど。だからよほどのへまをしない限り、コーディング規約で抑制可能な程度のバグなんて入らないものだ。もっととんでもない複数の条件が重なった場合に発動するようなバグが入るのだ。そして、もちろん、3であるはずがない。2だけだ。

でも、メンテなんてのは、ちょっと違う。上で書いた、とんでもない複数の条件が重なって発動した問題を解決するために行う時を想定しなきゃならないからだ。この時、最悪の状態ってのは、細い細い回線で仮想端末越しにあれこれするようなことだ。そのような場合でもちゃんと読めるようなソースを書くこと。つまり、必要な情報が80×24に収まること、昔からのUnixルールに従っていること、本当はこいつが1番重要なのだ。そうでなければ、気楽なものだな。

#すると重複コードはどうなるよ？ という疑問が当然出てくるのであるが、それはそれ、また幾つかの切り分けの考え方があるのだ。だから、コードを書くのはおもしろいし、間違いなく機械的には（読み取って修正するのも機械に任せられるようにならない限りは）処理できないってことでもある。

_ モックとしてのインナークラス

やっとここまできた。

っていうわけで、最近は、EasyMockとか利用しなくてもインナークラスでいいじゃんという気がしていたり。こんな感じ。

int evidence;
public void testUpdate() throws Exception {
    evidence = 0;
    testTarget.setDao(new DAO() {
        public DAO.Record read(int key1, int key2) throws SQLException {
            assertEquals(0, evidence++);
            assertEquals(10, key1);
            assertEquals(11, key2);
            return new DAO.Record() {
                int column1 = 111;
                public int getColumn1() {
                    return column1;
                }
                public void setColumn1(int newValue) {
                    column1 = newValue;
                }
                String column2 = "ABC";
                public String getColumn2() {
                    return column2;
                }
                public void setColumn2(String newValue) {
                    column2 = newValue;
                }
            };
        }
        public void update(DAO.Record rec) throws SQLException {
             assertEquals(1, evidence++);
             // このrecは上で返したモックと==が真。検証するには無名インナークラスじゃだめだけど。
             assertEquals(112, rec.getCoulumn1());
             assertEquals("CBA", rec.getColumn2());
        }
    });
    testTarget.foo(new FormData() {
        public int getKeyData1() {
            return 10;
        }
        public int getKeyData2() {
            return 11;
        }
    });
    assertEquals(2, evidence);
}

DIを利用するようにアプリケーションクラスを作るから、テストプログラムからは利用するDAO（ここでは文字通りDAOというクラス名としている）をセットできる。そこで、そのモックを無名インナークラスとして設定してやる。この中でAssertメソッド群を呼び出せるのは、インナークラスだからエンクローズドクラスであるTestCase派生のテストクラスを利用できるからだ。呼び出しシーケンスはevidenceという名前のフィールドで検証する。それによってモックの呼び出しが行われたことを最終的に検証する。

こういうやり方をすると、いくつかのコーディングルールが必要になってくる。たとえば、finalクラスは基本的に不可（上の例だとDAOとかDAO.Recordは継承している）。単なる値オブジェクトであってもゲッタ、セッタを用意する（上の例だとDAO.Recordの実装。この例ではセッタではアサートをかけていないので単に書き込み可能なpublicフィールドにしてもいいけど余り応用がきかなくなる）。など。追記：あと、パッケージプライベートも重要だ。上の例だとDAO.Recordなんてクラスは意味的にはDAOクラス内からしか本来生成するはずがないからコンストラクタをプライベートにしたくなるわけだが(無意味なメソッドの公開は良くないので、それはそういうものだ)、パッケージプライベートを利用することで同一パッケージに配置したテストプログラムからの生成を許すようにしておく。いずれにしろ、部外者はパッケージの外だから関係ないわけだし。

あまり良い方法とは思えないが(なんか本末転倒に思える)、DI抜きにしても動くように考えても良いかも。

class TestTarget {
    DAO dao;
    public void setDao(DAO newDao) {
        dao = newDao;
    }
    public void foo(FormData data) {
        if (dao == null) {
            // インジェクションされていなければ
            dao = new product.DAO();
        }
        ...
    }
}

_ JUnitの有効性

たとえば、StackだとかCalcだとかのテストであれば、呼び出しパラメータと戻り値の組でほとんどのテストが可能なわけだ。

ところが、ほとんどの業務アプリケーションって何かデータを貰って、それでデータベースをいじくることがほとんどで、ちょっと事情が異なる。

それでも情報取得系の処理なら、なんらかの戻り値があるはずだから（たとえば、Actionからmode.execute(param1, param2);と呼び出した後に、request.setAttribute("resultList", model.getViewDataList());とかしたり、あるいは直接request.setAttirubute("viewData", model);とかできるのなら、getViewDataList()の戻り値が実行結果と見なせる）どうにかなるかも知れない。

でも、更新系だとそうはいかない。

そこで、アサートするためには、メソッドの内部に入り込んで呼び出しを検証しなければならないということになる。与えたパラメータと、更新に利用する読み出したデータを与えてやって、更新のために生成された値を検証するという方法だ。

それを実行するには、モックを利用したエンドゥテストが必要となるわけだ。

もちろん、データベースを直接使うという手段はあるし、それはそれで良い方法だとは思う。setUpのたびにConnectionを繋ぐオーバーヘッドが気にならなければ。あるいは、テストプログラム内でコネクションプールを使うとか。そうすれば、呼出し後のテーブルから更新結果を読み出して検証することはできるからだ。

でも、DIを自由に利用するようになると、データベースへのアクセスはDAOを使うほうがいろんな意味ですっきりする。かつ、それによってエンドゥテストが可能となる。データベースとのインターフェイスはDAOに任せることができるからだ。で、任せているからモックすることも可能になるということだ。

_ 寒い

天気は良くなったけど寒いなぁ。

_ うむ

やはり高橋メソッドはおもしろい(だけじゃない)。

_ knoppix 3.7

X31にインストールしようと思ったら、stage2 not found problemに引っかかった。残念。

_ 優雅に時を過ごす

YARVで一発試してみたいことがあった。

しかし、それはWin32でなければならない。

というわけで、既に作ってあるMacのほうは使えない。

しかし、Windowsのメインマシンはちょっと変えたくないし。

で、X31に目をつける。

が、cvsがインストールされていない。

cvsがないと、viewcvs（だと思ったけど）で最新のtarballは取れるけど、ある特定時点のtarballが取れるかどうかわからない。

そこで、早速knoppixを入れてみようとする。

が、挫折。（上のエントリー）

が、coLinuxは具合がよさそうだ。

で、なんかでかくていろいろ入ってそうだし、使ったことないし、gentooを入れてみる。

む、開始できない。

調べる。どうも、カーネル2.6というのがひっかっかってるように思える。

だんだん、億劫になってきてdebianにした。

どうせだからディスク容量を増やすか。

むむ、reiserfsで作ったイメージがマウントできない。2.2と2.4じゃなきゃね、みたいに言われる。多分、カーネルにfsが入ってないのかな、それとも本当にカーネルのバージョンの問題なのか？　（それにしては、たださんは成功されているみたいだし）

かって知ったるxfsにしてみる。

だめだ、こっちはカーネルにfsが入ってない。

で、ext3で妥協。(追記：自分で検証したわけではない単なる伝聞だが、reiserfsは小さなファイルがたくさんある環境に向き、xfsは大きなファイルの扱いに向き、ext3はどこでも使えるだけ、とかそんな特徴があるらしいので。実際、ext3は使える、というか元のdebianのイメージがext3だったから使えるのはわかっているわけで）

それから日本語環境を作る。cannaとwnnはいるが、skkがいない。しかし、apt-get install skkすると、既に最新が導入済みと出る。後回しだ。

knoppixのcdに入ってたcywgin（結局入れてしまった）のXを入れる。使いやすいのか悪いのか良くわからないな。でもまあいいか。

で、やっとcobfsだ。

エラーなりまくり。

日本語ファイルがディレクトリに存在すると、そのディレクトリをマウントすることも読むこともできないみたいだ。しかし、その下にもぐるのは大丈夫。

ということがわかるまで、延々とdocuments and settings\arton\my documentsを、/home/artonにマウントしようとやってうんざりする。っていうか、マウントはできるのだが、その後は何もできないので厄介だ。

で、とりあえず共有ディレクトリを作る。

しかし、rootからしか書き込めない。Windows側のパーミッションかと思ったけど、それは無さそうだし。後回しだ。(追記：optionsで指定する。たとえば、dmask=0777）

で、sudo vi test.txtとかして、書き込みテスト。zzを打った瞬間にブルースクリーン。おお、本当に久々に見たぞ。（まあ、ノートンもいるし、原因を探る気にはなれないので、電源オフ/オン）

でも、cpはできる。なんかのタイミングだったのか？ でも怖いから一度ext3上に作成してから、cpでwindows側に送ることにする。

で、cvsから取得。

で、いったい、何をやりたかったんだっけな？ と我に返るともう夕方だ。

ちなみにcoLinuxのメモにはすごくお世話になりました。感謝。

_ clean

nmake cleanしたらvm_evalbody.incも消えてしまうのはイヤンだなぁ。

_ シャークテイル

子供と見てきた。

なんていうか、普通に実写で、ニューヨークのダウンタウンに住むファンキーなあんちゃんと、（どこに住んでるのか知らないけど）マフィアのボスの気の弱い息子の友情物語にしたほうがおもしろいんじゃないだろうか。そのほうが唄ったり踊ったりするシーンが生きてくるような気がするな。もっともそうなると見に行かない可能性が高いけど。

浜田光夫と吉永小百合の映画みたいだな、とか。

兄貴の思いやりとあまりに馬鹿馬鹿しい自爆っぷりが、なんともいやな感じだったり。

で、マダガスカルの前売りを買わされたり。もう、こういうのはいい加減うんざりだな。

上でも思ったことを書いてるが、人間がやれば十分なことをアニメで表現してもそんなに面白くはない。ニモにあって、こっちには無い要素って、集団演技だな。亀とかカモメとかアジとかの。あれが良かったのかな。あっちは人間がやれば良いなんて思わなかったし。トイストリーの場合は、視点の低さかな。でも、シャークテイルにはそういうものが決定的に欠けている感じだ。

あと、泳ぐってことよりも飛ぶってことのほうが表現的だし、実写で人間が空を飛ぶ姿はあまりにも間抜けているから（スーパーマンとか。ティムバートンのバットマンは滑空だからさまになるのであって。水平という向きが良くないんだろう。スパイダーマンも斜めの動きだなそういえば）そっち系統のやつは見られるのかも。あとは手、腕、肩の動きかな。吉川コウジがバタフライで向かってくるのはさまになるのは、そのあたりかも。

_ 哈爾浜

どうでも良いことでもあるが、僕の父親は哈爾浜生まれだ。なかなかにどでかい屋敷の中で偉そうに椅子に腰掛けている幼児のころの父親の写真を見たことがある。どでかいと思ったらつまり内地じゃなかったということだ。

というようなことをLogを読んでいて思い出した。

でも、僕自身はハルピンという語感(注：言葉の響きによって受けるいろんなもののことをこう書いてみた)を知っていてもそこがどんなとこかまったく知らない。で、クリックしてみた。

_ 三項演算子がわかりにくいという伝説

たとえ三項演算子が好きでも、チームが分かりにくいと感じたなら、使わない。

コードがドキュメントだ(マーティンファウラー)

また妙なことを言い出す親父めが。

というくらい、この妙な伝説を目にする。オブジェクト倶楽部のコーディング規約にもあったような気がするな。

では、質問だが、三項演算子がわかりにくいと感じた人って実際にいるのかどうかだ。わかりにくいと感じますか？

いや、おいらは感じないが、きっと感じる人間がいるはずだ、ってのは無しにしておこう。だいたい、自分はわかるが他人はわからないという考えは傲慢というものだ。

たとえば、COBOLやVBにはそういう演算子は無いから、彼等にはわかりにくいということなのか？ でも、そんなこと言い出したらclassとかinterfaceとかどうするつもりなんだろう。今時はあるからいいのかな？ でもinterfaceはないぞ。

そうか、わかった。interfaceはわかりにくいから使うなということですね。本当にそれで良いのか？

むしろ、こういうのはどうだろうか。

たとえ正しい英語のフルスペルが好きでも、チームが分かりにくいと感じたなら、使わない。ローマ字（内閣訓示式なら小学校の教科書にも表が出ているからより良い）を好め。

ローマ字だから、masinn（マシンのこと）、buluu（ブルーのこと。本当はアクサンシルコンフレクスみたいなマークを使うべきだけど無いから重ねる表記法（これも正当））、konpyuutaa（コンピュータのこと）とかでコードを書いてくださいね。

追記：

もっと良い例が見つかった。

たとえ単項演算子++や--が好きでも、チームが分かりにくいと感じたなら、使わない。右につくか左につくかで評価順が変わること、VB、COBOL、Rubyといった主要な言語には存在しないことから、最低最悪にわかりにくくバグの温床である。

っていうか、だったらC系の言語を使わなきゃいいだけだろうに……

さらに追記：

プログラミング言語C++でストラウストラップが、条件の部分はifの応用で（文法的には不要だが）カッコでくくれと書いていたが、僕はその書き方が好きだ。

return (condition) ? LOCAL : GLOBAL;とか、int var = (condition) ? GODLEY : CREME;とか。

実際、Javaのように条件がbooleanと限定されていないCとかで、return var1 + var2 * var3 ? var4 + var5 : var6 * var7;とか書いてあれば、それは確かに紛らわしいと思う。多分、真意は結合規則に頼っていて実際の評価結果がわかりにくいものを書くな、という教訓だと想像できるが、それがどっかのおっちょこちょいのために三項演算子だけが槍玉にあげられたんじゃなかろうか。っていうか、return (var1 + var2 * var3) ? (var4 + var5) : (var6 * var7);と無駄でもしろということだけのような。(さらに追記：というか、3項演算が8重くらいにネストしたら、それは読めないだろうということから、単純に量の問題−−メソッドの行数はだいたい50行くらいまでとかそんなやつ−−なのが、黒白はっきり主義者の魔手にかかってしまって全てかまたは無かという選択になってしまったのかも。黒白くっきり主義者は、メソッドが長くなるとわかりにくくなるからメソッド自体の記述禁止とかといった規約を掲げて欲しいものだ。あるいはプログラミング言語は自然言語と異なって人間にはわかりにくいからプログラミング禁止とか。そのくらい馬鹿げた言い分であるな）

_ ちょっと引っ張る

もちろん、僕は、3項演算子は好きだ。

というよりも、規約的なプライオリティってあるわけで、

・変数は宣言時点で初期化せよ(追記：む、C/C++ならだなぁ。Javaの場合初期化はされないけど、未初期化状態で使おうとするコードはコンパイル時に検出するからな。でも、いずれにしても初期化は必要なわけだし、宣言時点で初期化するのが良いと思う)

ってのは、相当プライオリティが高い。というわけで

 int radix;
 if (s[0] == '0' && (s[1] == 'x' || s[1] == 'X')) {
    radix = 16;
 } else {
    radix = 10;
 } // いくら例とは言え、8進数や2進数は無視かよ？

 int radix = (s[0] == '0' && (s[1] == 'x' || s[1] == 'X')) ? 16 : 10;

だろう。

あと、無駄な代入って嫌いだから

 int radix = 10;
 if (s[0] == '0' && (s[1] == 'x' || s[1] == 'X')) {
     radix = 16;
 }

ってのはあまり好きじゃない。

ってことは、必然的に3項演算子はばしばし使いまくりですな。

_ Son-Shi

これか。

追記：っていうか児玉さんのとこからもろリンクが出てるや。