[go: nahoru, domu]

この記事は デベロッパー アドボケート  Doug Stevensonによる The Firebase Blog の記事 "Firebase Test Lab launches full support for iOS, Robo improvements" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。





Doug Stevenson
デベロッパー アドボケート
2016 年、Test Lab が Firebase とともに最初のリリースを迎えたとき、サポートされていたのは Android 端末のみでした。5 月の Google I/O 2018 で、Test Lab は iOS サポートのクローズド ベータ版をリリースしました。これに含まれていたのは、一部の iOS 端末と基本的な UI でした。
Android で包括的なテストを作成するには、Espresso や UIAutomator を使い、コードを書く必要があります。これはある意味で、アプリを「リモート コントロール」するようなものです。iOS でも、同じように XCTest を使ってテストを実行します。どちらの場合でも、Test Lab はクラウドにある実際の端末群でテストを実行できます。
10 月末、プラハで開催された Firebase Summit で、Test Lab チームは iOS サポートの一般公開についてお知らせしました。10 機種の iPhone と iPad で、iOS 12 を含む 7 種類のバージョンの iOS が稼働しています。また、iOS のドキュメントとコンソール操作も改善されました。

Test Lab では、Robo の改善も数多く行われています。Robo は、Android 端末で実行されるアプリに対して、全自動でテストを行うツールです。以下では、Robo の新機能をご紹介します。

モンキー アクション

ゲームでは、システム ウィジェットを使うよりも UI がカスタマイズされていることが多いため、クロールがしづらくなります。そのため、Robo がゲームのエクスペリエンスをクロールするのも難しくなります。今回より、テスト中のアプリが実際はゲームであることを Robo が検知した場合、ゲームの UI を操作しようと、ランダムにタップやスワイプを行うようになります。これによって、クラッシュやパフォーマンスに関する有用なデータが生成されることがあります。これは、意味のある自動ゲーム クロールに向けて手始めとなる大きな一歩です。

プライベート API の検知

APK で内部 Android API が使われている場合、Test Lab がそれを検知して警告するようになりました。Android P 以降では、このような API を使うとアプリがクラッシュする場合があります。Robo がクロールを行っているときにそのような API へのアクセスが発生すると、端末ログにスタック トレースが記録されるので、アプリのコードのどの場所で違反が起こっているのかがピンポイントでわかります。

行き詰まる時の警告

Robo のクロールが行き詰まると、Test Lab がデベロッパーに警告するようになりました。たとえば、ユーザーに複雑なサインアップ フォームやログイン画面が表示される場合、Robo がフォームの要件を満たすのは難しい場合があります。このような場合、Robo は完全なクロールを継続するための操作をデベロッパーに提案します。たとえば、テスト用の認証情報を提供する、Robo Script を記述するなどです。
定期的にアプリをテストする習慣がない方は、毎日の無料枠を使って Test Lab を試してみてください。Android では、コードを書かなくても APK をアップロードするだけで Robo テストを実行できます。ぜひ、Firebase Slack の #test-lab チャンネルに感想をお寄せください。

Reviewed by Khanh LeViet - Developer Relations Team

この記事は Google Ads API チーム Nadine Sundquist による Google Ads Developer Blog の記事 "Announcing v0_6 of the Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

11 月 30 日更新: 課金の概要について追加しました。本日は、Google Ads API v0_6 ベータ版がリリースされたことをお知らせします。今回のリリースでは、必要機能の要件(RMF)に記載されている機能が提供されます。この新しい API の中核機能が公開されたため、これに対応した計画、設計、コーディングを始めてください。このバージョンでは、引き続き v0 をエンドポイントとして使用できますが、クライアント ライブラリのアップデートが必要になります。主な機能は以下のとおりです。
  • 管理者アカウント認証: 管理者アカウントとして認証する場合、ヘッダーに認証したい管理者アカウントを login-customer-id として追加する必要があります。その後は、通常どおりに、やり取りする顧客をリクエストに設定します。これにより、認証したい管理者アカウント階層のレベルを API に伝えることができます。
  • 複数の変換オペレーション: GoogleAdsService.Mutate に数種類のオペレーションを渡します。
  • 課金: 課金の管理に新しいサービスを利用できます。読み取り専用の PaymentsAccountService を使うと、すべての支払いアカウントの一覧を表示できます。課金設定で支払いアカウントを指定する方法については、BillingSetupService をご覧ください。
  • ホテル広告: GoogleAdsService を拡張し、ユーザーがホテルの実績指標の問い合わせを行えるようになりました。この操作には、これまで Travel Partner APIHotelPerformanceView を使っていました。サポートされる実績指標は、費用、クリック数、インプレッション数、平均リード値です。いくつかの派生指標(平均掲載順位、クリックあたりの平均費用、1000 インプレッションあたりの平均費用、クリックスルー率)も事前に計算されます。これらの指標は、以下のセグメントで分割できます。
    • 旅程セグメント: チェックイン日、チェックイン曜日、予約日数、日付選択種別
    • ホテル セグメント: ホテル センター ID、ホテル ID、クラス、都市、州、国
    • 日付セグメント: 時、日、曜日、週、月、四半期、年
    • その他: キャンペーン、広告グループ、広告ネットワーク、端末
  • フィード: AdGroupFeedServiceCustomerFeedServiceFeedServiceCampaignFeedServiceFeedMappingService でフィードの管理と取得を行います。
  • アカウント管理:
    • CustomerClient を導入し、指定された顧客管理者に対応する顧客クライアントの拡張階層(直接および間接)を取得する機能を提供します。
    • 今回のリリースでは、CustomerService.CreateCustomerClient メソッドを使って管理者の下に新しい顧客クライアントを作成する機能もサポートします。
    • CustomerService で mutate がサポートされました。
  • 最適化案: RecommendationServiceDismissRecommendation メソッドが追加され、ガイドに記載されている最適化案を閉じることができるようになります。
  • 広告フォーマット: Gmail 広告とイメージ広告がサポートされました。
  • 検索語句レポート: SearchTermView リソースが使えるようになり、検索語句レベルで集計した指標が提供されます。SearchTermView は、AdWords API の検索語句パフォーマンス レポートに似た機能を提供します。
  • オーディエンス: UserListService でオーディエンスを作成します。
  • 条件種別: LANGUAGECARRIERUSER_LISTUSER_INTERESTIP_BLOCK の各 CriterionType を使って条件を作成できます。
この API を使ってみたい方は、以下の有用なリソースをご確認ください。
アップデートされたクライアント ライブラリとコードサンプルは、2 営業日以内に公開されます。ご質問やサポートが必要なことがありましたら、フォーラムからご連絡ください。

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Google Ads API チーム、Thanet Praneenararat による Google Ads Developer Blog の記事 "Smart Shopping campaigns are publicly available today" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

AdWords API v201802 では、ホワイトリストに登録された広告主に対して、スマート ショッピング キャンペーンがリリースされました。本日、AdWords APIGoogle Ads API の両方で、この機能をすべてのデベロッパーにリリースいたします。

スマート ショッピング キャンペーンは、自動化と機械学習を組み合わせることで、予算に応じてネットワーク全体でのコンバージョン値を最大化するものです。スマート ショッピング キャンペーン、広告グループ、広告を作成する詳細な手順は、AdWords API ガイドまたは Google Ads API ガイドをご覧ください。

最適なパフォーマンスを得るために、直近 45 日間に既存のショッピング キャンペーン全体に少なくとも 20 のコンバージョンがある状態でスマート ショッピング キャンペーンを作成することをお勧めします。

いつものように、質問や懸念事項がある方は、フォーラムに投稿してください。


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Ben Galbraith & Dion Almaer による Chromium Blog の記事 "Chrome Dev Summit 2018: Building a Faster, Smoother, Capable Web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

本日は(オリジナル記事公開当時)、ウェブ コミュニティの皆さんを 2018 年版の Chrome Dev Summit にお迎えします。これから 2 日間にわたって、プラットフォームの進化を祝うとともに、エコシステム全体の力を借りてウェブを進化させる Google の取り組みについて、最新情報をお伝えします。

Chrome が 10 歳の誕生日を迎えたことは、この 10 年間で Chrome やウェブがどれほど進化してきたかを振り返るきっかけとなりました。皆さんが作成するコンテンツアプリゲームがどれほど高機能になったのかを見るのは、とても楽しいことです。

