トップ «前月 最新 翌月» 追記

2002|01|02|03|04|05|06|07|08|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|02|03|04|07|

2004-02-01 [長年日記]

_ プロバイダに責任を代行させるのはどうだろう (13:51)

2004/2/1

悪徳商法？マニアックス（http://www6.big.or.jp/~beyond/akutoku/）が株式会社ウェディングの記事（http://www6.big.or.jp/~beyond/akutoku/topic/wedding.html）がらみでGoogleのインデックスから削除された件（http://www6.big.or.jp/~beyond/akutoku/topic/index.html#0106）や、はてなダイアリーで株式会社ウェディング関連のキーワードや日記が削除された件（http://d.hatena.ne.jp/koseki/20040201#1075628304、http://d.hatena.ne.jp/toronei/20040201#p5）。

なんか論調として、Googleへの批判とか、悪徳商法？マニアックスのホスティングをしているところ（が出て行くか個人情報を渡すかの二択を迫ったこと）への批判とか、（協議会とかを開かずに削除を行った）はてなに対する批判とかが大きいように感じるんだけど、それは違うんじゃないか。

まず大前提として、自分の言論の責任は自分でとるのが基本なんだから、プロバイダを隠れ蓑にして自分の言論の責任の代行をさせるのはやめようよ。特に問題がない状況で、プロバイダに匿名性を確保してもらうのはかまわないけれども、何らかのリアルなトラブルが発生した場合にまで、その言論の責任代行（の一端）をプロバイダに押しつけるってのは、プロバイダの業務の範囲外だろう。

プロバイダが自分の言論の責任代行をしてくれないと文句を言わずに、クレームをつけてきた相手が直接自分にコンタクトができるように、情報を公開したらどうだろう。じゃなかったら、中途半端な言論の主体を振りかざさずに、日本のネットにおける著名なクレーム代行請負者のところ（2ch＠ひろゆき）あたりで、匿名性の陰に隠れていた方がいいと思う。

まあ実名で批判したとしても、プロバイダに圧力をかけてくるようなクレーム者は存在するだろうけどね。弱くて効果が大きいところを攻めるってことで。

2004/2/2

>>僕の記事に限って言えば、今回のはてなの対応に問題があるとは思っていないですし、第一匿名でもありません。(一部誤解を招く表現を削除しました)事実関係をはっきりさせることで事態を改善する必要があるのではないですかと、穏当な意見を申し上げています。

確かにkosekiさんに関しては、「匿名で」という部分は正しくありませんでした。十把一絡げに扱ってすみません。ただ、

  1. もともとこの手の問題になりそうな話題をはてなダイアリーという場で行い、結果としてクレームがプロバイダ（はてな）に行ってしまった（kosekiさん個人へアクセスするよりもはてなにアクセスする方が簡単である状態になっていた＝匿名者の批判と同じことになってしまった）こと
  2. 自分の言論に対するクレームが付いた場合に、その仲介をしたプロバイダを追求するよりも先にやることがある（株式会社ウェディングを批判することがメインなのならば、はてなダイアリー以外の（より直接自分で責任がとれる）場に移動して、話を続ければいいのでは）ように私には思えるのに、追求の矛先がはてなの方に向いてしまっていること（これは「kosekiさん自身が」というよりも、「それをきっかけとした多くの人の反応が」という要素が大きいです）

というあたり（特に後者）に関しては、やはり当初の私の文章の対象となると思います。

要は、「はてなの対応」を批判（追求）したいのか、それとも「株式会社ウェディングの問題点」を追求したいのか、いう話です。そして前者（はてなの対応批判）に関しては、それは私には「筋違いの批判（自分の言論の責任代行をプロバイダに押しつけている）」ように見えるのです。

（追記）2/1ぶんと2/2ぶんの文章の間には、#726〜736のコメントでのやりとりが（暗黙の話の流れとして）挟まっていますので、そちらも読まないと、読解しにくいかもしれません。

2004/2/2 その2

>>はてなとかさるさる日記だからというわけではなく、レンタルサーバーでもおこってることだし、逆質問ですが、プロバイダーに責任は代行させるべきではない、ホームページやWeb日記、Weblogなどで責任ある発言をしたい人は、ホームサーバーぐらい立ててそこでやれということなのでしょうか？

思いつく方法としては、

  1. 犯罪・訴える系のクレームをつけられないような（プロバイダがその手のクレームを受けても自らの判断で却下できるくらいの）表現方法を考える
  2. サービスプロバイダなどにクレームが行かないように、現実でのクレームの宛先を明記しておく
  3. 責任をとらなくてすむ別の手段を考える（匿名告発手段としては、2chとかスラドみたいなシステムを使う方法がありますし、日本の法律の及ばない国のサーバーを使って身元を隠した告発を行うという方法もあるでしょう）

あたりでしょうか。

というか、「ホームページやWeb日記、Weblogなどで責任ある発言をしたい人」という場合の「責任」とは何をさしているんでしょう？

「すべての個人情報を相手に渡してもかまいません。直接私がクレームへの対応をします。ですから、私の文章は削除しないでください」でしょうか？　それとも「記名で文章を書いて公開します。しかしクレームがきた場合はプロバイダが仲介して、決して私の個人情報はあかさないでください」でしょうか？

相手がやばい系だった場合など、自分の身元を明らかにするリスクが高すぎることもあるでしょうから、その場合は3番目の「責任を回避して発言する」手段を模索するのもいいでしょう。ただ、「文責は持ちたい（記名で批判したい）」けれども、「現実的なクレームの矢面には立ちたくない（プロバイダに代行させたい）」というのは、「責任ある発言」ではないと思います。

ポイントをまとめると、「“言論の自由”を守るためのコストをサービスプロバイダに押しつけるのはおかしい。第一にまず発言者自らが最大のコストを支払うべきなのではないか」といった感じです。

2004/2/3

>>プロバイダ側でユーザの（まともな）発言をサポートするサービスがあってもいいんじゃないかな

確かに、そういうサービスができるといいですね。逆に言うと、そういうポリシーを明確にしているところ以外では、基本的にユーザーは自己責任の範囲で行動するべきだとも思います。あとたぶん私の言う「自己責任」はkosekiさんが考えている「自己責任」よりもずいぶんと重い。はっきり言うと「訴えられる覚悟をする」ってことです。

>>ishinaoさんの回答は少し腰が引けていますが、私は「そうです」と申し上げたい。極論でも何でもない。自分でサーバを用意していないのだから、結局はサーバ屋がダメといったらダメなのは当たり前です。

別に腰が引けているわけではなく、せっかく下がった技術的な敷居まであげることを是としたくないので、「自分でサーバーを立てろ」とはしなかったのです。

ところでこのような問題の背景にあるのは「ホームページ/blogで気軽に情報発信」的なコピーの「気軽」の意味の取り違えがあるのではないか、という気もしてきました。ここでいう「気軽」は、あくまでも「技術的・経済的コストがかからない」という意味での「気軽」であるはずなのに、「発言の内容を気にしなくていい、責任をとらなくていい」という意味での「気軽」だと認識している人が多いのではないか。あるいは2ch的な特殊な場に慣れすぎてしまい、あれがネットでの標準だと思ってしまっているのか。

私の文章は、はてなに限らずネットにおける風潮一般に対する批判なのですが、はてなに限定して言えば、ここの文章が一番私の言いたいことをわかりやすく表現してくれていると思います。

やばい発言をする場合には、本来どのくらいのリスクがかかるのか、それを受け止めることにはどれくらいのコストがかかるのか。そしてそのコストを誰が受け止めるのか。という話として。

2004/2/4 自分なりの総括

今回の件は、私にとって複数の問題が内包されていました。

  1. 悪徳商法？マニアックスがクレーム対処に関して、プロバイダの対応を非難していたこと。
  2. はてなダイアリーでキーワードやkosekiさんの日記などにクレームがつき、削除されたこと。その件について、はてなダイアリーの「削除」という対応に関する追求が多かった（説明責任という論調が多かったが）こと。
  3. その後も問題のクレームの対象になりそうな文章をはてなダイアリーに掲載する人が見受けられたこと。そのような再クレームを誘発するようなことを行いつつも、そのクレームを自ら引き受けるという人が見受けられなかったこと。
  4. 最近ネット上の発言があまりにも無責任方面に向かい過ぎているのではないか。またその責任は結局、顧客情報を守るという立場のプロバイダがかぶらされているのではないか。と以前から考えていたこと。

で、結局4という観点から、「発言の責任は自分で取れ。プロバイダに肩代わりさせるな」という問題を提起した訳ですが、この問題提起を元に1〜3の各項目を批判したのはあまりにも乱暴でした。結論をベースに各項目を批判してしまったため、結果として想像・創作の要素があまりに大きすぎる批判になってしまいました。

特に、今回のはてなダイアリーにおけるkosekiさんの件に重ね合わせ、kosekiさんを批判したのはやり過ぎだったと思います。結論ありきで批判してしまいましたが、色眼鏡を取り払って見ると、結果として似たような状態になったものに対して、結果論で批判しているという面は否めません。ですから、ここの記事・コメントにおいて私が書いた文章には、kosekiさんを不当に批判している点が含まれていることを認めます。kosekiさん、申し訳ありませんでした。

ただ、私の考え方は基本的に変わっていません。いくらネット上でも、いくつかの特殊な場を除いては、基本的に発言者が自分の発言の責任を取るべきだし、自分の発言に対するクレーム対処に、単に場を提供しているだけの（編集・公開の可否を判断するなどの、文責の一端を担う行為を行っていない＝ここが一般の出版社と著者の関係とは大きく異なる）プロバイダの手を患わせるのは極力避けるべきだと思います。なにしろ根本の問題は、自分の発言にあるわけですから。

しかし、プロバイダの責任（あるいは義務）というのもある程度あるわけですし、誰がどの程度のコストを負担して事態に対応するべきかは、ケースバイケースでしょう。また、プロバイダへの負担を考慮して「危険そうな文章ははじめから掲載するな」的な主張は、自由な言論を抑制するというデメリットも大きすぎるため撤回します。

私の考え方は、プロバイダ擁護に偏っていますが、誰でも基本的に自分の身はかわいいものなので、プロバイダ擁護に偏ったくらいの考え方をしてようやく、コスト負担が妥当なバランスになるのではないかという気がします。

