2008年3月

MIAU、NHK に「かぐや」ハイビジョン映像公開に関する質問状を送付

ここのところ、MIAU の動きが活発だ。今日、MIAU は NHK に対し、「かぐや」（月探査衛星「SELENE」の通称）のハイビジョン映像公開に関する質問状を送付したと発表した。質問内容は短くまとまっているため、下手に要約しない方がいいだろう。NHK が一体どのような返答を返すかで、その真価が問われることになる。

少し前には、既に国際連合児童基金 UNICEF の下位組織ではないことが広く定着した財団法人日本ユニセフ協会に対し、「準児童ポルノ」に関する公開質問を送付し、回答を得た。しかし、この回答は要領を得ないものであると言わざるを得ない。MIAU の質問に対しての明言は完全に避けている。つまり、財団法人日本ユニセフ協会は、組織の展開するキャンペーンに対する科学的根拠を明示しなかったのである。この事実は極めて遺憾としか言いようがない。

以下、有用と思われる記事を列挙する。

（財）日本ユニセフ協会インタビュー【第１回】外国からも「声」が届いている｜マンガ論争勃発のサイト

（財）日本ユニセフ協会インタビュー【第２回】児童ポルノ問題には国際的な一致が必要｜マンガ論争勃発のサイト

（財）日本ユニセフ協会インタビュー【第３回】アメリカ司法省「警察はそれほど暇じゃない」｜マンガ論争勃発のサイト

/

（財）日本ユニセフ協会インタビュー【第４回】「状況が悪化しているとはいっていない」｜マンガ論争勃発のサイト

（財）日本ユニセフ協会インタビュー【最終回】「単純所持規制は待ったなし」｜マンガ論争勃発のサイト

永山薫氏と昼間たかし氏による、財団法人日本ユニセフ協会 広報室長 中井裕真氏に対するインタビュー連載。必読。

MIAU の公開質問状についても言及しており、中井氏は来ています。ただ、お答えするだけの時間的なキャパがないんですけどと発言している。但し、註釈として「児童ポルノ問題」だけではなく日常の業務が多岐にわたるため非常に忙しいそうだともある。

児童ポルノ法改正、何が問題か

ascii.jp の記事。2ページ目には次のようなまとめがある。

「児童の性的被害につながる可能性があることは全て禁止すべき」とヒステリックになっている改正賛成派と、準児童ポルノの基準が曖昧だとか、表現の自由に規制が及ぶことを嫌う反対派、それぞれまったく違う次元で話をしている。これではいつまで経っても解決には至らない。

児童は性的虐待からは守る必要があるが、ただ短絡的な規制をしても児童の安全にはつながらないし、この問題を素通りして表現の自由を主張するだけでもおかしいだろう。ぜひ、これをこの問題を考える機会としてもらいたいと思う。

児童ポルノ法改正、何が問題か

日和見的、と揶揄される可能性もあるが、しかし改正賛成派と反対派の極にいる論者にとっては、是非耳が痛くなってほしい話である。バランスの欠けた議論に意味などないのだ。

小寺信良：「児童ポルノ法改正」に潜む危険 (1/3) - ITmedia +D LifeStyle

小寺信良：「児童ポルノ法改正」に潜む危険 (2/3) - ITmedia +D LifeStyle

小寺信良：「児童ポルノ法改正」に潜む危険 (3/3) - ITmedia +D LifeStyle

改正のポイントをうまく絞り込み、論考を加えた記事。

準児童ポルノ - Wikipedia

非常によくまとまった Wikipedia の項目。脚注、参照が豊富でとっかかりに適している。

Web サイトに自身の書いた文章を載せている以上、「表現の自由」[1]には敏感になる。この問題はどのレベルまで波及するか、見当もつかないのだ。少なくとも、日本が歩んでしまった帝国への道を、再び開通させてはならないのは事実である。

2008-03-31

静かな環境が欲しい - HP-NC250 はどうなんだ？

無音は無理だとしても、音を気にせず仕事なりプログラミングなりマークアップなりをしたいわけである。最近知ったのはノイズキャンセラを持ったヘッドフォン。Victor の HP-NC250 が風の噂で「いいらしい」と聞くようになった。……今度実物を試しにいこう。耳栓したって振動は伝搬するし、骨導音も気になると五月蝿いし。逆位相音で騒音を低減してくれるというのもガジェットとしてポイント高いかも。しかし、ノイズキャンセル回路にフィードバックループが使われていること自体を売りにしてるってことは、それ以前は別の方法だったってことか。

フィードバックというと、学生時代を思い出す。機械と電子回路に全く興味がなくなった上に、面倒極まりないフィードバック回路を組まされたんだからそりゃ嫌にもなる。プログラムならすぐできるものが、いざ電子回路となると面倒だし誤差は出るしうまくいかないしで始末が悪い。現実世界の猥雑さよりも、0と1が織り成す芸術的な世界の方が性に合う。

いや、ソフトウェアだってハードウェアなくしては成立しないとわかってはいる。わかってはいるが……。

2008-03-30

WebKit の Acid3 クリア用の修正 Changeset 31322 がバックアウトされる

