ってことなのかなー。先週いっぱい苦しんだ風邪もこの土日で治ったかなーと思っていたのに、昨日の夕方くらいになってまたひどい頭痛と鼻水が始まった。風邪がぶり返したんだと思っていたんだけど、どうも周りの話によるとすでに花粉症が始まっているらしいね。確かに頭痛と鼻水ってのは花粉症の症状でもあるからなー。うーんどっちなんだろう。

そういやDirectXって、もう.NET Frameworkに対応しているのか。.NET系言語でDirectXゲーム書くのって楽しそうだなー。半年以上仕事でVB.NETやってきたけど、仕事にとらわれないのならばC#を使った方がいろいろ良さそうな気がするし、C#に慣れるためにちょっとDirectXで遊んでみようかなー。

PostgreSQL（バージョン6.x）をしばらく運用しているとlogファイルが巨大になってくる。logファイルなんだから消してもいいだろうと、適当にmvしたりする人がまれにいる。が、PostgreSQLのlogファイルは人間が目で見るためのテキストlogファイルではなく、PostgreSQLの動作に必要なバイナリファイルであり、それを消すとPostgreSQLがまともに動かなくなる。

という状態になってしまったデータを復旧させてくれないかと頼まれていろいろ調べてみた。

PostgreSQLはupdateなどでデータを書き換える際に、実際にデータを書き換えるのではなく、既存のデータに無効フラグを立てて見えなくしつつ、新規に新しい内容のデータ領域を作成してそちらを有効にする。updateをかければかけるほどデータ領域はひたすら増え続けていく。そのため、定期的なvacuumを行って不必要なデータ領域を削除したりする必要がある。

PostgreSQLではすべてのSQLコマンドはトランザクションで囲まれているものと見なされる。明示的にbegin;commit;で囲まれていないSQLコマンドも、内部的にはその前後がbegin;commit;で囲まれているものとして処理する。そして、すべての処理は32ビット連番のトランザクションIDが割り当てられている。ある処理で変更があったデータには、その処理のトランザクションIDが記録される。

先ほどの「書き換えられたデータに無効なフラグを立てる」という処理には、このトランザクションIDが関わっているようだ。ある行の内容を書き換えた場合、その行には古いデータと新しいデータの二つが存在することになる。それぞれには、そのデータが生成された処理のトランザクションIDが記録されている。現在のトランザクションIDと比較して、より現在のIDに近いトランザクションIDをもつデータが、その行の最新のデータとなる。

logファイルはどうやらトランザクションを管理するデータらしい。logファイルを削除するとトランザクションIDがリセットされてしまう。実データは別ファイル（baseディレクトリ以下）に記録されており、logファイルがおかしくなってもそちらは影響を受けない。しかし、トランザクションIDがリセットされると、実データファイル側に記録されているトランザクションIDとの間に矛盾が生じるため、データが見えなくなってしまう。たとえばトランザクションIDが1000の状態で記録されたデータは、トランザクションIDが100の状態では見えない。

そのようになったデータを再び見えるようにするためには、現在のトランザクションIDを、実データファイルに記録されている最新のトランザクションIDよりも大きくしてやればいい。トランザクションIDを直接操作する方法は見つけられなかったが、SQLコマンドを1回発行すれば現在のトランザクションIDが1増えるので、特に意味のないSQLコマンドを必要な回数だけ発行してやればトランザクションIDを増やすことができる。

データに記録されている最新のトランザクションIDを知る方法も見つけられなかった。もしもDBの利用頻度が分かっているのならば、たとえば「1日の平均トランザクション数×運用日数」などでトランザクション数を予想して、その回数分SQLコマンドを発行してやればいい。利用頻度が分からない場合は、oidを使ってトランザクションIDが最新に追いついたかどうかを類推する方法がある。

害がなさそうな適当なテーブルに対して、1行新しい行を作成し、その行のoidを見る。トランザクションIDはリセットされても、oidはリセットされないようなので、oidはリセットされる前の最新のoidよりも新しいものが割り当てられる。その値を基準として使うことになる。

