Web屋のネタ帳

Yahoo! Developer Networkに設けられた、PHP Developer Centerに面白い内容があった。→Using Serialized PHP with Yahoo! Web Services

要するに、

1. 普通、Webサービスといえばやり取りするデータのフォーマットとしてXMLを使うけど
2. Yahoo（米国本家）のWebサービスではRESTでのリクエストで「&output=php」を指定してくれれば結果をXMLじゃなくてPHPの変数をシリアライズした状態で返してあげるようにしてみました、と。
3. それを直接PHPのunserialize関数に読み込ませれば、データをいきなり変数化できるんで便利だよ

という話。ためしに以下のURLにアクセスしてみましょう。PHP言語での多次元配列がシリアライズされた状態が結果として返される。

http://api.search.yahoo.com/ImageSearchService /V1/imageSearch?appid=YahooDemo&query=Madonna &results=1&output=php

PHPのserialize/unserialize関数は、変数の内容をテキスト化する（又はその逆）のための機能。情報を一時的にファイル等にキャッシュしたい場合などに使われるのだが、なるほど、こういう使い方もいいかもしれない。

PHPにはXMLを取り扱うための関数はいろいろとある。しかし、

• いろいろありすぎてどれをつかったらいいのかわからない（笑）。 （PHP マニュアルの目次のページ内を「XML」で検索すると、少なくとも3つか4つはヒットしてしまうはず。）
• それぞれに使い方にクセがある上に、それぞれ「PHP5以上」「まだ開発中(CVSにしかない）」「要拡張モジュール（or再コンパイル）」だったりして、いったいどーすりゃ・・・

という状態になりがち。 なお、PHP純正の関数ではなくPEARライブラリのほうにXML Serializerなんてのもあって、これが一番わかりやすいかもしれない。

しかし、どんなフォーマットでデータを送る/受け取るんあれ、最終的には受け取る側のプログラム内部で多次元配列変数かなにかにしてしまうわけだから、だったらXMLなんか使わなくともはじめからunserialize関数一発で変数化できるような形で送っちゃえばいいじゃん、というアプローチ。うーん、コロンブスの卵。

なお、 この記事の下のほうに、Javaやperlなど他の言語上でデータをPHP言語のserialize形式データに変換する方法（リンク）がいくつか紹介されている。Webサービスを提供する側がPHP以外の言語で構築されている場合でもやろうと思えば可能ということだ。

ちなみに、「これからはPHP言語を積極的に使います」とYahooが公言してから早3年たったわけか。

see also:
Yahoo!、オープンソースの PHP スクリプト言語に移行(Japan.internet.com 2002.10)
One Year of PHP at Yahoo!(PHP言語をYahooで採用して1年を経て) July 9, 2003 (OSCON 2002) PDFファイル
PHP at Yahoo! October 20, 2005 (Zend/PHP Conference) PPTファイル
ITmedia エンタープライズ：Yahoo!、PHP開発者センターを開設 (2006/2)

同じことを願っている人は少なくないんじゃないだろうか。 おまえがやれ？ C言語なんてポインタでつまづいてそれっきりなんだよママン。

短時間に大量のHTTPアクセスを浴びせてきて、Webサーバーが劇重パンク状態になって他のユーザーもまともにアクセスしにくくなり、Webサイト運営者を怒らせる＆悩ませるケースが後を絶たない。

• 手当たり次第にクロールしてWebページ上のメールアドレスをかき集めるロボット（もちろん迷惑メール業者の手による）
• RSS/RDF上に並ぶURLを全てクロールしようとして（何のため？）一気にGETを浴びせてくるロボット。RSSの普及に伴って急増。自宅で勉強中の人が作ったアプリ？から、一般企業の製品／サービスのプロトタイプと思われるもの、独立行政法人○○研究所の研究用アプリまで様々。
• Webサイトの更新チェックソフトや、狙ったWebサイトのページを全てダウンロードしてローカルで読むためと思われるソフト。
• とにかく稚拙な技術で作られた検索エンジンのクローラー （特に中国製はもう次から次へと．．．）
• ページ上のリンクを「先読み」することでネットサーフィンのスピードを上げようとするソフト。主にブラウザのプラグインの形である場合が多い。

などがその犯人だ。故意か、そうでないかにかかわらず、Webサーバーの管理者やそのサイトの他のユーザーに対する配慮が無い技術者がつくるとこうなる。 株式会社はてなの中の人のブログにもこんな話が載っているのでご参考まで。

もちろん、それに対する対抗策も昔から考えられていて、Apacheではmod_limitipconn, mod_bwshare, mod_throttleなどのモジュールで制限をかける手法が一般的だ。（他にもあるけど、適宜ググってください）

このなかでは筆者はmod_throttleが気に入っている。しかし残念ながらApache1.3用のものしかなく、Apache2.xには使えない。作者も、多忙につきApache2対応に手がつかないよ（やる気無いよ）、と公言している。 他のことやってるんでApache2対応に裂く時間は無いよと言ったきり数年が経過している。

しゃーない。勉強がてら触ってみるか。えーと

/usr/local/apache2/bin/apxs2 -g -n mod_throttle2

ほう、これで勝手にディレクトリ掘られて、MakefileやCのテンプレートができちゃうのね。便利。さて、C言語の勉強本ってどこにしまっちゃったんだっけ・・・。

以上で挫折しました。

ごめんなさい。言ってみたかっただけです。

この記事のタイトルだけ見るとものすごい暴論を言っているように聞こえてしまいかねないのだが、とにかく次の二つの記事を紹介しよう。

よく「Strutsは簡単だ」という人がいるけど、本当にそうかね？おいらは初心者を何人か見たけど、みんなJavaにもStrutsにも苦しんでいた。たかがデータ登録の画面を作るだけなのに、クラスを何個も作ってXMLファイルをかきかきして、それで動けばいいんだけど動かなくて、クラスやファイルが分散しているからどれが原因か突き止められなくて途方に暮れる。一度、Strutsを使わずに素のServletとJSPで作ってみせたことがあるんだけど、これはRailsのようにCRUDの操作を1つのクラスに押し込めた（FrontControllerは別クラスだけど）。そうするとすごくわかりやすいコードになって、初心者から「こっちのほうがずっとわかりやすいんですけど、それでもStrutsを使う利点って何ですか」と聞かれ、答えに窮してしまった。

これ↑、まるで俺のことのようだ。涙でそう。

要するに、(Strutsは)「問題の複雑さ」をJavaのコードからXMLファイルに切り出しただけで、本質的な難しさは解消されていなかったということです。

以上、プログラマー日記(2006-02-21)より。

一方でこんな記事も見かけた。

(PHPで)MVCモデルで言うコントローラーを作りたければ、

switch 　（分岐用変数）
case 条件１:
require "条件１のPHP";　
break;
case 条件2:
require "条件2のPHP";
break;
　・
　・
　・

最低限のものなら、たった、これだけで終わり。なんなら、これだけを書いたphpを定義ファイルとしてしまえば良い。それ自体もrequiredで呼び出すことができる。
Javaで何故これを実現するのに、わざわざstruts.confにいつまで経っても覚えられない特殊文法のXMLを書いていたのか？が不思議に思えてきた。

以上、 F's Garage：PHPがスゴイところ。 より。

またうまいタイトルが思いつかなかったが、つまり、 送られてきたメールを自動的に読み込んでしかるべく処理してしまおうという アプリを作る際のほんのちょっとしたコツのお話。 先に断っておくが自前のメールサーバを用意しているのが前提である。

誰でも思いつくのが、アプリがPOP3をしゃべってメールサーバからメールを取り込む、というアプローチだ。有名なグループウェア「サイボウズ」のWebメール機能がこれにあたる。物販サイトから自動送信される注文メールを自動的に読み取って自前の受注データベースに入れてくれるアプリなどもそうだ。楽天市場の出店者に重宝されているらしい。

だが、一般のメールクライアントと同じようにPOP3を使うだけが手段ではない。

sendmailやpostfixなどのメールサーバのエイリアス機能は、 届いたメールをパイプでコマンドに渡すということができる。/etc/aliasesファイル等に次のように書く。

root: hogehoge    ←普通のエイリアス
hogeap: "|/usr/bin/perl /hoge/hogeap.pl" ←アプリに渡す場合
hogeap2: hogeuser,"|/usr/bin/perl /hoge/hogeap.pl" 
↑普通のユーザーメールボックスとアプリの両方に渡す場合（安全）

これで、hogeap@example.comに届いたメールは全てhogeap.plというアプリに標準入力で渡される。あとはアプリのつくり次第だ。ヘッダや本文を解析してデータベースに直接入れるもよし、誰かに改めて転送するもよし。メーリングリスト運用ソフトなどで古くから使われている手法だ。

もちろん言語はperlに限らずshでもJavaでもPHPでもrubyでもなんでもよい。一定間隔でPOPで読み込みに行くより、こんなふうに受信するたびに直接処理できたほうが楽ではないだろうか。

postfixのバーチャルエイリアス機能を使うともっと面白いこともできる。

@mailap.example.com mailap

virtualテーブルにこのように書いておくと、***@mailap.example.com宛てのメールは全てmailapというユーザーに転送される。さらに組み合わせ技としてaliasesテーブルに

mailap: "|/usr/bin/perl /hoge/mailap.pl"

のように書いておけば、mailap.example.comドメイン宛てのメールを全てmailap.plに読み込ませることができる。メールのあて先のアカウント部分（@の左側）はなんでもよいので、その部分を変数にすることができる。 変数には例えばユーザーIDなり日付なりそのハッシュ値なりを入れておいてアプリ側で判断できるようにしておけば、「user01-20060210-abc123@mailap.example.comにメールを送るとその本文があなたのブログに掲載されます。ただしこのメールアドレスは2月10日の24時間のみ有効です」といったサービスが可能だ。楽天広場などのブログサービスでおなじみ。

当然、メールサーバ上でアプリが動くことになるので、通常のメールボックスへの格納よりは負荷がかかるが、後でアプリが処理しやすいような形式のファイルにして保存しておくとか、簡単な解析だけやってデータベースに格納するくらいにしておけばそれほどでもないだろう。届いたメールに対するより複雑な処理は、その格納しておいたファイルなりＤＢなりに別なサーバからアクセスしてやらせることでメールサーバの過負荷を避ける方法もある。

メールを送信するアプリの話なら本屋でも技術系サイトでもどこにでもある。 しかしメールを受信してどうにかするアプリの話は意外と少ない。それは自前のメールサーバが必要になるケースが多いのが原因かもしれない。 しかし、先日話した専用レンタルサーバならそれが可能だ。 興味を持ってもらえれば先日の記事も報われるかな。

うまいタイトル思いつかなかった。とにかく、生半可な知識や先入観で下手なことをする前に、前もって自分で勉強しておくか、それができないならわかる人にまず相談してから行動にうつさないと、恥をかくことになるよ、という話。

どうにかしてライバル政党の足をひっぱりたくてしょうがない人たちが、高校生でも見抜けるような初歩的なＩＴトリックを使っただけのツッコミどころ満載なガセネタに見事にひっかかっている件はご存知のとおり。

404 Blog Not Found:「堀江メール」の真贋鑑定
（わかりやすい説明はほかにもいろんなサイトにあるんだけど面倒なのでとりあえずこれだけ）

某議員も、行動に移す前に、ちょっとネットに詳しい人に「どう思う？」と聞いておけば恥をかかずに済んだのに。 こんな新証拠で切り返されたらなんて言うんだろう？(笑) もちろん冗談だけど。

余談だが、アメリカ産牛肉の問題の件についてもこんな記事が出ている。

米最大手の食肉加工業者が民主党に怒る理由 - nikkeibp.jp - 企業・経営

要するに、閣議決定されたはずの視察に行きもしなかった与党側の某大臣と、どっちもどっちなんじゃねえのということで。

話をＩＴに戻そう。次に、単なる脆弱性を突かれた不正侵入を、いまふうなコトバで叫びたがる人たち。

編集便り・原因はサイバーテロと確認しました

いや、サイバーとかテロだとか、センセーショナルに書きたいのは商売柄だろうからということで譲ろう。 でも「自分（のつくったアプリ）は悪くない！」と自分に言い聞かせたいがためなのか？それとももしかして、自分の作ったアプリがあまりに脆弱 or 既に注意喚起されていた脆弱性を放置していた（かもしれない）ということにすら気づいていないのか？と考える筆者はひねくれすぎだろうか(笑)。 ぜひ専門家に原因を追究してもらって公表していただきたいものだ。

しかし、その専門家ですら、こういうことをやらかす輩が多いのかと思うとげっそりする。

「松竹映画館ドットコム」不正アクセスについての調査結果ご報告│松竹

不正侵入されたサーバーのデータを消してしまったのでもう原因究明もどの程度の不正操作があったのかも永久にわかりません？もうね、アホかと。

一方、Winnyの開発者が著作権侵害の幇助という罪で起訴された件。

また、検察側が提出した証拠のうち、京都府警がWinnyを使ったファイル交換の実験を行なった際の説明図についても、村井氏に対して質問が行なわれた。図版には、ルータの内側のネットワークではプライベートアドレスを利用するように書かれているが、実験を行なったというPCにはグローバルアドレスが割り当てられているように書かれており、これではインターネットには接続できず、書かれているIPアドレスやセグメントが間違っていると指摘した。
Winny開発者の裁判に村井教授が証人として出廷、検察側の主張に異議(InternetWatch 2006/2)より

村井教授は正真正銘のネット業界の専門家。インターネット上の電子メールで日本語をやりとりするためのRFCを書いた人。音楽業界における坂本龍一みたいなポジションにいる人で、要するに神である。 それにしても警察側の初歩的なミス、というか何にもわかってないんじゃないか的な有様が笑える。これじゃ村井教授を召還するまでもないような気がしないでもない。もちろん教授はほかにも至極まっとうな意見を出しているので詳しくは上の記事を参照。

結局のところ大事なのは、学ぶことを怠らないことだ。
Linuxセキュリティクックブック―システム防御のためのレシピ集

たしかに、最近の共用レンタルサーバサービスは一昔前の「perlによるCGIなら使えます」程度のサービスしかなかったころに比べればとてつもなく高機能になった。 perl使えます、CPANモジュールはこれだけ用意してます、PHP使えます、telnet/sshでシェル使えます、cron使えます、MySQLのアカウントも１個つけます、sendmailたたけます、メールアドレスは500個まで設定できます.....etcetc

しかし、世の中の有名なWebサイトは、そのサイト専用のサーバを使い、Web、AP、DB、DNS、メール、ソースコード／コンテンツ管理、セキュリティ監視等を縦横無尽に組み合わせたものばかりだ。さらにそれらが組み合わさって起こる性能問題への対処も含めると、共用サーバを使っているだけでは絶対に学べないことや、そういうやり方もある、という発想にすらたどり着けないことがある。

筆者が直接／間接に知っている範囲での話だが、この業界の優秀な技術者は、自らの趣味、研究や勉強道具代わりとして、専用レンタルサーバーを借りている（た）ケースが実は少なくない。 一方で多くの技術者（の卵）は、共用レンタルサーバサービスの高機能化、低価格化を各社が競っているのを追うばかりで、「レンタルサーバを乗りかえようかな」といっても専用サーバを借りるという選択肢にはまったく考えが至らない人が少なくない。

昨年の秋に株式上場を果たしたレンタルサーバ業界の老舗、さくらインターネットの専用レンタルサーバは月額6800円だ。 6万円じゃない。その額は、半分も読まないような高価な技術書を買ったり上達の見えない英会話教室に通ったりなけなしの5万円を大して儲かりもしない株式投資にあてるのと比べてどちらが有意義だろう？

専用レンタルサーバなんて借りなくても、自宅のADSL環境でお古のパソコンにlinux入れてルーターの設定をいじってダイナミックDNSサービスも契約して、いわゆる自宅サーバーってやつで間に合ってるよ、という人も多いだろう。しかし、PCの稼動音が意外とうるさいとか、ブレーカーが飛んだときの対処が面倒だとかハードディスクがクラッシュして面倒なのでそれっきりとかいう状態の人も少なくないだろう。（※たいていの専用レンタルサーバはHDDのクラッシュは無償交換してくれる。日々のバックアップは自分で取る必要はあるが）

簡単に考えてほしくない面もある。セキュリティだ。 自分専用のサーバでroot権を持つ以上、脆弱性への対処や侵入者の検知も自分の責任でやらなければならない。怠ると、そこが踏み台にされて加害者に手を貸すも同然になる。世界中から毎日のように繰り返されるsshサーバへのパスワード総当り攻撃の痕跡をログで見ては、推測されやすいパスワードを使ってはいけないということを身をもって知ることになるだろう。ただそれによってセキュリティ意識を高められるといういい面もある。

あくまでも静的コンテンツ主体で、Webアプリなんてお問合せフォーム程度のものしかいらないよ、というのなら安い共用サーバーで十分だ。MovableTypeさえ使えればいいという場合もしかり。

しかし、本格的なWebサイト、Webアプリをつくりたい、あるいはそれを本気で学びたいと思うならば、root権のある専用レンタルサーバーを選択肢に入れて考えてみてはいかが？

過去記事のほうにコメントいただいて知ったのですが、ついに始まりました。やってくれましたライブドア。

お天気Webサービス仕様 - Weather Hacks - livedoor 天気情報

でも今日、明日、明後日までのしかないのがタマにキズ。 できれば週間天気予報にも対応していただきたい。

さて、あなたは気象庁に月額10万円超払ってやっともらえるXMLを使いますか？ それともライブドアWeather Hacksを使いますか？（笑）

．．．と、まあ素直に喜び称えるのはここまでにして。

結局のところ、気象庁が天気予報のXMLを直接配信するようになった場合にはこういうサービスはひとたまりもなく消えかねない。天気予報という、経済と生活に大きな影響を与える情報の流通経路が、気象庁の官僚とその天下り先と民間業界とのバランス次第でいかようにも変化してしまうという状態は今後も続くわけだ。素直に気象庁がいまのXML情報の配信を無償化してしまえば話は違うけど。

see also:
もしも天気予報がXMLだったら − その１ XMLとは？(2004/3)
もしも天気予報がXMLだったら − その２ できない理由(2004/3)
天気予報をXMLで提供すると気象庁が発表してから半年が経った(2005/7)
天気予報のXMLはFTPでGETできる。ただし月額10万円超(2005/8)

追記：
さっそくなんか作ってる人がいますね。
p4lifeのメモ - PHP で Livedoor のお天気Webサービスを使う

とりあえず速報。

日本時間2月8日現在で、 46000件ほどある。 つまりもとに戻ってる。

以下は、教訓はなぜ生かされなかったのか：IT Proからの抜粋。

「サーバーとネットワークはNECネクサソリューションズの資産またはリース物件で，システムはすべてNECネクサソリューションズが所有，作成，または選定したもの。当社はNECネクサソリューションズからソースコードの開示を受けていない。またアクセスログはネクサが保有し，管理している。ネクサは当社に対しアクセスログを提供していない」（ワコール）

という条件のもとにあって、

「SQLインジェクションは仕様で規定されていない問題であり，瑕疵ではないと考えている」と，NECネクサソリューションズ 多田氏は言う。

　「開発した2000年8月当時，SQLインジェクションは広く知られた脅威ではなかった。建物に例えるなら，建築当時はあまり知られていなかったサムターン回しという手口による侵入が頻発するようになったようなもの。日々新しいセキュリティ・ホールが発見されている。あらゆるケースをすべて網羅して穴をふさぐことはできない」（NECネクサソリューションズ 多田氏）。

とかいうセリフを吐く輩は、偽装を見抜けなかったのは検査機関のせいだとぬかすマンション屋や、「違反しました。どうもすいませーん」とぬかすホテル屋とほぼ同列である。

SEOテーマの他のブログサイト等で既報ですが、筆者も調査してみたので改めてまとめた。日本時間2006年2月5日現在、ＢＭＷドイツ本国のサイトはgoogleのインデクスに存在しない。 (※追記：日本時間2月8日現在で46000件ほどヒット。つまりもとに戻ってる。BMWがGoogleに「もうしませんから戻して」と泣きついたという見方が妥当かと)

念のため同社のほかのサイトも調べておこう。いずれも2006年2月6日現在。

サイト名	ドメイン	Googleでのsite:検索結果の数
BMWドイツ本国	bmw.de	該当無し
BMWインターナショナル	bmw.com	1360件
BMW日本	bmw.co.jp	15200件
BMWアメリカ	bmwusa.com	871件
BMWフランス	bmw.fr	18500件
BMW韓国	bmw.co.kr	377件
BMWオーストラリア	bmw.com.au	32800件

これはGoogleの不具合なんかではない。

Googleの技術者、カッツ氏はブログで次のように公言している。

Remember my previous post noting that Google would be paying more attention to webspam in other countries and languages this year? This week our webspam team continued ramping up our anti-spam efforts by removing bmw.de from our index, and ricoh.de will be removed soon for similar reasons.
（訳） 「今年は、（英語以外の）他の国や言語におけるWebスパムに対し、Googleはより多くの注意を払うことになる」という少し前の記事を思い出してほしい。 今週、われわれのWebスパム対策チームは、アンチスパムの取り組みの手始めとして、bmw.deを我々のインデクスから削除した。ricoh.deも同様の理由でまもなく削除する。

（途中、bmw.deサイトがJavascriptを使ってGoogleのロボットをだましている画像が2枚）

That’s a violation of our webmaster quality guidelines, specifically the principle of “Don’t deceive your users or present different content to search engines than you display to users.”
これは、「ユーザーをだましてはいけない。また、ユーザーに見せるものとは違うコンテンツをサーチエンジンに見せてはいけない」という、我々のWebマスター品質ガイドラインに明確に違反している。

Ramping up on international webspam (webスパム対策の国際的取組みの立ち上げ) (Matt Cutts: Gadgets, Google, and SEO 2006/2)より、一部を抜粋＆翻訳。

ちなみに、2005年10月のインタビュー記事によると、 カッツ氏のGoogleでの立場は 「lead senior engineer, webmaster relations, quality control specialist」（主席シニアエンジニア、Webマスター関連、品質管理スペシャリスト）である。

上の引用でbmw.deがやっていたという「Javascriptリダイレクティング」とは、検索エンジンがJavaScriptを理解できないことを逆手に取った手法である。つまり、

<html>
<script language="javascript">
  location="http://一般ユーザー向けのコンテンツがあるURL/"
</script>
検索エンジン向けにキーワードやリンクをちりばめたようなテキスト
</html>

こう書くことによって、一般ユーザーが使うブラウザはユーザーをそれようのコンテンツに誘導（リダイレクト）し、一方で検索エンジンはJavaScriptを理解しないのでその下のテキストをコンテンツであると勘違いして読み続ける。

こういった「検索エンジンだまし」のことを、ドアウェイページとかクローキングとか言うらしい（正確な定義は知らないけど）。 どことは言わないが、日本の有名企業のサイトでもこれをやっている例はある。 いずれにせよ、こうした行為は、後で後悔することになる。

see also:
ウェブマスターのための Google 情報
検索エンジンスパムのGoogleへの通報フォーム
独BMWのサイト、Googleインデックスから削除される(SEM R 2006/2)
Google、「スパムは厳しく対処」の姿勢を見せる(CNET Japan Blog - 渡辺隆広のサーチエンジン情報館 2006/2)
サイバーエージェント、Googleの逆鱗に触れてインデックスより削除

日本時間で2月の3日あたりからGoogle Analyticsに不調が起きているらしく、 管理画面見てもＰＶ数も訪問数もゼロ。 複数のサイトで起きてるっぽいので一部のサイトというわけではなく Google Analyticsの利用サイトの全域に影響しているのでは？とにらんでます。 他の利用者の方、調子いかがですか？