さて、先日私は「これはひどい」といえる WebKit の Acid3 用修正 Changeset 31322 を取り上げた。その後、情勢は大きく変化したようだ。結論から述べてしまえば、表題にもあるように「Changeset 31322 はバックアウトされた」のである。

「その後の Acid 3 test」によると、ここへ来て急に有名になってしまった Ahem font 固有の修正を WebKit は外すことになったという。そしてそれは本当だった。Changeset 31424 がまさにその修正である。これにより、Changeset 31322 はバックアウトされた形になった。危険は取り除かれたのだ。

この修正に至った経緯の中には、Acid3 テストそのものが変更された、という事情もある。Acid3 の開発者である Ian Hickson 氏の Blog によると、実際にサブピクセルエフェクトを用いてグリフをレンダリングする LCD アンチエイリアシングを持った Mac では、その処理によってテスト結果がリファレンスレンダリングとは異なってしまうという。WebKit Bugzilla の 17086 に登録されている内容のことだろう。これは WebKit に限った問題ではなく、Mac 上で動作する UA にはすべからく影響するとのことだ。

Hickson 氏は Blog にて、次のように述べている。

Now, I argue that this is a bug in the antialiasing, but sadly there's no real spec for the antialiasing and so other people argue that it shouldn't be in the test in the first place, whether I'm right or wrong. What we all agree on is that the font-specific hack is lame. (It's especially bad with this font because Ahem is supposed to be a testing font and we specifically don't want it going down different codepaths!)

So Hyatt and I came to a deal. I would move the test down and to the left one pixel, so it doesn't affect the border anymore, he would accept to remove the hack, and would fix one additional bug (a background-position rounding bug).

The antialiasing controversy in Acid3

前述の引用を（英語力のない私なりに）訳してみた。誤訳注意（脚注筆者）。

今、私はこのバグがアンチエイリアシングによるものと主張するが、残念ながらアンチエイリアシングの本当の仕様というものはないので、他の人々は第一テスト中にあるべきではないと主張している。私が正しいのか間違っているかに関わらず。我々全員が同意していることは、フォント特有のハック[1]は流行遅れということだ（それは、特にこのフォントにとって悪いことだ。何故ならば、Ahem はテスト用のフォントであるべきで、我々は特に異なるコードパスを降りてほしいと思っていない）。

そこで、Hyatt と私は取引をした。私がこのテストを下と左に1ピクセル移動させたならば――もはや境界線に影響されなくなる――彼はそのハックを取り除くことを受け入れ、ひとつの追加バグ修正を行うことだろう（background-position の四捨五入バグ）。

Acid3 のアンチエイリアシング論争

Hyatt とは、実際に Changeset 31424 をチェックインした David Hyatt 氏のことだろう。Hyatt 氏は以前に Changeset 31322 をチェックインした張本人でもある。Hickson 氏が Acid3 の該当テストで利用しているフォントのレンダリング位置を、サブピクセルレンダリングに影響されない座標にずらす[2]代わりに、Hyatt 氏は Changeset 31322 のバックアウトと background-position の四捨五入バグを修正する、と約束したようだ。

私個人としては、何故このような大事になる前に相談しなかったのかが気にかかる。テストに OS 依存の問題点があるならば、広く一般に周知した上で大いに議論すべきである。つまり、議論を行い、組織間で調整し、一般に周知した上で Acid3 そのものを変更することも当然できたはずなのだ。しかし今回、WebKit 開発チームはそのステップを踏まなかった。何故か。

あくまでも推測でしかないが、「Opera に負けたくなかった」ために後先考えずにあの忌まわしきコードをチェックインした可能性はある。Opera と「どちらが先に Acid3 をクリアするか」を、まるで競うかのように Blog への記事掲載という形で牽制しあっていたことは事実である。そのためには何が何でもリリースを早めなければならなくなり、結果として「ベターな方法」ではなく、「安易な方法」に逃げたのではないだろうか。

この兆候がもし単に私の推測ではないとすれば、非常に危険であることは間違いない。つまりそれは、実装された機能が「利用者のため」ではなく「開発者のため」でしかないことを意味するからだ[3]。

無論、私の意見も理想論であると言われるかもしれない。だが、Acid3 とは何かを今一度問うてみれば、ひとつの事実が明らかとなる。Acid3 は「クリアされるため」にあるのではなく、「Web 標準のサポートを助けるため」にある[4]のだ。

先日も少し述べたが、手段と目的を履き違えてはならない。Acid3 は手段であり、目的ではないのだ。しかし、Acid2 の成功が Acid3 の知名度・期待を高め、影響力と誤解を生み出した。今回の出来事は、その歴史が生み出した悲劇なのかもしれない。

ともあれ、今回の Changeset 31424 は歓迎したい。しかし今回の事態で、WebKit 開発者には大きなハンデができてしまった。信用の失墜である。純粋にソフトウェアを良いものにしたいと願い、情熱を傾けるハッカーには非常に好ましからざるものだ。だが、今後見事なソフトウェアを世に出し続ければ、疑心暗鬼の目は一掃されるだろう。私も、そうあって欲しいと願っている。

