Google

佐々木俊尚氏の「グーグル - Google 既存のビジネスを破壊する」を読了。所要時間は1時間57分53秒。

- Google そのものというより、ウェブの潮流を解説した本

この本では、ここ5年くらいに Google が発表したサービス、Google がどうやって利益を上げているのか、そして Google が何をしようとしているのかを知ることができる。技術的な描写はほとんど無い。Google は高い技術力と膨大なコンピュータ資源がある、ということくらいしかない。全体的に読みやすかった。

この本は Google を題材にしているが、取り扱っている題材は Google だけに限定した話ではない。検索、ロングテール、アテンションの収集、データの蓄積などは他の企業なども取り組んでいる。つまり、Web で起きていることと、今後の潮流を書いている本だ。ただ、Google は成長して大きな利益を上げる企業になっているようだし、優れた技術者を大勢抱えていることもあって、Google の動向はいやがおうにも目にとまる。そのため、Google を解説することはこれらの題材の先端の部分を解説することになる。この本はそういう書き方をしている。

第6章の管理と監視が進んだ社会は、改めて指摘されると不安になる。著者も書いているが、これは Google がやらなくても、テクノロジーが進めば多くの企業で十分実現可能になる。それが実用化されるのはいつになるかわからないけど、少しずつ進んでいく。過去にそういう便利な社会を想像して胸を高鳴らせたことがあるけど、いざそれが可能になると、その陰の部分が気になってくる。

個人的には便利さを重視して、こういった社会を受け入れることになりそう。人格を複数用意し、それぞれの人格に情報を分散させて個人の特定をされにくくするなど、ある程度の自衛はするだろうけど、技術が進むとそれも無力なような気がする。というか、今でさえそういった自衛を不完全にしかできていない私なので、技術が進んだ社会で私がそれを完璧にこなすのは難しいだろう。

- グーグル - Google 既存のビジネスを破壊するに書いてあったことのメモ

以下、書いてあったことのメモ。

1章。
Google は、テクノロジーを使って既存の仕組みを破壊していく。様々なサービスを無償でユーザに提供し、既存のプレイヤー達を駆逐し始めている。

2章。
検索は、ユーザーの要求そのものに非常に距離の近い技術である。そこには大きな市場がある。検索エンジン広告は、このことをうまく利用したシステムだ。

3章。
検索エンジン広告は、いままでのメディアがカバーしきれなかった領域や、カバーできたとしてもコストがかかりすぎる領域を低コストでカバーすることができる。羽田空港の民間駐車場の物語はその好例だった。

4章。
検索という技術とインターネットによって、いままでカバーされなかった領域をカバーすることとができるようになった。この領域はロングテールと呼ばれている。

5章。
これからの時代では、アテンション、すなわちどれだけ注目を集められるかに価値がある。注目が多ければ多いほど、人やデータが集まる。そこに広告を絡めることで莫大な利益を生み出す。これは広告代理店のビジネスモデルである。

6章。
あらゆるデータを蓄積していくと、それは神の存在を生み出す。そして、その神から見放されることは存在の消滅を意味するようになる。また、国家による監視よりも、データを持っている民間による監視が進む。

ザ・サーチ を読了。Google の歩みについて書かれた本。以下、断片的にメモ。

検索を単なるキーワードマッチではなく「ユーザーが探している答え」を返すものと位置づけ、日々洗練を重ねているとのこと。ユーザーニーズを最重視し、つねにユーザの望む物を提供する。そして、そこにはビジネスチャンスがあるというのが Google の考え方。確かに数年前の Google はこういうイメージだった。私の中には Google に対して今でもこのイメージを持ってはいるが、もうちょっと他の要素が入り込んでる感じがする。上手く言えないけど。

ユーザの探している答えを返すコンピュータの目標としてTVドラマ「スタートレック」に出てくるコンピュータを挙げていた。スタートレックのコンピュータは音声入出力が可能で、声で質問を投げかけると声で答えてくれる。確かに、あれなら誰でも使えるし、ある程度の知性を備えているコンピュータではある。

でも、スタートレックのコンピュータは、エンジニアのベラナ・トレス中尉の独り言にも反応して「質問の意味を理解できません」などとエラーを出してしまい「あなたには聞いてないわ」と言われてたたくらいだから、あんまり賢いというイメージはない。ストレージのデータ量はかなり多くて、膨大なデータは持ってはいるようだけど。

ユーザーのあらゆる行動の履歴は宝の山だ。誰が、いつ、どんなクエリで、どんな情報に、どこから、どんな機器を使って、どれだけの時間アクセスしたか。これをひたすら蓄積し、分析し、サービスを提供するためのデータとして使う。これは検索業界に限らず、あらゆる業種にあてはまる。こういったデータから常にユーザのニーズを意識することが重要、ということを再確認した。

本の構成はオーソドックスで、こういう成功企業分析物ではよくあるタイプ。Google とは何か、検索とは何かから始まり、検索エンジン業界の歴史を紹介。その後スタンフォード大学で Google が生まれ、会社を設立し、IPO し、現在の Google まで解説。そして今の検索エンジンが取り組んでいる課題と、そこから見える将来を解説している。

Google 創業者がスタンフォード大学時代の試行錯誤の連続は面白い。膨大なトラフィックで大学の帯域を食いつぶしたり、相手先サーバに高負荷を与えてトラブルになったり。それを乗り越えて Google が大きくなっていくところは、他の企業と変わらない。違いはその成長の速度が異常に速いという所だ。そこに Google のすごさを見た。

Gmail でスパムが振り分けられて格納されるディレクトリに一通もスパムがないと Hooray, no spam here! って言われる。

スパムも含めて大量のメールがディレクトリに存在している方が、大容量のメールボックスとスパムフィルタ搭載を謳う Gmail らしさがある。でも、「スパムないよ!」 と無邪気に喜んでいる Gmail はなんだかほほえましい。私はこの表現が好きで、ついついスパムディレクトリを空にしてメッセージを見たくなる。

Hooray って応援団の「ふれー、ふれー!」の「ふれー」なのか。「オーライ!」のことかと思ったよ。
辞書を引くまで知らなかったけど、「ふれー」って「ばんざーい」って意味なんだね。

検索キーワード広告サービスのオーバーチュア社では、検索連動広告枠の価格をオークションで決めている。そのオークションの高額入札キーワードの例が以下。金額は一クリックあたりの入札価格。

キャッシング 3517円
融資 2345円
バイク 買い取り 2014円
自動車保険 1701円
探偵 1500円
浮気調査 1500円
IT 転職 917円
中古車 買取 707円
プチ整形 622円

via: 日経ビジネス2005年10月31日号33ページ。

キャッシングがすごい。一クリックされただけで広告主は3517円も支払うってことか。広告主はそれでも利益が出るビジネスモデルを持ってるんだなあ。全体的に、扱う商品の単価が高いとキーワードも高額。そういう意味で、不動産とかが入ってるかと思ったけど、そうでもないのかな。

