熱と頭痛でダウン＆そろそろ Blue-ray ドライブが欲しい

色々ある時期に申し訳ありませんでした…… > 関係各位

夜になり、熱も36度8分ほどに落ち着いた。咳も鼻水もなかったが、風邪だったんだろうか……。

そろそろ Bul-ray 対応ドライブが欲しいと思う今日この頃。色々候補はある。今日は LG 電子の新型ドライブが出たので益々欲しくなった。

しかしウチのデスクトップは未だに Serial ATA すら装備していない上にメモリも 512MB しか積んでいない。ビデオカードは……論外か。CPU だってアレだし。Serial ATA を IDE に無理矢理変換したとしても、まともに再生できないだろう。

色々欲しいものはあるけれども、使い道の優先順位があるから仕方ない。ちなみにトップにあるのはアパートの更新費（貯蓄用）。結構バカにならない金額なので、今のうちに貯めておかないとマズかったりする。もし仮に実家から通勤するとなると、会社まで1時間40分ちょいはかかる。それに、部屋数の問題もあるし。

うまくいかないもんだ。

2008-11-28

window オブジェクトにしか resize イベントがない理由 - DOM 2 Events の仕様？

現在、IE 以外の UA[1][2] での resize イベントは window オブジェクトしか発行しないようになっている。MDC のドキュメントには次のようにある。

Only the window object has an onresize event.

element.onresize - MDC

その「理由」は、どうやら DOM 2 Events の仕様そのものにあるようだ。次のような仕様が存在しているからである（強調筆者）。

resize

The resize event occurs when a document view is resized.

  • Bubbles: Yes
  • Cancelable: No
  • Context Info: None

Document Object Model Events

つまり、a document view でしかイベントが発行されない……といっているのだと思う。多分。これが resize イベントを発行するオブジェクトが window しか存在しない理由になっているのかと。

ただ、次に引用するように DOM 3 Events では解消されている（強調筆者）。

A document view or an element has been resized. The resize occured before the dispatch of this event type.

Document Object Model Events

a document view だけでなく、an element にも適用できるようになっている。整理された表にもきちんと Target として Document, Element のように明記された。

早く DOM 3 Events が勧告されるような状況（実装が出揃う）にならないかしらん？　ていうか resize だけでもいいから要素にも適用できるようにしてほしい……。

脚註

  1. Mozilla Firefox 3.0.4、Apple Safari 3.2.1、Opera 9.62、Google Chrome 0.4.154.25 時点。
  2. IE は以前から特定の要素も resize イベントを発行できるようになっている。但し、tr、th、td 要素などといった、イベントを発行しない特殊扱いの要素もある。

2008-11-25

Favicon に各種サイズの画像を追加

具体的には 256, 48, 32, 24 の各画像。ただ、色数は24bit＋アルファチャンネル（要は32bit）のみ。余裕があれば他のパターンも……。

追加した理由は、ただやってみたかったから。ソフトウェアは GIMP 2.6 と IcoFX の組み合わせ。

それにしても GIMP のインタフェイスは 2.6 になって更にカオスになった。というよりひどい。只でさえウインドウの数が OS に複数認識されるという問題（スイッチするとき面倒極まりない）が残っているのに、その他諸々。それでも機能としてはだいぶよくなってきているので、その点は頑張ってほしい。これで Photoshop のように「レイヤー効果」が実装されれば更によくなるんだけど。いや、プラグインでは存在しているのは知っているが、実際使ってみるとリアルタイム描画ではないところが泣かせる。あれが便利なのに。

しかし Photoshop は買う気になれない。でも魅力的な機能は多い。あーあ。

2008-11-22

そろそろ変え時？　デザインは難しい

そろそろサイトのデザインも変え時かなぁ、と思う今日この頃。こういう考えは大体定期的に現れてくるが、結局何もしないままに終わるのが常だったりする。

絵心のない自分にとって、画像を作成することは苦痛でしかないという罠。キーボードを叩けば現れる文字とは違い、もっと違うモノが求められる。

どうしたもんか。

2008-11-21

IE8 に Beta 3 はない - RC は時期尚早では？

