GoogleとNetflixがオープンソースのカナリア分析ツールを共同開発、プロダクションレベルの問題発掘を目指す

【抄訳】
GoogleとNetflixが今日(米国時間4/10)、Netflixが内製したカナリア分析ツールを一般公開することになるオープンソースのプロジェクトKayentaのローンチを発表した。Kayentaは、Netflixで育った継続的デリバリのプラットホームSpinnakerに統合されており、それはパブリックかプライベートかを問わずほとんどすべてのクラウドで使える。今回のリリースはSpinnakerにフォーカスがあるが、しかしKayentaはそのほかの環境にも適応させられる。

カナリア分析は、概念としては単純明快である。その名前が示しているように、サービスやインフラストラクチャを展開またはアップデートしたときの大きな問題を防ぐための早期警戒システムだ。展開やアップデートの対象をユーザーやサーバーやネットワークの一部に絞って行うテスト的実施で、カナリア分析は新しいシステムの振る舞いが正しいこと、あるいは前と変わらないことをチェックする。各ステップでシステムはチェックを実行し、その展開やアップデートが、通常のテストでは問題ないが、もっと複雑なプロダクションシステムに投じられたときにも問題が生じないことを、それら各ステップで確証していく。

GoogleのプロダクトマネージャーAndrew Phillipsによると、すでにそれをやっているデベロッパーは多いけれども、しかしそれはしばしば、非公式に行われている。チームがアプリケーションをビルドすると、いくつかのサーバーにデプロイしてみて数分動かし、ダッシュボードに異状が出ていないかチェックする。そんなやり方は人的エラーにつながりやすいし、偏りもありうる。それに対してカナリア分析ツールは、いくつかの測度の値を求めて、そのコードの完成度を客観的に判定する。コードのテストは多くの企業が自動化しているが、その種のテストではコードをプロダクションに投じたときに起きる問題を捉えられないことが多い。とくにそのプロダクション環境がマイクロサービスの集合から成り、それらが予期せざる対話をし始めたような場合には、お手上げとなる。

【後略】
〔以下、技術的な話題よりも、G社N社共同開発の経緯が中心。〕

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

子どもたちにプログラミングを教えるTynkerが、これからはロボットやドローンなどのデバイスも教材に

tynker-drone-training-puzzle

子どもたちにゲームを作らせながらプログラミングを教えるTynkerが、今度はゲームを作るだけでなく、デバイスをコントロールするプログラミングの教程を加えた。デバイスは、ドローンやロボット、照明器具のような“スマートホーム”製品など、さまざまだ。同社はこの新しい教育課程を、今週サンマテオで行われたBay Area Maker Faireで発表し、またiPadとAndroidタブレットのアプリケーションの提供も開始する。

同社はこれまで、子どもたちがドラッグ&ドロップでキャラクターを動かしながらプレイするゲームを作り、それによってプログラミングの基本概念を習得するための、ツールやチュートリアルを主に作ってきた

過去3年間で、Tynkerでプログラミングを始めた子どもたちは2300万名を超え、合衆国とカナダとイギリスとオーストラリアで計2万あまりの学校が同社のカリキュラムを利用している。各月に100万から200万のユーザがTynkerにログインし、同社のユーザベースは1か月に50万ずつ増加している。

同社のiPadアプリはAppleのストアの展示商品にプレロードされていて、子どもたちが遊べるようになっている。Androidのアプリも、Googleの今度のDesigned for Familiesでローンチする。CEOのKrishna Vedatiによると、今年の同社の決算は黒字になりそうだ。

これからは“物のインターネット”へのプログラミングが加わるので、子どもたちはこれまでのように純粋にソフトウェアだけのプログラミングではなく、ドローンを飛ばせたり玩具をコントロールしたり、ロボットに命令するなど現実世界のオブジェクトの制御を体験することになる。立ち上げにあたってTynkerが協力を求めるのは、ドローンのParrotやロボットのSphero、照明システムHue/LuxのPhilips、などの企業だ。協力企業は今後さらに増える、と同社は言っている。

tynker-sphero-training-puzzle-clue

子どもたちがTynkerのビジュアルなインタフェイスから、これらのオブジェクトをコントロールするプログラムを作れるために、新たなコードブロックが導入され、いくつかのサンプルコード的なテンプレートも提供される。たとえば”Flappy Drone”は、ドローンを障害物をよけながら飛ばせるプログラミングの例だ。人気のモバイルゲーム”Flappy Bird”に似ているので、この名前がつけられている。このほか、ロボットのレーシングゲームRobo Race、ドローンに曲芸飛行をやらせるStunt Pilot、インターネットに接続されている照明システムのコントロール、などが用意されている。

