OpenCensus Web: スタック全体の完全なエンドツーエンド観測を実現する

October 9, 2019, 8:59 pm

≫ Next: ウェブアプリを Interactive Canvas 向けに最適化する

≪ Previous: モーショナル インテリジェンス: スマートなアニメーションを作成する

$

0

0

この記事は Cristian González – OpenCensus チーム – 2019 年夏季 Google ソフトウェア エンジニアリング インターン、コロンビア国立大学コンピュータおよびシステム エンジニアリング学部生による Google Open Source Blog の記事 "OpenCensus Web: Unlocking Full End-to-End Observability for Your Entire Stack" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


 OpenCensus Web は、ユーザーがウェブページのパフォーマンスをどのように感じているかをトレースし、監視するツールです。診断方法がわからないパフォーマンスの問題がウェブページで発生していないかどうかを判断する際に役立ちます。

ウェブ アプリケーションの所有者は、実際のユーザーが感じるパフォーマンスを理解するために、アプリケーションのオペレーションの健全性を監視したいと思っています。しかし、多くの場合、ウェブ アプリケーションから関連データを集めるのは困難です。本日は、OpenCensus Web（OC Web）を紹介します。OC Web を使うと、簡単かつ自動的にウェブ アプリケーションのインストルメンテーションを行い、指標や分散トレースをエクスポートすることができます。

背景

OpenCensusプロジェクトは、いくつかの言語固有のインストルメンテーション ライブラリを提供しています。これらのライブラリは、アプリケーションからトレースや指標を収集し、Prometheus、Zipkin、Jaeger、Stackdriver などのトレースおよび監視バックエンドにエクスポートします。

OpenCensus Webライブラリは、ブラウザで実行されるフロントエンド ウェブ アプリケーションのコードに特化した OpenCensus の実装です。OC Web はウェブページのインストルメンテーションを行い、遅延や分散トレースなどのパフォーマンス データをユーザーサイドで収集します。デベロッパーは、フロントエンドの問題診断とアプリケーション全体の健全性監視のための情報を得ることができます。

なお、OC Web 以上に重要なのは、さらに広範な OpenCensus ファミリーのプロジェクトが OpenTracing を取り込んで OpenTelemetryになりつつあることです。このプロジェクトの準備が整った時点で、OpenCensus Web の機能は OpenTelemetry JSに移行される見込みです。その間も、OC Web はアルファ版リリースとして動作し続けます。

アーキテクチャ

OC Web は、次の 3 つのアプリケーション コンポーネントと連係して動作します。

• フロントエンド ウェブサーバー: OC Web のライブラリ コードや構成を含む最初の HTML をブラウザに対してレンダリングします。通常、これは OpenCensus サーバーサイド ライブラリ（Go、Java など）でインストルメンテーションされます。サーバーには、HTTP/JSON トレースを受信して OpenCensus Agent との通信を仲介するエンドポイントを作成することをお勧めします。
• ブラウザの JS: ブラウザで実行される OC Web ライブラリのコードです。このコードは、ユーザー操作の測定とブラウザデータの収集を行い、HTTP/JSON を使って OpenCensus Agent にスパンとして書き込みます。
• OpenCensus Agent: フロントエンド ウェブサーバーのプロキシ エンドポイントから、またはブラウザの JS から直接トレースを受け取り、トレース バックエンド（例: Stackdriver、Zipkin）にエクスポートします。

OC Web には、OpenCensus Agentが必要です。OpenCensus Agent は、診断データを仲介して任意のバックエンドに再エクスポートします。詳細については、ドキュメントをご覧ください。

機能

最初のページ読み込みのトレース

OC Web を使うと、最初のページ読み込みのトレースを取得できます。なんと、OC Web ライブラリがブラウザに読み込まれる前に発生したイベントも取得できます。最初のページ読み込みのトレースを行うと、どのリソースがウェブサイトのパフォーマンスを低下させているのかがわかります。また、通常は分散トレース システムで取得できないデータも取得できます。

最初のページ読み込みにおけるすべての相互作用の時間を測定するため、OC Web はドキュメントの load イベントが発生するまで待機し、最初のページ読み込みパフォーマンスを示すタイミングからスパンを生成します。その際に、ブラウザの Navigation Timing API と Resource Timing API を使います。以下に示すのは、最初の読み込みサンプルアプリからキャプチャした OC Web のトレース サンプルを Zipkinにエクスポートしたものです。ブラウザの load イベントが発行されるまでのユーザーのナビゲーションの全体を表す ‘nav./’スパンがあることに注目してください。

このサンプルには、クライアント サイドとサーバーサイドで最初の HTML 読み込みを測定した ‘/’スパンも含まれています。これらのスパンは、W3C Trace Context形式で ‘window.traceparent’変数を送り返すサーバーによって接続されます。これが必要になるのは、ブラウザは最初のページ読み込みの際に Trace Context ヘッダーを送信しないためです。サーバーサイドのスパンから、テンプレートの解析とレンダリングにかかった時間もわかります。

先ほどのイメージの long js task スパンは、CPU による制約を受ける JavaScript イベントループに 80.095 ミリ秒かかったことを示しています。これは、Long Tasksブラウザ API で計測しています。

DOM イベントとネットワーク イベントのスパンのアノテーション

OC Web が取得するスパンには、詳細なアノテーションも含まれています。たとえば、`domInteractive`や `first-paint`などの DOM イベントについてのアノテーションや、domainLookupStart や secureConnectionStart などのネットワーク イベントについてのアノテーションです。次に示すのは、先ほどと同じトレースを Stackdriver Traceにエクスポートし、アノテーションを展開したものです。

ユーザー操作

単一ページ アプリケーションでは、最初の読み込み後に操作（例: ユーザーがボタンをクリックする、ページの別のセクションに移動する）が発生するのが一般的です。エンドユーザーがブラウザ アプリケーション内で行った操作を測定すると、アプリケーションについて次のような有用なデータが得られます。

• 最初のページのレンダリングとその後のページ内操作を関連付ける
• クリック後にページの応答がなくなるなど、エンドユーザーが認識できる速度低下を可視化する

現在の OC Web は、Angular の Zone.jsライブラリにモンキーパッチを当てることにより、クリックとルートの遷移をトラックしています。OC Web は、その後の操作によって発生する同期タスクおよび非同期タスク（例: setTimeout、XHR）をトラックします。いくつかの操作が同時に実行された場合でも、トレースが行われます。

クリック イベントの自動トレース

ブラウザの clickイベントは、DOM 要素（例: ボタン）がクリックされ、クリック対象の要素が無効になっていない限り、すべてトレースされます。ユーザーが要素をクリックすると、新しい Zoneが作成され、操作にかかる合計時間が計測されます。

このルートスパンに名前を付けるため、デベロッパーが要素に data-ocweb-id属性を追加して操作の名前をカスタマイズできるようにしています。次の例では、‘Save edit user info’という名前になります。

<button type="submit"data-ocweb-id="Save edit user info">       Save changes </button>

これにより、特定の要素に関連するトレースを区別しやすくなり、似たような操作があっても明確に区別できるようになります。この属性を追加しない場合、OC Web は DOM 要素の ID、タグ名、操作に関連するイベント名を組み合わせたものを使います。たとえば、次のボタンをクリックすると、

<button id="save_changes"> Save changes </button>

“button#save_changes click”という名前のスパンが生成されます。

ルート遷移の自動トレース

OC Web は、History APIにモンキーパッチを適用することで、ページ セクション間のルート遷移をトレースします。OC Web は、‘Navigation /path/to/page’というパターンを使ってこの操作に名前を付けます。次のスクリーンショットは、ユーザー操作サンプルから Stackdriver にエクスポートしたトレースです。ここには 1 つの Navigation トレースが含まれており、ルート遷移が完了する前にいくつかのネットワーク呼び出しが行われています。

カスタム スパンの作成

OC Web では、ユーザーの操作に関連するタスクやコードのカスタムスパンを使ってウェブ アプリケーションのインストルメンテーションを行うことができます。次に示すのは、その方法を例示したコード スニペットです。

import { tracing } from'@opencensus/web-instrumentation-zone';

functionhandleClick() {

  // 現在の操作のルートスパンの子スパンを開始

  // これはボタンが実行するコードで実行する必要がある

  constchildSpan= tracing.tracer.startChildSpan({

    name:'name of your child span'

  });

  // 何らかのオペレーションを実行...

  // オペレーション終了時に子スパンを終了

  childSpan.end();

}

詳細については、OC Web のドキュメントをご覧ください。

HTTP リクエストの自動スパンとブラウザのパフォーマンス データ

OC Web は、ユーザーの操作によって生成される HTTP リクエストを自動的にインターセプトしてスパンを生成します。さらに、OC Web はインターセプトしたそれぞれの HTTP リクエストに W3C Trace Context形式の Trace Context ヘッダーを追加します。この処理は、同じオリジンのリクエストまたは提供された正規表現に一致するリクエストに対してのみ行われます。

サーバーで OpenCensus によるインストルメンテーションも行っている場合、バックエンド サービス全体でこれらのリクエストのトレースが継続されます。そのため、問題がフロントエンドにあるのかサーバーサイドにあるのかを知ることができます。

OC Web には、domainLookupStartや responseEnd などのアノテーションを作成し、CORS プリフライトリクエストのスパンを生成するための Performance APIデータも含まれています。

次のスクリーンショットは、ユーザー操作のサンプルとして Stackdriver にエクスポートしたトレースを示しています。アノテーションが付加されたスパンが自動生成されているネットワーク呼び出しがいくつか（例: ‘Sent./sleep’）あることがわかります。また、サーバーサイドのスパン（例: ‘/sleep’、‘ocweb.handlerequest’）や、CORS プリフライトに関連するスパンも存在します。

ユーザー操作と最初のページ読み込みのトレースとの関連付け

OC Web は、属性およびスパンリンクとして、ユーザーの操作に最初のページ読み込み時のトレース IDを付加します。これにより、1 つの属性に対するクエリでトレースを検索することで、最初の読み込みのトレースとその操作に関連するトレースを探せるようになります。また、あるページを読み込んだ後のアプリケーション内でのユーザーのナビゲーション全体を理解することも可能です。

次のスクリーンショットは、initial_load_trace_id属性を使った検索を示しています。これには、最初にページを読み込んだ後のすべてのユーザー操作のトレースが含まれています。

実現する

OC Web を使えば、数行のインストルメンテーションを記述するだけで、ウェブ アプリケーションの分散トレースをエクスポートできます。ぜひ、最初の読み込みとユーザー操作のサンプルを試してみてください。ソースコードに手を入れてみたり、Gitterからフィードバックを送ったり、プル リクエストで貢献したりすることも大歓迎です！

投稿者: Cristian González – OpenCensus チーム – 2019 年夏季 Google ソフトウェア エンジニアリング インターン、コロンビア国立大学コンピュータおよびシステム エンジニアリング学部生

OC Web の最初の作成者であり、今回の開発のサポートをしてくれた Dave Raffensperger 氏に格別の感謝を捧げます。

Reviewed by Yoshifumi Yamaguchi - Developer Relations Team

---

ウェブアプリを Interactive Canvas 向けに最適化する

October 10, 2019, 7:59 pm

≫ Next: Google Maps Platform ベストプラクティス：最適化とパフォーマンス改善のヒント

≪ Previous: OpenCensus Web: スタック全体の完全なエンドツーエンド観測を実現する

$

0

0

この記事は Leon Nicholls による Google Developers - Medium の記事 "Optimize your web apps for Interactive Canvas" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Interactive Canvasを使って Google アシスタント用の Action を作成すると、最高の会話型インターフェースと HTML の豊かな視覚表現を組み合わせることができます。

私たちは、ここしばらくの間、Interactive Canvas を使ってさまざまなアイデアを実験し、Action を作成するパートナーと協力しながら、どうすればうまくいくのかという知見を得ることができました。この投稿では、をお伝えすることで、Interactive Canvas を使った Action を成功させるお手伝いをしたいと思います。

注: 現時点で、Google は Canvas Action をゲームに限って承認しています。

設計

Interactive Canvas を使う Action は、会話型 Actionです。ゲームの設計は、Interactive Canvas による視覚表現を使ってどのように音声ユーザー インターフェースを補完できるかを考えるところから始める必要があります。Action の会話を設計する着手点として、設計ガイドラインをご確認ください。

Interactive Canvas を使う Action では、ゲームの主なステージを網羅したストーリーボードを作ることをお勧めします。これには、読み込み画面、ようこそ画面とチュートリアル画面、ゲームのメイン画面、終了画面などを含めます。

ユーザーがゲーム中に画面に触れることもあるので、タッチイベントに対してフィードバックを行う方法も考えます。ユーザーの入力に対するコールバックの応答を待つのではなく、ウェブアプリ内ですぐに確認することをお勧めします。

さらに、Interactive Canvas ウェブアプリにはさまざまな制限があることも考慮しなければなりません。たとえば、ローカル ストレージは使えず、メモリは 200 MB の制限を超えてはいけません。

Action で使う視覚要素、GUI コンポーネント、アニメーションが決まったら、Interactive Canvas をサポートする端末にとって技術的にベストな実装を選択します。次のセクションでは、すべてのサポート対象の Interactive Canvas で問題なく動作するさまざまな推奨 HTML 技術を紹介します。ここで紹介する内容は、下に示す今回試作したデモ用 Action のようなものを作る際に役立ちます。

ローディング ページ

ウェブページが完全に読み込まれてアニメーション本体が表示されるまでの間は、ローディング ページを表示することをお勧めします。これにより、アニメーションのパフォーマンスに大きな違いが出るだけでなく、ページ アセットの読み込み中に起きがちなレイアウトの問題を避けることもできます。

ローディング ページが表示されている間に、JavaScript のロジックを使って非同期的に任意のアセット（画像ファイルやテクスチャなど）を読み込むことができます。
一番簡単にローディング ページをデザインするには、単色の塗りつぶし背景上にアニメーションする読み込み中のインジケーターを表示させます。JavaScript によるアニメーションは避けた方がよいので、CSS かアニメーション GIF を使いましょう。ローディング ページの参考として、こちらのクールな CSS ローダーをご覧ください。

レスポンシブ デザイン

現在のところ、Interactive Canvas は Google アシスタント スマート ディスプレイと Android モバイル端末でサポートされています。これらの端末は画面解像度が異なり、ランドスケープ モード（横向き）とポートレート モード（縦向き）の両方をサポートしている可能性もあります。

そのため、それぞれの種類のディスプレイでレイアウトとテキストが適切なサイズになるように、レスポンシブ デザインのウェブアプリにするとよいでしょう。簡単にこれを行うには、Sassブレークポイントを使います。

@mixin for-small-display-landscape {
@media screen and (min-width: 1024px) and (min-height: 600px) {
@content;
    }
}

@mixin for-medium-display-landscape {
@media screen and (min-width: 1280px) and (min-height: 700px) {
@content;
    }
}

また、Action の画面上部にはヘッダーがあり、Action の名前とアイコンが表示されます。また、ユーザーはヘッダーから Action を閉じることができます。このヘッダーの後ろに重要なコンテンツやテキストを配置してはいけません。

Interactive Canvas では、ヘッダーの高さ（ピクセル単位）を非同期的に決める getHeaderHeightPx() API が提供されています。この値を使うと、ウェブアプリが読み込まれた際にレイアウトを動的に調整することができます。

window.onload = () => {
  const callbacks = {
    onUpdate(data) {
      // update game state based on intent response data
    },
  }
  interactiveCanvas.ready(callbacks)

interactiveCanvas.getHeaderHeightPx().then((height) => {
    // initialize web app layout with header height value
  })
}

アニメーション

HTML では、DOM の操作、CSS アニメーション、HTML キャンバス、WebGL など、さまざまな方法でアニメーションを行うことができます。

私たちの経験上、JavaScript でほぼリアルタイムに計算を行うアニメーションには多くの最適化が必要になります。しかし、スムーズで FPS の高いアニメーションを行う方法は他にもあります。

CSS

JavaScript で DOM を操作する代わりに、CSS アニメーションを使うことを検討します。ブラウザは GPU を使ってこの種のアニメーションを高速化できるだけでなく、メイン UI スレッドとは別にアニメーションを管理することもできます。

低レベルの CSS プロパティを使いたくない場合は、animate.cssなどの CSS ライブラリを利用できます。こういったライブラリには、さまざまな高品質アニメーションに利用できる CSS クラスが含まれています。このようなアニメーションを使う場合、まず、要素と必要な CSS アニメーション プロパティを宣言します。

.title {
  animation-duration: 3s;
  animation-delay: 2s;
  animation-iteration-count: infinite;
}

その後、アニメーション クラスを HTML 要素とともに静的に宣言するか、JavaScript を使ってアニメーション クラスを動的に呼び出します。

const element = document.querySelector('.title');
element.classList.add('animated', 'bounceInUp');
element.style.visibility = 'visible';
element.addEventListener('animationend', () => {
  element.style.visibility = 'hidden';
});

アニメーションの同時実行は避け、前のアニメーションの終了イベントで次のアニメーションを呼び出して連続したアニメーションを行うことをお勧めします。

Web Animations APIの利用も検討できます。これを使うと、CSS による最適なパフォーマンスと JavaScript の動的機能を両立させることができます。

SVG

SVG を使うと、JavaScript や CSS を通して動的に操作できる 2 次元ベクター グラフィックを作成できます。

SVG は、時間によって要素の属性をアニメーションさせる <animate>タグをサポートしています。基本的なアニメーションなら、Canvas 端末で非常にスムーズに動作します。

