Inside Frontend行ってきた #insideFE

先週土曜日にInside Frontend行ってきたのでレポート。

Inside Frontend

inside-frontend.com

CyberとYahooの共同主催のフロントエンドのイベント。

国内だとHTML5 Conferenceに次ぐくらいの大きさかな？？

会場はAbema Towers。

行く途中で中本でラーメン食べたから、イベント中腹壊したらどうしようと思っていたが杞憂で終わってよかった・・・

TypeScript: Why and how we adopted it at Slack

  • SlackをTypeScriptで作り直した話
  • Reactも導入しているっぽい
  • 2017年4月ごろっぽい
  • JSはVanila JSで書くのが好きで、ライブラリとか入れない予定だったけどTSで書いたらTS最高だった
  • Battle Field 1のUIはReactとTSで作っているらしい
  • 他にもNvidia,Adobe,Skype,Visual Studio InstallerとかもJS(Electronっぽい)
  • C++で書かれたnode.jsモジュールがある
  • JSDoc書いていたけどメンテされないし、Objectで渡ってきたら中身わからないし・・・
  • そこでTS、TS書いても既存のJS破壊しない（JSにコンパイルされるから）
  • エディターがTSを強力にサポートしている
  • JSは実行するまでエラーに気づけない（コンパイラを求めていた
  • Coffeeは使ったことない
  • TSは実行せずともエディターがエラーを出してくれる
  • 最初は.jsを.tsにかえるだけでOK
  • デモでJSをTSにして、コンパイルしたJSを見せる
  • 少しずつTSに移行していった
  • TS書いていたらVanila JSが汚く見えてきた
  • TSで型が定義されるのでメソッドのサジェストが助かった
  • koa使うときほとんどドキュメント見なかった
  • 当時TSLintにはお世話になった
  • 今はESLintのほうがいい
  • 想定より早く移行が終わった

そもそもSlackってElectronで作られているのが初耳だった

TS最高だぞという話。結構エディターのサポートが強力という話が多かった気がする。

Introduction to Lucet

前提のwasmの知識がなくかなり難しかった

途中からコンパイルの仕組みとかの話でかなり難しかった・・・

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

www.slideshare.net

  • 無料まんが・試し読みが豊富！eBookJapan｜まんが（漫画）・電子書籍をお得に買うなら、無料で読むならeBookJapan
  • フロントはYahoo
  • バックはEBJI
  • Yahooのデザイナーはマークアップまでできる
  • Vue.js,Nuxt.js,Node.js,Express
  • 他社で分担しているので風土が違う
  • Yahooは属人化をさけるが制約が多い
  • EBJIはスピードが速く自由度が高いが属人化しがち
  • そこでスクラムを導入し吸収した
  • 1週間スプリント
  • 部署や役割ごちゃ混ぜでAとBチームを作った
  • Atomic Designを導入
    • デザイナーがHTML,CSSをエンジニアにわたす
    • エンジニアはAtomicデザイン通りのVueファイルを作る
    • エンジニアとデザイナーで溝ができた（アトミックデザインの共有とか）
  • デザイナーはAtomic Designの共有を受けていなかった
  • 最初からデザイナーに共有をしてデザイナーがAtmoic Design通りにVueファイルを作る流れのほうが良かった
  • 大は小をかねるので大量の項目を返すAPIを作っていた
  • でかすぎるのでmixinで絞る処理を書いた
  • Vueファイル以外で使ってバグった
  • 直列でAPI叩いていたからタイムアウトしていた
  • 目に見えるものをスクラムで作りまくっていたので目に見えない処理とかが後手後手だった
  • 比較的若いエンジニアが多かった
  • 名古屋チーム（一人）を作った
  • スクラムは機能追加
  • 名古屋チームは、スクラムに入らずFEのサポート、レビュー、相談、パフォーマンス改善
  • FEエンジニアで会話する場を作る
  • 新しいこと、実装時の課題を拾う（スクラムで拾えないのを拾う
  • 直列でAPIを呼んでいたところをリファクタリング
  • APIを小さくした
  • webpack bundle analyzerでJSを削る
    • 7MBくらいあった
  • 名古屋チームもスクラムに混ぜた
  • 7割機能追加、3割改善
  • Q APIのドキュメント方法
    • A エクセル、swaggerなどAPIによって違う（辛い
  • GrapshQLは検討中
  • NuxtにしたのはSSRしたいのとwebpackメンテが嫌だった
  • 1週間スプリントは実装の割合が減るが、仕様等がコロコロ変わるので1週間スプリントにした
  • 機能開発はJIRAで管理、改善系はGitHubで管理
  • スクリュードライバーというCIでデプロイ
  • UnitTestは書いてあるが、e2eはない
  • 2つのチームは同じPO

