_ いまだ体調は回復せず

いまだ体調は回復せず。薬の効いているときと効いていないときの落差が激しい。でも今日は買い物に行かないとなー。

_ フリーの編集者？

この天然さん（http://masao2002.tdiary.net/20021201.html）はいったい何ものなんだろう？　フリーの編集者っぽい記述が見受けられるけど、この対人スキルのひどさで編集なんて出来るのか？　それにしてもさいたまー！病院（http://www.aiseikai.or.jp/）を彷彿とさせるホームページ（http://www.masao-k.net/）だ。

_ いつまで経っても治らない

頭痛とだるさが全然取れないので今日は休み。この体調不良いつまで経っても治らないな。普通に安静に暖かくして熟睡して、大汗をかいてすっきり快癒したと思っても、ちょっと涼しいと感じるとすぐに元の木阿弥になる。なんか風邪とかではなく根本的な体調不良のような気がしてきた。といいつつ病院には行っていないんだけど。派手な症状がないとどうも病院に行く気がしないんだよなー。

_ TrackBackを実装する 2

TrackBackを実装するの続きを考えてみる。

情報を受け取るインターフェースと情報を受け渡すインターフェースは、その実装（管理）責任者が異なるため、分けて考えた方がいいだろう。同じシステム同士でのやりとりならば統一して考えることが出来るが、ひとまずはシステムに縛られない汎用的なインターフェースとして考えてみる。

情報を受け取るインターフェースというのは、

• 他のサイトやクライアントツールからのTrackBack通知を受信する

のが目的。

自システムの「どの記事（記事ID）」に対して、「どのような反応（外部サイトのURL、コメント本文、反応者情報（名前、メールアドレス、url））」を受けたかを受信し、記録する。具体的な処理に関しては、受信処理と記録処理の2段階に分けて考えた方がいいだろう。さまざまな拡張情報を受信しうるが、そのすべてを記録するとは限らないし、受け取った情報にシステムでさらに独自情報を付加して記録することもありうる。

情報を受け渡すインターフェースというのは、

• TrackBack通知を発信する
• TrackBackされる情報元として、情報ソース（引用文）を発信する

という2パターンがありそう。

後者はTrackBack関連のインターフェースというよりは、RSSとか2chのdat直読みみたいな、コンテンツのrawデータ（通常のWebブラウザ向けではないコンピュータ同士の通信用フォーマット）を受け渡す仕組みみたいなものなんで、そっち方面の機能として考えた方がいいのかもしれない。具体的な機能としては、あるURL（外部サイトの特定の記事を差す）を指定すると、自動的（ネットワーク経由で）にその本文を取り込んで、その記事を引用したコメントを記述するフォームが表示される、といったイメージ。もちろんその他TrackBack通知に必要な情報も自動的に取り込む。

そして前者がTrackBackの基本となる通知側の仕組み。いまいち把握し切れていないけれども、Movable Typeでは他のサイトへのTrackBack通知を送る仕組みは、あんまり洗練されたものが用意されていない気配。それはちょっといまいち。出来ればある記事urlを指定して「この記事にTrackBack通知する」みたいなコマンドを発行すると、付加情報を入力するフォームが表示されて、それをPOSTすると自動的にTrackBack通知が行われるみたいな感じになっているといいな。

もちろん上記みたいな流れはTrackBack通知専用のフォームという訳ではなく、自サイトのシステムで他のサイトの記事への反応記事を書くときに、反応元URLとしてTrackBack対応サイトのurlを書いておくと、そのurl文字列から自動的にTrackBackインターフェースの有無の問い合わせを行い、もしもTrackBackインターフェースが用意されていたら、自サイトの記事としての投稿処理を行う裏タスクで、反応元サイトへのTrackBack通知も行われる感じ。

現在のWikiLikeでは反応元を明示したblockquoteは使えないけれど、hnf互換コマンドを実装した場合は、たとえば、

CITE http://somedomain.com/somepath/?id=123 引用元名称
引用文引用文引用文引用文引用文引用文引用文
/CITE
コメント本文コメント本文コメント本文コメント本文コメント本文コメント本文

みたいな記事をPOSTしたら、somedomain.com/somepath/に対してTrackBackインターフェースの存在確認を行い、もしも存在したらそのTrackBack受信インターフェースに対して、http://somedomain.com/somepath/trackback.cgi?id=123;author=someont;url=someurl;comment=somecomment;みたいな通知が自動的に行われる（という仕様には具体的にはいろいろ穴があるので要検討）。

データに関しては、最初は気軽にGET、POSTして引数渡しするのが手軽かなーと思っていたんだけど、本当に汎用インターフェースとして考えた場合に、日本語文字コードの問題とかが結構ややこしいことになりそうだ。Googleみたいにie=***;oe=***で文字コードを指定する手軽な実装方法もあるだろうけど、ここは逆にxmlで文字コード宣言をちゃんと行って、受信側が文字コードを適切に解釈すべしとしておいた方が、逆にあとあと面倒が少ないのかも。

_ コンテンツの分散管理 (13:48)

Web日記サービスみたいなもので、集中サーバーでデータの管理をしつつ、そのコンテンツの配信は各ユーザーがそれぞれアカウントをもつ個人サーバー領域で行う、って形式には需要があるのかなー。

たとえばtDiary.netみたいなところでは、コンテンツの管理から配信まで全部サービスしてくれるけれども、コンテンツの管理自体はtDiary.netでやりつつも、その最新日記ページおよび過去ログページについては、ftp経由で各ユーザーの個人サーバー領域に（差分）アップロードして、一般閲覧者はそっちを見るという形にしてしまうパターン。

メリット、デメリットを並べてみると、

• メリット
  • サービスを提供するサーバーの負荷が大幅に低減できる
  • サービスが終了してもユーザーには自分の管理サーバーに過去ログhtmlデータが残る
  • 自分のページのurlを自分で選べる（日記ページだけ別サーバーとかならなくて済む）
• デメリット
  • ユーザーのftpアカウントの管理を行うというセキュリティ的なリスクを管理者が負わなければならない
  • 自動ftp関連の設定がちょっと（一般ユーザーには）難しいかも

ちょっと考えてみる価値があるサービス形態なのかも。特にASP（アプリケーションサービスプロバイダーの方ね）とかで商売をやる際に、こういうやり方でいけるものも結構ありそうだな。

_ 小便排出

飲みたくなくても無理矢理水分をたくさん取って小便として排出していたら、なんだかずいぶん調子が良くなってきたかも。汗をかくだけじゃ足りないのかな。

_ 2003年F1エントリーリスト発表

• Arrows refused entry! Into the 2003 season - http://f1.racing-live.com/en/headlines/news/detail/021202113540.shtml

あらアロウズは申込みはしたけど、FIA側から断られてしまったのね。というのはまあどうでもよくって、ジョーダンのセカンドドライバーはまだTBA（to be announced：後日発表）なのね。佐藤琢磨はちょっとキビシイかもなー。スポンサー集めに走り回るようなタイプにはあんまり見えないし、いまどきの日本企業はF1スポンサー候補としてはいまいちだし。

_ 長座席の利用効率

いまだ体調は回復せず。でもこれ以上寝ていてもしょうがない気がしてきたんで、午後から出社。ケツが決まっている（すでに一回延長している）仕事なんで、それだけでも終わらせておかないと。で、埼京線に乗ったら快速は臨海線車両に変わっていた。長座席を3人：4人に分けるバーがついたんで、長座席の利用効率が多少向上するかな？　で、渋谷まで電車に揺られてきたらとても具合が悪くなった。頭痛が痛い。今日はちょっとだけ作業をしたら帰ろう。

_ 健康食品と風邪薬と健康ドリンク

健康食品と風邪薬と健康ドリンクとを体内に注入したら、一気に体感体温が上がったよ。漫画的に言うと私の背後にオーラが燃え上がっている感じ。でも頭痛が引かないのは何故？