はてなダイアリーでは、この手の問題に対応するためのガイドラインを作成する（http://d.hatena.ne.jp/keyword/%a4%cf%a4%c6%a4%ca%a5%b3%a5%f3%a5%c6%a5%f3%a5%c4%ba%ef%bd%fc%a5%ac%a5%a4%a5%c9%a5%e9%a5%a4%a5%f3）という方向に向かっているみたいですし、個人的には公開の場で現実にもまれながら作成されるガイドラインの有効性・妥当性というものに期待します。一般プロバイダが用意している、おそらくは弁護士が作成したのであろう規約が、どの程度妥当なのかは疑問だったので。

2004/2/6

今回の件のまとめとして、kosekiさんが関連する10の質問を公開しています。今回の件に限らず、一般論としても回答できるものなので、興味のある方は是非回答してみてください。特に11。

[ツッコミを入れる]

2004-02-03 [長年日記]

_ So-net ADSL 26M化計画 (6)

ようやく縛りが解けた（開通確認がとれた）らしいんで、早速So-net ADSL 40Mに申し込み。ところでSo-net Phoneの方の解約ってどうなっているんだろう？　回収キットが届くと書いてあったはずだけど、さっぱり届かないなー。So-net ADSL 26Mに切り替える手続きに紛れて忘れ去られているんじゃなかろうか。

[ツッコミを入れる]

2004-02-04 [長年日記]

_ So-net ADSL 26M化計画 (7)

今朝So-net Phoneの回収キットが到着。結局月頭に解約依頼を出しても、その月いっぱいは契約が継続するから、翌月頭になるまで回収キットは届かないのね。接続機器の変更を伴うコース変更はとっととやってくれるのに。

で、結局今回はいつまでたって「TAを使ってSo-net Phoneを利用している人のみADSLコース変更不可」という状況に嫌気がさして、変則的に「So-net Phoneを解約」直後に「コース変更申し込み」をしてみたわけですが、コース変更の手順をだらだら踏んでいるうちに、いつの間にやら上記縛りがなくなった模様（だよね。見つからなかった）。

あんまり意味のあるチャレンジじゃなかったな。いまだにしばりがあるようだったら、どうやると効率よく縛りを回避してコース変更ができるのかのTIPSがネタになったのに。

ちなみにうちの回線は、現在26Mコースを14Mbps強程度で安定して使えています。

_ ＣＧＩの欠陥突き情報引き出した京大研究員逮捕　警視庁 from asahi.com

2004/2/6 の続き

この件のまとめページ。後半で罪状ごとに、検察側、弁護側の（想像上の）意見を並立させているあたり、とても良くできている。

2004/2/4

>>ハイテク犯罪対策総合センターの調べでは、河合容疑者は昨年１１月６〜８日、著作権保護団体のサイトのサーバーに不正に接続し、ネット上で同協会に相談を寄せた約１２００人分の氏名や住所、相談内容などを引き出した疑い。

>>さらに同月８日、都内で開かれたネットの安全対策担当者やハッカーの集会で、参加者約２００人に接続方法を公開し、協会にも接続したことをメールで通知した。そのうえで、サイトの一部の閉鎖を余儀なくさせ、協会の業務を妨げたとされる。

不正アクセス禁止法違反と威力業務妨害か。厳しい判断だな。

特に前者に関しては、やばそうなWebアプリを見かけたときに、自分の身を守るために勝手にテストすることまで、不正アクセス禁止法違反に問われてしまいかねない。ただ逆に言うと、少しでもやばいことをしたら即不正アクセス禁止法違反だと認定されるのならば、遊び半分でクラックするような行為への抑止力になるかもしれない。ただそうすると、この手の問題は根深い方向に向かってしまいそうだ。

威力業務妨害の方も微妙すぎる。「威力」ってのは何？　システムに問題があることを周知させることも「威力」なのか？　「業務が妨害された」のか、それとも問題を認識して「自主的に業務を中断した」のかどっちなんだ？　これってACCS側から罪状を取り下げさせることはできないのかな？（親告罪じゃないけど）

多人数に公開したことは問題だったと思うけれども、基本的にはセキュリティ意識の改革・向上を求めてのことだったんだから、厳重注意の上、今回は罪に問わないってあたりでいいと思うんだけど。

>>ACCSによれば「男性はイベント終了後に，はじめて当協会宛にメールでCGIのぜい弱性を指摘し，個人情報を入手できることを通知してきた」という。

あれ、そうだったの。てっきり逆だ（すでに通知してあるのにまだあいている穴を使った）と思っていたよ。それだったら確かに「ちょっと行き過ぎた」ですませるのは難しいな。悪意のある攻撃（クラッキングというのではなく、ACCSという存在自体に対しての）ととられても仕方がないかも。なんでそんなことをしたんだろう。

2004/2/5

公式に、今回の件のグレーな部分をきちんと指摘する声明を出してくるあたり、京都大学およびこのセンター長は偉いな。トカゲのしっぽ切り的な方向に向かわなくて好印象。

2004/2/6

問題のコンテンツをACCSから請け負って作成・運営している会社の代表取締役の人の見解。

>>また、この間、ユーザの個人情報を盾に、われわれを脅迫した人物でもあります。

と言い切ったのが結構すごい。この事実をきちんと証明できるんだろうか。

>>現在、ASKACCSの再開に向けた作業を進めていますが、 セキュリティの専門家やセキュリティ技術に依存しないセキュリティのあり方、セキュリティに依存しない情報社会のあり方を模索していかなければならないと考えております。

ってのはなんとなくいやな感じだ。技術嫌いの人の技術否定論って感じがして。その解決策はおそらく法規制の方向なんだろうなーと思うけど、技術を伴わない法規制なんてものでは、技術的な問題は解決できないだろう。セキュリティは倫理だけでコントロールできるものではない。最低限の技術的な裏付けは必要だ。もちろん技術だけで解決できるものでもないので、ある程度の法規制も必要だが。

って書いてから見に行ったら、うげ、このページ削除されてるよ。ひでーなー。

そういうことすると、うちみたいに文章の一部分を引用して批判しているところを見た人に、文章のほかの部分を読む機会を失わせ、結果として自分自身の主張がねじ曲げて伝えられるという行為を、自ら助長していることになってしまうんだよ。それにどうせそのうち2chとかに全文コピペが貼り出されるだろうし。

によれば、この会社のサイトの他の人のコラムにも、

>>ASKACCS「著作権・プライバシー相談室」を閉鎖に追い込んだ憎っくきサイバーテロリスト、「officeこと、河合一穂」がついに逮捕されました！

と書かれてあったのが削除されたらしい。なんかすごい印象悪いんだけど、削除してばっくれるつもりなの？　なんらかの釈明なり再掲載なりした方が印象がいいと思うんだけど。

後者の全文コピペ発見。

声明文の方もまだGoogleキャッシュに残っていた。

_ NEC WR7600H

2004/3/2

結局この機種にはPCカード「WL54AG」がちゃんとささっていました。疑ってごめんよ＞NEC。詳しくは「So-net ADSL 40M化計画」の方を。

2004/2/4

ひとまず購入。まだ使っていないんだけど、箱を開けてみたら保証書が2枚入っていてびびった。片方はWR7600Hのものなんだけど、もう片方にはWL54AGと書いてある。一瞬間違ってPCカード同梱版を買っちゃったのかと思ったけど、箱にもそんなことは書いていないし、もちろんPCカード本体も入っていない。保証書だけ入れ間違えたのか。まさか保証書はどの機種もみんなまとめて同じものを入れているってことはないよな。

2004/2/8

ひとまずふつうに使えている。128ビットWEPキー＋SSIDステルス＋MACアドレス制限で。設定ユーティリティはいろいろ親切設計っぽいけど、わかっている人間がやりたいことだけやるには逆にわかりにくいかも。会社で設定したメルコのb/g対応ステーションの方がやりやすかった。

ちなみに最初はgで使っていたんだけど、試しにaにしてみたら、間に障害物が挟まる寝室でもふつうに使えたんで、今はaモードで利用中。aの方が反射・回り込み系に弱いって聞いていたけど、それほど気にすることもないのかな。ちゃんと54Mbpsでコネクトする。

うちの周辺は垂れ流し無線LANが多くて、しかも同機種を利用している人（デフォルトSSID名でわかる）までいるんで、設定時にとってもじゃまくさかった。どうやらノーセキュリティの人もいるらしくて、Windowsがそっちのステーションを先に見つけちゃうと、「つなげる？」といちいち聞いてくるのがうざい。

_ LANDISK HDL-160U

2004/2/8

ネットワーク周り以外は何も設定せずに使っているだけなんで、本当にただのネットワークドライブだ。そのうち暇なときにでももうちょっといじるかもしれない。

普段はほとんどアクセスしていないんで、その場合は完全にファンもHDDも止まっていて無音。アクセスするとちょっとタイムラグがあってから動き出すけど、それでもHDDの回転音がかすかに聞こえるくらいでとても静か。静粛性は問題なし。俺の用途では十分な性能かな。ともかく普段存在が気にならないってだけで十分だ。

2004/2/4

データ移行＆バックアップ用に購入。BUFFALOの似たような製品（ちょっと安くて、確かファンレス）とどっちにしようか迷ったけれども、インテリジェントコントローラでファンやHDDの回転を止める機能がついているというこっちを選んだ。前にしばらく動かしていた家サーバーの動作音のうるささに（結構静かな機種を選んでいたにもかかわらず）うんざりしていたんで、少しでも安定して静かそうなものを狙って。まだ動かしていないんで、続きは後で。

[ツッコミを入れる]

2004-02-06 [長年日記]

_ erogmap (13:51)

2004/2/7

なるほど、blogmapの既存のDBではエロゲ分野はカバーし切れていないから、ってのが主な理由なんですね。最近のエロゲ事情＆Amazonのゲーム系のカバー度合いはよくわかっていないんで、その辺わかっていませんでした。

ちなみにblogmapでも、本当は「ISBN/ASINコードを持たないメディア」に対してキーを発行する仕組みを用意したいのですが、妥当な仕組みが思いつかないので放置中です。

ポイントは「そのメディアは本当に（将来的にも）ISBN/ASINコードを持たないのか」と「もしも将来的にISBN/ASINコードを持った場合に、独自発行のキーとISBN/ASINコードを確実に（自動的に）リンクさせる手段があるのか」というあたり。

2004/2/6

>>blogmapにエロゲのTrackBackを送るのもなんだかなぁ、というところが主動機。

