Technote

Composerにはautoloadを自動生成する機能があり、これを利用するとrequire_onceなどを使わなくとも自動的にソースコードがロードされます。言葉のとおりautoloadですね。

例えばCakePHPではApp::uses()という記述で利用するクラスがどこにあるのか識別して、クラスをロードできるようにするのですが、これを使わなくても Composer のautoload機能を使うとクラスが利用可能になります。

app/composer.json に以下のような定義を記述してみましょう。

{
    "autoload": {
        "classmap": ["Model", "Controller"]
    },
}

ここで autoloadだけ を更新するコマンドを実行します。

composer dumpautoload

コマンド名からはちょっと想像がつきにくいのですが、これを実行すると Generating autoload files という結果が表示されてautoload定義が更新されます。

// app/Vendor/composer/autoload_classmap.php
<?php

// autoload_classmap.php @generated by Composer

$vendorDir = dirname(dirname(__FILE__));
$baseDir = dirname($vendorDir);

return array(
    'AppController' => $baseDir . '/Controller/AppController.php',
    'AppModel' => $baseDir . '/Model/AppModel.php',
    'PagesController' => $baseDir . '/Controller/PagesController.php',
    'Post' => $baseDir . '/Model/Post.php',
    'PostsController' => $baseDir . '/Controller/PostsController.php',
);

今回は予めpostsテーブルからbakeしてPostモデルとPostsコントローラを生成しておきました。 こうすると、App::uses()を記述しなくても、composerのautoloadがクラス名からPHPファイルを自動解決してくれます。App::uses()の記述が多過ぎてコードの見通しが悪い場合などに利用を検討されてはいかがでしょうか？

この他にもComposerのautoload機能は

• PSR-4
• PSR-0
• Files（ファイルを直接指定できる）
• include-path(どうしてもphp.ini的なincludeパスで解決しなくてはならない時のためにある)

といったパス解決方法を用意していますので、namespaceが入ったものなどのサポートも万全です。

詳しくは Composerの公式ドキュメントのautoloadを参照ください。

2014/3/18にコワーキングスペース茅場町Co-Edoで開催された「テスト駆動web開発勉強会 Vol.1」で「Webアプリケーションテスト手法2014」の発表をしました。

第一回目ということと、1時間枠と限られた時間の中でCakePHPとJavaScriptについてのテストの話をしたので、ざっくりした内容となっています。

今後ハンズオンなども計画しているようなので、DoorKeeperのページをチェックしておくと良いかなーと思います。 また当日は「Java,PHPエンジニアの派遣、求人を探すならJapheego（ジャフィーゴ）」さんに懇親会スポンサーになっていただき、美味いビールとSUBWAYのサンドイッチをいただきました。感謝! 勉強会の懇親会はピザが多いのですが、連続すると飽きるのでたまにはSUBWAYのデリバリーとか良いと思いますよ！（SUBWAY大好きです）

最後に、当日紹介したサンプルのCakePHPテストコードを掲載しておきます。

モデルのテスト例：

<?php
class PostTest extends CakeTestCase {
    public $fixture = ['app.Post', 'app.Comment'];

    public function setUp() {
        $this->model = ClassRegistry::init('Post');
        $this->model = $this->getMockForModel('Post');
        $this->model = $this->getMockForModel('Post', ['save']);
    }

    public function testタイトルがない場合はバリデーションエラーになること() {

    }
    public function testデータベースへの保存に失敗した場合はfalseが戻ること() {

    }
    public function testデータベースへの保存に成功した場合はtrueが戻ること() {

    }
    public function testデータベースに新規登録できること() {

    }
}

モデルの初期化方法には3つのやり方があり、通常はClassRegistry::init()で良いのですが、モデルをモックしたい場合はgetMockForModel()というCakeTestCaseが用意してくれているモデル専用のモックジェネレータを使います。第二引数にメソッドの配列を指定するとパーシャルモックとなり、特定のメソッドのみモックします。

コントローラのテスト例:

<?php
class PostsControllerTest extends ControllerTestCase {
    public function setUp() {
        $this->controller = $this->generate('Posts',[
            'components' => [
                'Session',
                'RequestHandler'=>['isPost'],
            ],
            'models' => [
                'Post' => ['findById','delete'],
            ],
            'methods' => [
                'redirect', 'render',
            ],
        ]);
    }

