May 23, 2007

FeedBurnerは何も隠していないと思うよ

FeedBurnerは超重大な事実を隠してる - たねちゃんズ12

それは言いがかり…だけど、NASAばりに○○の存在をひた隠しにしなければならない団体に準えるセンスには脱帽。

自然に考えてこれはFeedBurnerが悪いのではなくて、Yahoo! Japanが悪いのだろう。ブログとフィードのURLの不一致があろうとも正しい形式でRSSを生成しているのであればそれを検索対象に含めるのが、「ブログ検索」のあるべき振る舞いだから。

むしろ問題は、

主に以下のような場合は、検索エンジン用ロボットの巡回対象とならないことがあります。 * RSSのアドレスが、ブログや各記事のドメインと異なる(例:外部サーバ上のRSSアドレスを直接参照している)

みたいに単純に技術的要請から生じた(であろうと想像される)留保条項をいつまで継続しなければならないのか、ということだ。

ブログ検索の中身がどうなっているのかは知らないが、基本的にはフィードに対する検索機能を実現するには、あるブログに(時間的・空間的に)複数のフィードが関連付けられているときにそれらのうちどのフィードを信用するかを決定する必要がある。それにはあるパラメータセットを取る評価関数が必要であって、そのパラメータセットには、フィードURL、ブログURL、フィードの更新頻度や最終更新日時、そのブログのlink要素へのフィードURLの記載の有無と時間的分布などが含まれ得る。で、評価関数はそれらのパラメータを使って各フィードのランク付けを行う。まあそんなとこだろう。

そういう前提があるものとして、ではなぜブログURLとフィードURLのドメインの一致・不一致が問題になるのか(≒「留保条項」が存在するのか)をちょっと考えてみると、まずあるブログに関連付けられるフィードは無限個存在するという事実がある。あなたがあるフィードを提供していたとすると、第三者がそのコピーフィードや若干加工したフィード、あるいはエントリーのURLのみをコピーした中身は出鱈目なフィード、を別のURLで公開することは際限なく実施できるから。で、その無限個存在するフィードのうち、ブログURLとドメインが一致するフィードの信用度はより高いとするだけの蓋然性がある。なぜなら両者のURLの所有者が同一であると考えられるから。これに対して、不一致の場合には、濫造されたフィードか、FeedBurnerのように本来は(暗黙的に)信用に値するフィードかを区別する手立てがなければ信用度は一律により低くするより他ない。

当然この基準に基づいて信用度が低くなったフィードであったとしても他のパラメータセットによって相対的に最も信用度の高いフィードとして選択されることはあり得る。だから、FeedBurnerを使っていてブログ検索に掲載されないサイトもあれば、問題なく掲載されるサイトもある、ということになる。

一方で、こういう疑問もある。「留保条項をいつまで継続しなければならないのか」という疑問に通底するのだが、このようなアルゴリズミックなエフォートと、プロトコル的なエフォート(単純に現時点でのブログのlink要素を信頼してフィードを確定する方法)の、いったいどちらがより優れた結果をもたらすのかという疑問である。現状では前者が後者を上回る結果をもたらすのだろうか。それとも実際にはlink要素を使っていないフィードがあまりに多くて検索対象となるフィードが少なくなり過ぎる(=coverageが下がり過ぎる)のだろうか。

門外漢なりにいろいろ技術的な困難さは想像してはいるのだけれど、日本のネット人口のブログユーザ率は他国に比べてかなり高いそうだから、この問題の解決は是非日本人の手で達成されるといいよねー。

追記:
Typoがあったので修正しました。

May 18, 2007

遅ればせながらTwitter。

今更Twitter。昨日のMXもちらっとだけ観た。

Twitter / ogawa

