栗林健太郎

id:secondlife さんを中心に、Shibuya.pm インスパイヤリスペクトな Shibuya.js が結成されたとのこと。

以前、他の言語はコミュニティがあって、勉強会なりカンファレンスなりいろいろ開かれて活発だけど、去年から見直されてきた JavaScript はそういうコミュが無くて悲しいよねという話をしました。その時、コミュを作ったら参加するよというありがたい言葉を数人からもらったので思い切って作ってみました！ネーミングは Shibuya.pm リスペクト。

Shibuya.js は主に東京近辺の JavaScript プログラマによる非営利団体です。各個人のプログラミングスキルの向上を目的に、勉強会ならびにカンファレンスの開催、情報交換などを行うコミュニティを目指しています。
Shibuya.js は JavaScript を利用し、スキル向上を望む方であればどなたでも無料で参加できます。

田舎者なので、例によって他のイベント同様、直接には参加とかまったくできそうにないのがアレなのですが、期待しまくりですね。

機能もコードも非常にショボくてだめだめな感じの拙作 greasemonkey スクリプトの Hatena Rolling ですが、自分的には非常に便利で、愛用していたりします。先日、サーバが死んだことにともない、そのスクリプトも消え失せてしまってたかと思いきや、Userscripts.org: Hatena Rolling に残っているのを発見し、ちと安堵したりもしました。

さて、その間にもみんな大好きはてなさんは次々と新しいサービスをリリースしまくりで、Hatena Rolling を新サービスに対応しる！ との声も聞かれたり聞かれなかったりしたので、10 文字ぐらい追加すればオケなはずってんでやってみると、あれ、うまくいかないなぁ……という事態に。

そのうまくいかなかったところってのは、はてなマップのユーザごとのページでのリンクボックス表示（僕とこだとはてなマップ – antipopの地図）。元々は for (var i in obj) { ... } としてまわしていたのですが、はてなマップが prototype.js を利用している関係で、prototype.js が Object を拡張しちゃってて、単にそゆふうにまわすだけではうまくいかないわけです。困りました。

そこで、ニート言語の使い手に泣きついたら、さくっと解決してくれました。さすが過ぎ。要は、「最速インターフェース研究会 :: prototype.jsのObject汚染を回避する方法」で述べられている通り、あるオブジェクトが持つプロパティが、元々そのオブジェクトが持っていたものなのか、あるいは prototype.js がやるように、あとから拡張されたものなのかを、hasOwnProperty メソッドで判別してやればいい、と。たとえば、以下のような感じ。

for (var i in obj) {
// もともと持っているプロパティかどうか調べ、
// 後付されたものならスキップ
if(!obj.hasOwnProperty(i)) continue;
// 以下、通常の処理
...
}

とまぁ、そんなこんなで、Hatena Rolling を update しましたよ、というお話でした。

JavaScript 版 CPAN というべき JSAN (JavaScript Archive Network) が、CPAN シェルに似たインストール法を提供する JSAN モジュールが CPAN にあがったり、また、ライブラリも整備され始める等、本格始動したようです。

てな感じで、CPAN に馴染みのある Perl 使いのひとにはすっと入りやすい仕組みになっているようですが、他の言語スキーのひと的にはどうなんだろう……。ともあれ要注目、というか普通に便利ちっくなので、JS ハカーな方々ががんがん便利ライブラリをあげてくれると素晴らしいなぁと思います。

Blog Hackers Conference 2005 で話題になったという「もんたメソッド」について、さっそく以下のもんたメソッドによるプレゼン作成ツールが公開されています。

• 最速インターフェース研究会 :: もんたメソッドなプレゼン作成ツール
• もんたメソッドを組み込む JavaScript を公開。
  • YappoLogs: 既存のページにもんたメソッドを簡単に組み込むツールを作った

  おぉ、超お手軽だー！ などといいつつ、IRC で突如「もんたメソッド JavaScript 作成プチ祭り」が勃発したりりしつつ、僕もちとやってみました。てゆか、すでにお気づきの通り、このエントリで実験してみてるわけですがｗ

  ソースは以下の感じ。

  • monta.js

  こんな感じで使います。

  var config = {
  'bgColor'     : '#000000',
  'targetNodes' : [{
  'element'   : 'strong',
  'class'     : ''
  },
  {
  'element'   : 'div',
  'class'     : 'more'
  }]
  };
  var monta = new MontaMethod(config);
  monta.init();

  「「続きを読む」と、Blog のユーザビリティ」にからめていえば、「続きを読む」でクリックする手間を閲覧者に強いるよりもむしろ、どうせクリックさせるならもんたメソッドにしてしまうのがいま一番アツイ Blog 作法です！ たとえば以下のように隠します。いかにも重要そうだ！

  otsune さんによれば「単純に文章の最初に全体の概要を簡潔に書くという英語圏でよくある習慣が、日本だと一般的ではな」く、とすれば、そのような習慣を前提としない Blog で「続きを読む」機能を使うのは、単なる舶来物を無意味にありがたがるのといっしょ、つまり猿真似なのでは？ そして、そういう批判って、かつての Blog 論争の時に、m.e.s.h. を攻撃する時に用いられた論法だったりしますね。その辺、あのとき批判してたひとは大丈夫なのかしらん、とか思ったよ。

  というかそんなことよりもむしろ、「続きを読む」をわざわざクリックして、ページ遷移をする手間をかけたところで、たいていは、わざわざクリックしてまで読むようなことなど書かれてはない。

