Latest topics 近況報告

MNGMNGってお前はMNGキチか！って話 - Nov 25, 2010

背景。

• PNGの仕様には、アニメーション用の形式としてMNGというものも含まれてる。
  • アルファチャネルを含んだアニメーション画像を作れる形式の1つ。
  • 色々詰め込みすぎて仕様が膨大という欠点がある。
  • Mozillaは過去（Mozilla Suite 1.7まで）にはMNGに一応対応してた。
• MozillaはFirefox 3で、MNGとは別のAPNGという形式に対応した。
  • APNGはアニメーションできるPNG。
  • MNGより仕様が単純。
  • APNGの仕様はPNGの仕様の標準化グループに提出されたが、標準仕様には含まれない事になった。（なので今の所はあくまでMozillaの独自形式。）
• MozillaはAPNGに対応する代わりにMNGに対応しなくなった（MNGデコーダがリリース版のバイナリには含まれなくなった）。
  • 「MNGなんて誰も使ってない」「そのくせデコーダがでかくてインストーラのサイズが無駄に大きくなってる」などがその理由だったようだ。

Web標準に対応しなくて自社独自の技術だけ使い続ける、というのはまあよくある事だから、ことさらMozillaだけをあげつらう事はないと思うんですよ。VMLには対応するけどSVGには対応しないというIE8までの方針であるとか、そういうのはありふれてる。

また、標準仕様はあるけどまだ実装されてない、っていうのもしょうがないと思うんですよ。仕様そのものが曖昧だとか、仕様が膨大すぎて対応できないとか、需要がそもそも無いとか。

釈然としないのは、

• 一度はMNGに対応していたのに、対応のためのコストが高いワリに需要がないからということで、対応しなくなった。 その後改めて需要が発生した（半透明のアニメーションを使いたくなった）時に、MNGサポートを復活させずに、別のもの（APNG）を新しく立てた。
• Mozillaはよく「Web標準を大事にしている」とアピールしている。Appleが「HTML5のデモです、これを見るにはSafariが必要です」って言ってる事に対してもMozillaは激しい非難をしていた。

これが僕には2枚舌に見えるってこと。

APNGに新たに対応して今後はそっちをメインで使っていくよ、というのはまあ別にいいんですよ。でも、今まで一応対応してたMNGをこれを機にばっさり切り捨てちゃう今まで一度は対応してたことがあったMNGを顧みることもなく別の物をっていうのはどうなん？　それじゃあ、なんかの動画形式で動画を埋め込んでて、その形式に対応してなかったらMNGにフォールバックして、みたいな事ができなくなっちゃうじゃんできないまんまじゃん？　フォールバック先にはやっぱり、仕様が標準化されてて安心して使える形式を選びたいじゃん？　そういう感じでMNGを使ってた使いたい人がいたかもしんないじゃん？　僕はまだ使ってなかったけど、静止画の簡単なアニメーションを公開する事があったら是非そうしたかった。Web標準ってそうやって、地ならしっていうか下支えっていうかそういう所でも活きてくる物だと思ってたんですよ。

いやMozillaの言い分もわかるっちゃ分かるんですよ？

• 「中途半端に対応する方が、全く対応しないよりもよっぽど悪い」という考え方。
  • 特に、バグがあるにも関わらず修正しないままずっと放置してて、間違った挙動や結果の方がデファクトスタンダードになっちゃう、というまずい事態が起こりうる。
    • CSS2のrect()はそれでIEの実際の挙動の方に合わせて仕様がCSS2.1で「修正」されたんだっけ？
• 人的リソースの問題。既にある機能を壊さないように維持し続けるコストの問題。
  • Microsoftとかはサポート契約をしてお金を貰う代わりに長期に渡ってサポートし続けますよ、ということをやってる。そうしてコストを負担してもらえてるからこそ長期にサポートし続けられる。
  • MNGに関して誰もそういうコストを負担してくれない以上は、MozillaはMNGをサポートし続けられない。

「MozillaはWeb標準を限定的にしか尊重しません。自分たちの組織を維持できなくなるレベルでコミットする事はありません。自己犠牲でWeb標準のために殉死するつもりはさらさら無いです。」というのは真っ当な判断だと思うんですよ。

でも、だったら、「お前はWeb標準を大事にしてない」って他者を非難する資格も無いんじゃないの？　自分の事は棚に上げるの？　そういうみっともない事をしないでくれよ。Mozillaだけはそういう事をしてくれるなよ。

っていうモヤモヤがずっとある。

Google Chromeでツリー型タブ - Nov 10, 2010

ツリー型タブのGoogle Chrome版は作らないの？という問い合わせを一時期よくもらってたんだけど、とうとう出た。Google Chrome版Tree Style Tab。といっても僕が作ったんじゃなくて、ジェバンニが一晩でやってくれました。的な。

• 45: Tree Style Tab 風のタブ管理を提供する chrome extension

ただ、やはり僕が懸念していたように、形態としては「ツールバーのボタンをクリックしたらポップアップでツリーが出る」という物のようで、実際試してみても違和感があった……　僕は「ツリーが常に見えている事」がTSTの常用には欠かせないと思っているので、この形の物はやはり辛い。

Side Tabs（起動オプション --enable-vertical-tabs で有効になる）が入っている最近のChromeでなら、あともうちょっと頑張ればなんとかなりそうな気がしなくもない。ページのタイトルの頭にスペースを挿入して擬似的にタブをインデント表示するとか。

msysgitとTortoiseGitの組み合わせでSSHでの接続に失敗する - Nov 10, 2010

SubversionからGitに移行したまとめには書いてなかったけど、TortoiseGitを使うと git@github.com:piroor/treestyletab.git とかのcloneやpullに失敗するという現象に遭遇した。「じゃあ諦めてmsysygitのbashコンソールからやるか……」で今まではなんとかなってたんだけど、これもいつの間にか動かなくなってた。「fatal: the remote end hang up unexpectedly.」とか言われる。

僕は会社でメインで使ってるUbuntuの上で作ったOpenSSHの鍵を使ってて、Windows環境ではそれをPuTTY形式の鍵に変換して使ってる。変換がうまくいってれば、OpenSSHの公開鍵をauthorized_keysに登録してあるサーバに対してもPuTTYで接続できる事を確認済み。pagent.exeが起動していてそいつにPuTTY形式の鍵が読み込まれていれば、パスフレーズの入力も省略できる。

なのにGitではうまくいかない。

TortoiseGitでSSHできない件についてはTortoiseGit 1.5.8付属のTortoisePlink.exeのバグらしい。次のリリース版では直ると書いてあるけど、今使えないんじゃ困る……なので、TortoiseGitの設定ダイアログのNetworkの所でSSH Clientに「C:\Program Files\TortoiseGit\bin\TortoisePlink.exe」の代わりに「C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe」（TortoiseSVN付属のTortoisePlink.exe。こっちはこのバグがない。）を指定して回避することにした。

これでGUI（TortoiseGit）からはcloneしたりpullしたりpushしたりできるようになったんだけど、msysgitのbashからは相変わらずpullも何もできなくてやっぱり「fatal: the remote end hang up unexpectedly.」って言われる。

エラーメッセージで検索してたら、英語圏のフォーラムの記事が引っかかったんだけど、読み進めてるうちにGIT_SSHという環境変数が関係してるらしいという事が分かった。bashコンソール等でSSH経由での接続を試みる時は、Windowsの環境変数でGIT_SSHに入ってる物がSSHのクライアントとして使われるみたいだ。早速システムのプロパティで確認してみたら、大当たりだった。「C:\Program Files\TortoiseGit\bin\TortoisePlink.exe」とバグ持ちのSSHクライアントのパスが入ってたので、「C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe」を指定し直しておいた。bashコンソールを起動し直してもう一度試したら、ちゃんとpullできるようになってた。

TortoiseSVNだとフォルダを複数選択してまとめてチェックアウトでワーキングコピーを最新の物に更新できてたんだけど、TortoiseGitだとそれがうまくいかないようだったので、こういうbashスクリプトで代用しようとして、Windows環境だとgitにパスが通ってない（Cygwinとmsysygit両方入ってる環境だから敢えてmsysgitにはパスを通してない）から

