radioc@?

レディオキャットハテナ

【勉強会メモ】フロントエンジニア♡最前線Night

kansai-venture.connpass.com

f:id:radiocat:20171216115638p:plain:w600

フロントエンドに関する、UI設計、AMPとPWA、自社プロダクトの改善の話の3本立てだった。

せっかく遅刻せず参加したのに1本目のメモの途中でVimが異常終了してしまったので1本目は思い出してまとめた内容になります。あと、RoRはあまり詳しくないので若干省略気味。詳細は資料をご参照ください。

オブジェクト指向UIで立ち向かう

株式会社Goodpatch DesignDiv フロントエンドエンジニア 大角 将輝氏

2種類のUI

  • タスクベース:CUI
    • 動詞⇒名詞
    • アクション中心
  • オブジェクトベース:GUI
    • 名詞⇒動詞
    • オブジェクト中心

オブジェクトベースのUI設計

  • オブジェクト⇒ユーザーの関心事
    • オブジェクトは変わりにくい(アクションは変わりやすい)
    • オブジェクトが持つ属性を定義する
    • 属性に対する共通のアクションを定義する
  • データと表示要素が自然に対応する⇒フロントエンドとバックエンドの関係がシンプルになる
  • オブジェクトベースで設計すると機能の重複が少ない

あとで色々ググってみると以下の情報が参考になりそう。プレゼン資料の中でもこのサイトの内容が一部紹介されていた。

www.sociomedia.co.jp

AMPとPWAについて

クックビズ株式会社 フロントエンドエンジニア 高田 洋祐氏

AMPの特徴

※会場アンケート:APMを自社で導入⇒1/4ぐらい

AMPの導入状況

3つのコアとなる早くなる要素

  • AMP HTML…独自記法
  • AMP Component…豊富なコンポーネント
    • AMPはJSが使えない
    • AMP Example
    • <amp-list> <amp-bind> <amp-google-vrview-image> など
  • カスタマイズ機能と柔軟性

AMPを使えばGoogleが持っているサーバにキャッシュしてくれる

クックビズのAMPへの取り組み

  • LPのAMP版を作成してコンテストで優勝
    • 通常のサイトと全く同じ
    • ページ表示:60%
    • CVR:40%

釣り目的のAMPページを駆逐

  • ページの冒頭だけAMPで 続きを見る で通常サイト
    • 2018年2月からはAMPページとして扱われない

ascii.jp

フロントエンドエンジニアは忙しい

  • 1999年⇒HTMLとCSSで完成
  • 2017年⇒Babelでトランスパイル、Webpack、ジェネレータなどなど
  • 2017年のAPM⇒HTML,CSSで完成

PWA

  • PWAはマーケティング用語
  • ネットワークの遅い新興国で期待

  • フルスクリーンで起動

  • PWAはアプリとして起動
  • Webプッシュも実装

初回アクセスはAMP、2回目以降のアクセスはPWAという設計⇒PWAMP

このあたりは個人的に以前Qiitaにまとめた内容と同じ。

qiita.com

音声検索

※会場アンケート

  • 音声検索を使っている…少ない
  • スマートスピーカー…たくさん

音声検索

  • 2020年までに50%
  • 音声検索により検索のクエリ数は増える

強調スニペット

digitalidentity.co.jp

コンテンツの中身・意味を明確にする

  • 適切なタグを使用
  • きれいなアウトライン
  • 構造化

成長中のプロダクトでフロントエンド環境改善を進める話

スピーカー:freee株式会社 アプリケーションエンジニア 加藤 慧氏

speakerdeck.com

2015年ごろからのSprocketsまわりの改善について

qiita.com

Sprockets

課題

  • concat≠依存性の定義
    • requireディレクティブをつかったconcat⇒読み込む順番を人間の努力でカバーしないといけない
  • Gemライブラリのロード⇒Gem化されたものしか読み込めない

⇒Sprocektsディレクティブの排除

成果

  • Sprocketsディレクトリを部分的にCommonJSに書き換えてBabelでトランスパイル
  • Gemではなくnpmを利用
  • ESLint利用
  • flowによる型チェック導入

残る課題

  • Sprocketsディレクトリの糖衣構文としてのCommonJS導入にとどまり
  • gulpによるビルドタスクの複雑性

総括

  • 課題は解決できたが新たに課題が生じた
  • ツールは刷新できたが依存管理アーキテクチャのリファクタが伴わなかった

革命の火ふたたび

  • Sprocketsやめてwebpackに⇒変更が膨大すぎて失敗
  • 暴力革命から平和革命へ
    • レビュー可能な変更
    • 小さなコンテキストで大きな横断的変更を作る
    • 物量が多いのは避けられない

正しそうな変更

  • 静的解析を仕掛ける
  • 機械的・法則的に変更
  • 人為ミスが入らないようにする

再現可能な変更

  • そうこうしている間にもプロダクトは成長を続ける
  • conflictする前提でもう一度すぐに変更を再現できるようにする

残る課題

  • Sprocketsのディレクティブだけ残る

GemのCommonJS化

  • 枯れているライブラリなら自プロダクトに取り込んで改変する割り切りが可能

残る課題

  • gulpの複雑さ

ビルドタスク分解

  • CLIで充分
  • ESLint
  • Webpack
  • Sassも node-sassCLI

Webpacker

  • Sprocketsディレクティブのようなロックインリスクが少ない
  • フロントエンドとサーバの歩み寄りのラインが重要

次なる課題

  • 継続的な防御
    • 未使用モジュールの検知…webpack-unused
    • 未到達コード検知…EsLint no-unreachableルール
    • 静的解析をCI連携
  • 参照アプリケーション・アーキテクチャ定義
    • 解釈の自由度が高いFluxアーキテクチャ
    • ベストプラクティスに寄り添う
    • Redux
      • Flux Standard Action
    • 窮屈感?
      • 10日に1回のHack dayで技術課題に打ち込む