Home > Latest topics

Latest topics 近況報告

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

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

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

宣伝2。Firefox Hacks Rebooted発売中。本書の1/3を使って、再起動不要なアドオンの作り方のテクニックや非同期処理の効率のいい書き方などを解説しています。既刊のFirefox 3 Hacks拡張機能開発チュートリアルと併せてどうぞ。

Firefox Hacks Rebooted ―Mozillaテクノロジ徹底活用テクニック
浅井 智也 池田 譲治 小山田 昌史 五味渕 大賀 下田 洋志 寺田 真 松澤 太郎
オライリージャパン

Page 31/240: « 27 28 29 30 31 32 33 34 35 »

そろそろFirefoxからChromeへの移行を本気で検討した方がいい気がしてきた - Feb 07, 2010

B.B.S/2628 "タブバーのスクロール後タブバーが正しくリペイントされない" - outsider reflex

Tree Style TabとJetpackを入れるとタブバーをスクロールするとタブの残像が残ったままになる。

[str]
1. Firefox3.6を新しいプロファイルにTree Style Tab-0.9.2010020502とJetpack-0.7をインストールし起動する
2.タブバーがスクロールするように多数のタブを開く
3. スクロールバーまたはホイールスクロールによりタブバーをスクロールする

[actual]
タブバーが正しくリペイントされずタブの残像が残る

[expected]
正しくリペイントされる。

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100206 Namoroka/3.6.2pre ID:20100206050755

B.B.S/2629 "Re: タブバーのスクロール後タブバーが正しくリペイントされない" - outsider reflex

widgetがどうとかのGecko 1.9.2での修正(異常に縦に長いページのレンダリングが壊れる問題に対する修正)の影響だと思われます。JetpackではSlidebarの実装のためにtabbrowserと同じ大きさのbrowser要素をopacity:0の状態でtabbrowserの下に重ねていますが、こいつのせいでレンダリングがおかしくなっています。

タブのcollapsed属性をいじってるTMPの多段タブならともかくTab Kitでも問題が起こらないのはなんでなんだ?と思ってスタイルシートを調べてみた所、scrollboxでスクロールさせてると駄目で、その中のbox.scrollbox-innerboxに対するoverflow:autoでスクロールさせてる場合はこの問題が起こらないようです。

しかしscrollboxをoverflow:autoにした場合はnsIScrollBoxObjectのインターフェース経由でスクロール位置の操作が可能なのに対し、box.scrollbox-innerboxをoverflow:autoにした場合はnsIScrollBoxObjectのインターフェースが取れません。結果、画面の外に新しいタブが開かれた時にその位置まで自動的にスクロールさせるという事ができなくなります。

「Jetpack 0.7と組み合わせても問題が起こらないが、画面外にタブが開かれるとフォーカスを見失う」
「画面外のタブにフォーカスが行くと自動的にそこまでスクロールしてくれるが、Jetpack 0.7とは同時に利用できない」
どっちがいいでしょうか。僕は後者です。(どうせ現状のJetpackはなくなるそうだし、その過程でなんとかしてもらいたいと思ってます)

掲示板の方では「現状のJetpackはRebootで置き換えられるそうだからそっちに期待」的な事を書いたけど、下手したらReboot後でもずっとこのままなのかもなーという風な悲観的な予想も捨てきれずにいます。

norahさん曰く、同じ問題がサードパーティ製のテーマとJetpackとの組み合わせにおいても発生するそうです。既存のアドオン、既存のテーマについては「冷遇」して、JetpackとPersonasへの移行を促したいという事をMozillaの偉い人が言ってたらしいけど、実装レベルで着々と実力行使が進んでる感がありますね。

対するGoogle Chromeでは、タブの縦置きが試験的に実装され始めてるそうです。こんな事を書いたばかりですが、そろそろ本気でGoogle Chromeへのエクソダスを図った方がいいような気がなんとなくしてきました。

今までできていたことが少しずつできなくなっていく、締め付けが強まっていくストレスというのは、いざ自分が締め付けられる立場になるととても辛いものですね。それならいっそ、最初から制限がきつくても将来性のある新天地に移ってしまおう、と考えても変じゃないよなあと思いました。Mozilla SuiteからFirefoxに移行した時以来、レンダリングエンジンの違いで言えばDonutからMozillaに移行した時以来なので、今更それがほんとに可能なのかという不安はありますが。

xpcshellでタイマーやXMLHttpRequestなどの非同期処理を扱う方法(Gecko 1.9以降限定) - Feb 06, 2010

XPConnectも使えるコマンドラインのJavaScript実行環境で、xpcshellという物がある。XULRunnerをダウンロードするとおまけでついてくる。

  • 引数無しで実行すると対話インターフェースが起動する。irbみたいな感じで使える。
  • -fオプションを付けると外部のファイルをスクリプトとして実行できる。なので、JavaScriptでシェルスクリプトっぽいことができる。