しかし、CSS を使う方が、SVG のグラフィック要素をスムーズにアニメーションさせることができます。SVG の <path>にはクラスを割り当てることができ、そのクラスと CSS アニメーションを使ってアニメーションさせることができます。この方式のアニメーションも、端末でスムーズにレンダリングされます。

WebGL

WebGL は、端末の GPU を使ってウェブページのアニメーションのパフォーマンスを大幅に改善します。WebGL を使った経験がない方は、PixiJSなどのさまざまなライブラリを使うことができます。こういったライブラリは、使いやすい高レベルの JavaScript API を提供しており、WebGL でレンダリングされるアニメーションをデザインできます。

Adobe Animate などのツールに親しんでいるアニメーターの方なら、PixiAnimate拡張機能を使ってコンテンツをエクスポートし、PixiJS ラインタイム ライブラリで再生することができます。Canvas ウェブアプリでは、Pixi Animate プラグインを使ってエクスポートしたアニメーションを読み込むことができます。読み込んだアニメーションは、JavaScript のコードで制御できます。図形の色を変えるなど、動的に外見を変えることもできます。

Adobe Animate の「シェイプ トゥイーン」の使用は避けることをお勧めします。この機能はたくさんのテクスチャを生成するので、Canvas ウェブアプリのメモリ制限を超過する可能性があります。代わりに、「クラシック トゥイーン」を使うようにしてください。

WebAssembly

他の言語で書かれた既存のコードがあるデベロッパーの方には、WebAssembly（WASM）はおもしろい選択肢です。たとえば、C や C++ で書かれた既存のゲームがある場合、Emscriptenなどのツールチェーンを使って WebAssembly にコンパイルできます。Canvas ウェブアプリは、WASM コードを読み込んでインスタンス化することが可能です。すると、JavaScript のロジックから WASM の機能を呼び出せるようになります。

WebAssembly は、デベロッパーに低レベルの制御と高レベルのパフォーマンスを提供します。試しに、ガベージ コレクションを回避するように Rust to WASMをコンパイルしてみたところ、60 FPS の非常にスムーズなアニメーションを実現できました。

WASM を使うと、テキストの高速レンダリングと静的要素の表示に HTML を利用しつつ WASM アニメーションをオーバーレイさせ、両者の長所を共存させることができます。

動画

ゲームで動画アセットを使うと、高度な視覚表現を効果的に表示し、カットシーンのような魅力的な場面を作ることができます。

「その場で」生成するとコストが高すぎる視覚表現を使いたい場合、動画としてレンダリングしたアニメーションをウェブアプリの HTML メディア要素で再生することを検討します。これにより、表現力豊かな背景をとても効果的に実現できます。動的 DOM 要素やアニメーションと組み合わせることもできます。

Canvas では、アクティブなメディア要素は 1 つしか許可されず、video 要素を CSS でスタイル設定することはできません。

長期間継続する効果の場合、メディア要素の “loop” 属性を指定して動画をループさせることができます。ただし、自動ループを行うと、ループの終わりと次のループの始まりの間で遅延が生じる可能性があります。

この遷移をシームレスに行うには、Media Source Extensions（MSE）を使う必要があります。これによってメディア要素が拡張され、JavaScript で再生用のメディア ストリームを生成できるようになります。MSE を使うと、HTML5 の video タグのバッファに直接メディアのセグメントを渡すことができます。動画が永久にループし続け、ループ間で遅延が発生しないことを保証するには、JavaScript のコードを使って動画データのダウンロードとバッファリングを行う必要があります。

状態管理

ウェブアプリは、Interactive Canvas の sendTextQuery() API を使って Dialogflow エージェントのインテントを呼び出し、その状態をフルフィルメント ロジックと同期させます。この呼び出しはユーザーの音声応答と同じライフサイクルに従います。バックエンドに永続化する際の遅延を追加することもできます。

バックエンドに対して状態の更新を永続化するタイミングが重要になる場合、ウェブアプリがフロントエンドの JavaScript ロジックから直接 Cloud Firestoreなどの永続化 API を呼び出すことができます。

テスト

Chrome DevToolsを使ってウェブアプリのパフォーマンスとメモリ使用量をプロファイリングすることをお勧めします。PC のシミュレータで Action をテストする場合は、ウェブアプリを埋め込むために使われている iframe を探し、DevTools を使ってウェブアプリの DOM を調査します。
メモリや CPU の使用状況のプロファイリングには、DevTools が便利です。DevTools を使うと、コードのボトルネックを見つけてアニメーションの FPS を改善できます。
ゲームのリアルタイム FPS をトラックしてオーバーレイ表示させるなら、stats.jsもお勧めです。
パフォーマンスに満足できるようになったら、Interactive Canvas をサポートするすべての端末で Action をテストします。これが必要なのは、端末によって画面の比率やパフォーマンスが異なるためです。

次のステップ

Interactive Canvas で開発するゲームの種類によっては、さまざまな方法でスムーズなアニメーションや効果を実現できます。多少のテストとプロファイリングは必要になりますが、迫力のある楽しい Interactive Canvas ゲームを実現できるはずです。

Interactive Canvas を使ったゲームはまだ生まれたばかりなので、ぜひこの機会に実際に試してみて、HTML の力でできることを体験してください。

意見や質問を共有したい方は、 /r/GoogleAssistantDevから Reddit に参加してください。私たちのチームの詳しい最新情報を受け取るには、Twitter で @ActionsOnGoogleをフォローします。#AoGDevs を付けてツイートし、皆さんが作っているものについて教えてください。



Reviewed by Chiko Shimizu - Developer Relations Team

Google Maps Platform ベストプラクティス：最適化とパフォーマンス改善のヒント

October 10, 2019, 10:35 pm

≫ Next: Chrome 77：新しいパフォーマンス指標、新しいフォーム機能、オリジン トライアル中の機能など

≪ Previous: ウェブアプリを Interactive Canvas 向けに最適化する

$

0

0

この記事は、Google の Software Engineer である Travis McPhail による Google Maps Platform Blog の記事 " Google Maps Platform best practices: Optimization and performance tips" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


デスクトップ ブラウザ、モバイルウェブ ブラウザに関係なく、多くのユーザは、スムーズかつすばやく必要な情報を取得することができるウェブアプリを期待しています。これは、JavaScript 開発者にとって、パフォーマンス最適化が大きな課題の一つであることを意味しています。レスポンスの遅いサイトはユーザ離れを起こす一方で、レスポンスが速いサイトはユーザを惹きつけ、使い続けてくれるというわけです。地図や、その他の位置情報に基づく機能を提供するアプリも例外ではありません。このトピックに関して講演を行ったので、その際にお伝えしたヒントを改めてお伝えしましょう。


カスタムオーバーレイを使う


カスタムオーバーレイ は、地図上に展開される、カスタマイズされた地理空間データです。ユーザがドラッグまたはズームすると地図と連動して動きます。多くの開発者が、マーカーなど、自社の独自のデータを地図上に展開するため、この機能を使っています。具体的には、OverlayView.draw()メソッドを使用します。

<!-->MyOverlay.prototype = new google.maps.OverlayView();

/** @constructor */
function MyOverlay(map, ...) { ... };

MyOverlay.prototype.draw = function() { ... };

これは、カスタマイズされた地図を作成する上で適切な方法ですが、この方法を使う場合、ユーザがパンまたはズームするたびに、OverlayView.draw()メソッドを呼び出すことになります。すなわち、地図上に表示するコンテンツだけでなく、ベースの地図も都度描画されることになります。 カスタムオーバーレイの作成や更新のロジックが、CPU を大量に使いブロックする場合は、このことを念頭に置いておく必要があります。地図を再描画すると同時に、オーバーレイのコードも実行されることによって、全体として地図の表示が途切れがちとなり、表示が完了するまでの待ち時間が長くなる可能性があります。また、 draw() では、できる限り必要なコードのみを実行するようにしてください。地図描画に直接関係のないことはすべて事前に実行し、カスタマイズすべきオーバーレイの情報は、可能な限り軽量に保つことが重要です。


次の図は、地図の再描画と同時にカスタムオーバーレイを行う一例です。





ヒント：地図が動いていない状態で、コンテンツを追加または削除すれば、ユーザーエクスペリエンスを高めることができます。一つのベストプラクティスとしては、ドラッグする dragまたはドラッグ終了 dragend等のイベント発生を利用して、ユーザが地図を操作しているタイミングを知ることで、地図が再描画されている間、カスタムオーバーレイに変更を加えることを避けることができます。この方法は、地図にマーカーを追加したり削除する場合にも有効です。

次の図は、先の例に対して、ユーザの操作が完了するまで待った場合に、どのように見えるかを示した例です。





かなり改善されましたね。パフォーマンスが向上しただけでなく、ユーザが画面操作をしていない時に画面上にマーカーを表示することで、ユーザーエクスペリエンスが改善されました。

マーカーを使用する

パフォーマンスを維持しつつ地図にデータを追加するもう一つの方法は、マーカーを使用することです。マーカーは地図上に地点を特定するものです。初期設定では、地図に追加できるマーカーは、標準的な赤い丸印のピンですが、カスタマイズした画像を使うことも可能です。パフォーマンスを維持したまま、マーカーを使う方法を見てみましょう。

この例は、境界ボックス内で 1,000 か所の地理座標を生成したものです。

function initLocations(latMin, lngMin, latMax, lngMax, numPoints) {
  let latExtent = latMax - latMin;
  let lngExtent = lngMax - lngMin;
  let tmpLocations = new Array(numPoints);

  for (let i = 0; i < numPoints; i++) {
    tmpLocations[i] = {
        lat: Math.random() * latExtent + latMin,
        lng: Math.random() * lngExtent + lngMin};
    };
  }
  return tmpLocations;
}
...
let locations = initLocations(-33, 117, -22, 148, 1000);

次に、いくつかのマーカーを作成し、地図に追加します。そのマーカーには、独自の svg を指定しています。

function initMap() {
    // initialize the map
    let map = new google.maps.Map(document.getElementById('map'), {
      zoom: 3,
      center: {lat: -25.906174, lng: 132.409812},
    });

    // Add the markers to the map
    let markers = locations.map((location, i) => {
      return new google.maps.Marker({
        icon: './images/pin.svg',
        position: location,
        zIndex: i,
        map: map
      });
    });

    // Add event listeners to the markers
    markers.map((marker, i) => {
      marker.addListener('mouseover', () => {
          toggleIcon(marker, true);
      });
      marker.addListener('mouseout', () => {
          toggleIcon(marker, false);
      });
    });

    ...
  }

それでは、ユーザが地図を操作した場合に何が起きるかを見てみましょう。




ユーザが画面操作をしていない時やズームをした際に、レスポンスが遅れることに注意してください。次に、上記のコードスニペットに簡単な変更を加えます。「アイコン」プロパティでマーカーの設定を、ラスタ画像（この場合は png）に切り変えてみます。





いかがでしょうか、レスポンスは遅くなっていませんね。svg 画像の方がパフォーマンスが良い場合が多いものの、Google Maps Platform では、多数のマーカー（数百ほど）を全て一括で展開する際に、ラスタ画像のカスタマイズされたマーカーを表示するための特別な最適化を実施しています。したがって、地図上に多数のマーカーを表示する場合、パフォーマンスを向上させるためにラスタ画像の使用をおすすめします。


その他

今回、Maps JavaScript API を最適に利用するためのいくつかのヒントを紹介しました。しかし、これ以外にも多くの最適化の方法があります。例えば、多数のマーカーを表示する地図では、 マーカーのクラスタ化 は不可欠です。

Maps JavaScript API について、より詳しく知りたい方は、 こちらのドキュメントをご覧ください。さらに、Google Maps Platform に関する今後の計画について詳細は、こちらの動画でもをご覧いただけます。

· 

Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカルアカウントマネージャ

Chrome 77：新しいパフォーマンス指標、新しいフォーム機能、オリジン トライアル中の機能など

October 14, 2019, 10:51 pm

≫ Next: Google Maps Plarform を使って生態系に配慮した農業コミュニティを構築

≪ Previous: Google Maps Platform ベストプラクティス：最適化とパフォーマンス改善のヒント

$

0

0

この記事は Chromium Blog の記事 "Chrome 77 Beta: New performance metrics, new form capabilities, capabilities in origin trials and more" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの Chrome ベータ版チャンネル リリース（当時）に適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.comの一覧でご確認ください。2019 年 10 月 8 日の時点で Chrome 77 はすでに安定版です。

新しいパフォーマンス指標

最大コンテンツの描画 (Large Contentful Paint)

デベロッパーにとって、ウェブページのメイン コンテンツがどのくらい早く読み込まれ、ユーザーに表示されるかを測定することは必ずしも簡単ではありません。既存の指標の有用性は千差万別です。ラボ環境でしか測定できない指標もあれば、ユーザーが関心を持つコンテンツにはまったく関係ない指標もあります。下の例について考えてみましょう。これは、DevTools のパフォーマンス監査機能によるものです。最初のコンテンツが描画された時点では、ユーザーが操作できるコンテンツは何も表示されていません。



最大コンテンツの描画（Largest Contentful Paint）は、最大のコンテンツ要素をページのメイン コンテンツと見なし、それがユーザーに表示されたと思われるタイミングを利用して有用なデータを提供しようとするものです。

この新しい指標について、何をトラッキングしているのか、いつ報告されるのか、遅い場合にどうすれば改善できるのか、といった疑問を持つ方もいるでしょう。このような疑問への回答については、web.devの Large Contentful Paintをご覧ください。

最初の入力タイミング (First Input Timing)

PerformanceEventTiming インターフェースは、最初の個別のユーザー操作までの遅延に関するタイミング情報を提供します。ユーザー操作とは、キーダウン、マウスダウン、クリック、ポインタダウンとポインタアップの組み合わせのいずれかです。ポインタダウンはスクロールの開始である可能性がありますが、その場合はトラックされません。この機能は EventTiming API の一部ですが、応答性を計測して最適化するために重要な指標を提供することから、一足先に公開されます。

新しいフォーム機能

多くのウェブサイトでは、標準コントロールでは利用できない機能を追加したり、フォームのデザインに一致させたりするために、カスタムのフォーム コントロールが使われています。カスタム コントロールの欠点は、データを非表示（hidden）の <input>要素に格納しなければならないことです。

そこで、2 つの新機能によってカスタムのフォーム コントロールをサポートします。formdataイベントを使うと、非表示の <input>要素ではなく JavaScript を使ってフォームにデータを追加できます。この機能を使うと、サイト開発者がフォーム要素に formdataイベント リスナーを追加できるようになります。渡されるイベントには、送信されるデータを含む FormDataオブジェクトが含まれます。送信データの変更もできます。

formdataイベントでは、サイトは送信プロセスとやり取りするだけです。フォーム関連のカスタム要素を使うと、サイト制作者はビルトイン フォーム コントロールのように動作するカスタム要素を作ることができます。そのため、入力の検証やサーバーへのデータ送信といった機能を実現できます。

詳細およびサンプルコードは、web.devの More capable form controlsをお読みください。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、オリジン トライアル ダッシュボードをご覧ください。オリジン トライアル自体の詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。

ウェブ用の連絡先ピッカー

Contact Picker API は、新しいオンデマンド ピッカーです。これを使うと、ユーザーは連絡先リストのエントリを選択し、その詳細情報の一部をウェブサイトと共有できます。ユーザーは、共有したいときに共有したい情報のみを共有し、友だちや家族と簡単につながることができるようになります。詳細については、A Contact Picker for the Web をご覧ください。

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

Enter キーヒント

enterkeyhintコンテンツ属性は
<form>要素の列挙型属性で、仮想キーボードの Enter キーにどのアクション ラベル（またはアイコン）を表示するかを指定します。これにより、Enter キーの表示をカスタマイズできるようになり、ユーザーの利便性が高まります。この属性には、enter、done、go、next、previous、search、sendのいずれかを指定します。

document.domain のフィーチャー ポリシー制御

ドキュメント ドメイン ポリシーは、document.domain へのアクセスを制御します。デフォルトで有効になっていますが、無効にした場合は document.domainを設定しようとするとエラーがスローされます。

不安定なレイアウトの監視

Performance API に LayoutShiftインターフェースが追加されます。
これにより、デベロッパーが DOM 要素の画面上の位置の変化を監視できるようになります。

"referer" ヘッダー長の 4 kB 制限

refererヘッダーのサイズが 4 kB を超える場合、オリジンまで切り詰められます。
refererヘッダーが長すぎる場合、サーバーが意図しない動作をすることがあります。攻撃者は、ヘッダーの長さを制御して no-corsリクエストを生成する際に、よく refererを利用します。

registerProtocolHandler() の url 引数を http/https に制限

registerProtocolHandler()は、http または https スキーマの URL のみを受け入れるようになります。この API の目的は、たとえばエンドポイントが SMS メッセージなどを扱えるようにすることなので、ハンドラがデータ URL や blob URL などである場合はあまり意味をなしません。

Intl.NumberFormat の新機能

この変更により、測定単位、通貨と符号の表示ポリシー、指数表記と圧縮表記のサポートが追加され、Intl.NumberFormatが改善されます。

オーバースクロール時の動作の論理個別指定表記

論理寸法を通してオーバースクロール時の動作を制御する CSS flow-relativeプロパティが追加されます。flow-relativeプロパティは、コンテンツのフローに対して相対的に解釈されます。新しいプロパティは、overscroll-behavior-inlineと overscroll-behavior-blockです。

PerformanceObserverInit の buffered フラグ

observer.observe()に bufferedフラグが追加されます。これにより、PerformanceObserverが呼び出しの実行前に作成されたエントリを受け取れるようになります。

WebRTC

