Open Container Initiativeがコンテナの仕様の標準規格v.1.0をリリース

ついにやっと今日(米国時間7/19)、Open Container Initiative(OCI)が、そのコンテナランタイムとソフトウェアコンテナのイメージの仕様の標準規格、バージョン1.0のローンチにこぎつけた。この、今年で2歳になるオープンソースのファウンデーションは、Dockerをはじめコンテナエコシステムのリーダーたちが、まさにこれらの共通仕様を確立し維持管理するために作った組織だ。すなわちそれらは今後、コンテナのフォーマットとランタイムの業界標準になる。

Dockerは、これらの仕様の基盤となるものの多くをOCIに提供した。たとえば同社は、同社のコンテナランタイムのコードベースをOCIに寄贈した。さらにその後、同社の技術コミュニティがコンテナのイメージのフォーマットをOCIのプロジェクトに加えた。OCIの現メンバーは40社あまり、クラウドでプレイする大手テク企業のほとんどが参加している(AWS, Cisco, Facebook, Google, Huawei, IBM, Intel, Microsoft, Oracle, Red Hat, VMwareなどなど)。またRancherやWerckerのような、コンテナ技術を専業とする企業も、少なからず加盟している。

OCIの事務局長を務めるChris Aniszczykによると、たしかに、この組織における仕事の進め方やリリースの形式が決まるまで、かなりの時間がかかった。“同じコラボレーションでも、オープンソースのプロジェクトと違ってスタンダードの作成には困難な側面がある。オープンソースのプロジェクトでも、多くの企業がさまざまなやり方ですでに業務に使用しているものは、意見の違いが大きくなりがちだが、共通スタンダードについても同じことが言える”、と彼は語る。しかし、Linux Foundationの傘下となった今では、ガバナンスの構造も適正かつ安定してきた、と彼は感じている。この取材の席にいたDockerのStephen Walliは、こんだけたくさんのメンバーがいること自体、組織とプロジェクトの成功を物語っている、と付言した。

Aniszczykによると、仕様の策定作業でとくに大きく貢献したのがRedHat, Docker, CoreOS, そしてHuaweiだった。またFujitsu, Microsoft, Google, Oracle, Cisco, Tencentなども積極的に動いてくれた。

バージョンが0.xでなく1.0でリリースされたことは、そのスペックは一般的な採用が可能で、今後、採用者がコードを大きく書き換えなければならないような変更はない、ということを意味している。

今後の計画としてAniszczykは、次に取り組みたいのは検定(仕様への合致の証明)だが、そのほかに、すでに温めている企画として、現状のLinuxだけでなくそのほかのプラットホームのサポートと、レジストリのアクセスやコンテナの配布のためのAPIの標準化作業がある、と語った。

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

サービスメッシュ型コンピューティングの普及に賭けるBuoyantがシリーズAで$10.5Mを調達

Buoyantは、TwitterのインフラストラクチャエンジニアだったWilliam MorganとOliver Gouldが作った企業だが、同社は今日(米国時間7/11)、シリーズAで1050万ドルを調達したことを発表した。このラウンドをリードしたのはBenchmark Capital、これに、女性を中心とするTwitterの新旧役員グループ#Angelsと、これまでの投資家A Capital Ventures, Data Collective, Fuel Capital, SV Angel, そしてWebb Investment Networkが参加した。BenchmarkのPeter FentonがBuoyantの取締役会に加わるが、彼は数か月前にTwitterの取締役会を降りたばかりだ。

Buoyantは誰もが知ってる名前ではないが、オープンソースのLinkerdプロジェクトを作った企業だ。今年の初めにCloud Native Computing Foundationの一員となったこのプロジェクトは、いわゆる“サービスメッシュ”(service mesh)と呼ばれる、新しいインフラストラクチャツールの中で、たぶんもっとも人気のあるシステムだ。サービスメッシュ(サービスの網)とは、今日のアプリケーションを構成するさまざまなサービスを互いに通信/コミュニケーションさせるための、インフラストラクチャ層だ。たとえば、Kubernetesなどのコンテナオーケストレータの上で動く複雑なアプリケーションは、たぶん何百ものさまざまなサービスで構成されているだろう。これらのサービスは、静的とはとても言えないネットワークの上で、互いに通信できなければならない。LinkerdやIstioのようなサービスメッシュは、ロードバランシングとダイナミックルーティングを組み合わせて、それらのサービス間の通信を確保する。なお、Istioは、最近発表されたGoogle/Lyft/IBMのコラボレーションだが、今ではLinkerdと共用できる。

現在のLinkerdのユーザーには、Ticketmaster, Apprenda, NextVR, Houghton Mifflin Harcourt, Monzo(イギリスの銀行スタートアップ)などがいる。

“ソフトウェア産業の全体がクラウドコンピューティングへ移行すると、アプリケーションの作られ方や運用のされ方が大きく変わる”、 BenchmarkのFentonは今日の発表声明でこう述べている。“Buoyantによるサービスメッシュの導入は、マイクロサービスのコンポーネントやクラウドネイティブなソフトウェアと同じぐらい基本的な成分になる可能性がある。ネットワークプログラミングにとって、TCP/IPがそうであったように。そしてLinkerdが昨年思い切ってオープンソースを採用したことによって、そのニーズが企業にとって喫緊のものであることが明白になってきた”。

BuoyantのCEO William Morganによると、サービスの収益化についてはまだ何も決めていない。今度の資金は、エンジニアと製品開発部門の増員に充てられる。今社員は13名だが、エンタープライズユーザーにはすでに有料サポートを提供している。Linkerdを中心とするエコシステムを築くことが先決で、収益化云々に関心を向けるのは時期尚早である。“ある時点で方向を変えてお金を稼がなければならないけど、短期的にはオープンソースの採用が関心の中心になる”、と彼は語る。

企業のアプリケーションの開発が“クラウドネイティブ”型へ移行していくに伴い、Linkerdのようなプロダクトへのニーズもたちまち明らかになってくると思われるが、現時点ではまだ時期が早く、とくに大企業は歩みが遅い。しかしMorganによれば、アーリーアダプタたちの多くは大企業よりむしろスタートアップたちである。“彼らは今すでにクラウドネイティブのスタックへ移行しつつあるし、それには正当な理由がある”、とMorganは語る。“彼らは自分たちのアプリケーションをこのクラウドモデルで運用したいと願っている。それなら、ハードウェアのコントロールがほとんど不要だからだ”。

DockerとKubernetesがこのパズルの一片を解いたが、往々にして一つのソリューションが新しい問題をもたらすのだ。

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

Atlassianが全デベロッパーツールをワンセットにしたAtlassian Stackを年会費制でローンチ