    /**
     * @expectedException NotFoundException
     */
    public function test存在しない記事を表示するとNotFound例外になること() {
        $this->testAction('/posts/view/999');
    }
    /**
     * @expectedException BadRequestException
     */
    public function test保存がPOST以外で呼び出されたらBadResuest例外になること() {
        $this->testAction('/posts/save/1', ['method' => 'get']);
    }
    public function test削除が成功したらindexにリダイレクトする() {
        $this->controller->Post->expects($this->once())->method('delete')
                ->with($this->equalTo(1))->will($this->returnValue(true));
        $this->controller->expects($this->once())->method('redirect')
                ->with($this->equalTo('index'));
        $this->testAction('/posts/delete/1', ['method' => 'delete']);
    }
    public function test新しいトピックを追加できたら画面にメッセージが戻ること() {

    }
}

コントローラのテストをするとき、testActionメソッドを呼び出すわけですが、そのときコントローラ自体をモックするにはControllerTestCaseが用意してくれているコントローラ専用のモックジェネレータであるgenerate()を利用します。generateで作成したインスタンスをテストケースクラスのcontrollerメンバ変数にセットすることでControllerTestCaseがURLからディスパッチするときに、このモックオブジェクトを利用してくれます。

コントローラから依存関係にある、コンポーネント、モデルについてそれぞれサンプルのようにモックでき、コントローラ自体のメソッドもmethodsに列挙することでモックできます。例えばredirect()やrender()などがよく使われると思います。

あるURLや特定のパラメータ、ユーザでアクセスされたとき、プレフィックスルーティングを付けたかったので、動的に付与したらハマったので小ネタを書いておきます。

動的にプレフィックスルーティングを追加するには

公式ドキュメントの解説のとおり、

// routes.php
Router::connect(
    "/site-proxy/:controller",
    array('action' => 'index', 'prefix' => 'site-proxy', 'site-proxy' => true)
);

// core.phpなど
Configure::write('Routing.prefixes', array('site-proxy'));

のように記述します。

RouterTest.phpのテストコードを見たら

$request = new CakeRequest();
$request->addParams(array(
    'controller' => 'registrations', 'action' => 'admin_index',
    'plugin' => null, 'prefix' => 'admin', 'admin' => true,
    'ext' => 'html'
));

みたいなコードがあったので、CakeRequest::addParams() を使って追加できることがわかります。

実際コントローラで

$this->request->addParams(['prefix' => 'site-proxy', 'site-proxy' => true]);

みたいに書くと、View上で $this->html->link() などで出力されるURLにプレフィックスルーティングが追加されます。

ハマりポイント

View上でフォームを作成するときに

echo $this->Form->create('Post');

のように書くと思うのですが、このようにモデル名だけが指定されているときCakePHPではどのようにURLが生成されるか、というと

