駒形電産

PicoContainer – Home

PicoContainer is a lightweight embeddable container for components that honour Dependency Injection. Want more? See One minute description, Two minute tutorial, and Five minute introduction.

最近うちの会社でもDIコンテナが流行ってます。席の周りはみんなJava(おれはPHP)なのでやれSeasar2だSpringだPOJOだ言ってます。

「AOPを仕事に取り入れたいけどAspectJは糞面倒臭そう。ダイコン・・・これならいけるかも!?」 って感じで広まってるんでしょうか。 Javaのスクリプト言語Groovyで有名なcodehausのプロジェクトPicoContainer。ピコっつーぐらいだから小さくて簡単なんでしょうな。Dependency Injectionの考えは言語に依存しないのでこのPicoContainerもJava以外に.NETやRubyのなんかも。でもPHPは対応してないんですな。PHPの欄に「watch this space!」の記述。誰か作れってこと?

Mojavi関連で有名なトイレの落書きにもDI関連の記述が。PHPも5になったからっつってEJBみたいな重厚なもんじゃなくてPOPOとでもいうべきクラスを外からいろいろする方向なんでしょうか。

PHP関西セミナー行ってきました。さすがに大阪日帰りは疲れた・・・。

内容の方はDB_DataObjectと大規模PHPとQuickFormって感じでした。それぞれに自分の中でタイムリーな話がいっぱいあって勉強になりました。

あとはPHP関西のXOOPSに講師の方々のリンクとか資料があるとうれしい。(会社からセミナーの内容をフィードバックせよと言われてる・・・)

みなさん、普通の人はUMLモデリングツールに何を使っているんでしょうか。 とくにPHPの人は・・・??? PHPに対応したツールってほとんど見当たらないので本当に謎です。マジで! 会社ではVisio2000に PHP データ型 とか勝手に作って書いてます。 開発標準化にあたってツール類も探しているんですが、フリーの(オープンソースでなくてもいい)UMLモデリングツールってなかなかコレ!ってのが無いです。PHPに関してはラウンドトリップなんかはあきらめてるんですが、QtベースのUmbrelloというオープンソースのUMLモデリングツールがPHPに対応しているというので試してみました。(これのためだけにsargeインストール・・・)

umbrello_1.png見ての通りUMLモデリングツールとしては普通っぽいUIなのでVisioからすんなり入れました。本気でこれに移行しようとかいうんじゃないんで「おー良くできとる」っていう感じです。

適当なクラス図を描いて早速、クラス図からソースを吐いてみました。(ソースからの読み込みはできないみたいです。)

request.php

/**
 * class Request
 * 
 */
class Request
{

    /** Aggregations: */

    /** Compositions: */

    /*** Attributes: ***/

    /**
     * 
     *
     * @param string name 
     * @return string
     * @access public
     */
    function get( $name )
    {

    } // end of member function get

    /**
     * 
     *
     * @param int name 
     * @param int value 
     * @return void
     * @access private
     */
    function set( $name,  $value )
    {

    } // end of member function set

} // end of Request
?>

view.php

/**
 * class View
 * 
 */
class View extends Smarty
{

    /** Aggregations: */

    /** Compositions: */

    /*** Attributes: ***/

    /**
     * 
     *
     * @return void
     * @access public
     */
    function execute(  )
    {

    } // end of member function execute

} // end of View
?>

おお、継承とかはちゃんとやってくれるみたいです。でもこのソースフォーマットって標準的じゃないっぽくない? 改めて考えてみるとラウンドトリップ機能ってコード書いてて途中でリファクタリングしてもクラス図やソースのメンテナンスが楽!っていうために使うんですな。吐いて終わりだと最初の一回だけだからあんまり嬉しくないかも・・・。

hatotech::kumatch: 第2回PHP関西セミナー

PHP関西 SEMINAR : 2004年9月度セミナーのご案内 セミナーには PHP の初心者から言語全般上級者の方まで幅広く参加します。セミナー内容およびその後の懇親会まで非常に身になる内容になります、させますので是非ともご参加を。関西 PHP のその無駄に元気な部分まで垣間見ることができます。

23日、会社の命を受けて最近噂のPHP関西のセミナー行ってきます。レベルが高そうなので付いて行けるかどうか・・・。会場で見かけても物を投げないで下さい。

Linuxを使ってみるにお邪魔してコメントさせてもらっていたネタ。

DB_DataObjectはfactory以外のメソッドではエラー時にDB_DataObject_Errorじゃなくてfalseを返してる。それじゃあErrorはどこ?と思ったら_lastErrorに入ってる。 で、_lastErrorはPHP慣例によりprivateじゃないの?どうやって取るの?取る方法が見つかんねーYO!という話。

* Last Error that has occured
* - use $this->_lastError or
* $last_error = &PEAR::getStaticProperty('DB_DataObject','lastError');

ソースのコメント中には「_lastErrorを取るかgetStaticPropertyしろ」との記述。結局_lastErrorもアリってこと?そもそも何でfalse返すようにしてんの?教えて、PHPのエライ人!

社内の開発方法標準化に取り組んでいます。

基本的にPHPでもオブジェクト指向開発&標準的なツール・ライブラリを使おうよってことで進めてるんですが穏やかに民主的に進めようとすると全然決まりませんな。

今更なにあたりまえのこと言ってんの?と思う人もいるかもしれませんが、結構多いんですよ、 「ファンクションベースで一から全部書くべきだ!」 とか 「オブジェクト指向開発は導入コストがかかりすぎる!」 といった反論に出会うことが。

