Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
XML署名とハッシュを使って安全な方法でアドオンを更新できるようにする - Sep 21, 2007
Firefox 3からは、安全な方法での自動更新に対応していないアドオンはインストールできなくなるようだ、ということを先日書いた。そっちのエントリに詳しいことを書いたんだけど、要約すると、「安全な方法での自動更新を提供する」方法には以下の3つのパターンがある。
- Mozilla Add-onsにアドオンを登録し、そちらの自動更新の仕組みを利用する。
- HTTPSで通信できるサーバを自分で用意して、そこで自動更新の情報を含んだRDFデータソースとXPIパッケージを公開する。
- 自動更新の情報を含んだRDFデータソースに、XPIパッケージのハッシュ値を記述した上で、XML署名を施す。
くでんさんの報じる所によると、このうち3番目の方法をものすごく簡単に実行できるようになる開発者向けのツール「McCoy（マッコイ）」が公開されたそうで、早速自分も使ってみたところ、本当に簡単だった（手順としては。作業はなんだかんだで手間取ったけど……）。なので、せっかく須藤さんにCOZMIXNGのアカウントを作ってもらったけど、今後はこの方法を使っていこうと思う。
CSS3セレクタとXPathでの表現の対応表 - Sep 13, 2007
拡張機能勉強会の時に焚き付けられた、Text Shadowのコード（textshadow.js）を教材にして拡張機能開発のノウハウを解説していくシリーズ。
XPathをノードの検索に活用する方法を紹介したけど、肝心のXPathが書けなきゃ意味がないわけで。でもXPathって、ノードセットがどうとかノードテストがどうとか軸がどうとか修飾がどうとか、いざ勉強しようとしてもこれ専用の用語がやたらたくさん登場してきてものすごく萎える。CSSのセレクタの方が、機能は限られてるけどまだ分かりやすい。CSSのセレクタとXPath式の対応表があればいいのになあ、ということを、だいぶ前から僕は思ってた。
実は何年か前、哀さんのサイト（Black Box）でそういうコンテンツがあったんだけど、移転のゴタゴタか何かで消滅したままになってる。しかも、今「CSS XPath」みたいなキーワードでGoogleで検索してみて上位にくるエントリは、情報が不十分だったり間違いが含まれてたりする。
というわけで、CSS3セレクタ（このエントリを書いた時点ではワーキングドラフト）とXPath式の対応表で、詳細な物を作ってみた。
getElementsByなんちゃら の代わりにXPathを使う - Sep 09, 2007
拡張機能勉強会の時に焚き付けられた、Text Shadowのコード（textshadow.js）を教材にして拡張機能開発のノウハウを解説していくシリーズ。
W3CのDOMでは、要素ノード（およびそのリスト）を得る方法として以下の方法がある。
getElementById(aName)- IDをキーにして単一の要素ノードを得る。
getElementsByTagName(aTagName)- タグ名、要素名をキーにして要素ノードのリストを得る。
childNodes- 子ノードのリスト。
本当はネームスペースを指定して検索する物もあるんだけど、ここでは割愛。
これら以外に、W3C DOMではないがこういうのもある。
getElementsByClassName(aClassName)- クラス名をキーにして要素ノードのリストを得る。WHATWGのWeb Applications 1.0で定義されており、Firefox 3で利用可能。
getElementsByAttribute(aName, aValue)- 属性名と属性値をキーにして要素ノードのリストを得る。属性値として「*」を渡すとその属性を指定された要素全てを得る。FirefoxでXULドキュメントにおいて利用可能。
ただ、探したい要素ノードの条件が複雑な時は、これらを使って取得したノードリストをループ回して条件判断しないといけないし、そもそもこれらでは要素ノード以外は取得できない。そこで最近のJS界隈でよく使われているのが、XPathだ。
XPathとは、/html/descendant::li[@class="navigation"]という風な「式」でXMLノードを特定する技術だ。XPathの書き方を新たに憶える必要はあるが、これを使えば、複雑な条件に合致するノードのリストを一発で取得することができる。コードが簡潔になるのはいいことだし、FirefoxでもSafari 3でもOperaでも、普通にDOMとJavaScriptでごりごりやるのに比べて20倍以上高速に動作するという話もある。
XUL Tipsのページに書いてるけど、FirefoxではDOM3 XPathで提案されているXPath関係の機能が利用できる。詳しい解説はHawk's W3 Laboratoryの「DOMとXPathの連携」（サイトが消えてるので、インターネットアーカイブからどうぞ）を見て欲しい。リンク先では「Gecko用」と書かれてるけど、現在ではOperaとSafari 3でも利用できるようになっている。
いざ要素名や属性名などを変えたくなった時にソースの中をあちこち探し回ったり巧みな正規表現を考えるために頭をひねったりしなくても済むようにするテク - Sep 05, 2007
拡張機能勉強会の時に焚き付けられた、Text Shadowのコード（textshadow.js）を教材にして拡張機能開発のノウハウを解説していくシリーズ。
Firefoxの拡張機能で、DOM要素ノードを動的に生成したり、編集したり、そうして生成したノードを後でまた収集したり、といった操作を行うような物を作る時は、必然的に、ソースの中に要素名や属性名が登場してくる。
var newNode = document.createElement('box');
newNode.setAttribute('class', 'my-custom-box');
parentBox.appendChild(newNode);
var nodes = document.evaluate('/descendant::*[@class="my-custom-box"]',
document, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
for (var i = 0, maxi = nodes.snapshotLength; i < maxi; i++)
{
this.processBox(nodes.snapshotItem(i));
}
こういう操作が一カ所だけにしか登場しないんなら別にいいけど、複数箇所で、似たような操作が何度もある場合は、要素名であるとか属性値・属性名であるとかノード検索の条件であるとかを、コードの冒頭で定数（定数プロパティ）として定義しておくことをお薦めしたい。
var myService = {
CUSTOM_BOX_NODE_NAME : 'box',
CUSTOM_BOX_CLASS_NAME : 'my-custom-box',
CUSTOM_BOX_EXPRESSION : '/descendant::*[@class="my-custom-box"]',
(略）すると、さっきのような箇所はこうなる。
var newNode = document.createElement(this.CUSTOM_BOX_NODE_NAME);
newNode.setAttribute('class', this.CUSTOM_BOX_CLASS_NAME);
parentBox.appendChild(newNode);
var nodes = document.evaluate(this.CUSTOM_BOX_EXPRESSION, document, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
for (var i = 0, maxi = nodes.snapshotLength; i < maxi; i++)
{
this.processBox(nodes.snapshotItem(i));
}textshadow.jsの冒頭箇所を見てみると、動的に生成するIDのプレフィクスとか、途中で生成する要素のクラス名であるとか、XPath式の中に埋め込む検索条件だとかを、片っ端から定数としてまとめて定義していることが分かるはずだ。
こうしておくと、いざクラス名が他の拡張機能とかぶっていたと判明した時なんかでも、ソースの頭の方をちょこっと書き換えるだけで済む。class属性の値として文字列リテラルが書かれている箇所を片っ端から探すようなことはしなくていい。
え？ 一括置換を使えばすぐだろうって？ まあ、確かにたいていの場合はそうなんだけど、でもそれじゃ解決できない時もある。
Firefox 3でのアドオンの自動更新に関する仕様変更（セキュアじゃないアドオンは全部蹴られる件） - Sep 04, 2007
のりさんのところで報じられている、Firefox 3の仕様変更について、チェックインされたパッチを詳しく調べてみた。
今後拡張機能の自動更新では、以下の2つの段階でセキュアかどうかのチェックが入るようだ。
- install.rdfに書かれたupdateURL（更新情報を提供するRDFデータソースのURI）がhttpsで始まる、もしくは、updateURLで示された先のRDFデータソースであるXML文書が署名されていてinstall.rdfのupdateKeyに書かれた公開鍵で復号化できること。これが第一の条件。
- 更新情報を提供するRDFデータソースに書かれたupdateLink（新バージョンのXPIパッケージのダウンロード用URI）がhttpsで始まる、もしくは、updateHashでハッシュが示されていること。これが第二の条件。
この二つの条件が満たされてやっと、アドオンの自動更新が行われるという仕組みになっている。
よって、アドオン作者が取れる選択肢は以下の4つになる。
- install.rdfからupdateURLの記述を削除し、全ての更新をMozilla Add-ons経由で行うようにする。（Mozilla Add-ons経由の更新はhttpsなのでセキュア）
- 自前のサーバにSSL証明書を置いてhttpsで通信できるようにして、そこに更新情報提供用のRDFデータソースとXPIパッケージを置く。
- 更新情報提供用のRDFデータソースに署名して、さらに、その中にXPIパッケージのハッシュの情報も含めておく。
- 自動更新のための仕組みを提供しない。現実は非情である。
やる方として一番楽なのは1と4なんだけど、1には重大な問題がある。
- 公開申請に通ったアドオンは、ファイルを更新する度に審査があるので、審査待ちで長期間放置されると死亡。
- 公開申請してないアドオンは、ファイル更新の度の審査は不要だけど、ユーザから見えないから気付かれなくて使ってもらえなくて死亡。
というわけでもうちょっと素早く対応できる路線として2を検討してみようと思ったんだけど、仮にどうにかしてSSL証明書を手に入れたとしても、そもそもさくらのレンタルサーバじゃビジネス用プラン以外ではSSLは使えないんだってさ……
3はやりかた自体が分からない。XMLに署名するとかハッシュ値得るとか、僕の頭ではちんぷんかんぷんです。
ということでいずれにしても今の野良アドオン天国はオシマイだと言えよう。
他の拡張機能やFirefoxの機能を破壊しないための基本テク - Sep 04, 2007
拡張機能勉強会の時に焚き付けられた、Text Shadowのコード（textshadow.js）を教材にして拡張機能開発のノウハウを解説していくシリーズ。
JavaScriptでは、普通に宣言した変数や関数はグローバルな物になる。
var name = 'hoge';
function getItem(aKey) {
return array[aKey];
}だから、Firefoxで最初から定義されてるグローバル変数や関数と同じ名前の変数や関数を定義してしまうと、エラーが起こるし、最悪の場合はFirefoxが動かなくなってしまう。
// ステータスバーだけ表示した
// 新規ウィンドウを開く関数「loadURI」を定義。
function loadURI(aURI) {
window.open(aURI, 'mytarget', 'status');
}
// でも、これをやってしまうと、事あるごとに
// 新しいウィンドウが開かれるようになってしまう。
// なぜなら、Firefox内で既に「loadURI」という関数が
// 「ページを現在のタブで読み込む関数」として
// 定義されているから。
// 「ブラウザの一覧」のページを新しいウィンドウで開いて、
// そのウィンドウをgBrowserという変数に格納する。
gBrowser = window.open('http://piro.sakura.ne.jp/browsers-list.html');
// でも、これをやってしまうと、Firefoxがまともに
// 動かなくなる。なぜなら、Firefoxのブラウズ領域の
// 要素ノードへの参照としてgBrowserが定義されているから。
これを防ぐ手っ取り早い方法としてお勧めしたいのが、自分の拡張機能で使う変数や関数を、「自分の拡張機能専用のサービスオブジェクト」のプロパティやメソッドとして保持するようにするというやり方だ。
高橋メソッド in XULの改良 - Aug 06, 2007
LL魂で高橋メソッド in XUL RETURNSの問題点や課題がいくつか浮き彫りになったので、それへの対応をちょっとばかしやってみた。
- 高橋メソッド提唱者の高橋氏自身から「文字の大きさを変えられない」という指摘を受けたので、プレゼンデータ内に記述するコマンドで文字の大きさを変えられるようにした。
- 複数のファイルに別れているために導入に躓く人がいたので、スタイルシートも画像も全部takahashi.xulに埋め込むようにした。
- WYSIWYGに近くするための作業を開始。とりあえずソース表示だけじゃなく、ページごとにデータを切って表示できるようにしてみた。ページ単位の削除や編集の機能はあるけど、ページの追加や並べ替えは未実装。
なるべく、自分が使ってもストレス無く使えるようにしたい。普通に文字入力してる感覚でサクサク作れるようなのが理想だなあ。
折り返されたインライン要素への影付け - Jul 29, 2007
テキストシャドウでの影付けの基本原理は以下の通り。
以下の解説を図を使って書き直しました。
拡張機能でtext-shadowを実装できないものだろうか - Jul 27, 2007
CSS2からCSS3に移ったtext-shadowは、どうやらFirefox 3ではサポートされない事がほとんど確定したようだ。これでモダンブラウザでドロップシャドウを実現できないのはFirefoxだけになったな（Opera 10とSafariは対応、IEもfilterを使えば可能）。
ということで拡張機能でtext-shadowを実現するという可能性を勝手に模索してみる事にしたよ。
アルゴリズムとしては以前須藤さんがcairoで不透明度を下げた物をひたすらずらして並べるというアレです。
拡張機能の名前と説明文の多言語化 - Jun 27, 2007
のりさんの伝える所によると、Firefox 3ではアドオンマネージャに表示される拡張機能の名前と説明文のローカライズ方法が変わるらしい。新しいやり方の解説がMDCにある。
| 方式 | 実際の手順とメカニズム | 利点 | 欠点 |
|---|---|---|---|
| 現状 | 各ロケール内のpropertiesファイルに名前と説明文をローカライズした物を置いておき、デフォルトの設定ファイル（defaults/preferences/*.js）でそれを参照する。 | 各言語ごとのローカライズ済みリソースが言語ごとに一ヶ所にまとまるので、作者にとっては管理がしやすい。 | 拡張機能を無効化すると、名前や説明文がデフォルトの物（一般的には英語）になってしまい、削除や再度有効化する際に、どれが目的の拡張機能なのか分からなくなる。 |
| 今後 | install.rdfに各言語へローカライズ済みの名前と説明文をまとめて書く。 | 拡張機能を無効化した状態でも、自分が現在使っている設定の言語で名前と説明文が表示される。 | 各言語ごとのローカライズ済みリソースが分散するので、作者に取って管理の手間が増える。 |
現状の問題を目にする人はあまり多くないかもしれないけど、例えばSplit Browser/分割ブラウザのように英語と日本語のロケールそれぞれで名前を変えているアドオンを使うと、この問題が表面化する。新方式では作る手間や管理の手間が増えるのが気になるが、この問題を解決するためには仕方がないのか。めんどくさいと思う奴はinstall.rdfもビルドスクリプトで自動生成するようにしやがれってことなんだろう。