NTTの株価総額が世界一だった時に、Microsoftに転職した理由
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
Life is beautiful: 優秀なナースがいるとシステムがなかなか改善されないという話
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
Python Hack : 噛めば噛むほどおいしくなるクロージャの話
最近 JavaScript を書く機会が増えているが、それに従って自分のコーディングスタイルが少しづつだが変化してきているのが分かる。もともと「コードの読みやすさ」や「実行効率」にとことんこだわるタイプだが、（JavaやC++になくて）JavaScriptやRubyにあるクロージャや無名関数が私のコーディングスタイルにとてもマッチしているからだと思う。 簡単な例を紹介しよう。Pythonで書かれた config.py というモジュール。config.yamlという設定ファイルを読み込んで Dictionary として返す config.get() という関数。普通に実装すると、以下のような感じになる。 import yaml _config = None def get(): global _config if not _config: data = open('config.yaml')
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
Life is beautiful: Excelのチャートを簡単にブログに貼付ける方法
ちょっとしたチャートとかグラフを作る時にはやはりExcelが便利だが、作ったチャートをブログに貼付ける方法を知らない人が多いことを発見したので、私が採用している方法をここで披露。 1. Excelでチャートを作る 2. 作ったチャートを選択し、編集→コピー 3. Wordで新しい文書を作成 4. その文書に編集→ペースト 5. その文書に適当な名前（例えばdocument1）を付けてウェブページとして保存 こうすると、Excelで作ったチャートが、ブログに貼付けることができるPNGというファイル形式で新しいフォルダー内（上の例だとdocument1_files内）に作られるので、それをブログに貼付ける。 例えば、私のブログに訪れる人のOSを月ごとにグラフにしたのがこれ。 私が使っているのは、Microsoft Office 2008 for Macだが、他のバージョンのオフィスでも基本的に
HTML+JSでプレゼン、YAML版も作ってみた
一つ前のエントリーに対して、アップルの増井さんから「もうちょっとシンプルな『メタ言語』で良いんじゃないでしょうか。YAMLみたいなのとか。」という良いアイデアをいただいたので、早速実装。先のサンプルが、ページ内にこんな感じで直接記述できる。 ==iAnime.js: Benefits *Small footprint (<6KB compressed) *Lightweight (runs fine on iPhone) *Works well with jQuery.js and prototype.js *Free (MIT license) ==iAnime.js: Power *Easy to use (only three methods) *Powerful JSON-based animation language *Extensivle ("effects" and "pl
スライドするUIを実現するiSlider.js
iAnime.jsのテスト用に作っていたスライドするUI。書いているうちにライブラリ化したくなったので、これもやはりMITライセンスとしてオープンソース化（Google Code iAnimejsよりダウンロード化）。たて・よこ・ななめ、自由にスライドさせることができることが特徴。"easein", "bounce"などのエフェクトも利用可能。 まずはごく基本的なカード型のUIで横にスライドするもの。 こんどは同じコンテンツを縦にスライドさせるもの。アコーディオンUIと呼ばれることもある。エフェクトに"bounce"を使っている点に注目。 軽いのでiPhone/iPod touchでもサクサクと動くのが特徴。
Life is beautiful: Javascriptクイズ（中級者向け）：無名関数と実行効率の話
Javascriptを使い始めたばかりの太郎君に、上司の花子さんから「スタイルシート用のスタイル名をDOMからアクセス可能なプロパティ名に変更するJavascriptのライブラリを作って欲しい」という課題が与えられました。何のことか分からずにポカンとしている太郎君に、花子さんは「"font-style" を"fontStyle"に変更する関数を作ればいいのよ」と言い残して立ち去ってしまいます。 O'ReillyのJavascript本としばらく格闘した太郎君は、やっとライブラリを完成させます。 function capitalize(str) { return str.charAt(1).toUpperCase(); } function style2prop(str) { return str.replace(/-[a-z]/g, capitalize); } "font-style"が
Javascriptの黒魔術＝クロージャを宮沢賢治風に説明してみる
先日のエントリーで、「Javascriptの黒魔術」と呼んだのはクロージャのこと。関数呼び出しの際に一時的に作られただけのはずのローカル変数が、ある条件が整うとその関数の実行が終わった後もゾンビのように生き延びて参照が可能、というのがJavascriptのクロージャだ。 これを宮沢賢治風に書いてみるとこんな感じになる。 ある町でふらりと一人で立ち寄ったカラオケ・スナックは、カウンター席しかないとても小さな店だが、客のノリが良くてとても気持ちよく歌えた。おかげでマイクが離せなくなってしまった私に、帰り際にマスターが「そんなに気に入ったのなら、そのマイク持って返ってもいいですよ」と言う。 言われるままに持って返ったマイクは、しばらく家のテレビの横にだらしなく置いてあったのだが、ある晩に歌番組を見ていると私がカラオケで十八番にしている曲が流れるものだから、おもわずそのマイクを手に取って歌ってみた
ウェブサービスAPIにおける『成りすまし問題』に関する一考察
先週の末に、はてなのウェブ・サービスAPIを使ったMash-upアプリをFlash上で作り始めていきなりつまずいたのが、Cross-Domainセキュリティ。satoshi.blogs.comから取得したswfファイル上のActionScriptからb.hatena.ne.jp下にあるRSSフィードだとかXML-RPCにアクセスができないのだ。 「確か方法があったはず」と調べてみると、はてな側がサーバーにcrossdomain.xmlというファイルを置いて明示的にCross-Domainアクセスを許可していなければならない、という。そこで見つけたのが、「Flashから各APIの操作、データのロードができるよう、サーバ上に「crossdomain.xml」というポリシーファイルの設置をお願いしたい。」というはてなアイデアへのリクエスト。2006年の2月にリクエストが出されているのだが、11月
Ruby on Rails: なぜActiveRecordが必要なのか？
Railsの勉強がしばらくストップしてしまったので、今日はビデオを見てお勉強。Rails Envyの「ActiveRecord Tutorial」は長さも２５分とちょうど良いし、「ActiveRecordとはなんぞや」を具体例を交えて簡潔に教えてくれるのでとても良い勉強になる。 英語だが、冒頭の部分を乗り越えればあとはプログラミングの話なので、日本人にもそれほど難しくないはず。念のため、オープニングの部分のみ、超訳しておいた。 ActiveRecordのアイデアは、いったいどこから来たのか？ まずは"Active Record"の意味から （ActiveRecordではない点に注意） "Active Record"とは、デザイン・パターンの一つ。 どうやってデータベースにアクセスするか？ SQLにプログラムから直接アクセスする方法もあるが...ちょっと不便 データベースのテーブルをオブジェ
英語うんちく
今日の単語はdeplete。「減らす」「使ってしまう」などの意味である。 The fire had depleted the game in the forest. は、 山火事で森の動物たちがずいぶん減ってしまった となる。ちなみに、ここでのgameは日本語で言うゲームのことではなく、主に狩猟の対象となる動物たちのことを指す。 同じくdepleteを使った例としては、depleted uranium（劣化ウラン）がある。自然に存在するウランから、原子力発電や核爆弾に使用するウラン235を取り除いた「残りかす」のことで、主にウラン238から出来ている。ウランは非常に重い金属なので、弾等に使うと貫通力を高めることが出来、戦車や地下壕の上空からの攻撃などに使われる。米国軍が、アフガニスタン・イランでの戦争で大量に使い、その放射能汚染や重金属汚染の可能性が問題視されているのが、この「劣化ウラン弾
その「頭がいい人は成功して当然」という発想が甘すぎる
はてなの人気エントリーに見つけた「頭のいい人が成功できるかどうかの境目」というanonymousなエントリー。ちょっと彼（そのエントリーの作者）の将来が心配になったのでひと言。 そもそも「頭が良さ」が一つのものさしで計れると思っている点が大間違い。百歩譲って、「旧帝大の大学院にトップクラスの成績で入れるぐらいの学力がある」＝「頭がいい」という彼のものさしを認めたとしても、「俺はこんなに頭がいいのになぜ成功できないのだろう＝頭がいい人は成功して当然」という発想はあまりにも甘すぎる。子供のころから、「東大に入りさえば幸せになれるのよ、○○ちゃん」という母親の一途な価値観だけに踊らされて塾に通い続けた学歴社会の被害者、とで言えば良いのだろうか。 これを読んで思い出したのが、大学時代の同期の一人。成績は文句なくクラスでトップ。ものすごく頭の切れる男で、修士号取得後に霞ヶ関の官僚になったのだが、彼が
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億円） ベンチャー企業が成功したかどうかをはかる「ものさし」はいくつかあるが、創業者や株主のためにどのくらいのリターンをもたらしたか、という「
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
今年の末までにFirefoxのシェアがIEを抜く?!
今月に入ってからGoogle Analyticsをこのブログに導入したのだが、「どんなサーチワードでこのブログにたどりつくのか」とか、「訪問者のブラウザーのマーケットシェア」などを一目で分かる形で表示してくれるのがとても良い。 興味深いのがブラウザーのマーケットシェア。去年の初めに別のツールを使って測定したときは、Firefoxのシェアはまだ２０％と少しぐらいしかなかったのだが、今や約３５％。Safari＋Operaと会わせるとほぼInternet Explorerと肩を並べる。 もちろん、このデータはインターネット全体のデータではなく、このブログの訪問者に関するデータでしかないのだが、このブログに来る人たちの多くが、インターネットのアーリィ・アダプタ（もしくはオピニオン・リーダー）であろうことを考慮すれば、今後の傾向を読む意味でも、このデータには意味がある。 ということで、これから四半期
ブクマコメントに「後で読む」と書かれたら負けだと思っている
こうやってブログを書いていてつくづく思うのは、簡潔で分かりやすい文章を書くことの難しさと大切さ。だらだらと思いついたままに長い文章を書くのは簡単だが、「小粒でピリリと辛い」文章を書くには推敲に推敲を重ねる必要がある。 特にブログの場合は、最初の１～２段落が勝負。そこで読者をグッと引き込み、飽きてしまう前に要点を手早く効果的に伝えて一気に結びの文章に持って行く。スクロールしなければ読めない部分はまず読んでもらえないと思ったほうが良い。ブクマコメントに「後で読む」と書かれたら負けだ。
マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
Life is beautiful: Aクラスの人はAクラスの人を採用したがるが、Bクラスの人はCクラスの人を採用したがる
連休のしめくくりは、DVD「The Incredibles」（日本での題名 Mr.インクレディブル）の鑑賞。Pixar の映画は全て見たと思いこんでいたのだが、これだけを見ていなかったことに「スティーブ・ジョブズ・偶像復活」を読んでいて気が付いて以来、見たくて仕方がなかったのだ。 既に知っている人も多いかも知れないが、「The Incredibles」以前の Pixar の作品、「Toy Story」、「A Bug's Life」などは全て John Lasseter 自らが監督した作品。それを、あえて外部から Brad Bird を招き入れて作らせたのが 「The Incredibles」である。他の Pixar 作品と少し毛色が異なるのも納得できる。 「スティーブ・ジョブズ・偶像復活」を読んでいて、この映画を見たくなった理由は、Brad Bird をこの映画のために Pixar に招き
「50%の完成度でサービスを出す」という言葉を誤解してはいけない
はてなの近藤社長の、「５０％完成度でサービスを出す」という指摘は、まさに「ソフトウェアはサービス」の時代を反映する、ものすごく意味のある言葉だが、万が一勘違いする人がいると困るので、自戒も含めて補足しておく。 ここで言う「５０％の完成度」とは、「サービスとして『完成品』と呼ぶにはまだ機能が十分揃っていない」という意味の完成度を指し、決して「アーキテクチャーや不完全だったり、明らかなバグがあるのにサービスインしてかまわない」という意味ではないので注意が必要だ。 少し前に、私の会社で外部のエンジニアを使ってあるウェブ・サービスを作ったことがあるのだが、慣れていない人にプロジェクトのマネージメントをさせてしまったために（これは私のミス）、一応外見上は動いているものが出来てきたものの、スケーラビリティに明らかな問題があり、ユーザーの数が増えたときに破綻するようなものが出来てきてしまったのだ。 担当
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
