Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
Firefox 3.1ロケーションバーの新機能 - Jul 22, 2008
というわけでXUL/Migemoの方でも対応する事にしました。Trunkではすでに組み込んでありますが、リリースはまだです（やる気がないので）。ちなみに上記エントリで紹介されている隠し設定の値を直接見に行ってるので、設定さえしてあればFirefox 3.0でも動作しますっていうか手元で動作してます。
ロケーションバーまわりの自動テストができるようになってからリリースしたいなあ。
Firefox 3 Hacks - Jul 17, 2008
萌えキャラをという話もありましたが、年齢層の高い複数関係者の反対でボツになりました
というのを見て「ま た P i r o か」とあらぬ疑いをかける人がいそうなので先に言っておきますが、僕は関係者の中では一番最初に反対を表明しましたよ。
あと江村さんに倣って自分も担当章の見出しを晒してみます。
- 3章 Firefox 3向けの拡張機能開発テクニック
- #19. 拡張機能開発の基礎
- #20. 標準ライブラリ「FUEL」を活用する
- #21. MozStorageでSQLiteデータベースを操作する
- #22. 履歴とブックマークのデータベース「Places」の正体を知る
- #23. APIを通じて履歴とブックマークを操作する
- #24. Placesデータベースへの問い合わせ命令
- #25. Placesデータベースへの問い合わせ結果を利用する
- #26. JavaScriptコードモジュール
- #27. Firefoxに含まれているJavaScriptコードモジュールを使う
- #28. JavaScript製XPCOMコンポーネントで特殊な処理を実現する
- #29. 拡張機能を安全に自動更新できるようにする
見出しの数だけ見ると大したことないんですが、ゲラ刷りの目次によると、この章だけで100ページ超えてるみたいです。この見出しの下に大量の小見出しがあるので読みにくさ抜群ですね。校正したくないよう……
UxUの自己テスト - Jul 17, 2008
UxUの自己テストを（現実逃避に）ようやく書き始めてみている。今まで無かったのかよって怒られそうだけど……
アサーションのモジュールのテストとかテストケースのテストとか、書いてて頭がこんがらがってくる。
スマートロケーションバーでNOT検索できるようにしたXUL/Migemo 0.10.5をリリースしたよ - Jul 07, 2008
表題の通り、XUL/Migemo 0.10.5からロケーションバーでNOT検索を可能にしました。「mozilla -firefox」という風に入力すると、「Mozillaという単語は含むがFirefoxという単語は含まない」候補だけがヒットするようになります。当然Migemo検索との併用も可能。いらん候補が大量にヒットするのがウゼーと常々思っていたので、バグ修正のついでにサクッと実装してみました。
残念ながら、履歴とブックマークの管理、履歴サイドバー、ブックマークサイドバーでの検索については非対応です。これらの検索機能はPlacesのクエリ機能に依存していて、そのクエリ機能にNOT検索の機能がないためです。クエリにNOT検索の機能が付いたら対応できるかも。
スマートロケーションバーの検索に対応したXUL/Migemo 0.10.0をリリースしたよ - Jul 03, 2008
ということでXUL/Migemo 0.10.0やっとリリース。
スクリーンショットを見ると分かるとおり、なにげにAND検索にも対応してます。仕掛けは単純といえば単純で、入力された文字列をスペースで区切ってそれぞれについて正規表現を生成した後に、それらの順列組み合わせを全展開した正規表現をさらに生成する（これを使ってマッチングするので、各単語の順番が入れ替わってもマッチする）という、ものすんごい力業。単語数が増えると組み合わせの数が爆発的に増えて正規表現がクソ長くなってマッチングがクソ重くなるので、実用的な速度が出るのはだいたい3語くらいまでが限界だと思います……
ちなみに順列組み合わせの展開には無駄にMozStorageを使ってます。JavaScriptで一体どーいうアルゴリズムでやりゃぁいいのかちっとも分からんかったのでググってみたら、順列組み合わせの総数を求める方法ばっかり引っかかる中で一つだけSQLの自己結合を使った解き方が見つかったので、それをそのまま使わしてもらいました。pIXMigemoTextUtilsのgetANDFindRegExpFromTermsというメソッドがそれなので、興味ある人は見てみてください。
しかしまあ、今回のこれはFirefox 3 HacksのためにPlacesのことを詳しく調べてたからやっと実現できたようなもんで、つまりFirefox 3 Hacksを読めばこんなことは楽勝でできるようになるかもねということで、皆さんゼヒ買って下さい、と宣伝しておきます。オライリーから8月発売予定です（再掲）。
5日追記。ページ内検索では考慮しなくてもよかった問題が表面化してフリーズする（全角スペース1文字だけにヒットした場合に無限ループに陥ってしまう）という現象が起こってしまっていて焦った。対策を入れて早速更新した。
ロケーションバーでXUL/Migemoを使う計画がわりと現実的になってきたっぽい - Jul 02, 2008
places.sqliteが数十MBを超えているのりさんやdrryさんの環境では分単位で固まってしまって使い物にならん、ということだったので、お二人に協力してもらって各段階での処理の所要時間を調べてみた。
そしたらどうも、Placesデータベースから文字列をぶっこ抜いて正規表現でマッチングしてるところがものすごく重いらしいということが判明した。ログによると500万文字ある文字列に対してマッチングをかけようとしてたんだから、そりゃあ固まるわ、と。
固まる問題だけでもとりあえず何とかしよう、ということで数千件単位で文字列を取り出し→マッチング→取り出し→マッチング……という風に分割処理するようにしてみたところ、とりあえず固まる問題は何とかなったんだけど、でも検索結果が出るまで延々待ち続けないといけないのは相変わらずで。
と、そこでやっと気づいたんだけど、べつに正規表現でのマッチングとポップアップの内容の更新とを完全に分けて実行する必要はないんですよね。ちょっとずつマッチングしてちょっとずつ検索結果を取得してちょっとずつ結果のリストを更新していけば、全体ではものすごく時間がかかるようであっても、とりあえず最初の方の結果だけは見えるからストレスにはならない。必要な数だけ結果を取り出せたらそこで処理を打ち切ってしまえばいいんだし。
というわけであちこち書き直してみた結果、最初の実装に比べるとびっくりするほど快適に動くようになった。スレッド使ってなくてもそんなに重くない。のりさんにも「これなら常用できそう」と言ってもらえたし。
最終的にやってることは同じなんだけど、やり方を変えるだけでこんなにも体感速度に違いが出るものなんだなあ、ということをこれ以上ないほど実感した日でした。
それはそうと、途中の段階で分割処理を行うようにしたときのログを見てて気がついたんだけど、SQLite（というか RDBMS）ってすごいね。テストしてもらったのりさんの環境の場合、スマートロケーションバーの検索対象になる物だけでも46000件近く、そうじゃない物も含めればきっともっと大量のレコードがあるのに、「並べ替え後の順番で任意の箇所を取り出す」のに1秒もかからないというのには驚いた。今までちゃんとしたデータベースを触ったことがなかったから、こんなの未知の世界だ。世界規模のデータベースと世界規模の処理環境に憧れてグーグルを目指す人の気持ちが、少しは分かったような気がする。
ロケーションバーでXUL/Migemo - Jul 01, 2008
こないだから少しずつ取り組んでる。
当初は皆目見当も付かなかったけど、Firefox 3 Hacksを書くために調べた知識が早速役に立って、Places APIを使ってる「履歴とブックマークの管理」と「ブックマーク」「履歴」の各サイドバーについてはワリとあっさり実装できた。
ロケーションバーについては残念ながら普通のAPIを使っておらず、オートコンプリートの実装の中でガチガチに書かれてて、まともにやっても手出しできない。OR検索さえできればMigemoが使えるのに。ということで、まず最初は、オートコンプリートのコントローラに複数の単語を順番に渡して結果のリストを生成させてそれを最後にまとめる、という事をやってみた。これは結構イイ線いったんじゃないかと思ったんだけど、履歴の件数が増えたりヒットした単語数が増えたりするとえらい事になってしまって、実用的な速度は出なかった。
そこで諦めて腹をくくって、無い知恵絞ってSQL文書いて、なるべく効率よく処理するようにしてみた。これで速度はだいぶ上がって、3文字以上入力した先あたりならかなりサクサク動くようにはなったんだけど、1文字2文字程度しか入力していないとやっぱりズシッと重い感じがある。
XPCOMのスレッドを作る機能を使ってみた所、Firefoxが落ちたし。
拡張機能で独自プロトコルを実装しようとしてFirefox 2とFirefox 3での動作の違いに躓いた - Jun 19, 2008
ソース表示タブを更新して「やったー」と思ってたらFirefox 3では動くけどFirefox 2では動かないという状態になっていて焦った。0.2.*からFirefoxのブラウザのUIによりシームレスに統合するべく、「view-source-tab:（元のURI）」という独自プロトコルでソース表示するようにして、Chrome URLをユーザの目には見えないようにしてみたんだけど、この際に使ったリダイレクトの方法だとFirefox 3では動くのにFirefox 2では動かないという現象が起こってしまっていた。基本的には過去に訳した記事の通りにやったんだけど、思わぬ所で嵌ってしまった。
この情報、元々はURNサポートの実装を改善するために調べたんだけど、その時は、訳した記事の指示の通りにやるとブラウザ上で表示されるURIがリダイレクト前のURNのままになるのは望んでいなくて、結局nsIContentPolicyを使うようにしていた。
しかし今回はむしろその逆で、about:configみたいにユーザには実体のChrome URLを見せないまま機能させたいというのが目標だ。というわけで元記事のやり方ほぼそのままでnewChannel()で生成するURIだけChrome URLにしてみた所、Firefox 3でのテストでは問題なく動いたのでそのままリリースしたんだけど、これがFirefox 2では動かなかったという次第で。
viewSource.xul等を「リダイレクト先」にした場合、ブラウザ上に表示されるURIとしてはあくまでリダイレクト前の「view-source-tab:（URI）」という物になって、Firefoxからもあくまでそのリダイレクト前のリソースであるという風に見えるようになる。userChrome.cssでabout:configの表示をいじりたかったら 実体のChrome URLの方ではなく@-moz-document url(about:config) { ... }と書かないと機能しない、ということからもそれが分かる。そのため、viewSource.xulにクロスパッケージオーバーレイで機能を追加していた場合、viewSource.xulにリダイレクトするとその表示結果のURIのもとではクロスパッケージオーバーレイは適用されず、タブの中でうまく動かすためのパッチを当てられないことになる。
しかしこの場合でも<?xul-overlay href="..."?>で書かれていたオーバーレイは適用される。なので、ソース表示タブで用意したXULドキュメントからオーバーレイでviewSource.xulを読み込んでやれば問題なく動くようになる。というのがFirefox 3上でテストした時の結果だった。
Firefox 2では、クロスパッケージオーバーレイが効かないのはもちろんのこと、上記のように直接ヘッダ部分に書いて指定したオーバーレイも全然読み込まれないということが、リリース後に試してみてやっと分かった。ソース表示タブで用意したXULドキュメントを読ませても何もオーバーレイが適用されないので、画面は真っ白のまま……という状態になっていた。なんてこった。
ちょっと試した限りでは上手くやる方法が見つかりそうにないと思ったので、もう諦めて、Firefox 2の時はドキュメントのURIがリダイレクト先の物に完全に切り替わるnsIContentPolicyを使った方法を使うようにした。今のソース表示タブは、Firefox 3で「view-source-tab:http://...」などと入力するとそのURIのままでソースを表示するけど、Firefox 2の場合は「chrome://viewsourceintab/content/viewer.xul?http://...」という風にChrome URLが丸見えになる。その代わりちゃんと動く。という状態。
UxUの使い方の簡単な解説を書きました - Jun 13, 2008
会社のサイトのコンテンツが一新され、コンテンツにブログが加わりました。何をやってる会社なのか（何ができるのか）分からんと言われがちなようなので、みんながちまちまやってる内容をここに書いていって、「当社ではこういうことができます」的な宣伝材料にする、というのが一応の目的のようです。
で、自分もアドオン開発者向けの自動テストツールであるUxUの使い方の解説なんかを書いてみました。ツールの使い方というよりは、「はじめての自動テスト」みたいな感じになってしまってますが。自分自身がまだ自動テストのことをよく分かってなくて須藤さんとかにしょっちゅう「何考えてんだ（全然分かってねえな）……」的な指摘を受けてばかりなので、自分の理解レベルに合わせるとこんな感じになってしまいました。技術力とか実績とかのアピールの場のはずなのに、こんな低レベルな記事を載せてしまうと却って会社の印象に泥を塗ってしまうんじゃなかろうか、ということをamachangのエントリとか見て思いもしましたが、もう後の祭りです。
UxUのマニュアルのつもりで、またそのうちXUL/Migemoのテストでの利用例の解説の続きを書くかもしれません。
あと、サービス→Mozillaサポート 実績紹介→Thunderbird用アドオンと辿ったページでThunderbird用の地味なパッチもいくつか公開しています。中にはもしかしたら同種のアドオンがすでに世の中にある車輪の再発明な物もあるのかもしれませんが、探すより作った方が早かったんで……
Firefox 3 on Mac OS Xのタイトルバーの新機能 - May 29, 2008
誰も書いてないようだったので、activetitlebarcolor属性とinactivetitlebarcolor属性についての説明を勝手に書き加えた。どこにも説明がなかったってことは、これは本当は触っちゃいけないって事なのかもしれんけど、そんなこと知ったこっちゃねえな！（ひどい）
以下、具体的な利用シーンについてちょっと解説。
Mac OS X上では、FinderやSafari、iTunesなどいくつかのアプリケーションで、ウィンドウのタイトルバーとツールバーが結合されたような見た目になっている。これを真似するためにFirefox 3で実装されたのが、activetitlebarcolor属性とinactivetitlebarcolor属性だ。実際には、OS X用デフォルトテーマのバインディングで利用されている。
通常、Mac OS Xではウィンドウのタイトルバーはグラデーションがかかってるんだけど、この属性で #FFF とか #FEFEFE とか gray とかの形で色を指定しておくと、ウィンドウがアクティブな時と非アクティブな時のそれぞれで、タイトルバーの背景がその色一色で塗りつぶされるようになる。と同時に、タイトルバーとウィンドウ内容との間の境界線が表示されなくなる。あとはウィンドウの背景やツールバーの背景をタイトルバーに指定した色と同じ色もしくはそれにつながるグラデーションにしておけば、タイトルバーとツールバーがくっついたデザインのように見えるようになる、というわけ。（逆に、これらの属性をremoveAttribute()で取っ払ってやれば、タイトルバーの表示を強制的に今まで通りの物に戻すことができる）
なお、これらの属性値を変更した場合、ウィンドウのフォーカスが移動するとかウィンドウの大きさが変わるとかしてタイトルバーが再描画されるまでは、見た目は変化しない。動的に変更する時は、属性値を変えた後に window.resizeBy(-1, 0); window.resizeBy(1, 0); とかいう感じで強制的に再描画させるといいと思う。
この機能の残念なところは、グラデーションや半透明や背景色といった派手な指定ができない点。あくまで背景を一色で塗りつぶすことしかできない。CSSのbackgroundプロパティと同等の機能をフル機能で使えれば良かったんだけどなあ。