トップ 最新 追記

2007-03-02 [長年日記]

_ リアルタイム性と記録性、閲覧性、検索性の間

ITmedia Biz.ID:“社内IRC”を駆使するエンジニアの仕事術とは――モバイルファクトリー・松野徳大さん

こ、こんな若かったのか…。というのは置いといて。

irc + bot + plagger っつーのは確かにいいかもしんない。IP messenger のフォルダ添付もかなり便利で、(ファイルサーバを経由しちゃうとどこ行ったか訳分からなくなったりするような)こまいデータをリアルタイムにやりとりするにはものすごく重宝するんだけど、こういう応用はできないんだよな。

実は内部向け irc は一度試そうと思ったことがあって、というのは前から言ってるように Classic Mac も混ざっているネットワーク上ではまともなメッセンジャーソリューションてないわけ*1。じゃあ irc かなぁと思って実験してたんだけど、そのときは「(確か試した Classic 用のクライアントが)DCC send でファイルを送ろうとすると死ぬほど遅い」ということで断念したような気がする*2。文字だけなら IP messenger でもカバーできてるしってことで*3。ただこういう全体のシステムと同期させるってのは考えてなかったなぁ。

確かに以前にやりとりした情報を閲覧するとか検索するってことになると、Web ベースの方がなんとなくしっくりきたりする*4。でも入力の段階では Web ベースってのはちょっとだるい。専用のインターフェイスがあったりするのも意外と面倒。URL を特定するのが面倒だったりね*5。irc と連携させちゃうことで両方を一気に解決するってのはかなり面白い。irc bot って漠然とは興味持ってたんだけど、こうなると俄然面白そうだ。

ただこの irc ベースって、人数に制限があるような気がするんだよな…。100人、200人の体制で irc ってのはかなり無理があるような。channel 分けできる分、IP Messenger で行くよりは現実的だけど、例えば一時的に別な部署と情報を共有したいとかって要求になるとちょっと難しくなってくる。複数の channel に手動で入る操作って結構面倒くさいんだよな。起動して自動で入るようになってるだけなら簡単でいいんだけど。あ、それも bot 任せにすればいいのか。自分で手で channel に入らなくても bot が全体の情報を扱うシステムに転送して、そこから例えば複数の channel に bot が broadcast なんてこともできるのか。おぉすげぇ。妄想だけならどんどんシステムが膨らんでいくわ。

Tags: Net Tool

*1 Classic Mac を捨てろという正論はとりあえず置いておく。

*2 DCC なんだからサーバの問題じゃないよねぇ?

*3 ログは各自の判断で残すこともできるし、検索とかはお任せってことで。ま、たぶんそんな機能があるってことを知ってる人はほとんどいないだろうけど。

*4 これは最近 RSS リーダーべったりになっちゃったからかもしんないし、データの取り込みさえできればインターフェイスはみんな同じにできそうっていうのがもう見えてるからだな。

*5 Widget とか bookmarklet にすればいいのかもしんないけど。


2007-03-05 [長年日記]

_ 近江町市場を壊し始めたらしい

話には聞いていたけども武蔵の再開発で近江町市場を壊し始めたらしい。すでに仮店舗での営業をしている店が結構出てたけど、いよいよかと。

近江町市場は将来的には地上5階、地下1階のビルに収まっちゃうそうな。なんだか風情がないねぇ。

ということはあれか、今年の夏があの氷の見納めか。撮っておいた方がいいかな?

Tags: 日々

_ 思い立って simple delegator もどきを書き始める

PHP で、なんつーか、filter 構造のオブジェクトが欲しくなり、自分の持っていないメソッドがあったら委譲先に丸投げする*1という潔いクラスを作って、Ruby のマニュアルで見かけたことのある simple delegator という名前をそのまま拝借して付けてみた。

その後、実際にメソッドが定義されているオブジェクトのリファレンスを返すメソッドと、定義されているメソッドを移譲先のオブジェクトごとに一覧してくれるメソッドを追加しておしまい。*2

たったこれだけなんだけど自分が思っていた以上に便利だ。

こいつをさらに wrap して今度は手で通常の委譲をしてやると、中ではどこで定義されているかによらずにメソッドを自由に呼べて、外からは限られたメソッドしか呼べないというオブジェクトができあがる。

もしかして PHP 5 ではこんなの普通ですか? まぁいいや。

Tags: PHP

