Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 17/248: « 13 14 15 16 17 18 19 20 21 »

FUEL使ったんだ…… - May 16, 2009

FUEL の Window/Tab 周りのハンドラは Firefox 3 では使うな - 8時40分が超えられない - subtech

書籍の中で詳しく解説しといてナンですが、アレをほんとに使う人がいたのか!ということにむしろ驚いてますよってなもんです。

まあ言う人に言わせれば、NSPRやらNeckoやらのよくわからない物が何層も積み重なった上にあるFirefoxを使うということ自体が「しんじらんねー」な感じなんでしょうけども。

他のアドオンと連携しやすくするためのライブラリを作ってみた - May 13, 2009

マルチプルタブハンドラについてRockridge氏ほかから「メニューをカスタマイズできるようにしてくれ」という要望が挙がっていたのだけれども、Menu Editorという素晴らしいアドオンがあるのに自前で同じような機能を再実装するのは徒労感しか無いなあと思ったので、開き直って、マルチプルタブハンドラの設定ダイアログを以下のようにしてみた。

  • Menu Editorがインストールされていなければ「Menu Editorをダウンロードする」リンクを表示する。
  • Menu Editorがインストールされていれば「Menu Editorの設定を開く」ボタンを表示する。

Menu EditorのAPIをよく分かってないので(ていうかそもそも公開APIなのかどうかも知らない)、タブ選択時のメニューをカスタマイズできるようにするためにちょっと強引な方法を使ってる。

で、同じようなこと(他のアドオンの有無を調べた上で設定を開く)を何度も書きたくなかったので、設定ダイアログに加えた変更の要点を他のアドオンと連携しやすくするためのライブラリとして分離してみた。

if (window['piro.sakura.ne.jp'].extensions.isInstalled('my.extension.id@example.com') &&
    window['piro.sakura.ne.jp'].extensions.isEnabled('my.extension.id@example.com'))
    window['piro.sakura.ne.jp'].extensions.goToOptions('my.extension.id@example.com');

アドオンがインストールされているかどうか・有効か無効かを調べるだけならFUELで事足りるので、あまり使い出がないといえば使い出がない。まあThunderbird 2あたりでだったらニーズがあるかもだけど。

ちなみにFUELで書く場合、アドオンがインストールされているかどうかはApplication.extensions.has('my.extension.id@example.com')、有効か無効かはApplication.extensions.get('my.extension.id@example.com').enabledで分かる。設定ダイアログのChrome URLを調べるAPIはなくて、それでこのライブラリを作ることにした次第です。

マルチプルタブハンドラのAPIを使って貰えて嬉しかったという話 - May 10, 2009

感謝されても喜べないとか書いたけど、マルチプルタブハンドラのAMOでのレビューでAPIのことを誉められたのは、最近あった事の中では特に嬉しいと感じた出来事だ。

マルチプルタブハンドラは「複数のタブをまとめて操作する」機能を提供するアドオンだけれども、公開して多分すぐくらいから「こんな機能も付けてくれ」「あんな機能も付けてくれ」「このアドオンと連携してくれ」とかそんな感じの要望が出たと思う。そうなる事は最初から結構想像できていて、だから、タブの選択状態の制御や選択状態によるタブの取得といった事をできるAPIを開発初期から公開していた。他のアドオン作者の人がこれを見て、マルチプルタブハンドラ用のコードを組み込んでくれたら嬉しいなあ、という風に思っていた。

しかし実際には、MozillaZine Forum(本家の方)で宣伝するわけでもなく、AMOに同じだけの情報を載せられるでもなく、せいぜい分割ブラウザツリー型タブなどの自作アドオンで細々と使う程度だった。このまま誰にも知られずに終わってしまうんだろうなあ、と思っていた。

なので、Paolo Amadini氏のこのコメントは非常に嬉しかった。