Chrome に対して行ってきたアップデートの中でも、特に力を入れてきたのがブラウザの高速化です。私たちは、スピードこそがウェブの決定的かつ特に重要な機能の 1 つだと考えています。ユーザーがサイトを見つけてから実際に利用するまでの時間がこれほど短く、サイト間もすばやく移動できるプラットフォームは他にありません。しかし、サイトの読み込みに時間がかかりすぎたり、UI がぎこちなかったりすると、それが台無しになってしまいます。

そこで、エンドユーザーがリンクをクリックした瞬間から楽しく高速な体験を提供できるように、ウェブ デベロッパー コミュニティとの協力関係を強化したいと考えています。

最初のクリックから高速

HTTPArchive によれば、サイトで使われている JavaScript は、平均で 2011 年の 8 倍以上に増加しています。現在、CPU が主要なボトルネックの 1 つになりつつあります。これは、パワー不足のモバイル端末で多くのコードのコンパイルや実行が行われる際に特に顕著になります。

最初の読み込み(およびそれ以降)を重視している企業は、Performance Budget の利用に注目することで大きな成果を上げています。バジェットは、JavaScript、CSS、イメージなどのリソースのバイト数や、その他の読み込み指標に基づいています。たとえば、エミュレートされた 3G ネットワークと特定の種類のスマートフォンで、Time-to-Interactive(操作可能になるまでの時間)を 5 秒以内に指定することができます。

徐々に機能を追加しながら、常にバジェットの範囲内に抑えるのは簡単なことではありません。Wayfair は、リグレッションが発生していることに気づいた後、デベロッパー向けに内部パフォーマンス バジェット システムを構築し、パフォーマンス スコアをトラッキングできるようにしました。それ以降、ページのスピードは向上し続けており、前年比でコンバージョン率が 10% 以上増加しています。

Pinterest は、パフォーマンスを重視してモバイルウェブ体験を再構築したことで、ユーザーの反応やエンゲージメントが上昇しました。現在の Pinterest のモバイル ウェブサイトは、サインアップが最も多いプラットフォームとなっています。この取り組みの詳細は、こちらからご覧ください。



クリック後の動作もなめらかに

ウェブページの読み込みスピードを最適化することは重要ですが、ページの読み込み時やページが表示された後にスムーズでインタラクティブなユーザー エクスペリエンスを実現することも重要です。すべてのユーザーからの入力に 10 分の 1 秒未満ですばやく応答し、ユーザー インターフェースが「ジャンク」しないようにしなければなりません。つまり、UI が停止して突然表示位置が切り替わったりしてはいけないということです。

ここ 10 年間で、私たちはできる限り多くの処理をメインスレッドからオフロードするように Chrome を進化させてきました。たとえば、イメージのデコードや JavaScript の解析を分離し、Web Worker を使えば、UI をブロックせずに長時間にわたって動作する JavaScript を実行できます。

最新のウェブアプリは、どうすればなめらかに動作させることができるでしょうか。特に、重大なワークロードがある場合はどうでしょう。私たちのチームは、このテーマを徹底的に追求しました。その最終結果が、本日リリースする Squoosh という新しいアプリです。この強力なイメージ圧縮ツールは、ほぼ瞬時に起動します。Web Assembly を使ってブラウザに内蔵されていないコーデックを処理するなど、重い作業を行っている場合でも、スムーズな UI を実現しています。これをどのように実現しているかを知りたい方は、本日開催される Jake と Mariko のセッションに注目してください。


この点に関してお伝えしたいことはこれだけではありません。Worklet、Virtual Scroller、スケジューラなど、デベロッパーがスムーズなエクスペリエンスを簡単に構築できるようにするプラットフォーム API も近日中に登場する予定です。このような多くのツールやテクニックについては、2 日目の基調講演以降で紹介します。

統合機能の強化

PWA を使うと、容易にユーザーに満足してもらい、リピート率やコンバージョン率を高めることができます。ホスト OS との統合が強化され、読み込みや実行がさらに高速になった PWA は、実に優れています。しかし統合機能のほとんどは、モバイルファーストあるいはモバイル限定の機能に重点を置いていました。

この半年間で新たにリソースを投入し、すべての PC プラットフォームに同じ機能セットを提供できるようにしています。Chrome OS は、まさにウェブの限界を広げるすばらしいプラットフォームです。そこから得た教訓をもとに、Chrome 72 をターゲットに、PC での PWA サポートを Windows および Linux、Mac 向けの Chrome に拡大いたします。


モバイルと PC の両方に機能を追加するにあたっては、コミュニティにとって重要な機能を優先できるように、皆さんの意見を取り入れたいと考えています。そこで本日、ウェブに求められている機能を把握し、協力しながら皆さんの実際のニーズに対応する取り組みについて、今後の予定をお知らせします。

web.dev によるサポート

すべての最新の Web API のリファレンス情報を 1 か所に集めてほしいという要望は承知しています。そのため、MDN と協力してウェブのコア リファレンス ドキュメントの改善を続けています。

また、すばらしいウェブ体験を提供する方法について、実践的なガイドがほしいという声も寄せられています。そこで本日、新たなアプローチとなる web.dev についてお知らせします。

web.dev は、Glitch の協力のもと、私たちのチームによるベスト プラクティス ガイドを活用して Lighthouse ツールと密接に統合されています。的を絞った直接的なベスト プラクティスと、サイトの高速性、弾力性、可用性を常に保つことができるサイト監視機能によって、皆さんのサイトの改善をサポートします。



web.dev の作業を行っていたとき、学習の参考になるすばらしいウェブ コンテンツに触発されました。Flexbox Zombies と CSS Grid Critters を作成した Dave Geddes 氏は、新たな学習ゲームを作成しました。Service Workies では、Service Worker のすべてを学ぶことができます。現在、冒険の第 1 章がベータ版として公開されています。私たちは、Dave 氏と協力して、すべての冒険を誰もが無料で利用できるようにいたします。早速おばあちゃんの話を聞いてみてください!



ウェブのデザインをブラウザで

Chrome Dev Summit では、おなじみのデベロッパー向けのツールやライブラリの最新情報をすべてカバーしますが、皆さんがフィードバックを送りたくなるような最新の早期アクセス試験運用版機能についてもお知らせしたいと思っています。

Firebug が登場し、ブラウザがデベロッパー ツール プラットフォーム自体になりうることを証明したときの衝撃は忘れることができません。そして今、私たちはウェブ上でデザインを行うことも検討しています。Lighthouse が Chrome 拡張機能として始まったように、ブラウザ内でデザインを可能にするもう 1 つの拡張機能 Project Visbug を提供します。すぐにダウンロードすることもできますが、その前にぜひこちらから動作をご覧ください。


その他のセッションについては、 ライブストリームまたは Chrome Developers Youtube チャンネルの動画をご覧ください。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google ソフトウェア エンジニア、Kristofer Baxter による Accelerated Mobile Pages Project の記事 "WorkerDOM: Concurrency for JavaScript programming with the DOM" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Web Worker から Document Object Model(DOM)を利用できるようにする JavaScript ライブラリ、WorkerDOM のアルファ リリースについてお知らせします。このライブラリを使うと、ウェブ デベロッパーがパフォーマンスを向上させるためにウェブページのプログラミングを行う際に、広く普及しているマルチコア プロセッサ アーキテクチャを活用できるようになります。WorkerDOM ライブラリは、汎用ウェブ プログラミング向けに設計されていますが、AMP Project でも利用する予定です。この点については、後ほど説明します。
このライブラリの基盤となる Web Worker API は、10 年近く前からウェブ デベロッパーが利用できるようになっていますが、広く採用されてきたわけではありません。その理由の 1 つは、Worker からウェブページ、すなわち DOM の操作を行う主な API が利用できないことでした。WorkerDOM は、この点を改善し、デベロッパーが既存のアプリケーションを簡単に移植できるようにします。これによって、ウェブのマルチスレッド プログラミングが新たな脚光を浴び、今後のユーザー エクスペリエンス向上につながることを期待しています。
これまでの調査で、低費用端末向けシングルコア CPU のパフォーマンスは、ここ数年間でそれほど向上していないことがわかっています。その結果、シングルコアという観点から見れば、モバイル端末は安くなってはいるものの、速くなってはいません。これは、非常に安価な CPU にさえ搭載されているにもかかわらず、デフォルトの JavaScript プログラミングでは利用できない追加のコアを活用するまたとないチャンスです。ウェブのパフォーマンスを実際にネイティブ プラットフォームに匹敵させるためには、この追加のパフォーマンスを解放し、人々が使うさまざまな端末すべてに対して、最新の優れたエクスペリエンスを提供しなければなりません。



