CakePHP Archive

2015/09/14に行われたDevLove関西にて「レイヤードアーキテクチャを意識したPHPアプリケーションの構築 ver2」を発表してきました。

このセッションは、PHPカンファレンス福岡で発表したものですが、DevLove関西主催の @yohhatu さんからお声がけ頂いて、再演を行いました。ただ、同じ内容では面白くないので、Laravelアプリケーション構築時に意識した点を掘り下げて資料を改変しました。

発表資料

発表資料は以下です。

アプリケーションコードをレイヤ分けする際に、ただのグループとして分離するのではなく、レイヤの責務を明確にする、そしてレイヤ間の依存関係（処理の流れ）を一方向にするのがポイントです。

さいごに

今回は、3 人のスピーカーだったのですが、発表内容を事前に打ち合わせしたわけでもないのに、私、@s_kozake さん、@OkaHiromasa さんの順に抽象度があがって、広いテーマになっていくという流れが面白かったです:)

お二人の発表はもちろんのこと、イベント後の食事会も合わせて、楽しい時間でした。ありがとうございました！

CakePHP2 アプリケーションを Heroku 上で動かす設定についてです。

以前のエントリにも書きましたが、Heroku で Web アプリケーションを動かす際に重要なのは、Web サーバ自体（Heroku では、Dyno）に、アプリケーションの状態（データ、セッション情報、ログ等）を保持させないということです。

Heroku の Dyno は、デプロイの際や、定常的な再起動により、破棄されるため、記録されたファイルは消えてしまいます。よって、こうしたデータファイルは、アドオンなど外部に記録する必要があります。

Heroku では、アドオンを活用するのがポイントですので、ここでは、主に CakePHP アプリケーションからこうしたアドオンと連携する方法を見ていきます。

Environments Library as a plugin

まず、開発環境と Heroku 環境で設定値を切り替えるために Environments Library as a plugin を使います。

https://github.com/josegonzalez/cakephp-environments

これは、CAKE_ENV という環境変数の値で、環境に応じて、データベースやキャッシュなどの設定を切り替えるものです。昨今のフレームワークではお馴染みの機能ですね。

ここでは、下記の設定について切り替えを行います。

• ログ
• データベース
• キャッシュ / セッション

このプラグインでは、まず Config/bootstrap/environments.php を作成します。このファイルで、環境毎の設定ファイルの読み込みを行います。下記では、Heroku 環境用の heroku.php と、開発環境用の development.php を読み込んでいます。

• Config/bootstrap/environments.php

<?php
CakePlugin::load('Environments');
App::uses('Environment', 'Environments.Lib');

include dirname(__FILE__) . DS . 'environments' . DS . 'heroku.php';
include dirname(__FILE__) . DS . 'environments' . DS . 'development.php';

Environment::start();

次に、Heroku 環境用の Config/bootstrap/environments/heroku.php です。

環境の設定は、Environment::configure() で行います。第一引数に環境名（CAKE_ENVで指定するもの）、第二引数は適用条件（true なら、CAKE_ENV に合致しなければデフォルトとして適用）、第三引数に設定値の連想配列（Configure::write() する）、第四引数にコールバックを指定します。

第三引数で設定する方法もあるのですが、より柔軟な設定を行うために、ここでは、第四引数のコールバックを指定します。実際の設定は、以降で順に指定していきます。

• Config/bootstrap/environments/heroku.php

<?php
Environment::configure('heroku', false, [
], function () {
    // Heroku 用設定
});

開発環境用の Config/bootstrap/environments/development です。コールバックで、デフォルトの設定を記述しています。

• Config/bootstrap/environments/development.php

<?php
Environment::configure('development', true, [
], function () {
    // Log settings
    App::uses('CakeLog', 'Log');
    CakeLog::config('debug', array(
        'engine' => 'File',
        'types' => array('notice', 'info', 'debug'),
        'file' => 'debug',
    ));
    CakeLog::config('error', array(
        'engine' => 'File',
        'types' => array('warning', 'error', 'critical', 'alert', 'emergency'),
        'file' => 'error',
    ));

    // Database settings
    Configure::write('DATABASE_OPTIONS', [
        'datasource' => 'Database/Postgres',
        'persistent' => false,
        'host' => 'localhost',
        'login' => 'shin',
        'password' => '',
        'database' => 'app',
    ]);

    Configure::write('TEST_DATABASE_OPTIONS', [
        'datasource' => 'Database/Postgres',
        'persistent' => false,
        'host' => 'localhost',
        'login' => 'shin',
        'password' => '',
        'database' => 'app_test',
    ]);

    // Cache settings
    Cache::config('default', array('engine' => 'File'));
});

次に、database.php での接続情報を、環境ごとに設定できるように下記のようにします。各環境ファイルで Configure::write()
した値を、DATABASE_CONFIG クラスに設定します。

• Config/database.php

class DATABASE_CONFIG {
    public $default = [];
    public $test = [];

    public function __construct() {
        $this->default = Configure::read('DATABASE_OPTIONS');
        $this->test = Configure::read('TEST_DATABASE_OPTIONS');
    }
}

このプラグインを有効にするために、bootstrap.phpを以下のように変更します。コメント部分は削除しています。

• Config/bootstrap.php

<?php
require_once __DIR__ . '/../vendor/autoload.php';

include __DIR__ . '/bootstrap/environments.php';

Configure::write('Dispatcher.filters', array(
    'AssetDispatcher',
    'CacheDispatcher'
));

Heroku で環境変数 CAKE_ENV をセット

このアプリケーションが、Heroku にデプロイした際に、heroku.php を利用するように、環境変数CAKE_ENVにherokuをセットします。これで、デプロイしたアプリケーションは、heroku 設定で動作するようになります。

$ heroku config:set CAKE_ENV=heroku

ログ

Heroku 環境でのログの設定です。ログは、ファイルではなく、標準出力もしくは標準エラー出力に出力します。

こうしておくと、heroku logs コマンドでログが確認できます。また、Papertail や FlyData のようにログを各サービスへ転送するアドオンを使うと、出力されたログを閲覧したり、S3 などに転送することができます。

ログは、まずは標準出力もしくは標準エラー出力にして、あとそれをどう活用するかは、アドオンに任せるという考え方です。

下記では、アプリケーションログを標準出力へ、エラー出力を標準エラー出力へ出力しています。

• Config/bootstrap/environments/heroku.php

<?php
Environment::configure('heroku', false, [
], function () {
    // Log settings
    App::uses('CakeLog', 'Log');
    App::uses('ConsoleOutput', 'Console');
    CakeLog::config('debug', [
        'engine' => 'ConsoleLog',
        'stream' => new ConsoleOutput(),
    ]);
    CakeLog::config('error', [
        'engine' => 'ConsoleLog',
        'stream' => new ConsoleOutput('php://stderr'),
    ]);
});

