PHP と MySQL を使ってカジュアルに MapReduce する MyMR というものを作ってみました.
とても安直な名前ですね.

yuya-takeyama/mymr – GitHub

とりあえず試してみる

MyMR には, MapReduce のマナー (?) に従って, WordCount するためのサンプルコードとサンプルデータを同梱してみました.

map/reduce 関数は PHP で書かれています.
WordCount.php

MySQL のユーザ名・パスワード等は適宜置き換えて下さい.

見事, 入力テーブル内の単語の出現回数を集計することができました.

MyMR の特徴

• データの入出力はいずれも MySQL のテーブル
• 入力と出力のデータベースは同じでもいいし別でもいい
  (入力はプロダクションサービスの Slave サーバで, 出力はデータ集計用の別サーバ, とかいうこともできる)
• map/reduce 関数を PHP で書く
• MySQL を意識することは無く, PHP 標準の array にほげほげするだけ
• 分散/冗長性/耐障害性などについては特に考えていないし, 考える予定も無い
  (エラー処理はちゃんとしたい)
• 並列処理でなく直列処理
  (並列処理は出来た方がいいと思っている)

まだ「とりあえず動く」程度の状態なので, 色々足りてない状態ではありますが, ギガ/テラバイト級のデータを相手にするのであれば Hadoop とかを使うべきだと思いますし, MyMR はそのような問題を解決しようとはしていません.

モチベーション

• MySQL に直接 MapReduce 処理を行いたい
• GROUP BY よりはもっと複雑な処理がやりたい
• map/reduce を LL で書きたい
• プログラミングモデルとしての MapReduce を活用したい

DBMS 上で MapReduce をやりたいのであれば MongoDB や CouchDB という選択肢がありますし, map/reduce を LL で書きたいというのであれば Hadoop Streaming という選択肢があるでしょう.
そうなると, やはり一番のモチベーションは MySQL で MapReduce する ということに尽きるように思います.

MongoDB による MapReduce も JavaScript でカジュアルにできてとても便利です.
ですが, 自分の場合, 普段の仕事だと, そもそものデータはほとんど MySQL に入っているので,

1. mysqldump で csv ファイルを作成
2. mongoimport で MongoDB にインポート
3. MongoDB 上で MapReduce

みたいな手順を踏む必要があり, 非常に面倒です.
場合によっては mongoexport で csv に出力してさらに MySQL 上にインポート, なんてことをやることもあって, 正直疲れました.

MySQL で ということの次に重要だと思うのが, プログラミングモデルとしての MapReduce です.
これについては書くと長くなりそうなのでやめておきますが, Haskell のような関数型言語をつまみ食いすることで, この辺りの魅力がわかってきたように思います.
(関数型言語における map 関数と Hadoop/MongoDB/MyMR における Map はちょっと違いますが)
伊藤直也さんの MapReduce::Lite なんかも, その辺りにモチベーションがあって作られたのではないか, と想像しています.

何故 PHP か

特に大した理由はありません.
強いていえば仕事で使いたいと思っていて, 周囲で使われているのが PHP である, というだけの話です.

ついでに挙げるなら, PHP では MySQL ドライバが標準で備わっている, というのもあります.
MyMR では PDO を使っており, 普通に構築された LAMP 環境であれば, まず問題無く使えると思います.

とはいえ, 例えば Bundler の使える環境であればそういった依存関係に悩まされることもありませんし, 正直 Ruby で書き直したい.

MyMR の仕組み

仕組みといえるほど複雑なことはやっていませんが…

1: 入力データの取得

これはとても単純で, mymr コマンドの -i (–input) オプションに渡したテーブルを全件 SELECT するのみです.

今の所全データをガバっとメモリ内に取り込むようになっているので, テーブルサイズに比例してメモリを食います.
非ビッグデータ向けのフレームワークとはいえ, これはさすがにあんまりなので, 何とかするつもりです.

あと, 未実装ですが, WHERE 条件なども指定できれば入力の段階でフィルタできて便利そうなので, やろうと思っています.

2: Map

SELECT で取得した全ての行に対して Map 処理を行います.

MyMR の map 関数では, その中で emit メソッドを実行することで, テンポラリテーブルにデータを INSERT していきます.
関数のプロトタイプは void map(array $record) というシンプルなもので, 1 レコードを表すハッシュ (PHP なので array) を受け取るだけです.

入力テーブルの定義についての制約は特にありません.
通常どんなテーブルでも入力として扱うことができます.

emit にはキーとそれに対応する値を渡すことで, 中間データがテンポラリテーブルに 1 行ずつ挿入されます.
本来は MySQL セッションが終了した時点でテーブルは消えるのですが, 先の WordCount の例でいうと以下のようなテーブルが作成されています.

emit に渡された値は自動的に JSON に変換されています.

JSON 化してるのは構造化データを扱えるようにするためで, この辺りは MongoDB の MapReduce にインスパイアされてます.

3: Shuffle/Sort (?)

Hadoop なんかで言うところの Shuffle/Sort 付近に該当する, と思っているのですが, あんまり自信ないです.
ぶっちゃけると Hadoop 自体を使ったことは無くて, ブログ記事や書籍でつまみ食いした程度の知識しかありません.
(り, りろんはしってる (知らない))

とにかく, ここでは Reduce フェーズの前の下準備として, キーが同一のものをグループ化しています.

MyMR ではカジュアルに GROUP BY と GROUP_CONCAT を使っています.

実際は GROUP_CONCAT の SEPARATOR には改行コードの LF を指定しており, 複数の JSON が改行区切りで連結されたものになります.
要するに複雑なパース無しで複数の JSON を分割できるデリミタであれば何でもよくて, 無難に LF を使っているというだけの話です.

ところで, ここで JSON の代わりに MessagePack を使えれば, それだけである程度高速化できると思うんですが, そのときのデリミタは何にすればいいんでしょう?

4: Reduce

前の Shuffle フェーズで実行したクエリの結果全行に対して, 1 行 1 行 Reduce 処理を行います.

Map と同様, reduce 関数に 1 行 1 行の値を渡していきます.
関数のプロトタイプは array reduce(string $key, array $values) となっています.
$values では GROUP_CONCAT で改行区切りとなっていた JSON を予めパースし, 値の配列として渡されます.

そして返り値のハッシュがそのまま 1 行として -o (–output) に指定されたテーブルに 1 行 1 行挿入されていきます.

また, map と違って単純な入出力モデルになっているので, テストが書きやすいという利点があります.

そしてこれも map と違って, 挿入するデータは JSON ではなく, ハッシュのキーをカラム名としてレコードにマッピングされます.
そのため, 出力テーブルの定義は reduce 処理に合わせておく必要があります.

