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

ここ最近はブラウザーの上で動く思いっきりRIAなアプリケーションを書いている私。こと通信の部分になると JavaScript での開発効率が、C++/Java/Objective Cなどと比べて格段に高いことをつくづく感じている毎日なので、今日は、そのあたりを少し解説してみようかと思う。 サーバーのAPIにアクセスするプログラムを書く方法は色々とあるが、「サーバー上の特定のURLにHTTPでアクセスして結果をXMLやHTMLやJSONで受け取る」というケースに限定すれば、基本的に３つのパターンに分けられる。 1. 同期通信 result = urlfetch.fetch("http://www.google.com/") if result.status_code == 200: doSomethingWithResult(result.content) その書きやすさのために、実務経験の

飛行機の中に９時間ほどネットもテレビもない環境に閉じ込められていたおかげでObjective-CとiPhone SDKの勉強もとても良くはかどり、簡単なアニメーションぐらいアプリなら作れる様になったし、Objective-Cでプログラムを書くことにもだんだん違和感がなくなってきた。 しかし理解が進めば進むほど分かってくるのがiPhoneがいかに他の携帯電話と比べて進化しているかということ。OS Xの不要な部分はばっさりと切り捨てつつ、Objective-Cの拡張性を最大限に利用したとても完成度の高いものとなっている。 特に良くできているのが、iPhone特有のユーザーインターフェイスを実現するために仕組みと、メモリ消費と電力消費を抑えるための仕組み。特に、バーチャルメモリの仕組み、リードオンリーリソースの扱い、ハードウェアアクセラレータの活用、アプリケーションプロセスの扱いなど、それぞれが

米国のベンチャー企業に関わる場合、社員であろうと、経営者であろうと、投資家であろうと、社員にインセンティブとして与える株式に関してちゃんと理解しておくことは大切。これから米国のベンチャー企業で一旗あげようという人たちには必須の知識だ。今までは「なんとなく理解していた」だけだったが、今回、ちゃんと勉強する機会があったので、ここにまとめておく。 １。Incentive Stock Option（ISO） これは、二種類あるストック・オプションのうちでも非常に特殊なもの。税金面で言えば、オプションを与えられた時（grant）にも行使した時にも税金が発生せず、株式を売却して現金を得た時に初めて税金がかかる。それも、キャピタルゲインの扱いなので、税率は低い（現状１５％）。 良い話ばかりのISOだが、ISOと認められるための条件はとても厳しい。 （１）オプション・プランは株主の同意が必要 （２）オプシ

Railsの勉強がしばらくストップしてしまったので、今日はビデオを見てお勉強。Rails Envyの「ActiveRecord Tutorial」は長さも２５分とちょうど良いし、「ActiveRecordとはなんぞや」を具体例を交えて簡潔に教えてくれるのでとても良い勉強になる。 英語だが、冒頭の部分を乗り越えればあとはプログラミングの話なので、日本人にもそれほど難しくないはず。念のため、オープニングの部分のみ、超訳しておいた。 ActiveRecordのアイデアは、いったいどこから来たのか？ まずは"Active Record"の意味から （ActiveRecordではない点に注意） "Active Record"とは、デザイン・パターンの一つ。 どうやってデータベースにアクセスするか？ SQLにプログラムから直接アクセスする方法もあるが...ちょっと不便 データベースのテーブルをオブジェ

今朝になって、話題のgPhoneがアナウンスされた（参照１）訳だが、大方の予想を裏切ってそれはデバイスではなくてソフトウェア、それも2005年にGoogleが買収したandroidという会社の作っていたLinuxベースのマイクロ・カーネルと、バーチャル・マシン。androidの買収とともにGoogleに入ったAndy Rubinがandroidの前に作ったSidekick (Danger Inc.)の中身を良く知る私としては、「これってDanger OSとどこがちがうんねん？」という感じ。 ほぼ同じ時期に会社をスタートしたこともあり、Dangerの連中とはスタートアップ当時から一緒に仕事をし、サードパーティとしてSidekick向けのソフトウェアを作った数少ない会社の一つがうちの会社UIEvolution Inc.だ（資料２）。 Javaに似てはいるが微妙に異なるバーチャル・マシンを持ち、

