日々の破片

_ AC

Anonymous Coderなのかなぁ。Anonymous ProgrammerならAPだけど。

実はAnonymousじゃなくAlienとかArabiqueとかだったり。Anti ChristもACだな。Amazon Comってこたないか。

_ それにしても検索数が気になる

access.log見て同一クライアントからの要求じゃなさそうなことは確認したが、なんでなんだ？ ブレークするにはわけがあるだろうし。

_ おれたちのような泥棒

僕はジョイディヴィジョンが本当に好きだったから、ニューオーダーは好きになれなかった。だいたいいくらああいうデンデコスタイルのベースの弾き方だって歌を歌えばどうしても弱くなるから、最初から歌がイアンカーティスに敵わないだけならいざ知らず、ベースの音までジョイディヴィジョンより弱くなってしまったわけだし。

でも、ティーヴスライクアスはかならずしも嫌いじゃなかった。きれいなジャケットのマクシシングルだったんだが、本当の理由は曲でもなければジャケットでもなく、ましてやニューオーダーじゃなく、そのタイトルだった。

thieves like usは、エドワードアンダーソンの小説の題であると同時に、2つの優れた、そして僕の大好きな映画に関係するからだ。

1つはニコラスレイのデビュー作で、邦題は『夜の人々』または『彼らは夜生きる』。でも原題は、they live by nightだから、どちらかというと、彼らは夜に依存して生きる（依存なんて言葉を使ってはだめだろう）、彼らは夜にまぎれて生きる（闇にまぎれて生きると妖怪人間だが）、というような感じだと思う。

ファリーグレンジャーがボウイキッドの役を演じていた。キーチは忘れてしまったが、調べたらオダネルとからしい。最初は映画史上最初のヘリコプター撮影を利用して、逃走する自動車のシーンから始まる。そして、最後、銃撃戦の中でボウイは死ぬわけだ。

いっぽうのボウイとキーチは、原題はThieves like usでアンダーソンの題をそのまま使っている。ボウイはキースキャラダインで、この役者はストリートオブノーリターンも良かったし、アランルドルフの作品でもとても良かった。もちろんボウイの役も。キーチはシェリーデュヴァルで、そのせんからわかる人にはぴんと来るのだが、作家はロバートオルトマン（アルトマンかな）だ。

どういうわけか、ボウイとキーチという3流の強盗の物語より、ボニーとクライドという強盗の物語のほうが良く知られているのは不思議なことだ。

でも良く考えてみれば、ボウイとキーチも、彼らは夜生きるも、俺たちに明日はないも、いずれも、大恐慌時代に食い詰めて銀行強盗で生きることになったカップルの物語だが同じところはそこまでで、大胆でお洒落で最後まで派手なボニーとクライドとくらべてボウイとキーチは頭も悪そうだし、やることも田舎臭いし（ボウイキッドがいきがってバカにされるシーンとかあるし）、大して稼ぎもしないから、どうしても・貧乏・バカ・勤労青年という感じとなって（ようするに、吉永小百合と浜田光夫のチンピラ映画みたいなもんだ）それだけで痛々しい上に、最後2人がいんちき臭いモーテルに隣接した教会でしんみりと結婚式を挙げたりして、その日のうちに撃ち殺されたりするから、悲惨な感じが強くてまあ、そんなもんかも知れないかも知れない。だからこそ、like usなんだろうが、usと言われてもちょっと困る。しかし、オダネルのリンクしたページを見るとガールネクストドアとか書かれているから、ニコラスレイもそういう女優をきちんと選んだんだろう。フェイダナウェイとは同じ土俵に立ってないわけだ。（でもファリーグレンジャーは良い役者だ）。

しかし、そのいんちき臭い教会だが、なんか忘れたけどアメリカのうさんくさい風習について書いた本を読んでいたら、あっちでもラブホテルのようなモーテルの利用方法はあるんだけど州によってはいろいろうるさかったりするんでモーテルについたら教会で結婚式を挙げて、部屋に入って次の朝は離婚する（法的なことは無しなんだろう）というシステムがある（った？）というのが出ていたから、あー、ボウイとキーチの結婚式ってそういうのを使ったということで、見ている人間には本当に惨めなカップルであるなぁと（本来の使い方ではなくて、2人はカタギに戻るつもりで本気で結婚式を挙げているわけだから）感じさせる泣かせどころなんだな、と得心したのであった。（いや、本当にかわいそうなシーンなのである。カタギになってまじめに働いて子供を作ってどうしたこうしたみたいに希望を持って生きようと決めて、その決意を確認するためにまともな人のように結婚式を挙げることに決めたのだが。指輪を買う金に困って一番安いのにするんじゃなかったっけな。確か。でうさんくさげにマネージャに眺められて、その結果、お尋ねものだとばれて密告されるんじゃなかったかな。しかも神父はお祈りをすっ飛ばすし――1番安いコースだからだ。

というようなことを、やたら参照されているページを見て思い出してみたりしてみたり。

しかし、ニューオーダーのティーヴスライクアス（マクシシングル）は当然としても、ニコラスレイもオルトマンもDVDは無いんだな。大傑作なのにな。

_ 私の2セント

オダネルのページからリンクをたどったら彼らは夜生きるの評に出会った。

そこにa two-dollar affairと書いてあって、この語で検索しても引っかからないからこの評者の造語かも知れないけど、なんとなく納得のいく言葉ではある。

フォーリンアフェアは、名曲だ。マンハッタントランスファーのカバーも良かったけど、トムウェイツのオリジナルはさらに好きだ。

しかし、『異国の出来事』はないだろう？ でも、トムウェイツのオリジナルと違って、マンハッタントランスファーの洗練と洒脱、軽やかさからは、確かに突き放して『出来事』としたほうが良いのかも。

_ デッドロック

コンポーネントAからコンポーネントEまでが連携してa〜cまでのテーブルを処理する場合、これまでの慣習から各コンポーネントと更新するテーブルの関係がA(a)-B(b)-C(a)-D(b)-E(c)だとする。

ちょっと待った。これってデッドロックするんじゃないか？

と普通は考えるだろう。（同時に複数のトランザクションが実行される場合）

たとえば

A(a-0)-B(b-1)-C(a-1)-D(b-2)-E(c-0)

と

A(a-1)-B(b-0)-C(a-2)-D(b-1)-E(c-0)

を同時に実行すれば、ほぼ確実にCかDで止まる。

この場合、AからEまでで1つのトランザクションなのだから、

A(a)-C(a)-B(b)-D(b)-E(c)

に変えることができる。し、そうでなければそれは1つのトランザクションではない。（実際はBがCの実行条件を設定するかも知れないので、そうとは言えないが、この時点ではその可能性は無いと仮定する）

ところが、これまた過去の経緯で処理すべきキーが必ずしも昇番順でないとする。

たとえば

A(a-1)-C(a-0)...

と

A(a-0)-C(a-1)...

を同時に実行すればこれまた確実に止まる。

この場合、動的にコンポーネントの実行順序を変えてみたらどうだろうか。

つまり、

C(a-0)-A(a-1)...

と

A(a-0)-C(a-1)...

というように、対象となるテーブルのキーの昇番順に処理順を変えるということだ。

このように変更すればデッドロックは起きない。

しかし、動的に実行順序を変えるということが可能だとして、本当にそれで処理的な問題は発生しないのだろうか？

それはもちろん処理内容に依存する。AでCが利用するなんらかの値や状態をセットアップするのであれば、この順序の変更は致命的だ。

そこでAで実行するセットアップ処理A'をAから分離してみる。この場合、

A'-C(a-0)-A(a-1)...

A'-A(a-0)-C(a-1)...

と実行することになる。しかし、A'の処理内容がAの結果に依存するのであれば、すなわち、A'の実行条件として事前にAの処理が完了していなければならないとしたら、この方法は単なる画へ居（むかむか、なんで変換しないんだ。さらしとく――追記：コメント欄参照）と化す。で、たいていの場合、そんなものだ。

また、Cで処理するロウの決定がAの処理に依存する場合には、最初から順序を変えることはできない。

結局、おもしろそうではあるが、実行時に順序を変更するという方法はうまくいかないことになる。

そこで、あらかじめ、デッドロックが発生することを前提してしまうという方法も取れる。楽観的に行こう。どうせデッドロックすればデータベースマネージャが教えてくれる。

だが、タイムアウトを待たせるのは問題があるとする。レスポンスが重要な場合。

その時は、処理表みたいなものをグローバルに参照可能として、自分がロックすべきロウをすでにロックしたトランザクションが、現在自分がロックしたロウに対する待ち状態になっているか判断させるという制御をすることになる。

これは面倒だ。