「人に言えない言葉」がネットでは人気というのは頷ける。お金のこととか、体のこととか、人間関係とか、悩みを打ち明けられる人がいない場合はネットがその役割を担う。同じ問題を抱えてる人がサイトを作ってるかもしれないし、何よりネットで検索するだけなら簡単だ。

上記のキーワードの価格はオーバーチュアの例だけど、他の検索連動型広告サービスも似たような金額なんだろうな。でもキーワードが高く売れても、私のように広告を表示する側のウェブサイトにはあまりお金が回ってこないのが残念。儲かってないのは私のところだけかもしれないけど。ただ、レンタルサーバー代はまかなえるようになった。そのおかげで sonic64.com を維持できている。

Google Adsense と Amazon、そして何より、私のサイトを見てくれている方に感謝します。

Google Analytics の解析用タグ (トラッキングコード) の挿入位置が body 要素の内の末尾に変更になっていた。今までは head 要素内に入れることになっていた。

2005-11-17 に書いた「Google Analytics のタグを head に入れる理由は?」で疑問を呈し、
2005-11-19 の「Google Analytics サポートからタグ位置について返答」で Google Analytics サポートから「head に入れてください」という趣旨の回答をもらっていたが、いつの間にか変更になっていたようだ。

Google Analytics - ウェブ サイトにトラッキング コードを追加するにはどうすればよいですか。
https://www.google.com/support/analytics/bin/answer.py?answe ...

このコードをコピーし、解析したい全てのページ下部にある、</body>タグの真上に貼り付けてください。

私は head 要素内にトラッキングコードを配置することを推奨されていた頃から body 要素の末尾にトラッキングコードを配置していた。それで全く問題なく解析できている。

via: しげふみメモ:Google Analyticsのタグ位置が変更
http://blog.livedoor.jp/hakin/archives/50265598.html

- 今度は逆に head 要素に入れておくとどうなるの?

あまのじゃくな考えかもしれないけど、今度は逆に body の末尾にトラッキングコードを配置せずに、head 要素内に配置するとどうなるんだろう? 普通に考えれば、既存の head に配置しているユーザーを切り捨てるわけがないので、head に配置していてもとくに問題なくアクセスをトラッキングできるはず。

Gmail のごみ箱ディレクトリである Trash ディレクトリのメールが30日経過で削除されるようになった。

いままでは messages that have been in Trash more than 30 days will be automatically deleted (30日経つと削除されます) と書かれていたが、なぜか実際には動作していなかった。2005-01-05 の「Gmail の Trash のメールが 30日経っても削除されない」で書いた。

私は 2004-11-09 の「GMail をバックアップストレージとして使う」などで Gmail を活用しているため、メールがあふれたりしていた。今日見たら使用している容量が一気に減っていた。もしかしてと思って Trash ディレクトリを見たら、ちょうど一ヶ月を境にメールが全部消えていた。よかったー。

ちなみに容量表示。

You are currently using 666 MB (25%) of your 2674 MB.

なんか不吉な数字だけどまあいいや。

友達に「http://sonic64.com/img/mail.png の画像ってどうやって作ったの?」と聞かれた。どこかの画像生成サービスで作ったということは覚えてるんだけど、サービスの URL がわからない。「ウェブ全体から検索」に切り替えたうえで、Google で Gmail Icon を検索するとヒット。

E-Mail Icon Generator
http://services.nexodyne.com/email/

このページだったかなあ? 違うような気もするけど、とりあえず生成してくれる画像は想像通りなので、たぶんここだろう。

E-Mail Icon Generator は多数のメールサービスに対応していて、それぞれのサービスの意匠を反映した画像を作ってくれる。こんな感じ。

Gmail
http://services.nexodyne.com/email/icon/b6N0IZUe0MU%3D/ZRw7P ...

Yahoo.co.jp
http://services.nexodyne.com/email/icon/JxajfHjVQRk%3D/hklZ% ...

Hotmail
http://services.nexodyne.com/email/icon/gSwcZ9PsmoM%3D/6vmnU ...

現時点で対応しているサービスは以下の通り。

AOL
ATT
Bigfoot
Blueyonder
Comcast
Cox
Earthlink
GMail
Hotmail
Lycos
MSN
Mac
Netscape
QQ
Rocket
Rogers
SBC
Sina
Spymac
Sympatico
VIPSina
Verizon
Yahoo

- みんなが同じ画像生成サービスを使うと、スパム業者に画像解析されちゃうのでは?

メールアドレスをテキストではなく画像にする理由の一つは、スパム業者やワームにアドレスを収集されないようにするため。でも、みんながみんな同じメールアドレス画像生成サービスを使っていると、画像のパターンからアドレス文字列を解析されてしまうかもしれない。

とくに、画像を自分のサイトにアップロードせずに生成サービスの URL を直接参照して画像を表示させるようにしていると、アドレス収集者に「この画像はメールアドレス画像」というヒントを与えてしまうことになり、より危険性が増すだろう。それを防ぐためには、自分の管理しているドメインや無料ホームページスペースに、メールアドレス画像と類推されないようなファイル名を付けてアップロードするのがよい。前述のメールアドレス画像のサンプルへのリンクなどは危険だ。たとえば、Gmail のメールアドレス画像 URL http://services.nexodyne.com/email/icon/b6N0IZUe0MU%3D/ZRw7P ... なら %3D/R01haWw%3D/0 という文字列が入るようだし。

なんか過敏になってるような気もするが、そのくらい用心しないとスパムは減らない。

Google Analytics のサポートへ送信した質問に回答があった。意外と早かったね。

ちなみに 2005-11-17 に書いた「Google Analytics のタグを head に入れる理由は?」で送信した質問は以下の通り。

トラッキングコードのインストール位置についての質問です。
質問は二つありあます。

1.
トラッキングコードが JavaScript なのであれば、head 要素以外の場所に
インストールしても動作するのではないでしょうか?

2.
もし head 要素以外の場所にインストールした場合、何か問題はありますか?
たとえば、トラッキングが正常におこなわれない、トラッキングの精度が落ちる、
Google がトラッキングコードを認識しにくくなる、といった不都合はありますか?

以上、よろしくお願いいたします。

Google Analytics サポートからの回答を以下に転載。私の本名の部分は伏せたが、それ以外は原文のまま。

******** *** 様

平素より Google Analytics をご利用いただき、誠にありがとうございます。

このトラッキングシステムは <HEAD></HEAD>タグの間に挿入していただかなければ正常に作動いたしません。
何卒ご理解賜りますようお願い申し上げます。

Google Analytics サポート

ほとんど質問の答えになってない。要するに企業秘密があるので答えられないか、答えたくないか、ヘルプデスク担当者向けマニュアルがないかのいずれかなんだろう。

- 「正常に動作しない」というのはどういうこと? 本当に動かない?

