GDG DevFest Tokyo 2019に参加したら、Webの未来にワクワクした

GDG DevFest Tokyo 2019 というイベントに参加してきました。 最近はプライベートの都合上、中々時間が取れていませんでした。 しかし今回、会社の都合上、良い感じに時間を確保できたため、こちらのイベントに参加してきました。 大阪→東京 でわざわざ新幹線を使ってまで参加しましたが、それに見合う発見が多くありました。 今回、私が学んだ内容について、報告しようかなと思います。

https://gdg-tokyo.connpass.com/event/137666/

GDG DevFest Tokyo 2019

DevFest は、Google Developer Group (GDG) コミュニティによって世界各地で開かれるデベロッパー向けイベントです。東京では、Android、Google Cloud Platform（GCP）、Web、Firebase、Machine Learning （ML）、Assistant、Flutter、Go といった様々な技術の最新情報や現場でのノウハウを一日で学べるコミュニティイベントとして開催しています。去年に引き続き 4 回目の開催となります。

https://tokyo.gdgjapan.org/devfest2019

私は、DevFest Day1 のみの参加でした。 開催場所は、電気通信大学です。スタッフさんの多くは学生さんだったと思います。積極的にサポートされていた姿は、立派だなと勉強になりました。

DevFests

DevFests are community-led developer events hosted by Google Developer Groups around the globe. GDGs are focused on community building and learning about Google’s technologies.

https://devfest.withgoogle.com/

DevFests 自体は、グローバルで活動されている GDG がホストのイベントです。 下の図は、2019 年の活動実績&予定です。全国各地で広く活発的に行われていることが分かると思います。

また、コミュニティの Youtube のチャンネルもあります。

https://www.youtube.com/channel/UCXDc-ckqru8BgppXbCt0APw

動画には、文字起こしとして 英語(自動生成)だけでなく、 英語(CC) もあります。 英語のリスニングが苦手な人でも、文字から理解できるようになっています。こういう配慮はさすがですね。

Google Developer Experts (GDE)

今回登壇されている方の多くが、 Google Developer Experts (GDE) という言葉を仰っていました。 最初は『Google 社内の何かしらのポジションか？』と思っていましたが、違っていました。

A global program to recognize individuals who are experts and thought leaders in one or more Google technologies. These professionals actively contribute and support the developer and startup ecosystems around the world, helping them build and launch highly innovative apps.

https://developers.google.com/community/experts

GDE の人は、端的に言うと『Google のテクノロジを開発者やスタートアップ企業らに対して支援・啓蒙活動をしている Google 外の人』です。 GDE になるためには、Google、Google パートナーからの紹介から入る必要があるそうです。

Sessions

今回のセッションでは、次のようなカテゴリでグループ分けされていました。

• Android
• Assistant
• Cloud
• Design
• Firebase
• Flutter
• Go
• ML
• Web
• misc (other かな)

私は、Web が好きな人なので、そのカテゴリを積極的に選んでいきました。

Keynote2: 円周率世界記録への道

Speaker: 岩尾 エマ はるかさん

こちらの記事が、今回の話のテーマとなります。

https://it.srad.jp/story/19/03/17/043207/

岩尾 エマ はるかさんのお話は、おおよそWikiに記載があるとおりです。

今回の発表の話にあった、以下の話が印象的でした。

• Linkedin 経由で Google からのオファーがあり、『５回面接をして、ようやく合格した』

岩尾さんは、『面接するのは無料』という精神で、何度も Try し続けて合格を勝ち取った人です。同じ大阪出身だそうで、納得しました。（笑）

また、元々英語は得意な方ではなかったという話も紹介されていました。 私も英語について悩んでおり、とても共感する部分が多かったです。 英語ができることによって、選択肢は広がる という当たり前の話があったのですが、 『語学が苦手だけど、Google(海外)で勤務できるようになった』という岩尾さんの経歴を知ると、頑張ってみようと思えました。 とても感謝しています。

Chrome Dev Summit 2019: Recap

Speaker: 矢倉 眞隆さん

Chrome Dev Summit(CDS) は、今まで以下のようなテーマが中心でした。

• 2013
  • Web API, パフォーマンス
• 2015
  • PWA

そして、今回の CDS では今までの ゴリゴリの JS 話から少し外れたものもいくつかあり、 その紹介をされていました。

