いまさらながらAutoPagerizeでmixi日記のコメント欄が逃げる件

いまさらながら、10/1にmixiのデザインが新しくなったときに、前よりぜんぜんXPathフレンドリーなHTMLになっていたのがうれしくてためしにSITEINFOを書いたけど、コメント欄がpageElementに入っていなかったのでコメントが書けなくなってAutoPagerizeを使われているひとに迷惑をかけた件について。まず迷惑をおかけしてしまってごめんなさい。そして直していただいたotusneさんありがとうございます。

このことについてまとめられているAutoPagerizeでmixi日記のコメント欄が逃げる件 – cameraLadyのこの件を通じて思ったことを読んで思ったことを。

この件を通じて思ったこと

個人的にはSITEINFOは気軽に書くことができて、気軽に使えるほうがよいと思う。

もし気軽にSITEINFOを書くことができないなら、たとえば一度書いてSITEINFOコミッタに提出したあとレビューをうけて反映される、ような手順が必要だったら、いまのようにはwiki上でSITEINFOが共有されずに各ユーザのautopagerize.user.jsの中に死蔵されてしまって今のようにはハッピーでなかってのではないかと思う。コミッタのレビューが必要な場合、コミッタのレビューを経て反映されるものと、誰のチェックもなく反映されるものと、どちらが参加しやすいかといったら後者だから。

Wikipediaとの比較

でも誰のレビューも通らないで自由に書けるのなら間違っていたときに困るという問題はある(実際今回困ったわけだし)。Wikipediaの場合は、間違っていたら気がついた誰かが直す、という仕組みを採用していて、たしかにときどきネタが仕込まれて正しくない状態になったりもしているが、全体で見れば極めてよく機能している。

SITEINFOも基本的にはWikipediaと同じやり方でうまくいくのではないかと思う。ただSITEINFOはWikipediaと決定的に違うところがある。Wikipediaは誰でも使いこなせる自然言語で書かれているのに対して、SITEINFOはあんまり使える人のいないXPathで書かれているので、おかしいと気がついても誰でもは修正できない。その点でWikipediaとまったく同じ方法をとることはできない。

XPathは誰もが書けるようなものでない問題を解決する方法のひとつとしてAutopagerize IDEのようなスクリプトでXPathの生成を助けることが考えられるが、実際にはHTMLの美しくなさに起因する問題があるので容易ではない。

スクリプト側での対策

SITEINFO自体の正しさを保つことは参加のしやすさとのトレードオフになるので、ある程度の誤りは許容する必要があるだろう。
AutoPagerize自体はそういった機能は持っていないが、それをAutoPagerizeとは別のひとつのGreasemonkeyスクリプトとして実装してどういう実装が好ましてか、どの程度有用かを検証することは難しくない。

AutoPagerizeはGreasemonkeyのwindowオブジェクトにwindow.AutoPagerize.addFilterという変数を設定している。自分のGreasemonkeyスクリプトからFirefox、evalの第二引数、プライベートメンバ/クロージャーの実行コンテキストへのアクセス – 実用を使って

var autopagerize = eval("AutoPagerize", window.AutoPagerize.addFilter);

というコードでAutoPagerize全体にアクセスすることができるようになり、AutoPagerizeのコードを直接書き換えることなく他のGreasemonkeyスクリプトからAutoPagerizeの動作を変更することができるので、他の人にもスリプトをインストールしてもらうだけでかんたんに試してもらうことができる。

各SITEINFOの記述のMD5を取って、変化があったときには旧バージョンのものを保存しておき、あたらしいものを適用して問題があったら前に戻せるようにする、ことでSITEINFOの誰かが書いたものが自動的に反映されるという利点を損なわずに、問題があるSITEINFOに対処することができる。と思う。

最後に

今回自分がmixiのSITEINFOを追加してからotsuneさんによって修正されるまでに5日が必要だった。infogamiのアカウントが新規で発行されていないことで限られたひとしか修正できず長くなったところもあるかもしれないが、問題に気がついたひとがXPathが書けなくても修正できるようになれば、問題のある状態の期間は短くなるだろうし、さらにAutoPagerizeが対応するサイトも増やせるかもしれない。

クライアント側での問題回避は比較的容易に実装できるが、SITEINFOの正しさを保つのは集合知の利用とのトレードオフにもなるのでどういう方法でそれを実現するかはよく考える必要がある。