これまた map と違って, 出力テーブルでは key という名前のカラムが, キーを格納するために予約されており, reduce 返すキーとしては避ける必要があります.
それ以外は自由ですが, key カラムにはユニークインデックスを設定しておくのが良いでしょう.

まとめ

MyMR について長々と書いてきましたが, この記事で一番主張したいのは「MySQL から直接 MapReduce できたら便利じゃないか」ということに尽きます.
そういう需要があってもよさそうなものですが, ググってみても意外とそれらしい記事は見つからず, じゃあ作ってみようということでできたのが MyMR です.

ほとんどプロトタイプみたいなもので, 作り込みはまだまだこれからですが, 「MySQL で MapReduce する」というアイディアを発表したくて, この記事を書いています.

また, 今回はたまたま MySQL でしたが, 入出力を抽象化して MapReduce をするための何かがあれば, いろいろ捗るんじゃないかなぁという妄想もあります.

ビッグデータは無くとも, ビッグデータ時代に生まれた知見を活かすことはできるんじゃないか, というお話でした.

See also

• MapReduce – naoyaのはてなダイアリー
• Map/Reduce チュートリアル
• MapReduce – Docs-Japanese – 10gen Confluence

Zend Engine 初心者による, Zend Engine 初心者のための発表という感じで話してきました.

今年に入ってから, scribble というなぐり書き用のブログを始めました.
GitHub Pages 内で Jekyll というツールを使って書いているんですが, Markdown で書いて git commit して git push するだけでサクッと公開できるのでとても気に入っています.

今のところ主に PHP 本体や, そのコアであるところの Zend Engine のコードリーディングが中心で, 今回の発表はこれらの記事をまとめた内容です.

闇 PHP 勉強会でのその他の発表はというと, PHP 製のパーサコンビネータとか, OpenCL とか, 魔改造 PHP とか様々で, こんな中でハッシュテーブルの実装について話し手も釈迦に説法なんではないかとかいろいろ危惧しましたが, わかりやすかったという声ももらえたようでよかったです.

この発表では, 既に scribble でも紹介している hashtable_dump という PHP Extension についても紹介しています.

本当は HashDoS 問題を解決したという Perl や Ruby におけるハッシュテーブルの実装についても調べて発表したかったんですが, 今回は間に合いませんでした.
次回の闇 PHP 勉強会があれば是非それらについて発表できればと思っています.

最後に, 主催の @anatoo さん, 会場提供のアシアル株式会社さん, 楽しい勉強会をありがとうございました.

お正月休みということでちょっとした Sinatra 製の Web アプリケーションをいじって遊んでいます.

ローカルでは Pow で開発して, Heroku へのデプロイを考えているんですが, 設定をどう管理するか迷いました.
いろいろ調べた結果, .powenv とか使う方法とかあったのですが, .powenv は Heroku 上では使えません.
どうしたものかとさらに探した結果, rack-config という gem があったのでそれをラップして何とかすることにしました.
(以降はエントリの内容から脱線するので省略. いい感じの方法があれば Twitter とかで教えていただけると幸いです.)

さっそく Gemfile を書いて必要な gem を用意しましょう.
趣味の開発ですし, rack は最新バージョンを指定して, あわよくば地雷を踏み, パッチなど書いて Pull request を送りたい, というのが人情というものでしょう.

これで bundle install を実行すると, 以下のようにエラーで中断してしまいます.

bundle install に失敗

これは rack と rack-config の互換性による問題です.
rack-config は 2012 年 1 月 2 日現在で丸 3 年程メンテされていない状態で, 依存する rack のバージョンが ~> 0.4 と, かなり古い状態です.
(~> 0.4 というのは 0.4.0 以上 0.5.0 未満という意味です)

今回指定した rack 1.4.0 は, rack-config が依存するバージョンに含まれないため, 依存関係の解決に失敗し, エラーとなってしまいます.

といっても, これはメタ情報におけるバージョンの指定の問題で, 実際に互換性があるかどうかは別の問題です.
rack-config の実装は README よりも短くシンプルなもので, 目 rackup した限りでは間違いなく動きそうに見えます.

作者に依頼して依存関係の指定を修正してもらうという手もありますが, 今回はとりあえずの解決をするための方法を紹介します.

大まかな手順

1. 元のプロジェクトを GitHub 上で fork してローカルに git clone する
2. ローカルの tmp-repo ブランチ上で *.gemspec の依存関係の指定を修正する
3. 自分のリポジトリに git push する
4. Gemfile で自分のリポジトリを指定する

Bundler は RubyGems.org からのインストールだけでなく, Git リポジトリからのインストールにも対応しています.
それを利用し, オレオレ Rubygems パッケージリポジトリを作って, そこからインストールしよう, というものです.

今回はたまたま元のプロジェクトが GitHub 上にあったので fork するだけで済みましたが, GitHub 上に無い場合も, 手動でリポジトリさえ作れば, あとは同様の手順で実行できます.

1. 元のプロジェクトを GitHub 上で fork してローカルに git clone する

clone については省略しますが, ブランチを切るのがいいでしょう.
一時的なリポジトリということで, tmp-repo という名前にしてみました.

2. ローカルの tmp-repo ブランチ上で *.gemspec の依存関係の指定を修正する

*.gemspec というのは, Rubygems パッケージのメタ情報を定義するファイルです.
依存関係もこのファイルに記述されています.

今回の場合は rack-config.gemspec に以下のような修正を加えました.

rack-config は rack 0.4.0 以上 1.5.0 未満に依存する, ということになったので, rack 1.4.0 も含まれるようになりました.

3. 自分のリポジトリに git push する

特に説明は要らないと思いますが念のため.

4. Gemfile で自分のリポジトリを指定する

先ほどの Gemfile を以下のように書き換えました.

fork した自分のリポジトリの URL と, 今回のために作成した tmp-repo ブランチを指定しています.

あとは最初と同じように bundle install を実行するだけです.

bundle install に成功

無理矢理 bundle install することに成功しました!

蛇足: オレはこう思う

今回はオレオレリポジトリを作ってとりあえずの解決を試みる方法を紹介しましたが, せっかくなら作者にも修正を出しておくとよりいいでしょう.
今後その gem を使用するときにいちいちオレオレリポジトリを指定するのは面倒ですし, 他の人にとってもその gem がメンテされた状態で使える方が便利です.

今回の rack-config についても, 実際は以下のような手順を経ています.

