「Inside Frontend」に参加してきました

  • Inside Frontendに参加してきました。

inside-frontend.com

# タイトル 発表者
A-1 TypeScript: Why and how we adopted it at Slack Felix Rieseberg
A-2 Introduction to Lucet Adam Foltzer
A-3 Nuxt.jsで中規模サービスを統合した話 Koichi Sawada
Hajime Sasanuma
B-3 Making less of the web with feature policy Andrew Betts
C-3 デザインエンジニアとフロントエンド Shinichi Kogiso
A-4 formの送信ログから反省する、本当は必要だったvalidationや機能たち Yuta Ide
B-4 Web App Checklist 〜高品質のWebアプリケーションをつくるために〜 Kazunari Hara
Marina Toki
C-4 いちからデザインシステムを作ってみて学んだこと Kengo Haruno
A-5 BFFのDeveloper Experience Yosuke Kurami
B-5 strobo.fm公開収録 Shogo Sensui
Hiroki Tani
C-5 AbemaTVにおけるCSS is too fragile問題に対する解 Shota Kubota
A-6 世界中誰もが使えるサービスを目指して、Web標準で作るガラケーサイト Mariko Kosaka
B-6 Loading Performanceとの向き合い方 Sho Miyamoto
C-6 品質と開発速度を両立させるために捨てたものと守ったもの Tsuyoshi Wada
Soichi Masuda

TypeScript: Why and how we adopted it at Slack

  • Felix Riesebergさん(Slack)

SlackのデスクトップアプリをTSに移行した話

  • Electronを使ってる
  • JSにバグが有るとクラッシュする
  • 構造化されたコードを書かないといけない
  • JSDocでドキュメント化
  • TSのよさ
    • 型がある
    • エディタの補助がきく
  • KOAをつかったけどドキュメントを開くことなく開発できた
    • 型と補完のおかげ
  • ESLintはすばらしいがTSLintはまだそこまでいってないe
    • ESLintがTSサポート始めた
  • JavaScriptしかやったことない人は型を知らない
    • そういう人にとっては型が難しい

Introduction to Lucet

  • Adam Foltzerさん(Fastly)

Lucet

Web Assembly

  • 低レイヤーの言語
  • 高パフォーマンス
  • ブラウザで動く
    • サーバでも動く
  • ブラウザ内でも安全に動く
  • WebAssemblyに変換できる言語
    • Rust, C, C++ TS, go, swift

Terrarium

  • RustやTSでかいたWebAssemblyをアップロードできるWebサイト

Nuxt.jsで中規模サービスを統合した話

  • Koichi Sawadaさん(yahoo)
  • Hajime Sasanumaさん(yahoo)

ebook japan

  • ebook japan + yahooブックストア
  • 開発期間約1年
  • 電子書籍販売サービス

開発体制

  • FE -> yahoo
    • yahooの資産が利用できる
  • API + DB -> ebook
    • ebookの表船機能/データ
  • vue × Nuxt
    • vueはデザイナーが理解しやすい
    • ライブラリアップデートの手間削減
    • 初心者向けに日本語ドキュメント
    • Reactは(当時)ライセンスの問題
  • node + express

風土の違い

AtomicDesignへの挑戦

  • なぜ?
    • 新規回月なので途中導入より入れやすい
    • デザイン変更が多発が予想できたから
    • UIの一貫性を保ちたかったから
  • 苦労したこと
    • エンジニアとデザイナーの成果物が違う
    • スクラムと相性悪かった
      • 通化していく作業の優先度が低く改善が疎かに

実装上の苦労したこと

  • apiから返ってくるデータが大きい
    • 使わない情報もたくさん入って返ってくる
    • 開発機関制約の中で大は小をかねた形
    • mixinsを使ってget処理をまとめた

リリース後の改善

体制

  • 動くものを見せるとこに集中しすぎた
    • エラー処理やシステム面での改善が放置気味
  • 経験豊富なエンジニアがいない
    • フロントエンドのサポートチーム追加
    • PRのレビューや実装の相談をうける

システム(パフォーマンス改善)

  • api呼び出しフローの改善
    • Promise.allできるものはまとめる
    • 描画語でいいものは描画後に取得
  • レスポンスサイズ削減
    • apiから取得したデータを削ってからclientに返す
  • JSファイル改善

いちからデザインシステムを作ってみて学んだこと

  • Kengo Harunoさん(yahoo)