いや、blogmapにエロゲのTrackBackを送るのは全然無問題なんですが、そうやってジャンルに特化した情報集積サイトってのも良さそうですね。blogmapにもメディア系ジャンル別ランキングとか作ろうかな。Amazon Web Serviceの現在のAPIを考えると、リアルタイム集計はかなりきつそうだから、週間とか月間程度か。あれ待てよ。Amazonからジャンルなんて情報とれたっけ？

[ツッコミを入れる]

2004-02-07 [長年日記]

_ Bulkfeeds: Similarity Search リリース from blog.bulknews.net (13:51)

>>Bulkfeeds で「似たBlog記事を検索」する Similarity Search をリリースしました。

「そのうち遊ぼう」用メモ。単に使うだけなら記事ごとにリンクを張るなり、JavaScript呼び出しを埋め込めばいいんだろうけど、せっかくならばRSSで取得してこっちでいじって遊びたい。たとえば、うちの最近の記事一通りに対して、似た記事をRSS経由で取得して、スコアでソートして、動的にサイト単位での「関連記事一覧」を作り出したりとか。って思ったらRSSでは各記事のスコア（類似度）はとれないのか。まあ単純に各記事のTrackBack/コメントに混ぜて表示する（関連記事一覧という意味は同じだから）ってのもありかな。

_ はてなダイアリーキーワード自動リンクAPI from はてなダイアリー日記 (13:51)

2004/2/24

現在の先っちょはunoさんの上記版らしい。全然追随できてないんだけど、そのうち試そう。

2004/2/7

>>はてなダイアリー外のアプリケーションにおいて、はてなダイアリー内と同じく、キーワードの自動リンクを可能とするためのAPIを試験公開しました。

これも「そのうち遊ぶ」用メモ。これも単に記事単位でヒットしたキーワードへのリンクを並べるだけなら簡単なんだよな。うちの場合はすでに自前のキーワードリンクを持っているんで、記事内にはてなキーワードへのリンクを埋め込むってのはしないけど。

ただ個人的には、Perl用正規表現の形式での配布よりも、純粋にキーワード一覧として（正規表現用エスケープなし＋改行区切りとかで）配布してもらえた方がうれしいな。その方が使い道の幅が広がりそうだし、自分でそれを正規表現用文字列に加工するのは簡単だし。

2004/2/17

むぅ。なんか思ったより手軽に遊べない。俺のローカルPHP環境ではこの巨大な正規表現の固まりは直接コンパイルできない（preg_**関数レベルでメモリ不足になるっぽい）でやんの。しょうがないから、適当に（特殊なキーワードを登録されたら通らなくなるけどまあいいか）キーワード単位でばらしてから利用することに。あと、短すぎるキーワードは嫌いなんで、ついでに指定文字数（デフォルトはマルチバイト含めて3文字）より短いキーワードは無視。とやってもまだすげー時間がかかるよ。ここのシステム上に組み込もうと思ってたけど、単語単位でばらし終わった後の正規表現のマッチングだけで10秒以上かかるとなると、とてもオンラインで実行する気になれないなー。新しいキーワードの取り込みから始めると余裕で1分近くかかるし。もっと高速化する姑息な手段を考えるか、それとも遅くても使えるような使い道を考えるか。

以下サンプルコード。使いたい人はもうちょっと確実度が高いように（エラーハンドリングとか排他制御とか）自力で改造して使うが吉。最近よくはてな関連落ちてるしね。

$hkw =& new CHatenaKeyword();
$url = 'http://mylog.ishinao.net/';
$results = $hkw->getMatchedList(file_get_contents($url));
foreach ($results as $keyword) {
   echo '[<a href="http://d.hatena.ne.jp/keyword/'.urlencode($keyword).'">';
   echo htmlspecialchars($keyword);
   echo '</a>]';
}

class CHatenaKeyword {
   var $_cacheFile;
   var $_keywordUrl;
   var $_cacheTime;
   var $_rawKeyword;
   var $_keywords;
   var $_sizeLimit;

   function CHatenaKeyword() {
       $this->_cacheFile = 'keywordlist.txt';
       $this->_keywordUrl = 'http://d.hatena.ne.jp/images/keyword/keywordlist';
       $this->_cacheTime = 60*60*24;
       $this->_sizeLimit = 3;

       if (!$this->_loadKeywordList()) {
           $this->_loadNewKeyword();
           $this->_saveKeywordList();
       }
   }

   function _loadNewKeyword() {
       $this->_keywordText = file_get_contents($this->_keywordUrl);
       $this->_splitKeywordText();
   }
    
   function _saveKeywordList() {
       $fp = fopen($this->_cacheFile, 'w') or die;
       fwrite($fp, serialize($this->_keywords));
       fclose($fp);
   }

   function _loadKeywordList() {
       $fileinfo = stat($this->_cacheFile);
       if (time() - $fileinfo['mtime'] > $this->_cacheTime) {return false;}
       $this->_keywords = unserialize(file_get_contents($this->_cacheFile));
       return true;
   }

   function getMatchedList($text) {
       $results = array();
       foreach ($this->_keywords as $pattern) {
           if (preg_match($pattern, $text, $matches)) {
               $results[] = $matches[0];
           }
       }
       return $results;
   }

   function _splitKeywordText() {
       $this->_keywords = array();
       $keywordText = preg_replace('/([^\\\])\|/', "$1\n", $this->_keywordText);
       foreach (split("\n", $keywordText) as $keyword) {
           if ($this->_sizeLimit != 0) {
               $str = str_replace('\s', ' ', $keyword);
               $str = str_replace('\\', '', $str);
               if (mb_strlen($str) < $this->_sizeLimit) {continue;}
           }
           $this->_keywords[] = '/'.$keyword.'/';
       }
   }
}

2004/2/17 その2

チェックしたいテキストを入れて「はてなキーワード抽出」すると、そのテキストに含まれるキーワードリンクを表示してくれる。高速化のために文字数制限を4文字にした。

2004/2/19

高速化版がでましたよ。このくらい速ければいろんな用途に使えそう。

※うが、なんか俺の環境では動かないな。コードを読まなきゃだめか。

_ リンクの拒否権 (13:51)

2004/2/8

「ゲストブック認証＋閲覧者数制限によるアクセス制御」へのネタ振りとして4年前の文章を再掲載しただけなのに、こっちの方にばかりアクセスが集中する（via 個人ニュースサイト系）のはなんかいやだなー。あくまでもこれは、4年前の段階での考察なんですからね、一応。まあ「ゲストブック認証＋閲覧者数制限によるアクセス制御」は技術論なんで技術者以外は楽しくないかもしれないけど。

2004/2/7

最近いろいろ話題になったネタについて、4年前に書いた（http://ishinao.net/ruins/text/01.htm#20001025224346）文章を発見したので、こっちにも転載しておこう。これからさらにいろいろ考察は進んでいるんだけど、核となる部分はこの文章にだいたい含まれているので。以下転載。

2000/1/7

リンクに拒否権はあるのか，あるいは拒否権というものが必要なのか？

リンクを拒否したいと考える人は，リンクされることによって自らに不利益を被る可能性を，拒否したいのだろう。自分にとって好意的な言及とともにリンクされるのはかまわないが，自分に対して批判的だったり悪意を持った言及を伴ったリンクはされたくない，という話だ。

確かに，リンクされることによって不利益を被る場合はあり得る。自分（の書いた文章）に対するネガティブなコメントとともにリンクされることによって，Web社会（ってのも曖昧な言葉だが）上に自分の悪評が広まるかもしれない（もちろんその批判があまりにも的はずれな場合は，リンクをした方の悪評が広まるだろう）。

これはたいていの場合，そのような批判されうる文章を書いたことに対する真っ当なつけを払わされている（という表現はあまりにもネガティブか。「発言の責任をとる」と読み替えても可）だけのようにも思える。

しかし，もしかしたら先入観無しで読んだ場合は特に問題のない文章でも，ネガティブなコメントという意識誘導を伴うことにより，本来よりも不当な悪評を生じうるかもしれない（仲間意識ってものが目の鱗となり理屈をねじ曲げてしまうことは，世の中珍しくない）。

また，自分にネガティブな印象を持った人間のアクセスが増えることによって，掲示板やメールなどで自分を攻撃する人間が増える，という不利益もあり得る。

これも基本的には自業自得の範囲内の出来事ではあるが，作者本人にとって不利益であることは間違いないし，先ほど挙げた意識誘導によって，本来の賛否両論バランス以上に不当な攻撃が増える可能性もあり得ることを考えると，そうそう自業自得とばかりは言っていられない。

しかし，不利益を被る可能性があるからという理由だけで，リンクを拒否できるものなのだろうか？

Webに限らず一般的な著作物（と言った場合，主に一般に流通する出版物を念頭においている）は，著作権法によって守られている。一般的な著作物の引用においてもWeb上のコメント付きリンク同様に，著作者が不利益を被る可能性はありうる。その不利益の内容もほとんど同じだろう。

一般的な著作物においては著作権法によって，第三者による引用が権利として認められている。「公正な慣行に合致するものであり、かつ、報道、批評、研究その他の引用の目的上正当な範囲内で行われるもの」であるならば，権利者の許諾なしで引用することが可能だ。ただし「著作物の出所を、明示しなければならない」という義務がある。

Webにおけるリンクは，引用の延長として考えることができる。「その出所を明示する」という条件は，もちろんリンク先のURLが明記されているので問題ない。「引用の目的上正当な範囲」というのは，要するに引用文が主であってはならない（引用文が主ならば，それは言及のための引用ではなく，ただの複製（コピー）になってしまう）ということだ。コメント付きリンクの場合は「引用文がゼロである引用」と考えることができる。Webでは引用元の参照が簡単にできるため，引用文を完全に省略することが可能なわけだ。

と考えると，一般的な著作物において第三者による無許可の引用が認められているのと同様に，Web上での第三者による無許可の引用と，その延長にある無断リンクは著作権法的に認められるものと考えられる。

だとすると，多少の不利益を被る可能性があるからといって，著作権法に明記された権利を制限していいものとも思えない。

発言する権利の裏にはその発言に対する批判を受ける義務が生じるのであり，自分の快不快の問題で義務を放棄するのは無責任すぎるのではないだろうか。

ただし，上記の議論はWeb上に公開された著作物を，一般的に「公表された著作物」とまったく同様に扱うという前提の上に成立している。では，その前提が本当に成立するのだろうか。

