2008年8月

『スカイ・クロラ』と『空の境界　第五章　矛盾螺旋』

今日は1日することもなかったうえ、午前中は雨も降っていなかったので映画でも観にいくかという気になった。そんなわけで新宿まで『スカイ・クロラ』と『空の境界』を鑑賞に。

先にテアトル新宿まで行って『空の境界』レイトショーのチケットをとろうと思ったら、タカシマヤタイムズスクエアにあるテアトルタイムズスクエアの方が空いているとのこと。時間も 16:00 からある。

ということでトボトボと歌舞伎町方面へ。新宿ミラノ3で『スカイ・クロラ』を観た。

そしてテアトルタイムズスクエアで『空の境界』。

『スカイ・クロラ』はいつもの押井節を「作画で」やってみた、という感じの作品に仕上がっていた。台詞が比較的少ない分、作画の、特に人間の情報量を上げまくっている感が。でもディズニーのそれみたいに破綻していない。きちんと人間の動作として受けとめられる。

押井監督は、各種メディアでメッセージ性を極端にアピールしているが、確かに比較的わかりやすい。過去作を考えれば、わかりやすすぎるぐらい表に出てきている。だが、あえて「世間一般でいう」わかりやすさとは変えている。そうしないと単なる説教臭い駄作になってしまうからだろう。少なくとも表面上、陳腐化の回避には成功していると思う。

だが、副作用もある。何も考えないで画面に反応するだけでは、監督の意図したものはわからないのだ。テーマがテーマなだけに思考が必須になる。しかし、過去作よりは思考に必要な過程を作品内でこれでもかと明示し、辿り着きやすくしている。このバランスは非常に危うい。やりすぎれば駄作になり、やらなさすぎればいつもの押井節になる。

結局のところ、監督は「わかる人にだけ観てもらえればいい」ではなく、「わかってくれる人をできるだけ増やす」努力をしたのだ。その結果が『スカイ・クロラ』といえるだろう。

『空の境界』のほうは、これまたうまい具合にまとめていてびっくりした。あの長大な章をわずか2時間足らずの間に抑えたのは、もっと評価していいと思う。

全体としてはきちんとニュアンスを拾いつつ、臙条巴の表現をがっつりと増やした印象。相克する螺旋、すなわち太極図を非常にわかりやすいスイッチとして図案化し、時折挟んだ演出がわかりやすさを助長する。あらゆる対立関係が、しかしどこかで混じり合い、それが全て螺旋と化している様子を、文章から見事に映像化したといっていいと思う。

2008-08-31

IE8 Beta 2 バグ報告へのレーティング求む

まず大前提の情報をひとつ。IE8 バグ潰しの特効薬はレーティング。……さて、去る日本時間2008年8月28日、ついに IE8 Beta 2 がリリースされた。早速インストールしてみたが、残念ながら新規バグも相当数出ているようだ。

IE8 には、IE7 の時もやっていたという「フィードバック」（バグ報告）を行えるサイトが立ち上げられている。他のプロダクトと同様、それは Microsoft Connect の中に Internet Explorer Beta Feedback という名で定義されている。とりわけ重要なのはフィードバックのページだ。

Microsoft の五寳氏がウィンドウズ開発統括部の blog 内で Microsoft Connect への参加方法としてまとめてくれている。まだ色々ヤバいバグがありそうなので、是非「コレはヤバい」というバグが見つかったら、どんどんレートを上げるとよい。

何しろ IE8 の品質が下がれば、苦労するのは我々のようなサイト作成者である。バグがなくなるに越したことはない。……こんなこと言ってると、「お前 M$ の手先だろ」と言われそうだが、個人的に IE6、IE7 のような地獄だけはもう嫌なのだ。最低限、クリティカルなバグだけは無いようにしてほしい。それだけが願いなのだ。

特に「トップ アクティブ バグ レポート」にある5件は、週に1回開かれるという IE 開発チームのミーティングで必ず議題に上げられ、絶対に検討対象になるという。そして、この「トップ アクティブ バグ レポート」に掲載される唯一の手段こそ、バグレポート（フィードバック）のレーティングが高いことなのである。

