Latest topics 近況報告

nsIFocusManagerを使ってウィンドウを最前面に持ってくる方法 - Jun 24, 2011

Firefox上でいくつかのサブウィンドウを開いていて、それらのウィンドウすべてがワンセットで他のウィンドウより前に出てきていて欲しい場面、というのがある。

例えば、GIMPはツールボックス等が複数のウィンドウにばらけている。これがもし、画像を編集するウィンドウにフォーカスしたらツールボックスのウィンドウがその背後に隠れてしまうという風になっていると、まるで作業にならないだろう（古いバージョンのGIMPをWindowsで使った時にはそんな風になってて頭を抱えた記憶がある）。

また、そういうワンセットで表示されていて欲しいウィンドウ達が、同時に起動している他のアプリケーションのウィンドウの前と後ろにそれぞればらけてしまうというのも、使う時に地味にうざい。

Firefoxの上で、拡張機能が開くウィンドウでGIMPのウィンドウ群のような振る舞いをさせるにはどうすればよいのか。このエントリでは2つの方法を紹介する。

まず1つ目。nsIXULWindowインターフェースのzLevelプロパティを使うと、Firefoxのプロセスが開くウィンドウの重ね合わせの順序をある程度制御する事ができる。一番単純なやり方は、ウィンドウを一時的に最前面表示に切り替えて、その後すぐに元に戻す、という方法だろう。

var XULWindow = window
                .top
                .QueryInterface(Ci.nsIInterfaceRequestor)
                .getInterface(Ci.nsIWebNavigation)
                .QueryInterface(Ci.nsIDocShellTreeItem)
                .treeOwner
                .QueryInterface(Ci.nsIInterfaceRequestor)
                .getInterface(Ci.nsIXULWindow);

var originalZIndex = XULWindow.zLevel;
XULWindow.zLevel = Ci.nsIXULWindow.highestZ;
window.setTimeout(function() {
    XULWindow.zLevel = originalZIndex;
}, 0);

ただ、仕様上の制限のため、この方法はWindowsでしか使えない。少なくともUbuntu 10.04のGnomeでは機能しなかった。

代わりに考えられるもう1つのやり方が、フォーカスを使うやり方だ。単純に考えても、window.focus()でウィンドウにフォーカスを与えると、強制的にそのウィンドウを最前面に持ってくる事ができる。

しかしこの方法にも問題がある。普通にwindow.focus()すると、例えばそのウィンドウの中の特定のテキストボックスにフォーカスしていたとしても、そのフォーカスが失われてしまう事になる。

この問題を回避するには、Gecko 1.9.2/Firefox 3.6から導入されたフォーカスマネージャを使わないといけない。具体的には以下のようにする。

var FocusManager = Cc['@mozilla.org/focus-manager;1']
                   .getService(Ci.nsIFocusManager);

// 現在フォーカスされている要素を取得する。
// 第1引数：検索する最上位のDOMWindow
// 第2引数：再帰的な検索を行うかどうかのフラグ（trueを渡す）
// 第3引数：その要素が含まれているフレームのDOMWindowを
//          受け取るためのスロットとなるオブジェクト
var focusedWindow = {};
var focusedElement = FocusManager.getFocusedElementForWindow(window, true, focusedWindow);

// 現在のフォーカスが何によって与えられたかの情報を取得する。
var reason = FocusManager.getLastFocusMethod(focusedWindow.value);

// フレームにフォーカスする。
focusedWindow.value.focus();

// フォーカスされていた要素がある時は、その要素にもフォーカスする。
if (focusedElement) {
    // フォーカスを与える時に、スクロール状態等に変更を加えないように指定する
    let flags = Ci.nsIFocusManager.FLAG_RAISE |
                Ci.nsIFocusManager.FLAG_NOSCROLL |
                Ci.nsIFocusManager.FLAG_NOSWITCHFRAME |
                reason;
    FocusManager.setFocus(focusedElement, flags);
}

こうすれば、Linuxでも要素のフォーカス状態を失わせずにウィンドウを最前面に持って来れる。ウィンドウのフォーカスを動的に切り替えるため、その都度各ウィンドウが画面上でぺかぺか点滅してしまう（一瞬だけフォーカスされて、その直後にフォーカスが失われるため）、というデメリットはあるが。