HTML と CSS

HTML isn't done.

https://www.youtube.com/watch?v=ZFvPLrKZywA

HTML は、まだ成熟されたものではなく、まだまだ改善の余地があるという考えから、 いくつかの改善提案の話が紹介されていました。

丸裸な純粋の HTML でも、わかりやすい UI を標準で表現できるのであれば、ユーザーにとっては ありがたいことですよね。だって、いろんなサイトのいろんな UI を知らなくて済むのですから。 個人的(開発者)には、Edge が Chromium ベースになることが、とても嬉しいです。 リリースが 2020 年 1 月 15 日だそうなので、もう間もなくですね。

Next-generation web styling

https://www.youtube.com/watch?v=-oyeaIirVC0

scroll-snap という機能は、スクロールの制御を CSS で実現しようとしています。 従来は、Javascript でハックな技を駆使していましたが、不要となります。 デザイナーだけでなく、JS を担当するエンジニアも必見です。

JS +SEO

SEO の話がありました。

https://www.suzukikenichi.com/blog/how-to-make-your-content-shine-on-google-search/

Googlebot が最新の Chromium ベースになったことで、Chrome でブラウザを動かすのと同じような振る舞いになるそうです。 今までは、Chrome 41 ベースで Googlebot が動いていたため、新しい JavaScript 構文やブラウザ API を使えなかったそうです。 また、ShadowDOM にも対応しているので、これは WebComponents を推進していることになるのでしょうか。

リアルワールド指向のパフォーマンス

開発環境で Javascript を動かしたとしても、本番環境で動かすと実は遅かったりします。 それは、Javascript による処理が複雑化していることも要因となります。 この現象は、ネットワーク通信が悪い環境（海外）であれば、より明確に実感するはずです。 このようなケースを考慮したテスト環境が必要なのではないかと、私は思います。

以下の記事にある通り、Google は「遅い」と感じるページに警告を出してくれます。

https://jp.techcrunch.com/2019/11/12/2019-11-11-google-chrome-to-identify-and-label-slow-websites/

パフォーマンス計測ツールを活用することで、事前に確認しておきましょう。

• web.dev
• PageSpeed Insights
• Lighthouse

また、Javascript をシングルスレッドによる低パフォーマンスに対するアプローチ方法を紹介されていました。

https://www.youtube.com/watch?v=7Rrv9qFMWNM

詳しくは、下記をご参考下さい。

https://medium.com/lazy-learning/my-summary-of-the-main-thread-is-overworked-underpaid-chrome-dev-summit-2019-cd65efdf1ce1

ネイティブアプリと Web アプリの差を埋めるには：Project Fugu とマルチスレッドプログラミング

Speaker: 清水 智公さん

ネイティブアプリと Web アプリの差

Web アプリは、ブラウザ上で動作するのものです。ブラウザから提供されている API を通して、Web アプリを構築します。 しかし、ブラウザからマシンのネイティブな部分、例えばマシンにあるファイルにアクセスしたり、ファイルをマシンに 保存したりする操作はできません。この制限は、ブラウザが安全性を担保するためのトレードオフであり、仕方がありません。

Project Fugu

Fugu’s mission is to close the capabilities gap with native to enable developers to build new experiences on the web while preserving everything that is great about the web.

https://www.chromium.org/teams/web-capabilities-fugu

Project Fugu とは、ネイティブとのギャップを縮めるために、(Chrome)ブラウザからネイティブな部分を操作する試みのプロジェクトのことです。 ネイティブ部分を操作するため、誤った使い方をするととても危険です。 そのような危険性を、『毒』を持つふぐの名前を借りて Project Fugu というそうです。

提案中の機能一覧は、下記のシートになります。

http://goo.gle/fugu-api-tracker

この中には、例えば『Contact Picker API』というものがあります。 名前の通り、ネイティブアプリに登録されている電話帳にアクセスできるようになります。 これにより、例えば『シェアしたいユーザーの情報を電話帳より取得する』ことが実現できます。

Worker

ブラウザは、Task(Event→Scripting→Rendering→Painting)という単位で動作します。 これは、1 つのメインスレッドのみで動作します。

ブラウザにおける fps の目標値は 60fps だそうです。

