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

Google Play における報酬に基づく評価、レビュー、インストールに関するポリシー

June 21, 2017, 8:37 pm
$
0
0
この記事は スパム対策ニンジャ、Kazushi Nagayama、ポリシー スペシャリスト、Bryan Woodward による Android Developers Blog の記事 "Google Play’s policy on incentivized ratings, reviews, and installs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。　
　
Google Play の信頼性と安全性の確保は、Google の最優先事項の 1 つです。先日は、スパム インストールや偽の評価やレビューへの対抗策の強化についてお知らせしました。こういった発表をさらに強調し、明確化するために、報酬に基づく評価、レビュー、インストールに関するデベロッパー プログラム ポリシーをアップデートしました。 　
　
デベロッパーは、いかなるアプリについても、ストア内の配置を操作しようとしてはいけません。これには、詐欺や報酬によるインストールやレビュー、評価などの不正な手段を用いた製品の評価やレビュー、インストール数のつり上げが含まれますが、それに限定されません。

　

報酬に基づく操作の定義


ユーザーが評価、レビュー、インストールの操作を、金銭、物品、あるいはそれと同等のものと引き替えに行った場合、それは報酬に基づくものと見なされます。報酬に基づく評価やレビューは例外なくポリシー違反です。Google は、ストアの統一性を維持するため、対策をとり続けます。Google Play のアプリの配置を変えることを意図したインストールは、検知されて除外されます。 　

ユーザー獲得手段としての報酬に基づくインストール


報酬に基づくインストールは、Google Play アプリの配置を操作するためだけに行われている場合もあります。この場合、ポリシー違反になります。ただし、一部のデベロッパーは、報酬に基づくインストールを正式なユーザー獲得チャンネルとして利用しています。この 2 つの異なるユースケースを判別するため、次のようなアプローチを採用しています。 　
  • 報酬に基づくインストールをユーザー獲得チャンネルの 1 つとして利用しただけでは、ストアからアプリが自動的に削除されることはありません。ただし、ストアの統一性を損なうような行動は監視されており、そのような行動には対策がとられます。
  • Google がアプリの配置を操作しようとした行動であると判断した場合、それに対処するため、報酬に基づくインストールをシステムで監視して除外します。トップチャートから削除されることもあります。削除すべき根拠がある場合、アプリがストアから削除されることもあります。

このアプローチを通して、Google Play でアプリを探すトップチャートなどの仕組みが、実際のアプリの人気を反映したものになることを期待しています。 　
　
原則として、報酬に基づくアクションを利用しないことをおすすめします。報酬によるユーザーは、他の獲得チャンネルによるユーザーとはまったく異なります。Google リサーチチームによる内部分析では、報酬によるユーザーは有償または有機的な獲得チャンネルによるユーザーよりも維持率が低く、アプリ内購入額も少なくなっています。 　
　
Google Play ポリシーについての詳細は、デベロッパー ポリシー センターをご覧ください。Google Play で成功するためのおすすめやベスト プラクティスは、Android デベロッパー ウェブサイトをご覧ください。 　
このブログ投稿はどのくらい役に立ちましたか？
★★★★★

Reviewed by Yoshifumi Yamaguchi - Developer Relations Team
↧
Search

AMP 圧縮のアップデート

June 22, 2017, 7:14 pm
$
0
0
この記事は ソフトウェア エンジニア、Zachary Nado による Google Developers Blog の記事 "AMP Compression Update" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

先日、Google AMP Cache に Brotli 圧縮が追加されたことをお知らせしました。Google AMP Cache から提供されるすべての AMP ドキュメントを Brotli 圧縮できるようになりました。これによって、ユーザーは帯域幅をかなり節約でき、モバイル体験の向上という目的にまた一歩近づきます。

Brotliは、Jyrki Alakuijala 氏と Zoltán Szabadka 氏が Google Research Europe の圧縮チームとともに作成した新しい効率的な圧縮アルゴリズムです。2015 年にリリースされて以来、Google の他の領域でもかなりの効率化に貢献しています。Brotli は汎用的な圧縮アルゴリズムですが、ウェブ ドキュメントでは特に効果が見込まれます。gzip の代わりに Brotli を利用すると、ドキュメントのサイズが平均で約 10% 小さくなります。Google AMP Cache では、1 日あたり数百ギガバイトの帯域幅が節約できます。

ドキュメントのサイズが小さくなると、ページの読み込みが早くなるだけでなく、データ量が限られたプランのユーザーは帯域幅を大幅に節約できます。しかし、Google AMP Cache はまだ始まりにすぎません。エンジニアリング チームは他のさまざまな製品で Brotli をサポートする作業を続けています。それによって、Google 全体にわたる帯域幅の節約が実現します。


Reviewed by Yoshifumi Yamaguchi - Developer Relations Team
↧
↧

Cloud Functions を使って Firebase Hosting から動的コンテンツを提供する

June 25, 2017, 7:46 pm
$
0
0
この記事は Firebase Hosting エンジニア、Michael Bleigh による The Firebase Blog の記事 "Serving dynamic content with Cloud Functions on Firebase Hosting" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


3 年前、Firebase Hosting がリリースされ、デベロッパーが高速で魅力的なウェブ コンテンツをより簡単に提供できるようになりました。2 か月前には、Cloud Functions for Firebase のベータ版がリリースされ、デベロッパーがサーバーやインフラについて心配せずに、カスタム バックエンド ロジックを記述できるようになりました。先日の Google I/O では、Firebase Hosting と Cloud Functions を組み合わせて、世界規模の拡張性とパフォーマンスを備えた Progressive Web Apps を作成できる柔軟なツールセットとして使う方法を紹介しました。

プロジェクトの firebase.json設定ファイルに rewrite を追加すると、HTTPS Cloud Function を Firebase Hosting アプリに接続できます。 
{
  "hosting": {
    "rewrites": [
      {"source": "/function/**", "function":"myFunction"}
    ]
  }
}

接続後は、一致するリクエストがスムーズに Cloud Function に渡されます（上記の例では、myFunctionという名前の機能が呼ばれます）。このわずか 1 行の変更だけで、Firebase Hosting ユーザーは以下のようなすばらしい新機能を使えるようになります。
  1. サーバーサイド レンダリング: 今までは、Firebase Hosting は静的なコンテンツしか提供できませんでしたが、Expressなどの業界標準ライブラリを使ってダイナミック コンテンツを提供できるようになります。超高速なグローバル CDN キャッシュが活用できる点は変わりません。
  2. カスタム API: Cloud Functions と Firebase Hosting を組み合わせると、独自のドメインにカスタム API エンドポイントを作成して、クロスオリジン リクエストの負荷を避けることができます。さらに、数行のコードを追加すると、Firebase Auth でエンドポイントを認証することもできます。
  3. ユーザー生成ウェブ コンテンツ: Firebase Hosting で初めてデプロイ不要で AMP、Twitter Cardsなどに対応したコンテンツを生成できるようになりました。これで、Firebase Hosting アプリはこれまで以上にコンテンツ共有や検索が容易になります。

Cloud Functions ユーザーは、SSL で保護されたカスタム ドメインで機能を実行できるようになり、不必要な実行を防ぐ強力なキャッシュも利用できます。

ご自分の Firebase プロジェクトの Firebase Hosting で Cloud Functions を使う方法については、ドキュメントをご覧ください。I/O セッション「Firebase Hosting で高速なウェブ体験を開発する」もご覧ください。

Reviewed by Khanh LeViet - Developer Relations Team
↧

動画: パート 1 — デベロッパーの皆さんに向けた Team Drives のご紹介

June 26, 2017, 6:55 pm
$
0
0
この記事は Google Drive プロダクト マネージャー、Hodie Meyers、G Suite デベロッパー アドボケート、Wesley Chun（@wescpy）による Google Apps Developer Blog の記事 "VIDEO: Part 1—Introducing Team Drives for developers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

エンタープライズ企業は常に効率化の方法を模索していますが、デベロッパーに正しいツールを用意することで違いを生みだすことができます。Google は今年、Team Drives をリリースしました。これは、Google Drive でユーザーに好評だった機能を企業のチームにも提供するものです。さらに、デベロッパーが Team Drives を活用したアプリを開発できるよう、Google Drive API もアップデートしました。

この最新の G Suite Dev Show 動画では、アプリで Team Drives の機能を活用する方法について説明しています。うれしいことに、まったく新しい API を学習する必要はありません。Team Drives の機能は Drive API に組み込まれているため、これまでに身につけた知識を使って開発できます。どうぞご覧ください。

この動画を最後まで見ていただければ、Team Drives の機能をアプリに組み込む際の次のような基本操作について理解できるでしょう。
  1. Team Drives の作成方法 
  2. Team Drives にメンバーやユーザーを追加する方法 
  3. Team Drives でフォルダを作成する方法（通常の Drive フォルダと同様） 
  4. Team Drives フォルダにファイルをアップロードまたはインポートする方法（通常のフォルダへのファイルのアップロードと同様） 
