トップ «前の日記(2004-05-14) 最新次の日記(2004-05-16)» 編集

日々の破片

おもしろいなぁ。

「書くのをとめましょうかね」

ってのがサイコウに面白いのだが、ここが「やめましょうかね」じゃないのがすごい。意識してこの言い回しを使われたんだろうか。きっとそうなんだろう。

とめるというのは他者への働きかけで、やめるというのは自分に対する制御だ。

この調子で、や〜めたっ、となるまで続けていくと一体どうなるんだろう？

_ 動き回るコード

と書いちまうとワームがそうか、あまりおもしろくないな。

JavaScriptを最初にこしらえた連中は、動き回るコードというのを意識してただろう。と書いちまうと、動き回るの意味が限定されてしまうな。

データなんだけどそれがコードであるものがあっちへ行ったりこっちへ行ったりする分散オブジェクトってのはRPCの枠組みだとあまり無い気がする。たくさんあるかも知れないが、DCOM、CORBA、dRuby、RMI、RPCあたりだと、あくまでも実行主体はあらかじめリモートにあって、それに対するプロクシがネットワークの向こうからやってくるか、あるいはデータだけがシリアライズされてやってくるかのいずれかで、データとともにまだ見ぬコードが飛んでくるっていうのは、思い出したが、wishなんかがそんな風にできたっけな。その意味ではdRubyでマーシャルして送信するタイプのほうで、そのクラス自体のソースをメタデータとして（dRubyが内部的に隠し持って）送りつけて受信時にevalしてやれば（実際にはRubyの場合、微妙に異なるバージョンのオブジェクトが飛んでくると具合が悪いかも）可能だな、RMIならバイトコード、RemotingならILを送れば良いわけだから不可能じゃない。ルータの内側の世界ならそんな感じでも良さそうだ。

あまりうまい例が考えつかないが、

現行）

JNDIを使って、サーバー上の設定を読み込む。

というシナリオであれば、


public void executeFoo() {
   Context c = new InitialContext();
   Bar h = c.lookup("bar.bar");
   h.doSomething();
   ...
   String peerName = c.lookup("my.peer");
   ...
}

というようなコードをいずれにしろ書くことになる。とは言え、最初のBarのインスタンスを取り出す（これはDataSourceなんかを想定）ことは可能だから既にできなくもないわけだが、いずれにしろプルしなければならないわけだ。

そうではなく、リモートから情報を設定しにやってくる ……（やめた）

_ Groovy

ふと気付いたが、NETRubyにちょっと手を入れてやれば(というより削りまくれば)C#用のGroovyになるな。

_ とか

いろいろ読まずに想像してからGroovy killed the XML file?を読んでみたが、あまり感心しなかった。

高井さんには悪いが、そういう意味じゃ、あれもそうなのかな？

パラメータの意味って、非プログラマーが構成管理を可能にすることなんじゃなかろうか。そうでなければ、プログラム書いちまえばすむわけだから。(追記：こりゃ乱暴だ。実装時には想定不可能な構成を実行時まで遅延させるという意義を無視している)

そこで、3年前くらいか4年くらい前だか(もっと前だな)に作ったシステムをちょっと思い出した。

デペンデンシインジェクションのようなもんだが、コンフィガレーションインジェクションですぜ、だんな。

つまり、こんな感じのプログラムですな。面倒なんでrubyで記述。

従来
class Application
 def initialize()
   parameters = ParamFile.new("c:\---\config.ini") # config.xmlでもなんでも構わん。レジストリリーダでも良い。
   @timeout = parameters.lookup("timeout")
   @retry_limit = parameters.lookup("retry.limit")
   @retry_interval = parameters.lookup("retry.interval")
   ...
 end
 ...
end

しかし、気付いた、おれはバカですか？仮に、class ParamFileというような形式で気の利いたパラメータ読み込みのクラスを作っても（こんなものは、Preferences、ResourceBundle、DOM、XmlReader、GetPrivateProfileString、RegGetValueEx など幾らでもインフラはあるわけだけど、そこはO-Pマッピング（Object−ParameterFile）してドメイン特化したオブジェクトを利用したほうが楽だ）、結局、プログラムの数だけパラメータをプルするコードを書かなきゃならない。

これはバカバカしい。

そこで、おもむろに、


interface IConfigurable : IDispatch {
   [id(1),propput] HRESULT Timeout([in]long NewValue);
   [id(1),propget] HRESULT Timeout([out,retval]long* pValue);
   [id(2),propput] HRESULT RetryLimitaion([in]long NewValue);
   [id(2),propget] HRESULT RetryLimitaion([out,retval]long* pValue);
    ...
}

