Posted:
[この記事は シニア タスク マスターの Sami Kyostila、Ross McIlroy による Chromium Blog の記事 "Scheduling tasks intelligently for optimized performance" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

4 月のはじめ、Chrome ではユーザーに迅速に早くページを表示する新しい技術を導入しました。これはパフォーマンスを向上する重要な技術ですが、そのための取り組みのうちの 1 つではありました。ページが完全に読み込まれた後でも、アニメーションがすみやかに表示され、スクロールやクリックへの反応が迅速であることをユーザーは求めるでしょう。Chrome 41 ではレンダリング エンジンにタスク スケジューラを実装し、こうした優先順位の高いタスクがすみやかに処理されるようにしています。これでさらに Chrome の動作が軽快になり、滑らかな 1 秒間に 60 フレームの動きに近づきます。

この大きな目標を前提として、Chrome ではフレームの生成をミリ秒単位で行っています。ただし、画面にグラフィックを描画するタスクは Chrome で完結するものではなく、1 つのプロセッサで複数のタスクが同時に処理されます。かつて Chrome では、ちょうど銀行がお客様の列を処理するように、並び順で先頭から、画像のアニメーション、クリックへの応答、メモリ処理など複数のタスクが実行されていました。このやり方はシンプルで簡単ですが、パフォーマンスの効率化という意味では必ずしも最適なものではありません。次のフレームを画面に描画するなどの優先度の高いタスクも、キューの最後尾に並ばなければならない可能性があります。これでは毎秒 60 フレームという目標は達成できません。
Chrome 41 から、「Blink」レンダリング エンジンに統合するタスク スケジューラを作成しました。スケジューラは処理待ちのタスクを検証し、ユーザー アクションに対するアニメーションや応答などの優先度の高いタスクを先に表示する機能を備えます。使用されていないメモリの解放など優先度の低いタスクは、プロセッサに余裕ができるまで処理を遅らせられます。実際これによって、Chrome でフレームの描画を集中的に処理している際のユーザー入力への応答が 40% 早まるという結果が生じています。
ただし、どんなに高度なスケジューラでも、その後に何が発生するか不明なものについては、適切に優先順位を付けることはできません。この問題に対処するため、「Blink」スケジューラは Chrome のグラフィック エンジンにも統合されます。このエンジンではグラフィックを画面に描画するため、Chrome で他のタスクの優先順位を下げる必要があるタイミングを正確に認識します。これによってスケジューラは、Chrome で次のフレームを描画する必要が生じる前の「アイドル」タイムを有効に活用して、優先度の低いタスクを処理できるようになります。優先度の低いタスクは原則的に、毎秒 60 フレームのアニメーションに何の影響も与えずに処理されます。
最新の Chrome で負荷の高いウェブサイトをスクロールした様子。
スケジューラが有効(左)、無効(右)。
この変更で示しているのは、パフォーマンスとは単に物事を早く行うことだけでなく、よりスマートに、適切な順序で、適切なタイミングで行う、ということを意味するということです。Chrome のスケジューラを使ってさらにパフォーマンスを向上させる試みについて、今後もご期待ください。

Posted by Eiji Kitamura - Developer Relations Team

Posted:
[この記事は Frederic Mayot、Google Play チームによる Android Developers Blog の記事 "Integrate Play data into your workflow with data exports" を元に、荒木が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Play デベロッパー コンソールでは、アプリやゲームを公開して、ビジネスを育て、収益化するために必要なノウハウを身に着けられるよう、豊富なデータを用意しています。現在デベロッパー コンソールに用意されている表示機能だけでなく、さまざまな形でデータを取得して分析したいという開発者のニーズにお応えして、財務情報、クラッシュデータ、ユーザー レビューなどがエクスポートできるようになりました。また、アプリやゲームに関するさまざまな統計情報 (インストール数、評価、Google クラウド メッセージング (GCM) の登録数など) に Google Cloud Storage からアクセスできるようになります。

Google Play デベロッパー コンソールの新しいレポート セクション

デベロッパー コンソールに [レポート] タブが加わり、エクスポートできるすべてのデータを 1 か所で確認できるようになっています。

Google Play データにアクセスする確実な方法

Google Play デベロッパー コンソールの統計情報をダウンロードする、最も簡単で確実な方法です。インストールに関する統計情報、レビュー、クラッシュ情報、収益情報などのすべてのレポートにアクセスできます。

プログラムから Google Play データを利用

Google Cloud Storage を利用する新しいアクセス方法を使うことで、さまざまな可能性が広がります。たとえば次のようなことをプログラムで実行できるようになります。
  • インストール数や収益のデータを社内のダッシュボードにインポートする
  • カスタマイズした分析を実行する
  • クラッシュと ANR のデータを任意のバグ管理システムにインポートする
  • 任意の CRM システムにレビューをインポートして、フィードバックをチェックしたりユーザーに返信したりする
データには Google Cloud Storage のバケットからアクセスできます。一番簡単なのは、gsutil を使う方法です。まずはじめに、次の 3 つのステップにしたがってレポートにアクセスします。
  1. gsutil ツールをインストールします。
    • Google Play デベロッパー コンソールのログイン情報を入力してアカウントの認証を行います。
  2. 新しい [レポート] セクションでレポートのバケット ID を確認します。
    • バケット ID は pubsite_prod_rev で始まります (例: pubsite_prod_rev_1234567890)。
  3. gsutil ls コマンドを使用すると、ディレクトリとレポートの一覧が表示されます。gsutil cp コマンドでレポートをコピーできます。レポートは、パッケージ名と作成日 (年月) ごとにディレクトリに分類されています。
レポート データのエクスポートについて詳しくは、Google Play デベロッパー ヘルプセンターを参照してください。

Google Play と Cloud Platform のデータ アクセスについて: Google Play デベロッパー アカウントがアクセスするのは、Google Play がオーナーになっている、レポート専用で、読み取り専用の Google Cloud Storage バケットです。Google Cloud Storage を既に使用していても、ほかのデータには影響はなく、Google Play デベロッパー アカウントと接続されることはありません。Google Cloud Storage を使用している場合、データの保存については利用規約をご覧ください。

Posted By Yuichi Araki - Developer Relations Team

Posted:
[この記事は Rich Hyndman、デベロッパー アドボケートによる Android Developers Blog の記事 "New Android Code Samples" を元に、荒木が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Android Wear、Android for Work、NFC、画面キャプチャに関する新しい Android コードサンプルが GitHub の Google Samples リポジトリにコミットされました。ここでは、新しいコードサンプルの概要を紹介します。
XYZTouristAttractions
このサンプルでは、実際のモバイル端末と Android Wear アプリの連携を模擬的に再現しています。洗練されたデザインで、モバイルアプリから対応する Wear 側コンポーネントと通信してデータをやり取りする方法を具体的に示したサンプルになっています。

アプリ自体は、観光名所を巡る場面を想定したもので、注目すべきポイントに近づくとユーザーに通知する、というものです。同時に、Wear のコンポーネントが観光名所の画像と概要を表示し、GridViewPager の UI コンポーネントで最寄りの観光名所に関するクイック アクションを表示します。

DeviceOwner - デバイス オーナーとは、デバイスのセキュリティや設定を管理できる特別な権限を持ったデバイス管理者です。このサンプルでは DevicePolicyManager を使ってデバイス オーナーの機能を利用する方法を紹介しています。グローバル設定の構成 (時刻やタイムゾーンの自動設定など) や標準ランチャーの設定が含まれます。

NfcProvisioning - このサンプルでは、NFC を使って、デバイス オーナーが設定されたデバイスをプロビジョニングする方法を示しています。このサンプルをデフォルトのまま使用すると、DeviceOwner のサンプルを使ってピアデバイスを設定します。設定を書き換えて他のデバイス オーナーを使用することもできます。

NFC BeamLargeFiles - Android 4.1 以上で Android ビームを使ってサイズの大きなファイルを転送する方法を示しています。NFC で最初のハンドシェイクを行った後、Bluetooth や WiFi Direct など、次の高速な通信チャンネルを使ってファイルを転送します。

ScreenCapture - Android Lollipop で MediaProjection API が加わり、画面上のコンテンツのキャプチャやシステム オーディオの録音が簡単にできるようになりました。ScreenCapture では、この API を使ってデバイスの画面をリアルタイムにキャプチャし、SurfaceView に表示する方法を紹介しています。

さらにおまけとして、Android アプリの Santa Tracker や、3 つのゲーム、2 つのウォッチフェイスなどもオープンソースで公開され、GitHub から入手できるようになりました。
この新しいサンプルも、Android のほかのサンプルと同じように、組み込みのサンプルのインポート機能を使って Android Studio からアクセスできます。また、サンプル ブラウザからもアクセスできます。
コードサンプルをチェックして、開発にお役立てください。

Posted by Yuichi Araki - Developer Relations Team

Posted:
[この記事は Security Team Engineer である Niels Provos による Online Security Blog の記事 "A Javascript-based DDoS Attack as seen by Safe Browsing" を元に、山口が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

ユーザーを悪質なコンテンツから守るため、セーフ ブラウジングのインフラでは、仮想マシン上のウェブブラウザを使ってウェブページを分析しています。この分析により、ユーザーのコンピューターを悪用しようとする JavaScript など、悪質なコンテンツがページに含まれていないかどうかを判定できます。機械学習アルゴリズムによって検査対象を選択しながら、毎日数百万のウェブページを分析することで、全体的にはウェブのかなりの部分を網羅的にチェックできています。

3 月中旬、中国の検閲状況をモニタリングする GreatFire に対して大規模な DDoS (分散型サービス拒否) 攻撃があったことがさまざまなサイトで報じられました。研究者による徹底的な分析の結果、この DDoS 攻撃は、害のないウェブ コンテンツをインターセプトした通信事業者によって実行されており、そのコンテンツから悪質な JavaScript のインジェクションが行われるという新しい形であることが明らかになりました。今回のケースでは、baidu.com でホストされていた JavaScript と HTML リソースが、攻撃対象のドメインのリソースに対して繰り返しリクエストを行う JavaScript に置き換えられていました。

セーフ ブラウジングではネットワーク レベルでトラフィックをチェックすることはできませんが、HTTP プロトコル レベルのトランザクションは確認できます。そのため、セーフ ブラウジングのインフラでもこの攻撃は確認されていました。セーフ ブラウジングのデータから、この攻撃の詳しい経緯を突き止め、どのようなインジェクションがいつ行われたのかを明らかにできます。

今回、このブログポストに際し分析したのは、2015 年 3 月 1 日から 4 月 15 日までのデータです。セーフ ブラウジングで baidu.com ドメインに対するコンテンツのインジェクションがはじめて観察されたのは、2015 年 3 月 3 日です。対象期間内で最後にインジェクションが確認されたのは 2015 年 4 月 7 日となっています。この状況は、下記のグラフでも確認できます。このグラフでは、時間の経過にともなうインジェクション数の推移を、観察された全回数に対する割合 (%) で示しています。
攻撃は、いくつかの段階を踏んで実行されていることがわかります。第 1 段階はテスト段階のようで、3 月 3 日から 6 日まで実行されています。最初のテストの標的は 114.113.156.119:56789 で、リクエスト数は意図的に制限されています。3 月 4 日から 6 日にかけてリクエスト数の制限が外されています。

次の段階は 10 日から 13 日にかけてで、まず標的となった IP アドレスは、203.90.242.126 で、パッシブ DNS では、sinajs.cn ドメインのホストにこの IP アドレスが割り当てられています。13 日には攻撃対象が拡大され、d1gztyvw1gvkdq.cloudfront.net も標的となります。当初は HTTP リクエストだけが使用されていますが、アップグレードされて HTTPS も使用されるようになっています。14 日になると攻撃が本格化しはじめ、HTTP と HTTPS の両方を使って d3rkfw22xppori.cloudfront.net を狙っています。このホストに対する攻撃は 17 日まで続きます。

18 日には攻撃対象のホストが増え、以下のホストが標的となっています。d117ucqx7my6vj.cloudfront.net, d14qqseh1jha6e.cloudfront.net, d18yee9du95yb4.cloudfront.net, d19r410x06nzy6.cloudfront.net, d1blw6ybvy6vm2.cloudfront.net.また、ここではじめて、トランケートされるインジェクションが見つかっています。これは、JavaScript の一部が切り捨てられて機能しないものです。この段階の攻撃の途中で、CloudFront のホストが greatfire.org をはじめとするドメインに対して 302 リダイレクトの送信を開始します。JavaScript の置き換えは 3 月 20 日には完全に終了していますが、HTML ページへのインジェクションは続いています。JavaScript の置き換えでは元のコンテンツの機能が損なわれますが、HTML へのインジェクションはそうではありません。このケースでは、次のように、元のコンテンツに加えて攻撃用の JavaScript にもアクセスするように HTML が変更されています。

<html>
<head>
<meta name="referrer" content="never"/>
<title> </title>
</head>
<body>
    <iframe src="http://pan.baidu.com/s/1i3[...]?t=Zmh4cXpXJApHIDFMcjZa" style="position:absolute; left:0; top:0; height:100%; width:100%; border:0px;" scrolling="yes"></iframe>
</body>
<script type="text/javascript">
[... regular attack Javascript ...]


この場合、ウェブブラウザは同じ HTML ページを 2 回取得を試みますが、t というクエリ パラメータがあるため 2 回目のリクエストではインジェクションが発生しません。攻撃対象のドメインも変更され、dyzem5oho3umy.cloudfront.netd25wg9b8djob8m.cloudfront.netd28d0hakfq6b4n.cloudfront.net が狙われています。この段階が始まってからおよそ 10 時間後に、標的となったサーバーからほかのドメインに対して 302 リダイレクトが返されます。

CloudFront のホストに対する攻撃は 3 月 25 日に終了しています。代わって github.com でホストされているリソースが標的となります。最初に新たな標的となったのは github.com/greatfire/wiki/wiki/nyt/ で、すぐに github.com/greatfire/github.com/greatfire/wiki/wiki/dw/ もこれに加わります。

3 月 26 日には、それまで難読化されていなかったスクリプトが、packer で難読化された攻撃用 JavaScript に置き換えられ、github.com/greatfire/github.com/cn-nytimes/ が新たな標的となります。ここでも、トランケートされるインジェクションが見つかっています。GitHub に対する攻撃は 2015 年 4 月 7 日で終了したようで、この対象期間中で最後のインジェクションが観察されています。

3 月初めから 4 月に入って攻撃が終了するまでに、JavaScript のペイロードの置き換えが 19 種類確認されています。それぞれを MD5 チェックサムに置き換えて、その割合を円グラフにしたのが下の図です。
HTML インジェクションの場合、挿入先の URL によってペイロードが異なるため、対応する MD5 チェックサムはここに記載しません。ただし、挿入された JavaScript は上記のペイロードとほぼ同様のものです。

セーフ ブラウジングでは、以下の 8 つの baidu.com ドメインとそれに対応する IP アドレスでコンテンツのインジェクションを検出しました。
  • cbjs.baidu.com (123.125.65.120)
  • eclick.baidu.com  (123.125.115.164)
  • hm.baidu.com (61.135.185.140)
  • pos.baidu.com (115.239.210.141)
  • cpro.baidu.com  (115.239.211.17)
  • bdimg.share.baidu.com (211.90.25.48)
  • pan.baidu.com (180.149.132.99)
  • wapbaike.baidu.com (123.125.114.15)
挿入された JavaScript のペイロードのサイズは 995~1325 バイトとばらつきがありました。

本記事が、今回の攻撃について明らかになった事実をもとにその全体像を理解する助けとなれば幸いです。また、総合的な分析によって、ウェブ上で何が起きているのかがかなりはっきりとわかることもご紹介しました。セーフ ブラウジングで確認できる HTTP のレベルでは、この攻撃の犯人を特定することはできません。それでも、攻撃が起こった後に詳細な分析を行えば、攻撃自体を隠ぺいするのは困難だということは明らかです。

もしもウェブ上のトラフィックがすべて TLS で暗号化されていたら、このようなインジェクション攻撃はそもそも不可能だったでしょう。今回の騒動は、通信の暗号化や完全性保護を重視する方向へとウェブを向かわせる契機のひとつとなるでしょう。とはいえ、このような攻撃に対する防御策を講じるのはウェブ オペレーターにとって簡単なことではありません。今回のケースでは、攻撃用 JavaScript はシーケンシャルにウェブリソースへのリクエストを送信しているため、レスポンスの速度を落としていれば、全体的な攻撃のトラフィック量を抑えることができた可能性もあります。また、このような攻撃が外部から把握されうるという事実が、今後は抑止力として働くことが期待されます。

Posted by Yoshifumi Yamaguchi - Developer Relations Team

Posted:
Google Developers Group (GDG)コミュニティの皆さんが主催する開発者向けイベント「GDG DevFest Japan 2015 Summer」が 2015 年 6 月 20 日(土)に日本各地で開催されます。

DevFest は Google が主催するのではなく、日本各地で活動する GDG コミュニティの皆さんが開催し、講演し、学び教えあうということが特徴です。

今回の DevFest では 5 月 28 日から 29 日にサンフランシスコで行われた Google I/O 2015 の報告会を行うことになりました。



今年の Google I/O に参加した Google Developers Expert や GDG Organizer をはじめ、多くの開発者の皆さんが日本各地に集まり、Android, Android Wear, Material Design などのセッションの解説やイベントの様子、そこで得られたさまざまな情報をまとめて報告するというイベントになります。

会場は以下の 8 ヶ所です。各会場は常時 Google+ ハングアウトオンエアで繋がっており、会場間の交流を行い、全会場の様子をネット中継で配信する予定です。

参加を希望される方は、会場ごとに参加お申し込みフォームが用意されていますので、ご登録をお願いします。詳しくはイベントサイトをご覧ください。

■イベント概要

■Google I/O 報告会 東京会場

日時: 2015 年 6 月 20 日(土)、13:00 - 18:00 (受付 12:30 -) 18:00-21:00 懇親会
場所: サイバーエージェント、渋谷マークシティ
参加費: 無料
定員: 230 名(先着順)
主催: GDG 東京
協力: Google、サイバーエージェント


■Google I/O 報告会 石巻会場

日時: 2015 年 6 月 20 日(土)、13:00 - 18:00 (受付 12:30 -) 18:00-21:00 懇親会
場所: イトナブ石巻
参加費: 無料
定員: 30 名(先着順)
主催: GDG 石巻
協力: Google、一般社団法人イトナブ石巻


■Google I/O 報告会 信州会場

日時: 2015 年 6 月 20 日(土)、13:00 - 18:00 (受付 12:30 -) 18:00-19:30 懇親会
場所: 塩尻インキュベーションプラザ(http://sip.shiojiri.com/access/
参加費: 無料
定員: 40 名(先着順)
主催: GDG 信州
協力: Google


■Google I/O 報告会 名古屋会場

日時: 2015 年 6 月 20 日(土)、13:00 - 18:00 (受付 12:30 -) 18:30-20:30 懇親会
場所: 株式会社エイチーム(http://www.a-tm.co.jp/
参加費: 無料
定員: 50 名(先着順)
主催: GDG 名古屋
協力: Google


■Google I/O 報告会 京都会場

日時: 2015 年 6 月 20 日(土)、13:00 - 18:00 (受付 12:30 -) 18:00-20:00 懇親会
場所: 京都リサーチパーク
参加費: 無料
定員: 60 名(先着順)
主催: GDG 京都・ GDG 神戸
後援: 京都リサーチパーク株式会社
協力: Google


■Google I/O 報告会 中国会場

日時: 2015 年 6 月 20 日(土)、13:00 - 18:00 (受付 12:30 -) 19:00-21:00 懇親会
場所: 広島国際学院大学 中野キャンパス(広島市)
参加費: 無料
定員: 50 名(先着順)
主催: GDG 中国
後援: 広島国際学院大学
協力: Google


■Google I/O 報告会 四国会場

日時: 2015 年 6 月 20 日(土)、13:00 - 18:00 (受付 12:30 -) 19:00-21:00 懇親会
場所: 愛媛大学 総合情報メディアセンター 1F 大ホール(松山市)
参加費: 無料
定員: 50 名(先着順)
主催: GDG 四国
協力: Google


■Google I/O 報告会 九州会場

日時: 2015 年 6 月 20 日(土)、13:00 - 18:00 (受付 12:30 -) 18:00-21:00 懇親会
場所: 九州産業大学 情報科学部(地図:http://goo.gl/EOTfV8)
参加費: 無料
定員: 50 名(先着順)
主催: GDG 九州
協力: Google


<お申し込み方法>


会場毎にお申し込み方法が異なります。詳しくは以下をご覧ください。

東京会場:https://goo.gl/9fcLt6
石巻会場:https://goo.gl/eQzdAV
信州会場:https://goo.gl/Elv6cx
名古屋会場 :https://goo.gl/fht5Kn
京都会場 :https://goo.gl/2lUAb3
中国会場 :https://goo.gl/MG0m1J
四国会場 :http://goo.gl/nBhDdO
九州会場 :http://goo.gl/KqtZvO

皆様のご参加を心よりお待ちしております。


Posted by Takuo Suzuki - Developer Relations Team

Posted:
[この記事は ソフトウェアエンジニアの Steven Robertson(最近視ているのは "St. Lucia - Before The Dive." )による YouTube Engineer and Developers Blog の記事 "VP9: Faster, better, buffer-free YouTube videos" を元に、山口が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

ますます多くの人が、さらに高画質な動画を、より多くの画面で視聴するようになっているため、使用する帯域幅を増やさずに高解像度を提供できる動画フォーマットが必要になっています。そのため、私たちは YouTube 動画を VP9 でエンコードするようになりました。VP9 はオープンソースのコーデックで、他の一般的なコーデックが使用する帯域幅の半分で、ハイビジョンに加えて 4K (2160p)画質も再生できます。

VP9 は現在広く使われている中で最も効率のよい映像圧縮コーデックです。昨年 1 年間だけでも、YouTube ユーザーが再生した VP9 動画は 250 億時間を超えており、そのうち数十億時間分の動画は、VP9 による帯域幅効率の向上がなければ HD 画質で再生できなかったでしょう。VP9 の再生に対応する端末も増えているため、この技術を簡単に紹介したいと思います。

VP9 の仕組み

動画の情報量は膨大です。カメラセンサーが撮影に使うフォーマットと同じフォーマットで動画を保存するとしたら、そのファイルはとてつもない大きさになります。4K RAW 動画は最大 18,000 Mbps になるでしょう。現在の動画圧縮技術では、撮影されたシーンに含まれる特徴をコード化し、その特徴の動きと変化を追跡することによって、カメラセンサーではなく人間が見るように動画を捉えます。この圧縮はカメラセンサーによる録画に比べて数百倍効率がよく、おかげでビデオストリーミングが可能になりました。

VP9 はそれまでのコーデックと基本原理は同じですが、動画再生の品質をバイト単位で高めるために、WebM チームがさまざまな改良を施して完成させました。たとえば、VP9 のエンコーダーではよりくっきりした画像の特徴が優先して処理され、VP9 コーデックでどのような画像でも鮮明でブロックノイズなく、連続再生できるように非対称変換が用いられています。

Janelle Monaé を通信速度 600Kbps で VP9 と従来の H.264 変換で視聴した場合の質の違いを次の画像で比べてみてください。


高品質な動画視聴を実現

この新しいフォーマットは、すぐに視聴できる高品質でバッファ不要の動画という目標に、すべての人を一段階近づけます。つまり、従来は YouTube でバッファなく最大 480p までの動画しか見ることができなかったインターネット接続環境でも、VP9 のおかげで滑らかな 720p の動画が見られるようになりました。

帯域幅に制限があったり、データ使用量による従量課金プランを使ったりしている人にとっても VP9 はメリットがあります。ビットレートを約半分に削減することで、再バッファしたりかける費用を増やしたりすることなく、360p の画質を視聴できるユーザーの数が劇的に増加します。

4K 動画の世界へ

(本稿の著者を含め)常によりよい画質を求める人にとって、急成長しつつある 4K 動画への世界を開く鍵が VP9 です。実際、VP9 は動画サイズが大きくなると、これまでのコーデックよりもさらに効率がよくなるため、すでに多くの YouTube 視聴者が 4K コンテンツを途切れずにストリーミングしており、その数はますます増えています。YouTube にアップロードされた 4K 動画は昨年 1 年間で 3 倍になり、VP9 のおかげで将来を見据えたストリーミングの改善を計画できるようになっています。検索フィルタを使うと 4K 動画を探すことができます。また、このおすすめプレイリストもご確認ください。

VP9 を利用できる端末

Google パートナーの各種端末メーカーのおかげで、現在では Chrome ブラウザ、Android 端末(サムスン Galaxy S6 など)、テレビやゲーム機(ソニー、LG、シャープ)などで VP9 のデコーディングがサポートされています。2015 年以降、業界全体で 20 を超えるパートナー各社が VP9 に対応する製品を発売する予定です。

自身の VP9 コンテンツを制作する詳細については、FFMpeg encoding guideAdobe Adobe Premier WebM プラグイン をご確認ください。

Posted by Yoshifumi Yamaguchi - Developer Relations Team

Posted:
[この記事は Developer Programs Engineer の Kalyan Reddy による Google Apps Developer Blog の記事 "New Advanced services in Apps Script" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Apps Script には、Gmail や Google ドライブなどの主なプロダクト向けのビルトインサービスが含まれています。そして最近、アドバンス Google サービスとしてデベロッパーから要望され続けてきたその他の API を追加しています。4 月 6 日に次の 7 つのアドバンスサービスを追加しました。
Apps Script の他のアドバンスサービスと同様に、使用前にサービスを有効にする必要があります。サービスを有効にすると、他の組み込み Apps Script サービスと同じように簡単に使うことができます。エディターはオートコンプリート機能を備えており、認証フローが自動的に処理されます。

Apps Activity のアドバンスサービスを使用して、Google ドライブにある特定のファイルを操作したユーザーのリストを取得する方法を表すサンプルを次に示します。
function getUsersActivity() {
  var fileId = 'YOUR_FILE_ID_HERE';
  var pageToken;
  var users = {};
  do {
    var result = AppsActivity.Activities.list({
      'drive.fileId': fileId,
      'source': 'drive.google.com',
      'pageToken': pageToken
    });
    var activities = result.activities;
    for (var i = 0; i < activities.length; i++) {
      var events = activities[i].singleEvents;
      for (var j = 0; j < events.length; j++) {
        var event = events[j];
        users[event.user.name] = true;
      }
    }
    pageToken = result.nextPageToken;
  } while (pageToken);
  Logger.log(Object.keys(users));
}
上記の関数では、AppsActivity.Activities.list() メソッドを用いて drive.fileIdsource といった必須パラメーターを送り、ページトークンを使ってアクティビティの全リストを取得しています。このメソッドで利用できるパラメーターの全リストについては、Apps Activity API の参照資料をご確認ください。

Posted by Eiji Kitamura - Developer Relations Team