RubyKaigi 2018 が楽し過ぎたから再開したブログ

表参道でWebエンジニアをやっています。

HTML5 Conference 2018 参加ノート

HTML5 Conference とは

events.html5j.org

上記イベントサイトには、

Web技術に関するノウハウや最新情報の共有、そして交流の場

であり、

「Web技術者の祭典」

と書いてあります。 私の中では、Webのフロントエンド技術に関するカンファレンス、というイメージがあります。

参加した経緯

仕事ではサーバーサイド(主に Ruby on Rails)を中心にやってきましたが、これからはフロントエンドも頑張っていこうということで、参加させていただきました。

前職の社内ツール開発や、 Eight の開発で React + Redux は触っていましたし、プライベートでも勉強はしていたので、フロントエンドが全くわからないわけではありません。
とはいえ、勉強会やカンファレンスに参加したことはありませんでした。

今回は、初めてのフロントエンド界隈のカンファレンスということで、楽しみにしていました。

参加したセッションのメモと所感

参加したセッションの内容について、箇条書きのメモに近いですが、まとめさせていただきます。
また、ところどころでコメントを足したり、最後に所感も付けています。

ZOZOのグローバルECのフロントエンドアーキテクチャ設計

電車からスマホで拝見していたためメモを取れず・・・Twitter#html5j_h を見返して気になったところにコメントさせていただきます。

  • state はリソース単位ではなくページ単位
    • サーバーサイドで RDB に慣れ親しんで来た身としては、state はリソース単位で扱うものだと思っていました。
    • ただ、実際に Redux を触ってみると、State は巨大な JSON であることがわかります。リソースがネストすることもよくあると思います。そうすると、一つのリソースが state の複数箇所に存在するということが起き得ると思います。
      • Eight ではnormalizr というライブラリを使って state を正規化していました。(少なくとも、私がいたころはそうでした。)ただ、normalizr は state の中でリソースが散らばるのを防げる一方で、実装が複雑になる印象があります。導入は慎重に検討するのが良い気がします。
    • state をページ単位で管理することで、スッキリできるの煩雑にならずに済むのかもしれませんが、やってみないとイメージが湧かないかもしれないですね。実際には、ページをまたいでリソースを共有したいケースはあまりないんですかね。であれば、すべてを SPA にするのではなく、ページが変わる時は普通に画面遷移して、ページごとに一つの SPA を構築?しても良いような気もします。実際、React を勉強し始めた頃はそのように実装していました。
  • BFF, GraphQL
    • 巨大なアプリケーションになってくると、やはり BFF が欲しくなってくるんですかね。その場合、一つのリクエストですべてのリソースを取ってこれるという意味で、GraphQL は良さそうな印象があります。

所感

全体的に、プロダクトの状況からあらゆる手段を検討して最適と思われるものを導入している感じで、良いと思いました。
一方で、そこまで検討できるチームなら、最初から考慮できるものもあったのでは?と思ってしましましたが・・・メンバーも変わったり、チームの成熟度も高まったりしたこともあるのでしょうか。

FIDO認証によるパスワードレスログイン実装入門

  • パスワード認証の課題
    • 利便性、安全性の課題
  • FIDO
    • Fast IDentity Online
    • パスワードへの依存度を減らす
    • 利便性と安全性を向上する
    • 公開鍵認証
    • RP
      • Relying Party
    • 認証器 (Autenticator)
  • FIDO の利便性
    • 生体認証
  • FIDO認証モデル
    • ローカル認証
    • Authenticator はスマホなど
  • FIDO 技術仕様
    • FIDO UAF
      • パスワードレス
      • 主にスマホ
      • 生体認証
    • FIDO U2F
    • FIDO2
      • Web Authentication API
        • ブラウザからクレデンシャルにアクセスするAPI
      • CTAP
      • 認証対応プラットフォームの拡大
      • RP のサンプル実装
        • 様々な言語で実装されている
        • github/fido-aliance/
  • UAFとU2F
    • ユースケースが異なる
      • U2F => 二要素認証
    • 様々なユースケースに対応するために、FIDO2 が出てきた
      • これからは FIDO2 が中心になってくるという認識で良いのでしょうか?
  • Web Authentication API
    • ブラウザからクレデンシャルにアクセスするAPI
    • Credential Management API の拡張
  • CTAP
    • クライアントと外部認証器間の通信をサポートするプロトコル
  • デモ
    • name を入れるだけ + USBセキュリティキーで登録
    • ブラウザのユーザー登録で、名前と USB セキュリティキーを登録する、というのは新鮮でした。
  • Web Authentication(登録)
  • 資料は後日公開してくださるそうです!

