概ね最新版で大丈夫でしょう。Chefをクローン(またはダウンロード)します。upを実行してしばらく待ちましょう。READMEに書いてあるので、そちらを参照してください。completeなメッセージが出て、コンソールが戻ってきたらインストールの完了です。アクセスしてみてください。デフォルト画面が出たら環境構築の完了です。CakeにCakePHPの環境を作るスケルトンコマンドが別途用意されているので、レシピの編集は必要ないです。生成したVagrant環境にログインします。Vagrantfileのようになっていて、すでにappディレクトリが存在します。ここには先程のデフォルト画面が入っているのですが、今回は新しくアプリを作成するのでappディレクトリは削除します。いうリポジトリがあります。CakePHP3用のスケルトンも(cake3ブランチとして)用意されているので、GitHubのREADMEに書いてあるとおりのコマンドでCakePHPのアプリケーション環境を構築します。部分がアプリケーション名です。Chefを使った場合はappを指定してください。最後に上記のような確認メッセージが出てくるので、履歴が気にならなければそのままEnterを押して終了します。アクセスしてみてください。おなじみのCakePHP画面が表示されます。tmpディレクトリが書き込みできないと警告されます。app/tmpなどのコマンドで権限を書き換えてください。いうデータベースが生成されています。文字コードの指定などの問題もあると思うので、ここは自分でデータベースを作成します。rootパスワードは、vagrant-chefのREADMEを参照ください(現時点ではbananasです)。utf8_general_ci;続けておなじみのpostsテーブルを作成します。AUTO_INCREMENT=1;app-templateで作成したCakePHPアプリケーションは、php-dotenvというライブラリを使って環境設定できるようになっています。app/App/Config/.envファイルを作成します。CAKEDATABASE_TEST_URL="mysql://root:bananas@localhost/test_cake3_mokumoku?encoding=utf8"のように書き換えます。AD7six/php-dsnを参照ください。%>@localhost/test_database_name?encoding=utf8";のような指定がされているため、設定値が重複してしまいfastcgi側が優先される仕組みとなっています。このため異なる名前に変更しておきます。合わせて、app.phpでDATABASEURLを利用している箇所もCAKEDATABASEURLに変更します。"$@"のように変更してください。オプションがあるとうまく動作しないためです。--helpのように表示されるはずです。Postsで生成します。うまく動作するようです(執筆時においては)。最後にこのブログはもくもく会から2週間ぐらい経過してしまいましたが、今回再度新しい環境を作って試しています。会のときも同様の手順で進めていたのですが、いくらかbake周辺でコードの変更があったようで、うまく動いていた箇所が動かなくなっていたり、動かなかった箇所が動いていたりします。開発者用のプレビュー2ということで、今後もコードは変わって行くと思いますが、Bakeが動く事で取り急ぎ動作するプログラムのベースは作れるようになっています。実際にアプリケーションを作ってみてCakePHP3の新機能について感想を書いてみたり、要望を出してみたりすることも実リリースまでの期間としては大切なことだと思うので、今回簡単ではありますがブログとして公開してみました。CakePHP3もくもく会が開かれると思うので、イベントページをチェックしておくと良いと思います。私も可能な範囲で参加していこうと思っています。ComposerComposerにはautoloadを自動生成する機能があり、これを利用するとrequire_onceなどを使わなくとも自動的にソースコードがロードされます。言葉のとおりautoloadですね。autoload機能を使うとクラスが利用可能になります。以下のような定義を記述してみましょう。更新するコマンドを実行します。いう結果が表示されてautoload定義が更新されます。'/Controller/PostsController.php',);今回は予めpostsテーブルからbakeしてPostモデルとPostsコントローラを生成しておきました。すると、App::uses()を記述しなくても、composerのautoloadがクラス名からPHPファイルを自動解決してくれます。App::uses()の記述が多過ぎてコードの見通しが悪い場合などに利用を検討されてはいかがでしょうか?この他にもComposerのautoload機能はPSR-4PSR-0Files(ファイルを直接指定できる)include-path(どうしてもphp.ini的なincludeパスで解決しなくてはならない時のためにある)といったパス解決方法を用意していますので、namespaceが入ったものなどのサポートも万全です。Composerの公式ドキュメントのautoloadを参照ください。Vol.1」で「Webアプリケーションテスト手法2014」の発表をしました。第一回目ということと、1時間枠と限られた時間の中でCakePHPとJavaScriptについてのテストの話をしたので、ざっくりした内容となっています。今後ハンズオンなども計画しているようなので、DoorKeeperのページをチェックしておくと良いかなーと思います。当日は「Java,PHPエンジニアの派遣、求人を探すならJapheego(ジャフィーゴ)」さんに懇親会スポンサーになっていただき、美味いビールとSUBWAYのサンドイッチをいただきました。file最後に、当日紹介したサンプルのCakePHPテストコードを掲載しておきます。}}モデルの初期化方法には3つのやり方があり、通常はClassRegistry::init()で良いのですが、モデルをモックしたい場合はgetMockForModel()というCakeTestCaseが用意してくれているモデル専用のモックジェネレータを使います。第二引数にメソッドの配列を指定するとパーシャルモックとなり、特定のメソッドのみモックします。}}コントローラのテストをするとき、testActionメソッドを呼び出すわけですが、そのときコントローラ自体をモックするにはControllerTestCaseが用意してくれているコントローラ専用のモックジェネレータであるgenerate()を利用します。generateで作成したインスタンスをテストケースクラスのcontrollerメンバ変数にセットすることでControllerTestCaseがURLからディスパッチするときに、このモックオブジェクトを利用してくれます。コントローラから依存関係にある、コンポーネント、モデルについてそれぞれサンプルのようにモックでき、コントローラ自体のメソッドもmethodsに列挙することでモックできます。redirect()やrender()などがよく使われると思います。PMCakePHPあるURLや特定のパラメータ、ユーザでアクセスされたとき、プレフィックスルーティングを付けたかったので、動的に付与したらハマったので小ネタを書いておきます。array('site-proxy'));のように記述します。使って追加できることがわかります。出力されるURLにプレフィックスルーティングが追加されます。値になることがわかります。$url;}のようになっていて、要は現在のURL($this->query)から再生成されるだけです。リクエストに入っているプレフィックスルーティングの設定は参照されず、プレフィックスなしのURLがformタグのactionに入ってしまいます。'/admin/this/interesting/index',))あたりが良さそうです。phpunit現在以下のような環境を設置して開発をしています。Bddプラグインから依存関係にあったライブラリが行方不明になっていました。以前はpearにあって、あるときからgithubに移行していたはずなのに、どこにも痕跡を残さず消滅していました。どこで使っているかというと、Bddプラグインの単体テストモジュールにあたるSpec-PHPです。"*"のように指定していました。OSX環境+BddExampleAppで確認)と安心して月曜日出社したのです。その週末にPHPUnit4.0のコードがGitHubのデフォルトになりはじめたあたりでした。"3.7.*"のように入っています。merge.のようにエラーになります。Issueが光の速さで取り消されるともかく事は重大そうなので、PHPUnitにIssue登録した方が良いかなと思ったので、投稿したところ、ものの数秒でそれはcomposerとか環境の問題でPHPUnitじゃないよ、と返ってきました。composerちょっと慌てていたので、あまり確認しなかったのも良くないなと思い、ここから検証作業の開始です。原因を調べてみたまず、その週末にPHPUnitのgithubを見たところで、デフォルトブランチ(master)が4.0系になっているよ、という事に気がついていました。file」になり失敗するのです。Vagrant上のCentOSでなく、素のWindowsでした。何かがおかしい....そこで偶然なぜか思ったのが、とりあえずディレクトリ変えてみるか、という事。何か理由があった訳でなくたまたまそう思っただけなのです。みたいなところもしかしてVagrantでマウントしているWindowsディスク上だと大文字、小文字の変更をトレースできなくなるのでは!!という結論に至り、他の人で同様にVagrantのsync_folder環境で試したらダメでした。まとめホストがwindowsでゲストがLinuxということはあると思うのですが、ディスク同期してそこにソースコードを置いてエディタはホストOS上で実行は仮想環境上みたいな開発するのは今後も増えてくると思います。限らず起きそうだなと思いました。エラーが出た時に、あぁそういう事かと心構えができていれば慌てず、一旦ホストOS側で作業するとか、仮想環境上のsync_folder以外で作業するなどやりようがあるかな、と思います。慌てず騒がず、落ち着いて対応しましょうという良い教訓になりました。