Yahooの検索がgoogleからYSTに変更

eNatural.orgさんの

[eN] Yahoo! Japan、検索エンジン切り替えへ
で知って驚いた。Yahoo Japanのページ検索がgoogleではなくなっているようだ。 Yahooが世界規模でいろんな検索技術を買収しまくってできあがったYST(YahooSearchTechnology)に切り替わっているらしい。 確かに同じキーワードで検索してもgoogleとは結果が違う。 日本ではもうしばらくgoogleからのライセンス提供を使い続けると思っていたのでちょっと驚き。

SEOを考えている人たち、SEOでご飯食べてる人たちにとっては大騒ぎになるのでは。

See also: ケイコとマナブに見る苦悩の検索エンジン対策

MS Accessの限界とインターフェースとしてのAccess

手軽で便利なツールだが、それゆえに限界もある、ということで…… おそらく多くの人がこやつには喜ばせてもらっているのと同じくらい悩まされているかと思う(^^; 私はけっこう好きなんだけども、これのせいで一時期胃に穴があきそうになりまいた。
MS Accessの限界
(つれづれネット散歩 2004/5 より)
そういえばず〜〜いぶん昔に必要に迫られてAccess単独でのアプリをつくったことが何回かあった。 小さなものだったしそんな長いこと継続利用されるほどのものでもなかったので、 つれづれネット散歩さんの話のようなカベにぶちあたる前に筆者の手元を離れてくれたのがコレ幸い。

いま筆者のもとではOracleやらPostgreSQLやらでつくったDBサーバに対し ローカルPCから簡単にアクセスする手段としてMS Accessが活躍している。 つまりAccess自身のDBエンジンは使わずに、外部のDBに対するインターフェースとしてのみ使う、ということ。 本格的なアプリにする場合にはもちろんAccessなんて使わずにWebなりVBなりでインターフェース部分をつくるけど。(VBももう最近使わないか)

実際、とにかくDBの内容をエクセルみたいな表形式で見せてくれ、といった程度の要件なら DBがなんであれそのインターフェースにAccessを使うことでかなり簡単に実現できるだろう。 もちろんエクセルでもできるけど。いや、むしろエクセルのほうが簡単なのか?うーん。 (あまりVBA詳しくないんで^^;)

とにかく、ハサミは使いようだ。

用紙幅に収まるようにWebページを印刷するツールを無償公開byエプソン

エプソン,用紙幅に収まるようにWebページを印刷するツールを無償公開
(ITPro 2004/5)
プリンターメーカーによるこうした行動は、プリンター購入者からの 「印刷したら右端が切れちゃうんだけどおたくのプリンタはどうなってるの一体?」 のような電話の数が無視できないほど多いということの裏返しとも言える。

そういったことをWebサイト側が自覚している場合であっても、だからといって必要以上にWebページの横幅を抑制しすぎると、 www.honda.co.jpのように「なんでこんなきゅうくつそうに左側にまとまっているんだろう?」みたいなことになる。

「Webデザインのせいじゃない。プリンタのせいでもない。ブラウザの印刷機能が貧弱すぎるのが悪いんだ。文句はマイクロソフトに言おうぜ。」 という話もあるが、そんなグチっぽく責任転嫁したところでお客様の問題解決にはならない。

See also:

ツールバーもアドレスバーも消すな! − 後悔しないためのWebデザイン

Javascriptを使ってツールバーやアドレスバーを表示しないようにしているページは多い。 しかもよりによって地図のページでだ。

話を続ける前に用語説明。

以下は、どんな企業のサイトにもたいていあるであろう、「弊社への地図」のページの例だ。

中外製薬の事業所地図のページ
「MAP」という画像をクリックすると、それぞれ地図が小さな別ウィンドウで表示される。

さて、ここでいくつか想像していただきたい。

  1. あなたは、それほどパソコンに詳しくない経験1年程度の派遣社員である。 上司に頼まれた。
    「取引先が来社する。駅からここまでの地図のURLをメールしてあげておいてくれ。」
    あなたはズバリなURLをメールで伝えることができるか? (ワンクリックでできてナンボの世界ということをお忘れなく)
  2. あなたは取引先の社員。上司に頼まれた。
    「打ち合わせに行くけど、初めて行くから場所がわからない。地図をプリントアウトしてくれ」
    あなたは地図をプリントアウトできるか?

ご理解いただけるだろうか?

  • ツールバーやメニューバーを消すと、印刷する手段を失う
  • アドレスバーを消すと、URLをコピーアンドペーストする手段を失う
ということだ。そもそも、 こういうデザインをしたデザイナーもそれを承認したWebマスターも、 Webサイトの利用シーンというものをまるで考えていないといわざるをえない。
画面上で右クリックすればメニューに「印刷」が出るからそれを使えばいいし、 「プロパティ」を見ればURLもわかるでしょう。
はたしてそれで初心者に優しいページと言えるか。 少なくとも筆者はクライアントにそんなことを話す勇気はない。

アドレスバーを隠すことはもっと深刻なセキュリティ問題を引き起こす。 とりあえずそれについては、産業技術総合研究所の高木氏のレポート にリンクを張っておくことにしよう。 なお、このレポートを見た銀行各社のインターネットバンキング担当者はあわてて 自社サイトのアドレスバーをちゃんと表示するように仕様変更したといういわくつき。

2006/4 追記

上で問題にしているページは現在では若干リニューアルされている。 メニューバーを消すのはやめたようだが、アドレスバーは消したままだ。 Javascriptを使ったオリジナルの「印刷」ボタンが追加されているが、MacのIEでは動かないと言う。 ちなみに、医師、薬剤師などの業界では伝統的にMacintoshを使う人が多い。 それって業界人なら常識的なことなのだが、それでもMacのIEでは動かないボタンを提供するあたり、 センスないねというかなんというか。あ、どうでもいいですか。

ホットデプロイメントは本当にホットなのか?

ホットデプロイメントは本当にホットなのか?
(Izu@San Diego 2004/5)
やっぱりそういうことなんだよね。 本番環境(クライアントに納品して稼動中の環境)でAPの変更があったときは、 まるっきり再起動させなきゃならないと。日中は利用者が多いからできないと。 つまり徹夜しろと・・・。

似たような話:Javaジャバ言ってる間にも(その2)

ところで、Apacheにgraceful restartはあってもgraceful stopが無いのが惜しい。 もしもこれがあったら、たとえばPHPなんかで書いたアプリを入れ替えるときであっても、 graceful stop → PHPスクリプト入れ替え → start の順でやることでいつでも、ほんの数秒で、しかも安全に、アプリの入れ替えができるのに。(わかる人しかわからない話になってしまった。)

フレームの代わりにPHPを使う

フレームは使うべきでないことは以前書いたとおりだ。 それでもフレームを捨てられないという理由の過半数は 以下のようなことだろう。

  1. 統一的なメニュー(orヘッダ、フッタ)をすべてのページにつけたい
  2. そのためにはメニューとコンテンツをそれぞれフレームにしたほうが 別々に編集できてしかも互いに干渉しないためメンテナンスしやすい
そこで、フレームを使わずに上の2点を実現する方法のひとつを紹介しよう。

下のようなフレーム構成のページがあるとする。

これはPHPを使うと以下のような二つのファイルによって構成することができる。
(menu.phpとする)

<a href=content1.php>コンテンツその1へ</a><br>
<a href=content2.php>コンテンツその2へ</a><br>
(content1.phpとする)

<html>
<body>
<table>
<tr>
<td valign="top" width="20%">
    <?php include("menu.php"); ?>
</td>
<td valign="top" width="80%">
    content1だよ。
</td>
</tr>
</table>
</body>
</html>
このようにすることで、
  1. 各コンテンツを作るときはmenu.phpをインクルードするように書けば メニュー部分が自動的に取り込まれる。手書きでコピペする必要はない。
  2. メニュー部分に変更がある場合にはmenu.phpを編集するだけで それをincludeしているすべてのコンテンツのメニュー部分も変更される
  3. コンテンツ1を閲覧したければ http://www.example.com/content1.php、 コンテンツ2を閲覧したければ http://www.example.com/content2.php というふうに一意なURLを表現でき、フレームを使ったがために「ここを見てください」とURLを伝えることが事実上できなくなるという致命傷を難なく避けることができる。
ということを実現できる。

PHP言語の include 命令は呼んで字のごとく「含めろ」という意味。 たったこれひとつを覚えるだけのことだ。 「プログラミングなんて無理」といわず、未経験のデザイナーさんでも挑戦してほしい。

ついでに、必ずぶちあたるであろう疑問や問題のいくつかについて以下に述べておく。

Q. とにかくPHPって何?状態なんだけど。

とりあえず本屋に行くこと。 数年前と比べると驚くほどPHP関連の書籍は増えている。

Q. いま借りてるサーバー、PHPは使えないみたいだ

迷わず乗換えを考えること。「PHP動きます」とうたっているレンタルサーバー業者はいまや山ほど存在する。

Q. 結局CGIでしょ?表示が重くなるのはやだよ。

PHP言語の動作原理は一般に言うperlなどのCGIとは違う。 技術的な話をしだすとキリが無いのでここでは 「体感速度的には静的ページを見るのとほとんどかわらない」 とだけ言っておこう。

Q. PHPを使うと、普通のHTMLみたいに手元のPC上で出来栄えを確認できないのは不便だ。

手元のPC上でApache+PHPの環境をつくることは読者の皆さんが考えるほど難しくない。 金銭的なコストもほぼゼロだ。 Googleで「apache php windows 環境」といったキーワードで検索すると いくらでも情報は出てくるのでそれらを参考にしてほしい。

Q. いま*.htmlになってる拡張子をすべて*.phpかえろってこと? ということは、リンクも全部*.phpに変えるの?そんな面倒な。

この理由でPHPの導入をためらう業界人は驚くほど多い。 しかし残念ながらそれはWebサーバーに関する正確な知識の不足である。 *.phpをPHPスクリプトとみなすというのは単にWebサーバーのデフォルトの設定に過ぎない。 Apacheで言えばhttpd.confの
AddType application/x-httpd-php .php
というところを例えば
AddType application/x-httpd-php .php .html
にするだけで、*.phpでも*.htmlなファイルであってもそこに埋め込まれているPHPスクリプトは実行されるようになる。 この設定は各ディレクトリの.htaccessファイルなどでも設定できる (httpd.conf側の設定にもよるので要確認)。

さらについでだが、includeされる側のファイルの拡張子は実はなんでもよい(Webサーバ側に拡張子設定をする必要は無い)。 上の例で言えば、menu.php は例えばmenu.inc であってもmenu.include であってもきちんとincludeされる。

国税庁システム3000億円で発注先が文具店でその下請けがIBMとNEC??

国税庁システム、発注方式見直し 開発費膨れて3千億円
(asahi.com 2004/5)
300億円の予定が5年遅れで3000億円というのもあきれたが、もっと驚いたのが、
  1. 発注先が資本金5億円の文房具屋
  2. その下請けが日本IBM、日立製作所、NEC、東芝、NTTデータ、キヤノン販売
だと!?!?

もうね、アホか!と。 この国は狂っている。

なんかヘンだぞ?ACCSといいWinny作者逮捕の京都府警といい

政治/社会的な話をするのはこのblogのテーマとやや離れるのでナンなのだが、 それでもやっぱりなんかヘンだと思う今日この頃。

不正アクセスの元研究員に流出の監視要求 著作権協会 - asahi.com : 社会
不正アクセス? まあ素人目にはなんでも「不正な」「アクセス」になってしまうだろうが、 技術的な観点から見れば、 このケースは「ACCSという家屋のなかのコルクボードかなにかに名簿が張ってあって それが家の窓から見える位置で、強力な双眼鏡で外から窓をのぞけば見えるような状態だった」 と言えるのではないだろうか。むろんそれを見て伏字もせずに(つまりwatanabeさんを○○さんに塗りつぶしもせずに)第三者に見せびらかした奴も奴だが、ACCSも責任転嫁しすぎやしませんか?

Winnyの作者を逮捕した京都府警も、ソフト作っただけでタイホ? そんなことやったら世の中のプログラマーはみなタイホだ。勇み足と感じざるを得ない。

なんでもシステム化されつつあるこの世の中。しかし IT技術に関する正しい知識(?)が、圧倒的に不足している気がする。

フレームを使うと「ここを見てください」とURLを伝えることが事実上できなくなる − 後悔しないためのWebデザイン


2005/4 追記: 例に挙げているみずほ証券のサイトは、 いつのまにか、フレームを使わないデザインにリニューアルされました。

みずほインベスターズ証券を例にしよう。

ユーザーが、みずほ証券に対し次のような質問をメールで送ってきたとする。

「株の売買にかかる手数料はいくらですか?」
これに対し「資料を送りますのでご住所を・・・」では模範解答とは言えない。 メールで問い合わせてきたお客様にはメールで返すべきだ。 だからといって売買手数料体系を長々と文章で書く暇はないし、お客様もそんなことは望んでいない。 手数料体系が書いてあるWebページのURLをメールで伝えるというのが回答としてべストだろう。

ということで、まず売買手数料について書かれたページを探してみよう。

  1. みずほインベスターズ証券のトップページにアクセスする。
  2. 左のメニューにある「Q&A」をクリックしてみる。
  3. 「サービスに関するQ&A」をクリックしてみる。
  4. 「委託手数料一覧」をクリックしてみる。
ビンゴ!このページをお客様に見ていただくのがベストだろう。

さて、あとはこのページのURLをメールでお客様に伝えるだけだ。 いつもやっているように、アドレスバーからURLをコピーする。

そしてメールに貼り付けて送信! たとえば本文は以下のような感じになるだろう。
○○様

お問い合わせ誠にありがとうございます。
弊社の売買手数料についてわかりやすい詳細が以下にございますので
ぜひご覧いただければと思います。
http://www.mizuho-isec.co.jp/MJ/index
.jsp?url=%2FMJ%2FMember%2FCategory%2FnodeName.jsp%3Fname%3DQA
さて、上のURLを実際にクリックしてほしい。(※) その結果に、お客様は満足するだろうか?

※ ブラウザのキャッシュ等が結果に影響してしまう可能性があるため、 できればほかのPCにメールを送るか、あるいはPCを再起動してから URLをクリックしてほしい。

いったいどうしたらよいのだろう?このURLを書けばいいのか?

http://www.mizuho-isec.co.jp/MJ/Member/Category/nodeName.jsp?name=ITAKU_TESURYO
いや、あってるが・・・見え方がなんかヘンだ。どうやってトップページに戻るんだこれ?(笑) 見え方も含めてこっちが意図したページそのものを示すURLを提示できないとなると、
http://www.mizuho-isec.co.jp/ にアクセスしていただき、 左側のメニューから「Q&A」を選んでさらに 「サービスに関するQ&A」をクリックし、 その2番目あたりに「委託手数料一覧」というページがありますので そこをクリックしてください。
という文面でメールすることになる。おいおい冗談じゃない。 ワンクリックでいけてナンボの世界でこんなやりとりをしていてはお客様の納得と満足が得られるわけがない。

これがフレームの最大の欠点である。 「ここを見てください」とURLを伝えることが事実上できない。 ということは、メールマガジン上にURLを書けないということでもある。 メルマガを主要なマーケティングツールとして使っているECサイトだったら、これは致命傷だ。

実は、みずほ証券のケースでは

http://www.mizuho-isec.co.jp/MJ/index .jsp?url=%2FMJ%2FMember%2FCategory%2FnodeName.jsp%3Fname%3DITAKU_TESURYO
というURLを提示することで目的を達成できる。 しかしこれはみずほ証券が使っているなんらかのCMS (コンテントマネジメントシステム)的な機能によるものであり、 そうした凝ったツールを使っていない場合にはまともな解決策はほとんどないだろう。

蛇足だが、みずほ証券のURLは顧客に教えるにはなんだか長すぎて怪しすぎる(笑)
(参考:ある経験則−ユーザーは?や=の入ったURLを嫌う?

顧客サポートのためのコールセンター業務には費用がかかる。 これをできるだけWebで解決できるようにならないか? というのはあらゆる企業に共通する要求だ。

わかりやすく言うと、消費者金融のプロミスのテレビCMのように、 井上和香みたいな(?)お姉さんをいっぱいそろえた電話サポート業務センター (=コールセンター)は構築と維持にものすごい金がかかるので、 これを2634.jpのようなWebサイトで 情報提供することでコールセンターにかかってくる電話の数を少しでも減らしてコスト削減したい、 ということである。

が、ちょっとフレームを使っただけで、その目論見の達成度は急減する。

もしも、フレームを使っているサイトを見つけたら、 トップページ以外の特定のページに行き、 そのページのURLをブラウザのアドレスバーからコピーし、 自分のお客様や友人に「ここをご覧ください」と伝えるようなつもりで 自分宛に(あるいは実際に友人に)メールしてみよう。 そして翌日、そのメールを見て、書いてあるURLをクリックしてみてほしい。 前日に自分が意図したページを一発で見ることができるだろうか? もしできなければ、そのサイトはWebサイトとして大きな欠陥を抱えている といわざるを得ない。

フレームの弊害についてはもう何年も前から言われていることだ。 「フレームの弊害」といったキーワードでGoogleで検索するといくらでもでてくる。 しかし、こうした認識が薄いWebマスターやデザイナーが未だにいる。 (ほんとうに、驚いてしまう・・・。)

Yahooやアマゾンではフレームをほとんど使っていない。 使わない理由があるから使っていないのだ、 ということを学び取ることは、そんなにも難しいことだろうか?

See also:
フレームの代わりにPHPを使う
特定のコンテンツ≒特定のURLという前提が崩れるとき - 後悔しないためのWebデザイン

題名の工夫とメルマガの限界

メールの題名とFromは既に戦場という記事で既に述べたように、メールマガジンの題名とFromの書き方は、 メールの開封率を上げる上で非常に重要だ。

最近、とある有名なECショップの出すメルマガの題名にちょっとした工夫を見つけたので紹介しよう。

お分かりいただけるだろうか? 題名の頭に全角空白をひとついれているのである。

ユーザーのメールソフト上で少しでも目立とう、という涙ぐましい努力と言える。しかし裏返すとそれは、(そのECサイトに限らず)メルマガの題名、From、本文の内容や送信タイミングなどのノウハウの発達が枯渇しかけている気がしてならない。 早い話が、もう工夫しつくしてしまって他に手段がなくなってきたためこうした視覚的トリックにたよらざるをえなくなってきた、ということだ。

メールを、新聞の折り込みチラシなどと同種の宣伝媒体としてしかとらえない場合、 そのノウハウの枯渇がすぐにやってくるだろうことは想像に難くない。 そうしたなかで、そろそろメールならではのマーケティング力を考えるべきだろうという以下のコラムに同意。

メールマーケティングの効かせ方
(japan.internet.com 2004/5)

楽天もPHP

楽天がWebサイト高速化ツールZend Performance Suiteを導入
(IT Pro 2004/5)
あくまで未確認情報だが、たとえば楽天広場などはPHPで構築されているはず。 ほかのサービスでも多々使われていると思われる。

参考: @IT:楽天とオープンソース、その密接な関係
(アットマークIT 2003/11)

日立、企業向けの Blog サービスを開始

いよいよでてきたという感じ。

日立、企業向けの Blog サービスを開始
(Japan.internet.com 2004.5)
参考記事:
blog(ブログ)でビジネスになるか?(1)
blog(ブログ)でビジネスになるか?(2)
blog(ブログ)でビジネスになるか?(3)

リップルウッド、三菱、新生銀行

<三菱自>米リップルウッドが出資の可能性も
(Yahoo ニュース 毎日新聞 より 2004/5)
だそうで(タイヤ脱落事件の三菱ふそうではなく三菱自動車)。ちなみに過去には
新生銀行再上場、リップルウッドは高笑い
(unique_critique 2004/2)
なんて話もあったりする。

「ハゲタカめ!」などと負け惜しみを言うじいさまは多いが、 個人的には、リップルウッドが悪いとかハゲタカだとかは少しも思わない。 やはり、買収される側がもともと愚かなことをやらかしまくっているだけじゃないだろうか。

そういえば雪印とおなじ

「スノーブランドを守りたかった」

「スリーダイヤに傷がつくと思った」

おごるじじいの言い訳はいつもおなじ。

PHP温故知新 − PHPはバッチ処理ができなかった(その2)

(前回からの続き) では昔のPHPはなぜバッチ処理ができなかった(やりづらかった)のだろうか? 実は、PHP言語の動作原理そのものに原因がある。

PHP言語で書かれたプログラムを実行する方式はいろいろある(後述)のだが、 もっとも多く用いられている方法は、PHPの実行エンジンをApacheのモジュールとして稼動させるというものだ。 これは一般にDSOコンパイル方式などと呼ばれる(DSO=Dynamic Shared Object)。 以下の説明ではWebサーバとしてもっとも一般的なApacheを前提として話を進めるが、 ほかのWebサーバ(IISなど)であっても基本は似たようなものだ。

上の図はApacheの構造をものすごく簡単に示したものだ。 このように、Apacheの内部は機能ごとにいくつかのモジュールに わかれており、必要に応じてモジュールを開発し、追加/変更することができる。 ちなみに、上にある各モジュールはなにかというと、

mod_log_config Apacheのログのフォーマットをつかさどる。 httpd.confファイルで言えば"LogFormat"という設定値にあわせて 実際にログをファイルに書き込む機能。デフォルトでコンパイル/追加される。
mod_access アクセス制限をつかさどる。 httpd.confで言えば"Deny"とか"Allow"とかそういうやつ。デフォルトでコンパイル/追加される。
mod_auth 基本認証機能を提供する。認証のかかったページを見ようとすると ブラウザがポンと認証用ダイアログボックスを示すアレ。デフォルトでコンパイル/追加される。
mod_php4 PHP実行エンジン。HTML中に埋め込まれた <?php 〜 ?>という タグ間に書かれたPHPコードを実際に実行し、結果をApacheに返す。 Apacheはそれをユーザーのブラウザに返す。
もちろん上は抜粋で、このほかにもいろいろある。手元のApache環境をいじれる人は /usr/local/apache/bin/httpd -l などのコマンドをたたくとそのApacheにコンパイルされているすべてのモジュールの一覧を 見ることができるだろう。(DSOとして追加されるモジュールは表示されない)

さて、わざわざ、PHPの動作原理などと難しい話をしたのにはもちろん理由がある。

前回、Webシステムの機能は画面処理とバッチ処理の 大きく二つにわかれるということを述べた。当然、PHP言語で書かれた画面処理は、 上で述べたようなApacheに追加されるmod_php4モジュールがそれを実行してくれる。 しかしバッチ処理はどうだろう?

画面を見る(ブラウザでアクセスする)or画面上のボタンを押す = Apacheがそれを受け取って処理してくれる
というわけだが、画面を見るわけでもボタンを押すわけでもないバッチ処理において、 Apacheはどう対処するのか?どうしようもないのだ! Apacheは、ブラウザからのなんらかのアクセスがないと何もできない。 不思議なことではない。一般にWebサーバーとはそういうものだ。 そのため、Apacheに依存するPHP実行エンジンは画面処理しかできない! ということになる。

対処方法はいくつかあるが、いずれもトリッキーというか、スマートではない。

  1. バッチ処理を画面処理として走らせる
    バッチ処理としての機能だけで、画面としてはほとんど何のHTML出力もしない PHPコードを書き、それをApache上に置く。 そしてほかのサーバー上で、あるいはWebサーバそのもの上で、 lynxやwgetといったコマンドラインから実行できるようなテキストブラウザ (Mozzilaでもできるのかな?)をcronなどで定期実行し、 その画面にHTTPアクセスさせることで、バッチ処理を走らせる。
    • この方法だと、たとえばアクセスが多くて 画面処理がこみあっている場合、バッチ処理用画面へのアクセスもその混雑に巻き込まれてしまい、 結果的にバッチ処理をうまく実行できない事態に陥る可能性がある。 オークションサイトで言えば、 オークション終了時刻の間際に出品者や入札者のアクセスが 増加したためにオークション終了バッチ処理が動かなくなるなんてことになる。 それはまずいだろう。
    • 10分とか20分といった時間のかかる大きなバッチ処理の場合、 Apacheのタイムアウト制限に引っかかってバッチ処理が完全に終わってないのに前に 強制的にPHPスクリプトが終了させられてしまう可能性すらある。
  2. ほかの画面処理のついでにバッチ処理を走らせる
    上で述べた方法とほとんど同じ。 実はPHP自身もこの方法を使ってある処理を行っている。 それは古いセッション保存用ファイルの削除という処理だ。 通常、session_start()関数が呼ばれるたびに 1/100の確率でこの処理も勝手に走るようになっている。 詳しくはここを。
  3. CGIコンパイル版PHPエンジンを併用する
    PHPスクリプト実行エンジンにはいくつかのコンパイル方式がある。 Apache-DSO方式のPHPが、完全にApacheの機能の一部として(=Apacheに依存して) 動作するのに対し、CGI方式でコンパイルされたPHP実行エンジンは apacheとは無関係に単体で動くこともできるので、バッチ処理に向いている。 ただしCGI方式だと画面処理はApache-DSO方式と比べ格段に遅くなってしまう。 画面処理用にApache-DSO方式のPHPエンジンを、バッチ処理用にCGI版を、 という使い分けをする方法もあるが、 二つのPHPエンジンを同時に管理しなければならなくなり、面倒だ。

この問題をながらく抱えていたPHPだが、 2002年12月にリリースされたPHP4.3.0によって、改善された。

PHP実行エンジンをコンパイル/インストールすると、 CLI(Command Line Interface)というコマンドラインから実行するためのインターフェースも デフォルトでインストールされるようになったのだ。 CLIは例えば /usr/local/bin/php といった具合で実行コマンドとして インストールされる。/usr/bin/perl と似たようなものだ。 これにより、画面処理は通常通り、Apache-DSO版で実行し、 バッチ処理はCLIにやらせる、といったことが完全にサポートされるようになった。

たとえば掲示板のように、書きこむ、消す、修正する、 といった程度の機能であれば、画面処理だけですべて事足りるので バッチ処理ができないという問題を気にする必要もなかった。 だが、ちょっと高機能なWebサイトをつくるにはバッチ処理が欠かせず、 しかしPHPはそれに答えることが事実上困難だった。 解決策を開発してくれたPHP開発コミュニティの皆さんに敬意を表したい。

PHP温故知新 − PHPはバッチ処理ができなかった

ほんの1年か2年くらい前まで、PHP言語には致命的な弱点があった。 バッチ処理ができなかったのだ。 いや、できなかったというと語弊があるので正確に言うと、 昔のPHPでバッチ処理をするような機能をつくるのにはかなりコツがいり、 場合によっては非常に難しかった。

掲示板のようにごく簡単なWebシステムであればバッチ処理の必要がない (あるいは運用でなんとかなる程度)ため、この問題を意識することはないのだが、 ちょっと複雑なWebシステムを作ろうとすると頭を悩ませることになる。

先に言っておくと、現在のバージョンのPHPはバッチ処理もできるようになっているので安心してほしい。 以下、Webシステムにおける画面処理とバッチ処理の違いや、 Webサーバそのものの構造とPHP言語との関連について極力わかりやすく書いておきたい。 わかりやすくとはいっても内容が内容なのでどこまでわかりやすいかは自信無いが。

比較的複雑なWebシステムとして代表的な、オークションサイト=たとえばYahoo!オークションとか=を例にしながら説明してゆこう。

Webシステムの機能には大きく分けて画面処理とバッチ処理がある。 バッチ処理は日本語で書くと「一括処理」という意味あいだ。 オークションサイトで言えば、まず、それぞれの出品物の画面を表示することそのものが画面処理である。URLに含まれた「a1234567」といったオークション番号をもとに、データベース(あるいはそのキャッシュ)から該当する出品物の情報を引き出し、HTMLに整え、ブラウザに返す。 その人がログインしているかしていないか、出品者か入札者かどちらでもない人か、によっても出力するHTMLの内容は違う。

「入札する」というのも画面処理のひとつだ。 金額を入力し、「入札」ボタンを押すと入札の記録がデータベースに書き込まれる。 「現在はあなたが最高額入札者です」と画面に表示されるようになる。 ついでに、すでに入札していた人に「ほかの人がさらに高値で入札したようですよ」というメールを発信する。

問題は、オークションが終了する場合だ。 Yahoo!オークションでは、希望価格に達したとかいう例外を除き、通常は、オークションの終了=終了時刻になったとき、である。

では、いったい誰が、「オークションの終了」という処理を行うのだろう? Yahooの担当者がじーっと時計を見ていて時間がきたらなんらかの画面上の「終了」ボタンを押すのだろうか? まさか(笑)。 そう、こうした処理は画面処理ではできないのだ。そこでバッチ処理の出番となる。

バッチ処理にもいろいろあるが、この例で言うとオークション終了バッチ処理が1分ごとに自動的に起動され、その時刻がオークション終了時刻として設定されているオークションをすべてピックアップし、終了処理を施す=画面から「入札する」ボタンを消し、 出品者と最高額落札者にそれぞれオークションの終了を知らせるメールを出す。

ひらたく言えば、「画面を見る」とか「画面のボタンを押す」といった人間の手による動作が必要なのが画面処理で、コンピュータ勝手に動き出してやりたいことを一気にやってくれる処理がバッチ処理と言える。 (バッチ処理であっても手作業で起動するケースももちろんあるが、たいていは自動起動である)

では昔のPHPはなぜこのバッチ処理ができなかった(やりづらかった)のだろうか? 続けて書いてしまおうと思ったのだが思ったより長くなってしまったので次回に続く。

いまおすすめの言語はPHP −Javaジャバ言ってる間にも(3)

予算や技術や要件についてそれぞれエキスパートが十分に考え抜いて 言語やツールを選択しているシステム開発プロジェクト−Web/非web問わず− というものはめったにない。

逆に、ことWebシステムの構築プロジェクトにおいて 開発言語にJavaを使う理由の9割以上は、そのプロジェクトにかかわる人々が 「とりあえず「ジャバ」という単語を口に出しておけば間違いはなかろう」 という強力な催眠術にかかっているケースだろう。

Webシステムの開発に限って言えば、開発言語として、いま、ベストな選択はPHPである。 以下、技術的な用語を極力避けつつ、その理由を述べたい。

「フォームに入力された内容をwebマスター宛にメールしたい」という要件があったとしよう。
PHPで書く場合:

<?php
    $subject="タイトル";
    $body   ="本文";
    mb_send_mail("hoge@example.com",$subject,$body);
?>
Javaで書く場合:
import javax.mail.Session;
import javax.mail.Message;
import javax.mail.Transport;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.InternetAddress;

public class sendmail {
    try {
      Session session = Session.getDefaultInstance(prop, null);
      MimeMessage mail = new MimeMessage(session);
      mail.setRecipients(Message.RecipientType.TO, 
          "hoge@example.com");
      mail.setHeader("Content-Type", "text/plain");
      mail.setSubject("タイトル", "iso-2022-jp");
      mail.setText(text, "iso-2022-jp");
      Transport.send(mail);
    }
    //ここでははかなり簡略して書いてる。
    //実際まったく不足だがとりあえず省略。
}    
もちろんJavaでのコーディング方法はもっと簡単な方法もある。しかしいずれにせよどう書いても、 手軽さ、学びやすさ、ぱっと見の理解しやすさにおいて、JavaはPHPに全く及ばない。 これが、筆者がJAVAではなくPHPをすすめる理由である。 素人でも学びやすく、書きやすい。もしも「Webデザインだけじゃ食ってけないし、 もっと複雑なことができる言語でも学ぼうかな」と思っているWebデザイナーがいたら、 迷わずPHPを学び始めることをおすすめする。

Javaが全面的によくないわけではまったくない。ハサミは使いようだ。 だが、それほど複雑な機能を必要としないWebサイト=おそらく世の中の8,9割がたのWebサイト= においてはJavaでつくるよりPHPのほうが早道である。つくりやすさだけで言うとperlという手もあるが、 perlによるWebシステムは実行速度の点で難がありすぎる。Apache+mod_perlという手もあるが、 そこまでやるならPHPで考え直したほうがよいだろう。

Javaを使えば、書いたコード=部品=の再利用性が向上するとか拡張性が向上するとかいう話もいろいろあるが、 ぶっちゃけ、部品を再利用し拡張することを考えるような事態になるときは、 結局Webサイト自体をすべて作り直すような結論に達することが多いので、 再利用性も拡張性もたいした意味をなさない。 繰り返すようだがそもそも世の中の8,9割がたのサイトは、Javaがもたらすコード再利用性や拡張性に頼らなければならないほど複雑巨大な機能をもたないし必要としていないのだ。

もちろん、PHPにできないこともJAVAならできるということもある。なぜなら、、PHPは完全にWebシステム開発専用の言語であるのに対し、JavaはWebシステム/Webサイト構築に限った言語ではないからだ。PHPはWebサーバ(Apacheなど)に寄生する形で稼動し、HTML言語に埋め込む形で書かれることを前提としている。だからこそPHPはWebシステム構築に用いる言語の選択肢としてJavaより有利な立場にある。

Yahoo!、オープンソースの PHP スクリプト言語に移行 (Japan.internet.com 2002/10)
まんまと催眠術にかかってJavaジャバ言ってる間にも、 Webの世界のリーダー達は、すでに、自分自身の選択眼でツールや言語を選んでいる。

See also:
Javaジャバ言ってる間にも (2003/12)
Javaジャバ言ってる間にも(2) (2004/3)
いまおすすめの言語はPHP −Javaジャバ言ってる間にも(3)(2004/5)
Javaジャバ言ってる間にも(4) − FriendSterはJavaからPHPに乗り換えていた(2004/9)
IBM、PHPの支持を表明 − Javaジャバ言ってる間にも(5)(2005/3)
「従来のEJBは存在自体が間違いだった」 - Javaジャバ言ってる間にも(6) (2005/6)
アマゾンはperlでできている - Javaジャバ言ってる間にも(7) (2005/7)