Atlassianが今日(米国時間6/13)、Atlassian Stackという、新しい会員制のサービスを立ち上げた。それは、同社がホストしているデベロッパーツールをすべてまとめたサービスで、会費は1000ライセンスにつき年額18万6875ドルだ。これにより企業の調達担当は仕事が楽になり、費用削減にもなる(一見、高いけど!)。個々のプロダクトの会員ユーザーになるよりも、Atlassian Stackの会員になるとデベロッパーツールのすべてを手早く利用できて簡単なのだ。

Stackにはこんなものがある:

  • データセンターバージョン: JIRA Software, Bitbucket, JIRA Service Desk, Confluence
  • サーバーバージョン: JIRA Core, HipChat, Bamboo, FishEye, Crucible, Crowd
  • アドオン: JIRAのPortfolio, JIRAのCapture, ConfluenceのQuestions, ConfluenceのTeam Calendars
  • 有料サポート

デベロッパーがAtlassianの上で仕事をするには、これで十分だろうが、ただしファイヤーウォールの内側で使えるもののみだ。Atlassianのツールのホストバージョンはないが、このようなバンドルに関心のある企業は、自社独自のデプロイをするところがほとんどだろう。

1000ライセンスの料金は一人あたりの月額で15ドル57セントになる。1万ユーザー以上もいる超大企業は、一人あたり月額が6ドル74セントになる。

Atlassian Stackに加えて今日同社はDevOps Marketplaceをローンチした。この新しいストアはAtlassianのユーザーに、200以上のアドオンとインテグレーションへのアクセスを提供する。現在のパートナーはAppDynamics, Splunk, そしてSauce Labsだ。Atlassianにはすでにマーケットプレースはあるが、この新作はDevOpsツールが中心だ。

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

‘サーバーレス’のブームに乗り遅れなかったTwilio Functionsはデベロッパーがサーバーのことを忘れて通信アプリケーションを書ける

デベロッパーに通信APIを提供しているTwilioが今日(米国時間5/25)、Twilio Functionsというものを立ち上げて、世に言う“サーバーレス”プラットホームの仲間入りをした。FunctionsもAPIの一種だが、これを使うとデベロッパーは、サーバーの運用とかインフラストラクチャの管理、スケーラビリティなど低レベルの問題をすべて忘れて、自分のイベント駆動アプリケーションの構築に専念できる。

Twilioの今日の発表声明でプロダクト担当VP Patrick Malatackはこう言っている: “コードは書くことはクリエイティブな仕事だから、たとえばクラウドを利用する通信アプリケーションを作るデベロッパーや企業は、顧客がそれから得る体験に集中すべきであり、サーバーの管理に時間と精力を取られるべきではない。通信の未来を築くのはデベロッパーの創造力であり、Twilio Functionsはそれを支える。これを利用するデベロッパーの仕事ぶりを見るのが、今から待ち遠しい”。

というわけで、インフラのメンテナンスやスケーリングに煩わされることなくデベロッパーは、一連のファンクションを使って自分のコードをTwilioのプラットホーム上で動かせる。たとえばそれは、新たにSMSのメッセージが来るたびに何かをするアプリケーション、だったりするだろう。具体的には、デベロッパーはJavaScriptでコードを書く。するとTwilioはそのコードをNode.jsの標準的な環境で実行する。そのNode.js環境は、Twilioのインフラ上にある。

率直に言って、“サーバーレス”は、ぼくのあまり好きくないバズワードの筆頭だ(“ハイパーコンバージド”と肩を並べるかな)。たしかにそれは、サーバーなどのインフラを抽象化してデベロッパーの念頭から消し去ってしまうけれども、プログラミング上の重要な含意は、それよりむしろ、入ってくるイベントに対応してコードの実行がトリガされる、イベント駆動型のプログラミングである、という点にある。

このイベント駆動モデルのもうひとつの約束は、計算機資源の使用料を、実際に使ったぶんだけ払えばよい、ということにある。たとえばTwilio Functionの場合は、最初の10000リクエストは無料、その後は1リクエストごとに0.0001ドルだ。リクエストに(==イベントに)応じて、静的ファイルをサーブしてもよい。その場合も、最初の10000リクエストは無料、その後は1回につき0.0001ドルだ。

これらすべてを動かすのがTwilio Runtime、そこにはヘルパーライブラリやAPIのキー、構成済みの諸資産、デバッグツールなどがある。

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

Red Hatがコンテナ化アプリケーションを開発するためのクラウドIDE、OpenShift.ioを立ち上げ

Red Hatが今日(米国時間5/2)、OpenShift.ioを立ち上げた。それは同社としては初めての、本格的なクラウドベースのデベロッパーツールだ。その名が示すように、OpenShift.ioは、Kubernetesをベースとする同社のコンテナ管理プラットホームOpenShiftを使用し、クラウドネイティブでコンテナを利用するアプリケーションの構築に必要なツールを提供する。それらは、チームコラボレーションのためのサービス、アジャイルプランニングのツール、デベロッパーのワークスペース管理、コーディングとテストのためのIDE、モニタリング、そしてもちろん、継続的インテグレーションとデリバリのサービスだ。

方向性はやや違うが、これはいわば、MicrosoftのVisual Studio Team ServicesのRed Hatバージョンだ。しかしRed Hatがここでやっているのは、fabric8, Jenkins, Eclipse Che, それにもちろんOpenShiftといった既存のオープンソースプロジェクトをひとつのサービスにまとめて、主にコンテナベースのアプリケーションにフォーカスした体験を提供することだ。

OpenShift.ioは中でもとくに、チームのコラボレーションを重視し、そのためのさまざまな開発方法論や哲学をサポート、そしてソースコントロールシステムを提供している。またプロジェクトマネージャーやビジネスアナリストなど、チーム内のノンプログラマーがプロジェクトの状態を追えるためのツールも、充実している。

Red Hatでプロダクトとテクノロジーを統轄するPaul Cormier社長が、今日のブログ記事で述べている: “Red Hatは、クラウドネイティブと従来型の両方のアプリケーション開発に取り組むための、オープンで自由度が高く安全なツールを、標準的ツールをベースとする全体的に斉合性のあるプラットホームとして提供している。今日私たちはご覧のように、Red HatのコンテナプラットホームOpenShiftを利用してコンテナ化されたアプリケーションを構築するための、クラウドベースのフレームワークを立ち上げる。それは、今日の類似製品の中でもっとも総合的な、エンタープライズ向けKubernetesプラットホームだ”。

Red Hatは今日、OpenShift.ioのほかに、Red Hatおよび同社のISVパートナーたちのすべてのコンテナ関連製品の、セキュリティや安定性などを調べて評価できるContainer Health Indexを発表した。またもうひとつ今日ローンチしたRed Hat OpenShift Application Runtimesは、マイクロサービスのための、構築済みのコンテナ化ランタイムの基盤群だ。これらのランタイムには、Node.js, Eclipse Vert.x, WildFly Swarmなどのサポートが含まれる。

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