あとは、アドオンと追加すれば、出力されたログがアドオンで利用できます。例えば、Papertrailを以下のコマンドで追加して、アプリケーションを動作させると、Papertrail の画面でログが確認できます。

$ heroku addons:add papertrail

データベース

Heroku のデータベースといえば、PostgreSQL なので、Heroku Postgres を使います。（もちろん、MySQL が良ければ、ClearDB なり、RDS なり使えます。）

$ heroku addons:add heroku-postgresql

Heroku 内では接続情報が環境変数で渡されるので、これをパースします。パースされた情報を、heroku.php で、Configure::write() で、セットしていきます。

• Config/bootstrap/environments/heroku.php

<?php
Environment::configure('heroku', false, [
], function () {
    // Log settings
    (snip)

    // Database settings
    if (empty(getenv('DATABASE_URL'))) {
        throw new CakeException('no DATABASE_URL environment variable');
    }
    $url = parse_url(getenv('DATABASE_URL'));
    Configure::write('DATABASE_OPTIONS', [
        'datasource' => 'Database/Postgres',
        'persistent' => false,
        'host' => $url['host'],
        'login' => $url['user'],
        'password' => $url['pass'],
        'database' => substr($url['path'], 1),
    ]);
});

キャッシュ / セッション

キャッシュ / セッションのデータストアには、Redis を使います。

ここでは、Redis サービスのアドオンとして、Redis To Go を利用します。

$ heroku addons:add redistogo

データベースと同じく、接続情報が環境変数で渡されるので、それをパース（ホスト、ポート、パスワード）して、セットするだけです。セッションハンドラには、Cache を使いたいので、その指定も行います。

これで、キャッシュもセッションも、Redis To Go に保存されます。

• Config/bootstrap/environments/heroku.php

<?php
Environment::configure('heroku', false, [
], function () {
    // Log settings
    (snip)

    // Database settings
    (snip)

    // Cache settings
    if (empty(getenv('REDISTOGO_URL'))) {
        throw new CakeException('no REDISTOGO_URL environment variable');
    }
    $url = parse_url(getenv('REDISTOGO_URL'));
    Cache::config('default', [
        'engine' => 'Redis',
        'server' => $url['host'],
        'port' => $url['port'],
        'compress' => false,
        'password' => $url['pass'],
        'serialize' => 'php'
    ]);

    // Session Settings
    Configure::write('Session', [
        'defaults' => 'cache',
    ]);
});

さいごに

ベーシックな部分だけですが、Heroku で CakePHP アプリケーションを動かす設定を見てきました。

ここで紹介した以外では、メールやデータファイル（画像等）など、他にもアプリケーションでは必要なものがありますが、ほとんどのものは、ここで見てきたようにアドオンを活用することで実現できます。

こうした構成にしておけば、Dyno が再起動したり、インスタンス数を増減しても、アプリケーションデータはアドオンに保持されているので、動作に支障はありません。こうしたスケーラブルナ構成にしておくのが、Heroku のような PaaS を活用する肝ですね。

このエントリは、CakePHP Advent Calendar 2014 の 3 日目でした。まだ少し空き枠があるので、CakePHP な何かを書いてみてはどうでしょうか。

著者の @kaz_29 さんから「CakePHPで学ぶ継続的インテグレーション」を献本して頂きました。日頃から関心のある分野なので、早速読ませて頂きました。

PHP で学ぶ継続的インテグレーション

本書のタイトルは「CakePHPで学ぶ継続的インテグレーション」です。実際、本書の中では、CakePHPアプリケーションを題材に継続的インテグレーションを行う手法が解説されています。

ただ、ここで紹介されている継続的インテグレーションの手法は、CakePHP 固有のものではなく、他のフレームワークでも転用可能なものです。

勝手なお世話ですが、書籍のタイトルとしては、「PHPで学ぶ継続的インテグレーション」の方が、良かったかもしれませんね:D

分散された情報がこの一冊に

継続的インテグレーション（CI）を行うには、あるツールさえ入れておけばできるというものではなく、多くのツールを組み合わせる必要があります。

数年前、自社で CI 環境を構築した際は、Jenkins のインストールからはじまり、PHP向けのビルドタスクの組み込み、Git リポジトリの連携、自動テストの実行、結果レポートの出力、検証など、多くの手間がかかりました。一つ一つのツールについては、公式サイトのドキュメントなどで情報はあるのですが、それらを組み合わせて、自分達の開発プロセスに合うように一つのビルドプロセスとして、インテグレートするのが大変でした。

特に、PHP プロジェクトで CI を行う際に参考となる情報が少なく、Template for Jenkins Jobs for PHP Projects が、数少ないお手本というような状況でした。

本書では、こうした CI 環境を構築するのに必要なツール群について多くの解説があります。ざっと書きだしただけで、下記のようなツールに触れられています。

• Vagrant
• VirtualBox
• Chef
• CakePHP
• Jenkins
• Behat
• PHPUnit
• PHP_CodeSniffer
• PHPCPD
• PHPMD
• PHP_CodeCoverage
• phpDocumentor
• Composer
• Phing
• Capistrano

さらに加えて、CakePHP のプラグインもいくつか紹介されています。これらは、単にインストールして動かすということではなく、CI の流れで、それぞれのツールをどのように使うか、という視点で書かれています。

これまで、自分で細切れになった情報をかき集めて、ビルドプロセスを組み上げていく必要があったのですが、本書では、こうしたインテグレーションの一つの解法が記載されており、これから PHP プロジェクトで CI を行うには大いに参考になります。

すでに CI 環境を構築している場合も、それらを振り返り、改善していくための一つのパターンとして本書を参考にすることができます。

紹介されているツールを眺めてみるのも一つの面白さで、私は vagrant-chachier プラグイン をこの本を読んで使ってみようと思いました。

自分で CI 環境を作って、開発プロセスを実践

本書では、Vagrant を使って、自分の PC の中に仮想ホストを 3 つ、そして Github をアプリケーションコードのリポジトリとして利用するようになっています。

こうした環境構築では、実践する環境を作るのに手間がかかっていたのですが、Vagrant のおかげで仮想環境が楽に使えるようになったので、手軽に書籍の内容が実践できるようになりました。良い時代です。

仮想ホストは、開発環境（develp）、CI サーバ（ci）、本番環境（deploy）とそれぞれ役割が割り当てられていて、それぞれが Github のリポジトリをハブにして、アプリケーションのビルドやデプロイを行うようになっています。