Screen Shot 2018-08-21 at 10.45.37 AM
どれ 1 つとして同じモバイル端末は存在しない。

WorkerDOM は、Web Worker 内で完全な DOM 表現を提供することを目指しています。つまり、理想的なケースでは、Worker 環境からでもスクリプトを変更せずに利用することができます。このライブラリの中核にあるのは、TypeScript で書かれた効率的な転送メカニズムです。これは、サーバーでレンダリングした DOM をハイドレート(hydrate)し、ユーザーのアクションに対する反応、アニメーションの実行など、アプリケーションがページを変更する際にその変化を仲介します。WorkerDOM ライブラリの内部処理の詳細や、想定されるユースケースについては、私たちが JSConf US 2018 で行ったプレゼンテーションのスライドをご覧ください。
AMP Conf 2018 でお知らせしたように、AMP Project は AMP ページの作成者が JavaScript プログラミングを利用できるようにする長期的な作業を行っています。WorkerDOM ライブラリはこの取り組みの中核をなし、うれしいことに、今年中に AMP に組み込まれます。WorkerDOM は React、Preact、Svelte などのフレームワークと互換性があり、互換フレームワークは今後も増加することがロードマップで示されています。将来的に、こういったすべてのフレームワークを使って AMP ページを作れるようになるのがとても楽しみです!
本日のリリースは、アルファ リリースです。WorkerDOM を使った実験はできるようになりますが、本番環境で広く使うための準備はまだ整っていません。私たちは、フレームワークやツールの作成者と協力して互換性を確保したいと考えています。そして、できるだけ多くの場所や状況で WorkerDOM を使っていただき、デベロッパー エクスペリエンスを向上させたいと考えています。

Reviewed by Yusuke Utsunomiya - Mobile Solution Consultant, gTech

この記事は JavaScript 管理人、Addy Osmani による Chromium Blog の記事 "10 years of Speed in Chrome" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

10 年前に初めてリリースされてから、スピードは Chrome の 4 つの基本原則の 1 つであり続けてきました。私たちはいつも、ウェブ デベロッパーがユーザーに高速で魅力的なウェブ体験を提供できるようにしたいと考えています。Chrome が 10 周年を迎えた今、これまで高速化のために行ってきたこと、今後の予定を紹介したいと思います。

多くのブラウザ コンポーネントがスピードに貢献

V8 は、Chrome の JavaScript および WebAssembly エンジンです。ウェブページで使われる JavaScript の量は増え続けており、それを処理する高速なエンジンは重要な土台となっています。ここ何年かの間に V8 用の新しい JavaScript 実行パイプラインの開発を行い、Ignition(新インタプリタ)や TurboFan(最適化コンパイラ)をリリースしてきました。その結果、Speedometer ベンチマークで 5~10% のパフォーマンスの向上を実現しました。また、スクリプト ストリーミングによって、JavaScript のダウンロードが始まると同時にバックグラウンド スレッドで解析できるようになり、ページの読み込みが最大 10% 早くなりました。さらに、バックグラウンド コンパイルの導入により、メインスレッドのコンパイル時間が最大 20% 短縮されました。

プロジェクト Orinoco の取り組みによってコンカレント ガベージ コレクションを実現し、メインスレッドが解放されてジャンクが減りました。その後は、重点領域を実環境での JavaScript のパフォーマンスに移し、React.js ランタイムのパフォーマンスが 2 倍になり、Vue.js、Preact、Angular などのライブラリのパフォーマンスが最大 40% 改善しました。並列、コンカレント、増分ガベージ コレクションにより、ガベージ コレクションによるジャンクは最初に V8 がコミットされたときに比べて 100 分の 1 まで減少しています。さらに、WebAssembly も実装し、デベロッパーがウェブで JavaScript 以外のコードを予測可能なパフォーマンスで実行できるようにしました。WASM アプリを確実に高速起動できるように、Liftoff ベースライン コンパイラもリリースしました。V8 のパフォーマンスはリリースごとに徐々に増加し、長年かけて 20 倍のパフォーマンスを達成しました。上記の新しいコンポーネントは、その 10 年間積み重ねた努力の中で、まさに最新のコンポーネントです。

これまでの Chrome リリースでの V8 Bench スコア。V8 Bench は、旧 Octane ベンチマークの前身。この図で V8 Bench を使っているのは、Octane と違って初期の Chrome ベータ版を含むすべてのバージョンの Chrome で動作するため。

Chrome は、SPDYHTTP/2QUIC を通して、ネットワーク プロトコルやトランスポート層の進化に重要な役割を果たしています。HTTP/1.1 の制限に対処することを目的とした SPDY は、現在すべてのモダンブラウザがサポートしている HTTP/2 プロトコルの土台となりました。同時に、レイテンシとユーザー エクスペリエンスをさらに改善することを狙った QUIC にも積極的に取り組み、活発な IETF もこの取り組みをサポートしています。QUIC は、YouTube などの動画サービスに大きなメリットをもたらします。QUIC で動画を視聴すると、再バッファリングが 30% 減少することがユーザーから報告されています。

次に紹介するのは、Chrome のレンダリング パイプラインです。レンダリング パイプラインの役割は、ウェブページがユーザーの操作にすばやく反応し、毎秒 60 フレーム(fps)で表示されるようにすることです。Chrome がコンテンツを 60fps で表示するには、1 つのフレームを 16 ミリ秒でレンダリングしなければなりません。これには、JavaScript の実行、スタイルの設定、レイアウトの決定、ピクセルの描画とユーザーの画面への表示などが含まれます。この 16 ミリ秒のうち、Chrome が使う時間が少なければ少ないほど、ウェブ デベロッパーがユーザーの満足度を上げるために使える時間は増えます。レンダリング パイプラインの改善には、再描画が必要になるページ要素の特定方法の最適化や、視覚的に重ならない要素のトラッキングの向上などが含まれます。これによって、画面に新しいフレームを描画する時間が最大 35% 短縮されました。

Chrome チームは 2015 年に RAIL というユーザー中心のパフォーマンス モデルを導入し、先日このモデルが更新された。

メモリ消費量はどうでしょうか。Chrome 63 から 66 の間で、レンダラー プロセスのメモリ使用量が最大 20~30% 削減されています。サイト分離が導入されたので、今後、このメモリ削減に基づいて行うことを模索する予定です。Ignition と TurboFan も、V8 の合計メモリ使用量の削減に貢献しており、V8 をサポートするすべての端末やプラットフォームで 5~10% のメモリが節約できています。今年行われた分析から、ウェブ上のサイトの 7% がメモリリークの影響を受けていたことがわかりましたが、これは完全に修正されています。Chrome のスピードには、DOM や CSS、IndexedDB を始めとするストレージ システムなど、多くのコンポーネントが貢献しています。パフォーマンス改善の詳細については、Chromium ブログの最新記事にご注目ください。

ウェブ デベロッパーによるウェブページの計測や最適化を強化

どこからサイトの改善を始めればよいのかを理解するのは、大変な作業です。その手助けとして、ラボ環境における状況や、ユーザーが実環境で感じる体験について把握できるいくつかのツールを検討しました。長年かけて、Chrome DevTools の Performance パネルは、ウェブページがラボ環境でどのように表示されるかを順を追って視覚化できる強力な方法となりました。サイトでパフォーマンスを改善する余地を見つける手間をさらに軽減するために、Lighthouse の開発も行いました。これは、ウェブサイトの品質を分析し、サイトのパフォーマンスに関する明快な指標とユーザー エクスペリエンスを改善するための具体的な方法を提示してくれるツールです。Lighthouse は、DevTools の Audits パネルを通して直接利用できるほか、コマンドラインからも実行できます。また、WebPageTest などの他の開発用プロダクトにも組み込まれています。
Chrome DevTools の Audits パネルで Lighthouse を実行



Lighthouse によるラボ環境のデータを補完するために、Chrome ユーザー エクスペリエンス レポートをリリースし、ユーザーが実環境で感じる体験の指標となる項目をデベロッパーに提供できるようにしました。レポートには、First Contentful PaintFirst Input Delay などの項目が含まれています。現在、デベロッパーはカスタムサイトのパフォーマンス レポートを作成し、CrUX Dashboard を使って莫大な数のオリジンに対する進捗をトラッキングできるようになっています。

