Previous month:
January 2011
Next month:
March 2011

CloudReaders 1.20 は P2Pファイル転送機能を搭載(iPhoneにも対応)

今回のCloudReadersのアップデートの目玉は、「iPhone/iPod touch対応」と「P2Pファイル転送機能」。前者に関しては後述するが、後者は「手持ちのPDFファイルやZIP化した自炊書籍をiPad/iPhone間でパソコンを介せずに直接交換できる」という仕組みだ(P2P=Peer to Peer, パソコンやサーバーを介さずデバイス間で直接通信をすること)。

P2Pファイル転送機能

ちなみに、いままで無料で提供してきたCloudReadersだが、この「P2Pファイル転送機能」に限ってアプリ内課金の仕組みを使って有料で提供することにした。価格は最終的には$3.99-$4.99ぐらいにする予定だが、広く普及させることを考えて、まずは $0.99(日本だと115円)という割引価格でスタートすることにした。(このブログの読者のような)アーリーアダプターの人たちの間で使っていただいてその便利さを実感してもらおうという期間限定の価格設定なので、ぜひともお早めにお試しいただきたい。

使い方だが、まずはホーム画面(My BookShelf)で下のツールバーのBluetoothアイコンをタップする。未購入の場合は、「購入が必要です」と簡単な説明と価格の書いてあるボタンが表示されるので、このボタンをタップすると購入確認のプロセスが始まる。

Drawing-3Screenshot 2011.02.22 12.42.26Screenshot 2011.02.22 12.43.25

アドオン機能の購入が完了すると、右上の"Connect"ボタンが使えるようになるので、これをタップする。すると、iOS 標準のBluetooth接続のためのUIが表示されるので、相手を見つけて接続を完了する(当然、接続相手も同じ操作をしておく必要がある)。

接続を完了した後は、送信側のデバイスで上部ツールバーの "Send" ボタンをタップし、リストから送信したいファイルを選ぶと転送がスタートする。

転送時間はファイルの大きさや通信状態によるが、ベクター化されたPDFファイルなら数秒、自炊した書籍だと数分かかる(実測値だと、50MBのファイルで6〜7分)。Bluetoothを使っているので、WiFiも3Gもパソコンも不要。3G電波の届かない地下鉄の車内とかでも使える。

iPhone/iPod touch対応

CloudReadersをiPhone/iPod touchで動く様にして欲しいというリクエストは以前から受けていたのだが、なかなか思ったような読み心地が実現できないのでしばらく保留にしておいた。しかし、retina displayを積んだiPod touchも出たことだし、そろそろサポートすべきと思い、本腰を入れて「小さな画面でもマンガを読みやすい」を実現するために色々な工夫をしてみた。大きくは、

・iPhone/iPod touchを横にしてズームしてマンガを読む時の読み心地の改善。これはいくつかの細かな微調整の組み合わせだが、「自炊したマンガのページをそのまま縦に表示をしても文字が小さすぎるが、横にしてズームして読むとページ送りが面倒」という問題を解決するためのもの。なかなな文章では説明しにくいが、実際に試していただければ分かると思う。

・retina displayを持たないiPhone/iPod touch向けのスムージング。retina displayを持たない世代のiPhone/iPod touchでマンガを読むとどうしても画像がきたなくなるのを解決するため、スムージングにより擬似的に解像度を上げる工夫をしている。ただ、その分スピードは遅くなるので、設定アプリからSmoothingを0以外の数字にした時のみかける様にしている。

・ロテーションのロック。これは、ソファーに横になって読む時などに必須の機能。ツールバー上部のロックボタンをタップすることにより、ロックの設定・解除をすることができる。

の3点であるが、他にもこまごまと微調整がしてあるので、ぜひともお試しいただきたい。


デジタルでは補いきれないCDの売り上げの急速な落ち込み

何となく肌では感じていても、実際の数字とグラフで見せつけられると「ここまでひどかったかと驚愕することがあるが、ここで見た下の図がまさにそれ。CDの売り上げがiTunesなどのデジタル・ミュージックでは補うことができない速度で急行下していることが良く分かる。

