freeeのアクセシビリティ、いまとこれから
- @magi1125(freee)
- https://docs.google.com/presentation/d/1D2DP0aP4l5N3MKNtt-LbfLeAEexkXYs4snC8vmzur3o/edit#slide=id.p
アクセシビリティ
freeeのサービス
- Webサイト
- アプリ
Webサイト
- W3C Eazy Check(https://www.w3.org/WAI/eval/preliminary)
アプリ
- 読み上げない場合あり
- アイコンにラベルがない
- 関連づかない場合あり
- フォーム(for属性)
Webサイトのこれから
- よく使われるところだけ重点的にやれば最低限はなんとかなりそう
- https://havelog.ayumusato.com/develop/a11y/e718-a11y_atonose_sakusaku.html
AMA
- A11yから遠いと感じる業種
- エンターテイメント系
- ゲーム、映画
- タッチスクリーンによって指が目の代わりになってきている
- 新規の時にコストをかけずに入れられるとよい
- CIでlint入れるとか
参考
現場の ES201x とアーキテクチャの変遷と未来
フレームワークの振り返り
過去
変遷
太古
テンプレーティングの時代
- コンポーネント的のな概念がでてきた
- htmlの生成がクライアント側へ
- underscore.template, handlebars
データバインディングの時代
- 木構造を出力するものへ
- データを更新すると描画も変わる
- backbone.stickit,knockout, Angular.js
- MVVMの導入
現在
Flux,Obvervableの時代
- EventとStateとViewを分離
- Ex, Elm, Redux
- FunctionalReactiveProgramming
- Componentの内側にあるstateは悪
- ReduxはRxのサブセット
トレンド
- データをメモリに置くようになる
- 仮想DOMによるバッファリング
- ブラウザの機能をより賢く実装する
- JS
- 毎年更新
- 多言語由来系
- ScalaJSとか
- WebAssemply系
- Rust系があつい
- AltJS
- ES201xに吸い込まれて消滅
- 生きてるのは型系
- なぜ型？
- テストが書きづらい
- 静的チェックで済ませたい
- observableがimmutable前提だと静的チェックないと作れない
未来
WebComponents
何が出来る
- 泥臭いことしかない
- lint
- 型
- テスト
- グローバル変数を消す(ESModule)
- 良いコード
- 静的チェックできる
- コードを捨てられること
- QiitaのReact -> hyperappとか
- lint
- prettier
- eslint: prefer-XXX
- eslint: no-unused-vars
ゴール設定
- スピードを突き詰めるのか
- 継続して価値を届けるのか
まとめ
AMA
- WebComponentsはスタンダードになりうるか
- なる
- けどIE11
- まだちょっと速い
- Reactとの連携とか
- ShadowDOM時代のCSS
- BEMとか消える？
- ESModulesでてくるとwebpack消える？
- IE11
- npmと相性悪い
- 間をとりもつものないと
- PWA
- PWAでネイティブアプリをWebでっていうのと、ReactNativeは競合するかも
- 超速本の話
- レイヤーを分けることでどこに時間がかかってるか分かりやすくなる
- http://amzn.asia/8SCM2Ic
- http://mizchi.hatenablog.com/entry/2017/11/24/141301
- パフォーマンス計測
- レガシーなフレームワークをどうやって置き換えるのが良いか
- 本当はスクラッチがいいだろう
- SEO
コンポーネントTDDの実践から見えたもの
- @pirosikick
- yahoo(第6,7代黒帯(JavaScript))
- リッチラボ株式会社(yahooの子会社)
- https://www.slideshare.net/hiroyukianai/inside-frontend-2-insidefe
- http://amzn.asia/c662Wwu
コンポーネントの単体テスト
リリース前
- コンポーネントの単体テストは書かない
- ケースが複雑でコストが高い
- リリース後にE2E/スナップショット入れればいい
- 入れる時間ない
- 今の開発フローのどこに入れる?
- レビューに時間がかかるよういなる
- 動作確認が..
コンポーネントの単体テスト何使うか
- Reactはenzyme
- airbnbが作ってる
- Vueは@vue/test-utils
- Shadow関数mount関数
何を確認
- porpの確認
- DOMが意図したものか確認
- イベント処理の確認
テストどうやって書くようにするか
- 新規は必ず作る
- 不安感
- すぐ壊れる
- 実装に対するテストケース
- TDDやってみよう
- 仕様に対するテストが書けるはず
- 実装が変わっても壊れないはず
TDDの進め方
- テストを書く
- 動かして失敗する
- 実装する
- リファクタする
TDDのコツ
- 仕様について考えて仕様に対してテストを書く
- テストも小さくステップを踏んで書く
- それでとりあえず通す
- view的なロジックをテストする
- react自体のテストにならないように注意する
- 要素にはカスタムデータ属性をつけること
- data-testid
TDDやってみて
- 手が止まる時間が多い
- 仕様を考える
- 実装ははやい
- ゴールが明確なので
- トータルは変わらない
- テスト書く前提なら?
テストコードの質
動的デザインガイドのつくり方
- @narirou
- Masanari Hamada
- yahoo,gyao
- https://speakerdeck.com/narirou/dong-de-dezaingaidorainfalsetukurifang
DesignSystemについて
- SGDD
- style guide driven development
- Living Design Guideline
DesignSystemとは何か
- 定義したデザインを迅速にプロダクトに反映させるシステム
- デザイン系
- 統一されたUX
- 再利用性
- 開発
- 低コスト
- 再利用性
- 仕様
- コードからガイドラインを作成
動的デザインガイドラインの作成ポイント
- コードを参照してデザインガイドラインを作ること
- ReactでいうとStoryBook
- 他レイヤーの情報を含める
- デザインの意図
- 使いかた
- ビジネス仕様
- 技術情報しかないUIの羅列だと技術者しか役に立たない
- UIコンポーネント間のデータ型を明確に定義する
- UIが受け取る型を定義しておく
- 同じデータを渡せばいつでも同じものができる状態
DesignSystemの事例
- Riff
- yahoo社内ライブラリ
- ATLASKIT
GYAOでの事例
古い構成から移行させる
- ReactのようなモダンなFW必要？
- なくてもできる
どうやって既存システムに適用したか
分類
- Script
- 動作
- Style
- スタイル
- Template
- テンプレート
- README.md
- 業務仕様も
- package.json
- モノレポにする
micro-benchmarking is hard
- @saneyuki(abemaTV)
- https://docs.google.com/presentation/d/1MXlFGqFQFJByv8k6Ege0pt0GwJQqbjoh7GdIYia9UQg/edit#slide=id.g331e86b4b3_0_807
ベンチマークを作る
- abemaTVはマイクロサービス
- ベンチマーク作るのとても大変
Webkit
- 実行エンジンによっていろいろ最適化している
- とりあえず10万回回してパフォーマンスとるとかは正確じゃない
- 有名所のベンチマークでもやらかしてる
- 検証対象の使われ方によって何をどう測るかも変わってくる
- たくさん回せばいいなんてことじゃない
- ポイント
- returnしたものを使う
- そうしないと不要だと判断されて消される