1. 元のプロジェクトを GitHub 上で fork してローカルに git clone する
2. ローカルの develop ブランチ上で Bundler を使ってテストできるように修正する
3. GitHub 上で Pull request を送る
4. develop ブランチから tmp-repo ブランチを作成する
5. ローカルの tmp-repo ブランチ上で *.gemspec の依存関係の指定を修正する
6. 自分のリポジトリに git push する
7. Gemfile で自分のリポジトリを指定する

修正を依頼しつつ, それとは別のブランチをオレオレリポジトリにしています.
(この Pull request が取り入れられるのかはまだわかりませんが…)

ついでに Travis CI で 0.4.0 以上 1.5.0 未満の全ての rack でテストが通ることも確認済みです.

Travis CI 用の設定ファイルは以下のようなスクリプトで, .travis.yml と gemfiles を生成しました.
Travis CI では複数の gemfiles を指定することで, それぞれで bundle install し, 複数のバージョンの gem に対してテストを行うことができます.

なお, rack は 0.4.x のあといきなり 0.9.x にバージョンが飛んでいます.

これで, 見事に全てのバージョンでテストが通ることが確認できました.
(ここまで必死になることも無いとは思いますが…)

• yuya-takeyama/algerb – GitHub
• algerb | RubyGems.org

これは何?

まぁタイトルの通りです.

Ruby には Kernel.#autoload というメソッドがあります.
これを利用すればいちいち手動で require しなくても, 対象となるモジュールやクラス名が参照されたタイミングで自動的に require してくれるというものです.

autoload は便利ですが, ライブラリ内のファイル数が増えてくるといちいち手動で書くのは大変になってくるので, じゃあ自動生成すればいいじゃない, ということで作ってみました.

使い方

プロジェクトの Gemfile に適当に設定します.

あとは bundler 経由でコマンドを実行するのみです.

これで ./lib ディレクトリ内を自動的に走査し, ./autoloader.rb というファイルを生成します.

これぐらいの規模だとそんなにありがたみは無いですが, 例えば Cucumber のような規模のプロジェクトで使用すると, 以下のようなファイルが生成されます.

ただ, これが実際に Cucumber プロジェクト内で正常に使えるかは試しておらず, よくわかりません.
理由は以下に.

仕組み

仕組みはすごく簡単で, ファイルパスからクラス・モジュール名をルールに従って変換し, それをもとに Ruby スクリプト化しているだけです.

例えば, ./lib/foo/bar/baz/foo_bar.rb というファイルがあるとすると, 中には Foo::Bar::Baz::FooBar というクラス (またはモジュール) があるに違い無い, という前提で生成しています.
ファイルの中身は一切参照していません.

よって, algerb が正常に動作する条件として, ファイルとクラス・モジュールの命名がルールに従っている必要があります.

課題

今のところひとつの ./lib ディレクトリしか対象にできないので, ./vendor ディレクトリ内のライブラリなどは相変わらず require する必要があります.

また, 1 ファイルに複数のクラス・モジュールが存在するなどといった場合にも対応できません.
これを実現するとなると, Ruby パーサなどを用いてもっとちゃんとファイル解析する必要があるでしょう.

あと, 情けない話なんですが, gem コマンド経由でインストールしたときに正常に動作しません…
gem install した時点で bundle install されてないので, 依存関係を解決することができずに, 起動すらできません.
これはただ単にやり方をしらないだけなので, 調べて直すつもりです.

ちょこちょこ修正するつもりではありますが, 普段 Ruby 開発をやっているわけではないので, どういう仕様にすれば役に立つのかよくわかってなかったりします.
Twitter などでご意見いただけると幸いです.

• 前日: 次のプロジェクトで PHP 5.4 の採用を提案するための 3 つのポイント (@co3k さん)
• 翌日: (@kokkekun さん)

Travis CI とは

Travis CI は, Continuous Integration (CI: 継続的インテグレーション) を実行するクラウド環境です.
GitHub に push すると, Travis CI の VM 上に通知が行われ, GitHub リポジトリからのチェックアウトや, ユニットテストの実行が行われます.
ユニットテストの実行は成功/失敗の結果により通知が行われ, また, 履歴も Travis CI 上に残ります.

元々は Ruby 専用のサービスだったと思いますが, その後 Clojure や Node.js などをサポートし, 1 ヶ月ぐらい前に PHP までもサポートされました.

Travis CI を利用する PHP プロジェクト

• Symfony2
• Doctrine2
• Behat
• PHP_CodeSniffer

これら以外にも Symfony 関連のライブラリやバンドルは多く登録されています.

ところで, 国産のものだと今のところは Diggin_Http_Charset ぐらいしか把握していません.
日本語の情報はまだほとんど無いに等しい状況なので, 日本国内の, 少なくとも PHP コミュニティにおいてはまだあまり認知されていないように思えます.

記事にするにはまだまだ調べが足りないのですが, とりあえず日本の PHP コミュニティにも広まって欲しいと思い, 紹介してみることにしました.

Travis CI で CI するまでの手順

何はともあれ, 実際に GitHub のリポジトリを登録してみましょう.

大まかに以下のような流れとなります.

1. GitHub でのアカウント登録
2. PHP プロジェクトのリポジトリを用意
3. リポジトリ内に専用の設定ファイル .travis.yml を用意
4. GitHub アカウントでの OAuth により Travis CI にサインイン
5. Travis CI のアカウント情報を GitHub のリポジトリの Service Hooks に登録
6. GitHub リポジトリに git push

まずは, Travis CI にサインインします.
GitHub のアカウントさえあれば, OAuth で簡単にサインインできます.

PHP のプロジェクトは何でもいいですが, とりあえずは PHPUnit のテストが書かれているものが必要です.
ちょっと試したいけど手頃なリポジトリが無い, という場合は, 以下のリポジトリを fork してやってみるのもいいでしょう.

• lsmith77/travis-ci-php-example – GitHub

Travis CI 用の設定ファイル .travis.yml ファイルは, とりあえず以下のようなものを用意しましょう.
これを, リポジトリ上のルートディレクトリに配置します.

設定項目は他にもたくさんあるので, 詳細は公式ドキュメントの Building a PHP Project を参照してください.

これで, git push 時に PHP5.3 と PHP5.4 の環境でテストが実行されます.
(そういえばこの記事は PHP5.4 Advent Calendar でした)

テストの実行には明示していませんが, デフォルトでは phpunit コマンドが実行されます.
PHPUnit ではデフォルトで phpunit.xml を設定ファイルとして読み込むので, これもリポジトリルートに置いておきましょう.
(ところで, よく phpunit.xml.dist という名前にしているものがありますけど, あれってどういう意味なんでしょう…)

リポジトリの Service Hooks の指定, つまりこれは push 等のイベントの発生時に Travis CI に通知を行う機能ですが, これは Travis CI 上の画面から簡単にできます.
フリックスイッチを ON にするだけです.