正常に動作しないというのはどういうことだろう? 精度が悪くなる? トラッキングが全くなされない? 「サイトの確認」ができない? 何だろう? ただ、2005-11-17 で書いたように、トラッキングコードを head 要素に入れずに html の一番下の方に配置するように変更したが、問題なくレポートが継続して表示されている。dkiroku さんも私と同様にレポートが表示されているそうだ。

Google Analytics のタグを head に入れる理由は?
http://dkiroku.com/2005-11-18-15.html

で、疑問に思っているのは、なんでトラッキング用のコードのインストール位
置が head 限定なのかということ。

知らなかった。
でもheadに入れてなくてもレポートは出ていますよ。

私と dkiroku さんの2例しかないが、とりあえず解析は可能なようだ。

ただ一つ気になる点がある。私は最初は head 要素にインストールして「サイトの確認」を済ませ、その後疑問に思ってトラッキングコードを html の下の方に移動させた。そうせずに、全く最初から head 要素以外の場所にインストールした場合はどうなるだろう? とりあえず http://sonic64.com/ を解析対象に追加して実験してみることにした。これでいつまで経ってもサイトの確認がなされない場合は、サイトの確認の問題が原因の一つだと推測できる。

追記。
最初から head 要素以外の場所にインストールした http://sonic64.com/ も、レポートが表示されるようになった。とりあえず問題なさそう。

- インストール位置による HTTP トランザクションの中身の変化はない

ふと思ったので、ブラウザが www.google-analytics.com に送信している内容とその応答、いわゆる HTTP トランザクションの中身を比較してみることにした。たぶん違いはないと思うけど。でも、これ載せちゃっていいのかな? 私の環境固有の情報とかかなり入ってるんだけど・・・まあいいか。

まず、当サイト Landscape 流に html の末尾付近に配置した場合。

GET /__utm.gif?utmwv=1&utmn=1809224424&utmsr=1600x1200&utmsc=32-bit&utmul=ja-jp&utmje=0&utmfl=6.0%20%20r29&utmdt=Google%20Analytics%20%u306E%u30BF%u30B0%u3092%20head%20%u306B%u5165%u308C%u308B%u7406%u7531%u306F%3F&utmhn=sonic64.com&utmr=0&utmp=/2005-11-17.html&utmac=UA-54034-1&utmcc=__utma%3D160379711.1091067899.1131959904.1132385137.1132444634.6%3B+__utmb%3D160379711%3B+__utmc%3D160379711%3B+__utmz%3D160379711.1131959904.1.1.utmccn%3D%28direct%29%7Cutmcsr%3D%28direct%29%7Cutmcmd%3D%28none%29%3B HTTP/1.1
Host: www.google-analytics.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Accept: image/png,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://sonic64.com/2005-11-17.html
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.x 200 OK
Content-Type: image/gif
Last-Modified: Sat, 19 Nov 2005 14:09:27 GMT
Server: ucfe
Content-Length: 35
Date: Sat, 19 Nov 2005 23:57:30 GMT

Google Analytics の指示通り head 要素内に配置した場合。

GET /__utm.gif?utmwv=1&utmn=1910400003&utmsr=1600x1200&utmsc=32-bit&utmul=ja-jp&utmje=0&utmfl=6.0%20%20r29&utmdt=Google%20Analytics%20%u306E%u30BF%u30B0%u3092%20head%20%u306B%u5165%u308C%u308B%u7406%u7531%u306F%3F&utmhn=sonic64.com&utmr=0&utmp=/2005-11-17.html&utmac=UA-54034-1&utmcc=__utma%3D160379711.1091067899.1131959904.1132385137.1132444634.6%3B+__utmb%3D160379711%3B+__utmc%3D160379711%3B+__utmz%3D160379711.1131959904.1.1.utmccn%3D%28direct%29%7Cutmcsr%3D%28direct%29%7Cutmcmd%3D%28none%29%3B HTTP/1.1
Host: www.google-analytics.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Accept: image/png,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://sonic64.com/2005-11-17.html
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.x 200 OK
Content-Type: image/gif
Last-Modified: Sat, 19 Nov 2005 14:09:19 GMT
Server: ucfe
Content-Length: 35
Date: Sun, 20 Nov 2005 00:05:49 GMT

相違点は utmn=1809224424 が utmn=1910400003 になっているところだけ。名前から推察するに、これはタイムスタンプだろう。それ以外はまったく同じだった。

あともう一つ気になったことが、Cookie を使ってないというところ。同じユーザーかどうかを調べるには、Cookie を使うのが手っ取り早い。そうしない理由は何だろう? 他のパラメータ中に GUID みたいなものがあるんだろうか?

- トラッキングコードのインストール位置、どうする?

トラブルを避けたい人は Google Analytics の指示通り設置するのが良い。HTTP トランザクションレベルでは相違点が見つからなかったが、私が何か見落としている可能性もあるし、また今後何か変更が加えられるかもしれないからだ。

トラッキングコードを head 要素に入れるという条件を満たせないためにGoogle Analytics の利用を見合わせている人は、とりあえず試してみる価値はある。解析結果に100% の精度は得られないかもしれないが、参考にはなる。全く利用できないかもしれないが、とりあえず無料なんだし、試すだけなら簡単。アクセス解析で大変なのは、集計よりは結果の分析の方だし。

私はとりあえず傾向がわかればいいというレベルなので、このまま head にはトラッキングコードをインストールせずに、html の末尾に配置しておくことにする。

2005年12月25日追記。
タグ位置が body 要素の末尾に変更になった。2005-12-25 の「Google Analytics のタグ位置が body の末尾に変更」を参照。

私は Google が好きなので、御多分に漏れず Google Analytics を導入している。

Google Analytics
http://www.google.com/analytics/ja-JP/

で、疑問に思っているのは、なんでトラッキング用のコードのインストール位置が head 限定なのかということ。導入の説明やヘルプセンターのサポート文書にもすべて、head 要素内の meta 要素の後 に入れるようにと書いてある。

こういうオプション的なものって、私はページの一番下に配置したい。読み込みとかレンダリングのスピードに影響を与えるだろうし、検索エンジンは先頭 n バイトしかキャッシュしないことが多いから。サイドバーを html 的にメインコンテンツの後に置いているのも同じ理由。はてなの Hatena ID Auto-Discovery も html の最後の方に配置してる。

Google Analytics のヘルプを読んでみる。

ウェブ サイトにトラッキング コードを追加するにはどうすればよいですか。
http://www.google.com/support/analytics/bin/answer.py?answer ...

すべてのウェブ ページの <head> タグと </head> タグの間で、<meta> タグの後に次のコードを挿入します。 インクルードまたはテンプレートを共有している場合は、これらのファイルのいずれかに挿入します。

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
  _uacct="UA-xxxx-x";
  urchinTracker();
</script>

