...
この記事は Mike Cloonan による Google Ads Developer Blog の記事 "Adding New Resource Types to ChangeStatus in Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

現在、change_status レポートにいくつかの新しいリソースタイプを追加する作業を懸命に進めています。今後、shared_set や asset などを改善する予定です。これらのタイプは今後のバージョンの Google Ads API で完全にサポートされますが、そのために現在行っているインフラストラクチャの変更作業によって、既存のバージョンにも多少の影響が発生します。

新しいリソースタイプのサポートが追加されると、すべてのバージョンの API で新しい行を取得できるようになります。その際に、すでにリリースされているバージョンでは、resource_type が UNKNOWN として返却されます。具体的には、これまで CAMPAIGN などの既知の resource_type が返されていた行で、UNKNOWN リソースタイプが返される場合があります。これが発生するのは、これまで CAMPAIGN の変更と報告されていた変更が、実際には CAMPAIGN_ASSET の変更だった場合などです。今後のバージョンの API は CAMPAIGN_ASSET リソースタイプを認識しますが、既存のバージョンは認識しないので、UNKNOWN を使うしかありません。この行には、新しい resource_name も関連付けられ、アセットの ID が含まれるようになります。

その行の新しいリソース名には、変更の種類を表す識別子が含まれます。最新の識別子のリストは、ステータス変更ガイドをご覧ください。これを調べる必要があるのは、UNKNOWN リソースタイプが含まれる行だけです。これにより、今後の API バージョンでそのリソースタイプが完全にサポートされたときに返されるリソースタイプがわかります。

change_status レポートには、新しいリソースタイプを複数追加する予定なので、さまざまな新しいリソースタイプに対して UNKNOWN タイプが出現する可能性があります。これが表示されるのは、今後のリリースによって change_status レポートで新しいリソースタイプがサポートされるためなので、ご安心ください。

質問がある方は、サポートを受けることができるようにフォーラムに投稿してください。


- Google Ads API チーム、Mike Cloonan
Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

...
この記事は Google Chrome、プロダクト マネージャー、Janice Wong による Chromium Blog の記事 "An experiment in helping users and web publishers create deeper connections on Chrome" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

 現在のユーザーは、メーリング リストの購読、通知、RSS など、多くの方法でお気に入りのウェブサイトの最新情報を得ています。これを 1 人で管理するのは大変なので、オープンな RSS ウェブ標準をベースに、簡単な操作で Chrome から直接お気に入りのサイトの最新情報を取得する方法を検討しています。Google のビジョンは、ユーザーがウェブ上のお気に入りのパブリッシャーやクリエイターと直接つながれるようにすることです。

今後数週間のうちに（元記事公開当時）、米国で Chrome Canary を使っている一部の Android ユーザーに、試験運用版のフォロー機能が表示されます。これは、フォローしているサイトの最新コンテンツを取得する機能です。この機能の目的は、ユーザーが Chrome のフォローボタンをタップすることで、大規模なパブリッシャーから小さな近所のブログまで、興味のあるウェブサイトをフォローできるようにすることです。ウェブサイトでコンテンツが公開されると、[New Tab] ページの新しい [Following] セクションから、フォローしているサイトの最新情報を確認できます。




この Chrome の試験運用機能では、サイトの RSS を最新に保つことで、ユーザーに最新のコンテンツを提供できます。この機能の試験運用を終えて Chrome で幅広く展開するかを評価する際には、ウェブ パブリッシャー向けに詳しいガイドをお伝えしたいと思います。

Chrome を通してユーザーとウェブ パブリッシャーの深い交流をサポートしたいので、パブリッシャー、ブロガー、クリエイター、そしてオープンウェブの住民（皆さんのことです！）からの試験運用に関するフィードバックをお待ちしています。Twitter の @WebCreators や、webcreators@google.com へのメールを通じて、最新情報を入手したり質問したりすることもできます。

この記事は Chromium Blog の記事 "Chrome 92: Web Apps as File Handlers, New JavaScript Features, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

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