リポジトリの選択

ですが, このリポジトリ一覧は最大で 30 しか表示されない問題があるようで, 登録したいリポジトリが表示されない場合は, 手動で登録する必要があります.
手動での登録は GitHub のリポジトリから Admin -> Service Hooks -> Travis と進み, 必要な情報を入力します.

Domain と User は通常空のままでいいので, Token のみ Travis CI の画面上からコピーし, Active にチェックを入れた上で, Update Settings します.

これで Travis CI で CI を行う準備が整いました.
あとは, git push すればそのタイミングでビルドが実行されるので, Travis CI の画面上で確認しましょう.
また, GitHub の Service Hooks の画面で Test Hook ボタンを押すことでもビルドが始まります.
なお, このときは GitHub 上でデフォルトで表示される設定に鳴っているブランチ (デフォルトは master) に対してビルドが行われるようです.

Travis CI のワーカの稼働状況によってはなかなか結果が反映されないこともあるので, ご注意ください.

以下は, 細かい設定について説明します.

vendor ディレクトリへの対応

開発しているプロジェクトが依存する外部ライブラリは, よく vendor というディレクトリに入れられています.
vendor ごとリポジトリに放り込むこともできますが, 通常は vendor は .gitignore に登録して, リポジトリには登録しないことが多いでしょう.

その場合, vendor ディレクトリに対象のライブラリを自動でインストールできる必要があります.

今回は, 最近開発中の Speciphy という BDD フレームワークを例に説明を行います.

今回は, Speciphy は PHPSpec に依存しているので, 事前に PHPSpec をインストールしておかないと, Travis CI 上でテストを実行することができません.
そこで, 以下のようなインストールスクリプトを, install-vendor.sh として用意します.

今回は, PHPSpec を pyrus.phar でインストールしています.
(pyrus.phar というのは次世代の pear コマンドです)
予め必要となる pear channel を登録しておくことで, 対話無しで全自動でインストールが完了します.

なお, Symfony2 だと git submodule を利用して vendor を管理していると聞きますが, これについてはあまり知らないので割愛します.
やり方はいろいろあると思うので, フレームワークに合わせたり, 自分の好きな方法を探してみてもいいでしょう.
(Composer を使うのも面白いですね)

そして, .travis.yml に, 先ほどのインストールスクリプトを, ビルドの前の準備として実行するよう, 追記しましょう.

pyrus による vendor 対応については以下の記事を参考にしました.

• Using Pyrus To Manage PEAR Installable Vendor Libs

Behat によるテストも行う

デフォルトでは PHPUnit によるテストが実行されるのみですが, Behat によるテストも実行できるようにします.

テストとして実行されるコマンドは, .travis.yml で script という項目にコマンドを指定することで可能です.

ところで, ビルドの成功/失敗の判定は, コマンドの終了ステータスで行われているようです.
終了ステータスが 0 なら成功, それ以外なら失敗, という具合です.

つまり, 終了ステータスをきちんと指定しているテスティングフレームワークであれば, 基本的に何でも使えることになります.

そこで, テストを実行するためのスクリプトとして, 以下のような run-test.php を用意します.

環境変数 TESTING_FRAMEWORK が PHPUnit なら PHPUnit を実行し, Behat なら Behat を phar ファイルでダウンロードして実行する, というものです.
スクリプトの最後に終了ステータスを指定して exit しているので, テストの実行が成功/失敗のいずれでも適切に通知されます.

そして .travis.yml にも再度追記を行います.

今度は env という項目を追加しています.
これは, env を配列で複数指定することによって, その数だけテストを実行するというものです.

今回は PHP のバージョンに 5.3 と 5.4 の 2 種類, テスティングフレームワークに PHPUnit と Behat の 2 種類指定しているので, 2 x 2 で合計 4 パターンのビルドが行われます.
うまくいけば, 以下のような結果が得られます.
(設定は上記のものと多少異なります)

Travis CI 実行結果

PHP の Travis CI を支える技術

Travis CI では, テストを実行する際の環境の実行に phpenv が使われています.
また, PHP のビルドには当初 phpfarm が, そして今後は php-build に切り替わるようです.

どのように使われているかは, このあたりを見れば何となくわかると思います.
(ただし, master がデプロイされているとは限らないので, これが最新の状態とは限らないので注意は必要ですが)

phpenv と php-build については以前に以下のような記事を書いていますので, これらが参考になれば幸いです.

• 第57回PHP勉強会＠東京で開発環境構築について話して来た
• phpenv で複数の PHP 環境を管理する
• php-build で PHP 5.4.0 beta1 をビルドする

蛇足: オレはこう思う

Travis CI がどういう組織で作られているのかはまだよくわかってないのですが, GitHub のアカウントページを見る限りはそれぞれ所属はバラバラですし, IT ベンチャーとかではなく, コミュニティベースの活動による成果, ということなのでしょうか.

Travis CI の PHP 対応にあたっては, phpenv と php-build の作者である CHH さん, それらを Travis CI に取り入れるべく多くのパッチを提供した loicfrering さんを初め, 何人もの開発者が関わっているようです.

こんな風にありもののツールと, 多方面からの強力が実を結び, 今までには無い手軽さで CI 環境が手に入れられるようになったことは大変素晴らしいことだと思います.

Travis CI 自体もオープンソース活動をさらに加速させるものだと思いますし, これからの PHP コミュニティにも希望が持てると感じます.

フレームワークやライブラリを開発している皆さんは, 導入を検討してみてはいかがでしょうか.

• 前日: TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP (@kyon_mm さん)
• 翌日: TDDに対して思っていること (@gab_km さん)

この記事の概要

• TDD で開発することで設計上の問題点に気づきやすくなる
• Singleton はグローバル変数である
• Singleton の使用はできる限り避けるべきである

テスタビリティを意識しよう

TDD では, 原則としてユニットテストを書いてから実際のコードを実装します.
なので, 自然と「テストのしやすさ (テスタビリティ)」を意識して実装することになります.

そして, TDD においては一般的に, テスタビリティを意識することで, 設計が改善されるとされています.

オブジェクト指向には難しい概念がたくさん登場します.
単一責任の原則 (Single Responsibility Principle) とか, 関心事の分離 (Separation of Concerns)とか, 依存性の注入 (Dependency Injection) とか…
これらを, 書籍などで読むだけで理解できた, という人は少ないのではないでしょうか.
少なくとも私は, TDD を実践することで初めて, これらの原則の言いたいことを実感し, 理解につなげることができたと考えています.