For developers, MTH provides a programming interface that makes it really easy to add new functions that work on multiple tabs; I used this interface in MAF, to provide an easy way to save multiple pages in a single file. (開発者向けに、MTHは複数のタブのために働く新しい機能を非常に簡単に追加できるようにするプログラミングインターフェースを備えている。複数のページを1つのファイルに簡単に保存できる手段を提供するために、私はMAFでこのインターフェースを使った。)

そこに目を付けて貰えた事が嬉しかっただけでなく、MAFという(僕にとっては)ずっと技術的に凄い事をやっているアドオンにマルチプルタブハンドラのためのコードを含めてもらえたということが、嬉しかった。今まで他のアドオンとの連携といえば、ずっとマイナーで世界の隅っこで細々開発してるだけの立場である自分の方から頑張って他のアドオンのコードをなんとか読み解いて連携のためのハックを考える、という事しかやってこなかったので、向こうの方で解決してもらえたということが嬉しかった。

タブキラーをアップデートするついでにFirefox 2以前のサポートを終了した - May 07, 2009

Tab Killer 2.0.2009050701 MinefieldとShiretoko用にアップデートした。

  • Firefox 3.5だと「ウィンドウを開き直す」が本体側に装備されているので、Tab Killer側での無理矢理な再現は行わないようにした。
  • タブを開く操作が行われた時やタブを閉じる操作が行われた時は、既定の動作として、その要求をどう扱うかを選択するダイアログを表示するようにした。タブを開く要求であれば「今のウィンドウに読み込む」「ウィンドウを開く」「無視する」、タブを閉じる要求であれば「現在のページをアンロード」「ウィンドウを閉じる」「無視する」のそれぞれ3択にした。
  • Firefox 2以下を切り捨てた。

こんな物でも要望がたまに来るからFirefoxのユーザ層って趣味の幅が広いなと思う。

Split Browser 0.6.2009050101(Firefox 2以下切り捨て) - May 01, 2009

分割ブラウザ更新した。Firefox 2捨てで、Firefox 3以降専用にした。おかげでJavaScriptコードモジュールとかの便利技術をためらいなく使えるようになった。最近になってアドオンを作り始めた人達がほんと羨ましい。あんな糞みたいな苦労をしなくても遙かに簡単に同じ事ができてより素晴らしい物を作れるんだから。羨ましいを通り越して妬ましくすらある。

更新履歴的には「ShiretokoとMinefieldで動くようにしました」で済ませてるけど、Firefox 2→Firefox 3で色々変わってた部分にかなり見落としがあったのを相当数直してる。ペイン内でのズームとかドラッグ&ドロップとか。

機能的な変更は以下の点くらい。

  • 分割の状態をpreferencesではなくセッションの方に保存するようにした。ウィンドウ単位で状態を保存するので、アドオンインストール後の再起動時やクラッシュからの復帰時はもちろんの事、Firefox 3.5以降の「最近閉じたウィンドウ」でも分割の状態までちゃんと復元されるようになった。
  • 閉じたペインを開き直す機能を加えた。デフォルトでは最大10回まで。開き直される位置は元通りではないので注意。
  • 分割後の領域のツールバー部分へのドラッグ&ドロップを、タブバーへのドロップと同等に扱うようにした。タブやリンクをツールバー部分にドロップするとタブで開く。

あと、地味にFirefox 3.5以降のプライベートブラウジングに対応してみた。プライバシーついでに、プライバシー情報の消去関係の機能とも統合を図ってる。この辺のノウハウはまたどっかで文書化したい(それか、勉強会のネタにするとか)。

swapBrowsersAndCloseOtherの変更への追従と、メソッドの動的な書き換えのメリット・デメリット - Apr 30, 2009

以前書いたtabbrowser要素のswapBrowsersAndCloseOther()メソッドの上書きの話で書いてたサンプルが使えなくなっていたので直した。というか自作アドオンの機能を使おうとして正しく動かなかったのでコードを改めて見てみて、メソッドの書き換えの対象になってる箇所に変更があった事に気付いた(4月16日に変更が行われていたようだ)。