全く同じ構成で良ければ、実際のプロジェクトにそのまま生かすこともできるでしょう。また、異なる構成でも CI として大まかな流れは似たものになるでしょうから、本書で得たノウハウを持って、自分のプロジェクトに CI を導入することができます。

実際に自分で手を動かして、CI 環境の構築、実践を行うことで、各ツールの役割や動きなどが実感として知ることができます。昨今は、Travis など SaaS のビルドサービスを使う場合も多いですが、自分で環境を作ってみることで、こうしたサービスもより理解が深まるのではないでしょうか。

サンプルコードの動かし方

書籍を読んで、記載されている手順を順に試すことで、CI 環境を構築することができます。はじめて、こうした環境を作るという方は、順に読み進めていくのが良いでしょう。

すでに CI 環境を利用している人は、公開されているサンプルコードを利用して環境構築を行うこともできます。私は、公開されているサンプルコードを使って、環境構築を行ないました。手順を記載しておきますので、参考まで。

事前準備

必要なツールです。以下は最低限必要になります。

• Vagrant
• vagrant-omnibus
• VirtualBox

ChefDk インストール

Berkshelf を使うために、ChefDk をインストールしました。これは、Berkshelf や Knife など Chef 関連のツール群をパッケージングしているツールで、ダウンロードして、パッケージをインストールするだけでツールを使うことができます。Berkshelf を gem で入れると、すんなり行けば良いのですが、環境によってエラーが発生したりするので、こうした手間を省くために利用しました。

OSX であれば、brew cask でインストールすることができます。

$ brew cask install chefdk

サンプルコード取得

サンプルコードは、アプリケーションと環境構築でリポジトリが分かれています。

はじめに、自分で push できるように両リポジトリを fork します。

そして、環境構築のリポジトリを cakephp_ci ディレクトリに git clone します。cakephp_ci ディレクトリに移動して、アプリケーションのコードをリポジトリから、application ディレクトリに展開します。

$ git clone 環境構築リポジトリ cakephp_ci
$ cd cakephp_ci
$ git clone アプリケーションリポジトリ application

Berkshelf でクックブック取得

Berkchelf でクックブックを取得します。下記は、brew cask でインストールした ChefDk に含まれる berks コマンドを利用しています。

$ /opt/chefdk/bin/berks vendor cookbooks

vagrant up で仮想マシンを起動

cakephp_ci ディレクトリには、Vagrantfile があるので、vagrant upで起動します。3 つのホストについて、起動、プロビジョンを行うので、しばらく待ちましょう。

$ vagrant up
Bringing machine 'develop' up with 'virtualbox' provider...
Bringing machine 'ci' up with 'virtualbox' provider...
Bringing machine 'deploy' up with 'virtualbox' provider...

Composer の実行

develop にログインして、composer install を実行します。

$ vagrant ssh develop
vagrant@develop: cd /var/www/application/current/app
vagrant@develop: composer install

データベースの構築

各ホストにログインして、データベースとユーザを作成します。構築手順は、書籍の「4-3-2. データベースの作成」に記載があります。

vagrant@develop: mysql -uroot -ppassword

GRANT ALL PRIVILEGES ON *.* TO 'webapp'@'%' identified by 'passw0rd' WITH GRANT OPTION;
FLUSH PRIVILEGES;
CREATE DATABASE blog default character set utf8;
CREATE DATABASE test_blog default character set utf8;

データベーススキーマの構築

データベーススキーマは、CakePHP のプラグイン「CakeDC Migrations Plugin」を使って、構築します。マイグレーションファイルは、用意されているので、下記のように実行します。

vagrant@develop: cd /var/www/application/current
vagrant@develop: ./app/Console/cake migrations.migration run all

これで、delvelop ホストで、フィーチャのテストとユニットテストが通るようになります。

vagrant@develop: cd /var/www/application/current
vagrant@develop: ./app/Console/cake Bdd.story
vagrant@develop: ./app/Console/cake test app

さいごに

継続的インテグレーションの環境を構築して運用していくには、それなりにノウハウが必要です。これまで自力で何とかするしかなかったのですが、本書があれば、まずベーシックな構成については、構築することができます。正直、これから CI 環境を構築する人は、羨ましいです:D

できれば、データベースの構築などもプロビジョンで行うようになっていると、より自動化できて良いと思いましたが、これは読者への課題ということなのでしょう。

また、PHPCPD や PHPMD で算出される数値をベースにコードを改善していく内容がもっとあると嬉しかったです。（やや本書の範囲からはずれていきますが）

読んでいくにあたっては、その内容がどのホストで実行すべきものなのかをイメージしながら進むようにしましょう。これは実際の現場でも同じで、このタスクはどこでやるべきことなのかは常に意識する必要があります。

CI を実践するにあたって必要な情報が、ぎゅっと、まとまった 1 冊です。CakePHP に限らず、PHP プロジェクトで継続的インテグレーションを行うなら、ぜひ一度手にとってみて下さい。

「CakePHPで学ぶ継続的インテグレーション」ハンズオン

2014/11/01 に大阪で本書を題材にしたハンズオンが開催されます。講師には、著者の @kaz_29 さんにお願いしています。私もヘルプで入るつもりなので、みんなで CI を体験してみましょう。

http://devlove-kansai.doorkeeper.jp/events/15073

PHPカンファレンス2013でPHP開発環境をVagrantで作る発表を行ったのですが、具体的なVagrantfileが欲しいという声を頂いたので、GitHubに公開しました。

ご自身で構築するベースになれば良いと思うので、どう作れば良いの？と言う方は参考にしてみて下さい。

なお、このリポジトリの Vagrantfile は、開発PC内の VirtualBox 上で開発環境として動かすことを想定しています。セキュリティについては考慮されていないのでご注意下さい。

vagrant-lapp-sample

https://github.com/shin1x1/vagrant-lapp-sample

このリポジトリは、PHPアプリケーション（CakePHP）をイメージしています。構成は以下です。

• CentOS 6.4
• Apache 2.2
• PHP 5.4
• PostgreSQL 9.3
• phpPgAdmin

ディレクトリ構成としては、app/ がアプリケーションのコードを置くディレクトリで、vagrant/ に Vagrant のファイルを置くイメージです。

app/ には、サンプルとして CakePHP アプリケーションを置いています。（cake bake project したもの）

使い方

git clone でプロジェクトのコードを取得して、あとは vagrant ディレクトリ で、vagrant up を実行するだけです。

$ git clone https://github.com/shin1x1/vagrant-lapp-sample
$ cd vagrant-lapp-sample/vagrant
$ vagrant up

アプリケーションへのアクセス

ブラウザから http://192.168.33.30/ にアクセスすると、PHPアプリケーションを実行することができます。