「Web上に公開された著作物は，一般的な著作物と同様に扱われるべきだ」とする人の主張は，おそらく「世間一般に公開されるWebというメディア上に自分の意志で掲載したのだから」という，発表メディアの機能から逆引き的にその一般性の根拠を見つけだしているのだと思われる。

わたしも基本的には同感なのだが，いくつかの異論も持ち合わせている。その第一としてあげられるのは，「掲載した人間の意図として，どこまで一般的な著作物として発表したかどうか」の問題だ。

Web上に公開された著作物は，他の一般的な著作物よりも，非常に手軽で私的な著作物であることが多い。多くの個人Webページは，著作者一人の手で執筆・編集・出版がなされている。またその制作にかかる日数も非常に短い。

Webにおける著作物は，世間一般に公開されるWebというメディアの一般性の強さに比べて，その制作に関してはあまりにも私的個人的な部分が大きい。

また，制作者による仮想読者の設定に関しても，おそらくは非常に狭い範囲を想定している場合が多いだろう。また実際問題として，その読者数は多くの場合ほかの一般的な著作物よりも非常に少ない。

第三者によるチェックを受けることなく，ごく個人的な作業によって制作・発表され，それをごく少数の人間が見る。そして作者本人が，そういうものだという前提で制作している。それがたまたま一般性の高いメディアに掲載されたからといって，世間一般に発表されたと言い切っていいのだろうか。

たまたま一般性の高いWebというメディアを使っているが，その読者対象としてはごくごく身内の人間だけを対象にしているつもりの，作者本人は一般性を意識していないWebページというものは少なくない。そのようなWebページをも，まったく一般的な著作物と同様に扱っていいのだろうか。

そのような私的な著作物は，一般に公開されるWebというメディアに掲載するな，という反論はあるだろう。

しかし，Webというメディアはある程度人数の多い内輪の話をするには，とても便利なメディアだ。それよりも便利なメディアが見あたらないのだったら，Webを内輪の話をする目的で使うのはありだろう。

ならば，アクセス制限などでロックをかけろ，という人もいる。

しかし，Webに著作物を掲載するだけならば，その技術的な敷居は非常に低くなっているが，それにアクセス制限をかけるという技術的な敷居はまだまだ高い。手軽で便利だからという理由でWebを使っている人ならばなおさら，アクセス制限という技術を身につけるのは難しいだろう。

この議論について考える場合，わたしは道ばたで会話している人とその周囲を通り過ぎる人の光景を思い浮かべてしまう。

道ばたで会話している人たちは，周囲の人にも聞こえるような声で話している。別に周囲に聞かせたいわけではないが，お互いにしか聞こえないような小さな声で会話をするよりも，周囲にも聞こえる程度の大きな声で話した方が手軽だからだ。

しかし，話している内容がそばにいれば聞こえるからといって，わざわざ聞き耳を立てている人がいる。そして，会話の途中で気に入らない内容があったからといって，突然会話に割り込んで文句を付けはじめる。

よほど犯罪性のあるような問題のある発言をしていたのだったら，まあそれもありだとは思う。しかし，多少問題があったとしても聞き流しておくのが，ふつうの対応だろう。

とはいうものの，やはりわたしは，基本的にはWebは公開されているメディアであるので，そこに著作物を掲載する場合はその著作物に対する批判を受ける義務が生じる，という立場を取る。

そのあたりは，田舎と都会の違いのようなものだ。

田舎では家の鍵などいつでも開けっぱなしにしており，身内の深い話なんかもご近所で簡単にしゃべってしまったりする。一方都会では，基本的に親しい人間以外は信じない方がいい。ちょっと外に出るときにも家にはきっちり鍵をかけないといけないし，人が訪ねてきても簡単にドアを開けてはいけない。身内の話を外部に漏らしたら，それを悪用されるリスクを考えなければならない。

究極を突き詰めれば都会の方が正しいのだろう。しかし，多少いい加減でもそれなりにやっていける田舎の生活は，実際問題としてそういうコミュニティとして成立しているのだから，それはそれで問題ない。

ただし，田舎の生活もいずれは都会のように変わっていくものだ。どんな田舎に行っても家には鍵がかかっており，訪ねてきた人を簡単にドアを開けて迎え入れるということがなくなるときが，いつかはやってくる。

それならば，現状は現状として容認しつつも，将来のための心構えは啓蒙しておいたほうがいい。

蛇足だが，Webの今後の発展を考えると，パブリックなWebページとプライベートなWebページを簡単に使い分けることができるインフラを整えていく必要があるだろう。現在実現可能なアクセス制限のような不便な仕様ではなく，もっと洗練されたアクセス制限の手法を考え出したら，一財産築けるかもしれない。

追記） 一行コメント付きメールで「リンクの拒否権とアクセス制限の問題をプライバシーの観点から考えています。公開する方向と範囲をコントロールしたいという欲求があるのではないかと思っています。」というコメントをいただいた。

「公開する方向と範囲をコントロールするためのアクセス制限」というのは面白いテーマだ。プライバシーについての考察は今回は意図的に省略したのだが，今から考えるとやはり絡めて考えた方が良かったようにも思える。

このネタは，まだまだ考察をする価値があるテーマだ。いずれ続きを書こう。

_ ゲストブック認証＋閲覧者数制限によるアクセス制御 (13:51)

微妙に補足説明を追加してます。

で、「リンクの拒否権」（http://mylog.ishinao.net/id/1129）の最後に出てきた、「パブリックなWebページとプライベートなWebページを簡単に使い分けることができるインフラ」に関する考察を進めてきた結果、「ゲストブックとRURIコードによるアクセス制御」（http://mylog.ishinao.net/id/1096）と「記事ごとに読める人の人数を制限できる仕組み」（すみません。どこで読んだのか忘れてしまいました）を組み合わせた、現在の私が考えつく、もっともバランスのいい匿名のままに認証＆アクセス制御する仕組みについてまとめてみる。

まず、アクセスしてきた閲覧者（ブラウザ）にランダムなIDを振り、Cookieに登録する。次回アクセス以降、CookieにランダムIDが存在した場合はそのIDを利用し、存在しない場合にのみ新しいIDを割り振る。IDは重複することが（論理的に実用時間内には）なく、閲覧者（ブラウザ）を一意に認識するためのIDとして利用できる。+[また十分に複雑なランダム性を持つIDなので、他人のIDを類推することは不可能である。]+そのIDのことを、この考えの元ネタであるHNS（Hyper Nikki System）での呼び方に準じて、ここではRURIコードと呼ぶ。

RURIコードを使うことによって、閲覧者を匿名のままに区別して扱うことが可能になる。閲覧者にID、パスワードの管理や入力という手間をかけさせることがない。ただし、Cookie盗難には十分注意する必要がある。

続いてゲストブック（記名帳）を用意する。ゲストブックとは、閲覧者がサイト管理者に対して、自分が読者であることを表明するための投稿フォームである。ゲストブックへの登録の際には自動的にその閲覧者のRURIコードも記録される。ゲストブックに登録した人（RURIコード）は、「GUESTグループ」に加えられることになる。

またこのゲストブック登録の段階で、メールによる自動認証（登録されたメールアドレスにシステムがワンタイムパスワード付きメールを送信し、そのパスワードによって正当なメールアドレスかを自動確認する）などをシステムに組み込むことができる。そのシステムを適用する場合は、ゲストブックに登録しただけの閲覧者を「弱いGUESTグループ」、その中でメールによる自動認証をすませた閲覧者を「強いGUESTグループ」に加えるなど、2段階のグルーピングを適用することもできる。ただしここではできるだけ話をシンプルにするため、1段階のGUESTグループを適用することにして話を進める。

ゲストブックは原則として管理者にのみ公開される。そこで、そこには管理者以外には知られたくない情報を記述することもできる。たとえば「○○高校で同級生だった○○だよ」みたいに個人情報を含んだ内容も登録でき、それによって管理者はあるRURIコードの持ち主が誰なのかをより正確に判別することができる。当人同士しか知らないはずの情報を含ませるほど、本人確認の厳密さが高まるだろう。

管理者は、ゲストブックに登録した人の中から自分が選んだ人を、「FRIENDグループ」に昇格させることができる。単純にゲストブックの書き込み1件ごとに対して、グループ昇格ボタンなどをクリックするような形だろう。

ここでも実際には、ごくごく親しい知り合い用の「強いFRIENDグループ」、それ以外の知り合い用の「弱いFRIENDグループ」のような複数の段階のグルーピングを行うこともできるが、ここでは話を単純化するために1段階のFRIENDグループを適用することにして話を進める。

以上のグループに含まれていない閲覧者は、「ANONYMOUSグループ」に含まれることとすると、閲覧者は「ANONYMOUS（見知らぬ読者）」、「GUEST（登録読者）」、「FRIEND（知り合い）」という三つのグループに分けられることになる。

ANONYMOUSに関しては完全な自動登録となるし、GUESTに関しては閲覧者のちょっとした作業のみで登録が行われる。FRIENDに関してはさらに管理者のちょっとした作業が必要になるが、規模がよほど大きくない限りはそれほどの手間ではないだろう。といった程度のコストで、閲覧者をそれなりに妥当な権限グループに振り分けることができる。また、この程度ならばそれほど技術に詳しい人でなくても、仕組みを理解することができるだろう。

続いて、このようにグルーピングした閲覧者に対して、どのように認証および制限を加えていくか。

システム自体の設定としては、まず閲覧者からのリアクション機能に関する設定がある。具体的にはコメント機能やメールフォーム機能を、どのグループのユーザーに対して公開するか。ゲストブックにURLも登録されているのならば、そのURLとのマッチングによってTrackBackに対する認証を行うことも可能になる。

比較的内輪向けのサイトならば、コメント機能はFRIENDのみ、メールフォーム機能はGUESTとFRIENDのみ、といった感じになるだろうか。オープンなサイトならば、すべての機能をANONYMOUSにも使わせればいい。

あるいは、許可したグループにのみリアクション機能を使わせるのではなく、他のグループにも投稿だけは許可するが、その内容をサイト上に掲載するかどうかは、管理者が決定できるようにすることもできるだろう。+[いわゆる、管理者がチェックしない限りはWeb上に投稿が掲載されない掲示板システムと同様の仕組みだ。]+

続いて公開範囲および規模の設定を、記事単位で行うことができる。基本的には、どのグループに対して何アクセスまで公開するかを設定することになる。

たとえば内輪向けの記事ならば、FRIENDに対してのみ無制限アクセスを許可（許可アクセス数=-1）し、GUESTやANONYMOUSに対してはアクセスを拒否（許可アクセス数=0）すればいい。その記事は知り合いのみが閲覧することができるようになる。