xpcshell内ではWindowオブジェクトが無いので、当然だけどWindow.setTimeout()Window.setInterval()等を使った遅延処理は書けない。でもXPConnectは使えるので、nsITimerの機能を使えば似たようなことはできるはず。

という事で以下のようなスクリプトを書いて-fオプションで読み込ませてみたけど、実はこのままでは期待通りに動いてくれない。

var Cc = Components.classes;
var Ci = Components.interfaces;

function Timeout(aCallback, aDelay) {
  this.finished = false;
  this.callback = aCallback;
  this.init(aDelay);
}
Timeout.prototype = {
  init : function(aDelay) {
    this.timer = Cc['@mozilla.org/timer;1']
                  .createInstance(Ci.nsITimer);
    this.timer.init(this, aDelay, Ci.nsITimer.TYPE_ONE_SHOT);
  },
  cancel : function() {
    if (!this.timer) return;
    delete this.timer;
    delete this.callback;
    this.finished = true;
  },
  observe : function(aSubject, aTopic, aData) {
    if (aTopic != 'timer-callback') return;

    if (typeof this.callback == 'function')
      this.callback();
    else
      eval(this.callback);

    this.cancel();
  }
};

print('START');

var timeout = new Timeout(
    function() {
      print('3 SEC AFTER');
    },
    3000
  );

これを実行しても、「START」と出てすぐに終わってしまう。何故かというと、xpcshellはメインスレッドの処理が終わったらその時点でxpcshell自体を終了させてしまうからなのだそうだ。

UxU 0.7.6でも使ってるGecko 1.9以降のスレッド関係の機能を使うと、この問題を解消できる。さっきのスクリプトの末尾に以下を加えて実行すると、今度は「START」と出た3秒後に「3 SEC AFTER」「END」と出てからxpcshellが終了するようになる。

var thread = Cc['@mozilla.org/thread-manager;1']
              .getService()
              .mainThread;
while (!timeout.finished) {
  thread.processNextEvent(true);
}

print('END');

多分nsITimerのタイマー機能以外でも、これ(フラグが立つまでwhileでループ回してメインスレッドを止める)でうまくいくんじゃないかと思う。

XMLHttpRequestも試してみた。

var Cc = Components.classes;
var Ci = Components.interfaces;

var request = Cc['@mozilla.org/xmlextras/xmlhttprequest;1']
                .createInstance(Ci.nsIXMLHttpRequest)
                .QueryInterface(Ci.nsIDOMEventTarget);

var loaded = false;
request.open('GET', 'http://piro.sakura.ne.jp/', true);
request.addEventListener('load', function() {
  print(request.responseText);
  loaded = true;
}, false);
request.send(null);

print('REQUESTING...');

var thread = Cc['@mozilla.org/thread-manager;1']
              .getService()
              .mainThread;
while (!loaded) {
  thread.processNextEvent(true);
}

print('END');

これも、ちゃんとレスポンスが帰ってきてから終了した。

ツリー型タブのGoogle Chrome版は作らないの?(Tree Style Tab for Google Chrome) - Feb 05, 2010

Q

Any plans to add Tree Style Tab to Google Chrome or Chromium?

ツリー型タブをGoogle ChromeもしくはChromiumに移植する計画は無いの?

A

Now I have no plan to export Tree Style Tab to Chrome. The fact "Tree of tabs are permanently shown, without any operation" is the best benefit of Tree Style Tab for me. Currently there seems to be no API to do it. I don't want to use such a feature if clicking on a toolbar button (or any other operation) is required to show the view.

Moreover, it is the main reason of my development that I want to improve my PC environment. Because I'm not planning to switch to Chrome, I will not develop Chrome extensions.

By the way, there are some similar extensions VerticalTabs, Tab Menu, and Tree Style Tabs (Beta) (Note: it has same name but it is NOT my product!). They possibly help you.

Updated at 2012-11-22: More extensions, Sidewise Tree Style Tabs and Tabs Outliner are available now. They are good alternative of Tree Style Tab on Google Chrome.

今の所、私自身がツリー型タブをChromeに移植する予定はありません。私は、「ツリー型タブ」の便利な所は「タブの一覧(ツリー)が常時表示されている」点だと思っています。現状のChromeの拡張機能向けのAPIでは、そのような拡張機能は残念ながら作ることができないようです。ボタンをクリックしないとツリーが表示されないような機能は、自分は使いたくないです。

また、私自身の開発のモチベーションは主に「自分が日常的に使う環境を使いやすくしたい」という所に支えられています。私は今の所Chromeを常用するつもりが無いため、Chrome用拡張機能を開発するモチベーションがありません。

