Web屋のネタ帳

ライブドア−旧社名エッジ／オンザエッジ−が、 合併問題でゆれている近鉄バッファローズの買収に名乗りを挙げているらしい。

野球はそれほど興味ないので「ふ〜ん」としか思ってなかったのだが、 こんな記事にたどりついた。

署名で書く記者の「ニュース日記」:「社長日記」に異議アリ！

たかがblog−メモや日々のよもやま話−に何をいきまいているんだろう？というのが正直な感想。 誰もが知っているマスコミ大手の偉い人クラスの書くこととは思えない。

そういえば、なにかこう、十数年前の、「上司と新人類」みたいなことと同じような構図を感じる。つまり単なるジェネレーションギャップ？

MODULE.JP - ユニバーサルなHTMLフォーム認証

basic認証−ダイアログボックスがポンと出るやつ−ではなく、 フォーム認証−例えばMyYahoo!にログインするときのような−をApache段階で共通に行えるモジュール。世の中にはすごい人もいるものです。自分もCが書ければ・・・。

KNN's Photolog:セグウェイ返してください！」キャンペーン

だそうです。

この件に関しては賛否両論いろいろあるようだが、 筆者としては、日本でのセグウェイ云々の議論がこれで終わりというのはあまりにも悲しすぎると思う。

See also:
セグウェイと道交法とイラク派遣
『セグウェイ』の行く手を阻むヨーロッパの交通法規

「文字の大きさは相対指定しましょう」
「画像にはaltタグを入れましょう」
みたいな基本が書かれているJIS規格が 2004年6月20日、正式に制定された。

素案づくりや公開レビューなどはすでに2003年の夏から秋ぐらいに 行われていたので知っている人は知っていたと思う。 自分も公開レビュー案をざっと見た覚えがある。

このたび正式文書になったということで、改めて目を通すくらいしようと思ったのだが、

JIS X 8341-3:2004 − 高齢者・障害者等配慮設計指針−情報通信における機器，ソフトウェア及びサービス−第３部：ウェブコンテンツ − JSA Web Store-規格詳細情報（JIS）

和文ＰＤＦダウンロード3045円 − 買い物かごへ

あのー、こういう文書って、ひろくあまねく見てもらうことによって この規格に沿ったWebづくりを推進して、見やすいWebサイトを増やそうぜ、 っていうのが目的だと思うのだが・・・。

そりゃわからんでもないですよ。お役所の文書を蓄積するWebサイトを 維持するのにもそれなりにお金がかかるということは。 だから規格文書を読む人自身に多少の実費を請求しようという趣旨もわからんでもない。

しかし、よく考えよう。

1. ショッピングカート機能や会員管理（ログイン/ログアウト）機能を 装備したWebシステムを発注し、運用委託し、 クレジットカード決済するためにカード会社と契約し、 それなりに集まってしまう個人情報をそれなりに厳重管理し、 毎月の入金などしかるべき会計処理し、消費税も納め・・・といったことをやるのと、
2. PDF版の規格文書ファイルをWebサーバにだーっと置いて、そのindex.htmlも簡単に作っておいて、 もし必要なら検索窓をつける、といったごく簡単なサイトを作るのと
   （検索機能はnamazuとかで十分可能。いや、Googleのサイト指定検索窓ならタダで30分で可能！）

トータルなコストとして考えて、上のの二つのうちどちらが、人的および金銭的コストのかけ方として効率的で、しかも公的な規格文書そのものの本来の目的により近づけるだろう？

ちなみに、JISなどの規格を取りまとめているのは、日本規格協会という財団法人らしい。

たったの１．７メガ、５６ページのPDFファイルをダウンロードするだけで3045円って・・・買い物カゴに入れてクレジットカード決済って・・・