60fps のフレームレートがなめらかなパフォーマンスの目標値であり、あるイベントに対して必要なすべての更新に与えられた時間は 16.7 ミリ秒です。

https://developer.mozilla.org/ja/docs/Tools/Performance/Frame_rate

1Task を実行するのに 16.7 ミリ秒を超えてしまうと、ガタガタした動作になってしまいます。 そこで、Web Worker という技術で解決しようと考えました。

Web Worker は、ウェブコンテンツがスクリプトをバックグラウンドのスレッドで実行するためのシンプルな手段です。

https://developer.mozilla.org/ja/docs/Web/API/Web_Workers_API/Using_web_workers

しかし、スレッド間のメッセージパッシングが複雑化してしまう問題があるそうです。 その問題を、さらに解決するため、GoogleChromeLabs は、comlink なるライブラリを開発しました。

Comlink makes WebWorkers enjoyable. Comlink is a tiny library (1.1kB), that removes the mental barrier of thinking about postMessage and hides the fact that you are working with workers.

https://github.com/GoogleChromeLabs/comlink

Web Worker におけるメッセージパッシングの複雑さが comlink によって減少するそうです。

※ atomics.wait() atomics.notify()の話もありました。

How to Distribute Your Web App? 「インストール」可能なウェブアプリ

Speaker: 宍戸 俊哉さん
タイトル通り、Web アプリをどのようにして配布するのかというテーマで、 様々な手段の紹介をされていました。

PWA

Web 好きならご存知の Progressive Web App (PWA)のお話です。 Web アプリに対して、よくある PWA 機能は次のとおりです。

• オフラインで閲覧
• Push 通知
• フルスクリーン

PWA は、Web アプリでありながら、ネイティブアプリにとても近い存在に位置しています。

例えば、サンタトラッカーという Web アプリがとても良い例です。

https://santatracker.google.com/

ソースコードも公開されており、PWA として良い参考例になります。

https://github.com/google/santa-tracker-web

この Web アプリを『ホーム画面に追加』し、その追加されたアプリを起動してみて下さい。 ネイティブアプリと似たユーザー体験ができるはずです。

ブラウザのブックマークで良いのでは？

わざわざ『ホーム画面に追加』しなくても、ブックマークを使えばよいのでは？ という議論がありました。 話の主となっていたのは、モバイルファーストというキーワードでした。 現在、モバイルからのブックマーク利用率はとても小さいみたいですが、 『え？普通に利用しているけど』と反感してしまいました。私が遅れているのでしょうか。 今の時代、『ホーム画面に追加』が多いのでしょうか。少し疑問です。

インストールを促す手段

PWA をインストールしてもらう場合、Mini-infobar というもので誘導します。 ただ、この Mini-infobar はヘルパーとして使われるため、別途 UI を用意する必要があるそうです。

The mini-infobar is only meant as a helper, and it will go away in the future.

https://developers.google.com/web/fundamentals/app-install-banners/promoting-install-mobile

ただ、既にネイティブアプリがある場合、PWA のインストール要求したくありません。 そんなときは、『既にネイティブアプリをインストールしているかどうか』判断する仕組みが既にあるそうです。(origin trials)

https://web.dev/get-installed-related-apps/

Desktop PWA

モバイルだけでなく、Desktop にも PWA を適用できます。

先程紹介したサンタトラッカーは、Desktop PWA にも対応しています。

https://santatracker.google.com/

アドレスバーにある+ボタンよりインストールできます。

Trusted Web Activities (TWA)

Trusted Web Activity は、Android アプリ内で Chrome ブラウザを全画面で実行します。

https://developers-jp.googleblog.com/2019/03/trusted-web-activity.html

Android アプリでも、PWA が実現できるみたいです。

TWA は、Android アプリの全画面ウェブ コンテンツで WebView では利用できない Chrome 機能を使いたい場合や、Chrome ブラウザとオリジン ストレージを共有することでユーザーのナビゲーションが便利になる場合などに適しています。

私は Android ユーザーはないので、GooglePlay からアプリをダウンロードできません。

• Rakuten Pasha
• OYO Rooms

のようなものが TWA 対応しているそうです。 会社内で使うアプリ(勤怠, 経費, etc)を、TWA として配信することも１つの使い道と紹介されていました。