また、ある程度は一般に公開してもいいが、あまりリアクションが多くなることを恐れるのならば、たとえばGUESTには「許可アクセス数=100」、ANONYMOUSには「許可アクセス数=10」などと設定しておく。すると、GUESTグループに所属する人が100回アクセスすると、それ以降訪れたGUESTグループの人には「現在公開が停止されています」などのアナウンスが表示されるようになる。同じくANONYMOUSグループの人は10アクセスまでしか閲覧することはできない。

ちなみに、このような制限を施している場合は、（システム的に）その説明を明示しておいた方がいいだろう。

「この記事は友達登録を行った人にのみ公開しており、それ以外の方は閲覧できないようになっています。友達登録を行いたい方はゲストブックからご登録ください」

あるいは、

「この記事は100人にまで閲覧を許可しています。それ以上の閲覧者が訪れた場合は自動的に公開が停止されます」

などと提示しておく。それによって、その記事の公開範囲・規模が閲覧者に伝わり、その結果背景にある管理者の意図が、ある程度閲覧者（あるいは閲覧できない人）に伝わることになる。

もちろんこのように閲覧者を制限したところで、誰かがその記事の内容を引用したり転載したりすることによって、ネット上に広まっていってしまうことはある程度はさけられない。しかし、現状の管理者の公開意図がほとんど伝わらないシステムと比べると、ずいぶんとましな状況になるのではないだろうか。

以上の仕様では、特に難度・コストが高い技術は使っていないので、一般的なWeb技術者ならば比較的簡単に実装が可能だろう。また、細部に関しては様々なカスタマイズの余地もあるので、利用するサービスに応じて適切に応用してもいい。

[ツッコミを入れる]

2004-02-09 [長年日記]

_ InterWikiPoweredByGoogle (13:51)

2004/2/9 その2

ちょっとだけ試してみたら、「WikiName site:登録WikiサイトURL」だとドメインを持っているWikiサイトしか対応できないんで、「WikiName site:登録Wikiサイトドメイン 登録WikiサイトURL（共通部分）」にしないとだめっぽいな。

たとえばうちのpukiwikiでblogmapを探す場合は、「blogmap site:ishinao.net http://ishinao.net/pukiwiki/」（http://www.google.com/search?q=blogmap%20site:ishinao.net%20http://ishinao.net/pukiwiki/）なんて感じ。

2004/2/9

>>Wiki同士の連係がもっと容易になったら便利だとは思いますが。 とかその前の日のコメント（http://sheepman.parfait.ne.jp/20040207.html#c）あたりがネタもと。

あるWikiNameがある。そのWikiNameに対して、Google Web APIを使って、「WikiName site:登録WikiサイトURL」というQueryを投げる。登録WikiサイトURLってのは、InterWikiの設定みたいに連携したいWikiサイトを登録しておいたもの。

Google Web APIの検索結果として返ってきたリストから、ページタイトルにパターンマッチして、それぞれのWikiサイトに該当WikiNameが存在するかどうかを確認する。存在したら、接続用の適切なインターフェース（表示、編集）を用意するなり、強引にGETでページ内容を取得して使っちゃうなり（著作権的に微妙だけど、Wikiならばまあいいか）。RSSがauto-discoveryできたらそのdescriptionを取り込んじゃう程度が一番無難かな？

とかやると、GoogleのDBを使ってInterWikiより濃い目のWikiサイト間連携が実現できるかも。InterWikiPoweredByGoogleと名付けてみよう。

_ 匿名性を保持したアクセス認証のニーズ from kera-ma-go (13:51)

「ゲストブック認証＋閲覧者数制限によるアクセス制御（http://mylog.ishinao.net/id/1130）」への反応。

>>「メールアドレスが分かっているだけの常連さん」に対してそのようなトピックを公開しようとは思いません。身元の分からない相手を非公開情報の公開ターゲットにしたいというニーズがどのくらいあるだろうということには正直疑問を感じます。

「メールアドレスが分かっているだけの常連さん」は「（強い）GUEST」グループ扱いになります。さらに身内度の高い「FRIEND」グループというものを用意しており、その認証の仕組みとしては「ゲストブック登録時に当人同士しかわからない情報を含める」という提案をしていますので、上記に関しては「FRIEND」グループを利用すればいいのではないかと思います。

「FRIENDとGUESTを使い分けるニーズがどれだけあるかわからない」というのでしたら、私にもそれはわかりません。もしかしたら、FRIENDとANONYMOUSだけでいいのかもしれませんし（DI:DOと同じ分類になりますね）、その場合は仕組みをもう一段シンプルにすることができます。

ただ私個人としては、Webにおいては「FRIEND」と「ANONYMOUS」の間に広がる空間（人間関係）を表現することに、大きな可能性を感じています。その部分に、ネットワークにおける人間関係に関する大きな可能性が隠されているのではないか。まあ、そんなものはないのかもしれませんが。

ちなみに「匿名のままに」というのは必ずしもアクセス制御の対象全員が「匿名である」ことを意識しているのではありません。「知り合いも見知らぬ読者も、匿名認証という共通の枠組みの中で取り扱えるようにする」ということです。

たとえばDI:DOでは、アクセス制御対象となる閲覧者には必ず最低限の登録作業（読者登録）およびDI:DOサービス用のID・パスワードの取得を必須としていますが、その作業に伴って、

  1. 閲覧者（読者）登録を行う（ある程度の個人情報をインターネットに流す）
  2. DI:DO向けのID・パスワードを用意する（ID・パスワードを用意すること自体がセキュリティリスクになる。人はたくさんのID・パスワードを覚えられないので、他のID・パスワードと同じもしくは類推可能なものを使いがち）
  3. 認証時に入力する（上記2の論点より、そのID・パスワードの重要度・危険性は、そのサービス内のみならず、その人が管理するID・パスワード一般にまで広がる可能性がある。そのようなID・パスワードを使う機会が増えるほど、その漏洩リスクが高まる）

といったような（括弧内で書かれたような）リスクを思いつくことができます。

そのリスクが実際にどの程度の大きさなのかは、サービスの内容やユーザーの意識によって違ってきますが、もしもリスク自体をなくしてしまうことができるのならば、それに越したことはないでしょう。

というところが、ユーザーを匿名のままに（ID・パスワード登録およびそれを使った認証なしで）アクセス制御を行うシステムの有用性（上記における2と3をなくす）だと思います。ID・パスワードのようなものは、使わなくてすむのならばできる限り使わない方がいい、という提案です。

もちろんそれによって新たに生じるリスクも存在するでしょうから、（すぐに思いつくのはCookieへの依存性が高すぎることから生じるリスク）もしかしたらここで提案しているシステムの方が、一般的なユーザー登録＋ID・パスワード認証よりもトータルでのリスクが高くなる可能性がありますが。

>>ただ、この「匿名のままにアクセス認証する」というシステムは、逆に匿名のままアクセスを弾くという用途では有用なのかもしれないとふと思いました。

「アクセス制御」なんで、もちろん許可する方にも拒否する方にも使うことを想定しています。前回は触れませんでしたが、もちろん特定のRURIコードを「BAN（アクセス拒否）」グループに追加するなどといった運用もあると思います。

ただしアクセス拒否に関しては、くりすさんの言われるような偽装行為で容易に回避できるため、単にBANグループに入れるというだけでは実効性が低いだろうとも思っています。単に「拒否されています」ではなく、何らかの穏当な表現によって相手にメッセージを伝えることができれば、それなりに有効な対処方法になるかもしれません。

ちなみにRURIコードを使えば、匿名の相手に対してRURIコードを指定してメッセージを送ることができます（いわゆる私書箱系か。今はなきIch（仮）でも採用していた）。アクセスログなどから何らかの不審な行動（アクセス）を行ったと思われる人に対して、直接メッセージを送ったり1対1で会話をしたりすることも可能でしょう（相手が再度アクセスしてくれば、ですが）。

結局のところ相手は人間ですから、人間を相手にどれだけきちんと（発信者の）意図を伝えることができるか、そしてそれに納得してもらうことができるか、というのがもっとも重要な点となるでしょう。

「ゲストブック認証＋閲覧者数制限によるアクセス制御」で提案しているシステムは、Webで情報を公開する人間の意図をうまく表現（コントロール）するためにはどのようなインフラが必要なのか、について考えた結果の一提案であり、あくまでも「インフラ」レベルの提案（具体的な実装はサービスによる）にすぎません。

[ツッコミを入れる]

2004-02-10 [長年日記]

_ blogmapのゴミ掃除プロセス (13:51)

そろそろまたblogmapのURLリスト巨大化が始まったんで、ゴミURL掃除プロセスを作成。DB初回登録時から30日以上経っても、そのURLを利用するサイトが現れない場合（要するに一つのサイトしか使わなかったURL）は、削除するようにした。そういうURLがDBの約1/3を占めていた模様。ただ、そのついでに各プロセスのバランスを調整したら失敗してしまい、デッドロック地獄にはまってしまったんでサーバーを強引に再起動。依存関係がややこしいプロセスをパラレルに動かしているんで、ロジカルにデッドロックが起こらないようにはできないんだよなー。MySQLって、temporary tableをファイルに作成するプロセス（ちょっと複雑なjoinをしているもの）が異常に遅くなるんで、そのタイミングで関連tableに触るとlockがかかってしまい、そこにlow priorityな命令が混ざるとデッドロック地獄に落ちてしまう。だいたいindexをちゃんと見てくれれば、全行くっつけるような巨大なtemporary tableなんて作らなくてもいけるように作ってあるはずなのに、なんでindexで絞ったjoinのたびに巨大なtemporary tableを作っちゃうんだろう。

[ツッコミを入れる]

2004-02-11 [長年日記]

_ eBayに「中傷投稿削除の義務なし」 from ITmedia (13:51)

>>米カリフォルニアの控訴裁判所が、「eBayは、自社のオークションサイト上に虚偽あるいは名誉棄損の疑いのある情報が掲載されても、それを削除する義務はない」との判断を示した。

>>同裁判所は2月5日、1996年の米通信品位法（CDA）に合わせて、eBayや同様の「双方向コンピュータサービス」企業を保護する目的で制定された連邦法を引き合いに出し、フィードバックのコーナーに掲載された情報が中傷的だからだと訴えられても、eBayはその情報を無理に削除する必要はないと判断した。