米国で暮らしている身としては、音楽に関してはPandora、映画に関してはNetflix、の提供するストリーミング・サービスで十分で(ちなみに、Pandoraは法律ぎりぎりのところで「ストリーミング・サービス」ではなく、「インターネット・ラジオ」だそうだが、それは単なる方便)、CDやDVDどころかデジタル・コピーすら自分で持つ必要がなくなりつつあるというのが実感。「PandoraやNetflixはただのりしているだけ」という声が、コンテンツ側からも通信事業側からも聞こえてくるのも分かる。いずれにせよ、この状況はサステイナブルとは全く言えない状況で、今後どう展開して行くかを読むのは非情に難しい。

Global-Music-Industry


Nokia+Microsoftパートナーシップは、「3強3OS時代」の幕開けか

おおかたの予想通り、NokiaはGoogleではなくMicrosoftをパートナーとして選んだ(参照)。簡単に解説すると、

  1. NokiaはWindows Phone7をNokiaのスマートフォンの唯一無二のプラットフォームとして選択する
  2. NokiaはMicrosoftのBingサーチエンジンとadCenterを全面的に採用する
  3. 低価格端末にはSymbianを使いつづけるが、これ以上のSymbianへの開発投資は行わない
  4. 開発中のMeeGoベースの機種は一応は出すが、これはWindows Phone7への「中継ぎ」でしかない
  5. 携帯電話、スマートデバイスを作っている部門を別々のビネスユニットとする(スピンアウトではなし)
  6. ソフトウェア(Symbian + MeeGo)の開発部門を大幅にカットする
  7. NokiaはMicrosoftにソフトウェアのライセンスフィーを払うことになるため粗利益率は下がる
  8. MicrosoftはNokiaの携帯電話を売るためのマーケティングに大量のお金を使う

となる。

ここまで追い込まれてはこれぐらいの「英断」が必要なのだが、注目すべきは5と6。従来型の携帯電話部門とスマートフォンやタブレットを作る部門を別々の事業部として独立させ、同時にWindows Phone7を採用することにより不必要になるソフトウェア人員をカットするということは、ノキア本体側の経営陣としては(1)事業部のアジアメーカーへの売却、(2)ソニエリなどとの合併、(3)スマートデバイス事業部のスピンアウトとそこへのMicrosoftからの資金注入、などのシナリオを考えていると予想できる。

Microsoft としても、今の劣勢を挽回するには強力なパートナーが必要で、「どのOSでもとりあえず採用するSamsung」よりは、「土俵際に追いつめられたNokia」の方が組みやすかったのだろうと予想できる。

こうなると興味深いのはNokiaと同じ様に追いつめられたソニエリの動向。ひょっとすると、今回のNokiaからのスピンアウト会社とソニエリが合併し、そこにMicrosoftが大量な資金を注入して大株主となり、最終的には Apple(iOS)、Samsung(Android)、ソニエリノキアマイクロソフト(Windows)という3強3OS時代が来るのかも知れない。

【追記】ちなみに、このエントリーを書いてからTwitterでNokiaのキーワードでサーチをしたところ最初に見つかったものが、Googleの採用担当が書いたこれ。

 

aidanbiggins Aidan Biggins 
Any Nokia software engineers need a job? We're hiring: www.google.com/jobs

 

こんな時は、まず優秀なエンジニアから先に辞めて行くのが常なので、Googleの採用担当としてはチャンス到来というわけだ。


1つめの封筒を開けたStephen Elop (CEO of Nokia)

こちら(米国)の携帯業界での今日の一番のニュースは、NokiaのCEOのStephen Elopの書いたメモ。全文がこちらに掲載されている。Nokiaの置かれている状況は、規模こそちがうが日本のガラケー・メーカーの置かれている立場ととても良く似ている。