• これだけで、世の貧乏クリエイターさんたちのやる気を５０％ほどそぐことになって、 規格文書本来の目的をいきなり邪魔しているような気がするのは筆者だけ？
• 仕方ない、買うかって？ ５００円ならともかく、３０００円なら他に買いたい技術本いっぱいあるんだけど・・・と思うのは筆者だけ？
• ちなみに、去年の素案＆公開レビュー段階の文書の中身は全て「公開レビューは終了しました。 この素案は削除されました。」になっている。こういうところだけは計画的だなあと感じるのは筆者だけ？
• PDF版と紙文書版が両方とも3045円で同じ値段ということはなんにも考えずに従来型の紙媒体出版物と同じ値段にしただけだろ！とツッコミたくなるのは筆者だけ？
• Webアクセシビリティに限らず、公的な規格文書を自前のショッピングWebサイトで売り出す前に、自分らのWebそのものに対する理解や、公的文書のネット配布と紙配布のコストの違い、目的達成度の違いに関する理解を勉強しなおしたほうがいいんじゃないのと思うのは筆者だけ？

素案のときのPDFファイルとっときゃよかった。どなたかまだお持ちじゃないですか？ Googleのキャッシュには・・・もう無いかなあ。

（前回からの続き）
筆者の経験的に言って断言するが、 「リコメンデーション機能があったらな・・・」といったことを考えるＥＣサイトの9割、 いや95%が、もっとほかに取り組むべき多くの問題を抱えている。

• 8MのADSL回線で見てもページの表示に5秒以上かかることが多い

  これはリコメンデーションだの商品数だの以前の問題である。

• 検索機能が無いまたは不足

  日本の主要な検索サイトで検索に用いられるキーワードの第一位が「yahoo」である。 つまりユーザーはずぼらなのだ。 ブラウザのアドレスバーに「www.yahoo.co.jp」と打つことすらめんどくさがるほどに。 だからこそ、ユーザーは無意識に検索フォームを探し、 条件反射的な勢いで自分のほしいものの単語を打ち込む。 望むものが見つからなければその時点でそのサイトからサヨウナラだ。 検索エンジンを買うお金が無いのなら、とりあえずGoogleの力を借りればいい。

• とにかく品揃えが少ない

  １０００アイテムも無いのならリコメンデーション機能など全く必要ない。 通常の検索機能と、サイトの階層構造の整理やメニュー表示（パンくずリスト等も含め）の充実で十分だ。 「品揃えが豊富」これは商売において客を集める基本じゃないだろうか？

• ひとつひとつの商品ページにおいて説明文が30文字もない

  ひどいときは値段と買い物カゴに入れるボタンがあるだけ。 たとえリコメンデーションで誘導されてもそれでは買う気になるはずもない。

• 商品の写真が無いか、あっても一枚だけ、小さい、ピンボケ等とにかく貧弱

  たとえばおもちゃのＥＣサイトでは、ぬいぐるみなどが単独で写っている画像よりも ２、３歳の子供が実際にそれを抱いている画像のほうが、売れ行きは1.5倍になる。 大きさのイメージがつかみやすくなるからだ。
  商品画像の良し悪しは購買意欲の増減に直結する。 ただデジカメで撮ればいいというわけではない。 工夫すべきことはいろいろある。 (See also: 商品画像すら動的生成しているアマゾン)

• おそろしく書きづらい注文フォーム

  「郵便番号にハイフンは入れないでください」！？ だったら「012-0012」と入力されたものは「0120012」に自動修正して 処理を続けてくれよ！簡単だろ！ とプンプンしながら 戻ると、苦労して入力した都道府県やら市町村やら全て消えていて最初からやり直し〜 みたいな。

• 見づらい

  白地に黄色い文字＝薄くて読めない。 赤、青、黄色、緑、やたらカラフルな色使い＝目がチカチカするだけ。

• 不親切なナビゲーション

  トップページ→商品カテゴリ→個別商品詳細、といった階層構造が無い。 階層メニューリンクも無い。 ひどいときはトップページに戻ることすらままならない。 つまりサイト内の構造がむちゃくちゃになっている＝ユーザーが迷子になりやすい

• フレームの弊害

  フレームの使いすぎでスクロールバーだらけで見づらい また商品を一意に示すURLが無い（詳細は→フレームを使うと「ここを見てください」とURLを伝えることが事実上できなくなる − 後悔しないためのWebデザイン ）

• 基本デザインの問題

  ツールバーやアドレスバー無意味に消している、フォントサイズを無駄に固定している、横幅を固定している、むやみなポップアップ ウィンドウ、 など。

