「PWA Night vol.3 ~PWAのミライや活用方法をみんなで考えよう~」に参加してきました

  • PWA Night vol.3 ~PWAのミライや活用方法をみんなで考えよう~に参加してきました。

pwanight.connpass.com

  • 今回はキャッシュ周りの話が多く実践的なノウハウが多かったんじゃないかと思います。開発する時に資料活用させてもらいます。
  • 参加者全員の自己紹介があったので参加者の層もなんとなく分かってそれも良かったです(アカウント名とアイコンと紐付かないのが残念!)
タイトル 発表者
既存のWebサイトをPWA化してみよう~Sevice Worker導入手順解説~ 小椋陽太さん@アシアル
Cache APIに触れる @tiwu_officialさん
RoRをVueJS + Nuxt PWAで置き換えてみた 天野たけしさん@devMeTokyo
最大公約数的なServiceWorker制作から見るPWAの勘所 進藤龍之介さん@NPO法人日本Androidの会
ServiceWorkerのCacheでいろいろと問題が起きた話 biga816さん
Ionic PWA Toolkitについて scrpgilさん

既存のWebサイトをPWA化してみよう~Sevice Worker導入手順解説~

  • 小椋陽太さん@アシアル

PWAとは

  • Googleが推進するモバイルWebのユーザ体験の指針
  • Reliable
  • Fast
  • Engaging

ServiceWorker

  • バックグラウンドで動くスクリプト
  • アプリごとにブラウザに登録される

ServiceWorkerのイベント

  • install
  • wait
  • activate
  • uninstall

SWの更新

  • 全てのタブでアプリを終了すると次に開いた時に更新済みのものが適用される

Cache APIに触れる

PWAの特徴

  • その一つにネットワークに依存しない

CacheAPI

  • ServiceWorkerがキャッシュの仕組みを持ってるわけでない
    • requestのイベントを拾えるだけ
    • CacheAPIがキャッシュの機能を持っている
  • ServiceWorker内でなくても使える
  • 有効期限はない

プロダクトでのキャッシュの使い方

  • 一覧画面で詳細画面のリソースをキャッシュしておくとか
  • 新しいバージョンが来たら古いバージョンを消しておく

RoRをVueJS + Nuxt PWAで置き換えてみた

  • 天野たけしさん@devMeTokyo

PWAの効果

www.pwastats.com

PWAの導入

  • 新しいことをやらないといけないか?
    • 今あるアプリを改良するとKPIや売上があがる
    • 既存のビジネスモデルを変える必要はない

最大公約数的なServiceWorker制作から見るPWAの勘所

PWA4WP

  • WordPressのPWAプラグインを作った
  • PWAはキャッシュが命
    • キャッシュファースト/オフラインファーストの選択
    • キャッシュするファイルの選択
    • キャッシュの有効期限
    • キャッシュファーストとオフラインファーストの組み合わせは今後実装
  • キャッシュするしないの選択が大事

ServiceWorkerのCacheでいろいろと問題が起きた話

  • biga816さん

キャッシュ上限に到達

  • 画像を全部キャッシュしてた
    • 容量上限に達してしまった
  • 上限や期限を設定しないといけなかった

開発環境でのみキャッシュの上限に到達

  • 開発中はAoTコンパイルしてないのでコードの量も大きかった
  • 定期的にキャッシュ削除

キャッシュから動画が再生されない

まとめ

  • 容量上限意識する必要あり
  • 無限に増えるコンテンツはCDN使った方がいい

Ionic PWA Toolkitについて

  • scrpgilさん

Ionic

  • Ionic4はAngular捨ててWebComponentsベースのUIフレームワークになった
    • ReactとかVueでも使えるようになった
  • cordvaからcapacitorに変わった

PWA Toolkit

ionicframework.com

  • ionicチームが出してる
  • デフォルトでいろんな設定やってくれてる
  • スタータープロジェクトが充実

「Frontrend × Bonfire Frontend」に参加してきました

  • Frontrend × Bonfire Frontendに参加してきました。