アメリカの話だけど、こういう判決がでたんだそうな。インタラクティブなサービス上でのユーザー同士の争いにおけるプロバイダの責任範囲をかなり明確化する判決だな。

それにしても、“「双方向コンピュータサービス」企業を保護する目的で制定された連邦法”があるなんて、さすが日本よりも法整備が進んでいるなー。

ちなみに該当の条文は、以下だそうな。

インターネットを利用したインタラクティブなメディアの技術的な進歩、および、それらをユーザーが自らの手によってコントロールできる可能性を阻害しないための法整備ってのは、日本でも考えられていいんじゃないか。危険からユーザーを保護するための法律（不正アクセス禁止法とか個人情報保護法とか）ばかりだと、考え方がなんだか後ろ向きになりすぎる気がする。

[ツッコミを入れる]

2004-02-12 [長年日記]

_ mysqldumpが固まる (13:51)

2004/2/12 その2

念のため冗長に持っていたデータをすべて削除するように変更＆過去のデータはすべて削除。これで何か異常が起きても手元のデータで復帰することは不可能になったけど、もう一回収集プロセスからやり直すなり、失敗したデータは「なかったことにする」なりで対処すればいいか。クリティカルなデータってわけじゃないし。ともかくこれでDBのデータサイズが半分以下まで削れたんで、DB周りの不具合（時間がかかるプロセスが原因となってロックしたり落ちたりする）が減ることでしょう。あとhttpdのプロセス数も減らしてしまった。メンテナンス性を高める＆仕様変更を柔軟に実現するために、httpd主導でリスト生成・更新（というかキャッシュコントロール）を行っているんだけど、このくらいデータ量がでかくなってきたら、負荷コントロール重視で、重い処理はバックグラウンドプロセス主導で行った方がいいんだろうなー。でもblogmapなんてしょせん俺の遊びの道具を一般開放しているにすぎないから、一般開放を安定して行うために俺の遊べる余地を減らすってのは、俺にとっては本末転倒なんだよなー。

2004/2/12

今朝、毎朝行っているDBバックアッププロセスが途中で死んで、そのままサーバーの主な機能がほとんどお亡くなりになっていた。手動でmysqldumpしても死ぬってことは、DBのファイルのどこかが死んでいるのか。ちょっとまずそうな予感。

[ツッコミを入れる]

2004-02-13 [長年日記]

_ オンドゥル語のこつがわかった (13:51)

オンドゥル語系リンク集

なんかGoogleで「オンドゥル語」のトップになっちゃっているんで、もっと楽しいサイトへアクセスを流してみる。

2004/2/13

オンドゥル語がなんなのかは、わかる人だけわかればいいので説明は略。

日々オンドゥル語の練習をしているうちにこつがわかってきた。発音するときに「ダ」行の音を同時に発音するとかなりいい感じになる。たとえば「ほんとにうらぎったんですかー」には「どんどでぃどぅだでぃっだんでどぅだー」を、「うそだそんなことー」には「どぅどだどんだどどー」を重ね合わせてる感じで。

ただ二つの音を同時に発音するのは、オンドゥル語の達人にならないとうまくできない。日々精進（するな）。

[ツッコミを入れる]

2004-02-16 [長年日記]

_ 車のバッテリーがあがった (13:51)

2004/2/17

昨日の夜に、新しいバッテリーをつないで10分ほど充電したら、8Vくらいから11Vくらいまで復活したんでそこでエンジン始動。その後30分くらいドライブしてなんとか12Vくらいまで復活させた。一応今朝も12V程度で維持できていた模様。でもしばらくは気を遣ってまめにのるようにしないと危険だな。まあ充電用バッテリーをいつもキープしておくようにしたから、ある程度気は楽なんだけど。

ちなみにブースターケーブルのつなぎ方は、給電元プラス、給電先プラス、給電先マイナス（バッテリーではなく車自体のグランド。エンジンの金属部分とか）、給電元マイナスって順番でいいんだっけ？

2004/2/16

今朝ムスコを保育園に送っていこうと車に乗ったら、バッテリーがあがっていた。うが。もともと電装品をつけすぎていて放っておくとバッテリーがあがりがちな車なんだけど、埼玉に引っ越してからは比較的まめに車を使っていたんで、ここ1、2年はずっと大丈夫だったのになー。バイクのバッテリーはあがりっぱなしで絶賛放置中だけど。

そういや、先週はムスコの体調がいまいちだったんで一週間まるまる保育園を休ませた（＝送り迎えに車を使わなかった）し、週末の買い物も近所で済ませてしまったんで、ほぼ2週間全然車を動かしていなかったのか。あと最近寒いから、朝方はさらにバッテリーのパワーがでにくいってのもあるかも。

そろそろ車検だし、いったんあがってしまったバッテリーをそのままにしておくのもあれだから、新しいバッテリーでも買って交換するか。でもくそ寒い外で作業するのも面倒だなー。予備バッテリーを買ってきて充電してから、近所のパーツ屋で交換してもらおうかなー。

[ツッコミを入れる]

2004-02-18 [長年日記]

_ タカラ、IPv6対応“糸電話”を年内発売 from ITmedia (13:51)

なるほど単機能に絞って、設定はそれぞれのハードウェアに埋め込みでもっておいて、使う人のレベルではとってもお手軽に、って感じか。

このアプローチってソフトウェアでもできないかな。プライベートキーとパブリックキーを二組生成して、それぞれ互いのキーを使わないと暗号化・復号化できない二つのソフトウェアバイナリを用意して、通信レイヤーがそのキーに依存していて、そのバイナリ同士じゃないときちんと通信できないよ、って感じのもの。

ただまあソフトウェアの場合はコピーが簡単だから、この糸電話みたいな感じにはいかないだろうな。とか考え出すと、さらにハードウェアキーと連動させて、特定のマシン上でしか動かないような仕組みにして、とかありきたりのネタになってしまうな。うーん、もう一ネタ欲しいところ。

_ ついにきましたね (13:51)

こいつは確定ですかね。まだひどくはないんですが、鼻の奥が常時むずむずしてますよ。朝起きたときに目やにがついてますよ。ときどき思いがけないくしゃみがでますよ。

今年はちゃんと病院に行こうかな。病院って内科でいいの？　耳鼻科？

[ツッコミを入れる]

2004-02-23 [長年日記]

_ アレルギー科に行ってきましたよ (13:51)

2004/4/15

アレルギー薬の追加3週間分をゲット。処方箋代600円＋薬（タリオン錠10mg）3週間分1350円なり。ちなみにそろそろ今年のシーズンも終わりが見えてきたんで、初めてちゃんと医者に行った感想を書いておきます。

<strong>医者行ってないやつは、ひとまず行ってこい。</strong>

例年だと、早ければ1月後半から5月の序盤まで、スペックが5割程度ダウンするのですが、ちゃんと病院に行った今年は、ほとんど平常通りのスペックで花粉症シーズンを乗り切ることができましたよ。

薬が切れる朝方や夕方あたりなんかには、それなりに（鼻水・くしゃみが）キテいる時間もあったんだけど、ちゃんと薬を飲めばだいたい1時間くらいで治まって、後は何も意識しないで過ごせるようになる。

特に例年だと目がひどくて、ふとした拍子に（痛み・かゆみで）目を開けていられなくなったりしたんだけど、今年は朝起きたときに多少目やにがあるかな程度で、普段目に来るってことは全然なかった。洗眼薬も買っておいたんだけど、一度も使わず。目薬は1、2回使ったけど。

というわけで、結局今シーズン花粉症に悩まされたのは、毎朝起き抜けの1時間程度のみだったかな。あとは花粉がひどい日もひどくない日も、特にマスクなんかなくても全然平気だった。単に今年は花粉が少なかったから、とかだったらいやだな。

2004/2/23

昨日の大風（ってさいたまだけか？）で症状が本格化しはじめたんで、ついに行ってきましたよ。「ついにきましたね」でアレルギー科という存在を教えてもらったんですが、やはりググってみてもうちの近所にはそんなものはなかったので、渋谷近郊で適当に検索。

で、医者には「1年間効く系の強い注射は打つな」「焼却系の治療はするな（鼻の粘膜とかを焼くやつ）」と言われ、「自分がどの花粉に対するアレルギーなのかを知り、花粉飛散情報をまめにチェックして状況を把握しつつ、あまり強くない薬を適当に飲んで、理性でコントロールしなさい」という診断（忠告？）を受け、ひとまず血を抜かれて（アレルギー検査用。結果が出るのは一週間後）、中くらいの飲み薬2週間分とと目薬を処方されてきました。診察代3000円弱、薬代1500円弱って感じ（3割負担）。

さて、今まで5年以上市販の鼻炎薬と洗眼薬で粘ってきたわけだけど、医者にかかった今年は症状の出方がどう違うかな？

2004/2/25

昨日の夜から目のかゆみが発生。朝起きたときの目やにがひどい＆その目やにを取るとかゆみがひどくなるパターン。薬を飲むと4、5時間は効く模様。あと目薬もそこそこ効いている。でもそろそろ洗眼薬も用意した方がいいかな。

2004/3/4

アレルギー検査の結果をもらってきました。結局私の場合は、スギ花粉に対して6段階中3点をとり、立派な花粉症であると認定されました。ただ、ヒノキのほうは0点だったので、今後はスギ花粉飛散情報だけをチェックしていればいいとのこと。診察料600円＋飲み薬だけ3週間分で1500円くらい。薬のおかげか今年は花粉が少ないおかげか、今のところすごいひどい状態にはならないですんでいるな。

[ツッコミを入れる]

2004-02-24 [長年日記]

_ blog map (13:51)

2004/2/26

blogmapに位置情報もサポートさせる仕組み、自前でも何とかなりそうな気がしてきた。地図情報との連携は、URLが素直なマピオンを使えば、緯度経度さえわかればふつうにリンクを張れそうだ。

地名や駅名などから緯度経度情報に変換する部分に関しては、Aries Home Page（http://www.asahi-net.or.jp/~xj6t-tkd/）で公開されている「全国都道府県市町村・緯度経度位置データベース for GPS（2002年版）」と「全国地下鉄駅&出入口・緯度経度位置データベース for GPS」を使えばそこそこいけそう。ライセンスも高くないし。

ただ、ユーザー（各サイト管理者）が記事に位置情報を付加するコストに関しては、どうやってもそんなに敷居が低いことにはならないだろうなー。

