先日の「node.js と thread hog の話」には、たくさんのコメントをいただいたが、やはり「イベント駆動型」のプログラミングには抵抗がある人も多いようだ。そこで、JavaScript の無名関数を使ったイベント駆動型のプログラミングの可読性が悪くないことを示すために、「朝７時に目覚まし時計をかけて眠りにつき、朝ご飯を食べ終わったら会社に行く」という典型的な「サラリーマンの朝」をイベント駆動型のJavaScriptで記述してみた。 注目して欲しいのは、素早く出来る「着替える」「顔を洗う」などの動作は割り込み不可な動作なので、通常のプログラミングと同じようにシーケンシャルに実行するが、時間のかかる「朝ご飯を食べる」「駅まで歩く」などの動作は割り込み可能な状態で実行し、"complete" のイベントを受けてから次の動作に移る点だ。 ちなみに、目覚まし時計は 「スヌーズボタン」付きな

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

日本でスパコン産業支援のための予算が事業仕分けで見送りになった件については、Twitterとかでつぶやいても来たが、そろそろ「産業支援のありかた」を根本的に見直すべき時が来ていると思う。特にIT産業においては、勝負すべきレイヤーが大幅に変化している時期でもあり、過去の産業構造に捕われた支援の仕方をしても税金が無駄になるだけ。 特に今朝米国で報道された「なぜ米国空軍がPS3を2200台を追加発注したのか」という記事は、この業界の変化を顕著に表すもの。要約すると、 1. 米国空軍はさまざまなシミュレーション（空軍なので、弾道ミサイル、迎撃ミサイル、戦闘機の性能シミュレーションと考えられる）にスパコンを使って来ているが、現時点では、（IntelのチップやGPUよりも）CELLチップで構成したスパコンがもっとも現実的である。 2. ただ、CELLチップを二つ搭載したサーバー(1チップあたり200G

もともとは携帯電話向けに提供されていたGoogleのandroidが、それ以外の組み込み機器向けのOSとして注目されている。私なりの見解もそれなりにあるのだが、勘違いしている部分もあるかも知れないので、確認のためにも私の見方をぽろぽろとTwitterでつぶやいてみたので、ぜひともフィードバックをいただきたい（Twitter、このブログのコメント欄やトラックバック、はてぶ、のいずれでも結構）。以下がつぶやきの内容。 androidが携帯だけでなく組み込み機器一般で注目されている背景には、「要求される機能が肥大化し開発費が膨大になり、機種ごとにOSから組み上げるのがコスト的に見合わなって来た」というのがある（リンク）。 それに加えて、GUIやマルチタスクなどの要求に対し、従来の組み込みOS（μiTron・VxWorksなど）が答えられなかったという状況もある（リンク）。 その答えの一つとして浮

本日、Big Canvasとしては６本目となるアプリケーション、PhotoCanvasをリリースした。去年の７月にPhotoShareをリリースして以来、PhotoShareのアドオン的な存在のアプリを４本リリースしてきたわけだが、それを通じて学んださまざまなことの集大成が今回のPhotoCanvas。 カテゴリーとしては、SmallCanvas、PhotoArtistなどと同じく「写真加工アプリ」だが、ポジショニングとしては、PhotoShareとならぶ会社の「看板アプリ」として本気で「iPhone向けのPhotoShop」の座を取りに行こうという試みだ。 私が「iPhone向けのPhotoShop」の話をすると、ほとんどの人から「それはいくら何でも無理でしょう」という反応が返って来る。その思考プロセスには「iPhone上でパソコン上のPhotoShopと同じ機能を提供することは技術的に

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

MacBlogzにPhotoShare by Big Canvasという解説ビデオが公開されていることを発見。PhotoShareの基本機能を分かりやすく解説しており、そこに関しては僕らが作ったプロモーション・ビデオよりも良く出来ているかも。 いずれにせよ、こういうものを作ってもらえるのはとても喜ばしい。やはり、オープン当日に間に合わせたことには意味があったのか、と。

iPhone OS 2.0のリリースに先駆けて、App Storeがついにオープンした。待ちに待ったBig Canvas最初のアプリ、PhotoShareの世界に向けたリリースだ。PhotoShareはその名前の通り「写真共有アプリ」。iPhoneで撮影した写真を友達や家族と共有することにより、「経験の共有」をしようというコミュニケーション・ツールだ。 PhotoShareの特徴はとにかく使いやすいこと。Flickr、Facebook、MySpace などの既存のSNS向けの専用iPhoneアプリがたくさん出てくることは当然予想できた（そして実際出て来た）。それにも関わらず、PhotoShareを独自のウェブ・サービスとあわせて開発をしたのは、「iPhoneに最適化されたおもてなし」を提供するため。ユーザー登録が不要なところ、すべての通信が非同期で行われること、友達や家族の招待がとても簡単

先日のRails Conference 2008に関するレポートでも書いたが、米国のオープン系の開発者の間でのMacへのシフトが急速に進んでいる。たまにWindowsマシンを持っている人がいても、そんな人たちは口を揃えたように「うちの会社は.Netの案件もあるので、Macは買わせてもらえないんですよ」と本当は彼らもMacに切り替えたいことを告白する。 いろいろな事情・環境がからみあってこうなっているのだが、簡単にまとめると、そもそも、 アップル製品に対する昔からある漠然としたあこがれ ９０年代にソフトウェア業界の富を独り占めにしたマイクロソフトに対する恨み iPodの成功で一躍元気を取り戻したアップルという企業自身の魅力の上昇 という潜在需要があったところに、 意味もなく重くなっただけのVistaに比べて完成度の高いOS-X Unix系OSをカーネルに持つが故に整った開発環境 バーチャルマ

学ぶ時には「原典」に当たる たとえば、PerlであればCGI本とかではなく、ラクダ本に当たる、というのがこれの意味するところです。もちろんCならK&R。なぜ原典でなければならないか。それは、原典には、その言語の設計者の意図が書かれているからです。それで、その言語は何が得意で何が不得意なのかもわかる。結果的に易しく「こうやれば出来る」が書いた本よりも、「こういう人向けに作りました」がわかる原典の方が優しいのです。 【404 Blog Not Found:私の言語遅延学習法 - 三つのルール+1より引用】 これを読んで思い出したのが、学生時代に勉強に関して思ったこと。公式とか法則とかをを覚えるのが不得意だった上に、「これはこういう決まりだから覚えておきなさい」と先生から頭ごなしに言われるのが嫌いだった私は、一度理解しようとしたことは自分が納得できるまで（つまり、自分で公式や法則を導けるようにな

Apparently, it is a fake. But you just have to think how much effort has been put to make this trailer. Impressive!

University Washington で Executive MBA のコースを受けることにした理由の一つは、成功する企業とそうでない企業を分ける要因を私なりにちゃんと理解したかったからである。 Microsoft 時代に Bill Gates の下で働くことにより、業界の流れを読んだり、それに基づいた企業戦略を立てることに関しては、それほど不自由を感じなくなった。しかし、いざ自分で起業をしてみて強く感じたのは、企業戦略を立てることは「初めの一歩」でしかなく、その戦略に基づいてちゃんと利益を生み出す組織を作りあげる方がその何倍も何十倍も難しいということ。 色々と反省する点はあるのだが、あえて一番反省している部分を上げるのであれば、会社のカルチャー作りに十分な注意を払って来なかったこと。戦略に関わる mission statement や vision に関しては常にはっきりと語り続け

404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で