• 過剰なユーザー認証/管理機能

  とにかく住所氏名を書いてユーザー登録をしてログインしないことには 見ることすらできないページがたくさんある。 当然、GoogleやYahooなどのロボットもクロールできないので 一般検索エンジン経由での集客が望めなくなる。

• システムやデザイン以前の問題

  「店長からのメールはこちら」（つまりメルマガ）とあるので ためしにと思ってメールアドレスを登録しても、いっこうにメルマガが送られてこない。 つまりメルマガを書く担当者がいないor書く気力が無い。 だったらメルマガの登録ページを削除すべきなのにそうしたコンテンツ管理すらできていない。 嘘みたいな話だが実際少なくないケース。

まずはこれらの基本をひとつひとつ解決していくことが先決であり、 かつ、多くの場合、それで十分なはずだ。

さて、リコメンデーションやらパーソナライゼーションやら、 昔のネットバブルの幻に惑わされるなと前回もさんざん言っておきながらナンなのだが、 新しい技術をやたら否定することもやはり本意ではない。 とりあえず本を一冊紹介したいと思う。

One to Oneマーケティングを超えた戦略的Webパーソナライゼーション トーマス A.フォーリー ， 西村 淳子

この本を書いたフォーリー氏はシルバーエッグテクノロジー社のCEO。 ルールベース型でもない、購買データの類似性抽出型でもない、 人工知能型のリコメンデーションエンジンをASPで提供している謎の会社。 だが、もしもシルバーエッグを使うならある程度の覚悟が必要だ。 たとえば自分のサイトのトップページ上段に置く「あなただけの本日の目玉商品！」の選択を、 人工知能なる謎のブラックボックスに託すことになるのだ。 そのことに違和感も不安も覚えないというのであれば、試してみる価値はあるかもしれない。

「うちのサイトにもリコメンデーション(レコメンデーション、recommendation)機能が必要なんだ！」 と声高に叫ぶＥＣサイト運営者が、おそろしいことにいまだに少なくないらしい。 結論から言うと、パーソナライゼーションもリコメンデーションも90年代後半のネットバブルの残骸のひとつだ。 導入して成功と言える例は世界でも数えるほどしかないだろう。

そもそもリコメンデーション(レコメンデーション)機能とはなんだろうか？ 直訳すると、recommendation＝アドバイス、推奨、オススメ。 噛み砕いて言うと、「ごいっしょにポテトもいかがですか？」というやつだ。 最近のマクドの店員はそんなこと言わないよというツッコミは無しの方向で(笑)。

リコメンデーション機能の実現方法には大きくわけて２種類ある。

1. 他人の過去の購買データの統計的類似性を利用する

   アマゾンの「この本を買った人はこんな本も買っています」が典型。 この手法を使うには次のような条件が必要となる。

   • 誰もが買うものだが、個人による嗜好性の違いが非常に大きい
   • 人間の能力では全容を把握しきれないほど非常に多種類な商品（少なくとも常時１万アイテム以上）
   • 売れ行きに季節変動が少なく、値段は高くても5000円くらい
   嗜好性が強く多種類な商品ならなんでもよいというわけではない。 たとえば衣料品は、１万円前後の洋服が同じ客にバカスカ売れるものではないし、 売れる内容に季節変動がありすぎる。 したがって他人の購買パターンとの高い類似性を見つけだせるほど大量の購買データを収集することができない。 つまり、かなり限られたジャンルの商品を扱うECサイトの場合にしか使えない方法なのだ。 書籍、音楽CD、映画DVD、他には・・・ワインとか？価格が高すぎるか。
   
   