つまり、レーティングが高い → 「トップ アクティブ バグ レポート」に掲載されやすい → 検討対象になりやすい → 修正されやすい、という具合なのだ。

また、レーティングは Windows Live ID （Hotmail アカウント）を持っている人なら誰でも編集できる。繰り返しになるが、是非「コレはヤバい」というバグが見つかったら、どんどんレートを上げるとよい。

あと、日本人がバグを登録するときは検索をやりやすくするため「タイトルに JP: を含める」というローカルルールがある。日本人が書いたと思しきバグを見つけるには、JP: を検索キーワードにするといいだろう。

更には、検証した結果、自分の環境でも出るよ、という方は「検証」に項目を追加すると尚 good だ。最低限必要なのは、「検証の有無」項目だけである。出たら「はい」、出なかったら「いいえ」を選ぶ。コメントに環境の情報などをつけるともっと good になる。

2008-08-29

Firebug 1.2 Released

ついにベータがとれる時がきた。Firebug 1.2 がリリースされた。John Resig 氏が Blog で明らかにした。Mozilla Add-ons では、00:38 時点ではまだダウンロードできない。危険を承知の上であるならば、getfirebug.com から直接ダウンロードすることはできる。ファイル名は firebug-1.2.0.xpi。つい先日 Beta 15 が出た（15という数字が Firebug への期待、関心、完成度を高める努力を物語っている）ばかりの正式版リリース。

Firebug 1.2 に至るには紆余曲折あったようである。1.1 系はついにベータ版しか出なかった（最終版は Beta 12 であった）。現在では getfirebug.com からも削除されており、公式なモノを入手することはできない。

Firebug 1.2 系は Firefox 3 以上のみをサポートしている。つまり、まだサポート期間中である Firefox 2 系で利用するには、現在のところ Firebug 1.0 系を利用するか、Firebug 1.1b12 を利用するしかない。

Firebug の開発は停滞していた時期があった。そこでテコ入れされたらしいのだが……詳細な経緯はどこに書いてあったっけか。John Resig 氏の Blog だったか。

2008-08-26

MIAU 公開シンポジウム「Google ストリートビュー"問題"を考える」

MIAU が今度は Google ストリートビューに関するシンポジウムを開催するとのこと。今週の水曜、つまり8月27日のことだ。日本版ストリートビューが公開されたのが8月5日なので、シンポジウムという形式にしてはかなり素早く準備したのではないか？　と勝手に思っている。

実は、このシンポジウムが開催されるのは東京は杉並区、阿佐谷にある産業商工会館。地図を Google マップの、しかもストリートビューつきで見せているあたり、確信犯である。

これには是非とも参加したいが、仕事が18時に終わったとしても……ギリギリか。なまじ自宅から徒歩数分の場所なだけに、こう、絶妙な時間帯というのが何ともはや。

2008-08-25

TraceMonkey による Firefox JavaScript 高速化2 - chrome 用

昨日のネタにひとつ追記。Chrome 用の設定もあるようだ。次の about:config 項目を true にすればよいらしい。

javascript.options.jit.chrome

そういえば Internet Explorer 8 Beta 2 は8月中だったか……。どこかで8月28日リリースという情報を見た気がするのだが（ソースは失念）、どうしたもんかね。

2008-08-24

不安定注意？ - TraceMonkey による Firefox JavaScript 高速化

Mozilla Links（日本語版）で報じられたように、Firefox 3.1 には TraceMonkey と呼ばれる最適化機能が実装されるとのこと。既に Trunk には実装が入れられており、今すぐテストしてみることも可能だ。次の about:config 項目を true にすればよい。

javascript.options.jit.content

Mozilla Links によると、イメージエディタでテストすると差が歴然となるらしい。実際に試してみたが、確かに true にした後の方がスムーズに処理できているようだった。体感でもわかるぐらいの差は出ているということか。

Brendan Eich 氏のブログエントリ（そもそものパフォーマンステストをやった張本人）、John Resig 氏のブログエントリ、Ajaxian の記事も参考になる。