Google AssistantのSDKをデベロッパーに提供、製品のプロトタイプへの使用は自由で無料

Googleは前から、Assistantをさまざまなハードウェア企業やデベロッパーから成る大きなエコシステムへ公開したい、と言っていた。今日(米国時間4/27)同社はその方向へ大きく一歩前進し、Google AssistantのSDKローンチした。デベロッパーはこれを使って、自分のハードウェアにAssistantの知能を組み込める。たとえばスマートミラー(鏡)とか、Google Home的な器具や装置、絶対禁酒を誓った人が秘かに楽しむロボットのバーテンダー(上図)など、何でも好きなものを作れる。

ただしGoogleのAPIを自由に使えるのは、プロトタイプを作るときだけだ。商用製品を作るときには、Googleの正式の許可が要る。

SDKはPythonのコードで提供され、人気のRaspberry Pi 3をはじめ、さまざまなハードウェアプラットホームで使える。GoogleのgRPC APIを使えば、Assistantをそのほかのハードウェアプラットホームにも統合でき、またJava, C#, Node.js, Rubyなどの言語を使える。このSDKを使えば、自分のハードウェア製品が音声コマンドを聞き取り、それらをGoogle Assistantのサービスに送り、適切な応答を受け取ることが容易にできる。

Googleによると、SDKを使っているデバイスはAssistantのすべての能力を利用できる予定だが、現状は違う。リリースノートにはたとえば、アラームとタイマーをセットできない、と書いてある。音楽の再生、ニュース、ポッドキャストもだめだ。ホームオートメーションの機能の多く、および、Uberなどサードパーティサービスの呼び出しは、まだGoogle Homeにしかできない。

Assistantに話しかけるAPIはすでに公開されている。この“Actions on Google” APIは、サードパーティのアプリケーションをGoogle Homeに統合するためのものだ。またPixelスマートフォンや今後のAlloでも、Assistantがサポートされる。

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

Cloud Foundryがクラウドネイティブのスキルを涵養するためデベロッパー資格認定事業を開始

Cloud Foundryは大規模なオープンソースプロジェクトで、企業はこれを利用して自社専用のPaaSをホストし、自分のデータセンターやパブリッククラウドでクラウドアプリケーションを動かす。同社は今日(米国時間3/29)、そのためのデベロッパーを育成するため、“Cloud Foundry Certified Developer(Cloud Foundry認定デベロッパー)”事業のローンチを発表した。

Cloud Foundry Foundationはこれを、“世界最大のクラウドネイティブデベロッパーの資格認定事業”、と呼ぶ。その成否を今から云々することはもちろんできないが、すでにDell EMC, IBM, SAP and Pivotal(Cloud Foundryのインキュベーター)などが支援している。同社はLinux Foundationとパートナーして、そのeラーニングインフラストラクチャから資格認定事業を提供していく。〔*: クラウドネイティブ, 既存の何かをクラウド化するのでなく、最初からクラウド上で動くものとして開発すること。〕

目に見える資格認定があれば、デベロッパーはオープンソースのクラウドに関する自分のスキルを他に示すことができる。この事業は、現在Cloud Foundryをサポートしている大手のパブリッククラウドプラットホームすべてを対象とする。それらは、Huawei, IBM, Pivotal, SAP, Swisscomなどだ。

約4時間で終わる300ドルの試験は、Cloud Foundryの基礎、クラウドネイティブなアプリケーションのセキュリティ、アプリケーション管理とコンテナの管理などをカバーし、また、JavaやNode.js、Rubyなどで書かれたシンプルなアプリケーションの書き換えも試験に含まれる。範囲がきわめて広いと思われるが、でもこれだけの分野で有能なデベロッパーなら、仕事を見つけるのも早いだろう。

Cloud FoundryのCTO Chip Childersが今日の発表声明で言っている: “企業はクラウドネイティブなアプリケーションを構築し管理できるデベロッパーを必要としており、そしてデベロッパーは仕事が必要だ。弊社はそこにある大きなギャップに着目し、デベロッパーとエンタープライズの両者が必要とするものを提供することを、弊社の機会と認識している”。

この事業の立ち上げは、必ずしも意外ではない。Childersはすでに昨年の11月に、これを今準備中、と語っていた。

この資格認定事業は今はベータで、一般供用は6月13日からになる(その日はCloud FoundryのSummit Silicon Valleyカンファレンスの初日で、そこでデベロッパーは個人でこの試験を受けられる)。

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

CoreOSのKubernetesデプロイサービスTectonicがAzureとOpenStackをサポート

CoreOSはたぶん今でも、Linuxのディストリビューションとしていちばんよく知られていると思うが、でも今やそれは、同社の多様なサービスへの、敷居の低い入り口にすぎない。今同社のビジネスの核になっているのは、KubernetesをベースとするコンテナデプロイサービスTectonicだ。これまでTectonicは、KubernetesをベアメタルとAWSにインストールし管理していたが、今日から(米国時間3/23)は、AzureとOpenStackをサポートする。この二つのプラットホームのサポートは、現在、プレビューである。

具体的には、近くオープンソースのCoreOS Tectonic Installerというものが提供されるので、ユーザーはそれを使ってKubernetesのクラスターをAzureやOpenStackの上にセットアップする。ここにGoogleのCloud Platformが欠けていることが目立つが、それも今後十分な需要があればきっとサポートされるだろう。

以前と同様、Tectonicは10ノードまでのデプロイは無料だ。同社のサービスを利用してどうやってKubernetesのクラスターをセットアップするのか、同社は初心者のための実地演習チュートリアルを数種提供している。

CoreOSのもうひとつのメインサービスQuayは、エンタープライズ向けのコンテナレジストリだが、Kubernetesベースのアプリケーションをサポートするために拡張されたQuayもある。そのレジストリには、複数のコンテナイメージのほかに、アプリケーションの構成ファイルなども収まる。

“新しいレジストリプラグインを使うと、Helmが直接Quayと対話して、アプリケーションの定義を取り出し、それを使って必要なイメージに構成を適用し、アプリケーションを成功裡にデプロイする”、と同社は今日の発表声明で述べている。“これらはすべて、App Registryと呼ばれるコミュニティのAPI仕様で行われるので、Kubernetesのエコシステムはより高度なツールとより信頼性の高いデプロイパイプラインを開発できる”、という。

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

App Store、定期購読より有料アプリを優遇してトップチャートを正常化するテストを実施

apple-app-store-ios

この週末Apple App Storeのトップセールス(Top Grossing)チャートに、あまり知られていない有料アプリがいくつか登場した。App Storeが新しいアルゴリズムをテストしているのか、かなり大きなバグなのかどちらかと思われる。この状態が始まったのは金曜日で、トップセールスアプリだけの現象のようで、トップ無料とトップ有料アプリでは起きていない。