Vedatiによると今後Tynkerは、もっと多くの機種のドローンや、リモートコントロール玩具などをサポートし、AppleのApple HomeKitやParrotのFlower Powerなどとも統合し、またLegoやArduino、Raspberry Piなどのためのシンプルなプログラミングインタフェイスも提供して行く。

新たなコードブロックと学習用のパズルは、Google PlayiTunesで入手できる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

プログラミングは言語能力の一種、読む・書くがその基盤、と信ずる子ども向けプログラミング教室Bitsbox

Bitsboxの協同ファウンダScott Liningerがプログラミングをおぼえたのは、子どものとき両親が買ってくれたTRS-80だった。彼はこのコンピュータについていた本からプログラムのコードをコピーして、実際に自分の手でコードを書く(タイプする)プログラミングをおぼえた。今、自分が子どもの親になったLiningerは、娘に、自分の手で実際にコードを書く体験を伴うプログラミングをやらせたい、と考えた。しかし、今Webに多数登場しているサービスや教材(and玩具ふう教材)はどれも、このかんじんのフィジカルな体験を欠いていた。

Liningerは曰く、“子ども用のプログラミング学習製品は、どれもすばらしいけど、ああゆうドラッグ&ドロップ方式のツールは、プログラミング言語の文法やシンタックスや構造を教えない。でもたとえば、ドイツ語で何かを書きたいと思ったら、ドイツ語のルールを理解しなければならない。そしてドイツ語で何でも書けるようになるためには、自分でたくさん書いて練習することが唯一の道だ。プログラミングでも、実際にコードをたくさん書く経験をしなくちゃ、上達しないよ”。

彼は半年前まで、GoogleのSketchUp部門で働くエンジニアだった。彼自身も、自分のスタートアップを2007年に売ってGoogleに入社した。

自分の娘へのプログラミングの教え方について、かつてのGoogleの同僚などにいろいろ相談したところ、全員が彼と同じ体験をしていた。実際に、コードをタイプすること。“今30歳以上のプログラマは誰も、ブロックをドラッグしてプログラミングをおぼえてなんかいない。子どもたちにも、コードをタイプさせるのが最良の方法だと思う”、とLiningerは語る。

ただし、コードをタイプすることが楽しくなければ、だめだ。そこで彼は、Bitsboxを構想した。

“最大の敵は、難しいことではない。退屈なことだ。子どもたちは、難しいことには関心を持つ。でも退屈なことからは、さっさと逃げる”、とLiningerは言う。

彼のBitsboxのサイトは立ち上げてからまだ3週間だが、すでに登録ユーザ数はおよそ7万、彼らがWeb上でコードを書いた時間は28万分(一人平均4分)、日数換算で194日にもなる。

Code.orgからのトラフィックが多いが、それは、そこでBitsboxが推奨されているからだ。Bitboxのサイトにアクセスすると子どもたちには仮想タブレットが与えられ、JavaScriptで簡単なアプリケーションやゲームを書いていく。

Liningerによると、Bitboxが使っている軽量なプログラミングAPIは、いわばアメリカの小学生の読本の古典的定番”Dick and Jane”のプログラミングバージョンだ。この読本の古典は、短い、書きやすいフレーズを繰り返しながら、子どもたちが読み書きをおぼえるように誘導する。

作った(書いた)ゲームは、QRコードをスキャンして自分のタブレットやスマートフォン(iOSとAndroid)にインストールできる。実はそれはHTML5のアプリなので、ブラウザのあるデバイスなら何でもよい。ゲームの内容は、泡を出す、車でドライブする、エイリアンを空から撃ち落とすなど、簡単なものばかりだ。

来週Bitsboxは、Kickstarter上で資金募集のためのキャンペーンを開始する。今のWebサイトは無料だが、会員制の有料バージョンを作って、それを収益源にしたいのだ。この有料バージョンの開発には、同じくGoogleでSketchUpにいたAidan Chopraが協力してくれる。

有料会員に毎月届くボックスには、10数本ぶんののアプリケーションの書かれた本とトレカが入っている。子どもは自分が作りたいアプリケーションを選んでから、Webへ行き、コードをタイプして、画面上の仮想タブレットでそのコードを実行する。次は、そのアプリケーションを自分のデバイスへ送ったり、ソーシャルメディアで共有したりする。