_ Rotisserie

• “便所の落書き”から抜け出すには 〜有意義な議論を行なうための掲示板ツール - http://www.watch.impress.co.jp/internet/www/article/2002/1203/hbc.htm

基本的には既存技術の組み合わせって感じだな。良くできた（？）スラドというか。ただ、 >投稿を公開する“タイミング”を制御する って部分にオリジナリティがある。確かに時系列で表示されるシステムの場合、投稿する（表示される）タイミングってのはかなり重要な要素になるんで、それを制御しようという着眼点はいい。

ただ、このシステムは基本的に、あまり参加者が多くなく、かつ参加者の粒がそれなりにそろっていることを前提に作られたシステムのようにみえる。学校とか企業とかで使われる分にはそれで十分かもしれないけど、雑多な参加者が使ってもうまくいくような方向に発展するといいな。

_ 乙一のホームページ

作家がこんな風にそこらへんの学生とかが思いつきではじめたようなホームページを開設するのもいいね。どこまで狙っていてどこまで天然なのか読みにくいあたりも、乙一っぽい。

• http://www.geocities.co.jp/Bookend-Yasunari/3259/

_ 毎日毎日体調が悪い体調が悪い

いまだに体調は回復しませんのことよ。って、毎日毎日体調が悪い体調が悪いしか書くことがないのか、おのれは！　と言っても、これだけ体調が悪いとそれが生活のほとんどだしね。昨日は結局健康ドリンク3本費やしても5時間しか働けなかったし。今日の主症状は頭が相変わらず痛くて、粘っこい鼻水が鼻の奥にまとわりついていて、思わずすすってしまうと喉の奥に鼻水の感触が広がって、ゲロ吐きそうになる感じ。気を抜いて咳き込むと大量の痰が吐き出されるし。

_ WikiLikeの最終目標

WikiLikeの最終目標（http://ishinao.mine.nu/WikiLikeDev/?query=WikiLike%A4%CE%BA%C7%BD%AA%CC%DC%C9%B8）とか考えているうちに、このまま新しい日記システムだってことにしちゃう手もあるかもなーと思ったり。「Wikiだ」というよりも「日記システムだよ」といった方が世の中通りがいいかも。あるいは「blogシステムだよ」の方がいいかな？ といった方向から発展させたシステムの妄想。ユーザーを軸にした検索機能を強化する。そして、いろんな人が好き勝手に記事を投稿していったものを、「ある人の日記」という軸で見たいときにはその作成者名で検索して表示する。キーワードのリンク先としては、同じ作成者が書いた記事を最優先で表示しつつ、他の人が書いた記事も関連検索結果として並べる。コミュニケーション志向の日記のような関心空間のようなWikiのような、微妙なものになりそうだ。キーワードに他の人の書いた記事タイトルを入れておけば、その記事を検索したときに自動的に関連検索結果に含まれるようになるし。

_ TrackBackとRefererを同じ枠で取り扱う方法

TrackBackとRefererを同じ枠で取り扱う方法。

Refererには以下のようなパターンがある。

• トップページのurlへ
  • そのサイト自体へのリンクという意味
  • そのトップページ記事へのリンクという意味
  • 過去のある時期に、トップページに書かれていた内容へのリンクという意味
• 一覧ページのurlへ
  • 一覧ページという概念（最新10件、など）へのリンク
  • 過去のある時期に、一覧ページに書かれていた内容へのリンク
  • そのサイト自体へのリンクという意味
• 個別記事のurl
  • その記事自体への言及リンク
• その他全体に関して
  • 検索エンジン経由のもの
    • 検索キーワードが特定できた場合
    • 検索キーワードが特定できなかった場合
  • 誤爆Referer
  • 偽造Referer
  • リンク張り間違え

個別記事へのリンクに関しては、多くの場合TrackBack的なものと扱っても構わないはずだ。ただし、TrackBackとは違って相手の記事url（＝Referer）は相手にとっての固定記事urlとは限らない（いずれその記事は該当のurlに存在しなくなる可能性がある）。

最新n件表示するページなどへのリンクに関しては、そのときそのページに記載されていたある記事へのTrackBack的なものが含まれる可能性がある。ただし、その確率がどの程度か見積もるのは非常に難しいし、複数記事中のどの記事に対するTrackBackなのかを判別することも非常に難しい。

というあたりを考えつつ、明示的なTrackBackとRefererをうまく同じ枠で取り扱う方法を考え出そう。

_ 偽造Referer

Refererとは、本来あるurlのWebページに記述されたリンクから別のurlへと移動したときに、移動先のサーバーに移動元のurlを通知するための仕組みだ。しかし、Refererを通知するのはWebブラウザの処理であるので、ブラウザ側でその内容を偽造することも出来る。たとえばダウンロードツールなどは標準でRefererを偽造する仕組みをもっているものが多い。

_ TouchGraph GoogleBrowser

Googleの関連url検索（related:****）を使って、あるurlに関連するurl群を視覚化して見せてくれるツール。

• TouchGraph GoogleBrowser V1.00 - http://www.touchgraph.com/TGGoogleBrowser.html

このTouchGraph（おお、WikiNameだ！）ってのはオープンソースで開発されているものらしい。いろいろ遊びのネタに使えそうな気配。WikiBrowserみたいなものを各Wikiシステムがそれぞれ自前で用意していたりすると面白いだろうなー。現在WikiLikeで実装しているキーワード検索の結果画面みたいなものを、文字ではなくグラフで表示しちゃったりなんかして。

_ Bフレッツ

会社のメイン回線がBフレッツに変わった。今までのSDSL（1.5M）でも特に不自由したことはなかったし、家のADSL8Mで十分速いと思っていたんで、それ以上速くなったところで大して感動はないと思って、特にダウンロードテストとかもしていなかった。けれども、サーバーのセットアップをしているときに、5Mバイトくらいのファイルをダウンロードしたら、Lynxのダウンロードステータスが一瞬も表示されずに終わってしまってちょっとびっくりした。ダウンロードが異常終了したのかと思ってファイルを見てみたら、ちゃんと正しいサイズのファイルが保存されている。ふへーと思って、今度は数十Mバイトのファイルをダウンロードしたら一瞬表示されたステータスバーに、ダウンロードアベレージとして5から始まる4桁の数字kバイト/秒という文字が見えた。――これはちょっとすごいね。もはやダウンロード処理中一服するなんてことは出来なくなったんだね。

_ NetGenesis Super OPT90の設定

今朝起きたときにはずいぶん調子が良かったのに、NetGenesis Super OPT90の設定ではまっているうちにまた具合が悪くなった。ルーター本体のアドレスの設定と、複数IPアドレス変換（WAN−LAN）設定で行うIPマスカレード変換用IPアドレスの設定とは、全然関係ないのね。ネットワーク回線の移行とDHCPサーバーの移行を、重複したIPアドレス範囲で同時にやろうとしたら、わけ分からなくなってしまった。でもこれでいつでもSDSLとはおさらばできるようになったな。さよならめたりっく。

_ OpenBlockSS

OpenBlockSSって、実行時にはディスクイメージをすべてRAMディスクに展開してから動くんだっけ。設定を書き換えても再起動したら消えちゃうんでなんでだろうと悩んでしまった。

_ OpenBlockSSでDNS

げげっ！　OpenBlockSSって単体ではネームサーバーが動かないのかよ。ハードディスク増設が必須だったとは。単体でも設定項目自体は生きているんで、マニュアル読むまで気づかなかったよ。

フラッシュメモリ増設でもいけるようないけないような。どっちの記述が正しいんだ？

• http://openlab.plathome.co.jp/OpenBlockSS/pkgs.html#pkgs
• http://openlab.plathome.co.jp/OpenBlockSS/spec.html

マニュアルではハードディスク増設はブートデバイス追加で、フラッシュメモリ増設はディスク領域追加と、別扱いになっているみたいなんだけど。

