Latest topics 近況報告

DOM2 Eventsの機能でアドオン同士を連携させる方法 - Dec 27, 2009

ツリー型タブに他のアドオン向けのAPIを加えていきたいという話を書いた関係でコードをあちこち見直して書き直していて、カスタムイベントを通知→イベントを捕捉した側でキャンセル→イベントを通知した側でキャンセルを検知して処理を中断　という事をやりたくなって調べた結果をmodestにまとめてみた。

• 機能が呼び出されたことを他のアドオンに通知する
• 機能を他のアドオンからキャンセルできるようにする

ここに書かずにmodestの方に書いたのは、話のレベル的に今更感があったのと、わりと基礎的な話だからこんな世界の果てのオメガギークの日々の下らない愚痴に混ぜて書くだけにしたら誰にも見てもらえないんじゃないか（それよりももっと多くの人に読んで貰って取り入れてもらって、アドオン同士の連携を取りやすい世の中になってくれると嬉しい）と思ったというのと、というあたりが理由です。

でもなんかほんと今更過ぎるというかものすげえ基本的なことを得意げに解説してしまった気がしていて、失敗だったかなあとちょっとブルーです。

ツリー型タブとTabberwockyを同時に入れられるようにしたよ - Dec 25, 2009

Tree Style Tab 0.8.2009122501でTabberwocky用のコードを入れました。とりあえず、選択範囲のリンクをタブで開く機能と、新しいタブを現在のタブのすぐ隣に開く機能については、ちゃんと動くことを確認してます。他にうまく動かない機能があったら言って下さい。Tab Mix Plusに比べたら全然コードの量も少ないんで、たぶん対応できると思う。

Tab Mix Plusと組み合わせた時の問題もどうにかしようと思ったんだけど、見てみたらTMPの中にTST用のコードが入ってたので、さっくり諦めた。お互いがお互いに手を出すともはや収拾が付かなくなるから。なのでちょうどいい機会だと思って、TMPのフォーラムに「いいかげんこの状況なんとかしようよ」的な提案を書き込んでみた。そのついでに、ソースコード中で「PUBLIC API」と書いておきながら説明を書き忘れてたAPIをドキュメントに追加した。

他のアドオンと連携を取りやすくするためのAPIを加えるのはやぶさかじゃないので、要望があれば是非言ってください。最近の例では、TreeStyleTabService.currentTabbarPositionやTreeStyleTabService.treeViewEnabledはメールで「こういう事をしたいんだけどどうすればいいのさ」と問い合わせを受けたので追加したAPIです。

クリックされたタブを取得する方法 - Dec 25, 2009

ツリー型タブとClose tab by double clickの競合について報告をもらった。

向こうのコードを見てみたら、タブバーの上でダブルクリックされた時にそのイベントがタブの中で発生したものかどうかを検出するのにevent.originalTargetとそのparentNodeだけを見ていて、ツリー型タブによって追加されたバインディングがあると判別に失敗するようになっていた。これはツリー型タブだけの問題じゃなく、バインディングを加えるあらゆるアドオンと衝突の可能性があるし、テーマによっても衝突する。バインディングに変更を加えなくても、タブの中に何か要素を追加するアドオンは全部衝突する。

いいかげん、こういう時にはDOM3 XPathを使うのが常識になってて欲しいです。こんな所で他のアドオンと衝突する可能性を残す必要はない。

clicked : function(event) {
  if (gBrowser.mTabs.length <= 1) return;
  var tab = document.evaluate(
              'ancestor-or-self::*[local-name()="tab"][1]',
              event.originalTarget,
              null,
              XPathResult.FIRST_ORDERED_NODE_TYPE,
              null
            ).singleNodeValue;
  if (tab) gBrowser.removeTab(tab);
}

こういう風に書けば、クリックされた要素の祖先まで辿って確実に判別できる。他にも絞り込みの条件を付けたければ付けられる。

「シンプルに作る事」と「手抜き」とは、必ずしも一致しませんよね。

画面の描画内容を一時的にロックしておいて、裏であれこれして最後にまとめて描画させる方法の再考 - Dec 24, 2009

画面の描画を一時停止する方法を先日書いたけど、案の定というかやっぱりというか、重大な弊害があることが分かった。また、その弊害にぶち当たらない安全なやり方も見つけることができた。

