日々の破片

_ Good Enough

何で読んだかのか覚えてないが、クライスラーのネオン（だと思う）について書かれたもので、なぜこの値段で作れるんだ？ と不思議に思った日本の自動車会社がバラして調べたらエンジンの鋳造の仕方が考えもしなかったいい加減（とは言え、安全面では問題ないはず）な方法で、そんなやり方があるのかとびっくりしたっていうようなエピソードを思い出した。（刳り抜くんじゃなくて張り合わせるとかだったかな？）

どこまで普遍化できるかわからないが、1990年代のアメリカの代表的な工業製品でもそういうgood enoughな方法論が適用されていた（はず）だから、それはソフトウェアに限ったことでは無いのではなかろうか。オリジナルなアメリカンウェイなのか、1990年代以降のアメリカンウェイなのかはわからないが。

そう言えば最初にCSMA/CDを知ったときは驚いた。常識的にはトークンリングみたいに組み合わせるかインテリハブを置いたスター構成で物理的なP2Pでsyn-ackとかを考えるんじゃないか？ それがバスにぶらぶらぶら下げて同時に投げますなんていうのはgood enoughの最たるものだと思う。その後、元々は無線のためでどうした、というようなのを知ってちょっと納得したが、それを有線に持ち込むっていうのはやはり大したものである。とりあえず大丈夫そうなら投げてみてぶつかったら間をおいてやり直せばいいじゃん、なんていう方法を良く持ってきたものだ。当然、回線の使用効率は良くないんだが（30%くらいの実測値を以前手にしたことがある）、単純化されているため高速化できる、そのため結果的に（ノード数に依存するが）高速だとか。これってCPUの先読みにしても、キャッシュラインのフィルにしても、とりあえず後先考えずにまず実行してしまうっていうのは、やはりアメリカンな大雑把さじゃないかなぁ、とか。いや、そう思うのは、原爆とかいきなり実戦投入したり、マグロ漁船がいようがなんだろうがいきなり水爆実験したり、とか、森にゲリラがいるなら森をなくせば隠れられないだろうと枯葉剤ばら撒いたりとか、とりあえず先住民族にガラス玉を渡したり虐殺してみたりとか、とネが同じような気がしないでもないでもない×10くらいかな。でもそういう方向に話を持ってけば、誰が八路かわからないからとりあえず全員殺しちまえとかやった吾国にもはねかえってくることでもあったのであった。そういうことには驚くほど大胆不敵なくせに、自分が痛みを伴う可能性がほの見える場合には驚くほど小心不遜なのはこれいかにとか。

