YAPC::Asia Tokyo 2015 メモ (2/2)

カンファレンス/勉強会

(2015-08-31 修正: li要素のインデントが壊れていたのを修正)

前回の記事 の続きです。

Adventures in Refactoring - Ben Lavender

内容

リファクタリングとは
  • 振る舞いを変えずにコードを変更すること
  • リファクタリングのための悪い理由 (これらは計測できない!)
    • 一貫性
    • DRY
    • 抽象化
  • 良いリファクタリングとは
    • 行数が減る (diffstat)
    • テストのカバレッジと「表現性」が増える
    • パフォーマンスが良くなる
    • 開発者の幸福度が増す
リファクタリングの理由・動機
  1. 開発者の幸福度
  2. パフォーマンスの向上
  3. 技術的負債の返済 (Gain confidence for future work)
  4. 開発者の教育・トレーニング
リファクタリングのテクニック
  1. コードを幸せにする
    • 深いネストをやめる
    • 関数の抽出
    • 良い抽象レイヤの追加
    • 一貫性
    • 整形
    • スタイルガイドを手に入れる (つくる or 持ってくる => 従う)
      • go fmt => すばらしい
  2. 動詞の名詞化
    • 複雑な動詞の処理 => 名詞化してクラスにする
  3. 抽象化レイヤの追加
    • pull.branch_valid?, pull.branch_exist? => pull.branch.valid?, pull.branch.exist?
    • _ のところに1つのレイヤを追加できるかも
  4. 不要な抽象化レイヤの削除
    • かなりのコードとテストを減らすことができる
リファクタリングのためのツール
  1. Backscatter
  2. Scientist
Complaining
質疑応答
  • リファクタリングに関して議論になった場合は?
    • => Metrics を見る、デザインガイドに従う、議論を重ねる
  • リファクタリングと新規の開発、どちらを優先する?
  • リファクタリング: 振る舞いを変えない、その「振る舞い」というのは何? 「振る舞い」に自信がないときは?
  • リファクタリングでデザインパターン使う? どんなパターンを多く使う?
    • => No, コードがテストにフィットするように書かれてしまう
    • よいテストはよいコードから生まれる
    • ただし「自分はやらない」というだけで、他人に対して「やるな」とは言わない
  • スタイルガイドの変更/更新はする?
    • => スタイルガイド: 1枚の web ページ、プルリクベースで変更する
  • リファクタリングは退屈なこともあるけど?
    • => 素晴らしい仕事をしたら褒める、ハッピーな絵文字を振る舞う
  • テストがない or 少ない場合は?
  • テスト自体のリファクタリングは?

感想

  • 何をするにもまずはテストを書け、という話がまず前提としてあって、ちゃんとテストを書かねば、という気持ちになった。
  • その他にも、本を読めば書いてありそうな話が結構多くて、それを現場できちんと実践するのはなかなか難しいという現実があるけれども、それでも守るべき、という主張の発表だと認識した。
  • 「素晴らしい仕事をしたらハッピーな絵文字を振る舞う」 => チーム開発の場合はそれで良いのだけれども、1人で開発をしている場合にもうまいことリファクタリングに対する動機づけができるとよい…かもしれない。
  • さらっと聞き流してしまったせいか、テストの「表現性」の部分が理解できなかったのだけれども、 YAPC::Asia Tokyo 2015 2日目に参加してきた． - てきとーになんか書きます によると、“テストが何をやっているかがどれだけ分かりやすいかの指標”ということだったらしい。

HTTP2 時代の Web - Jxck

内容

  • @Jxck さん
  • HTTP2: RFC7540 になった
    • 策定フェーズ => 使うフェーズ
    • どうするか
現状
  • HTTP の高速化 => RTT (距離、レスポンス速度), RT (アクセス回数) を減らす
HTTP/1.*
  • Header: テキストベース、圧縮不可、毎回送る、重複多い (UAとか)
  • Body: バイナリも送れる、圧縮可
  • 毎回TCPコネクションを確立 (3-way handshake)
  • HTTP Head of Line Blocking (1度に1つだけのリクエスト、1つ詰まると残りもブロック)
    • 現状: 同時に6本接続
  • シンプルだけど高速化に限界 (既存の回避策: ハイパフォーマンスWebサイト)