弾：最初の質問です。なぜRubyを選んだのですか？ DHH：極端なことを言うと，Rubyが一番美しく自分のコードが書けるからです。 【小飼弾のアルファギークに逢いたい♥：#2　Ruby on Rails作者 David Heinemeier Hansson（前編）　RubyでRailsを書いたわけ｜gihyo.jpより引用】 この記事を既に読んだ方も多いと思うが、この「Rubyが一番美しく自分のコードが書ける」というセリフは非常に重要である。「イテレータに片思い」というエントリーで書いた通り、Rubyには生みの親の「コードは読みやすくあるべき」という魂がしっかりと込められており、それが「コードの美しさ」に繋がっているのである。 私がRubyを触り始めて一番強く感じたことは、Smalltalkとの類似点である。私自身、９０年に数ヶ月間Smalltalkにどっぷりと使っていた時期があるが（マイ

今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たち

UIEvolution の起業は私にとっては初の起業であった。今から思い直してみると、ビギナーだった故のたくさんの失敗をしてきたが、今の私から見て「良くそれなしで会社として成り立ったなァ」と言いたくなるよう恥ずかしいことを一つしている。 「User Experience Matters」、「Pervasive Application」など、会社の外に向けたビジョンやミッションははっきりと打ち出していたものの、どんな人を採用してどんなカルチャーの会社にしたいか、という会社作りにおいてもっとも大切な「企業理念」を目に見える形の言葉にしておかなかったのである。 そもそも「企業カルチャー」の大切さを私が理解していなかったこともあるし、私自身の中でも「どんなカルチャーの会社にしたいか」というイメージが固まっていなかったのもある。Google・Microsoft・Sony・Honda、どれもファウンダ

訪問先でUIEngineとFlashの違いを良く聞かれるので、それにちゃんと答えられるようにとFlashの勉強を始めた。これが一番最初の作品。写真を動かしたり回転させたりできる。いきなりActionScriptの3.0から入る人も珍しいのかも知れないと思いつつ書いてみた。まだまだ改良の余地はあるが、とりあえず今日はここまで（マウスのキャプチャーのしかたが分からん…ととりあえず書いてみるテスト^^;）。

CNetでも報道された通り、Sunが独自のスクリプト言語JavaFX Scriptを発表した。テクノロジーの優劣だけで決まるものではないので、この試みがうまく行くかどうかは何とも予測しがたいが、とりあえず言語仕様が公開されたので目を通してみた。 私なりに興味深いと思った点は以下の５つ（ただし、私なりの拡大解釈が多少入っている可能性もあるので要注意）。 １．宣言型のUIをサポートしていること 宣言型大好き人間の私としては、この方向性は大賛成（ちなみに、UJMLも宣言型のUI言語^^）。"押してね！"というラベルがついたボタンを表示するには、こう書けば良い。 Frame { content: Button { text: "押してね！" action: operation() { System.out.println("押してくれて、ありがとう"); } } visible: true } ２

このブログの場合、ほとんどのエントリーはその場で思いついたことを５～１０分ぐらいでサラサラと書くのだが、たまには気合を入れて時間をかけたエントリーを書くこともある。特に気合を入れなければいけないのが、自分が得意でないテーマについて書くとき。最近だと「コーポレート・ファイナンス入門」が良い例。 自分の専門以外のことを得たばかりの知識をもとに書くのだから、完全に的外れなこと書いて赤っ恥をかいてしまう可能性も大きい。だからこそ気合を入れなければ書けないのだが、それでもときどきそんなエントリーを書いてしまうのは、そうすることにより「新しいことを勉強しなければいけない状態」に自分を追い込むのが好きだし、そこにあるスリルが楽しくてしかたがないからだ。 しかし、ブログならではの楽しみは、そこに返ってくるフィードバック。私の間違いを丁寧に指摘してくれる人から学べることも多いし、私が言い足りなかったことを補

