この記事は Google Play プロダクト マーケティング マネージャー、Lloyd Hightowerによる Google for Developers の記事 " Announcing the Winners of the Gemini API Developer Competition!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
5 月の I/O で、Google は世界中の開発者のみなさんに Gemini API を活用した革新的なアプリの開発を呼びかけました。世界中の何千もの開発者の皆さんがこの呼びかけに応え、既存のアプリに AI を搭載した機能を追加し、可能性の限界を広げる AI のアプリを開発しました。
そして、みなさんが待ち望んでいた瞬間が訪れました：
Gemini API デベロッパー コンテストの受賞者を紹介します！日本からは 2 名の方が選出されました。
総合的なベスト アプリ : Jayu
AI 搭載のパーソナルアシスタント「Jayu」は、Gemini API とクリエイティブな開発の融合による可能性を実証しています。この革新的なアプリは、ウェブブラウザ、コードエディタ、音楽ストリーミング、ゲームなど、さまざまなアプリと統合されています。Jayu は、視覚情報を解釈することによって、アプリのインターフェースと直接対話してリアルタイムで翻訳する能力を持ち、Gemini API の力とその能力を最大限に引き出すクリエイターの卓越したスキルを同時に示します。Google にとって、Jayu は単なる受賞アプリではなく、AI が生活に統合され、働く未来の一端を垣間見ることができます。
Vite Vere は、認知障害を持つ人びとが日常的なタスクをこなすためのパーソナライズされたガイダンスを提供することで、より自立することを支援します。このアプリが Gemini の視覚的理解と巧みなプロンプトを使用して、ユーザーがタスクを完了できるよう段階的な指示を提供することで、自立とスキル開発を促進している点に感銘を受けました。
最もクリエイティブなアプリ : Outdraw AI (日本)
Outdraw は、創造性と AI のユニークな融合により、AI ならではのゲーム体験を可能にしました。このゲームは、ユーザーは人間には認識できて、AI の視覚理解では認識できない画像を描くという挑戦をユーザーに与えるゲームです。このアプリは、AI をコラボレーションパートナーから挑戦的な対戦相手に変えることで、クリエイティブな取り組みにおける AI の役割を再定義します。これは、AI の最も創造的な使用例の 1 つでした。
Prospera は、革新的な Flutter アプリで、Gemini API を活用してリアルタイムの AI セールスコーチを構築しています。セールス会話の分析と即時のフィードバックやパフォーマンス レポートを提供することで、Prospera は 営業担当者がスキルを向上させることを可能にします。このアプリは、実用的なビジネス課題に対処し、プロとしての成長を促進する Gemini モデルの汎用性を示しています。Prospera の詳細と、アプリの選出理由については、Flutter ブログ (英語) をご覧ください。
Gaze Link は、重度の運動障害と言語障害を発症した筋萎縮性側索硬化症（ALS）の患者の力を引き出す可能性を秘めており、私たちに感銘を与えました。この Android アプリは、眼球追跡技術とGemini API を使用して、介護者の質問を理解し、患者から生成された単一単語に基づいて完全な文章の応答を正確に予測および生成します。Gaze Link の詳細については、Android Developer ブログ (英語) をご覧ください。
Trippy は、Firebase と Gemini API を巧みに活用して、パーソナライズされた旅行計画体験を作り出すことで注目を集めました。このアプリは、Gemini の自然言語理解とレコメンド機能を活用して、ユーザーの好みをもとに目的地、アクティビティ、旅程を提案します。Trippy は、AI がどのように旅行計画を強化し、世界を探検するのをよりアクセスしやすく楽しいものにするかを示しています。Trippy の詳細については、Firebase ブログ (英語) をご覧ください。
ViddyScribe は、視覚障害者の方々がよりアクセスしやすくなるよう、動画に自動的に音声説明を追加するウェブ アプリです。このアプリは、Gemini モデルを使用して文脈的に正確な説明を生成し、視聴体験を妨げることなく動画にシームレスに統合します。ViddyScribe の詳細については、Chrome Developers ブログをご覧ください。
Pen Apple は、Gemini Flash モデル を巧みに活用して、ゲームプレイのインタラクションを迅速に解釈して実行するオンライン デッキ構築ゲームです。このゲームは、Gemini の自然言語処理能力を使用して、カードの効果を直接カード名から解釈します。これにより、最小限の開発努力で複雑で創造的なカードが可能になります。私たちは特に、Gemini API がゲームの背景設定、敵、ステージ、さらにはゲームの仕組みに統合される新しいカードの作成にも使用されている点にも感銘を受けました。
Everies は、Gemini API と ARCore を活用して、身の周りの物に命を吹き込みます。Gemini の視覚理解と高度なプロンプトを使用して、Everies は物ごとにユニークなスクリプトを作成し、ARCore を使用して顔の特徴を重ね合わせることで、革新的で楽しい方法で物に命を吹き込みます。
Gemini API で未来を構築する
これらのアプリは、さまざまな分野で画期的な問題を解決するための Gemini API の計り知れないな可能性を示しています。Google は、開発者の皆さんが Gemini の能力を活用して、今後さらにインパクトのある革新的なアプリを開発することを期待しています。Gemini を活用した開発を始めるには、Google AI Studio をご覧ください。
Reviewed by Tamao Imura - Developer Marketing Manager, Google Play
Google Cloud は、10 月 24 日 (木) にインフラエンジニアのためのイベント、「 Generative AI Summit Tokyo '24 Fall」を 開催します。
生成 AI はいよいよ「社会実装」へ移行しつつあります。
企業はますます生成 AI 技術を活用し、顧客体験の向上やプロセスの自動化、新しい製品やサービスの開発など、さまざまな分野での活動に取り組んでいます。生成 AI の技術革新は、競争力の向上やイノベーションの促進に貢献し、ビジネスの成長に寄与しています。
本イベントでは、「Gemini」、そして「Vertex AI」について、お客様の事例を中心に具体的な活用方法をご紹介します。これらのサービスは、ビジネスの成長やイノベーションを加速させるための非常に強力なツールです。実際の導入事例や成功事例を通じて、参加者の皆様に生成AIをどのように活用するか、その可能性を理解いただければと思います。
今回は現地会場参加者に抽選でオリジナル T シャツをプレゼントいたします。（※ T シャツのプレゼントには諸条件がございます。詳細は Webサ イトをご覧ください）
ぜひ、 Generative AI Summit Tokyo '24 Fall にご参加ください。
日時 : 10 月 24 日（木）11:00 - 18:30
開催方法 : ハイブリッド（ベルサール渋谷ファースト / オンライン配信）
会場 : ベルサール渋谷ファースト
詳細・お申し込みはこちら
※ プログラムは変更になる可能性がございます。最新の情報は上記 Web ページにてご確認ください。
Google Cloud イベント事務局
Email : googlecloud-genai-japan@google.com
#gc_genai
新たなウェブ標準である Reporting API は、本番ウェブサイトにアクセスするブラウザで発生する問題をレポートする汎用的な仕組みを提供します。受け取るレポートでは、世界中のユーザーのブラウザで発生するセキュリティ違反やまもなく非推奨になる API などの問題が詳しく説明されています。
多くの場合は、HTTP ヘッダーでエンドポイント URL を指定するだけでレポートを収集できます。するとブラウザは、皆さんにとって関心のある問題が含まれたレポートをエンドポイントに自動転送し始めます。ただし、レポートの処理や分析はそれほど簡単ではありません。たとえば、エンドポイントには大量のレポートが送られてくる可能性がありますが、そのすべてが根本的な問題の特定に役立つわけではない場合があります。そのような状況では、問題を抽出して修正するのは非常に困難かもしれません。
このブログ投稿では、Google セキュリティ チームがどのように Reporting API を使って潜在的な問題を検出し、実際の問題を特定しているかを紹介します。また、Google と同じようなアプローチで簡単にレポートの処理や対策ができるように、オープンソースのソリューションも紹介します。
本番環境のユーザーのブラウザでしか発生しないエラーもあります。もちろん、皆さんはユーザーのブラウザにアクセスすることはできません。こういったエラーは、ローカルで、あるいは開発中に見かけることはありません。実際のユーザーやネットワーク、デバイスがどのような状態になっているかわからないからです。Reporting API を使えば、ブラウザを直接利用してこういったエラーをモニタリングできます。つまり、ブラウザがエラーをキャッチし、エラーレポートを生成して、指定したエンドポイントに送信してくれます。
レポートの生成と送信の仕組み。
Reporting API でモニタリングできるエラーには、次のようなものがあります。
# CSP 違反レポート、Document-Policy 違反レポート、非推奨レポートを受け取る設定の例 Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default" # CSP 違反と Document-Policy 違反を `main-endpoint` に送信するContent-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint; Document-Policy: document-write=?0; report-to=main-endpoint; # 非推奨レポートは自動生成され、明示的なエンドポイントは必要ない。常に `default` エンドポイントに送信される
DevTools の [Application] パネルに表示されるレポートの例。
レポートのエンドポイントのデモでは、生成されたさまざまな違反がサーバーでどのように受信されるかを確認できます。
違反レポートの例
2024 年 3 月時点で、Chrome は Reporting API をサポートしており、Safari は一部をサポートしています。詳細については、ブラウザ サポートの表をご覧ください。
Google は、セキュリティを大規模に向上できるという恩恵を受けています。Content Security Policy、Trusted Types、Fetch Metadata、Cross-Origin Opener Policy といったウェブ プラットフォームによる対策は、さまざまな Google プロダクトや無数の個々のサービスからあらゆる脆弱性を排除するために役立ちます。この点は、こちらのブログ投稿で詳しく説明しています。
Reporting API では、1 つのレポート エンドポイントと、複数のセキュリティ機能を表現する 1 つのスキーマを使ってこのサイクルを実行できます。そのため、ブラウザ、コードパス、ユーザータイプを問わずに、さまざまな機能のレポートを一元的に収集できます。
注 : ポリシーで禁止されているアクションを行おうとすると、違反レポートが生成されます。たとえば、あるページに CSP を設定しているにもかかわらず、CSP で許可されていないスクリプトを読み込もうとする場合です。Reporting API で生成されるレポートのほとんどは違反レポートですが、それがすべてではありません。その他のタイプには、非推奨レポートやクラッシュ レポートなどがあります。詳細については、ユースケースとレポートタイプをご覧ください。
残念ながら、違反レポートのストリームにはノイズが紛れ込むことがよくあります。その場合、準拠していないコードを見つけることが難しくなる可能性があります。たとえば、多くのブラウザ拡張機能、マルウェア、ウィルス対策ソフトウェア、開発ツールのユーザーは、DOM にサードパーティのコードを挿入したり、禁止された API を使ったりしています。挿入されるコードがポリシーに準拠していない場合、コードベースにリンクされていない対策不可能な違反レポートになる可能性があります。そのため、レポートのトリアージが困難になり、すべてのコードを確実に準拠させてから新しいポリシーを適用するのが難しくなります。
Google は長年にわたり、違反レポートを収集して活用し、それをまとめて 根本原因に集約するための多くの技術を開発してきました ここでは、デベロッパーが違反レポートのノイズを除外できる技術の中から、特に役立つ技術の概要を紹介します。
ブラウザのタブが使われている間に、ポリシーに準拠していないコードが何度も実行されることはよくあります。それが発生するたびに、新しい違反レポートが作成され、キューイングされて、レポートのエンドポイントに送信されます。これが起きると、冗長な情報を含む大量のレポートができてしまいます。そこで、違反レポートをクラスタにグループ化することで、個々の違反を意識することなく、根本原因について考えることができます。根本原因の方が理解しやすいので、有効なリファクタリング方法を探す時間を短縮できます。
例を通して、違反がどのようにグループ化されるのかを確認してみましょう。たとえば、インライン JavaScript イベント ハンドラの使用を禁止する report-only の CSP が導入されているとします。違反レポートは、該当するハンドラのすべてのインスタンスについて作成され、次のフィールドが設定されます。
blockedURL
inline
scriptSample
documentURL
ほとんどの場合、この 3 つのフィールドで、特定の URL のインライン ハンドラを一意に識別できます。他のフィールドの値が異なる場合でも同様です。こういったことがよく起こるのは、トークンやタイムスタンプなどのランダムな値をページをまたいで使う場合です。前述のようなフィールドの値は、アプリケーションやフレームワークによって微妙に異なる場合があるため、レポート値をあいまい一致させることができれば、手間を省きつつ、違反をクラスタにグループ化して対策につなげることができます。必要に応じて、URL フィールドに既知のプレフィックスがある違反をグループ化することができます。たとえば、URL が chrome-extension、moz-extension、safari-extension で始まるすべての違反をグループ化すると、根本原因がコードベース以外のブラウザ拡張機能である違反を、高い信頼性で特定できます。
chrome-extension
moz-extension
safari-extension
対策不可能な違反レポートと対策可能な違反レポートを区別するもう 1 つの方法が、環境情報です。このデータは、レポートのエンドポイントへのリクエストには含まれますが、違反レポート自体には含まれません。環境情報からクライアント設定におけるノイズ源を判別できる可能性があるので、トリアージに役立つかもしれません。
違反のタイプによっては、source_file フィールドまたはそれと同等のフィールドが含まれます。このフィールドは、違反の原因となった JavaScript ファイルを表し、通常は行番号と列番号が付いています。これらの 3 ビットデータは高品質の信号であり、リファクタリングが必要なコードの行を直接指すことができます。
source_file
ただし、コンパイルや最小化のために、ブラウザがフェッチしたソースファイルがコードベースに直接マッピングできなくなることもよくあります。その場合は、JavaScript ソースマップを使って、デプロイされたファイルとオーサリングされたファイルの間で行番号と列番号をマッピングするとよいでしょう。すると、違反レポートがソースコードの行に直接変換されるので、非常に対策しやすいレポート グループと根本原因が生成されます。
Reporting API は、セキュリティ違反、非推奨の API 呼び出し、ブラウザの介入などのブラウザ側イベントを、イベントごとに指定されたエンドポイントに送信します。ただし、前のセクションで説明したように、そのレポートから実際の問題を抽出するには、データ処理システムが必要です。
ブラウザからレポートを受け取る方法と、受け取ったレポートを処理する方法を理解できるように、小さなサンプル アプリケーションを作成しました。このアプリケーションで、ブラウザが送信したレポートからウェブ アプリケーションのセキュリティ問題を抽出するために必要なプロセスを示します。具体的には、以下のプロセスになります。
緑色のボックスは、独自に実装する必要があるコンポーネントです。 フォワーダ（forwarder） はシンプルなウェブサーバーであり、JSON 形式のレポートを受け取り、それを Bigtable 用のスキーマに変換します。 ビームコレクタ（beam-collector） はシンプルな Apache Beam パイプラインであり、ノイズの多いレポートをフィルタリングし、関連するレポートを集約して、CSV ファイルとして保存します。この 2 つのコンポーネントは、Reporting API からのレポートを有効利用するうえで重要な役割を果たしています。
ここで共有したオープンソース ソリューション以外にも、Reporting API を簡単に使えるようにするツールがいくつも用意されています。次のようなものがあります。
この記事では、ウェブ デベロッパーが Reporting API を使ってクライアント側の問題を収集する方法と、収集したレポートから実際の問題を抽出する際の課題について説明しました。また、その課題を解決するために Google がどのようにレポートをフィルタリングして処理しているかを説明し、同様のソリューションを実現する際に利用できるオープンソース プロジェクトを紹介しました。この情報が役立ち、Reporting API を活用するデベロッパーが増え、結果としてウェブサイトの安全性と持続可能性が向上することを願っています。
この記事は Google マップ、Google Maps Platform プロダクト マネージャー Alicia Sullivan による Google Cloud Blog の記事 " New Cloud-based maps styling features provide more options, control, and flexibility to enhance your user experience" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
今年の Google I/O にて、Google は Maps JavaScript API 向けクラウドベースのマップスタイル設定の一般提供を発表しました。この度 Google は、クラウドベースのマップスタイル設定の新機能を発表いたします。この新機能は選択肢の幅を広げ、制御性を高め、ユーザーに優れたエクスペリエンスを提供します。その新機能とは、ランドマークとビルディング フットプリント（建物の外形情報）の 2 つです。ウェブ版とアプリ版の一般向け Google マップをご利用の方はこれらの機能をすでにご存知かもしれません。また、業界別に最適化された地図スタイルの新バージョンもリリースします。新しいバージョンではより細やかな設定が設定できるようになると同時に柔軟性が向上し、優れたエクスペリエンスを実現します。それでは詳細を見てみましょう。
ウェブ版とアプリ版の一般向け Google マップをご利用の方は、主要なスポットが強調表示されていることにお気づきかもしれません。このランドマークは、ユーザーが自身の現在地を確認し、探索中または訪問中の都市でどのように移動すればよいかを決定するための目印として役立ちます。
このたび、クラウドベースのマップスタイル設定を使用して地図を作成することで、一般向け Google マップと同じエクスペリエンスをユーザーに提供できるようになりました。この機能は、ニューヨーク、ドバイ、パリ、ムンバイ、シンガポールなど、世界中の 100 の都市で利用可能です。地図にランドマークを表示するには、Cloud Console にログインし、スタイル エディタで [Points of interest] の機能タイプに移動して、[Marker Style] で [Illustrated] を選択します。
ビルディングフットプリント面の塗りつぶしと線幅も、それぞれ多様なカラーテーマで設定できます。ビルディング フットプリントを有効にするには、スタイル エディタで [Buildings] に移動し、[Building Style] で [Footprints] を選択します。
Google は今年の 1 月、旅行、不動産、小売、ロジスティクス業界向けに最適化された地図のスタイルの提供を開始しました。これによりお客様は、クラウドベースのマップスタイル設定を通じて、事前設定されたスタイル付き地図が利用できるようになりました。ランドマークは業界別に最適化されたすべてのスタイル付き地図で使用でき、ビルディング フットプリントは旅行業界向けのスタイル付き地図のみで使用できます。業界別に最適化されたスタイル付き地図をすでに利用している場合、それらの新機能は地図に自動で適用されるため、追加操作は不要です。この変更を無効にしたい場合は、スタイル エディタで機能をオフにします。
また、業界別に最適化された地図のスタイルに限定されますが、詳細なストリート マップが利用可能になります。この機能は、2020 年 8 月に Google I/O で発表したウェブ版とアプリ版の一般向け Google マップの新しい機能ですでにご覧になっているかもしれません。詳細なストリート マップは、現在サンフランシスコ、ニューヨーク、ロンドン、東京で使用できますが、2021 年の終わりまでに新たに 50 都市をサポートをする予定です。
詳細なストリート マップは、業界別に最適化された地図の全スタイルでデフォルトで有効になります。この表示設定は、新たに作成された設定メニューから必要に応じて変更できます。将来的に、すべてのクラウドベースのマップスタイル設定に、詳細なストリート マップ機能を完全導入できるようこの取り組みを続けています。
ランドマークとビルディング フットプリントおよび業界別に最適化された地図のスタイルの新バージョンは、Google Cloud Console 内のクラウドベースのマップスタイル設定からご利用いただけます。利用料金は Google Maps Platform の料金に含まれています。ランドマーク、ビルディング フットプリント、業界別に最適化された地図スタイルの使用方法については、開発者ドキュメントをご参照ください。また、クラウドベースのマップスタイル設定を開始するには、JavaScript のドキュメントをご覧ください。
Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。
Google Cloud Japan は 2 月 3 日 （水）、2 月 10 日 （水）、3 月 17 日 （水）の 3 週にわたって Google Cloud App Modernization OnAir を開催いたします。
Google Cloud App Modernization OnAir では、Google Cloud のエンジニアが、モダンなアプリケーション開発で利用可能な Google Cloud のサービスや、コンテナ、Kubernetes を利用した開発手法、マイクロサービス アーキテクチャの採用、CI/CD パイプラインの構築、DevOps の実践方法、SRE の考え方、アプリケーション セキュリティ、デザインパターンなどをご紹介いたします。 既に Google Cloud についてご存知のお客様、これから利用を検討しているお客様、ぜひご視聴ください。
この Google Cloud App Modernization OnAir は、一度ご登録いただくと、3 週間分のセッションを追加登録なしでご視聴いただけます。配信当日はライブでの Q&A も行いますので、ぜひご参加ください。
また、今回 App Modernization OnAir 放送開始キャンペーンを実施しております。
参加ご登録者の中から抽選で 10 名様に Kubernetes パーカーをプレゼントいたします。
（全配信終了後に送付いたします）
事前お申込み受付中：http://goo.gle/devrelblog
名 称 『App Modernization OnAir』
日 程 毎週 水曜日（3 連続開催） 2021 年 2 月 3 日（水）、2 月 10 日 （水）、2 月 17 日 （水）
対 象 開発エンジニア、インフラエンジニア、運用エンジニア
参加費 無料（事前登録制）
登 録 http://goo.gle/devrelblog
Location Intelligence 位置情報を活用したデータ分析プラットフォーム こちらのデモでは食品の配達ゲームを通して、Google Maps Platform の機能をご体感いただくことができます。ゲーム画面上に表示される複数の配達先に、どのようなルートを選択すれば効率よく配達できるかを競い合います。
Explore Cloud TPU Google が開発した AI プロセッサのアーキテクチャ Google が開発した AI プロセッサ「Cloud TPU」のメカニズムを学べるデモです。CPU、GPU、そして TPU のアーキテクチャの違いや、TPU が GPU より優れた費用対効果を実現できる理由を理解できます。また、TPU で構成された AI スーパーコンピュータ「Cloud TPU Pod」のテクノロジーや応用分野を解説しています。 PA!GO powered by Edge TPU PA!GO は、パナソニックが Google の機械学習技術を活用して開発する、子どものための新しい知育デバイスのコンセプトモデルです。PA!GO を家の外に持ち出して、草や花、動物や虫など、外の世界で出会ったさまざまなモノを内蔵カメラで撮ると、AI がそれらが何かを音声で教えてくれます。PA!GO の実装には、Google の機械学習ライブラリ TensorFlow と AI プロセッサ Edge TPU によるオンデバイスでの画像認識や、Google ナレッジグラフによるモノの情報探索が利用されています。（協力会社：パナソニック株式会社)
Reimagine Workstyle with AI G Suite と Chromebook、Hangouts Meet ハードウェア と Jamboard が、時も場所も選ばず、セキュアで効率的なクラウドコラボレーションを実現。AI 技術がもたらすスマートワークをぜひ体験してください。ミニセッションも開催します。
Cloud Armor Fortified Castle Cloud Armor をご利用いただくことで、外部からの有害な攻撃を防ぐことができます。Web サイトを城に見立て、そこに攻撃を仕掛けてくる忍者や侍を、Cloud Armor を使って簡単に守れる様子をゲーム感覚で体験できるブースです。
Hybrid & Multi-Cloud City Anthos や Kubernates について詳しくない方でも、スクリーン上に構築された仮想都市を通じて、ハイブリッドなコンテナ環境、構成管理、Service Mesh の構築など、Anthos の概念を体験しながら理解できます。
Life of Your Code with Cloud Run コンテナ化したアプリケーションを、Cloud Build でビルドし Cloud Run にデプロイする一連の CI/CD ワークフローをインタラクティブに体験できます。 DevOps with Google Cloud デジタル時代を生き抜くためのビジネスを創出する際、DevOps を行うことによるメリットは大いにあります。本ブースでは DevOps による効果と GCP を使った実装方法をデモを通じてお伝えします。
イベント名： Google Cloud Next ’19 in Tokyo ウェブサイト：https://cloud.withgoogle.com/next/tokyo 日程： 2019 年 7 月 30 日（火）・7 月 31 日（水）・ 8 月 1 日（木） 時間： 7 月 30 日（火） Bootcamp（有料） 9:00 / 13:00 〜 18:00（予定） DevDay 10:00 〜 18:00（予定） 7 月 31 日（水） 開場 8:30 （予定） 基調講演 9:30 〜 11:30 （予定） セッション 12:00 ~ 21:00（予定） 8 月 1 日（木） 開場 8:30 （予定） 基調講演 9:30 〜 11:30 （予定） セッション 12:00 〜 18:00（予定） Next '19 in Tokyo Night 18:30 〜 20:30（予定） 会場： ザ・プリンス パークタワー東京 および東京プリンスホテル
Bootcamp（有料） 9:00 / 13:00 〜 18:00（予定） DevDay 10:00 〜 18:00（予定）
開場 8:30 （予定） 基調講演 9:30 〜 11:30 （予定） セッション 12:00 ~ 21:00（予定）
開場 8:30 （予定） 基調講演 9:30 〜 11:30 （予定） セッション 12:00 〜 18:00（予定） Next '19 in Tokyo Night 18:30 〜 20:30（予定）
イベント名： Google Cloud Next ’19 in Tokyo ウェブサイト：https://cloud.withgoogle.com/next/tokyo 日程： 2019 年 7 月 31 日（水）・ 8 月 1 日（木） 開場： 8:30 （予定） 基調講演： 9:30 〜 11:30 （予定） セッション： 12:00 〜 18:00（予定） 会場： ザ・プリンス パークタワー東京 および東京プリンスホテル
対象：G Suite や Google Cloud Platform (GCP) の活用にまつわる専門的知見やナレッジをセッションの場で共有してくださる方 応募期間： 2019 年 3 月 15 日（金）まで 応募先はこちら
※ 画面が、英語表記になった場合は、右上の言語設定ボタン*で Japanese を選択すると、日本語表記に変更できます。*
implementation 'com.google.android.things:cloud-iot-core:1.0.0'
var configuration = IotCoreConfiguration.Builder(). .setProjectId("my-gcp-project") .setRegistry("my-device-registry", "us-central1") .setDeviceId("my-device-id") .setKeyPair(keyPairObject) .build() var iotCoreClient = IotCoreClient.Builder() .setIotCoreConfiguration(configuration) .setOnConfigurationListener(onConfigurationListener) .setConnectionCallback(connectionCallback) .build() iotCoreClient.connect()
private fun publishTelemetry(temperature: Float, humidity: Float) { // payload is an arbitrary, application-specific array of bytes val examplePayload = """{ |"temperature" : $temperature, |"humidity": $humidity |}""".trimMargin().toByteArray() val event = TelemetryEvent(examplePayload, topicSubpath, TelemetryEvent.QOS_AT_LEAST_ONCE) iotCoreClient.publishTelemetry(event) } private fun publishDeviceState(telemetryFrequency: Int, enabledSensors: Array<String>) { // payload is an arbitrary, application-specific array of bytes val examplePayload = """{ |"telemetryFrequency": $telemetryFrequency, |"enabledSensors": ${enabledSensors.contentToString()} |}""".trimMargin().toByteArray() iotCoreClient.publishDeviceState(examplePayload) }