また、たくさんの Web Platform 機能を導入し、デベロッパーがサイトの読み込みを最適化できるようにしています。早い段階で読み込む必要があるリソースをブラウザに伝えられるように、リソースヒント<link rel=preload> を追加しました。Chrome は、Brotli 圧縮WOFF2 ウェブフォント圧縮、イメージの WebP サポートなど、バイト削減をサポートするアプローチを実装したブラウザの先駆けでもあります。

今後、ますます多くのブラウザでこれらの機能がサポートされることを楽しみにしています。Chrome は Service Worker を実装しているので、何度もページにアクセスする際にオフライン キャッシュやネットワーク レジリエンスを活用できます。この機能が幅広くモダンブラウザでサポートされていることをうれしく思います。


実際に、現在の Google 検索は、繰り返し検索を行う際の便宜的キャッシュに Service Worker とナビゲーション プリロードを使っています。これにより、繰り返しアクセスする場合のページの読み込み時間が半分になっています。

将来的に、イメージや iframe のネイティブ遅延読み込み、AV1 などの画像形式を含む新しい標準によって、ユーザーに対して効率的にコンテンツを提供できるようになるでしょう。今からとても楽しみです。

Chrome を使ってデータプラン内でウェブをもっと楽しむ


ここ 10 年間で、ウェブページのサイズは増加の一途をたどっています。しかし、初めてオンラインの世界にデビューする多くのユーザーにとっては、データは法外に高価だったり、耐えられないほど遅い可能性もあります。それに対応するため、ここ数年で、Chrome データセーバーなどのデータを意識した機能がリリースされてきました。データセーバーは、インテリジェントにページを最適化し、データ消費量を最大 92% 削減します。

さらに、データを節約する新しい方法も模索しています。Chrome for Android を対象に、接続速度が遅いユーザーのために、ページをスマートに最適化して重要なコンテンツが最初に表示されるようにする機能の開発を進めています。このようなページ変換によって、完全なページよりもはるかに早く読み込めるようになります。この機能については、再現性、網羅性、パフォーマンスをさらに向上させる作業を続けています。

データやネットワークに制限のあるユーザーのために、ガードレールを設ける実験も行っています。たとえば、Chrome にネイティブ遅延読み込みを導入する方法や、たくさんのデータを使った場合にページの追加リクエストを停止するオプションをユーザーに提供する方法を模索しています。

まだ始まったばかり

これらの変更点は、デベロッパーや企業がユーザーに便利なコンテンツをすばやく提供する際に役立ちます。しかし、まだやるべきことがあります。今後 10 年間で行われるページ読み込みパフォーマンスの改善に乾杯しましょう!


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google Play 学習事業責任者、Dan Lavelle による Android Developers Blog の記事 "Free training for Android developers - learn how to succeed on Google Play" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


すばらしいアプリやゲームのアイデアは、ほんの始まりにすぎません。Google Play の目的は、モバイル向けのアプリやゲームのビジネスを成功させるために必要なツールやスキルを皆さんに提供することです。トレーニングは常に Android デベロッパーから最もリクエストされている機能で、私たちは皆さんのフィードバックを真摯に受け止めました。
そこで、Google Play における皆さんのビジネスの可能性を完全に開花させるため、まったく新しい無償の e ラーニング プラットフォームをリリースいたします。

アプリを成功させるための Google Play Academy のご紹介

Play Academy では、ユーザーを拡大したい方、パフォーマンス指標について理解したい方、収益を上げたい方など、どなたでも Google Play で成功するためのベスト プラクティスや Play Console 機能を学ぶことができます。Play Academy は、多忙な皆さんでも利用しやすいように作りました。自宅や会社のパソコンで学ぶことも、移動中にモバイル端末でコースを受講することもできます。

Play Academy の主な機能

ラーニングパス

機能やベスト プラクティスが盛り込まれた 10 種類のミニコースから選択できます。たとえば、 アプリのリリース前テストアプリの技術的パフォーマンスの評価アプリの収益化などがあります。

インタラクティブな学習

マルチメディアを多用したインタラクティブな e ラーニングで学習できます。

評価

重要な Play Console 機能やモバイルアプリのベスト プラクティスについての新たな知識をテストできます。

実績

新たなスキルをアピールしましょう。Play Academy プロフィールに、堂々たる実績バッジが掲載されます。

今すぐ学習を始めましょう

Google Play の無償の e ラーニング コンテンツは、簡単にご利用いただけます。g.co/play/academy にアクセスしてサインアップを行い、デベロッパーとしての学習の旅を始めましょう。コンテンツは日本語でご利用いただけます。一番下の言語メニューから「日本語」を選択してください。

また、今後の Play Academy ニュースにもご注目ください。皆さんが最新の機能やプログラムから後れをとることなく、アプリやゲームのビジネス拡大に必要な最新情報をタイムリーに入手できるように、コースは定期的にアップデートいたします。

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



Reviewed by Yuichi Araki - Developer Relations Team

Google では、Google Cloud Platform(GCP)を使ってみたい方に向け、 12 月 17 日(月)のハンズオンイベントを皮切りにした 1 か月の間 トライアルキャンペーンを開催します。

今年の Next in Tokyo ‘18 において、オンライン学習プラットフォーム、QWIKLABS 上にある GCP 関連のコードラボが、多数、日本語化されたことが発表されました。QWIKLABS には、約 30 もの、GCPについて学べるコース*1があります。

*1:QWIKLABS では特定のテーマに沿ったコードラボを集めたコースを「クエスト」と呼んでいます。

このコンテンツをより多くのデベロッパーに使っていただくため、Google Developer Relations チームでは、来年、複数回にわたるQWIKLABSのトレーニングキャンペーンを企画しています。来年、デベロッパーの皆さまのニーズに合った形でトレーニングを提供できるよう、今回はトライアルとして、いくつかの異なった参加方法を用意させていただきます。

  1. Google 東京オフィスで行うハンズオンイベントに来場して参加、その後自主学習
  2. Google 東京オフィスで行うハンズオンイベントにオンライン参加、その後自主学習
  3. 自主学習のみ

すべての参加方法において、ご応募いただいた皆さまには QWIKLABS の無料クーポンをお配りします。今回は、GCP 基礎 コースを行っていただきます。来年以降は、毎回別のクエストを行う予定です。

Google東京オフィスにて行うハンズオンイベントは、最初に使い方や、実際のコースで質問がしたい方に向け、12月17日に行います。東京近郊以外の方にもご参加いただけるよう、オンライン参加も可能です。*2。本イベント中は、GCPのエキスパートである Google Developers Experts に質問をしていただくことが可能です。

*2:本キャンペーン終了後のアンケートで、東京以外でのハンズオンイベント開催の要望が多数あった場合、開催を検討したいと思いますので、東京以外の皆さまも、ぜひ今回ご参加いただきお声をお聞かせください。

詳細、申し込み方法についてはこちらのサイトをご覧ください。皆さまのご参加をお待ちしています。


Posted by Serene Yu Okawa - Developer Relations Team

この記事は Flutter グループ プロダクト マネージャー、Tim Sneath による Google Developers Blog の記事 "Flutter 1.0: Google’s Portable UI Toolkit" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

本日の Flutter Live では、Google の UI ツールキットの最初の安定版リリースとなる Flutter 1.0 についてお知らせしています。Flutter を使うと、1 つのコードベースから iOS と Android の両方で美しいネイティブ エクスペリエンスを作成することができます。

現在のクロスプラットフォーム モバイル開発は、妥協だらけです。デベロッパーは、複数のオペレーティング システムで複数回同じアプリを構築するか、ネイティブのスピードや移植の正確さを犠牲にして最低限の共通項となるソリューションを受け入れるかのどちらかを選ばざるをえません。Flutter を使うと、両方の良い部分を兼ね備えたソリューションを実現できるはずです。つまり、人気のモバイル オペレーティング システムをどちらも対象にして、ネイティブ ARM コードとハードウェア アクセラレーションを活用したグラフィックや UI を利用できます。

Flutter の概要