やはり予定通りを貫き通すらしい。IEBlog によると、Beta 2 の次は RC になることが決定したようだ。因みに、IE8 が RC になったら MS が「致命的」と判断したバグのみが修正される。それは例えば「Web 標準に関するもの」「翻訳に関するもの」だったりするという。だが、その評価基準はあくまでも MS の中の人次第ではないか、という疑念は拭えない。そして、現在 IE8 Beta 2 は Beta とは思えないほど大量の、特に Web 標準に関する面──その中でも CSS と JScript──のバグを内包しており、かなりのフィードバックがあがっている。つまり、まだまだ隠れたバグが見つかる可能性が高いのだ。

Beta 3 を出すべきではないのか？　というのが率直な意見。RC ということは即ち "Release Candidate" つまり「リリース候補」である。要するに「リリースまで待ったなし」にかなり近いということだ。

あくまでも私見だが、Web サイトを構築する者にとって何より重要なのは「予定通りリリースされた UA」などでは決してない。W3C その他の標準化団体により策定された仕様にきちんと準拠した「正しくレンダリングする UA」である。

IEBlog では、IE8 Beta 2 をインストールしてから是非フィードバックに参加してくれ、という話を最後に載せている。とはいえ許可のない人ができることは「評価（スター）を付与する」ことしかできない。

ただ、この「評価」はかなりの効力を持つという。「これはまずい」と思ったバグの評価を上げておくと、そのバグがトップページの「トップ アクティブ バグ レポート」に掲載されやすくなる。この「トップ アクティブ バグ レポート」は、週に1度開催されるという IE Team のミーティングで必ず議題にあげられるという。要は「みんなで組織票入れればバグが修正されやすくなる」という具合らしい。

IE7 の悪夢は二度と繰り返してもらいたくない。せめて IE8 は、Gecko や WebKit、Opera が既に達成しているレベルの最低ラインには追いついてほしい。MS の狗になったようで非常に悔しいが、いい加減 IE6 と IE7 は滅んでしまえと思っている身としては、IE8 の完成度が高くなること自体には賛成なのである。

ていうかもう IE のレンダリングエンジンは Lunascape みたいに Gecko や WebKit と組み合わせたものを使ってくれよと。それが一番手っ取り早いだろうと。IE8 では無理だが、IE9 では実現してもいいんじゃないかと。もし MS が自社での開発を諦めてくれさえすれば、あるいは……。ううむ、それはないか。過去の因縁もあることだし。

2008-11-20

続・IE5.5、IE6、IE7 で li 要素ないしその子孫要素における hasLayout が true である場合、リストマーカが下方にずれるバグの解決法（実例つき）

ということで先日の続き。実際にコード例を見てもらったほうがわかりやすい。

先日は書き忘れたが、このバグは IE8 の "IE8 Standard Mode" では Fix 済である[1]。

次のコード断片は、IE5.5, 6, 7 でバグが発現する CSS 及び XHTML 1.1 文書の例である。

/* CSS 断片 */
/* img 要素を float させる → hasLayout が true になる */
#date-2008-11-19-bug li div img
{
  margin : 0 0.5em 0.5em 0;
  float  : left;
}

/* clearfix をかけないと IE でリストマーカが出現しない */
/*
 * div 要素を噛ませているのは、IE で li 要素に直接 clearfix を
 * かけるとカウンタがリセットされる別バグを回避する為
 */
/* p 要素だと IE が落ちたので、泣く泣く div 要素を使用 */
/* clearfix: IE */
#date-2008-11-19-bug li div
{
  zoom : 1; /* Fxxk! */
}
/* clearfix: 他UA */
#date-2008-11-19-bug li div:after
{
  display    : block;
  clear      : both;
  height     : 0;
  visibility : hidden;
  content    : "";
}
<!-- XHTML 断片 -->
<ol id="date-2008-11-19-bug">
  <li><div><img src="data/2008-11-19/test-80x80.png" alt="Test Image" /> テキスト</div></li>
  <li><div><img src="data/2008-11-19/test-80x80.png" alt="Test Image" /> テキスト</div></li>
  <li><div><img src="data/2008-11-19/test-80x80.png" alt="Test Image" /> テキスト</div></li>
</ol>