for dirname in *
do
  if [ -d $dirname/.git ]
  then
    cd $dirname
    echo "pull: $dirname"
    "/c/Program Files/Git/bin/git.exe" pull
    echo "submodule update: $dirname"
    "/c/Program Files/Git/bin/git.exe" submodule update --init ""
    "/c/Program Files/Git/bin/git.exe" submodule foreach 'git fetch;git c he cko ut  origin/master'
    cd ..
  fi
done

としてたんだけど、それがうまくいかなかったからムキーッとなってたんだけど、うまくいくようになってよかった。

Jetpackを読み解く - Nov 10, 2010

Developers Conferenceでの発表向けの内容に盛り込めそうにない話を書いていく。

話のテーマを決めるにあたって、とにかく最初は1つJetpack SDKでアドオンを書いてみようと思ったんですよ。

でも、「こう書くと動きますよ」って言われてもなんだか信じられなかったというか、どういう経路でどういう風にしてそのコードが読み込まれるのか分からなくて、スクリプトの書き方次第じゃ他のコードに悪影響を及ぼしたりすることもあるんじゃないのか？（prototoype.jsのObject汚染みたいな感じで）とか、名前空間の衝突は大丈夫なのか？　とか、そういうどーでもいい所が気になって気になって、仕組みが分からないまま使うのは怖いと思った。何をやってよくて、何をやったら駄目なのか、というのが分からないのが怖かった。

その境目を見極めたくて、Jetpack自体の成り立ちを探ってみたのですよ。

特に謎だったのが、他のモジュールを読み込むrequire()。これが一体どこで処理されているのか。main.js（Jetpackでアドオンを作る時の主たる実装になるファイルの固定の名前）もどこかからrequire()されているのなら、require()の実装を見たら謎が解けるんじゃないかなーと思った。

• 核になるのは packages/jetpack-core/lib/securable-module.js の内容。Jetpackで頻出のexportsやrequire()はここで定義されている。
  • コードを見ると、CommonJS風のやり方だけでなく、JataScriptコードモジュール形式の書き方（EXPORTED_SYMBOLSを使うやり方）にも対応してるみたい。
• コードを追っていくと、最終的に Components.utils.evalInSandbox() が呼ばれていることが分かった。ライブラリのモジュールもmain.jsも全部これで実行される。
  • ということで、JavaScriptの名前空間の中での事に関してはどんな無茶をしても大丈夫そうという事が分かった。
• もうひとつ、packages/jetpack-core/lib/cuddlefish.js も重要っぽい。
  • Jetpack自体の組み込みのライブラリでしょっちゅう使われてるユーティリティっぽいモジュールであるところの require("chrome") の実態が、これ。
  • Cuddlefish Labというアドオンの形で導入することもできるみたい？
  • Labs/Jetpack/JEP/28に、詳しい事が書かれてる。

Jetpackとは、この基本的な仕組みに基づいて、個々のモジュールの名前空間を分け、それらを安全に連携できるようにしたもの。と言える。MozLabでmodule_manager.jsというものが過去に使われていて、それを想起させられた。

module_manager.jsはJavaScriptコードモジュールが無かった頃にJavaScriptそのものの言語仕様を超えた所で高度なモジュール化を行おうとしていたらしく、渡されたモジュールの名前からパスを生成してファイルを読み込んでサンドボックス内で実行してそのグローバルオブジェクトを保持し続けて……ということを普通のJavaScriptの機能とmozIJSSubScriptLoaderでやってた。Jetpackの仕組みはそれのずっとスマートなバージョンなのかなと思った。

今までの開発手法しか知らなくてJetpackがさっぱり分からないという僕みたいな時代後れの人でも、securable-module.jsとcuddlefish.jsを起点にすれば、他のモジュールも無理なく読んでいけるんじゃないだろうか。

Jetpackへのモヤモヤを全部吐き出そう - Nov 08, 2010

僕はJetpackに対していろんな意味で期待していたはずなのに、自分がJetpackでバリバリ開発する姿はいまいち想像できないでいる。Jetpackの話が出始めた頃よりも、JetpackがrebootされてSDKとなってからの方がむしろ、「あれ、なんか僕ってJetpack使ってなさそうなんじゃね？」感が強くなっていっている気がする。Jetpackは僕を幸せにしてくれるのか？　くれないのか？　それが分からない。

Firefox Developers Conferenceでの発表について「Jetpackからよりディープな世界へのステップアップや、あるいはその逆に、これまでの手法でアドオンを開発していた人達がJetpackにステップアップするには？　という風な話題」というオーダーをもらって、ようやっと重い腰を上げてJetpack SDK（とPython）をインストールしてみた。で、とりあえずJetpackの流儀というのを理解しなきゃと思って実際にアドオンを書いてみようとしていきなり挫折して、ドキュメントを読んでみようとしたけどどこから読めばいいのかすら分からなくて頭クラクラで、ヤケクソでJetpack SDKそのもののコードを読んでみたりして、という事をやりながらモヤモヤと考えてた。何故僕はこんなにも、Jetpackに乗り切れていないのか。

現実的にはJetpackを使った方がいい・使わざるを得ないという状況になってきている

Jetpack SDKのドキュメントをちょっと読んで雰囲気を眺めただけでも、僕の今までの知識はまるで役に立たないということはよく分かった。

アドオンを構成するコードは、大雑把に言うと

1. 「タブの上でダブルクリックしたらタブを閉じる」とか「twitterで新しいツイートがあったらポップアップを表示する」とかの、ユーザ視点での便利さの向上に繋がる機能のためのロジック。Railsでいうなら、generateで生成されるRailsアプリケーション。
2. 「タブの上で行われたマウスの操作を拾って任意の関数を実行する」とか「ポーリングやソケット通信を使ってサーバから必要な情報を取ってくる」とか「自動的に消えるパネルをデスクトップ上にフェードイン・フェードアウトで表示させる」とかの、前項のロジックを実際のアプリケーションで実現するための基盤。RailsでいうならRailsというフレームワークそのものにあたる部分。

の2つのレイヤに分けることができる。

これまでのアドオン開発においては、2の部分の開発コストが非常に大きかった。W3CのDOMであるとかCSSであるとかのWeb標準の知識がベースにあるとはいっても、XULやXPCOMというMozilla specificな技術を覚えなければならないし、覚えた上で、さらに工夫しないといけない。はっきり言って、アドオンのコードのほとんどは2のための物で、1のためのコードなんてのはほんの一部分だけだったりする。2の部分をどうやって解決するかというのが問題の大部分を占めていて、ほとんどの人はおそらくその段階で挫折してしまって、本題である1の部分に取りかかる事すらできないのだと思う。

僕は、そこ（2のレイヤ）に膨大な時間を注ぎ込んできた。そこに時間を取られるせいでFirefox本体の開発に貢献とかそんなとこまで頭が回らないよ、というくらいの勢いで。その結果蓄積された大量のバッドノウハウこそが、今の僕の武器であり価値なんだと思う。

でも、そういうバッドノウハウはすぐに陳腐化する。また、せっかく覚えたXULやXPCOMの知識も無駄になる時がある。特に、Gecko 2.0からはすべてのインターフェースが凍結されなくなるということは、これからはnsIPrefBranch::getBoolPref()のような頻出のインターフェースすら安心して使えなくなるという事で、かかるコストと得られる物が全然釣り合わないんじゃないのか。

という事を考えると、「だからこそJetpackなんだよ」という話は理解できる。Jetpack SDKは、2の部分をアドオン開発者の代わりにカバーするライブラリ集でもある。Gecko 2.0以降のインターフェースの不安定さをJetpack SDKが吸収して隠蔽してくれるから、開発者は2の部分のためにかける労力が要らなくなって、全力を1の部分の開発に注げるようになる。という寸法だ。1と2の両方に（特に2の部分に異常に多くの）力を注がなくてはいけないロートルの開発者と、1のことだけ考えて開発していればいい新しい開発者、どっちの方が生産性が高くてクリエイティブな結果を沢山生み出せるか。あるいは、どっちの方が労力が少なく済んで、長くメンテナンスし続けられるか。そういう話だ。

その謳い文句、本当なの？

しかし、ホントにそんなにうまくいくのかな？

