February 13, 2009

BPM を調べるやつ

ヒビノアワ: 自作iPhoneアプリ「BPM」公開されました！

こういうのいいなーと思いつつ、iPhone 持ってないから俺使えないじゃん！

と、ついカッとなって作った。今は反省している。

#!perl

use strict;
use warnings;
use Time::HiRes qw(gettimeofday);
use Term::Screen;

use constant DEFAULT_SECONDS => 60;

my $secs = int $ARGV[0] || DEFAULT_SECONDS();

my $screen = Term::Screen->new;
$screen->clrscr();

my $start;
my $end;

$screen->at(0, 0)->puts(sprintf("pless any key to start. (%d secs)", $secs));

my $count = 0;
my $bpm;

while (my $c = $screen->at(1, 0)->getch) {
    $screen->clrscr();
    exit if $c =~ /^[\x03\x04\x1b]$/;
    $count++;
    unless ($start) {
        $start = gettimeofday();
    }
    $end = gettimeofday();
    my $diff = $end - $start;
    $bpm = $diff > 1 ? $count * (60 / $diff) : 0;
    $screen->at(0, 0)->puts(
        sprintf("%3dbeats - %.2f BPM (%.3fsecs)", $count, $bpm, $diff));
    last if $diff >= $secs;
}

$screen->clrscr();
$screen->at(0, 0)->puts(sprintf("%.2f BPM", $bpm));
$screen->at(1, 0)->puts('');

音楽を聞きながら、キーボードをタップ (?) して調査できます。
そもそも、BPM 調べる用のソフトは色々とあるので、GUI が使えないという、奇特な環境の人向け。

そんな人あんまいないだろ JK

nipotan at 12:33 | Comments(0) | TrackBack(0) | 技術

February 05, 2009

正規表現で、ソーシャルブックマーカブルな URL かそうでないかを判定する

#!perl

use strict;
use warnings;
use Perl6::Say;

my $PRIV_IP_RE = qr{^https?://
    \b(?:
	10\.(?:\d\d?|1\d\d|2(?:[0-4]\d|5[0-5]))|  # class A
	172\.(?:1[6-9]|2\d|3[01])|                # class B
	192\.168                                  # class C
    )
    \.(?:\d\d?|1\d\d|2(?:[0-4]\d|5[0-5]))
    \.(?:\d\d?|1\d\d|2(?:[0-4]\d|5[0-5]))\b
}xi;

