Jun 25, 2007

Movable Typeが WordPressに負けない理由

小粋空間: Movable Type が WordPress に負けた本当の理由

danメソッドに従って書くと。重要なのはこのゲームがWinner takes allタイプのゲームではないということである。

「MySQLはPostgresに比べてインストールベースが圧倒的に多いという意味で勝っているが、そのこと自体がPostgresを使い続けることの妨げとなり得るか?」

あるいは

「LinuxはFreeBSDに比べてインストールベースが圧倒的に多いという意味で勝っているが、そのこと自体がFreeBSDを使い続けることの妨げとなり得るか?」

どちらも答えはNoである。現状PostgresやFreeBSDでしかできない(あるいはずっと楽にできる)業務があるのだから。

同様にMovable Typeにしかできないことがあり続け、あるいはWordPressがユーザベースの巨大さに胡坐をかいて現状の洗練を欠いたソフトウェアのままであり続けるのならば、ユーザベースの大小に関わらずMovable Typeの意義は失われないだろう。

Six Apartに戦略の乱れがあったことは事実だが、そんなことはMovable TypeがGPL化されることによって両ソフトウェアが同じ土俵に上がるという事実に比べれば卑小な事柄に過ぎない。

WordPressにとっての勝利もMovable Typeにとっての勝利も、ユーザベースが存在し、開発が継続されることである。また、Movable Typeを使う使わないに関わらず、人類の共有財産にひとつのソフトウェアが追加されることの意義を過小評価してはならない。あなたの生活を便利にしてくれる計算機環境(の少なくとも一部)はひとつひとつそうやって追加された共有財産によって構成されているのだから。

というわけでdanメソッド終了。danメソッド便利。対象をアサッテな方向から論評できるもん。

Jun 23, 2007

Googleの順位決定に Analyticsのデータが使われていたなどという事実は判明していない

これはひどい。こういうことを書くからSEO屋さんは信用できない。

SEOmoz | Proof Google is Using Behavioral Data in Rankings (原文)
Googleの順位決定にGoogle Analyticsのデータが使われていたことが判明! | Web担当者Forum (日本語版)

オリジナルの記事(Google bounce factor research data is in)によれば、実験1は10~11位に位置していたリンクを人海戦術でクリックし続けるという実験である。かなり恣意的なキーワードで検索した結果に対して実験を行った場合には最高2位まで上昇したが、メジャーなキーワードの場合にはほとんど変化がなかったという。

ここで注意する必要があるのは、リンクが元々「10~11位に位置していた」という事実である。実験2では80位に位置するリンクを対象にしているのだから、この実験でも80位に位置するリンクでなければ、順位向上の効果の多寡を(少なくともBounce Rateに基づくものと)比較して評価できない。だから、

Googleの検索結果ページで行う特定サイトへのクリック数は、アルゴリズムの計算に反映されるが、わずかしか影響しない。

などというobservationは成立しない。アルゴリズムである以上「影響」があるかないかの二者択一であって、もし影響があるのなら、マイナーなキーワードであればあるほどまた順位が低ければ低いほど影響は大きく、その逆なら影響は小さくなるのが一般的だろう(門外漢なのでよく分からないが、サイト集合の分布というのはキーワードの生起頻度をλとするようなポアソン分布に従うのではないかな?)。

次に実験2は、同じく人海戦術で、Googleの検索結果ページからあるGoogle Analyticsが組み込まれたサイトへ飛び、そのサイト内で一定時間過ごすという試行を繰り返す実験。およそ1週間の試行でサイトの順位が80位から33位へと向上したという。

ここで問題となるのは有効な対照実験がなされていないことである。実験2は「Googleの検索結果ページのリンクをクリック」し、かつ「一定以上の滞在時間があることをGoogle Analyticsを使ってGoogleに伝達」した結果、順位が向上した、と言っている。であれば、前者のみの条件下で行った実験結果と比較しなければ、後者の寄与が存在するのかどうかを確認するのは不可能だ。