phpPgAdminへのアクセス

ブラウザから http://192.168.33.30/phpPgAdmin/ にアクセスすると、phpPgAdmin を利用できます。ユーザは vagrant、パスワードは pass です。（厳密にはパスワードは何でも ok です）

ポイント

synced_folder

このリポジトリのルートディレクトリ（ app/ があるディレクトリ）を synced_folder に設定しており、仮想マシンからは /share でアクセスすることができます。

つまり、ホストPCで app/webroot/index.php というファイル編集すると、仮想マシンでは /share/app/webroot/index.php のファイルが自動で更新されます。

ドキュメントルート

Apache のドキュメントルートは、/share/app/webroot に設定しています。

これは vagrant/httpd.conf で設定しており、プロビジョニング実行時に /etc/httpd/conf/httpd.conf に上書きされます。変更が必要であれば、vagrant/httpd.conf を編集して、vagrant provision でプロビジョニングを再実行すると良いでしょう。

なお php.ini も同様に vagrant/php.ini を用意しています。

設定ファイルの準備

Apache や PHP などの設定ファイルを準備する際は、下記手順で行っています。

仮想マシン内での /vagrant ディレクトリが、ホストPCでは Vagrantfile があるディレクトリと synced_folder になっているのがポイントです。

• まずが vagrant up で仮想マシンを起動
• vagrant ssh でログインして、yum で対象パッケージをインストール
• 設定ファイルを変更、動作確認
• cp -a /etc/http/conf/http.conf /vagrant/
• ホスト PC の variant/ に httpd.conf がコピーされる
• プロビジョニングで、/vagrant/httpd.conf を /etc/httpd/conf/ にコピーするコードを書いておく

データベース

この Vagrantfile では、データベースの構築は行っていますが、アプリケーションで必要なテーブル定義などは行っていません。

このあたりはプロジェクトによって方法が異なると思いますが、フレームワークやライブラリ等でマイグレーション機能があればそちらを、無ければ dmp ファイルを適用するコマンドをプロビジョニングで記述することになります。
（ PostgreSQL であれば、 psql -Uvagrant app < pgsql.dmp など。）

シェルプロビジョニング

プロビジョニングには、シェルを使っています。

普段、サーバにSSHログインして yum や apt-get などでインストールしているコマンドをそのまま Vagrantfile に記述していくだけなので、簡単に書けるのが利点です。

Chef や Puppet、Ansible などのプロビジョニングツールを利用しても良いのですが、以前にこういったツールを使ったことが無いのであれば、まずはシェルで構築してみて、次の段階として好みのプロビジョニングツールを試してみるがおすすめです。（もちろん、一気にプロビジョニングツールを使いたい方はその方法でも問題ありません。）

Composer

composer.json が存在すれば、composer.phar をダウンロードして、composer install を実行するようにしています。

このリポジトリでは、CakePHP と PHPUnit を Composer でインストールしています。

CakePHP（1.2.x 以降全て）の Paginate / PaginatorComponent にて SQL インジェクション可能な脆弱性が見つかりました。

すでに cakephper さんの blog でも注意勧告されていますが、 連休中にリリースされた情報ということで見落としている人もいると思うので、こちらでも。

内容

この脆弱性を悪用すると Paginate / PaginatorComponent にて SQL インジェクションが可能となります。
現在は影響の大きさを考慮して、公式サイトでは脆弱性の詳細は明らかにされていませんが（一定期間、ユーザのアップグレードを待って公開するようです。）、私が開発環境で試したところ、SQL インジェクション可能であることが確認できました。

対象

Paginate / PaginatorComponent を利用している全ての CakePHP アプリケーションが対象となります。
Paginate / PaginatorComponent を利用していない場合は、本脆弱性は存在しませんが、今後利用する可能性も考慮して、可能であれば対応しておいた方が良いです。

簡易的ですが、Paginate / PaginatorComponent を利用しているか否かは以下のコマンドで調べることができます。1 件でも該当行があれば、Paginate / PaginatorComponent を利用している可能性があるので、下記対応を検討して下さい。

$ cd /path/to/cake
$ find ./app -type f -name "*.php" | xargs grep -i paginat

対応方法

下記のいずれかの方法で対応を行なって下さい。b. についてはフレームワークを理解している必要がありますので、内容が理解できないようであれば a. の方法をおすすめします。

a. 最新版にアップグレードする

この脆弱性の修正版（1.2.12 / 1.3.16 / 2.2.8 / 2.3.4）がリリースされていますので、こちらのバージョンへアップグレードして下さい。

Security Release – CakePHP 1.2.12, 1.3.16, 2.2.8 and 2.3.4 :: The Bakery: Everything CakePHP

b. 修正箇所を自分で適用する

ただちに CakePHP のアップグレードができないようであれば、今回の脆弱性に関する修正箇所を自分で適用する方法もあります。
各バージョンごとに差分を確認して適用を行なって下さい。

• CakePHP2.3.x
  https://github.com/cakephp/cakephp/commit/c327bdc4bd309ce07fe2c20a2a9123f2165cae76#lib/Cake/Controller/Component/PaginatorComponent.php
• CakePHP2.2.x
  https://github.com/cakephp/cakephp/commit/b4efeb48b8554aba316d80eb89424a20b3be0b27#lib/Cake/Controller/Component/PaginatorComponent.php
• CakePHP1.3.x
  https://github.com/cakephp/cakephp/commit/8fc6b3fa9afc1e6859a138b4c86c0cb4d554caaf
• CakePHP1.2.x
  https://github.com/cakephp/cakephp/commit/db39c242cc8001106bae4530434bdac5878bf438

CakePHP を利用した OSS も対応を

CakePHP 自体の脆弱性なので、CakePHP をベースとした OSS もこの脆弱性が存在する可能性があります。随時それぞれの OSS にてセキュリティフィックス版がリリースされるかと思いますが、まだの場合は上記のとおりアップグレードを検討して下さい。

• baserCMS は、2.1.1にてセキュリティフィックス版（1.2.12）に更新されています。
• candycane は、master ブランチにてセキュリティフィックス版（2.3.4）に更新されています。

CakePHP 2.3 に追加された機能 ServerShell についてです。

CakePHP Advent Calendar 2012の11日目です。昨日は社会派ブロガーに仲間入りした yandod さんの「カンファレンスなどで海外からゲストを呼ぶ際に注意すること」でした。いつも横で見てるだけですが、海外から人を招くのは大変ですね。

さて11日目の今日は CakePHP 2.3 に追加された ServerShell を実装して、pull request したという話を。

ServerShell

ServerShell は CakePHPアプリケーションを動かすための httpd サーバを起動する機能です。Apache などを設定せずとも簡単にCakePHPアプリケーションを起動することができます。