そこで、やはりデッドロックの発生をロジカルに無くす方法を考えることにする。

それは可能か？ まず、Aを実行しなければCの処理対象が決定できないというルールをどうにかしなければならない。たとえば、ここで1回トランザクションを完結させればどうだろうか？ だが、Eの実行に失敗したらすべて廃棄という処理であれば、ここで完結させるのは考えものだ。

しかし、補償ができるのであればこの一連の処理をロングトランザクションとみなしてしまえば良いことになる。

とすれば、たかだか3個のテーブルを更新する5つの処理であっても、ロングトランザクション足りえる要件を持っているということになる（ロングトランザクションという呼び名よりは、サーガトランザクションという呼び名のほうが、この場合しっくりする）。

だが、それ以前の問題としてアイソレーションの必要性があればどうか？ A-B-C-D-Eが完結するまで更新内容を他のトランザクションが参照してはならない場合だ。

そこで面倒になって、シリアライザブルに実行させることにしようと考えてみる。しかし、デッドロックの現実的な可能性と、実際に捌かなければならないトランザクション量、AからEまでの処理時間を予測すると、どうしても並列処理が必要だとする。

結局、どうにもならないのではないか？

そこで、ぎりぎりの短さでデッドロックタイムアウト検出時間を設定し、再試行処理を実装することを考える。

実はこれが一番、簡単である。A-B-C-D-Eを順に呼び出すコントローラがデッドロックでロールバックしたことを検出できれば良いからだ。

for (;;) {
   try {
       A(); B(); C(); D(); E();
   } catch (DeadLockDetected e) {
       continue;
   } catch (Exception e) {
       log("!");
   }
   break;
}

しかし、もっとうまい方法があるような気がする。そもそもAとCが同一のテーブルaを更新するというのが間違いなのではないか？ 正規化すれば実際には異なるテーブルとなるものを、1つのテーブルとしてインスタンス化してしまったのではないか？

あるいは、本当はA-B-Eと、C-D-Eという異なるトランザクションなのではないか？ もしそうならば、Aの処理完了時に同一トランザクションを利用するキューイングでC-D-Eの実行をスケジュールすれば良い。だが、そうではなかったらどうすれば良いか。

デッドロックする可能性があるトランザクションの存在というのは分析ミスなのか、それとも仕様に内在されるものなのか？

もし後者だとしたら、何かおかしいのではないだろうか。あらかじめエラーがロジカルに予見されるシステムというのが、なぜあり得るのか。

_ 混迷の現代（どういう意味だ？）

思想を持てない人は、他人が「思想」と口に出すと勝手に痛みを感じキレる。存在の空虚さを無意識のうちに自覚しているからだ。似たような症状として、他人の言質に対しプロ市民というおそらく誤用に基づくレッテル貼りをすることとして顕現することも散見される。自分が選択したアティテュードの歴史的な正当性の無さを無意識のうちに自覚しているからだ。

#と空疎にして根拠がない言葉を断定調で書いてみたり。

_ 本当は誰のなんて言葉だっけなぁ

疎にして嫌だが非はあらず

_ rjb途中

とりあえず、桑島さんのattach_current_threadを使う一方、JNIEnv*を引数で与えるように変更したソース。

1つにはsleepさせるためのループかも。

いずれにしろ、次のようないかにもありそうな状態で死ぬ。

 	msvcrt.dll!7800bd65() 	
 	msvcrt.dll!7801e742() 	
>	msvcrt-ruby18.dll!rb_longjmp(int tag=6, unsigned long mesg=44985592)  行 4035	C
 	msvcrt-ruby18.dll!rb_exc_raise(unsigned long mesg=44985592)  行 4042	C
 	msvcrt-ruby18.dll!localjump_error()  行 1582	C
 	msvcrt-ruby18.dll!rb_yield_0(unsigned long val=6, unsigned long self=0, unsigned long klass=0, int flags=0, int avalue=0)  行 4184 + 0xe	C
 	msvcrt-ruby18.dll!rb_f_loop()  行 4394 + 0xf	C
 	msvcrt-ruby18.dll!rb_call0()  行 5066 + 0xb2	C
 	msvcrt-ruby18.dll!rb_call(unsigned long klass=45132040, unsigned long recv=45126328, unsigned long mid=3937, int argc=0, const unsigned long * argv=0x00000000, int scope=1)  行 5287 + 0x28	C
 	msvcrt-ruby18.dll!rb_eval(unsigned long self=45126328, RNode * n=0x02af64f0)  行 3091 + 0xa1	C
 	msvcrt-ruby18.dll!rb_eval(unsigned long self=45126328, RNode * n=0x02af7780)  行 2796 + 0x10	C
 	msvcrt-ruby18.dll!eval_node()  行 1267 + 0xd	C
 	msvcrt-ruby18.dll!ruby_exec()  行 1436 + 0x12	C
 	msvcrt-ruby18.dll!ruby_run()  行 1457 + 0x5	C
 	ruby.exe!main()  行 52	C
 	ruby.exe!_mainCRTStartup()  + 0xe3	
 	KERNEL32.DLL!77e61af6() 	

とりあえず、安全なループを提供することを考えるところから始めればよいのかな。

_ なんちゃらの森で検索されまくり

ふと気づいたが、referrer-antibotが無効になってて、リファラで輻輳してるんじゃないか？

というか、いつのまにか Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp なんてのが遊びに来てるし。で、とりあえず@options['disp_referrer.deny_user_agents']に、'Slurp;'を追加してみる...と思ったらちゃんと入ってるな。

というか、いろいろちゃんと設定していないことに気づく。

だいたいdisp_referrer.rbをjaの下にしかコピーしていなかった。たぶんenにも入れなければenから来たロボットには効かないはずだろう。それにそれ以前の問題として有効になってないようだ。っていうか、plugin直下にも入れてないじゃん。設定メニューに出てこないはずだ。

というわけでいろいろいじる。

まだ、いじる。

_ いかん

tDiaryの設定をいじってたら日付が変わってしまった。

というわけで申し訳ありませんが、この件は、もうちょっと待ってて。というか、本当は読めてるんだろうから、どういう書き方にすればいいのかなぁ。

_ Mac OS XのX

後で調べることをメモ：

・metaキー

・日本語入力（そういえば、skkがあるはず）

・フォント

あるはずと思い出したのは良かったが、以前メモした山下さん情報のリンク先がproxyにブロックされてしまうな。

_ 無

こんだ、ずいぶん控えめになったな。

_ なんでも試しておくもんだ

tdiary-comment-cleanを単にsudoして回したせいで書き込みエラーになったり。

正解は、sudo -u nobody ruby tdiary-comment-clean ... かな。

_ rjb-0.1.6

マージしました。どうもありがとうございます。 （ちょっと変えたけど。^Mの削除とか、euc-jpとかのあたり。（追記：あと$KCODEは書き換えできるから、もし$KCODE=nilとかされた時の対応とか）

check_exceptionのフラグはその通りraiseさせるためのフラグです。あれは仮引数名が最低ですね。throwするかどうかのフラグでtだったり（誰もわかるはずない。でも、読めばif (t) { rb_raise(..); } だからわかるはず。で、その通り。やっぱり読めばわかる、と）。ただ、見てのとおりどの呼び出しでtを立てるかというのがいい加減（実際には、Javaに対するスクリプトからの明示的な呼び出しと例外になる可能性がある場合には立てて、rjbの内部処理でかつほとんどなければ立てないというような使い分けがある―――実際には仮引数名がどうとかよりも、こういったルールをコメントすべきですね）なのでソースからはわかりにくいと思います。

setup_については、おいおいまとめます。でも、ここについては特別なルールはなくて、淡々と初期化してるだけだからそんなに難しくはないです。ただ同じような処理が多いのでプリミティブ変換テーブルのように、処理手順をテーブル化するリファクタリングをかますかも知れません。

こちらではやはりボタン連打で（というより2回目くらいで確実に）落ちます。落ちるコードは以前Hikiのほうに貼っていただいたボタンのイベントでメッセージボックスをポップアップさせるプログラムです。mswin32とcygwinでsleep回りのライブラリの実装が違うんじゃないかな。このあたりは、確か拡張ライブラリの中でブロックを作ればしのげると思ったので（元々スタックポインタが全く異なるので無理はあるわけですが）、

 Rjb::loop {
   break if !w.visible
 }

というようなのと、

 Rjb::signal
 Rjb::wait

というペアで動かすJavaのモニターを使うのの2種類くらいを用意しようかな、と考えています。

J2SE1.5でのビルド、動作確認はまだ先になると思います。

_ こちらで死ぬといえば

デュアルCPUだからとても死にやすいのであった。と思いついた。