XPIファイルのパッケージングの仕方を工夫してもあんまり報われないという事が分かった（僕の場合は） - May 30, 2011

先に結論だけ。

• アドオンの規模にもよるだろうけど、僕の場合、XPIパッケージの作り方の工夫は大したパフォーマンスの向上には繋がりませんでした。
• アドオンをインストールした時にFirefoxの起動がどれくらい遅くなるかのパフォーマンス計測の仕組みをMozillaが用意してくれているので、みんなそれを使うといいです。

---

Firefoxの起動を遅くするアドオンランキングなんてものが公開されて、そこにツリー型タブも堂々ランクインしてて、「多機能オールインワン型アドオンを散々批判してるくせに単機能とか言ってるお前のアドオンの方がよっぽど重てーじゃねえかﾌﾟｹﾞﾗ」的なコメントも見受けられる昨今（僕はメンテナンス性とか共存のしやすさとかの観点から多機能型を否定しているつもりなので、ある単機能のアドオンが必ずある多機能のアドオンより軽いはずだとかそんな事は言えないと思っているのですが）、皆様いかがお過ごしでしょうか。

自分はわりと富豪的なプログラムを書く方なので、欲しい機能を実現させるためにいろんなイベントを監視したり、メンテナンスしやすくするためにファイルを細かく分けたり、とかそういう事をやりがちなのですけれども、そういうのって一般的にFirefoxの起動とか動作とかを遅くさせるからやめなさいよというメッセージを、Mozillaは最近アドオン開発者に向けてよく発しています。上記のランキングもその一環ですね（あんまり遅いとこうして晒し挙げるぜ、という）。

• Mozilla、Firefoxのアドオンによる減速を回避する取り組みを発表 - ITmedia ニュース
• Mozilla、Firefoxの「遅いアドオンのランキング」公表、高速化に向け取り組み -INTERNET Watch
• Improving Add-on Performance | Mozilla Add-ons Blog

で、その晒し挙げランキングのページからパフォーマンス改善の色々なテクニックがリンクされていて、これ読んで出直して来いよ、出直してこないならペナルティだぜ、という話なんですが、そのページの末尾でTalosというパフォーマンス測定ツールを使ってアドオンがFirefoxの起動速度に与える影響を計測する手順も紹介されてました。上記の晒し上げランキングもこれで計測した結果に基づいてるみたいです。

晒し上げランキングの中でツリー型タブがWindows XPで99％ Slow（Firefoxの起動にかかる時間が2倍になる）と書かれてて、いくら僕でもちょっと信じがたかったので、実際に自分でもTalosを使ってパフォーマンス計測を試みてみました。僕が試験用に用意したWindows XP環境では、ツリー型タブ0.11.2011050602とNightlyとの組み合わせで35％前後という数値が出ていますが、これはランキングに出ている数値と大きく隔たりがあります。どういうことなんでしょうね。

まあそれはどうでもいいんですよこの際。とにかくこれが契機となって、自分の環境でもアドオンがFirefoxの起動速度に与える影響を機械的に測定できるようになったので、今後のパフォーマンス改善にはこれを1つの指標として使っていこうと思ってるわけです。

---

さて、そういう背景があってツリー型タブのリポジトリ上の最新版では、主要なコードをJavaScriptコードモジュール化してみたり、関連ライブラリの読み込みをXPCOMUtils.defineLazyGetter()でやるようにしてみたり（この機能はFirefox 3.6以降でしか使えないので、自動的にツリー型タブの次のリリースはFirefox 3.5対応を切り捨てる事になります）、読み込ませるスタイルシートの数を大幅に減らすようにしたり、ついでに属性セレクタの使用を減らしてみたり、という風な、アーキテクチャに変更が無い範囲で前述の「パフォーマンス改善のためのテクニック」を色々と取り込んでいるのですけれども、まだ実施していない項目の1つに「XPIパッケージの作り方を工夫する」という物がありました。

XPIパッケージというのは、アドオンを構成するファイル一式をZIP形式で圧縮した、配布用のパッケージです。Firefox 3.6までは、アドオンをインストールするとこのXPIパッケージが自動的に展開されて、ユーザのPCのストレージ上に個々のファイルが配置されるようになってました。ただ、ファイルの数が多いとFirefoxの起動に時間がかかるようになってしまうためとか諸々の理由から、XULファイルやCSSファイルやJavaScriptファイルなどはJARファイル（これも実態はZIP形式の書庫ファイルです）にまとめておいて、見かけ上のファイルアクセスを減らす事が推奨されていました。

