Life is beautiful

フィードバックありがとうございます。上にも書きましたが、Adobe Ideasのように一度「折れ線」で描いてから、あとでスムージングした方が好きというユーザーの方もいることは分かりますが、このトレード・オフは難しいところです。私も最初はAdobe Ideaの手法は面白いと感じていましたが、長く使っているとどうも好きになれなくて、描きながら同時にスムージングをかけるようにしてあります。このあたりは、皆さんのフィードバックを聞きながら微調整をして行きたいと思いますので、よろしくお願いします。

◇　◇　◇

また、これから投稿されるフィードバックにも必ず目を通すので、コメント・ご要望のある方はぜひとも、iTunesもしくはこのブログへのコメントをお願いする。特に気に入ってお使いいただている方には、とても励みになるので、iTunesストアでの４つ星なり５つ星をいただけるとありがたい。

ちなみに、iPad版のneu.Notesは初速でのダウンロード数は爆発的だったが、少し後に地味にリリースしたiPhone版がじりじりと追い上げ、今では日々のダウンロード数はiPhone版の方がはるかに多い。iPhoneの母数が多いというのもあるだろうが、「ちょっとしたメモを書く」「写真に何か書いて送る」などのユーザー・シナリオ的にはiPhone版の方がマッチしているのだと解釈している。

先日iPad向けにリリースした「加速する創作系マガジン『暫』」、とても好評で発売３日目には書籍部門で１位、４日目には総合で２位（瞬間風速では一時的に１位）という快挙。

「どのくらいダウンロードがあるとランキングの上位に食い込めるのか」という質問を良く受けるので、発売後８日間のダウンロード数と、（日本での）総合順位をグラフにしてみたのがこれ。

グラフの一番右下が初日の結果で（２４８ダウンロード／総合６５位）、ダウンロード数が急速に伸びるとともに順位も上がり、４日目のピークで、２７８１ダウンロード／総合２位に達している。

アップルがどのくらいの期間のダウンロード数を目安にランキングを決めているかが不明なので、このグラフが１００％正しいとは言えないが、大体の感覚はつかんでいただけると思う。重要なことは、このグラフが直線ではなく、大きくカーブしていること。

これは無料アプリのカーブだが、当然有料アプリも同じようなカーブを描く。「ランキングの上位に入れば儲かるが、そうでなければ開発費の回収もままならない」というアプリストアのRed Ocean状態を良く表している。

ところで、iTunesストアでのランキングは、国別のもの。上の数字は日本でのもので、母数がはるかに多い米国だとランキング上位に食い込むのに必要なダウンロード数もそれに比例して多い。

ちなみに、CloudReadersのダウンロード数を見ていると、中国でのダウンロード数が急激に増えており、日本や米国からのダウンロード数を超えている。それだけでも面白いのだが、もっと興味深いのはダウンロード数の割には総合ランキングが日本よりも低いこと。その数字だけを見る限り、「中国でのiPad販売数の方が日本より多い」ように見えるのだが、実際のところはどうなんだろうか。

CloudReadersベースの電子書籍は既に何冊かiTunesストアに出ているが、高画質のマガジンはこの「暫」が初（iTunesストアへのリンク）。値段は無料。iPad専用。

ちゃんとしたフォーマット（ZIP化したJPEGファイル）で作ったマンガや雑誌をCloudReadersで読むとどのくらいサクサク読めるのかが実感できるので、ぜひともお試しいただきたい。

ちなみに、この雑誌に関しては、ホームページがあるので、興味のある方、作家として参加したい方、広告を出向したい方などはそちらへどうぞ。

電子書籍に関るアプローチは色々とあるが、その中でもあくまでクリエーターが主人公であるというアプローチがとてもユニークだと思う。その意味でも色々な可能性を持っていると思うので、ぜひとも応援をお願いしたい。

雑誌 WEB-DB PRESSに連載中のコラムの記事がまた一つウェブで読める様になったので、紹介させていただく。

オブジェクト指向の本質

そもそも、単身赴任中の私が主に家族通信のために書いていたブログがこんな形のブログに変わったのは、何気なく書いた「日本語とオブジェクト指向」というエントリーがきっかけ。突然「はてなブックマーク」という不思議なサイトからのトラフィックが増え、「ブログを書く楽しさ」を教えてくれたエントリーだ。

いまさら「オブジェクト指向の本質」もなにもないとは思う人もいるだろうが、実際に現場で働いているエンジニアの中にも「オブジェクト指向プログラミング＝クラスを使ってプログラムを書く事」と勘違いしている人もたくさんいるわけで、そんな人たちにぜひとも読んで欲しいと思って書いたエントリー。

