[Google Chrome] やってらんねー

AdDictというChrome拡張機能を公開していたのだが、Chrome開発陣の腐れっぷりに愛想が尽きたので公開を停止しギャラリーからも削除した。この問題への対応を見て、Chrome開発陣の性根が良くわかりましたんでね。なかでも、pkasting@chromium.orgなる人物の発言には、正直言って、目を疑った。「ウチは民主主義じゃねぇんだよ（ｷﾘｯ」ってアンタねw。どんだけ自分とこのUIに自信があるかは知らんが、でけぇ口たたくのはApple以上のUXを提供出来るようになってからにしてくれや。

Flash統合の件なんかもそうなんだが、Googleはどんどん、技術主導の会社から政治主導の会社に変貌しつつある。俺たちゃそんなアバズレにゃ興味ねぇよ。「マップリデュース！」の呪文で俺たちをメロメロにさせたGoogleたんはどこに行っちまったんだ。

今回の件にしても、WebKit2の発表にビビって、慌てて付け焼き刃のしょーもない変更を加えただけなんじゃね？という印象がある。そこにはポリシーもなければテクノロジーも無い。ただ不毛で下衆な対抗心があるだけだ。そんな会社にUXなんて作れるわけねぇだろ。

[Programming] Chrome Extension は福袋的にした方が良い？

ここしばらく、ちまちまとChrome拡張機能をいじっております。で、「リンクのターゲットを_blankに書き換える」というありがちな拡張機能を試しに作ってみたわけです。正味の処理は

var l = document.querySelectorAll("a");
for (var i = 0; i < l.length; i++) {
  if (!l[i].target) {
    l[i].setAttribute("target", "_blank");
  }
}

だけという、実にあっさりしたもの。御存知の通りChromeでは各タブおよび拡張機能ごとにプロセスが割り当てられるわけですが、どれくらいメモリ消費してるのかなと思いアクティビティモニタを見たところ

ということで、えらくメモリ食うんだなぁとびっくりいたしました。

確かに Firefox でも OOPP を初めとするプロセス分離作業が進められているわけで、各プロセス毎に分厚い土台を準備しなきゃならなくなるというのも時代の流れなのでしょう。

この驚きはあの時の驚きに似てます。C から C++ に移行した時、バイナリの肥大化にのけぞった時の驚きです。ただの Hello World が iostream にしただけで何でこんなにでかくなるんだよｗというやつです。C は高級言語じゃなくて超高級マクロアセンブラだという説を心底納得出来たのもこの時でした。まぁ、libc からこのかた分厚い土台に支えられてきた人間がいまさらメモリ効率がどうこうなんて言えた義理じゃねぇだろ、というのも重々承知ではあるんですけどね。

で、こういった状況を鑑みまするに、今後は単機能な拡張機能を個別に数多く入れるという考え方よりも、色々な機能を詰め込んだ多機能な拡張機能を一つだけ入れるという考え方の方がメモリ効率的に良いということになります。「福袋的」というのはそういうことです。要るか要らないかは置いといて、とりあえず色々詰め込んどけという手法です。

でもやっぱりこの手法には違和感を感じざるを得ないんですわ。小人さんがわらわらと群がり手を取り合って仕事するというファンタジー的・明治合体チョコボール的世界、すなわち、コマンドをパイプでちまちまとつないでいく世界を知っている人間からしてみれば、上で述べたような福袋的アーキテクチャは「何このゴリアテｗ」「かっこ悪〜」となるんじゃないでしょうか。

[Google] Chrome Extension を作ってみて

やっぱWebKit系もやっとかんとね、ということでGoogle Chromeのdev版を入れてみたのですが、やはり気になるのは拡張機能の作りやすさ。ということで実際に作って確かめるためにこんなのを作ってみたわけです。

で、結論としては「Firefox（というかXUL）でExtensionを作っている人やGreasemonkeyでページをいじっている人にとってはストレスがたまるのでは？」という感じです。

content_scriptsの制限のきつさ
XMLHttpRequestもlocalStorageも直接には使えず、すべてbackground_pageを別途作製してsendRequestもしくはconnectしないと使えない、というのは異常に思えます。せっかくmanifest.jsonにpermissions設定があるのですからXMLHttpRequestくらいは直に使えるようにしてほしいところです。まぁcontent_scripts程度であればGreasemonkeyのChrome版でGM_系APIが実装されるまで待てということでいいんじゃないでしょうか。

コンテクストメニューへのアイテム追加などが出来ない
すくなくともドキュメントを見た範囲では出来ないようで、これはかなり痛い。UIをいじりたければWebKit APIを使えと言うことなのでしょうか。いずれにしてもXULのオーバーレイという一貫した設計思想とはかけ離れているようなので、また勉強し直しですな。

XUL慣れしているとかえってイライラする
これもGoogle側にしてみれば「おれにいわれてもなぁ」なので、仕方ないっちゃ仕方ないんですけどね。たとえば右クリックされた単語を拾うならばdocument.popupRangeParentとdocument.popupRangeOffsetを使うという定石がFirefoxでは使えるわけですが、Chromeではそんなプロパティは無いわけで、DOM Rangeで書き直しすることになりそうです。他にも「XULなら出来るのに」というのがどんどん出てくるんじゃないでしょうか。

まぁ「まだこなれていないだけだから気長にいこう」というのもアリなわけで、しばらくはちまちまと楽しませていただくことにします。