2. あらかじめ決められたルールによって表示する

   ルールベース型と言われる。「ごいっしょにポテトもいかがですか？」は マクドの店員マニュアルというルールに沿って行われる。 この手法は商品の種類がなんであれ使えるが、次のような欠点がある。
   

   • やたらと個人情報を聞き出さなければならない
     そりゃそうだ。「ユーザーが、男性かつ年収400万以上かつ既婚かつ ・・・であるならば○○という商品/ジャンル（orそのリンク）を見せる」 というのがルールベース型リコメンデーションというものだ。 企業から流出した個人情報をベースにした架空請求が全盛のこの世の中、 誰が自分の情報を易々と他人に教えるだろうか？ そこをかいくぐってユーザーを登録フォームに誘導し、 根気よく個人データを入力させ、さらにサイトに来るたびに「ログイン」させて、 ようやくユーザーを識別しルールベースのリコメンデーションができる。 トップページの検索フォームに「横浜 マンション」と 打ち込んでもらうことに比べれば、その道のりは月より遠い。
     
     
   • 絶え間なくルールをメンテナンスしなければならない
     うまいルールがいくつか思いついたとしよう。 でも長い時間使えるルールはわずかだ。 商品はときどき入れ替わる。それにあわせてルールも調整しなければならないのだ。 しかし、ルールを考えるよりも重要かつ簡単なはずのコンテンツの管理 ＝商品カテゴリの整理や商品画像と説明文の編集＝ すらろくにできず四苦八苦するケースのほうが圧倒的に多いなかで、 ルールのメンテナンスにまで手が回るとは思えない。
     
     
   • そもそも定義すべきルールが見当たらない
     「あの商品を買った人はこの商品も気に入ってもらえる可能性が高い」というパターンを リコメンデーションルールを定義する担当者がどれだけ思いつくだろうか。 その数は意外と少ないことに気づくだろう。 それこそ、なにを買っても「ごいっしょにポテトもいかが」と言えば済む程度 （orそれに毛が生えた程度）のことしかできない場合もある。 ならば、高価なリコメンデーションツールなど必要ない。 定型文や画像のリンクをほんの数種類ばかり用意し、簡単な条件分岐でincludeすれば済む。
     
     

さて、ＥＣサイトの売り上げに貢献するのが高価なリコメンデーションツールの導入ではないとすれば、 何をするべきなのだろう？ 特別なことはなく、基本を大切にすべきというだけのことではないだろうか。 長くなったので次回に・・・。

See also:
ウェブパーソナライゼーションを酷評するレポート発表 (CNET Japan 2003/10)
ネットにおけるレコメンドは有効か(波多野blog 2005/4)

＠IT：Java TIPS − Eclipseのソース管理にVisual SourceSafeを活用

を見て「ちょっと待った」と言いたくなった。 以前VisualSourceSafe(VSS)をためしてみて面倒な事態になったことがある。 改行コードが「LF」なソースをVSSに入れると、次にチェックアウトするときは 改行コードが勝手に「CR+LF」になってしまうのだ。 これには困った。

そのときはあまり詳しく調査しなかったのだが、実際、解決策はあるのだろうか？（VSSの設定とか？） ご存知の方いればコメント求むです。

Webの世界にちょっと深めに足を踏み入れたことのある人なら、 というか、この「ネタ帳」を読んでいる人なら「Mozilla（モジラ）」という単語を まったく知らないということはないだろう。

実は、Mozillaという単語にはWebの世界の歴史が詰まっている。

1993年、アメリカのイリノイ大学の学生だったマーク・アンドリーセンを 中心とする研究チームが、「Mosaic」 （モザイクまたはモゼークと発音）というソフトをつくった。 文字しか表示できない当時のほかのソフトと違い、 同じ画面に文字と画像を同時に表示できるという点で画期的だった。 現在のWebブラウザの原型となるこのソフトは 現在もダウンロード可能だ。 興味のある人はお試しを。

1994年、シリコングラフィックス社の創業者ジム・クラークが、 マーク・アンドリーセンとともに新しいブラウザを作ることを計画する。 「Mosaicよりすごいやつをつくろうぜ」 そこで開発コードネームが名づけられた。 それが「Mozilla」。後のNetscape Navigatorである。

ご想像のとおり、MozillaはMosaicとゴジラを組み合わせた造語だ。 今もNetscapeのサイトにはこうした画像が残されている。 筆者の記憶が確かならば、昔はNetscapeをインストールすると、 インストール先ディレクトリのどこかにこの画像のアニメーションGIFがあった。 隠れキャラみたいなものだったのだろうか。（とっとけばよかったなあ・・・）