JARファイルにせよXPIファイルにせよ、圧縮率を高くすればするほど中身を取り出すのには余計な時間がかかる事になります。なので、ユーザの環境にインストールされた時に1回だけ展開されるXPIファイルは圧縮率を最高にして保存して、インストールされた後も毎回中身を参照されるJARファイルは無圧縮で保存する、という事によって配布ファイルのサイズを小さくすると同時に実際の使用時のパフォーマンスも高く保つ……というのが従来のXPIファイルの作り方の定石でした。

ところがFirefox 4以降、パフォーマンス改善の一環として、Firefoxの構成ファイルは可能な限り1つのJARファイルにまとめられるようになりました。これは「omnijar」と呼ばれている新機能で、今まではバラバラのファイルとして配置されていたJavaScript製のXPCOMコンポーネントやJavaScriptコードモジュールまでも、他のXULファイルやCSSファイルのようにJARファイルの中に格納してしまって、更なるパフォーマンスの向上を実現しようというわけです。

Firefox 4本体がそうなったのに併せて、アドオンにもomnijarの仕組みが使われるようになりました。今までならXPIファイルをインストールしたらその中身を常に展開するようになっていたのが、Firefox 4でアドオンをインストールした場合は原則としてXPIファイルのままで保存されて、中身にはomnijarの仕組みでアクセスするようになったんですね。

ここで3つの問題が起こります。

1. XPIの中にあるバイナリ形式のコンポーネントをそのまま使う事はできない。
2. XPIファイルはインストール時に1回だけ展開される事を想定して最高の圧縮率にしている。毎回の起動時にその都度展開されると、その分余計な時間がかかる事になる。
3. XPIファイルの中にJARファイルが格納されている、という入れ子構造のままで毎回使われる事になる。これもその分余計な時間がかかる事になる。

1については仕様上の制限という事で、こういう場合だけはFirefox 3.6の時と同様の形でXPIを展開した状態にしてインストールさせる必要があります。install.rdfにem:unpack="true"という指定を書き加えると、アドオンのインストール時にXPIファイルが展開されるようになります。

2と3はパフォーマンス低下の問題です。前述の「パフォーマンス改善のためのテクニック」では2と3を理由として、無圧縮JARに固めてから最高圧縮率のXPIを作るのではなく、中身をJARに固めないで全体を圧縮率の低いXPIに固める（アーカイブを入れ子にしない）、という事が推奨されています。

しかしこれは見ての通り、Firefox 3.6以前のバージョン向けの定石と全く相反しています。Firefox 4のためにFirefox 3.6でのパフォーマンスを犠牲にするか、Firefox 3.6のためにFirefox 4でのパフォーマンスを犠牲にするか、どちらかを選ばないといけないという事になります。

---

でも、ほんとにそうなの？　Firefox本体くらいの規模ならいざ知らず、それより遙かに小規模なアドオンでXPIファイルの作り方がそんなに起動速度に大きな影響を与えるの？

という事が気になったので、ツリー型タブのリポジトリ上のHEADでパッケージングの仕方だけを変えてTalosでパフォーマンスを計測してみました。結果は以下の通りでした。

パッケージングの仕方	1回目の結果	2回目の結果	3回目の結果	平均	余計にかかった起動時間	起動時間の増加率
（アドオン無し）	2029.53msec	2091.58msec	2058.53msec	2059.88msec	0	-
無圧縮JAR＋圧縮率最高XPI	2354.05msec	2341.63msec	2279.21msec	2324.96msec	265.08msec	12.87％
無圧縮JAR＋圧縮率最高XPI＋em:unpack="true"	2327.0msec	2314.84msec	2337.63msec	2326.49msec	266.61msec	12.94％
無圧縮XPI	2287.58msec	2380.79msec	2331.26msec	2333.21msec	273.33msec	13.27％

数値が物凄く大きいのは、試験環境がシングルコアなCeleronの上で動いてるVirtualPCの上で動いてるWindows XP SP3だったからです。無圧縮XPIは上記の「Firefo 4向けの推奨されるやり方」ではないのですが、CPUが低速なら展開に時間がかからない方が有利なんじゃないかと思ってそうしてみました。

