Latest topics 近況報告

とりあえずなんでもやってみなはれとか、北方謙三的に言うと「ソープ行け」とか、そういうアレ - Apr 05, 2010

進むべきか退くべきか。違う道を選ぶべきか、今いる道を歩き続けるべきか。@saneyuki_sさんのそういう悩みと、内田樹氏の「なんとなく、で始めた人のほうが長続きする」という話を見てて、こんな事を思ったんですが。

結婚は「好きな物が一致する人」ではなく「嫌いな物が一致する人」とした方が長続きする、という風な話をどこかで見たか聞いたかしました。どうも世の中は、「好きな事が一致してたら、他の所でどんなに相性が合わなくても大丈夫！」という人よりも、「どーしてもここだけは我慢ならない！　という点で問題がなければそれ以外の事はだいたい妥協できるよ」という人の方が多いみたいです。僕自身もそういうタイプな気がします。

思い返してみれば僕自身、プログラミングでご飯食べる事になるとは小さい頃にはこれっぽっちも全く考えてなかったと思います。どちらかというと、数十人にも及ぶキャラクター達の膨大な設定と、彼らの暮らす世界の通貨やら単位系やらにまで言及した細々とした世界設定と、世界の始まりと終わりを股にかけるようなやたら壮大なストーリーを盛り込んだ、超大作RPGを作るプランナー的な立場に超憧れていて、RPGツクールとかRPGメーカーとかを買ってはみたものの、最初の村すら完成させる事ができず、いやまあそんな事はどうでもいいんですが、とにかく「クリエイター」に憧れてはいたけれども「プログラマー」には憧れてはいなかったと思うんですよ。

そもそもこのサイトを作り始めたきっかけは、自作の絵をメインコンテンツとして公開する場所を設けたかったからだと思います。そう、今じゃ年に2回くらいしか絵を描かなくなってしまいましたが、当初の自分の心の拠り所は「絵描き」だったのです。将来はキャラクターデザイナーになりたいとか、イラストレーターになりたいとか、そんな事を夢想していたりもしたのです。

またある時は、プロモデラーに憧れた事もありました。プロポーションをいじる加工のやり方や関節を増やす加工のやり方を勉強して、MG RX-78-2 Ver.kaをスマートにする改造とか電撃ホビー付録のとにかく動かない1/144 TR-1ヘイズルをフル可動にする改造とかやったりもしました。が、今では成形色仕上げのお手軽パチ組みが関の山です。

どうしてこうなったのか、理由はたくさんあると思うんですが、自分の内面的な最大の理由は「面倒だったから」で説明できる気がします。

絵を描くのってめんどくさいんですよね、ぶっちゃけ。背景を真面目に描こうとすると、パース取るのに気をつけなきゃいけないし、木の葉っぱとか窓とか真面目に描くと本当に単純作業だし。それでも頑張って完成させたとしても、雰囲気のいい写真には絶対敵わないわけですよ。風景を描くのが好きで描いてるんじゃなく、風景がないとみっともないから嫌々描いてるだけだから、そこには愛がないのです。

プラモは、塗装がとにかく嫌なんですよね。道具の準備と片付けがものすごくめんどくさい。気が短いから半乾きで触ってしまって指紋べっとり、なんてのはしょっちゅうですよ。乾くの待ってる間に熱意が冷めてしまうし、なんとか頑張って最後まで仕上げた所で、中国のおばちゃん（お姉さん？）が手がけたGFFよりもヘボい仕上がりにしかならないし。とても報われません。塗る楽しさじゃなくて、できあがった物でブブーンドドドドドと遊ぶ方が楽しいのです。いわゆるブンドドです。

それらに比べるとプログラミングは、まだ長続きしてるんですよね。面倒な所はコピペしても誰も文句言われない、むしろそれ（車輪の再発明をしないで、ライブラリを利用するようにする事）が奨励されてるくらいです。自動テストを書くのも、果てしないリグレッションの嵐に終止符を打つ事ができるからです。手作業で10時間かかる面倒な事を10時間かけてこなす事が尊ばれるのではなく、仮に10時間でも20時間でもかかったとしても、実行したら1分で自動的に片付けてくれる自動処理を書く事の方が尊ばれる。それが自分の性に合っているのだと思います。

ただ、すべての人がそうだとは思いません。人によっては、自動化の手順やらなんやらを考える事が苦痛でたまらない、そんな事するくらいだったら淡々と手を動かす方がいいよ、って場合もあるだろうと思います。

そこが多分、自分が一番多くの時間を過ごす事が何になるのかを決めるポイントなんじゃないかと思います。

自分にとって、何が耐え難い苦痛なのか。どうであったら我慢できるのか。苦にならないのか。苦にならない物であれば長続きするわけで、長続きすればそれだけ沢山経験が蓄積されるわけで、嫌々やらされる場合に比べたらそれは大きなアドバンテージになると思うんです。やる気の燃費がいい、というか何というか。

でも、何が耐え難い苦痛になるのかなんて、実際やってみないと分からない部分が大きいんですよね。やってるうちに慣れるかもしれない。というか大抵の事は慣れてしまう。人間の適応力ってすごいみたいです。「美人は3日で飽きるけど、ブスは3日ですぐ慣れる」なんてフレーズもありました。だから、恐れることなく色々手を出していいんじゃないかと思います。若くても、大人でも、それは変わらないんじゃないかと思います。

続いてるかもしれない

Why I don't roll Tree Style Tab back to the version which have the option "hide new tab button"? - Mar 31, 2010

I got some requests to add an option "hide new tab button" again.