for my $url (qw(http://10.10.2.60/ http://www.google.com/)) {
    say "$url IS " . ($url =~ $PRIV_IP_RE ? "NOT BOOKMARKABLE" : "BOOKMARKABLE");
}

結果:

http://10.10.2.60/ IS NOT BOOKMARKABLE
http://www.google.com/ IS BOOKMARKABLE

参考:
おまいの iTunes も共有汁 - にぽたん研究所
はてなブックマーク - うごメモはてな - メモからはじまる新しいコミュニケーション！

nipotan at 18:07 | Comments(0) | TrackBack(0) | 技術

January 16, 2009

2 年半ぐらい前に購入した Lenovo ThinkPad X60 が段々不安定になってきたのと、標準で搭載されている 80GB HDD が容量的にほんの少しだけ不満に思えてきたので、そろそろ新しいラップトップを購入しようと考えました。

でも、色々調べていても、ここ 2 年の間で、ほとんどがビックリするほどほとんどスペックアップしてない。
HDD が (モデルによって) SSD になったぐらい。。。

X60 シリーズ用の 8 セルの大容量バッテリーとかも使ってるし、

レノボ・ジャパン ThinkPad X60シリーズ8セル大容量バッテリー 40Y7003

Lenovo

Amazon.co.jp で詳細を見る

これを使わなくしてしまうのはもったいないので、ということで、新しい ThinkPad を購入するのは見送って、しばらくこのまま X60 を使い続けることにしました。
ただ、先述の通り、若干動作が不安定になってきていたので ThinkPad をリカバリ (HDD の中身を工場出荷時の内容に戻す) しようという思いが前々からあったので、リカバリついでに HDD の容量をもっと大きくしたいなとも考えてました。

年が明けて、2009 年は SSD が主流になる年だという声をところどころで見かけたので、あー、じゃあそれに乗ってみるかーということで、SSD を調べたところ、意外に安かったので購入し、換装してみました。

二年半前に購入した ThinkPad X60 です。Designed for Windows のシールとか、Intel Core2 Duo のシールとかは、手汗で完全に剥がれました。

レノボ・ジャパン ThinkPad X60 (T55/512/60/XP/12TFT)T 1709AJ1

Lenovo

Amazon.co.jp で詳細を見る

データのバックアップ用に 500GB の外付け HDD (I-O DATA HDCN-U500) を買いました。
この容量でこのお値段は安いです。

I-O DATA USB 2.0/1.1対応外付型ハードディスク 500GB HDCN-U500

アイ・オー・データ

Amazon.co.jp で詳細を見る

I-O DATA 東芝[レグザ]対応 USB 2.0/1.1接続外付型ハードディスク 2TB HDC-EU2.0K [フラストレーションフリーパッケージ(FFP)]

アイ・オー・データ

Amazon.co.jp で詳細を見る

この外付け HDD に、保存しておくべきファイルを一つ一つ保存しました。
ここで、ディスクやドライブのバックアップイメージファイルとかを作らなかったのは、それを復元してしまうと、不安定な状態までも復元してしまうんじゃないかと思ったからです。
この認識が正しいのかどうかはよくわかってません。多分、正しい気はします。

バックアップを取った後に、内蔵 HDD のリカバリ領域からリカバリして、外付け HDD に保存したデータから、元々使っていたファイルとかを取り出し、使い勝手が良い状態になるまで、各種設定をし、OS 入れたてだから非常に安定していながらも、不安定さが大幅に改善された「いつもの環境」と呼べる状態にまで戻しました。
ちなみに、SSD は書き換え回数に限界があって、今回購入した SSD は MLC で、MLC の場合の書き換え回数の限界は 1 セルあたり 1 万回ぐらいと言われています。
なので、SSD にまっさらな OS を入れて外付け HDD からデータをコピーしたり、使うアプリケーションのアーカイブを取ってきて、展開 (解凍) して、インストールしてとかやると、書き換えの回数が異常に増えるような気がしたので、SSD の寿命をなるべく延ばすために「HDD で完全に環境を作って、そこから SSD に移す」という手順を考えました。きっとそのほうが書き換え回数が少なく済むと思ったからです。

で、いよいよここから SSD へ換装する作業へと突入です。

今回購入した SSD は、BUFFALO SHD-NSUM120G です。
120GB と、容量も増えて嬉しい。

BUFFALO 2.5インチ MLC搭載 SATA II/USB2.0用内蔵SSD SHD-NSUM120G

バッファロー

Amazon.co.jp で詳細を見る

Crucial 2.5インチ内蔵型 SATA3.0対応 M4 SSDシリーズ 128GB CT128M4SSD2

Crucial Technology

Amazon.co.jp で詳細を見る

Intel SSD 330 Series Maple Crest 120GB MLC 2.5inch 9.5mm Reseller Box SSDSC2CT120A3K5

インテル

Amazon.co.jp で詳細を見る

気になったのは、パッケージとかに「起動」が速くなると書いてあるが、起動以外についてはあまり大々的には触れられていない点。

SSD には USB 端子が付いているので、USB 経由でデータの移行を行ないます。

移行には、購入した SSD (BUFFALO SHD-NSUM120G) に同梱されていた、Acronis Migrate Easy を使い、HDD のクローンを SSD に作りました。

Acronis Migrate Easy 7.0

Acronis

Amazon.co.jp で詳細を見る

LB コピーワークス 12 特別優待版

ライフボート

Amazon.co.jp で詳細を見る

移行が完了したら、HDD を SSD に換装です。

ここのネジを取って HDD を取り出します。

オープン。

このビニールのビラビラを引っ張って HDD を抜きます。

抜かれちゃいました。

両脇についてたゴムのやつを取ります。

HDD がついてたケース的なものを取り外します。

SSD にさっきのケースを取り付けます。

両脇のゴムのも SSD に取り付けます。

奥まで入れます。ビラビラは元通り中に入れます。

フタを閉めたら完了です。

と、ここまで作業が完了したら、いよいよ期待の「激速 OS 起動」です！

…しかし、ThinkPad の起動画面の後、画面左上にプロンプトが点滅したままで、うんともすんとも言わず、起動しませんでした。。。

起動しなおして、ThinkPad 起動画面の時に ThinkVantage ボタンを押したら、SSD 内のリカバリ領域 (別パーティション) から ThinkVantage Rescue and Recovery (工場出荷時の状態に戻すアプリケーション) がちゃんと起動したので、少なくともリカバリ領域のクローンは出来ている模様。

HDD に挿しかえなおして、USB で接続したら、Windows の領域もちゃんとクローンが作られている。
何が原因なのだろう？

Migrate Easy の FAQ をサイトで検索したら
ラネクシーサポート | Acronis コンシューマ製品 FAQ: クローンしたハードディスクから Windows が起動しません

というページに、「コピー作業が完了した直後に、クローン元とクローン先のハードディスクを接続した状態でコンピュータを起動しないでください。」と赤字で書かれている。

しかし、Migrate Easy は、コピー完了して、正常に終了しようとすると、HDD や SSD を差し換える猶予がまったく与えられず突如再起動してしまうので、その仕様はおかしくないか？とか、それは完了画面に出すべき重要な情報なんじゃないか？とか思った。でも、えー、まさかそんなのが原因なはずないだろ？と疑いつつ、もう一度 HDD クローンを作成。
次は当然ながら作成完了直後に電源長押ししてブッチン切り。

そして、再度 SSD を接続して起動。
しかし OS が起動せず、プロンプトが点滅しているだけの状況はかわらない。

これは恐らく MBR (マスターブートレコード) がちゃんとコピーされなかったか、破損しているために起動しないんだなと判断。

MBR の修復には、 Windows XP 回復コンソールから fixmbr コマンドを実行すればいいという情報を得たものの、ThinkPad X60 に適合する Windows XP の CD-ROM は持っていない。
そういう場合は Microsoft の web サイトから ISO イメージをダウンロードして、FD に保存して、FDD から起動するらしいのだが、そもそも FDD なんて持っていない。。。
今どき、FDD なんて普通持ってないよな。FD 用のイメージしか用意していないなんて頭悪いんじゃないか？

ここに FD のイメージを用いて CD ブータブルな回復コンソールを作る方法が説明されているので、この手順で、回復コンソール用の CD-ROM を作成する。
実に複雑な手順であるが、何とか完成。

しかし、この CD-ROM を入れて ThinkPad を起動しても、回復コンソールの起動途中にブルースクリーンで落ちる。
20 回繰り返したが、必ず同じ場所でブルースクリーンになる。こりゃ、CD-ROM がマズかったかなと思って、別の PC に繋いだら、うまいこと回復コンソールが起動した。
回復コンソールが起動しないのは、どうやら、ThinkPad X60 固有の問題なのかも知れない。

で、回復コンソールが起動するその PC に、SSD を USB で繋いで、回復コンソールを起動して、fixmbr を実行してみたら、うまくいった模様。

意気揚々と SSD を ThinkPad に挿し、電源を入れた…が、状況がかわらない。
んー、これでも MBR がどうしてもおかしいのだろうか。

MBR のコピーが失敗しているのであれば、いったん SSD をちゃんと起動する状態にした後に、元々ちゃんと起動する HDD の中身をコピーすれば、MBR は上書きされずに、起動したというようなことを書いていたサイトを見掛けたので、SSD のリカバリ領域から ThinkVantage Rescue and Recovery を起動して、SSD の中身を、工場出荷時の HDD と同様にしてみた。
もちろんその状態なら Windows は起動する。
そして、その後に Migrate Easy を使って HDD の中身を SSD にコピー。
さすがにこれでいよいよ起動するだろうと思って、元気よく SSD を ThinkPad に挿し、電源を入れた…が、起動しない。

FreeDOS のブータブル CD を作って起動すれば、fdisk コマンドで MBR を修復出来るという情報もあったので、ブータブル CD を作ってみたものの、Invalid Opcode とか言われて、fdisk を起動する段階まで行かない。

次に、再び SSD から ThinkVantage Rescue and Recovery を起動して、SSD の中身を、工場出荷時の HDD と同様にして、SSD に同梱の Acronis True Image で、HDD の C ドライブ (パーティション) のみのバックアップイメージを作って、別ディスクに保存。そこから SDD にリストアしてみた。

イメージを作るのは 1 時間半ぐらいで終わったんだが、SSD へのリストアを開始したら、完了予定まで「残り 14 日」とか出てきた。
ひぃぃ！ 2 週間 ThinkPad 使えないのかぁ！！

と、見ていたら「残り 12 日」「残り 8 日」「残り 2 日」…と段々減っていく。
「残り 22 時間」「残り 16 時間」「残り 12 時間」と、10 分ぐらいで 12 日から 12 時間まで縮まったので、何とかなりそうだなーと思った。
そこからも劇的に残り時間が減っていき、結局リストアにはトータルで 6 時間半ぐらいかかった。
が、6 時間半経って「残り 15 秒」ぐらいの表示の時に、リストアに失敗した旨のメッセージが。

はぅっ！ヤバいっ！！
と、慌てて起動しなおしてみたら、黒い画面に白い文字で Operating System not found とだけ表示された。
バックアップとリストア足して 8 時間完全に無駄。
ここまで来ると、さすがに、部屋で独りながら PC に向かって大きな声で言いましたよ。

死ね！！！

悪戦苦闘にも程がある。

書き換え回数ふんふん言って寿命を気にして考えた手順だが、この時点で既に SSD の中身の大部分を書き換える作業は 6 回を超えている。
どんだけ寿命縮めてんだよと。

いや、サマリーだけ書いて 6 回だが、実はここに書くのもアホらしかったり、恥ずかしかったりして、ここに書いていない作業もある。本当はこの時点で SSD の中身の大部分を書き換える作業を既に 8 回行なっている。

恐らく、ここまで費した総作業時間は 40 時間程度。

で、9 回目にはさすがに観念して、一番最初に書き換え回数を気にして行なった作業

バックアップを取った後に、内蔵 HDD のリカバリ領域からリカバリして、外付け HDD に保存したデータから、元々使っていたファイルとかを取り出し、使い勝手が良い状態になるまで、各種設定をし、OS 入れたてだから非常に安定していながらも、不安定さが大幅に改善された「いつもの環境」と呼べる状態にまで戻しました。

を、内蔵 HDD ではなく、SSD に対して行なった。
最初からそれを行なっていればこの 40 時間に渡る無駄作業をせずに済んだのに…。

で、いよいよ今週から SSD 生活に突入してまだ数日ですが、さすがに驚くのは OS の起動がバカみたいに速いことです。今まで逆に遅過ぎたので、それに比べて 5 倍ぐらいの速度で起動しているように見えます。

他にも起動が妙に重かったアプリケーションはとにかく速いという実感があります。
それ以外はそんなにスゲーっと言うほど何かが速いという実感はないです。
むしろ複数のプロセスが同時に読み書きを行なったりしている状況だと、全体的に処理が固まってしまうような感覚があります。
それは HDD の時にもあったのでしょうが、HDD の時のようにカリカリカリカリ…という音による「ちょっと、今忙しいから待って」みたいな主張が、SSD からは一切感じられないので、一瞬、あれ？壊れたのかな？なんて思ってしまうことが多かったです。

そう、音といえば SSD の場合は HDD のカリカリ音やモーター音がなく静かだという利点があげられますが、正直、そんな音にイライラするほど神経質だったわけではないので、別に…という感じです。
HDD の音に関しては上記のように「今忙しいから待って」という主張を音で感じてた程度で、別にイライラなんかしてないし。

HDD よりは消費電力が遥かに少ないようで、バッテリー駆動の時はバッテリーがだいぶ長持ちするので良いです。30% 以上は駆動時間が延びているかも知れないです。
電気代の節約にもなると思います。微々たるものでしょうが。

あと、しばらく忘れていたのですが、ファイルの中身を読み出すと atime (最終アクセス時刻) 属性が更新されますが、読み出すたびに更新が走ってしまって、SSD だと寿命も縮めるわ、読み込みが重くなったりするわで大変だったので、atime 属性を以下のコマンドを実行することで、今後更新しないようにしました。

C:\WINDOWS>fsutil behavior set disablelastaccess 1

あと、旧 MS-DOS 互換用に 8.3 形式のファイル名の生成 (Program Files が PROGRA~1 みたいになるやつ) が行なわれているのを抑止するために

C:\WINDOWS>fsutil behavior set disable8dot3 1

コマンドも実行しました。

ということで、とりあえず、もうしばらく ThinkPad X60 と付き合っていこうと思います。

で、SSD があまりに良いという実感が沸いたら、MacBook も SSD に換装するんだ。
あと PS3 も。

nipotan at 17:54 | Comments(14) | 技術

December 15, 2008

IPv6 とかよくわからない人間が IPv6 対応サイトを作る際の知っておくべき 8 つの注意点

先日、一般や企業向けに IPv6 対応を支援をする、EDGE Co.Lab v6 というのを始めました。
これを始めるにあたって、弊社情報環境技術研究室の伊勢さんから、「なんかウチでやってるコンテンツで、どれか IPv6 対応しようよ」と、いきなり言われました。

実は IPv6 って何年も前からよく耳にするけど、特にインフラまわりの知識が拙いし、何だかんだ身の回りのほとんどが IPv4 で、それでまぁウマくいってるからよくわからないし、別にどうでもいい…と、IPv6 に対して「現実味がない。時期尚早なのでは？」みたいな勝手な印象を抱いて、毛嫌いしてました。

伊勢さんは 2ch の IPv6 板とかを立ち上げたらしく、IPv6 でアクセスすると、トップページのひろゆきが踊って表示されるそうです。
IPv6 と IPv4 の差って、ひろゆきが踊るか踊らないかの差だけ？とか、そうじゃないのをわかってながら変に牽制しつつ、対応しようとか言われても、IPv6 の何がいいのかよくわからんーとか思って、ボンヤリと引き受けました。

で、その話の中で IPv4 枯渇時計というものを教えてもらって、衝撃を受けました。

実は IPv4 アドレスの枯渇 (予測) が意外に間近に迫っていて、今現在、良い悪いだ議論してようが、毛嫌いをしていようが、近い将来、この業界で働いている限りは免れることの出来ない現実だと感じました。
なのでこれを機に、実験的に fixdap を IPv6 化することにしました。

しかし、何をもって「IPv6 化」と言うのかわからず、何となく調べながら、ちょこちょこいじって、とりあえずは IPv6 対応が完了しました。
2ch の IPv6 板と同様に、IPv6 でアクセスした場合はロゴが変わるようになってます。

IPv4:
fixdap IPv4

IPv6:

実際に見てみたい方はこちらにアクセスしてみてください。
どうでしたか？あなたの環境は IPv6 でしたか？

ちなみに、ロゴが違う以外は、特に違いはありません。もちろん、違いをつけることももちろん可能です (その予定はないです) が。

プロトコルの差異とかは、特に気にはしてない…というか、実はちゃんと理解出来てませんが、実際にやってみると、IPv6 に対応するのはそんなに難しいことでもありませんでした。
今後避けて通れない IPv6 対応をする際、どういうところを注意すれば良いか、要点をまとめてみました。

クライアントとサーバの終端装置が IPv6 対応していないとダメ

サーバ ID (SSL 証明書) は IPv4 だろうが IPv6 だろうが関係ないよ

SSL ページ

Apache の設定は、そんなに難しくないよ

Apache Portable Runtime (APR)

Listen [2001:db8:bad:feed::dead:beef:cafe]:80

NameVirtualHost [2001:db8::babe:face]:80

<VirtualHost [2001:db8::babe:face]:80>
  ServerName babe-face.example.com
    :
    :
</VirtualHost>

Allow from 2001:db8:c0:ffee::/64

疎通確認は ping や traceroute ではないよ

% ping6 2001:db8:bad:face::dead

% traceroute6 2001:db8:bad:face::dead

DNS 登録は A レコードではないからね

IPv6 か IPv4 かの判別はどうすればいいのかな

$ENV{REMOTE_ADDR}

$r->connection->remote_ip

Listen 80

# IP-based virtual hosting
<VirtualHost [2001:db8::babe:face]:80>
  ServerName babe-face.example.com
  RewriteEngine On
    :
    :
  RequestHeader set X-IP-Version 6
</VirtualHost>

<VirtualHost 192.0.2.1:80>
  ServerName babe-face.example.com
  RewriteEngine On
    :
    :
  RequestHeader set X-IP-Version 4
</VirtualHost>

$ENV{HTTP_X_IP_VERSION}

$r->header_in('X-IP-Version')

IP アドレスを保存するカラムとかの長さは足りてるかな

|255.255.255.255|
+----5----0----5+

実際どれぐらい長ければいいのかわかってないのですが

|0000:0000:0000:0000:0000:0000:255.255.255.255|
+----5----0----5----0----5----0----5----0----5+

0000:0000:0000:0000:0000:0000:

0:0:0:0:0:0:

::

アクセス解析がちゃんと出来るかな

以上が注意すべき 8 つのポイントです。

とは言え、実際には IPv4 が枯渇しそうな今の次点でも、IPv6 環境が構築できるような環境がなかなか無いのが実情です。
しかし、来るべき IPv4 枯渇時代に備えて、これらの知識を今のうちに知っておくのは有益なのではないかなと思います。

正直、自分は、環境を提供してもらって、作ったってだけなので、IPv6 化するという基本的なスタート地点より先が未だによくわかってませんが。。。
(これからちゃんと本とか読んで勉強したいと思います)

実際に、環境が整えられないが、IPv6 環境を構築したり、その環境下で検証等をしてみたいという方は、EDGE Co.Lab v6 に応募されてみてはいかがでしょうか。

マスタリングTCP/IP IPv6編

IRIユビキタス研究所
オーム社

Amazon.co.jp で詳細を見る

IPv6 エッセンシャルズ第2版

Silvia Hagen
オライリー・ジャパン

Amazon.co.jp で詳細を見る

IPv6教科書 (インプレス標準教科書シリーズ)

インプレスR&D

Amazon.co.jp で詳細を見る

IPv6ちょー入門

栗林誠也
広文社

Amazon.co.jpで詳細を見る

nipotan at 20:14 | Comments(6) | 技術

November 27, 2008

堀愚霊瑠の指摘で気付いた、はてなスターの静的ファイルとか想像以上にアレな件

id:HolyGrail (堀愚霊瑠氏) の「はてなブックマークが重い件について、Page Detailerというツールを使って調べてみる - id:HolyGrailとid:HoryGrailの区別がつかない日記」とか見てて、色々問題点が指摘されてて、うん、まぁそうだねーとか色々と思いつつ、YSlow は、有用なツールである反面、減点基準が必ずしも全てのサイトに適合しないというか、ハッキリ言ってしまえば Yahoo! Inc. 基準すぎるので、鵜呑みにし過ぎるのもどうかなーとか思ってた。

で、気になったのは

13. Configure ETags

ETagsっていうのはサーバ上のファイルとブラウザのキャッシュが一致しているかどうかを検証するためのものなのですが、正しく利用できていないのであれば、ETagsは無駄なだけなので取り除いてやりましょう、という項目です。

http://s.hatena.ne.jp/js/HatenaStar.js

http://s.hatena.ne.jp/images/comment.gif

http://s.hatena.ne.jp/images/add.gif

http://s.hatena.ne.jp/images/star.gif

の4つのファイルに対してETagsヘッダが出ているようなので、必要なければ取り除いてヘッダサイズを減らしましょう。

という箇所。

ETag 自体は「正しく利用していれば」有用だし、ヘッダサイズ云々って言うほどデカくもないし、アレだなーとか思いつつ、なんで「正しく利用できていないのであれば」という前提のものに引っかかったのかなというのが非常に気になった。

ちなみに、ETag ヘッダは、デフォルトではそのファイルの inode 番号、ファイルサイズ、更新時刻 (epoch 秒) の値を 16 進数表記して、ハイフンで繋いだ文字列をダブルクォーテーションで括ったもの。
Perl で同じような文字列を出力するなら、

printf qq/ETag: "%x-%x-%x"\n/, (stat $filename)[1, 7, 9];

こんな感じ。

-- 以下、HTTP とかにさほど詳しくない人向けの説明。

これが、HTTP レスポンスに含まれていたら、次に HTTP リクエストする際に、ブラウザ側でキャッシュした時の ETag の値を If-None-Match ヘッダに渡します。サーバは、今現在サーバ上にあるファイルの ETag の値が一致するかを確認して、一致した場合は 304 (Not Modified) の HTTP ステータスを返し、ブラウザは「以前キャッシュした時から更新されていない」と解釈して、キャッシュされているファイルを再利用します。

ETag の値を返さない場合、Last-Modified ヘッダが HTTP レスポンスに含まれていたら、次に HTTP リクエストする際に、ブラウザ側でキャッシュした時の Last-Modified の値を If-Modified-Since ヘッダに渡します。サーバは、今現在サーバ上にあるファイルの Last-Modified の値がそれ以前であるかを確認して、それ以前だった場合は 304 (Not Modified) の HTTP ステータスを返し、ブラウザは「以前キャッシュした時から更新されていない」と解釈して、キャッシュされているファイルを再利用します。

-- 以上、HTTP とかにさほど詳しくない人向けの説明。

で、思ったのは「はてなスター (だけ？) の静的ファイルが ETag を正しく使えてないから引っ掛かったのかな」と。
よくよく考えたらはてなスターはこのブログにも貼ってあるし、はてなの色々なコンテンツに大量に利用されている事実を考えたら、もし ETag を正しく使えてないのなら、無駄なトラフィックを大量に生み出しているわけで、決して侮れない。
ナニゲに HatenaStar.js はデカいし。

考えられるありがちな落し穴を考えると、「基本的には同じファイル」なんだけど、配置されているサーバが複数台数に分散されているような場合、ほぼ間違いなくそれぞれのサーバで inode 番号が変わるので、ETag に含まれる値の inode の部分 (先頭部分) はリクエストを処理するサーバによって異なってくる。

そういう場合は、ETag を吐かないようにさえすれば、Last-Modified と If-Modified-Since でいいあんばいにキャッシュ比較とかをしてくれる。
Apache の場合は FileETag ディレクティブを利用して、以下のように設定すれば ETag を吐かなくなる。

FileETag None

あるいは、ファイルサイズ、更新時刻 (epoch 秒) は一緒なのであれば、ETag を吐く時に不要になるのは inode 番号だけ。では、ETag の値から inode 番号を抑制すれば済む問題なので、同様に FileETag ディレクティブを利用して、inode 番号だけ利用しないように、以下のように設定するのがセオリー。

FileETag Size MTime

あるいは

FileETag -INode

こうすることで、複数台数であっても、ファイルサイズと更新時刻によって生成された値によって、ETag と If-None-Match でいいあんばいにキャッシュ比較とかをしてくれる。

じゃあ、はてなスターは、このありがちな落し穴をおかしているのではないだろうか？とアタリをつけて、HTTP HEAD リクエストを送出してみて確認してみた。

% telnet s.hatena.ne.jp 80
Trying 59.106.108.97...
Connected to s.hatena.ne.jp.
Escape character is '^]'.
HEAD /js/HatenaStar.js HTTP/1.1
Host: s.hatena.ne.jp
Cookie: b=hoge
Connection: close

HTTP/1.1 200 OK
Date: Thu, 27 Nov 2008 00:53:51 GMT
Server: Apache
Last-Modified: Tue, 04 Nov 2008 09:25:37 GMT
ETag: "b88995-1697f-45ad9a572a640"
Accept-Ranges: bytes
Content-Length: 92543
Vary: Accept-Encoding
Connection: close
Content-Type: application/x-javascript

Connection closed by foreign host.

* ちなみに、b=hoge とかいう Cookie を送っているのは、session cookie をリクエストの都度吐いてくるので、迷惑にならないように「既に session cookie 持ってるよ」と欺いてます

案の定、ETag は三つの値がハイフンで繋がれています。
恐らく先頭の b88995 は inode 番号なので、複数台のサーバで運用されている場合は、邪魔になる恐れがあります。
続いて、それを検証するために、この ETag の値と、Last-Modified の値を、それぞれ If-None-Match と If-Modified-Since に含んでみたら、ちゃんと 304 (Not Modified) ステータスを返してくれるか検証してみました。

% telnet s.hatena.ne.jp 80
Trying 59.106.108.97...
Connected to s.hatena.ne.jp.
Escape character is '^]'.
HEAD /js/HatenaStar.js HTTP/1.1
Host: s.hatena.ne.jp
Connection: close
Cookie: b=hoge
If-Modified-Since: Tue, 04 Nov 2008 09:25:37 GMT
If-None-Match: "b88995-1697f-45ad9a572a640"

HTTP/1.1 200 OK
Date: Thu, 27 Nov 2008 00:54:48 GMT
Server: Apache
Last-Modified: Tue, 04 Nov 2008 09:20:37 GMT
ETag: "f9665-1697f-45ad993910340"
Accept-Ranges: bytes
Content-Length: 92543
Vary: Accept-Encoding
Connection: close
Content-Type: application/x-javascript

Connection closed by foreign host.

304 (Not Modified) を期待していたら、200 (OK) ステータスが返ってきました。
ETag を見るとやはり先頭が f9665 で先程とは違うので、inode 番号が違います。
でも Content-Length も一緒だし、MD5 の checksum を見ても同じなので、同じ JS ファイルであることは間違いありません。
でも「あなたのとこにキャッシュされているファイルとは、比較するかぎりどうも別のファイルだから、このデッカイ JS ファイルをあらためて読み込んでキャッシュしなおしてよ」とブラウザに訴えてきているのです。
堀愚霊瑠氏の指摘するとおり、正しく使えてない、無駄な ETag を吐いてます。
何度か繰り返してみると、ETag によって返される inode 番号は 2 種類であることから、「はてなスターは 2 台のサーバから静的なファイルを返している」ということがわかります。

結論: はてなスターは ETag を吐かないようにするか、inode 番号を利用しないように正して、きちんとブラウザのキャッシュを有効活用させるようにして欲しいです！

って、気持ちよくしめようとしたら、現実はもっとひどいことに気付いた。

目を凝らしてよく見れば ETag だけの問題ではない。
Last-Modified が 2 台それぞれのサーバによって違う。
5 分も違う。
当然、ETag も inode 番号の部分だけじゃなく、更新時刻の部分も違う。
ETag を抑止しても、Last-Modified がバラバラだから、古いほうを先に GET してしまうと結局新しいほうを GET しに行った時に 304 ステータスは返らない。

はてなスターは、あれだけのパーツ画像とデッカイ JS をバラまいておいて、ブラウザにキャッシュさせる気はないのだろうか。。

ファイルの属性は転送しないようなよっぽど変なデプロイツールを使っているのか、あるいはインターンで来た学生に JS を精密に写経させていたのだろうか。
ちなみに、上記であがっていた 4 つのファイルのそれぞれが、ETag と Last-Modified 共にサーバごとに合致しない。
GIF 画像ファイルまでもがそういう状況なのだから、インターンで来た学生にバイナリエディタで GIF を精密に写経させていたのだろうか。

ちなみに、今日の午前中の時点での各ファイルの ETag、Last-Modified の組み合わせを列挙してみた。

■ http://s.hatena.ne.jp/js/HatenaStar.js

Last-Modified: Tue, 04 Nov 2008 09:25:37 GMT
ETag: "b88995-1697f-45ad9a572a640"

Last-Modified: Tue, 04 Nov 2008 09:20:37 GMT
ETag: "f9665-1697f-45ad993910340"

■ http://s.hatena.ne.jp/images/comment.gif

Last-Modified: Tue, 13 May 2008 13:04:52 GMT
ETag: "f8ff2-362-44d1c4f516500"

Last-Modified: Tue, 13 May 2008 13:04:53 GMT
ETag: "b88361-362-44d1c4f60a740"

■ http://s.hatena.ne.jp/images/add.gif

Last-Modified: Tue, 13 May 2008 13:04:52 GMT
ETag: "f8fe8-51-44d1c4f516500"

Last-Modified: Tue, 13 May 2008 13:04:53 GMT
ETag: "b88357-51-44d1c4f60a740"

■ http://s.hatena.ne.jp/images/star.gif

Last-Modified: Tue, 13 May 2008 13:04:52 GMT
ETag: "f9044-b2-44d1c4f516500"

Last-Modified: Tue, 13 May 2008 13:04:53 GMT
ETag: "b883b3-b2-44d1c4f60a740"

これらを直して欲しいと切に願うと同時に、それぞれのファイルのヘッダがいつ正しく修正されるかを、今後継続して生暖かく見つめていきたいと思いました。

nipotan at 11:53 | Comments(1) | TrackBack(1) | 技術

にぽたん研究所

技術

February 13, 2009

BPM を調べるやつ

February 05, 2009

正規表現で、ソーシャルブックマーカブルな URL かそうでないかを判定する

January 16, 2009

ThinkPad X60 で SSD の換装をしてみた

死ね！！！

December 15, 2008

IPv6 とかよくわからない人間が IPv6 対応サイトを作る際の知っておくべき 8 つの注意点

November 27, 2008

堀愚霊瑠の指摘で気付いた、はてなスターの静的ファイルとか想像以上にアレな件