ベイズ理論とGoogle

「グーグル―Google 既存のビジネスを破壊する」を読了。一気に読めるだけの物語性をもってGoogleの【今まで】を説明してくれている。

「ウェブ進化論」と併せて、現在のGoogleを中心にしたIT業界でどのような価値変動が行われているかを説明している本として紹介されているが、「ウェブ進化論」はどちらかというと、Google寄り。上記「グーグル」はどちらかというとGoogleを脅威の対象としてもみている。

個人的にはGoogleの今までの功績自体は素晴らしいものであると思うし、検索エンジン（他サービス）をGoogle中心に使わせて貰っていてあまり【脅威】を感じる事はあまりない。ただ、本当にIT業界全体としてGoogle無くしてネットは成り立たないという構図が100％になってしまった場合(ほぼ出来たと言っても良いかも知れないが)は暗い未来を勝手に妄想してしまうので、現在心酔するまでには至っていない。Googleとは違うアプローチでの【次アイディア】が出てきてから、始めて私は脅威を感じずに【帰依】する事になると思っている。

さて、話を変えて下の記事を見て欲しい。
ちなみに、以下内容は私の妄想ですので正しい情報だとは限りませんです。ハイ

• グーグル、インテル、MSが注目するベイズ理論

かなり古い記事(2003/03/17)であるので、有名な話なのかも知れないが私は最近始めてこの記事も類似内容も読んだ。私のアンテナの低さから起因しているのが大半だろうが、あまり話題になっているように思えない。

ベイズ理論は
「ベイズの定理」と呼ばれ以下のようにWikipediaでは説明している。

1763年に発表された確率論の定理である。今日では、幾つかの未観測要素を含むコンピュータによる推論等に応用され、迷惑メールの発見・分類といった作業の自動化（フィルタリング）といった情報工学上の情報ふるい分けに利用されている。

ベイズ理論が使われているアプリケーションで有名なのはメールフィルタリングプロクシの「POPFile」であるが、つまり「判断材料がたくさんあり」「その材料の【良し】【悪し】が判断できる」情報があればかなり高い確率で情報を【良し】と【悪し】に分類できる定理であると私は認識している。

これがGoogleで利用されているとした場合、有名な「ページランク」以上にすごい事ではないか？と思うのである。ページランクはリンクされている数を数えてそれを数値化して重み付けをする事で、故意に重みを増やそうとする輩のサイトを排除しようとする試みだが、現状「判断材料がたくさんある」Googleにはベイズ理論があると更に重み付けに信頼性をつけられる。

ただ、これは「検索しているユーザ」を１人の無人格なスーパーユーザとみなして判断をしている（国別等で条件分岐してるかもしれないが）と思われる。そして、「判断材料」は全てボットが拾ってきているので自動である。これはページランクでも同様な事が言えるが、ここで少し更に妄想してみると・・・。そうすると流行の「ロングテール」を検索で実現するのは「ニッチな言葉（検索ワード）」をユーザが入力するしかない。AdSense,AdWordsではこれでいいかも知れないが、これでは単一の情報をなるべく良質に表示するだけで終わってしまう。

これでGoogleが終わるとは到底思えない。情報を集めている事は次に狙ってくるのは、１人の無人格なスーパーユーザではなくパーソナライズの方であろう。現に「パーソナライズドページ」をリリースした。また、「判断材料」集めに「Google base」をリリースしてきたのではないだろうか？

今後、Googleの手のひらの上ではなく対等に仕事をするとしたら多分この辺りが勝負になるんだろう・・・。多分。
以下引用。

法や市場原理、モラルといった伝統的な制約だけでなく、ソフトウェアやシステムなどのアーキテクチャによっても人々の行動を制約し、規制することは可能なのである。そしてグーグルという司祭の権力は、まさしくアーキテクチャによって成り立っている権力システム以外のなにものでもない。

主義主張は違っていても多数の国があるように、単一化したアーキテクチャでの制約上の世界というのは心地良いと思える部分とそうでない部分がでてくるであろう。次のアーキテクチャを考えられ早く【帰依】させて欲しい（実現するのはGoogleを普通に使っている世代かもね）。

さて、偉そうに色々書いてきたが「妄想」なので許してたもれ。「おめーのブログだってAdsense貼ってるじゃね～か」というツッコミはその通り。私も現状Googleの手の上に多少なりともいると思っている。

• グーグル―Google 既存のビジネスを破壊する

複数リポジトリを1つのTracで

Tracではリポジトリは1つしか扱えない。例えば【１つのリポジトリを複数のTracで利用する】の事は出来るようだが、逆に【複数リポジトリを1つのTracで動かす】のは色々検索したが見つからなかった。

例えば、社内に複数のリポジトリがあってそれを１つのTracで管理したい場合。こんなのありそうだが・・・Trac 0.10xとかで機能追加されるのかな(?)。これがまた私の方でこのようなケースを自分で作り出してしまって困ったので…。無理やりではあるがSubversionのリポジトリ側で統合をしてみた。クレバーじゃぁないが、忘れそうなのでメモ。ちなみに、外部からのアクセスに関してはsvnserve、Tracで使うWebサーバはApacheだった場合を想定です。
なんかクレバーな方法あったら教えてください。m(_ _)m

大まかな説明

下記にあるシェルスクリプトをcronで回す。流れは以下。

• 統合させたい複数リポジトリをダンプ。
• 【統合リポジトリ】を作成する（しなおす）。
• ダンプしたファイルを【統合リポジトリ】にダンプをインポート。
• Tracにて【統合リポジトリ】を読み込み直す。

設定項目

SVN_USER

Subversionを操作するユーザ

SVN_PASS

Subversionを操作するユーザパスワード

SVN_REPO

元になるSubversionリポジトリパス

TMPLOG

ダンプの一時ファイルを作るフォルダ

SVNSERVE_CONF

Svnserveのコンフィグファイル(あらかじめ作っておく)。

TRAC_PATH

Tracのパス。

TRAC_PROJECT

統合するリポジトリ名（配列で入れる）

TRAC_ALL_PROJECT

統合リポジトリ名

APACHE_USER

Apacheユーザ

APACHE_GROUP

Apacheユーザパスワード

問題点

リビジョン番号

３つの複数リポジトリを統合した場合、Tracで表示されるRevisionは３つのリポジトリを足した番号になる。例えば以下のような感じ。
project1 (rev3) — Tracだと –> (rev3)
project2 (rev5) — Tracだと –> (rev8)
project3 (rev2) — Tracだと –> (rev10)

リアルタイムには反映できない

シェルで定時で同期を取るのでリアルタイムには反映されない。また、リポジトリを更新する際にソース表示関連のもの(リポジトリを利用する機能)は使えなくなる。大体長くて５分～１０分程度なので３時間毎でもいいかも知れない。

参照させて頂いたサイト

• Subversionで複数のリポジトリをまとめる(統合する)手順

TracのWebDB+Press記事

Trac! Trac! すげ～! と言ってたら・・・。今月号のWebDB+Press誌の特集は、Eclipse + Subversion + Tracの特集が載ってる！やっぱりソフトウェア開発の方々とか使ってるのねぇ～～。なんだか一人で興奮してるんじゃないのは良かったけど、自分がアホっぽく思えて恥ずかしくなってきた…ｗ

内容はざっくりとしか読んでないけど、「Tracを使ってプロジェクト内のワークフローを作ろう」っぽい。Eclipseとかは自分で使わないのが残念。

• WEB+DB PRESS Vol.32