Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
UnitTest.XUL 0.5.0 - Oct 30, 2008
会社サイトのブログの方で解説を書くつもりですが、UxU新バージョン（0.5.0）を公開しました。日本時間10月30日の昼下がり、太平洋標準時で29日の肉の日リリースです。変更点はMozilla Add-onsのバージョン詳細の方を見てください。
自分自身がサーバソケットの方を使ってなかったのでMozRepl互換のサーバ機能の方がだいぶ長らく死亡してたみたいなんですが、今回プロファイルを指定してテストを実行する機能を作るにあたり、新たに起動された子プロセスと親プロセス側でテストの実行結果や中止の命令とかを通信しあうために、UxUサーバで使われていた機能をブラッシュアップして流用するようにしたため、ぶっ壊れていた所がだいぶ直りました。今後はサーバ周りの実装も気をつけて見るようになると思いますので、ぶっ壊れっぱなしのまま放置ということは減るんじゃないかと思います。多分。
ところで、子プロセス起動してうんたらかんたらということができるようになったということは、FirefoxやThunderbirdの上で動かすことにこだわらなくてもいいようになった（必要に応じてそれらを呼び出せば済む）という事で、やる気次第ではXULRunnerアプリケーション化という道もあり得るかもしれませんね。
Firefox 2.0.0.17とThnderbird 2.0.0.17のJavaScriptエンジンに極めて深刻な問題があるようです - Sep 30, 2008
仕事で書いてるコードがどーにもうまく動かなくて、ついこないだまで正常に動いてたのにどうして？！と思って色々試していたら、特定の関数をtoString()等で文字列化した時におかしな現象が起こっていた。具体的には、Thunderbird 2.0.0.17のAccountManager.jsで定義されているsaveAccount()を書き換えようとしたら例外が発生して、onSave()を文字列にしてreplace()で改変した物はfor〜inループだった箇所がwhileループになってしまっていた。コードを削っていったらめちゃめちゃ短いコードでも再現したので、Bugzillaに報告しておいた。
上記のような方法で動的にパッチを当てる手法を僕は多用してるので、仕事で書いたコードもここで公開してる拡張機能のコードも、正直、どのくらい影響を受けるのか見当も付かない。早急に解決されることを祈るのみだ。
ちなみにFirefox 3.0.3ではこの問題は起こらなかった。2.0.0.17で入ったセキュリティ上の修正による後退バグっぽい？
追記。29日時点ですでに修正済みだったようだ。これ、あと1ヶ月間放置ですか……？ ものっそクリティカルなバグだと思うんだけど。
Shibuya.js in Kyoto - Jul 20, 2008
すみません寝坊しました。
自分で納得できる所までUxUを直してからでないと話が始まらないと思って（「なんだプレゼンで喋ってる事は実際にはまだ使えないのか」というガッカリ感が好きじゃない）、手を入れているうちに遅くなってしまい、帰ってからとりあえずご飯食べて、徹夜覚悟でプレゼン資料作りに取りかかったのですが、そこで記憶が途切れています。おそらく「ちょっと休んで再開しよう」とか思って横になったんだと思いますが、そのまま寝入ってしまったようです。
6時台には出発して新幹線に乗る予定だったのに、目が覚めたのはもう9時近くになってからでした。速攻で調べても、東京を出発して京都に着くのは12時ちょうどが限界でそれより早くにはどう頑張っても無理。
「ちょっと長めに時間欲しい」とかほざいて15分を割り当ててもらったのに、そこにぽかーんと穴が開くわけですよ。これはまずい。早く伝えないと、時間を他の人に使ってもらうなり何なりの対処も取れない。しかし参加メンバーの電話番号とか緊急連絡先を把握していなかったので超焦った。古いメールに書かれてた電話番号にダメ元で電話してみたけど繋がらないし、USTREAMで誰かやってないかと検索してみても引っかからないし……って当たり前だ、この時間じゃまだイベント自体始まってすらいない。焦りすぎだ自分。会場に向かう予定の知人にチャット経由で連絡を取れたので伝言をお願いしたりする一方で、発表内容が自動テストの事だから誰かに代わりに自動実行のデモだけしてもらって少しでも穴埋めにしてもらえるようにと思って、途中だったプレゼン資料を適当な所まで作った後、必要なファイル群をZIPで固めて、自動テストの実行手順を付けて関係者に送信。やきもきしながらレスポンスを待ちました。
で、nagayamaさんから連絡があったので、電話で確認しながらとりあえずデモが動く状態までセットアップしてもらい、後のすべてを託しました。その後発表がどうなったかは把握していません。イベント自体つつがなく終わってくれた事を祈るばかりです。
UxUの自己テスト - Jul 17, 2008
UxUの自己テストを（現実逃避に）ようやく書き始めてみている。今まで無かったのかよって怒られそうだけど……
アサーションのモジュールのテストとかテストケースのテストとか、書いてて頭がこんがらがってくる。
MochiKitのテスト機能 - Jul 15, 2008
MochiKit見てみた。
これも基本はやっぱりユニットテストに特化した感じかなあ。少なくともGUIのテストは意識してないか……
仕事でFirefoxの拡張機能をやるという事になったときに最初に須藤さんに「拡張機能のテスト用フレームワークってあるの？」みたいな事を聞かれて、それでMozUnitに辿り着いたんだけど、その時の僕にはまだ自動テストとかテスト駆動開発という物がどういうものかよく分かってなかった（今もまだよく分かってないかもだけど）。今思うと、その時僕が思ってた「自動テストって、こういう事をしなきゃいけないのかな？」というのは、開発者世界の常識的には相当ワガママな要求をイメージしていたようで、普通は「自動テスト」「ユニットテスト」というともっと低レベルの、あくまで部品単位の品質を高める物という認識でよかったみたいだ。それを知らずに僕はSeleniumのGUIアプリ用版みたいなのをイメージしてたから、「そんなの無理ッスよ……」と勝手に諦めムードになってた。とはいえ、その勘違いが無ければここまで意地になってUxUに手を入れまくる事もなかっただろうしなあ。
JsUnit - Jul 15, 2008
JsUnit見てみた。
オンラインの例はFirefox 3で普通に動いたんだけど、ダウンロードしたやつは何故か動かなかった……パスに日本語が含まれてるとダメとかそういうやつ？
見た感じではWebページ用のJavaScript一般のユニットテスト用という感じで、Chrome特権であれこれするやつを、しかもGUI上の動作をテストするという前提では……ないよねえ、やっぱり。
script.aculo.usのユニットテスト機能 - Jul 15, 2008
script.aculo.usのユニットテスト機能を見てみた。
昔、Firefox上でprototype.jsを試してみたことがあるけど、少なくとも当時のバージョンではprototype.jsはObjectのプロトタイプとかにプロパティを追加する仕様だったような気がする。なんか全般的にfor-inループを多用してる部分で影響が出すぎてて、Firefoxの動作自体がぶっ壊れてしまって使い物にならなかった記憶がある。少なくとも今のscript.aculo.usが使ってるバージョンについてはObjectのプロトタイプは触らないようになってるみたいだけど、FunctionやRegExpなどのプロトタイプには変更を加えてるみたいで、ちょっと怖い……気にしすぎだろうか。
肝心のユニットテスト機能について。
- アサーションが色々ある。アニメーション効果を扱うライブラリってことで、要素が見える状態かどうかとかのためのアサーションもある。
- ベンチマークを取る機能がある。これパクろうかな。
- BDD風の記述もできるみたい。
- 処理待ちについては、setTimeoutを使って一定時間後に渡した関数に処理を移すという機能がある。
Firefox上でも問題なく動くと仮定しても、これを使って拡張機能のテストをやろうとすると結局は「どうやってテストを走らせるのか」「テストの結果をどうやって見るのか」といったあたりは自分で解決しなきゃいけないか……粒度を高めて本当にユニットテストのために使うぶんには十分使えそうなんだけど、いわゆる結合テスト的な所になってくると面倒さが跳ね上がりそう。XULに特化した便利なユーティリティを沢山用意しておくだけでもそれなりにUxU意義はあるのかな。
自分自身が基本的にGUIアプリしか使えない人間なので、script.aculo.usのテスト機能のように「これ使ったらテストができるよ」って機能群をぽんと渡されても、「え？ え？」って感じで戸惑ってしまう。何かしら型にはめて「あなたはここだけやればいいですよ」って感じでやるべき事を絞り込んで貰えないと、どうしていいか分からなくなってしまう。そのあたりが、UxUでMozRepl由来の部分を全然使わずにMozUnitの部分ばかり拡張し続けている最大の理由なんだな。
僕があまりDocumentFragmentを使っていない理由 - Jul 07, 2008
自分にはちょっと承伏できない理由でJintrick氏にDISられてるので、一応釈明しておきます。
――「一応」と書いておきながら、Jintrick氏に「バカじゃねーの」みたいに煽られたような気がして感情的になってクドクド書き過ぎてしまったので、最初に例だけ示しておきます。
<?xml version="1.0"?>
<html xml:lang="ja">
<head>
<title>テスト</title>
</head>
<body onload="init()">
<script type="application/x-javascript">
function init()
{
var ul = document.getElementById('indicator');
document.addEventListener('keypress', function(aEvent) {
var li = document.createElement('li');
li.appendChild(
document.createTextNode(
[
aEvent.type,
aEvent.keyCode,
String.fromCharCode(aEvent.charCode) +'('+aEvent.charCode+')',
aEvent.target,
aEvent.target.localName,
(new Date()).getTime()
].join(' : ')
)
);
ul.insertBefore(li, ul.firstChild);
}, false);
}
</script>
<textarea rows="5" cols="50">ここに文字を入力すると、イベントの詳細を表示します。</textarea>
<ul id="indicator" style="height: 15em; overflow: auto;">
</ul>
</body>
</html>これが正常に動作しなくなるというただそれだけの理由で、僕はJintrick氏の勧める方法（上位のDOMノードをゴソッとDOMツリーから切り離して、ツリーに対する処理を行い、最後に再挿入することで、パフォーマンスを向上する）を全面的には採用できません。
以下、長々とその説明。
ロケーションバーで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が落ちたし。