Excuse me, but I say "no". There are two reasons.

First, by adding too many options, users consider Tree Style Tab as an all-in-one/versatile addon, and novice users who don't understand what is the purpose of TST will also install it. I don't hope that future. Actually, I received some requests like "please add an option to disable tree features, I want only a vertical tab bar." -- I just ignored it.

Yes, currently TST has some features not related to tree, but they are anguished decisions. When I find out other addons which provide those futures, I'll readily remove them from TST itself, and make TST work with those addons together. (Actually I removed "open selected links in tabs" and some features.) I hope that only users who want to use "tree of tabs" install TST.

By the way, in old days I developed an all-in-one style addon "Tabbrowser Extensions" which was well-known before the Tab Mix Plus became major. It had very various options about tabs, it had huge codes, I received too many requests, and I gave up to continue to develop it. I don't want to repeat stupid thing like that.

Second, hiding the "new tab" button is a choice of an user who use another addon to do it. TST is designed to work with visible"new tab" button, and not designed to work without the button. If you decide to hide the button at your own risk, you also have to care the result, especially when you hide the button by customizing of userChrome.css.

Nonetheless, If you hide the button by an option of an existing addon, then I should add some hack to TST for compatibility with the addon, because I said "and make TST work with those addons together." Which addon do you use, Tab Mix Plus? TMP Lite CE? Tab Utilities? If you tell me which is installed, then I can write hack for the addon promptly.

regards,

ツリー型タブにツリーと関係ない機能を加えてくれという要求は尽きない。何度でも言うけど、ツリー型タブを多機能アドオンにするつもりは全く無いし、現状でツリーと関係ない機能が含まれているのは実装上の都合とかそういう理由による苦渋の選択だし、そういう機能を取り除けるものならどんどん取り除いていくつもりだし実際そうしてきたし、とにかくそこを譲るつもりは全くこれっぽっちもありません。特に、アドオンを自分で作ってないエンドユーザの立場から物を言っている人に対しては。自分で作ってる人にはもちろんこう返しますよ、「じゃあそのためのアドオンをあなたが作って下さい。なるべく連携できるようにこっちも頑張るから。」と。

Minefield 3.7a4preのタブバーの仕様変更に対してツリー型タブで取った対応方法 - Mar 29, 2010

タブバーがtabbrowser要素の中から取り出されて1つのツールバーになったということで、タブ関係の挙動を変える系のアドオンが死屍累々なんじゃないかと不謹慎にもwktkしてるわけですけれども。特に影響が大きくて話としても「あーそりゃそうなるわな」ってのが分かりやすいのは、やはりタブバーの表示位置の変更機能ですよね。

今まで

今までは、Firefoxのメインウィンドウの中身は簡単に言えばこんな要素構造になってた。

<toolbox>
  <toolbar/>
</toolbox>
<tabbrowser>
  <tabbox orient="vertical">
    <tabs orient="horizontal">
      <tab/>
      <tab/>
    </tabs>
    <tabpanels>
      <browser/>
      <browser/>
    </tabpanels>
  </tabbox>
</tabbrowser>

XULのレイアウトは主にMozillaの関係者からCSS3に提案中のflexible box layoutに基づいてるんだけど、

• -moz-box-orient: horizontal（XUL要素の属性指定だとorient="horizontal"）だとボックスの中身が横に並ぶ。
• -moz-box-orient: vertical（XUL要素の属性指定だとorient="vertical"）だとボックスの中身が縦に並ぶ。
• -moz-box-ordinal-groupの値（XUL要素の属性指定だとordinalの値）の順にボックスが並べ替えられて表示される。

これだけの事を組み合わせれば、タブバーの位置を上下左右好きな位置に移動できた。

• 初期状態では、tabboxのorientがverticalで、tabsにもtabpanelsにもordinalは指定されていないので、タブバーは上に来る。
• tabboxのorientをhorizontalにしてtabsのorientをverticalにすれば、タブバーが左に来る。
• tabsのordinalを2、tabpanelsのordinalを1にすれば、タブバーが下に来る。
• 両方を同時に指定すれば、タブバーが右に来る。

という具合。

これから

ところが、bug 347930のパッチで要素構造が以下のようにガラッと変わった。

<toolbox>
  <toolbar/>
  <toolbar id="TabsToolbar">
    <tabs orient="horizontal">
      <tab/>
      <tab/>
    </tabs>
  </toolbar>
</toolbox>
<tabbrowser>
  <tabbox orient="vertical">
    <tabpanels>
      <browser/>
      <browser/>
    </tabpanels>
  </tabbox>
</tabbrowser>

こうなると、単純にボックスの並び順やら並べる方向やらを変えただけではタブバーの位置を動かせない。

• toolboxの中にtabsがあるので、ordinalではtabbrowserより下にtabsを持って来れない。無理に持ってこようとするとtoolbox全体がtabbrowserの下に来てしまう。
• toolboxの中にtabsがあるので、orientではtabbrowserの横にtabsを持って来れない。無理に持ってこようとするとtoolbox全体がtabbrowserの左に来てしまう。

ドン詰まりですね。

他のタブ関係のアドオンが採用した方法

alice0775さんの調べによると、タブバーの位置を変える機能を持ってる他のアドオンでは、tabsを一旦DOMツリーから取り外して別の位置に挿入し直すという方法で、タブバーの表示位置変更を実現しているらしい。

しかしこのやり方だと、tabsがDOMツリーから取り外されるより前に他のアドオンが行った初期化処理の効果がリセットされてしまう場合がある。リンク先のエントリでいくつか挙げられてる懸念がそれ。

