November 2008
November 27, 2008
id:HolyGrail (堀愚霊瑠氏) の「はてなブックマークが重い件について、Page Detailerというツールを使って調べてみる - id:HolyGrailとid:HoryGrailの区別がつかない日記」とか見てて、色々問題点が指摘されてて、うん、まぁそうだねーとか色々と思いつつ、YSlow は、有用なツールである反面、減点基準が必ずしも全てのサイトに適合しないというか、ハッキリ言ってしまえば Yahoo! Inc. 基準すぎるので、鵜呑みにし過ぎるのもどうかなーとか思ってた。
で、気になったのは
ETag 自体は「正しく利用していれば」有用だし、ヘッダサイズ云々って言うほどデカくもないし、アレだなーとか思いつつ、なんで「正しく利用できていないのであれば」という前提のものに引っかかったのかなというのが非常に気になった。
ちなみに、ETag ヘッダは、デフォルトではそのファイルの inode 番号、ファイルサイズ、更新時刻 (epoch 秒) の値を 16 進数表記して、ハイフンで繋いだ文字列をダブルクォーテーションで括ったもの。
Perl で同じような文字列を出力するなら、
-- 以下、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 を吐かなくなる。
あるいは、ファイルサイズ、更新時刻 (epoch 秒) は一緒なのであれば、ETag を吐く時に不要になるのは inode 番号だけ。では、ETag の値から inode 番号を抑制すれば済む問題なので、同様に FileETag ディレクティブを利用して、inode 番号だけ利用しないように、以下のように設定するのがセオリー。
じゃあ、はてなスターは、このありがちな落し穴をおかしているのではないだろうか?とアタリをつけて、HTTP HEAD リクエストを送出してみて確認してみた。
案の定、ETag は三つの値がハイフンで繋がれています。
恐らく先頭の b88995 は inode 番号なので、複数台のサーバで運用されている場合は、邪魔になる恐れがあります。
続いて、それを検証するために、この ETag の値と、Last-Modified の値を、それぞれ If-None-Match と If-Modified-Since に含んでみたら、ちゃんと 304 (Not Modified) ステータスを返してくれるか検証してみました。
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
■ http://s.hatena.ne.jp/images/comment.gif
■ http://s.hatena.ne.jp/images/add.gif
■ http://s.hatena.ne.jp/images/star.gif
これらを直して欲しいと切に願うと同時に、それぞれのファイルのヘッダがいつ正しく修正されるかを、今後継続して生暖かく見つめていきたいと思いました。
で、気になったのは
という箇所。13. Configure ETags
ETagsっていうのはサーバ上のファイルとブラウザのキャッシュが一致しているかどうかを検証するためのものなのですが、正しく利用できていないのであれば、ETagsは無駄なだけなので取り除いてやりましょう、という項目です。
http://s.hatena.ne.jp/js/HatenaStar.js
http://s.hatena.ne.jp/images/comment.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"
これらを直して欲しいと切に願うと同時に、それぞれのファイルのヘッダがいつ正しく修正されるかを、今後継続して生暖かく見つめていきたいと思いました。
November 20, 2008
Date: 18 Nov 2008 12:36:49 +0900
From: auction-patrol-master at mail.yahoo.co.jp
Subject: Yahoo!オークションより - 利用停止のお知らせ
nipotan 様
Yahoo! JAPANです。
お客様のYahoo! JAPAN IDは、利用状況、利用規約および
Yahoo!オークション・ガイドラインにもとづき、
Yahoo!オークションの利用を停止いたしました。
このメールに心当たりのない場合は、お手数ですが、
以下のページよりご連絡ください。
http://ms.yahoo.co.jp/bin/auction-exw/feedback
以上、よろしくお願いいたします
------------------------------
Yahoo!オークション
http://auctions.yahoo.co.jp/

「このメールに心当たりのない場合」だったので、一昨日連絡したのに完全放置。
とりあえず今日もまた連絡してみたけど、今のところ放置されている。
どうなってんだ一体。
ちなみに、放置がひどいから、代表電話番号にでも電話しようかなーって思ったら、Twitter で「電話してもメールするように言われるだけ」と教わった。
そうなのかー。
というか、最後にヤフオク使ったの去年の 7/17 だぞ。あとは入札も出品もしてないのに、何で停止なんだ。
むしろ、最近出品しようかなぁーと思って、商品の写真をデジカメで撮ってみたんだけど、フラッシュたくとテカるし、たかなきゃボケるし…ってんで、わざわざ三脚を買ったのにな。。
プレミアム会員なんだが、アカウントが停止状態から復活する場合、使えなかった分は会費日割でちゃんと返金してくれるのかなぁ?
使ってないで払い続けてるだけなんだから、たかだか一日 10 円程度、返金してくれなくても一緒だし、どうでもいいっちゃどうでもいいんだけど、お前らの意味不明な理由も説明しない勝手な都合でアカウント止めておいて、金だけ取るとかはおかしいだろ。
これ、誰か解決する方法を知ってたら教えてください。
November 06, 2008

