ようやくAmazon.co.jpでもWebサービスが始まったんで、それにも対応。こっちはGoogle Web APIよりも多機能なんで、さらに使い道がいろいろ思い浮かぶ。ただうざくないように組み込んでいくのはそれなりに難しいし、HTTPごしだという信頼感のなさにもそれなりに対応する必要があるんだよな。

ひとまず読書感想系ページに関しては、Amazon.co.jp Webサービスにべったりと依存した作りにしてみた。Amazonこけたらみなこけた、になりそうなくらい。ひとまずプリミティブな機能のみを利用してみているけれども、今後もうちょっとリッチな機能もいろいろ使ってみる予定。

それにしても、キーワード検索がまともにヒットしないのはどういうことなんだろう？　カテゴリー選択あたりが怪しい気がするんだけど。

ここ二ヶ月くらいろくに読書関連の情報を入力していなかったので、未入力の書誌情報がやたらとたまっている。がんばって入力してみたんだけど、半分も入力しないうちにやる気を失った。今日のところはここまで。それにしても、Amazon.co.jp Webサービスが始まってくれたおかげで、書誌情報の入力が楽になったなー。もうちょっとAmazonのDBの精度が高いと、さらにうれしいんだけど。

サイト全体をWeb XP管理下に置いた。一応この程度の機能だったらなんとか表現し切れるみたいだな。まだまだやるべきことは残っているけれども、ひとまず基本機能に関しては初期実験は終了といった感じか。どのくらいの負荷がかかるかをチェックしてみないとな。

ついでにいろいろコンテンツを整理した。すでに整理済みだったものを合わせて、だいぶすっきりした状態になった。あとは生き残っているものたちをさらにリファインしていく作業か。いやその前に、まだ基本機能を充実させていった方がいいかな。

スタイルシートって、必要なパーツに対しての装飾用でしか使ったことがないから、真面目にHTMLの論理構造とマッピングさせて使おうとすると、根本的な知識の不足を感じる。一からちゃんと勉強すればいいんだろうけど、デザイナーじゃない人間がそこまで覚えなければならないのかよ、という気もしていまいちやる気にならない。でも論理的なスタイルシートベースのデザインが出来るデザイナーって少なそうだし、ここまでプログラマーの領分だと考えておいた方がいいんだろうか。

とか考えながら、味も素っ気もなかったこのサイトにデザイン要素を載せてみた。まだ試行錯誤中＆ブラウザ互換性はあんまり考えられていないかも。一応ネスケ4でもそれなりには見えていた気がするけど。

予選1日目

いやー、やっぱりコクーンはいいなー。何も考えなくても自動的に予選1日目から録画してくれるよ。F1みたいに撮り捨てでいい番組を見るのには抜群にいいよなー。ただ、まだ使い方が甘いせいか、自動的に録画してくれる番組のゴミ率が多いし、番組録画の途中で次の番組に（スカパーのチャンネルが）勝手に切り替わっちゃったり、わけのわからない挙動も多い。筋は悪くないと思うんだけど。ってコクーンの話をはじめると長くなる。

イギリスらしい曇天の予選1日目。今シーズンは波乱が多いけど、さらに波乱の要因が増える曇天は歓迎。

あららら、バリチェロダメじゃん。せっかくタイムが出そうな雰囲気の時にこういうミスをしちゃいますか。なんか悪循環というか。ライコネンもずいぶんいまいちだな。予選ノータイムが多くてチームに絞られたんだろうか？

トヨタ良さそうだな。これがフロックじゃなければ、一気に一段飛び抜けて5番手チームにつけたかも。

ハイドフェルドは来年クルサードと代わってマクラーレンかなー。安定感がないんじゃ、ベテランドライバーをキープしておく価値がないからなー。それならまだ若くて元気な（安い）ドライバーを二人そろえた方がいい。ハイドフェルドがフェラーリ入りって展開も面白いけど、その線は薄そうだ。フェラーリならばまだフィジケラの方があるか。トゥルーリでもいいけど。

で、ひとまず1日目はミハエルがトップで、ウィリアムズ勢が続き、ルノー勢が相変わらず良くて、マクラーレンはいまいちって感じか。トヨタは予選2日目から決勝にかけて、どのあたりのポジションにつけるかな。

決勝

うげ、予選2日目を録画したのに見ないうちに決勝の時間が来ちゃったよ。バリチェロがポール、トゥルーリが2番手だったのかよ、と思いきやスタートでトゥルーリがバリチェロをかわしてトップに。さらにライコネンが2番手につけてバリチェロは3番手。後ろでミハエル、アロンソ、モントーヤも絡んでいるし。なかなか出だしから面白そうだな。

クルサードのヘッドレストが飛んでペースカーという、訳の分からないアクシデントに続いて、コース内に乱入者（アイルランド問題ですかね？）でペースカー。ちょうどいいタイミング過ぎてみんなで同時ピットストップしたら順位がぐちゃぐちゃ。トヨタの1-2体制とか訳の分からない状態に。

おお、バリチェロ今日は速いじゃん。速い車をコース上であそこまで強引に抜くところは久しぶりに見たよ。

すげーな、トヨタ。あのくらい1-3体制をキープできたってのは、かなり車の戦力が高いってことだよな。でも結果に結びつけないのか。もったいないなー。

おお、バリチェロ自力でコース上で抜いてトップに立ったよ。

いつのまにやらミハエルが4番手に。そしてミスったライコネンが3位まで落ちてきてくれて、獲得ポイント差（予定）が1まで減っちゃったか。