TWA の開発には、次のライブラリが便利だそうです。

https://github.com/GoogleChromeLabs/llama-pack

Web Packaging

PWA や Destop PWA, TWA といったもので、様々なところから Web アプリを 配布する手段が増えました。では、オフラインの場合はどうでしょうか。 その場合は、Web Packaging の Web Bundles が使えます。

https://github.com/WICG/webpackage

Web Packaging には、大きく２つのものが含まれています。

• Signed HTTP exchanges
• Web Bundles

前者は、AMP ページの URL を google ホストから元のホストへ戻す際に有効だそうです。

https://amp.dev/documentation/guides-and-tutorials/optimize-and-measure/signed-exchange/

後者は、Web のアプリケーションを人まとまりにし、オフライン上で提供することができるそうです。

https://www.youtube.com/watch?v=xAujz66la3Y

※ chrome canary フラグを有効化する必要あり

Yearly Web 2019

Speaker: Jxck さん
2019 に起きた Web に関する Topic をざっくりと紹介されていました。 ご本人のブログに、詳細が載っていますので、こちらでは項目だけリストアップします。

Perspective of Angular in 2020

Speaker:稲富 駿さん

セッション内容は、Angular における 2019 年のアップデート内容と、2020 年とその先の未来についてです。

以下を要チェック！

• dev.to/angular-jp
• community.angular.jp

ちなみに、私は Augular の v2 で止まっています。（笑）

Updates in 2019

Angular の価値(values)は、

• Apps That users to use
• Apps That developers to use
• Community where everyone feels welcome

という 3 点あるそうです。私にとっては、v2 へのアップデートで大変つらい記憶がありますが...。

2019 年,2020 年における Angular のバージョンは、

• 2019-05
  • v7.x
  • v8.x
• 2020-Q1
  • v9.x
• 2020-Q3
  • v10.x

こうみると、メジャーアップデートの更新がとても早いですね。 追いつくのが大変そうです。

v7.x

• Size Budgets by default
  • バンドル時のサイズを制限する機能
  • パフォーマンス向上を期待
• CDK Drag&Drop
  • 手軽に Drag&Drop を実行可能
• Virtual Scroll
  • 画面に見えているものだけ DOM 構築される
  • パフォーマンス向上を期待
• Bazel
  • gulp のようなビルドシステム
  • Opt-in support

v8.x

• Differential Loading by Default
  • ブラウザによって、polyfill の量をコントロール
  • レガシーの部分はそのまま。モダンブラウザの polyfill の量が削減
  • パフォーマンス向上を期待
• Dynamic Import for Lazy Loading
• Support Module Web Worker
• ng deploy
  • production build していない deploy が多くなかった。
  • かならず --prod となる。

主にパフォーマンス向上に取り組んだ 1 年だったそうです。 Angular は All-in-One なフレームワークなため、どうしてもアプリケーションのコード量が 他フレームワークに比べると多いと思います。そうすると、アプリケーションを読み込む際に、 必要以上にロードされ、パフォーマンスが問題視されていたのでしょうか。

Roadmap 2020

2020 年の Angular はどんなものになるのか、紹介されていました。

v9.x

• Ivy by Default
  • Ivy は、angular の次世代コンパイラだそうです
• CDK Clipboard API
• CDK Testing Harness
  • コンポーネントのテストをより抽象化
  • await 処理が簡単になった
• @angular/components
• Strict Type -checking in templates

2019 年はパフォーマンスというユーザーのための取り組みで、 2020 年は開発者向けの取り組みが多いという印象でした。

Imagine the Future

今までの Angular は、エンタープライズ向けのアプリや、 小規模のアプリに使われていました。

次は、Billion のユーザ向けアプリをターゲットにするそうです。 そのためには、そのアプリに寄り添った機能提供ができるようにと考えているみたいです。 例えば、SEO やアクセシビリティ、国際化といった観点です。

終わりに

Web の進化は早いなと実感した濃い一日でした。 吸収しすぎて、消化が追いつかないですね、ワクワクが止まらないです。

GDE の方々は、どの方も専門領域がとても詳しく、かつ、説明の仕方が上手という印象を持ちました。 私も GDE になってみたいので、得意分野を見つけるところから始めようと思います。

また来年 GDG イベントありましたら、参加したいなと思います！

Tags