死因 - masayang's diary
天災・人災・事故・病気・・・人が死ぬ理由は様々。ここでは米国における事故による死因別発生頻度を紹介する。原文にはいくつかの数値がでているが、ここでは「人生約77年として、何人に一人がその原因で亡くなるか」を抜粋。根拠となったのは2000年米国国勢調査。 この数字は「その原因を生む行為が安全か危険かを特定する根拠にはならない」ことに注意されたい。例えば歩行中に亡くなる人は610人に一人で、自転車は4838人に一人だが、これだけでは歩行中のほうが危険とは断定できない。自転車に乗ってる人は、歩いている人よりも圧倒的に少ないから。 * 歩行中の死...610人に一人 自転車乗車中の死...4838人に一人 自動二輪乗車中...1295人に一人 自動車乗車中...242人に一人 鉄道乗車中...119,335人に一人 溺死...7,683人に一人 交通事故一般...77人に一人 どっかから落ちて死亡
あるApple Store店員の告白 - masayang's diary
機密主義が徹底したApple。Apple Store従業員も例外ではなく、中々その実情は伝わらない。この記事ではある店員がインタビューに応じている。以下、適当に訳す。 製品発表があるその瞬間まで、店員にも一切の情報は入ってこない。 新製品に関する噂・予想を話したら即クビ。 ひどい客はひどい。ここは「給料のよいマクドナルド」みたいな所だ。 ヤクの売人とかもやってくる。ニセの身分証明書や偽クレジットカード持って。もちろん、それを指摘するのも仕事。たいてい逃げていく。 Apple Storeは販売成績に応じたコミッション制度ではない。AppleCareは売りつけないといけないことになっているが、これは問題ない。MobileMeも売りつけることになっているが、中々買ってもらえない。 同じ店舗で働く人達の販売成績が壁に張り出される。成績が悪いとマネージャ会議に呼び出され、詰められる。 ここはカルトじ
HTCの「目標失敗率」は95% - masayang's diary
先日、雑感にて某ゲーム会社の失敗プロジェクト率について取り上げたが、その後「HTCの失敗率はもっとすごい」という話を聞いた。驚くなかれ95%。 調べたら2009年12月のWiredで取り上げられていたようだ。 Wired Gadget Lab: Strapped to Android, HTC Takes a Dizzying Ride to the Top →HTC社のR&D失敗率目標は「95%に設定されているよ」というお話。 失敗する、それも早い段階で失敗しておくことで、より深みにハマってからの失敗を避ける。そのことが、より速い研究開発と製品化につながる。だから95%の目標失敗率。 “It’s no longer a mystery what it takes to create a differentiated handset,” says Greengart. Handset ma
WiFi版AndroidタブレットはかつてのPCになるか - masayang's diary
Dell Streakが予想通りの空振りで$580から$399.99に値下げ。Galaxy Tabletも$199.99なんてのがでてきている。ただし3G版で2年間のデータ通信縛り付き。そんなの欲しくねーよ。 で、この手の(5" or 7")Androidタブレットの価格を比較してみると... メーカー 機種名 価格 備考 ViewSonic ViewPad 7 $599.99 SIM Unlocked Dell Streak $399.99 新価格は2011/1/11より Android 2.2 Upgradeつき Samsung Galaxy P1000 $349.99 T-Mobile 2年縛り Huawei Ideos S7 $599.99 Verizon or Sprintの縛りあり/Android 2.1 Velocity Cruz T301 $249.99 WiFiのみ/An
iPadを絶賛していた人達はなんだったんだ？ - masayang's diary
というわけで某社の提供でiPad 3G/32GBを入手した。今日で5日目だが、普段使うアプリケーションはiPodとKindle for iPadに集約されつつある。家ではMacBook Proがあるし、移動中はG2使えばほとんど用は足りる。 個別のアプリケーションではiPadのほうが圧倒的に素晴らしい。UIはよくできている。Flipboardなんてのは最高にしびれた。*1 Kindle for iPadも、画面に反射する天井の光さえ気にしなければオリジナルKindleを凌駕した出来ではなかろうか。*2 だけど、そうやって褒められるのは「アプリケーションを通して情報を受け入れて、そこでおしまい」という人達だけだと思うんよ。 WSJ WSJのiPadアプリケーションで面白い記事を見つけた。是非これをTwitterでみんなに教えたい。こんな時にどうすればよいか？ ToolsメニューからEmail
今日のシステム延命は向こう5年の技術的負債（しかも高金利雪だるま） - masayang's diary
相変わらずクラウド活用とAgile開発を売り歩く日々なわけだが。 企業のシステム投資周期は必ずしも景気循環周期とは同期してくれない。償却が迫り、老朽化が目立っているシステムのその後を検討する際に、外部経済環境が最悪で動くに動けない、という状況に陥るのは珍しい話ではない。 だからといって現行システムの延命を図ることが正解なのだろうか。 今延命を図ろうとしているシステムは少なくとも5年前の事業戦略・事業設計・システム設計を基準にしているわけだ。当時の事業戦略が今も有効である可能性は高くはないだろう。そこを無理して延命すれば、5年後に改修ないしは再構築が待っている確率は極めて高くなる。 その場合(5年前のシステムを延命して5年待った後): 基準となる事業戦略は10年前のもの。 それを継承する事業設計も10年前のもの。 システムとして具現化した基盤もアプリも10年前の設計・技術。 これらを熟知して
議論するまでもない - masayang's diary
ITMedia: クラウドコンピューティングは本当に安上がりなのか？ →はい。安上がりです（終了） 補足 能力は想定繁忙時にあわせる。 サーバ機器を5年償却で保有。 この前提だけで、充分クラウドのほうが安上がり。そもそも想定繁忙時をどうやって見積もるのかで、高給取りのコンサルタントやら上流設計技術者やらがワラワラ沸いてきて高額な請求書を置いていく。そしてその想定繁忙能力がいかに妥当か、外れたときの責任所在をいかに曖昧にするかの駆け引きが続き、これだけでプロジェクト着手が数ヶ月は遅れる→稼動しなかった分は「機会損失」ね。 で、普通は責任所在を曖昧にするために繁忙時能力は多めに見積もられる。つまりは過剰投資。そして繁忙時／閑散時の能力差が大きいほど、この投資効果は低くなる。100あるサーバ能力が100使われることは滅多になく、普段は10とか5で動いていたら、それは損失だよね。でも負荷に応じてサ
Unit Test vs Functional TestそしてClean Code - masayang's diary
Agile2008でもらったゴムバンドを未だに手首につけている。確かBob Martinだったと思うが、テスト駆動開発と「Clean Code」の関係について熱く語っていた年だ。 メソッドは短く。 メソッドが実現することは一つ。 あるメソッドのテストに色々と条件を設定しているのなら、それはClean Codeではない。 だが我々はその基本を簡単に忘れてしまう。色々とテストのための道具が揃ってきたせいもあろう。基本を忘れて一つのメソッドに色々と詰め込みすぎるとテストが大変になる。Mockがあっても、だ。Fixture使うのはさらに大変だし、Seleniumとかで入力から何から条件を与えるのはもっと面倒。そしておそらく抜けが発生する。 最近、内職でPython使ったアプリを組んでいるのだが、今回は上記「基本」を徹底するようにしている。例えばこんなコードがある。 def nearby(reque
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
BMUF (Big Modeling Up Front)＝上流設計のインチキを斬る - masayang's diary
DDJのCounteracting the False Arguments for Big Modeling Up Front (BMUF)という記事が面白い。BMUFは、日本語なら「上流設計」だろうね。SI屋の自称上流設計エンジニアがやってる、アレだ。[*1] この記事を書いているのはScott Ambler。Refactoring Database著者だ。例によって無断適当意訳。読みやすくするために原文よりも段落を増やした。 上流設計(BMUF)にまつわる嘘を斬る 自分は１９８０年代から数々のプロジェクトで上流設計をしてきたし、様々な手法をみてきた。 そして、うまく行った事例よりは、うまくいかなかった事例の方が多いと言えるね。プロジェクトは明らかに失敗しつつあるのに、上流設計は順調に進んでいる、という現象を誰よりも多く見てきた、ということも言っておこう。 まだあるよ。上流設計担当の人た
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
