今年最終の更新

いつしか31日になっていたと。実家に帰省してこれを書いているのだが、まあ環境ができていてよかった。結構ギリギリな時間帯だったりする。

30日はコミケット75に行ってきたのだが、腹の調子は相変わらず最低最悪のままだった。また、前回・前々回よりも金額・数共に少なく済んでいた。ということで早々に撤収をかけた。もえじら組はいつも通りの面子というか……平和だなぁ。日本は。

そういえば、帰省して一番驚いたのは、親父がドナルド・タイスンの『アルハザード』（学習研究社）上下巻を揃えていたこと。個人的にも欲しいよソレ！　ということでちょくちょく読ませてもらっている。帰省早々自慢されるとは思わなかった……。悔しいぞ、畜生め。

2008-12-31

よくわからん高熱と下痢でダウンしてた

どうやら内臓に何らかの病原菌が入り込んで悪さをした模様。ようやく回復しつつある途上。

24日の夜、とある店で回鍋肉を食べて紹興酒を呑んでからが全ての始まりだった。同日深夜には下痢と頭痛が出始める。25日朝は体中の関節が痛みを訴えていた。しかし大事な仕事を控えていたのでバファリンで誤魔化しつつ出社。この時点で体温は平熱。しかし25日午後にはいよいよもって頭痛と疲労感が強くなり、早退。帰宅した後は布団に潜り込んでいたが夜中に何度も起こされる。その都度下痢。26日に病院へ行き、体温を測ったら39度あった。インフルエンザのチェックをしてもらうが陰性。血液サンプルを採ってチェックしてくれるとのことで、解熱剤注射と点滴である程度の体力を回復させる。薬を処方してもらって帰宅、この日は仕事の締め日ながらも休暇をとる羽目に。

そして27日。血液検査の結果は前述した通り。炎症反応があるものの白血球の増加がみられないそうで、要するに病原菌は殺しきっているがダメージが残り続けている状態らしい。それでこの下痢ですか……。処方してもらった下痢止め、あまり効いてないんですけど。むしろ便秘にしてくれ。

年末のアレ、行けるかなぁ……。

2008-12-27

『ハーモニー』に登場する ETML の要素を集計中

ETML は Emotion-in-Text Markup Language の頭字語。つまり「感情」をマークアップするための言語。昨日も話題にした伊藤計劃『ハーモニー』（早川書房）に登場する作中作ならぬ作中マークアップ言語である。改めて読み返してみると、結構いろいろな種類とバリエーションがある上、明らかに感情とは関係なさそうなものまで含まれている[1]。というわけで、現在まとめてみているところ。

Warning 以降の文章は、『ハーモニー』のネタバレを含んでいる。

ていうか小説なのにどうしてそんなガジェットが必要やねん、という話なのだが、まあオチが「感情の存在しない世界」である。「感情」が何かを理解することはできなくても、判別することができるようにはなる。そういう目的で作成された言語、と考えるのが自然であるし、そもそもこの小説自体が「後々に書かれた」という設定になっている。

しかし、文法は整然としているところもあれば混乱しているところもある。「何らかのアイテム（項目）」を表現する要素が i 空要素と item 要素の2種類存在し、略されている方が「空要素」という法則があったりする。これは理に適っている。また属性と属性の間、ないし要素名と属性の間は　文字列ではなく : で区切っている。また、クォーテーション類は用いない。

しかし、空要素が SGML 風と XML 風の混在になっている。つまり、> だけで終了するものもあれば、/> で終了するものもあるのだ[2]。これは混乱している。法則性も今のところ見当らない。

意図せずこういう状況になったのか、それとも「混乱し、時間もなかった」という状況の説明をわざわざせずとも表現したかったのか。好意的に解釈すれば後者だが……。

まだ半分の200ページぐらいしか、サーチが完了していない。もう疲れたんで、残りは明日か明後日にしようと思う[3]。

脚註

  1. 動画を鑑賞している状況を表現し、その実際的な参照まで兼務している movie 要素など。
  2. i 要素は SGML 風で <i: 文字列> のみだが、part 要素は XML 風で <part:number=00:title=タイトル/> になっている。
  3. つくづく釣られてんなぁ、自分……とは思う。

2008-12-19