以下は、Shiretoko 3.5b5preに合わせて修正した後のバージョンのサンプルコード。

if ('swapBrowsersAndCloseOther' in aTabBrowser) {
  eval('aTabBrowser.swapBrowsersAndCloseOther = '+
    aTabBrowser.swapBrowsersAndCloseOther.toSource().replace(
      '{',
      '$& MyAddonService.destroyTab(aOurTab);'
    ).replace(
      'if (aOurTab == this.selectedTab) {this.updateCurrentBrowser(',
      'MyAddonService.initTab(aOurTab); $&'
    )
  );
}

if (aOurTab == this.selectedTab)を目印にして「タブを入れ換えた後の再初期化処理」を入れてたんだけど、同じif文がこれより前の位置に増えたせいで、コードの挿入位置がずれてしまい、本来期待していた順番とは異なる順番で処理が行われてしまっていた。if文の中まで目印に含めるようにして一応回避したけど、これはこれで、if文の中を書き換えるアドオンがあると破綻してしまう可能性があるわけで……何かいい方法はないものだろうか。

今回の場合に限らず、「メソッドの入れ替えではなく動的な書き換えを行う」やり方には、こういう変更に逐一追従しなくてはならないという弱点がある。メソッドのインターフェース(引数の数や返り値)はそうそう変わらなくても、中身は結構頻繁に変わる。なので、気をつけておかないといけない。

もう1つの弱点として、書き換え対象のメソッドの中で参照されている変数がそのメソッドが定義された変数スコープからしか参照できないものであった場合に、それへの対処も必要となる。その変数の値がグローバルな名前空間からアクセス可能なものであれば、メソッドの書き換え時にその変数を同時に宣言し直してやればいいんだけど……

(function() {
  var attrName = 'foo';
  window.ExampleAddonService = {
    method : function(aNode) {
      aNode.setAttribute(attrName, true);
    }
  };
})();

// メソッドの書き換えには成功するが、attrNameという変数が
// 見つからなくなってしまうので、実行時にエラーになる
eval(
  'window.ExampleAddonService.method = '+
  window.ExampleAddonService.method.toSource().replace(
    '{',
    '{ AnotherAddonService.preProcess(aNode);'
  )
);

この例のような場合になると、もうお手上げ。

それでも動的なメソッドの書き換えの方を僕が積極的に使う最大の理由は、同じやり方でメソッドを書き換える他のアドオンとの互換性を維持するためだ。別名で元のメソッドを保持しておくやり方の場合、他のアドオンが元のメソッドの名前で関数オブジェクトを取得しても、その関数の内容は元のメソッドとは全然違うから、書き換えられなくて動かなくなる、という事態が起こり得る。それを避けるためには、上の例のようなお手上げな事例を除き、可能な限り元のメソッドを動的に書き換えた方が良いということになる。

顔の見えない「ユーザ」のための不毛な努力はもうしないよ - Apr 24, 2009

統合を批判する拡張開発の人たちは、 「自分のやりたいことに何が必要なのかを考えない人は、 そもそも拡張を使うな」とどうしても厳しい目線に立ってしまう。

これはちょっと違う。使い手は使い手自身のエゴに則って好きにすればいいと思う。

僕がしてるのは、「自分が何をしたいかもちゃんとは認識できてない、『とりあえず何でもいいから便利なプラグイン教えて』と言ってしまうような人」の、行動や思想を批判する事でも、そういう人達の行動を改めさせるべく啓蒙活動する事でもなく、「そういう人達のために自分が努力する事を、やめる」「そういう人達の視界に入らない場所に自分が逃げる」って事だ。

何故そういう人の行動や思想そのものを批判や否定しないのかというと、自分自身も別の場面では「そういう人」だと自覚しているからだ。そういう人、をターゲットにアホだのマヌケだの言う自分の姿を想像すると、「こいつ自分がそうなのを棚に上げて他人の事ばっかり言ってやがるな」とあまりに滑稽すぎて恥ずかしいので、同じ事を他人から言われたくないから、そういう事をしないようにしようと思っている。