表を見ての通り、XPIの作り方で劇的に起動速度が変わるという事はありませんでした。少なくともツリー型タブ程度の規模では、XPIファイルの作り方の違いを変えてもFirefoxの起動速度は大して早くならない、ぶっちゃけ好きなようにやればいいという事が言えると思います。

ちなみに、繰り返しテストする前に試験実行した時にはそもそもFirefox自体の起動時間が600ミリ秒ほど短い1400ミリ秒ほどであるという結果が出ていました。その時の計測結果も以下に記しておきます。

パッケージングの仕方	テスト実行時の結果	余計にかかった起動時間	起動時間の増加率
（アドオン無し）	1411.26msec	0	-
無圧縮JAR＋圧縮率最高XPI	1730.58msec	319.32msec	22.63％
無圧縮JAR＋圧縮率最高XPI＋em:unpack="true"	1718.05msec	306.79msec	21.74％
無圧縮XPI	1779.53msec	368.27msec	26.10％

これを見ると、ツリー型タブがある時に絶対的に何ミリ秒余計な時間がかかるのか？という点では、先の表と併せて見ても、だいたい常に300ミリ秒くらい起動に余計に時間がかかってるみたいだという事が分かります。Firefox自体の起動が300ミリ秒くらいで済む環境でテストすると、ツリー型タブのせいで起動時間が2倍かかるようになると考えられます。もしこれが事実なら、上記の晒し上げランキングの元データは結構高速なマシンで計測した物という事になるのかもしれません。

---

結論としては、XPIファイルの作り方を見直すなんてのは最後の最後でいいと思います。それよりもアーキテクチャの変更とかの方が多分ずっと高速化には効きます。実際、ツリー型タブのここまでの改善の中では、レイジーゲッターとかJSコードモジュール化とかよりも、読み込んだまま使ってなかった大量のスタイルシートを必要最小限だけ読み込むようにして@importを減らしたりセレクタを単純化したりした時の方が、大きな数値上の差が出てたと思います。

あと、このエントリ内での計測結果がおかしいと思う人は自分でPythonとTalosとNightlyを用意してパフォーマンス計測をやってみるといいです。こういう物が既にある以上、今後は、数値による裏付けが無い「遅い」「重い」といった類の話は無視しちゃっていいと思いますよ（動作時の速度についての言及は除く。上記の文書で解説されてる手順で計測できるのはあくまで起動にかかる時間だけで、メニューを展開したりタブを切り替えたりといった操作のパフォーマンスまでは測定してないので）。

Firefoxと自分の関係を見直す - May 07, 2011

Twitterとかでポロポロこぼしてるのをまとめておきたいと思ったのでまとめることにした。要点だけ先に書いておくと、以下の3点。

• Firefoxが世の中に受け入れられてたのは、オープンソースだからでもWeb標準だからでもなく、単純に「無料で手に入り、必要十分な機能を持ってて、ヘビーユーザの使用にも耐えるポテンシャルを持った、良いアプリケーションソフトウェア」だったから。
• その点において世の中の関心は既にGoogle Chromeに移っている。
• 今でもFirefoxにこだわってる人は、おそらく時代を読めてない（でも敢えてそうしてる所が多分ある）。

---

何度も書いてる話をまた繰り返すんだけど。

僕がMozillaに肩入れしだしたのは、僕がW3C信者で、Geckoエンジンが当時一番マシなCSS2の実装を持ってた（ように僕には思えた）からだった。ポジショニングがちゃんと仕様通りにできて、疑似要素とかも使えて、スタイルシートWebデザインで語られていた「あるべきWeb」を実現してくれる物だ、という風に僕は思ってた。

そのうち僕はMozillaの拡張機能開発にのめり込んでいったんだけれども、のめり込む中で「Web標準は世間知らずの学生やら学者やらが語るだけのオモチャで非現実的な絵空事、なんかでは決してないという事を証明したい」「プラットフォームを選ばずWeb標準技術でアプリケーションソフトウェアを作れるという事そのものが、その証明になる」という思いをだんだんと強めていった気がする。その後でUIがどうとか色々加わったものも有るんだけど、発端にあって且つ今もある核の1つであることは間違いないと思う。

