Life is beautiful: GoogleがYouTube買収の詳細を発表。受付嬢が１億５千万円って…
WSJによると、YouTubeの買収に関する詳細が昨日発表されたそうだ。YouTubeの創業者二人および投資家のセコイア・キャピタルがこの買収によって手に入れたGoogleの株とその時価総額は以下のとおりである（"＋…" となっている部分は、創業者を繋ぎ止めておくために別個に設置されたトラストにしばらく保留される分）。 Chad Hurley: 694,087 + 41,232株 （時価総額$345.6 million、約410億円） Steve Chen: 625,366 + 68,721株 （時価総額$326.2 million、約390億円） Sequoia Capital: 941,027株 （時価総額 $442.3 million、約530億円） ベンチャー企業が成功したかどうかをはかる「ものさし」はいくつかあるが、創業者や株主のためにどのくらいのリターンをもたらしたか、という「
技術者にも必要な「もうける決意」
「日経エレ１０月９日号」の「日本半導体産業・復活への提言（湯之上隆著）」。半導体産業に限らず、ソフト・家電・ゲーム・ウェブサービスなどを含んだ広い意味での「この業界」で生き残るために必要な提言を含んだ、すばらしいペーパーだ。 オンラインで全文を読んでいただくことが出来ないのが残念でしかたがないが、このペーパーにこめられた著者のメッセージが集約された部分を引用させていただく。 ある日本のメーカーの技術者は「開発部門の技術者は、開発にしか興味がない」と証言した。別の技術者は「おおくの技術者は、コスト削減を工場の仕事と考えている」と話した。（…中略…）一方、Intel社の技術者は「ある開発プロジェクトに対する社内評価は、どれだけの最終製品をいくらで出荷したかが判断基準になる」という。開発者のボーナスも最終製品の利益で決まる。これが、開発段階で徹底した低コスト化を目指すインセンティブになっている。
Life is beautiful: スパムメールに関する一考察
今週は、UIEJのメンバーの間で、ユーザーから取得したメアドの扱いに関してさまざまな議論が交わされた。特にスパムメールに関する意見交換が興味深かったので、私なりのスパムメールに関する考え方をまとめてみた。 ・内容は何であれ、ユーザーにスパムだと思われたらそれはスパム ・スパムだと思われたら読んでもらえない ・読んでもらえないメールを送ってもしかたがない ここで問題となるのは「ユーザーに一度スパムを送る企業だと一度思われてしまうと、メールを一切読んでもらえなくなる」点である。 例えば、私は、mixi、GREE、はてな、シマニティの４つのSNSサービスに登録しているが、送られてきたメールを読むのはmixiとはてなのみである。Greeとシマニティからのメールは内容を確認せずに削除している。なぜこんな行動をとるのか、自分なりに解析してみた。 ・Greeとシマニティは毎日メールを送って来るが、mix
Life is beautiful: Edward Tufteに学ぶプレゼンのスキル
「スティーブ・ジョブスに学ぶプレゼンのスキル」は、このブログの人気エントリーの一つだが、ことプレゼンに関して私が師と仰ぐのはEdward Tufteである。日本ではあまり名が売れていないようだが、米国では「データのプレゼン技法」に関しては第一人者で、本も何冊も書いているし、全米各地でセミナーも行なっている。 私自身も、一日セミナーに参加したことがあるが、膨大な量の実例を集めて、それぞれのどこが優れているか、どこがダメなのかを的確に分かりやすく説明してくれるTufteは、まさに「プレゼンの神」であった。彼からは色々なことを教わったが、特に心に残り、今でも常に実戦しようと心がけていることは、 ・文字に頼らず、図を効果的に使うこと ・一度に見せる情報量を絞ること ・意味を持った色使いをすること の三つである。特に最後の「色も情報を運ぶことができる」という点は、それまで意識したことがなかっただけに
Life is beautiful: Amazon AffiliateがGoogle AdSenseに勝てる理由
今まで、このブログでも何回もGoogleとMicrosoftを比較して、Googleにばかり軍配を上げてきた私だが、Googleに弱点が全く無いと思っているかというと決してそんなことはない。そこで、今日はこのブログでも採用しているAmazon AffiliateとGoogle AdSenseとを比較した場合、どうして私が「長い目で見たらAmazon Affiliateの方が強いかも知れない」と思っているかを述べてみたい。 まずは、このブログでの過去数ヶ月の実データを元に、Amazon Affiliateの結果をまとめると以下のようになる。 ・測定単位： 10万ページビュー ・クリック数： 約2500クリック ・注文数： 約150点 ・アマゾンの売り上げ： 約25万円 ・紹介料： 約1万５千円 まあ妥当な数値である。クリック率は約2.5%。クリックから実際の注文へのコンバージョン率は約6%で
StarOffice/OpenOfficeがMicrosoft Officeに勝てない理由
このことは以前から書こうと思っていたのだが、誤解を招かずに説明するのが難しいので、しばらく棚にしまっておいた。しかし、今回「Blue Ocean Strategy」（日本語訳：ブルーオーシャン戦略）を読み始めて、なかなか良い表現を見つけたので、それを利用して説明する。 詳しくは、この本の第二章、「Analytical Tools and Frameworks（分析のためのツールとフレームワーク）」を読んでいただくのが一番良いが、あるマーケットを見たときに、既存の商品の「主要な要素（principal factors）」を抽出して、そこで真っ向から血みどろの戦いを挑むのが「red oceanの戦い」であり、逆にその要素から幾つかの項目を思い切って切り捨て、それとは別に新しい価値を生み出す要素を追加して、真っ向からの戦いを避けるのが「blue oceanの戦い」なのである。 この観点から St
Essence of AJAX
It is great to see Yahoo proves that creating AJAX-style web application does not necessary require Javascript or even XML (see "Yahoo launches next battle in map wars"). The essense of AJAX-style applications represented by Google Map service is not in its implementation but in its programming style and user experience. Google happened to choose Javascript and XML over HTTP, but it can be easily
Web2.0時代らしいエンジニアのクリエイティビティの引き出し方
Foxnews の "Lerning From Google" という記事を読んだ。特に目新しいことは書いていないのだが、その冒頭に書いてある、 The top executives at Google recently admitted that they kind of let their employees invent and develop whatever they think is cool and the company has no problem putting it online to see what happens. 【意訳】Googleの重役たちは、エンジニア自身がカッコいいと思うものであれば、何であれ（誰にも了解を取らずに）作ってしまって良く、会社としてもそれをそのままサービスとして公開してしまってユーザーがどう反応するかを試してみる、というやり方が全然かまわ
マイクロソフトがついにオンライン版の Windows と Office を作ると発表
社員の一人が、「マイクロソフトが遂にオンライン版のWindows と Office を発表」というセンセーショナルなタイトルの記事へのリンクを送ってくれた（参照）。 「発表って、もう出来ているのか！オンライン版のWinodwsってなんだ？」と記事を読んでみると、厳密には「そういうものを作ることにしました」というイニチアチブの発表に過ぎない。少しはデモがあるらしいが。うーむ。 さらに読み進めると、Windows Live はメッセンジャー、オンライン・メール・サービス（hotmailとは別のものを作るようだ）、ストレージ・サービスなどを組み合わせたサービスだそうだ。どこが新しいんだろう？Yahoo、Google との戦いに本気になったと宣言したいのだろうが、これを Windows Live と呼ぶのはかなり強引だ。MSN ブランドではもう戦えないととうとう観念したのだろうか。 Office
「Software is service」の心構え
社員向けの英語ブログの３番目のエントリーは、「Software is service: Why is it so hard for software engineers to fully internalize it?」というタイトル。私の会社には、Microsoft、Apple、PalmなどでOSとかIDEなどの開発経験のある優秀なエンジニアが集まっているのだが、伝統的なソフトウェア作りでの成功経験があるからこそなかなか理解してもらえないのが、「Software is Service」の心構えだ。今回のエントリーは、そんな彼らのためのメッセージ。 少し前までのソフトウェア作りのプロセスは、（１）マーケットやテクノロジーのことが分かっている賢い人たちを集め、（２）彼らに作るべきプロダクトをデザインさせ、（３）必要な人員を集めて作り込み、（４）ある程度できたところでベータ版としてリリースし、
Life is beautiful: リーダーシップについて思い出したこと
アメリカの人口の１２％が「貧困層」であり、そう言った人たちは日々の食事も満足に食べることの出来ない生活をしている、などの報道は、米国に住んでいると新聞やニュースでは良く見かける。しかし、中流以上の生活をしている我々にとってみれば、生活圏がほとんど重ならない彼らの生活の実態は、なかなか実感として捉えられず、単なる「統計データ」としてしか頭に入って来ない、というのが正直な所である。 しかし、今回のハリケーンで、彼らの生活の基盤がいかにもろいものか、そして、その数がものすごいものであることを、映像を通して目の当たりに見させられることになったことにショックを受けている人はとても多いはずだ。 今回のハリケーンの被害は、政府からの非難命令にも関わらず、逃げるための交通手段も持たず、逃げたところで避難先のホテル代も払うことが出来ない人達が「予想に反して」１０万人も市内に残ってしまったために大きくなってし
ケイタイでAjax(2): PC/Mac上のエミュレーター
先週、ケイタイAjax版RSSリーダーを初披露したが、通信事業者側が課した制限のために、ドコモ版しかサンプルとして提供できなかった。インターネットを通じてさまざまな技術を未完成時から披露し合って切磋琢磨することが可能になった今の時代には、auやVodafoneの定めている『通信事業者から許可をもらったアプリしか携帯電話にダウンロードできない』という制限は、大きな足かせになる。 なんとかして、ドコモの携帯を持っていない方たちにもデモを見てもらう方法はないものかと頭を悩ませていた所に、シアトルのエンジニアから朗報が届いた。UIEngine（自社製スクリプトエンジン）がJava Appletとして動くようになったというのだ。これがあれば、パソコンのブラウザー上でこのアプリのエミュレーターを作ることができる。 「すぐにデモに使いたいので、JARファイルを送ってくれ」というと、案の定「まだ出来たばか
Google Map で遊ぶ（３）： 地図ブックマーカー
Google Map や Amazon Web Service のような「公開型」のウェブ・サービスのすごい所は、何の利害関係も無い第三者がそれを利用して新たなウェブ・アプリケーションを作れてしまう点である。特に複数のウェブ・サービスを組み合わせると、色々と面白いことが出来る。 その実例として、Google Map と はてなブックマークを組み合わせて、「地図ブックマーク」の仕組みを作ってみた。これを利用すれば皆で Google Map の衛星写真を使って見つけた場所をブックマークしてコメントを共有しあったりして遊ぶことが出来るのである（すぐ下のリンクをクリックすれば遊べる）。 Google Map ブックマーカー 例として、幾つか私自身もブックマークしてみた。 ・代々木公園 ・新宿都庁ビル ・東京ドーム ・セフコ・スタジアム ちなみに、このアイデアは今日乗ってきたシアトル→東京便の中で思
Google Map API で早速遊んでみた
つい昨日、『私自身、もしLonghornのベータ版で遊ぶか、Googleの新しいウェブ・サービスのベータ版で遊ぶかの選択肢を迫られたら、迷うことなく後者を選ぶ』と書いたばかりだが、偶然とは恐ろしいもので、ちょうど Google が Map API のベータ版をリリースしたことを発見した。そこで早速、遊んでみた。 会社の近所の地図を表示し、そのまわりの幾つかの場所にマーカーを付け、クリックすると説明が出るようにしたのだ。もちろん、マウスで地図をドラッグしてスクロールさせることも出来るし、Satelite ボタンを押して写真に切り替えることもできる。こんなウェブ・アプリケーションが３０分ぐらい遊んだだけで出来てしまうのだから、すばらしい時代が来たものだ。 ［追記］ 参考までにソースコードを添付。ただし、ソースコード中の "key=..." は、このブログのURL用に取得した専用の Maps A
Life is beautiful: 恋の連立方程式、「パートナー探し」の最適化アルゴリズムに関する一考察
「自分にできるだけ相応（ふさわ）しいパートナー」を見つけることは、我々人間にとって、人生の最も重要なのテーマの一つでもある。しかし、そのプロセスである「恋愛」や「お見合い」に関して、なぜか今までシステマティックな考察がされて来なかったように思える。そこで、今回はその「パートナー探し」のプロセスをモデル化・数値化することにより、最適なアルゴリズムを見つけようと思う。 まずは、「自分にできるだけ相応しいパートナーを探す」というあいまいな問題を、もう少し明確にモデル化された問題に単純化する。もちろん、単純化するとはいえ、あまり現実とかけ離れていては役に立たないので、現実味を壊さない程度の単純化を行う。 ［モデル化された問題］ 結婚適齢期の女性が、これから１０人の男性と順番にお見合いをして、その中から結婚相手を見つけることにしたとする。相手の意思は無視して良く、「この人と結婚したい」と宣言した時点
Life is beautiful: ビル・ゲイツの面接試験―私の場合
マイクロソフトの採用面接がユニークであることは、「ビル・ゲイツの面接試験－富士山をどう動かしますか」という本で一時話題になった。もちろん、私自身もマイクロソフト本社で面接官として数え切れないほどのエンジニアの面接を担当し、自分なりに工夫して作り出した試験問題を幾つも用意していた。今日は、その一つを披露して、得意のうんちくを展開しよう。 ［問題］ 二次元座標上に、それぞれの辺がX軸・Y軸と平行に置かれた長方形Aと長方形Bがあるとする。その時、長方形Aと長方形Bが一部でも重なるかどうかを判断する条件式を書け。フォーマットは、CやJavaなどのコンピューター言語でも良し、単なる数式でも良い。制限時間は３０分。ただし、考えていることを声に出し、ホワイト・ボードを使って自分の考えのプロセスを説明しながら解くこと。 もし、これからプロのソフトウェア・エンジニアを目指そうという理科系の学生がこのブログを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