使い方

まず、CakePHP2.3RC1 をダウンロードします。github に zip パッケージがあるのでこれをダウンロードするのが簡単です。

https://github.com/cakephp/cakephp/archive/2.3.0-RC1.zip

zip を解凍して、ServerShell を実行します。

$ ./app/Console server

デフォルトでは80ポートでListenするので、すでにApache等を実行している環境では、-p でポートを変更すると良いでしょう。

$ ./app/Console server -p 8001
Welcome to CakePHP v2.3.0-RC1 Console
---------------------------------------------------------------
App : app
Path: /path/to/cakephp-2.3.0-RC1/app/
DocumentRoot: /path/to/cakephp-2.3.0-RC1/app/webroot
-------------------------------------------------------
built-in server is running in http://localhost:8001/

ブラウザで最後の行に表示されたURL（http://localhost:8001/）にアクセスするとおなじみの画面が表示されます。

ああ、簡単:D

PHP5.4 以上が対象

この機能は PHP5.4 以降でのみ実行することができます。PHP5.4 未満で実行すると下記のようにエラーが表示されます。

仕組み

ここまでご覧になった方はおおよそ予想が付くと思いますが、実は ServerShell は PHP5.4 で追加されたビルトインサーバをラップしただけです。また、ビルトインサーバ上で動かすための改良を少し加えています。

ビルトインサーバをベースとしてますので、ServerShell は開発環境でのみ利用するようにして下さい。

ソースはこちらにあるので気になる方はどうぞ。

https://github.com/cakephp/cakephp/blob/2.3/lib/Cake/Console/Command/ServerShell.php

作った経緯

以前から CakePHP アプリケーションを簡単に動かすために httpd サーバを CakePHP パッケージに追加したいと思っていました。（こんなの作ったりしてみました）PHP5.4 のビルトインサーバの登場により簡単に実現することができました。

ハンズオンの勉強会を開催していても、やはり環境構築でつまづく方が多かったので、これを使えば簡単に CakePHP を試すことができます。

まだ試していないですが、CandyCane や baserCMS など CakePHP で作られたシステムも .htaccess が CakePHP デフォルトのままであれば動作すると思います。

pull request から取り込まれるまで

7月に福岡でCakePHP翻訳合宿があったのですが、その際に基本的な実装を行なって、pull request を送りました。

反応がいまひとつ予想できなかったのですが、以前にCakePHP1.3向けビルトインサーバ対応パッチを pull request して、取り込まれたこともあったので、とりあえず送って見ることにしました。

細かな指摘は多数あったのですが、結果としてはそれほど反対意見もなく、最初の pull request を投げてから 3 週間ほどして取り込めることになりました。

いくつかあった指摘事項は以下のようなものです。

名前が微妙

ServerShellの「Server」という言葉が汎用的過ぎるのでどうだろ、という意見がありました。

確かにこれは理解できます。別名として「PhpWebserverShell」や「HttpServerShell」という意見もあったのですが、コンソールから入力するのが長いので「ServerShell」で進めました。結果的には、このコマンドで php+web server以外が起動するのは想像できないという意見もあって、ServerShell のままとなりました。

2.3 ブランチへ

はじめは master（当時バージョンは2.2）へ pull request を送信したのですが、2.3 ブランチへ投げて欲しいというリクエストがあったので、2.3 ブランチへ送信し直しました。

typo, インデント, メッセージ など細々とした修正

大筋は問題無かったのですが、typo やインデント、メッセージの書き方などは多数指摘がありました。やっぱり他人の目で見るとボロボロ出てきますね＞＜コードレビュー大事です。

とくに CakePHP 本体に取り込まれるコードなので、CakePHP のコーディング規約に乗っ取るようにとの指摘がありました。コーディング規約のチェックには、phpcs を使っているようなので、CakePHP 用のルールでチェックを行い、チェックが通るまで修正を行いました。

• CakePHP Code Sniffer
  https://github.com/cakephp/cakephp-codesniffer

やりとりが楽しかった pull request

実際に送信した pull request がこちらです。

https://github.com/cakephp/cakephp/pull/713
https://github.com/cakephp/cakephp/pull/714

これまでいくつか pull request を送信したり、パッチを送ったりはしていたのですが、不具合の指摘が多く、あまり議論になるようなことはありませんでした。

今回も実装の内容についての議論は無かったのですが、細かなことで指摘を受けて、こちらの意見を言って、といったやり取りが有意義でした。pull request を見てもらうと分かりますが、変な英語でもPHPのソースがあるので、それなりに意図は通じたかなと思ってます。

やっぱりこういうのは楽しいですね。

PHP5.4 が普及するのはもう少し先かもしれませんが、機会があれば ServerShell を使ってみて下さい。

共著で執筆に参加した「CakePHP2 実践入門」が2012/09/29に出版されました。

2007年に執筆した「CakePHPガイドブック（共著）」から数えて4冊目の書籍執筆となるのですが、執筆の方法やコラボレーションのツールも大きく変わりました。執筆を終えて一息ついた今、執筆環境を振り返ってみたいと思います。

2007年と今回の執筆環境をざっくりと比較するとこんな感じでした。

	原稿執筆	原稿提出	連絡	issue管理	CI
2007年	Word	FTP	ML	ML	なし（Wordで確認）
2012年	Vim + Marked	Github	Facebookグループ	Github	Githubリポジトリをpollingして、Markdown+独自マークアップをHTMLにコンバートなど。

原稿執筆

原稿は Vim で書いて、Marked のプレビューを確認するという形で進めました。

Vim

原稿の形式は、Markdown＋独自マークアップのプレーンテキストだったので、執筆陣は各自好きなツールを使うことができました。

Vim は普段から使っていて慣れていますし、技術本ということでソースコードを読んだり書いたりする場面が多いので同じエディタ上でそれができるのは楽でしたね。

Markdown ということで当初は専用のエディタなども試したのですが、やはり「書く」という行為に関しては手に馴染んでいるものが一番です。

Marked

Marked は Markdown 形式で書かれたファイルをプレビューするツールです。Marked でファイルを開いておくと元ファイルが変更されるとプレビュー側も連動して更新されます。

あくまでプレビューに特化したツールなので任意のエディタと組み合わせて使用することができるのが良いですね。

実は Vim + Marked の組み合わせが気に入ったので、この blog も同じ構成で書いています。

以前は Word だったので、プレビューという点では問題無いのですが、ソースコードが書きにくかったり、差分が取りづらかったりしていました。当時はそれが当たり前だと思っていましたが、やはりプレーンテキストで書けるのは慣れてる分、楽でした。

原稿提出、issue管理

Github