安全に画面の描画を一時停止・再開する方法は、以下の通り。

var baseWindow = window.top
                   .QueryInterface(Ci.nsIInterfaceRequestor)
                   .getInterface(Ci.nsIWebNavigation)
                   .QueryInterface(Ci.nsIDocShell)
                   .QueryInterface(Ci.nsIBaseWindow);
baseWindow.setPosition(window.innerWidth, window.innerHeight); // これで画面の描画が止まる

gBrowser.addTab(); // これによって起こる変化は画面上に現れない
gBrowser.addTab(); // この変化も画面上に現れない
gBrowser.addTab(); // 同上

baseWindow.setPosition(0, 0); // ここでやっと描画が再開される

以下、前のエントリに書いたやり方にどういう弊害があるのか、および、このエントリで紹介するやり方の方がどのくらい安全なのかについて詳しく説明する。

続きを表示する ...

整形手術 - Dec 22, 2009

僕は、整形手術には（自分がするのも、他人がするのも）抵抗があるのに、歯列矯正には抵抗がない。もし仮に自分に子供ができたとしたら、多分問答無用で矯正させると思う。

はい、何を隠そう僕自身小学校までずっと矯正やってました。ほっといたら酷い受け口（下の前歯が上の前歯よりも前に出る、アゴの出た状態）だったのを、長い時間かけて矯正しました。つまり「生まれつきの、自然に成長した状態」とは明らかに異なる形の顔を、今の僕はしてるわけです。

それって整形手術と同じじゃん。と、唐突に思った。（僕がしたようなマウスピースによる歯列矯正は保険適用外ということなので、扱い的にも「美容整形」と同じ。）

だいたい、成長してからやる歯列矯正ともなるともう完璧に「整形手術」の域だし。骨が固まってるから切って削って貼ってで形を変えてやらないといけない。骨までいじるって、整形手術の中でも相当な部類ですよね。やってる事は整形手術と何も変わらない。やってる事が同じなのに、どうして整形手術はイヤで、歯列矯正ならOKなんだろう。

というところを突き詰めて考えると僕には整形手術と歯列矯正の違いが分からなくなってきて、同じ物なんだったらなんで自分が過去にやった事は肯定する（わざわざ「本来の姿」であるところの受け口の状態に戻そうとはしない）のに他人がこれからやろうとする事は否定する（「本来の姿」を受け入れてそのままで生きることを求める）のかって話になるので、健康その他に害を及ぼさない範囲であれば、整形手術をしたがる人の事を止めてもいい道理が僕には何ら無いよなあ、だったら止められないなあ、と思いました。

追記。歯列矯正は医学的健康的にうんたらかんたらという言い訳は当然僕も考えたけど、他人から見て別にそんなブサイクでもない人が自分の容貌が自分の理想からかけ離れてる事でストレスを感じているというケースでの整形は、心の健康・安定を手に入れるための治療とか予防とかの一種であると僕は真面目に思うんですよ。前にどっかで、整形前でも十分イケメンなのに、整形してなんかオカマっぽい顔になって、でも本人はそれですごく喜んでる、そんな例を見て、美容整形も突き詰めると「本人の健康のため」「QOLを高めるため」なんだなという事を改めて感じさせられた。だから歯列矯正との違いが分からなくなったと書いたんです。

ツリー型タブ0.8.2009122103 - Dec 21, 2009

ツリー型タブはバグをつぶし始めたらきりがなくなってきたので、適当なところで打ち切ってリリースしました。バグ報告への返信で「I'll update as soon.」とか書いちゃったからというのもある。

画面の描画内容をロックするアレについては、結局ライブラリ化しました。window['piro.sakura.ne.jp'].stopRendering.stop()で描画停止、window['piro.sakura.ne.jp'].stopRendering.start()で再開します。複数の機能で停止/再開をネストしても大丈夫なように、呼び出し回数をカウントするようにしてあります。start()し忘れると変なことになるので注意して下さい。

他にもいくつかAPIを追加したので、自作アドオンと連携して動作させてみたい人は参考にして下さい。

画面の描画内容を一時的にロックしておいて、裏であれこれして最後にまとめて描画させる方法 - Dec 18, 2009