Flutter は、従来の Apple や Android のモバイルアプリ構築モデルを置き換わるものではありません。Flutter はアプリエンジンで、既存のアプリに埋め込むことも、まったく新しいアプリを作成する際に使うこともできます。
私たちは、Flutter の特徴を 4 つの側面から考えています。
  1. Flutter を使うと、美しいアプリを構築できます。私たちは、基盤となるフレームワークの制限に縛られることなく、デザイナーが最大限に創造性を発揮できるようにしたいと考えています。Flutter は、画面上のすべてのピクセルまで制御でき、グラフィック、動画、テキスト、コントロールを何の制約もなく重ねたりアニメーションさせたりできる強力な描画機能を備えています。Flutter にはフルセットのウィジェットが含まれており、iOS と Android の両方でピクセルパーフェクトなエクスペリエンスを提供できます。さらに、Google のデジタル エクスペリエンス向けオープン デザイン システムであるマテリアル デザインを最大限に実現しています。
  2. Flutter は高速です。Chrome や Android と同じく、ハードウェア アクセラレーションに対応した Skia 2D グラフィック エンジンを活用できます。Flutter は、乱れることのないグラフィックを端末のネイティブ スピードで提供できるように設計されています。Flutter のコードには、世界トップクラスの Dart プラットフォームが使われています。Dart は、iOS および Android 向けに 32 ビットおよび 64 ビットのネイティブ ARM コードにコンパイルできます。
  3. Flutter は、高い生産性を誇ります。Flutter には、 ステートフル ホット リロードが導入されています。これは、モバイルのデベロッパーやデザイナーにとって革命的な新機能で、アプリに対して繰り返し行う作業がリアルタイムで反映されます。ステートフル ホット リロードを使うと、アプリのコードを変更した結果を即座に確認できます。アプリを再起動する必要はなく、状態が失われることもありません。ステートフル ホット リロードは、デベロッパーのアプリ開発方法を変革します。ユーザーへのアンケートによると、デベロッパーの開発サイクルの生産性は 3 倍以上向上しています。
  4. 最後に、Flutter はオープンです。Flutter は、BSD スタイルのライセンスによるオープンソース プロジェクトで、世界中の数百人に及ぶデベロッパーの貢献によって支えられています。さらに、たくさんのプラグインが提供されている活発なエコシステムが存在します。すべての Flutter アプリは、標準の Android および iOS のビルドツールを使うネイティブ アプリです。そのため、Android では Kotlin や Java、iOS では Swift や Objective-C で書かれたコードや UI を含め、基盤となるオペレーティング システムの機能をすべて利用できます。
このすべてを統合し、Visual Studio Code や、Android Studio、IntelliJ などお好みのプログラマー向けエディタに対応した最高水準のツールと組み合わせれば、1 つのコードベースから iOS と Android の美しいネイティブ エクスペリエンスを構築できる開発環境、Flutter が手に入ります。

Flutter の拡大と勢い

Flutter の最初のベータ版についてお知らせしたのは、10 か月前の Mobile World Congress でした。大変うれしいことに、Flutter はあっという間に広くコミュニティに受け入れられました。その証拠に、1.0 のリリース前にもかかわらず、Apple や Google Play のストアには既にたくさんの Flutter アプリが並んでいます。デベロッパーが UI 開発への新しいアプローチを待ちわびているのは明らかです。
当初より、Flutter は Google のさまざまなプロダクトに利用されています。Google 広告の iOS および Android アプリは、既に Flutter への切り替えが完了しています。1.0 がリリースされる前から、Abbey Road Studios、Alibaba、Capital One、Groupon、Hamilton、JD.com、Philips Hue、Reflectly、Tencent をはじめとする世界中のさまざまなお客様が Flutter でアプリを開発または提供しています。
Capital One チームのエンジニアリング上級ディレクター、Michael Jones 氏は、Flutter の利用について次のように述べています。
「Flutter の高パフォーマンスなクロスプラットフォーム開発という独自の機能は、本当にすばらしいです。当社のエンジニアは迅速に開発できるという確約とホット リロード機能を高く評価しており、この 1 年間でネイティブ統合を中心にフレームワークが大きな飛躍を遂げたことも見てきました。
Capital One は Flutter を使うことで、機能を「iOS ファーストか Android ファーストか」ではなく、真のモバイル ファースト モデルで考えられるようになりました。Flutter 1.0 の登場をうれしく思うとともに、進化のペースやエンジニアリング コミュニティの期待の大きさに驚いています」
本日の Flutter Live イベントでは、人気の決済サービスの Square が Flutter で簡単に商品やサービスを決済できる 2 つの新しい Flutter SDK を発表しました。対面で Square の支払いリーダーを使うことも、モバイルアプリ内で支払いを受けることもできます。Square は、果物を育てて太平洋岸北西部の農産物直売所で販売している家族農場 Collins Family Orchards のアプリを使い、支払い SDK のサンプルのデモを行いました。

Collins Family Orchards アプリのデベロッパーである Dean Papastrat 氏は、その経験について次のように述べています。
「本番ビルドのアニメーションや画面遷移のスピードに驚かされました。ウェブ デベロッパーなら、簡単に Flutter に移行できます。たった 1 週間で支払いを受け取ることができる完全なアプリを作れたなんて、とても信じられません」
さらに Flutter Live では 2Dimensions が、デザイナー向けの画期的な新ツール Flare のリリースを発表しました。このツールを使えば、直接 Flutter アプリに埋め込んでコードで操作可能なベクター アニメーションを作成できます。Flare を使うと、あるアプリでデザインして、別のアプリでアニメーションさせ、それを端末固有のアセットやコードに変換するという作業を省略できます。

Flare で作成したアニメーションは、ウィジェットとして既存の Flutter アプリに埋め込み、完全なコンポジタの一部として追加したり、別のテキストやグラフィック レイヤー、または UI ウィジェットなどと重ね合わせることができます。このような形でアプリに組み込むことで、アニメーションが他のアーキテクチャによる「ブラック ボックス」的な制限を受けることがなくなり、アプリが完成する瞬間までデザイナーとデベロッパーが連携できるようになります。このように Flutter と Flare は緊密に統合されているので、洗練されたモバイル エクスペリエンスを作成したいと考えているデジタル デザイナーやアニメーターには、非常に魅力的で他にはない選択肢となります。
Flutter に期待を寄せているもう 1 つのパートナーが Nevercode です。Nevercode は、モバイルアプリ用の継続的インテグレーションおよびデリバリ(CI/CD)ツールのプロバイダとして、急成長を遂げています。同社は Flutter Live で Codemagic を発表しました。これは Flutter 専用に設計された新ツールで、Android と iOS の両方で 1 つの自動操作から簡単に、Flutter アプリのビルドおよびパッケージ化プロセスを自動化できます。本日は、Codemagic のベータ版が公開されています。Flutter プロジェクトを含む GitHub リポジトリを選択すると、わずか数クリックで、テストを実行してバイナリ アプリバンドルを生成する継続的ビルドフローを作成できます。このバンドルは、Apple や Google Play のストアにアップロードできます。
デベロッパーがベータ版以降の Flutter を使って開発したさまざまなアプリをまとめて紹介する、短い動画を作成しました。

Flutter 1.0 の新機能

私たちは最初のベータ版以降、Flutter の機能追加や品質向上に取り組んできました。特に、新しいウィジェットによるピクセルパーフェクト iOS アプリのサポートを完成させ、20 ほどの Firebase サービスのサポートを追加し、Flutter アプリのパフォーマンス向上とサイズの縮小に対応しました。さらに、コミュニティからのフィードバックに基づき、数千に及ぶ問題を解決しました。
Flutter には、最新バージョンとなる Dart プラットフォーム 2.1 も含まれています。Dart 2 へのアップデートでは、コードサイズの縮小、型チェックの高速化、型エラーに関するユーザビリティの向上が提供されます。Dart 2.1 には新たな言語機能も追加されており、ユーザー エクスペリエンスを構築する際の生産性が向上します。既に Dart 2.1 を採用しているデベロッパーからは、最新のエンジンに切り替えるだけで大幅にスピードが向上したという声が寄せられています。

1.0 リリースではバグの修正と安定化を主眼としていますが、2 つの主要なデベロッパー向け新機能のプレビューも追加しています。これは、2019 年 2 月に予定している次の四半期のリリースに含まれる機能を、プレビュー モードで試していただくためのものです。具体的には、 アプリに追加プラットフォーム ビューの 2 つです。

アプリに追加

