Bibliwoで文京区も修正したが言いたいことが

千代田区と全く同じ問題がありましたので修正しました。
ISBN10で検索し、見つからなかったらISBN13で再検索します。

　　　　　　　　　 　 /＼＿＿_／ヽ
　　　　　　　　　／ﾉヽ　　　　　　 ヽ、
　　　　　　 　　/　⌒''ヽ,,,)ii(,,,ｒ'''''' :::ﾍ
　　　　　　　　 | ﾝ（○）,ﾝ　<､（○）<::|　　|｀ヽ､
　　　　　　　 　|　 ｀⌒,,ﾉ(､_, )ヽ⌒´ ::l　　|::::ヽl 　ウウウオアアーー！
.　　　　　　　　ヽ　ヽ iｌ´ﾄｪｪｪｲ｀ｌi　ｒ ;/　 .|:::::ｉ |
　　　　　　　　／ヽ　 !ｌ |,ｒ-ｒ-| ｌ! 　 /ヽ　 |:::::ｌ |
　　　　　　　/　　|^|ヽ､ ｀ﾆﾆ´一／|^|｀,ｒ-|:「￣
　　　　　　 /　　 | .|　　 　 　 　 　 | .|　,Ｕ(ﾆ ､)ヽ
　　　　　　/　 　 | .|　　 　 　 　 　 | .|人(_(ﾆ､ﾉﾉ


ISBN検索だけはホンマ真面目に作って!
ISBN10では検索できないとかやめて! ISBN10をもう使いたくないなら、ISBN13だけで確実に検索できるようにして!

というか書籍なんてISBNをURLに組み込んでしまえば良くない? Amazonみたいに。そうできない何らかの事情があるのかな?

JScriptのエンジンがいつの間にか更新されていた?

Javascript

JScript(IEとかWSHとかで使われるJavaScript)は1年くらい前の時点では、サイズが100万個くらいある配列のリテラルを書くことができなかったハズなんですよ(evalもダメ)。
具体的にはどのくらいのサイズでダメになるのかなーと思って今調べてみたら、その程度の大きさの配列リテラルが平気で使えるじゃありませんか。

いつ頃更新されたんだろう? 以前動作していなかったのは気のせいか? でもFirefoxでは動いてWSHでは動かないなーとか悩んでいた記憶があるし……


100万個もあるような配列リテラルなんか何に使うんじゃーという話ですが、SuffixArrayを使った検索エンジンをWSH(JScript)で書いたらこのくらいのインデックスが平気でできてしまったのですよ。今でも業務に使っておるのですが、業務に使っているバージョンは配列リテラルを使わずに文字列としてデータを保持しているのです(','で分割して配列を作成し直している)。普通に配列リテラルで書けるんだったら、文字列解析するより起動が速くなりそうなので、書き直そうかな。

Bibliwoで千代田区の検索に失敗していた件を修正したが言いたいことがある

Bibliwo

千代田区図書館にて、あるはずの蔵書が見つからない場合がある件を修正しました。
スクリプト本体のバグも見つけてしまったので、更新が必要です。


ただ、この問題については千代田区が悪い(断言)。
千代田区図書館は、なぜか書籍ごとにISBN10かISBN13のどちらかしか登録していない模様。したがって、ISBN10で検索すると、ISBN13でしか登録されていない書籍が検索されないのです(e.g. この本はISBN13でしか登録されていないので、ISBN10では検索できない)。んな馬鹿な……。逆もまた真で、ISBN10でしか登録されていない書籍は13では検索できません。
千代田区側の(致命的な)障害だと思うので、なおして欲しいところです。ISBN13は10の上位互換なので、13で検索すれば全ての書籍が検索対象になる、とか。スクリプトから検索する分にはまだ良いけど、人間が検索するにあたっては極めて不便でわかりにくい振る舞いをするようになってしまいます。

まぁ、昔の渋谷区や中野区みたいに、登録されているISBNの区切り文字の位置が書籍によって異なり(信じられない)、何パターンか検索を試行錯誤しないと蔵書の有無が解らないという狂気の沙汰よりはまだ全然マシですがな。

ダンディとサバイバル

今週は奥様が出張なので、生後5ヶ月のダンディと3歳の雄猫とでサバイバルしております。

着替え、授乳、保育所への送迎、といったところは想定通りというかいつも通りの負荷というか、単に2倍手間暇がかかるだけなのです。が、こと入浴になると3から4倍手間がかかっている感触。この糞寒い中(いま雪が舞ってる……)洗面所に乳児を放置するわけにもいかないので、風呂上がりはホントばたばたするわけですよ。
それでも入浴は「手間がかかる」程度で済むものの、僕の体調が崩れてしまったらダンディの世話はどうすんねん、というのは深刻な懸案事項です。それを考えると恐くて晩酌なんかできやしない。元からしないけど。

実際に経験してみないと実感できなかったことですが、一人親家庭(単身赴任とかを含む)ってのは、日々が心配な環境なんだろうなと。そういう実感に加え、奥様が居ないにもかかわらず猫が徹底的に僕に懐かないのはどういうことだという憤慨も抱きつつ(人間が僕しかいなかったら流石に懐いてくるだろうと高をくくっていた)、あともうちょっと頑張ります。

たまには技術系以外の話題も書きたいと思ったので、こういうグダグダなエントリ。

Bibliwoに一宮市,弥富市,常滑市,豊明市,江南市を追加

Bibliwo

愛知県の5つの市が追加になりました。@tanak_に感謝!


最近はBibliwoがAndroidで動かぬものか思案しておるのですが、トリッキーなことをしないと難しそうという結論に落ち着きつつあります。
とりあえず、ただ検索するだけでPOSTメソッド+Cookieを使うような図書館はこの世から無くなってしまえばいいと思いました。GETメソッドだけでなぜ実装できぬ。

ChromeがJetpackをサポートしたらどうしよう

ChromeがGreasemonkeyをサポートしてしまいました。

Bibliwoを書いてて、1000行超(データを含めたらもっと沢山)のuserscriptってちょっとどうよ……ええかげんFirefox拡張として書くべきと違うんか……と思うこと甚だしかったのですが、Firefoxの現行の拡張の仕組みは将来的に縮小(なくなりはしないけど基本Jetpack)、ChromeはGreasemonkeyサポート、という誰も予想しなかったであろう状況になりつつあります。
userscriptをJetpackに書き直すのはごく簡単なので(例えば、簡単な修正を加えることでBibliwoは手元ではJetpackとして動かせてる)、userscriptとして書いておけば将来的にFirefoxでもChromeでも拡張として動かせる! Greasemonkeyこそブラウザ拡張の中心的技術だった! Bibliwoも無理にFirefox拡張に書き直さなくて良かった!と安堵しております。

グリモンが簡単にChromeで動いてしまったのは、グリモンのAPIが数少なくて安定していたのが一つの原因でしょう(難しいAPIは未だサポートされてないけど……クロスドメインXHRやset/getValueは、セキュリティ的にあえてサポートしてないという気もしてきた)。。
安定的なAPIを提供すると言えば、それはJetpackのプロジェクト目標でもあります。あれ、ということはJetpack正式リリースの暁には、ChromeがJetpackをサポートしちゃう可能性もあるのでは?
現に、現在提供されている/提案されているJetpackのAPIで、Firefox特有でChromeでのサポートが難しそうなものは少ないです(JEPのGadgetは微妙。XULRunnerと密な連携をするものは当然ダメ。でも大抵の拡張はここら辺使わないでしょう)。

もしChromeがGreasemonkeyのみならず将来的にJetpackをサポートしてしまい、大抵の拡張はChromeでもFirefoxでも動くようになってしまったら、みんなどっちを使うんでしょうかね。
JetpackはなるべくXPCOMなどへの直接的なアクセスを排除するような方向で開発されつつあるようですが、Mozilla生き残りのためにあえて移植性を低くするような設計にしてしまうという可能性もなきにしもあらずなのかなぁ、という陰謀史観(その場合、高度な機能を実現する拡張のためにXPCOMへのアクセスは残すべきだみたいな建前の下に、実際にはXPCOMへのアクセス無しにはろくな拡張が作れないようにしてしまうのが良いんじゃないでしょうか)。

Chromeで動かないGreasemonkeyのスクリプトはかなり多いのでは?

http://blog.chromium.org/2010/02/40000-more-extensions.html

I expect between 15%-25% of scripts to not work in Google Chrome.

Google ChromeでGreasemonkeyのスクリプトが拡張として動くようになったよ、大体15から25%のスクリプトはダメだと思うけど……ですってよ奥さま。

というわけで、拙作のスクリプトを実際に動かしてみました。

Bibliwo
公立図書館に蔵書確認を行い、Amazon等オンライン書店の書籍ページに予約ページへのリンクを挿入します。

=>ダメ。

Google App Engine Log Timezone Adjuster
Adjusts Google App Engine's log timezone(PST) to your local timezone. Google App Engineのログにおける時刻表示のタイムゾーンを、PSTからローカルのものに変換します。

=>ダメ。

ALC counter
Counts up the number of looking up for each word by ALC. http://www.alc.co.jp/ ALCの提供する英辞郎 On the Webでの各単語の検索回数を覚えて表示します。 同じ単語ばっかり検索してる気がするので作ってみました。

=>ダメ。

全滅ですってよ奥さま!
Chromeのコードを読んでみると、動くのは以下のAPIだけっぽい。

以下のAPIは明示的に未サポートである旨コードに書いてある。

  • GM_getValue
  • GM_setValue
  • GM_registerMenuCommand

そしておそらく、GM_XHRはクロスドメイン制約がかかっている模様(GM_がつかない、通常のXmlHttpRequestで実装してあるように見える。詳しく読んでいないので嘘の可能性大)。

というわけで、

Bibliwo -> getValue, setValue, registerMenuCommand, クロスドメインXHRを使っている。全然ダメ。
Google App Engine Log Timezone Adjuster -> クロスドメインXHRを使っている。ダメ。
ALC counter -> getValue, setValueを使っている。
ダメ。

こういうことのようです。


これだけ制約が厳しいと、よく使っている有用なスクリプトがほとんど動かないような気がする……


よしOK。愛してるぜFirefox!