File Handling API

ウェブアプリでファイルの読み取りと書き込みができるようになったので、次の論理的なステップは、デベロッパーがファイルの作成や処理をするウェブアプリをファイル ハンドラとして宣言できるようにすることです。File Handling API は、まさにそれを行います。たとえば、テキスト エディタ PWA が自身をファイル ハンドラとして登録すると、オペレーティング システムのファイル マネージャーで .txt ファイルを右クリックし、この PWA に（常に、または 1 回だけ）.txt ファイルを開くように指示できます。つまり、ファイル マネージャーで（ダブル）クリックするだけで、PWA を利用できます。

Excalidraw のコンテキスト メニュー


これにより、PWA ユースケースのユーザー エクスペリエンスが改善され、これまでよりも OS のアプリに近くなります。次に例を示します。

  • テキスト エディタ、スプレッドシート アプリ、スライドショー作成ツールなどのオフィス アプリケーション
  • グラフィック エディタやドローイング ツール
  • ビデオゲームのレベルエディタ ツール

ファイル ハンドリングのオリジン トライアルは 92 で始まり、2021 年 8 月末ごろまで続く予定です。この機能の詳細については、ウェブ アプリケーションをファイル ハンドラにするをご覧ください。このリリースのその他のオリジン トライアルについては、以下のオリジン トライアルをご覧ください。

オリジン トライアル

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

新しいオリジン トライアル

Shared Element Transitions

Shared Element Transitions を使うと、シングルページ アプリケーション（SPA）とマルチページ アプリケーション（MPA）の両方でシンプルな画面遷移を実現できます。デベロッパーはユーザー エージェントが提供する遷移効果の中から選ぶだけでよいので、最低限の作業でページの視覚的な洗練度が向上します。シングルページ アプリでは、この機能がない場合、アニメーションと DOM 操作を慎重に連動させなければ望む効果を実現できないので、画面遷移効果を実現するのは困難です。マルチページ アプリでは、ページが制御できるのは自身のビューだけなので、画面遷移効果を実現できない場合がほとんどです。今回のオリジン トライアルは、SPA のユースケースのみに対応します。

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

アプリのショートカット機能の変更

ほとんどの Android ランチャーで、以前は 4 つまでアプリのショートカット機能を登録できましたが、今後は 3 つだけになります。サイト設定へのショートカットが Android ランチャーのアプリアイコンに追加され、アプリのショートカット機能のスロットが 1 つ減ることになります。詳しくは、アプリのショートカット機能でものごとをすばやく行うをご覧ください。

CSS

@font-face の size-adjust ディスクリプタ

@font-face に size-adjust ディスクリプタが追加され、特定のフォント フェイスで CSS の font-size や em などの派生指標に影響を与えることなく、グリフのサイズのスケーリングができるようになりました。CSS の font-size は、フォントを描画するボックスのスケール ファクタと見なされます。ボックス内のグリフのサイズはフォントによって異なりますが、size-adjust を使うと、さまざまな種類のフォントでサイズを合わせることができます。そのため、このディスクリプタを使ってフォールバック フォントとプライマリ ウェブフォントのマッチアップをすることで、Cumulative Layout Shift（ページのレイアウトのずれ）を減らすことができます。

命令的な slot 割り当て動作

命令的な slot 割り当てを使うと、マークアップで slot 属性を必要とせず、ノードからスロットへの割り当てをすることができます。これにより、入力条件や種類に応じた動的なスロット割り当て動作が可能になります。この機能は、もともとは Chrome 86 に導入されました。今回のリリースで API が調整され、他のブラウザとの相互運用性が向上しています。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.2 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。

Intl.DateTimeFormat に dayPeriod を追加

Intl.DateTimeFormat() メソッドに dayPeriod オプション（ECMA402 2021 の一部）が追加され、呼び出し元が時間を「7 in the morning」、「11 in the morning」、「12 noon」、「1 in the afternoon」、「6 in the evening」、「10 at night」などの形式（または中国語で「清晨 7 時」、「上午 11 時」、「中午 12 時」、「下午 1 時」、「下午 6 時」、「晚上 10 時」）を指定できるようになりました。