私たちが最初に Flutter を開発したとき、ゼロから新しいアプリを作るシナリオでの生産性に重点を置いていました。しかしもちろん、誰もが何もない状態からスタートできるわけではありません。多数のお客様との会話を通して、既存アプリのユーザーを対象とした新機能に Flutter を使ったり、既存アプリを徐々に Flutter に変換するという用途があることが明らかになりました。
すべての Flutter アプリにはホスト Android および iOS コンテナが含まれているので、Flutter のアーキテクチャはこのモデルをうまくサポートできます。しかしもっと簡単に、少しずつ Flutter を採用できるように、テンプレートやツール、既存アプリ向けのガイドを更新しています。Flutter とホストコードとの間でアセットを簡単に共有できるようにする対応も行いました。また、ツールを手直しして、デバッガやアプリケーションを起動しなくても既存の Flutter プロセスに簡単に接続できるようにしています。
今後も、操作性を向上させるための作業を継続します。アプリに Flutter を追加するためのガイドは、既にたくさんの方に活用していただいていますが、サンプルを追加し、複雑なシナリオのサポートを強化する作業は現在も続いています。当面の間、既存アプリに Flutter を追加する手順は Wiki に掲載します。その他の作業の状況は、GitHub プロジェクト ボードで確認できます。

プラットフォーム ビュー

アプリに追加機能は、既存アプリに少しずつ Flutter を導入する方法としては便利ですが、逆に Android または iPhone プラットフォームのコントロールを Flutter アプリに埋め込むと便利な場合もあります。
そこで、プラットフォーム ビュー ウィジェット(AndroidViewUiKitView)を導入しました。この機能を使うと、各プラットフォームにこの種のコンテンツを埋め込むことができます。これまで数か月にわたって Android サポートのプレビューを行ってきましたが、そのサポートを iOS にも拡大し、この機能を活用できる Google マップWebView などのプラグインを追加できるようにします。

他のコンポーネントと同じく、プラットフォーム ビュー ウィジェットもコンポジション モデルの一部になっています。つまり、このウィジェットも他の Flutter コンテンツと統合することができます。たとえば、上のスクリーンショットの右下隅にあるフローティング アクション ボタンは、背景色のアルファが 50% になっている Flutter ウィジェットです。ここから、Flutter 独自のアーキテクチャのメリットがよくわかるでしょう。
この機能はデベロッパーに試していただける状態になっていますが、パフォーマンスや端末の互換性を改善する作業が続いているので、PlatformView を使うアプリをデプロイする際は十分注意してください。プラットフォーム ビューの最適化作業を積極的に続けており、次の四半期アップデートで製品版として利用できるようになる見込みです。

モバイル以外の Flutter

今まで、Flutter の主なターゲットは iOS と Android でした。しかし、私たちは、モバイル以外にも幅広いプラットフォームに Flutter を展開したいと考えています。実は、Flutter は元来、ピクセルが描画できるところならどこにでも対応できる柔軟性を持ったポータブル UI ツールキットとして設計されています。
この作業の一部は、既に公開されています。Flutter Desktop Embedding は、Flutter を Windows、MacOS、Linux などのデスクトップ オペレーティング システムで動作させるための初期段階プロジェクトです。さらに先日、完全なデスクトップ環境を含まない小規模端末に対する Flutter の埋め込みサポートのデモとして、Flutter を Raspberry Pi で使うための非公式詳細情報を公開しました。
今週の Flutter Live では、Flutter が動作する場所を飛躍的に拡大させる現在実験中の試験運用版プロジェクトについても、ほんの少しだけ紹介しました。

Hummingbird は、ウェブベースの Flutter ランタイム実装で、ネイティブ ARM コードへのコンパイルだけでなく、JavaScript にもコンパイルできるという Dart プラットフォームの機能を活用しています。これにより、何の変更も加えることなく、Flutter コードを標準ベースのウェブで実行できるようになります。

Hummingbird の実装の詳細を含む技術情報は、Medium の別のブログ記事に記載しています。2019 年の Google I/O では、Hummingbird についてもっと詳しくお伝えする予定です。どうぞお楽しみに!
もちろん、現在はモバイルが最優先であることは間違いありません。今後数か月間で、中核であるモバイル シナリオへの大きな注力の成果をご覧いただけるはずです。

まとめ

Flutter 1.0 のリリースと合わせて、既存のベータ版、開発版、マスター版の各チャンネルに加え、新たに「安定版」チャンネルを作成しました。安定版チャンネルの更新頻度は他のチャンネルよりも少なくなりますが、このチャンネルのビルドは他のチャンネルによって吟味されているため、品質の高さは確実です。安定版チャンネルは、四半期ごとに一番実績のあるビルドでアップデートする予定です。
Flutter 1.0 は、ウェブサイト https://flutter.io からダウンロードできます。このサイトには、他のフレームワークから移行するデベロッパー向けのドキュメントや、コードラボ一般的なサンプルを取り上げたクックブック技術解説動画も掲載されています。
これまで共に歩み、フィードバックの提供、問題の特定、コンテンツの作成、汎用プロダクトの検討などの際に助力してくださった先行ユーザーの皆さんには、とても感謝しています。Flutter コミュニティは、私たちにとってプロジェクトとして最高の資産の 1 つであり、このオープンソース プロジェクトについて気にかけ、献身的に奉仕し、あたたかく、多様で、有能な皆さんのおかげで成り立っています。本当にありがとうございます!

ぜひ Flutter をご利用ください。皆さんは何を作りますか?


Reviewed by Takuo Suzuki - Developer Relations Team

この記事は Google AMP Project プロジェクト マネージャー、Eric Lindley による Accelerated Mobile Pages Project の記事 "What’s new in AMP, Q4 2018" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


AMP の新たなオープン ガバナンス モデル

別のブログ投稿で、AMP Project の新たなガバナンス モデルへの移行方針について説明しています。

AMP Linker

ブラウザがサードパーティの Cookie アクセスを制限する場合、AMP Linker が新たな方法でユーザー セッションを同期します。詳細やウェブページでの実装方法については、ブログ投稿によるお知らせをご覧ください。

amp-next-page による「無限スクロール」

<amp-next-page>(試験運用版として利用可能)は、いわゆる「無限スクロール」する記事をサポートします。ユーザーが一定量ページをスクロールすると、デベロッパーが指定した最大 3 つの URL を読み込むことができます。各ドキュメントは、インラインでシームレスに読み込まれます。
image1


amp-orientation-observer による傾きと連動したアニメーション

端末の傾きと指定したアニメーション フレームを低レベルで同期させる <amp-orientation-observer> がリリースされました。この機能を利用すると、ページの背景のわずかな移動、イメージのパン、傾きに応じたアニメーションなど、さまざまな効果を実現できます。シーン上で重なり合った複数のコンポーネントを異なる速度で移動させて、レイヤーに対応した 3D 空間を作成することもできます。
image4


amp-image-slider によるイメージの比較

<amp-image-slider> を使うと、2 つのイメージを重ねて比較することができます。これは、「事前と事後」の写真を表示するような場合に特に便利です。このコンポーネントの詳細については、先日のブログ投稿をご覧ください。
image2


Google アド マネージャーによる AMP ストーリーの広告サポート(ベータ版)

Google アド マネージャーが、サイト運営者によって生成される AMP ストーリーでの直販広告の提供をサポートしました。詳細については、こちらをご覧ください。




image3
ストーリー ページの 1 つに表示される Google Pixel 2 の広告

その他の主な新機能

  • いくつかの新しいコンポーネントをリリースしています。
    • インライン インタラクティブ コンテンツのパンとズームをサポートする <amp-pan-zoom>。これを使うと、商品イメージの詳細を確認する、インタラクティブなシートマップで座席を選択するなど、さまざまなユースケースに対応できます。
    • フォームに日付や日付の範囲を入力する <amp-date-picker>。以前は試験運用版としてリリースされていましたが、一般公開版となりました。詳細はこちらをご覧ください。
    • 指定された日付や時間まで動的にカウントダウンを行う <amp-date-countdown>
    • Word ドキュメント、Excel スプレッドシート、PDF などのドキュメント ファイルを AMP ページ内にインライン表示する <amp-google-document-embed>
  • 既存の <amp-lightbox> コンポーネントを表示または非表示にする場合のトランジションをカスタマイズできるようになりました。
  • MOAT で、AMP HTML 広告の視認性計測機能と迷惑広告検知機能がベータ版サポートとしてリリースされました。ベータ版に参加したい方は、MOAT にご連絡ください。
  • こちらの手順によって、メール プロバイダが AMP for Email と統合できるようになりました。