やっぱりとくに理由は書いてない。なんでだろう? urtin.js を2分くらい読んだけど、理由になるようなものは見つけられなかった。あ、もしかしてサイト滞在時間とかを厳密に計測するため? それとも Google がトラッキングコードの存在を認識する精度を上げるため?

トラッキングコードの存在を認識する精度を上げるためだったら、認識した後は位置を変えても問題ないんじゃないのかな? 頻繁に再認識してるならダメだけど。

とりあえず試してみるか。「データの待機中: sonic64.com Analytics を正常にインストールし、データの収集を開始しました。 最初のレポートは 12 時間以内に表示できます。」という表示も出たし、レポートも正常に表示されるようになった。この状態で、トラッキングコードを body のかなり下の方に貼り直してみた。さあ、どうなるかな。

考えても埒があかないし、実験だけだと不足なので Google Analytics サポートにも質問を送信した。

トラッキングコードのインストール位置についての質問です。
質問は二つありあます。

1.
トラッキングコードが JavaScript なのであれば、head 要素以外の場所に
インストールしても動作するのではないでしょうか?

2.
もし head 要素以外の場所にインストールした場合、何か問題はありますか?
たとえば、トラッキングが正常におこなわれない、トラッキングの精度が落ちる、
Google がトラッキングコードを認識しにくくなる、といった不都合はありますか?

以上、よろしくお願いいたします。

回答待ち。

追記。
Google Analytics サポートから返答が来た。詳しくは 2005-11-19 の「Google Analytics サポートからタグ位置について返答」を参照。

2005年12月25日追記。
タグ位置が body 要素の末尾に変更になった。2005-12-25 の「Google Analytics のタグ位置が body の末尾に変更」を参照。

http://d.hatena.ne.jp/sonic64/ に当サイト Landscape の目次を置くようにしてみた。別件ではてなダイアリーについて調査してたんだけど、せっかく作ったアカウントを死蔵するのはもったいないと思ったため。たつをさんがやってる http://nais.to/~yto/clog/2005-05-09-1.html の真似。ちなみにページ名は「Landscape - エンジニアのはてな」にしておいた。

ただ、置いているのはあくまでも目次。検索エンジンでは目次よりも本文がヒットして欲しいし、同じコンテンツがたくさんあるとユーザを迷わせるかもしれないので、目次にはロボット避けを設定したい。

- はてなダイアリーでロボット検索避け

ロボット避けは 2003-06-08 で書いたように、meta 要素か robots.txt で設定するのが一般的。robots.txt はそのドメインの管理者向けなので、はてなダイアリーでは meta 要素くらいしか使えないだろう。HTML としては meta 要素はhead 要素内に書かなければならない。でも、はてなダイアリーでは html のうち書き換えられる部分は body 要素など一部だけで、head 要素には手が出せない。どうすればいいんだろう?

何度か検索を繰り返したら、はてなダイアリーでロボット除けをする方法が見つかった。

http://d.hatena.ne.jp/keyword/%a4%cf%a4%c6%a4%ca%a5%c0%a5%a4 ...

Q：ロボット検索を避けたい。

A：ダイアリーやアンテナの管理ツール画のヘッダー部分に、

<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
を設定します。

その他、サーチエンジン対策のための様々なメタタグ（META要素）については、

Google ページの削除‐個々のページを削除する　http://www.google.co.jp/intl/ja/remove.html#exclude_pages
などを参考にしてください。

※META要素はHTMLの本来の書き方としてはHEAD要素に書き込まねばなりませんが、はてなダイアリーでは個々のユーザがスタイルシート以外のHEAD要素を設定することが出来ないため、あくまでも便宜的にMETA要素をBODY要素内の「ヘッダ」に書き込むことでロボットに認識させるという手段をとっています。

そうなんだ。たいていの検索エンジンは body 中の meta 要素も検出してくれるということか。知らなかったよ。

管理画面で <meta name="robots" content="noindex,follow"> を設定して完了。確認にためにもう一度表示させてみる。

<meta content="noindex,follow" name="robots">

あれ? なんか name と content の順番が逆になってる。ひょっとして、はてなダイアリーではアルファベット順に属性をソートしてるのかな。まあ問題ないだろうけど。

追記。
設定を入れてしばらく経ってから http://d.hatena.ne.jp/sonic64/ を検索してみると、ちゃんと消えてる。よしよし。
http://www.google.co.jp/search?hl=ja&lr=lang_ja&ie=e ...

- 本文にロボット避けを仕込んで、スパムサイトを検索から締め出せないかな

でも、本文中のロボット避けを解釈するってことは、html のサニタイズが甘いとロボットの制御権を奪われかねないな。

たとえば、最近よくある RSS から勝手に本文を抽出し、そのキーワードのまとめサイトみたいのを作ってるスパムサイト。有用な Planet や RSS 検索ではなく、単なる広告目的なやつ。RSS の本文中に meta 要素でロボット避けを入れておけば、そういうサイトを検索エンジンから消滅させることができるかも。・・・と思ったけどダメかな。サニタイズってライブラリでやってるだろうし、そのライブラリは使える要素を個別に指定できるタイプだろうからなあ。そんな甘い作りにするわけないか。

Google のキャッシュは 101KB までという制限があったのだが、いつのまにか制限が101KB ではなくなっている。

たとえば、Landscape の音楽カテゴリのページは 380KB ほどのサイズを持つ大きめのページだ。

音楽 - Landscape
http://sonic64.com/cat_e99fb3e6a5bd.html

Google で 音楽 - Landscape sonic64.com cat_e99fb3e6a5bd.html を検索すると、当該ページは 101KB を超えてるのにもかかわらず、全部をキャッシュで表示することができる。

sonic64.com/cat_e99fb3e6a5bd.html - 389k - キャッシュ - 関連ページ

いつからこうなったんだろう? Google のヘルプなどを探してみたが、制限が変更された時期や、新たなサイズ上限値は見つけられなかった。もしかして、Google のキャッシュを利用して Web ページの表示を速くする Google Web Accelerator のために上限を変更したのだろうか?

いずれにせよ、ユーザーにはうれしい変更だ。Web ページのデータを失って Google キャッシュからサルベージしたりすることがあるそうだが、サイズ上限が増えればそれもやりやすくなる。

Gmail のストレージ容量が 2GB になるとのこと。じゃあ早速2GB 使い切ろう。

- Gmail からの 2GB 増量の発表

About Gmail
http://gmail.google.com/gmail/help/about_whatsnew.html

G is for growth

Storage is an important part of email, but that doesn't mean you should have to worry about it. To celebrate our one-year birthday, we're giving everyone one more gigabyte. But why stop the party there? Our plan is to continue growing your storage beyond 2GBs by giving you more space as we are able. We know that email will only become more important in people's lives, and we want Gmail to keep up with our users and their needs. From Gmail, you can expect more.

要するに、「Gmail 一周年を祝って 1GB 増量するよ、その後もできる限り増量していくよ」ということだ。発表が4月1日なのでエイプリルフールのウソかと思ったが、どうやらそうではないらしい。