所感

  • 実際に認証するのはローカルの認証器(スマホなど)なので、生体認証の中身がインターネットに出ることはないとのこと。(という理解です・・・)
  • ブラウザ上の Web アプリケーションで生体認証が使えるのは良い!と思った一方で、予想以上に実装が大変そうでした。既にここまで追っているのはすごいです・・・
  • 浸透してくるにはもう少し時間が必要なのかな?という印象です。

Yahoo! JAPANアプリ上で動くWebVIewサービス開発〜Web技術で動くライブクイズ「ワイキュー」〜

  • アジェンダ
    • WebApp on ネイティブアプリ
    • メリット/デメリット
    • デバッグ方法
  • メリット
    • アプリ開発チームと別チームで開発できる
    • iOS/Android 一緒に開発できる
      • PC と違って IE のことも考えなくて良い
      • 実行ファイルは ES5 に落とせば動く
    • 審査なし
      • リリースサイクル
  • 各サービスはそれぞれ自前のBEアーキテクチャを持っている
  • 同時に開発できなかった事例
    • 時間の文字列の取扱が ChromeSafari で違う
    • HLS の取扱い
  • デメリット
    • パフォーマンス
      • WebView の生成をしてから、APIを撮ってきて描画する
    • ネイティブ機能を使うのは少し手間
  • WebView ならでは
    • ネイティブの機能を使わせてもらう
    • Push
      • アプリ任せ
      • 通知すべきか、いつ通知するかなどは、各サービスで管理
    • ログイン情報は Cookie で管理
    • 普通に Webb でログインしている
      • Web でログインした情報をアプリと共有して、アプリでもログイン
    • URLScheme でネイティブとやり取りする
      • Web => ネイティブは URLScheme
        • iframe を使って URLScheme を呼び出している
      • ネイティブ => Web はカスタムイベント
        • 予め取り決めしておいたカスタムイベントをアプリに発火してもらい、JSではイベントを listen するだけ
      • 例えば
        • ユーザー情報ください
        • 未ログインなのでログインさせてください
        • 別のIDでログインさせてください
        • 終わりなので WebView 閉じてください
  • ネイティブアプリのように見せる
    • WebbView のフチをなくして全画面に
      • アプリ側の設定
      • もちろん、必要ならつける
    • SPA で作る
      • 通常の遷移だと Web っぽい
      • URL という概念があったほうが作りやすい
      • URL はつけてもユーザーには見えないので、多少変な URL でも大丈夫
    • SSR は必要に応じて
      • ワイキューではやっていない
      • 初期レンダリング速度を要求されるようなサービスではない
      • 任意のページに直接アクセスされることもない
      • アプリ内から見られるので、SEO対策も必要ない
    • Android の戻るボタンをオーバーライド
      • デフォルト動作のブラウザバックの代わりに、戻るボタンを押したというイベbントを起こしてもらう
      • SPA的にブラウザバックで良い時はブラウザバックさせる
        • 確認ボタンとか出したい時はフックさせる
  • 実際の開発について
    • 開発環境
    • ブラウザでのデバッグ
      • アプリからのイベントは通常のカスタムイベントなので、イベントを発生させるボタンがあればエミュレートできる
      • APIやSocket なども最終的には Redux の Action として処理される
    • 対応する Action を叩くボタンがあれば確認できる
    • シュミレータでのデバッグ

