valid,invalid

関心を持てる事柄について

Front Line of Frontend − Forkwell Meetup #2

イベント

Forkwell 社主催の Front Line of Frontend − Forkwell Meetup #2 に参加した。

web フロントエンドが広域化していく中で"フロントエンド"という言葉に複数の意味が混在しているのがややこしい、というような雑談を前に banyan さんとした。曰く、主に2つの役割がある。

  1. HTML (含 テンプレートエンジン) や CSS (含 SCSS etc.) を中心としたマークアップを得意とするエンジニア (クライアントサイドのデザイン担当)
  2. jQuery に始まり Angular, Backbone, React など一連の JavaScript フレームワーク、エコシステム、ビルド環境などに精通したエンジニア (クライアントサイドのロジック担当)

自分はフロントエンドも多少触るが業務内容はほぼ後者なので、前者に寄った内容が多かった今回のイベントは結構新鮮で面白かった。

特に CSS の複雑さの解消方法やテスト手法、またはデザイン手法周り。これらは Quipper では designer と web engineer の隙間で埋まりきっていないところなのでまだ改善の余地がありそう。

懇親会では以前に Quipper の Meetup に来てくださった方と再会したりした。

メモ

発表を聞きながら取ったメモ。

トーク① 「スタイルシートの長い夢」 GMOペパボ @shikakun

  • カラーミーショップ
  • CSS の複雑さ 優先度を決める
    • ID, class, 重複, selector の合計, !important, reset
  • 普通に書いていれば !important は要らない。class セレクタをちゃんと使う
  • CSS にスコープがない、グローバルに定義しすぎている
    • 2万行の common.css

戦い方

  • global をリセットする reset_common.css を読み込む
  • BEM MindBEMding 名前の規約によって部品がわかる
  • frocss

CSS は何故増える？

  • 消せないから
    • 消したときの影響がわからない
    • 消せなくてもエラーが出ない

  • 2週間延々と消す期間を設けて一個一個消していった

  • Enduring CSS 消せる CSS にする

    • ページと対応するディレクトリを切ることで scope がわかる

整理するために

  • スタイルシートの先頭にドキュメント書いてパースしたり
  • sample page を作る

  • hologram / pepagram

  • gulp で vendor prefix は auto でつける

  • stylelint

  • ...というのは全て夢で、まだ何も手を付けてない

  • CSS Architecture は3年前に提唱されている

トーク② 「フロントエンド最前線に流されないAtomic Designという考え方」 サイバーエージェント @79yuuki

  • 最近複雑化しすぎているフロントエンド
  • まずウェブ標準に立ち返ってみよう、HTML, CSS, JS
  • W3C による Web Components
    • まだ実用的じゃない
    • Google が攻めてる Polymer もあるが実装が複雑
  • Bootstrap -> Material Design -> Atomic Design

Atomic Design

  • style guide に atom / molecules の一覧を作る
  • codepen みたいに見た目を確認しながら作れるようにしている

やるべき理由

  • スコープが良い
  • 仕事がし易い

  • これは Web の話ではなくデザインのスタンダードになる話

    • ツールを選ばない

  • Riot.js は良い

    • HTML ぽく実装できるので Web Components を体験できる
    • マークアップはわかるけど JS はちょっと…という人にオススメ

  • 色んなフレームワークが Web Components の考え方を採用してきている

トーク③「ビジュアルCSSテスティング（仮）」 Forkwell @ringogirl

  • forkwell は5年続いているサービス、それなりに CSS の負債ある

戦い方

  • スタイルガイドを作っている http://styleguide.forkwell.com/

    • 機能とべったりなコードを防ぐためにアプリから切り離す
    • npm で管理

  • が、テストがない、見た目もテストしたい

    • 目視確認
      • 画面の状態が多い意図分岐の確認に時間がかかる
      • 再現性
    • E2E
      • 画面の崩れを完璧には防げない

visual css testing