デザインシステムを作るきっかけ

  • 多くのサービス多くの関係者
    • 20サービス関係者1000人(デザイナー/エンジニア/ビジネス/業務委託)
  • デザインがサービスでばらばら
    • 一貫性確保
    • デザイン開発効率化
  • 何を作る?

デザインシステム開発(デザイン編)

デザインガイドラインの策定

  • デザインの定義
  • 抽象的なスタイル定義
  • 具体的なルール

コンポーネントのリストアップ

  • 名前をつけていく(時間かかった)
  • 汎用的過ぎて名前むずい
  • 業務固有すぎてしっくりこない
  • 見た目にとらわれずどんな役割をもっているかを考えて選ぶ
  • 全員が納得するものにした(納得しない=適切でない)

スタイルガイドの制作

  • sketchでデザイン作成
    • あらゆるケースや状態を考慮しないといけないので大変だった
    • 種類×サイズ×状態分作る
  • デザインルールをドキュメント化
    • デザインルールを文字化するの難しい
    • 不明瞭な部分が残らないように
  • レビューは全員(4人)がOK出すまでやる
    • 共通認識を担保

デザインシステム開発(フロントエンド編)

コンポーネントライブラリの提供方法

  • 最初はhtml/css/jsでの提供
  • コーディング設計
    • BEM記法
  • Fractal
    • スタイルガイドジェネレーター
    • markdownで書ける
    • Handlebars + yaml
    • 静的サイトとして出力できる

方向転換

  • Reactを使ったプロジェクトが多い
  • Reactコンポーネントとして提供してほしいという要望
  • html/cssでの提供ではは活用しづらい

Reactでコンポーネントライブラリ

  • Storybookベースのものに変更
  • CSS Modules with Sass
  • TS
    • 有識者はいなかった
    • 性的チェックでエラー気づきやすい
    • エディタ補完便利
    • 型でデザインをより厳格化できる
  • スタイルガイドをGatsbyで静的ページとして作った

振り返って

  • デザインから実装までこなすのはとても大変だった
  • デザインシステムは巨大なプロダクト
  • 使う人とのコミュニケーションが大事

BFFのDeveloper Experience

  • Yosuke Kuramiさん(FOLIO)

BFF

  • Backends for Frontends
  • UX視点
    • パフォーマンス
    • UIに必要十分なAPI
    • 統一したUI
  • マイクロサービス視点
    • ドメインに注力
    • シンプルで再利用性の高いAPPI
    • サービスこどの技術得意製
  • これらをつなぐためにBFF

FOLIOのBFFの役割

  • API Aggregation
    • koa
  • SSR
    • react + redux

BFFのいいところ

  • バックエンドはドメインの開発に注力
  • フロントエンドはUIの要求をAPI
  • SSRで高速化
  • => ただしフロントの仕事は増える

BFFを効率的に開発するために

バックエンドを待たない

  • IDL driven development
  • Interface Definition Language
  • FOLIOではThrift
  • IDLからコードを生成

サービスの仮データ

  • 開発中のAPIはモックに差し替えたい
  • 開発済みならテスト環境につなぎたい
  • BFFのコードはどちらにつないでも変わらないようにしたい
  • Direct Proxy

Developer向けの機能

  • BFFはフロントエンドがいじるので開発者用のAPI作ってUIを作ることもできる
  • stateを変える画面作って画面のバリエーションを試せたり

世界中誰もが使えるサービスを目指して、Web標準で作るガラケーサイト

proxx.app

今の時代のガラケー

  • スマートフィーチャーフォンのこと
  • 機能
    • KaiOS
    • モダンブラウザ搭載
  • アフリカ、インド、インネシアではやってる
    • 安いから
  • 画面小さい、タッチスクリーンない、十字キー
  • キャリアがアプリを握っているからWebで提供するようにした方がいい

ゲームを作ってみる

  • Webの強みはドキュメント
    • その正反対をやってみる
  • ユーザのインプットが多いもの
  • あらゆるデバイスをサボーとするようなもの
  • => マインスイーパー的なもの

どうやって開発したか

  • チームスペック
    • フロントエンドエンジニア3人
    • kaiOS初めて
    • WebGL初めて
  • どこまでやるか
    • 1コードベースで作る
    • a11y対応も
    • パフォーマンス第一
  • コード
    • ゲームロジック
    • Stateサービス
    • UIサービス
    • 描画処理
    • 前者2つはWebWorkerで動かす
  • FW
    • WebWorkerとのやりとりはComlink
    • preact