そうこうするうちにオープンソースというキーワードから就職が決まり、「オープンソース素晴らしい！」的な言説にそれまでよりも沢山触れるようになった。Mozillaも、「Firefoxはオープンソースだから多数の目によって監視されていて品質が高い」とかのアピールをよくしてた。Firefoxのシェアがちょっとずつ増えていって、「オープンソース素晴らしい！」「コミュニティ素晴らしい！」「バザール！」「カスタマイズ性が高いのって素晴らしい！」的な言説にもさらに多く触れるようになった気がするし、自分でもそういう事を言うようになった気がする。

• Web標準技術に基づいているという事。
  • 仕様が特定のプラットフォームの習わしに囚われていない。無色透明である。
  • Webの礎を作った人達のお墨付きである。
• オープンソースで、全てのコードを見られるという事。
  • トラブルの原因をとことん調べられる（根気さえあれば）。
  • 既存のコードを参考に派生物を作れる。誰にも気兼ねせず、恐怖に怯える事もなく、安心して成果物を公開できるし他人の成果物も取り込める。
  • 誰でも関われる。コードを書くだけでなく、検証したりバグを立てたりドキュメントを整備したりといった、自分にできる形でプロジェクトに参与できる。
• カスタマイズ性が高い事。
  • 使っていて不満に思う所があれば、かなりの程度自由に挙動を変えられる。
  • 愛用の道具に少しずつ手を加えていく、秘密基地を少しずつ整備していく感覚で、居心地の良い空間を作っていける。

こういうものがMozillaの、Firefoxの価値だと僕は思うようになっていた。

Mozillaの拡張機能を開発する中で僕は、それなりの評価を世間から得る事ができた。Firefoxが世の中で受け入れられていく中で、僕の成果も評価されていった。W3C信者でCSSコミューンで啓蒙啓蒙と息巻いていた頃に抱いた「どうしてこんな素晴らしい物を皆分かってくれないんだ」という鬱屈、運動ができず特段勉強ができるわけでも人気者でもない自分がメインストリームの人達を横目に休み時間机に俯せていた時に感じていたやるせなさ、朝礼での表彰だとかトロフィーだとか優勝旗だとかに憧れながら無縁のままだった口惜しさ、そういった物から僕は解放されたような気がしていた。

僕は、僕を救ってくれたモノの事を、僕自身の存在意義をも仮託して支持するようになっていたのだと思う。

---

ただ、世間がFirefoxを評価していた最大の理由は、そういう事とは全く別の所にあったんだな。

世間が評価したのはあくまで、Ben GoodgerやDavid Hyattといった人達が「こういうブラウザがあったら使いやすくて便利なのに」と思ってスカンクワークス的にユーザ視点で作ったアプリケーションソフトウェアとしてのPhoenix、そしてその血を引くFirefoxだった。これは多分間違いない。

オープンソースだとかWeb標準だとかは、ある意味ではオマケの要素に過ぎなくて、ある意味では「今時そうであって当たり前だろ？」っていうレベルの話でしかない。カスタマイズ性だって、別にFirefoxのやり方でなきゃいけなかったなんて事は全然無くて、というかFirefoxのやり方（不安定且つドキュメント不在のAPIの山で、全てが個々人のアドオン開発者に丸投げ）なんて下策もいいとこで、結果的に「フツーの人」や「ヘビーユーザ」が欲しい機能が手に入るのであれば、それは安定したAPIと開発を支援する仕組みによって実現されるものであっても何ら問題ないどころか、そうであった方がユーザのためにも良い。

「必要なのはこの機能だ」「こんな機能は不要だ」といった判断を下して方針を定めて1つのビジョンの元に形作られたからこそ、Firefoxには「使いやすくて便利だ」という分かりやすいメッセージが備わって、小難しい事になんか興味の無い普通の人にも受け入れてもらえてたんだと思う。

---

つまり、こういう事だ。「オープンソースでWeb標準」なMozillaが元々そこにあった。その中から「便利なアプリ」のPhoenixそしてFirefoxが産まれてきて、その「便利なアプリ」に惹かれていろんな人が寄ってきた。でもそのうちに「便利なアプリ」を作った中心人物達はMozillaを去って、AppleやらGoogleやらに行ってしまった。そして彼らはそこでまた別の「便利なアプリ」を作り始めた。今またその「便利なアプリ」が新たにいろんな人の関心を集めている一方で、「便利なアプリ」を産んだ中心人物達がいなくなったMozillaにはFirefoxには、多くの人の関心を集める材料たり得ない「オープンソースでWeb標準」という部分だけが残された。