どうやらフラッシュメモリ増設でもいける模様。ところで↓の説明にあるWeb設定画面はうちのOpenBlockSSのとは全然違うよ。なんか旧機種（OpenBlockS）のWeb設定の方が多＆高機能に見えるのは気のせい？　まあWeb設定を使う気はなかったけどさ。

• http://openlab.plathome.co.jp/OpenBlockS/dns.html

_ 埼京線はよう止まるのぉ

埼京線はよう止まるのぉ。今日も昼過ぎに出かけようとしたら止まっていた。東武線経由で振り替え輸送しているという放送が流れていたが、遠回りするのはきつかったので昼飯を食いがてら復旧を待ったが、1時間経っても復旧していなかった。とかしている間にまた体調が悪くなってきたのでいったん帰宅。

ちなみに関東地方のJR線におけるトラブル状況は、

• JR東日本関東エリア列車運行情報 - http://www.jreast.co.jp/train_info/kanto.asp（※このurlはRefererチェックして外部からの直リンクを弾いている模様。トップページに飛ばされちゃうんで、そこから「列車運行情報」-「関東エリア」を選んでください）

で分かる模様。ただしこのページのシステムは腐っているっぽい。ここで表示されている更新時刻は、情報が更新された時刻ではなくて、単にページをロードした（aspを実行した）時間を返しているだけだ。更新時刻が不明なもんだから、更新履歴がほとんど意味をなしていないし。

_ 私が既存のWikiEngineを使わなかった理由

読むまで死ねるかっのPukiWiki版が仮公開されている。私ももともとこういう用途でWikiを使いたかったんだよな。情報系のコンテンツは、キーワードリンクとはとても相性がいいから、読書感想とか情報提供とかのコンテンツをWikiベースに移行すると気持ちいいだろうなーと思って。世の中にたくさんある日記系システムみたいな時系列系ではうまく扱えないからね。

でも実際にいろいろ試してみたところ、既存のWikiEngine（というかWikiの基本的な考え方）は私の使いたい用途ではうまく使えなかった（運用で回避することは出来なくもないんだけど、主用途の部分で工夫が必要なシステムは使いたくない）。しょうがないんで、自分でいろんなWikiもどきを作り始めて現在に至る、といった感じ。

ちなみに、私が既存のWikiEngineで我慢できなかったのは、キーワード＝ページ名であるという原則を曲げられないこと（名前空間とかグループとかで逃げているシステムもあるけど）。書籍情報なんかは書籍名をページ名にしたくなるけど、同じ書籍名の書籍なんていくらでもありうる。それらの情報を同じページにつっこむか、あるいはちょっとだけ名前を変えた別ページにするか、あるいはページ名自体にもっとユニーク性の高いキーワードを付属させるか（ISBNとか）、なんてことを考えはじめたらちょっといやになった。

あと、日本語系のWikiEngineは基本的に検索処理が遅そう。Namazuあたりと連携するシステムが出てくればいいけれども、普通にパターンマッチしていたんじゃ日本語ではつらい。たぶん日本語Wikiで英語と同じようにパターンマッチベースの実装をしていると、英語版よりもかなり早い段階で速度的な問題が出てくるだろう。まあその辺はそのうちNamazuと連携するとか、あるいは自前でインデックスを生成するシステムが出てくるだろうけど。

あともう一点はコンテンツ保護の問題。ユーザー認証周りを実装しているWikiEngineは少ないし、認証周りの仕組みも大仰すぎるかあるいはあまり使い勝手が良くない。まあWikiWayに則れば、Wikiには「誰でも編集可能」であることは必須なのかもしれない。でも「キーワード検索」で簡単につながるページを「手軽にWeb上で編集」できる「コンテンツ管理システム」が欲しいだけの用途で既存のWikiEngineを使おうとするとちょっと面倒くさい。

などなど私が既存のWikiを使わなかった理由を並べてみたわけだけれども、ただ私の場合は既存のWikiEngineについては、ちょっとだけ使ってみてそれから長いこと思考実験をして、それでもって使わないことに決めちゃったという経緯がある。実際に運用で回避しつつどのくらいのものができるのかは結構気になる。もしかしたら私が思考実験において出した結論の多くは、単なる杞憂である可能性もあるし。

というわけで、読むまで死ねるかっが、既存の（一般的な）WikiEngineをどこまで情報系コンテンツ管理システムとして実践的に活用できるのかとても注目している。って、実験台みたいに言ってごめんなさい。

TrackBack（嘘）

• Wikiで本の感想コンテンツを運営していくこと - http://bm.que.ne.jp/text/?200212a&to=200212071#200212071

_ WikiLike公開までの道のり

TrackBack to

• Wikiで本の感想コンテンツを運営していくこと - http://bm.que.ne.jp/text/?200212a&to=200212071#200212071

ところで いしなおさんのオリジナルの WikiLike 、できれば使ってみたい人は山ほどいると思うんですけど公開しないのですか？そしたらそっちを使いたいかも。

WikiLikeは公開できるところまでたどり着ければ公開する予定ではいます。ただ、自分の中で乗り越えなければならない課題がまだいくつもあるので、予定は未定と言った状態です。

結構致命的なレベルの課題としては、

• まだ思想（コンセプト）自体が固まっているとは言い難い（IPWikiみたいに設計途中にコンセプト自体を投げ出す可能性がある）
• このコンセプトで続けるとしても、まだ現状のデータ形式を維持し続けるかどうかわからない（気軽にバージョンアップは出来ない。私も現在の実験スペースは最悪、データを捨てる覚悟をしている）
• Wikiレンダリングエンジンとして暫定的に、IPWikiSimpleのときに作った「複数のレンダリングメソッドを簡単に切り替えることが出来る」設計のものを使っているが、これは「Wikiライクなレンダリングメソッドとhnf風のメソッドを同時に成立させつつ、今後の拡張性も高い」設計のものに置き換えたい

なんてものがあって、これをクリアすることは自分の中で絶対条件です。

あと、ちょっと微妙な課題として、

• 現状はDBMS依存で作成しているが、公開するのならば動く環境を増やすために、ファイルベースでも動くようにしておくべきか
• データ入出力周りなんかは、新規に設計しつつあるフレームワーク上で動くようにしているので、もしもファイルベースで動くようにするのならば、フレームワークの方を完成させないといけない
  • でもフレームワーク側はWebアプリ関連の一通りの機能を持たせるつもりなんで、そっちを完成させるとなるといつになるかわからないなー。
  • あとファイルベースで簡単なDBMSもどきの機能（インデクシングによる検索の高速化とか）を実装するのも大変そうだなー。
  • っつーかまじめに作り始めちゃったら、フレームワークの方がWikiLikeなんかよりもよっぽど時間がかかる。
• 本筋とは関係ないけれども、どうせならばTrackBack関連の機能も一通り実装し終えておきたいなー。

なんてのもあるんだけど。

今後どうなるかわからない（たぶんWikiLikeの完成形とは互換性がない）現在私が使っているものをそれなりにまとめて公開することは不可能ではないけれど、そんなドッグフードは俺一人で食っていればいいかなーと思うし。まあどうしても使ってみたいと言う人がいたら、連絡ください。php4以降＋MySQLで動作します。ほかのDBMSに移植するのはそんなに難しくないはず。

_ click critique

• http://clicri.takenaka.com/

略称（愛称？）クリクリらしい。Wikiでの編集作業がページ単位（ParagraphOrientedならば段落単位）なのに対して、文字単位で編集範囲を指定できるようにしたシステム。細かい編集単位を指定してきちんとロックしている分、ちょっとインターフェースがうざくなるのは仕方ないか。編集単位が細かいことよりも、その細かく編集されていく過程を追っていきやすい点が売りなんだろう。