May the Hack be with you.

2008-03-29

Opera、Acid3 クリア可能なテスト用ビルドを公開

Opera Desktop Team の Blog によると、ついに Acid3 をクリア可能な Opera コアエンジンのテスト用ビルドと簡易インタフェイス[1]をセットにしたアーカイブが公開された。Windows 用と Linux 用の2種類がダウンロード可能である。

このテストビルドの公開によって、Opera の最新コアエンジンは Acid3 をクリア可能であることが証明された。また、Blog への投稿日時から、クリア一番乗りを果たした可能性が高まった。

WinGogi を動作させる方法は単純だ。ダウンロードしたアーカイブを解凍し、wingogi_release_desktop.exe を実行するだけでよい。

WinGogi による Acid3 クリアの様子

確かにクリアできていることがわかる。

Opera はプロプライエタリなソフトウェアである。故に、ソースコードを読むことはできない。……私は Opera の開発チームを信じるしかない。WebKit の悪夢が存在していないことを。

2008-03-28

WebKit 開発者の一部よ、恥を知れ！ - Opera の非公開テストビルドと WebKit Nightly r31342 が Acid3 をクリア

2008年3月26日。その日は Opera にとって記念すべき瞬間となった。Opera Desktop Team の Blog によると、開発用の非公開テストビルドが Acid3 をクリアしたのである。掲載されたスクリーンショットは Acid3 の「100」を輝かしく示している。引用によると、Opera Labs で来週そこそこにも公開されるらしい。テストするのが楽しみだ。

2008年3月27日。その日は WebKit (Safari) にとって記念すべき瞬間となった。Surfin' Safari によると、27日のうちに「もう少し」から「完全」となり、Acid3 をクリアしたというのである。その変換点ともいえるリビジョンが r31342 である。現在「WebKit Nightly Builds」から最新版をダウンロードすれば、Mac OS X でも Windows でも Acid3 をクリアするビルドを入手することができる。

しかし、WebKit の開発者はやってはならない過ちを犯した。このことを知らせてくれたのは、Taken SPC 経由で読んだ Mozilla Corporation の Rob Sayre 氏の Blog である。Sayre 氏は Acid3 の有用性について basically worthless（基本的に価値がない）と述べ、その理由について述べている。そして、再々追記にてたった一文、こう記述したのである。

P.P.S. — Shameful!

Acid3 is basically worthless

Shameful とは「けしからん」という意味。そのリンク先は WebKit のチェックイン記録である。

結論から先に述べよう。「WebKit 開発者は Acid3 をリファレンスレンダリングとのピクセル完全一致レベルでクリアすることのみに特化した、汎用性のない、バグの温床となりうるコードを実装した」のである。

では、具体的に Sayre 氏の指摘した WebKit チェックイン記録の Changeset 31322 を見ていくとしよう。

まず飛び込んでくるのは、次に引用した ChangeLog である。

Make the Ahem font antialias correctly on Acid3.

Changeset 31322

次に訳文を記す。訳文訂正、註釈筆者、誤訳の可能性に注意。

Acid3 に向け、Ahem フォントのアンチエイリアス補正を作成する[4]。Acid3 に対して、Ahem フォントのアンチエイリアスを正しく行う。

Changeset 31322

ここでまず、最悪の状態を見極めることができる。「Ahem」というフォントに特化したアンチエイリアス補正である。つまり、ここでは言外にこう言っているわけだ。「Ahem 以外は対応していない」。

そもそも「Ahem」とは何なのか。その答えは Acid3 のテストサイトに存在する。

Ahem とは TrueType フォントの一種である。Acid3 では、このフォントを @font-face アットルール内の src プロパティで利用している[1]。つまり、「ダウンローダブルフォント」のテストに用いているのである。

この Ahem というフォントに対し、どうやら WebKit はアンチエイリアスをかけると変なレンダリングをしてしまったらしい。そこで David Hyatt という Apple Computer の社員と思しき人物[2]は、要約すれば「ファミリ名が「Ahem」というフォントであった場合は強制的にアンチエイリアスを OFF にする」という最低最悪のコードをチェックインしたのである。その記録が Changeset 31322 というわけだ。

Mac 用と Windows 用で2種類のコードがチェックインされているが、やっていることはどちらも全く同じである。ここでは Windows 用のコード、trunk/WebCore/platform/graphics/win/SimpleFontDataCGWin.cpp から抜粋してみよう（強調筆者、コメントは原文を拙訳）。誤訳の可能性に注意。

// Ahem フォントの妙な CG アンチエイリアシング用の次善策。Web フォント版に制限する。
if (isCustomFont()) {
    RetainPtr<CFStringRef> fullName(AdoptCF, CGFontCopyFullName(m_font.cgFont()));
    String nameStr(fullName.get());
    m_allowFontSmoothing = (nameStr != "Ahem");
}

さて、ここで憤慨すべきなのはソースコード中に "Ahem" という固有名詞をマジックナンバとして入れ込んでしまった点だ。このコードには汎用性はおろか、保守性その他ありとあらゆる配慮が存在しない。つまり、このコードは作成された時点からバグの温床になっているのである。このコードをレビューした Dan という人物は、一体何を考えているのだろうか？　このコードの存在は、WebKit というソフトウェアの価値を貶めるだけなのである！