本当だったらFirefox本体の方でなんとか面倒を見て欲しい（タブバーの位置変更を行う機能を持たせて、位置が変わる前と後でイベントを発行するようにするとか）所なんだけど、責任者の人達をIRCで英語で説得する自信は全く無いチキンでTOEICスコアめためたで英語音痴な僕は、アドオン側でなんとかする方法を考えないといけない。しかし、最も単純なやり方（DOMツリーの改変）だと他のアドオンとの競合という点で弊害が大きすぎる。

そういうわけで、ちょっと考えてみました。DOMツリーをいじらずにタブバーの位置を変える方法を。

ツリー型タブが採用した方法

ヒントになったのは、XUL/Migemoの「タブバーの下に検索バーを移動する」機能や、Unified Sidebarの「サイドバーを縦型タブバーの下半分に表示する」機能の実装方法。

これらのアドオンでは「検索バーやサイドバーを表示したい位置にmarginやpaddingでスペースを設けて、検索バーやサイドバーをCSS2のポジショニングでその位置に重ねる」という方法で、DOMツリーを改変することなく要素の表示位置だけを変更している。また、ウィンドウの大きさなどが変わった時には、resizeイベントを捕捉して表示位置や要素の表示サイズを自動調整するようにしている。

ツリー型タブのMinefield 3.7a4pre対応でも、基本的にはそれと同じ方法を使う事にした。ただ、タブバーの幅をリサイズできるようにするsplitterを、ポジショニングで表示位置を変えられた状態向けにゼロから作りなおすのは面倒だったので、tabboxの中にダミーのhbox要素を挿入して、splitterは普通にXULのsplitterを使い続ける事にした。

<toolbox>
  <toolbar/>
  <toolbar id="TabsToolbar">
    <tabs orient="horizontal">
      <tab/>
      <tab/>
    </tabs>
  </toolbar>
</toolbox>
<tabbrowser>
  <tabbox orient="vertical">
    <hbox/>
    <splitter/>
    <tabpanels>
      <browser/>
      <browser/>
    </tabpanels>
  </tabbox>
</tabbrowser>

このようにした上で、

• hboxを含むtabboxの内容を、Firefox 3.6までの手法でレイアウトして、tabsの表示用のスペースを確保する。
• hboxの上に同じ大きさでtabsを重ねる。
• splitterによってhboxがリサイズされた時は、tabsの位置や大きさを自動的に更新する。

とする事で、ぱっと見は今までと同じような挙動を実現しつつ、タブ周りのDOMツリーは一切破壊しないという実装になった。

どっちのやり方の方がいいのか

ツリー型タブのやり方とTab Mix Plus等のやり方のどっちがいいかは、一概には言えない。どちらにもメリットとデメリットがある。

ただ僕は、ツリー型タブで採用したやり方の方が「他のアドオンが全く動かなくなってしまうような衝突の仕方はしなくて、仮に衝突しても最小限の労力でなんとか回避できる可能性が高い」と信じている。

現在Firefox本体の側には、3.6以前のバージョンのFirefox向けに書かれたアドオンについて、Minefield 3.7a4pre以降でもそのまま動くようにするためのパッチも取り込まれている。ちょっとアドオンの作り方に気をつけさえすれば、タブをダブルクリックした時の挙動を変えるとか、リンクから開いたタブの位置を制御するとかいった単機能のアドオンは、ほとんど何も手を加えずにMinefield 3.7a4pre以降に対応できるようになってる。

しかしながら、Tab Mix Plusが現在採用している（らしい）DOMノードを切り貼りするやり方では、「ほっといても他のアドオンがちゃんと動いてくれる」ようにはなりにくい。「DOMノードの切り貼りでタブバーの位置が変更された事」を検知して何らかの特別な初期化処理を行うようなコード、を他のアドオンの側に加えてもらわないと互換性を保てない。僕は、僕のアドオンと競合しないで使えるようにするために、他のアドオンの作者がわざわざ気を使ってくれるとは思えない。僕が作ってる物が、そこまで他のアドオン作者から特別視してもらえる存在だとは、思えない。

なので、僕がアドオンを作る時はなるべく、他のアドオンの側に変更が必要になるような作りにはしないでおこうと思ってる。どうしてもそうなる時は、APIを提供してAPI経由でスッキリと連携できるようにしようと思ってる。そういう謙虚というか悲観的な姿勢が、「ユーザがどんなアドオンと組み合わせて使うかは全く分からない」アドオンを作る上では必要なんじゃないかと思ってる。

nsIVariantを使ってるアドオンが終了していた、と思ったら僕の知識の方が終了していた件 - Mar 23, 2010

SCRAPBLOG : JavaScript 製 XPCOM で配列構造・列挙構造のデータをメソッドの戻り値にする

独自に開発したXPCOMコンポーネントに対して配列を渡したり、あるいは戻り値を配列で受け取ったり、ということをやる方法はいくつかある。上記エントリではコメント欄も含めると4つの方法が紹介されていて、そのうちコメント欄にある2つはJavaScriptの配列をそのまま受け渡せるという点で有用だ。特にnsIVariantインターフェースを使うやり方は、戻り値に使う時に余計な引数を定義しなくていいので、実際にそのXPCOMコンポーネントをJavaScriptから使う時にとても使い勝手がいい。

ということでXUL/Migemoでは積極的にnsIVariantを使ってたんだけど、これがMinefield（検証したバージョンは3.7a4pre）で動かなくなってた。