つまり、この場合の適切な比較対象は、「Google Analyticsが一切組み込まれていない、同等のキーワード・順位を持つサイト」に対して同様な実験を行ったもの、である。比較がなされていない以上、

この実験では、Googleが順位のアルゴリズムを改善するために、Google Analyticsのデータを利用していることが証明された。

などということは口が裂けても言えない。

著者らは「Googleの検索結果ページのリンクをクリック」する効果が無視できるほど小さいことを実験1で示したではないかと言うかもしれない。だが示していない。だから実際に筆者らが行ったのは「実験2の結論を導くために、実験1で意図的に効果を小さいものに見せることで読者をミスリードする」ことである。少なくともresearchと称してこんなことを行うべきではない。

念のため、私は、著者らの仮説がこれらの実験によっては証明されないと述べているのであって、仮説自体が誤っていると述べているのではない(そんなことは分からない)ことをお間違えなく。

だが、私は疑わしいと感じている。なぜなら滞在時間の増大や直帰率の低下は、ユーザがコンテンツに関心を寄せている場合だけでなく、単にサイトのナヴィゲーションやレスポンスが劣悪な場合にも生じる現象だからである。例えば、コンテンツ本文を読む際にユーザに一段の間接参照を強いれば必然的に直帰率は低下するが、それはユーザのコンテンツへの関心の高さを表しているわけではない。

Jun 18, 2007

Cybozu2iCal 0.13公開

サイボウズオフィス6のカレンダーアイテムを取得して、iCalendar形式に変換するスクリプト、Cybozu2iCalをまた久々に更新しました。

Cybozu2ICal - ogawa - Google Code

0.10でサイボウズカレンダーの反復イベントに対応し、0.12ではそれをリファインしましたが、0.13では反復イベントの一部を削除、または日付・時刻を変更した場合にも正しくカレンダー表示できるようにEXDATE(iCalendar spec: 4.8.5.1 Exception Date/Times)に対応しました。また、各イベントにUIDというユニークIDを付与するようにしました。これにより、Google Calendarなどで一つのイベントが重複して表示される問題が解決するものと期待しています。

詳しい変更点は上記リンクから。

テストが不足していますので、問題点やコメントがあればこのエントリーのコメント欄にでもお書きください。

関連:
Ogawa::Buzz: Cybozu2iCal 0.12公開
Ogawa::Buzz: Cybozu2iCal 0.10公開
Ogawa::Buzz: Cybozu Office 6のカレンダーを Google Calendarで表示する

Jun 12, 2007

「TrackBackはもうなかったことにしてはどうか?」とは?

そんなにセンセーショナルなことを書き逃げしたつもりはなかったのだけど、ちゃんと書いておかないと誤解されると思ったので書いておく。

そうそう、TrackBackはもうなかったことにしてはどうか?
Ogawa::Buzz: Movable Type 4ベータテスト

5年前にはブログのキーフィーチャーのように語られていたTrackBackだが、end-to-endで特定のプロトコルで通知する仕組みは古臭い。直接的には送信者と受信者しか感知し得ないという意味でちっともWeb 2.0的でないし、単なる通知にしては受信側のリソースを食い過ぎる。一応Movable TypeのTrackBack実装にはエントリーに関連付けられたTrackBackをRSSフィードとして取り出す機能があるが、あまり知られているようでもない。

Web 2.0的な発想からより自然だと思えるのは、URL間のlinkageを提供する外部サービスを実現して、ブログからは適当なAPIを用いてそのlinkage情報を利用するようにする、というモデルである。このモデルが優れているのは、linkage情報の収集やそれに含まれるスパムをフィルタするための負荷が利用者の負担とならないということと、リソース・エフォートが集約できるということである。linkage graphを利用した新しいアプリに利用できるかもしれないし、そのgraph構造自体がスパムの発見に利用できるかもしれない。もちろん、任意のURLが(TrackBackに対応しているいないに関わらず)擬似的にTrackBack-enabledになるという利点も見過ごせない。

実はこうした外部サービス(の類似物)は、すでに存在している。