ただ実用上は、編集単位を文字単位まで細かくしなくても、構文解析して一文もしくは文節単位で指定できれば十分って気がする――って案も結構面白そうだな。WikiLikeにそういうインターフェースを用意してもいいかもね。ただWikiの基本的に全文編集って考え方は捨てたくないから、文節単位編集とかと両立させるのはちょっとうざそうだ。せいぜい段落か一文（改行から改行まで）かのどちらか単位でも編集範囲を指定できるようにするくらいか。それでもまだ標準インターフェース化するとうざいかな？　文章量がある程度大きくなった場合（数段落分）のみ、編集パーツを選択できる画面（各文頭にパーツ編集用リンクをつけて表示しつつ、全文編集用リンクも用意する）を編集操作の間に挟むようにすれば、そんなにうざくないかな。でもしょせんWikiだからロック単位は全文になっちゃうだろうけど。それともパーツ編集と全文編集を同時に成立させる仕組みを思いつけるだろうか……。

_ 昨日は雪が降った

ああそういえば書いていなかった。昨日は雪が降ったんでムスコともどもお休み。雪の中ムスコを保育園に送っていくのが面倒くさかったんで（←おい）。んでもって、ムスコとちょっと外で雪遊びをしたり。といっても俺がムスコに雪玉をぶつけて遊んでいただけだけど（←おい）。埼玉南部では10センチくらい積もっていたみたいだけど、都内は1センチ程度だったの？　やっぱ埼玉は南部とはいえ東京とは気候が違うんだなー。そういや今年はスタッドレスタイヤどうしようかなー。去年までの幅が合わないタイヤをもう1年履くか、それとも新しいタイヤを買うか、それとも他人（の車）任せで1年過ごすか。

_ スタイラスをなくした

CLIE PEG-N700Cのスタイラスをなくしてしまったよ。（中古で）買った当初から緩くて落ちやすいからいつかなくすとは思っていたけれど、先週の金曜日に家に帰ったらなかった。てっきり会社の自分の席周辺に落としたと思っていたんだけど、会社に来ても見あたらない。まあCLIEのスタイラスはよく純正品が売っているから、そこらの店で簡単に代替品は手にはいるだろうけど。でもNシリーズの周辺機器はそろそろ危険かな？　サードパーティ製のペン付きとかにもちょっと興味がある。

_ キーワード指向コンテンツ管理システム

• http://member.nifty.ne.jp/ippo/s_d200212.html#d7_t2
• http://bm.que.ne.jp/text/?200212a&to=200212103#200212103

あたりを読んで、やっぱり私と同じようなことを考えている人は結構いるんだろうなーと思った。

結局ポイントは、（日本では（？））個人Webサイト文化の中心があまりにもWeb日記に寄りすぎてしまったため、時系列でコンテンツを管理するシステムばかりが高度に洗練されてしまい、それ以外のコンテンツ管理手法を採用したシステムがあまり発展しなかった、ってことなのかな。本来ハイパーテキストのキーワードでドキュメントを結んでいく仕組みからすれば、キーワードをコンテンツ管理の要として利用するコンテンツ管理システムがもうちょっとたくさん出ていてもおかしくなかったのに。

ちなみに私が2年くらい前に作ったWeb日記システムは、内部的にはかなりキーワード指向に作っていた。ドキュメントには複数のキーワードを設定することができ、そのキーワードと生成更新時刻の2軸を使ってドキュメントを検索し、一覧・詳細表示するという仕組み。はっきりいって現在のWikiLikeは、そのWeb日記システムをWikiっぽく作り直したものだ。

あと、キーワードで複数のサイトを結びつけたいという欲求は私ももっている。たとえばWikiLikeでは、キーワード検索を自サイト内検索であると同時に他サイト検索でもある、といった感じにもっていこうと思っている。現在のところはキーワード検索すると、

• それに一致した自サイト内のドキュメントの内容を表示
• 類似キーワードをもつ自サイト内のドキュメントを一覧表示
• 登録されている他サイト（Googleおよび他のWikiサイト）の該当キーワード検索リンクを一覧表示

を行うようにしている。このあたりはもうちょっと進化させて、他サイトのRSSをもってきて該当ドキュメントが存在するかどうかをもうちょっと詳しく表示したりできるといいかなーと思っている。これによってたぶん「同じ本の感想を複数のサイトにまたがって検索する」なんてことあたりは実現できるだろう。

ただし、このあたりはコンテンツ管理システム側が実装するよりも、実はGoogleのような検索エンジン側が（Webサービスインターフェース経由で）より細かいクライアントからの要求を受け付けるようになればそっちを利用した方が話が早いかも、と思ってもいるけど。

ひとまず私はWikiLikeという方向性でいろいろ試してみるつもりだけど、いろんな人がいろんな枠組みで（できればWiki方面からのアプローチだけでなく、新しいWeb日記システムという方向からのアプローチも）キーワード指向のコンテンツ管理システムを作ってみたりすると、そのうちできのいいシステムが出てきたりするんじゃないかなー。blog方面もかなり有望なんだけど、あっちはニュース指向があまりにも強すぎる気がする。もっと色がないシステムとして開発された方が使いやすくなりそうだ（色は後から付ければいい）。

その他文章としてまとめきらなかったポイントを列挙。

• コンテンツ管理とコミュニケーションのバランス。コミュニケーションは面白くていろいろ発展性もあるけど、コンテンツ管理とは本来別枠に考えた方がいい。→TrackBack
• 認証周りの問題。あるいはコラボレーションの是非というか。コミュニケーションとも絡んでくる。その辺り、根本的なところから考え直す必要がある。

_ スタイラスの代替品

なくしたスタイラスの代替品として、純正のスタイラス3本パックPEGA-ST500/Jを購入。ビックカメラ渋谷東口にはぱっと見た限りではもうCLIE Tシリーズ以降のスタイラスしか置いてないように見えるけれども、Tシリーズ以降用の純正品スタイラスがぶら下がっているところの一番後ろにそっとN/Sシリーズ用スタイラスも置いてあった。

ついでに、とても使いにくいトラックボール風味センターボタン付きマウスArvel Magic ball MFB3USM-MTの代わりに、マイクロソフトのMobile Optical Mouseを買ってきた。Magic ballというのは、センターのスクロールボタン部分がトラックボールみたいなボールになっている製品で、最近のマウス過当競争においてはそれなりにインパクトのあるギミックとして興味を引いている製品っぽいけれども、たぶんこれは一度使ったことがある人たちがある程度以上増えたらそれ以上は売れなくなる代物だろう。

はっきり言ってこのボール式センターボタンは、引っかかりも指向性もないため、通常のスクロールボタンの代替としてはとても使いにくい（思った方向に思った量回転させることが難しい）。またこのボタンは最悪の場合でも、トラックボールの代わりに使えるのではと期待させるのだが、少なくとも現状の（Windows XP用）ドライバーにおいてはそのような使い方は出来ない（パッケージにはそれっぽいことが書いてあったのに）。また、ボールボタン部は通常のスクロールボタンと比べてとても壊れやすい（トラックボールと同じような仕組みだけど、しょせんおまけだからトラックボールほどその部分にお金をかけていない）。

まあどうしても試してみたいという人は一度使ってみればいいだろうけれども、たぶんこれは「着眼点は面白いけれども、実際に使ってみたらとても使いにくい」という感想を持つ人が多いのではないだろうか。

_ Rawデータによけいな装飾はいらない

帰り道にぼーっと、WikiLikeみたいなツールは別にWeb上に公開しておかなくても、PC上で単体で動作するものがあってもそれなりに有用だよなーと考えていて、そして気がついた。

WikiLikeの場合WikiNameやBracketNameで修飾したキーワードは必ず、ドキュメントのキーワードとして別途保存されるんで、それを使えばドキュメントのどの部分をリンクしたいのか分かるんだから、データを保存する際にわざわざ本文にBracketNameを指定する大カッコなんて保存しておく必要はないよな。最初にキーワードを設定するときにだけ指定してやればそれでいい。