場所に関連した記事を書く場合には、

  • 記事中にマピオンの地図へのリンク（URL）が書かれていれば
    • クローリングした際に、マピオン地図URLから自動的に緯度経度を抽出して、blogmapに記録する（サイトURL＋登録日時）
    • その記事をPingProxyに投げてもらえば、そこから緯度経度情報を抽出してblogmapにTrackBackする
  • blogmapのTrackBack Ping URLとして、?q=E***/***/***.***,N***/***/***.***みたいな緯度経度情報用のI/Fも用意しておき、適当な地図サービスで緯度経度を調べてから手動でTrackBackしてもらう

という2つ（細かく分けると3つ）の口を想定しているんだけど、たぶんそんなことをする（マピオンで記事に関連した地図をいちいち検索してリンクを張る）人はとても少ないだろう。

マピオンが、Amazonみたいにリンクを張ることのインセンティブが大きいサイトになってくれると、各サイト管理者がマピオンへのリンクを張る理由ができていいんだけどな。地図掲載店と連携したアフィリエイトとか始めてくれないかな。

2004/2/24

blogmapでblog map（http://d-s-j.net/archives/000428.html）が話題になっているのを見て、blogmapでも地図（位置情報）に対してTrackBackを送れるようにするのもいいかもなーと考えた。blog mapはblogレベルでの位置情報を登録する仕組みらしいけど、本当ならばエントリー（記事）レベルで位置情報を登録できた方が、有用な情報になりえるだろう。

でも実際問題として、一般blogユーザーが手軽に表現可能なエントリーごとの位置情報データってのはなかなかないだろう。コンピュータレベルで妥当な位置情報の表現としては、緯度経度とか、ナビとかで使っているエリア情報とか、あるいは日本国内ならば郵便番号とか電話番号（市外局番）とか、いろいろ考えられるけれども、どれも人間レベルでの使い勝手がいいとは言えないし。

携帯電話内蔵カメラなんかで作れる、位置情報埋め込み写真データの添付を必須にするとかすれば、かなり質が高いデータが集まりそうだけど、いくらなんでも敷居が高すぎて、とても十分な数のデータが集まるとは思えないしなー。

現時点で何とかするとなると、文章から住所とか郵便番号とか電話番号とかを抽出して、それなりに妥当な位置情報にマップする仕組みを考える感じかなー。住所、郵便番号、電話番号を緯度経度情報に変換するロジックってどこかに転がってないだろうか。

2004/2/24 その2

そういやCNETとかbk1とかぽすれんとか、商用サイトでTrackBackをサポートするところが出始めているところだし、電車の乗り換え案内系サービスをやっているところとか、地図情報提供サービスをやっているところとか、すでに位置情報に関連したDB（とUI）を持っている商用サイトが、位置情報に関連したTrackBackを受け付けるようになると、それをベースにした地域情報コミュニティをblogベースで作れそうだな。

どこかやらない？　個人的にはまちBBSのblog版みたいな感じを期待したい。住所（都道府県レベルから、市町村レベルまで）からも最寄り駅からも関連記事を検索できるようだといいな。ミニマムでは地域と種別から検索すると、渋谷のラーメン屋に関する記事が検索できるようになったりとか。

最近そういうことに金をかけそうな企業はどこだ？　一昔前ならばリクルートだったんだけど、今ならlivedoorあたりとかどう？

このセクションに対するはてなブックマーク

_ 納税証明書と久しぶりのバイク (13:51)

そろそろ車検だっつーのに、またも（前回も）納税証明書をなくしてしまっていた。

さいたまに引っ越してからも車は杉並区に登録したままなんで、納税証明書の再交付には杉並区役所までいかなきゃならない。一番行きやすそうなのは（昔住んでいた）永福の出張所なんだけど、電車でわざわざ行くのは面倒くさいんで、天気もいいことだし友達にバイクを借りて行ってみた。

久しぶりのバイクだけど、うちのDJEBEL125の兄弟車種のDJEBEL200なんで、車両感覚は変わらず（といっても、125の方にももう4ヶ月くらい乗っていないし、その前に乗ったのはさらに半年くらい前だ）。非力な125と違って2速、3速の余裕があるんでとても運転が楽。バイク用の上着じゃなくふつうのジャケットだったけど、体は全然寒くなかったな。もう春なのか。さすがに素手はちょっと冷たかったけど、運転に支障が出るほどではない。

ちなみに納税証明書は書類を書くだけで無料だった。特に本人証明とかも必要ない模様。これであとは車検に出すだけか。今回はいろいろあった（車上荒らしとか）んで、車検も面倒なことになりそうな予感。

[ツッコミを入れる]

2004-02-25 [長年日記]

_ スタパトロニクス 俺的携帯電話事情 「MysyncとA5403CAでシアワセに！」 from ケータイWatch (13:51)

上記記事を見てMySync for Bizを買ってしまった。LaVie RXにメインマシンを乗り換えたついでに、昔使っていたCLIEの流れでLinux Zaurusでも使い続けていたPalm Desktopから、Outlook 2003にスケジュール管理ソフトを乗り換えたところだったし、どうせならそのデータを携帯（A5301T）でも連携できるとうれしいかな、と思って。ちょうど対応ケーブルのアイ・オーデータUSB-cdmaも持っているし。

で、ちょっと使ってみたところ、このソフト自体は良さそうなんだけど、A5301Tのスケジュール管理＆ToDo管理がだめだめなんで、あんまり使い勝手がよくなさそうだ。A5301TのスケジュールとかToDoってどうしてメニューのこんな深いところにあるんだろう。ショートカットナンバーを暗記すれば呼び出しまでは何とかなるかもしれないけど、そこから先の使い勝手もいまいちっぽいしなー。なんか新しい携帯が欲しくなって来ちゃいそう。

現状でも結構うれしいのは、データフォルダの管理が簡単にできること。だらだらと取りだめた写真とかムービーって、携帯のUIで管理してられないんだよなー。それをPCに一気に取り込んで、必要なデータはバックアップして、残りはまとめて削除とかできるのはうれしい。これがあれば、SDカードなんかいらないかも。

あとそうやってファイルをPCにコピーしてみて気がついたんだけど、いつの間にやらQuickTimeがau独自のmpeg4ムービー形式（拡張子amc）に対応していたんだね。PCに取り込んだらQuickTimeアイコンで表示されたんで試しに開いてみたらふつうに（音声も映像も）再生された。QuickTimeが3gppに対応していたのは知っていたけど、その派生フォーマットであるamcにまで対応していたのか。

_ 全文検索を利用したサイト間連携 (13:51)

2004/4/15

Estraierにメタ検索インターフェースが標準装備されたんで、試しに自サイト内の複数形式のコンテンツに、それぞれEstraierでindexを作り、さらにそれぞれ用の検索CGIを用意し、さらにそれらをまとめて検索するメタ検索インターフェースを用意してみましたよ。

といった感じで簡単に串刺し検索がかかるようになったことだし、あとは元々の目的だった、InterWikiのように検索機能を使って、複数サイトにまたがったコンテンツを連携させる取り組みにかかろう。

というわけで、Estraierのestsearch.cgi（互換）の検索インターフェースを持つサイト（特にWiki系）募集中。PukiWikiにEstraier検索を組み込む方法は、そのうちドキュメントにでもまとめておこうか。

アプローチとしては3種類くらいあって、

  • ともかくwikiディレクトリでestautoregしてindexを生成し、estsearch.cgiへのフィルターを書いて、妥当な（URLやタイトルを変換した）xhtmlを吐き出すようにする（←うちで採用している方法）
  • ともかくwikiディレクトリでestautoregしてindexを生成し、estxviewでコマンドライン検索（結果はXML）を取得し、その結果を使ってestsearch.cgi互換のxhtmlを生成する（←単にEstraier検索を組み込むだけならもっとも妥当な方法だけど、estsearch.cgi互換にするのが面倒くさそう）
  • pukiwikiデータファイル用のフィルターを書いて、indexを生成する（←これが一番妥当な方法かな？　でもフィルター周りの仕様は全然読んでいないんで、本当に妥当なのかどうか知らない）

って感じ。

2004/2/25

のメタ検索の項にある、

>>メタ検索を多階層で行うことによって、さらに大規模な検索システムを構築することも考えられる。例えば、始めに10サイトに対してクエリを発行し、その10サイトが各々10サイトにクエリを発行すれば、100サイトを対象にした検索が実現できるだろう。インターネット環境で不特定多数のサイトがこのようなクエリの交換を行うと面白いに違いない。

ってのはとても面白そうだ。BulkfeedsのSimilarSearchみたいなものをP2Pで実現するために使えるかもしれない。

まず各サイトがEstraierでの全文検索をサポートしつつ、検索連携用I/Fとしてestsearch.cgiへのURLを公開しておく。さらにInterWikiみたいな感じで、自サイトと連携させたいサイトの検索連携用I/Fも登録しておく。

あるサイトの検索連携I/Fに対してクエリー（検索文字列）を投げると、そのサイトはさらに連携するサイトへとクエリーを投げる。何階層までクエリーをたどるかはリソース次第。そうやって、n階層たどったクエリーの結果は集約されつつ、大元のサイトまで返ってきてそこで表示される。

連携先をInterWikiみたいにサイト運営者が登録するのではなく、そのサイトにTrackBackを送ったサイトが自動的に登録されるような仕組みにしておくと、「そのサイトと似たような話題を扱ったことがあるサイト群に対して文字列全文検索を行い、類似する記事を見つけ出す」なんてことが可能になるかもしれない。

必要な要素としては、以下のような感じかな。

  • 検索連携I/F URL
    • TrackBackにおけるTrackBack Ping URLみたいな感じか。いや、どちらかというとPingBackサーバーURLに近いかも
  • その呼び出しはどのサイトから行われたものか
    • 直接の呼び出し元と、大元の呼び出し元のどちらの情報も得られた方がいいだろうな
  • その呼び出しが何階層目の呼び出しか
    • たとえば最初に?count=3とかで呼び出すと、以降階層をたどるごとに?count=2、?count=1とか減っていって、?count=0になったらその階層で打ち止め、なんてのもありかな
  • その検索結果はいつ実行されたものか
    • たぶん検索結果をある程度キャッシュして再利用しないとつらそうだから、キャッシュ更新時刻を返すようにしておいた方がよさそうだ。
  • その呼び出しはいつ実行されたものか
    • タイムアウト時間とかを考えると、大元の呼び出しが実行された時間が正確にわかった方がよさそう。「すでに呼び出しから30秒も経っているから、まだcountは残っているけど次の階層は呼び出さずに結果を返そう」とか。