これによって Intl.DateTimeFormat() が拡張され、C++ や Java で ICU や ICU4J を呼び出して実行できる既存の操作と同じことを実現できるようになります。この機能がなければ、デベロッパーはサーバーで四半期をフォーマットするか、時間帯のパターンと時間の対応表をサーバーからクライアントに送信することによって、このタスクをする必要があります。

Array、String、TypedArray の相対インデックス メソッド

Array.prototype、String.prototype、TypedArray のプロトタイプに at() という新しいメソッドを追加し、負のインデックスによる相対インデックスを利用できるようにします。次に例を示します。

let arr = [1,2,3,4];
arr.at(-1); // Returns 4

ICU LocaleMatcher を使用する Intl BestFitMatcher

ICU LocaleMatcher に BestFitMatcher 抽象オペレーションが実装され、ロケールデータとの照合が向上します。

デスクトップ プラットフォームの SharedArrayBuffer がクロスオリジン分離環境のみに制限

デスクトップ プラットフォームの SharedArrayBuffer がクロスオリジン分離環境のみに制限されます。これにより、動作が最新の Android や Firefox と一致します。クロスオリジン分離されたページでは、オプトインされていないクロスオリジン リソースの読み込みとクロスオリジンのウィンドウとの通信がブロックされます。そのため、ページは安全な環境と見なされます。SharedArrayBuffer を使えるのは、クロスオリジン分離をオプトインしたページのみになります。導入されるオプションの詳細については、Android 版の Chrome 88 とデスクトップ版の Chrome 92 における SharedArrayBuffer のアップデートをご覧ください。

Media Session API: ビデオ会議のアクション

Media Session API に "togglemicrophone"、"togglecamera"、"hangup" アクションが追加されました。これにより、ビデオ会議サイトのデベロッパーが、ブラウザのインターフェースでこれらのアクションを扱えるようになります。たとえば、ユーザーがビデオ通話をピクチャー イン ピクチャー ウィンドウにした場合、ミュート / ミュート解除、カメラのオン / オフ、通話終了のボタンをブラウザに表示できます。ユーザーがこれらをクリックすると、ウェブサイトは Media Session API を通して処理できます。詳細については、最新記事の該当セクションを参照するか、デモをお試しください。

Resource Timing に Tainted Origin フラグを適用

Chrome は、フェッチしたリソースが Timing Allow Origin チェックを通過するかどうかを計算する際に、Tainted Origin フラグを考慮するようになります。Timing Allow Origin チェックは、ページで使われるリソースに関する詳細タイミング情報を受け取れるかどうかを判断するために Resource Timing で使用されます。オリジンをまたぐ複数のリダイレクトがある場合、Tainted Origin フラグがこのチェックに影響します。その場合、ヘッダーを '*' にする必要があります。つまり、具体的なオリジンであってはいけません。

リソースが（リダイレクトによって）2 つのオリジンにまたがる場合、このチェックを通過するために Timing-Allow-Origin: * を使用する必要があります。たとえば、オリジン A のページがオリジン B のリソースをフェッチし、オリジン B のリソースからオリジン C のリソースにリダイレクトされる場合、Tainted Origin フラグが設定され、最終的なリソースが詳細なタイミング情報を受け取るには、Timing-Allow-Origin: * が必要になります。

Web Bluetooth のメーカーデータ フィルタ

Web Bluetooth API で、ベンダー ID やプロダクト ID などのメーカーデータによるフィルタが可能になります。これまでも、近くにある Bluetooth デバイスで、アドバタイズされる名前やサービスに一致するものをブラウザのピッカーで選択することはできました。しかし、近くにある Bluetooth デバイスを、アドバタイズされるメーカー固有のデータで絞り込むことはできませんでした。メーカーのデータは、options.filters の新しいプロパティで指定し、Bluetooth.requestDevice() に渡します。詳細については、JavaScript で Bluetooth デバイスと通信するを参照するか、デモをお試しください。

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

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