緩やかなる自殺への『ハーモニー』

帰りがけに伊藤計劃『ハーモニー』（早川書房）とウィリアム・ギブスン『スプーク・カントリー』（早川書房）を購入。晩飯ついでに近所のデニーズで『ハーモニー』を読みはじめたら……全部読んでしまった。『虐殺器官』もよかったが、『ハーモニー』は更によくなっている。読者の心をくすぐる小ネタの仕込みも相変わらずだが、そんなものは瑣末なことでしかない[1]。

Warning 以降の文章は、『ハーモニー』と『虐殺器官』のネタバレを含んでいる。

実のところ、『虐殺器官』と『ハーモニー』は、物語構造・主題ともどもかなり酷似している。しかしながら、最終的な規模と絶望感は『ハーモニー』のほうが大きい。そして『ハーモニー』では、『虐殺器官』ではわかりにくかった（らしい）、いわゆる「虐殺の文法」がより明示的な SF ガジェット──WatchMe──を経由して使用されている。

『虐殺器官』が「社会・肉体のディストピアと意識のユートピア」を描いたものであると仮定するならば、『ハーモニー』は「社会・肉体のユートピアと意識のディストピア」を描いているといえるだろう。言いかえるならば、『虐殺器官』において「虐殺」されるのは「社会・肉体」であるが、『ハーモニー』において「虐殺」されるのは「意識」である。無論、ここでいう「社会」や「意識」という単語に対して疑問を呈し、その意味を剥奪した上で物語を終結させているのは言うまでもない。

ディストピアとユートピアが紙一重なのは昔から言われ続けていることだが、同じ出版社から出した2作品がそれぞれを象徴し、相互に対称を成しているのは実に面白い。

個人的に残念なのは、ガジェットとして機能しているマークアップが XML の「ような」文法でありながら、しかし XML ベースの言語としては invalid であることだ。属性値はダブルクォーテーションで囲まれていないし、名前空間・要素名・属性の区別がぐちゃまぜ。その他色々ツッコミどころはあるのだが……。著者が Web ディレクタという職業（だった？）なので、技術的側面は仕方ないところなのか、それともワザとこうしたのか。何しろ DOCTYPE 宣言には次のように書かれていたりするのだから。

<!DOCTYPE etml PUBLIC :-//WENC//DTD ETML 1.2 transitional//EN>

XHTML 1.0 における Transitional DTD の場合と比較してみよう。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Transitional なものですよー、という一種の皮肉……だろうか。少なくとも、マークアップされた──意味付けされた──文書が伝えられこそすれ、それは自然言語を扱うよりも流動的にならざるを得ない。だからこその Transitional DTD なのか。

因みに「人間の感情をマークアップで表現する」というのはありそうで今まで誰も書いてはこなかったと思われる。SGML/HTML/XML を知っているならば、そこそこニヤニヤしながら読めるだろう。

ニヤニヤといえば、この作品の重要人物たる2人は明らかに百合的関係なのだが、しかし単なるソレではない。そこのところ、著者はよーくわかってらっしゃる。そのへんの、実のところはドロドロ病み病みな状態についてはまた次の機会にでも。

脚註

  1. 無論、小ネタはどれも楽しめるものなので、コレはコレで実によい。『虐殺器官』に登場した「ユージーン＆クルップス」社と〈大災渦〉を並列にして〈大災渦〉の原因を妄想するのは、単純で短絡的だが楽しいことに変わりない。やろうと思えばシリーズ化の伏線にもできる。

2008-12-18

祖父死亡により年賀の挨拶はご遠慮ください

まあ、表題の通り身内に不幸があったので。滅茶苦茶に急な話だった。タイトなスケジュールのなか通夜・葬儀・告別式その他諸々をやってきたのだが、正直体力的にキツかった……（あと正座も）。

親はともかく、孫連中も集合していた。私以外は全員30歳以上なので、年代的に差こそあるのだが、色々と昔話がきけてよかったとは思う。

ネットワーク環境が皆無だったので、今日ようやく帰宅してからいつものルートを巡ることができた。……モバイルまわりの貧弱さが今後の課題だろうか。

2008-12-15

グレッグ・イーガンの傑作選『TAP』を買い逃してた

