機能改善する？テストする？

請負仕事なら、もちろんテストに時間を費やすと思う。

これが自社製品ならどうなるか。

ほとんど起こりえない、バグの洗い出しのために１週間使うのか、
操作性を改善して気持ちよく使ってもらうか。

当然後者。

１パーセントの可能性よりも９９％の通常操作の使い勝手の改善に費やす方がいい。

これって、プロとして間違ってるのか？

悩ましい問題だ。

前回の「ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール」の続編。

前回がすごく良かっただけに大変期待できる続編。絶対買う。

2,940円と値段も１.5倍、ページ数も1.5倍。充実したコンテンツを期待してしまう。

目次をながめていると気になることばかりなんだけど、こんかいは、メモリ使用の問題あたりでいいネタがもらえればと期待している。

ただ、今回もはずれない本だと思う。マストBUY。

高速サイトを実現するための14の基本ルールを提示し、世界中のエンジニアから大きな支持を得てベストセラーとなった『ハイパフォーマンスWebサイト』の続編。本書ではAjaxやWeb 2.0技術の浸透といった前著からの技術的なトレンドを反映するとともに、Chromeなど新しく登場したブラウザや他のブラウザの新バージョンにも対応するための情報を追加しました。HTML5、Web Workers、Web Socketsなどの新しい技術、最新のリアルタイムインターネットを支える技術についても言及しています。日本語版ではYahoo! JAPANやMozilla Japan、Google Japanで採用している高速化手法や高速化に関連した最新技術の動向を巻末付録として収録しました。

目次
訳者まえがき
クレジット
まえがき

1章 Ajaxアプリケーションとパフォーマンス
Douglas Crockford●Yahoo!
1.1 トレードオフ
1.2 最適化の原則
1.3 Ajax
1.4 ブラウザ
1.5 Wow!
1.6 JavaScript
1.7 まとめ

2章応答性の高いウェブアプリケーション
Ben Galbraith、Dion Almaer ●Ajaxian.com, Mozilla
2.1 どれくらい速ければよいのか
2.2 遅延の測定
2.2.1 遅延の度合いが悪化するとき
2.3 スレッド
2.4 応答性の確保
2.4.1 Web Workers
2.4.2 Gears
2.4.3 タイマー
2.4.4 メモリ使用が応答時間に及ぼす影響
2.4.5 仮想メモリ
2.4.6 メモリ問題のトラブルシューティング
2.5 まとめ

3章初期ロードの分割
3.1 現状の分析
3.2 分割による節減効果
3.3 分割位置の特定
3.4 未定義シンボルと競合状態
3.5 ケーススタディ −Googleカレンダー

4章実行をブロックしないスクリプトのロード
4.1 スクリプトによるブロック
4.2 スクリプトダウンロードの動作の矯正
4.2.1 XHR eval
4.2.2 XHRインジェクション
4.2.3 iframeスクリプト
4.2.4 Script DOM要素
4.2.5 Script Defer
4.2.6 document.writeによる SCRIPTタグ書き出し
4.3 ブラウザのビジーインジケータ
4.4 順序実行の保証
4.5 結果のまとめ
4.6 そして勝者は

5章非同期のスクリプトの組み合わせ
5.1 コード例 −menu.js
5.2 競合状態
5.3 非同期ロード時の実行順序維持
5.3.1 テクニック 1−ハードコーディングコールバック
5.3.2 テクニック 2−Window Onload
5.3.3 テクニック 3−タイマー
5.3.4 テクニック 4−Script Onload
5.3.5 テクニック 5−SCRIPTタグの分解
5.4 複数の外部スクリプト
5.4.1 管理された XHR
5.4.2 DOM要素と Doc Write
5.5 汎用的な解決方法
5.5.1 単一スクリプトの場合
5.5.2 複数スクリプトの場合
5.6 非同期ロードの実例
5.6.1 Google AnalyticsとDojo
5.6.2 YUI Loaderユーティリティ