RTCPeerConnection.onicecandidateerror
incecandidateerror イベントが追加されます。このイベントは、WebRTC ICE 候補の収集失敗についての詳細情報を提供します。情報には、STUN（RFC5389）や TURN（RFC5766）で定義されているものが含まれます。

収集の失敗についての詳細を参照せずに ICE の接続の問題を診断するのは困難な場合があります。ICE 候補エラーのサポートは、接続の問題のトラブルシューティングやネットワークの診断を改善することを目的としています。

RTCPeerConnection.restartIce()
ICE の再起動をトリガーするメソッドが追加されます。これにより、WebRTC の再接続が試行されます。Chrome では、createOffer()に iceRestart引数を渡すことで、既にこの機能を利用できるようになっています。restartIce()はこのメソッドの 1 形態ですが、signalingStateにかかわらず動作します。

Service Worker

Service Worker を経由するリクエスト優先度の保持
リクエストが Service Worker に渡される際に、元々の優先度が保持されます。これまで、Service Worker を経由するリクエストは、すべて優先度「高」になっていました。つまり、レンダリングをブロックするスタイルシートが優先されず、逆に重要性の低いリソースが優先されていたことになります。

Service Worker がベーシック HTTP 認証をサポート
Service Worker によるリクエストであっても、HTTP 認証ダイアログ ボックスが表示されます。これにより、HTTP 401 レスポンスを受信するとネイティブのログイン ダイアログが表示されるようになります。

メディア セッションの停止アクション

MediaSession.setActionHandler()の呼び出しにおいて、MediaSessionAction として stopが追加されます。アクションは、一時停止や再生などの共通メディア関数に明確に結びつけられているイベントです。stopアクション ハンドラは、サイトが再生を停止し、必要に応じて状態をクリアすべきときに呼び出されます。GitHub でサンプルが公開されています。

Web Payments: 無効な "basic-card" データに対して TypeError をスロー

ベーシック カード支払いで無効な supportedNetworksまたは supportedTypesが指定されている場合、PaymentRequestコンストラクタが TypeErrorをスローします。

もう 1 つの Web Payments のアップデート項目については、サポートの終了と機能の削除をご覧ください。直近の Web Payments のアップデートの詳細については、W3C Payment API changes in Chrome 77 をご覧ください。

相互運用性の改善

ステップ タイミング関数 jump-start|end|both|none のサポート

いくつかの高度なステップ アニメーションがサポートされます。Firefox は、既に jump-*ステップ タイミング関数をサポートしています。ステップ タイミング関数 jump-both、jump-none、jump-start、jump-endは、2018 年にイージング関数仕様に追加されました。このうちの 2 つ、jump-startと jump-endは、startと endの別名です。その他の 2 つによって、不連続なステップが両方のエンドポイントにあるステップ関数や、どちらにもないステップ関数が実現できるようになるため、ステップ遷移の柔軟性が増します。これまで不連続なステップを持たせることができたのは、2 つのエンドポイントの片方だけでした。Chromium でサポートが追加されたことにより、クロスブラウザの相互運用性が向上します。

white-space: break-spaces

通常、保持されている空白の連続は改行せずに、行がはみ出します（CSS Text Module 仕様のトリミングと位置決めのルールに記載されています）。break-spacesプロパティに white-space値を使うと、これを改行させるように指定できます。

white-space: pre-wrapを使うと、テキストを途中で折り返しつつ、行中にある空白の連続を保持することができます。しかし、空白の連続が行末にあった場合、省略するかぶら下げるかどちらかになり、ボックス領域からはみ出す可能性があります。新しい値 overflow-wrap: break-spacesを使うと、テキストを折り返して空白の連続を保持することができます。これにより、スペースバーを押すイベントによって追加された空白の連続を適切に処理でき、必要に応じて改行が生成されるので、textarea要素や contenteditable要素にも便利です。また、改行関連の CSS プロパティ（white-space、word-break、overflow-wrap）の相互運用性を高めるための作業も続いています。この新しい値は、これを正確に実現するために定義されました。

サポートの終了と機能の削除

支払い方法の名称としてのカード発行者ネットワーク

supportedMethodsフィールドにカード発行者ネットワーク（例: "visa"、"amex"、"mastercard"）を指定した PaymentRequestの呼び出しのサポートが削除されます。

安全でないオリジンでの Web MIDI の使用のサポート終了

Web MIDI の使用は、特権なしの使用と、sysex パーミッションを持つ特権ありの使用の 2 種類に分けられます。Chrome 77 までは、後者の使用のみがユーザーにパーミッションを求めていました。セキュリティの懸念を緩和するため、sysex の使用にかかわらず、常にパーミッションがリクエストされるようになります。つまり、安全でないオリジンでは Web MIDI の使用が許可されなくなります。

WebVR 1.1 API のサポート終了

この API は Chrome で非推奨となり、WebXR Device API に置き換えられます。WebXR Device API は Chrome 78 に搭載される予定です。WebVR のオリジン トライアルは、2018 年 7 月 24 日に終了しました。

WebVR は Chrome においてデフォルトで有効になることはなく、ウェブ標準にも採用されませんでした。WebXR Device APIは、WebVR に代わる API です。Chrome から WebVR が削除されることで、WebXR の今後に集中できるようになり、WebVR のメンテナンス負荷もなくなります。また、今後のウェブベースの没入体験を構築するにあたり、Chrome は WebXR に注力していくことを再確認するものでもあります。この機能の削除は、Chrome 79 で行われる予定です。


Reviewed by Eiji Kitamura - Developer Relations Team

Google Maps Plarform を使って生態系に配慮した農業コミュニティを構築

October 14, 2019, 11:04 pm

≫ Next: プライバシー サンドボックスの可能性を検討する

≪ Previous: Chrome 77：新しいパフォーマンス指標、新しいフォーム機能、オリジン トライアル中の機能など

$

0

0

この記事は、有機農場を検索する地図ベースのサービスを提供する非営利組織 Worldwide Opportunities on Organic Farms, USA (WWOOF-USA) の Executive Director である Sarah Potenza による Google Maps Platform Blog の記事 " Worldwide Opportunities on Organic Farms uses Google Maps Platform to build communities that care about ecological farming" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

有機農業は、農業従事者が持続可能な形で食物を栽培することを可能とし、地球環境にやさしいと言われています。WWOOF-USA は、生態系に配慮した農業に興味を持つ人々のコミュニティ構築を支援するために、有機農場で働くことを希望する旅行者にそうした農場を紹介しています。訪問者には 1 日ないし 2 日間の労働と引き換えに、食事と宿泊場所が提供されます。WWOOF-USA は、1970 年代に設立された WWOOF 協会の米国における組織です。全米 50 州とヴァージン諸島、プエルトリコにある 2,134 の有機農場と連携しています。

WWOOF が発足した当時は、参加する有機農場のリストを冊子にして、年会費を支払う会員の自宅へ郵送していました。会員はその冊子を見て、どの農場で働くかを決めていたのです。冊子の印刷代や郵送代は高く、また、制作上の制限や郵送期間もあるため、参加する農場リストの最新の情報を冊子に反映できないこともありました。


しかしながら、インターネットの普及によって、これらの課題を解決できることに気づきました。それまでは考えられなかった方法で、人々に最新情報を直ちに届けることができるのです。WWOOF-USA は、地図をベースとしたウェブサイトを構築しました。これにより、会員は訪問したい農場をより容易に見つけることができ、各農場についてより多くの最新情報を得ることが可能となりました。また、このウェブサイトは新たな有料会員を獲得するためのマーケティングツールとしても有効に働いています。WWOOF への加入を検討する人に対して、有料会員になった場合にどれほど多くの農場を訪問できるかというメリットを伝える手段だからです。

我々は、ウェブサイトに地図や位置情報を追加するために、Google Maps Platform を選択しました。その理由は、Google Maps Platform が提供する API がバックエンド システムと簡単に連携することができたこと、最も包括的で正確な地図データを持っていたこと、地図がユーザ体験をもたらすインターフェースとして今後標準となると考えたからです。Maps JavaScript API、MarkerClustererライブラリ（注 :こちらでもご覧いただけます）および Geocoding APIを使って、会員が WWOOF に登録した全米各地の農場を閲覧、検索できるインタラクティブなウェブサイトを実現することができました。


サイト訪問者は、このページにアクセスして、訪問したい地域を拡大して、ホスト有機農場の位置を示すマーカーを見ることができます。滞在希望期間、農場の種類（野菜、果樹、ワイン用葡萄、乳業等）、すぐに訪問可能な農場、子どもやペットの同伴は可能か、などの検索条件を設定して、農場の候補を絞り込むこともできます。



マーカーをクリックすると、農場の概要、写真やそこに滞在した人のレビューを含む詳細情報が表示されます。会費を払って WWOOF 会員になった人だけが詳細情報を閲覧でき、非会員は見ることができません。農場の詳細情報の閲覧を会員限定にしたことは、ウェブサイト訪問者に WWOOF への加入を検討してもらうための効果的な宣伝にもなりました。すなわち、WWOOF 未会員に対して会員登録を強く勧める効果があったのです。

Google Maps Platform により、サイトの利便性は大いに向上しました。もし Google Maps Platform を使っていなければ、農場の静的なリストを掲示するだけとなり、地図上に表示した農場を閲覧、検索できる今の画面よりも、ユーザにとってはるかに魅力の薄いサイトとなっていたでしょう。Google Maps Platform を使ったおかげで、2018 年度のページ閲覧数は 800 万回を超えました。


さらに、Google Maps Platform を統合して以来、当サイトの有料会員数は、統合直後の 6,400 名から大幅に増えて、現在は 18,000 名以上です。

Google Maps Platform クレジット制度の適用を受けられたことは、 WWOOF の成長にとって不可欠でした。Google の非営利団体向けプログラムのもとで、Google Maps Platform クレジットを申請できました。そのおかげで会員に、手頃な価格で農場情報を提供することが可能となりました。この助成無くして、WWOOF のサイトで地図を閲覧する膨大な人数に対処することはできなかったでしょう。あらゆる非営利組織に、Google の非営利団体向けプログラムの利用を推薦します。Google Maps Platform クレジット および Google の非営利団体向けプログラムの詳細をご覧ください。


Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカルアカウントマネージャ

プライバシー サンドボックスの可能性を検討する

October 14, 2019, 11:53 pm

≫ Next: ジェスチャー ナビゲーション: エッジ ツー エッジへの対応

≪ Previous: Google Maps Plarform を使って生態系に配慮した農業コミュニティを構築

$

0

0

この記事は Justin Schuh - Chrome エンジニアリング ディレクターによる Chromium Blog の記事 "Potential uses for the Privacy Sandbox" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


先日 blog.google で、ある取り組みに関するビジョンについて説明しました。この取り組みは、プライバシーを強化するアーキテクチャによってウェブを進化させつつ、自由でオープンなエコシステムを支え続けることを目指すものです。このビジョンを実現するため、コミュニティ全体と共有、連携することを目的として、一連の説明資料を公開する作業に着手しています。

以下では、初期提案の各項目について概要を説明します。私たちは、この初期提案の全体をまとめてプライバシー サンドボックスと呼んでいます。

ユーザー情報

まず、現在の広告エコシステムでユーザー情報がどのように使われているかについて確認しましょう。そこから、プライバシー サンドボックスで使うプライバシー保護 API をどのように開発するかを考えることができます。

広告の選択

ブラウザは、共有する閲覧履歴をできるだけ少なくしつつ、サイト運営者が関連コンテンツを選んだり関連性の高い広告を表示したりできるようにしなければなりません。どうすればこれを実現できるかは、特に難しい課題の 1 つです。

私たちは、広告を、似たユーザーを集めた大きなグループに対して、ブラウザから個人情報を漏らすことなく配信する方法について考えています。この方法は、Chrome で匿名の診断データを集めるために 5 年近く使ってきた差分プライバシー技術をベースにしています。皆さんが Beyoncé やセーターベストが好きなグループに属しているとしても、そのグループに数千人の人が集まるまで、ブラウザがそのことを明かす必要はありません。この点が明らかになったのは、フェデレーション ラーニングなどの新技術のおかげです。

コンバージョンの測定

サイト運営者や広告主は、広告が実際にビジネスの拡大につながるかどうかを知る必要があります。売上が上がったなら、ユーザーにとって適切な広告だったことは明らかです。しかし、そうでないなら、コンテンツやカスタマイズ方法を改善してユーザーとの関連性を高める工夫をしなければなりません。そうすれば、ユーザーには興味がある広告が表示され、広告主も効果的に宣伝できるので、双方がメリットを得ることができます。

こういったユースケースのいくつかに対処する方法を評価する案は既に検討されており、Google と Apple の両方が公開しています。これらの案は、広告主にサイト間で特定のユーザーをトラッキングさせることなく、必要な測定を行うというニーズに対処する方法を検討する上での第一歩となります。

不正の防止

現在、ほとんどのサイト運営者には、不正行為を検知して防止したいというニーズがあります。不正行為の例として、不正取引や、広告主やサイト運営者から金銭をだまし取ろうとする嘘の広告活動があげられます。Google を含む多くの企業は、不正の検知と防止に取り組んでいます。広告会社や広告詐欺については、特にそれが言えます。

現在、合法的に詐欺と戦っているツールの中には、プライバシー セーフな仕組みの恩恵を受けた技術を活用したものがあります。その一例が CloudFlare が Tor ユーザーのために導入した PrivacyPass トークンです。現在、この技術は標準化の過程にあります。

サンドボックスの境界を保護

ウェブからある機能を削除すれば、デベロッパーは正規の道を選ぶのではなく、現在のシステムを動作させ続けるために回避策を見つけようとします。このことは、既に経験から明らかになっており、最近でも、他のブラウザが Cookie をブロックするために行った措置に対してこのような反応が見られました。そのようにして登場したのが、フィンガープリントのように、ユーザーにとって透過的でない新しい技術です。

フィンガープリントを使うと、ユーザーごとに異なるごくわずかな情報を知ることができます。たとえば、ユーザーがどんな端末をもっているか、どんなフォントをインストールしているかなどです。こういった小さなデータを組み合わせることで一意な識別子を生成でき、それを使えばウェブサイト間でユーザーを照合することも可能です。Cookie と違い、フィンガープリントはユーザーがクリアすることはできません。つまり、特定されることを嫌うユーザーでも、デベロッパーによるユーザーの特定を避けることはできません。私たちは、このような形でユーザーから選択肢を奪うのは間違いだと考えています。

5 月の I/O でも触れましたが、私たちはフィンガープリントを防止する対策を積極的に行っており、プライバシー予算と呼ぶものを実現することを提案しています。プライバシー予算の考え方によると、ウェブサイトはユーザー情報を得る API を呼び出すことができますが、ユーザーが匿名を維持できる十分な大きさのグループに絞り込まれた情報までに限られます。その後、さらに詳しい情報を得ようとして API を呼び出そうとすると、ブラウザが介入して呼び出しをブロックします。

プライバシー サンドボックス構築のための初期提案にも目を通していただけるとありがたく思います。これは壮大な計画であることは承知しています。他のブラウザやサイト運営者を含め、業界全体で連携した結果として改良、改善していくことが重要です。この点は、どんなに誇張しても誇張しすぎるということはありません。ぜひ皆さんの意見もお聞かせください。

Reviewed by Eiji Kitamura - Developer Relations Team

ジェスチャー ナビゲーション: エッジ ツー エッジへの対応

October 15, 2019, 4:04 am

≫ Next: コードからコミュニティへ: デベロッパーが DevFest を大切にする理由

≪ Previous: プライバシー サンドボックスの可能性を検討する

$

0

0

この記事は Chris Banes (Developer Programs Engineer) による Medium Blog の記事 "Gesture Navigation: Going edge-to-edge" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android Q では新しいシステム ナビゲーション モードが追加され、前の画面に戻る、ホーム画面に移動する、デバイスでアシスタントを起動する、などの操作をジェスチャーで行えるようになりました。

Android Q での新しいジェスチャーのデモ

システム ナビゲーション用ジェスチャー モデルに移行することにより、アプリが利用できる画面の領域が広がります。つまり、ユーザーの没入感がさらに高まるようなアプリを提供できるようになるとも言えます。
ただし、ユーザーは今後もほとんどのデバイスで、自分が使いたいナビゲーション モードを選択できます。3 つのボタン（戻る、ホーム、最近）による従来のナビゲーション モードがなくなることは当面ありません。このモードは、Android Q 以降を搭載するデバイスでも必須となります。
ジェスチャー ナビゲーションに関して行われた調査やジェスチャーを決定する過程については、Android システム UI 担当プロダクト マネージャーが投稿した以下のブログ記事に詳しく書かれています。

ジェスチャー ナビゲーションの裏話

今回の投稿は、デベロッパーがアプリでジェスチャー ナビゲーションに対応する方法を中心に紹介する短い連載の第 1 回です。この連載では以下のトピックについて取り上げます。
1.アプリのコンテンツを画面いっぱいに表示できるようになる、エッジ ツー エッジへの対応
2.システム UI と視覚的に重なった場合の対処方法
3.アプリのジェスチャーがシステム ジェスチャーと競合した場合の対処方法
4.よくあるシナリオと、それぞれの対応方法
それでは早速、アプリが「エッジ ツー エッジ」に対応する方法をご紹介します。

エッジ ツー エッジ

ここで使っている「エッジ ツー エッジ」という表現には、アプリのウィンドウを全画面に拡張することでユーザーの没入感を高められる、という意味が込められています。アプリがデフォルトで配置されるのは、上部はステータスバーより下、下部はナビゲーション バーより上の領域です（2 つのバーを合わせて「システムバー」と呼びます）。
エッジ ツー エッジに対応することで、アプリはシステムバーの背後に配置されるようになります。これは、アプリのコンテンツを引き立てて、さらに没入感の高いユーザー エクスペリエンスを提供できるようにするためです。
実際に「エッジ ツー エッジ」のアプリにするには、次の 2 点を考慮する必要があります。

