Google App Engine入門：実行効率を犠牲にせずに開発効率だけを上げるテクニック
一つ前の富豪プログラミングのエントリーともつながる話だが、Google App Engineは「ちゃんとスケーラビリティを考慮してアプリケーションを作るには何に気をつけなければならないか」を勉強するには絶好の環境だ。そこで今回は、その「ケチな大富豪的なプログラミング」の実践編。 Google App Engine上のアプリをいくつか書いているうちに、必要に迫られて自然発生的にできてきたのが、gdispatchという数十行のコードからなる小さなモジュール（ソースコードはgithubに置いてある）。これをGoogle App Engineに標準で付いて来るwebappと組み合わせてフレームワークとして使っている。 gdispatchを設計する上で重視したのは、 （１）Google App Engine上でのアプリの開発を効率化する上で「明らかにこれがあると開発効率が格段に向上する」というもの以
JavaScript HTMLテンプレートエンジン SNBinder 公開
先日予告したSNBinderのオープンソース化、GitHubに簡単なREADME付きでアップロードしたのでご覧いただきたい。 https://github.com/snakajima/SNBinder SNBinderは、ひと言で言えば「ブラウザー上でView(テンプレート)とData（JSON）を結合して HTML を生成するテンプレートエンジン」である。 ９０年の半ばから急速に広まったインターネット。サーバー側でダイナミックに生成したHTMLページをブラウザーで閲覧するだけ、というシンプルでエレガントなアーキテクチャゆえの成功だ。しかし、ブラウザーの高機能化に伴い、JavaScriptを駆使して使いやすさを向上しようという試みが色々なウェブサイトで行われている。GMail、Google Docs、Facebookなどは良い例だ。 その方向性を究極にまで突き詰めると、サーバー側は（MVC
誰にでも分かる「クラウド」
ここの所、「クラウド」という言葉が一人歩きしているようなので、言葉の定義を明確にして業界関係者間のコミュニケーションをスムーズにすることを試みてみたい。 クラウド・コンピューティング もともとは、すべての計算をクライアント側で行う「デスクトップ・コンピューティング」に対して、（しばしば雲の形で図式化される）ネット上のサーバー側で計算してしまうことを表すために生まれた言葉。しかし、後述の「クラウド・サービス」の普及とともに狭義・広義・誤用・バズワード化が進み、今や「ユビキタス」と同じぐらい使っている人によって意味が異なる言葉になりつつあるので要注意。 クラウド・サービス アマゾンのec2、GoogleのApp Engineのようにサーバーの能力を従量課金方式で提供するサービスのこと。自社サーバーやレンタルサーバーと比べて、初期投資の面でもスケーラビリティの面でも優れていることが特徴。 クラウ
なぜ気象庁のホームページには地震速報のフィードがないのか
先日、地震速報のフィードがないものかと気象庁のホームページを探していてこんな記述を見つけた。 （財）気象業務支援センター 天気予報や天気図、注意報、地震情報などの即時情報は（財）気象業務支援センターから必要経費によりオンラインやファックスなどで入手することができます。 データの種類や料金などの詳細については（財）気象業務支援センターのホームページに掲載されていますのでご覧下さい。 普通に考えれば、オンラインでのデータの配布コストは限りなくゼロに近いのだから、税金を使って集めた気象情報や地震速報などはRSSやJSONのフィードとして気象庁のホームページから無料で配布して当然である。 ところが実際には、FAXや電話でしか情報が流通できなかった時代の名残りか、気象業務支援センターという財団法人が一括して、それも有料で配布を担当しているのだ。 ならば、さっさとそんな仕組みは廃止して気象庁から直接フ
高速道路無料化をするなら「エコカーのみ無料」にすべき
題名だけで私が何を伝えたいかはほぼ理解していただけると思うが、私としては、高速道路の全面無料化には、 今後の日本経済にとってプラスになるとは思えない 環境に優しくない さらなる渋滞をまねく その財源がどこにあるのか不透明 という理由で反対。どうせやるのであれば「エコカーとして国から認定された車のみ無料」とすべきだと思う。これにより、 日本の消費者の間でエコカーの人気が上がる →日本の自動車メーカーのエコカーへの開発投資意欲が上がる →日本にエコカー関連の知的財産が蓄積する →日本の自動車メーカーの海外での競争力が増す →日本の景気が良くなる という相乗効果を狙う。財源はガソリン税および無料対象外の車の高速道路使用料金を当てる。 さらに、エコカーの基準を毎年厳しくすることにより、「日本で自動車メーカーを経営しようとしたら、毎年厳しくなる環境基準をクリアする車を作りつづけない限りやっていけない
１２月３日にAndroidに関して講演します
久しぶりに日本で講演をすることになったので、ここで告知させていただく。詳しくは日経エレクトロニクスのアナウンスメントを見ていただくのが良いと思うが、今回は「Android家電の衝撃」というテーマのいくつかの講演＋パネルディスカション。 技術的に突っ込んだ話というよりは、ビジネス上の意味だとか、Googleの戦略という話になるとは思うが、UIEvolutionの創設者としてモバイル・組み込み業界でいろいろとビジネスをして来た経験や、iPhoneディベロッパーとしてiPhoneアプリを開発・販売して来た経験を通したいろいろな話ができると思う。 それにしても、最近は色々と試したいもの・勉強したいものが多くて困る。ここ一年ばかりどっぷりと浸かって来たのがiPhone SDK、それに最近はHTML5、CSS3、Google App Engine、Pythonが加わり忙しくてしかたがない。 まあ、この
Cloud Computing考：Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた
Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいの
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
DellのAndroidケータイが意味するもの
CNet/WSJにも書かれていたが（参照）、DellがAndroidを使ったスマートフォンのリリースに向けて着々と準備を進めているらしい。 Microsoft/Intel連合がOSとチップセットという組み合わせでパソコンビジネス（ハード）への参入障壁を極端に低くし、大量の新規参入組と自然淘汰により一気にパソコンの低価格化・コモディテぃ化が進んだことは記憶に新しいと思うが、それと同じような波がようやく携帯電話の世界に押し寄せて来ている。 ここに来てはっきりと見えて来たことがいくつかある。 Androidにより参入障壁が大幅にさがり、中国・台湾・韓国などからメーカーが大量に参入してくる そういったメーカーに製造をまかせ、自分はデザインとブランドだけで勝負する企業も参戦する（Dellはだぶんここに位置することになる） スマートフォンとそれ以外の境があいまいになり、フルブラウザーを搭載するのがあた
「Flash vs. HTML5」という構図がはっきりと見え始めたぞ、と
業界関係者（特にスマートフォン関係の仕事をしている人たち）少し前からすでに気がついていた話だが、今回のAdobeからの一連のアナウンスメントで明らかになってきた「HTML5対Flash」という構図。とてもワクワクする戦いだ。 ウェブ上のリッチコンテンツという分野でリーダーシップ・ポジションを取りながらも、「無料Flashゲーム」と「ウェブサイトの見栄えをちょっと良くするアイ・キャンディ」というニッチなポジションに一度は追いやられるように見えたFlash（数年前の話）。しかし、動画フォーマットがReal Networks、Microsoft、Appleの三強いの間で中に浮く隙間を付いた戦略で、見事に「ウェブ上のマルチメディアのデファクト・スタンダード」のポジションをがっちりつかんだかに見えるFlash（現在）。しかし、その地位も安泰ではない。 Adobeにとって一番頭の痛い問題はiPhone
モバイルブラウザーのデファクトスタンダードになりつつあるWebkit
最近、なぜかいろいろなところでHTML5やら モバイル端末向けのブラウザーの話をすることが多いのだが、今年になってトレンドとしてはっきりと見えてきたのは、WebKitがモバイル端末のブラウザーのデファクト・スタンダードになりつつあるということ。 私自身、最初にAppleがブラウザーを作ると聞いた時には「なんでそんな大変なことを今更？片手間でできる仕事じゃないぞ」と思ったりしたわけだが、その予想に反してAppleが見せた本気度とリーダーシップには本当に関心してしまった。 世の中にすでに何百万とあるサイトとコンパチビリティを保つというだけでも大変な作業なのに（経験者語る）、CANVASやCSS Transform/Transitionなどの新しいコンセプトを次々に導入してHTML5の標準化でリーダーシップを取っている点は注目に値する。 「スタンダードを決める」立場に自分を置く事がどのくらい重要
AT&Tがモトローラ製のAndroid携帯を「時代遅れ」と拒否
今日、米国の携帯業界関係者の間で話題に上ったのが「AT&T rejects Motorola's Android smartphones」という記事。AT&Tから正式に発表された訳ではないが、たぶん真実に近いだろうことは容易に想像できる。 AppleがハードからソフトまですべてコントロールするiPhoneと比べ、GoogleはOSを提供するだけで、最終的な製品の仕上がりはハードメーカーまかせのAndroid携帯は「ソウル（魂）のない」中途半端なデバイスになりがち。 このあたりの事情はMicrosoftのOSを使ったWindows Mobile端末も同じで、「個別の機能を見る限りiPhoneに負けてはいないのになぜか魅力的でない」デバイスができてしまうのは、ソフトからハードまで一貫して責任を持って作り上げることが不可能だから。 この業界の歴史を見ると、古くはMicrosoftが旗ふり役だった
「官僚たちの夏」と「ガラパゴス携帯」と
知り合いの勧めで録画したままにしてあった「官僚たちの夏」を今になって見ている私だが、あのドラマを単純に「なぜ戦後の日本はあれほどの急成長をとげたのか」という視点から見るだけでなく、「その同じ日本でなぜガラパゴス携帯ができてしまったのか」を考えながら見るとより面白い。 「今の官僚や企業が（あのころの官僚や企業とくらべて）だらしないから」という見方もあるかも知れないが、私としては「そもそも官僚主導の産業政策が今の時代に合わなくなっている」と見る方が正解に近いように思える。 もちろん、その場その場で異なる状況があるので、あまりに単純化して見るのは危険だが、少なくともアナログ方式からデジタル方式に移行した2Gケータイの時代に霞ヶ関主導で「モトローラやノキアなどの海外メーカーに席巻されることを嫌い、あえて日本独自の方式を採用して国内の携帯機器産業を保護・育成しようとした」ことは歴然とした事実である。
GoogleのAndroid向けのアプリビジネスはなぜ魅力的ではないか？
PhotoShareをiPhone向けに提供して早くも一年になるが、もっとも良く投げかけられる質問は「PhotoShareはAndroidとかの他のプラットフォームに移植しないの？」というものだ。 少し前までは、「まだiPhone以外のビジネスが十分に大きくないから今はまだ早い」、「iPhone上でやるべきことはまだ沢山あるから」、などと答えて来たのだが、最近は少し見方が変わってきた。 今の勢いでHTML5が進化・浸透してくれるのであれば、わざわざ移植コストをかけてAndroidやWindows Mobile向けにネーティブ・アプリを開発するよりは、少なくともUIの部分をすべてHTML+Javascriptにまかせたアーキテクチャでのインタラクティブなアプリの開発というのも十分に可能性があるように思えてきたのだ。 この「HTML+Javascriptですべて出来るじゃん」という発想は、そも
「戦略的OS」の開発がことごとく失敗している点に関する一考察
９０年代にIBM、Microsoft、Apple各社が巨額の開発費を投じて作っていた「戦略的OS」がすべて失敗してしまったことを皆さんはご存知だろうか？ IBMが作っていたのはOS/2。元々はMicrosoftとの共同開発だったが、途中で仲違いをしてしまい、最後はIBMだけが細々とサポートしていたことすら覚えていない人が多いとは思うが、Windows95の成功であっというまに市場から消えてしまったのがOS/2。具体的な数値は公開されていないので分からないが、両社が数百人体制で数年間開発していたので、少なく見積もっても日本円で数百億円は投じられたことは間違いない。 Cairoの方は私自身が初期のころにいたこともあるし、最終的には「Chicago(Windows95のプロジェクト名) vs. Cairo」の戦いの最前線にいた私としては知りすぎている点も多いのだが、一つだけ確かなのは、プロジェク
怒濤の二月、６つの新製品と３つのアップデート
マイクロソフトを辞めてからもう９年も過ぎるが、辞めた一番の理由は「会社が大きくなりすぎて思いっきりコードが書けなくなった」こと。私がいた時代ですでに１０００人のエンジニアを抱えたWindowsチームの生産効率は、「エンジニア一人あたり一日1.5行」という悲惨なもの。 プロジェクトが肥大化して人が増えて来ると、それに反比例して生産効率が下がって来るのはどうしても避けられないが、この規模になると常にすし詰め状態の満員電車の中でマラソンをしているしているような気分で、前に進んでいるのかどうかすら分からなくなってくる。 特にWindowsクラスの大きなプロジェクトになると、その複雑さのために開発期間が３年とか５年とかの長期なものになってしまい、途中で何がなんだかわからなくなってしまうケースもしばしばだ（Windows Vistaが良い例）。 逆に今は、増井君がサーバー側・私がiPhone側、という
マーケティング：SMARTな目標設定
University WashingtonでのMBAの授業も既に二年目に入った。４月に二つ目のベンチャービジネスを始めたばかりの私としては、授業で聞いたことをすぐに実践できるのでとても良い勉強になる。「MBAは何年か実務を経験してからこそ受ける価値がある」という話は良く聞くが、自分でビジネスをしながら受けるMBAの授業は格別である。 今回ためしたのは、マーケティングの教授が口をすっぱくして繰り返す "S・M・A・R・T" な目標設定。いかなるマーケティング活動をする場合においても、まずはその目標設定をしっかりすることが大切で、その際に大切なことは、 Specific: 目標は具体的でなければならない Measurable: 目標が達成できたかを計ることができなければならない Atteinable: 目標は（たとえ難しくとも）十分に達成可能でなければならない Relevant: 目標はそのビ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Windows Mobileに「全力投球」を決めたMicrosoftの厳しい戦い
で、実際のところHTML5でどのくらいのアプリが実装できるのか実験してみた
外国為替相場取引（FX）で確実にもうける方法（必勝法）