今でも、過去にFUELという「アドオン開発者向けの、Firefox組み込みのライブラリ」が作られて、それが「XULやXPCOMといった小難しい物を隠蔽すること」を目指していたはずなのに、仕様が十分に錬られてないわ利用者（アドオン開発者）にとっての使いやすさという視点が欠けてるわ実装もあまりにやっつけ仕事でヘビーな利用には全然耐えられないわ（普通に使うとメモリリークしまくる）で、あっという間に「ああ、そんな物もあったっけ……でも使ってる人いるの？」な位置に落ちぶれてしまった。搭載当初は何も特別な準備をしなくても使えるように作られてたのに、Firefox 4からは「コイツの初期化に時間かかるから、初期状態で使えるようにわざわざしておく必要ないよね」と「一級市民のAPI」の地位を追われてしまった。という事実がある。あの頃「FUELで状況はよくなるはずだよ！」という風な事を言って、紹介を書いたりして安易に勧めていた人達は、自分も含めて戦犯として裁かれなきゃいかんね。

そういう前例を見ると、Jetpackも、今は威勢のいいことを言っていても、これから先Firefoxの仕様が変わった時に、「JetpackのライブラリのAPIを維持してFirefoxの仕様変更を頑張って吸収する」方向ではなく「JetpackのライブラリのAPIを変えてFirefoxの仕様変更に合わせる」方向に流れてしまうんじゃないのか、「XULやXPCOMといったコロコロ変わる厄介なAPIの上に、Jetpackというこれまたコロコロ変わる新しい厄介なAPIが加わっただけ」になってしまうんじゃないだろうか、と僕は思ってしまうんだ。それじゃあただの第2のFUELだ。

そこで頑張って自分で貢献するんだよ、って言われても、そもそも前述の2の所の開発で悩まされる事から解放されるためのJetpackのはずなのに……って思うわけですよ。

APIが窮屈

また、Jetpack SDKの提供するAPIをキモく感じてしまった、というのもある。APIで提供される機能がどうこう以前に、API越しでしかFirefoxに触れないっていうことがストレスになった。

例えばタブのコンテンツ領域になってるフレームの生に近いAPIには、今までだったらgBrowser.mTabContainer.childNodes[n].linkedBrowser.docShellでアクセスできた。べつにフツーにフツーのアドオンを作るだけだったらそんなとこ触る必要ないけど、いざというときにはそういう低レベルのAPIから裏口を叩けば何とかなるという、なんていうんだろ、安心感？　みたいな？　そういうのがあった。

しかしJetpackではこれが隠蔽される。APIで用意された範囲の機能にしかアクセスできない。ということは、やりたいことができそうに無かった時、今までよりもずっと手前の時点で諦めなきゃいけないんじゃないかって気がして、今すぐそれをやりたいかどうか以前に、もう、それができなくなるってだけで息苦しくて窮屈で「うああああ嫌だ嫌だ嫌だ」となってしまう。

まだJetpackがrebootされるよりも前の頃、生のXUL要素に触れるrawというプロパティがあった事について、僕はそれを激しく非難した。そんなのがあったら将来的なAPIの互換性を保てなくなってしまうじゃないか、と。その認識は今でも変わっていない。しかし自分がいざ当事者になってみて初めて、その窮屈さ不自由さを身に染みて実感した。（僕がChromeの拡張機能に手を出そうとしなかったのは、これを本能的に避けていたからなのかもしれない。）

Web標準から離れていく？

そもそも自分がMozillaに肩入れしてるのは何でだったのか。よく考えてみるまでもなく何度も言ってるけど、プロダクトそのものがW3CのWeb標準の技術に基づいているから、そしてそれらの技術にちゃんと対応してたから、というのが一番最初にあった理由なんだよね。

「W3CのDOM？　XML？　CSS3？　そんなの全然Webで使えないじゃん、IEで使えない物に意味なんてないよ。」
「W3Cの仕様なんて、現実見てない頭でっかちの奴らが決めたものだろ？　名前がやたら長ったらしい（例：document.getElementById(id)はIEのDOM0だとdocument.all.idに相当）し、キモすぎる。」
「デファクトスタンダード（事実上の標準仕様）こそがすべてだよ。デジュールスタンダード（標準はこれです、という形で作られた標準仕様）なんかに意味はないよ。」
そんなWeb標準冬の時代に、CSS2のポジショニングにも疑似要素にも疑似クラスにもかなりのレベルで対応してて、W3Cの仕様書にある通りの書き方でちゃんとレンダリングしてくれるGeckoは、実に素晴らしいものだと本気で思ったし、ブラウザのUI自体すらもW3Cの仕様通りのWeb標準技術をベースにして作られてると知った時にはもう、泣いて喜ぶ勢いでしたよ。

「ああ、世間であんなに冷遇されてるWeb標準が、ここにはちゃんと息づいてる！！」それが僕のMozillaとの関わりの始まりだった。僕にとってMozillaは、Web標準の象徴だった。W3C信者だった僕にとっては、魅上照ばりに「あなたが神か」てなもんでした。

でも気がついたら、RDFを使う部分はどんどん減らされて、MNGサポートもドロップして代わりにAPNGなんてMozilla独自の画像形式になってしまって、SOAPサポートもドロップして（だったよね？確か。）……そんな感じで「世間ではまだ広く使われてないけどWeb標準の技術に対応してる、だからまだマイナーなWeb標準の技術でも実際に動くアプリケーションを僕でも作って実証できる、Web標準はちゃんと役に立つんだって事を証明できる」と思ってた余地がどんどん減っていって。その一方で、「次のスタンダードはWebKitだ！」と「標準」のお株を奪われて、新しいWeb標準への準拠度で後れを取って、性能面でも引き離されちゃって。

さらにはユーザの側からも開発者の側からも「XULなんてクソ重い無駄なもんなくしちまえ」みたいな声が出てきて。Jetpackって、XPCOMが廃止されてもXULが廃止されても拡張機能向けのAPIの互換性を保てるようにっていうことで出てきたんだったと記憶してるんですけど、ということは、Jetpackが最高にうまくいったらXULもなくなっちゃうって事ですか？　CSS3で外観を変えたり、XPathでUI要素をゴソッと収集したり、そういうのがなくなっちゃうって事ですか？　みたいな。

切ないね……

だいたいさあ、安定したAPIになる保証もないのにオレオレAPIをどんどん重ねてくっていうのが気にくわんのですよ！！　document.allとかlayersとか混沌として色々分断されてた世の中が、せっかくWeb標準のおかげで見通し良くなってまとまってきたと思ったのに！　prototype.jsとかDojoとかMochikitとかjQueryとかYUIとかExtJSとかオレオレな実装が乱立してきてさあ！！　なんなの！！　もう！！！　Web標準だけあればいいじゃん！！！！　そんでもってUI用の言語として開発されたXULでいいじゃん！！！！　なんでHTMLで無理矢理UI作ろうとするんだよ！！！！！　XMLっていう仕組みがあるんだから、それに則った上で用途に適した道具を選ぼうよ！！！！！　そういう事を考えもしないで、見慣れてるからってだけでdivだのspanだのでオレオレUI作ってさあ！！！！！！！！　なんなんだよそれ！！！！！！！！！

はあ……

しかし光明もある

そんな感じで考えれば考えるほどダウンな気持ちになってきたんだけど、さらに調査を進めていく中で、Jetpackの今のAPIの基礎になる部分はCommonJSの仕様に則る形で開発されているという事を知って、「おおっ！？」と思った。

僕がJetpackの前のAPIでとても「うへぇ」ってなってたのは、ライブラリの読み込み方の部分だった。Greasemonkey等で広く使われてたDocComment風の記法じゃない、jetpack.future.XXXとかのアクセス方法、あれがすごい気持ち悪かった。なんでここでまた無駄にオレオレルールを増やすかなあ！？　と思って色々萎えた記憶がある。

でも今のJetpackでは、ライブラリを呼ぶ時はrequre('ライブラリ名')、ライブラリを作る時はexports.プロパティ名に値や関数をセットするというルールになっていた。これは、サーバサイドでJavaScriptを実行するnode.js等の環境でAPIを共通化しようということで議論が進められている、CommonJSのルールだ（そうだ）。これは、Webの開発者にとって親しみやすい物にしよう、独自拡張オレオレルールでなんでもやるんじゃなくて足並み合わせる所はきちんと合わせていこうという意図の顕れだと、僕には思えた。MNGとAPNGの件では見損なったけど、この件では見直した。

あと、Mozillaの中の構造とか全然知らない人にペアプログラミング形式で「ちょっとしたアドオンを作ってみましょうか」とJetpackベースでのやり方を指南（？）しようとして、ああやっぱりこのアプローチは間違ってないんだなということを実感した。