シリコンバレーで働く日本人エンジニアの方の多くが参加していて、勉強したり、交流したりする場を提供してくれていますので、そこで開催されるセミナーやギークサロン等に積極的に参加することによって、色々刺激を受けたり、技術トレンドを肌で感じたり出来ます。
JTPA は、日本からシリコンバレーでのキャリアを目指す人たち向けに、「シリコンバレー・ツアー」というのを毎年開催してきたようですが、今年は「シリコンバレー・カンファレンス」というのを実験的に開催するようです。
なんかネットでよく見掛ける (JTPA ボードメンバーの) あの有名な方々の講演や、シリコンバレーに住んで働く上でどうなのよ?的なお話とかをパネルディスカッションするようです。
日本の外に可能性を求めたいと思う方、シリコンバレーで働くことに興味がある方は、是非参加されてみてはいかがでしょうか。
シリコンバレーでしか感じられない何かをきっと感じ取れるはずです。
募集はアメリカ西海岸時間で 11/15 から (ちなみに今なら日本時間からマイナス 17 時間したのが西海岸時間) だそうです。
来年 3/21(土) に開催ですので、日本でお勤めの方も、3/20(金) が春分の日で、三連休だし、気軽に参加出来そうですね。
あ、
NRT 3/20 午後発 → SFO 3/20 昼着
SFO 3/22 昼初 → NRT 3/23 午後着
なので、3/23 は有給を取ったほうがいいかもですね。。
ツアーの詳細については、下記関連リンクをご参照ください。
関連リンク:
JTPAサイト記事
プレスリリース
November 04, 2008
livedoor Blog の画面を開くと、いっつもいっつも「パンドラ」というドラマの第一話の DVD が先着 1 万人に当たる とか出てるから、「1 万人とかすげー当たりそう過ぎる」と思って、このあいだ何の気なしに申し込んでみたら、どうも当たったようで、この連休中に家に届いてた。
「パンドラ」ってのは、今年の春に WOWOW でやっていた連ドラだそうな。WOWOW 初の連ドラっていう話だったかな。そもそもあんまりドラマ見ないから、まぁ、もし当たったら見るかーぐらいの軽いノリだったんだけど、実際当たったから軽いノリで見てみた。
まぁ、結構面白そうだなーとか思った。
どんな癌にでも効く抗癌剤を長年に渡って研究し続けて、マウスによる実験でやっと成果が見られたので、人体を対象にその抗癌剤の治験を認めてくれるように医学部長に頼むが、嘲笑われて認められず、そんな時に出会った余命僅かな末期癌の少女の身体を使って、秘密裏に治験をするみたいな話。
どんな癌にでも効く抗癌剤というのは、世界中の人を幸せにする発見なのかも知れないけど、それがもし実用化されたら、世界中の平均寿命は伸びて、一層高齢者社会になって、年金とかの制度は破綻するし、そう考えたら、本当に皆全員が幸せになる発見なのか。本当は取り返しのつかないパンドラの箱を開けることになってしまうんじゃないか。みたいな話。
と、まぁ、第一話が大まかにこんな話なんだけどどうも続きが見たくなってしまった。。
買おうかな。どうしようかな。迷う。
ただ、なんかキャスティングとかが、あまりにベテランすぎるせいか、妙に過去の他のドラマとかぶって、変な風に感じながら見てしまった。
山本耕史と山本圭は「ひとつ屋根の下」だし…。
特に山本圭が開業医とか、設定がかぶりすぎ。
柳葉敏郎と小野武彦 (と小西真奈美) は「踊る大捜査線 (THE MOVIE 2)」だし…。
室井さん、管理官から刑事に格下げ食らったのかとか。
あと、國村隼は台詞をボソボソ言ってて何言ってんだか聞き取りにくかったなぁ。それが芸風なんだろうけど。
でもこれ、第一話しかもらえないとかアレだなぁ。
抽選でコレクターズ・ボックスくれたらいいのに。
「パンドラ」ってのは、今年の春に WOWOW でやっていた連ドラだそうな。WOWOW 初の連ドラっていう話だったかな。そもそもあんまりドラマ見ないから、まぁ、もし当たったら見るかーぐらいの軽いノリだったんだけど、実際当たったから軽いノリで見てみた。
まぁ、結構面白そうだなーとか思った。
どんな癌にでも効く抗癌剤を長年に渡って研究し続けて、マウスによる実験でやっと成果が見られたので、人体を対象にその抗癌剤の治験を認めてくれるように医学部長に頼むが、嘲笑われて認められず、そんな時に出会った余命僅かな末期癌の少女の身体を使って、秘密裏に治験をするみたいな話。
どんな癌にでも効く抗癌剤というのは、世界中の人を幸せにする発見なのかも知れないけど、それがもし実用化されたら、世界中の平均寿命は伸びて、一層高齢者社会になって、年金とかの制度は破綻するし、そう考えたら、本当に皆全員が幸せになる発見なのか。本当は取り返しのつかないパンドラの箱を開けることになってしまうんじゃないか。みたいな話。
と、まぁ、第一話が大まかにこんな話なんだけどどうも続きが見たくなってしまった。。
買おうかな。どうしようかな。迷う。
ただ、なんかキャスティングとかが、あまりにベテランすぎるせいか、妙に過去の他のドラマとかぶって、変な風に感じながら見てしまった。
山本耕史と山本圭は「ひとつ屋根の下」だし…。
特に山本圭が開業医とか、設定がかぶりすぎ。
柳葉敏郎と小野武彦 (と小西真奈美) は「踊る大捜査線 (THE MOVIE 2)」だし…。
室井さん、管理官から刑事に格下げ食らったのかとか。
あと、國村隼は台詞をボソボソ言ってて何言ってんだか聞き取りにくかったなぁ。それが芸風なんだろうけど。
でもこれ、第一話しかもらえないとかアレだなぁ。
抽選でコレクターズ・ボックスくれたらいいのに。