このボックスは、すでに150名ぐらいの子どもたちでテストし、本番ローンチのためにKickstarterで4万5000ドルを募る。その資金プラス、ボウルダー(コロラド州)のアクセラレータBoomtownへの参加により、来年4月からボックスの発売を開始する。

ボックスは毎月30ドルで、水泳やダンスなどの教室の月謝とあまり変わらない。会員にはならないがボックスを見てみたいという人は、Kickstarterで40ドルを支援するとよい。

対象年齢は7〜11歳、毎月新しくておもしろいプログラムを作れる(書ける)ようにして、子どもたちが飽きずに継続することを促す。

プログラミングも言語能力だから、小さい子どものころから始めた方が身につく、とチームは信じている。しかも現代ではそれは、特定の外国語を勉強するよりも普遍的に重要な言語能力だろう。

“昔から、読み書きの嫌いな子でも、なんとかして読み書きを教えてきた。結果的に、大人になれば誰もが読んだり書いたりできる。今はそれと同じで、プログラミングの読み書きも、親は少なくとも自分の子がその学習機会に触れるだけのことは、してあげるべきだ、子どもを小学校へ入れるのと同じように”、とLiningerは言う。

関心を持たれた方は、誰でもBitsboxのユーザになれる。そして来週は、Kickstarterのプロジェクトのご案内が表示されるだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Apple、WatchKitを公開。デベロッパーはウェアラブル向け開発が可能に


Appleは、来年発売予定のスマートウォッチ用プラットフォーム、WatchKitを公開した。Apple Watchでは、時計と接続したiPhone内にWatchKitエクステンションを持ち、Watch自身にはUIエレメントを保存しているアプリが、発売時点でサポートされる。主要な作業はiPhoneが行い、出力(通知等)やユーザーからの入力(タップその他のアクション)はApple Watchが受け持つ。

興味のあるデベロッパーは、Xcode 6.2 beta、およびWatchKitを含むiOS 8.2 SDKを入手する必要がある他、iPhoneで使うWatchKitエクステンションを開発するためには、iOS 8.2 betaも必要になる。

同時にAppleは、同社のウェアラブル用ソフトウェアを作る人たちのためのデザイン・ガイドラインおよびヒューマンインターフェース・ガイドラインも提供した。そこには、様々な種類のインターフェースに向けた提案やテンプレート、Apple Watchの新しい独自のバブルベースメニューのためのホーム画面用アイコンを作る際のヒント、サイズとレイアウトスタイルの提案、フォントやテキストサイズに関するヒントなどが書かれている。Apple Watchは全く新しいカテゴリーの商品なので、この上に作られるアプリで使われるデザイン言語は、スマートフォンやタブレットで使われていたものとは大きく異なる。

WatchKitアプリの主要コンポーネントには、高度な機能のためのUI一式、ソフトウェアで起きていることに関する情報を一目で見られる “Glances”、メッセージにすばやく返信したり接続したスマートフォン端末を制御するための、アクション可能な通知等が含まれている。

大量の処理要求がiPhoneに向けられることになるのは興味深いが、Apple Watchのバッテリー消費を極力抑えるためには理にかなったやり方だ。これがApple Watchの自主性にどう影響するのかを知るにはまだ情報が足りないが、Appleは、接続したデバイスとは別にApple PayにWatchを使う方法を検討してるので、Watchアプリが何らかのオフライン機能を持つと思われる。

[原文へ]