どうやら Mozilla が開発する C 言語による JavaScript 実行エンジンである SpiderMonkey を JIT コンパイラとして機能させるプロジェクトのコードネームを TraceMonkey と呼称しているようだ。JIT コンパイラであることは、about:config の項目名からも窺い知れる。

つまるところ、Firefox 3.1 ではより高速な JavaScript の実行を期待できるというわけだ。

しかし、まだ非常に不安定でもある。現在、前述のオプションを true にしたままテストしてみているが、クラッシュ回数が劇的に増大した。ここ5時間で既に3回はクラッシュしている。下手に true にすることは、まだお薦めできない。

だが、最適化の効果は抜群だ。これからの実装状況にとても期待できる。

2008-08-23

ひどい名称 - Firefox が Nightly で children プロパティでの子「要素」アクセスを実装

昨今話題になりつつある Element Traversal。この実装絡みで Mozilla Firefox の Nightly に children プロパティが実装された。関連 bug は Bug 447917。Comment #12 によると、どうやら元々存在していた mozChildElements を名称変更しただけの様子。しかし、個人的には children という名称がとっても問題アリだと思っていたりする。

まず何より問題なのは、肝心の Element Traversal 仕様には要素だけを収集した NodeList を取得できるインタフェイスが定義されていないらしいということだ。つまるところ、childNodes の要素のみバージョンが欲しいという話である。これでは for でぶん回して処理させることができない。一番よく使うであろう機能がないなんて……。それでいて、何故か子要素（つまり nodeType が1のノード）の数は childElementCount で取得できるようになっている。どうせなら、childElementNodes なり childElements なりを定義すればいいのに（前者の方が命名規則的には妥当？）。

ちなみに、議論自体はされている。Should the ElementTraversal Interface Have a Nodelist? がそれだ。Description によると、どうやらモバイル環境を考慮しているらしい。Doug Schepers 氏による投稿によると、NodeList が Live であろうが static （not live のこと？）であろうが、実装すると環境に対する負荷が大きいから……というのが理由らしい。それならば実装を MUST でなくせばいいような気もするが、どうなんだろう？　一応、現時点での最新である 2008-08-13 版の Editor's Draft を確認してみたが、NodeList を取得できるインタフェイスは定義されていなかった。やはり仕様には盛り込まない方針なのだろうか。

そして一番の大問題は、children が一見して「要素」を取り扱うプロパティには見えないこと。実に直感的でない。しかも、歴史的な背景が邪魔をしている。その歴史とは……何を隠そう、いつもやらかしてくれる Internet Explorer の独自拡張である。

元々 children プロパティは IE に独自実装された機能であった。その仕様は MSDN にもきちんと掲載されている。読んでみると、DHTML Objects のコレクションである、という記載がある。IE でいうところの DHTML Objects とは、つまるところ要素ノードのこと。つまり、children プロパティは確実にその内容が要素であることを保証している。

この children プロパティは、検証してみたところ Safari 3.1.2、Opera 9.27、Opera 9.52 には実装されていることがわかった。動作はいずれも nodeType が1のノードを収集するというもの。今まで Gecko のみが実装してこなかったわけだが、ここにきて mozChildElements のリネームという形で実装されたというわけだ。

要素ノードだけを収集できる NodeList を取得できる機能が実装されること自体には大賛成なのだが、いかんせん名称がひどすぎる。これでは IE のもたらした負の遺産を、ずっと継承することになりかねない。一刻も早い名称変更と、仕様への追加を求めたい。

2008-08-22

プロパティ属性・内部プロパティを設定する - Object.defineProperty

昨日、私は Object.seal()、Object.freeze()、Object.preventExtensions() が使いにくいと書いた。それもそのはずだ。何しろ、最も汎用的なプロパティ属性・内部プロパティの設定方法があったのだ。それが Object.defineProperty である。

実例を交えた解説が amachang 氏のエントリにある。ということで、私はより仕様に密着した側面から少しばかりの検証を試みる。

Object.defineProperty(O, P, Attributes)

