2002-11-18
_ 頭痛と鼻水と腹下し (20:02)
朝起きたときはそこそこ体調が良さそうな気がしたのに、ムスコを保育園に送って返ってきたら一気にぐったり来たんで、今日はお休み決定。今回の風邪の主な症状は頭痛と鼻水と腹下し。そんなにひどくはないんだけど、微妙につらい状態が長く続く。普段は風邪薬が結構効く体質なんだけど、今回の風邪にはあんまり効かないなー。
_ TrackBack (20:02)
TrackBackという機能
blogネタで話題になったMovableType。基本機能の部分には大して興味がなかった（ありがちなものの集大成というだけ）し、RSS配信ってのも別にやればいつでもできる（けど再利用する人が出てこないと面白くない）よなーと思っていたんだけど、TrackBackって仕組みはちょっと興味を引かれるな。こういうのをWikiCloneでも取り込むといいかもね。
- http://www.movabletype.org/docs/mtmanual_trackback.html
- 日本語訳 - http://lowlife.jp/translation/mttrackback.html
- 2003/04/05 「TrackBackの図解」を追加
今のところ複数のWikiサイト間のつながりはInterWikiで表現しようってのが主流なんだろうけど、個人的にInterWikiってのはあんまり面白いと思わない。リンク（とページ生成コマンド）だけはつながるけど、それ以上のつながりがあまりにもないし。まあたったあれだけの実装であのくらいつながると言うこと自体は面白いけど（っつーかWiki自体がそういう面白さの積み重ねだから、それを否定しちゃおしまいって気もするけど）。
TrackBackのポイントは、ある記事（WikiCloneならばWikiPage）への他サイト（のWiki）からの言及を取り込む仕組みを用意しよう、ってことだろう。その仕組みも非常にシンプルだ。ある記事に他のサイトから反応する場合、あるURLを「対象の記事ID」と「反応したURL」を引数につけて呼んでくれれば、システムはその記事に対する他サイトからの反応があったことを認識する、というだけのもの。
tDiaryみたいにReferer解析をそういう用途で使えるように実装しているシステムがあったり、アクセス解析を使って手動でそういうことをやっている人は結構いるだろうけど、共通フォーマットを定めてシステムとしてそういうことが出来るようにするってのはいい考えだな。ずいぶん昔から「Web日記同士の言及リンクがわかりやすい更新報告型リンク集:http://ishinao.net/diary/?200201c&to=200201281#200201281」を作りたいといろいろ考えていたんだけど、リンク集という形式ではなくP2Pベースに実装するという考えは思いつかなかったよ。
WikiLikeでのTrackBackサポート方法（文字コードについて）
ここのWikiLikeでも実験的にTrackBackをサポートしてみました（RSSとTrackBackを実装を参照）。現行のTrackBackの仕様書には文字コードに関する情報が盛り込まれていないため、その部分を拡張しました。
- http://host.domain/dir/tb.php/sid/****というPATH_INFOの2階層目に入力文字コードを指定
- ie=****という要素（GET/POST）で入力文字コードを指定
- charset=****という要素（GET/POST）で入力文字コードを指定
- 投稿要素の文字列から自動認識を使って入力文字コードを判別
という順序で入力文字コードを指定します。最初に見つかった要素が優先です。
送信側としては、POSTするパラメータにcharsetを追加。多分これが一番直観的な実装なんで文字コードの解決手段としてはこの方法に収束していくといいな。うちはしばらくの間はすべてのパラメータを受け付けるようにしておきますけど。
TrackBackの送信側インターフェースも実装。文字コードは送信時にドロップダウンから選択できるようにした。ただ、本文の最初の255文字を抜粋として送信しているんだけど、そうするとほとんど元の引用文部分だけになっちゃうな。それはちょっといまいちかも。
※文字コード指定文字列は、受信側はそのままPHPのmbstring系関数に渡しています。送信側はutf-8/euc-jp/shift_jisで渡しています
_ TrackBackを実装する (20:02)
TrackBack的なものをWikiLikeに実装するとして、どんな感じにするといいだろう。もともとのTrackBackの実装を参考にしつつ、自分で欲しい機能を中心に仕様を考えてみる。
TrackBack的な機能を実装するにあたって抑えておきたいポイントとしては、
- 他のサイトの記事→自サイトの記事の言及について
- 他サイト側から自サイトへの通知が簡単
- 自サイト側の通知の受け取りが簡単
- 他サイトのどの記事（URL）が自サイトのどの記事（記事番号）に言及しているか
あたりだろう。
あとどうせこういうものを実装するならば、
- 専用クライアント→自サイトの記事の言及について
- 専用クライアントから自サイトへの通知が簡単
- 自サイト側の通知の受け取りが簡単
- 専用クライアントからの言及については、そのコメント本文自体も受け取る
なんて機能も実装したいところだ。
さらにそれらのインターフェース（API）について、特定の実装に依存するのは避けたいところなので、
というのもある。
あと、WikiCloneをはじめとする特殊な機能（単なるblogシステムよりも高度な機能）をもっているシステムで使った際に、さらに有用な機能を追加できるように、
- 送受信APIは、拡張情報の受け渡しに対応できるようにする
- ただし、基本的になAPIの利用は手軽である必要がある
ってな感じで試しにWikiLikeに実装してみて、複数サイトに置いたWikiLike同士で通信できたらどんな感じになるかを試してみよう。なんてことをやっていると、いつまで経っても完成しない罠。
_ TrackBackインターフェース (20:02)
TrackBackの受信側のインターフェースの実装はそんなに難しくないよな。試しに作ってみたけど、簡単に実装できる。ところでIEってヘッダにtext/xmlを返さないと、内容がxmlでもxmlと解釈（表示）してくれないんだっけ？
閑話休題、受信側のインターフェースにコメントの実体まで受信するとなると、それをどう処理するかを抽象化するのが難しそうではある。WikiLikeだったら、そのままコメント欄にPOSTしちゃえばそれで終わりなんだけど、一般的なインターフェースとして考えるともうちょっと融通が利くようにしておかないとまずいだろうし。
何にしろ、受信側はそんなに難しくなさそうだ。が、送信側が結構面倒くさい。えーっと、本家のTrackBackは送信側のインターフェースをどうやって実装しているのかな？ 単純に考えると、コメント先のTrackBackインターフェース（ping url）と記事番号をフォームに手入力する感じ？ なんかそれはかなりいまいちだよなー。
本当ならば、コメント先のurlを入力すると、そのurlから自動的に相手先のTrackBackインターフェースの実装を問い合わせて、TrackBackインターフェースにTrackBack情報を送る、みたいな実装がいいよなー。コメント先URLのQUERY_STRINGにたとえば「?sysinfo」とかつけたら、必ずそのシステムのTrackBack（をはじめとするコミュニケーション系の）APIの実装に関する情報を（xmlで）返す、みたいなメタ情報向けAPIはやはり欲しい。
2004-11-18
_ やられた (12:53)
下の子の風邪をまんまとうつされたぜ。上からも下からも状態。最近家族全員別の場所（会社・保育園）に通っているから、風邪菌のバラエティも豊富になって、治った頃にまた新しい風邪をひく状態が続いているなー。もうこれで何週間風邪をひき続けているんだろう。
_ 転送量とか (14:42)
また、送り手のコストの問題として、転送量増加というのも意外な障害である。具体的に、私が現在使っているTypepadで、現在のPlusプランでは１か月3GBの制限があるのだが、拙ブログの現状では2000Hit/日くらいで、このキャップの80%くらいになってしまう。Proレベルにアップグレードすれば5GBまでキャップが増えるが、それもこのまま成長していけばすぐだろう。
あたりを読んで。
MovableTypeって、自動的にgzファイルも作ってコンテントネゴシエーションを利用するような設定にできないのかな？ ほとんどがテキストベースのblogサイトの転送量問題なんて、それでほとんど解決するんじゃないか？
ちなみにblogmapは1ページあたりのデータサイズは結構あるけど、ほとんど圧縮かけているから、1日10万ヒット（8万ページ）でも月間転送量は20Gバイトくらいですんでいる。あ、下りだけの話ね。上りはその3倍くらい。
ただ、ブラウザでHTMLを表示する帯域よりも、RSSの帯域の方が多いようだったら、ちょっと微妙。RSSリーダーで、Accept-Encoding: gzip, deflateしてるやつとかあるのかな？
ちなみに
現在のblogmapのトップページだと、無圧縮で51kバイト、圧縮して10kバイト。ほぼ1/5になっている。
_ バックアップの方法 (17:00)
「Sleipnir作者、開発マシンが盗難に遭う」を読んで。
Windows系の開発者っていまだにバージョン管理ツールとか使っていない人、結構いそうだよなー。いや、Sleipnirの作者さんは、もしかしたらローカルでCVSとか使っていたかもしれないけど。
現状バックアップ環境ってものがいまいち整っていない原因のひとつは、やっぱり手軽なサーバー環境が少ないからだと思う。ふつうのプロバイダが提供するサービスに、WebDAVとかSubversionとか（SSL＋認証設定可能）があれば、結構気軽にサーバーにバックアップを取ったりできるだろうに。
現在一番手軽なのは、さくらの専用サーバーかなー。月6800円という値段は、Web＋メール＋20Gディスクスペース＋安定したネットワーク環境＋電気代等考えれば十分その価値があると思うけど、それを値段分だけ使いこなすスキルが必要ってところが難。Webmin経由でしか設定をいじらないとしても「誰でもできる」というわけにはいかないからなー。
デスクトップLinux関係はいろいろ頑張っているところがあるみたいだけど、個人用サーバーLinuxというターゲットも今後は需要が増えるんじゃないかな。コントロールパネルの発展系なんだろうけど、もっとデスクトップLinux並にターゲットユーザーを低くする感じで。
ちなみに俺は、ここ最近はSubversionをバックアップ環境のメインとして使っている。cron＋pdumpfs＋rsyncとかも試してみたけど、その手の自動バックアップの仕掛けは、ディレクトリ丸ごとバックアップとかになっちゃって、長い間使っているうちに不要なデータがたまりすぎて、たまりすぎたバックアップデータの管理（人間ガベージコレクション）が面倒くさい。
Subversion＋TortoiseSVNだと、自分の好きなタイミングで好きな部分（ディレクトリ、ファイル）だけバックアップできるし、差分も必要最低限しか残らないので、検索性も高い（cron＋pdumpfsだと不要でも定期的にバックアップが取られてしまうけど、個人用バックアップの場合はそこまで完璧なバックアップは逆にじゃまくさい）。あと「ここはテンポラリだから、バックアップ不要」みたいな設定も柔軟に（そのディレクトリだけignoreすればいい）できる。あと、CVSと違ってバイナリのコミットとかファイルの移動とかも気楽にできるし。
ただ、バージョン管理システムというものの概念と、それにまつわる操作のコツがわからないと、ちゃんと使いこなせないだろうな、とも思う（TortoiseSVNを使っていると、普段の操作はExplorerから手軽にできるけど、ディレクトリの移動・削除とか、ファイルの移動とかは、Subversionの仕組みを意識しながらやらないといけなかったりする）。あと、ソースコードのバージョン管理に使うならばSubversionのフル機能（差分管理とか）が必要だけど、単なる履歴付きバックアップストレージとして使うならば、そこまでの機能はいらない。というか、ない方が使いやすい。
ちなみに今まで自分が試してきたバックアップ環境の歴史は、
- 手動でメディア（フロッピーディスク、MO、CD-R、別ハードディスク）に気が向いたときにフルコピー
- 半自動で別ハードディスクに差分コピー。ときどき気が向いたときに外部メディアにフルコピー。
- 半自動で別ネットワークドライブに差分コピー。
- JUST SYSTEMのInternetDiskサービスと専用クライアントツールを使って、気が向いたときに外部サーバーに差分コピー。
- pdumpfsで別ハードディスクに履歴付きコピー＋手動rsyncで最新データを別サーバーにコピー。
- バックアップしたいデータは必ずEclipseのプロジェクトにして、EclipseのCVSプラグインでCVSサーバーに手動コミット（履歴付きバックアップ）。
- Subversion＋TorutoiseSVNで、バックアップを取りたいディレクトリをExplorer上でプロジェクト化し、必要なときに必要な分だけ手動コミット。
なんて感じかな。順番はだいたいあっているけど、必ずしもまっすぐ下に下りてきたわけではなく、途中で行ったり戻ったりも結構ある。そういや昔々のデータって、家のどこかにふるーいHDDという形式で埋まっているんだよなー。DOS/VとかWindows 3.1とかの頃のIDEとかSCSIのハードディスクからデータを吸い出すのは、今となっては大変そうだ。
あとちなみに、ここに書いたのはあくまでも個人的なデータのバックアップ方法であって、サーバーのデータとか仕事関係のデータのバックアップについてはまた別の話。
_ ただただし [「上りはその3倍くらい」ってとこで、ちょっと笑ってしまいました(笑)]