Web屋のネタ帳 |
Ｗｅｂビジネスに必要な「戦略」「システム」「デザイン」の３要素とそれらをまとめる「マネジメント」について現場の実感と独自の観点でお送りするコラム・・・のはずなんですが、要するにＷｅｂがらみのシステム＆デザイン業界に関する小ネタとツッコミの雑記です。
eNatural.orgさんの
[eN] Yahoo! Japan、検索エンジン切り替えへで知って驚いた。Yahoo Japanのページ検索がgoogleではなくなっているようだ。 Yahooが世界規模でいろんな検索技術を買収しまくってできあがったYST（YahooSearchTechnology)に切り替わっているらしい。 確かに同じキーワードで検索してもgoogleとは結果が違う。 日本ではもうしばらくgoogleからのライセンス提供を使い続けると思っていたのでちょっと驚き。
SEOを考えている人たち、SEOでご飯食べてる人たちにとっては大騒ぎになるのでは。
See also: ケイコとマナブに見る苦悩の検索エンジン対策
2004年5月31日
| Permalink
|
Comments [0]
|
Trackbacks [3]
手軽で便利なツールだが、それゆえに限界もある、ということで…… おそらく多くの人がこやつには喜ばせてもらっているのと同じくらい悩まされているかと思う(^^; 私はけっこう好きなんだけども、これのせいで一時期胃に穴があきそうになりまいた。そういえばず〜〜いぶん昔に必要に迫られてＡｃｃｅｓｓ単独でのアプリをつくったことが何回かあった。 小さなものだったしそんな長いこと継続利用されるほどのものでもなかったので、 つれづれネット散歩さんの話のようなカベにぶちあたる前に筆者の手元を離れてくれたのがコレ幸い。
MS Accessの限界
(つれづれネット散歩 2004/5 より)
いま筆者のもとではOracleやらPostgreSQLやらでつくったDBサーバに対し ローカルPCから簡単にアクセスする手段としてMS Accessが活躍している。 つまりAccess自身のDBエンジンは使わずに、外部のDBに対するインターフェースとしてのみ使う、ということ。 本格的なアプリにする場合にはもちろんAccessなんて使わずにWebなりVBなりでインターフェース部分をつくるけど。（VBももう最近使わないか）
実際、とにかくDBの内容をエクセルみたいな表形式で見せてくれ、といった程度の要件なら DBがなんであれそのインターフェースにAccessを使うことでかなり簡単に実現できるだろう。 もちろんエクセルでもできるけど。いや、むしろエクセルのほうが簡単なのか？うーん。 （あまりVBA詳しくないんで＾＾；）
とにかく、ハサミは使いようだ。
2004年5月28日
| Permalink
|
Comments [2]
|
Trackbacks [0]
エプソン，用紙幅に収まるようにWebページを印刷するツールを無償公開プリンターメーカーによるこうした行動は、プリンター購入者からの 「印刷したら右端が切れちゃうんだけどおたくのプリンタはどうなってるの一体？」 のような電話の数が無視できないほど多いということの裏返しとも言える。
(ITPro 2004/5)
そういったことをWebサイト側が自覚している場合であっても、だからといって必要以上にWebページの横幅を抑制しすぎると、 www.honda.co.jpのように「なんでこんなきゅうくつそうに左側にまとまっているんだろう？」みたいなことになる。
「Webデザインのせいじゃない。プリンタのせいでもない。ブラウザの印刷機能が貧弱すぎるのが悪いんだ。文句はマイクロソフトに言おうぜ。」 という話もあるが、そんなグチっぽく責任転嫁したところでお客様の問題解決にはならない。
See also:
2004年5月27日
| Permalink
|
Comments [0]
|
Trackbacks [0]
Javascriptを使ってツールバーやアドレスバーを表示しないようにしているページは多い。 しかもよりによって地図のページでだ。
話を続ける前に用語説明。
以下は、どんな企業のサイトにもたいていあるであろう、「弊社への地図」のページの例だ。
中外製薬の事業所地図のページ「ＭＡＰ」という画像をクリックすると、それぞれ地図が小さな別ウィンドウで表示される。
さて、ここでいくつか想像していただきたい。
「取引先が来社する。駅からここまでの地図のURLをメールしてあげておいてくれ。」あなたはズバリなURLをメールで伝えることができるか？ （ワンクリックでできてナンボの世界ということをお忘れなく）
「打ち合わせに行くけど、初めて行くから場所がわからない。地図をプリントアウトしてくれ」あなたは地図をプリントアウトできるか？
ご理解いただけるだろうか？
画面上で右クリックすればメニューに「印刷」が出るからそれを使えばいいし、 「プロパティ」を見ればURLもわかるでしょう。はたしてそれで初心者に優しいページと言えるか。 少なくとも筆者はクライアントにそんなことを話す勇気はない。
アドレスバーを隠すことはもっと深刻なセキュリティ問題を引き起こす。 とりあえずそれについては、産業技術総合研究所の高木氏のレポート にリンクを張っておくことにしよう。 なお、このレポートを見た銀行各社のインターネットバンキング担当者はあわてて 自社サイトのアドレスバーをちゃんと表示するように仕様変更したといういわくつき。
2004年5月26日
| Permalink
|
Comments [0]
|
Trackbacks [1]
ホットデプロイメントは本当にホットなのか?やっぱりそういうことなんだよね。 本番環境（クライアントに納品して稼動中の環境）でＡＰの変更があったときは、 まるっきり再起動させなきゃならないと。日中は利用者が多いからできないと。 つまり徹夜しろと・・・。
(Izu@San Diego 2004/5)
似たような話：Javaジャバ言ってる間にも（その２）
ところで、Apacheにgraceful restartはあってもgraceful stopが無いのが惜しい。 もしもこれがあったら、たとえばPHPなんかで書いたアプリを入れ替えるときであっても、 graceful stop → PHPスクリプト入れ替え → start の順でやることでいつでも、ほんの数秒で、しかも安全に、アプリの入れ替えができるのに。（わかる人しかわからない話になってしまった。）
2004年5月25日
| Permalink
|
Comments [3]
|
Trackbacks [0]
フレームは使うべきでないことは以前書いたとおりだ。 それでもフレームを捨てられないという理由の過半数は 以下のようなことだろう。
下のようなフレーム構成のページがあるとする。
これはPHPを使うと以下のような二つのファイルによって構成することができる。
(menu.phpとする)
<a href=content1.php>コンテンツその１へ</a><br> <a href=content2.php>コンテンツその２へ</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>
PHP言語の include 命令は呼んで字のごとく「含めろ」という意味。 たったこれひとつを覚えるだけのことだ。 「プログラミングなんて無理」といわず、未経験のデザイナーさんでも挑戦してほしい。
ついでに、必ずぶちあたるであろう疑問や問題のいくつかについて以下に述べておく。
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される。
2004年5月24日
| Permalink
|
Comments [11]
|
Trackbacks [9]
国税庁システム、発注方式見直し 開発費膨れて３千億円300億円の予定が5年遅れで3000億円というのもあきれたが、もっと驚いたのが、
(asahi.com 2004/5)
もうね、アホか！と。 この国は狂っている。
2004年5月21日
| Permalink
|
Comments [0]
|
Trackbacks [1]
政治/社会的な話をするのはこのblogのテーマとやや離れるのでナンなのだが、 それでもやっぱりなんかヘンだと思う今日この頃。
不正アクセスの元研究員に流出の監視要求 著作権協会 - asahi.com : 社会不正アクセス？ まあ素人目にはなんでも「不正な」「アクセス」になってしまうだろうが、 技術的な観点から見れば、 このケースは「ACCSという家屋のなかのコルクボードかなにかに名簿が張ってあって それが家の窓から見える位置で、強力な双眼鏡で外から窓をのぞけば見えるような状態だった」 と言えるのではないだろうか。むろんそれを見て伏字もせずに（つまりwatanabeさんを○○さんに塗りつぶしもせずに）第三者に見せびらかした奴も奴だが、ACCSも責任転嫁しすぎやしませんか？
Winnyの作者を逮捕した京都府警も、ソフト作っただけでタイホ？ そんなことやったら世の中のプログラマーはみなタイホだ。勇み足と感じざるを得ない。
なんでもシステム化されつつあるこの世の中。しかし ＩＴ技術に関する正しい知識(?)が、圧倒的に不足している気がする。
2004年5月21日
| Permalink
|
Comments [0]
|
Trackbacks [0]
みずほインベスターズ証券を例にしよう。
ユーザーが、みずほ証券に対し次のような質問をメールで送ってきたとする。
「株の売買にかかる手数料はいくらですか？」これに対し「資料を送りますのでご住所を・・・」では模範解答とは言えない。 メールで問い合わせてきたお客様にはメールで返すべきだ。 だからといって売買手数料体系を長々と文章で書く暇はないし、お客様もそんなことは望んでいない。 手数料体系が書いてあるWebページのURLをメールで伝えるというのが回答としてべストだろう。
ということで、まず売買手数料について書かれたページを探してみよう。
さて、あとはこのページのURLをメールでお客様に伝えるだけだ。 いつもやっているように、アドレスバーからURLをコピーする。
そしてメールに貼り付けて送信！ たとえば本文は以下のような感じになるだろう。
さて、上のURLを実際にクリックしてほしい。(※） その結果に、お客様は満足するだろうか？○○様 お問い合わせ誠にありがとうございます。 弊社の売買手数料についてわかりやすい詳細が以下にございますので ぜひご覧いただければと思います。 http://www.mizuho-isec.co.jp/MJ/index .jsp?url=%2FMJ%2FMember%2FCategory%2FnodeName.jsp%3Fname%3DQA
いったいどうしたらよいのだろう？このＵＲＬを書けばいいのか？
http://www.mizuho-isec.co.jp/MJ/Member/Category/nodeName.jsp?name=ITAKU_TESURYOいや、あってるが・・・見え方がなんかヘンだ。どうやってトップページに戻るんだこれ？(笑) 見え方も含めてこっちが意図したページそのものを示すURLを提示できないとなると、
http://www.mizuho-isec.co.jp/ にアクセスしていただき、 左側のメニューから「Ｑ＆Ａ」を選んでさらに 「サービスに関するＱ＆Ａ」をクリックし、 その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で解決できるようにならないか？ というのはあらゆる企業に共通する要求だ。
わかりやすく言うと、消費者金融のプロミスのテレビＣＭのように、 井上和香みたいな（？）お姉さんをいっぱいそろえた電話サポート業務センター （＝コールセンター）は構築と維持にものすごい金がかかるので、 これを2634.jpのようなWebサイトで 情報提供することでコールセンターにかかってくる電話の数を少しでも減らしてコスト削減したい、 ということである。
が、ちょっとフレームを使っただけで、その目論見の達成度は急減する。
もしも、フレームを使っているサイトを見つけたら、 トップページ以外の特定のページに行き、 そのページのURLをブラウザのアドレスバーからコピーし、 自分のお客様や友人に「ここをご覧ください」と伝えるようなつもりで 自分宛に（あるいは実際に友人に）メールしてみよう。 そして翌日、そのメールを見て、書いてあるURLをクリックしてみてほしい。 前日に自分が意図したページを一発で見ることができるだろうか？ もしできなければ、そのサイトはWebサイトとして大きな欠陥を抱えている といわざるを得ない。
フレームの弊害についてはもう何年も前から言われていることだ。 「フレームの弊害」といったキーワードでGoogleで検索するといくらでもでてくる。 しかし、こうした認識が薄いWebマスターやデザイナーが未だにいる。 （ほんとうに、驚いてしまう・・・。）
Yahooやアマゾンではフレームをほとんど使っていない。 使わない理由があるから使っていないのだ、 ということを学び取ることは、そんなにも難しいことだろうか？
See also:
フレームの代わりにPHPを使う
特定のコンテンツ≒特定のURLという前提が崩れるとき - 後悔しないためのWebデザイン
2004年5月20日
| Permalink
|
Comments [0]
|
Trackbacks [2]
メールの題名とFromは既に戦場という記事で既に述べたように、メールマガジンの題名とFromの書き方は、 メールの開封率を上げる上で非常に重要だ。
最近、とある有名なECショップの出すメルマガの題名にちょっとした工夫を見つけたので紹介しよう。
お分かりいただけるだろうか？ 題名の頭に全角空白をひとついれているのである。
ユーザーのメールソフト上で少しでも目立とう、という涙ぐましい努力と言える。しかし裏返すとそれは、（そのECサイトに限らず）メルマガの題名、From、本文の内容や送信タイミングなどのノウハウの発達が枯渇しかけている気がしてならない。 早い話が、もう工夫しつくしてしまって他に手段がなくなってきたためこうした視覚的トリックにたよらざるをえなくなってきた、ということだ。
メールを、新聞の折り込みチラシなどと同種の宣伝媒体としてしかとらえない場合、 そのノウハウの枯渇がすぐにやってくるだろうことは想像に難くない。 そうしたなかで、そろそろメールならではのマーケティング力を考えるべきだろうという以下のコラムに同意。
メールマーケティングの効かせ方
(japan.internet.com 2004/5)
2004年5月18日
| Permalink
|
Comments [0]
|
Trackbacks [0]
楽天がWebサイト高速化ツールZend Performance Suiteを導入あくまで未確認情報だが、たとえば楽天広場などはPHPで構築されているはず。 ほかのサービスでも多々使われていると思われる。
(IT Pro 2004/5)
参考：
＠IT：楽天とオープンソース、その密接な関係
（アットマークIT 2003/11）
2004年5月17日
| Permalink
|
Comments [0]
|
Trackbacks [0]
いよいよでてきたという感じ。
日立、企業向けの Blog サービスを開始参考記事：
(Japan.internet.com 2004.5)
2004年5月14日
| Permalink
|
Comments [0]
|
Trackbacks [1]
＜三菱自＞米リップルウッドが出資の可能性もだそうで（タイヤ脱落事件の三菱ふそうではなく三菱自動車）。ちなみに過去には
(Yahoo ニュース 毎日新聞 より 2004/5）
新生銀行再上場、リップルウッドは高笑いなんて話もあったりする。
（unique_critique 2004/2）
「ハゲタカめ！」などと負け惜しみを言うじいさまは多いが、 個人的には、リップルウッドが悪いとかハゲタカだとかは少しも思わない。 やはり、買収される側がもともと愚かなことをやらかしまくっているだけじゃないだろうか。
2004年5月13日
| Permalink
|
Comments [0]
|
Trackbacks [1]
「スノーブランドを守りたかった」
「スリーダイヤに傷がつくと思った」
おごるじじいの言い訳はいつもおなじ。
2004年5月13日
| Permalink
|
Comments [0]
|
Trackbacks [0]
(前回からの続き） では昔の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はそれをユーザーのブラウザに返す。 |
さて、わざわざ、PHPの動作原理などと難しい話をしたのにはもちろん理由がある。
前回、Webシステムの機能は画面処理とバッチ処理の 大きく二つにわかれるということを述べた。当然、PHP言語で書かれた画面処理は、 上で述べたようなApacheに追加されるmod_php4モジュールがそれを実行してくれる。 しかしバッチ処理はどうだろう？
画面を見る（ブラウザでアクセスする）or画面上のボタンを押す ＝ Apacheがそれを受け取って処理してくれるというわけだが、画面を見るわけでもボタンを押すわけでもないバッチ処理において、 Apacheはどう対処するのか？どうしようもないのだ！ Apacheは、ブラウザからのなんらかのアクセスがないと何もできない。 不思議なことではない。一般にWebサーバーとはそういうものだ。 そのため、Apacheに依存する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開発コミュニティの皆さんに敬意を表したい。
2004年5月12日
| Permalink
|
Comments [0]
|
Trackbacks [0]
ほんの1年か2年くらい前まで、PHP言語には致命的な弱点があった。 バッチ処理ができなかったのだ。 いや、できなかったというと語弊があるので正確に言うと、 昔のPHPでバッチ処理をするような機能をつくるのにはかなりコツがいり、 場合によっては非常に難しかった。
掲示板のようにごく簡単なWebシステムであればバッチ処理の必要がない （あるいは運用でなんとかなる程度）ため、この問題を意識することはないのだが、 ちょっと複雑なWebシステムを作ろうとすると頭を悩ませることになる。
先に言っておくと、現在のバージョンのPHPはバッチ処理もできるようになっているので安心してほしい。 以下、Webシステムにおける画面処理とバッチ処理の違いや、 Webサーバそのものの構造とPHP言語との関連について極力わかりやすく書いておきたい。 わかりやすくとはいっても内容が内容なのでどこまでわかりやすいかは自信無いが。
比較的複雑なWebシステムとして代表的な、オークションサイト＝たとえばYahoo!オークションとか＝を例にしながら説明してゆこう。
Webシステムの機能には大きく分けて画面処理とバッチ処理がある。 バッチ処理は日本語で書くと「一括処理」という意味あいだ。 オークションサイトで言えば、まず、それぞれの出品物の画面を表示することそのものが画面処理である。URLに含まれた「a1234567」といったオークション番号をもとに、データベース（あるいはそのキャッシュ）から該当する出品物の情報を引き出し、HTMLに整え、ブラウザに返す。 その人がログインしているかしていないか、出品者か入札者かどちらでもない人か、によっても出力するHTMLの内容は違う。
「入札する」というのも画面処理のひとつだ。 金額を入力し、「入札」ボタンを押すと入札の記録がデータベースに書き込まれる。 「現在はあなたが最高額入札者です」と画面に表示されるようになる。 ついでに、すでに入札していた人に「ほかの人がさらに高値で入札したようですよ」というメールを発信する。
問題は、オークションが終了する場合だ。 Yahoo!オークションでは、希望価格に達したとかいう例外を除き、通常は、オークションの終了＝終了時刻になったとき、である。
では、いったい誰が、「オークションの終了」という処理を行うのだろう？ Yahooの担当者がじーっと時計を見ていて時間がきたらなんらかの画面上の「終了」ボタンを押すのだろうか？ まさか(笑)。 そう、こうした処理は画面処理ではできないのだ。そこでバッチ処理の出番となる。
バッチ処理にもいろいろあるが、この例で言うとオークション終了バッチ処理が1分ごとに自動的に起動され、その時刻がオークション終了時刻として設定されているオークションをすべてピックアップし、終了処理を施す＝画面から「入札する」ボタンを消し、 出品者と最高額落札者にそれぞれオークションの終了を知らせるメールを出す。
ひらたく言えば、「画面を見る」とか「画面のボタンを押す」といった人間の手による動作が必要なのが画面処理で、コンピュータ勝手に動き出してやりたいことを一気にやってくれる処理がバッチ処理と言える。 （バッチ処理であっても手作業で起動するケースももちろんあるが、たいていは自動起動である）
では昔のPHPはなぜこのバッチ処理ができなかった（やりづらかった）のだろうか？ 続けて書いてしまおうと思ったのだが思ったより長くなってしまったので次回に続く。
2004年5月11日
| Permalink
|
Comments [0]
|
Trackbacks [0]
予算や技術や要件についてそれぞれエキスパートが十分に考え抜いて 言語やツールを選択しているシステム開発プロジェクト−Web/非web問わず− というものはめったにない。
逆に、ことWebシステムの構築プロジェクトにおいて 開発言語にJavaを使う理由の9割以上は、そのプロジェクトにかかわる人々が 「とりあえず「ジャバ」という単語を口に出しておけば間違いはなかろう」 という強力な催眠術にかかっているケースだろう。
Webシステムの開発に限って言えば、開発言語として、いま、ベストな選択はPHPである。 以下、技術的な用語を極力避けつつ、その理由を述べたい。
「フォームに入力された内容をwebマスター宛にメールしたい」という要件があったとしよう。
PHPで書く場合：
<?php
$subject="タイトル";
$body ="本文";
mb_send_mail("hoge@example.com",$subject,$body);
?>
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が全面的によくないわけではまったくない。ハサミは使いようだ。 だが、それほど複雑な機能を必要としない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)
2004年5月10日
| Permalink
|
Comments [23]
|
Trackbacks [1]