レンダリング結果が次の ol 要素。IE で見てもらえるとわかりやすいだろう。リストマーカが li 要素の生成するブロックボックスの下に寄ってしまっている。

  1. Test Image テキスト
  2. Test Image テキスト
  3. Test Image テキスト

お次は Fix したもの。次のコード断片は、IE5.5, 6, 7 でも意図通りにレンダリングされる CSS 及び XHTML 1.1 文書の例である。

#date-2008-11-19-fix li
{
  /* li 要素にこれを指定することでバグ回避 */
  vertical-align : top;
}

/* デフォルトに戻して影響を最小限に留める (特に IE) */
#date-2008-11-19-fix li div
{
  vertical-align : baseline;
}

/* clearfix: IE */
#date-2008-11-19-fix li div
{
  zoom : 1; /* Fxxk! */
}
/* clearfix: 他UA */
#date-2008-11-19-fix li div:after
{
  display    : block;
  clear      : both;
  height     : 0;
  visibility : hidden;
  content    : "";
}

#date-2008-11-19-fix li div img
{
  margin : 0 0.5em 0.5em 0;
  float  : left;
}
<!-- XHTML 断片 -->
<-- id が変化しているだけでマークアップは全て同じ -->
<ol id="date-2008-11-19-fix">
  <li><div><img src="data/2008-11-19/test-80x80.png" alt="Test Image" /> テキスト</div></li>
  <li><div><img src="data/2008-11-19/test-80x80.png" alt="Test Image" /> テキスト</div></li>
  <li><div><img src="data/2008-11-19/test-80x80.png" alt="Test Image" /> テキスト</div></li>
</ol>

レンダリング結果が次の ol 要素。きちんと意図通りの位置にリストマーカが付与されているのがわかる。

  1. Test Image テキスト
  2. Test Image テキスト
  3. Test Image テキスト

「IE + float + リスト」の組み合わせはホントに鬼門だと思う。でもこういうのってよく使われがち。

脚註

  1. 現状、Beta 2 ではうまくレンダリングされない。ただ、Developer Tool を同一ウインドウ内に表示・非表示するとレンダリングされる。これは Beta 2 のバグだろう。

2008-11-19

IE5.5、IE6、IE7 で li 要素ないしその子孫要素における hasLayout が true である場合、リストマーカが下方にずれるバグの解決法

非常にスマートな解決策を会社の同僚が発見したのでメモ。IE5.5、IE6、IE7 に存在するのだが、li 要素ないしその子孫要素における hasLayout の値が true である場合、リストマーカが下方にずれるというバグがある。hasLayout が true になる条件については MSDN の該当ドキュメントを参照のこと。これの解決法は次の通り。

li 要素に vertical-align:top を指定する

hasLayout が true になってしまう状況は、例えば float を利用した場合が該当する。li 要素内で img 要素を float:left （もしくは right）したい状況はしばしば発生する。先のバグは子孫要素の hasLayout が true なら否応なく発生するので、そのような場合に解決策が利用できる。

例コードを書く気力が……。まあいいや。今度で。

2008-11-17

RSS 2.0 フィードも Valid にした - XML::Atom と XML::FeedPP による Valid な RSS 2.0 フィードの作成法

結構簡単に対応させることができた。以下、XML::Atom を利用して Valid な Atom フィードを生成している場合を前提にして、XML::FeedPP を利用した Valid な RSS 2.0 フィードを生成する方法について解説する。

Valid な Atom 1.0 フィードを XML::FeedPP に食わせただけで生成した RSS 2.0 フィードが持つエラーは次の2つ。

author 要素の内容が不正な形式

これは XML::FeedPP が Atom 1.0 の email 要素と name 要素をきちんと解釈しないのが原因らしい。

Atom 1.0 フィードで、次のような author 要素があるとしよう。

<author>
  <email>taku.eof@gmail.com</email>
  <name>Taku Watabe</name>
</author>

XML::FeedPP を経由して RSS 2.0 フィードにすると、次の形式になってしまう。

<author>Taku Watabe</author>

見事に name 要素の内容しか取得できていない。RSS 2.0 では E-Mail アドレスも記述し、さらに推奨される形式にしなければならない。

で、次のようなコードを書いた。

