Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
Selenium、Selenium IDE - Jul 16, 2008
試してみた。
SeleniumはWebアプリケーション用のクロスブラウザな自動テストツールで、独自の書式または好みの開発言語でテストケースを書いて、Webアプリケーションの機能テストを行える。Selenium IDEを使うとFirefox上での操作を記録して（何もないところでクリックするという風な操作も記録される）、Selenium用のテストケース（の雛形）まで生成してくれる。
あーこれはいいわー。Webアプリ開発やるなら絶対お勧めだと思う。FirefoxでSelenium IDE使ってテストケース作って、それをエクスポートして他のブラウザでも自動テスト、ということもできるようだし。
ちゃんとドキュメント見てないからよく分かってないけど、ユニットテスト（単体テスト）より機能テスト（結合テスト）に特化してるような気がした。単体テストには別のツールを組み合わせることになるんだろうか。あと当然だけどFirefoxのアドオンの自動テストには使えない。
MozLab - Jul 15, 2008
19日のShibuya.js in KyotoでUxUの事を話そうと思ってとりあえずその前に他のツールの現状を調べとこうと思ってUxUの元になったMozLabを見てみたら、ライセンスがMPL/GPL/LGPLのトリプルライセンスになってた。フォーク前のMozLabはGPLだけだったのでUxUもGPLなんだけど、こういう場合ってUxUもトリプルライセンスにできたりするんだろうか、それともあくまでフォーク時点でのライセンスに従う事になるんだろうか。
とりあえず中身見てみたけど、スタックトレースをマトモに辿れないっぽいとことかその辺はあまり変わってなかった。先方はMozReplの開発の方に注力してるってことみたいだなあ。対するUxUはサーバソケットの方はほとんど放置（僕が触れないので）でGUIのテストランナーの方に注力してる。まだ返信できてないけどこないだ会社の代表アドレス宛にMozLab作者の人から「英語版ドキュメント無いの？」的メールが届いてたので、このあたりの事を話してマージの方向を目指してみるべきだろうか？
スマートロケーションバーで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文字だけにヒットした場合に無限ループに陥ってしまう）という現象が起こってしまっていて焦った。対策を入れて早速更新した。
意外なところでFirefox - Jul 03, 2008
前者は「ねんどろいど」等で有名なグッドスマイルカンパニーのブログ、後者はアイマスの双海亜美・真美役の下田麻美さんのブログ。まさかこんな所でFirefoxを見かける日が来るとは思わなかった。
どうでもいいけど、再販分のねんどろミク早くこないかなー……クオリティ落ちてないといいんだけど。
ロケーションバーで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が丸見えになる。その代わりちゃんと動く。という状態。
Firefox 3のロケーションバーにフォーカスを移したときに必ず日本語入力を無効にする方法 - Jun 18, 2008
既出だと思うけど。userChrome.cssに以下の内容を書けば、ロケーションバーにフォーカスしてURIを入力しようとして日本語入力になっててムキー！！！となる事態を防げる。
#urlbar *|input {
ime-mode: inactive !important;
}ただし副作用として（というか当たり前だけど）毎回必ず日本語入力をONにしないといけなくなる。スマートロケーションバーでポップアップされた候補を上下キーで選び始めてから「やっぱり別の入力で」と思ってロケーションバーにフォーカスを戻してもう一度入力をやり直す、という場合でも日本語が勝手にOFFになる。これを解決しようと思ったらスクリプト（userChrome.jsかアドオン）で動的に上記のスタイル指定を与えたり外したりしないといけない。
ちなみに、XUL/Migemoは直接入力でローマ字入力を行わないとまともに動かないので、最近のバージョンでは検索バーのテキストボックスに対してそういう処理（スクリプトで一時的にIMEを無効化する）をしている。
19日追記。というわけで作ってみた（Auto Disable IME 0.1.2008061901）。動的にIMEのON/OFFを切り替えるので、上のスタイル指定と違い、スマートロケーションバーで候補を表示した後にフォーカスを戻した時などはそのままIME ONの状態が維持される。たったそれだけのアドオンです。WindowsとMac OS XのFirefox 3以降専用で、Linuxでは動かない。
公開してから気付いたけど、IME and DiMENSiONにも同じ機能があったのね……まあFx3以降のネイティブ機能によるミニマム実装ということでどうかひとつ。