Symbian Series 60を搭載したNokiaのケータイは、一応「スマートフォン」のカテゴリーには入れてもらえてはいるが、実際のところは日本のガラケー以下のものでしかない。利益率の高いハイエンド市場を完全にAppleに持って行かれ(300ドル以上のケータイの61%がiPhone)、Nokiaにとって稼ぎ頭だった低価格ケータイはいまや誰にでも作れる時代になってしまった。

Stephen Elopのメモで一番印象に残ったのは、この部分、

At the lower-end price range, Chinese OEMs are cranking out a device much faster than, as one Nokia employee said only partially in jest, “the time that it takes us to polish a PowerPoint presentation.”

低価格帯では、中国勢がものすごい勢いでデバイスを次々に開発している。Nokiaの従業員の一人が冗談混じりに言ったとおり「Nokia社内でパワポのプレゼン資料を作るのと同じぐらいのスピードで」新機種を作って来る。

日本であれば「稟議書に判子を押している間に」と言った方が分かりやすいかも知れないが。

ちなみに、このエントリーのタイトルは以下のようなジョークから来ている(オリジナルはこちら)。

3つの封筒

ある人が某ハイテク企業のCEOに就任したのだが、引き継ぎの際に前CEOが3つの封筒を渡しながらこう言った「もしどうしても解決できない難関にぶつかった時にはこれを開けなさい」。

就任後、しばらくは業績も良かったのだが、6ヶ月目から売り上げも急速に落ち、株価も下がり始める。新CEOは窮地に立たされた。藁をもつかむような気持ちで1つめの封筒を開けると、こう書いてある「前任者のせいにしろ」。

そこで、新CEOは記者会見を開き、売り上げの低迷は前CEO時代からの戦略の誤りにあり、それを解決するのが自分の仕事だと宣言する。ウォールストリートはそれを好材料として取り上げ、株価は再び上昇に転じる。

1年ほど立つと、再び売り上げが落ち、不良品も出るという状況に陥る。そこで二つ目の封筒を開けると「組織替えをしろ」と書いてある。そこで、大きな組織替えをし、会社の業績は見事に回復する。

しかし、しばらくするとまた会社の業績が落ち始める。やむなく最後の封筒を開けると、こう書いてある。

「3つの封筒を用意しろ」


SNBinder入門:一行おきに背景色を変えるテクニック

ピュアAjaxアーキテクチャ」なウェブサイトを実現するために作ったSNBinder、多くの方々からフィードバックをいただけ、私もとても良い勉強になっている。そんなフィードバックの中に、「テンプレート内で条件分岐ができるようにして欲しい」「テンプレート内にスクリプトが書ける様にして欲しい」などのリクエストをたびたび見かけるので、今日はそれに関してひと言。

たしかに、従来型のテンプレートのほとんどに「繰り返し」や「条件分岐」の機能がある。ものによっては、そのテンプレート中にスクリプトが書けてしまうものもある。SNBinderにそんな機能を追加するのもけっして難しくないのだが、私がSNBinderで実現しようとしている方向性とは少し違う、と感じている。

そもそもテンプレートとは、JavaとかPythonなどで記述された「ロジック(もしくはコントローラ)」と、ユーザーに何を見せるかというHTML(ビュー)を切り離すことにより、メンテナンスをしやすくしようという試みである。

しかし、それを「特定のURLにリクエストが来ると、サーバー側でHTMLページを生成して返す」という従来型のアーキテクチャにはめ込もうとすると、どうしてもテンプレート側に「繰り返し」や「条件分岐」の機能を追加せざるをえない。返すべきページを一つのテンプレートで表現し、その中に「リスト」を表示したり、特定の条件に応じて何かを表示する必要があるからだ。ロジックとビューを切り離すという発想から言えば本末転倒とも言えるが、ウェブのアーキテクチャ上しかたがないという面もあり広く用いられているテクニックだ。

