日々の破片

_ 帰りが遅い

ついにバッティングが明らかになってこちら立てればあちらが立たずで帰りが遅くなる日がこれで2日目。しかし明日を乗り切ればおしまいだと勝手に決めているので、まあ良いか。

今日の教訓。

public foo(bar, baz) {
  super.foo(bar, baz); // 忘れても気付きにくく忘れるととっても困る
  ...
}

教訓というほどのことでも無いのだが久々にこれで1時間潰した。これがまた、あまりにもどうでも良い処理だったため（デバッグフラグの設定）にJUnitで検証していなかったという罠。しかし、まさにデバッグしようという時にこのバグのためにとても困ったのであった

今日の教訓の2。

A extends B, B extends Cという関係が成立しているところに、Bの兄弟が欲しくなり、Bを汎化してB extends B', B' extends Cとし（これによりB_brother extends B'可能となる）た場合に、肝となるメソッドが

protected void foo() {
  aaaaaa;
  try {
    bbbbb;
    ccccc;
  } catch (Exception e) {
    ddddd;
  } finally {
    eeee;
  }
}

protected void foo() {
  aaaaaa;
  try {
    foofoo();
  } catch (Exception e) {
    ddddd;
  } finally {
    eeee;
  }
}
 
// これが欲しくて汎化させた
protected void foofoo() throws Exception {
  bbbbb;
  ccccc;
}

bbbb ... bar.open();
eeee ... bar.close();

だったりすると、切り出したメソッドfoofooのbarに対する対称性が著しく欠けることになる。かくして、B_brotherでは見事にbar.open();を呼び忘れてはまること約10分（汎化作業に時間がかかった分だけすごくうんざり）。

#これの教訓は、後付けの汎化だと容易に対称性が悪いテンプレートメソッドが生まれるということ。常に切り出すメソッドはリソースの確保（open、newなど）と解放（closeやdestroyなど）を両方含むか、両方外すかでなければならない。

_ がーん

cvarのcをconstantのcだと誤解釈したとは言え(本当はclassのcなわけなのか)、varはvariableのvarだというのは見りゃわかりますな。

失礼しました。

_ 宣伝

るいもさんとのJava本です。

SEshop（こっちはちょっぴりだけど内容紹介文もある）。

4つの領域（開発前、実装、テスト/チューニングなど、設計――実装設計のほう）に分けて、簡単なことから複雑なことまで、いろいろなノウハウやチップス（や必要に応じて原則論も）を詰め込めるだけ詰め込んでみました。原則論もあるが、オルターネイティブについても書いてあったりするので、右も左もわからない初心者用ではありません。でも初心者が脱初心者を目指して実装設計＝実装（を、ついに等号で結んだな）を考えるための良きガイドにはなることは意識しているわけですが、位置的には中級本といった感じかな。まあ、この日記の3月から4月あたり（に執筆してた）にメモしたりしているようなことをまとめていたりもするので、大体の雰囲気や考えていることはわかるかも知れません。

個人的にはるいもさんのマルチスレッドバナナの叩き売りがお気に入り。

自分の書いたパートでは多値を例にしてTell Don't Askに繋げているやつが結構気に入ってます（追記：が、まさにこのパートにポカがあって正誤が入ったりしてるのがシオシオなんだな……）。

_ ソフトウェア技術者を考える

と言う愚痴から生まれたメモ。

若手→プログラム書く。じじい→設計（実装設計ではなくビジネスモデリングやデータフロー設計やコンポーネント配置とか）やる。

というのはクソですな。

むしろ、全体像を掴む練習とか散々にやった後で全体を俯瞰してホットスポットを攻めるとかのほうが順番としては良いのではなかろうか。つまり工程でいくと最初のうちは上流をやって、慣れてきたら下流へ進むというわけだ。

軍隊モデルというのがあって、尉官から佐官、元帥と進むに連れて統率する隊の規模がでかくなるとともに、戦術から戦略のほうに進むわけだが（で、そのうち現場を離れてバカをすると）、戦争にうまくやっていたころは元帥自ら船に乗り双眼鏡で眺めながら指揮していたりしたわけでまさに戦術をやっていたのであった（とは言え事例はたった1つに過ぎないのだが）。

だいたい自分が何のためにこれやってるんだということが曖昧だと目的を見失いかねないし、目的がわからなければ迷走してもそれほどおかしくはない。目的（戦略）は上流工程で明らかになり、それをドリルダウンして個々のプログラム（戦術）まで落っこちてくる。そういうのはわかっているから情報の共有というようなお題目がことさら唱えられるんだろうが、お題目を唱えるよりも、上流の現場に若手を投入することこそ重要なんじゃなかろうか。

_ まあそんなもんだ

勝手に決めてもそうは問屋がおろさずに今帰ってきたという罠。

_ OS-X

上流クラスは際立たなくても良いからさっさとStartOnFirstThreadの使い方を教えて欲しい。

_ 三段論法

Left-Labelから

1.人懐こい可愛い犬がいる

2.この町の人たちは良い人だ

3.許したる

ソドムやゴモラの人々も犬を飼っていたらどうだっただろうか、とか。

_ Googleでまぎらわしいやつ

These terms only appear in links pointing to this page: XXXX

キャッシュのほうを見なければわからないからこれ結構ガックリする。

_ JavaOne雑感（単に感想をだらだらと並べてみる）

ここ2〜3週間ほど本業の負荷が高くてあまり物事を見ることができなかったが、久々にいろいろ情報を掻き集めていろいろ想起させてみる。

いろいろ読んだ感じから考えてみると、こんな図式が書けるのかなぁ？（バズワードのオンパレードだけど）

1.密結合→疎結合

極論すれば、EJBによる分散オブジェクトから、SOAによる分散サービス

どうでも良いが、どっちも「コンポーネント」なんだよね。

例によってDCOM→SOAPに対する後追い感をなんとなく感じるが。

2.プログラムから記述言語（うまい言い方がわからない）

JSF（というかELということになるのか）にしろBPELにしろ、脱プログラム言語（というか脱プログラマーと言うか）。こういうのは今まで絶対的には勝利できなかったわけだが。

#っていうか、ELがキーワードみたいだから記述言語で良いのかも。

#ホワイトホースもからんでくるな。

#追記：Groovyもここだな。

※1+2=EJB3.0？

今後3年で予測されるバジーなビッグウェーブは？

ずばり、非同期プロセッシング（のキャッチーな言い換え）でしょう。

MSのIndigo、IBMのESB（のどっかにあるサブシステム）。

で、思い出すのはRambus（綴りは例によっていい加減）の圧倒的な先進的なイメージで、システムバス上をメモリーコントローラとメモリーがパケットをバカバカ投げあうやつだ。

で、消えてなくなってしまったわけだが。少なくても見てくれ上は。どっかに生きているとは思うが。

コンセプトの先進性に対して、実装コストが追いつかなかったのだろうか。

非同期プロセッシングとはなんだろうか？

基幹系置き換えにマストな機能だ。

基幹系とは何か？

JCLを使って

（ファイル→プログラム→ファイル）＋ （この＋は正規表現の＋）

を並べていくことだ。途中で分岐もある。

ファイル→プログラム→ファイル[A-Z]

ファイルA→プログラムA→帳票A

ファイルB→プログラムB→ファイルb

ファイルC→プログラムC→帳票C

...

ファイルZ＋ファイルb→プログラムZ→帳票Z