というわけで、バリチェロ久しぶりに優勝。バリチェロ速かったなー＆ミハエルぱっとしなかったなー。モントーヤ全然目立たなかったけれども、いつの間にか2位だったなー。トヨタは何とかポイントは取れたのね。

Amazon.co.jp Webサービスが始まって、書籍、CD、DVD、ゲーム、PCソフト、電気製品まで幅広く、書影／製品写真＋書誌／製品情報を取得できるようになったおかげで、Web上で気軽にいろいろ更新できる表現手段として、テキスト＋論理マークアップ（Wiki文法）に加えて、ASIN（ISBN）リンクというものが加わった。

現在、キーワードにASIN:******という形式を入れておくと、自動的にAmazon.co.jp Webサービスから各種情報を取得し、そのドキュメントに写真や各種情報を表示するようにしている。取得できる情報としてはそのほかに、Amazon.co.jpに登録されている他人の書評や評価ポイント、関連商品情報などもあるんで、さらにリッチな表示にしようと思えば簡単に出来る。

あまりやりすぎると自分の書く本文の価値がなくなってしまいそうなんで、使い方をちゃんと考える必要があるけど、シンプルなドキュメントを書くだけで、自動的に関連する各種情報を取得できて、ドキュメントの装飾的に表示できるってのはありがたいな。

特に画像は自分で作っていると時間がかかってしょうがないんで、自動的にそれなりのものが取得できるってのはとても便利。画像があるとないとでは、見た目の印象がずいぶん違うしね。

けど、会社の業績が良くないとのことで0.5ヶ月減。まあ額はどうでもいいんだけど、ほぼ1年間人を島流しにしておいて、戻ってきたらなんだかわからないけど「業績が良くないからもっとがんばってくれ」とかいうのはやめて欲しいな。営業が仕事を取ってこれないというのならば、現場レベルで仕事を取ってこようかと提案したら、「電話営業しろといったらするか？」とか聞かれてげんなりした。電話営業ですか。本気で言っているのかな？　「お前に出来るのか」と暗ににおわせたいのかな？　それとも骨の髄までトップダウン的な考え方しかできないのかな？　まあ実際俺にどの程度何が出来るのかはわからないけれども、少なくとも売り物になる技術はいろいろ持っているつもりなんだけどな。うちの会社の人間にはほとんど理解されていないみたいだけど。

昼から草野球。雨が降りそうで降らず、しかも曇っているくせにやたらとむしむしと暑くて、雲の陰からさんさんと紫外線が降り注ぐ一日。なかなかたくさん汗をかいた。野球の内容は、一言で言うとダメでした。フライ取るのへたくそすぎ。バッティングの方は、そんなに悪くない感じだったのに結果は出なかった。キャッチャーミットの使い方のこつをちょっとつかんだかな、というのが唯一の収穫か。

wikilogもTrackBackに対応したようなしないような。一応送受信＋charsetパラメータには対応したけれども、RDFでのPing URL通知とかまで対応するのは面倒くさいなー。利用頻度の割には実装が汚すぎるし。もうちょっとTrackBackが一般化して使われるようになったら考えよう。というか、その頃にはTrackBackに取って代わる規格が出てきているかな。

• Functional API for XML --- xFAX - http://www.ba.wakwak.com/~fuchi/rubyxml/rFAX/doc/

作りかけて放棄したHTMLレンダリングエンジンのアプローチにちょっと似ているかも。作ろうとしていたHTMLレンダリングエンジンは、XMLではなくて、PHPのarrayを使ったツリー構造データなんだけど、その各ノードに、

• テンプレート（ファイルもしくはテンプレート文字列そのもの）
• データ（型は自由）
• レンダリング関数（関数名文字列、もしくはAbstractRendererを継承したクラスのインスタンス）

を持ち、テンプレートファイルをデータとレンダリング関数を使って展開しつつ、ツリーのノードをたどっていくイメージだった。どうやってそれを表現し実装するかは、あまり具体的に考えていなかったんだけど、もしXMLでその定義ファイルを書くと、

<item name="html_header">
<template>html_header.html</template>
<data>$_ENV,$_SERVER,$_GLOBALS</data>
<renderer>replacer</renderer>
</item>
<item name="pagelist">
<item name="list_header">
<template>list_header.html</template>
<data>Page::ListCaption</data>
<renderer>replacer</renderer>
</item>
<item name="list_body">
<template>list_line.html</template>
<data>Page::GetList</data>
<renderer>iterator</renderer>
</item>
<item name="list_footer">
<template>list_footer.html</template>
<data></data>
<renderer></renderer>
</item>
</item>
<item name="html_footer">
<template>html_footer.html</template>
<data></data>
<renderer></renderer>
</item>

なんて感じか。多分内部的な処理としては、XML Functional Mapping（http://www.ba.wakwak.com/~fuchi/rubyxml/rFAX/doc/mapping.html）と似た感じになるだろうな。

ただ、この方向でこり始めると、手間を省くために作ったものが新たな手間を生み出したりする展開になりそうだったんで、途中であきらめた。でもいろいろややこしくなりそうな部分を一通りきれいに解決する方法を思いついたら、もう一度チャレンジしてみるかも。

テンプレートエンジン内で独自のマクロ言語を定義するアプローチよりも、ロジックを組み込みたければ純粋に（データ定義レイヤーではなく、ロジックレイヤーで）ロジックを書くアプローチの方が好みだ。