Standardized Payment Method Identifier の支払いハンドラ

この機能は、ウェブベースの支払いハンドラが URL のない paymentrequest イベントを受け取れるようにするものですが、 "basic-card" や "tokenized-card" などの Standardized Payment Method Identifier が削除されました。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chrome チーム、Mike Taylor、Jade Kessler による Chromium Blog の記事 "Update on User-Agent String Reduction in Chrome" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

1 年ほど前に、User-Agent 文字列で公開される情報の粒度を徐々に削減する計画についてお知らせしました。この文字列は、デフォルトで HTTP リクエストのたびに送信されています。その直後、COVID-19 パンデミックの初期段階でウェブのエコシステムに移行の負荷をかけないよう、この取り組みを一時的に停止することを決めました。それ以降は、多大な時間を費やしてエコシステムから貴重なフィードバックを集め、これに代わるコンテンツのネゴシエーションと検出用の仕組みとして提唱している User-Agent Client Hints API（UA-CH）への人間工学的な改善を提案したり、ウェブの互換性の修正をしました。

現在、UA-CH はデフォルトで Chrome に搭載されています（M89 以降）。また、最初のリクエストでヒントが必要になるユースケースに対処するため、両方の Client Hints Reliability の仕組み（Critical-CH と ACCEPT_CH）のロールアウトも始めました。今後予定されている User-Agent 文字列削減の変更の厳密な日程やマイルストーンはまだお知らせできませんが、この領域の取り組みを再開する準備はできています。

とは言うものの、エコシステムやデベロッパーがユースケースをテストし、フィードバックを送り、適切な場合は UA-CH に移行する十分な時間を確保できる形で作業を進めることが重要だと感じています。そのため、2021 年中は、Chrome の安定版チャンネルで User-Agent 文字列の変更は行わない予定です。この投稿の目的は、皆さんが適切な対応計画を立てられるように、早い段階で私たちの考えやロードマップを公開することです。

変更点とその手法

User-Agent ヘッダー フィールドで公開される情報の粒度を段階的に引き下げることを計画しています。navigator.userAgent、navigator.appVersion、navigator.platform JS API についても同様です。

すべての対応が終わっても、User-Agent 文字列だけでブラウザのメジャー バージョンとプラットフォーム名は確実に取得でき、デスクトップかモバイルか（またはタブレットか）も判別できます。さらに高度なユースケースでは、User Agent Client Hints API に移行する必要があります。

注 : 現時点では、Android WebView や Chrome for iOS の User-Agent 文字列を変更する計画はありませんが、変更の有無やその時期については、あらためてお知らせします。

現在の計画の概要は、以下のとおりです。

  • M92 より、DevTools の [Issues] タブに、navigator.userAgent、navigator.appVersion、navigator.platform の取得に関するサポートの終了のお知らせを表示する予定です。
  • 今後数週間のうちに、完全に削減された User-Agent を実験的に受け取るオリジン トライアルについてお知らせする予定です。サイトでオプトインとテストをする十分な時間を確保し、私たちが目指す最終状態の実現可能性や整合性に関するフィードバックを提供していただけるように、オリジン トライアルは少なくとも 6 か月は継続する予定です。
  • オリジン トライアル パートナーやコミュニティからのフィードバックを評価し、そのフィードバックに基づき、計画のフェーズ 3 から 7（詳細は次のセクションを参照）を進めます。その間に、エコシステムが適応するための十分な時間をとります。もしくは、フィードバックに応じて、最善策について再検討します。
  • 複雑なユースケースで移行にさらに時間が必要なサイトのために、（「逆オリジン トライアル」によって）現在の User-Agent の動作を少なくとも 6 か月は延長できる機能を提供する予定です。

ロールアウト計画案