トランザクションIDを進めていくと、少しずつデータが復旧していく（古いトランザクションIDをもつデータから見えるようになってくる）。そこで既存テーブルの中で新規行の作成が頻繁であったと思われるテーブルのもっとも大きなoidをチェックする。データが復旧していくとそのoidの値が大きくなっていく。その値が先ほど得た基準となるoidの値に限りなく近くなる＝データが元の状態に復旧した、ということになる。

トランザクションIDがリセットされると、システム管理テーブルの内容も見えなくなるので、テーブルのスキーマ情報なども得られなくなる。が、トランザクションIDを進めていくことで、システム管理テーブルの内容も回復し、スキーマ情報も得られるようになる。ただし、sequenceやindexなどのデータは完全に回復できないこともあるようだ。それらはスキーマと実データを使って、再生成・設定すればいいだろう。

私の場合は「select 1;」を100万回実行するたびに、oidをチェックし、対象テーブルの最新oidが増えなくなってからさらに念のため200万回ぶんトランザクションIDを進めた辺りで、だいたい元のデータが復旧したと判断した。そのあたりの判断はDBの設計によって異なるだろう。

• 書評リンク - http://member.nifty.ne.jp/ippo/s_d200302.html#d8_t1

あちこちでやっていてポイントを抑えてリンク張るのが難しいんで、興味がある方は上記からあちこちたどってみてください。

で、俺の場合は、「さまざまな個人Webサイトにおける各自ばらばらな行動の中から、ある一定のベクトルをもつデータを抽出して整理して見せること」一般に対して興味があって、そういうベクトルの一つとしての「書評リンク」に興味があるという立場なんで、この手の話をしようとすると話が発散する方向に向かう可能性が高い。風呂敷がでかくなりすぎるというか。という言い訳をしてから話をはじめてみる。

まずは、個人Webサイトにおけるさまざまな情報を、Webサイト同士でやりとりするための、RSSみたいなXMLベースの汎用データフォーマットを決める。んでもって、主だったWeb日記システムやコンテンツ管理システムが、そのフォーマットのデータを自動的に生成できるようにする。

それから、Webサイト間でそのデータをやりとりするためのインターフェース仕様を決める。できればシンプルな（実装しやすい）ものから、汎用性・機能性の高い（けどちょっと実装が面倒な）ものまで数パターンあるといい。あと、インターフェースの起動方法も複数用意しておいた方がいい。個人Webサイト側から送信するパターンとか、集約サーバー側からデータを引っ張ってくるパターンとか。起動に人間が必要なパターンと、必要ないパターンのどちらも用意しておいた方がいい。

そのあたりはアンテナ（サイト更新情報リンク）文化のやり方とかblog系システムのやり方を参考にすると良さそう。アンテナ文化ではLIRSとかDIとかみたいな、個人Webサイトで生成したデータを他のサイトで二次利用するという仕組みを実践的に使ってきている。あと、MovableTypeにおけるTrackBackを使ったサイト間をまたがったやりとりの仕組みとか、RSSを使ったデータ配信の仕組みとかが参考になる。

あんまり深く考えずに適当な仕様を試しに書いてみると、たとえば各個人Webサイトでは、書評を書いたら、各Web日記システムなどが以下のようなフォーマットのデータもはき出せるようにしておく。

<?xml version="1.0" encoding="utf-8" ?>
<bookreview>
<site>
<title>ishinao.net</title>
<url>http://ishinao.net/</url>
</site>
<item>
<updt>2003-01-20 23:54</updt>
<isbn>4150306931</isbn>
<title>ムジカ・マキーナ</title>
<author>高野史緒</author>
<comment></comment>
<url>http://ishinao.net/WikiLike/?sid=147</url>
</item>
</bookreview>