Drive API は、さまざまなデベロッパーが Google Drive と Team Drives の両方と連携するソリューションを作成するために役立ちます。独立ソフトウェア ベンダー（ISV）の方でも、システム インテグレーター（SI）や IT 従事者の方でも、生産性向上、企業の G Suite への移行サポート、ワークフローを自動化するツールの開発など、さまざまな用途に Drive API を利用できます。

Team Drives 機能では、Drive API v2 と v3 の両方を利用できます。さらに詳しい説明は、Drive API ドキュメントをご覧ください。皆さんが Team Drives を使って作るアプリを楽しみにしています。


Reviewed by Eiji Kitamura - Developer Relations Team
↧

Dynamic Links をさらに簡単に

June 26, 2017, 8:11 pm
$
0
0
この記事は プロダクト マネージャー 、Jumana Al Hashal  による The Firebase Blog の記事 "Making Dynamic Links Easier" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Firebase Dynamic Links は便利なリンクシステムです。1 つだけのリンクで、インストール済みの iOS や Android アプリを開き、ディープリンクを使用し、ユーザーが探しているコンテンツを直接にアプリ内で表示することができます。アプリがインストールされていない場合にも、同じリンクで App Store や Google Play のアプリのページからアプリ内のコンテンツまで案内することができます。

私たちは 1 年前からこの機能を改善し、よりスムーズでよりパワフルな体験をデベロッパー、ユーザーの両方に届けられるよう努力してきました。今回、最新の機能を iOS SDK と Android SDK に届けることができたことを嬉しく思います。

Dynamic Links をダイナミックに生成する


今まで、Dynamic Links を生成するには Firebase コンソールからアクセスする必要がありました。広告、宣伝などのキャンペーンの目的では十分でしたが、デベロッパーの皆さまからは、ユーザー同士で共有できるキャンペーンなどを対応するために、アプリからリンクを作成できるようにしたいというフィードバックを多数いただいていました。

そのため、iOS と Android の Firebase SDK に、ロングとショートの Dynamic Link を生成する機能を追加しました。

iOS:

guard let deepLink = URL(string: "https://mydomain.com/page?param=value") else { return }

let components = DynamicLinkComponents(link: deepLink, domain: domain)

let iOSParams = DynamicLinkIOSParameters(bundleID: bundleID)
iOSParams.minimumAppVersion = minVersion
components.iOSParameters = iOSParams

// ダイナミック リンクを生成する
let link = components.url

// またはショート リンクを生成する
components.shorten { (shortURL, warnings, error) in
      if let error = error {
        print(error.localizedDescription)
        return
      }

    // TODO: shortURL を使用する
    }

Android:

String deepLink = "https://mydomain.com/page?param=value";

DynamicLink.Builder builder = FirebaseDynamicLinks.getInstance()
        .createDynamicLink()
        .setDynamicLinkDomain(domain)
        .setAndroidParameters(new DynamicLink.AndroidParameters.Builder()
                .setMinimumVersion(minVersion)
                .build())
        .setLink(deepLink);

// ダイナミック リンクを生成する
DynamicLink link = builder.buildDynamicLink();

// またはショート リンクを生成する
builder.buildShortDynamicLink()
        .addOnSuccessListener(new OnSuccessListener() {
            @Override
            public void onSuccess(ShortDynamicLink shortDynamicLink) {
                // shortDynamicLink を使用する
            }
        });

新しい Android API

アプリから Dynamic Links を実装しやすくするために Android API を考え直して、新たに FirebaseDynamicLinksというクラスを追加しました。このクラスを利用するには build.gradleファイルに新しく提供したライブラリーを追加していただけます。

compile "com.google.firebase:firebase-dynamic-links:11.0.0"

これだけで起動されたアクティビティから Dynamic Link を処理することは簡単です。

FirebaseDynamicLinks.getInstance().getDynamicLink(getIntent())
  .addOnSuccessListener(
    new OnSuccessListener() {
      @Override
      public void onSuccess(PendingDynamicLinkData data) {
      if (data == null || data.getLink() == null) {
        // FDL は特にない。何もする必要がない
        return;
      }

      Intent launchIntent = data.getUpdateAppIntent(MainActivity.this);
      if (launchIntent != null) {
        startActivity(launchIntent); // アップグレード フローを起動する
      }

     Uri deepLink = dynamicLink.getLink();
     String myAppItemId = deepLink.getQueryParameter("myAppItemId");
     // TODO: myAppItemId のコンテンツを表示する
    }
});

新しい API に関するご質問やフィードバックがあった場合は、サポートページをご確認ください。


Reviewed by Oscar Rodríguez - Developer Relations Team
↧
↧

全プラットフォーム対応の Google マップ URL でユーザーを自在にナビゲーション

June 27, 2017, 8:12 pm
$
0
0
この記事は Google Maps API プロダクト マネージャー、Joel Kalmanowicz による Google Geo Developers Blog の記事 "Get your users where they need to go on any platform with Google Maps URLs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google I/O 2017 でご紹介した「Google Maps URL」は、任意のアプリから Google マップに直接リンクすることができる新たな方法です。毎月 10 億人以上のユーザーが Google マップのアプリやサイトを利用して世界中の情報にアクセスしています。今回発表した仕組みによって、任意のアプリやサイトから Google マップを簡単に活用することができます。


URL を利用する理由

ユーザーが何か目的を達成したいときに、地図が重要なことがあります。しかし、地図がアプリやサイトの中で重要なサービスではないこともあります。特定の場所を示すなど、ユーザーが移動する際の手助けになれば十分というときもあるでしょう。買い物をするために皆さんのもとに訪れようとしているお客様が付近の店舗を探したい場合や、他のユーザーとどこで待ち合わせするかを決めようとしている場合ということもあるでしょう。こうした状況に、Google マップは簡単に対応することができます。

Google Maps URL を使うことによって、 Google マップにリンクし、必要とする機能を自動的に呼び出すことができます。この Google Maps URL は新しい機能というわけではありません。あるプラットフォームでは、ブラウザの URL をコピーすることで動作することに気づいている方もいることでしょう。Android のアクティビティの起動を司るインテントや iOS の URL スキームも利用できます。しかし、これはネイティブ プラットフォームでしか動作しません。デベロッパーの作業も増えますし、マルチユーザー機能は同じプラットフォームのユーザーに制限されます。

クロスプラットフォーム

そこで必要になるのが、Android、iOS、ウェブのすべてをサポートするクロスプラットフォームのユニバーサル URL スキームです。たとえば、メッセージング アプリのユーザーは、メッセージの受信者が Android か iOS かを気にすること無く、友人と会う場所を共有したいはずです。同様に、デベロッパーも同じ機能を 2 つの異なるライブラリで再実装したいとは思わないはずです。

Google Maps URL を開くと、ユーザーの端末の種類に関わらず、インストールされている Google マップのアプリがそれを処理することになります。Android や iOS の Google マップが利用できる場合、それが開きます。そうでない場合は、ブラウザで Google マップが開きます。

利用は簡単

この機能は簡単に利用できます。実施したいことに沿って、URL のいくつかの値を置き換えるだけなので、プログラムで URL を作成するのも簡単です。いくつか例を示します。

予約した宿泊先へ行く方法を知りたい場合や、近隣の飲食店を探したい場合は、次のようにURLを定義します。
https://www.google.com/maps/search/?api=1&query=sushi+near+94043
queryパラメータにクエリを指定します。ここでは特定の場所を指定していますが、場所を指定しない場合は、リンクをクリックしたユーザーの近くの場所で探します。ここをクリックすると近くの寿司店を探すことができますので、お試しください。

次のリンクは先ほどのクエリに似ていますが、 1 つの結果だけを返し、ページに追加情報が表示されます。
google.com/maps/search/?api=1&query=shoreline+amphitheatre
apiパラメータ（必須）には、使用する Google Maps URL のバージョンを指定します。現在リリースされているバージョンは 1 です。


フィットネス アプリを設定したユーザーが自転車で新しいルートを走ってみたい場合は、次のようにします。
www.google.com/maps/dir/?api=1&destination=stevens+creek+trail&travelmode=bicycling&dir_action=navigate
ここでは、travelmode（移動モード）に bicycling（自転車）を、destination（行き先）に自転車専用道路を指定します。

また、実際にどんな場所かを確かめるために、直接ストリート ビューを開くこともできます。
www.google.com/maps/@?api=1&map_action=pano&viewpoint=36.0665,-112.0906&heading=85&pitch=10&fov=75
viewpoint（視点）パラメータには、表示したい場所の緯度経度を指定します。また、heading（方角）、pitch（上下の角度）、fov（視野角）パラメータで見る方向を指定します。

機能の詳細

Google Maps URL を活用すると、Google マップで何らかのタスクを実行するユーザーをサポートできます。しかし、もっと柔軟な対応が必要な場合や、カスタマイズや制御が必要な場合には、さらに強力な Google Maps APIを活用して、Google マップをアプリやサイトに組み込む方法をおすすめします。API が提供する豊富な機能を使うことによって、カメラの制御、マップへの図形の描画、マップのスタイル設定などのさまざまな機能にアクセスできます。さらに、マップだけでなく、場所のメタデータやイメージなどを活用することもできます。