12月3日には出ていたようだが、グレッグ・イーガン『TAP』（河出書房新社）を買い逃していたので即購入。まだ読めていない。これから読む。しかも「奇想コレクション」のひとつとして出ていたのだからちょっと驚きだ。ノーチェックだったのが悔やまれる。

ついでに小林めぐみ『回帰祭』（ハヤカワ書房 JA）も。この人は『食卓にビールを』の作者でもある。裏表紙の紹介文と冒頭読みで面白そうだと思ったんで買った。読了してから、他の作品を蒐集するかは決めたい。

そういえば西尾維新『不気味で素朴な囲われたきみとぼくの壊れた世界』（講談社 NOVELS）を読了した。内容は……言えない。ただひとつ言えることは、バックアップに要注意、ということだけ。色々と悔しかった。私はどうしてもミステリ読みにはなれないのか……。

2008-12-13

円城塔 in ユリイカ 初音ミク特集

円城先生何やってんすかw　色々話題の『ユリイカ 12月臨時増刊号　総特集♪初音ミク──ネットに舞い降りた天使』（青土社）に『Self-Reference ENSINE』（早川書房）などでお馴染み（？）の円城塔氏が『ベビーロイド』というショートショートを寄稿している。相変わらずの筆致だが、どうやらテーマはコミュニケーション、コンタクト、そして VOCALOID の行きつく先。完全に SF でありながら、SF としては破綻しているように思える。だが、どうやらギリギリのところにあるようだ。

他の論考・論文・対談・エッセイなども、『ユリイカ』だけあって相変わらず内容のバリエーションと濃度はピカイチ。まだ全部は読みきれていないが、かなり楽しめそうな代物にきっちり仕上がっている。

個人的に『ユリイカ』の特集で一番嬉しかったのは1991年1月号の「特集＝P・K・ディックの世界」。ディック大好きな者としては、これは是が非にも欲しかった。結局は神保町を探しまわって見つけ出した。あの時はただひたすらに嬉しかった……。

そのテの界隈では以前から話題になっていた、今回の『ユリイカ』初音ミク特集。ひとつの歴史を振り返るという上でも、よい書籍に仕上がっていると思う。

2008-12-12

続・DOM イベントの bubbling フェイズ終着点が UA によって違う - HTML5 仕様に定義あり

昨日の続き。vantguarde 氏のはてブ経由で、HTML5 の仕様に「bubbling フェイズ[1]において、bubbling が防がれない[2]限り、イベントは最終フェイズで Window オブジェクト[3]に送られなければならない」と定義されているらしいと知る。次に原文を引用する（強調筆者）。

When an event is dispatched at a DOM node in a Document in a browsing context, if the event is not a load event, the user agent must also dispatch the event to the Window, as follows:

  1. In the capture phase, the event must be dispatched to the Window object before being dispatched to any of the nodes.
  2. In the bubble phase, the event must be dispatched to the Window object at the end of the phase, unless bubbling has been prevented.

5.4.6.3 Events and the Window object

つまるところ、Opera が「HTML5 仕様に準拠した」と公言するには、Opera 9.5x, Opera 9.6x, Opera 10 Alpha f1 の挙動では駄目、ということになる。

勿論 HTML5 はまだ策定中の仕様だし、Opera シリーズは HTML5 に準拠しているとは公言していない。DOM 2 Events はサポートしていると謳っているので、これに従えば昨日も書いたように現状の動作で「仕様通り」となる。

ともかく、昨日書いたこのへんの食い違いを解決する場ってないのかしらんという疑問は解決したわけだ。解：HTML5 仕様（と WHATWG）

まさかここまで考えていたとは。HTML5 恐るべし。

ただ、WHATWG に Microsoft が参加していないのがなぁ。W3C に取り込まれてはいるから、一応コネクションはできていると考えてよさそうだが……。むう。

脚註

  1. 仕様書では bubble phase。
  2. 要するに stopPropagation メソッドが呼ばれたりしない限り。
  3. JavaScript では window オブジェクト。

2008-12-11

DOM イベントの bubbling フェイズ終着点が UA によって違う - resize の罠

Opera 9.5x, Opera 9.6x, Opera 10 Alpha 1 で発生する問題なのだが、bubbling フェイズの resize イベントを dispatchEvent メソッドによって任意のノードから発行した場合、window オブジェクトまで到達しないのだ[1]。