ツリー型タブとJetpackが同時にインストールされているとコンテンツ表示領域に何も表示されなくなってしまう、という問題の原因がやっと分かった。そこからさらに調査をして、表題のような「画面の再描画を任意に停止・再開させる」方法が見つかった。

先にやり方だけ書いとくと、こうするとできる。

var rootContentViewer = window.top
                          .QueryInterface(Ci.nsIInterfaceRequestor)
                          .getInterface(Ci.nsIWebNavigation)
                          .QueryInterface(Ci.nsIDocShell)
                          .contentViewer;
rootContentViewer.hide(); // これで画面の描画が止まる

gBrowser.addTab(); // これによって起こる変化は画面上に現れない
gBrowser.addTab(); // この変化も画面上に現れない
gBrowser.addTab(); // 同上

rootContentViewer.show(); // ここでやっと描画が再開される

24日追記。この方法には重大な弊害があることが分かりました。使用を検討している人はより安全な方法を使うようにして下さい。

以下は、これに辿り着いた経緯のお話。

続きを表示する ...

Google Chrome Extensions - Dec 16, 2009

GoogleChromeの拡張を作る上でFirefoxアドオン作者が知っておくべきやればできること « kuでFirefoxアドオンの自由度は奇跡的です。millennium | Google Chrome Extensionsを読んでその奇跡を噛み締めましょう。と紹介されていたエントリを勝手に翻訳してみました。原文の著者は、Firefoxの初期開発チームの一員で、今はGoogleに転職してGoogle Chrome開発チームの一員となっているBen Goodger氏です。

Chromeチームは今日（※訳注：2009年12月8日）、Mac OS XとLinux、そして拡張機能に対応した最初のバージョンをリリースしました。これは、非常に多くの人達の1年間にわたる作業の完成を意味しており、私は開発チームがこの目標を達成できたことを誇らしく思っています。そこで、拡張機能について少し語る機会を設けることにしました。

Chrome拡張機能APIはユーザと開発者に対して、Chromeの核となる原則である「速度」「安定性」「安全性」そして「シンプルさ」を保ちながらブラウザをカスタマイズする能力を提供します。

Google Chromeの拡張機能には以下のようなことができます。

• JavaScript、HTML、CSSなどの一般的なWeb技術によって簡単に開発できます。
• それぞれ別々のプロセスで実行されるため、ブラウザ全体の動作を遅くさせるような問題は起こりません。
• 限定的なAPIを持っており、各拡張機能はブラウザのタブと同様のサンドボックス内で実行されます。
• Chrome自身と同様の自動アップデートの仕組みを使うため、開発者は彼らのソフトウェアの新しいバージョンを容易に公開することができ、ユーザは何もしなくても、最新・最高・最も安全なバージョンにアップデートし続けることができます。

Google Chrome拡張機能についての動画はここで見られます。

私はここしばらくの間、ブラウザの開発に関わり続けてきました。私の話を興味深く思う人もいるでしょうから、拡張機能の歴史について少しお話ししましょう……

かつてNetscapeがNetscape 6（ブラウザ、メールクライアント、ページ作成ツール、そしてIMクライアントのセット）を開発していた頃の要求仕様の1つとして、メールクライアント、IMクライアント、ページ作成ツールといった「選択式の」コンポーネントを含めずにブラウザだけをインストールできるようにする、というものがありました。それらのコンポーネントをインストールした場合は、メールクライアントやIMクライアント等を起動できるようにするために、ブラウザのUIに「追加の項目（メニュー項目、ツールバー上のボタンなど）」が表示されることになります。

NetscapeのフロントエンドはクロスプラットフォームなUI言語であるXULによって実装されていました。選択式のコンポーネントは、それらがインストールされている場合に「追加の項目」を加えられるよう、「オーバーレイ」と呼ばれるファイルを含んでいました。選択式のコンポーネントはそれ自身のオーバーレイや他のロジックを「XPI」ファイルの中にパッケージングされていて、インストールエンジンによってインストールされるようになっていました。

