Inside Frontend
大手町日経カンファレンスルームで開催されたINSIDE FRONTENDというカンファレンスに参加してきました。
2回めの開催ということですが、僕は今回が初めての参加でした。
AMAルームでinsideFrontend開幕です♪( ´▽｀)🎉#insideFE pic.twitter.com/iOPMlM7sMY
— Inside Frontend (@insidefrontend) 2018年2月11日
どういうカンファレンスだったか
「Web フロントエンドの現場とこれからをつなぐカンファレンス」ということで、主なスポンサーのCyber Agentさん、日本経済新聞社さん、YAHOO!さんを中心に各現場でのノウハウがたくさん聞けました。
このカンファレンスでは、一般的な講演形式の「セミナー」と、質疑応答形式の「AMA（Ask Me Anything）」が並行しており、AMAではみなさんが普段どのような悩みを持っておられるのか、どのへんに引っかかりポイントがあるのかが、よりわかって良かったです。
やり取りのログは、運営の方がいかにまとめてくださっています！すごいです。
GitHub - insidefrontend/issue2-ama: AMA ブースで聞いてみたい質問をこの Repo の Issue として Submit ください（どなたでも！）
また、当日のセッションのビデオもFRESH!さんにアーカイブされています。（生放送もされていました。）
このエントリでは、僕が参加したセッションをベースに感想を書いていきます。
カンファレンス中に書いたメモもこちらに残しますが、あくまでメモなので、上記のビデオや、公開されている資料、AMAは上記のgithubにまとまっているので時間がある方はそちらを参照される方が良いと思います。
実際に参加して現場感を感じたり、知り合いと会ったり、質問したりというのが良いですが、すべてログに残っているのは素晴らしいです！
セッションの感想
以下感想です。
freeeのアクセシビリティ、いまとこれから - @magi1125 (AMA含む)
docs.google.com Issues · insidefrontend/issue2-ama · GitHub
freeeにおけるアクセシビリティの意識を上げていくときの取り組みの紹介と現状、これからの方向性についての紹介でした。
アクセシビリティチェックリストの紹介や実際にどのようにコードに落としていくかなど技術的な話もありましたが、僕はかなりエモい話だったなと感じました。
正直、アクセシビリティを意識してのプロダクト開発というのをそこまで意識していなかったので、新鮮に聞くことができました。
アクセシビリティというものを、デザインの問題、凝ったアニメーション、などそういったもので 間違って認識していたので改めました。（じゃあアクセシビリティが何なのか、というのは僕の言葉ではうまく説明できる気がしないので、資料を参照ください。）
作るサービスによってアクセシビリティが重要視されるかどうか、必要性が議論されるべきというのは、僕も感じることがありました。
例えば担当している法人向けの管理画面などは、定常運用をいかに効率化するか、間違いがなく運用できるようにするか、などが重要視される、といったような違いがあげられるかと思います。
現場の ES201x とアーキテクチャの変遷と未来 - @mizchi (AMA含む)
speakerdeck.com Issues · insidefrontend/issue2-ama · GitHub
題名通り、フロントエンドのこれまでのアーキテクチャ変遷から、未来を予測すると言った話でmizchiさん節がすごかったです。
僕は現在プロダクションコードとして存在するレベルのjQueryしか知りませんが、ざっくりとこれまでのことを理解できましたし、現状のフロントエンドのライブラリ、フレームワークを大枠で捉えたときにEventとStateとViewを完全に分離するというのは、そうですよねと思って聞けました。
WebComponentsの話や、今のWeb標準とPWAの関係*1などについてもお話されていました。
とはいえ、一番面白かったのはじゃあどうやって現状のものをきれいにするのか、というところでした。
まずやるべきこととしてprettierを入れたり、lintを入れたり、型をつける作業をしたりとかなり泥臭いところからやっていくということで、フリーランスでいろいろな現場を見られているかたがそのように段取りを提示してくださるのは良いなと思いました。
コンポーネントTDDの実践から見えたもの - @pirosikick
www.slideshare.net
ReactとVueにおいてコンポーネントを作成するときにTDDを導入する話。
TDDとは関係のないコンポーネントのテストを書くときのハマりどころから、TDDを導入する際の注意点と、今後の改善点を説明してくださっていました。
TDDについてはTDD本を読んでいたので、目的や良さなど理解できていたように感じました。
コンポーネントのテストということで、デザイン変更のたびに頻繁に変わりうるUIのテストをどこまで書くのかという議論があるのではないかと思っていたのですが、セッションを聞いていてTDDでやるとコンポーネントのテストを見た目とふるまいを分離して書けるのかもしれないなと思いました。
セッション中に紹介されていた以下の資料も参考になりそうでした。
動的デザインガイドのつくり方 - @narirou
モノリシックなフロントエンドのアプリケーションをデザインガイドラインを適用するための開発プロセスと、各ステークホルダーとの調整方法をまとめて話してくださっていました。
Design Systemという概念やそれが具体的にどういうものだったのかということはいまいち理解しきれなかったのが残念だったのでもう少し他の資料も当たってみたいと思います。
Micro-benchmarking is Hard - @saneyuki
開発中にベンチマークを取る際ときに、しっかりと意味のあるベンチマークを取らないと根拠のない数字から可読性の低いコードを生産してしまう可能性があるよ、という話でした 。
具体的には、
大きな（マクロな）機能のベンチマークを取る場合はその機能の使われ方内部の実装をしっかりと理解しなければならないために難しく、
じゃあちいさな（マイクロな）機能のベンチマークはどうなのかというと、利用しているJavaScriptエンジン（今回はフロントエンドの話なので）の最適化の実装によって期待しているような結果が得られない可能性があるので難しいということでした。
結局、エンジンの内部実装を理解して最適化されにくいようにベンチマーキングするのか、ベンチマークする単位をある程度複雑にして最適化されにくくするのかというような結論だったのではないかと思います。
ふわっと思います、と書いたのは、このセッションが僕にはかなり難しかったからです。
もう少しJavaScriptに詳しくなってから、資料を読み返したいと思います。
まとめ
かなり遅くなりましたが、Inside Frontend #2の感想記事を書きました。
現在、業務にてStorybookの導入を勧めているため、今回のInside Frontend#2ではUIコンポーネントのデザインや設計についてのセッションを多く聞きました。
アクセシビリティやベンチマークなどは初めての話が多く、興味を惹かれたので、優先度付けて深ぼれたらなと思いました。
メモ
基本、聞きながら書いたものなのでまとまりはありません。あくまで私的メモとして。
お時間ある人は、公開されている資料やビデオを見られることをおすすめします。
freeeのアクセシビリティ、いまとこれから - @magi1125
https://docs.google.com/presentation/d/1D2DP0aP4l5N3MKNtt-LbfLeAEexkXYs4snC8vmzur3o/edit
セッション
- 情報設計、UXデザインのお話
- 「UX = できたらやること」？
- => アクセシビリティがビジネスに貢献するには？
freee * アクセシビリティ どんな仕事にも必要、テキストベース、手堅いUI、Webが主戦場
成熟度モデル
- 認識していない
- 関心がある <-いまここ
- 投資している
- 全力で取り組んでいる
- 没頭している
- 根付いている
1=>2にどうなったのか？
一人から始めるWebアクセシビリティ => あとで見れる
自分ごとにしやすい = 理解しやすい
アクセシビリティと連想してもらう
- VoiceOverが有用なことを飲み会で体験してもらう
- 音声入力 => IFTTTの仕組み紹介
- 画像認識 => 自動入力
多数のサイトとアプリ
easy check
http://code.kzakza.com/2014/02/easy-checks/
- 空のi要素？
- 画像の文字にaltがない
- エラーを読み上げない
アプリケーションのアクセシビリティ
ラベルが入力項目と紐付いていない
ボタンが押せない => 先に進めない場合あり
組み合わさると複合的に
iOS版に切り替えつつ利用しているらしい
機能が絞られている
全容を把握しやすい
20:80の法則
よく使う機能などに絞って、課題を解決したらとりあえず良くなるのでは？
既存Webアプリケーションのアクセシビリティを向上させる時によくあるやつと対応方針
https://havelog.ayumusato.com/develop/a11y/e718-a11y_atonose_sakusaku.html
- Easy Checksの和訳開始
- チェックしていく流れを作る
- 方針策定 => まず簡単なところから
既存と新規開発
新規開発
これから
既存のUI修正と向きあう
機能追加 => 因果を示しやすい
修正 => 因果を示しにくい
UXメトリクスの整備が必要
必要性に向き合う
- 目標と成果の明示
- アプリケーション特性
必要とする当事者に向きあう
JBICT
AMA
導入されやすいところは？
エンターテイメント <=> 公共事業
それでもゲームとかで設定でやってるところはあるのでそうはいっても物による
プロダクトにおけるフェーズ
目指すべきところは大規模な主要サービスをアクセシブルにすることだが、動いている小さいサービスをすべてやってしまうことによって
実際どのくらいみんながアクセシビリティを気にしているか？どういうアプローチをしてるの？
現状、成熟度モデルにおける1番のひとと2番の人が混在
アクセシビリティを気にしている人は少なからずいるので、それに着火していく作業
熱い気持ちを飲みの場で、草の根活動
freeeはアクセシビリティが重要なサービスだというロジックを組みやすい
パイを増やす
海外ではどんどんそうなる？
本当かどうかはどうでも良いから、ある程度確からしい差を示せるロジックがあれば良い
逆に、アクセシビリティはやったほうがよい、という空気になりがちだが、本当にそれをやることが会社や状況においてよいのか、というのをある種冷めた目で見る必要がある
競合他社や海外の先行事例をまとめる
- 基本的にOSやプラットフォームをどうするか
- 新規には、lintを入れたりして、コストを減らす
現場の ES201x とアーキテクチャの変遷と未来 - @mizchi (AMA含む)
セッション
https://speakerdeck.com/mizchi/real-world-es201x-and-future @mizchi
自己紹介
node.js
SPA職人
フロントエンドの消耗
いろいろな消耗
アーキテクチャの変遷を整理
変化に強い設計のための考察
少しでもできるように！
振り返り
テンプレーティング→データバインディング→flux /obserbableの時代
flashの衰退とjavascript
太古:セルフスクレイピング
手で気を書き換える
不安定なdom apiをjQueryが吸収
IE6が残る
テンプレーティングの時代
htmlの初期生成がクライアントに
二重テンプレート問題
データバインディングの時代
テンプレート→コンポーネント
文字列を展開するものから、木構造を出力ものに
効率的な部分書き換えとリスト展開
MVVMの輸入
現代
Client mvcの破綻
クライアントとサーバサイドで、必要な抽象化が違った。
概念の分解
単方向データ
EventSourceとsubscribeの形態
FRPの概念を輸入
RXの世界観
オブザーバブルをビューがサブスクライブ
reduxの世界観
mapStatetoProps
考え方
スナップショットを表示
トレンドは？
メモリ上に沢山のデータがある
ブラウザの機能をより賢くじっそう
富豪とマイクロチューニングの振り子
開発言語
- javascript
- トランスパイル
- web assembly
近年盛り上がる言語は。。
型が重要
なんで？
- guiのテスト
- データがimmutableとなっているのが前提
祈りが消えることはない
未来
ノードの末端がWebComponentsに
フレームワークが状態を持つのは変わらない。
マテリアルデザイン、フラットデザイン、bootstrapなどは死ぬ？
hogeデザインのfuga実装
未来に向けてどうするのか？
古いコードを手なずける
- lintを書く
- 型を書く
- グローバル変数を消す
- テストを書く
置き換えやすいのが重要
view とstateが分離
とりあえずやっとけ
- prettier
- no-unused-value
- preffer-const
フロントエンドエンジニアとは？
それぞれのゴール設定
- スピード？
- 継続して価値を届ける？
まとめ
- 普遍的なgui設計との合流
- 様々な思想をぶつけある戦場
AMA
web componentsはwebアプリのスタンダートになりうるか？
ie11が残る
shadow dom時代のCSS?
命名規約が必要
ES Modulesについて
npmと相性が悪い
https://www.weblio.jp/content/フォールバック
フロントエンドの給与相場
言語によってじゃない、フロントエンドエンジニアとは？
ラベルの破綻
- nodejs？
- デザイン？
マークアップと実装の乖離
統一的なrouter
universal-router
URLと状態のマッピングとヒストリー
GUI側から見ると、見た目をスタックしていく
状態のシリアライズがルーティング
web componentsとReact
web componentsはカスタムエレメントとしてReactがうけ取れるが、propsを解決しづらい
現場ではまだ厳しそう => エコシステムをまて
現在のWeb実装がPWAに変わっているためには？
PWAを知っていく。 React-nativeとpwaは競合する概念
Rx と Redux
やり過ぎでは？ => 本当はブラウザに任せたい
SPAはライフタイムが長いもののためにあるものである
-> イニシャルレンダリングの体験を良くするというのもある
薄く浅く、メンテンナンス性を良くするというのも方向性としてはある
コンポーネントTDDの実践から見えたもの - @pirosikick
https://www.slideshare.net/hiroyukianai/inside-frontend-2-insidefe
ReactとVueの話
React入門 「React・Reduxの導入からサーバサイドレンダリングによるUXの向上まで」
コンポーネントの単体テストを書いている人？
コンポーネントをTDDで開発している人？
=> 少なめ
世間の認識
コンポーネントの単体テストは書かない -> テストケースが複雑でコストが高い
リリース後にE2Eテストやスナップショットを導入すれば良いと、ぼんやり考えていた。
特にB2Bだと、速さが求められて、放置されがち
価値が見いだせなかったり？
リリースしても手がアカない、機能追加、Bug fix、他の案件
E2Eテスト・スナップショットテスト、導入辛い
そうすると、、、
レビューにじかんがかかる、PRを出すのが億劫
悪いスパイラル
- Reactはenzyme
- Vueは@vue/test-utils
具体的なテスト
- shallow関数 / mount関数
- shallow、仮想DOM上
- mount、実際のDOM
コンポーネントによって描画される要素の確認、イベント処理の確認
enzymeとvue/test-utilsの違いを意識する
子要素の取得ができない?
新規コンポーネントは必ず単体テストを開く
- KAIZENアワー
- 新規案件は絶対書く
漠然とした不安感
仕様変更によってすぐ壊れるテスト
実装に対するテストケースになってしまって、振る舞いに対するテストにならない
=> TDDがいいよ
仕様に対するテストケースになるはず
実装が変わっても仕様が変わらなければテストは通る
コンポーネントにおけるTDDのススメかた
- テストケースを書く
- テストを動かして失敗することを確認
- 実装する
- リファクタする
仮実装で良いのでテストが通るようなコードを書く 仕様について考える->テストを書く->実装する
コツ
資料 : Components Tests with Vue.js
- Viewてきなロジックをテストする
VueやReact自体のテストにならないように注意する
テストツールに詳しくなる
- ハマりどころに注意する => チームで共有
時間
最初は時間がかかるように感じる
実装の時間は短くなる
ゴールが明確なので迷いがない
実装とリファクタリングが別れている
トータルの時間はあまり変わらない
安心感
画面に描画して触るまで完成した実感がない => 想定通り動いている状態を常にキープできる
テストケースのまとまりがメソッド・props => 振る舞いに変わるのは良い
布教の方法について
懐疑的な人が多い？
最初は時間がかかるので => モブプロ、ペアプロ
テストコードの質の担保
テストコードをレビューする文化
今後
テストをドキュメントとして機能させることを模索したい。
=> 質問、どのように説得するといいですか？？
デザイナーとの協業、見ながらやるひとがおおい
コンポーネント座談会 - @pirosikick, @koh110, @ikasumiwt
大きく作って細かく砕くか？
細かく作って大きく組むか？
ケースバイケース？
デザインカンプを見ながらコンポーネントを切っていく
デザイナーと一緒に作るにはそれになりそう
小さく組むには難しい、共通化するものは難しい
デザイナーが共通化したい部分と、エンジニアが共通化したい部分が違う
動的デザインガイドのつくり方 - @narirou
https://speakerdeck.com/narirou/dong-de-dezaingaidorainfalsetukurifang
動的？l
- living design guideline
- SGDD
既存の資産を抱えたwebにガイドラインを導入する
design system
デザインは定義しただけでは製品にならない
開発するために考えることはたくさん、さらにコンセンサスを取るのはもっと大変
デザインの潮流の変化に耐えうるシステムが必要
アイデアを速やかに製品に反映するためにコンポーネント化前提にデザインを考える
コンポーネント単位で仕様とデザインを明確化
そのためには
- 実コードを参照して生きたデザインガイドラインを作る
- ドキュメントには他レイヤーの情報を含める
- UIコンポーネント間のデータ型を明確に定義する
- 同じデータさえ渡せば、コンポーネントが必ず同じ状態で表示できる
現状の敵を把握、以降プランを考える
段階を踏む
- phpのリファクタリング、コードをロジックとテンプレートに分離
- モノリスをコンポーネントに大きく分解、分解できたものから再利用可能なものでさらにまとめる、jsonscemaでデータを定義
- 新しいフレームワークに
プロジェクトの回し方
デザイナーに協力してもらうには？
現状の問題点を洗い出して理解してもらう。
やりたい理想を整理はしておく。
課題を洗い出す。
事業をとめないためには？
コーディングタスクとビジュアルタスクが分離
UIUXの検討に集中
Micro-benchmarking is Hard - @saneyuki
https://docs.google.com/presentation/d/1MXlFGqFQFJByv8k6Ege0pt0GwJQqbjoh7GdIYia9UQg/edit
セッション
性能の改善がコンバージョンの改善につながる
=> ベンチマークを取る、継続的にプロットする
検討違いの対応をしないために、
速さを上げるためには、汚いコードを書かないと行けないが、それが意味がなかったら保守性を悪くするだけとなってしまう
マクロベンチマークを書くのはサービスが同設計されている必要がある
=> すごくめんどくさい
日常的にベンチマークを取るためにはマイクロベンチマークをするほうがよい？
しかし、そこにも違う難しさがある。
図ることにしくじったケーススタディ
JSのVMはJITを積んでいて賢いので、測りたいものが測れなかったりする
JavaScriptCoreの実装
DFGとFTL
real use case?
その関数の、アプリケーションで呼ばれる回数は？
使われ方によって測るべき対象が異なる
いつでも早くないと行けない
- start up performance => frist iteration
- worst case performance => worst 4iterations （GCなど）
- average
たとえマイクロベンチマークでも、アプリケーションのシナリオを意識しないといけない
泥臭いのはわかった じゃあ、実際どうするの？
マイクロベンチマークはそれ固有の知識が必要
うっかり失敗してしまったら、面白い具合にだめなののか。。
かなり簡単に言うと、
- ある程度複雑なロジックを測るのがよい、
- 使われ方を理解して書くと良い。