Nuxt.jsがメインと言うよりは、チーム作りや開発体制などの話がメインだった。

違う会社を同じスクラムに混ぜて開発するのめっちゃ大変だったんだろうなという印象。

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

speakerdeck.com

  • Yahooの広告配信管理ツールのデザインシステムを作った話
  • 20社以上1000人が関わる
  • それぞれ独自に作るのでばらばらになってしまう
  • デザイナー4人で開発
  • スタイルガイド
    • 原則定義
    • 色とかの定義
    • モーションの定義
  • デザインキット、コンポーネントライブラリ
  • コンポーネントを洗い出して名前をつけた
  • 名前付けは時間がかかった
  • Card?Panel?Plate?
  • シンプルが故に難しい
  • サービス特有の謎パーツも難しい
  • 見た目ではなく機能・役割を考えて言葉を選ぶ
  • 全員が納得するまで議論
  • Sketch使ってAbstract?でレビュー
  • 全員の承認が必要
  • エンジニアがレビューに入っていたから実装目線でも会話ができてよかった
    • ホバー
    • エラー
    • 入力量
  • HTML,CSS,JSスニペット提供(BEM記法
  • Fractal(スタイルガイドジェネレーター
  • 作ったはいいがReactのコンポーネントで提供してほしいと言われた
  • npmで提供できるようにした
  • TSは有識者いなかったが導入した
  • Storybook
  • sassの型解決できずなやんだ（typings-for-css-modules-loaderで解決
  • スタイルガイドはGatsbyで作って、自動的に同期して更新漏れが発生しないようにした

作ったあとにReactコンポーネントで書き直すのはなかなかつらみがあるな・・・

Web Componentsもこんな感じで配布したい

BFFのDeveloper Experience

speakerdeck.com

  • Backends For Frontend
  • 全然詳しくない
  • BFFはUXのためにある
  • Micro ServiceとUXをつなぐ
  • MSはドメイン注力、シンプルなAPI、サービスごとに技術最適
  • API Aggregation(node.js/koa)
  • SSR(React, Redux)
  • バックエンドはドメインごとの開発に注力
  • フロントはUI要求をAPI化
  • フロントの仕事が増えている・・・
  • そこでBFFをサクサク開発する必要がある
  • APIのインターフェイスの合意をバックエンドとフロントエンドで取る必要がある
  • Interface Definition Language　e.g. Swagger
  • Thriftを採用
  • 並行開発をよりよくする
  • モックデータを作る
  • Cross cutting concern（関心ごとの分離
  • マイクロサービスのモックデータは横断として考える
  • インターセプターする
  • Aspect Oriented Programming
  • Dev用の画面もBFFで作る（デバッグにつかう
  • フロント複雑になっているからエンジニアリングで解決していこうな

BFFは単語だけ知っていたので興味本位で聞いていた

手を動かしてみないと実際のところはわからないが・・・

フロントエンドの仕事が増えてきたのは同意

node.jsの存在がフロントエンドの垣根を壊しているイメージ

Loading Performanceとの向き合い方

speakerdeck.com

  • 日経電子版は7月に2度目のリニューアルをする
  • LightHouse100点だけどユーザーの状況によっては低くなる（速度制限とか
  • 広告のスクリプトが速度低下の原因
  • 簡単に導入でき、確実に表示され、正確に計測ができるが
  • document.write...
  • 自由度がない
  • 外せないので最適化をする
  • minifyされたコードを読みデバッガーで頑張る
  • スクリプトを読み込む処理を探し、スクリプトをダウンロード、呼び出しを潰して、連結してminifyしFastlyで配信
  • onScrollも上書きしてintersectoin obseverにする
  • UIの表示以外はWebWorkerに任せる
  • comlinkを利用
  • どこかで失敗したら従来どおりの読み込みをする
  • 最適化もレベルを分けて実施して、効果を図る
  • handlebarsからJSX
  • vanila jsはそのまま
  • 通常のSSRサイトなのでReactとかいらなかった
  • Web Components使う
  • 泥臭いの作業は業務後にやっている
  • Edge,IE11はスルー
  • lit-elementは使わない
  • なお、リニューアルは天の声が・・・

広告最適化の泥臭さやばい

広告のJSはドキュメントがほしいと言っていた

それにしてもリニューアルでWebComponents使うの楽しそう・・・

懇親会

寿司！ビール！ピザ！

終わり

node.jsが存在するおかげで、フロントエンドもサーバーサイド書くっしょみたいな風潮がより強くなってきた気がする

個人的にはWeb Componentsが好きだからデザインシステムとかもWeb Componetsとかどうだろうとか思いながら聞いていた

実はCall For Proposalで2つほど申し込んだけど残念ながら、落選していた(・∀・)

次回こそ・・・