例えば、はてなブックマークの「このエントリーを含むほかのエントリー」機能は、エントリー間の言及関係に基づいてlinkage情報を生成・表示する。残念なことにこの情報のみを取り出すAPIは用意されていないようだし(あったらゴメン)、言及しているエントリーがブックマークされないとリストされない。

また、Googleなどのブログ検索もエントリー間の言及関係に基づいてlinkage情報を生成・表示することができる。例えば、このブログに言及しているブログは link:blog.as-is.net - Google ブログ検索で検索でき、そのフィード(RSS, Atom)URLを一種のWeb APIとして利用できる。Yahoo!ブログ検索でもほぼ同等の機能が提供されている(Yahoo!ブログ検索 - 「http://blog.as-is.net/」の検索結果)。Google AJAX Feed APIと組み合わせれば、フィードはサーバーサイドにキャッシュされ、便利なレンダリングライブラリも利用できるのでとても都合がよい。

ここに挙げたものは、いずれも「エントリー間の言及関係」を機械的に取得するインタフェースとして利用するのにすでに十分であるか、あるいはほんのわずかな拡張だけで十分利用可能なことが分かるだろう。

一方で、TrackBack protocolとそれを利用するレガシークライアントの普及度を考えると、もう少しstraightforwardなやり方もある。つまり、引数に対象URLを取るスタンドアロンなTrackBackサーバと、URLをキーにしてTrackBackフィードをRSSやJSONで返すサーバをペアで提供すればとりあえず事は足りる。ブログ側ではTrackBackフィードを定期的に取得してレンダリングするか、JavaScriptでオンデマンドにレンダリングするかすればよい。誰でもTrackBackフィードを利用できるようにしておけば再利用して新しいアプリも実現できる。なんて2.0!

もちろん欠点もないわけではない。最も重要な点を挙げるなら、サービス側に多大なリソースが必要となるために誰でも簡単にサービスを開始(あるいは維持)できるわけではないことだ。だからこそ競争相手が少ないとも言えるし、だからこそTrackBackフィードに広告リンクを混ぜればビジネスモデルとして成立するとも言える。

実はこのモデルはユーザの負荷を外部サーバにオフロードすることによって利便性を提供しているという点でFeedBurnerと似通っている。誰か立ち上げてGoogleに買われるまで頑張ってみては(嘘)!!

2007-06-12追記:
「Googleのブログ検索ではブログの代表URLに検索結果が集約されてしまう」と書いていたけど、それは誤りだったので本文を訂正(Thanks: はてなブックマーク - Fuktommyが後で読む / 2007年06月12日)。Google AJAX Feed APIへの言及も追加。

Jun 11, 2007

Movable Type 4ベータテスト

Movable Type 4 beta1が公開されているのは既報のとおりです。

movabletype.org
MT4 Beta Download Movable Type Beta

軽くインストールして使ってみましたが、*impressive*です。2.x当時我々を虜にした「いいもの使ってる」感が戻ってきた感じです。Wordpressなどに比べてインストールや運用に必要な手間・リソースとも依然大きいのですが、こうしたコストと引き換えにしてもなるべく多くの人に体験してもらいたいと思います。念のため、ベータ版は、個人無償ライセンスに準じた利用条件に従う限り、個人が個人サイトにおいて利用することに何ら制限はありません。単に正規版に比べてバグをより多く含んでいる可能性が高いというだけです。正規ライセンス版でもデータが破壊されることはありますし、使用による損害は補償されないのは共通です。

現在のところ、movabletype.org: Known Issuesに掲載されているくらいの問題は発見されています。一行で意味が分かる不具合とそうでない不具合があるので、以前みたいにBTSを公開してほしいところですね。

あとはオープンソースってどうなるのでしょう。オープンソース版を商用利用するSOHO業者がGPLを理解できないせいで発生するであろう混乱が今から目に見えるようです。面白いので私の公開しているプラグインもGPLにしてやろうかな(笑)。

少しネガティブな話をすると、私は最近(というかかなり以前から)ブログソフトウェアを個人的に運用するコストが高まり続けていて、いずれアマチュアユーザの手に負えなくなるだろうと思っています。共用サーバのMySQLでの運用に支障を来たしているという事実もそうですし、スパムに対抗するのに今後はより一層複雑な仕組みとそれを可能にするだけのリソースを必要とするだろうからです。MTAやDNSのように容易にスパミングの対象になるサービスはアウトソース化にそれほど抵抗なく踏み切れるわけで、最終的には自前でブログソフトウェアを動かす人は、同じく自前でBINDを動かす人の数の定数倍程度に留まると予想しています。

一方で、Google BloggerやVoxをはじめとするホスティングサービスは自前でMTなどを動かすのに比べて自由度がなさ過ぎるではないかという指摘は当然あります。でもこれは将来に渡ってそうなのかというとそうでもないのではないかと思っています。あるべき将来像の一つとして、例えばブログのコアサービス自体はシンプルに維持する一方、ブログのデータ構造(他にもGoogle Base、Flickrなどなどもろもろ)をintrospectionするためのJavaScript APIを提供し、Gadgetとして必要に応じて拡張機能を実装する、というものが想定できるでしょう。効率化のためにはサーバーサイドキャッシングと併せて提供することが必須ですけどね。

そういう将来像も頭の片隅に置きつつも、今はMT4の世界を体験してみるのもよいでしょう。

そうそう、TrackBackはもうなかったことにしてはどうか?

Jun 5, 2007

Yahoo! の無線LANスポットの続き

あんまり引っ張るつもりはないのだけど。

続)Yahoo!がおかしいって言うか... : NOBODY:PLACE