オブジェクト指向設計の大切なことは TDD に学んだ, と言っても過言ではありません.
あまりにもたくさんのことを学んだので, それらをここで全て紹介するのは無理なことです.
なので, 今回はその中から一つだけ, 簡単なものを紹介しようと思います.

この記事では, 明日から意識できるポイントとして, 例えば, Singleton を避ける, ということについて紹介します.

Singleton とは

いわゆる Gang of Four の書籍で紹介されているデザインパターンのひとつで, 以下のようなことを実現するために利用されます.

• あるクラスのインスタンスが 1 つであることを保証する
• 常に同一へのインスタンスを取得するためのアクセスポイントを提供する

数あるデザインパターンの中でも比較的理解しやすく, 実装も簡単であるため, これを最初に覚えたという方も多いでしょう.
私自身もそうであったように思います.

Singleton パターンを適用してみる

例えば, PHP においては以下のように実装されます.
ここでは, ありがちな例として, アプリケーション中からグローバルに参照される Config (設定) クラスを作ってみましょう.

要点は以下の 3 点です.

• コンストラクタ (__construct メソッド) を private にすることで, new を禁止している
• 代わりに getInstance() という static メソッドでオブジェクトの生成をする
• getInstance() では初回だけ Config オブジェクトを生成して返すが, 次回以降は最初に作ったオブジェクトをそのまま返す

Singleton をテストする

次に Config オブジェクトをテストするコードを書いてみましょう.
テスティングフレームワークには PHPUnit を使用します.

このふたつのテストはいずれも成功します.

テストは問題無く通った

ですが, 記述する順序を逆にしてみると, いとも簡単に失敗してしまいます.

テストは壊れてしまった

一体, どうしてでしょうか.

Singleton はグローバル変数である

クラスを定義して, クラスメソッドを通してのアクセスを行っていますが, Config クラスのオブジェクトはグローバルに参照可能です.
本来ローカルスコープであるはずのメソッド間を超えて, 状態が共有されてしまいます.
そのため, 一度設定値 foo がセットされると, その後のテストで「foo がセットされていない状態」をテストすることができなくなってしまいました.

このように, Singleton パターンを適用したクラスのオブジェクトは, 本質的にはほとんどグローバル変数なのです.

テストは新鮮なうちに

ユニットテストを書く上で大切なことは, 出来る限りクリーンな状態で始めることです.

グローバル変数, データベース, ファイルシステムなどは, 状態として考えることができます.
コードやテストがこれらの状態に依存してしまうと, 状態の変化に弱くなり, 壊れやすくなります.

Singleton でない通常のクラスであれば, 複数のテストメソッド間で状態を共有されません.
スコープがテストメソッドごとに区切られるので, テスト対象のオブジェクトはガベージコレクションにより, 二度と再利用されないためです.
(もちろん, テストケースクラスのインスタンス変数などに入れてしまえば別ですが)

Singleton では, このガベージコレクションによる状態のクリアが起こらないため, 前のテストコンテキストを引きずったまま, 次のテストを実行することになってしまいます.
複数のテストが影響し合うことによりメンテナンス性が下がるだけでなく, 暗黙的なコンテキストの増大により, 理解もしづらくなります.

さらなる問題

Config 自体はとてもシンプルなので, さほど問題にはならないかもしれません.
ですが, Config::getInstance() がアプリケーションのあちこちで呼び出されていたらどうでしょうか.

例えば, ウェブアプリケーションにおいて, アプリケーションそれ自体を表す Application クラスについて考えてみます.

Application は設定によりデバッグモードの On/Off が切り替えられるとしましょう.
その設定は, Config オブジェクトが保持することになります.

デバッグモードであるかどうかは, Application オブジェクトの isDebug() メソッドで確認できます.
今度はそれをテストするコードを書いてみましょう.

そしてこのテストが通るように Application クラスを実装します.

これで, テストは問題なく通ります.
以下は Config のテストもあわせて実行した結果です.

テストは問題無く通った

ですが, さっきと同じで, このテストも順序を逆にすると失敗してしまいます.

テストはまたしても壊れてしまった

原因は, 先ほど Config のテストが失敗したのと全く同じです.
既に debug という設定値が入ってしまっているため, false を明示的に値をセットしない限りは, デバッグする設定のままになります.

このように, Singleton で実装したクラスそれ自体だけでなく, それを呼び出すクラスにまで, テストのしにくさが伝染してしまう可能性があるのです.

処方箋 1: 状態を初期化できるようにする

Config クラスのテストしにくさは, 状態がクリーンでないことにありました.
そこで, init() メソッドを実装することで, 状態を初期化できるようにしてみます.

テストもこのように書き換えます.

変更点は, Config::getInstance() した後に, init() を呼び出すようにしている点のみです.

これにより, いずれのテストもクリーンな状態でテストが実行されることになったので, 例え順番を変えても失敗しなくなりました.
Application クラスにおいても, 同じアプローチを採ることで, テストの実行順序に依存することは無くなります.

処方箋 2: 依存性の注入 (Dependency Injection) の利用

とはいえ, これで問題が無くなったわけではありません.
この Application クラスには, Config というクラス名がハードコードされており, 2 つのクラスは密結合になってしまっています.

これでは, Config に似た動きをした別のクラス (例えば CachedConfig とか) を作っても, 差し替えるには全ての Config を書き換える必要が出てしまいます.

ではどうするか.
オブジェクト指向が本来持つモジュール性を活かすのであれば, 引数で Config オブジェクトを渡すことを検討しましょう.
ここでいう引数とは, コンストラクタ引数でも, メソッド引数のどちらでも構いません.

先ほどよりもややコードが増えてしまいましたが, Config クラスのハードコードが無くなりました.
Application と Config の間の結合は緩くなり, CachedConfig や YamlConfig など, 同じように振る舞う別クラスへの差し替えが容易になりました.
また, モックやスタブを使ってのユニットテストも書きやすくなっています.

このように, 依存するオブジェクトのクラス名をハードコードするのではなく, 引数で渡すことを依存性の注入 (Dependency Injection) といいます.

ところで, クラス名のハードコードが問題になるのは, 何も Singleton だけの問題ではありません.
例え Singleton ではなくとも, new するクラス名をハードコードすれば, 同じようなことが問題になります.

とはいえ, Singleton を利用すると, getInstance() メソッドを利用した依存にしてしまいがちです.
出来る限り依存性の注入を利用し, クラス名をハードコードする箇所を最小限に留めることで, 後の改修時のコストを大幅に下げることができます.

処方箋 3: そのクラスは本当に Singleton なのか

あなたが今実装しようとしているクラスは, 本当に唯一なのでしょうか.
また, 通常唯一であるとしても, コンストラクタを private にしないと実現できないことなのでしょうか.