• 使えるAPIの数が限られてるから、「どのやり方でやるべきか、どの方法を教えるべきか」で迷わないで、「この目的を達成するならこのAPIでやろう（っていうかそれ以外の方法がない）」とサクサク進める。
• 実際に書くコードの量は少なくなるから、見通しが良くなる。
• SDKにFirefoxのテスト実行モードがあるから、トライ＆エラーで開発できる。「あれー、ダメだった。なんでだ？　じゃあここをこうしてみるか」ですぐやり直せるし、「よし、まずはここまでできた。OK？　じゃあ次のステップに進もう」という風にちょっとずつ教えられる。
• 今回は使わなかったけど、自動テストのための仕組みもSDKに含まれてる。

初学者とかWebデベロッパーとか、Mozillaヲタじゃなくてもアドオンを作りやすくなってると思う。Pythonをインストールしなきゃならんとかコマンドラインでやらなきゃならんとかの点は、これからどうにでもなることだ。今まで取りこぼされていた人達をすくい上げる基礎になる物が、今のJetpackには確かに揃いつつあるのだと思う。今までの「動的に適用されるパッチ」でしかなかったアドオンの路線のままでは絶対になし得なかったことが、Jetpackでなら確かに可能になるのだと思う。

どう見ても老害です

しかしまあ、改めて考えると、僕がやっていた事も先人から見れば十分「なんだあの窮屈な世界は」てなもんなんだろうね。C++の生の実装に触ることなくその上に幾層にも積み上げられた物の上で僕はずっと遊んできたわけだけれども、その世界での制限には目を向けることもなく、全てを所与の物として受け入れてありがたがっていた。そんな僕が、GreasemonkeyやGoogle Chromeの拡張機能やJetpackに対して「なんだあの窮屈な世界は」なんて言うのはまったく笑い話でしかないのだろう。

下の層に目を向ければ、ハードウェア寄りのレイヤではそれこそ鬼のような非互換の嵐で、それを吸収するためのOSのレイヤがあって。上の層に目を向ければ、プラットフォームどころかデバイスの違いすら吸収するWebがあって。その中間層であるところのブラウザを作る段階で、プラットフォーム間の互換性がどうだのバージョン間の互換性がああだの言ってるのは、ちゃんちゃらおかしい。

そういう中途半端な所に（Web製作の世界から）逃げ延びて住み着いていた僕が、上の層から僕の居場所をなくそうと迫ってくるJetpackに恐怖を抱いて、拒絶反応を示していた。版図を広げようとしている若手の前で竹槍を振り回してた。ああ、実に老害だ……

それに、Web標準Web標準とわめいてみても、WebKitが中心になってしまった今のWebじゃあGeckoの方がはるかにオレオレ実装なはぐれ者だしおまけに10年以上前のコードを引きずってる骨董品だし、XULもXBLもXMLという仕組みの上に成り立っているとはいってもそれ自体はみんなの合意が得られた標準仕様じゃないわけだし。「神！私は仰せの通りに！」と崇めてるうちに、僕はWeb標準とMozillaのオレオレの見境が付かなくなってたのか……

まとめ

とりとめがないままにモヤモヤした物を吐き出してきたわけだけれども、それと平行してJetpackの内側を覗いてみたりして、光明も見えたりして、自分の勘違いも見えてきて、いくらかスッキリした気はする。

あと、最近は人生っていいものかもしれないなあと思うようになってきたので、老害と言われようともそれでも往生際悪く地味に追いすがっていこうと思ってます。オメガギーク！

SubversionからGitに移行した - Nov 01, 2010

アドオンの開発にはずっと須藤さんに用意してもらったSubversionのリポジトリを使ってたんだけど、

• インターネットに繋がらない状態でコミットできないのが辛い
• 他の人からの変更を受け取りづらい（そんな事があればの話なんだけど）

と思っていて、Git（あるいは他の分散型バージョン管理システム）ならそれが解消されると期待してて、でもずっと移行できていなかった。

• コマンドライン操作が嫌いなので、Subversionを使うのにWindowsではTortoiseSVNを、LinuxではRabbitVCS（旧称：NautilusSVN）を使ってるけど、GitではWindowsにはTortoiseGitがあってもLinuxでは相当する物が無いみたい。
• バージョン管理システムを移行するとそれまでのコミットの履歴も全部なくなっちゃうんじゃないの？
• git-svnっていうのを使うといいと聞いたけど、試しても空のディレクトリしかできないんですけど……

というのがその理由だった。でも

• git-svnは時々動作がうまくいかない事があるみたいで、Windows上のmsysgitが特に高確率で失敗するだけで、VirtualPC上のUbuntu 10.04LTSのgit-svnだとそれほどでもなかった。
  • それで成功したケースだとコミット履歴が完全に引き継がれてた。なんだ、ちゃんと動けばちゃんとやってくれるんじゃん！！！
• 最近、システムモニターの開発でGitをずっと使ってたから、まあLinux上ではコマンドラインでも別にいいかな……という気がしてきた。

という事で、思い切って移行してみる事にしました。具体的な手順はSourceForge.JP のプロジェクトを Subversion から Git へ移行するに従いました。

SubversionとGit

大まかに言うとこういう事だと僕は理解してる。

• Subversionでは、中央に1つのリポジトリがあって、それを各人がチェックアウトしてワーキングコピーを作り、ワーキングコピーに対して行った変更をリポジトリにコミットする、という形で「バージョンの管理」と「成果の共有」を実現する。
• Gitでは、リポジトリのコピーを誰でも簡単に手元に作る事ができて（Gitではこれをcloneと言う）、Subversionでワーキングコピーからリポジトリに変更点をコミットするのと同じように、Gitではリポジトリとリポジトリの間で変更点をコミットできる（Gitではこれをpushとかpullとか言う）。
  • どれか1つのリポジトリを「中央のリポジトリ」として運用すれば、Subversionでのバージョン管理と同じような運用もできる。
  • 手元にできるのは「履歴の情報を持たないワーキングコピー」ではなく「元のリポジトリを複製したリポジトリそのもの」なので、インターネットに繋がってない状態でもローカルのリポジトリに対してコミットできる。
  • Subversionではtrunkと呼ばれていた物は、Gitではmasterと呼ばれる。
• git-svnは、以下のような事をする。
  • Subversionのリポジトリのコミット履歴を全部辿る。
  • ローカルに新しいGitリポジトリを作って、Subversionのコミット履歴に対応するコミットを順番にそのGitリポジトリにコミットする。
  • なので、git-svnでGitリポジトリ化したSubversionリポジトリは、元のリポジトリの変更履歴を完全に引き継いだ物になる。

やってみる

ツリー型タブのSubversionリポジトリをgithub上の同名のリポジトリに移行する手順を振り返ってみる。

1. Subversionのリポジトリをgit-svnでGitリポジトリに変換する。

   $ git svn clone --prefix svn/ -s https://www.cozmixng.org/repos/piro/treestyletab

   これでローカルにtreestyletabという名前のディレクトリができて、これがGitリポジトリになってる。コミットを1件1件取り込むので、コミット数が多いとメチャメチャ時間がかかるけど、黙って待つ。たまに失敗するので、そういう時はできたゴミディレクトリを消してもう一度やり直す。
2. githubに「treestyletab」という名前でリポジトリを作る。（分かりやすくするためにSubversionの物と同じ名前にするといい。リポジトリ名は後でgithub上で好きなように変更できるので。）これで、読み書き両用のURLとして「git@github.com:piroor/treestyletab.git」みたいなのが使えるようになる。
3. ローカルにできたtreestyletabのGitリポジトリの「元」として、githubのリポジトリを登録する。

   $ git remote add origin git@github.com:piroor/treestyletab.git

   これによって、「このリポジトリはgithubのリポジトリをcloneした物ですよ」「このリポジトリに行われた変更を元のリポジトリにpushする時は、githubにpushしますよ」ということになる。
4. pushする。

   $ git push origin master

   これで、Subversionのリポジトリから持ってきたコミット履歴が全部github上のリポジトリに反映される。
5. Subversionのtagsの内容をGitのtagに変換する。Subversionでtags以下に作ったタグはブランチとして取り込まれているので、これをGitのタグにしてやる。

   $ git branch -r

   これでブランチの一覧を見れるので、

   $ git checkout svn/tags/0.10.2010102501

   という風にしてブランチを切り替えて

   $ git tag 0.10.2010102501

   でタグを打って

   $ git push --tags origin

   でタグの情報をgithubのリポジトリにpushする。タグの数だけこの操作を繰り返す。
