Developers | SEO-LPO.net

Microsoftのモバイルプラットフォームに対するデベロッパーの興味は減少中

マルチプラットフォーム開発を支援する会社、Appceleratorが今日（米国時間9/26）四半期調査レポートを公開した。このレポートは様々なプラットフォームに対する市場の関心度を知り、トレンドの変化を探るのに役立つ。

第3四半期レポートには、Microsoftの苦しい市場ポジションが詳しく説明されている。回答者（デベロッパー、CIO等）の中で、Microsoftのスマートフォンおよびタブレット用にアプリを開発することに「非常に興味がある」と答えた人の割合は少なかった。25%がMicrosoftのタブレットのために開発することに興味があると答え、同スマートフォンに関しては26%だった。

CiteWorldによると、これらの数字は年初と比べて数ポイント下がっている。新しいプラットフォームが成熟してきたにもかかわらず、Microsoftは、Windows Phoneやタブレットに対するデベロッパーの興味を引くことができていない。

Microsoftが失った「非常に興味がある」のパーセンテージ（スマートフォンで3ポイント、タブレットで5ポイント）は、致命的ではないが正しい方向ではない。Microsoftはデベロッパープラットフォームを作ることにかけて長い歴史をもっている。そして今、Windows StoreやWindows Phone Storeを成功させるために全力を注いでいる。

ある意味で、彼らに選択肢はない。モバイル市場から徹退することはできないし、この分野で戦うためにはデベロッパーサポートが必須だ。

Microsoftにはしかし、隠し玉がある。The VergeのTom Warrenが
今日書いた記事によると、Microsoftは、WindowsとWindows Phoneのアプリストアを統合しようとしている。これは驚きではないが ― プラットフォーム自体の統合ならともかく ― 結構なことではある。別々よりも全体の方が大きい。統合されればデベロッパーにも働きかけやすくなる。

Microsoftの現CEO、Steve Ballmerは最近、この会社はモバイルデバイスの「シェアがほぼゼロ」であると発言した。Microsoftが消費者の世界で何らかの重要性を維持するためには、これを変える必要がある。また、Microsoftが他の市場セクターで生き残るためにもそのDNAは重要である、ということが過小評価されているのではないかと私は思っている。

他のデータをいくつか。回答者の6%がBlackBerryタブレット用の開発に「非常に興味がある」と答えた。iPhoneについてそう答えたのは80%で、Microsoftは両者の中間にいる。

トップ画像提供：Microsoft Sweden

[原文へ]

（翻訳：Nob Takahashi）

アメリカは、ソフトウェア開発大国の地位を失いつつあるのか?!

PC時代のソフトウェア産業というものは、モバイル時代のアプリケーション開発に当たるだろうか。そうだとすると、アメリカはPC時代の栄光を失いつつあるようだ。モバイル関連データ分析を行っているFlurryの最新データによると、モバイルアプリケーションの開発で、アメリカが世界をリードするという状況にはないようなのだ。モバイルアプリケーション開発国別のマーケットシェアを見ると、2011年時点でアメリカの占める割合が45%であったのが、2013年には36%に落ち込んでいる。ちなみにPC時代の2008年を振り返れば、販売されたソフトウェアの68%程度がアメリカ産という状況だった。ある意味で、モバイルアプリケーション産業というのは、真の国際化を実現しているのだとも言える。

但し、別の観点でみればアメリカのアプリケーション業界も相変わらず頑張っているという見方もある。すなわちエンゲージメントないし利用者数の観点から言えば、アメリカ発のアプリケーションが好成績をおさめているのだ。アプリケーションの利用時間や利用者数、利用頻度等を考えた場合は、アメリカ産アプリケーションが依然として牽引者としての立場を維持しているのだ。但し、こうした面を考慮にいれて計算した市場占有率も2011年の75%から、2013年には70%と低落傾向であることは間違いないようだ。

さらに、国別で考えると、また別の側面が見えてくる。すなわち、アメリカ国内で考えた場合は、全アプリケーション利用時間の59%が国内で生産されたアプリケーションによるものとなっている。中国でも国内発アプリケーションの比率が64%となる。一方でイギリスやブラジルをみると、国内産アプリケーションの率はそれぞれ13%および8%となるのだ。

中国での利用時間を見ると、アメリカ産アプリケーションの占める割合はわずか16%ということになる。中国のアプリケーション市場の規模は大きく、ますます成長していく傾向にある。それを考えるとアメリカ産アプリケーションの比率はますます下がっていくことになるだろうと、FlurryのSimon Khalafは書いている。

アメリカ産アプリケーションがシェアを失いつつあるらしいことの一因は、「ローカライズ」ということだろう。これまでは英語というのは世界中で使われているのだということに甘えてきた面があると思われる。英語利用国以外は、懸命にアプリケーションの各国語対応を考えてきた。フィンランドやデンマーク、ブルガリアやスロヴェニアに開発者たちは、おかげでローカライズの技術を積み上げることができたのだ。たとえばフィンランドのRovio（Angry Birds）、ロシアのZepto Labs（Cut the Rope）、そしてオーストラリアのHalf Brick Studios（Fruit Ninja）などのアメリカ外メーカーが、世界的なマーケットを獲得しているのは注目に値する。

ところで、アプリケーションの製作は比較的安価で行える。アプリケーションストアもあるのでグローバル化したものを販売しやすいという性質がある。但し、Flurryの調査によるとプロモーションにかかる費用が高騰しつつあるのだそうだ。Fiksuもアメリカ国内の調査を行って、2011年あたりと比べると、ユーザー獲得のための費用が高騰していると報告している。今年を見ても6月には1.50ドルだったものが、7月には1.80ドルになっている。2011年12月以来の最高値となっているそうだ。

Facebookのモバイルアプリケーション広告プラットフォームも、プロモーション費用の応答の一因となっているだろう。稼いでいる会社がますますプロモーションに力を入れ、すると弱小のところも対抗上プロモーション費用を用意しなければならなくなってくる。アプリケーションストアではビッグネームによる寡占状態に拍車がかかり、新参者がトップ250に入ることがますます難しくなってきている。アプリケーションマーケットの世界でも強者がすべてを獲得する（winnter-takes-all）仕組みが生じているわけだ。そしてどうやら、今回のFlurryの報告を見るに、勝者の多くはアメリカ発ではないようだ。

［原文へ］

（翻訳：Maeda, H）

Google Playの売上、ここ半年で67%アップ―日本と韓国の貢献が大

GoogleのAndroidアプリのマーケット、Google Playの売上が今年に入って急増している。特に日本と韓国で人気が高い。今日（米国時間8/12）、調査会社のDistimoが発表した新しい調査結果によれば、Google Playの売上は過去6ヵ月で 67%上昇したという。これに対し、AppleのApp Storeの売上は同期間に15%の上昇にとどまった。

この急増はAndroidが世界的に圧倒的なシェアを獲得したことを反映するものだが、アプリ業界を全体として見ると、AppleのApp Storeの市場シェアが依然として最大であり、売上もGoogle Playの2倍あるという。

ただし、App Storeの統計に関しては違う数字も報告されていた。ライバルの調査会社、App Annieが4月に発表したところでは、直前の四半期ではAppleのApp StoreはGoogle Playの2.6倍の売上があったという。ただし両者の調査方法には違いがある。Distimoの調査は、過去6ヶ月間で主要18カ国が対象であるのに対して、App Annieの調査は前述したように直前四半期だ。

いずれにせよ、Google Playの売上の伸びが急であることは間違いない。両プラットフォーム合計のうち、Google Playは今年2月には25%のシェアだったのに対して7月には8%ポイントも上昇して33%となった。

Google Playの急成長を支えたのは日本と韓国での人気

Google Playの売上の国別シェアのトップは依然アメリカだ。日本、韓国が2位と3位につけ、この3カ国がGoogle Playの売上の大半を占めている。この後に、イギリス、オーストラリア、ドイツ、フランス、ロシア、イタリーが続く。ひとつ興味あるのは、ロシアではApp Storeでの売上がiPhone向けよりiPad向けの方が多いという現象が起きている。

先月の売上トップのアプリを見ると、日本と韓国の貢献が顕著であることがはっきり分かる。King.comのCandy Crush Sagaが依然1位を占めるものの、2位は日本のパズル&ドラゴンズで、3位、5位は韓国のKakaoのアプリ、そして4位が日本のLINEとなっている。

一方、App Storeの売上げベストアプリはCandy Crush、Clash of Clans、Hay Day、パズル&ドラゴンズ、TheHobbit: Kingdoms of Middle-Earthとなっている。