ナビゲーション バー背後の描画

ジェスチャー ナビゲーションに対応するにあたり最初に考慮すべき最重要事項は、ナビゲーション バーの背後に描画することです。ナビゲーション バーは以前より小さく、そして目立たなくなっています。そのため、Android Q 以降で動作するアプリについては、より魅力的な最新の UX を実現できるよう、ナビゲーション バーの背後にもコンテンツを描画することを強くおすすめします。
Android Pie 以前を搭載したデバイスでアプリを実行する場合は、ナビゲーション バー背後の描画は必ずしも必要ではなく、どの方法が合理的かを判断したうえで対応していただいてかまいません。とは言え、必要なほぼすべての API は API 21 にさかのぼって機能する（つまり AndroidX が違いを処理する）ので、Android Pie 以前のデバイスに対応するために必要な追加作業の量は最小限で済みます。Pie 以前のデバイスでも、ナビゲーション バーの背後に描画すればユーザーの没入感を高められますが、必要な作業やテストの量を最小限に抑えるため、デベロッパーの裁量に委ねることにしています。

ステータスバー背後の描画

次は、画面上部にあるステータスバーについてです。アプリのコンテンツやレイアウトとの兼ね合いで、ステータスバーの背後に描画するほうが有意義である場合はそのようにすることをおすすめします。たとえば、幅いっぱいに表示される画像は、ステータスバーの背後に描画するのが適したレイアウトと言えます。この場合、デベロッパーは AppBarLayout などを使用して、画面上部に画像を固定します。

ステータスバーの背後に全幅の画像を配置したアプリの例

一方、上部にツールバーを固定していくつかの項目を並べる UI を作成している場合は、ステータスバーの背後に描画してもあまり意味はないかもしれません。また、Android Pie 以前を搭載するデバイスで実行するアプリについては、ナビゲーション バーの場合と同様に、ステータスバー背後の描画に対応するかどうかは完全に任意です。

実装

「エッジ ツー エッジ」の描画は、以下の 3 つのステップで実装します。

1. 全画面配置をリクエストする

最初のステップは、アプリを（Y 軸上で）システムバーの背後に配置するようシステムに伝えることです。そのためには、ビューの API setSystemUiVisibility() を使用し、いくつかフラグを設定します。該当するフラグは次のとおりです。（ソースはこちら）

この設定により、ビューはナビゲーション バー背後の全画面に配置されるようになります。

アプリがナビゲーション バーの背後で全画面に配置された状態

2. システムバーの色を変更する

アプリが全画面に配置されるようになったら、システムバーの背後にあるコンテンツが見えるように、システムバーの色を変更する必要があります。

Android Q

Android Q で動作するアプリの場合、システムバーの色を完全な透明に設定するだけです。（ソースはこちら）

Android Q では、どのナビゲーション モードでも、システムバーの要素（時間、アイコン、ドラッグ ハンドルなど）の視覚的保護はすべてシステムが処理するようになりました。つまり、デベロッパー側で対応する必要はありません。システムで行われる処理は、次の 2 種類のいずれかとなります。

動的な色調整

システムバーの要素は、システムバーの背後にあるコンテンツに応じて色が変化します。たとえば、ハンドルの背後に明るい色のコンテンツがあるときは、ハンドルは暗めの色に変わります。反対に、背後に暗い色のコンテンツがあるときは、明るい色に変わります。この処理は、「動的な色調整」と呼ばれています。

Android Q の動的な色調整

半透明スクリム

システムバーの背後に半透明のスクリムを適用する場合もあります。ただしこの処理は、アプリが targetSdkVersion を 29 と宣言した場合にのみ適用されます。アプリのターゲット バージョンが SDK 28 以前の場合は、この自動スクリムは表示されず、ナビゲーション バーは透明になります。

Android Q のボタン ナビゲーション モードでスクリムが適用された状態

この 2 種類の処理はいずれも、システムバーの要素が常に見えるようにするために適用されるものです。システムがどちらの方法を採用するかは、いくつかの要因によって決まります。スクリムが適用されるのは次の場合です。

• いずれかのボタンモード（2 ボタンまたは 3 ボタン）が有効になっている。
• ジェスチャー ナビゲーション モードが有効な状態に対し、デバイスのメーカーが動的な色調整を無効にしている。この理由としては、そのデバイスで色調整処理を行うとパフォーマンスが低下する可能性があることが挙げられます。

ジェスチャー ナビゲーション モードでスクリムが使用されている例

それ以外の場合は、動的な色調整が採用されます。上記の理由は現時点で当てはまるものであり、今後変わる可能性があります。

Android Q でシステムバーの保護を無効にする

システムバーの要素を自動的に保護する処理を必要としない場合、アプリのテーマで android:enforceNavigationBarContrast または android:enforceStatusBarContrast、あるいはその両方を false に設定することで、この機能を無効にできます。

Android Pie 以前

Android Pie 以前のデバイスでもエッジ ツー エッジ対応にする場合は、システムバーの要素を保護するために、システムバーの色を半透明に設定する必要があります。システムバーが暗い色のテーマの場合、不透明度 70% の黒のスクリムから試してみることをおすすめします。（ソースはこちら）

この不透明度は、背後に表示されるコンテンツに応じて調整してください。明るい色のテーマであれば、明るい半透明の色（例: #B3FFFFFF）に設定してもよいでしょう。

暗い色のテーマと明るい色のテーマで、それぞれに適したスクリムを使用した例

3. 視覚的な重なり

以上の対応が済んだ後に、アプリの重要なビューがシステムバーの背後に隠れてしまっていることに気付く場合があるかもしれません。3 番目の（つまり最後の）ステップでは視覚的な重なりを処理しますが、これについてはこちらのブログ投稿で解説します。

Posted by Yuichi Araki - Developer Relations Team

コードからコミュニティへ: デベロッパーが DevFest を大切にする理由

October 15, 2019, 9:53 pm

≫ Next: Chrome 78 ベータ版: 新しい Houdini API、ネイティブ ファイル システム アクセスなど

≪ Previous: ジェスチャー ナビゲーション: エッジ ツー エッジへの対応

$

0

0

この記事は Google Developers Blog の記事 "From Code to Community: Why developers call DevFest home" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


同僚の GDG リードと DevFest Coimbra について企画する Ricardo さん（左）

Ricardo Costeira さんは、ポルトガルの都市コインブラ在住のソフトウェア エンジニアで、昨年初めて DevFest に参加しました。DevFest は、デベロッパー コミュニティが主導する活動で、世界中の Google Developer Group によって開催されています。DevFest 2019 の開催を祝して、コードを書いていた Ricardo さんがどのようにコミュニティを見つけることができたのかを紹介しましょう。

1. DevFest のことはどこで知り、どうして参加しようと思ったのですか？

2018 年でコインブラに住んで 3 年目になっていましたが、ソフトウェア デベロッパーとして働いている職場以外の友人はいませんでした。私の熱意を理解してくれる人に会いたいと思っていたので、今までとは違うことをしようと決意しました。そして、どうすれば知見を持った開発者とつながることができるのかと考え、ソーシャル メディアを使い始めました。やがて、フィードに DevFest が表示されました。そのとき突然、このすばらしいイベントがコインブラで行われ、業界のリーダーたちが集まり、セッションが行われ、とてもクリエイティブな体験できることを知りました。コミュニティへの参加をこれほど楽しみに思ったことはありません。すぐにチケットを手に入れました。

2. 初めての DevFest はどんな場所でしたか？

とても爽快で、この世のものとは思えませんでした。最初に会場に入ったとき、そこにいた人 たちが何年も前からの知り合いのように声をかけてくれました。思いっきり笑顔で笑い合い、まわりの人はみんなとても親切でした。かなり内気で人付き合いが苦手な性格だった私が「ここは自分の居場所だ、わが家なんだ」と感じたので、驚きました。その日の夜から、次に参加できるイベントを探していました。その後、2 つのイベントに参加し、6 つ以上のイベントに登録し、今は GDG リードになりました。つまり、すっかりはまってしまったのです。

いったいどうしてこんなに変わってしまったのでしょうか。DevFest は、私の個性を進化させてくれたのだと実感しています。今は、コミュニティの一部でありたいと思っています。これまでの人生にはなかった感覚です。

「かなり内気で人付き合いが苦手な性格だった私が『ここは自分の居場所だ、わが家なんだ』と感じたので、驚きました」

3. DevFest 2018 の中で、今年も体験したいと思っていることは何ですか？
さまざまなブースです。DevFest Coimbra には、いろいろな会社の人と話せるブースがあります。家のすぐそばに成長できるチャンスがこんなにもあることがわかり、興奮します。私の場合、ポルトガルが急速に拡大していること、そして有能な人と話すために非常に多くの会社が DevFest にやってくるのを見るのが楽しいですね。このような関係を作っておけば、自分にふさわしいチャンスを見つけようとするとき、違った結果になるはずです。


4. まもなく DevFest 2019 が開催されます。一番楽しみにしていることは何ですか？
新しい参加者を刺激することです。最近運営スタッフになったので、新しい参加者の方にも、私が初めて DevFest の会場に入ったときのように感じてもらえることを楽しみにしています。同僚の GDG リードと一緒に、みんなで心を込めて参加者をお迎えするための活動を行う中で、そのように感じています。


5. DevFest 2019 に参加する皆さんへのアドバイスをお願いします。
ぜひ声をかけてください。それだけでどんなことが起こるでしょうか。きっと驚くと思います。DevFest は、ただの講演やワークショップではありません。大事なのは人なのです。このコミュニティでは、外向的な人も内向的な人も理解され、どちらも温かく迎えてもらえます。つまり、どんな人でも、どんなコードを書いていても、皆さんの居場所はここにあります。

「DevFest は、ただの講演やワークショップではありません。大事なのは人と人の繋がりなのです」

お近くの DevFest イベントを探しましょう。コミュニティに参加し、他のデベロッパーからクラウド、Android、Flutter、機械学習などについて学びたい方は、devfest.withgoogle.comをご覧ください。


#DevFest #Community


Reviewed by Takuo Suzuki - Developer Relations Team

---

Chrome 78 ベータ版: 新しい Houdini API、ネイティブ ファイル システム アクセスなど

October 16, 2019, 1:04 am

≫ Next: Google Maps Platform と deck.gl を使った高性能なデータの視覚化

≪ Previous: コードからコミュニティへ: デベロッパーが DevFest を大切にする理由

$

0

0

この記事は Chromium Blog の記事 "Chrome 78 Beta: a new Houdini API, native file system access and more" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome Beta チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.comの一覧でご確認ください。2019 年 10 月 7 日の時点で Chrome 78 はベータ版です。

CSS のプロパティと値

CSS Properties and Values API Level 1 により、CSS 変数はさらに力を発揮するようになります。変数を完全なカスタム プロパティとして登録できるので、特定の型であることを常に保証できます。また、デフォルト値を設定したり、アニメーションさせたりすることも可能です。

例として次のイメージをご覧ください。



ここでは、CSS のカスタム プロパティを使って色を変化させています。この変化は新しい API を使わなければ実現できないだけでなく、型安全でもあります。詳細およびこのイメージを生成するために使ったコードについては、Houdini の新しい API を使ったスマートなカスタム プロパティをご覧ください。

ネイティブ ファイル システム

オリジン トライアル中の新しい Native File System API を使うと、ユーザーのローカル端末にあるファイルを操作できます。これにより、IDE、写真や動画のエディタ、テキスト エディタなどの強力なウェブアプリを構築できるようになります。ユーザーがアクセス権を与えると、ウェブアプリはこの API を使ってユーザーの端末にあるファイルやフォルダを直接読み取ったり保存したりできるようになります。この処理は、すべてプラットフォーム独自のファイルを開くまたはファイルを保存するダイアログ ボックスを通して行われます。下のイメージは、Mac でファイルを開くダイアログ ボックスを使っているウェブページを示しています。



詳細を知りたい方、サンプルコードやテキスト エディターのデモアプリを見たい方は、Native File System API: 簡単にローカル ファイルにアクセスするをご覧ください。

登録に関する情報や、本リリースの他のオリジン トライアルのリストについては、オリジン トライアルのセクションをご覧ください。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。上記の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録したい方は、オリジン トライアル ダッシュボードをご覧ください。オリジン トライアル自体の詳細を知りたい方は、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。

SMS Receiver API

ウェブサイトでは、SMS メッセージでワンタイム パスワードを送り、それをフォームに手入力（またはコピーして貼り付け）してもらうことで電話番号を検証することがあります。ネイティブ プラットフォームはプログラムから SMS メッセージにアクセスする API を提供しているので、ユーザーはフォームを手で操作する必要はありません。
SMS Receiver APIを使うと、ユーザーの電話に配信された SMS メッセージで明示的にオリジンに宛てられたものに対し、（特別なフォーマット規約を通して）ウェブサイトからのアクセスが可能になります。

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

INPUT/TEXTAREA プレースホルダのデフォルト スタイルに不透明度を適用

::placeholder のデフォルト スタイルを #757575から rgba(0, 0, 0, 0.54)に変更します。

ページのアンロード時にポップアップを許可しない

window.open()メソッドを使ってアンロード時に新しいページを開くことができなくなります。ポップアップ ブロッカーは既にこれを禁止していますが、ポップアップ ブロッカーが有効になっているかどうかにかかわらず、禁止されるようになります。現在のところ、企業は AllowPopupsDuringPageUnloadポリシーフラグを使ってアンロード中のポップアップを許可することができます。このフラグは、Chrome 82 で削除される予定です。

バイト単位の更新チェックをすべての Service Worker の importScripts() リソースに拡大

importScripts()でインポートされる Service Worker スクリプトでバイト単位のチェックが有効になります。現在、Service Worker が更新されるのは、Service Worker のメイン スクリプトが変更された場合のみです。この動作は最新の仕様に準拠していません。また、デベロッパーは、インポートしたスクリプトの URL にハッシュを追加するなどの回避策を使う必要があります。

Web Socket の高速化

PC で Chrome 78 の WebSocketオブジェクトを使う場合、ArrayBufferオブジェクトのダウンロード速度が向上します。私たちのテストでは、以下のように改善されています。結果はネットワークのスピードやハードウェアに依存するので、環境によって異なる場合があります。

• Linux: 7.5 倍高速
• Windows: 4.1 倍高速
• Mac: 7.8 倍高速

マスク可能アイコン

Chrome 78 では、マスク可能アイコンのサポートが追加されます。ウェブ デベロッパーは、マスキングされる前のアイコンを指定して icon オブジェクトに "purpose": "maskable" を追加できるようになります。マスク可能アイコンには、108dp のアイコンを使うことを推奨します。詳細については、CSS Tricks の マスク可能アイコン: PWA で Android のアダプティブ アイコンを使うをご覧ください。

オートフィルされる支払い手段に対する hasEnrolledInstrument() の制限を強化

有効期限内のカードと請求先住所を要求することにより、取引の際の認証を改善します。これにより、オートフィル データの質が向上し、PaymentRequest.hasEnrolledInstrument()が true を返す確率が高くなります。また、オートフィル データを使って取引を行う際のユーザー エクスペリエンスが改善されます。

PaymentResponse.prototype.retry()

支払いの応答データに問題がある場合（配送先住所が私書箱である場合など）、PaymentResponseインスタンスの retry()メソッドを使ってユーザーに支払いのやり直しを求めることができるようになります。

不透明度のパーセント表記

不透明度関係のプロパティで値のパーセント表記が可能になります。具体的には、opacity、stop-opacity、fill-opacity、stroke-opacity、shape-image-thresholdが対象になります。たとえば、opacity: 50%は opacity: 0.5と同じ意味になります。これにより、整合性と仕様への準拠性が向上します。rgba()関数は、rgba(0, 255, 0, 50%)などの alpha 値のパーセント表記に既に対応しています。

PaymentRequest.onshippingaddresschange イベントでの住所の間引き

ShippingAddressChange イベントから販売者のウェブサイトに共有する配送先住所の詳しい情報を間引きます。PaymentRequest.onshippingaddresschange は送料や税金などを踏まえて支払金額を調整できるよう、ユーザーが選択した配送先住所を販売者に渡します。この時点で、ユーザーは取引を完全に確定させてはいないため、販売者に返す情報はできる限り少なくすべきです。これにより、配送先住所から recipient、organization、addressLine、phoneNumberが削除されます。通常、これらの情報は送料や税金の計算には不要です。

シーク

seektoアクションにメディア セッション アクション ハンドラが追加されます。アクション ハンドラは、一時停止や再生などの共通メディア関数に明示的に結びつけられているイベントです。seektoアクション ハンドラは、再生時間を特定の時間に移動させる場合に呼び出されます。

User Timing L3

既存の User Timing API を拡張し、2 つの新しいユースケースに対応します。

• デベロッパーは、performance.measure()および performance.mark()にカスタム タイムスタンプを渡せるようになります。これにより、任意のタイムスタンプ間の計測を行うことができます。
• デベロッパーは、performance.mark()および performance.measure()で任意のメタデータを報告できるようになります。これにより、標準化された API で分析用の高度なデータを提供できます。

サポートの終了と機能の削除

ページを離れる際の同期 XHR を許可しない

ユーザーがページを移動するまたは閉じることによってページを離れる際に、同期 XHR が許可されなくなります。これは、以下のイベントに適用されます。

• beforeunload
• unload
• pagehide
• visibilitychange