# 推奨形式の著者名・E-Mail アドレス
my $AUTHOR = 'taku.eof@gmail.com (Taku Watabe)';

# 全アイテムの author 要素を適切な形式に上書き
my @items = $feed->get_item();
foreach (@items) {
    $_->author($AUTHOR);
}

力技だが、うまくいった。

rel="self" な atom:link 要素がない

要するに、次のような自己参照を行う要素。

<atom:link rel="self" type="application/rss+xml" href="http://end-of-file.net/blog/blog.rdf" />

これはある意味しょうがないのかもしれない。しかし、Atom 1.0 でも必須であるにも関わらず「チャンネル要素操作系のメソッド」に該当メソッドが定義されていないのはいかがなものかと思う。

そんなわけで、set メソッドを使用して力技で解決するしかない。また、atom の名前空間を使うので xmlns メソッドを使う必要がある。

で、次のようなコードを書いた。

# フィード URI
my $FEED_URI = URI->new('http://end-of-file.net/blog/blog.rdf');

# atom 名前空間を利用可能にする
$feed->xmlns('xmlns:atom' => 'http://www.w3.org/2005/Atom' );

# atom:link 要素を追加 (rel="self" による自己参照)
$feed->set('atom:link@rel', 'self');
$feed->set('atom:link@type', 'application/rss+xml');
$feed->set('atom:link@href', $FEED_URI);

これですべて解決。

そうして作成された RSS 2.0 フィードを Validator にかけてみると、見事に Valid であることが証明された。やれやれ。

2008-11-15

RSS 2.0 がきちんと出力できてなかった

既に修正済。XML::Feed の convert メソッドを利用して変換すると文字が全部化ける上に、化け方が滅茶苦茶。もう二度と XML::Feed を利用することはないだろう。多言語対応がお粗末すぎる。

代わって白羽の矢を立てたのが XML::FeedPP。きちんと Atom 1.0 を RSS 2.0 に変換できる。ただし、invalid になってしまう。こればかりはどうしようもないのか、そもそも valid な RSS という認識が低いのか……。

RSS 2.0 も valid な出力ができるように色々やってみよう。

2008-11-14

JavaScript でもオブジェクトへの参照をプロパティ名にできたらいいな……でも仕様を考えると現実的じゃない

例えば Perl などではできる。JavaScript ではオブジェクトのプロパティ名として文字列しか与えられない。また、例えば DOM ノードをプロパティ名に与えると、toString() メソッドの返値（文字列）をプロパティ名にしてしまう。そのため、例えば次のコード断片は意図した通りに動かない。

var elem0 = document.createElement("div");
var elem1 = document.createElement("div");
var obj = {};
obj[elem0] = "value 0";
obj[elem1] = "value 1";
alert(obj[elem0]); // "value 1" をアラート
alert(obj[elem1]); // "value 1" をアラート
for (var o in obj) {
    alert(o+" : "+obj[o]); // "[object HTMLDivElement] : value 1" を1回だけアラート
}

要するに、elem0 と elem1 の返値がそれぞれ同一の [object HTMLDivElement] という文字列なので以下略。ネイティブオブジェクトであっても駄目。どれも文字列に変換されるから。

Function オブジェクトの toString() メソッドにおける返値が同じになりがちなパターンのひとつが、関数リテラルによる関数オブジェクト（俗にいう無名関数）を、高階関数で返している場合。特に高階関数で返す関数オブジェクトがクロージャであるような状況は、個人的にはよく起きる。公開関数をいわゆるファクトリやテンプレートのように使うのは、イベントリスナ関数を作る場合の常套手段だったりする[1]ので、結局のところ諦めるしかない。

オブジェクトへの参照そのものがプロパティとして使えたら何が嬉しいのか？　例えば、DOM ノードと関連づけた値をキャッシュしておきたい場合に検索がとっても楽になる。DOM ノードは違うが値は同じという場合（例：XPath のパス）などだ。配列に保存しておいて線形探索なんかしたら、それこそパフォーマンスに影響する。対象要素数が多ければ尚更だ。要素数を n とするとき、計算量（最悪の場合）は O(n) になる。所謂「連想配列」として使える Object オブジェクトは、理論上は計算量が O(1) で済む。雲泥の差といっていい。