どんなソフトウェアでもそうだが、 製品として売られるパッケージには「Netscape Navigator」とか 「Netscape Communicater」と印刷されていたりしても、 細かいところでは開発コードネームがそのまま露出してしまうものだ。 HTTPリクエスト信号を送信する際のUser-Agentヘッダ （＝Webサーバのログに残るブラウザ名）に記される 「Mozilla」の文字列がそのひとつである。

と、ここまで書いたところで、下のページを見つけてしまった。

第一部 Mozilla とは？ - はじめての Mozilla 1.0

ここで書いてるのよりずっと詳しいじゃん（苦笑）。

ところで、なぜ、MicrosoftのInternet Explorerや Yahoo!のクローラーまでが Mozillaを名乗ったりするのだろう？ 実はそれほどたいした理由は無いというのが実際のところだが、 長くなりそうなのでまた次の機会に。

他人の無線ＬＡＮ盗用…不正アクセスで逮捕の大学職員
（読売新聞 2004/5)

という報道があったが、実は筆者もゾッとする経験をしたことがある。

１年ほどまえのことだ。ノートパソコンを買い換えた。無線LAN内蔵のやつだ。 家に帰って嬉々として(笑)箱を開け、マシンを立ち上げてWindowsの初期設定をし、再起動すると、 「無線ネットワークに接続しました」のようなメッセージがピョコンと出た。 「？？？」と思いつつ、ためしにブラウザを立ち上げ、www.yahoo.co.jp や他のurlをたたいてみると、 ちゃんと見れるではないか！ もちろんマシンのLANケーブルを抜いた状態で、だ。

ちょっとまて、無線LANのアクセスポイントは我が家にはまだ存在しない！ （あとから買いに行こうと思っていたので）

おそらく、近所の家にセキュリティ設定の施されていない無線LANのアクセスポイント機器があって、 そこに筆者のノートパソコンが自動接続したのだ。 どこの家、あるいは事務所や工場、なのかはいまだにわからない。 アクセスポイントの性能やアンテナの位置、電波状況によるのだが、我が家から半径３０ｍ、もしかしたら５０ｍくらいのうちのどこかだ。

読売の記事にある

...容疑者（４７）は昨年１１月下旬、車に積んだパソコンを使って、無断使用防止対策が講じられていない無線ＬＡＮ用電波を物色。 東京・調布市の住宅街で、会社役員宅の電波が無断で使えるのを発見した中山容疑者は....

という手法は、「ウォー・ドライビング」と呼ばれ、欧米でもすでに問題になっている。

警視庁が、同大のコンピューターに残されていたアクセス記録を分析した結果、会社役員の自宅のパソコンが不正アクセスの接続ポイントの一つだったことが判明。会社役員は同庁の事情聴取に対し「身に覚えがない」と話したため、確認作業を進めた.....

「接続ポイントの一つだった」ということは、この容疑者は他の接続元も使っていて、 容疑者にたどりつく手がかりはそっちだった、ということを示唆している。

逆に言うと、犯人がこのアクセスポイントのみを使っていた場合には、手がかりがここで途絶え、 逮捕に至らず迷宮入りするか、あるいはこの会社役員さんが犯人扱いされる（＝冤罪）可能性が非常に高かったということだ。

現在筆者の自前のＡＰについてはESSIDの変更、WEPの設定、MACアドレスしばりといった セキュリティを施してある。しかし、無線LANの危険性をまるで考えずに、というか全く知らずに、何のセキュリティ設定もせずに使っているユーザーはごまんといる。 これはおこるべくして起こった事件、というか、絶対に氷山の一角にすぎないと考えているのは筆者だけではないだろう。

無線LANアクセスポイントを置いている人は注意してほしい。 誰かが勝手にあなたのアクセスポイントを使っているかもしれない。

無線LAN機能を持つパソコンを使っている人もやはり注意してほしい。 知らず知らずのうちに、覚えの無いアクセスポイントに接続してしまっていないだろうか？ 無線アクセスポイントは自分で買ったものだから大丈夫と思っていても、 あるいはLANケーブルを挿して使っている（＝有線接続）から関係ないと思っていても、 あなたの意思を、たとえばセキュリティ設定という形であなたの機器に教え込まなければ、 必ずしもあなたの意思に沿って稼動してはくれない。