「今まで使ってたFirefoxの新しいバージョンが入ったから使ってみたけど、重くてヤダ。これだったらGoogle Chromeっていうの？　こっちの方がいいや。」カジュアルにFirefoxを使い始めた人は、こうしてカジュアルにFirefoxから去って行っている。今Firefoxについて行っているのは、その残された部分に元から惹かれていた僕のような酔狂な人間と、Firefoxやそのアドオン（特にTab Mix Plusあたり）にロックインされて他に移れなくなってしまったドン詰まりの人間だけだったりするんじゃないのか。

さらに言うなら、前述した通りオープンソースもWeb標準もカスタマイズ性も今となっては「どのプレイヤーも備えていて当たり前の、最低限の要素」となっているのだとすれば、Firefoxに残された部分にすら何ら特別な独自性は無いという事にはならないか？

---

他のプレイヤーが持ち得ない全く独自のカラー、進むべき道を指し示す分かりやすい「方針」「指針」を持てないと、Firefoxの衰退のスピードは加速する一方なのではないか。

Ben GoodgerらがPhoenixをスリムに作れたのは、彼らに「こういうものを作りたい」という思いがあったからというだけでなく、スカンクワークスとして余計な横やりに晒される事無く初期の開発を進める事ができたからではないだろうか。まだ世の中のどこにも無いまだ見ぬ「より良い物」を求めて最先端をひた走っていたからこそ、そういう事ができていたのではないか？　10年来の「Mozillaユーザ」といったしがらみに囚われて、船頭多くして船山に登りまくりになっているようにも見えるFirefoxが、他の模倣・後追いではない独自の「最先端」を切り開いていく事は可能なのだろうか？

FirefoxボタンやApp Tabやステータスパネルといった新機能の導入は、OperaやChromeといった競合製品の猿真似に過ぎなかったりはしないか？　Microsummariesやプロファイルマネージャの廃止は、「アンケート調査の結果」という一見するともっともらしい数字を楯にした思考停止だったりはしないか？　受け身に徹していたりはしないか？　そこにビジョンはあるのか？　一本筋の通ったストーリーはちゃんとあるのか？

……というかそもそもの話として、「進むべき方向が分からない。プロジェクトが生き残るために、進むべき道を定めなければ。」なんて考え方をしてるなら、その時点でもう終わっちゃってるとも思う。進みたい道があるから進む、その道を進むためにプロジェクトを立てる、それが当たり前のあり方だ。組織の自己保全が目的となった組織の末路なんて、今更語るまでも無い。プロジェクトの自己保全が目的となったプロジェクトだなんて、一体何の冗談か。プロジェクトとしての役割を果たし終えたのであれば、プロジェクトは解散しないといけない。

Netscapeのための「無償労働力集めの場」ではなくなったMozillaプロジェクトの目的は、一体何なのか。その目的はまだ達成されきってなどいなくて、今も果たし続けなければならない物なのか。The Mozilla Manifestoが「何かを言っているようで実は何も言っていない」言い訳などではないなら、ここから演繹される物がFirefoxの進む道なのだろう。

その道に、僕はどのように関われるのか。あるいは、どのように関われないのか。もうすぐ三十路に突入する僕は、個人的な承認欲求が満たされるかどうかといった話に留まらず、仕事上での関わりも含めて、いいかげん真面目に考えないといけないという気がしている。

リゾット作った - Apr 24, 2011

おじやだか雑炊だかを作った後に連続で同じ物をというのも気が引けたので、趣向を変えてリゾットにしてみる事にした。簡単に作れるリゾットの素というのが世の中にはあるらしいと聞いていたんだけれども、行ったスーパーにはそういうのがなかったので、クックパッドのレシピを見ながらやってみる事にした。

• ベーコンときのこの簡単リゾット♬ by jmari [クックパッド] 簡単おいしいみんなのレシピが97万品
• 簡単キノコのクリームリゾット by リナセナ [クックパッド] 簡単おいしいみんなのレシピが97万品

1つ目の物を基本として、2つ目の方に出てきていたタマネギを加えた事と、もう少し野菜を入れるかと思ってニンジンを加えた事と、使ったバターが無塩バターだった事、あとパセリがなかった事が違い。