このような「Acid3 を最重要目標にしている」としか思えない潮流が、一握りの開発者かもしれないとはいえ、WebKit 開発者の集団には確実に存在しているようだ。しかし、Acid3 はあくまでもテストである。テストは「それが全て」ではなく、「最低限できうるべき」ことなのだ。明らかに、Acid3 のクリアを「目的」とすることは、手段と目的を履き違えているとしか言いようがない。

コードはプログラマの全てを物語る。WebKit というソフトウェアは、どう考えても「やっつけ仕事」で済ませてよいものではないはずだ。しかし、先程紹介したコードは明らかに「やっつけ仕事」[3]に他ならない。これでは、他の真面目に改良を施しているプログラマが可哀想すぎる。ひとつの汚点は、百万の美点に勝ってしまうのだ。

せっかくの良いニュースが、たったひとつの冴えないやりかたのせいで悪いニュースと化した。Safari 2.x 系の JavaScript がバグだらけだった歴史が脳裏をよぎる。沢山の素晴らしいコードを書くハッカーがいる一方で、十分なレビューと明確な指針さえあればいくらでも防げたはずの、そもそも存在すること自体があってはならないコードを平気でチェックインしてしまうレビュアとプログラマもいる。……書いてて泣けてきた。

とりあえず、最後にふたつだけ。

Opera 開発チームの皆さん、おめでとう！

そして。

WebKit 開発者の一部よ、恥を知れ！

2008-03-27

IE8 の Array オブジェクトは高速化されているらしい その1

JScript Blog に「配列のパフォーマンス最適化 その1」という記事が掲載された。どうやら IE8 では Array オブジェクトに最適化が施され、パフォーマンスが良くなったらしい。記事では、その手法について1つ説明されている（続きは後日掲載するようだ）。

今回掲載されたのは、「JScript didn't treat Arrays as Arrays」というもの。直訳すると、「JScript は配列達を配列達として取り扱っていなかった」。これは、どうやら JScript の内部では Array オブジェクトのインデックス値を単に文字列変換し、連想配列として扱っていたということらしい。

つまり、Array オブジェクトに与えられたアイテム数が少ない（疎）な時でも多い時でも連想配列として扱っていたというのである。この状態だと、Array オブジェクトのアイテムにアクセスする時、インデックス値を文字列にする → ハッシュ表を調べて該当するキーの値を得るという段階がアクセスの度に実行される羽目になる。ここにパフォーマンス悪化の原因があったという。

Fix されたバージョンの JScript ランタイムは、Array オブジェクトを他のオブジェクトとは違った特別な存在として扱っているという。それは、2つのストレージ領域を持つことで実現しているらしい。1つは通常のハッシュテーブル用領域。ネイティブオブジェクトならすべからく持っている領域である。そして新規に追加されたのは、C言語風な配列用の、ハッシュテーブルとは排他的関係にある領域。この新規に追加されたC言語風配列領域は常時使用されるわけではなく、配列のアイテムが連続しておらずにまばらになってしまっている場合には利用されない。このようなパターンでは従来のように連想配列が用いられる。つまり、ポイントはデータが連続していることにあるようだ。

勿論、その見極めも考慮されている。JScript Blog では次のコード断片を用いて説明している。

arrObj = new Array();
arrObj[10] = 20;
arrObj[50000] = 500000;

前述のようなコードの場合、arrObj[10] ではC言語風配列領域が利用されるらしい。そして、arrObj[50000] = 500000; では従来のハッシュテーブル用領域が用いられる。だが、残念ながら実際の判別アルゴリズムまでは紹介されていなかった。秘密にしたい理由があるということなのだろう。今は、それが何かという詮索はしないでおく。

更に記事は続く。実際のところ、配列への値の挿入方法によっては、一見連続したデータとして取り扱っているようでも、C言語風配列領域が利用されないパターンがあるという。次のコード断片は、紹介されていた「利用されない」パターンである。

arrObj = new Array();
for(var i = 2000; i >= 0; i--) {
    arrObj[i] = i;
}

arrObj = new Array();
var length = 2000;
for(var i = 0; i < length/2; i++) {
  arrObj[i] = i;
  arrObj[length – i - 1] = length – i;
}

前者は、値を「最大インデックスから」代入したパターン。後者は、値を「0と最大インデックスから挟み込むように」代入したパターンである。後者はともかく、前者は使われる可能性のあるコードである。

駄目な例に共通しているのは、「インデックス0から線形に操作していない」ことである。JScript Blog では、C言語風配列領域を有効にするためには次のことを守ればよいとしている。

「インデックス0から順に、インクリメントしつつ操作する」

何が何でも線形に行う、というのがカギらしい。この話題はまだ続くそうなので、続報にも期待しよう。

話は変わる。今日、Mozilla Firefox 2.0.0.13 がリリースされた。詳細はリリースノートを参照のこと。セキュリティアップデートなので更新必須。お早めに。

