Trivia

URLのパラメータに「id」を使用すると google にインデックスされない

へぇ〜。じゃぁこれは？？

Google Search "inurl:id blog"

“?id=” でページ内検索してみよう！

正直、僕も知らなかったし、ヘェ〜と思った。でも Webmaster Help Center - Webmaster Guidelines を読んで、マジで？と思ったね。ID でページ内検索していくつか抜粋。Technical guidelines と中見出しのついているリストの以下３つ。

• Use a text browser such as Lynx to examine your site, because most search engine spiders see your site much as Lynx would. If fancy features such as JavaScript, cookies, session IDs, frames, DHTML, or Flash keep you from seeing all of your site in a text browser, then search engine spiders may have trouble crawling your site.
• Allow search bots to crawl your sites without session IDs or arguments that track their path through the site. These techniques are useful for tracking individual user behavior, but the access pattern of bots is entirely different. Using these techniques may result in incomplete indexing of your site, as bots may not be able to eliminate URLs that look different but actually point to the same page.
• Don't use "&id=" as a parameter in your URLs, as we don't include these pages in our index.

前の二つは session ID と入ってるけど、page ID の話なんてしてねぇよ、って？もちろん session ID と page ID が違うのくらい知ってるけれど、まぁここで Search Engine 的に問題としているのは、dynamic に生成されるページなので、やや強引ですが一絡に話をします。まずは訳してみましょう。

• Lynx のようなテキストブラウザを使って自身のサイトを確かめてください。多くのサーチエンジンは Lynx で見えるような世界を見ています。Javascript, Cookie, Session ID, Frame, DHTML あるいは Flash のような派手な機能を使っているのなら、テキストブラウザでも見られるようにしてください。そうすればサーチエンジンも難なくあなたのサイトを収集できるでしょう。
• ユーザのページ閲覧順序を確認するための Session ID や引数を使わなくても、サーチエンジンがページを収集できるようにしてください。それらの技術は個別ユーザの閲覧行動を確認するためには非常に有用ですが、サーチエンジンのアクセスパターンは全く違います。Session ID や引数を使うことで、サーチエンジンが URL を見て、実際には同じなのに違うように見えるページを確認しきれずに、あなたのサイトの索引生成作業が完了しないままになる可能性もあります。
• “&id=” を URL に含めないでください。我々はそういったページを索引生成作業に含めません。

っていうか、Google ってそんなに馬鹿なんですか（反語）？？ずいぶんと上からのもの言いだし。。

Google こそ究極の Bottom up の集団だと思っている僕としては、あのページはアジテーション以上ではないなと思う。件のページに書いてあるのはあくまで、サイト作成・管理の指針となるようなものであって、本当にそうしている、という仕様書ではないはず（僕だって Google の中の人ではないので、ホントはどうだか知らないけれど）。だって、整理の下手なダメ人間ばかりのこの世界で、そんな少数の整理|仕様|規格好きだけを相手にして、トップの座を守り続けられるわけない。

だから My RSS 管理人 aka さんのコンセプトというか結論というか主張には 100% 賛成するし、del.icio.us の Joshua が主張するような理由からも、&id= なんて ugly な URL は使うべきじゃない（ちょっと前に似たような記事書いたとこだし）と思う。けれども Subject にあるような 『URLのパラメータに「id」を使用すると google にインデックスされない』というのは、看板に偽りありと云うほかない。

以下は、5 Things You Probably Didn't Know About PHP By Gregory Szorcのいい加減訳です。

---

?> はオプション

<?php
...
?>

たいだい上のように PHP のコードを書くと思うけれど、最後の ?> は実は書かなくてもいい。少なくとも PHP 5.1 では動く。問題点はあるけど、XML なんかの出力には、?> 以降に（意図的でない）空白行が入ると問題を引き起こす（こともある）ので、終了タグを書かない。

他言語を PHP 中に埋め込むことができる

Java, Perl, Python と .NET なんかは PHP から実行できる。Java Inteface はとってもクール。

配列へアクセスする方法で、オブジェクトも扱える

Standard PHP Library (SPL) を使えば、オブジェクトをあたかも配列のように扱える。 例えば ArrayObject を使うと以下のようなことが出来る。

$object = new MyObject();
$object['name'] = 'Hello World';

あるいは

$object = new MyObject();
foreach ($object as $k=>$v) {
	echo "$k = $v\n";
}

など。

require() は require_once() より速い