そうすれば、ドキュメントのRawデータによけいな装飾をもたせておく必要性がなくなって、再利用性とか可読性が高まるし、同じキーワードに何度もリンク指定を書く必要もなくなる。キーワード最長一致でリンクを張っていけば、キーワードの部分一致関連はだいたいなんとかなるだろう。

_ レンダリング処理にキャッシュを追加

WikiLikeのページレンダリング処理にキャッシュを追加したら、処理がずいぶん軽くなったな。やっぱりレンダリング処理は結構重かったか。特にここのサーバーはCPU負荷がきついときが結構あるみたいなんで、効果が大きいみたいだ。

ただし効果が大きいのはページのデータサイズがある程度以上大きい（というか、フォーマットが複雑な）ときだから、現状のページはすべてキャッシングする仕組みよりも、キャッシングするかどうか判断するロジックをつけた方がいいかもしれない。ただ、そんなロジックを入れて効率化を図ったところで、そのロジック分で食われておしまいかもしれない。

あと微妙なのはコメントだよなー。コメントのほうこそ、データサイズを見てキャッシングするかどうか決めればいいのかな。現状はコメントはキャッシングしていません。

_ ウイルス性胃腸炎

昨日はオクサンが寝込んで、ついでにムスコもちょっと調子悪げだったんで保育園を休ませ、おまけで俺も休み。で、オクサンは何とか動けるようになって今日は会社に行き、ムスコもまあ大丈夫そうなんで保育園に連れて行き、俺はまた明日から出向が始まるんで英気を養うために（ばっくれたくならないように）今日は休んでのんびりすごそうと思ったら、ムスコを保育園に送って帰ってきたとたんに電話が鳴った。ムスコが二度ほどゲロを吐いたという。

あわてて保育園に迎えに行き病院に連れて行ったら、冬場に流行るウイルス性胃腸炎だとか。ゲロゲロ→ゲリゲリコースになるらしく、基本的に1日飲み食いさせずに過ごし、どうしてもゲロが止まらない場合は座薬をつっこめといわれる。で、家に帰ってきてからも更にゲロゲロ状態だったんで、あきらめて今日は家でおとなしく過ごすことに決定。今日はハイペリオンとハイペリオンの没落を買い直しに出かける予定だったのに。会社＆家の近所の本屋では売ってなかったんだよなー。

さらにムスコが「喉が渇いた」「おなかが痛い」と騒ぐもんだから、のんびりWikiLikeをいじっていたりすることも出来ず。ようやく昼寝してくれたんでこんなことをやってられるけど、また起きたら騒ぐんだろうなー。キーワード周りの大幅仕様変更を一気にやっつけてしまおうと思っていたのに。

_ ぷちメディア

• ぷちメディア - http://www.petitmedia.com/

その解説は、自分で書くより良さそうなので以下を引用。

「Odigo」という、同じドメインを見ている人同士でチャットができるIMツールがありましたが、今度はその会話のログが残り、更にブラウザのツールバーで会話の履歴を見ることができる「ぷちメディア」というサービスが登場したようです。どんなサイトにでも勝手につけられるゲストブックというイメージでしょうか。 kera-ma-go ver.2 2002/12/13(金) ぷちメディアより

アイディアはとてもいい。Odigoが出たときにはとても面白そうだと思ったけど、実際に使ってみたらつまらなかったんですっかり忘れていた。けど、その面白くなかった理由を検討し直して修正すれば、十分に魅力があるサービスになるだろう。

でもこのぷちメディアってサービスは、検討し直し方がいまいちだ。普通にWebブラウザで完結するようにしつつ、データの入出力の見せ方を工夫をすればもっと楽しくなるだろうに。自分で作ってみたくなるけれども、作りかけをたくさん抱えても仕方がないんで、やめておこう。でもプロトタイプは1日で出来そうだなー。

ちょっと考えてみたところ、Webブラウザで完結させるのは無理かな。っつーか、Webブラウザで完結させない方がいい部分もあるな。でもWebブラウザのみ（ツールバーアプリケーションは使わない）でもそれなりに使えるようにした方がいいとは思う。

_ 情報の集約と管理者の分散

読むまで死ねるかっにみんなのお勧め本コーナーが出来た。

• みんなのお勧め本 - http://bm.que.ne.jp/review/index.php?cmd=search&word=%5B%5B%A4%DF%A4%F3%A4%CA%A4%CE%A4%AA%B4%AB%A4%E1%CB%DC%5D%5D
• とりあえず試してみる？ - http://bm.que.ne.jp/text/?200212b&to=200212132#200212132

Wikiを使った書籍情報サイトのコーナーとしては、とてもまっとうなアプローチだと思うけれども、ただしこういうイベント的なコーナーをうまく盛り上げるのはとても難しいだろう。

なぜならこのみんなのお勧め本というイベントは、あまりにも一般的すぎる目的を持っているため、それが特定の個人のサイトの1コーナーにあるというポジションと、うまくかみ合わないからだ。このコーナーの目的をサイトのオーナー（および読者）にお勧め本を紹介するという意味に取れば、それはそのポジションとマッチするためそれなりにうまく回るかもしれないが。

本来このようなイベント的なコーナーは、出来るだけ一般的な目的を持ったまま成立させた方が面白い。具体的にいうと、すべての人がすべての人に対してお勧め本を紹介する、というアプローチの方が面白い（情報量が多くなりすぎる点に関しては、適切なフィルターをかませる仕組みを用意して対処する）。たとえば2chやYahoo!くらいの大きなサイトがそのようなものを用意するとそれなりに面白くなるだろう。2chやYahoo!は標準ではそのようなイベントをうまく回すためのシステムはもっていないが（既存のシステムの枠内でそれなりにやることはできるけど）。

で、こういうときにサイトをまたがって情報を集約するシステムが欲しくなる。今回の読むまで死ねるかっ版みんなのお勧め本コーナーのようなものを、さまざまなサイト管理者が自分のサイト上で運営する。そして、その情報をRSSなどの汎用フォーマットで配信して、どこかのサイトで（あるいは何らかのクライアントツールで）複数のサイトをまたがった情報として集約して見せる。そうすることで、情報の管理・運営者を分散させつつ、情報自体はまとめて見せる（検索＆要約のレベルで）ことができるようになる。

その手の仕組みは、最終的にはセマンティックWeb方面の「あらゆるWeb上の情報を再利用できるようにしよう」といった感じを目指すことになるんだろうけど、ひとまず現状においては、さまざまなコンテンツ管理システム同士で相互にデータ交換できることを目指したほうが、実現が早いのではないだろうか。

というのを最近ずっと考えているので、思いついたことをずらずらと書いてみた。ちょっとこの文章は殴り書きすぎるんで、後で（仕事が終わってから）ちゃんと推敲しよう。文意は変えないと思うけど。あともうちょっと具体的な話まで発展させたいな。

_ SL-C700をちょっと触った

近所の電気屋でSL-C700をちょっと触ってきた。ディスプレイはやっぱりきれいで明るい。大きさは思ったよりも小さくて軽い。キーボードは十分に使える。アルファベットに関しては親指ブラインドタッチできそう。特殊文字の入力もそのうち慣れるだろう。ただし、中カッコを直接入力する方法が見あたらなかった（「かっこ」で変換すれば入力できる）。ソースコードを入力する際には必須なんだけどなー。キーバインドの変更って手軽に出来るんだろうか。大カッコはあったんで、Wikiドキュメントを入力するのには問題がなさそう。スピード的にも、メモ帳にひたすら入力するためのデバイスとしては十分な速度。シングルタスクで使う分には初代機でもなんとかなりそうだな。

入荷2台で1台展示用だから在庫1台だけだそうな。次回入荷は一応2週間めどだけど年明けになっちゃうかも、だと。一応世の中に出回ってユーザーの評価が出そろうまで我慢するつもりだけど、何かの気の迷いで買っちゃうかもしれない。ストレス発散とか。

