主な機能は新しいサーバー側に移動したんで、DNSもこっち側を参照するように切り替えた。まだいろいろ漏れている部分や修正が完全じゃない部分があるし、これから全面的に書き直す予定の機能もあるんで、まだまだしばらくの間は不安定な状態が続くだろうけど。

ちなみにこの記事は新しいサーバー側にだけ投稿してあるんで、この記事が見えている人は新しいサーバー側を見ている人。古いサーバーは契約が残っている間は一応残しておくけれども、そのうち消えると思う。メールもこっちのサーバー側をMX 10にしたんだけど、ちゃんと届くかな？　メール回りの設定はいろいろ手こずったんで、結構不安かも。

ちなみに全体的にURLがいろいろ変更されている（アプリケーションごとにバーチャルホストを割り当てる方針）けれども、だいたい転送をかけているんでそれほど不便はないはず（だといいな）。何かあったらBBSあたりにどうぞ。

QuickMLを社内MLシステムとして使ってみているんだけど、社外の人にメールを送るときにBCC:quiclml-addressとして、QuickML側にログを残そう（QuickMLあてのメールはすべてアーカイブを残すようにしている）としたら、そのメールにCCした人たちがQuickMLのメンバーに追加されてしまい、さらにそれに気付かずに社内向けのお金の話とかをぶっちゃけ気味に書いたメールを別便で出してしまった（＝社外の人に送ってしまった）。うがー。まあ基本的に正直な商売をしているつもりなんで、お金の話がばれても大して痛くないつもりなんだけど、悪い方に考えるといろいろまずいかも。まあひとまずなるようになるさということで、あまり深く考えないでおこう。

• 本人以外が送るTrackBackについて - http://artifact-jp.com/mt/archives/200309/sendtrackback.html

私も一時期、REFERERで自分のサイトあての言及を見つけたら、それを自分でTrackBack化する、ってことをやってました。

当時はREFERERも表示していたので、「ノイズが多いREREFERの中から、明示的な言及元を抽出し、第三者が関連記事を追いやすくなるように」、という目的でした。

私は、TrackBackの意義は、「言及通知を明示的に送ることができること」よりも、「言及に関する情報が第三者に公開されること」の方が大きいと思っているので、それを送った人間が誰であろうが構わない、と思います。

あと本筋ではないけれども、

>>具体的には、先日excerpt内でaタグが閉じていないTrackBackが送られてきて、サイトのデザインが崩れてしまったんですが

みたいなのはTrackBackの脆弱性ではなく、MovableTypeの脆弱性でしょう。ソースを見たわけではないけれども、なんだかMovableTypeって基本的な作りが甘すぎる気がする。

「CoCoonが来た」で書いた、50日体験キャンペーンに当選して一ヶ月ちょっとの間使ってきたCoCoon CSV-P500を昨日返却（着払いで発送）した。

スカパーと連動し、適当なキーワードで好きそうな番組を適当に録画し、見なかった番組は勝手に消えていく、というコンセプトは確かに悪くない。特にCoCoonがある間は、「F1」とキーワードに入れておけば、F1の放送日を気にしなくても勝手に録画してくれたのが、一番便利だった。

ただ、10万円出して買いたいというほどのものではなかった。というのは私の場合、ハードディスクレコーダーとしてすでに東芝のRD-X2を持っているので、ハードディスクレコーダーの基本性能はすでに魅力にはならない、というのが大きい。多分ハードディスクレコーダーを持っていなかった人が体験すれば、それだけで購入する動機になるだろう。

ちなみに、インターフェースのできが悪い東芝機と比べると、CoCoonの操作性はものすごくよかった。一般的な家電としては、複雑すぎていまいちだろうけど、並の1/10くらいのできであるRD-X2と比べれば5倍は使いやすい。

あと、EPG（番組表）機能があるというのはやはり便利だった。特に地上波とスカパーの両方のEPGがあるというのは強力だ。スカパーチューナーとも専用端子を使って完全に連動する。そして、うちのスカパーチューナーのEPG画面よりも、ジャンル別表示などの機能が用意されたCoCoonの方が圧倒的に使いやすい。

キーワード登録は思ったよりも使いにくかった。というのは、登録できるキーワード数が少なすぎる（地上波、スカパー3個ずつ）し、うまくヒットするキーワードを用意するのも難しい。情報量の少ないEPGで提供されるデータを元に、自分の好みの番組をヒットさせたいならば、簡単な正規表現くらい使えないと納得いく設定が出来なそうだ。ジャンルをキーワード化してしまうと山のようなゴミ番組が取られてしまうし。

