Previous month:
September 2007
Next month:
November 2007

Mac向けMSN Messengerの異常なトラフィックについての質問

 最近、家からのインターネットへのアクセスが異常に重い。色々と調べたところ、息子のiMacで走らせているMSN Messengerが原因のようだ。それも、メッセージをやりとりしているかどうかに関係なく、セッションを幾つか開いているだけでものすごい量のネットトラフィックが発生する。

 日本と違い、こちら(米国)のネット事情はまだまだなので、我が家には1Mbps弱のADSLが来ているだけだが、それでもメッセンジャーのセッションを幾つか開いただけで、数百Kbpsを使ってしまうとは、ちょっとおかしい。本来ならメッセンジャーは、TCP/IPを開きっぱなしにしておき、メッセージをpush型で受け取る仕組みになっているはずなので、メッセージがやりとりされていない時のトラフィックは、ほとんどゼロに近いはず。この状況は、まるでpollingでもしているかのようだ。

 まあ、Mac向けのメッセンジャーにマイクロソフトが力を入れて作るとは思えないとは言え、この状況は少し異常。どなたかこんな状況について詳しい方、もしくは同じような症状に出会った方がいらしたら、コメント欄でご一報をいただきたい。


「ウミウシの生殖活動ブログ」とアルファブロガーの話

 徳力さんに2007年度のアルファブロガーの選出に協力するように頼まれたのだが、少し困ってしまった。というのも、去年あたりから「アルファブロガー」という名前が一人歩きし始め、しだいに「たくさんの読者を抱えること」、「たくさんブックマークされること」がアルファブログの定義のようになりつつあるような気がするからだ。

 まあ、言葉の定義なんてそもそも人が決めるものだから、たくさんの人が特定の意味で使い始めればそれが定義になって行くものなので、目くじらをたてることもないのだが、逆に言えばブログとかを通して言葉の定義に影響を与えることも可能なはず。ということで、今日は「アルファブログ」、「アルファブロガー」という言葉の定義そのものに、少し影響を与えてみようと言うエントリー。

 私にとってのブログとは、自分の興味のあること、たまたま目についたこと、その時感じたことなどを、できるだけ自然に自分の言葉で語る場所。その中には、「自分でも良く書けた」と思うエントリーもあれば、そうでないエントリーもある。

 そして、私にとって「良く書けたエントリー」とは、「自分だけにしか書けないことを、だれにもわかるように書けたエントリー」のこと(参照)。

 当然、読者あってのブログなのだから、コメントの数や、ブックマークの数を成功指標の一つとして参考にはするが、それだけを指標にしていては、ブログは変な方向に行ってしまう。ブックマークの数が稼ぎたかったら「○○するひとは絶対読むべきサイト20」みたいなリンク集のエントリーを書けば良いし、ページビューが欲しかったらdigg.comで上位に上がっている海外のエントリーを毎日翻訳すれば十分。でも、そんなことをしていては、「自分だけにしか書けないことを、だれにもわかるように書く」という私にとってのブログの本質を外してしまうし、自然体では書けない。

 で、何が言いたいかと言うと、私にとっての「アルファブログ」の定義は、まさにこの「自分だけにしか書けないことを、だれにもわかるように書く」ということを徹底しているブログ。当然、そのブログが主としているテーマによってはコミュニティの大きさは違うので、私のようにネット・ソフトウェア・ハード業界のことを幅広く書いていればそれなりのページビューも稼げるが、「ウミウシの生殖活動」がメインテーマではページビューは稼げない。だからと言って、私のブログをその読者の数を理由にアルファブログと呼び、「ウミウシの生殖活動」に関して誰にも負けないような独自の視点のエントリーを毎日書き続けるブログをアルファブログとは呼ばない、というのは私にはどうもしっくりと来ない。

 その意味では、毎年のように「アルファブロガーを選ぶ」こと自体に無理があるのではないかと思う。特にその選択基準に、「読者数が多い」「多くの人が楽しめる」を含めたとたんに、上に書いたようなせっかくの「ウミウシの生殖活動」ブログを否定してしまうことになる。毎年「アルファブロガー選び」をすることが多くのブロガーをページビューやブックマーク稼ぎに走らせてしまうとしたら、主催者の意図とは逆にブログのクオリティの低下を招いてしまうのではないかと少し心配である。


