Quantcast
Channel: Google Developers Japan
Viewing all 2204 articles
Browse latest View live

Google Play - Indie Games Festival 2018 開催のお知らせ

$
0
0


Google Play は、日本のインディーゲーム開発者の皆様が情熱と創造力を注いで作ったゲームのために、日本、そして世界のプレイヤーと業界エキスパートに広く知っていただき、ひいてはビジネスとしての成功も目指すためのお手伝いをさせていただければと願い、このコンテストを開催します。

コンテスト参加に興味をお持ちの開発者の皆様は、2017 年 10 月 28 日に開催するキックオフイベントへの出席をぜひご検討ください。当日はコンテストの説明やトレーニングを実施いたします。


また、以下が今後の主なスケジュールとなっております。コンテストのルールなど、詳しくはウェブサイトをご参照ください。



スケジュール


2017年

  • 10 月 28 日(土):キックオフイベント(詳細はこちら
  • 11 月 13 日(月):Unreal ゲーム開発ワークショップ(詳細はこちら

2018年

  • 2 月 1 日(木):ゲーム参加受付開始。賞品、審査員、ファイナルイベント開催日時と会場などの発表。一般参加者のファイナルイベント参加受付開始
  • 3 月 25 日(日):ゲーム参加受付締切
  • 4 月上旬:トップ 20 ファイナリストの発表
  • 4 月 28 日(土):ファイナルイベント開催。トップ 10、トップ 3を選抜

Posted by Hidenori Fujii - Play Team

Speech Commands Dataset をリリース

$
0
0
この記事は Google Brain チーム ソフトウェア エンジニア、Pete Warden による Google Research Blog の記事 "Launching the Speech Commands Dataset" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ディープ ラーニングを使ってキーワードやコマンドを検知する音声認識を行うには、どこから始めればよいかという質問をよく受けます。ニューラル ネットワークをコンポーネントとして利用できる Kaldiのようなすばらしいオープンソース音声認識システムもあるものの、いずれも複雑であるため、シンプルなタスクを行うためのガイドとして利用するのは困難です。おそらくさらに重要なのは、初心者用のチュートリアルとして無料で広く利用できるデータセットが多くないことです(多くの場合、ニューラル ネットワーク モデルの構築に使うには、データセットの前処理が必要になります)。また、単純なキーワードの検出に向いているデータセットもほとんどありません。

こういった問題を解決するために、TensorFlowチームと AIYチームは Speech Commands Datasetを作成し、それを使ってトレーニング*推論を行うサンプルコードを TensorFlow に追加しました。このデータセットには、30 種類の短い単語を発音した長さ 1 秒の 65,000 個のデータが含まれています。これは、AIY のウェブサイトを通して貢献してくださった数千人の一般の方々が発声したものです。このデータセットは Creative Commons BY 4.0 ライセンスでリリースされており、さらにデータが集まり次第、今後のリリースで追加してく予定です。これは、アプリで「Yes」、「No」や数字、命令などの一般的な単語を使った基本的かつ有用な音声インターフェースを構築するために作られています。データを作成するために使ったインフラもオープンソース化されています。まだサポートされていない言語や目的に対応する独自のデータセットを作るために、この仕組みが広くコミュニティで使われることも期待しています。

実際に試してみるには、ビルド済みの TensorFlow Android デモアプリをダウンロードし、[TF Speech] を開きます。マイクにアクセスするパーミッションを与えると、10 個の単語のリストが表示され、皆さんが発声した単語がハイライトされます。

結果は、皆さんの話し方がデータセットでカバーされているかどうかによって異なりますので、完璧ではないかもしれません。商用の音声認識システムは、この教育用の例よりもはるかに複雑です。しかし、特徴的な発音や話し方の違いがデータセットに追加されるにつれて、またコミュニティの貢献によって TensorFlow のモデルが改善されるにつれて、精度が上がり、拡張機能が増えていくことを期待しています。

自分でモデルをトレーニングする方法は、TensorFlow.org の新しい音声認識チュートリアルで学ぶことができます。フレームワークの最新の開発バージョンと最新の PC を利用すれば、わずか数時間でデータセットをダウンロードしてモデルをトレーニングできます。また、さまざまな問題に対応したり、プラットフォームによって遅延やサイズ、精度のトレードオフを行うオプションも豊富に用意されており、ニューラル ネットワークをカスタマイズできるようになっています。

このデータセットとチュートリアルを使って皆さんが構築するアプリを見ることを楽しみにしています。ぜひ、この世界に飛び込んで音声認識を始めてみてください!


* このネットワークのアーキテクチャは、Interspeech 2015で発表された Convolutional Neural Networks for Small-footprint Keyword Spotting(短いキーワードを検出するための畳み込みニューラル ネットワーク)に基づいています。



Reviewed by Takuo Suzuki - Developer Relations Team

AIY Projects アップデート: 新しいモノ作りプロジェクト、新しいパートナー、そして新しいキット

$
0
0
この記事は AIY Projects ディレクター、Billy Rutledge による Google Developers Blog の記事 "AIY Projects update: new maker projects, new partners, new kits" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Maker とは、往々にして型破りな自らのアイデアに基づいてデバイスやエコシステム、アートを生み出す問題解決の手腕に優れた冒険者であり、ハッカーです。彼らにとって変化とは、自分たちの一部のようなものです。ですので、Google で磨き上げてきた AI テクノロジーをすべての Maker に使ってもらうには、それはオープンで広くアクセスできるものでなければなりませんでした。プラットフォームやソフトウェア スタックの要件、高価な費用やセットアップの複雑さから生じる制限を克服し、世界中の Maker を奮い立たせる好奇心や創意工夫に目を向け続けました。

パートナーの Raspberry Piと力を合わせて 5 月に リリースした Voice Kitは、わずか数時間のうちに完売しました。そのとき、私たちは明確なメッセージを受け取りました。人工知能は、人間と機械のインタラクションを自然な人間のインタラクションに近づけます。そういった人工知能を活用したモノ作りを自分たちの手で行いたいという純粋な需要があるのです。

先週は、TensorFlow チームと AIY チームとのコラボレーションの成果である Speech Commands Datasetについてお知らせしました。このデータセットには、30 種類の短い単語を発声した長さ 1 秒の 65,000 個のデータが含まれています。これは、AIY のウェブサイトを通して貢献してくださった数千人が発声したもので、これを使えば、アプリケーションでシンプルな音声インターフェースを実現できます。現在私たちは、このデータセットを次期バージョンの Voice Kit に組み込む作業を行っています。これによって、モノ作り愛好家の皆さんはシンプルな音声コマンドに応答するデバイスを作れるようになります。ボタン操作もインターネット接続も不要です。

本日(*原文公開当時)より、Voice Kit の予約注文を受け付けています。注文した製品は、Micro Center を通して店舗やオンラインで購入できるようになります。

5 月に Voice Kit with MagPi #57が売り切れた際に、モノ作り愛好家の Shivasiddarth氏が作成し、今月再び(17 分以内で)作り上げたものをハックしてみるのもよいかもしれません。


Maker による Voice Kit のクールな活用方法


Martin Mander氏は、レトロ風インターホンを作りました。その名も、 1986 Google Pi Intercomです。Mander 氏は、「Raspberry PI 3 と Google AIY(Artificial Intelligence Yourself)の [音声] キットで作った壁掛け型 Google 音声アシスタント」と説明しています。これに使われているのは、4 ポンドで買った 80 年代半ばのインターホンです。既製品かと思うようなできばえですね!

Martin 氏による詳しい解説や、このプロジェクトについての Slashgear のコメントもご覧ください。

ドクター・フーのファンである)Tom Minnich氏は、ダーレクの声で話すアシスタントを作りました。

Minnich 氏は同じようなことをしたい方のために Voice Kit の改造方法をまとめたチュートリアルも提供しています。これを使えば、ドロゴンの声のアシスタントも作れるかもしれません。

Victor Van Hee氏は、Voice Kit を使って音声で起動できるインターネット ストリーミング ラジオを作りました。別のタイプのオーディオ ファイルも再生できます。手順が公開されているので、同じものを作ることもできます。

現在、Voice Kit は米国で入手できます。今年末までに、世界各国で販売されるようになる予定です。最新のアップデート情報をお知らせする本ブログにもご注目ください。Voice Kit に強い需要があることは、AIY Projects の大きな推進力になっています。

人間の声や視覚、動きを理解するキットで Maker を刺激する


次のキットには、視覚や動作検出が含まれる予定です。これは、既存の Voice Kitと連携して動作できるようになるはずです。AIY Project のキットは、シンプルで強力なデバイスのインターフェースを実現する「目」、「耳」、「声」、そして「バランス」感覚をモノ作り愛好家の皆さんに提供するものになるでしょう。

皆さんからのフィードバックを次のリリースに反映したいと考えていますので、ぜひ hackster.ioにアクセスするか、コメントを記入してお知らせください。また、皆さんが作っているものを私たちやモノ作り愛好家コミュニティと共有してください。その際には、ソーシャル メディアでハッシュタグ #AIYprojects をつけてください。



Reviewed by Takuo Suzuki - Developer Relations Team

Android Native Development Kit r16 のご紹介

$
0
0
この記事は Android NDK テックリード、Dan Albert による Android Developers Blog の記事 "Introducing Android Native Development Kit r16" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android Native Development Kit(NDK)の最新版 Android NDK r16 Beta 1 がダウンロードできるようになりました。Android Studio の SDK Manager からも利用できます。

NDK r16 は大きなマイルストーンであり、libc++ への移行の開始をおすすめできる最初のリリースです。詳しくは後ほど説明します。

libc++ とその関連プロジェクトもアップデートしているので、このリリースでは、C++1z のサポートが強化されています。C++1z が C++17 になるまでは、仕様変更の可能性があるためご注意ください。

今回のリリースノートについては、こちらをご覧ください。

libc++ と libandroid_support


この NDK には、libc++ が依存している libc API(以前のリリースでは利用できませんでした)を移植する libandroid_support と呼ばれるライブラリが含まれています。これまで libc++(この NDK に実装されている)を承認できなかった理由は、このライブラリの信頼性を保証できなかったからです。r16 では、このライブラリを書き直して安定性を改善することに重点を置きました。

libandroid_support がより小さなライブラリになったので、アプリの動作がシステムの動作に厳密に一致するはずです。たとえば、libandroid_support には以前、stdio の一部が代替実装されていました。一部の機能は ICS に移植されていましたが、そうするとバグがアプリに埋め込まれ、代替実装のバグが すべての OS リリースにも存在することを意味していました。libandroid_support の新しいバージョンでは、これを排除しました。そのため旧式の端末でいくつかの機能が使用できなくなりますが(書式文字列での %aのサポートなど、ユーザーが使用しない機能にほぼ限られます)、これらの機能がないため、libc++ を使用するアプリのサイズが小さくなり、信頼性が向上します。

libc++ への切り替え


なぜ libc++ に切り替える必要があるのでしょう。まず第一に(かなり前からロードマップでお知らせしているとおり)、今後、他の STL はサポートされなくなります。Google では、Lollipop 以降の Android プラットフォームで libc++ を使用してきましたが、この変更について Google のエンジニアは非常に満足しています。libandroid_support は必要ではなく、代わりに libc をアップデートするだけでよかったため、NDK よりも前に、プラットフォームでこの変更を実施することができました。

NDK で現在利用できる他の STL とは異なり、libc++ は、C++11 と C++14 に加えて、ほとんどの C++1z をサポートします。Stlport は 2008 年以降アップデートされておらず、gnustl(STL ではない Bionic の libstdc++ との混同を避けるため、GNU の libstdc++ と呼ばれる)は従来から Clang との連携においてうまく動作しませんでした。特に、<atomic><type_traits> などのコンパイラー ビルトインに密接に結び付けられているヘッダーでは適切に動作しません。

Google は次の NDK リリースで libc++ をデフォルトにする予定ですが、このライブラリをまだ使用していない場合は、現時点では、以下の手順を実行して、このライブラリをオプトインすることができます。

他の STL と同じように、libc++ は静的ライブラリまたは共有ライブラリとして利用できます。どちらのライブラリを使用するかは、ドキュメントで説明しているように、デベロッパー固有の状況により異なりますが、アプリケーションに静的ライブラリがあり、共有ライブラリが 1 つだけある場合、tl;dr は静的ライブラリを使用し、それ以外の場合は、共有ライブラリを使用します。
ndk-build
次のコードを Application.mk ファイルに追加します。
APP_STL := c++_shared
CMake
CMake を起動するときは、次のコードを渡します。
-DANDROID_STL=c++_shared

Gradle から CMake を使っている場合は、次のコードを build.gradle に追加します。
externalNativeBuild {
cmake {
arguments "-DANDROID_STL=c++_shared"
}
}
スタンドアロン ツールチェーン
スタンドアロン ツールチェーンを作成する場合は、--stl=libc++を渡します。

将来の libandroid_support


ロードマップに記載しているとおり、Google は、libandroid_support を拡張して、libc/libm を可能な限り多く移植する予定でした。しかしこの計画を話題にしても、どっちつかずの反応しか返ってきませんでした。この計画に対する関心は低く、また結果的にライブラリ サイズが増大する(つまり、 人々の関心が高いと思われる APK サイズの増大につながる)ことを考慮して、この計画は取り止めました。

この解釈が誤っているか、またはこの変更を待ち望んでいる人々の声が 届いていないのであれば、ぜひお知らせください

_FILE_OFFSET_BITS=64


tl;dr: 以前の NDK の動作を保持する場合は、_FILE_OFFSET_BITS=64を設定しないでください。

従来より、NDK に _FILE_OFFSET_BITS=64を設定しても何も起こりませんでした。この機能は、廃止されたヘッダーには一切存在しませんでした。現在、NDK は最新の統合ヘッダーを備えており、この機能がサポートされています。

_FILE_OFFSET_BITS=64は、32 ビットコードで 64 ビット off_tをサポートするためにアプリケーションに定義できるマクロです。このマクロは、off_tを 64 ビットにして(デフォルトでは、32 ビットコード内で 32 ビット)、lseekなどの API への呼び出しを lseek64への呼び出しに明示的に置き換えることで動作します。

_FILE_OFFSET_BITS=64のサポートは単一リリースの Android に追加されませんでした。1 つの API、つまり lseek64は常に bionic に含まれていました。ほとんどの API は Lollipop に追加されましたが、以降のリリースまで、いくつかの API は追加されませんでした。

使用している関数の 64 ビット off_tバリアントをサポートしていないリリースを対象としていて、_FILE_OFFSET_BITS=64を設定している場合、この関数は利用できなくなります。これは、関数が 32 ビット off_tで誤って公開されてサイレント トランケーションされる r15 や r15b の動作とは対照的です(r15c の動作には一致します)。

64 ビット off_t API は、_FILE_OFFSET_BITS=64を設定しなくても、別の名前で引き続き利用できることに注意してください。たとえば、lseekではなく、lseek64を呼び出します。また、off_tではなく、off64_tを使用します。

最後に、この機能は統合ヘッダーを備えた NDK に新しく追加された機能であるため、統合ヘッダーなしの動作に戻したい場合は、_FILE_OFFSET_BITS=64の設定をやめるだけで以前の動作に戻せます。

bionic に含まれている off_t ABI の詳細については、Bionic 32 ビット ABI バグのドキュメントをご覧ください。


Reviewed by Yuichi Araki - Developer Relations Team

ウェブでリアルタイム空間オーディオを実現する Songbird

$
0
0
この記事は Chrome メディアチーム、Jamieson Brettle、Drew Allen による Google Developers Blog の記事 "Bringing Real-time Spatial Audio to the Web with Songbird" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

仮想世界で現実のようにリアルで迫力ある体験を提供するには、迫真のビジュアルとともに真の空間オーディオが欠かせません。空間オーディオ ツールを使うと、デベロッパーはどの方向からでも自由に音を出すことができます。また、3D 空間とオーディオ ソースを関連付けることができるので、ユーザーを完全に取り囲む 360 度サウンドを実現できます。

空間オーディオを活用すると、ユーザーをシーンに引き込み、まったく新しい世界に入り込んだかのような感覚を与えることができます。それを実現するために、Chrome メディアチームは、オープンソースの空間オーディオ エンコーディング エンジンである Songbirdを作成しました。Songbird は、Web Audio APIを使うことによって、どのウェブブラウザでも動作します。

Songbird ライブラリは、入力として任意の数のモノラル オーディオ ストリームを受け取ります。デベロッパーは、プログラムによってそのモノラル オーディオ ストリームをユーザーのまわりの 3D 空間に配置します。Songbird を使うと、表現したい空間の反射や残響をリアルに再現できるので、迫力のある音響環境を実現できます。現実世界と同じように、音が壁面や物体で反射するので、真の 360 度サウンドを再現します。Songbird を利用すると、リアルタイムに計算されるアンビソニック音響環境をアプリケーションから利用できます。私たちは、かつてないほど精度の高いオーディオを実現するために、昨年のブログで紹介した Omnitoneプロジェクトと連携して、Omnitone の 両耳レンダラーに高次のアンビソニック サポートを追加しました。

Songbird の内部には、カプセル化された Omnitone が組み込まれています。そのため、デベロッパーはどのようなウェブベース アプリケーションにでもインタラクティブな完全球面オーディオを追加できます。また、Songbird は、任意の次元のアンビソニックに拡張できるので、標準の Web Audio API 以上にリアルなサウンドと高いパフォーマンスを実現できます。
Songbird のオーディオ処理を示した図

Songbird の実装は、Google 空間メディア仕様をベースとしています。モノラル入力を受け付け、SN3D ノーマライゼーションを適用したアンビソニック(マルチチャンネル)ACN チャンネル レイアウトを出力します。詳しいドキュメントは、こちらをご覧ください。

ウェブは、多様なコンテンツの重要な VR プラットフォームになりつつあります。空間オーディオはこの新たなメディアが広く採用されるかどうかおいて決定的な役割を果たすようになります。Songbird と Omnitone は、ウェブ プラットフォームで空間オーディオを実現する際に鍵となるツールです。感動的な VR 体験を提供する最高のプラットフォームとしてウェブを確立できるかどうかも、これらのツールにかかっています。こういったオーディオ体験と three.jsのような 3D JavaScript ライブラリを組み合わせれば、未来のウェブを垣間見ることができます。
3D 環境と空間サウンドを組み合わせたデモ

このプロジェクトは、Google の Daydreamチームと Web Audio チームとの密接な連携によって実現できたものです。この連携によって、デベロッパーが開発する Daydream アプリケーションと同じようなオーディオ機能をウェブで実現できるようになります。

オープンソースの Songbird を使って皆さんが作るものを楽しみにしています。GitHubでコードをご確認いただき、フィードバックをお送りください。Songbird を使って完全な空間オーディオを作成するデモもたくさん公開されています。



Reviewed by Eiji Kitamura - Developer Relations Team

Chrome が Symantec の証明書に対する信頼を破棄する予定について

$
0
0
この記事は Chrome セキュリティ、Devon O’Brien、Ryan Sleevi、Andrew Whalley による Google Security Blog の記事 "Chrome’s Plan to Distrust Symantec Certificates" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この投稿は、blink-dev メーリング リストすでに確定している計画を広く通知するためのものです。

Chrome チームと PKI コミュニティは 7 月下旬に、ユーザーがウェブを閲覧するときのセキュリティとプライバシーを確保するために、Symantec のインフラストラクチャに対する信頼度を下げ、最終的に破棄するという計画に合意しました。blink-dev フォーラムでの重要な議論の後に明らかになったこの計画に沿うには、Symantec が業界基準に準拠するためにそのインフラストラクチャの最新化と再設計を進める間に、独立して運用される新しい Managed Partner Infrastructure に移行するための妥当な期間を見越す必要があります。この投稿では、この計画についてもう一度説明し、サイト運営者が新しい証明書を取得する必要があるタイミングについて、詳細なタイムラインを示します。

2017 年 1 月 19 日、mozilla.dev.security.policy ニュースグループへの公開投稿で、Symantec Corporation の PKI から発行された一連の不審なウェブサイト認証証明書に関する問題が指摘されました。Thawte、VeriSign、Equifax、GeoTrust、RapidSSL などのさまざまなブランド名で一連の認証局を運用している Symantec の PKI ビジネスは、業界が策定した CA / ブラウザ フォーラム ベースライン要件に準拠していない証明書を多数発行していました。その後の調査により、Symantec は適切または必要な監督なしに証明書を発行できるいくつかの組織に管理を任せ、これらの組織のセキュリティの不備を相当な期間にわたって認識していたことが判明しました。

この出来事は 2015 年に発生した以前のインシデントとは異なりますが、過去数年に発生した問題の継続的なパターンに合致するものであり、Chrome チームから Symantec のインフラストラクチャ(結果として、そこから発行される証明書)に対する信頼を失う原因となりました。

Chrome チームが合意した提案が周知された後、Symantec は、この独立した新しい Managed Partner Infrastructure を運用する組織として DigiCert を選択したことに加えて、新しい信頼できるインフラストラクチャを構築する代わりに、Symantec の PKI ビジネスを DigiCert に売却することを発表しました。この投稿では、この移行のタイムラインについて概説するとともに、ユーザーへの混乱を最小限にするために Symantec の既存顧客が実施する必要のある手順について説明しています。

サイト運営者向けの情報

Chrome 66 以降、Symantec によって 2016 年 6 月 1 日より前に発行された証明書に対する信頼が破棄されます。現時点では、Chrome 66 は Chrome ベータ版ユーザーに対して 2018 年 3 月 15 日に、安定版ユーザーに対して 2018 年 4 月 17 日頃にリリースされる予定です。

Symantec CA によって 2016 年 6 月 1 日より前に発行された証明書を使用しているサイト運営者は、Chrome 66 のリリースよりも前に、既存の証明書を Chrome が信頼する認証局から発行された新しい証明書に置き換える必要があります。

また、Symantec は 2017 年 12 月 1 日までに信頼できる公式の証明書の発行と運用を DigiCert インフラストラクチャに移行し、この日付以降に古い Symantec インフラストラクチャから発行された証明書は Chrome で信頼されなくなります。

Symantec の古いインフラストラクチャとそれらが発行したすべての証明書に対する信頼が完全に破棄される Chrome 70 は、2018 年 10 月 23 日の週前後にリリースされる予定です。これにより、Google に以前公開された独立して運用されている監査済みの下位 CA が発行した少数の証明書を除いて、Symantec ルートに結び付けられているすべての証明書が影響を受けます。

Symantec の既存のルート認証局および中間認証局から証明書を取得する必要のあるサイト運営者は 2017 年 12 月 1 日まで Symantec の古いインフラストラクチャから取得することができますが、これらの証明書は、Chrome 70 がリリースされる前に再度置き換える必要があります。また、Symantec のインフラストラクチャから発行された証明書は、有効期間が 13 か月に制限されます。代替策として、サイト運営者は Chrome が現在信頼している他の認証局から代替証明書を取得することができます。これらの証明書は、こうした信頼の破棄や有効期間の制限の影響を受けません。
目安となるタイムライン
この計画に関連する日付のタイムラインを次に示します。さまざまな要件とマイルストーンに基づき、サイト運営者が行う必要がある作業についてまとめました。これまでのように Chrome のリリース日は若干ずれる可能性がありますが、今後のリリース日はこちらで確認できます。

日付
イベント
現在
2018 年 3 月 15 日
Symantec が 2016 年 6 月 1 日よりも前に発行した TLS サーバー証明書を使用しているサイト運営者はこれらの証明書を置き換える必要があります。これらの証明書は現在信頼されている CA に置き換えることができます。
~ 2017 年 10 月 24 日
Chrome 62 の安定版がリリースされます。このリリースでは、Chrome 66 での信頼破棄によって影響を受ける証明書を評価する際の DevTools のアラートが追加されます。
2017 年 12 月 1 日
Symantec によると、この時点で DigiCert の新しい「Managed Partner Infrastructure」は完全な発行が可能です。この時点以降に Symantec の古いインフラストラクチャから発行された証明書は、将来の Chrome アップデートで機能しなくなります。

この日付以降、サイト運営者は、Chrome 70(2018 年 10 月 23 日から)以降で引き続き信頼される新しい Managed Partner Infrastructure から発行された TLS サーバー証明書を取得できます。

2017 年 12 月 1 日に証明書を変更することは必須ではありませんが、サイト運営者にとっては、Chrome 70 による古いインフラストラクチャに対する信頼破棄の影響を受けない TLS サーバー証明書を取得するよい機会です。
2018 年 3 月 15 日
Chrome 66 のベータ版がリリースされます。このリリースでは、Symantec が 2016 年 6 月 1 日よりも前に発行した証明書に対する信頼が破棄されます。この時点で、サイト運営者は、Symantec が 2016 年 6 月 1 日以降に発行した TLS サーバー証明書か Chrome 66 が信頼する他の CA から発行された有効な証明書を使用している必要があります。

2016 年 6 月 1 日以降に Symantec の古いインフラストラクチャから証明書を取得したサイト運営者は Chrome 66 の影響を受けませんが、以下に説明するように、Chrome 70 のリリース日までに新しい証明書を取得する必要があります。
~ 2018 年 4 月 17 日
Chrome 66 の安定版がリリースされます。
~ 2018 年 9 月 13 日
Chrome 70 のベータ版がリリースされます。このリリースでは、古い Symantec ルート インフラストラクチャに対する信頼が破棄されます。これにより、新しい Managed Partner Infrastructure(Symantec によると、2017 年 12 月 1 日までに運用開始予定)に結び付けられた証明書に影響が及ぶことはありません。

Symantec の古いインフラストラクチャから発行された TLS サーバー証明書のみが、発行日に関係なく、この信頼破棄の影響を受けます。
~ 2018 年 10 月 23 日
Chrome 70 の安定版がリリースされます。



Reviewed by Eiji Kitamura - Developer Relations Team

Firebase Admin SDK for Go のご紹介

$
0
0
この記事は Hiranya Jayathilaka、ソフトウェア エンジニアによる The Firebase Blog の記事 "Introducing Firebase Admin SDK for Go" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

このたび、Firebase Admin SDK for Go が一般公開されました。拡大し続けている Admin SDK ファミリーにはすでに Java、Python、Node.js のサポートが含まれており、今回 4 つ目のプログラミング言語として新たに Go が加わりました。アプリのデベロッパーが Firebase Admin SDK を使うと、信頼された環境からプログラムを介して Firebase サービスにアクセスできるようになります。Firebase Admin SDK は、エンドユーザーがウェブブラウザやモバイル端末から Firebase にアクセスできるようにする Firebase クライアント SDK を補完するものです。Firebase Admin SDK for Go の最初のリリースでは、Firebase Authentication 機能のうち、カスタム トークン作成と ID トークン検証の機能がサポートされます。

Firebase Admin SDK for Go の初期化

他の Firebase Admin SDK と同様に、Go Admin SDK もさまざまな認証方法やクライアント オプションを使って初期化できます。次のコード スニペットは、Firebase Console または Google Cloud Console で取得したサービス アカウント認証情報を使って SDK を初期化する方法を示しています。
import (
"golang.org/x/net/context"

firebase "firebase.google.com/go"
"google.golang.org/api/option"
)

opt := option.WithCredentialsFile("path/to/key.json")
app, err := firebase.NewApp(context.Background(), nil, opt)

Google App Engine や Google Compute Engine などの Google のインフラ上でコードを実行している場合、SDK は環境からアプリのデフォルト認証情報を自動検出します。その場合、Go Admin SDK を初期化する際に明示的に認証情報を指定する必要はありません。
import (
"golang.org/x/net/context"

firebase "firebase.google.com/go"
)

app, err := firebase.NewApp(context.Background(), nil)


カスタム トークンの作成と ID トークンの確認

Firebase Admin SDK for Go の最初のリリースでは、カスタム トークンの作成Firebase ID トークンの検証機能がサポートされています。カスタム トークンを作成すると、独自のユーザーストアや認証メカニズムを使ってユーザー認証を行えるようになります。
client, err := app.Auth()
if err != nil {
return err
}

claims := map[string]interface{}{
"premium": true,
"package": "gold",
}
token, err := client.CustomToken("some-uid", claims)

作成されたカスタム トークンをクライアント端末に送信すると、Firebase クライアント SDK を使った認証フローを行うことができます。また、ID トークンの検証により、サーバー上で現在アプリにログインしているユーザーを確実に特定できるようになります。
client, err := app.Auth()
if err != nil {
return err
}

decoded, err := client.VerifyIDToken(idToken)
uid := decoded.UID

Firebase Admin SDK for Go の詳しい使用方法については、Admin SDK セットアップ ガイドをご覧ください。

次のステップ

Go Admin SDK の機能は今後さらに強化され、ユーザー管理や Firebase Cloud Messaging など、他にも有用な API が実装される予定です。また、この SDK は、オープンソースです。そのため、Github レポジトリをご覧いただいたり、問題の報告やプル リクエストの送信によって開発プロセスに参加していただくことは大歓迎です。Golang gopher の皆さん、ぜひ Firebase のコーディングをお楽しみください。


Reviewed by Khanh LeViet - Developer Relations Team

Google for Mobile | I/O RECAP 2017 セッション動画を公開

$
0
0
デベロッパーの皆さまに日本語で技術情報を提供する YouTube チャネル「Google Developers Japan」に、Google for Mobile | I/O RECAP 2017 Japan基調講演を含む全 41 セッションの動画を公開しました。

今年の Google for Mobile には、米国で開催された Google I/Oのスピーカーを含む、世界中のプロダクト マネージャーやエンジニアがスピーカーとして来日しました。そして、日本のデベロッパーにお届けしたい最新情報だけを厳選し、皆さまにお伝えました。

セッションはすべて、Google I/O の内容を短く再編成しており、英語のセッションは日本語音声にて、または一部を字幕付きでご視聴いただけます。以下では代表的なセッションをご紹介します。動画にはスライドも収録されていますので、デベロッパーの皆さまが多くのトピックに効率的に接し、より良いサービスを開発するヒントとなれば幸いです。


基調講演 拡大と進化を続ける Android と Google Play(James Sandars)

Android 端末の利用数の伸びや Google Play ストアの現状報告など、開発者にとって気になる最新の情報を数字や例でお伝えします。




基調講演 I/O 2017 から振り返る最新技術トレンド(Takuo Suzuki)

Google for Mobile | I/O RECAP 2017 にて行われた他講演の全容をご紹介している、当 Playlist で最初にご覧いただきたいセッションです。




【Android】Android Support Library 最新情報(Yuichi Araki)

Android Support Library は、メソッドを呼び出す基本的な互換性から、スタンドアローンの新しい機能の実装まで、すべてを提供するモジュールの集大成です。 バージョン 25 と 26 の新機能を中心に Support Library モジュールをアプリに統合するための事例について紹介します。



【Firebase】ユーザーを分析し、アプリを成長させよう(Laurence Moroney)
Google Analitics による成長のための戦略と、Google Analytics をFirebase で使用するとどのようなシナリオが可能になるかを示します。




【Mobile Web】AMP最新情報: ECでも使える!インタラクティブなAMPの作り方(Yusuke Utsunomiya)

最近 EC での活用が多く見られるようになった AMP ですが、その最新情報と、PWA との連携方法などをご紹介いたします。





他にもたくさんのセッション動画がアップロードされています。ぜひご覧ください。


Posted by Hidenori Fujii - Google Play

Chrome 62 ベータ版: Network Quality Estimator API、OpenType バリアブル フォント、DOM 要素のメディア キャプチャー

$
0
0
この記事は "ネットワーク監視人"、Ben Greenstein、Tarun Bansal
による Chromium Blog の記事 "Network Quality Estimator API, OpenType variable fonts, and media capture from DOM elements" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、Mac、Windows 向けの最新の Chrome ベータ版に適用されます。

Network Quality Estimator API

以前のバージョンの Chrome では Network Infomation APIが利用できましたが、これはユーザーの接続タイプに応じた理論的なネットワーク速度しか提供できないものでした。今回のリリースではこの API が拡張され、クライアントが体験しているネットワーク パフォーマンスの指標を提供できるようになります。この API を利用すると、デベロッパーは現在のラウンドトリップ時間やスループットの予測値を取得したり、パフォーマンスの変化に関する通知を受けることができます。アプリケーションのロジックを簡単にするために、実際の接続が WiFi やイーサネットであっても、API は計測したネットワーク パフォーマンスにもっとも近いモバイル接続タイプ(2G など)への集約も行います。

こういったネットワーク品質シグナルを利用すると、デベロッパーはネットワークの制約に応じたコンテンツを提供できます。たとえば、とても遅い接続では、簡易版のページを提供してページの読み込み時間を短縮できます。 このシグナルは、まもなく HTTP リクエスト ヘッダーやクライアント ヒントとして利用できるようになる予定です。

OpenType バリアブル フォント

OpenType フォントのバリエーションは、ウェブに新たなフォント機能をもたらします。今までは、1 つのフォント ファイルには、1 つのフォント ファミリーの 1 つの太さ(レギュラー、ボールド、ブラックなど)や幅(Normal、Condensed、Expanded など)のインスタンスのみが含まれていました。
図: AmstelvarDecovarのバリアブル フォントをアニメーションで示した例


バリアブル フォントによって、ウェブのレスポンシブ デザインをフォントにまで適用できるようになりました。OpenType のバリエーションを活用すると、スタイルのバリエーションを連続的に変化させられるだけでなく、すべてが 1 つの小さなフォント ファイルから読み込まれるので、領域や帯域幅も節約することができます。CSS プロパティがアップデートされているので、幅、スタイル、太さは数値で指定できます。太さや幅などのバリエーション軸パラメータは、font-variation-settings CSS プロパティを使って細かく調整できます。

DOM 要素のメディア キャプチャー

W3C Media Capture from DOM Elements API を使うと、サイトで HTMLMediaElements(つまり <video> と <audio>)から直接コンテンツを MediaStream 形式でライブ キャプチャーすることができます。HTMLMediaElements の captureStream()メソッドを呼び出すと、ストリームコンテンツの録画、WebRTC によるリモート送信、WebAudio による処理、その他さまざまな方法による処理を行うことができます。


図: 3D レンダリングをライブでキャプチャーし、WebRTC でピア接続にストリーム送信

今回のリリースに追加されたその他の機能

  • Chrome for iOS で Payment Request APIが利用できるようになります
  • PaymentRequestで、PaymentDetailsModifier.dataの支払い方法ごとに異なる価格と項目がサポートされるようになります。
  • Non-documentおよび <body>要素がビューポートのスクロール効果に対応し、document.rootScrollerで URL バーを隠したり、オーバースクロール時にグローを発生させたりできるようになりました。 
  • DOM インターフェースで <data>および <time> HTML 要素がサポートされました。これにより、デベロッパーは、クライアントサイドのコンテンツをマシンが認識できるネイティブ形式で格納できるようになります。 
  • CSS の色パーサーが 8 桁および 4 桁の 16 進数を使った #RRGGBBAAおよび #RGBA形式をサポートするようになりました。 
  • 先読みに加え、後読みの正規表現が利用できるようになります。これにより、デベロッパーはパターンが別のパターンの前にあるかどうかを確認する正規表現を利用できるようになります。たとえば、ドル記号がついていない金額にマッチさせることができます。 
  • 新しい WebVR オリジン トライアルが利用できるようになりました。これにより、デベロッパーはウェブで豊かな仮想現実体験を実験できます。 
  • 以前にお知らせしたように、ユーザーが HTTP ページにデータを入力した場合と、HTTP ページにシークレット モードでアクセスした場合に、「Not secure」警告が表示されるようになりました。 
  • デベロッパーは、sフラグを使って ECMAScript 正規表現の dotAllモードを利用できるようになります。これにより、「.」が行末文字を含むすべての文字にマッチするようになりました。 
  • Chrome for Android にイメージをアップロードする際のユーザー エクスペリエンスが改善され、イメージのみを受け付ける accept属性が付いた <input type="file">を利用しているサイトで複数選択がサポートされるようになりました。 
  • MediaSource APIを利用するアプリで、HTMLMediaElement.seekableの範囲ロジックのカスタマイズを効率的に行えるようになりました。これには、新しい Media Source Extensions API である setLiveSeekableRangeclearLiveSeekableRangeを利用します。 
  • 新しい visibility:collapse CSS 宣言を使うと、列幅の指定を保持しつつ表の行を隠すことができます。これは、単に行の描画をスキップする visibility:hiddenとは異なります。 
  • Intl.PluralRulesに言語/地域と数値を指定すると、サイトから数値の複数形に関する言語依存データやそれに関連する周辺テキストにアクセスできるようになりました。 
  • Media Source Extensions(MSE)で、ISO-BMFFのロスレス オーディオ コーディング形式である FLAC がサポートされました。 
  • Chrome for Android で、EMEによって保護されたメディアがオフライン再生できるようになりました。 
  • Chrome for Android で Widevine L1がサポートされました。これにより、サイトで安全に暗号化されたメディアを再生できるようになります。 
  • テンプレート リテラルのエスケープ シーケンスの制限が緩和され、テンプレート タグを LaTeX 処理などの新しい方法に活用できるようになります。 
  • Android O では、通知パーミッションを持つサイトが Android の [Settings] の [Chrome] の下の通知チャンネルに表示されるようになりました。これにより、ユーザーは簡単にパーミッションを管理できるようになります。

サポートの終了と相互運用性の改善

  • macOS でのネイティブ ボタン表示のアップデートに合わせて、<input>ボタンと <button>要素の外観が変更されました。これにより、background-colorborderborder-radiuspadding CSS プロパティのデフォルト値に影響が発生します。 
  • HTTP 接続とクロスオリジン iframesで、通知を表示するパーミッションのリクエスト機能が削除されました。これは、強力な機能を HTTPS のみに制限するというポリシーにしたがったものです。 
  • ユーザーが予期する言語でコンテンツを受信できる確率を上げるため、言語設定から accept-languageヘッダーを生成する際に、言語と地域の直後にベース言語が追加されました。 
  • UX とブラウザの一貫性を向上させるため、意図するレイアウトが変更された後、従来のマウスイベントがディスパッチされ、ホバー状態更新もすばやく行われるようになりました。 
  • OfflineAudioContextに、3 つの個別の引数を受け取る既存のコンストラクタに加え、ディクショナリ引数も渡せるようになりました。 
  • 他のブラウザに合わせるため、RTCPeerConnectiongetStreamByIdメソッドが削除されました。 
  • 他の主要ブラウザでのサポートの終了および削除に合わせて、SharedWorker.workerStartが削除されました。 
  • 仕様に準拠するため、<ol>.startのデフォルト値が 1に設定されました。 


Kaldi と TensorFlow の統合が可能に

$
0
0
この記事は Google スタッフ リサーチ エンジニア、Raziel Alvarez、IntelligentWire 創業者、Yishay Carmiel  による Google Developers Blog の記事 "Kaldi now offers TensorFlow integration" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

近年の仮想パーソナル アシスタントの普及やディープ ラーニング アルゴリズムの応用による単語認識の精度向上によって、自動音声認識(ASR)が広く採用されています。音声認識を手がけるチームの多くは、人気のオープンソース音声認識ツールキット Kaldiを使っています。本日(*原文公開当時)は、その Kaldi と TensorFlow の統合が可能になったことをお知らせします。

この統合により、Kaldi を使っている音声認識のリサーチャーやデベロッパーが TensorFlow を使って Kaldi 音声認識パイプラインでディープ ラーニング モデルを分析およびデプロイできるようになります。Kaldi コミュニティは、さらに優れた強力な ASR システムを構築できるようになり、TensorFlow ユーザーは、Kaldi デベロッパーの大きなコミュニティの経験を活かして ASR に取り組めるようになります。

言語、アクセント、環境、会話の種類を問わず人間の会話を理解できる ASR システムを作るのは、非常に複雑な作業です。従来の ASR システムは、多くの個別のモジュールを使った処理パイプラインとなっており、各モジュールが前のモジュールからの出力を処理しています。つまり、片方から生のオーディオ データがパイプラインに入力され、もう片方から認識された音声を文字に起こしたものが出てくるというものです。Kaldi の場合は、ASR の認識結果はさまざまな方法で後処理され、増加を続けるエンドユーザー アプリケーションをサポートしています。


Kaldi と TensorFlow を統合するための開発は、それぞれのチームのサポートを得つつ、シアトルを本拠地とする IntelligentWireの Yishay Carmiel と Hainan Xu が率いました。この 2 人は、その際の複雑な作業を直接体験しています。IntelligentWire は、電話でのライブの会話とビジネス アプリケーションをつなぐクラウド ソフトウェアを開発しており、企業の担当者と顧客との間で行われる無数の会話の内容をリアルタイムに分析し、データ入力やリクエストへの対応などのタスクを自動処理することを目指しています。現在、IntelligentWire は、コンタクト センター市場に注目しています。世界中で 2,200 万人以上がこの業界に従事しており、電話での会話には年間 500 億時間が、各種ビジネス アプリケーションの操作には 250 億時間が費やされています。

この状況で ASR システムを活用するには、正確な書き起こしを提供するだけでなく、非常に低いレイテンシでそれを行う必要があります。また、並列に行われる無数の会話に効率よく対応できるだけの規模も必要です。このような場合、近年発展しているディープ ラーニングによって技術的な限界を突破できる可能性があります。その際に威力を発揮するのが TensorFlow です。

ここ数年間で、多くの既存の ASR モジュールがディープ ニューラル ネットワークによって置き換えられ、その結果、単語認識の精度が大きく向上しています。通常、こういったディープ ラーニング モデルは、大量のデータを処理する必要がありますが、TensorFlow を使うとそれを簡単に行うことができます。しかし、実用に耐えうる ASR システムを開発するには、まだいくつか乗り越えなければならない大きな問題がありました。
  • アルゴリズム - ディープ ラーニングのアルゴリズムは、処理するタスクに合わせて調整することで最高の結果が得られます。具体的には、音響環境(ノイズなど)、話される言語、語彙の範囲などが関わってきます。デプロイした後にこういったアルゴリズムに適応するのは、必ずしも簡単ではありません。
  • データ - 異なる言語や異なる音響環境で使われる ASR システムを開発するには、さまざまな種類のデータが大量に必要になります。そのようなデータがいつも使えるとは限らず、目的のユースケースに適切とも限りません。
  • スケール - 通常、使用量が多く、たくさんの言語をサポートできる ASR システムは、大きな計算能力を必要とします。

こういった問題を例示する ASR システムのモジュールの 1 つが言語モデルです。言語モデルは、ほとんどの最新 ASR システムの中核をなす部分で、正しい単語の並びを予測したり、同じように聞こえる単語を識別する際に役立つ言語のコンテキスト情報を提供します。近年の機械学習の画期的な発展にともない、音声認識デベロッパーはディープ ラーニングに基づく言語モデル(ニューラル言語モデル)を利用できるようになっています。とりわけ、再帰型ニューラル言語モデルは、従来の統計的アプローチに比べて非常に優れた成果をあげています。

しかし、ニューラル言語モデルのトレーニングやデプロイは複雑な作業であり、非常に時間がかかるものです。IntelligentWire では、TensorFlow と Kaldi の統合によって、ASR の開発サイクルが桁違いに短縮されています。ある言語モデルが TensorFlow に存在する場合、モデルから概念実証までにかかる日数は、数週間から数日に短縮できます。また、新しいモデルの開発に必要な期間は、数か月から数週間に短縮されています。TensorFlow モデルを本番環境の Kaldi パイプラインにデプロイするのも簡単です。これは、直接 Kaldi を使っている方にとって大きなメリットになるだけでなく、今後さらにインテリジェントな ASR システムが実現され、誰もが使えるようになることを確約するものでもあります。

同じように、この統合によって TensorFlow デベロッパーは確かな ASR プラットフォームに簡単にアクセスできるようになり、Kaldi の強力な音響環境モデルなどの既存の音声認識パイプラインを機械学習アプリケーションに組み込めるようになります。TensorFlow のディープ ラーニング モデルのトレーニングをフィードする Kaldi モジュールは、きれいに入れ替えることができます。これによって、調査や研究が容易になるだけでなく、本番環境で使用しているものと同じパイプラインをモデルの質の評価に再利用することも可能になります。

今回の Kaldi と TensorFlow の統合によって、2 つの活発なオープンソース コミュニティが近づき、さまざまな新しい音声認識ベースの製品や、関連する研究の飛躍に貢献できることを期待しています。Kaldi と TensorFlow を使ってみるには、Kaldi レポジトリをチェックアウトし、TensorFlow と合わせて動作させるための Kaldi セットアップの例をご覧ください。



Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud

Condé Nast が Accelerated Mobile Pages を導入した理由とその方法

$
0
0
この記事は Condé Nast、Oscar Perez による Accelerated Mobile Pages Project の記事 "The Why and How of Accelerated Mobile Pages at Condé Nast" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

編集者のメモ: Condé Nast のテクノロジー ブログでこのすばらしい投稿を発見しました。フィードバックは @oscrperezに送信してください。Condé Nast テクノロジーの詳細については、@CondeNastTechをフォローしてください。

Google が主導する AMP プロジェクトとは


Accelerated Mobile Pages は HTML、CSS、JavaScript に適用される、パフォーマンスに重点を置いた一連の制限であり、パフォーマンスを最大限に高め、Google が CDN を介して最適化されたコンテンツを配信できるようにします。つまり、AMP は、HTML タグの代わりに、AMP ウェブ コンポーネントの使用を強制し、パフォーマンスに悪影響を及ぼす可能性のある CSS セレクターを制限し、サンドボックス化された iframe の外部で非 AMP JavaScript を使用することを禁止します。AMP の形式、その仕組み、Google 検索にどのように適合するかの詳細については、公式の概要技術的な説明AMP by Exampleポータルをご覧ください。

AMP で公開する理由 



Condé Nast は世界で最も名高い出版社の 1 つです。Condé Nast が発行している Ars Technica、Bon Appétit、Golf Digest、GQ、Pitchfork、The New Yorker、Vanity Fair、Vogue、Wired やその他のブランドは広く認知されていることと思います。出版社として AMP を実装することは簡単でした。パフォーマンス、一貫性、モバイル ユーザー向けのエクスペリエンスの観点から見て、AMP は多くのメリットをもたらします。Google 検索から当社のサイトにアクセスするユーザーは、検索化からコンテンツに到達するまで妨げられることのないフローを体験します。Google の CDN と AMP HTML が強制するパフォーマンス ガイドラインのおかげで、AMP コンテンツはすばやく読み込まれます。AMP のレイアウト システムにより、サードパーティ コンテンツが読み込まれる際にページ上のコンテンツが動き回らないため、快適に閲覧できます。当社の通常のサイトはいかなる場合も低速にならず、競合他社よりも読み込み時間とレンダリング時間を短縮していますが、コンテンツが Google の CDN で配信される場合は、ユーザーに対して特定のパフォーマンスが保証されます(プリフェッチなど)。

ここで一歩下がって、出版社である当社の動機について考えてみましょう。当社は収益を生み出すために、コンテンツの訴求力を高め、可能な限り多くの読者にコンテンツを見つけてもらう必要があります。当社のブランド全体を通じて高品質のコンテンツで読者をつなぎ止めておけば、当社の収益が最大化します。AMP により、これらのニーズを満たすことが容易になります。AMP を活用すると、コンテンツを Google のトップニュース カルーセルに含めたり、通常の Google 検索の結果を改善したりできるため、コンテンツの可視性と検出可能性が向上します。また、統合された AMP ビューアーを介して Google 検索からのシームレスな操作感を実現することにより、世界中どこでもコンテンツが一貫してすばやく読み込まれるようになります。このシームレスな操作感はエンゲージメントの増加と直帰率の減少をもたらします。収益化によるメリットはそれほど決定的ではなく、その結果について、現在の実装を詳細に分析しているところです。初期の AMP 導入では、コンテンツ ターゲティング広告のみを配信しました。コンテンツ ターゲティング広告は、コンテンツ ターゲティング広告とオーディエンス ターゲティング広告の両方をサポートする当社の通常のモバイルサイトに配信する広告よりも CPM(インプレッション単価: 広告が 1000 回表示されるごとにサイトオーナーが払う金額)が低くなっています。ターゲティング広告を改善し、他の収益パートナーへのサポートを追加したため、ブランドによっては、AMP の CPM が同じままか、高くなったサイトがあります。

Vanity Fair には、1 年ほど前に AMP を導入しました。導入後、トラフィックと検索ランク結果がかなり好転しました。Google 検索のクリックスルー率が 5.9%(通常)から 10.3%(AMP)になり、平均的な検索位置が 5.9(通常)から 1.7(AMP)になりました。それ以降、当社の 15 のブランドに AMP をデプロイしましたが、その結果にとても満足しています。現在、AMP は当社のモバイル検索トラフィックの 79% を、モバイル アクセス全体の 36% を占めています。Condé Nast では、当社のブランドの技術的努力の結果、混乱を最小限に抑えながら、AMP の実装を 1 つのブランドから 15 のブランドにまで拡張できました。

AMP の実装方法 



当社のブランドの AMP コンテンツは、ページの AMP 版の URL を指す link rel="amphtml" タグを通常のページの head セクションに含めることにより検出されます。当社のアーキテクチャでは、AMP URL のトラフィックが社内 AMP サービスのプロキシ サーバーに送られ、リクエストされたコンテンツの AMP 版が生成されます。次の図は、当社のコンテンツ作成および AMP 配信アーキテクチャの概要を示しています。



Condé Nast AMP サービス アーキテクチャ



当社のブランドはすべて、社内コンテンツ管理システム(CMS)である Copilot を使用しています。CMS は、コンテンツを Copilot Markdown と呼ばれるカスタマイズ版のマークダウンで保存しますCopilot Markdown は CommonMark 仕様の拡張機能セットであり、編集者が使用する埋め込み、コールアウト、区切り、その他の機能のための特別な構文を追加します。

Google ユーザーが当社のブランドの 1 つの AMP 結果を開くと、Google AMP CDN が最新のキャッシュ コピーをすばやく配信します。この背後では、Google AMP CDN が、当社のブランド ドメインにある AMP ドキュメントの URL へのリクエストをトリガーします。当社のすべてのブランドは、別のキャッシュ レイヤーを提供する Fastly CDN を利用しています。リクエストが Fastly をヒットすると、ブランドの Varnish Control Language(VCL)構成のロジックにより AMPコンテンツのリクエストかどうかが判定されます。AMP コンテンツのリクエストである場合は、Fastly がリクエストのバックエンドを AMP サービスに設定し、その後、このサービスが処理を引き継ぎ、リクエストされたコンテンツの AMP HTML が生成されます。

AMP サービスがコンテンツをレンダリングできるようにするには、CMS からコンテンツを取得してから、コンテンツを解析し、有効な AMP HTML にレンダリングされる React コンポーネントに変換する必要があります。次の図は、AMP サービス内部にあるこのレンダリング パイプラインを示しています。


AMP サービスのレンダリング パイプライン



Condé Nast では、ほとんどのブランドの通常のウェブサイトのために、技術スタックで Node.js と React を使用しています。AMP コンテンツを生成するために React とサーバー側レンダリングを活用することは、非常に理にかなっています。この選択により、当社のブランドのエンジニアが AMP コードベースに簡単に貢献できるようになります。また、Node.js と React を使用することにより、通常のサイトと AMP サービスでコンポーネントとヘルパー コードを再利用できるようになりました。

AMP サービスを作成するうえで、AMP 経由で配信されたときにブランドがデザインと操作感を維持できることが重要な優先事項でした。AMP サービスでは、これを実現するために、当社の正当なデフォルトをオーバーライドする独自の構成と Sassファイルをブランドが提供できるようにしています。この構成と SCSS ファイルが提供された場合、AMP HTML マークアップ出力と CSS がそれぞれ制御されます。ブランドはこのアプローチを通して、機能を切り替えたり、設計をカスタマイズしたりできます。将来的には、React コンポーネントの拡張性をさらに活用して、ブランドの AMP HTML マークアップ出力を詳細にカスタマイズできるようにします。当社のすべてのブランドでこのようなサービスを活用できるようにすることは非常に有益で、無駄な労力を大幅に削減します。ブランドは単一の設定ファイルを追加して、Fastly VCL 設定を変更するだけで AMP トラフィックの配信を開始できます。AMP 実装の機能セットを拡張し、多くのブランドに AMP を導入してきた結果、このアーキテクチャが大幅に拡張可能なソリューションであることが証明されました。

当社の認識 



当社の一元化されたコンテンツ管理システムとサービス指向アーキテクチャにより、新しいブランドに AMP を導入することが非常に簡単になりましたが、常にうまくいくとは限りませんでした。最初のブランドに AMP を導入したときは、サービス アーキテクチャを使用せずに、各ブランドが AMP プラグインに依存する必要があるプラグイン アーキテクチャを使っていました。このプラグイン アーキテクチャの使用により、他のブランドに AMP を導入するときにコードの重複が発生したほか、すべてのブランドに新しいプラグイン バージョンを展開することが難しくなりました。これらの問題は、共有 AMP サービスに切り替えたことにより解決しました。サービス指向アーキテクチャの機能性と拡張性はもはや明らかです。AMP サービスは、Condé Nast のブランドを横断した共有サービスでの使用が検証されています。さらに、共有ツール、API、技術的取り組みによりすべてのブランドでデータを共通の形式(Copilot Markdown)で保存できるようになったメリットは明白です。

まとめると、AMP は、トラフィックの観点でビジネスに良い影響を与え、Google ユーザーのエクスペリエンスを向上させています。現在、AMP は当社のモバイル トラフィック全体の 36% を占めています。ビジネスの収益化のチャンスをもたらし、AMP ユーザーのエクスペリエンスを改善する機能を継続的に追加しています。Google 以外のプラットフォームが AMP コンテンツを配信することを決断し、より多くの組織が AMP オープンソース プロジェクトに参加するようになれば、どのような未来が到来するかを楽しみにしています。

執筆者へのフィードバックとコメントは、@oscrperezまでお寄せください。Condé Nast テクノロジーの詳細については、@CondeNastTechをフォローしてください。


Reviewed by Yoshifumi Yamaguchi - Developer Relations Team

Cloud OnAir - 2017 年 10 月 5 日(木)LIVE 放送開始のお知らせ

$
0
0
Google Cloud について学べる Cloud OnAir が始まります!


Cloud OnAirは、Google Cloud の製品をわかりやすく解説し、最新の情報などをいち早く皆様にお伝えする Online LIVE 番組です。LIVE 中、皆様からいただいた疑問にすぐにお答えする Q&A コーナーも設けます。わからない事や疑問に思ってる事などを、ぜひ Goolge Cloud のエキスパートに聞いてみてください。

10 月 5 日(木)より隔週の木曜日 18:00 - 19:00 に放送。各回 Google Cloud のエンジニアがトピックを設け、Google Cloud の最新情報を交えて解説していきます。

記念すべき第 1 回目は、Google Cloud Platform の概要や Google Cloud のビジョンなどをお話する「徹底解剖 GCP のここがすごい」。Google Cloud Platform の製品で何ができるのか? 何がビジネスに役立つのかなど、ポイントを整理してご紹介します。

番組で取り上げるテーマは毎回変わります。番組の内容、視聴登録はこちらの登録ページをご覧ください。


Posted by Kaz Sato - Staff Developer Advocate, Google Cloud

新しい TensorBoard API で機械学習の独自の可視化をビルド

$
0
0
この記事は Google Brain チーム ソフトウェア エンジニア、Chi Zeng、Justine Tunney による Google Research Blog の記事 "Build your own Machine Learning Visualizations with the new TensorBoard API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2015 年に TensorFlow をオープンソース化しましたが、これには、TensorFlow モデルと実行環境を調査して理解するための一連の可視化ツールである TensorBoardが含まれていました。TensorBoard は、様々なディープ ラーニング アプリケーションに汎用的に適用できるコンパクトな可視化ツールです。損失関数の長期的な変動の監視や、高次元空間のクラスタの探索などの用途に利用できます。

しかし TensorBoard には再利用可能な API がないため、TensorFlow チーム以外のデベロッパーが TensorBoard に新しい可視化ツールを追加することはとても困難でした。そのため、さまざまな用途に使えるクリエイティブで洗練された便利な可視化ツールを自分でビルドできない状況でした。

今回、新しい便利な可視化ツールを作成するための API のセットをリリースしました。この API を使用することで、 TensorBoard を拡張し幅広いユースケースに対応可能になります。

新しい TensorBoard では、ダッシュボード(タブ)が変更され、新しい API を使えるようになりました。これは、プラグイン作成者向けのサンプルとして機能します。TensorBoard に含まれているプラグインの最新のリストについては、GitHub にある tensorboard/plugins ディレクトリをご覧ください。たとえば、適合率-再現率曲線を生成する次の新しいプラグインをご覧ください。


 TensorBoard プラグインは以下の 3 つの部分から構成されます。
  • データの収集とその後の可視化に使用する、サマリー用 TensorFlow 演算 [GitHub]
  • カスタムデータを供給する Python バックエンド [GitHub]
  • TypeScript と polymer を使用して構築された TensorBoard 内のダッシュボード [GitHub]
上述の pr_curves プラグインは、他のプラグインと同じように(1)ユーザーがプラグインの使用方法を学ぶために確認したり、(2)作成者が開発中にサンプルデータを生成するために使用したりできるデモを提供します。プラグインの動作方法をさらに明確にするために、基盤となる TensorBoard "Greeter" プラグインも作成しています。この単純なプラグインは、モデルの実行中に案内メッセージ("Hello" で始まるシンプルな文字列)を収集して表示します。Greeter プラグインに加えて、その他の既存のプラグインを調べて(またはフォークして)から開始することをおすすめします。

TensorBoard API を既に活用している他の制作者の注目すべき例は、修士課程に取り組んでいる Chris Anderson氏が最近作成した Beholderです。Beholder は、データのライブ ビデオフィード(グラデーションや畳み込みフィルタなど)をモデルトレインとして表示します。デモ動画はこちらでご覧いただけます。


今後はコミュニティからの新しいツールの登場が期待されます。TensorBoard レポジトリにプラグインを提供しようと考えている方は、サポートとガイドを提供しますので、最初に Issue Trackerでアイデアをお知らせください。

謝辞
この API のビルドでは、Dandelion Mané と William Chargin が中心的な役割を果たしました。

Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud

Chrome における自動再生機能の統一について

$
0
0
この記事は ソフトウェア エンジニア、Mounir Lamouri による Chromium Blog の記事 "Unified autoplay" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ユーザーはたくさんのメディアを視聴しています。自動再生を使うと、ウェブ上でメディアを高速かつ簡単に視聴することができますが、ユーザーが特に嫌うのは、予期しないメディアの再生です。メディアが再生されると、データ転送が行われ、バッテリーが消費され、望ましくない音が発生します。この問題に対処するため、Chrome では、ユーザーの意図に合わせて自動再生されるようになるとともに、ユーザーがオーディオをさらに細かく制御できるようになります。

Chrome 64 以降では、音を出さないメディアか、ユーザーが明確に興味を示したメディアのみに自動再生が許可されるようになります。これによって、ユーザーがメディアを再生したい場合のみ自動再生されるようになり、自動再生したくない場合はその意思が尊重されるようになります。この変更によって、ウェブにおける PC とモバイルウェブの動作が統一され、さまざまなプラットフォームやブラウザを対象としたウェブメディア開発において動作を予測しやすくなります。

メディアの自動再生に関する好みはユーザーによって異なります。そのため、Chrome 63 には、個々のサイトでオーディオを完全に無効化するための新しいユーザー オプションが追加されます。サイトをミュートさせるこのオプションは、ブラウジング セッションをまたいで有効であるため、ユーザーはいつどこでオーディオを再生するかをカスタマイズできるようになります。

以上の変更によって、ユーザーはブラウザ上でのメディア再生を細かく制御できるようになります。また、サイトオーナーも、ユーザーにメリットがある自動再生を実装しやすくなります。詳細については、自動再生のロードマップをご覧ください。


Reviewed by Eiji Kitamura - Developer Relations Team

Cloud Firestore のご紹介: アプリ用の新しいドキュメント データベース

$
0
0
この記事は プロダクト マネージャー、Alex Dufetel による The Firebase Blog の記事 "Introducing Cloud Firestore: Our New Document Database for Apps" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


本日(*原文公開当時)、Cloud Firestore をリリースしました。これは、モバイルおよびウェブアプリ開発用のフル マネージド(Fully Managed)型の NoSQL ドキュメント データベースです。世界規模でアプリデータを簡単に格納して同期できるようにデザインされており、ベータ版として利用できるようになりました。

Cloud Firestore の主な特徴は以下のとおりです。
  • 強力なクエリを備えたドキュメントとコレクション
  • オフライン データアクセスに対応した iOS、Android とウェブ SDK
  • リアルタイム データ同期
  • 高い整合性を持った自動マルチリージョン データ複製
  • Node、Python、Go、Java のサーバー SDK

そしてもちろん、シンプルかつ簡単に使えるという、常に Firebase の最優先事項である特徴を保ちながら、Cloud Firestore は、最大規模のアプリがスケールする力となるよう作られています。


アプリの開発に最適


サーバーをスケールアップしたり、断続的な接続に対応したり、データを低いレイテンシで提供したりと、アプリのデータ管理が難しいのは現在も変わりません。

Cloud Firestore は、アプリ開発に最適化されているので、ユーザーに価値を提供して質の高いアプリをすばやくリリースすることに集中できます。Cloud Firestore を使うと、以下のようなことが実現できます。
  • 端末間でデータをリアルタイムに同期します。Android、iOS、JavaScript の 各 SDK は、ほぼ瞬時にアプリのデータを同期します。これによって、リアクティブなアプリを信じられないほど簡単に開発したり、端末間でデータを自動的に同期したり、強力なコラボレーション機能を構築したりできます。また、リアルタイム同期が不要でも、非常に優れた 1 回限りの読み込み機能を利用できます。
  • コレクションとドキュメントによるデータの構造化とクエリが利用できます。このデータモデルは、多くのデベロッパーにとっておなじみの直感的なものであり、表現力の高いクエリを利用できます。クエリの処理の重さは、データセットのサイズではなく結果セットのサイズに比例するため、1 つの結果をフェッチする際のパフォーマンスは、100 セットのデータから抽出する場合も 1 億セットのデータから抽出する場合も変わりません。
  • 強力な端末内データベースでオフライン時のデータアクセスを可能にします。ローカルにデータベースがあるので、ネットワーク接続が失われてもアプリはスムーズな動作を続けることができます。オフライン モードは、ウェブ、iOS、Android で利用できます。
  • サーバーレス開発を実現します。認証やネットワーク接続に必要なコードは複雑で、通常なら自分で記述しなければなりませんが、それらはすべて Cloud Firestore のクライアントサイド SDK が行ってくれます。バックエンドでは、一連の強力なセキュリティ ルールが提供されているため、データのアクセスも制御できます。セキュリティ ルールを利用すると、どのユーザーがどのドキュメントにアクセスできるかを制御したり、データに複雑な検証ロジックを適用したりすることが可能です。これらの機能を組み合わせて、モバイルアプリを直接データベースに接続することができます。
  • 他の Firebase プラットフォームと統合できます。Cloud Functions を使ってデータが書き込まれた際にカスタムコードを実行するような設定も簡単です。SDK を使うと、自動的に Firebase Authentication が統合されるため、すぐに使い始めることができます。

「クラウド」を Cloud Firestore に格納する


名前から想像できるかもしれませんが、Cloud Firestore は Google Cloud Platform チームと密接に連携して開発されています。

つまり、これはゼロから作成されたフル マネージド製品で、自動的にスケールアップされるようになっています。Cloud Firestore は、マルチリージョンにレプリケーションされるデータベースで、データがコミットされると、たとえ予期せぬ災害が発生してもデータが失われることはなくなります。それだけでなく、分散データベースでありながら強い整合性も備えているため、厄介なエッジケースを排除できます。そのため、規模にかかわらず簡単にアプリを開発することができます。

これは、バックエンド デベロッパーに最高のサーバーサイド開発体験を提供することが最重要だという意味でもあります。Java、Go、Python、Node.js 用の SDK も本日リリースされています。今後、他の言語用の SDK も登場する予定です。

これは別のデータベースですか?


Firebase はこの 3 年間で成長を遂げ、Google のアプリ開発プラットフォームとなりました。現在、16 の製品をアプリの開発と拡大のために活用していただけます。現在 Firebase を使っている方なら、既に Firebase Realtime Database というデータベースが提供されていることをご存知でしょう。これは、前述のいくつかの課題の解決に既に役に立っています。

クライアント SDK とリアルタイム機能を備えた Firebase Realtime Database は、アプリ開発を高速化、簡素化するものです。この機能がリリースされてから、数多くのデベロッパーに採用され、その採用が拡大するにつれて利用パターンも増加しています。デベロッパーは、Realtime Database を複雑なデータや大きなアプリに利用し始めており、その用途は JSON データモデルと大規模データベースのパフォーマンスの限界を超えつつあります。Cloud Firestore は、Firebase Realtime Database のデベロッパーにもっとも愛用されている部分に着想を得つつ、データ構造、クエリ、スケーリングといった主な制限に対処しています。

そのため、現在 Firebase Realtime Database を使っている方なら、Cloud Firestore を気に入っていただけるはずです。ただし、Firebase Realtime Database は単純に Cloud Firestore で置き換えられるものではありません。ユースケースによっては、Realtime Database を利用して費用やレイテンシを最適化する方が妥当な場合もあります。また、両方のデータベースを併用することも簡単です。2 つのデータベースの詳しい比較は、こちらをご覧ください。

私たちは両方のデータベースの開発を継続します。コンソールやドキュメントも両方に対応しています。

使ってみる


本日より、Cloud Firestore はパブリック ベータ版となります。ベータ版の製品を使っても問題ないという方は、ぜひ次のプロジェクトで使ってみてください!以下は、既に Cloud Firestore を使って開発を行っている会社やスタートアップ企業です。


使ってみたい方は、Firebase Console の [Database] タブにアクセスしてください。詳しくは、ドキュメント価格コードサンプルベータ版期間のパフォーマンス制限をご覧ください。オープンソースの iOSおよび JavaScript SDK も GitHub でご覧いただけます。

皆さんのアプリのリリースや、Cloud Firestore を使った感想を楽しみにしています。


Reviewed by Khanh LeViet - Developer Relations Team

Firebase Dynamic Links の新機能

$
0
0
この記事は デベロッパー アドボケート、Todd Kerpelman による The Firebase Blog の記事 "What's new with Firebase Dynamic Links?" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Firebase Dynamic Links の新機能

皆さんは既に Firebase Dynamic Linksをご存知かもしれません。Firebase Dynamic Links は、ユーザーを iOS アプリや Android アプリの任意のアプリ内コンテンツに案内できるスマート URL です。最初にアプリのインストールが必要になる場合でも大丈夫です。この数か月間で Dynamic Links にはいくつかのすばらしい改善が行われており、さらに簡単に使えるようになりました。特に、iOS 側で大きく改善されました。以下では、その新機能について紹介します。

アプリのプレビュー ページの改善

少し前に、iOS でアプリをインストールしていないユーザーがリンクをクリックした場合のために、Dynamic Links チームはアプリのプレビュー ページを追加しました。その理由は、ユーザーを App Store にリダイレクトする JavaScript を無視するアプリもあるためです。このような動作は、特に人気のソーシャル アプリで多く見られます。アプリのプレビュー ページを設けることによって、ユーザーはデベロッパーが意図したように確実に App Store にたどりつけるようになります。さらに、次に App Store が開くことがわかるので、ユーザー エクスペリエンスの向上にもつながります。

とはいえ、初期のプレビュー ページはやや質素なものでした。このページの導入以降、アプリストアの掲載情報または直接指定できるプレビュー用アセットから取得したグラフィックやアセットを使って、このページの見栄えを整えてきました。これによって、アプリストアへのクリックスルー数が大幅に増加したことがわかっています。そしてもちろん、見た目もよくなっています。

アプリのプレビュー ページ: 改善前、改善後のデフォルト バージョン、カスタム アセットを使用したバージョン

当然ながら、アプリのプレビュー ページを作るのは気が進まないという方は、いつでも削除することができます。そのためには、生成したダイナミック リンク URL に efr=1を追加するか、Firebase Console で [Skip the app preview page] チェックボックスをオンにするか、iOSおよび Androidのビルダー API で forcedRedirectEnabledパラメータを使用します。

エラー メッセージの改善 -- リンクの追加

Dynamic Links の実装でエラー メッセージが表示される際、ほとんどの場合においてエラーの詳しい意味や修正方法が記載されたドキュメントへの直接リンクが提供されるようになります。すばらしいですね!

iOS の自己診断ツール

Dynamic Links の実装を簡単にする取り組みについて取り上げましたが、iOS 版の Dynamic Links ライブラリには自己診断ツールも追加されました。コード内の任意の場所で DynamicLinks.performDiagnostics(completion: nil)を呼び出すと、Dynamic Links ライブラリがプロジェクトを分析してセットアップ時に発生する一般的なエラーがあるかどうかを検出し、その結果を教えてくれます。さらに、トラブルシューティング チームに連絡する必要がある場合、送信する必要がある情報も提供してくれます。

分析機能の強化

今までは、コンソールで生成された短縮 Dynamic Link について、リンクがクリックされた回数が日ごとに表示されていました。これはとてもすばらしい機能ですが、この分析レポートが強化され、さらに詳しい情報が含まれるようになりました。これからは、ユーザーが Dynamic Link をクリックしてアプリを再オープンした回数と、短縮 Dynamic Link をクリックしてユーザーが初めてアプリを開いた回数も日ごとに表示されるようになります。これは、Firebase Console で表示される分析と、REST API で取得できる分析の両方で利用できます。

また、いつものように Dynamic Links に utmパラメータを追加すると、Google Analytics for Firebase はユーザーを初めてアプリにつなげた重要なコンバージョン イベントを Dynamic Link によるものと見なします。

お試しください

本投稿では、ここ数か月間で Firebase Dynamic Links に対して行われてきたさまざまな改善点のうち、代表的なものをご紹介しました。
  • 分析情報を取得したいが Firebase Console は使いたくないという方のために、短縮 Dynamic Links に関する分析情報を取得する REST APIを追加
  • ユーザーがダイナミック リンクをクリックするとどうなるかを、すばらしいフローチャートで正確に示すリンクのデバッグページ
  • すぐにダイナミック リンクを構築できるように、iOS および Android 用ツールを改善

最近 Firebase Dynamic Links を試していないという方は、ぜひこの機会にお試しください。始めるにあたって、参考になる各種ドキュメントもそろっています。また、いつでもサポート チャンネルにご連絡ください。



Reviewed by Khanh LeViet - Developer Relations Team

Crashlytics を最大限に活用する 7 つのヒント

$
0
0
この記事は プロダクト マネージャー、Jason St. Pierre による The Firebase Blog の記事 "7 tips for getting the most out of Crashlytics" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



 

長年にわたり、デベロッパーやアプリチームは Crashlytics を活用してアプリの安定性を向上させてきました。おそらく、皆さんは既に Crashlytics UI の主な部分をご存知でしょう。クラッシュのないユーザーやセッション、問題リストを一日に何度も見ている方もいるかもしれません(皆さんだけではありません!)。


本投稿では、Crashlytics をさらに価値あるものにするプロフェッショナル向けの 7 つのヒントを紹介します。Crashlytics は新しい Fabric ダッシュボードの一部になっているので、問題のトラッキング、優先順位付け、解決をすばやく行うことができます。

1. クラッシュ インサイトをチェックしてトラブルシューティングを高速化する


クラッシュ インサイトは、7 月にベータ版を卒業して正式にリリースされました。クラッシュ インサイトでは、クラッシュに至った状況やその 理由が明らかにされるため、クラッシュについて深く理解できるようになります。問題リストの問題に緑色の稲妻マークが表示されている場合、それをクリックすると考えられる根本原因や、トラブルシューティングに活用できるリソースが表示されます。

2. 解決した問題を「クローズ」してリグレッションを追跡する


クラッシュのデバッグやトラブルシューティングは、時間がかかる困難な作業です。私たち自身もデベロッパーなので、厄介な問題が解決でき次第、ログアウトしてもっとおもしろいタスク(アプリの新機能の構築など)に戻りたいという気持ちはよく理解できます。しかし、Crashlytics で問題を「クローズ」することは忘れないようにしましょう!問題を正式にクローズすると、リグレッション検知によって問題のライフサイクルを詳しく見ることができるようになります。リグレッション検知は、以前にクローズした問題が新しいバージョンのアプリで再発した際に警告してくれます。これは、何かがうまくいっておらず、注意が必要であることを示す兆候になります。

3. 無視したい問題をクローズしてロックし、問題リストを整理する


一般的には、リグレッションを検知するために問題をクローズする必要がありますが、問題をクローズして ロックすることで、修正する予定のない問題や優先度の低い問題について 通知されないようにすることができます。影響が少なくほとんど発生しないバグや、コードには問題がなく自分たちでは制御できない問題などがこれに該当します。そういった問題を非表示にして Crashlytics チャートを整理するには、問題をクローズした後にロックします。この「無視機能」を利用すると、安定性のページをカスタマイズして、対応が必要となる重要な情報のみを表面化させることができます。

4. ビルド バージョンを手動で追加する代わりに、ワイルドカード ビルドをショートカットとして利用する


同じバージョンに複数のビルドが存在する場合もあるでしょう。そういったビルド バージョンは同じ番号で始まりますが、末尾には一意の識別子が含まれています(たとえば、9.12 (123)、9.12 (124)、9.12 (125) など)。これらすべてのバージョンのクラッシュを確認したい場合は、検索バーにビルド バージョンを手動で入力する代わりに、ワイルドカードを使って同じバージョンをグループ化すると、すばやく確認することができます。これを行うには、バージョン プレフィックスの末尾に星印(アスタリスク)を追加します(例: 9.12*)。たとえば、Android で APK の分割を行っている場合、ワイルドカード ビルドを指定すると複数のビルドのクラッシュをすばやく表示できます。

5. 重要なビルドを固定して一番目立つようにする


デベロッパーの皆さんは、毎日いくつかのビルドをデプロイしていることでしょう。開発 チームで扱うビルドの数が、数十や数百におよぶこともあります。モバイルチームのスピードや反応の早さには目を見張るものがあります。しかし、それには良くない側面もあります。たくさんのビルドから、特に重要な 1 つ(あるいは 2 つや 3 つなど)のビルドを探し出すのは時間の無駄です。そのため、Crashlytics では、重要なビルドを「固定」してビルドリストの一番上に表示できるようになっています。ビルドを固定すると、必要な間だけ、重要なビルドを一番目立つようにして見つけやすくすることができます。さらに、この機能を使うと、チームのメンバーのビルドリストでも自動的に一番上に表示されるようになるので、チームのメンバーと協調してクラッシュの修正がしやすくなります。

6. 重要な安定性の問題について最新情報を受け取るため、ベロシティ アラートに注意する


安定性の問題は、いつ発生するかわかりません。皆さんがワークステーションから離れているときに起きることもあるでしょう。Crashlytics は、スマートにビルドを監視し、1 つの問題が統計的にクラッシュの大多数を占めているかどうかを確認してくれます。そして、それに該当する場合は、ベロシティ アラートでアプリのホット フィックスが必要になることをお知らせします。ベロシティ アラートは、問題の重要度や影響が急激に増加した際にクラッシュ レポーティング ダッシュボードに表示されるプロアクティブなアラートです。メールによる通知も行われますが、ぜひ Fabric モバイルアプリもインストールしておいてください。プッシュ通知が送信されるので、外出中でも最新情報が受け取れるようになります。ベロシティ アラートには常に注意してください。そうすれば、どこにいても重要なクラッシュを見逃すことはなくなります!

7. ログ、キー、non-fatal を適切なシナリオで利用する


Crashlytics SDK を使うと、ログ、キー、non-fatal、カスタム イベントを診断できます。これによって、クラッシュが発生した理由や、何がクラッシュにつながったかについての詳しい情報を得ることができます。ただし、ログ、キー、non-fatal、カスタム イベントは、別々の事象をトラッキングするためにデザインされたものです。そこで、これらの適切な利用法をご紹介します。

ログ: ログを分析すると、ユーザーがクラッシュ前に何をしていたかについて重要な情報を得ることができます。たとえば、ユーザーの行動(例: ユーザーがダウンロード画面を開く、ダウンロード ボタンをクリックする)や、行った操作の詳細(例: イメージのダウンロードやダウンロード元)などが考えられます。基本的に、ログはユーザーの断片的な操作記録であり、クラッシュ前に何が起きたかを示すものです。クラッシュが発生した際には、ログの内容が取得されてクラッシュに添付されるので、デバッグの際に便利です。iOSAndroidUnityの各アプリでログの診断を行う手順については、こちらをご覧ください。


キー: キーは、ある時点の情報のスナップショットであるキーと値のペアを示します。時系列に操作を記録するログとは違い、キーは検出された最新の値を記録するもので、時間とともに変化します。キーは上書きされるため、検出された最新の値のみを知りたい場合に使用するようにします。たとえば、ユーザーが完了した最後のレベル、ウィザードで完了した最後の手順、最後に表示したイメージ、最後に行ったカスタム設定などをトラッキングするために利用します。キーは、情報の要約にも活用できます。たとえば、ログが「ログイン、リトライ、リトライ、リトライ」となっている場合、キーを使うと「リトライ: 3 回」と表示することができます。iOSAndroidUnityの各アプリでキーを設定する手順については、こちらをご覧ください。

non-fatal: Crashlytics は自動的にクラッシュを記録しますが、致命的ではない(non-fatal)イベントも記録することができます。non-fatal イベントとは、エラーが発生したものの、アプリのクラッシュには至らなかったイベントです。

たとえば、アプリにディープリンクが存在し、それを開けなかった場合などが non-fatal を記録するシナリオに当たります。リンクの破損によってアプリがクラッシュするとは限りませんが、トラッキングしてリンクを修正することが望ましいでしょう。non-fatal を記録すべきでないシナリオは、ネットワーク エラーによってイメージの読み込みが失敗した場合など、対応できないものや特殊なケースではないものです。

non-fatal イベントは、スタック トレースを取得して優先順位付けやトラブルシューティングを行いたい問題に対して設定するようにします。

単に何かが発生した回数を数えたい(そしてスタック トレースは必要ない)場合は、カスタム イベントを使うことを推奨します。


ここで紹介した 7 つのヒントは、Crashlytics を最大限に活用するために役立つはずです。Crashlytics を使ってアプリの安定性を向上させることができるプロフェッショナル向けのヒントを他にも知っているという方は、ぜひ私たちにツイートしてください!皆さんが Crashlytics をどのように活用しているのか、ご報告をお待ちしています。


Reviewed by Khanh LeViet - Developer Relations Team

第 1 回 Google Cloud INSIDE Games & Apps 開催のご報告

$
0
0



Google Cloud は、ゲーム & アプリ業界で活躍するインフラエンジニア、サーバーアプリケーションエンジニア、テクニカルリーダーの皆さまを対象に、2017 年 9 月 28 日(木)に第 1 回 Google Cloud INSIDE Games & Apps を開催しました。ご参加いただいた皆さま、ありがとうございました。

このイベントでは、SRE (Site Reliability Engineering) をテーマにした、株式会社メルカリの中島 大一 氏 ならびに Google Cloud SRE アドボケイト、ポール ニューソンによるセッションや、株式会社バンダイナムコスタジオ 保科 一成 氏による "アイドルマスター ミリオンライブ!シアターデイズ" の、今回のイベントで初公開となる GAE/Go  活用事例をお届けしました。

今回、残念ながらご参加いただけなかった皆さま向けに、各セッション動画をご覧いただけるページをご用意しています。ぜひ、ご覧ください。→  https://goo.gl/pPkj3H

なお、次回開催は 2017 年 11 月 22 日(水)を予定しております。詳細が決まり次第、お知らせいたします。皆さまのご参加をお待ちしております。

e コマースに AMP のスピード感を取り入れよう

$
0
0
この記事は AMP Project プロダクト マネージャー、Lisa Wang による Accelerated Mobile Pages (AMP) Blog の記事 "E-COMMERCE AT THE SPEED OF AMP" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Accelerated Mobile Pages(AMP)に投資している e コマース企業の初期段階の実績を見ると、このフォーマットがコンバージョン、速度、直帰率、モバイル獲得単価において成果をあげていることがわかります。
  • ブラジルを拠点とする Fastcommerceのクライアントでは、AMP 200 万ページで、非 AMP ページと比較してモバイルのコンバージョン率が 15% 向上しています。

  • WompMobileは e コマース ウェブサイト向けの効果的なモバイル体験を構築し、AMP ページによってコンバージョン率が 105% 向上し、直帰率が 31% 減少しました。

  • 中東およびアジア太平洋地域最大の旅行サービスサイトである Wego.comは、AMP 版の主要ランディング ページを作成したことにより、パートナー コンバージョン率が 95% 向上し、広告コンバージョン率が 3 倍増加しました。

  • フランスのオーガニック食品小売りサイトの Greenweezでは、約半分のモバイル トラフィックが AMP で処理されており、2017 年 1~3 月の間に、モバイル コンバージョン率が 80% 向上し、モバイル獲得単価が 66% 低下しました。

AMP を実装すると、ページがほぼ一瞬で読み込まれるため、ユーザーとの最初のインタラクションが理想的なものになります。しかし、e コマース体験で重要なことは速度だけではありません。AMP は e コマース体験をさらに進化させるために理想的なパートナーです。Greenweez や Fastcommerce に匹敵する成功を望む方のために、AMP を活用した e コマースで何ができるのか、その概要を次にご紹介します。

基本


まずは、e コマースサイトの基本事項を確認しておきましょう。AMPbyExample ウェブサイトにある e コマース向け AMP のスタートガイドをご覧ください。製品ページ、製品カテゴリページ、購入 / 支払いフローの構築を開始するためのサンドボックス サンプルがあります。レビュー写真製品のカスタマイズなど、製品の購入を判断するために必要なすべての要素をユーザーに提供します。




AMP がサポートする主要な機能の一部:

  • 動的コンテンツ: ユーザーに常に最新の情報を表示するために、amp-list と amp-bind を使用して、ページで最新のコンテンツを取得してレンダリングします。
  • 購入 / 支払い: ショッピング カートを実装して、AMP ページ内から購入フローを直接開始できます。ウェブサイトで Payment Request APIamp-formを使用するか、またはユーザーを非 AMP ページにリダイレクトするかは自由に設定できます。WompMobile は今年の AMP カンファレンスでその支払い実装例を紹介しました。リンク先の動画でご覧いただけます。
  • パーソナライズ / ログイン: amp-list を使用すると、おすすめの製品を表示したり、ショッピング カートの状態を保存したりして、ユーザーにパーソナライズされたコンテンツを提供できます。
  • A/B テスト: ユーザーに対して最適な方法を見つけるために、amp-experiment を使用して、AMP ページでユーザー エクスペリエンスの実験ができます。

ネイティブでサポートされていない機能を実装する場合は、amp-iframeを使用して、コンテンツを埋め込んだり、チャットアプリ、マップなどのサードパーティ機能を組み込むことができます。また必要に応じて、ウェブサイトに非 AMP ページを表示することもできます。

amp-bind


amp-bind を使用すると、このような多くの魅力的で便利な e コマース体験が実現します。このインタラクティブ モデルによって、ユーザー アクションとドキュメントのさまざまな状態を関連付けることができます。今年の 7 月に、amp-bind がもたらす新たな可能性の例を多数ご紹介しました。e コマースで重要となる追加の要素を次にいくつか示します。

次の例では、フィルタリングと並べ替えが組み込まれています。

sort_filter

ご説明したように、ここで取り上げた機能以外にも多くの機能が見つかるはずです。有用な機能を探し、見つけた機能をコミュニティで共有してください。

AMP + PWA


中東最大の旅行サービスサイトである Wego では、AMP を活用してランディング ページを再構築し、PWA を活用してよりインタラクティブなページを作成した結果、サイトのパフォーマンスが大幅に向上しました。AMP ページでは速度が 10 倍以上向上し、オーガニック ページアクセスが 12% 増加しました。

PWA はアプリと同じような魅力的な機能をサポートしていますが、ユーザーがサイトを最初に読み込んだときは、PWA に必要な Service Worker を利用できません。AMP を活用すると、画面の背後で PWA を読み込むことができる最適なエントリ ポイントをサイトに追加できます。Wego は AMP と PWA を実装することにより、コンバージョン率を 95% 向上させ、サイトへの訪問者を 26% 増やすことに成功しました。

このように、特に e コマースサイトではこの組み合わせが効果を発揮します。AMP はサイトの最初のページの読み込みを大幅に高速化し、PWA はそれ以降のクリックで発生する読み込み時間を短縮します。これは、コンバージョン ファネルが複数のページにまたがる場合に特に有用です。

さらに PWA は、ホーム画面への追加ボタン、プッシュ通知、ネットワークの条件が悪いときの信頼性、ユーザーが完全にオフラインであっても使用できる機能など、アプリと同じような魅力的な機能もサポートします。

AMP + PWA サイトを実装する方法の詳細については、このチュートリアル ビデオガイドをご覧ください。

アナリティクス


amp-analytics は、サードパーティのアナリティクス ツールと独自の社内アナリティクス ソリューションの両方をサポートします。Adobe Analytics、Google アナリティクス、Clicky Web Analytics など、amp-analytics コンポーネントと併用可能な構成が組み込まれているすべてのサードパーティ ツールのリストについては、こちらをご覧ください。社内で実装する場合は、アナリティクスに関する AMP By Exampleをご覧ください。また、今年の AMP カンファレンスでは、eBayPinterestなどの企業が、AMP 向けアナリティクスの導入方法について詳しく説明しました。リンク先の動画をご覧ください。
* * *

AMP Project は、e コマースサイト向けにこの超高速フォーマットの活用を支援しています。今後数か月のうちに、AMPstart.com で新しい e コマース テンプレートなどの追加リソースをご紹介していきます。作業したりフィードバックを寄せてくださっている AMP 開発コミュニティの方々に感謝いたします。いつものように、問題や機能リクエストがありましたら遠慮なくお知らせください


Posted by Yoshifumi Yamaguchi - Developer Relations Team

Chromebook 向け Android アプリの最適化

$
0
0
この記事は Google Play モバイルアプリ ソリューション コンサルタント、Cheryl Lindo Jones による Android Developers Blog の記事 "Optimize your Android apps for Chromebooks" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Play に対応した Chromebook の増加に伴い、Chromebook 向けに Android アプリを最適化して、より多くのユーザーを獲得するチャンスが到来しています。変更を加えて、より大きな画面に合わせて最適化すれば、デスクトップ モニターに投影できる Samsung Galaxy S8 などのモバイル端末の魅力が高まります。Play Store にアクセスできる Chromebook の最新リストは拡大し続けています。

Chromebook 向けに Android アプリやゲームを最適化するときは、次の違いを考慮する必要があります。
  • 大きな画面サイズと高い解像度
  • マルチウィンドウとサイズ変更可能なウィンドウのサポート
  • さまざまなハードウェア入力方法: キーボード、トラックパッド、マウス、タッチペン
  • ノートパソコンやタブレットに切り替えて使用できるコンバーチブル型の Chromebook

Chromebook ユーザーは必要に応じて画面解像度を変更したり、入力方法を切り替えたり、ノートパソコンからタブレット モードに変更したりするため、Android アプリやゲームはこうしたすべての状況に適切に対応できる必要があります。

Google Play での検出可能性


Chromebook で利用できないハードウェア(セルラー機能や GPS)を Android アプリまたはゲームで必要とする場合、Android タブレット向けの Google Play と同じように、これらのタイトルは Chromebook ユーザー向けの Google Play に表示されません。デベロッパーは次のように対処して、Google Play での検出可能性を最大にする必要があります。

マニフェストで要求されるパーミッションと uses-features を設定し、Chromebook との互換性を確保します。一部の Chromebook には、スマートフォンが通常備えているタッチスクリーン、GPS、背面カメラがありません。マニフェストをアップデートして、Chromebook に通常搭載されていないセンサーやハードウェアが要求されないようにします。次に例を示します。

<uses-feature android:name="android.hardware.touchscreen"
android:required="false" />


また、キーボード、トラックパッド、タッチペンなどの追加入力方法のサポートや大きな高解像度の画面とレスポンシブ レイアウトのサポートといった Chrome OS 固有の実装機能に関する説明を Chromebook ユーザーに提供するために、デベロッパーは、Google Play 上のアプリの説明をアップデートする必要があります。アプリやゲームが大画面でどのようにうまく動作し、そのタイトルが Chromebook で具体的にどう動作するかを示すスクリーンショットを提供するのも効果的です。

機能の最適化


ほとんどのアプリやゲームは、そのままでもすでに Chromebook で問題なく動作しますが、Chromebook ユーザー向けに最適化された一貫性のあるエクスペリエンスを提供する方法を模索することをおすすめします。

大画面とサイズ変更可能なウィンドウ
Chromebook ユーザーはマルチタスクを使う傾向があり、複数のアプリやゲームを一度に開き、画面サイズを有効に活用し、PC やノートパソコンのフォームファクタに応じて操作しています。また、Android スマートフォンとは異なり、必要に応じて、画面に適合するように画面解像度を変更したり、フォント、UI、グラフィックを拡大することもあります。このようなユースケースでは、マルチウィンドウおよび完全にサイズ変更可能なウィンドウのサポートが重要になります。画面解像度や向きが変更されたときに、グラフィック、フォント、レイアウト、タップ ターゲットが適切に調整される必要があります。

アプリやゲームのウィンドウにフォーカスがない場合でも、アプリやゲームが非表示とは限らない点にも注意する必要があります。たとえば、動画アプリが非アクティブなウィンドウで開いている場合、この動画アプリは別のアプリ ウィンドウの横に引き続き表示されている可能性があるため、「バックグラウンド」でコンテンツの再生を続ける必要があります。この場合、マルチウィンドウの使用を完全にサポートするには、onStop()で動画を一時停止し、onStart()で動画の再生を再開する必要があります。

Android N(API レベル 24 以降)を対象にすると、互換性の制限を使用しないことが Chrome OS ウィンドウ マネージャーに通知されます。これにより、ウィンドウのサイズ変更をサポートする際にデベロッパー側の柔軟性が高まり、制御しやすくなります。

Android N を対象としている場合、ウィンドウマネージャーが最適に処理されますが、N より前の API サポートでは、アプリの起動時に選択されたデフォルト サイズ、ウィンドウバーが表示された全画面モード、またはウィンドウ UI が非表示の没入型フルスクリーン モードのいずれかにウィンドウを切り替えることができます。

異なるウィンドウ モードを処理する際、アプリやゲームのウィンドウ エリアがウィンドウ コントロール バーの表示 / 非表示によってオフセットされることに注意する必要があります。アプリのアクティビティが常にウィンドウの (0,0) に設定されるとは限りません。レイアウトとタップ ターゲットを適宜調整してください。ウィンドウのサイズや画面の向きを変更したとき、ウィンドウ コントロール バーの表示または Chromebook 画面の高解像度設定が適切に処理されなかったために、アプリやゲームが応答しなくなることがよくあります。

画面の向きのサポート
Chromebook ユーザーは、ノートパソコンのフォームファクタから、Chromebook でアプリを使用するときは横向きがデフォルトの画面の向きであると考えています。ただし通常、ユーザーはスマートフォンを縦向きで操作するため、多くの場合、Android アプリでサポートされるデフォルトの画面の向きは縦向きであると想定されています。柔軟性を高めるため、縦向きと横向きの両方をサポートすることを強くおすすめします。一部の Chromebook はコンバーチブル型であるため、ユーザーはノートパソコン モードやタブレット モードに自由に変更でき、特定のユースケースごとの快適さに応じて、縦向きと横向きを切り替えます。

最も重要なことは、画面の向きやウィンドウ サイズが変更された場合に、可能な限り再起動を求めないことです。ユーザーがフォームに入力しているとき、一部のコンテンツを作成または編集しているとき、あるいはゲームのレベルが途中のときに、(意図的かどうかに関係なく)ウィンドウの変更のために進行が妨げられると、ユーザー エクスペリエンスが悪化します。

デベロッパーは onConfigurationChanged()を使用してウィンドウ構成の変更を監視し、次の行をアクティビティのマニフェストに追加することにより、こうした変更を動的に処理できます。

android:configChanges="screenSize|smallestScreenSize|orientation|screenLayout".

ウィンドウが変更された際に再起動が必須になる場合は、onSaveInstanceState()メソッドを使用して状態を復元し、作業や状態が失われないようにする必要があります。

さらに、ユーザーがアクティビティ間を移動するときに、アプリの向きと一致していることが重要です。現在、Android アプリがルート アクティビティの向きに強制的に従うことで、一貫性が保持されるようになっています。ただし、これにより、アプリが横向きで起動し、通常は縦向きにレイアウトされているログイン画面がポップアップ表示され、レスポンシブではないレイアウトのために表示が最適化されない状況になる場合があります。また、出発点となるアクティビティがアプリの本来の向きとは異なる向きで起動する可能性もあります。アクティビティのレイアウトを設計するときは、発生する可能性のあるこれらのシナリオに留意してください。

最後に、Chromebook ではカメラの扱いと向きが異なることに注意する必要があります。言うまでもありませんが、Android スマートフォンの縦向き画面の上部には前面と背面にカメラがあります。Chromebook の前面カメラは横向き画面の上部にあります。多くの Chromebook は背面カメラを備えていません。アプリでカメラが必要な場合は、android.hardware.camera.any を使用して前面カメラにアクセスすることが最適です(背面カメラが利用できない場合)。繰り返しますが、デベロッパーは Android N を対象とする必要があり、可能な限り、アプリのサイズを変更できるようにして、カメラ プレビューが適切な向きで表示されるようにしてください。

複数の入力方法のサポート
Chromebook ユーザーは、キーボードやトラックパッドを使ってウェブページとアプリを操作することに慣れています。Android アプリ向けにこれらの入力方法を実際にサポートするには、以下の措置を講じる必要があります。
  • PC アプリのユーザーが慣れ親しんでいるコマンドのホットキーをサポートする
  • 矢印キー、Tab キー、トラックパッドを使ってアクティビティをナビゲートできるようにする
  • カーソルを合わせてコンテキスト メニューを開けるようにする
  • 他のトラックパッド操作をサポートして PC / ノートパソコン モードでの生産性を向上させる

メッセージング アプリでリターンキーを押してテキストを送信したり、Tab キーを押してフィールド間を移動したりできるようにするといった単純な操作を実装すると、Chromebook で使用するアプリの効率と統一感が高まります。

Chrome OS にはタッチスクリーン スクロールとその他のタップ イベントをエミュレートするための互換性モードがありますが、マニフェストで以下を宣言して互換性モードを無効にすることが最善策です。
<uses-feature
android:name="android.hardware.type.pc"
android:required="false" />

そうすると、キーボードとトラックパッドのカスタム サポートを詳細に定義して、Android アプリを最適化することができます。

また、キーボードで Tab キーや矢印キーを使って移動するときに、フォーカスを与える必要のある正しいビューをシステムが推測できます。ただし、最大のパフォーマンスを得るには、Tab キーによるナビゲーションには android:nextFocusForward属性を、矢印キーによるナビゲーションには android:nextFocusUpandroid:nextFocusDownandroid:nextFocusLeftandroid:nextFocusRight属性を使用して、アクティビティ マニフェストでキーボード ナビゲーションを処理する方法を指定します。

さらに、一部の Chromebook にはタッチスクリーンがないため、Chrome 上の最適化された Android アプリでは、ユーザーが通常のスワイプやマルチタッチ タップ操作を行ってアプリやゲームをナビゲートできるとは限りません。キーボードやトラックパッドのみを使って主要機能を実行できない場合、タッチスクリーンを備えていない Chromebook でのユーザー エクスペリエンスに大きな影響を及ぼします。既存のタッチスクリーン タップとスワイプ操作を、トラックパッドやキーボード操作で簡単に行えるようなものに「変換」することを試みてください。

新しい Chromebook はタッチペンをサポートしており、スケッチブックやメモ取りアプリ、写真編集アプリ、ゲームなどの高度な操作が可能です。デベロッパーには、利用可能な APIを使用して、筆圧感知、チルト、イレイザーによる入力をサポートすることをおすすめします。ユーザーがタッチペンで文字を書いたり、描画したり、ゲームをプレイしたりするときに、手を画面に気楽に置けるようにするには、パーム リジェクションをサポートします。システムはユーザーが置いた手からの入力を無視しようとしますが、間違ったタップイベントが登録された場合は、Android アプリで ACTION_CANCELイベントを適切に処理し、間違った入力を消去する必要があります。

これらの追加入力方法をすべてサポートすれば、ユーザーが Chromebook のノートパソコン モードをフル活用して、より効率的に仕事をして、創造力を発揮できるようになります。

さらに詳しく知る


この記事では多くのことを取り上げましたが、Chromebook 向けにアプリやゲームを最適化する方法についてさらに詳しく説明している追加リソースがあります。Chromebook でアプリを適切に動作させる方法のヒントが記載された Medium の投稿を読み、Google I/O 2017 のセッション Android Apps for Chromebooks and Large Screen Devices(Chromebook と大画面端末用の Android アプリ)をご覧ください。また、Android デベロッパー ウェブサイトには、Chrome OS 向けにアプリをビルドするためのトレーニング マテリアルがあります。質問がありましたら、Android デベロッパー コミュニティにアクセスして、ハッシュタグ #AndroidAppsOnChromeOS を使って質問を投稿してください。

このブログ投稿はどのくらい役に立ちましたか?

Reviewed by Takeshi Hagikura - Developer Relations Team
Viewing all 2204 articles
Browse latest View live