ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
Google App Engine向けのアプリを作る際に最初に悩んだのはフレームワークの選択。Google App Engineにはwebappという最低限の機能を持ったフレームワークが付いて来るが、Python使いの人たちの間では、DJangoというフレームワークが広く使われているらしいし。かといって、あまり大きなフレームワークを使うと、パフォーマンスのチューニングとかもしにくくなるし、フレームワークそのもののバグや制限に悩ませられる可能性もある。 そんな中で増井君が見つけてくれてまず試したのが、Junoというフレームワーク。DJangoと比べると遥かに小さく、WebappよりもURLのルーティングのメカニズムとかが充実している。 そこで一旦はアプリをJunoの上で作り始めたのだが、Junoのソースコードを見ているうちにいろいろと気に入らないところが出て来た。不必要にオプションが多いし、
一つ前の富豪プログラミングのエントリーともつながる話だが、Google App Engineは「ちゃんとスケーラビリティを考慮してアプリケーションを作るには何に気をつけなければならないか」を勉強するには絶好の環境だ。そこで今回は、その「ケチな大富豪的なプログラミング」の実践編。 Google App Engine上のアプリをいくつか書いているうちに、必要に迫られて自然発生的にできてきたのが、gdispatchという数十行のコードからなる小さなモジュール（ソースコードはgithubに置いてある）。これをGoogle App Engineに標準で付いて来るwebappと組み合わせてフレームワークとして使っている。 gdispatchを設計する上で重視したのは、 （１）Google App Engine上でのアプリの開発を効率化する上で「明らかにこれがあると開発効率が格段に向上する」というもの以
Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。 Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。 もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。 App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エン
今週に入ってから、ようやく少し本気でGoogle App Engineでプログラムを書き始めている私だが、ようやく Entity Group の使い方が分かって来たので簡単に解説してみる。 Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。 イメージとしては、まず「一つのハノイの塔を三人で同時に遊んでいる姿」を思い浮かべると分かりやすいかも知れない。全くのルールなしで皆で同時に遊ぼうとすると、腕が交錯してぐちゃぐちゃになってしまう。 そこで、「ある時点でハノイの塔ボード（三つの棒を支えている水平に置かれた板）に触ることが出来る人は常に一人。一度ボードに触った人はすべての円盤をいずれかの棒の位置に置いた状態にしてからしか手を離してはいけない。もし自分がハノイの塔に触りたい時に、す
今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。３日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む２０〜３０代の社交
前から常々思っていることだが、何かについて勉強する一番効率的な方法はそれを誰かに教えること。人に教えようとすると、それなりに準備をしなければならないし、自分の頭の中を整理しなければならない。また教える過程でするどい質問をされたり間違いを指摘されて、さらに勉強を強いられることもある。 私がこの手の「入門編エントリー」を書くのは、ほとんどの場合「自分自身の理解をより深めたい」ことが一番の目的であるが、ブログの場合、教室などと違って「その道の達人」みたいな人たちがツッコミを入れてくれるケースもしばしばあるので、そのメリットは何倍にもなる。 先日のクロージャに関するエントリーなどは良い例で、「そんな用途にはmemoizeというデコレータが便利」などの指摘がいただけだけであれを書いた価値があるというもの。 そこで、今日はPythonのデコレータに関して。デコレータがPythonという言語に導入された
最近 JavaScript を書く機会が増えているが、それに従って自分のコーディングスタイルが少しづつだが変化してきているのが分かる。もともと「コードの読みやすさ」や「実行効率」にとことんこだわるタイプだが、（JavaやC++になくて）JavaScriptやRubyにあるクロージャや無名関数が私のコーディングスタイルにとてもマッチしているからだと思う。 簡単な例を紹介しよう。Pythonで書かれた config.py というモジュール。config.yamlという設定ファイルを読み込んで Dictionary として返す config.get() という関数。普通に実装すると、以下のような感じになる。 import yaml _config = None def get(): global _config if not _config: data = open('config.yaml')
一昨日はMVCの話で妙に盛り上がってしまったが、考えてみるとModel/View/Controller間の分離が不十分という話はサーバー側だけの話ではなく、クライアント側にも言える事。事実、私自身も div.innerHTML = "<span class='red'>" + message + "</span>"; みたいなHTMLが混ざったJavaScriptコードを書く事は良くある。特に、最近はJSONとして取得して来たデータセットをリストとして表示するケースが増えて来たが、そんな時に「サーバー側のようなHTMLテンプレートが使えたらいいな」と思う事は良くある。手っ取り早くとりあえず動くものを作るのにはHTML埋め込み型のJavaScriptで良いのかも知れないが、後々のメンテナンスを考えると少なくともModelとViewぐらいはキチンと切り話しておいた方が良い事は確か。 ということ
Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいの
今朝の「iPadでHTML5 Widgetを走らせて遊ぼう」に対して、「もう少しWidgetについて知りたい」との声が聞こえてきたので、「Widget入門編」を書いてみようかと思う。 Widgetとは何か？ 先のエントリーで書いたが、ひとことで言えば「パッケージ化されたウェブアプリケーションである」。通常のウェブアプリは、特定のURLにアクセスすることにより走らせるが、Widgetの場合は、.wgt のエクステンションを持つWidgetファイルをダウンロード＋インストールした上で、それを起動する。 Widgetファイルの中身は、HTML+CSS+JS+メディア・ファイルで構成されており、それをZIP圧縮して、エクステンションを.wgtに変更しただけのものである。 なぜそんなことをするかと言えば、（１）オフラインで動かしたい、（２）通常のデスクトップアプリの感覚で起動したい、（３）パッケージ
昨日の「HTML5: W3C Widget とその応用を考える会」は参加者も多く、私自身とても良い勉強になったが、そこでも予告した通り、iPad発売を記念してWidgetのサンプルをいくつか用意したので、ぜひともお試しいただきたい。 手順は以下の通り。 ステップ１. iPadにCloudReadersをインストールする（iTunes ストアへのリンク） ステップ２. 以下のWidgetをダウンロードする Download 3dClock.wgt (2.5K) ー CSS3を使った３D時計 Download TimeTrial25.wgt (7.8K) ー タイムトライアルゲーム Download JSCalc.wgt (3.4K) ー 電卓 Download QuadraBench.wgt (2.5K) ー Canvas のベンチマークプログラム ステップ３. iPadをPC/Macに繋げ
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
上の三つの絵は、私がiPhone/iPod touch向けのお絵描きソフトSmallCanvasで描いた絵だが、パッと見てどう感じるだろう。「結構絵が上手な絵じゃないか」と思った人も多いかもしれない。 実は上の三つの絵は、SmallCanvasの発売に合わせて、私自身がサンプルとして書いたもの。絵心のない私が苦肉の策で作り出したのが、SmallCanvasのundo/redo機能を駆使して写真のトレーシングをするという裏技（アプリの作者が「裏技」を発明してどうするんだ、とうツッコミはなしで^^;）。下に置いた写真をトレースするために、基本的なデッサンがしっかりとし、これだけで「そこそこ見られる絵」になってしまうから不思議だ。 これで再認識したのは、「絵の上手さ」は、「ちゃんとした構図でデッサンが描けるか」という「テクニック」の部分と、「描き手オリジナルの表現ができるか」という「センス」の部
「マーケティング」という言葉を聞くと「商品に関する情報を顧客に向けて発信する」だけと考える人が多いが、マーケティング部門の役割として同時に重要なのは、顧客のニーズをきちんと探り出して「何を作るべきか」という部分に反映させること。 ちょうど今読んでいるHarard Buisness Reviewにとても良い例が出ていたのでその紹介。 米国のペンキ会社が、競争相手に安売り競争を仕掛けてられ、「利益を削ってでもマーケットシェアを維持すべきか」という厳しい選択に迫られていた。その時にその会社のマーケティング部門が調べ出したのが、主な顧客である塗装業者が何にお金を使っているかというデータ。 そのデータによると、ペンキそのものは経費の１５％にすぎず、大半は人件費だという。それも、ほとんどのケースで、一度塗ったペンキを十分に乾かすために、次の日にもう一度現場に足を運んで二度塗りをしているためによけいな人
シアトルの新聞社Seattle PIにVenture Blogというベンチャー企業をテーマにしたブログを書くJohn Cookという人がいる。その人とたまたま話す機会があったので、以前から聞きたかった質問を投げかけてみた。 私「せっかく良いアイデアを持っていたり、すばらしい技術を持っているのに、投資家からお金を集められずに消えて行くベンチャー企業って沢山あるよね。何とかしてあげることはできないのかな？」 John「それは必要ないと思うな。ベンチャー企業の経営者に一番大切な能力は、『必要なものは何とかして手に入れてしまう能力』だよ。起業資金ぐらい自分で集められない起業家に、ベンチャー企業が経営できるとは思えない。」 確かにJohnの言う通りである。ベンチャーの生き残り合戦は、ダーウィンの適者生存の法則がそのまま当てはまる世界。自然淘汰のプロセスは資金集めの段階から既に始まっている。だから手を
今朝になって、話題のgPhoneがアナウンスされた（参照１）訳だが、大方の予想を裏切ってそれはデバイスではなくてソフトウェア、それも2005年にGoogleが買収したandroidという会社の作っていたLinuxベースのマイクロ・カーネルと、バーチャル・マシン。androidの買収とともにGoogleに入ったAndy Rubinがandroidの前に作ったSidekick (Danger Inc.)の中身を良く知る私としては、「これってDanger OSとどこがちがうんねん？」という感じ。 ほぼ同じ時期に会社をスタートしたこともあり、Dangerの連中とはスタートアップ当時から一緒に仕事をし、サードパーティとしてSidekick向けのソフトウェアを作った数少ない会社の一つがうちの会社UIEvolution Inc.だ（資料２）。 Javaに似てはいるが微妙に異なるバーチャル・マシンを持ち、
Rubyに慣れようと、コマンドライン・ツールなどを作ってみることにしたのだが、すでにUnixに存在しているgrepなどを作っても仕方がない。そこで、指定したブログのURLからHTMLページをHTTP GETで取得し、それをパースしてATOMやRSSフィードのURLを見つけて、それをさらにHTTP GETで取得してタイトルだけ表示する、というツールを作ってみることにした。 できるだけRubyらしい作り方をしようと思いついたのが「Ruby Filter」。Unixのフィルターのようにそれぞれは単一の機能を持ったプログラムをパイプでつなげて複雑なことをさせる。ただし、フィルターからフィルターに渡すものは単なるテキストではなく、オブジェクトのテキスト表現だ（次のフィルターはそのテキストをevalしてから入力として利用する）。 上のブログのURLからRSSフィードを取り出すケースだと、 parseU
先日の「習作UI: 縁日の金魚を再現してみた」というエントリー。特に深い意味もなく作ったのだが、ソフトウェア・エンジニアを目指す学生さんのためにひとこと付け加えておきたいのは、この業界で本気で成功しようと思ったら、この程度のプログラムは、シミュレーションの専門家でなくともサクッと作れるように自分を鍛えておかなければいけない、ということ。 この業界で働きはじめると、担当した仕事によって、データ解析・Java・３D・シミュレーションなどのある特定の分野のプログラミングの経験を積むことになる。そういった経験を通して特定の分野を深堀りしてエキスパートになるのはおおいに結構なのだが、往々にして落ち込んでしまうのが「ボクはJavaのエキスパートだからRubyではプログラムは書かない」、「シミュレーションのことならそれに詳しいエンジニアがいるんだからその人に頼んで」、「今からFlashを勉強している時間
息子の大学で授業参観をする機会があったので聴講したのが「Corporate Finance」の授業。わずか７０分の授業であったが、とても分かりやすかったので復習の意味も兼ねてここに解説してみる。 まず、会社として採用することを考慮している二つのプロジェクト、「S」と「L」があったとする。プロジェクト「S」は、一年目に５０万ドル、二年目に４０万ドル、三年目に３０万ドル、四年目に１０万ドルのキャッシュフロー（＝会社に入ってくるお金）を生み出すが、プロジェクト「L」は、一年目に１０万ドル、二年目に２０万ドル、三年目に３０万ドル、４年目に６０万ドルのキャッシュフローを生み出す。 それぞれのプロジェクトに１００万ドルの資金が必要で、調達した資金には１０％の利息がかかると仮定したとき、会社としてはどちらのプロジェクトを選ぶべきか、というのが今回の課題である。 「投資した資金を回収するのにどのくらいの期
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く