タグ

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

  • Andy Rubin が Android の開発責任者から降りた件について

    2月の終わりにスペインで開かれた「Mobile World Congress 2013」で、「Tizen」「Firefox OS」という二つのモバイルOSの発表が注目を集めたが、これらに絡めて「モバイルOSの動向」に関しての記事を執筆して欲しいというリクエストが複数のところから来た。 それはそれで書いているのだが、私がもっと注目しているは、Andy RubinがAndroidの開発責任者のポジションから外れた件だ。 Googleのことなので多少違う意味合いがあるのかも知れないが、これがMicrosoftであれば99.9%降格人事だ。 合議制でものが決まる日とは違い、米国の場合、「何をどんな目的で作るか」という product vision に関しては開発責任者が全責任を追う。そのため、責任者が変われば、作るものも大きく変わってしまう。 優秀な人であればあるほど、上からあれこれと指示される

    r-west
    r-west 2013/03/20
    統合ったって、Androidを実質消し去るか、ChromeOSを懐かしのJavaAppletベースシンクライアント()みたいなのにするしかない気が。
  • 特許庁のシステム開発が破綻した本当の理由

    特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には(1)コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、(2)霞ヶ関から流れて来るお金にたかる IT ゼネコン、(3)そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。 破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。 そもそも破格だと言われた99億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれ

    特許庁のシステム開発が破綻した本当の理由
    r-west
    r-west 2013/01/06
    ハッカーたち自身が好きなものを勝手にコード書くだけなら4億でできるかもね。要件定義で破綻したって言ってるのに。いいこと言ってた人がおかしくなっていくのは辛い
  • 非同期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 の無名関数を使ったイベント駆動型のプログラミングの可読性が悪くないことを示すために、「朝7時に目覚まし時計をかけて眠りにつき、朝ご飯をべ終わったら会社に行く」という典型的な「サラリーマンの朝」をイベント駆動型のJavaScriptで記述してみた。 注目して欲しいのは、素早く出来る「着替える」「顔を洗う」などの動作は割り込み不可な動作なので、通常のプログラミングと同じようにシーケンシャルに実行するが、時間のかかる「朝ご飯をべる」「駅まで歩く」などの動作は割り込み可能な状態で実行し、"complete" のイベントを受けてから次の動作に移る点だ。 ちなみに、目覚まし時計は 「スヌーズボタン」付きな

    r-west
    r-west 2012/10/21
    微妙...。てか、スレッド(同期)ベースだったらどんなコードかって考えると、やっぱり、、、。ただ、うまい構文糖があれば問題なくいけそうな気もする。
  • 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 のスタック領域を仮想メモリ空間に確保しなければならな

    r-west
    r-west 2012/10/18
    CPUキャッシュに乗るから早い説。GCはの影響はどうなんだろう
  • Life is beautiful: Windows95と地上の星

    Windows95の開発の総責任者であるDavid Coleから開発の主要メンバーに緊急召集がかけられたのは、Windows95の開発も大詰めを迎えた1994年末のことである。 Shell(デスクトップ、エクスプローラ、スタートメニューなどのユーザーインターフェイス)の開発を担当していたSatoshiは、いままでの経験からこの手の緊急招集が良い知らせでないことはないことは知っていた。 David Coleが深刻な顔をして緊急招集の理由を説明し始める。Windows95そのものの開発は順調に進んでいるが、Windows3.1との互換性の維持が思うように進んでいないのである。 「このままだと、95年中にリリースすることはできない」 深刻な問題である。既に当初の予定より1年以上遅れているWindows95のリリースをさらに遅らせて95年のクリスマスシーズンを逃すことはOffice95を同時にリリ

    r-west
    r-west 2012/09/03
    これJoelの本で読んだ気がしてたけど中島さんだったか
  • なぜJava開発者は眼鏡をかけているのか?

    Home Archives Profile Subscribe 今週の週刊 Life is Beautiful : 4月24日号 活断層マップと原発マップを重ねてみる なぜJava開発者は眼鏡をかけているのか? 2012.04.25 Satoshi | Permalink | Comments (1) | | Comments 日にもJava開発者は多くまた日には眼鏡の人は多いです。ドントシーシャープ。 Posted by: jar | 2012.04.26 at 04:07 The comments to this entry are closed. Life is beautiful • Powered by Typepad Top

    なぜJava開発者は眼鏡をかけているのか?
    r-west
    r-west 2012/04/27
    コメント見るまで何の事か解らなかったよ…orz。
  • 誰も言いたがらない「Sony が Apple になれなかった本当の理由」

    Sony や Panasonic が家電のコモディティ化で大赤字を出して苦しむ一方で、今や株価総額が日の大手家電メーカー8社の株価総額の3倍以上にもなった Apple(参照)。 この差に関しては、私も含めて、リーダーシップの欠如だとか、ゼネコン型のソフトウェア開発スタイルが悪いとか、ソフトウェアの重要性を理解しない経営者、などのさまざまな考察がされているが、その根底にあるのは、「大企業は一度正社員になった人は会社が倒産の危機にでもさらされない限り解雇してはいけない」という日特有の雇用スタイル。 家電業界の成り立ちは、日の家電メーカーが業績をのばしていた高度経済成長期とは大きく変わってしまった。ソフトウェアがものすごく重要になったのはもちろんのこと、ハードウェアに関しても、中国を含む東南アジアが「世界の工場」となった今、「何を自分で作り何をアウトソースするか」がコスト削減の上でも差別化

    r-west
    r-west 2012/03/11
    なるほど。気狂いトップとエレベーターに同乗しただけで解雇できないといけないわけですね/叩かれてるけど、まあ実際問題必要条件のひとつではあるとは思う。ソフト中心のIT系は現実にアメリカひとり勝ちだし
  • 可視化された Android OS アップデート問題

    先日、ここでも触れた Android OS のアップデート問題。Android 端末がどのくらいの勢いで「陳腐化(OSのアップデートから見放されること、セキュリティ・パッチの配布が止まること)」するかをとても分かりやすく表現しているブログ・エントリーを見つけたので紹介する。 Android Orphans: Visualizing a Sad History of Support iPhoneの場合(上から4つ)は、新機種が発売されてから3年間は陳腐化することはない(緑色)が、Android 端末の場合、大半がすぐに陳腐化(黄色から赤)してしまっていることが良く分かる。 特に問題なのは、発売当初から1〜2世代前のバージョンを搭載した「生まれた時から陳腐化」している端末。中でも Motorola Cliq XT が最悪で、発売された時から2世代遅れており、発売後3ヶ月で3世代遅れになり、その

    可視化された Android OS アップデート問題
    r-west
    r-west 2011/12/29
    アホかw AndroidはベースのOSが出来た時点から陳腐化カウントしてiOSは全ハード搭載準備できるまでカウントしないで、何を比較したつもりなんだ?
  • 私からの提案:おかえりなさいテレビ

    若干誤解してしまった人も少しいたようだが、私が「もし日のメーカーがiPhoneを発売したら...」で指摘したかったのは、「広告一つでこんなにインパクトが違うのか」という単純な話ではなく、「どこに重きを置いてもの作りをするか」というもっともっと根的な問題。 カタログスペック重視のもの作りは、確かに社内の稟議を通しやすいし、作る過程でも目標設定が簡単だ。量販店で横並びにされた時にも他社の製品に負けない。しかし、これがそろそろ通じなくなっていることは、日のどのメーカーもひしひしと感じているはずだ。 確かに「ユーザー・エクスペリエンス(おもてなし)」とか「ライフスタイルへのインパクト」重視のもの作りは、定量化ができなし、大失敗の可能性もあるので、「出る杭は打たれる」型の日の会社では難しいのかも知れないが、そろそろ意識を切り替えないと手遅れになる。「ユーザーにどんな体験をしてほしいか」をまず

    r-west
    r-west 2010/03/08
    エンジニアとしては涙が出るほど同意なんだけど、実際にCocoonがSonyにどれだけ利益をもたらしただろうか。あと、事業部が単年度予算単位でしか評価されない問題。
  • もし日本のメーカーが iPhone を発売していたら..

    iPhoneは会社から支給されて使っていますが、非常に使い勝手がいいです。 ただ、これでは、いまほど欲しくならないことはたしかですね。 他の機種と同じ土俵の上に上がってしまっているので、「なんかいろいろ機能がごてごて付いてる中の携帯の一つ」というところでしょう。 つまり、「売れるモノも売れなくなる」、「売り方次第」ということを今更ながら思い知らされました。

    もし日本のメーカーが iPhone を発売していたら..
    r-west
    r-west 2010/03/07
    フイタw 「もし日本のメーカーが iPhone を発売していたら..」
  • Life is beautiful: とある家電メーカーでの会話:クラウドテレビ編

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

    Life is beautiful: とある家電メーカーでの会話:クラウドテレビ編
    r-west
    r-west 2010/03/07
    あれ?うちの会社の情報が漏洩してる!?/でも幹部が多少なりとも言葉の意味を判ってるから違うか。。。
  • Google App Engine上のベスト・プラクティス、その1: Datastore

    Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと(=頭を使うべきところ)は、データベースの設計である。特にリレーショナル・データベース(RDB)上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En

  • 「富豪プログラミング」もいいけど「けちな大富豪」になるべき

    Ruby on Railsに代表されるDRY(Don't Repeat Yourself)スタイルのフレームワークは、手っ取り早くサイトを立ち上げるのにはとても便利だ。特にRailsのActive Recordの様に、ランタイムにダイナミックにコードや設定ファイル(もしくはそれに相当するもの)を生成してくれる仕組みは、情報を一カ所のみに記述することによりミスを減らすという意味でもアジャイルな開発という意味でも重要である。 ただ、この手のフレームワークを使う場合に一つ気をつけなければならないのは、それがスケーラビリティの面で商用に耐えられるものか、という点である。特に、その手のダイナミックなコードや設定ファイルの生成(Railsの場合だとデータベース上のテーブルのスキーマに基づいたActive Recordクラスのダイナミックな生成)が、最初にサイトにアクセスが来た時に一度だけ実行されるもの

    r-west
    r-west 2009/11/28
    何にコストが掛かるか知らなくても最適化される基盤が望まれる。そう言う研究はないのかな。詰まる所宣言的プログラミングに行くのかもしれないけど。
  • Life is beautiful

  • Life is beautiful: 自分で考える前にググっていませんか?

    つい先日、興味深い話を聞いた。ある大学の授業で「デジタル・コンテンツ・ビジネス」というテーマで小論文を宿題として書かせたところ、同じような内容の小論文ばかりが集まったという。その原因を調べたところ、「デジタル コンテンツ ビジネス」のキーワードでググると上位に来る私の過去のエントリーの内容がほぼ丸写しにされていたという。 日の学生の勉強に対する態度なんてそんなものなのかも知れないが(それはそれで憂うべき話だがその話は別の機会に)、少し心配になるのがどんな気持ちでその手の「コピペ」をしているのか、という点である。確信犯的に「徹底的に手を抜きたいからコピペしているだけ」ならまだ許せる。私が問題視するのは「自分で考える前にまずググる」習慣であり、「ググれば答えが見つかるにちがいない」という錯覚である。 暗黒時代とも呼ばれる中世ヨーロッパで科学の進歩があんなにも長い間低迷した原因の一つは、あの時

  • 交渉の場にのぞむ前にしておくべき心の準備

    ネゴシエーション(交渉)に関するテクニックにはさまざまなものがあるが、その多くが「いかに自分の欲する条件に近いものを勝ち取るか」をゴールとしたもの。それはそれで役に立つのかも知れないが、私としてはどちらかというと、今読んでいる「Getting to YES(日語訳:ハーバード流交渉術)」というに書いてあるアプローチの方がしっくりと来る。 このの筆者(Roger FisherとWilliam Ury)は、一般に良く使われる「交渉は勝つか負けるか」「相手に手の内を見せない」「自分はできるだけ譲らずに相手に譲らせる」などのテクニックは交渉を長引かせるだけだし、その過程で相手との信頼関係を損ねかねないと警告する。 このにはいくつかの有効な提言が含まれているので何回かに分けて紹介したいと思うが、まず最初に紹介したいのは、交渉の場にのぞむ前に自分がしておくべき心の準備の話。 多くの場合、人は交

    r-west
    r-west 2007/10/24
    決裂時の対案がしっかりしてる事で強く
  • Life is beautiful: 私のとっておきのプログラミングスタイル

    404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は7月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、当は大幅な設計変更をすべきなのに応急処置で

    r-west
    r-west 2007/09/16
    細かく切ってそれぞれを超集中。の積み上げ
  • Youtubeでものを売りつけられた…それもとても上手に

    Youtubeでたまたま見つけたビデオに思いっきりひきつけられてしまった。これだ、 これにはまいった。子供のころから磁石が大好きだった私のために作られたような商品だ(ちなみに、この商品はBandoleer Bracelet from Dynomighty Design)。 それにしても、このYoutubeを使ったマーケティングはなかなかするどい。この商品のように「一目見てもらえばユニークさが分かる」ものにはとても効果的だ。

    r-west
    r-west 2007/03/04
    欲しい!けど、磁気大丈夫?画面が虹色になったり買い物が出来なくなったり
  • DNA マーカー『M122』を持つ人は、お米が大好き!?

    2ヶ月ほど前にが大好きな Good Morning America で Genographic Project の存在を知り、さっそくキットを取り寄せて DNA サンプルを送っておいたのだが、テストの結果をチェックするのをすっかり忘れていたことに今日気が付いた。 そこで Genographic のサイトに行き、私の DNA サンプルの識別番号を入力すると、結果が表示される(左の図)。私の祖先は、アフリカから中近東を経て、大陸を渡ってきたらしい。 結果を見たときには、「どうせ日人は皆同じような結果が出ているのではないか」と思ったのだが、他にもこのテストの結果を公開している日人のものと比べてみると(参照1、参照2、参照3)、かなり異なった結果である。 このプロジェクトは99ドルの手数料(+DNAサンプルを送る時の送料)を払えば誰でも参加できるオープンなプロジェクトである。自分の先祖がどん

  • 1