Digitune [memo]

不思議な結果?(2)

CGI や FastCGI、Servlet 等の性能を評価していた時のこと。

ふと戯れに (ってそればっかりだな…) apache と tomcat の Coyote で、通常のファイル送出性能にどれくらいの差があるのか調べてみたくなりました。

環境は昨日と同じです。性能測定には ab (apache bench) を使いました。

さて、まず apache。手元の環境は Debian woody、apache の version は 1.3.26 です。

kazawa@tpx20:~$ ab -c 20 -n 10000 http://localhost/hello.html  
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3  
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/  
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/  
  
Benchmarking localhost (be patient)
Completed 1000 requests  
Completed 2000 requests  
Completed 3000 requests  
Completed 4000 requests  
Completed 5000 requests  
Completed 6000 requests  
Completed 7000 requests  
Completed 8000 requests  
Completed 9000 requests  
Finished 10000 requests  
Server Software:        Apache/1.3.26  
Server Hostname:        localhost  
Server Port:            80  
  
Document Path:          /hello.html  
Document Length:        92 bytes  
  
Concurrency Level:      20  
Time taken for tests:   19.021 seconds  
Complete requests:      10000  
Failed requests:        0  
Broken pipe errors:     0  
Total transferred:      3560000 bytes  
HTML transferred:       920000 bytes  
Requests per second:    525.73 [#/sec] (mean)
Time per request:       38.04 [ms] (mean)
Time per request:       1.90 [ms] (mean, across all concurrent requests)
Transfer rate:          187.16 [Kbytes/sec] received  
  
Connnection Times (ms)
              min  mean[+/-sd] median   max  
Connect:        0     0    0.2      0    10  
Processing:     1    37  101.9     26  2658  
Waiting:        1    37  101.9     26  2658  
Total:          1    37  101.9     26  2658  
  
Percentage of the requests served within a certain time (ms)
  50%     26  
  66%     28  
  75%     29  
  80%     30  
  90%     33  
  95%     38  
  98%    175  
  99%    531  
 100%   2658 (last request)

毎秒500回ちょっとですか。この時は妙に結果がばらつくのが気になりました。あ、昨日と同じで、何回か実行して結果が安定してきたところを見ています。

さて、次に tomcat です。tomcat のバージョンは 5.0.19、JavaVM は最新のものを持ってきて 1.5.0β1 を使ってみました。

kazawa@tpx20:~$ ab -c 20 -n 10000 http://localhost:8080/hello.html  
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3  
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/  
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/  
  
Benchmarking localhost (be patient)
Completed 1000 requests  
Completed 2000 requests  
Completed 3000 requests  
Completed 4000 requests  
Completed 5000 requests  
Completed 6000 requests  
Completed 7000 requests  
Completed 8000 requests  
Completed 9000 requests  
Finished 10000 requests  
Server Software:        Apache-Coyote/1.1  
Server Hostname:        localhost  
Server Port:            8080  
  
Document Path:          /hello.html  
Document Length:        92 bytes  
  
Concurrency Level:      20  
Time taken for tests:   14.684 seconds  
Complete requests:      10000  
Failed requests:        0  
Broken pipe errors:     0  
Total transferred:      3133756 bytes  
HTML transferred:       921104 bytes  
Requests per second:    681.01 [#/sec] (mean)
Time per request:       29.37 [ms] (mean)
Time per request:       1.47 [ms] (mean, across all concurrent requests)
Transfer rate:          213.41 [Kbytes/sec] received  
  
Connnection Times (ms)
              min  mean[+/-sd] median   max  
Connect:        0    14    7.1     13   147  
Processing:    15    15    7.7     14   148  
Waiting:        7    14    7.5     13   147  
Total:         26    29    9.0     26   155  
  
Percentage of the requests served within a certain time (ms)
  50%     26  
  66%     27  
  75%     27  
  80%     28  
  90%     35  
  95%     38  
  98%     57  
  99%     70  
 100%    155 (last request)

むむむ。apache よりも速いですね。なお、デフォルト設定の tomcat から変更したところと言えば、

• JAVA_OPTS 環境変数に「-server」オプションをセット (HotSpot Server VM が利用される)。
• server.xml を編集してアクセスログが出力されるようにした (apache 側と条件を揃えるため)。

くらいです。あ、もちろん Server VM 使用、ということで、結果が安定するまで何回か (5〜6回) くらい ab を回し、JITC による最適化が行き渡るようにしています (最適化されるまでは4倍くらい遅いです)。

さて、ここまでの話だと「単純なファイル送出なら apache より tomcat 方が速い」という結論が出かねないわけですけれども、ここで、apache のテスト時に結果がばらついていたことを思い出しました。そこでテスト中の apache プロセスの状況を調べてみました。

すると、結構高い頻度で apache プロセスが起動したり終了したりしているらしいことが分かりました (defunct な apache プロセスがたびたび現れる)。手元の apache は woody のそれをインストールしたままの設定でしたが、性能に関係する主なパラメータの状況は下記のようになっていました。

MinSpareServers 5  
MaxSpareServers 10  
MaxClients 150  
MaxRequestsPerChild 100  

MaxClients が 150 なのはいいとして、MaxRequestsPerChild が 100、ってのはまたずいぶん安全よりな設定なんですね、woody は。

そこで、SpareServer が常に 20 以上存在するようにし、また MaxRequestsPerChild を 10000 に変更してもう一度テストしてみました。その結果が下記です。

kazawa@tpx20:~$ ab -c 20 -n 10000 http://localhost/hello.html  
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3  
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/  
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/  
  
Benchmarking localhost (be patient)
Completed 1000 requests  
Completed 2000 requests  
Completed 3000 requests  
Completed 4000 requests  
Completed 5000 requests  
Completed 6000 requests  
Completed 7000 requests  
Completed 8000 requests  
Completed 9000 requests  
Finished 10000 requests  
Server Software:        Apache/1.3.26  
Server Hostname:        localhost  
Server Port:            80  
  
Document Path:          /hello.html  
Document Length:        92 bytes  
  
Concurrency Level:      20  
Time taken for tests:   14.631 seconds  
Complete requests:      10000  
Failed requests:        0  
Broken pipe errors:     0  
Total transferred:      3560712 bytes  
HTML transferred:       920184 bytes  
Requests per second:    683.48 [#/sec] (mean)
Time per request:       29.26 [ms] (mean)
Time per request:       1.46 [ms] (mean, across all concurrent requests)
Transfer rate:          243.37 [Kbytes/sec] received  
  
Connnection Times (ms)
              min  mean[+/-sd] median   max  
Connect:        0     2    2.6      1    30  
Processing:     6    27    8.1     25   387  
Waiting:        0    26    8.2     25   386  
Total:          6    29    8.6     27   388  
  
Percentage of the requests served within a certain time (ms)
  50%     27  
  66%     28  
  75%     29  
  80%     30  
  90%     37  
  95%     49  
  98%     54  
  99%     57  
 100%    388 (last request)

これで、tomcat とほとんど変わらない性能が出るようになりました。apache って結構頻繁に SpareServer の回収を行ってるんですね。また、大量のアクセスが定常的に発生しているような場合は、常にたくさんのプロセスが立ちあがっているように設定しておかないと結構オーバーヘッドが大きいのですね。なるほどー。

というわけで、こちらはあんまり不思議な結果にはなりませんでした。一つ分かったのは、単純なファイル送出ならば tomcat Coyote でも十分な性能を持っていること。apache の持つ多彩な機能が必要ない場合は、安直に Coyote を使ってしまうのも悪くないのかもしれません。

昨日は

夜になって鳥乃が激しく嘔吐し、しまいには血の混じった胃液まで吐き出したので急遽近所の救急病院へ行きました。そこで吐き止めと失われた水分を補給するために点滴してもらっている間に鳥乃はすやすや眠ってしまい、0:00 過ぎに家に帰ってきました。
今日、かかりつけの病院に行って薬をもらってきたんですが、「今日一日は固形物は避けるように」と言われたのに早くもいつもの食い意地を発揮してヨーグルトやプリンをぱくぱく。元気になったのはいいけどちょっと心配だよ…。

不思議な結果

64bit 環境での性能向上率をいろいろ調べていた時のこと。

C で言う long long int、64bit 整数に関する演算速度を調べてみようと、下記のようなテストプログラムを作りました¹。

#include <stdio.h>  
int main()
{  
    long long int   a, b, c, d;  
    int     i;  
    a = b = c = d = 1;  
    for ( i=0; i<100000000; i++ )
    {  
        a = d % 0xFFFFFFFFFFFFFFFLL;  
        b = a + a + 1LL;  
        c = b * 4LL;  
        d = c / 2LL;  
    }  
    printf("i:%d,  a:%lld, b:%lld, c:%lld, d:%lld\n", i, a, b, c, d);  
}  

まず、このプログラムを今の僕の手元の環境でコンパイル、実行した時の結果は下記の通りとなりました²。

kazawa@tpx20:~$ uname -a  
Linux tpx20 2.6.3 #1 Sat Mar 6 11:30:13 JST 2004 i686 unknown  
kazawa@tpx20:~$ cat /proc/cpuinfo  
processor       : 0  
vendor_id       : GenuineIntel  
cpu family      : 6  
model           : 8  
model name      : Pentium III (Coppermine)
stepping        : 3  
cpu MHz         : 597.526  
cache size      : 256 KB  
fdiv_bug        : no  
hlt_bug         : no  
f00f_bug        : no  
coma_bug        : no  
fpu             : yes  
fpu_exception   : yes  
cpuid level     : 2  
wp              : yes  
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse  
bogomips        : 1179.64  

kazawa@tpx20:~$ gcc -v  
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs  
gcc version 2.95.4 20011002 (Debian prerelease)
kazawa@tpx20:~$ icc -V  
Intel(R) C++ Compiler for 32-bit applications, Version 7.0   Build 20021021Z  
Copyright (C) 1985-2002 Intel Corporation.  All rights reserved.  
FOR NON-COMMERCIAL USE ONLY  

GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux  
Supported emulations:  
elf_i386  
i386linux  
/usr/lib/crt1.o: In function `_start':  
/usr/lib/crt1.o(.text+0x18): undefined reference to `main'  
kazawa@tpx20:~$ gcc -O3 -o multi_gcc multi.c  
kazawa@tpx20:~$ time ./multi_gcc  
i:100000000,  a:436906, b:873813, c:3495252, d:1747626  

real    0m19.619s  
user    0m19.201s  
sys     0m0.004s  
kazawa@tpx20:~$ icc -O3 -mp1 -prec_div -fp_port -rcd -tpp6 -mcpu=pentiumpro -xiMK -o multi_icc multi.c  
kazawa@tpx20:~$ time ./multi_icc  
i:100000000,  a:436906, b:873813, c:3495252, d:1747626  

real    0m13.636s  
user    0m13.346s  
sys     0m0.003s  

ここまでは、「ふむふむ、やっぱり Intel コンパイラの方が結構効率いいんだなぁ (最適化オプションが違い過ぎかも)」とか思いつつ普通に考えていました。

実際にはここでさらに 64bit バイナリを作ってテスト…という作業を行っていたのですが、その後戯れに、「Java だとどうだろう？」と思いつき、テストしてみることにしました。

まず、先程の C のプログラムとほぼ同じ内容の下記のようなプログラムを作成します。

public class multi {  
    public static void main(String[] args) throws Exception {  
        long a, b, c, d;  
        int i;  
        a = b = c = d = 1;  
        for (i = 0; i < 100000000; i++) {  
            a = d % 0xfffffffffffffffl;  
            b = a + a + 1l;  
            c = b * 4l;  
            d = c / 2l;  
        }  
        System.out.println("i:" + i + ", a:" + a + ", b:" + b + ", c:" + c + ", d:" + d);  
    }  
}  

Java の場合は long が 64bit なのでこれで OK なのです。さてその後、普通に javac でコンパイルして実行してみました³。

kazawa@tpx20:~$ java -server -version  
java version "1.4.2_01"  
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06)
Java HotSpot(TM) Server VM (build 1.4.2_01-b06, mixed mode)
kazawa@tpx20:~$ javac multi.java  
kazawa@tpx20:~$ time java -server multi  
i:100000000, a:436906, b:873813, c:3495252, d:1747626  

real    0m7.485s  
user    0m7.223s  
sys     0m0.033s  

ちょっとびっくりなことに、VM の起動時間まで含まれてしまう time による計測にもかかわらず、icc による結果に比べても倍くらい高速です。なんじゃこりゃーって感じです。

１億回のループ中、中間結果をはしょったりしているんじゃなかろうか、と１千万回に１回中間結果を表示するようにしてみたりもしたんですが、結果は変わりませんでした。当然の如く、得られる数値も全て同一です。

これほど小さなプログラム、それも計算主体のものでこんなに差が出る理由がはっきり言って謎です。なお興味深いことに、テストプログラム中の *4 を *6 に、/2 を /3 に変更して試してみた結果が下記です。

kazawa@tpx20:~$ time ./multi_icc  
i:100000000,  a:-384307168202464939, b:-768614336404929877, c:-4611686018429579262, d:-1537228672809859754  
  
real    0m31.510s  
user    0m30.825s  
sys     0m0.007s  
kazawa@tpx20:~$ time java -server multi  
i:100000000, a:-384307168202464939, b:-768614336404929877, c:-4611686018429579262, d:-1537228672809859754  
  
real    0m32.544s  
user    0m31.778s  
sys     0m0.027s  

icc 版は２倍、java 版は4倍くらい遅くなって、どちらもほとんど変わらない結果となりました (Java が１秒ほど遅いのは VM 起動時のラグだとすると体感的にはちょうどな感じ)。つまりあれですか、かけ算をシフト命令で置き換えられるような時の 64bit 計算の効率が激しく良い、ってこと？しかし、いくら HotSpotVM が動的最適化して効率の良いネイティブコードを生成する、と言ったって、icc が静的に生成するコードよりも効率のいいものを作れるものなんでしょうかね。しかもこんな単純なコードで。

おまけ。HotSpot Server VM でなく Client VM では、

kazawa@tpx20:~$ time java multi  
i:100000000, a:436906, b:873813, c:3495252, d:1747626  
  
real    0m58.071s  
user    0m56.676s  
sys     0m0.040s  

てな感じになります。また IBM VM でも

kazawa@tpx20:~$ /usr/local/IBMJava2-141/bin/java -version  
java version "1.4.1"  
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1)
Classic VM (build 1.4.1, J2RE 1.4.1 IBM build cxia32141-20030522 (JIT enabled: jitc))
kazawa@tpx20:~$ time /usr/local/IBMJava2-141/bin/java multi  
i:100000000, a:436906, b:873813, c:3495252, d:1747626  
  
real    0m56.422s  
user    0m54.605s  
sys     0m0.093s  

と、あまり変わらない結果となります。こう見てくると、HotSpot Server VM だけが異常に (C と比べても) 速いことがわかります。なんでなんだろう…？

液晶テレビ

最近、電気屋さんにいくとついつい大画面フラットテレビ売り場に入り浸ってしまいます。
どこかで「日本人には絵画的な液晶テレビの画質がうけている」という話を見かけましたが、確かに液晶テレビの画面は絵画的です。店頭でずっと見ていて¹、個人的にはどうも違和感、というか物足りない感じがずっとあったのですが、昨日ブラウン管のテレビを見比べてみて一つ原因かもしれないことを思いつきました。
というのも、液晶テレビには (当たり前なんですけど) フリッカーがほとんどないんですよね。逆に残像が気になるくらい。もちろん、最近の機種はずいぶん残像が少なくなってきていて、実用上はほとんど問題ないわけですけれども。
対して、ブラウン管のテレビはかなりちらちらしています。真正面から見ている時はほとんど気になりませんが、目の端に画面を捉えている時などはかなり気になるでしょう？
僕なんかは小さいころからブラウン管のテレビをずっと見続けてきていて、テレビというのはすなわちブラウン管のあれだ、という意識があるわけです。ああいう、ちらちらした画面、言ってみれば (無駄に) 刺激過多の画面をずっと見続けてきたがゆえに、液晶画面の絵画的な、しっとりとした画面を見ると、どうも物足りないというか、違和感があるんじゃないかな、と思いました。同じようにフリッカーが少なく、しかも残像もないプラズマはどうか、というと、どちらかと言うと液晶テレビを見た時の印象に近い気がするし…。気のせいかなぁ？
とにもかくにも、今の僕の感覚はある意味狂ってしまっているとも言えるわけで、子供たちのためにはもしかすると今からもっと低刺激な映像装置を使った方が良いのかもしれないなぁ、と思ったりしました。

君は天然色

「生茶」の新しい CM でかかっている歌。懐かしいなぁ。好きなんですよね、この歌。

「Avalon」

SAK から借りていまさら見ました。すみません＞誰に？

実写、なのに全然実写っぽくないのが印象的。昔、人は人工物と自然物を主に複雑さの違いで判別している、という話を読んだのを思い出しました。

映画だけだとストーリー的には少し食い足りない感じ。腹八分目で抑えておくのがポイントなのかしら？(笑。それにしてもますます「イノセンス」が見たくなってしまった…。

今日のあゆみさん

F1 予選の中継を見ていた時のこと。
「ジャガーってイタリアのチーム？」
「いや、イギリス」
「イギリス？ミック・ジャガー？」
「？」
「…肉じゃが？」
なんでそーなるの！?(笑

VAIO のキーボード

あゆみさん VAIO のキーボードがまた効かなくなってきた…。
ずいぶん前からふとした拍子にキーボードが効かなくなることがありました。1) 電源を入れ直す or 再起動 or スタンバイから復帰すれば直る、2) USB キーボードでは問題なく入力出来る、といったことから、どうも OS がくさい。
ちょっと調べてみると、「[REG] デバイス ドライバ エントリ、パート 2 – マウス/キーボード ドライバ」というページを見つけました。イベントビューワーの「システムログ」には特に何も残っていないところから、怪しそうなパラメータとして「PollStatusIterations」を増やしてみたりしたんですが、改善されず。他にも「PollingIterations」や「PollingIterationsMaximum」、「ResendIterations」などを増やしてみたりもしてみましたが、状況は変わりませんでした。
しょうがないから USB キーボードを買ってくるかなぁ…。

リモコン交換

ちょっと前から PSX のリモコンの効きが悪くなってきました。電池チェッカーで調べてみた限り、電池が切れている、というわけでもないようなんですが、とにかくリモコンが効かない。おかしいのは、そんな時でも裏の電池蓋を開けて、電池をグルグル回してあげると、ごく普通に使えるようになるのです。
しばらくグルグルしつつ使っていたんですが、イイカゲンめんどくさくなってきたのでまたしてもサポートに電話してみました。こちらで一通り症状を伝えた後、先方に教えてもらった確認点を確認して特に相関がないことを報告すると、あっさり交換処理に。しかも新品をすぐ送ってくれ、新品到着時に故障したリモコンを運送屋さんに交換で渡してくれれば良い、とのこと。
というわけで、我が家はリモコンだけ新品の PSX となりました。今考えてみると、使っていた電池¹が微妙に消耗してたのかも。チェッカーではまだ残量はあることになっていましたが、PSX のリモコンが要求する電圧が実はかなりシビアだ、とか。グルグル回すと復活するのは、グルグルすることで電池と接点がこすれて接触抵抗が下がり、一時的に電圧が回復する、とか。そんなことはないか…。
新品電池を入れてちゃんと試してみればよかったなぁ。今度のリモコンで同じ状況になったら試してみようっと²。

MSN Messenger 6.1

にアップデートされてから、netbios-ns な UDP パケットをやたらにばらまいているような気が…。
気のせいか？

Subversion 1.0.1

mod_authz_svn が SVNParentPath に対応したり、匿名ユーザも含めた形でアクセスコントロールが出来るように拡張された模様。ますます便利になったなぁ。
それにしても、こちらの日本語訳はいつも対応が早くてとても助かります。今回の拡張についてもさっそく翻訳されているようです。どうもありがとうございます。

桜のつぼみが

大きくなってきましたね。都立大の周りにはたくさん桜の木があって、毎年楽しませてもらっています。アウトレットモールの菜の花畑も綺麗だし、いよいよ春めいてまいりました…。

「ビラヴド」

トニ・モリスン著。南北戦争前後のアメリカにおける、黒人奴隷の「自由」や「自身」を取り戻すための苦悩の日々を描いたお話。あゆみさんに借りた本。

この本では、当時のアメリカにおける黒人奴隷の境遇が、当事者の視点で切々と語られています。読むのがつらいくらいのその告白を読みつづけている間に僕が感じたのは、絶望的な「共感の欠如」でした。白人の『先生』は、単なる家畜と同じように奴隷を扱います。そこに悪意があるわけではなく、奴隷というものが他の家畜と同じ、農場主にとっての資産に過ぎないと思っているだけなんですね。出産可能な年齢の女奴隷は資産を増やしてくれる可能性があるから大切、まだ若い子供奴隷を売って大人の奴隷を二人買おう、女奴隷に子供を生ませるために若い男奴隷とまぐわせよう、エトセトラ、エトセトラ…。『先生』が来る前に農場を所有していたガーナーさんにしても、「同じ人間である」というレベルでは共感を持ちつつ、しかし奴隷という立場への共感は持ち得ませんでした。

一方の黒人の側でも、共感し得ない白人による扱いを受け続けたゆえ、自由州において黒人の権利獲得に尽力している白人に対してすら、彼らの考えていることなど分かるわけがない、とあきらめてしまっています。

本を読みながら僕は、ガンジーさんが菜食主義者だったことを思い出しました。それはもちろん、彼がヒンズー教徒であったことと深い関係があるのでしょうが、彼の持っていた「共感の力」とも関係しているのではないだろうか、と思いました。ガンジーさんが大衆から圧倒的な支持をうけた理由として、大衆と同じ服を着、大衆と同じものを食べて、歩いて大衆の元へ赴き、大衆に対して共感出来る言葉で語りかけることが出来たからだ、と書いてありましたが、ガンジーさんのサッティヤーグラハも、原理的にはその、人間の持つ「共感の力」を用いたものと言えるのではないでしょうか。

人は、共感を感じないものに対してはどこまでも残酷になれるようです。しかし逆に、「共感の力」はアメリカで奴隷制度を廃止させました。他者への共感を拒否する人間はまた、他者に共感されることもなくなってしまう、ということを、いとも簡単に人を殺すことの出来る人達には考えて欲しいです。

読書の時間

総計三時間にもなる行き帰りの電車で本を読んでいればそりゃたくさん読めますがな＞うさ。薄い文庫本なんかだと一往復で読み終わっちゃうんですよね。だから最近は厚い本が好き。厚すぎると腕が筋肉痛になっちゃうのが難点。「虚数の情緒」は大変だった…。
森博嗣は犀川＆萌の最初の三巻だけ読みました。その野暮ったさが結構ツボなので、そのうちまた続きを読むかも。

こないだのデカレンジャー

「ウメコ、俺じゃない」
わはははははははは。あいかわらず最高っす。今回はかなりお色気過多だったなー。父親向けなんでしょーか？

日曜に

家族でお出かけ。駅を歩いているとあゆみさんが恥ずかしそうにしている。
「どしたの？」
と聞いてみたところ、
「すっぱいお口をした Suica ペンギンのポスター¹を見て、思わず同じ顔をしちゃったところを、ちょうどすれ違った人にばっちり見られちゃって恥ずかしかった」
とのこと。わはは。あるある、そういうこと。

「王の帰還」

先週の金曜にレイトショーで見てきました。21:00 スタートだと終了は 24:40！歩いて帰れるところに映画館があるんでもないとなかなか見られないスケジュールだよな…。
で、肝心の内容ですが、僕は３時間半があっという間に感じられたほど、楽しめました。どのシーンをとってもおざなりなところがなく、原作への愛を感じる出来だったと思います。
映画の内容には大満足だったんですが、隣に座ったおじさんが…。シーンの変わり目に必ず「ムフー！」と盛大な鼻息を吹くのです。それも「息止めてんのかよ！」と裏拳ツッコミしたくなるような勢い。むちゃくちゃ気が散るがな。

そういえば鳥乃は

大きくなったらドラえもんになりたいのだそうです。こないだ、いつものように「ドラえもんになりたいんだ！」と言った後、小さな声で「僕ドラえもん」と大山のぶ代チックな声でぼそっとつぶやいてました。おとーさんは笑いをこらえるのに必死だったよ。プププ。

ここのところ

更新頻度が低いのは、実生活と脳生活¹の比率について最近よく考えているからかも。思うに、どうも僕はこれまで家庭での実生活を軽んじ過ぎていたようで、必要以上に脳生活偏重型だったみたいです。ここを更新することなどの脳生活も確かに必要なことだとは思いつつ、日々の生活の中での比率は今よりもう少し低くてもいいだろうと。それよりももっと人間的な生活を送るために必要な実生活に時間をかけた方が、僕にとっての幸せ度は高まることに最近ようやく気がつきました。子供達にとっても今はその方が良いみたい。

次はマレーシア

F1 の話。今週末はマレーシア GP です。先週のオーストラリアは、開幕戦としては近年稀に見るくらい落ち着いたレースでした。たぶんどのチームも今年から導入された「１レース１エンジンルール」が気になって、「リタイアするくらいなら速度を犠牲にしよう」とコンサバ方向に振ってきた結果なんでしょうが、その反動がマレーシアで出るんじゃないかと今から楽しみ。とっても涼しかったオーストラリアと違い、マレーシアは猛暑ですからねー。明らかに速度の足りなかったチームもちらほらありましたから、今回はきっと勝負をかけてくるに違いない。ドタバタしたレース展開に期待！

MS InfoPath

が近ごろ流行っているようですね。こちらの記事などを見て思ったのは、クライアントを握っている Microsoft としてはしごく当たり前の展開だとは思いつつ、その革新性はどこにあるんだろうか？ということ。

僕なりの理解では、InfoPath とは、

1. XML オーサリングツールであり、
2. FORM 作成/実行ツールである。

というもの。先に紹介した記事でも、「InfoPathは、定形フォームを使ったデータ入力の支援ツールだといえる。」とあり、最後は「一言でいって『もはやクライアント・アプリケーションを開発する必要はない』ということだ。」とまで言っており、つまりは現在 SIer が各企業にカスタム・メイドしている業務系のアプリケーションのクライアント部分に位置づけられる製品／技術であることが分かります。

さて、まず最初に僕が考えたのは、「MS ワールドの外に同等の位置づけの製品はあるだろうか」という点です。同じような業務アプリケーションのクライアント側技術としては、最近は Web ベースとされることも多く、そこで用いられる技術としては Struts/Tiles や JSF、オーサリング環境という意味では Project RAVE が対応することになるのでしょうか。Web ベースの UI はクライアント環境への依存度と機能性がトレードオフとなっており、依存度を低くしようと思えば使える機能は非常に限定されてしまう、という欠点があります。クライアントをガッチリ握っている Microsoft としては、思いっきりクライアント環境に依存する代わりに極めてリッチな UI を提供する、というアプローチはある意味王道と言えます。

しかしそう考えていくと、「それってちょっと前に流行った Client/Server システム (いわゆるクラサバ) とどこが違うの？」という気がしてしまいます。C/S 時代も、クライアント側 UI は VB 等を用いてペタペタ form 部品を貼付けていくだけで作成することが出来ました。また、バックエンドシステムとの間は、ODBC を使って RDBMS 中立を保ちつつデータをやりとり、というのが定番でした。

それら過去の仕組みに対して InfoPath では、XML という中立なデータ構造外部化形式が挟まっていることによって、Client-Server 間のみならず、Client 内に閉じたデータも中立的に、抽象化された形で扱うことが出来る、という点が新しいのかな？構造化された情報自体をユーザが意識しやすくなっている点が革新的？確かにかつてのシステムではユーザが扱っている情報の構造全体を明確に意識することは難しかったですが、反面あえて見せないことでシステムに最適化された形のハンドリングも可能だったわけです。

それに、いわゆる C/S システムから Web ベースシステムへの大きな流れを作った原因の一つである、「クライアント環境への依存度」¹はまた元の状態に戻ってしまいますよね？いくら XML がシステム中立なデータ構造とはいえ、その中身に何らかの意味を与え動作させる以上、それを読んで動くプログラムのバージョンにまったく依存しないように保つことは至難の技のように思えます。比較的後方互換性が重要視されている Web ブラウザの HTML レンダリングですら、バージョン間非互換性には皆泣かされてきているわけで。

単なる「リッチなコントロールが使える XML オーサリングツール」という存在としては、実はかなりレアだったりしますから、価値あるものだと思います。マルチメディアを扱える特定業務向け XML オーサリングツールを Java (Swing+JAXP) で作っているのを見ていたことがありますが、やっぱりそれなりにめんどくさそうでしたから…。

すなわちそういうことなのかな？上記記事の「もはやクライアント・アプリケーションを開発する必要はない」っていうのが言い過ぎなだけ？

追記。クライアント環境への依存性、という点では、XML Schema という標準準拠なデータファイルを用意するだけで最低限のフォームは自動生成出来るようですね。でも、妥当性チェックなどの少し突っ込んだ処理を記述するためにはやっぱり JScript や VBScript を用いるようで、この辺は結構微妙。

XML Schema (+妥当性チェックのための独自ロジック) を用意するのと、例えば Struts で入れ物の JSP+form オブジェクト+Validator クラスを用意するのって、前者の方が圧倒的に簡単、ってことは必ずしもない気がするがなぁ。

歩きタバコ

会社帰り、団地に向かう道を歩いていると、歩きタバコしている人を小走りに追い抜く若い女性を見かけ。うーん気持ち分かるなぁ。
体調がいい時はあんまり気にならないけど、すごく疲れている時とかって結構ツライんですよね。しかも帰る方向が一緒だったりするとずっと煙を吸わされちゃったりして。タバコを吸う人にはこういう感覚はよく分からないかもしれませんが、例えて言えば口臭が超臭い人の吐く息を家に歩いて帰る間中吸わされているような感じ、かなぁ。言葉は悪いですが…。

2.6.3

自宅マシンの kernel を 2.6.3 へ。Debian backportsの 2.6.2 ディレクトリを apt の sources.list に追加したらなぜか 2.6.3 の source tarball がゲット出来た。

その後はいつも通り、

• .config をコピーして
• make oldconfig して
• make-kpkg –revision tpx20.1 kernel_image して
• 出来上がった deb を dpkg -i

して完了。

VMware は kernel を上げた後必ず vmware-config.pl をもう一度流す必要があります。会社マシンの 2.6.2 では以前 2.6 対応を行った時のままですんなり実行出来たんですが、自宅マシンの 2.6.3 ではエラーでうまく実行出来ず。まぁ自宅では VMware を使うこと自体希なのでとりあえず放っておくことにしました。そのうちに VMware のバージョンアップで対応されるでしょう。

libdv

kernel を 2.6 台に上げてから一度も実行していなかったので気がつかなかったんですが、IEEE1394 経由で DV カメラ¹と動画データをやりとりするのに使う libdv が、Debian 標準の 0.99-woody2 というバージョンではうまく通信出来なくなっていました。どうも video1394 デバイスドライバのインターフェイスが微妙に変わった模様。
しょうがないので Quasar DV Codec Home Page から最新の source tarball を取得し適当にインストール。無事、動画データの送受信が出来るようになりました。
ところでこういった Debian パッケージ外のアプリケーションを入れる場合、最近の僕の好みは home directory の opt 以下にアプリケーション毎にディレクトリを作成し、そこへインストールしてしまう方法。PATH や LD_LIBRARY_PATH 環境変数を適当に修正して利用します。これならば将来正式なパッケージが対応してくれた場合には、単にそのディレクトリを消して PATH と LD_LIBRARY_PATH を戻すだけで修正出来ます。
昔は何も考えずに /usr/local に入れちゃってたりしたんですが、後から消そうと思うとかなりめんどくさいんですよね…。ちゃんと自作 deb を作ってどうこう、というのが Debian では本筋なんでしょうが、それも激しくめんどくさい。

「立喰師列伝」

SAK に借りたアホな本。「イノセンス」が今話題の押井守監督の、「立喰師」という架空の (だよね？) ゴト師についての列伝形式の論文。

やーなんと言うか、激しくアホなんですよ。昼前の牛丼屋に現れて店の在庫を喰いつくす、鼻輪をつけまるで野獣のような牛五郎って誰よっ！？(笑。しかし、戦後から高度成長期、学生闘争の時代から現代に至るまでの社会に描写には、押井さんの社会観が、以前ねおんさんと「人狼」を見た時に議論した、学生闘争の影響の大きさ、ってものをここでも感じたような気がしました。彼は「何も生み出さなかった<戦前>」なんて書いてますが、だとしたら僕らの世代は失われた太平洋戦争前後の断絶を繋ぐことを期待されている世代なのかもしれないなぁ…なんて漠然と思ってみたり。

押井さんと言えば、「イノセンス」の主題歌を歌う伊藤君子さんんのインタビューで紹介されている、押井さんのお嬢さんの言葉がとても印象的。

押井さんについては、こんなに物忘れの激しい私でも忘れられないことがありまして。実は、録音の時に、押井さんのお嬢さんがいらしていたので、「どんなお父さん？」て聞いてみたんです。そうしたら、「このお父さんで本当によかった」って言うんですね。「だって自分のためにこんなにいろんな話をしてくれるお父さんって、他にいないと思うから」って。作品についての話よりも、「Ｆｏｌｌｏｗ Ｍｅ」を歌うためにはこの言葉で十分だったのかも知れませんね。

「イノセンス」主題歌を歌う伊藤君子さんに聞く(2004/2/24)より引用

娘さんにもあの調子で語ってるんだ…という点はさておき(笑、僕も娘が大きくなったらこんな風に言ってもらえるような父親になれるでしょうか。がんばらないと。