というようにファイルの入出力でプロセスを繋ぐことだ。ここで帳票の代わりにWebベースのオンデマンド出力に置き換え可能なものはありうるわけだが、日計のようなものは、オンデマンドすることが本当に良いかどうか微妙になる。あと、レポートそのもののイミュータビリティ（なんて言葉はあるのかなぁ）が重要なものでは、印字しなければならなかったり（CD-RへのPDFでのファイル出力とかでも良いかも）。

この時、機能を単純にたとえばJ2EEで置換していく場合、既に存在する機能そのものをリストラクチャリングすることは移行負荷が高くなるため、単にテクノロジアーキテクチャのみの置換とすることは十分にありうる（もちろん、クリティカルな領域についてはビジネスアーキテクチャの見直し変更もありうる）。

ここでプログラムとプログラムの接続をファイルではなくオブジェクト（あるいはメッセージ）で結合していく（そのほうがアプリケーションアーキテクチャからは設計しやすい）ためには、プログラムZのように待ち合わせを行うプログラムが存在する以上非同期メッセージングが必須となる。

さらに極論していくと、各プログラムを意味単位にまとめてサービスとして構成していくことが可能となる。この場合、トリガーとなる行為（JOBの投入に相当）から見た場合、同期プロセッシングされてはむしろ困る。

追記：J2EEバッチプロセッシングという方法も選択枝としてはあり得るから、必ずしもメッセージングで繋ぐ必要は無い。が配備個所が複数になると運用障害の発生要因となり得ること、POJOをうまく使えばオンデマンド処理と基幹系更新処理でクラスの共用が可能なこと、クライアントが極少数なためDBサーバー＝アプリケーションサーバーとすることによるメリットが多いこと（特にハードウェア障害に対し）、メモリーは複数JVMの実行より1JVMおよびDBへのキャッシュに振り向けたほうが有効なこと、モニタリング対象のの集中、オンライン更新（移行する以上これは目玉となり得るわけだから外しようがない）、特に最後の点から、サービスはバッチから切り離してやる必要がある。

そのためには非同期プロセッシングがうまくできなければならない。

本来は、MDBの役割のはずだが。

なんか、EJBでMDBって人気が無いように見える。

非同期プロセッシングそのものが持つ設計ノウハウの広い意味での欠落が原因なのではなかろうか？ たとえば、まともな非同期プロセッシングの本の少なさが1つの証左かも。

で、Rambusだ。

ハードウェアで起きたことはソフトウェアでも起きうる。

その場合未来はどうなんのかなぁ、とか考えながら、おいらは非同期プロセッシングが大好物なんでにやりにやりしてれば良いのだが。

さすがに、ここまでまとまりが無いとメモ未満だな。

_ SOA

と考えていけば、（このジャンルに関して言えば）SOAがバズワードなんていうのはとんでもない話だ。

まさに、30年かけて構築したメインフレーム上の基幹系をオープンシステム（オープンソースじゃない。マクネーリの言葉の意味でのオープンだ）で再構築するためには、必須となる。

なぜなら、30年かけて作られたマニエリスティックなゴシック建築をモダーン建築に置き換えることに相当するんだから、一朝一夕にできるわけがない（と思う）。

途中で、システムをバラバラに分割して繋げていく必要が出てくる。

この再構築自体に5年かかると想定した場合、5年間有効で移行負荷が軽く設計がしやすく設計が単純で負荷予測が簡単で障害対応がそこそこ簡単でマルチベンダーでも問題が起きにくくフロントエンドコントローラの設計実装保守がしやすく誰でもノウハウがそれなりにあり安く買い叩ける……と考えていけばSOA（HTTPベースのメッセージング）の現実性は明らかだ。

誰もこの領域にMQ（IBM）やMSMQやRPCやORPCを想定する気にはならないだろう。

なんとなくアパートメントモデルという言葉を考えつく。各フロアを繋ぐのは階段とエレベータ、各部屋を繋ぐのは廊下。すべて枯れきってお釣りが来るような技術ですな。

追記：で、旧館と新館をつなぐ渡り廊下のことをストラングラーアプリケーションと言うのかな？ ある日、誰も旧館には足を踏み入れていないことに気付く。そこで渡り廊下を叩っ切って旧館を取り壊す。

_ 作家主義(Auteur Theory)は遠くになりにけり

と思った。たとえば反もいるわけで(Googleのトップ。まあ、トップにふさわしいかも知れない。概観できかつ主張も明白)、当然のように反あるところに正がある。僕が生まれるちょっと前からある。それも声高にある（あった？）。だからこそ反もあるのだが。

それが、そんな言い方は無いとか言われるとさすがにビックリしてしまう。そんなもんだ。

追記：「そんなもんだ」というのは便利なもんだ。まるでreturn null;

_ 出世魚

かっこいいな。そういうのを作ってみたくなる。

その一方で車輪を再発明するのはくだりませんな、と思うジャンル（ということなんだろう）もある。そのためにもしかしたら作ったほうが早いかも知れないのに検証したりしてみたり。で文句言いながら実戦投入してみたり。たとえばスキーマコンパイラとか。ユニットテスト用のツールの類とか。ビルドツールもそうだな（これは早くないのは明らかか）。

どうも自分の好みのジャンルまたは自分のジャンルと考えているものについては自分でやってみたくなるようだ（って言うかあたりまえか）。で、つい自分でやってしまうところが

1.まさにプロ：自分の道具で自分で作る、正しい考え。完全に制御下においてこそ信頼できる。

2.アマちゃん：余分な作業を増やして何やっているんですか？ コストを考えているんですか？

ふむ。どっちでも良いな。作りたいものを作れないことこそ避けるべきだ。もし作ることができるなら。だが時間には限りがある。それが問題だ。

_ モーパッサン短編集読了

メヌエットを読みトスカの接吻を思い出す。

劇場では失笑や嘲笑が聴こえてきたが、確かに声はひっくり返ったりしていたが、確かにそれはいささか滑稽であったが、確かに監督作家は底意地が悪い視線の持ち主なのだが、だが、その視線の更に奥には優雅だった頃の面影を掬い上げ、美というものが実は永遠だということを想起させ（人生は短く芸術は永遠という言葉にある意味で反対し）、忘れ去られ行くものに対する愛情（多分、明日は我が身という感覚から生じる）で、世界を作る。

_ 神のお恵みを

で、リブロとかに行ってみると、意外なことに『ローズウォーターさん、あなたに神のお恵みを』どころかまったくカートヴォネガットジュニアの本が見当たらなかったり。確か早川文庫にあったはずだがなぁと思えども、置いてないものはしょうがない。

ちゃんとあるじゃん。でも文庫をAmazonで頼む気にはならないので明日というか今日、別の本屋で再挑戦だ。

一方単行本のコーナーに行けばサリンジャーはなんとなく理由はわかるが、結構いろんな米国文学の作家の本はいっぱいあるし。

で、まあ、それはそれでいいんだけど、あまりに早川文庫のところをウロウロしてたもんで、平積みされてたこいつにどうしても目が行ってしまった。

で、つい買ってしまって読んでしまった。

これは相当おもしろかった。孤島での地獄の訓練とかいうとデスハンターを真っ先に思い浮かべてしまうわけだが、同じくらい出口無しなイヤンな状況でなんとも言い難い。やたら国への忠誠を口にするのは作家のエクスキューズなのだろうかとか疑いながら、しかしデスハンターと時代も同じなんだがもちろん無関係なんだろうなぁとか考えながら、この島のすぐ近くに普通の人々が暮らす島があってとんだ災難だなぁとか考えながら、徐勝さんの顔を（解説に言及があるために）思い浮かべたり、バスジャックというのはどう考えたってうまく行くはずないよな（ここで想起しているのは名前忘れたフランス映画だったり、トカレフだったり、トカレフからTKだったり、そこから軍事政権っていうのは本当にごめんこうむりたいなとか）とか思ったり、わが国では赤報隊（同名の右翼がいたが関係ない。信相楽総三のやつ）や天狗党みたいなものかとか、あまり気分が良いものではない。で、隣の2つの国がこんなことをやっていてわが国だけが安全圏にいるわけはないわけで、それが今いろいろな形で少しずつだが解決しつつあるのは、まあ良かったということになるんだろうかな。