しかしトップセールスチャートは、全体チャートだけではなくApp Storeの全カテゴリーが影響を受けている。

あるデベロッパーによると、自分たちのアプリはカテゴリーで2位だったのが35位に下がったという。これが彼らに問題を知らせた最初の警告だった。その日は非常に好調で、過去最高の月になるかもしれない時だった。

先週末を通じて、トップセールスチャートでふだん上位を占めていたアプリが順位を下げ、人気の低いアプリが取って代わった。まるでアルゴリズムが有償アプリをアプリ内購入で稼ぐアプリより優先するようにアルゴリズムが変更されたかのようだ。

例えば、 アルゴリズムの変更は一部の絵文字アプリに有利に働いていてSteph CurryのStephMojiもその一つだ。しかし、絵文字アプリがいくつか急に人気を得るのはわからないでもないが、もっとニッチなContruction Manager Proや15ドルの翻訳アプリがチャートに登場するのは場違いに感じる(下の画像参照)。

unnamed

Image Credit: Sensor Tower

ソフトウェアメーカーのEquinuxが提示する一つの理論は、Appleが新アルゴリズムの実験を行っていて、定期購読による収益のウェイトを減らし、有料アプリを重視しているのではないかというものだ。

このところトップセールスチャートが停滞気味であることを踏まえると、これは理にかなっている。

近年App Storeのトップセールスチャートは、SupercellのClash RoyaleやCandy Crush、ポケモンGO等の常連人気ゲームと、Netflix、Pandora、Spotify等のトップストリーミングサービスで占められている。

最近Appleは定期購読サービスを拡大して、これまで以上に多くのアプリが利用できるようになっ たが、定期購読アプリの人気が高くなったためにトップセールスチャートには同じ顔ぶれのアプリが並ぶ傾向にある。これでは新しいアプリが割り込むのが難しくなり、チャートを見る楽しみが半減する。

変更されれば、有料アプリは定期購読アプリと同じ条件で競えるようになる。新アルゴリズムは定期購読の最初の新規利用分だけを勘案し、更新は考慮しなくなるらしいからだ。

インディー系アプリにとっては歓迎すべき変更で、ビッグネームと並んでランキング入りするチャンスがようやく巡ってくる。

残念ながらそうはならなかった。月曜日(米国時間2/20)の午前0時、すべてが元に戻った。

もちろんこれは、AppleがApp Storeのアルゴリズムについて少なくとも〈考えている〉ことを示すものだ。ただし、アプリの発見にどれほど効果があるかはまた別の問題だ。トップチャートで何がトレンドかを見るユーザーも何パーセントか存在するだろうが、大方はApp Storeをキーワードで検索するか、まとめ記事を見るのが普通だ。ともあれトップセールスチャートは改変の時期を迎えているので、Appleが今後もこの種の実験を続けても不思議はない。

[原文へ]