所感

  • アプリが大きくなってきて、複数チームに分かれて開発をする場合、WebView という選択肢は良さそうに思いました。
  • 巨大な一つのモノリシックなアプリケーションを複数チームで開発することで、コンフリクトが発生することは、サーバーサイドでも話題になります。
  • そこでマイクロサービスが一つの解決策になるわけですが、サーバーサイドをマイクロサービスにしてもフロントエンドやモバイルアプリは分割できない、という話はよくありそうです。
  • フロントエンドではマイクロフロントエンドという選択肢があるようですが、モバイルにおいては、WebView の一つの解決策なのかもしれないですね。

Node.js まとめ

  • Node.js 11 リリース
    • あまり変更がない
  • Node.js コアポリシー
    • small core, less is more
    • LESS IS MORE.
      • 建築家の言葉
      • これ以上引くことがない状態が、良い状態
      • シンプルな状態を目指しましょう
      • Less is More 普段の開発でも意識していたい。
    • コミュニティのエコシステムで解決できるものは
    • では何をやるのか
  • Stability (Node.js Core)
    • Long Term Support で不具合は2年間修正される
    • セキュリティ問題はさらに3年間修正される
    • 安定的に運用できる
    • LTS 的なことをやっている言語はあまりない
      • 新しいバージョンが出たら追従していかないといけない
  • V8 & Node.js
    • V8 は Node.js 非互換の修正は通知する
    • v8/node に Node を fork している
      • 自動テストを回して、テストが壊れないことを保証している
    • 昔は壊れた
      • V8 のバージョンが上げられない => 最新の仕様を取り込めない
  • PR毎に CI でテストする
    • 全CPU・プラットフォームでビルドしてうまくいくことを確認している
  • たまに壊れるテスト (flaky test) に関してはどのプラットフォームで起きるか調査し、修正していく
    • フレーキーテスト
    • Issue に書いておく
      • フレーキーテスト をどこかにまとめておくというプラクティスは、普段の開発でも取り入れたいと思いました。実際、たまに落ちるテストってあるんですよね・・・
  • Stability (Node.js Application)
  • Performance
    • Performance priority is high
    • 遅いことを許容しない
      • ES2015 の let, const
        • 初回は遅い
        • var とスコープが違う
        • 若干遅くなっていた
        • 今は、v8 が頑張ってチューニングしているので、let, const にしても良いかもしれない
        • Node の中のコードは var が多い
    • 必ず定期的に benchmark を取得
    • マイクロベンチマークだけではなく、Express を使ったある程度の規模のアプリでもテストする
  • keep v8 fresh
    • v8 はパフォーマンスチューニングをかなりやっている
    • v8 を最新に保つのは、パフォーマンスの点で重要
    • v8 のバージョンはメジャーバージョンリリース時までの Stable Chrome に利用されている v8 を利用。
  • Worker
    • Thread を使えるようにするためのもの
    • Node.js はずっとシングルスレッドだった
    • Node.js で multi thread プログラミングができる(ついに)
    • 何が嬉しいか
    • Node.js の需要はサーバーサイドだけではない
      • Webpack, Babel
      • ファイルを集めてきて、ファイルの中身を呼んでトランスパイルしている
      • CPU をめっちゃ食う
      • シングルスレッドでは限界がある
    • 4つの Babel プロセスに投げる
  • 最近入った llhttp というパーサがやばい
    • Node.js は http_parser という C で書かれたものを使っていた
    • まだ experimental
    • TypeScript から LLVM bitcode 生成する
      • ラッパーを書いてから C からも呼べるようにしている
    • 普通は C から LLVM にして WASM にして JS で呼べるようにする
    • パフォーマンス向上
  • Security (Node Core)
    • Security Release は脆弱性が報告される度に修正パッチが作られて報告される
  • Security (Ecosystem)
    • npm-audit
    • npm audit コマンドは脆弱性が報告されているライブラリが自分のパッケージの中にあるか、調べてくれる
    • yarn audit もある
      • yarn audit は CI の中に入れちゃって良いのかも?と思いました。
  • Less is More で機能追加はしないと言っても例外はある
  • Web Standards
    • Why Node needs web standard?
    • internet standard なものも取り入れていく
  • Node.js v10.0.0 ~ v10.12.0
    • http2
    • Promise
  • Node.js v11
  • http2
    • 1 TCP connection
    • リクエストを多重化できる
  • ES Modules
    • import で読み込める
    • まだ Experimental だが、commonjs も es modules も相互運用できる形で実装されている
    • .mjs という拡張子
    • nodejs/modules で議論
  • Promise in Node Core
    • Node.js には非同期処理のやり方が複数
      • Callbabck
      • Promise
      • Stream
      • フロントエンドで非同期といったら Promise なので、普通に Promise で書いてました・・・
    • Web では Promise がほぼ標準的なので、Promise に集中されていく
    • util.promisify
      • Callback を Promise 化できる
    • fs.promises
      • これも Experimental
  • Stream/Promise の親和性改善
    • Stream => Promise
    • Promise => Stream
    • どっちもいける?
  • Node.js の今後
    • Big News
    • Node.js Foundation, JS Foundation はマージしていく流れ
  • Unified JavaScript Platform
    • W3C/WHATWG
      • Web
    • ECMA(Web と Node.js の中央にいる)
      • tc39
      • 少しずつ中間を増やしていきたい
    • Node.js
    • 統合していきたい
  • Web API も Node.js も ECMAScript も求めているのはユースケース
    • 開発者がユースケースを作っていき、仕様策定者側にフィードバックする必要がある