2008-03-26

「高専連携グリッドプロジェクト」が始まるらしい

高専出身者としてちょっと興味深いニュース。国立高等専門学校機構と Microsoft が連携し、国立高等専門学校（高専）に存在する教育用のコンピュータに Windows Compute Cluster Server 2003 を導入してグリッドコンピューティング環境を実現するとのこと。……そこで MS の OS というのが個人的には残念というか。プロジェクトチーム作って教育の一環で実装やらせてみるとか、そういうことも必要のような気がしたので。勿論、それが非常に大変であることはわかっているが、人材育成という意味では有意義かもしれない。

このニュースはマイコミジャーナル、ITmedia、CNET Japan 等が相次いで報道している。

ぶっちゃけた話、このプロジェクトの最大の弱点は、高専に存在するコンピュータのうち Windows OS を稼動させることが前提のものにしか適用されないことだ。大多数は Windows の稼動しているものだろうが、学科によっては Linux が稼動している場合も少なくないだろう。私が在籍していた学科のコンピュータ演習室にあったコンピュータには Vine Linux が導入されていた。結構、管理者の人柄が表れるものなのだ。OS に依存しないシステムは考えなかったのかしらん？

また同時に、電源が落とされていては意味がない。グリッドコンピューティングのために常時稼動させるとなると、予算と環境に優しくないのは明白だ。無論、そういう運用をされているコンピュータは該当しないと考えていいだろう。……そうでなければある意味本末転倒になりかねない。

しかしながら、利用されていない時間帯の資源有効利用という点ではよいことだと思う。性能悪化しない限り、資源は有効に活用すべきだ。高専クラスになれば、専用回線を引いているところも少なくないだろうから、回線への負荷も最小限で済むのかもしれない。

あくまで個人的な意見でしかないが、独立行政法人になってしまった国立高等専門学校機構が抱える問題のひとつである「予算削減」にも貢献できるのかもしれない。つまり、国立高専は国からの予算が少なくなってしまった現在、どうにかして苦しい家計をやりくりしなければならない状況――つまり、「足りない分は自分達で稼げ」という状況――にあるのだ。要は国立大学と同じ境遇である。Microsoft に対し、交換条件としてライセンス料を削減ないし撤廃させているというのは十分に考えられる。それも魂胆のひとつと考えてよいだろう。

機械、加工、電子、化学といった分野では企業や組織との共同研究や特許などで比較的金を稼ぎやすい。しかし、計算機科学の分野はまだその点で遅れをとりがちであるという指摘も、在校時代、風の噂程度に耳にしたことがある。この提携はその面でひとつの実績になるのかもしれない。

2008-03-25

フォント指定は一般フォントファミリのみ - IE は別

フォント指定の話が盛り上がっているようだ。先に私の見解を述べてしまうなら、「IE 以外で一般フォントファミリ名以外の指定はしない」となる。

「CSSのfont-family：ヒラギノとＭＳ Ｐゴシックとメイリオの悩ましい関係 - webデザイナーのナナメガキ」ではイレギュラーケースについても色々とパターンを書いてある。「CSSでのフォント指定 : ARTIFACT ―人工事実―」ではHTMLタグでlang=”ja”宣言をしておくといいそうだというが、XHTML 1.1 では xml:lang にしなければならない。また、xml:lang では前述の効果を期待できないという点は補足が必要だろう。

本サイトでは IE とそれ以外とで処理を分けている。IE には通常のフォントファミリ名と一般フォントファミリ名を、他の UA には一般フォントファミリ名だけを指定している。IE 利用者には申し訳ないが、本サイトの文書は全て UTF-8 である。デフォルト値のままでは Times New Roman + MS UI Gothic になる[1]。このままではあまりにも意図に沿わないため、敢えて Verdana やＭＳ Ｐゴシックといった具体的なファミリ名を指定させてもらっている。それが嫌だ！　という方はユーザスタイルシートでいじっていただければいいだろう。そのために !important は一切利用せず、なるべく選択子の固有性を小さくするよう心がけている。一部例外[2]もあるが。

Firefox などの UA では、必ず一般フォントファミリが利用されるようにしている。これは自分自身のためでもある。私は普段利用している Mozilla Firefox で、次に列挙するような指定を施している[3]。

• Serif: IPA P明朝
• Sans-serif: VL Pゴシック
• Monospace: VL ゴシック

だが、これもサイト側で具体的に最低最悪なＭＳ Ｐゴシックなどが指定されていたりすると駄目だったりする。そのため Firefox でもユーザスタイルシートでゴニョゴニョしている。

閲覧者からしてみれば、普段利用している、自分がセレクトしたフォントで表示されてほしいこともある。無論、デザインが重視されても問題は少ないサイトロゴやちょっとした見出しなどは、雰囲気を壊さないためにもデザインした側の意見が尊重されてもいいだろう。しかし、肝心の情報源である本文など[4]については、閲覧者の好きにさせてほしいというのが私の本音である。