というところから楽観ロックと悲観ロックとかに思いを巡らす。だから、そんなにガチガチに作ってどうするよ？ 悲観ロックでWebアプリケーション作るってそもそも間違ってるでしょ？ 最初に読み取ってレスポンス返したらコネクションクローズするから意味ないでしょ？――だからコネクションをセッションに保存してお……――バカですか？(追記：というか悲観ロック以前の問題だな、これは。トランザクションをセッションと合わせようってのが……）――そうは言っても、同時に更新されたらどうすんですか？ ――1.上書きでシカト（更新ログ取っておいて衝突してないか調査可能にしておく、あるいは定期的にログチェックする仕組みを用意する）、2.参照カウンターを仕込んでおく、とか方法はいくらでもあるじゃん。大体において、同時に複数の人間がマスターをいじくる可能性ってどれだけあるのよ？ ――そうは言っても可能性は0じゃないですよね……とか。

（追記：待てよ、コネクションをセッションに突っ込んで（クラスタリングではセッションを開始時のノードにべたべたさせる設定にするのが前提）for updateでロックかけた状態でレスポンス返して、次のpostで更新−commitっていうのがこの文脈では大雑把に大胆不敵なのかな？ 単なる無知ではなくそれはもしかしたら優れた発想の転換かも知れない、かなぁ。とは言うもののやっぱり許せないのだが。とは言え、セッションタイムアウトのイベント拾ってロールバックできるわけだし、そういうのもアリか？ 同時接続ユーザー数次第かな）(更に追記：っていうか、逆にやっぱり難しいな。アンロック待ちで待たされる人間が出てきた場合――だが行ロックなんだから最初の前提である同時に同じマスターをメンテする可能性は低いがこっちでも適用可能ではある――には、きっと中止ボタンを押してやり直すはずだから、その場合は同一セッションの別のスレッドが動いて、現在ロック待ちのコネクションを拾ってくることになるから、それを判定して中止してやるとかしなきゃならないが（とりあえずcloseしてやれば良いのか。中止した場合は更新データのPOSTにはならないから。その場合元のスレッドはSQLExceptionで飛ぶからそれはそれで良さそうかな。どっちが簡単に実装できるかだな、問題は。というか、コネクションが幾つあっても足りないような気がやはりするのだが、それ次第か？ 1000コネクションくらい作っとけば平気かも）

しかし、どうやればページ間で情報を受け渡せるんだ？ とBTW。#getSessionMapってセッション間で維持されないのか、それとも元々セッションが維持されていないのか（ではどうすりゃいいんだろう？ managed-beans.xmlにはmanaged-bean-scope要素にsesshonって書いてあるんだが、これはそういう意味じゃないのかなぁ。

全然、情報がenoughじゃないんだな、これが。

追記：getSessionMapで合っている。JSPのエンコーディングをいじったり勝手に変更されたり追加されたりした（そこが既にダメダメなんだが）コントロールを手修正しているうちに、イベントハンドラの設定が飛んでいて呼び出されていなかった。しかし……（言いたいことが死ぬほどある。とりあえず>×10000個ほど）

#しかし、いつもながらに、全然元の記事とは無関係なことを書いているのでこれもリンクは無し。

_ コメント付いてた

しかも40代SI・経営者。どんな知見が得られるかと思ったが、当時はH/Wが貧弱だから机上考査が必要で云々とか書いている。オープンシステムについての実体験に基づく考察がゼロな上にこちらが提供している考察を繰り返しているだけで、いろいろな事と見比べろとは、片腹痛い。

どうして、ちゃんと読まずに説教を垂れるんだろう？ 知見が乏しいから自分の正しさを主張したくなるのだろうか？

ようするに最後まで読まずに（こちらは適用可能性を出しているわけだから）書いてみたのだろうか。

と同じ轍を踏まないように続きを見るとこちらにもコメントが付いていた。それは良し。しかし、内容はだめだ。読んでいない。言った言わないは要件／外部仕様の範疇で、こちらはそれは「必要」とわざわざ書いているしスコープも明確にしているのにそこは読まずに反応しているらしい。

さらにその上には、言葉尻に反応してみせた人間らしきもの――()が無いので人口無能かも知れないが――。プログラムを組む＝設計するは、当然の話だ。こちらは人口無能だけあって何を言いたいのかわからないが、とりあえず嘴を突っ込みたかったらしい。

筆者は一応書いている範囲のことは実証してんだよ（人月でいけば300程度の規模だけど）。秘密だけどな。

多分、真に知見を持っている人間はわざわざ書き込まない（誰が他人にタダで教えてやるもんか、と考えるのが従来型だからな）、ということなんだろうが、それにしてもあまりに予想通りの反応しか得られないのでがっかりする。それならそれで人口無能型のが100個くらい書き込んでくれればそれなりにおもしろいんだが。引っ張られてこちらの気付いていない／気付けない知見を出してくれる人が出てくる可能性があるからだ。いずれにしろいささか遅すぎる。

追記：ESRだってfetchmailの規模でもとりあえず実証実験してからノウアスフィアを開墾しているじゃなくてバザールという考えを出してきているのだ。思いつきだけで書いてるはずが無いではないか。それもわからんのかとちょっと不快になるな、人口無能の書き込みについては。

とは言え当然だがある程度以上の規模になると関われるプロジェクトの数には限界があるから実証するったってそう簡単にいろいろ試せるはずがない。って言うか失敗したらそこまでだしな（少人数規模だと無理すればやり直しがきくからそっちでいろいろ試せた後だというのはまあ、あるかも。いろいろすまんかったと思うことも無いわけでは無い）。したがって、こっちの知見より優れたものや、あるいは優劣無関係に別の角度からのもの、そういったものがあるのは当然のことだ。

実際、ある程度以上の規模だと失敗は致命的だからあらかじめ複数の逃げ道を用意してからことに当たることになる。その結果から得た知見だからそのための妥協点などが夾雑物として紛れ込んでいる可能性も高い。ましてこっちは机上の話をしているんじゃないし、言うだけ言ってさようならな仕事をしているわけじゃない。あくまでも実装／稼動を前提としていて、実際に動かしているわけだしな。という点から批判は十分に有り得るだろうとは想像していた。だが、あれでは意味がない。

結局のところ、事前にいろいろ考えてからやるのは当たり前。だが自分の頭は自分の頭の鉢の大きさに制約される。したがって、それ以外の情報がいやでも必要になる。そのためには事例はこちらも知りたい。だが、業務システムだとこれは知的所有権にかかわってくるので生で出てくることは考えにくい。そのため事例が無理なら知見（これは抽象化されているので知的所有権にどうかかわるかは微妙になる。特に個人的知見というやつなら安全であろう）でも良い。そのために手持ちの知見を提供しているという側面がゼロとは言わない。そのために持って回って丁寧にしつこく書いていたのだが、いささか期待外れではあった。

さらに追記：もって回って書きすぎたのかも知れないな。ツッコミどころをところどころにハニーポットとして仕込めば良かったのかも。だが、それでは逆に記事としては価値を低めることになりかねない。というかそれは本末転倒だ。結局のところあまり良い記事じゃなかったようだな、と反省。

_ 爽やかで高級感あふれる「ソウデッチュ」

カネゴンさんのとこで見てOnsonic体験版を体験してみる。

ポンポコポン 個性的 活動的 庶民的

ポコペン 庶民的 安らぎ 都会的

オリハルコン 静的 信頼感

ひびのかけら 明白さ 特殊的

レクラデジュール 静的 充実感 信頼感 老人層

ジェイツーイーイー 特殊的（圧倒的な） 男性女性ともシルバー層ねぇ

だんごさんきょうだい 充実感 静的

たけやぶやけた　庶民的

いってよし 特殊的 活動的 女性ヤング層とジュニアに断トツ

マイクロソフト 爽やかさ 中年男性

サンマイクロ 特に特徴が無い

オバルディン 充実感

ラスプーチン 爽やかさ 中年男性

ゆげのどうきょう 静的 充実感 信頼感 中年女性 なるほど。

おんそにっく 充実感 中年男性

どうしてそうなるのかは全然わからないが、おもしろいな。なんか、みなさん爽やかですなぁ。