今回の地獄少女は、ローゼンメイデンのような少女です。これはスタッフの趣味でしょうか。こんばんは。
地獄少女ってとりわけ面白いわけではないのですが、時代劇みたいに毎回展開がワンパターンなので、安心して見られます。ぼーっと見るには向いてますね。
あー、ローゼンメイデンは見たことないです。
国内外を問わず、普通に出版社から出版された書籍にはISBNが付きます。ただし、雑誌やムックには付きません。海外は知りませんが、日本の雑誌には別に雑誌番号が付きます。当然、同人誌（同人雑誌）には付きません。正規のルートを通ってませんしね。
ISBNが決まると、一意に書籍が決まるので、出版地域、出版社、書名、を特定できます。そこまで決まれば、著者や出版年なども容易に導くことができます。ただし、版や刷りまではわかりません。そういった情報は含まれていないからです。
さて、以前からISBN周りのデータベースが欲しいと思っていました。ISBNとその周辺情報を何とか手に入れられないかと考えたのですが、この辺は「ビジネス」として成立しているらしく、ただでは手に入りません。定期更新も含めて年間契約でン百万らしいです。とてもじゃないですが、そんな金払えません。
ないものは作ってしまえ、ということで、作ります。もちろん手入力で…なんて面倒なことはしません。完全で体系的、とは言えませんが、WWWにはそれなりに豊富な情報があります。例えば、本屋のウェブサイトとかね。適当にウェブクローラー（ロボット）を作って、これらのサイトを適当に徘徊させながらISBNとその付随情報を集めてくれば良いでしょう。自動収集させるので、
が必須条件となります。これらの条件に適合したサイトを探すのは容易ではありません。まずはサイト探しです。
楽天はページの汚さはamazon級 *1 ですが、関連書籍の情報量が少ないため、とりあえず候補から外します。JavaScriptが有効でないと閲覧すらできない丸善は論外、Cookieが有効でないと一部のページにアクセスできないJBOOKも候補から外します。ほか、ISBNからURLを作成しにくいサイトも対象外です。
残ったのはamazonとManaHouseです。amazonの吐くページには、その書籍以外にも関連した書籍情報がありますから、関連書籍情報の豊富さではamazonが有力です。ただし、ページから書籍情報（書籍名や著者名など）を取り出すには、ManaHouseの方がやりやすそうです。ManaHouseにない書籍は、仕方がないのでamazonから取得します。
次にクローラー（ロボット）の方ですが、実装するのが面倒なので、wgetにします。機能的にも豊富ですし、WindowsでもLinuxでも使えます。
取得したデータはRDBに保存します。RDBMSにはSQLiteを使用します。
といったところでSQLiteに決定です。
情報を取得する順序、つまり、次に何を取得すればよいかという情報は、「取得キュー」（FIFO）に保持します。キューはもう一つ、「解析キュー」というものもあります。キューにはISBNやURLを放り込んでいきます。 *2
キューの実装については二通り考えました。名前付きパイプとRDB上のテーブルです。名前付きパイプは、FIFOとも言われるファイルの一種で、ほとんどのUNIX系OSでは標準で実装されています *3 。多数のプロセスから同時に書き込める、読み出し順序が保証される、など、レギュラーファイルと異なる性質を持ちますが、扱い方はレギュラーファイルと大差ありません。多数のプロセスから同時に書き込みたいけど、ソケットやIPCを使うほどではない、といったときには結構便利です。しかし、Windowsにはありません。cygwin上でなら使えますが、cygwinの名前付きパイプは、大量のプロセスから一斉に書き込みまくると、プロセスが固まってしまうという欠点があります *4 。移植性や保守性、特にリストアに問題が出そうなので、名前付きパイプは使いづらそうです。
RDBテーブルにはそもそもキューの概念がありません。つまり、sequenceやserialの列を設けて、行の作成や取り出し・削除順序を自分で制御する必要があります。これらの列は、当然ユニークであり、かつNULLでないという制約下に置かれます。これはとりあえず主キーにしておけばよいでしょう。SQLiteでは、一意制約の実装としてユニークインデックスだけを利用している（？）っぽく、SQLiteの主キーはNULLを許可してしまいます。NULLデータの混入に気をつけた方が良さそうです。もっとも、INTEGER型の単一列主キーであれば、自動的にシーケンスを振ってくれる（PostgreSQLのSERIAL型に相当）し、NOT NULL（CHECK制約）にすれば回避できるし、あまり心配はないかも。
それよりも、エンキュー（挿入）、デキュー（削除）時に発生する、インデックスの再作成コストが心配です。前述の通り、キューは二つあります。WWWにアクセスして情報を取得するプロセス（ゲッター）は、この「取得キュー」から情報を読み、WWWからの情報を取得し、その結果（HTTPレスポンス本体）をファイルとして保存します。と同時に、その結果から関連書籍情報を取得し、今度取得すべきISBN,URLを「取得キュー」に登録します。さらに、「WWWから取得した」という情報は、「解析キュー」に書き込まれます。厳密な解析を行うプロセス（アナライザー）が別に稼働しており、このプロセスに解析を依頼するわけです。つまり、WWWから取得するたびに、「取得キュー」に対してデキューが一回、エンキューが0〜N回、「解析キュー」に対してエンキューが一回発生します。このコストは、キューにたくさん溜まっているときには意外と馬鹿にならないかもしれません。
次に、全体制御です。bashで済ませようかとも考えましたが、取得したページの解析など、強力な文字列処理機能が要求される局面では少々心許ないので、それなりのスクリプトが必要でしょう。
というわけでPerlに決定です。というか、それ以外は眼中にありません。 *5
制御する人（プロセス）は二種類あります。WWWからリソースを取得する人（ゲッター）と、リソースを解析する人（アナライザー）です。お互いに独立したプロセスなので、一人ずつ同時に存在するのはもちろん、多対一、多対零、零対多、…でもOKです。ゲッターは、WWWから一定間隔でリソースを取得する、デーモンとして稼働します。細かいことは前述の通りです。アナライザーは、適当な時間に「解析キュー」からデキューし、該当するリソースを解析して、解析結果（書籍名や著者など）を本体テーブルに登録します。この本体テーブルこそがISBN DBのコアです。うまく解析できなかったら、別のサイトからリソースを取得するよう、「取得キュー」にエンキューします。つまり「取得依頼」ですね。
こうして自律的かつ自動的にDBが出来上がっていく…はずなんですよ。実はまだ「ゲッター」しか実装されていなくて、取得することしかできず、キャッシュ（取得したリソースファイル）が溜まる一方です。アナライザーがないので、肝心の本体テーブルが構築されないわけで、ごにょごにょ。
昨日、書いてから気づいたのですが、「ゲッター」が関連書籍情報を取得するのはおかしいですね。一旦取得したリソースを解析するのはアナライザーの仕事ですから、関連書籍情報の取得と「取得キュー」へのエンキューも、アナライザーがやるべきです。ゲッターにはWWWからの取得に専念させた方が、設計として美しいです。
IBMのSpace Saver II（今はlenovoだっけ）というキーボードが欲しいのですが、新品では手に入らないっぽいですね。lenovoでは販売終了になっているようですし、アキバで中古品を探すしかないですかね。
吉里吉里プラグイン。release版なのに、ドキュメントには堂々とβ版と書かれたままになっているあたり、さすがです、俺。そのままだと格好悪いので、こっそり差し替えておきます。