今は Eyecatch

  • スタイルガイドのコンポーネントごとに Eyecatch でテストができる
    • JS を動かしてのテストもできる（React component に対してもできる）
  • 自前でスクショ撮る機能を作らなくてよい

  • 共通レイアウト部分に変更があるとまとめてくれる（ロゴとか）

  • ただしブラウザの種類が一つなので、クロスブラウザテストしたかったら BrowserStack が必要

  • まだ beta、これからどうなるかわからない

課題

  • アプリ側で入れたい
  • ランダムなデータだと差分が結構出てしまうのでテストデータ整備が必要

まとめ

  • CSS のテストはむずかしいがそれなりにツールが有る
  • 使っていきましょう

トーク④「Web ブラウザで DRM」 サイバーエージェント @ygoto3_

プロフェッショナルなコンテンツとは

  • それで生計を立てないといけない
  • 映画のウィンドウコントロール
    • 劇場公開 -> DVD -> BS/CS -> 地上波 (インターネットもココに入っていく)
  • コンテンツ保護しないといけない

コンテンツ保護

  • 保護のランクがある
    • ノーガード
    • ユーザー認証 コンテンツを配布するような悪意あるユーザーは防げない
    • コンテンツ暗号化 コンテンツを配布されても閲覧不可
    • DRM　(Degital Rights Management)
      • ハリウッドからはより厳しい管理要望がある
      • 手法は幾つかある

web でできる DRM

できること

  • コピーは出来るが特定な環境に制限
  • 有効期限を設ける

仕組み

  • エンコードする時にライセンスサーバーと協同してパッケージングする
  • CDN に置く
  • クライアントがダウンロードする

  • クライアントは再生できない、ライセンスサーバに問い合わせ、OKなユーザーなら初めて鍵を渡して閲覧できるようにする

  • ただし web ブラウザごとに異なる鍵システム

  • 動画の数と組み合わせて膨大な量になってしまう

Common Encryption

  • Encrypted Media Extentsions ... HTMLMediaElement を拡張してコンテンツを保護する JavaScript API。

  • Content Decryption Module ... 複合アルゴリズム。複数のブラウザで共通化された API を利用できる

  • どんな暗号もいつか破られるので、暗号を差し替えることができるようにする

  • ブラウザはコンテンツのメタデータから暗号化されていることを知る

LT フロントエンド開発のチームビルディング

  • 結論、エンジニア同士がディスカッションする機会を増やす
  • 他社の考え方やナレッジを取り込める
  • 習慣的にやることで自律的なチームになる
  • マネージャーは具体的な How to を提示するんじゃなくてチームが自立成長するために仕掛ける
  • トップダウンで完全にコントロールするのでもある程度は回るだろうが、スケールしない
    • 経験上7人が限界

Phenonic

  • https://phenomic.io/
  • static website generator
  • template / contents -> compile build -> website
  • React / Webpacck が使われている
    • issue / pull request 見ていても参考になる

UX プロジェクトファシリテーション

  • UX プランナー おかいもの研究室
  • 消費者行動の調査、発表、セミナー

  • ユーザテストのない UX は UX ではない

    • どんなによく考えられたデザインもユーザに届くまでは仮説にすぎない

  • ユーザーテストはプロジェクト共感ツール

  • ユーザーテストはには可能性がある、UX プロジェクトファシリテーションはその一手法

トーク⑤ 「フロントエンドのパラダイムシフトとプロダクトの成長」freee @joe_re

  • 2012 -> 2016
    • bower -> npm, coffee -> esnext, backbone -> react / redux

  • sprockets 捨てるか

    • webpack などのアセットバンドラーで何とかなる
    • require は js を concat してくれるだけなので順番守らないといけないのはいけてない
    • 使い続けてはモジュール化された ESNext の世界に到達できない

  • 今はビルド結果を app/assets に出力して最終的には Sprockets を通している

    • 既存のデプロイフローは変えなくても良い

  • 捨てるには

    • Rails に依存しているビルドを取り除く
    • webpack でフィンガープリント