詳しい情報は

皆さんのニーズを満たすため、Google マップを使ったアプリで大変な作業を簡単に済ませたいという方は、ぜひ Google Maps URL をお使いください。詳細は、新しいドキュメントをご覧ください。

Google Maps URL と Google Maps APIs を利用していただき、ありがとうございます！フィードバックや問題点は、Issue Trackerで共有してください。


Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Customer Engineer Lead, Japan and APAC
↧

Actions on Google から SDK へ、Google Assistant の開発が簡単に

June 28, 2017, 6:56 pm
$
0
0
この記事は Google Assistant プロダクト マネージャー、Brad Abrams による Google Developers Blog の記事 "From Actions on Google to the SDK, the Google Assistant is getting better for developers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2016 年 12 月に、Google Home 向け Actions on Google デベロッパー プラットフォームのアーリーアクセス版を発表しました。それ以来、ユーザーを増やし、このプラットフォームの機能やデベロッパー エクスペリエンスを向上させることに重点的に取り組んできました。本日（*原文公開当時）、本プラットフォームがスマートフォンに対応し、新機能が追加されて SDK が強化されたことをお知らせします。あらゆる場所にいる Google Assistant ユーザー向けにすばらしいアプリを作成するため、私たちは今後も皆さんと協力してゆきます。

スマートフォン向け Actions on Google の導入


2016 年 12 月に Actions on Google プラットフォームがリリースされてから、Google Home では創造性あふれる楽しいアプリが生まれています。たとえば、FitStarでフィットネスを行ったり、CNBCで最新ニュースを取得したりするものがあります。そしてこのたび、Android スマートフォンと iPhone の両方の Assistant で Actions on Google が利用できるようになりました。


スマートフォンでも Assistant アプリが利用できるようになるので、ユーザーベースの拡大や、まったく新しいユースケースのアプリの構築も可能です。膨大なメニューの中から衣料品を購入する、食料品を注文するといった操作は、音声のみのインターフェースに適したものではないからです。さらに、画面が使えるようになることで、アプリでイメージ カルーセル、リスト、サジェスチョン表示などの新しい UI 要素を簡単に使えるようにもなります。


Assistant 向けスマートフォン アプリは、構築やデプロイが可能になっています。ドキュメントはこちらです。


イギリスでは、近日中に英語の Actions on Google がリリースされる予定です。フランス語、ドイツ語などの言語も今年中にリリースされる予定です。


取引と支払いへの対応

Assistant の目的は、皆さんのやりたいことをサポートすることです。それは、単に質問をしたり、情報を聞いたりすることにとどまりません。購入手続きも簡単に行えるようにしたいと考えています。

Google Assistant アプリで支払いを行うには、2 つのオプションがあります。1つ目のオプションは、無償で簡単に組み込むことができる Google ペイメントを使う事で、すでに Google に登録されている何億ものカードを活用できます。または、2つ目のオプションとしてユーザーがすでにアプリに登録している支払い方法も使うことができます。この 2 つ目のオプションを使う場合は、ユーザーがシームレスに決済ができるソリューションを構築する事を推奨します。


もちろん、取引はユーザーの支払いで終わるわけではありません。注文のトラッキングや変更、再注文などが必要になる場合もあります。そのため、Assistant では、単一の履歴ビューですべての取引を参照できるようになっています。さらに、リピート率向上のために、注文のアップデート機能も開発しています。この機能を使うと、迎えにきた車が到着したとき、食料品が配送されたとき、処方箋が準備できたときなどにステータスのアップデートを送信できます。


取引を行うアプリは、本日より作成やテストができるようになっています。スマートフォンの Google Assistant ユーザーも、近日中にこの機能を利用できるようになります。

ツールとアプリの見つけやすさの向上

以上のような新機能では、今まで以上に基本を理解することが重要になります。また、言うまでもなく、優れたツールや人目に触れやすくすることはもっとも重要です。


そこで、デベロッパー エクスペリエンスの向上のため、本日、新しいデベロッパー コンソールをリリースしました。このコンソールにより、デベロッパーがチームで作業し、アプリの使用状況、パフォーマンス、ユーザー検出パターンに基づくデータの収集ができるようになります。これは、Firebase コンソールと Google Cloud コンソールを統合して、アプリ内のデータを共有できるようにしたものです。


さらに、新たなアプリのディレクトリもリリースします。ユーザーは Google Assistant を 1 回タップするだけでこの機能にアクセスでき、カテゴリやユーザーの評価を確認できます。各アプリのディレクトリ ページはウェブでも共有できるので、新しいユーザーや既存のユーザーにアプリを宣伝したり、ユーザーが友だちと共有したりできます。


今回のアップデートによって、ユーザーはアプリのショートカットを作成できるようになります。そのため、ユーザーは「OK Google、Forecaster Joe にアウターバンクスの波の様子を聞いてくれ」と言わなくても、たとえば「OK Google、波は来てるかい？」とパーソナル ショートカットを声に出すだけで簡単にアプリに戻ることができます。


こういった機能によって確かにユーザーはアプリを見つけやすくなるはずですが、私たちの仕事はこれで終わりではありません。今後も、さらに新機能を追加し、アプリを見つけやすくしてゆく予定です。

Assistant SDK のアップデート

先月、Google Assistant SDK のプレビュー版を紹介しました。これは現在も改善が続けられており、たくさんの新機能が追加されています。


ホットワードがサポートされたので、デベロッパーはボタンなどの物理的な操作ではなく、「OK Google」をトリガーとする端末を構築できるようになります。また、タイマーとアラームの機能も追加されているので、ビルトインで Google Assistant が組み込まれている端末に「OK Google、60 秒のタイマーを設定してくれ」と言うことができるようになります。


この SDK とプラットフォームは生まれて間もないものですが、今まで以上に包括的なデベロッパー エクスペリエンスを提供できるように作業を続けています。また、Google Assistant SDK を搭載したものも含め、新しい端末にこのプラットフォームを提供することも検討中です。



新しいデベロッパー コンテストのお知らせ

最後に重要なお知らせです。初めての Actions on Google デベロッパー コンテストが開催されることになりました。このコンテストでは、優秀な Google Assistant アプリに 20 以上の賞が贈られる予定です。早速開発を始めましょう。皆さんのアプリを見るのが待ちきれません。


今後も、皆さんとともに新しい Google Assistant アプリを開発できることを楽しみにしています。


Reviewed by Takuo Suzuki - Developer Relations Team
↧

インターネットを早く安全に: reCAPTCHA Android API のご紹介

June 28, 2017, 6:55 pm
$
0
0
この記事は プロダクト マネージャー、Wei Liu による Android Developers Blog の記事 "Making the Internet safer and faster: Introducing reCAPTCHA Android API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

10 年前に reCAPTCHA がリリースされたとき、その目的はシンプルなものでした。その目的とは、スパムや不正使用の心配をせずに、ユーザーが好きなサイトにアクセスできるようにすることです。長い年月を経て reCAPTCHA は大きな変化を遂げ、ゆがんだテキストから住所の番地や名前へ、そして 2014 年の No CAPTCHA reCAPTCHA、今年 3 月の Invisible reCAPTCHA へと進化しています。

現在までに、10 億以上のユーザーが reCAPTCHA のメリットを受けています。私たちはこの保護の改善に引き続き取り組んでゆきます。

reCAPTCHA は、あらゆる場所にいるオンラインのユーザーを保護します。モバイル端末の利用が急速に拡大する中で重要になるのは、モバイルアプリとそのデータを安全に保つことです。reCAPTCHA が 10 歳の誕生日を迎える本日、最初の reCAPTCHA Android APIが Google Play Services の一部としてリリースされたことをお知らせします。

この API を使うと、reCAPTCHA による人間とボットの区別の精度が上がり、モバイル ユーザーの操作性を向上させることができます。これは最新の Invisible reCAPTCHA テクノロジーを利用したもので、裏でリスク分析を行うことによって、ほとんどの人間のユーザーはクリックなしで通過できるようになっています。そのため、モバイル ユーザーは中断されることなくアプリを楽しむことができます。スパムや不正使用に悩まされることがない点は変わりません。

reCAPTCHA Android API は、モバイルアプリを保護する端末認証、セーフ ブラウジングなどのサービスを提供する Google SafetyNetの一部です。モバイル デベロッパーは、同じ API で端末とユーザーの両方を認証できるので、さらに効率的にアプリのセキュリティ リスクを低減できます。また、Android のセキュリティ保護の多様性も向上し、有害な可能性があるアプリを監視する Google Play Protect、端末の暗号化、通常のセキュリティ アップデートにこの機能が加わることになります。reCAPTCHA Android API を組み込む方法については、こちらのサイトをご覧ください。また、iOS 版のライブラリにもご期待ください。

reCAPTCHA の旅はまだ続きます。私たちは、（ボットを除く）誰もがインターネットを安全かつ簡単に使えるようにすることに取り組んでゆきます。