このあたりの項目に関しては、必須項目とオプショナル項目をいろいろ設定しておいて、あったらそれをちゃんと使うし、なくてもそれなりに扱えるようにしておくといい。上記は書評関連しか考えてないけど、本当はベースとなる汎用フォーマットを決めて、その上にジャンルごとの拡張フォーマットが乗ってくるようにするときれいだろう。

んでもって、それをどこかの書評リンクサイトに送信するインターフェースを用意する。実際にやりはじめると認証とかいろいろ絡んでくるけれども、ひとまず情報を受け渡すだけなら簡単だ。個人Webサイト側からPOSTしてもいいし、個人Webサイト側からはこういう情報を得るためのURLだけを渡してやって、実際のデータは書評リンクサイト側から引っ張っていってもいい。

あ、Web日記システムを使っていない人向けに、集約サイト側の方で普通のフォームから必要な情報をその場で入力してPOSTするようなインターフェースも用意しておいた方がいいだろうね。

書評リンクサイト側の内部では、受け取ったデータをどういう形式で保存管理しても構わない。けれども、書評リンクサイト側でも必ず同様の形式でデータを出力できるようにしておく。んでもって、各個人サイト側からの要求に応じて、必要なデータを個人サイト側にも返してやると、個人Webサイト側で他のサイトのデータを再利用することも可能になる。ってのはあくまでもデータの二次利用性を高めるための仕組みであって、もっともメインとなるのは書評リンクサイト上でそこに集約されている情報を見せるリンク集ページ部分だろう。

んでもって、書評リンクサイト上に集約された情報に含まれるキーワード（＝ISBNもしくは著者名もしくは作品名）をベースにしたコミュニケーションツール（それがWikiであってもBBSであって構わない）とかを用意すると「はてなダイアリー的なものをグローバルに（http://d.hatena.ne.jp/ishinao/?date=20030203#p1）」な感じになってくる。書評に限らずノンジャンルで情報を集約するようにすればそのままはてなダイアリーっぽいし、各ジャンルごとにさまざまな集約サーバーを立てて独自の文化圏を作っていっても面白そうだ。

ってな感じのものを（ひとまず動くように）作るのはそんなに難しくないけれども、将来性のあるまともな仕様を決めたりとか、各Web日記システム用のプラグインを作ったりとか、参加者を集めたりとか、本気でやろうとすると結構大変そうだね。いろんな言語用のサンプルコードを書いたりとかも必要だし、まじめに集約サーバーを運用するとなるとお金の心配とかもしないといけないし。

書評リンクの話の続き。もうちょっと具体的な運用イメージを考えてみる。

リンク参加希望サイト側での参加イメージ。

• Web日記システムを使用している場合
  • Web日記システムを拡張して、汎用フォーマットのデータを出力できるようにしておく
    • オンラインで動的生成するタイプならば、CGIなどでいつでも動的に必要項目を汎用フォーマット化できるようにする
    • オフラインで動的生成するタイプならば、Web日記上の該当項目を汎用フォーマット化したデータも別途オンラインにアップロードしておき、該当項目そばにリンクを置くことによって、誰でもダウンロードできるようにしておく
      • 新規記事の汎用フォーマットURLを集約サイトに通知する
        • 簡単にQueryStringで渡してもいいし、複数記事ぶんをまとめてPOSTしてもいいし
        • 通知タイミングは、新規記事作成タイミングでもいいし、あとで適当にでもいい
        • あらかじめ集約サイト側にメンバー登録しておき、そのサイトのRSS URLを登録しておけば、集約サイト側から新規記事の存在確認をしに来る
  • 汎用フォーマットに対応できない場合は、Web日記システムを使用していない場合と同様
• Web日記システムを使用していない場合
  • 自力で汎用フォーマットデータを作って、それをWeb上にアップロードしておく
  • 集約サイトにいって、必要情報を投稿するフォームに各項目を入力する

集約サイト側の運用イメージ。