とはいうものの、Object オブジェクトにプロパティを持たせて云々という仕様は、JavaScript (ECMAScript) におけるオブジェクトシステムの根幹。もしここを変更するとなるとインタプリタの大改修が必要になるだろうし、そもそも現実的でもなければ、変更すべきでもない。

どうにかして代替案を考えないとなぁ……とぼやき気味の今日この頃。

脚註

  1. Prototype の bind や bindAsEventListener が代表例。

2008-11-12

HHKB Professional JP - これはひどい……？

私も職場で愛用している Happy Hacking Keyboard ファミリに新顔が登場した。何と Professional シリーズの日本語配列（JIS配列）モデルである。

正直、その詰め込みすぎの配列に唖然としてしまった。これが、あの素晴らしい HHKB Professional2 を世に送り出した PFU の製品なのだろうか？　機能美が全く感じられないキー配置……悔しくて泣きそうだ。しかし苦渋の選択だったんだろうなぁ。

このニュースは ASCII.jp とスラドで取り上げられている他、早速 2ch の HHKB スレでは活発な議論・罵倒・賛美のレスが。その中で、「おお、なるほど」と思った書き込みがこれ。

98 ：不明なデバイスさん：2008/11/10(月) 14:25:40 ID:hD9/CuqE

あーなにか変だとおもったら段ズレもいじってるんだな

http://www.pfu.fujitsu.com/hhkeyboard/lineup/pdkb420w.html

通常、中段 (ASDF...) と下段 (ZXCV...) はキー1/2幅分横ズレしてるんだが

Professional JPは1/4ズレに縮めてある。

カーソルと右Shiftを稼ぐためにコンパクトキーボードがよくやる方法だけど、

人によっては下段が打ちやすくなるという副作用が。

105 ：不明なデバイスさん：2008/11/10(月) 15:54:27 ID:Mjys9VCh

>>98

> Professional JPは1/4ズレに縮めてある。

げー、これはちょっと賛否両論だろうな。メインのキー配列をいじるってのは下手すれば致命傷。

HHKシリーズでは下手にカーソルキーなんかで妥協せずに、

テンキーなし&カーソルキーなしですぱっと割り切ってほしかったな。

そりゃカーソルキーがあった方が便利ではあるけどねぇ。

そのために変則配列になるのは本末転倒。

Happy Hacking Keyboard Part25

確かに該当写真をよく見ると、下段列（z のある列）が1/4ズラしになっている。Pro2 の画像と見比べると一目瞭然。これは実際打ち心地にどう影響するのだろう？　今度秋葉原に行ったら実機を触って確かめてみることにしよう。

カーソルキーは個人的にほとんど使っていない。職場で使っているのは Pro の初代無刻印墨だが、カーソルキーが必要になったら Fn 経由で使う。逆に、Fn 経由のほうが慣れればほとんどホームポジションから指を動かさずに対応できてしまったりする（うまく考えてるなぁ、と思った）。

登場したての日本語配列仕様 HHKB。後世にどのような評価を残すかが楽しみである。……案外「これはイイ！」ということになったりして。

2008-11-10

大盛りヒレカツ1人前 - 阿佐ヶ谷「鉄路」

腹も丁度いい具合に空いていたので、阿佐ヶ谷のゴールド街にあるとんかつ屋「鉄路」に行った。ここのとんかつ定食は大・中・小とあるのだが、小でもかなりのボリュームを誇り、キャベツ・味噌汁・おしんこ・奴豆腐・大盛りごはんがついて900円。ただ、残念ながら少々遅い時間に行ったため、ヒレカツしか残っていなかった。そのためヒレカツ定食 (1100円) を注文。小さいハンバーグくらいのヒレカツが8切＋とんかつ定食と同じサイドメニューというガッツリ食べられる状態に。

キャベツは水にひたしていないからきちんと味があったし、ごはんも普通。味噌汁は赤味噌で、具は豆腐とわかめ。カブの漬物はたぶん自家製。肝心のカツは油をきちんと切ってあり、サクサク。肉も食べ応えがある厚み。