オブジェクト O に対し、プロパティ P を設定する。その際、各種プロパティ属性 Attributes を定義する。

Attributes は内部関数 ToPropertyDescripter(Desc) によって P への関連付けが行われる。Desc には次の値が入る。

undefined

ToPropertyDescripter() の返値は undefined になる。

Object オブジェクト

次の形式でプロパティ属性を設定することができる。省略時は各々のデフォルトに従う。

// someValue:     任意の値
// boolValue:     真偽値、ただし内部関数 ToBoolean で変換されるのでその他の値も可
// functionValue: function オブジェクトないし function リテラル
{
    value      : someValue,     // [[Value]] プロパティ属性値を設定
    enumerable : boolValue,     // [[Enumerable]] プロパティ属性値を設定
    flexible   : boolValue,     // [[Flexible]] プロパティ属性値を設定
    writable   : boolValue,     // [[Writable]] プロパティ属性値を設定
    getter     : functionValue, // [[Getter]] プロパティ属性値を設定
    setter     : functionValue  // [[Setter]] プロパティ属性値を設定
}

プロパティ属性の意味は次の通り。

プロパティ属性名	意味
[[Value]]	プロパティの値
[[Enumerable]]	for-in 構文での列挙可否
[[Flexible]]	delete 演算子での削除可否
[[Writable]]	[[Value]] 値の変更可否
[[Getter]]	ゲッタ関数
[[Setter]]	セッタ関数

つまり、Object.seal()、Object.freeze()、Object.preventExtensions() は Object.defineProperty() の糖衣構文 (syntax sugar) だったのだ。そりゃ、機能が制限されていて当然である。

これで色々とスッキリしたー。やっぱり定義されていたんだ。

それにしても、前々から言われていることだが、仕様書読みにくいなぁ。処理系の実装者向けに書かれているのは周知の事実だが、こうまで大量の参照があると PDF や Word 文書ではなく、W3C の勧告仕様のように XHTML/HTML 文書として整備してほしい。

2008-08-21

ECMAScript 3.1 の Object.seal()、Object.freeze()、Object.preventExtensions() は少々使い勝手が悪い？

ECMAScript 3.1 (2008-08-18 Working Draft) の Object オブジェクトコンストラクタのプロパティには、これまで触ることのできなかったプロパティ属性・内部プロパティへのアクセスを可能にする関数が定義されている。次に列挙した3種である。解説は概略。私の勘違いがある可能性に注意。

Object.seal(O)

オブジェクト O が持つ全ての固有プロパティ P に対し、[[Flexible]] プロパティ属性値を false にする。

つまり、P に対し、delete 演算子でプロパティを削除できなくする。

Object.freeze(O)

オブジェクト O が持つ全ての固有プロパティ P に対し、[[Flexible]] 並びに [[Writable]] プロパティ属性値を false にする。

つまり、P に対し：

• delete 演算子でプロパティを削除できなくする
• 値の代入ができないようにする

Object.preventExtensions(O)

オブジェクト O に対し、[[Extensible]] 内部プロパティ値を false にする。

つまり、O に対し、プロパティの追加が一切できないようにする。

軽くプロパティ属性・内部プロパティに関しても触れておこう。

[[Flexible]]

プロパティ属性 (property attributes)。

true ならば、delete 演算子によるプロパティ削除が有効になる。

false の場合と ECMAScript 3 の DontDelete プロパティ属性は同義である。

[[Writable]]

プロパティ属性 (property attributes)。

true ならば、プロパティ値の変更が有効になる。

false の場合と ECMAScript 3 の ReadOnly プロパティ属性は同義である。

[[Extensible]]

内部プロパティ (internal property)。

true ならば、オブジェクトへのプロパティ追加が有効になる。

Gecko 1.9 (Mozilla Firefox 3.0) が Object 要素などに対してかけようとしていた制限と同様の概念。

さて、これまで延々と紹介してきた Object.seal()、Object.freeze()、Object.preventExtensions()。これらは現状のプロトタイプベースオブジェクト指向プログラミングの手法と組み合わせるには少々おおざっぱすぎると思っている。何故なら、引数として与えたオブジェクトないしその全プロパティに対し、一律に実行されてしまうからだ。