立ち読みするだけのつもりだったのについ買ってしまった。

Spidering hacks―ウェブ情報ラクラク取得テクニック101選 Kevin Hemenway, Tara Calishain, 村上 雅章

米国で出版されたものの日本語訳なので、 日本国内向きの話はほとんど無いだろうと思っていたらとんでもない。

• Hack#52 Yahoo!テレビを使って番組の検索を行う
• Hack#87 Yahoo!オークションの検索
  （検索するとき何度も「次の20件」をクリックする面倒を解消する）
• Hack#88 レストランクーポン情報の取得
  （ぐるなびに登録されているレストランのクーポン情報を取得する）

といった感じで面白そうな事例がぞろぞろ載っている。

ほとんどの例がperlスクリプトだが、一部PHPもあるようだ。 先日記事で紹介したコマンドラインでピザを注文するperlスクリプトも "Spidering Hack" のひとつと言えるだろう。

ただ、この本を読んで、俺もやってみよう！と思う前に 絶対に注意してほしいことがある。

この手のスクリプトはちょっと間違えると スパイダリング先のWebサーバーに多大な迷惑をかけることになる。 例えば、1秒間に数十回もHTTPリクエストを送ることになるような 作り方は絶対にしてはならない。 アクセス先のWebサーバーがパンクしてしまいかねないからだ。 立派に業務妨害罪にあたるので注意してほしい。

という話はこの本の冒頭にもあるのでよく読んでほしい。 だからといって必要以上に恐れる必要はなく、 例えばスクリプトのしかるべきところに sleep(2) （2秒間休めという命令） などと入れるだけで、相手のWebサーバにかか負担はだいぶ押さえられるのだ。

アマゾンには「ログイン」が無い。「ユーザー登録」すらない。 あるのは「サインイン」それだけ。

「sign in」は特別な単語ではまったくない。たとえば
「You must sign in if you are using reference room」は
「資料室に入る場合には名前を書いてから入室すること」、
「All visitors must sign in at the nurse's station before entering a patient's room」は
「お見舞いの方は病室に入る前に必ずナースステーションでご記名ください」
といった意味合いになる。 「log in（ログイン）」といった純粋なコンピュータ技術を起源とする単語と違い、多くの人にわかりやすい言葉なのだ。

それに比べて、日本のサイトはどうだろう？ とにかくユーザー登録しろ？ そんな簡単に自分の情報を書き込む人はもはやいない。 ログインしてください？ログイン、ログアウトという言葉の意味がわからない人の存在を忘れていないだろうか。

アマゾンにおけるユーザー情報の登録フローは、 ユーザーの持てるボキャブラリーとその心理に忠実に考え抜いた結果、サインイン、それだけになった。たまたまそうなったわけではないだろう。 残念ながら日本は英語圏ではないため、ログインでもサインインでもその違いを意識する人は少ない（苦笑）。 しかし、辞書を引く、ただそれだけでそのむこうにあるものを学ぶことぐらいはできるはずだ。

Yahoo! JapanがGoogleとの提携を切って自前のロボット型検索エンジンを使うようになったのはすでに報じられているとおりだ。

Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)

これが、新生Yahoo!検索エンジンのクローラー（ロボットとも呼ばれる）が巡回するときに巡回先のWebサーバに示すUser-Agent名（＝Webサーバのログに残るブラウザ名）である。 自分でWebサイトを運営している人ならお手元のログにこんなのが残されているのを見ることができるだろう。 ちなみにSlurp というのは旧Inktomi社（Yahooが買収済み）が開発した検索エンジン用クローラーの名称である。

問題は、Mozilla/5.0 (compatible; と名乗られると、 アクセスログ解析ソフトがそれをPC用の通常ブラウザと同じと解釈してしまいかねないということだ。 たとえば、

Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.0.1) Gecko/20020823 Netscape/7.0" "-"

これはWindowsXP上のNetscape7.0が名乗るUser-Agentだ。 たとえばログ解析ソフトとして有名なanalogをデフォルトのまま使っていると、ブラウザの概要レポートにおいて、 Yahoo! Slurpも上のNetscapeも同じ「Mozilla/5.0」としてカウントしてしまうはずだ。 （※analogの最新バージョンであれば対応しているかもしれない）

