土曜日にIPA未踏の成果発表会に行ってきました。

• http://www.ipa.go.jp/jinzai/mitou/2008/2008_2/hontai/event/kato-takeda-program_20090801.pdf

午後から参加したので、最初があのOnixでした。

グリーンOSに半信半疑でしたが、素晴らしいプレゼンでした。既存研究(通常のメモリでディスクへの読み書きをキャッシュしてHDDを休ませてグリーン化)の話から始めて、メモリ容量とディスク容量の桁の違いからうまく機能しないのではないかという疑念につなげて、SSDがHDDを休ませるための永続キャッシュとして最適ではないか、という導入部の流れは感動的なほどスムーズでした。

導入部がうまく行けば後はプレゼンが流れるように進み、見事に時間が余りました(本人が持ち時間を間違えていたようですが)。

質問もだいたい想定内ばかりでした。アリエル社内で厳しいツッコミに耐えてきた大山さんとすればかなり余裕だったのではないでしょうか。

次の発表は街角ネット世界コミルバでした。Web上にアバターを出して街角感を出す(いい意味でも悪い意味でも)未踏っぽい発表でした。

率直に言うと個人的には問題意識を共有できていません。自分にとってWebはやはり文書DBの延長で、あえて現実世界にたとえれば図書館です。Webに街角感が必要と言われても、まったく共感できません。しかし、文化や世代が変わればWebに出会いを求める人もいるのでコミルバのようなアプローチを否定する気はありません。