2004/4/14

blogmap新着全文検索がどうにかならないかなー、などと、すっかり忘れていたネタを思い出していじろうとしたら、いつの間にやらEstraierがバージョンアップしていた。前回使ったバージョンからの主な変更点としては、

  • コマンドライン検索が可能になった（estxview）
  • メタ検索用インターフェースが標準で用意された（estmerge.cgi）

ってあたりか。どちらもなかなか俺的には楽しそうなバージョンアップだ。

けどそれよりも先に、blogmapの新着全文検索をなんとか回す手段を思いつけないかなー。ひとまずestautoregを使って分割インデックス生成＋合成を試してみたりしているけど、やっぱり頻繁に更新される数万文書のインデックス生成は結構つらそうな気配。

[ツッコミを入れる]

2004-02-26 [長年日記]

_ So-net ADSL 40M化計画 (13:51)

これ以前はSo-net ADSL 26M化計画へ。

2004/3/17

So-net Phoneの手続きができるようになったんで早速申し込み、ADSLモデムにIP電話の設定をしようと思ったら、どうもおかしい。

うちのモデムはAterm WD634GV（と本体には書いてある）なんで、So-netのWebでその機種用の説明を見ながら設定しようと思ったんだけど、「VoIP」に関する設定項目がいろいろ出てくると書かれてあるページに、「SIP」に関する設定項目が表示される。

ファームウェアのバージョン違いかと思ってチェックしてみたけど、最新8.0aと表示されているし、イコール配布バージョンでもあるらしい。はて？　念のため「オンラインバージョンアップ」で強制的に最新版にアップデートしてみたが特に変化なし。

といったところでふと気がついた、うちのモデムの設定画面のトップにはWD624GVと書かれてある。WD624GVとWD634GVは、ハードウェアは基本的に同等で、対応するIP電話がKDDI用とNTTコミュニケーション用という違いがあるらしい。もしかしてうちのモデムって、WD634GVと書かれているけれども、間違ってWD624GV用のファームウェアがインストールされているんでないかい。

今朝So-netサポートに電話をして状況を説明したところ、結局モデム交換ということになった。まだ旧26Mモデムも送り返していないんだけど、またもう1個増えるのか。昨日の夜は珍しくSo-net ACCA回線がダウンしていて（たぶん認証サーバーエラー）、さらに問題の切り分けを難しくしてくれたりするおまけ付きだったのもつらかったね。

2004/2/26

2/3に26Mコースの開通確認が終わって、コース変更の縛りが解けたんで、早速40Mへのコース変更を申し込んだ。で、すぐにACCAの工事待ちフェーズに入ったんだけど、そのままほぼ1ヶ月放置。ようやく今日工事日確定のメールが来た。工事予定日は3/4。

どこかに2月中旬からって書いてあった気がするけど、思ったよりも混んでいるのか、それとも技術的な問題とか機材の入手の都合とかで遅れ気味だったのか。

移行期間が大してかからないだろうと言う読みで、（その当時のSo-netのADSLコース変更の縛りを回避するために）いったんSo-net Phoneを解約したんだけど、結局まるまる1ヶ月以上So-net Phoneが使えなかったことになるのか。まあそれほどばりばり使う訳じゃないから大して痛くはないんだけど。

2004/3/1

そういや一昨日40M対応モデムが送られてきていた。けど、まだ開けてもいない。えっと工事予定日が4日だから、とっとと付け替えておかないとな。

2004/3/2

モデムを開けてみたらびっくり。この間買ったNECの無線LANルーターWR7600Hの兄弟機種だったよ。で、無線LANにはPCカード後付で対応すると書いてあったんでよく見てみたら、うちのWR7600HにもPCカードがささっていた。ふたのサイズがPCカードよりも小さかったから、てっきり電池か何かのふただと思って確認しないでいたところが、無線LANカードを差す場所だったんだね。

そうなると、WR7600Hのカードを引っこ抜いて、新しいモデムにさして、そっちで一元管理するという手も使えるんだよなー。ただ、ADSLモデムを設置する場所は電話線の制約が大きいんで、無線LANの電波状況を考えるとそっちに集約するよりは別々に管理した方がいいかもしれない。ただ、民生用の同系機種を同じネットワーク上に置いておくと、いざというときに混乱したりしないかちょっと心配だ。

と考え込んでいるうちに時間切れになったんで、モデムのつなぎ換え作業はまた後で。

2004/3/5

新しいモデムにつなぎ変えて工事日も過ぎたわけですが、モデムの接続状態を見たら、26Mモデムでは「Annex I」でコネクトして15Mbps出ていたのが、40Mモデムではどうやっても「Annex C」でしかコネクトせず、10Mbpsでるか出ないか程度にスピードも落ちてしまっていますが、なにか？

2004/3/7

ふと気がついたら、Annex Iで14Mbps程度でコネクトしていた。局側の設定を何か変えたのかな？　でもDouble Spectrumではどうしてもコネクトしない。うーん、つまらん。強制Double Spectrumでも試してみようかなー。

_ blogmapのASINランキングデータ (13:51)

このライトノベルがすごい！（http://maijar.org/sugoi/）が面白そうだったんで、試しにblogmapのASINランキングの中から、日本の書籍系データ（4から始まるASINのデータ）のみを抜き出してみた。blogmapのASIN関連データは2003/7/24からあるんで、ひとまず2003年いっぱいのトップ500と、現時点（2004/2/26）までのトップ500のデータを抽出。

CSVフォーマットで「ASIN（ISBN）」「ポイント数」という列で構成されている。

これをベースにジャンル分けとかすると、いわゆる「この○○がすごい！」系のWeb版が比較的簡単にできるかな？　まあblogmapのデータは、単にWebサイト上にISBNらしき文字列が現れた頻度ってだけなんで、ノイズもいろいろ混ざっているはずだけど。

上記データは、出所を明示してもらえれば自由に二次利用（加工含む）してもらってかまいません。

あと、ISBNコードだけだと調べるのが面倒くさいでしょうから、簡易ランキング表示アプリも作っておきました。

上記形式のCSVデータを食わせると、そのデータを使ってランキングを表示します。表示件数は100件までに絞ってあります。こちらも（あまりばりばり負荷がかからない程度で）ご自由にご利用ください。

[ツッコミを入れる]

2004-02-27 [長年日記]

_ ClearType対応IEフォント設定とWinSCPのドラッグ＆ドロップ (13:51)

そういやマシンパワーも上がったことだし、Windows XPのClearType設定をONにして、IEのデフォルト日本語フォントをClearType有効なやつにして、「きれいなフォントでWebブラウズ三昧」を実行しようと思ったんだけど、ところでどのフォントを設定するのが無難なの？　ひとまず俺のマシンに入っている中で比較的よさげだった「HGPゴシックM」（本当は「ゴシック」は半角カナ）にしてみたんだけど、世の中的にはどれを使っている人が多いんだろう？

あと、新しいマシンに乗り換えてから、WinSCP3でファイルをドラッグ＆ドロップすると、1つしかファイルを選んでいないのに、二つのファイルをコピーしようとして、しかも片方は文字化けしてわけがわからない状態で「ファイル・フォルダ（以下文字化け）はありません」って表示されるんだけど、これって回避できないの？　ひとまずダイアログで「中止」とかすれば通るんだけど、気色悪い。エクスプローラとかフォルダとかの設定で回避できそうな気がするんだけど。

おしえてはてなダイアリー（嘘）。

参考
[ツッコミを入れる]

2004-02-28 [長年日記]

_ 他人によるTrackBackのための拡張 (13:51)

ちょっと前に上記のような話題があったけど、今現在書評リンク集としてのblogmapに他人のサイトを登録しようとした場合に、本当はTrackBackを使って登録するのが一番手っ取り早い。

けど、なんのエクスキューズもなしで他人のサイトをTrackBackするのは上記のような問題からちょっとやりにくいし、かといってhttp://bm.ishinao.net/detail.html/4338079118#c1042みたいにいちいちエクスキューズ付きのコメントとして投稿するのもなんか面倒だ。

結局のところ、機能としてはTrackBackで十分なわけで、問題になるのはほんのちょっとした（本人が投稿したのか、他人が投稿したのか）情報が欲しいと言うだけのことならば、その情報を付加できるようにTrackBackを拡張してしまえばいい。

たとえばTrackBackが送る情報として、sender（登録者名）/senderurl（登録者URL）という項目を追加して、それが含まれている場合は他人による（DB登録のための）TrackBackである、とするとか。表示方法としては、単にexcerptの後ろにでも「by <a href="[senderurl]">[sender]</a>」とか「このTrackBackは<a href="[senderurl]">[sender]</a>によって登録されました。」とか付与すればいいだろう。

というわけで、blogmapでは上記独自拡張を取り入れました。sender、senderurlをつけてTrackBackを送ることで、本人以外によるTrackBackであることが明示されるようになり、DB上はTrackBackとして扱われるようになります（といっても、__mode=rssに対応していなかったりするけど、もしも対応したらそこにも掲載されるデータになる）。

DB登録用インターフェースとしてTrackBackを使いたい場合向けのTrackBack拡張サンプルってことで。

む、なんかregisterは登録者って意味では使わないっぽいな。なにかほかの表現に変えた方がよさそう。何がいいだろう？

無難にsender、senderurlの方がいいかな。register、registerurlだったのを直しました。

[ツッコミを入れる]

home | RSS | 1470.net

前 2004年
2月		 次
日 月 火 水 木 金 土
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29

powered by Estraier

テニスでどのくらい走る？

広告

最近のコメント

  1. ｗ (07-09)
  2. ishinao (07-09)
  3. ｗ (07-09)
  4. takano32 (04-30)
  5. まあ (02-22)

最近のtrackback

  1. 1.Kwappa開発室:PDO::bindParamの.. (2008-05-29 17:18)
  2. 2.MOVION.net:Zend_MailのsetSubject.. (2008-03-05 02:31)
  3. 3.ふらっと:Zend_Mailの日本語(の.. (2008-02-07 22:12)
  4. 4.yuum3のお仕事日記:[ソフト][メ.. (2007-10-14 15:04)
  5. 5.プログラマーが困った時に読むメ.. (2007-08-25 13:55)

題字フォント: Third Entertainment

Amazon.co.jp アソシエイト

Generated by tDiary version 2.1.4
Powered by Ruby version 1.8.2