• メンバー登録されているサイトに対して、
  • RSSなどから最新の記事一覧を取得。記事一覧中に未取得の書評記事を見つけた場合、その記事に汎用フォーマットデータを取得
  • 各サイトの新規記事の汎用フォーマットURLの通知を受け取る。サーバーからその実体を取りに行く（オンタイムもしくはある程度まとめてから定期的に）
  • 各サイトから直接ポストされた汎用フォーマットデータを受け取る
  • サイト内に用意した投稿フォームからさまざまな形式での投稿を受け付ける

集約サイト側は、書誌データと書評データは分けて管理した方がいいだろうな。書誌データの方はAmazon Webサービスみたいなものが日本でも始まることを期待しつつ、基本的にはみんなで使い回せるイメージで。逆に集約サイトが書評サイトに書誌データを配信できるようにすることも考えた方がよさそう。

そうなると書評データの方は、ISBN＋各サイト独自の部分だけを集約サイト側に渡せばよくなる。書評の内容をどこまで集約サイト側に渡すかは、各サイト運営者の意志によっていろいろだろうな。少しも渡さないパターンもあれば、さわりの部分だけ渡すところもあれば、全文渡しちゃうところもあるだろう。どうせなら、サイトをもたない人が集約サイトにだけ書評を投稿できる仕組みももった方がいいんだろうな。

あと、集約するしたときの面白さのために、書評データには評価ランクみたいなわかりやすい項目もオプションとして用意した方がいいだろう。そうすると、評価ランクの平均とかいろいろ面白い見せ方ができるだろうし。

ISBNはキーとして使えるのか、という話について。以下ISBN絡みについてのまとまった資料へのリンク。

• 日本図書コードの仕組み - http://member.nifty.ne.jp/rain/misc/isbn.html

まれに同一のISBNが別の書籍に振られている場合があるらしいけれども、楽天みたいに「出版日が新しいものを優先」ってことで、古い方は対象外にしてしまって構わない気がする。どうしても扱いたいならば、存在しないはずのISBN（風コード）を生成して無理矢理それで代替させるとか。

目的が「完璧な書誌データDBを作成すること」ではなく、「書評リンク集の基盤として使えるレベルの書誌データDBが欲しい」ならば、ISBNをキーに作成した書誌データDBでも十分に実用に耐えるだろう。イレギュラーなデータに対しては、運用でカバー（イレギュラーな対応を用意）で問題なさそう。

ISBNが不明な段階での書誌データ（主に新作を想定）に関しては、別テーブルにいったんデータを蓄えて、ISBNが定まった時点でメインのテーブルにデータを移行。ただし、書名や著者名による検索に関しては、そのテーブルに対してもメインテーブルと同様に（透過的に）行えるようにする。なんて感じでどうだろう？

あと、データフォーマットの話。タブ区切りテキストとかCSVとかだと、1フィールドに複数の情報をもたせるのがやりにくいのがガンなんだよな。適当なフィールド内区切り文字を予約して、それを使って表現することは可能だけど、そういう拡張をごちゃごちゃ考えるくらいだったら、はじめからその辺りまで吸収できるフォーマット（XMLとか）を採用した方が幸せになれる気がする。

というのは、そのデータフォーマットを再利用性のあるものとして扱いたい場合の話で、そこまで考えないならば、タブ区切りテキストとかCSVでも十分だと思う。その場その場で必要な情報を盛り込んだデータフォーマットを使うのは問題ないけれども、バックエンドで管理するデータに関しては多少リッチな情報をもっておいた方がいいよね、という話。いつでもリッチな表現（＝解釈にかかるコストが大きい）を使うのはバカらしいけど、後付けで必要になってずるずる仕様を拡張するのも大変だしね。