frontrend.connpass.com

  • YahooとAbemaTVの若手社員の入社から現在までの成長についてお話をきくことができました。
  • 学生エンジニアから事業プロダクトを作るプロのエンジニアに成長できた」という言葉もありましたが、単にアプリ開発をするだけでなくKPIなどを意識して取り組んでいる姿勢が印象的でした。
  • 原さんの発表はノウハウがかなりつまっていたのでスライドをじっくり見返しておきたいと思います。
タイトル 発表者
新卒3年目、ヤフーで学んだ2年間を振り返る 濱田 唯 / ヤフー株式会社
AbemaTV 新卒1年目エンジニア実録 野口 直 / 株式会社AbemaTV
Webフロントエンド&デザインで学んだ2年間を総括 内藤 秀彦 / ヤフー株式会社
こえのブログでのPWA 〜開発現場編〜 原 一成 / 株式会社サイバーエージェント

新卒3年目、ヤフーで学んだ2年間を振り返る

  • 濱田 唯さん / ヤフー株式会社 メディアカンパニー マーケティングソリューションズ統括本部
  • 2017入社 エンジニア入社からフロントエンド

入社して2年

  • 新卒研修(3ヶ月)
  • OJT(3ヶ月)
  • 本配属
  • 広告入稿管理システム

2年での成長ポイント

チーム開発の心構え

  • コードレビューは大事
  • 人が読むことを意識して書く
  • レビューはプロジェクトの雰囲気を作る

設計構成への意識

  • 動けばいいではダメ
    • 大人数で長期で運用される
  • チームごとのルールにのっとったアーキテクチャで開発
    • TypeScript
    • re-ducks
    • AtomicDesign
  • 大事なのは
    • ルールが言語化されてること
    • メンバーが合意してること

新しい技術に対する意欲

  • 自分も議論に参加するために意欲的になった

AbemaTV 新卒1年目エンジニア実録

  • 野口 直寛さん @nodaguti / 株式会社AbemaTV 開発本部

1年目エンジニア実録

  • 配属から1年弱で約560PR10万行
  • 新卒研修:4月-5月
  • AbemaTVに配属:5月
  • 5-8月
    • コミット/PRの粒度に慣れた
    • 担当した機能はレビューもできるようになった
    • RxJS使ったFluxのフローを一通り作れた
  • 8-12月
    • 大きな案件でタスク分解/見積もりしてスケジュールどおり進行
    • プロダクトを伸ばすにはどうすればいいか考え実行
    • Chrome Dev Summitに参加
  • 1-4月
    • ディレクターやエンジニアにヒアリングして曖昧な仕様を固める
    • リリースまで持っていった
  • 振り返り
    • 学生エンジニアから事業プロダクトを作るプロのエンジニアに成長できた
    • どうUXに影響するか、どうKPIに影響するか考えられるようになった

2年目に向けて

  • 技術から事業に貢献できるエンジニア

Webフロントエンド&デザインで学んだ2年間を総括

  • 内藤 秀彦さん / ヤフー株式会社 ショピング統括本部
  • 2017入社 デザイナー入社からフロントエンド

入社から本配属

  • デザイナー研修
  • OJT
  • デザインによるサービス改善
    • サービスの課題を探して解決する
    • 商品数が多いので抽象的なワードで探しにくい
    • 絞り込みのUIを改善
    • ABテスト
    • 何が利いて効果があったか分かるようにするとよい
  • UIパーツのコーディングお作法
    • モジュール単位でパーツを実装
    • SCSS
      • カラーなどは共通化
      • よく使うスタイル軍はmixin

本配属から2年目の終わりまで

CVRを伸ばす改善サイクル

  • CVR: コンバージョン率
  • 課題に対して再現性のある勝ち筋を見つけサイクルを回す

UIパーツの整理

  • 一つのサービスなのに似たような部品がたくさん出来てしまう
    • UIライブラリを作った
    • コードと使い方をまとめたドキュメント

レガシーからモダンな開発環境へ

  • Before
    • PHPではきだしたHTMLにjQueryでDOM操作
  • After(移行中)
    • React/Redux/Next.js

今後

こえのブログでのPWA 〜開発現場編〜

PWAの高速化

  • PRPLパターン
    • Push,Render,Pre-cache,LazyLoad
  • CDNの活用
    • できるだけCDNにキャッシュする
    • originサーバまでアクセスしないから高速