結論から言うと、これはnsIVariantインターフェースのIIDが6c9eb060-8c6a-11d5-90f3-0010a4e73d9aから81e4c2de-acac-4ad6-901a-b5fb1b851a0dに変更されたせいで起こっている問題で、nsIDOMRangeのIIDが変更された時に起こった問題と同様の物だ。

変更が入ったのは昨年9月で、HTML5の新しい仕様に対応するための作業の一環として、何らかの必要があってインターフェースに機能を加えると同時にIIDも変わったらしい。nsIVariantはFROZENなインターフェースじゃないから、nsIDOMRangeの時のようにIIDが元に戻されることは多分あり得ない。よって、考えられる対策は以下のいずれかということになる 。

• APIをXPCOM経由で提供する事を諦める。Firefox 2以前、Thunderbird 2以前を切り捨てて、JavaScriptコードモジュールとして書き直す。
• Firefox 3.6以前用とFirefox 3.7以降用とでXPIDLのコンパイル後のバイナリを分けて、Firefoxのバージョン別に2つのXPIファイルを提供するようにする。

JavaScriptコードモジュールにするデメリットは、Thunderbird 2で利用できなくなってしまう点と、APIが変わってしまう点。バイナリを分けるデメリットは、リリースの時の作業がめんどくさくなる（XPIファイルが2つになるので）という点。どっちを選んでも大変なのは変わらない……

APIが変わってしまうことは避けたかったので、結局、後者の方で対処することにした。

前から使ってるXPI生成用シェルスクリプトに起動オプションでサフィックスを指定できるようにして、

• xpidl.bat
• xpidl.sh

こんなショボいスクリプトを作って、前出のスクリプトと一緒に

call xpidl.bat xulrunner-sdk-1.9.2
bash makexpi.sh -n xulmigemo -v 0 -s "1.9.2"

call xpidl.bat xulrunner-sdk-central
bash makexpi.sh -n xulmigemo -v 0 -s "central"

てな感じで実行するようにして（make.bat / make.sh）、MozillaのFTPサイトからXULRunner SDKのファイル一式を入手して、

• xulmigemo
  • make.bat (make.sh)
  • xpidl.bat (xpidl.sh)
  • makexpi.sh
  • install.rdfなど
• xulrunner-sdk-1.9.2
  • bin
    • xpidl.exe (xpidl)
  • idl
• xulrunner-sdk-central
  • bin
    • xpidl.exe (xpidl)
  • idl

という感じにファイルを配置するようにした。

XPIを作りたい時にはXULRunner SDKが必要になってしまうけど、スクリプトいっこ走らせれば xulmigemo-mozilla-1.9.2.xpi と xulmigemo-mozilla-central.xpi という風に複数のXPIを出力できるようになったので、リリースにかかる手間は少しは軽減された……のかな……

追記。Gomitaさんのコメントを見て、IDLファイルからincludeの行を消して試してみたら、それでちゃんとコンパイルできた。なんでだ……！！！

えーと。ずっと勘違いしてたんだけど、#include "nsISupports.idl" みたいな行は、interface xmIXMigemoFileAccess : nsISupports てな感じでインターフェース定義の継承元に別のインターフェースを使う場合にだけ必要で、戻り値や引数に使う分には単に interface nsIVariant; とだけ書いておけばいいみたいですね……そうすると、コンパイル時には余計なIIDが含まれなくなって、Firefox 3.6まででも3.7以降でも問題なく使えるXPTファイルが作られるみたい。

まとめ。

• IDLファイルの書き方を間違えておらず、最小限の記述だけにしてあれば、コンパイルしたXPTファイルはFirefox 3.6まででもFirefox 3.7以降でも使える。
  • 継承元に使うインターフェースはその内容が定義されたIDLファイルをincludeした上で interface インターフェース名; と書く。
  • そうでない物（引数や戻り値でしか使わないインターフェース）は interface インターフェース名; だけ書く。
• Minefield 3.7におけるnsIVariantのIIDの変更の影響を受けるのは、nsIVariantを継承元としてさらに拡張したインターフェースを定義する場合だけ。

そんなわけで、xmIXMigemo.idlの頭の所はずいぶんスッキリしました。

#include "nsISupports.idl"
#include "nsIObserver.idl"

interface nsIObserver;
interface nsIFile;
interface nsIVariant;
interface nsIDOMWindow;
interface nsIDOMDocument;
interface nsIDOMRange;
interface nsIDOMElement;
interface nsIDOMNode;


/* Utilities: You can use them for your language without additional implementation. */

