Latest topics > 拡張勉強会ではなく敢えて拡張機能勉強会と呼びたい

拡張勉強会ではなく敢えて拡張機能勉強会と呼びたい - May 21, 2007

土曜日、第4回に行ってきた。会場が麻布十番のいいとこで、建物も妙に綺麗でオフィスも同様で、かなりびびった。

MLでの反応が薄いようだったので「大丈夫か？」と思ってたけど、行ってみたら10人以上集まってて、これもまたびびった。

GomitaさんのFUEL（XPCOMその他をもっと使いやすくするためのラッパー）の話は非常に面白かったというか、調べなきゃなーと思ってたことを代わりに調べていただいた感じで（ぉぃ）大変助かった。

要約すると、現在のMinefield 3.0a5preに入ってるFUEL 0.1はまだまだ大した機能は含まれていなくて、Firefoxの起動と終了の監視、設定値の読み書き、Firefox起動中のみ保持されるセッション用のデータの保持、程度のものしかない。ブラウザの制御やブックマークの管理などは今後の0.2とか0.3とかで入ってくるんだとか。仕様も何もまだ固まっていなくて、Mozilla Wikiでディスカッションされてる状態だから、今のうちにツッコんどけば要望が反映されるかもね？　ということだった。

個人的には、コードがFirefoxにガチガチに依存した物になるのだけは避けてもらいたい所だ。例えばFUEL 0.2のプランに挙がっている例を見ると、ブラウザは一つだけというのが大前提になってるようだけれども、Split Browserのような変態的な拡張機能を作っている僕としては、なるべくフレキシビリティとかスケーラビリティとかそういうものを保つようにしておいてもらいたい。XULの仕様として、browser要素のtype属性にcontent-primaryが指定されているとその内容ウィンドウにwindow.contentでアクセスできる、という物があるけれども、そういう風に汎用性のある仕様で作って欲しい。idがcontentであるもの、とかそういう仕様ではなく。

その後の余った時間のTab Scope苦労話も大変興味深かった。SCRAPBLOGの最近のトピックのまとめというかなんというか。これらの実験がどういう背景で出てきてどういう風に活かされているのか、といったことを一連の流れとして見ることができたのは面白かった。限りなくバッドノウハウに近い話のような気もするけど。苦笑。

DevConでもこういう話をたくさん聞けるといいんだけどなあ。

Swimmyの大澤さんの作っておられる「タイムマシーン」は今の所Internet Archiveだけをバックエンドに使っているそうだけれども、Googleなどの検索サイトやウェブ魚拓のような他のキャッシュなど、Web上に点在している各種のサービスを統合して一つのUIの下にシームレスに連携させられるようにして、あたかも「そういう機能」であるかのように完全に振る舞わせることができれば、それはある意味でマッシュアップ的というか、Webの可能性を引き出す試みとしてとても面白いと思う。

teramakoさんの話は、Tag Dialogについてはあまり心惹かれなかった（失礼）けれども、拡張機能を統合開発環境を使って開発している場面をナマで見れたのはよかった。Eclipseベースの環境ってどんなもんなのか全然想像が付いてなかったんだけど、実際の物を見てみると予想以上になかなかよくできてるっぽいなと思った。

全く前知識のない状態で拡張機能の開発を始めるのなら、こういう物があった方がやっぱりいいんだろうなあ。僕なんか、そういうのが全然無い頃から手探りで秀丸エディタ一本でやってきてるから、もう体がすっかりそれに順応してしまっていて、むしろGUIを使うのが面倒と感じるようにすら……あわわわ。そりゃまずいよ。

でもGUIとかよりも、APIのリファレンスが内臓されてるとか、メソッド名やクラス名とかを自動的に補完してくれるとかのアシストは僕から見てもとても魅力的だ。僕はくだらないtypoの類がめちゃめちゃ多いので、あれができるときっと生産性が飛躍的に向上するんだろうなあ。

わくらわのあかつかさんは、拡張機能を自動的にオススメしてくれるようなシステムについての提案をされていた。その時にも話したけれども、Amazonの「この商品を買った人はこれも買っています」というオススメのように、「この拡張機能を使っている人はこれも使っています」とオススメするというあたりが現実的なんじゃないかなあと僕は思っていて、あかつかさんが最初におっしゃっていたような「個人の行動からオススメを割り出す」というのは大変困難なことのような気がする。

Amazonとかが採っているアプローチは、個々人の行動傾向を分析するのではなく、顧客全体の行動傾向を分析するという物だ。行動の傾向が似ている人が二人いて、片方がやっていることをもう片方がやっていなければそれをオススメする、というのは、よく考えてみれば、本当の意味で「行動からオススメを割り出している」とは言い難い。「片方だけが既にやっていること」というのは、つまり「その人が自力で見つけ出した物」であって、Amazonはその尻馬に乗っかっているに過ぎない。それだけに過ぎないからこそ、比較的実装が楽なんだと思う（楽といっても、統計処理とかの専門知識がいるだろうから、僕から見たら物凄く難しいことなんだけど……）

どっかのブログでオススメされていた拡張機能を導入するというのも、これと本質的には同じことなんじゃないかと僕は思っている。自分と趣味嗜好の傾向が似通った人、行動パターンが似通った人が書いているブログだから、ついつい興味を惹かれて、他のエントリも続けて見てしまったり、あるいは継続的にウォッチしたりするようになる。その中で紹介される拡張機能というのは、行動の傾向や思考の傾向が似ている自分にとっても有用である可能性が、少しは高いと言えるだろう。

しかし個々人の行動だけを見て分析するのは、それとは比べものにならないほど大変な作業なんじゃないだろうか。拡張機能をオススメするというのは、何らかの拡張機能によって解決されうる問題がそこに存在しているということに「気付く」ということだ。それは、問題解決のプロセスの第一歩そのものだ。「現状」と「理想状態」とを比較して一致していないギャップを「問題」と捉え、その「問題」が存在していることに「気付き」、それを解消するための方法を「考える」というのは、例えばドラクエの戦闘のように非常に限定された世界の中であれば可能かもしれないけれども、それに比べるとずっと広大でずっと自由度の高いWebの世界でやるのは、一般的なコンピュータ環境の手に負える処理とは僕にはちょっと思えない。……というのは、今の科学技術を僕が見くびりすぎているんだろうか？

TakenさんのSVGや透過ウィンドウの話。chrome://global/skin/global.cssの読み込みを行わないことでLinuxでもウィンドウが透過されるようになる（ただしXの設定をいじらないといけないらしい）というのは知らなかった。「XULでクロスプラットフォームで伺か」までは、あと一歩、という感じか。もしほんとに使い物になるようになったら、ふぉくす子とさんだば子のゴーストでほっといたら画面の端で勝手にイチャイチャと百合百合しい振る舞いを見せるような物を是非とも作らなければ。夢がひろがりんぐだ。