Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
UIプロトタイプ：autocomplete (jQuery plug-in jSuggest)
昨日に引き続いて、今日も作成中の Google App Engine アプリ用のUI部品の作成。HTMLの一部に記述された（もしくは別途JSONで取得した）ワード・リストの入力を autocomplete を使って簡単にしようという試み（Google Suggestのようにダイナミックにリストを取得する必要はない）。 そこで、まずは既存のライブラリ・プラグインの調査から。必要とする人も多いようで、少し調べただけで２０個ぐらい見つかる。デモを見て５つに絞ってからそれぞれのソースコードを解析。例によってどうしようもない品質のコードもあるので、結局のところたどり着いたのは、比較的コードがきれいなこの二つ。 jQuery Autocomplete Mod JQuery Plugins by Dylan Verheul - autocomplete どちらかをそのまま使っても良かったのだが、どちらも
「リニアにスケールするように作れる」からこそのGoogle App Engine
Google App Engineを使った最初の作品 Tiny Message （http://tinymsg.appspot.com）をリリースしてまだ２０時間経っていないが、設計の過程でいろいろと学べたことがある。 その中でも一番収穫として大きいのは、「Google App Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。 もちろん、Google App Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Entity Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。 リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデー
HTML5入門：アニメーションの実装方法３種
HTML5・CSS3のような新しい技術の問題点は、HTML4やらFlashなどの枯れた技術と違ってノウハウ・ライブラリ・ツールとかがまだ十分にそろっていない事。普及のタイミングもまだはっきりとしていないこの段階で手を出せない・出しにくいと感じている人が多いのも良く理解できる。 私から見れば、逆に「こんな楽しい状況は滅多にない」わけで、商売になるかならないかは二の次にしていろいろと試したくなる。 今日作ったのは、HTML5+CSS3上で可能になる（ただし現在ではWebkit独自の拡張を含む）３つのアニメーション・テクニックの比較（左に貼付けたものがそれ、Safari/Chromiumだとすべて動く。Firefox/OperaだとDOMとCanvasのみ（ただし別ウィンドウで開かないとCanvasが動かないークロス・ドメインセキュリティのバグか？））。 詳しくはソース（参照）を見ていただければ
Javascript雑学：SetTimeoutについて知っておくべき事
昨日のベンチマーク・プログラムだが、MacやWindows上で走らせて60-70fps程度しか出ていない事に驚いた人も多いかも知れないのでひと言補足しておく。 あのベンチマーク・プログラムは１フレーム描画するごとにSetTimeout()を使って1msの遅延で関数updateFrameを呼び出し、実際に１秒間に何回呼び出されるかを測定している。スマート・フォン上でこのベンチマーク・プログラムを走らせると、フレームの描画の部分に30msとか40msとかが必要なので、その結果33fps、25fpsなどの測定結果が得られる。 ということは、Javascriptの実行速度が猛烈に早ければ1000fpsも可能なはずだが、どんなに高速なパソコンを使おうと、どんなに描画のロジックを単純化しようと、実測値が通常100fpsを超えることはないのをご存知だろうか。
モバイルブラウザーのデファクトスタンダードになりつつあるWebkit
最近、なぜかいろいろなところでHTML5やら モバイル端末向けのブラウザーの話をすることが多いのだが、今年になってトレンドとしてはっきりと見えてきたのは、WebKitがモバイル端末のブラウザーのデファクト・スタンダードになりつつあるということ。 私自身、最初にAppleがブラウザーを作ると聞いた時には「なんでそんな大変なことを今更？片手間でできる仕事じゃないぞ」と思ったりしたわけだが、その予想に反してAppleが見せた本気度とリーダーシップには本当に関心してしまった。 世の中にすでに何百万とあるサイトとコンパチビリティを保つというだけでも大変な作業なのに（経験者語る）、CANVASやCSS Transform/Transitionなどの新しいコンセプトを次々に導入してHTML5の標準化でリーダーシップを取っている点は注目に値する。 「スタンダードを決める」立場に自分を置く事がどのくらい重要
iPhoneを持っている人へのアンケート調査結果
先日の「iPhoneを持っている方々へのアンケート調査」には、１４００人以上の方々にご協力いただけ、とても感謝している。iPhoneを持っていない人へのアンケートと合計するとパソコンからフォームを作るだけで２０００人以上の人たちから回答がいただけたことになる。 以前、スマートフォンに関する意識調査を街角インタビューで集めたことがあるが、人を三人半日雇って半日でかろうじて２００集めることが出来た事を覚えている。ブログというメディアにはまだまだ開拓されていないポテンシャルがあるというのが実感である。 まずは、いつからiPhoneを持っているかという質問に対する回答。過半数が日本でiPhoneが発売になったばかりの２００８年の第二四半期からという結果は、このブログの読者にアーリー・アダプターが多いことの反映だとは思うが、それに続く半年間の伸びの鈍りは、典型的な「キャズム」と呼ばれる新しいデバイス
「官僚たちの夏」と「ガラパゴス携帯」と
知り合いの勧めで録画したままにしてあった「官僚たちの夏」を今になって見ている私だが、あのドラマを単純に「なぜ戦後の日本はあれほどの急成長をとげたのか」という視点から見るだけでなく、「その同じ日本でなぜガラパゴス携帯ができてしまったのか」を考えながら見るとより面白い。 「今の官僚や企業が（あのころの官僚や企業とくらべて）だらしないから」という見方もあるかも知れないが、私としては「そもそも官僚主導の産業政策が今の時代に合わなくなっている」と見る方が正解に近いように思える。 もちろん、その場その場で異なる状況があるので、あまりに単純化して見るのは危険だが、少なくともアナログ方式からデジタル方式に移行した2Gケータイの時代に霞ヶ関主導で「モトローラやノキアなどの海外メーカーに席巻されることを嫌い、あえて日本独自の方式を採用して国内の携帯機器産業を保護・育成しようとした」ことは歴然とした事実である。
「戦略的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側、という
Life is beautiful: Windows95と地上の星
Windows95の開発の総責任者であるDavid Coleから開発の主要メンバーに緊急召集がかけられたのは、Windows95の開発も大詰めを迎えた1994年末のことである。 Shell（デスクトップ、エクスプローラ、スタートメニューなどのユーザーインターフェイス）の開発を担当していたSatoshiは、いままでの経験からこの手の緊急招集が良い知らせでないことはないことは知っていた。 David Coleが深刻な顔をして緊急招集の理由を説明し始める。Windows95そのものの開発は順調に進んでいるが、Windows3.1との互換性の維持が思うように進んでいないのである。 「このままだと、９５年中にリリースすることはできない」 深刻な問題である。既に当初の予定より１年以上遅れているWindows95のリリースをさらに遅らせて95年のクリスマスシーズンを逃すことはOffice95を同時にリリ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
