ビスケットビスケットでちょっと遊んでみた。お絵描きツールのところで、「ペイントを呼び出す(Windowsのみ)」というのを見て、なんとなく寂しくなる。なんでrjbを作ったのかを思い出した。メモBPELについて調査中に出会ったページ。initiative。なんかいろいろあるが、ほとんどがプロプラエタリなプロセスモデル。唯一のBPEL派がTwister。右折信号が点いていても車信号が赤になった途端に渡り始める連中が数人、タクシーの激しいクラクションに押し戻される。おお東京だな、と感じる瞬間。COMを読み返してみたり。考えてみれば、ここからどれだけたくさんの事を学んだことだろう。*らしく、この本には50のプラクティスが出ているが、それを幾つか並べてみるだけで、わかる人にはわかるだろう。interface.(オブジェクトは独自のユーザーインターフェイスを持つべきではない。singleton.(シングルトンには気をつけろ。immutable.(インターフェイスは文法―メソッドシグネチャ―であり......次の訳は難しいな、緩い意味というのは文書化されたメソッドの説明のことだ......は変えてはいけない)これらの規則は、COMに限定されるものではない。すべてのインターフェイスセントリク(可能)なシステムの基本となるものだ。ほとんどの章はC++とCOM固有の問題が扱われている。appropriate(25)などはCOMのオブジェクト寿命管理が参照カウンタによるからこそ可能なものだ(もちろん、closeやdestroyといったメソッドを規定すれば紳士協定としては可能であるが)。MFCからATLへの移行期ということもあってか強型付けの推奨が随分たくさん出てきたりもする。至ってはCOMを知らなければ意味不明だろう。これは文字通り「1つのオブジェクトが特定インターフェイスの複数の実装を提供してはならない」という意味だが、この規則が生まれるということは、1つのオブジェクトが特定インターフェイスの複数の実装を提供可能だということだ。これはある意味非常にトリッキーなのだが、実際には複数のカスタムインターフェイスをそれぞれデュアルインターフェイスとして実装するシナリオだと比較的簡単にできてしまう。いうことはするな、ということが書いてあるのだが(COMの交換則が破壊されるからだが)、ちょっと技巧に走り過ぎてあまり意味がない章とも言える。ちなみに、P.201〜2のエピローグに並べられた箴言を列挙しよう。communityこれはそのまま他のインターフェイスセントリクなシステムにも流用できるものだ。邦訳では「ゆるやかなセマンティクス」になってました。[まったく意味不明な翻訳のような......でもそれで良いのかも。別に厳密に定義しているわけじゃなさそうだから。防災の日は171既に一昨日のことだが、NTTが防災の日を記念して毎月1日は171サービスデーとか始めたのを良い事に171を利用した伝言サービスを家人が試していた。不通時に使うわれるんだから22とか、輻輳時に使われるんだから293とかのほうがいいような気がする。1で始めるって決まりがありそうだから197とか。(ではなぜloose?)ここになんとなく良くない匂いを感じるぞ。rjb日本語APIドキュメントどうもありがとうございました。インターフェイスの件についても書いておきました。EditorフリーのBPELエディターをいろいろ探したが見つからなかった。Designerを使ってみる。DesignerもBPELの生成だけ(ビルドしようとするといろいろManagerを探すのだが―TechNode#5に思わせぶりな記述があるが、以前は違ったようだ)にも利用できる。単なる夜のドライブでも、主人公が「私は恒星間飛行をして......」とナレーションすればそれは恒星間飛行なのだ。(サラ金のCMで引用していたな)というのを思い出させてくれるのが、新湘南バイパスだ。