チーズは、前に何か作った時に買ったチーズがずっと残ってたのでそれを使った。このリゾット（風の何か）だったらそう手もかからないので、使い切れそうな気がしてきた。

js-ctypesで期待した通りにガーベジコレクトされてくれないから自分でmalloc/freeする - Mar 27, 2011

最初に要点だけまとめておくと、

• js-ctypesを使う時は、JavaScriptのコード側では基本的にメモリの管理のことは考えなくてもいい（ガーベジコレクト任せにしていい）事になってる。
• しかし実際使ってみると、JavaScriptからjs-ctypes経由で自分でmalloc/freeしないとどうにもならないという場面があるみたい。
• なのでJavaScriptからjs-ctypes経由でmalloc/freeする方法とその実例を紹介する。

という話です。

続きを表示する ...

64bit整数を使わないという、js-ctypesの最適化ノウハウ - Mar 27, 2011

先に結論だけ書くと、

• js-ctypesでCのライブラリから帰ってきた64ビット整数を32ビット整数2つで代用できる場面では、32ビット整数にしておいた方が何倍も速くなることがある。
• ctypes.uint32_tとctypes.unsigned_longが同じ意味になる場合（Win32/Win64など）はctypes.uint32_tを使った方がいい。

という話です。以下、実際にどういうケースでこれが役立つかの説明です。

続きを表示する ...

rmで消してしまったファイルやSambaで共有してるフォルダの中身をWindowsから消してしまった場合の復活 - Mar 24, 2011

僕は会社では主にUbuntuを使用しているのですが、Sambaで共有してるフォルダの中にあったThunderbirdのプロファイルっぽい物を「あれ、これテスト用に作ったやつだっけ」と思ってWindowsから削除してしまった後になって「あ、これメインで使ってるThunderbirdのプロファイルへのシンボリックリンクやがな」と気がついて慌てて止めたものの、時既に遅しでメールフィルタもなんもかも消えてしまった。せめてNautilusからの削除だったらゴミ箱に残ってたのに……！

Thunderbirdは起動した状態のままだったので、設定エディタを開いて適当な設定値をいじって、一番重要なprefs.js（アカウント情報が入ってる）だけは書き出させた。アドレス帳は全く使ってないに等しい状態だったので、消えても構わない。メールフォルダの中身も、IMAPで自宅・サーバ上・このPCの3箇所で同じ物を複製しあってる状態だったのでなんとかなる。しかし、このPCでしか設定してなかったメールフィルタが消えてしまったのは痛い。

ということでなんとかundeleteする方法はないかと検索したら、extundeleteというのを使えばいいらしいという事が分かった。

• Linuxでうっかりrm -rfしちゃったけど復活出来たよー＼(＾o＾)／ - y-kawazの日記

試してみたらかなりの数のファイルを救出できたけど、なんやかやで一部壊れてる物もあった。とりあえず目当てのメールフィルタは無傷で救出できたので、なくさないようにDropboxに入れて自宅にもコピーを置いておこう……

js-ctypes - Mar 20, 2011

js-ctypesはFirefox 3.6から利用できるMozillaの独自の機能で、平たく言うとC言語の実装の中で定義された関数をJavaScriptから呼べるようにするという物。Pythonにctypesという機能があって、それのJavaScript版がjs-ctypes。

• 加藤誠さんの発表のスライド資料
• Using js-ctypes：MDCのチュートリアル

Firefox 3.6（Gecko 1.9.2）ではできる事の制限が厳しかったので使えるケースがあんまり無かったようなんだけど、Firefox 4（Gecko 2.0）では構造体がサポートされたので一気に使える場面が増えた。らしい。

システムモニターをFirefox 4に対応させなきゃねと思ってたんだけど、Compartmentがどうとか色々変更があったのを全部調べてたら絶対自分の手に負えん！！と思ったので、いっそのことjs-ctypesで実装すりゃいいんじゃね？　と思って、試行錯誤しながらやってみてる。試行錯誤の様子はリポジトリを見るとバレバレです。

js-ctypesのいい所：

