Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
Mozilla 24 - Sep 15, 2007
14時からのSOI A+zillaのセッションに審査員として参加しないといけないのに起床したのが13時過ぎだったPiroですこんにちは。
ごはんもたべずに飛び出してタクシー拾って、セッション開始時間ちょうどに会場入りすることができました。
Shibuya.JSの後のブラポロリセッションに、チャットからユーザの声を拾い上げる役割で参加させていただいているのですが、同一IPからの接続が多すぎと言われてハブられてしまいました！
と言っている間に、だれかログアウトしたのか入れるようになりました。
29:30追記：会場からText Shadowを更新した（パッケージングしただけだけど）。
CSS3セレクタとXPathでの表現の対応表 - Sep 13, 2007
拡張機能勉強会の時に焚き付けられた、Text Shadowのコード（textshadow.js）を教材にして拡張機能開発のノウハウを解説していくシリーズ。
XPathをノードの検索に活用する方法を紹介したけど、肝心のXPathが書けなきゃ意味がないわけで。でもXPathって、ノードセットがどうとかノードテストがどうとか軸がどうとか修飾がどうとか、いざ勉強しようとしてもこれ専用の用語がやたらたくさん登場してきてものすごく萎える。CSSのセレクタの方が、機能は限られてるけどまだ分かりやすい。CSSのセレクタとXPath式の対応表があればいいのになあ、ということを、だいぶ前から僕は思ってた。
実は何年か前、哀さんのサイト（Black Box）でそういうコンテンツがあったんだけど、移転のゴタゴタか何かで消滅したままになってる。しかも、今「CSS XPath」みたいなキーワードでGoogleで検索してみて上位にくるエントリは、情報が不十分だったり間違いが含まれてたりする。
というわけで、CSS3セレクタ（このエントリを書いた時点ではワーキングドラフト）とXPath式の対応表で、詳細な物を作ってみた。
getElementsByなんちゃら の代わりにXPathを使う - Sep 09, 2007
拡張機能勉強会の時に焚き付けられた、Text Shadowのコード（textshadow.js）を教材にして拡張機能開発のノウハウを解説していくシリーズ。
W3CのDOMでは、要素ノード（およびそのリスト）を得る方法として以下の方法がある。
getElementById(aName)- IDをキーにして単一の要素ノードを得る。
getElementsByTagName(aTagName)- タグ名、要素名をキーにして要素ノードのリストを得る。
childNodes- 子ノードのリスト。
本当はネームスペースを指定して検索する物もあるんだけど、ここでは割愛。
これら以外に、W3C DOMではないがこういうのもある。
getElementsByClassName(aClassName)- クラス名をキーにして要素ノードのリストを得る。WHATWGのWeb Applications 1.0で定義されており、Firefox 3で利用可能。
getElementsByAttribute(aName, aValue)- 属性名と属性値をキーにして要素ノードのリストを得る。属性値として「*」を渡すとその属性を指定された要素全てを得る。FirefoxでXULドキュメントにおいて利用可能。
ただ、探したい要素ノードの条件が複雑な時は、これらを使って取得したノードリストをループ回して条件判断しないといけないし、そもそもこれらでは要素ノード以外は取得できない。そこで最近のJS界隈でよく使われているのが、XPathだ。
XPathとは、/html/descendant::li[@class="navigation"]という風な「式」でXMLノードを特定する技術だ。XPathの書き方を新たに憶える必要はあるが、これを使えば、複雑な条件に合致するノードのリストを一発で取得することができる。コードが簡潔になるのはいいことだし、FirefoxでもSafari 3でもOperaでも、普通にDOMとJavaScriptでごりごりやるのに比べて20倍以上高速に動作するという話もある。
XUL Tipsのページに書いてるけど、FirefoxではDOM3 XPathで提案されているXPath関係の機能が利用できる。詳しい解説はHawk's W3 Laboratoryの「DOMとXPathの連携」（サイトが消えてるので、インターネットアーカイブからどうぞ）を見て欲しい。リンク先では「Gecko用」と書かれてるけど、現在ではOperaとSafari 3でも利用できるようになっている。
不可逆的な変化に対する感じ方と、死 - Sep 08, 2007
iPod miniの新モデルの話を書く時に、半分無意識で、半分は意識して、物凄く気を遣った点がある。
それは、なるべく価値判断をしないように……ということだ。「良い」「悪い」という価値判断を可能な限り避けて、なるべく「好き」「嫌い」という僕個人の主観に帰結させるように、という。
人によっては、新nanoがたまらなく魅力的に思えるかもしれない。もしくは、これからnanoを知る人は、大きめの画面で動画を見やすいことこそがnanoのアイデンティティを形成する重要なポイントだと思うかもしれない。だからこそ価値がある、だからこそ「良い」、と考えるかもしれない。「彼ら」にとっては僕の好きな第2世代nanoが「ニーズを満たせない低機能の旧世代の遺物」としか思えず、だからこそ価値が無く、「悪い」、と思うかもしれない。
それどころか、もしかしたらそういう合理的な理由なんて無いかもしれない。ただ単に今まで慣れていた物と「違う」から、今まで好きだった物と「違う」から、自分自身の脳内に新しい物に対して快感であるとか親近感だとかを憶えるための回路がまだ形成されていないから、「駄目」と思っているのかもしれない。
イマムラさんのサンリオのショーに対する感想を見ても、そういうことを思ってしまった。
「良い」「悪い」と断じるためには、客観的にそう言えるだけの根拠がないといけない、と僕は思っている。その根拠を理解できない・示せないうちは、prototype.jsとjQueryのどっちが「良い」とか「悪い」とか言っていい資格は僕にはなく、ただ「慣れてるかどうか」「自分のスタイルに合ってるかどうか」「好きかどうか」のレベルでしか語ることは許されない、と思う。まぁ、客観的・合理的な観点で精査した結果として「結局好みの問題だね」とか「結局流儀の問題だね」というところに落ち着いてしまえば、やっぱり「良い」」「悪い」を超越した事しか言えなくなるのかもしれないけど。
好きだったモデルが製造中止になったとか、好きだったイベントが終了して別の物に取って代わられたとか、そういうのって、一種の「死」なんじゃないだろうかと思う。絶版品や終了したイベントに対して僕らが感じる口惜しさ、残念さと、大切な人・一緒に長い時間を過ごした人を失った時に感じる気持ちとは、もしかしたら似ていたりしないだろうか、と思う。死んだ人に義理立てして今を見ようとしない、とか、マンガやらドラマやらでよくある話。そう思うのは僕自身が人間的な暖かみのある感情を持ち合わせていないからかもしれないけど。
「戻る」ボタンに「何回戻れるか」を表示するアドオン作ってみた - Sep 06, 2007
「戻る」ボタンがどれだけ履歴を保持してるか一目でわかればどんなにいいかという話を見てサクッと実装してみた。
元記事では色とかアイコンの変化とかで視覚的に表す方法を提唱しているけれども、そこまでやる元気がなかったので、単に数字で「2」とか「4」とか表示するだけにしてます。
追記。専用ページ作った。
オープンソースって一体何なのか？ ということがよくわかるドキュメンタリー「レボリューションOS」 - Sep 06, 2007
ストールマンとかリーナス・トーバルスとかのオプソ界の有名人へのインタビューを中心にしてオープンソース誕生から今に至るまでの歴史を解説したドキュメンタリー映画の「Revolution OS」を、今頃になって見た。
調べてみたところ、これの日本語字幕付きのバージョンはオンラインだとナウオンメディア直営のサイトからしか買えないようだ。Amazonでも取り扱うようにしてくれればいいのに。まぁ買ったけどさ……
周辺にいる僕らにとって、分かってるつもりでもいまいち理解が怪しかったり、先入観によってうまく答えられなかったりする事について、「中心」にいる人達が最も的確な言葉で明解に答えてくれる。そういう内容だった。中でも、「オープンソースって共産主義なの？」というよくある指摘に対する反論は、実に分かり易かった。こんな具合で。
不思議少女の中でもこれまでに無いタイプの不思議さがあるラブコメ「謎の彼女X」 - Sep 06, 2007
謎の彼女X 1（作：植芝理一）
謎の彼女X 2（作：植芝理一）ふつう「不思議ちゃん」とかいうと、電波入ってる頭の弱い人とかそういうのを思い浮かべるんじゃないかと思うけど、本作に登場する「彼女」卜部さんはそれとは異なるベクトルの「不思議少女」と言えよう。ハサミで物を切り刻むという特技も、感情らしい感情を一切表情に表さない無愛想さも、「絆」で繋がった彼氏がいるから友達にはなれないという風な理屈に代表される独自の価値観に基づく判断も。「不思議」っていうより「<ruby><rb>謎</rb><rp>（</rp><rt>ナゾ</rt><rp>）</rp></ruby>」という言葉の方が多分しっくりくる。
そんな謎少女の卜部さんに対して、主人公の椿くんはいたって普通の健康的な少年だ。「彼女」に対して触りたいとか手をつなぎたいとかキスしたいとかの「ありがちな」欲は当然ある。でも謎少女の卜部さんはそれをことごとく拒絶する。卜部さん自身が望んだ時でなければ触れることも許されない。夏休みも、デートといえるようなデートはたった1回あったきりだ（2巻までの時点で）。世の中の「普通のカップル」がしてるような事、椿くん自身も「そうしたい」と思ってた事は、どうやら卜部さんとのつきあいの中ではなかなか得られそうに無いようである。
でも、いや、だからこそなのか、椿くんは卜部さんにますます興味を惹かれていく。期待しすぎず、でも絶望もしすぎない、適度な距離感を保ちながら、半ば「観察」してるような状態。この微妙な空気が許されるのは、作者自身が語っている通り、二人が「17歳」だからなんだろうな。
しかし、彼がこう安心してられるのは、目に見えて分かる「絆」が二人の間にあるからなんだろう。それが無かったら、どうだっただろうか……彼はこんなに余裕で毎日を送っていられたんだろうか？
iPod - Sep 06, 2007
iPodの新モデルが発表されましたね。
iPod classic（かつての無印iPodに相当するモデル）はともかく、第3世代のiPod nanoは……好みじゃないなあ。モデルチェンジの話を聞いて、「ギリギリのタイミングで第2世代nanoを買った俺涙目」とか思ったけど、実際出てきたものを見てみたら「ギリギリで第2世代を買っといてよかった」と思った。なんかずんぐりむっくりしててぱっとしない気がする。個人的に、外で動画を見るという習慣が無いから、動画向けにパワーアップしたといわれてもあんまりピンとこないというのもあるけど。
iPod miniも第2世代iPod nanoも、あとプレゼンの時にたまに見かけるMac用のリモコン？も、「スティック」っぽい感じと「中身の詰まった機器」っぽい感じの中間のような微妙なラインが好きだった。サイドの角は面取りされてるのに上下はスパッと切れてる、というギャップも好きだ。
いや、負け惜しみではないですよ？ 電池の持ちがよくなったとか羨ましくなんかないんですよ？（←羨ましい）
場違い - Sep 05, 2007
SOI A+zillaのアドオンコンテストの詳細ページ（英語）を見たら、伊藤穣一と村井純というビッグネームに挟まれて、よく分からん謎の人がいるんですけどどうしたらいいんですか。
……というわけでなぜかアドオンコンテストの審査員の一人になってしまいました。人生何があるかわかりません。ていうかよく考えたら自分自身がコンテストに出品したのって、参加者少数につきお寒い状況だったMozilla Party 4.0 XULコンテスト（結果）とmozilla.party.jp 5.0 XULコンテストくらいで、まともに批評の目に晒されたことがないくせに、いっちょ前に審査する側になるというのは、なんだか自分で映画作るわけじゃないのに批評はする映画評論家みたいかもしれない……。まー試験問題を作る側だから調理師免許を取ろうにも取れない服部先生みたいなとこまでいけばある意味かっこいいですけど。
ちなみに、当初は当サイトのプロフィールのページに誘導してもらうことを考えていたのですが、いきなり自己紹介漫画があるようなページに飛ばすなんてありえねーと言われてしまいましたので、適当にデッチ上げた経歴のページを代わりに置いてあります。で、タケイジュンって誰？（※title要素の内容がJun Takeiになってる）
んで、このプログラムの時間が3時間組まれてるんですが、応募者数が少ないと下手したら僕とこのお二方とで3時間トークショーをやる羽目になりかねません。皆さんどうか応募おながいします（自分で応募しやがれって？ いやそう言われても審査員なんで……）。
いざ要素名や属性名などを変えたくなった時にソースの中をあちこち探し回ったり巧みな正規表現を考えるために頭をひねったりしなくても済むようにするテク - Sep 05, 2007
拡張機能勉強会の時に焚き付けられた、Text Shadowのコード（textshadow.js）を教材にして拡張機能開発のノウハウを解説していくシリーズ。
Firefoxの拡張機能で、DOM要素ノードを動的に生成したり、編集したり、そうして生成したノードを後でまた収集したり、といった操作を行うような物を作る時は、必然的に、ソースの中に要素名や属性名が登場してくる。
var newNode = document.createElement('box');
newNode.setAttribute('class', 'my-custom-box');
parentBox.appendChild(newNode);
var nodes = document.evaluate('/descendant::*[@class="my-custom-box"]',
document, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
for (var i = 0, maxi = nodes.snapshotLength; i < maxi; i++)
{
this.processBox(nodes.snapshotItem(i));
}
こういう操作が一カ所だけにしか登場しないんなら別にいいけど、複数箇所で、似たような操作が何度もある場合は、要素名であるとか属性値・属性名であるとかノード検索の条件であるとかを、コードの冒頭で定数（定数プロパティ）として定義しておくことをお薦めしたい。
var myService = {
CUSTOM_BOX_NODE_NAME : 'box',
CUSTOM_BOX_CLASS_NAME : 'my-custom-box',
CUSTOM_BOX_EXPRESSION : '/descendant::*[@class="my-custom-box"]',
(略）すると、さっきのような箇所はこうなる。
var newNode = document.createElement(this.CUSTOM_BOX_NODE_NAME);
newNode.setAttribute('class', this.CUSTOM_BOX_CLASS_NAME);
parentBox.appendChild(newNode);
var nodes = document.evaluate(this.CUSTOM_BOX_EXPRESSION, document, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
for (var i = 0, maxi = nodes.snapshotLength; i < maxi; i++)
{
this.processBox(nodes.snapshotItem(i));
}textshadow.jsの冒頭箇所を見てみると、動的に生成するIDのプレフィクスとか、途中で生成する要素のクラス名であるとか、XPath式の中に埋め込む検索条件だとかを、片っ端から定数としてまとめて定義していることが分かるはずだ。
こうしておくと、いざクラス名が他の拡張機能とかぶっていたと判明した時なんかでも、ソースの頭の方をちょこっと書き換えるだけで済む。class属性の値として文字列リテラルが書かれている箇所を片っ端から探すようなことはしなくていい。
え？ 一括置換を使えばすぐだろうって？ まあ、確かにたいていの場合はそうなんだけど、でもそれじゃ解決できない時もある。