ロボットによるアクセスと人間によるアクセスを区別できない統計結果など信頼できるものではない。 analogに限らずアクセスログ解析ソフトを使っている人は設定ファイルの調整などに気を配ったほうがいいだろう。 ちなみにGoogleは

Googlebot/2.1 (+http://www.googlebot.com/bot.html)

と名乗る。実にわかりやすくてよろしいし、ログ解析ソフトの調整も必要ない。

YST(YahooSearchTechnology)のロボットがMozillaでもないくせにMozillaを名乗るのが悪いというのももっともだ。 そもそもMozillaってなんなのさという話もあり、 それはそれでちょっとしたエピソードがあるので、そのうちまた記事にしたい。

以前、ここでも紹介したが、60歳代は本当によく印刷するらしい。その理由は？ キヤノンさんの発表では目的の１位は「年賀状・ポストカード等を作るため」（59.6％）とありましたが・・・
使いやすさを考えてみる。: デジタルカメラ写真印刷の理由（１）(2004/5)

ほんと、ネットの世界でF1M1層なんて言ってる場合じゃない。 50歳以上の層とその特性(?)を忘れてはいけないと思う。

See also:
印刷できるページを作るには
横幅を固定するな！ − 後悔しないためのWebデザイン
ツールバーもアドレスバーも消すな！ − 後悔しないためのWebデザイン
用紙幅に収まるようにWebページを印刷するツールを無償公開byエプソン

コマンドを入力するとピザが注文されて本当に届くというソフトの話。

コマンド一発、ピザよ来い!
(スラッシュドットジャパン 2004/5)

「電話しろよ(笑)」ってことでもちろんシャレなソフトなんだけど、 見方を変えればネットの技術の奥（とちょっとした未来）を理解する材料になる。

このソフト、 ダウンロードしてもらえばわかるとおり、perlで書かれている。 要は、人間がブラウザからドミノピザのサイトで注文データを入力するという動作を perlに自動的にやってもらっている。

CPANで公開されているモジュールを使っているようだ。例えば

• LWP::UserAgent
  ブラウザのような通信動作をやってくれるモジュール。たとえば

  my $ua = LWP::UserAgent->new;
  my $string = $ua->get('http://www.yahoo.co.jp/');
  

  これだけでYahooのトップページのHTMLソースを丸ごと持ってくることができる。

とか。（ほかにもあるけど省略）

Webブラウザからの操作をコンピュータ君に肩代わりしてもらうためのソフト はそれほどめずらしいものではない。 最近の筆者のお気に入りは Amazonのアフィリエイトレポートサイトに自動的にログインして売り上げレポートをメールで送ってくれるスクリプトと Googleのアドセンス広告のレポートをメールで送ってくれるスクリプト。

そうこうしているうちに、上に上げたようなピザの注文データをブラウザから入力するようなことに限らず、 ありとあらゆる「データ」の「やりとり」をHTTP、SMTP、XMLなどをうまく使いつつ、 できるだけみんな共通のやり方で行うようにすることで世の中便利にしていこうよ、 という機運が高まり、正式な規格となった。 それがSOAP。

実際にSOAP規格に基づいて提供されているWebサービスで有名なのは Amazon Webサービスと Google Web APIだろう。ちなみにGogle APIのサイトには ロボットみたいなのがパソコンに向かってgoogleのサイトを見ている絵がある。 「SOAPって何なの？」という問いに対するわかりやすい(?)答えを示唆している。

PEAR SOAP＋Google Web APIsでGoogle検索してみる

上の例はPHPスクリプトにGoogle検索させる例だ。もしもこれをSOAPを使わずに、 ピザを注文するスクリプトと似たような手法でプログラミングしようとしたら 少なくとも2倍以上の労力、半分以下の柔軟性になってしまうだろう。 逆にSOAP規格に沿ってサービスできるようになれば それに自動的にアクセスする仕組みを簡単につくれるようになる。

実際には企業間のクローズなやりとりで使われる場面のほうが多く、広く公開される形でのSOAPの利用は少ないかもしれないが、 まあとにかくamazonやgoogle以外の企業にも期待したい。