2010年3月26日 — takeo
Steve Souders 著 、武舎 広幸、福地 太郎、武舎 るみ 訳 オライリー（2010年04月09日 発売予定）
前回の「ハイパフォーマンス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で採用している高速化手法や高速化に関連した最新技術の動向を巻末付録として収録しました。
(続きを読む…)
2010年3月2日 — takeo
いまだ対応が必要なIE6。
レイアウトやjavascriptの確認のため環境を残しておく必要がある。
ブラウザのバージョンごとにテスト環境をVMとかで環境を作っておくのもいいけど、ノートパソコンとか非力のPCではつらい。（ただでさえいろいろ起動しなければならないのに）
AdobeやMicrosoft製のツール、web上のサービスなどいろいろ試してみたけど、これが一番いい。
IETester
IE8, IE7 IE 6 and IE5.5のレイアウトが確認できる。
Javascriptの動きや、ページ遷移もできるのが、このツールのいいとこ。
ただ、結構落ちる。
2008年7月8日 — takeo
実践 パケット解析 ―Wiresharkを使ったトラブルシューティング
Chris Sanders (著), 園田 道夫 (監修), 一瀬 小夜 (翻訳) ,オライリー・ジャパン (2008/1/25)
ブラウザの挙動が変？
単純にHTTPリクエスト、レスポンスだけでは解決できず、パケットキャプチャーをやりながらいろいろ調べたときに読んだ本。
HTTPリクエスト、レスポンスをキャプチャーするソフトはたくさんある（Firebugとか、Fiddlerとか）。こういうソフトって基本的にプロキシとして動いていて、ソフトを通すと挙動が変わったりする（ネットワークが滑らかになるというか..）。
バグの解析をしたいのに、ソフトを通したらバグが発生しなくなることもよくあると思う。
今回もそんな現象が発生して、WireShark(ワイヤーシャーク)を投入させた。
※このソフト以前は「Ethereal(イーサリアル)」という名前で呼ばれていたらしく（著作権の問題でWireSharkに改名。Etherealは現在開発されていない）、SEの人たちと話すときは、「イーサリアル」っていったほうが通じやすい。
ただ、このWireShark、日本語の情報が少ない。まったくの素人にとって未知の領域の物を英語で試すのは本当に疲れる。
そこで、オライリー本「実践 パケット解析 ―Wiresharkを使ったトラブルシューティング」。
WireSharkの使い方から、パケット解析に当然必要なネットワークの知識、実際の解析のチュートリアルを織り交ぜ説明してくれる。２００ページくらいの薄い本だけど、一読するとなんとなく使いこなせるようになる。
いろいろなパケットをパラパラと紹介してくれているので、気になったものは、より詳細をネットで調べるといった感じで使ってみた。手っ取り早くWireSharkを使おうと思っている人にはオススメできる（ほかの本を読んだことないが）
たしかに、ソフトの細かいところや、ネットワークの深いところは解説していない。そういう面では、入門書として扱われて仕方ないが、十分に実践で使える基礎知識をつけることができる本だと思う。
この本をスタートに、ネットワークの深い世界に行くのもいいかもしれない。と思う◎
結局バグは未解決のままだが…
※WireSharkはHTTPリクエスト、レスポンスの中身を見るツールとしては微妙。日本語が化けたり。この辺、エンコードとか指定して見れるようにしてくれたら便利になるのに、と思う。
2008年5月19日 — takeo
Googleを支える技術 ~巨大システムの内側の世界
西田 圭介 (著) ,技術評論社 (2008/3/28)
Googleのシステムを論文などから調べわかりやすく解説している本。
正直、ここまですごいシステム構成だと想像もつかなかった。
「日本のすべてのPCよりも多いサーバを使用し、アルファベットごとにインデックスサーバが作られ、サーバーが壊れてもいいように物理的に離れた場所に複数のコピーを置く」
みたいな中途半端で怪しい知識から一歩前進した。
「とにかく、ひたすら、分散・分散・分散！！！」
この本からのGoogleのシステムの印象は、「そこまで、そんなとこまで分散しているのか！？」だ。
ストレージ（HDD？）の分散、データベースの分散、プログラムの処理の分散、Webサーバの分散・・・。さまざまな層で分散処理が行われている。
分散処理では、データの保護（物理的に離れた場所のサーバーに複数のコピー）、処理の高速化（１回の検索で数百、数千台のサーバーで同時に検索）、ネットワークの高速化（物理的に近いサーバーに接続）などが行われているらしい。
いったい、１回のGoogle検索で何台のサーバーが動くのか？
１つのDBに入りきらないようなデータを扱った仕事をしたことがないけど、分散処理の難しさは十分に伝わってくる。
「電力のチューニング」
巨大なデータセンター、膨大なサーバーを動かす電力はとてつもなくでデカイ、電気代も大変らしい。
Googleでは、価格、性能、電気代を考慮したCPUの選択から、電気代を節約するための電源の改造、ピーク電力の削減などを行っている。電気代、データセンターの設備代はピーク電力に左右され、電力はCPUの使用率により変化する。そこで、処理の時間を均等に割り振るとか、ピーク電力に近づくと処理速度を落とすとかして電力をチューニングしているらしい。
････････････・・・・・・・・・・・・・・・
他、さまざまな方向からGoogleのシステムについて解説しているこの本。理系ではない人（自分）にとって多少難しいor理解できない部分もあるが、Googleのシステムを例題に分散処置の勉強ができる、コストパフォーマンスがものすごい高い本だと思う。Googleのソフトウェア開発環境についても触れているので、是非読んでほしい。◎
2008年5月19日 — takeo
最近の流行？のlightbox系UIを導入してみた。
wordpressのプラグインとして「ightbox 2 Wordpress Plugin」が定番っぽい感じだけど、ライブラリに「prototype.js」が使われているのが嫌で、「jquery.js」を使っている「jQuery lightBox plugin」にした。
（このブログでは、jquery.jsをJavascriptライブラリとして使っていこうと思っているので、prototype.jsを避けた。一応ちょっとした工夫で共存はできるがこれだけの為にprototype.jsは重い。）
以下で説明する方法で設置すると、簡単にページ中の画像をスライド表示することができる。
簡単に設置できるし、軽快に動く、いいライブラリだ。
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>
以下サンプル
2008年5月18日 — takeo
また便利な機能が追加された。
昨日、Google Mapを使っていて新機能が追加されているこに気づいた。（いつからだろう？４月は、こんな機能はなかったはず）
GoogleMapの左フレームに「このエリアを散策 »」が表示されていて、クリックすると地図上に小さな写真（サムネール）が表示される。地図をドラッグしたりズームするごとにパラパラと新しい写真が表示される。
サムネールをクリックすると、ふきだしの中にちょっと大きめの写真が表示される。写真をクリックすると、Panoramioのコンテンツが表示される。
地図と、写真をみながら、道順を調べることができてとても便利。旅行やしらない場所を訪れるときにいい目印になってくれるはず。
写真の追加
この写真を提供しているのが「Panoramio」っていうサービス。登録すると写真をアップードすることができる。写真をアップロードしたあとでGoogle Map APIを利用したUIで地図から位置を指定する（写真に座標が入っている場合は自動で登録されるらしい。）
登録した写真がどんな確認を経て、どのタイミングでGoogle Mapに反映されるかは不明だが、登録される写真、更新頻度が増えていくと便利なサービスになっていきそう。地図の更新より写真の更新が速くなると、携帯から「このへんにコンビニがあったような？」「今のこの場所込んでいるかな？」なんて調べることができるかも。
とりあえず写真を登録してみた。
2008年4月14日 — takeo
ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール
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サイトの分析
2004年11月10日 — takeo
英語の読みかたって微妙に自己中なことがある。たとえば、
【SWF】 ×エス・ダブリュー・エフ → ◎スウィフ
【RSS】 ×レス → ◎アール・エス・エス
読みかたって難しい。
2004年7月24日 — takeo
Macromedia(globalサイト)で｢Announcing Contribute 3 with over 300 updates.｣っとContributeがアップグレードしていた。かたやMacromedia Japanでは｢1本買えば、もう1本をプレゼント！Macromedia Contribute 2 日本語版キャンペーン｣っとおいしいキャンペーンが・・。
日本語サイトの微妙なキャンペーンは抜きにして、Contribute 3はちょっと大きくな取り上げ方をされている。『Macromedia Web Publishing System』っていう新しいコンセプトのようなものまで登場！。Macromediaは、誰に向かってコレを売っていくのか？中小企業？駆け出しのWebデザイナー？
Contribute 3にバンドリングのFlashPaper2は、明らかにTarget>Abode。
SWFだけでなくPDFにも対応してしまった。正直これは欲しい。
Macromediaのswfに対応したLiveMotionの開発をやめたAbode。それに対してAbodeのPDFに対応したMacromedia(次バージョンColdFusionもPDFに対応)。どーなっていくんだろ～。webベンダー・・。
英語版StudioMXにバンドリングされていたContribute。とりあえずアップグレードしたContribute 2。まだ1度も使っていない。Contribute 3は・・？
もともとOffice製品を使わない人にとってはなんの魅力も感じないものだけど。これ売れるのかな？？？？
2004年6月22日 — takeo
GIFの特許問題について
2004年6月20日、日本においても Unisys社の特許が有効期限が切れました。
GIFの特許問題でPNGがでてきた話は聞いたことがある、adobeも前に訴えられていたような、、。
PNGを使いたいんだけどIEで画像の周りにグレーの線が入ったり、アンチェイリアスがきかなかったりと（ちなみにHomeのFirefoxへのリンク画像がPNGだった）。また、種類が微妙に多い、gifっぽい圧縮、jpegっぽい圧縮、またpictみたいにアルファチャンネルに対応していたりと。Macromedia Fireworksなんて、デフォルトの保存形式になっていてレイヤー情報とかふくんでいる。
でも便利なのでFireworksは、お気に入り。
この機会にFlashも外部ファイルの読み込みにGIFを加えてほしい。特許の問題だけだと思うんだけど。GIFが読み込めたらホントブラウザの代わりとして使えるのに。