以上の変更は、7 つのフェーズに分けて、オリジン トライアルのフィードバックを待ちながら、ゆっくりと段階的にロールアウトする予定です。フェーズ 1 以降のスケジュールとマイルストーンの案については、近日中に最新情報をお知らせします。

削減の準備

フェーズ 1: M92 より、navigator.userAgent、navigator.appVersion、navigator.platform へのアクセスに関する警告を DevTools に表示します。

フェーズ 2: オリジン トライアルを開始し、サイトが最終形まで削減した UA 文字列でテストやフィードバックできる期間を、少なくとも 6 か月間継続します。

削減のロールアウト

フェーズ 3: 移行にさらに時間を要するサイトなどのために、逆オリジン トライアルを開始して、少なくとも 6 か月間継続します。

フェーズ 4: Chrome の MINOR.BUILD.PATCH バージョン番号を削減します（ "0.0.0" ）。これがロールアウトされると、デスクトップとモバイル OS で、逆オリジン トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。

フェーズ 5: 削減版のデスクトップ UA 文字列と関連する JS API（navigator.userAgent、navigator.appVersion、navigator.platform）のロールアウトを開始します。これがロールアウトされると、デスクトップ OS で、逆オリジン トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。

フェーズ 6: 削減版の Android モバイル（とタブレット）の UA 文字列と関連する JS API のロールアウトを開始します。これがロールアウトされると、Android で、逆オリジン トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。

削減の完了

フェーズ 7: 逆オリジン トライアルが終了し、すべてのページの読み込みに、削減版の UA 文字列と関連する JS API が適用されます。

詳細や、各フェーズでの User-Agent 文字列の例については、削減版の User-Agent 文字列に関する最新情報ページをご覧ください。

デベロッパーが準備すべきことは何ですか？

この計画は下位互換性を考慮しています。User-Agent 文字列の変更は慎重に行われるべきですが、ロールアウトが行われても、デベロッパーへの影響は最低限に留まると考えています（既存のパーサーは期待どおりに動作するはずです）。

サイトやサービス、ライブラリ、アプリケーションで、Chrome のマイナー バージョン、OS のバージョン番号、Android デバイスのモデルなどの User-Agent 文字列に含まれる一部の情報を使っている場合は、User Agent Client Hints API を使うように移行する必要があります。

これらの情報が必要ない場合は、変更は不要で、これまでどおり動作するはずです。

これを行う理由は何ですか？

User Agent Client Hints の説明に記載しているとおり、User-Agent 文字列には 2 つの理由で問題があります。1 つ目は、HTTP リクエストのたびに、ブラウザに関する多くの情報が何もしなくても公開されることです。この情報は、フィンガープリンティングに使われる可能性があります。2 つ目は、時間とともに長く複雑になり、エラーが起こりやすい文字列の解析が必要になることです。User Agent Client Hints API は、デベロッパーにもユーザーにも優しい形で、この 2 つの問題を解決できると考えています。

他のブラウザはどうなりますか？

ある意味、Chrome はこの点で追いつきつつあります。UA 文字列で macOS のバージョン番号を制限したのは Safari が最初で、Firefox もそれに続きました。Firefox は、Windows のバージョン番号も 10 に制限しています。

さらに詳しく


Reviewed by Eiji Kitamura - Developer Relations Team

...
この記事は Devin Chasanoff による Google Ads Developer Blog の記事 "The Query Builder Blog Series: Part 6 - Selecting and Deselecting Fields" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

このブログシリーズでは、新しく改善されたインタラクティブ Google 広告クエリビルダー ツールの構築過程についてお伝えしています。シリーズのパート 5 では、フィールドが選択可能かどうかを判断する方法について説明しました。パート 6 では、SelectionService を使って Google Ads Query Language（GAQL）文字列にフィールドを追加する方法について説明します。

GAQL 文字列の状態

どのフィールドが選択されているかを追跡するには、GAQL 文字列の状態を追跡する必要があります。これは、以下のインターフェース定義で表される selectedFields というインスタンス変数で行います。