SNBinderが前提にしている「ピュアAjaxアーキテクチャ」は、従来型のものとは大きく異なるアーキテクチャである。ブラウザーが最初にHTTP-GETで取得するHTMLページは静的ファイルであり、そこにJavaScriptでページを作るのに必要な部品を「名前付きテンプレートの集まり」としてを読み込み、サーバーのAPIを叩いてJSONを取得した上で、その取得したJSONと名前付きテンプレートの一つ(=部品)を結合(Bind)した上で、HTMLページの適切な場所にペタペタと「貼付ける」のだ。

この場合には当然だが、すでにさまざまなロジックをJavaScriptで記述しているわけで、「繰り返し」や「条件分岐」もJavaScriptでするのが自然であり、そうすることによってロジックとビューをきれいに切り離したままに保つことができる。

説明のために少し具体例を示そう。

「繰り返し」に関しては、bind_rowsetというヘルパー関数をもうけており、

            $('ul#completed_todos').html(SNBinder.bind_rowset(s_parts['todo_item'],json)); 

のような書き方が可能だが、これは

            var func = SNBinder.compile(s_parts['todo_item']);
            var rows = []; 
            for (var index in json) {
                rows.push(func(json[index], index));
            }
            $('ul#completed_todos').html(rows.join(''));

と同値である。

例えば、リストを表示する際に、1行おきに背景色を変えたい場合などは、偶数行・奇数行向けのテンプレートを二つ用意しておき、

            var func_even = SNBinder.compile(s_parts['todo_item_even']);
            var func_odd = SNBinder.compile(s_parts['todo_item_odd']);
            var rows = []; 
            for (var index in json) {
                if (index % 2==0) {
                    rows.push(func_even(json[index], index));
                } else {
                    rows.push(func_odd(json[index], index));
                }
            }
           $('ul#completed_todos').html(rows.join(''));

とすれば良い。JSONを変更してかまわないのであれば、

           for (var index in json) {
               json.css_class = (index % 2 ==0) ? 'even' : 'odd';
           }
           $('ul#completed_todos').html(SNBinder.bind_rowset(s_parts['todo_item'],json)); 

のようにあらかじめcss_classというプロパティを各行のデータに持たせておき、それをテンプレートで展開するという手法もある(Fruenceはこの手法を使っている)。

なぜこんなことが可能になるかというと、SNBinderであつかうテンプレートが「ページ全体を表したもの」ではなく、「データと結合した上でHTMLページに貼付けるべき部品」だからである。サーバー側でのテンプレートに慣れた人には少し発想の転換をしていただく必要があるが、その発想の転換さえしていただければ、SNBinderのテンプレートには「繰り返し」や「条件分岐」が必要ない、ことが理解していただけると思う。


日本が取るべき「ガラパゴス戦略」

Techcrunchに「ComScore Says You Don’t Got Mail: Web Email Usage Declines, 59% Among Teens!」という記事が出ている。要約すれば、「若い人たちほど旧来型のメールは使わなくなっており、SMS(携帯メール)やIM(メッセンジャー)やFacebookなどの新しい形のコミュニケーションを使う」という話。

日本の「ケータイ文化」やmixiの(初期の)成功を見て来た私としては「何をいまさら」という感じ。日本には「パソコンのメールなんて使ったことがない」「最初にインターネットに触れたのはケータイから」というユーザーが沢山いるわけで、「パソコンのメールよりもより軽くて即時性のあるコミュニケーションの方が今の人たちのモバイル・ライフスタイルには適している」ことは数年前から周知の事実。

この例が示す様に、日本はまだまだ「モバイル先進国」。普通に考えれば、こんな先進国で勝ち抜いた生え抜きのデバイスやサービス(iモード、mixi、モバゲー、お財布ケータイ)が世界を席巻してしかるべき。私がもともと「ガラパゴス」という言葉をポジティブな意味で使って来た(参照)のはこれが理由だ。

iモードやmixiが世界を席巻できていないのは、「日本独自規格だから」などという表面的な理由ではなく、もっと別の部分にある(英語で対等に交渉できるコミュニケーション能力を持っている人材が少ない、国内だけでそれなりのビジネスが作れてしまうので「世界で成功しなくてはダメだ」という意気込みが欠ける、一旦上場してしまうと「ハイリスク・ハイリターン」なビジネス戦略が取れなくなる、など)。