なお、似たような拡張機能でVerticalTabsTab MenuTree Style Tabs (Beta)(注:同じ名前ですが私が開発した物ではありません!)というものがあります。まずはこれらを試してみてください。

2012-11-22追記:その後、Sidewise Tree Style TabsおよびTabs Outlinerという拡張機能が公開されています。これらを使うと、ツリー型タブにより近いユーザー体験をGoogle Chrome上で得られます。

ツリー型タブでタブバーの「新しいタブ」ボタンを隠せなくなった(How to hide "New Tab" button in the tab bar?) - Feb 05, 2010

Q

I just updated the Tree Style Tab addon and the new tab button that used to be hidden is now visible. Is there a way to hide it? I always use Ctrl-T, so it just wastes space.

ツリー型タブを更新したら、今まで隠れていた「新しいタブ」ボタンが表示されるようになってしまいました。これを隠す方法はありませんか? 私はCtrl-Tをいつも使っているので、このボタンは不要です。

A

Sorry, I removed the option because it is not a feature related to "tree". Instead, you'll hide the button by customizing your userChrome.css like:

.tabs-newtab-button {
    display:none !important;
}
/* hide the "shadow" */
tabbrowser
  .tabbrowser-strip
  .tabbrowser-tab
  .tabs-container
  .scrollbox-innerbox {
    background-image: none !important;
}

Note: These examples work on Tree Style Tab 0.8.2009100101 or later.

すみません。「ツリー」と関係ないものだったので、その機能は削除してしまいました。代わりにuserChrome.cssに上記のようなスタイル指定を書き加える事で、ボタンを非表示にできます。

縦置きタブバーの下にサイドバーを統合するUnified Sidebarをリリースしたよ - Feb 05, 2010

とりあえずMozilla Add-onsに置いた

ツリー型タブに対して表題のような要望が寄せられることが何度かある。ツリーと関係ないからツリー型タブにそういう機能を入れる気はないんだけど、まあそういうニーズはあるんだろうなというのは理解できる。なので以前にuserChrome.cssでそれっぽくする方法を考えてみたりもした。その時の結論としては「ちゃんとアドオンにしないと駄目だね」という感じだったんだけど、結局誰もアドオン化してくれてなかったようだったので、仕方がないから自分で作った。

このアドオン自体はタブを縦置き表示する機能は持ってません。単にサイドバーの表示位置を変えるだけです。タブを縦置きするにはuserChrome.cssで頑張るか以下のアドオンを使って下さい。

他にもタブを縦置きするアドオンがあれば、なるべく連携するようにはしたいので、このエントリにコメント付けるなどして教えて下さい。

タブをまとめてリロードする時にちょっとずつリロードを行うようにする「Reload Tabs Progressively」をリリースしたよ - Feb 02, 2010

とりあえずMozilla Add-onsにうぷした

マルチプルタブハンドラについて「複数のタブをリロードする時、全部一気に読み込み始めるんじゃなく、3秒ずつ位間を空けて読み込むような機能を付けて欲しい」という風な要望をもらったんだけど、マルチプルタブハンドラに依存する機能にするよりは単機能で使えるようにしといた方がいいような気がしたので、サクッと作って公開した。

  • BarTapで待機状態になってるタブについては、リロードではなく普通の読み込み開始になります。
  • ナローバンドだったりPCが遅かったりすると効果的かもしれない。
  • 副作用として、いつまでもリロード中になってしまうようなページ(Cometでセッション張りっぱなしでレスポンスを待つようなページ)があると他のタブの再読み込みがいつまで待っても始まらないかもしれません。
  • tabbrowser要素のreloadTab()メソッドとreloadAllTabs()メソッドをゴッソリ入れ替えてるので、この辺を触ってるアドオンがもしあったら衝突するかも。

こういう風にブラウザそのものの挙動を変えてしまうアドオンはChrome(Chromium)では作るのは難しいような気がするけど、実際にチャレンジしたわけではないので、ほんとのところはどうなんだろ。

束縛 - Feb 01, 2010

ひょっとしたら同じような事を既に書いたかもしれないけど。

僕は、あまり束縛はしたくないと考えてる。理由はいくつかある。

  • 相手が嫌がる事をなるべくしたくない。束縛されるのは嫌だと言ってる人の事を束縛するのは、タバコが嫌いだと言ってる人の目の前で喫煙するのと同じような事だと思ってる。
    • それで自分が嫌われるのが怖い。
    • 相手のためを思いやって、というのが全く無いわけではないと思うけど。
  • 束縛しても無駄だと思ってる。同じ家に住んでて、同じ会社で働いてて、という風な条件でも揃ってない限り、完璧な束縛は不可能だと思う。抜け道はいくらでもある、浮気とか二股とかやろうと思えばいくらでもできる、と思う。
    • 「束縛しないと浮気される」のであれば、その関係は既に破綻してるんだと思う。
    • そんな状態なんだったら、束縛しててもそれをかいくぐって浮気する道を探られるんじゃないの?
  • 行動は縛れても、思想は縛れないと思ってるし、縛ろうとしてはいけないと思ってる。
    • 表現の自由は大事ですよ。
  • そもそも束縛するのが面倒というのもある。
    • 相手の一挙手一投足を監視するのって、それだけで大変だろう。自分の気も休まらないだろう。
    • 探偵とか興信所とか、そんなお金ありません!