最後にひとつ言えることは、昔から散々議論され、よく知られている当り前のことだ。「Web 上でフォントが思い通りになると思うな」。そして、「閲覧者が全てをコントロールできるべきだ」。DTP ではないのだ。デザイナのエゴなど、閲覧者にとってはどうでもいいことなのだ。情報が伝達できているか、ということが重要なのである。体裁も大事ではあるが、それはコントロール可能でなければならないのだ。この事実さえしっかり念頭に置いていれば、下手な指定などしなくなるし、できない筈である。

2008-03-23

最近のハヤカワ文庫はカバーにビニールコーティングが施されるようになった

気付いたのは2008年3月25日発行の『永久帰還装置』（神林長平）。つい先日発売された復刊である。朝日ソノラマから単行本・文庫が発刊されたが、版元消滅に伴い権利が早川書房に移ったのだろう。ソノラマ文庫版を読了しているが、当然購入。

書店で手にとって違和感を覚え、軽く撫でてみてその理由を理解した。それまでのハヤカワ文庫は汗をよく通してふやけてしまいがちなカバー表面コーティングだった。だが、『永久帰還装置』はかなり厚手のビニールコーティングが施されているようで、例えるならば電撃文庫に近い手触りなのだ。当然、耐水性は向上しているとみていいだろう。ちなみに、中の本体は旧仕様のままだ。

小さな違いだが、大胆な試みともとれる。鹿皮製のブックカバーを愛用しているからどちらでも影響はないといえばないのだが、ずいぶんと以前に（ブックカバー入手前）『宇宙の戦士』（ロバート・A・ハインライン　ハヤカワ文庫 SF）の表紙を手汗でふやけさせ、かなり劣化させてしまった身としては、強度アップしたという面で評価できる。

この間ようやく購入した『麦撃機の飛ぶ空』も大変よろしい作品集だった。早く『雪風』の最新作掲載されないかなー。

2008-03-22

ひたすら JavaScript の日

気づいたらずーっとコード書いてた。そんな日もあるさ。コードをブラッシュアップしている間は、プロトタイプのコードを書いている時と同じくらい心休まるひとときだ。バグ潰しも自分の不手際によるものは嬉々として修正する。……UA のバグや仕様絡みだとゲンナリしてしまうけれども。

……あーあ。早く Safari 2 系は廃れてくれないかなー。あれの CSS/JavaScript に対応するのは、中途半端に仕様に準拠している点が多いから厄介なのだ。大多数はプロパティ判別で乗り切れるが、スタイルが絡むとどうしても UA 判定しなければならない場面が出てくる。UA 文字列は偽装されるから論外として、独自サポートプロパティなどで見極めるしかない。それでいて 2 系と 3 系で仕様変更がかかっているものは更に双方のうち片方しかサポートしていないプロパティなどをトリガにして判定したりする。ビューポートのエリア取得はその代表例だろう。

Opera はその点優秀かと思いきや、9.2 系には Computed Style 絡みでバグがちらほら。height の値をとってきてみれば border-box の height になっていたり。これは 9.5 系で修正されているからまだいいけれども、判定に widnow.opera 使う必要に迫られる。……そう。バグのある中途半端な対応が一番頭の痛い問題となりうるのだ。

その点、Gecko ってあまり苦労させられた記憶がないな……。新機能よりも既存機能のバグ潰しを優先してくれているのだろうか（あくまで個人的主観だが、そんな気がする）。いちプログラマとしてはその方が有り難い。中途半端なサポートよりも、「ある」か「ない」かのどちらかであった方がやりやすい。

IE は論外ってことでひとつ。

そういえば、日本語文字の Bold レンダリングは Gecko/2008032005 で無事直っていた。パッチがバックアウトさせられたのかしらん。

2008-03-21

15時間ぐらい……？

起きたら 18:00 だった。……えっと、何時に寝たっけか。まあいいか。

今日は特に何もない日だった。休日はそうであって欲しい。波瀾万丈な休日ばかりでは疲れがたまるだけ。

そういえば、Firefox Nightly (Gecko/2008031905) は日本語文字の Bold レンダリングが無効になってるな……。どこかで見たようなバグ。regression か？

2008-03-20

アーサー・C・クラーク卿死去 - "Big 3" 最後の巨星

カナダ CBC によると、SF 界に多大なる影響を与え続けた、偉大なる "Big 3" 最後の一人であるアーサー・C・クラーク卿が今朝死去した。90歳であった。アイザック・アジモフ、ロバート・A・ハインラインと共に "Big 3" と呼ばれ、SF の黄金時代を支えた重要人物の一人として著名である。晩年まで SF 以外にもノンフィクションやエッセイなど、数々の著作を発表し続けた。

『2001年宇宙の旅』は映画化されたこともあって有名となった作品のひとつである。

私もつい先程（09:30 頃）このニュースを聞きつけ、衝撃を受けたところだ。しかし90まで生きたのだから、大往生といえるだろう。

これで近々『S-F マガジン』で特集されるのは明白になった。

続報や関連リンクは 本家 Slashdot のコメントが詳しい。

2008-03-19

IE と Safari の document.cookie は max-age を解釈できない罠