なので、「そんな独自なことをやったらガラパゴスになっちゃう」と、先進的なこと、他の国にないものを頭から否定するのは大きな間違い。モバイル先進国だからこそ受け入れられる新しい商品を生み出し、この島国で強く育てておき、他の国々のライフスタイルやインフラが追いついて来たタイミングで、日本市場での経験を活かして一気に勝負に出て世界を席巻する、みたいなビジネスこそが今の日本が取るべき「ガラパゴス戦略」だと思うのだがいかがだろうか。


Androidのアップグレード問題に関してひとこと

前にも似たようなことがあったと思うが、今度はモトローラがAndroid端末のOSのアップグレードに苦労していることが報道されている(CLIQ XT won't get Android 2.1 upgrade, Motorola's word as good as dirt)。この記事を読む限り、CLIQ XTのユーザーが新しいOSを手に入れることは現実的ではなくなってきているようだ。

パソコンのようにハードウェアのアーキテクチャが基本的に同じで、共通Biosのようなレイヤーもしっかりとあるものと比べ、スマートフォンの場合は、それぞれのハードウェアも大きく異なっているし、共通Biosのようなものも存在しない。それに加え、差別化の難しいAndroid端末の場合、ぎりぎりまでにコストを削る必要もあり、それも「バージョンアップとともに大きくなる」OSのアップグレードを難しくしている。

理由は何であれ、こういう状況はユーザーにとってはとんだ迷惑だし、アプリケーションを作るソフトウェア・ベンダーにとっては悩みのタネだ。こんな状況を見ると「まだまだAndroidに手を出す必要はないな」というのがアプリケーション開発者としての正直な感想だ。

しかし、こう考えてみると、MicrosoftとIntelが作り出した「Windowsパソコン」というプラットフォーム・ビジネスの成功が実はものすごく例外的なものだったんではないかとつくづく思えて来る。デバイス上のプラットフォームの標準化という試みは、Windows以外にも、MSX、Windows CE、3DO、OS/2、J2ME/MIDP、BREW、Symbiam、などさまざまなものが試みられて来たが、Windowsほどの互換性の高さとビジネス規模を達成した例は他にない。今の状況を見る限り、AndroidはWindowsよりはJ2ME/MIDPと同じ道を歩いている様に思える。


SNBinderと「混ざり物のないコンソメスープ」と

先日オープンソース化したSNBinder(参照)、たくさんの人たちから色々なフィードバッックをいただけてとても感謝している。ブログの記事として書かれたものは私が知る限り以下の三つ。

当初は、最新のjQueryと動かないというバグがあったり、READMEにタイポがあったりとご迷惑をおかけしてしまったが、こうやってフィードバックをいただくことによって、励みになったり改良したり、というのがオープンソースの醍醐味である。とてもありがたい。

ちなみに、SNBinderは原型のようなものは1年前以上前からあったのだが、ViewとControllerの切り分けに部分がなかなかすっきりせず、公開を控えていた。今年になって、fruence.comを実装している時に「named template(名前付きテンプレート)」の手法を思いつき、いざ実装してみると「なんでこんな自明の答えにもっと前にたどりつかなかったんだ?」と思えるぐらいのシンプルさ。スティーブン・キングが小説を書く際に大切にしているのは「(自分が書きはじめ設定した)キャラクター自身にあるがままの行動や発言を決めさせること」と書いていたが、プログラミングに関しても同じことが言える。

上の3番目のブログ・エントリー「SNBinderに目からウロコ...」の作者にはそのあたりが伝わったようで、こんなコメントをいただいている。

NSBinderは、DOM要素ごとに、テンプレートファイルから部品を取り出し完全にJSのコントロール下でHTMLパーツを配置していきます。例えていうと、パレットから必要な色を取り出しキャンバスを彩る油絵の如く、テンプレートファイル内から必要な部品を取り出し必要な場所に出したり消したりして画面を構築します。

