NTTの株価総額が世界一だった時に、Microsoftに転職した理由
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
ビットコインとは
幾つかの理由があり（小学５年生の男の子が一番憧れる職業だ、というのもその一つです）、今年の抱負は「Youtuber になる」ことに決め、早速、第一弾のビデオを配信しました。 とはいえ、ヒカキンのようなエンタメは私のキャラではないので、いつも仕事でやっている「テクノロジーとビジネスのトピックを一般の人にも分かりやすく説明する」ことを、シリーズ化して配信することにしました。 チャンネルのタイトルは、メルマガと同じく、「週刊 Life is beautiful」です。 第一弾のテーマはビットコインにしたのですが、理由は、まともな説明をネット上に見つけるのが非常に難しいからです。 私のようなエンジニアにとっては、ブロックチェーンの仕組みだとか、マイニングマシンの設計などが重要な話ですが、一般の人には理解するのも難しいし、そもそも縁がない話です。 かと言って、ビットコインへの投資（正確には投機）の話
ＭＢＡで学べることより大切な、たった一つの人生の掟
6月1日に上梓した拙著『なぜ、あなたの仕事は終わらないのか？』（文響社）からの引用です。 ◇ ◇ ◇ 突然ですが、私はここでみなさんにお詫びをしなければいけないことがあります。 それは、ここまで長らく私の人生がトントン拍子にうまく進んできたかのように書いてきてしまったことです。 自慢話のようで鼻についた方もいたでしょう。そういう方にはお詫びを申し上げたいと思います。不快な思いをさせてしまったことと同時に、私の人生も決してうまくいったことばかりではなかったからです。 そういった話――すなわち、何かを成し遂げたり幸せな人生を手に入れたりするには、「好きなことに向き合い続けること以外に方法はない」という話――をこれからしていきたいのですが、私の人生の最大の試練は、初めてのスタートアップであるUIEvolutionを立ち上げた直後に訪れました。 起業直後から本当に失敗の連続でした。良いものを作って
TEDxSapporo スピーチ：なぜ、あなたの仕事は終わらないのか
７月の頭に TEDxSapporo で 行ったスピーチのビデオが、ようやく公開されました。６月に出版した『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である」の中でも最も重要なエッセンスを抜き出し、１４分弱のスピーチにまとめてみました。ぜひともご視聴ください。 ちなみに、今回のプレゼンでもっと重視したことは、「普段通りにしゃべる」ことです。普段から「スライドを読むだけのプレゼン」「弁論大会のような不自然なしゃべり」を批判して来た私としては、可能な限り「自然なしゃべり口調」でのプレゼンをしたかったのです。 しかし、実際に練習してみるとそれは結構難しく、「弁論大会のような口調になってしまう」私を乗り越えるには、かなり苦労しました。
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
jQBinder, ブラウザー側でのHTML templateを可能にするjQuery plug-in
一昨日はMVCの話で妙に盛り上がってしまったが、考えてみるとModel/View/Controller間の分離が不十分という話はサーバー側だけの話ではなく、クライアント側にも言える事。事実、私自身も div.innerHTML = "<span class='red'>" + message + "</span>"; みたいなHTMLが混ざったJavaScriptコードを書く事は良くある。特に、最近はJSONとして取得して来たデータセットをリストとして表示するケースが増えて来たが、そんな時に「サーバー側のようなHTMLテンプレートが使えたらいいな」と思う事は良くある。手っ取り早くとりあえず動くものを作るのにはHTML埋め込み型のJavaScriptで良いのかも知れないが、後々のメンテナンスを考えると少なくともModelとViewぐらいはキチンと切り話しておいた方が良い事は確か。 ということ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