Reviewed by Takeshi Hagikura - Developer Relations Team
↧
Search

Chrome 60 ベータ版：Paint Timing API、CSS font-display、Credential Management API の改善

June 28, 2017, 7:54 pm
$
0
0
この記事は Paint Timing Promoter、Shubhie Panicker による Chromium Blog の記事 "Chrome 60 Beta: Paint Timing API, CSS font-display, and Credential Management API improvements" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

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

Paint Timing API
汎用的な指標では、ページを読み込む瞬間をあらゆるケースにおいて的確に記録することはできません。一方、First Paint と First Contentful Paintは、ユーザーにとって重要な読み込み中の瞬間を測定できるため、非常に有益な値です。新しい Paint Timing APIでは、この First Paint と First Contentful Paint を取得するための指標が公開されています。これにより、デベロッパーは自身のサイトの読み込みパフォーマンスをより詳しく把握できます。

Screen Shot 2017-06-08 at 8.57.03 AM.png
Google.com における First Paint と First Contentful Paint の瞬間の画像。Google I/O 2017 の「Web Performance:Leveraging the Metrics that Most Affect User Experience」より引用


CSS font-display
ダウンロード可能なウェブフォントは、より視覚的にリッチなウェブ エクスペリエンスを実現するためによく利用されます。従来の Chrome では、きれいに整った画面を確実に表示するために、指定のフォントが利用可能になるまでテキストのレンダリングを遅らせていました。しかし、通信速度が遅いとフォントをダウンロードするのに何秒もかかることがあるため、ユーザーにコンテンツが表示されるまでの時間に大幅な遅延が生じてしまいます。Chrome では現在、CSS の @font-faceディスクリプタと、対応する font-displayプロパティをサポートしています。これにより、デベロッパーはフォントのダウンロード中に、Chrome でテキスト コンテンツを表示する方法とタイミングを指定することができます。

Credential Management API の改善
デベロッパーのみなさまからのフィードバックを受け、Credential Management API をすべてのサイトで利用しやすいものに改善し、保存済みパスワードにアクセスするためのカスタム fetch()を廃止しました。Chrome 60 以降、ユーザーのパスワードは PasswordCredentialの一部として直接返されるようになります。

さらに、Web Authentication Working Groupの取り組みに合わせ、一連の変更を加えました。たとえば、requireUserMediationを廃止し、preventSilentAccessに名称変更しています。


今回のリリースに追加されたその他の機能
  • Payment Request APIがデスクトップ版の Chrome でサポートされるようになりました。 
  • Payment Request API を使用することにより、支払い機能を備えたネイティブ Android アプリで サイト上での支払い処理が行えるようになりました。 
  • オブジェクトの rest および spread プロパティが新たにサポートされ、オブジェクトの統合やシャロー クローン、さまざまな変更不能なオブジェクト パターンの作成がより簡単にできるようになりました。 
  • 新しい Web Budget APIによって、プッシュ通知のパーミッションを持つサイトで有限のプッシュ メッセージを送信できるようになりました。これにより、ユーザーに通知を表示しなくても、データの同期やユーザーが他のデバイスで操作した通知の削除などのバックグラウンド処理をトリガーできます。 
  • 新しい Web Push 暗号化フォーマットがサポート対象になりました。使用可能な箇所は、PushManager.supportedContentEncodingsで検出できます。 
  • PushSubscription.expirationTimeが利用可能になり、定期購入の期限が切れる場合はその時期についてサイトに通知されるようになりました。 
  • パフォーマンスと予測可能性を向上させるため、scrollと TouchEventsの既存機能に合わせて、pointermoveイベントと mousemoveイベントが AnimationFrameごとに 1 回発行されるようになりました。 
  • CSS 疑似クラスの :focus-withinが利用可能になりました。これは :focus疑似クラスが影響を与えるあらゆる要素、および :focusの影響を受ける子孫を持つあらゆる要素に影響を与えます。 
  • CSS フレーム タイミング関数が利用可能になりました。最初から最後まですべてのフレームをまったく同じ時間表示するアニメーションにおいて、アニメーションをループさせる際に役立ちます。 
  • 編集アクションの検出方法が改良されました。InputEventによってユーザー入力をスクリプトで管理できるようになり、さらに充実した詳細情報が編集可能な要素に提供されます。 
  • セキュリティ向上のため、ユーザーがサイトを離れる際にトリガーされる BeforeUnloadダイアログは、その表示を試みるフレームがユーザーの操作やインタラクションを取得したことがある場合にのみ表示されるようになりした。ただし、これとは別に BeforeUnloadEventは引き続きディスパッチされます。 
  • ロイヤリティ フリーのオープンな動画コーディング フォーマットである VP9 が、MP4（ISO BMFF）コンテナと一緒に使用できるようになり、以下の新しい VP9 文字列フォーマットが必要になりました。 
  • 新しい VP9 文字列フォーマットが利用可能になり、さまざまなメディア関連 APIで受け付けられるようになりました。そのため、デベロッパーは動画コーデックとしては一般的であるものの未公開のエンコード プロパティを記述することができます。

サポートの終了と相互運用性の改善
  • getElementsByTagName()は、DOM 仕様のアップデートに伴い、修飾名を受け付けるようになりました。 
  • /deep/は、事実上は操作不能な子孫コンビネータとして動作するようになりました。 
  • ユーザー エクスペリエンスの向上のため、Navigator.vibrate()を呼び出すと、ユーザーがフレームまたは組み込まれたフレームを明示的にタップしていない場合は、即座に falseが返されるようになりました。これは既存のクロスオリジン iframeの動作と一致しています。 
  • WEBKIT_KEYFRAME_RULEと WEBKIT_KEYFRAMES_RULEは削除され、接頭辞のない標準 API、KEYFRAME_RULE、KEYFRAMES_RULEに置き換えられました。 
  • 非標準の WebKitAnimationEventと WebKitTransitionEventは、document.createEvent()のサポート対象外になりました。 
  • 仕様に準拠するため、NodeIterator.filterと TreeWalker.filterは JavaScript オブジェクトをラップしなくなりました。また、.prototypeが window.NodeFilterから削除されました。 
  • RTCPeerConnection.getStreamById()が削除されました。代わりに polyfillを使用することをお勧めします。 
  • SVGPathElement.getPathSegAtLength()は SVGPathElement仕様から削除されたため、サポートを終了しました。 
  • Headers.prototype.getAll()は仕様から削除されたため、Fetch APIから削除されました。 


↧
↧

Google マップと Particle の連携で IoT 端末に位置認識機能を導入

June 29, 2017, 6:55 pm
$
0
0
この記事は Google Maps API のソリューション アーキテクト、Ken Nevarez による Google Geo Developers Blog の記事 "Google Maps and Particle partner to bring location-aware capabilities to IoT devices" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年、「IoT を容易にする Particle と GCP」でも紹介した IoT プラットフォームの Particle と Google Maps APIs を組み合わせることによって、GPS を使わずに IoT 端末で位置情報を容易に検出できるようになりました。たった 1 行のコードを書き加えるだけで、ネットワーク上に分散する端末やセンサー（IoT エッジデバイス）からGoogle Maps Geolocation APIを使用して Wi-Fi や携帯電話の基地局に関する Google の地理空間データベースにアクセスできるようになります。

IoT 端末やセンサーの位置情報を把握するために、高価で消費電力の大きな GPS モジュールはもはや必要ありません。既存の GPS システムと Google Maps APIs を一緒に活用することで、精度の高い位置情報を得ることが可能となり、屋内など GPS が働かない場合でも位置情報を把握することができます。

現在 Particle と Google では、収集したデータを Google Cloud Platform に送信する一連の流れをサポートしています。IoT センサーは自身の位置情報を検知すると、関連データを収集して返します。Google Cloud Platformにこうしたデータを蓄え、堅牢なクラウド上で利用することができます。

従来のアセット トラッキングは GPS などをベースに構築されていますが、GPS は過密な都市エリアや室内では利用できないことがしばしばあります。これは、GPS 信号が高層ビルや屋根によって遮断されてしまうためです。一方 Geolocation API は、携帯電話の基地局や Wi-Fi の信号をベースにするので、GPS が無効な場合でも位置の検出が可能です。そのため、屋内外を問わず、あらゆる場所のアセットのトラッキングが可能です。

IoT が主導する世界では、位置以外の情報も捉えることができます。こうした追加情報は、利用目的によって大変重要なものもあります。たとえば、冷凍品のサプライチェーンでは、「温度」に関する情報は工場、発送センター、輸送トラックにとって重要なデータの一つです。こうした情報によって、サプライチェーンの全体像を把握して、高品質の商品を配送することが可能になります。
Particle プラットフォーム上に構築されたWi-Fi 対応製品は、位置情報に基づいてその設定を自動化する機能も提供します。Geolocation API を使用することで位置情報に応じて、タイムゾーンの設定や、利用可能な周波数帯域の調整、地域ごとのサービス プロバイダへの接続などを自動的に行います。これにより、製品の設定作業はシームレスになり、操作性も向上し、有用な分析も可能になります。