6. Subversionのbranchesにブランチがある場合、Gitのbranchに変換する。Gitだとローカルにあるブランチをgit push origin ローカルリポジトリのブランチ名:リモートリポジトリのブランチ名でリモートリポジトリにpushできるんだけど、git−svnでcloneしたローカルリポジトリにあるブランチはそのままだとpushできない（不可視のブランチになってる？）ようなので、

   $ git checkout svn/my-branch

   でブランチを切り替えて

   $ git branch my-branch

   で普通のブランチとして切り直して

   $ git push origin my-branch:my-branch

   でgithubにpushする。

自分はアドオンの数自体20個以上あるし、それぞれアホみたいに何度もリリースしててタグの数がハンパないことになってるので、全部手動でやることを考えたら気が遠くなりました。なのでこういうスクリプトをRubyで書いてみました。

#!/usr/bin/ruby

SVN_REPOSITORY_PATH = "https://www.cozmixng.org/repos/piro/<%= src_project_name %>"
GIT_REPOSITORY_PATH = "git@github.com:piroor/<%= dest_project_name %>.git"

$LOAD_PATH.unshift(File.dirname(__FILE__))

require "fileutils"
require "erb"
require "shellwords"

def main
  ARGV.each do |arg|
    p "process #{arg}"
    args = arg.split(":")
    src_project_name = args[0]
    dest_project_name = args.size > 1 ? args[1] : args[0]
    svn_to_git(src_project_name, dest_project_name)
  end
end

def svn_to_git(src_project_name, dest_project_name)
  p "svn:#{src_project_name}, git:#{dest_project_name}"
  clone(src_project_name)
  push(src_project_name, dest_project_name)
  push_branches_and_tags(src_project_name)
rescue Exception
  p $!
end

def clone(src_project_name)
  result = run("git", "svn", "clone",
               "--prefix", "svn/",
               "-s", ERB.new(SVN_REPOSITORY_PATH).result(binding).chomp)
    p result.to_s
  raise Exception.new("clone of #{src_project_name}, #{result.to_s}") unless result.to_s.include?("Checked out HEAD:")
end

def push(src_project_name, dest_project_name)
  FileUtils.cd(src_project_name) do
    result = run("git", "remote", "add",
                 "origin", ERB.new(GIT_REPOSITORY_PATH).result(binding).chomp)
    p result.to_s
    result = run("git", "push", "origin", "master")
    p result.to_s
    raise Exception.new("push of #{src_project_name}, #{result.to_s}") unless result.to_s.include?("master -> master")
  end
end

def push_branches_and_tags(src_project_name)
  FileUtils.cd(src_project_name) do
    branches = run("git", "branch", "-r")
    branches = branches.to_s.split("\n")
    branches.each do |branch|
      next unless branch.include?("svn/")
      branch.strip!

      name = branch.split("svn/")[1]
      next if name == "trunk"

      if name.include?("tags/")
        tag = branch.split("tags/")[1]
        p run("git", "checkout", branch)
        p run("git", "tag", tag)
        p run("git", "push", "--tags", "origin")
      else
        p run("git", "checkout", branch)
        p run("git", "branch", name)
        p run("git", "push", "origin", "#{name}:#{name}")
      end
    end
  end
end

def run(*args)
  command_line = Shellwords.shelljoin(args)
  result = `#{command_line} 2>&1`
  result
end

main

ファイル名は svn-to-git.rb として、

$ ./svn-to-git.rb treestyletab

とやると、ここまでの手順のうちgithubのサイト上でリポジトリを作る所以外を全部自動でやってくれるという物です（ということは、スクリプトの実行前にあらかじめgithubのサイト上でリポジトリを作っておかないといけない）。これでなんとか全部のリポジトリをgithubに持ってくることができました。XUL/Migemoの辞書をSQLiteにしてみようとかそういうブランチを切ってた物が取り込めてなかったり、svn:externalsで参照してた物が入ってなかったり、Subversionに突っ込んでから1回もコミットしてないプロジェクトをまだgithubに持ってきてなかったり（必要あるの？　無いよね？）という課題は残っていますが。→ブランチの取り込み方が分かったので追記しました。→svn:externalsの移行は諦めてsubmoduleにすることにしました。TortoiseGitでメニューから「Submodule Add」を選んでリポジトリにgit@github.com:piroor/makexpi.gitを、パスにbuildscriptを指定する、という手順でだいたい同じような結果になるみたい。更新の時はTortoiseGitだと「Git Sync」から「Submodule Sync」しないといけないようだ。コマンドラインなら一発で更新できるようなんだけど……

今後はgit-svn駆け込み寺あたりを熟読して頑張っていきたいと思っております。あと、今後具体的にコードを提供してくれるような人がもしいれば、githubの方にpull requestっていうんですか？するようにしてもらえたら幸いです。

……というまとめエントリを書こうとしてもうちょっと調べ直してたら、git-svnでタグが自動で取り込まれないとかの問題を解消するラッパーのsvn2gitという物があるということを今更知りました。ギャフン！！！！！

……さらに後から気がついたけど、HTTPでアクセスできる公開のSubversionリポジトリをgithubに移行するだけならtagやbranchの変換も含めてgithubのWebインターフェース上の機能だけでサクッとできてしまうことが分かりました。ギャフンギャフン！！！！！！！！！　手順は以下の通りです。

1. githubで新しいリポジトリを作る。
2. 空のリポジトリができたら、最初に表示されてる説明の下の方にある「Subversionのリポジトリを取り込みたい?　ここをクリック」というリンク（日本語のUIにしてる場合。英語でも多分似たような文言があると思う。）を辿る。
3. インポート元のSubversionリポジトリのURLを入力する。
5. githubのユーザ名（ 「piroor <piro.outsider.reflex@gmail.com>」のような、githubのユーザ名と登録済みのメールアドレスの組み合わせ）を作者として入力する。
6. しばらく待つ。

最初githubのUIを英語で使ってたのと、下までスクロールしてなかったから気がついてなかった。なんということでしょう。丸1日以上を無駄にしてしまいました。

Ubuntu 10.04LTSからUbuntu 10.10へのアップグレードとATOK X3 - Oct 26, 2010

仕事でRails 3.0とかRuby 1.9.2とかを使わないといけなくなったんだけど、Rails 3.0と併せて使うとお薦めと紹介されていたBundlerというやつをgemでインストールしようとしたらRubyGemsのバージョンが古くてダメだと言われてしまい、Ubuntu 10.10にアップグレードしたらいけると教えてもらったので、早速上げてみた。（10.04はLong Time Supportだからアップグレードの通知が来てなくて、10.10がリリースされていたことに気付いてなかった。）

• 例によってUbuntu Japanese Wikiのアップグレード手順解説の通りに操作したらアップグレードできた。
• Ubuntu 9.10→Ubuntu 10.04LTSの時は沢山エラーが出たけど今回は特にそういうことはなかった。
• DropboxのクライアントもWineにインストールしたLimeChat 2もそのまま動いてくれた。
• 既定のブラウザがFirefoxじゃなく自分でインストールしてたGoogle Chromeになっていたので、Firefoxの設定から既定のブラウザに設定し直す必要があった。
• 多分Ubuntu 10.04LTSの頃からだと思うけど、Ubuntuマシン上のフォルダをSambaで共有しててそのフォルダの中に別のフォルダへのシンボリックリンクがある時に、別のマシンからその共有フォルダを覗いてシンボリックリンクを辿ろうとすると、権限がないから開けないみたいな事を言われるようになってた。Ubuntu 10.10でも変わっていなかった。
  • 改めて調べてみたら、これはSamba 3.4.6からセキュリティ向上のためにシンボリックリンクがデフォルトで無効化されるようになっていたせいだった。
  • /etc/samba/smb.confの[global]セクションに

    unix extensions = no
    wide links = yes

    の2行を足してsudo server smbd restartとしたら、シンボリックリンクを辿れるようになった（でもセキュリティ的にまずいのか？）