_ 前進モード

に入ったので読書はちょいと中断。

っていうか買いに行く余裕がなかったり。

_ 中断もなにも

今日は渋谷の紀ノ国屋と赤坂の旭屋を見たが、旭屋には影もなく、紀ノ国屋にはタイタンの妖女（変換候補に出てこないんで危うく違う検索語を入れるとこだった）とゆりかごのなんちゃらとスローターハウスだけ。

_ without EJB

というわけでこの国にはいらんと書いた舌の根も乾かぬうちに拾い読みをはじめるわけだが、なぜか最初に開くのは

Pefrformance and Scalabilityだったり。

しかし、XMLとWeb serviceのパフォーマンスについて、どうしてこうボロボロと文句が出るんだろうか？ あるものについてはnot issueで、あるものはpenaltyとする基準は、その人の必要性と利用局面なんだろうが、それにつけても腑に落ちない。とは言うもののDOMベースのスキーマコンパイラを使ってみたら多少は理解できたような気もするが。

_ メモ

choiceヤバイ。choice使うよりminOccurs="0"の要素としたsequenceのほうがいいんじゃないか？ choiceの価値はそこに並んだ要素のいずれか1つが選択されていることが検証できるという検証側の楽さであって、XML消費者および生産者にとってはsequneceの中で必要な要素を入れておくで十分な場合が多いというか、しょせんプロトコルなんだから十分だ。

さらに考えると検証側の楽さというか、スキーマ設計者の楽さ（choiceにはビジネスルールは無くchoiceだという事実だけがあり、minOccurs="0"の要素を並べたsequenceではこのうちどれか1つだけを入れるというのはビジネスルールとしてしか表現できない＝文字通り表現できない）。

と考えるとchoiceは正当だな。正当なのにヤバイと感じる理由はなんだろうか、と考えてみればCastorの実装に突き当たる。

Casotrの実装が検証の手間をおそらく省くためにchoiceとchoiceItemという2つの面倒なノードとして表現していることが問題なのか。こいつのせいで、choiceでくくられた要素の取り出し（と作成）とsequenceでくくられた要素の取り出し（と作成）が異なる方法（というかパスというか）となるため、ソースの自動的な生成がやたらと面倒なのだ。

追記：なんて言っている時間があるなら、XSDからRNGに変えるか（Relaxerの生成コードは使える）、Castor以外のスキーマコンパイラを探すか、自作するか（そりゃ面倒だからごめんだ）、打つ手はあるのだが考えなきゃならないポイントがいろいろあるんだな、これが。

_ やっと買えた

で渋谷旭屋もなくて、大盛堂の角のほうの店に行ったら見つかった。

ムシャリが古本屋でカーマスートラと一緒に2BRO2B買うとこまで読んだが（というかしか読んでないというか）、おもしろいや。

で、なぜこれまで敬遠していたか思い出した。

和田誠の絵があまり好みではないので買う気にならなかったのだな。

#追記：というより、むしろタイトルのレタリングが好きになれないというほうが正確かな。などと書きながら、父親が「この男が、この男が」とわめいているまさにその時、表紙の絵の状態でいるところまで読んだ。

_ WSX

という言葉を捜しているときにたどりついたページ。

Schema browserが結構、見やすい。

_ 読了

……

_ 表紙に絵がついた

#どなたか知りませんが、ご予約ありがとうございます。

今までのどのるいも/arton本よりも、（なんかレノン/マッカートニーとかジョーンズ/ストラマーとかジャガー/リチャードとかボウイ/キーチとか加藤/北山みたいだな、しかし最後のは一体なんなんだ）お互いの色が強めに出ている（のは方法論が多いからだな）ので、ある程度までは矛盾したことを(フォロー付きであっても)平然と書いているから真の初心者にはやはり向かないのだが（章によって理由付けや対論の参照などが付いているにしろ正反対のことが書いてある――例：配列をどう引数に使うかとか例外とか――ここでおもしろいのは配列については多分正論がartonで効率論がるいもさん、例外については正論がるいもさんで効率論がartonと、必ずしもそれぞれが同じロールを担っているわけではないのは興味深い）、やっぱりこれはおもしろいよ（と、校正用PDFを読みながら思う）。

仕様を前提とした上での経験に基づく知見集のような本だから反論や納得できないものもあるかも知れない（というかあるはずだ。方法論が主なんだから――定数の扱いとかでもるいも/artonで一致点と不一致点がある）ので、絶対の神の意見のようなものを求めている場合にも向かないだろうけど。

というわけで、新入社員もそろそろ5月病を乗り切って暑さにへばってる頃だ。可愛い後輩へのプレゼントに是非どうぞ。

追記：絵がついたところで著書目録を更新。

_ ？なぜ絵が出ない？

キャッシュされてんのかな？ でも何がだ？

