日々の破片

_ 聖なる日

3と1だってだけだが。

プログラムは、隅々まで明らかでなければならない。と思う。トランザクションのACID特性にならっていえば、常に同じ結果を生むこと（さて何特性でしょう？ 時間や空間に関することだな）、誰が書いても同じ結果を生むこと（究極には誰が書いても同じコードであること）（これは非属人性だな）、他に何かある？ といった特性が必要だ。

プログラムについて書かれたものも、同様に、隅々まで明らかだといいなと思う。ここでは推敲は、言葉の平明さと明確さを意識する。こちらは、書かれたものである以上、もうちょっとブレが無ければつまらんな。しかしブレは例の選び方とか応用範囲（狭ければ入門用だし広ければ上級用だ）といった方向でなければならないだろう。つまるところ実用性が重要だ。

だから、できるかぎり、それ以外のことは、曖昧でデタラメで韻文的で、しかも散（乱した意味から構成される）文でありたいと考える。考える。

オノマトペは名前がオノマトペだから素敵なんであって、多分、オノマトピでも楽しそうだけど、ギオンじゃつまらない。そこでオノマトペという言葉から元の意味をはがして、言葉の持つ響き、そこから生まれる感覚、そこから想起されるなにか、しかもその時点で（表層的な、なぜなら深層的であれば、その時点ではなく、次の時点や、その次の時点や、へたを打てば永遠にそれがついて回ってしまうかも知れないじゃないか）浮かび上がってきたもの、そういったものに焦点を当ててみる。

したがって、記録された言葉の連なりであっても、それを見返す時点でまた、異なった意味を持つ可能性が出てくる。

グールドの演奏がそんな感じだ。バックハウスは常にバックハウスで、コンテキストはバックハウスが持つ。1回聴いても2回聴いても同じ音が聴こえる。グールドの演奏ではコンテキストは音源には刻み込めない。だから、聴くたびにグールドかも知れないが、異なる印象を得ることができる。少なくても成功している幾つかは。

記録されたもので、そのような即興性を持てるのであれば、常にベストなコンディションを要求されるコンサートを回避するのは、当然の帰結だ。と思う。体、弱そうだし。心臓病のロボくん。

どのどんぐり？ と訊かれてでたらめでてんでなっていないのだと応える精神。どっどどどっどっどとリズムは違えど、そんな感じで吹き過ぎて行く。

音楽はどこから生まれたんだろう？

儀式はなんのために始まったんだろう？

幸いなことに、言葉には、辞書的な意味のほかに、コンテキスト依存の意味、記憶に結びついた意味、その記憶は社会的であったり（9.11という数字の羅列の意味とか）、個人的であったり（しょわんとか）、歴史的であったり（ルビコン河とか）、民族的であったり（井戸とか）、党派的であったり（いろいろあるな）、幾重にも花弁を持つ花のようなものだ。中心にあるのは辞書的な意味ではなく、単なる穴だろう。すべての意味を吸い込む穴だから、意味は生まれては吸い込まれていき、人によって見えたり見えなかったり。

と考えると、プロトコルに乗っ取った、複数の人間との間で意味のやり取りが可能な言葉の連なりというのは（その相手は、数秒後の自分でも良いわけだ）、まったく数の世界の中に浮かぶ自然数とか、宇宙の中の地球とか、50億の中のおいらとか、のようなもので、たまたま、奇跡的に、そこにあるだけだという事実にちょっとは驚きたいものだ。が、割と通じるんだよね、これが。

そいつが、つまり、理性の箍（って漢字が出てきたがあってるかどうかわかんないけど見かけないからこいつにしてしまえ、と説明するメタデータ）ってやつなのだ。あーくだらない。

_ メモ

アクター　→　ユースケース

って場合、→に乗っかるメッセージの容量は小さいというのが前提？

クライアント     コントローラ       モデル
　object    →   object 　　　→  object　　→　　データ

の→についてもメッセージの容量は小さいのが前提。

これが、

     システム　　　　　→　　　　　　システム
データ  ←  サービス         サービス  → データ

となると考えると、このメッセージ呼び出し側システムのコンテキストを運ぶ必要が場合によっては出てくるだろうから、とてつもなくでかくなるのではないか?

仮にそうだとしたら、その呼び出しのメソッドシグネチャーは

void foo(String a0, String a1 ...);

ではおそらくだめで、

void foo(String[] a0, String[] a1, ...);

でもおそらくだめで、

void foo(String theDocument);

とか。

これをXML Webサービスでやると、XML over XML。

それは無意味なので、Document形式でのメッセージ交換。

するとアンマーシャリングは、一段上のレイヤー。

_ DTO

DTOの話題が目に付くので、以前からの疑問を。

シナリオ：リモートからデータ群を読み込む

当然のごとく、この場合はDTOを使う。しかし、COMの時はMBV（マーシャルバイバリュー）って書いてたが、すっかりJavaな人になってるな。

このとき、このDTOは次のように書かなければならない（と思う。エラーになるし）

public class DTO implements Serializable {
    public void DTO() {
    }
    public int getInt() {
       return intVal;
    }
    public void setInt(int i) {
              intVal = i;
    }
    private int intVal;
}

何がいやかって、どう考えたって、こいつはイミュータブルなんだからsetIntはいらんだろう。

確かに、Class#getMethodsにしてもClass#getFieldsにしても、public縛りがあるから、これがイヤなら、

public int intVal;

とするしか方法がないというのはわかる。

どっちにしても、原理的に不変性は失われる。

っていうか、hashCodeの実装に、安心してiValの値を利用するってのは難しい。紳士協定しかないからだ。

#ここではRMIの動作を前提としているから、コンストラクタの引数というのは無し。

いっぽう、.NET FrameworkのType#GetMethods(BindingFlags)はどうかといえば、BindingFlags.NonPublicを指定することで、ぞろぞろ抜き出せる。したがって、イミュータブルオブジェクトであっても一般的な機構だけ利用してマーシャル／アンマーシャル可能。逆に言えば、一見イミュータブルであってもリフレクションを利用すると裏から変更できる。

さて、クラスのインターフェイスに紳士協定を求めるのと、タイプシステムがアクセス権を無視して介入できるのと、どっちが好き?

難しい。

#僕は後者なんだけど、こういういろいろな危うさがあるのが、いいところ。

#でもこれって、アプリケーションプログラマを舐めてるとも言えるんじゃないかな?

_ ちょっと不安になったので、試してみた。

.NET Framework 1.1

using System;
using System.Reflection;
public class A {
    class B {
	private int a;
	internal B(int c) {
	    a = c;
	}
	public int getA() {
	    return a;
	}
    }
    public static void Main() {
	B b = new B(100);
	Type t = typeof(B);
	FieldInfo f = t.GetField("a",
			 BindingFlags.NonPublic | BindingFlags.Instance);
	f.SetValue(b, 500);
	System.Console.WriteLine(b.getA());
    }
}

実行結果

C:\Home\arton\test>csc test.cs
Microsoft(R) Visual C# .NET Compiler version 7.10.3052.4
for Microsoft(R) .NET Framework version 1.1.4322
Copyright (C) Microsoft Corporation 2001-2002. All rights reserved.
 
C:\Home\arton\test>test
500

注：JavaとC#ではインナークラスのアクセス修飾子の意味が異なるので、Mainから、直接、b.aとした参照はできない。privateフィールドにさわるにはリフレクションが必要。

_ 耳の日

だからというわけでもないが、ボエームを聴く。なぜかドイツ語でルチアッポップが唄うやつ。

こんなのがあるんだから、日本語オペラだって問題ないんだが。でも、リズムと音声が良かったりするとやはり原語主義ですな、とか、思い出すのは動くな死ね甦れというか独りで生きる。あの声は素晴らしい（と、なぜか映画の話に変化してる）。

_ 契約駆動開発

メイヤー。

フリーマンのとこから。なんか文句があるらしい。

両方とも後で読むつもり。

_ これどーなったか知ってる人はいないかなぁ

当時、ふーんおもしろいなぁとか思って眺めていたものの、2000年前後は、COM−DCOM−.NETが中心だったし、そのうちすっかり忘れていた。こちらが知らないだけで、そこら中で動いている可能性が当然あるので、とっても知りたいんですが。

エージェント指向。

アンテナとかスパイダーはエージェントじゃないよね。いや、エージェントと言えなくもないか。いや、多分、エージェントだろうって気がしてきたな。スパイダーはともかく、アンテナはエージェント、本当?

クライアントがプログラムを送り込んでサーバーで動かすっていう意味じゃ、XMLでどかんと送り込んでお任せするサービス指向ってのは関連しているかも知れない。

XML Webサービスってのは、エージェント指向の成果なのか? もしかして。

スマートクライアントはエージェントか?

実装技術としてのアグレットってのは、どうなったんだろう?

_ リラクサー

なかなか、調子良い。最初DOMでやってみて遅いなぁ、だめかなぁ、と思ったものの、SAXオプション使って生成したハンドラを使えば許容範囲になったし。

こうなると、XSDをRELAX NGに変換するしか、と思ったら、結構記述ミスがあってコンバーターが通らない。人間コンバーティングするのが早いか、記述ミスを直すのが早いかがいささか微妙。

_ iBookの現在

妻の専用機になってしまっているのであった……

_ サービス指向

なんでオブジェクト指向でないかと言えば、送り込まれてきたメッセージは振る舞いを持たないからだ。もちろん、.NET間、Java間であれば、XMLシリアライズされた（単にSerializableとかISerializableを実装した）オブジェクトとしてアンマーシャルできるから、自分が持ってるデータを使って振舞うこともできるわけだが、そんなよそから入ってきたオブジェクトが傍若無人に振舞ったら、そりゃ、カプセル化の破壊ですな。ここでカプセル化されているのはドメインかな。

しかし、送られてきたメッセージが運んできたデータについては当然だが、受け手は知っている（知らなきゃ無視するーしたがってanyが出てくるわけだが）のが前提だから、受け手がそのメッセージ内のデータをもとに振舞う必要がある、というか、振舞うのがすなわちサービス。

これを額面通りに実装すると、イミュータブルオブジェクト（変更は呼び出し側に反映されない。なぜならば値渡しだからだ）に対して、ゲッタを呼んで、得たデータから自分の側をいじくって、またゲッタを呼んで……となって、Tell, Don't Ask原則の出る幕はないことになる。

そこで、このメッセージを1度、外部から来たオブジェクトとして、振る舞い可能なように服を着せてやることを考える。

すると、メッセージは魂で、服を着せると人間のように行動できるようになる、ってことになる。

サービス産業のメッセージは、心と心のふれあい、裸のおつきあい、ということですな。

たわけたことを（と一言付け加えたくなるよな、そりゃ）。

_ まだ続く

たとえばアクションフォームでもいいや。これだって、外部からやって来た値オブジェクト(DTOでもいいけど)だから。この中に買い物カゴに入るべき商品に対応するチェックボックスのチェックと、数が入っているわけだから、これを受け取った側で、

actionForm.pack(cart);

するほうが(お前さんの中身をカゴに詰めろ)、

 String itemId = actionForm.getItemId();
 int quantity = actionForm.getQuantity();
 cart.pack(itemId, quantity);

より本当ぽいんじゃないだろか。こっちは、目に見えぬ主役（アクション）が1度コンテナから荷を取り出して、こっちのカゴに入れてやるわけだから、確かにコントローラだからこれで良いのだと言う事は可能だが。

もちろん、

 cart.pack(actionForm);

でも良いかも知れないが、この場合、actionFormをcartに与えてはいかんだろう。でも、actionFormが、ShoppersHandsインターフェイスを実装していれば、

 ShoppersHands hands = (ShoppersHands)actionForm;
 cart.pack(hands);

で、それなりにさまになるかも。手の中のものを取り出せってことだ。

でも、このcartに命令するのって、結局、cartのpackメソッドでは、

 String itemId = hands.getItemId();
 int quantity = hands.getQuantity();

っていう買い物客の手に対するaskが走るわけで、いっぽう、最初のやつだと、

 cart.addLine(itemId, quantity); // itemIdとかはActionFormのインスタンス変数

という具合に、askはどこにも出てこない。きれいにtellだけで済む。

これはMVCモデルがオブジェクト指向の原則論にあってないってことではなくて（たとえばGUIアプリケーションであれば、入力は最初からコマンドオブジェクトにしておくことは可能だ）、間にネットワークが入るから値オブジェクト（DTO）が出てくるためだ。もちろん、カートはサーバー側のオブジェクトだから、ここでActionFormがクライアント側オブジェクトとして参照でやって来たらとてもまずいことになる。だから値オブジェクトになるのは全然OKなのだから、こいつをアンマーシャルする（ここではStrutsを無理矢理出しているから、アンマーシャリングとは思えないかも知れないが、url-encodedなストリームとしてマーシャルされたオブジェクトをアンマーシャルした結果がActionFormだと考える）時に、まっとうなオブジェクト（振る舞いを持つ）に変換できれば、良いのだな。

RPCだと、この外部からの値が、引数としてあらかじめアンマーシャルされて来るため（量に依存するけど）

public class Cart implements Remote {
  public void add(String id, int quantity) {
     ....
  }
}

となって、オブジェクトが外部から来るとは、それほど考えないで済むのだが、MBVとかDTOがクライアントからサーバーへ来るシナリオでは、ここに妙な断絶があって、いきなり、問い合わせが始まるのが興味深い。

_ レイジー

竹内さんのとこだと思ってツッコミを入れたが、もしかしたら誤爆だったかも。

_ スキーマはどう切りますか？

スキーマ言語に何を使うか：DTD, XSD, RELAX NG, その他

ツール：メモ帳/エディター, VS.NET, その他（これしか選択枝が出てこないところがXSDとDTDに偏重する理由かも知れない）

何に使っているか？： 仕様書、コード生成のため、バリデーション、その他

_ 今日困ったこと

XSD→RELAX NGするのに、Sun RELAX NG Converterを使ってみた。

