Home

Allajah's Reservoir

19 Feb 2018

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や超速本の話が出ていて面白かったです笑

Allajah at 16:00