たとえば、窓のブラインドの場合、位置情報をもとに日照時間のデータを参照して、その開閉を制御することで室内の温度を調整することができます。また、位置情報を送信する機能がついたコーヒー メーカーの場合、その位置情報から市場浸透率やターゲット層の詳細などマーケット分析に必要な情報を得ることもできます。

Particle 端末で位置情報を有効にする方法は、こちらのドキュメントを参照ください。必要な基本ステップは次の 4 つです。

  1. 位置情報に対して有効な Google Maps API キーを取得する
  2. Particle 端末に Google マップのファームウェアを書き込む
  3. Particle Console で Google Maps Integration を有効にする
  4. テストする

Google と Particle の詳細は、デベロッパー ドキュメントをご覧ください。


Reviewed by 丸山 智康 (Tomoyasu Maruyama) - Google Customer Engineer Lead, Japan and APAC
↧

Android および iOS 版 Blockly 1.0 のご紹介

June 29, 2017, 8:22 pm
$
0
0
この記事は Erik Pasternak とキッズ コーディング チームによる Google Developers Blog の記事 "Introducing Blockly 1.0 for Android and iOS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Blocklyはブロックベースのコーディング体験を提供するオープンソース ライブラリです。この 5 年間で、デベロッパーは Blockly を使って、Code.orgのような教育プラットフォームから、littleBitsのような電子工作キット、MIT App Inventorのような Android アプリ作成ツールまで、何百ものプロジェクトを生み出してきました。昨年には、Scratch チームと協力して Scratch Blocksを開発したこともお知らせしました。これは Blockly をソースをフォークして作られたもので、子供向けアプリのコーディングに最適化されています。

本日（*原文公開当時）は、Android と iOS で Blockly のリリース 1.0 が完成したことをお知らせします。Blockly 1.0 には、モバイルアプリでネイティブに Blockly を使うために必要な次のものがすべてがそろっています。
  • Blockly の標準 UI
  • カスタム ブロック、ツールボックス カテゴリ、レイアウト
  • 関数、変数、ミューテーター、エクステンション
  • JavaScript、Python、Dart、PHP、Lua コード生成
  • 国際化サポート（RTL 言語も含む）

本日の 1.0 へのアップデートは、ネイティブのモバイル環境を主眼に置いたものですが、ウェブ版のプロジェクトもここ半年でいくつかのアップデートが行われています。パフォーマンスとテストは大きく改善されており、構造的な API が追加され、モバイルウェブでのタッチ機能のサポートも改善されています。さらに、Internet Explorer と Edge のサポートも強化され、IE10 以上で Blockly が完全にサポートされています。

また、クロス プラットフォーム開発を容易にするために、さまざまな作業も行われています。ブロックはすべて JSON で定義できるようになったので、1 つのブロック定義をウェブ、iOS、Android で使い回すことができます。これら 3 つのプラットフォームの詳細については、ドキュメントをご覧ください。


iOS コードラボは、すぐにご利用いただけます（Android 版も近日中に提供予定）。Blockly の詳細については、上の紹介ビデオやデベロッパー サイトをご覧ください。また、メーリング リストにもご参加ください。ウェブ、Android、iOSのコードを直接参照することもできます。



Reviewed by Takuo Suzuki - Developer Relations Team
↧

Android Things Developer Preview 4.1

July 2, 2017, 8:49 pm
$
0
0
この記事は IoT デベロッパー アドボケート、Wayne Piekarski による Android Developers Blog の記事 "Android Things Developer Preview 4.1" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。　
　
先日、Android Thingsの Developer Preview 4.1（DP4.1）を新しくリリースしました。これには、サポート対象ハードウェアの追加や、プラットフォームのバグの修正を行うアップデートが含まれています。Android Things は、Android デベロッパーがモノのインターネット（IoT）端末を構築し、シームレスにプロトタイプから製品に展開できるようにするための Google 製プラットフォームです。 　
　

新たなハードウェア


Pico i.MX6UL リビジョン B ボードが新しくリリースされています。これは、Adafruit や Pimoroni などのパートナー製のさまざまな汎用外部機器をサポートしています。一部のアーリーベータ版テスターは Pico i.MX6UL ボードのプロトタイプを利用できましたが、これには DP4.1 との互換性はありません。 　
　

改善点


DP4.1 には、i.MX7D ベースのハードウェアの起動時間を短縮するブート時間の最適化など、DP4 以降に行われたいくつかのパフォーマンス改善が含まれています。今回の Developer Preview には、IoT 端末向けに最適化されたバージョンの Google Play Services も含まれています。この新たな IoT 向けバージョンはサイズが大幅に小さくなり、Android Things 用に最適化されています。これを使うには、build.gradle に play-services 11.0.0 以降を設定する必要があります。IoT 向けの Google Play Services でサポートされる機能の詳細については、インフォメーション ページをご覧ください。 　
　

Google I/O


今年の Google I/O では Android Things が大きく取り上げられ、デベロッパー向けに Android Things の異なる側面を紹介する 7 つのセッションが開催されました。参加できなかった方は、プレイリストから動画をご覧ください。 　
　
Google の IoT プラットフォームの新機能、Google のユビキタス コンピューティング



誰でもできる Android Things の端末作成




Android Things でプロトタイプから製品版まで




Android Studio を使った Android Things 開発




Android Things の IoT セキュリティ




Android Things で Google Cloud と TensorFlow を利用する




Android Things と Google Cloud Platform によるエンタープライズ IoT 開発

　
Google I/O では、参加者がガイドつきでじっくりと Android Things 開発を試すことができるコードラボ エリアも開設されました。コードラボは、どなたでも https://codelabs.developers.google.com/?cat=IoTからお試しいただけます。 　
　

フィードバック


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

TensorFlow Object Detection API でコンピュータ ビジョンモデルを強化する

July 3, 2017, 7:34 pm
$
0
0
この記事は 科学研究者、Jonathan Huang、ソフトウェア エンジニア、Vivek Rathod による Google Research Blog の記事 "Supercharge your Computer Vision models with the TensorFlow Object Detection API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。　
　
（Google オープンソース ブログにも投稿されています）　
　
Google では、画像認識向け柔軟な最新の機械学習（ML）システムを開発しています。これは Google の製品やサービスの改善だけでなく、研究コミュニティの発展にも活用されています。例えば 1 枚のイメージから複数の物体を正確に検出し位置を特定できる ML モデルの作成は、依然としてこの分野における重要な課題で、そうしたモデルの学習や実験に Google は多くの時間を費やしています。 　
　
Google のモデルの 1 つを使ってサンプル イメージ（COCOデータセットより）から検出した物体。イメージのクレジット: Michael Miley、元のイメージ

昨年 10 月、Google の物体検出システムはそれまでにない結果を出し、COCO の物体検出コンテストで第 1 位を獲得しました。その後、このシステムはさまざまな研究論文1,2,3,4,5,6,7でも結果を出し、NestCam、画像検索の類似アイテムとスタイルのアイデア機能、ストリートビューでの番地や名称の検出など、Google 製品でも活用されています。 　
　
そして今回、このシステムが TensorFlow Object Detection APIとして幅広い研究コミュニティで利用できるようになりました。このコードのベースとなるのは、TensorFlow上に構築されたオープンソース フレームワークです。これを使えば、物体検出モデルの構築や学習、導入が簡単になります。調査や研究のスピードアップと最新モデルのサポートを目的として開発されました。 　
　
今回のリリースには、以下が含まれています。 　
MobileNet を使う SSD モデルは軽量なので、モバイル端末でもリアルタイムで快適に動作します。一方、2016 年に COCO で優勝したモデルは、高速 RCNN モデルを組み合わせたものを利用していました。演算負荷が増大しますが、精度は大幅に向上します。これらのモデルのパフォーマンスの詳細については、CVPR 2017 の論文をご覧ください。 　
　
試してみたい方へ　
このコードは Google 社内の画像認識処理ですでに威力を発揮しており、皆さんのアプリケーションでも役立つはずです。また、皆さんからのコードの改善や機能追加は大歓迎です。今後のフレームワークのアップデートにもご期待ください。Object Detection API を試してみたい方は、こちらからコードをダウンロードして Jupyter Notebookを使い任意のイメージで物体を検出してみるか、Cloud ML エンジンでペット検出ツールをトレーニングしてみてください。 　
　
謝辞　
Tensorflow Object Detection API 、および学習済みの動物サンプルモデルをリリースできたのは、Google エンジニア間でのさまざまな共同作業や、製品開発チームからのフィードバックおよびテストのおかげです。特に、以下の方々の貢献に感謝いたします。 　
　
主な貢献者: Derek Chow、Chen Sun、Menglong Zhu、Matthew Tang、Anoop Korattikara、Alireza Fathi、Ian Fischer、Zbigniew Wojna、Yang Song、Sergio Guadarrama、Jasper Uijlings、Viacheslav Kovalevskyi、Kevin Murphy　
　
その他の協力者: Andrew Howard、Rahul Sukthankar、Vittorio Ferrari、Tom Duerig、Chuck Rosenberg、Hartwig Adam、Jing Jing Long、Victor Gomes、George Papandreou、Tyler Zhu　
　
参考文献　
  1. Speed/accuracy trade-offs for modern convolutional object detectors, Huang et al., CVPR 2017（本フレームワークについて説明した論文）
  2. Towards Accurate Multi-person Pose Estimation in the Wild, Papandreou et al., CVPR 2017
  3. YouTube-BoundingBoxes: A Large High-Precision Human-Annotated Data Set for Object Detection in Video, Real et al., CVPR 2017（ブログ投稿もご覧ください）
  4. Beyond Skip Connections: Top-Down Modulation for Object Detection, Shrivastava et al., arXiv preprint arXiv:1612.06851, 2016
  5. Spatially Adaptive Computation Time for Residual Networks, Figurnov et al., CVPR 2017
  6. AVA: A Video Dataset of Spatio-temporally Localized Atomic Visual Actions, Gu et al., arXiv preprint arXiv:1705.08421, 2017
  7. MobileNets: Efficient convolutional neural networks for mobile vision applications, Howard et al., arXiv preprint arXiv:1704.04861, 2017
　
　
Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud
↧
↧