• コンパイルしなくていい。SDKやらビルド環境やらを整えるのに苦労しなくてもいい。
• 単にバイナリを用意できてないだけで、その環境でバイナリをビルドしさえすれば大丈夫なのに……って場合には、多分そのまま動く。（動かない場合もある）
• CとJavaScriptの境界で動作するコードで考えなきゃいけなかった諸々の事（JavaScriptのコンテキストがどうだとか、nsIVariantを経由したりJSObjにしたりとか、いろんな事）を考えなくてもいい。

困った所：

• 結局はCなので、C言語が分かってないとどうしようもない。（僕はjs-ctypesでちょっとC言語への理解が深まりました……）
• Cでの開発だったらヘッダファイルをインクルードすればそれでいいという場面でも、js-ctypes用に構造体の定義をJavaScriptで全部書き直さないといけない。
• 取得した値が数値になってると思って「+」演算子で計算しようとするとハマる。数値を返すような関数でも返ってくる値はjs-ctypesによってラップされたオブジェクトなので、「+」演算子で繋げると文字列連結になってしまう（「-」などの、数値型に暗黙のうちに変換する演算子であれば問題は起こらない）。
  • 必ずparseInt()する、みたいな癖を付けとくとハマらなくていいと思う。
• JavaScriptの書き方が悪くてJITされてないせいもあるのかもしれないけど、ループが遅くいからか、Cで書くよりずいぶんパフォーマンスが落ちる場面がある。メモリ消費量の計算だけでCPUを20%近く使っちゃうことになったりとか……

JavaScriptでFirefoxをクラッシュさせたかったらjs-ctypesでメモリ破壊とかやると手っ取り早いですよ！　と、数え切れないほどFirefoxをクラッシュさせて思いました。

msysGitが動かなくなった - Mar 18, 2011

しばらくぶりに帰宅して、さあ外出先で行った開発の結果を取ってきましょうと思ってgit pullしようとしたら、bashが起動しなくなってた。

背景を説明すると、僕は自宅ではWindowsを使ってて、Gitを使った開発にはTortoiseGitとmsysGitの組み合わせを使用しているのですが、普段は全然普通に使えてるのに今日になって急にそれが動かなくなってたという状況でした。どうもTortoiseGitが内部的に呼び出してるCygwinのbashが動いてないようで、bash単体で起動しようとしてもこんな風なエラーが出てしまってすぐにプロセスが落ちてしまいます。

      0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x68540000, RegionSize 0x70000, State 0x10000
C:\Program Files\Git\bin\bash.exe: *** Couldn't reserve space for cygwin's heap,
 Win32 error 0

で、エラーメッセージを頼りに何か情報が無いかとGoogle先生に聞いてみた所、同じようなエラーが起こって困ってる人が結構いるみたいだったんですが、そこで紹介されてた以下の2つの対処法は僕の環境では効果がありませんでした。

• msys-1.0.dllを入れ換えてみる
• レジストリを編集してみる

諦めずにさらに探してたら、MSYSの謎のエラー - メモ@wantoraというエントリで紹介されてた方法でうまくいきました。

>cd "c:\program files\git\bin"
>rebase -b 0x30000000 msys-1.0.dll

rebaseというのはひょっとしたら普通は入ってないかもしれません。自分はFirefoxのビルドのためにWindows SDKというのを入れてましたが、それに付いてきてたのかもしれません。リンク先のエントリによるとWindows SDK for Windows Server 2008 and .NET Framework 3.5を入れると付いてくるようです。

rebaseってなんやねん、git rebaseとは違うのか、と思って検索してみたら以下のような記事が出てきましたが、読んでもよくわかりませんでした。

• DLL Hell の終焉
• モジュールのロードを高速化する方法
• dllとベースアドレス - 新日々此何有哉

「巻き戻し/早送りボタン」でクラッシュする件 - Mar 16, 2011

14日くらいから、Rewind/Fastforward Buttonsを入れてるとFirefoxが頻繁にクラッシュするという現象が発生するようになっているようです。wedataのAutoPagerize用データベースに新しく追加された項目がトリガーになって、長すぎる正規表現か何かの制限に引っかかるようになってクラッシュしているものと考えられます。問題としては認識しているのですが、現在修正のための時間を取れない状態なので、アドオンを無効化するか、about:configで以下の設定を変更して回避して下さい。

• rewindforward.related.use.siteInfo →falseに変更
• rewindforward.siteinfo.importFrom → ""（空文字）に変更