konazeさん、なかなか良い点に目をつけていると思う。konazeさんの言い換えになるけど、一番の問題は、Yahoo!のサービスではそれぞれの無線LANアクセスポイントが誰のpropertyであるかが明確にされていないことだろう。

私はマクドナルドのpropertyだと思っている。マクドナルドのpropertyとして使用規定を遵守させる仕組みだけ用意すれば本来合理的に運用できる。だからやれ、というのがOgawa::Buzz: Yahoo! の無線LANスポットの趣旨。

片やそうでないと本当はYahoo!がpropertyの使用に関する一切合財を引き受けなければならない。利用規定を定めるのもどこが厳密に利用可能な場所か定めるのも無線LANだけ使いに来る客がいたら追い出すのもYahoo!の仕事となる。現実的ではないだろう。

現実はどうかと言えば、マクドナルドはpropertyとしての認識がないのに、運用上の支障に関しては店側が対処するっていう状態。乱暴な言い方をすると、現状Yahoo!のサービスってFONみたいなものじゃないかね。誰も責任を持たないproperty(La Fonera)をサブスクリプションしたユーザに使わせているのとあまり違いがないじゃない。

さてと話を変えると、アクセスポイントにログインした際にYahoo!からマクドナルドに100円落ちる仕組みがあったとしよう。この場合、無線LANのみのユーザは珈琲一杯の客と同等の立場のはずだ。だったらマクドナルドは無線LAN客を普通の客と同等に扱うべきかもしれない。「マクドナルドの客」が何によって規定されるべきかというのは、認識が一致しない可能性を残している(空港やホテルの例を挙げたのは、同じ空間を提供するサービス業であっても単なる訪問者すら客とみなす業があるように、店・客ともに多様な認識の仕方があることを言わんがため)。

Yahoo!のサービス単価が安すぎるところを見ると(または件の人物が追い立てをくらったところを見ると)、そういう仕組みはないか、無視し得るほどの売り上げにしかならないか、あるいはちゃんと売り上げはあるのだけど一店員が(または全社的に)それを認識していないか、のいずれか。しかし、そんな仕組みの有無や店側の認識を単なる一ユーザである身のいったい誰が知り得ようか。そう、マクドナルドでの使用規定が何も示されていないのも忘れてはならない。件の人物の困惑、そう困惑の部分に関してだけは、もっともだと思えないか。

前半の話と併せると、つまりはこういうことだ。マクドナルドが無線LANアクセスポイントをpropertyとして認識してそれを業として提供できるのならこんな問題はそもそも最初から起こらなかった、と。マクドナルドはNTTコミュニケーションズと組めばよかったのに、と(嘘)。