ページがアンロードされるタイミングで確実にサーバーにデータを送信するには、sendBeacon()または Fetchkeep-aliveを使うことを推奨します。

現在のところ、企業ユーザーは AllowSyncXHRInPageDismissalポリシーフラグを使ってページ アンロード時の同期 XHR リクエストを許可できます。デベロッパーは、オリジン トライアル フラグ allow-sync-xhr-in-page-dismissalを使って同じことができます。これは暫定的な「オプトアウト」方法です。このフラグは Chrome 82 で削除される予定です。

XSS Auditor

XSS Auditor は Chrome から削除されました。XSS Auditor を使うと、サイト間で情報がリークされる可能性があります。また、Auditor をバイパスする仕組みもよく知られています。

Reviewed by Eiji Kitamura - Developer Relations Team

Google Maps Platform と deck.gl を使った高性能なデータの視覚化

October 16, 2019, 1:28 am

≫ Next: Google Maps Platform の新しいオートコンプリート機能

≪ Previous: Chrome 78 ベータ版: 新しい Houdini API、ネイティブ ファイル システム アクセスなど

$

0

0

この記事は Google の Developer Advocate である Alex Muramoto による Google Maps Platform Blog の記事 " High-performance data visualizations with Google Maps Platform and deck.gl" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google マップのエンジニアリングチームをリードする Travis McPhail は 今年の Google I/Oにおいて、Google Maps Platform 上で高いパフォーマンスと拡張性を持ったアプリを構築するため　Maps JavaScript API上での deck.glのサポートを発表しました。それ以降、世界中のデベロッパーのみなさんに、deck.gl がウェブ地図にもたらす可能性についてお伝えしてきました。みなさんからの熱狂的な反応をうれしく思っています。deck.gl とは何か、まったく初耳という方へ、この記事では、deck.gl の概要をお話します。

deck.gl とは？

vis.glのフレームワーク スイートの一部である deck.gl は、各種の高性能で美しいデータ視覚化をウェブ環境にもたらすことができるオープンソースのフレームワークです。このフレームワークを使ってどのようなことができるのか、deck.gl 関連文書から抜粋します。

• 大量のデータセットの取扱いと効率の良い更新
• インタラクティブなイベントハンドリング（大量のデータセットから1点を抽出するピッキングなど）
• 地図の投影法、背景地図との重畳
• 実証済みで十分にテストされた各種サンプルデータ
• 新たなレイヤーの作成や既存レイヤーのカスタマイズが容易

なぜ deck.gl なのか？

データ視覚化において多くのウェブ開発者が直面する課題の一つが、極めて大量のデータセットを、効率良く取り扱わなければならないということです。開発者からは、もはや何百ではなく、数万、数十万、数百万点ものデータポイントの展開を図らなければならないという声も上がっています。

シングルスレッドのイベントループ モデルである JavaScript は、大量データの取り扱いや 3D 画像の描画といった、重いコンピュータ処理にはあまり適していません。この弱点を克服するため、deck.gl は非同期でユーザーのコンピュータの GPU にアクセスを可能にする WebGLライブラリを使います。すなわち、大量のデータを処理する負担を、ブラウザから、この種の作業により適しているハードウェア内部に移行させるわけです。その結果、数百万ものデータポイントを迅速に処理し、とても美しいデータ可視化を実現できるのです。

deck.gl はどのように機能するのでしょうか？

deck.gl は、Maps JavaScript API が提供する OverlayView を利用し、地図上にレイヤーとして重ねて、データを視覚化します。ユーザーが地図を左右上下に動かしたりズームさせる時でも、deck.gl の視覚化レイヤーは、ユーザーが日頃使い慣れているグーグルマップでのユーザー体験と同じような、背景地図と完全に同調した動きが可能です。



deck.gl のレイヤーを使ったアプローチによって、複合的効果を得るために、地図の上に複数の視覚化した情報のレイヤーを追加することも可能です。それを実行した例が以下の図です。それぞれ独立した 2 つのデータセットを散布図レイヤーとして重ね合わせることで、一枚の主題図を作成しました。

複合散布図レイヤーの例


deck.gl は、レイヤーの属性やデータへの変更に基づいて、迅速に図的表現を更新できるリアクティブプログラミングモデルを使用しています。これはどういう意味でしょうか？具体例はたくさんありますが、アニメーション化されたデータの視覚化がその一例です。以下の動画は、Maps JavaScript API の経路検索サービスの結果を表示する例です。これは deck.gl の Trips Layerを使ってアニメーション化したものです。

使ってみましょう

サンプルや deck.gl 関連文書をご覧いただき、Maps JavaScript API と deck.gl を使って何が実現できるかを理解しましょう。Google の GitHubには、サンプルアプリのソースコードおよび事例を掲載しています。deck.gl チームは、期待されるパフォーマンスおよび最適化の技法についても優れた記事も書いており、こちらでご覧いただけます。

次回は、 deck.gl を初めて Google Maps Platform と共に使う方のために、わかりやすいチュートリアルをお届けします。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やご意見はページ右上の「お問い合わせ」より承っています。




Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカルアカウントマネージャ

Google Maps Platform の新しいオートコンプリート機能

October 16, 2019, 6:51 am

≫ Next: ジェスチャー ナビゲーション: 視覚的な重なりの処理

≪ Previous: Google Maps Platform と deck.gl を使った高性能なデータの視覚化

$

0

0

この記事は、Google Maps Platform の Software Engineer である Mike McCreavy による Google Maps Platform Blog の記事 " New Autocomplete features in Google Maps Platform help your users make faster decisions" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

多くの企業が、ユーザーが探したい場所を正確にすばやく見つけるのに役立つ Google Maps Platform のオートコンプリート（入力補完）機能を活用しています。一方で、似たような検索結果が複数得られた場合に、その精度をさらに高めるために何かできるのではないかという要望も耳にします。今回は、ユーザーが探している場所をより簡単に選択し、迅速な意思決定を行えるよう、そして効率の良い方法で日々の用事を済ませられるように改良した新しいオートコンプリート機能をご紹介します。

追加のプレイスタイプ

ユーザーが関心を持っている場所を似通ったものの中から明確に区別できるように、既存のオートコンプリートを拡張して、該当するすべてのプレイスタイプを返すようにしました。新しいオートコンプリート機能は、レストラン、医療サービス、礼拝所、金融機関など、追加のプレイスタイプを返すことができます。これらの追加のプレイスタイプを使用することで、たとえば、公園、ショップ、介護施設、その他のビジネス用にそれぞれカスタムアイコンを定義して、検索結果を視覚的にわかりやすくできます（注:次の図は、東京で、タイプが”施設”で、”na”から始まる場所の検索を行った時の表示例です。左側（Example 1）が以前の表示で、結果一覧のアイコンはすべて同じ表示です。右側（Example 1a）が追加のプレイスタイプを利用した場合で、タイプごとに異なるアイコンを表示することができます）。

より多くのコントロールをカスタマイズ

追加のプレイスタイプを使用することで、ユーザーにとって最も関連性の高い結果のみを提示可能となります。実際にこれを実現するためには、オートコンプリートの戻り値で返される追加のプレースタイプを使用することで、アプリまたはサイトの要件に合致した、適切な条件で結果を抽出・結合できるでしょう。

たとえば、旅行サイトの場合、検索結果のホテルの周辺にあるレストランやショッピングの場所の結果のみを返すように選択できます。不動産サイトの場合、物件の周辺にある学校、公園、食料品店のみを表示するように選択できます。

直線距離

似通った場所を区別できるようにして、すばやく迷わずに適切な場所を選択したいという要望も耳にします。たとえば、ユーザーがサンフランシスコのダウンタウンを訪れていてコーヒーショップを探しているとします。検索の結果、同じ名前のカフェが 5 か所、検索エリア内にあるということは起こりえることです。そのエリアについて詳しくなければ、ユーザーが名前と住所だけでカフェを選ぶのは難しいでしょう。

そこで、より良いユーザーエクスペリエンスを提供できるよう、ユーザーが選択した場所から検索結果までの直線距離を提供する新しいオートコンプリートフィールドを設けました。直線距離を提供することで、ユーザーは同じ名前を持つ複数の場所をより適切に区別し、探している場所を正確にすばやく見つけることができます。たとえば、ユーザーがサイトで「Joe's Coffee Shop」と入力して複数の「Joe's Coffee Shop」カフェがリストアップされたときに、それぞれのカフェがユーザーの現在地からどれだけ離れているかを示すことができるのです。こうして、検索結果にある各カフェの違いをより簡単に認識し、適切なものを選択できます（注:次の図は、サンフランシスコで、”osh”から始まる施設を検索する例です。 左側（Example 2）が以前の表示です。直線距離の表示は無く、同じ名前を有する複数の場所を区別しにくいことがわかります。右側（Example 2a）は直線距離を追加した表示であり、左側よりも場所の区別がしやすい表示となっています。）

現在、この直線距離フィールドは Places APIでウェブサービスとして利用できます。 Android、iOS、JavaScript の Places SDK への追加作業は現在開発を進めています。


ユーザーにとって有益であり、旅行、不動産、ライドシェアリング、配送など、多くの業界で優れたエクスペリエンスを構築できるよう、今回新たに開発したオートコンプリート機能についてご紹介致しました。ぜひ試していただき、 Issue Trackerに課題やフィードバックなどご報告ください。また、@GMapsPlatformにツイートして皆さんの開発の様子をお聞かせください。我々は、開発者の皆さんが Google Maps Platform で素晴らしいものを開発されるお手伝いをするために日々努力しています。今回ご紹介した新機能を使って何を構築されるのか、楽しみにしています。



Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やご意見はページ右上の「お問い合わせ」より承っています。


Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカルアカウントマネージャ

ジェスチャー ナビゲーション: 視覚的な重なりの処理

October 17, 2019, 12:05 am

≫ Next: AMP のプリレンダリングでスピードアップ

≪ Previous: Google Maps Platform の新しいオートコンプリート機能

$

0

0

この記事は Chris Banes (Developer Programs Engineer) による Medium Blog の記事 "Gesture Navigation: Handling visual overlaps" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今回は、ジェスチャー ナビゲーションに関する連載の第 2 回です。他の回を見逃した方は、こちらからご覧になれます。

ジェスチャー ナビゲーション: エッジ ツー エッジへの対応

本連載の第 1 回では、アプリを「エッジ ツー エッジ」に対応させる方法をご紹介しました。ただしこの方法では、アプリのビューの一部がシステムバーの背後に隠れてしまい、ユーザーから見えなくなる場合があります。そこでこの投稿では、インセットを使用して、こうしたビューをシステムバーから離す方法を説明します。
この投稿では、「システム UI」と呼ばれる要素についても取り上げます。これは、システムが提供する画面上の UI の総称で、たとえばナビゲーション バーやステータスバー、通知パネルなどが該当します。

インセット

「インセット」と聞いて思わず尻込みした Android デベロッパーは、おそらく Android Lollipop の頃、ステータスバーの背後に描写しようとした経験があるのではないでしょうか。たとえば、このトピックに関するだいぶ前の StackOverflow の質問は、驚くほど多くの閲覧数を集めています 😲。
インセットは、画面のどの部分がシステム UI（ナビゲーション バーやステータスバーなど）と交差するかを表します。交差とは、単にコンテンツの上に表示されることを意味する場合もありますが、システム ジェスチャーに関係することもあります。インセットを使用することで、たとえば特定のビューを端から離すなどのようにして、重なり合いを避けることができます。
Android では、インセットは WindowInsetsクラス（AndroidX では WindowInsetsCompat）で表されます。Android Q には、アプリのレイアウト時に考慮すべき 5 種類のインセットがあります。どのインセットを使用するかは状況に応じて異なります。それぞれのタイプについて詳しく見ていきましょう。

システム ウィンドウ インセット

メソッド: getSystemWindowInsets()
システム ウィンドウ インセットは、現在最もよく使用されているインセットです。API 1 以降、さまざまな形式で存在するこのインセットは、システム UI が（Z 軸上で）アプリの上に表示されるときは常にビュー階層にディスパッチされます。代表的な例はステータスバーとナビゲーション バーですが、画面キーボード（IME）もこれに該当します。
アプリでシステム ウィンドウ インセットを使用する例を見てみましょう。ここで設定している FloatingActionButton（FAB）は、画面の下隅に 16 dp の余白（ガイドラインの仕様どおり）をとって配置されます。（ソースはこちら）

エッジ ツー エッジ対応に変換する前の Google I/O アプリの FAB

前回の投稿のステップ 1 と 2 を完了すると、ビューは下図のようにナビゲーション バー背後にまで広がって配置されるようになります。

全画面配置をリクエストした後の Google I/O アプリの FAB

このように、カンファレンスのスケジュール リストがナビゲーション バーの背後にまで拡張された状態は、ユーザーの没入感を高めるのに効果的です ✔️。リストとグリッドの処理方法については、後日別の投稿で説明します。

ところで、この例を改めて見てみると、FAB の一部が隠れてしまっているため、ユーザーがビューを操作（タップ）できない可能性があります。この種の視覚的な重なりは解消しなければなりません 🚫。上の図のように、デバイスがボタン ナビゲーション モードに設定されているときはバーが高くなるため、対応が必要なことはより明らかです。ジェスチャー ナビゲーション モードで動的な色調整が行われる場合は特に問題ありませんが、半透明スクリムに切り替わる可能性が常にあることを覚えておく必要があります。半透明スクリムになると、操作できなくなる場合があるためです。

この機会にすべてのナビゲーション モードでアプリをテストしておくことをおすすめします。

では、視覚的な重なりはどのように処理すればよいのでしょう。そこで出番となるのがシステム ウィンドウ インセットです。このインセットはビュー階層上のどの位置にシステムバーが配置されるかを表すので、その値を使用して、システムバーからビューを遠ざけることができます。

上の例では、FAB が下端と右端の近くに配置されています。そこで、systemWindowInsets.bottom および systemWindowInsets.right の値を大きくしてビューの下端と右端の余白を広くすることで、ナビゲーション バーから離すことができます。
この設定を適用すると、次のようになります。

これを正確に実装する方法については、この投稿の後半で詳しく説明します。

つまり、システム ウィンドウ インセットは、クリック可能なビューがシステムバーと重なって隠れてしまわないよう、そのビューを移動またはパディングする場合に活用できます。

タップ可能要素インセット

メソッド: getTappableElementInsets()
次に紹介するのは、Android Q で新たに追加されたタップ可能要素インセットです。前述のシステム ウィンドウ インセットとよく似ていますが、こちらはナビゲーション バーの表示の変化に対応します。
実は、「タップ可能要素インセット」は無視して、代わりに「システム ウィンドウ インセット」を使用する方が便利です。次の「ジェスチャー インセット」にスキップしてかまいませんが、詳しく知りたい方は引き続きお読みください。🕵️

タップ可能要素インセットでは、クリック可能（タップ可能）なビューに適用される最小限のインセットを定義します。ここでの最小限とは、このインセットの値ではシステムバーと重なる部分が引き続き存在する場合があることを意味します。この点で、システムバーとの重なりを常に回避するシステム ウィンドウ インセットとは異なります。
FloatingActionButtonの例を使って、2 つのインセットの値の違いを確認しましょう。

ピンク = ナビゲーション バーの領域。緑 = 下の余白に各インセットを指定した FAB の領域。

なお、ナビゲーション バーのサイズは変化するので、上の表の値はハードコードせず、インセットを使用してください。

「タップ可能要素インセット」と「システム ウィンドウ インセット」は、デバイスがボタン ナビゲーションに設定されているときは同様に機能することがわかります。違いが現れるのは、デバイスがジェスチャー ナビゲーションに設定され、かつ色調整が有効になっているときです。この状態ではナビゲーション バーは透明です。つまり、タップ可能なビューは理論上ナビゲーション バー内に配置可能であることから、下端の値が 0 になっています。

ただし、インセットではビューの配置場所を考慮しないため、タップ可能要素インセットを使用すると理論的に次のような結果になる可能性もあります。

これでは、ビューがナビゲーション バーに近過ぎて、ユーザーにとって紛らわしくなり適切とは言えません。

実際のところ、タップ可能要素インセットを使用できる状況でも、代わりに「システム ウィンドウ インセット」を使用した方がよい場合がほとんどです。

ジェスチャー インセット

メソッド: getSystemGestureInsets()および getMandatorySystemGestureInsets()
次に紹介するシステム ジェスチャー インセットも、Android Q で新たにプラットフォームに追加されたインセットです。ご存じのとおり、Android Q では新しいジェスチャー ナビゲーション モードが導入され、ユーザーは次の 2 種類のタッチ ジェスチャーでデバイスを操作できるようになりました。

1. 画面の右端または左端から横にスワイプすると、「戻る」機能がトリガーされます。
2. 画面の下端から上にスワイプすると、ホーム画面または最近使ったアプリを表示できます。

Android Q のジェスチャー ナビゲーションのデモ

システム ジェスチャー インセットは、システム ジェスチャーがアプリのタッチ操作より優先されるウィンドウの領域を表します。ところで、先ほど紹介した方法は 2 つありました。これは、システム ジェスチャー インセットが実際に 2 種類あるためです。すなわち、すべてのジェスチャー領域を含むインセットと、そのサブセットである必須システム ジェスチャー インセットです。

システム ジェスチャー インセット

1 番目のシステム ジェスチャー インセットについて説明します。このインセットには、システム ジェスチャーがアプリのタッチ操作より優先される画面上の領域全体が含まれます。Android Q では下の図のように、下のインセット（ホーム表示ジェスチャー用）と左右のインセット（戻るジェスチャー用）が設定された状態になります。

          0
   +--------------+
   |              |
   |  システム    |