[scriptable, uuid(4aca3120-ae38-11de-8a39-0800200c9a66)]
interface xmIXMigemoFileAccess : nsISupports
{
（以下略）

Split Browser（分割ブラウザ）をFox Splitterに改名した - Mar 19, 2010

「Split Browser」という名前で公開してたアドオンについて、「名前かぶってるから変えてんか（大意）」というメールが来た。2004年からある「SplitBrowser」という名前のWebKitベースのブラウザの作者の人だった。

こっちの奴は2007年が最初のリリースなので、どう考えてもこっちが悪いですよね……ということで名前を変える事にした。edvakfさんが呟いた「SplitFox」という名前がナイスだと思ったんだけど、検索してみたところそういうハンドルで活動してる人がいたので、これも駄目かーと思ってちょっとひねって「Fox Splitter」にした。

リポジトリ上のファイルは全部修正したけど、リリースはしてないので、今インストールすると表示は「Split Browser」のままです。名前が変わるのは次のバージョンからという事で、今はまだWebページだけの変更。

ツリー型タブのサイドバーをAll-in-One Sidebarと連携させられないの？（I want the tree of tabs to be shown in the sidebar.） - Mar 19, 2010

Q

I was wondering if there is any way to have it open inside All-in-One Sidebar. If so could you please tell me how to do it?

ツリー型タブの縦型タブバーをAll-in-One Sidebarの中で表示する方法があるなら、教えてもらえませんか？

A

Unfortunately, there is no way. Tree Style Tab's vertical tab bar is not a "sidebar panel", so, it cannot be showin in the AIOS sidebar.

There is another addon "Tab Tree" which provide a sidebar panel of tree of tabs.

• http://forums.mozillazine.jp/viewtopic.php?p=33127#33127 (*Japanese)
• http://park2.wakwak.com/~benki/ (*Japanese)

It is abandoned by the author, however, it is very similar to your requirement. He published it as a public domain software, so, if you can, you'll take over the project without any warranty.

By the way, I think that Unified Sidebar possibly help you.

残念ながら、方法はありません。ツリー型タブが提供する縦長のタブバーはサイドバー用のパネルではないので、All-in-One Sidebarの中に表示する事はできません。

他のアドオンで、タブのツリーのサイドバーパネルを提供する「Tab Tree」という物があります。

• http://forums.mozillazine.jp/viewtopic.php?p=33127#33127
• http://park2.wakwak.com/~benki/

作者はこのアドオンをもう更新しないという事を公言していますが、これはあなたの求めているものによく似ています。彼はこのアドオンを、著作権を主張しないパブリックドメインソフトウェアとしているようなので、もしやる気があるなら、あなたはこのアドオンの開発を（許可を求めずとも）引き継ぐ事ができます。

あと、ひょっとしたらUnified Sidebarもあなたの役に立つかもしれません。

独自の文書型宣言を含めつつエラーを出さない方法（XHTML 1.1でXMLとして他の名前空間の要素を組み合わせて使いたい人向けの話） - Mar 17, 2010

僕はXHTMLのルビ（小さな字で読み仮名をふったりするアレ）を使いたくてXHTML 1.1を選択してるんですが、過去にXHTML2で検討されてたl要素（パラグラフより細かい単位の「行」を示すための物）やiframeやなんかをどうしても埋め込みたくなって、しかしそのせいでバリデータでエラーが出てしまうのも嫌だったので、見よう見まねで頑張って独自の文書型宣言を書いてみたんですよ。いつやったのか忘れたけど、結構前に。

<?xml version="1.0" encoding="Shift_JIS"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
    <!ENTITY % XLINK.xmlns.attrib "xmlns:xhtml2 CDATA #FIXED 'http://www.w3.org/2002/06/xhtml2'">
    <!ENTITY % Inline.extra "| xhtml2:l | iframe">

    <!ELEMENT xhtml2:l (#PCDATA|br|span|em|strong|dfn|code|samp|kbd|var|cite|abbr|acronym|q|sub|sup|bdo|a|img|map|object|input|select|textarea|label|button|ruby|ins|del|script|noscript|xhtml2:l)*>
    <!ATTLIST xhtml2:l 
      id    ID    #IMPLIED
      class CDATA #IMPLIED
      style CDATA #IMPLIED
      title CDATA #IMPLIED>

    <!ELEMENT iframe (#PCDATA|br|span|em|strong|dfn|code|samp|kbd|var|cite|abbr|acronym|q|sub|sup|bdo|a|img|map|object|input|select|textarea|label|button|ruby|ins|del|script|noscript|xhtml2:l)*>
    <!ATTLIST iframe
      id    ID    #IMPLIED
      class CDATA #IMPLIED
      style CDATA #IMPLIED
      title CDATA #IMPLIED
      longdesc     CDATA               #IMPLIED
      src          CDATA               #IMPLIED
      frameborder  ( 1 | 0 )           '1'
      marginwidth  CDATA               #IMPLIED
      marginheight CDATA               #IMPLIED
      scrolling    ( yes | no | auto ) 'auto'
      height       CDATA               #IMPLIED
      width        CDATA               #IMPLIED
    >
]>

CGIを使ってIEにはこの文書型宣言を出さないようにしてますが、FirefoxとかChromeとかでトップページあたりを開いてソースを見れば、こういうのが頭にくっついてるのが分かると思います。

で、バリデータ的にはこれでvalidになったのでめでたしめでたしだったんですが、GeckoのDTDパーサ部分にバグがあるらしくて、この文書型宣言を正しく解釈してくれないんですよね。最後の]>ではなくその前の>の部分で文書型宣言が終わったものと見なされてしまうせいで、Firefoxでこのサイトのページを開くと、ページの頭に謎の]>という文字列がくっついてしまう状態になってたのです。表示が崩れるのが嫌だったので、この]>がテキストノードとしてページの頭に存在してる時は動的に削除するようなJavaScriptを書いて、長らくごまかしてました。

そしたら先日、W3CのHTML5のルビに関する議論の中で紹介されてたXHTMLルビサポートのページを見たという方（Leif Halvard Silliさん）がメールを下さいまして、以下のようなハックを使えばページの頭に謎の]>が出てくる事を防げるよ、と教えてくれたんです。

