Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
拡張性や互換性を高く保つ設計とか - Apr 25, 2007
AiO GesturesとSplit Browserの連携を試みてみよう、と思って挫折した。基本的にSplit Browserは、Firefoxの初期状態の構造であることを前提にして開発されている拡張機能とは、とても相性が悪い。ハック用のコードを書いてみようと思っても、変更箇所が膨大になりすぎて、とてもやる気が起こらない。FireBugとの連携が結局中途半端な状態で止まってしまってるのもそのせいだ。
Split Browserが連携しやすいのは、Firefox全体に渡ってではなく、tabbrowserというウィジェットに対してだけ拡張を行うように設計されている物だ。マルチプルタブハンドラや情報化タブやなんかは最初からそういう風に設計したので、わりかし簡単に連携がとれるようになった。
情報化タブ - Apr 25, 2007
TBEの分割・再構築の一環で、マルチプルタブハンドラに続いて情報化タブを公開した。
今回、未読タブの強調表示の方法は斜体で決め打ちにした（userChrome.cssでカスタマイズできるけど）。設定UIに凝っても誰も喜んでくれないみたいだから…… 現在のタブを強調表示する機能は、Fx 2のタブだったら最初から現在のタブが判別しやすくなってるから、オミットしてしまった。
これが第2弾なのは、実装に手間がかからないからというだけの理由なんだけど、まあともかく、これでuserChrome.cssを使ってタブを縦置きすれば、とりあえずFirefox 2には移行できるかなー。という感じ。
いちおう旧TBEよりは若干改良してある。
- 画像を開いたタブのサムネイルは、「画像を開いた状態のタブの内容」ではなく「画像そのもの」のサムネイルを表示するようにした。小さい画像を開いたタブも、ちゃんと判別できるようになったはず。これはそのうちタブカタログにもフィードバックしよう……
- スクロールに追従してサムネイルが更新される。これはまああんまりたいしたことないか……
- タブのプログレスメーターを、文字に完全に重ねるのではなく、ちょっとずらして表示するようにした。読み込み中でもタイトルを読みやすくなったと思う。
- サムネイルの表示位置を変更できる。これは、Viamatic Tabnailとの互換性を考えてのこと。元々、Viamatic TabnailがFx 2で動くようならサムネイル関係は自力で実装し直すのは放棄しようと思ってたんだけど、Viamatic TabnailがFx 1.5までにしか対応してなかったので、そっちのユーザさんの乗り換え先にもなれるように、サムネイルの一をTBE風とViamatic Tabnail風で選択できるようにしたというわけ。
TBE for Firefox 2に向けて - Apr 25, 2007
こないだ英語で問い合わせを受けた時に書いた物をここにも転載しておく。
I'm going to split TBE and re-create tiny extensions which can work with other extensions together. This is the first step. I repulsed by old TBE because it is too large, too heavy, and too spaghetti...
I've created the extension above at first because the feature is important just for me. "Tab Tree" feature becomes possibly available next. Currently I'm focusing to satisfying myself, not for other users, so I'm very sorry. However I think this is the best way to solve this huge business (restructuring TBE). When I developed the old TBE, I was a school student, and I could work for users (not for me) like a volunteer service. Now I have less time so I believe that the self-satisfaction-driven development is the way.
I'm planning to release a meta package (a new feature from Fx 1.5, which is an archive of several XPIs and can be distributed as one XPI) of those tiny extensions, as new TBE.
一応、こういう事を言いたかったつもりです、という訳。
僕は今、TBEを分割して、他の拡張機能と連係して動作できる小さな拡張機能として作り直そうとしている。これ（マルチプルタブハンドラ）はその最初のステップだ。僕は古いTBEにうんざりさせられてきた。アレは大きすぎて、重すぎて、あまりにスパゲッティ化していた……
僕が前述の拡張機能（マルチプルタブハンドラ）を最初に作ったのは、その機能が他の誰でもなく僕にとって重要だったからだ。多分次は「タブツリー」機能を提供する拡張機能をリリースすると思う。申し訳ないけど、現在、僕は他のユーザのためではなく、あくまで自分自身の要求事項を満足させることだけに集中している。しかし僕はこれが、TBEの再構築という難題を解決するための一番いい方法だと思っている。僕がかつてTBEを開発していた時、僕は学生で、他のユーザのために自分自身の要求以上のクオリティでボランティアのサービス的に尽くしていた。今ぼくはその頃ほど自由時間が無いから、僕は、自己満足ドリブンな開発こそが、唯一の道だと思っている。
僕は今、そうして開発した小さな拡張機能を一つのメタパッケージ（Firefox 1.5以降の新機能で、複数のXPIパッケージを一つのXPIパッケージにまとめて配布できる）にまとめて、新しいTBEとして配布することを考えている。
マルチプルタブハンドラの次にタブツリー機能を提供する物をリリースするつもりだったんだけど、先に実装の簡単な方から片付けることにしたので、上記の発言は結果的には嘘になってしまったなあ……
Mozilla Party JP 8.0いってきた - Apr 22, 2007
寝坊したから途中から行った。着いた頃にはSeth Spitzer氏の方の話の最中だった。
普段使ってるのが未だにFirefox 1.5で、拡張機能のバグ修正などのテスト環境がFirefox 2という具合なので、ここ最近のXULやGecko方面の動きに関して「アレ、これって2の話だっけ3の話だっけ……」と思うことがよくあるので、現状を把握するのにはとても助かった。ような気がする。
こないだ須藤さんが、cairoの機能でオブジェクトの透明度をいじってずらして複製して擬似的にぼかしを実現するという試みをされていて、すごいけどバックエンドでそれやられても困るよなあ、と思っていたので、たけんさんに訊くのも変かなあと思いながら訊いてみた。なんでcairoにはいつまで経ってもぼかしやドロップシャドウが入らないんでしょうかと。たけんさん曰く、cairoの開発者達はあくまでこれをベクトルベースの描画ライブラリと考えているので、ラスタの描画になってしまうドロップシャドウやぼかしに関しては、どうやらハナから入れる気がないらしいとかなんとか……ってことはFirefox 3でも4でもtext-shadowのサポートは絶望的なんでしょうか。
nanto_viさんには、質疑応答の時間がなかったので、個人的に質問させてもらった。
- E4Xのパフォーマンスについて。DOMでやるのとどっちが速いのか？ ということなんだけど、条件によってはE4Xだと異常に遅くなる事があるらしいとのことで、高速化のためではなくあくまで保守性向上のためにこそ使うのが現状ではベターっぽい。
- E4XのXMLオブジェクトとDOMのノードとの相互変換については、Firefox 1.5以降の環境でなら使用可能。ただし一旦文字列への変換を経由するので、結構重いとかなんとか。
E4XのCDATAマーク区間リテラル（言われてみれば確かにCDATA区間もXMLの仕様の一部なんだよね……）をJavaScriptにおいてヒアドキュメントとして使うという発想はなかったわ。曰く、Brazil氏の所が発祥なんだとか。CDATAマーク区間のXMLオブジェクトはtoString()すると内容の文字列だけが取れるそうで、しかもXULというかChromeウィンドウ内のスクリプトでは特に何も指定しなくてもE4Xが有効だということで、ほんとに普通にヒアドキュメントとして使える予感。
わくらわと空耳のあかつかさんの新作は超ウケた。Firefoxのブラウズ領域を使ったブロック崩しは、まさに技術力の無駄遣いと言えよう。
全ての内容が終わった後、今まで実際には会ったことがなくてネット上でしかやりとりしたこと無かった人とかと話してたんだけど、その時のメンバーがみんな僕より若くて、ちょっと切なくなった。今までは、特にオープンソースとかそういう系の人と顔を合わせる時というのは、大抵の所で「その場の最年少」だったんだけど、それがだんだん最年少でもなくなってきて、気がついたら、自分がもう年長者になってしまっていた、ということが軽くショックだ。
宴会では会場の日本電子専門学校の教員の方と隣の席になって、全然違う世界のことについて興味深い話を聞けたと思う。曰く、専門学校というと、即戦力になる兵士をひたすら養成して量産するような所という性質が強いので、そうして育て上げた人を社会に送り込んで大プロジェクトの歯車にさせてしまうのは若干心が痛む、その点で、この場に集まっている人達は、自分がしてることが全体で言うとどういう位置づけにあるのかとか、自分のしてることの意義だとかをちゃんと分かっていて、すごく楽しそうだ、と。確かに言われてみれば、ほとんど全ての情報に容易にアクセスできて、細部まで把握できるという状態にあると、「俺ってスゲー」感が何故か（特にコアにコミットしてなくても）ある気がする。好きなことやってるから、というだけのことなのかもしれんけど、そういう分かりやすい楽しさって、モチベーションの元になるように思う。
あかつかさんが、内容領域のスクロールバーのツマミ部分の大きさってどうにかして取得できないか、という疑問を持っていらっしゃったんだけど、それはXBLを使った怪しいテクニックで実現できそう。ただ、こんな事するよりは、ページの実際の高さと現在のスクロール位置、そしてビューポートの大きさから算出する方が、たぶんいいとは思う。
その後のカラオケでアイマスの動画で覚えた演歌を歌ったら、組長に「なんであんなん歌えるんだ」とツッコまれてしまった。いや音域的には演歌か古いアニソンでないと歌えなくて、最近の若い男性アーティストのそれのような高い声で歌うのを前提にした曲を1オクターブ低い声で歌っても様にならないから、演歌は歌詞とメロディーを知らないから歌ってなかっただけで、覚えさえすればいくらでも歌うよ、と言ったら、「俺達が苦労してあれなのに、ぴろたんは……」てな風に言われてしまった。
早速更新したのと、タブの複製で思い付いたこと - Apr 20, 2007
マルチプルタブハンドラを更新する中で、思い付いたというか気がついたことなんだけど。
nsISessionStoreを使ってウィンドウやタブを複製する方法って、うまくやればもっと効率よくやれるんだな。getWindowState()で取得した文字列をそのまま使うんじゃなくて、一旦eval()で評価してオブジェクトの形に戻して、不要なタブのデータとかをあらかじめ全部削除してから、もう一度toSource()でJSON風文字列に戻して使えば、無駄なタブを開く→初期化→無駄なタブを削除 という処理をなくすことができる。
ていうかもっと突き詰めれば、ウィンドウ全体の状態を取得した後で、そのデータの中からある特定のタブの状態だけを抜き出して（それ以外を消して）、そのウィンドウ自身に対してsetWIndowState()で「復元」を実行してやれば、タブをウィンドウ内に複製することだって簡単じゃないか。
というわけで、時々自分自身もタブの複製機能を使っていたこともあって、マルチプルタブハンドラにこの機能を組み込んでみた。
Multiple Tab Handler - Apr 20, 2007
昨日一日がかりで作ってた物をマルチプルタブハンドラという名前で公開してみた。
「TBEのFirefox 2用アップデート」というのは敷居が高すぎるというか既に情熱が枯れてしまった僕には荷が重すぎてとても不可能なので、今ある機能のうち特に自分が今よく使っている機能から順番に再実装していくことにした。こいつはその中でも、タブのクローズボックスのドラッグによる選択→まとめて閉じる という操作だけに特化した拡張機能だ。
この機能は元々はiRiderというブラウザの挙動をパクった物で、TBEの機能の中では最も最近加わったやつなんだけど、Firefox 2標準のタブの使い方を勉強するには手頃な規模の物になったと思う。
で、せっかくだから似たような実装で実現できる機能として、タブカタログの「ドラッグして選択→いろんな操作」という挙動も盛り込んでみた。メニューの内容は簡単に追加できるようにしてあるので、これからTBEの機能を分割していった後にも比較的楽にそれぞれを連携できるんじゃないだろうか……と、夢想してみている。
APIはまだちゃんとしたドキュメントは書いてないんだけど、草稿はあるんで、userChrome.jsあたりと組み合わせて誰か使ってみてくれないかなあ。とか。
あと、Tab KillerをFirefox 2向けにアップデートした時に勉強した成果を活かして、Firefox 2のセッション管理機能だけを使って「タブをウィンドウに分割」という機能も入れてみた。
何となく、この規模でこの程度の機能の物は既に誰かがもう作っちゃってるんじゃないかなーという気もするんだけど。どうなんだろ。
ていうか開発初期の数時間くらいの間、名前をどうするか悩んでて、「タブを選択したりまとめて閉じたりするアレ」とかのネタっぽい名前が結構有力候補になってたんだけど、結局こういうモヤモヤしたよくワカラン名前に落ち着いた。まあ、どうせ今頃こんなの作った所でハナから死んだプロジェクトみたいなもんだし、どうでもいいよね……
どうでもいいといえばこれはほんとにどうでもいいんだけど、「マルチプルタブハンドラ」てカタカナで書くと「ハムナプトラ」とか「アルハンブラ」とかそういうのと混乱して困る。
グラフはスコアが52と47の時の物を重ねたもの。風呂 - Apr 14, 2007
僕の入居している部屋は、一応、風呂トイレキッチン付きだ。でも風呂は今時の便利な給湯設備ではなく、ガスの元栓の開け閉めから点火確認、沸かす時間の調節に湯のかき混ぜまで全て人の手でやらないといけない、バランス釜というやつだ。
まあ使い方のコツさえ覚えれば思い通りに運用できてあんまり困らない（車のMTみたいなもの）。入居してから1年間、毎日世話になっている、僕の生活のよきパートナーである。料理する頻度よりこいつの利用頻度の方が明らかに高いし。
ちなみに何故「バランス」と言うかというと、もっと旧型の、ボイラーの吸気を浴室内で行って排気を屋外で行う方式だと、外の風が強かったりすると空気が逆流して上手く動かなかったりしたそうなんだけど、それを改良して、吸排気をどちらも屋外で行うことによって、吸気と排気のバランスが取れるようになった、と。これが名前の由来らしい。
という感じの設備がおそらく全部屋に付いてるんだけど、こないだ隣の人が引っ越していった後にしばらく何か工事をしていたようで、気がついたら、隣の部屋の今までバランス釜の煙突（？）があった場所に、小綺麗でいかにも高性能そうな給湯器が付いていた。どうも、退去者が出て次の入居者が決まるまでの間のタイミングで、設備を更新していくということらしい。ってーことは、ナンデスカ、この部屋も僕が引っ越した後から風呂が新しくなるってことですか。僕はその恩恵にあずかれないわけですか。ぐぎぎぎ！ くやしい！
と思っていたら、今日帰宅したらポストに工事の通知が入っていて、この部屋も含めて全部屋で浴室設備を更新することになったと書いてあった。YATTA！ ぼくんちの風呂も新しくなる！ 不便な風呂とはもうおさらばだYO！（←さっきと言ってること変わってる）
あーでも、バスタブがデカくなるとその分水道代がかかるようになるし、追い炊きができないとますます水道代がかさむし、家計が……せめて追い炊きだけはできるものであって欲しいなあ。
Page Concaterと日経ビジネスオンラインとGreasemonkeyと自動更新 - Apr 13, 2007
複数ページに分かれている続き物のコンテンツを動的に結合して表示するGreasemonkeyスクリプトのPage Concater（バージョン0.10.0）を使っていると日経ビジネスオンラインの記事でうまく動作しないどころか次のページにすら進めなくなってしまった。
concater.REG_BODY = '<div class="articlecontent">(.*?)<!-- /articlecontent -->';
ここを
concater.REG_BODY = '="articlecontent">(.*?)(<!-- /articlecontent -->|<div align="center">)';
と書き換えてみたら、ちゃんと動くようになった。あと、そもそも前後のページがあるということ自体認識できない場合もあったけど、これについては、
el.href.match(/P=(\w+$)/);
ここを
el.href.match(/P=(\w+)(&.+)?$/);
に直したら改善された。
XULとインラインフレームと重ね合わせ - Apr 11, 2007
Split BrowserとGoogle Notebook Extensionがコンフリクトしてるという報告を受けて調べてみた結果のメモ。
XULでは、というかGeckoでは、iframeもbrowserも、インラインフレームについてはCSSのz-indexプロパティの指定とは関係なく、一番最後に描画されたものが一番上に表示されるようになっている。たぶんバグなんだけど、長年そのままになってるから、仕様ということになってるのかもしれない。
Google Notebook Extensionはウィンドウ内にインラインフレームを生成して絶対配置でメインのブラウザ領域の上に重ねて表示してるんだけど、Split Browserで新しいブラウザ領域を追加すると、それがGoogle Notebook Extensionのフレームよりも上に描画されてしまう、というのが問題の現象だ。この問題は分割後の領域でタブを切り替えた際にも発生する。
Google Notebook Extensionのデフォルトの挙動を調べてみると、メインのブラウザ領域については、タブを切り替える度にGoogle Notebook Extensionのフレームを表示し直すようになっていることが分かった。つまりこれと同様に、Split Browserでブラウズ領域を分割した時と、それらの領域内でタブを切り替えたときにも、Google Notebook Extensionのフレームを表示し直してやればいいということになる。
ただ、検証中にさらにもう一つ問題が発覚した。deck要素で内容を切り替えた部分と重なるGoogle Notebook Extensionの領域が白く抜けて描画されてしまうというものだ。deckを使わないようにすればどうにかなりそうなんだけど、そうするとツールバーの高さがガタついてしまうので、どうしたらよいか悩んでいる。