- Gmail 容量カウンタに見入る

Gmail トップページでは、容量カウンタが増えている様を見ることができる。いきなりログイン完了になってメール一覧が表示されてしまう場合、右上の Sign out でログアウトすると見られる。

http://gmail.google.com/

* The gift that keeps on giving.
  1357.861573 megabytes of storage (and counting) for every user.

1357.861573 の部分は JavaScript で生成されていて、カウンタが増え続けている。私もしばらく見入ってしまった。2004-05-26 で書いた「ディレクトリ中のファイルサイズ合計値を バイト表示」するシェルスクリプトに雰囲気が似てる。理由はよくわからないけど、私はこういう「増え続けるもの」に弱い。ネットワーク転送量とか、データのサイズとか、ページビュー数とか。なんか見入っちゃうんだよなあ。

- 増えてる増えてる

ログインすると、メール一覧下部にある使用容量と最大容量の部分が更新されていた。以前は最大1000MB だったのが、1357MB になっている。

You are currently using 992 MB (73%) of your 1358 MB.

私はいくつかの Gmail アカウントを使い分けている。他のアカウントを見ると、1359MB だったりした。少しずつ増えているようだ。

- じゃあ早速 2GB を使い切ろうじゃないか

容量が増えたなら、使ってあげなきゃね。2004-11-09 に書いた「GMail をバックアップストレージとして使う」のスクリプトをちょっと修正して、2MB 弱のメールを200通ほど送信するようにしてみた。

しばらくして送信完了。しかし、ログインしてみたがどうもおかしい。メール一覧表示には新着メールが数通しかない。容量表示部分を見ると、以下のようになっていた。

You are currently using 1023 MB (68%) of your 1487 MB.

どうやら、最大容量の表示は更新されているが、実際に使用可能な容量はまだ増えていないらしい。大人は嘘つきだ。というか、もしかしてエイプリルフール? いや、私は Google を信じてるよ。早く実際の使用可能容量が増えないかなー。

- Gmail からのエラーメール

追記。Gmail からエラーメールが返ってきていた。

From: Mail Delivery Subsystem <mailer-daemon@gmail.com>
Subject: Delivery Status Notification (Failure)

This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

    *****************@gmail.com

でも、これだけじゃエラーの理由がよくわからないね。

- 実際の容量も増えた

2005-04-16 追記。実際に使える容量も2GB まで増えた。

You are currently using 2098 MB (100%) of your 2099 MB.

Google、一度に入力できるキーワード数の制限を緩和〜32語まで入力可能に
http://internet.watch.impress.co.jp/cda/news/2005/01/25/6190 ...

Google が入力可能なキーワード数の上限を32語に増やしたという記事。ということは、2004-01-28 で書いた「Google のキャッシュのハイライト色の最大色数」も増えてるのかな? 実験してみよう。

- Google 検索に32語分キーワードを入力してキャッシュを表示させる

32語キーワードを入力してキャッシュを表示させ、html ソースを確認すれば各キーワードがどの色でハイライトされているかを調べることができる。でも32語もキーワードを考えるのが大変だな。とりえあえず思い浮かべられる単語をどんどん入れてみるか。

Google で Landscape 最終 更新 時刻 RSS 斎藤 宏明 sonic64 2003 2004 2005 エンジニア メモ カテゴリ .net 2ch amazon Apache bash bookmarklet C# chalow ChangeLog CSS Delphi DVD F-ZERO ftp Google gpg HTML http iPod を検索。

これだけあれば十分でしょ。Google のキャッシュを表示する URL をコピペしておくと以下のようになる。長い。1600 * 1200 程度の画面では、ブラウザを最大化してもステータスバーからはみ出すくらいの長さだろう。

http://www.google.co.jp/search?q=cache:mbIIC3VDM04J:sonic64. ...

- あれ? 同じ?

なんか IE で見るとカラーバーのようだな。

どれどれ、11語目の 2005 の色は・・・って、おんなじじゃん。

<td bgcolor=#ffff66><B><font face="" color=black size=-1>landscape&nbsp;</font></B></td>
(略)
<td bgcolor=#ffff66><B><font face="" color=black size=-1>2005&nbsp;</font></B></td>

なんだ、結局10色をローテーションしてるだけなんだね。めくるめく多色環境を体験できるかと思ったのに。ちょっと残念。

Gmail の Trash ディレクトリに移動したメールは30日経つと自動削除されるはずだが、どうやら動いていないようだ。

- Gmail は手頃なネットワーク上のストレージ

2004-11-09 の「GMail をバックアップストレージとして使う」で書いたが、私はバックアップファイルを暗号化し添付ファイルとして Gmail に送信するスクリプトを定期的に動かしている。このバックアップメールは Gmail に届くと自動的に Trash ディレクトリに移動されるようにフィルタを設定してある。Trash に入ったメールは30日経過すると自動的に削除されるので手間がかからない。

- 1GB の Gmail メールボックスが溢れた

Gmail にログインしてみると、以下のようなメッセージが表示されていた。どうやらメールボックスがいっぱいになってしまったらしい。容量表示メッセージはいつもは緑色なのだが、以下は赤い色だった。

You are currently using 1003 MB (100%) of your 1000 MB.

なんでこんなことになってるのか。もしかして古いバックアップが削除されていないのでは? とおもって Trash を見ると、バックアップメールがたくさん残っていた。一番古い物は2004年10月26日のものだ。

- せっせ、せっせと削除

なんで30日経ったメールが残ってるんだろう? 仕方がないので手作業で削除。Select: All を選択して、Delete Forever ボタンを押す。Newer を押してページを切り替え、同じことを繰り返す。10回ほど繰り返したら700MB ほど空き容量ができた。

仕様変更ってわけでもないよね。以下のようにちゃんと書いてあるし。なんでだろう?

Note:  Trashed messages more than 30 days old will be automatically deleted.

Google さん、お願いだから Trash に入れて30日経ったメールは削除してください。手作業で削除するのは手間だし、忘れちゃう。

- Gmail が表示した気になるメッセージ

削除を実行してそのページ中に一つもメールが無くなったとき、以下のメッセージが表示された。ちょっと気になるな。

No conversations in the trash. Who needs to delete when you have 1000 MB of storage?!

「1000MB もストレージがあるなら、削除する必要なんてある?」というメッセージ。いや、私は削除が必要だったんだけど・・・。1テラバイトくらいディスクスペースをくれるなら削除する必要はないと思うけどね。

GMail の 1GB という容量を生かして、バックアップストレージとして使う方法。

ストレージというと大げさな感じがするが、やってることは暗号化したアーカイブファイルを GMail にメール送信するスクリプトを書き、これを cron で一時間ごとに実行するだけ。GmailFS などを使ってファイルシステムとしてマウントするのも一つの方法だとは思うが、バックアップなんだから安定性重視でいきたいし、こういうのはシンプルな方がいい。