(翻訳:Nob Takahashi / facebook

DigitalOceanがロードバランサーを現料金内で提供開始、徐々に本格的なクラウドコンピューティングサービスへ成長中

hero-6c0992e2

DigitalOceanが今日から、このプラットホーム上でアプリケーションを運用しているデベロッパーのために、ロードバランスサービスの提供を開始する。ロードバランサーは比較的単純明快なプロダクトで、DigitalOceanの場合も、サイトへの接続を複数のサーバーに分散することによって、アプリケーションの良好なアップタイムを保証する。言い換えると、トラフィックにスパイクがあっても、ロードバランサーがあれば一箇所のエラーですべてがだめになることはないから、顧客へのサービス性が向上する。ただし、一つしかない(バックアップのない)データベースがダウンしたら、上記の‘一箇所のエラーで云々’という説は通用しなくなる。

これまでDigitalOceanのユーザーは、ロードバランサーを自前でセットアップしていた。しかしこれからは各月20ドルの料金にロードバランサーの利用も含まれ、同社のダッシュボードやAPIからアクセスできる、プロトコルはHTTP, HTTPS, およびTCPをサポートしている。またロードバランサーのアルゴリズムをラウンドロビン最小接続の二つから選べる。

2017-02-13_1612

ロードバランサーのセットアップは、数クリックで終わる。時間にして1分足らずだ。利用できる圏域は、DigitalOceanの全世界の全リージョンだ。

DigitalOceanによると、同社の登録ユーザー数は100万に近く、現在のアクティブユーザーはデベロッパーのチーム数で言って4万あまりだ。同社は今日までずっと基本サービスの規模拡大で忙しくて、関連サービスの提供が遅かったが、そろそろその悪癖も、改まりつつある。これまでは単純に安く使える仮想プライベートサーバーが売りだった同社も、今では本格的なクラウドコンピューティングプラットホームを目指している。たとえば昨年はストレージサービスを開始したし、また複雑なアプリケーションを高い可利用性で提供できるフローティングIPを導入した。そしてさらに最近は、改良されたモニタリングサービスの提供も開始した。

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

AWSがローンチするBloxはEC2 Container Serviceのためのオープンソースツールのコレクション

img_20161201_102504

AmazonのクラウドコンピューティングプラットホームAWSはかなり前から、EC2 Container Service(ECS)でもってソフトウェアコンテナのサポートを提供してきた。今日の同社のデベロッパーカンファレンスre:Inventで同社は、コンテナのサポートの仕方に関するいくつかのアップデートを発表した。コンテナは今や、分散アプリケーションを運用する方法の定番とも言える地位に、急速に上(のぼ)りつめている。

まず、EC2のこのコンテナサービスは、カスタマイズの幅が広がる。とくに、Task Placement Engineと呼ばれるツールにより、デベロッパーはコンテナを特定の可利用域に配置できるようになる。

“コンテナの管理と実行は、弊社の少なからぬ顧客にとって、とりわけ一部のオープンソースソフトウェアを使った場合、苦労が多すぎた”、とAmazonのCTO Werner Vogelsが今日のキーノートで述べた。ECSの今回のアップデートは、その苦労の一部を軽減することが目的で、AWS上でコンテナを使うユーザーに、より多くの柔軟性を与える。

また今日Amazonが発表したBloxは、ECS用のコンテナ管理ツールを作るためのオープンソースプロジェクトのコレクションだ。たとえばコンテナのスケジューラーを作りたければ、MesosのようなサードパーティのスケジューラーをECSに統合できる。

Bloxが最初に提供する二つのプロジェクトは、どちらもGitHub上にある。それらは、クラスターのステートをチェックするサービスと、デーモンのスケジューラーだ。これまでオープンソースのコミュニティとは比較的‘浅い仲’だったAWSにしては、興味深い動きだ。しかしコンテナのエコシステムはその大半がオープンソースのプロジェクトに支えられているから、Amazonとしてもそろそろ積極的に関わった方が得策かもしれない。BloxプロジェクトはApache 2.0のライセンスで公開される。

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

AWSがパートナーをサポートする多彩な新事業をローンチ、とくにIoTと金融サービスを重視

img_20161129_121008

Amazonのクラウドコンピューティング部門であるAWSが今週、今年のre:Inventデベロッパーカンファレンスをラスベガスで行っている。そのメインイベントに先立って同社は今日(米国時間11/29)、AWSのツールやサービスを売っている同社のエコシステムパートナーのためのキーノートを開催した。そのキーノートで同社は、パートナー事業の大幅な拡張と、ソフトウェアやAPIやそのほかのサービスをAWSのマーケットプレース(AWS Marketplace)で売りたいベンダのための、新しい機能もいくつか発表した。

AWSが発表した新しいパートナー事業はいくつかあり、ひとつは公共部門へ売っていきたい企業向け、もうひとつはAWSのサービスを使おうとする顧客企業を支援する立場のパートナーだ。それらAWSのサービスとは、Redshift, Lambda, Kinesis, Machine Learningなどなどだ。さらに加えてAWSとVMwareは、2017年に統合パートナーシップ事業を発表し、またAlexaのスキルを作っている企業だけのためのパートナー事業も開始される。

これらのパートナー事業に参加した企業は、市場開発のための資金や、さまざまなマーケティング素材、自分のマーケティング素材をブランド化できるたものバッジなどにアクセスでき、場合によってはPartner Solutions Finderでフィーチャーされる(大きく扱われる)。これらの事業はテクノロジー系企業と、コンサルティング系企業の両方を対象とする。

さらにまた、AWS上でIoT金融アプリケーションを立ち上げるユーザー企業を支援する能力のあるパートナーのための事業もある。これらの新しい事業は、マイグレーションやストレージ、DevOps、セキュリティ、ビッグデータなどに注力していくそれらの企業のための既存の事業に加わる形になる。

今回Amazonは、中でもとくにIoTソリューションをAWS上で充実していくことに大きな関心があるようだ。今日のキーノートではAWSのJames Hamiltonが、わざわざ、インターネットに接続された自分のボートを、未来志向の企業にできることの例として挙げたほどだ。これら新しいパートナー事業に参加できる企業の要件を、Amazonは詳細なリストにまとめている。たとえばIoT企業に関しては、これがそのリストだ。

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

GoogleのDartプログラミング言語に再びスポットライトが…その高い生産性にまず社内で人気が盛り上がる

3351037214_1fabfbe31d_o

昔々、GoogleのDartプログラミング言語は、今すぐにもJavaScriptに置き換わって、Webのデフォルトの言語になる、と思われていた。Googleは同社のブラウザーChromeで、JavaScriptと同格の扱いをしたほどだ。しかしDartがそうやってスターになりつつあったときでも、JavaScriptと、それを取り巻く分厚いエコシステムは、すでに数マイル先を走っていた。ほぼ1年前にGoogleは、DartをJavaScriptの直接的なコンペティタと見なすことをやめ、位置づけをJavaScriptへコンパイルされる言語と変えて、TypeScriptやCoffeeScriptなどと同列に置いた。

                       [クリックすると文字を大きく表示]
screenshot-2016-10-25-at-18-37-54

その後、Dartの周辺は静かになった。しかし今、それが変わろうとしている。Googleは今週ミュンヘンでDartデベロッパーカンファレンスを開催し、Dartに再び、ステージのライトを当てた。Googleの内部でも、Dartは大きく成功している。今ではAdWordsとAdSense(Googleのメインの収益源を駆動)、およびGoogle Fiberのチームが、消費者向けのWebアプリケーションをDartで書いている。AdSenseのアップデートはすでに本格稼働し、AdWordsの次世代インタフェイスは目下テスト中だが、近い将来には前よりも広範囲にローンチされる。GoogleのこれらDart愛用チームは、開発スピードが25〜100%アップした、と報告している。Google内部で今いちばん急成長しているプログラミング言語は何か、といえばそれはDartだ。コードの行数で言うと、Dartで書かれたコードの量は昨年比で3.5倍以上になっている。ただし3.5倍と言っても絶対数はそんなに大きくないから、びっくりするほどの数値ではない。

Google以外では、Wrike, Workiva, Blossomなどの企業がDartで製品開発をしている。つまりGoogleの外にも、Dartユーザーのコミュニティは確かにある。

Dartの協同ファウンダーKasper Lundは、最近のDartの巻き返しについて、“最初が頑張りすぎだ。Dartのランタイムをブラウザーに組み込んで今日的なWebの全体を狙うなんて、とてもついていけなかったな”、と、言語の初期を回想する。しかしランタイムがChromeに載ることがなかったとしても、言語自体とそのツールは大成功だった。それはDartからJavaScriptへのコンパイラーをすでに彼らが作っていて、Dartで書いたコードがChromeの外でも動く、という状態が確立していたからだ。Dartコードがいちばん速く動くのは、Chrome上だったけれども。

そこでチームはランタイムの開発を断念し、DartからJavaScriptへのコンパイラーおよび関連ツールの開発に専念した。

DartとJavaScript両方のランタイムがChromeにあると、二つの言語間の対話がかえって困難になった、とLundは述べる。ランタイムを放棄した今では、その問題もなく、最初そのために苦労して作り出した依存性も、すべてなくなった。逆に今のDartは、サードパーティツールとの協働が容易だ。チームが今とくに力を入れているのがAngularで、それはWebアプリケーションとモバイルアプリを作るためのGoogleのJavaScriptフレームワークだ。

Angular 2.0はデフォルトでMicrosoftのTypeScriptを推奨言語としている。でも今日ベータを終了したAngularDart 2.0では、当然ながら推奨言語はDartだ。今週のミュンヘンのイベントでは、たくさんの、AngularDartによるMaterial Designのコンポーネントがデベロッパープレビューとしてリリースされた。それらの、データピッカー等々は元々、Googleの社内チームのために開発されたものだ。

Dartにはstrong modeというオプションがあって、そのモードではDartが強い型付けのある言語になり、ジェネリックメソッドも使える。なお、JavaScriptへのコンパイル速度は、今や多くの場合1秒未満だそうだ。〔本来のJavaScriptは型付けが厳格でない言語…楽だけどある意味危険。〕

ひとつのアプリのiOSバージョンもAndroidバージョンも書くコードは一つでOK、というGoogleのプロジェクトFlutterは、今プレビューの段階だが、使う言語はDartだ。Flutterのウィジェットは、関数型反応型フレームワーク(functional-reactive framework)を使っている。reactive?!、そう、その基本的な考え方はFacebookのReactと同じだ(Flutterのチームもそれを認めている)。今のところは、Reactが相当前の方を快調に走っているが、Googleの基本的な考え方は、デベロッパーに完全なDartツールキットを提供して、多くのユースケースに対応していただくことだ。

というわけでDartは今、Google内部で人気が盛り上がっているが、Googleは社内で終わらせたくないからこそ、今週のミュンヘンのイベントを開催したのだ。でも、その歴史が歴史だけに、多くの外部デベロッパーをその気にさせるためには、今後なお一層の努力が必要なことは、今からすでに明々白々だ。

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

Android 7.1のデベロッパープレビューがついにベータテスター向けに公開開始、最終安定バージョンは12月に

Freshly made nougat for sale

もはや大きなサプライズではないが、今月の初めにGoogleは、Android 7.1 NougatのデベロッパープレビューとSDKツールを今月の終わり頃公開する、と発表し、そして月半ばを過ぎた今日、そのプレビューがAndroidのベータに参加していた人たち向けに、まさに公開された

Androidのベータ(Android Beta Program)は主にデベロッパー向けだが、デベロッパーではないけど単純に好奇心旺盛な人でも、Android 7.1を試そうと思えば試せる。ただしまだベータだから、まだバグは多いかもしれない(だからぼくは、自分の日常用のスマートフォンにはインストールしない)。

2016-10-11_1134

こないだ発表されたGoogle Pixelには、このAndroid 7.1がすでに載っているから、現状はもうかなり安定しているのだろう。でもPixelの最新機能の数々は、そのほかのデバイスにはない。だからたとえば7.1をNexus 6Pにインストールしても、Google Assistantの全面的な機能はない。

Googleの計画では、11月にもう一度プレビューを出し、最終バージョンは12月になる。Nexus 5X, 6PやPixel Cのオーナーでベータに参加している人は、もうすぐ自動アップデートに出会うだろう。最終リリースはNexus 9, Nexus Player, それにAndroid Oneのデバイスにも来る。もちろん、新しいPixelスマートフォンにも。

Android 7.1の新しい機能は、本誌の記事が紹介している。そう多くはないが、どれも、とても便利だ。

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

開発のサーバーレス化を助けるServerlessがシードで$3Mを調達、ただしサーバーレスはサーバーが動かす

fb_data_center_tour-6

Serverlessはデベロッパーたちに、彼らがAWS Lambdaや、今後のMicrosoft Azure FunctionsGoogle Cloud Functionsなどを利用して、なるべく容易にアプリケーションを書けるためのフレームワークを提供する。同社は今日(米国時間10/12)、Trinity Venturesがリードするシードラウンドで300万ドルを調達し、そのフレームワークがベータを終了したことを発表した。

Serverlessという社名の起源でもあるサーバーレスという流行(はや)り言葉は、一種の誤称でもある。このサーバー‘レス’という考え方は、実際のインフラストラクチャが抽象化されていて隠されている、という意味であり、そのためにデベロッパーは自分のコードを、通常はLambdaのようなイベント駆動の計算サービス(compute services)へ、単純にデプロイできるのだ。そしてそれらのサービスがそのコードを、イベントにトリガされて実行する。でもそのコードはもちろんすべて、AWSのサーバーの上で動くのだ。

でも、今では名前がひとり歩きしていて、ServerlessのファウンダーでCEOのAusten Collinsも、エンタープライズやスタートアップがこの新しい計算モデルをより容易に利用できるためのフレームワークを作れる、とひらめいた人たちの一人だ。“まず、これはおもしろい、と思ったし、サーバーレスのプラットホームを動かすためには大量のサーバーが必要だから、本当は正しくない言葉だけれど、デベロッパーたちが待ち望んでいたものを言い表す、とてもぴったりの言葉だ、とも思った”、とCollinsは語る。

Serverlessを創る前のCollinsはAWSのコンサルタントで、アプリケーションの開発とデプロイをもっとはやくやりたい、と願う企業がとても多いことを痛感していた。“Lambdaに着目したのも、そのためだ”、とCollinsは述べる。彼がとくにLambdaを気に入った理由は、AWSのそのほかのいろんな機能を、容易に併用できることだった。複雑なアプリケーションを小さなパーツに分割して、それらがAPIで連結する、いわゆるマイクロサービス方式の開発が関心を集めるようになり、保守的な大企業ですら今では、Lambdaのようなプラットホームを利用して開発サイクルをスピードアップしたい、と望んでいる。

Serverlessは、スタートアップやデベロッパーのプロダクトの市場化を助けるHeavybitの育成事業から巣立った。StripeやPagerDuty、CircleCIなどもその同類だ。同社の社員は今12名、Collinsの計画では今回の資金を、フレームワークの開発を担当するデベロッパーの増員と、AWS以外のクラウドコンピューティングサービスのサポートに充てたい、という。

ただし、まだ決まっていないのが収益化の方法だ。Collinsは今検討中だ、と言うが、オープンソース企業によくある、有料コンサルティングサービスとか、有料の特殊機能などが妥当な線かもしれない。このような企業の収益化に関しては、HeavybitとTrinity Venturesの両方に、良い知恵があるはずだ(Trinityは前から、Dockerや類似のデベロッパー企業に投資している)。

GitHub上で同社のプロジェクトは11000あまりのスターをもらい、ユーザーの中にはCoca-Cola Companyのような有名企業もいる。つまり、サーバーレスという言葉はまだ若いのに、このフレームワークに対する需要と関心は、すでに確実に存在している。

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

App Storeから追放される不良iOSアプリは数十万のオーダーになりそうだ

app-store-graveyard1

【抄訳】
Appleが最近発表した、App Storeから古くて一定の基準に合わないアプリを取り除くという予告の、対象になると思われる、見捨てられたアプリは、最新のデータ(後述)によると数十万にのぼることが分かった。ただしAppleの言い方は依然抽象的で、“意図されたとおりに機能しない”、または、“現在のレビューのガイドラインに従っていない”、または、“長期間、互換性アップデートによりサポートされていない”アプリが削除される、という。

上の最後の“長期間”は、具体的にどれくらいの期間なのか。それによっても、追放されるアプリの数は変わるだろう。

でも今日(米国時間9/6)得られた数字からは、リリースされたけどその後メンテナンスされていないアプリの数が意外と多いことが分かる。

上位にいるアクティブなアプリデベロッパーは、少なくとも毎月または隔月で、自分のアプリをアップデートしている。昨年のある記事によると、上位のiOSデベロッパーはアップデートの平均間隔が45日である。小さなインディーのデベロッパーは、そこまでできないかもしれない。でも、アクティブにメンテナンスされているアプリとは、少なくとも年に一回はアップデートされ、OSやハードウェアの更新に対応している、と考えるのが妥当だろう。

しかし、多くのアプリが、そうではない。

今日、App Storeのアクティブなアプリは全世界計で210万ある。しかし、アプリのマーケターたちのためのビジネスインテリジェンス企業Adjustのデータによると、すべてのアプリの50%が2015年5月以降、放置されている。このように、App Storeの半分が追放を検討されることになれば、Appleのこのマーケットプレースの姿は大きく変わることになるかもしれない。

chart-with-annotation

時間をやや延ばして2013年以降とすると、その間にアップデートされていないアプリは全体の25.6%になる。また逆に、最近の3か月でアップデートされたアプリはわずかに20%だ。App Storeのデビュー以降一貫してメンテナンスされているアプリは、ほとんどない、と言えるのではないか。

一方、App Storeから蹴りだされることが確実と思われるアプリのグループは、iPhone 5以降の大型画面に対応するためのアップデートをやってないアプリだ。Adjustによると、全アプリの11.4%がこれに該当し、またすべてのiOSアプリの10%が、iPhone 4以降放置されている。

もうひとつのアプリインテリジェンス企業Sensor Towerによると、32万8000のiOSアプリが3年以上前からアップデートされていない。これらすべてにAppleからの通知が行っても、意外ではない。一方Sensor Towerのデータでは、過去3か月以内にアップデートされたアプリは全体の約40%だ。ただし6.5%は、iPhone 6以降をサポートしていない。

App Storeにおけるアプリの検討評価と削除の作業は、明日(米国時間9/7)始まる予定だ。iPhone 7の発表イベントと同じ日である。同社によると、立ち上げ時にクラッシュするアプリはただちに排除される。そのほかの問題アプリは、Appleからのアップデートリクエストに、デベロッパーが30日以内に応じなかったら、App Storeから取り除かれる。

【後略】

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

Facebookが新しいオープンソースプロジェクトでReactの敷居を低くする

BERLIN, GERMANY - FEBRUARY 24:  The Facebook logo is displayed at the Facebook Innovation Hub on February 24, 2016 in Berlin, Germany. The Facebook Innovation Hub is a temporary exhibition space where the company is showcasing some of its newest technologies and projects.  (Photo by Sean Gallup/Getty Images)

FacebookのReactは、JavaScriptで手早くアプリケーションとそのユーザーインタフェイスを作りたいときのための、オープンソースのライブラリだ。ただし、実際の話はこれほど単純ではない。Reactでアプリケーションを作るためには、JavaScriptのほかにも、いろんなツールを勉強しなければならないのだ。

FacebookはReact用の自社のツールについて語っているが、でも個人のデベロッパーやスタートアップの多くは、Facebookのような企業が持ってるリソースがない。

そこで、もっと多くの人がReactで仕事ができるために、同社は今日(米国時間7/22)、新しいオープンソースプロジェクト”Create React App”(Reactアプリケーションを作ろう)を立ちあげた。それは、あるハッカソンから生まれたプロジェクトで、Reactでアプリケーション開発を始めるために必要なツール集合を、たった一つのコマンドラインツールにまとめたものだ。

[Marcはあとちょっとで彼のReactの”hello world”アプリケーションを実装できるところだった]〔実際には複雑すぎてできなかった〕

FacebookのDan Abramovが今日の発表声明で次のように述べている: “従来、このようなプロジェクトはうまく行かないことが多かった。しかし先日、Christopher [Chedeau]がぼくに、複数の’React CLI’(Reactコマンドラインインタフェイス)を作り始めたけど、Facebookには無視された、と言った。コミュニティにも、同じような目標のツールが存在している。でも今のところは、それほど人気がない”。

Create React App(すごい分かりやすい名前だ!)の場合は、構成ファイルというものがない。環境のセットアップは、自動的に行われる。しかも、デベロッパーが手にするのは単一のツールだ。だから依存性も単一だ。しかし内部的には、JavaScriptやReactのエコシステムの既存のツールをたくさん利用している(Webpack, Babel, ESLint, などなど)。

このツールがユーザーをロックインしないことも、強調されている。この種のサービスでは、よくあることだが。ユーザーはつねに単一のコマンドを発行し、それが基本的にやるのは、ユーザーの構成を‘イジェクト’して、依存性を新しいプロジェクトへ構築することだが、プロジェクトはCreate React Appには依存しない。

Abramovはこう書いている: “‘イジェクト’によっていつでもCreate React Appの居心地の良いセットアップを去ることができる。コマンドを一つ発行するだけで、ビルドのすべての依存性、構成、そしてスクリプトがユーザーのプロジェクトへ移動する。その時点でユーザーは必要なものを何でもカスタマイズできるが、しかしそれはわれわれの構成をフォークして自分の道を進むことだ”。

これによって初心者がReactを使い始めるのが容易になるが、しかし経験豊富なデベロッパーでも、この新しいツールをは試してみたくなるだろう。

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

GoogleがAndroid NのDeveloper Preview 4をリリース、とくに目立つ新機能はなし

android

Googleが今日(米国時間6/15)、Android Nの四度目のプレビューリリースした。同社のモバイルオペレーティングシステムの次のバージョンは、未だに正式名が決まっていないのだ

発表された範囲では、今回のプレビューには新しい大型機能はない。むしろ今回は、デベロッパーがAndroid Nの新しい機能を使うためのAPIの拡張に焦点が置かれた。これらのAPI(およびAndroid N SDK)は今回がファイナルとなり、この状態で夏の最終消費者バージョンへ行く。

android n

Googleは、Android Nの現状をベータ級、日常利用可、と見なしている。先日のGoogle I/Oではそう述べられた。たしかにAndroid Nは、かなり初期から安定していた。Googleがテスト用に最新のNexusデバイスを提供し、面倒なインストール作業などを省いたことも、これまでのプレビューにおけるバグ発見などの過程を円滑にしただろう。

Androidデベロッパーは、今のプレビューの上で、マルチウィンドウや通知のダイレクトリプライなど、新しい機能をテストできる。最近改良されたGoogle Playのベータテスト機能により、デベロッパーはユーザーからのフィードバックを早期から得やすくなったので、Googleによると、その機能がこのデベロッパープレビューでも利用されている。

今、最終消費者のための新しい大型機能をこのプレビューに探しているのだが、見つかったらこの記事を更新しよう。でも今のところの感触としては、今回の主な目的はもっぱらバグフィックスにあるようだ。

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

Apple、App Storeのレビュー・ガイドラインを改訂。定期購読のルールは明確化されず

app-store-previews

Apple毎年恒例のデベロッパーカンファレンス、WWDCの数あるニュースリリースの一環として、AppleはApp Storeレビュー・ガイドラインを改訂した ― App Storeに申請するアプリが受理されるか却下されるかを事前に判断するために、デベロッパーが利用する文書。Appleの説明によると、ガイドライン内容そのものに変更はなく、「よりわかりやすく」書き、「状況に応じた説明」が加えられたという。残念ながら、定期購読でアプリを収益化する機能の拡大等、新しいApp Storeのルールに関する追加説明は入っていない。

もう一つ注目すべきは、AppleがiOSとMacのApp Storeガイドラインを一本化したことだ。

後者の変更は、Appleがプラットフォームを扱う全体戦略を象徴している。iOS、macOS、tvOS、およびwatchOSが同じ傘の下に統合され、個別の規約文書が必要になるような特異性をなくそうとしている。また、従来のMac AppガイドラインとApp Storeカイドラインを統合することも、規則に多くこ重複があることを考えれば理にかなっている。

改訂された文書で、AppleはMac App Storeアプリ(2.4.5)の専用セクションを設け、アプリがMacとどのように協調して動くか、何をしてよいか、更新、保守が必要なのは何かを説明している。

Screen Shot 2016-06-14 at 11.22.09 AM奇妙なことに、Appleはこの新しいガイドラインの別バージョンを、コミック本形式でも公開しており、その反響は様々だ。

しかし、全体的に見て2つの文書に大きな違いはないというAppleの説明は正しい。規則そのもの ― プライバシー、スパム、ポルノ、その他の有害コンテンツ、暴力、誘拐、メタデータ、支払い、等々に焦点を合わせている ― は同じだ。

定期購読はまだ改訂が必要

ガイドラインには、定期購読を利用するアプリのための、長い専用セクションがあり、注目に値する。

これはAppleがデベロッパーの定期購読で利用できる機能を拡張するという最近のニュースを受けたもので、単なるアプリ内購入や有料ダウンロード以外に、アプリを収益化する一手段として定期購読を使えるようになる。しかしAppleは定期購読の利用方法に関する新ルールを明確に説明する改訂を行っていないため、現在多くのデベロッパーが混乱している。

Appleは、「今秋から適用予定の定期購読の規約変更に合わせて、数週間のうちにこのガイドラインを改訂する予定」とだけ言っている。

言い換えれば、自分たちの定期購読ベースのアプリが受理されるかどうかを判断するためにガイドラインを見ているデベロッパーたちは、まだ待たなくてはならないということだ。

定期購読がApp Storeで使えるようになってからしばらくたつが、利用できる分野は、雑誌、ビジネスアプリ、メディアプル等限られていた。今や人気の高いこのビジネスモデルをより多くのデベロッパーに開放することは、App Storeの売上を促進し、デベロッパーの利益拡大も後押しするかもしれない。

しかしこのニュースは、喜びより、混乱をもって受け止められている。

Appleは、定期購読があらゆるアプリで利用できるようになると言っているが、同社の “What’s News in Subscriptions” ページを見ると、何が許可されるかについて大きな落とし穴が待っている。「全カテゴリーのアプリが対象になるが、このビジネスモデルはどのアプリにでも適しているわけではない」。

例えばデベロッパーは、アプリ保守の資金を集める方法として定期購読を利用できるのかどうか確証がない ― Appleが定期購読に適した事例として提供した、「クラウドストレージや多人数オンラインゲーム(MMOG)のような継続的サービス」では必ずしもないため。もしこれが許されれば、放棄アプリの問題解決に期待がもてる。Appleは、App Storeのアプリが200万本に達したと言ったが、その多くはデベロッパーに時間と金がないために、更新されていない。

Appleは明らかに、ユーザーの利益にならない形で定期購読を使用するアプリがApp Storeに溢れることを望んでおらず、同社の考える正しい方法で定期購読を使わないアプリを受理または拒否する手段を持とうとしている。しかし、デベロッパーの今の混乱は、そもそも定期購読ベースのアプリを作ろうとしないことを意味している。なぜなら、拒否されるかどうかわからないからだ。

願わくば、Appleがこの後「定期購読」セクションの文言をまとめる際に、こうした懸念について考慮してくれることを期待したい。

[原文へ]

(翻訳:Nob Takahashi / facebook

Amazon Alexaのスキルが1000を突破(1月にはわずか135だったのに)…スキルストアの整備が早急に必要

amazon-echo2

AmazonのEchoスピーカーとその子孫Dot and Tapは、消費者に好まれる家庭用の“お利口な”スピーカー、そして声を出すコンピューターとして、人気が拡大している。しかしそこにはさらに、“スキル(skill(s))”と呼ばれるアドオンをめぐってデベロッパーの関心の高まりもある。スキルは、AmazonのパーソナルアシスタントAlexaに教える新しいワザのことで、Uberを呼んだり、ピザを注文したりなど、いろいろある。今日(米国時間6/3)Amazonは、Alexaのアプリストア(のようなもの)のスキル部門において、スキルの数が1000を超えた、と発表した。昨年の6月まではEchoは招待制でしか手に入らなかったから、それにしては大した数だ。

同社はAlexaの能力を、インターネットに接続されたそのほかのデバイスにも移植しようとしている。それは同社のFire TVもあるし、またオープンなプラットホームだからサードパーティのハードウェアもありだ。

Alexaのスキルは、今年の1月の時点で130強だったから、半年足らずで1000を突破とは、ものすごい成長である。

今日の発表の中でAmazonは、注目すべきスキルをいくつか挙げている。金融サービスのCapital One、ピザのDomino’s、フィットネスのFitbit、航空券/ホテル予約のKAYAK、スマートホームのSmartThings、Uberなどなどのスキルだ。AmazonでAlexaを担当しているディレクターRob Pulcianiによると、Alexaのスキルを作っているサードパーティのデベロッパーは数万人いるそうだ。Alexaをいじくることが、デベロッパーたちのあいだで、ブームになりつつある。まだスキルを一つもローンチしてない人も、多いようだけど。

Alexa用の音声で起動するアプリ、すなわちスキルは、Alexa Skills Kit(ASK)を使って作る。そのアプリは顧客のリクエストを聞いて理解し、解決し、それをデベロッパーのエンドポイント(目的アクション)にマップする、とAmazonは説明している。これらの“デベロッパー語”に慣れてない人は、Amazon提供のドキュメンテーション勉強しよう

Alexaの能力は、時間とともに着実に良くなっている。

たとえば3月にAmazonはAlexa Voice Servicesを改良した。それによりデベロッパーは、Alexaの音声コントロールを自分のデバイスに実装できる。また今週Amazonは、ASKに4つの新しいインテントを加えた。これで、サードパーティアプリのユーザーは、スキルをもっと容易にナビゲートできる。リストの次のアイテムへ行ったり、進行中のアクションをポーズしたり、前のアイテムに戻ったり、アクションを再開したり、などなど。

スキルが増えてAlexaがより有能になるのは嬉しいけど、今度はスキルの発見が問題になる。

Alexaの“アプリストア”のスキル部門は、まだ機能が貧弱だ。検索機能は弱いし、スキルがカテゴリーで分類されていない。ほかのアプリストアには必ずある、人気上位作品のトップチャートもない。1000を超えてまだ成長中だから、ベストアプリを目立つように陳列したりして、ユーザーが良いスキルを見つけやすいようにすべきだ。

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