近日中にリリースされる特筆すべき機能

  • 関連記事を読みながら動画の視聴を続けたい、またはレシピの説明を読みながら実際に調理の様子を見たいと思ったことはないでしょうか。近日中に、<amp-video> の “dock” 属性で、ユーザーがページをスクロールしたときに動画をビューポートの隅に最小化する機能がサポートされます。これにより、デベロッパーは動画がドッキングする場所や方法をカスタマイズできるようになります。
  • 近日中に、<amp-video-iframe> で amp-video やその他のサードパーティ製動画コンポーネントで使える一連の機能(たとえば、前述の動画最小化など)がサポートされます。これは、iframe に埋め込んだ動画が対象となります。
  • ドキュメントの「無限スクロール」を行う <amp-next-page> と同様に、リストのページ要素でも近日中に同じ動作がサポートされます。この機能は、検索結果や商品カードなどのリスト要素を無限にスクロールさせる場合に便利です。
  • インプット マスキングによって、デベロッパーが指定した空白文字や区切り文字などの書式が自動的に追加されるようになり、ユーザーのフォーム入力が効率化されます。
  • IAB の透明性と同意に関するフレームワークとサードパーティ CMP 統合機能が、<amp-consent> の一部として近日中にサポートされます。AMP ページへの IAB 同意フレームワークの組み込みを希望する CMP またはサイト運営者は、GitHub からご連絡ください。
  • <amp-ima-video> プレーヤーが拡張され、新機能とバグの修正が行われました。消えたミュートおよびミュート解除ボタンの追加、再生中の非表示コントロールの修正、動画のループ再生機能などが含まれています。
  • PC のスティッキー広告で、ページの左端または右端に位置が固定されるケースがサポートされます。
* * *
作業したりフィードバックを寄せてくださっている AMP 開発コミュニティの方々に感謝いたします。いつものように、問題や機能リクエストがありましたら遠慮なくお知らせください

Reviewed by Yusuke Utsunomiya - Mobile Solution Consultant, gTech

※イベントのご案内
INEVITABLE ja night - “インターネットの次にくるもの”
                  第 7 回 コネクティッド社会に向けた不可避な流れ
日 程 : 2018 年 12 月 14 日(金) 19:00 〜 21:00(開場 18:30 より)
スピーカー:
  • 玉川 憲 氏(株式会社ソラコム 代表取締役社長)
  • 饗庭 秀一郎 氏(JapanTaxi 株式会社 データエンジニア)
  • 登 不二雄 氏(インフォメティス株式会社 Co-founder ネットワーク技術主幹)他
申し込み:お申し込みサイト

Google Cloud に代表されるクラウド技術の進化が引き起こすその先の世界を、機械学習、VR / AR、IoT などの領域で活躍されている方々と一緒に議論するイベント「INEVITABLE ja night」。 9 月 18 日に開催した第 6 回目のイベントは、「日本の情シスを巡る不可避な流れ」をテーマに、現役の CIO や情シスでの業務経験のある方々をお招きして、日本企業における情報システム部門は今後どのような役割を果たすべきか、どのように進化すべきか、さらには、情シス的な人材が今後どのように活躍できるのかについて、議論しました。


現役 CIO が語る情シスの現状と未来

前半のテーマは「現役 CIO に聞く。情シスと CIO の役割を巡る不可避な流れ」ということで、以下の3名の方に登壇いただきました。
  • 友岡 賢二さん(フジテック株式会社 常務執行役 情報システム部長)
  • 成田 敏博さん(株式会社ディー・エヌ・エー 経営企画本部 IT 戦略部部長)
  • 金山 裕樹さん(株式会社スタートトゥデイテクノロジーズ 代表取締役 CINO(Chief Innovation Officer))

(左から、友岡さん、成田さん、金山さん。聞き手は小島 英揮さん(Still Day One 合同会社 代表社員 パラレルマーケター・エバンジェリスト))
「クラウドとモバイルを組み合わせることがまずは重要だが、日本の製造業の多くはまだそのレベルには達していない。先進的な取り組みを社内でどのように説得し、導入を促進するか」(友岡さん)「ビジネスの現場の方が IT に詳しい企業において情シスが果たす役割の一つがチームワークを活性化する”ビジネスコラボレーションハブ”を実現すること」(成田さん)「ビジネス変革のために IT をどう活用し、”コーポレートエンジニアリング”を実現するか」(金山さん)と、それぞれの立場から情シスの現状と将来への期待を語っていただきました。

業界も、会社における情シスの役割も異なる御三方ですが、共通する考えもあるようです。たとえば、いずれも社内システムは内製化を積極的に進めているとのこと。自らの手を動かすことで課題解決を人任せにせずに進めることが大切であり、また、構築したシステムは、運用の過程で、仮説立案・検証・改善というフィードバックループを回していくことで、システムの価値を高めていくべきと述べていました。こうした変化は、開発や運用をいっしょに行う社外パートナーとの付き合い方にも影響しているとのこと。IT サービスを購入・試用し、前述のフィードバックループを共に回せるパートナーが求められていると言います。

さらには、自社内のみならず他社や異業種との交流も推進しているそうです。様々なノウハウを競合他社を問わずに共有することで、新たな知識を得たり技術力を磨くことができるだけでなく、自らを客観的に評価できるようになるとのこと。情シスに所属しているメンバーは社外のコミュニティにどんどん参加すべきだということも、3 名の一致した意見でした。

参加者からは、CIO のロールモデルとして三者三様の考え方に共感したという声も多数あがったセッションでした。

クロスオーバー時代にみる情シス的キャリア

イベント後半は、金融業界から 2 名のゲストを招いて、情シス的な人材が金融の分野で活躍するには何をすべきか、キャリア形成の観点から様々なお話を語っていただきました。

  • 大久保 光伸さん(株式会社 Blue Lab 最高技術責任者(CTO))
  • 黒須 義一さん(株式会社みずほ銀行 個人マーケティング部 シニアマネージャー )

(左:大久保さん、右:黒須さん)
現在、5 社目の大久保さんと 4 社目の黒須さん。それぞれのキャリア形成は異なるアプローチでした。大久保さんは、自らが理想とするスキルマップを描き、不足しているスキルや経験を身につけるために転職を繰り返してきたそうです。特に、外部コミュニティに参画して、さまざまな背景を持つ人々との交流を通じて、自分に足りないものが何かを意識し始めたとのこと。コミュニティに参加する重要性がここでも語られていました。

一方、黒須さんは「この業種、この会社に勤めたいというよりも、自分が関わることで世の中にインパクトを与えられることが実現できるか」を重視しているとのこと。自らを「わらしべ長者的キャリア」と語るように、ルート営業、データセンター事業のアライアンス開拓、クラウド導入支援と、その時に所属した企業で身につけた技術や知識、経験を次の職場でどのように活かすかを心がけてきたそうです。「敵を作らない対人スキルとテクノロジーを噛み砕いてわかりやすく説明するスキル」も大切であると、黒須さんは語っていました。

今回の INEVITABLE ja night は、過去 5 回とは異なり、テクノロジーではなく、それを使う情シスという組織をテーマにお送りしました。今回登壇された 5 名のゲストスピーカーそれぞれの考え方は、イベントの参加者にとって、大いに刺激になったようです。


Posted by Takuo Suzuki - Developer Relations Team

この記事は Chrome DevTools チームによる Chromium Blog の記事 "10 Years of Chrome DevTools" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Chrome が 10 周年を迎えました!オープンで協調的、協力的なウェブ開発コミュニティが実現していることを皆さんに感謝します。DevTools は、たくさんのプロジェクトからインスピレーションを得ています。ここでは、DevTools がどのように登場し、年とともにどう変化してきたのかを振り返りたいと思います。

はじめに Firebug ありき

デベロッパー ツールが搭載されていなかったブラウザを想像してみてください。その場合、JavaScript をどうやってデバッグするのでしょうか。基本的には、3 つの選択肢があるでしょう。
  • コードのあちこちで window.alert() を呼び出す
  • コードの一部をコメントアウトする
  • JavaScript の神様が解決策を授けてくれるまで、じっとコードを見つめる
レイアウトの問題や、ネットワークのエラーはどうでしょう。ここでも、実際に行えるのは、コードの中で骨の折れる実験を行うことだけでした。2006 年までは、それがウェブ開発の現実でした。その後、Firebug というちょっとしたツールが登場し、すべてが変わりました。