何年か後、Netscapeの後継者であるFirefoxの人気が高まると同時に、開発者達は、前述のようなコンポーネントのインストールのための仕組みを、ブラウザに対して他の機能を追加するためにも利用できるという事に気がつきました。この機能自体はNetscapeの自社製品以外が使うことを全く想定せずに作られていたので、ブラウザのUIの中でどんなAPIが公開される必要があるのかといったことに対しては十分な注意が払われていませんでした。本当に単なる内部的なAPIでしかなかったのです。そのため、人々がFirefox用の「拡張機能」の開発を始めたばかりの頃は、Firefoxに何か変更が行われるとその度に拡張機能のせいでブラウザが起動しなくなるというのが日常茶飯事でした。Firefoxの初期の頃には、ある拡張機能（※訳注：多分タブブラウザ拡張のことじゃないだろうか。というのは自意識過剰？）をインストールしていたユーザにとっては、Firefoxの新しいバージョンにアップグレードする度に「ブラウザにXBLのバインディングが適用されていません」というエラーにぶつかる、といったことも珍しくありませんでした。

Firefoxがバージョン1.0に達する前にこの問題を解決しなければならないのは明らかでしたので、私は拡張機能マネージャをFirefoxに加えることにしました。これは、インストールやアンインストールのためのやっかいなコードを書かなくても済むようにすると同時に、より重要な点として、バージョン管理のための仕組みを提供するものでした。安定したAPIが無い以上、システムは単純に、ブラウザのそのバージョンに対して互換性があると明記されていない拡張機能を無効化します。これは開発者達にとって、新しいバージョンのFirefoxがリリースされるごとに毎回、彼らの拡張機能の動作を保証しなければならないということを意味します。この仕組みは完璧でもないし、煩わしいものでしたが、しかしそれなりにうまくいったため、私達はひとそろいのAPIを凍結させなくてもよかったのです。APIの凍結を急かされていたら、まず間違いなくそれはおざなりな物になってしまっていたでしょう。

Firefoxの拡張機能は常に諸刃の剣です――それは計り知れない柔軟性を提供しますが、その引き替えに、ブラウザがアップデートされるごとに毎回動作確認を取らなければいけないというコストを開発者に対して強います。開発者の動作確認が遅れた場合、ブラウザの新バージョンがでてすぐにアップグレードしたユーザは、しばらくその拡張期能なしで過ごさなければならないか、あるいは、互換性の確認の過程を自己責任で無効化する必要があります。

私はこの歴史についての覚え書きには、面白いというだけでなくケーススタディとしても価値があると考えています。もし、Netscapeのコンポーネント式のインストールのおかげでこのブラウザのカスタマイズのための「裏口」が存在していなかったら、Firefoxに拡張機能の存在自体が全く無かったかもしれないのです。考えてみて下さい。その機能がユーザに愛されたために、Firefoxは成功したのです。これは驚異的な事です。この前例があって、ユーザが拡張機能を愛しているということが分かったので、私達Google Chromeチームは今、カスタマイズ性とChromeの核となる原則とを両立させる最良の物を作るべく、新しいAPIをゼロから作るという贅沢が許されているのです。

Firefoxでの体験は計り知れないほど有益な物でした。私は、Google Chromeの拡張機能の開発に個人的に寄与した数多くの技術者達のうちの1人ではありませんが、しかし、機能をどのように実現するかを検討する事については十分な戦歴があります。私はChrome拡張機能のチームがこのアプローチを取ることを決定した事をとても嬉しく思います。最初のマイルストーンへと私達を導いてくれた彼らに賞賛を！

カード配り問題 - Dec 16, 2009

10分プログラミング - hogehogeを見て、10分でコーディング｜プログラミングに自信があるやつこい！！に挑戦してみました。

結果。コーディング（と検証）だけで6分くらいかかりました。しかもエレガントでもなんでもありません。

function Cards() {
}
Cards.prototype = {
  deal : function(aPlayers, aDeck)
  {
    var result = [];
    for (var i = 0; i < aPlayers; i++)
      result.push('');
    aDeck
      .split('')
      .slice(0, aDeck.length - (aDeck.length % aPlayers))
      .forEach(function(aCard, aIndex) {
        result[aIndex % aPlayers] += aCard;
      });
    return result;
  }
};

var c = new Cards();
alert(c.deal(4, "123123123"));

クラス名がどうとか書いてあったから馬鹿正直にそれに従ってしまったし。

追記。いかん、人数よりカード枚数が少ないときの考慮が足りてなかった。修正した。

1981忘年会に混ざってきたよ - Dec 13, 2009