40 | ジェスチャー |  40
   | インセット   |
   |              |
   +--------------+

          60

では、デベロッパーがシステム ジェスチャー インセットを使用するのはどのような場合でしょうか。このインセットはシステム ジェスチャーが優先される場所を表します。つまり、このインセットを使えば、スワイプ操作が必要なビューの位置をあらかじめ決めておくことができます。
システム ジェスチャー インセットの使用が適している例としては、下部のシート、スワイプ操作を使用するゲーム、カルーセル（ViewPager）などが挙げられます。一般に、このインセットは、スワイプ可能なビューを端から離れた位置に移動またはパディングする場合に使用します。

必須システム ジェスチャー インセット

必須システム ジェスチャー インセットはシステム ジェスチャー インセットのサブセットで、アプリによって除外できない（つまり「必須」の）領域のみが含まれます。詳しくは次回のブログ投稿（ジェスチャーの競合への対処方法の回）で説明しますが、ここではまず、アプリで画面の特定の部分からシステム ジェスチャーを排除できるということを覚えておいてください。

必須システム ジェスチャー インセットは、システム ジェスチャーが必須であり常に優先される画面の領域を表します。現在 Android Q で必須の領域は、画面下部のホーム表示用ジェスチャー領域のみです。ユーザーがいつでもアプリを終了できるようにするため、必須の領域となっています。
Android Q デバイスのジェスチャー インセットの一例を挙げるとすると、次の図のようになります。

          0                              0
   +--------------+               +--------------+
   |              |               |    必須      |
   |  システム    |               |  システム    |
40 | ジェスチャー | 40          0 | ジェスチャー | 0
   | インセット   |               |  インセット  |
   |              |               |              |
   +--------------+               +--------------+
          60                             60

システム ジェスチャー インセットでは左右と下部にインセットが設定されていますが、必須システム ジェスチャー インセットの方は、ホーム表示ジェスチャー用の下部のインセットしかありません。ジェスチャー領域の除外については、次回のブログ投稿で詳しく取り上げます。

固定インセット

メソッド: getStableInsets()
最後にご紹介するのは、固定インセットです。ジェスチャー ナビゲーションと特に関連はありませんが、Android で利用できるインセットの一種ですので簡単に説明しておきます。

固定インセットはシステム ウィンドウ インセットと関係がありますが、システム UI が実際に表示される場所ではなく、表示される「可能性がある」場所を表します。固定インセットは主に、システム UI の表示のオンとオフを切り替え可能なモード（たとえば、ゲーム、フォトビューア、動画プレーヤーなどでよく使われるリーンバックモードや没入モードなど）に設定されているときに使用されます。

インセットの処理

ここまでで、各インセットについて理解を深めていただけたことと思います。次は、これらのインセットを実際にアプリで使用する方法を見ていきましょう。

WindowInsets にアクセスする際は、主に setOnApplyWindowInsetsListenerメソッドを使用します。次に示すのは、ビューがナビゲーション バーの背後に表示されないようパディングを追加する例です。（ソースはこちら）

ここでは、ビューの下部のパディングを、システム ウィンドウ インセットの下部の値に設定しています（具体的な数値は指定していません）。

注: ViewGroupでこれを行う場合は、必要に応じて android:clipToPadding="false" に設定してください。デフォルトでは、すべてのビューでパディング内の描画がクリップされるためです。この属性は RecyclerViewでよく使用されます。詳しくは、今後別の投稿で取り上げたいと思います。

なお、リスナー関数には冪等性が必要です。リスナーが同じインセットで複数回呼び出される場合、結果は毎回同じでなければなりません。次に示すのは、冪等性がない関数の例です。（ソースはこちら）

🙅リスナーが呼び出されるたびにビューのパディングを追加（+=）してはいけません。ウィンドウ インセットのパスはいつでも、またビュー階層の存続中には複数回、発生する可能性があります。

Jetpack

インセットに関する注意点として、最小 SDK バージョンにかかわらず、Jetpackの WindowInsetsCompatを常に使用することをおすすめします。WindowInsets API は長年にわたって改良を重ね、拡張されています。この compat バージョンを使うことで、すべての API レベルで一貫した API と動作を実現できます。

Android Q で利用可能な新しい種類のインセットに対し、この compat メソッドは、すべての API レベルのホストデバイスに適した値を提供します。AndroidXの新しい API を使用するには、androidx.core:core:1.2.0-xxx（現在のアルファ版）以降にアップデートしてください。最新バージョンについてはこちらで確認できます。

さらに先へ

上記でご紹介したのは WindowInsets[Compat] API を使用する最も簡単な方法ですが、コードが非常に冗長で反復的になる可能性もあります。今年前半に私が投稿したブログ記事では、バインディング アダプターを使用して、ウィンドウ インセットの処理を大幅に簡素化する方法をいくつかご紹介しました。詳しくはこちらをご覧ください。

WindowInsets — リスナーからレイアウトまで

この連載の次回の投稿では、アプリのジェスチャーがシステム ジェスチャーと競合した場合の対処方法について見ていきます。

Posted by Yuichi Araki - Developer Relations Team

AMP のプリレンダリングでスピードアップ

October 17, 2019, 2:55 am

≫ Next: 11 月 1 日（金）第 4 回 Google Cloud INSIDE Digital を開催します

≪ Previous: ジェスチャー ナビゲーション: 視覚的な重なりの処理

$

0

0

この記事は Eric Steinlauf による Google Developers Blog の記事 "The Speed Benefit of AMP Prerendering" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
 投稿者: Google ソフトウェア エンジニア、Eric Steinlauf


本日は、プリレンダリングが読み込み時間に与えるメリットについて、最新の分析を紹介したいと思います。AMP は、ページ読み込み時間を短縮するために設計されました。また、Google 検索は、ページ読み込み時間を短縮する特に重要な方法の 1 つとして、リンクがクリックされる前にプライバシーを保護しつつ AMP ドキュメントのプリレンダリングを行っています。

First Viewport Ready

AMP フレームワークは、すべてのページ コンテンツのレイアウトと、すべてのリソースの読み込みステータスを把握できるように設計されています。そのため、すべての「ファースト ビュー」コンテンツが読み込まれたタイミングがわかります。また、ドキュメントがプリレンダリングされたり、表示されたりしたタイミングもわかります。つまり、AMP フレームワークは、クリックしてからファースト ビューのコンテンツが表示されるまでの時間を計算できます。AMP は、First Viewport Ready（FVR、最初のビューポートの準備完了）というカスタム指標を使ってページ読み込みのスピードを測定します。この指標の定義は、「ユーザーがクリックしてから、ファースト ビューの広告以外のリソースが load イベントを発行するまでの時間（プリレンダリングも考慮されます）」です。AMP ドキュメント全体がプリレンダリングされていれば、この指標は 0 になります。クリックされた時点でドキュメントのプリレンダリングが完了していない場合や、まったくプリレンダリングが行われていない場合、この指標は 0 よりも大きくなります。
Google 検索には、プリレンダリングされる AMP ドキュメントも、プリレンダリングされない AMP ドキュメントもあります。そのため、プリレンダリングが FVR に与える影響を確認することができます。下のグラフは、プリレンダリングが行われる場合と行われない場合の FVR をパーセンタイルで示しています。AMP フレームワークがドキュメントの表示前にプリレンダリングを正常に完了した場合、FVR は 0 になります。

First Contentful Paint

First Contentful Paint（FCP、最初のコンテンツの描画）は、ブラウザが測定するページ読み込みスピード指標です。この指標は、AMP ドキュメントだけでなく、すべてのドキュメントで利用できます。FCP は、DOM のコンテンツの一部が初めてレンダリングされたタイミングを指します。FCP が高いということは、明らかにページが遅いことを意味します。ただし、FCP が低くても、必ずしもページの読み込みが早いとは限りません。最初に表示されるコンテンツが重要とは限らないからです。これは便利な指標ですが、AMP はどのコンテンツが表示されているかを把握しているので、コンテンツの表示タイミングを理解したい場合、FVR を使う方がよいでしょう。
FCP はプリレンダリングを考慮しないので、AMP はプリレンダリングを踏まえた派生指標として、クリック前の時間を引いた Prerender-adjusted First Contentful Paint（PFCP、プリレンダリング調整済みの最初のコンテンツの描画）を計算します。プリレンダリングが行われない場合、PFCP = FCP となります。FCP もプリレンダリングによって低下しますが、違いは FVR ほど劇的ではありません。

プリレンダリングが行われる場合の PFCP の中央値は、プリレンダリングが行われる場合の FVR の中央値よりも高くなっています。これは驚きかもしれません。これが起こるのは、クリック後にブラウザが画面にコンテンツを描画しなければならないためです。PFCP にはこの時間が含まれますが、FVR には含まれません。

まとめ

AMP ドキュメントのプリレンダリングを行うと、ページの読み込み時間を大幅に短縮できます。プリレンダリングを行うと、ユーザーが早く見たいコンテンツを早く表示できます。ページ読み込み時間はさまざまな方法で測定できますが、この点は測定方法によらず一貫しています。このスピードアップには、プライバシーを保護したプリレンダリングが必要です。現在のところ、これを行えるのは AMP だけです。今後は、Signed Exchangesなどの新しいウェブ プラットフォーム機能によって、非 AMP ドキュメントでもプライバシーを保護した即時読み込みが実現できるようになるでしょう。

Reviewed by Chiko Shimizu - Developer Relations Team

11 月 1 日（金）第 4 回 Google Cloud INSIDE Digital を開催します

October 17, 2019, 3:54 am

≫ Next: ジェスチャー ナビゲーションの裏話

≪ Previous: AMP のプリレンダリングでスピードアップ

$

0

0

Google Cloud は、インターネットサービス業界で活躍するインフラエンジニア、サーバーアプリケーションエンジニア、テクニカルリーダーの皆様に向けて、"Google Cloud INSIDE Digital" を開催します。

業界をリードする方々や、深い専門知識をもつ Google 社員をスピーカーに迎え、注目インターネットサービスの開発の裏側や、Google Cloud Platform（GCP） を中心としたテクノロジーアップデートをお届けします。この Google Cloud INSIDE Digital をきっかけに、新しいサービスやプロダクトが生まれるような会へ、参加者の皆様と共に育てて行きたいと考えています。

今回のテーマは「ここでしか聞けない AI 、機械学習サービスの活用例」。様々なアプリケーション、サービスに AI が搭載されると言われる時代において、他企業の取り組みが気になる方も多いのではないでしょうか。今回は、GCP の AI、機械学習サービスの最新動向と、先進的な企業における AI 、機械学習の活用例についてご紹介します。

開催概要

• 名 称 : Google Cloud INSIDE Digital

• 日 時 : 2019 年 11 月 1 日（金） 19 : 00 - 22 : 00

• 会 場 : グーグル・クラウド・ジャパン合同会社

〒106‐­6108 東京都港区六本木 6-11-10 六本木ヒルズ森タワー

• プログラム

18:30 受付開始 18:30 ～ 開場 19:00 ～ 19:05 オープニング 19:05 ～ 19:25 Google Cloud と機械学習が切り拓く、IT 開発の新しい潮流 佐藤 一憲 Google デベロッパー アドボケイト 19:25 ～ 19:45 広告会社のクリエイター、エンジニア、Google AI でなにができるか？ ”そっくりとりっぷ” 誕生ストーリー 林 智彦 氏 博報堂 グローバル統合ソリューション局 グローバル・インタラクティブ・ディレクター 19:45 ～ 19:55 休憩 19:55 ～ 20:15 AI 技術集団による GCP サービス化事例 山本 大祐 氏 株式会社オプティム 経営企画本部 ディレクター 20:15 ～ 20:35　 ショッピングサイトにおける商品画像への Could Vision API の活用 木村 慎太郎 氏 20:35 ～ 20:55 株式会社エニグモ サービスエンジニアリング本部 リードエンジニア 言葉を AI であつかうために 最首 英裕 氏 株式会社グルーヴノーツ 代表取締役社長 20:55 ～ 21:00 クロージング 21:00 ～ 22:00 懇親会

• 主 催： グーグル・クラウド・ジャパン合同会社

• 定 員：200 名

• 参加費：無料 （事前登録制）

参加申し込み 

https://goo.gle/2lCQWGk

上記リンクからお申し込みください。




※ 競合他社様、パートナー企業様からのお申し込みはお断りさせていただくことがございます。
※ 報道関係者のご参加はお断りさせていただきます。
※ ビジネス向けのイベントとなっております。学生の方のご参加はご遠慮ください。
※ お申し込み多数の場合は抽選を行います。参加いただける方には、後日、ご登録されたメールアドレスに参加のご案内をお送りします。

Posted by Takuo Suzuki - Developer Relations Team

ジェスチャー ナビゲーションの裏話

October 17, 2019, 11:57 pm

≫ Next: amp-script: AMP ❤️ JS

≪ Previous: 11 月 1 日（金）第 4 回 Google Cloud INSIDE Digital を開催します

$

0

0

この記事は Allen Huang and Rohan Shah (Product Managers on Android UI) による Android Developers Blog の記事 "Gesture Navigation: A Backstory" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android Q の最大の変更点の 1 つが、新しくなったジェスチャー ナビゲーションです。新しいシステム ナビゲーション モードでは、画面の左端または右端から内側にスワイプすると前の画面に戻ることができ、画面の下部から上にスワイプするとホーム画面に戻ることができます。また、画面の下隅から斜めにスワイプするとデバイス アシスタントが起動します。

システム ナビゲーションをジェスチャー モデルに移行したことで、ナビゲーション ボタンを非表示にしてアプリの画面領域を拡げ、より臨場感あふれるエクスペリエンスを実現できるようになりました。

今回は、ナビゲーション デザインの過程でどのような課題に直面し、難しい選択を迫られたときどのような理由で決断したかなど、新しいシステム ナビゲーションにまつわる裏話を披露します。ジェスチャーのデザインに関して少々マニアックな部分にまで踏み込みますが、デベロッパー並びに OEM パートナーの皆様とユーザーの利便性のバランスをどう取るかについて、Google がいかに頭を悩ませたかをご理解いただけたらと思っています。アプリをこれらの変更に対応させる方法については、Medium の記事シリーズ「エッジ ツー エッジへの対応」で詳しく解説しておりますのでぜひご覧ください。

ジェスチャーに移行した理由

アプリ デベロッパーやパートナーの皆様にとっての Android の魅力の 1 つは、スマートフォンでまったく新しい革新的な手法を試すことができる点ではないでしょうか。

モバイル デバイスのジェスチャー機能は 2009 年には登場していましたが、ジェスチャー ナビゲーションのパターンが急激に増えたのはここ 3 年ほどのことです。

この流れをリードしたのが、たとえば Fluid NGや XDAのような、独創的なアイデアに挑戦してきた革新的な Android パートナーや Android アプリです。

Google が調査したところ、ジェスチャーはユーザーにとってさまざまなメリットがあることがわかりました。

1. ジェスチャーは、スマートフォンを操作する方法としてよりスピーディーで、自然で、人間工学的に優れている
2. ジェスチャーはより意図的である（ソフトウェア ボタンは、スマートフォンを手に取るとき偶然タップしてしまうことがある）
3. ジェスチャーを採用することで、アプリ コンテンツに上書き表示するシステム ナビゲーションを最小限に抑えることができ、より臨場感あふれるエクスペリエンスを実現できる（大画面化と狭額縁化が進む中、「ホーム」ボタン、「戻る」ボタン、ナビゲーション バーなどを画面に表示する必要がない）

しかし、良いことばかりではありません。ジェスチャー モードにはさまざまな問題もあります。

1. ジェスチャーは、すべてのユーザーが快適に利用できるとは限らない
2. ジェスチャーは、習得がより難しく、ある程度の na 調整も必要になる
3. ジェスチャーは、アプリのナビゲーション パターンと競合する可能性がある

しかし、何よりも私たちが問題だと感じたのは、Android スマートフォンでもブランドや機種が違えばジェスチャーが異なるという「断片化」が生じており、特に Android デベロッパーの皆様がこの点に大きな懸念を抱かれていることでした。
そこで Google では、ここ 1 年ほどかけて Samsung、Xiaomi、HMD Global、OPPO、OnePlus、LG、Motorola などのパートナーと協力し、将来的にジェスチャー ナビゲーションを標準化していくことを決めました。一貫性のあるユーザー エクスペリエンスとデベロッパー エクスペリエンスを提供するため、Android Q 以降の新しいデバイスでは、Q のジェスチャーをデフォルトのジェスチャー ナビゲーションにします。
ただし、すべてのユーザーがジャスチャーを快適に利用できるとは限りません。ジェスチャーのような細かな動きが得意でない方々のために、すべての Android デバイスで引き続き 3 ボタン ナビゲーションをオプション機能として提供することにしています。

今回これらのジェスチャーを採用した理由

Google ではまず徹底的な調査を行いました。ユーザーはどういう形でスマートフォンを握っているか、指が届く範囲はどのあたりか、最もよく使うのはスマートフォンのどの部分か、などです。これらの調査結果をもとに、ジェスチャー モデルのプロトタイプを数多く作成し、望ましさ、使用速度、人間工学性などさまざまな側面にわたってテストを実施しました。最終的なデザインは、ユーザーがすぐに習得できるか、ユーザーが短期間で慣れるか、ユーザーがどう感じたかなどを基準に決定しました。
「戻る」ボタンは、Android の初期から引き継がれている特徴的なナビゲーション要素です。どのような操作方法が「正解か」という議論はあるものの、「戻る」ボタンのおかげで多くのユーザーが Android を、操作しやすい、習得しやすいと感じてくれたようです。実際のところ、「戻る」ボタンは非常によく利用されており、使用回数は「ホーム」ボタンより 50% も多くなっています。今回のデザインにあたっては、この「戻る」ボタンを人間工学性と信頼性に優れ直感的に行えるジェスチャーにすることを目標の 1 つとし、使用頻度がそれほど高くないナビゲーション（ドロワー、「最近」など）よりも優先することにしました。
また、最も重要な 2 つのジェスチャー（「戻る」と「ホーム」）は、下に示した到達範囲の図に基づいて、親指が最も快適に届く領域で操作できるようにデザインしました。

