InsideFrontend #2 に参加してきた

2/11 に日経カンファレンスルームで開催されたInside Frontend #2に参加してきました。

このイベントには去年も参加していて、非常にいいイベントだったので今年も参加させてもらいました。

Inside Frontend はほとんどのセッションの資料や、録画映像が配信されているので、この投稿では各セッションを聴いての感想とか AMA を中心に書こうと思います。

配信: セミナー A / セミナー B

資料: connpass で公開されている資料

Opening

オープニングでは会場説明や WiFi、行動規範などの諸注意がありました。

その後、スポンサーであるmoffersさんからサービスの紹介がありました。また、moffers さんの提供で、AMA の会場でコーヒーが配られていて、ありがたく頂きました。

moffers はレジュメをサブミットすると企業からスカウトが届く転職支援サービスで、オファーの時点で年収が確約されてるのは個人的にかなり好みなので、次転職する機会があったときは使いたいです。

Vary ヘッダとキャッシュバリエーションの将来(The Vary header and the future of cache variation) by Andrew Betts

Fastly の Andrew Betts によるキャッシュ周りのトークでした。(資料)

概要

フロントエンドエンジニアはマークアップや JS の知識だけ持っていれば良いわけではなく、キャッシュなどを適切に扱うためには HTTP の知識が重要。
キャッシュを適切に扱うためには Vary ヘッダーと CDN の理解が必要
余分なレスポンスを受け取らなきゃいけないためコンテントネゴシエーションの原案は死んだと言っていい
Vary ヘッダを適切に利用することで、キャッシュサーバーを経由していても同じ URL から異なるレスポンス(Language, ファイル形式など)を得ることが可能
Vary: Accept-Languageをヘッダーに付与すると、Accept-Language によってレスポンスが異なることをキャッシュサーバーに伝えることができる。
同じ URL へのリクエストに対しては常に同じ Vary ヘッダーを含めるべき
ブラウザは 6 段階のキャッシュの仕組みを持っている。すべて Vary をサポートすべきだが状況は微妙

感想

Vary ヘッダーの存在は知ってたけど正しい使い方がよく分かってなかったので、そのあたりを知れたのはよかった。
ブラウザキャッシュと CDN でキャッシュの流れが複雑化してるので、しっかり理解してクールにキャッシュする Web サイトを作りたい。

AMA WebPayments API

1 つめの AMA ではEiji Kitamuraさんのブースで Payment Request API の話を聞きました。

質疑一覧

概要

Payment Request API でブラウザの NativeUI を使える。
ユーザーはブラウザに保存されているクレジットカードなどの決済情報を使用することができる。
クレジットカード以外にも、サードパーティの Payment サービスを自分で追加できる
参考になる記事: https://blog.agektmr.com/2017/12/web-payment-misconception.html
ユーザーが支払い情報を入力してサブミットすると、JSON 形式で Payment Request API から返却される。
従来の入力フォームより 75%少ない時間で決済が完了するというケーススタディ
クレジットカードの生の情報じゃなくて、Token を扱うのでセキュア
現実的には、実際にサイトの開発者が Payment Request API を直に触ることはない。決済代行業者の SDK が基本的にやってくれる。

現場の ES201x とアーキテクチャの変遷と未来 by Koutaro Chikuba

mizchi さんによるフロントエンドの歴史と未来の話でした。

資料

概要

みんな消耗してる(IE11, webpack.config.js, 現場で動く jQuery…)
自分のコードに必要なもの、腐る部分、腐らない部分を見極める力をつけてほしい
セルフスクレイピングの時代 -> テンプレーティングの時代 -> データバインディングの時代 -> Flux/Observable の時代
フロントエンドは富豪的設計とマイクロチューニングを繰り返して、その先にある”理想”に近づいてる
AltJS は文法追加とか機能提案をしてきて、それがどんどん ES201x に入ってきた
最近の流行はとにかく型
Observable とか、静的型検査がないとしんどい
お祈りデプロイ 50%の時代から 5%くらいの時代になった
WebComponents で「xxx デザインの yyy(フレームワーク)実装」みたいなのは死ぬはず。
まずは現場にある古いコードを手懐けるところから
いいコード: 静的検査、インターフェースが明らか、簡単に捨てられる
悪いコード: モジュール境界が明らかじゃない
今のフロントエンド: OOP, FP, GUI 設計論の知見がごった煮の、様々な思想をぶつけあう戦場

感想

前半は今までのフロントエンドの変遷がよくまとめられていて分かりやすかった。自分が若いフロントエンジニアってのもあって、 4 割くらいは知らない時代の話だった。
トーク中に出てきた「型がないと Rx かけない」って話は全力で同意だった。自分が途中で参加したプロジェクトでは絶対にsomeFunc(): Observable<any>を殺すという強い意気込みを持ってやっていきたい。
良いコードの例で「簡単に捨てられる」というのがあったが、これはあんまり今まで意識してなかったので、意識してやってみる。

AMA 現場の ES201x とアーキテクチャの変遷と未来

前の時間枠で mizchi さんのセッションを聴いたので、AMA も mizchi さんのブースでお話を聴いた。

質疑一覧

概要