1981年生忘年会#3に混ざってきました。1983の方によく参加させてもらってたけど、1981の方には行ったことがなかったので、せっかくだから申し込んでみた。

集合場所に着いたら案外人が少なくて「おや？」と思ってたら、既に1次隊が出発済みだったらしい。そこで挨拶した方がクックパッドの方で、先日のFirefox Developers Conferencesにも来られててありがとうございますみたいな話をした（1次会でも同じテーブルに座った）。

• 1次会、坐・和民で100人オーバーだった。
• クックパッドにも弊社代表と同姓同名な「すとうこうへい」さんがいると聞いた。なんという偶然……！
• 店から全員に一人あたり1500円分のお食事券が配られました。ただし500円分を3枚でランチタイム使用不可、1回の利用は1人1枚までなので、使う機会がなさそうで困っています。
• 僕の座ったテーブルは初参加の人ばかりでしかも1981生まれの人がほとんどいなかった。空気読んでなさ過ぎですね！！！
• iPhoneの事とかAndroidの事とか上級SEはエンジニアと言えるのかどうかとか色々話した気がするけどよく覚えてません。
• 2次会の店をamachangが探しに行くというので僕も同行した。人数が多くなりそうだったので見つからないだろうなあと思ってたけど、同じビルの地下の店であっさり決まってよかった。
• 戻ってきた頃にはもう鍋がおじやになっていた……飲み物のラストオーダーも過ぎてた。
• iGirlの人とは1回絡んでおかねばなあと思っていたのでここぞとばかりに挨拶させてもらった。asami81さんもこの辺のことは覚えていらっしゃった。
• 最近よく顔を合わせるdent-de-lionさんとここでも再会した。何このヒット率。

2次会の店は、最初に用意してもらったスペースに全員おさまりきらなかったので別の部屋に主に幹事の人達が溢れる形になっていた。何故か僕もそこに混ざっていた。

• 70人くらい残ったそうだ。
• kiyoheroさんに、はてなハイク2に招待してもらった。つっつかれるとぶるぶる震える仕組みはcho45さんが作ってるとな。つっつかれるとぶるぶる震える仕組みはcho45さんじゃない別の人が作ったそうです。
• あとはてなブックマークブックマーク（ノベルティグッズのしおり）を沢山もらった。
• amachangの上着のボタンが取れたのをasami81さんが縫うのに僕のソーイングセットをお貸ししました。「なんでこんなん持ってるねん」と全員からツッコまれました。独り暮らしなら持ってて変じゃないですよね……？！
• ドワンゴの中の人曰く、糸柳さんはあれで案外常識人で「これ以上やったらヤバイ」という線をちゃんと分かってやってるとのことなんだけど、Web上での彼を見てるとなかなかそうは思えないのが不思議です。
• それ以外に何を話していたのか全然覚えていません。

3次会（徹夜）はまた最初の店に戻る……はずだったんだけど、2次会の店の店長？がよきに計らってくださいまして、2次会の店に併設の別の店を貸し切り状態で使うことになりました。

• 残ったのは20～30人くらい？
• amachangは最近Jython（Python on Java）を書いてるそうで。
  • Java書きづれー！！という魂の叫び。
  • yukobaさん「素のJava言語は今となってはアセンブラみたいなもんで、高速化のためにしか触らないよね」
  • Java書くんだったらeclipseかその元になったIDEは必須でしょという。4～5年ずっとJavaやるのなら1ヶ月かけてでもIDEに慣れておいた方が絶対に生産性が高い。→amachang「1ヶ月だけJavaをやらなきゃいけないんだけど……」→yukoba「それは……諦めるしかないね」
