NeonsWiredSymphony

Displex v1.3向けにGAE/JのBilling設定を有効にしてみた

Neons — 2009-09-29T01:52:47+09:00

GoogleAppEngine for Java(以下GAE/J)は、一定のリソース分までは無料で使うことができる。リソース制約についてはQuotaの説明ページに載せられているのだが、数字を見ただけでは何をどれくらい使えるのかいまいちイメージできていなかった。

iPhoneアプリ Displex v1.2.1では、番組関連情報のクロスサーチにだけGAE/Jを使っていた。しかし、9月末日での日刊スポーツTVサービス終了に伴い、Displexv1.3からは番組データもGAE/Jから配信するように変更した。Displex v1.3の公開直後はいつも通りの静かな滑り出しだったのだが、iPhoneアプリをおすすめするAppBankさんで紹介された途端、猛烈にダウンロード数が伸び、一日で数万アクセスが一斉にやってくる事態となった。（無料アプリ総合12位、無料アプリユーティリティ3位は全く持って初めての数字で、紹介には感謝しております。）

アクセスの増加に伴い、GAE/JのBilling設定を有効にすることになったため、今回はそのあたりについてまとめてみる。

まず開発途上でリソース的にまずいかなと感じていたのは、Datastore API Calls(DataStore=GAE版DB)の回数だった。番組データを番組詳細情報で補完するのにDataStoreを使っていたのだが、一度のアクセスで番組の数だけDataStoreにアクセスする実装にしていたため、あっという間にAPIコール回数が数万回に達してしまった。そもそもこのやり方は、APIコールの呼び出し回数もさることながら、処理時間のほうも問題で2000ms～5000msかかっており、30秒以内のResponseがマストなGAE環境においては、処理方法を見直す必要に迫られた。