スマートフォン画面のヒートマップを見ると、ユーザーが片手でスマートフォンを持った状態で快適に行えるジェスチャーがわかります。
ジェスチャー モデルのプロトタイプを数多く作成したことはすでに述べましたが、これらを試してもらい、ユーザーの評価とジェスチャー操作にかかった時間を比較しました。以下は、最終的な Q モデルと他のナビゲーション モードを比較したテスト結果のグラフです。

各ナビゲーション モードの人間工学性と片手操作性についてのユーザー評価の比較（値が大きいほど良い）

各ナビゲーション モードでの「戻る」と「ホーム」の操作にかかった平均時間の比較（値が小さいほど良い）

各ナビゲーション モードでの「最近」操作にかかった平均時間の比較（値が小さいほど良い）

「ホーム」と「戻る」の操作にかかった平均時間は、Q モデルが他のどのモデルよりも短く、ボタンを使った操作よりも速いことがわかります。一方、「最近」の操作は他のモデルに比べ少し時間がかかっていますが、これは「最近」の使用頻度が「ホーム」の半分程度であるため優先度を下げたことによるものです。
定性的に見ると、ユーザーは Q モデルの片手操作性を高く評価していますが、人間工学性の面では依然としてボタンのほうが評価が高くなっています。

アプリドロワーとその他のアプリスワイプ

最終的には、操作性と使用頻度のバランスを考慮し、サイドスワイプを「戻る」ジェスチャーとして採用しました。しかし、特にジェスチャーがアプリに及ぼす影響を考えると、難しい決断を強いられる場面もありました。

たとえば、Google アプリによって異なりますが、アプリ ナビゲーション ドロワーをスワイプ操作で開いているユーザーは 3～7% 存在します（残りのユーザーは 3 本線のメニューをタップして開いています）。このドロワーのスワイプ ジェスチャーが「戻る」ジェスチャーに置き換えられたため、一部のユーザーは 3 本線のメニューを使った操作に慣れる必要があります。非常に難しい決断でしたが、「戻る」操作の使用頻度の高さを考慮し、ユーザーにとって最も便利になるように最適化したつもりです。

ユーザーの行動を変えずにすむよう、ドロワー ジェスチャーと「戻る」ジェスチャーをうまく識別できる方法がないか試行錯誤しました。しかし、どの方法を採用した場合でも、前の画面に戻ろうとしたユーザーが誤ってドロワーを引き出してしまうことがあり、「戻る」ジェスチャーの信頼性に疑念が生じてしまうと判断しました。

ドロワーに限らず、ジェスチャーは人々にとって大きな変更であり、慣れるまでに平均で 1～3 日かかりました。特に、カルーセルを左右にスワイプするのが苦手だったユーザーは、「戻る」ジェスチャーに慣れるのにも苦労したようです。

定性的な調査の結果によると、1～3 日で新しい操作に慣れたユーザーは、2 つのジェスチャーをしっかり区別し、スムーズに操作できるようになりました。3 ボタン ナビゲーションに戻すオプションも残されていますが、大部分のユーザーが戻したくないと回答しました。

他の調査では、ユーザーが新しいシステム ナビゲーションに切り替える際には、それに慣れるための明確な調整段階があることもわかりました。Q モデルの場合、最初の 1～3 日は「戻る」ジェスチャーの使用回数は少ないのですが、その後は 3 ボタン システムや Android P ナビゲーションと同じぐらいの頻度で利用されるようになりました。

デベロッパーの皆様にご対応いただきたいこと

Google としては、このようなジェスチャー ナビゲーションによって、Android でのユーザー エクスペリエンスの標準化を進めていきたいと考えています。今回採用したジェスチャー モデルはほとんどのユーザーにとって最適なものと考えていますが、これらが既存のアプリのジェスチャーと競合する場合は、デベロッパーの皆様にアプリの操作方法を調整していただく必要がございます。皆様のご負担を少しでも軽減できるよう、十分な情報提供を心掛けてまいります。

新しいジェスチャー ナビゲーションへの対応は、次に示す 3 つステップで進めることができます。

1. エッジ ツー エッジに対応します。これにより、アプリのコンテンツを画面いっぱいに表示できるようになります。
2. システム ユーザー インターフェース（ナビゲーション バーなど）との視覚的な重なりを処理します。
3. システム ジェスチャーとの競合を解消します。

これらのステップについては、Medium の記事シリーズ「エッジ ツー エッジへの対応」で詳しく解説しています。シリーズ最後の記事では、これまでに多く見られたいくつかのシナリオを紹介し、アプリをエッジ ツー エッジ対応にするための最適な方法を提案します。
新しいジェスチャー ナビゲーションについて、ご意見、ご感想などございましたらぜひお寄せください。Android Q のジェスチャー ナビゲーションはもちろん、Android の日々の改善に役立てさせていただきます。

Posted by Yuichi Araki - Developer Relations Team

---

amp-script: AMP ❤️ JS

October 18, 2019, 1:40 am

≫ Next: 強烈なインパクト: オーストラリアのポップカルチャー サイト GOAT を AMP 化した理由

≪ Previous: ジェスチャー ナビゲーションの裏話

$

0

0

この記事は Naina Raisinghani による The AMP Blog の記事 "amp-script: AMP ❤️ JS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今年の AMP Conf では、<amp-script> のデベロッパー プレビューを紹介しました。本日は、<amp-script>の一般公開についてお知らせします。カスタム JavaScript は、AMP コンポーネントによって別の Worker スレッドで実行されます。そのため、超高速な AMP ページはそのままに、カスタム JavaScript を追加できるようになります。
<amp-script> を使うと、既存の AMP コンポーネントでは実現できなかったユースケースに対応できます。また、AMP ページと非 AMP ページでコードを共有することもできます。JavaScript フレームワークを使うことも可能です。次にあげるのは、<amp-script> チームが構築してきたいくつかのサンプルです。

• Vue を使った Todo MVC
• パスワード チェッカー
• D3.js を使ったニュース記事のデータ視覚化
• 次のセクションに移動する前に検証が必要になる複数ページフォーム（下のイメージ）

上の例を見て興味を持った方は、<amp-script> を試してみてください。なお、AMP のパフォーマンスを保証するために、いくつか制約がある点に注意が必要です。

• コンテンツのジャンプ: 通常の <amp-script> では、意図しないコンテンツのジャンプを回避するため、ユーザーのジェスチャーが発生しないとページのコンテンツを変更することはできません。 
• ページ読み込み: <amp-script> はユーザーの操作なしにページのコンテンツを変更することはできないので、ページの読み込み時にコンテンツを変更することもできません。
• スクリプトのサイズ: 1 つの <amp-script> で使うスクリプトは、150 kB 以下である必要があります。なお、お気に入りの JS フレームワークを使うことはできますが、150 K の制限内に収まっている必要があります。
• API のサポート: Web Worker ですべての API がサポートされているとは限りません。WorkerDOM には、許可されている API のリストが掲載されています。また、いくつかの DOM のメソッドやプロパティはまだ実装されていません。リスト全体は、WorkerDOM の互換性で公開されています。追加してほしい API がある方は、問題として送信してください、

<amp-script> は、React、Preact、Angular、Vue.js、jQuery、D3.js など、皆さんが既に利用しているかもしれないフレームワークに対応しています。

この点は、AMP を使っているデベロッパーから寄せられた最も重要な要望でした。AMP Project は、スピードという AMP の価値提案を維持しつつ、この要望に対処できたことをうれしく思っています。<amp-script> の動作の詳細については、こちらをご覧ください。また、このガイドに従って <amp-script> を試してみてください。このすばらしい手法を使うと、これまでは不可能だったたくさんのユースケースを実現できるようになります。

<amp-script> の使用に関する問題や機能リクエストがありましたら、遠慮なくお知らせください。


投稿者: Naina Raisinghani（Google AMP Project、プロダクト マネージャー）


Reviewed by Chiko Shimizu - Developer Relations Team

強烈なインパクト: オーストラリアのポップカルチャー サイト GOAT を AMP 化した理由

October 23, 2019, 8:35 pm

≫ Next: 同一プロバイダによる DNS-over-HTTPS アップグレードの実験について

≪ Previous: amp-script: AMP ❤️ JS

$

0

0

この記事は Leo Postovoit による The AMP Blog の記事 "Powerful impact: Why we AMPized the Australian pop culture site – GOAT" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


NOVA Entertainmentはオーストラリアでも特に有名なメディア ブランドで、過去 19 年間にわたってラジオ、メディア、ローカル コンテンツに携わってきました。その NOVA がポップカルチャーやニュース、エンターテイメント向けのモバイル ファースト プラットフォームとして構築したのが GOATです。

GOAT は、プログレッシブを重視した WordPress ビルドの開発によって恩恵を受けた最初の NOVA のサイトです。GOAT の編集者たちの目標の 1 つは、アクセスしやすく便利で高速なフォーマットによってコンテンツを届けることです。パフォーマンスとユーザビリティは最優先事項です。ここでは、GOAT の技術革新において AMP と PWA がどのようなインパクトをもたらしたのかについて説明します。

課題
GOAT ウェブサイトには、パフォーマンスとユーザビリティに関する問題が発生していました。ユーザー エクスペリエンスを改善して多くの端末との互換性を向上させるための最優先事項は、サイトのパフォーマンスを向上させることでした。サイトがコンテンツやアセットをレンダリングする際に遅延が生じ、ユーザーやオンサイト体験、共有体験の妨げになっていました。これは驚くべきことではありません。サイトへのエンゲージメントのレベルにパフォーマンスがどれほど重要かは、複数の調査結果が一貫して示しています。
今年東京で開催された技術カンファレンスの講演の冒頭で、Google 社員の Jeany Hallimanは、Google がメディアサイトの訪問者を対象に「サイトを見る際に一番嫌なこと」を尋ねた調査について触れました。

「広告業界出身の私は、いつも（訪問者が嫌うのは）広告だと思っていました。しかし、ユーザーの大半は、遅いウェブサイトと答えたのです」 – Jeany Halliman

この回答と、ページのスピードが直帰率に与える影響を細かく観測した結果には、明らかに相関性があります。しかし、過大な広告戦略が注目され、多くのメディアサイトがそれに対する「反動」を受けていることを考えれば、多くの方にとって、スピードがページの広告よりも上位に来ていることは驚きだったはずです。

チャンス
NOVA は、WordPress エンジニアリング エコシステムのリーダー的存在であり、Google と連携して公式の AMP Plugin for WordPressのメンテナンスを行っている XWPに連絡しました。XWP は、Rolling Stone、News Corp Australia、Rogers などの大手パブリッシャーや、Cloudinary、Google、BigCommerce、Automattic などの技術パートナー向けに美しく複雑なソリューションを開発していることで知られ、ウェブを進化させることを重視して仕事に取り組んでいます。

NOVA のステークホルダーが示した主要な目標は、パフォーマンス、拡張性、ユーザビリティでした。そのため、XWP にとっては、向かうべき道がプログレッシブ AMP によるアプローチであることは明白でした。

一方で、AMP ファースト戦略に移行するにあたって最も重要な目的は明らかでした。ユーザーが繰り返し利用し、喜んで共有してくれる高速な体験を作成するには、CI/CD、自動テスト、高可用性ホスティングを含む開発のベスト プラクティスを駆使して確実に拡張性や安定性を実現することも重要です。GOAT サイトは、コードの品質が高く、最新の WordPress の実装に関する留意点を踏まえて構築されているので、早いだけでなく、長く使えるものとして作られています。

解決策
AMP やその他のパフォーマンス改善策に精通している XWP は、NOVA が GOAT サイトで達成したい目標を実現するため、さまざまな実装を検討しました。最も適していたのは、1 つのコードベースで開発を効率化できる AMP ファースト戦略でした。

そこからさらに一歩進めた GOAT は、PWA 機能プラグイン（これも XWP と Google が連携して開発しています）のすばらしい事例とも言えるでしょう。このプラグインは、Service Worker を活用してオフライン モードや通知などの追加機能を提供します。また、この定義済みソリューションでは、AMP と PWA のメリットを今までになく簡単に組み合わせることができる amp-install-serviceworkerコンポーネントが活用されています。

現在含まれている PWA 機能の範囲は限定的ですが、長期的な目標として、PC やモバイル端末へのインストール機能、さらに充実したオフライン モードやプリフェッチ ページ、ネイティブのプッシュ通知などを追加したいと考えています。これらの機能は、ウェブのあちこちに見られる強力な PWA と同様のものです。

広告の組み込み 
広告の読み込みが適切に設定されていない場合、ページのパフォーマンスが低下する原因となる可能性があります。GOAT のようなメディア重視のサイトでは、特にその傾向が顕著です。AMP を使うということは、XWP が GOAT の広告スタックを実装する際に、AMP 標準に準拠したアプローチを採用しなければならないということです。  完全に AMP 対応されていない広告プロバイダを利用するために多少の妥協は必要になりましたが、結果的には、広告収入を頼りにするメディアサイトとしてかなり高いパフォーマンスを実現しました。これは 2 つの長所を兼ね備えています。すなわち、優れたユーザー エクスペリエンスを実現でき、広告の読み込みも次善の方法で最適化されているので、パフォーマンスの低下につながることはありません。

結果 
ここまで説明してきたように、GOAT は NOVA のサイトで初めて統合編集ワークフローとパフォーマンスを重視したテーマビルドを実稼働させたものです。これは PWA サイトであると同時に、すべてのテンプレートがネイティブ AMP として構築されています。パフォーマンス面での成果は明らかです。

• 複数のプロパティの編集操作を統合しています。
• モバイルの Google Pagespeed Insights スコアは 7 から 77 に上昇しました。
• WebPageTest 3G テスト: 実装前 / 実装後。ポイント: レンダリング開始時間（Start Render）が 1.5 秒短縮されました。操作が可能になるまでの時間は、43 秒からわずか 10 秒になりました。
• Lighthouse テスト: 実装前 / 実装後。最初のコンテンツ描画（First Contentful Paint）が 5.8 秒から 2.5 秒になりました（3.3 秒短縮）。パフォーマンス スコアは 7 から 65 に上昇しました。最初の CPU アイドル時間（First CPU Idle）は 16.2 秒から 5.9 秒に短縮されました。
• GTmetrix: 実装前 / 実装後。PageSpeed スコアは D（63%）から B（82%）に上昇しました。

AMP の活用を始める
GOAT サイトの AMP ファースト戦略で達成した結果をもとに、AMP を活用して現在のビジネスの課題を解決する方法について、さらに学習することをお勧めします。

• AMP の詳細については、amp.devにあるプロジェクトのホームページをご覧ください。  
• 自分のサイトの互換性を評価し、AMP によってパフォーマンスとユーザー エクスペリエンスの恩恵を得られるかを確認してみたい方は、AMPized.com（WordPress サイトで AMP のメリットを実現する XWP のサービス）をご覧ください。

執筆者: XWP ストラテジスト、Leo Postovoit

Reviewed by Chiko Shimizu - Developer Relations Team

同一プロバイダによる DNS-over-HTTPS アップグレードの実験について

October 23, 2019, 6:30 pm

≫ Next: 以前の TLS バージョンのサポート終了に伴う Chrome UI の変更点

≪ Previous: 強烈なインパクト: オーストラリアのポップカルチャー サイト GOAT を AMP 化した理由

$

0

0

この記事は Chrome プロダクト マネージャー、Kenji Baheux による Chromium Blog の記事 "Experimenting with same-provider DNS-over-HTTPS upgrade" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


 ウェブを安全に使えるようにするという長年にわたる私たちの取り組みの一環として、Chrome 78 で DNS-over-HTTPS（DoH）実装を検証するための実験を行います。名前からもわかるとおり、この考え方は、HTTPS によって確保されるセキュリティとプライバシー上の重要な利点を DNS にもたらします。DNS は、指定されたウェブサイトをホスティングしているサーバーをブラウザが判断する仕組みです。たとえば、パブリック WiFi に接続しても、DoH を使っていれば、他の WiFi ユーザーが皆さんの見ているサイトを知ることはできなくなります。また、なりすましやフィッシング攻撃も防ぐことができます。この実験は、既に DoH をサポートしている DNS プロバイダと連携して実施します。実験の目的は、現在の DNS サービスを DoH バージョンにアップグレードすることで、ユーザー間のセキュリティやプライバシーを改善することにあります。このアプローチでは、使用する DNS サービスは変わらず、プロトコルだけが変わります。そのため、既存の子ども向けの保護を含め、現在の DNS プロバイダが行っているコンテンツ制御の有効性は変わりません。

さらに具体的に説明します。Chrome 78 で行う実験では、ユーザーの現在の DNS プロバイダが DoH 対応プロバイダのリストに掲載されているかどうかを確認し、そのプロバイダが提供する同等の DoH サービスにアップグレードします。DNS プロバイダがリストに掲載されていない場合、Chrome は現在の動作を継続します。リストに掲載されるプロバイダは、プライバシーとセキュリティに対する強い姿勢、DoH サービスに向けた準備の完了、実験の参加への同意という条件を満たすプロバイダから選択されました。実験の目的は、Chrome の実装を検証し、パフォーマンスへの影響を評価することです。 