• また例によってLet’s noteのくるくるスクロールができなくなってた。
  • Ubuntu 10.04LTSにアップグレードした時は設定ファイルを追加してやる必要があったけど、そのファイルは已然として存在している。gsynapticsもインストールされている。なのにシステム→設定→マウス の所を見ても設定がない！！
  • 検索したらgpointing-device-settingsというのを使うとできるとあったんだけど、パッケージは既にインストール済みになってる……と思ってよく読んだら、設定には システム→設定→Pointing devices を使うと書いてあった。こっちに移動してたのか。アイコンがタッチパッドじゃなくてマウスだったし、そもそもラベル文字列が翻訳されてなかったから、完全に見落としてた。
  • ここで「回転スクロールを有効にする」にチェックを入れたらまたくるくるスクロールできるようになった。

が、日本語入力の所で問題が起こった。

ATOK X3をUbuntu 10.10で動かした時に起こった問題とその対策

僕は以前からUbuntuでATOK X3を使ってた。アップグレード後も、特にインストールし直さなくてもATOKによる日本語入力はできるようだったが、どうも動作が怪しい。

• gedit等のアプリケーションで日本語を入力すると、確定した瞬間にメニューバーにフォーカスが行ってしまう。（Altキーが入力されてしまうのか何なのか分からないけど、「ファイル」メニューが開かれてしまって入力中の内容が失われる。）
• 変換候補のポップアップが、アプリケーションのウィンドウの左下に張り付いてしまう。
• 最初に導入した時にiiimf-properties（iiim-properties）で設定した「ウィンドウ左下のツールチップ？を表示しない設定」＋「変換キーでIMEのON/OFFをトグル」が効かなくなったみたい。
  • さらに悪いことに、ウィンドウ左下に出てくるツールチップが何故か真っ黒になる。

9.10→10.04LTSの時の手順でATOKを再インストールしてみよう……とする前に、念のため「Ubuntu 10.10 ATOK」で検索してみたら、Ubuntu日本語フォーラム / 10.10にATOKをインストールというのが出てきた。これによると、

• Ubuntu 10.10ではdpkgの仕様が変更されて、そのままではATOK X3のdebパッケージをインストールできない。
• この点に対処したdebパッケージがJustSystemのサポートサイトで既に公開されている。このページに、過去のパッチも適用した上でインストールする手順の解説も掲載されている。

という事だったので、早速やってみた。しかし、上記の「動作が怪しい」点は変化が無かった。

症状をキーワードに検索してみたけど類似の例が見つからなかったのでお手上げということでtwitterでぼやいたら、いくやさんが情報を示して下さった。紹介していただいたエントリによると、「immoduleの設定がおかしい」のが原因……らしい。

いくやさんのエントリには /usr/lib/gtk-2.0/2.10.0/immodule-files.d/libgtk2.0-0.immodules を編集するように書いてあるけど、何故か僕の環境だとこの位置にファイルが無くて /usr/lib/gtk-2.0/2.10.0/gtk.immodules にそれらしきファイルがあった。sudo vi /usr/lib/gtk-2.0/2.10.0/gtk.immodulesで開いて、こちらはいくやさんのエントリと同じように

"/usr/lib/gtk-2.0/immodules/im-iiim.so"
"iiim" "Internet/Intranet Input Method" "iiimgcf" "/usr/share/locale" ""

と追記し（ /usr/lib/gtk-2.0/immodules/im-iiim.so の位置にファイルがあることはちゃんと確認した）、ログアウトしてログインし直したら、「入力を確定するとメニューバーにフォーカスしてしまう」「変換候補のポップアップがウィンドウの左下に張り付いてしまう」問題は解消された。

ただ、上記のリンク先にある修正版のATOK（用のIIIMF）のパッチにはiiimf-properties（iiim-properties）のパッケージは含まれていなくて、tarからインストールするのはさすがに怖かったので、「ウィンドウ左下のツールチップ？を表示しない設定」＋「変換キーでIMEのON/OFFをトグル」は諦めるしかないようだった。（「ウィンドウ左下のツールチップ？を表示しない設定」の方だけは、JustSystemのサポートサイトで公開されているIIIMFステータス非表示ツールというのを使うことでどうにかできるけど。）

ibus-mozc

ATOKの使用をあきらめかけた時に、せっかくだからとibus-mozc（Google日本語入力のエンジンのオープンソース版）を試してみることにした。

• アップグレードで使ってるからか、10.10になった段階ではibus-mozcは入っていなかった。
• 日本語環境セットアップ・ヘルパを起動したらibus-mozcの項目があったので、そこにチェックを入れたらインストールできた。
• 再起動してもどうやって有効にすればいいのか分からなかったけど、システム→システム管理→言語サポート で「キーボード入力に使うIMシステム」をiiimfからibusに切り替えたら、ibus-mozcが有効になった（ログアウト→ログイン してからだったかもしれない）。

ibusの設定は システム→設定→キーボード・インプットメソッド で変更できる。こちらは変換キーだけでのIMEのON/OFFトグルも簡単に設定できた。また、言語パネルを表示させた状態であればibus-mozcの設定を変更できて、ここからキーバインドをATOK風に変えることができた。

とりあえずちょっと触った感じでは日常的な利用には支障なさそうだと思った。ただ、僕はATOKに電子辞書を入れて変換候補の同音異義語の使い分けに使ってて、mozcにはそれがないようだったので、ATOKが使えるうちはATOKを使いたいなあと思った。

XBLの使用を避けたがるのは何故か - Oct 22, 2010

僕がアドオン開発でXBLの利用を避けることが多いのは、XBLを使ってると、他のアドオンやサードパーティ製のテーマと衝突した時ににっちもさっちもいかなくなってしまうことが多かった（という印象が強い）り、複数のバージョンのFirefoxに対応しようと思うとドツボにハマったりしたからだ。

例えばツリー型タブのようなアドオンを作る時に、「タブのDOMノードに、子タブの一覧を取得するためのchildTabsというプロパティを追加したいな」と思ったとする。思ったっていうか、タブブラウザ拡張でかつてツリー表示機能を実装した時には実際そうしてたんだけど。それをXBLでやるとこんな風になるだろう。

<binding id="tabbrowser-tab"
         extends="chrome://browser/content/tabbrowser.xml#tabbrowser-tab">
  <implementation>
    <property name="childTabs" readonly="true">
      <getter><![CDATA[
        ...
      ]]></getter>
    </property>
  </implementation>
</binding>

同時に、こういうCSSも書くことになる。

.tabbrowser-tab {
  -moz-binding: url("mybinding.xml#tabbrowser-tab");
}

XBLではextendsで他のバインディング定義を継承することができる。chrome://browser/content/tabbrowser.xml というのは、Firefox 3.6でタブブラウズ関係の機能を定義してるバインディングなので、これで「Firefox本来のタブの機能に加えて新しい機能を定義する」という事が簡単にできる。

が、これは同時に欠点でもある。XULの機能のかなりの部分はXBLで定義されているので、extendsを書き忘れるとマトモに動かなくなってしまうことが結構ある。だから、独自のバインディングを適用する時は、適用先の要素に既にバインディングが適用されているかどうかを調べて、現在適用されているバインディングのURIを独自のバインディングのextendsに書いておかないといけない。

そして、「元々適用されているバインディングのURI」は簡単には同定できない。Firefoxのバージョンによっても変わるし、WindowsかMac OS Xかによっても変わるし、サードパーティ製のテーマでバインディングが上書きされているかもしれないし、アドオンがバインディングを適用しているかもしれない。ひょっとしたらユーザがuserChrome.cssでバインディングの指定を変えているかもしれない。継承の順番は、自分のXBL→tabbrowser.xml→tabbox.xml→general.xml かもしれないし、自分のXBL→テーマのXBL→tabbrowser.xml→tabbox.xml→general.xml かもしれないし、自分のXBL→他のアドオンのXBL→テーマのXBL→tabbrowser.xml→tabbox.xml→general.xml かもしれない。「こう書いておけば大丈夫」という単一の継承元のURIは存在しないのだ。

さらにタチが悪いことに、XBLの定義ファイルの中に書かれたextendsは動的には書き換えられない。現在適用されているバインディングのURIをgetComputedStyle()で取得しても、それを後からXBLのextendsに指定するという事はできない。（ひょっとしたらdata: URLを使えばできるかもしれないけど、僕はそんなのやりたくないし見たくもない……）