イベントハンドラを処理しているスレッドがrubyのブロック（というかフレームと言うべき）を作っているときに、メイン側がsleepから戻ってブロックを巻き戻してとかやっていれば、当然のように、jumpエラーになる。なぜならjumpバッファ内のスタックポインタなどが自分が作ったものとは異なるからだ。

回避するには、

1.メイン側にはrjbの待機関数を呼び出させて、rubyのブロックが変化しないようにし、

2.ワーカスレッド側ではコールバックの最初と最後でクリティカルセクションを作って

3.クリティカルセクション内では他のスレッドの実行を待たせる

でも、こうやると、コールバックから他のスレッドと（Rubyの中で）会話しようとするとデッドロックするから考えものだったり。

本当かな？

_ Wiki使ってる？ ―― yes!

YAMADAS現更新履歴で、yomoyomoさんが『Javaプログラミングの処方箋』に言及されている。なんとなく嬉しい。

yomoyomoさんにはまったく面識はないのだが、いつもなんとなく気にすなることをされている（身も蓋もない言い方をすればリスペクトしてるってことだ）ため、結果的にurlが参照点として出てくることがある。最初はESRがDeCSSについて書いた文章の翻訳について。で、処方箋では『日本発のwikiクローンリスト』と『日本発のwikiクローンリスト２』だ。

で、yomoyomoさんは

しかし、それら二つと並んで Wiki が名前を連ねているのを見ると感慨深く、また嬉しいのだけど、ホントかよ！？ と思ってしまうのもまた正直なところである（笑）

と書かれている。なんで「嬉しいのだけど」と言われるているかと言えば、やはり日本でのwiki普及の功労者（少なくてもご本人はそう自負されていると思うし、事実そのとおりだと思う）だからだろう。

で、まあ、その感想はそうかも知れない。ということで、なぜwikiかを書く（が、時計を見たらやばい。ちょっと尻切れになるだろう）。

SCM（CVSとか）についてはその必要性は論を待たない。

BTSになると、共有ディレクトリに置いたExcelでもいいじゃん、となってくるだろう。で、ここで「いや、BTS重要」と、代替手段ではなく正攻法でいくかどうかで、次の（本の中ではこの順番ではない。なぜなら必要度ではなく重要度で並べたからだ）wikiに対しての感じ方が変わってくるのだと思う。

いや、こういう書き方では真意は伝わらないな。

まずね、開発者は鋭敏であって欲しいと思うし、僕自身もそうでありたい。

何に鋭敏かと言えば、ソースコードの美しさもそうだが、あるもの（特に技術――コンピュータだけでなくても良い。人間が考え出して利用するもの全般で）について何がどう新しく、何がどう流行で、何が今までと違うのか、どういう思想背景があるのか……みたいなことについてだ。

で、それと同時に無闇に飛びつけば良いというわけでもなく（トレンドの先端にいく必要はないが）、しかし常に意識は必要（ファッションは考えなければならない）だ、というようなバランス感覚もあるんだけど……なんか説教くさいな……そういったもろもろのところから、実際にコラボレーションツールを使ってみるの重要（これはBTSと同様）、使ってみるのであれば自分でいじれること重要、Webに関連する技術重要、Web（とそれにまつわる種々の技術要素や背景にある考え方）に対する皮膚感覚（あ、これだ、これ）とても重要――といけば、wikiを知らないなんてことは許されないし、知ってるだけでは意味がなく、実際に開発に利用可能な以上利用するのは理の当然なのだ（というようなことを2004年に書いているところがトレンディである必要はないということだったり）。ただ、厳密には重要なのはコラボレーションツールということになるので、注釈としてノーツとか既に導入されているのならそれでももちろん良いというようになってはいるんだけど。

で、さらにどういう導入の仕方が良いのかとか、継続的に利用する（させる）にはどうすれば良いのかとか、そういうの考えるのもまた重要でしょうとか、いろいろくっついてくるのが良い点だ。

うほっ10時だ、やばい。後で付け足したりするかも。

_ MacでX

結局、SKKを考えたものの、kinput2でことえりがそのまま利用できるというのを何かで読んでEasy Packageからお気楽インストールをすることにした。やっぱ、辞書が1個で済むというのは魅力だ。しかし、./configure;sudo make installするだけで済むとは言え、楽チンなインストールを覚えるとついそれに頼ってしまうものだ（と思ったけど、ソースを読む可能性の有無も大きいかも。kinput2のソースとか読みたいと思わないし、今は）。

残りは、メタキーとフォントだ。

_ iconv.so

そう言えば、あること前提はまずいかも知れません。

というのは、mswin32で素直に（MSオンリーという意味）VC++で作れば、iconvlibなどは入っていませんからiconv.soも作られないからです。

#でも自分で作らなければ、うささんのところや、appoloや、MoonWolfさんが今作ってるヤツ、あとASRを使いそうだから入っていそうだし、そうじゃなければ自分でiconvくらい入れるかな？

だから、Iconvを間接的に呼ぶほうがiconvより良いとは思います。でも、無かった場合呼び出しスキップするようにはなってなかったかも。すみません、確かにrb_const_definedでチェックしてました。確認せずにいい加減なこと書いてごめんなさい。

>$KCODE=~/none/iならRUBY_PLATFORM見てWindowsならcp932にするんだった。

これは賛成です、現在のrubyの実装ではそれが良いと僕も思います。

_ JSFプログラミング講座

JSFとJava Studio Creator（ちょっとだけど）の本です。

最初、JSCがとんでもなくて一体どうなることかと思ったけど、最後にはそれなりに使えるようになって（メモリー増強したからってのもあるけど）どうにかなりました。どうしても、僕は先行するVisual Studioと比較してしまうから厳しくなりますな。とりあえず、Win32マシンでも1Gバイト積むことを推奨します（1台のマシンでAppServer込みで試すなら）。

実際、ベータの時点ではあまりのわけのわからなさに、るいもさんがJSFのRI読みながらガシガシ書いたりバグ報告出したりしているのを横目で見ながら、一体どうしたら良いのか（グリッドぽとぺたして単にRowSet繋いで出来ましたなんてのを書いてもしょうがないわけだし）途方に暮れたのも事実だし。というか、フレームワークのソースが付属しないのはいかがなものかと。

でも、できあがってみるとやり過ぎかと思うほどIDEは日本語化されているし（でも、クラス名とパレットの対応付けが切れるから痛し痒しのような気も）、いきなりフリーズするようなことは無いし、安いし、イントラ用ビジネスシステムを作りこんでいくためのツールとしては（デザイナとの分業体制を取るにはあまり向かないような）、それなりに良いのではないでしょうか。

JSFの入門書（学習書という位置付けですね）としては、るいもさんの説明がていねい(文章だけではなく、RIに逐次あたりながら動作を検証して書いていたからというのもあるけどそれは普通の読者には見えない――でも読む人が読めばわかるはず)なので良いのではないでしょうか。僕にはわかりやすかったです。

JSCについては（EoDだから）入門するも何もないので、使い方と付き合い方について、前者は淡々と後者は2004年という現在の時制を意識した上での主観を交えて、書いてます。

_ Seaserのからさわぎ

参加希望。よろしいでしょうか？

僕の感触だけど、わりと聞いた話としてでもあるけど（というのは、実際にそういったことを経験したわけではないからだけど）、たとえばソフトウェアを多層化しますとか、UIとビジネスロジックを切り離しますとか、サービスとして（サブシステムをインターフェイス境界の内側に隠蔽して）実装しますとか、の戦略についてはだいたい話せばわかってもらえるけれども、そこから先につながらない（ビジネス＝契約の話じゃないよ）ことが多くて、「なるほど理解しました。で、それでどうやって実装設計するんですか？」となることが多いそうだ。戦術なき戦略ですか？ （ここでの戦略はシステム構築という狭いスコープだけど）

で、ひがさんたちがすごいところは、最近のJ2EEの設計思想（＝上で書いた戦略に相当）＋Seasar2というツールというありがちな組み合わせ（っていうか、思想＋ツールというのはOSS的には普通のことではあるけど。使い方はおまいらの自由にどうぞということで、それはそれで良いのだが、この場合はOSSといってもRubyやEmacsとは対象となるユーザー層が違うというか戦場が違いますなということになるのだが）で終らせずに、戦術に相当するものを『くーす』（しかし、これどういう意味なんだろう？）という設計手法（ユースケースから実装設計への落とし込み方法と言えばわかりやすいかな）としてパッケージ化している点にあるんじゃなかろうか。いや、実に具体的というかクソリアリズムというか、絶対こういうのも世の中に必要だよね。

というわけで、見逃せないイベントです。

_ 新宿と表参道

