Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
Moezilla Suite、もとい、Moezilla Sweet - Dec 13, 2007
どうにかフルカラー表紙の印刷〆切に入稿が間に合ったので、もえじら組トップを色々更新しました。
今回出す本は、2005年冬コミから2007夏コミまでの間に発表したPiro作品の再録本です。何でも入ってるSuiteにちなんで？、名前は「Moezilla Sweet!」としました。
内容自体は変わってませんが、初出時にトーンを貼る時間が無くて真っ白けだったのがマシになってるとかそういう程度の修正はしてますっていうか今まさに作業を進めております。
分量はもえじら組で最初に出した合同誌と同じ80ページで、印刷部数は300部です。前回はコピー本の新刊が150部出たので、同じだけはければ半数は通販に回せるかなという算段ですが、もう前に読んだからイラネって人が結構いそうだなということを考えると発注しすぎたかもしれません。在庫の山で死んでる姿が目に浮かびます。
あと、再版を望む声がちらほら聞こえてくる最初の合同誌ですが、権利関係の事もあるし在庫を抱えるのもアレだしってことで、PDFかなんかの形式でぱーっと公開しちゃえないかなーとか妄想してます。ほら、まあ、あれは、お祭りみたいなもんだったし。
ところで、表紙絵は線画だけで4時間、彩色で5〜6時間（表紙としての加工にはその後さらに4時間くらい）ってところですか……1枚描くのに平均10時間くらいというのが僕のペースのようです。ニコ動の「描いてみた」系のやつはあんまり見てないのでよく知りませんが、みなさんもっと描き慣れてて速かったりするんでしょうか？ しかし中身はエロ本なのに全然表紙がエロくないので売れ行きが心配です。あまりに健全すぎるので、もうヤケクソで、今までいぬねさんのふぉくす子絵を使ってたバナーやもえじら組トップをこれに差し替えてみました。むしゃくしゃしてやった。後悔はしていない。
緑のgoo - Dec 11, 2007
緑のgoo版Firefoxが今日公開されました。緑のgooは収益の15％が環境保護団体に寄付されるという検索サービスで、緑のFirefoxを使うと普通に検索してるだけで環境保護に貢献できるYO、という物です。
詳しくは配布ページなりITmediaやCNET JapanやINTERNET Watchの記事なりに書いてありますが、要するに、デフォルトの検索エンジンが緑のgooになってて、緑のgooで検索した回数がツールバー上の「gooの木」ボタンに（gooの木の本数換算（検索100回＝gooの木一本）で）出て、おまけに緑のgooっぽいテーマが適用されてる、というFirefoxです。導入済みのFirefoxに全く同じ機能を追加するアドオンも同時に公開されてます。
まあぶっちゃけ、タブが使いやすくなるとかそういう系の実用的なメリットは特に無いっちゃあ無いんですが、損したり面倒な手間をかけたりしないでも普通に検索するだけで環境保護にチョコっと貢献できる、社会的なメリットがあるアドオンというのは珍しいんではないでしょうか。緑のgooのWeb検索のバックエンドはGoogleなので普段ググりまくりの人にも特にデメリットは無いし。ということで僕も今のところデフォルトの検索エンジンは緑のgooにしてます。
なお、他の検索エンジンと併用するためにセカンドサーチも入れておくとより一層便利でしょう（宣伝）。
落ちる - Dec 10, 2007
とよく言われるんだけど自分の環境＆自分の見てる範囲のWebサイトでは落ちないので原因が分からない、ということが多い。落ちるか落ちないかのギリギリの所をうまく突くようなコードを知らず知らずのうちに書いてしまっているのでしょうか。そんな能力いらなさすぎる。
死ぬまでにあと何日 - Dec 08, 2007
親孝行したくなるコピペの中にこんなものがあった。
ところでさ、一人暮らししてる人は年に何日実家に帰ってる？
俺は仕事が忙しくて夏休み3日正月休み3日の、計年間6日位なんだけどさ。俺のｶｰﾁｬﾝ今50歳で、考えたくないけど
女性の平均寿命から考えてあと30数年とするわな。単純計算すると、あと180日位しか会えないことになる。
冷静に考えてみたら、もう半年しかないんだぜ？おまいらも数えてみ？
あと何日ｶｰﾁｬﾝと会える日があるか。
実際には、その「あと何日」はこっちの都合であるいは向こうの都合である日突然0になることもあるわけですがね……
ていうか親子もそうだけど、終わりが決まっていない遠距離やってる人もシャレにならない気がするよ。厚労相のデータでは僕と同世代の男性の平均寿命はだいたい73～4歳ってところだそうだから、僕の余命は50年ないことになる。今年会えた回数は4～5回だから、これで計算すると、ひょっとしたらあと200日程度しかどんなに頑張っても会える機会はないってことになる。まあ死の間際になってくると遠出とかもそうそう出来んだろうし、そもそも死ぬまでずっと関係が続いてるという保証もないから、それを割り引くと半年……いや、2～3ヶ月……いや、もっと短いか？ 仮に「30歳になるまで」だったら、あと5年で、年平均4回なら会う日数は20日、つまりだいたい3週間。
……計算しない方がいいことも世の中にはたくさんあるんだなということがよく分かった
秋葉原 - Dec 02, 2007
友人が出張だか研修だかのために東京まで来ていて、秋葉原も見に行きたいということだったのでせっかくだから同行してみた。
彼の目的の一つはメイドカフェだったのだけれども、そっち方面については僕はどこにどういう店があるのか全然知らなかったので、とりあえず駅前でチラシを配っているメイド衣装の人からチラシを受け取ってみる（僕は恥ずかしいのでとてもそんな事できません）……が……なんかメイドの時間貸しとかそういうのばっかりだった。駅からちょっと離れた中央通りの工事中のビルの前では「メイドカフェでーす」と言っていたけど。
以前別の友人に連れられていった所を記憶を頼りに探してみたけど、それも見つけられなかった。途方に暮れたので、工事中のビルの前でもらったチラシの店に行ってみることにした。地図の指し示している場所の近くをうろついてみるも、それらしい店を見つけられずまたウロウロ……ビルの看板をふと見てみると、明かりはついていないものの、もらったチラシの店名が書かれている。入り口はどこだ？と裏側に回ってみようとしたところで、地下行きの階段と看板を発見。なんだ、上ばかり見てたから全然気付かんかった……後でチラシを良く見てみたら「B1F」って確かに書いてあったけど、歩きながらでそこまで見てなかったから下手したらずっと見つけられなかったかもしれない。
CAFE&BAR VIERGE。ぶっちゃけメイドカフェという時点でそれほど期待はしてなかったんだけど、サンドイッチがかなりボリュームがあったし焼きたてジューシーなチキンだったし普通においしかったです。店の雰囲気も落ち着いてるし、会計済ませて店を出た後深々とお辞儀して見送ってくれたりなんかしたし、あーここはまた来たいなーと思った。友人は待機してるメイドさん（一人だけ男装の執事なのは女性客向けの配慮か！）やキッチンの様子も見える席だったけど、僕は後ろ向きだったから全然見てNEEEEEEEEというのもありますが……ともかく、「メイドカフェ行きたい！」とか客人（誰）に言われた時にも躊躇せず連れて行けそうな気がします多分。
ちなみに入店時の言葉は「いらっしゃいませ」でした。
そのあとゲーセンとかリバティーとかアニメイトとかとらのあなとかを見て回った。僕自身は、近くに住んでると「べつにそんな意気込んでいくほどの所でも……」って感じでせいぜいヨドバシに行くぐらいしか来ることがないんだけど、東京に来ること自体が稀だった時は僕も確かに観光地気分であちこち見て回ってたし、そういうものなんですかね。
アニメイトのガチャコーナーで友人が何故かミスドのストラップを回してハニーチュロを引き当てて、「個人的にハズレだ……」と残念がっていた。せっかくだから僕も何か買ってみるかと思って300円投入してシューティングゲームヒストリカを回してみたら、R-9A ARROW-HEAD（スミ入れ有り）が出た。
アソート率が変更になったとかスミ入れ無し版が半分混入されるようになったとか、発売直前の仕様変更で物凄く酷いことになっているという話も聞こえてくるんだけど、そんな状況下でこれは大当たりと言っていい気がする。ていうかこんな所で運を使い果たしてしまった。でもすごくかっこいいから許す。
まぁR-TYPEはほとんどやったことないわけですが。
タブからプレースホルダーがゴッソリ消えた件についての憤り - Dec 01, 2007
タブのバインディングやスタイル指定のためのコードの削減のせいで、Firefoxのタブの拡張性は深刻なまでに低下した。ツリー型タブも情報化タブも動かなくなったし、Alice0775氏のスクリプトなども被害を被っているし、他にも被害を受けている拡張機能はあるんじゃないかと思う。
拡張機能がたくさんあるから云々ということを売り文句にしておきながら、このように拡張機能作者をいじめることにしかならないような変更を軽々しく入れてくる連中には、本当に腹が立つ。この詐欺的行為にあまりに腹が立ったので、自分でバグを立ててみた。
バグの報告文に書いたけど、この問題の要点は「拡張するためのあそびが全くなくなってしまった」という一言に尽きる。現行のFirefoxでは、スタイル指定のために用意された匿名要素のボックスや、そもそも今のFirefoxでは使われていないけれども今後実装されるかもしれない何らかの機能のために用意されていた（と僕は思っているけど確証はない）プレースホルダーがあって、それらの中に色々な要素を追加することができた。そのお陰で、タブの中にサムネイルを出したり、タブのロック状態などをアイコンで表示したりということが可能になっていた。ところが前述のバグで提出されたパッチによって、現在Firefoxの標準的な機能で使われている物以外の「あそび」は一掃されてしまった。
今の構造でも、バインディングを使えば要素を追加することはできるけれども、複数のアドオンでそれぞれ別々のバインディングを提供すればそれらは確実に衝突する。例えば、今までは情報化タブとツリー型タブを（それだけでなく、他のいろんなタブ系拡張機能を）好みに応じて組み合わせて使えていたのに、これからは、そのうちどれか一つしか使えなくなる、「組み合わせて使う自由」が失われるということだ。これでは、Firefox 1.5以前の暗黒時代に逆戻りだ。拡張性が高いことにFirefoxの価値を見出している者にとっては、こういう愚行は決して容認できるものではない。
でも英語力に自信がないしBugzillaの流儀にも詳しくないので、invalidとかworksformeとかそういう処理をされて、結局何も変わらないままFirefox 3正式リリースまでこの問題は解決されないまま放置されてしまいそうな気がする。誰か援護射撃してくれると嬉しいんだけれど……
APIを作る時はどんな使われ方をするかちゃんと考えてから作ろうという話 - Nov 30, 2007
ツリー型タブでずっと前から発生条件が分からなくて困ってた「一つもタブが選択されていない状態」になってしまうバグの原因がやっと分かったので、速攻で修正した。
この問題は、以下の条件がすべて揃った時に発生していた。
- タブバーの末尾に、ツリー状になったタブがある
- そのツリーが折り畳まれた状態で、ツリーの最上位の親のタブが選択されている
- そのタブを閉じる操作を行う
この時、内部的にどういう処理が行われていたかというと、以下のような感じだ。
- removeTabメソッドが呼ばれる
- removeTabメソッドにてTabCloseイベントが発生
- TreeStyleTabBrowserのインスタンスがTabCloseイベントを捕捉
- 1で閉じられようとしているタブがツリーの親で且つ子孫タブが折り畳まれている場合、TreeStyleTabBrowserが子孫タブを先に閉じる
- TreeStyleTabBrowserのTabCloseイベントに対する処理が完了
- removeTabメソッドの残りの部分に制御が戻る
- 閉じようとしているタブが、選択されたタブだった場合、次に選択するべきタブを決定し、そのタブを選択する
- removeTabメソッドの処理が完了
この「TabCloseイベント」というのがFirefox 2以降で使えるAPIなんだけれども、問題は7のステップで起こっていた。7のステップで「次に選択するべきタブ」を決定するためのキーとして「現在開いているタブの総数」を使っているのだけれども、その値は1のステップの間に取得しているため、1から7までの間のどこかでタブの数が増減した場合、タブの選択状態が狂ってしまうのである。7のステップで「現在のタブまたはそれよりあとのタブ」が選択される場合、ここでは4のステップでタブの数が減少しているため、「次に選択するタブの番号」が「すでに削除されたタブ」のインデックスを指し示すことになり、selectedTabの値がundefinedとなりNull Pointer Errorが発生してしまう。……というのが事の真相だった。
ツリー型タブの側でselectedTabのセッタを上書きし、もし存在しないタブが選択されそうになった時は強制的に最後のタブを選択するようにしたところ、「一つもタブが選択されていない状態」は発生しなくなった。以下はそのためのコード。
// var b = gBrowser
var getter = b.__lookupGetter__('selectedTab');
var setter = b.__lookupSetter__('selectedTab');
eval('setter = '+setter.toSource().replace(
'{',
'{ if (!val) val = this.mTabContainer.lastChild;'
));
b.__defineGetter__('selectedTab', getter);
b.__defineSetter__('selectedTab', setter);
この部分ではなく、removeTabメソッドを上書きするという手もあるんだけど、ここはいろんなアドオンが上書きしたがるためコンフリクトの原因になると思ったので、「標準的な動作と変わってしまう」ことは仕方がないと割り切って、ほとんど誰も触らないであろうselectedTabの方を上書きするようにした。ちなみに、ゲッタとセッタ両方を定義し直しているのは、片方だけを再定義するともう片方が未定義になってしまうから。
表題の件に流れを戻すと、「タブを閉じる」という操作をイベントとして捕捉できるようにしたのなら、そのイベントをトリガーにして他のタブを連動して操作するという機能も当然登場してくるわけで、そういうことを考慮せずに「はいはいイベント発行すりゃいいんだろdispatchEvent っと！」と適当に設計してしまうとこういうトラブルが起こるので、APIを作る時にはもうちょっと慎重になった方がいいよね、という教訓を得たという話なのでした。