原稿提出やissue管理にはGithubを使いました。

執筆陣は各々原稿を書いて、Github へ push して原稿を提出するという流れでした。

git のメリットは言わずもがなですが、こちらも日常でソースコードを push するのと同じ感覚で原稿を提出できたのは良かったです。さらに原稿がプレーンテキストということで、差分を確認したり、変更履歴を見たりというのもお手のものでした。

今回は章ごとに執筆者が決まっていたので、conflict することも無いだろうということで、ブランチ分けはせずに master へpushしていました。

原稿の修正依頼や査読結果などの issue 管理も Github で行なっています。

Github の issue 管理では、commit ログに issue no を記載することで issue チケットから commit にリンクを貼ることができるので、issue に関する修正が明示できて、これは便利でした。

本書のサンプルコードもGithub上で公開する予定ですので、書籍を購入された方はご参照下さい。

連絡

Facebook

編集の方、執筆陣との連絡には Facebook グループを使いました。

ML でも良かったのですが、メールより気軽に投稿、返信ができたのでやりやすかったです。返信するほどではないけど同意や見たことを現したい時に「いいね！（Like）」で反応できるのは手軽で便利ですね。

ただ Facebook グループだとどうしても過去の発言が流れて行ったり、一つのトッピクについてコメントが大量についたときに見づらかったりするので、もし次回があればchatworkなど別のコラボレーションツールの方が良いかもしれません。

CI

CI 的な機能もいくつか用意しました。

Githubのリポジトリをpollingしており、定期的に自動実行されます。

• PHPコードの自動lint（安藤さん作）
• 原稿中のソースコード自動抽出（安藤さん作）
• 原稿をHTMLへ自動変換、変換ブラウザで閲覧可能に（鈴木さん作）
• 原稿の規約（マークアップや一行文字数等）を検証して、エラーログを出力（鈴木さん作）

特に鈴木さんが用意してくれた原稿をブラウザで確認できるツールはかなり便利でした。書式エラーなどがログとして確認できるので、これを活用して原稿の修正を行いました。いずれ公開されると思うので乞うご期待を。

今にして思うと Jenkins でこういったツール群を管理しても良かったですね。

普段のシステム開発と同じリズムで原稿を書く

今回利用したツールはどれも普段のシステム開発で利用しているもので、ソースコードを書くのと同じリズムで執筆を進めることができました。

執筆期間中に度重なるCakePHPのバージョンアップ（2.0 -> 2.1 -> 2.2）があり、リスケを余儀なくされましたが、原稿のデグレや issue の取りこぼしもなく、無事に書店に並べることができました。

CakePHP は、公式ドキュメントである cookbook が充実しており、和訳も少しづつ進んでいるのですが、日本語で書かれたまとまった情報を望む声が多くありました。この本はそういった機運を受けて執筆されました。みなさんのCakePHP開発の一助になればと思いますので、一度手にとって頂ければ嬉しいです。

最後に、セキュリティ章について丁寧な査読、ご指摘をして頂いた徳丸浩さんにお礼を言いたいと思います。本当にありがとうございました。

Rails 界隈で話題の Mass Assignment 脆弱性を CakePHP で防ぐ方法です。

Github に Mass Assignment 脆弱性が発見されて、Rails 界隈で話題になっています。この問題自体は目新しいものではなく、Rails 自体の問題というより、Rails アプリケーションの作り方の問題ということで、以前から作る側が注意を払う必要がありました。

この Mass Assignment 脆弱性は、Rails を手本に発展してきた CakePHP アプリケーションでも同様の問題が発生する可能性があります。知っている人には常識なのですが、まだ知らない人もいるかと思うので、CakePHPにおける対策方法を書いてみます。下記コードはCakePHP2系を想定していますが、考え方はCakePHP1系でも同じです。

Mass Assignment 脆弱性

CakePHP における Mass Assignment 脆弱性は、フォーム（多くはFormHelperで作成）からPOSTで送信された値をモデルに渡す時に発生します。

例えば、以下のようなフォームの場合、一見するとnameだけが送信されるように見えます。このフォームをブラウザで表示して入力内容を送信すれば、もちろんnameだけが送信されます。しかし、フォームというかHTTPリクエストは自在に改変できるので、nameの他にemailでもpasswordでも何でも送ることができます。

app/View/User/edit.ctp

<?php echo $this->Form->create('User'); ?>
<?php echo $this->Form->input('name'); ?>
<?php echo $this->Form->end('submit'); ?>

コントローラで見ると、edit()メソッド内で、$this->request->dataの値をそのままUser#save()に渡しています。サンプルコードなどではよくある書き方ですが、$this->request->dataに本来想定していないパラメータが含まれていても（上記フォームで言うところのname以外）、usersテーブルにカラムが存在すれば、送信された内容がそのままデータベースに保存されてしまいます。

app/Controller/UserController.php

<?php
App::uses('AppController', 'Contoller');

classs UserController extends AppController {
  public $uses = array('User');

  public function edit() {
    if (!empty($this->request->data['User'])) {
      $this->User->save($this->request->data);
    }
  }
}

これを悪用すると、本来入力フォームでは変更して欲しくないカラム（例えば管理者フラグや権限、もしかするとポイント数など）を外部から操作することが可能となります。

さらにModel#save()では、与えられた引数にプライマリーキー（多くはid）が含まれていると、その値にマッチするレコードをupdateしてしまいます。つまり新規追加フォームのつもりが、任意のレコードを変更されてしまう可能性があります。

この問題、実は意識しておかないと結構影響が大きいです。

対策1. SecurityComponent を使う

対策として、SecurityComponent を使う方法があります。SecurityComponentをコントローラの$componentsに記載しておけば、自動的にフォーム改ざんチェックが有効となるので、フォームを改ざんして任意のパラメータを送信してもエラーとなり、アクションメソッドが実行されません。

対策2. save()に渡す値を設定する

対策1でも対策にはなるのですが、本質的な問題は$this->request->dataに意図しないパラメータを含まれているのにそのまま処理してしまうことです。そこで、処理対象のパラメータのみを抽出して、save()には抽出したパラメータを渡すようにします。

下記がサンプルです。$dataに処理対象のパラメータだけをセットして、save()には$dataを渡しています。これにより意図しないパラメータが送られてきても、save()に渡されることはありません。

  public function edit() {
    if (!empty($this->request->data['User'])) {
      $data = array(
        'name' => Set::extract($this->request->data, 'User.name'),
      );
      $this->User->save($data);
    }
  }

不十分な対策 save()の第三引数に更新対象カラムを渡す

save()の第三引数に処理対象カラムを指定することで、意図しないカラムへの更新を防ぐという方法があります。