予定もしくは野望もしくは妄想 - Apr 21, 2009

今の所、XUL/Migemoの辞書ファイルは全部普通のテキストファイルなんだけど、これをSQLiteデータベースに置き換えてみようかなと思ってる。メリットがあるのかどうかは分からないんだが。

現在の辞書周りは基本的にはplus7さんが作られた物を踏襲していて、起動時に全ての内容を読み込み、JavaScriptの普通の文字列としてオンメモリで保持しておくようになってる。でもこれだとFennecで動かすのって多分きついだろうなあ、とは思ってた。

どうなんだろう、SQLiteって関係ないデータはメモリに読み込まずにいてくれたりするんだろうか? Fennecのデフォルト設定を見た限りでは、履歴の保持日数はFirefoxと同じ90~180日となってるから、これを全部メモリ上に読み込んだらエラい事になるよねぇ。と考えると、必要最小限だけメモリに読み込むようになってる事を期待してると考えていいんだろうか? それとも、これは単にFennec開発陣がSQLiteを過信あるいはモバイルプラットフォームを甘く見てただけで、実は全部オンメモリになっちゃいますとか?

まあとりあえず実装するだけしてみて、それから考えてみよう……

……とりあえずやってみたけど、なんか、めさめさ重い……ちゃんと作ってないから単にどっかで無限ループしてるのかもだけど。しかしそれを抜きにしても、辞書が約4MBだったのがSQLiteにしたら9MBに膨れ上がってしまった。モバイルで使うなんてのはますます非現実的な領域だ。工夫しないと全然お話にならんね……

追記。もうちょっと進めてみたけど、余計泥沼に嵌ってる気がしてきた。バックエンドのSQLite化は無しだな、というのが現時点での結論ですわ。

Tab Mix Plus排斥運動をしたいわけではないんですよ - Apr 21, 2009

Tab Mix Plus は window オブジェクトレイパー - 地獄の猫日記 とか、自分の書いた話がきっかけとなって他の人もTMPの他のアドオンとの互換性に関する話を書いていたりしていて、それらを参照した上で「TMP使うのやめます」と表明している人もいるのですけれども。そこら辺の状況をもって「PiroはTMP批判の世論を作ろうとしているのだ! 扇動しているのだ! 排斥運動をしたがっているのだ! 私怨に狂っているのだ!」とかなんとか言い出すような人が現れたら嫌だなあ、ということで自己保身のために予防線を張っておく。

こんな事言っといてアレですが、僕は今Tab Mix Plusを使ってる人に「今すぐそんな物窓から投げ捨てちまえ!」と言いたい、わけではないんですよ。他のアドオンと組み合わせさえしなければ別に問題はないんだから、使ってて不満を感じてなければ使ってて全然構わないし、使うのをやめる必要もない。

つうかね。グローバルな名前空間がどうこう言い出したら、そもそもFirefox自身のコードだって結構酷いし。将来的に問題が起こりやすい・起こりにくい設計です、ということと、今問題が起こっています・起こっていません、ということはあくまで別の話だし。

単に、いくつもアドオンをとっかえひっかえしながら使うようなスタイルでFirefoxを使うんだったら、「Firefox+TMP」という環境をベースにするのは、お勧めできないし残念な思いをすることが多そうだよ、って話です。むしろ、「アドオンという仕組みが無かったSleipnir 1.x系のようなブラウザを使ってるのと同じようなもんだ」と思えば、別に何も変じゃないわけです。

他のアドオンと衝突しないように心がけたいし、心がけて欲しい - Apr 17, 2009

「次のエントリで書く」なんて予告じみたことを書いてはみたものの、どうも話がまとまらない。もう、思ったことを箇条書きで書くだけにする。