JS内にテンプレート(HTML)要素が混ざることもないし、テンプレート(HTML)内にJS(ロジック)が混ざることもない。銀座かわむらのコンソメスープのごとく一切混ざり物なしでソースをクリーンな状態に保つことが出来そう。

(中略)

SNBinderでもっとも関心したところのtemplate.html。このファイルには、ページ内の要素をプリミティブな要素まで分解した一つずつがバラバラに記載されている。そして、JS側で表示させたいDOMに対してbindメソッドでプリミティブな要素を呼び出し突っ込んでレンダリングする。

このテンプレートを含めJSも全てクライアントサイドで動くことになるので、サーバー上のフレームワークで毎週のように言われている「どのテンプレートエンジンが速いのか?」といった話題に全く影響を受ける事がない。さらに、HTMLコードと何をレンダリングすべきか考えるコントロールのJSが、綺麗に分割されている。コレがまた気持ち良い。

このエントリー一つ書いていただけだだけで、SNBinderをオープンソースにした価値があるというもの。こんな風に、設計思想の部分まで理解して使っていただけるというのは本当にうれしい。

ちなみに、世の中にはテンプレート・エンジンはたくさんあり、その中にはテンプレートの中に条件分岐が書けたり、スクリプトを埋め込めるという高機能なものまでがある。しかし、私には本末転倒だと思えるのだが、そんなことを思うのは私だけだろうか。複雑なロジックの実行はすべてスクリプト側(つまりController側)で行い、テンプレートはあくまで見た目(View)を記述するだけ、というのがあるべき姿(つまり、混ざり物のないコンソメスープ)だと思うのだがいかがだろうか?

 


ライトノベル「ヒッチコックの憂鬱」

プロローグ

205X 年2月1日付 毎朝新聞

ジュネーブで開かれていたWHO主催の「グローバル・エピデミック・サミット」において米国代表のチャールズ博士が東京のハシブトガラスの異常進化について警告を発した。WHOは、さまざまな細菌・ウィルス・寄生虫に関して発言をして来たが、鳥類そのものの危険性に関して言及したのはこれが初めて。

1990年ごろから顕在化した東京都市部の「人間とカラスの知恵比べ」は、「人間との知恵比べに勝てないかぎり生き残れない」という強烈な「進化圧」をカラスに与え続けており、その結果、東京のハシブトカラスの知能指数が「危険なまでのスピードで異常進化をとげている」とチャールズ博士は警告している。4桁までの暗証番号なら覚えることができるという実験結果も報告されており、既に人間で言うと9歳児に相当するまでの知能を持っていると推定される(注:チンパンジーの知能は3歳児相当)。

2045年に東京都が市街地における鍵付きゴミ箱の設置を市町村に義務化して以来、生き残りをかけたハシブトガラスの行動は、コンビニの自動ドアのモーションセンサーを利用してドアを開けて陳列棚のパンを盗む、網戸をやぶって家庭に侵入し冷蔵庫の中の食べ物を物色するなど、さらに狡猾・悪質なものとなっており、東京都は早急な対応を迫られている。

チャールズ博士は「これは東京だけの問題ではない」と問題の重要性を強調し、各国が強調してハシブトガラス問題に着手することが大切、とスピーチを締めくくった。

(夕べ、NHKの番組を見ながら思いついたライトノベルの冒頭部分。完成させるつもりも、著作権を主張するつもりもないので、残りを書きたい人があったらどうぞ。ハシブトガラスが集団で計画的に人間から食料を奪う様になるというパニック映画風に仕立ててもよいし、カラスの天敵である鷹を人工的に進化させた対抗させようとした結果、逆に地球の生態系がむちゃくちゃになってしまうという反面教師映画にしても良い。最後にはハシブトガラスが人間の言葉を覚えて「平和的な共存」を目指す話し合いに望むという「なんでもありSF」だけはちょっといただけないが...)。