Born Too Late

最近 PHP ばっかりやってましたが, 年末で時間もあったので久々に Ruby で作ってみました.
2011 年最後の日にして, 初の Rubygems パッケージリリースです.

• 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 などでご意見いただけると幸いです.

algerb

この記事は PHP5.4 Advent Calendar jp: 2011 の 20 日目です.

• 前日: 次のプロジェクトで 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 パターンのビルドが行われます.
うまくいけば, 以下のような結果が得られます.
(設定は上記のものと多少異なります)

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 コミュニティにも希望が持てると感じます.

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

Behat, Continuous Integration, php-build, phpenv, PHPUnit, Travis CI

この記事は TDD Advent Calendar jp: 2011 の 14 日目です.

• 前日: 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 自体を導入する前の段階でも, 設計について新たな目線を得ることができるので, 何かしら良い効果を得ることでしょう.

Dependency Injection, Design Pattern, Singleton, TDD