変化をもたらす立場に立った方が有利だ、という話

 読んでいた資料に出て来た William Pollard という人の発言が気に入ったのでここで紹介する。

Without change there is no innovation, creativity, or incentive for improvement. Those who initiate change will have a better opportunity to manage the change that is inevitable. by William Pollard

 訳せば、「変化なしでは、イノベーションも、クリエーティビティも、より良くするためのインセンティブもない。避けることができない変化が起こる時には、変化を自ら起こす立場に立った人の方がその変化をコントロールするチャンスがある。」


Apple 、iPhone用のSDKを来年二月にリリース:待望のiPhone向けのネイティブ・アプリの開発が可能に

 たった今アップルのホームページで発表されたばかりの資料。Steve Jobsが自ら書いたニュースリリースだ。ざっと訳してみる

iPhone向けのサードパーティ・アプリケーション
 思い切って言ってしまおう。サードパーティによるiPhoe向けのネーティブなアプリケーションが欲しいんだ。2月には開発者の手にSDKを渡すつもりだ。iPhoneのまわりに活気に満ちたサードパーティ開発者のコミュニティを作り、何百もの新しいアプリケーションをユーザーに届けることにエキサイトしている。iPhoneが持つ革新的なマルチタッチ・インターフェイス、パワフルなハードウェア、そして(他の携帯電話よりも)遥かに進んだソフトウェア・アーキテクチャで、開発者にとって最高のモバイル・プラットフォームを提供できると確信している。

 SDKをリリースするのが2月になってしまうのは、二つの相反するゴールを同時に達成しようとしているからだー開発者にオープンなプラットフォームを提供しつつ、iPhoneユーザーをウィルスやプライバシーの侵害から守ることだ。これは簡単ではない。人によっては携帯電話のウィルスやマルウェアは大した問題ではないと言うが、それは全くの間違いだ。既に現時点で携帯電話用のウィルスは存在する。携帯電話網を通じて、誰も気がつかないうちに一つの電話機から別の電話機に広がって行くウィルスすらある。携帯電話がパワフルになればなるほど、悪意を持ったプログラムはより危険になる。iPhoneは今ある携帯電話の中で最も進化した携帯電話。当然、悪意を持った人たちにとっての一番のターゲットになる。

 いくつかの企業は、既にアクションを起こしている。ノキアの場合、最新の携帯電話の上では、開発者のシグニチャーが入ったアプリケーションしか走らせないという工夫をしている。このアプローチは、携帯電話を「完全にオープンにする」という意味では不完全だが、少なくとも正しい方向への一歩と認識している。我々は、できるだけ多くの開発者にiPhoneのすばらしいソフトウェア・プラットフォームをネーティブなレベルでプログラムすることを可能にしつつ、ユーザーを悪意の持ったプログラムから守る、ということを実現するべく努力をしている。

 開発者たちには、あと数ヶ月だけ我慢してほしい。そうすれば、その後何年間もの間、サード・パーティ・アプリケーションをiPhoneの上で安全に走らせることができる。

スティーブ

追伸:このSDKを使えば、開発者はiPod touch向けのアプリケーションも作ることが可能になる。


ESPN MVP が FieceMobile の Top 10 App 入り