確かに, Singleton の「常に同一のインスタンスを返す」という特性は便利です.
ですが, 少なくとも私の経験においては, 「インスタンスが 1 つであることの保証」は, そんなに気張るほどのことでは無かったのではないか, と考えてしまいます.

また, 見方を変えれば, Singleton は, そのクラス本来の役割 (Config であれば設定の保持) とは別にもうひとつ, 「オブジェクト生成の管理」という, 全く違った責任を持ってしまっています.
これは, 単一責任の原則に違反していると言えるでしょう.

これをどう解決するか.
少々場当たり的ですが, 例えば Config と, その生成を責任とする ConfigManager に分割する, といったことが考えられます.

この実装自体はあまりオススメしませんが, とりあえず設定の保持 (Config) という責任と, 設定オブジェクト生成の管理 (ConfigManager) という責任を, 個別のクラスに分割することができました.
これにより, Config クラスのコンストラクタを private にするという縛りは無くとも, ConfigManager を利用する限りにおいては, 常に同一のインスタンスを得ることができるようになりました.

コンストラクタが使用できる以上は, オブジェクトの生成は自由になったので, テスト時は毎回オブジェクトを生成・破棄し, クリーンな状態でのテストが可能になりました.
もう init() は必要ありません.

テストメソッドごとにコンテキストが分割されたので, ガベージコレクション任せで安心してテストに集中することができるようになりました.

まとめ

Singleton の話ばかりしましたが, この記事で私が言いたいのは, TDD で開発することで設計上の問題点に気づきやすくなる, ということです.

TDD の実践から学べることは多いにあるので, まだやったことないという方には, まず趣味の開発でいいので, 軽い気持ちでやってみることをオススメします.
業務に TDD 自体を導入する前の段階でも, 設計について新たな目線を得ることができるので, 何かしら良い効果を得ることでしょう.

内容はほぼ最近のブログ記事をまとめた感じです.

• php-build で PHP 5.4.0 beta1 をビルドする
• phpenv で複数の PHP 環境を管理する

一度ブログに書いたものを敢えて発表ネタにしたのにはいくつか理由があります.
(もちろん, 一度記事にまとめたネタなのでスライドに起こしやすい, というのもありますが…)

• もっと色んな人に知って欲しい
• もっといろんな人に使って欲しい
• まだまだこなれていない部分があり, フィードバックが必要
• フィードバックやパッチによりもっと改善されるはず

というわけで皆さんどんどん使いましょう.

類似のツールについて

php-build および phpenv と類似の機能をもったツールは他にもあります.
勉強会でも, 例えば phpall とはどう違うのか, という質問がありました.

結論から言うと, 私は他のツールは特に使ったことが無いのでよくわかりません.
ですが, もともと rbenv は Ruby コミュニティではかなり人気のツールですし, 便利な機能はいろいろと揃っており, 比較的失敗の無い選択肢だと考えています.

また, phpall の違いとして, phpall は各バージョンのバイナリをそれぞれ php-5.2.8 といった, バージョン番号付きのファイル名にしているようですが, phpenv は php コマンド自体を自由に切り替えます.
特定のコードを複数のバージョンで一気に実行する, というときには phpall が便利そうですが, ライブラリの開発等には phpenv の方が適していると思われます.
また, phpenv においては pyrus, phar, phpunit といったコマンドも各バージョンごとに試すことができる, というのも大きな利点です.

phpenv のプラグイン機能について

元々, これまでのブログ記事をまとめただけの発表にするつもりでしたが, ひとつだけおもしろい機能を見つけたので, そこだけ新ネタです.
phpenv の元になっている rbenv にはプラグインという機能があり, 専用のディレクトリにシェルスクリプトを配置するだけで簡単にサブコマンドを登録できる, というものです.
当然 phpenv でも使える機能です.

phpenv each によるコマンドの一斉実行

rbenv のプラグインとして公開されているものの中で, とりあえず rbenv-each というものをつかってみました.
これは rbnev (もしくは phpenv) の管理下にある全てのバージョンのバイナリで, 指定したコマンドを実行する, というものです.

とりあえず, php -v によるバージョンの確認を試してみました.

phpenv each によるバージョンの一斉確認

これ自体はあまり意味の無い例ですが, 例えば PHPUnit によるユニットテストを, 複数のバージョンの PHP で一斉に実行できるすれば, ライブラリ作者に取ってはかなり便利なのではないでしょうか.
それについてはいずれ調べて, また記事にしたいと思います.

このように, php-build と phpenv にはまだまだ便利な使い方がたくさんあるはずです.
利用者が増えることで, そういったノウハウが発掘され, 共有されることを心から願います.

最後になりますが, 今回の勉強会の主催の @gusagi さん, そして会場提供の株式会社 VOYAGE GROUP さん, 楽しい勉強会を本当にありがとうございました.

CHH/phpenv – GitHub

複数のバージョンの PHP を管理し, コマンドで簡単に切り替えるためのものです.
Ruby でいう rbenv や RVM, Perl でいうところの perlbrew にあたるものです.

なお, phpenv の中身は rbenv を流用することで動いています.

インストール

まず, 以下のコマンドでインストールスクリプトを実行します.

$ curl https://raw.github.com/CHH/phpenv/master/install.sh | sh

中では rbenv を git clone していたりするので, Git をインストールしている必要があります.

上記コマンドが成功したら, ~/.bashrc もしくは zsh 使いなら ~/.zshrc に以下のコマンドを追記します.

あとはいま編集したファイルを再度読み込み直すことでインストールは完了です.

# bash の場合
$ source ~/.bashrc

# zsh の場合
$ source ~/.zshrc

# phpenv
export PATH=$HOME/.phpenv/bin:$PATH
eval "$(phpenv init -)"

rbenv をインストールしている場合

先にも書きましたが, phpenv は rbenv を利用した作りになっています.
その関係もあって, PATH の設定は rbenv が phpenv よりも先になっていないと, 正常に動作しません.
~/.bashrc や ~/.zshrc の設定は, 例えば以下のようにする必要があるので注意が必要です.

# rbenv & phpenv
export PATH=$HOME/.rbenv/bin:$HOME/.phpenv/bin:$PATH
eval "$(rbenv init -)"
eval "$(phpenv init -)"

PHP のインストール

phpenv は PHP の環境を管理するためのものであって, RVM や perlbrew のようにインストールするための機能はありません.
その点は rbenv も同様です.

rbenv では ruby-build を使って Ruby をインストールしますが, phpenv では php-build というツールを使うことができます.

php-build のインストールについては以下の記事を参考にしてください.

php-build で PHP 5.4.0 beta1 をビルドする