有料アプリのトップランクを見ると、App StoreではWhatsAppが4位に入っているのを例外として残りはゲームが占めている。これに対してGoogle Playではゲームとユーティリティ（キーボード、バックアップ、ランチャー等）が混じっている。

トップ・パブリッシャーや無料アプリのランクなど詳しい情報はこちら。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）

モバイルアプリを”Web化”, ディープリンクの導入でQuixeyが標準技術AppURLを提唱

【抄訳】

モバイルアプリを検索するQuixeyが今日（米国時間8/2）、モバイルアプリにWebサイトのような機能を持たせるためのAppURLという規格を提唱した。個々のアプリがスタンドアローンで孤立するのではなく、あるアプリから別のアプリやコンテンツにナビゲートできる、という仕組みだ。ニュースアプリなら別の記事へ行けたり、Yelpのレストランリストなら関心あるレストランのアプリをインストール/立ち上げたり、ソーシャルアプリなら友だちのプロフィールに飛べたり…。

このようなコンセプトはディープリンク/ディープリンキングと呼ばれていて、かなり前からある。ディープリンクURLを作るCellogicのDeeplink.meのようなサービスも最近はある（モバイルアプリのディープリンクのためのbit.lyのようなサービスだ）。さらにその前には、iOSアプリのそれぞれ独自のURL方式をオープンソース化しようとするデータベースOneMillionAppSchemes.com（本当に100万種類もあるか！）や、アプリをリンクして複数の写真編集アプリを一か所で使っちゃおうというPhotoAppLinkなんかもあった（ちなみに私も個人的には、アプリのディープリンクには大賛成である）。

Quixeyの協同ファウンダでCEOのTomer Kaganも、“ディープリンクという考え方は必ずしも新しくはない”、と認める。“たとえばTwitterにはカードがある”。つまりTwitterが今力を入れているのは、一つのツイートを多面的なメディアにするための追加的なHTMLをWebページに置かせる、という方式だ。“ほかにも、いろんなサイトが独自の方式でディープリンクの拡大をねらっているが、モバイルアプリ上のそれは、やり方が統一・標準化されてもよいのではないか。この際、アプリ間に妙な格差ができないためにも”。

デベロッパコミュニティの取り組みに任せずにQuixeyという一企業が乗り出してきた理由についてKaganは、これまで誰も取り組まなかったし、放置されていた時間がもはや長すぎる、と言った。

“うちのCTOのLiron Shapiraと一緒に3年あまり前にQuixeyを始めたとき、すでにAppURLのようなコンセプトが二人の間で話題になっていた。‘そういうものがあればいいのにね’と二人で言っていた”。Kaganはそう説明するが、その実現のために動き出すことはなかった。そのうちできる、と考えていたからだ。“うちがやらなきゃ、ほかの誰もしない、とは当時は考えなかった”。

CelllogicのDeeplink.meの場合がそうだったように、AppURLの発想も、ほかの仕事がきっかけで生まれた。それは、同社のアプリ検索だ。今ではパートナーのAsk.comやMicrosoft、Sprint、NokiaなどがQuixeyをもとにそれぞれ独自のアプリ検索を提供しているが、Deeplink.meの場合と違ってQuixeyは、AppURLを自社のビジネスにする気はなかった。

“ディープリンクはモバイルアプリのエコシステム全体にとって重要だ。私企業が保有して収益源とすべきものではない”、とKaganは言う。そこでQuixeyは、AppURLがやっていることを一般公開して、デベロッパたちから今後寄せられるモアベターなアイデアに期待することにした。そうすれば、コミュニティの全員が同意する標準規格が出来上がるだろう。

そのやり方

AppURLのやり方は、三段階から成る:

1)アプリのデベロッパは自分のアプリ用のURL形式を選ぶ。

2)アプリがURLを扱う部分を書く。

3)appurl.jsonファイルをパブリッシュする（機械可読なドキュメンテーションで、アプリからHTTP Webへの接続方式を記述）。

それによって、システムがディープリンクを有効にし、検索エンジンがアプリ内リンクをクロールできるようになる。アプリ内にあるURLへのリクエストを検索エンジンからできたり、そこからの情報をインデクシングしたりする。（したがって、AppURLがスタンダートとして広く採用されれば、アプリ検索をメインのビジネスとするQuixeyにとっても、より良い検索ができることになる。）

【後略】
—-以下、リダイレクトの方法など—-

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

デベロッパ教育訓練企業もMicrosoft/Windows偏重から脱出して現代化未来化へ転身

プロのデベロッパに対する教育訓練のための各種リソースを提供するPluralsightは、今年の初めにInsight Venture Partnersからの2750万ドルの資金調達を発表したが、このほどそのお金を、実際に当初の目的どおりに使うことになった。MicrosoftやSalesforce、Twitter、Facebook、Dell、HP、Intel、Disney、EMCなどが利用している同社は、同じくデベロッパ教育のためのリソース、とりわけビデオによるチュートリアルを提供しているPeepCodeを買収した。ここには、Ruby、Node.js、JavaScript、Unix、Git、CSS、RSpec、データベースなどなど、さまざまな技術を対象とする教材が揃っている。

全額キャッシュによる買収だが、その額は公表されていない。しかしこの買収によってPluralsightのオンラインライブラリには新たにおよそ100の新しいコースが加わることになり、とりわけ、相当量のオープンソースコンテンツが増加する。今では、プロのデベロッパの多くが、オープンソースの技術およびツールと親しい仲になりたいと願っているから、絶好の買収だったと言える。

“PeepCodeはオープンソース界隈でもっとも尊敬されている名前の一つだ。そのクライアントにはGitHub、AT&T、Yammerなどが顔を揃えている”、とPluralsightのCEO Aaron Skonnardは語る。“これまでのPluralsightの顧客ベースは、顔をもっぱらMicrosoftの方に向けているエンタプライズが中心だった。今回の買収はPluralsightに、本格的なオープンソースプログラマの学習リソースとなっているコンテンツを与える。また、それらを支えている人材も得られる”、と彼は述べた。

2004年に創業されたPluralsightは最初の3年間、物理的な教室を使うデベロッパ教育を提供していたが、その後オンラインに方向転換した。今日の同社は数百ものコースを抱え、プランは個人、モバイルユーザ、企業、エンタプライズなどに分かれている。これまではMicrosoftの技術に強い教育企業だったが、そのほかSalesforce、Java、Android、iOSなどのプラットホームのための教材や教程も提供している。

今年の初めにSkonnardは、新たに得られた資金を教材/教程の一層の多様化に充てていきたい、と言っていた。そのとき具体的に構想していた開発プラットホームは、TwitterやFacebookのようなソーシャルプラットホーム、Java、Android、Ruby、PHP、Python、そしてAmazonのAWS、Google App Engine、Windows Azureなどのクラウドプラットホームだ。

PeepCodeには、それらのコンテンツが部分的にあり、またそのビデオコースの有料ユーザが数千人いる（ビデオ5本で55ドル、10本で99ドル、無制限で199ドル）。それらのビデオは、デスクトップからモバイルまでどんなデバイスからでも見ることができ、またオフラインで見ることもできる。

これらの顧客が、これからはPluralsightのユーザベースに加わる。その総数は、150か国30万名におよぶ。

さらにPeepCodeは、ビデオ教材/教程コースを作る数十名の教材制作者を抱え、彼らに指導料とロイヤリティを払っている。その点はPluralsightも同じで、Peepの数十名がこれからはPluralの150名の教材制作者の仲間に加わることになる。またPeepCodeのファウンダGeoffrey Grosenbachは、Pluralsightにおいてオープンソース開発を担当するVPになる。

Skonnardの予定では、両社の教材ライブラリの統合に数か月を要する。その後はコース数が650あまりになり、受講の方式は一本化される。

また、経過措置として、PeepCodeの既存のユーザに対し、Pluralsightの料金体系に対する“両替システム”が提供される。たとえばPeepのビデオ教材5本プランを買っていたユーザは、Pluralで一定時間のコースを受講できることになる。

向こう数か月は両サイトとも現状のまま運用されるが、そのあとは、PeepCode.comがPluralsight.comへリダイレクトされる。

今回の新コースの追加により、来年以降のPluralsightの売上の成長は三桁ペース（伸び率数百パーセント==倍増、倍々増）を維持する、とSkonnardは豪語している。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

有料アプリますます減少–2010年は80%が無料, 2013年は90%に

モバイルのアプリケーションはますます無料が多くなる、という傾向が続いている。アプリの市場を分析しているFlurryの最新レポートは、およそ35万本のモバイルアプリケーションを調べた結果として、iOSのアプリは2010年から2012年にかけて約80から84%が無料、2013年には一挙に90%が無料、と報じている。