DVDメディアが扱えないという点は、やはりかなりのマイナスだ。CoCoonがある間はRD-X2はほとんど使わなかったのだけど、そうすると後でちゃんと見たい番組なんかもCoCoonで録画することになってしまう。しかし、テレビなんか観ている暇はほとんどなかったので、結局CoCoonで録画した番組はそのまま見ずに返却することになってしまった。外部メディアがあれば、ひとまずDVDに落としておくことが出来たのに。

RD-X2ユーザーによるCoCoon体験記はこんな感じでしたとさ。

こっちのサーバーが安定稼働しているっぽいんで、旧サーバーはまだ利用期間が残っていたけれども、アカウントを破棄してしまった。英文で契約関係のメールがちゃんと通じるかどうか結構不安だったけど、なんとかなった模様。DNS情報もだいたい浸透したっぽいし。ただ、www.ishinao.netの登録は最後の最後に切り替えたんで、まだ古いサーバーを見ているところがあるかも。

日記やらblogやらwikiやらCMSやらの連携について議論するML（http://kitaj.no-ip.com/tdiary/20030909.html#p02）に投稿したネタだけど、こっちにも転載しておこう。

QuickMLのルーズな柔軟さはWikiに通じるものがあるよなーと思い、面白そうな実装方法をいろいろ考えていたのですが、いまいちうまい仕組みが思いつきません。

が、試しに無理矢理実装例を考えだしてみます。

QuickMLの1アドレスが、一つのWikiサイトに相当します。目的なしのWikiサイトではなく、何か目的を持ったWikiサイトな感じです。

replyではない投稿は、新しいWikiページを作成します。Subjectがページタイトルになるでしょう。メール本文には簡単なWiki記法が使えます。

そして、そのメールへのreplyはそのWikiページへの編集コマンドになります。特に何も指定がなければ追記（あるいはコメント）になります。対象となる場所と差し替える文章を指定することで、既存のドキュメントを修正することも出来ます（patch風）。

Web上では、そのようにして作成されたWikiページの形でMLアーカイブを見ることが出来ます。Web上でも通常のWiki同様の編集が可能です。

こうやってMLのスレッドをWikiページに見立てることによって、単純なツリー表示などよりも、ある話題に関する可読性の高いドキュメントの生成が期待できそうに思います。

といった感じなんてどうでしょうね。修正系の簡便なコマンド体系さえ思いつけば、実装は簡単そう。新規にWikiシステムを書くのが面倒ならば、MLの投稿を適当に整形して、既存のWikiシステムのインターフェースに放り込んでしまってもいいし。

ただ、メールの本文だけを確実に抽出する（署名みたいな余計な要素を削る）処理が結構難しそう。あと、Web（Wiki）からML側へのフィードバックをどの程度にするかも考えどころ。

このサーバーにqmailとQuickMLを同居させてみようといろいろ試してみたところ、QuickMLがlocalhostにSMTP接続して、他のサーバーにメールを配信しようとするときに、中継拒否になってしまうので、それを回避しようと、relay-ctrlの設定やらqmailの設定やらをいろいろいじっているうちに、通常のメール着信を拒否（rcpthostsからメール用ドメインを削除）してしまっていた。今日の昼から2時間くらいその状態になっていたんで、その間にML関連とかがひどいことになっていないといいんだけど。最悪、自動退会になってるかなー。

ちなみにtcpserver -x /etc/tcp.smtp.cdbとか/etc/relay-ctrl/RELAY_CTRL_RELAYCLIENTとかを設定しても、どうしてもlocalhostからのSMTP接続を無条件に許可する設定が有効になってくれなかったんで、現在のところ/var/spool/relay-ctrl/allow/127.0.0.1を定期的に生成する、という超ごまかし設定で逃げている。qmail＋APOP before SMTPな環境でのストライクな設定例がどこかに転がっていないかなー。

また、日記やらblogやらwikiやらCMSやらの連携について議論するMLに投稿したネタの転載。

私は、

• サイト間の被言及（逆リンク）情報を、REFERERやWeb巡回で見つけ出すのは面倒だなー。そんな情報が自動的に構築できたらいいのになー。
• MovableTypeにあるTrackBackという機能が流行れば、（半）自動的にそういう 情報が構築できそうだぞ。
• TrackBackが流行らないかなー（自サイトへの適用＆微妙に宣伝活動）。

という感じだったので、もともとTrackBackの本来の意義（ってなに？）よりも、それを使えば「サイト間の被言及情報が構築される（されやすくなる）」ことが重要でした。

ですから、TrackBack自体（の、そういう目的で使える仕様以外の要素）はどうでもよく、サイト間の被言及情報が簡単に構築される仕組みさえあれば、その依って立つ技術は何であっても構わない、という立場です。

流行らせるために、TrackBackがすでに持っていたユーザーベースは魅力だったのですが、TrackBackはそういう目的（がメイン）のものではない、という意見が多いのならば、そういう目的がメインの仕組みを別に作ってもいいかなー、とも思っています。