この実験は、サポートされているすべてのプラットフォーム（Linux と iOS を除く）で、一部の Chrome ユーザーを対象に行われます。Android 9 以上で、ユーザーが Private DNS 設定で DNS-over-TLS プロバイダを指定している場合、Chrome は関連付けられている DoH プロバイダを使い、エラー時にはシステムの Private DNS にフォールバックする場合があります。

DNS プロバイダの現状を維持し、プロバイダの同等な DoH サービスへのアップグレードのみを行うので、同じユーザー エクスペリエンスが維持されます。たとえば、DNS プロバイダが提供する不正なソフトウェアからの保護やペアレンタル コントロール機能は引き続き動作します。DoH が失敗した場合、Chrome はプロバイダの通常の DNS サービスを使います。Chrome 78 の chrome://flags/#dns-over-https でフラグを無効にして、実験をオプトアウトすることも可能です。


ほとんどのマネージド Chrome リリースは、実験の対象外になります。企業や教育機関の管理者の方は、今後のリリースノートを読んで DoH ポリシーについての詳細をご確認ください。このポリシーは、Chrome Enterprise ブログでも公開する予定です。

DNS には 35 年の歴史があり、さまざまな関係者が利用して多様なユースケースを実現しています。特に、ISP が提供する家族向けの安全なコンテンツ フィルタリングにおいて、DNS が重要な役割を果たせることは承知しています。そのため、重要なステークホルダー（ISP や DNS プロバイダ、オンラインの安全性を専門とする組織など）を巻き込んで手順についての議論を行いつつ、家族向けフィルターなどの現在利用されているユーザー向け機能を尊重した段階的なアプローチをとります。また、Chrome の機能とパフォーマンスの改善への協力に同意したユーザーから送られるパフォーマンスや信頼性に関する統計、ユーザーによるフィードバックも考慮します。

この実験は、ユーザーのプライバシー、セキュリティ、安全性を改善するために、協力して歩まなければならない長い道のりのつつましい第一歩です。DoH が実環境でどのように動作するか、確認するのが待ち遠しくてたまりません。皆さんからのフィードバックもお待ちしています！

Reviewed by Eiji Kitamura - Developer Relations Team

以前の TLS バージョンのサポート終了に伴う Chrome UI の変更点

October 24, 2019, 6:37 pm

≫ Next: Cloud Firestore のクエリが遅くなる理由

≪ Previous: 同一プロバイダによる DNS-over-HTTPS アップグレードの実験について

$

0

0

この記事は Chrome セキュリティ チーム、Chris Thompson による Google Online Security Blog の記事 "Chrome UI for Deprecating Legacy TLS Versions" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年 10 月、Chrome 81 で TLS 1.0 と 1.1 のサポートを削除する計画についてお知らせしました。この投稿では、削除の前段階として穏やかな警告 UI を導入すること、Chrome 81 で TLS 1.0 と 1.1 をブロックすることになる UI についてお知らせします。サイト管理者は、ただちに TLS 1.2 以降を有効にし、ここで紹介する UI が表示されないようにしてください。
以前の TLS の使用は減少していますが、現在もページ読み込みの 0.5% 以上で非推奨のバージョンが使われています。最終的なサポートの削除に向けた移行を容易にし、古い設定が動作しなくなったときにユーザーを驚かせることがないように、Chrome は 2 段階でサポートの終了に対応します。まず、非推奨のバージョンを使っているサイトに対して、新しいセキュリティ インジケーターを表示します。次に、ページ全面に警告を表示してサイトへの接続をブロックします。


削除前の警告
2020 年 1 月 13 日より、Chrome 79 以降で、TLS 1.0 または 1.1 を使用しているサイトに「Not Secure」インジケーターを表示し、ユーザーに古い設定であることを警告します。

新しいセキュリティ インジケーターと接続セキュリティ情報。2020 年 1 月以降、ユーザーが TLS 1.0 または 1.1 を使っているサイトにアクセスした際に表示される。

サイトで TLS 1.0 または 1.1 を使っている場合、Chrome はセキュリティ インジケーターをダウングレードし、ページ情報に詳細な警告メッセージを表示します。この変更では、ユーザーがページにアクセスする操作がブロックされることはありませんが、接続のセキュリティがダウングレードされていることが警告されます。
なお、Chrome の DevTools には既に警告が表示されるようになっています。非推奨のバージョンの TLS を使っていることをサイトオーナーに警告するためです。


削除後の UI
2020 年 3 月に Stable チャンネルにリリースされる予定の Chrome 81 以降では、TLS 1.0 または 1.1 を使っているサイトにアクセスしようとすると、ページ全体を覆うインタースティシャル警告が表示されて接続がブロックされます。

Chrome 81 以降では、TLS 1.0 または 1.1 を使っているサイトにアクセスしたユーザーに、全画面のインタースティシャル警告が表示される。最終的な警告は、今後変更される可能性がある。

サイト管理者は、ただちに TLS 1.2 以降を有効にしてください。サーバー ソフトウェアによっては（Apache や nginx など）、構成の変更やソフトウェアのアップデートが必要になる場合があります。さらに、すべてのサイトで TLS 設定を再確認することをお勧めします。最初のお知らせの際に、最新の TLS の基準について概要を説明しています。

企業向けリリースで SSLVersionMin ポリシーを “tls1.2” に設定すると、TLS 1.0 と 1.1 の最終的な削除について事前に確認することができます。この設定を行うと、クライアントが TLS 1.0 および 1.1 プロトコルで接続できなくなります。対応に時間がかかる企業は、このポリシーを使って TLS 1.0 や TLS 1.1 を有効化し直し、警告 UI を無効化することができます。ただし、この操作を行えるのは、2021 年 1 月までに限られます。

Reviewed by Eiji Kitamura - Developer Relations Team

Cloud Firestore のクエリが遅くなる理由

October 27, 2019, 7:08 pm

≫ Next: Android アプリのエクスペリエンスを Chrome OS 向けに最適化する

≪ Previous: 以前の TLS バージョンのサポート終了に伴う Chrome UI の変更点

$

0

0

この記事は Todd Kerpelman(Developer Advocate) による The Firebase Blog の記事 "Why is my Cloud Firestore query slow?" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Cloud Firestore のパフォーマンスについては、「ベースのデータセットではなく結果セットのサイズに比例して高速化する」、「低速のクエリを作成するのは実質的に不可能だ」など、その素晴らしさを評価する声がよく聞かれます。そしてほとんどの場合、それは事実です。アプリでは莫大な数のレコードが格納されたデータセットに対するクエリを実行し、ユーザーが画面から親指を離すよりも早く結果を取得できます。

とは言え、デベロッパーからは「特定の状況では Cloud Firestore の動作が遅く感じられ、クエリの結果を取得するのに予想よりも時間がかかる」という意見を聞くこともあります。それはなぜでしょうか。今回は、Cloud Firestore の動作が遅くなったように見える場合に考えられる原因と、その対処方法をご紹介します。

理由その 1: データが多すぎる

クエリが遅くなったと感じる場合に第一に考えられる原因としてクエリ自体は非常に高速に実行されているのですが、クエリが完了した後にすべてのデータをデバイスに転送する必要があり、実際にはその処理に時間がかかっているのです。

たとえば、組織内の全営業担当者を対象にしたクエリを実行するとしましょう。このクエリは非常に高速に実行されます。しかし、その結果セットが 2,000 人の従業員のドキュメントで構成されていて、各ドキュメントに 75 KB のデータが含まれていたらどうでしょう。デバイスでは 150 MB のデータをダウンロードする必要があり、それが完了するまで結果は確認できません。

パフォーマンスを改善するには

この問題を解決するには、必要なデータ以外は転送しないようにするとよいでしょう。簡単なのは、クエリに制限を追加する方法です。従業員リストの結果のうち、ユーザーが必要なのは先頭のごく一部だけだと思われる場合は、クエリの最後に limit(25) を追加すれば、最初の方のデータのみダウンロードされ、その他のレコードはユーザーがリクエストした場合に限りダウンロードされるようにすることができます。これについてはこちらの動画で詳しく説明していますので、ぜひご覧ください。

一方、営業担当者 2,000 人全員のデータをクエリで取得する必要があると考える場合は、別の方法があります。最初のクエリで取得したいデータのみを含むドキュメントをこれらのレコードから分離し、その他の詳細なデータを含むドキュメントは個別のコレクションまたはサブコレクションにまとめるのです。後者のドキュメントは最初の取得時には転送されませんが、ユーザーの必要に応じて後からリクエストできます。

ドキュメントのサイズを小さくすると他にもメリットがあります。たとえば、クエリにリアルタイム リスナーを設定して、ドキュメントが更新されるとそのドキュメントがデバイスに送信されるようにしたい場合です。ドキュメントのサイズを小さくしておけば、リスナーで変更が発生するたびに転送されるデータの量も少なくなります。

理由その 2: オフライン キャッシュが大きすぎる

Cloud Firestore のオフライン キャッシュはとても優れた機能です。オフラインの永続性を有効にすると、ユーザーがトンネル内に入ったときや飛行機に 9 時間乗っている間でも、アプリはオンラインと「同じように機能」します。つまり、オンライン中に読み取ったドキュメントをオフラインでも利用でき、オフライン中に書き込んだデータは、アプリがオンラインに戻るまでローカルでキューに追加されます。さらに、クライアントの SDK ではこのオフライン キャッシュを利用して、大量のデータがダウンロードされないようにすることができるため、ドキュメントの書き込みなどのアクションを高速化できます。ただし Cloud Firestore は「オフライン優先」のデータベースとして設計されているわけではないので、今のところローカルでの大量のデータの処理には向いていません。

Cloud Firestore はクラウド内で、すべてのコレクションの全ドキュメントとそのフィールドをもれなくインデックスに登録しますが、（現時点では）オフライン キャッシュ用にこうしたインデックスを作成することはありません。つまり、オフライン キャッシュ内のドキュメントにクエリを実行する場合、Cloud Firestore ではクエリ対象のコレクションについて、ローカルに保存されているすべてのドキュメントを展開してからクエリと照合する必要があります。

別の言い方をすれば、バックエンドでのクエリは結果セットのサイズに応じて遅くなりますが、ローカルのオフライン キャッシュ内でのクエリは、クエリ対象のコレクションに含まれるデータのサイズに応じて遅くなります。

ところで、ローカルでのクエリが実際にどの程度遅くなるかは、状況によって異なります。ここで話題にしているのはローカル、つまりネットワークに接続していない状態でのオペレーションですが、これはネットワーク呼び出しを行うよりも速い可能性が（しかもかなりの確率で）あります。ただし、1 つのコレクションに含まれる大量のデータを分類しなければならない場合、あるいは単に動作が遅いデバイスを使用している場合、大きなオフライン キャッシュに対するローカル オペレーションは著しく遅くなる可能性もあります。

パフォーマンスを改善するには

最初に、前のセクションで説明したおすすめの方法を試してみてください。つまり、ユーザーが必要とするデータのみを取得できるようクエリに制限を追加し、不要な細かいデータはサブコレクションに移動することを検討します。また、以前の投稿の最後に取り上げた「複数のサブコレクションと単独の最上位コレクション」のどちらを使うべきかという観点で考えた場合、このケースでは「複数のサブコレクション」を採用した方がよいでしょう。そうすれば、キャッシュの検索対象が、こうした小さめのコレクションに含まれるデータのみとなるからです。

2 番目の方法は、必要以上のデータをキャッシュに詰め込まないようにすることです。私は、デベロッパーがキャッシュを意図的にこのように使用するケースをいくつか見たことがあります。アプリの最初の起動時に膨大な数のドキュメントにクエリを実行し、その後のすべてのデータベース リクエストにローカル キャッシュを強制的に参照させるというものです。通常、データベース コストを削減したり、以降の呼び出しを高速化したりする目的で用いられますが、実際にはメリットよりデメリットの方が大きい場合がほとんどです。

3 番目の方法は、オフライン キャッシュのサイズを小さくすることです。モバイル デバイスのキャッシュのサイズはデフォルトで 100 MB に設定されていますが、状況によっては（特に、大規模な 1 つのコレクションにほとんどのデータが格納されている場合は）、このサイズではデータが多すぎてデバイスで処理できない可能性があります。このサイズは、Firebase の設定で cacheSizeBytesの値を変更することで調整できます。特定のクライアントに対してサイズを調整するとよいでしょう。

4 番目に、永続性を完全に無効にして、何か変化があるか確認してみてください。この方法は通常はおすすめしません。前に述べたように、オフライン キャッシュは非常に優れた機能だからです。それでも、クエリが遅くなったように感じて、その理由がわからない場合は、永続性を無効にしてアプリを再実行することでキャッシュが問題の原因かどうかを判断できるでしょう。

理由その 3: ジグザグマージ結合に問題がある

「ジグザグマージ結合」という名前を私が個人的に気に入っていることはさておき、このアルゴリズムは複合インデックスに依存せずに複数のインデックスからの結果を統合できる点で非常に便利です。基本的には、ドキュメント ID 順に並べ替えた 2 つ（またはそれ以上）のインデックス間を行き来して一致を見つける仕組みになっています。

しかし、ジグザグマージ結合にも 1 つ弱点があります。どちらの結果セットもサイズが大きいにもかかわらず両者の共通部分が少ないと、パフォーマンスの問題が発生する場合があるのです。一例として、カウンター サービスも提供している高級レストランを検索するクエリを考えてみましょう。

restaurants.where('price', '==', '$$$$').where('orderAtCounter', '==', 'true')

両方ともかなり大きいグループですが、共通部分はおそらくほとんどありません。この場合、ジグザグマージ結合では、必要な結果を取得するために多くの検索を行う必要があります。

クエリのほとんどが高速に実行されているのに、特定のクエリを複数のフィールドに対して一度に実行している最中に遅くなる場合は、この状況に陥っている可能性があります。

パフォーマンスを改善するには

複数のフィールドにわたるクエリがが遅くなる場合、それらのフィールドに対する複合インデックスを作成することでパフォーマンスを改善できます。バックエンドでは、その後のすべてのクエリで、ジグザグマージ結合ではなくこの複合インデックスを使用するようになります。つまり、クエリは結果セットのサイズに比例して高速になるということです。

理由その 4: Realtime Database に慣れてしまっている

Cloud Firestore は、クエリ機能、信頼性、スケーラビリティの点で Firebase Realtime Database を上回ります。ただし北米で利用する場合は、一般に Realtime Database の方が低レイテンシです。通常はそれほど大きな差はなく、チャットアプリなどでは違いに気付くことはおそらくないでしょう。しかし、データベースの超高速応答に依存するアプリ（たとえばリアルタイム描画アプリやマルチプレーヤー型ゲームなど）の場合は、Realtime Database の方が「まさにリアルタイム」だと感じられるかもしれません。

パフォーマンスを改善するには

Realtime Database の低レイテンシが求められるプロジェクトを進めている（かつ、大部分のユーザーが北米にいると予想される）場合、もし Cloud Firestore の特有の機能が必要ないのであれば、そのプロジェクトの該当箇所には Realtime Database を使用するとよいでしょう。ただしその前に、以前のブログ投稿や公式ドキュメントを確認して、2 つのデータベースそれぞれのメリットとデメリットを十分に理解しておくことをおすすめします。

理由その 5: 物理的な制約がある

ほぼ完ぺきな状況であっても、利用している Cloud Firestore インスタンスがオクラホマでホストされていて、ユーザーがニューデリーにいる場合、「光の速度」の関係で少なくとも 80 ミリ秒のレイテンシが発生します。そして現実的に、どのネットワーク呼び出しでも 242 ミリ秒前後のラウンドトリップ時間がかかります。そのため、Cloud Firestore がどれほど高速に応答しても、その応答が Cloud Firestore とデバイス間を移動する時間がどうしてもかかってしまうのです。

パフォーマンスを改善するには

まず、単回のフェッチの代わりにリアルタイム リスナーを使用することをおすすめします。クライアントの SDK 内でリアルタイム リスナーを使用すると、非常に優れた多くのレイテンシ補正機能が提供されるためです。たとえば Cloud Firestore は、ネットワーク呼び出しが戻るのを待っている間、キャッシュされたデータをリスナーに提示するため、ユーザーに結果を表示する時間がより高速になります。また、データベースへの書き込みはすぐにローカル キャッシュに適用されます。つまり、デバイスがサーバーによる確認を待っている間に、これらの変更が即座に反映されることがわかるでしょう。

次に、ユーザーの大半が所在する場所でデータをホストするようにします。最初にデータベース インスタンスを初期化する際に Cloud Firestore のロケーションを選択できるので、アプリに最適なロケーションはどこか、コスト面だけでなくパフォーマンス面も含めて十分に検討しましょう。

3 番目の方法としては、量子エンタングルメントに基づいた信頼性の高い安価なグローバル通信ネットワークを実装することが挙げられます。これにより、光の速度の問題を回避できるためです。この対応が済めば、おそらくライセンス料の支払いを終わらせることができ、そもそもどんなアプリを作っていたかも忘れてしまうかもしれません。

最後に

今後、Cloud Firestore のクエリが遅く感じる場面に遭遇したときは、上記の内容に目を通していずれかの状況に当てはまるかどうかを確認してください。なお、アプリのパフォーマンスを確認するには、実際の使用環境でのパフォーマンスを測定するのが一番です。この目的に最適なサービスとして、Firebase Performance Monitoring があります。

Performance Monitoring をアプリに統合して、クエリの実際のパフォーマンスを確認できるようカスタム トレースを 1～2 つ設定してみることをおすすめします。

Reviewed by Sophia Hu - Data Management Specialist, Google Cloud