[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

この記事は Kobi Glick、Google Play プロダクト マネージャによる Android Developers Blog の記事 "Publish your app with confidence from the Google Play Developer Console" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

新しいアプリの公開や既存のアプリのアップデートは、あらゆるデベロッパーにとって胸が高鳴る重要なマイルストーンです。今回は、いくつかの新機能を使った新しい方法で Google Play にアプリを公開できるようになったことをお知らせします。これにより、リリースのプロセスがスムーズでトラッキングしやすいものになっています。今回の変更では、Google Play Developer Console のリリースの管理ページが新しくなっており、アプリのリリース管理の信頼性が向上しています。




アプリのアップデートを明快かつ詳細に管理
新しくなったリリースの管理ページでは、アプリのアルファ版、ベータ版、製品版の各リリースをアップロードできます。ここから、重要な情報や、各リリース トラックにおけるすべてのステータスを参照できます。


新しくなったリリースの管理ページ

既存の公開機能や新しい公開機能に簡単にアクセス
アプリやアップデートの公開はデベロッパーにとって大きな一歩であり、誰でも自信を持って行いたいものです。それを実現するために、2 つの新機能が追加されました。

1 つ目として、アプリの公開前に潜在的な問題を発見できる検証ステップが追加されています。新しいアプリのロールアウトを確定する前に、新しく追加された「レビューとロールアウト」に関するページが表示され、検証エラーや警告がある場合はそこで報告されます。特にマルチ APK を使うアプリでは、この新しいフローによってアプリのリリース プロセスが簡単になります。さらにこのページでは、アプリに新しいパーミッションを追加した場合にハイライト表示されるなど、新しい情報も表示されるようになっています。



2 つ目として、公開フローでの段階的ロールアウトの実行やトラッキングが簡単になっています。段階的ロールアウトを使うと、ユーザーに対して徐々にアップデートをリリースすることができるので、すべての対象端末に影響する前に問題を発見して対処できる可能性が生まれます。

また、リリースの履歴を確認したい場合のために、細かなトラッキングや以前の APK のダウンロードも可能になっています。

さらに、リリースの管理ページの中に、新しくアーティファクト ライブラリが追加されています。ここでは、リリースの管理に役立つすべてのファイルを探すことができます。
早速新しくなったリリースの管理ページへ

新しくなったリリースの管理ページには、Developer Console からアクセスできます。詳細は、Google Play デベロッパー ヘルプセンターをご覧ください。今回の変更によって、Google Play でのアプリの公開、トラッキング、管理の信頼性が向上しています。


Posted by Yuichi Araki - Developer Relations Team

この記事は Todd Kerpelman、デベロッパー アドボケートによる The Firebase Blog の記事 "Firebase Analytics Quick Tip: The 'value' Parameter" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Todd Kerpleman


Todd Kerpelman
Developer Advocate
Firebase Analytics は、すぐに使えるたくさんのすばらしいレポートを提供しています。たとえば、定着率、アクティブ ユーザー数、アプリを使っているユーザーの年齢や性別などです。また、特定のイベントについて、ある期間におけるイベントの発生回数や、セッションあたりの平均イベント数などの便利な統計情報も確認できます。しかし、現在(BigQuery を使わずに)できないことの 1 つが、Firebase Analytics イベントで送信したカスタム パラメータに設定されている値を確認することです。

Firebase Analytics チームはこの点を改善する方法を模索していますが、今すぐに利用できる機能で対応する方法もあります。Firebase Analytics で記録するイベントには、「value」パラメータを設定できます。これは浮動小数点値または整数値で、このパラメータが設定されていると、Firebase Analytics は特定期間におけるこの値の平均値を計算してくれます。

たとえば、フィットネス アプリで運動の終わりを示すイベントを次のように記録するとしましょう。[1]

  FIRAnalytics.logEvent(withName: "workout_complete", parameters: [
    "time": 1804
    "exercise_type": "interval"
    "intensity": 2
  ])
Firebase Analytics のレポートでは、時間ごとの運動の合計数、セッションあたりの平均運動数、運動したユーザーの年代や性別の内訳を確認できます。しかし、たとえばユーザーの平均運動時間などはトラッキングできません。



ここで、同じ運動時間の情報に次のように value パラメータを追加したとしましょう。
FIRAnalytics.logEvent(withName: "workout_complete", parameters: [ "time": 1804 "exercise_type": "interval" "intensity": 2 kFIRParameterValue: 1804 ])
すると、アプリがリリースされてからの運動時間についての情報を workout_complete イベントの 「Value」グラフから確認できるようになります。下のスクリーンショットの例では、アプリのユーザーが直近 30 日で約 1400 回運動(「Event count」のグラフ)を行い、それに合計 150 万秒(「Value」グラフ)を費やしていることがわかります。ここから、1 回あたりの運動時間は約 17 分であることもわかります。




もちろん、value パラメータですべての必要な情報が取得できるとは限りません。インターバル トレーニングの平均運動時間とヨガの平均運動時間を比較したいような場合は、BigQuery を使ってデータを分析する必要があります。しかし、この value パラメータだけでも驚くほどさまざまなことができることがわかったはずです。

value パラメータを使えば、様々なイベントの様々な意味を持つ値をトラッキングできます。そのため、workout_complete イベントの平均運動時間、invite_friends イベントで招待した友人数、eat_meal イベントで消費したカロリー量などをトラッキングできます。

アプリで記録しているイベントを見直し、value パラメータを使って新たに得られる有用な情報があるか、確認してみることをお勧めします。詳しくは、ドキュメントをご覧ください。また、StackOverflow で Firebase タグを検索してみてください。

ハッピー トラッキング!

[1] ここでは、少し手抜きしています。Swift 3 では、すべての値を NSObject にキャストする必要がありますが、余分なコードが増えてサンプルの重要な点がわかりにくくなってしまうので、ここでは値が適切にキャストされているとお考えください。:)


Posted by Khanh LeViet - Developer Relations Team

この記事は Joel Kalmanowicz、Google Maps API プロダクト マネージャーによる Google Geo Developers Blog の記事 "Styling and custom data for polylines and polygons in the Google Maps Android API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Maps API には、ポリゴン、ポリライン、地面オーバーレイといった地図をカスタマイズするための便利なツールが提供されています。今回、Google Maps Android API に新しいカスタム スタイル設定とデータ オブジェクトを関連付ける機能が追加されます。

図形のスタイル設定: ポリゴンとポリライン

昨年、自社ブランドやアプリなどに合わせて地図のスタイルをカスタマイズできるように、モバイル プラットフォーム向けにカスタム地図スタイルを追加しました。この機能拡張によって、次図のスクリーンショットに示すように、地図全体をスタイリッシュなシルバーにしたり、あるいは鮮やかなピンク色にすることができます。ユーザーは地図をもっと気軽に見ることができるのです。今回、Android 端末でのスタイル設定のオプションがポリゴンとポリラインも対象となり、新しい枠線パターン、キャップ、ジョイントの変更などが可能となりました。
独自の図形とスタイルが Android で利用可能に

今回の拡張によって、さまざまな方法で図形をカスタマイズすることができるようになります。ポリラインやポリゴンの枠線パターンは、実線、破線、点線、ギャップ(線の切れ目)などの種類に変更できます。また、ジョイントも固定の角張ったものでなく、ベベルや丸みのあるジョイントを使えます。さらに、ポリラインの両端のキャップは、四角形、円形、カスタマイズしたビットマップ図形に変更することも可能となり、より魅力的な矢印を描くこともできます。
Polylines.png

ポリラインのスタイル設定が Android で利用可能に

今回の新しいスタイルの設定やカスタマイズの方法については、ポリラインおよびポリゴン チュートリアルをご覧ください。罫線パターンなどのドキュメントも参考になるでしょう。なお、これらの新しいスタイル設定機能は、完全な Google Maps Android API のみで利用可能です。ライトモードでは利用できません。

ポリゴン、ポリライン、地面オーバーレイへのカスタムデータの保存

これまで、データ オブジェクトはマーカーにのみ保存できましたが、この保存機能がポリゴン、ポリライン、円、地面オーバーレイにも拡張されました。すなわち、ジオメトリ オブジェクトを拡張して、任意の種類のデータやプロパティを持たせることができるようになります。これにより、マップの外観へのデータの関連付けを管理する際に、面倒なプログラムを書く必要がなくなります。たとえば、家の間取り図を示すいくつかの地面オーバーレイを提供したい場合、それぞれにデータベースへの参照情報を格納することができます。データベースには自由に情報を格納できるので、不動産物件の一覧を格納して、物件に対応する URL をクリックして開くこともできます。

