参加してCakePHP3ベータ1を早速試しました。テンプレートから生成しなおします。最新のcakephp/appテンプレートにはDebugKitプラグインが依存関係に入っています。},require-devではないのですね、と思ったり。以下のコマンドでCakePHP3アプリケーションのプロジェクトスケルトンを作ります。appブラウザでアクセスすると、以下のような画面が表示されます。なんかDebugKitがSQLiteを参照しているみたいなんですよ。]);}そうですか、そうですか...githubのCakePHP3用ブランチもチェックしてみました。Datasourceに以下のようなdebug_kit接続を追加してみます。(length=9)上記のようになっています。2と3誰よ....ということで、まだベータ1だからねー。はははーという事で、現時点はSQLiteのextension入れて試しましょう。friendsofcakeのvagrant-chef使っているなら、cookbooks/php/recipes/install.rbに追加します。"php5-sqlite",mysqlの下あたりに追加します。destroy/upを実行して環境を作り直したら、もう一度ブラウザをリロードします。おなじみの青いバーの画面が表示されました。画面の右下に出ているCakePHPアイコンがDebugKitです。アイコンをクリックすると以下のようにデバッグ情報を参照可能になります。DebugKitも使えるし、どんどんCakePHP3のアプリケーション開発がやりやすくなっていると思います。春先ぐらいからBlogの更新が滞っていましたが、その要因となったアレが大分落ち着いてきたので、たまっていたネタを順番に書き出します。でかい画像を付けましたよ。CakePHPで学ぶ継続的インテグレーション共著者の@kaz_29さんのブログ@ryuzeeさんのブログでも既に紹介されていますので、そちらを一読いただくと理解が深まります。私は主に以下のあたりを担当しました。上記以外でも、おおよそCakePHPに関連するところを書いたと思っていただければ。これは何の本タイトルの通り、と言いたいところですが、わからないという人のために補足すると継続的インテグレーションの入門書ですCakePHPでのアプリケーションの作り方を解説した本ではありませんサンプルアプリケーションの構築、自動テストの作成方法の解説にCakePHPを使っていますタイトルや見出しから内容が想像しずらいと思うので、私が書いた部分の継続的インテグレーションに関する技術的キーワードを列挙すると、以下のとおりです。Usersプラグインも使っています。自分が作ったプラグインであるBDDとFabricateを採用していますが、これは現在支援を行っている現場でも活躍しているので手前味噌というだけでなく、自動テストを継続していく上で役立つと思います。私の記述したところの、ざっくりした解説は以下のとおりです。ComposerとMigrationsプラグインを使うと、誰でも簡単に同じ環境を構築することができるようになります。Environmentsプラグインを使うと、環境毎の設定切り替えや、振る舞いの制御を容易にできるようになります。BDDプラグインを使うとCakePHPからBehatとの連携が容易になり、受入テストの自動化に取り組みやすくなります。Fabricateプラグインを使うとFixtureを使ったテストデータの呪縛から解放されます。これらは過去から現在に至るまで、私が様々なプロジェクトで経験したことを背景にしています。プロジェクトごとに様々な背景があると思いますが、一度実践していただければ効果を体感していただけるのではないかと思っています。PHP界隈ではまだBDDやATDDに関して、解説する本がなかったり、実践的な解説がなかったのですが、本書がこれらを導入するきっかけになると嬉しいなと思っています。CakePHP以外ではどうなのサンプルアプリケーションの構築にはCakePHPを利用していますが、上記の技術要素に関しては他のPHPフレームワークでも同様のものがあると思います。CakePHP以外のフレームワークに精通していれば、Behatを直接使ったり、データジェネレータにFakerの機能を使ったり、各フレームワークのマイグレーションや環境切り替えプラグインを使ったりできるのではないかと思います。皆様の現場の状況に合わせて読み替えて、継続的インテグレーションを導入する参考にしていただければ幸いです。いつ発売なの?amazonでは2014/09/19(金)に発売です。書店などでは多少前後することがあると思いますが、ぜひ一度手に取ってみてください。9/19は、茅場町Co-EdoにてCakeFest2014報告会を実施します。先月実施されたCakeFestではどんな事があったのか、CakePHP3の動向などを話しますので、ぜひこちらにも参加ください。お知らせと感謝(追記)CakePHP3の話題もあるなか、まだまだ現場ではCakePHP2を利用するケースもあると思います。本書をきっかけにCakePHPをより学んでみたいなと思っていただけたら、私も共著者で参加したCakePHP2実践入門(amazonでチェック)を参考文献として手に取ってみてください。長い間CakePHP2の参考書として手に取っていただいているようで、本当に嬉しいです。ありがとうございます。継続的インテグレーション春先ぐらいからBlogの更新が滞っていましたが、その要因となったアレが大分落ち着いてきたので、たまっていたネタを順番に書き出します。CakePHP2のプラグインを作成/公開していて、継続的インテグレーションってどうするの?と思っていました。Requestを送ってくれれば、developブランチに取り込んでテストしたりします。Githubを徘徊していると、よく見るこれを表示したいと思ったのです。CakePHP2のプラグインは当然それだけではユニットテストを実行できません。CakePHPのアプリケーションがあって、テスト用データベースとその設定があって...、ぬーん。早い話、テスト用のアプリケーション作って、そこからテスト実行すれば良いの?ということをずっと思っていました。CakePHPの有名プラグインはどうしているのだろう?と思い、最初にチェックしたのはCakeDC/searchプラグイン。アプリケーションで使う、もっともメジャーなプラグインではないかと思います。Searchプラグインにも、あのビルド成功やダウンロード数、バージョン番号の画像が表示されています。ファイルがあるので、内容を確認してみます。fihttps://github.com/burzum/travis.gitをcloneしてきて、何かやっているようです。CakePHPプラグインを簡単にTravis.ciで継続的インテグレーションできる早速、ページにアクセスしてみると、どうもそれはあのFriendsOfCakeからForkされたもののようです。FriendsOfCakeの元リポジトリを確認します。requirements.おぉ、正に私の求めていたもの。Fabricateに導入してみた最近作った中で、最も思い入れのあるCakePHPプラグインFabricateを継続的インテグレーションするため、上記のFriendsOfCake/travisを導入してみます。Installに書いてるとおり、以下の手順で進めます。細かい事は気にせずですね。実行すると、以下のファイルが自動生成されます。プラグインのユニットテストをすべて実行するテストスイート。この命名規則で生成されていれば作られません。以前のバージョンでは.editorconfig.semver.travis.yml.AllPluginNameTest.phpcomposer.jsonCONTRIBUTING.markdownLICENSE.txtREADME.markdownが生成されていましたが、継続的インテグレーションには必要がないファイルも混在していたので、整理されたものと思います。後はTravis.ciにサインアップして、リポジトリを追加するだけです。実は、これが最初のビルド。PLUGIN_NAMEをexportしていなかったので、正しくテストの実行が動いていませんでした。PLUGIN_NAMEはちゃんとexportするようにした方が良いです。.travis.ymlのPLUGIN_NAMEをFabricateに設定して実行した結果が以下の画面です。現在のtravis.gitではPHP5.4以上のようなので、問題ないのですが、当時(と言っても数ヶ月前)はPHP5.3もテスト対象になっていたので、ショートArrayシンタックスを使っている私のコードはテストが失敗していました。5.5pushすると、ビルド結果は以下のようになります。PHPCS以外は成功しています。PHPCSではCakePHPのコード標準がチェックされます。CakePHPの標準コードチェックだと厳しい部分だったり、パラメータを変更してチェックさせたくないディレクトリがあったりすると思うので、PHPCS_ARGSでphpcsを実行するときのパラメータを上書きできるようになっています。."拡張子phpのファイルを対象とし、TestやVendorのディレクトリを対象外として実行します。ruleset.xmlは以下のようにしました。</rule></ruleset>CakePHPのコード標準ではprivateやprotectedの変数、関数の先頭にアンダースコアが求められるので、それを無効にしたのと、キャメルケースではない変数や関数名を使いたい箇所があったので、それを無効にしています。最後のCakePHP.WhiteSpace.TabAndSpaceでは、以下のように=のインデント位置を合わせたコードがエラーになってしまうので、無効にしています(わかりづらいですが、=の位置が揃っています)。[];}どうなっているのか?プラグインのリポジトリには.travis.ymlが追加されるぐらいです。この設定内で、FriendsOfCakeのtravisリポジトリがcloneされ、以下に記述されている手順が実行されます。../travis/after_success.sh実行されるパターンは.travis.ymlに記述されているphpとenv-matrixの組み合わせと、matrixのパターンになります。PHPCS=1この6パターン毎に、before_script、script、after_successが呼び出されます。事前準備before_script.shは実行準備のためのスクリプトで、PHPCSが1にセットされている場合は、以下のとおりpearチャンネルからCakePHPのコード標準とphpcsが依存関係としてインストールされます。0fi続いて、CakePHP本体が1つ親のディレクトリにインストールされます。Travis.ciではプラグインのリポジトリが最初にcloneされるのですが、結果として以下のようなディレクトリ構成となります。依存関係を解決します。COVERALLS用のカバレッジレポートも生成されるようにファイルが準備されます。実行script.shがPHPCSが1の場合はphpcsを、それ以外の場合はユニットテストを実行します。実行が成功したらafter_success.shがCOVERALLSのカバレッジレポートを生成します。最初のスクリーンショットがFabricateの現在の状態です。すべて成功しています。最後にREADMEにバッジを表示させる方法を紹介します。Travis.ciのバッジを表示するTravis.ciの画面にアクセスしてbuild:failingのように表示されている画像をクリックします。ブランチを選択して、表示形式からマークダウンを選択したら、表示内容をREADME.mdに貼り付けます。カバレッジのバッジを表示するカバレッジはCOVERALLSというサービスを使って表示します。サイトにアクセスして、サインアップはGithubのアカウントでできるの簡単です。REPOをクリックしてリポジトリを追加します。その後、追加したリポジトリのページを表示します。URLというボタンをクリックします。このあたりのUIは統一されると嬉しいですね...いろいろな記述形式のコードが表示されるのでマークダウンのコードを選択してREADME.mdに貼り付けます。ダウンロード数、バージョンを表示するここからはCIとは関係ないのですが、よく見るバッジであるダウンロード数とバージョン番号も表示してみたいと思います。Poserというサイトにアクセスします。ダウンロード数やバージョン番号は、Packagistで表示されている情報を画像に変換するので、リポジトリがPackagistに登録されていることが条件となります。Badgesにダウンロード数を表示したいPackagistのパッケージ名を入力します。表示形式からマークダウンを選択して、コードをREADME.mdに貼り付けます。最後にCakePHPのプラグインを継続的インテグレーションする方法は、実はとても簡単でした。これを機に、まだプラグインを継続的インテグレーションしていないそこのあなたも、Travis.ciとCOVERALLSを使って継続的インテグレーションをしてみましょう。#5」に参加しました。前回のイベントではBakeすることに成功したので、今回は大きく変更となったモデル周辺についてテストコードから把握してみる目標をたてました。いうリポジトリがあります。CakePHP3用のスケルトンも(cake3ブランチとして)用意されているので、GitHubのREADMEに書いてあるとおりのコマンドでCakePHPのアプリケーション環境を構築します。dev-cake3のように記述したのですが、その後devが上がったところでこちらのスケルトンは最新追従していなかったので、CakePHPの公式スケルトンを使っています。dev-cake3CakePHP3におけるモデルCakePHP3では従来モデル(Model)と呼んでいたクラスはなくなり、テーブル(Table)とエンティティ(Entity)という2つのクラスに別れます。従来のモデルがテーブルに変更になりfindなどの責務を持っています。find結果は従来arrayで返却されてきたのですが、CakePHP3からはエンティティと呼ばれるオブジェクトで返却されます。CakePHP1から2にかけてbasukeさんが作られたCakeEntityというプラグインがあります。このプラグインはCakePHP3の新しいモデルのベースになったものでもあり、利用したことがあればそれほど違和感なく移行できるのではないかと思います。];}のようになっています。PostsTable::initialize()は従来publicプロパティとして定義していたテーブル名などの情報です。validationDefault()は$validatesで定義していたバリデーション定義です。Postクラスはエンティティで$accesibleに利用可能なフィールド名を列挙します。これはRailsでattraccessorを定義するとプロパティにアクセス可能になるのと同様の効果を持つようになると推測されますが、現時点では何も実装はされていないようです。}とてもザックリしたところを切り抜きましたが、まぁそういうことです。なんか聞いている程変わってないですよね。findやwhere,orderなどのメソッドがあり、それをチェインさせてクエリを組み立てるようです。これも他のActiveRecord系の記述とほぼ変わらない形式になります。hydrate(false)を指定するとエンティティでなく従来の配列形式で値を戻すことができるようになっています。メソッドチェインの最後のtoArray()はエンティティを配列形式で取得するという意味ではありません。CakePHP3からはfindの戻りがイテレータになります(配列ではないので注意が必要)。イテレータからすべて配列形式で取得するという意味になります。いくつかそれ以外の例を見てみましょう。->order('id');たとえば取得するカラムを絞り込むためにはselect()を利用するようです。従来はfieldsで指定していたカラム名の配列です。->order('id');とはいえ、従来っぽい書き方もできるようです。findがチェインの中で2回呼ばれています。これがCakePHP3のモデルだ!findが2回とはどういうことなのか、ソースを調べてみました。何ですか?を返すみたいです。呼ぶとfindAllメソッドがあるかどうか(ビヘイビアも含めて)調べて、なければ例外になる。}あるよ!そういうことか、これがCakePHP3のモデルか。条件やら何やらメソッドチェインである旧来の配列形式に変換できるfindXxxで独自の条件などをメソッドチェインに組み込める(今ココ)独自の条件をメソッドチェインに組み込むまずPostsテーブルにfindOrderIdDescというIDの降順で検索するメソッドを作成します。$this->Posts->find('all')->find('orderIdDesc')->all();みたいに書けるわけです。いくつチェインしても良いです。様々なテーブルで利用できるファインダ(findXxxメソッド)をtraitで共通化するもの面白そうです。このように新しいモデルはかなり期待の持てる作りにもなっています。CakePHP3もAlphaになりました。Tokyo#2」に参加してきました。当日は1回目の反省をふまえて以下の仕様について実施することとなっていました。JapanのHayatoさんがSpecを書いているので、テストがマージされやすいんじゃないか?!という不純な動機と、仕様が難しいので参加者が少ないかな?という妄想からでした(ただ実際は一番人気でした!)。そもそもこの活動は何なのか?というと、みんなでHTML5やCSS、API仕様のテストケースを書こうというミートアップですと書いてある通りです。私たちWebに関わるデベロッパーであれば必ず利用するHTMLやCSS、ブラウザによって実装がマチマチでとか、IEがぁーとか言ってますよね。なるのか?まずHTMLとかCSSはW3Cの仕様があってそれを各ブラウザベンダが実装するわけです(もちろん先に実装されているケースもあります)。結果としてどのように見えるのか?という部分に関して言うと、特にこうなるべきという具体的な結果が書いてある訳ではありません。なると各ベンダは自分の実装は正しいと思ってリリースするのですが、それぞれバラバラだったという結果が起きるのです。そのため、W3Cではテストの充実に力を入れているのですが、現時点ではリソース不足であったり、そもそもスペックの理解不足という自体が起こります。W3Cのスペックを読んだことがあると何となく想像できるかな、と思います。Forwardという公式イベントや、今回のようなコミュニティ主導のミートアップでテストコードを充実させようという機会が増えてきています。Forwardのドキュメントを見れば、今時のWebデベロッパーであれば問題なく環境を構築することができます。必要なのに漏れていた(これについては今回のミートアップでPRが出されてマージされたはずです)り、ちょっと面倒なのですがまぁ問題ないでしょう。そのうちVagrantファイルでも作ろうかなーと思っています。ここまでは事前の準備としてやっておきました。当日やったことW3Cのスペックを見ましょう。Itoさんから仕様の説明を受けて進めるという流れだったのですが、それにしても仕様がむずい。新しいテストケースはちょっと置いておき、既存のテストを流してみることにしました。これはすぐ取り込まれました。しているテストについて、スペシャリストの方に確認して修正方針を聞いたりして、テストを黙々と書いていきます。1日作業でしたが、2つのテスト失敗を修正してタイムアップ。DOMはtestharness.jsでDOMのテストをする段階でした。記法になっていて、キモい!という話をしたら、開発者がmozilla系の方でfire方面ではそういう記述になっているという話を(FireFoxのcontributorの方から)伺うことができました。これもミートアップでこその体験です。モダンなテストの書き方という意味では、サーバサイドスクリプトとか今時のJavaScriptのテスティングフレームワークの方がイケてる感じにできますが、これも歴史的な背景(DOMの細かい評価をするのにtestharness.jsが最適であるという理由)ということです。今後についてはわからないけど、各ブラウザベンダなどがテストするときに利用しているということで変更(例えばJasmineに変えるとか)には高い壁があるのかもしれないです。最後にW3Cの活動に貢献する作業は今後も続けて行きたいので、ミートアップなくてもテストコードを書き続けて行きたいとおもいました。metaデータの書き方とかちょっと特殊なところもあったので、新しくやる場合は既存のテストコードをいくつか参照して、書き方のテンプレート部分を把握した方が良いと思いました。氏が初来日ということで基調講演を聴く事ができました。2年間かかって作ったという最高傑作テストケースを見てスペックのテストとは!を感じれたのも良かった。フォントもインストールしました。さん(ノベルティまでいただき感謝!)、スポンサー各社様の協力でとても楽しいイベント(部活)でした。