Amazon.comのWebサービス（XML Webサービスの方ね）を試してみた。PHPからアクセスするのも簡単そう、というか環境設定の敷居が低そうなんで、いろんなサーバーで使えそうだ。Amazon.co.jpでも始まってくれたら、自前のDBに情報が見つからなかった場合は、自動的にAmazon.co.jpにアクセスして必要な情報をもってくるような、書誌データ集約サーバーとか簡単に作れそうなのに（という利用法はグレイっぽいけれども、まあ言い訳を用意するのもそんなに難しくないだろう）。Amazon.co.jpの方でWebサービスをはじめる予定はないのかなー。

• http://ishinao.net/pukiwiki/

特に使うあてのないWikiをPukiWikiで立ててみました。使いたい方がいれば適当に使ってください。情報集積所とか意見交換所とか。

うひゃひゃ、某仕事で使うテスト機のSH2101Vが来たよ。店頭以外でこんなもの触ったことがある人は世界でも100人単位のオーダーでしかいないに違いない。っつーか、まったく興味がない機械だったから、まったく情報をもっていない状態で触りはじめたりしたんで、使い方がさぱーり分かりませんよ。しかもこの機械、基本的にものすごく使いにくいインターフェースの持ち主だし。機械ものでここまで使い方にとまどったのは、は・じ・め・て（はぁと）って感じですよ。

ちなみにSH2101Vってなんなのかいまだに分からない方のために簡単に説明しておくと、NTTドコモさんのFOMAとかいういまいちな次世代規格機において、さらに異端児的な存在であるPDA風（？）端末のことです。なんかPDAみたいなでかい本体があって、それとBluetoothで接続するスティックタイプの受話器がついてくるんですよ。本体のOSが（旧）ザウルス系だってのは本当なのかな？

せっかく遊んでいい機械なんだから、しばらく持ち歩いて遊ぼうかと思ったんだけど、本体部が思ったよりもずいぶんでかくてじゃまなんで、普段から持ち歩いて使うってのはちょっと無理っぽい。っつーか、これだけ使い勝手が悪い機械じゃ、どっちにしろ三日でいやになりそうだ。

まあともかくSH2101Vで作ったasfファイルはffmpegでまともにデコードできるみたいでほっと一安心。なんかちまたに出回っているmpeg4エンコードされたasfファイルって怪しげなエンコードがされているものが多いのかな？　昔のシャープ製エンコーダが悪いのか？

ウムイの「凡人はつらい（http://www.ag.wakwak.com/~mai_u/umui/200302b.html#200302121908）」に書いたWikiに関するコメント。自分のところにもログとして残しておこう。

ishinao：Wikiは「Webの再開発」的な意味ももっていて、あまりにもサポート範囲が広い（夢が大きい）んで、まだまだこなれてませんけど、そのうちWikiの延長に普通に使いやすい何かが出てくるんじゃないでしょうか（技術者の遊び道具レベルで終わる可能性もあるけど）。Wikiって（現状では）一般的なWebのサービスよりもWebDAVとかと比べて語られるのが似合っている気がする。（2003/02/13 09:15）

ishinao：子門さんの言葉を借りると、Wikiは「プラットホーム」であり「アプリケーション」でもある（まだその辺りの切り分けが明確ではない）ので、プラットホームとして捉えるとWebDAVとかの仲間になるし、アプリケーションとして捉えるとblogシステムとか関心空間の仲間になる、って感じじゃないでしょうか。作る人はアプリケーションよりの意識で作るんだけれども、「プラットホームとしてのWiki」の定義が定かでないので、ある程度プラットホーム構築的な部分も意識せざるを得なくなる。Wiki Wayなんて言葉が出てくるくらい思想的な面白さもあるし。（2003/02/13 15:08）

ishinao：Wikiには「何もかもユーザーの自由にさせたい」という思想が背景にあり、しかし「あまりにも自由である＝使いにくい」ので、「使いやすいインターフェースを用意したい＝自由を制限したい」という葛藤が出てきてしまうのです。既存のWikiクローンは自由を尊重しすぎているため、その思想を理解した人が用途を限定して使わないと、すぐにぐちゃぐちゃなコンテンツができあがってしまう。（2003/02/14 09:17）