詳細については、リリースノートをご覧ください。

Google Maps Android API を利用していただき、誠にありがとうございます! フィードバックや問題点は、Issue Tracker で共有をお願いします。



Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps Solution Architect, Google Maps

この記事は Laurence Moroney による The Firebase Blog の記事 "Complex Sign-in user flows made easy on Android with Firebase" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Laurence Moroney


Laurence Moroney
Developer Advocate

Firebase Auth は、ユーザーがアプリへのログインやサインアップを行えるようにする安全な認証システムです。Facebook、Twitter、そしてもちろん Google など、フェデレーションに対応した ID プロバイダによるログインも可能です。

ユーザーは高度なエクスペリエンスを期待しています。そして、複雑な ID 管理の問題を解決することによってこれらすべてを実現しているのが、オープンソースの FirebaseUI プロジェクトです。Firebase UI は、多数の新しいツールや革新的な UX を活用して、ユーザーのログインやサインアップのプロセスをサポートします。こういった機能拡張は、長年にわたってログインのコンバージョン率を最大限に高めることに取り組んできた Google ID チームの経験がベースになっています。

本投稿では、この機能を活用して Android アプリへのログインやサインアップを行う方法について説明します。また、Google ログインとメール / パスワードの組み合わせの両方について取り上げます。
スタートガイド

まずは、GitHub にアクセスして FirebaseUI を使用することをおすすめします。
FirebaseUI for Android には、こちらからアクセスできます。

ダウンロード ボタンをクリックすると、コードとサンプルアプリを含む zip ファイルを入手できます。本投稿では、このサンプルアプリを題材にして FirebaseUI の使い方を説明します。

サンプルアプリにアクセスするには、Android Studio の [File] -> [Open] メニューからコードを展開したディレクトリを開きます。これで、Android Studio プロジェクトを使用できるようになります。次のように表示されます。



これを実行するには、Firebase コンソールに Firebase プロジェクトが存在している必要があります。このプロジェクトから google-services.json 設定ファイルを取得できます。このファイルを取得するには、以下のステップを実行してください。

Android Studio で [Tools] -> [Firebase] をクリックします。Android Studio ウィンドウの右側に Firebase Assistant が開きます。表示されている [Authentication] セクションを選択します。[Email and password authentication] というアクションがあります。



このアクションをクリックすると、これから実行する必要があるいくつかのアクションが表示されます。最初の [Connect your app to Firebase] ではアプリを Firebase に接続します。



ボタンをクリックすると、[Connect to Firebase] ダイアログが表示されます。



既存のアプリを選択するか、上の例のように新しいアプリを作成します。完了後、[Connect to Firebase] ボタンを押します。

Android Studio がコンソール上で Firebase アプリを作成します。これにはしばらくかかることがあります。完了すると、次のようなステータスが表示されます。



次に、Firebase Authentication をアプリに追加します。画面のテキストとリンクに注意してください。ここで Firebase コンソールに移動して、希望するログイン方法を設定する必要があります。



コンソールで、[Email/Password] と [Google] のログイン プロバイダをオンにします。次のように表示されます。



次に、アプリに Firebase Authentication を追加するため、アシスタント画面の [Add Firebase Authentication to your app] ボタンをクリックします。[Add Authentication] ダイアログが表示されます。



[Accept Changes] を選択して変更を反映します。Android Studio はリクエストされたライブラリをアプリに追加します。以上で実行する準備が整いました。
FirebaseUI Auth アプリの実行

以上でアプリを実行する準備が整いました。Android Studio のバージョンによっては、Instant Run が動作しないというエラーが表示されるかもしれません。その場合は、[Android Studio] -> [Preferences] -> [Instant Run] メニューから Instant Run を無効化できます。
アプリを実行すると、次のような画面が表示されます。



[Auth UI demo] を選択すると、次の画面が表示されます。



上のように [Google] と [Email] をチェックしたまま、[Start] をクリックして実験してみてください。最初に Android のヒント セレクターが表示され、自動的にユーザーがログインまたはサインアップのフローに進めるようになっています。この例では、2 種類の Google ID で端末にログインしていた(さらに Google Smart Lock で保存していた)ので、[Sign In] をクリックするとその両方が表示されたカードが現れます。これによって、ログイン画面をスキップすることができます。ヒント セレクターには、端末上の他のアカウントや、Smart Lock for Passwords で保存されている他のメールアドレスも含まれます。端末でまだ Google などのアカウントにログインしていない場合、この画面は表示されず、代わりにログイン画面が表示されます。ログイン後にオプションが表示され、アカウントを Smart Lock に追加することができます。



[None of the Above] をクリックすると、ログイン画面が表示され、Google アカウントまたはメールアドレスでログインできます。



この機能を使うと、さまざまなユーザーフローの実装をどれだけ省くことができるかを考えてみてください。
  1. Google アカウントがない場合でも Google でログインしたい場合は、新しいアカウントを作成するオプションが必要。そうでなければ、既存のアカウントを使用。
  2. Google アカウントが 1 つのみ存在し、ログイン済みの場合、以降はそのアカウントを使ってただちにログイン可能。
  3. 複数の Google アカウントがある場合は、それを選択できるオプション、既存のアカウントを追加するオプション、新しいアカウントを追加するオプションが必要。
アプリをいろいろ使ってみると、これらが標準的な方法で実装されていることがわかるでしょう。ログインが成功すると、次のような画面が表示されます。ここでは、ログインしたユーザーのメタデータが利用できます。



なお、メールアドレスや他の ID プロバイダのアカウントにも同じことがあてはまります。こういったことを自前で行うには、大量のコードを書く必要があります。しかし、このアプリのコードを見れば、FirebaseUI Auth にいかに多くの機能がカプセル化されているかがわかるはずです。
コードの理解

コードを理解するために、Android Studio に戻り、app フォルダの中を見てみましょう。中に、「auth」フォルダがあり、さらにその中に 3 つのアクティビティが存在しています。

最初のアクティビティ、AuthUiActivity は、ログインボタンやログインのリクエストとレスポンスを処理します。LeakCatcher は、その名の通り、メモリリークを検出します。最後の SignedInActivity は、先ほど紹介したようなログイン セッションの細かい処理を行っています。



では、AuthUiActivity を見てみましょう。onCreate メソッドには、次のコードが書かれています。

 FirebaseAuth auth = FirebaseAuth.getInstance();
        if (auth.getCurrentUser() != null) {
            startActivity(SignedInActivity.createIntent(this, null));
            finish();
        }

これは、抽象クラス FirebaseAuth のインスタンスを取得し、カレント ユーザーが存在すれば(すでにログイン済みであれば)、直接 SignedInActivity に移動します。

複数のボタン(Google でログイン、メールアドレスでログインなど)が存在する可能性もありますが、ボタン コントロールは R.id.sign_inという 1 つしかなく、これですべてのユーザー操作を処理しています。ここには、次のようなコードが書かれています。

@OnClick(R.id.sign_in)
    public void signIn(View view) {
        startActivityForResult(
                AuthUI.getInstance().createSignInIntentBuilder()
                        .setTheme(getSelectedTheme())
                        .setLogo(getSelectedLogo())
                        .setProviders(getSelectedProviders())
                        .setTosUrl(getSelectedTosUrl())
                        .setIsSmartLockEnabled(mEnableSmartLock.isChecked())
                        .build(),
                RC_SIGN_IN);
    }


ここでは、AuthUI クラスから SignInIntent を作成しています。その中にあるロジックが、先ほど説明したすべてのユーザーフローを処理してくれます。AuthUI は完全なオープンソースなので、どのような処理が行われているかは自由に確認できます。しかし、単に AuthUI を使いたいだけなら、上のように呼び出すだけです。

インテントが終了すると、アクティビティの結果が返されます。上のコードの結果では、リクエスト コードは RC_SIGN_IN になります。その場合、handleSignInResponse 関数に resultCode とインテントから返されたデータを渡します。次の例をご覧ください。

@Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        super.onActivityResult(requestCode, resultCode, data);
        if (requestCode == RC_SIGN_IN) {
            handleSignInResponse(resultCode, data);
            return;
        }

        showSnackbar(R.string.unknown_response);
    }


この関数は、アクティビティから返されたデータを確認し、ログインが成功している場合、レスポンス データを渡して SignedInActivity を開始します。そこでユーザーのメタデータを解析しています。

  private void handleSignInResponse(int resultCode, Intent data) {
        IdpResponse response = IdpResponse.fromResultIntent(data);

        // Successfully signed in
        if (resultCode == ResultCodes.OK) {
            startActivity(SignedInActivity.createIntent(this, response));
            finish();
            return;
        } else {
            // handle failure conditions
  }
    }


