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

先日、出版記念イベントを開かせていただいた「エンジニアとしての生き方」、アマゾンでの在庫がなくなっていたようでご迷惑をおかげしたが、再び入荷したようである（３０日現在）。 ちなみに、この本はブログの人気エントリーとWEB+DB PRESSのコラムと書き下ろしから構成されるが、WEB+DB PRESSのコラムの連載はまだ続いているのでこちらもよろしくお願いする。 最新号のVol.62には、「プラットフォームは乗るものではなく、担ぐもの」というタイトルで、AndroidだiOSだHTML5だと乱立するプラットフォームにどんな気持ちで向き合うべきかという話を書いてみた。要約すれば「常に時代の先端を走り続けたいのであれば、『勝ち馬を見つけ出してそこにお金を張る』のではなく、『自らが騎手になって自分がこれと思ったプラットフォームを勝たせる』意気込みが必要」という話。 SDKの公開当初からアプリケーシ

「ピュアAjaxアーキテクチャ」なウェブサイトを実現するために作ったSNBinder、多くの方々からフィードバックをいただけ、私もとても良い勉強になっている。そんなフィードバックの中に、「テンプレート内で条件分岐ができるようにして欲しい」「テンプレート内にスクリプトが書ける様にして欲しい」などのリクエストをたびたび見かけるので、今日はそれに関してひと言。 たしかに、従来型のテンプレートのほとんどに「繰り返し」や「条件分岐」の機能がある。ものによっては、そのテンプレート中にスクリプトが書けてしまうものもある。SNBinderにそんな機能を追加するのもけっして難しくないのだが、私がSNBinderで実現しようとしている方向性とは少し違う、と感じている。 そもそもテンプレートとは、JavaとかPythonなどで記述された「ロジック（もしくはコントローラ）」と、ユーザーに何を見せるかというHTML

前にも似たようなことがあったと思うが、今度はモトローラがAndroid端末のOSのアップグレードに苦労していることが報道されている（CLIQ XT won't get Android 2.1 upgrade, Motorola's word as good as dirt）。この記事を読む限り、CLIQ XTのユーザーが新しいOSを手に入れることは現実的ではなくなってきているようだ。 パソコンのようにハードウェアのアーキテクチャが基本的に同じで、共通Biosのようなレイヤーもしっかりとあるものと比べ、スマートフォンの場合は、それぞれのハードウェアも大きく異なっているし、共通Biosのようなものも存在しない。それに加え、差別化の難しいAndroid端末の場合、ぎりぎりまでにコストを削る必要もあり、それも「バージョンアップとともに大きくなる」OSのアップグレードを難しくしている。 理由は何であ

週末はクリスマス休暇でロスに住む長男が遊びに来ていたのだが、金曜日の朝になって面白そうなFacebookユーザー向けのサービス案を提案して来たので、さっそく作ってみた。２４日にはクリスマスパーティもあったし、テニスも毎朝していたので、正味プログラミングをしていた時間は３０時間ぐらいしかなかったのだが、発案からわずか３日でサービスがローンチできてしまうとは（Google App EngineとFacebook APIのおかげ）、ずいぶんと便利な時代になったものだ。 日本ではまだまだだが、米国では人口の７割以上がアカウントを持つと言われるFacebook。Twitterでの不特定多数向けの「つぶやき」よりも、友達・知り合い間での「プライベートなコミュニケーション」向けのFacebookは、どちらかと言えばmixiに似ている。mixiとの根本的な違いは「大人も使っている」点。 特に最近は、「プラ

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

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

Google App Engineを使った最初の作品 Tiny Message （http://tinymsg.appspot.com）をリリースしてまだ２０時間経っていないが、設計の過程でいろいろと学べたことがある。 その中でも一番収穫として大きいのは、「Google App Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。 もちろん、Google App Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Entity Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。 リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデー

Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいの

今週はMBAの授業の一環でインドのいくつかの企業を訪ねてまわっているのだが、今日行ったのはInfoSys。 InfoSysは、Fortuneマガジンが"Top Companies for Leaders 2007' list"の１０位に選んだ、インドの「IT産業」の花形。

ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと

iPhoneに関しては、まだ誤解している人も多いようなので、念のために解説しておくと、iPhoneがこれほどまでに通信業界で注目されているのは、マルチタッチのUIを採用しているからでも、NextStepの血を引く最先端のiPhoneOSを積んでいるからでもない。NTTドコモなどの旧来型の通信キャリアからみれば「単なるデバイスの調達先」でしかなかったデバイスメーカーがキャリアのビジネスに口も手も出している点にある。 私がAppleとAT&Tの提携発表で一番驚かされたのは、その料金体系であった。パソコン並にネットワークを使うiPhone向けの使い放題プラン（日本の「パケ放題」に相当する部分、ただし容量制限は一切ない）が月々わずか２０ドルというのは、本当に破壊的な価格である。この価格故にiPhoneは非常に魅力的なデバイスとなっているし、これだけ普及している。もちろん、それを実現するためにAT&

この業界で仕事をしていると、しばしば迫られるのが「どのプラットフォームに向けて商品開発をして行くのか」という決断。会社としての経営判断の場合もあれば、個人のスキルアップやキャリアパスのための判断の場合もあるが、いずれにしろ限られたリソース・時間をいかに有効に使うか、という点ではとても大切。 パソコン用のソフトウェアであれば、「Windows向けに作るのかMac向けに作るのか」というOSレベルでの選択肢もあるし、「Windows Vista独自の機能を使って差別化を図るのか、それともWindows XPでもちゃんと動くように作ってまずは大きな市場をとりに行くのか」というOSのバージョンレベルでの選択肢もある。もちろん「そもそも特定のOS向けのアプリを作るべきか、それとも、すべてウェブ・アプリケーションとして作るか」というアーキテクチャ・レベルでの選択肢もある。 「少なくともここ数ヶ月はiPh

毎日のように「iPhoneアプリでApple Design Awardを取るぞ！」と騒いでいるので、知り合いに「それって（現実が分かっていない）大学生のノリですよ」と指摘されてしまった私だが、マイクロソフトを２０００年に退社してからは、ひたすらモバイル・組み込みの世界で仕事をしてきた私としては「俺が取らなくて誰が取る？」という気分。その超楽天的な態度が彼が言うところの「大学生のノリ」なのだろう。 市場に受け入れられるアプリを作るためには、もちろん「誰にどんな価値を提供するのか」が一番大切。しかし、そこには残念ながら成功の一般方程式はないので、今日は比較的に一般化しやすい「どう作るか」という部分に関して、まとめることにした。 1. ユーザーの利用シーン・使用パターンを良く考えて作る パソコンやゲームコンソール向けのソフトと大きく違うのが、ユーザーの使用パターン。iPhoneに限らず、携帯電話

大まかな設計図をあたまに浮かべ、おもむろにコードを書き始める 下回りの部品から順番に、丁寧に積み上げて行く それでも必ず後から下回りの設計に気に食わない部分が出てくるので、 苦しくてもそこは躊躇せずに壊しては作り直す そうして行くうちに、だんだんと下の方から設計がしっかりしたものになってくる 踏み固められた地面が固くなるように、少しづつ強固なプラットフォームが作られて行く 「今日はここまで実現しよう」と決めたら死にものぐるいでそこまで走る でも頭が回らなくなってきたら早く寝る そうやって愛しい我が子を育てる様にコードを一行一行書いていく 何百万人、何千万人もの人に使ってもらえる日を夢見ながら プログラミングという楽しみがある時代に生まれて来ることができた幸せを噛み締めながら

これを読んで、「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が作れなかったのはエンジニアが悪い」と決めつけているかのように誤解をされてしまっているのが私としてはとても残念。 せっかく私の本を読んでいただ