Espn_menu ESPNとUIEvolutionの関係はすでに5年ぐらいになる。ESPNによるMVNOビジネスの失敗などの紆余曲折があったものの、MVNO端末向けに作ったアプリ(全米の各種スポーツのリアルタイムスコア、ビデオ、各選手の統計データなどが簡単にアクセスできるアプリケーテョン)をVerizonのVCastサービス向けのダウンロード型のアプリケーションとしてリニューアルし、ようやくESPNの(そしてUIEvolutionの)フラグシップ・アプリケーションとして認められるようになったのは何よりも喜ばしい限りだ。

 この件でも明らかになったことだが、結局のところは「技術そのものの価値」を売ろうとしてもなかなかビジネスにならず、顧客(この場合は ESPN)、もしくは顧客の顧客(いつでもどこでもスポーツ情報に触れていたいスポーツおたくたち)にとって本当に価値があるものは何かを見極めた上で、それを可能にする会社としてなくてはならないポジションに自分自身を置くことが必要。この場合は、うちの会社がこだわる「徹底的なおもてなし」とマーケットのニーズがちょうど良い具合にマッチしたのでうまくいったのだ。

 「それが分かっているなら、なんでUIEvolutionはもっともっと大きな会社になっていないの?」とツッコまれそうなので説明しておくと、それはまだまだ「打率」が低いから。「これぞ」と思って作ったアプリが市場で思うように売れなかったり、パートナーの都合で日の目をみなかったりすると、その苦労も水のアワである。

 そうは言っても、このESPN MVPだけでなく、MySpaceと共同開発したMySpace Mobileも順調に売り上げは伸ばしているし、オンデマンドTV社向けのサービスのUIもとても評判が良い。結局のところは、こうやって地道に一歩ずつ業界での地位を築いて行くしかないわけで、その意味でもこの受賞は喜ばしい。

Like a franchise quarterback stuck on a last-place team, the comprehensive mobile sports news, video and fantasy application ESPN MVP got lost in the shuffle as part of the Worldwide Leader in Sports' ill-fated and short-lived ESPN Mobile venture. After the MVNO crashed and burned, ESPN teamed with Verizon Wireless to resurrect the app for exclusive distribution via the operator's V Cast platform--no longer tied to an overpriced handset and flawed business model, ESPN MVP offers pretty much everything your average SportsCenter junkie could want from a mobile service. Highlights include real-time play-by-play updates from across the pro and collegiate sports landscape, personalization tools enabling subscribers to spotlight their favorite teams and players, exclusive commentary from ESPN columnists, and fantasy alerts (e.g., injury and substitution notifications, league updates and information, and player statistics). Also available from Verizon Wireless: ESPN Mobile TV, a 24-hour V Cast channel featuring news and commentary, real-time scores and updates, and live game and event coverage, most notably more than 75 NCAA football match-ups.

ESPN MVP - Mobile Apps, Mobile Applicationより引用】


教えながら学ぶRuby:「Rangeの積を求める」をやってみた

 今日は必要もなく早起きしてしまったので、Rubyに感して書かれた過去のブログなどをネットサーフィング。すると、「Rangeの積を求める」に遭遇。この手のものに出会うと、かならず自分で解きたくなるのが私の性分。1年以上の激遅レス。

class Range
 def &(dest)
  return nil if self.max <= dest.min or dest.max <= self.min
  return ([self.min, dest.min].max..[self.max, dest.max].min)
 end
end

 Rubyでmin/maxをどう書けば良いのか分からず少し苦労してしまったが、Arrayを使うのだと一度理解してしまえば簡単。たかがmin/maxのためにオブジェクトを作るという点にはどうも抵抗があるが、これは慣れるしかないのだろう。


オブジェクトを次々に渡す「Ruby Filter」ってどうだろう

 Rubyに慣れようと、コマンドライン・ツールなどを作ってみることにしたのだが、すでにUnixに存在しているgrepなどを作っても仕方がない。そこで、指定したブログのURLからHTMLページをHTTP GETで取得し、それをパースしてATOMやRSSフィードのURLを見つけて、それをさらにHTTP GETで取得してタイトルだけ表示する、というツールを作ってみることにした。

 できるだけRubyらしい作り方をしようと思いついたのが「Ruby Filter」。Unixのフィルターのようにそれぞれは単一の機能を持ったプログラムをパイプでつなげて複雑なことをさせる。ただし、フィルターからフィルターに渡すものは単なるテキストではなく、オブジェクトのテキスト表現だ(次のフィルターはそのテキストをevalしてから入力として利用する)。

 上のブログのURLからRSSフィードを取り出すケースだと、

 parseURI | getHTTP | parseHTML | extract rss10 | parseURI | getHTTP | parseRSS | eachPrint title