<?xml version="1.0" encoding="Shift_JIS"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
    <!ENTITY % XLINK.xmlns.attrib "xmlns:xhtml2 CDATA #FIXED 'http://www.w3.org/2002/06/xhtml2'">
    <!ENTITY % Inline.extra "| xhtml2:l | iframe">

    <!ELEMENT xhtml2:l (#PCDATA|br|span|em|strong|dfn|code|samp|kbd|var|cite|abbr|acronym|q|sub|sup|bdo|a|img|map|object|input|select|textarea|label|button|ruby|ins|del|script|noscript|xhtml2:l)*>
    <!ATTLIST xhtml2:l 
      id    ID    #IMPLIED
      class CDATA #IMPLIED
      style CDATA #IMPLIED
      title CDATA #IMPLIED>

    <!ELEMENT iframe (#PCDATA|br|span|em|strong|dfn|code|samp|kbd|var|cite|abbr|acronym|q|sub|sup|bdo|a|img|map|object|input|select|textarea|label|button|ruby|ins|del|script|noscript|xhtml2:l)*>
    <!ATTLIST iframe
      id    ID    #IMPLIED
      class CDATA #IMPLIED
      style CDATA #IMPLIED
      title CDATA #IMPLIED
      longdesc     CDATA               #IMPLIED
      src          CDATA               #IMPLIED
      frameborder  ( 1 | 0 )           '1'
      marginwidth  CDATA               #IMPLIED
      marginheight CDATA               #IMPLIED
      scrolling    ( yes | no | auto ) 'auto'
      height       CDATA               #IMPLIED
      width        CDATA               #IMPLIED
    >
<?parser-hack ><!-- ?>
]>
<!--><?!-->

強調箇所がそのハック。処理命令（PHPのコード片を埋め込んだりするのに使うのと同じ奴）の記法でコメントとして解釈できる文字列を埋め込んで、問題の部分を無視させるという物のようです。バリデータに通しても、これでもvalidです。素晴らしいです。

同じような事をやってる酔狂な人がもしいたら役立てて欲しいと思ったので、氏に許可を得てエントリにさせて頂きました。Thanks a lot, Leif!

文法的な解釈

何故これがvalidなのかも考えてみよう。

<?parser-hack ><!-- ?>

• この行は、これ自体で1つの処理命令となる。
  • 処理命令は <?ターゲット名 任意のUnicode文字?> という書式なので、これはあくまで「><!-- という内容」を含んだ処理命令として解釈される。
• 文書型宣言の定義では、[から]までの間に登場しうる内容として処理命令も含まれている。そして、上記の箇所は一つの完結した処理命令である。よって、文書型宣言中に登場しても何ら問題ない。

<!--><?!-->

• この行は、「><?! という内容」を含んだコメントと解釈される。

という具合で文法的には何も問題ないので、W3Cのバリデータはこれをvalidと判断する。きちんとXMLパーサを実装しているブラウザ上でも同様です。

Geckoの解釈

一方、Geckoの解釈はどうか。これは「ソースを表示」での色分けを見るとよく分かる。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [

Geckoはまず、この部分だけで完結した文書型宣言と認識する。「[」で終わりと判断したのではなくて、その次の <!ENTITY が来た時点で「あ、もう文書型宣言は終わってたのね」と見なしてるようだ。

<!ENTITY ～>

<!ELEMENT ～>

<!ATTLIST ～>

この辺はすべて、それぞれ別々の宣言として解釈されている。という事で、

]>

何もハックをしない場合はこの部分だけが取り残されてしまって、Gecko的にはこれが「XML的には不正だけどSGML的にはアリ」なテキストノードとして扱われて、ゴミとして表示されてしまうわけだ。

では、ハック有りの場合はどうなるか。

<?parser-hack ><!-- ?>
]>
<!--><?!-->

Geckoはこれを3つのノードとして解釈している。

<?parser-hack >

まずGeckoは、これを1つの処理命令と判断する。XMLの仕様では ?> が来るまで処理命令の終わりにはならないんだけど、Geckoのパーサは > で処理命令が終わったものと見なしてしまう。

<!-- ?>
]>
<!-->

これは当然1つのコメントになる。

<?!-->

最後、これも <? から > までで1つの処理命令と見なされる。

という事で、ハック有りの時はどの文字もテキストノードとして取り残されずに済むので、画面上は何もゴミが表示されずに済む。

こんなのよく考えるなー、と、読み解いてみて改めて感心しました。

すべて彼女のために - Mar 11, 2010

撃たれると痛い「すべて彼女のために」 - 2010-03-01 - ゾンビ、カンフー、ロックンロールのレビューを見て気になったので、すべて彼女のためにを見てきた。東京だと有楽町、神奈川だと横浜、関西だと大阪で上映してるようです。って3館だけかい！　これから増えるのかな？　毎週水曜の安くなる日でも夜の回は結構空いてました。

• セリフがいきなり英語じゃなくて驚いたんだけど、これフランスの映画だったんですね。
• 妻が逮捕された冤罪については、真実を解き明かすとかそういう展開は無いです。逃げようのない極限状態に追い込まれた時に、人は愛する人のために一体どこまでできるのか？　という事を描くための背景設定でしかないので。
• ギリギリの綱渡りばかりで、見てて非常にハラハラいたしました。
• 親も兄弟も友達も仕事も住む所も、今の生活を全部捨ててでも取り戻したいモノ。それのためにどこまでも強くなろうとする、でもなりきれないで挫けそうになる、主人公の葛藤がすごい。妻が電話口で崩れ落ちる時の絶望感がすさまじい。

見終わった後、圧倒されて言葉が出てこなくなる。そんな映画でした。

Windows VistaからWindows 7へアップグレードした - Mar 08, 2010

