2003-03-12
_ Trackback on bulknews.net from blog.bulknews.net (20:18)
>Bulknews において Trackback 機能をもたせてみました。各記事単位で、記事についてのべたWebサイトのURLをTrackbackで通知することができます。
というわけで、ニュース集約サイトBulknewsがTrackBackをサポートしました。俺が言葉交差点とblogmapを組み合わせてやろうとしていたネタの先を越されちゃったなー。でもBulknewsの方が扱っているニュースの数が多いから、普遍性は高くなりそうだ。
問題はニュース数が多いことによって、情報を集約することが難しくなる（どのニュースに反応していいかわからない）ことか。ある程度参加者が集まって来たら、TrackBackが多い順にニュースをソートしてみせると、TrackBack版blogdex的な感じになっていいかも。あと、普段Bulknews以外でニュースをチェックしている人間（俺とか）がBulknewsにTrackBackするのを簡単にするために、ニュース検索結果にもTrackBackリンクを用意して欲しい。
あと、俺ならばTrackBack（Webサイトを持つ人の意見）にプラスして、掲示板（Webサイトを持たない人の意見）も用意するところだけど、そうすると一気に管理コストが高くなるという罠。
あ、ニュース検索結果の各ニュース頭にある■はTrackBackへのリンクだったのか。てっきり各ニュースへのリンクかと思っていた。
_ ソニー、HPなど日韓米欧7社、「MPV」規格採用を推進 from ZDNet (20:18)
- ソニー、HPなど日韓米欧7社、「MPV」規格採用を推進 - http://www.zdnet.co.jp/news/0303/11/njbt_02.html
>MPVは、CDやDVDなど光ストレージに記録した静止画や動画を、CD/DVDプレーヤーで再生させるための規格
なんだか音楽業界に喝を入れる「DVDミュージック」の正体 from ZDNetで紹介したDVDミュージックとやけに方向性がかぶっているな。ただMPVの方がかなり普遍性の高い仕様っぽいけど。
- CD/DVD再生を容易にする新仕様「MPV 1.0」 - http://www.zdnet.co.jp/news/0211/25/ne00_osta.html
の方を見ると、XMLで記述したメタデータによってコンテンツ管理情報を提供するって仕組みらしいな。新規に作る規格としてはそういうアプローチは悪くないけれども、すでに適当にCD-RとかDVD-Rにいろいろなデータをつっこんでいる人たちはノーフォローな感じなんだろうか。XMLメタデータがあればそれを使って、なければないなりになんとかする、って感じの仕様だとかなり使えるものになりそうだけど。
_ 粗悪な記録型DVDメディアが、なぜ“怖い”のか from ZDNet (20:18)
このあたりの話は記録型DVDユーザーの間ではすでに当たり前で、2chのCD-R,DVD板ではいろいろな情報がやりとりされていたけれども、ZDNetあたりがわざわざ取り上げるようになったってのは、そういうマニア向け情報をチェックしない人たちの間にも記録型DVDが浸透し始めているからなんだろうな。そろそろDVD/HDDビデオレコーダーが普通の人の選択肢にもなりつつあるのか、という印象を受けた。って、ZDNetもまだマニア向け情報源の範囲かな。
_ マルチユーザー版WikiLike (20:18)
「xreaのアカウント」で書いたようにWikiLikeの配布用サブセットを作る方向もあるんだけど、マルチユーザー版WikiLike（WikiではなくWeb日記ツール的な用途版）を作ってどこかのサーバーで動かすってアプローチもあるよなー。tDiary.netとかはてなダイアリーとかみたいな感じで。
ただ、ここのサーバーにはあんまり負荷をかけたくないから、やるとしたら家サーバーでかな。でもあれはあんまり安定稼働させていないし、回線も細いからなー。キーワードで複数のページが自動的につながるWikiLikeのコンセプトは、マルチユーザー環境の方が面白いとは思うし、そういうのを立ち上げるとWikiLike同士をWebサービスでつないでみようかなという実験環境も同時に用意できるんだよなー。
でも管理コストが増えるのはとても面倒だ。でもまあWikiLikeDevとIchOnWikiLikeをつぶして動かせば、そのあたりもとんとんって感じかなー。うーん、びみょー。WikiLikeのコンセプトだとアカウント管理コストはゼロに近くできそうな気もするし。ちょっと試してみるか。
_ 【レポート】NuCOREデジタルカメラ用第2世代映像エンジンは5月14日に発表 from MYCOM PC WEB (20:18)
- 【レポート】NuCOREデジタルカメラ用第2世代映像エンジンは5月14日に発表 - http://pcweb.mycom.co.jp/news/2003/03/12/13.html
>NuCOREの画像処理エンジンを経て出力された画像は、カラー位相ノイズが少ないので、高周波成分を縮約するJPEG圧縮が効果的に働き、ファイルサイズが小さくなる
古いアニメなんかはノイズが多いせいで、MPEG2圧縮するときレートを高くしないと綺麗に録画できないって話を連想した。それ専門の人以外（俺も含む）には全然関係のない技術の話だけど、読んでいてちょっと面白かったので。
_ 米大リーグ1000試合をネットで生中継 from ZDNet (20:18)
>料金は月額14ドル95セント、シーズン通しの場合は79ドル95セント。個々の試合をペイパービュー方式で購入することもでき、1試合当たり2ドル95セントとなっている。
うーん、ちょっと見てみたい気もするなー。でもはっきり言ってずっとストリーミング中継映像なんて見ていたくない。基本的には文字情報（＋補助的なFlashムービーくらい）をリアルタイムで提供しつつ、見たいところだけ映像でも見られる感じのサービスだったら使いたいと思うんだけど。
_ お風呂に特化すると、テレビはこう進化する〜カシオ from ZDNet (20:18)
- お風呂に特化すると、テレビはこう進化する〜カシオ - http://www.zdnet.co.jp/broadband/0303/11/lp18.html
昔は風呂で本を一冊読むくらい長風呂だったから、そういう時代だったらちょっと欲しくなったかもなー。別に風呂専用というわけじゃなく、チューナー分離型モバイルテレビといった感じで使えるんだろうし。でも実売で10万円もするのか。もう半額くらいにならないかなー。
_ Button is in a sulk with Villeneuve from F1-Live.com (20:18)
- Button is in a sulk with Villeneuve - http://www.f1-live.com/en/headlines/news/detail/030311203508.shtml
>Jacques told me that he was sorry but I am not impressed.
あれだけ人（バトン）を批判（というかメディアに格下扱いする発言を）しておいて、実際のレースになったら早速これですか。この確執は多分溶けることはないでしょうねー。「無線の調子が悪かった」って理由は、すごく言い訳臭く聞こえるものだし。
_ PDAのアップグレードは終わらない悪夢だ from ZDNet (20:18)
なぜPDAをアップグレードしなければならないんだろう？ 今のPDAを使い続けることに何か問題があるんだろうか？ なんて言ってみてもしょうがないか。人は新しいよりよい製品が出たら、たとえ今使っている製品に問題がなかったとしても、新しい製品を使いたくなるものだし。
俺はPDAはPCに似た家電製品だと思っているから、周辺機器（オプション）が使えなくて当たり前で使えたら僥倖だ程度にしか思っていない。一般的な家電製品ってそういうものだし。もちろん周辺機器互換性が高いに越したことはないけれど、そのためにはPC並みに「標準」ってものができてこないと難しいだろうな。
_ ソニー、新CPU搭載のバイオノート“バイオノートZ”と“バイオU”を発表 from ASCII24 (20:18)
- ソニー、新CPU搭載のバイオノート“バイオノートZ”と“バイオU”を発表 - http://ascii24.com/news/i/hard/article/2003/03/12/642282-000.html
バイオノートZは微妙だなー。モバイル用途がメインだったら、やっぱりSRシリーズ程度の大きさ＆重さにして欲しい。モバイルとしても使えるメイン機としてならば、確かに悪くないけど。モバイルとしても使えるようにしている割には、機能を削って妥協しているところが少ないしな。今から買うとしたら、SRシリーズ（＋周辺機器いろいろ）とこっちとどっちを選ぶだろうなー。次のSRシリーズを待っちゃいそうな気もするなー。
新バイオUは新しい超低電圧版モバイルCeleron-600AMHzなのね。入力デバイス周りがどんな使い勝手なのかちょっと使ってみたいけれども、基本的にこういうコンセプトのものだったらLinux Zaurusの次のバージョンに期待するな。電車の中とかでは立ったまま使えるレベルになってくれないと俺には意味がない。
_ 中国toインドvia Silicon Valley from On Off and Beyond (20:18)
先行していたはずの日本、台湾、韓国は、いつ中国に追い抜かれるんだろう。中国の人口の多さおよび歴史（感覚）の長さは、国（民族）の底力を感じさせる。歴史がどんどん古い方向に伸びていく（遺跡が発見されることによって、伝説や神話が史実になる）という妙な国だしな。
インドも中国と似た印象があるけれども、あそこは国の中での制度の複雑さがどう影響してくるのかいまいちよくわからない。ああいう制度の複雑さがあってこそ（古代ローマは奴隷制度があったからこそ栄えた的な）なのか、それとも現代においてはマイナスの意味しか持たないのか。
_ Centrinoはワイヤレス革命を起こせるか？ from ZDNet (20:18)
>インターネットは業界にとって大きなカンフル剤だった。私はワイヤレスについても同じことを感じている
ワイヤレスがインターネット並みに大きなインパクトを与えるには、現状の接続可能範囲が狭い無線LANだけでなく、携帯電話とかPHSみたいなより広い範囲で使えるインターネットへのワイアレス接続にもシームレスに切り替わるような仕組みが出てくる必要がある気がする。無線LANレベルだとどれだけホットスポットが増えてもしょせんはケーブルがないだけだ。どんな場所でも最低限のインターネット接続が確保できる＝ユビキタスまでいかないとインパクトは薄い。
_ 「感情的な電子メール」の送信は慎重に from HOT WIRED JAPAN (20:18)
メールは送信ボタンを押した瞬間に自分の管理下から離れてしまうからねー。Webに載せるのだったらまだ取り返しがつく期間があるけれども、それでも最近では自分の管理下から離れた場所にコピーが保存されてしまう可能性が大きくなりつつあるし。でも、
>メールを書いたら、送信ボタンを押す前に、それが新聞の第1面に載っているのを想像してみるといい。もし自分が新聞の1面でその文章を読んだら不快だと思うのであれば、どんな状況であれ送信すべきではない
ってのは考えすぎだと思う。
昔仕事先の担当者に喧嘩を売るようなクレームメールを投げたことがあった。あれは新聞の第1面に載っていたら不快に思うような内容かもしれないけれど、送信すべきでなかったとは別に思っていない。出した結果と出さなかった結果を天秤にかけて、出した方がマシだという計算が成り立つのならば出してもいいのでは。感情も裏で計算しながら出そう。
2004-03-12
_ blogmap新着全文検索 (13:51)
- blogmap blog検索 - http://bm.ishinao.net/estsearch.php
- blogmap news検索 - http://bm.ishinao.net/newssearch/estsearch.php
2004/4/16
というわけで、新着全文検索を復活。データ収集先サイト（blog）と、そこでリンクを張られていたサイト（news）でそれぞれ別に検索できるようにしました。Estraierって同じディレクトリに一つのCGI設定ファイルしかおけないのかな？ まあいいけど。
随時収集しているデータについて、毎日朝1回だけindexを生成しています。んで、リアルタイム性はあまりありません。あと、更新されたサイトはどんどんデータが上書きされていきますし、データを取得してからある程度（3日ほど）経ったデータはばりばり削除していきます。
というわけで、とても狭い範囲（blog界隈およびそこで話題になったニュース）と狭い期間（更新されて、もしくは話題にされて3日以内）に対して全文検索をかけてみたいという方はご利用ください。
2004/3/12
「ベイジアンなRSS Aggregator from blog.bulknews.net」で書いた「blogmapにもなにかその系統（記事中に含まれる特徴的なキーワードを利用する）の機能をつけてみようかなー」というネタ。一番ひねりがない機能をつけてみた。単にクロールしたページにインデックスを張って全文検索するだけ。しかもEstraierを試しに使ってみたりしたら、応用の仕方（独自UIを作る方法）がよくわからなかったりして、UIまで既成のもののまんまだし。Estraierで自前のUIから検索機能だけを使う（コマンドラインとかでもいいけど）方法ってないのかな。なければやっぱりNamazu＋Chasenにして、PHP用のNamazuモジュールでも試しに使ってみようかな。
2004/3/13
いろいろ試行錯誤をした結果、なんとかそれなりに使えるようになったかな。
Namazuに移行しようかとindexを作ってみたんだけど、やっぱりEstraierのrelatedとかdetailとかの機能に魅力を感じたんで、できる限りEstraierで行く方針に。でも、Estraierには専用のCGI以外の検索クライアントがないっぽいし、専用CGIも見た目のカスタマイズ以外はほとんどできない。
一番痛いのはローカルで別名をつけたファイルに対してindexを張っておいて、検索結果には動的にエイリアスの元URLを表示する、ってことができないこと。リダイレクタを介したりすればリンクの解決自体は何とかなるけど、検索結果とかにリダイレクタのURL文字列が表示されるってのはちょっと我慢ならない。
ローカルで別名をつけるのをやめて、URLをurlencodeしたファイル名を使えば、decurlオプションを使ってなんとかなるかなーと思ったんだけど、そっちはそっちで別の問題が生じた。というのは、index生成コマンドのestindexが、長いファイル名のファイルが大量にあるときに全部のファイルを見てくれない。数千ファイルあるディレクトリに対してestindex registerをやっても250ファイルくらいしかindexが作られなかった。なんとなくファイル一覧を保持するバッファの制限とかがあるんじゃなかろうか（ソースは読んでない）。findと組み合わせたりいろいろやってみてもだめだったんで、URLをurlencodeしたファイル名を使う方法もあきらめ。
で、結局PHPでプロキシーを作ってestsearch.cgiにプロキシー経由アクセスし、ブラウザに返す前にリダイレクタのURLを元々のURLに置換して返す、というローテクというか強引な方法を採用。なんかあほらしい気がするけど、ひとまずほかの方法が思いつかないし。php4_namazuもインストールしたから、単に全文検索機能だけならそっち経由でもいけるんだけど。
あああと、Estraierのindex生成が速いのは対象のファイル数がある程度少ない間だけみたいだ。数千ファイルを越えたらNamazu＋kakasiよりもずいぶん遅くなってしまった。現状でこのくらいindex生成の負荷が高いとなると、安定運用させるためのバランスを取るのが結構大変そうだな。この機能だけのために1台専用サーバーが必要なくらいかも。
2004/3/14
あれー、なんかindexが壊れてた。ちゃんと二重化して更新しているし、logには正常終了した形跡が残っているんだけどなー。よくわからん。ひとまずデータ量をできるだけ削減する方向に設定を変更して、最初からもう一度回してみよう。
2004/3/16
なんとかそれなりに回るようになったかな。でもさすがに運用コストが高いなー。取得してから24時間経過したドキュメントは破棄しているんだけど、それでも現時点で15000件くらいはインデクシング対象に入っているし、まだまだ増えていきそうだしなー。常設できるバランス点を見つけることができるかなー。
多少なりとも負荷を減らすために、今まで内部でestsearch.cgiを使っていたところを、estserver（専用検索サーバー）を使うように切り替えてみた。それなりに負荷は減っただろうけど、インデックス更新にかかっている負荷を考えると、この程度の対処じゃあんまり意味がないかもなー。現時点ではさほど検索を使っている人が多いとは思えないし。
今のところあまりこの機能を使うあてが思いつかないんだけど、唯一related検索はちょっと楽しい。related検索ってのは、bulkfeedsでいうところのSimilaritySearchみたいなもの。検索結果の最後の方にある「related」ってリンクをたどると、似た話題を扱っているページをたどることができる。なんとなく似たような趣味のページを探すときに使えるかも。
2004/4/14
blogmap新着全文検索は、index更新負荷があまりに大きくなりすぎて、ほかに影響が出始めたんで止めちゃいました。indexを分割して復活しようかと思ってたんですが、なんかあんまりいい感じにならなそうなんで、そのまま放置中です。
というわけで、現在blogmap新着全文検索は死んでます。うまい方法（それなりの負荷で、それなりに使える情報が得られる運用パターン）を思いつくまでたぶん復活はなさそうな感じです。
2004/4/15
昨日、 >>というわけで、現在blogmap新着全文検索は死んでます。うまい方法（それなりの負荷で、それなりに使える情報が得られる運用パターン）を思いつくまでたぶん復活はなさそうな感じです。 とか言っておきながら、なんとなくめどがついたかも。
Estraierのindex作成処理を観察してみたところ、indexのファイルサイズ（対象ドキュメント数）がある程度以上大きくなると、速度が急激に遅くなるようだ。ってことはEstraierのドキュメントにも書いてあるんだけど、ドキュメントに書かれている「数万件」って目安は、想定マシンパワーか運用パターンがずいぶん俺とは違っているっぽい。
毎日1万件程度更新される1万件オーバーのドキュメントに対して、Celeron 1.8GHz/512M RAM程度のマシンで、他にもたくさんプロセスが走っているのを妨げない程度にindex生成を実行するとなると、一度に作成するindexの対象ドキュメントは1000件程度に抑えた方が良さそうだ。
ちなみにEstraierでindexを作成する場合の負荷ってのは、
- ある程度巨大になったindexファイルに対して登録作業を行う
- index更新作業が終わった後にファイルシステムにsyncをかける
って二つの要素が大きいようで、特に後者はindexサイズが大きくなるとものすごく莫大な負荷になる模様。
幸いEstraierには、大量のドキュメントを指定数以内に分割してindexを作成し、最終的に一つのindexにmergeするスクリプト（estautoreg）が用意されているんで、それのunit（1度に対象とするドキュメント）数を変更すれば、そのあたりがずいぶん調整できる。
1万件弱のドキュメントに対してindexを作成した場合、分割せずに実行しようとすると3時間かかっても完了しなかったけど、512件ごとに分割して作成した場合は、1時間以内で完了した。作成中にかかる負荷もずいぶんましな模様。
もうちょっと状況を見てみないとわからないけど、現状程度だったらそこそこの頻度（1日1〜2回程度）でindex更新かけてもなんとかなるかもな。
_ Text::ChaSenでundefined symbol: __gxx_personality_v0 (13:51)
Namazu＋ChaSenを使おうと、Text::ChaSenをインストールしようとしたら、Text::ChaSenをロードしようとすると「undefined symbol: __gxx_personality_v0」がでて止まる。結論から言うと、 gccのバージョンの問題で、-lstdc++を追加しなければならないということらしい。
Text::ChaSenのMakeFile.PLを
'LIBS' => ['-lchasen']
から
'LIBS' => ['-lchasen -lstdc++']
に修正してからインストール。
あとおまけに、rpmでインストールされていたnamazuでmknmzすると途中で「sh: line 1: no: command not found」で死ぬのは、たぶんインストール時にnkfかkakasiかchasenのパスが解決できていなかったため。たぶんmknmzのどこかのパスを書き換えれば通るんだろうけど、探すのが面倒だったんで、rpmベースのnamazuをremoveして、ソースからインストールし直したら通った。
ついでにphp4_namazuをインストールしようと思ったんだけど、元々のググって見つかるftpサーバーにはもうソースが置かれていないんだね。現在の入手方法としては、PECLのCVS（http://cvs.php.net/cvs.php/pecl/namazu）からcheckoutするってことになるのかな？ ひとまずそっち経由で入手。
でもEstraierでは待てる程度の時間で構築できたindexが、mknmzだとkakasiを使ってもちょっと待ってられないレベルの時間がかかるなー。しかもせっかくChaSenを使えるようにしたのに、どこかのドキュメントでセグメンテーションフォルトで落ちるから、そのままでは使えないし。
カスタマイズ性は低い（いや、ソースからいじればいいんだけどさ）けど、Estraierのままでいった方が無難かも。でももうちょっとUIをいじりたいんだけどなー。
2007-03-12
_ スカパー!の契約を変えた
デジタル放送（っつーかほぼデジタルWOWOWのHD放送）が見られるようになってから、ほとんどスカパー!を見なくなったんで、契約チャンネルを大幅に削減。えらべる15＋Gaora単チャンネル契約にしてみた。e2の方が多少画質的にマシなのかなーと思いつつも、アンテナ＋レコーダーを新調しなければならないし、契約パターンも割高な選択肢しかないe2に移行するのは、敷居が高すぎるんだよなー。e2の方で、たとえSD画質だとしても16:9放送してくれるんだったら、移行してもいいんだけどなー。
_ DVD-RのISOイメージってCD-Rにやけないのかな？
もちろん容量はCD-Rで収まる場合ね。ってのは、MSDNで落としたISOイメージファイルが、DVD用なのにCDに収まる容量なんで、わざわざDVD-Rを買ってきて焼くのが面倒くさいし、手元のCD-Rに焼けたら楽だなーと思ったんで。フォーマットの違いは吸収できそうだけど、CD/DVDブートの部分の仕組みが違いそうな気もする。試しにやってみるか。
_ RDS002 Tour買っちゃった
RDS002 Tour/UL2を買っちゃった。RQS11HGの新色かRDS001MPの間で迷っていたはずなのに、ショップで悩んだ結果はなぜかRDS002 Tour。選択した決め手は、ガット（ポリプラズマ）の色に合わせただけだったりするんだけど。ちなみにガットはポリプラズマ1.28/面圧58。
今のラケット（RQS-11HG）にもだいぶなじんできたところだったんで、ここで新しいラケットを導入するべきかどうか悩んだんだけど、やっぱり慣れてきてもまだRQS11HGだと飛びすぎなところがあるし、ラケットを変えるとどのくらい変わるのか実際に確かめてみることも必要だろう。
2008-03-12
_ Zend_Db_Select::where()メソッドの$type
trunkでは、
* @param string $cond The WHERE condition.
* @param string $value OPTIONAL A single value to quote into the condition.
* @param constant $type OPTIONAL The type of the given value
* @return Zend_Db_Select This Zend_Db_Select object.
*/
public function where($cond, $value = null, $type = null)
{
if ((func_num_args() > 3) or (($type !== null) and ($type !== 0) and ($type !== 1) and ($type !== 2))) {
$value = func_get_args();
array_shift($value);
$type = null;
}
$this->_parts[self::WHERE][] = $this->_where($cond, $value, $type, true);
return $this;
}
なんて感じになっているんだけど、この「(($type !== null) and ($type !== 0) and ($type !== 1) and ($type !== 2))」ってのはどこから現れたんだ？
where()メソッドでは、
* @param constant $type OPTIONAL The type of the given value
になっているけど、ここから呼ばれている_where()メソッドでは、
* @param string $type optional
になっているし、実際PDO_MYSQLを使ったZend_Db_Tableのinfo()では、DATA_TYPEはstringで返ってくる（"varchar"とか"int"とか）。
0、1、2という数値から、Zend_Db::INT_TYPE = 0、Zend_Db::BIGINT_TYPE = 1、Zend_Db::FLOAT_TYPE = 2あたりが怪しそうな気がするけど、この値ってZend_Db_Adapter_Abstract内で$_numericDataTypesとして定義されて以降、まったく使われていないし、意味的にも$typeが数値ではなかった場合に$valueを配列扱いするっていう意味がわからない。
これのせいで、trunkにしたらZend_Db_Tableのリレーション周り（findParentRow()とか）が動かなくなっちゃったんだよなー（Zend_Db_Table_Row_Abstract::findParentRow()内でZend_Db_Table_Abstract::info()で取得したDATA_TYPEをそのまま渡しているため）。自前で直そうにも、コードの意味がわからなくて直せないし。
3/13追記
昨日更新されたrevision 8783で、上記の怪しげな条件文はばっさり削除された。なんだったんだ……。
