Sep 03, 2007
第6回拡張機能勉強会
目が覚めたら14時でした。
勉強会本体の感想。
Firemacs作者の山本さんの話を聞いてると、以前の自分を思い出した。XPCOMにどんな機能があるのか知らなかった頃に、知ってる範囲の知識でどうにかして解決しようとあれこれ工夫を試みていた。そういう「工夫」を思い付くかどうか、というのが、もしかしたらある種の「分れ道」なのかもしれないなと思った。
marさんによるXUL preLoaderの話。
- XULオーバーレイでボタンを追加したいのに、その要素にidが指定されていない、という場合、JavaScriptとDOMを使ってXUL要素を生成して埋め込むという方法をとらざるを得ない。
- オーバーレイで読み込むXUL文書を間に一つ増やして、その「間に挟まれた」XUL文書においてid属性をスクリプトで設定してオーバーレイを適用できるようにしてから、改めて、本来オーバーレイで読み込ませたかったXUL文書を
document.loadOverlay()で動的に読み込む。……というのが、preLoaderの発想。
preLoaderのような発想が僕に無かったのは、loadOverlayというメソッドを知らなかった・存在を忘れてたからというのも大きいんだけど、それ以前に、他の拡張機能で同じ方法を使われて異なるIDを指定されてしまったらこのテクニックは破綻してしまう、ということに気づいていたからだ。僕は以前から、拡張機能を作るときは他の拡張機能となるべく衝突しないようにということに気を付けるようにしている（TBEの時はそれで散々叩かれたし）ので、preLoaderのテクニックはあまり推奨しづらい。
ところで、今ふと思ったんだけど。E4X使ったらJavaScriptの中に普通にXUL文書片を書けるから、preLoaderあんまりいらなくね？（ぉ
誕生日を祝ってもらえて、フォクすけは幸せ者ですね。僕もこれくらい愛されてみたいです。どうでもいいですが、ケーキの周りのフィルムについたクリームを舐め取っている様子をばっちり撮られてしまっていました。
Mozilla 24のための各プログラムの番宣ビデオ？の撮影があって、Shibuya.jsのビデオに僕まで出ることになってしまった、というかほとんど僕が喋ってた。幽霊部員なのに。あとで映像見てみても、ほんとキモイなーと思った。また叩かれるんだろうなあ。いやだなあ。
勉強会が終わった後の飲み会などで出た話。
- ノードの検索はDOM3 XPath使うのがオヌヌメ。DOMでやるより20倍以上速い（らしい）。
- Mozillaとかオプソ界隈の人達は、ソースコードをまるごとどかっと公開したらそれで役目は終わった、と考えがちであるが、それはソースコードを見る側の事を何も考えていない。読みやすい量で区切って逐一解説してくれないと、初学者には理解できない。
var a = b+c; // aはbとcの合計という風な、普通は「ダメなコメント」とされるようなコメントをソースコード片に大量に付けてエントリに貼り付ければ、それが何よりの解説になる。
こういう視点は僕にはなかったので、なるほどなと思わされた。公開するソースにつけるコメントは意味のあるものでなければならない、ある1ステートメントの意味を解説するだけのような物は有意なコメントとは言えない、という考え方がすっかり染み着いていたので、過剰なコメント、言うなれば「単語力の時点でまず躓いている人」のためのそれぞれの単語の訳を付けるという発想が、僕には最初から無かった。
……っていうか、そういう風に「丁寧に教える」だけの気力がないんだよね、もう。そういう情熱はW3C信者時代に使い果たしてしまった気がする。その情熱が報われればまだよかったけど、結局W3C信者気取りのガキが個人レベルでちまちまやってたことなんか全然社会的に無意味で、社会に与えた影響はMTが採用したからとか某森川氏が言ってたからとかそういう事の方がずっと大きかった、という事実があるから、僕の中でそういう頑張りに対するモチベーションはなくなってしまった気がする。
- 分かってる人、触ってる時間が長い人ほど、Firefoxの「いいこと」が「当り前」になってしまい、嫌な所ばかりが見えるようになってしまう。だからFirefoxの批判ばかり書いてしまう。でもそれを見ると、初心者は、「上級者がこんなに批判ばっかりしてるんだったらFirefoxはダメなソフトなんだな」と思ってしまう。Piroとかの鬱ブログ書きの人間はもっと自分の発言の社会的な意義を考えて発言するべきである。1けなしたら3褒める、くらいの割合で発言するべきである。
- もっと情報を共有しやすい場で発表するべき。XUL Tipsのようなオレオレコンテンツは開発者から見て全然うれしくない。ブログ（もっと言えば、はてなダイアリー）に書くべき。
これはよく言われることだし、確かにそうある「べき」なのは事実だと思うけど……それを「強制される」のはとてもうれしくない。今の若い人達、熱心な技術者の人達は、「情報」の方が主体で、「自分」はそれに付随する物だと考えられるんだろうと思う。でも僕は、テレホーダイ時代に「ほーむぺーじ」を作って「ぎゃらりー」のページに自作の絵を置いていたような古くさい人間で、「情報」よりも「自分」の方が上位にあるという考え方を捨てきれていない。二つを天秤にかけたら、最終的には「自分」の方を選ぶ、そういう人間だ。
以下は、3次会？で他の人ほったらかしてZIGOROuさん（途中で帰ったけどamachangさんも）相手にtextshadow.jsを見ながら頭から解説していて出てきた「これ個別にエントリ立てたらブクマ数結構行くんじゃね？」と言われた箇所。
- タグ名やクラス名は冒頭で定数プロパティとして定義しておく。→詳しい解説
- Split Browserとの互換性確保のための方法。
- DOM3 XPathで多用するのは
ORDERED_NODE_SNAPSHOT_TYPE。→詳しい解説 - ノードタイプなどの指定・判別には定数プロパティを使い、そのプロパティの値は基本的に使わない。例として、数値で
1と書かずにNode.ELEMENT_NODEと書く。 - セレクタの詳細度の計算方法について。classが10000個あったらidの指定より詳細度が高くなるのか？→うっかり連結してたけど、どうやら連結せずに比較するのが正しいようだ。コード書き直さないといかんなあ……→trunkで書き直した。次版から直る。
:first-line疑似要素を「疑似要素」でなくする（具現化する）方法。getBoxObjectForメソッドはIEに合わせてgetなんちゃらRectsなんちゃら、という名前に変わる？- CSS3セレクタからXPathへの変換テーブル。哀さんの良エントリが今は見れなくなってる。今Googleで検索して上位にくるやつは間違いが多くて使いものにならない。
- テキストノードを新しく生成した要素でラッピングする際の、ホワイトスペース文字を追い出す処理の必要性について。
- XPCNativeWrapperでラッピングされた
windowとの情報の受渡しのテクニック。 - 時間がかかりすぎてFirefoxが長時間固まってしまうような処理は、キューの形にしたあと、タイマーで一つ一つ分割処理していく。
- GeckoではDOM2 CSSの
selectorTextに対する値のセットができない（未実装） - preferences listener（nsIPrefBranchInternalの
addObserver/removeObserver）の使い方。 - 既存のメソッドを置き換えるときに必ずやるべきこと。
- Piroの最近作る拡張機能で使っている、典型的なサービスオブジェクトのパターン。アホみたいに大量に拡張機能を作ってきた中で得た反省が集約されている。
- DOM2 Event、
handleEventを使ったテクニック。 getCharPref,getIntPref,getBoolPref→getPrefにまとめると楽（全部文字列として扱う、というアプローチもありうる）- nsIPrefBranchはBranchとして使う機能があるけど、あんまり意味が無いと思ってる。
そのうち一つずつエントリ立てて詳しく解説するかもしれない。
自分ではごく当たり前だと思っていること、こんなのやってて当たり前だろと思うことばかりなんだけど、ZIGOROuさんに「Text Shadowはスルーしてたけど、詳しく見てみると宝の山じゃないか」とやたら褒められてしまって、むずがゆかった。でも、「当り前」と思いつつも「なんでみんなこんな程度の事やってないの？」とも思っていたので、自尊心をくすぐられて調子に乗ってべらべらと喋り倒してしまった。僕は所詮は「褒めてもらいたいだけ」の薄っぺらな人間なんだ、ということを再認識させられた。
で、こうして書き出してみたものを酔いの醒めた頭で見直してみても、やっぱり、どれもこれも大したことのないしょぼいテクニックばかりで、うまく乗せられただけなんじゃないの？ という気がしてならない。
まあ、そんなしょぼいテクニックでも、塵も積もれば山となるということで、それなりに評価されても変ではないんだと思う。でも、だとしたらなおさら、こうやってノウハウを開示したら、個々のテクニック自体はすぐに真似できる簡単な物ばかりなのであって、今まではそれが難読コードの中に埋もれていたおかげでそれを「読み解ける」レベルの人にしかバレなかったけれども、それを紐解いてしまうと僕の手元には何も残らないわけで、「僕でなければできないこと」がどんどん消えてなくなってしまうわけで、僕の存在価値はますます失われていくんだなあと思えて、やるせない。
いや、約束した以上はもちろんやるつもりですけどね。
以下はText Shadowとは関係ない話。
- 指定した座標の要素を取得するメソッド、elementFromPointの話→tabcatalogの実装の解説とも関係している。
- 拡張機能同士の依存関係はinstall.rdfに記述できる。でも依存してるパッケージを自動でインストールしてくれるような仕組みは無い。
- AMOはアドオン単位での管理で、エンドユーザの方を向いている。でも開発者としては、ライブラリやソースコード単位で管理されていてほしい。CPANのような、ライブラリ単位での再利用の仕組みがない。→グローバルな名前空間を汚さなかったり、古いバージョンの同じライブラリが他のアドオンで読み込まれていても大丈夫だったり、という風な、ありがちな諸問題への対策がきちんと盛りこまれたライブラリの枠組みがあればいいんじゃないのか？→MDCのコードスニペットは便利だけど、コード片がぽんと置いてあるだけだからあまりうれしくない。そのコードが出てくる「文脈」まで含めたライブラリでなければ意味が無い。
以下は、参加者によるまとめなど。
wikieditish message: Ready to edit this entry.