以下は php-build のインストールを済ませた, という前提で進めます.

phpenv で管理できるようにインストールするには, ~/.phpenv/versions ディレクトリ内にサブディレクトリを作って, それぞれのバージョンの PHP をインストールする必要があるので, 以下のようにします.

$ php-build 5.4.0beta2 ~/.phpenv/versions/5.4.0beta2

インストールが完了すれば phpenv の管理下に置かれることになります.

$ phpenv versions
  5.4.0beta1
* 5.4.0beta2 (set by /home/yuya/.phpenv/version)

使用する PHP のバージョンを切り替える

以下のようなのコマンドで, インストール済みの PHP のバージョンを切り替えることができます.

$ phpenv global 5.4.0beta2

その他, 使い方は基本的に rbenv と同様なので, そちらを参考にしてください.

sstephenson/rbenv – GitHub

phpenv と php-build の連携

php-build でのビルドでも充分に簡単ですが, せっかくなので phpenv と連携させてもっと簡単にしてみましょう.
以下のようなコマンドだけで好きなバージョンの PHP をビルドし, phpenv の管理下にインストールできるようにします.

$ phpenv install 5.4.0beta2

rbenv でも ruby-build と連携することで rbenv install というサブコマンドを利用することができるようになります.
そこで, rbenv install するためのスクリプト rbenv-install を流用して, こんなものを用意してみました.

このスクリプトを ~/.phpenv/libexec/rbenv-install として保存するだけでインストールは完了です.
これで先のような phpenv install サブコマンドが使えるようになっています.

1. Gist にコードを貼付ける
2. UserScript を使って好きな色に変える
3. PowerPoint なり Keynote なりにコピペする

この方法で作られたのが, ひとつ前の記事のスライドです.
以下, もう少し詳しく説明します.

Gist にコードを貼付ける

これは特に説明いらないと思いますが, GitHub の Gist に, スライドに掲載したいコードをコピペします.
Gist ではアカウントが無くても匿名でコードを貼付けることができます.

UserScript を使って好きな色に変える

ここが一連の流れの中のキモです.

UserScript とは, Firefox であれば Greasemonkey というアドオンを使って, ページのレンダリング後にフックさせるスクリプトのことです.
要は, 特定のページの表示するときに好きな JavaScript を実行させるものです.
UserScript の設定についてはこの記事では説明しません.

なお, Google Chrome であれば UserScript は標準でサポートされています.

以下の UserScript は, PHP のコードのシンタックスハイライトを, ボク自身の好みに合わせて変えるためのものです.

Gist ではシンタックスハイライトが span タグの class で指定されています.
この UserScript では, それぞれのクラスに対して自分の好きなスタイルを追加で適用しています.

これを使うと, Gist におけるシンタックスハイライトは以下のようになります.

シンタックスハイライトを変更した Gist

言語によって, 指定された class は結構異なるようで, 上記の UserScript ではカバーされていない class もあります.
上記はそのまま使うのではなく, それぞれの好みや言語によって作り替えるのがいいでしょう.

PowerPoint なり Keynote なりにコピペする

PowerPoint や Keynote は, ブラウザから文字列をコピペする際, 色や大きさといった文字の属性ごとコピーしてくれます.
それ以外でも, そういった機能を持つプレゼンテーションソフトウェアであればこの方法は使えますし, そうでないものであれば使えません.

Gist からコードを貼付けると以下のようになります.

コードを Keynote にコピペ

このままだと小さすぎるので, 文字サイズは適宜調節します.
UserScript で予め文字を大きくしておくこともできますが, 文字の大きさはそれぞれで微調整するので, 貼付けたあとで変更するようにしました.

問題点

コピペ作業が多いので, コードが増えてくると結局煩雑になります.
プレゼンテーションソフトウェアの中には, プレーンテキストからスライドを生成するものがあり, それらは主にエンジニア向けにデザインされているので, コードのシンタックスハイライトに対応しているものが多いです.
そういう場合はそういった選択肢を考えてみるのもいいかもしれません.

最近 HTML5 化した Slideshare ですが, エラーで表示できないスライドが多すぎてまともに閲覧できないようです.
この記事に掲載している Flash 版は今まで通りの問題なく表示できるのですが…

スライドが完成したのが勉強会への出発 15 分前で, 通しで練習することすらできず, 発表はかなりひどいものとなっていまいました.
最低限, スライドの流れぐらいは頭の中に入れて発表すべきですね…

スライドだけ見てわかるような作りにはなっていないので, 以下で補足したいと思います.
ただし, 序盤は省略し, 本論となる書法編とパターン編についてのみとなります.

それぞれ該当するスライド番号も付記してありますので, よければご活用ください.

書法編 1: ヘルパーメソッドを使う (25 ~ 30)

テスト対象のオブジェクト, それを生成するのに必要な依存オブジェクトの生成には, ヘルパーメソッドの使用を検討しましょう.
new するだけで済むものであればそれでもいいのですが, 生成に複雑なステップを踏む必要がある場合に威力を発揮します.

これは一般的なプログラミングにおけるサブルーチンみたいなものだと思って問題無いと思います.
ただし, 可読性を問題にするのであれば, 多少長くても説明的でわかりやすいメソッドの命名を心がける必要があります.

テスト対象の生成が複雑だと, 複数のテストの比較が大変になります.
ヘルパーメソッドを使うことで, テスト A とテスト B はどこに有意な違いが有り, 結果に違いが生まれるのか, ということがわかりやすくなります.

書籍 xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler)) では, Fixture Setup Patterns において Creation Method という名前で紹介されています.
また, これの応用として, 引数付きの Parameterized Creation Method というものも紹介されています.

書法編 2: テストメソッドを分割する (31 ~ 36)

ひとつのテストメソッド内で, いろんなことをテストしようとすると, 何をテストしようとしているのかがわかりにくくなります.
例え同じメソッドを対象にしたテストであっても, 前提条件等が違うのであれば, 分割するべきです.

分割することで, それぞれのテストメソッドには, より具体的な名前をつけることができます.
これもまた可読性に寄与すると言えるでしょう.

これは癖のレベルの話なので, 普段からテストを書いている人であれば無意識にそうなると思います.
まずは 1 つのテストメソッドにおいてアサーションは 1 つまで, というルールを課すことで自然とそういう書き方に近づくと思います.

パターン編 1: 依存性は外から差し込む (39 ~ 49)

スライドでは, フレームワークによくある Request クラスを例に, $_SERVER といったスーパーグローバル変数を使ったときに起こる問題について説明しました.

$_SERVER を使った実装でもちゃんと動作するので, 問題と見なさないこともできます.
しかし, 問題はテストを書こうとしたときに顕在化します.