*1 PHP には method_missing なんて便利なものはないので、移譲先を含めてどうにかメソッドを呼び出してくれというメソッドを定義しないといけない。今回はこれを _call() と名付けた。なにかとかぶっていそうだけどとりあえず無視。

*2 実際には自作のベースオブジェクトの機能を使って呼び出しに失敗した際のエラーを格納するとか、そういう機能もついてるけど。

本日のツッコミ(全1件) [ツッコミを入れる]

_ showchan [うっそんー。 つうかビルって。あれビルに入ったらなんかこう... においとかこもってすごくいやーんな感じになりそうな..]


2007-03-09 [長年日記]

_ JavaScript で Safari 1.3 除け

※ Safari と書く際にバージョン番号を抜いちゃう人は IE 5, 5.5, 6 が混在していた時期や Netscape 4 と 6 が混在していた時期のいやらしさ、あるいは WinIE と MacIE の信じられない挙動の違いなどを知らない幸せな人か、または忘れちゃった幸せな人に違いないと自分は思っている。省略するな! 全然ベツモノなんだよ! お前は IE 6 と 7 の違いも無視すんのか!?

えー今回は Safari 1.3 のお話。

JavaScript を書く際に window.onload にあれこれ処理をつけていくのはよくある話だと思うのですが、この onload event、中を覗いてみたことありますか?

いやね、あたしゃ知らなかったんですよ。

Safari 1.3 と WinIE*1 では onload event の中に event の発生した target(IE では srcElement)が存在しない

んです。な、なんだってー。

じゃあお前どこでそのイベント拾ってきやがったんだ。言ってみろコノヤロー。子どものお使いじゃねーんだぞ、ちゃんと報告しなさいよ、報告を。このアメ玉誰にもらったの? 知らない人? 知らない人から食べ物もらっちゃダメって言ってるでしょ!

えー。

コトの起こりは Safari 1.3 の event がイベントハンドラをセットしたオブジェクトとなんかちょっと違うオブジェクトを抱えて持ってくるという、お前はなんのコントだ状態の変なバグに遭遇したことでした*2

悩んだ末、いっそ Safari 1.3 は無視しちまおうと思って*3 event をあれこれ調べてるうちに onload event はもっとはっきり変だよ! やった! この段階で無視できるよ! と思って trap を設置したら隣で WinIE が引っかかったよorz

お前もか!

ってね。しょうがないんで target を持ってなくても WinIE 独自のプロパティを持ってたら ok を出すことにして解決とあいなりました。

( evt.target || evt.srcElement || evt.boundElements )

だったかな。なんかこんな感じです。確認したい人は適当に補完してやってみてください。と言っても Safari 1.3 が手元にないと確認できないので多くの人には意味のない情報ですけど。

ところで、WinIE はなぜ window.onload イベントで window.scroll が効かないのでしょうか。不思議ですね。ごきげんよう。

*1 6, 7 で確認

*2 イベントハンドラの書き方によっても挙動は違うのかもしれないけど、今回はそこまで深く追求していない。

*3 当然 JavaScript を切ってもユーザーは困らないようになってますよ。


2007-03-13 [長年日記]

_ 独自実装の部分は断って書いてくれないと勘違いしかねないよ

【コラム】そろそろきっちりJavaScript 第2回 無名関数についてもう少し考える (MYCOMジャーナル)

せっかく最近の事情を反映してきっちり保全されそうで、まとまりがあって日本語で書かれている JavaScript の記事が Web 上にできるのかと思っていたんだけど、ミスなのか気づいてないのか、

/* dollar関数 .. $() は document.getElementById() の別名として利用できる */
/* 引数は配列でも受け取れる。多用されるため、覚えておいて損は無い */
>>> document.write('<h1 id=\'myHeader\'>Hello!</h1>');
>>> $('myHeader').style.color='red';
"red"

なんてことをサンプルとして書いちゃってる。

これは困る。

純真な子*1は $() がどこでも使えると思っちゃうでしょ。これはこの場合は Firebug の独自実装なので他の環境では使えない。あるいは有名どころのフレームワークを調査してこれこれでは使える、って書いてくれるなら親切だけど、それはクレクレ言いすぎかな。

とにかくこの連載では Firebug で動作確認していくってのはまぁ一応断りがあるんだけど、サンプルのコードが Firebug 依存なのかどうかくらいは明確にしておいてほしいな。この記事のターゲットは当然バリバリの JavaScript 使いじゃないわけだから。

あと細かいけど