課題

振り返り

  • 2012年から Backbone、SPA ではなかった
  • 給与計算 freee は Vue.js と使用した完全 SPA としてローンチ
  • とはいえ VM 、状態管理は辛いし、Object.observe も死にました

React

  • 既存実装 (Backbone.js) があるところに導入するのはつらい
  • 初めは共存させたが、途切れ途切れの view、single store はどこに置く

  • flux-utils を使った

    • 既存の flux から乖離せずに済んだ

  • redux でないのは当時使用例が少なくてスケールしていくかわからなかった

天秤

  • プロダクトの置かれている問題を果たして解決するのか？を考える

人類共通コンポーネント

  • 複数プロダクトを抱えているのでそれらの間でコンポーネントを再利用していきたい
  • 再利用する上で
    • トランスパイルに必要なツールのバージョンは要求しない
    • スタイルは再利用したい
  • CSS Loader でスタイルもコンポーネント化していく
    • そのために DOM に規約を持たせる

開発体制

  • 60人のエンジニア
  • web エンジニアはフロント・サーバサイド両方やる

パネルディスカッション − Front Line of Frontend − freee @ymrl, Goodpatch @yoshiko_pg

どのフロントエンドの人？

  • ymrl: API からこっち側いろいろやる。欲しい JSON を作って UI 作り、CSS も書く。チームは5人で1サービスを担当している。フロントエンドだけ、だと狭すぎる
  • yoshiko: CSS も書いてるが業務だとほぼ JS の人。prott チームはエンジニア10人、biz 含めて30人

最前線での戦い方

技術の選定基準

  • ymrl: あまりはっきりしていない。過去にはっきりあったのは"辛くなったから"。それ以外は突然カッとなって入れたらり。この前は immutable.js しれッと入れた。事前に根回し的なことをやっても結構反対はあるので自分で面倒見る気持ちで（辛くなったら外す、入れるのは自分で外すのも自分）。
  • yoshiko: 情報量、エコシステム、チームのスキル。あと web 標準に沿っているか？も最近考える。CoffeeScript を使っていたが ES2016 のビルド環境を整えて、新機能はそちらで書くようにした。

レガシーからの移行

  • ymrl: ライブラリとかコードの負債についてはなるべく影響の範囲を小さくできないか考えつつ。SPA は一度やるとやめるのが大変になる。コツコツやって一周したら最初のところが古くなる。メジャーバージョンアップやフレームワークレベルのでかい改修はガーッとやるしかない。祭り。レビューは大変なので機能AはAさん、BはBさんが見るというチェックリストを作って見てもらう。
  • yoshiko: ガッと置き換えて動かないところは直していた。ES への置き換えは ES Lint 使いつつ。

反対意見があったらどうする？

  • ymrl: 反対意見というか、よくわからないので特に意見ない、というのが多い。過激派が声張って主張していくことでチーム内に空気ができていく。
  • yoshiko: うちはあんまり反対意見なくて好きにやらせてくれる環境。元々はいちいち許可を取っていたが、その権限を移譲されてテックリードになった。

最前線の一歩先

次に注目していく技術など

  • ymrl: 標準は見ていく。型、flowtype は入れたりしている。自分で各コードにはアノテーション付けている。同じメソッドなのに違う型返すみたいな事故を防げる。皆がちゃんとやるようになるまでは継続的に見ていく、型警察ほどではないがレビューでチラッと書いてほしいと言ってみたり。
  • yoshiko: プロットの目線で言うと service worker でオフラインでも色々動くようにしたい。モバイルのプログレッシブなどもあるが、PC がサービスにマッチするので入れてみたい。electron など、web を持っていく話もあるが、デバッグが難しいので辛そう。

10年後のフロントエンド

  • 人間が接するところ全てがフロントエンドなので色々追いかけるか。端末の多様化。それに伴う API の追加