Firebase Admin Java SDK によるユーザー管理

July 4, 2017, 7:38 pm
$
0
0
この記事は ソフトウェア エンジニア、Hiranya Jayathilaka による The Firebase Blog の記事 "Managing Users from the Firebase Admin Java SDK" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Firebase で開発したアプリのデベロッパーや管理者は、さまざまなユーザー管理タスクを実行しなければならないことがあります。たとえば、次のようなものがあげられます。
  • アプリへの新しいユーザー アカウントの登録
  • 既存のユーザー アカウントのアップデート
  • 手動でのユーザー アカウントの検証や有効化
  • ユーザー アカウントの無効化や削除
  • ダッシュボード構築やレポート作成に必要なユーザー プロフィール情報の参照

Firebase Admin SDKには、特権環境からこのようなユーザー管理タスクを実行するための強力な API があります。Admin SDK を使って、管理コンソールやダッシュボード、バックエンド サービスなどに上記の機能を直接組み込むためのプログラムを記述できます。Admin SDK は Firebase クライアント SDK とは異なり、サービス アカウントの認証情報を使って初期化します。これによって、SDK はユーザー管理操作を実行できる特権に昇格できます。

これは新しい機能ではありません。ユーザー管理 APIは Firebase Admin Node.js SDK でも提供されていますが、Admin Java SDK のバージョン 5.1.0 以降でもこの API が利用できるようになりました。これは、Admin Java SDK に対して最も多くリクエストが寄せられた機能の 1 つですから、多くの Firebase アプリのデベロッパーに活用していただけるはずです。

Java のユーザー管理 APIは、Node.js 版をほぼそのまま反映したもので、具体的には 5 つの新しいメソッドで構成されています。
  • getUser()
  • getUserByEmail()
  • createUser()
  • updateUser()
  • deleteUser()

次のコードは、これらの新しいメソッドを実際に使用する方法を示しています。この例では、既存のユーザー アカウントを受け取り、一部の属性を更新しています。 
final FirebaseAuth auth = FirebaseAuth.getInstance();
Task task = auth.getUserByEmail("editor@example.com")
    .addOnSuccessListener(userRecord -> {
      System.out.println("Successfully fetched user data: " + userRecord.getUid());
      UpdateRequest update = userRecord.updateRequest()
          .setDisabled(false)        // Enable the user account
          .setEmailVerified(true); // Set the email verification status
      auth.updateUser(update);
    })
    .addOnFailureListener(e -> {
      System.err.println("Error fetching user data: " + e.getMessage());
    });

Firebase ユーザー管理 API の詳細については、Admin SDK ドキュメントをご覧ください。また、実装方法も知りたい方は、Github レポジトリをご覧ください（ご想像どおり、これはすべてオープンソースです！）。フィードバックや問題の報告を通じて、この API の改善にご協力ください。いつものように、コードベースのプルリクエストなど、あらゆる種類の貢献をお待ちしています。ぜひ Firebase のコーディングをお楽しみください。


Reviewed by Khanh LeViet - Developer Relations Team
↧

技術ドキュメントの翻訳品質を向上させるイベント Glossari-a-thon Tokyo を開催します

July 5, 2017, 6:58 am
$
0
0

　

Google は、世界中のより多くのデベロッパーの皆さまに情報を届けることを重視し、さまざまな取り組みを行っています。その一環として技術ドキュメントを世界各地の言語に翻訳しており、最重要言語の１つとして多くのドキュメントを日本語に翻訳しています。

しかし、現実問題として、翻訳の質にはまだまだ課題が多くあります。 　
　
そこで今回、実験的な取り組みとして半日イベント「Glossari-a-thon」を開催することにいたしました。対象とするのは Android と Firebase のドキュメントです。参加者で手分けして、翻訳されたドキュメントをチェックし、問題点を洗い出すことが目的です。

技術ドキュメントの翻訳の質の向上に貢献したい方は、ぜひ参加し、この新たな取り組みをサポートしてください。 　
　
【開催概要】　
日時：2017 年 7 月 8 日（土）13:00 - 17:00（開場 12:30）
場所：六本木ヒルズ 森タワー Google 東京オフィス
主催：Google Inc.
対象ドキュメント：Firebase、Android
参加方法：
以下のフォームにご記入ください。なお、応募者多数の場合は参加者を選考させていただきます。
参加できる方には別途ご案内を差し上げます。 　
　
参加登録フォーム
↧
Search

Google アナリティクス、AMP のサポートを強化

July 5, 2017, 6:55 pm
$
0
0
この記事は Google Analytics チームによる Accelerated Mobile Pages Project の記事 "Google Analytics is Enhancing Support for AMP" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


この記事は、Google アナリティクス チームによってGoogle アナリティクス ブログに投稿された記事の クロスポストです。

この 1 年間で、Accelerated Mobile Pages（AMP）テクノロジーはニュースサイトからレシピ、e コマースに至るあらゆる種類のサイトで採用され、ページの高速化を実現してきました。公開されている AMP ページは既に数十億を数えており、Google アナリティクスでは AMP を導入されたサイト運営者様のためのサポート強化を続けています。

しかし、Google アナリティクスのユーザー様からは、サイト訪問者の ID が AMP ページと非 AMP ページで一致しないため、完全にナビゲーションを理解するのが難しいというフィードバックが寄せられています。そこで、ユーザーがウェブサイトの AMP ページと非 AMP ページをまたいで遷移する際のナビゲーションをさらに正確に捉えられる拡張機能をリリースしたことをお知らせいたします。これにより、AMP および非 AMP を含むサイト全体におけるユーザーのエンゲージメントをより正確に理解することができます。


新たな仕組み
今回の変更によって、サイト運営者様のドメインから提供される AMP ページのサイト訪問者と非 AMP ページのサイト訪問者が一致するようになります。2 つのページ形式によらずサイト訪問者が統一されるので、ユーザー解析の精度が上がります。Google AMP Cache などの AMP キャッシュから提供される AMP ページへの影響はありません。

導入時期
今後数週間ですべての Google アナリティクス アカウントに反映される予定です。

この変更による他の影響
AMP ユーザーと非 AMP ユーザーの統一により、今後ユーザーがサイトを訪問した際に、ユーザー数やセッション数などの指標に影響が出る可能性があります。以前は同じユーザーが別々の ID として認識されていたため、ユーザー数やセッション数は時間が経つにつれて減少します。ただし、この変更が反映された時点で ID がリセットされるため、新規ユーザー数の指標が一時的に上がる可能性があります。

また、AMP のページビューと非 AMP のページビューが別のセッションとして扱われることがなくなるので、サイトの滞在時間、セッション当たりのページビュー、直帰率などの指標は上がります。これは、過去に AMP ページを閲覧したすべてのユーザーの ID が統合されるまで続きます（この期間は、ユーザーがサイトやアプリを使用する頻度によって異なります）。

今回の変更に際して必要な対応
これらの変更は自動的に反映されるため、特にアクションは必要ありません。

自社ドメインと他社ドメインの両方で自社ページを閲覧したユーザーの識別子統合
AMP ページの中には、元々コンテンツがホストされているドメインではなく、AMP キャッシュ経由やプラットフォーム内にあるコンテンツにアクセスするものもあります。しかし、今回の変更では、クライアントに提供する価値をできるだけ速やかに高めるため、まずサイトオーナーのドメインに関する問題を修正することに重点を置いています。

私たちは、AMP ページでも非 AMP ページでも同じようにユーザーのナビゲーションを分析できるよう、最高の品質のデータを提供することに努めています。今回の変更によって、サイト運営者様のドメインで AMP ページを提供しやすくなります。この改善が皆様のお役に立つことを願っております。ぜひご利用ください。

どうぞよろしくお願いいたします。