だいぶ前に登録してはあったのだが、使い始めたのはようやく2、3日前。ミニ感想を言うと、GoogleとかYahoo!とかMSNとかメッセンジャーのサービスをしている大手が始めたらあっという間に駆逐されそうである、真っ当なアクセスコントロールを実現してからリリースするものではないのか、というところである。まあ弱小でユルユルだからこそイイ…というのは中央線文化にも合い通じるものがあり、とりわけ日本人のあるふぁなファンを集めているのも分からないではない。

FriendsのFriendsを勝手に追加していけばいいんだろうけど、クソ小さいアイコンをクリックしていくのがハゲシク面倒。こういうチマチマしたインタフェースは悪趣味だと思うなあ。ブログのヘッダにlink rel要素を書いておいて自動検出するようにするとか、ブログのURLを与えたらTwitter IDを返すAPIを「Twitterが」提供するとか、ありがちな解は多分すでに提案されていて実現されていたりするのだろう(ちょっとフォローしてられない)。

May 11, 2007

PXE + iSCSIブートするための試行錯誤に費やされた GW前半のメモ

連休中に書いたメモ・その2。編集せずにManchesterからお送りします。

PXEブートしたカーネルからNFS rootやiSCSIデバイスをroot mountすることでディスクレスブートマシンを実現できることは知られているし、枯れた技術でもある。重要なのは、特殊な機材がなくても、PXE compliantなネットワークインタフェースを持つマシンなら何であっても(それが実マシンであっても仮想マシンであっても)「擬似的に」iSCSIブートできるということである。

Stateless Linuxは、この技術をコアにディスクレスクライアントのディスクイメージやプロファイルを中央集中的に管理するマネージャ機能などを提供するもののようだ。が、どの記事を見ても全貌はさっぱり分からない。Component-wiseに「できたもの」からStateless Linuxという名前を付けていくだけなのかもしれない。正式にFedora CoreやRHELのリリースに包含されるようになればもう少し分かりやすくなるだろうが。

それはさておき、StatelessLinuxiSCSIRoot - Fedora Project Wikiには、iSCSIブート用のinitrd.imgを作る方法が書かれているのだが、私が試した限りではちっともうまくいかなかった。

おおまかに言って三つの問題があった。

一つは、StatelessLinuxiSCSIRootにあるとおりに、mkinitrd --net-dev eth0して作ったinitrd.imgに含まれるinitスクリプトに、

network  --device eth0 --bootproto dhcp

と書かれていることだ。この部分はDHCPサーバからIPアドレスなど取得して、ifconfig upしてくれたり、route addしてくれたりするのだと思うのだが、Fedora Core 6ではこれがまったく動かない。dhcpdが動作しているマシン上でtcpdump port dhcpcしていると、PXEのブートシーケンス(dhcpによってIPアドレスなどを確定してカーネルやRAMディスクのイメージをダウンロードする必要がある)ではパケットダンプが観測されるが、initスクリプトの実行部分ではまったく観測できない。なんなんだこれは。

もう一つは、StatelessLinuxiSCSIRootの方法だと、initスクリプトに/sbin/iscsistartを実行する部分が生成されなければならないはずなのだが、実際にはうまく生成されない。いくつか思い付く理由も対策もあるのだが、mkinitrdを改造する必要があるのでとても面倒くさい。

もう一つの問題は、上ができたとしてもiscsistartへの引数がinitrd.img内にスタティックに書き込まれてしまうことである。これだとホストごとに同じ手続きでmkinitrdしなくてはならない。NFS rootの場合と同様に、カーネル引数に渡したオプションを解釈してiscsistartしてくれればよいのだが。

ちょっとNFS rootの補足をすると、rootファイルシステムはread-only mountする(つまり複数のNFS rootクライアントが同じrootを共有する)のに加え、設定を同じくするホスト群のinitrd.img/vmlinuzは共通化して、カーネル引数で渡した情報に基づいてクライアントは各自の設定を行うようになっている。iSCSIブートの場合には、クライアントごとにrootに使用するiSCSIデバイスが異なるのでread-write mountする点に注意することを除けば、NFS rootの場合とほとんど同じようにできるはずだ(むしろ簡単なはず)。