さて、JavaScriptでのオブジェクトはJSON(JavaScript Object Notation)という表記法によって表現することができる。

なんか卵が鶏を生んでるような。

うーん。

で、今頃気づいたけど、MYCOM のコラムにはトラックバックできないのね。

*1 そりゃ含む意味もあるさ

_ News って内向けに使えるかも

スラッシュドット ジャパン|京都大学のネットニュースサービスが3月を持って終了

を見かけて思いついたこと。

  • 一斉に配信可能
    • っていうか、購読させる必要があって配信とは言わないけど
  • サーバ側でネタごとに分類可能
    • 個々人のスキルに依存するメールのフォルダ分けよりも絶対に確実

っていうのは、こまごましたメールアドレスの管理をしなくてよく、参加者のスキルに依存しない分、内部向けでメーリングリスト代わりに気軽に使うのに向いている仕組みじゃなかろうか。コントロールメール投げなくてもアーカイブもそのまま共有できるし、人の出入りに強そう。

ただし、リモートからアクセスする必要があるケースはちょっと考えなきゃいけないのと、添付ファイルに相当するのは今でも uuencode なのかな?ってのが気になるかな。

あと特定の人たち”だけ”に配信したいという要求には応えられないので、そういう用途には使えないな。(もしかして認証掛けることで可能?)基本、オープンでいきましょうよという身軽な組織なら結構使えそうな気がする。News Reader 機能付きのメールソフトも多いし、プロジェクトごとにカテゴリを作っていけばなかなかいい感じにならないだろうか。例えば Trac が News と連動できたら面白くない?

Tags: News Net

2007-03-14 [長年日記]

_ 立ち上げたタイミングによって速度が変わるとか

Linuxを入れて起動するとペンギンが80匹並ぶのですか!

PS3で8匹並ぶと書かれたページを読んだので。Yellow Dog Linux for PS3だと違うらしいですが。

王冠をかぶった10体のキングペンギンが現れるようにしたい。

Re:今度はコア数競争?(Intelからサーバー向け省電力版クアッドコアプロセッサ発表 /.-j)

ぶふぉっ。

メタルペンギンとか現れたらやだな。最初たくさん出てくるけどどんどん消えてコア数は最終的にだいたい 1 か 0 とか。そんなときは諦めて再起動しろってか。(ゼロになっても再起動ってできるの?)


2007-03-18 [長年日記]

_ Markdown と Textile になんとなく感じたこと

Textile は最初見たとき「なんじゃこりゃ HTML の再発明じゃないか」と思ったが、実際に Markdown で Web ページを書き始めると

  • ID が指定できない
  • ブロック要素を定義できない

など、不便な点がいろいろ出てくる。細かな属性を書きたいわけではないが、div が書けて ID が指定できるくらいの機能がないとさすがに Web ページ全体(サイト全体にあらず)を記述するには力不足を感じる。日記のエントリくらいなら heading が 3つくらい使えればいいけど、ある程度の長さになると意味のある id を付与して URL としても意味を持たせたいし、意味の構造ごとに div で囲めると、デザインのコントロールなどの効果を後から足すことができて嬉しかったりする。

じゃあ Texile かというと、やっぱどーも HTML のまんまな感じがして、例えば普通の人にこれを使ってコンテンツを作ってくれとはさすがに言えない気がする。Markdown くらいならなんとかなると思うけど。バランス的には RedCloth [Textile Humane Web Text for Ruby] は結構好きかも。

======

------

で見出しを書きつつ、

| セル | セル |
| セル | セル |

でテーブルを書けるのはなかなかいい感じ。

ちなみに WYSIWYG で HTML を直接編集させた方がよいという考えもあるかもしれないけど、デザイン的な統一感を維持しつつ、コンテンツの更新コストだけを下げようと思ったときにその方法はあんまり採用したくない。各自が自由気ままに書くためには WYSIWYG の方がいいかもしれないけど、コンテンツを更新しなければいけないというルールが存在する場合は、シンプルで守りやすい制約を与えた方が結果として良い方向に働くことは多いし、コンバータを介してコンテンツを生成した方が HTML は壊れにくい。

話がそれた。

