Bruce Lawson「以後operaはwebkitとv8にします」
Opera Developer News 2012.2.12のエントリ
Opera Developer News - 300 million users and move to WebKit
以下斜め読んだ内容
- operaユーザ数：3億人突破
- レンダリングエンジン：webkit/v8に変更
- 投入時期：スマホが最初
- お披露目：Barcelonaのカンファレンス
- 影響：ユーザはゼロ。開発者は少々
- 音声データ：webmとh.246両方をサポートが安全。source要素で両方ソースに書く。canPlayType()使って判定
- winow.object：廃止。ブラウザ判定では使えない。ていうかmodernizrとかその辺使え
- operaアドオン：変換ツール出す予定
- 昔話
- opera起源の便利機能：タブブラウザ、スピードダイアル、ページ読込のためのデータ圧縮
- （補足）「ページ読込のためのデータ圧縮」が他のブラウザでどう使われてるのかが？？
- 転向理由：
- 正式にwebkitチームに参加
- [webkit-dev] Opera and WebKit
- 以後パッチ送って貢献
- コメント欄
Nick Pettit「Paul Irish一問一答」
Treehouse Blog 2012.10.24のエントリ
Treehouse Friends: Paul Irish - Treehouse Blog
- 聞き手が教育系スタートアップの人
- html5 boilerplate始めたきっかけの話とか
- 条件付きコメントを使ってる理由とか
- yeomanの話とか
- なんだかフロントエンド開発の敷居が上がり続けてる件とか
- web業界以前の話（wordの差込印刷作った奴偉い、とか）
- アドバイスとか
通り一遍を訊いててinformative
以下斜め読んだ内容
- Paul Irish。誰？
- google chrome developer relationsチームの人
- 色々プロジェクト手がけたり参加したり
- インタビューのポイント
- どんどん複雑になってるフロントエンド開発
- キャリアパス
- html5 boilerplace
- などなど
- インタビュー動画あります
以下一問一答
- Q：自己紹介、やってること
- A：
- Q：色々なプロジェクトを進めてる動機
- A：
- 一つは人助けから得られる満足感から
- あとは自分の記憶力の悪さを補うものが欲しかったから
- 書き出しておかないと忘れる
- meqia queriesやviewportの使い方を調べるとする。得た知識やノウハウをいつでも使える状態にしておきたい
- html5 boilerplateはそうやってできた
- ネットや本で調べた知識・ノウハウをストックしてる
- 自分が必要としたもので、自分がとても助かってる
- 転じて、自分以外の人にも役立ってる
- webはみんなが凄いものを作れる場所であって欲しい
- こういう気持ちが自分がやってることの動機にもなってる
- webがもっと強力なプラットフォームになっていくプロセスに自分が貢献できることに満足感を得てる
- Q：必要としてるノウハウ・知識は色々なタイプがあるから、プロジェクトも色々な形をとってる？
- A：そうできるからそうやってる
- Q：色々なプロジェクトに割くリソースの配分。バランス
- A：
- 時間管理は得意じゃない
- workflowly使ってる
- WorkFlowy - Organize your brain.
- いいツール
- リストのネストができる強力なto doリストアプリ
- ４半期に分けて、プライオリティ設定して、ひたすら試行錯誤
- 少し長めの期間を視野にいれとくのは大事
- 日単位だと、別のことに気が向いたり、新しいことを試したくなったり、とやってしまうのはありがち
- ある程度経って振り返ったら、諸々の脱線が本当にやっとかないといけないことにデカいダメージ与えてる、ってもありがち
- 自分は時間管理がとても下手くそだが頑張ってる
- Q：生まれとか経歴とか
- A：
- Massachusetts西部、Connecticut出身。要はNew England出身
- 音楽やってた。マーチングバンドでチューバ吹いてた。高校では演劇とバンド
- ネットで最初に作ったのは音楽ブログ。2004年くらい。
- 音楽ブログでは古参で、最初の５０番目以内に入っててそこそこPVあった
- ブログのデザインを変えたり色々試したりしてた
- フィードバックもたくさんもらえる状況にあった
- フロントエンド開発はとても楽しい、と思った最初の時
- Q：いつ頃からwebやテクノロジーに関心を持ちだした？
- A：
- フルタイムで働き出した頃
- 遊びでウェブサイト作ってた頃、ie4が出た
- msはクールなマーケティングやってて、DHTMLが出てきた頃
- msは全米の映画館を貸切にして開発者を招待し、ポップコーン、Tシャツ、win95のOSディスクを無料で配ってた
- msは映画館でie4でできることを披露し、それがとてもすごかった
- ものすごい数の機能が登場してて、「凄いクールだ」と感動してた
- 実はその自分の熱は一旦冷めて、大学進学したが、進学した後にその熱はぶり返した
- Q：webとテクノロジーの勉強のために進学した？
- A：
- 学位はtechnical communicationsで取った
- web開発全般を学べる大学があれば、と当時思ってた
- フロントエンド開発は大変でキツイ
- フロントエンド開発のために洗練された教育プログラムがあったらな、と思ってた
- 実際には自分が受けた教育は、コンピュータサイエンス、数学、経営、コミュニケーションだった
- Q：
- technical communicationsという学位は自分のキャリアに役立ってる
- 自分（＝nick）は教育系会社の人なので訊きたい所
- A：
- ある。現状、CSの学位のご利益はデカい
- ５年前の時点でコンピュータサイエンスがweb開発に役立ってるとは言えなかった
- 現在は違う。クライアントサイドでは、ロジックに溢れてる
- jqueryで書き、物事がよくなってく。。tranlateをしてる、より大きなアプリのコードを書いてる
- Q：相当複雑なものになりつつある
- A：
- 文房具会社でマーケティング的なことをやってた
- 文房具会社は結婚式招待状や出産報告とかを作ってた
- つまりweb成分ゼロ
- 自分はwordで差し込み印刷用のファイル作りファックスを一斉送信に使った
- 差込印刷を送信する顧客むけにカスタマイズすることもやってた
- こうしたカスタマイズを可能にするロジックがwordにはあった。word偉い
- その後配置換えになってEC部門へ。よい機会になった
- 自力で開発できるものを持ってたほうがいいと思う
- 自分の場合は音楽ブログ
- 更に、ブログじゃなくてもいいけどweb上に自分の場所を持ってたほうがいい
- ブログ書くのはいいこと。学んでることをブログに書くのはとてもスマートなこと
- 色々繰り返したり試したり遊んだりできる場所を持ってるのはいいこと
- 例えばcss3の新機能が登場したとき
- デモ作る、色々調べる、codepenにポストする
- デモ・調べもの・ポスト等々を奨励し、フィードバックをくれるコミュニティがたくさんあり
- コミュニティに参加して、調べ物したり、話ししたり、プロフェッショナルな開発を探求したりできる
- 自分はそうやってきた、物事すすめるスマートなやり方だった
- Q：ちなみに最初のブログはworpress？
- A：yes
- Q：
- A：
- インターフェース開発であるから
- インタラクションの仕方を決めることができる
- ユーザやお客からフィードバックをもらうことができる
- ユーザやお客の心に届くものを作ってる
- ユーザやお客がマウスカーソルを走らせる場所を作ってる
- インタラクションのあり方、UXのクオリティをコントロールする立場にある
- レスポンスを高速化させる仕事、堅牢なインフラを作る仕事も開発にはある
- だが、UIに自分はとても魅力を感じてる
- Q：すぐに達成感を得られるってこと？
- A：
- 素早い達成感、自分が作ったものへのフィードバックサイクル
- ユーザを喜ばせるものを作れる
- 使った技術がまずければ反感も買うことだってある
- Q：
- 次はhtml5boilerplate
- デザイン・開発初心者にとっても役立ち、内容充実してる
- プロジェクトが始まったきっかけ
- A：
- 前職の頃。Bostonのweb制作・開発の会社
- プロジェクトをこなすなかで、自分のコードを何度もコピペしてることに気付いた
- テンプレ化したほうが過去のプロジェクトのコードを漁る手間がスキップできる、と判断
- 次々プロジェクトこなすときに必要だったものが出発点
- しばらくしたらDivya Manianもプロジェクトに参加してくれた
- v1.0をリリースでは、他の人も役立つを思ってくれるテクニックを盛り込んだ
- 最近まで、インラインでドキュメントつけてた
- githubにソースをホストしてる
- 公開後github経由でたくさんフィードバックもらった
- ここはこう調整するともっと良くなり、opera9.6のバグのよい説明にもなる、とか
- html5 boilerplatesのトピックごとに色々ディスカッションが生まれてる
- ディスカッションの成果が盛り込まれてる
- ディスカッションには、優れたフロントエンドエンジニアも参加してる
- 更新履歴、議論、過去の問題等々を辿れる
- コミットログは詳しく書いてる。変更の根拠がわかる
html5 boilerplates
>|||
|
- Q：
- html5 boilerplatesをDLしてファイル開いても「何これ？」となる初心者向けに
- ファイル見た人が最初に目にするIEのconditonal commentsから
- A：
- conditional comment。洗練さとかセクシーさとかの対極
- ie対策はまだ必要
- ie6-7は無視出来るくらいシェア落とした
- ie8はまだシェアもってる
- css実装にバグがあって対処しないといけないケースは、開発現場で目にする
- cssハックはドキュメントされない
- cssハックでブラウザのcss実装のバグに対応するのは、後々面倒に
- conditional commentsはある意味ファーストクラスの手法
- ベンダが提供してる
- ie7だけ、ie8だけ，等々。ieだけに適用されるスタイルを書くために提供されてる
- vender specificなスタイルを書くのを出来るだけ避けたいとみんなcss書いてる
- 明示的に高さと幅を指定してるときは、vender specificスタイルを回避するのが動機にある
- vender specificなスタイルを書かざる得ない場面は出てくる
- そんなときにconditional commentsは役立つ
- Q：一番お気に入りの思う機能
- A：
- protocol relativeなurl記法。プロトコル部分を抜いたURLの書き方
- "//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"
- ajaxian,stackoverflowにも載ってた
- httpsでもhttpでもどっちでも読込できる
- この機能知らない人から「typo：httpが抜けてる」とpull requestもらったことあり
- ページがhttpのときにhttpsのリソース読むと、オーバーヘッドが少しある。
- ローカルでサーバ立てずにフロントエンド開発してるとプロトコル部分を「file://」と解釈されてしまうのが注意点
- ローカルでサーバー立てて開発すれば解決
- Q：ここ数年でフロントエンド開発で起きてること。仕事が複雑になってきた。いい傾向 or not？
- A：
- ２つのことがここ数年で起こってる
- １つは、レガシーなブラウザが視界から消えた
- ie6死亡、ie7はシェア1%
- ie8はシェア持ってるが、ブラウザの性能アップした
- レガシーなブラウザへの対策がフロントエンド開発で悩みの種だった
- もう１つは、沢山の新機能が登場した
- 過去3年で沢山の機能がブラウザに追加されてる
- 追加された新機能をどう使うか、組み込んでいくかに、頭を使ってる状態
- 例えばcss transition
- css transionを実務で使う時、非対応ブラウザ向けにfallbackも実装する
- 自分はfallbackしたほうが良い派
- フォールバックとして何を提供するかを決めるのは、少し大変
- 例えばcss transionを使ったサイト作ったとして
- modernizrで非対応ブラウザ検出して、非対応ブラウザ向けにjqueryでアニメーション実装、とか
- 常にやるべきことじゃない
- だからhtml5 pleaseというサイト作った
- HTML5 Please - Use the new and shiny responsibly
- フォールバック、クロスブラウザ対応のためのガイド
- polyfillの使いどころとかを機能別に羅列
- Q：フォールバックシナリオの安全牌ある？
- A:
- polyfillを旧いブラウザに送りつけるのは好きじゃないが
- 常にこうしたほうがいい、というのはない。いつも複雑で込み入ってる
- かつては、「あらゆるブラウザで見た目を揃える」、「機能が足りないブラウザにはテキストだけ表示」とかあった
- いろんなデバイスがあってサイトの見え方も複数ある状況も生まれて、状況をさらに複雑にしてる
- 一つは気にしないこと
- 使いたい機能を使えるブラウザにユーザが乗り換えるように働きかけていく
- 乗り換えてくれれば、フロントエンド開発の苦しみは減る
- 高い乗り換え率を弾きだした場面も過去にあった。ブラウザの高速化は乗り換えを大幅に促進した
- Q：
- フロントエンド開発の敷居がぐっと上がってる
- 今は、フロントエンド開発が沢山のステップを経るようになってる
- いくつものツールをつなぎあわせて開発するのは面食らうね、ブログに書いてたのを読んだ
- 今後シンプルになっていくべきか
- なんかオールインワンなものが出てくるべきか
- 全く別のかたちになるか
- A：そこでYeoman
- Addy Osmaniらと最近やってるプロジェクト
- すぐれたwebアプリのビルドに必要なツールは沢山ある
- たくさんあるツールをまとめる役割を果たすのがyeoman
- yeomanが対象とするツールは色々
- 大抵のフロントエンド開発で必須になるツールセットのベースラインを打ち出す
- このベースラインは受け入れられつつある、と感じてる
- 多くの人がエディタとかソース管理といった開発環境について同僚と話しをしていない
- 自分は話をするのが好きだし、同僚の開発してる所を眺めるのが好き
- 仕事の効率があがったり、快適になったりする
- 隣に座って「今のどうやってやったの」とかやってる。みんなこういう時間をもっと持ったほうがいい
- Q：なんだかよくわからないけど、使えればOKという人もいるが、そうでない人もいる
- A：良い質問
- Nicolas Gallagher
- html5 boilerplateのプロジェクトリードやってる
- boilerplateはみんなのベースラインになるようにしてくべき、とnicholasは考えてる
- webアプリ、webサイトのベースライン
- 安定したプロジェクトになったのは、余計なものを足さず、今取り組んでる問題とは別の問題を解こうとしたりしてないから
- jquery初期からよくみかける話
- jqueryの勉強とjsの勉強を同時にやるべき？js勉強してからjquery勉強したほうがいい？
- 「実際にjqueryとjsを同時に学んでる」と、いつも自分は答えてる
- 勉強を始めた人は、Math,String,Arrayのメソッドはjqueryいくら勉強してもわからない
- でも、込み入ったDOMの操作の諸々を延々学びたいとも思ってないはず
- ツールを使うことは一種の上手な勉強のやり方と考えてる
- html5 boilerplateを使ってると、色々ドキュメントを読むことになる
- ドキュメントを読みながら、「なんでこうなってる？」とか分からないことが出てくるはず
- でも、わからないことが出てきても、boilerplateを使うことはできる
- ある時、わからないことについて勉強したいけど、ストレスなく勉強したいと思うかもしれない
- 勉強したいと思った時にツールがある
- 仕組みを理解するのは大事だと思う
- 自分の場合だと、ブラウザの仕組みについて深く理解したいと今思ってて、ブラウザは本当に複雑だな、と思ってる
- かといって、「みんなぶれウザの仕組みを深く理解すべき」と説いて回る気持ちはない
- 現時点でのブラウザへの通り一遍の理解でOKでいいと思う
- 要はバランス
- 自分が使ってるツールの仕組みについて深く理解してることは、ツールを使う場面でもとても役立つ
- でも、仕組みが全くわからなくてもツールを使っていいはず
- Q：そろそろまとめに。なんかアドバイス
- A：
- 振り返ると、jqueryのIRCに参加したのは自分にとって変化のきっかけになった
- もちろん、IRCは超オタク臭い
- IRCに参加し、IRCでアクティブに活動し、jquery開発に参加し、jqueryチームにも参加し、jqueryプロジェクに長いこと参加し続けてる
- それもこれもIRCに参加してIRCで色々教えたり助けたりしたのがきっかけ
- フロントエンド開発で人助け
- そこから学べることはとても大きい。実際に自分がそうだった
- 自分はオススメしたい
- jquery書いてる人たちのグループに出会い、js書いてる人たちに出会い、20人くらいのグループを作っていった
- IRCで今自分がやってることを話をして、競争みたいなものも中にはあったが、協力して沢山のこと、プロジェクトをやった
- movethewebforward.orgとかhtml5pleaseとかはそういうプロジェクトからのアウトプット
- 自分以外の人たち劣等感を感じることなく、お互いに助け合うソーシャルなコミュニティに参加すると、自分に力をくれる
- 学んでるときに楽しむことができるが大事
- 学びながらデモを作ったり実験をすれば、クールな機能・使ってみたい機能についての経験値が増える
- 自信を持って上司を説得して使いたい機能を実戦投下できる
- 「なぜこれを使わないとダメ？その根拠は？」
- 「OK。自分はちゃんと使ったことがあります。懸念されるようなものではありませんし、バッチリ動きます」
- 自信を持って上司を説得して使いたい機能を実戦投下できる
- Q：要するに、とにかく手を動かしてクールなことをやってみる、それをシェアする、でOK？
- A：Yes
Joshua Green「大量の献金を獲得したObama陣営のメール最適化」
- businessweek.com 2012.11.29の記事
- 更新：数字の桁がおかしかった
- 690万ドル ＝＞6.9億ドル。など
- via id:okemosさん
- 更新：I will be outspentの意味の取り違い
- 「支出が大杉」じゃなく「金遣いで負けてる」
- これもvia id:okemosさん
The Science Behind Those Obama Campaign E-Mails - Businessweek
- 大統領選でObama陣営はメールをa/bテスト使って最適化
- オンライン経由の献金の大半をメールから獲得
- 件名別成績とか
- 大量に送りつけても実害ゼロだと分かったとか
- 親父から「スパムだろ」と文句言われたくらいだ、とか
- 「見た目最悪」なデザインが一番献金してもらえてショックだった
等々を、中の人への取材を元にまとめててわかりやすい
以下斜め読んだ内容
- 今回の大統領戦選挙の特徴の１つは、Obama陣営が手がけたメール戦略
- Obama陣営が送ってくる件名がちょっと変わってた
- 「夕食でもどう？」
- 「公式には終了」
- 「こうせなアカン、ってことやないから」
- 「Wow」
- daily showのjohn stuartは番組でネタにするくらい
- だがObama陣営のメール戦略は大成功
- オンラインでの寄付金は、690万ドル。その大半があのメール経由
- 選挙期間中は話題になってるメールについてObam陣営は情報出してくれなかった
- 選挙後に裏側を見せてくれた
- アナリストからなる大規模チームが手がけた厳密な実験が、魅力的な件名を突き止めた
- Amerila Showalter
- digital analyticsチームのディレクター
- Showalter曰く
- A/Bテストの対象は、件名とメールの書く（献金の）金額。だけではない
- メッセージ本文、フォーマットもA/Bテストの対象とした
- 18パターン用意してテスト。成績良いのを選び出す
- それから1000万人以上いるメール購読者に一斉送信前にテスト
- Toby Fallsgraff
- e-mailチームのディレクター
- 20人のライターを部下に持ってた
- fallsgraff曰く「これはと思うものを見つけたらメールに採用した」
- A/Bテスト開始直後に見えてきた事実
- カジュアルな文体が大抵好成績
- Fallsgraff曰く
- みんなのいつものメール受信箱でみかけるような件名が、成績良かった
- 「Hey」が選挙期間通して一番成績良かったフレーズ
- A/Bテスト開始からしばらくして好成績フレーズ
- 2012年6月頃
- Fallsgraff曰く
- 「金遣いでは負けるね I will be outspent」
- 「金遣いでは負けるね」の成績をbusinessweek bloomsbergがデータ調べた
- 件名18種類の中で成績は一位
- 獲得献金2.5億486.6万ドル
- （補足）2位以下の成績もミニinfographicとして載せてる
-
- ２位「ぞっとした数字」
- 1.9億1137.9万ドル
- ２位「ぞっとした数字」
- ３位「僕達の行動を信じてるくれてるなら・・・」
-
- 9118.06万ドル
-
- ４位「最終案内：michelleと私と一緒にやりましょう」
-
- 8946.44万ドル
-
-
- メールチームの予想を裏切る結果が出続けた
- メールチームのメンバーはテスト前に色々予想を出して臨んだ
- Showalter曰く
- 全然予想通りにならなかった
- だから、テストし続けないといけなかった
- 「見た目最悪」系が常に好成績で、ショック受けた
- 文字サイズをアホみたいに大きくしたリンク、手間かけた「献金」ボタン、ただのテキストリンク、etc..
- たどり着いた結論は、「注目してほしい箇所には黄色で強調」という外見最悪なやつ
- 予想外の事実
- 荒っぽい言葉をジャブで入れるとクリック稼げた
- ただし効果は一過性
- Showalter曰く
- 「奇をてらう」路線はストップ。仕切りなおした
- 直感に反する重要な洞察も出た
- これは将来の選挙戦にも活かせるもの
- メール受信量を増やしても意外とみんな心が広い
- 登録解除は、全然無かった。
- Fallsgraff曰く
- ってことで、気にせずメール大量投下
- ライター２０名使ってフル稼働
- 不快になる人。中にはいた。例えば、自分の親父。直接文句言われた
- この記事まとめ
- オバマ陣営のメール献金チームは「心を掴むメール件名」を追求した
- 数百回テスト繰り返した
- 「Hey」が一番お金を集めれた。数億ドルの献金を獲得した
Guy Podjarny「HTTP Pipeliningはwebを速くも遅くもしない」
Guy's Pod 2012.6.26のブログエントリ
Guy's Pod » Blog Archive » HTTP Pipelining – Not So Fast…(Nor Slow!)
- http pipeliningサポートが普及した
- でも全然サイト高速化に貢献できてないこと
- なんで速くなってないのか調べた（サイトの作りが効果を相殺してる）
- グラフ入りで詳しく書いてるエントリ
spdyのベンチマークの姉妹編のようなエントリで、http pipeliningとspdyが持てる力を発揮できてない理由は共通してる、など勉強になった
以下斜め読んだ内容
http pipelinig
- 昔から知られた最適化テクニック
- 最近モバイルでもブラウザでも広く使われつつある
- chrome/fxはデフォルト有効になった
http pipeliningで速くなったと期待して軽くテストしてみた
- 全然速くなくてびっくりした
- びっくりしたので本腰入れてテストした
- テストして学んだことをまとめた
いきなりまとめ（時間ない人向け）
- http pipeliningはサイトを高速化しない。が、遅くもしない
- ネットワーク速度、ブラウザ、サイト。色々変えても結論は変わらない
- 効果ゼロな理由は現状のwebサイトの設計の仕方にある
- 読み込むリソースがたくさんのドメインに分散させている
- フロントエンドの設計が筋悪。スクリプトが読込/ブロックしてる状態を放置してる、とか色々
http pipeliningのテスト結果は、自分のspdyのテスト結果にも通じるものあり
- Guy's Pod » Blog Archive » Not as SPDY as You Thought
- Guy Podjarny「SPDYはみんな思ってるものと違う」 - 以下斜め読んだ内容
- spdyが期待されてるほど効果薄い原因と共通してる
テストその１：firefox13。pipelinineオン／オフ。色々なネットワーク環境
- テスト前に思ってたこと
- 遅いネットワーク（レイテンシ高いネットワーク）でpiepeliningは真価を発揮する、はず
- テスト対象。alexaランキングの上位500サイト
- テスト・ツール：WebPageTest
- ブラウザ：Firefox
- 回線速度：DSL、ケーブル、ファイバー。ツールでシミュレート
- レイテンシ：2-4段階で変えた
- 結果
- グラフにした
- x軸：レイテンシ(ミリ秒)
- 読込時間に変化なし：パイプラインon/offで比較して読込時間変化なし
- DSL
- ケーブル
- ファイバー
- pipeliningの実装は複雑
- 概念はシンプルだが実装は大変
- 実装のポイントを前に書いた
- 実装のポイントをおさらい
- サーバ側が実装してるかどうかを検知する仕組み
- サーバの要件
- http/1.1
- keep-alive
- サーバの要件
- 多くのブラウザの挙動
- コネクションの度にpipeliningサポートをチェックする
- リクエスト送ってレスポンスがhttp/1.1かつkeep-aliveかどうかチェックする
- チェックをパスしてからpipeliningオンにしてサーバ通信開始する
- コネクションを作るたびにチェックする
- operaの挙動
- サーバー単位でpipeliningをチェックする
- keep-aliveでレスポンス来たら「pipelinigオンでOK」と判断してpipeliningオンにする
- エラーも増えるが、pipeliningオンにできる場面も増えるアプローチ
- リクエストを分配するモデルをどうするか
- ブラウザが4リクエストを２つのコネクション使って出したいとき、リクエストをどうやってコネクションに割り振るか
- ２つやりかたあり
- 分配してからリクエストを出す
- リクエスト1と2を１つ目のコネクションに割り振り、リクエスト3と4を２つ目のコネクションに割り振ってから通信開始
- 都度リクエストを分配する
- コネクションの上限数に到達してからpipeliningがオンになる
- コネクション１にリクエスト１、コネクション２にリクエスト２を割り振って通信開始
- 開始してから、リクエスト3をコネクション１に、リクエスト4をコネクション3に割り振って、第二弾のリクエストにする
- 去年ブラウザをテストした時。最大コネクション数に達してからpipeliningがオンになる流れ
- サーバ側が実装してるかどうかを検知する仕組み
- fx13の実装
-
- コネクションごとにpipeningサポートをチェック
- 最大コネクション到達を待たずにpipelingスタート
- コネクション１にリクエスト1,2を割り振るやつ
-
- 自分の理想
- サーバ単位でサポートチェック、最大コネクション到達後にpipeliningスタートの組み合わせ
- fxの中の人も自分と同意見になっていった
- fx14でテコ入れ入って、fx16で新しくなった
- fx16
- piepeningの実装は複雑
- 自分た書いた２つのポイント以外の要素も追加されてる
- テストみてもpipeliningの実装として改善してる
- chrome
- pipelingオンはコマンドライン経由
- 実装もfirefoxと違う
- fx13,fx16,chromeでpipeliningのテストした理由
- 実装が異なるから
テストその２：firefox16、chrome
- テスト１と違って1/5の規模でやった。諸事情で
- alexa上位100サイトで実施
- 回線はfiberのみ。上り5Mbps。下り20Mbps
- レイテンシは、300ミリ秒のみ
- 結果はほぼテスト１と同じ
- 平均値と中央値の差分も1-2%以下だから無視できる
- 補足するとfx16はnightlyビルド。なので正式版じゃないのでバグとか機能制限とかあるかも
- pipeliningモデルの実装がfx13とくらべて大きく変わったのは、waterfallの図を見比べれば一目瞭然
- fx16（pipe=オフ）、fx13（pipe=オン）、fx16（pipe=オン）
pipeliningがオンになった頻度
- pipeliningがオンになっててもpipelining通信が発生してるかどうかとは別
- fx13
- 初回12リクエストはpipeliningされなかった
- ドメインあたり13以上リクエストあるときにだけpipelingの恩恵を得る
- テストツール(=webpagetest)はpipeliningと相性悪い
- pipeliningされてリクエストを取りこぼしたりしてる可能性がある
- waterfallの図みても取りこぼしをもいつけることができない
- pipeliningオフの平均リクエスト数のデータと比較してpipeliningされたリクエストの比率を出した
- fx13
- リクエスト数：off=79、on＝68
- pipeされたリクエスト数：11。13.9%
- fx16
- リクエスト数：off=78.6、on＝65.9
- pipeされたリクエスト数：12.7。16.1%
- chrome
- リクエスト数：off=77.8、on＝65
- pipeされたリクエスト数：12.8。16.4%
- 全てのリクエストがpipeliningされてない
- スポットで手動でもテストを行った
テストその３：fx16のbrute foces設定を使う
- fx16,chromeのpipelining実装はとても複雑
- 履歴からpipeliningをオンにしたサーバなのかどうかとかから学習するような機能もある
- fx16のbrute forces設定
- network.http.pipelining.aggressive
- pipelining通信を最大限行う設定で、フォールバック機能付き
- alexa上位100サイトでfx16をbrute force設定で追加でテストしてみた
- 結果は前(brute forceオフ)と大差ない
- pipeliningオフ時と比べると、平均値は3%遅く、中央値は8%遅い
- pipelining利用頻度は35%まで上がった
- brute force設定オンにしてpipelining利用率最大化したら結果
- 却って遅くなったサイトが出てきた
- about.comは2.5倍遅くなった
- WebPagetest - Visual Comparison
- 速くなったサイトもあり、だいたい10-15%高速化
- 却って遅くなったサイトが出てきた
- brute modeオンはまだ適切じゃない
- ブラウザがpipeliningオンにすべきかどうかまで学習できてるわけじゃないから
- 最良の結果が出た所だけとってもpipeliningは1%の高速化にとどまった
なぜ高速化しないか
- ありそうな説明
- 読込が遅いリソースが混じってると、順番待ちしてるリソースの読込がブロックされた状態が長くなる
- 読込が遅いリソースとそうでないリソースを自動判定する仕組みは実現が難しい
- 自分はこれが原因ではないと思ってる
- pipelining機能を活かすようなウェプページになってないのが原因
- 16%のリクエストでしかpipeliningが実際に使われてない
- brute force設定オンでも35%くらい
- リソース別にみると、jsやcssの読込はpipelingほとんどされてない。画像系がpipeliningされてた
- 画像のようなサイズ大のリソースのpipeliningはそれほどインパクト大きくない
- brute force設定オンの時にパフォーマンスが改善したサイトがいくつかあった
- 改善するサイトの数はどんどん増やしていけると思う
- pipeliningが実際に使われる頻度が低い理由
- リソースが多数のドメインに分散しすぎ
- 平均で18ドメイン使ってた
- 各ドメインは1-2リソースしか読み込まれないからpipeliningが利用される機会がない
- フロントエンド実装にボトルネックあり
- cssの@importやjsが他のリソースの読込をブロックしてる状況
- pipeliningはこの状況を改善するものじゃない。引き続きブロックされ続ける
- pipelining実装も万全じゃない
- proxyなどがpipelining通信を邪魔する可能性にブラウザが備えないといけない
- pipeliningが利用可能かどうかをブラウザの検知機能がもっと良くならないといけない
- リソースが多数のドメインに分散しすぎ
まとめ
- 理論上はpipeliningは有益
- webはプロトコルに最適化していく途上
- 現在のサイトは複雑な怪物で、プロキシは役割から外れた振る舞いする
- Subbu Allamarも似たようなこと言ってた
- spdy利用は状況を改善策として指摘できる
- が、指摘したボトルネックへの解決策ではない
- リソースの複数ドメインへの分散や筋の悪いフロントエンド実装は、プロトコルで解決できるものじゃない
- pipeliningの力を存分に引き出すために必要なこと
- １コネクションで複数ドメインとの通信を多重化
- pipelinng利用できるかどうかをサーバから情報を通知するような仕組み
- ヘッダをうまく使う形になるはず
- mark nottinghamがhintingというスペックのドラフト書いてる。akamaimもいくつかのproposalをhttp/2.0に送った
- draft-nottingham-http-browser-hints-03 - HTTP Browser Hints
- draft-safruti-httpbis-connection-reuse-01 - Connection Reuse for Multiple Hostnames and for Fast Redirect
Guy Podjarny「SPDYのベンチマークに寄せられた声へのリプライ」
Guy's Pod 2012.6.20のブログエントリ
Guy's Pod » Blog Archive » SPDY Benchmark – Feedback Highlights
以下斜め読んだ内容
- 前に出したエントリ。反響たくさん
- Guy's Pod » Blog Archive » Not as SPDY as You Thought
- Guy Podjarny「SPDYはみんな思ってるものと違う」 - 以下斜め読んだ内容
- フィードバックにはいいものもあった
- 自分（＝Guy）がやったテストの追試
- 高速化のためのアイディア
- まとめて寸評付けてみた
- Q：ウェブサイトはhttpに最適化されてるから「spdyは言うほど速くない」という結論が出たんじゃ？
- A：
- 一理ある。が、自分のテストの結論に影響無し
- http時代の高速化tipsであるdomain sharding
- spdyと相性悪い
- domain shardingへの対策
- 自分も取り組んだ経験あり
- 例。リソースをページと同一ドメインに引越したり
- だが、引越しは全てを解決しない
- domain shardingは未だ使われ続けてる
- 自分のテストで出した結論に影響はない
- テスト対象にしたサイトが使ってるドメイン数は、平均18個
- 自社管理ドメイン（1stパーティドメイン）はわずか2-3個、残りは外部サイトドメイン（3rdパーティドメイン）
- Q：理想は、サイトがspdyに最適化すること
- A：
- spdy時代特有の高速化tipsは今後出てくる、かも
- たいていはhttpの場合でも有効なものが多い
- domain shardingはhttp時代限定のtips。例外的存在
- 理想（みんなspdy）への過渡期として、http/spdy両方対応の時期がある
- http/spdy両方対応できるサイトは、それなりのインフラ持った所じゃないのと難しく、少数派だと
- 限られたサイトだけがspdyのメリットを存分に享受
- Q：テストではCDN〜オリジンサーバ間はhttpだった。それではspdyの真価は測れない
- A：
- テストおさらい
- 対象サイト群がspdy対応のリバースプロキシーをフロントに置いてる、かのような状態にした
- リバースプロキシ役を演じたのがcotendo cdn
- エッジサーバ（cdn）とオリジンサーバ（対象サイト）の間の通信はhttpだけ
- cdnのリージョンは東海岸（new york）
- オリジン〜エッジサーバ間の通信がボトルネックになる？
- だからクライアント（ブラウザとか）〜エッジサーバ間がspdyだとしても効果が相殺される
- という想定をしてる人がこういう疑問出してくる
- この懸念は的外れ。３つ理由ある
- 1。間にcdn入れたから遅くなるとかありえない
- cdnはクライアント〜オリジン間の通信高層化のための技術
- エッジ〜オリジン間のリクエスト多重化とか色々高速化するためのテクニックが投下されてる
- akamai、cotendoとかに限らずcdn屋がみんなやってること
- cdnは実績積み重ねてる
- 2。レイテンシと帯域の平均を比較すれば、オリジン〜エッジサーバ間の方が圧倒的に上
- モバイルネットワークと比較すると、その差は一番大きくなる
- テストによれば、モバイルネットワークでもspdyは高速化にそれほど貢献してなかった
- 3。クライアント〜エッジサーバ間の平均読込時間は、環境によって大きく変わる
- ケーブルはモバイルの半分以下のレイテンシ
- cdn〜オリジン間はクライアント〜cdn間がケーブルだろうとモバイルだろうと一定
- 1。間にcdn入れたから遅くなるとかありえない
- cdnを間においてるからspdyの価値を測りそこねてるという言い草はナンセンス
- cdn〜オリジン間がspdyだったとしてもテスト結果は変わらない
- テストおさらい
- Q：1stパーティのリソースはcdnに全てキャッシュした状態でテストしないとspdyの真価は分からない
- A：
- つまり、エッジサーバ〜オリジンサーバ間の通信が実質ゼロ状態でテストすること
- 懸念に同意できないが、試してもいいテスト方法
- 現実のケースには無いようなバイアスを色々持ち込むテストでもある
- cdn〜オリジン間の通信がほぼゼロなんだから、現実よりもリソース読み込みが当然速なった状態でのてスト
- spdyのパフォーマンスのテスト結果の信頼性を損なう
- リソースの読込がどれとっても高速なんだったら、リクエスト多重化の効果は軽減するから
- Q：spdyファーストなサイト設計がデフォルトになれば、3rdパーティのドメインからのリソース読込は消え去るのでは？
- A：
- そうなってほしいが、そんな兆しは見えません
- 益々3rdパーティドメインからのリソース利用は増えてる
- ソーシャルプラグインとか3rdパーティのドメインのリソース利用がサイトを遅くする元凶なのは一目瞭然
- ビジネス上の理由で3rdパーティのリソースはサイトに組み込まれてる
- 3rdパーティのリソース利用の増大が現在の趨勢
- spdy（http/2.0でもいいけど）はこの趨勢への対応策を含んだ設計になっていくかな、と感じてる
- 有りそうもない流れを期待しないspdyの変化
まとめ
-
- 誤解があるかも。自分はspdyラブ
- みんながあらゆる手立てを講じてspdyをプッシュすべき
- spdyが力を発揮できない局面では発揮できるように障害を取り除くべき
Christopher Rogers、Namil Kim「lineもspdyサポート（その１）」
NAVER Engineers' Blog 2013.1.11のエントリ
Adopting SPDY in Line – Part 1: An Overview « NAVER Engineers' Blog
lineがspdyサポートしたよ、というシリーズものエントリ第１弾
場合によっては非sslでもspdy使ってるよ、とか、tlsのNPNは使わないことにしたとか、概要的内容
以下斜め読んだ内容
- 自分らはux向上頑張ってる。現在進行形
- line＝コミュニケーションツールだとすると。。。
- メッセージ送受信時間を短縮できれば、ux改善、と言える
- これまでの送受信はずっとhttp
- httpは普及してる技術
- シンプルなrequest/responseモデル
- tcpコネクションの上で送受信するモデル
- httpの欠点
- リアルタイム通信向けに設計されてないhttp
- メッセージングサービスにhttpが不向きな理由あれこれ
- リクエスト多重化がない
- FIFO無視したレスポンス受信がない
- 新規メッセージ受信のために問合せを都度やる
- リクエスト増えればバッテリー使う
- これまでlong polling多用してきたline
- long pollingは専用にtcpコネクションが必要
- req/res頻度増えれば、httpヘッダの送受信のサイズは肥大化
- 冗長なhttpヘッダを同じコネクション使って何度も送ってる
- user-agentは変わらないのに
- 他にいいのないか調べた
- http/long-pollingの問題を解決するもの
- spdyは求めてたものに近かった
- spdy使うことにした
- 車輪の再発明はしなかった。これはメリット
- spdyが廃れなければ、spdyとspdy関連技術からもたくさんメリットを受け取り続けれる
- spdyおさらい
- 新しいブラウザのためのプロトコル
- googleが開発
- http2.0に取り込まれることが意図されてる
- lineが恩恵受けるspdyの機能
- リクエスト多重化
- fifo無視したレスポンス受け取り
- ヘッダ圧縮。辞書使って圧縮効率アップ
- ping使ってコネクションが生きてるか確認できる機能もあり
- lineでのspdyの使い方は色々
- 暗号化オフでspdy使う時もある
- tls+spdyで行くときもある
- NPNは使わないことにした。理由は２つ
- １つは、ブラウザなら得られるメリットがlineの場合なかった
- ブラウザからはホスト先がspdyサポートしてるからわからない
- NPM使うとコネクション確立で発生するラウンドトリップの総数を減らせるメリットあり
- lineの場合はクライアントはspdyサポートの有無をチェックする必要なし
- NPN使った利用できるプロトコルのチェックはlineには不要
- もう２はアプリのアップグレードが必要な点
-
- NPN使うならアプリのOpenSSLのアップグレードが必要
-
- ポートスキャンもspdyと一緒にサポートした
- 広く使われるポートでもブロックしてるネットワークがある
- 世界中のキャリアでどのポートが使えるかをサーベイした結果、使えるポートの候補はごくわずかだった
- 一応フォールバックとしてhttpでポート80番での接続もサポートしてる
- lineの自作のapiゲートウェイサーバ
- 自分らはLEGYと読んでる
- Line Event-delivery GatewaY
- legyはerlangで書いた
- LEGYがspdyをサポートしてる
- 2012.10.16からspdyをサポート開始
- 導入後に出た問題
- 一定時間超えるとLEGYのメモリ使用量が跳ね上がる現象
- ヘッダ圧縮に使う辞書のサイズと辞書の状態が原因だった
- コード最適化して解決済
- たまーに、クライアントへ送るデータが一部ロスする現象
- 特定ネットワークでのみ起こってて、間にあったプロキシが邪魔してたことが分かった
- このネットワークのポートは使わないことにした
- それ以外は問題出てない
- 一定時間超えるとLEGYのメモリ使用量が跳ね上がる現象
- lineでのspdyサポートはうまく行ってる
- 必要コネクション数を減らせた
- メッセージ送受信の高速化
- 変化し続けるネットワーク環境への適応をこれからも進める
- その２では、spdyサポートの詳細を書く
Jonathan Cutrell「Obama陣営のエンジニア／デザイナーチームの一人に一問一答した」
Nettuts+ 2012.11.26のブログエントリ
Chatting with Obama For America’s Director of Frontend Development: Daniel Ryan | Nettuts+
- 2012年大統領選挙のObama陣営のネット戦略を担うエンジニア・デザイナーチームの中人へチャットでインタビュー
- 使ったツールから、教訓とか色々書いてる
- jekyll,cssプリプロセッサ、github、高速化ツール、ec2,s3,rails,django,magengo
- モバイルはトラフィック多い（全体の1/4）けど献金はほぼゼロ、とか
- 前回(2008年)の選挙のときは肝心なときにシステム障害を起こした件
- それを踏まえて今回はどうやったか
- Romney陣営は敵陣営の失敗から学ばなかった（肝心なときに同じ障害を味わった）
知らなかったこととか書いてて勉強になった
以下斜め読んだ内容
- Q：デザイン・開発チームにとって、大統領選期間の最大のチャレンジ
- A：
- たくさんのプロジェクトが毎日同時に動いてること
- いろんな要件がチームにどんどん飛び込んできた
- 資金集めだったり、支持者集めだったり、投票所への有権者の誘導だったり
- デザインは、支持者の意見、陣営のポリシー、法律等々を見て調整
- 数日、数時間で新規プロジェクトがスタートしてる
- Q：A/Bテスト、データドリブンな意思決定。どう使ったのか
- A：
- Obamaチームはデータドリブンとよく言われてるが、誇張されてる
- データドリブンなアプローチもあれば、そうでないもの色々組み合わせてやってた
- a/bテストツール：optimizely
- 毎日テストを走らせ、週次レポートでは、毎回ベストプラクティス、（PDCAの）Actionも載せてた
- 例えば献金での実績：前回比で125万ドル増加を達成
- Q：スタックの構成
- A：
- Q：使ったオープンソースのツール。プロダクション環境、デプロイ時のプラン
- A：
- jsのメインライブラリ：jquery、modernizr
- jqueryプラグイン：Fitvids.jsをよく使ってた
- テンプレートエンジン：mustache
- レスポンシブデザイン：やってみた。選挙陣営のサイト初じゃないか？
- cssプリプロセッサ
- less
- ツールはcodekit
- lessはチームのエンジニアに教えてもらったその日のうちに、less導入を完了させた
- 2011年10月のサイトテコ入れやってる時
- less導入のスピードの速さ
- 何かいい方法があればすぐ変えるような体制でやってたから
- git使った。ソースはgithubにホスト
- githubの中の人が書いてるgithub活用法をわりと忠実に守ってやってた
- How GitHub Uses GitHub to Build GitHub
- ローカルでブランチを切る
- レビューとテストできる段階になったらレポジトリに
- gitタグつける。レビュー、テスト、ステージング
- コードレビュー、QAやる
- masterブランチへプルリクエスト
- プルリクエストのレビュー。リードエンジニアとシニアエンジニアがやる
- 静的ファイル；S3にホスト
- サーバーサイドのコード；一旦DevOpsチームにデプロイリクエスト出す
- devopsチーム；puppetとgippetto使ってapk作ってた
- 小規模なコード変更：オンザフライでデプロイ
- 大規模なコード変更；新サーバクラスタにまずはデプロイ。内部テストしてから、古いクラスタと置き換え
- いつもこのフローでやってたわけではない
- 2011年8月にチームに参加したとき、dev環境、ステージング環境とかもなかった
- ステージング環境の導入はすぐに終わった
- cmsだけはローカル環境の構築とメンテがずっと大変なまま終わりを迎えた
- Q：サイトデザインの作り方
- A：
- デザインチームからたたき台
- エンジニアチーム、デザインチームそれぞれがアイディアを出してた
- データをもとに絞り込んでた
- クールなアイディアよりも結果出せるかどうか
- すぐれたデジタルエージェンシーの体制に近い
- PM、リーダー級メンバーが集まってキックオフ
- 方向性を決めててく、キックオフのメンバー間でフィードバック出し合ってまとめてく
- プロジェクトの中身がまとまったら、プロジェクトの中身を細かくしてく
- デザインはカンプ作ったり、エンジニアはプロトタイプ作り。これを繰り返す
- テストに回す
- 2012年夏ごろは１０以上のプロジェクトが同時に進んでた
- Q：ロムニー陣営は技術的問題を色々抱えてた。サーバー落ちたり。ハードウェア故障とか。Obama陣営はこの手の問題を回避に成功したきっかけ
- A：
- 自分（＝Daniel Ryan）は今回の選挙がはじめて。前回は中の人じゃなかった
- 前回の経験者がたくさんいた
- 2008年選挙のときにObama陣営のシステムで一度失敗を経験してる
- 投票者の動向をリアルタイムモニタリングシステムでHoudiniと呼ばれたやつ
- Romney陣営は今回の選挙では前回Obama陣営が失敗したシステムとよく似たシステム（Orcaと呼ばれた）を使ってた
- Orca Failed; but So Did Obama's 2008 Version of the Same - Ben Jacobs - The Atlantic
- 失敗をふまえ単一障害点をもつシステムを選ばなかった
- 冗長な構成にした
- 例えば支払いシステム
- Q：レスポンシブデザインは役に立った？モバイルファーストでデザインした？
- A：
- jquery mobileベースで最初開発。テンプレートは２つだけ
- テンプレート２つだけで回してるとスケールアウトできなかった
- トラフィックの1/4はモバイル経由
- モバイル経由の献金はほぼゼロ
- 2011年秋に大規模なテコ入れ
- モバイルファースト、レスポンシブで行くのが当然という感覚だった
- みんなゼロから勉強した
- モバイルファーストでは、横幅(width）でなく、低帯域にフォーカスするべき
- 320px幅のデザインから始めるのがモバイルファーストじゃない
- 低帯域環境でのエクスペリエンスから取り組むのがモバイルファースト
- モバイルファーストは包括的なもの
- コンテンツ作成では、ユーザフレンドリーにすること
- デザインは柔軟にしていくこと
- コードは量を切り詰めること
- Q：大規模なデプロイから一番学んだこと
- A：
- 有能なエンジニアの獲得が超大事
- 効率性の追求をできるエンジニアが構成するスタックの全てのレイヤーで必要
- スケールアウトが必要なときにその時点のチームでは力不足だった
- 有能な人が必要なことにすぐ気づいて雇うことができた
- Q：オバマチームのマネージメントの仕組み
- A：
- プロジェクトごとに変わる
- 献金、支持者集め、投票所への誘導。これが３大ミッション
- オンライン関連だと、デジタル部門、テック部門に別れるが、相互連携はかなり多く、自分（＝Daniel）は調整役として主にやってた
- obama陣営の中で、オンライン系チームは分離された形で機能してたが、陣営のオフライン／オンラインのおぼあらゆる局面に関係してた
- 次回（2016年大統領選挙）では、陣営の体制は今回までのヒエラルキーのある構造から、マトリックス構造に変わっていく、と予想してる
終わりに
- Danielのtwitter/blogで追加情報ある、かも
コメント欄