で、<xsd:include schemaLocation="file:///C:/hogehoge.xsd">

が、エラーになること。実際にはhogehogeの部分は/documents/xxxx/...なんだが、

java.net.忘れた： unknown host: documents

というようなエラーになる。どう書いてもなる。xsd:importは、file:でフルパスを書けば通るのにxsd:includeはどうあっても、unknown hostになる。

うーん、と悩んだ末、IISをインストールして（これはWindowsマシンで作業してた）、http://localhost/xxx/hogehoge.xsd にして解決。

その後も、妙なクセに悩まされた。変換するとルート要素すら必ずchoiceから始まるのだが、Relaxerがうまく処理してくれない。これは、choiceから始まるのが変だろう（最初から手で書けばこういうスキーマにはならないし）ということで、変換したものをRubyでフィルタかけてchoiceを外した。

とかやっていくうちに、さらにいろいろ出てきたが、とどめは、antで複数のファイルを順にjavaタスクのargとして与える書き方がわからないことでした。

面倒になって、スクリプトを書いて（scriptタスクじゃなくて）、execタスクで実行したり。

しかし、そんな苦労をしたものの、今、落ち着いてantのマニュアル見ると、Apply/ExecOnが、まさにその機能だな。

_ アンテナはエージェントじゃない

プログラムが移動するわけじゃないし。

ごもっともです。

アンテナではアンテナを確認するユーザーエージェント（っていうかブラウザー）と、アンテナ設置サイト、アンテナ監視対象のサイト（群）の3種類のオブジェクト（というのは語弊が大有りだけど）があって、アンテナ設置サイトは黙々と監視を行っているというあたりでそんなことを考えたのかな。

しかし、なぜ、エージェント指向って言葉が消えてなくなったのかは興味深いです。とは言え、実際には消えてなくてガシガシ動いている可能性はあるんですよね、こういう技術って。

_ ZONA

カールでカイゼル（読みはでたらめ）のフラッシュだけで構成されたサイトなんだが、ZONAというシベリアの収容所の写真集（BOOKSとEXHIBITIONSの両セクションにある）がとんでもなくすごい（実は、他のまで見ていないからもっとすごいのがあるかも）。たとえば食堂で飯食っている連中がすさまじいガンヅケしてる写真があるんだが、怖いぞ、とか。

これもLeftさんのところ経由。昨日はどうも、楽しかったです。

ロシア、目つきというと、ゲルマンの我が友イアンラプーシンはたまたま試写会で見たのだが、日本海映画の人が、この映画を買い付けた1番の理由は途中の列車のシーンの兵士の目つきがすごかったからだ、とか言っていたのを思い出す。

_ 牯嶺街少年殺人事件

DVDにはなってないのか。

ちょっと間違えていて、主人公達は中学生。途中で出てくるヤクザとその一派だけが本省人で、ほとんどは外省人。60年代初頭または50年代末期が舞台。裸電球。

主人公のスーの家は公務員で、同級生か隣のクラスだかのミンの家は兵隊、同級生のマーの家は高級官僚（というか司令官）。職業が違うと住む地域も違うし、生活も違うし、仲間も違う。しかし、公立の中学校は同じ。この呉越同舟ぶりが、そのまま世界となる。その他に、歌がむちゃくちゃうまいサルミネオみたいな役回り(あれ？ なんて題名か忘れたぞ。プラネタリウムのシーンがとてもきれいなニコラスレイの映画)の小僧とか、トルストイの戦争と平和を少しずつ読んでいるハニーと呼ばれる熊のような不良青年（兵士の子弟の親分格）とか。

4時間と長いのには理由があって、些細な細部を描くことで文脈を徹底的に明らかにしていくからだ。

たとえば、サルミネオがラブミーテンダー（違うかも）を唄いたいのだが、そこはあんまりまじめに勉強していないから英語がわからない。そこで、スーの姉さんに頼んで聞き取ってもらって紙に書いてもらうシーン。何度も針をレコードに落としなおしては言葉を拾っていく。酔っ払った隣の家の親父が自転車ごとドブに落っこちたのをスーが助けるところ。この親父はスーの家を毛嫌いしているのだが、ここにX省人をからめているのかも知れないがわからない。サルミネオがプレスリーを唄おうとすると、敵対グループから投げつけられる「コニーフランシスでも唄ってろ」とか。

話は大きく、スーの家、通学路、学校の往復で成り立つ。その間にはさまる集団闘争。

実はミンはハニーの恋人なのだが、ハニーはコンサートの利権争いに巻き込まれ殺されてしまい、結局、生活のために母とともにマーの家に住み込むことになる。

下層と上層は自由(あるいは不自由であっても)、放縦に振舞える/振舞わざるを得ないのだが、中層は、そういうことは関わりなく暮らしているので、自分が本当にただのノンキな少年に過ぎないということを知ってしまう。

という中学生日記のような世界と並列して、スーの親父が国民党の恐怖政治の（ときどきスパイをでっちあげて見せしめることで、恐怖政治を維持するってのがあるわけで）餌食になってしまうのだが、これが2重構造となっている。また、公演でスーや友人たちがサルミネオコンサートを開いてちょっとしたパーティ券で儲けようとする（記憶は不確かだな）行動と、ハニーが殺される原因となるコンサート会場を借りて実際に札束が飛ぶ兵士グループの行動の対称とか（この構造は記憶違いかも）。

スーの世界と、ほとんど言葉の端でしか示されないミンの世界、そして最後のほうになってそれまで示されることがなかったマーの世界（スーがミンのことを好きなことを気付いているし、しかしそれなりに親友のつもりでもあり、ミンよりはスーのほうが自分に社会的立場が近いわけだし、自分の社会的な地位の絶対的な優位性について思うところもあったりして、実際にはマーが非常に複雑なのはマーの語られ方で示されているのだが、実際に中学生なんだからしょうがないが厨坊っぽく「今度、貸してやろうか、おいしいぜ」というような言い方をしてしまうような覚えがあるのだが）が明らかになり、題名にしたがって（というよりも、実話を下敷きにしているそうだから、ラストは誰でもわかっているのだ）スーはミンを刺し殺す。なぜマーを殺すんじゃなくミンを殺すんだ、と最初見たときは思ったが、やはり死ぬのはミンでなければならないのだな、と今は思う。

獄中にサルミネオからテープが届く。看守に握らせたから聴けると思うよ。そしてサルミネオ版プレスリーが流れておしまい。

監督エドワードヤン。

最初3時間版を見て、すぐに公開されたので4時間版も見た。本当に好きな映画のひとつだ。

この監督が圧倒的なのは、時間軸は素直に取っているのに、その上で多層構造で個々の人間とその人間の世界をきちんと書くことだ。

マルチスレッドでセキュリティコンテキスト、トランザクション境界、処理ドメインが異なる複数のオブジェクトを同一プロセス内できちんとインタラクトさせながら動かし、かつその論理構造が明解で、かつ実行時に破綻がなく、かつソースコードが明晰であることの困難さは誰でもわかる。そしてそれを平然とこなせるのだから、すばらしい。

右のカップルズは、リアルタイムな台北を舞台に4人のちんぴらと、そこに紛れ込んだ1人の外人の女の子（まるで御厨里美の漫画を思い出す）を巡る冒険の物語。退屈な日常を退屈でなく過ごすために空回りするつまらなさ。これも良かったが、しかし、短いかも。また、ホンコーンと呼ばれる小僧の書き方があまりにも滑稽過ぎてちょっと気分が悪くもなる。

_ クーリンチェ少年殺人事件

懐中電灯か!。

言われて鮮やかに思い出す押入の中の懐中電灯、夜の学校(?やっぱ鮮やかじゃないじゃん)での懐中電灯、まるで武士の大小のように、身につけていなければならないものの如く、孫悟空の如意棒のごとく、常にスーと共にある銀色の懐中電灯は忘れていた。

それに、全然、記憶から欠落していたが、「私はこの世界と同じよ」と言われたのだった。世界から追放されたら、口元に笑みをたたえて背を向けて歩き出すか、さもなければ世界を変えるかだ。そして世界を変えるためにナイフを突き出したんだったんだな。

モノへの偏愛っていうのも、思い出した。カップルズでの携帯電話なんか、完全に、異常なほど、携帯電話、携帯電話。まあ、ディスコミューニケーショナルなコミュニケーションツールというとてもわかりやすいツールだから特徴とは感じなかったのかも知れないが、言われてみれば、そのような機器への偏愛があるのは間違いなかろう。

_ しょぼーん

言語の問題はあるな。

以前も指摘されたが、こればっかりは先に立てられないし、まあしょうがないところだ。

_ ブランディング

で、ついでに引用されていたから、This is truly one of the best pieces I have ever read on “branding.”とウィリアムとムーア(というマーケッター。知らないけど)も言ってることだし、あとで読んでおくことにしよう。

ディズニーはこんなことを言ってる。

追記：なぜか途中から訳し始めたのだが、この前になぜ失敗したかの分析があり、それも重要。まあ、ピクシーの作った映画は当たるけど、ディズニーが作った映画は当たらないということなんだが。

創造すること（the creative process）こそディズニーカンパニーの生命線だ。それができるなら、僕らはどんな犠牲を払ってでももう一度花開くような環境を整えるべきなんだ。

創造性ってのは奇妙なものだ。計測は難しいけど、無くなってしまえばすぐわかる。それは生き物なんだ。命を持って息をしてるんだ。それは個人や小さなグループの中で花開くんだ。欲しがれば――時宜を得たからといって手に入るってわけじゃない。委員会とか戦略会議とかによって簡単に死滅しちゃうし。だから、いつだって育て方を見つけなきゃならなし、最小公分母精神に委ねちゃいけないんだ。

創造性の最大の敵を僕は「企業思考」と呼ぶことがある。これはとても奇妙に聞こえるかも知れない。だって、ディズニーは企業なんだから。でも、だからといってそういう思考法を採用しなきゃならないってわけじゃない。

こいつの危険性について喋らせてくれ。僕らの会社の1番の財産はディズニーという名前だ。これ以上は言わないよ。こいつは僕の名前だし。でも、最近では「ディズニーブランド」として扱われることが多いようだね。僕にとっては、それは「ディズニー」を官僚主義的管理可能な「モノ」に格下げされたように見える。本当は創造性のチャンピオンの「名前」なのに。今ではミッキーやプーさんや他の連中も、そういった扱いを受けてるとしか思えない。

別の機会にも言ったことがあるけど、ブランド（烙印）ってのは牛のケツに押すものだ。君たちが牧場主ならそれも結構なことだが、まあ、牛ってのはどれも似たようなもんだし。それから、ブランドはビジネスマンにとっても価値があるみたいだね。ビジネスマンは洗剤や靴とかにブランディングするけど、ああいったものは牛みたいにどれも同じようなもんだから。つまりだ。ブランドってのは、君たちの売り物がまったくオリジナリティがなくて他と区別できないときに使うシロモノなんだ。

でも、僕らの売り物には何かしらのオリジナリティがあるだろう? 少なくてもあったんだ。消費者は、僕らの名前から何かを感じるんだ。

僕はね、もしこれからもディズニーを「ブランド」として扱い続けていると、3/4世紀もの間にディズニーの文字の上に作られてきたすべての意味を失ってしまうと、本気で考えているんだ。僕らに必要なのはもう一度それを称えられたり祝福されたりする対象――「名前」として考えることなんだ。企業思考から抜け出すんだ。創造への途へ舵を切りなおそう。そして儲けるんだ。

これまでディズニーカンパニーはどうやって株主へ莫大な価値を与えてこれたんだい？ その理由は2つある。1つ目は、クリエイティブピープルの想像力と才能を信じ、任せてきたことだ。2つ目は、彼らが要求するリソースでサポートしてきたことだ。

現在の経営陣が君らに何を吹き込むかは僕にはどうでも良い。明らかな事実はたった1つ。君たちはいつでも誰でも騙すことはできないってことだ。そしてこのビジネスで成功するには割引サービスじゃだめだってことだ。消費者は価値のために金を使うんだ。そして君らが中古品を売りつけようとしてるのに気付いているんだ。

じゃあ、僕らは何をしなけりゃならいんだ？ 簡単なことだ。僕らに任された巨大な価値ある資産を信じ、理解する新しい経営陣を迎えることだ。

ディズニーという苗字を持つ人間の言葉として受け取って欲しいんだが、僕の会社はコモディティーじゃないと信じているんだ。創造的なアイディアのパワーを信じ続ける限り、僕らの前途は洋々だ。

てな感じかな。株主への発言だからもっと固いんだろうが。

それにしても、クリエイティビティへの信頼重要とか、妙に心地良い響きではある。ブランドとネームの差というのは考えてみたこともなかったが、ネームは祝福可能とか評価可能とかっていうのはちょっと日本の感覚と異なって面白い。言いたいことは（日本に置き換えれば）デルやHPはブランドだが、アップルは名前だってことだろう。でもどっちもブランドなんだけどね。烙印って意味は一般的には入ってないから。ファッションだとナショナルブランド、キャラクターブランド、デザイナーブランドと区別があるが、どれもブランドだし。

しかし、HPとコンパックの合併のときも感じたが、アメリカってのはおもしろい国だな。

追記：ピエールカルダンとかがまさに牛のケツに押すブランドに堕した良い例だ。

_ 蓮の実の砂糖まぶし

腹が減ったので食ってみたら、思ったより（蓮の実って入れ物の丸い穴の蜂の巣のほうを想像してなんか固そうに感じるし）うまい。

みてくれと色はマカデミアナッツみたいだが、これが蓮の実の味なんだな。

どうもごちそうさまです。

_ 祐天吉松で検索キター

なんか嬉しいらしいな。

_ Relaxerメモ

relaxer.orgを眺めててもだめだったのか。

日本語マニュアル。

メーリングリスト。

しかし、メーリングリストってのは厄介なんだな、これが。

_ SWin/vruby

これから更新します。

_ Swin

うが、これはだめでしょ。