まーとにかくこれらのフォーマットに何らかの不足を感じる人はやはり居るらしく、すでに Markdown にも Textile にもあれこれ拡張バージョンが存在している。特に My Wandering Wiki: MultiMarkdown なんてのはあーやっぱりこういうの欲しくなるよね、と思ってしまった。何がってメタデータを含めることができると、生の Markdown ファイルをデータとしてそのまま利用しながら CMS としてメタデータを活用できるんで、例えば表示期間の制御とか認証関係とか作り込みやすくなるから。まぁ自分がやるなら Markdown 側からは無視される領域ってのを作ってやるだけにしておくと思うけど。そうしたらフォーマッタとメタデータを利用する CMS の部分を分離しやすくなるんで。CMS の側がヘッダを削除してから Markdown に渡す、でもいいんだけど。どっちにしろ Markdown そのものを拡張しちゃうとちょっといじりにくくなるんじゃないかなーと思ったりしている。実際にアプリ書いてないから外れてるかもしんないけど。

今のところの結論としては、自分が使うなら RedCloth、サイトやページの一部をなんにも知らない人が更新するために使うなら Markdown がいいかな。

あと面白いと思ったのは Pandoc. Haskell ってところがネックになるかもしれないけど、Markdown で書いて S5 スライドに変換できるのは便利そげ。まぁ実際にはプレゼンの機会なんて今はもう全然ないんだけど、S5 スライドがサクっと作れるとネタ作りとかにも便利そう。というか S5 いいなーと思いつつ HTML 直書きはもう勘弁と思っていたからこれいいかな、というのが本音。

なんか、「まぁ」が多いよね。まぁいっか。


2007-03-20 [長年日記]

_ エンコーディングが混ざっていても化けない diff

こんな感じ。

for i in `svn status | awk '$1 == "M" {print $NF}'`;
do svn diff $i | nkf ;
done | less

これは動作確認済み。

それかこんな感じ。

for i in `svn diff | awk '/^Index: / {print $2}'`;
do svn diff $i | nkf;
done | less

これはちゃんと確認してない。

というのも、上のものは最初から working copy に存在するファイル、ディレクトリしか処理対象にできないが、下の方法だと diff に -r を与えることで任意のタイミングの diff が取れる。でも本当に存在しないファイルやディレクトリに対して diff が取れるかどうかは確かめてないのです。

なんでこんなことしてるかというと、Trac 上でなぜか diff の見れない changset があるんだよね。たぶん Trac のバージョンが古いからなんだけど、上げる段取り(いろいろあるの)が面倒なので、手元で回避しちゃうのであった。

本日のツッコミ(全1件) [ツッコミを入れる]

