たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
背景。
Web標準に対応しなくて自社独自の技術だけ使い続ける、というのはまあよくある事だから、ことさらMozillaだけをあげつらう事はないと思うんですよ。VMLには対応するけどSVGには対応しないというIE8までの方針であるとか、そういうのはありふれてる。
また、標準仕様はあるけどまだ実装されてない、っていうのもしょうがないと思うんですよ。仕様そのものが曖昧だとか、仕様が膨大すぎて対応できないとか、需要がそもそも無いとか。
釈然としないのは、
これが僕には2枚舌に見えるってこと。
APNGに新たに対応して今後はそっちをメインで使っていくよ、というのはまあ別にいいんですよ。でも、今まで一応対応してたMNGをこれを機にばっさり切り捨てちゃう今まで一度は対応してたことがあったMNGを顧みることもなく別の物をっていうのはどうなん? それじゃあ、なんかの動画形式で動画を埋め込んでて、その形式に対応してなかったらMNGにフォールバックして、みたいな事ができなくなっちゃうじゃんできないまんまじゃん? フォールバック先にはやっぱり、仕様が標準化されてて安心して使える形式を選びたいじゃん? そういう感じでMNGを使ってた使いたい人がいたかもしんないじゃん? 僕はまだ使ってなかったけど、静止画の簡単なアニメーションを公開する事があったら是非そうしたかった。Web標準ってそうやって、地ならしっていうか下支えっていうかそういう所でも活きてくる物だと思ってたんですよ。
いやMozillaの言い分もわかるっちゃ分かるんですよ?
「MozillaはWeb標準を限定的にしか尊重しません。自分たちの組織を維持できなくなるレベルでコミットする事はありません。自己犠牲でWeb標準のために殉死するつもりはさらさら無いです。」というのは真っ当な判断だと思うんですよ。
でも、だったら、「お前はWeb標準を大事にしてない」って他者を非難する資格も無いんじゃないの? 自分の事は棚に上げるの? そういうみっともない事をしないでくれよ。Mozillaだけはそういう事をしてくれるなよ。
っていうモヤモヤがずっとある。
ツリー型タブのGoogle Chrome版は作らないの?という問い合わせを一時期よくもらってたんだけど、とうとう出た。Google Chrome版Tree Style Tab。といっても僕が作ったんじゃなくて、ジェバンニが一晩でやってくれました。的な。
ただ、やはり僕が懸念していたように、形態としては「ツールバーのボタンをクリックしたらポップアップでツリーが出る」という物のようで、実際試してみても違和感があった…… 僕は「ツリーが常に見えている事」がTSTの常用には欠かせないと思っているので、この形の物はやはり辛い。
Side Tabs(起動オプション --enable-vertical-tabs で有効になる)が入っている最近のChromeでなら、あともうちょっと頑張ればなんとかなりそうな気がしなくもない。ページのタイトルの頭にスペースを挿入して擬似的にタブをインデント表示するとか。
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
としてたんだけど、それがうまくいかなかったからムキーッとなってたんだけど、うまくいくようになってよかった。
Developers Conferenceでの発表向けの内容に盛り込めそうにない話を書いていく。
話のテーマを決めるにあたって、とにかく最初は1つJetpack SDKでアドオンを書いてみようと思ったんですよ。
でも、「こう書くと動きますよ」って言われてもなんだか信じられなかったというか、どういう経路でどういう風にしてそのコードが読み込まれるのか分からなくて、スクリプトの書き方次第じゃ他のコードに悪影響を及ぼしたりすることもあるんじゃないのか?(prototoype.jsのObject汚染みたいな感じで)とか、名前空間の衝突は大丈夫なのか? とか、そういうどーでもいい所が気になって気になって、仕組みが分からないまま使うのは怖いと思った。何をやってよくて、何をやったら駄目なのか、というのが分からないのが怖かった。
その境目を見極めたくて、Jetpack自体の成り立ちを探ってみたのですよ。
特に謎だったのが、他のモジュールを読み込むrequire()
。これが一体どこで処理されているのか。main.js(Jetpackでアドオンを作る時の主たる実装になるファイルの固定の名前)もどこかからrequire()
されているのなら、require()
の実装を見たら謎が解けるんじゃないかなーと思った。
exports
やrequire()
はここで定義されている。
EXPORTED_SYMBOLS
を使うやり方)にも対応してるみたい。Components.utils.evalInSandbox()
が呼ばれていることが分かった。ライブラリのモジュールもmain.jsも全部これで実行される。
require("chrome")
の実態が、これ。Jetpackとは、この基本的な仕組みに基づいて、個々のモジュールの名前空間を分け、それらを安全に連携できるようにしたもの。と言える。MozLabでmodule_manager.jsというものが過去に使われていて、それを想起させられた。
module_manager.jsはJavaScriptコードモジュールが無かった頃にJavaScriptそのものの言語仕様を超えた所で高度なモジュール化を行おうとしていたらしく、渡されたモジュールの名前からパスを生成してファイルを読み込んでサンドボックス内で実行してそのグローバルオブジェクトを保持し続けて……ということを普通のJavaScriptの機能とmozIJSSubScriptLoaderでやってた。Jetpackの仕組みはそれのずっとスマートなバージョンなのかなと思った。
今までの開発手法しか知らなくてJetpackがさっぱり分からないという僕みたいな時代後れの人でも、securable-module.jsとcuddlefish.jsを起点にすれば、他のモジュールも無理なく読んでいけるんじゃないだろうか。
僕はJetpackに対していろんな意味で期待していたはずなのに、自分がJetpackでバリバリ開発する姿はいまいち想像できないでいる。Jetpackの話が出始めた頃よりも、JetpackがrebootされてSDKとなってからの方がむしろ、「あれ、なんか僕ってJetpack使ってなさそうなんじゃね?」感が強くなっていっている気がする。Jetpackは僕を幸せにしてくれるのか? くれないのか? それが分からない。
Firefox Developers Conferenceでの発表について「Jetpackからよりディープな世界へのステップアップや、あるいはその逆に、これまでの手法でアドオンを開発していた人達がJetpackにステップアップするには? という風な話題」というオーダーをもらって、ようやっと重い腰を上げてJetpack SDK(とPython)をインストールしてみた。で、とりあえずJetpackの流儀というのを理解しなきゃと思って実際にアドオンを書いてみようとしていきなり挫折して、ドキュメントを読んでみようとしたけどどこから読めばいいのかすら分からなくて頭クラクラで、ヤケクソでJetpack SDKそのもののコードを読んでみたりして、という事をやりながらモヤモヤと考えてた。何故僕はこんなにも、Jetpackに乗り切れていないのか。
Jetpack SDKのドキュメントをちょっと読んで雰囲気を眺めただけでも、僕の今までの知識はまるで役に立たないということはよく分かった。
アドオンを構成するコードは、大雑把に言うと
の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のはずなのに……って思うわけですよ。
また、Jetpack SDKの提供するAPIをキモく感じてしまった、というのもある。APIで提供される機能がどうこう以前に、API越しでしかFirefoxに触れないっていうことがストレスになった。
例えばタブのコンテンツ領域になってるフレームの生に近いAPIには、今までだったらgBrowser.mTabContainer.childNodes[n].linkedBrowser.docShell
でアクセスできた。べつにフツーにフツーのアドオンを作るだけだったらそんなとこ触る必要ないけど、いざというときにはそういう低レベルのAPIから裏口を叩けば何とかなるという、なんていうんだろ、安心感? みたいな? そういうのがあった。
しかしJetpackではこれが隠蔽される。APIで用意された範囲の機能にしかアクセスできない。ということは、やりたいことができそうに無かった時、今までよりもずっと手前の時点で諦めなきゃいけないんじゃないかって気がして、今すぐそれをやりたいかどうか以前に、もう、それができなくなるってだけで息苦しくて窮屈で「うああああ嫌だ嫌だ嫌だ」となってしまう。
まだJetpackがrebootされるよりも前の頃、生のXUL要素に触れるraw
というプロパティがあった事について、僕はそれを激しく非難した。そんなのがあったら将来的なAPIの互換性を保てなくなってしまうじゃないか、と。その認識は今でも変わっていない。しかし自分がいざ当事者になってみて初めて、その窮屈さ不自由さを身に染みて実感した。(僕がChromeの拡張機能に手を出そうとしなかったのは、これを本能的に避けていたからなのかもしれない。)
そもそも自分が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ベースでのやり方を指南(?)しようとして、ああやっぱりこのアプローチは間違ってないんだなということを実感した。
初学者とか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(あるいは他の分散型バージョン管理システム)ならそれが解消されると期待してて、でもずっと移行できていなかった。
というのがその理由だった。でも
という事で、思い切って移行してみる事にしました。具体的な手順はSourceForge.JP のプロジェクトを Subversion から Git へ移行するに従いました。
大まかに言うとこういう事だと僕は理解してる。
ツリー型タブのSubversionリポジトリをgithub上の同名のリポジトリに移行する手順を振り返ってみる。
$ git svn clone --prefix svn/ -s https://www.cozmixng.org/repos/piro/treestyletabこれでローカルにtreestyletabという名前のディレクトリができて、これがGitリポジトリになってる。コミットを1件1件取り込むので、コミット数が多いとメチャメチャ時間がかかるけど、黙って待つ。たまに失敗するので、そういう時はできたゴミディレクトリを消してもう一度やり直す。
$ git remote add origin git@github.com:piroor/treestyletab.gitこれによって、「このリポジトリはgithubのリポジトリをcloneした物ですよ」「このリポジトリに行われた変更を元のリポジトリにpushする時は、githubにpushしますよ」ということになる。
$ git push origin masterこれで、Subversionのリポジトリから持ってきたコミット履歴が全部github上のリポジトリに反映される。
$ git branch -rこれでブランチの一覧を見れるので、
$ git checkout svn/tags/0.10.2010102501という風にしてブランチを切り替えて
$ git tag 0.10.2010102501でタグを打って
$ git push --tags originでタグの情報をgithubのリポジトリに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インターフェース上の機能だけでサクッとできてしまうことが分かりました。ギャフンギャフン!!!!!!!!! 手順は以下の通りです。
最初githubのUIを英語で使ってたのと、下までスクロールしてなかったから気がついてなかった。なんということでしょう。丸1日以上を無駄にしてしまいました。
仕事でRails 3.0とかRuby 1.9.2とかを使わないといけなくなったんだけど、Rails 3.0と併せて使うとお薦めと紹介されていたBundlerというやつをgemでインストールしようとしたらRubyGemsのバージョンが古くてダメだと言われてしまい、Ubuntu 10.10にアップグレードしたらいけると教えてもらったので、早速上げてみた。(10.04はLong Time Supportだからアップグレードの通知が来てなくて、10.10がリリースされていたことに気付いてなかった。)
unix extensions = no wide links = yesの2行を足してsudo server smbd restartとしたら、シンボリックリンクを辿れるようになった(でもセキュリティ的にまずいのか?)
が、日本語入力の所で問題が起こった。
僕は以前からUbuntuでATOK X3を使ってた。アップグレード後も、特にインストールし直さなくてもATOKによる日本語入力はできるようだったが、どうも動作が怪しい。
9.10→10.04LTSの時の手順でATOKを再インストールしてみよう……とする前に、念のため「Ubuntu 10.10 ATOK」で検索してみたら、Ubuntu日本語フォーラム / 10.10にATOKをインストールというのが出てきた。これによると、
という事だったので、早速やってみた。しかし、上記の「動作が怪しい」点は変化が無かった。
症状をキーワードに検索してみたけど類似の例が見つからなかったのでお手上げということで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ステータス非表示ツールというのを使うことでどうにかできるけど。)
ATOKの使用をあきらめかけた時に、せっかくだからとibus-mozc(Google日本語入力のエンジンのオープンソース版)を試してみることにした。
ibusの設定は システム→設定→キーボード・インプットメソッド で変更できる。こちらは変換キーだけでのIMEのON/OFFトグルも簡単に設定できた。また、言語パネルを表示させた状態であればibus-mozcの設定を変更できて、ここからキーバインドをATOK風に変えることができた。
とりあえずちょっと触った感じでは日常的な利用には支障なさそうだと思った。ただ、僕はATOKに電子辞書を入れて変換候補の同音異義語の使い分けに使ってて、mozcにはそれがないようだったので、ATOKが使えるうちはATOKを使いたいなあと思った。
僕がアドオン開発で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はアドオン同士の衝突の原因になりやすい。だから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にしたってよかったはず。ほんとに、何でこんな設計にするんだろう……
かつて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以前は、
「標準の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とかその後に出てくる物とかには移せないんじゃないかなー、と思ってる。些細な「イラッ」に目を瞑らずにストレートにそれを解消することができる、という居心地の良さに、僕はあまりにドップリと浸かりきってしまっているので。あまりに「自分を変えなくていい」事に慣れきってしまっているので。