現実的に言って、1つのアドオンであらゆる人のニーズを満たすことは不可能だと思うし、そういう方向での努力はしない方がいいとも思う。何でもかんでも……と際限なく詰め込んでいくと、どこかで破綻すると思う。機能の詰め込みは、ある時点までは効率がいいんだけど、ある時点を超えてしまうと、デメリットの方が大きくなってくる。「Piro拡張化」なんて言われるようになる。

作る側の心理として、どうして機能を増やしたくなるのか。他の人はどうか知らないけど、僕はこんな感じだった。

  • デバッグより、新機能を実装する方が楽しい。モチベーションが高まる。
  • 大は小を兼ねる。大きいことはよいことだ。みたいな。
    • 「こんな小さな物をたくさん作りました」よりも「こんなデカい物をたった一人で作りました」の方がなんかすごそう。
    • より多くの人のニーズを満たせば、より多くの称賛を得られる。誉められて嬉しい。
  • それまでに作った部分を土台や部品として使えるので、新しい別個のアドオンにするのに比べてはるかに楽に「すぐ動く物」ができる。
    • 共有できる部分が多ければ、それだけ「無駄が無い」と言える。同じことをするコードが複数のアドオンにあるのは、無駄なことで、気持ち悪いと感じる。
    • 複数の機能を有機的に連携させて、「100%ぴったり、思い通り」の挙動を実現できる。

そんな感じの理由でどんどん機能を加えていく。ある時点までは、それでうまく回る。応援してくれる人とか感謝してくれる人とか、モチベーションを高めてくれる声も寄せられる。でも、なんかの閾値を超えたところで、あらゆる物事が下り坂に転じる。

  • 目が行き届かない所が出てくる。
    • 自分が使う物は目が届くけど、使ってない機能には目が届かない。
    • 自分の環境では問題ないのに他の環境では問題が起こる、というケースが頻発するようになる。
  • 機能同士が複雑に絡み合っているので、原因の特定がどんどん困難になる。
  • 既にある機能との整合性を常に考えないといけないため、新しい機能を加えにくくなってくる。新しい機能を加えることに物凄くエネルギーを使わないといけなくなる。
  • 作り込めば作り込む程、前提とする環境への依存が強くなる。
    • 前提がちょっと変わるともう全然動かなくなる。Firefox 1.5向けに作り込んでいたから、もはやFirefox 2に対応できない。
  • 最初の頃は「こんなの今まで無かった! これがあると大違い! 素晴らしい!」と称賛されていたのに、だんだんそれがなくなってくる。
    • 「定番だよね」「むしろ当たり前だよね」と言われるようになってくる。
      • 使う側から見たら「あって当たり前」という感覚だから、感動なんてしない。最初の時点で「とりあえず入れとけ」みたいな感じで勧められるから、それが無い時の不便さも、それを導入することで起こる変化にも、気がつかない。
      • 本当だったら使わなくてもいいはずの人まで、「なんかみんな使ってるみたいだし、入れとくか」という感じで使うようになる。
      • アドオンは薬のようなもので、導入するのは薬効と副作用のトレードオフ。どうしても必要な薬効があるから副作用を我慢して使う、というのが本来そうあるべき使い方なのに、薬効をそもそも知らないまま流されて服用して、副作用に苦しむことになる。
        • 「バグが多い」「不具合ばっかり」「他のアドオンと衝突しまくる」などのデメリットばかりがとりあげられるようになってくる。
      • 「定番なんだから責任持って作れよ」「こんな事もできないの? 定番なんだからできて当然なんじゃないの?」みたいな、お客様気分の声が増えてくる。やる気を削がれてくる。

