3連休がこの時期に来てほしくなかった……というのが本音。祝日が有給みたいにストックできて、どこか別の日に使えたらいいのに。そしたらどこか忙しくない時にでも連休をでっちあげてやるのだが。
そしてアメリカでは金融危機なのだとか。正直、そっちには全然詳しくないので何もわからんのだが、明日の日本マーケットがどうなるかはちょいと気になる。
ということで、9月11日にマイクロソフト新宿本社で開かれた CSS Nite in Shinjuku, Vol.2 に行ってきた。詳細は、そのうち CSS Nite のサイトで公開されるであろう資料やヨモツネットの記事、kazuhi.to の記事、えむもじらの記事などで。
内容としては、非常に包括的なものだったので、ツッコんだ話題になりきれていなかったのが残念だった。だが、人数と分野の関係を鑑みればうまくまとまっていたと思う。かなり UI に関する話が多かった。Web 標準に関連した事項では、やはりレンダリングモードスイッチに関する話題が注目されていた。IE8 Beta 2 には Beta 1 に対して更に "Emulate IE8" モードが追加されていたり、イントラネットゾーンと解釈されるサイトではデフォルトで "Emulate IE7" モードになったりと色々変更されている。
個人的には、Beta 2 が出た当初から触ってうれしかった機能としてデベロッパツールで利用可能な2機能がある。JScript プロファイラと動的なレンダリングモードスイッチだ。
JScript プロファイラについては IEBlog にも記事が出ていたりするので詳細は割愛する。ただ、ひとついえるのは、IE8 Beta 2 のプロファイラは Firebug のプロファイラを越えている部分を持っているという点だ。
IE8 のプロファイラは、コールツリーを表示できる機能を持っている。これは Firebug にはない機能だ。……今のところ越えてるのはこれだけである。Firebug のプロファイラはウォッチ機能も持っていたりするので、もう少し IE8 のプロファイラは頑張ってほしい。でも、全体的にはよくできている。きちんとページロード時のプロファイルもとれるし。伊達に IDE まで自作している企業ではないということか。
ちなみに、WebKit (Safari) のプロファイラは非常に貧弱で、肝心なページロード時のプロファイルがとれないという致命的な弱点を持つ。Opera の Dragonfly に至っては実装すらしていない。
動的なレンダリングモードスイッチについては今更語ることもないだろう。デベロッパツールで変更できるようになった、という話だ。それも、"IE8 Standard Mode"、"IE7 Standard Mode"、"Quirks Mode" それぞれを。また、"Emulate IE8"、"Emulate IE7" も切り替えられる。再起動の必要ナシ。JScript の挙動もきちんと変更しているようだ。まあ、こんなモードチェンジに需要があるのも、IE が抱えた負の遺産がどれほど膨大かを物語るものだといっていいだろう。IE8 の完成度によっては……。ああ、考えたくない。
最後に、つい先日 John Resig が Podcast: Microsoft on ECMAScript, IE 8 という記事を書いていた点についての話題。どうやら Microsoft の中の人2人と Podcast をやった模様。その2人とは Allen Wirfs-Brock（Microsoft 社員、ECMA に関与）と Pratap Lakshman（JScript チームメンバにして ECMAScript 3.1 コミュニティに関与）。
そこで出たのが驚きの新事実。John Resig によると、何と The guys talked about the Object.defineProperty support added in IE8b2
（強調筆者）らしいのだ。まだ試していないので事実かどうかはわからないが、事実ならびっくりだ。
で、本題に戻る。私は CSS Nite で五寳さんにこの点を尋ねてみたのだ。「IE8 Beta 2 に ECMAScript 3.1 の実装がはいっているらしいんですが、これってホントなんですか」と。五寳さん曰く、JScript チームは IE チームとは別だから（確かにそうだ）、きいてみないとわからない、またきいておいてみるとのこと。お願いします。
帰りがけにはギネスを呑みながらいっしょに来ていた3人と色々話をした。内容は多岐に渡ったが、ひとついえるのは「昔話は長くなりがち」だということ。えー、お疲れさまでした（業務連絡）。
ついにやってきた。ウィリアム・ギブスン＆ブルース・スターリングによる『ディファレンス・エンジン』。ハヤカワ文庫 SF から再刊された。以前は角川文庫から出ていたのだが、版元品切れで事実上の絶版状態だった。今まさに読んでいる真っ最中。ついでに『ツァラトゥストラへの階段3』（土橋真二郎 電撃文庫）と『嘘つきみーくんと壊れたまーちゃん6 嘘の価値は真実』（入間人間 電撃文庫）も。何この新刊ラッシュ。私の財布をすっからかんにするつもりか。
そういえば、浅学少識日記帳に Google Chrome のインストールディレクトリがMSの新しい慣例(.NETのクリックワンス等)
との記述が。MSDN あたりをざっくり検索してみたが、うまく見つけることができなかった。まあ MSDN の検索システムがダメダメなので、単に見つけられなかっただけなのかもしれない。……もちっと調べてみるか。
ついに本日午前、Google Chrome がリリースされた。実に素晴らしい事件であり、今日という日は記念されていい。ついに Google が UA を世に送り出したのだ！ その技術もまた、独自の JavaScript エンジンである V8 を実装しているというのだから。速度も素晴らしいという。レンダリングには WebKit。技術的な問題は何ひとつとして存在しない。だが、技術の問題とは別の点で、2つだけ引っかかることがある。「インストールディレクトリが Application Data」であることと、「NT カーネルへのアクセス疑惑」である。
Application Data現時点での Windows 版 Google Chrome は、インストール時にインストールディレクトリを選べない。そして、デフォルトで C:\Documents and Settings\[USER_NAME]\Local Settings\Application Data\Google\ に実行バイナリがインストールされる。同時に、設定ファイルもこのディレクトリ内に配置される。
後者はいいとしても、前者は明らかに不可解だ。どうして Windows デフォルトのインストールディレクトリである Program Files にインストールしようとしないのか？ 謎である。意図が読めない。
例えば Windows Vista で Administrator のパスワードを要求されるのを回避するためかな、とも考えたが、それはそれでやるべきではないし、やってはならない。Windows XP でも、普段使いのユーザの権限を制御している場合は同じことだ。わざわざインストールディレクトリを不自然な場所にすることで回避する必要はない。
インストールしたユーザにのみ利用させたい……という場合もあるだろう。だが、それはそれで別個にオプションを設ければ済むことだ。わざわざユーザに何も問いかけず、無言で意図せぬ場所に、慣例を無視してインストールするのは実にいただけない。
何か、強烈に臭い意図を感じるのは私だけだろうか？ それとも、この疑問はただの疑心暗鬼なのだろうか？ 答えは、まだ出ていない。
Google Gears をインストールしたものの、利用できないという話はぽつぽつと出てきているようだ。私も、とある現象に遭遇した。「ローカル、オンライン、オフラインを問わず、あらゆる HTML/XHTML 文書を開くことができない」というものだ。そしてその原因は、Symantec Endpoint Protection (SEP) バージョン11の「クライアント管理」がとった正当な防衛措置だった。
ログを見てみたところ、そこには権限がない NT 呼び出しを保護ドライバが拒否しました
との説明が。これはどうやらアプリケーションが NT カーネルにアクセスした際に、SEP が自動的に「これはヤバいかも」とアクセスを遮断した際に記録されるログのようだ。
NT カーネルでは、アプリケーションからカーネルへのアクセスは原則的に禁止とし、アプリケーションが落ちても OS 側に与える影響を最小限に食い止めるように設計されているらしい。だが、どうしたことか、Google Chrome は NT カーネルにアクセスしている疑いがある。もしかしたら、より低レベルな方法で直接デバイス側にアクセスを試み、パフォーマンスアップを狙っているのかもしれない。残念ながら私にはわからないが、少なくとも SEP がアクセスを遮断するようなことを Google Chrome がしでかしていることは確かだ。
前述した2つの事実には共通点がある。「Windows OS の慣例に反している」行為を「ユーザに無断かつ裏でごにょごにょやっている」ことだ。私はこれら Google Chrome がしでかしていることに、多大な違和感（気持ち悪さ、と言いかえてもいい）と疑念を抱いている。
慣例を破ることが悪だとは言わない。だがしかし、せめて「インストールディレクトリを慣例とは変えるけど、それでもいい？」とひとこと断るべきだ。嫌ならカスタマイズできるようにすればいい。それだけの話である。なのに、Google Chrome はその手間すらもかけなかった。将来のアップデートでは期待してもいいのだろうか？
あと、こんなことを書くのは気がひけるが、叩かれることを承知で記しておく。バグのないプログラムなど存在しない。例え Google の中の人が自身たっぷりに送り出していたとしても、そこにバグは必ず潜んでいる。だから、せめて危険な行為は避けるべきだ。NT カーネルへのアクセスは OS を巻き込む諸刃の剣である。もし NT カーネルへのアクセスが事実だとするならば、せめてそれが安全であるというお墨付は欲しい。最も無難な判断は、そもそも石橋は叩いて渡ることだ。つまり、下手にカーネルに手を出したりしないこと。それに尽きるのではないだろうか？
Google の行動規範には Don't be evil
とある。「邪悪になるな」という意味だ。Google はこの精神を忘れていないだろうか？ 「やろうとしていること」に対して、きちんと意味のある行為であると理論武装できるのだろうか？
Google Chrome は、技術面では紛れもなく素晴らしいアプリケーションだ。だが、別の面ではどうだろうか。あらゆる存在に対して良い面・悪い面・どちらでもない点を知っておくことも、大事だと思う。