6章インラインスクリプトの適切な位置
6.1 インラインスクリプトによるブロック
6.1.1 インラインスクリプトをページ末尾に移動
6.1.2 非同期に実行を開始
6.1.3 Script Deferの利用
6.2 CSSとJavaScriptの適用順序の維持
6.3 危険 −スタイルシートに続くインラインスクリプト
6.3.1 インラインスクリプトのブロック
6.3.2 スタイルシートによるブロック
6.3.3 現実の事例

7章効率的な JavaScriptコード
Nicholas C. Zakas●Yahoo!
7.1 スコープの管理
7.1.1 ローカル変数の使用
7.1.2 スコープチェーンの拡張
7.2 効率的なデータアクセス
7.3 フロー制御
7.3.1 高速な条件文
7.3.2 高速なループ
7.4 文字列の最適化
7.4.1 文字列の連結
7.4.2 文字列のトリミング
7.5 長時間実行されるスクリプトは避ける
7.5.1 タイマーを使って処理を明け渡す
7.5.2 処理の明け渡しのためのタイマーパターン
7.6 まとめ

8章 Comet
Dylan Schiemann●SitePen
8.1 Cometの原理
8.2 トランスポート処理の手法
8.2.1 ポーリング
8.2.2 ロングポーリング
8.2.3 永久フレーム
8.2.4 XHRストリーミング
8.2.5 将来のトランスポート処理
8.3 クロスドメイン
8.4 Cometを実装した場合のアプリケーションに対する効果
8.4.1 接続の管理
8.4.2 パフォーマンスの測定
8.4.3 プロトコル
8.5 まとめ

9章 gzip圧縮再考
Tony Gentilcore●Google
9.1 なぜこれが問題か
9.2 原因
9.2.1 圧縮の指定
9.2.2 犯人捜し
9.2.3 一般に見られるタートルタッピングの例
9.3 非対応ユーザーの救済方法
9.3.1 非圧縮時のページサイズを最小化するページ設計
9.3.2 ユーザーへの周知
9.3.3 gzipサポートの直接検知

10章画像の最適化
Stoyan Stefanov●Yahoo!
Nicole Sullivan●CSS Ninja
10.1 画像最適化を単純にするための 2ステップ
10.2 画像の形式
10.2.1 背景知識
10.2.2 画像ファイル形式の特徴
10.2.3 PNGの詳細
10.3 可逆な画像最適化の自動化
10.3.1 PNGのチャンクの削除
10.3.2 JPEGのメタデータの削除
10.3.3 GIFから PNGへの変換
10.3.4 GIFアニメーションの最適化
10.3.5 Smush.it
10.3.6 プログレッシブ JPEGとファイルサイズ
10.4 透過度 −AlphaImageLoaderの使用を避ける
10.4.1 透過度の効果
10.4.2 AlphaImageLoader
10.4.3 AlphaImageLoaderの問題点
10.4.4 プログレッシブエンハンスメント
10.5 スプライトの最適化
10.5.1 スーパースプライトとモジュール式スプライト
10.5.2 高度に最適化された CSSスプライト
10.6 その他の画像最適化
10.6.1 画像のサイズを変更しない
10.6.2 生成した画像の圧縮
10.6.3 ファビコン
10.6.4 Appleタッチアイコン
10.7 まとめ

11章主ドメインの細分化
11.1 クリティカルパス
11.2 誰が細分化を行うか
11.3 HTTP/1.0へのダウングレード
11.4 細分化の実際
11.4.1 IPアドレスとホスト名
11.4.2 ドメイン数の問題
11.4.3 リソースの分散法
11.4.4 最新のブラウザ

12章ドキュメントのフラッシュ
12.1 先頭のフラッシュ
12.2 出力のバッファリング
12.3 チャンク形式エンコーディング
12.4 フラッシュと gzip
12.5 その他の介在システム
12.6 ドメインのブロックとフラッシュ
12.7 ブラウザ −最後の障害
12.8 PHP以外の言語
12.9 フラッシュに関するチェックリスト