（これは PHP 5.2 までの話だけれど、）require_once でなく require を使った方が、アプリケーションが大きくなればなるほど、相当速くなる。require_once は呼ばれるたびに余分な system call が走って重複がないことを確認するから。「じゃぁどうやって重複がないことを保証するわけ？」「まだ require_once なんか使ってんのがダセーの。__autoload をうまく使え。」もし SPL が入ってるなら、spl_autoload_* を使えば複数の autoload ができる。より詳しい内容は Zend Framework ML のこのスレを読もう。

PHP 5.1.0 未満を使ってる奴はアフォ

PHP 5.0.x ブランチはもうメンテされてない。PHP 4.x ブランチは死んでる。いかに理由を挙げるから、まだ移行してない奴はするように

• たいていの PHP4 で書かれたコードは動く。動かないとか言ってたのは FUD。開発者は互換性確保のためによくやってるから、まだ PHP4 を動かしてる奴は PHP 4 から PHP 5 への移行: 下位互換性のない変更点 を見ながらコードを grep するように。
• PDO 使え！ SQL を別ハンドラにかく必要なくなるし、SQL Injection 対策もばっちりになる。
• Standard PHP Library (SPL) は今まで PHP で考えられかったすごいこと。
• いくつかの人気アプリが PHP5 への以降をすませた。例えば MediaWiki 1.7
• PHP5 のオブジェクトモデルは他のオブジェクト指向言語によく似てる。例えば Java とか。PHP5 はアクセス修飾子もあるし、抽象クラス、インターフェイス、それにマジックメソッドもある。

---

以下感想。

僕は PHP の parse の処理を考えると、閉じタグがいらない理由はなんとなくわかるけど、場合によりけりだと思うなぁ。Class 定義の書いてあるファイルとか、人に見せるコードはちゃんと閉じたい。直接関係ないけれど、始まりは <?php でするのは大賛成です（できれば short-open-tag を php.ini で off にして）。

他言語埋め込みは、僕にはとりあえず必要性がないのでよくわかりません。

SPL の ArrayObject は、Greg 曰く database query result とか LDAP directory queries によく使って便利だとか。ちょうど昨日も書いたけど、SPL は面白そうなので今度触ってみよう。

PDO 使えってのも、いいんだけど、『PDO 使えば SQL Injection 対策になる』ってのは危ないね。ちゃんと使えば、SQL Injection を起こすコードを書きにくくなるってだけだし。

なんだか最近 GMail の演算子を語るのがはやってるらしい（オレンジニュース とか はてブとか）。以下は最良のまとめ。というか Google 本家の日本語訳酷い。

Gmailの検索やフィルタで使用できるコマンド（演算子）一覧表

そこでも載ってないのが ! （否定演算子）。手前味噌ですが１年前のエントリで解説ちう。

Why we like GMail.

去年の今頃の GMail の変化を A to Z に追っかけてた感覚からいうと、こういう細かい仕様は結構ちょこちょこ変わるのだが。というわけで ! が使えるのをもう一度調べてみました。効果が確認できたのは…

• has:attachment
• is:unread
• is:starred
• in:inbox
• is:sent
• in:drafts
• in:spam
• in:trash

あまり用途が思いつかないけど、label: も使えるっぽい。というか、僕はラベラーではないので確認できない。。

GMail Search Operator.

GMail がなぜこれほど、hacker 達に愛されるのか？それはこう言う所だと思います。上記リンクは GMail の Search box で 演算子 として使える特殊記号。つまりちょっと特殊な検索をする時に使える便利な命令群。from: とか cc: とか。詳しくはご自分でお読みください。

で、ここには書いて無いんだけど、実は使えるって言うのが ! (exclamation mark) を使った、直後命令の否定。ギークっぽいですね。つまり、

!is:satrred

とすると Star がついてない全てのメールを検索って出来るのです。普通の画面でも Unstarred っていうのが、画面上部にあるんだけど、あれだと一画面ずつしか出来ないしね。これだと連続的に、全メールボックスに対して出来るのです。

とはいえ全ての演算子にたいしてこの !、プログラム風に言えば NOT 演算子は使えるわけではありません。使えるのは、期待される戻り値が Boolean の演算に対してのみ、つまり確認した所で言えば、has:attachment, is:starred。is:read は is:unread があるから意味無し。他は知りませんので、お試し/確認あれ。

醍醐味

チーズの話: 11.”醍醐味”の語源はチーズにあり

関連して

Be on Saturday: 君の名は: スジャータ