ユーザースクリプトと製作者スクリプト ― 2008年08月02日 02時25分
あと、動作の細かな話ですが、オリジナルのAutoPagerizeとかぶってしまう（二重に読み込まれてしまう）ため、あえてa要素のrel属性（rel=”next”）を外して対処しています。
同じ機能を提供するユーザースクリプト (Greasemonkey スクリプト、Web ページに変更を加えるブラウザの拡張機能など) と製作者スクリプトがあった場合、その競合をどう解決するかということについて。最初は単にユーザースクリプト (ここでは特に AutoPagerize) を製作者スクリプトから無効化できるようにすればいいのかなと思いましたが、「3:14 - UserAgentの使い方について」を読んで考えを改めました。
ユーザースクリプトはブラウザの機能を補うものであり、ブラウザがもともと持っている機能と同一視できます。ある機能を (一般の Web ページを対象とした) ユーザースクリプトで実現するということは、それをブラウザの機能として、すなわち統一された操作感の下で提供するということです。同じ機能は同じ操作で実現できることを第一とするなら、ユーザースクリプトと製作者スクリプトとではユーザースクリプトのほうを優先させるべきです。
ではそのためにはユーザースクリプト、製作者スクリプトをどのように書けばいいのでしょうか。とりあえず考えてみたのが以下です。(本当に考えただけです。動かしてもいません。) 本題とは関係ありませんが、AutoPagerize のソースコードには文末にセミコロンがつけられていないんですね。
--- autopagerize.original.user.js 2008-08-01 17:16:41.531250000 +0900
+++ autopagerize.user.js 2008-08-02 01:09:41.500000000 +0900
@@ -28,6 +28,7 @@ var CACHE_EXPIRE = 24 * 60 * 60 * 1000
var BASE_REMAIN_HEIGHT = 400
var FORCE_TARGET_WINDOW = true
var USE_COUNTER = true
+var FORCE_AUTO_PAGER = true
var SITEINFO_IMPORT_URLS = [
'http://wedata.net/databases/AutoPagerize/items.json',
]
@@ -575,7 +576,11 @@ var launchAutoPager = function(list) {
}
}
else {
- ap = new AutoPager(list[i])
+ var event = document.createEvent('Event')
+ event.initEvent('AutoPagerizeReady', true, !FORCE_AUTO_PAGER)
+ if (document.dispatchEvent(event) || FORCE_AUTO_PAGER) {
+ ap = new AutoPager(list[i])
+ }
return
}
}
// 製作者スクリプト
if (document.addEventListener) {
document.addEventListener("AutoPagerizeReady", function (event) {
if (event.cancelable) {
// イベントがキャンセル可能 (ユーザースクリプト中の
// FORCE_AUTO_PAGER の値が偽) ならキャンセルする。
// このとき、製作者スクリプトの MyAutoPager が使われる。
event.preventDefault();
} else {
// イベントがキャンセル可能でないなら
// MyAutoPager を無効化して AutoPagerize を使う。
disableMyAutoPager();
}
}, false);
// AutoPagerize を使っていない環境ではそもそも
// AutoPagerizeReady イベントが発生しないので
// MyAutoPager がそのまま使われる。
}
initMyAutoPager();このようにすれば、機能が衝突したときに、ユーザースクリプトを使うか製作者スクリプトを使うかをユーザー側で決定できます。常にユーザースクリプトを優先したいが、製作者スクリプトに無効化機能が公開されていない場合は、そのサイトの製作者スクリプトを無効化するユーザースクリプトを作る必要があるかもしれません (そのようなスクリプトを作るのが難しいことも多いでしょうが)。イベントを使うというアイデアは「Greasemonkeyスクリプトとウインドウ間で安全に通信する - ロックスターになりたい」からいただきました。
ある機能に関するスクリプトにも CSS のように、重要指定付きユーザースクリプト、製作者スクリプト、通常のユーザースクリプトと排他的な優先順位を設定する仕組みが整っていればいいんですけどね。排他的というより多層的といったほうがいいような気がしてきました。
JS オタが非オタの彼女に JavaScript 世界を軽く紹介するための 10 実装 ― 2008年08月03日 20時00分
アニオタが非オタの彼女にアニメ世界を軽く紹介するための 10 本が流行っているようで (◯◯オタが非オタの彼女に◯◯世界を紹介するための 10 本まとめ)。えっ、もうブームは去った? まあそんなこと気にせず勝手にいっちゃいます。
軽く紹介するための 10 本
まあ、どのくらいの数の JS オタがそういう彼女をゲットできるかは別にして、「オタではまったくないんだが、しかし自分のオタ趣味を肯定的に黙認してくれて、その上で全く知らない JavaScript の世界とはなんなのか、ちょっとだけ好奇心持ってる」ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、JavaScript のことを紹介するために見せるべき 10 実装を選んでみたいのだけれど。(要は「脱オタクファッションガイド」の正反対版だな。彼女に JavaScript を布教するのではなく相互のコミュニケーションの入口として)
あくまで「入口」なので、時間的に過大な負担を伴う SML、PHP 製の実装は避けたい。できればオブジェクト指向言語、手続き型でも C 言語製にとどめたい。あと、いくら JavaScript 的に基礎といっても古びを感じすぎるものは避けたい。ブラウザ好きが『Mosaic』は外せないと言っても、それはちょっとさすがになあ、と思う。そういう感じ。
彼女の設定は
- JavaScript 知識はいわゆる「Java」と混同してるのを除けば、うざいポップアップ程度は見ている
- ギーク度も低いが、頭はけっこう良い
という条件で。
まずは俺的に。出した順番は実質的には意味がない。
SpiderMonkey (Mozilla Foundation)
まあ、いきなりここかよとも思うけれど、「JSRef 以前」を濃縮しきっていて、「JSRef 以後」を決定づけたという点では外せないんだよなあ。実装言語も C 言語だし。
ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。この派生過多な実装について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報を彼女に伝えられるかということは、オタ側の「真のコミュニケーション能力」の試験としてはいいタスクだろうと思う。
DMonkey (Project DMonkey)、ExtendScript (Adobe Systems)
アレって典型的な「オタクが考える一般人に受け入れられそうな実装 (そうオタクが思い込んでいるだけ。実際は全然受け入れられない)」そのものという意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには一番よさそうな素材なんじゃないのかな。
「JS オタとしてはこの二つは“マクロ言語”としていいと思うんだけど、率直に言ってどう?」って。
JE (Father Chrysostomos)
ある種の軽量言語オタが持ってる Perl への憧憬と、XS いらずのオタ的な Pure-Perl へのこだわりを彼女に紹介するという意味ではいいなと思うのと、それに加えていかにも CPAN な
- 「コンバート的なださカッコよさ」を体現する Perl/JS オブジェクトの相互変換
- 「ストリーム的に好みなデータ」を体現する直列化可能性
の二つをはじめとして、オタ好きのする機能を世界にちりばめているのが、紹介してみたい理由。
Narcissus (Brendan Eich)
たぶんこれを見た彼女は「ナルシストだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。
この系譜の実装がその後続いていないこと、これがアメリカでは大人気になったこと、日本ならオレオレ言語ブームになって、それがブラウザ上で動かされてもおかしくはなさそうなのに、ブラウザ上で動くこういうのがつくられないこと、なんかを非オタ彼女と話してみたいかな、という妄想的願望。
futhark (Opera Software)
「やっぱり JavaScript はブラウザのためのものだよね」という話になったときに、そこで選ぶのは『InScript』でもいいのだけれど、そこでこっちを選んだのは、この実装にかけるテッちゃんの思いが好きだから。
断腸の思いで磨きに磨いた『linear_b』をそれでも捨てる、っていう判断が、どうしても俺の心をつかんでしまうのは、その「捨てる」ということへの諦めのよさがいかにもオタ的だなあと思えてしまうから。
linear_b の速度を俺自身は遅いとは思わないし、もう速くできないだろうとは思うけれど、一方でこれが Geoffrey Garen や Brendan Eich だったらきっちりスピードアップしてしまうだろうとも思う。
なのに、各所に頭下げて迷惑かけて新しいスクリプトエンジンを作ってしまう、というあたり、どうしても「はじめからやり直したい症候群のオタク」としては、たとえテッちゃんがそういうキャラでなかったとしても、親近感を禁じ得ない。実装自体の高評価と合わせて、そんなことを彼女に話してみたい。
Rhino (Mozilla Foundation)
今の若年層で Javagator 見たことのある人はそんなにいないと思うのだけれど、だから紹介してみたい。
JSR 223 よりも前の段階で、Java からの呼び出しとか LiveConnect とかはこの実装で頂点に達していたとも言えて、こういうクオリティの実装が Java でこの時代に書かれていたんだよ、というのは、別に俺自身がなんらそこに貢献してなくとも、なんとなく JavaScript 好きとしては不思議に誇らしいし、いわゆるアプレットでしか Java を知らない彼女には見せてあげたいなと思う。
JavaScriptCore (WebKit Project)
SquirrelFish の「レジスタ」あるいは「ダイレクトディスパッチ」をオタとして教えたい、というお節介焼きから見せる、ということではなくて。「終わらない速度競争を毎日生きる」的な感覚がオタには共通してあるのかなということを感じていて、だからこそ Tracing 版『Tamarin』仮想マシンは JIT 以外ではあり得なかったとも思う。
「高速化した日常を生きる」というオタの感覚が今日さらに強まっているとするなら、その「オタクの気分」の源は『KJS』にあったんじゃないか、という、そんな理屈はかけらも口にせずに、単純に楽しんでもらえるかどうかを見てみたい。
JScript (Microsoft)
これは地雷だよなあ。地雷が火を噴くか否か、そこのスリルを味わってみたいなあ。
こういう微妙に非互換風味の言語をこういうかたちで Active Script 化して、それが非オタに受け入れられるか気持ち悪さを誘発するか、というのを見てみたい。
長門有希 (涼宮ハルヒの憂鬱)
9 本まではあっさり決まったんだけど 10 本目は空白でもいいかな、などと思いつつ、便宜的に長門を選んだ。SpiderMonkey から始まって長門で終わるのもそれなりに収まりはいいだろうし、SQL や C++ も使えるみたいだし、紹介する価値はあるのだろうけど、もっと他にいい実装がありそうな気もする。
というわけで、俺のこういう意図にそって、もっといい 10 本目はこんなのどうよ、というのがあったら教えてください。
「駄目だこのオタク未満は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。こういう試みそのものに関する意見も聞けたら嬉しい。
参考文献
はてなインターンに参加しています ― 2008年08月19日 03時35分
現在株式会社はてなのインターンシップに参加しています。期間は全 4 週間で、前半 2 週間で製品レベルのコードを書けるようにし、後半 2 週間で実働中の開発チームに所属し実際のサービス開発に携わるという流れです。
前半の詳しいカリキュラムは「0×0018 till I die ? はてなインターンのカリキュラム」に紹介されていますが、実務に関われるようにするというだけあって密度の濃い内容となっています。特に大規模データ処理は私にとって未知の分野であり、はてなの実データを使った演習が受けられるというだけでも大きな経験となりました。
基本的にはてなでは Perl が用いられますが、私自身の Perl の経験は 6、7 年前にゆいちゃっとを改造し、4、5 年前にオブジェクトの作成をやったくらいで止まっていたので、今回インターンに参加するに当たって再入門として perldoc を読み直しました。といっても目を通したのは各種チュートリアルと構文、データ型、サブルーチン、演算子、関数などの一部だけですが、各課題についていける程度にはなったと思います。ちなみに perldoc を選んだのは、一番入手が簡単 (さらに無料) で信頼性が高い (なんといっても公式) と思ったからです。
また、文法的なことは perldoc を読めばすぐわかるのですが、意外とわからないのがライブラリパスの設定やテストの実行方法。私が見聞きした範囲だけでも私も含めたインターン生 4 人が prove コマンドの存在を口伝で知ったとのことで、言語自体に比べそれを取り巻く環境の情報は共有が遅れているのではないかと思います。perl-users.jp は真っ先に
- アプリケーションディレクトリ
- lib
- モジュール.pm
- t
- テスト.t
- lib
というディレクトリ構成と use FindBin::libs と prove コマンドと cpan コマンドの使い方を教えてもいいのではないでしょうか。
話をはてなに戻すと、社内は開放的であり、静かではあってもほかの人に話しかけづらいという雰囲気ではありません。見渡せば小規模ミーティングもあちらこちらで行われています。京都は美人が多いですし、Web アプリケーションの作成、またはその裏側に広がる大規模データ処理に興味がある学生はぜひとも参加してみることをお勧めします。第 2 回の応募締め切りは明日 20 日までなので、迷っている方は急いで申し込みましょう。
最近のコメント