コンポーネント指向

  • WebComponents
    • LitElements
  • 影響範囲を狭めることで捨てやすくなる
  • スタイルのCascadeとShadowDOOMによるスコープをそれぞれ活用する

WebでAudioRecording

  • ブラウザからマイクを利用できる
  • WAVはファイルサイズ大きいのでmp3に変換して使ってる
    • vmsg

開発フロー

  • 餅つき開発
    • 細かい粒度でプルリク
    • 捨てやすいように細かく
  • 最速でプロトタイプ
    • 無駄になることを恐れない
    • リリース前に出戻りになるよりいい
    • Firebase便利

「Cloud Native Meetup Tokyo #7」に参加してきました

  • Cloud Native Meetup Tokyo #7に参加してきました。

cloudnative.connpass.com

タイトル 発表者
Telepresence ではじめる k8s 時代のローカル開発 Toshihiro Goto@_shiro16(GMOペパボ)
Consul Kubernetes Integration and Consul Connect Ryo Takaishi@r_takaishi(GMOペパボ)
分散イメージレジストリの検討 〜Beiran & Dragonfly〜 安田 侑史@yupeji(クリエーションライン株式会社)
フルカン ムスタファ@furkanmustafa(Rainlab 株式会社)

Telepresence ではじめる k8s 時代のローカル開発

Telepresenceとは

  • サービスをリモートのk8sクラスタにつなぎながらローカルで動かせる
  • ローカルで動いてるアプリがクラスタの一部みたいな感じで扱える
  • 何がうれしい?
    • build/push/podのimage更新といった手間を省ける
    • ローカルからリモートの他のサービスに接続しながら開発できる
    • ネットワーク経路がデプロイしたときとほぼ同じになる

Telepresenceの使い方

  • brewでおとせる
  • 起動のパターン
    • ローカルで起動したアプリ
    • ローカルデ起動下docker上で動くアプリ

Telepresence導入のポイント

ハマりポイント

  • port80を使う場合
    • 80は使えないので他のポートにする必要あり
  • 1podに複数コンテナある場合
    • defaultのcontainerが置き換わる
    • defaultじゃないのがいいときはオプションで指定
  • dockerを使う場合
    • mountが遅い

参考

Consul Kubernetes Integration and Consul Connect

Consulとは

  • hashicorpが作って
  • Conusulの機能
    • Service Discovery for Connectivity
    • Service Segmentation for security
    • Service Configuration for runtime configuration

Consul Connect

  • サービス間通信の暗号化や認可
  • サイドカープロキシ
  • Consul Connect Proxyの代わりにEnvoyも使える

Kubernetes Integration

分散イメージレジストリの検討 〜Beiran & Dragonfly〜

  • 安田 侑史@yupeji(クリエーションライン株式会社)
  • フルカン ムスタファ@furkanmustafa(Rainlab 株式会社)

背景

  • docker pullするの遅い
  • Peer to Peerでそれを早くする

Dragonfly

Kraken

Origin

  • Seeder
  • マルチクラスタしたときに別のところにデータをとれる

Tracker

  • どのデータがどのチャンクを持ってるか知ってる

Proxy

  • Docker Registry Interface

Beiran

  • 自作のライブラリ
  • peerにイメージ持ってるか聞き回る
  • 隣の人が持ってれば高速にインストールできる
  • dockerコマンドの頭にbeiranをつけて使う

「どこでもKotlin #7 〜Kotlin MPP特集〜」に参加してきました

  • どこでもKotlin #7 〜Kotlin MPP特集〜に参加してきました。

m3-engineer.connpass.com

タイトル 発表者
Kotlin/MPPでX-PF事始めのつまづきポイント yashims85 (モバイルファクトリー)
How to publish a Kotlin Multiplatform Library 荒谷 光 (サイバーエージェント)
DroidKaigi 公式アプリのKotlin Multiplatform takahirom (AbemaTV)
Kotlin/NativeのiOSにおけるオーバーヘッド 星川 貴樹 (エムスリー)

Kotlin/MPPでX-PF事始めのつまづきポイント

なぜKotlin/MPP?

  • いい感じにクライアントサイドをリプレイスしたいから