龍成さん（http://www.ryu-sei.com/d-point/）がやっているTrackGetみたいな仕組みの方が、より目的が明確でいいのかも。

＃ただ、いちいちReferer元をGETして解析するという実装は、あまりにも負荷が大きそうなので、そのあたりをなんとかしないとつらそうだけど。 ＃そのあたり、負荷が分散できるTrackBackの方が現状においては使いやすい。 ＃現実的には、TrackBack互換のインターフェースも持たせつつ、さまざまな方法で被言及情報を構築するための仕組み、を考えるのがいいのかな。で、TrackBackという名前は（トータルの仕組みに関しては）名乗らないようにして。

2004/2/16

WindowsとSyncしようとすると、一応認識はしているのにSyncに失敗するときがある。しばらく待ってつなぎなおしたら通ったり、それでも通らなかったりといろいろあってうざかったんだけど、Syncが通るかどうかの見分け方がわかったので紹介。ちなみにSync方法はUSBネットワークを利用している場合。

USBケーブルを差したときに、Linux Zaurusを認識している場合は、タスクトレイの「ハードウェアの安全な取り外し」あたりに「SL series Ver3 (NDIS 5)」なんていう選択肢が表示されるはず。

で、それで認識OKだと思ってSyncをしてもうまくいかない場合は、Windowsの「ネットワーク接続」あたりを見てみる。すると、現在Windowsで認識しているネットワーク端子の一覧が表示される。そこで、「SL series Ver3 (NDIS 5)」がきちんと有効になっているかどうかを確かめる。うまくいかない場合は、こっちが無効になっているはず。たぶん、ハードウェアとしては初期化に成功したけど、ネットワークとしての初期化に失敗したって感じなんだと思う。

一度「無効」として認識されてしまうと、ソフトウェア的に「有効」にしようとしてもうまくいかないらしいんで、ハードウェア的に初期化をやり直してみる（＝ケーブルを抜き差しする）のが吉。自動認識（Plug and Play）が働くのにちょっと時間がかかるんで、抜き差しにはちょっと間をあけた方がいい。あと、なんか一度失敗したUSB端子にもう一度差してもまた失敗する確率が高いっぽいんで、端子が別にあるならそっちを使った方がよさげ。

2003/9/11

• ポケットシンク for Zaurus - http://pocketgames.jp/modules.php?op=modload&name=Shop&file=index&req=viewarticle&artid=146

リナザウでシンク＆充電が出来る巻き取り式USBケーブル。むむむ、欲しいかも。充電ってどのくらいの効率で出来るんだろうなー。

2004/1/13

今さらながら通販で購入。やっぱりこれいいな。標準のケーブルみたいにじゃまくさくなくコンパクトだし、ケーブル自体も薄いからのばしたときの邪魔度も低め。USB経由での充電効率がどれくらいなのかよく分からないけど、俺の場合それほどばりばりバッテリを消費しないんで、会社でSyncついでにノートPCに接続してからしばらく放置しておけば、そのうち（数時間で）満充電になっている感じ。

こうなると、同じような形のau携帯対応USBモデム＆充電ケーブルが欲しくなるなー。俺がバッテリ残量を気にしているのは、ノートPCとSL-C760と携帯電話の三つなんだよな。巻き取り式じゃないやつだったら、携帯電話管理ソフトの付属品として存在するみたいだけど。

• ZDNN：ダウンロード楽曲の転売、ついに成功 - http://www.zdnet.co.jp/news/0309/11/ne00_itunes.html

なるほど、デジタル音楽を権利付きでプレゼントする、か。それができるならば、従来CD（物理媒体）をプレゼントしていたところをMP3で送ったり、（商用）着メロをプレゼントしたりとか、いろいろ使い道があるし市場もありそうだな。

現状の技術で一番シンプルな実現方法としては、プレゼントする側が決済まで行ったあとで、ワンタイムのユニークIDを発行して、それをメールか何かでプレゼントする相手に送ると、送られた相手はそのワンタイムIDを使って権利登録ができる、って感じかな。

本当だったら、権利を簡単に他人に譲渡する仕組みを構築した方がスマートなんだけど、そっちのアプローチは完全に穴がない仕組みを作る（＆検証する）のが難しいし、1個でも穴があったらすべてに意味がなくなっちゃうからなー。

前記の方法のサービスをしているところってあるのかな？　まさかこういうのまでソフトウエア特許とかビジネスモデル特許とか取られたりしてないだろうなー。まだ取られていなかったらここで書いたから公知の技術ってことで。

※ワンタイムID＋当事者同士たちだけが知っているパスワード的情報（携帯電話番号とか）の組み合わせ、とかにするともっとセキュアかな。 ※いわゆる「魂の移動」と組み合わせれば、すでに購入した楽曲の権利を譲渡することも可能そうだな。