今日の戯言 ChangeLog 主にテキストファイルを gmail にバックアップ
http://apollo.u-gakugei.ac.jp/~sunaoka/clog/2004-11.php#2004 ...

主にテキストファイルを gmail にバックアップするつもりででっち上げてみたが，車輪の再開発のような気がしてならない．

1GB の容量を与えられたらそれを活用しようとする人はたくさんいるし、実装もたくさんあるようなので確かに車輪の再発明かもしれないですね。でも、自分好みの機能やインターフェイスにしたいなら、スクリプトを書いちゃう方が良いと思います。File::MMagic と Compress::Zlib を使って、テキストだったら圧縮するという機能は面白いと思いましたし。

- GMail をバックアップストレージとして使う - 私の場合

私の場合、シェルスクリプトで tar と gpg を呼び出して圧縮と暗号化をおこない、2004-10-09 と 2004-11-01 で書いた「添付ファイル付メールを送信する Ruby スクリプト」である samail で SMTP サーバに投げている。

送信先は GMail をはじめとするメールボックス容量に余裕のあるアドレス。メールなので数十メガバイトのファイルのバックアップという用途には適さない。ChangeLog メモのファイルや自分用 CVS リポジトリ、etc ディレクトリなど、小さなものだけをバックアップしている。Gmail のアカウントを取得する前は一日一回だったが、Gmail ができてからは一時間に一回に実行頻度を上げた。

内容にもよるが、外部にデータを持ち出すなら暗号化は必須だと感じている。GnuPG を使えばフリーで強力な暗号を利用可能。具体的には 2004-01-08 で書いた「gpg で標準入力からパスワードを渡してバッチ処理で暗号化」を利用し、GPG の共通鍵暗号で暗号化している。

暗号化アルゴリズムには AES256 (256bit Advanced Encryption Standard) を指定。gpg のデフォルトの CAST5 でも良いと思うけど、AES は NIST (National Institute of Standards and Technology 米国商務省技術標準局) 御用達の暗号化アルゴリズムとのことなので、これを使うことにした。

Perl だったら Crypt::CAST5 や Crypt::Rijndael とか使うのが一般的なのかな?

#!/bin/sh

# gmail_backup.sh
# Archiving, Crypting, and mail sending script
# Copyright (C) 2004 Saito Hiroaki <sonic64@infoseek.jp>
# http://sonic64.com/

# setup
PASS_PHRASE="MY SECRET PASS PHRASE STRING"
TAR_TARGET="/home/hiroaki/log.txt /home/hiroaki/etc /cygdrive/s/cvsroot"
OUTPUT_PATH="/home/hiroaki/tmp/backup.tar.bz2.encoded"
to_address="to@example.com, to@gmail.example.com"
optional_adderss="to@daily.example.com"
from_address="from@example.com"
smtp_server="smtp.example.com"


date
echo $TAR_TARGET
echo $PASS_PHRASE | { tar --bzip2 -cf - $TAR_TARGET |gpg --batch -c --cipher-algo AES256 --force-mdc --passphrase-fd 3;} 3>&0 >$OUTPUT_PATH

echo output to $OUTPUT_PATH
echo archiving complete

if [ `date +%H` -eq 23 ]; then
  to_address="$to_address $optional_adderss"
fi

/usr/local/bin/ruby /home/hiroaki/script/samail -v --to "$to_address" --from $from_address --smtp $smtp_server --subject "[GMail Backup] `date +%c`" --attachment $OUTPUT_PATH

date
echo mail send complete

以前は暗号化した圧縮ファイルの md5 ハッシュを取っておいて、前回と異なったときのみメール送信という動きにしていたが、その機能は外してしまった。そういう意味では一度ファイル出力せずに直接 samail の標準入力に渡した方がシンプルだな。よし、samail の次のバージョンでは標準入力から読み込んだデータを添付ファイルとして送信できるようにしよう。

- gmail_backup.sh の設定方法

# setup のところに設定を書く。
PASS_PHRASE に gpg に渡すパスフレーズ、TAR_TARGET にバックアップしたいファイルやディレクトリのパス、OUTPUT_PATH に暗号化した圧縮ファイルの出力先を記述。あとは To と From と SMTP サーバ名を書いて完了。Ruby のパスを /usr/local/bin/ruby と samail のパスを /home/hiroaki/script/samail とハードコーディングしてるのはあまり良くないかも。

私の場合 cygwin ネイティブのファイルシステムと /cygdrive の両方にバックアップしたいファイルがあるため、/ からフルパスで TAR_TARGET を記述している。このせいで tar に以下のようなメッセージを表示されるけど、実害がないので問題ないだろう。