Kotlin/MPP構成

  • Android/iOSのクライアントアプリ
  • クライアントのプレゼンテーションルータ
    • KoRouter
    • VueRouterみたいなもの
  • KoRouter
    • commonMain
      • 成果物はmetadata
    • jvmMain
    • iosMain
      • Native向け
      • iOS
      • 成果物.framework
  • クライアントアプリ
    • commonMain
    • androidMain
      • jvmMainのサブセット
    • iOSMain
    • main
      • AndroidManifestが入ってるだけ
      • 成果物.aar

まとめ

  • 目的によって構成を変えよう
  • なにが同じライブラリかどこかにまとめておくとよい
  • kotlinx難しい

How to publish a Kotlin Multiplatform Library

MPPライブラリのパッケージ構成

MPPライブラリのGradleの設定

  • IntelliJだとKotlinの雛形選べる

まとめ

  • Kotlin1.3からはbuild.gradleは一つで
  • metadataの成果物はcommonのこと
  • androidの配布はreleaseを明示的に

DroidKaigi 公式アプリのKotlin Multiplatform

  • takahiromさん(AbemaTV)

Kotlin Multiplatformを導入しやすい構成に

  • Ktor-Client + kotlinx.serializationを使う
  • Andorid定番のRxJavaなどはMultiplatform非対応
  • Modelで使うクラスはKotlin Multiplatformで使えるものだけにする
  • Klockというライブラリで日時など扱える

Kotlin MultiplatformとDagger

  • Dagger
    • DIライブラリ

Dynamic feature module

  • 必要ないものはあとかダウンロードしてくる

APIの環境切り替え

  • iOSあるからAndroidのBuildConfigだけではだめ

ハマったこと

  • 古いiPhoneだと動かないとか

Ktolin Multiplatform使ってどうだったか

  • Kotlinで書いたクラスやメソッドがXCodeの補完がきく
  • キャストもうまく動いてる

Kotlin/NativeのiOSにおけるオーバーヘッド

  • 星川 貴樹さん(エムスリー)

マイクロベンチマークの結果

ラムダ式の比較

  • inline化するとあまり変わらなかった
  • inline化しないとKotlin遅い

in(contains)の比較

  • kotlinはだいたい遅い
  • contains使うなら定数化するとよい

forEachの比較

  • forEachとfor inとfor in step
  • Kotlinのほうが圧倒的に速い
  • 特にfor inとfor in stepが遅い
  • kotlinでもforEachは遅い

ツールの紹介

AppCode

Hopper Disassembler

相互運用のオーバーヘッド

  • SwiftからKotlinを呼ぶコード遅い
  • Kotlinのクラス生成が遅い

相互運用におけるオーバーヘッド

  • Kotlin/Native内で完結する処理は割と高速
  • Hopper便利

「freee Tech Night #2 「大規模SaaSを支えるフロントエンドの話」」に参加してきました

  • freee Tech Night #2 「大規模SaaSを支えるフロントエンドの話」に参加してきました。

freee-tech-night.connpass.com

  • freeeのシステムは歴史があってかなり大規模だということを初めて知りました。
  • 多くのエンジニアで大規模なシステムを開発してい、普段のフロントエンドの勉強会ではあまり得られない考え方を得られました。
    • yarnからnpmに戻した理由なんかは大規模ならではだなと思いました。
    • デザインシステム作って効率的に開発できるようにする、なんていう夢はいろんな人が考えると思いますがそれを実現する段階まできていてすごいと思いました。
タイトル 発表者
会計freee7年目のフロントエンド開発 Takumi Ohashi
会計freee が yarn から npm に出戻った本当の理由 @_kemuridama
デザインシステムの設計とアクセシビリティの実現 @ymrl
最新の新プロダクトのフロントエンド事情〜freeeアプリストアの事例〜 横路隆

会計freee7年目のフロントエンド開発

  • Takumi Ohashiさん

会計freee

  • 単一リポジトリで7年くらいやってきた
    • モノリシックなRailsアプリ
    • フロントエンドもそこに含む
  • もともとcoffeeだったのを置き換えていってる
  • フロント/サーバの区分はなくみんなRailsとReactスキルが必須

初期 - 2014年の構成

  • Backbone
  • CoffeeScript
  • 片手間JSだった時代
  • 一つのGlobal変数でデータを共有