まさかと思ったが、よもや Safari までが……。ちなみに IE は6と7、Safari は Mac 版 2.0.4 と 3.0.4 で確認。Firefox 2.0.0.12、Opera 9.26 は利用可能。仕方ないので max-age 用に与えた数値を加工し、Date オブジェクトを現在時刻として new。getTime() で取った現在時刻に加工した値を加算し、setTime() して予定時刻を表現。toUTCString() メソッドで文字列生成してから expires として与えることで対応した。

Cookie の最新仕様らしい RFC は、RFC 2965。ここにはきちんと max-age が定義されている。MSDN の該当項目である「cookie Property (document)」という文書には max-age がなく、expires のみが定義されていることがわかる。……こういう所、きっちりしてほしいなぁ。

そういえば IE8 Beta 1 でチェックするのを忘れてた。明日確かめよう。

2008-03-18

JavaScript の柔軟性がもたらす落とし穴 - Number オブジェクトの constructor プロパティの constructor プロパティには要注意？

今日気になった記事は「予約語なしに JavaScript でいろいろしてみる」。連想配列と [[Prototype]] プロパティが言語の根幹にある JavaScript において、文字列による参照は非常に便利でもあるし、非常に危険でもあるということだ。

実際に hoshikuzu | star_dust 氏のやっていることは単純である。次のコード断片は、関数として呼び出される Function コンストラクタを利用した、同一のことをやろうとしているコードである。

(Function('alert("Hello World!")'))();

しかしリンク先のコード断片では Function コンストラクタを明示的には利用していない。説明にもあるように、Number オブジェクトの constructor プロパティの constructor プロパティが Function コンストラクタであることを利用している[1]。コード中には Function という文字列は一切出てこないが、これがきちんと動作する。因みに文字列を unescape するのにも同様の方法を用いている。

コレじゃあブラックリストを作成したところでどえらいパターンが存在してしまうから、ホワイトリストでどうにかした方がいいと思うよ、ということらしい。

プロトタイプチェーンのことをぐだぐだと考えるのに [[Prototype]] プロパティと prototype プロパティを延々とおっかけているような人種には「おお！　なるほど！」と思わずにはいられない。

2008-03-17

IE8 Beta 1 で当サイトのナビゲーションは崩壊する

……何でやねん。とりあえず IE7 用の CSS を IE8 以降には適用しないようにし、Gecko/Opera/WebKit 用に作成したナビゲーション（文字サイズ変更でも崩壊せず、画像置換ではない）をそのまま読ませるようにしてみたのだが。結果は惨敗。いいところまでいってるがやはり駄目なものは駄目。

どうやら :after 疑似要素のあたりがおかしくなっているようだ。また、フルページズームをかけるとおかしなことになるし、テキストズームでも駄目駄目。これは何としても早急に原因を突き止めなければ。多分、IE8 の問題のような気がする。やはり少しでも複雑なことをやらせようとするとボロが出るのか……？

2008-03-10

IE8 Beta 1 Released - しかし色々注意が必要、Virtual PC イメージ版がおすすめ

ついにこの時がやってきた。IE8 Beta 1 の登場である。早速導入して色々試してみた。テスト以前に注意するべき点・おすすめの利用法があるので、まず紹介。

最後に、軽く関連サイトの記事をまとめてみた。

Internet Explorer 8 Beta: Download Now

Microsoft のダウンロードページ。Select your operating system とあるセレクトメニューから該当の OS を選択、Go ボタン選択でダウンロードページへ誘導される。

IEBlog : Internet Explorer 8 Beta 1 for Developers Now Available

IEBlog の IE8 Beta 1 発表を告知したエントリ。

IEBlog : Why Isn't IE8 Passing Acid2?

「IE8、Acid2 クリアしてないじゃねーか」という声に対する理由の説明。

実は IE8 がクリアしたのは http://www.webstandards.org/files/acid2/test.html にホストされている方の Acid2 Test である。http://acid2.acidtests.org/ にホストされた Acid2 Test はクリアできていない。実は両者のコードには相違点がある。

ざっくり説明すると、acid2.acidtests.org の方では object 要素の data 属性値に http://www.damowmow.com/404/ が指定されている。ファイルがホストされているドメインとは別のドメインが指定されているのが原因だ、というのが IE Blog 当該エントリの主張。つまり IE は別ドメインへの参照を処理していないのである。恐らく、セキュリティ上の配慮と考えられる。

因みに、www.webstandards.org/files/acid2/test.html の方は http://www.webstandards.org/404/ が指定されている。同一ドメインなので IE8 は問題なく処理を実行しているというわけだ。

この問題は Ajaxian でも取り上げられた。

JScript Blog : JScript in Internet Explorer 8 Beta 1 for Developers

JScript Blog の IE8 JScript エンジンに関するエントリ。このエントリでは「COM インフラの循環参照によるメモリリークを Fix しなければならない」と述べている。つまり、まだ Fix していないらしい（拙い英語力なので意味が汲みとれているかどうか……）。ちなみに該当部の英語は We took a hard look at this problem and realized that this has to be fixed at the COM infrastructure. である。

Windows Internet Explorer Testing Center