• Zaurus Support Station SL-C700 - http://zaurus.spacetown.ne.jp/sl-c700/menu-slc700.asp

_ ウイルス性胃腸炎感染

やられた。ムスコのウイルス性胃腸炎を見事に感染されてしまった。今日の昼くらいから、なんだか腹の調子がおかしくなってきたなーと思っていたら、夕方くらいから水様便が出始めて、さっきついに吐いてしまった。ウイルスパワーのためか、久しぶりに胃の底の底まで吐いて、喉の奥に胃液の味がたまってとても気持ち悪い。全身がだるくて力が入らない。子供がかかったウイルスなんてしょせん大人の体力を超えることが出来ないんじゃないかなんて甘く見ていたけど、そんなことないね。しかも俺は最近体調を崩していることが多くて体力的に弱っている状態だったし。というわけで、今週末も何も出来ないままに終了してしまう気配。週末中に完治すればいいけど。

_ 救急医療センター (13:48)

あれからひどい目にあった。食べ物はあきらめていたんだけど我慢できずに飲み物を飲んだら吐いて、水様便は止まらなくて、異常に寒気がして布団を重ねて掛けてもがたがた震えて、胃が痛くて体中の筋肉と関節が痛くて眠れなくて、また喉が渇いたんで一口だけお茶を飲んだらまた吐いて、そのうち熱も出てきて頭も痛くなって、結局日曜日に救急医療センター（正式名称忘れた。さいたま市役所の隣にあるやつ）に行って薬をもらったらようやく胃腸は落ち着いたんだけど、普通の風邪の症状は残った。さらにムスコまで、いったん固いウンチになっていたのが、また水様便に戻ってしまった。というわけで、今日はムスコともどもお休み。なんかここ数ヶ月まともな体調でいた期間が異常に短い気がするよ。オクサンがまだ元気（といってもちょっと風邪気味）なのが救いか。

_ 09:13 (20:17)

えーっといつから書いていないんだっけ。ああ、自分が死んでいたときが最後か。月曜日一日休んだらなんとか俺は復活して、ムスコも胃腸の方はなんとかなったっぽかったんで、火曜日に保育園に連れて行ったら、午前中のうちにオクサンのところに呼び出しがかかった。今度は発熱だそうな。で、昨日の朝は保育園に行く前から熱があったんで連れて行くのはあきらめて、すでに出勤していたオクサンに戻ってもらって交代して出社。今が出向中じゃなければ俺ももうちょっと休みやすいんだけどなー。ちなみに俺の体調は復活したといっても、ここ最近のひどい状態から回復しただけで、全快したわけではない。数ヶ月続いている微妙に体調が悪い状態に戻っただけ。

_ 09:17 (20:17)

ボーナスなんてものがうちの会社でもようやく出ましたよ。最近会社に行っていないんで会社自体の調子がどんな感じなのかよく分かっていなかったから、もしかしたら世の中一般の状況に歩調を合わせて結構悪くてボーナスもほとんどでなかったりして、とかちょっと覚悟していたりしたんだけど、全然そんなことはなくて普通に出た。毎年の額は全然覚えていないんで増えたのか減ったのかもよく分かっていないんだけど、たぶん昇給分くらい増えているんじゃないかな？　でもまあボーナスで特に何かを買う予定はなし。ローン関連を払って家計にちょっと入れておしまいかな。次期Linux Zaurus購入資金としてキープしておこう。

_ 09:22 (20:17)

ああそういえば、ボーナスをもらってそれを銀行口座に振り分けて入れたときに気がついたんだけど、俺の各種引き落とし専用口座の残額が先月から3000円しか入っていなかった模様。げげっ、やっちゃったよ。引き落とし専用口座から引き落とされているものは、住所変更とかの手続きをせずに放置しているものばかりで、引き落とし失敗しても簡単に連絡がつかないんだよな。まあ先月の履歴を確認してみたところ、もうこの口座に残っていた引き落としはほとんどが終了しているみたいで、残っている主要なものは先月引き落とされた日付の雰囲気からいって、今月分はまだっぽいからたぶん大丈夫だと思うけど。最後の大物である自動車ローンがとっとと終わってくれるといいんだけどな。来年3月くらいまでかかるんだっけ。

_ 11:19 (20:17)

そういやうちの近所の電器屋ではLinux Zaurusがあんまり人気なくて（というか店自体が人気ない？）展示機さわり放題なんで、昨日早く帰ったついでにいろいろいじってきた（といってもそこにはSL-C700しか置いていないけど）。

アプリケーションの起動は確かに遅いけど、それはGUIアプリケーションだけの話っぽいね。Terminalからコマンドを叩いた感触では、基本的なマシンパワーは結構ありそうな感じだった。ただしメモリ不足はやはり致命的だ。すべてのアプリケーション（高速起動オプション）常駐解除しても、6Mバイト程度しかあかない。いまどきのGUIアプリケーションにとっては少なすぎる。

マイクロドライブにスワップを作れるんだったら結構我慢できそうだけどどうなんだろうな。メモリ64Mバイトになったら絶対買うな。バッテリ容量も増えてくれた方がうれしいけど、そっちは必須ではない。メモリ64Mバイト＋マイクロドライブにスワップ＋マイクロドライブにアプリケーションをインストールできれば、ものすごく使えるマシンになるだろうなー。

そういえば、前に中括弧がキーボードから入力できないと書いたけど、キーボード面にプリントされていないだけで、CTRL＋FN＋「、」と「。」で入力できたよ。これでコーディングも普通に出来そうだな。ただ結構重要な記号がちょっと入力しにくいキーバインディングになっているんで、その辺りをどうするか悩みそうだ。

_ XScaleのキャッシュバグ問題 (13:48)

• Linuxザウルス開発メモ/ハードウェア - http://digit.que.ne.jp/visit/index.cgi?Linux%A5%B6%A5%A6%A5%EB%A5%B9%B3%AB%C8%AF%A5%E1%A5%E2%2F%A5%CF%A1%BC%A5%C9%A5%A6%A5%A7%A5%A2
  • SL-C700はなぜ遅いか(ハードウェア編) - http://digit.que.ne.jp/visit/?Linux%A5%B6%A5%A6%A5%EB%A5%B9%B3%AB%C8%AF%A5%E1%A5%E2%2F%A5%CF%A1%BC%A5%C9%A5%A6%A5%A7%A5%A2#i20

現行のXScale PXA250には、キャッシュ周りにハードウエア的なバグがあり、そのため公式発表通りのパフォーマンスが出ていない（実際に市場に流れている製品では、キャッシュ周りの機能を一部殺している）。Windows CEとかで、旧StrongARMマシンと比べてXScale化された新マシンが速くない理由として、「OSがXScaleに最適化されていないため」だと言われていたが、それは嘘（正確な事実の公表ではない）で、実際にはXScaleのハードウエアバグが主な原因なのでは。という話。

具体的にいうと、PXA210とPXA250にはWrite Backキャッシュにバグがあるんで、現行の機種（少なくともLinux Zaurusでは。Windows CE系はOSソースが公開されていないので不明。CPU設定を覗く系のツールで確認できるのかな？）ではWrite Throughで動かしている状態になっている。Write Back有効と無効でどのくらいパフォーマンスに差が出るのかは不明。もしもその影響が大きいのだとしたら確かに問題だ。

理屈で言うと、非常に局所性が高く、かつ、データの書き込みも発生するような処理においては、Write Backキャッシュ有効/無効でのパフォーマンスの差は大きくなるはず。OSレベルでそういう処理はどのくらい多いものなんだろう？　何にしろ次期Linux Zaurusにおいては、メモリの増強以外にもCPUバグフィックス済みのものに置き換えを希望しよう。

スラドにもスレが立っていた。

• http://slashdot.jp/article.pl?sid=02/12/21/1139251&mode=nested