タイミング良く、GAE/J向けフレームワークSlim3の開発に取り組んでおられるひがやすをさんが、「SQL脳からBigTable脳へ」というお題目でお話をされるということだったので聴きに行ってみた。内容はGoogle I/O2008のBigTableの説明スライドをべースにしたものだったのだが、SQLで当たり前だった処理をそのままBigTableに落とし込んでもダメで、代わりにこうやるべしというメッセージがきちんと伝わってくる秀逸な内容だった。簡単に言えば、where句のプロパティ指定は出来る限り一個になるようなデータ設計をして（where 句でorも使えないし）、あとのSQL的な処理(countとか複数where句andとかjoinとか）は、Javaオブジェクト側でやるべし、ということだった。そして、Java側のSQLライクな処理はSlim3を使うと簡単ですよ、という締めくくり。

検索条件をシンプルにするために非正規化も厭わないという考え方は、RDBの正規化至上主義とは大きく異なる。第四、第五正規化はさすがにやりすぎだが、第三正規化くらいまではさくっと切り込めてこそ、一人前のDBエンジニアという教育を受けた身には結構衝撃的ではある。

また、GoogleI/Oのセッションによると、GAEはWebサーバ、アプリケーションサーバ、DataStoreサーバ、MemCacheサーバおよび各API群ごとにサーバがデフォルトで分かれているらしく、開発者はGAEの制約に沿ってアプリを書くだけでスケーラビリティと信頼性を確保することができるそうだ。

引用:Google I/O 2009 Life of an App Engine Request
上記のセッションは、自前でサービスを拡張していく場合にぶつかる様々な問題をベースに説明が展開されているので、なかなか興味深い内容だった。

考え方を改めて設計を見直し、DataStoreへのアクセスを極小化して、Javaオブジェクトにおけるフィルタリング処理の活用、およびMemCacheの積極的な適用という方向にふってみたところ、利用者が増えれば増える程キャッシュが貯め込まれて、相対的にレスポンス速度が向上するという構成を実現することができた。実際、アクセスの9割程度がMemCacheに完結した処理にとどまっているので、レスポンスは平均400ms程度に収まっている。(ただし、たまに1500msくらいかかる事もある）

前置きがあまりに長くなりすぎたが、ここからBillingの話題に入る。結局、リソース的にあっという間にフリーQuota分を超える勢いを示したのは、Outgoing Bandwidthだった。EPGデータは24時間分で約100KB程なのだが、数百MB単位でどんどん消費されていく。2009/5/25付で、フリー分が10GB→1GBに変更された事から鑑みても、Outgoing Bandwidthはやはり上限に近づきやすいカテゴリのリソースなのだろう。

設定は左メニューの「Billing Settings 」から入る。GoogleCheckOutにクレジットカード番号を登録して、下記の画面でリソースごとの予算を割り振ることができる。Budget Presetからいくつかお勧め設定が出てくるが、Outgoing Bandwidth以外はまだまだ余裕があるので、Custom設定で$1.00すべてを一点集中で設定しておいた。これで1GB→9.3GBまで拡大することができた。

もちろん1日ごとの予算の上限設定が$1.00なだけで、フリー分を超えた分だけ支払いが発生する形だ。ご都合.comの事例でも触れられているが、1日数ドルの予算設定で済むレベルであれば、Google AdSenseで十分Payできるので、いまのところ実質はフリーで使い続けることができている。また、Billing設定を有効にすると、Quotaの表示にフリー分を示すアンカーが表示されるようになる。

ちなみに上記のグラフで所々にアクセスの間欠があるのは、裏でサーバロジックを更新して、別バージョンに切り替えていた時間帯である。リアルデータを使って動作確認をした後、本番URLに瞬時につなぎ替えられる機能がデフォルトで入っているあたりに、NonStopサービス運用に長けたGoogleのノウハウが垣間見える。

ここ数日は5～6万アクセス/dayくらいが発生しているが、サーバインフラ面での不具合には遭遇していない。ただし、アプリレベルではバグがいくつかあり、AppStoreではユーザーさんから厳しいコメントをいただいているが、これは単純に自分のミスである...orz　9/27はいくつかバグ対策に追われたが、9/28以降は安定して稼働を続けており、やっと枕を高くして寝ることができそうだ。

最後に別の事例について。Google App Engine Blogの2009/9/22付けのエントリでは、Norexという企業がカヌーの世界大会のタイム速報サイトにGAEを適用した事例が載せられている。初日で84万アクセス、決勝のピーク時には100Request/secondという強烈なアクセス集中が発生したそうなのだが、タイムレコード更新タイミングごとにMemCacheをうまく適用するという工夫は必要だったものの、障害なく乗り切ったそうだ。

ここまでのレベルでもきちんとスケールしてくれるのであれば、インフラ面の心配はGAEにお任せして、Webアプリロジックに専念したサービス開発を行うことができそうだ。

GoogleはAppEngineで本気のビジネスをしようとしている

Neons — 2009-08-11T02:09:37+09:00

テレビ番組表から録画予約ができるiPhoneアプリ「Displex」のv1.2.0まででは、番組名をキーワードにして、Amazonに直接検索をしていた。アニメやドラマなど、DVDが出ていたり原作があったりする番組では中々おもしろい結果が出ていたのだが、検索にひっかからない番組名が多々あるという問題を抱えていた。

そこで、GoogleAppEngineのJava版(GAEJ)を使って検索処理をサーバーに肩代わりさせて、検索にヒットしたときだけリンクを表示するという改善を試みた。実装はすでに終わっていて、このサービスに繋げたv1.2.1を~~本日申請した。~~
~~(申請後、3Gによるテスト中に不具合が見つかったため、自己リジェクトをしました。8/17に再申請しております。)~~
(v1.2.1が公開されました)

GAEの導入に際しては、Google App Engineで手軽に試すJavaクラウドを参考にした。2009年8月時点では、別途登録しなくてもいきなりJava版の利用も可能な状態であった。

これまでTomcatやJettyを使ってJavaServlet/JSPの実装をした事があったので、ほとんどGAE環境の特殊さを気にせずにアプリを書くことができた。Eclipseのツールバーからボタン一発でローカルサーバでの実行とサーバーサイド環境へのアップロードまでサクっとでき、すこぶる快適であった。ここまでの開発環境がさっと揃うだけでも凄い。

もし自宅で自前サーバを用意する場合、専用マシンを用意して、LinuxOSを入れて、JDK入れて、Apache入れて、Tomcat入れて、連携用のmod_jkなどのプラグインを入れて、RDBをインストールして、JDBCをインストールして、、、、とアプリを書き始めるまで膨大な工数を要する。さらに外部に晒すサーバともなれば、DDNSなどを使ったドメイン名解決、ルータへのアタック対策(国別フィルタくらいは入れないと海外からの攻撃がものすごい）、停電対策で簡易UPSを導入、そして月々の電気代の支払いなどなど、継続運用に要する時間的、金銭的コストもなかなか馬鹿にならない。

レンタルサーバを借りるとしても、意外とJavaに対応しているサービスは少なく、PerlやPHP、Rubyなどが多い。まぁRoRでもいいんだけど、とにかく無料では済まされない。

それがGAEJの場合、JDKインストール、Eclipseインストール、GAEJプラグインストールとGAEアカウント登録、以上だけであとは一切合切お任せして、アプリ実装に集中できるのである。これってよくよく考えるとものすごいことだ。個人レベルで月ごとの無料リソースを使い切ることは相当なアクセス数を稼がない限りなさそうなので、実質無料でさくっとサーバアプリがかける環境が、個人に提供される時代になってしまったのだ。しかもGoogleのビジネスの根幹を支える分散実行環境で稼働されるわけなので、彼らの競争力の源泉の一部を開放しているということになる。

近頃のGoogleの動きを冷静に眺めれば、Androidは傍流でしかなく、本命はHTML5によるブラウザを介したソフトウェアの総Web化であることに気づく。Chromeブラウザ、ChromeOS、そしてAppEngineは総Web化に向けた施策であると捉えるべきだろう。何より無料リソースを超えたときにきちんとお金をとる気満々なところが、ビジネスとして真剣に考えている証拠だろう。AndroidはAndroid Marketのおざなりさ具合からもしても、どう考えても本気とは到底思えない。

さて、デジタル家電のネットサービス連携を考えるに当たっても、サービスの増減、サービスのダウン、アダルトなど不都合なデータのフィルタリング等々を鑑みると、クライアントからの直アクセスは相当リスクが高いという結論に達する。現実的な対策を考えると中間サーバの整備は必須であると言い切って良いだろう。中途半端かつ時代遅れなDalvikVMに依存してAndroidなんぞを導入するより、HTML5にきちんと対応できるブラウザを載せることに集中し、あとはAppEngineを使った家電向けサービスを考えたほうがずっと意義があるのでは、と思えてならない。

長くなってしまったので、Displex向けサービスの中身についてはまた次回に。
とりあえずURLはこちらです。
iPhone Safari向け画面になっている都合上、Firefox/Safari/Chromeあたりでどうぞ。(IE6だと激しく崩れます。）

iPhoneアプリ「Displex v1.2」が公開されました。

Neons — 2009-07-17T01:39:23+09:00

iPhone3G向けパフォーマンスチューニングを含む多数の改善を施した
v1.2が公開されました。7/9申請で7/16公開なので、今回はちょうど一週間でした。前回の更新はちょうどOS3.0公開タイミングとかぶっていたので、たまたま二週間もかかってのかもしれません。

修正内容は以下の通りです。

◇番組表ダウンロード速度を高速化した
　・いままで一番不満点として多く挙げられていた課題なので、かなり時間を割いた部分です。
　 iPhone3GS+WiFi回線ですと、競合アプリ(テレビ番組表、Bangumi)に負けない速度がでていると思います
　　もちろんiPhone3Gでも実用レベルの速度が出るようにしてあります

◇番組表ダウンロード中にアナログ時計を表示するようにした
　・ちょっとしたギミックですが、DL中画面の真ん中が寂しかったので

◇今日の番組表の場合、放送中の番組を強調表示するようにした
　・いまやってる番組が知りたいというニーズも多かったです。録画ニーズはその次、が正しい認識でした。

◇番組表で放送局名が常に上部に表示されるようにした
　・こちらも改善要望が多かったです。確かに圧倒的に見やすくなりますね

◇番組表の文字サイズを5段階で指定できるようにした
　・デフォルトは中ですが、小が個人的にはしっくりきています

◇番組表のフォントをヒラギノに変更して、タイトル名は太字にした。
　・ラテ欄番組表の基本であるタイトル以外の一行寄せもいれています。だいぶ視認性が上がりました。

◇番組をワンタップすることで情報表示/非表示を切り替えるようにした
　・いままではタイムバーのみだったのですが、番組矩形でも反応するようにしました。
　　トグル動作は辞めて表示/非表示の二択にしています。

◇一日の表示番組数を削減するによって、スクロール速度を向上させた
　・朝4時～翌日の3時までにしました

◇本体向き判定を改善した
　・上下逆とか変わった向きでもきちんと表示できます

あ、あと重要なポイントとして、アイコンのテレビにアンテナをつけました。アプリ名がアプリ名なので、テレビに関係していること自体が認知されないという課題への取り組み、、、ということで。後発アプリなので仕方ないのですが、「テレビ番組表」もあるし、「テレビ」もあるし、もはや「テレビ」というキーワードがつけにくい状況にあります。その点、「Bangumi」は本当に一本とられた感じです。

iPhone3G向けパフォーマンスチューニングを考える

Neons — 2009-07-09T02:02:40+09:00

自分が所持しているのはiPod Touch2G(CPU:532Mhz)なのですが、知人が3GS(CPU:600Mhz)を購入したので3G(CPU:412Mhz)をお借りすることができました。
早速Displex v1.1を3GにDLしてみたのですが、そのもっさり感に愕然としました。

まず番組表ダウンロードでUIProgressBarが激重、その後の番組表のスクロールもカクカクでした。
これはだいぶ酷い体験をさせてしまったなぁと反省しきりです。

今回はiPhone3G向けに施したチューニングについて幾つか書いてみます。

番組表ダウンロードで時間がかかっていたのは、各番組の時間長の計算において、開始時刻と終了時刻のNSStringからNSDateFormatterを使ってNSDateに変換する、という処理を生真面目に書いてしまっていたからです。この処理を時刻の文字列から分単位のintに変換してその差分をとる形に変えることで、一気に10倍以上速くなりました。これでダウンロードメーターはサクサク進むようになりました。

次が、UIScrollViewの設定です。番組表の上下左右の端に到達した際に、慣性が働いてバウンドする動きがデフォルトではonになっていました。200個オーダーのUIViewをUIScrollViewのcontentsに格納した状態ですと3Gではカクカクになります。これは端に到達しない状態でも常にスクロールが重くなるので注意が必要です。この動作をdisableにするには、下記のpropertyをすべてNOに設定する必要があります。bouncesはデフォルトでYESなので明示的に指定しないと効きません。

bounces = NO alwaysBounceVertical = NO alwaysBounceHorizontal = NO

上記の変更は3Gだけで効かすのではなく、すべてのモデルに適用しました。これでiPod Touch2G/3GSでは、さらなる素早い操作感が得られるようになるという副次的なメリットも得られました。Displex v1.2として本日申請したので、順調にいけば2週間後くらいにAppStoreに公開されると思います。

さて、1Ghz未満のCPUでは、100Mhz単位の違いで随分の操作感が変わってきます。iPod Touch2GとiPhone3GではGPUが同等で、完全にソフトウェアスタックに互換性があっても、これだけのアプリ体験の差が生まれてしまうのだと実感することができました。では、Androidのように画面解像度やCPUアーキ、入力デバイスまで異なってきた場合にはどうなってしまうのでしょうか？動作検証を考えると莫大な工数を要することは容易に想像できます。HTCはすでにAndroid搭載ケータイを数モデル出してしまいましたが、初期開発コストは想像以上に高い、なんて言っていたのが懐かしくなるほど、今後はその比ではないレベルでアップデート対応工数がかかってくるでしょうね....。

ラテ欄番組表からテレビ王国経由で予約できるiPhoneアプリ「Displex v1.1」をリリースしました。

Neons — 2009-06-27T02:26:42+09:00

まさかのv1.0公開から、はや三週間。ようやくv1.1が公開されました。v1.0のときの課題だった番組表のスクロール速度の改善、メモリ不足によるアプリ終了ケースの回避策などをいれました。だいぶ実用的になってきたと思います。

それしてもv1.1審査中に積み上がるv1.0に対する★1つ評価はなかなかつらいものがありました。そんな中でも先の可能性も含めてくださったのか★5つをつけてくれる奇特な方もおられて、それが無性にうれしかったりして...。1ユーザーのときには大して気にしていなかった★の数ですが、いざアプリ公開をすると凄く気になるものですね。

そんな気分で改めてアプリランキングを眺めると、大企業に属する商用タイトル開発チームから、小規模組織、そして個人までが横一線にならんで同一プラットホームでクオリティとアイデアを競い合い、ユーザーの評価によってのみシビアにランキングされるiTunesAppStoreの仕組みは、組織と個人の線引きすらあいまいにする強烈な仕組みだと思い知らされます。Appleはこのサバイバルを生き残った至高のアプリを次期商品に組み入れることによって、かつてMSがWindows上で実現していたポジティブループをモバイルにおいて手中に収めました。少なくとも直近の2年はiPhoneに勝てる端末は出てこないでしょう。もちろん、スペックで勝るものがは多数でるでしょうが、トータルな商品価値という観点ではたぶん太刀打ちできません。

さて、3GSは買おうかどうか踏ん切りがつかないうちに、ついに日本の発売日を迎えてしまいました。
2年で14万、、、と考えると...

そんな中、運よく知人が3GSを発売日にゲットしていたので、さっそくDisplexv1.1をDLしてもらい操作してみました。実は番組表の箇所は豪勢なクラスの使い方をしており、番組用の矩形ひとつひとつにUIViewクラスを割り当てています。しかもそのまま切り替えなしで拡縮時に表示している都合上、最小表示にしたときには約50個以上のUIViewを一斉にスクロールすることになるため、iPod Touch2Gではタッチの反応に遅れるような動作がありました。しかし3GSは終始きびきび動作してくれており、さらなる快適体験が味わえました。番組表ダウンロード処理時間も体感速度で半分とまでは行きませんが、20%くらいは速くなっていたように感じられました。

v1.2では、番組表の長さの計算処理を効率化することによりさらなる番組表ダウンロード速度の向上が実現できそうです。v1.x系のアップデートはv1.2までとして、いよいよメジャーアップデートとなるv2.0で予定通り家庭内LANにおけるSony製BD/DVDレコーダーへのダイレクトアクセス対応に着手していこうと思っています。テレビ王国経由よりは圧倒的に使いやすくなりそうです。

まずは、ラテ欄番組表の快適ブラウズをぜひ体験して見てください。無料アプリなのでお気軽にどうぞ！

iPhoneアプリ「Displex」v1.0をリリースしました。

Neons — 2009-06-07T01:22:35+09:00

産経新聞のiPhoneアプリによる朝刊無料配信が始まって以来、iPod touchが手放せない日々が続いていた。
ピンチイン、アウトによる読みやすさに感心しながら、一際目を引いたのはテレビの番組表のページだった。

「もしこの番組表からレコーダーに予約できたら....」

と思い立ち、そのままiPhoneアプリ開発への邁進していったのが4月末くらいのお話。

ちょうどテレビ王国のリモート予約機能をiPod Touchで使いはじめていたので、iPhoneネイティブアプリによるラテ欄形式番組表とテレビ王国のリモート予約を軸に据えることに決めた。

ObjectiveC自体初めてという所からのスタートで試行錯誤の連続だったのだが、このたび初めてのアプリストア公開までこぎ着けることができた。

Displex @ iTunes アプリストア

EPGデータも借り物、テレビ王国の予約機能も借り物というつなぎ合わせ系アプリなので、当然のことながら無料に設定した。

審査のReject例として、システムアイコンを独自機能に割り当てたり、12時間表示設定時のチェックがされたり、といった辺りがひっかかったという情報があり、こりゃ2,3回Rejectは覚悟かなと思っていたのだが、あっさり初回でReady for Sale通知が来た。厳しいのはUSのAppStoreなのかな？(本アプリは国内限定公開)。5/28に申請して6/6公開だったので約10日かかったことになる。

さっそくレビューが上がっているのだが、ごもっともな内容が多い。起動時間の遅さは番組表ダウンロードの遅さなので、プログレスバーをつける予定だ。またメモリ不足による強制終了はAutoReleaseオブジェクトの解放をこまめにしていないのが原因なので、NSAutoReleasePoolをいれて対処する。短い番組でのフォント切れ、スクロールのパフォーマンス改善周りも大体めどがついているので、近日中にV1.1の申請を出す予定だ。

Androidはクライアントサイドの技術革新を止める

Neons — 2009-03-16T09:30:00+09:00

近頃、「時代はクラウド、ガラパゴス化した日本のケータイ業界はオープンなAndroidを使って世界標準に合わせるべきである」、という論調をよく目や耳にする。金融危機に起因する強烈なコスト削減要求にふらついたメーカーが、ロイヤリティフリーのAndroid採用に目が眩むという現象も起きている。

しかし、これからもクライアントサイドの端末を市場に送り出してビジネスを継続していこうとしているメーカーなら、Android採用に伴うリスクをきちんと評価すべきだ。勿論、セキュリティホールや致命的な基盤の不具合による不祥事発生の可能性も大きな問題ではある。

GoogleのAndroid SDKに複数の脆弱性
 「Android」セキュリティ問題と情報制限--グーグルとT-Mobileがとった対応の妥当性

しかし最大かつ最悪のリスクは、クライアントサイド（ケータイ、カーナビ、STB）の技術革新が抑制されることにある、と認識すべきである。

なぜ、Androidを採用すると、クライアントサイドの技術革新が止まると言えるのだろうか？

それはGoogleがクライアントサイドの技術革新に全く興味がないからである。

もうちょっと正確に書くと、いかに今以上にユーザー行動の内容をより速く、より広く、より細かくとれるか、ということにしか興味がない。だから、GPSやカメラや電話帳や動画の視聴履歴管理には素早く対応するが、それ以外はどうでもいいから全くやらないか後回しにする。クライアントの操作性なんてどうでもいいから、マルチタッチ操作を使えるようにAppleとまともな交渉もしないし、革新的なGUIなんてどうでもいいから3DGUIフレームワークはHTCに作らせて市場実験をやらせるだけだし、いつ開発を辞めても文句を言われないように、AndroidMarketで利益をあげようともしていない。

タッチパネルを使った入力インタフェースでマルチタッチなしがどれほど残念なことになるかは、iPhoneを一度味わった人は容易に想像がつくだろう。GoogleCEOのSchmidtはApple社外取締役なんだから、交渉ができないわけがない。クライアントでビジネスをやっていこうとしているPalmはもちろん真っ向勝負だ。

3DならOpenGL ES1.0がついている？OpenGLだけでどうやってアプリを書くのか。標準GUIコンポーネントが3D描画支援されるiPhoneならともかく、Javaの3DAPIでラップしただけの状態ではお話にならない。当面GPUを積んだAndroid端末を出すメーカーはここに投資が必要となるだろう。

AndroidMarketが開発者とキャリアに全部還元するなんて素晴らしいこと？....だとは全く思わない。もしGoogleがほんの数%でもAppMarketで利益を上げようとしていたら、逆にAndroidを見直していたかもしれない。それがプラットホームが死ぬまでリソースを注ぎ込む覚悟だと捉えられるからだ。(※注1)　ソフトプラットホームの存在意義とは、互換性の維持、これに尽きる。アーキテクチャの美しさとかアプリ開発効率も勿論大切だが、互換性がずっと維持されなければそもそもソフト資産が蓄積されない。WindowsやMacOSがプラットホームとして成立しているのは、一つの企業が(自らの戦略を実現する方向に限定されるものの)莫大なリソースをかけて互換性を保ってきたからだ。オープンソースの奇跡的な成功例と言われるLinuxだって終身の優しい独裁者であるLinusがきちんと何を入れて、何を入れないかを判断してきているからカーネルレベルでは互換性が維持されているのだし、LinuxFoundationという名札をつけてLinusがきちんと主要コンポーネントのメンテナを任命しているからセキュリティパッチがリリースされ続けられるのだ。こんなにしんどいことをやり続けられるのは「それがぼくには楽しかったから」である。

Androidは、せいぜいV8 Engineが移植されてクライアントとして機能向上は終了するだろう。Webブラウザが高速に動くところまでしかGoogleにはクライアントの興味がないのだから。

では、すべてがオープンなんだから、各メーカーが自由に拡張して技術革新を起こせばいいのだろうか？

1号機の製品出荷時にはそれで問題ないだろう。、多かれ少なかれOHAという名札をつけたGoogleが提供するSDK(=本線)を改変してリリースすることになる。さて、そのメーカーがAndroid搭載2号機を出そうとするとき、以下の二つの選択に迫られる事になる。

(1)Google本線のアップデートを取り込んで、1号機の変更内容をマージする
(2)Google本線を無視して、独自拡張に突き進む

(2)を選んだら互換性は失われる。従って他のアプリがすぐに動くというAndroidの唯一のメリットを享受しつづけるには、泣きながら(1)を選ぶしかない。これがLinuxカーネルや特定のオープンソースコンポーネントだけに限定された話であれば、マージの続行は可能である。しかし、AndroidはOSではなくて、アプリフレームワークを含んだケータイのフルスタックソフトウェアである。(1)を現実的なコストで実施していくには、1号機開発のときに施した改変(や追加内容)を、Google本線に入れてもらうしかないだろう。さて、本線に何を入れるか、入れないかを判断するのは誰か？OHAという名札をつけたGoogleである。従って、Googleに興味がなければ入らない。ここで最初の話に戻る。Googleに興味があるのは何だったのかと。

ここに興味深い実例がある。AndroidのIssueリストを見ると、2007年11月の開設当初にはDefect(欠陥)だけでなくEnhancement(機能拡張依頼)も丁寧にReviewされていた。しかし日を追うにつれ、Newのまま放置されるものが目立ってきている。かの有名なRebootバグだって、一度目の報告では放置されて、二度目の報告でやっと対応してもらえたようだ。よほど致命的な欠陥でもない限りなかなか話を聞いてもらえそうにないと感じるのは自分だけだろうか。何しろ一銭も払っていないのだからGoogleには何の義務もない。ビジネス的メリットもない。そしてあくまで繰り返すがGoogleにはクライアントには興味がない。

その結果、Android採用端末はどうなってしまうのか？先ほどの選択肢に、実はもうひとつオプションがあったのだ。
それは....

(3)独自拡張を辞める

というものだ。これなら互換性の維持はばっちりである。そして、クライアントサイドの技術革新は止まる。

以上の理由から自分はAndoridには関わりたくない。人と接するクライアントデバイス部分の価値は絶対に失われないと信じているし、引き続きクライアントに興味があるからだ。その点Appleもクライアントに興味を持ち続けているし、そこを競争領域として投資して、そして利益を上げている。iPhoneとAndroidはスマートフォンプラットホームの未来を担うかのように並べて良く語られるが、見た目は似ていても目指すところが全く別物であり、比較するべきものでもないだろう。なぜならiPhoneプラットホームは革新を続けるが、Androidプラットホームに革新はないからだ。

もちろん、Androidクライアントの革新が止まっても、Googleのサービスは革新を続けるだろう。しかしそれでコンテンツもサービスインフラも持たないメーカーはビジネスを続けられるのだろうか？ハードは誰でも買えるものを持ってきてアプリだけで差異化ができるのだろうか？こうした懸念を払拭するスーパーな作戦を持たない限り、Androidには流れてほしくないなぁと思う今日この頃である。

-------
2009/6/13
(※注1)2008/10/22付Android Developer BlogではGoogleの取り分はない、とありました。しかし、今年のインタビューによると、キャリア分30%うち、5%をGoogleが決済手数料としてとっているようですね。コメントありがとうござました。

SpursEngine start-upイベントに行ってきた

Neons — 2008-12-07T00:17:33+09:00

SpursEngine start-upイベント @ 秋葉原に行ってきた。リンク先の写真だと閑散としていたかのように見えるが、撮影した時間が早かったのだろう。13時くらいに遅れていったのだが、入り口は50名くらいが二重になって並んでいて、入るのに20分くらい待たされてしまったくらいであった。SpursEngine搭載カードの売れ行きも予想外(?)に好調のようである。

東芝さんは、2009年CellTV発売のアナウンスを行ない、自社ノートPC「Qosmio」にSpursEngineを搭載し終え、着実に社内の生き残り策を打ってきている。今月のSpursEngine搭載PCI Expressカード2モデル（Leadtek WinFast PxVc1100, THOMSON Canopus FIRECODER Blu）発売に合わせて、どんな施策を打ってくるか、というあたりに興味を持って行ってきた。

最大のサプライズは、SpursEngineソフトウェアSDKのアナウンス内容だ。MPEG2,AVCのDecoder/EncoderのAPIのみでなく、SPU4基に対して自前プログラムを実行するための開発ツールも提供する、というのだ。残念ながら、SPUのコードからDecoder/Encoderを叩くことは最初のバージョンでは出来ないそうだが、今後対応予定らしい。初回バージョンで提供できない理由は、現行の顔認識やジェスチャ+Decoder/Encoderのソフトの作りが密結合しており、とても汎用コードから呼ぶための切り口の整備ができていない状況だから、とのことであり、ライセンス、技術的な制約ではないらしいのでここは安心してよさそう。

SPUを使ったオープンな開発環境としてPS3Linuxがあったが、XDRAM256MBでXWindowを走らせても重いだけでまずここで萎えてしまった。じゃぁまずはCodecの高速化あたりかな、ということになるが、例えばx264を移植するという試みもやはり開発規模が個人として大きすぎてなかなか難しそうであった。仮にCodecの高速化ができて、SPU処理で高速化する部分を括りだしても、その前後の入出力整備(入力ソース整備、出力ファイル先)の敷居があまりに高く、おまけにGPUとしてのRSXはたたけないという状況で、火のつきようがなかったと言えよう。

しかし、今回の場合はWindowsOS上からPCIExpressカードアクセス、というところからスタートすることができる。動画処理で重くて困っている部分だけを切り出して、それ以外は従来のワークフローをそのまま使うということが可能になるので、ターゲットを絞った効率的な速度向上ネタをたくさん投入することができそうだ。しかもMPEG2からH.264へのトランスコードという国内でニーズの多い(?)ユースケースにおいて、最も重い部分であるDecode/Encodeは理論値であるが実時間の2倍速の性能を狙えるところからスタートできるため、その前後処理でやりたい準ヘビィ級の処理をSPU化するという方向が良さそうに思える。

たとえば、AviUtilという動画編集時に自由にフィルタをかけられる点で定評のあるオープンソースツールがあるが、入力/フィルタ/出力プラグインとしてSpursEngineを組み込むことの敷居は低いだろう。出力プラグインとしてSpursEngineのEncoderを指定するというところから始められるし、その前段で使われるまるも製作所さん謹製「MPEG-2 VIDEO VFAPI Plug-In」「Lanczos 3-lobed 拡大縮小」のような定番かつ重めなフィルタの、MMX/SSEアセンブラのSIMD命令実行部分をSPU SIMD命令置き換えてさらに並列化する、というような案配である。

東芝さんがこれまで提案してきたジェスチャ操作や顔認識もまぁおもしろいのだが、やはり現実的に今必要とされているユースケースの高速化から実現されていかないと、なかなか盛り上がっていかないだろう。クラウドが台頭してきた昨今において、個人レベルでコンピューティングパフォーマンスが必要な用途はもはや動画処理だけと言っても過言ではない。クライアントサイドに残された数少ないパフォーマンス競争領域を巡って、IAコアの高速化という従来路線、急進的実験プラットホームLarrabee、GPGPUのさらなる汎用化に走るCUDA、OpenCL等で今後華々しいリリース合戦が予想される中、第三のプロセッサとしてSpursEngineが地位を確立できる可能性のある時間は意外と少ないかもしれない。


LEADTEK WinFast PxVC1100	カノープス FIRECODER Blu(RC)

TOEIC Bクラスへの高速道路を走ってみた

Neons — 2008-06-18T23:07:17+09:00

ここ最近、海外出張に行ったり、北米のエンジニアとミーティングをする機会が多くなってきている。
今年、三十路に突入予定で、もう若手とは言ってもらえない年齢になるというのに、こんな英語力ではやばすぎるという焦りと、もうすぐ子供が生まれて時間があまりとれなくなるという事情から、できる限り今のうちに英語力アップを図ろうと奮起した。

まず最初に、リスニングができないことには、ミーティングで自分の意見も言えない。また、英語でEメールをかくのにも、基本的な文法を再度やり直す必要がある。この格好の題材はTOEICだろう、という安直な思考パターンで、とりあえずTOEICの勉強を始めてみることにした。

梅田さんによると、インターネットによって大体の分野で高速道路が整備されているそうである。TOEIC高得点獲得への高速道路を探してみたところ、「中学生レベルの英語力の奴が４ヶ月でTOEIC「Bクラス」を出す方法」というエントリが見つかった。内容を見ると別にトリッキーなことをしているわけでもなく、正攻法でありつつも、必要最低限のルートを押さえているように感じられたので、その通りにやってみた。そうしたら、本当にBクラスがあっさりとれてしまった。会社で受けたIPテストが765点。弊社では、800点を超えないとこれから毎年IPテストを受けさせられるみたいなので、自分でもう一度公開テストを受けたところ、825点を獲得することができた。

さすがに元サイトは、去年3月のエントリで、今では同じシリーズの本でも、より新しいものが出ていたりするので、適時そこは更新した内容でまとめてみたい。

１：基礎文法力をつける

文法の基礎をもれなくきちんと押さえてくれる、これまで出会った中で最良の文法本だった。(大学受験時に知っておきたかった.....)。元エントリでは、この本を一週間でやったとあるが、社会人でそれは厳しかったので、一週間で5Lessonずつくらいのペースで進めた。平日に1Lessonずつやっていって、出来なかった日の分を土日に一気に追いつくというような形が個人的にはフィットした。例文の出来がよいので、基本的にすべてノートに書き出して、後から見直すという形態を基本としつつ、日本語部分だけをみて、英訳した内容を音読しながら学習していくのが後から思うと効果的だったように思う。ちなみに、各Lessonの確認問題のうち、Bの間違い直し問題は、現在のTOEICでは出題されないので飛ばしておいた。これ一冊で、TOEIC READINGの文法問題を落とすことは基本的になくなるだろう。ただし、最近の出題傾向は、文法問題が減って、語彙問題の比重が上がってきているので、別の対策も必要だ。(これは後述する）

この本を終えるだけで、自分の言いたいことを即座にちゃんとした文法で組み立てて発言する、ということが前よりはずいぶんと出来るようになったように感じられた。

２：基礎単語力をつける

DUO3.0は、この高速道路のいわば核心部分だ。学習順序は以下の通り。

(1)テキストを参照しながら、基礎用CDを使うのだが、聞こえてきた内容の箇所のテキストを目で追いながら、少し遅れて発音してみる。(あとから知ったのだが、これってシャドーイングっていうらしいですね)。スローテンポできいたあと、各単語の発音をきちんと確認し、その後ナチュラルテンポで聞くと、前置詞と名詞を繋げて発音したり、1センテンスの特定の部分にどのようにアクセントをつけると、「ネイティブ」っぽく聞こえるのか、というのが感覚的にわかるようになってくる。

(2)1つのSectionが終わったら、復習用CDを使って、Section内のすべての例文を一気にナチュラルテンポで聞くのだが、本を見ないでCDの音声に少し遅れながら発音する

(3)個人差があると思うが、前のほうの内容を忘れ始めているかも....というタイミングで、復習用CDを付属の「The Collection of DUO's Sentences」を使いながら、シャドーイングをする

大体1週間で10Sectionずつくらいのペースで進めた。復習は10Sectionをまとめて一気にやる、くらいの区切りが良かったように思う。1/3くらいを終えたあたりから、着実にリスニング力の向上を自覚することができるようになってくる。これまで全然聞き取れなかった内容が、明快に各単語に分離して認識できるようになるのだ。このあたりから英語の勉強が俄然楽しくなってくる。ここを超えれば全体の半分以上は終わったと言える。基礎と銘打っているだけあって、汎用的かつ実用的な力がつくフェーズだ。

3-A:TOEIC 3:Part5、Part6対策

ここからTOEICに特化した対策フェーズに入る。元エントリではパワーアップ編のみが薦められているが、2007年後半から2008年にかけて、Part5で文法問題が減って、語彙問題が増える、という傾向が顕著になっているようだ。パワーアップ編のあとに、ステップアップ編というのも出ているのだが、これは文法的に難しいものをどう攻略するかという観点の本であり、ちょっと最近の傾向にはそぐわない。IPテストは、少し前の公開テストを使っているようなのだが、2008/2時点の受験時には、すでに語彙問題がかなり増えていた。IPテスト受験時には、パワーアップ編とステップアップ編しかやっていなかったので、随分とPart5が難しく感じられて、実際READINGは300点半ばしかとれなかった。一方で、千本ノックのほうは、語彙問題の増加に追従した内容になっており、Part6向けの対策も結構入っている。従って、パワーアップ編+千本ノック編の二冊をここではおすすめしておきたい。語彙問題が増えているとはいえ、TOEIC恒例のパターン問題というものはやっぱり存在していて、緑本シリーズはそれを余すところなく掲載してくれている。

3-B:サードパーティの模試をやり込む

緑本は一気にやるというよりは、通勤時間など隙間時間をぬってやり続けるものなので、並行してサードパーティの模試をやり込む。各Partの基本的な攻略方法が冒頭にあり、LISTENING問題の先読み手法やREADING問題の時間配分など試験攻略に有益な情報が多数掲載されている。一般的にTOEIC本番の内容よりも、このシリーズの問題は難易度が高いと言われている。確かにリスニングは極端にまで訛りの強いスピーカーが混ざっていたり、時間勝負なだけなはずのPart7に、引っかけ問題が多数埋め込まれていたりして、予想していたより全然得点がとれなくて結構へこむことになる。しかし、事前に難しいものに当たっておくことで本番が楽に感じられるので、このシリーズの模試はぜひやっておいたほうがいいだろう。予想外の出来なささ加減によって、これまでの英語力向上の実感が揺らぐので、基礎文法、基礎単語を復習するモチベーションが沸くという副次的効果もある。

4:公式模試をやりこむ

仕上げは、ETS公式の模試。2008年になってから立て続けに新しいものがでている。実はVo.1～Vol.3をすべて買っていたりするのだが、やはり新しいもののほうが最近の傾向に近い。ピンポイントでVol.3だけをやるのでも良いだろう。より新しいものがでていれば、そっちだけでも良いと思われる。この模試でとれた点数は、本番でとれる点数と大体同じくらいであった。平日は緑本や基礎文法、基礎単語の復習をしつつ、週末ごとに模試をやるというペースで進めた。

以上がTOEIC対策のすべてである。当然ながら、TOEICではLISTENINGとREADINGしか養われないので、WRINTING、SPEAKINGは別途対応が必要だ。「英語の敬語」や「会社で使う英語スキルアップゼミ」などを読んで過ごす日々だったりするが、もうそろそろ子供が生まれるのでタイムアップである。。。。

WILLCOM 03

Neons — 2008-05-27T01:46:34+09:00

D4延期という悪材料を先に出しておいてから、満を持してのWILLCOM 03発表が行われた。

....が、再びW-OAM TypeGは非対応、、、、せめてFelica対応までしてくれれば、ケータイの集約も図れたんだけど。
スタイラスペンもこの写真を見る限りでは、アドエスから変化なし。

うーん、将来の100Mbpsより、今すぐの800kbpsのほうがうれしいんですがねぇ。
一旦解約かな。