Saying Goodbye to Firebug より転載した Firebug の Net パネルのスクリーンショット(出典およびライセンス

Firebug は、ページのデバッグ、編集、監視をリアルタイムに行える Firefox の拡張機能です。その途端、ページについて何もわからない状態にあったウェブ デベロッパーは、現在のデベロッパー ツールの実質的な中核機能を使えるようになりました。Firefox がなぜそのような動作になるかを厳密に理解できるようになったことで、ウェブに創造性があふれることになりました。Firebug がなければ、Web 2.0 の時代は到来しなかったことでしょう。

WebKit Web Inspector

Firebug のリリースとほぼ同時期に、何名かの Google エンジニアがやがて Chrome となるプロジェクトに着手しました。Chrome は、最初からさまざまなコード ライブラリのマッシュアップでした。Chrome エンジニアは、レンダリングにオープンソース プロジェクトである WebKit を使いました。WebKit は、現在も Safari で利用されています。WebKit を使うメリットの 1 つに、Web Inspector という便利なツールが付属していたことがあげられます。

Web Inspector Redesign から転載した Web Inspector のスクリーンショット(出典およびライセンス

Firebug の Net パネルと同じように、この最初の Web Inspector も見覚えがあるでしょう。ほとんどの機能は、現在の Chrome DevTools の Elements パネルに受け継がれています。Web Inspector は Firebug の数日後にリリースされ、Safari はデベロッパー ツールが直接バンドルされた初めてのブラウザになりました。

「Inspect Element」の時代

Chrome は、ブラウザ エコシステムに多くの革新的なアイデアをもたらしました。たとえば、検索とアドレスバーを組み合わせたオムニボックス、1 つのタブがハングしてもブラウザ全体がクラッシュしないようにするマルチプロセス アーキテクチャなどです。しかし、私たちが最も満足しているイノベーションは、すべてのビルドですべてのユーザーにデベロッパー ツールが提供され、マウスのクリックだけで使えるようになったことです。

2010 年の「Inspect Element」


Chrome 以前のデベロッパー ツールはオプトイン機能であり、Firebug のように拡張機能をインストールするか、現在の Safari のようにフラグを設定しなければなりませんでした。Chrome は、すべてのブラウザ インスタンスでデベロッパー ツールを使えるようにした初めてのブラウザです。私たちは、最初からデベロッパーが親しみやすいブラウザを作るという壮大なビジョンを持っていました。しかし、実際問題として、初期の Chrome にはたくさんの互換性の問題(誰も Chrome 向けに構築していなかったので、これは当然のことです)があり、そういった問題を簡単に修正できる方法をウェブ デベロッパーに提供する必要がありました。ウェブ デベロッパーから便利な機能だという声が寄せられたので、この機能はその後も継続されることになりました。


モバイルの時代


DevTools プロジェクトの最初の数年間で行ってきたのは、本質的に Firebug や Web Inspector から始まった物語にいくつかの章を追加するような作業でした。DevTools へのアプローチにおいて次の大きな転換点は、明らかなスマートフォン時代の到来です。
このすばらしい新世界における私たちの最初のミッションは、デベロッパーが開発マシンから実際のモバイル端末のデバッグを行えるようにすることでした。この仕組みは、リモート デバッグと呼ばれています。実は、DevTools はリモート デバッグを処理する上で絶好の位置にありました。これは、Chrome のマルチプロセス アーキテクチャが生んだもう 1 つの成果です。私たちは、DevTools プロジェクトの初期のころから、デバッガがマルチプロセス ブラウザに確実にアクセスする唯一の方法は、ブラウザをサーバー、デバッガをクライアントとして、クライアント サーバー プロトコルを使うことであるという点に気づいていました。このプロトコルは、モバイル Chrome の登場時点で既に組み込まれていました。そのため必要なことは、開発マシンで実行されている DevTools がこのプロトコルを使ってモバイル端末で実行されている Chrome と通信できるようにすることだけでした。このプロトコルは、Chrome DevTools Protocol と呼ばれており、現在も DevTools のバックボーンであり続けています。

リモート デバッグ

リモート デバッグは正しい方向に向かう一歩であり、現在も実際のモバイル端末でサイトが問題なく動作することを確認する主なツールであり続けています。しかし、時間とともに、リモート デバッグはやや煩雑に感じるようになりました。サイトや機能の構築の初期段階にある場合、一般的に必要になるのはおおまかなモバイル機能だけです。そこで、次のようなモバイル シミュレーション機能を作ることにしました。
  • タッチベースの入力、端末の画面の向きのシミュレーションを含む厳密なモバイル ビューポートのエミュレーション
  • ネットワーク接続の帯域を絞ることによる 3G のシミュレーション、CPU の制限による能力の低いモバイル ハードウェアのシミュレーション
  • ユーザー エージェント、位置情報、加速度計データなどの偽装

これらの機能は、まとめて Device Mode と呼ばれています。





Device Mode の初期プロトタイプ



2018 年時点の Device Mode





パフォーマンスの時代


モバイルの時代が幕を開け、Gmail などの大型アプリがウェブ機能の限界を突破していきました。その一方で、Gmail 規模のバグには、Gmail 規模のツールが必要となりました。そこで、Chrome がページを表示するために必要な処理について、すべての内訳を順を追って厳密に表示するようにしました。これは、私たちが行ったツール エコシステムに対する最初の大きな貢献の 1 つとなりました。

Chrome デベロッパー ツールの機能強化で発表された最初の Timeline パネル


2018 年時点の Performance パネル

こういったツールは正しい方向に向かう一歩でしたが、最適化できる場所を見つけるためには、ブラウザの動作について細かい部分まで把握し、たくさんのデータを分析する必要がありました。そこで先日、この機能をベースにして開発を行い、パフォーマンスについての詳しい分析を提供できるようにしました。新しい Lighthouse エンジンは、Audits パネルで活用され、さらに CI システムと統合できる Node モジュールとしても利用できるようになっています。

Audits パネルに表示されるパフォーマンス提案

Node.js の時代

2014 年頃まで、私たちは DevTools が主に Chrome ですばらしい体験を構築するためのツールだと考えていました。しかし、Node の台頭によって、ウェブ エコシステムにおける私たちの役割の再考が求められることになりました。

Node が登場して最初の数年間、Node デベロッパーは、Firebug が登場する前のウェブ デベロッパーや、Timeline パネルが登場する前の Gmail デベロッパーのような状況にありました。つまり、Node アプリの規模が Node ツールの規模を上回っていたのです。Node が Chrome の JavaScript エンジンである V8 で動作していることを考えれば、DevTools がこの溝を埋める候補となることは自然なことです。Node のデバッグをサポートし、ブレークポイント、コードのステップ実行、ブラックボックス化、トランスパイルされたコードのソースマップなどの通常の DevTools 機能を利用できる DevTools は、2016 年に登場しました。
Node Connection Manager



DevTools プロトコル エコシステム

Chrome DevTools Protocol(CDP)という名前を聞くと、DevTools のみが使う API であるように思うかもしれません。しかし実際はそれよりも汎用的で、プログラムから Chrome にアクセスできる API になっています。ここ数年間で、このプロトコル エコシステムに加わるサードパーティ製のライブラリやアプリケーションがいくつか登場しています。
  • プロトコルへの低レベル JavaScript アクセスを提供する chrome-remote-interface
  • 1 段階上の抽象化を提供し、最新の JavaScript API と自動更新に対応したヘッドレス Chrome ブラウザの自動化を実現する Puppeteer
  • ページのパフォーマンスと品質を改善する方法を見つける処理を自動化する Lighthouse

うれしいことに、これらのパッケージを使って Chrome と高度なインタラクションを行うたくさんのプロジェクトが登場しています。ツールの開発や自動化のビジネスに携わっている方は、ぜひこのプロトコルを確認し、皆さんの領域で新たなチャンスを開くことができないかを調べてみてください。たとえば、VS Code チームや WebStorm チームは、それぞれの IDE で JavaScript デバッグを実現するために、この機能を使っています。


次のステップ

私たちのミッションの中心にあるのは、皆さんがウェブですばらしい体験を構築するために役立つツールを開発することです。どんなプロダクトや機能を開発するかという判断にあたっては、皆さんのフィードバックを非常に重視しています。

このような活発なコミュニティを実現していただき、ありがとうございます。皆さんとともにウェブを作り上げる次の 10 年間を楽しみにしています。

Reviewed by Eiji Kitamura - Developer Relations Team