スーパーグローバル変数に限らず, グローバル変数を利用した実装だと, 複数のテストが影響し合う可能性が生まれます.
スライドではコードで例示しているので, 具体的にはスライドの該当箇所を参照してください.
スライドのように unset($_SERVER['HTTPS']) とすることで回避できますが, コードベースが巨大化すると, 暗黙的なコンテキストが肥大化し, テストを書くのがだんだんと困難になります.

その代わりにどうするのかというと, スーパーグローバル変数 $_SERVER を直接参照するのではなく, コンストラクタやセッターメソッド等で, 引数として差し込む, という方法を採ります.
Dependency Injection (DI, 依存性の注入) というパターンです.
DI を採用することで, 再利用性が高くなるので, テストを書くことで設計が向上する例としては比較的よく挙げられます.

パターン編 2: 外部への依存を避ける (50 ~ 62)

ひとつ前の話を逆に言っているだけですが, 別の側面から解説しています.

外部への依存としては, 例えば以下のようなものが挙げられます.

• グローバル変数/スーパーグローバル変数
• ファイルシステム
• Web API やデータベース等のネットワーク

しかし, もちろんこれらを完全に避けてのアプリケーション開発は考えられません.
それではどうするのか, ということで, スライドでは Active Record の問題点と, それを解決したパターンとしての Data Mapper を例に説明しています.

ここでいう Active Record というのはパターンとしての Active Record で, 書籍 Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler)) で紹介されています.
Ruby on Rails の ORM としての ActiveRecord は, それを実装したものです.

Active Record においては, 1 つのレコードが 1 つのオブジェクトにマッピングされ, それぞれのレコードはデータベースを知っています.
なので, $record->save() といった操作が可能になります.

Data Mapper でも 1 つのレコードが 1 つのオブジェクトに, という部分は変わりませんが, それぞれのレコードはデータベースのことを知りません.
例えば users というテーブルであれば, User クラスがその 1 レコードを表し, UserMapper はテーブルを表します.
(実際にはテーブルをラップしたクラスとして実装されることが多いと思いますが, ここでは単純化しています)
レコードはデータベースのことを知らないので, レコードを保存する際は $mapper->save($record) といったようにする必要があります.

それでは Active Record の何が問題なのか.
Active Record ではレコードがドメインロジック (ビジネスロジック) を持ったドメインオブジェクトとしての側面と, データアクセスを行うオブジェクトとしての側面を持つことになります.
それぞれは全く違った関心事なので, 関心事の分離 (SoC) や単一責任原則 (SRP) といったソフトウェア開発の原則に違反することになります.
テストに関していうと, データベースへのアクセス無しにドメインロジックをテストできない, といったことが起こりやすくなります.
(もちろん, 実装によりますが)

逆に Data Mapper ではドメインロジック (上の例でいうと User クラス) をデータベース無しでテストできます.
データベースに対してテストを書きたいときもありますし, そのためのテクニックもいろいろとありますが, まずはそれらを無視してテストできるようなクラス分割を行うことで, 低コストで確実にテストを書くことができます.

パターン編 3: Singleton を避ける (63 ~ 71)

Singleton は GoF のデザインパターンの中では最も理解しやいもののひとつで, よく使われるパターンのひとつです.
しかし, 同時に批判的意見の多いパターンでもあります.

Singleton ではクラスの static プロパティとしてオブジェクトとその状態がグローバル空間に残ってしまいます.
これはつまり, グローバル変数と同様の性質を持っている, ということができます.

また, グローバル変数と違って, 容易に上書くこともできないので, テストをする上ではさらに厄介な存在といえます.

対策としては以下が考えられます.

• 状態を初期化するためのメソッドを用意する
• アプリケーション本体では getInstance() といった, 常に同一のインスタンスを取得するメソッドの使用を規約化し, テストでは new でそれぞれ独立したオブジェクトを生成し, テストする

また, PHPUnit にはこれらを回避するための –process-isolation オプションであったり, @runTestsInSeparateProcesses アノテーションといった機能もあるのですが, それらについては説明しませんでした.
Singleton を使わなければ, これらの機能について理解する必要もなくなりますし, これらは Slow Test (テストの実行が遅くなる) 問題を引き起こします.

Singleton で実装したくなったとき, 本当に Singleton である必要があるのかについては, 一度考えてみる必要があるでしょう.

参考文献

スライド中に挙げたものです.
書籍へのリンクにはアフィリエイトタグをつけています.

• xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))
  xUnit とというのは SUnit (Smalltalk), JUnit (Java) といったナントカ Unit 系テスティングフレームの総称です.
  例として示されるコードは Java のものが多めですが, PHPUnit も書き方を含めて xUnit と呼べるものなので, この書籍で挙げられている考え方やテクニックは, ほぼそのまま適用できます.
  鈍器として人を殺せる程の分量がありますが, 気になるトピックをつまみ食いすることもできます.
• Real-World Solutions for Developing High-Quality PHP Frameworks and Applications
  PHPUnit の作者 Sebastian Bergmann を初めとする豪華な著者陣による, PHP アプリケーションの品質, テスト, 設計についての書籍.
  Symfony の作者 Fabien Potencier による章もあります.
  ソフトウェアの品質についての解説などは他の PHP 本にはまず無いものですし, 非常に刺激的な 1 册です.
• Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler))
  アプリケーションのアーキテクチャパターンについての書籍.
  全体的な分量からするとほとんど読めていないのですが, スライド中の Active Record や Data Mapper について参考にしました.
• PHPによるデザインパターン入門
  GoF によるデザインパターンを PHP に翻訳して紹介している書籍.
  新卒の頃に読んで衝撃を受けました.
  残念ながら絶版なので買うことはできませんが, 原稿が公開されているので, 読むことはできます.
  是非電子書籍化して欲しい 1 冊です.

こちらはスライドです.

• Dependency Injection with PHP 5. 3
  
Symfony の作者 Fabien Potencier によるスライド.
  序盤は Dependency Injection の基礎についての説明で, そのあとに PHP 5.3 における DI コンテナの実装について説明しています.
• BEAR DI
  リソース指向のフレームワーク BEAR の作者の @koriym さんによるスライド.
  序盤は前のスライドを日本語訳しつつ引用し, 後半では BEAR の DI コンテナについて説明しています.
• Clean PHP
  PHPUnit の作者 Sebastian Bergmann によるスライド.
  これだけ見て何かを理解するのには向きませんが, Active Record と Data Mapper の比較についてはこれを参考にしました.
• Singletons in PHP – Why they are bad and how you can eliminate them from your applications
  
Singleton の問題点について, 詳細に説明されています.