そんなわけで、精神的な負荷と時間的なコストがどんどん大きくなっていって、タブブラウザ拡張は破綻した。Firefox 1.5のサポート完全終了と共に、過去の遺物となった。

  • かといって、Firefox 2デフォルトの状態で我慢できるわけもなくて。
  • でも、タブの複数行表示機能をやめてツリー表示しか使わなくなってしまっていた自分には、今更Tab Mix Plusに乗り換えるというのも考えられなかった。
    • 感情的な理由もあった。後から来て追い抜いていった(と同時に、良い評価もかっさらっていった)相手に自分が依存するのは屈辱だと思った。
    • TMPも「Piro拡張化」の行き着く果てまで来ているように思えた。ここから先は下り坂だと思った。

そういうわけで、過去の自分の失敗を徹底的に反省して、ゼロからやり直すことにした。

  • 全部詰め込むのはやめる。1つ1つのアドオンを可能な限り単機能に保つようにする。
    • 多少効率が悪くても、重複する部分があっても、個別のアドオンに分ける。
    • 重複する部分がデカくなるようだったら、ライブラリにする。
      • ライブラリはファイル単位で上書きできるようにする。ファイルの中を見て必要な箇所を切り貼りして……という風なことはミスの元になるから、やらない。
      • 複数の異なるバージョンの同じライブラリが同時に入っていても、問題なく動くようにする。
      • という考えで作ったライブラリをリポジトリにまとめてある
    • 関係ない機能を含めない。コンセプトが合わない機能は、簡単に実装できそうであったとしても、加えない。
      • これはユーザにもメリットがある。
      • 多機能で「とにかく便利」なんてコンセプトだと、ユーザは入れてみるまで薬効と副作用の比較ができない。入れた後も、どれが薬効でどれが副作用なのか分からない。
      • 単機能なら、薬効と副作用を比較しやすい。「この機能はいらないから、入れない」という判断ができる。「よく分からんけどとりあえず入れてみる」という選択を防ぐ圧力が生じる。
        • 多機能にするよりユーザ数は多分減る。でもそれでいい。薬効が必要なくて副作用しか得られない人にまで、使ってもらいたくない。
  • 主要な機能を、他のアドオン(自分が作る物も含めて)から使いやすいように「API」として公開する。
    • といっても、物自体は変わらない。あくまでただのメソッド。ただ、作る時の心構えを変える。
      • 自分だけが使うものだから……と思っていると、メンバ変数とかをがんがん使った、実装するのが楽な、結合が密な設計にしてしまいがち。
      • 結合が密だと、100%全ての情報の流れを理解している人間でなければメソッドを使えない。
      • 半年くらいして自分でもすっかり忘れた頃にもう一度見て、すぐに理解できるか? 理解できなさそうなら、それは駄目な設計。
      • 結合をなるべく疎にする。密な結合にしないといけない時は、せめて、情報が双方向に流れないようにする。一方通行に処理を追いかけるだけで理解できるようにする。
    • インターフェースを公開して、ドキュメントも作る。
      • 既に公開してしまっている物だから、安易に変更できないというプレッシャーがかかる。APIの互換性を維持する力が働く。
    • 機能同士の連携は、必ず公開APIを経由して行う。
      • APIでできないことはしない。
      • 必要なら新しいAPIを考える。やっつけ仕事ではなく、ちゃんとした設計で。
  • TBEでやってたような、ガチガチの作り込みはしない。
    • 泥臭くてカッコ悪くても、フレキシブルな対応が可能なやり方を取る。
      • XBLでスッキリ書くより、DOMでゴリゴリ書く。
    • なるべく、Firefox自体が持つ構造を壊さない。
      • 要素構造を自分好みにすっかり作り替えてしまえば、自分は楽になる。でも、ユーザが困る。他のアドオン作者も困る。要素構造を変えると他のアドオンと衝突しやすくなる。
    • XBLの使用はできるだけ避ける。
      • 特に、既存のバインディングの「置き換え」は「最後の手段」「禁じ手」と考える。
      • 「まだバインディングが行われていない部分への追加」だったら、使ってもいい。
      • どうしてもXBLじゃなきゃ実現できない、という部分だけに限って使う。それ以外でXBLを使うのは、極論すれば「珍しい技術を使ってる自分」に酔っぱらってる自己満足な行為でしかない、と考える。
    • メソッドを丸ごと置き換える、という事はできる限り避ける。
      • やるのなら、eval()による部分的な書き換えで対処する。
      • やりたいことの大半は、元のメソッドの最初か最後に処理を追加するだけ。メソッドを丸ごと全部別物に置き換えてしまう必要は本来無い。
      • 見通しは悪くなるけど、他のアドオンとの競合は起こりにくくなる。と思う。
      • これによる開発効率・メンテナンス効率の低下は、個々のアドオンを単機能に・シンプルに保つという前提によって相殺する。
  • 他のアドオンでできることはしない。
    • 自分一人で抱え込まない。他の人がやってることをわざわざ自分でやり直そうなんてことはしない。
    • 組み合わせて使うことを積極的に推奨する。自分自身も、他のアドオンと組み合わせて使う。
      • 組み合わせて使って問題が起こりにくい設計にしないといけない、という圧力が自然とかかる。

