DevFest 2018 Tokyoに参加してきた話
TL;DR
DevFest 2018 Tokyoに参加してきたけど、すべてのセッションを聞くことは分身するか時間遡行しないと無理だったのでレポートだよ! 他の人も書いてくれると私が他のセッションに参加した気になれて幸せなので、書いて欲しいっす。
参加したセッション
技術領域 | セッションタイトル |
---|---|
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 パフォーマンス改善!
基本情報
- Presenter: Yusuke Utsunomiya (@uskay) | Twitter
- 資料:非公開(Tweetでセッション内でのTipsは紹介)
内容メモ
- ライブコーディングをしながら、自作したウェブサイトのパフォーマンスを改善していくというセッション。
- 作成した釣りのブログでまず、Lighthouseで現状分析 -> 18点
- ひたすら改善
- 最終的には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の用意めっちゃ大事
リンク
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はロイヤリティの低いユーザー向けなので、ストーリー設計がより重要になる
感想
リンク
Google AIY Vision kitで遊ぼう ~麻雀牌のリアルタイム識別
基本情報
- Presenter: RIo Kurihara
- 資料:後日公開
内容メモ
- 麻雀が好きだけど、符計算ができない -> 物体検出で符計算させるアプリを作ろう
- 先輩の協力でイケてる学習モデルができた
- 東北大学の学生チームとか、KDDIによる麻雀アプリがリリースされて焦る
- LINE Botの開発をしたが、若干もっさり...
- Google AIY Version Kit(スマートカメラ自作キット)でやろう
- 実演デモ
- 速度は改善したが、学習モデルの制約で精度は低い
- 今後の展望
感想
- ものづくりしてて、めっちゃ良い発表だった
- エッジ・モバイルデバイス上でMLを動かすニーズが高まってきてる -> TensorFlow.jsのとかに繋がってきてるのだろうか
- 実演デモで「3筒」とか「5索」がきちんと認識された
- 実演デモで「發」が「西」に認識されてた
- どれぐらい早くなったのか分からなかったので、比較みたいなの欲しかったかも
Flutterとの1年
基本情報
- Presenter: najeira (@najeira) | Twitter
- 資料:Flutterとの1年 - Speaker Deck
内容メモ
- 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
基本情報
- Presenter: きりん (@sota1235) | Twitter
- 資料:Realtime Database for high traffic production application - Speaker Deck
内容メモ
- Firebase Realtime Databaseをproductionに投入して1年経ったので、開発と運用と少しの技術的テクニックの話
- メルカリチャンネル(Live e-commerce)で使っている
- 開発
- 運用
- メルカリは全体で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導入で得られる「変えていく勇気」
基本情報
- Presenter: 奥野賢太郎 / Crescware (@okunokentaro) | Twitter
- 資料:TypeScript導入で得られる「変えていく勇気」 / The courage to change by TypeScript - Speaker Deck
内容メモ
- Typescriptの歴史
- JSは、HTMLの中に書けば手軽に動かせる言語から
.js
ファイルじゃない何かをJSへと変換して動かす言語に変化してきた - 変換するなら処理を足してコンパイルも変換に入れてもより安全にしたっていいんじゃない? -> Typescript
- JSは、HTMLの中に書けば手軽に動かせる言語から
- コードが腐る
- 型検査の安心感
- とはいえ、信用ならないこともあるので、値オブジェクトや混同防止プロパティを使っていこう
- 継承は抽象的性質の表現、Not、処理の共通化手段
- コンパイルエラーを有効に用いたリファクタリングメソッド:「炙り出し」の紹介
感想
- 型定義ファイル、昔はnpmで管理できなかったのか...つらそう...
- 昔は
.js
と.ts
を混ぜて運用もできなかったのか...つらそう - とある人が型検査は第1のテストって言ってたけど、まさにそういう話だった
- なぜ今Typescriptなのかという歴史から入って、実際にどんなTipsがあるかの紹介の構成は本当に分かりやすかった
- Typescriptやりたみが高まった
リンク
Firebase Realtime Database in Production
基本情報
- Presenter: Taketoshi Aono (@brn227) | Twitter
- 資料:Firebase Realtime Database in production - Speaker Deck
内容
- 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の資料をまとめてくれている方がいらっしゃるので、他のセッションの資料が見たい方はご覧ください