2002-02-01
_ newsウォッチはどうしようかなー
どうせまめにニュース関係はチェックしているんだから、それをシステマチックに記録に残してみようとはじめたNewsウォッチなんだけど、どうも前のサイトでやっている形式は今ひとつ面白くない。俺フィルターを通してニュースクリッピングをしつつ、話題の広がりがあるものに関してはそれを元に一ネタだべるというやり方だと、記事リストの部分とだべっている部分のバランスを取るのが難しすぎだ。うまくやれば情報ソースとして有用になるかと思っていたんだけど、これじゃー自分用の記録場所としても使いづらい。
というわけで、ひとまずフィルタリング＆リスト化の部分だけを抽出して、こっちのサーバーにも置いてみた。これはこれだけのものにしておいて、その中でも特に興味を持ったニュースに関しては、日記でちゃんと触れる形式にした方がバランスが良くなるかな。一応最低限日記との連携はとれるようにしておこうか。
_ 「カメラにドメイン名，月額3000円の画像モニタリング 九州松下」
Dynamic DNSを採用し，カメラにドメイン名「xxx.miemasu.net」（xxxは任意）を割り当て，遠隔地のPCからWebブラウザでアクセスできるようにした。
そうか、ダイナミックDNSの登録更新ツールを載せておけば、IPアドレスが固定じゃなくてもいいもんな。家サーバーとかでダイナミックDNSを使っていても、こういうのに応用できるとはなかなか思いつけなんだ。
_ 「肥満を制御する司令塔遺伝子、東大チームが発見(14:45)」
この遺伝子の働きを弱めたマウスは、体重が約３分の１になり、体内の脂肪も約１０分の１に減少した。
早くこの技術を応用したやせ薬が、一般向けに実用化されないかなー。いや、俺には関係ないよ。関係ないってば。
_ 「Googleで検索結果＝1を目指せ」
このゲームの決まりは，Googleの検索バーに2つの単語を入力し，出てくる検索結果をたった1つにすること。つまりGooglewhackの“上がり”は，スクリーン右上角に「Results 1-1 of 1」（1件中1-1）と表示させることだ。
試しにやってみて最初に成功した組み合わせ「在原業平 コモドドラゴン」。
_ newsウォッチ→日記方向の連携は完了
こんな感じで、newsウォッチ側から日記に連携させる仕組みは完成。やっぱhnsの仕組みは柔軟だから連携させるのが楽でいいなー。ただ、日記→newsウォッチ方向への連携させる仕組みを考えるのはちょっと難しいか。mail2nikki経由で投稿した記事の固定URLを外部で受け取る方法ってあるのかな？
_ そろそろやばいかな
最近ちょっと遊んでいすぎたな。締め切りがはっきりしないままにずるずるとのばしてきた仕事たちが、突然わらわらと終幕に向けて動き出したよ。勝手に終幕に向かってくれるんだったらいいんだけど、俺が終わらせなきゃ終わらないんだよね。えっと、基本的には今抱えている仕事はみんな、今月中頃までには終わらせないとダメなのかな？ 結構きつそうだなー。ひとまず一番作業量が多そうなHDML30ページものに取りかかっておくか。HDML＋CGIスクリプトをたくさん書かされるのって、一種の拷問のような気がする。あの直観的ではない言語仕様は、なんとかならんのか？
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さんに関しては、「匿名で」という部分は正しくありませんでした。十把一絡げに扱ってすみません。ただ、
- もともとこの手の問題になりそうな話題をはてなダイアリーという場で行い、結果としてクレームがプロバイダ（はてな）に行ってしまった（kosekiさん個人へアクセスするよりもはてなにアクセスする方が簡単である状態になっていた＝匿名者の批判と同じことになってしまった）こと
- 自分の言論に対するクレームが付いた場合に、その仲介をしたプロバイダを追求するよりも先にやることがある（株式会社ウェディングを批判することがメインなのならば、はてなダイアリー以外の（より直接自分で責任がとれる）場に移動して、話を続ければいいのでは）ように私には思えるのに、追求の矛先がはてなの方に向いてしまっていること（これは「kosekiさん自身が」というよりも、「それをきっかけとした多くの人の反応が」という要素が大きいです）
というあたり（特に後者）に関しては、やはり当初の私の文章の対象となると思います。
要は、「はてなの対応」を批判（追求）したいのか、それとも「株式会社ウェディングの問題点」を追求したいのか、いう話です。そして前者（はてなの対応批判）に関しては、それは私には「筋違いの批判（自分の言論の責任代行をプロバイダに押しつけている）」ように見えるのです。
（追記）2/1ぶんと2/2ぶんの文章の間には、#726〜736のコメントでのやりとりが（暗黙の話の流れとして）挟まっていますので、そちらも読まないと、読解しにくいかもしれません。
2004/2/2 その2
- 株式会社ウェディング様より有限会社はてな様に削除要請 - http://d.hatena.ne.jp/toronei/20040201#p5
>>はてなとかさるさる日記だからというわけではなく、レンタルサーバーでもおこってることだし、逆質問ですが、プロバイダーに責任は代行させるべきではない、ホームページやWeb日記、Weblogなどで責任ある発言をしたい人は、ホームサーバーぐらい立ててそこでやれということなのでしょうか？
思いつく方法としては、
- 犯罪・訴える系のクレームをつけられないような（プロバイダがその手のクレームを受けても自らの判断で却下できるくらいの）表現方法を考える
- サービスプロバイダなどにクレームが行かないように、現実でのクレームの宛先を明記しておく
- 責任をとらなくてすむ別の手段を考える（匿名告発手段としては、2chとかスラドみたいなシステムを使う方法がありますし、日本の法律の及ばない国のサーバーを使って身元を隠した告発を行うという方法もあるでしょう）
あたりでしょうか。
というか、「ホームページやWeb日記、Weblogなどで責任ある発言をしたい人」という場合の「責任」とは何をさしているんでしょう？
「すべての個人情報を相手に渡してもかまいません。直接私がクレームへの対応をします。ですから、私の文章は削除しないでください」でしょうか？ それとも「記名で文章を書いて公開します。しかしクレームがきた場合はプロバイダが仲介して、決して私の個人情報はあかさないでください」でしょうか？
相手がやばい系だった場合など、自分の身元を明らかにするリスクが高すぎることもあるでしょうから、その場合は3番目の「責任を回避して発言する」手段を模索するのもいいでしょう。ただ、「文責は持ちたい（記名で批判したい）」けれども、「現実的なクレームの矢面には立ちたくない（プロバイダに代行させたい）」というのは、「責任ある発言」ではないと思います。
ポイントをまとめると、「“言論の自由”を守るためのコストをサービスプロバイダに押しつけるのはおかしい。第一にまず発言者自らが最大のコストを支払うべきなのではないか」といった感じです。
2004/2/3
- 整理できたことだけコメントを - http://d.hatena.ne.jp/koseki/20040202#1075723708
>>プロバイダ側でユーザの（まともな）発言をサポートするサービスがあってもいいんじゃないかな
確かに、そういうサービスができるといいですね。逆に言うと、そういうポリシーを明確にしているところ以外では、基本的にユーザーは自己責任の範囲で行動するべきだとも思います。あとたぶん私の言う「自己責任」はkosekiさんが考えている「自己責任」よりもずいぶんと重い。はっきり言うと「訴えられる覚悟をする」ってことです。
- ソニータイマー（悪徳商法?マニアックスと株式会社ウェディング関連） - http://deztec.jp/design/04/02/000082.html
>>ishinaoさんの回答は少し腰が引けていますが、私は「そうです」と申し上げたい。極論でも何でもない。自分でサーバを用意していないのだから、結局はサーバ屋がダメといったらダメなのは当たり前です。
別に腰が引けているわけではなく、せっかく下がった技術的な敷居まであげることを是としたくないので、「自分でサーバーを立てろ」とはしなかったのです。
ところでこのような問題の背景にあるのは「ホームページ/blogで気軽に情報発信」的なコピーの「気軽」の意味の取り違えがあるのではないか、という気もしてきました。ここでいう「気軽」は、あくまでも「技術的・経済的コストがかからない」という意味での「気軽」であるはずなのに、「発言の内容を気にしなくていい、責任をとらなくていい」という意味での「気軽」だと認識している人が多いのではないか。あるいは2ch的な特殊な場に慣れすぎてしまい、あれがネットでの標準だと思ってしまっているのか。
- 好奇心はキーワードを殺した - http://d.hatena.ne.jp/wushi/20040202#p2
私の文章は、はてなに限らずネットにおける風潮一般に対する批判なのですが、はてなに限定して言えば、ここの文章が一番私の言いたいことをわかりやすく表現してくれていると思います。
やばい発言をする場合には、本来どのくらいのリスクがかかるのか、それを受け止めることにはどれくらいのコストがかかるのか。そしてそのコストを誰が受け止めるのか。という話として。
2004/2/4 自分なりの総括
今回の件は、私にとって複数の問題が内包されていました。
- 悪徳商法？マニアックスがクレーム対処に関して、プロバイダの対応を非難していたこと。
- はてなダイアリーでキーワードやkosekiさんの日記などにクレームがつき、削除されたこと。その件について、はてなダイアリーの「削除」という対応に関する追求が多かった（説明責任という論調が多かったが）こと。
- その後も問題のクレームの対象になりそうな文章をはてなダイアリーに掲載する人が見受けられたこと。そのような再クレームを誘発するようなことを行いつつも、そのクレームを自ら引き受けるという人が見受けられなかったこと。
- 最近ネット上の発言があまりにも無責任方面に向かい過ぎているのではないか。またその責任は結局、顧客情報を守るという立場のプロバイダがかぶらされているのではないか。と以前から考えていたこと。
で、結局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
- まとめの代わりに10の質問 - http://d.hatena.ne.jp/koseki/20040205#1075920258
今回の件のまとめとして、kosekiさんが関連する10の質問を公開しています。今回の件に限らず、一般論としても回答できるものなので、興味のある方は是非回答してみてください。特に11。
2005-02-01
_ gonzui の php support (00:57)
とくひろさんが、昨日のネタを使って、gonzuiのPHP parserを書いてくれました。試してみたところ、ちゃんとPHPのコードとして認識されcolorizeしてくれるようになりました。ただ、関数とかクラスの定義はうまく認識されていない模様。でも、ここまで動くものがあればあとは自力でいじっても何とかなりそうな感じです。ありがとうございました。
_ 関数・クラス対応バージョン (13:46)
おお、早くも関数・クラス定義に対応したバージョンにアップデートされましたよ。インポートし直したら、今度はちゃんとPHPの関数使用率統計とかも現れた。
ただ、勢い余ってPEARライブラリをまとめてgonzuiにつっこんでみようかと思ったら、PEARのtgzなアーカイブを食わせるとgonzuiがうまく認識できない模様。いったんtarで展開してからもう一度tgzに固め直してやるとうまく食えるらしいけど、何かアーカイブのフォーマットが違うんだろうか？
ひとまずhttp://gonzui.ishinao.net/以下には自分がチェックしたい公開アーカイブをつっこんでおくけど、それとは別に自分の作ったコードをgonzuiで閲覧できるようにしたプライベートなgonzuiも立ち上げておくと便利そうだな。どうせなら、Subversionリポジトリと適当に同期をとるようにしておくと、さらに便利かも。あるいは単に特定ディレクトリにおかれたtgzファイルをチェックして、更新されていたらremove、importを自動的にしてくれるだけでもいいか。
あと、gonzui用PHPパーサーページが独立した模様。
ところで、gonzuiは基本的には自前で各言語のパーサーを持つというアプローチみたいだけど、このPHPのアプローチみたいに他言語で使いやすいパーサーがある場合は、それを使ってgonzuiに取り込むためのインターフェースを持たせておくと便利かもしれない。インターフェースっていうか中間出力のフォーマットを決めておく感じかな。XMLとかYAMLとか。
_ mm_footer.rbとrss_recent.rb改造版 (15:37)
ちゃんとRuby（とtDiary）のお勉強をしてから真面目に書き直そうかと思ってたんだけど、キビシイ督促（笑）を受けたんで、適当バージョンを公開しておきます。
なかにはrss_recent.rbの改造版と、それに依存したmm_footer.rbがあります。rss_recentは、
- 引数にテンプレート文字列を渡すことで、出力するHTMLを変更できるようにした
- RSSのcontent:encoded要素を解釈＆保存するようにした（require 'rss/content'）
- RSSの取得（パース）失敗時には古いキャッシュを使うようにした
- アイテムが0のときは空文字列を返すようにした
という改造を施しています。あとデフォルトのテンプレートを従来のものと変えちゃっているんで、置き換えるとrss_recentの出力が変わってしまいます（どう変わるかというと、ここのサイドバーのような内容になります）。
で、mm_footer.rbは改造版rss_recentを使って、各日付のフッタにその日のMMの内容（content:encoded部のみ）を表示するプラグインです。面倒くさいんでMMのユーザーIDは17行目あたりに、
mm_user = 1 # your MM id
とかしちゃってるんで、それを自分のIDに書き換えて使ってください。というか本当は、プラグインで設定を編集・保存できるようにしつつ、未設定の場合は表示しないようにすればいいんだけどね。ついでにテンプレートもWebインターフェースで変更できるようにしておけばいいんだけどね。
標準のテンプレートでは、<div class="section"><ul class="mm_footer">なんて感じになってるんで、適当にCSS定義を追加して見た目を変えてください。ul.mm_footer span.url {font-size: 80%; color: silver;}とかしておくと、ここの表示みたいな感じでURL文字列が目立たなくなります。
ところでテンプレートに埋め込んだ文字列変数を再評価するのにevalを使っているんだけど、もっと安全な方法ってないのかな？ それともsecureの設定で使用できる命令とかが絞られて自動的に安全になる？ というかもしかしたらsecure関連の設定によっては、このコードはそのままじゃ動かないかも？
あ、あとcontent:encodedをCGI.escapeHTMLしないで出力してますけど、その場合content:encodedに攻撃コードを入れられることによって、tDiaryをおいているドメインに対して攻撃を受ける危険性があります。一応そういうリスクを念頭に置いた上でご利用ください。
このセクションに対するはてなブックマーク
_ ジャスト「一太郎」の販売中止を命じる 松下アイコン訴訟で判決 (もっと詳しく) (17:15)
こういうつまらん特許は、行使しようとした結果もめたらその段階で、まずそれが本当に特許として有効な技術なのかどうかの再審査を受けるようにして、それでつまらん内容だと判断されたら簡単に無効化できるようにならないだろうか。
特許の初期審査にコストをかけられないというのは、まあしょうがないとしよう。すでに取得済みのつまらない特許も山のようにあるだろうから、今から入り口を塞いでも手遅れだ。だから、入り口（新規申請）は今まで通りでかまわない。
ただし、それを行使しようとしてもめた場合（裁判になった場合）、特許が有効という前提で侵害されているかどうかを争う前に、まずその特許自体の妥当性を審査するようにする。そうすれば、妥当な技術審査をするべき件数は大幅に減るだろうから、1件あたりにはそれなりのコストをかけられるんじゃないか。
個人的には、その問題について世界中の人が考えた場合、100人以上の人が思いつきそうな技術（手段）は、特許にならない、とかして欲しいな。10人でもいいかも。
このセクションに対するはてなブックマーク
2006-02-01
_ PocketBloglinesでときどきネットワーク接続ができなくなる件
原因が分かった気がする。なんか腐ったDNSに当たって名前解決自体ができなくなっているっぽい。WILLCOM任せで自動で割り当てられたDNSサーバーの中に、おかしな情報を返してくるやつが混ざってない？ 試しにDNSサーバーをWILLCOM任せにせずに、別プロバイダのDNSサーバーを使うように設定を変えてみたら、今のところ上記の症状が発生していない。
ちなみにそれに気づいたのは、その状態の時にIEで、かなり昔にサーバーを切り替えたサービスにアクセスしようとしたところ、もうキャッシュ期間もとっくに過ぎているはずなのに、切り替え前の古いサーバーにアクセスしにいったから。
_ smbd [recent_rssの改造版、公開マダー？(AA略 … スミマセン]
_ smbd [ありがとうございます〜]