エンジニアの役割
技術評論社の WEB+DB PRESS に連載中のコラムが新しくウェブで公開されたので、ぜひとも読んでいただきたい。 エンジニアの魔法の手〜面白いプロジェクトの関るには このコラムで一番注目していただきたい部分は、以下の一節。 自分が関わっているプロジェクトの方向性がおかしいと思ったら，自分がどんな立場にいようと強く主張すべきだ。会社はそんなエンジニアを必要としているし，本当に会社のためになるのであれば必ず耳を傾けてもらえるはずだ。「そうは言っても，難しいんだよ」などと逃げを決める上司は怒鳴りつけてやればよい。 会社にとって最悪なのは，「こんなものを作っても誰も使わないんじゃないか，会社の価値を上げることにつながらないんじゃないか」と思いながらも黙々と仕事をするエンジニアだ。そんなエンジニアばかり集まっている会社は絶対に市場で成功しない。プロジェクトに関わるエンジニア全員が，「自分たちがど
プラットフォームは乗るものではなく、担ぐもの
先日、出版記念イベントを開かせていただいた「エンジニアとしての生き方」、アマゾンでの在庫がなくなっていたようでご迷惑をおかげしたが、再び入荷したようである（３０日現在）。 ちなみに、この本はブログの人気エントリーとWEB+DB PRESSのコラムと書き下ろしから構成されるが、WEB+DB PRESSのコラムの連載はまだ続いているのでこちらもよろしくお願いする。 最新号のVol.62には、「プラットフォームは乗るものではなく、担ぐもの」というタイトルで、AndroidだiOSだHTML5だと乱立するプラットフォームにどんな気持ちで向き合うべきかという話を書いてみた。要約すれば「常に時代の先端を走り続けたいのであれば、『勝ち馬を見つけ出してそこにお金を張る』のではなく、『自らが騎手になって自分がこれと思ったプラットフォームを勝たせる』意気込みが必要」という話。 SDKの公開当初からアプリケーシ
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
Cloud Computing考：Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた
Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいの
マルチスレッド・プログラミングの落とし穴、その２
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
プラットフォームを選ぶということ
この業界で仕事をしていると、しばしば迫られるのが「どのプラットフォームに向けて商品開発をして行くのか」という決断。会社としての経営判断の場合もあれば、個人のスキルアップやキャリアパスのための判断の場合もあるが、いずれにしろ限られたリソース・時間をいかに有効に使うか、という点ではとても大切。 パソコン用のソフトウェアであれば、「Windows向けに作るのかMac向けに作るのか」というOSレベルでの選択肢もあるし、「Windows Vista独自の機能を使って差別化を図るのか、それともWindows XPでもちゃんと動くように作ってまずは大きな市場をとりに行くのか」というOSのバージョンレベルでの選択肢もある。もちろん「そもそも特定のOS向けのアプリを作るべきか、それとも、すべてウェブ・アプリケーションとして作るか」というアーキテクチャ・レベルでの選択肢もある。 「少なくともここ数ヶ月はiPh
iPhoneアプリを作る際に注意すべき５つのポイント
毎日のように「iPhoneアプリでApple Design Awardを取るぞ！」と騒いでいるので、知り合いに「それって（現実が分かっていない）大学生のノリですよ」と指摘されてしまった私だが、マイクロソフトを２０００年に退社してからは、ひたすらモバイル・組み込みの世界で仕事をしてきた私としては「俺が取らなくて誰が取る？」という気分。その超楽天的な態度が彼が言うところの「大学生のノリ」なのだろう。 市場に受け入れられるアプリを作るためには、もちろん「誰にどんな価値を提供するのか」が一番大切。しかし、そこには残念ながら成功の一般方程式はないので、今日は比較的に一般化しやすい「どう作るか」という部分に関して、まとめることにした。 1. ユーザーの利用シーン・使用パターンを良く考えて作る パソコンやゲームコンソール向けのソフトと大きく違うのが、ユーザーの使用パターン。iPhoneに限らず、携帯電話
Born to code
大まかな設計図をあたまに浮かべ、おもむろにコードを書き始める 下回りの部品から順番に、丁寧に積み上げて行く それでも必ず後から下回りの設計に気に食わない部分が出てくるので、 苦しくてもそこは躊躇せずに壊しては作り直す そうして行くうちに、だんだんと下の方から設計がしっかりしたものになってくる 踏み固められた地面が固くなるように、少しづつ強固なプラットフォームが作られて行く 「今日はここまで実現しよう」と決めたら死にものぐるいでそこまで走る でも頭が回らなくなってきたら早く寝る そうやって愛しい我が子を育てる様にコードを一行一行書いていく 何百万人、何千万人もの人に使ってもらえる日を夢見ながら プログラミングという楽しみがある時代に生まれて来ることができた幸せを噛み締めながら
建物と違って、一見簡単に修正が利きそうなのがソフトウェアの問題点かな、と
これを読んで、「SIerの仕事って『工事』だったのかあ」と思った人は私だけではないはず。 これまでSIerは、工事進行基準ではなく、開発終了時に売り上げと原価を一括計上できる「工事完成基準」を取るケースが多かった。一般的に日本のシステム開発は要件定義やユーザー企業との契約が明確でなく、開発中の手戻りや期間の超過が多い...【デスマーチがなくなる？ IT業界に義務付け「工事進行基準」ってなんだ − ＠ITより引用】 さらに「工事進行基準」と「工事完成基準」の定義を読むとますますそう思える。 工事進行基準 長期請負工事契約に関する会計上の収益認識基準の1つ。工事期間中、目的物が完成に近づくにつれて徐々に収益が発生するものと考え、工事の完成度合いに応じて工事に関する収益と原価を計上し、各会計期間に分配する方法である。“発生主義”に基づく収益認識法とされる。【工事進行基準 − ＠IT情報マネジメン
「作っては壊す」過程があってこそ良いものが作れる
iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ（XMLOverHTTPはDataOverHTTPのサブクラス）、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController（HotEntryViewController）からModel側（HateneHotEntry）に移すことにより、難解になりが
ソニーの「イノベーションのジレンマ」について一言
私の書物「おもてなしの経営学」についてのさまざまなフィードバックはポジティブなものもネガティブなものもとても良い勉強になるので全部読ませていただいているつもりだが、以下の二つに関しては、少し誤解があるようなので一言書いておこうと思う。 何故SONYの経営はiPodを創れなかったか - 雑種路線でいこう 「おもてなしの経営学」：ソニーのエンジニアの名誉のために一言 ([の] のまのしわざ) 私の本のごく一部、それも梅田氏とのの対談における「ギークとスーツ」の話題の前フリとして「ギークとスーツのすれちがい」「技術と経営の両方が分かる人が少ない」ことの例として語った言葉だけを取り上げて、あたかも私が「ソニーにiPod+iTunes+iTunes storeが作れなかったのはエンジニアが悪い」と決めつけているかのように誤解をされてしまっているのが私としてはとても残念。 せっかく私の本を読んでいただ
Ajaxian が UIEvolution について書いてくれたのはいいんだけど
I have seen the huge batches of cell phones that companies keep around to test their applications on. Companies like UI Evolution have come along to try to help out the madness of getting something that works across more than a couple of them.【Ajaxian » Google Gears for Mobile Releasedより引用】 "UI" と "Evolution" の間にスペースが入っちゃてるのがちょっと不満だけど、宣伝になるので良しとしよう。 Windowsが独占状態のパソコンと違い、モバイルデバイスのマーケットはプラットフォームが乱立し
ネットが進めるノウハウのコモディティ化
昨日のエントリーには、たくさんのブックマークをいただいたが（）、興味深いのはそこで引用したCraig Raynoldの論文にもたくさんのブックマークが付いたという事実だ（）。１９８７年のSIGGRAPHで発表された論文が、こんな形で「再発見」されて若い学生や技術者たちに読まれることになる、というところが何とも言えずに楽しい。私から見れば「『群れ』のシミュレーションが作りたいならRaynoldの論文を読めば良い」などという情報は「知っててあたりまえの常識」なのだが、知らなかった人にとっては「貴重なノウハウ」なのだ。 「インターネット以前」は、この手の情報共有はものすごく難しかった。それどころか、逆にこの手の情報を会社の内部ですら「自分だけのノウハウ」として抱え込むことによって差別化を計ろうとするせこい技術者がたくさんいた。つまり、「他の人が簡単に手に入れることができない知識・情報を持っている
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
単なる「低コストの外注先」ではなくなりつつあるインドのIT産業