interface SelectedFields {
  select: string[];
  where: Array<{field: string, context: string}>;
  orderBy: Array<{field: string, context?: string}>;
  limit?: string;
  params?: string;
}



select フィールドは、フィールド名の配列を保持します。where フィールドは、オブジェクトの配列を保持します。それぞれのオブジェクトには、field 名と context 文字列が含まれています。context は、フィールドに適用するフィルタ条件（つまり、演算子とオペランド）です。たとえば、WHERE 句にフィルタ条件 ad_group.id = 1234567890 を追加した場合、field は ad_group.id、context は = 1234567890 になります。同様に、orderBy フィールドも field 名と省略可能な context 文字列を含む配列を保持します。context は、ASC または DESC でソート順を示しますが、省略も可能です（デフォルトは ASC）。limit フィールドは LIMIT の整数を文字列で表現したもので、省略可能です。最後の params フィールドは PARAMETERS 句の文字列値を表します。これも省略可能です。現在のところ、この句で利用できる選択肢は 1 つだけなので、配列にする必要はありません、

フィールドの選択

ユーザーのクエリの状態を追跡するデータ構造が完成したので、任意の句のフィールドを選択するメソッドを実装できるようになります。


selectField(field: string, clause: string, context?: string): void {
    ...
}

clause が SELECT の場合、指定されたフィールドを selectedFields の select 配列に追加します。ユーザーが SELECT 句にフィールドを追加する場合、context は指定しません。


clause が WHERE である場合は、context 文字列として演算子とオペランドを含むフィルタ条件を提供する必要があるので、3 つのパラメータのすべてが必要です。ユーザーがチェックボックスをクリックして WHERE 句にフィールドを追加すると、ダイアログが開き、まずは演算子を、続いてオペランドを指定します。ユーザーが選択できる演算子のリストは、選択するフィールドの data_type に応じてあらかじめ指定されています。また、オペランドを入力するためにユーザーに表示するコンポーネントは、選択した演算子に応じて変わります。ユーザーがフィルタ条件を追加すると、演算子とオペランドを結合して 1 つの文字列にすることで context 文字列を作成します。





clause が ORDER BY である場合、context は省略可能です。ユーザーが ORDER BY 句のフィールドを選択すると、context なしで selectField を呼び出し、context がない状態で selectedFields の orderBy 配列にフィールドを追加します。また、フィールド名の下にラジオボタンを表示し、ASC か DESC でソート順を指定できるようにしています。ユーザーがいずれかの項目をクリックすると、orderBy 配列のそれぞれのフィールドのエントリを更新し、context にソート順を追加します。




clause が LIMIT か PARAMETERS である場合は、field パラメータで指定された文字列を使って selectedFields の limit エントリまたは params エントリを更新します。limit は正の整数である必要があるので、関連する UI コンポーネントで検証をします。現在利用できるパラメータは include_drafts だけで、このデフォルト値は false です。そのため、PARAMETERS の UI コンポーネントでは、'include_drafts=true' という選択肢が 1 つだけあるチェックボックスをユーザーに表示します。ユーザーがチェックボックスをクリックすると、field パラメータとして文字列 include_drafts=true を selectField に渡します。

SELECT での存在

フィールドを選択するロジックは単純ですが、パート 5 ではあえて触れなかった選択可否に関するルールが 2 つあります。WHERE 句または ORDER BY 句にフィールドを挿入する場合、そのフィールドは SELECT 句に存在しなければなりません。

ルール 1: 「コア日付セグメント」（segments.date、segments.week、segments.month、segments.quarter、segments.year）を除き、すべてのセグメントとセグメント化リソースは、SELECT 句に存在しなければ WHERE 句に挿入することはできません。

ルール 2: すべてのセグメント、セグメント化リソース、指標、属性付きリソースのフィールドは、SELECT 句に存在しなければ ORDER BY 句に挿入することはできません。言い換えるなら、最初に SELECT 句に挿入することなく ORDER BY 句に配置できるのは、FROM 句のリソースのフィールドだけです。