次のコード断片は、Test オブジェクトのコンストラクタと prototype プロパティの例である。

function Test() {
    // 何かてきとーなコード
}

Test.prototype = {
    doFoo : function() {
        // 何かてきとーなコード
    },

    doBar : function() {
        // 何かてきとーなコード
    }
};

さて、ここで doFoo にだけ [[Flexible]]、[[Writable]] プロパティ属性値を false にしたい場合はどうすればいいのだろうか？　Object.freeze() を使えばいいように思われる。

しかし、Object.freeze() では効果範囲が広すぎて、doBar の [[Flexible]]、[[Writable]] プロパティ属性値も false になってしまうのである。

次のコード断片は、先のコードに対して実際に Object.freeze() を適用している例である。

// そもそも prototype プロパティに適用できるかどうかも疑問……
Object.freeze(Test.prototype)

これでは思ったとおりにはいっていない。……ううむ。これでは利用価値が下がってしまうのでは？　それとも、他に方法があるのだろうか？

個人的には、Object オブジェクトコンストラクタのプロパティだけに freeze などを追加するのではなく、Object オブジェクトの prototype オブジェクトのプロパティにも加えた方がよいのではないかと思う。あと、制御できるプロパティ属性や内部プロパティにもっと直結した getter/setter 形式でもよい気がする。……今提示した方法も、問題点ありそうなんだよなぁ。

ああ。言語仕様を造るのは本当に難しいことだ。実際に作業されている方々の苦労が偲ばれる。

2008-08-20

次期 ECMAScript は 3.1

各所で既報だが、個人的にはとっても嬉しいニュース。つまりこれは、JavaScript 2.0 のベースとなる言語が、激しく仕様が変更される ECMAScript 4 ではなく、マイナーバージョンアップにとどまる ECMAScript 3.1 になるということを意味するらしい。個人的に ECMAScript 4 はまったく魅力に欠ける言語になってしまっていただけに、この変更は素直に喜びたい。……不安材料もあるのだが。

詳細はスラッシュドット・ジャパン、マイコミジャーナルの記事、John Resig のブログ、Brendan Eich の投稿（邦訳）を参照。

言語仕様は拡張しすぎてはならない、と私は思う。この考え方は古くからある。C 言語のコミュニティに伝来する "Keep it simple, stupid" というスローガンは、正鵠を射ている。

かといって、仕様を変更しないことが善であるわけでもない。時代のニーズに即した機能を、こまめな検討により随時導入していくこともまた大事だ。これもまた C 言語のとった政策（？）である。最新仕様である C99 には、C++ から取り込まれた素晴らしい拡張機能が搭載されている。どうやら、同様のことを ECMAScript 3.1 はやるようだ。ECMAScript 4 の良い点をバックポートして導入するとのこと。

少なくとも、次の機能が ECMAScript 3.1 の新機能になるようである。他にもあるとのこと。仕様書読め、ってことか。

• getter/setter
• Object.freeze()
• Name オブジェクト
• let （式・文・定義の全てが入るかは明記がない）
• 式クロージャ
• 分割代入

他には、次のバージョンを選択できる言語内の pragma 指定などが検討されているとか。……なんか、pragma ってトラウマなんですが。いや、C 言語の pragma がひどい仕様なんで。こいつには近づかないで生きてきたんで。別の言語のハナシで申し訳ないが。

明日はちょいと気になった Object.freeze() について調べてみる予定。このエントリにある利用法、どうも違うと思うんで……。つか、コンストラクタの記述法が違ってると思う。仕様書急いで読まなきゃ！

2008-08-19

休息の日、睡眠の日

疲れはとれた。実にいいことだ。今日は一日、有給をとってお休み。6日間に仕立てあげた休暇は平穏だった。