ほとんどの消耗は IE11 が原因。
IE11 をサポートから外す言い訳はいくらでもできる。
フロントエンドエンジニアっていうラベル付は破綻してる
デザイン方面から来た人と、node.js から来た人だと価値観が違う。前者は供給が多いので、フロントエンドってくくりで一緒にすると全体の給与水準は下がる
URL がマスターなのか内部状態がマスターなのかは意識して Router を書くべき
WebComponents はまだエコシステムが整ってないので、現場で使える状態ではないと思う
ようやく State 管理で議論ができるようになったのでいい時代

攻めつづける FRESH! の Web ver.新春 by すちを

sutiwo さんによる FRESH!のフロントエンドの進化のお話でした。

資料

概要

-　今まで決済代行サービスを使っていたが、購入手続きのたびに別ドメインに遷移するのを避けたかったし、FRESH!のサービス側で決済情報を持ちたくなかった -> Payment Request API

現段階では対応ブラウザは Chrome だけで、対応している決済方法はクレジットカードのみ。
Edge は MicroSoft アカウントを使わないといけなかった。それはユーザー体験が悪すぎた。
React を v15 から v16 にあげた。Fragment や render()の修正で余分な要素(div, span など)を作らなくてよくなった。
パフォーマンスの改善はとくに見られなかった
デプロイフローで、チェックシートにあるテスト項目を手で確認するのが大変だった。
Puppeteer と mocha でテスト自動化
CI でスナップショットのテストとかもやりたい

感想

新しい技術をとりいれて、非効率なフローを効率化して、どんどん攻めていく姿勢はすごく良いと思ったし、こういう環境で仕事がしたいと思った。

AMA 現場の ES201x とアーキテクチャの変遷と未来

前時間枠の AMA に引き続き mizchi さんの AMA ブースでお話を聴ききました。

質問を消化しきったので、同時間枠に別の AMA ブースで@ahomuさんと@1000chさんがやっている超速本の裏話をするというまさかの会でした。

mizchi さんの書評記事をベースに、いろいろおもしろい話が聴けました。

その中で「Chrome の DevTools は UI がすぐ変わるから読むなら早く読んだほうがいい」と話していて、たしかに…と思い僕は買っていてまだ手をつけてなかった超速本をすぐ読むことにしました。

日経電子版を速くするためにやっていること by sisidovski

sisidovski さんによる話題の日経電子版がなぜこんなに速いかというお話でした。

資料

概要

モバイルサイトは全面刷新。表示速度は約 2 倍になり、Hearst のランキングで 2 位になった
Financial Times の調査でサイトの速度が 1 秒落ちるとユーザーエンゲージメントは 5%下がることがわかった
チーム発足時からチーム内でスピードを最重要 KPI にした
r.nikkei.com とネイティブアプリのバックエンドで Fastly を使ってる
CDN でできるところは任せる
VCL で柔軟にキャッシュを制御。ただ VCL は辛い。
キャッシュヒット率 90%, 有料会員に対しても 70%以上
あとでいいことはあとでする。
必要なことは先にする。
使いまわせるものは使い回す
クライアントにとって最適なものを配信
まずは分析すること。Lighthouse や webpagetest などのツールを使う。
手がつけられるところから手を付ける

感想

高速化や CDN(Fastly)の使い方の知見が濃く詰まった非常に良いセッションだった。自分の中でパフォーマンス向上やっていきが非常に高まった。
既存のサービスと現実的にどう向き合って、ユーザーが喜ぶようなパフォーマンス改善を施していくか、よくまとめられていて良かった。

AMA 日経電子版の高速化について何でも訊いて下さい

sisidovskiさんとcssradarさんの日経電子版の高速化の AMA ブースでお話を聴きました。

質疑一覧

概要

Babel で Polifyll やらせると、無駄なコードを作ってしまうので、ランタイムで Polyfill してる
広告の表示を高速にするために全部同じ Ad Server から受け取ってたり、document.write を吸収して書き換えてる。そのあと eval して、shadowDOM でレンダリングしてる
仮に AdServer が死んでも影響が出ないようにしている
prerender が Chrome58 から無効化されてる(chrome の内部ロジック置き換えのため一時的に)

デザインシステムとコードを密結合するワークフロー by Takanori Sugawara

Takanori Sugawara さんによる、デザインシステムとコーディングを蜜に連携させるフローを構築するお話でした。

資料は公開されていないようです。

概要

チームでは基本みんなリモートなので認識合わせのコストが高い
現状の実装構造が複雑化 -> プロダクトの変化速度が低下して身動き取れなくなる
企画から実装まで、職種による翻訳や出戻りが多く発生する
全員で UI デザインしたらレビューいらなくね? -> Figma でやってみた
企画には具象度を高めてもらって、エンジニアには抽象度を高めてもらう
全員同じ土俵で UI を作った
UI 実装の依存関係も定義する
UI デザインにないものは絶対に実装されないルールにした
Figma の実践と Vue.js のライブコーディングによるデモ

感想

「UI デザインにないものは絶対に実装されないルール」というのが個人的に刺さった。これを徹底できるとデザインされたコンポーネントは破綻しづらいし、コーディングでスタイルも書きやすいのでいい。
最後のセッションは AMA がなくて、質問できなかったのが残念だった。

全体を通して

今年も数多くの有益な知見全開のセッションを聴けて大変勉強になりました！運営の皆様、発表者の皆様、本当にお疲れ様でした、ありがとうございました！！

また来年予定が合ったら参加したいし、トークも応募したいと思います！

数日後に、Rebuild.fm のこのエピソードを聴いていたら、Inside Frontend や超速本の話が出ていて面白かったです笑

変更履歴

360d0cfd Add icon variations