でそれを読んで、この問題を「問題がある」というためには前提条件が必要であることに思い当たった。それは、XScaleの売り文句がWrite Backキャッシュ有効時のパフォーマンスを前提にしたものであったのかどうか、ということ。Write Backキャッシュ無効時のパフォーマンスを前提に宣伝して売っていたのならば、それは全然問題がない。いわゆる「それは仕様です」だからだ。しかし、Write Back有効時のパフォーマンスを前提に（ベンチマークなどでその場合の値を公表し）売っていたにも関わらず、実際にはそのスペックを満たしていなかったとしたら、それは問題になる。さてこの場合はどっちだったんだろう。

_ 13:27 (20:17)

ここ最近仕事でずっと.NETばかりやっていて、あんまりそればっかりやっていると深みにはまりすぎて後戻りが出来なくなりそうな気がしてきた。.NETはマイクロソフトプロダクツにしてはものすごくできがいいと思うんだけど、やっぱり将来性に不安があるし。せめてApacheあたりと連携して手軽にUnix系サーバー上で動作すればいいんだけど。

というわけで、個人的なリハビリのために家サーバーにTomcatをインストール。Tomcatはバージョン3の頃にちょっと触ったけど、インストールでやたらと苦労した覚えがある（主に関連コンポーネントのバージョン合わせ）。最新バージョンの4.1.18では、最新のJDKとJRE（J2SE v1.4.1）をインストールして、Tomcat 4.1.18をインストールしたらあっさり動いた。しかもなんか管理ツールみたいなものまでインストールされている気配。ずいぶん使いやすくなったみたいだなー。

さてこの環境で何を作ってみようか。.NETとJavaとをWebサービスを使って連携させたりするとちょっと面白そうかな。とかいう色物ネタよりも、普通に単独で動くWebアプリを作った方がリハビリにはいいかな。そういやJavaで作られたWikiって存在するんだろうか？

あら、インストールは簡単じゃなかった。Tomcat自体は簡単に動いたんだけど、Apacheとの連携部分がうまくいかない。昔インストールしたときにはmod_jkとかいうモジュールで接続した覚えがあるけど、今はmod_webappなんてものになっているんだね。で、環境変数JAVA_HOME（/usr/java/j2sdk）とCATALINA_HOME（/usr/local/jakarta-tomcat）を設定して、httpd.confに

LoadModule webapp_module libexec/mod_webapp.so
AddModule mod_webapp.c
WebAppConnection WarpConnection warp localhost:8008
WebAppDeploy examples WarpConnection /examples

を記述するところでしばらくはまる（apachectl configtestが通らない）。が、これは結局httpd.confに上記設定を記述する場所の問題だった。上記設定は、ServerName行とPort行よりも後に記述しなければならない。

というわけで、ひとまず設定自体は通るようになったんだけど、Apache（80ポート）からexamplesを呼び出そうとしてもうまくTomcatのexamplesが呼び出されない。mod_webappまではちゃんと接続しているみたいだけど、mod_webappが「Web-application not yet deployed」と返してくる。ヘッダにJSESSIONIDなんて項目がくっついているから、一応Tomcatエンジン自体は起動しているけれども、アプリケーションが見つかっていない感じなのかな。

うげげ。server.xmlのwebapp関連の設定がデフォルトでコメントアウトされていたというオチだった。つまんねー話だ。

_ Eclipseいじり (13:48)

Eclipse（http://www.eclipse.org/）いじり中。JBuilderよりもこっちのほうがいいのかなー。Borlandは好きだから、JavaだけだったらJBuilderにしようと思っていたんだけど、EclipseはJava以外の言語（PHPとかJavaScriptとか）も統合環境で扱えるってのが魅力だ。CVSサーバーと直接やりとりできるみたいだし。ところでEUC-JPはどうやったら扱えるのかな？　まあこれを機会にコードはすべてUTF-8に統一するってのもありかもしれない。いや、それだとLinuxのshell環境で扱いが面倒だし、UTF-8が読めないブラウザもまだありそうだよな。

とか言っているうちに勢い余って、PCG-SRX7にApacheとPHPとMySQLまで入れてしまった。ついでに設定が腐りつつあったcygwin環境もいったん捨てて再構築。おお、Windowsローカル環境でTomcatもPHPもちゃんと動くよ。WikiLikeは何も書き換える必要なく動作するみたいだな。ローカルWikiLikeをメモ帳代わりに使うのもそれなりに楽しそうだ。ただこのマシンはときどきIIS系の開発のサブマシンとして使うこともあるんだよなー。80ポートはどっちで使おう。排他利用にするかそれともどちらかを別ポートに移動するか。できればIISの方を別ポートに動かしたいけれど、あっちは関連アプリ（VisualStudioとか）がちゃんと連携してくれるかどうか不安だなー。ひとまず排他利用にしておくか。

なんだ、EclipseでEUC-JPを使うのは簡単だ。設定-ワークプレース-エディター-テキスト・ファイル・エンコードの「その他」に「EUC-JP」が見つからないから、てっきりそれ関係のプラグインでも探してきて追加しなければならないのかと思っていたら、単にドロップダウンリストに自分で「EUC-JP」と入れるだけで良かった。Windowsのドロップダウンリストってフリーワード入力OKなのかどうかが一見判別つかないよね。

_ Eclipseいじり 2 (13:48)

EclipseにWebStudio for Php（http://www.xored.com/products.php）とphp Plugin（http://sourceforge.net/projects/phpeclipse）の二つのプラグインをつっこんで、php開発環境を構築。基本的に前者の方ができがいいけれども、-[後者の方はphpのヘルプが同梱されていて、マニュアルを参照しやすい。前者に後者のマニュアル機能だけをつっこむことは出来ないものか]-+[マニュアルがついているのも前者の方だった。あと、マニュアル単体でもダウンロード＆インストールできるはず]+。いずれプラグイン開発関連の資料をあたってみるか。ひとまず前者を使うことに決定。ただし、

<script Langage="php">...</script>

という表現で書かれたコードをうまくparseできないらしい。

<?php ... ?>

に書き直したらちゃんとparseしてくれるようになった。EUC-JPを認識させる方法はEclipseいじりに書いてあるとおり。なかなか良さそうな開発環境を構築できたんで、しばらくこれを使ってphpフレームワークを作っていこう。その前にphpフレームワークの名前を決めないとなー。

_ Eclipse (13:48)

• ホームページ - http://www.eclipse.org/
• プラグインホームページ - http://eclipse-plugins.2y.net/eclipse/

オープンソースの統合開発環境。標準でJava開発環境として設定されているが、プラグインを追加することによって他の言語の開発環境としても使用できる。CVSサーバーとの連係機能も用意されているので、Windows環境ではWinCVSなんかを使うよりも手軽。

_ Eclipseいじり 3 (13:48)

やっぱりすごくいい。これからはほとんどの開発環境はこれに移行しよう。Java関連はもちろん充実しているし（携帯Java関連もできるかな？）、PHPもWebStudio for Phpをベースに環境構築すればちゃんとデバッグまで出来る。ついでにC#も結構まともに開発環境が構築できた（けど、これはまあVisualStudioの方が今のところは使いやすいかな）。あとPerlとHTML/CSS関連の環境があれば完璧なんだけどなー。なぜPerlのPlug-inは見あたらないんだろう。まあ単にコーディング＋実行だけだったら現状の環境でも出来そうだけど。HTML/CSS関連も純粋にそれ用というのではなく、JSP作成の補助的な意味合いのものしか見あたらないし。

そういやWiki（英語のみ）の環境なんかもあったりするみたいだから、がんばればemacsみたいにエディタ機能をコアにがんがんいろんなアプリケーション的機能を取り込んでいくアプローチで、統合開発環境機能をコアにいろんなアプリケーション的機能も取り込んでいけるのかな。コアの機能がemacsなんかよりも強力な分、よりすごいものが出来てきそうだ。