2015年- の構成

  • ES2015
  • React
  • babel

現在

  • ほぼReact
  • SPAではなく小さなSPAの集合みたいな感じ
  • ESLint/Prettier
  • Storybook
  • flowtype
  • jest

facebook/flux続けてしまった

  • Reduxではなくflux(アーキテクチャではなくライブラリの方)を使っている
    • 当時はReduxロックインを懸念してより薄いfluxを採用
  • 薄いがゆえにいろいろできすぎてしまう
  • 情報量が少ない
  • コード量が大きくなりすぎてReduxへの移行は厳しくなった

コンポーネントの状態をStoreで管理してしまった

  • 例えば
    • モーダルの開閉
    • ローディング
    • フォームの値
  • UIStoreというのを作ってそこで管理した
  • 非同期処理でAction2つ呼ぶのがつらい

Reactコンポーネントを継承して使ってしまっていた

振り返って

  • 初期の設計や規約がちゃんと整備できてなかった
  • 大規模ゆえに軌道修正が難しい
  • 誰かが横断的に監視し続けるにも限界がある
  • ルールの整備を勧めてる

今後

  • 共通UIコンポーネントライブラリを開発してる
  • フロントエンド委員会も継続的に活動中

会計freee が yarn から npm に出戻った本当の理由

  • @_kemuridamaさん

yarnからnpmにで戻るというブログを書いた

npm vs yarn

npm

  • nodeに内用される
  • officialなパッケージマネージャ

yarn

本当にyarnが必要なのか

yarnの利点

  • 高速インストール
    • かつては20倍
    • npm6ではほぼ同等
  • ロックファイル
    • パッケージが依存するパッケージのバージョンを固定できる
    • package-lock.jsonが登場した
  • ワークスペース
    • monorepoを管理する機能
    • Lernaを使えばnpmでもできる

なぜnpmに戻したか

複数バージョンのyarnが使いにくい

  • プロジェクトごとにバージョン返るのがやりづらい
  • yvmというものもあるけどnodeenvのように使いやすいものではなかった

2つのビルド環境

  • CircleCIによるDockerベースのビルド
  • Jenkinsによるビルド
    • 本番向けのビルド
  • 環境ごとにyarn入れるステップが増えてしまう

エンジニア組織の巨大化

  • npmは最初から入ってるから誰でも使える

npmに出戻るまでの道のり

  • yarn.lockの削除
  • node_modulesの削除
  • npm iでパッケージ再インストール
  • lockの移行は素直に行かないのでE2Eで担保

まとめ

  • npmの課題が解消されyarnのメリットが薄れてきた
  • エンジニアが多いことによるyarn導入コストの増加した

デザインシステムの設計とアクセシビリティの実現

  • @ymrlさん

会社の規模が急激の大きくなった

freeeのWebフロントエンド開発

  • デザイナーが画面モック作ってエンジニアへ
    • sketch
  • そこから先はエンジニア

大きくなってきた頃のWebUI

  • Bootstrapあら独自UIに
  • 要件が複雑化する一方で環境整備の不備が目立つ
    • CSS得意な人あんまりいない
  • 微妙に違う実装がうまれてくる
  • フロント不慣れな人も書くのでめちゃくちゃになってきた
  • UI作るのがつらい状況に

UIの統一的なチーム

  • Atomic Design and GuideLineチーム
  • どのデザイナーでも統一されたUIをデザインできるようにする
  • フロントエンド不慣れでも統一したUIをじっそうできるようにしたい

UIガイドライン

アクセシビリティ

  • 誰でも使えるサービスにしたい
  • 機能がどんどん増えてるので少ない人数でやっていくの大変
  • ESLintでJSXタグをチェック
    • Storybookに対して自動チェック回したり
    • a11yのaddonがある

今後

  • デザインシステムほぼ実装完了
  • サービスへ導入中
  • Sketchライブラリの共有が課題
    • SketchClooudで配布
    • 将来的にFigmaやAdobeXDにするかも
  • SCSS無秩序にオーバーライドされそうで怖い
  • ReactやFlowtypeへのロックイン問題
    • TS対応の検討
    • Vueなど使うプロジェクトがでてきたら・・