13章 iframeの取り扱い
13.1 もっともコストのかかる DOM要素
13.2 iframeによる onloadイベントのブロック
13.3 iframeと並列ダウンロード
13.3.1 iframeより前に置かれたスクリプト
13.3.2 iframeより前に置かれたスタイルシート
13.3.3 iframeより後に置かれたスタイルシート
13.4 ホスト名当たりの接続数
13.4.1 iframeにおける接続の共有
13.4.2 複数のタブとウィンドウにわたる接続の共有
13.5 iframeのコストに関するまとめ

14章 CSSセレクタの単純化
14.1 セレクタの種類
14.1.1 IDセレクタ
14.1.2 クラスセレクタ
14.1.3 タイプセレクタ
14.1.4 隣接兄弟セレクタ
14.1.5 子供セレクタ
14.1.6 子孫セレクタ
14.1.7 ユニバーサルセレクタ
14.1.8 属性セレクタ
14.1.9 擬似クラスと擬似要素
14.2 CSSセレクタを効率的にするためのポイント
14.2.1 右端が最初
14.2.2 効率的な CSSセレクタの記述
14.3 CSSセレクタのパフォーマンス
14.3.1 複雑なセレクタのパフォーマンスへの影響
14.3.2 使用を控えるべき CSSセレクタ
14.3.3 リフロー時間
14.4 実際のウェブサイトにおける CSSセレクタの働きの測定

付録A パフォーマンス関連ツール
A.1 パケットアナライザ
A.1.1 HttpWatch
A.1.2 Firebugの［接続］パネル
A.1.3 AOL Pagetest
A.1.4 VRTA
A.1.5 IBM Page Detailer
A.1.6 Webインスペクタの［リソース］パネル
A.1.7 Fiddler
A.1.8 Charles
A.1.9 Wireshark
A.2 ウェブ開発ツール
A.2.1 Firebug
A.2.2 Webインスペクタ
A.2.3 IE Developer Toolbar
A.3 パフォーマンスアナライザ
A.3.1 YSlow
A.3.2 AOLPagetest
A.3.3 VRTA
A.3.4 neXpert
A.4 その他のツール
A.4.1 Hammerhead
A.4.2 Smush.it
A.4.3 Cuzillion
A.4.4 UA ProfilerとBrowserscope

付録B Yahoo! JAPANが実践する Webの高速化
岡部和昌、黒田真澄、由衛朋久、高林貴仁、木村尚敬 ●ヤフー株式会社
B.1 CSSスプライト −事例： Yahoo! JAPANトップページ
B.1.1 画像フォーマット
B.1.2 スプライト内画像の並べ方
B.1.3 スプライト画像の読み込み方法
B.1.4 CSSスプライトを利用する際の手順
B.2 画像の軽量化 −事例： Yahoo!ニュース
B.2.1 PNG形式の減色
B.2.2 JPEG形式の画像
B.2.3 サーバサイドの画像圧縮
B.3 FirstByte−事例： Yahoo! JAPANウェブ検索ページ
B.3.1 FirstByteの実装例
B.4 消費リソースの分析 −事例： Yahoo!検索のフロントエンド
B.5 効率的な開発とパフォーマンスを意識した運用
B.5.1 役割分担
B.5.2 制作フェーズ
B.5.3 運用フェーズ

付録 Cブラウザの最新技術を活用した Webの高速化
浅井智也 ●一般社団法人 Mozilla Japan
C.1 プラットフォームとしてのブラウザ
C.2 JavaScriptエンジンを意識した高速化
C.2.1 JITコンパイラについて
C.2.2 関数のインライン展開はほどほどに
C.2.3 ループ処理となるように記述する
C.2.4 クロージャの使用は最小限に
C.2.5 DOMプロパティへのアクセス
C.2.6 argumentsの使用に注意する
C.3 ブラウザの処理を意識した高速化
C.3.1 DOM要素やプロパティのキャッシュ
C.3.2 ブラウザのリフローを意識する
C.3.3 Selectors APIを利用する
C.3.4 ネイティブメソッドを利用する
C.4 ブラウザの最新機能を活用した高速化
C.4.1 リンクプリフェッチ
C.4.2 DNSプリフェッチ
C.4.3 画像ファイルを減らして高速化する
C.4.4 WebGL−Webで3次元グラフィックス
C.5 ユーザー体験を意識した高速化
C.5.1 HTML5の