こういう考えに基づいて作ったのが、マルチプルタブハンドラ情報化タブツリー型タブソース表示タブという4つのアドオンだ。上に書いたことを完全に守れてるとは言えない部分もあるけど、昔に比べれば遙かにマシになってると思う。

作る側としても、使う側としても、僕は今の方がずっと楽だ。

「多機能に」「1つだけで様々なニーズに応えられるように」という方向に頑張ると、縛りがどんどんきつくなってくる。1つのアドオンだけでできることを増やしていこうとすると、妙な話だけど、他のアドオンに頼れなくなっていく。作り込むほどに、そのアドオンを入れた結果が素のFirefoxとかけ離れてしまうから、他のアドオンとの互換性がどんどん失われていく。だから、1つのアドオンだけでしなきゃいけない事がイモヅル式にどんどん増えてくる。

ユーザの視点から見ると、「多機能なアドオン1つだけの世界で完結した使い勝手を享受する」か、「いろんなアドオンを組み合わせて使う」かの、どっちかを選ばないといけないということでもある。両立はできない。

ここで改めて念を押すけれども、僕は、Tab Mix Plusと上記のタブ系アドオンの組み合わせは推奨していない。一応TMPで動くようにはした、けれども、継続的に追っかけ続けるモチベーションが無い。何故なら、僕はTMPユーザではなく、TMPと組み合わせて壊れるようであっても僕自身は全く困らないから。TMPユーザでない他のアドオンの作者の中には、同じように感じてる人もいるんじゃないかと思う。自分が使ってもいないのに対応を迫られるなんて、厄介な奴だ、目障りな奴だ、みたいな。閑話休題。

「多機能なアドオンで、部分的には、痒い所に手が届くような感覚がある。でも、足りない部分もある。それを補うための他のアドオンと組み合わせて使うことは、残念ながらできない。」「単機能のアドオンをたくさん入れていて、それぞれはそれなりに便利。でも、いまいち連携が取れてなくて、痒い所に手が届かない。」そのどっちかを選ばないといけない。

一人あるいは少数の作者の頑張りだけに期待しなきゃいけない、期待して待ってなきゃいけない。多機能長大路線を歩むという事は、ユーザにそれを強いるという事だと思う。僕はそれが嫌になった。

多分、多機能な物を「作る」だけなら、誰にでもできるんだと思う。時間さえかければ。当時の僕にもうなる程の時間があった(大学生で、レベルもそんなに高くなかったから楽に単位を取れて、その分自由に時間を使えた)から、できてたんだと思う。でも、より大きな問題は「作った」の後にあると思う。メンテナンスし続けられるのか? 他のアドオンと協調させられるのか? 多機能長大路線ではそれは難しいと、僕は思った。

Page 17/248: « 13 14 15 16 17 18 19 20 21 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のコメント

最近のつぶやき