無料のアプリに売上がない、という意味ではない。広告やアプリ内購入、そのアプリの有料バージョン（広告がない、など）、などで収益を得ているアプリも少なくない。ちなみに、広告のないバージョンへのアップグレード費用は通常、99セントとか1ドル99セントという額だ。

ただし、有料バージョンに乗り換えるユーザはあまり多くない。レポートを書いたFlurryのアナリストMary Ellen Gordonは、“広告がないことやコンテンツが高品質であることよりも、無料であることが好まれている”、と説明している。

また、ほかの調査報告書などでも言われていることだが、今回のレポートもやはり、AndroidのユーザはiOSのユーザよりもモバイルアプリにお金を払いたがらないことを指摘している。無料製品を含めた2013年4月のアプリの平均価格は、Androidが6セント、iPhoneが19セント、iPadが50セントだった。

Flurryの推定では、iPadのユーザは高収入なのでお金を払ってでもアプリを買う。しかし実は、それがすべてではない。iPadの初期には、画面が大きいのだからアプリのお値段も高い、という市場の動向だった。iPadの初期採用者は高所得者だった、あるいは、iPadアプリは開発に多くの時間を要する、といった事情があったのかもしれない。いずれにしても、そういった初期の価格政策が、iPadがタブレット市場の首位に立ち、大衆的に普及した今日でも、そのまま持続しているのだ。

デベロッパの多くが、iOSとAndroidの両プラットホームでアプリを無料にする動機は何だろう？　Flurryによるとそれは、デベロッパ界隈におけるA/Bテストや価格に関する実験の結果だ。そういう一連の事前的な市場調査の結果として、有料はノー、という結果をデベロッパたちは得ている。有料にすると、そのお値段が99セントでも、需要はガタ落ちになるのだ。

モバイルアプリは、テレビやラジオやインターネットのようなものになりつつある、とレポートは結論している。広告は嫌でも、それが無料の代償なら我慢するのだ。テレビにもラジオにもインターネットにも、電話をすれば（クリックすれば）買える、という売上発生経路があるように、アプリにはアプリ内購入というものがある。人気上位のアプリでは、これの売上額が非常に大きい。この夏のぶっちぎり大ヒットCandy Crush Sagaは、一日の売上が60万ドルを超えている、と言われる。

しかし、市場に新規参入したデベロッパがアプリストアの上位に食い込むことは、ますます難しくなっている。今年の初めにDistimoが公表したデータは、iPhoneの上位パブリッシャー中わずか2%が新人、Google Playストアではわずか3%、と言っている。アプリの製作というビジネスは、長期的に見てなかなか厳しい。アプリ内購入で稼ぐためには、その前に、アプリがたくさんダウンロードされなければならない。そしてまさにそのことが、今ますます難しくなっている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

ステータスページが必要なことは分かっているがなかなか…という企業をStatusPageがお助け

Y Combinator出身のStatusPageは、今日（米国時間7/16）の公式デビューに先駆けてすでに、Jawbone、Shopify、New Relic、Parse、Ping Identity、Zendeskなどが有料ユーザであるという幸運なスタートアップだ。名前から見当がつくと思うが、同社はWebサイト/サービス/アプリケーションを運営する企業のために（というか～～に代わって）ステータスページをホストする。どの企業も本当は、自前で良質なステータスページを提供したい…が、なかなかそのための時間や人を割けないのだ。

同社は昨年10月に、Steve Klein/Scott Klein兄弟が創業した。5月には第三の協同ファウンダDanny Olinskyが加わった。Klein兄弟は前に、モバイルアプリ制作企業をミュージシャンのリソースReverbNationに売り、その後は請負仕事などをしながら次にやることを模索していた。

ステータスページを身代わりホストするというアイデア…ユーザ企業に代わってダウンタイムやそのほかの状況をその企業の顧客のために提供する…は、なかなか良いと思われた。彼らはそれまでの経験から、とくに小企業がそんなサービスを強く求めていることを知っていたからだ。Scottがデベロッパたちにその話をすると、全員口を揃えて、“いいね。ほしいね。金払ってでも使うよ。ステータスページまではなかなか手が回らないからね”、と言った。

StatusPageのサービスは、ステータスページを作るだけなら無料だが、それをユーザが自分のブランドとドメインで一般公開するときは有料になる。ページは、そのユーザ企業が重要とみなす測度…APIのレスポンスタイム、バックグラウンドジョブ、エラー、システムダウン、などなど…を追跡する。最近では、Pingdom、New Relic、Datadog、TempoDB、Webmon、Libratoなどのサードパーティからもらったデータも表示できる。

いろんな測度の現状/現在値を表示するだけでなく、ユーザ企業はそのページから、問題に関して顧客とコミュニケーションし、対策について報告できる。そのためにメールやテキストメッセージングも使える。またユーザ企業はダッシュボードの上でそれまでの事故履歴などをグラフィカルに見ることができる（その例）。

基本プランは月額19ドルで、ページとドメイン（status.社名.com）が提供される。月額79ドルでは、SMSによる通知が加わり、また表示する測度をカスタマイズできる（その企業が必要とするデータ）。さらにその上には、ビジネスプランとエンタプライズプランがある。

Scottによると、ユーザ登録をしてから基本プランのページが表示されるまでの時間は15分から30分ぐらいだ。彼曰く、“自分でなかなか作れないのは、開発の納期が厳しいからだ。だからうちが作るステータスページは、デベロッパの手と時間をいっさい煩わせないものでなければならない”。こんなページは、CSSの初歩を知ってて会社のロゴなどの画像が手元にある人なら誰にでも作れる、Scottはそう説明する。“デベロッパが忙しければ、事務職にだって作れるよ”。

今後は、もっとカスタマイズの幅を広げたい、と彼らは考えている。とくに大規模なサイトでは、今どのサービスがどのユーザに影響を及ぼしているかを、明確に表示する必要がある。マルチテナントの場合はとくに、誰にでも情報を見せるのではなく、関係ある情報を関係ある顧客にだけ見せる、という粒度が必須だ。

StatusPageの類似サービスには、Stashboard、Offsitestatus、Whiskerboardなどがある。彼らは今日の一般公開デビューの前にHacker Newsの上で非公開でローンチしたが、その間に登録アカウント450を獲得し、そのうち50は有料顧客だ。

今はわずか3名のチームが、Y Combinatorに近いMountain Viewにオフィスを構えている。しかし今後は、Dannyだけを残してリモートで仕事をするつもりだ。Scottはコロラド州Fort Collins、Steveはノースカロライナ州Durhamとなる。まだ、新たな資金調達の予定はない。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

デベロッパがクラウドを生かす; その逆ではない–Oracle/Salesforce批判

今週（米国時間6/23-29）はOracle/Salesforceの連携を契機にクラウドの話題が盛り上がったが、でもそれは、クラウドの実態から見ると、かなりずれた話ばかりだった。クラウドを支えているのはデベロッパであり、その逆ではない。

大物たちが手を組むのも、今やそうせざるを得ないからだ。それは既存の顧客にサービスを提供していくための、守りの姿勢だ。それは、老いたる王たちが新しいソフトウェアのライセンスで稼ぎを増やす、という前向きの話ではない。合従連衡してクラウドからレガシー技術を提供していくのは、まあそんなクラウドの使い方もあるね、という程度の話にすぎない。