だから、XBLを使うアドオン同士ではバインディングの優先権の取り合いになる。CSSは後から読み込まれたもの・セレクタの指定の詳細度が高いものほど優先的に適用されるから、後からインストールしたアドオンのせいでそれまで使っていたアドオンのバインディングが適用されなくなる、なんてこともしょっちゅうあった。タブブラウザのタブ要素なんて、激戦区中の激戦区と言っていいだろう。

そう考えると、ほんの2～3個のプロパティだとかメソッドだとかを追加するためだけにこれだけのリスクを負うのは到底割に合わない。それだったら、要素のDOMノードに直接プロパティを加えるのを諦めて、コントローラやサービスになるようなクラスを作ってそっちに必要な処理を集約させる方がずっと楽だ。（だからツリー型タブでは、前述の例のようなバインディングを使う代わりに、gBrowser.treeStyleTab.getChildTabs(aTab)で子タブの配列を得るように設計した。）

というのが、僕の出した結論だった。

そういう話なので、僕は、「何が何でもXBLを使うな」とまで言うつもりはない。前述のようなバインディングの適用の優先権争いが起こらない場所、例えば独自のXULRunnerアプリケーションだったり、独自のサイドバーパネルだったり……という部分でなら、XBLはいくらでも使っていいと思ってる。

例えば、派生の要素型がたくさんあるようなケースではXBLの継承が威力を発揮する。会社で一時期やってたXULRunnerアプリのプロジェクトでは、継承を多用することで結構工数を削減できた（と思う）。また、anonymous contentsの追加は（特に、既に存在しているDOMツリーのノードの親子関係の間に安全に割り込むような物は）、XBLでなければできないことだ。

ただ、XBLは、1つのウィンドウの中にいろんな人が好き勝手に書いたコードが同居する「Firefoxのアドオン」という分野とは、すこぶる相性が悪い。JavaScriptで書く物でもCSSで書く物でも「最初にやった者勝ち」な所はどこかしらあるけれども、XBLの場合はそれが顕著だし、「後から来た者が上手く隙間に入り込む」という風な余地が全然無い。だから僕は、XBLをなるべく避ける形でコードを書くように努めてるんだな。

未だにXBLを使うことを避けられない場面 - Oct 22, 2010

XBLはアドオン同士の衝突の原因になりやすい。だからXBLはあまり使わないように僕はしてる。

XBLを使うと、DOMノードにgetterやsetterになってるプロパティを定義したり、独自のメソッドを追加したりできる。でも、それらはJavaScriptのテクニックで代用できないこともない。JavaScriptのレベルで目的を達成するやり方として、僕は最近よく、こんな設計をしてる。

function MyController(aNode) {
  this._node = aNode;
  this.init();
}
MyController.prototype = {
  get property() {
    ...
  },
  set property(aVaule) {
    ...
  },
  method : function() {
    ...
  },
  init : function() {
    this._node.addEventListener('...', this, false);
    ...
  },
  destroy : function() {
    this._node.removeEventListener('...', this, false);
    ...
  },
  handleEvent : function(aEvent) {
    ...
  }
};

var node = document.createElement('box');
node.controller = new MyController(node);

かなりの部分はこういったやり方で目的を達成できると思う。ツリー型タブなんかもこれに近い実装になってる。

ただ、オートコンプリートのテキストボックスの挙動を変えるだとかの、本体で定義されている物を置き換える場面では、たまにこの方法だけでは不十分なことがある。例えば<textbox type="autocomplete" />な要素のmaxDropMarkerRowsや<panel type="autocomplete" />な要素のoverrideValueやなんかはreadonlyなプロパティとしてXBLで定義されてしまっているので、これらが返す値を変えたいと思うと結構厄介な事になる。

XBLを使わないでサクッと済ませようとすると、__defineGetter__()を使う方法がまずは思い浮かぶ。Firefox 3.0以降ではDOMノードに対して__defineGetter__()を使えるので、上記の例のコードのinit()あたりでそれを使ってやるという感じだ。実際、XUL/MigemoではoverrideValueで任意の値を返すためにそうしてる。

でも、この方法はできれば使わない方がいいのかもなと思ってる。そう思ったきっかけは、同じようなことをやるコードの自動テストを書いていた時。setUpとtearDownで毎回ウィンドウを開いたり閉じたりとやってると時間がかかってしょうがないからUxU組み込みのフレームにページを読み込ませて……という風にしてみたら、セキュリティの制限に引っかかってしまった。object.__defineGetter__(name, getter)のobjectとgetterの属してる名前空間が違うと、Illegal valueとか言われてエラーになってしまった。それでTrunkでの__defineGetter__()の実装を見てみたら、この両者のコンパートメントが違う場合はゲッタの登録を拒否するような設計になってた。こういうセキュリティの制限を回避してreadonlyなプロパティの働きを置き換えようと思ったら、どうもやはり、XBLを使うしかないようだ。

そもそもなんでoverrideValueがreadonlyなんだよ、なんで書き換え可能なただのフィールドになってないんだよ、って思って来歴を調べてみたら、nsIAutoCompletePopupインターフェースのoverrideValueは昔のオートコンプリートの実装におけるgetOverrideValue()メソッドがその祖先で、当時のコードには「こいつの働きを変えたかったらXBLでオーバーライドしろ」ってコメントが書いてあった。今のFirefoxのオートコンプリートの実装にはこのコメントがなかったので、なんでreadonlyになってるんだよという不満しか抱きようがなかった。getXXXとなってたメソッドをプロパティの形に置き換えるなら、確かにそれはreadonlyになるだろう。

でもどうせプロパティに変えたんだったらwritableにしたってよかったはず。ほんとに、何でこんな設計にするんだろう……

拡張機能の標準化の話について思うこと - Oct 20, 2010

• Operaがついに拡張を採用--「Firefoxのように重くはならない」 - CNET Japan
• Opera「ブラウザの拡張の仕様を標準化して、使い回せるようにしませんか？」 - CNET Japan
• Opera「ブラウザの拡張の仕様を標準化して、使い回せるようにしませんか？」 - WebStudio

かつてIE6が一番先進的なブラウザだった頃は、ブラウザに機能を加える物といったら、「ツールバー」か「コンテキストメニューの追加項目」くらいしかなかった気がする。そもそも、「ブラウザにツールバーを追加できますよ」だけでもずいぶんすごいことであったような気がする。僕がそれ以外を知らなかっただけかも知れないけど。（具体的に僕が「その頃」の代表的なブラウザとして今思い浮かべているのはIE6とNetscape Communicator 4.xです。）

その頃は、MicrosoftとかNetscapeとかがリリースしてるメジャーなブラウザの使い勝手に不満があっても、プログラミングの知識がないフツーの人は、我慢するか、既にある別のブラウザ（iCabとかOperaとか）を探すかしか無かった。そもそもこの時代、ちょっと前までブラウザは4000円とか9000円とかお金払って「買う物」であったから、基本的には「買った物をそのまま使うか、買わないか」という選択肢しかなかったとも言える。

それでも、腕に覚えのある人なら、コアであるレンダリングエンジンにはIEの物を流用して、それ以外のブラウザのUI自体を頑張って全部作り直すということは可能だったようだ。それで出てきたのがDonutだったりSleipnirだったりLunascapeだったりのいわゆるIEコンポーネントブラウザだった。メジャーなブラウザがリリース計画とか顧客とか組織とか色んな都合で足踏みしている間に、個人の開発者あるいは小規模な開発チームであるが故のフットワークの軽さによって、凡庸なメジャー製品では手に入らなかった「痒い所に手が届く使い勝手の良さ」を提供したことで、それらIEコンポーネントブラウザはパワーユーザの支持を得るに至ったのだろう。

IEを使うのなら、できる「機能拡張」はせいぜいツールバーの追加かコンテキストメニューの機能追加くらい。なぜなら、IEが開発者向けに開いていた「ブラウザの個々に機能を追加できますよ」というポイントが限られていたから。（あるいは、もっと色々できたのかもしれないけど、それくらいしかできないという印象が強かった。）それ以上の物が欲しかったら、そういう機能を提供するIEコンポーネントブラウザに乗り換えるしかない。それが、あの頃に取り得た現実的な選択肢の全てだったのだと思う。

僕にとっては、そういう「暗黒時代」はMozillaとの出会いで終わった。当時はまだMozilla Suite（Seamonkey）がメインラインで、バージョンはM16とか0.6とか言われてた頃だったか。当初はCSS2に一番真っ当に対応してたブラウザだったからという理由で使い始めたけど、使い続ける理由はいつの間にか、「一番痒い所に手が届くから」になっていた。