最近は、先日購入したノートをメインマシンにしてしまっている。メモリを喰う作業は全部そう。この文書を書いているのもノート。今のところ特に支障はない。一番の利点は、Gigabit Ethernet ポートがあることか。RWIN をきちんとカスタムしているので、調子がいい時は実測で 90Mbps は出てる (11.25MByte/sec)。調子が悪いと半分くらいになってしまうが、まあそれはそれ。以前と比べて格段に快適な環境は実に気持ちいい。

2008-08-18

夏コミ終了

2日目と3日目に行ってきた。3日目は始発。

2日目はリストアップした項目の数が少なかったため、特記するようなことはあまりない。案の定、松浦リッチ研究所の仮想マシン本はいい出来だった。待った甲斐はある。しかし暑かった。あっという間に体内の水分が消え失せていく熱気。シャツとタオルは塩辛さがまったくない、水のような汗でびちょびちょ。水分補給こまめにやっておいてよかった。

3日目は……とても涼しかった。天気予報によると、9月中旬～下旬ぐらいの気温だったとか。雨も、ビッグサイト周辺は霧雨がパラつく程度で、ひんやり感を更に増長してくれて助かったり。トッププライオリティなものはあらかた買えたし。

もえじら組のスペースに顔出してみたら、二代目（♂）と四代目のふぉくす子がいた（Piro 氏は不在？）。いや、二代目は別のコスだったのだが。少しだけ会話してきたのだが、そこで二代目からトンデモない提案が。いや、だから○○○○○○○○に○○禁本を持っていくなんて……それどこの勘違い勇者w　むしろ愚者www

とりあえず公言はしておく。絶対に持っていきません。

そして四代目は既刊の朗読を開始。……ええと、ごっつぁんです（色々な意味で凄かったっす）。

そういえば、意外と穴場らしい（？）のが、トラックヤードに出るシャッターのすぐ近くにある自動販売機。一応標識はあるものの、一目見ただけではわからない位置に自動販売機が整然と並んでいるため気づかれにくいようだ。人もそれほどいない上に、クリスタルカイザー (110円) ならほぼ確実に買える（スポーツドリンクとお茶系は売り切れていることがほとんど）。塩分が心配なら、市販の岩塩をちっちゃなケースにでも入れて持っていけばいい。3～4粒くらい飲み込んでおけばしばらく保つ。

2008-08-17

明日は夏コミ1日目（用事はない）

個人的に用があるのは2日目と3日目。特に2日目は U○IX 近傍のジャンルが集中している。パっと見で面白そうなのは USAGI 補完計画と松浦リッチ研究所あたりか？　仮想マシン本はちょっと期待。

今年は軍資金が例年に比べて少ないのが気になるなぁ……。色々と無理してたのが祟ったか。まあ「絶対確保」なブツ以外は諦める方針でいけば、それなりに削れるはず。

2008-08-14

阿佐ヶ谷七夕まつりの「はちゅねミク」、ついに livedoor でニュースに & 本人降臨！　ニコニコ動画にはちゅねミク制作過程動画アップロード

先日紹介した阿佐ヶ谷七夕まつりに登場した巨大「はちゅねミク」。後になって話題になりつつあるようだ。ついに livedoor ニュースが取り上げるまでに至っている。

更に、製作者本人による制作過程動画がニコニコ動画にアップロードされていた。次に列挙したリンクはその投稿順になっている。

1. 巨大なはちゅねミクを作ってみるよ【未完成】‐ニコニコ動画(夏)
2. 巨大なはちゅねミクを作ってみるよ（２）【まだ未完成】‐ニコニコ動画(夏)
3. 巨大なはちゅねミクを作ってみるよ（３）【やっと完成】‐ニコニコ動画(夏)

地元民でよかったー。現物をナマで見れたし。

2008-08-13

阿佐ヶ谷七夕まつりに「はちゅねミク」登場

毎年8月になると、東京都杉並区の阿佐ヶ谷にある商店街、パールセンターでは「阿佐ヶ谷七夕まつり」が実施される。最大の特徴は商店街に並ぶ店などが制作した巨大なハリボテ。これが商店街の天蓋からワイヤで吊り下げられている。