「不安にならないのか?」と訊かれたけれども、不安がってもしょうがないというか、相手が束縛を嫌がるからという理由でまず「束縛したくても束縛できない」し、束縛されるのを嫌がってるのを無理に束縛するのはただの嫌がらせにしかならないと思うし、束縛したって(腰の退けた束縛の仕方にしかならないから)いくらでも浮気二股やろうと思えばできると思うし。結局、相手の言ってる事を信じるしかないよね。という感じで僕は開き直ってます。

もちろんその信用を裏切られる事はないと思いたいけれども、もし裏切られても、まあいいか、と。もちろん、本当に裏切られたらきっとものすごいショックを受けるだろうけれども、でも「裏切られる事」を恐れて束縛を強めることが結果的に相手を「裏切り」に走らせる事に繋がるのなら、束縛してもしなくても結局同じだと思う。僕は相手の事を信じる事にした、その上で相手が僕の事を裏切る事にしたんだったらそれはもうどうしようもないだろうなあ、と。裏切って欲しくないと僕が思っていて、そう言っていて、それでも裏切らずにはいられなくなったのであれば、そりゃもうしょうがないよね、と。

ところで、束縛というと「相手が自由意志で何かをしようとすることを、無理矢理引き留める」というイメージがあるけど、「相手がやりたくないと思ってる事を、無理矢理やらせる」のも本質的には同じ事だと思う。料理が嫌いな人に手料理を無理矢理作らせたりとか。クリスマスやバレンタインデーといったイベント事に何かする事を強要したりとか。

束縛って、要は相手の事を完全に支配したい、コントロール下に置きたいと願うという事だと思う。相手をコントロールしたいなんておこがましいと僕は思うし、コントロールしきれるとも思ってない。じゃあ、そんな僕が相手を束縛するというのは、コントロールしきれるとも思ってないしコントロールする権利もないと思っている相手の事を、コントロールしようとするという、賽の河原で石を積むような行為だよね。それって意味無いよね。と思ったら、束縛する気が萎えてしまいました。そんな感じ。

コアJetpackミーティング - Jan 26, 2010

23日にMozilla Japanで行われたコアJetpackミーティングに参加してきました。2月にGomitaさんとあかつかさんがMozilla Corporationまで行く時に持って行く意見・アイデア等をまとめるのが趣旨の会合でした。Mozilla信者な視点だけからでは意見が偏るんじゃないかと思ったので、Chrome拡張機能のえらい人のos0xさんにも来てもらいました。

議題は「Jetpackのスクリプトの開発環境について」「Jetpack Galleryについて」「Jetpackが提供するAPIについて」の3つでした。以下、思い出しながらグダグダ書いてみます。

開発環境について

既存のアドオンを冷遇していくとかの話はさておき、これまで普通のアドオンを作ってた人が、Jetpackで事足りるような機能についてはJetpackでやるようになる、という未来を実現するには何が必要か? という話をしました。

結論としては、Bespin要らないんじゃね、ていうか好きなエディタを使わせて下さい、的な所に意見が集中しました。Bespin自体技術デモの性格が強いような物で、IMEがまともに使えない等のどうしようもない問題を沢山抱えていて、はっきり言って「これで(vim|Emacs|秀丸)を捨てられる!」みたいな未来は当分、つうか絶対に来ないと思われるわけで。かといって、eclipseみたいなファットな開発環境をJetpackの中に突っ込むというのも、それはなんか違うんじゃないの? とも思うし。既にデバッグ用にはFirebugを使うのがお勧めみたいな事も言ってる事だし、適材適所でそれぞれ分担すりゃいいじゃないの。頑張ってここ(BespinとJetpackの連携)に色々と機能追加する事にリソースを作よりも別の所で頑張りませんか? というのが、参加者達の総意だった気がします。