Ben Goodger氏が当時を振り返って語ったエントリにもあるけれど、Mozillaの設計上の特性からくる「拡張性の高さ」はホントにぶっ飛んでた。

• タブを並べ替えるという機能がMozilla本体には無いのに、拡張機能によって、タブを並べ替えられるようにできた。
• セッションを保存するという機能がMozilla本体には無いのに、拡張機能によって、前回終了時の状態を丸ごと復元したり、1回閉じたタブを開き直したりという事を実現できた。
• 検索ボックスでキー入力が始まったタイミングで自動的に表示されるポップアップから、別の検索エンジンで検索を実行する、なんてことすら実現できた。

Mozilla以前は、
「標準のUIに不満がある？　Googleサジェストが使える検索ボックスが欲しい？　じゃあ、このツールバーを追加して下さい。ほら、このツールバーの中でならもっと快適に過ごせますよ！　Googleサジェストの結果もポップアップされますよ！　まあ、このツールバーの世界から一歩でも外に出ると、また今まで通りの世界に逆戻りですけどね。」
「え、このボタンだけ切り離してウィンドウの下の方に置いておきたい？　そんなことできるわけないでしょ。この素敵な便利機能は、このツールバーの世界から外には持ち出せませないんですよ。」
「え、専用のツールバーなんかいらないから、本来のアドレスバーから色んな検索エンジンでWeb検索できるようにしてくれって？　そりゃ無理ですよ。このツールバーの枠の中の事ならどうとでもできるけど、枠の外は元々作られてた通りにしか動かないんだもの。」
こうだった。ツールバーという細長い箱の中、コンテキストメニューというメニューの中、そういう様式の中でないと何もできなかったっぽかった。

あるいは、こうだった。
「このブラウザに乗り換えたら、こんな便利な機能が使えますよ！」
「え、こっちのブラウザのこの機能が欲しいって？　そんなこと言われても、それは別のソフトだし……正直、そんなもん知らんがな。」
「パソコン盗まれてソースコードが失なわれちゃいました！　もうメンテナンスできません！」

でもMozillaではそうじゃなかった。
「標準のUIに不満がある？　じゃあ、そこをピンポイントで解決しちゃえばいいよ。」
「ボタンはウィンドウの上じゃなくて下の方にあって欲しい？　じゃあそうすればいいよ。ほら、ツールバーのボタンをウィンドウの下に移動できるようになった。」
「アドレスバーから色んな検索エンジンで検索できるようにしたい？　じゃあそうすればいいよ。ほら、GoogleやAmazonの検索結果がアドレスバーの履歴と一緒に表示されるようになった。」
こうだ。実にシンプルだった。「イラッ」と来たまさにその点を、イメージしていた通りに、一番ストレスのない形で解決できる。ツールバーという細長い四角い枠の中であるとか、たった1人の作者の都合であるとかに、囲い込まれなくてよかった。使いたい機能を使いたいように組み合わせて使えた。

具体的な例をもっと挙げると、例えば、ツリー型タブとマルチプルタブハンドラと情報化タブの併用みたいなことができるのかどうか、ってことなんですよ。

タブで開いてるページをツリー表示するポップアップを表示する拡張機能。うん、それは多分便利。
開いてるタブのリストを表示して、任意のアイテムを選択してまとめて操作するポップアップを表示する拡張機能。うん、それも多分便利。
開いてる全てのタブの内容をサムネイルで一覧表示するポップアップを表示する拡張機能。うん、それも多分便利。

で、それを1つにまとめて同時に使えるの？　ツリー表示されていて、気が向いたらそれを複数個選択してまとめて閉じられて、それらには常時サムネイルが表示されてる、というソリューションは誰でも得られるの？　エンドユーザでも？　って事なんですよ。

「ツリー表示してサムネイルも表示して複数選択もできるUI、を提供する1つの拡張機能」があればいい？　「ツリー表示してサムネイルも表示して複数選択もできるUI、を持ったIEコンポーネントブラウザ」があればいい？　そういう物がもしあるのならそれを使うのもいいだろうし、作れる能力があるのなら作って全然いいと思う。でも、そういう物が無かったらどうなのか？　誰も作っていなかったら？　そして自分でそれを作る知識は無いというのなら？　

また、3つの機能を持った物くらいならともかく、要求事項が4つ5つと増えていったらどうなるか。条件が増えれば増えるほど、既製品で要求を完全に満たす物は見つけにくくなるだろう。妥協が増えてくるだろう。その逆に、個々の要求事項を満たす物を集めてきてそれで1つの物として使えるのなら、何も我慢しなくて済む。

だから僕は、Firefoxを捨てられないんだ。「Operaならあれもできるよ、これもできるよ」って言われても、「Chromeなら爆速だよ」って言われても、「ほうほう、ではこのポップアップパネルの下の端にこれこれこういうボタンを置いておきたいんだけど、そういうことはできるのかね？　え、できない？　ああそう……それじゃ日々の『イラッ』はなくならないなあ」と思ってしまうんだな。（だからFirefoxが好きなんですよ、っていうのが全く無いとは言い切れないけど、むしろ、他の物もそうだったらいいのに、でも残念ながらそうじゃないから諦めてFirefox使い続けるしかないのか、って思ってる所も結構ある。）

でも、時代は今また「用意された枠の中でならなんでもできますよ、でもそこからは一歩もはみ出せませんよ」の方向に戻ろうとしている。（いや、あの頃に比べたらずっと洗練されたAPIで、できることの幅も広がっているようなのだけれども。）何故なのか。

理由はたくさんあるようだけど、多分一番重要なのは、「みんな、そんなに自由でなくていい」って事なんだろうね。

頑固で融通の利かない馬鹿で順応性が低い僕にとっては、こうだ。「イラッと来たまさにその部分がピンポイントで解決されてくれないと、我慢ならない。ちょっとでも遠回りしないといけないのは、もう嫌。このツールバーの中でならそんな不満は起こりませんよ、なんて言われても、ツールバーなんていらんし。そんなん興味ない。今目の前にあるコイツがどうにかなってくれないと嫌なの。」でも、普通の人は僕なんかよりもっと頭が柔らかくて順応性が高いから、苦にならないんだろう。「こういうとこが不満で、なんとかして欲しいんだけど。え、代わりにこれを使わないといけないの？　ふーん、まあ、いいけど。」で受け入れてしまえるのだろう。

（というか多分そもそも「こういうとこが不満で」なんて思わなくて、今ある物でだいたい満足できてしまうんだろう。思い入れも無ければ、一日中それと接するわけでもない、1日1回1時間くらいしかブラウザを操作しない、だからそんな深刻な不満を抱きようがないんじゃあないかな。頭が固いとか柔らかいとか以前に。）

（あと、これは、「普通の人」を揶揄する話ではない。そういう人達の方が環境の変化に柔軟に適応できる能力があるって事で、それは人として素晴らしいことだと僕は思う。こうやりたいと決めたやり方以外だとストレスを感じてしまうとか、そういうどうでもいいことにこだわってしまう性根というのは、人として問題があると思う。）

Jetpackがrebootされる前、まだJavaScriptのファイルいっこで完結してた頃、僕は「JetpackはGreasemonkeyやChromeの拡張機能とAPIのレベルで互換性を設けるべきだ」と強く思っていた。なので今回のOperaの「拡張機能を標準化しよう」っていう話に僕は賛成する。既に、ChromeとSafariの間では既にそういう状況になっていると聞いた気がする。大抵の人がそれで満足できる、ツールバーのボタンなり、Webページ内で自動実行されるスクリプトなり、そういう「どのブラウザでも共通して利用できそうな物」には、互換性があっていいと思う。僕だってひょっとしたら、ユーザになるかもしれないし。OperaやSafariをメインで使ってる人が作った拡張機能の恩恵に僕がFirefoxで与れる、そういうことがあり得るかも知れないし。

ただ、Firefoxと同じくらいになんでもできる環境になってくれない限りは、僕自身は軸足をChromeとかその後に出てくる物とかには移せないんじゃないかなー、と思ってる。些細な「イラッ」に目を瞑らずにストレートにそれを解消することができる、という居心地の良さに、僕はあまりにドップリと浸かりきってしまっているので。あまりに「自分を変えなくていい」事に慣れきってしまっているので。