タグ

ブックマーク / satoshi.blogs.com (38)

  • NTTの株価総額が世界一だった時に、Microsoftに転職した理由

    「6年勤めたNTT退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が32年前(1986年)に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ(週刊 Life is beautiful)の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、1985年に入社した私は、NTTとしては第1期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました(当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました)。

  • 「締め切りは絶対に守るもの」と考えると世界が変わる

    2011年にインプレスジャパンから「エンジニアとしての生き方」というを出版して以来、書籍よりは「メルマガ(週刊 Life is Beautiful)」の執筆を優先して来た私ですが、この度、とある編集者に説得されて「時間術」のを出版することになりました。 『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』(文響社) 「時間術」とは言っても、巷に良くある「どうやって時間を効率よく使うか」という話ではなく、実際の仕事の現場において「常に締め切り通りに仕事を終える人」になるための、私なりの「仕事に対する取り組み方」を解説した仕事術のです。 「いつも締め切りに追われている」「締め切り間際にならないと気で仕事ができない」という悩みを抱える人たちには是非とも読んでいただきたいです。締め切りを守れるかどうかは、締め切り間際のラストスパートで決まるのではなく、もっと前の段階での、「

  • Kindle ダイレクト・パブリシング、失敗から学んだこと

    先日「Kindle ダイレクト・パブリシングを試してみた」というエントリーに書いた通り、私としては初のKindle 向けの電子書籍を発売したのだが、いきなり失敗をしてしまった。 出版したのは、下の二冊。 週刊 Life is Beautiful 創刊号(2011年8月分) 週刊 Life is Beautiful Vol.2(2011年9月分) メルマガの読者の協力も得て、KindleiPadKindleAndroidKindle のそれぞれで読めることを確認した上で出版し、ブログでアナウンスをした。滑り出しは上々で、出版して2時間もしないうちに、創刊号がヒット商品の1位になり、続いて Vol.2 が2位に。全体のランキングでも創刊号が98位にい込む。 「この調子ならば全体のランキングでも上位を狙える!」と思ったとたんに問題が起こった。 購入した読者の1人から「購入した電子書

  • neu.Node リリースのお知らせ

    去年の暮れから準備を進めて来た neu.Node だが、ようやく今日、オープンソース・プロジェクトとして github に公開することができたので報告する。 https://github.com/snakajima/neunode 詳しくは README.md ファイルに書いたが、neu.Node は iOS 上で Node.js の API を使って作った マイクロ・サーバーを走らせる仕組みである。iTunes ストアで配布する iOS アプリに組み込んでも良いし、自分や仲間だけで楽しむ「手作りアプリ」に組み込んでいただいても良い。ライセンスは MIT で、ライセンス料フリーで、非営利・商用、無料・有料の区別なく使える。 neu.Node が目指すのは、新しい形の分散コンピューティングである。「モバイル・デバイスはクライアント、サーバーはウェブ・サービス」という垣根をとっぱらい、全てのモ

  • 各種ブラウザーで Java (applet) を無効にする方法

    こちら(米国)では、見つかった Javaセキュリティホール(+それを利用した実際のアタック)が大問題になり、米国政府が「ただちに Java を無効にするように」と声明を出し(参照)、全国ニュースでも大きく取り上げられている。 実質的な危険があるのは Java applet なのだが、JavaJava applet の違いの分からない報道機関は、大々的に「Java が危険」と報道しており、Sun Microsystems を買収して Java を入手した Oracle にとっては大きなブランドイメージの損失だ。Oracle は火曜日には56カ所のセキュリティホールを塞いだパッチを提供するそうだが、そんなパッチでは、今回作られてしまった「Java は危ない」というイメージは拭えない。 どのみち、Java applet にはほとんど価値がないので、これを機会に無効にする人も多いようだ(

    各種ブラウザーで Java (applet) を無効にする方法
  • node.js と thread hog の話(3)

    [前回までの話へのリンク] ・node.js と thread hog の話(1) ・node.js と thread hog の話(2) では、なぜ今頃になって HTTP Server の c10k 問題(もしくは、thread hog 問題)が顕在化したのだろう。 当時(90年代の終わり頃)と比べて、もっとも大きく変わったのはCPUの性能である。クロック数は、数百MHzから数GHzへと一桁増えたし、マルチコア化もしている。CPU 性能だけ見れば、当時の数十倍の能力が出てしかるべきである。 しかし、実際の人生はそう簡単ではない。サーバーのパフォーマンスはCPU性能だけが決めるわけではないからだ。そこで、ボトルネックの一つとして注目されはじめたのが、thread の数なのである。 前回述べた様に、thread 一つあたり 2MB~8MB のスタック領域を仮想メモリ空間に確保しなければならな

  • Ruby on Railsの「えせMVC」の弊害

    先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC(Model View Controller)がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの(コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること)を避

  • Amazon Fire がタブレット市場の15%を確保するとの予想

    Amazon が2012年にはAmazon Fire 1200万代を売り、タブレット市場の15%を確保するだろう」との予測が出されている。 この数字は私の予想とほぼ同じ。2012年に関して言えば、AppleiPadが相変わらず強くてタブレット市場の70%近くを占め、さらに残りのマーケットの半分以上を Amazon Fire が取る、というのが私の読みだ。 消費者から見れば、iPadが一番魅力的だが、値段が半分以下でコンテンツも充実しているAmazon Fireにも捨てがたい魅力がある。 AppleiPadで30%強の粗利を稼ぎ出す一方、AmazonはFireを一台売るたびに20〜30ドルの赤字になると予想されているが、一気にシェアを確保して、後からコンテンツで儲けるビジネスモデルのAmazonとしては正しい戦略だ。 間に立たされて苦しい思いをするのが他のタブレット・メーカー。iPad

  • エンジニアの役割

    技術評論社の WEB+DB PRESS に連載中のコラムが新しくウェブで公開されたので、ぜひとも読んでいただきたい。 エンジニアの魔法の手〜面白いプロジェクトの関るには このコラムで一番注目していただきたい部分は、以下の一節。 自分が関わっているプロジェクトの方向性がおかしいと思ったら,自分がどんな立場にいようと強く主張すべきだ。会社はそんなエンジニアを必要としているし,当に会社のためになるのであれば必ず耳を傾けてもらえるはずだ。「そうは言っても,難しいんだよ」などと逃げを決める上司は怒鳴りつけてやればよい。 会社にとって最悪なのは,「こんなものを作っても誰も使わないんじゃないか,会社の価値を上げることにつながらないんじゃないか」と思いながらも黙々と仕事をするエンジニアだ。そんなエンジニアばかり集まっている会社は絶対に市場で成功しない。プロジェクトに関わるエンジニア全員が,「自分たちがど

  • HTML5時代の「運営しやすいアーキテクチャ」の話

    増井君と二人でPhotoShareというサービスを立ち上げてもう15ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ(JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく(上の図で、CSS,

    HTML5時代の「運営しやすいアーキテクチャ」の話
  • SNBinderと「混ざり物のないコンソメスープ」と

    先日オープンソース化したSNBinder(参照)、たくさんの人たちから色々なフィードバッックをいただけてとても感謝している。ブログの記事として書かれたものは私が知る限り以下の三つ。 penultimate diary: SNBinderを試してみる js do.it: SNBinderを試したよ! a2c.get.diary: SNBinderに目からウロコ 小さなMVCが今現実に 当初は、最新のjQueryと動かないというバグがあったり、READMEにタイポがあったりとご迷惑をおかけしてしまったが、こうやってフィードバックをいただくことによって、励みになったり改良したり、というのがオープンソースの醍醐味である。とてもありがたい。 ちなみに、SNBinderは原型のようなものは1年前以上前からあったのだが、ViewとControllerの切り分けに部分がなかなかすっきりせず、公開を控えてい

  • JavaScript HTMLテンプレートエンジン SNBinder 公開

    先日予告したSNBinderのオープンソース化、GitHubに簡単なREADME付きでアップロードしたのでご覧いただきたい。 https://github.com/snakajima/SNBinder SNBinderは、ひと言で言えば「ブラウザー上でView(テンプレート)とData(JSON)を結合して HTML を生成するテンプレートエンジン」である。 90年の半ばから急速に広まったインターネット。サーバー側でダイナミックに生成したHTMLページをブラウザーで閲覧するだけ、というシンプルでエレガントなアーキテクチャゆえの成功だ。しかし、ブラウザーの高機能化に伴い、JavaScriptを駆使して使いやすさを向上しようという試みが色々なウェブサイトで行われている。GMail、Google Docs、Facebookなどは良い例だ。 その方向性を究極にまで突き詰めると、サーバー側は(MVC

  • 日本のケータイが「ガラパゴス化」した本当の理由

    「ガラパゴス」という言葉が今年の流行語大賞の候補に選ばれたということを聞いていたので、密かに受賞しないかと期待していたのだが、残念ながら大賞は逃したようだ(もし大賞に選ばれていたら、私が受賞することになったのかどうかの疑問はこれで解けずに終わってしまった)。しかし、この言葉をずいぶん前から使っている私としては、この言葉が一人歩きしているようでなんとも言えない気持ちなのでひと言。 まず最初に断っておくと、私が2001年のCTIA(米国の携帯電話業界で一番大きなカンファレンス)のスピーチでこの言葉を使った時は、単に日という「単一民族で、国民の大半の生活レベルが同じで、家電とか携帯電話のようなガジェットに流れるお金が比較的多い」という特殊な環境で、iモードを中心に「ケータイ・ライフスタイル」が異常なスピードで進化をとげていることを表して、「ガラパゴス現象」と呼んだだけのこと。決してネガティブな

  • google appengine に関してひと言

    ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt

  • iPadアプリ開発日誌:「アノテーション」が可能になったCloudReaders

    少し前から予告していた(参照)neu.Notesと連携してPDFやマンガにアノテーション(=赤入れ)をすることを可能にしたCloudReaders(バージョン1.14)がAppleに承認されたので、ぜひともお試しいただきたい。 正直、今回のバージョンは一発承認は難しいと考えていた。というのも、この機能はneu.NotesがインストールされているiPadでしか動かないので、「他のアプリがインストールされていないと使えない機能を持ったアプリなんて承認できない」といちゃもんを付けられてる可能性があると考えていたのだ。 しかし、結果は一発承認。neu.Notesがインストールされていない場合のレスポンス(後述)などを慎重に作り込んでおいたのが良かったのだろうと自分なりに納得している。 その仕組み(プロトコル)はとてもシンプル。ユーザーがペンアイコンとタップすると(上の図参照)CloudReader

    iPadアプリ開発日誌:「アノテーション」が可能になったCloudReaders
  • Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し,締め切りが近づいたら流す」という働き方

    かれこれ30年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は100人に1人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分

  • iPadアプリ作成日記: アプリ間の連携について一考察

    CloudReadersというPDF/マンガリーダーを個人で、neu.Notesという手書きノートアプリをneu.Pen LLCを通して開発・リリースしている私だが、当然のようにその二つを組み合わせて「PDFの赤入れアプリ」を作って欲しいというユーザーからのリクエストは聞こえて来るし、私自身も欲しい。 これまで二つのプロトタイプを作っては見たのだが、どうも気に入らないのでリリースは見合わせている。 最初に作ったのは、CloudReadersに "Annotation Mode" (赤入れモード)を追加したバージョン。とりあえず赤入れが出来るところまでは三日ぐらいであっさりと動いたのだが、「シンプルでサクサク読める」ことを最優先に設計されているCloudReadersの場合、追加した書込みを常に表示するのかしないのかでかなりパフォーマンスに影響が出るし、「赤入れモード」という明示的なモードを

    iPadアプリ作成日記: アプリ間の連携について一考察
  • 共著「Google Chrome OS」出版のお知らせ

    先日のセミナーでも少し触れた、「Googleのコモディティ戦略」。インプレスからこのたび出版される「Google Chrome OSー最新技術と戦略を完全ガイド」の「戦略」の部分に共著者の一人として寄稿したのでここで紹介させていただく。 Chrome OSにせよAndroidにせよ、OSをGoogleが無料で提供するには深い意味があるのだから、それをちゃんと理解した上で、自社のデバイスに採用するかしないかを「経営判断」として決めるべき。「他のメーカーも載せはじめたから」とか「自分だけ乗り遅れたくないから」ぐらいな安易な気持ちで始めると、「実際やってみたら得をしたのはGoogleだけ」という結末になりかねないので慎重にすすめるべき。 2年ほどiPhone向けのアプリを作って来た結果、最近強く思うのは、テレビなどの据え置きがたの家電にアプリをダウンロードして走らせる、という発想自体が根的に間

  • 今、日本に必要なのは企業の新陳代謝と優秀な人材の有効な活用

    先日の「とある家電メーカーでの会話:クラウドテレビ編」と「もし日のメーカーがiPhoneを発売していたら」、ユーザー不在・カタログスペック重視のもの作りの問題点を浮き彫りにしてみたつもりだ。「こんな場面につい最近も出くわした」という意見から、「こんなにはひどくない」というフィードバックまでいただけたが、多かれ少なかれ、これに近い状況が現場で起こっており、それが日のメーカーの国際競争力を奪う原因の一つになっていると私は見ている。 日の家電・半導体メーカーが米国のメーカーと激しい貿易摩擦を起こしていた80年代、日の企業の強さはまさにこの「スペック重視のもの作り」にあったことは事実である。日人の勤勉な気質と日流の経営スタイルがちょうど良い案配に働き、より集積度の高い半導体、より画質のきれいなテレビ、よりハイスペックな家電を欧米よりもはるかに低コストで効率良く作ることにより、日が一気

  • Life is beautiful: とある家電メーカーでの会話:クラウドテレビ編

    ある日の家電メーカーでの会話。まずは副社長室での会話から。 技術部長:副社長、来年度の予算の件はどうなりましたか 副社長:大丈夫だと言っただろう。台湾中国からの追い上げは相変わらず激しいが、テレビは家電ビジネスの要だ、経営陣としてもここだけは手を抜けない。来年も君たちにがんばってもらわなければならない。 技術部長:もちろんです。そのあたりは現場のエンジニアたちも強く感じてると思います。ちなみに、メールに書いてあった「戦略の変更」って何ですか? 副社長:そのことなんだが、経営会議でも持ち上がったんだが、台湾勢と戦うには、我が社にしかできない「差別化要因」が必要だ。価格競争では彼らにかなわない、消費者にとって目に見える価値を提供して、台湾製品よりも3割・4割増の値段でも喜んで買ってもらえるテレビを作らなければならない。私は、キーワードは「クラウド」だと思っている。 技術部長:え?「ク、クラ

    Life is beautiful: とある家電メーカーでの会話:クラウドテレビ編