HTTP/2
  • バイナリフレーム
    • パースしやすい、サイズ効率が良い、データ分割しやすい
  • セマンティクスはHTTP/1.*のものを維持 (互換)
  • HPACK
    • Huffman符号で圧縮
    • 頻出ヘッダ (e.g. Status: 200) を共有
    • 送信済みデータ (e.g. UA) を再利用
    • (圧縮率は実装次第; そこまでは仕様で規定していない)
  • コネクションは1本; ストリームを多重化
    • コンテンツの優先度制御 (e.g. html > CSS > js > 画像その他)
    • 帯域を効率的に消費できる (スロースタートとか輻輳制御とか3-W-Hとか)
    • Head of Line Blocking を解消 => 画面中の白い部分が早めになくなったりして、速く感じることも
  • Server Push
    • e.g. HTML の中で使われている js とかを、GET HTML の時点でサーバからクライアントに Push する
    • 1 Req / 1 RT の壁を超える
  • 積極的な Cache Control
    • Browser Cache: 熾烈な奪い合い
    • そのセッションだけに着目して、もっと積極的に Push
  • Server Push with Service Worker
    • API で Push を受け取る => 双方向通信 (Fetch / Push) ができる!
    • WebSocket on HTTP2, RPC on HTTP2 とかができる
HTTP2は必要か?
  • 性能
    • Response Time だけを測っていてもだめ、人間が速いと感じるかどうか
      • Metrics: Speed Index, Film Strip, TTFB (Time to First Byte), First Paint, RUM (Real User Monitoring), ...
      • バックエンドだけの数値ではないので簡単ではないが、それだけ見ていてはだめ
  • HTTP/1.* に最適化してしまっている
    • Bad Hack 無しの素直な作りでも速くなるなら…?
  • 実装あるの?
    • いま進んでいるところ、成熟していない
  • インフラは?
    • need more 知見
    • とくに HTTPS の終端については問題かも
  • HTTPS にしないといけない!
    • Pervasive Surveillance (スノーデンとか) => TLS 推奨の流れ (W3C, IETF, Google, Mozilla, ...)
    • Let's Encrypt: 個人向けに、無料 or 安価に証明書を発行しよう、というプロジェクト (Arriving Q4 2015 らしい…)
    • HTTPS でないといろいろ不具合がでる
      • ブラウザが未実装
      • WebRTC の getUserMedia() で毎回確認ダイアログ出る
      • Service Worker: HTTPSでないと登録できない
      • など…
  • HTTP2はハイパージャイアントのもの?
    • HTTP/1.1 との戦い: Web 全体の課題
    • 使いたくなければ使わなくてもよい
    • クライアントはすでに (勝手に) 対応している、あとはサービス側が対応するかどうか
  • 敷居が高い
    • とりあえずリバースプロキシ入れるだけでも速くなるみたいな話もあったり
    • 検証は容易、どうしてもダメなら HTTP/1.1 にすぐ戻せる
研究課題
  • priority 最適化
  • hpack の圧縮戦略
  • push による cache の管理戦略
  • など…
  • TCP の限界 (パケットが詰まったらどうしようもない)
    • => HTTP2 over UDP, QUIC over UDP
まとめ
  • よく知らない、導入しない => HTTP/1.1 もこの先使える
  • 理解した、導入しない => それが低コストである保証はないが、そういう選択もあり (ただし特に HTTPS 化には逆らえない…)
  • よく知らない、導入する => エコシステムが成熟すればそうなる、いずれそうならないといけない
  • 理解した、導入する => 今までできなかったことができるようになる
  • まずは使ってみよう (導入はまだ早いけど検証は十分できる!)

感想

  • HTTP/2 の背景と現状、展望がたいへん分かりやすくまとまっていた。
  • HTTP/2 自体について、全体的に HTTP/1.* 時代のバッドノウハウをきれいに再構成して規格化した、きれいなままで性能のでるプロトコルのようで大変よいと思う。
  • 「エコシステムが成熟すれば『よく知らないけど使っていた』という状態になる」という件、たしかにその通りではあるのだけど、それに甘えることなく自分で検証とかして勉強すべきであるなあ。

その他、全体的な感想など