swincdlg.c(90) : error C2057: 定数式が必要です。
swincdlg.c(90) : error C2466: サイズが 0 の配列を割当てまたは宣言しようとしました。
swincdlg.c(90) : error C2133: 'buf' : サイズが不明です。
swincdlg.c(94) : warning C4034: sizeof 演算子がサイズが 0 となったオペランドに適用されました。
NMAKE : fatal error U1077: 'cl' : リターン コード '0x2'
Stop.

見てみると、

static unsigned buffersize=8192;
...
   char buf[buffersize];
   buf[0]=0;

でも、雪見酒さんは、3/7にはコンパイルできてるようだし。VC6の問題? でもコンパイル時には確かにサイズは決まらないと思うんだけど。

char* buf = _alloca(buffersize);
*buf = 0;
...

てな感じに直して通しちゃいますが、よろしいですか?

と訊きながら、返事を待たずに、パッチ。

swincdlg_OpenFileNameといっしょにswincdlg_SaveFileNameも同じようなバッファアロケーションに変えました。

_ リフレクションでprivateメソッド

プライベートメソッドのテスト。

Class#getDeclaredMethodを使うとprivateメソッドも取得できる。

そっか、それは気づかなかった。

と思ったが、DTOへの自動設定の役には立たないからやっぱりだめか。

追記：public Method[] getDeclaredMethods()は、This includes public, protected, default (package) access, and private methods。ただし、継承したメソッドはダメという制限。だからgetSuperClass()を呼びながら順番にprivateなsetXXXXを拾っていけば継承ツリーを持ったDTOであっても外部から再構築可能。

_ おそるべしgcc

通るんですか。
どんなコードを生成するんだろ。って、allocaするのかな。
って言うか、こういうときのSFU.

#include 
static int size=16;
int main(int argc, char* argv[])
{
  char buff[size];
  strcpy(buff, "hello!");
  puts(buff);
  return 0;
}

をtest.cとして

gcc -S test.c
cat test.s
...今となってはオペランドがintelアセンブラと違って読みにくい……
        .data
        .balign 4
_size:
　　　　.long   16
...
　　　　movl    _size, %eax       #16をeaxに入れる
　　　　decl    %eax              #?
　　　　incl    %eax              #?
　　　　addl    $15, %eax         #0mod16にする
　　　　shrl    $4, %eax          #  続き
　　　　sall    $4, %eax          #  続き
　　　　movl    %eax, -16(%ebp)   # 引数を積む(?)
　　　　movl    -16(%ebp), %eax   # ? 無駄なコード(それともレジスタ渡しかも)
　　　　call    __alloca          # アロケーション
　　　　movl    %esp, %ebx        # espに結果が入るのか? というかallocaはespを指定したサイズだけ下へ進めるんだろう。
　　　　subl    $8, %esp          # ?
　　　　pushl   $LC0              # "hello!"
　　　　pushl   %ebx              # buff
　　　　call    _strcpy
　　　　addl    $16, %esp         # 引数×2と、その前にsubl $8した分らしい
　　　　subl    $12, %esp         # ? まただ
　　　　pushl   %ebx              # buff
　　　　call    _puts
　　　　addl    $16, %esp         # 引数領域が0mod16になるようにしているのかな?

うーん、世の中変わったなぁ。

_ 悪魔と天使

または黒ちゃん白ちゃん。

オキドキ系の店で見かけて、iBookのスピーカーの音があまりにひどいこともあって、外側：iBook=白、内側：BSD=悪魔（はいはいダエモンは妖精ですかそうですか）、という色合わせもあって購入。

しかし、相変わらず妻マシンとなっているのであった。

_ lax

laxってなんだろう?

辞書で引くと「ゆるい」とか出てるし。

<xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

やっぱり「ゆるい」からか。

_ Relaxer

1番気に入った点は、実行時に何もいらない点。必要なソースは全部吐き出してくれる。これが一番でかいかな。

気に入らない点はJavadocがいささかあんまりな点。アノテーションをまじめに入れれば良いのだろうか、とか言いながら調べる気にはならなかったり。ちなみにコメントは棄てられてるが、そりゃそうだろう。

_ iPodにカーペンターズ

PILだのルーリードだのに混ざって、時たまカーペンターズが入ると、思わず、殺伐とした世界を忘れかけて、いかんいかんと気を取り直す。悪魔の音楽だな。

今日は久しぶりにデキシーミッドナイトランナーズが聞けて、結構、幸福であった。

若き魂の反逆児を求めて(デキシーズ・ミッドナイト・ランナーズ)

ケルト民族版桑田圭佑というかなんか、変な声なんだが、好きだなぁ。

今日聞けたのは「7日間は長すぎる」だが、なんかハードロック、ピストルズ（パンク）、スペシャルズ（スカ）、と音楽史をたどるようにラジオのチューナーをいじって、最後に、「くそったれ焼き払っちまえ」と叫び出すとブラスがパパパッパパーパーパパパパーと鳴り捲る、ファーストアルバムのオープニングナンバーは、今でもえらくかっこ良い。で、ボーカルが実にへなへなした声であっけにとられるんだな、これが。

_ マロングラッセ

子供が今練習している湯山昭の曲。

ちょっとラベルを思わせるのは、みまかれし王女のためのパヴァヌに出てくるのと同じ和音の進行があるからなんだが、本当に、とけてしまうような付点音符の使い方とか、最近の（自分で弾くのに関して）気に入っている。

ふむ、ラベルはラベルと書くが、パヴァヌはパヴァヌだな、どうしようもなく。

_ ごめん、sageを見逃してました。はてなの差分に残ってないといいな。

_ 気になる

「MS SQL SA パスワード 忘れた」というとても悲惨な検索をかけてきた人がいるが、素直に、www.microsoft.com/japanにいって、技術情報検索で、製品=SQL Server、キーワード=パスワード リセット とすれば、

ローカルAdministratorsグループのメンバーは、sysadminロールのメンバになれるから、混合モードから認証モードに変更してsaのパスワードを変更できるというようなことがわかるはずだ。

なぜ、グーグルを使うんだろうか?

#もちろん、saのパスワードを忘れて困っている人の日記を見てあざ笑うために検索したって可能性もある。

_ COM Meets Ruby

geoも更新。

MinGWは、gccだからOKだったみたいです。

_ あえて伝説を読み解く

wildcatsさんのとこから引っ張って読んでたが、逆に、真の伝説の勇者だということにして読み解けないかという実験。もっとも、I氏とかK氏とか伝説にもなれない人達はどう読んでも救いようが無いですね。

X氏の伝説

第1話「得意分野」

「GUIでのプログラミングでしか（データベースプログラミングを）した事が無い」からVBが苦手というのは、ごりごりのWin32APIで、ハックしたメッセージを使ってネットワークパイプ越しに最適化したデータベースプログラミングしかしたことがないから、VB（生パイプ使うのはVB素人には不可能、僕は素人じゃないが生パイプをVBで使う方法を調べるくらいならC++で書く）では苦手。

まあ、不得意なことやるとパフォーマンスが出ないからな。

第2話「もしも……」

VBでは永遠の==ではなく、<>を使って判定したり論理演算でも&ではなくAndを使ったりというように変態記法なので、不等号を素直に記述できるかわからないので確認してみた。

まあ、真のプログラマーはマニュアルを読まないからな。

第3話「もしも……、再び」

だから、VBの記法は知らないんだったら。

まあ、真のプログラマーはマニュアルを読まないからな。

第4話「名付け親は私…」

本当は、「こんな無意味な変数名つけるんじゃねぇ、ごるぁ」と言いたかったんだが、派遣先でそんな発言はできません、と気付きました。

第5話「変わるメッセージの怪」

もちろん、真のプログラマーは、：がファイルシステムに使われているとは知らない。（少なくてもTOPS-20,10、MULTICS、VAX/VMSには無いな。;は使われているけど）

第6話「難しい数学」

真のプログラマーは数学ができない。

第7話「右は箸を持つ方」

徹夜でMC68000アセンブラで遊んでいた（真のプログラマーは68000と戯れるものだ）ので、ちょっと寝ぼけていたのだ。

第8話「釈迦に説法」

第1話の続きで、しょうがなく、VBでADOをやってるのだが、渡された仕様書がいい加減で「プライマリーキーがわからないだろ、ごるぁ」と本当は言いたかったのだが……面倒だから、SELECT * FROM TABLEでやるよ、ぷんぷん。

#メタデータくらい自分で調べろという声は面倒なのでパス

別解：データベース != RDB だ。そんなことも知らんのかボケ。RDBの場合は、SQLという気持ちが悪い言語を使うってことは知っているが、真のプログラマーはそんなものは使わない。ISAMマンセー。

第9話「謎のツール」

隠れた言葉を復元。

「プログラムが正しく動いているか（実環境に近いデータを使って）確かめたいんだけど」

「デバッガを使ったら？」

「（こいつ、本当に低脳だな。負荷かけた場合とか、イリーガルな状態のこととかなーんにもわかってないんじゃねぇのか？、とは言えないからせめて）何それ？」

第10話「日本人なら…」

まあ、最初がトグルスィッチだったから、どうもキーボードには慣れないってことで。

第11話「X …？ L'arc …？」

晶紀「それは、ハ・イ・ド(hide)」

X氏「（なんだ、読めるんじゃねぇか。気をつかって損したぜ）」

第12話「伝説は永遠へと…」

もうこねぇよ〜

_ VB -> COM -> VC++

なひさんのコメントを読んで思い出したまずいコード。

HRESULT Foo(VARIANT_BOOL bar)
{
    if (bar == TRUE)
    {
        // VBからは絶対実行されない。でもVC++からは呼べる
    }
    return S_OK;
}

まずいのは、呼び出す側のVC++プログラマも

IFoo* ifoo;
CoCreateInstance(CLSID_Foo, .... (void**)&ifoo);
ifoo->Foo(TRUE);
ifoo->Release();

なんて書いていたから。(確か、VBで作成したActiveXコントロールで、If bar = True Thenとか書いてあるとひっかっかたような気もするが不確実)
正しくは、

HRESULT Foo(VARIANT_BOOL bar)
{
    if (bar) // 勘違いしているVC++から呼ばれてもOK
    {
        // 正しく実行される
    }
    return S_OK;
}

で、呼び出しは

IFoo* ifoo;
CoCreateInstance(CLSID_Foo, .... (void**)&ifoo);
ifoo->Foo(VARIANT_TRUE);
ifoo->Release();

っていうか、Win32APIでも!FALSEが不定値というのは多いから、TRUEというdefineを無しにしておいて、

if (!Win32APICall(...)) // 失敗の判定
{
 ...
}
if (Win32APICall(...)) // 成功の判定
{
 ...
}

というのをベストプラクティスとしておきゃ良いのだが、なぜか、真かどうかを同値検査で判定するコードを書く人っているのだな、これが。

_ Subversion

これだけそこら中で見かけるのだから、よほどモノが良いか、よほど宣伝が良いかのどちらかだろう。で、当然、後者のはずはありえない。だから、機会を見つけて移行しようかな。

Subversion によるバージョン管理。

移行ツール次第のような。

_ 313

シメトリカル

_ 反EA

EAじゃない方向を考えて見る。

まず、EAの場合、全体に対して単一のデータソースを用意するというのが根底にあると感じる。

その場合、どうしても頭にひっかかるのは、プリブラムの遍在する記憶モデル（なんて言葉は無いが）だ。

中央データソースにはもちろんバックアップがあるわけだし、そのうち物理的に遠隔地に対してミラーリングすることもできるようになるだろう。東京のど真ん中と松代とか。

それにしても、ミラーじゃつまらん（とか考えるところがあれだが）し、DATに入っていたら全く即時性が無いわけで、やはり遍在してこその情報ではなかろうか。というようなのはビジネスモデルには合わないな。だから、ナレッジマネージメントのほうになるんだろう。

すると、楽しい情報のありかたというのは、ある情報に対して異なる角度からのビューが遍在するモデルで、それに対して同時に検索がかけられるシステムとか考えていくと、なんのことはなく、電話会議じゃん、とか。コンピュータネットワークならIMだな。

しかし問題は人間が持つ知識をデータとして扱うことを可能にすることが前提だということだ。だから、直接、人間に対してインタラクトするのはこの前提を無視しているんだから、なんの解決にもならない。そこで、手を変え品を変え、人間の脳みその中にしまわれている知識を外に引っ張り出し、データとして扱えるようにしようとせざるを得ない。

逆に言えば、情報をデータとして提供しないという方法論もありえるだろう。結局、情報を持ってる人間が強い。そこで、生き残り重要な規模になると、その規模を支えるだけの頭数を揃え、情報を遍在させ、個々の人間が逃げようと追い出そうと、全体の情報量が失われないようにせざるを得ない。この状態を一般に、人は自分が組織の中の歯車になったように感じる、と称するのかも。それでも人間は移ろいやすいものだし、ふにゃふにゃしてやわらかいものだから、データとして固く管理する方向へ持ってくように圧力をかける必要はある。

いずれにしても情報は陳腐化するものだ。陳腐化しない情報には価値がないとも言える。共有できない情報には意味がないからな。そして共有化されるとそれは文字通りコモディティとなり独自性ではなくなる＝価値を失う。したがって、それを前提としなければならない。

そこで新たな情報を作り、少しずつコモディティ化しながら、常に最新の情報を握るようなシステムを作ることが重要（誰にとって？）となる。ここで忘れてはならないのは、真に情報を作る必要はないということだ。省エネですますには、その組織にとっては未知でしかも価値がありさえすれば良いのだから、必ずしも無から生み出さずとも、右から左へ持ってくるだけで良い。後はそれをいかに組み入れて、陳腐化させ、手コマから外し、次の情報を仕入れる（もちろん生むでも良い）かだ。

ところがこの構造は、なんのことはなく、ビジネスそのものでもある。結局、マンダラやフラクタルのように、ある一部分を取り出せば、同じ形が見えるだけということだ。火の鳥の未来編だかで銀河も原子も同じだという幻覚を見せるところがあるが、ちょうどそんなもんだろう。

