誘われて行ってきました、GDG DevFest！
寝坊して午後からでしたが、割と楽しめました 🙂

内容は発表者の方々の資料を見たほうが早いと思うので、
気になったポイントだけ記録しておきます。

Growing your app with Fireabase

スピーカー：@shihochandesu
資料：Growing your app with Firebase – Speaker Deck

In-App Messaging [BETA]

アプリのアクティブユーザに対して、使用中にメッセージを送れる。
バージョンアップしてねーとかそういうやつらしい。
対応バージョンがAndroid4.4〜、XCode9.2〜なので注意。
1日に1回かn日に1回で、1日n回はできない。

使いどころ難しいけど、ロイヤリティを高めるためには使えそうな感じ。
Qiitaでわかりやすく紹介してくれているので、詳しくはこちら。
Firebase In-App Messagingを早速触ってみたのでまとめる

Google Analytics

初期化するだけで基本的なプロパティを全部収集してくれる

今の業務でもGA（not Firebase）を使用しているけど、
これだけでいろいろやってくれるならこっちにしても良かったなーと。
そもそもFirebaseを使うとこからですけど。笑

Predictions [BETA]

Analyticsで収集したデータをもとに機械学習でより高レベルの分析ができる
* 今後7日間でアプリ利用を停止するユーザ
* 今後7日間でアプリ内課金をするユーザ
などのグループを作ってくれる。

リスクの許容度（厳密度）も設定できるらしい。
信頼は下がるけど、もう少し量の多いデータが見れるとか。

自分で作るときぜひ入れたい！純粋に面白そう。

A/B Testing

Predictionsで作成されたユーザグループをテスト対象として、
A/B Testing（プッシュ通知の文言やデザインだけを変えての実証テスト）でテストできる。

サービス開発だったらきちんとやりたいなーと思っている。
Cookpadに憧れる。

Cloud Messaging

メッセージ送信。そのまま。
* 通知メッセージ　FCM SDKによって自動的に処理される
* データメッセージ

このへん、自力で実装するのは大変ですよねー。

Remote Config

アプリのアップデートなしに動作やデザインを変更することができる。
クリスマスデザインとか。

Dynamic Links

Webサイトからアプリをインストールしても、
Webサイトで見ていたページをそのまま開くことができる。

これすごいー！離脱率下げられそう。

App Indexing

Google検索結果にアプリのディープリンクを表示できる。
Appleの仕様変更でiOSでは実装できなくなったそう。
Appleは全面的にGoogleと対抗してきますね…笑
Google、iOS向けApp Indexingを停止。ランキングへのプラス影響もなくなった | 海外SEO情報ブログ

新しいMaterialDesignとMDC

スピーカー：@nyanyoni、@yanzm)、@joooi13
資料：DevFestTokyo 2018 – Google スライド

新しいMaterial Design

日本語PDFないらしい。残念…

Material Theming

ブランドを反映しつつ、マテリアルデザインを使える。
オリジナリティが出せるというのが売りらしい。
Sketchのプラグインを利用するとMaterial Theme Editorが使えるらしい。

開発ロードマップがすでに提示されていて、
Flutterが一番進んでいるというのが個人的なびっくり。

AndroidX対応

あー、早めにやっといたほうがいいんだろうなー…。（独り言）

TypeScript導入で得られる「変えていく勇気」

スピーカー：@okunokentaro
資料：GCP Compute 概要と選定 / DevFest Tokyo 2018 – Speaker Deck

TypeScript自体には（実は）特に関心がなく、ぼんやり聞いたけど結構楽しかった。
コンパイルでチェックできる静的型付けはたしかにいい。
そして、テストコードには劣らないまでも、
コンパイルできるからこそ得られる安心感にはなるほど。

って思いつつ、Swiftの存在ってなんなんだろうと、疑問…（）

途中からでもTypeScriptを取り入れられるというのもやっぱり◎。
扱う人間のスキルがJavaScriptとTypeScriptとで2つ必要になってしまうデメリットはあるけれど。

Firebase Realtime Database in Production

スピーカー：@brn227
資料：Firebase Realtime Database in production – Speaker Deck

Firebase Realtime DatabaseをAIMessangerというCyber Agentのプロダクトで
どのように利用したかという話。

直接クライアントサイドから書き込むのだと検索性にすぐれないため、
サーバからRealtimeDBに書き込むらしい。
デメリットとしては、データが二重管理になったり分散してしまったりすること。
APIを間に挟むので障害の可能性は高まる。

たしかになー。
サービス全体の規模感とか理想像にもよるかもしれないけれど、
API経由での利用を想定して作っておいたほうが拡張性は高いんだろうなと。
コンポーネントごとに管理するような感じで。

終わりに

期せずして午後からの参加となりましたが（笑）、なかなか楽しめました。
こういったイベントは意識高まるし今まで全く興味を持ってこなかったことにも触れられるので、
定期的に参加していきたいなーと思いました。
そして、参加するとアプリ作りたい浴が高まる…！
そろそろ本格的にVue.js学びます。（宣言）