所感

  • 古川さんがイケメンだった
  • 知識量に圧倒されました。Node.js の最新の動向についてや、WASM や LLVM についてなど、かなり深いところまで理解していらっしゃるなと・・・
  • これくらい強い人になりたい
  • 開発者がユースケースを作っていき、仕様策定者側にフィードバックする必要がある という言葉も印象的です。こういう意味でも、ある種 攻めの 技術選定というのは必要なのかもしれないですね。

HTTP の今と未来 ー BBR, HTTP/2, QUIC の基礎から 5G 試験ネットワークでのブラウザベース評価試験まで

  • 事前配布資料
  • GZip 圧縮していない人は論外
  • 低遅延の事例
    • トラックの隊列走行
    • 建設機器の監視・制御
    • VR を用いたリアルタイム観戦
    • 場所にとらわれない e-sports
    • あらゆる映像の解析
  • 5Gサービス実現に向けた取り組み
    • 2018~ 実証実験
    • 2020~ 5G実現
    • 2022~ 5G高度化
  • Web for 5G の課題
    • 5G の性能を活かしきれない
  • MEC (Multi-access Edge Computing) の活用
    • 5G基地局 の前にサーバーを置く?
    • 5G の性能を活かしたアプリ提供
  • 今まで
    • オペレータは土管として NW パフォーマンスを意識
  • これからの5G
    • エンドユーザへのサービス視点がないとやばい
  • 実験環境を提供
    • 一緒に作っていく
  • 場所の提供
  • HTTP/2 & TCP のおさらい
    • 待ち行列の先頭が詰まると待たされる
      • 最初のファイルの送信完了まで後続のファイルが待たされる
    • TCP の課題・限界
    • HTTP/1.1 から HTTP/2 へ
    • 単一 TCP 接続上での非同期並列通信
      • 今までは単一 TCP で1ファイル
      • 今のブラウザの実装では、HTTP/2 なら100ファイルまで
    • Google SPDY => HTTP/2
    • TLS 1.3
      • SSL の新しいやつ
      • 初回接続(Full Handshake)
    • TCP における輻輳制御
      • フルスピードで送ると、回線が細いところであふれる
        • パケットがロスする
      • 観測して、調整する
        • ロス検出
  • HTTP3 QUIC
    • QUIC とは
      • HTTP + TLS over TCPUDP 上で再実装する
  • HTTP/3 + QUIC Transport
  • HTTP/3, QUIC を試すには
  • LiteSpeed
    • QUIC 対応は商用ライセンス