Bookmarkletの存在を知ってから、いくつか気に入ったものをインストールしたり、自分で作ってみたりして遊んで来たのだが、普通のウェブページへのリンクも含めて数が増えてくるとツールバーが一杯になってしまい、使い勝手がぐっと悪くなる。 そこで、いくつかのBookmarkletの機能を一つにまとめた、メタBookmarkletを自分のために作ったのだが、せっかくなので、ここで公開。名づけて「シオレット」だ（bookmark=しおり）。 【シオレットのインストールの仕方】 [シオレット]　←　このリンクを右ボタンでクリックして「お気に入り/bookmark」として追加する。左ボタンでクリックしてしまうと、シオレットがこのページ上で動いてしまうので注意（その場合は、グレーの部分をクリックすればメニューを閉じることができる）。 追加する場所としては、Firefoxの場合は Bookmark To

１２月に日本に出張したときのインタビューがpodcastとして公開されたので、ここで報告。 Universal Interview, 第19回「アプリケーションやコンテンツへデバイスを問わないアクセスパスを提供～パーベイシブ・アプリケーション時代を築く」 （リンク先のページの「パソコンで再生」をクリックするとパソコンで再生できる） podcastインタビューと言うのは初体験だったが、自分で聞いた感想は、「無駄な言葉がやたらと多い」だ。 インタビュー記事の場合は編集者の手が入るし、ブログの記事の場合は自分で推敲できる。しかし、インタビューの内容がそのまま音声として公開されてしまうpodcastの場合は、もう少し言葉を選んで簡潔に話さなければならないと自分でも反省。まだまだ修行が足らない。 ちなみに、普通は一回分におさまるインタビューが、私があまりにもたくさんしゃべりすぎたために、19回、20

会社のエンジニアの一人が見つけてきた Dion Hinchcliffe という人の「Ten Ways To Take Advange of Web 2.0」というブログエントリー。未だに「Web2.0とは何か」を延々と議論し続けている理論先行型のブログが多い中、実際のウェブ・サービス・ビジネスにどう活用したら良いかをきれいにまとめてある点が評価できる。 英語の勉強にもなると思うので、ぜひとも原文を読んでいただきたい。 … と突き放そうかとも思ったのだが、毎日のように私のブログを読みに来ていただいている方々への感謝の意味も含めて、私の意見もまぜながら、解説して行こうかと思う。ただし、結構内容が濃い記事なので、一度に全部を解説するのは時間的に難しい。そこで、一つずつ順番に解説して行く。 １．Encourage Social Contributions With Individual Benef

先日このブログで公開したばかりの、「ライブドア事件」専用トラックバック・ステーションであるが、毎回ページが開かれるたびにデータベースにアクセスする仕組みで作ったのだが、そんな作りのままではトラフィック増には耐えられない。そこで、良く出来たブログ・サービス（例えばMT）の様に、変更があったときに（つまり、トラックバックが送られてきた時に）、データベース上のデータからHTMLページを生成しておき、閲覧時にはそれを返すように変更することにした。 その作業を進めているときに、この手法の一つの欠点に気が付いた。MovableType がしているように、ヘッダーも含めた全HTMLページを生成するようにしておくと、その中にスタイルシート（CSS）へのリンクを埋め込むことになるので、スタイル（見た目）が固定化されてしまうのである。これでは面白くない。そこで、複数のスタイルシートを用意しておき、閲覧時に動的

最近、「これからのウェブ・アプリケーションはAjaxだ」という声を良く聞く。ソフトウェアを生業としているエンジニアとしては、この手の「流行もの（hype）」に触れた時には、表面的なものに踊らされずに、その本質を自分なりにしっかりと捕らえて消化・吸収して自分のものにしなければいけない。今までも、「オブジェクト指向」、「マルチ・ティアー・アーキテクチャー」、などの言葉が一人歩きするたびに、「これからは○○だ」とか「○○の時代は終わった」などと、過激なことを言って読者の目を引こうとだけするマスコミや企業のマーケティング戦略に数多くの人が踊らされてきた。 そんなノイズだらけのメッセージに混乱させられた結果、「Ｃではオブジェクト指向のプログラミングは出来ない」と信じているエンジニアがいまだに沢山いることは全く嘆かわしいことだ。「オブジェクト指向のプログラミング」は、設計姿勢・プログラミングスタイルに