以前「リファラを残さずにリダイレクトする」というエントリで述べた、リファラを残さないリンクの作り方について、せきむらさんに、より簡単な方法を教えていただきました。

• qootas.org/blog: referrerを空にするリンクの作成方法

なるなる。window.open で新しい window を開いて、そこに meta 要素書き出し & refresh する、と。CGI 経由でリダイレクトするよか、楽ちんですね。

通常は、リファラを送信して問題になるということはあんまりないかと思うのですが、以前そのようなことを試したのは、Web 上から参照できる IRC のログヴューワ内のリンクをどうにかしたいということで、つーのは、チャンネルのメンバーしか見ることができないよう認証をかけているのですが、認証のかかったところからのリファラがあると、リンク先のひとがヤな思いをすることもあるかなぁといった事情で、そゆことをやっておったわけです。同様の問題を抱えている方は、この方法を試してみるといいかもしれませんね。

この Blog でも使わせていただいている、ありみかさとみさん作の「あれこれポップアップ」。どんなものかってーと…。

ウェブページ (HTML) にて、マウスポインタの下にある任意の箇所（要素）の情報（属性値）あれこれをポップアップに出す、 JavaScript と CSS のセット。 Web サイトの製作運営者向けの一種の「素材」。（中略）

（中略）

多くの典型的なブラウザでは、 title 属性に何か書いてある要素部分にマウスポインタをかざすと、その title 属性値がツールチップとしてポップアップしますよね。あれのゴージャス版と思ってもらえればよいです。典型ブラウザ本来のポップアップとの違いは、ポップアップするのが title 属性だけではない点。それと自分で言うのも何だけど、見てくれがカコイイ事（笑）

あれこれポップアップ

すでにお気づきの方も多いかと思いますが、たとえば上の引用箇所にマウスポインタをかざすと、どういうものかわかると思います。ここでは、この「あれこれポップアップ」を、Web サイトの製作運営者向けの一種の「素材」としてのみならず、Firefox の拡張 greasemonkey を用いることによって、ユーザサイドでも使えるようにしてみました。

といってもたいしたことをするわけでもなく、「川o・-・）＜2nd life – bookmarkletの文字数制限を無くす」で述べられている方法を greasemonkey に適用し、ページロード時に外部 JavaScript（この場合は、あれこれポップアップ本体の ArekorePopup.js）と、画像の指定等を記述したスタイルシートを読み込むようにしただけ。

• ArekorePopup Anywhere

greasemonkey をすでにインストールしているならば、上記リンク上で右クリックして出てくるコンテキストメニューに、”Install User Script…” というメニューが出てくると思います。それを選択してインストール。これだけでオケ。たとえば、以下ははてなダイアリー日記にて動作している例。なかなかかっけーよね。

詳しくは先述の「あれこれポップアップ」のドキュメントを見ていただくとして、たとえば title 属性や cite 属性が指定されている要素の上にマウスポインタをかざすと、リッチなポップアップが出てくるようになります。

ここで注意。上にリンクした user.js は、この Blog を置いてあるサーバのドメイン上の JavaScript ファイルを、greasemonkey スクリプトが実行される場所の権限で読み込んで動作させることになります。よって、上の user.js をそのままいじらずにインストールすると、僕が悪いことをしようと思えばなんだってできちゃうということになります。じゃーどうすりゃいいのよ、ってことになるわけですが、常用しようという奇特な方は、その場でインストールするのではなく必ずダウンロードして user.js の該当箇所を適宜書き直してインストールし、また、あれこれポップアップ一式を自分の利用しているサーバにでもおくようにしてください。セキュリティ上の問題に加え、あれこれポップアップは設定項目が多岐にわたりますので、自分の好みに合わせて使う方がよりよいとも思います。