ハリボテのクオリティは制作する店などにとってまちまちだが、毎年とんでもなくハイクオリティなハリボテを制作している店がある。そのひとつが「みなとや」だ。そんな「みなとや」、今年もまたやってくれた。ハリボテのお題は、何と「はちゅねミク」。それがどれほどのものかは、実際に撮影してきた写真でご覧いただこう。

「はちゅねミク」全体像。曲線の造形が見事である。ペイントの出来栄えも上々。写真下部中央左寄りに「みなとや」が見える。

別アングルからの一枚。残念（？）ながらぱんちゅは展示上の理由により visibility:hidden; 指定されているようだ。下から見上げる形になるので当然だが。

パールセンターの Web サイトにあるスナップ写真集にもバッチリ写っている。

この「みなとや」、去年も『電脳コイル』のサッチーを展示していて私を驚かせてくれた。当時もサッチーのなめらかな曲面を見事に表現していた。ハリボテは基本的に金属製のワイヤと紙で造られる（祭りの前、深夜に商店街を歩くと作業している方々を見かけることができる）。故に、少しでもワイヤが歪めば直接表面に貼りつけてある紙に影響が現れる。つまり、美しい曲面は美しい骨組みなくして現れ得ない。相当うまく工作しているのは明白だ。まさに職人芸である。

この「はちゅねミク」、見ることができるのは七夕まつり期間中のみ。つまり明日（8月10日）まで。近くに住んでいる方は、一度は見ておいても損はないだろう。

2008-08-09

さよなら絶望放送 DJCD 第四巻 & ActiveX アクティベーションの是非取得問題

届いてた。早速聴いてみると……某「ぱに」で「ぽに」なラジオとスタッフ丸カブりだったこともあり、何というか色々やりたい放題。相変わらず娘のギャラを使い込む母。いつもの三割増しでフィーリング重視なトーク。

後半は緊急ゲストの登場。500円で×っ××を○むなんて。しかも踏み倒す。そして暴走。異様なテンションのままオチというオチもつかずに終了と。

……絶望した！　相変らずのラジオ（？）に絶望した！

そして音ブログではアレの件についてひとこと。「このまま続く方が、絶望的」。――素直に喜んでいいのか、悲しんでいいのか……いや、絶望すればいいんだ。

あとで本放送も聴こう。

そういえば、IE は JScript 側から ActiveX オブジェクトがアクティブかどうか判定できない（仕様）なんだよなぁ。随分と前に Eolas 問題の解決パッチ（旧仕様に戻すやつ）は出てるし、セキュリティパッチと同梱されて自動更新でも入れば Microsoft Update のデフォルトリストにも入っているけれども、パッチ当ててない残念な環境のことも一応考えておく必要はあるわけで。IEBlog の該当エントリ（邦訳）に狂喜した日が懐かしい。

2008-08-06

IE の object 要素から代替コンテンツが取得できない - innerHTML で解決

IE の object 要素はとても厄介な代物だ。JavaScript (JScript) 経由で「object 要素の子要素」を取得しようとすると、実は param 要素しか取得できない。次のコード断片は、Flash を読み込む際に利用する object 要素の例である。

<object type="application/x-shockwave-flash" data="media/flash-test.swf" width="100" height="50">
  <param name="movie" value="media/flash-test.swf" />
  <img src="media/img-test.png" alt="Test Image" />
</object>

次のコード断片は、前述の例を IE Developer Toolbar 経由で見てみた場合のノード状況を擬似的にコード化した例である。

<OBJECT type="application/x-shockwave-flash" data="media/flash-test.swf" width="100" height="50">
  <PARAM name="movie" value="media/flash-test.swf">
</OBJECT>

手許に適当な .swf ファイルがある方は試してみて欲しい。img 要素が消え失せているのがわかるだろう。

さて、JavaScript もとい JScript 側から object 要素の代替コンテンツを取得したい場合があるとする（というか実際にあった）。この場合はどうすればよいのだろうか？

当然ながら、DOM ツリー上に代替コンテンツが存在しない。そのため次のコード断片のような JScript コードは意図した動作をとらない。次のコード断片は、ドキュメントの全 object 要素から param 要素以外の子ノードを取得しようとしている例である。Gecko、Opera (Kestrel)、WebKit ではうまくいくが、IE では何も取得できない。