会社で使ってるWindows Vistaがどういうわけか、ハイバネーションからの復帰にやたら時間がかかるわ復帰後ほっとくとブルースクリーンになるわで死にかけだったので、一縷の望みを託してWindows 7にアップグレードしてみることにした。（もしなんかのファイルが破損してるなら、そのファイルが使われなくなってくれないかなあ？と思ったので。）

• 「エクスプローラ」改め「エクスプローラー」をファイラ代わりに使うにあたって、左ペインにフォルダのツリーを表示できなくなっていた。
  • フォルダーオプションで「全般」タブの「ナビゲーション ウィンドウ」で「すべてのフォルダーを表示する」と「自動的に現在のフォルダーまで展開する」にチェックを入れてやらないと、今までと同じ使い勝手にできない。
• フォルダアイコンをデスクトップの端にドロップして作るツールバーが、Windows 7では使えない。これまでは、クイック起動をタスクバーから分離して、個別のツールバーとしてランチャ代わりに利用していたのだけれども、代替手段が無くなってしまった。
  • Windows 7のタスクバーはMac OS XのDockのパクリなので、一回起動してタスクバー上のボタンを右クリック→登録 でタスクバーにショートカットを登録できるんだけど、なにぶん数が多い（Firefox 2、Firefox 3、Firefox 3.5、Firefox 3.6、Minefieldのそれぞれで通常起動とコンソール付きの2通り、同じようなショートカットがThudnerbird用にもある）ので、登録し直すのが面倒でたまらない。
    • と思ってたけど、ショートカットをタスクバーにドラッグ＆ドロップすればよかったみたい。こんだけで登録できたのかー！！　無駄な苦労をしたよ……
  • 登録し直してみたけど、それぞれのアイコンの横にラベルを表示できないみたいで、判別に苦労する。
  • ショートカットの実体は C:\Users\ユーザ名\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar に置かれるので、ここにショートカットを置けばタスクバーの方に反映されるのかな？と思って試してみたけど駄目だった。タスクバー上でピン留めしないと表示されなかった。
• Windows 7のインストール時に、互換性のレポートでMicrosoft Virtual PC 2007 SP1がWindows 7での動作を保証されていないという警告が出た。
  • Windows 7になってからVirtual PCを起動すると、VMNetSrv.sysというファイルが見つからないとかなんとかいうエラーが出た。
  • このファイルは C:\Windows\System32\DriverStore\FileRepository\vmnetsrv.inf_x86_neutral_ランダムな文字列？ の位置にあった。ファイルの検索で見つかったので、選択してやると、Virtual PCが起動してくれた。
  • 1回正常に起動した後は、それ以後も問題なく動いてるみたい。
  • クライアントOSのWindows XPとの間でドラッグ＆ドロップでファイルをコピーする機能もちゃんと動いてる。

これでまだ落ちるようだったら無駄なことに時間を使ってしまったということになるのでとても悲しいです。

四次元ポケットを考えていたら、他のひみつ道具の原理も説明できた - Mar 02, 2010

ドラえもんの4次元ポケットについて真面目に考えてみた。

4次元ポケットの中には、外見から想像される容積より遙かに多くの物を格納することができる。また、内部空間はスペアポケットとの間で共有されているため、スペアポケットから入ってドラえもんのポケットから出てくるということもできる。（実際に、行方不明・回収不能になったドラえもんを発見するためにこの方法を使ったエピソードもある。）

4次元という物を正しく理解すると、どのようにすればこういった仕組みを実現できるのかが見えてくる。

4次元を理解するには、2次元と3次元を対比した場合を考えるのが手っ取り早い。

• 2次元の住人である2Dドラえもんや2Dのび太達は、床の上に置かれた1枚の巨大な模造紙のようなレイヤである、2次元世界で生活している。
  • この世界は平面なので、X軸とY軸しか無い。
• ここで、2Dドラえもんがお腹の3次元ポケットに2次元の物体を放り込んだとしよう。するとその物体は、2Dドラえもん達が生活しているレイヤから数mmだけZ軸方向にずれた所に平行に浮かんでいる別のレイヤに移動する。
  • つまり、物体は「3次元ポケットの中に入っている」のではなく、レイヤ同士を繋ぐ3次元ポケットという「ゲート」を通じて別のレイヤへ移動されているのである。
• これらのレイヤの重なりの方向であるZ軸は、2次元世界のX軸とY軸に対してそれぞれ90度直交している。2次元世界の住人達はZ軸の存在を知らないし、Z軸方向に動くこともできないので、隣のレイヤにある物体を見ることはできないし、ぶつかることもない。
• 同様のレイヤが、2Dドラえもんの生活する2次元世界や3次元ポケットの先のレイヤの他にも無数に存在していて、ミルフィーユのように積み重なっている。2Dドラえもんの3次元ポケットの出口をどのレイヤに設定するか――出口をどれだけZ軸方向にずらすかは、おそらく任意に決めることができる。
  • よって、スペア3Dポケットは、出口のレイヤの設定が同一である複数の3次元ポケット同士の事を指すのだと考えられる。
• 2Dドラえもんとスペア3Dポケットが離れた所にある場合はどうなるか。レイヤを何らかの方法で折り曲げると、2Dドラえもん、スペア3Dポケット、そして「3次元ポケットの先のレイヤ」上の点とが重なる。こうして、スペア3Dポケットに入った2Dのび太は、海の底に沈んでいる2Dドラえもんのお腹の3次元ポケットから出てくることができる。
• 同じ事が、ポケットの中に放り込んだ物を取り出す時にも言える。3次元ポケットの先のレイヤと2Dドラえもんがいるレイヤとの関係を逆にすれば、レイヤ状の好きなところにある物を、別のレイヤの2Dドラえもんがいる位置まで持ってくることができると分かる。