次がApacheのモジュールでロードバランサーを作り背後のサーバを休ませてグリーン化するネタでした。ツッコミどころ満載でした。少し質問したら実装レベルの話で逃げようとしました。たぶんApache内部の難しそうな話をしたら諦めると思ったのでしょう。こちらはAPRを7年以上使っていますし、昔、IPAから金をもらってApacheの内部実装を調べていたぐらいなので(https://www.codeblog.org/blog/inoue/)、そんなところ逃げたって無駄だよと言う感じです。しかし公開処刑が趣味ではないので適当に切り上げました。

ここまで聞いてOnixのレベルが他を圧倒しています。これはもしかして大山さん、スーパークリエイター当確か、今度からスパクリ大山と呼ばないとダメかなと思っていたら、最後に度肝を抜く発表が待っていました。

最後の発表は、iPhoneを使い音声メモを空間に張り付けるネタです。裏側を読解してしまえば、位置情報と(ヘッドセットから取得できる)向き情報をキーにして音声を記録するだけですが、このような読解は些細な話です。何よりも空間に音声メモを張り付けるという発想と、それを実現してしまったことが凄い点です。

フィクションで、場が映像や音を記憶するというモチーフが使われることがあります。特殊能力を持った人に、場が記憶する過去の映像が見えたり音が聞こえたりする話です。この力で事件の謎を解いたり事件に巻き込まれたりします。今回の発表の音声メモのネタを使うと、空間が声を記憶するモチーフが特殊能力無しに実現できます。殺人事件現場に立つ探偵が空を見上げて、過去発せられた声に耳をすましてダイイングメッセージを探しだす、なんてシーンが思い浮かびます。

発想力、実現する技術力、プレゼンでの訴求力、これら総合力でIPA未踏史上、屈指の発表だった気がします。残念ながらOnixがかすみました(でも相対的に見てスーパークリエイターの可能性は70%ぐらいある気がします)。

• http://code.google.com/p/sqlitecs

sqliteをC#で再実装したものの発表がありました。

DRH(sqliteの作者)からsqliteの名称を勝手に使うのはやめてほしいと言われたようです。たぶん名称が変わります。

• http://code.google.com/p/sqlitecs/wiki/FAQ

FAQによると速度はC版の4分の1から5分の1程度です。もう少し速くてもいいと思います。作者も言っていますがたぶん実装の問題でしょう。

MLの反応は微妙です。よく読むと、声の大きなひとりが否定しているだけのようですが。

Hummm... Guess there is a reason there are no implementations of C# external to the Mickeysoft world :-)

これはMSとC#を全否定している発言なんでしょう。これが伝統的オープンソースマインドです(皮肉です)。

Monoはなんとなくまがい物を使わされている気分になるのが欠点です。とは言え、そろそろMonoを触ってみようかと思いつつ1年ぐらい経っています。

APRのセキュリティパッチです(Apache httpdには影響ありません。当然、AirOneも大丈夫です)。

• http://www.apache.org/dist/apr/patches/
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2412

バグの元凶は次のマクロです。

/* APR_ALIGN() is only to be used to align on a power of 2 boundary */
#define APR_ALIGN(size, boundary) \
   (((size) + ((boundary) - 1)) & ~((boundary) - 1))

マクロの意図は、第1引数のsize以上かつboundaryの倍数を返すことです。実例の方が分かりやすいので、boundaryを8にして次のコードを動かしてみます。

#include <stdio.h>
int main()
{
    unsigned int i;
    for (i = 0; i < 24; i++) {
        printf("%u %u\n", i, APR_ALIGN(i, 8));
    }
    return 0;
}

結果は次のようになります。

0 0
1 8
2 8
3 8
4 8
5 8
6 8
7 8
8 8
9 16
10 16
11 16
12 16
13 16
14 16
15 16
16 16
17 24
18 24
19 24
20 24
21 24
22 24
23 24

第1引数(size)を入力、マクロの結果を出力と思えば意図は自明だと思います。普通に見ていると、出力は入力以上の数値になりそうです。しかし、セキュリティパッチは、出力が入力(size)より小さくなることがあることを示唆しています。

上のコードのループを次のように変更してみます。

for (i = 0; i < ~0; i++) {
    if (i > APR_ALIGN(i, 8)) {
        printf("%u %u\n", i, APR_ALIGN(i, 8));
    }
}

動かすと次のようになります。

4294967289 0
4294967290 0
4294967291 0
4294967292 0
4294967293 0
4294967294 0

実際に言われてみれば、という感じですが、Apacheのソースコードは相当数の目に晒されてきたはずなのに誰も気づきませんでした。

ここで注目したいのがqmailです。

• http://www.google.com/codesearch/p?hl=en&sa=N&cd=3&ct=rc#k-Egc8xEO4Q/qmail-1.03/alloc.c&q=qmail

似た目的のマクロを持っていますが、次のようにしっかりとオーバーフローの可能性を明記しています。さすがdjb、ひとりでASFを越えています。

n = ALIGNMENT + n - (n & (ALIGNMENT - 1)); /* XXX: could overflow */

JDK2ことJD勝さんにJavaScriptライブラリ3種のグリッド(カラムをリサイズ可能なテーブル)の実装を調べてもらいました。

• YUI(Yahoo! UI Library)
• jQuery(Grid)
• Ext JS

それぞれの実装の骨格だけを再現したのが以下のコードです。JavaScriptのグローバル変数が気になる、とか言いたいことがあるかもしれませんが無視してください。

• http://dev.ariel-networks.com/misc/grid/all-yui.html
• http://dev.ariel-networks.com/misc/grid/all-jquery.html
• http://dev.ariel-networks.com/misc/grid/all-extjs2.html
• http://dev.ariel-networks.com/misc/grid/all-extjs.html (Ext JS改変版)

Ext JS版は元実装が気に入らない(by JD勝さん)とのことで改変版もあります。

それぞれの実装を簡単に説明します。

YUI版:

• テーブルの1行が <tr><td><div>col1</div></td><td><div>col2</div></td></tr> の構造
• 上記<div>にカラムごとにクラスを指定
• カラムリサイズ時にdocument.styleSheets内で上記クラスのスタイルを変更
• マルスケでも採用

jQuery版:

• テーブルの1行が <tr><td>col1</td><td>col2</td></tr> の構造
• カラムリサイズ時にテーブル要素の rows[0].cells[col].style.width の値を変更

Ext JS版:

• テーブルの1行が <table><tr><td>col1</td><td>col2</td></tr></table> の構造(行数分のテーブル要素が存在)
• カラムリサイズ時に全行のテーブル要素の firstChild.rows[0].childNodes[col].style.width の値を変更

Ext JS改変版:

• テーブルの1行が <tr><td>col1</td><td>col2</td></tr> の構造(jQuery版と同じ)
• カラムリサイズ時にテーブル要素の全行の cells[col].style.width の値を変更

行数が増えた場合の体感速度は、速い順に次のような感じです(Firefox3)。

jQuery > YUI > Ext JS

体感速度ではなくJavaScriptのコード実行時間を計測しろと言われそうですが、今回の場合、コード実行時間にあまり意味がありません。例えばYUI版はスタイルの書き換えだけなのでJavaScriptの実行はすぐに終わります。しかし、カラム幅が実際に変わるのは、その後の再レンダリングが終わる時です。

Java本「Perfect Java」の発売がもうすぐです(9月16日)。

最終工程の作業がアナログでした。目次と索引を手作業で作りました。手作業と言っても紙に手書きという意味ではなく、目次の場合、章や節とページの対応を人力で拾った、という意味です。結果として校正も兼ねることになったとは言え、データが電子化されているとは思えない世界です。

入稿までは自分の世界(Emacsで作業)でしたが、入稿後は作業が向こうの世界(Mac?)に行ってしまった印象です。

こう考えるとTeXは偉大です。DTPの最終工程に近いところまでEmacsで作業ができるのですから。

とは言え、本作りを一通り経験したのは良いことでした。次に書く時は今回よりもっとうまくできる気がします。

家で社内に流れているtracのメールを見ていたらTomcatの一部のデフォルト設定がデバッグ向けになっていることを知りました。下記リンク先のdevelopment設定です。

• http://tomcat.apache.org/tomcat-6.0-doc/jasper-howto.html#Production%20Configuration

知りませんでした。

Tomcatの設定ファイルのリファレンスのトップ(http://tomcat.apache.org/tomcat-6.0-doc/config/index.html)から1クリックのリンク先はすべて目を通していた(覚えているわけではない)のですが、上記のJSP周りの設定は別にあるので全然知りませんでした。設定ファイルリファレンスにすべてが網羅されていると思っていたので、だまされた気分です。

それはともかく。

ここで注目したいのがgenStringAsCharArrayです。名前からしてCっぽい最適化の匂いがします。

この設定を使っているのは

• [Tomcatのソースツリー]/java/org/apache/jasper/compiler/Generator.java

内の

• public void visit(Node.TemplateText n) throws JasperException {

の中です。

次の1900行目です。

• http://www.google.co.jp/codesearch/p?hl=ja&sa=N&cd=1&ct=rc#KNqCNnRERSg/apache-tomcat-6.0.10-src/java/org/apache/jasper/compiler/Generator.java&q=Generator.java%20tomcat-6.0&l=1900

visitメソッドのやっていることは、JSPファイル内の通常テキストをJavaのサーブレット用コードのout.write("...")に変換することです。簡単に言えば、JSPファイル内に abc と書くと、Javaのサーブレット用コードの out.write("abc") になり、HTTPのレスポンス出力の一部になる、という理屈です。CGIを知っている人はout.writeが標準出力処理に相当すると考えてください。

以下、説明が繁雑になるのでエスケープ処理は無視しています。

genStringAsCharArrayがfalseの場合(デフォルト)、普通に out.write("abc") 相当の文字列を生成します。

genStringAsCharArrayをtrueにすると、次のようなコードを生成します(JSPに書いた文字列が abc の場合)。

static char[] _jspx_char_array_1 = "abc".toCharArray(); // 実際にはクラスフィールド
out.write(_jspx_char_array_1);

上記の _jspx_char_array_ の部分は固定文字列です。1 の部分は内部的にインクリメントする数値です。

高速化のポイントは、一度現れた"abc"をキーにして_jspx_char_array_1の名前を内部で記憶しておくことです。2度目に同じ文字列"abc"がJSPに現れると、生成されるコードは次の行だけになります。

out.write(_jspx_char_array_1);

姑息です。少しTomcatが好きになりました。

ところで、これ本当にパフォーマンスの効果はあるのでしょうか。