下記のようにsave()の第三引数にarray(‘name’)を指定して、nameのみを更新対象とします。この方法なら更新されるカラムはnameに限定することができます。しかし、$this->request->data[‘User’]にidが含まれていると、そのidに該当するレコードが更新されるという問題が残ります。つまり更新カラムはnameのみですが、その対象レコードは任意に指定されてしまいます。

  public function edit() {
    if (!empty($this->request->data['User'])) {
      $this->User->save($this->request->data, true, array('name'));
    }
  }

便利機能には注意を

$this->request->dataをそのままModel#save()に渡して処理する。この方法は簡単だし、スマートに見えます。しかし、上で見てきたように意識しておかないと意外な落とし穴にはまります。

このあたりは手を抜かずにきっちりと処理対象パラメータのみを抽出してsave()に渡すという方法が問題も起こりづらいし、挙動も把握しやすいと思います。意識していなかった人はご注意を。

PHP5.4のビルトインサーバで CakePHP を動かしてみました。

CakePHP Advent Calendar 2011 の 4 日目です。

いよいよ PHP5.4 の正式リリースが近づいてきました。5.3 からのマイナーバージョンアップとはいえ、Trait や Short syntax for arrays、Array Dereferencing など興味深い機能が追加されています。

そんな新機能の中から注目のビルトインサーバを使って、CakePHP を動かしてみました。今回は CakePHP1系と2系の両方を試しています。

PHP5.4RC2をインストール

まずは現時点での最新版 PHP5.4RC2 が動く環境を作ります。

手順は以前書いたエントリ「 現状のPHP環境はそのままで、PHP 5.4 を試す 」を参考にして下さい。

上記エントリではとりあえず 5.4 環境を作るという内容でしたが、実際にアプリケーションを動作させる場合は、./configure で利用するオプションを指定する必要があります。今回は下記のようにオプションを指定しました。

$ ./configure --with-mysql --with-pdo-mysql --enable-mbstring --with-pgsql=/opt/local/lib/postgresql90

ビルトインサーバを起動

ビルトインサーバは PHP5.4 で実装された新機能です。CLI 版 PHP のオプションとして実装されており、コマンドラインから Web サーバを起動して、その上で PHP を実行することができます。これを使えば Apache のような Web サーバが無くても CakePHP を実行することができます。

では先ほど構築した PHP5.4RC2 環境でビルトインサーバを起動してみましょう。

CLI 版 PHP に「-S」を付けるとビルトインサーバが起動します。「-S」の後ろは HTTP リクエストを待ち受ける IP とポートを指定します。下記例では local:8111 で待ち受けます。なお、ここでは既存の PHP の ini ファイルを利用したいので、「-c」で php.ini のパスを指定しています。

$ sapi/cli/php -S localhost:8111 -c /path/to/php.ini
PHP 5.4.0RC2 Development Server started at Sun Dec  4 15:38:15 2011
Listening on localhost:8111
Document root is /path/to/docroot
Press Ctrl-C to quit.

起動したらブラウザで「http://localhost:8111/」にアクセスするとページが表示されます。

Ctrl-C を押すと、ビルトインサーバが停止します。

-t で DocumentRoot を指定

デフォルトではコマンドを実行したカレントディレクトリが DocumentRoot になります。「-t」を付けると任意のディレクトリを DocumentRoot に変更できます。

$ sapi/cli/php -S localhost:8111 -t /path/to/docroot

.htaccess は無効

.htaccess はビルトインサーバ上ではただの１ファイルにしかすぎず、mod_rewrite などの制御は働きません。

しかし、ビルトインサーバではリクエストファイル名に「.」が含まれておらず、該当ファイルが存在しない場合は、index.php もしくは index.html を起動する仕様になっているようなので、CakePHP のように index.php からフレームワークが起動するアプリケーションでは問題無く実行することができます。

詳細はPHPマニュアルに

さすが PHP ということで、すでにビルトインサーバについては PHP にマニュアル解説があります。詳細はこちらをどうぞ。
PHP: ビルトインウェブサーバー – Manual

CakePHP2 を試す

では実際に CakePHP2 をビルトインサーバ上で動かしてみましょう。今回動かしたのは 2.0.4 です。

手順は簡単で、CakePHP2 の app/webroot を DocumentRoot に指定して、ビルトインサーバを起動するだけです。

$ sapi/cli/php -S localhost:8111 -c /path/to/php.ini -t /path/to/cakephp2/app/webroot

ブラウザでアクセスすると見事におなじみの画面が表示されます。

本格的なアプリケーションは実行していませんが、ざっと見た感じでは、PHPソースを変更することなく、そのまま実行することができました。

CakePHP1 を試す

次は CakePHP1 をビルトインサーバ上で動かしてみます。今回動かしたのは 1.3.13 です。

$ sapi/cli/php -S localhost:8111 -c /path/to/php.ini -t /path/to/cakephp1/app/webroot

ブラウザでアクセスするといつもの画面が表示されますが、いくつかエラーが出ています。

エラーメッセージは以下。

Strict Standards: Redefining already defined constructor for class Object in /path/to/cakephp1/cake/libs/object.php on line 54

Strict Standards: Non-static method Configure::getInstance() should not be called statically in /path/to/cakephp1/cake/bootstrap.php on line 38

Strict Standards: Non-static method CakeLog::getInstance() should not be called statically, assuming $this from incompatible context in /path/to/cakephp1/cake/libs/cake_log.php on line 290

E_STRICTエラー

PHP5.4 からエラー出力レベル E_ALL に E_STRICT が含まれたため、E_STRICT に引っかかった箇所がエラーとして表示されてます。

CakePHP ではフレームワーク自身が error_reporting() でエラー出力レベルを上書きしてしまうので、E_STRICT を除外するように変更する必要があります。（display_error=off でエラー表示を抑制する手もありますが、開発環境では表示しておいた方が便利です。）

この問題についてはビルトインサーバ上でなくとも、PHP5.4環境では同じく発生します。

修正箇所は github に commit してあるので、こちらをどうぞ。
Commit 9cbc30101c7d43221b88ea0d9fa66c2cfaa4f1d1 to shin1x1/cakephp – GitHub

URLパス生成の問題

「http://localhost:8111/a」など存在しないコントローラにアクセスするとお馴染みのエラー画面となるのですが、CSS が効かずにテキストのみが表示されます。画面下の画像も表示されていません。

これはフレームワークのURL生成に問題が発生しているためで、HTMLのソースを見ると CSS のパスが「/index.php/css/cake.generic.css」のように頭に余計な内容が入っています。

<link rel="stylesheet" type="text/css" href="/index.php/css/cake.generic.css" />

この対応として、app/webroot/index.php に以下の記述を追加します。

