PEARに関して復習してます

manamanmana2006-02-24

最近うちの会社では新しい体制に向かっていて、それに伴い、新しいサービスとか新しい改善を行おうとしています。
ということで、俺の方でも自分のシステム環境とか開発環境やテクノロジーの採用に関していろいろ見直し調査をしています。


ASP.NETに関して調べたのもそのためですし(結局採用する価値まで至らなかったけど)、サーバシステム構成のスケールアウトに関して何パターンか作ってみたり(はてなのDBサーバの持ち方なんか参考になりました)、MySQLの4.1〜5.0以上に関して調べ直したりしてます(特にローケール周りの変更とか)。


やはりMySQL DBMS周りが一番のシステムの肝なんですが、今日はPHP周りに関しても色々と復習しました。
特にPEAR関係に関しては今まであまり積極的に調べてこなかったので、この機会に整理しようと言う感じです。
PEAR周りで悩ましいのが、それを採用するに足る物なのかに関して判断しなければならないという事です。
やはり、何でもかんでもPEARを採用すれば良いというものではありません。
本来こういったライブラリ類は、複雑なロジックや低レベルの処理を隠蔽する事により、より簡単なインターフェイスを提供する事で、求める機能を楽にかつ確実に実現する事だと思います。
なので、例えばあまり使い勝手の良くないインターフェイスのライブラリだとか、複雑なAPIを学習しなければならないような、あまり直感的でないPEARライブラリに関してはあまり採用するに値しないという事です。
わざわざPEARを使わなくても、べたなPHPプログラミングで足りることもままあります。
要は道具は使いようなので、そのライブラリという道具が実現できる範囲とか、実現できるケースやそのケースが外れたときの自由度、使いやすさというものが大切な訳です。


俺にかぎっていうと、DB抽象化のライブラリはあまり使っていない。
DBMSMySQL一本やりなので、PEARライブラリによるパフォーマンスの低下よりは、よりMyQLの機能をストレートに出したいというところです。
つまり抽象化による、他DBへの変更可用性をそう重点におく必要は無いというところなのです。
でも、PHP5.1以降のPDOにかんしては、使うべきとき(PHPのバージョンアップ)には使おうと思っています。
特にSQLインジェクション対策やパフォーマンス向上のための、PrepareStatementやプレイスホルダ的な部分というのは重要になってくると思います。


その他としては、MAIL関連とかMAIL_Mime関連なんかは結構便利かと思いますが、これに関してもごりごり書いてかけない事はありません。
POP3FTP等のネットワークの隠蔽化ライブラリ関係は実際にごりごり書こうと思えばかけない事も無いので、あまり緊急な必要性は感じません。


HTML_Quickform関連もいまいちピンとこないんだよな。
まあ、自分にとっては覚える事はシンプルで、それを応用拡張して考える事でソリューションできるという体制が一番すきなので、こういったライブラリ関係はよほど省力化ができない限り、使用するときのインターフェイスが良く出来ていて使いやすくないと使う気になりませんね。


こういった事をコードを書きながらいろいろ考えてプログラミングしていると、プログラムを書く手がとまってしまって良くありません。
なので、ある程度まとまったときに、自分にとってのこういった道具使用の指針に関して整理しておく事が、実際にプログラミングに入ったときに、一心不乱にプログラミング出来るという利点があります。


あと、こういったライブラリ関係を新規に採用するときに問題なのは、それがオープンソースである限り当然自己責任で使用するので、事前にそのライブラリが信用するに値するかを調べてからで無いと、結構怖くて使用できないということもあります。
今日もNet_UserAgent_MobileというライブラリをPEARサイトで見つけて、これはっ、と思ったのですが、実際に本番に使用するとなると、やはり気軽にという訳には行きません。
結局コードの中身をみて、どういう判断や分岐をしているのかに関して調べる事になります。
この時間も馬鹿にはなりません。


こういった事は他のフレームワーク類等にも言える事で、Mojavi関連なんかも興味ありますが、こういうのもじっくり調べて吟味しないとです。
なるべくならば、PEARでもフレームワークでも、なるべく使用例の多くて実績の多い物に落ち着く事になるんでしょうが。
PEARに関してはいわゆる「標準ライブラリ」と言われるライブラリ群に関しては大丈夫だと思いますが。
結構PEARのサイトをみると、いろんな物が増えているみたいで、こういった無名的な物を使うときには吟味する時間が必要ですね。


結局は時間の問題で、本来、僕がこういった吟味をして提案する立場なのですが、自分も実稼働でコーディングしてプロジェクトを進めて行かないと行けないんで、なかなかそういった時間が取れない事が結構フラストレーションになります。


週末は引き続き、MySQLの4.1以降、特に5以降に関してじっくり調べる。
週明けは実プロジェクトを進めながら、PEARMojaviなんかを自社に取り入れる可能性に関して調査を続けたいと思います。