「新規のアドオン開発者」として取り込みたいターゲットと思われるWeb制作の現場の人のためには何をすればいいか? という事を次に議論したんですが、参加者の中にWebデベロッパが一人もいないという状況だったので(ひでーな!)想像だけで議論した限りでは、とりあえず、「スクリプトの頭と尻にお約束の構文を書いたら後はwindow等の見慣れたキーワードに普通にアクセスできる」ような状態にしておいた方がいいんじゃないのか、という事を提案しました。Greasemonkeyが受け入れられたのって、Webページの中に埋め込まれるスクリプトと全く同じ感覚で書けたからだと思うんですよね。で、Webのスクリプトを書く時、名前空間の違いとかクロスウィンドウなスクリプトとかそういうのを意識する事ってまず無くて、1つのフレームの中で動くスクリプトを書く感覚が染み着いてるんじゃないのかと。その感覚でスクリプトを書けるかどうかってのが、Webデベロッパに対する第1印象を決定づけるんじゃないのだろうかと。ちなみに、Google Chromeではこの要求に対する回答として、「コンテントスクリプト」という種類の拡張機能であればWebページ内のスクリプトと同じ感覚で書けるという設計になってるようです。

一般ユーザ、つまり今までアドオンを作った事もなければスクリプトを書いた事もないという層の人に対してはどうか。

グラフィカルプログラミングがどうとかそういう話もチラッと出はしたんですが、そこに力を入れるのもやっぱりJetpackの仕事じゃないんじゃないの? と。そういうのは大学の研究室とかで頭のいい人達が散々やってるわけだし。

ポイントは、「簡単にプログラムをかけるかどうか」「知識が無くてもプログラムをかけるかどうか」ではなくて、そもそも「プログラムを書かなくてもカスタマイズできるかどうか」なんじゃないのか、という指摘が出てました。Ubiquityでは複数のコマンドをユーザが組み合わせて使う事を想定している(これはコマンドラインで複数のコマンドをパイプで繋げて使うような感覚)、というのを引き合いに出して、例えるなら「新しい文房具を簡単に作れるようにする」んじゃなくて「ハサミとホッチキスとセロテープ、という道具を手に入れたユーザがそれを好きなように組み合わせて使えるようにする」という風な。そこが大事なんじゃないのか、と。だから例えばAutoPagerizeのSITEINFO on wedataとか、アップローダに勝手改造版スクリプトをアップロードするみたいな、「スクラッチでスクリプトを書ける人以外でも気軽に改良できる、参加できる」ような仕組みがあるといいんじゃないか? という提案が出ました。そういうAPIがJetpackに標準で入ってて、Jetpack GalleryでユーザがSITEINFOをどんどん追加できるようになってて、APIを使っていればそれを簡単に取得できる、みたいな仕組みが用意されていれば、もっと「Webを便利にしてくれる人」の裾野が広がるのではないかなー。と、僕は思ってます。

Jetpack Galleryについて

Jetpack Galleryへの要望・提案としては、まず前述の話にも出た、JetpackのAPIとも連携したwedataのような仕組みがあるといいんじゃないかという話を出しました。

それと、ドキュメント類が不足してる問題への解として、Galleryに登録されてるスクリプト全部をオンラインで検索できるMXRみたいな機能があればいいんじゃないの?という話も出しました。実際、自分がアドオン作る時でも、使い方が分からないAPIはMDCのドキュメントを見るだけでなく、MXRでFirefoxのソースを検索して「ほうほうこうやって使うのか」と調べる場合が非常に多いです(MDCにドキュメントが無ければそれしかないし)。ドキュメントを書け書けと言っても人はめんどくさがって絶対にそんなもん用意せんのだから、じゃあ既にあるコードをスニペットとして全部活用できるようにすりゃあいいじゃないか、という意図での提案です。

現状のGalleryにはレビューの仕組みがないので危険だ、という話も出ました。これは次の話にも関係してるので、そっちで詳しく書く事にします。

APIについて

ここは議論が割れました。あかつかさんはrawのような仕組み、つまりAPIが用意されてない部分にアクセスしてその気になればなんでもできるような余地を残しておいた方がいいんじゃないのか、という立場で、僕とかは、そういう余地は一切残すべきでないという立場で話をしました。

確かに、そういう余地があったからこそ今のFirefoxのアドオンはここまで色々なものが出てきたわけで、そういう自由度をなくしてしまうのは残念だという感覚は、僕もよく分かります。ただ、だからってFrozenじゃない所に全部アクセスできるようにしてしまうというのも乱暴すぎて、それじゃあ結局今のアドオンのように、Firefoxのバージョンが上がったら使えなくなっちゃいました、アドオンのバージョンアップ待ちです、みたいな状況が絶対また出てくる。それって、Jetpackが謳う「安定したAPIでバージョンごとの非互換から解放されます」という話とまるっきり矛盾してしまうわけです。

それに、レビューの問題もある。今はJetpack GalleryにはAMOのような「レビューが通らないと一般公開されない」という風な仕組みはないけど、「最初は無難そうなスクリプトで登録して関係者を欺いて、後からプライバシーぶっこ抜きなコードを追加したものを自動アップデートで一斉配信して、悪意のある開発者がウマー」という事態を防ぐには(今のGalleryではこれが出来てしまう!)、レビューの仕組みは絶対必要になります。