こうした状況にめげずに何とか便利なツールはないものかと探していたわけなのだが、あまりいいツールがない。

iSCSI-initは、カーネル引数を解釈してiSCSIデバイスをアタッチしてくれるカーネルモジュールだが、Open-iSCSI以前のLinux-iSCSIにしか対応していない。CentOS 4.xの場合には使える。

Diskless / remote boot with Open-iSCSI - WPKG - Windows software deployment toolは、initスクリプトそのものを自作のものに置き換えるものでOpen-iSCSIに対応している。その自作スクリプトが難ありで、カーネル引数でホストのIPアドレスなどを指定しなければならないという困った仕様。

正常動作し、カーネル引数を使ってiSCSIの設定を行うinitrdを生成するツールを作るだけでGWの前半を潰してしまった。不慣れなもので。暇があれば続編を書く。

AT車で急発進する事故の対策がどうのこうのという話に関するメモ

連休中に書いたメモ・その1。編集せずにManchesterからお送りします。

ヒューマンインタフェースとは無関係に、ほとんどの道具のインタフェースはその道具の内部構造に規定される。

アクセルもブレーキも加速度を制御するレバーである。前者が燃料の噴射量によって加速度を制御する装置に起源を持ち、後者が摩擦によって加速度を制御する装置に起源を持っている。それぞれ異なる機構だから異なるレバーにそれぞれを制御する役割が割り振ってある。

では、アクセルとブレーキを同一のレバーにすることができるかというと原理的にはできる。が、するべきでない。それは、(1)異なる役割のものを異なるレバーに割り当てることが人間にとって自然であること、(2)アクセルレバーはすでにアクセルと変速機の両方を制御するレバーになっていて(or ブレーキレバーはすでにブレーキとABSの両方を制御するレバーになっていて)これ以上の役割を持たせるのは人間にとって難しいこと、による。

私は基本的に操作系にフェイルセーフを加える(アクセルレバーに加速度センサーを取り付けて急激な入力があればブレーキを作動させる)よりは、システムとしてフェイルセーフにした方がよいと思っている。単一の操作系への意味の追加は多分現在のAT車が限界だ。

システムとしてフェイルセーフにするという意味では、バンパーに何かが接触したらアクセルを無効化しブレーキを作動させる(センサーベースの自動ブレーキシステム)のは一つの方法である。ただし、意図せぬ場合に作用する危険性もある。

より確実にするには、スロースタートモードを追加することである。つまり、まずエンジンスタートしてアクセルを踏んでも高々10km/hしか出ないようにしておく。このモードの場合のみセンサーベースの自動ブレーキシステムを作動させるようにすればよい。

システムとしてファイルセーフにするという意味では、(ずっとハードルが高いが)アクセルレバー自体をなくすという方法もある。乗用車が速度を制御できるレバーとして作用するアクセルを持つようになったら(あるいは全速度域においてオートクルージング可能になったら)、それはアクセルを操作する必要のない乗り物とほぼ等価である。足元にはブレーキレバーだけがあればよく、アクセルを単なるダイアル式のスイッチかにするか、あるいはなくしてしまうことができる。これなら急発進などあり得ない。

May 10, 2007

Manchesterに来ています

週の頭からイギリスはManchesterに来ております。仕事です。

6日に2位のChelseaが引き分けたためにManchester Unitedのプレミアリーグ優勝があっさり決まってしまったので、「私が滞在中、首位決戦(9日)で優勝が決まって街中大騒ぎになる」イベントは残念ながらありませんした。まあ、私が応援しているのは川崎フロンターレとFC岐阜なので別に構わないのですが。

しかし、GBP高過ぎです。5年前Edinburghに来たときは1GBP=約195JPYだったのが、今は約242JPY。Travelexあたりで両替すると250円を超えてしまいます。ペットボトルの水が1GBP(M岡先生はスーツケースに大量の発泡水を仕込んで運んだそうですよ)、サブウェイのサンドウィッチが3GBP。ロンドンの地下鉄の初乗り料金が4GBPというのは例外としても平均的に見て日本より2倍くらいは物価というか為替が高いです。VATもしゃれにならん。なんかものすごく貧乏になった気分です。欧米以外から来日している外国人もそう思っているんでしょうなあ。

