2019/05/28(火)に行われた「Firebase Meetup #13 @DeNA」のまとめです。
ハッシュタグは#FJUGです🐦
イベントページはこちら↓
「FJUG」とは？
「Firebase Japan User Group」の略で、Firebaseの日本ユーザーグループのことです。
Firebaseが広く使われることを目的として活動している団体です。
詳細は以下のページをご参照ください。
コミュニティのSlackもあり、Firebaseについての交流が活発に行われています。
開場
- 時間：19:00–20:00
今回の主催はDeNAさんです。
研修室のような部屋で、しっかりと腰を据えて発表を聞くことができました。
開始前に流れていた曲が、ジョジョ第5部の終了間際に流れる曲に似ていたのですが、やはりそうとのことでしたｗ
ちなみに私は補欠の56番から奇跡的な繰り上げを果たし、本日の15時頃に参加が確定しました。諦めていたのでPCを持ってきておらず、スマホでTwitterを更新していました。
LT
firebaseでwebアプリを作る際のTips
- 時間：19:40–19:50
- 発表者：山下 悠介さん(@hand12_k)
Nuxt.jsとFirebaseを使ってサーバーサイドレンダリングのWebアプリを作られたお話でした。
作られたWebアプリはこちらです↓
スライド、Webアプリ共にデザインがおしゃれです。私もこのようにおしゃれなスライドを作れるようになりたいです。
クイズと解答はFirestore、画像はCloud Storageと分けて保存されていましたが、画像などの大きなデータはFirestoreに入れないのがベターなようです↓
Nuxt.jsなどWebアプリ開発の技術については詳しくないのでここでは触れません。
モバイルアプリだけでなく、Webアプリの開発にもFirebaseは効果的だと感じさせるスライドでした。
FirebaseNotification,RemoteConfigでユーザセグメントごとにプッシュ通知を実装する
- 時間：19:50–20:00
- 発表者：三堀裕さん(@1013Youmee)
Firebase Notification(Cloud Messaging)とRemote Configを使い、ユーザーを均等に分割してリモートプッシュ通知を送ったお話でした。
三堀さんは私と同じ会社で同じチームのエンジニアです。三堀さんはAndroid、私はiOS側の開発を担当しています。
今回の発表は実務の内容であり、両OSで実現しています。
発表を要約するとこんな感じです↓
他のアプリがどのようにリモートプッシュ通知の負荷分散をしているか気になったので、After Partyで何人かの方に伺ってみたところ、以下のようでした↓
他には「全ユーザーにリモートプッシュ通知を送っていないので、負荷分散の必要がない」という意見もありました。
できる限りコストを掛けずに、リモートプッシュ通知の負荷分散を行う際に参考になるスライドです。
Firebase Test Labの紹介
- 時間：20:20–20:30
- 発表者：Kenta.Kaseさん(@Kesin11)
Firebase Test Labについての発表でした。
会場の3割ほどはTest Labを知っていましたが、実際に使っている人はまさかの0人でした。私は「Test Lab」という言葉自体を初めて聞きました…。
UIテストを実行するサービスとのことです。私は業務でVisual Studio App Centerのサービスを使ってUIテストを実行しているのですが、それと競合するサービスのようです。
ちなみにBitriseのUIテストでは裏でTest Labが動いており、追加料金なしで使えるとのことです↓
Android Studioから実行できるのは便利だと思いましたが、iOS版は不安定なところもあるようで、採用は慎重に検討する必要がありそうです。
Androidのみですが、Roboテストという機能を使うとテストコードなしにある程度UIテストを実行できるとのことです。すごい…！
ポチさんのツイートは笑いましたｗ
Test Labsを使う際には参考にしたいスライドです。
Firebase Crashlytics のクラッシュ レポートをカスタマイズする
- 時間：20:30–20:40
- 発表者：かしはらさん(@kashihararara)
Firebase Crashlyticsのクラッシュレポートをカスタマイズされたお話でした。
私はFabricとFirebaseで2つあるCrashlyticsの違いがわからなかったのですが、現在はFabricからFirebaseに移行している最中であり、2020年3月には移行が完了するとのことです。
そのため、既存のプロジェクトでCrashlyticsを使っている場合、FabricからFirebaseに移行させる必要があります。
カスタムログメッセージやカスタムキー、ユーザーIDを使うことで、アプリの状態を出力したり、ユーザーを特定できたりするとのことです。
Analyticsと連携させることもでき、ボタンタップイベントや画面表示のログとスタックトレースを同時に出力することで、どの画面でどのような操作をしたらクラッシュしたか特定することが容易になります。
Firebase Crashlyticsのクラッシュレポートをカスタマイズする際には参考にしたいスライドです。
私も業務で早くFirebase Crashlyticsに移行したいと思いました。
2プロジェクトでAuthentication UserをSyncさせる 〜LINEログインを使ったカスタムログインでやる編〜
- 時間：20:40–20:50
- 発表者：ポチさん(@pitown)
Firebase Authenticationのカスタム認証を使ってLINEログインを実現したお話でした。
Firebase Authenticationを使ったことがないので着いていくのがやっとでしたが、After Partyでお話ししたところ、カスタムプロパイダを作れないのがネックのようでした。
LINEログインがデフォルトで用意されていない理由は、LINEが日本を中心に流行っているサービスということもありそうですが、ポチさん曰く以下とのことです↓
ちなみに今回は3人もの方がコンソールにソースコードを表示させていておしゃれだったのですが、そういったサービスがあるとのことです↓
こんな素晴らしいサービスがあるとは…！ 発表資料を作成する際にはぜひ使いたいです。
ポチさんのスライドは自分の言葉を多く取り入れていました↓
Firebase Authenticationのカスタム認証を使う際には参考にしたいスライドです。
ちなみにFirebase Authenticationでは以下も実現できるとのことです↓
独自の認証システムでなく、Firebase Authenticationを使いたいと思いました。
Firestore における CQRS の可能性
- 時間：20:50–21:00
- 発表者：yukin01さん(@_yukin01)
Firestoreの設計にCQRSを取り入れたお話でした。
「CQRS」という言葉は初めて聞いたのですが、「コマンドクエリ責務分離(CQRS:Command and Query Responsibility Segregation)」の略とのことです。
一言でいうと「Command(追加・更新・削除)とQuery(検索)は分けよう」ということのようです。
FirestoreのようなNoSQLの設計はしたことがなく、ノウハウも全くないので、非常に興味深い内容でした。
Firestoreの設計をする際には参考にしたいスライドです。
After Party
- 時間：21:10–22:00
食事はお寿司とまい泉のかつサンドでした。
まい泉のかつサンド、おいしい…🥪
After PartyではFJUGのコキチーズさんやKaseさんをはじめ、養命酒さん、かしはらさん、ポチさん、yukin01さんなど発表者の方ともいろいろとお話しさせていただくことができ、非常に充実した時間でした。
おわりに
Firebase限定のLTだとFirestoreなどの機能に集中するかと思ったのですが、意外とばらけ、Firebaseの知見を幅広く得られたのでよかったです。