付録 D Web高速化に対する Googleのアプローチ
及川卓也 ●Google
D.1 Webの高速化
D.1.1 Google Chromeにおけるブラウザの高速化
D.2 Web標準採用 /推進による高速化の利点
D.3 Web SocketsとSPDY
D.3.1 Web Socketsとは
D.3.2 Web Socketsの実装状況
D.3.3 SPDYとは
D.4 Steve Soudersとの一問一答

レイアウトやjavascriptの確認のため環境を残しておく必要がある。

ブラウザのバージョンごとにテスト環境をVMとかで環境を作っておくのもいいけど、ノートパソコンとか非力のPCではつらい。（ただでさえいろいろ起動しなければならないのに）

AdobeやMicrosoft製のツール、web上のサービスなどいろいろ試してみたけど、これが一番いい。

IETester

IE8, IE7 IE 6 and IE5.5のレイアウトが確認できる。

Javascriptの動きや、ページ遷移もできるのが、このツールのいいとこ。

ただ、結構落ちる。

Chris Sanders (著), 園田 道夫 (監修), 一瀬 小夜 (翻訳) ,オライリー・ジャパン (2008/1/25)

ブラウザの挙動が変？

単純にHTTPリクエスト、レスポンスだけでは解決できず、パケットキャプチャーをやりながらいろいろ調べたときに読んだ本。

HTTPリクエスト、レスポンスをキャプチャーするソフトはたくさんある（Firebugとか、Fiddlerとか）。こういうソフトって基本的にプロキシとして動いていて、ソフトを通すと挙動が変わったりする（ネットワークが滑らかになるというか..）。

バグの解析をしたいのに、ソフトを通したらバグが発生しなくなることもよくあると思う。
今回もそんな現象が発生して、WireShark(ワイヤーシャーク)を投入させた。

※このソフト以前は「Ethereal(イーサリアル)」という名前で呼ばれていたらしく（著作権の問題でWireSharkに改名。Etherealは現在開発されていない）、SEの人たちと話すときは、「イーサリアル」っていったほうが通じやすい。

ただ、このWireShark、日本語の情報が少ない。まったくの素人にとって未知の領域の物を英語で試すのは本当に疲れる。

そこで、オライリー本「実践 パケット解析 ―Wiresharkを使ったトラブルシューティング」。

WireSharkの使い方から、パケット解析に当然必要なネットワークの知識、実際の解析のチュートリアルを織り交ぜ説明してくれる。２００ページくらいの薄い本だけど、一読するとなんとなく使いこなせるようになる。

いろいろなパケットをパラパラと紹介してくれているので、気になったものは、より詳細をネットで調べるといった感じで使ってみた。手っ取り早くWireSharkを使おうと思っている人にはオススメできる（ほかの本を読んだことないが）

たしかに、ソフトの細かいところや、ネットワークの深いところは解説していない。そういう面では、入門書として扱われて仕方ないが、十分に実践で使える基礎知識をつけることができる本だと思う。

この本をスタートに、ネットワークの深い世界に行くのもいいかもしれない。と思う◎

結局バグは未解決のままだが…

※WireSharkはHTTPリクエスト、レスポンスの中身を見るツールとしては微妙。日本語が化けたり。この辺、エンコードとか指定して見れるようにしてくれたら便利になるのに、と思う。

西田 圭介 (著) ,技術評論社 (2008/3/28)

Googleのシステムを論文などから調べわかりやすく解説している本。

正直、ここまですごいシステム構成だと想像もつかなかった。

「日本のすべてのPCよりも多いサーバを使用し、アルファベットごとにインデックスサーバが作られ、サーバーが壊れてもいいように物理的に離れた場所に複数のコピーを置く」