したがって、そんなことは考えずとも、自然に振舞っていれば勝手にそうなるってだけのことだ。

だとしたら、情報ってのは大して面白いものではないな。

ただなすこともなく、長く生きながらえることなぞくだらぬわ……今ごろ気付くとは。クワッ!!

――白土 三平「栬身黒人黒潢（漢字が無いぞ）」

_ スマートクライアント原稿公開

WEB+DB Press Vol.14に掲載の原稿の手元のテキストを裏庭に流し込み。図やリストは徐々に復元する予定。

追記：あらためて読み直すと、ホント、.NET Frameworkは良くできてるわ。gzip以外は全部揃ってるもんな。しかし、いきなりサードパーティリレイとか書いてるが、ちょっとわからんだろうな、と反省。

_ Subsevenversion

バカ往く読んで、社内CVSサーバーの移行はとりあえず見合わせることにする。

何より一番不安なのが枯れていない点です

すげー説得力。まあ、MSじゃないんだからVer3まで待つ必要は無いだろうが（でもVer6超えると余分な機能が付いて結局互換性が無くなる罠）、もうちょっと様子を見るって事で。

Apacheも1.3で運用してるしなぁ。

ちなみに、CVSに行くと"Looking for more development tools?"として、Subversionがリコマンドされてるのがおもしろかったり。ScarbってのはBTSなのか?

_ JavaScript

そうなんだよなぁ、と。
ああいうルーズな言語で、わざわざvarで宣言するのは明示的なグローバル変数と重要な(着目すべき)ローカル変数、に限定と自分でコーディング規約決めてまあ、こんなの書いてしまったわけですよ。

<script>
var currentConcern = null;
function checkKeyword(k) {
  for (i = 0; i < k.length; i++) {
    if (k[i] == "machgogo") {
        return "tatsunoko";
    }
  }
  return "hachinoko";
}
...

もうね……推して知るべし。

_ 車輪の再発明

なぜそんな無駄なことをする？

そこに車体があるからだ。（早く、運転したいのよ）

思いつきで書いたが、なんか真理を見つけたようだ。

たいてい、再発明する場合って、再発明だって意識してやるもんだ。っていうか、おいらはそうだ。

この場合、なんで再発明するか、その結果として何ができるか、ヴィジョンがあるんだな。それが車体ということだ。

真の発明は、まだ車体がどんなものかさえわからない状態でやる。

まあ、当然だが、車輪を作ること、それ自体がおもしろいからだ、というのが根底にあるわけだが。

_ ;

半日、無意味に費やしてしまった。

教訓：サンプルに読みやすい例だけを書くと、;を見落とす。

_ 新しいオモチャ

rjb。Ruby-Java-Bridge。

JNIを使って、RubyからJavaを呼び出す。

やってないこと：たくさん。

たとえば、メソッドシグネチャのチェックが大甘。

Rubyのオブジェクトの移出は手付かず。

配列の変換も後回し。

一応、役には立たないけど動くことは動く。

金曜の夜というか、土曜の朝からだから、2日の作業としちゃこんなもんが、僕の限界のようだ。

_ 寝坊