という組み合わせで実現できる。

 このブログのURL "http://satoshi.blogs.com/" を食わせた場合の処理は以下の通りになる。

ステップ1. parseURI
 入力: "http://satoshi.blogs.com/"
 出力: { :port=>80, :path=>"/", :scheme=>"http:, :host=>"satoshi.blogs.com" }

ステップ2. getHTTP
 入力: { :port=>80, :path=>"/", :scheme=>"http:, :host=>"satoshi.blogs.com" }
 出力: "<!DOCTYPE html ...(中略)...</html>"

ステップ3. parseHTML
 入力: "<!DOCTYPE html ...(中略)...</html>"
 出力: {:rss10=>"http://satoshi.blogs.com/life/index.rdf", rss20=>"http://satoshi.blogs.com/life/rss.xml", :atom=>"http://satoshi.blogs.com/life/atom.xml", :title=>"Life is beautiful"}

ステップ4. extract rss10 (注:パラメータが必要)
 入力: {:rss10=>"http://satoshi.blogs.com/life/index.rdf", rss20=>"http://satoshi.blogs.com/life/rss.xml", :atom=>"http://satoshi.blogs.com/life/atom.xml", :title=>"Life is beautiful"}
 出力: "http://satoshi.blogs.com/life/index.rdf"

ステップ5. parseURI
 入力: "http://satoshi.blogs.com/life/index.rdf"
 出力: { :port=>80, :path=>"/life/index.rdf", :scheme=>"http:, :host=>"satoshi.blogs.com" }

ステップ6. getHTTP
 入力: { :port=>80, :path=>"/life/index.rdf", :scheme=>"http:, :host=>"satoshi.blogs.com" }
 出力: "<?xml version=...(中略)...</rdf:RDF>"

ステップ7. parseRSS
 入力: "<?xml version=...(中略)...</rdf:RDF>"
 出力: [{:url=>"http://satoshi...", :title=>"..."}, {:url=>"...", :title=>"..."}, ...]

ステップ8. printEach title (注:これだけは出力が人間向け)
 入力: [{:url=>"http://satoshi...", :title=>"..."}, {:url=>"...", :title=>"..."}, ...]
 出力: (人間向けの)タイトル一覧

 結構面白いと思うんだがどうだろう。

 参考までにソースコードを乗せておく(注:Ruby初心者なので、あまり良いコードではないかも知れない)。

parseURI

#!/usr/bin/ruby
require 'uri'
require 'filter'
Filter.evalStdin
uri = URI.parse($val)
ret = {:scheme=>uri.scheme, :host=>uri.host, :port=>uri.port, :path=>uri.path}
p ret

getHTTP

#!/usr/bin/ruby
require 'net/http'
require 'filter'
Filter.evalStdin
Net::HTTP.version_1_2 # omajinai
Net::HTTP.start($val[:host], $val[:port]) { |http|
ret = http.get($val[:path])
p ret.body
}

parseHTML

#!/usr/bin/ruby
require 'filter'
Filter.evalStdin
ret = { :title=>nil, :rss10=>nil, :rss20=>nil, :atom=>nil }
ret[:title]=$1 if /<title>(.*)<¥/title>/ =~ $val
ret[:rss20]=$1 if /<link.*title="RSS 2.0".*href="(.*)".*¥/>/ =~ $val
ret[:rss10]=$1 if /<link.*title="RSS".*href="(.*)".*¥/>/ =~ $val
ret[:rss10]=$1 if /<link.*title="RSS 1.0".*href="(.*)".*¥/>/ =~ $val
ret[:atom]=$1 if /<link.*title="Atom".*href="(.*)".*¥/>/ =~ $val
p ret

extract

#!/usr/bin/ruby
require 'filter'
key=ARGV.shift
Filter.evalStdin
p $val[key.to_sym]

parseRSS

#!/usr/bin/ruby
require 'rexml/document'
require 'filter'
Filter.evalStdin
ret=[]
doc = REXML::Document.new $val
doc.elements.each('//item') { |e|
url=e.attributes['about']
item = { :url=>url, :title=>nil }
e.each_element('title') { |ee| item[:title]=ee.text }
ret.push(item)
}
p ret

printEach

#!/usr/bin/ruby
require 'filter'
key=ARGV.shift.to_sym
Filter.evalStdin
$val.each { |e| printf "%s¥n", e[key] }

filter.rb

class Filter
def self.evalStdin
input = "$val="
until $stdin.eof?
input += gets
end
eval(input)
end
end


書評:艶っぽさなら「吉原手引草」

 ここのところテクノロジーの話題ばかり続いたので、今日はひさしぶりの書評。いつものようなビジネス書や啓蒙書ではなく、小説。それも、江戸時代の吉原の花魁(おいらん)を主人公にした「吉原手引草」。

 この手の時代小説は、忠臣蔵から鬼平版課長鬼平犯科帳まで幅広くこなす時代小説ファンである私の妻の守備範囲。普段は彼女の本には手を出さない私だが、帯の「直木賞受賞!」に説得されて手に取り、一気読み。なかなかのエンターテイメントである。

 読んでみて納得できたのが、この本が直木賞を受賞した理由。吉原の花魁を主人公にしながら濡れ場はなく、その意味では決して「文学を気取ったエロ本」ではない。しかし、テーマがテーマだし、作者(松井今朝子)が使う微妙な言い回しで、全編に何とも言えない色っぽさが漂う小説なのだ。これが女流作家に書かれたものであり、エロとははっきりと一線を引いた色っぽさというか艶っぽさが直木賞を受賞させたのだろう。エロ本ではなく、艶(つや)本とでも呼ぶべき本である。


教えながら学ぶRuby: 言語を拡張したくなる衝動に関して

 少しMBAの勉強の方が一段落したので、今日はRubyの勉強。「Ruby本」にサンプルとして掲載されているチャットのプログラムを色々な技巧を使って「どこまで美しくできるか」を試みるのが今日の課題。そこで悩んでしまったのが、「やたらと言語を拡張したくなる衝動」を押さえるべきかどうか。Rubyの場合、すべてのものがオブジェクトで、かつ、すでに存在するクラスにメソッドを自由に追加できるので、FixNumだとかNilClassなど基本的なクラスの再定義をすることにより、あたかも言語を拡張しているような効果を生むことが可能なのだ。

 今日書いていて気に入らなかったのは下のコードの太字の部分。

while(!@err)
 r,w,e = select(@socks)
 next if r.nil?
 r.each { |sock|
  case sock
  ...
 }
}

 これは、selectから返されたrがnilだった場合に、それに続くr.eachでエラーにならないようにするための処理だが(注:実際にはタイムアウトのパラメターを与えていないのでnilが返るはずはないのだが、とりあえずそれは無視していただきたい)、この一行がどうにも読みにくくしている。

 そこで私がすかさず思ったのは、「NilClassにeachメソッドを加えれば良いじゃん」である。

class NilClass
 def each
 end
end

「nilのすべての要素に対して何かをする=何もしない」なので、論理的にも正しい。こうしておけば、上のプログラムは、

while(!@err)
 r,w,e = select(@socks)
 r.each { |sock|
  case sock
  ...
 }
}

とすることができ、ずっと読みやすくなる。

 Smalltalkもそうであったが、Rubyを書いていると、こんな風にシステムで提供されているクラスを再定義したいという衝動に駆られる。こんな衝動に、ちまたのRubyistたちはどう対処しているのだろう?

 上の例のように、システムクラスを拡張することにより、(その拡張を理解した)自分自身にとってのコードの可読性を上げることは可能だ。しかし、複数の人間が関わるプロジェクトでそれぞれのエンジニアが勝手にシステムクラスの再定義を初めてしまっては支離滅裂になってしまう。かといって、いちいち相談していては効率が悪い。結局のところは、Railsのように一人とか二人とかいったごく少数の人がフレームワーク構築の一環としてシステムクラスに手を入れ、他の人たちはその上に乗っかるようにプログラムを作る、というスタイルが現実的なのだろうか 。増井さんが指摘したように、確かにこれがRailsを使う大きなメリットの一つ、なのかも知れない。


Haloを作ったBungie StudioがMicrosoftからスピンアウトした件について

 XBox360がそもそもパッとしない日本では大したニュースではないのかもしれないが、発売後わずか1週間で$300millionを売り上げたHelo3はこちらでは大きなニュースだ。先日も、スポーツクラブで「Halo3が楽しくて」と隣で話している人を見ると初老の女性二人。どうみても「典型的なゲーマー」ではない。

 しかし、Helo3の売り上げよりも業界を驚かせたのは、ほぼ同時にアナウンスされた、Haloを作ったグループ「Bungie Studio」がMicrosoftからスピンアウトするというニュース。

Bungie has 113 employees. Evan Wilson, a video game industry analyst with Pacific Crest Securities, said that leading employees of Bungie had bought out majority ownership from Microsoft. “Bungie and Microsoft clearly had different creative directions,” Mr. Wilson said.

Halo Games Maker to Be Independent of Microsoft - New York Timesより引用】

 予想するに、Halo3のリリースとともにLockup期間が過ぎたBungie Studioの連中をつなぎ止めておくことが出来なくなったMicrosoftがやむなく彼らの独立を認めざるをえなかった、というのが真相だろう。

 戦略的な買収がさかんな米国では、買収時に「二年間」とか「次のプロダクトのリリースまで」という条件で、キーとなる従業員を必ずLock-upする。Lock-upと言っても、鍵をかけた部屋に閉じ込めるわけではなく、買収時に彼らが受け取るはずのお金(もしくはMirosoftの株)の一部をLock-upの条件が終わるまで渡さずに「保留」しておく、という手法である。

 Lock-up期間中に買収したメンバーがうまく親会社の一部として機能するようになっていれば問題はないが、Bungie Studioのように独立したビジネスユニットのように運営されて来た場合、おうおうにしてLock-up期間が終わって「保留」されていたお金なり株を受け取ったとたんに主要なメンバーが辞めてしまう、ということは日常茶飯事。Lock-up期間が終わってまで会社に残っていると「どうして残っているの」と不思議がられるぐらいだ。

 日本人の感覚では理解できないかも知れないが、Bungie Studioの主要なメンバーが、Halo3の発売前に「俺はHalo3を出したら辞めるつもりなんだ」と大っぴらに発言したりしていたことは十分に想像できる。それは往々にしてまわりの人に対する「お前も一緒に来ないか?」という暗黙のシグナルだったりする(大っぴらに人を引き抜くことは出来ないが、相手が「俺も一緒に辞める」と言ってくる分にはかまわない)。そんな風にBungie Studioから人が次々にいなくなってしまい、Halo4が出せなくなるぐらいなら、スピンアウトさせた上でしばらくはXBox向けにHaloを作り続けてもらった方が良い、とMicrosoftとしては判断したのだろう。

 抜け目のないMicrosoftのことだから、「Halo4と5はXBox360のみに出す」ぐらいの付帯条件をつけてスピンアウトを認めたに違いない。Bungie Studio側としては、その程度の条件を飲もうとも次のHaloからは大半の利益を自分たちのものに出来るとなればそれぐらいのリスクを背負っても当然、とう判断だろう。