github

github.com

「Google I/O 2019 わいわい報告会」に参加してきました

  • Google I/O 2019 わいわい報告会に参加してきました。

mercaridev.connpass.com

  • Google I/OのセッションをKeynoteを中心に紹介していただきました。FirebaseでMLやARのデモなどさっそく試してみたくなるようなものも紹介いてもらったのでやってみたいと思います!
タイトル 発表者
現地でのGoogle I/O体験をおすすめする理由 @tenntenn
What's new in ARCore And xR Technology @ikkou
Googleの今年のキーテクノロジと背景をわかった気になるセッション @mhidaka
Firebase AutoMLのオンデバイス実行とCameraXを組み合わせた新しい価値を秒で試す @teshi04
I/O Quick Q&A タイムラインから見つけた疑問をクイック回答! @mhidaka

現地でのGoogle I/O体験をおすすめする理由

  • @tenntennさん

Google I/O

  • 3日間
  • 7000人
  • 184セッション
  • 513Office Hour

コンテンツ

  • キーノート
    • 全体向け/developer向け
  • セッション
  • Office Hour
    • Googlerに直接相談できるブース
  • App Review
    • 予約してデザインやテクニカルなレビューをしてもらえる
  • Sandbox
    • ARなど体験ブース
  • CodeLab
    • 手を動かして学ぶブース
    • ヘルプボタン押すとランプがついてGooglerがかけつけてくれる

現地でしかできないこと

  • 体験ブース
    • Sandbox
  • コミュニケーション
    • 世界各国
    • 日本から来てる普段話さない人
    • Googler

まとめ

  • いろんな国のエンジニアとコミュニケーションとれる
  • Googlerに直接質問したりFBもらえたりFBすることもできる

What's new in ARCore And xR Technology

  • @ikkouさん

AR at keynote

  • Google検索結果に3Dモデルを表示
  • GoogleLensの超進化
  • GoogleMapsのAR機能がPixelユーザに順次開放

ARCore

<model-viewer>

  • iOSのAR Quick Lookと同等のことをWebでできる
  • 1ソースでAndroid/iOS

VR

  • VRのセッションは残念ながらなかった
  • AR推しを強めてることは明らか
    • 2年前VRのカテゴリあり
    • 去年VR/ARのカテゴリあり
    • 今年ARのカテゴリあり

Googleの今年のキーテクノロジと背景をわかった気になるセッション

  • @mhidakaさん

Google I/O 2019のテーマ

  • AI for everyone

検索

  • 検索結果をARで現実空間に出す

プライバシー&セキュリティ

  • AndroidQのセキュリティの強化
  • 検索履歴の管理
  • Degital Wellbeing
  • Parental Control

オンデバイス技術

  • 機会学習をスマホの中で実行する
  • ネットワークを通さないので高速
  • MLKitの翻訳機能70言語が数百KBしかない
  • 分散学習
  • LiveCaptionのデモ
    • ネットワーク介さずに動画のキャプションを表示

GoogleLens

  • 現実空間を検索できる
    • カメラで撮影したものを検索

Duplex on the web

  • Webフォームを自動で入力してくれる
    • Gmailの注文履歴をもとに
    • ユーザは音声で指示するだけ
  • AIが前後のコンテキストを理解している
  • プライバシーの問題は課題
  • まだ公開されてない機能

まとめ

  • ML関連のセッションが増えた
  • Android関連が減った
  • モバイル上でMLというながれ

Firebase AutoMLのオンデバイス実行とCameraXを組み合わせた新しい価値を秒で試す

  • @teshi04さん

Androidのカメラ

  • いろんな端末がある
  • CameraAPIは複雑
  • google/cameraview便利

CameraX

  • Camera機能をラップしたもので使いやすい
  • 基本的なユースケースで使いやすい
    • preview
    • image analysis
    • image capture
  • CameraX Test Labであらゆるデバイスでテスト済み

ML Kit for Firebase

  • Firebase上でトレーニングできる
  • ステップ
    • データ(画像)をアップロード
    • 自動でラベル付け
    • レーニン

まとめ

  • CameraXでカメラが扱いやすくなった
  • Firebase AutoMLでAIアプリが身近になった

「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をつけて使う