話を我々が暮らす3次元を基準にして考えてみよう。

• 我々はX・Y・Zの3つの直交する軸が存在する3次元空間で生活している。
• ここで3Dドラえもんがお腹の4次元ポケットに物体を放り込むと、その物体は、X・Y・Zのすべての軸に直交する第4の軸の分だけ「ずれた」所に移動される。その「ずれた」方向を我々は認識することもできなければ、その方向に我々自身が「ずれる」事もできないので、その物体は目に見えないし、触ることもできない。
• スペアポケットに入ると、自分自身がその「ずれた」方向に同じだけ「ずれる」事になるので、4次元ポケットの中に放り込まれた物体達に遭遇する事ができる。さらにそこにある「出口」を通ると「ずれ」が元に戻るので、またしずかちゃんやジャイアンやスネ夫と再会する事ができる。4次元ポケットとスペアポケットのある位置が離れていても問題にはならない。

こうして考えてみると、どこでもドアや道路光線や通り抜けフープ、ビッグライトやスモールライトやガリバートンネルも、おそらく同じ基礎技術に基づいて開発されているのだろうと考えることができる。

• どこでもドアは、途中で「外に出る」事ができないように、4次元ポケットとスペアポケットとを直結した物だと考えられる。なので、スキャン＆再構築方式のどこでもドアのようなホラーな事態は起こらない。また、これならドアの出口の先が見えることの説明も付く。
  • そういえば、「宇宙開拓史」ではのび太の部屋の床下と宇宙船との間が繋がった（繋がりが切れそうになっている時には「入り口と出口の間の空間」も描写されてた）のが物語の発端だったなあ。
• 道路光線や通り抜けフープは、入口を通ると4次元方向に「ずれた」所に移動して、出口を通るとその「ずれ」が元に戻されるのだと考えられる。単に4次元方向に「ずれる」だけなので、3次元的な移動は徒歩なりタケコプターなりで自力で行わないといけない。
• ビッグライトは、光を当てた物体を4次元方向に強制的に「ずらす」物なのだと考えられる。2次元平面上に置かれた10円玉を持ち上げると、そこにできる影は大きくなる。同様に、物体を4次元方向にずらせば影は大きくなる。
  • ビッグライトとは逆方向に「ずらす」のがスモールライトであり、両方向に対応しているのがガリバートンネルであると考えられる。
  • 影じゃなくて物体そのものの4次元方向の何かを操作するのかも知れない。人間を3次元的に切り刻むともちろん死んでしまうけれど、4次元的に切り刻まれたりこねくり回されたりしても3次元的に問題なければいいということなのかもしれない。
• のび太を上半身と下半身にぶった切った道具（人体切断機だっけ？　名前忘れた）とか、のび太としずかが首から下を交換したりドラえもんにしずかの脚をくっつけたりした道具とか、任意の動物と合体できる合体のりとか、あの辺の道具も実は4次元的な操作で実現してるのかも知れない。

同じような理屈で、移動する物や大きさを変える物、形を変える物の「原理」を色々と説明することができる。ひょっとしたらタケコプターすらも、同じ基礎技術を使っているのかもしれない。ドラえもんが開発された22世紀というのは、このような4次元を扱う技術が高度に発達した時代なのかもしれない。

この考えの中で一番問題になるのは、「空間を折り曲げる」という所ではないかと思う。

• 4次元方向の軸に沿った「回転」や「すれる」動作は、多分それほど大きなエネルギーを使わなくても済むはず（位置が大きく変わるわけではないから）。
• 4次元方向への軸に沿った操作が可能になった時にまず実現されるのは「通り抜けフープ」や「道路光線」の類だろう。これらは単に、4次元方向に「ずれる」だけで実現できるから。
• しかし空間を曲げるとなると、物凄いエネルギーが必要になるのではないか？　ブラックホールはその巨大な質量のせいで周囲の空間を歪めるそうだ。任意の2地点を繋げるように空間を歪めるとなると、ブラックホールと同じくらい、あるいはそれ以上の質量が必要になるのではないか？
• その点が解決されない限り、4次元ポケットは「物を放り込んだり取り出したりする」事はできても「放り込んだ物を一緒に持ち歩く」事はできない（同じ場所でポケットを使わないと、入れた物を取り出せない）。

ところで4次元ポケットは、ドラえもんに限らず誰でも任意の道具を取り出すことができる。また、ドラえもん自身ですら、混乱している時には望みの道具を一発で見つけることができない。この事から、4次元ポケットは利用者の思考を何らかの方法で読み取ってそれに対応する内容物を返す、汎用的な物体格納・運搬デバイスなのだと考えられる。

• ドラえもんは「子守用ロボット」であるが、上記のように4次元ポケットを考えた場合には、ドラえもん自体を「4次元ポケットというデバイスを子守という目的に有効活用するために、子供が与える曖昧なインプットに対して適切な道具を検索するデータベースおよび人工知能を備えたロボット」であると言うこともできるだろう。
• ひょっとしたら、ドラえもんと同一のハードウェア仕様で検索用データベースや人工知能の思考エンジンだけが異なる、介助用ロボットや探査用ロボットというのも存在するのかもしれない。
  • エクステリアまで完全に同一仕様だと耐圧性能だとかそういう点で性能要求を満たせなかったり逆に過剰品質になったりしそうだから、コンピュータ部分だけが共通でそれ以外は別な方がいいかもしれない。