まあ結局、私が言いたいのは、安いのには訳があるってことだけどね。あと安物サービスならFONに置き換え可能だって言ってもよいかも。

Jun 4, 2007

Yahoo! の無線LANスポット

Yahoo! 無線LANスポット、看板にいつわりあり?? - OhmyNews:オーマイニュース "市民みんなが記者だ"

条件付きだがこの人の主張はそんなに間違っていないと思った。別にロハで使わせろと言っているわけではない。ホテルのアクセスポイントは宿泊しなくても使えるし、空港のアクセスポイントは航空券がなくても使えるのに、マクドナルドは商品を購入しなければ使えない、というのは全ユーザに共有されている事実には思えない。

Wayportなどのサービスだとアクセスポイントに接続した後、ブラウザでユーザ認証させるのだけど、そのときに使用許諾を読まされたような気がする。また、WayportのFAQには

Q. If I purchase a connection, can I use it anywhere on the property?

A. If you purchase a connection at a Wayport location, this does not necessarily mean that you will have access anywhere on the property. Each location has a specific configuration, defined by the hotel property, therefore it is important that you thoroughly read through the Wayport Welcome Page before purchasing a connection.

とか書いてある。

Yahoo!のサービスのサブスクリプションページでこの手の説明がなされていないとしたら(少なくともYahoo! 無線LANスポット ヘルプには説明されていない)、それは不明確だから説明すべきだろう。一般に本来利用できるはずの場所あっても利用できないという場合は当然ある。完全なサービスや製品というものは予め存在しないのだから。だったらその条件と責任の所在を明確にするということは、どんなサービス・製品であっても必要ではないか。

実際的にはもう少し包括的に、サービス範囲内であっても「アクセスポイントごとに定められた使用許諾に従わない場合、物理的・ソフトウェア的な障害が発生した場合、または社会的情勢に照らして使用が許可できない場合」にはサービスが正しく使えないことを説明した上で、マクドナルドのアクセスポイントでのユーザ認証時に「マクドナルドの商品を○○円以上購入すること、従わない場合退店を命じることができること」を条件付けた使用許諾を受け入れさせるようにすればよい。マクドナルドの店員に「お客様、ご注文をお伺いします」などと言わせるなんてまったくコストの無駄(マクド難民への対処も実は難民用にカウンター席数席しか使わせないように制限し、eat-inの客はその制限に合意したものとみなすだけで済む)。

こんなのは技術でも何でもないわけで、とっととやるべき。責任の所在を不明確にするのは日本の良くない商慣習だし、常識を盾にする大企業に優しくするのは消費者として賢明な行動とは限らない。

冒頭で「条件付き」だと書いたのは、「詐欺まがいの不当表示」「こうるさいクレーマーにこれ以上、突っ込みを入れさせないように適度にあしらっておく、という担当者の姿勢だけがよくわかる」みたいな個人的な感想と、事実や企業への真っ当な要求事項とを区別して述べられていないからである。「不利益を被ったと私は感じた→解約した(事実)」とか「不利益を被ったと感じた→クレームした・対応はこうである(事実)」とか書いてあれば無駄に人々の劣情を喚起せずに済むし、「不利益」の内容に関心も示すだろう。まあ率直に言ってしまえば、自分の設定した「仮定」を感情も露に否定する文章って新聞の投書欄などでよく見かけるわけだけど噴飯ものだね、ってだけなんだけど。

Jun 2, 2007

予想通りFeedBurnerが買収された

GMO傘下のFeedBurner Japanから「feedburner.comからfeedburner.jpに乗り換えませんかー?」というメールが何回か来ていて、うっぜーと思ってスルーし続けていたのだが、それはFeedBurnerがどこかにacquireされる可能性を視野に入れてのことだった。

Google has acquired FeedBurner

で、FeedBurner Japanどうなるの?GMOの株がGoogleの株に交換できてラッキーってことなの?日本のユーザは梯子外されたりしないのかな?