論より証拠、まずは次の段落を見てほしい。現象を実際に再現した例である（IE は除外してある）。ボタンをクリックする度に bubbling フェイズの resize イベントを発行する dispatchEvent を実行している。数値はそれぞれ window オブジェクトと document オブジェクトで resize イベントを受け取った回数を示している。

JavaScript が無効か UA が IE であるため、例を実行していない。次の段落以降を読み進めてほしい。

Firefox 3.x, Safari 3.x, Opera 9.2x, Google Chrome では両方とも値が増える。だが Opera 9.5x, Opera 9.6x, Opera 10 Alpha 1 では document の方しか値が増えないのだ。

DOM 2 Events 仕様によると、resize イベントは Bubbles: Yes なので、イベント伝搬は親要素側に発生する。そして最終的には「原点」のオブジェクトに到達する。もし window オブジェクトが原点ならば、window オブジェクトに設定されたイベントが実行されるはずである。

だが DOM 2 Events 仕様によると、どうやら bubbling フェイズは「原点」まで到達しなくてもよく、document オブジェクトを含んでさえいれば OK らしいのだ。次の引用は、そのことが書かれている部分である（強調筆者）。

（前略）This upward propagation will continue up to and including the Document.（後略）

1.2.3. Event bubbling

つまるところ、DOM 2 Events 仕様は bubbling フェイズが window オブジェクトまで到達することを保証していない[2]。だから including the Document を守っている Opera 9.5x, Opera 9.6x, Opera 10 Alpha 1 は「仕様通り」だといえるし、ついでに window オブジェクトまで到達するようにしてくれている Firefox 3.x, Safari 3.x, Opera 9.2x, Google Chrome もまた「仕様通り」なのである。

とはいえ、さすがにこの辺は各ベンダが協調路線をとってほしいものである。個人的には Firefox 3.x, Safari 3.x, Google Chrome の仕様──window オブジェクトまで bubbling フェイズが到達する──にあわせてほしい[3]。

このへんの食い違いを解決する場ってないのかしらん……？

補足：例で用いた JavaScript コード

次のコード断片は、実際に前述した例で用いた JavaScript コードである。

// IE では動作しないよう設定 (条件コンパイルを用いる)
/*@cc_on @if (!@_jscript) @*/
(function() {
    window.addEventListener("load", function() {
        var p       = document.getElementById("date-2008-12-10-test");
        var button  = document.createElement("button");
        var targetW = document.createElement("samp");
        var targetD = document.createElement("samp");

        button.setAttribute("type", "button");
        button.appendChild(document.createTextNode("実行"));

        targetW.appendChild(document.createTextNode("0"));
        targetD.appendChild(document.createTextNode("0"));

        p.textContent = "window:";
        p.appendChild(targetW);
        p.appendChild(document.createTextNode(", document:"));
        p.appendChild(targetD);
        p.appendChild(document.createTextNode(" "));
        p.appendChild(button);

        button.addEventListener("click", function() {
            // resize イベントを生成
            // とりあえず DOM 2 Events にあわせて次の設定を行う
            //   Bubbles: Yes, Cancelable: No
            var event = document.createEvent("Event");
            event.initEvent("resize", true, false);
            // p 要素に resize イベントを発行
            p.dispatchEvent(event);
        }, false);

        // resize イベントを受け取る度に数値をインクリメント
        window.addEventListener("resize", function() {
            targetW.textContent = parseInt(targetW.textContent) + 1;
        }, false);
        document.addEventListener("resize", function() {
            targetD.textContent = parseInt(targetD.textContent) + 1;
        }, false);
    }, false);
})();
/*@end @*/

脚註

  1. Firefox 2.x でも似たような問題が発生する。しかし、原因はまったく別。そもそも resize イベントが window にも document にも到達していないのだ。どうやらバグらしい？　該当 Bugzilla は不明。
  2. DOM 3 Events も、図を見る限りでは DOM 2 Events と同じで document オブジェクトを含んでいればよさそうなのだが、具体的な記述はどこだろう？　エイゴムズカシイヨ。
  3. 実は、Opera 9.2x の仕様は微妙に他と異なる。アプリケーションウインドウを本当にリサイズした時、document オブジェクトも resize イベントを受け取ってしまうのだ。Firefox 3.x, Safari 3.x, Google Chrome では window オブジェクトのみ resize イベントを受け取る。