このような場合は、ユーザーが 1 回の手順で、指定された句だけでなく SELECT 句にもフィールドを追加できるダイアログを表示します。





フィールドの選択解除

フィールドを選択解除できるように、SelectionService に deselectField というメソッドを実装します。


deselectField(field: string, clause: string): void {
    …
}




フィールドの選択解除は、フィールドの選択と同様です。念のため、最初にそのフィールドが選択されているかどうかをチェックします。続いて、clause が SELECT、WHERE、ORDER BY のいずれかである場合は、selectedFields の対応する配列のエントリから選択解除されたフィールドを削除します。前述のルールにより、WHERE や ORDER BY に追加される前に SELECT に存在していなければならないフィールドが SELECT から削除されると、そのフィールドが SELECT から 1 回の操作で自動的に削除されます。句が LIMIT や PARAMETERS である場合は、selectedFields のそれぞれのエントリを undefined に更新します。

出力の更新

selectedFields 変数、selectField メソッド、deselectField メソッドがそろったので、クエリ文字列の状態を追跡できます。アプリケーション全体で変化を追跡できるように、SelectionService で Observable を作成し、selectField か deselectField が呼び出されるたびに next を呼び出します。これにより、GAQL クエリの状態を認識したいコンポーネントで Observable をサブスクライブできるようになります。

まとめ

SelectionService を更新し、フィールドの選択と選択解除ができるようになりました。今回の投稿では、以下について説明しました。
  • GAQL クエリと句の構造
  • フィールドの選択可否に関する追加の詳細情報
  • Angular での Observable の利用
Google Ads API での GAOL クエリの構築について理解が深まれば幸いです。ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。


- Devin Chasanoff（Google Ads API チーム）

この記事はデベロッパー リレーションズ、プログラム マネージャー、Sebastian Trzcinski-Clément による Google Developers Blog の記事 "A new open source content library from Google" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

世界中のデベロッパーが絶え間なくオープンソースのツールやチュートリアルを作成していますが、それを見つけてもらうのは至難の業です。多くの場合、公開されたコンテンツは、GitHub から Medium まで、さまざまなサイトに広がっています。そこで、Google のテクノロジーに関連する優れたプロジェクトを 1 か所にまとめた場所を作ることにしました。それが Developer Library です。

Developer Library をスクロールする様子を示した GIF

このプラットフォームでは、ブログ投稿や、簡単な操作で使えるオープンソース ツールを紹介しています。コンテンツは、プロダクトの種類によって、Machine Learning、Flutter、Firebase、Angular、Cloud、Android に分類されています。分類は今後さらに追加される予定です。

Developer Library ならではの特徴は、取り上げられているすべてのサイトが正確さと妥当性の観点で Google のエキスパート チームによって細かく検証されている点です。つまり、このサイトにコンテンツが掲載されているということは、Google が承認したということです。

このサイトのコンテンツの幅広さをお見せするため、公開されているコンテンツや作成したデベロッパーの動画インタビューの一部を以下に紹介します。

Developer Library の更なる成長のために、皆さんにご協力いただける方法が 2 つあります。

1 つ目として、Developer Library で公開したい優れたコンテンツをお持ちの方は、こちらからレビューの申請をしてください。

2 つ目として、フィードバックも歓迎しています。Developer Library サイトに追加や変更の希望がある方は、こちらの簡単なフィードバック フォームに入力するか、GitHub で Issue を送信してください。

皆さんの作品を楽しみにしています。


Reviewed by Eiji Kitamura - Developer Relations Team

