DevFest 2018 Tokyoに参加してきた話

TL;DR

DevFest 2018 Tokyoに参加してきたけど、すべてのセッションを聞くことは分身するか時間遡行しないと無理だったのでレポートだよ! 他の人も書いてくれると私が他のセッションに参加した気になれて幸せなので、書いて欲しいっす。

tokyo2018.gdgjapan.org

参加したセッション

技術領域 セッションタイトル
Web 仮)実践!!Web パフォーマンス改善!
Web PWAのイマ
ML Google AIY Vision kitで遊ぼう ~麻雀牌のリアルタイム識別
Flutter FLutterとの1年
Firebase Realtime Database for high traffic production application
Web TypeScript導入で得られる「変えていく勇気」
Firebase Firebase Realtime Database in Production

Webばっかりに偏るかと思ったら、意外とバランスがいい感じになりました。

セッション詳細

仮)実践!!Web パフォーマンス改善!

基本情報

内容メモ

  • ライブコーディングをしながら、自作したウェブサイトのパフォーマンスを改善していくというセッション。
  • 作成した釣りのブログでまず、Lighthouseで現状分析 -> 18点
  • ひたすら改善
    • リソースのサイズを圧縮(gzip化 / コードのminify)
    • 使ってないCSS/JSを送らないようにする(Code splitting / Dynamic import )
    • 画像の最適化(tool入れる / CDN活用 / Lazy Load)
    • リソースの取得順を調整(Resource Hintsでpreconnect / font-displayでフォント戦略の設定)
  • 最終的にはLighthouseで99点
  • パフォーマンスの改善は1つ改善して、auditsするの繰り返し
  • JSはDownload -> Parse -> Compile -> Executeの4段階を持つので、コストが高い
  • 高速なJSは4つのすべてで速い
  • Page Load時に見えるところを最優先して、地道に減らしていく
  • ほとんど同じ話がWeb performance made easy (Google I/O '18) - YouTubeで見れる

感想

  • devtools、めっちゃ便利
  • Webパフォーマンス改善のやっていきが高まった
  • ライブコーディングで改善前と改善後の差が一目瞭然で、分かりやすかった
  • ライブコーディング用のCheatsheetの用意めっちゃ大事

リンク

www.youtube.com

PWAのイマ

基本情報

内容メモ

  • PWAの魅力の1つは、UXがよくなること
  • PWAはNativeアプリをインストールするほどにはロイヤリティが高くない人にもアプローチできる手段
  • PWAはだいたい2つの技術でできている
    • Service Worker
    • Web App Manifest
  • SafariのPWAはかなり渋い
  • GitHub - Polymer/pwa-starter-kit: Starter templates for building PWAs.でPWA with Polymerができるし、PWAに限らないhelper関数を提供してくれる
  • PWAがGoogle DevelopersのWeb Fundamentalsにあるように、Webアプリの必須項目になりつつある
  • 世界的に見れば、Android優勢な国ほどPWAの成功事例が上がってきている(Ex. スタバ、航空会社)
  • 日本はApple次第かも
  • PWAは完全にNativeアプリを置き換えるものではない、あくまで別物
  • ページロードのタイミングで通知の許可を取りに行くのはアンチパターンオブアンチパターンなので、絶対にやらないこと
    • アプリでは、起動時に許可を求めるので、それと同じにしがちなウェブサイトがかなり多い
    • 1度、拒否されると現状では2度とアプリから通知の許可を求めるバナーを出すことができない
    • PWAはロイヤリティの低いユーザー向けなので、ストーリー設計がより重要になる

感想

  • iOS SafariのPWA対応が想像以上に渋くて驚いた
  • 世界的に見ると、PWAじゃないの?マジ?みたいな世界線になりつつあるのすごい

リンク

Google AIY Vision kitで遊ぼう ~麻雀牌のリアルタイム識別

基本情報

  • Presenter: RIo Kurihara
  • 資料:後日公開

内容メモ

  • 麻雀が好きだけど、符計算ができない -> 物体検出で符計算させるアプリを作ろう
  • 先輩の協力でイケてる学習モデルができた
  • 東北大学の学生チームとか、KDDIによる麻雀アプリがリリースされて焦る
  • LINE Botの開発をしたが、若干もっさり...
  • Google AIY Version Kit(スマートカメラ自作キット)でやろう
  • 実演デモ
    • 速度は改善したが、学習モデルの制約で精度は低い
  • 今後の展望

感想

  • ものづくりしてて、めっちゃ良い発表だった
  • エッジ・モバイルデバイス上でMLを動かすニーズが高まってきてる -> TensorFlow.jsのとかに繋がってきてるのだろうか
  • 実演デモで「3筒」とか「5索」がきちんと認識された
  • 実演デモで「發」が「西」に認識されてた
  • どれぐらい早くなったのか分からなかったので、比較みたいなの欲しかったかも

Flutterとの1年

基本情報

内容メモ

  • FlutterをProduction投入して1年経ったので、四方山話
  • 去年のGoogle I/Oから使ってる
  • 思うように動かなければ最悪、ネイティブで書けるとの確信からproductionへ投入
  • Hot Reload便利
  • Dartでのクロスプラットホームのコード共有率は、画面数ベースで95%、コードベースだと70%
  • ちょいちょいネイティブとFlutterの連携画面がある(OpenCV使う、テキスト周りのバグ回避)
  • Alphaから使ってるので、バグを踏み抜いてきた
  • BetaになってだいぶFixされた
  • UIのバグは大抵、回避策がある

感想

  • Flutter、よさそう
  • Flutterもreact-nativeも、クロスプラットホームは特殊文字が含まれるテキストは鬼門感がある
  • Alphaから使っていて、どっちのプラットフォームもネイティブコードを見れるってめちゃくちゃすごい
  • Hot Reloadは最高

Realtime Database for high traffic production application

基本情報

内容メモ

  • Firebase Realtime Databaseをproductionに投入して1年経ったので、開発と運用と少しの技術的テクニックの話
  • メルカリチャンネル(Live e-commerce)で使っている
  • 開発
    • クライアントからは直接、Firebaseを叩かずに、メルカリのサーバーを挟んで、サーバーからFirebaseのAPIをcallする構成にしている
    • この構成によって、更新頻度の間引きや禁止ワードのフィルタリングなどができ、Realtime Databaseに対するクライアントのpermissionを考えなくて済む
  • 運用
    • メルカリは全体で59000/secのAPI callがある規模感
    • メルカリチャンネルはだいたい1500stremers/day, 30K viewers/day, 5M yen / streamという規模感
    • Realtime Databaseはauto scaleしない、かつdatabaseごとに制約があるので、自前で15台以上のインスタンスを立てて、Vertical Shardingしてる
    • 今ならFirestoreがあるよ
    • モニタリングは自前ツール(KibanaとMackerel)とStackdriverでダッシュボード化して、異常状態と正常状態を可視化
    • 「すべてのサービスは落ちる」ので、問題発生->検知->対応のフローを迅速かつ円滑にいくように整備
    • メルカリチャンネルはしかるべき権限を持つ人がボタン1つで、メンテナンスモードに切り替えられる
  • Cloud FirestoreとRealtime Databaseの違いはThe Firebase Blog: Cloud Firestore for Realtime Database Developersを読んでね
  • 詳しいアーキテクチャが気になる人はRealtime Messaging with Firebase #phpcon2017 - Speaker Deckを読んでね

感想

  • メイン開発者のきりんさんがjoinしてから開発期間1ヶ月でメルカリチャンネル機能がローンチされてるのすごい
  • メルカリの規模感で本番運用してる知見、めっちゃ貴重
  • 障害発生時のAlertボットの配慮が行き届いて本当に良い
    • CSメンバーしか起きていないときでも意思決定ができるだけの情報を提供するために英語->日本語翻訳をかけてる
    • 障害発生は@channelだけど、復帰はつけない

リンク

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

基本情報

内容メモ

  • Typescriptの歴史
    • JSは、HTMLの中に書けば手軽に動かせる言語から.jsファイルじゃない何かをJSへと変換して動かす言語に変化してきた
    • 変換するなら処理を足してコンパイルも変換に入れてもより安全にしたっていいんじゃない? -> Typescript
  • コードが腐る
    • コードは変わらないけど、コード以外の部分(チームメンバーの技量、増減、仕様変更etc.)が劇的に変わっていく
    • 現代では、常にリファクタリングが求められ、それを行うためには「変えていく勇気」が必要
  • 型検査の安心感
    • とはいえ、信用ならないこともあるので、値オブジェクトや混同防止プロパティを使っていこう
  • 継承は抽象的性質の表現、Not、処理の共通化手段
  • コンパイルエラーを有効に用いたリファクタリングメソッド:「炙り出し」の紹介

感想

  • 型定義ファイル、昔はnpmで管理できなかったのか...つらそう...
  • 昔は.js.tsを混ぜて運用もできなかったのか...つらそう
  • とある人が型検査は第1のテストって言ってたけど、まさにそういう話だった
  • なぜ今Typescriptなのかという歴史から入って、実際にどんなTipsがあるかの紹介の構成は本当に分かりやすかった
  • Typescriptやりたみが高まった

リンク

Firebase Realtime Database in Production

基本情報

内容

  • AI MessengerというBtoB向けのチャットボットにFirebase Realtime Databaseを使っている話
  • データの書き込みはメルカリと同じく、Clientから直接Firebase Realtime Databaseは叩かず、一旦サーバーを経由する
    • メルカリと同じ構成ではあるものの、その理由はちょっと違い、主にRealtime Databaseのクエリの制約の厳しさ・データマイグレーションの大変さから
  • いくつかの技術的問題にどう対処したか
    • Realtime DBは意外と書き込みの反映が遅いので、Client側で管理が必要
    • 値のクエリでフィルタリングが非常に苦手なので、データ設計の段階からそうならないように考慮すべき
    • Firebaseで大量のデータにFilterをかけるとReadが100%になり、読み書きが停止する。Googleから何したんだと連絡が来たらしいw。Big Tableへのダブルライトで回避
  • Full ManagedなServiceだろうと、すべてのサービスは止まる
    • だが、BtoBなので、サービスが止まるは許されない(元々の仕様では、そこまで厳しいダウンタイム運用になる予定ではなかったらしい)
    • Realtime DB障害時はBigTableなどにダブルライトされているデータをPollingして擬似的にRealtime DBを再現
  • Cloud Firestoreへの移行していきたい

感想

  • 奇しくも、きりんさんのセッションとほぼ同じタイトルで、青野さんも苦笑いしてた
  • それだけFirebase Realtime Databaseがアツいということでもある
  • サービスを止めることができないという要件がPJ最初期に上がっていたら、Realtime DBの選定には行かなかった可能性もありそうな感じだった
  • Realtime DB、工夫が結構いりそうだった

リンク

全体を通して

  • セッション間の移動がめちゃくちゃ混んでて、運営チーム大変そうだった
  • Google Dev User Groupめっちゃあって、コミュニティ多くて楽しそう
  • セッション7本連続で聞くと、頭がパンクする
  • Realtime DBの話、2つあったが、別のサービス間で使い方の似ている所、違う所が比較できて良かった
  • 部屋が満室で入れないのは悲しい
  • WiFiはできれば、欲しい
  • セッションのプレゼンターは、ウェブ・ネイティブアプリ・MLなど色々なバックグラウンドの人が集まるので、どういう発表の組み立てにするか苦心しそう
  • 全体的なやっていきが高まった

最後に

運営チームの皆様、発表者の皆様、素敵なお祭りをありがとうございました!🎉

P.S.

DevFest 2018 Tokyoの資料をまとめてくれている方がいらっしゃるので、他のセッションの資料が見たい方はご覧ください