tar: Removing leading `/' from member names

- GMail 側の設定

Gmail といえども 1GB しか容量がないので、古いバックアップファイルは削除する必要がある。Gmail の Trash ディレクトリは 30日過ぎると削除されるという性質があるので、これを利用する。この性質は Trash を開いたときに出るメッセージに書かれていた。

Note: Trashed messages more than 30 days old will be automatically deleted.

メール送信時に Subject に特徴的な文字列を入れておき、その文字列でフィルタリング。マッチしたメールは自動的に Trash 行きになるように設定する。こうすることで「30日を過ぎたバックアップファイルは自動的に削除」を実現できる。

- メール送信の頻度はどれくらいがよいか

これはもうお好みで良いと思う。一日一回くらいでも充分なんじゃないかと思うが、せっかく容量があるんならいっぱい送っちゃえ、ということで一時間に一回にしている。

一回 1MB のファイルを送るとして、1MB * 24時間 * 30日 = 720MB 、Base64 すると 3分の4倍くらいになるので、それを含めても 1MB * 24時間 * 30日 * 4 / 3 = 960MB。24時間稼働のマシンでなければ頻度はもっと減るし、一日一回にしておけばさらに余裕。ところで、GMail って添付ファイルは Base64 デコードした状態でファイルサイズを計算している気がするんだけど気のせいかな。

- 一日一回だけ別のアドレスを追加して送信

このスクリプトは cron で一時間ごとに起動しているが、23時台に起動したときだけ optional_adderss にセットされた送信先を追加している。Gmail ほどメールボックス容量に余裕がないアドレスなので、一日一回だけの送信にしたいからだ。Gmail の予備として使っている。

if [ `date +%H` -eq 23 ]; then
  to_address="$to_address $optional_adderss"
fi

- 分割すれば巨大ファイルでも OK?

分割すれば数十メガバイト単位の巨大ファイルでもバックアップできるが、いざリストアしようと思ったときに分割したメールを連結するという手間をかけたくない。標準で POP で受信できない場合はなおさら。そういう巨大ファイルは他の方法を使うべきでだ。どうしてもネットワーク経由でのバックアップがしたいなら、2004-03-19 で書いた「Linux: gpg: ftp: ftp + tar + gpgで暗号化ネットワーク・バックアップ」などが使えるかもしれない。

- 正常に復号して圧縮ファイルを展開できるかどうかのテストを忘れずに

バックアップしただけで安心してはいけない。いざという時にに迅速にリストアできなければ意味がない。私は以下のようにして復号と圧縮ファイルの展開をしている。

$ echo "MY SECRET PASS PHRASE STRING" |gpg --passphrase-fd 0 -o - backup.tar.bz2.encoded |tar -x --bzip2
Reading passphrase from file descriptor 0
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase

bzip2: (stdin): trailing garbage after EOF ignored

--force-mdc オプションなしで暗号化したファイルの場合、以下のメッセージが表示されるかも知れない。これについては私も詳しくないので言及しない。とりあえず --force-mdc を付ければ警告は出なくなる。

gpg: WARNING: message was not integrity protected

bzip2 の警告は、末尾になにか余計なデータがあるので無視するよ、というもの。理由は不明。tar の出力を直接 gpg の標準入力に渡しているから?

- 「フッフッフッフッフッフッ まぬけめ! Gmail」「や…やろう まさか!」「きさまのおかげで ストレージ利用がしやすくなったぞッ!」

追記。Gmail が POP3 をサポートするとのこと。

ITmediaニュース：GmailがPOP3サポート、ウイルス対策も提供へ
http://www.itmedia.co.jp/news/articles/0411/11/news010.html

これでさらにストレージとして利用するのが簡単になった。そのうち 読み書き用の API を書く人も出てくるだろうな。POP/SMTP ベースだと遅延があるのでリアルタイム性を要求するアプリケーションには使えないだろうけど、用途を選べば充分使える。

Sleipnir をはじめとするタブブラウザなどの検索バーを使って Google 検索すると、検索結果表示画面が文字化けしてしまう現象が発生しているようだ。

以下、Sleipnir についての対策方法。対策方法はいくつかあるが、以前と同じ環境で使いたいなら、「shift_jis だと明示する」が良いだろう。「utf-8 でクエリを送信する」だと、検索結果画面の英数字フォントが微妙に異なることがある。

- shift_jis だと明示する

ツール(T) の 「Sleipnir オプション(B)」を開く。
「検索バー」の「検索エンジン」を開く。

「先頭(F)」を

http://www.google.co.jp/search?num=50&lr=lang_ja&ie=shift_jis&oe=shift_jis&q=

にする。「エンコード (E)」は「URL エンコード」を選択する。

「エンジニアのメモ」を検索した場合の URL
http://www.google.co.jp/search?num=50&lr=lang_ja&ie= ...

- utf-8 でクエリを送信する

ツール(T) の 「Sleipnir オプション(B)」を開く。
「検索バー」の「検索エンジン」を開く。

「先頭(F)」を

http://www.google.co.jp/search?num=50&lr=lang_ja&q=

にする。「エンコード (E)」は「UTF-8」を選択する。

「エンジニアのメモ」を検索した場合の URL
http://www.google.co.jp/search?num=50&lr=lang_ja&q=% ...

- euc-jp でクエリを送信する

ツール(T) の 「Sleipnir オプション(B)」を開く。
「検索バー」の「検索エンジン」を開く。

「先頭(F)」を

http://www.google.co.jp/search?num=50&lr=lang_ja&ie=euc-jp&oe=euc-jp&q=

にする。「エンコード (E)」は「EUC」を選択する。

「エンジニアのメモ」を検索した場合の URL
http://www.google.co.jp/search?num=50&lr=lang_ja&ie= ...

- 原因

Google のデフォルトのエンコーディングが shift_jis から utf-8 に変更になったのが原因のようだ。
もっとも、私はいつも euc-jp でクエリを送っていたので影響はなかった。

窓の杜 - 【NEWS】“Google”検索の仕様変更で検索結果が文字化けしてしまうソフトが続出
http://www.forest.impress.co.jp/article/2004/04/22/google_cs ...

ITmediaニュース：SleipnirでGoogle検索結果が文字化けする現象
http://www.itmedia.co.jp/news/articles/0404/22/news032.html

2004-01-29 の Google の検索結果一覧画面からキャッシュのリンクだけを開く Bookmarklet について、2ちゃんねるの「1行javascriptプログラミング」スレでアドバイスを求めたところ、いくつかレスを頂いた。

1行javascriptプログラミング
http://pc2.2ch.net/test/read.cgi/hp/1066750037/166-

166 ： [sage] ：04/01/30 02:12 ID:???
Bookmarklet を作ってみました。
もっとスマートな書き方があったら教えてください。

Bookmarklet: Google の検索結果一覧画面から キャッシュのリンクだけを開く Bookmarklet
http://sonic64.hp.infoseek.co.jp/2004-01-29.html#2004-01-29-1

javascript:(function() {max=10; z=document.links; t='/search?q=cache:'; for(i = 0; i < z.length && 0 < max; ++i) { if (z[i].innerHTML && z[i].href.indexOf(t) != -1) { void(window.open(z[i].href)); max--;} }}) ();


167 ：Name_Not_Found [sage] ：04/01/30 02:37 ID:???
キャッシュのページか一気に開くからブラクラかと思った（W


168 ：Name_Not_Found ：04/01/30 16:00 ID:tnCbXvna
>>166-167
初期値だと開くウインドウの数は10で、
ブックマークレットを実行した瞬間に10個のウインドウが一気に立ち上がっていくから、
ブラクラと同じような動きに見えるかもね。

タブブラウザを使っていて、マシンのリソースに余裕がある人は
もっとウインドウの数を多くした方が快適に使えると思う。
自分は20にしてるけど、いい感じだよ。

「ブラクラかと思った」というお褒めの言葉(?)を頂く。
開くウインドウの数を20にしてみた方もいるようだ。私のマシンは Celeron 500MHz なので、これ以上増やすとちょっとつらいかなあ。開いた直後にしばらく Sleipnir が反応しなくなっちゃう。

169 ：Name_Not_Found [sage] ：04/01/31 09:26 ID:???
>>166
なんの為の function() なんだか。
というツッコミついでにこういう書き方を。

javascript:(function(){var max=10,z=document.links,i=0;while(i++<z.length,0<max)z[i].innerHTML,z[i].href.indexOf('/search?q=cache:')!=-1,max--,void(window.open(z[i].href));})();

書き方変えたついでにＮＮ４にも対応させてみる。
javascript:(function(){for(var max=10,z=document.links,i=0;i<z.length&&0<max;++i)if((document.layers?z[i].text:z[i].innerHTML)&&z[i].href.indexOf('/search?q=cache:')!=-1)window.open(z[i].href),max--;})(undefined);

スマートかどうかは別として、参考までにな。


170 ：169 [sage] ：04/01/31 10:49 ID:???
スマソ
一つ目のやつは流石に ( , ) 演算子だけじゃだめアルよ。

あ、var 宣言忘れてた。2004-01-29 のスクリプトを修正、と。>>169 氏の自己レスにもあるように >>169 の上のスクリプトは動かないので注意。>>169 の下のスクリプト、Netscape でも動くのは素晴らしい。もっとも、この Bookmarklet はタブブラウザで真価を発揮するので、タブに対応していない Netscape 4.x ではあまり需要がないだろう。「すごい たぶちさん http://www.vector.co.jp/magazine/softnews/040114/n0401142.ht ... 」のような何でもタブ化してしまうツールを使えば対応はできるが、そこまでして Netscpe 4.x を使い続ける人ってすごく少なそう。

Google で検索をしてキャッシュを表示させると、検索したキーワードがハイライトされる。私はこの機能を知ってからは、キャッシュ収録後に更新されていそうなページやキャッシュで見られないページを除き、Google 検索した結果はまずキャッシュで見るようになった。キャッシュで見た方が見やすいからだ。PageRANK とキャッシュとハイライトが Google の目玉機能だと思っているほどだ。

スペースで区切って複数のキーワードを検索したときでも、異なる色でハイライトされるのでとても見やすい。ここでふと疑問に思ったのだが、このハイライトって何色まであるんだろう? 色数が多くなったとき、どんな色が出てくるんだろう? とりあえず 15個のキーワードで検索してみる。Google で 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 を検索。すると、以下のような警告が出ていた。そういえば、エラーメッセージをそのまま検索したときなどに見た覚えがあるな。

検索が10語までに制限されているので"11"とその後の語句は検索には使用されていません。

じゃあ、すべての色を見るには10語での検索で十分なんだね。

- やってみよう

時間が経ってからこの記事を読んだ人が、実際に Google のキャッシュを見て色を確かめられるようにしておきたいので、自分のサイトのキャッシュを見られるようなキーワードにしてみた。

Google で Landscape 最終 更新 時刻 RSS 斎藤 宏明 sonic64 2003 2004を検索

Landscape トップページのキャッシュ表示
http://www.google.co.jp/search?q=cache:mbIIC3VDM04J:sonic64. ...



上記のクエリでキャッシュを表示させて html ソースを見ると、以下のようになっていた。

これらのキーワードがハイライトされています：&nbsp;</font></td>
<td bgcolor=#ffff66><B><font face="" color=black size=-1>landscape&nbsp;</font></B></td>
<td bgcolor=#A0FFFF><B><font face="" color=black size=-1>最終&nbsp;</font></B></td>
<td bgcolor=#99ff99><B><font face="" color=black size=-1>更新&nbsp;</font></B></td>
<td bgcolor=#ff9999><B><font face="" color=black size=-1>時刻&nbsp;</font></B></td>
<td bgcolor=#ff66ff><B><font face="" color=black size=-1>rss&nbsp;</font></B></td>
<td bgcolor=#880000><B><font face="" color=white size=-1>斎藤&nbsp;</font></B></td>
<td bgcolor=#00aa00><B><font face="" color=white size=-1>宏明&nbsp;</font></B></td>
<td bgcolor=#886800><B><font face="" color=white size=-1>sonic64&nbsp;</font></B></td>
<td bgcolor=#004699><B><font face="" color=white size=-1>2003&nbsp;</font></B></td>
<td bgcolor=#990099><B><font face="" color=white size=-1>2004&nbsp;</font></B>

ちなみに、上記の「これらのキーワードがハイライトされています」は table のセルの背景色でハイライト色を指定しているが、実際のページ中のキーワードは物理マークアップタグの <b> の style 属性で色を指定している。本文中にいきなりテーブルを割り込ませる訳にはいかないからね。

<B style="color:black;background-color:#ffff66">Landscape</B>

あと、いままでは気にしてなかったけど、1色目から5色目までの文字色は黒、6色目から10色目は文字色が白なんだね。

- Google ハイライト使用色一覧

表の項目を説明しておく。左から以下の四項目を並べてある。
・24ビット RGB の値
・html や スタイルシートにおいて、16進数ではなく名前で指定できるときの色名
・斎藤の私見による色の名前。齋藤にはこの色に見えた。
・216色 web セーフカラーに含まれているか否か

RGB 値    色名    私見    web セーフカラー
#ffff66    色名無    黄色    セーフ
#a0ffff    色名無    水色    非セーフ
#99ff99    色名無    緑色    セーフ
#ff9999    色名無    橙色    セーフ
#ff66ff    色名無    桃色    セーフ
#880000    色名無    藤色    非セーフ
#00aa00    色名無    緑色    非セーフ
#886800    色名無    土色    非セーフ
#004699    色名無    紺色    非セーフ
#990099    色名無    紫色    非セーフ

斎藤の私見による色の名前は、あくまでも私の環境ではこの色に見えたというだけ。ビデオカードの種類やディスプレイの種類、明るさやコントラストによって変わってくるので、絶対的なものではない。

- 結構適当に指定しているのかなあ?

Google ほどの巨大なサイトになると、いろんな環境からアクセスされる。環境によって見えにくい色などがあっては困る。そのため、Google のカラーコーディネータは、極力 web セーフカラーなどに則って色を指定しているんじゃないだろうかと予想したのだが、そうでもなさそうだ。10色中 Web セーフカラーはわずか4色。また、色名で指定できるようなメジャーな色は使っていない。見やすければいい、というポリシーなんだろうな。

DNS の生死を確認するために、IP アドレスで接続したいときがある。
以前は大学のアプリケーションサーバのアドレスを使っていたが、もっとわかりやすいアドレスがいいだろうということで、Google サーバ群の IP アドレスを調べてることにする。

Google で Google サーバ IP アドレスを検索するとヒット。
Googleサーバー ホスト名IPアドレス
http://bingoall.net/google/googleserver.html

- 3つほど抜粋しておく

http://216.239.33.100/
http://216.239.41.100/
http://216.239.55.100/

Google で perl url エンコードを検索、と書いたら、それが自動的に Google へのリンクになってくれるとうれしい。ということで、以下の正規表現による置換を cl.conf に追加した。

s!(google\s*で\s*(.*?)\s*(を|で)検索)!"<a href=\"http://www.google.com/search?num=50&amp;lr=lang_ja&amp;ie=euc-jp&amp;q=" . url_encode($2) . "\" title=\"Google 検索: $2\">$1</a>"!eig;

chalow はキーワードの置換に perl の eval() を使っている。eval() の中身は文字列として表記しなければならないため、" や ' のエスケープが面倒。そのせいもあってあんまりきれいな正規表現じゃないけど、普段使いにはこれで十分でしょ。ちなみに、上記正規表現で使ってる url_encode() はさきに紹介したもの。

いろんなところで話題になってる、Google を電卓にする機能。
Googleの特殊機能 電卓機能
http://www.google.com/help/features.html#calculator

「よーしパパ半径10cm の円の面積求めちゃうぞー」という場合。
http://www.google.com/search?lr=lang_ja&ie=euc-jp&q= ...