広告主に喜ばれるのは、ただ人がたくさん集まっているサイトではなく、特定の層の人が確実に集まるサイト。

しかし、その特定の層の客単価はとってもとっても低いという罠。

（あ、青山通りより南側ってことか。それなら納得がいく。でもエキサイトってごちゃごちゃしてるからキディランドあたりとか、オリエンタルバザーとかのあたりのような気が）

っていうか、新宿と表参道というのは比較対象としてはあまりに非対称な設定だ。新宿通りと表参道とか、靖国通りと表参道とか、甲州街道と表参道とか、かな。甲州街道パラダイス。

どういうイメージのもとにこう発言したんだろうか？

_ back to 2000 era

調べものをしてたら、こんなの発見。

Visual Basic Developer 2000, July 2000 ― xTrem Programming。

出てすぐだな。

_ 読まないし買わないとは思うがメモ

プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集(PLoPD Editors)

_ とりあえずこっちは読むつもりメモ

インテグレーションパターン。via まさよしくん。

_ わかんねー（MIME vs IMT）

MIMEとInternet Media Type(IMT)の違いがわからないよ。

IMTって誰かの気の迷いか、MIME未登録のメディアタイプを記述する必要性からひねくり出したインチキ言葉なんじゃないか？

大体同じ、とか、HTTP用に最適化とか、いろんなのが見つかるけど、IANA（追記：IANA=MIME、IETF=IMTとか？）はどう定義してんだろう？ これが探してもわからない。

どなたか、ポインタを教えていただけませんか？

_ ますますわからん

RFC1590では

The Multimedia Internet Message Extensions (MIME) protocol [1]

なんてMIMEのことを書いてるが、参照している[1]は