// FormHelper::create() L367付近
if ($options['action'] === null && $options['url'] === null) {
    $options['action'] = $this->request->here(false);
} elseif (empty($options['url']) || is_array($options['url'])) {

URLというオプションを指定しない場合は、 action は CakeRequest::here() の値になることがわかります。

で、CakeRequest::here() とはどんなコードか見てみると

public function here($base = true) {
    $url = $this->here;
    if (!empty($this->query)) {
        $url .= '?' . http_build_query($this->query, null, '&');
    }
    if (!$base) {
        $url = preg_replace('/^' . preg_quote($this->base, '/') . '/', '', $url, 1);
    }
    return $url;
}

のようになっていて、要は現在のURL（$this->query）から再生成されるだけです。リクエストに入っているプレフィックスルーティングの設定は参照されず、プレフィックスなしのURLがformタグのactionに入ってしまいます。

まとめ

解決方法としては

• Form::create() で url オプションを追加する

• addParams するときに here を変更する

  // 例）
  $request->addParams(array(
      'admin' => true,
      'prefix' => 'admin',
  ))->addPaths(array(
      'here' => '/admin/this/interesting/index',
  ))
  

あたりが良さそうです。まぁ動的にプレフィックス付けるなんてあんまりやらないのかもしれないですが、何かの参考になれば…

現在以下のような環境を設置して開発をしています。

• ホストOS: Windows7
• 仮想環境: Vagrant + VirtualBox
• ゲストOS: CentOS 6.4
• 開発環境: Apache, PHP, MySQL, git, composer, CakePHP, Bdd, …

事件その1: Bddプラグインがインストールできなくなった

ある日、新しくcomposer installで環境を作っていた人が「Bddプラグインがうまくインストールできないんですけど…」 という事で調べていたら Bddプラグインから依存関係にあったライブラリが行方不明になっていました。

それは phpunit/Object_Freezer です。以前はpearにあって、あるときからgithubに移行していたはずなのに、どこにも痕跡を残さず消滅していました。 で、どこで使っているかというと、Bddプラグインの単体テストモジュールにあたるSpec-PHPです。 現在は Spec-PHP に同梱する形で解決しているのですが、以前はcomposer.jsonに

"pear-phpunit/Object_Freezer": "*"

のように指定していました。ちょうど金曜日だったので、週末にこれらを解決してBddプラグインがうまくイントールできるようになった（私の自宅Mac OSX環境+BddExampleAppで確認）と安心して月曜日出社したのです。

事件その2: PHPUnitがインストールできない!

で、Vagrant環境で更新してみたら….

composer update sizuhiko/Bdd

失敗….

しかも全然関係ないところ PHPUnit のインストールで失敗するよ！ ちょうどその週末にPHPUnit4.0のコードがGitHubのデフォルトになりはじめたあたりでした。

でcomposer.jsonにはPHPUnitの記述が

"phpunit/phpunit": "3.7.*"

のように入っています。一見PHPUnit4をインストールするわけではないので関係なさそうですが、 composer install を実行すると

.....
  - Installing phpunit/php-token-stream (dev-master 292f4d5)
    Cloning 292f4d5772dad5a12775be69f4a8dd663b20f103

  - Installing phpunit/php-file-iterator (dev-master acd6903)
    Cloning acd690379117b042d1c8af1fafd61bde001bf6bb

  - Installing phpunit/php-code-coverage (1.2.x-dev 3a60a66)
    Cloning 3a60a660998e8d41d5ea81ff8d96ead546bce150

[RuntimeException]
Failed to execute git checkout '3a60a660998e8d41d5ea81ff8d96ead546bce150' &
& git reset -- hard '3a60a660998e8d41d5ea81ff8d96ead546bce150'

error: Untracked working tree file 'Tests/PHP/CodeCoverage/FilterTest,php'
would be overwritten by merge.

のようにエラーになります。

事件その3: Issueが光の速さで取り消される

ともかく事は重大そうなので、PHPUnitにIssue登録した方が良いかなと思ったので、投稿したところ、ものの数秒でそれはcomposerとか環境の問題でPHPUnitじゃないよ、と返ってきました。

Can’t install 3.7.x to Linux environment by composer

ちょっと慌てていたので、あまり確認しなかったのも良くないなと思い、ここから検証作業の開始です。

原因を調べてみた

まず、その週末にPHPUnitのgithubを見たところで、デフォルトブランチ(master)が4.0系になっているよ、という事に気がついていました。

ここで composer がどのようにライブラリを取得するか考えてみたところ、

• packagist からリポジトリ情報をダウンロード
• phpunit/phpunit と一致するソースコードリポジトリからダウンロード（この場合はgithub）
• git clone git@github.com:sebastianbergmann/phpunit.git が実行される
• リリースを指定しているので一致するタグがチェックアウトされる git checkout ....

この最後のステップで「Untracked working tree file」になり失敗するのです。

PHPUnitのリポジトリを見てみると、3系まではディレクトリ名が Tests だったのですが、 4系では tests のように小文字に変更となっています。大文字、小文字問題か！と意気たったのが、先程の Issue なわけですが。

自分の環境だけかなーと思って、隣の人にちょっとインストールしてみてもらえないか頼んでみたところ、成功…. えぇぇー！

その環境は Vagrant上のCentOSでなく、素のWindowsでした。 何かがおかしい….

そこで偶然なぜか思ったのが、とりあえずディレクトリ変えてみるか、という事。とりわけ何か理由があった訳でなくたまたまそう思っただけなのです。

composer update （この日は何度実行したろう….） …… 成功した！！！！でも、なんで？！

違いに悩むと…

成功したところ：

• 素のWindows
• Vagrant仮想環境内の /tmp/work/app

失敗したところ：

• Vagrantのsyncfolderである /var/www/html/yourapp/app (CentOSから見えるディレクトリ) windows上だと c:¥develop¥your_app¥app みたいなところ

もしかしてVagrantでマウントしているWindowsディスク上だと大文字、小文字の変更をトレースできなくなるのでは！！

という結論に至り、他の人で同様にVagrantのsync_folder環境で試したらダメでした。

まとめ

ホストがwindowsでゲストがLinuxということはあると思うのですが、ディスク同期してそこにソースコードを置いてエディタはホストOS上で実行は仮想環境上みたいな開発するのは今後も増えてくると思います。 その中で今回のような事象に陥ることは composer + PHPUnit に限らず起きそうだなと思いました。

上記のような Failed to execute git checkout ... エラーが出た時に、あぁそういう事かと心構えができていれば慌てず、一旦ホストOS側で作業するとか、仮想環境上のsync_folder以外で作業するなどやりようがあるかな、と思います。

まぁ慌てず騒がず、落ち着いて対応しましょうという良い教訓になりました。twitterなどでお騒がせしてすみませんでした…

ブログを Middleman で作る（厳密に言うとmy.opera.comから移行）するにあたり、いくらかハマりポイントがあったので、メモとして残しておきます。

参考になったサイト

以下のサイトを参照しながら、作業を実施しました。

• Middleman公式
• middlemanの設定
• GitHub Pagesで独自ドメインを使う方法
• rbenv を使って ruby をインストールする(CentOS編)

HTMLジェネレータは何を使うの？

ブログを移行するにあたり、利用可能なフォーマットは WordPress互換フォーマット ということで、「WordPressで良くない？」とか、「my.opera作った人がスピンアウトして作ったサービスがあるらしいよ」とか様々な誘惑があったものの、今時は GitHub Pagesでやるんでしょ？という勝手な妄想（実際そういう人が増えているわけですが）から、そうなれば静的サイトジェネレータが必要だなぁと。

最初に思いついたのはChatWorkが作成したPHP製のデザイナ向け静的サイトジェネレーター「Phest」だったのですが、前提となるWordPressフォーマットからの変換どうするかなーと思っているうちに、気持ちは他のものへ….

で、GitHub Pages ブログ なんてキーワードで検索すると出てくるページと言えば Octopress jekyll あたりなわけです。もちろん jekyll にしておくと GitHub Pagesの公式にも出てくるぐらいで良いなーと思ったのですが、世の中の流れは Middleman みたいな記事をいくつか見かけるうちにすっかりと方向は Middleman に決まりました。それに WordPress XMLからインポートできるプラグイン Wordpress to Middleman Exporter があるということ。

Middleman インストール

しばらく ruby の環境とか触ってなかったので、一番最後の記憶を頼りに「まずは RVM + bundler で環境構築やー」と意気込んで Gemfile に middleman を追加して bundle installを実行したところ、うんともすんともならずインストールできない…. もう今時はRVMじゃないのかな? と思っていたら、rbenvなんですね。そうですか、そうとわかればすぐに切り替えて参考サイトを参照しながら呆気なく構築は完了。

gem install middleman

でインストールも楽々完了です。

ブログモジュールを使うので、middleman の Gemfile に

gem "middleman-blog", "~> 3.5.1"

を追加して

bundle install
middleman init blog --template=blog

と実行すると blog ディレクトリに環境が生成されます。

WorkPress からのインポート

my.opera から WordPress 互換 フォーマットのファイルをダウンロードして、画像やらも全部ダウンロード。 いよいよ先程の変換ツールで実行…. エラーだよ！！（泣）

rubyのエラーだったので、調べて直す事もできたのかもしれないのですが、そのとき思ったのは「要はWordPress.xml をmarkdownに変換すれば良いのだから他にもあるんじゃない？」という誘惑。 イロイロ調べたところ、

• wp2middleman
• wordpress-to-jekyll
• ruby-wpdb
• wp_conversion

などがあるようで、とりあえず1つずつ試みるという泥臭い作戦に。 どれもうまくいかない….

python系のライブラリもあるらしく

• wp2md
• prlican-import
• exitwp

順番に試して行くと、exitwp がいくつか失敗するものの良い感じに変換できることがわかった。 しかしいくつか失敗する… なんでだろうと思っていたところで、もう一度my.operaのクローズ本文を読んでいたら WordPress 互換 フォーマットなんですよ。「互換」….. もしかして、WordPressに取り込んで、そこから再度エクスポートすると「互換」じゃなくて「正式」なXMLになるんじゃないか！と

WordPress インストール

ちょっと迂回している感じですが、PHPの環境は手元にいくらでもあるのでテキパキとインストールしてXMLをインポート、何もせずそのままエクスポート。2つのファイルを diff で比較してみると確かにちょっと違う。 これを先程一番うまく変換できた exitwp にかけると…….

あらー全部奇麗に変換できるじゃないですかー

デザイン

ここまで来ると後は erb と css なので、既存のmy.operaから html, css, js やらをすべてダウンロードして erb を html と同じになるように編集し、cssとjsも不要な部分を取り除いて設置。

middleman server

で見た目を確認しながら調整して CNAME ファイルも設置。

GitHub Pages へデプロイするために Gemfile に

gem "middleman-deploy"

モジュールを追加して bundle install。

config.rg に

activate :deploy do |deploy|
  deploy.build_before = true # default: false
  deploy.method = :git
  deploy.branch   = "master" # default: gh-pages
end

な感じで設定したら

middleman deproy

でビルドした内容をgithubへ連携してくれます。

今後

ローカル（手元）のmiddleman使えば簡単にデプロイまでできるのですが、たまたま外で自分のPCじゃないときとか、githubにmarkdownをpushしたらビルドしてGitHub Pagesにデプロイしてくれたら良いな、とか思っているので、そのあたりはこれからやっていこうと思います。