うひゃー、寝過ごしたよ。だから会社、休む。
rjbとWin32OLE(もちろん、参照してる）の相違。

• Win32OLEはWin32OLEのインスタンスが、COMのインターフェイスのインスタンス
• Rjbのインスタンスは、Classのインスタンス
  (GCの考慮が相変わらずだが、これはロード済みクラスのハッシュを持つことですぐに解決するから後回し）

使い方

予定だけどな
Rjb.load        # JVMのロード（自動でやればいいんだけど、一応あるのはテストの必要性）
JavaClass = Rjb.new('package.JavaClass') # Classのロード
jcInstance = JavaClass.new()             # インスタンス生成
jcInstance.some                          # メソッドは当面missingからだ。
jcInstance.Prop = 'hoge'                 # setPropから生成予定
p jcInstance.Prop                        # getPropから生成予定
jcInstance.invoke('method-name', 'method-signature', ...)
                         # overloadされてる場合、どこまで自動判定可能かがあるし
jcInstance2 = JavaClass.new_with_sig('II', 5, 10)
                         # テストの必要性からこっちは実装済み
class RubyObj
end
ro = RubyObj.new
Rjb.add_interface(ro, 'package.Interface') # 予定だけどな
jcInstance3 = JavaClass.new(ro)          # 移出できなきゃな
Rjb.unload               # JVMのアンロード。こっちはloadと違って必要な気がする

JNIの仕様を読んだのが一昨日からだから、まだ、こっちの世界が向こうでどうなるかわかってない（まだ読んでない）から、最後から2行目は違う方法になるかも。

_ TestUnit

使えよな。わかったよ。

_ うーむ

newでクラスをインスタンス化すると、いくらでも重複ロードできちゃうな。まあ、いいか。そんなことするやつが悪い。

って言うか、loadをJVMのロードに割り当てたのが敗因か。

_ なぜだ

TestUnit作ると、妙に実装が計画的になるぞ。って、先にテストを書くからってのが1つ、利用方法を先に考えるからってのが2つ目、と、あらためて再確認。

_ 0.0.2

rjb。Ruby-Java-Bridge。
staticメソッドの呼び出し。
しみじみと、

 if (x)    ---ここから
 {
 }         ---ここまでコピペしたもんで次の行のelseを忘れた
 if (y)
 {
 }
 else
 {
 }

で、時間を無駄にするとは……(処理は排他だがx && yという条件があるため)……伝説は遠い（あれは処理が無駄ってだけか）。
配列は未実装。
Rubyからの移出も未実装。
しかし、しばらく中断。

_ 偶然の悪魔

13日の分が更新（unoさんが突っ込み）されてたから読み返してみたら、なんか、情報占有->共有の陳腐化戦略（というより多分、P2Pのなにかについて考えてたみたいだが）のすぐ次の項目で、1年前の原稿を裏庭で陰干しみたいな流れになってる……馬鹿げてタイムリーなことだ。

_ rjb-0.0.3

結局、1次元配列の処理(割と手抜きだが)まで実装。残りで重要なのは、オブジェクトの移出。

しかし、Win32では動くのに、Linux上ではコアになってしまうという罠。

どっちも1.8.1と1.4.2の組み合わせなんだがな。

しかし、当分、ここまでの予定。

って言うか、もうRAAに入れちまうか。と思ったけど、ドキュメント書いてからにしよう。

_ Windows XP

何気なくシフトキーを乱打（KVM切り替え器用のコントロールキーだと思ってーー見ずにーーやってたからだが）してたら、妙なメッセージがニョロンという音ともに出てきて一瞬びびる。

こんな機能があるのか。（手がふるえる人と自動判断したということか？）

_ Windows2000

でも、5回シフト叩くとメッセージが出るな。

_ rjb

メソッドの戻りがオブジェクトと、オブジェクト配列の場合の処理を追加。

ZIPの名前は変えてないが中身は0.0.4。

って言うか、これをやってちゃまずいんだが。

_ 高校の頃の友人に会ったり

今日(昨日だけど)は楽しかったです。ごちそうさまでした。

_ rjbって何？

こんなことを考えてる。まだ移出できないから予定だが。
java.exe(Win32の場合)で起動するかわりに、ruby.exeで起動する。
で、Java側でRubyのスクリプト書いて何かすれば、Rubyに送り返せるからそこでevalするとか(スレッドの問題は付いて回るけど)。 Inversion of Controlですな。
まあ、普通にRubyのUIとしてSwing使うとか、いろいろ応用はきくはずだ。

 Hoge.java
 package com.example;
 public class Hoge {
    public static void setRuby(Ruby r) {
       ruby = r;
    }
    public static Ruby getRuby() {
       return ruby;
    }
    static Ruby ruby;
    public static void main(String[] args) {
      ...
      // 自分を操作するスクリプトを送り込む
      ruby.run("h = hoge_class.new();" +
               "h.start_foo();" +
               "h.zzzzzz();");
      ...
    }
 }
 //
 hoge.rb
 class JavaPipe
   def run(script)
       eval(script)
   end
   ...
 end
 hoge_class = Rjb.new('com.example.Hoge')
 hoge_class.setRuby(JavaPipe.new)
 hoge_class.main([])

_ rjb

突然インターフェイス大変更。
ZIPの名前は変えてないが中身は0.0.5。
newされてまずけりゃ、無名クラス。
newさせたくなけりゃ、モジュールファンクション。
というわけで、

include Rjb
load
jstr = import('java.lang.String')
...
unload

これなら、明示的な変換はexportだ。
って言うか、今週はこれ以上、いじらないぞ。

_ UMLの可能性が見えるかなぁ？

翻訳者がいっぱいいるため、船頭多くして……みたいな訳本になってるため、Amazonでは星が少ない。が、一応、定番書みたいだな。

役に立つか？ と訊かれると、大して役には立たない。なるほど、こんなふうにモデリングしてくのか、という意味ではそれなりに面白かったとは言える。正直に言うと、おもしろい。おもしろいという点が逆に、現実世界に意味ないんじゃないか？ と感じる点でもある。世の中、そんなに単純かよ、とか。

前半が解説(読むもの)。後半がパターン集(必要に応じて拾い読み)。

お金があれば、買っても後悔はしないとは思う。

#ソフトウェアの本じゃなくて、ビジネスモデリングの本だから、最上流ってこと。

そんなもの何の役に立つかと思うのは正常な感覚だが、ワークショップ的にやってみたことがある経験からいくと、これはすごくおもしろい。馬鹿馬鹿しいほど明晰に、ビジネスにおける金と情報と物の流れが見えてくる。そこがおもしろ過ぎてやばいんじゃないかと感じる点。

逆に言うと、この手法を身につけてクライアントをたぶらかせば、イチコロなんじゃなかろうか。

でも、この成果物がどうシステムになるかというと、まったくわからない。

第10章「ビジネスアーキテクチャからソフトウェアアーキテクチャへ」なんてのもあるけど、これを冷静に読めば……と書くために読み返してみたら、おもしろかった。パターン（ビジネスモデルのであって、システムのではない）集の後にあるから以前は読み飛ばしてたのかも。具体性にはその前の記述と異なり乏しいわけだが(でもこういったことを記述してみせるということに意味はある)、それはこの著者が最上流のコンサルだからしょうがなかろう。

良い点：UMLでビジネスモデルを記述するという手法により、非常に明晰でわかりやすくビジネスをシステム的（定義付けし、分類し、整理する）に考えることを示している。

悪い点：で、それがどうした？ という疑問が常につきまとう。

#っていうか、用語が属人性（好きだね、この言葉）を帯びてるから、同じ言葉で示す概念が人によって全然違うのがおもしろい。

_ COMの再入問題

Excelが終らない件とは関係ない話。

STAでメッセージポンプを回すCOMのサーバーを作ったとする。

HRESULT foo() 
{
   m_pOuterProcess->bar(); // 外部プロセスサーバーへ問い合わせ
   return S_OK;
}

この場合、外部プロセスサーバーの呼出し中にメッセージポンプが回る。ここでは他のメッセージを受け入れる。なぜならば、コールバック（イベントの呼び出し）が行われる可能性があるから。

しかし、もし、fooというこのメソッドの呼び出しがシリアライズされなければならないとしたら、話がいきなり厄介になる。

同期させるわけだからと、

HRESULT foo() 
{
  m_criticalSection.lock();
  m_pOuterProcess->bar(); // 外部プロセスサーバーへ問い合わせ
  m_criticalSection.unlock();
  return S_OK;
}

とやっても、なんの役にも立たない。というのは、STAなんだから、外部からの呼び出しは、このスレッドに対して行われるからだ。自スレッドの同期オブジェクトのロックは待ち状態になるわけにはいかないから単純にスルーされてしまう（ロックカウントは上がるはずだけど）。

つまり、再入されてしまう。

ここで、fooがインスタンス変数をいじるととてもまずいことになる。で、それに対応できない場合は、再入不可能だから気をつけて下さい、とクライアント側が同時に呼び出さないことを求めることになる。

これを回避するには、IMessageFilterインターフェイスを実装して、メッセージポンプに介入する必要がある。が、今度はデッドロックの可能性が出てくる。ASRですな。

_ ものを作るってこと

まあ、とある事情があって、待ち状態になる機会が結構な頻度である。たまたま、数10冊ほど本が置いてあるから、最初のうちは矢野徹が翻訳（とは思えないから下訳の日本語化ということだろうが）した子供用モンテクリスト伯とか読んでたんだが、あるときから見えなくなったもんで、何気なく町工場がどうしたってのを読み始めた。

ら、こいつが結構、ツボにはまった。

たとえばこんなエピソード。

プロペラの依頼が来たんだが、すごく固い上に薄く削る必要があったり大変なんで、忘れちゃったけどなんかの合金で固めて旋盤かける方法を考え付いて（この合金がミソなんだが忘れた: 3/22追記 Uアロイという合金。なお、このエピソードは198898の本の中で、今から20年ほど前のこと、とされている。あおしまさんの指摘が正しいと思う。センジュはメーカー名だから）削ってたら、別の町工場の親父が見てる(町工場ってのは表から中が見えるらしい)。で、近づいてきて削られたクズをペロリとなめて、鉛が少ねぇな、だか、変な半田だな、とか（3/22追記 実際には噛んでみて「錫が少ねぇ」。錫は噛むと鳴るので熟練すると噛んだだけでわかるらしい。またその親父は勝手に覗いていたんではなく、まだ珍しかったNCマシンの見学のために来ていた）。

そんな芸当をするのは、年期が入った職人だけだから、そりゃまじめに相手をせざるを得ない。で、いや、こりゃ半田じゃなくて、プロペラ削るんでいろいろ探して見つけたなんちゃらって合金で、こいつを使うとこれこれって理由で具合がいいんだ。どう具合がいいかっていうと、最後の仕上げの時になにかをするとぱかっと割れてプロペラだけが取り出せる、とか説明すると、親父、そりゃいい話を聞かせてもらった、じゃ、おいらのやつも教えてやる。

新幹線の下につけるステンレスの箱を作れと依頼が来たんだが、話を聞くと箱じゃねぇ。穴がそこら中にあいてるから、早い話が網なんだな、これが。

で、穴をあけたらうまく折曲がらない。先に折ると穴がうまくあかねぇ。鉄板に付けたらうまく曲がるがうまく取れない。で、おめぇさんならどうする？

うーん、考えないとわからんな。

そうよ。で、おいらも考えながら歩いていたら、表具屋の店先ではたと気付いた。で、和紙を買ってきてだな、表具屋に張ってもらったのよ。これで自由に加工できるようになったってわけだ。ありゃ、丈夫だからな。で、最後は水にどぼんだ。

なるほど、そういや、障子の張り替えは昔は川でやったもんだったな。

そのとおり。お前さんのその合金と同じだよ。

Amazonのブックレビューを読むと眠たいことが書いてあるが、デペンデンシインジェクションとかハリウッドメソッドなんてのは、まさにこういうことだ。加工しにくい素材を扱う場合は、外し易い補助材を使うっていうデザインパターンだな（それだけじゃなくて素材の発見っていうストーリーもあるな）。

_ 今思ったこと

jni.hはきれいだ。
たとえば、jvalueという共用体が定義されているが、jdoubleはdだし、jintはiだ。
こういう名前って、センスが無いやつにやらせると平気でdoubleValueだのintValueだの馬鹿気た名前をつける。もっとも全体の長さに合わせるべきだから、java.lang.IntegerのintValueとかはしょうがないとは思うが。
というわけで、たまに、次のようなゴミのようなプログラムを見ることがある。

if (hoge) {
  long currentDepositAmount = accountInfo.getDepositAmount();
  newAccoutInfo.setDepositAmount(currentDepositAmount + ビジネスルール);
}

バカですか？
たかだか数行のスコープで、しかも、ゲッタとセッタのpublicメソッドから、何をつかんでいるかは明々白々にもかかわらず、long currentDepositAmountなんて馬のイバリみたいな名前をつけるなんて、なんの意味もありませんな。
もし、こう書かなければ理解できないとしたら、それを書いたヤツはpublicインターフェイスの名称がどういう意味を持つかわかってないと思いこんでいるのか、さもなきゃ、ソースを読むやつをバカにしているかのどちらかだ。
まともな人間なら、現在のアカウント情報に保持されている供託金を新規アカウントの供託金にビジネスルールを適用して突っ込んでるとわかる。もしわからないと仮定するのであれば、accountInfoだのgetDepositAmountだのって名称そのものがそもそも無意味だってことだ。
当然、こんな場合は

if (hoge) {
  long l = accountInfo.getDepositAmount();
  newAccoutInfo.setDepositAmount(l + ビジネスルール);
}

のほうが遙かに良い。こんな短いスコープの変数に時間を0.05秒でも余分に使う閑があったら、目でも休ませてなってことだ。
つまりだ、これは「メリハリ」をつけるってことだ。
子供の作文ってのがある。 「朝起きて、歯を磨いて、顔を洗って、ごはんを食べて、牛乳を飲んで、頭をかいて、靴下のにおいをかいで、猫を撫でて、ヘリコプターに乗って、へそでチャをわかして、学校に来て、先生に挨拶をして……」
すべてを同じ調子でやってたら、バグが入ってても見つけにくいじゃないか。
ここぞってとこは強調し、どうでも良いところは見えなくする。
それがメリハリをつけるってことだ。
ローカル変数なんてのは、そのブロック内だけでしか意味を持たないどうでも良いものなんだから、そんなものに有意味な名前をつけてはいけない。
もちろん、例外はあって、

for (int outer = 0; outer < dendekodennsuke.getFukusuke(); outer++) {
  for (int inner = 0; inner < denndekodensuke.denkihaTaisetuni(); inner++) {
 ....
 innerループがある特定の数でかつouterループの何番目かの時点では非常に特殊なことをする
 ...
  }
}

ってような場合に、int iとint jってのは「非常に特殊なこと」をする条件がわかりにくくなる。こんな場合には、コンテキストが明白になる名前をつけるべきだ。
しかし、「こんな場合には……べきだ」ってのはルールとするのは曖昧だ。
曖昧なことはルール化できない。であれば、原則論を主としなきゃならないのは当然の帰結となる。
したがって、ローカル変数は、1文字か2文字にして、ブロック毎に作れ。ブロックはできるだけ5行長くても10行。それを越えたらルールを単位としたメソッドとして別立てにし、メソッドコメントとしてルールを記述せよ、ってことになる。ちなみにメソッドレベルのローカル変数はもうちょっと長くしたほうが良い。この例だとdepositAmtとか。まあ、currentDpositAmountでもいいけど。でもdepositは長すぎるから3文字短縮語辞書を作っておいたほうがいいだろうな。curDepAmtとかだな。つまり、3文字略語の複合がメソッドレベルのローカル変数にはちょうどリズムが良い。
まあ、ローカル変数名が5文字を越えてたら、バグの前兆ってことだ。

_ 1文字変数名の規則

i, j これは古いFortlan（綴り忘れたから違うような）から持ち込まれた由緒正しい変数名の規約で、整数に使用する。その後、iterationの意味も含まれるようになったため、for文のインデックス値に利用する。

c これは一般には文字に使用するが、別解として、counterの略でint c = 0; ... c++;なものに(iterationの場合は、i)に利用する。

ただし、C/C++のようにポインタのサイズが重要になる場合には、

cb (counter of bytes), ci (counter of ints), cs (counter of shorts)などとする。このへんは由緒正しいハンガリアン由来。

n ニューメリック一般だが、iがiterationに取られるため、intを示す。

o, d, f, l わからないやつは言語仕様を読め。というくらい当然のように利用する。

p pで始まるすべてだが、oと異なり途中で参照が変更される可能性を持つオブジェクトを示す場合に使用する。

e 例外

r rで始まるすべてだが、特にレコードの概念を示す場合に利用する。

f これはboolean。bはbyteに利用する。この場合のfはflag valueの意味。これも由緒正しいハンガリアン由来。ただしFileの概念を持つ場合にはそちらに優先的に与え、同一ブロック内で真偽値が必要になる場合には、例外として意味的な名称(continueToReadなど）を真偽値に与える。というか、制御に利用する変数名は実際には長い名前にしたほうが良い。そのほうが妙な修正による誤った流用を回避できる。ただし、つい流用したくなるってのはブロックがでか過ぎる証拠。

x, y, z ……i, j が不足した場合に利用しても良いが、そんなにfor文を重ねてはいけない。むしろ、数値計算の過程で利用する。

np, lp, これは使うべきではない。あまりにも歴史的。

これ以上ローカル変数が必要になるとしたら、書き方がおかしい。それはブロックやメソッドを分割しなければならない。

追記：まあ、まじめに考えればすぐにわかることだが、オブジェクトはアイデンティティによって区別されるんであって、変数名で区別されるわけじゃない。そこがわからないと馬子にも衣装とばかりに変数名に凝ってしまうんだろう。だが、値が入ってるならともかく（というか、値自体がテンポラリな存在なわけで）しょせん参照に過ぎないわけで、まったくオブジェクトそのものとは関係は無いわけだ。したがって、読みやすさと記述力を優先するのは当然。

_ >900

よっしゃわかった。じゃあ、longの先頭2文字で

long lO = 10;

とか（大文字のOは勘弁だな）。

#実際には、longを取る値であれば、入る内容の略語を使ってcntとかamtとかqtyとかすることが個人的には多い気がする。あと、ニュートラルな場合（intでもlongでもどっちでもいいけど大きいことはいいことだでlongとなっているような場合）にはnが多いな。

ちなみに、jni.hでは、jobjectがlで、jlongはj （iの次だからか?）となっている。

っていうか、ローカル変数まで長い名前を付けたがるのは、メインフレーム方面から流れてきた連中なんじゃなかろうか。だから、Sunのコーディング規約（多少のブレはあるが、Unix流儀）に文句をつけるんじゃなかろうかね。

古いCOBOLにはローカル変数っていう概念がないから、なんでもかんでもグローバルな変数と同一の流儀で変数名をつけようとしでかすんじゃなかろうか。

ちゃんとスコープを理解してるのかなぁ。

略語の問題は、人によってln, len, lgth, lg, とかいろいろあるから困ると言われているが、スコープが限定された変数はなんでも良いってのが最初にあるわけだから、どれでも構わない。つまり、困らない。

あたりまえだが、インターフェイス名やそのメソッド名にCalAMt#ccとかするのはだめでしょう。やっぱりCalendarAmateur#CCompileとか付けなければわからないし。

_ 続変数名

というわけで、ローカル変数名のデフォルトを無意味1文字変数とすると、次のように論が進められる。

前提：ローカル変数は1文字か2文字で付ける。(実際は、もっとゆるいのだ。別にBook bkでもBook bookでも構わない。この場合、Book bokはありえないとは思うけど、それでも構わない）

例外：特に着目すべき変数についてはフルスペルやそれに準じた変数名をつける。たとえば、

Book myGrandFathersFavoriteBook

この方法論は、次の方法論より、有効だ。

前提：ローカル変数であってもフルスペルな変数名を付ける.

Book myGrandFathersFavoriteBook

Book myGrandMothersFavoriteBook

Book myFatersFavoriteBook

Book myMothersFavoriteBook

Book myBrothersFavoriteBook

Book mySistersFavoriteBook

Book mySonsFavoriteBook

(ふむ、さらに悪いことにコピペ地獄に陥ってるな)

例外：for文のiくらいは勘弁してやる。

なぜ有効かといえば、例外的な記述は違和感を持つからだ。そのためそれが注目すべきものだということが明らかになる。

ところが、後者の場合、せっかくの例外的な状況が、まったく有効に活用できない。

それは

極上の料理にハチミツをぶちまけるかのごとく甘い思想

――範馬勇次郎

であろう。

_ 参照

これはOASISのXML Common Biometric Format TC Public Documentsだったりするのだが、ここからCommon Biometric Formatを見ると、簡単に

biometricObject.biometricHeader.format.formatType.BindedPrimaryAccountNumberっていうようなオブジェクトが集約したオブジェクトが集約した……オブジェクトの属性名とかが出てくるわけだ。

で、BindedPrimaryAccountNumberっていうのが正式な属性名になるんだが、もし変数名としてaccountNumberってのをテンポラリに使おうとしたら（それでも死ぬほど長いが）、それは既に略してるんだよね。

で、まあ、手元にメソッドの引数としてbiometricObjectのインスタンスが渡されたとする。で、いちいち

biometricObject.getBiometricHeader().getFormat()....

なんて書くのは何がなんでもくだらないから、部分で切り分けることになる。

BiometricHeader h = biometricObject.getBiometricHeader();

で、ここで、hと書かずにbiometricHeaderと書くと

BiometricHeader biometricHeader = biometricObject.getBiometricHeader();

だ。

こんな行がずらずら並んだ、真っ黒なソースから問題点を探すのはばかげている。

というわけで、

BiometricHeader header = biometricObject.getBiometricHeader();

としてみたとする。

で

header.getFormat().getFormatType()....

と書いたほうが

h.getFormat().getFormatType()....

と書くより、「読みやすい」とか「理解が促進される」とか言い出す人がいたら、やはり何か変ですな。

プログラム書いたこともなければ、読んだこともないんじゃなかろうか？

すると、恣意的なルールを持ち出したくなったりするかも。

ゲッタが4個以上になる場合は〜とするが、2個ならば〜とか。

だが、ルールは少ないほうが覚え易いし、実効性を持つ。そうじゃなければ破られるだけだ。破りたくなるようなルールは間違っている。

ショウカの法三章ってやつだ。

というわけで、ブロック内での変数（だいたいオブジェクト指向言語で記述する以上、変数の役割はキャッシュか計算の中間結果の保持用だ）の名前なんて短くても問題なし。

#まあ、可能性としては、乏しい語彙の世界でしかプログラムを記述したことが無い人間がルールだとか言ってるんだろう。としか考えられん。

というわけで、豊富な語彙の世界でプログラムを記述したり読んだりしているおいらが言っておこう。

「変数名は短ければ短いほど良い。」

#追記：当然だが、スキーマ上の要素名が長いのはまったく問題ない。こっちを省略させたり短くしては本末転倒だ。

_ 簡潔な記述のためのキャッシュ

ここで言うキャッシュっていうのは、たとえば最適化とかを意識して行うことではなく、単に短くための道具のことだ。
a.getB().getC().getD().getE();
とある場合に、
b.getB().getC().getD().setE(a.getB().getC().getD().getE());
と書くかわりに、
b_d.setE(a_d.getE());
と書いてある方が、単純に読みやすい。それは、余白が多いからだというのはいい?
で、この時に、aがソース、bがデスティネーション（クラスは同じ）という場合に、
dst_d.setE(src_d.getE());
と書くとする。
で、ここで、
desination_d.setE(source_d.getE());
のほうが、本当に、dst_d.setE(src_d.getE());
より望ましいですか？ （と、具体的な読み手が想像されると急に丁寧語になってみたり）
で、実際には、dとしているがこれが、AccountOfTheCustomerっていう要素名だと
dst_act.setE(src_act.getE());
というよりキャメルケースで、
dstAct.setE(srcAct.getE());
より、
destinationAccount.setE(sourceAccount.getE());
のほうが良い？
しかも、実際には、ここでAccountと略しているが、同じXMLの兄弟要素に、AccountOfThePublisherとかAccountOfTheShoppersとかが並列しているとする。
その場合、Accountという省略は、「わかりにくい」。なぜならば、どのAccountかが略されているからだ。
すると明晰さを求めるためには、
destinationAccountOfTheCustomer.setE(sourceAccountOfTheCustomer.getE());
で、こうなってしまえば、最初に行った「 ここで言うキャッシュっていうのは、たとえば最適化とかを意識して行うことではなく、単に短くための道具のことだ。」が無効化されてしまう。
というところで、落としどころとして、まあ、兄弟要素には目をつむって
destinationAccount.setE(sourceAccount.getE());
としたとする。
だったら、そんな「落としどころ」はやめてしまって、
dstAct.setE(srcAct.getE());
のほうが良いのではないか？
ってことなんだけど。
#あと、上じゃ忘れてるが、前提はスコープの狭さにあります。 #わざとクネクネカーブの道を住宅地に作り時速20Km制限を守らせようとするのに近いのかも知れない。
#変数名は短くて良いとすれば、よろこんでhとかsとかを使いまくるだろうと前提しているわけだ。
#反省略/フルスペル派は、やっぱり放っておけば、そうなって荒れると危惧してるだろうと想像できるから、この前提は良いと思う。
で、実際に書けば、よほどセンスが無ければともかく、iとかsとかnとかで100行もあるブロック作れば、いったいおれが使っているこのsはなんだったか? となるんじゃなかろうか。
つまり、短い変数名は狭いスコープを強制し、かつ、「放っておけば省略した短い変数名を使うんじゃ無かろうか」の危惧のもとになる人間精神の方向に沿ったルールだと思う。変数名をどうつけるかより、スコープを短くとり、実行している処理を局所分割してあるほうが、後からソースを読んだ場合の読みやすさは上だと考えるというか、実際に読みやすい。
しかし、ひねくれた人間はいるから、短い名前をつけろ、と言っているのに、昨日の最初の引用のような、どう考えてもメソッド名をコピペしたような変数を作って、しかもたった5行くらいのスコープで使われるとたまらんなぁ、ということだったり。 などとやっている間にも、1000行くらいのメソッドに変数名hだのを使ったソースが量産されているという罠。
にも、かかわらず、1000行も真っ黒なコードで埋められるよりは、スカスカしているほうが読みやすいから、短い名前のほうがやっぱり好きだ、となるんだけど。 （っていうか、1000行もあったら、変数への代入が出てきた時点でメソッド呼び出しに変更していくしかないだろうな）
#しかし、世の中にはインテリセンスとかメソッド補完といったおそろしいツールを装備した開発環境があるから、素直に記述させると、
b.getB().getC().getD().setE(a.getB().getC().getD().getE());
が編集画面の全体を覆ってしまうという罠。
それと同時に、兄弟Accountがいくつあろうが、順番に処理するのであれば、

AccountType accounts[] = getAccounts(a);
for (int i = 0; i < nrOfAccount; i++) { // nrOfは良く使うな
    accounts[i] = null;
}

の都合2カ所しか使われない変数のために、accountsなんて打ち込むのはあまり意味がないと思うのは事実。
そのいっぽうで、メリハリってことに関しては、

AccountType as[] = getAccounts(a);
for (int i = 0; i < nrOfAccount; i++) { // nrOfは良く使うな
    as[i] = null;
    if (i == PUBLISHER_ACCOUNT_INDEX) {
      publisherAccount = as[i];
      ....(publisherAccount);
      publisherAccount.xxxx(ssss);
      .... = publisherAccount.getxxx();
    }
}

のほうが良いと思うのだが、その瞬間に、この内容は、

AccountType as[] = getAccounts(a);
for (int i = 0; i < nrOfAccount; i++) { // nrOfは良く使うな
    as[i] = null;
    if (i == PUBLISHER_ACCOUNT_INDEX) {
      setupPublisherAccount(as[i]);
    }
}

というように、メソッド名によって吸収されてしまうのであった。 で、追加があって、setupPublisherAccountというか、最初の要素名にあわせればsetupAccountOfThePublisher()という名前になるわけだが、このメソッドは名前からいっても特定要素の関心空間だってのは自明だから

private void setupAccountOfThePublisher(AccountType a) {
      ....(a);
      a.xxxx(ssss);
      .... = a.getxxx();
}

となってしまう。これはイヤなんだろうなぁ、と想像できるが、ここで引数がAccountOfThePublisher以外の意味になることはありえないんだから、暗黙のselfが欲しいくらいでaと書くのさえばかばかしく感じるので、(AccountType account) { とはやはり書かない。
というか、自動生成じゃなければ、こんなメソッドはAccountTypeクラスに入れたいところだがよく考えてみればそれはおかしい(AccountOfThePublisherという特定の要素に関連）のでインスタンスの特異メソッドであるべきなんだろうがそんなものは無いから（たった1つの初期化メソッドのために無理矢理AccountTypeへのデコレータを作ってそこに入れるとはしない）、ここではコントローラに持たせてしまっているから仮引数なんていうものが必要になるのであった。
でも、copyAccount(AccountType source, AccountType destination);
くらいだとsrc,dstとする必要もないようには思うので（しても全然良い）、そのメソッドの処理範囲によって仮引数名の長さが決まる（が、こんなのは恣意的なルールだから、ローカル変数と異なり、メソッドレベルの命名規則の適用ということで、aは原則だめですなぁ、となる）。

_ ふむ。

適切な名前が付けられない、キャッシュ的なlocal変数を作るハメになったら、どこか、何か理解や設計の間違いがある。

実は同じことを言ってるように思える。

本来は、local変数というのは、パラメータやループのインデックスくらいしか出てこないものなのだ。これは同じ認識だと思う。

その出てこないほうがいいし、出ないようにもできるんだが、そこまでやり過ぎるのはかえって無駄であろうと判断した場合（たとえば、上のsetupAccountOfThePublisherメソッドをこの要素限定にするためにAccountOfThePublisherTypeというクラスを作るというようなこと）に、そうは言っても適切な代名詞を使うべし（って、srcはまさに3文字略語だと思うんだけど。だったらhdrでもいいじゃん）と考えるか、そんなの使い捨てなんだから短きゃ短いほど良し、と考えるかって「ここまで認識が異なる」ってほど重要な点かな（もちろん、重要なんだけど、後述）。

本質的にはどうも一致しているんだが、枝葉の部分で異なるってのがそんなに重要かと聞かれれば、「表現」ってのはまさにそれだ。

同一の内容を書いた文書であっても、ですます調、である調、2ch調、べらんめえ調で、全然、印象が異なる。当然だ。

で、おそらく、一般論としては「文語」であるべきだということなのであろう。ここが認識の相違で、僕は「口語」のほうが読みやすいと感じているのだ。厳密度は微妙に（スカスカすることは逆にノイジーである）口語のほうが落ちるのだが、そのかわりに文語には無い、リズムが生まれると感じているからだ。つまり、喋るように記述せよ、ということだ。

困ったことに、こと本質ではなくて表現にかかわる意見の相違ってのいうのは意見の一致を見ることは難しい。というか、あまり意味がない。だから仮に一緒に仕事する機会があったら、じゃんけんか多数決で「コーディング規約」を作って遵守するってことになるだろう。その時は、グーを出してください。僕はパーを出します。

_ 320

さっさと、土曜と祝日が重なったら金曜にずらしてほすい。

というか、別に春分の日や秋分の日が12:12の必要ないから、他のと同じように月曜に回してくれると楽なんだけどな。

しかし、天皇誕生日は絶対に月曜に回したりはしないだろうな。（誕生日だし）

と考えると、金曜にずらすのが良いと思うんだが。

_ 楽譜の疑問

買うこと（お金をはらうこと）はやぶさかじゃないんだが、なぜ、テキストのようにフリーでは出回ってないんだろう？

たとえば、バッハのインベンションや平均率やフーガの技法（AOF）やゴルトベルク変奏曲とか、ベートーヴェンのソナタとか？ 別に西欧だけのものではなく、人類の遺産だろ？

チャイコフスキー（メモ）

PDF化する労力のため？

楽譜のデジタル化って専有技術しかないのか？

XML-SCOREとかって規格は聞かないし。MIDIがそれにあたるのかな？

_ COM is LOVE

1998

_ 久々に映画

ペドロコスタのヴァンダの部屋。

友人に誘われて。そいつによれば、アテネに見に行ったんだが、映画が終って出ようとしたら、誰一人として立ち上がらない。その場にいた連中はどうやら新たな才能の発見の場に立ち会った感動で腰が抜けたらしい。

うそつけ。単に落ちただけじゃないのか？

とは言うものの、全員が落ちたとしてもそれはそれで只者ではあるまい。

というわけで、3時間しか寝ないで見に行って、見事に落とされたが、すごい作家だってのは間違いない。

冒頭、いきなり2人の女が汚いベッドの上でアルミフォイルを使うとこから始まる。とにかく光が良い。で、クレジット。シャワーを浴びる男。で、2シーン過ぎて、窓から薄く光がさす部屋のシーンで、その男が体を拭きに来るのだが、全身から発散される湯気が光にからむ。すげー。湯気だよ。湯気と窓からの光。おむつを替える母親。野菜を売ってるんだかなんだか、良くわからないが街をうろつく。半分廃墟。ドアが無い家。屋根から砕かれてドガーと塵埃が降り注ぎ後から光が入り込む。半分に割れた家。今度の家はドアが無い。2階の部屋は……だから戸締りは万全だ、だがドアが無い。

狭い室内撮影が多いのでベッドで寝転んでアルミを使う以外はほとんどがバストショットなんだが気にならない。徹底して固定されている。人間は話にしか出てこない姉夫婦、本人、妹、今の親父と話にしか出てこない親父、島から来た人、そしてまた船を乗り換える。しかし、落ちたので全体の1/100も見てないんだろうな。ルースってのは光の意味だ。

エンドクレジットの直前の暗闇で弦楽。エンドクレジットは完全なる無音。

落ちたのはしょうがないが、映画の価値が落ちたわけじゃない。次の機会には全部見よう。

メイ。予告編。デコボーでかわいい。

_ 評価順

そういや、仕事を始めた頃、ボトムアップアプローチ（サブルーチンの1番リーフにあたる部分から作っていって最後に幹を作る）てのと、トップダウンアプローチ（最初に幹を作って最後に葉を実装/設計する）てのの2種類があります、みたいなことを教わった。

で、とっくの昔に会社を抜け出して某所でどうも偉い人になってるらしき先輩がボトムアップの得意な人で、作りかけのプログラムを見るとサブルーチンがぼこぼこあるだけなんだけど、最後はカチッとそれが組み合わさるって感じでえらく感心したことがある。僕は1つのことに集中してやるのが嫌いなので同時進行でメインとサブルーチンを作っていくことが多かったので、とうてい、そんな開発スタイルは取れなかったが、それでもわりとトップダウン的なような感じなのは全体の流れから葉を決めていくような感じだったかなぁ。

もちろん、構造化時代の話。

今はわりとリファクタリングしながら作るからどちらかというとやっぱりトップダウンのような（全体から部分を切り出して行くことが多い）アプローチに近いのかなぁ、とはいうものの、最初にクラスにどう分割するか大雑把には決めてから取り掛かるからその意味ではボトムアップ的なような感じだが……

というようなことをruby-list見てて、急に思い出したのは、ボトムアップ/トップダウンなんて考え方自体、この10年くらい意識していないように思えたからだ。

で、オブジェクト指向プログラミングだとそのへんどうなんだろうかとか興味を持ってメイヤーの本を見ると

トップダウンのオブジェクト指向設計法を想像する人もいるだろうが、オブジェクト指向設計にはボトムアップ設計のほうがずっと合っているようである。

"トップダウン"と"ボトムアップ"はもちろん極端な特殊化である。

……

クラスは、本質的にボトムアップ的な再利用、拡張、組み合わせに適している。……したがって、継承は欠かせない要素である。

――14.1.4 ボトムアップ設計「オブジェクト指向入門」

となっているが、今となっては継承と言えばテンプレートメソッドなんていうのは、トップダウンで考えなきゃだめなような気がするんだが。とはいえ、再利用可能コンポーネントなんてのは確かにボトムアップかな？ でもユースケース主導だとやっぱりトップダウンのような。

#だから、極端な特殊化するなって。そういう分類はあまり意味がないということを書いているんだろう。ただし、解説書だから人口に膾炙した用語との関連を示す必要があったってことで。

_ で

結局、Rubyの記述スタイルは、

・スクリプト

上からだらだらいきます。スクリプトなんだから途中でdefしたっていいじゃん

・プログラム

クラスから書いていき、最後にif $0 == __FILE__でmainの実装

でFAなのかな?

って、そう書いているな、実際問題として。Javaで書くときは完全に下のスタイルだし（最後にmainの記述がある場合もある）。

ってことはボトムアップなのかな。そうみたいだな。

_ 醜いやつらは皆殺し

人気あるんだなぁ、Amazonのランキングじゃ最低の線だが（しかしなぜか絵はある）。

長島良三は良い訳者だから、当然のようにこれも良いのだが、なんでこれが人気あるんだろう？ おもしろいからか。わかりやすいからか。そうなのか？

_ 感情

るさんちまんってのはものがたりから生まれる。

だが、ものがたりがなくても、そこに光景があれば、光景は容易に情景に転化し、るさんちまんが生まれる。光景が光景たり得るのはそこに目があるからだ。

るさんちまんは、心が生み出し、心がなければ人ではないから、人がいればいやおうなくるさんちまんが生まれ、逆にものがたりも生まれる。

るさんちまんはものがたりを生み出す。

覚えてるのは、どんな気持ちでそれを聞いたか、だけ。

ということは(相手が子供かどうかに関わらず)実際に見聞きすることだ。

理性と論理を尊ぶタウリシュにして説得し得るは信徒のみとな

注）ressentimentとle sentimentを混交させていることに注意。

_ サーカス

キダムに行った。

最初、寺山修司みたいだなとか思ったが、考えたら逆だな。

妙に客の年齢層が高いが、サーカスなんて初めて（ってことはなくて小学生の頃、2回くらい行ったな、突然思い出したが札幌のなんかのお祭りで木下サーカスの派出みたいなのでオートバイの曲芸を見たっけ）なんでそんなもんかどうかもよくわからない。

それにつけても、肉体ってのは美しいものだとは、意外な発見だった。

幾つかの演目は失敗したら相当痛い目に合いそうで、こんな失敗が許されない世界ってのは恐ろしいなぁ、とかぼーっと考えもしたが、原子力発電所の制御プログラムなんてのは24H7Dで大きな破綻なく稼動してるわけだから、そっちのほうがよっぽど恐ろしかったり。

で、さらに、なんか詳細はほとんど忘れたが、ベルリンの映画作家が撮ったやつで、売れない歌手や性転換者やトランスベイターやらがどわどわ出てくる（ヨアキムだな、歌手の名前は）映画を思い出した。で、そこでブランコ乗りが、「この商売は結構、若くして引退するんだよね」とか言ってて、半年後には「ほらね」とか半身不随とかになって出てくるシーンがあったような、単なる記憶違いや摩り替えのような気もするが。なんだっけな？

で、キダムのはロープや布を使うから、見た目や小技がおもしろいが、逆に棒のブランコと違って、引っ掛かり易い分だけ、相当安全性は高いんじゃないかとか、素直に驚嘆して見てれば良いのに余分なことも考えながら見るのであった。

_ 教訓

あるクラスに特化したコレクションの命名に、格納するクラス名+sはやめておいたほうが（少なくても英語圏の人は）良い。

例証）

Although not removed, in many cases you should replace the deprecated ActionErrors with the preferred ActionMessages to ensure correct operation.

――Struts Ver 1.1 Release Note

で、これを見て、ActionErrorsのJavadocを見ると、確かにメソッドはdeprecatedされているが、コンストラクタは生きているし、ActionForm#validateも非deprecatedで、ActionErrosを返す。

が、ActionErrorのJavadocを見て疑問氷解（リリースノートの先端のchangelogを読んでもいいんだけど）。

deprecatedなのはActionErrorで、どうも、元の文の意味は、（コード中の）ActionError(複数)を、ActionMessage(複数)に置き換えてね、ということなのでは。

と、宇野るいもさんが気付く。

多分、エラーを意味するActionMessageを格納したActionErrorsは別にdeprecatedじゃないのでは、ということでした。あの書き方じゃわかんないよ。

_ なひさんの指摘を受けて、さらに良く読む

2003-09-26 - FieldChecks,ValidWhen: Changed validator signatures to use ActionMessages rather than ActionErrors, was breaking validations.

なるほど。

まあ、いずれにしても、コレクションの命名に+sは良くないってのは正しそうではある。

_ 順序について考えてみる

大雑把に2種類に分けると具合が良いので、

・過去から学ぶ

・現在から学ぶ

の2種類を前提としてみる。

過去から学ぶってのは、ユークリッド幾何学やってから……みたいなやつ。

現在から学ぶってのは、祈祷とか神頼みとかはおいておいていきなり西洋医学を学ぶようなの。

前者は、それが過去のものであっても、現在と連続しているからやるんだろうか。後者は、断続しているから捨ててるんだろう。

人文系は逆で、最初に現代語をやってから古文に遡るが（これはおそらく違うんじゃないかという気もするが）多分、連続性が無いという判断から来てるんじゃないか。でも、二葉亭四迷と坪内逍遥があって、夏目漱石と森鴎外があって、山田美妙があって……みたく実は近代以降は連続してるだろうし、近松門左衛門とかまで遡ってもいいんじゃないかとか。っていうか、小学生にそんなもの読ませてもしょうがないから、ちょっと別か。

でまあ、前からオブジェクト指向プログラミングをいきなりやりゃいいじゃんと思ってたんだが、実際にはまず構造化をきっちりやってからじゃなけりゃならんのかな？ という疑問なんだが。

だが、明らかに断続はあって、askとtellは別物じゃないかとか。構造化でやっていってもtellはできなくはない気はするけれど。できなくはない気はするが、構造的な仕様を切るのが難しそうな。

って言うか、おいらが1番、不思議なのは、なぜソースを読まないんだ？ いや、読んでる人は読みまくってるんだろうけど。

作家は、本を読みまくるそうだ。中には天才もいて、いきなり書き出すかも。島清とか。

演奏家は、演奏を聴きまくるそうだ。なかにはカッコをつけて影響を排除するためにワタシは他人の演奏は聴きませんとか言い出すのもいるけど、それでも子供の頃は聴いてるだろうとは思う。

ベートーヴェンは演奏もするから他人の曲の研究したはずだし、シューベルトやベルリオーズは確実にベートーヴェンマニアだし、バッハはヴィヴァルディを研究してイタリア協奏曲を書いたはず。

画家は絵を見る。ネロは最後に絵を見てやっと死ねる。

教育がいかんのかな？

いきなりハローワールドを書かせるんじゃなくて、最初は、ハローワールドを読ませるとか。つまらないな。

少なくても共通語としてC、今じゃJavaでも良さそうだけど、最初は読むとこから始めるのが本当は良いのかも。

それはつまらない？ 小学校の図画の時間は、最初は描くとこから始める。中学になって美術の時間で他人の絵を見せる。

プログラマは小学生ですか？

国語はいきなり書かせる前にまず、読ませるけど。

などと、つらつら考えてみるが、どうでもいいや。

なんか、途中から福助が出てきてるし（久生十蘭のハムレットの手法についてのメタな言及）。

_ 31日

リングに行けそうだ。

_ 見つけた

まずソフトウェアを観まくってください。プログラムを読みまくってください。作ることや書くことに先立ちます。

創造の源

なんでか知らないけど、名前の通ったsmalltalkerが語ることっていつも腑に落ちる。彼らがかって通ってきた道を歩いてるってことなんだろか。

追記：名前の通ったってのは別に有名人だからということではない。むしろ、その人の略歴を見るとsmalltalkerなことがあるということだな。

_ J2EE プロジェクトの問題

こんな資料があったとは（JDCSDCの会員登録が多分必要）。

問題 8: 開発工程が古い

プロジェクトフェーズ:

開発

影響のあるプロジェクトフェーズ:

安定化、本稼動

影響のあるシステム要素:

保守、コーディング品質

徴候:

プロジェクト計画が、直下型 (Waterfall) 方式をとっている。つまり、システム を最初から設計し、コーディングなどに大量の時間を費やしている。

構築工程が存在しないため、構築品質が低い

構築を行っている間は何も作業できず、構築の遅れが開発の遅れにつながっている

コンポーネントを統合する前に十分にテストしていない。つまり、2 つのコンポーネントを安定しないうちに統合し、そのスタックトレースを検証している

解決策:

優れたソフトウェア技術を採り入れる必要があります。XP についてはすでに言及しましたが、XP の詳細については最後の「参照情報」から関連サイトを参照してください。

注:

単体テストを行うときは JUnit、構築するときは Ant を使用することをお勧めします。JUnit および Ant は、XP 方法論を支援する無料のツールです。JUnitおよび Ant の詳細については、「参照情報」を参照してください

サンの公式な技術情報で、アンチパターンになってるよ>ウォーターフォール

_ ちょっと読解

ツッコミに書いたことは別として、あの文書の内容がどこまで有効かの議論とは別に、読解しておく。

問題は、「徴候」のパートで、これは4つの異なる徴候を示している。

1. 直下型の問題として、最初から設計し、コーディングに時間をかける。

訳が変なんじゃないかと思うが、原文を探す気にはならないので、かってに逆翻訳してから再翻訳して、最初に設計してからコーディングするので時間がかかるというふうに読み取った。

解決策：XP

2. 構築工程がない

そんなバカな。ということで、おそらくここで想定している状況は、どっかにクラスツリーが非管理レポジトリとして用意してあって、メンバーが別々にjavacした出力をコピーするというようなことを指しているのだと思う。

解決策：仕事やめろと思うが、ここではantくらい使えということ。

追記：構築工程ではなく、これは構成管理のことではないかな？

3. 構築に時間がかかる

2.はさすがにバカげていると気付いたので、ソースのツリーを作り、誰かがソースをコピーしてから、全体をコンパイルする。だから、誰かがコンパイル中はほかのことが（テスト実行を含み）できない

解決策：仕事やめろと思うが、ここではantくらい使えということ。

4. ユニットテストがバータリー

解決策：JUnit使って順に検証し、新たな実装の追加が、元の実装の破壊を生むこと無いように確認してから、統合テストのフェーズに移れ

2と3はさすがに考えにくいが、僕には、1.と4.は有意な提言だと思う。

ちなみに、500人のプロジェクトでXPは使えるか、について、使えるとこないだ気付いた。

最初の時点できちんとアーキテクチャを構築すれば、500人分の作業といっても50の異なるサブドメインに分割可能なはずだ。各サブドメインは別にWebサービスで結合する必要はないが、SOAの考えを流用してきちんとブラックボックス化したサービスとして相互に結合可能なアーキテクチャだ。

であれば、10人1プロジェクトとなるのだから、そこでXPすれば良い。

500人のうち、優秀なのが20人（そのくらいはいるだろう）いれば、その20人から1番出来の良いのを1〜2人、喧嘩になるようなら3人の合議制で、アーキテクチャを決めさせる。まあ、出来が良いんだから、スケジュールは守るだろう。次にその20人を重要度の高い20のプロジェクトに配分すれば、50のサブプロジェクトのうち2/5は確実にまかなえるはずだ。実際には500人もいれば優秀なのは100人以上はいるはずだから、その配置をきちんとやり、週1ペースでサブプロジェクトのリーダーによる相互の進捗ミーティングを行いサブプロジェクトの重要度に応じたメンバー移動などを行っていけば良い。

間違ってるかな？

_ 真似るということ

そういや、子供を見てたり、自分のことを振り返ったり、その他いろいろな見聞から考えると、最初はマネするもんだな。

マンガを見ればマンガを書き、病気になれば看護婦や医者になりたがり、小説を読めば小説を書く。

子供は金を稼ぐためのシノギとして考えないから素直なもんだ。自分がそれによって何か、心が動かされれば、同じように、心を動かすためのものを自分の手で作りたくなる。

プログラマがシノギのための学習項目であるならば、まず読むまず観るなんて面倒なことがなおざりになるのも、効率ってやつに焦点を当てれば無理もなかろう。

しかし、その無理のなさが、世に腐れプログラムが垂れ流される元凶なんだとしたら、それは良くない。

「仕事は趣味ではない」

というのは、フツーの文脈では、「遊びじゃないんだから真剣にやれ」という意味であるとか「遊びじゃないんだから規約を守れ」というどちらかといえば積極的にプラス方向へモノゴトを進めるために使うべきものなのだが、ことプログラムに関して言えば、「手を抜け」であるとか「後先を考えちゃおしまいよ」とか「目先の利益優先」とか「形式さえ合っていれば内容は問わない」とマイナス方向へ進めるために利用されているのではなかろうか。

っていうか、「形式」が2種類の意味を持ってるのがまず問題だろう。ドキュメントの整形式ってのが、数合わせだったりするわけだし、コーディングルールが目先の見易さだったりするようなことだ。

かくして、やはり「文芸的」と訳すのが正解なのだ（プログラミングは理系作業ではなく、文系作業。レトリック重要）とここでひとまず結論をおいてみる。

_ レトリック重視プログラミング

というわけで、そのプログラムが非常に無意味なバータリーなためにあると感じたら、正しいプログラムは、

/**
 * とりあえず、データベースを指定されたキーで読み込んで中に入れて返す。
 * 各フィールドの並び順は運任せ。
 */
public class A {
 public static DataSource dataSource;
 public int a1; // バータリーなんだから命名もいい加減。
 public int a2;
  ...
 public int a259;
 /**
  * 指定されたキーで読み取った内容を格納したインスタンスを生成。
  * 事前条件: {@link #dataSource}に有効なデータソースを設定しておく。
  * @param key SQLを指定する
  * @throws IllegalArgumentException エラーの時に投げる。エラーになるのはいつだって引数が変だからである。
  */
 public A(String key) {
   assert dataSource != null;
 
   Connection connection = null;
   PreparedStatement preparedStatement = null;
   ResultSet resultSet = null;
   try {
     connection = dataSource.getConnection();
     preparedStatement = conneciton.prepareStatement(key); // インジェクションOK!
     resultSet = prepraedStatemet.executeQuery();
     resultSet.next();
     for (int i = 1; i < 259; i++) {
         String fieldName = "a" + i;
         Filed field = getClass().getDeclardField(filedName);
         field.setInt(this, resultSet.getInt(i);
     }
   } catch (Exception e) {
     throw new IllegalArgumentException(e);
   } finally {
     close(resultSet);
     close(prepraedStatement);
     close(connection);
   }
 }
 /**
  * なんでもクローズする。
  * @param object クローズしたいオブジェクト。nullの場合は既にクローズ済みとみなし、何も行わない。
  */
 public void close(Object object) {
   if (object == null) {
       return;
   }
   try {
     Method method = object.getClass().getMethod("close");
     method.invoke(object, null);
   } catch (Exception e) {
   }
 }
 /**
  * a1を返す。いちいちゲッタメソッドを呼ぶと面倒だから、直接
  * {@link #a1}を操作すること。
  * @return ない
  * @throws IllegalStateException このメソッドは呼ぶためにあるわけではない
  * @deprecated
  */
 public void getA1(int x) { throws IllegalStateException("呼ぶな"); }
}
 

とか。 コードによって表現されている内容。

• フィールドは配列ではなく、きわめて抽象的なフィールド名によって示されているのは、抽象化こそ人間精神の発露であるという自己表現。
• なぜか、intで決定となっているのは、すべての事象は数値的に表現できる（しかし32ビット以内）という明確な意思の表現。
• SQLがなんであろうが受け止めてしまうのは柔軟な精神の表現。
• どんなエラーであっても引数が悪いことにしている（データベースが落ちていた時に呼び出したやつ＝引数を与えたやつが悪いという含意も）、悪意に満ちた眼差し。
• 意味無くリフレクションを使用してコード量を削減して省力化をアピール。
• Javadocは嫌味っぽくそれなりに記述してあるのは、底意地の悪さと嫌々やっていることの意思表示。

など。
それから見逃してはいけないのは、クラス名のAというのが、どんなSQLでも受け付ける＝どのようなロウのインスタンス化も引き受けるという点から、AnonymousやAliasのA、すなわち匿名のAという極めて意味付けされた名前だという点。当然、フィールド名もその文脈において（A社の従業員a1, a2, ...）という極めて正しい命名則に則っていると言う点。ここを見逃すと重要な意味が理解できなくなる。
すなわちコメントの記述(// バータリーなんだから命名もいい加減。)は、韜晦であって事実ではないという点。わざわざコードに韜晦的なコメントを入れると言うのは、バータリーな作業なためウンザリしているという心理状態を反映している。すなわち、「非常に無意味なでバータリーな」作業だと感づいているということを示している。
これだけの意味を読み取れましたか？

_ 花見

目黒川経由で、芝に出て、桜田門から、内堀通りに入って、神保町から外堀通りに経由で、上智の横には入らずに戻る。

青山墓地を忘れた。

飛鳥山は北区にあるとか。上野の山とは別物なのか。

_ Rjb

DLを呼び出してjvm.dllを動的にロードするように修正。

win32は、%JAVA_HOME%\jre\bin\type

それ以外は、$JAVA_HOME/jre/lib/arch/type

でいいのかなぁ。

_ バータリー

キャッシュにしか残ってない(追記：消えた。キャッシュから消えるタイミングって謎だな)。

この言葉は、歴史的な文脈としてアーチャリーとかダルジブダッタイダ（でたらめ）みたいな名前の人がぞろぞろ出てきたのと結合してるから、すごーくはまって、以来、愛用。

_ なんでRjbがLinuxでクラッシュするのか？

わかった。stackのアドレスのMSBが立ってるからだ。

これでは、INT2FIXとか使えない。って言うか、そんな依存性を入れてはだめですな。

_ わかってないや

なんでだろう？

_ わかった

関数の戻り値の扱いで、先に足すか後で足すかだ。

_ rjb-0.0.5

まだ、Rubyのオブジェクトの移出は未サポート。

j2sdkインストール済みで、JAVA_HOMEが設定されていれば、その他の設定を不要にした（extconf.rb含む）。

でも、CLASSPATHは.のみ（J2SEは勝手にロードされるけど）。

試した環境：Windows2000SP4+VC6+J2SE1.4.2+Ruby1.8.1, Linux2.4.22+gcc2.95.4+J2SE1.4.2+Ruby1.8.1

DLは必須。

なかなかおもしろかった。

謎）LinuxだとJNI_GetDefaultJavaVMInitArgs がSEGV。確かに、Win32版J2SEのsrc/launcherと、Linux版J2SEのsrc/launcherでは処理が異なり、Linux版はJNI_GetDefaultJavaVMInitArgsを呼び出してない。なんかあるんだろうな。

追記：こっちが引数に違う構造体を与えていたバグ（4/15を参照）

_ 遊びをせんとや生まれけん

その部長の言い草が普通の意味かな。でも、それじゃ余りに情ないというか、不愉快だから（少しも楽しくもない仕事なんてごめんですな）、少しニュアンスをかえてみた（だから普通じゃなくてフツー）。実際問題として、遊びだからこそ真剣にやるって側面はあったり。

で、それを「趣味ならいくら凝っても良いけれど、仕事なんだから……」と読み替えれば、あんな感じ。

だから、本来、口に出して言うようなことではなく、もし口にするのであれば、「趣味なら適当でも良いけれど……」というベクトルで使わなきゃだめでしょう。

立場が上の人が手抜きを変なたとえかたで勧めてはいけない。手抜きをするなら、バレた時の言い訳が可能なまでに論理付けるか、さもなければ金額の多寡で、松竹梅スカ、この仕事は梅料金だから梅で行きますよ、ってな合理化ができなければ、だめだろうな、と思う。その場合、それは手抜きではなく、正当な作業量だ。あまった時間をハックに使おう。手持ちのコマがなければ、とりあえず、その仕事のやつでいいや、とか。

もしかしたら、遥か昔のギリシャにイソップが住んでたころから、遊びは仕事じゃなかったんだろうか？ （と、唐突に話は過去へ遡る）

英語のplay、フランス語ならjeux（xはいらないかも）、どっちも遊びであり音楽を奏でることでもある。だから、キリギリスは一生懸命音楽を奏でてあげていたのに、冬になったらアリに門前払いを食らわされるのかな。

「お前は夏の間、遊んでいた（＝音楽を奏でていた）んだから、野垂れ死にがお似合いだ」

だから、イソップの寓話は、「奴隷の処世術」と呼ばれるし、事実イソップは奴隷であった。

とは言うものの、キリギリスの夏の日々には、音楽家というビジネスモデルがなかったのが運の尽きかも。

_ rjbだめだめ

うにゅー、うまくいくと思ったら、LD_LIBRARY_PATHをあらかじめ設定してあった。

素じゃだめでした。

・LD_LIBRARY_PATHは、起動時に1回だけ評価だから設定したらexecし直しが必要

ですね。というか、それでlauncher/java_md.cがあんなにごちゃごちゃしてるのか。

なんか、抵抗があるが、しょうがあるまい。

しかし、それに較べるとやはりWin32は呑気なOSなんだろうかなぁ。

_ rjb

evecvするにしたって、argvとargcがオリジナルで手に入らないんだからどうやったてだめでしょう。

無理矢理staticを外したrubyを作ってもしょうがないし。

こういう場合は、setupでシェルを作ってそいつをbinに送りこむってのが正解では。

というわけで、Win32以外については、じたばたするのやめた。

っていうか、man dlopenしても、LD_LIBRARY_PATHの評価については出てないな。

#libjvml.soが呼び出す前に、つまりibjvm.soのロード前に、関連するすべての共用オブジェクトをロードしちまえば良いのかな？ フルパスはわかってるわけだし。しかし、本末転倒だからそれはやらない。

って言うか2000年のトピックだし。

って言うか、「なるほど、そりゃ正しい仕様だわ」で（おいら含めて）あきらめるところが、いいところだね。

_ オリヴィエラ

また来るのか。それは是非、行かねば。

それにつけても精力的な爺さんだ。

_ XPのテスター

内容に対する判断は別として

An XP tester is not a separate person, dedicated to breaking the sys-

tem and humiliating the programmers. However, someone has to run all

tests regularly (if you can't run your unit and functional tests together),

broadcast test results, and to make sure that the testing tools run well.

って、

XPのテスターは、孤立した、システムを壊したりプログラマに恥をかかせたりするための専任者ではない。そのかわりに、すべてのテストを恒常的に走らせてその結果をみんなに教えたり、テスティングツールがちゃんと動いているか確認したりする人間のことだ。

って感じでは。

not a separate personというのは、XPチームとは別のチーム（良く引用されるMSのテスト野郎Aチームみたいなの）ではなく、チームメンバーだという意味なんじゃないかな? dedicatedは、何を任されているかという作業内容についてにかかるのでは?

実感として、確かにテスト専任チームと、開発チームがあると、どうしたってhumilitating the programmersみたいなものが（当然、そんなつもりがあるわけないのだが）プログラマー側にもやもや湧いてくるってのはあるように経験的に思える。

そこで、専任のテスターは必要だが、それはあくまでもXPチームの中で動くんだよというようなことを書いているのではないかなぁ、と想像してみる。

20%くらいの確度で、それとは違って、単なる執筆中の気の迷いかも。

_ 通常表現

すごく違和感がある。IBM用語なのかなぁ。

正規表現が正しい訳であるかどうかはおいておくとしても（正則？）、最初なんだかわからなかった。平文の意味じゃないし、とか。

_ 今日は劇場の日

これからブラザーベア。

このあたりの（どう考えても単なるお子様）映画を字幕スーパーで見に行く酔狂な人がどれだけいるのかは結構謎だな。

追記：予告編のうち、実写版サンダーバード、特に2号のぬめぬめした質感にいたく興味をひかれ、なんとなく見に行きたくなる。多分、行く（そしてうんざりするパターンと予言）。

去年見たワーナーの馬映画といい、どうしてネイティブアメリカン（イヌイットはそう呼ばれないのかな）ものが多いように感じるんだろう。ホーンテッドマンションもエディマーフィーの黒人一家なんだが、人口比でいけば、白人のほうが多いのだろうし。

1.輸出を考える（と白人が多いとはいえない）

2.映画を見るのはマイノリティ

3.子供映画を見に行くのはマイノリティ

4.モノガタリが発見できない

まあ、悪くはないかな。っていうか、昼寝をしなきゃならない。

_ リング

劇場の入り口がわからず少しばかり迷う。

ドアを開けると木（というよりニスっぽい）匂い。縦長の空間。これだよこれ。ピットが深い穴なんでなんとなく感心。やたらと練習しまくってる。こんなもんだっけ？ それとも、そういう演出なのか？

以降、ライトモティーフ名は勝手名称。

宇宙挨拶の反−合パターンに痺れる。これだよ。

テセラックみたいな物体がふらふら漂い、黄色いリールが左半分を占める映写室（？）でめがねをかけた禿かつらのインチキ科学者のような3人のノルン。末娘のちょっと太めの人が良かったり。赤いデーモン君の串のようなトゲをぽきぽき折っては地面に串刺し。フィルムを読みながら過去、現在、未来の綱がわり。赤いのは宇宙樹。

黄色と赤でとってもポップ。

そうか、これがトーキョーリングか。

で、歪んだ掘ったて小屋。オレンジにSマークのTシャツ着たブリュンヒルデ。いい感じだ。馬はオモチャの木馬。なるほど、これがトーキョーリングか。

で、ラインの旅。＾の白い壁に地図を映し、旅を映写。爆発シーン。宇宙人みたいな女性はなんだろうと思ったら、ジークフリートにも行ってた人から小鳥だと教えてもらう。ふむ。

ちょっと退屈。ギビッヒは羊の頭。なんなんだ？

ピンクの服、ショートカットのグートルデ（単なるキャピギャル）、白い服でやたらノッポのグンター（血筋は良い無能者。巨大医院の若先生ということか）、無精ひげ黒い服のハーゲン（血筋が悪い陰謀家）。いい感じ。ギビッヒのちょっと英雄的なんだがスカスカしたモティーフ。

ジークフリートが＾、その手前でハーゲンが客席を向いて手を広げ、逆転の構図でギビッヒの地へ上陸。ヴォータンの槍はルーンが刻まれているから契約を兼ねてるんだっけな？

だが、ハーゲン、役者っぷりは良いのだが、ちょっと声が小さいかも。長い独白で一瞬、気が遠くなる。

ハーゲンは舞台手前のソファに座りつづける。

ヴァルトラウテ。確かに歌はうまいや。声量も。ハーゲンが座して終末を待ち受けるヴォータンとダブる。うまい演出。

隠れ頭巾はジークフリートとグンターの2人組で表現。掘っ立て小屋にブリュンヒルデとともに入るグンター。ハーゲンの向かいのソファに座り込むジークフリート。ノートングは青い板。ちゃんとドアを封印するが、グンターは小屋に入っているからちょっと微妙な解釈。

45分休憩。ここまで最初の世界挨拶以外は別段オーケストラは可もなく不可も無く。ラッパが引っくり返ったらしいが気付かなかった。

アルベリヒは医院での臨終の場。点滴かな。ハーゲンは点滴を止め、枕で顔を押して引導を渡す。びっくり。ジークフリートのミーメ殺しとハーゲンのアルベリヒ殺しという対照を作りたかったのかな。

で、ハイホーハイホーが、陰惨で、やっぱり、このハーゲンはうまい。しかし声はちょっと小さい。呼ばれて、レントゲン技師というか青っぽい服着たのがぞろぞろ。薬を調合するようにして酒をまわし、毒を飲まされたかのごとくのたうちまわり、そのうち1人は担架で退場。

女たちはみんなピンクの服で、グートルデと同じだが、看護婦さんかな。そんな感じ。ジークフリートは以後ワイシャツとジャケット。ブリュンヒルデは黒い服。

3幕。オーケストラが良い。

ラインの乙女。白い水着にトレンチコート。泳ぐと詰め物をしているんだと思うがすさまじく丸い。

回想の歌。鳥の歌がユーモラスな感じ。ミーメが裏切るところで泣きじゃくる。そこで回想の薬（その前だったか？）。

ジークフリートが死ぬところ。舞台手前に倒れ、奥の扉1つ分空いたところに女が立つ。そこににじり寄って行くのが葬送曲。すごくオーケストラが良い。ウェルズングの愛は好きだな。最後は英雄として死ぬのだ。ドンドン。血の流れは赤い稲妻模様の照明。女は現実には大鴉。ジークフリートにとってはブリュンヒルデ。葬送曲が終ると、手前に歩いてきて服を脱ぐと黒い下着姿のグートルデ。という3重構造（という演出だと思う）。

あっさりグンターの首をかききるハーゲン。

黒い竈。ギビッヒの郎党が赤いヤリをボキボキ折ながら焚き付け口に放り込んでいく。

ブリュンヒルデの愛の死。オーケストラ合わせて良いでき。タララララーララーラーのたびにぞくぞくするね。ブリュンヒルデが指輪を地面に置くのを虎視眈々と狙うハーゲン。

ギビッヒの文字が砕けて終末。郎党は折り重なって倒れる。

舞台が沈んでハーゲンとラインの乙女が消える。

ジグソーパズルが嵌め合わさってラインゴールドの復活。最後の1枚を手にして1人の乙女が外から映像に嵌めこむ。

ヴァルハラの炎上は無し。最後、舞台裏の人々で幕。

ライトモティーフのうち、フリッカとかドナーとかのは全然、覚えてないことに気付く。

それにしても、数十年振りだが、やはりオーケストラの音はいいなぁ。