病院に行ってきた
いつもと同じタリオン錠10mgを3週間分と、緊急用にポララミン錠2mgを5日分。タリオン錠が聞き始まるまでは5日くらいかかるんで、それまでは抗ヒスタミン薬のポララミンで症状を抑えるがよろし、とのこと。ポララミンの方は眠気が出るらしいんで、仕事の時は使わない方が良さそうだな。
ひどい状態キープ
金曜日に病院に行こうと思っていたんだけど、打ち合わせが長引いていけなかった。しょうがないんで土、日は市販の鼻炎カプセルでごまかしていたんだけど、あれを飲むと眠くなりすぎて何もできない。でも、飲まないでいると鼻水と目のかゆみで何もできないしなー。今日はとっとと病院に行ってこよう。
早くも開幕戦
土曜日には早くも草野球の今シーズン開幕戦だった。最近いろいろ忙しくてスポクラにもろくにいけていない状態だったんで、体力的にはかなりぐだぐだ。でもまあピッチングは4回2失点ですんだんで、そんなに悪くなかった。バッティングは全然だめ。4打席で3三振1内野フライだったかな？ なんかバットが全然思ったところに振れない。当てにいっても芯に当たらないし、振りにいったらかすりもしない。ボールは見えているつもりなのになー。で、翌日からは予想通りの筋肉痛となり、現在老人のような動きしかできません。
しょうがない、認めてやろうじゃないか
一昨日あたりから急激に来ていたんだけど、もしかして風邪でもひいちゃったかな、なんて自分をごまかしていたりしたんだけど、そろそろごまかしきれないんで、認めてやろうじゃないか。今年も花粉がばりばり来てますよ！ 病院行ってこよう。
だりぃ＆ねみぃ
今日は、寝不足＋車のバッテリー上がり＋子供のお遊戯会で保育園まで徒歩で2往復＋重いバッテリーを買って歩いて帰る＋気の重い打ち合わせ、が重なり、非常にだりぃ＆ねみぃと書いていたら、頭の中で「Darry and Nemmyの二人が大活躍！ カートゥーンネットワークでこの後すぐ！」というCMが流れた。デクスターとディディ姉弟みたいなキャラクターが主役で、話の内容はエドエッドエディみたいな感じ。5年後くらいに新番組として始まったら、これはただの妄想ではなく、予知妄想だったってことになるでしょう。っつーか眠い。
サーバーとクライアントでテンプレートを共有したい場合
データとテンプレートの配置 その3で書いたように、同じURL引数違いで出力フォーマットを変えるインターフェースを、作ったり使ったりして試してみている。基本的な方向性は悪くなさそう。
- データ層 - ここは好きにやる
- 汎用データ取得層 - ここは汎用クラスとして一般的なインターフェースを持たせる
- アプリケーション用データ取得処理 - アプリケーション内で共用するインターフェースとして作る（キャッシュとかはここでかます）
- データ出力層 - HTML、XML、JSON、TXTなどリクエストに応じて、形式を変えて出力する
なんて感じで作ってみている。
で、そういう作り方をしていると、データ出力層では出力形式に合わせて複数のテンプレートを使い分けたりするわけだけど、どうせならばHTML形式の場合に、リクエスト側でHTML展開する時に使うテンプレートファイルを指定できるようにしておけば、それでいいんじゃないかって気がしてきた。
JavaScriptでがりがり出力したい場合は、
http://example.com/path/to/resource?format=json
とかやって、JSON形式で受け取ったデータをJavaScript側でDOM操作なりJavaScriptテンプレートエンジンなりを使って出力してやればよく、たいていの場合はその方法を使うことになるんだろう。その場合の流れは、
- クライアント - サーバーにリクエストを投げる
- サーバー - データをJavaScriptが扱いやすいフォーマットで返す
- クライアント - 受け取ったデータをJavaScriptネイティブな変数に展開する
- クライアント - DOM操作やJavaScriptテンプレートを使って、データを出力する
どうしてもサーバーサイドにあるテンプレートを使いたい場合は、
http://example.com/path/to/resource?format=html&template=templatename
とかやって、必要に応じてサーバーサイドで部品レベルのテンプレート展開処理をしてもらい、その結果を受け取ればいい。その場合の処理は、
- クライアント - サーバーにリクエストを投げる
- サーバー - データを指定されたテンプレートで展開したHTMLとして返す
- クライアント - 受け取ったHTMLをそのまま表示する
ただしこういうやり方は、サーバーサイド実装者とクライアント実装者が同じ場合にはやりやすいけど、そうじゃない場合（たとえば別管理者が公開しているリソースを利用したい場合）はそう簡単にはいかない。
けど、その場合はクライアント実装者が、自前のサーバーに簡単なプロキシ（＋テンプレート展開エンジン）を用意すればいいだろう。その場合の流れは、
- クライアント - プロキシにリクエストを投げる
- プロキシ - リソース提供サーバーにリクエストを投げる
- リソース提供サーバー - プロキシにリソースデータを返す
- プロキシ - 受け取ったリソースデータとローカルのテンプレートを使ってHTML展開処理を行う
- プロキシ - 展開したHTMLをクライアントに返す
- クライアント - 受け取ったHTMLをそのまま表示する
なんて感じか。
ひとまずそういう方向でいろいろ実験してみる。
script.aculo.usにすることにした
そろそろAJAX関連も実用レベルで使い始めなきゃなーって感じなんだけど、たくさんあるライブラリ群を調べる気力がない（し、高度なJavaScriptライブラリたちを正しく評価する能力もない）んで、雰囲気でscript.aculo.usを基本ライブラリとして使うことに決めた。これってスクリプタキュラスって読むの？
フレームワーク的な部分とユーティリティ的な部分を（script.aculo.usの一部として使われる）prototype.jsに任せ、基本的なエフェクト処理をscript.aculo.usに任せる、ってイメージでいいのかな？ あとYahoo!のUIライブラリあたりを部品として使いたいんところだけど、JavaScriptレベルでバッティングとかしちゃわないかな？
どっちがましだろう
Trackback vs Pingbackを読んだだけで、元文章はどっちも読んでいないんだけど、ひとまずtrackbackとpingbackを比べてみると、
- trackback
- いいところ
- 実装・利用例が多く、すでにデファクトスタンダード化している
- （URLのみやりとりするping backと比べると）得られる情報量が多い
- 悪いところ
- 仕様レベルでノーセキュリティ。SPAM対策が難しい。
- trackback ping URLの仕様うざ。機械専用の情報を人間様に入力させようとは、何事か。
- auto discoveryの仕様もうざ。ないよりはましだし、動くことは動くけど。
- trackback ping URLのせいで、リンク先URL、通知先（ping）URLを二重管理しなければならない。しかもその二つを結ぶラインは、auto discoveryという非常に弱いラインしかない。
- 文字コード問題には現行仕様では対応している（結局初期の頃にshiroさんが言っていた仕様になったってことか）けど、実装レベルで対応しているところはほとんどなさそう。仕様のアップデートに関するアナウンスよわっ。
- いいところ
- pingback
- いいところ
- シンプル＆スマート。逆に言うと、必要最低限。
- 人間は単にリンクするだけでOK（どこにどうやって送信するかなんて意識しなくていい）。
- URLと受信するサーバーとが切り離されている（HEADなどに受信サーバーURL（固定）を入れておくだけでいい。trackbackもある程度は切り離せるけど、エントリー単位の情報は共有する必要がある）
- 悪いところ
- ほとんど使われていない。
- これも特にセキュリティはないな。利用例が少ないからターゲットになっていないだけだろう。
- 情報量が少ない（URL情報しか持っていない）。
- いいところ
ちなみにpingbackは2、3年前に調べて以来全然見ていないから、現行仕様では何か変わっているのかもしれない（けど、きっと変わってないと思う）。
とか書いていて思ったけど、trackbackはWindowsライクな仕様（リッチだけど穴を塞ぐのが難しい設計）で、pingbackはUNIXライク（シンプルなツールを、外部と（パイプで）つないで使いこなしてね）な仕様、なんてイメージが重なるな。
現行trackbackの利点って、すでにデファクトスタンダード化しているところだけって気もするし、いろいろ問題点を解消しようとした結果、現行仕様と互換性がなくなったりするようならば、何もtrackbackにこだわる必要はないよなー、とは思う。
っつーか今更URLをキーにつながるなんてチープなことは考えずに、みんなHyper Estraierの全文検索機能を持って、P2P連携を使って全文検索でつながっちゃったほうが話が早いじゃん、ってのはどうだろう。まあP2P連携もそんなに大量のノードはつなげられないだろうから（ってHyper EstraierのP2P連携機能は使ったことないけど）、動的ノード解決の仕組みを考える必要があるかな。
ってなんだかずいぶん話が発散したな。
1470.netリニューアル計画
長々やってきたストレスの溜まる仕事が一区切りついたんで、1470.netの全面リニューアル計画に着手することにした。ひとまず周辺ライブラリを地味にそろえて実験しながら、方向性を固めていこう。