(翻訳:Nob Takahashi / facebook


GoogleがAndroidソフトウェア開発の無料学習コースを提供、Udacityから

Googleがオンライン学習のUdacityと提携して、無料のAndroidソフトウェア開発コースを提供する。ビデオのほかに、小テストや教材、それにフォーラムも提供される。このコースは”Developing Android Apps: Android Fundamentals”(Androidのアプリ開発: Androidの基礎)と呼ばれ、Androidアプリを作るために必要なもののすべてを、一歩ずつ教えていく。ただし学習者は、プログラミングに関する基礎的な理解をすでに持っている必要がある。

このAndroidコースは、GoogleのDeveloper Advocates〔仮訳: デベロッパヘルパー〕 Reto Meier、Dan Galpin、およびKatherine Kuanが担当し、またフィードバックへの個人的な対応や直接指導が、Udacityの有料コースをすでに受講している先生生徒間で行われる。この事業の目的はまず、Androidの歴史や成り立ちを学んでAndroidをよく知ること、そして過去のプログラミング経験等ではなく、Androidの具体的な知識をベースとしてプログラミングを発想/書けることを目的として、Androidソフトウェアの作り方を教える。

Googleの当然のねらいは、Androidのソフトウェアを作るデベロッパの増員だ。先月行われたGoogle I/Oでの発表が正しければ、今やAndroidはありとあらゆるものを動かすOSになりつつある。だから、Androidで考え、Androidで書くことのできるデベロッパを増やすことは、今後のAndroidの、自動車、テレビ、ウェアラブルなどへの実装が、広い消費者層に普及していくために欠かせない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Android vs. iOS, アプリはどっちから先に作る/売り出すべきか

“AndroidとiOS、どっちを先にやるか?”という、スタートアップにとって永遠の問いは、ますます難問になってきた。Androidのマーケットシェアが80%を超えた、というニュースがあったからだ。でも、経営者や非技術系のファウンダはさておき、かんじんのデベロッパ! デベロッパ!は、この対立をどう考えているのか? どちらが、デベロッパの人生にとって有利か?

実はぼくも、デベロッパの一人だ。本誌の記事(や小説)を書いていないときは、ぼくはHappyFunCorpのソフトウェアエンジニアだ。世界でもっとも良い名前のコンサルタント企業であり、Webサイトだ(クリックしてみて)。最近は管理職的な仕事が多くなっているが、プログラミングを忘れたくないので、ちょっとした個人的なプロジェクトをAndroid用とiOS用両方を作って、それをオープンソースにした。以下はそのときの経験に基づく、両プラットホームの比較論だ。

ぼく自身の経歴としては、これまで数多くのAndroidアプリとiOSアプリを作ってきた。仕事と、個人的なプロジェクトの両方だ。たとえば、ぼくの好きなニュースアグリゲータScanvine用に作ったネイティブクライアントは、ソーシャルメディア上で異様に広く共有されている記事を見つける。そのソースコードはGithubにあり: (Android | iOS) 、アプリ本体もダウンロードできる: (Google Play | App Store)。

比較論を始める前に、Xamarinのクロスプラットホームな開発ツールに言及しておくべきだろう。ぼく自身も、もしも自分がC#プログラマで、JavaやObjective-Cを知らない人間だったら、モバイルアプリの開発のためには、これを選んでいたと思う。

それにまた、今回のプロジェクトは、商用製品ではなくて、個人的に楽しむためのプログラミングだ。だから、テスト用のコードがない。だからiOSのハイゼンバグは、今でも手作業で調べている。サードパーティのライブラリも、gitのサブモジュールにせずに、ファイルをコピペしている。今は直したけど、Androidのビルドでレイアウトファイルにバグがあって、タブレットがクラッシュしたこともある。

では、前置きはこれぐらいにして、二頭の馬たちのゲートを開こう。さあ、走れ!

環境

コードをテキストファイルに書いて、コマンドラインでビルドすることは、今でも可能だがしかし統合開発環境(integrated development environment, IDE)を使った方が生産性は高い。

AppleはXcodeだ。使っていて楽しいし、すっきりしてるし(ごたごたの逆)、速いし、強力だし、出しゃばらないヘルプが良い。AppleはiOSのアプリやデバイスを厳しく管理するために、奇妙で独特なコンパイラと、被害妄想的な証明/プロファイリングの仕組みを持っているが、それらはXcodeの快適な外見の下に隠されている。デバッガはシームレスだし、シミュレータは速くて応答性が良い。

Androidは、ほぼ標準のIDEがEclipse + Androidプラグインだが、こいつが厄介者だ。遅い、ぎくしゃくしている、分かりにくい、そしてときにはまったく不可解。レイアウトが悪い、不必要に複雑、そして混乱。デバッガーがドジなので、ぼくはログファイルを見ながらデバッグをしている。Xcodeのデバッガは、まさに、頼りになるデバッガだ。Androidのエミュレータもひどくて、立ち上げに数分かかるし、Android Debug Bridgeに接続できないことが、とても多い。

ツイート訳: [Androidの仮想デバイスを使って開発している人なんかいるの? なんで、立ち上げに10分もかかるんだよ?]

そこでGoogleは、独自のIDE Android Studioを提供するつもりでいるが、しかし:

Android Studioは現在、初期的なプレビューバージョン(early access preview)です。まだ不完全な機能や未実装の機能があり、バグもあります。未完成の製品を使いたくない方は、代わりにADT Bundle(Eclipse + ADTプラグイン)をお使いください。

GoogleがAndroid Studioを鋭意開発中なのはよろしいが、ぼくが最初のAndroid携帯を買ってからほぼ5年になるのに、まともな開発環境がまだないとは、どーゆーこっちゃ?

勝者: 大差でiOS。


構成

上で述べたように、Xcodeの外見はすっきりシームレスだが、その下にはObjective-Cという、70年代のプログラミングの恐怖を彷彿とさせる怪獣が眠っている。おおげさかもしれないが、そう言いたくなる。マクロ、ヘッダファイル、プロジェクト、ターゲット、スキーム、そしてビルドのコンフィギュレーション(構成)。ビルドの設定だけでも、うんざりしてくる。不可解なリンカエラーが出ると、絶望あるのみ。そして、こんな発見: “あら、きみのサードパーティコードはARCをサポートしていないの? じゃあフラグ-fno-objc-arcを加えるんだよ。簡単だろ?”。

Androidではマニフェストファイルが一つあるだけで、アプリのビルドはEclipse が完全にやってくれる(正常時は)。ファイルを保存したらビルドは自動的に行われる。パーミッションの構成ミスでアプリが動かないときに出るエラーメッセージは、もっと分かりやすくしてほしいが、それはそんなに重大な問題ではない。とにかく、ビルドのための構成はAndroidの方が概してシンプル、そしてエレガントだ。

勝者: Android。


UXデザイン

勝者は当然Apple、とみなさんお思いだろう。Interface Builderを使うと、きれいなユーザインタフェイスを簡単に手早く指定できる。でもぼく的には、Interface Builderを使えば使うほど、嫌いになった。ここでもまた、構成が面倒なのだ。最初は単純で楽ちんでも、その後のアプリの進化とともに、世界はぐちゃぐちゃになっていく。とくに、Appleが1年前に加えた、マルチスクリーンのStoryboardsは、すごーく、好きくないね。

Androidのビジュアルツールもまあまあだが、それについて、あまり言うべきことはない。なにしろAndroidは製品の種類が多様で画面サイズもまちまちだから、UIをそのすべてに正しく対応させるために、レイアウトの指定をXMLファイルで書く(AppleのAuto Layoutも、今後のiOS製品の画面の多様さに対応するための仕掛けだろう)。なお、Androidではアイコンパックが提供されているが、iOSではIcons8のようなサードパーティ製品を使うか、または自作する。

意外にも‘Apple圧勝’とはいかなかった。ちょっと奇妙な結果ではある。しかし、iOSは幸運にも製品種類がとても少ないから、デベロッパの苦労も少ない。それにiOSのデフォルトのUI部品は、デザインがおおむね美しい。この二点で、iOSが有利だ。

勝者: iOS。


言語

AndroidのアプリはJavaで書く。iOSのアプリはObjective-Cで書く。その例外は、Xamarin(前述)を使うとき。ただしツールによってはマイナーな例外があるし、PhoneGapのようなネイティブ/Webのハイブリッドもある。しかし一般的には、AndroidはJava、iOSはObjective-Cでネイティブアプリを書く。

ぼくがプログラミングをやり始めたときの言語がJavaだったから、最初はObjective-Cに馴染めなかった。とくに、書く量が多すぎる、と思った。

Javaなら:
String s2 = s1.replace(“abc”,”xyz”);

Objective-Cでは:
NSString *s2 = [s1 stringByReplacingOccurrencesOfString:@"abc" withString:@"xyz"];

でも、その後だんだんとObjective-Cが大好きになった。Javaよりもクリーンな、良い言語だ。Objective-Cにはブロックブロック構文〕があり、Javaにはない。Objective-Cにはカテゴリーカテゴリ〕があり、Javaにはない。Javaでは大量の例外処理(try/catch節)を義務的に書かなければならないが、Objective-Cにはそれがない。

Javaにも、良い点はある。たとえばスタックトレースが良くできているので、散発的な(起きたり起きなかったりする)バグの原因を見つけやすい。2年前までは、ガーベッジコレクションではAndroidが断然優位だった。今ではiOSにautomatic reference counting(ARC(前述))があるので、Javaの優位は薄れた(ただし古いサードパーティのツールはARCをサポートしていないのでXCodeの構成で苦労しないといけない)。この点でJavaの優位はなくなったので、勝者はObjective-Cで決まりだ。

勝者: iOS.


API

AndroidもiOSもライブラリの規模は大きく、その内容は互いに似ている。電話機能、ネットワークアクセス、多様なViewオブジェクト…その中にはブラウザそのものとも言える強力なWebViewがある。実際の仕事は、コントローラの中で行う…iOSではViewController、AndroidではActivity。

iOSにあってAndroidにないものは、一連の機能集、フレームワークだ。たとえばiOSの強力なCore Dataフレームワークに相当するものは、Androidにない。またiOSのAPIの方がよりクリーンでありシステムとしての設計も良い。ぼくのアプリでは、iOSの場合、これこれ、二つのかなりシンプルなクラスが仕事の大半を行うが、Androidではこれこれこれ、計三つのクラスが同じことをする。そしてこれらは、10個近い内部クラスや無名クラスを使用している。結局のところ、iOSのCollectionViewControllerの方がAndroidのListAdapterよりも使いやすい。

あまり客観性はないが、ぼくのこのアプリの自作コードはiOS版が1596行、Android版が2109行だ(Java + XML)。32%もの差がある。

勝者: iOS.


インターネット

今ではほとんどのアプリが、スタンドアロンのプログラムではなく、多かれ少なかれインターネットに依存している。だからここでは、それほどまでに重要なインターネット機能を比較しよう。インターネットに関して、ツールやAPIは両プラットホームとも、たいへん多い。どちらも、互いによく似たWebViewsがあるので、どのアプリにも完全なブラウザウィンドウを置くことができる。

ネットワークへの接続は基本的にバックグラウンドで動く処理であり、アプリの本流の邪魔をしない。しかし、このようなマルチスレディング(multithreading, 処理の多重化並列化)は難しい。Androidが提供しているAsyncTaskクラスは、大きいが良い仕事をする。今オンラインかどうかをとても容易に判定できるための、便利な方法もある。iOSにも同様の機能はあるが、どれもかなり低レベルで、不満足なものだ。

しかしながら、オープンソースのライブラリがたくさんあるから、それらを使えば苦労はない。ぼくはAFNetworkingを使ったが、作者が言ってるとおりの、良質なフレームワークだ。Webのリクエストが完了したら動かしてほしいコードのブロックを、渡すだけだ。ブロック構文(前述)のないJavaでは、それはできない。

勝者: ネイティブではAndroid、サードパーティのライブラリも含めるとiOS。


共有

アプリから容易にFacebookやTwitterやEvernoteなどで共有できるか? AndroidにはIntentという強力なアプリ間コミュニケーションシステムが前からあるから、第一ラウンドでAndroidのノックアウト勝ちだ、とぼくは思った。一般的に言っても、複数のアプリ間のデータ共有機能は、Androidの方が優れている。

でも、きわめてふつうの共有機能では、Appleもかなり追いついている。というか、これは読者ご自身が判断していただきたい。ぼくのアプリScanvineの、Androidの共有コードはこれ、iOSのコードはこれだ。iOSのコードがやや長いのは、Google Analyticsでちょっと余計なことをしているためだ。こいつは、直したい。

勝者: 引き分け。


分裂

こいつは、簡単。AndroidはこうiOSはこう。証明終。Googleがおもしろい統一策を実装中だから、この話題は再訪の価値があるかもしれない。

勝者: iOS.


発表

Androidアプリは、世の中に発表することが、うそみたいにやさしい。Eclipseには便利なアプリ登録ウィザードがある。どのデバイスでも動くAPKファイルを、あなたは作った(はず)。それを、メールしてもよい、Webサイトに載せてもよい、Google Playにアップロードしたらたちまち、全世界があなたの市場になる。最高にシンプルだ。インストール時のログデータとクラッシュ報告を見る。スタックトレースを見れば、問題のコードがどこか分かる。すぐにバグフィクスして再びアップロードすればよい。

Appleのアプリは、発表が悪夢だ。頭の良いぼくの友人は、iOSアプリを開発するときは通常のスケジュールに最低でも1日足せ、とアドバイスする。証明とか配布プロファイルと苦戦するための時間だ。何度やっても、それにXCodeの最新バージョンがどんなにそのための努力をしていても、それはつねに、でっかい苦労だ。TestFlightがあるから、ややましだが、アプリのテストも厳しい。そしてAppleの”iTunes Connect”WebサイトとGoogle PlayのDeveloper Console(デベロッパコンソール)は、Ford Pinto vs. Teslaだ。クラッシュレポートがもらえたら、ついてる方。だいたい、ろくな情報は得られない。彼らの、デベロッパに対する恣意的な態度は、こうなったら楽しむしかない。そしてAppleのUXのひどさに、感嘆するのだ。

勝者: 大差でAndroid。


そして優勝は…

僅差でiOSだ。Androidにも良い点はあるが、良いiOSアプリを書くことと、良いAndroidアプリを書くことを比べると、前者の方が相当にやさしい。今でも。それにAndroidユーザはお金持ちで周囲への影響力もあるから、大ウケをねらうスタートアップは、最初にiOS、Androidは後で、で行くのが理にかなっている。Android Studio IDEは、差をやや縮めるかもしれないが、まだ横並びにはならないだろう。

(なお、ぼくの日常のメインの携帯はNexus 4だ。しかも、すごく満足している。)

画像クレジット: Jennifer Stolzer, DeviantArt

〔訳注: この記事はコメントが166もあり(日本時間11月19日18時現在)、参考になるコメントも多いので、この記事をより相対的に読むためにはコメントも読むことをおすすめします(Twitter上の関連ツイートは961件あります)。以下に、今はEclipseじゃなくてIntellij、という正論を書いていると思われるコメントを一つだけ訳出(抄訳)しておきます(GoogleのAndroid StudioはIntellij(の無料版)がベースです)。〕

<コメント訳開始>
ちょいと、こいつは露骨に偏った記事だよ。詳しく書いてる時間がないから、Eclipseが標準IDE説を、ここでは取り上げよう。前からJavaをやってる人なら、Intellijを知ってるだろう(Android Studioはまだバグが多くてだめだけど)。GoogleがEclipseを見捨てたのも、当然だ。Androidデベロッパも、だいぶ前から、すでにIntellijを使ってる人が多い。また、エミュレータはとっくに誰も使っていない。あまりにも、ひどいから。今はほとんどの人が、デバイスそのもの、またはx86エミュレータ、またはGenymotionなどを使っている。今更一体誰がSamsung Realityなんか検討するの?
【後略】— from kpgalligan
<コメント訳終了>

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


中小キャリアとOEMにアプリvs.デバイスの網羅的テストを提供するApkudoがデベロッパツールを無料で提供

ボルチモアのApkudoが今週、“Apkudo Approved”(Apkudo公認)という事業を立ち上げ、AndroidアプリとAndroidデバイスの相性をより良くするという同社のこれまでのサービスを一層強化することになった。同社の、デベロッパとデバイス、あるいはデバイスとキャリアの仲立ちをするという役割は、それ自身が成長市場だ。つまり同社は、Androidのハードウェア市場の、分裂した、ときには迷路のようでもある地形を、上記二者がより歩きやすくなるようにしてくれるのだ。

Tier-1キャリア(最大手元締キャリア, MNO)は通常、発売前のデバイスに対して徹底的なテストをする。BlackBerryは最近、BlackBerry 10の発売にあたってそのテストのことを一般に公開したが、でもそれは、すべてのキャリアがすべてのデバイスに関してやっていることだ。Apkudoはそのようなテストを、Tier-2以下のキャリア(MVNOなど)にサービスとして提供する。小規模キャリアは、徹底的なデバイステストを行えるだけのリソースがないことが多いからだ。

Apkudoが行うテストには、キャリアのデベロッパパートナーから提供される2万も3万もあるアプリを動かして、そのパフォーマンスをチェックすることが含まれる。CEOのJosh Matthewsによると、その具体的な作業は、短い時間間隔で撮った画面の連続写真を調べてコマ落ちを見つけるといった、細かい作業の積み重ねだ。これまでテストして結果を提供できたデバイスは1700あまり、それらのOEMの名は明かせないが、だいたいわれわれが名前を知っている今現役のスマートフォンなら、どれも同社のテスト対象になっているそうだ。

“Androidデバイスは価格も仕様もピンからキリまであるが、高機能な製品を安く提供できることはキャリアのマーケティングにおける重要な武器なのだ”、とMatthewsは説明する。“しかし機種間の質の違いが大きいために、アプリのパフォーマンスには大差が生ずることもある。それが、非常に高い返品率と顧客の不満の原因になる”。

Apkudoのサービスによってキャリアは、ハードウェアを消費者に提供する前にハードウェアの隠されたデータを自分で知ることができる。だから中小のキャリアは、デバイスを細部まで調べたことの証拠として、これから検討するデバイスが“Apkudo Approved”であることを求めるのだ。そのことはもちろん、Apkudoにとっても大きな利益になる。しかし同社は、もう一つの顔をOEMたちに向けて、彼らにもデバイスの正しいアップグレードのための重要なテストデータを提供している。

Matthewsによると、同社はモバイルデバイスのアプリテストというレアな業態であるため、技術的には優位である。毎日々々来る日も来る日もデバイスとソフトウェアの突き合わせをやっているのだから、どのキャリアよりも、どのOEMメーカーよりも、彼らの強みや弱みを判定する能力が高いのだ。立場が、いかなるキャリア〜OEMに対しても中立であることでも、同社は有利だ。

目下Apkudoの年商は500万ドルほどだが、顧客の中にはCricket、Cincinnati Bell、Associated Carrier Group(C Spire、Alltelなどの小規模キャリアの団体)といった強力な面々がいる。同社のデベロッパ製品は無料だが、それは、これまで作ってきたライブラリによって同社が、キャリアとの十分に儲かる関係をすでに構築しているからだ。だからAndroidデベロッパが一連のデバイスで自分のアプリをテストしなければならないときには、自分でハードウェアを集めて苦労するよりも、Apkudoのツールを使った方が楽かもしれない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


モバイルプラットホームの分裂はインディーのアプリデベロッパを殺すだろうか?–開発環境の成熟が彼らを救う

Image (1) fragmentation.jpg for post 157569

今日(米国時間3/5)Flurry発表した調査報告書によると、アプリを世の中で使われている多くのモバイル製品に合わせて最適化することは、今やますます難しい仕事になっている。Flurryのデータによると、現用製品の80%で自分のアプリが無事動いてほしいと思ったら、156種類の機種に対応しなければならない。目標を60%まで下げれば、37機種となる*。Flurryの結論によると、このような分裂の激化により、とくにインディーのアプリデベロッパの市場参入が難しくなっている。

この分裂という問題が、なくなるとか、軽症になることはありえないだろう。とくにデバイスのメーカーは製品の多様化に走りがちだ(PadFoneやFonePadなんてものもいずれ…)。Appleでさえ、画面サイズや解像度は次第に多様化し、アプリ開発がより難しくなっている。まあ、OSのバージョンが同じであることに安心できないAndroidに比べれば、ずっとましだけど。

area_chart_1_V2

それでも、Flurryの数字によると、現用機の数が他を圧して多いのはApple製品だ。だから個人や小企業が、あまり苦労せずにすむ最大のユーザのいる市場からスタートしようと考えたら、iOSで決まりだ。しかしその後、真のグローバル化、グローバルな成功を目指したなら、できるだけ多くのAndroid機でテストしアプリの調整をしなければならない。しかもAndroidの場合は、機種間の差異がどれだけ大きくても、アプリのマーケットプレースやリビューは同じ場所に集まっている。ある特定の製品のユーザグループを怒らせたら、リビューに悪評が混じることになり、悪評はたちまちネット上に広まる。

だから、どうなんだ? 複数の製品で十分なテストをしてリーチを広げるだけの資力のないインディーのデベロッパは死ね、ということか? 答は、イエス、そしてノーだ。スタートアップやインディーのデベロッパがアプリの世界で成功する機会は、まだまだたくさんある。とりわけAppleは、大手のデベロッパだけでなく、斬新で革新的な作品をApp Storeで優遇してくれる。またそういうアプリは、あちこちのブログなどで記事になりやすい。ときおり、無名の企業や個人による優れた作品に光を当てることは、Appleというプラットホームの健康にも寄与する。

アプリ開発の風土が変わったことによって、中位置に付けているデベロッパが有利になったと言える。彼らは最新のクロスプラットホーム開発ツールから多くを学び、また、Facebook6WunderkinderBrightcoveなどが最近学んだ教訓…Webアプリよりもネイティブアプリの方が良い場合が多い…にも配慮する。分裂状態に対応するアプリの試験は今、それ専門のSaaSが現れつつある。それだけ、デベロッパのニーズが増え、また今および今後は、テストツールやAPIのプロバイダからもそんな専門サービスへのニーズがある。さらにまた、インディーデベロッパのアイデアを導入して、クロスプラットホームな成功作品を作るというデベロッパサービスも、今後ますます流行(はや)るだろう。

〔*訳注: Flurryのオリジナルのレポートでもこの点は曖昧ですが、この156機種とか37機種という数値は単純にボリューム構成(例: 200品目ある某レストランの売り上げの60%は上位10品目が占める、など)であり、実際に必要なアプリ調整作業の件数は156や37よりもずっと少ない、と思われます。原文のコメントに見られるデベロッパの意見も、Androidの分裂をそれほど深刻視していません。〕

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))