彼ら独特のクラウドの定義によると、大きなITを抱える大企業が旧タイプのデータベースの新しいバージョンを手に入れて、10年も15年も前にインストールしたソフトを動かす、という筋書きになる。デスクトップやクライアント/サーバの時代に作られたオペレーティングシステム*を、クラウドサービスとして新たに鋳込むことはたしかにできる。古手のSaaS企業（ここではSalesforce）がオンプレミスの旧敵（ここではOracle）と組んで、過去14年間順調に動いていたものが次の二世代およびそれ以降もそのまま良好に使える、と嬉々として語るのもよい。何かをしなければならない会社は、牛がいればカウベルをつけたくなるものだ、それにはきりがない。〔*: operating system, ここではコンピュータのOSではなく、ITオペレーション(DevOpsのOps側に相当）のベースとなるシステム。具体的にはRDBMSを軸とする業務系システムのインフラ。〕

しかし、このような、レガシーデータベースによるオペレーティングシステム（業務系）とCRMが手を組む動きは、イノベーションではない。それは単にステータスクォーを保全し、彼らがこれまで数十億ドルを稼いできた源泉であるパンとバター（ご飯と味噌汁）的な定番的事業を提供するにすぎない。真のイノベーションは、新しいジャンルのデータベースにあり、デベロッパフレームワークに、ソーシャルなコーディングサービスに、データ分析によりコンテキスト対応力を持ったAPIに、などなどにある。クラウドに価値がない、と言っているのではない。価値なら、たくさんある。クラウドは、その価値ゆえに買われる。計算処理とストレージの費用低減、という価値だ。Joyentの料金は、今や月でも年でもない、秒単位だ。

しかしそのインフラストラクチャの底の方を見ると、そこにすらデベロッパの仕事のきざしがある。たとえば、ソフトウェア定義データセンターの話題が盛り上がっている。それは、金属製のスイッチではなくソフトウェアがデータセンターを構成し、そのAPIがすべての要素を結びつける、というコンセプトだ。APIが、ネットワークと、データストアと、ありとあらゆる形のクライアントやデータベースや等々を結びつける。今や、ネットワークの働きでアプリケーションが構成され機能する。昔とは逆だ。

そうやって巨大なマシンもパイプも抽象化され、その変化をデベロッパが引っ張る。あの小さなスマートフォンが、今やサーバだ。JoyentのProject Mantaが示しているように、大きなストレージとネットワークマシンがオペレーティングシステム*の一部になりつつある。計算処理とストレージが一体となり、インメモリデータベースが分析を瞬時に行う。〔*: operating system, 前記訳注参照。〕

Just.meのファウンダKeith Teare（本誌TechCrunchのファウンダの一人）が、今週のGillmor Gangで、クラウドは定数だが、やることは毎回同じとはかぎらない、と言っている。たしかに、最近のクラウドの使い方は変わりつつある。クラウドの消費のされ方が、変わってきた。クラウドを使うアプリケーション、デバイス、クラウドにプッシュされ〜〜からプルされるデータが。クラウドはデータのインテグレータ（メッセージバス）でありデータストアだが、今ではブラウザだけから消費されるものではなくなっている。

Andreessen HorowitzのパートナーPeter Levineが先週のインタビューで、15〜20年前にはMicrosoftとWinAPIがすべてだった、あらゆるプログラムやAPI呼び出しがWindows詣でをした、と言った。しかし今では、APIはおびただしく多様化している。今は、何をするにもそのためのAPIがある、と期待する。そしてそのことが、開発を加速する。

今年は、デベロッパの年だ。GitHubの会員が一日に約1万ずつ増えている。Levineの説では、クラウドという雲を高みに押し上げたのは、この、噴火して盛り上がるようなデベロッパたちの軍勢だ。クラウドのプロバイダたちは、その価値を提供してデベロッパの関心に沿い、するとデベロッパはますます多くのアプリケーションを作る。アプリケーションが増えれば、ますます多くのクラウドサービスが必要になる。スマートフォンのメーカーやキャリアも、充実したデベロッパコミュニティを育てることに関心がある。デベロッパの作品が増えれば、彼らのデバイスや時間の売上も増えるからだ。Levineは、上流がデベロッパ、下流がアプリケーション等のユーザ/ユーザ企業だ、と言う。

だから、今度また、レガシーのプレイヤーたちが嬉々としてクラウドはすばらしいと宣（のたま）う記事を見たら、よく考えてみよう。レガシーのクラウド化もそれなりにすごいことではあるけど、でもそこに、新しいクールなものを作るデベロッパがいなければ、無意味だ。ポケットにあるスーパーコンピュータが、われわれを世界につなぐのは、デベロッパが作りだすイノベーションがあるからだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

社会貢献を強調するApple, アプリは世界を変えると中編ビデオで訴える

Appleが今日ポストした、かなり長い、10分近くのビデオは、同社のプラットホーム向けのアプリが世界中で利用され、人びとの生活に大きな変化をもたらしている、と訴求している。それは、これまでのAppleのコマーシャルとはずいぶん違う視点だ。これまでは、平均的な消費者の生活が、アプリによってちょっと便利になりますよ、といった軽い短編ばかりだった。

このビデオはもっと視野が大きくて、一部の人びとの生活に重要な変化が訪れることを描いている。テーマとしては同社の最新のテレビコマーシャル“Our Signature”と同類だが、後者のようなAppleの製品作りにおける指導的原理ではなく、実際のケーススタディを強調している。そしてもちろん、サードパーティのデベロッパに光を当てている。彼らの、少数民族文化の保存努力や、医療技術の大きな進歩への貢献など、取りあげるにふさわしいものを、あらためて取りあげているのだ。便利なお買い物リストを簡単に作れますよ、という世界ではなくて。

(出典: 9to5Mac)

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

WebRTCとWeb AudioとWebGLのパワーを見せつけるためにオープンソースのPongクローンをGoogleがローンチ

Googleが今日（米国時間6/12）、PongゲームのクローンCube Slamを、オープンソースで立ち上げた。ブラウザの上で、友だちやコンピュータと対戦できる。そのこと自体はあまりエキサイティングでもないが、しかしGoogleはこのゲームを、WebRTCとWeb AudioとWebGLのデモとして作ったのだ。

多くの人、とくにデベロッパにとって、WebRTCは、ブラウザ上でできるプラグイン不要のビデオ会議を意味しているが、しかしCube Slamはこの通信技術を使って、プレイ中にライブのビデオとオーディオのストリームを友だちの仮想スクリーンに映し出す。

とりわけ重要なのは、このゲームがWebRTCのRTCPeerConnectionとRTCDataChannelを使って、オーディオとビデオと“ゲームの同期を維持するためのあらゆるデータ”を、二つのマシン間で送受していることだ。WebRTCのこの二つの部位は、これまで知らなかったデベロッパが多いと思う。

Googleの主張によるとCube Slamは、“ RTCDataChannelを使った初めての大規模なアプリケーションであり、そのAPIはWebSocketに似ているが、しかしデータをRTCPeerConnectionのピアツーピアリンクで送る”。

明らかにここでGoogleが見せたいのは、WebRTCのパワーだ。すでにWebSocketに関しては同様のことを実験作Racer Chromeでやっている。そしてまた同時に、WebGLとWeb Audioで何ができるかも、見せつけたいのだ。

このゲームのインフラストラクチャはGoogleのCompute Engineがホストし、そのコードはここで入手できる。

今Cube Slamを動かせるのはデスクトップのChromeとChrome OSだ。今年後半にはAndroidのChromeでも遊べるようになる。ただし今でも、chrome://flagsのメニューで”WebRTC Android”を有効にすると、Android上で試用できる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

iOS 7のフラットデザインでアプリを開発するための移行ガイドをAppleが発行

予想どおりAppleは、iOS 7にまったく新しいデザイン原則を導入した。自分のアプリを最新作に見せたいデベロッパは、その‘原則’に適応しなければならない。幸いにもAppleは今日（米国時間6/10）、iOS 7向けの設計や既存アプリの移行に関する、相当網羅的なガイドを発表した。これを読むと、縁なしボタンや半透明バー、全画面レイアウトなど、新しいUI成分の使い方を理解できる。

完全新装のiOS 7についてAppleは、“アプリがその目的と機能性をユーザに伝えるやり方を再検討するための、またとない機会だ”、と言っている。

iOS 7向けにアプリを設計するときのAppleが掲げる三大テーマは:

服従(Deference)* UIはユーザによるコンテンツの理解やコンテンツとの対話を助けるが、コンテンツと競合しない。

明晰(Clarity) テキストはどのサイズでも読みやすく、アイコンは精密で明快、装飾は目立たず適切、そして機能性を重視したデザイン。

深遠(Depth)** ヴィジュアルレイヤ（層化UI）とそのリアルな動きがユーザの満足と理解を高める。

〔訳者注: *Deference, 三歩下がってコンテンツの邪魔をせずのような、控えめな態度。**Depth, はてブsecurecatさんのご忠告に従うと「奥行き」、ただここは、全体的に文学調・哲学調にしてみたかったので。〕

中でもAppleがとくに強調している新機能が動的タイプ(Dynamic Type)だ。それによりiOS 7の中ではテキストレイアウトの多くが自動化される。Appleはまた、iOS 7向けのアプリは新しいデザイン成分、とくに透明なステータスバー、ナビゲーションバー、タブバー、ツールバー、検索バー、スコープバー、デート（日付）ピッカーなどをサポートしてくれ、と言っている。

さらにまたAppleは、アプリがiOS 7にふさわしい“くっきりとした美しいUIとなめらかな動き”を実現して、いかにもAppleふうのアプリになるためのコツを二つほど述べている。その第一は、全画面重視。はめ込み的なレイアウト(inset)やフレームを使わずに、アプリのコンテンツが“画面の端から端までを占領する”こと（上図）。第二は、物理的なリアリズム（ベゼル、グラデーション、ドロップシャドウなど）を廃すること。その理由は、それらはUIを重くし、コンテンツよりも目立ってしまうことがあるからだ。Appleは曰く、“UIはあくまでも脇役に徹するべきである”。そして、アプリは“明快さを優先し”、ホワイトスペースが多くて、色はUIを単純化するためにのみ、使うこと。

そのほか、Appleがデベロッパに多用してほしいと思っているUI成分は、半透明な背景とトランジションの強調により、複数のコンテンツの深度と階層を表現するやり方…層化UI…だ（下図）。

このガイドはiOS 7のドキュメンテーションでありながら、必要ならば当分の間はiOS 6ふうのデザインを維持してもよい、と言っている。そのためXcode 5は、アプリの複数のバージョンの管理をサポートし、Auto Layoutを使った場合とそうでない場合を比較できる。

以下に、Appleが主張するiOS 7向けアプリ開発の原則を、箇条書きにしてみた:

アプリのコンテンツが半透明のUI成分（バーやキーボードなど）や透明なステータスバーの下に見えること。iOS 7では、ビューコントローラは全画面レイアウトを使う（ビューコントローラの使い方は、Using View Controllers）。
カスタムバーののボタンアイコンのデザインを変える。iOS 7ではバーのボタンアイコンは軽くてスタイルも異なる。
ふちなしボタンに備える…ボタンのバックグラウンド画像をやめて、レイアウトも再検討する。
UI成分のサイズや位置をコード中で具体的に指定することをやめて、システム提供の値からそれらが自動生成されるようにする。レイアウトを変えたときにアプリが自動的に適応するためにAuto Layoutを使う（Auto Layoutの使い方は、Cocoa Auto Layout Guide）。
アプリ中の、UIKitコントロールやビューの寸法・スタイル等が変わるとレイアウトや外見が変わるような場所を見直す。たとえば、スイッチは幅が広いし、テーブルのグループにはインセットがなく、プログレスビューは前よりも薄い。個々のUI成分に関する詳しい情報は、Bars and Bar Buttons、Controls、Content Views、Temporary Viewsを見よ。
Dynamic Typeを使え。iOS 7では、アプリ内で今見ているテキストのサイズをユーザが調節できる。ユーザのそんなアクションにアプリが対応できるためには、Dynamic Typeを採用しなければならない。詳しくは、Using Fontsを。
アプリ独自のタッチ処理を書いたときなどには、iOS 7の新機能であるControl Centerのジェスチャーやナビゲーションコントローラの‘スワイプして戻る’ジェスチャなどと衝突しないよう気をつける。
ドロップシャドウやグラデーション、ベゼルなどの使用をやめる。iOS 7の美学はスムースさと層化（半透明化）にあるので、物理的な実物に見えるようなUI成分は重視されない。影つきとか、立体感とか、そういう物理的実物感は再検討を要する〔つまり、やめてほしい〕。
必要なら、アプリをiOS 6のベストプラクティスにアップデートする（Auto Layoutやストーリーボードなど）。それにより、アプリが非推奨APIを使っていないようにする。

iOS 7デザインガイド本体は、ここにある。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

AppleのApp Storeダウンロード総数は500億。アプリケーション数が90万で、開発者が得た金額は100億ドル

毎年のWorldwide Developers Conferenceで楽しみなことのひとつは、Appleエコシステムの状況について発表をきくことだ。本日も、最新の情報が発表された。App Storeからのダウンロード総数は500億に達したとのことで、昨年の300億から大いに伸び、480億ダウンロードの達成を先日アナウンスしたGoogle Playをリードする状況であるようだ。iOS用アプリケーションの数は90万本に達しており、iPhone、iPad、およびiPod touchなどで利用できる。iPad専用アプリケーションの数は37万5000本となっているそうだ。

2012年6月の段階では、iOSアプリケーションの数は65万本であるとされ、iPad用が22万5000本だとアナウンスされていた。ちなみに2011年段階ではiOSアプリケーションの数は42万5000本で、iPad用は9万本とのことだった。登録アプリケーションを利用する登録利用者数は現在のところ5億7500万であるとのこと。

Appleのアプリケーション経済は開発者たちにとってもうまく機能しており、Appleがサードパーティー開発者に支払った額も100億ドルに達しているそうだ。こちらの方は2012年には50億ドルで、2011年段階では25億ドルだった。成長具合をみるためにさらに遡ってみると、2010年は15億ドルであるとアナウンスされていた。

アプリケーション開発者がマネタイズを目指す際に、やはりAppleのエコシステムというのが有効に機能しているようだ。アプリケーション分析を行なっているApp Annieの今年第一四半期についてのレポートによれば、iOS App Storeの売り上げはGoogle Playストアの2.6倍であったとのこと。App Annieと競合するDistimoも、Google Playが着実に成長しつつあるものの、現状ではiOS App Storeが優位であることをレポートしている。また、アメリカのストアにおいてトップ200のアプリケーションを比較した調査も行なっている。それによれば、2013年4月時点で、Google Playにおける日々の売り上げは110万ドルで、Apple App Storeの方は510万ドルとなっている。

ただ、Appleのアプリケーションエコシステムの成長が諸刃の剣となっている状況もある。多くの利用者が存在してチャンスはあるものの、しかし一部の「勝者」が全てを獲得するという状況にもなりつつあるのだ。iPhoneアプリケーションの売り上げが上位のパブリッシャーのうち、新人が占める割合がわずか2%であるという報告もあった。100億ドルの行き先がどうなっていたのかは、なかなか興味深いところだ。

爆発的な人気を獲得したわけではないアプリケーションの開発者にとってみれば、App Storeの成長ぶりや売上げについてのアナウンスはすなわち機会損失を証明するものともなる。Apple App Storeの成長が落ち着いてくる中、Google Playの方に目を向けようとする開発者も存在するようだ。

［原文へ］

（翻訳：Maeda, H）

既存のGoogle Mapsのアクセスではなく自由にカスタム地図を作れるMaps Engine APIがまず有料の企業ユーザに公開–将来は一般公開も

GoogleのMaps Engineは、主に企業が自分のデータに基づいて独自の地図を作るためのサービスで、二年前にローンチされ昨年から商用化された。今日（米国時間6/5）Googleはこのプラットホームの機能をなお一層増強すべく、Maps EngineのAPIを立ち上げた。これによりデベロッパは、独自データを使った独自の地図作りを、Maps Engineサービス上ではなく自己のアプリケーション内で行えるようになる。APIの提供に踏み切った理由をGoogleは、企業がアプリケーション内の地図作成提供機能としてGoogle Mapsよりも高度な、自己データに基づくものを要望しているからだ、と説明した。たとえば（静的なGoogle Mapsとは違って）、社員や顧客からのデータや情報を生かした地図の作成提供も可能になるのだ。

GoogleにはすでにMaps APIがあるじゃないか、と思われた方もおられると思うが、しかしMaps Engine APIのプロダクトマネージャDylan Lorimerによると、Maps APIでは主に、Google自身の地図コンテンツにアクセスできるだけである。それに対し、Maps Engine APIを使うと独自のデータを使ったカスタム地図を作れる（例: 上図）。なお、そのシステムにはGoogleの分散グローバルGPSデータベースSpannerが使われている。

このAPIはこれまで“実験段階”とされていたが、これを使うことにより、アプリケーションからの入力データ〜読み取りデータによって地図〜地図上の情報も変わる、という部分をデベロッパが容易にプログラミングできる。顧客のブランドのブランドイメージやニーズに即した地図も作れるし、またその地図をほかのデベロッパと共有することもできる。

たとえばFedExはこのAPIをしばらく試用していたが、今では同社の位置情報サービスstore locatorが完全にこれで動いている。 FedExのITマネージャPat Doyleによると、Maps Engineの利用に完全に切り換えたのは今年の1月からである。

テスターとしてのFedExからのフィードバックも、Maps Engine APIに反映されている。たとえば、指定した位置に関する結果（お店の所在など）をサーバサイドでソートするより容易な方法、などだ。このAPIを利用することによってFedExは、タッチインタフェイスの地図上の50000あまりの小売店の、営業時間のアップデートを、15分おきにできるようになった（営業時間だけでなく、一つのお店に約150項目のデータがある）。たとえば停電や天災などで急な閉店になっても、そのことがユーザにはすぐに分かるのだ。

Doyleによると、システムの信頼度は今のところ100%である。そして、アクセス分析データによると、store locatorを使ってお店を見つける人が、前よりも増えている。FedExの用例については、このビデオが参考になるだろう。

APIはまだ、Maps Engineサービスのごく一部の機能しかサポートしていない。ベーシックな場所クェリやベクタデータの操作などだ。近い将来、APIの拡張を行う、とGoogleのチームは言っている。またLorimerは、高価な企業向けのMaps Engineアカウントを持っていない一般のデベロッパでも、このようなAPIを利用できるようにしたい、これは自分個人の考えではなくGoogle自身の関心事だ、と力説した。この件に関しGoogleからの公式発表はまだないが、いずれある、と考えて間違いないだろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

デベロッパが自分のアプリの利用状況をチェックできるApp Engagement ReportsをAmazon Appstoreが提供

モバイルアプリのデベロッパ向けに数々のサービスを連射しているAmazonが今日（米国時間5/24）は、App Engagement Reportsを発表した。これは、アプリの利用状況を報告する無料のアプリケーションで、今度から同社のMobile App Distribution Portalに含まれることになる。Amazon Appstoreのデベロッパがアプリのパフォーマンスや売上などに関する情報を知りたいときに、このアプリケーションを使う。

同社の発表時の説明によると、このレポートには、各日各月のアクティブデバイス数、アプリのインストール数、アプリの実動セッション数、デバイス一台あたりの平均売上、ユーザ保持率（リテンションレート）などの数値データがあり、それをマーケットプレース別にフィルタしてチャート形式で見たり、CSVでダウンロードしたりできる。また期間を区切って時系列でデータを見ることもできる。

提供されるEngagement Reports（エンゲージメントレポート）は、次の６種類だ:

概要: あなたのアプリやゲームの主な利用状況データ
平均売上: アプリ内アイテムのデバイス一台あたり各日各月平均売上(Average Revenue per Device, ARPD)と有料ユーザ一人当たり平均売上(Average Revenue per Paid User, ARPPU)
リテンション（ユーザ保持率）: 1日3日7日の日別保持率と1週2週3週の週別保持率
アクティブデバイス数: 各日アクティブデバイス(Daily Active Devices, DAD)、各月アクティブデバイス(Monthly Active Devices, MAD)、スティッキーファクター(Sticky Factor(DAD/MAD), 継続率)
アプリ実動セッション: 各日総セッション数とデバイス一台当たり平均セッション数
アプリのインストール: 各日インストール数とアンインストール数

当面、レポートが得られるのは2012年10月25日以降に提出したアプリのみだ。それ以降に更新のないデベロッパは、アプリを再パブリッシュするかアップデートを提出して、レポート機能を有効にする必要がある。ただしアプリのコードに変更は必要なく、ほかのソフトウェアを統合する必要もない。

Amazon Appstoreのアプリの最新バージョンの、一般的なAndroidデバイス上での使用状況のほかに、Kindle FireやFire HDなどAmazonのデバイスで動くアプリもレポートに含まれる。

アプリの売上や利用状況に関するデータはAmazonのAppstoreにかぎらず、マーケットプレースサービスが提供するサービスの一環としてきわめて重要だから、Google PlayストアやAppleのiTunesではすでに標準の機能になっている。多くのデベロッパがサードパーティのSDKを統合して詳細なレポートを得ているが、だからAmazon自身が提供しなくもてよい、ということにはならない。Amazonはこの機能について、“デベロッパからのリクエストがとても多かった”、と言っているが、なにしろマーケットプレースが必ず持つべき機能の一つだ。

このEngagement Reportsの提供の前にも、AmazonはAppstoreの機能増強に努めている。そのグローバル展開だけではなく、アプリ内決済、サブスクリプション（会費制）、そしてAmazon独自の仮想通貨Amazon Coinsまで導入してきた。いずれも、デベロッパの収益性を高めるための布陣だ。

デベロッパにはこういう機能を実験しているひまが、なかなかなかったが、でもARPU(ユーザ一人当たり平均売上)やリテンション（保持率）などは、アプリの今後の改良の強力な動機を導くデータだから、必ずレポートを見るという習慣をつけた方が良い。

レポートの項目の詳細については、ここに説明がある。またEngagement ReportsのFAQには、いろいろと具体的な質問とそれらへの答えが載っている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

Google Glassの開発環境が明らかに―現状では制限があるものの可能性はすばらしい

先週Googleはとうとうデベロッパー・ガイドその他Glassアプリの開発に必要な文書をリリースした。このMirror APIには完全なAR（拡張現実）アプリの開発を希望していた一部のデベロッパーから失望の声も上がった。しかし現状のままでもデベロッパーは新規、あるいは既存のアプリに今までは不可能だったまったく新しいユーザー体験を提供できるはずだ。

Googleがこのドキュメントを公開して多くのデベロッパーが始めて知ったことの一つは、APIが基本的に伝統的なRESTfulサービスだったことだ。これはつまりGlassに対する操作はすべてクラウドを通さねばならないことを意味する。Glass自身はAndroidで動いているが、現状ではデベロッパーはGlassのハードウェア上で作動するアプリを開発することはできない。開発できるのはウェブアプリだけだ。

Googleがこのような選択をした理由はいくつか考えられる。ひとつにはGlassのバッテリー駆動時間があまり短くならないように配慮したのだろう（Googleでは「ビデオを長時間録画しないかぎり1日もつ」としている）。ウェブアプリであれば、ネコの写真を1秒に1枚送りつけるような振る舞いに及んだ場合、Googleは配信をブロックすることができる。ユーザーの観点からは善悪は決めにくいが、Googleが当面Glass環境にある種のコントロールを及ぼそうとしていることは確かだ。

現在のMirror APIの仕様からすると、スマートフォンならどれでも一般に可能な動作でもGlassでは不可能なものが出てくる。たとえば、上で述べたようにARアプリは開発できない。また音声やビデオをユーザーのモバイル・デバイスからGlassにストリーミングすることも難しい（しかしGlassでもGoogle+のハングアウトは利用可能なはず）。

ウェブアプリであるからには表示はHTMLとCSSを使わねばならない。GoogleはユーザーがカスタムCSSを書くことを好まず、標準テンプレートだけを使わせようとしている。.

しかし全体としてみれば、デベロッパーは昨年Googleが公開したGlassのデモ・ビデオで描かれた機能はすべて実装できそうだ。

Androidデバイスがベースであれば、位置情報利用アプリを開発することも可能だ。ユーザーが画像をサーバに送り、そこでなんらかの処理を行なってからユーザーのGlassに送り返すようなアプリも開発できる。ビデオのアップロードもできる（逆にサーバ側から画像、音声、動画を配信することもできる）。

デベロッパーに（少なくとも現在は）許されていないのは、ユーザーのGlassに広告を表示すること、有料アプリを販売すること（違法なギャンブルアプリも問題外）だ。Glassの当面の市場規模を考えればこうした制限は大きな問題にはならないだろう。おそらくGoogleは将来デベロッパーに対して何らかの有料化を認めるだろうが、Glassプラットフォームに伝統的な広告を表示するのはユーザー体験を大いに損なうだろうから、将来とも許可されないだろう。

Googleは「デベロッパーはGlassが誕生したばかりのプラットフォームであることを強く意識して開発にあたってもらいたい」としている。現にGlassのハードウェアを購入したデベロッパーだけがAPIにアクセスできるのもこうした事情によるものだ。

当面、このAPIFに対してデベロッパーはいろいろな不満のを抱きそうだ。しかしこれは最初の一歩にすぎないことを忘れないｙほうしなければならない。Googleは今後もっと強力なAPIをリリースし、また現在のAPIの制限を緩めるはずだ。ネーティブ・アプリが開発できなければデベロッパーが望んでいたようなサービスをすべて提供するのは不可能だ。こうした制限付きではあっても、さまざまな革新的Glassアプリが近く登場することは確実だ。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）

バックエンドまわりをすべて引き受けるBacklift, デベロッパはフロントエンドだけ書けばよい

今日ローンチしたY Combinator出身のスタートアップBackliftは、フロントエンドデベロッパのためのバックエンドデベロッパ、を自称している。サーバ環境のセットアップなどをすべて引き受けるので、フロントエンドデベロッパはまさにフロントエンドのロジックだけに集中できる。そのために必要なのは、Dropboxのアカウントとテキストエディタのみ。BackliftはDropboxをファイルシンクサービスとして利用する。あなたの縁の下にBackliftがいると、RailsやDjango、node.jsなどのセットアップについて、あなた自身は何も知らなくてもよい。

BackliftのファウンダCole Krumbholzによると、彼のねらいはデベロッパがいきなり自分のフロントエンドのコードを書き始められること。デベロッパの中にはバックエンドについてびびる人が多いが、Backliftはそういう人たちのための教材としても優れている、と彼は言う。またBackliftは、プロトタイピングの場としても利用して欲しいし、将来的にはアプリケーションのホスティングもやりたい、と。

Backliftには、Dropboxのアカウントでサインインする。そしていろんなテンプレートが用意されているから、その中から自分のアプリ用を選ぶ。backbone.jsのサンプルアプリケーションも各種用意されている。Google MapsのAPIを使うサイトの例、Bootstrapを使うシンプルなサイトの例、などもある。そのほかのよく使われる技術、AngularJS、CoffeeScript、Handlebarsなども使える。BackliftはユーザのDropboxアカウントに新しいフォルダを作り（それはユーザのデスクトップにも反映し）、ユーザはお好きなテキストエディタでコードを書き始める。コードをDropboxにセーブすると、それはBackliftにシンクされ、結果をブラウザ上で見られる（シンクはユーザがコードをDropboxにアップロードしてから1秒未満で始まる）。

アプリケーションは何らかのデータを扱うものが多いから、Backliftはベーシックなデータ処理のためのAPIを提供している。管理用のダッシュボードが提供されるので、そこでデータベースへのデータのインポート/エキスポートなどを行う。

ベータの段階でBackliftを本格的に利用したスタートアップの一つがAutomatic.comだ。これもYC出身だが、最近ローンチした独特なハードウェアによって、どんな車でもインターネットに接続できる車にする。Automatic.comのビジュアルと対話デザイナーGabriel Valdiviaは、次のように言う: “うちはAmazonのS3も使ってるけど、開発段階、それに投資家たちにに見せる段階では、Backliftの方がずっと便利だし、仕事がはやいし、それにセキュアだ”。

Krumbholzによると、このサービスは絶えず進化していて、今計画している今後の機能も多い。ただし、その詳細を話すのは尚早だそうだ。

Backliftは今、完全に無料だ。今後は有料の機能も加えるが、それについても詳細は未定だ。

Krumbholzは、Y Combinatorのスタートアップとしては珍しく、単独ファウンダだ。海軍を除隊した彼は次に航空管制用ソフトウェアのインタフェイスを作り、さらにその次にはiOS用のモバイルゲームを作り始めた。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

モバイル開発の”継続的インテグレーション”を自動化するCisimple,アプリのHTML5シミュレーションも

Cisimpleは、モバイルアプリケーションの構築と試験と展開過程を自動化してくれる。同社が今日（米国時間4/9）ベータを脱して、その新しい試験プラットホームを全デベロッパに公開する。同社はKickfolio’sのAPIを統合した初めての企業でもある。こちらの新進スタートアップは、iOSのアプリをHTML5を使ってブラウザに持ち込む。

継続的インテグレーション(continuous integration, CI)（日本語）はこのところ、市場としても活気づいてきた。そのきっかけは、試験のためのHerokuと呼ばれるCircleCIが、今年の初めにHerokuのファウンダたちとEric Riesから150万ドルのシード資金を獲得したことだ。Cisimpleは、混み合ってきた市場…Atlassian Bamboo、CloudBees(Java用)、Travis CIなどなど…で自己を差別化するために、モバイル専門で行くつもりだ。HostedCiもその路線だが、まだベータだ。

デベロッパが登録会員になると、CisimpleはそのデベロッパのGitHub上のリポジトリ（モバイル開発用）をスキャンする。デベロッパがそこにコードをアップロード/アップデートすると、Cisimpleが自動的にビルドを行い、試験をし、そのアプリをTestFlightや新進のHockeyAppなどのサービスから展開する。後者は、数週間前にCisimpleを統合したばかりだ。

AngelPadが支えるこのスタートアップがモバイルデベロッパ向けに初めてその扉を開いたのは、昨年の11月で、約1100名の初期ユーザがこのサービスを使った。“立ち上げ直後からたくさんのフィードバックをもらったので、モバイルデベロッパが抱える問題がよく分かった。うちなら、それらの問題解決のお手伝いができる、と確信した”、CEOのKevin Rohlingはそう語る。“彼らの悩みのタネの一つが試験だ。たしかにそれは（モバイルではとくに）現状では本当に難しい。モバイルデベロッパのためにアプリの試験を自動化するサービスは、これまでなかったから”。

Cisimpleのインフラストラクチャの上でデベロッパ企業は、アプリの複数の機種の上でのシミュレーション、ビルド、試験(#)、そして展開（デプロイ）ができる。iOSとAndroidをサポートしているが、(#)試験は今のところiOSのみだ。AndroidはOSやSDKの不統一という問題を抱えているが、しかし自動化の需要が多いのは今現在ではiOSだそうだ。だから、Android対応はとりあえず後回しとなった。

Cisimpleが試験に関して提供するのは、ログや合格/失敗の結果だけではない。たとえば、シミュレーションをやっているときのビデオなどもデベロッパに提供する。“試験を記録したビデオがあれば、細部検討をしやすい。しかしデベロッパが自分で試験をするときは、ビデオまではなかなか手が回らない”、とRohlingは指摘する。“うちは、アプリケーションに関するフィードバックを入手しやすいようにしたい。どこが変わったのか。どこがだめなのか。等々。また、問題をなるべく容易に見つけられるようにしたい。結局うちがやってるのは、モバイル開発をもっとアジャイルな工程にすることだ。今のモバイル開発は、デベロッパの手元ではちぐはぐになりがちだからね”、と彼は言う。

Kickfolioの統合も、注目に値する。開発〜試験の過程では、デベロッパがビルドの結果をブラウザ上で簡単に見られるからだ。だから試験が失敗すると、失敗したという結果だけでなく、ビルドの結果をブラウザ上でクリックしたりして、そのバグを実際に体験できる。Cismpleの顧客がここに載っているから、彼らのKickfolio版アプリを試してみるとよい。Cisimpleの有料ユーザは全員がKickfolioを利用できる。

Rohlingがベータ時のユーザ数などを明かさないのは、数字を公開するのは時期尚早と思っているからだが、ベータに参加したデベロッパの一部はすでに有料ユーザになっている。とくに多いのは、同社の料金体系の中のインディー向けプランだ。

今日（米国時間4/9）サインアップするデベロッパは2週間の無料試用ができる。あるいは、一（ひと）月に30ビルドまでという無料プランもある。有料プランはインディーの月額19ドル、スタートアップの99ドル、大企業の999ドルなどだ。サインアップはここで。

〔継続的インテグレーションの実践参考書の例。〕

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

MapReduceのオープンソース実装を特許訴訟の対象にしないとGoogleが公式に誓約

Googleが今日（米国時間3/28）、同社のMapReduceプログラミングモデルのオープンソースバージョンを実装したユーザやディストリビュータやデベロッパを、それらの実装が本質的にはGoogleのパテントを侵害しているものであるにもかかわらず、訴訟はしないと公式に誓約した。たとえばApacheのHadoopはおそらく、Googleがこの技術に関して保有している10件のパテントを侵害している。同社法務部でパテント関連を担当しているDuane Valzは今日の発表声明の中で。“これをこの業界における範例としたい。弊社以外の特許保有者にも、誓約やそれ相当の自発的行動をとるよう、おすすめしたい”、と言っている。

今回の誓約の対象はGoogleが保有する特許のごく一部にすぎないが、しかしGoogleは誓約の対象範囲を長期的に拡大していくものと予想している。ただし、最初にGoogleの方が攻撃された場合には、公然と特許権を振りかざして相手と戦う、としている。

残念なことにパテントをめぐる抗争はソフトウェア業界で日常化しており、そのため、GoogleやRed Hat、Sony、IBMなどが支援する団体Open Invention Networkは、オープンソース製品の開発をパテントに関する懸念から解放しようと努力している。

Googleは今回の”Open Patent Non-Assertion Pledge” （特許公開非主張誓約, OPN誓約）が、業界の今後のモデルになると考えている。同社のパートナーや競合企業が同様の誓約をすることによって、この過程（特許公開非主張の過程）関し長年待望されていた透明性と、幅の広さとセキュリティが導入される、と同社は期待している:

透明性: 特許保有者は誓約の対象となる特許と関連技術を正確に同定し、デベロッパと一般社会に対し特許権をめぐる透明性を提供する。

幅広さ: OPN誓約による保護の対象は特定のプロジェクトやオープンソースの著作権ライセンスに限定されない（Googleはその種のライセンスの下に大量のコードを寄与貢献している。それらはApacheやGNU GPLなどのライセンスであるが、特許からの保護に関してそれらは非力である）。それとは対照的にOPN誓約は、過去現在未来を問わず、誓約下のパテントに依存しているかもしれないいかなるオープンソースソフトウェアに対しても適用される。

守勢の保護: Googleの製品やサービスに対して特許訴訟が起こされ、それらの特許がOPN誓約の対象であったときには、そのときにかぎり、攻勢の保護を行うために、非主張誓約は破棄される（==特許権を主張して公然と戦う）。

永続性: 誓約は対象特許の寿命期間中有効であり、権利が他に移行された場合にも、有効である。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

MozillaがFirefoxのデベロッパツールの充実に注力: ブラウザ内エディタ, Firebugの統合, ネットワークパネルなどなど

先週、MozillaのテクノロジエヴァンジェリストPaul RougetがWebデベロッパたちに、Firefoxの開発ツールとして何が欲しいか、という質問をTwitterやHackerNewsで投げかけた。そのフィードバックに基づいてFirefoxのDevToolsチームは、今後のFirefoxの安定版に盛り込むべき新作または改良版のデベロッパ機能の数々を構想し、それらのプロトタイプ作りに取り組んできた。

Rougetが書いた記事によると、リクエストでもっとも多かったのは、ブラウザ内でコードを書けて、そしてエディタやIDE（統合開発環境）からブラウザをコントロールできることだ。このリクエストに対してチームは今、二つのやり方を検討している。DevToolsのチームは人気の高いSublime TextエディタとFirefoxに本来あるリモート機能を利用するライブエディティングの概念実証を作った。しかしMozillaはそのほかに、Firefoxの中にエディタを置くことも検討している。

Mozillaがブラウザ上のエディタを考えたのは、これが初めてではない。2009年にMozillaは、Bespinというものに取り組んだ。それがのちにSkywriterになったが、このプロジェクトは今休眠している。しかしCSSとHTMLによるエディタThimbleは、Mozillaが再び取り組んでおり、RougetはDevToolsの作品がエディタのメインのような書き方をしているものの、ブラウザ上のテキストエディタに関してはMozilla本体にも相当な経験と知識があることは確かだ。

デベロッパたちのもう一つのリクエストは、Chrome的Firebug的なネットワークパネルとタイムラインだ。チームはすでに、Webアプリケーションがネットワークをどのように使っているかを容易に見るためのツールの、プロトタイプを開発した。

Firefoxのチームは、ブラウザの互換性の向上にも取り組んでいる。Rougetによると、現状は“FirebugのユーザにとってFirefoxのDevToolsは邪魔者”という状況なので、それを何とかするためにMozillaは、コンテキストメニューの”inspect”メニューをディスエーブルにできるようにする。またFirebugをDevToolsのボックスに統合する方法も検討中だ。

そのほかにチームが今取り組んでいるのは、ブラウザの右側にドックツールを置けること（Firefox Nightlyではすでに実装）、CoffeeScriptのサポート、最小化したCSSとJavaScriptファイルのデバッグ、ページ上のリペイントされた部分が分かること（これもFirefox Nightlyにはある）。

Rougetによれば、チームはそのほかの機能にも取り組んでいる（イベント結合の視覚化、オフラインのストレージツール、擬似要素の検査、など）。

以上はどれも、すぐに実現するというものではなく、プロトタイプを脱するのに数か月かかりそうなのもある。でもデベロッパにとっては、こうやってMozillaがデベロッパツールの改良に励み、競合に負けまいとしている姿は大歓迎だ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

Appleがクッキーを利用しているアプリを拒絶へ: Ad Identifierへの統一がねらい

ios-cookie1

HTTPのクッキーを利用してユーザステータスを保存/取り出ししているモバイルアプリは今後、Appleが承認を拒否することになるだろう、と一部の業界筋が言っている。クッキーがあるおかげで、Safariブラウザを使ってそれを読むアプリは、たとえばユーザの広告との対話履歴などを知ることができる。その情報を読むためにアプリは、わざわざSafariを立ち上げる。そのおかしな振る舞いは良質なユーザ体験とは言えないが、今では廃れてしまったUDIDに代わってよく使われる。AppleがUDIDを廃止する計画を発表したのは、2011年の半ばだった。

UDIDは計40文字の数字と文字の文字列で、デベロッパや広告ネットワークはこれを利用してユーザに関するデータを集めることができる。UDIDそのものにはユーザ個人に関する情報はないが、ユーザのアプリ利用行動、対話的アクション、各種の入力などから得られる情報（名前、住所、好み、アプリの使い方などなど）にUDIDのタグを付けて保存しておけば、クッキー同様の利用価値がある。

AppleがUDIDの廃止を発表したのは2011年だが、Appleが実際にUDIDを使っているアプリを拒否し始めた昨年の初めごろから、デベロッパたちもついに、UDIDに代わる技術に殺到するようになった。クッキーもその一つだ。

クッキーはデスクトップ時代からある技術で、それが使われるようになってから今年で20年近くになる。モバイルでも技術的にはデスクトップと同じで、ユーザ側のストレージを利用して情報を記録する。また今のSafariのようなHTML5対応のブラウザでは、古典的なクッキーではなくHTML5のLocal Storage（Web Storage) APIを利用してユーザ情報を保存することもある。“Local Storageではデベロッパがトークン、すなわちユーザのIDを保存するので、クッキーと同じように使える”、とモバイルアプリのマーケティング企業Fiksuの事業開発担当VP Craig Palliが説明してくれた。

彼の会社は、Appleがクッキーを利用しているアプリケーションを拒絶するという話を、数週間前から聞いている。でも、実際にどれだけのアプリに‘被害’が出るのか、今の時点では明言できない、と言う。でもAppleは、同社の今後の方向性を業界に暗示しているのだろう、と。Appleのねらいは、デベロッパたちが今後、同社独自のAd Identifier技術を使っていくことではないか、とPalliは言う。

Advertising Identifierは、AppleのiOS 6の設定のところ（General –> About –> Advertising –> Limit Ad Tracking）で説明されている。そこには“将来はすべての広告ネットワークがAdvertising Identifierを使用しなければならない”、と書かれている。

つまりAppleは、クッキーなどに代わってこちらをスタンダードにしたいのだ。

limit-ad-tracking

“HTMLやHTML5の技術に依存せず、Apple独自の方法へ移行したい、という兆候は明らかにある”、とPalliはクッキーの拒絶についてこう言う。Appleが信ずる正しいユーザ体験とアプリのクッキー利用は、マッチしないのだ。アプリがいちいちSafariを立ち上げて、HTML/HTML5経由でユーザのストレージに勝手に書き込み/書き換えをやるところが、Appleから見ればだめなんだろうね”。

ユーザから見ても、目的のアプリのユーザインタフェイスが出る前にSafariをロードする、というアプリの振る舞いは、おかしいと感ずる。なにか、いかがわしいことをアプリがやっているのではないか、と感じてしまう。もちろん実際には、悪事はいっさい、やっていないのだけど。

UDIDについては、かなり前にAppleは廃止したにもかかわらず、その不使用をデベロッパに強制する措置は今のところない。Palliによると、UDIDを使っているアプリはまだとても多いし、またクッキーやデジタル指紋を使っているアプリもある。つまり、どれか一つに収束しつつあるのではなくて、いまだにばらばらだ。

Palliの指摘では、優秀なマーケターにとっては、方法が統一されてないほうがむしろ好都合だ。クッキーなど特定の方法を、使えないモバイル事業者もある。しかし大企業などは伝統的にクッキーだけしか使っていないので、そういうところは今回のAppleの新方針の犠牲者になるかもしれない。とはいえ、Appleとしても、そういうところには対応が難しいだろう、とPalliは言う。

彼自身が個人的に気にしているアプリは半ダース以下しかないが、でもその中にはダウンロード数が100万を超える大物もある。本誌TechCrunchが知ってる範囲でもPricelineやHotels.comのような超有名なアプリが、やはりクッキーを利用している。ただし今のところこれらのアプリは、クッキーの利用も含め、何もなかったかのように順調に動作するが。

アプリ測定プラットホームAppsFlyerのCEO Oren Kanielも最近のApp Storeのクッキー拒絶説を最初に耳にした人の一人だが、彼が旅行の予約アプリやモバイルの広告代理店から聞いた話では、今すでに、クッキーを使っているアプリは拒絶され始めているそうだ。Kanielは、App Storeに審査用に提出するアプリではクッキーを使っておらず、いったん承認されるとクッキーを使い始めるアプリもある（一部のアクセス分析/アプリの利用分析アプリなど）から、取り締まる側のAppleにとっても一筋縄ではいかない、と言う。

アプリのクッキー利用に関するリーダー格がAd-Xで、そこに今回の件に関するコメントを求めているが、まだ何も言ってこない（時差の関係か？）。コメントが得られ次第、この記事をアップデートしよう。

モバイルアプリの調査プロダクトを提供しているHasOffersのAryeh Altshulによると、同社はクッキーは情報の精度が悪いので使っていないから、Appleから拒否されていないが、確かにクッキーは劣悪なユーザ体験だ、と言う。“今でもアプリがクッキーを使っている企業は、主に初期からのモバイルゲームの企業で、未だに、技術を新しいやり方に変えていないところだ”、と彼は述べた。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）