たぶんこれでJBuilderとはさよならすることになりそうだな。ついでにDelphiともさよならしようかな。旧VBとDelphi（Object Pascal）を比較して、言語仕様的な優劣でDelphiを選んで好んで使ってきたわけだけど、現在のVB.NETはDelphiよりもできがいい。これならばWindows系アプリはDelphiよりもVB.NETを使った方が作りやすそうだ。本当ならばC#に行きたいところだけど、あれはJavaに似すぎていて気色悪いし、仕事の都合上VB.NETの方が使い回しが効く。それにVB.NET単体は1万円くらいで売っているから個人で買うのもそれほどつらくないし。Delphi 5 Professionalは5万円くらいしたんじゃなかったっけ。

もうちょっといろいろいじって自分なりの納得いく環境を構築できたら、そのうち情報のまとめを書いておこう。現在の懸案事項は、ApacheとかPerlとかの環境をCygwin環境をベースに構築するのと、Win32用のインストールパッケージ（ActivePerlとか）をベースに構築するのとどちらがEclipseとの相性がいいのか、という問題。最初Win32用パッケージをインストールして構築していったんだけど、あまりWin32パッケージが提供されないツール関連を使いたいとなるとCygwin環境をベースに全部構築した方が良さそうなんだよなー。

_ PHPのオブジェクトとリファレンス (13:48)

PHPのオブジェクトとリファレンス周りの仕様は大嫌いなんだけど、それを何とか使いこなすために試行錯誤中。問題なのは、

• インスタンスの変数への代入＝インスタンスのコピーの作成であること
• インスタンスを返す関数に直接続けてインスタンスの機能を呼び出すコードが書けないこと

たとえば、

class ClassA{
	var $value;
	function Set($newvalue){
		$this->value=$newvalue;
	}
	function Get(){
		return $this->value;
	}
 }

なんて値を保持する簡単なクラスがある。で、そのクラスのインスタンスをグローバルに一つ生成しておいて、あちこちで手軽にそれを使い回したいと思う。

global $a;
$a=new ClassA();

なんてすることで、グローバル変数$aにClassAのインスタンスが生成される。あとはカレントスコープがグローバルな場所ならば、

$a->Set("newvalue");

なんて感じで$aにアクセスできる。でも、スコープがローカルな場所ならば、

function func(){
	global $a;
	$a->Set("newvalue");
}

なんて感じで、いちいち$aがglobalであることを宣言しないといけない。それがいやなんで、どこからでも同じ表現でアクセスできるようなインターフェースを用意してみようかと思った。たとえば、

function &IA(){
	global $a;
	return $a;
}

なんて関数を用意すれば、カレントのスコープがグローバルだろうがローカルだろうが、IA()でグローバルな$aへの参照が返される。しかし、PHPでは関数が返したインスタンス変数への参照を使って、直接そのインスタンス変数の機能を呼び出すことは許されていないらしい。たとえば、

IA()->Set("newvalue");

なんて書くとタイムアウトまで固まってしまう。

$b=&IA();
$b->Set("newvalue");

というように、いったんローカル変数にインスタンスの参照を受け取ってからSetすると、きちんとグローバルな$aに値がセットされるのだが、これならばいちいちglobal $a;を記述するのと大差ないだろう。

ちなみに余談だが、

$b=IA();
$b->Set("newvalue");

は間違い。これはグローバルな$aのコピーである$bに対して値をセットしているだけなので、グローバルな$aには値はセットされない。

このあたりはとてもわかりにくい仕様だ。出来れば代入処理は、stringやintegerみたいな型に対して行った場合はコピーになり、その他オブジェクト型に対して行った場合は参照の代入になるといいんだけど。

ちなみにグローバルなインスタンス変数に対して、どのスコープからでも一意な表現でアクセスする手段としては、

$GLOBALS["a"];

を使うという方法もある。でも$GLOBALSを使った表現は見た目が美しくないので使いたくない。あと、

define("a",new ClassA());

なんてやったらどこでも、

a->Set("newvalue");

なんて出来るようになるんじゃないかと思ったら、あいにく定数にはオブジェクト型は入れられないそうな。

というわけで、現在手詰まり状態（動くことは動くけどね）。グローバルなインスタンス変数に対して、どのスコープからも手軽にアクセスできるような手段はないものかのー。

_ Cygwin環境はなくてもいいかも (13:48)

Eclipseを中心にしたWindows上での開発環境を充実させようと苦闘中。Java（＋Tomcat）、PHP、C#（まあおまけで）、JavaScript、C/C++、Ruby（これは新しくお勉強用）、Python（これも新しくお勉強用）、HTML/CSS（いいプラグインがいまだに見つからない）、XML、おまけでPerl（これはひとまずエディタとしてのみ使えればいいや）あたりを、きちんとWindows上で編集、デバッグもしくは単なる動作テストできるようにしようという方向で。

で、Eclipseとそのプラグインについては、まあ普通にインストールすればそれでOK。あまり揺らぎがない。けれどもその他環境については、Win32専用のインストールパッケージを利用するパターンと、Cygwinを使った疑似UNIX環境を利用するパターンの二つがあって、どれを利用するか迷う。

最初はApache、Tomcat、ActivePerl、PHPをWin32用パッケージでインストールして環境を構築してEclipseと連携させたところ、結構ちゃんと安定して動くようになった。PHPなんかはデバッグ用モジュールとかをつっこんだらトレース実行とかもちゃんと出来るようになったし。

ただ、Win32用パッケージが用意されているツールはさほど多くないし、PerlモジュールなんかをCPAN経由でインストールしようとするときには、Cygwinの疑似UNIX環境が合った方が役に立つ。あと、Win32用パッケージは最新版に追随しないから、最新版を追いかけたいようなツール類をWindows上でも使いたいとなると、Cygwin環境の方がいいかも。

と思って、一日かかって環境を再構築していたんだけど、Cygwin環境ってそんなに万能じゃないみたいだなー。UNIX環境みたいに普通にソースからインストールできるツールはそんなに多くないようだ。設定を何とかしろっていうレベルならばいいんだけど、コンパイルにVisual C++が必須と言われるとつらい。特にVisual Studio .NETのC++は古いバージョンとはいろいろ互換性がなくなっているみたいだし（windows.hはどこに消えた？）。

というわけで結局、ApacheとPerlとRubyはWin32用のパッケージからCygwin環境のものに移行したんだけど、その他は普通のWin32パッケージを使うことにした。Cygwin環境のApacheからもWin32用パッケージでインストールしたバイナリに「/cygdrive/ドライブレター/****」でアクセスできるみたいだし、逆方向の連携は普通に実行すればCygwin用バイナリは勝手に内部でCygwin経由で起動してくれるようだ。

ただ単にEclipseを使ってWindows上での開発環境を構築したいという場合は、基本的にCygwinとの連携ははじめから考えずに、Win32ベースで出来る範囲でベストの環境を構築する方針にした方が良さそうだな。Windows環境ではWin32用パッケージでインストールしたものの方が使いやすいことが多いし、Cygwin環境を使ったところで開発環境の可能性の幅はさほど広がらないようだ。というのは、Cygwin環境で（Visual C++なしで）普通にソースからインストールできる開発ツールは少ないようだから。

まあRubyみたいにCygwin環境でも普通にコンパイルできるものもあるし、ApacheからPerlのパスを指定するときに「c:\perl\bin\perl」なんて書くよりは「/usr/bin/perl」と書けたほうがいいから、俺は一応Cygwin環境と半々で使っていこうと思うけれども、たいていの場合はWin32用パッケージだけで環境構築した方がよさそう。しばらく使ってみてCygwin環境を使うメリットが感じられなくなったら、俺もWin32用インストールパッケージオンリーな環境に戻すかも。

ああ、ちなみにメインの実行環境はUNIX系OS上であることが前提ね。実運用までWindows上でやろうというパターンは想定していない。