……(ちょっとサーバーを見る）……cache/amazon/ASIN# がそうなのか。（ついにソースを見る前にデータを見るまでに堕落してしまったようだ）

_ ADC

StartOnFirstThread（というか、今はW2Kなんで正確なメッセージが手元にないから嘘かも）のバグレポートに対して最初の解答が来た。

で、ローンチャのサンプルソースへのポインタと、なんでそんなことが必要なのかとの質問。

一応ソースを見て、おおpthreadってこうやるんですか（Win32ネイティブと、JavaとRubyのスレッドしか触ったことが無いわけで―追記：WinCEネイティブもさわったな、そう言えば）とそれはそれで勉強になったけど、ruby.cでそれやるわけには行かない（ことは無いけどやりたくない。-r で指定できるのが欲しいわけだし。やるんだったらmainからpthread作ってそっちでRubyの初期化からrjbのロードまで全部やることにしてメインスレッドは単にそっちのスレッドの終了シグナルの受信専用――とか書いていて気付いたがfork,execじゃないんだからそんなシグナルあるのかなぁ、あるんだろうな、ローンチャのサンプルを読めば良いわけだが今はW2Kなんで……とループ）ので、なんで必要かをリプライする。

英語が通じるかと、必要性が通じるかの、2つの通じるか、不安と希望が耕作するノウアスフィア! おっと間違えた交錯する（ってのはエルマーのネズミだっけなぁ）

_ 買ったマンガ

存美が妙にリアリティがあって怖いんですが……

それはそれとしてこの妙に元気な子供が主役のシリーズのシリーズ（河童のやつも妙に元気な子供が主役のシリーズだし、そういったシリーズがextendsではなくimplementsされているシリーズ）は一体なんなんだろうなぁ。

       <<interface>>
          さすらう元気な子供
               △
               ｜
  ＋−−−＋−ー＋−−−−−−+−−−//
　｜　　　｜　　　　　　　　　｜
 河童    親を探すやつ      これ
　　　　　　　　　　　　　　 △
                    ＋−−−＋−−−−//
　　　　　　　　　　 ｜　    ｜
                  それぞれの話

ただ、こんだのは元気な子供が自分のことを生きていると確信をもって勘違いしているから、あっちとこっちを自由に行き来できるところが実装のキモのようだ。

恨みは己の心を汚すだけじゃ　　　　（と仏のような顔で話し出す）
くやしさに耐え悲しみに耐えてこそ魂は強く大きくなれるのじゃ
……（中略）
そなたをこんな目にあわせた者たちは皆心がみじめなのじゃ
そなたは今の心の壁を越えよ
……（中略）
さすれば壁は越えられる
……とかいっちゃあ
皆　泣き寝入りしちまうんじゃわい　（足踏みバンバン）
呪い殺しちゃるわ あのガキども 　　（おっかない顔）
わしの大事な弟子をここまで　こけにされてだまってられるか
グチョグチョにしちゃる

と、相変わらずの花輪節も健在（当然、呪われた連中は基本的には惨め無残な死を迎えることになる）

なんか妙にパワーダウンしているような気もするが、いい加減にヒロシみたいなのを書くのがイヤになってきたのかな。というわけで、相当マトモな人間が初めて出てきて、十分にマトモな行動を取るわけで5に期待というところか。

_ どこまでバラすか

入力値AにルールBを適用しCを作成しDに保存する。

#1.バラさない
class Hole
  def do_all(a)
    # b
    if (a == 0)
      c = a + 1
    elsif (a == 10)
      c = a * 2
    elsif (a == 20)
      c = a * 3
    else
      c = a
    end
    d = Persistence.new()
    d.write(c)
    d.close
  end
end

 
#2.bをバラす
class WithoutB
  def do_all(a)
    b = B.new(a)
    d = Persistence.new()
    d.write(b.c)
    d.close
  end
end
 
class B
  def initialize(a)
    if (a == 0)
      @c = a + 1
    elsif (a == 10)
      @c = a * 2
    elsif (a == 20)
      @c = a * 3
    else
      @c = a
    end
  end
  attr_reader :c
end

#3.BとDの統合
class WithoutBandD
  def do_all(a)
    B.new(a).save
  end
end
 
class B
  def initialize(a)
    if (a == 0)
      @c = a + 1
    elsif (a == 10)
      @c = a * 2
    elsif (a == 20)
      @c = a * 3
    else
      @c = a
    end
  end
  def save()
    d = Persistence.new()
    d.write(@c)
    d.close
  end
end

#4.2と同じだがDから具象性を奪う
class WithoutB
  def do_all(a)
    b = B.new(a)
    D.instance().save(b.c)
  end
end
 
class B
  def initialize(a)
    if (a == 0)
      @c = a + 1
    elsif (a == 10)
      @c = a * 2
    elsif (a == 20)
      @c = a * 3
    else
      @c = a
    end
  end
  attr_reader :c
end
 
class D
  def self.instance()
    D.new()
  end
 
  def save(c)
    d = get_writer()
    d.write(c)
    d.close
  end
 
 protected
  def get_writer()
    Persistence.new
  end
end

#5.2と同じだがBを細分化する
class WithoutB
  def do_all(a)
    b = B.create(a)
    d = Persistence.new()
    d.write(b.c)
    d.close
  end
end
 
class B
  def self.create(a)
    if (a == 0)
      b = B0.new(a)
    elsif (a == 10)
      b = B1.new(a)
    elsif (a == 20)
      b = B2.new(a)
    else
      b = B.new(a)
    end
    b
  end
  
  def initialize(a)
    @c = a
  end
 
  attr_reader :c
end
 
class B0 < B
  def initialize(a)
    @c = a + 1
  end
end
 
class B1 < B
  def initialize(a)
    @c = a * 2
  end
end
 
class B2 < B
  def initialize(a)
    @c = a * 3
  end
end

_ スカンジナビア

チャーチャチャー……

デンマルク、ノルウェー、スェーデン＋フィンランド

なんか良くわからない謎の国々である。辺境のようで辺境でない。

確かにいつか行ってみたいなスカンジナビアだなぁ。しかしフィヨルドに囲まれた暮らしも悪くないかどうかはさっぱりわからないが。悪くないと言えば砂漠に囲まれた暮らしも悪くないかも知れない。でも粘土砂漠は悪そうだが。

ストロウストラップとかリヌスとかヤンソンとかニルスとかカウリスマキとかシベリウスとかアンナカリーナとかノキアとかグリーグとかアンデルセンとかベルグンドとか固有名詞は結構出てくるのだが、わかっているようでわかっていないし。

もうちょっと南下したドイツもいつの間にか随分遠くなってしまったようで、僕にはクリスチアーネFとファスビンダーあたりが最後のようだ。そう言えばクリスチアーネFの慣れの果てが出てくる映画を見たがあれはなんだったけかな。ラースフォントリアじゃないし。ベルリンのローザフォンなんちゃらかなぁ。

deをdkを最初取り違えてなんとなくそんなことを思った。

_ 失敗者

失敗者というのは、未完成のまま次々と次を作る人のことと定義する。ここではバッハがそれにあたる。

煙草を吸うように映画を撮ったファスビンダー（40本以上撮ったということは年に2本近く撮っていたということだ）も当然、この系譜に入ることになるだろう。

逆に成功者というのは、完成させる人のことで、ベートーヴェンがその筆頭になるのかな。小津もこっちの系譜だろう。ある時点で完成してしまうから、その後は安定した（良質でなければ成功ではないので当然ながら非常に高品質でもある）完成品を定期的に生産可能となる。

ここでの失敗者という妙な言葉は、looserの高橋悠治的な言い回しと考えてみれば、確かにファスビンダーが失敗者なのは間違いないのは、そこで語られるのは敗者達だからだ。

失敗者という言葉を使うことで、勝敗とは異なる観点から見直すことができる。そこにあるのは、敏感に時代の流れに耳を澄まし影響を受け次々と新しいことに挑戦し過去を捨てたり拾ったり漁ったりしながら膨大な実験を積み重ねていく行為である。その過程は極めて豊かあり、生産物は非常に多い。無いのは完成だけだ。

膨大な積み上げということから、突然ゴミおばさんとかゴミおじさんとかを想起すると、まったく異なる側面も見えてくるわけだが。

だが、ゴミおばさんと「失敗者」の相違は、前者は捨てることが出来ないのに対し（その意味では逆に成功者である）、失敗者は平然と捨ててしまうことだ。なぜ捨てられるかと言えば、いくらでも次を作ることが可能だからだ。

かくして陰極まれば陽となるような制御の反転が生じる。失敗者というのはその定義から多様な生産者となる。

技術は失敗者の手によって作られる。ということだ。

_ 失敗者（続）

ふーん、意識してなかったが、微妙に互換性とからむな。

失敗者は幾らでも生産できるから、腐れAPIだなと感じたら（腐れ設定ファイルだなでも良いが）やーめった、と放り出して非互換な次のやつをこしらえる。

成功を夢見て追従してきた人達は変化を前提としてないから古びた以前のものと、合わせるためには相当手数が必要となる（検証量も増えるし）新しいやつに乗り換えるべきかで困ってしまう。

だが失敗者はまったく気にしてくれない。だって気にする必要は無いからだ。手を動かせば解決するわけだし。そして失敗者は手が早いのだ。

まるで槍を持つこのような人のようだ。

_ 今日は

会社をさぼってということは無いがJ2EEカンファレンスの予定。

_ 次は

では、猫のゆりかごを読もうかな。

_ ローズウォーターさん、あなたに神のお恵みを

読了してから色々考えてみたが、読んでいる間はあれだけおもしろかったのに妙な寂しさだけが残るのはなぜだろうか。

最後の取ってつけたような終わり方のせいだろうか？

親父に多分、他人を不幸にしていることを指摘されることにより、別の自分になる、あるいは自分を取り戻す。それは冷たい自分なのだが、1年ほどして最後の最後でまた自分を取り戻す。

そのもう1人の自分と取り戻した自分の結論がどちらも同じだということが笑うべきとこなんだろうか、それとも深く考えるべきことなんだろうか。単なる誤読なんだろうか。

それにつけても金の欲しさよ。

_ J2EEカンファレンス

EoDについてのみ。

どーしても、デジャヴュとしか思えないのだが、ちゃんとラセンが上に上っているか確認してみる……やっぱり同じところを1周遅れで回っているだけのような。案件が違うから違うといえば違うのだが、開発技術という意味ではどうなんだろう。

多数のペタポトプログラマと少数のJSF「コンポーネント」プログラマ？ オレはVB5の頃のTechEDに来ているのか？

ペタポト……DBアクセスのコードが不要ですなぁ――オレはADOの頃のつまりVB6の頃のTechEDに来ているのか？

いや、クライアントアプリケーションではなくて、Webサーバーの開発ですと来れば、Visul InterDevの頃のTechEDに来ているのか？ ああ、でもコードビハインドが出てきているから2000年のころのTechEdかも。

ほとんどあれだなぁ。

歴史は2度繰り返される。最初は悲劇として、次は喜劇として。うら寂しくなるだけだから某Mさんがどうしたとかは言わないほうが良いと思うよ。

EoDというのは、結局のところ、End of Developper ということなのかなぁ。ああ、End of Dawnか。明けてしまえばただ白々しいだけだ。

それはそれとして、JAX-RPCの非同期メッセージングがクライアント側だけの非同期処理というようなことを聞いて後でちゃんと調べようと思った（が、忘れるだろう）。

それよりも、Validatorが妙に少なくて疑問だったのだが、ConverterがValidatorを兼ねてることがわかったのが妙に現実的な収穫だったり。

#まあ、それはそれとしてJava Studio Creatorは良いですな。

何が良いって、モデルを作るのに時間をかけられるからだったり（VBが必要なのは、ATLで作ったコンポーネントのテストを楽にやるため、というのと同じノリだ）。

追記：思い出した。1番、納得したメッセージは「もまえらStrutsやめてJSFサポートしたIDE使え」ってやつ。なんでStruts使うかって言えばActionとJSPでのTaglibですな（モデルはどっちにしても別だ）。で確かにJSFサポートしたIDE使えばこっちのほうが楽。で、こんなところは楽なのが1番。で、競合技術はStrutsではなくPHPだとのこと（とまとめてみる）。

#タイルは？

_ なんだかとっても

いそがしーなー

で、Strutsで現実逃避の術なのだが、テストしないでモデルを作るんだったらJSPに直接スクリプトレットを書くほうが早いのでは無いかと今頃気付く。

って言うか、Tomcat5にしたんだからEL使って書けばそのほうがいいんじゃないだろかとか。

_ コンパイラの見分け方またはブラックホールチョイス

<xs:sequence>
 <xs:choice maxOccurs="unbounded">
  <xs:element name="foo" type="fooType"/>
  <xs:any processContents="lax" maxOccurs="unbounded"/>
 </xs:choice>
 <xs:elemenet name="bar" type="barType"/>
</xs:sequence>

もし正しくハンドリングできるスキーマコンパイラならば、それは神認定したい。

たとえば、foo,foo,bar,foo,bar,foo,baz,foo,bar,baz,foo,barまで読み込んでも、それが最後のbarなのかchoiceの中なのかは、まだ判断できない。ということは、このsequenceを抜けたところの要素の出現まで見なければならないからだ。でも、それがchoiceの中なのかは、まだ判断できない……

_ 今頃バージョンアップ

$?を使いまくってたのね……

#で思い出したけどレシピブックでのsystemの戻り値の記述は違うんじゃないかな(今日騒いでいたのを横で見かけてちょっと試してみただけで手元に無いから確証は80%くらい)。1.8.1だけど真偽値が返ってくるけど。

_ キュアー

5日前くらいか、リブロで本を漁っていたらどっかで聞いたような歌声が流れてきた。ちょっとヒステリックなでも明晰な声だ。しばらく頭の中の歌声データベースに対してパターンマッチングして、ああ、ロバートスミスかと気付いた。

最後に聴いてからどれくらいになるだろう。よもや新作かな？

で気にしたものの、そこは本屋だから（CDもあるけどちょっと違う）それまでだった。今日になってHMVに寄れたからあらためて探すと本当に新作だ。しかし4年ぶりと書いてあるな。僕にとっては一体何年ぶりなんだろう。なんかジャケットの絵も良い感じだから購入決定。

というわけで買ってPCに突っ込んでから切り替え器で別のマシンを触っていたら、なんか同じ曲が何度も繰り返されるんで変だと思ったら、ジャケットのアニメがループ再生されていた。でクリックするとオフィシャルなシークレットサイトに飛んだりして。エンハンスドCDってのはいつまでたっても慣れないな。それにしてもジャケットの絵＝ループしている絵は子供の絵だなぁと思ったら嘘か本当かニースとかネフューとか書いてあるし。そのループしてたTHE END OF THE WORLDは良い曲だ。

ライナーを読むと、久々のレコーディングなんでプロデューサーの意見を取り入れて、ロバートスミスが個々の曲のレコーディング前にメンバーに対してユースケースを説明してどうしたとか書いてあるが、なんかXPみたいだなぁとか思ったり。

ロバートスミスは以前も書いた覚えがあるが、スージーアンドザバンシーズのプロモビデオで走らされて躓いたりしていて無器用そうな小太りの小僧だったのが、キャタピラガールのあたりでコムサデモードコムデギャルソン（失礼な間違いだ）のスーツみたいなのを着て妙に洗練されて出てきたり（今思えばシザースハンドみたいだ）、スカスカしたハーモニカのやつではXYZマーダーズの最後の箪笥だったりガンスのナポレオンの雪合戦だったりその時その時で同じようなモノを見ていたから妙に思い入れがないわけでもない。で1番好きなやつはCOM Meets Rubyで引用していたりもするのだが。そりゃやっぱり猫が好き。

_ 子供の絵が動く

ニールヤングの午年で、ニールヤングの息子の書いた汽車の絵が動くのがあった。確か人間は飛んでいるんじゃなかったけな。というのを思い出した。

_ 子供の絵が動く(続）

あーSqueakを忘れてた。そう言えば科学技術館の友の会のやつでSqueak教室があるから申し込んでやろうと思ったら5年生以上だったので門前払いというのを思い出したり。

_ アンチパターン名

ファットイベントハンドラ・アンチパターンという名前を考えたがどんなもんだろうか？ 文字通り、イベントハンドラに無闇に処理を詰め込んだアンチパターンのことだ。

具体的には良くあるVBプログラムや、StrutsでActionに直接データベースアクセスコードを書きまくるようなプログラムスタイルのことだ。

既に知られたアンチパターン名ってあるだろうか。

_ 小さい電話を買いたい

携帯というと特定のメディア（物理層なのか？）になってしまうみたいなんで、小型電話と言うとして、早い話、京ポン（kdmsnrさんだな）か、WIN端末（こっちはたださんだ）かどっちにしようかと迷っている現在。ちなみに最大手というのは好きでは無いので（とは言えMSはキライではない）ドコモは選択枝には無い。

で、京ポンっていうのはH"だから64kbpsだけどWINってビット数だけはやたら多いのだからそっちが良さそうな気がする半面、それにしては相変わらずPHSは生き残っているわけだからきっと美点もあるんだろう。

_ やっぱりWINかなぁ

もっさりしてるんですかぁ。そう言えばそんなことも書いてあったような。小型と速度のトレードオフだとB5ノートでは小型で泣きを見たしなぁ。

#やっぱスピードスターを目指すのが王道かな

_ ボリショイサーカス

犬、猫、熊、ライオン。

犬は時々ミスをするがそつなくこなしてるかな？

猫は途中でやめてしまったりする。猫ですなぁ。

ライオンはドーナツみたいな赤いもの（多分肉だろうけど）を先に付けた金属棒と、何もついていないやつ（電撃かな？ それとも単なる棒なのか）を交互に使ってる雰囲気。雄9対雌1という配分には何かあるのだろうか、とか。どうも雌が1番芸達者なように見えるが単に付き合いが長いだけかも知れないのでそういうことはわからない。

で、熊は普通に熊で、どうも1番賢そうに見える。熊っておもしろいな。子供が熊と写真を撮りたいというので（そういうサービスがあって、熊か犬か猫かの選択制。妻に寄ればアクロバットダンサーの選択を加えればおばさんたちで大繁盛ではないかとか）行かせたところ、熊にさわっても良いと言われたので首筋を撫でてみたとか言う。ふわふわしていたというので、ちょっとびっくり。剥製の熊とかの感じでも見た目でも剛毛っぽいんだが、違うのか。剥製の熊と言えば五日市街道で武蔵境あたりを通ると熊のでっかな剥製を店頭に置いた剥製屋さんがあって、とても気になる。

_ ○//|

先に7月を読んでしまったから（間抜けた感想だと思っても）どうにもしょうがないが、6/25すごくおもしろかった。

非常に個人的なことを書いて、それを第3者が読んで味わえるというのは、随筆家ってのがかっていたから（今はいないと思う）事実なんだろうが、どうしてこういうものが書けるのだろうかなぁ。

_ 抽象ファクトリパターンって面倒だ

だからまじめに実装する気にはならず、常に直接ファクトリメソッドを実装し、中でいろいろやることにしている。

実際、どのくらいクソマジメに抽象ファクトリパターンを利用しているシステムってあるのだろうか？

たとえば、COMのIClassFactoryを考えてみる。確かにこれは抽象ファクトリなのだが、現実問題としてIClassFactoryを生成してから実際のオブジェクトを生成している人っているんだろうか？ CoCreateInstanceを使ってるんじゃなかろうか（結局、同じことだし）。

Javaではどうだろうか。XMLReaderFactoryは抽象ファクトリではなく単なるスタティックメソッドとしてファクトリメソッドを提供している。内部ではプロパティからXMLReaderの実装クラス名を得て生成するから生成するオブジェクトについては十分に抽象化されていると言える。

抽象ファクトリパターンではなぜファクトリが抽象化されているかと言えば、ファクトリメソッドを抽象メソッドとしたいからに他ならない。しかし、代替手段があればそんな実装を行う必要はない。たとえば、IClassFactoryについて言えば、レジストリによってPROGID＋CLSID＋xServerエントリによってクラスがパラメタライズされているからCoCreateInstanceスタティックメソッド（というかWin32APIだから関数）で代替できる。Javaの場合、文字列からClass.forNameで実体化できるからXMLReaderFactoryはスタティックメソッドの提供で十分となる。

その一方でjavax.crypto.SecretKeyFactoryみたいに抽象ファクトリを教科書どおりに実装しているものもあるわけだが。

でも、SecretKeyFactory#getInstanceの引数をPROGIDと見立て、それをCLSIDと見立てたクラス名に変換して、そのクラス（KeySpecとProvider、SecretKey……というか、こいつは生成するオブジェクトの種類が多いからこれはこれで正解なのか）を返送するように実装したほうが素直ではないか？ というか、java.sql.DriverManagerなんか、まさにそういうパターンのような（直接クラス名を指定してforNameで作れとなっている）。

むしろ、抽象ファクトリクラスよりも、オブジェクトそれ自身にファクトリメソッドを用意したほうが良い場合もあるのではないだろうか（実装固有の処理をクラス内に閉じるため）。

abstract class A {
 public abstract A newInstance();
 ...
}
class B extends A {
 private B(B org) { ... }
 public A newInstance() { return new B(this); // Copy default settings }
}
class C extends A {
 private C(C org) { ... }
 public A newInstance() { return new C(this); // Copy default settings }
}

_ 暑いですね

そうですね

子供のころジャンプを読んでたらカエルが2匹出てきて、「さぶいれすれー」「そうれすれー」とハナを垂らしながらしゃべるのがあって、学校ではやったが（誰かが「さぶいれすれー」と言うと「そうれすれー」と返す）なんのマンガだったかな。

_ 抽象ファクトリパターンを実装する意味がある場合

JNDIからルックアップしたインスタンスから、何かのインスタンスを100個生成することを考える。

この場合、最初の時点でインスタンスが必要だから、ファクトリクラスが必要となるし、newできないことから（ルックアップするという前提から）抽象ファクトリパターンを実装したものになる。

_ 何か起きたんだろうか？

と不思議に思う日々。

しかしある意味、とても貴重な日々のような。

TechEDまでにはカタがつくんだろうか？

_ 戦略と戦術をちゃんと考えましょう

とまじめに書いてみたり。

今、なんでも良いけど（どうせ例だから）何かのプロジェクトがあってそこに参加することが決められていたりすると仮定する。

当然、そのプロジェクトのミッションってものがある。どうでも良いお題目でいけば、納期厳守とか稼動後障害発生率1件/?期間を目指すとか、そんなものだが、ここで言っているのは、そのチーム内での自分のミッションのこと。たとえば、なんちゃらマスターの更新プログラムを5本、なんちゃらバックアップツールのフロントエンドを1本、とかそういった具体的に割り当てられた作業のこと。

で、こいつを片付けることは戦術だということ。

戦術は戦略を成功させるためのステップに過ぎない。

そこで、戦術もちゃんと考えなければならないということだ。

たとえば、戦略を「現在の社内のプロジェクト運用の腐った方針を180%方向転換させ、XXXXな方法論に基づいた運用を行うようにすること」というように設定したとする。どのような戦略かは戦略立案者の立場によるから内容が正しいかどうかは置いておく。したがってXXXXには好きな言葉を入れると良い。たとえば、バザールでも良いしノンドキュメントでも良いしバーターリーでも良い。

それを実現するためには、戦術としていろいろあるどの方法を採用するかを考え、実行する。普通は3種類くらいから選択する。・隠忍自重で忠実に方針を守り信頼を勝ち得ていく、・基本的に方針を守るが、部分的にオルターネイティブを使えばよりうまくいくことを実際に示す（それには90:10は1つの目安となる。ここで0:100でやると和を乱す狼藉者扱いが待っていると考えられる：次項）、・無視してうまくやってのける。後ろに行くほど危険な戦術となる。特に最後のは、失敗すれば致命的だし、成功しても後ろから斬られる可能性がある。

というようなことを考えながら仕事をしている人間ってのは外から見てると大体わかる。結果的にそれまでの仕事の履歴が有機的に結びついているから単に経験がついているだけでなく、知見というものが養われているからだ。

ところが思い返してみれば、戦術と戦略の区別とかそれぞれの立て方といった重要なことは、中学生くらいになったら思考訓練として義務教育でやるべきことのように思えるのだが、そういった教育を受けた覚えはない。これは不思議なことだ。帰納法と演繹法は高校のころに教わった覚えはあるが、こっちはある意味、思考法としては基礎も良いところだから意味合いが異なるし。

_ 惜しい

いんすたんすをせいせいしてくれるっていうと誤解されそう（もちろん生成もするけれど、コンストラクタベース限定じゃないし、生成くらいは当たり前でありがたみがないということで）。っていうかせいせいって言葉もイマイチかな。

（っていうか、本当はつっこみたいのだが、外部つっこみ禁止らしいのでここで書いてたり）

しーさーはおぶじぇくとをつくったあとに、いんたーふぇいすやなまえをきーにせっとあっぷしてくれるんだ。だからおぶじぇくとのめそっどをすぐによべるんだ。おぶじぇくとのほうだってぷろぱてぃをよういしておけばすぐにめそっどのじっそうにはいれるんだ。

手品師のポケットというメタファを考えついたぞ。なべとにくとねぎとしらたきとしょうゆとさとうをぼけっとにいれとけば（えっくすえむえるでなにをいれるかはかいておくんだけどね）、あとはなべをとりだせばいつでもすきやきがたべられるよ（っていうか、ふろふきだいこんやおでんとかのほうがよいかも）

_ 続き

おぶじぇくとのほうだって……の部分に着目してみる。

その意味ではオブジェクトデシリアライゼーション（アンマーシャルでも良いが）の一種かも。だが、違いがあって第1にゲッタの作成は不要だ。根本的にデシリアライゼーションと異なるのは、元の状態が最初にあったわけではないという点だ。

ゲッタが不要という点から、ビーンを作るというのとは感触が随分異なる。もちろんデシリアライゼーションとは全然異なるから、バージョニングのようなものを意識する必要もない（というか、シリアライズされないからやはり意識は相当異なる）。

この作成時の感覚の独特さが、ある意味、1番の新しさのように感じるかも。

public class Foo {
 Bar bar;
 public void setBar(Bar newBar) {
     bar = newBar;
 }
 public void doSomething() {
     assert bar != null;
     bar.doBar();    // おお、なんだこれは？
 }
}

_ ワーテルローに陽は落ちる

何気に目に涙。

_ 映画

と言っても子供とポケモン。

しかし、なんだこれは、と相変わらずなんとも言えない不快感。筋のひどさはおいておいても、ポケモンを怖がっている（見りゃわかる）子供に無理矢理ポケモンを近づけるようなガサツな押し付けがましさを誰も疑わないところが既に不快だ。というか前提としている世界がポケモンと慣れ親しむ行為が水を飲むように当たり前なんだからしょうがないのかも知れないが、それにしてもイヤな話だ。それにつけてもプラスとマイナスのポケモンは可愛いんだが。

ご都合主義もさらに磨きがかかり、さすがに子供も言葉を解析する部分などには後から妙だとか言い出す始末。今年で終わりになりゃいいな。

が、それはそれとして、蓮のポケモンは見てて楽しい。

結局、筋のひどさが気になるということは、映画としてつまらないということだ。おもしろい映画は筋なんて気にならないからだ。だからプログラムピクチャってのも存在できるわけだし。

で予告編だが、やっぱりスイングガールだな。

_ 凧揚げ

風があるから5メートルくらいは普通に揚がる。でもその後水平になってしばらく漂った挙句に落下する。糸の引き方が悪いのか風があるのは地面に近いとこだけである程度上は無風なのか、良くわからない。

_ 最後のゴジラ

に行きたいと言われたので親子ペア券を買う。前々回のがつまらなかったから前回は行かなかったのだが（というかハム太郎は苦痛だ）、今回はハム太郎が無いからまあ、いいか。って言うか、ポケモンもそうだが2本立てを1本にしつつあるのかな。

で、これまでの怪獣集合のようなトランプがオマケに付いてきたが、見事に知らないや。ミニラはさすがに知っているが、それ以外の子供が3種類くらい（成長したやつらしいが）出てるが、どれも初見。意外と見てないものだ。あるいは忘れてるのか。っていうか、なぜ轟天号が出てくるのか？ 緯度ゼロ大作戦ってのはなんか足が溶ける沼のシーンは妙に覚えているが、海底軍艦は全然覚えてないや。でも妙にカッコ良いとは思ったのは覚えている。モグラタンクみたいなドリルがついてたが。で、図書館で押川春ロウ（字を忘れた）の原作を借りて読んだがすさまじくつまらなかったというかきれいさっぱり覚えていないな。でも、海野十三の本の裏表紙に出ていた地中の秘密基地の絵はわりと覚えていたり。江戸川乱歩の手にかかると大暗室だが、同じ地下の大宮殿でも海野十三のはかっこ良かったな。しかしこれまた見事に覚えていないのは不思議なものだ。第3の手で特許を出願する男の話は割と覚えているが。特許を取れて喜んで首を振ったら首を締めたり。でオチがゾーですってなんなんだろうか。

子供の頃に読んだきりの本なんて忘れてしまうのだろうか？

と言うと必ずしもそうではないようだ。

変なことだが、筒井康隆のSF入門だかは意外なまでに細部を覚えている。オールディーズの地球の長い午後とバラードの結晶世界の2作とか、ベスターの虎よ虎よとかについてとか。あと、ファーマーの名前もここで知ったのだろう。しかし既に図書館で借りた時点では古くなってしまっていたから、ベスターは分解された男が創元文庫にあるだけだったし（バラードも入手できたな、そう言えば）、他のは随分後になってから読んだようだ（地球の長い午後は記憶が鮮明だ）。分解された男ってしかし覚えてないなぁ。悪徳企業家が分解される話だってのは覚えているが。

最初に文庫本を読んだのが4年か5年の時にハーンの怪談奇談を買ったのが最初だから、その頃のことだろう。なぜか次に手に入れたのがにぎやかな未来だったというのも覚えている。これは何度も読んだから相当覚えている。時間を認識する尺度がどんどん短くなっていき（009の加速装置作動中みたいだ）最後にトラックにじわりじわりと轢かれるやつとか。なんかラジオのスイッチを入れるとボサノバが聞こえるというシーン（にぎわかな未来そのもかな？）が妙に印象的なのはボサノバという言葉のせいだな。腸が腸捻転の後遺症でクラインの壷化するってのを思い出した。数年間大便をしていないことに気付き医者へ行く。で医者がマッサージをすることで捩れを解消させる。とてつもないクソ話だが、良くこんな話を考えついたもんだと今頃になって感心したり。それから幻想の未来というのも買って読んだ。砂漠をひょろ長いのが2体放浪するシーンがあったかな。とてつもなく美しく寂しい小説だったと記憶するが今となっては読むかどうかは微妙だ。こないだ本を整理してたら出てきて値段を見ると160円とかだ。奥付を見ると本当に4年くらいの時に買ったようだ。

幻想の未来 (角川文庫 緑 305-1)(筒井 康隆) 今もあるのか。

追記：そうだ。この時、初めて作家というのが1つのタイプの作品だけを作るのでは無いと心底了解したのだった。にぎやかな未来と幻想の未来、名前は似ているがまったく異なる作品だったからだ。最初はにぎやかな未来のようなものを期待していて死ぬほどがっかりしたのだが（っていうか小遣いは幾らだったんだろう？）、その後には幻想の未来を何度も読み返したはずだからだ。

で、友人が北杜夫の船乗りクプクプを貸してくれて（新潮文庫だった）、そこで僕も北杜夫を読むことにしたが、たまたま手にしたのが『遙かな国遠い国』だが、主人公がちょっとうすのろで捕鯨船か何かでゲロを吐くと回虫が出てきたというような細部を覚えてるだけだな（で、この主人公はシベリアで恋人たちを見るのだが、中学くらいで再読したのかな？ ちゃんと認識してるってのは、動くな死ね甦れを見ていて急に思い出したのだから間違いなさそうだ）。あとホープの銀紙を丸める趣味の人間が虫に襲われる話とか。小市民とのはじめての邂逅だ。あと2人のうち1人はパチンコだが、もう1人はどんなんだっけな。（追記：ここでも1人の作家が全く異なる作品を作り出すということを叩き込まれているな）

と記憶をたどると、中学の時読んだものは相当きちんと筋とかも追えるが、小学生のころ読んだものでそれっきりのはほとんど細部を覚えているというのがせきのやまのようだ。と思ったが水滸伝とかは相当覚えているなぁ。さすがに108人全員は言えないが金毛犬の段景ジュウが108人目で1人目が宋江とか（追記：108人目は犬じゃなくてノミだったような気がしてきた。だとすると犬は107人目かな）。

そう言えば、最初に見た怪獣映画っておそらくガッパだと思うが会議が多くて退屈だったような記憶がある（というか何も覚えていない）。あれは大人用だったのかな（しかも松竹だったと思うし）。そこでガメラが出てくるんだろうか（こっちは大映だ）。ガメラ対ギロンは割と良く覚えている。三角形のモジュールを逆に嵌めて連絡通路の制御を逆転させるとか。

_ マドレーヌ

みたいな高級なものから流れが生まれたんじゃなくてゴジラトランプだからこんなもんだな。それにつけても馬の首風雲録って掘り出して来るまではきれいさっぱり忘れていたが、すごく影響を受けたはずだ（感動したのは覚えているからだが）。ちなみに280円、11歳だ。今の子供にとってのハリーポッターみたいなもんなんじゃなかろうか？ がさっぱり思い出せない。

_ 727

シメトリカル。

昨日みたいに、朝に猛烈な雨が降るとその日は結構ご機嫌なものになるのかな？

_ 今日のバグ

GUIDの表記方法は、{AABBCCDD-EEFF...}だが、実際のバイト配列としてはDDCCBBAA...というようにリトルエンディアンが使われる。

あるテーブルのキーにGUIDを利用しているのだが、ディスプレイ表現（って言うのかな？ 可読表現）としては、{AABBCCDD...}のほうを利用しているとき、都合3つの処理を経由してから読み取りが行われるアプリケーションを構成した。

1. パラメータにGUIDを付加したURLを生成し、該当URLへのアンカータグを乗せたHTMLを返送する（ここでは読み込み対象には特別なセキュリティ的な考慮は不要で、人間がGUIDを入れるのは大変だからLINKを生成しているので、GETのクェリーストリングとしてURLに組み込むことに問題は無い。というかwgetでGUIDを指定するシェルもあるし、いざとなればURL直打ちの読み取りもやる必要がある）

2. （Strutsを使っているので）ActionForm#getGuidを通してActionがGUIDを取り、モデルに与える

3. モデルは与えられたGUIDをキーとして読み込む。

で、3でどうやっても読み取りエラー（というかSELECTの結果が0件）となる。ユニットテストではうまく行くのにエラーになる。

ここで、サクッと1と2の過程を疑えば良いのにそうしなかったのは、なぜなのかなぁ。1. ではアンカータグのテキストとしては可視表現、しかしクェリーパラメータとしては後の加工の楽さを考えてニブルを文字列化したもので表現していた。しかし2.の作成時点では、アンカータグのテキストに引きずられて可視表現化されたGUIDからバイト列化する変換をかけてた。そのため、本来のGUIDとは異なる値が渡っていたのだった。

教訓1：GUIDからバイト列への変換関数がまずい。フォーマットが異なる文字列を与えられたら例外を通知すべきだ。（与えられた文字列から単純に{}-を捨てて結果の32文字のニブル表現からエンディアンを考慮してバイト配列に直すように実装していたため、最初からニブル表現でもそのまま処理が通り、単純にエンディアンの交換処理が実行されてしまっていた。文字数や{}の有無でよいから最初にチェックすべきだろう。

教訓2：見た目と異なるデータというのは必ずしも良くない。見た目が可視化表現のため、2.のステップで特に意識せずに変換関数を呼び出している。

教訓3：思いつきで作っていく場合には、入出力くらいメモしておいたほうが良い。1を作った時点では、クェリーパラメータの流れはコンピュータ処理なんだから最初からニブルにしておけば効率的だと考えたのであった。が、2を作る時点でコロリと忘れている。

教訓4：簡単過ぎるプログラムは問題かも。2のActionは実質8行くらいのコードしか持たないのでここに問題があるなんて全然考えつかなかったのは良くない。これが40行くらいあれば、テストプログラムを作ってただろうな、とか早めに見直したかも。

教訓5：テストを信用する。モデルはテストを通ってるんだから、ここに問題が無いのはわかっているのに、（テーブルの扱いにちょっと特殊なことをしているため）ここを疑って無駄な時間を使ってしまった。

特に1と2だ。5は反省点。

_ GREE

なんか送れたんだか無視されてんだか良くわからないインターフェイスだな。

_ Visio

Viso(多分2000)で、UMLを書くと最初のセーブの時に死ぬほど時間がかかる。だから、Visioは好きじゃなくてインストールされたままになっていたんだが（Judeを使う）、ところがフローチャートを書かなきゃならなくなってしまったのではたと困った。Excelで書く人もいるみたいだが、矢印が箱に付いて一緒に動かないツールを使ってあのてのものを書くのはご免だ。それくらいだったら死ぬほど待たされてもいいやとVisioをいやいやながら立ち上げて――っていうかフローチャートが見つからなくて変だなと思ったらソフトウェア図じゃないんだな。まあ見識だ――使ってみたら、サクサク動く。保存もリーズナブルにできるではないか。ちょっとびっくりした。

_ inject into

（文法は）わからんなりに参考になる気がする。

_ スラド

今日、はじめてスラドから知識を得た。それは、ウホッの語源だ。わけねぇな。

_ 今日のスパマーナンバー1

その名はアマゾン。

っていうか、たださんのところに情報が集約。

でも、30分に1件/1登録だから可愛いもんかも。

_ メディア

おもちゃというよりはマーキュリー劇場を連想した。

メディア側の人間は、そのメディアを実際にエンターテインメントのメディアとして捉えることができるくらいそれを熟知している。

が、現実がそれに追いついていない場合がある（でも手品だと思ってない人が現実にいたということ自体がメディアが作った伝説なんじゃないかと思うこともある）ということかな、と思ったのだった。

とは言え、対話性があるというのが（本当に？）相違点だな。しかしマーキュリー劇場を聴いていて裸足で外に飛び出した人たちは、きっと家族で会話したのじゃないか？ マリックを見てた子供（年齢関係なく）は子供同士でハンドパワーって何かと話合ったんだろうとも思う。

#送り手側ではなく、受け取り手側に着目したわけだな。

_ JSCのバグ

HtmlHiddenにvalidatorを設定するとValueChangedListenerへのバインディングが生成される。逆も真。

_ 大人はわかってくれない

っていうか、わかってあげる気にはならない。というか、ネタだろう？ マジなのか？

#下のほうのレスポンス群を眺めて釣れたとか言ってるとしか思えん。

#奇妙なのでマークしておく。

#つーか下のほうの連中もあまりに妙なんで原因と結果を勘違いしている者が続出。

#これ1人の人間が全部書いてるんだったらおもしろいな。

#こういうのをたくさん読ませておいてから「残業代とか休出代とか妙な制度ですな。年俸制へ移行しますた」とか言われると納得してしまう人間が出てきてもおかしかないな。

_ などと

書いていることがすべて自分に降りかかっているというワナ。

_ よっしゃ

見えた。光明が。月の影から抜け出す太陽が。