UI も完全にカスタマイズ可能です。サンプルは、プロジェクトの styles.xml ファイルをご覧ください。ここからログイン アクティビティの色を設定できます。次に示すのは、「暗色系」のテーマの例です。

<style name="DarkTheme" parent="FirebaseUI">
        <item name="colorPrimary">@color/material_gray_900</item>
        <item name="colorPrimaryDark">@android:color/black</item>
 …
</style>

テーマはログイン インテントを作成する際に設定します。

@OnClick(R.id.sign_in)
    public void signIn(View view) {
        startActivityForResult(
                AuthUI.getInstance().createSignInIntentBuilder()
                        .setTheme(R.style.DarkTheme)
                        .setLogo(getSelectedLogo())


または、上のスニペットで示したように、ロゴを設定することもできます。詳しくは、getSelectedLogo 関数をご覧ください。ロゴをリソースに追加し、関数からロゴのリソース ID を返すように設定するだけです。

必要になるのは、上のコードだけです。ユーザーフローはすべて AuthUI クラスにカプセル化されており、コンバージョン率の高いログインおよびサインアップ用の UI が提供されていますので、デベロッパーの皆さんはアプリのロジックに集中できます。FirebaseUI は Android だけのものではありません。iOSJavascript でも、コンバージョン率の高い UI を簡単に追加してカスタマイズできます。

FirebaseUI Auth クラスには、GitHub(https://github.com/firebase/FirebaseUI-Android)からアクセスできます。ぜひご活用ください。


Posted by Yuichi Araki - Developer Relations Team

この記事は Hoi Lam、Android Wear リード デベロッパー アドボケートによる Android Developers Blog の記事 "Android Wear 2.0 is here with new hardware features!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



本日(*原文公開当時)、Android Wear 2.0 の最終版 SDK がリリースされます。今回のリリースでは、昨日お知らせした新しいハードウェア機能のサポートが追加されています。明日には、一般ユーザー向けにハードウェアが発売されます。このチャンスを逃さないように、まだ公開していない方は、ぜひアプリを公開しましょう。

これまで、デベロッパー プレビュー プログラム全体にわたって、たくさんの建設的なフィードバックやバグレポートをいただきました。ありがとうございました。

Android Wear 2.0 の概要

Android Wear 2.0 は、Wear が 2014 年にリリースされて以来最大のアップデートで、たくさんのプラットフォームやデベロッパー機能が拡張されています。主な内容は次のとおりです。
  • Android Wear マテリアル デザイン - 暗色系のカラーパレット、縦方向レイアウト、WearableRecyclerViewWearableNavigationDrawer などのビジュアル コンポーネントを特徴とする新しいシステム ユーザー インターフェースとデザイン ガイドラインです。さらに、時計の通知機能も強化され、新しい MessagingStyle による高機能な通知形式やインライン アクションに対応しています。
  • ウォッチフェイス コンプリケーション - ウォッチフェイスで時間以外の情報を表示している部分をコンプリケーションと呼びます。アプリで ComplicationProviderService を作成してサポートされているウォッチフェイスにデータを提供すると、そのデータがウォッチフェイスのデザインに適した形式でレンダリングされます。
  • スタンドアロン Android Wear アプリと iOS サポート - 時計から Google Play ストアを開いて Wear 端末に直接アプリをダウンロードできるようになります。さらに、そういったアプリはスマートフォン アプリに依存せずに直接インターネットにアクセスできます。つまり、iOS 端末とペア設定されている Android Wear 端末でもアプリが動作するようになります。

新しいハードウェアのサポート

初めて Android Wear 2.0 を搭載した 2 つのモデルの時計では、ユーザーが新たな方法でスマートウォッチを操作できます。最終版 SDK では、物理ボタンの位置ロータリー入力に関連する API が追加でサポートされています。現在のところ、これらの新しい機能を試すには、新しい LG Watch Style または LG Watch Sport が必要になります。しかし現在、これらの新しいハードウェア機能をエミュレータに追加する作業を行っています。今後のアップデートにご期待ください。また、SDK には、他にもいくつかの最終的なバグの修正も含まれています。たとえば、ウェアラブル アクション ドロワーで 3 つ以上の項目がサポートされています。

アプリのレビュー プロセスの変更

Android Wear 2.0 が利用できるようになりますので、近日中に Android Wear アプリ品質レビュー プロセスをアップデートする予定です。これには、2 つの重要な変更が含まれています。1 点目は、スマートフォン アプリの通知を Android Wear 向けに強化しただけのものはレビューを通過できなくなる点です。2 点目は、近日中に Android Wear 2.0 と互換性がある APK をアップロードしなければならなくなる点です。これらの基準に合格したアプリのみがスマートフォンの Play ストアでバッジを受け取ることができ、Android Wear アプリのトップチャートの候補になります。これらの変更によって、一貫したユーザー エクスペリエンスが提供されるようになり、レビュー プロセスも効率化されます。

これからも旅は続く

Android Wear 2.0 デベロッパー プレビューは、当初の予定よりも長く続きましたが、その追加の期間は非常に有用だったと考えています。辛抱強く貢献し続けてくださった皆さんに重ねてお礼を申し上げます。皆さんの協力がなければ実現できなかった高い品質を実現することができました。

Android Wear 2.0 Developer Preview ドキュメントは、メインの Wear デベロッパー ドキュメント サイトに統合されています。また、プレビュー端末のファクトリー イメージへのリンクは今後もメンテナンスされます。デベロッパー関連のバグについては、引き続きデベロッパー バグレポートに送信するか、Android Wear デベロッパー コミュニティにコメントを投稿してください。

Android Wear チームより、重ねてフィードバックとサポートのお礼を申し上げます。


Posted by Takeshi Hagikura - Developer Relations Team

この記事は Wayne Piekarski、IoT デベロッパー アドボケートによる Android Developers Blog の記事 "Android Things Developer Preview 2" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

先日、プラットフォームへの新機能の追加とバグの修正を含む Android Things の Developer Preview 2(DP2)をリリースしました。私たちは、約 6~8 週ごとにデベロッパー向けの新しいプレビュー リリースを行うことを目指し、定期的にアップデートを提供できるよう努力を重ねています。Android Things は、Android のパワーを活用して Internet of Things(IoT)製品を構築するための包括的なソリューションです。現在は、Android デベロッパーなら誰でも Android API や Google のサービスを使ってすばやくスマート端末を構築できます。さらに、Google からアップデートが直接提供されるので、とても安全です。これには、Android Studio、Android Software Development Kit(SDK)、Google Play サービス、Google Cloud Platform などのおなじみのツールも含まれています。Android Things は System-on-Module(SoM)アーキテクチャをサポートしています。これによって、まずは開発ボードとコア コンピューティング モジュールを使い、その後、カスタム デザインで簡単に大規模な本番環境に拡大できるようになります。その一方で、Google からの同じボードサポート パッケージ(BSP)を使用し続けることができます。
新機能とバグの修正
Developer Preview 1 でのデベロッパーの皆さんのすばらしいフィードバックのおかげで、Intel Edison および Raspberry Pi 3 用のハードウェア抽象化レイヤー(HAL)に USB オーディオのサポートを追加できました。NXP Pico には、端末のオーディオの直接サポートがすでに含まれています。Peripheral I/O(PIO)に関連する多くのバグも解決されました。Bluetooth サポートなどのその他の機能リクエストは既知の問題ですが、チームはこれらの修正に積極的に取り組んでいます。また、Intel Joule プラットフォームのサポートも追加されています。これは、現在のラインナップで最大のコンピューティング パワーを提供します。
ネイティブ I/O およびユーザー ドライバ

多くのデベロッパーが IoT ソフトウェアの開発にネイティブの C または C++ コードを使っており、Android Things は標準の Android NDK をサポートしています。現在は、Peripheral API(PIO)へのネイティブ アクセスを提供するライブラリがリリースされていますので、デベロッパーは簡単に既存のネイティブ コードを利用できます。新しい API の説明はドキュメントを、使用方法の例はサンプルをご覧ください。
Android Things DP1 で利用できるようになった重要な新機能は、ユーザー ドライバのサポートでした。デベロッパーは APK でユーザー ドライバを作成し、フレームワークにバインドできます。たとえば、ドライバのコードで GPIO ピンを読み出して通常の Android KeyEvent を発行したり、シリアルポート経由で外部 GPS を読み出して Android ロケーション API に提供したりできます。これによって、Linux カーネルや HAL をカスタマイズせずに、任意のアプリケーションでハードウェア イベントをフレームワークに注入できます。私たちは、センサー、ボタン、ディスプレイなど、さまざまな一般的なハードウェア インターフェース用のユーザー ドライバのレポジトリを管理しています。また、デベロッパーが独自のドライバを作成してコミュニティに共有することもできます。
Android Things 向けの TensorFlow

Android Things で特に興味深い機能の 1 つは、機械学習やコンピュータ ビジョンを簡単に導入できる能力です。リクエストの多かった、Android Things 端末で TensorFlow を使用する方法を説明するサンプルも作成しました。このサンプルでは、カメラにアクセスして物体認識とイメージ分類を行い、テキスト読み上げ(TTS)を使って結果を読み上げる方法を説明しています。アーリーアクセス TensorFlow インターフェース ライブラリは、ARM および x86 向けに事前ビルドされています。そのため、build.gradle ファイルに 1 行追加するだけで、任意の Android アプリに簡単に TensorFlow を追加できます。



犬の種類を識別する TensorFlow サンプル(アメリカン スタッフォードシャー テリア) 
カメラを搭載した Raspberry Pi 3 で動作

フィードバック

以前の Developer Preview にフィードバックを送ってくださったすべてのデベロッパーの皆さん、どうもありがとうございました。バグレポート機能リクエストを送信し、引き続きフィードバックをお願いします。質問は、どんなものでもかまいませんので、stackoverflow にお寄せください。Developer Preview 2 イメージは、Android Things ダウンロード ページからダウンロードできます。変更点はリリースノートをご覧ください。Google+ の Google IoT デベロッパー コミュニティにも参加できます。これは、最新情報やアイデアを話し合うことができるすばらしいリソースで、3000 名以上の新しいメンバーが参加しています。



Posted by Yuichi Araki - Developer Relations Team

この記事は Alex Fischer、Google 検索ソフトウェア エンジニアによる Google Developers Blog の記事 "What’s in an AMP URL?" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

(この投稿は長文です。)本日(*原文公開当時)、Google 検索に 1 つの AMP 統合機能が追加され、ユーザーが AMP ドキュメントの canonical URL にアクセスし、それをコピーしたり共有したりできるようになりました。このニュースを詳しく取り上げる前に、少し後戻りして AMP の世界の URL とそれが AMP のメリットであるスピードとどう関連しているのかについて説明しましょう。

URL とは何でしょうか。ウェブでは、それはさまざまなものを意味します。URL とオリジンは、ある程度、コンテンツの信頼性と所有権を示すものです。ニューヨーク タイムズの記事を読むとき、一瞬でも URL に目を向ければ、読んでいるものが本当にニューヨーク タイムズの記事なのかどうか、その信頼度がわかります。帰属先、ブランド、所有権がわかるからです。

しかし、最近リリースされたさまざまなモバイルアプリや Google 検索の AMP 対応によって、この点が少しわかりにくくなっています。この投稿では、まず私たちの技術的な決定の理由を説明し、さまざまな AMP URL について詳しく説明します。次に、 URL にまつわる懸念事項に対処するために行った変更点について、概略を説明します。

まず、AMP ドキュメントには、次の 3 種類の URL があります。
  • オリジナル URL: AMP フォーマットで記述されたサイトオーナーのドキュメントです。http://www.example.com/amp/doc.html 
  • AMP Cache URL: AMP Cache から提供されるドキュメントです(例: Google が提供するすべての AMP は、Google AMP Cache 経由で提供されます)。ほとんどのユーザーは、この URL を目にすることはありません。https://www-example-com.cdn.ampproject.org/c/www.example.com/amp/doc.html 
  • Google AMP ビューアー URL: AMP ビューアーに表示されるドキュメントです(例: 検索結果ページに表示されるとき)。https://www.google.com/amp/www.example.com/amp.doc.html




本質的に同一のコンテンツについて、オリジンが異なる 3 種類の URL が存在します。そのため、混乱を生む可能性もありますが、これには主に 2 つの理由があります。それは、キャッシュとプリレンダリングです。これらは AMP のスピードに大きく貢献しますが、どちらにも新しい URL が必要になります。その点について、詳しく説明しましょう。

AMP Cache URL
まず、AMP Cache URL について説明します。AMP Cache が存在する理由は、Google の AMP デベロッパー アドボケートである Paul Bakaus の投稿で丁寧に説明されています。この投稿では、AMP Cache のメリットが詳しく説明されていますが、なぜ新しい URL が必要になるのかという点は、特に説明されていません。この質問への回答は、AMP の設計原則の 1 つである「導入の簡単さ」によるものです。AMP は、いくつかのモバイルウェブの問題を大規模に解決しようとするものです。そのため、AMP のコンポーネントは誰でも簡単に使えるものでなければなりません。

AMP Cache が提供する検証、ユーザーからの近さなどのさまざまなメリットは、他の方法でも得ることができます。しかし、自身の DNS エントリを管理していない小さなサイトでは、複雑な API 経由でコンテンツをプッシュするエンジニアリング リソースがなかったり、コンテンツ配信ネットワークの費用がまかなえなかったりするため、そのようなテクノロジーを利用できません。

そのため、Google AMP Cache は簡単な URL 「変換」によって動作します。ウェブマスターは、ある URL でコンテンツを利用可能にするだけです。Google AP Cache はそのコンテンツをキャッシュし、オリジナルを反映した変換済みのドキュメントを、全世界に広がる Google のインフラ上の新しい URL で提供します。これはとてもシンプルな方法です。一方で、オリジナルの URL を使って AMP Cache を活用しようとする場合、ウェブマスターが DNS レコードを変更したり、ネームサーバーを再設定したりしなければなりません。実際にそれを行っているサイトもありますが、大多数のサイトでは、URL ベースの方が使いやすいアプローチでしょう。 

AMP ビューアー URL
先ほどのセクションでは、Google AMP Cache URL について説明しました。これは、キャッシュされた AMP ドキュメントを指す URL でした。しかし、www.google.com/amp という URL はどうでしょう。なぜこれが必要になるのでしょうか。これは、プリレンダリングに必要な「AMP ビューアー」の URL です。

AMP がプライバシーとリソースに配慮したプリレンダリングをビルトインでサポートしていることは、滅多に話題に上がることはなく、誤解されることもよくあります。AMP ドキュメントはプリレンダリングが可能です。その際に、リソースを連続で取得したり、ユーザーの CPU やメモリを大量に消費したり、プライバシーに注意が必要なアナリティクス コードを実行する必要はありません。この点は、呼び出し側のアプリがモバイルウェブ ページでも、ネイティブ アプリでも変わりません。ただし、新しい URL が必要になります。主にこれは、モバイルウェブの実装が関係しています。ここでは、例として、Google のモバイル検索結果ページ(SERP)を使って説明します。
プリレンダリングの仕組み

ユーザーが AMP に対応した結果を返す Google 検索を行う場合、その結果の一部は裏でプリレンダリングされています。ユーザーがプリレンダリングされた結果をクリックすると、AMP ページが即座に読み込まれます。

呼び出し元のページ(検索結果ページ)の隠し iframe に、AMP ページのコンテンツと、AMP ドキュメントがプリレンダリング中であることを示す追加パラメータを読み込むことで、プリレンダリングは機能します。この iframe のライフサイクルを管理する JavaScript コンポーネントは、「AMP ビューアー」と呼ばれます。

AMP ビューアーが隠し iframe 内で AMP ドキュメントをプリレンダリング 

ユーザーのブラウザは、ドキュメントと AMP ランタイムを読み込み、AMP ページのレンダリングを開始します。イメージや埋め込み要素など、その他のリソースはすべて AMP ランタイムが管理するため、この時点で読み込む必要があるものはこれだけです。AMP ランタイムはリソースを取得することもありますが、それはリソースとプライバシーに配慮した形で行われます。

ユーザーが結果をクリックした際に AMP ビューアーがしなければならないのは、レンダリング済みの iframe を表示させ、AMP ドキュメントが表示されたことを AMP ランタイムに知らせるだけです。

おわかりのように、この操作はとても軽いものです。ネットワークを経由せず、新しいページへの実際のナビゲーションも発生しません。そのため、結果がほぼ即座に読み込まれます。
google.com/amp という URL の正体

以上の動作はすべて、ユーザーがオリジナルのページ(この例では、検索結果ページ)にいる間に行われます。つまり、ユーザーは別のページには移動していません。同じページにある iframe を表示しているだけなので、ブラウザの URL は変わりません。

しかし、ブラウザの URL には、画面に表示されているページの URL を反映させて、ユーザーが簡単にリンクできるようにしたいものです。また、ユーザーがブラウザの更新ボタンを押した際には、裏にある検索結果ページではなく、同じドキュメントが表示されることが期待されます。そのため、AMP ビューアーは手動でこの URL をアップデートしています。これは、History API を使って実現されています。AMP ビューアーは、この API を使って実際のナビゲーションを行わずにブラウザの URL バーをアップデートしています。

ここで問題になるのが、ブラウザがどの URL にアップデートするのかという点です。結果自身の URL(例: www.example.com/amp/doc.html)か、AMP Cache URL(例: www-example-com.cdn.ampproject.org/www.example.com/amp/doc.html)を表示するのが理想的でしょう。しかし、残念ながら、どちらもうまくいきません。History API の大きな制約の 1 つに、新しい URL はオリジナルの URL(リファレンス)と同じオリジンでなければならない、というものがあります。この制約は(セキュリティ上の理由によって)ブラウザによって強制されます。Google 検索においては、この URL が www.google.com オリジンである必要があります。

ヘッダーバーを表示する理由

先ほどのセクションでは、AMP ビューアーが従わなければならない URL の制限について説明しました。しかし、この URL は混乱や誤解を生むことも考えられ、フィッシング攻撃の入り口となる可能性もあります。AMP ページに Google のようなログインページが現れ、URL バーに www.google.com と表示されていれば、ユーザーはそのページが実際に Google のものだと思ってしまうでしょう。そのため、追加で帰属先を表示する必要があります。
コンテンツの帰属先を適切な形で提供できるように、AMP ビューアーでは、表示されているコンテンツの提供元を必ずユーザーに明示しなければなりません。それを実現する手段の 1 つとして、ヘッダーバーを追加して「実際の」ページのオリジンを表示する方法があります。

次のステップ

ここまでのセクションで、いくつかの異なる URL が存在する理由と、AMP ビューアーに必ずヘッダーが存在する理由を明確に理解していただけたと思います。このアプローチと URL の重要性に関しては、皆さんの意見に耳を傾けてきました。では、次のステップは何でしょうか。ご存じのとおり、私たちは慎重に事を進め、ユーザーが AMP ページに期待するスピードやパフォーマンスを維持できるようにしたいと考えています。
2016 年 2 月に Google 検索の AMP 対応を行って以来、私たちは次の手順を踏んできました。
  • すべての Google の URL(例: Google AMP Cache URL や Google AMP ビューアー URL)で、www.google.com/amp/www.example.com/amp/doc.html のように可能な限りオリジナルのコンテンツの URL を反映させる。 
  • ユーザーがドキュメントを読むためにページをスクロールする際には、AMP ビューアーのヘッダーバーを非表示にして、貴重な画面上の領域を解放する。 
  • ビューアーが利用できないプラットフォームでユーザーが Google AMP ビューアー URL にアクセスした際には、ドキュメントの canonical ページにリダイレクトする。
これらに加え、多くのユーザーがドキュメントの canonical URL にアクセスし、それをコピーしたり共有したりする機能をリクエストしていました。本日より、Google 検索の AMP ビューアーのヘッダーにあるアンカーボタンという形でこの機能がサポートされています。これによって、ユーザーは表示されるリンクを長押しして、ブラウザのネイティブ共有機能を使えるようになります。



今後数週間の間に、Android Google アプリでも、共有ボタンをタップした際にドキュメントのオリジナル URL を共有できるようになります。iOS Google アプリでは、すでにこの機能が利用できるようになっています。

また、私たちは、まもなく登場するウェブ プラットフォーム API を活用してこの機能をさらに改善しようとしています。そのような API の 1 つに、Web Share API があります。これを活用すると、AMP ビューアーから AMP ビューアーの URL ではなく、オリジナルの URL を使ってプラットフォーム ネイティブの共有フローを呼び出すことができます。

私たち Google は、ユーザーとサイトオーナーの両方にとってできる限り最高の AMP 体験を提供したいと常に考えています。エコシステムの繁栄は私たちにとって非常に重要なことで、そのエコシステムにとって重要になるのが、コンテンツの帰属先、ユーザーの信頼、所有権です。このブログ投稿によって、AMP ドキュメントの 3 つの URL の由来と、それらが AMP の高速化に果たしている役割、そして Google 検索の AMP をさらに改善しようという私たちの努力について、理解を深めていただければ幸いです。最後になりますが、エコシステムとは皆さんの参加があってこそ繁栄するものです。ぜひフィードバックをお寄せください。そして、AMP に参加してください。


Posted by Yoshifumi Yamaguchi - Developer Relations Team

この記事はホーム画面のヒロイン、Xi Han による Chromium Blog の記事 "Chrome 57 Beta: CSS Grid Layout, Improved Add to Home screen, Media Session API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

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

CSS グリッド レイアウト
大きな LCD テレビから小さなウォッチ フェイスまで、サイトはさまざまな大きさの画面からアクセスされるようになっています。以前は、こういったすべての画面サイズをサポートするためにマークアップと CSS の複雑な組み合わせが必要だったため、コードの管理が難しくなっていました。そこで、現在の画面サイズに合わせて要素をどのように拡大縮小させるかをデベロッパーが細かく制御できるように、CSS グリッド レイアウト利用できるようになります。

CSS グリッドは、2 次元グリッドをベースとしたレイアウト システムをサポートするもので、レスポンシブ ユーザー インターフェースの設計に最適です。グリッド内の要素は、複数の行や列にまたがるよう指定することも可能です。CSS グリッドの中に配置する要素には名前を付けることができるので、レイアウトのコードはわかりやすく書くことができます。
CSS グリッドを使うと、デベロッパーはグリッドに要素を自由に配置可能。要素の配置方向、拡大縮小の動作、応答性の制御も自由自在。


ホーム画面に追加の改善

Chrome for Android では、かなり前のバージョンから、ユーザーがすばやく簡単にサイトにアクセスするために、サイトをホーム画面に追加することができました。この機能では、Android ショートカットを利用してアイコンを追加します。つまり、ウェブアプリは Android にインストールされたネイティブ アプリと同じように動作するわけではありませんでした。

今回のリリースでは、ユーザーが Chrome を使って プログレッシブ ウェブアプリ をホーム画面に追加すると、今までよりも深いレベルで Android に統合されるようになります。たとえば、プログレッシブ ウェブアプリはランチャーのアプリドロワー部分や Android 設定に表示されるようになり、他のアプリからのインテントも受信できるようになります。また、通知を長押しすると、Chrome の通知管理コントロールではなく、通常の Android 通知管理コントロールが表示されます。

Media Session API

モバイルウェブは、メディアを表示するために使われることもよくあります。デベロッパーが Chrome for Android の新しい Media Session API を利用すると、ロック画面の UI や通知をメディア コンテンツを使ってカスタマイズできます。デベロッパーは、再生するコンテンツのメタデータをブラウザに設定することで、タイトル、アーティスト、アルバム名、アートワークなどの情報を含む高機能なロック画面を作成できます。さらに、頭出しやスキップなど、通知上でユーザーが行った操作にサイトを応答させることもできます。




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

  • Android 端末で動画が全画面になると、その動画のアスペクト比に応じて自動的に画面の向きがロックされるようになりました。 
  • 連続して setTimeout() を使っているサイトは、ループを使って画面外でフレーム アニメーションを動かす際に制限を受けるようになります。これによって、ユーザーのパフォーマンスが改善されます。 
  • Fetch APIResponse クラスが .redirected 属性をサポートするようになりました。これにより、ウェブ デベロッパーは信頼できないレスポンスを回避し、リダイレクト先が開かれるリスクを軽減できます。 
  • 新しいフォーマット ツールである padStart および padEnd によって、テキストのパディングが可能になりました。これにより、コンソール出力の位置合わせや、数値の桁数固定表示が容易になります。 
  • Service Worker Navigation Preload がオリジン トライアルとして利用できるようになりました。これにより、デベロッパーは主要なリソースに対するネットワーク リクエストと Service Worker の起動を並列に実行できるようになります。 
  • Payment Request API を iframe 内で実行できるようになりました。これは、allowpaymentrequest 属性を追加することによって実現します。 
  • PaymentMethodDatabasic-card がサポートされます。これにより、デベロッパーは 1 つのメソッド識別子であらゆる種類のカードを参照できるようになり、個々のデータタイプを使う必要がなくなりました。 
  • HTTP から HTTPS への移行を簡単にするために、HTTP フォームで保存された認証情報が HTTPS 版のサイトに引き継がれるようになりました。また、Credential Management API は、サブドメインが一致する認証情報を自動設定できるようになりました。 
  • caret-color プロパティを使うと、デベロッパーがテキスト入力カーソルの色を指定できます。 
  • 他の on<event> 属性との一貫性を維持するため、ongotpointercaptureonlostpointercaptureGlobalEventHandlers mixin の一部になりました。 
  • text-decoration-skip: ink がサポートされるようになりました。これにより、ディセンダー(文字がテキストのベースラインより下にはみ出る部分)の下線をスキップできます。 
  • 新しい text-decoration プロパティが利用できるようになりました。これにより、デベロッパーは線の色やスタイルなどの視覚効果を指定できます。 
  • PresentationRequest コンストラクタが変更され、sequence<DOMString> 経由で複数の URL を受け取れるようになりました。単一の URL を受け取る既存のコンストラクタも利用できます。 
  • AudioContext.getOutputTimestamp() メソッドが新しく追加され、デベロッパーは DOMHighResTimeStampAudioContext.currentTime の値を同期させることができます。 
  • AudioBufferSourceNodeOscillatorNodeConstantSourceNodeAudioScheduledSourceNode から継承されるようになりました。これにより、機能が統合されます。 
  • cancelTime 以後の時間の AudioParam イベントをキャンセルする cancelAndHoldAtTime 関数が新しく追加されました。これにより、デベロッパーはスケジュールされた時間の値を直接的に保存できます。 
  • OfflineAudioCompletionEventAudioProcessEvent などの WebAudio 固有のイベントをデベロッパーが作成できるようになりました。 
  • ユーザー セキュリティ強化のため、Chrome の XSS Auditor は、デフォルトでページの疑わしい反射型 XSS の一部を除外するのではなく、疑わしいページ全体をブロックするようになりました。

廃止予定と相互運用性の改善 


  • <keygen> 要素のサポートが削除されました。これにより、フォームの要素データには何も表示されなくなり、送信もされなくなります。これは、他のブラウザの機能に合わせるための措置です。 
  • 以前にお知らせしたように、EnableSha1ForLocalAnchors エンタープライズ ポリシーが設定されていない場合、ローカルで信頼される SHA-1 証明書を使っているページで証明書エラーページが表示されるようになりました。 
  • fieldset.elementsHTMLFormControlsCollection ではなく HTMLCollection を返すようになります。これは、仕様への準拠のための措置です。 
  • <cursor> 要素が削除されました。なお、カーソル アイコンは cursor CSS プロパティで設定することができます。 
  • HTMLEmbedElementHTMLObjectElement から legacycaller が削除されました。これにより、これらのインターフェースのインスタンスを関数として呼ぶことはできなくなり、そうした場合例外がスローされるようになります。 
  • usemap 属性で大文字、小文字が区別されるようになりました。 
  • IndexedDB のグローバル エイリアスですべての -webkit- 接頭辞が削除されました。これらは、M38 でサポートが終了しています。 
  • Service Worker のカスタム メッセージ イベントと、client.postMessage(message, transfer) によって作成されるイベントで、ServiceWorkerMessageEvent の代わりに MessageEvent が使用されるようになりました。これは、HTML MessageEvent仕様拡張に従うための措置です。 
  • Performance インターフェースから webkitClearResourceTimings()webkitSetResourceTimingBufferSize()onwebkitresourcetimingbufferfull のサポートが削除されました。代わりに、clearResourceTimings()setResourceTimingBufferSize()onresourcetimingbufferfull が提供されています。 
  • 以下の -internal CSS セレクターのサポートが終了します。-internal-media-controls-cast-button-internal-media-controls-overlay-cast-button、およびすべての -internal-media-controls-text-track-list セレクター。 
  • 古い API webkitCancelRequestAnimationFrame のサポートが削除されました。代わりに、cancelAnimationFrame が提供されています。 
  • Android で、contenteditable コンテナのデフォルトに wordWrap: break-word および -webkit-line-break: after-white-space が設定されなくなります。これは、ブラウザ間の一貫性を維持するための措置です。 
  • AudioContext および OfflineAudioContext から webkit 接頭辞が削除されました。


この記事は Yaron Friedman、ホーム画面に追加の熱烈なファンによる Chromium Blog の記事 "Integrating Progressive Web Apps deeply into Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2015 年、Chrome for Android に新しい機能が追加されました。ユーザーにすばやく簡単にアクセスしてもらえるよう、ホーム画面にデベロッパーのサイトを追加してもらうことを促す機能です。この機能は、Android ショートカットを利用しています。つまり、ウェブアプリは Android にインストールされたネイティブ アプリと同じように動作するわけではありません。たとえば、多くのデベロッパーから、ランチャーのアプリドロワー部分に自分のウェブアプリを表示できないかという質問が寄せられます。この違いはユーザーにとって混乱の元であり、統一性のあるユーザー エクスペリエンスを提供する妨げとなっています。

今後数週間のうちにロールアウトされる Chrome ベータ版で、この機能の改訂版を公開します。この改訂版では、ユーザーが プログレッシブ ウェブアプリ をホーム画面に追加した際に、今までよりも深いレベルで Android に統合されます。たとえば、ランチャーのアプリドロワー部分や Android 設定に表示されるようになり、他のアプリからのインテントも受信できるようになります。また、通知を長押しすると、Chrome の通知管理コントロールではなく、通常の Android 通知管理コントロールが表示されます。



このホーム画面に追加の新機能は、最高のユーザー エクスペリエンスを提供するためにデベロッパーができることを増やす新たな 1 歩です。また、私たちは、Android のすべてのブラウザで プログレッシブ ウェブアプリ をインストールする仕組みが利用できるよう、努力を続けています。

この記事は Amy McDonald SandjidehTensorFlow テクニカル プログラム マネージャーによる Google Developers Blog の記事 "Announcing TensorFlow 1.0" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

TensorFlow は、誕生して 1 年の間に 自然言語翻訳から皮膚がんの早期検知糖尿病による失明の防止までのさまざまな分野で、研究者、エンジニア、アーティスト、学生など、多くの人を支えてきました。現在まで 6,000 以上のオープンソース オンライン リポジトリで活用されるすばらしい成果が得られました。

そして 2 月 15 日、第 1 回目の TensorFlow デベロッパー サミットが米国マウンテンビューで開催され、世界中にライブストリーミングされるなか、私たちは TensorFlow 1.0 を発表しました。

TensorFlow 1.0 は速くなりました。圧倒的に高速です。今回新たにリリースされたコンパイラ XLA は、今後のさらなるパフォーマンス改善の土台となります。 tensorflow.org には、モデルをさらに高速化するためのおすすめの方法を掲載しています。また、よく利用されるモデルにおいて TensorFlow 1.0 の性能をフルに活用するためのアップデートがまもなく公開される予定です。例えば  Inception v3 に対して 8 GPU を用いた学習で 7.3 倍、64 GPU で 58 倍の高速化が可能になるモデルを提供します。

TensorFlow 1.0 は使いやすくなりました。tf.layers、tf.metrics、tf.losses モジュールなどのハイレベル API が新たに導入されています。また、新しい tf.keras モジュールの導入も発表されました。これは、ニューラル ネットワーク 設計のための高レベル API として人気のある Keras と完全な互換性があります。

TensorFlow 1.0 はより実運用向けになりました。Python API の仕様がフィックスされ(詳細はこちら)、既存のコードを損なうことなく新機能を簡単に試せます。

TensorFlow 1.0 のその他の主な特徴は以下のとおりです。

  • Python API が変更され、NumPy との親和性がさらに高くなりました。この点を含め、今後の API の互換性を確保するため、これまでの API との互換性が失われる変更がいくつか行われています。移行に便利な移行ガイドおよび変換スクリプトをご活用ください
  • Java および Go の試験運用版 API が追加されています
  • tf.contrib.learnskflowTF Slim を組み込んだハイレベル API モジュール tf.layers、tf.metrics および tf.losses が追加されています
  • 特定の CPU および GPU に向けた TensorFlow コンパイラ XLA が試験運用版としてリリースされています。XLA は今後も急速に進化していく予定です。今後のリリースでの進展にご期待ください
  • TensorFlow プログラムをその場でデバッグできるコマンドライン インターフェースおよび API として TensorFlow Debugger(tfdbg)が導入されました
  • 物体検知や翻訳、さらにカメラを使った画像スタイル変換を行う Android 向けのデモが新しく追加されました
  • インストールが改善されています。Python 3 の Docker イメージが追加され、TensorFlow の pip パッケージが PyPI 互換になりました。これにより、pip install tensorflow と実行するだけで TensorFlow をインストールできます。
いま世界中で、TensorFlow コミュニティが急速に広がりつつあります。TensorFlow 1.0 についてさらに知りたい方は、YouTube に掲載された TensorFlow デベロッパー サミットのセッションをご覧ください。新たに追加されたハイレベル API をはじめ、モバイルでの TensorFlow の活用、新しい XLA コンパイラまで、最新のアップデート内容が網羅されています。また、TensorFlow を活用したすばらしい事例もいくつか紹介されています。




動画リストへのリンクはこちらです。

動的バッチ用の FoldEmbedding Projector など、TensorFlow のエコシステムは急成長し続けています。また TensorFlow Serving などの既存ツールもアップデートされています。

誰でも使えるディープ ラーニングの実現に向けて貢献いただいてきた開発者や研究者、教育機関の皆さまに、深く感謝いたします。今後も、GitHub の issue ページStack OverflowTwitter の @TensorFlow アカウント、Google グループ discuss@tensorflow.org などのフォーラムや、今後開催されるイベントを通じて皆さまとコラボレーションできることを楽しみにしています。

Posted By: Amy McDonald Sandjideh, Technical Program Manager, TensorFlow

Translated by Kaz Sato - Staff Developer Advocate,  Google Cloud


[この記事は Vamsee Jasti、AMP Project プロダクト マネージャーによる Accelerated Mobile Pages Project の記事 "New default placeholders for ads in AMP" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

2017 年 2 月 9 日(木)に本番リリースされたばかりの AMP の追加機能をご紹介します。これは小さな機能ですが、視覚的なインパクトは絶大です。

AMP ページには、コンテンツが非常に高速に読み込まれます。しかし、従来型の広告の読み込みは相対的に遅く感じられます。サイトオーナーのページに空白の部分ができ、コンテンツが欠落しているように感じられ、快適に読むことができません。

軽く、高速で安全な広告を AMP コンテンツと同程度の速さで提供するには、AMP 広告への切り替えを検討する必要があります。

しかし、それまでの間、空の広告スペース問題に対処するために、AMP ページに配置されるすべての広告について、2 つのデフォルト機能を追加しています。広告にサイトオーナーが設定したプレースホルダがない場合、AMP は自動的に以下を追加します。
  1. 明示された「Ad」ラベル 
  2. 広告が読み込み中であることを示す上部の目立たない読み込みアニメーション
新しいデフォルト広告読み込みインジケーターとプレースホルダ機能



プレースホルダには広告であることが明示されているので、ユーザーはコンテンツに集中し、必要に応じて広告に注意を向けることもできます。さらに、広告の読み込み中にコンテンツが欠落していると思われる心配もありません。


目立たない読み込みインジケーターの拡大画面 


これは、ページにデフォルトのプレースホルダ を設定しているサイトオーナーにとっては、前提を覆すような変更になります。私たちもそれを承知していますが、この変更によって、ユーザーは前述のような多大なメリットを得ることができます。サイトオーナーが設定するプレースホルダは、今後も今までどおりに広告の読み込みを完全に制御できます。

AMP 開発チャンネルをオプトインして「amp-ad-loading-ux」試験運用版をサブスクライブし、この機能が既存のコンテンツにうまく適応できるかどうかを試してみることをお勧めします。


皆様のフィードバックをお待ちしています。


Posted by Yoshifumi Yamaguchi - Developer Relations Team

この記事は Jacob Wenger, ソフトウェア エンジニアによる The Firebase Blog の記事 "Firebase Cloud Messaging integrated into the Admin Node.js SDK" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

私たちは Firebase を通じ、デベロッパーがサーバーの管理から解放され、クライアントサイドのコードだけでウェブアプリやモバイルアプリを作成できる世界を実現するために努力しています。しかし、ときには独自にサーバーを立ち上げて活用しなければならない場合もあります。そこで、昨年 11 月に Firebase Admin SDK発表しました。

本日は、Admin SDK の 2 つの新機能を紹介します。
  • Node.js SDK に、Firebase Cloud Messaging(FCM)経由でメッセージを送信するための Admin API が追加されました。
  • Java SDK が複数のビルトイン認証情報で初期化できるようになり、とりわけ Google のインフラ上で簡単に使えるようになりました。
Admin Node.js FCM API

新しい Admin Node.js FCM API では、FCM 経由でメッセージを送信するプロセスが簡単になっています。この新しい API は、何の追加設定もしなくても使うことができます。Node.js SDK の認証を行っている既存の認証情報がすべて処理してくれるからです。新しい API には、個々の端末、端末グループ、トピック、条件に対してメッセージを送信するメソッドが含まれています。
たとえば、開催が迫っているスーパーボウル用のアプリを作成し、アトランタ ファルコンズのトピック(/topics/falcons)またはニューイングランド ペイトリオッツのトピック(/topics/patriots)をサブスクライブしているユーザーに通知する場合を考えてみましょう。
var admin = require("firebase-admin");

// Fetch the service account key JSON file contents
var serviceAccount = require("path/to/serviceAccountKey.json");

// Initialize the app with a service account, granting admin privileges
admin.initializeApp({
  credential: admin.credential.cert(serviceAccount),
  databaseURL: "https://<DATABASE_NAME>.firebaseio.com"
});

// Define who to send the message to
var condition = "'falcons' in topics || 'patriots' in topics";

// Define the message payload
var payload = {
  notification: {
    title: "Super Bowl LI: Falcons vs. Patriots",
    body: "Your team is Super Bowl bound! Get the inside scoop on the big game."
  }
};

// Send a message to the condition with the provided payload
admin.messaging.sendToCondition(condition, payload)
  .then(function(response) {
    console.log("Successfully sent message! Server response:", response);
  })
  .catch(function(error) {
    console.log("Error sending message:", error);
  });
各 FCM メソッドには、3 番目の省略可能な引数に、メッセージのオプションを指定することもできます。たとえば、試合までもう 1 週間を切っているので、有効期間が 1 週間のメッセージを優先度 high で送ってみましょう。
// condition and payload are the same as above

var options = {
  priority: "high",
  timeToLive: 60 * 60 * 24 * 7
};

admin.messaging.sendToCondition(condition, payload, options)
  .then(function(response) {
    console.log("Successfully sent message! Server response:", response);
  })
  .catch(function(error) {
    console.log("Error sending message:", error);
  });
新しい Admin Node.js FCM API を使うと、このようなことができます。詳しいコードサンプルやドキュメントについては、メッセージの送信をご覧ください。

Admin Java 認証情報インターフェース 

昨年 11 月に Admin SDK が公開されて以来、Node.js SDK はいくつかの初期化メソッドをサポートしていますが、Java SDK はサービス アカウント証明書ファイルを使った初期化しかできませんでした。最新の Admin Java SDK リリースでは、同様な認証情報インターフェースが両方の SDK とも提供するようになっています。そして、いくつかの便利なデフォルト実装もあります。

新しい API へのアップグレードは簡単です。以前からの SDK 初期化方法では、次のように setServiceAccount() メソッドを使います。
FileInputStream serviceAccount = new FileInputStream("path/to/serviceAccountCredentials.json");

FirebaseOptions options = new FirebaseOptions.Builder()
    .setServiceAccount(serviceAccount)
    .setDatabaseUrl("https://<DATABASE_NAME>.firebaseio.com")
    .build();

FirebaseApp.initializeApp(options);
アップデートされた SDK 初期化方法では、次のように setCredential() メソッドを使います。
FileInputStream serviceAccount = new FileInputStream("path/to/serviceAccountCredentials.json");

FirebaseOptions options = new FirebaseOptions.Builder()
    .setCredential(FirebaseCredentials.fromCertificate(serviceAccount))
    .setDatabaseUrl("https://<DATABASE_NAME>.firebaseio.com")
    .build();

FirebaseApp.initializeApp(options);

Admin Java SDK には、Google Application Default Credentials に基づいた認証情報の実装も含まれており、Google App Engine や Google Compute Engine など、Google のインフラ上でのサービス アカウント認証情報を自動検出できます。これによって、サービス アカウントの認証情報を自分で管理する必要がなくなります。そのため、何の設定も行わなくても、Google Application Default Credentials を使ってローカル環境、ステージング環境、本番環境でまったく同じコードを実行できます。
FirebaseOptions options = new FirebaseOptions.Builder()
    .setCredential(FirebaseCredentials.applicationDefault())
    .setDatabaseUrl("https://<DATABASE_NAME>.firebaseio.com")
    .build();

FirebaseApp.initializeApp(options);

詳しいコードサンプルやドキュメントは、SDK の初期化をご覧ください。

Admin SDK の今後


Firebase エコシステムのバックエンド デベロッパーに優れたサポートを幅広く提供するため、私たちは努力を続けています。Firebase Admin SDK に追加される今後の機能にもご期待ください。ご希望の機能がある場合は、機能リクエスト サポート チャンネルからリクエストを送信してください。


Posted by Khanh LeViet - Developer Relations Team



Google Developer Groups(GDG)というコミュニティをご存知ですか? GDG は、Google のテクノロジーに興味をもつデベロッパーの集まりで、Android、Chrome、Drive、Cloud などのプラットフォームから Google Cast API、Maps API などの製品 API まで幅広い内容を扱っています。

IMG_20160903_132136.jpg

海外で行われるイベントのライブ・ビューイングをすることもあれば、デモやテックトーク、コードラボをすることもあり、内容や規模はそれぞれの GDG で異なります。言えるのは、GDG はデベロッパーと技術的なコンテンツに焦点を置いているということです。

GDG は世界各地にあり、日本でも各地にチャプター(支部)があります。今回、GDG の活動を紹介するために「GDG Stories Asia」というキャンペーンを実施し、GDG として活動しているオーガナイザーやコミュニティのメンバーの皆さんにアンケートにご協力をいただきました。


松岡 謙治 さん(GDG 九州オーガナイザー)

Q: GDG のオーガナイザーをしているのはなぜですか?
気がつけば Google で情報を検索し、Android スマートフォンを使用し、GoogleAppEngine で業務アプリを作っており Google だらけになっていたときに、Google 社員の松尾さんよりGTUG 九州(GDG の前身コミュニティ)を立ち上げたい人の募集を聞き、何か貢献できたらと思ったためです。

Q: 意味や影響が大きかったとご自身が感じる、GDG にまつわる体験談を共有してください。 
GDG Organizers Summit で出会った人たち、そしてそこで知った Optimize My life の言葉は自分の中の働く理由を変え、自分の能力を活かしてお金にする手段としての仕事から、自分のやりたいことを達成するために仕事をするように気持ちが変わりました。それまでのサラリーマンとして言われた仕事をやる立場を脱してフリーランスとして独立し、仕様策定や企画まで含めて仕事にすることができるようになりました。

Q: あなたが開発者になりたいと思ったきっかけは何ですか?
子どもの頃から物づくりが好きでしたが、電子部品などは高くて購入することができませんでした。プログラミングなら中古のコンピューター1台で心ゆくまで開発することができたからです。


津田 恭平 さん(GDG 石巻オーガナイザー)

Q: GDG のオーガナイザーをしているのはなぜですか?
世界への扉を共有したいからです。GDG の活動を通じることにより、海外の方とのコミュニケーションや新しい技術の情報を得る機会が多くなりました。そういった機会を多くの方(とくに東北地方の方に)に共有したいと思っています。

Q: 意味や影響が大きかったとご自身が感じる、GDG にまつわる体験談を共有してください。 
Android の勉強会をしたときのことです。せっかくなので勉強した内容をプログラミングに関する知識を記録・共有するサービス(Qiita)に投稿しようということになりました。2 名の学生が投稿したところ、いくつかの Like(Stock)が付きました。自分が書いた内容が他の誰かに役にたっていると知り、彼らはとても喜んでいました。GDG 石巻として、彼らが将来良い開発者になれるよう願っています。

Q: Google が果たした役割とはどのようなものでしょうか?
東日本大震災の津波で家を被災した当時、私は大学生でした。多くの家屋が崩壊するのを目の当たりにし、「物はいつか壊れるかもしれない、しかし頭の中にあるものはずっと残り続ける」と感じました。それから勉学に勤しみ、いつのまにかプログラミングを始めていました。

そして、当時流行りはじめていたスマホアプリの開発に興味を持ち始めました。学部は文系だったため、本を買って独学で行おうと考えていましたが、友人の紹介で知った東北 TECH 道場に参加することになりました。これは、Google が主催(現在は後援)する初心者向けのイベントで、現役で活躍しているエンジニアからレクチャーを受けながら 3 か月をかけて Android 開発を行うというものでした。この東北 TECH 道場の参加をきっかけに Java や Android のアプリ開発を学び、その後、多くのハッカソンに参加して、仕事を請けるまでになりました。そして昨年に GDG 石巻を立ち上げ、2016 年の春に個人事業主として起業しました。

現在は、エンジニアとしてスマホアプリの受注のほか、自社サービスとして釣りアプリの開発をしています。私がエンジニアとして活動ができているのは、東北 TECH 道場のお陰だと思っています。

GDG 石巻には他にも、東北 TECH 道場のために石巻を訪れたことがきっかけで石巻へ移住したメンバーや、TECH 道場や GDG のイベントが「技術を使って好きな生き方ができる」と実感できる大切な場所となり、そこから技術者になろうと決断した、といったように人生に影響を与えられたメンバーがいます。


藏野 文子さん(GDG 京都オーガナイザー)




Q: GDG のオーガナイザーをしているのはなぜですか?
京都やその近郊の人達が楽しんで集える場を作ることや、世界の GDG のオーガナイザーと知り合えたり協働できることが楽しいからです。

Q: 意味や影響が大きかったとご自身が感じる、GDG にまつわる体験談を共有してください。 
2013 年に GDG DevFest W を開催した際に、同じ開催日であるロシアの GDG Omsk とハングアウトで接続して、コミュニケーションを取ったことがあります。それがきっかけで、ロシアの DevFest へのスピーカーのお誘いが日本の GDG 宛にきたり、GDG Omsk を通じてロシアの開発者の方が作った Chrome Extention の日本語化対応のお手伝いを GDG 京都で行うなどのやり取りがありました。GDG 京都は、他にも海外の GDG との交流があり、DevFestWomen Techmakers などのイベントに海外の GDG オーガナイザーが講演者として協力してくれたこともありました。面識がなくても、京都に旅行で訪れた際に GDG オーガナイザーが声をかけてくれ交流する機会もあります。グローバルなコミュニティならではの体験だと思っています。

Q: あなたが開発者になりたいと思ったきっかけは何ですか?
私は開発者かどうかは怪しいですが、少なくとも技術コミュニィでアプリ開発を学ぶきっかけや、その師となる方があったからです。私の場合は、Flex User Group 大阪 (2007年) の参加がそのきっかけです。


石丸 健太郎さん(GDG 信州オーガナイザー)

Q: GDG のオーガナイザーをしているのはなぜですか?

2012 年に GDG 信州を立ち上げましたが、そのきっかけとなったエピソードがあります。都心では多くの勉強会が日々行われていますが、地方ではそう言った機会が少なく、いざ申し込もうと思ってもすぐに満席となり、あえなく断念なんてことも。そんな折、Hangout を使った中継で繋ぐことで Google I/O 報告会を行う機会があり、地方でも勉強会を開催できたことがコミュニティの始まりでした。

Q: 意味や影響が大きかったとご自身が感じる、GDG にまつわる体験談を共有してください。
今年で設立 5 年が過ぎイベント数も 30 を超え、ここ数年はプログラミングコンテストにコミュニティとして参加しています。いつか決勝戦まで残れる作品を輩出するのが目標です。また、GDG 信州の特徴と言えるのですが、勉強会のたびに自作を含めたガジェットが多く集められ品評会状態になります。それが高じて、一昨年末の Google HackFair に 2 作品も呼んでいただくことができました。こうしてコミュニティが一体となって活動できていることに価値があると思ってます。




齊藤 真那 さん(GDG 石巻 メンバー)

Q: 開発者になりたいと思ったきっかけは何ですか?
自分の好きなスマホアプリやゲームを自分で開発してみたかったから。

Q: GDG にまつわる体験談を共有してください。 
東北 TECH 道場に参加していなければ、自分でアプリを開発しようとは思わなかったと感じています。アプリ開発から発展してウェブ開発にも挑戦しているので、プログラミングに触れる機会を与えてくれたことに感謝しています。


パソナテック 夏谷さん(GDG 神戸メンバー)

Q: 開発者になりたいと思ったきっかけは何ですか?
Deep Learningを使って従来の画像処理を置き換え、その技術を用いて地方の活性化を雇用を生み出したいと思ったから。

Q: GDG にまつわる体験談を共有してください。
Google 社員の佐藤さんによる Tensorflow の紹介がとても興味深く、自分自身が使ってみるきっかけになりました。

Q: Google が果たした役割は何でしょうか?
Google の Machine Learning への取り組みが自分たちの指標となり、弊社での大規模イベント「なにわテック」を開催するきっかけとなりました。


Google は今後も、コミュニティの皆さんとともに、デベロッパーに役立つ場を提供していきたいと考えています。GDG に興味のある方は、お近くの GDG のイベントに参加してみてください。


各 GDG のページはこちら

Posted by Takuo Suzuki - Developer Relations Team