Inside Frontend #2 に行ってきたメモ https://gyazo.com/78b2f04b4f6f479695225e2946266936 https://inside-frontend.com/
感想
昨年とくらべてセミナー A とセミナー B の内容がはっきりわかれていた(よかった
フロントエンドの多様な責務がここにも反映されてるように感じた
UX や a11y などに取り組む会社も確実に増えてきている
デザインにもシステムにも近いフロントエンドエンジニアはそれらの推進に適役っぽい
JS や CSS ももちろん書かないといけないんだけど、それ以前に解決しないといけないレイヤーにフロントエンドも手を出し始めた印象
ストレスが少なく満足度の高いイベントでした!
デザインシステム構築の進め方は教科書的になるんだろうか
実際段階リリースしたり
差し込みがあったり
作り込むまでにもっと紆余曲折ある話が聞きたい気がする
AMA の配信が見たかった
以下メモ。
普段自分が追えてなさそうな
Varyヘッダとキャッシュバリエーションの将来
字幕は上下にあった方がよかったかもしれないですね(前の席だと首痛い
普段はロンドンにいる
Vary で URI を同じにできる
モバイルのために軽量化や多言語化を考えたことはある?
多用な画像形式
Content negotiation
1997 から存在している
利用されてきていない
原案は死んだ
同じ URI で type を変えて違うフォーマットを取得できる
Nikkei.com が Accept Language で出し分け
Vary: Acept-Language
これで言語がキャッシュのキーになる
リクエストメソッド、ホスト名、パス以外の多くのヘッダはキャッシュに使われていない
Normali(sz)e😂
Fastly では language_lookup で探索
Accept-Encoding
圧縮方式
Brotli で使うようになってきた
Cookie でユーザーの状態が確認できても、全ての Cookie をキーにするとキーとして効かない
トップページは2つのページしかないのにキャッシュできないのはもったいない
Vary: Cookie ではなく Vary: UserRole
The Key HTTP Response Header Field
Vary の代替え
ヘッダ内にアルゴリズムを含めることもできる
サーバーでどちらにしろ言語を判断しているので Accepet があってもなくても Vary を返却するのが大事
例外は
Vary: UserRole, ABTestFlags の場合
ブラウザでは?
複数の variation を保持しない
ブラウザは6つキャッシュ
すべてで Vary をサポートするべきだが…
CDN は1つ
ServiceWorker では複数の Variation をほじするべきだと
いまのところ Vary を含む Push もつかえない
ビューポート、デバイスピクセル、Save-Data などが Vary の可能性を秘めている 無駄なリクエストをなげていない?
Client Hints 使ってる?
AMA: Fastly のエッジクラウドについて何でも訊いて下さい
CDN ベンダーではなく Edge Cloud って呼んでる
Instant
150ms でキャッシュ削除
リアルタイムで消えるのが最初
Real-time
ログは2秒程度の遅延
ログサービスとの連携もできる
API-friendly
設定は秒単位
Fastly で H2O をどれくらい使ってる?
HTTP/2 の終端で使っている
Early Hints はどれくらい対応している?
「規約に同意」のUX -ストレスフリーな同意UIとその実現方法-
コンプライアンスとは
企業倫理、法令遵守
Social Media ボタンをつけることで風説の流布、相場の操作にならないか
7% しか読んでいない
7% の人は規約を読んでから同意している
齟齬が発生しないように、厳密かつ明確に書いている
正しく理解して安心してもらうのが目的
クリエイターとしての目線と企業側の視線
両者をともに満たす UX を探っていく
FOLIO での変遷
利用規約をリンクで別タブに開くのは読んでもらう必要がなければベストではある
一元管理できていなかったので
もともと Word で管理していた Markdown を Word に逆生成
Confluence の編集はつぶして GitLab で直接 Web から編集
Web エンジニアのやり方を押し付けるべきではない
フロントエンドエンジニアとして
●●Tech が増えてる
その業界を知るのが大事 / 必須
デザインとシステムをつなげるからこそマーケティングやコンプライアンスともつなげる
コンポーネントTDDの実践から見えたもの
code:かっこいいけど見づらいプロフィール.jsx
<AbuotMe
name=""
handleName=""
titles={[]}
home=""
/>
React と思われがちだが最近は Vue もやってる
コンポーネント単体テストの案件と考え方について
コンポーネントの単体テストを書いている人が少ない
B2B でリリース優先になることが多い
リリースしても手があかない問題
リリース後に E2E なりスナップショットテストが書けない
レビューのコストが高くなり、変更をすくなく実装しちゃう
週1日 KAIZEN アワー
新しい案件だとコンポーネントがすぐ変わってしまう
実装に対するテストになっちゃう
漠然とした不安感に襲われたので TDD やろうと思った
コンポーネント TDD のコツ
粒度がわかる
enzyme や @vue/test-utils のハマりどころを知ろう(機能も
その他
テストコードをあーだこーだレビューしたい
他人のテストコードを読みたくない
AMA: Web パフォーマンスについて何でも訊いて下さい
CSS プロパティの組み合わせによりレイアウトの複雑度は加速度的に上がる
div を分けて別々にスタイリングする
blur の量を変える
角丸や shadow が減っている
ぼかしのコストが高い
画像にするなどラスタライズすればすればいい
Speed Curve
SpeedIndex よりも FP や FCP が影響している気がする 全部やると大変じゃない?どこまでやれてる?
遅いときにやるだけ?
全部チューニングしてるの?
ネットワーキングの部分は定常的に監視
レンダリングとスクリプティングはまずければ
自分のサービスなら自分が満足するまでやる
他人のサービスならアラートが飛んできたらやる
サードパーティの影響はどう管理している?
入ってしまったものはしょうがない(外しづらい
GTM で入れられてしまうと困る
Living Design Guideline
SGDD(StyleGuide Driven Development) 毎回デザインにまつわる課題を考えるのはつらい
Complextion Reduction Design
統一性、再利用性、仕様としてのデザインシステム
作成のポイント
実コードを使っているコンポーネント集をつくる
ドキュメントに他レイヤーの情報を含める
デザイン意図
ビジネス仕様
技術情報
利用方法
技術者以外にも有用なドキュメントに
UI コンポーネント間のデータ型を明確にする
どんなデータが渡るのかを明確に
同じ状態がつくりやすくなる
どんな言葉がささるか
エンジニアにはパフォーマンス、生産性、モダン
デザイナーには統一性、生産性
企画・経営には事故リスク、工数削減、潮流を届けられないのはリスク
デザインガイドラインを PR ベースの練習課題で教育
楽しい
デザインシステムとコードを密結合するワークフロー
牛はプロパティをたくさんもってる
UI までたどり着かない
企画・開発プロセスにおける溝をデザインシステムでの解決を試みた話
中盤から Figma と .vue を触ってただけ
デザインツールがぽこぽこ出てきてるけど選定していくのかしら