そうは言っても、「粗結合」の大切さみたいなものは、何度も何度も（スパゲッティ・コードに）痛いめに合ってこそ「身につく」もので、こういう記事を読んだからと言って、すぐに実行できるほど簡単な話ではない。

ということで、今回はざっと目を通しておいていただいて、次にスパゲッティ・コードに悩まされた時に、「そう言えば、スパゲッティ・コードが出来る原因について書いた記事を読んだ覚えがあるな」と思い出していただけるだけで十分だと思う。

ここのところ、サーバー側（Google App Engine）のコードはPythonで書き、クライアント側のコードはiPhone/iPad 向けはObjective-Cで、ブラウザー向けはJavaScriptで書く、という毎日が続いている私である。

それぞれの言語は難しくないのだが、さすがにこの３つを頻繁に行き来していると、pythonのコードに間違ってセミコロンを付けてしまったり、PythonとJavaScriptのどっちがTrueでどっちがtrueだか混乱したりする。

ちょうど昨日は、以前JavaScriptで書いたコード（写真をアップロードするコード）をObjective-Cに移植する機会があったのだが、とても分かりやすい結果が出たので、ここで比較してみる。

まずは元の JavaScript のコード。

            SNBinder.get("/blob/create_upload", {}, true, function(json) {

                SNBinder.get("/static/page_upload.htm", {}, false, function(htm) {
                    htm = SNBinder.bind(htm, { upload_url:json.upload_url });
                    $('#main').html(htm);
                    $('#form_upload').bind('submit', function() {
                        $('#wait_cursor').show();
                    });
                });
            });

-(IBAction) pickPhoto:(UIButton*)btn {
    UIImagePickerController* picker = [[[UIImagePickerController alloc] init] autorelease];

    picker.delegate = self;
    picker.sourceType = UIImagePickerControllerSourceTypePhotoLibrary;
    [self.popover dismissPopoverAnimated:false];
    self.popover = [[[UIPopoverController alloc]
        initWithContentViewController:picker] autorelease];
 
    [self.popover presentPopoverFromRect:btn.bounds inView:btn 
            permittedArrowDirections:UIPopoverArrowDirectionAny animated:YES];
}
 
// <UIImagePickerControllerDelegate> method
- (void)imagePickerController:(UIImagePickerController *)picker  didFinishPickingMediaWithInfo:(NSDictionary *)info {
    viewImage.image = [info valueForKey:UIImagePickerControllerOriginalImage];
    [self.popover dismissPopoverAnimated:true];
}
 
-(IBAction) uploadPhoto:(UIButton*)sender {
    self.uploader = [NBUploader uploaderWithSession:sessionManager.session 
        data:UIImageJPEGRepresentation(viewImage.image, 0.8) type:@"image/jpeg" name:textField.text 
            description:textDesc.text uuid:textUUID.text];
 
    NSNotificationCenter* center = [NSNotificationCenter defaultCenter];
    [center addObserver:self selector:@selector(uploadComplete:) 
                name:[NBLoader didFinishLoadingNotification] object:self.uploader];
    [self.uploader connect];
    labelURL.text = @"uploading...";
}
 
-(void) uploadComplete:(NSNotification*) notification {
    [[NSNotificationCenter defaultCenter] removeObserver:self];
}

この差は大きい。どちらもプログラムを書く手間そのものはデバッグの時間を含めればそれほど大きな違いは無いのだが、私自身が数ヶ月後にこのコードを見た時に（もしくは他の人がコードを見た時に）、何をしているのかが一目瞭然と分かるのはJavaScriptの方だけだ。Objective Cの方は、少し腰を落ちつけてコードの解析をしなければ、非同期通信の流れが把握できない。これをもし、JavaScriptと同じように３回もの非同期通信をするコードをObjective Cで書いたら、それはそれは読みにくいコードになる。

こと非同期通信に関しては、JavaScriptの方が圧倒的にすぐれている、ということが分かっていただけるとと思う。何と言っても大きいのは無名関数で非同期通信のコールバックがその場に記述できてしまうこと。

ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。

App Engine は純粋なソフトウェア・エンジニアにとっての天国

私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。

新しい言語を学ぶのが苦ならApp Engineは避けた方が良い