所感

  • スーツに素足で登壇されていて、印象的でした。既に只者ではない・・・
  • 結局 HTTP/2 にちゃんと触れることがないまま、HTTP/3 の話が来てしまった・・・
  • 5G×IoT Studio 面白そうです。 IoT に疎いので、まず「5G x IoT のデモ見学」をしてみたい。

スペシャルセッション

LTとクイズ大会でした。

1000万以上のWebページをAMPにした話

  • weblio
  • Why AMP
    • 速度改善
    • SEO
      • ページ表示速度が遅いと、検索順位が下がるかもしれない
    • ユーザー数増加
  • どうやって大量のページを AMP にしたか
    • 段階的に AMP にしていく
      • タグがなければ
    • GA で計測
  • 有効な AMP か検証する
    • URL の最後に develop...
    • Search Console
  • 便利な AMP コンポーネント
    • 100種類のコンポーネント
    • 非AMPページにも使える
    • amp-img で画像の遅延読み込み

slamdata/purescript-halogen の紹介

@e_ntyo さん

  • PureScriptとは
  • slamdata/purescript-halogen
    • VDOM を利用した UI ライブラリ

      - 仮想DOM

ビルドプロセスから考える CSS アンチパターン

@kimamula さん

  • CSS 苦手勢
  • Flexbox, Grid Layout を使えば、 CSS はそんなに辛くない
  • コンポーネントベースなのに、CSS はグローバル
    • Bootstrap, 独自CSSなど
  • フロントエンドはコンポーネントベース開発が主流
  • 使われていないCSSが場bンドルに混入する
    • ページのひょうじが遅くなる
  • ローカルスコープ化する技術を使えない
    • BEM などで戦う
  • ポータビリティが下がる
    • プロジェクト外で再利用しづらい
  • CSSコンポーネントに含める
    • メリット
      • code splitting が可能
      • ローカルなネームスペース
  • コードは DRY だが出力が DRY じゃない
  • CSS in JS
    • ビルド後のコードを考えていない
    • JS は DRY だが CSS は DRY じゃない

Preload, Preconnect を利用した SPA サイトのパフォーマンス改善

@yayoc さん

  • micro services, BFF, SPA, ...
  • Preconnect
    • DNS lookup, TCP handshake などを早期に行い、コネクションをせつぞく
    • 画像サーバー、
  • Preload
    • 早めに取得
  • Prelaod as font / image
  • Preload as fetch
    • API リクエストも指定できる
    • /layouts はレイアウトを構成するために必要な API
    • JS の実行前にリクエストを実行可能
    • componentDidMout の前に
    • preload タグは動的に挿入可能
  • 結果 / まとめ
    • Preload / Preconnect は割と簡単
    • ルーティングベースで動的に取得可能

CSS組版の救世主 Vivliostyle

@spring_raining さん

  • CSS組版
    • Web技術で本をつくる
    • HTMLで原稿を書き、CSSでページにレイアウト
    • 同人誌、商業誌で使われている
  • Vivliostule
  • ブラウザにない機能
    • ページの端っこのレイアウト
      • CSS Paged Media で定義
    • ページ番号や counter の参照
      • CSS Generated Content for Paged Media で定義
  • Vivliostyle の目的
    • 標準化される可能性
  • EPUB Adaptive Layout という仕様に対応した EPUB ビューアを

Webb Develop

@kosamari さん

  • Squoosh.app 作ったチームの人
    • すご・・・
  • Input のお話
  • Non-fast Scrollable region
    • passive: true
    • イベントは教えてほしいけど、スクロールはそのままやっちゃってください

最後に

改めて、Web を追いかけるのって大変ですね・・・。普段は今仕事で使うようなアプリケーションレイヤーのことばかり追いかけていて、深いところまで理解せずに使っていることを痛感したような時間でした。HTTP/2, HTTP/3 も触れねばだし、次の仕様を追いかけるような強い人になりたい。

私にとっては初めてのフロントエンド界隈のカンファレンスでしたが、とても楽しかったです。関係者の皆様、ありがとうございました!!