その時に、rawで生のXPCOM等を直接触れてしまう仕組みがあると、レビュワーは結局全部のコードをしっかり精査しないといけないことになる。レビュワーにも知識と経験が求められる。それでは、今のAMOにありがちな「有能なレビュワーのリソースは限られてるので、レビュー完了まで何ヶ月も待たされてしまう。なので、何ヶ月も最新版が公開されないで放置されてしまう。」という風な状態が、Jetpack Galleryにも発生してしまうわけです。

Jetpackが提供するAPIしか使えないのなら、そういう状況に陥る事を防げる。例えば、「Jetpackが提供するAPIでなければファイルにアクセスできないと」いう仕様で、スクリプトの先頭に書く各種の宣言部分で「このパス以下のファイルしか読み込みません」という宣言を書かなければファイルアクセスは一切できない、ファイルアクセスをする時も宣言された範囲のファイルにしかアクセスできない、そういう設計になったとしましょう。すると、レビュワーは冒頭の宣言部分だけ読めば「こいつは危険だな」とか「こいつは安全だ」といった判断ができて、レビューが早く進むようになる。また、スクリプト作者が面倒くさがって「あらゆるファイルにアクセスする可能性があります」みたいな宣言を書くと、レビュワーから疑われていつまでも放置されるから、いつまで経っても公開されないことになる。なのでスクリプト作者は詳細な指定を宣言に嫌でも書かないといけない事になる。そういう風に、みんながみんな自分の利益を最大化する事が結果としてコミュニティ全体の利益に繋がるような仕組みを、今から作る事ができるわけです。

Jetpackという仕組みをゼロから作ろうとしてる今こそ、過去のアドオンの「Firefoxのバージョンに依存する」「レビューにめちゃめちゃ時間がかかって、いつまでも最新バージョンが公開されない」という問題と決別するチャンスなんですよ。なんでそのチャンスをみすみす見逃して、同じ問題をまたJetpackの世界に持ち込むんですか? と。

だいたい、Jetpackが本体に入った後も既存のアドオンの仕組みは依然として残り続けるわけで、偉い人はXULとXPCOMを全部なくすとか言ってるけど実際にコアのコードを書いてる人曰く「そんなの絶対無理(加藤さん・談)」なわけで、だったら「安定したAPIのJetpackで、まずは作ってみる。それでできない事が出てきたら、自由度の高い(でもAPIが不安定な)既存のアドオンの仕組みで作る方にステップアップする」というスキームでやっていけばいいじゃないですか。と。

他には、プラットフォーム(XULRunner、Geckoのレイヤ)でやるべき事とJetpackがやるべき事はちゃんと切り分けて欲しいという話も出ました。例えば音声取り込み用のAPIなんてのは、Jetpackにプラットフォーム別のバイナリをブチ込むんじゃなくて、Geckoで面倒見るべき話でしょう。そのせいでJetpackの構成ファイルが何MBにもなってダウンロードも起動も遅くなって、その一方で、ほんのちょっと起動を速くするためにFUELを廃止するって、何ですかそれは? 何か大事な事を履き違えてるんじゃあないですか? と。

とにかく、Jetpackというプロジェクトが何にフォーカスしているのか、プロジェクトのポリシーが僕には全然見えない。Jetpackをウォッチし続けてるcon_mameさんもteramakoさんも、Jetpackの方針が揺らいでるように見えるという風におっしゃってました。なので、Mozilla Corporationに行く時にはGomitaさんとあかつかさんにはぜひとも、Jetpackが最優先しようとしているのは何なのか? 他のものを犠牲にしてでも貫かないといけないと考えているポイントはどこなのか? というプロジェクトの指針を明らかにしてきて欲しい、という事をこのミーティングの参加者達の最大の関心事として託しておきました。

余談:イノベーションの話

ミーティングの最中にtwitterで言及されてMicrosoftのAzureの話を読みました。既存の開発者のために腐心しすぎるとイノベーションが起こらなくなってしまう、僕のようなロートルがいつまでもでかい顔して居座っていられるような状況にしてしまっては新しいプレーヤーが参入して来れない、というのは実に耳の痛い話だと思いました。

もちろん将来的に、いつかはJetpack自体も今のアドオンのように「もう時代遅れだ」と冷遇され切り捨てられる時代が来るのかもしれません。が、それはその時に考えればいい事なんじゃないかと僕は思います。