[1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.

で、違うというかなんというかMIMEの構成語が違うのだが。っていうかRFC1521のMIMEが普通MIMEだと思うんだけど。

_ PowerBookとiBook

感想。PowerBookのほうが道具的だ。つまり多少汚れてもあまり気にならない（液晶は別）。ところがiBookのほうは、とても外部の汚れが気になる。閑が本当にあればハーと息をかけてしょっちゅう不織布で磨きたくなるような感じだ。肌触りもiBookのほうが好きだ。PowerBookは偏愛の対象にはならないが、iBookのほうには偏愛したくなる何かがあるみたいだ。

この感覚がある程度まで普遍的なものなら（なんか、白いものに弱みがあるかも知れないのでまったく自信はない）、入門機（値段が安いから取り合えず使ってみるかと思わせる機種）としてのiBookというのはすごくデキが良いと感じる。

_ 信者ではない

「マイクロソフト製品利用者の多くは、熱狂的にマイクロソフトやその製品を崇拝したり心酔したりしないので、そもそもマイクロソフト「信者」なる人種はほとんど存在しないだろう」

まあ、そうだな。っていうか、崇拝とか心酔ってのは、モノに対して行うことはあまりなく思想とか信条とかに対して行うもんだろうからな。と言う訳で読み始めた。

それにしても、誤解を招くようなことを平然と書いているのか、それとも本当に知らないのかどっちなんだろう。

論旨からLinusがMinixではご自慢の386マシンを生かせないからLinuxを作ったと書くよりは、時代が386を使うためにUnixを使いたい（Linusがそう考えたとは書いていないからわかっているんだろうが）という背景にすべきなのはわかるが、それもちょっと違うような気もしないでもない。別にUnixでなくても、TCP/IPプロトコルスタックを持って、POSIX互換のlibcがあればそれで良かったんじゃないか、っていうか、LinuxもMinixもUnixじゃないし。だからカーネルとlibcで、後は使えるからGNUを持ってきたというような感じだろうな。

っていうか、ポータブルC。

世界で一番移植性が高いプログラムは、K&Rの

#include 
main(argc, argv)
  int argc;
  char** argv;
{
    printf("hello world\n");
    return 0;  /* 最近は書かなければ怒るんだろうか? */
}

なわけだし。（ANSI Cですらまだ多少微妙だしC99も全然だな）

GUIがからんでくると話がややこしくなってくるんだろうけど。

ポータブルCから、Win32APIのライブラリを用意すれば良いということでWINEとかあったわけだが。『完全な互換』ってなんだろう？ そんなものはXPとXP SP2の間にすら『完全』には存在しないのだから、動くってことだけなんじゃないだろうか。

ああ、書いていてわかったが、Win32APIと違ってCLRは仕様を標準化しているからその気になればより互換度を上げられるということか。

まあ、Monoの人はもともとBonobo（Gnome自身がそうだともいえると思うが）な人だし。ここまで読んだら面倒になったので読むのやめた。

_ 紀ノ国屋

白いカラスの口型のマスクを着けて黒い服着た若い男が手にしたスーパーのカゴみたいなのにマンガを買いあさってた。でも、人形をぶらさげてるわけじゃない。

_ Webアプリケーション境界とセキュリティ境界

1個のでっかなWARとするのは、webアプリケーションが論理的に複数のサブシステムに分割できる場合、あまりうまい方法とは思えない。

複数のWARで管理すれば、サブシステム単位の独立性が上がるから、たとえば1部のバージョンアップなんかが全体に与える影響を抑制できるからだ。

でも、このwebサーバーが業務システムサーバーだと、今度はセキュリティ境界の設定が難しくなる。特にセッション情報に依存させる場合だ。

具体的には、webサーバー全体をカバーする仕組みとしてはBasic認証とかあるけれど、3種類のロール、5000人の（しかも頻繁に移動があり得る）ユーザーというような場合には、既存のアクセス管理の仕組みを利用したくないからだ。

#とは言うもののJDBCレルム使って、ユーザー登録時にテーブルを同時にメンテする仕組みを作ればいいような気もする。

いずれにしても、Webアプリケーションのコンテキストをまたがるセッション情報の引き継ぎはできないから、/をレルムとするBasic認証以外ではコンテキストをまたがった時点で以前の情報は失われてしまう(はず)。

しかしBasic認証であれば、セッション情報は消えてもレルムが/である限り、ブラウザーがAuthentication:フィールドを送ってくるからHttpservletRequest#getUserPrincipalでユーザー名が取得できる（はず）。ーDigest認証でも同様（のはず）。

ところが、望まれているのはユーザーアプリケーションによるビジネスルールに基づく認証（たとえば、社員コードの範囲チェックによるロールの割当など）だとする。

この場合、クッキーの読み取り範囲を/とすれば実現できなくはない。SSLセッションっていうのは、ログインしたHTTPSの範囲内でUserPrincipalを保持するんだろうか？ ならば、これも大丈夫だ。だが、クッキーを利用しない前提ならどうすれば良いのだろう？

ビジネスルールを生かそうとして、かえって問題が生じて面倒な回避策を考えなければならない例にはなってないだろうか？ セッションのチェックをRequesetProcessorかFilterで一元化して実行すれば、昇格は防御できるだろう（この場合も昇格で良いのかな？）。その場合の手数は、user/roll表の作成/管理よりも少ないか？ （管理は無限に続くが、開発は1回かも知れない）

_ ロン先生のこと好きだったんだ

ロン先生の虫眼鏡 (2) (秋田文庫)(光瀬 竜)

ロン先生の虫眼鏡 (3) (秋田文庫)(光瀬 竜)

くまのニュースを見てたら、子供が「悪いのは人間だよ」とか、3巻の最後から2番目のエピソードから得た知識を振りかざしていたのが一昨日のことだ。

SFマガジンの上質紙の連載の時から読んでたし、チャンピオンに連載中も読んでた。で、今は子供に読ませている。ちょっと古びたものもあるように思えるけど、今でも読めるな。

しかし、1番印象に残っているのは小学生の頃読んだエスパーもの（ジュヴィナイルだろうな）で、最後にテレポーテーションすると裸になるっていうやつだったり。

_ 不便になったな

月刊MSアップデートをかけたら、リンク（アンカータグ）のドラッグアンドドロップが利かなくなった。

_ コオロギ

なぜか家の中でコロコロ声がするんだが、どこから入ったんだろう？

_ いやな感じにたまってきたぞ

社会という名の学校で久々に勉強をずっとしている関係で、脳内知財は消費する一方だ。rjbを作ったおかげでJNIの知識を補充したけどこれは消費不可能だから（そうでもないかな）あまり関係ないし。

買った本も、森脇真末味はすぐ読んでしまったし（天使とかはまだだ）、w/o EJBは軽く眺めたからいいとしても、RtPはあまぞんさんから出しただけ状態、J2SE 1.5はダウンロードしかしてない状態、Squeakは（子供もなんだかんだと秋は忙しいし）止まってるし、そんな状態にもかかわらず、また1冊届いてしまったよ。でもなんとなく序文を読んでしまったら滅法おもしろいじゃないか（あさましするときは、多少の要約をつけるときにしてヒットポイントを狙ってみる）。

というわけで、来週からはこいつを読もうと決めるのだが、持ち運びは重くてできないんだな、これが。（箸より重いものを持つことはPowerBook15"くらいしかないし）。

_ がーそ

先を越されてるし。っていうか、そういう問題じゃないけど。

_ 今、家が揺れている

3:57くらい。

_ 22

こんだ、うまいな。

_ WHY?

高木さんのところ経由で、聞き手が無能というのを読む。

WHYを問い掛けると背景事情から全部話す気にはならず一般論に陥るからWHYそのものを聞かずに、具体的に「こと」を取り出してWHATとして訊けということなのかな、と首肯した。

_ お前の心の中の硬い骨

スタイルカウンシルがiPodの中から流れてきた。

一緒になって、solid bones in your heartと歌ってみたが、何か違うような気がする。

がーそ。お前の心の中に固い絆を築きたいなのか。

スタイルカウンシルは基本的にはポールウェーラーとミックタルボの2人組のバンドだ。ポールウェーラーはジャムのギタリストでボーカル、タルボ（とフランス語風にカタカナ化するのが正しいのかタルボットとシェークスピア風にするのが良いのかわからないけど）はキュアの愛すべきラブキャットなんかに貢献したキーボード奏者だ。かたっぽはモッズスタイルのパンクバンドだし、かたっぽはサイケデリックなニューウェーブバンドだからどうしてこんなコンビになるのが不思議だった。それだけに出てくる音楽もいろいろだったが、一貫してポールウェーラーの声に魅力があったし、ところどころとてつもなく美しいフレーズが出てくるのでしょちゅう聞くわけではなくても時々は思い出すことはある。

元々僕は、ジャムには全く興味はなかったし、当然ベスパにもダッフルコートにも縁はなかったのだが、ある日レコード屋で、インザシティを耳にしてからとてつもなく好きになった。

インザシティは僕にとって泣ける曲のナンバー1だ。たった2分ちょっとでバタバタと演奏するだけなんだが、かっこ良さという点で圧倒的なだけでなく、これだけは言っておきたいんだというような性急さ、ところどころに出てくるきれいなフレーズが圧倒的だ。

ジャムといえば、リトルダンサーで悪意という名の街が非常に印象的な使われ方をしていた。炭鉱ストか何かで警官隊が動員されてちょっとした暴動になるシーンとオーバーラップしてトイレか何かで踊り出して壁を蹴ったりするんじゃなかったっけな。

リトルダンサーってのも妙な映画だ。冷静に考えればスランの安部ひろしほどじゃないけど、とんでもなく自分勝手で端迷惑な小僧が主人公なのだが、なぜか回りの連中がこいつを一生懸命サポートしてやるという話だ(まあ、こちらは父親だから身につまされるってのはあるんだが、ヒットしたってことは見てる連中はみんなこの我儘な小僧をサポートしてやりたくなるってことなんだろう)。なぜかといえば、この小僧が心の底から踊りが好きだというその1点になるわけで、特別な人をとにかくサポートするという風習ってこういうことなんだろうか？ でも、炭鉱の町ってイメージからはジャムというよりは、シャム69とかみたいにもっと乱暴な感じのとか、UB40みたいなのが似合いそうなんだけど、リズムの良さ（すごく歯切れが良いのだ）ということを考えるとやっぱりジャムなのかな。

_ マイクロソフトの呪い

これは便利ですなぁ、とTechEDでありがたくもらって、しばらくして。（というところで句点を打つスタイルってニールヤング風だな）

仕事場でLANケーブルが無いことに気付いたが、そういや持ってたな、とあわてずさわがずTechEDバッグから取り出してPowerBookとLANの口につないだのであった。ちなみに両側から引っ張るという手順が最初わからず戸惑ったのはまあいいとして。

ところが、おかしい。

さくさく動いたかと思うと、次の瞬間には固まる（ってのはXの話）。

？？？？

でも、しばらくすると動き出すわけだし。しばらくそんな状態で我慢して使ってた。しかし、半日くらい使っててさすがにむかついた。

って言うか、なんでおれがネットワークの不調を前に黙ってas is君してなきゃならんのだ。

で、まあ、ifconfigしてみる。と、

media: autoselect (100baseTX ) status: inactive

なぜ、inactiveなのだ？

変だなぁ、といろいろ試してみるって言っても試せることなんてたかが知れてる。最初疑ったのは、会社のLANにMac(ポリシー的にはよろしく無かったり)を繋いだから殺されたのかな、とか（でもinactiveってのは違うよね、よく考えなくても――ただ、会社のネットワークSSによる粛清の話は聞くし、それなりに後ろめたさが無いわけでも無くも無くも無いし）。(追記：要するにDHCPサーバーはとりあえずリクエストに対してIPアドレスやデフォルトルータをふってくれるけれど、しばらくして気付かれてリリースされてしまう――ってできるかどうか知らないんだけど――ってのでギッタンバッタンしてるのかと推測してみたんだったり）

でもしばらくすると、動いてる。で、ifconfigすると、

media: autoselect (100baseTX ) status: active

で、なんとなくわかって、man ifconfigして調べてから

sudo ifconfig en0 media 10baseT/UTP

で、もう一度ifconfig

media: 10baseT/UTP <half-duplex> status: active

で、その後は順調。Xでemacs使ってる分には10も100も誤差みたいなもんだし。

結論：CAT5かどうかは、とっても重要。

_ 10/23が近いが天気は悪い

特別公開MITAKA。 去年はWebページは見なかったから台長に感心したが、こんだ、「来台」にちょっと感心した。千客来台。

_ 165

OpenSSLか。入れるとhttpsな通信ができるというわけね。

入れようかな。そのうち……って言うかVRubyも更新されてるし。でも、本人が1.8.2が出たらでいいんじゃないかと思ってるからな。

_ パッケージ

なんでおれは、こんなことをあんな時期に書いたんだろう？ 読み返してみるとばかばかしく正しいな。

っていうか、暮さんヒットから2ヶ月か。

_ 敗者

歯医者に行く時点でそう変換されてしまうものなのだろうか。

_ 目医者

ま、これはそれしか無さそうだ。

_ X医者

歯と目以外に、患部＋医者ってのは無いのかな？ 耳医者とは言わないし、産婦人科医を女医者とは言わないというかそれは女医さんの意味になりそうだし。

_ 会議脳の恐怖

他にも野球中継脳とか通勤ラッシュ脳とか、その影響力を駆使して欲しいもの多数あり。

通勤ラッシュ脳ってのは、3分以上、通勤電車（1平米あたりに3人以上の人間が押し込まれて振動を与えられている状態）では（というところでカッコが出てくるのはゲーム脳を読んでないから、どういうネガティブなことが書かれることになるか知らないからだが）……ということで、日本人は創造性がないとか、日本人はxxxがないとか（いろいろな俗説を当てはめよう）だからどうしたこうしたというどうでも良い研究をやって、NHKから本を出して、みんなが読んで、「おー、そうか、だからだめなんですなぁ」という機運が盛り上がる。新聞の投書欄に「会社役員52歳」氏とかの「最近の」（ってこたないだろ、まあ、もちつけ）「社員がくそで、ワタシが若い頃のように馬車馬のように働かない原因がわかりました。これからは通勤は控えようと決心しますた」とかが掲載されたり。

で、当然、通勤電車というのはだめなわけだから、企業活動のためにますます社会インフラとしてネットワークが発達して分散技術の研究が盛んになるか、あるいは中曽根構想（環7の内側は私有地を没収して高層ビル化）で時間都市みたいのを出現させるとかして、妙な世の中になる。

やっぱり、こういう世の中のためになることを研究して欲しいな。どうせ意味ないんだから。

で、この研究の存在をいち早くキャッチしたJRは、通勤電車で稼いだ金をネットワーク屋としてのインフラ投資に回してるとか。

#追記：しかし世の中はそう甘くもうまくもない。無振動車が開発されて無事解決してしまうのであった。

_ ソフトウェアベルトコンベア

ソフトウェアベルトコンベアシステムには、3種類のビューがある。

1.作業者のビュー（モダンタイムスのチャップリンである）

2.ベルトコンベアコントローラのビュー

3.製品のビュー

1.は、個々のプログラム。

2.は、フレームワーク（とかワークフローエンジンとか）

3.は、トランザクションデータ

ソフトウェアベルトコンベアモデルでは、仮にOOPを利用して実装したとしても真のインスタンスはトランザクションデータだけである。（もちろん、作業者を適正配備するにはベルトコンベアコントローラから見てストラテジとして実装されているほうが良かったり、集団教育みたいなもんで実装継承したりするほうが良かったりするから、実装にはOOPの恩恵は受けられる）

さて、そこでの問題は、

・ベルトコンベアは現在も優れた工業品製造のモデルなのか？

（1人が箱を抱えて最初から最後までやる方法とかってどうなったのかな）

・伝票処理ってのは、ベルトコンベアモデルと相性が良さそうだが、それは現状のプロセスが単に電子化されたこと以外にどのようなメリットがあるのか？（妥当性検証が必ず実行されるとか、いろいろあることはあるかも）

・昔ながらのベルトコンベアって1回組んじゃうと変化に弱いとかなかったっけ？ （そこをどうするかってことを考えとかないと）

_ この記事信頼できないな

「危機に瀕するJ2EE」――市場調査会社がレポート いや、主旨はそのとおりだろうな、とは思うが

SunやIBM、BEAなどのベンダーがMicrosoftの.NETフレームワークに代わる有望な選択肢として同規格を推進しているからだ。

まだ生まれかけのものに「代わる」もなにもないだろう。逆の書き方ならわかるが。 しかも、JBossを使おうがGeronimo使おうが、それはJ2EEなんだが。だったら「危機に瀕するJ2EEプロバイダー（ベンダーかな？）」なわけだし（しかも、これについては煽りですな、という感じだし）。

Spring、Hibernateあるいはサーブレットなどの勢力拡大にもうろたえてはならないという。同氏によると、これらの異種プレーヤー……

無茶苦茶だ。「サーブレット」（まあ、カタカナで別扱いにしているとも言えるが）が「異種プレーヤー」なのですか……

次に登場する「J2EE 5.0」リリース

2004/10/18の記事のようだが。もう登場している（過去）よ。誤読かつ誤爆でした。 結局、J2EEというのは、ActiveXみたいなもので、実際の仕様などとは無関係なマーケティング用語として利用されているということで良いのかな。（まあ、そりゃそうでもあるんだが、だがそれを首肯してしまうと「J2EE1.3仕様までを利用して、J2EE1.4仕様の利用は今回見送り」みたいな技術的決断が無効化されかねない）。 で、意味としては、J2EEというのは「J2EE仕様（1.3あたり）を完全に（EJB含めて）満たした商用アプリケーションサーバー製品」ということだということか。

_ もしかして

ちょっとバカ往く読んで興味をもって、グーグルしたら

もしかして: 愚痴 しかも自分の感情の生理をつけるための汚ならしい文章

非常に興味深い結果が得られたのでメモ。

_ プロクシとの通信料金

一度必ずキャッシュを送ってくれるんだが、この通信分も課金対象なのかな？

結局再読み込みする事になるんだが。

_ ステートレスコンポーネント

注）なんとなく書き始めてみたが精査できてないから結構怪しいとこがあるけど、仕上げる気力がないからこのままだったり。

あるコンポーネント(分離度が高く、他のプログラムから呼び出されることを前提としたプログラム)がステートレスであるとはどういう文脈で使われるかによってもちろん異なるのだが、暗黙の了解としては主となる公開メソッドの後続の呼び出しが以前の呼び出しに依存しないということだ。

当然、主とならない、たとえば依存性解消のためのセッタ呼び出しであるとかライフサイクルを通じて一度実行されるinitializeとかコンストラクタとかに、主となるメソッドの呼び出しは依存してもそれは構わない（それは不変条件あるいはクライアント側が実行する準備処理という意味においては事前条件である。っていうか、こういう場合の不変条件と事前条件の区別って良くわからないんだけど）。また、主となるメソッドの内部で状態遷移があるのも当然（JDBCでいけばConnectionからPreparedStatementを取得した状態、executeQueryを投げた状態、ResultSetをcloseした状態、の種々の状態がある）だ。

もともと（といっても僕に取っては1997年頃からの知識になるわけでそれ以前から別の文脈で使われているかも知れないのだが）、あるコンポーネントがステートレスかステートフルか、というのはスケーラビリティに関する議論であった。ステートフルであれば、あるコンポーネントのインスタンスは1つのクライアントに密結合されることになる（なぜなら、状態を保持したまま複数の呼び出しで処理が完結するから）。1000クライアントが存在すれば1000のインスタンスが必要となる。いっぽうステートレスであれば、コンポーネントのインスタンスプール（フライウェイトですね）が使えるし（最大で必要となるのは同時に実行されるスレッド数）、ましてスレッドに従属しなければ（通常のServletを想像すればよい）1インスタンスで同時に複数のクライアントにサービスを提供することができる。

ちなみに2年位前には、最後のServlet型が最高だと考えていたが、実際にいろいろ動かしてみたらコンポーネントのインスタンスの生成/廃棄のオーバーヘッドはもっと細かな（文字列みたいな）オブジェクトの生成/廃棄の影に隠れて誤差みたいなもんだとわかってきた。したがってインスタンス変数は使っても良いな、と考えが変わって来た（スレッドあたり1インスタンス）。でも、初期化処理のオーバーヘッドまで考えた場合、およびインスタンス管理の複雑度を考えると、ステートフルなのはちょいと考えものである（というか、インスタンス管理を考えるくらいならEJBコンテナを使えばよろしいと思う）。また、ステートフルな実装はある意味、設計が複雑になりやすい（ここは興味深い。「ある意味」以外の場合があるからだ）。

で、ステートフルにするメリットとステートレスにするメリットの差は一体なんでしょう？ と考えると、それはメソッド呼び出しのコンテキストの量に依存するということだ。

たとえば、ある状態を持った処理――誤解を招く可能性はあるが、マスターレコード読んで表示用データを返送、変更内容を受け取って更新の2つの状態を持つWebページを考えてみる――では、機能的にはステートは最初に読み込んだマスターレコードのキー（楽観ロックが必要であればさらに更新バージョンを示す情報も必要）である。非機能的にはログイン情報、クライアントのアドレス、セッション状態などなどがあるのだが、それをWebサーバーが提供すると前提できるのであれば、そのWebページにとってはレコードのキーだけが（楽観ロックの場合は……省略）呼び出すメソッド間で保持すべきステートとなる。

この情報をWebページが呼び出すコンポーネントが保持すれば2度目の呼び出しすなわち更新メソッドの呼び出し時にクライアントはキーをWebページへ送信する必要はない。しかし、そのために1つのインスタンスをクライアントに従属させるメリットってある？ というのがステートレスなコンポーネントの考え方である。しかし保持すべきコンテキスト情報が500Kバイトあれば、クライアントとサーバーで転送を繰り返すよりはサーバー側で保持したほうが良さそうに感じてくるはずだ。しかし、それが1000クライアントとなるとサーバー側は500Mバイトのステートフルコンポーネントのインスタンス群を同時に抱えることになる（大したことないな、こう書いてしまうと。でも処理は1種類のはずはないから合計すると非現実的なサイズになるわけだ。そこに、EJBがステートフルとステートレスの2種類のセッションビーンを規定し、かつステートフルの場合状態を保持したまま非アクティブ化したりする処理をEJBコンテナが提供するメリットが生じる）。

ちなみにスマートクライアントではセッションコンテキストをクライアント側が保持することが原則となる。

では、呼び出しの間に保持すべきステートが少ないかあるいはほとんど存在しない場合にはコンポーネントはどうあるべきか？ そのように設計できるのであればステートフルにする必要性はあるのだろうか？ ――無い。

って言うか、ステートレス/ステートフルの考え方についてEJB仕様は、実務に耐え得るか/実装に必要かはおいておいても非常にうまくまとまっているんだから読んでおいて損はない。って言うか、J2EEプログラミング講座もよろしく。

ASP(VB5)時代の文献――「ステートレスな (状態を持たない) コンポーネントを設計します」（しかし、最終更新日2003年とかってその通りなんだろうがミスリードしやすい表示だな）。

ちなみにひがさんのくーすでのステートレスの意味は上の分類ではServletタイプのようだ。想定している処理の粒度が違うのかも。

以下は個人的な感触。

もしステートを持たずpublicメソッドのみを提供するのであれば、そのクラスの実装は本当に構造化プログラミングだけで済むかどうかといえば処理の粒度に依存するということとなる。個人的には比較的粗粒度とし1つのコンポーネントが3〜4くらいのクラスによって実装されるくらいがバランスが良さそうに感じるのだが、処理内容に依存するから実際にはケースバイケースではないかと思う。また、徹底的に詳細まで仕様を落としていけば単一のプログラムになるからそれはそれでありかなとも思わないでもない。

_ Graffle

失敗だったかも。

追記：

GraffleProfessional3.0を購入。

理由：Visioとの移入／移出。

失敗と思う理由：VisioからUMLを移入。編集。移出。それをVisioで読み込むと図形は認識するがUMLとは認識しなくなる。その結果、Visio側でステンシルを貼ろうとすると「このステンシルはUML用です（というようなメッセージ。不正確）」となるため、編集できなくなる。

ちなみに、Visio2002での結果。

もちょっと追試するけど、それなりのダメージではある。

追試してみた：家のVisio2002SR-1では問題なく貼れるな。会社のVisio2002もSR-1にして試してみよう。というわけで上の記述は誤爆度90%以上。

_ POAD

買うだけなら金さえあれば(無いけど)できるわけで、こんだ、こんなの買ってみた。

序文を読んでみたらこんな感じだ。

ソフトウェアをこさえるのに1番大変なのはコーディングじゃなくてデザインだよ。デザインに失敗したらとんでもないのができちゃうよね。一生懸命コード書いてもさ。そんなの出荷して泣きを見るのは誰でも経験してるよね。でも、どうすりゃ実装する前にそのデザインが良いデザインだって判断できるんだろう？

まあ、そうですね、ということだ。

で、デザインパターンということになるのだが、この本はカタログとして個々のデザインパターンを云々するのではなく(2004年の本だから当たり前かも)、システマチックに（っていうことは方法論としてということと同義かな）デザインパターンを実際の開発に適用する方法を考えるって内容だ。

確かに、出来上がった後にあの設計はくそでした、すまんかったってことはあるし、設計の再利用ということはここ数年いろいろ思い当たる節が多いので主張は良さそうだ。

キーワードは、Composition of Design Patterns なんだろう。コンポジションパターンではなく、デザインパターンの組み合わせをソフトウェア部品（部品といえるのは再利用の単位だからだ）として開発に利用するということになるんだと思う。

ますます、2バイ4みたいな開発になるのかな。

POADのアプローチは、第7章から持ってくると

・パターン駆動

・コンポーネントベース開発

・アーキテクチュラル開発（なんかわけわからん言葉だが、機能より構造重視ということで良いのかな。デザインを再利用するってことは、個々のソフトウェアが提供する機能――が必要なのは当然だが――によって開発を駆動しないということになるんだろうか？ ユースケース駆動の正逆のような。誤読してる可能性が強いな、このあたりは）

・ライブラリ駆動開発

――コンポーネント駆動があるのに、なんで？ と思ったらデザインパターンのライブラリと書いてあるが、コード片という感じになるのかな（メソッドオブジェクト？）。っていうか、英語を書いとくと日本語訳が出てこないかな

POAD uses existing catalogues of design patterns. The approach heavily relies on the existence of reusable libraries of design patterns that can be browsed and queried. Therefore many of the traditional reuse library issues concerning asset retrieval still hold for pattern libraries. ...

・デザイン再利用

・階層的開発(Hierarchical Development)

――全体―部分という抽象化の階層（ってなんのことやらわからないが、読むとわかる――僕が形式知化できてないということだ）

・繰り返し開発

という性格を持つということだ。

で、この本は実際には実装の本なのだな。末尾がADだけど業務分析という意味での分析ではなく、実際にあてはめれば要件定義が完了してソフトウェアの機能（ユースケースということになるのだと思う）が明らかになった時点（といっても要件は変わるものであるが）で、ではどのようなソフトウェアになるかの分析、設計、実装……（と書いて、自分がこのフェーズでの分析というのはこれまで意識してなかったことがわかったり）、分析というのはどのようなパターンから構成されているかを考えるということのようだ。設計は設計。実装は実装。

では、この本の対象読者はどのような開発者なのだろうか？

序文には7種類の読者像が並べてある。

・ソフトウェアアーキテクトとデザイナー。フレームワーク作ったりするならますますそうだろう。

・Practitionersと書いてあるが手元の辞書の意味とは違いそうだ。ソフトウェアを作るためのパターンカタロウグの学習とかしている学習者という感じかな？

・アプリケーション開発者。コード書くときにデザインパターンの適用を考えるんじゃなく設計時に考えることで得するんじゃないかと考えてるような。っていうか、設計と実装は同じことなので大抵はこうなるような。

・研究者。元ネタになるぞと、なんか著者は自身満々であるな。

・デザインパターンを教えるプロフェッサーやレクチャー（教授や講師？）

・再利用マネージャ。なんか苦し紛れで7つにしたような感じだが。

コードサンプルはJava。Emacsをデフォルトの設定で使ってしかも失敗したような妙なインデントになってるし、フィールド名が大文字で始まってたり小文字で始まってたりするが、それほど気になるわけではない。（ということは、コーディング規約なんてほとんど意味ないということの証左でもある）

後ろのほうはUMLと仕様と称してOCLの解説とか。

340ページ程度とそんなに厚くないし、図版（UMLだけど）も結構使ってて、割と読みやすい。GoFを読むより応用問題になってるだけに面白いかも。目を通した範囲では、僕は結構面白いと思う。難を言えば形式化しているだけで、誰でも考えているようなことではないかという気もするが、あらためて文章化されているのを読むとそれはそれで勉強になる。なっているようだ(読む気になって、まさに読んでいるわけだから)。

ちなみに、直接Amazonから買うより約900円安いからuk books……というところ（マーケットプレイスに出てくる）から買ったら、10/10クリック、10/16 uk books...からメールで発送案内、10/25 到着と2週間かかった。どうもこのuk booksというのは遅いことで知られているようだ（評価を見ると遅いというのが結構見える）。ま、いいや。

_ build.xml

最初が面倒だな。

と言うことで、xcodeをいじってみたらbuild.xmlを吐き出すプロジェクトを見つけたのでちょっと利用してみたり。

#かくしてMavenを試す機会をまた失った。

_ ビジネススクリプト

ある仕様書見ていたら命名規約としてパッケージにxxx.xxx.blというのがでてきてうんざりした。blといったってボリシェビキレーニンの略じゃないこたすぐわかる。ビジネスロジックか。

ビジネスメソッドってのもあるけど。

こういう解釈が広いわりにはまったく直観的ではない言葉って曖昧でいやだな。

で、意味的には大抵の場合、入力パラメータをちょめちょめしてDAOを呼び出すようなプログラムのことだったり。

大体、ロジックってのは論理だ。

レトリックス アンド ロジックス、さっぱりわからないよ。パロールパロールパロール。ロゴスロゴスロゴス。

はヒカシューだけど。ちなみに、最初聞いたとき、パロールはもちろん知ってたけど、ぱおーぱおーぱおーってこまわり君の象を引用しているのかと思ったのは秘密だって言うか、今、ロゴスロゴスロゴスと書いていて初めてパロールじゃん、と気付いたのだが、それにしてもこのへんの言葉（こまわり君だのヒカシューだの）って、もう日本人の半数は知らないだろうなぁ。って言うかこまわり君はともかくヒカシューはもともと1/1000くらいしか知らないか。

ノンマカブルインタラプトおしまい。マカブルってのはリストなんかの舞踏曲に関連する言葉だ。本当はマスカブル。最初にNMIの説明を見たMSXの本がマカブルと誤植していたもんで、ほほー、それは恐ろしいインタラプトですね、と刷り込まれていつも間違えるのであった。ミルマスカラス。

そういうのって、ビジネススクリプトって呼ぶほうが良かないかな。

ビジネス処理なんだからビジネスが接頭されるのは良さそうだ。でも記述されている内容はどこでどれをどうするみたいなことなんだからロジックというよりはスクリプトだろう。

でもパッケージ名bsってのはわけわからないことに変わりないから、命名規約は勘弁しとくことにして、使う言葉だけビジネスロジックからビジネススクリプトに交換してみたり。

追記：引用したんだから、はっとくか。ディスク1の4曲目：レトリックス＆ロジックスだ。

20世紀の終わりに恋をするなら……

_ 私の仕事でございます

と言われても、ああそうとか頑張ってくださいとしか言えない時代があったわけだと考えると21世紀の日本は捨てたものじゃない可能性はあるのかな、とメモ。

_ メッセージングの3番目

ポイントツーポイント（ツーってやだね）とパブリッシュ/サブスクライブの2つのパターンが代表的というか、その2つしか知らないのだが、なにやら第3の道を考えなければならないらしい気がするようなしないような。

購読手続きをちゃんと考えれば済むのかどうか。

最低の方法としてポーリングってのもあるけど（サブスクライバーが店先に入荷したかしょっちゅう見にくるやつ）、それは見に来るのを忘れたやつが出てきたら相当困るから、忘れているなら忘れているで教えてやらなきゃならないだろうし、であればパブリッシュで良いじゃんとか。それにポーリングって無意味な負荷のような気がするし。無駄足ってのは嫌いだ。

と、メモしておこう。

_ 昨日の昼飯時の会話

妙な顔してスピーカーのほうに耳を向けているのに気付いた。

「ん？ この音楽がどうした？」

「なんですか、この変なの？」

「え、セルジュゲンズブールじゃん……じゃなかった、ピエールバルーだよ。」（最初、Je t'aimeに引っ張られてmoi non plusのほうからゲンズブールを引っ張って来た。しかしすぐに、カラスの死骸をトラックのフロントガラスにへばり着かせたまま旅を続ける男のドライブインでのショートカットの少年のような女との出会いの物語ではないほう――しかし、この映画ほど観客をコバカにして、しかも美しく、しかもまぎれもなく映画で、しかも不愉快になるものはないかも知れない――だと――砂漠の映像が浮かんで来たので――気付き言い直したが、結局これも間違いと後で知った）

「ほげ？」

「クロードシャブロル……じゃなかった、ジャンクロードユスタシュのはずありえないし、クロード、クロード、クロードチアリのはずなくて、クロード……なんだっけ？」

「知りますか」

「ルルーシュだ。クロードルルーシュの男と女の主題歌じゃん」

「氏等ねー」

「えっ？ マジか？」（と本気で驚いた）「って、オレも映画は退屈だから途中で見るのやめたが、シャバダバダを知らない？」

「氏等ねー」

「ピエールバルーを知らない？ （これは、間違い。実際はフランシスレイのほう）」

「氏等ねー」

「うーん、僕も男と女の頃は知らないけど、ちょうどYMOの高橋ユキヒロなんかと……（と過去の話が入ってサラヴァとかいろいろ）」

「ってか、オレ、YMOって知らないもん」

「えー、マジっすか？ ……ちょっと待てよ。キリンのLive(なぜか、YMOというとこっちを考えてしまうのは印象の強さの問題)がオレが17か18の頃だから（と逆算してる）……、あ、そうか、お前、生まれる前だわ。ガハハ、こりゃ失礼」

あー、完全にじじいだわ。

_ 僕の小さな恋人たち 買い

で、本当にピエールバルーか気になって調べているうちに、ジャンクロードユスタシュって変じゃないか？ と気になって調べたらクロードなんて付かないようだ。

って言うか、これを買わなきゃいかんだろう。というわけで、以前miniSDドライブ買った時のギフト券還元を思い出したので購入。

この映画はすごいのだ。

主人公の少年は小学校でそこそこ楽しく暮らしているし、聡明だし、いいやつだ。客観的な主観描写。

しかし、次々と不幸がタコ殴り（という言葉は大人はわかってくれないからの引用）に襲い掛かってくる。愛してもくれるし理解もしてくれる祖母の家から母親の家へ引き取られる。新しい町。見慣れぬ光景。立派な学校。目が輝く。が、新しい親父は子供は労働力としか考えていないから、さっさと丁稚奉公に出されてしまう。勉強したいのにできないってのは本当にいやだね。つい、ドトールに行く度に学校建設募金に小金を入れてしまうのはそんなことが理由かも。で、奉公先の親父の雇用ってものについての認識ときたら子供は奴隷のくせに小金を巻き上げる泥棒だ程度なもんで徹底的こき使われる。

しかも近所の小僧仲間とはほとんど話しが合わないのも辛そうだ。

でも、人間は環境に慣れてしまうものだ。

しかし、ナンパ方法を小僧グループの先輩から吹き込まれた関係でたまたま映画館に入ってしまう。おお、映画との出会いをここまで見事に表現したのって、他にはスタージェスの（題名忘れたが、無実の罪で南部の監獄に入れられてしまった映画作家についての）映画があるくらいだ。

最後、小僧仲間と海辺の町へナンパ旅行へ行く。そして小さな恋をする。おしまい。

もっとも美しい映画のひとつだ。

_ とかげ台風

マークボランのスライダーメタルグルーを聞いていたら、あらためてというかはじめて、モモヨの声を震わせるスタイルってマークボランの影響下にあるのかと納得した。

復刻あげ。

ただ、どうしても、『チンケな』という言葉が好きになれない(そのほかにも言葉の選択がまったく趣味にあわない)ので、買うか買わないか迷っている。

_ 必見! 最高のユーザーインターフェイス

うがー、さっきまで町山智浩アメリカ日記にリンクがあったはずなのに消えちゃった（書き直された）よ。

ヒストリーをゴソゴソ（しなくても、今はクリック一発で出てくるからいいね）。

電子投票システム。

大爆笑でした。（一応、文脈を紹介しておくと、米国で採用されている電子投票システムはブッシュの息がかかった企業が開発したシステムで、かつ仕様その他は企業秘密で、しかも40%くらいの州が採用かな――というとこがあまりにうろ覚えなんでもう一度読もうとしたら無くなってたわけだが――ってことは、こんなことも可能だよねというジョークなわけだが、おもしろい）

追記：2004-10-30として再掲されている。40%じゃなくて1/3。導入を進めたのがブッシュ政権。受注した会社は共和党に多大な献金をしている（直接的にブッシュの息がかかっているというわけではないらしい）。管理も集計もこの会社。っていうか、読んだ方が早い。

こういうふうに作っておけばシステム開発者の意図通りに操作されることになるわけで、やっぱりHTML（シンクライアント）じゃ無理があるよな。

_ kshじゃなくruby

単に僕がkshの書き方（というよりコマンドかも）を大して知らないからかもしれない。が、こんなのはRubyじゃなきゃ書けなかった（比較対象はksh。Cで書けるのは当たり前）。

ユースケース：

RMIのサーバープロセスをデーモンとして起動/停止する

コマンドライン：（実際はちょっと違うが）

起動：

sudo /etc/init.d/foo_rmisvr START

停止：

sudo /etc/init.d/foo_rmisvr STOP

問題点：

javaは実行後、LD_LIBRARY_PATHにjvm.soを含めた環境を用意し、fork/execする（rjbで問題となった動作そのものだ）。

このため、foo_rmisvr内で起動したjavaのpidを/var/tmp/foo/svr.pidに格納しSTOPで9を送っても実際に停止したいプロセスに影響を与えられない。したがって明示的にプロセスグループをjavaを実行するプロセスで設定したい。

解決方法：

if ARGV[0] == 'START'
  pid = fork
  if pid.nil?
    Process.setpgrp()  #ここがミソ
    exec("#{ENV['JAVA_HOME']}/bin/java .... ")
  else
    File.open('/var/tmp/foo/svr.pid', 'w') do |f|
      f.write(pid.to_s)
    end
  end
elsif ARGV[0] == 'STOP'
  if File.exist?('/var/tmp/foo/svr.pid')
    File.open('/var/tmp/foo/svr.pid', 'r') do |f|
      pid = f.read
    end
    begin
      Process.kill(-9, pid.to_i)
    rescue
    end
    File.delete('/var/tmp/foo/svr.pid')
  end
end

_ 制御の逆転

Officeさんが技術者かどうかはとりあえずおいておいて。

僕の乏しい知見では、技術者であればあるほど、例え話に苛立つような気がする。一言で言えば、正確ではないからだ。

例え話を理解するには、高度に抽象的な思考様式が求められる。直截な表現と異なり、類推と対比から相似性を発見し表面的に理解する方法だからだ(追記：風姿花伝のように、カタから入るって世界と共通してるような気がするな。WHYではなくHOWだ)。当然、表面的な理解がそのまま深奥まで同一とは限らないからどうしようもなく曖昧さが残る。が、自分の身近な事象に一度舞台を変えることで（擬似的な）経験に基づいて考えることができるようになるから、理解はうまくいけば瞬時にできる。

（追記：したがって、人間がしでかすことの考察には類推的な方法にそれなりの効果があり、非人間的なことの考察には類推的な方法は大抵間違えることになるのかも知れないな。人間は人間だが、自然は人間ではない。大体、自然は単純さを好むかも知れないが、人間は人それぞれだ）

突然思いついたが、ビジネスアプリケーションと組み込みアプリケーションと2種類に分けると、前者は例え話が当然の世界で（何しろ、XPじゃメタファーだし、いやおうなくモデルと付き合う必要もある）、後者は例え話禁止の世界（シグナルが相手で、ハイならハイ、ロウならロウだ）とかあるかも、したがって、技術者どうしたっていう分類はそれ自体が理系がどうしたのようなヨタ話ではある。

で、おもしろかったのが検察官を翻弄しまくったoffice氏の奮闘だ。ここでは（技術者とされる）Officeさんが例え話を駆使して検察官を黙らせてしまう様子が生き生きと描写されている。検察官がどこまで技術を理解しているかはわからない。しかし、例え話は確実に理解できるようだ。

<