現時点で、PythonとJavaのみがサポートされているが、App EngineをやるならPythonがおすすめ。私もPythonはApp Engineが初めてだが、とても簡単な言語なのでそれほど苦労せずに使いこなせるようになる。「今さら新しい言語を勉強するのは辛い」とか「RubyかPHPが動くならApp Engineを試してみたい」と考えるような人はApp Engineには手を出さない方が良い。Pythonの習得を苦労しているようでは、Big Tableは使いこなせない（というか、そもそも新しい言語の習得を「楽しい」と感じないならば、ソフトウェア・エンジニアという職に向いていないと）。

フレームワークに頼るな

上に述べたように、App Engineの一番の魅力は、実行効率を直感的に意識してプログラミングできる（もしくは、それを強いられる）ことにある。なので、できるだけサードパーティのフレームワークや巨大なライブラリは避け、必要最低限のコードだけをGoogleが提供している最低限のフレームワーク上にサクッと作るべき。もし、Googleが提供しているフレームワークが難しいと感じたり、不十分と思うのであれば、App Engineは避けた方が良い。私自身、最初はいくつかサードパーティのフレームワークを試してみたが、すべてのソースコードを読まなければ気が済まないし、読むと気に入らないところがたくさん出て来る。で、結局は自分なりの最低限のライブラリ集を作ってそれを再利用してアプリを作る、というのが効率面でも品質面でも一番良いとの結論だ（gdispatchはその副産物）。

Data Modelはできるだけフラットに、かつシンプルに

このあたりが、RDBに慣れた人たちには一番取っ付きにくい部分かもしれないが、Big Table上でのData ModelはRDB上のものとは大きくことなることを理解すべき。私は現在、ファイルの共有サービスをApp Engineで作っているが、ModelはUserとBlobStoreの二つしかない。RDB上に作れば２０個ぐらいのテーブルになりそうな複雑な処理をしているのだが、App Engine上ではたった二つである。「App Engine上ではJoinが出来ないから」という声を良く聞くが、そんな泣き事を言う前に、そもそもJoinが必要になるようなモデル設計（つまりBigtable向きでない設計）をしてしまっていないかを確認すべきである。

GQLはまやかしである

Googleは、App Engine上のQueryを記述するための言語としてGQLという言語を用意しているが、これはSQLに慣れた人に「App EngineにはGQLがあるから怖くない」と誤解させるための、まやかしである。本気でApp Engine上でプログラムを書くのであれば、GQLは使うべきではない。

Task Queueを使いこなせ

Big Tableの一つの大きな特徴は、ReadとWriteの非対称性である（Writeが何倍も遅い）。それゆえに、ループを回して連続でWriteをすのは得策ではない。そこで便利なのがTask Queue。Task Queueを活用したサーバー側での非同期プログラミングができるようになったあたりから、App Engine上でのプログラミングの自由度が大きく広がる。

テンプレートの処理はできるだけクライアントにさせろ

ガラケー向けのサイトでも作っているのならば仕方がないが、パソコン上のブラウザー向けのサービスを作っているのなら、テンプレート処理はクライアント側に処理させるのが得策。つまり、HTML/JS/CSSファイルに加え、HTMLのテンプレートファイルもすべてstaticファイルとしてクライアント側にダウンロードし、JavaScriptからApp EngineのModel APIを直接叩いてJSONの形で結果を受け取り、それをクライアント側でHTMLテンプレートと結合して表示する。つまり、Model/View/ControllerのModelをApp Engine上でPythonで書き、ViewはHTMLテンプレートも含めてすべてstaticファイルとして提供し、ControllerをJavaScriptで記述するのだ。こうすることにより、App Engine側での処理を極力軽くし、かつ、ユーザーにとっては見かけの待ち時間が少ないおもてなしを提供できる。

何と言っても「プログラミングに集中できる」のがApp Engineの醍醐味

そして、私にとってApp Engineの一番の魅力が、サーバーの台数を調整したり、ロードバランスをしたり、データベースのパーティションを気にしたりなどの「サーバーの構築・運営」などの雑務から解放されること。すでに、App Engine上で三つほどサービスを運営しているが、どれも一度走り出してしまえば基本的には「メンテナンス・フリー」になるところがすばらしい。何ヶ月か前にリリースしたTinyMsgも、発言する人や内容によって時々トラフィックが急増するのだが、そのあたりをキチンとハンドリングしてくれるのでとても助かる。

最大の欠点はGoogleにLock-inされてしまうこと