みたいな中途半端で怪しい知識から一歩前進した。

「とにかく、ひたすら、分散・分散・分散！！！」

この本からのGoogleのシステムの印象は、「そこまで、そんなとこまで分散しているのか！？」だ。

ストレージ（HDD？）の分散、データベースの分散、プログラムの処理の分散、Webサーバの分散・・・。さまざまな層で分散処理が行われている。
分散処理では、データの保護（物理的に離れた場所のサーバーに複数のコピー）、処理の高速化（１回の検索で数百、数千台のサーバーで同時に検索）、ネットワークの高速化（物理的に近いサーバーに接続）などが行われているらしい。

いったい、１回のGoogle検索で何台のサーバーが動くのか？
１つのDBに入りきらないようなデータを扱った仕事をしたことがないけど、分散処理の難しさは十分に伝わってくる。

「電力のチューニング」

巨大なデータセンター、膨大なサーバーを動かす電力はとてつもなくでデカイ、電気代も大変らしい。

Googleでは、価格、性能、電気代を考慮したCPUの選択から、電気代を節約するための電源の改造、ピーク電力の削減などを行っている。電気代、データセンターの設備代はピーク電力に左右され、電力はCPUの使用率により変化する。そこで、処理の時間を均等に割り振るとか、ピーク電力に近づくと処理速度を落とすとかして電力をチューニングしているらしい。

････････････・・・・・・・・・・・・・・・

他、さまざまな方向からGoogleのシステムについて解説しているこの本。理系ではない人（自分）にとって多少難しいor理解できない部分もあるが、Googleのシステムを例題に分散処置の勉強ができる、コストパフォーマンスがものすごい高い本だと思う。Googleのソフトウェア開発環境についても触れているので、是非読んでほしい。◎

最近の流行？のlightbox系UIを導入してみた。

wordpressのプラグインとして「ightbox 2 WordPress Plugin」が定番っぽい感じだけど、ライブラリに「prototype.js」が使われているのが嫌で、「jquery.js」を使っている「jQuery lightBox plugin」にした。
（このブログでは、jquery.jsをJavascriptライブラリとして使っていこうと思っているので、prototype.jsを避けた。一応ちょっとした工夫で共存はできるがこれだけの為にprototype.jsは重い。）

以下で説明する方法で設置すると、簡単にページ中の画像をスライド表示することができる。
簡単に設置できるし、軽快に動く、いいライブラリだ。

jQuery lightBox pluginの使い方

wordpressのプラグインではないので、pluginフォルダには入れない。HTMLからアクセスできる場所に置く。

１．JSを読み込む。

<script type="text/javascript" src="http://www.cubdesign.com/js/jquery.js"></script>
<script type="text/javascript" src="http://www.cubdesign.com/js/jquery.lightbox-0.5.js"></script>

２．CSSを読み込む。

<link rel="stylesheet" type="text/css" href="http://www.cubdesign.com/css/jquery.lightbox-0.5.css" media="screen" />

３．スクリプトを追加する。

<script type="text/javascript">

$(function(){

$('a[@rel*=lightbox]').lightBox();

});

</script>

４．lightbox機能を使いたいaタグにrel属性を設定する。

<a href="image1.jpg" rel="lightbox"><img src="thumb_image1.jpg" width="72" height="72" alt="" /></a>

<a href="image2.jpg" rel="lightbox"><img src="thumb_image2.jpg" width="72" height="72" alt="" /></a>

<a href="image3.jpg" rel="lightbox"><img src="thumb_image3.jpg" width="72" height="72" alt="" /></a>

以下サンプル

また便利な機能が追加された。

昨日、Google Mapを使っていて新機能が追加されているこに気づいた。（いつからだろう？４月は、こんな機能はなかったはず）

GoogleMapの左フレームに「このエリアを散策 »」が表示されていて、クリックすると地図上に小さな写真（サムネール）が表示される。地図をドラッグしたりズームするごとにパラパラと新しい写真が表示される。

