PHPの車輪はバカに出来ない。使うに留めず使いこなしてからが面白い。
スポンサード リンク
そろそろPHPに関して一言いっとくか
以下気になったところを抜粋
最近はAjaxの台頭で、かつてはサーバー側にやらせていたViewを、ブラウザー側にやらせる機会が増えてきた。PHPが「どこにでもある」かどうかは疑念の余地があるが、JavaScriptがどこにもあるのは疑念の余地がない。そして幸いなことに、JavaScriptは「新しい技を覚える」という喜びを味わえる言語でもある。そのことに皆が気づくのにだいぶ時間はかかったが、今ではみんな知っている。車輪の再発明があまりに多いのは頭痛の種だが、それでも車輪を再発明できるというのは、プログラマーの成長にとっては欠かせない特徴なのだ。
PHPにおいては、PHP「環境」に用意された車輪を使い続けるしかない。
だから、PHPに対して正しいスタンスは、「使うにとどめる」というものだと思う。「作る」までやりたかったら、他をあたるべきだろう。
こういう感じで言いくるめられました。
ですが【PHPの車輪はもっと別の意味をもつ】と言いたいのです。
単純にAjaxにしても、確かにその開発結果にはオリジナリティが如実にでますし、新しい喜びを感る事が出来る動きが見えます。
おおなるほどと納得。でもPHPの車輪は一言で言い表せない部分がまだまだありますので記事に残しておきます。
PHPは車のボディそのもの
弾さんが言っているように、PHPを使うならPHPを使う為の環境が必要です。
PHP言語を使う為には、サーバーにPHPをインストールしなければ使うことが出来ないのです。
さらにPHPのバージョンが違えば今まで使っていたプログラムが動かなくなると言うすさまじい存在です。
大規模なオブジェクト指向開発をしていると深刻な問題です。
詳しくはZAPA氏のブログで掲載されていました。
そろそろPHP5への移行に関して一言いっとくか
そして2007年5月3日時点でPHP 4.4.7 と PHP 5.2.2 がリリースされました。
これはつまりバージョンPHP4とPHP5の開発が同時に行われている事を意味しています。
当然サーバーサイドでは新しいPHP5を入れたくても、その配下でPHPを作っているユーザーがいれば簡単にバージョンアップなんて出来ません。
私の環境はPHP4ですが、これを突然5にされた日には泣きます。
それが車という意味になっています。
自動車だって、メーカーが変われば車輪も変えなければいけない。
PHPのバージョンアップとはそういう意味で極悪です。
ところが各ギアに関してはそうそう深刻な問題でもありません。
これからオブジェクト指向開発をはじめるよという方であれば、PHP5の方が開発しやすいのではと思っています。
誰がどんなブラウザでやってきても同じ車に乗せる
こんなことを声を大にして言うものでもありませんが、PHPとJavaScriptの抜本的違いはここです。
どんなブラウザでやってきてもPHPは同じ返事を返します。
サーバー側に完成された車が用意されている為です。
一方、JavaScriptはブラウザに依存します。
いまやGoogleの影響でJavaScriptをオフにしている人はあまり居ないかもしれない。
また、パソコン自体が、インターネットを楽しむだけに購入する人が増加した影響で、JavaScriptのオンオフの存在すら知らない人が多い。
だからといってブラウザが違えば動かなかったり、オフにされると機能しないプログラムというのがJavaScriptです。
今はどうかはわかりませんが、一昔前はこれこそがJavaScriptを使わなかった理由です。
車輪の働き
では車輪の意味はいったいなんなのでしょうか。
PHPの車輪とは、私が思うにPEARモジュールではないかと思っています。
ボディが同じであれば、その上で動作するプログラムも必然的に【同じような】構造になります。
そういった同じような車輪をPHPではPEARモジュールとして無数に公開されています。
例えばservice_YouTubeというPEARモジュールを使うと、YouTubeAPIを活用して驚くほど簡単に動画サイトが作れます。
指定したタグがついているすべての画像の一覧表示をいうのをservice_YouTubeを使うと以下の様な文で構築できます。
require_once 'Services/YouTube.php';
$dev_id = "YOUR_DEV_ID";//ユーチューブ開発者用コード
$tag = "girl";//タグ
$youtube = new Services_YouTube($dev_id, array('usesCache' => true));
$videos = $youtube->listByTag($tag);
foreach ($videos->xpath('//video') as $i => $video) {
print "<img src='{$video->thumbnail_url}' alt='{$video->title}' />\n";
print "<a href='{$video->url}'>URL</a><br />\n";
}
XMLの解析にしても車輪が用意されている。
require'XML/Unserializer.php';
$base = "http://vision.ameba.jp/api/get/search/privateMovie.do";
$xmldoc = join("",file($base));
$opt = array(
'complexType' => 'array',
'parseAttributes' => 'true',
'attributesArray' => '_attributes',
);
$xml = new XML_Unserializer($opt);
$xml->unserialize($xmldoc, false);
$data = $xml->getUnserializedData();
print_r ($data);
勉強の為に各パーツをくみ上げ、自力でXMLの解析をしていましたが、こういう車輪の力は確実に開発時間の短縮に繋がります。
他にも他のサイトの情報を簡単に抜き出すものや、Amazonのサービスを簡単に構築できるものまで様々ある。
これはWEBプログラマとしては短期間でserviceを作り上げ、公開し、使ってもらえるという点では一つの喜びに繋がります。
PEARの魅力はサーバー動作にある
GDライブラリです。
これは画像の圧縮などをサーバー側でやってくれたり、回転させたりと言う動作をさせる事が出来る優れもの。
大きな画像をアップロードしたと同時にリサイズしたりという機能はサーバー依存の力ではないかと思います。
JavaScriptを使わないAJax
本当にJavaScriptを使わないと言うわけではないけど、殆ど書かないでAjax機能を提供する事ができるPEARもちゃんとある。
PHPでAjax! JavaScript不要のxajaxや、HTML_AJAXなどが良い例です。
完成された大規模オープンソースの多くはPHPで書かれている
これを車輪と呼んでよいのかが難しいところ。
PHPで動いている高度なオープンソースWebアプリケーション15選でも紹介しましたが、PHPオープンソースアプリケーションの特徴は、比較的簡単に導入ができ、次の日からでも大規模コミニティサイトをオープンしたり、ESサイトをオープンさせる事が出来るものが多くそろっています。
こういうPHPで書かれたオープンソースが多い中、PHPを理解していると言う点では非常に優位なことです。
多少のバグがあろうと自分で修正できるわけですし、ちょっとした機能を追加したり出来るからです。
車輪の転がし方がポイント
弾さんが指摘するとおり、実際完成された車輪ばかり転がしていると、プログラムから遠ざかっていく事に間違いは無いと言えます。
ただ、弾さんがいう『使うにとどめる』で終わってしまうという意味がこれをさしているのではないかと。
PHPに対して正しいスタンスは、「使うにとどめる」というものだと思う。「作る」までやりたかったら、他をあたるべきだろう。
車輪の多さはこれまで述べてきた事に尽きます。
『作る』と言う意味合いは、プログラムを組むという点からすこしはずれ、WEBサイトを作ると言う点で考える方がPHPプログラマは自然です。
なぜなら、私が知っている限り、尊敬するPHPプログラマの方々は、車輪を『使いこなしている』からです。
まぁ突き詰めると、WEBプログラマーの喜びがどこにあるのかという点がポイントとなりますが、個人的にWEBアプリケーションが動作し、誰かに使ってもらえる事が私の喜びです。
さんざん出来合いの車輪の話をしてきましたが、各企業の為だけの、ブラウザベースの見積もりシステムや、グループウェアなど、一から依頼されたとおりのプログラムを作り上げ、使ってもらえるもの楽しいです。
結論
私なりのPHPに対する正しいスタンスは、『使う』、だけでは終わらないで、『使いこなす』ことこそが、PHPの味が出てきておもしろいので、是非使いこなして欲しい
です。
新ブログ:ITクオリティもよろしく。
スポンサード リンク
![]() |
![]() |
![]() |