そんな議論に付き合って半年ほど様子を見てきましたが、俺が責任者になったからにはそんなことを言う奴はフライス盤で右腕を切り落としてやる!

とりあえずPHPに関するところはこんな感じで行くことにします。(守らない奴はRS232Cケーブルで首を(略))

・フレームワーク(検証中)  ・Mojavi ・データベースコネクション  ・PEAR DB ・テンプレートエンジン  ・Smarty ・エラーハンドリング  ・PEAR PEAR ・O/Rマッパー  ・PEAR DB_DataObject ・Unitテスト  ・PEAR PHPUnit ・ユーザー認証(検証中)  ・PEAR LiveUser or PEAR Auth ・入力検証(検証中)  ・PEAR HTML_QuickForm ・ロギング(検証中)  ・PEAR Log or syslog ・データベース  ・MySQL4.0.20

そして2つのプロジェクトで試してみて良い感じだったのでPHPUnitによるテストファーストも必須にしました。 プロジェクトを成功させるにはこんな決めれば済むことはさっさと決めてしまって、メンバーのモチベーション管理や顧客とのコミュニケーションに時間を使いたいものです。

今後、この案が本当に通るのか、とか実際にやってみたら糞駄目で逆に左腕を切り落とされたとか、見守りつつ書いていこうと思います。PHPで開発をしている人は普通この辺の標準化をどうやって行っているか知りたいもんです。

PHP小ネタ。

PATH_SEPARATORという定数がある。これはWindowsだと””;”“、UNIXだと””:”“になっている。 何に使うかというとinclude_pathのセパレータとかに使う。

ini_set("include_path", ini_get("include_path").PATH_SEPARATOR."lib/");

IRCでariaが「Amazonで検索すると価格だけ出るようようなものができないか」という話をしていて、興味があったのでAmazonのWebサービスについて調べてみました。

PEAR XML_RPCを使ってみようと思ったんですが、よく見たらAmazonが提供するAPIはSOAPとRESTでした。AmazonのREST APIはパラメーターにxslも指定できるのでxslを用意するだけでいい感じの表示を得られるんですがやはりPHPで受け取ってパースすることに。

しかし作ろうと思ったとき何故かPEARのサイトが落ちてたのでリクエストの結果のXMLはxml関数でパースしました。(後日試したところPEAR XML_Treeは日本語文字化けした。みんな普通は何でパースしてるんだろう?)

少し面白げだったのでSmartyのキャッシュ機能とPEAR Pager_Slidingを使って価格調べ専用検索を作ってみました。

AmazonPriceSearch

Smartyのキャッシュ機能、強力でした。この場合、カテゴリー名・検索ワード・ページ番号を繋げてキャッシュIDにしてあります。キャッシュがある場合はバックエンドのWebサービスやDBにアクセスしないで表示するので相当パフォーマンスに影響あると思います。

Amazon Hacks 世界最大のショッピングサイト完全活用テクニック100選
ポール・ボシュ 篠原 稔和 ウェブ・ユーザビリティ研究会
オライリー・ジャパン (2004/04/24)
売り上げランキング: 2,320
通常24時間以内に発送します。
おすすめ度の平均: 3.2
4 Amazon を使いこなすために
5 アマゾンをもっと使いこなすための1冊
1 翻訳する価値があったかどうか疑問

来週PHPプロ・スタッフの面接があるのでかなりの確率で質問されるというWebアプリケーションのセキュリティに関して調べてみました。

■抑えておく用語

・XSS(クロスサイトスクリプティング) →フォームから入力した値がHTMLの一部として実行される場所で悪意あるスクリプトを動かしたり。具体的にはクッキーをパクッて他人のセッションを奪ったり。

・SQLインジェクション →SQL文を流し込むこと。例えばフォームの値をwhere句の条件に使う場合、入力フォームに”“1 or id = 2”“と入力したら・・・。

"update foo set cost = 100 where id = ".$_POST["id"];

・セッションハイジャック →他人のセッションを乗っ取ること。セッションIDの入ったクッキーがXSSによって盗まれたり、そのIDを使って成りすまされたり。

■対策

・GETパラメーター改竄 →GETの使用を最小限に留める。(Action=xxx的な処理の振り分けのフラグだけとか)

・HIDDEN値改竄(そしてAction値をフルパスに変更) →HIDDENを使わない。セッションにする。

・XSS →POSTにhtmlspecialchars。

・セッションハイジャック →セッションIDを単純な値にしたりCookieが盗まれなければ大丈夫。PHPのデフォルト設定ならそこそこ安心?(セッション有効時間24分、セッションIDはCookieに保存、Cookieはブラウザ閉じたら削除)

・SQLインジェクション →フォーム値の地道なValidationしかない?

少し前のPHPアプリのソースを読んでいて気付いた。

PEAR DBのfetchRowメソッドは1.5.0RC1を境にDB_common(DB_pgsqlとか)からDB_resultに移ってる。

1.4.0の場合

$row = $db->fetchRow($result);

1.5.0RC1以降の場合

$row = $result->fetchRow();

1.4.0まではなんでDBコネクションのオブジェクトのメソッドがfetchRowしてたんだろう・・・。古いスクリプトを今のPEAR DBで動かしたらfetchRow()が無いって。「えぇ、えぇ、無いですよ」