• 西尾さんは今やCGアーティスト→amachang「4次元ってどうなってるの！！」というところから話が膨らんで、空間の歪みがどうとか相対性理論がどうとか原爆の仕組みがどうとか量子論がどうとか対消滅がどうとか量子コンピュータがどうとかそういう話になった。他のテーブルはオナニーがどうとかそいう話で盛り上がっていたのにここだけ何だか空気が違うよ……！！
  • yukobaさんは一時期量子コンピュータに凝っておられたそうで、量子コンピュータとは一体どういう物なのか？　何がすごいのか？　何ができないのか？　といったことを色々教えてもらった。
  • 途中から話に加わって下さった方が物理を大学で専門にやってたそうで、その人も色々教えてくれた。
  • 古典的なコンピュータの上で量子コンピュータをエミュレーションする仕組みは既にあるそうで、それを使って量子コンピュータ用のプログラムをかけるんだとか。
    • evalに相当する関数の名前がmeasure（観測）というそうだ。何故なら量子コンピュータでは観測＝演算だから。
  • 今の量子コンピュータは足し算引き算はできるけど、内積を求めるアルゴリズムが確立されていないそうだ。ものすごい大きな桁の足し算引き算因数分解等が1クロックでできることが量子コンピュータの最大の利点なのに、かけ算ができないんじゃ意味ないよねー。とのこと。
  • 今のCPUの進歩はもう限界が見えてる。1回目の限界はクロック数の頭打ちで、昔は5GHzとか10GHzとかいくと思われてたのに結局物理的現象の限界に阻まれて4GHz前後で止まってしまった。次の限界は微細加工の物理的限界で、トンネル効果で電子が吹っ飛んでしまうようなサイズにまで至ってしまうともうそこでおしまいなのだという。つまりあと10年くらいでCPUの進歩は完全に止まってしまうという。（マルチコアとかは、1つ1つのCPUの性能が上がらなくなったから2個4個まとめて突っ込んじまえという力業でしかない。技術が根本的に進歩したわけではない。）
  • それを解決するのが量子コンピュータだ、と期待されてたんだけどそっちも何だか最初の数年でだいたいの研究が出尽くして今ではほとんど進歩がみられないとか……
  • 代わって脚光を浴びてるのが、電子の流れではなく光を媒体として使う光コンピュータという分野なのだそうで。
• 量子論の話に入る前は、3Dプリンタの話になってた。
  • （マンデルブロー集合とかそういう系のCGの）CGアーティストにとって、3Dプリンタがあるともっと面白いことができるんじゃないか？　とか。
    • 実際、鎖のような構造を継ぎ目無しに作れるのは今の所3Dプリンタくらいのもんだ、とか。
  • 3Dプリンタには、石膏を積層して固めるタイプと、光で固まる樹脂を積層するタイプがある（あとこの場では出さなかったけど、樹脂ブロックからの削り出しタイプもある）。
    • 石膏を使うやつは色を付けられるのが強みで、糸柳ミクも出力時点で色が着いてる。
    • 光で樹脂を固めるタイプは解像度がすごく高くなってる。ミカタンブログでとりあげられてた「パーファクトリー」なんて、鼻血物の緻密さ。
  • amachang「ゲームのキャラをそのまま出力したら面白いんじゃね？」→僕「それもう既にあるよ」
    • というか模型業界では今や、CADからラピッドプロト出力というのが当たり前ですよね。
    • コトブキヤのバーチャロンシリーズのプラモなんて、ゲームのハイエンドCGをそのまま立体出力して、プラモにするためにそこからさらに加工するというステップで作られてる。
    • フィギュアのねんどろいどにもCAD設計の物がある。
• amachangとyukobaさんが抜けた後、物理をやってた人と「こういう話もとても面白かったけど、もっとどーでもいい話もしたかった（笑）」という感じの事を話して、関西地元の深夜番組の話で盛り上がりました。
  • 「おとなのえほん」は当時の男子中学生にはたまらなかった！！とか。
  • 「アニメ大好き」はよいアニオタ養成番組であった、とか。

そんな感じでダラダラしてるうちに朝が来て、忘年会は終了しました。

• 会計の時、全然食べてないテーブルと食べまくってたテーブルとがあったために、amachangを大いに悩ませてしまった。全員で均等割にしたら怒る人出そう……と。
  • 実際僕は均等割にどちらかというと反対だったので、余計に悩ませてしまった。
• 2次会で帰られた方の中に、デスマーチの作者の人がいたんだって……後から知った。

幹事じゃなかったのに2次会以降は幹事を務めて下さって、最後まで頭を悩ませてしまって、ありがとうございます＆すみませんでした。amachang　改めて、彼はとてもいい人だなと思った。人に好かれる人、人が集まってくる人というのはこういう人を言うのだろう、と素直に思える。好奇心旺盛でまっすぐで、嫌味な所がなくて。自分が女だったら間違いなく惚れるね！！！　そのくらいに彼のことがますます好きになった、そんな忘年会でした。