Open Web Platform Daily DigestのRSS
便利だが。。。
野良rss
http://webplatformdaily-org.ap01.aws.af.cm/feed
- 冒頭の所は削って、日付入ってるとこだけにしてる
- かなり適当
- appfog使ってみた
- appfogはdashboardだけ超重い
- herokuにしようかと思ったが見送った
- /usr/bin/heroku以外にheroku toolbelt入れるやり方がすぐに分からなかった
- 「 brew install heroku-toolbelt」はしてみて「$HOME/homebrew/bin/heroku」になってるが、公式配布のものと同じ挙動してくれるのか(警告とか肝心なときに出たりしないか)把握できなかったのでパス
- cronはnode-cron。
- 1日1回.mdファイル読みに行ってる
- 調べたら有るのかもしれないが、appfogにheroku shceduler相当のものがあるかわからかった
- コマンドラインツール「af」も「af login」「af push」「af update」しか使ってない
- markdownパーサはnode-markdown
- markdown(npm install markdown)は使わなかた
- なぜか今回パースしたいmdファイルでうまく動かなかった
- rss生成はnode-rss
- validationサービス通るrss作ってくれて手軽
公式rss
- そのうちできるよ。とのこと
- simevidas/webplatformdaily-site · GitHub
Pat Shaughnessy「rubymotionクリエータに一問一答(前編)」
rubysource 2012.2.13のエントリ
RubySource | Getting To Know RubyMotion With Laurent SansonettiRubySource
- id:naoyaさんのエントリ経由で知った
- 長編で二部構成になってる
- プルリクエストもらえそうなビルドシステム(rubyで書いた)だけオープンソース
- プリリクエスト期待薄だと実体験が教えるコンパイラとランタイムはクローズドにし、プロジェクトの資金にもなってる、とか
- それぞれ違う理由でrubymotionからrequireとevalを削ったこととか、
以下斜め読んだ内容
はじめに
- 2012.4以来rubyコミュニティの心を掴んだrubymotion
- 初めてiosプラットフォームでrubyで書けるようになった
- 古式ゆかしいobjective-cもxcodeも一から勉強しなくてよくなった
- rubyとコマンドラインツールがそれに取って代わった
- インタビュー前編;ベーシック
- インタビュー後編:テクニカル
初のrubymotionカンファレンス
- Q:RubyMotion#INSPECT2013の話から
- A:
- リリース後半年したら閃いた。rubymotion小規模イベント
- 最近bubbleconfにスピーカとして呼ばれたので話をしてきた
- 動画ある
- スタートアップ向けカンファレンス
- rubymotion立ち上げる前に自分が抱いた恐れや不安とかをしゃべってきた
- Nihn Buiがオーガナイザ。周りに助けられた切り盛りしてた。
- 俺もやってみたい、となった
- Q:カンファレンス立ち上げるなんて大変そう
- A:
- Nihnほど大掛かりじゃないし
- 150人くらいの規模でよかった
- はじめはrubymotionユーザの多いアメリカでやろうかと思ってた
- 最初のカンファレンスは自分に特別なものとなるはず、と色々考えた
- ホーム(=ベルギー)でやることにした
- Q:なんでベルギー開催?
- A:
- 負担がより少ない
- できるだけ小さくやりたかった
- 顔を見ながら話したりハックできる場所にしたかった
- カネ目当てじゃない。今回は赤字になるはず
- 楽しむために、rubymotionの宣伝のためにやる
- 実はミニツアー付きカンファレンス
- チョコレート工場とビール工場見学ツアー。Brusselsらしいもの
- スピーカの数のリストは大きくなった。が、持ち時間は30分。間の時間もゆったり取った
- 会場は1つだけ。全員そこで登壇
- rubymotionコミュで有名なスピーカーもいる
- 37signalsのNick Quaranto
- HerokuのMatt Thompson
- 知名度高くないがrubymotionコミュで凄い仕事してる人たちもスピーカに参加してくれてる
- いいカンファレンスになるはず
rubymotionのはじまり
- Q:Appleで働いてたらしいけど
- A:
- Q:rubymotionのスタッフ
- A:
そもそもrubymotionとは
- Q:rubymotionnとは。。。
- A:
- 要は、rubyでios開発するためのツールチェーン
- objective-cランタイム上のruby実装
- iosコアフレームワークの上に構築
- rubymotionのobject model実装
- objectvie-cランタイムを使ってる
- 例えばrubymotionでエンジニアがクラス、オブジェクト、メソッドを作ったとする
- そのときに実際にはobjective-cのオブジェクト、クラス、メソッドを触ってる
- rubyからのブリッジとかミドルウェアは存在しない
- エンジニアは全てのios apiにダイレクトにアクセスしてる
- Q:objective-cでの開発と全く同じシステムを使ってる?
- A:
- YES
- objective-cランタイムは実際には、小規模なcライブラリ
- ios開発者は自由にこのライブラリを利用できる
- rubymotionで自分がやってることはまさにそれ
- rubymotionアプリは、objective-cアプリと同じ流儀でランタイムAPIを叩く
- rubymotionではiosのcoreframeworksを使ってネイティブのクラスを実装してる
- 例えばrubymotionのStringクラス
- FoundationフレームワークのNSMutableStringのサブクラスとして実装されてる
- Stringクラスは普段rubyを書いてるのと同じ感覚。違いはほぼゼロ
- rubymotionが裏側でobjective-cでstringを操作してるのと同じ状態を作ってる
- どういうことか
- 例えばrubyでstringを作る。
- このstringがobjective-c apiに渡される。変換とか挟まない
- rubymotionのオブジェクトモデルでは、objective-cのランタイムを使う
- rubymotionのクラス実装にはFoundationフレームワークを使う
- Q:
- rubyのString#upcaseに相当するものがobjective-cには無い
- 実装しないといけなかったはず
- A:
- Q:それ以外のrubymotionの構成要素
- A:
- Q:デバイスのobjective-cランタイム上でrubymotionランタイムが走る?
- A:
- YES
- オブジェクトモデルはobjective-cランタイム使う
- rubymotionランタイムがある。1MBくらい。静的にリンクされる
- rubymotionのランタイムではネイティブにあるクラスだけでなく、ネイティブにない機能も実装した
- 例1.objective-cには、mixinという概念がない
- 実装した
- 例2。あるクラスへインスタンス変数を動的にセットすることがobjective-cではできない
- そのためにworkaround入れた
rubymotion v.s. MRI
- Q:rubymotionがベースにしてるrubyのバージョン
- A:
- Q:rubyエンジニアがrubymotion始めるにあたり、気を付けるべき違いは?
- A:まずrequireが無い
- Q:じゃあrubymotionでのライブラリの読み込み方法は?
- A:
- rubymotionでは静的にコンパイルされる
- コンパイル時に必要なファイルをコンパイラに伝える必要がある
- ランタイム時にモジュール読込むとかしない
- Q:cで言うinclude、あるいはMakefileみたいな話し
- A:
- YES
- 最近ビルドシステムはどんどん賢くなってる
- rubymotionでは新規プロジェクト作ると「app.」ディレクトリができる
- 「.app」以下にrbファイル作ってく
- 作法としては、1クラス1ファイルがオススメ
- ビルドシステムは.app以下の全てのrbファイルを読込んで、依存関係を調べる
- 例。クラスFooが定義されたファイル、クラスBarが定義されたファイル、BarはFooを継承してる、とする
- ビルドシステムは継承関係検知して、FooをコンパイルしてからBarをコンパイルする
- ランタイム上ではクラスFooがクラスBarより先に生成される
- こんなわけで通常はrequireがいらない
- Q:依存関係の検知は全自動?
- A:
- やらなかったこと
- コンパイラへのヒント的なものとしてrequireを実装する
- こういう選択肢はあり得たがやらなかった。筋悪いと思う
- そもそもrequireはKernelクラスのメソッド。引数渡して使うもの
- requireはキーワードじゃないし、基本型扱いする必要がない
- requireには定義済みのstringを渡すことができる
- こんなrequireの挙動にrubymotionのコンパイラは対処しないといけない
- この手のエッジケースに対応するのはいい考えだと思わない
- rubymotionのビルドシステムはコードをパースし依存関係を検知しようとする
- rubymotionでrequire使うと例外がスローされる
- requireを別にすれば、rubyとrubymotionの違いはとても小さい
- あとevalも無い
- evalサポートはインタプリタ同梱するのと同じ
- インタプリタ同梱のアプリをリリースすることにつながる
- やらなかったこと
- Q:インタプリタ同梱はapple的にNGでは?
- A:
- Q:evalを外すことでrubymotionは大丈夫ですとappleに伝えてる、と
- A:
- あと、ハードウェア性能は低いので、ランタイム時にコードをevalするのはいい考えだと思わない
- Q:Kernel#eval以外、instance_evalとかclass_evalとかは?
- A:
- サポートしてる。それ以外のeval系メソッドは動く、はず
- メタプログラミングに使われる類のものは全部いける
- Q:requireとevalがないだけであとはMRIと同じ?
- A:
- まとめるとこんな感じ
- require無し。ビルドシステムあるから
- evalは動かない
- Proc#bindingは削除された
- FixnumとFloatでは、演算子オーバーライドできない
- まとめるとこんな感じ
rubymotinはオープンソースでない件
- Q:rubymotionはオープンソース?プロプライエタリ?
- Q:rubymotionがお客に提供できるコア技術はコンパイラ?
- A;
- Q:rubymotionはrailsのようにはいかない。サクっと直したり機能足したりとかできる領域じゃない、と
- A:
- Q:この仕組みでやりたいことを自分のペースでやれてる、と
- A:YES。というか、自分にはこれが唯一のやり方だった
今後
- Q:rubymotionの今後
- A:
- いいにくい部分
- rubymotionは急速に成長してる
- リリースしてから8ヶ月しか経ってない
- 現時点で、色々な選択肢が見えてきた。重要な機能追加、等々
- リソースは有限。決めて行かないといけない
- ツールチェーンの改善。これは多分今後やると言えそうなこと。
- コマンドラインベースしかない。これで大抵のユーザは使えてる
- IDEラブな人たちもいる。いまJetBrainsと一緒に仕事してる
- RubyMineのrubymotionサポートは良い感じになってる
- RubyMIne内部でrubymotionのデバッグができる
- このまま一緒に仕事続けたら、rubymotionユーザのためのIDEが作れるかも、と思ってる
- ios以外のプラットフォームもサポートしてほしいというリクエストは沢山もらってる
後編
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リストアプリ
- 4半期に分けて、プライオリティ設定して、ひたすら試行錯誤
- 少し長めの期間を視野にいれとくのは大事
- 日単位だと、別のことに気が向いたり、新しいことを試したくなったり、とやってしまうのはありがち
- ある程度経って振り返ったら、諸々の脱線が本当にやっとかないといけないことにデカいダメージ与えてる、ってもありがち
- 自分は時間管理がとても下手くそだが頑張ってる
- Q:生まれとか経歴とか
- A:
- Massachusetts西部、Connecticut出身。要はNew England出身
- 音楽やってた。マーチングバンドでチューバ吹いてた。高校では演劇とバンド
- ネットで最初に作ったのは音楽ブログ。2004年くらい。
- 音楽ブログでは古参で、最初の50番目以内に入っててそこそこ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の学位のご利益はデカい
- 5年前の時点でコンピュータサイエンスが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:
- 2つのことがここ数年で起こってる
- 1つは、レガシーなブラウザが視界から消えた
- ie6死亡、ie7はシェア1%
- ie8はシェア持ってるが、ブラウザの性能アップした
- レガシーなブラウザへの対策がフロントエンド開発で悩みの種だった
- もう1つは、沢山の新機能が登場した
- 過去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テスト使って最適化
- オンライン経由の献金の大半をメールから獲得
- 件名別成績とか
- 大量に送りつけても実害ゼロだと分かったとか
- 親父から「スパムだろ」と文句言われたくらいだ、とか
- 「見た目最悪」なデザインが一番献金してもらえてショックだった
等々を、中の人への取材を元にまとめててわかりやすい
以下斜め読んだ内容
- 今回の大統領戦選挙の特徴の1つは、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テスト開始からしばらくして好成績フレーズ
- メールチームの予想を裏切る結果が出続けた
- メールチームのメンバーはテスト前に色々予想を出して臨んだ
- Showalter曰く
- 全然予想通りにならなかった
- だから、テストし続けないといけなかった
- 「見た目最悪」系が常に好成績で、ショック受けた
- 文字サイズをアホみたいに大きくしたリンク、手間かけた「献金」ボタン、ただのテキストリンク、etc..
- たどり着いた結論は、「注目してほしい箇所には黄色で強調」という外見最悪なやつ
- 予想外の事実
- 荒っぽい言葉をジャブで入れるとクリック稼げた
- ただし効果は一過性
- Showalter曰く
- 「奇をてらう」路線はストップ。仕切りなおした
- 直感に反する重要な洞察も出た
- これは将来の選挙戦にも活かせるもの
- メール受信量を増やしても意外とみんな心が広い
- 登録解除は、全然無かった。
- Fallsgraff曰く
- ってことで、気にせずメール大量投下
- ライター20名使ってフル稼働
- 不快になる人。中にはいた。例えば、自分の親父。直接文句言われた
- この記事まとめ
- オバマ陣営のメール献金チームは「心を掴むメール件名」を追求した
- 数百回テスト繰り返した
- 「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が期待されてるほど効果薄い原因と共通してる
テストその1: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リクエストを2つのコネクション使って出したいとき、リクエストをどうやってコネクションに割り振るか
- 2つやりかたあり
- 分配してからリクエストを出す
- リクエスト1と2を1つ目のコネクションに割り振り、リクエスト3と4を2つ目のコネクションに割り振ってから通信開始
- 都度リクエストを分配する
- コネクションの上限数に到達してからpipeliningがオンになる
- コネクション1にリクエスト1、コネクション2にリクエスト2を割り振って通信開始
- 開始してから、リクエスト3をコネクション1に、リクエスト4をコネクション3に割り振って、第二弾のリクエストにする
- 去年ブラウザをテストした時。最大コネクション数に達してからpipeliningがオンになる流れ
- サーバ側が実装してるかどうかを検知する仕組み
- fx13の実装
-
- コネクションごとにpipeningサポートをチェック
- 最大コネクション到達を待たずにpipelingスタート
- コネクション1にリクエスト1,2を割り振るやつ
-
- 自分の理想
- サーバ単位でサポートチェック、最大コネクション到達後にpipeliningスタートの組み合わせ
- fxの中の人も自分と同意見になっていった
- fx14でテコ入れ入って、fx16で新しくなった
- fx16
- piepeningの実装は複雑
- 自分た書いた2つのポイント以外の要素も追加されてる
- テストみてもpipeliningの実装として改善してる
- chrome
- pipelingオンはコマンドライン経由
- 実装もfirefoxと違う
- fx13,fx16,chromeでpipeliningのテストした理由
- 実装が異なるから
テストその2:firefox16、chrome
- テスト1と違って1/5の規模でやった。諸事情で
- alexa上位100サイトで実施
- 回線はfiberのみ。上り5Mbps。下り20Mbps
- レイテンシは、300ミリ秒のみ
- 結果はほぼテスト1と同じ
- 平均値と中央値の差分も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されてない
- スポットで手動でもテストを行った
テストその3: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の力を存分に引き出すために必要なこと
- 1コネクションで複数ドメインとの通信を多重化
- 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だとしても効果が相殺される
- という想定をしてる人がこういう疑問出してくる
- この懸念は的外れ。3つ理由ある
- 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が力を発揮できない局面では発揮できるように障害を取り除くべき