_ TrackBack [http://aligach.net/diary/20070518.html#p01 あーありがち Debian 4..]


2007-03-21 [長年日記]

_ バッカスというと Bacchus を思い出しちゃう人間ですが

スラッシュドット ジャパン|FORTRAN言語の生みの親、J・バッカスさん死去

そう言えば FORTRAN 77 を触る前後が転機だったような気がするなぁ。あんまりいい思い出のない言語だ。

FORTRAN 77 に実際に触る前には FORTRAN から IF 文のブロック構文なんかを拝借した「構造化 N88-BASIC(86)*1」なんてのにハマったりしていて、割といいイメージを持っていたんだけど、実際触ったら BASIC 以上に扱いにくくてとても困った気がする。あーでも行列の扱いが楽でビビったような気がするな。あれ、行列が楽になったのは Fortran90 ? もう忘れたな。

TSS(Time Sharing System) でラインエディタで課題を提出させられ泣きそうになり*2、その後道を踏み外して写真撮りまくったり飲んだくれたりしながら、一人地味に awk なんかで遊んでいた成果が今に繋がるわけだ。あそこで TSS じゃなくて Unix と戯れることができていたら、もしかしたらまた違う人生を歩んでいたかもしれないけど、たぶん今の方が人間的には勉強になってるからどっちがいいとも言えないな。そうか、そうだな。

ちなみに FORTRAN 77 で二種を取った。その頃すでに Algol はなかった。PL/I はあったけど。あんまり真面目に勉強してなくて、数学とか英語で稼いでいたんだけど今そういうの通用しないんだよね。大変だ。

あ。

BNF もこの方でしたか。ありがとうございます。合掌。

*1 QuickBasic の時代がくる前にラッセル社の PCマガジンで福嶋さんが書いていたものです! 「一夜漬け」シリーズも好きでした! 福嶋さんありがとう! ぼくは日高総帥ではなく福嶋さんのファンです。

*2 「国民機」が 486 の時代に入っていたのに


2007-03-23 [長年日記]

_ Yahoo! Widgets 4

米Yahoo!が「Widgets 4」をリリース、より軽快に動作 (MYCOMジャーナル)

まだ日本語版が出てないのは置いておくとして。

changelog がないから細かい違いがよく分からないな。SQLite とか Canvas とかの目玉じゃないやつの情報が全然わかんねー。CSS のごく一部が使えるようになったとか、そんくらいか? 何が面倒って画像作るのが激しく面倒なんだけど、そこはどうにもならないんだろうか。

まだちょっと余裕がないのでしばらくはスルーだな。

とりあえず今日は一人 code festa 終了記念で飲んじまおう。


2007-03-27 [長年日記]

_ Web API にのっかってほしいもの

  • 各携帯キャリアの proxy の IP アドレスの範囲
  • 各携帯端末の user agent とスペック

https でオフィシャルに配ってください。キャッシュ期間は適当にそっちで決めて。

そしたらわざわざ人間が、更新しましたよー、サーバの設定確認してくださーいとか広報したり確認したり手間ひま掛ける必要なくなるじゃん。

キャッシュがないとおびただしいアクセスが発射されると思うので、必ずクライアントサイドにキャッシュして使え、守らないと弾いちゃうよんという仕様にしておく。

流れで。

各種ロボットの情報も全部 API で取れるようになればいいのにね。そんでロボットが通知してくる URL には API のリファレンスがあるの。てゆーかロボット用の API くらい共通になってればいいのか*1。そしたらロボットのアクセスを検知 → 自動的に API に確認に行く → ポリシーに反しているので除外とか楽にできねーだろうか。少なくともまっとうなロボットが API にのっかってお互いに楽しましょうよ的な紳士協定のもとで動いてくれれば、守らないやつは即排除という流れにしやすくていいんじゃなかろうか。

無理か。無理だよなぁ。誰がおいしいのかよく分からないものね。

携帯の方は少なくとも携帯サイト開発者はみんな欲しいと思うけど。

Tags: Web

*1 どの IP からアクセスするとかクローラなら周期とか。IP アドレスの範囲はどの記述方法が可能かによってサーチコストが変わってくるけど。


2007-03-28 [長年日記]

_ screen + Emacs 環境でたまに起きること

screen の key bind で何かをしようとしかけて、ふと思い立ってキャンセルのつもりで C-g を叩いて bell が visual に切り替わってしまい、それに気づかずに本当に Emacs 上でキャンセルのために C-g を叩くと画面が一瞬ド派手に反転してビビること。

あるんだって。たまに。今なったもん。


2007-03-29 [長年日記]

_ 全角半角チェックの問題

なんか textfile.org でも取り上げられてたので便乗して。

人力検索はてな - 住所欄の番地はなぜ全角? ネットで買い物をしていて、住所を入力したら「住所欄には全角しか使えません」とエラーがでて腹がたったことありませんか? 僕はもう「数字=半..

個人的には

  1. 仕様になかったから
  2. 利用しているフレームワークや開発環境では標準でそういう機能が盛り込まれていないから
  3. よそのサイトのマネしたから

のどれか、あるいは全部がこういう腐ったフォームの蔓延の原因だと思う。

1 についてはそもそも Web に向いていない開発会社が受注しているというか向いていないマネージャーが指揮しているケースが多そう*1とか、開発会社とサービス提供会社のどちらかあるいは両方がちゃんと顧客のことを考えていないとか、そういうネガティブな連想を加速させてしまうが、書き始めると長いのでやめる。

で、実は 2 との合わせ技が多いんじゃねーかなぁと踏んでいる。要するにフォームのバリデーションのコンポーネントに変換フィルタをかます処理が標準の機能だけでは書けない、あるいは書きにくい構造になっている。そして面倒くさいから対応しない。

保存したデータを印刷に利用するだのオフコン系、メインフレーム系のシステムと繋ぐがどうの、っていうのはそういうケースもあるかもしれないけど、むしろそういうケースしか想定していないツール(と頭)を使って開発している、という状態が正解に近いような気がする。

ここまでは基本的に融通の効かない開発会社のことを想定しているんだけど、3 は恐らく力のない SOHO 系に多いんじゃないかと踏んでいる。

いずれにしても結構ひどいことを書いてしまったなぁ。そして自分で書いておいてなんだか暗い気分になっちゃった。いかんいかん。

Tags: Web

*1 臆面もなく上流とか下流とかいう言葉が出てきちゃう人は Web には、少なくとも B2C には向いていないと思うな。例えばこの手の動作はマニュアルを整備して運用、という方法でもクローズドなシステムでは問題にならない。むしろチェックが厳格でマニュアルが整備されている方が業務的には安心だし、「手数勝負のテスト」をしている場合にはその方が圧倒的に楽。でも B2C サイトは一見さんを大事にしなきゃいけないんだから、そんな発想じゃダメだと思うんだよなぁ。


2007-03-30 [長年日記]

_ NeoOffice 2.1 が出た!

まだニュース見かけないからとりあえずそんだけ。

今から落とす。

Tags: OSX

2007-03-31 [長年日記]

_ W3拡張ログファイルフォーマットの応用を夢想

Web サーバの生ログではなく、独自に欲しい情報だけをログに落として集計に活用すると嬉しいんじゃないかと思った。つかほんとに思いついたのはずいぶん前なんだけど。

ということでまた「一部で当たり前のノウハウなんだろうけど、あんまり見かけることないから書いてしまえメソッド」発動。ちなみに今回の思いつきにおいて「DB に落とせば?」というのは却下とする。書き込みのオーバーヘッドがでかいし、追跡したい情報の変更に柔軟に対応するのが難しくなるし、データが巨大になりすぎた場合の対応も考えるのが面倒だから。ログなら適当に rotate してやるだけでいいし、どうしてもやりたくなったら必要な範囲のログを DB に突っ込んでじっくり解析すりゃいい。

話がそれた。

調べると W3拡張ログファイルフォーマット (W3C Working Draft WD-logfile-960323) というものがあるのでこれを利用するのがよさそうだ。でも基本的に HTTP のことしか考えてないので 1リクエスト:1リソース を記録するもので、複合的な意味を含めることができないように見える。(いやまぁログって普通そうなんでしょうけど。)

記録したい内容にもよるけど、考えられるケースは

  • POST メソッドで複合的な内容を送らせているのでこれをトレースできるようにしたい
  • トレースはしたいが session 管理はしていないし、する意思もない

なんて辺りかなぁ。というか今回個人的には

  • quesy string に埋まっちゃってるパラメータを、生ログ相手に面倒な文字列処理をせずに解析できたら楽じゃね?

というのが主目的だったりする。レベル低くてごめんなさい。

query string の問題は、パラメータの順番が不定なところ。これをそのまま生ログ解析しちゃうと、「実際にはまったく同じリソースにアクセスしているにも関わらず文字列としての URL は一致しない」ので、集計の際に文字列処理をかますなどの面倒な作業が必要になってしまう。

まともな解析ツール入れろ?だからレベル低くてごめんなさいって言ってるの。

で、思いついたのがリソースをユーザーに返す際にログに落とせばいいじゃんて話。しかしさっき書いたようにこのフォーマットは 1リソースに対するリクエストの記録を取るのが目的なので、例えばこれとこれとこのオプションを選びました、みたいな情報は残せない。

と。思ったけど。

uri-stem や uri-query を勝手に組み立てればいいんだ

ということに気づいた。別に今回のログは Web 上に公開されているリソースにどういうアクセスがあったかの情報がほしいわけじゃなくて、内部的にどういう情報が取得されたかを記録できればいいんだから、URI をオレルールで組んじゃえばいいんだよね。なるほどなるほど。オレルールじゃなくても query string の順番の揺れを補正するだけでも結構違いそう。

というかそういうことなら W3拡張ログファイルフォーマットかどうかって、実はあんまり関係ないんだな。別に common log でもいいんだ。ただ uri-stem と uri-query を別々に記録できるのは便利かも。URI として活用できるフィールド、つまりリソースの識別に利用できるフィールドが 2つあるわけだから、より細かく情報を残しやすい。また、対ユーザーという意味ではセッション管理してなくても、ユーザーからのリクエストに対してなんらかのセッション識別文字列を Session Identification URI をもとに付加して複数の情報をベッて吐いて解析時に取り出しやすくするってのも可能だな。

他にも自分でログを吐けば、mod_rewrite なんかで HTTP で公開する URI はサーチエンジン向けにきれいにしつつ、裏で落とすログの URI に細かい情報を載せる、なんてことができるわけだ*1。なかなかいいかも。あとは細かい情報を載せた URI を手軽に生成する方法とそれをログに簡単に落とす方法があればよい、ということですな。(すべて DBMS に入っているなら DBMS のログを解析するんでもいいのかもしれないけど。)

Tags: Sysadmin

*1 rewrite_log でもそういうことできたっけ?