Google は 多くの女性のエンジニアが勉強会やイベントでスピーカーとして活躍できるためのプログラム「Women Developer Academy」 を 7 月 17 日（土）より開催します。 Women Developer Academy は、技術勉強会やイベントで活躍する女性スピーカーを育成するためのプログラムで、オンライン ワークショップを通じて、登壇・講演を向上させるスキルやリソースを提供します。 本プログラムでは、ワークショップを通じて、プレゼンテーションスキルを向上させ、自信とネットワークを構築しようとしている IT 専門家（ソフトウェア エンジニア、データ サイエンティスト、開発者など）に向けてこの 3 週間プログラムはデザインされています。またいくつかのトピックに焦点を当てた週次ワークショップ（詳細は以下）が開催されます。新しいスキルを習得するだけでなく、似たような悩みを抱える他の女性デベロッパーに出会い、つながり、コミュニティ ネットワークを通じて、登壇機会を見つけることができます。（多くの女性が登壇枠に出ていない理由は、技術的なスキルが不足しているからではありません！） Google は Women Developer Academy を通じて、技術勉強会やイベントの登壇者の多様性を支援していきたいと考えています。 みなさまからの応募をお待ちしております ...

Google は 多くの女性のエンジニアが勉強会やイベントでスピーカーとして活躍できるためのプログラム「Women Developer Academy」 を 7 月 17 日（土）より開催します。

Women Developer Academy は、技術勉強会やイベントで活躍する女性スピーカーを育成するためのプログラムで、オンライン ワークショップを通じて、登壇・講演を向上させるスキルやリソースを提供します。

本プログラムでは、ワークショップを通じて、プレゼンテーションスキルを向上させ、自信とネットワークを構築しようとしている IT 専門家（ソフトウェア エンジニア、データ サイエンティスト、開発者など）に向けてこの 3 週間プログラムはデザインされています。またいくつかのトピックに焦点を当てた週次ワークショップ（詳細は以下）が開催されます。新しいスキルを習得するだけでなく、似たような悩みを抱える他の女性デベロッパーに出会い、つながり、コミュニティ ネットワークを通じて、登壇機会を見つけることができます。（多くの女性が登壇枠に出ていない理由は、技術的なスキルが不足しているからではありません！）

Google は Women Developer Academy を通じて、技術勉強会やイベントの登壇者の多様性を支援していきたいと考えています。

みなさまからの応募をお待ちしております。


プログラム内容

Week 1 - July 17 （1 週目のセッションは韓国地域の参加者と一緒に英語で行われます）
  • Session 1 : WDA プログラムの紹介、WTM＆GDE プログラムの概要
  • Session 2 : Workshop: 適切なテーマの選び方
  • Session 3 : 登壇する自信がない ... 自信をつけるには
Week 2 - July 24（日本語セッション）
  • Session 1 : 優れた技術プレゼンテーションの構築法
  • Session 2 : Machine Learning Workshop
Week 3 - July 31（日本語セッション）
  • Session 1 : Google Developer Expert (GDE) について
  • Session 2 : 女性 GDE 活躍事例

※ 参加者数が限られているため、なるべくすべてのセッションに参加できる方のみご登録をお願いいたします。



タイムライン

  • 6 月 21 日 : 応募登録開始
  • 7 月 3 日 : 登録締切
  • 7 月 5 日 : 参加確認メールを送信
  • 7 月 17 日 ～ 31 日 : Women Developer Academy 開催

参加対象

  • 次の技術のいずれかの知識、情熱と経験がある方 : Android, Google Cloud, Tensorflow, Machine Learning, Flutter, Firebase, Kotlin, Go, Web Technologies, Google Workspace
  • 公の場で演説した経験がほとんどない方
  • イベントやセミナーで登壇したい方
  • デベロッパー コミュニティで積極的に発言し、開発者会議やミートアップにスピーカーとして参加したいという意志がある方
  • 7 月に行われるすべてのセッションに（オンライン）参加し、プログラムの要件に専念することができる方
  • 日本に在住している女性の開発者
  • 登録してくださったすべての方がプログラムに参加できるわけではありません。上記要件を満たしている方に、プログラム詳細をメールにて個別ご連絡いたします。

以下のプログラム要件にご留意ください

  • コンテンツへのアクセスのために使用できる個人 Gmail や Gsuite アカウント
  • デスクトップ コンピュータまたはラップトップ
  • ウェブカメラとマイク（内蔵または外付け）