Microsoft による CSS 2.1 のテストページインデックス。これらのテストページは W3C に寄贈されたそうで、CSS test suites から閲覧することができる。

Mix08 初日！ Welcome to Microsoft Internet Explorer 8

日本の Windows 開発統括部の中の人である、五寳氏による IE8 Beta 1 と Mix 08 のエントリ。よくまとまっている。

Enjoy!

2008-03-06

IE8 の標準レンダリングが最も標準に準拠したモードに（ひとまず）変更

IEBlog 他、様々なメディア、Blog を駆け巡ったこの話題。このまま変更がなければ、非常に素晴らしい出来事だ。以前は IE7 と同じレンダリングを行うモード（IEBlog では IE7's Standards mode と形容）がデフォルトで、特殊な meta 要素の挿入もしくは HTTP ヘッダの送付でIE8's Standards mode に変更できるとされてきた（Web 標準 Blog の解説がまとまっている）。Microsoft はその方針を変更したのである。

「Microsoft Expands Support for Web Standards」や「Microsoft Introduces New Interoperability Principles」といった文書にあるように、過去ではなく現在と未来を見据えるようになった。

この変更により泣きを見るのは、「Web 標準？　何それ？　喰えるの？」とのたまうようなマークアップと体裁づけを施してきた、または現在進行形で施しているサイトの製作者である。無知は罪、とは一般人に対しては絶対に言わない。だが、長期的に見て自身――ないし業者であるならばその顧客――に最も利益をもたらすのは、標準（勧告）に準拠した成果物を日常的・通常仕様として作成・納品することである。

特に (X)HTML 文書などを制作し、顧客に納品することで対価を得ている企業・個人は最低限の知識[1]を持っている必要がある。何故ならば、納品物がそのまま顧客の収益に影響を及ぼすことが非常に多いからだ。体裁が崩壊したり、文書構造が無意味であったりすると直接被害を被るのは納品先、即ち顧客である。

共通のルールはソフトウェアベンダが相互の利益のために作成したものだ。特に W3C の勧告は「実際に該当ソフトウェアを制作している組織」が意見交換した末に練り上げていることが殆ど。天変地異でも起きない限りそれは変わらない。

安定した仕様を使い、意味のある文書を生成し、WWW というインフラに載せ、情報を発信する。WWW に人々が求めるのは兎にも角にも情報である。必要としている事柄が入手できなければ、WWW の存在意義はない。意味のないマークアップや崩壊した体裁は閲覧者を直撃する。

全ては閲覧者のために。情報を発信する側の自己満足や事情など、閲覧者は求めていやしない。より標準に準拠したレンダリングは、より上質な文書構造を要求し、より腱固な体裁を要求する。つまり、より閲覧者にとって都合のよい環境が整うのである。

2008-03-04

自宅の skkime を 1.0 から 1.5 に - 道具へのこだわり

随分と久しぶりに書いてる気がする。それはともかくとして、今日は色々と整理整頓やら洗濯やらで一日が過ぎていった。主要ソフトのバージョンアップもついでに実施。そのひとつが SKK クローンである skkime を 1.5 にすることだった。会社のマシンでは既に実施済だったが、そこでかなり安定していると判断。自宅にも導入してみることに。普段の利用で劇的によくなった面があるわけではない（？）が、問題もない。個人的に、設定画面は 1.0 と比べて飛躍的によくなったと思う。

この間、自分のものではないマシンを使用した時に日本語入力が必要な場面に出くわしたのだが……そこで問題になったのはやはり操作の違い。IME の ON/OFF はまだいいとして、変換の確定にいちいち Enter を押さなければならないというのがどれほど面倒かを思い知らされた格好になった。そこで改めて「ああ、もっと素晴らしい IME に巡りあわない限り元には戻れないんだ」と感じた。

自分の指というのは、あまりにも当然だが肉体の一部。使えば使っただけその動きを学習していく。どのようなスポーツや武道、日常動作にも当て嵌るが、キーボードの打鍵だってそのひとつである。最初は考えなければならなくても、じきに何も考えずともよくなる。ブラインドタッチもそうだし、SKK の扱い方もそうだ。先に述べた他マシン利用時には、Shift キーを多用する SKK の作法を MS-IME に持ち込んでしまい、変な入力をしてしまうことが多々あった。脳内を何かを無理矢理スイッチングして、10分ほどでたどたどしいながらも MS-IME を使えるようにした。

やはり道具は大切だ。大工の鉋のように。映像表現を追い求める人はモニタをよいものにしがちだし、音を追い求める人はスピーカやヘッドフォンにこだわる。プログラマはキーボードやポインティングデバイスにこだわりを見せることが多い。

ハードウェアの話ばかりしたが、ソフトウェアにしても同じこと。「こだわりがないのがこだわり」という人もいるし、特定のソフトウェアを愛する者もいる。vim に心酔する者もいれば、GNU Emacs に忠誠を誓う者もいる。因みに私は Emacs が好きで好きでたまらない。しかし Windows 環境では Meadow でなく xyzzy を使うことが多い。

このテの話をすると際限がなくなるので程々にする。まあアレだ。つまりは SKK 万歳、と。

2008-03-02