NTTの株価総額が世界一だった時に、Microsoftに転職した理由
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
米国人にとっての捕鯨・イルカ漁
ケネディ大使のイルカ漁に体する発言を「内政干渉」と大騒ぎをしている人がいるが、彼女の発言を理解するには、イルカ漁やクジラ漁が米国人にとって、どんな意味があり、何を象徴するか、を理解する必要がある。 マウイの Whalers Villege ショッピング・センターには、捕鯨博物館があり、そこには捕鯨の歴史が淡々と綴られている。鯨油や鯨蝋（げいろう）が石油の代わりを果たし、鯨ひげがプラスチックの代わりを果たした時代に、その商業的価値のために、大量の鯨を虐殺して来たこと、ラハイナの待ちが捕鯨で発展して来たことなどを、歴史の一コマとして描いている。 捕鯨博物館の出口には小さな映画館があり、鯨がダイナミックに泳いだりジャンプしたりするさまを映し、鯨の生体や、ハワイの観光産業にとっての価値を説明している。 そこにあるのは、捕鯨という「過去」と、観光資源・人類の宝としての鯨の「現在」の対比だ。 つまり、
neu.Node リリースのお知らせ
去年の暮れから準備を進めて来た neu.Node だが、ようやく今日、オープンソース・プロジェクトとして github に公開することができたので報告する。 https://github.com/snakajima/neunode 詳しくは README.md ファイルに書いたが、neu.Node は iOS 上で Node.js の API を使って作った マイクロ・サーバーを走らせる仕組みである。iTunes ストアで配布する iOS アプリに組み込んでも良いし、自分や仲間だけで楽しむ「手作りアプリ」に組み込んでいただいても良い。ライセンスは MIT で、ライセンス料フリーで、非営利・商用、無料・有料の区別なく使える。 neu.Node が目指すのは、新しい形の分散コンピューティングである。「モバイル・デバイスはクライアント、サーバーはウェブ・サービス」という垣根をとっぱらい、全てのモ
非同期APIと例外処理（node.js の domain について）
node.js のような非同期APIを使ったプログラミングに拒絶反応を示すエンジニアが多い理由の一つが、非同期APIと例外処理の相性の悪さだ。 Javascript の場合、例外処理はこんな感じに記述する。 function f(i) { try { throw new Error('an error #'+ i); } catch(e) { console.log('Error caught:', e.message); } } ところが、これに非同期APIが絡むと、とたんに分かりにくくなる。例えば下の例。 function f(i) { try { setTimeout(function() { throw new Error('an error #'+ i); }, 1000); } catch(e) { console.log('Error caught:', e.message)
node.js で「サラリーマンの朝」をプログラムしてみる
先日の「node.js と thread hog の話」には、たくさんのコメントをいただいたが、やはり「イベント駆動型」のプログラミングには抵抗がある人も多いようだ。そこで、JavaScript の無名関数を使ったイベント駆動型のプログラミングの可読性が悪くないことを示すために、「朝７時に目覚まし時計をかけて眠りにつき、朝ご飯を食べ終わったら会社に行く」という典型的な「サラリーマンの朝」をイベント駆動型のJavaScriptで記述してみた。 注目して欲しいのは、素早く出来る「着替える」「顔を洗う」などの動作は割り込み不可な動作なので、通常のプログラミングと同じようにシーケンシャルに実行するが、時間のかかる「朝ご飯を食べる」「駅まで歩く」などの動作は割り込み可能な状態で実行し、"complete" のイベントを受けてから次の動作に移る点だ。 ちなみに、目覚まし時計は 「スヌーズボタン」付きな
Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分
予告：iPad向けクラウド本棚付きeBook Readerを無料で配布します
数ヶ月前から、自分専用のiPhone向けComicリーダーを作ってスキャンした本とかマンガを読んでいる私だが、いまいち画面が小さいので、マンガは良いとしても本を読むにはちょっとつらい。そこでiPadには多いに期待している。自分だけで楽しむのももったいないので、iTunesストアから無料で配布するつもりなので期待していただきたい。 ちなみに、ついでにGoogle App Engine上に「クラウド本棚」を作ってそこからいろいろな本をダウンロードできるような仕組みも作ったのだが、今のところ「使い方マニュアル」しか置くものがないのでちょっと困っている。いくつか手持ちの本をスキャンしてはあるが、これを勝手に配布することはもちろんできない。青空文庫の本をPDF化しておいておけば喜んでもらえると思うんだが、読みやすい大きさにレイアウトするには、それなりに手間がかかる。 そこで、みなさんのご協力をあおぎ
「なぜAppleはiPadにFlashを載せるべきではない」のか
気がついた人も多いと思うが、iPadのアナウンスメントであっさりと無視されたのがAdobeのFlash。私は意図的（＝「Flashなんか重要じゃない」というメッセージ）と読んだが、皆さんはどうだろうか。 iPhoneがFlashをサポートしていないことに対するAdobeを含めたさまざまな方面からの批判を考えれば、「the best way to experience the web （最高のウェブ環境）」を売り文句のiPadが、これだけ広く使われているFlashをサポートしないというのはおかしな話だ。 不思議に思う人も多いかもしれないが、自分をAppleの経営陣の立場に置いて良く考えてみれば答えは明確になる。 Appleという会社は、昔からさまざまなクリエーターたち（アーティスト、ミュージシャン、ウェブ・デザイナー、etc.）を魅力的で便利なパソコンやツールで味方につけ、彼らの作品を消費者
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')
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
「Flash vs. HTML5」という構図がはっきりと見え始めたぞ、と
業界関係者（特にスマートフォン関係の仕事をしている人たち）少し前からすでに気がついていた話だが、今回のAdobeからの一連のアナウンスメントで明らかになってきた「HTML5対Flash」という構図。とてもワクワクする戦いだ。 ウェブ上のリッチコンテンツという分野でリーダーシップ・ポジションを取りながらも、「無料Flashゲーム」と「ウェブサイトの見栄えをちょっと良くするアイ・キャンディ」というニッチなポジションに一度は追いやられるように見えたFlash（数年前の話）。しかし、動画フォーマットがReal Networks、Microsoft、Appleの三強いの間で中に浮く隙間を付いた戦略で、見事に「ウェブ上のマルチメディアのデファクト・スタンダード」のポジションをがっちりつかんだかに見えるFlash（現在）。しかし、その地位も安泰ではない。 Adobeにとって一番頭の痛い問題はiPhone
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