惜しむらくは、わかめが煮えすぎて柔らかくなりかけていたのと、ヒレ肉が少々パサついていたことか。味は悪くない（むしろ良い）だけに、この2点は実に惜しい。とはいえ、コストパフォーマンスは抜群。成人男性なら腹9分目以上にはなれる量。また今度、おなかいっぱいになりたい時に行ってみようと思う。アパートからも近いし。

2008-11-09

Atom 1.0 フィードを Valid にした

ようやく対応。本サイトの Atom 1.0 フィードが Invalid であった問題を Fix した。W3C の Feed Validator でチェックしてみるとおわかりかと思う。

フィードは Perl で自動生成させているのだが、XML::Feed の吐く Atom 1.0 フィードが Invalid になってしまっていたのだ。そこで XML::Atom を直接使って出力させるようにしたという塩梅。RSS 2.0 はそうやって生成した Atom 1.0 フィードを XML::Feed の convert メソッドを利用して変換し、出力している。

思わぬ副作用は、RSS 2.0 フィードも一応 Valid になっていること。但し、Recommendations は出てしまっている。……今日はもう力尽きたのでヤメ。

2008-11-08

WebKit in IE? - 言及しただけ

Ajaxian 経由。AppleInsider の記事によると、Microsoft が開催した "Power Developers Conference" で、MS CEO の Steve Ballmer が次のような言及を行ったらしい。

Open source is interesting. Apple has embraced Webkit and we may look at that, but we will continue to build extensions for IE 8.

Microsoft considers adopting WebKit for Internet Explorer

この発言は TechCrunch でも取り上げられて記事になっており、その翻訳は次のようになるらしい。

オープンソースには興味がある。AppleはWebkitを採用した。われわれもその可能性を検討するかもしれない。しかし一方でIE8へのエクステンションの開発は続ける。

Microsoft、「IEへのWebKit採用に興味ある」―多分本気ではあるまいが

ぶっちゃけた話、IE のレンダリングエンジン Trident が WebKit に置換されてくれると非常にありがたい。IE8 は善戦しているものの、Beta 2 段階のバグが他のレンダリングエンジンのアルファ版より酷い有様なのは、率直にいって辟易している。その現状は Feedback フォーラムで垣間見ることができる。IE8 の品質が向上しきれないようなら、年内リリースは難しいだろうし、するべきではない。延期してでも完成度を高めるべきだ。

まあ、そもそも先の Ballmer 発言にしても「ただそう言ってみただけ」といった性質のものだ。それに、仮に CEO が「IE のレンダリングエンジンを WebKit にしろ、これは命令だ」と言ったとしても変更されるとは思えない。

期待しないで待っていた方が無難だし、精神衛生上もよろしいかと思う。もし本気で WebKit にしてくれれば全世界のデベロッパが狂喜乱舞するだろう。私もその末席を汚したい。そんな理想的な未来が訪れればいいが……。

えー、ともかく今は IE8 を何とかしてください。ホントに。このままの品質ではとてもリリースなど不可能なのだから。

2008-11-07

空の境界 未来福音

よーやく買った。『空の境界 未来福音』（竹箒）。同人でハードカバーというのも珍しいなぁ。内容は……まあ未来視のおはなし。そして度肝を抜かれたのが、最終章（？）扱いの『未来福音・序』。アレのアレがアレとアレするとは！　もうネタバレできないじゃんか。これはものすごいインパクト。まさかアレが結局アレを継いでアレとまた……あぁ！

漫画作品も収録されているが、これもいろいろとビックリな出来。ていうかまさかの浅上藤乃再登場。そして……ええと、結局のところ視力とは無関係だということなんだよな。千里眼持ってんだし。

明日は平日かぁ。……この間買った純米大吟醸でも呑んでから寝るか。びっくりするほど酔いがすぐまわるが、不自然じゃない上に香りが最高なんだこれが。

2008-11-03

ねこぢる大全

今日、いつものように駅前の書店に立ち寄ってみたら、『ねこぢる大全』（ねこぢる　文藝春秋）が置いてあった。しかも上下巻で、1冊2381円（税抜）。税込合計5000円。どうしようか一瞬だけ迷ったが、その頃にはレジ前にいた。そのまま買いましたよ。ええ。

全作品を収録しているということで、辞書並のぶ厚さ。それが2冊。読みごたえも抜群。

2008-11-01