↧

Android 用ゲームにおける Back キーの標準的挙動について

July 5, 2017, 7:54 pm
$
0
0
Android の Back キー（Back ボタン）は、ユーザーが直近で使用した画面を順番にさかのぼって移動できるように実装するのが基本です。また、ゲームデザインとユーザー体験に留意して動作を調整することも重要です。

そのほかに重要なこととして、ゲームを開発する際、（ゲームプレイのデータなどの）ユーザーにとって貴重な情報を損失しないようにする、ということがあります。それぞれの場面でユーザー体験を考慮し、ユーザーの期待に沿うような実装をご検討いただければ幸いです。

基本的な方針：
  • Back キーが押された際には何かアクションが起きるようにしてください。何もアクションが起きないとユーザーの混乱を招いてしまう可能性があります。
ゲーム内ナビゲーション：　
  • 適切であれば一つ手前の画面に移動する（例 1.1）
    • チュートリアルの途中、ゲームキャラクターの会話（例1.3）、ゲームの結果画面など、「戻る」動作が望ましくはない画面では、手前の画面に移動する以外の実装をご検討ください。
  • トップ画面でゲームを直接終了する（例 1.2）
    • 起動する際にゲームを開始できるまでに時間がかかってしまう場合、（直接ゲーム終了せず）ゲーム終了を確認するためのポップアップの実装をご検討ください。
  • （タブなどの）並列する画面間では前に戻らない

　



例 1.1 画面上の［戻る］と同じ挙動
例 1.2 終了確認用のポップアップ
例 1.3 ゲームキャラクターの会話

　
その他の挙動例：　
  • すべてのフローティング ウィンドウ（ポップアップやダイアログなど）をキャンセルする（例 2.1, 2.2 ）
  • ゲーム進行中にポーズ画面を表示し、ポーズ画面ではゲームを再開する（例 2.3）
  • 表示中のドロワーを最小化する (例 2.4)

　


例 2.1 選択が 1 つのみのダイアログでは、「Close」「OK」「X」ダイアログをキャンセル




例 2.2 2 つ以上の選択肢がある場合は「NO」「いいえ」「キャンセル」［戻る］と同じ挙動




例 2.3 ポーズ画面
例 2.4 ドロワー

　
参考資料：　
画像提供：株式会社サイバーエージェント

※本資料の情報は作成日（07/04/2016）時点のものであり、最新の Android や Google Play の仕様やガイドラインとは異なる場合がありますのでご了承ください。 　
　
　
Posted by Kei Kawabata
↧
↧

新しい Location API で負荷を軽減

July 6, 2017, 8:18 pm
$
0
0
この記事は Google Play サービス ソフトウェア エンジニア、Aaron Stacy による Android Developers Blog の記事 "Reduce friction with the new Location APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Play サービス SDK の 11.0.0 リリースでは、新たな方法で LocationServicesにアクセスできます。新しい API を使用すると、GoogleApiClient経由での Google Play サービスへの接続をアプリ側で手動で管理する必要がなくなります。これにより、アプリのボイラープレートが減り、一般的なミスを防止できます。

詳細については以下をご覧ください。最新の位置情報サンプルは GitHub から入手できます。

GoogleApiClient を使う


LocationServices API を使用すると、端末の位置情報へのアクセスやジオフェンスの設定、端末上で位置情報を有効にするようユーザーに促すなど、さまざまなことが可能になります。こうしたサービスを利用するには、アプリで Google Play サービスに接続する必要がありますが、その接続ロジックの一部がエラーの原因となる場合があります。たとえば、以下のアプリの例でクラッシュする箇所を見つけられるでしょうか。

注: アプリには、LocationServices API でユーザーの正確な位置情報を取得するために必要な ACCESS_FINE_LOCATIONパーミッションが付与されているものとします。 
public class MainActivity extends AppCompatActivity implements
        GoogleApiClient.OnConnectionFailedListener {

  @Override
  public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    GoogleApiClient client = new GoogleApiClient.Builder(this)
        .enableAutoManage(this, this)
        .addApi(LocationServices.API)
        .build();
    client.connect();

    PendingResult result = 
         LocationServices.FusedLocationApi.requestLocationUpdates(
                 client, LocationRequest.create(), pendingIntent);

    result.setResultCallback(new ResultCallback() {
      @Override
      public void onResult(@NonNull Status status) {
        Log.d(TAG, "Result: " + status.getStatusMessage());
      }
    });
  }

  // ...
}

正解は requestLocationUpdates()の呼び出しです。GoogleApiClientの接続が完了していないため、この呼び出しでは IllegalStateExceptionがスローされます。connect()の呼び出しは非同期です。

上のコードは問題ないように見えますが、GoogleApiClient Builder に渡す ConnectionCallbacks引数がありません。よって、必ず onConnectedコールバックが呼び出されたあとで、位置情報の更新をリクエストするための呼び出しを行う必要があります。 
public class MainActivity extends AppCompatActivity implements 
        GoogleApiClient.OnConnectionFailedListener,
        GoogleApiClient.ConnectionCallbacks {

  private GoogleApiClient client;

  @Override
  protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    client = new GoogleApiClient.Builder(this)
        .enableAutoManage(this, this)
        .addApi(LocationServices.API)
        .addConnectionCallbacks(this)
        .build();

    client.connect();
  }

  @Override
  public void onConnected(@Nullable Bundle bundle) {
    PendingResult result = 
            LocationServices.FusedLocationApi.requestLocationUpdates(
                    client, LocationRequest.create(), pendingIntent);

    result.setResultCallback(new ResultCallback() {
      @Override
      public void onResult(@NonNull Status status) {
        Log.d(TAG, "Result: " + status.getStatusMessage());
      }
    });
  }

  // ...
}

これでコードは機能するようになりましたが、まだ次のような問題があります。
  • 複数のアクティビティで位置情報サービスにアクセスしたい場合などに、共有クラスにリファクタリングしにくい。
  • 位置情報サービスがより後の段階（ユーザー入力後など）まで必要ない場合でも、アプリは onCreateで安易に接続してしまう。
  • アプリが Google Play サービスへの接続に失敗したケースに対処できない。
  • 位置情報の更新を始めるまでに、大量のボイラープレート接続ロジックがある。

デベロッパー エクスペリエンスの向上


新しい LocationServices API は格段にシンプルになっており、コードのエラーを防止できます。接続ロジックは自動で処理されるため、完了時のリスナーを 1 つ登録するだけで済みます。 
public class MainActivity extends AppCompatActivity {

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    FusedLocationProviderClient client =
            LocationServices.getFusedLocationProviderClient(this);

    client.requestLocationUpdates(LocationRequest.create(), pendingIntent)
        .addOnCompleteListener(new OnCompleteListener() {
          @Override
          public void onComplete(@NonNull Task task) {
            Log.d("MainActivity", "Result: " + task.getResult());
          }
        });
  }
}

この新しい API を使用すると、次のようにすぐにコードを改善できます。
  • サービス接続が確立されるまで API 呼び出しは自動で待機状態になるため、リクエスト前に onConnectedを待機する手間が省ける。
  • Task API を使用しているため、より簡単に非同期操作を構成できる。
  • コードは自己完結型なので、共有ユーティリティ クラスや同等のものに容易に取り入れることができる。
  • コーディング開始時に下層の接続プロセスを把握する必要がない。

コールバックの扱い


新しい API では特定の接続エラーを自動で解決するため、ユーザーに Google Play サービスのアップデートを促すようなコードを書く必要はありません。接続エラーが発生した場合は、エラーを onConnectionFailedメソッドでグローバルに公開する代わりに、ApiExceptionでそのタスクを失敗させます。 
    client.requestLocationUpdates(LocationRequest.create(), pendingIntent)
        .addOnFailureListener(new OnFailureListener() {
          @Override
          public void onFailure(@NonNull Exception e) {
            if (e instanceof ApiException) {
              Log.w(TAG, ((ApiException) e).getStatusMessage());
            } else {
              Log.w(TAG, e.getMessage());
            }
          }
        });

実際に試す


ご自身のアプリで新しい LocationServices API を使うか、GitHub にある android-play-location サンプルやその他のサンプルを試して、新しいクライアントによってどのようにボイラープレートが削減され、ロジックが簡略化されるのかをご確認ください。


Reviewed by Yoshifumi Yamaguchi - Developer Relations Team
↧

Tensor2Tensor ライブラリでディープ ラーニング研究を加速化