サムネールをクリックすると、ふきだしの中にちょっと大きめの写真が表示される。写真をクリックすると、Panoramioのコンテンツが表示される。

地図と、写真をみながら、道順を調べることができてとても便利。旅行やしらない場所を訪れるときにいい目印になってくれるはず。

写真の追加

この写真を提供しているのが「Panoramio」っていうサービス。登録すると写真をアップードすることができる。写真をアップロードしたあとでGoogle Map APIを利用したUIで地図から位置を指定する（写真に座標が入っている場合は自動で登録されるらしい。）

登録した写真がどんな確認を経て、どのタイミングでGoogle Mapに反映されるかは不明だが、登録される写真、更新頻度が増えていくと便利なサービスになっていきそう。地図の更新より写真の更新が速くなると、携帯から「このへんにコンビニがあったような？」「今のこの場所込んでいるかな？」なんて調べることができるかも。

とりあえず写真を登録してみた。

Steve Souders (著), スティーブ サウダーズ (著), 武舎 広幸 (翻訳), 福地 太郎 (翻訳), 武舎 るみ (翻訳) ,オライリージャパン (2008/4/11)

久しぶりに発売日が待ち遠しかった本。速読破。

サイトのパフォーマンス評価ツールYSlow（Firefox+Firebugのアドオン)を作成した米Yahoo!パフォーマンス担当責任者著が「高速サイトを実現する14のルール」とともにサイトのパフォーマンスチューニングを伝授してくれます。

「待ち時間の80%はフロントエンドの処理に費やされる」という調査結果のもと、実際のサイトを例にとりフロントエンド中心のパフォーマンスチューニングを解説してくれます。

なんとなく行っていた「コンテンツを圧縮するgzip。JavaScriptを軽量化する縮小化、難読化。ブラウザキャッシュ対策、CSS、JAVASCIPTの外部ファイル化。付加分散。」の「なぜ？」や、まったく知らなかった「Etag、CSS、JAVASCIPTの記述位置」、気軽に使っていた「IEのCSS expressionの問題」。

とくに、CSS、JAVASCIPTの記述位置（ルール5:スタイルシートは先頭に置く、ルール6:スクリプトは最後に置く）は体感速度に大きく関わるのですぐにでも実践したい。

あいまいな理解だったブラウザキャッシュについてもかなり明快に理解することができる。（Etagについては速対応が必要。）

JAVASCIPTの縮小化と難読化の解説もためになる。（難読化は、リスクのわりにその効果は低い）

本当にこういう本を待っていた。
Webの仕事に携わる人必読。今までを反省し、今後のサイトにはできるだけこの「１４のルール」を実践したい。◎◎◎

以下目次。

A章 フロントエンドのパフォーマンスの重要性
B章 HTTPの概要
1章 ルール1:HTTPリクエストを減らす
2章 ルール2:CDNを使う
3章 ルール3:Expiresヘッダを設定する
4章 ルール4:コンポーネントをgzipする
5章 ルール5:スタイルシートは先頭に置く
6章 ルール6:スクリプトは最後に置く
7章 ルール7:CSS expressionの使用を控える
8章 ルール8:JavaScriptとCSSは外部ファイル化する
9章 ルール9:DNSルックアップを減らす
10章 ルール10:JavaScriptを縮小化する
11章 ルール11:リダイレクトを避ける
12章 ルール12:スクリプトを重複させない
13章 ルール13:ETagの設定を変更する
14章 ルール14:Ajaxをキャッシュ可能にする
15章 米国トップ10サイトの分析

【SWF】　×エス・ダブリュー・エフ　→　◎スウィフ
【RSS】　×レス　→　◎アール・エス・エス

読みかたって難しい。

英語版StudioMXにバンドリングされていたContribute。とりあえずアップグレードしたContribute 2。まだ1度も使っていない。Contribute 3は・・？

もともとOffice製品を使わない人にとってはなんの魅力も感じないものだけど。これ売れるのかな？？？？