ところで、このディールはユーザから見ると割とつまんない。ユーザにとっては、FeedBurnerの集計機能が実現することよりは、ユニークかつ不変なURLをフィードURLとして使えることにバリューを認めていたわけで。少なくとも私なんかはそう感じていたわけで。当然GoogleはFeedBurnerの有償版の機能を含めて無償で提供し、Analyticsと統合するとかしてくるだろうけど、だからと言って特筆するほどユーザにメリットがあるとは思えない。フィードURLの不変性がより確実になったというだけ。むしろ、Googleが広告媒体をごっそり手に入れたということ、ほとんどその事実のみに価値があるようなニュースであり、ディールだよな、と。

Jun 1, 2007

Google Gears雑感。

Google Gears (BETA)

LocalServer、Database、WorkerPoolという3つの機能をWebブラウザ上で実現するextension。以下はメモ。

LocalServerは、Webコンテンツをブラウザローカルにキャッシュし、オフラインでもアクセス可能にする機能。ブラウザにはもともとコンテンツをローカルディスクやメモリーにキャッシュする機能があるが、このキャッシュはユーザの操作によって簡単にinvalidateできてしまう。これに対して、LocalServerはWebアプリから完全に制御可能なキャッシュを実現しており、ネットワーク接続が失われた状態でもキャッシュ済みのコンテンツであればトランスペアレントにアクセスできるようになる。どうやって実現しているのかちょっと分からないのだが、ブラウザのリクエストを常に横取りしてmanifestファイルにあるURLならキャッシュしたデータを返すようにしているのかな。だとしたら通常のページのブラウジングが多少重くなるはずなんだけど。

Databaseは一言で言えば、Fat Cookie機能。通常のブラウザに組み込まれているCookieはごくシンプルなpersistent state機能を実現するものだが、Google GearsのDatabase機能はより柔軟で、サイズに対してスケールするpersistent stateを実現したものだと言える(ゆえにセキュリティに関わる問題もcookieと共通する)。具体的には、Google Gearsのpersistent stateはブラウザローカルなリレーショナルデータベース(実装はSQLiteそのもの)として保存され、SQLを使って操作することができる。

WorkerPoolはバックグラウンドタスクを実現する機能。UIのレスポンスを犠牲にすることなく、I/Oやcomputation-intensiveなタスクを実行できる。ブラウザに標準に組み込まれているタイマーリソースだけで実現されたマルチタスクもどきとは雲泥の差がある。データを共有しないところを見ると別プロセスとして実行される(スケジュールはOSが行う)のかな。あるいは、そういう実装を選択せざるを得ないプラットフォームが存在することから演繹された仕様なのかな。

ローカルキャッシュ、Cookie、タイマーはブラウザに標準に実装されている(仕様が標準化されてもいる)のに対して、Google Gearsはそうではないが、「オープン」である。動作環境も多いし、誰でもこのextensionの機能を使ったアプリケーションを書ける。おそらくはGoogleは自社のWebアプリケーションに組み込むことで動作環境としてのde factoを狙う一方で、もう少し真っ当に標準化を行ってde jureとしてもブラウザへの組み込みを正当化するという両面作戦を採るのではないか。

一方で、私はこのextensionの仕様はまだまだ発展途上なのではないかと思っている。例えば、Database機能ではstateの保存にSQLiteを使っていて問い合わせインタフェースがSQLiteの実装に依存している点などは、Google Gearsの実装がmatureでないことを物語っている典型的な証左ではないだろうか。実装がガラス張りなので分かりやすいとも言えるが、バックエンドの実装を別のものに置き換えた瞬間にそれを利用するコードの書き換えが必要になるのでは、ソフトウェアの構築手法として美しくない。

2007-06-06追記:
そうそう。一番肝心なことを書くのを忘れていた。Google Gearsで重要なのは、minimum constructでアプリケーションプロキシーを実現している点。Vistaとか言っている場合じゃないよ。真面目にブラウザだけで任意のオンライン+デスクトップアプリケーションが動かせるようになるよ。

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

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