July 9, 2017, 8:24 pm
$
0
0
この記事は Google Brain チーム上級科学研究者、Łukasz Kaiser による Google Research Blog の記事 "Accelerating Deep Learning Research with the Tensor2Tensor Library" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ディープ ラーニング（DL）によって、機械翻訳、音声認識、物体検知など、数多くの便利なテクノロジーが急速に発展しています。研究コミュニティでは、作者がオープンソース化したコードを見つけてその成果を利用し、さらに高度なディープ ラーニングに発展させることができるようになっています。ただし、こういった DL システムのほとんどは、技術的に大きな労力を伴う特殊な設定が利用されており、特定の問題やアーキテクチャにしか効果がない場合もあります。そのため、新しい実験を行って結果を比較するのは困難です。
そこで本日（*原文公開当時）、TensorFlow でディープ ラーニング モデルのトレーニングを行うオープンソース システムの Tensor2Tensor（T2T）をリリースします。T2T は、翻訳、解析、イメージのキャプション生成など、さまざまな分野の ML に応用できる最新のモデルの作成をサポートし、いろいろなアイデアを以前よりもはるかに早く試すことができるようにするものです。このリリースには、データセットとモデルのライブラリや、DL 研究に弾みをつけることができる最新の論文（Attention Is All You Need、Depthwise Separable Convolutions for Neural Machine Translation、One Model to Learn Them All）に掲載された優れたモデルも含まれています。

翻訳モデル
トレーニング時間
BLEU（基準点との差）
Transformer（T2T）
8 GPU で 3 日間
28.4（+7.8）
SliceNet（T2T）
32 GPU で 6 日間
26.1（+5.5）
64 GPU で 1 日間
26.0（+5.4）
ConvS2S
1 GPU で 18 日間
25.1（+4.5）
GNMT
96 GPU で 1 日間
24.6（+4.0）
32 GPU で 8 日間
23.8（+3.2）
MOSES（フレーズベースの基準点）
該当せず
20.6（+0.0）
標準 WMT 英独翻訳タスクの BLEU スコア（高いほどよい）
T2T を機械翻訳タスクに適用した例を上に示します。この表からわかるように、2 種類の T2T モデル（SliceNet と Transformer）がこれまでのベストの成果だった GNMT+MoEを超えています。標準 GNMTモデルは、基準となるフレーズベースの翻訳システムである MOSES を 4 点上回っていますが、最高の T2T モデルである Transformer はそれをさらに 3.8 点上回っています。注目すべきは、T2T では以前の最新技術による結果を 1 日あたり 1 つの GPU で実現することに近づいている点です。小さな Transformer モデル（上には記載されていません）は、1 つの GPU で 1 日トレーニングを行っただけで、BLEU スコア 24.9 点を達成しています。つまり、GPU があれば、誰でも優れた翻訳モデルを利用できます。詳しい手順は github レポジトリをご覧ください。

モジュール式のマルチタスク トレーニング
T2T ライブラリは、おなじみの TensorFlow ツールを使って構築されており、ディープ ラーニング システムに必要なデータセット、モデル アーキテクチャ、オプティマイザー、学習率減衰スキーム、ハイパーパラメータなど、さまざまなパーツが定義されています。特に重要なのは、こういったすべてのパーツ間で標準インターフェースの利用が強制されていること、さらに現在の ML のベスト プラクティスが実装されていることです。そのため、任意のデータセット、モデル、オプティマイザー、ハイパーパラメータ セットを選んでトレーニングを実行し、その成果を確認できます。アーキテクチャはモジュール化されているので、入力データと予測結果となる出力をつなぐパーツはすべてテンソル変換機能です。モデル アーキテクチャのアイデアが新たに浮かんだ場合でも、設定全体を置き換える必要はありません。埋め込んだパーツや損失などはすべてそのまま使うことができるので、テンソルを入力として受け取りテンソルを返す独自の機能でモデル本体を置き換えるだけで済みます。

これが T2T の柔軟さを実現しています。トレーニングが特定のモデルやデータセットに固定されることはありません。使い方はとても簡単で、有名な LSTM Sequence to Sequence モデルなどのアーキテクチャでも数十行のコードで定義できます。また、別のドメインの複数のタスクで 1 つのモデルをトレーニングすることもできます。究極的には、1 つのモデルに対してすべてのデータセットを使って同時にトレーニングすることも可能です。そのようにトレーニングを行った MultiModel（T2T に含まれています）は、ImageNet（イメージ分類）、MS COCO（イメージのキャプション生成）、WSJ（音声認識）、WMT（翻訳）、Penn Treebank解析コーパスと合わせてトレーニングを行った場合でも、多くのタスクで優れた結果を残しています。単一のモデルでこういったすべてのタスクを同時に行えることが証明できたのは初めてです。

ベスト プラクティスの組み込み
この初回リリースでは、研究コミュニティで広く利用されているさまざまなデータセットを生成するスクリプト1、いくつかのモデル2、さまざまなハイパーパラメータ設定、その他の重要なポイントがうまく動作するように実装されたものが提供されています。ここですべてを紹介するのは困難ですが、T2T でモデルを実行する場合は、適切なシーケンスのパディング、対応する交差エントロピー損失、Adam オプティマイザー用に適切にチューニングされたパラメータ、アダプティブ バッチング、同期分散トレーニング、適切にチューニングされたイメージデータ拡張、ラベルのスムージング、最適な動作を提供するさまざまなハイパーパラメータ設定などを無償で使うことができます。上で説明したような翻訳で優れた結果を出す最新技術も含まれており、そこからもよい結果が得られるかもしれません。

例として、英語の文を解析して文法的な構文木で表現するタスクを考えてみましょう。この問題はすでに何十年にもわたって研究されており、多大な労力をかけて多くの方法が生み出されています。これはシーケンス変換問題としてニューラル ネットワークで解決することもできますが、それには多くのチューニングが必要でした。T2T を使うと、わずか数日で解析データセット生成ツールを追加できるので、この問題のトレーニングを行う変換モデルに集中することができます。これはうれしい驚きでしたが、わずか 1 週間でよい結果が得られました。

解析モデル
F1 スコア（高いほどよい）
Transformer（T2T）
91.3
Dyer など
91.7
Zhu など
90.4
Socher など
90.4
Vinyals & Kaiser など
88.3
標準テストセット、WSJ セクション 23 の解析 F1 スコア。Penn Treebank WSJ トレーニング セットのみでトレーニングしたモデルで比較。詳しい結果は論文を参照。

Tensor2Tensor に貢献する
既存のモデルやデータセットを使うだけでなく、Tensor2Tensor に独自のモデルを定義したり、独自のデータセットを追加するのも簡単です。同梱されているモデルは多くの NLP タスクで優れた動作をするはずなので、データセットを追加するだけで興味深い結果が得られるでしょう。T2T がモジュール化されたことによって、独自のモデルを提供して、さまざまなタスクで動作を確認することも非常に簡単になりました。このように、コミュニティ全体がベースラインとなるライブラリによる恩恵を受け、ディープ ラーニングの研究を加速することができます。早速 github レポジトリにアクセスして新しいモデルを試し、皆さんのモデルでコミュニティに参加してください。

謝辞
Tensor2Tensorをリリースできたのは、多くのエンジニアや研究者の皆さんと幅広く共同作業ができたおかげです。ここで、貢献していただいた主なチームにお礼を申し上げます（アルファベット順）。Samy Bengio、Eugene Brevdo、Francois Chollet、Aidan N. Gomez、Stephan Gouws、Llion Jones、Łukasz Kaiser、Nal Kalchbrenner、Niki Parmar、Ryan Sepassi、Noam Shazeer、Jakob Uszkoreit、Ashish Vaswani



1 イメージ分類（MNIST、CIFAR-10、CIFAR-100、ImageNet）、イメージのキャプション生成（MS COCO）、翻訳（英独と英仏を含む複数言語 WMT）、言語モデリング（LM1B）、解析（Penn Treebank）、自然言語推論（SNLI）、音声認識（TIMIT）、アルゴリズム問題（逆転、加算、乗算から代数まで、10 以上のタスク）などに利用できる多数のデータセットが含まれています。今後さらに追加される予定で、皆さんのデータセットも歓迎します。↩

2 LSTM Sequence to Sequence RNN、分割可能なものを含む畳み込みネットワーク（例: Xception）、ByteNet や Neural GPU などの最新研究モデルのほか、レポジトリのアップデートが精力的に行われている本投稿で紹介した最新モデルなどが含まれています。↩





Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud
↧

Android 2.1 以前の Android Market のサポート終了

July 10, 2017, 8:52 pm
$
0
0
この記事は Google Play ソフトウェア エンジニア、Maximilian Ruppaner による Android Developers Blog の記事 "Ending support for Android Market on Android 2.1 and lower" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google は 2017 年 6 月 30 日に、Android 2.1 Eclair 以前の端末の Android Market のサポートを終了します。この変更後、これらの端末のユーザーは Android Market にアクセスできなくなり、Android Market からアプリをインストールすることもできなくなります。Android Market アプリの技術的な制約により、この変更は端末に通知することなく行われます。

Android 2.1 Eclair はリリースされてから 7 年が経過しています。対象端末にインストールされているアプリの割合は少なく、ほとんどのデベロッパーはこれらの Android バージョンをサポートしていません。

これよりも新しいバージョンの Android Market は、今後もできる限り長期間サポートする予定です。Android Market の後継である Google Playは、Android 2.2 以降で利用できます。


Reviewed by Hak Matsuda - Developer Relations Team
↧
Viewing all 2207 articles
Browse latest View live
Search