食事はFish & Chipsと中華料理、インド料理を中心に摂取しています。昨日行ったCurry Mileのインド料理屋(Punjab Tandoori Rusholme Manchester - reviews and information)で脂に当たったっぽいです。旨かったんですけど。

May 5, 2007

ナゴヤドームで野球を観る

連休の後半はぷらっとこだま+在来線を使って岐阜に帰省。法事イベントに参加し、ナゴヤドームで野球観戦して慌しく帰ってきた。

初ナゴヤドーム!もう開場10周年なのだが、機会が恵まれず今まで行ったことがなかった。もう人生の約半分を東京で過ごしているもので。

ナゴヤドームの感想はというと、駅から遠い、でかい、チケット高いという感じ。夏日だったせいもあるけど、地下鉄駅からの長い地下道やそれを抜けて階段を上った後の長い長い空中回廊はちと辛い。チケットは座席クラスごとの値段という意味では他球場に比べて高くはないのだが、ナゴヤドームの指定席Aは東京ドームの指定席Bに相当する場所なので実質的に高い。両翼のフェンスが高過ぎるので福留が捕球するファールフライが軒並み観られないんだよね。

でも建造物として見ても野球場として見てもとても美しい。東京ドームは内圧で支えているドームに過ぎないけど、ナゴヤドームはちゃんと自力で支えるだけの骨格を持っている。

試合結果はというと、こんな感じ。

Yahoo!プロ野球 - 2007年5月4日 中日vs.横浜 結果
2007シーズン 公式戦/試合結果

前日で連敗が止まったおかげもあり、ドラゴンズらしい締まったゲームになって本当によかった。

May 1, 2007

「Googleの JavaScript API を使ったページのWebキャッシュにアクセスしたときに出るアラート」対策

小ネタ。

GoogleのJavaScript API(MapsSearchFeed)を使う場合、API keyを取得しておいて各ページに下のようなコードを埋め込むことになっています(コード例はOgawa::Buzz: Googleの JavaScript APIがこっそり統一されてきている件について。を参照)。

<script type="text/javascript"
        src="http://www.google.com/jsapi?key=API key"></script>

それは良いのですが、そのページがWebクローラによってクロールされてキャッシュされたとします。ブラウザでそのWebキャッシュにアクセスすると、「AJAX Search API Load Failure: invalid api key supplied」などのアラートメッセージが表示されるはずです。というのも、Google API keyはAPI利用者のURLごとに払い出されるもので、URLとkeyに不一致があると機能しなくなるものであるのに対して、Webキャッシュは元のURLを(Webキャッシュの)サービス提供者のURLに置き換えてしまうからです。他にも翻訳サービスのようにサーバ側で一旦オリジナルのページ情報に代理アクセスするサービス一般に当てはまります。

この問題は、script要素を各ページに張る代わりに、下のようなスクリプト片を記述するか別ファイルにしてscript要素で読み込んでやれば回避できますよ、という本当に本当の小ネタ。

(function() {
  var keys = { 'http://your.domain.name/': 'Google API Key' };
  var url = location.href;
  var idx;
  while ((idx = url.lastIndexOf('/')) != -1) {
    url = url.substring(0, idx);
    var key = keys[url + '/'];
    if (key) {
      document.write('<script type="text/javascript" src="http://www.google.com/jsapi?key=' + key + '"></script>');
      return;
    }
  }
})();

このスクリプト片では、ページのURLがhttp://your.domain.name/以下にあるときにはscript要素を生成しますが、そうでないときには生成しません。そのため、Webキャッシュ経由でアクセスした場合にはAPI自体使えなくなり、アラートも出なくなります。

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com