+  if (php_sapi_name() == 'cli-server') {
+    $_SERVER['PHP_SELF'] = '/'.basename(__FILE__);                                                                                                                                             
+  }
  if (!include(CORE_PATH . 'cake' . DS . 'bootstrap.php')) {

これで「http://localhost:8111/a」でアクセスすると CSS が効いて、いつもの表示になります。

他にも FormHelper が生成する URL など各所で同じ現象が発生しますが、上記修正で対応ができます。

ユニットテストもちゃんと通りました

ちなみに CakePHP1 系で作ったとあるアプリケーションの alltest を通すとビルトインサーバ上でもちゃんとテストが通りました。これで 5.4 上でも動作することが分かりました:D

ビルトインサーバで手軽に試す

ビルトインサーバの利点はなんといっても「手軽さ」です。

新たに環境構築が必要な場面で、いちいち Apache に VirtualHost を追加したりせずともビルトインサーバを使えば、すぐに任意のディレクトを DocumentRoot にして Web サーバを起動することができます。

ビルトインサーバは CLI 版 PHP ではデフォルトで組み込まれるので、拡張等無しで多くの環境で利用できるのが良いですね。

ぜひ PHP5.4 ビルトインサーバでお手軽に CakePHP を試してみて下さい。

明日の CakePHP Advent Calendar 2011 5 日目は、@kashioka さんです。お楽しみにー。

PHP Matauri 2011 が終了しました。いやあ楽しかった。

Photo by zatsu

大きな問題もなく無事にイベントを終えることができました。関西の方はもちろん、大阪開催にも関わらず、多くの方に関西外からお越し頂き、みなさん本当にありがとうございました。

個人的にも昨年参加できなかった PHP Matsuri にようやく参加できました。色々と感じたことなどをつらつらと書いていきます。

PHP Matsuri はどんなイベント？

参加前

• 昨年の PHP Matsuri は参加できず。
• まあ運営はいつものメンバーなので、後で聞いてみよう。
• みんな「とにかく楽しかった」しか言わない。。。
• 「カンファレンス」「ワークショップ」「ハッカソン」「開発合宿」「アンカンファレンス」が合わさったイベント？
• それぞれ参加したことあるし、魅力的なラインナップ、確かに楽しそうなのは分かる。

1日目終了

• カンファレンス、ワークショップは納得の内容。
• TDDワークショップでちょろっと講師。参加された方、ありがとうございました！（FizzBuzzでPHPUnitを体験）
• 翌日のライトニングトーク大会に向けてハッカソン開始するが、細々したことばかりやって今ひとつ手につかず。
• まあ雰囲気楽しいし、翌日の発表は今回はもういいかなーと思いつつ、3:00頃に就寝。

2日目午前終了

• チェックアウトぎりぎりの10:00前にようやく起床（同室の@itemanさんに起こしてもらったm(_ _)m）
• みんな頑張って作業してるのに触発されて、慌てて作業開始。
• そもそもテーマすら決めてなかったから、なかなか決まらず。
• ようやくあれこれやりだした頃にライトニングトーク大会締め切りが来て、エントリ出来ず。
• ただ頭のどこかでは「まあ間に合わなかったら別にいいか。」と思っていた。

2日目ライトニングトーク大会開始

• あ！！！そういうイベントか！！！
• ようやくイベントの核に気づく。
• 発表しない PHP Matsuri なんて、クリープの無いコーヒー、炭酸の無い RedBull やん。。。

PHP Matsuri はどんなイベント？

まず参加前に思っていた「「カンファレンス」「ワークショップ」「ハッカソン」「開発合宿」「アンカンファレンス」が合わさったイベント」は確かにそのとおり。それぞれが単体でイベントできる内容でかつ、わずか30時間の間に同じ場所で一気に繰り広げられるから、濃度が半端無く濃い。それだけに参加した人には強烈な印象（疲れも）が残ります。

ただそれだけじゃなく、参加して分かったのは、実は一番大事なコンテンツは2日目午後の「ライトニングトーク大会」だということ。そもそものコンセプトである「アウトプットする」を実践する「ライトニングトーク大会」こそがイベントで一番のコンテンツであり、@yandoさんが書かれているとおり、まさに「参加者の皆さん自身こそが目玉コンテンツ」ですね。

それを理解した頃には、まさに「後の祭り」なわけで、次回は発表するようにします！

PHP Matsuri を関西で開催したということ

多くの方に参加頂いたわけですが、関西以外からの参加者の方が多く、わざわざ関西に来てもらえて嬉しい気持ちでいっぱいでした。PHPカンファレンス関西の時もそうでしたが、イベントのために来阪してもらえるということはありがたいことですね。

一方で、関西からの参加者が少し少なく寂しい気持ちも若干ありました。

そもそも関西スタッフである自分のアピール不足が原因でもあるので、そこは反省するとして、ただこういった機会はそうは無いので迷っていた方には、できたら参加してもらいたかったなあという思いが残っています。

イベントに参加したからと言って、次の日から人生がバラ色になるとかそういうことはありません。イベントで高ぶった気持ちも翌日からの日常で徐々に落ち着いていき、いつもの日々に戻ります。

ただ確実に心のどこかでは何かが変わります。

上手く伝わるか分かりませんが、自分の中では、日常で徐々に積もっていく閉塞感というか、勝手に自分が創りだした心の壁のようなものを打ち砕くような効果があります。あと、なんとなくですが、スタッフ、スピーカー、参加者に関わらず、参加した人同士の結びつきも感じます。通常のイベントでもこういった感覚はあるのですが、一夜を共にした仲というのは（男女間に限らず）特別なものを感じます。

今後、関西でもイベントを開催していきたいので、次回こそはみなさん参加をお待ちしてます！

次回は？

会場でも次回開催を期待する声が多く、私自身もまた参加したいと思うのですが、いかんせん有料＋宿泊イベントということで運営負荷も大きいので、まだどうなるかは未定です。

突然ですが、最後にイベント中のとあるシーンが写真に残っていましたので、ご紹介します。

左から、マイクを持って何かを言っている@shin1x1、真ん中で不敵に笑う@yando、何かを決意したような@k1low。

Photo by koyhoge

次回が楽しみですね。みなさん、おつかれさまでしたー。

one more thing…

イベントの翌々日にCakePHPコアデベロッパーの@predominantさんと夕食に行くことができました。

身振り手振りにGoogle翻訳を駆使し、Air に入れていた自社フレームワークのコードを見てもらったり、MotoGP の話をして、とても楽しい時間を過ごすことができました。こういった機会に巡り会えたもの PHP Matsuri のおかげですね。

ありがとうございましたm(_ _)m