» Photoshopちょいテク『惑星を作ってみよう』+360度パノラマ画像も作れるように
» 最近、ブログを書いている途中に筆が止まる理由がわかった気がする
» ブログエントリ別に見る『注目度10の法則』
» 天才という言葉は、生きている人にいう言葉じゃない気がする
» まるでphotoshop!JavaScriptで実装するクールなカラーピッカー[prototype.js]
» 今後の期待度が高いphotoshopブラシまとめサイト『Quality Brushes for Photoshop』
» FLASHサイト作成インスピレーションの参考になるflashサイト7つ
» あの時、何気なく吸い始めた一本のタバコの値段が900万だと知ったとき
» jQueryサンプル公開後の反省会。みなさんからのアドバイスを5本サンプル化
» [追記]数百件先の画像まで一気に検索してしまうインターフェイスを搭載したfirefoxアドオン
» プロとアマの違いってぶっちゃけたったひとつ
» 一晩で覚えるjQueryの逆引き基礎サンプル7つ
» あなたは大丈夫?知らず知らずのうちに感じている10のパソコンストレス
» よごれた感じのフォトショップチュートリアルとブラシ
» 第2回web開発者インタビュー。マチウケメール便開発者『開発環境はeclipseです!』
Comment
何が問題って、読解力だよね。
いや、PEARの「貧弱さ」こそがPHPの弱さを象徴している
CPANに収録されているライブラリの数とPEAR/PECLに収録されているライブラリの数を比較すると、悲しいくらいにPEAR/PECLのライブラリ数は少ない。しかも完成度においてもPEAR/PECLのライブラリたちはCPANのそれに及ばないのです。それは、PHP自体の言語としての「自己拡張能力」の貧弱さから来ているのです。
たとえば、C言語は言語そのものには大した機能はなく、実用的な機能のほとんどはC言語自身で書かれたライブラリで実現されています。
言語仕様をコンパクトにして、機能はライブラリで実現する、という方針は言語開発者に大きなメリットをもたらします。
言語仕様がコンパクトであれば、処理系をバージョンアップする際、動作確認しなければならない範囲もコンパクトになります。したがって言語仕様を変更せずに、最適化やセキュリティホールへの対応のための処理系のバージョンアップを「安全」に行いやすくなります。(言語仕様は言語処理系とライブラリのI/Fなので、言語仕様が変わらなければライブラリも変更を求められない可能性が高い。)
ところがPHPはそうではありません。PHPに標準で提供されている関数群は、必ずしもPHP自身で実装することができません。たとえばmysql_connect()関数をどう思いますか。mysql_connect()関数の戻り値はPHP的に特殊な値であり、まったく別のMySQL処理関数群を作ることは可能でも、mysql_connect()そのものをPHP自身で書くことはできないのです。つまり、この関数はPHPの言語仕様に「組み込まれて」しまっています。
debug_backtrace()関数も同様です。これがないためにどれだけ苦労したか。こういう関数も、PHP5以前では、PHP自身では書くことができませんでした。こういう関数を後から書けるような言語仕様にしてくれれば、あとからライブラリ関数として書けばいいのです。
Javaは巨大なクラスライブラリを持っていますが、PHPほど言語仕様が無意味に大きくはありません。PHPの欠点は、ライブラリとして持つべき機能が、言語仕様に組み込まれ過ぎているということに尽きます。ある機能が必要になったとき、PHPの開発者たちは言語仕様を拡張してその機能をライブラリとして書けるようにする道を選ばず、直接その機能を言語そのものに組み込んでしまったのです。
PHPが下位互換性を犠牲にしてきたのは、言語仕様の設計ミスからくる、不可抗力です。言語仕様が大きすぎるので、厳密な検証ができないのです。実際、細かい挙動の違いがセキュリティアップデートの際にも生じてきました。(もう詳細はおぼえていませんが、4.3.0と4.3.1と4.3.2の違いに苦しんだことが僕にはあります。)
すると、PEAR/PECLにクラスライブラリを提供したくても、PHPのバージョンアップ時に、各バージョンで動作できるように保守しなければならないという懸念が生じざるを得ません。PHPの場合、configureのオプションやphp.iniの設定によって動作を変えられる部分も多く、ポータブルなクラスライブラリを書くことはかなり骨が折れます。
PEAR/PECLに提供されるクラスライブラリが少なく、また機能的にも素朴なものが多いのはここに原因があると僕は思います。
PHP5は、PHP4よりはるかに表現力に富んでいるので、PHP7かPHP8か、いずれかのタイミングで、言語仕様をコンパクトにし、機能のほとんどをライブラリ側に移せるかもしれません。そうなれば、PEAR/PECLも充実してくると思います。












404の話はPHPがつかえないって話じゃなくて、ださいって話だよね。