しかし自分が特に耳が痛いのは、既存プレーヤーがデカいツラしやがるという話です。自分の既得権益、自分の居場所を守るために必死に抵抗すればするほど、自分自身が今のまま何も変わらずに一線に立ち続けようとすればするほど、自分がすがりついている物の未来を奪う事になって、自分も他の人も不幸にする。「シーンの最前線から退く覚悟はあるか?」というエントリは、本文の内容は全然この話題と関係ないし趣旨も違うけど、でも僕は最近この事を考えがちなので、タイトル見ただけでこの事に結び付けて受け取ってドキッとしました。みんなのためを思うなら、老兵は黙って去って、不幸になるのは自分だけで終わらせないといけないんじゃないのか。

余談:Mozillaの生き残り戦略について

Microsoftは、Windows 95上でWindows 3.1用のアプリの動作を保証するために、Windowsの側で頑張って対策をしてまで互換性を維持したそうです。VistaのUltimateだったかWindows 7だったかではWindows XPとの互換性を維持するために仮想マシンまで用意しました。昔のAPIでも、「obsolete」という風にはMSDNに書いてあっても、動く事は動くという状態でずっと残ってるそうです。そういう「とにかく過去のソフトウェア資産を使い続けられるようにする」戦略をMicrosoftは取り続けて、製品はいまいち垢抜けない物ばかりになってしまいましたが、その結果としてシェアはものすごい事になりました。圧倒的多数の凡人がちょっとずつ落とすお金のおかげで、Microsoftは食えてます。

Appleは、ジョブズが思い描く「素晴らしいプロダクト」を目指すために、古いAPIを容赦なく切り捨ててがんがんアップデートしてます。Mac OS Xで「obsolete」となったAPIは、2つ後のバージョンくらいではもう綺麗さっぱり消えてしまうそうです。その結果、ついていけない脱落者が多くなるし、世界の過半数を占めるようなものすごいシェアは獲れてない。けれども強烈な信者ができて、彼らのおかげでAppleは食えてるわけです。

Googleは広告のシェアをガッツリ掴む事で、Operaはモバイル市場をガッツリ掴む事で、食っていってますよね。

で、Mozillaはどんな道を歩むつもりなんでしょうか。

今までの路線を見る限り、安定版リリースの寿命は短い(次のメジャーバージョンが出たら前のバージョンは半年で更新が打ち切られる)し、安定したAPIになるとか言ってたFUELもメジャーバージョン2つと保たずに黒歴史になってしまいそうだし、どう見てもゲイツよりはジョブズの生き方に見える。でも、ジョブズがジョブズの生き方を貫けてるのはあくまで、信者がお金を出して高い製品を買ってくれてるからですよね。でもこれって、言ってみればブランド物の生き残り戦略ですよね。Mozillaは物を売ってないから、その戦略じゃあ明日のおまんまが食えなくなるんじゃないの? 開発者を養っていけなくなるんじゃないの? そこが僕は心配でならないです。「いやオープンソースでバザールだから開発者はみんな善意で関わり続けてくれるんだよ」、という反論はすぐに思いつきますけど、今は世間はみんなWebkitに流れてますよね。オープンソースの開発者も、Geckoより将来有望な(ように見える)Webkitに流れていくんじゃないですか? その時、Geckoに関わり続けてくれる開発者はどれくらい残るんでしょうか?

上に挙げた各社のどれとも違う別の道を歩む、というのが多分、Mozillaにとっての模範解答なんでしょうけどね。その「別の道」ってのが一体何なのか、僕にはまだよく分からんです。

HIVの無料検査 - Jan 21, 2010

そういえば、公共広告機構のCMで「彼氏の元カノの元彼の……」というのがありましたね

思う所があって、受けてきましてん。

  • HIV(ヒト免疫不全ウィルス、いわゆるエイズウィルス)は感染してもすぐには発覚しない。感染から2ヶ月が経過した頃にようやく、検査で検出できるようになる。
  • HIVに感染すると、一方ではHIVに対する抗体が猛烈な勢いで作られ、一方ではHIVによって免疫系が猛烈な勢いで破壊され、という平衡状態になる。これが「HIVキャリア」の状態で、この平衡が崩れてHIVの方が勝ったらいよいよ「発症」ということになる。キャリアの状態は、長いと10年にもなる事もある。
  • HIVの検査は、この「HIVに対する抗体」ができているかどうかを見て行う。感染していると上記のように抗体が作られるので、「HIV抗体反応陽性」=「感染してる」、「HIV抗体反応陰性」=「感染してない」という判別ができる。

今は、献血で集めた血からHIV抗体陽性反応が出ても、その血を黙って捨てるだけで本人には絶対に通知しないそうですね。タダで検査結果を知りたい時は、各地でやってる無料検査に行くしかないようです。

  • HIV検査・相談マップを使うと、条件を指定して最寄りの検査所を検索できる。
  • 検査所の中には、いつもやってる所と、月1回検査・月1回結果発表という風なサイクルで時々やってる所がある。