としてやって、COMのインターフェイスを実装してやるわけだ。

でもって、

(メソッド名は怪しい)
IActiveScriptParse* p = CoCreateInstance(....);
p->parse(L"c:\\...\\config.vbs"); // VBScriptでもJScriptでも良い。ASRはちょっとやめとく

当然、このconfig.vbsとかでは


Application.Timeout = 30000
Application.RetryLimitation = 8
...

と記述する。

どうだい、これなら、パラメータだって拡張子がVBSってだけで、ResourceBundleや、Windowsのプロファイルと変わらないじゃないか。(追記：Rubyのアプリケーション――例えばtDiaryとか――の場合、当然だがパラメータファイル自身がRubyのスクリプトだったりするが、そんな感じだな)

一方のアプリケーション群からはパラメータからのプルをいちいち書く必要なしだぜ。

それに実行時にパラメータが正しく設定されているかは


 app = GetObject("***.Application")
 Wsh.Echo "Timeout=" & app.Timeout
 Wsh.Echo "RetryLimitation=" & app.RetryLimitation
 ...

って言うようなスクリプト書いておけば、実行中にチェックできるじゃん。

が、不評だったので、パラメータを切るというのとプログラムを書くというのがデプロイヤーにはどうも大きな差らしいとわかった。どうも実行の責任主体(これは起動した人ではなくプログラムを作成した人に属するらしい)にはなりたくないようだ。

しかし、J2EEではついこういった手法を忘れてたが、JNDI使えばオブジェクトのインスタンスを取り出せるわけだから、この手を復活させようかなぁ、とちょっと考えてみる。シェルから起動するタイプのやつには、Rjbがあるわけだし。

#と、なぜか、デプロイヤーに不評を忘れたかのようだが、WindowsマシンのデプロイヤーとJ2EEマシンのデプロイヤーは微妙に違うから大丈夫なのではないかとか。

_ 萎縮的効果

当然、これが1番の論点だろうなぁ。

ユーザーベースが大きくなればどんな使い方を仕出かす人間が出てくるかは当然わからないわけだ。

量的な実験を行うにはユーザーベースを徹底的に拡大するしかなく、そのためにはあえて秘孔を突かざるを得ず、ということもありえる。実際22万だの200万だのといった規模でのリアルタイムでの実証実験を行った単体のソフトウェアがかってあっただろうか？

その意味では同様な実証実験をちょっとした秘孔を突くことで為しえたやつがこないだの未踏に事例として既にある。

しかし、200万ノードの負荷テストかぁ、おもしろそうだな。

巨大なインストールベースがあり、情報の冗長化と取り出し時の最適化がされていてかつ情報発信の言質が取られないという特性を考えれば、日本のインターネットでのもう1つの悪の温床（という捉え方がされることもある）2chのようなBBSがすっぽり収まることが想定できるし、おそらくBBS機能の付加というのはそのあたりまで見据えた実験なんだろうから、最初のところはやはり単に量をかせぐための煽りと捕らえたほうが素直だ。

＜突然出てきた仮定説：明示的ログ取り以降、書き込みの質が低下、または均質化したということは無いか？　＞

かつ、何度もアップデートするのは、好評に支えられることによるインストールベースの更なる拡大と同時に大量のユーザーの支持を受けるユーザーインターフェイスなどの研究のために必須なわけだし、内部的にはより効率的な実装などに変えていくのはその実験的な性格から必要性は明らかだ。

Gnutellaを見ている時にそういう方法論が取れるな、と思ったことの1つに、検索（あれにはそれしか無いわけだが）のようなペイロードをエージェントとして、しかも可視化（ファイルにとってのアイコンといった意味での可視化）するというものがある。結構その可視化したことによって新たなペイロードが考え付くのではないかということだ。

現実側に倒してみると、減ったトラフィックの量＝表の著作物＋児童ポルノのように問題が大きいもの、減らないトラフィックの量＝ただのエロと見ているのだが、実際その程度なのじゃないかなぁ、と思うのであった。多分、都市伝説なんだろうが、ベータマックスがなくなったのは、VHS陣営のおまけにポルノビデオをプレゼント作戦のせいだというようなことがまことしやかに流れたりしてたが、伝説足りえるのは説得力があるからだ。（突然、Linux Journalかで生越さんがどうやってLinuxで飯を食ってるかで妙な書き方してたのを思い出したり）が、それは余談だし、正犯は確かにそっちの犯罪を犯してるわけだから、そういう連中がいたのは確かなんだろうが。

[ツッコミを入れる]