2008-12-10

Worker を試している途中

Firefox 3.1 から実装予定の Worker オブジェクトを試しているところ。まだドキュメントや Howto を眺めて、ちょっとしたコードを書いてみている段階だが、なかなか使いどころがありそう。プロセスやスレッドといったものが存在しなかった JavaScript において、色々と面白いことができそう、という感じではある。似たようなことをやらせようとすると、これまでは setTimeout などを使うことはできたものの、やはり擬似的なものでしかなく、色々と面倒なことが多かったのは事実だ。

ただ、Worker が実装されるとなると fork 爆弾のようなものも警戒しなければならなくなるし……。どうなるんだろう、これから。

2008-12-07

Firefox をターゲットにしたマルウェア登場……

スラッシュドットのタレコミより。正規のアドオンではなく、別のものとしてダウンロードさせることで感染するらしい。感染すると Greasemonkey を詐称するとのこと。例えばドライブバイダウンロードを用いてマルウェアをダウンロードさせるらしい。

ドライブバイダウンロードとは、Web サイトを閲覧しただけでファイルをダウンロードさせる手法をいうらしい。未パッチの IE、旧バージョンの Firefox、Flash Plugin などに存在するセキュリティホールを経由するのだろうか？

何にせよ、常に最新のソフトウェアを利用するのは当然かつ必然のこと、と。Firefox 2 もそろそろサポート終了なので、注意しておくに越したことはないだろうなぁ。

2008-12-05

Opera 10.0 Alpha 1 Released - Acid3 を「一応」クリア

ついに Presto 2.2 レンダリングエンジンを搭載した Opera 10 の Alpha 版、Opera 10.0 Alpha 1 がリリースされた。激しくテスタ向けなので一般利用者は使うべきでない。

Opera 10 Alpha 1 が Acid3 テストに合格している様子（パフォーマンスはまだ不完全）何といっても最大の特徴は Acid3 のクリアだろう。前掲のスクリーンショットは私の環境でテストした結果[1]。確かに100点はとれているが、まだまだ完璧ではない様子。ダイアログにあるように、いくつかのテストでパフォーマンスに改良の余地ありとの診断が出ている。まだ Alpha 1 なのでこの辺のチューニングにも期待。

その他の詳細は A blog? with Σαιτω 参照。因みに、当サイトのメインメニュー押し込みが不完全なままという問題は解決していない。残念。

脚註

  1. CPU: Intel Core 2 Duo T7500 2.20GHz, RAM: 1.96GB で試した。

2008-12-04

Dojo が Sizzle エンジンを採用

現在組み込み中らしい。Sizzle は CSS セレクタを解釈・要素取得を行う JavaScript ライブラリ（以前にも紹介した）。Ajaxian の記事によると、将来的には DOM 操作とイベントバインディングにも対応するかもしれないらしい。……それって、要するにプロジェクト横断的な、ホントにすべての下敷き（大元）になりかねない JavaScript ライブラリが誕生するってことか？　確かに Ajaxian の寄稿者が興奮するのもわかるなぁ。

因みに Ajaxian が引用しているのは Dojo Foundation が長したメール（開発メーリングリスト宛てか？）の内容らしい。1次情報源にアクセスしづらいな。

……そもそも、こういうライブラリが不要になるのが一番いい状況なのだが。やはり、あの悪夢の時代は今後もずっと影響を及ぼし続けるのだろうか？

あと10年経ったら、どんな時代になっているのだろうか。2018年に2008年のことを思い出してみて、どんな感想・考察を抱くのだろうか。それを妄想するのもまた一興だし、これはこれで面白い暇潰しではある。

2008-12-03

The Art of Computer Programming 欲すぃ

でもなぁ……予算が。1～4まででそれぞれ ¥3,150 + ¥10,290 + ¥10,290 + ¥3,150 っていうのはね、容易には手が出ないとですよ。もっと貯金しろというのはごもっとも。

まだ色々足りてないなーと思う今日この頃。しかし自助努力だけでどこまでいけるか。

2008-12-01