あと、遠くにあるサーバにおくよりも、ローカルにおいてそこから読み込めばいいじゃないか（file: スキームで）、ってんでちとやってみたのですが、ローカルファイルをリモートサイトの権限で読み込むことになり、セキュリティ上のエラーが出てだめでした。回避できるのかもしれないけど、めどいので放置。まぁそんなこんなで、単に外部 JavaScript をざくざく読み込むだけでも、あれこれ便利に使えたりする greasemonkey マンセーということで。

なんというか、意味のない愚痴みたいなことですが。

たとえば “Ajax: 99% Bad” という、ヤコブ・ニールセンさんの “Flash: 99% Bad” を文字った Ajax 批判エントリを読むと、なんかガイシュツな話をしてるなぁとか思うわけです。というのは、Ajax という言葉が作られて 10 日もたたないうちに、すでに「nazonoDiary – AjaxでもURIで状態を示せるようにお願いします。」というエントリに見られる通り、一般的な Flash アプリケーションが、ある状態を示す URL によって状態の復元が可能であるようには作られていないことが多い（単に一般的にそうなってないというだけで、可能ではあるようです）ことのユーザビリティ的問題を挙げて、Ajax に対する問題提起が行われています。

その提起に対して、mala さんが即日「location.hashを使ったセッション復元」というエントリを起こし、Google Maps が行っている実装の検討とともに、それとは別に location.hash を用いた状態保存方法を紹介し、問題解決の糸口を示しています。また、その方法ではマルチバイト文字を扱う上で不都合が生じることがあるということで、location.href から取得することで文字化けを回避する方法を示しています。

それを受けて nazoking さんの複合検索サービス「ご一緒にポテトはいかがですか?」に、検索結果ページを示す URL を扱えるよう改良がなされ、上述の “Ajax: 99% Bad” にて提起されている問題うち、URL の問題については、上記の通り一応の解決をすでに見ており、そのため、日本語のリソースで「Ajax は状態保存できないからうんこだ」などと書けば、「まぁ落ち着けよ。Ajax がどーのとかいうなら、せめて「最速インターフェース研究会」ぐらいはチェキっとこうな」と諭されることになるわけです。

しかし、考え直してみるに、単に僕が知らないだけで同様の問題は世界中の各言語で議論されていて、たまたまこの　”Ajax: 99% Bad” が目にとまり、「ガイシュツ」呼ばわりしているのかもしれないなぁ、と思いました。しかし、”AjaxPatterns” なる、Ajax に関するかなり高度な Tips 等がまとめられているように見受けられる Wiki を拝見しても、”UniqueURLs” に関する同様の問題提起はなされているものの、ソリューションとしては Google Maps が挙げられているのみです。そのようなことから、上述した nazoking さんと mala さんのやりとりで展開されたような方法は、単に知られていないということなのではないか、と思いました。

とはいえ、location.hash を用いた状態保存・復元という手法は mala さんのオリジナルというわけではなく、たとえば TiddlyWiki においてすでに試みられています。しかし、Tiddly Wiki の実装では、Google Maps と同じく、状態保存用の URL へのリンクがしめされ、それをクリックするなりコピーするなりして、当該 URL を取得しなければならず、ひとつ手間がかかります。先に挙げた nazoking さんの「ご一緒にポテトはいかがですか?」においては、URL が自動的に変遷していき、そのような手間は必要ありません。

要するになにがいいたいかというと、本件問題についてはすでに解決方法、あるいは、よりよいと思われるアイディアが提示されているのにも関わらず、それが言語を異にするという理由でうまいこと伝わっておらず、相も変わらず “Ajax: 99% Bad” などと無知に基づく因縁をつけられているような事態になっているのは、見ていてなんだか歯痒いなぁと思うわけです。やっぱ英語で書かないと読まれないし、読まれなければいいアイディアであっても広まらず、なんだか悲しいことになるのだなぁ、と。じゃぁおまえが英語で書けばいいじゃないか！ と、いまこの文章を読んでいるあなたは思ったでしょうが、僕にそんな能力があるわけないじゃないか！ そんなことできるなら最初からやってるよ！ つーか、そんな説教をたれてくださる英語ペラペラなあなたがまずは “UniqueURLs – AjaxPatterns” に上記のような内容を書いて、世界に広めてくださいよ！ と逆ギレ気味に、このエントリおしまし。