これに関してはあまり解説する必要もないとは思うが、App Engine上にサービスを作るということは、すなわち「Googleのインフラ上でサービスを提供することにコミットする」ことなることは覚悟して進めるべきである。「コンパチブルなオープンソースのプロジェクト」もあるにはあるが、それをサービスとしてGoogleほどの規模とコストで提供するところが現れるまでは（そう簡単には現れないと思うが）、Google が唯一の選択肢である。

長くなってしまったが、以上が私がApp Engineに関して感じていることのまとめだ。確かに「敷居は少々高い」が、一度その敷居を乗り越えてしまうと何とも心地よいプログラミング環境が整っているというのが実情である。その壁を乗り越えるのを「楽しい」と感じるのであれば、かつ、GoogleにLock-inされても良いと考えるのであれば、App Engineはとても良い選択肢だと思う。

iPad版のkoukouTVの紹介の際に、「本当の狙いはテレビ、セットトップボックス、車載機メーカーへのOEMビジネス」と書いたが、その第一弾がこれ。詳しくは、Coviaの製品ページを見ていただくのが一番良いと思うが、例の「実家に孫（の写真）を贈ろう」というコンセプトの元に作られたkoukouTVを搭載した地デジチューナーだ。

ちなみに、私がUIEvolutionを設立したのはちょうど１０年前。「これからは携帯電話に限らず、テレビ・カーナビ・冷蔵庫のドア・クレジットカードなどがネットに常時接続する時代になる。そんな時代に向けたソフトウェアとサービスを提供する会社」というビジョンで作った会社だが、１０年たった今でもようやくテレビとカーナビがネットに接続しはじめたばかりだ。冷蔵庫のドアやクレジットカードが常時接続しはじめるまでまだまだやることがありそうだ。

ということで、koukouTVのOEMライセンスは、テレビやカーナビに限った話ではなく、もちろん冷蔵庫のドアにも喜んで提供するので、そこのところよろしく（OEMビジネスに関しては、こちらを参照していただきたい）。

先日、日本から帰国する際に、持って行った Mac Book 二台のうち一台を間違ってボストンバッグ（それもソフトタイプ）の外ポケットに突っ込んだままチェック・インしてしまうという失敗をしてしまった。一度荷物室に積み込まれてしまってのだが、飛行機に乗り込んだ後ですぐに回収をし、かろうじて破損は免れたのだが、その後１週間ほどで充電が不可能になってしまった。

しかたがないので、近所のアップル・ストアのGenius Barに持って行くと、保証期間だということで無償で修理してくれることになった。「水没とかしていた場合、保証がきかなくなりますが」というジニアス・バーの店員に「水没はしていません」と強調してしまった私。「ボストンバッグに入れたままチェックインとかしていませんよね」と聞かれれば正直に答えたのに...＾＾；

ちなみに、最近は iPhone や iPad ばかり注目されているが、それと同時に MacBook を持つユーザーが回りに増えたというのがここ（シアトル）での実感。そのシェア拡大に大きな役割を果たしているのがこのGenius Barである。

まず何と言ってもすばらしいのは、「ネットで予約が出来る上に、保証期間でなくても、その場で直せるものはすぐに直してくれる」点。「買った時のレシートとか、保証書の提示」とかも全く不要なのも良い。以前も、保証期間が過ぎた古いMacBookにOS-Xの再インストールをしてもらったことがあるのだが（無償で、それも１０分ぐらいで）、そのレベルのサービスを提供してくれるところは他にない。

もう一つすばらしいのは、保証期間内のiPhoneとかiPadにハード的な問題が出た場合、（水没でないかぎり）その場で無償で全交換してくれること。先日も、Apple TVのビデオ出力に妙なノイズが出るので持って行ったところ、その場でサクッと交換してくれた（ノイズの原因は、実はApple TVとテレビの間のレシーバーにあったことが後で判明したのだが、いまさら「この前のノイズの件は私の勘違いでした」とは持って返っても逆に迷惑だろうからそのままにしてある）。

当初は誰もが「いまさら小売店を持つなんて」と否定的に見ていたアップル・ストア、ゆっくりとだが着実に「アップル・ファン」の数を増やすことに貢献していることは今や誰も否定できない。

ちなみに、私のなじみのアップル・ストアのすぐ近所に、まもなくマイクロソフト・ストアがオープンする。単なるショー・ルームではなく、Genius Barに匹敵するようなサービスを提供してくれるのか、楽しみである。３年前に買って放置してあるToshibaのノートパソコンを持って行って、「ハードディスクを一度まっさらにして、Windows XPを再インストールしてくれない？ディスクも保証書もなくしちゃったけど」と頼んだらやってくれるだろうか？