var objects = document.getElementsByTagName("object");
var nobjects = objects.length;
for (var o = 0; o < nobjects; o++) {
    var childs = objects[o].childNodes;
    var nchilds = childs.length;
    var alt = [];
    for (var c = 0; c < nchilds; c++) {
        // param 要素なら除外
        if (1 == childs[c].nodeType &&
            "param" == childs[c].nodeName.toLowerCase()) { continue; }
        // その他のノードなら取得
        alt.push(childs[c].cloneNode(true));
    }
    alert(alt.length); // IE では 0 になってる（はず）
}

IE では代替コンテンツを取得できないのか？　実は、結構意外な方法で取得できてしまったりする。innerHTML プロパティを利用する方法である。

理屈は今のところ不明だが、IE は代替コンテンツとして存在しなければならないノードを object 要素の innerHTML プロパティに記憶している。しかも、純粋に代替コンテンツとして認識される部分のみが記憶されており、つまりは param 要素を含まない。よって、次のコード断片のように、innerHTML に格納されている文字列をノードに変換してやれば全てがうまくいく。

// obj は object 要素ノードへの参照が格納された変数
var altStr = obj.innerHTML;                 // innerHTML に代替コンテンツがある
var df = document.createDocumentFragment(); // 実際に利用する Document Fragment
var tmp = document.createElement("div");    // innerHTML 実行用要素

tmp.innerHTML = altStr;

var childs = tmp.childNodes;
var nchilds = childs.length;
// DOM ノード化した代替コンテンツを Document Fragment へ格納
for (var c = 0; c < nchilds; c++) {
    df.appendChild(childs[0]);
}

// あとは好きなように変数 df を使うだけ

これでようやく object 要素へのアクセスが最低限可能になった……。というより、どうして IE はこうまで直感的ではないのか。因みに、この手法は IE6、7、8 Beta 1 全てで有効。……IE8 で直ってないのか！　これはけしからんなー。

2008-08-04

『ディファレンス・エンジン』が早川から復刊される！？

悪漢と密偵経由、ビーケーワン発信（上巻・下巻）の情報。どうやら角川文庫で版元品切れ状態にあったウィリアム・ギブスンの『ディファレンス・エンジン』がハヤカワ文庫 SF から再刊されるらしい。9月上旬のようだ。早川書房の刊行予定には、まだ情報が出ていない。

未だ未読のギブスン作品。この機会に是非とも入手したいものだ。翻訳も、今は亡き黒丸尚氏によるものをそのまま利用するらしい。浅倉久志氏の訳も悪くはない（むしろ読みやすい）のだが、黒丸訳のまま刊行するのは実に嬉しい。

実は一昨日から今日にかけて、スプロール三部作（『ニューロマンサー』『カウント・ゼロ』『モナリザ・オーヴァドライヴ』）を連続で読んでいたところ。実にタイミングがいい。これで9月の楽しみがひとつ増えた。

予算があれば角川文庫版も神保町で漁りたいなぁ。……今まで見つけられないままでいたから、読んだことがなかったのだけれども。意外と置いていないらしい。

そういえば、どこで読んだのかは忘れたが、黒丸文体の特徴をひとつだけ。元々日本語にはクエスチョンマーク「？」が存在しないため、三点リーダ「……」を原文では "?" になっていた部分に利用しているらしい。例えば『ニューロマンサー』 P435 でのケイスの台詞、本当かい、マジに……は「本当かい、マジに？」と読みかえられるわけだ。浅倉訳では素直に「？」を利用しているので、両者の違和感と感じたらこの点に着目してみるといいだろう。因みに、同様の理由でエクスクラメーションマーク「！」も使われていない。この珍しい方針が、邦訳ギブスンの独特な空気感を産み出しているといっても過言ではないはずだ。

そういえば、ギブスンの新作 "Spook Country" はいつ邦訳されるのかしらん？　今年か来年中には出てくれるといいなー。

2008-08-03