僕の場合は、区役所で月1回やってるという検査に行ってきました。

  • 何はともあれ、まず電話で予約します。名前は聞かれませんでした。何人受けに来るという事だけ把握するみたい。
  • 僕が受けた検査所の場合、検査は月に1回朝9時から10時までの間の受け付けで、来た人から早い者順で受けられるそうです。僕は9時30分頃に行きましたが、同時に受けてた人は1人だけで、すぐに検査してもらえました。
  • 当日検査所に行くと、説明を受けた後に申込書類に記名させられます。本名を書く必要はなくて、偽名でもニックネームでも有名人の名前でもなんでもいいそうです。僕は面倒なので本名を書きましたが。
  • オマケで他の性感染症の検査も一緒に無料で受けられます。僕が受けた説明では、クラミジア、淋病、梅毒の3つが受けられますよとのことだったので、せっかくだから全部受けました。
  • HIVの検査自体は、採血だけです。血を抜いて、血が止まるまでガーゼで押さえておしまいでした。
  • 他の性感染症の検査を受ける場合は、この後検尿があります。小学校の頃とかに言われた「最初の尿は捨てて……」ではなくて、逆に「最初の尿から取って」と言われました。

検査はこれでおわり。後はまんじりともしない気分で検査結果が出る日を待つばかりです。

で、結果発表の日。僕が受けた検査所ではこれも月1回だそうです。

  • 結果発表は個別の面談のみ。電話や郵送では結果を教えてもらえません。行きそびれるとまた1ヶ月まんじりともしない気分で待つことになります。
  • 検査結果を聞きに行く時は、検査を受けた時の申込書類の控えを持って行きます。そこに書いてある番号で結果を見つけてくれます。
  • 僕が受けた日には他にも4~5人受けてたようですね。ファイルを見せてもらう時に見えましたが、僕の検査結果の上下に数名、他の人の検査結果も記載されていたようです。プライバシー保護のためか、全員それぞれの結果には付箋が貼ってあって、説明する時だけその付箋を外して結果が見えるようになってました。
  • 白でした、あるいは黒でした、という風な証明の書類はもらえません。証拠が欲しい時は多分、病院に行って自費でもう一度検査してもらわないといけないみたいです。

検査結果はすべて陰性でした。ただし、HIVについてはあくまで「2ヶ月より前のことについては感染の心配はありません」という言い方なので注意が必要です。

「大丈夫だろ」と思ってる時に限って最悪の結果が帰ってくる、という事があったりなかったりするので結果を聞くまで安心はできないわけですが、試験と同じで受けたらもう結果が出るのを待つしかなくて、祈ろうが呪おうが結果は変わらないので、結果待ちの間は無我の境地でした。検査を受ける前と、結果を聞く直前が、一番gkbrだった気がします。

またネットワークに繋がらなくなった→/etc/network/interfacesを編集したらなんとかなった - Jan 18, 2010

WEPで無線LANに繋がらなくなったのでWPAにしたあと、正常に動いてるように見えたし、ハイバネーションからの復帰後もちゃんと動いてたんだけど、Ubuntuのアップデートがかかってその後再起動したらまたネットワークに繋がらなくなってしまった。

ログビューワでログを見た感じではハードウェア自体は認識されてるようで、 検索結果の見よう見まねで /etc/network/interfaces を以下のように編集してsudo /etc/init.d/networking restartしたら、とりあえずネットワークには繋がるようになった。

auto lo
iface lo inet loopback

auto wlan0
iface wlan0 inet dhcp
wpa-essid ssid
wpa-psk 共有キー

が、この状態だとGnomeパネル上のNetwork Managerアプレットが全く機能しなくなって、無線のアクセスポイントも何も切り替えられない。

キーワードを変えてさらに検索していたら、/etc/network/interfacesを消せばなんとかなるという話があったので、これ危なそうだなーと思いながら試してみた(interfacesを別の名前に変更してみた)ところ、再起動したらNetwork Managerアプレットがちゃんと動くようになった。WPAのアクセスポイントにもつながってる。

でもCtrl-Alt-F2とかでコンソールに切り替えるとログインプロンプトが出てなくて、これでまたトラブルになったら手の施しようがないと思ったのでもう少し検索してみたところ、今度はUbuntuフォーラムのやり取りがヒットした。やっぱりというかなんというか、最低限の記述はないといけないのか。ということでinterfacesの内容を以下のように削って最小限(?)にしてみた。

auto lo
iface lo inet loopback

auto wlan0

再起動したら、Ctrl-Alt-F2でもログインプロンプトがちゃんと出てて、Network Managerで無線LANにも繋がるという状態になった。

Page 31/240: « 27 28 29 30 31 32 33 34 35 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき

オススメ

Mozilla Firefox ブラウザ無料ダウンロード