PHP Archive

最近、話題のPHP5.3のサポート終了（End Of Life=EOL）について。

当初は2013/03末でEOL を迎えるという話だったのですが、これを延長する案が php-internals で流れていました。

PHP: rfc:php53eol [PHP Wiki]で投票が行われるくらいまでは追いかけていたのですが、結局どうなったのかなと気になってたところで @kenji_s さんの tweet から辿って以下のリンクを見つけました。

php.internals: [RFC][result] Define PHP 5.3 end of life

投票の結果、以下のことが決まったようです。

• PHP5.3のEOLはPHP5.5.0をリリースして1年後
• EOLの正確な日付はPHP5.5.0リリース時にアナウンス

当初よりは少し余裕は出来ましたが、PHP5.5はすでにbeta2まで来ているので、5.4への移行を進めておいた方が良いですね。稼働中のものは別としても、新規開発のものは5.4対応で開発しましょう。

Vagrant 便利ですね。Web システム構築ではサーバ構築、設定を何度となく繰り返すので、こういった「作って、壊して、元に戻せる」環境が自分の PC にあるというのはとても重宝します。

ここでは Vagrant1.0 を使って、Mac OS X 上に CentOS サーバを構築します。また触ってみて便利だった機能もいくつかご紹介します。

• 1. VirtualBox のインストール
• 2. Vagrant1.0 のインストール
• 3. box ファイルのインストール
• 4. Vagrantfile の作成
• 5. 仮想サーバを起動
• 6. 仮想サーバを停止
• 7. 仮想サーバを削除
• 8. 仮想サーバでhttpdサーバを構築
• 9. sahara プラグインで、作って、壊して、元に戻せる環境を構築
• 10. 複数の仮想サーバを起動
• 11. 仮想サーバのエクスポート
• Q. OS X, ruby, gem のバージョン

Vagrant とは

きちんとして説明は本家サイトを見るのが良いのですが、端的にいうと PC にインストールできる仮想PCを便利に使うツールです。
1.0 では仮想PCとして VirtualBox に対応しています。（1.1 からは VMWare や EC2 などにも対応しています。）

1. VirtualBox のインストール

まず VirtualBox をインストールします。VirtualBox は下記サイトから無料でダウンロードすることができます。

https://www.virtualbox.org/wiki/Downloads

2. Vagrant1.0 のインストール

次に Vagrant をインストールします。最新版は1.1なのですが、まだリリースされたばかりで、後述する便利なプラグインなどが対応していないので、ここでは1.0をインストールします。

Vagrant1.0は公式サイトからパッケージをダウンロードするか、 gem でインストールします。

Vagrant – Downloads

gem でインストールする場合は以下になります。（追記: gem でインストールした場合、sahara プラグインが動作しない場合があるので、こだわりが無ければ上記パッケージでのインストールをお勧めします。）

$ sudo gem install vagrant

インストールができたら vagrant コマンドが使えるか確認しておきます。

$ vagrant -v
Vagrant version 1.0.7

3. box ファイルのインストール

Vagrant で仮想サーバを作成するには box ファイルというイメージファイルが必要になります。box ファイルは自分で作成することもできるのですが、主要な Linux については公開されているファイルがあるので、これをインストールします。

Vagrantbox.es では各OSごとのboxファイルダウンロードURLが一覧として公開されています。CentOS もいくつか種類があるので、その中から CentOS6.4_x86_64 の box ファイル（CentOS 6.4 x86_64 Minimal (VirtualBox Guest Additions 4.2.8, Chef 11.4.0, Puppet 3.1.0)）をインストールします。

下記が box ファイルのインストール例です。

vagrant box add までがコマンドで、centos64_64 の部分が box ファイルの名称です。これは任意に付けることができるので、自分が分かりやすい名前を付けます。その後に box ファイルの URL を指定します。

$ vagrant box add centos64_64 http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130309.box
[vagrant] Downloading with Vagrant::Downloaders::HTTP...
[vagrant] Downloading box: http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130309.box
[vagrant] Extracting box...
[vagrant] Verifying box...
[vagrant] Cleaning up downloaded box...

インストールが完了したら、vagrant box list コマンドで確認します。

% vagrant box list
centos64_64

• Vagrant Documentation – Documentation – Boxes
• http://www.vagrantbox.es/

4. Vagrantfile の作成

次に vagrant の設定ファイルである Vagrantfile を作成します。作成する仮想サーバの設定はこのファイルに記述していきます。

Vagrantfile の作成するには vagrant init コマンドを使います。

% mkdir vagrant
% cd vagrant
% vagrant init
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
% ls
Vagrantfile

では Vagrantfile を編集してみましょう。
デフォルトのサンプルの設定がコメントで書かていますが、一旦削除して必要な設定だけ記述しています。

config.vm.box にはベースとなる box 名を指定します。ここでは先程ダウンロードした centos64_64 という box 名を指定しています。
これだけで仮想サーバを起動できるのですが、動作が分かりやすいように config.vm.boot_mode に :gui を指定しています。

% vim Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant::Config.run do |config|
  config.vm.box = "centos64_64"
  config.vm.boot_mode = :gui
end

5. 仮想サーバを起動

では実際に仮想サーバを起動してみましょう。

仮想サーバを起動するには、vagrant up コマンドを使います。

% vagrant up
[default] Importing base box 'centos64_64'...
[default] Matching MAC address for NAT networking...
[default] Clearing any previously set forwarded ports...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Booting VM...
[default] Waiting for VM to boot. This can take a few minutes.
[default] VM booted and ready for use!
[default] Mounting shared folders...
[default] -- v-root: /vagrant

コマンドを実行すると VirtualBox が起動します。

起動が完了すると VirtualBox のウィンドウにログインプロンプトが表示されます。
ウィンドウをクリックして、login に vagrant 、password に vagrant を入力するとログインすることができます。

Virtualbox ウィンドウから抜ける時は、ウィンドウ右下に書いてあるとおり、左のコマンドキーを1回押します。（Mac OS X の場合）

vagrant ssh コマンドを使うと、ssh で仮想サーバにログインすることができます。

% vagrant ssh
Last login: Thu Mar 21 06:46:13 2013
Welcome to your Vagrant-built virtual machine.
[vagrant@localhost ~]$

vagrant status コマンドを使うと、現在の仮想サーバの状態が確認できます。下記では、起動中なので ruuning と表示されています。

% vagrant status
Current VM states:

default                     running

6. 仮想サーバを停止

仮想サーバを停止する場合、VirtualBox ウィンドウでログインした状態で、/sbin/shutdown などを実行する方法と vagrant halt コマンドで仮想サーバを停止する方法があります。

下記では vagrant halt コマンドで仮想サーバを停止しています。

% vagrant halt

vagrant status コマンドを実行すると停止していることが分かります。

% vagrant status
Current VM states:

web1                     poweroff

7. 仮想サーバを削除

仮想サーバを削除する場合、vagrant destroy コマンドを使います。

% vagrant destory
Are you sure you want to destroy the 'default' VM? [Y/N] y
[default] Destroying VM and associated drives...

vagrant status コマンドを実行すると削除されていることが分かります。

% vagrant status
Current VM states:

default                     not created

8. 仮想サーバでhttpdサーバを構築

では仮想サーバにhttpdをインストールしてみましょう。

まず Vgrantfile を編集して、仮想サーバの設定を追加します。
Mac 上ですでに各種デーモンが起動しているため、ポートの競合などを避けるために仮想サーバにIPアドレス、ホスト名を付与しています。また、VirtualBox のウィンドウを隠すために config.vm.boot_mode をコメントアウトしています。

% vim Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant::Config.run do |config|
  config.vm.box = "centos64_64"
  #config.vm.boot_mode = :gui

  config.vm.define :web do |web|
    web.vm.host_name = "web"
    web.vm.network :hostonly, "192.168.33.10"
  end
end

では仮想サーバを起動しましょう。

% vagrand up

SSH で仮想サーバにログインします。vagrant ssh コマンドでも可能ですし、IP アドレスを指定して、ssh コマンドでもログインできます。

% vagrand ssh

% ssh vagrant@192.168.33.10
※パスワードは vagrant

次に httpd をインストールして、起動します。

[vagrant@web ~]$ sudo yum -y install httpd
(snip)
[vagrant@web ~]$ sudo /sbin/service httpd start

この仮想サーバでは iptables が設定されていて、外部からの通信を遮断してしまいます。VirtualBox を実行している PC から通信できるように全てのフィルタリングルールを削除しておきます。

[vagrant@web ~]$ sudo /sbin/iptables -F
[vagrant@web ~]$ sudo /etc/init.d/iptables save

ブラウザから仮想サーバの httpd にアクセスしてみましょう。http://192.168.33.10/ にアクセスするとおなじみのテストページが表示されます。

9. sahara プラグインで、作って、壊して、元に戻せる環境を構築

Vagrant にはプラグインで機能を拡張することができます。いくつかあるプラグインの中から、個人的にこれがあるから Vagrant が使いたくなるというプラグインをご紹介しましょう。

それは sahara プラグインです。sahara プラグインを使うと、データベースのトランザクションにおける rollback のように、サーバへ反映した作業をある時点まで簡単に戻すことができます。

では sahara プラグインをインストールして、気軽に元に戻せる機能を試してみましょう。

9–1. sahara プラグインをインストール

sahara プラグインをインストールするいは、vagrant gem install コマンドを使います。

% vagrant gem install sahara
Fetching: Platform-0.4.0.gem (100%)
Fetching: open4-1.3.0.gem (100%)
Fetching: popen4-0.1.2.gem (100%)
Fetching: thor-0.17.0.gem (100%)
Fetching: sahara-0.0.13.gem (100%)
Successfully installed Platform-0.4.0
Successfully installed open4-1.3.0
Successfully installed popen4-0.1.2
Successfully installed thor-0.17.0
Successfully installed sahara-0.0.13
5 gems installed
Installing ri documentation for Platform-0.4.0...
Installing ri documentation for open4-1.3.0...
Installing ri documentation for popen4-0.1.2...
Installing ri documentation for thor-0.17.0...
Installing ri documentation for sahara-0.0.13...
Installing RDoc documentation for Platform-0.4.0...
Installing RDoc documentation for open4-1.3.0...
Installing RDoc documentation for popen4-0.1.2...
Installing RDoc documentation for thor-0.17.0...
Installing RDoc documentation for sahara-0.0.13...

インストールが完了すると、vagrant で利用できるサブコマンドに sandbox が追加されます。

% vagrant
[/Users/shin/vagrant]% vagrant
(snip)
Available subcommands:
     box
     destroy
     gem
     halt
     init
     package
     provision
     reload
     resume
     sandbox  <---- 追加
     ssh
     ssh-config
     status
     suspend
     up

For help on any individual command run `vagrant COMMAND -h`

9–2. sahara プラグインを試す

実際に sahara プラグインを試してみましょう。

まず vagrant sandbox on コマンドで、snapshot mode を開始します。これは RDBMS の BEGIN にあたり、rollback した場合にこの時点まで仮想サーバを戻すことができます。

% vagrant sandbox on
[web] - Enabling sandbox
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

vagrant sandbox status コマンドを実行すると snapshot mode 中であることが分かります。

% vagrant sandbox status
[web] - snapshot mode is on

仮想サーバにログインして、php をインストールします。php コマンドが実行できることが確認できたらログアウトします。

% vagrant ssh
Last login: Thu Mar 21 07:10:35 2013 from 192.168.33.1
Welcome to your Vagrant-built virtual machine.
[vagrant@web ~]$ sudo yum -y install php
[vagrant@web ~]$ php -v
PHP 5.3.3 (cli) (built: Feb 22 2013 02:51:11)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
[vagrant@web ~]$ exit

php のインストールを取り消すために、vagrant sandbox rollback コマンドで vagrant sandbox on を実行した時点に戻します。

% vagrant sandbox rollback
[web] - powering off machine
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[web] - roll back machine
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[web] - starting the machine again

これは仮想サーバが元に戻りました。再度 vagrant ssh でログインしてみると、さきほどインストールした php が存在しません。

[vagrant@web ~]$ php
-bash: php: コマンドが見つかりません

rollback を実行した後も snapshot mode が有効なままとなっています。（これは DBMS とは異なります）

% vagrant sandbox status
[web] - snapshot mode is on

では、つづけて、sudo rm -rf /bin を実行してみましょう。（必ず仮想サーバで実行して下さい！）

[vagrant@web ~]$ sudo rm -rf /bin
(snip)
[vagrant@web ~]$ ls
-bash: /bin/ls: No such file or directory

こりゃ大変！でも大丈夫。サーバをログアウトして、vagrant sandbox rollback を実行すれば元通り。

% vagrant sandbox rollback
[web] - powering off machine
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[web] - roll back machine
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[web] - starting the machine again

% vagrant ssh
[vagrant@web ~]$ ls

snapshot mode を終了する場合は vagrant sandbox off コマンドを実行します。vagrant sandbox off コマンドを実行すると現在の状態をそのまま保存して、snapshot mode が終了します。

% vagrant sandbox off
[web] - switching sandbox off
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

vagrant sandbox status で確認すると snapshot mode が終了していることが分かります。

% vagrant sandbox status
[web] - snapshot mode is off

10. 複数の仮想サーバを起動

Web システムでは複数台のサーバで構成することが多いのですが、その検証として複数の仮想サーバを起動してみましょう。

Vagrantfile で、config.vm.define を追加して、それぞれの仮想サーバの設定を記述します。以下の設定では、web サーバ 2 台と db サーバ 1 台を起動しています。
config.vm.define の第一引数が仮想サーバの名前となります。db サーバでは、db.vm.cusomise でメモリを 1GB に変更しています。（デフォルトは 512 MB）

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant::Config.run do |config|
  config.vm.box = "centos64_64"
  #config.vm.boot_mode = :gui

  config.vm.define :web1 do |web1|
    web1.vm.host_name = "web1"
    web1.vm.network :hostonly, "192.168.33.10"
  end
  config.vm.define :web2 do |web2|
    web2.vm.host_name = "web2"
    web2.vm.network :hostonly, "192.168.33.11"
  end
  config.vm.define :db do |db|
    db.vm.host_name = "db"
    db.vm.network :hostonly, "192.168.33.12"
    db.vm.customize ["modifyvm", :id, "--memory", 1024]
  end
end

vagrant up コマンドを実行すると 3 台が順番に起動します。

% vagrant up
[web1] ...
[web2] ...
[db] ...

% vagrant status
Current VM states:

web1                     running
web2                     running
db                       running

...

それぞれのコマンドは、仮想サーバ名を指定すると、対象の仮想サーバに対して実行できます。下記では db サーバを起動して、ssh ログインしています。

% vagrant up db
% vagrant ssh db

仮想サーバ間の通信は IP アドレスで可能なので、複数サーバ構成を構築することができます。

11. 仮想サーバのエクスポート

構築した仮想サーバを box ファイルにエクスポートすることができます。エクスポートした box ファイルは別の PC でインストールすることができるので、同じ開発環境をチームで共有したり、ベースとなるサーバ環境を用意しておいてプロジェクト毎に差分を変更していくなどが可能となります。

仮想サーバを box ファイルへエクスポートするには、vagrant package コマンドを実行します。

% vagrant package
[web1] Attempting graceful shutdown of VM...
[web1] Clearing any previously set forwarded ports...
[web1] Creating temporary directory for export...
[web1] Exporting VM...
[web1] Compressing package to: /Users/shin/vagrant/package.box

vagrant package コマンドが完了すると、package.box という box ファイルが作成されています。

% ls package.box
package.box

このファイルを vagrant box add コマンドでインストールすれば、この仮想サーバをベースに新たな仮想サーバを作成することができます。

まとめ

Vagrant は Chef や puppet などで自動構築する機能があるので、これらと組み合わせることでより真価を発揮します。
ただ、それらを使わずとも、手軽に触れるサーバ、壊せるサーバ、開発環境としても十二分に便利なツールです。

業務はもちろんですが、ハンズオンなどで参加者に同じ環境を配布したい時にも使えそうなので、活用していきたいですね。

参考

• Vagrantで簡単仮想マシン構築 | Ryuzee.com

Q. OS X, ruby, gem のバージョン（追記）

ykitade
現行のsaharaはパッチを当てないと使えなくね？OSXとrubyのバージョンが知りたい。
http://b.hatena.ne.jp/ykitade/20130323#bookmark-137571070

OS X は「10.8.3」です。

Vagrant は公式サイトの dmg ファイルからインストールしています。これなら ruby や gem をパッケージに内包しているので問題無く動作しました。バージョンは以下です。

% /Applications/Vagrant/embedded/bin/ruby -v
ruby 1.9.3p327 (2012-11-10 revision 37606) [universal.x86_64-darwin12.2.1]
% /Applications/Vagrant/embedded/bin/gem -v
1.8.23

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 を使ってみて下さい。

今年もやって参りました年末を彩る PHP Advent Calendar 2012 です。3年目ということですっかり恒例行事となってきましたね。今年も完走目指してみんなで頑張りましょう！

参加枠があとわずかですが残っていますので、いっちょやってみようという方は参加表明をお願いします。

• PHP Advent Calendar

さて、初日は前から書いてみたかったテーマです。

PHPをWebシステム開発言語として使い出してかれこれ12年が経ちました。これだけ長い間使い続けているとうことは何か理由があるわけです。そこで、あらためてその理由を考えてみました。

1. 安定して動作する

まず、なんと言っても大きいのが安定して動作し続けているということです。
規模の大小に関わらず数多くのWebサイトがPHPで動作しているのは周知のとおりです。私がこれまでPHPで構築してきたWebシステムが現在でも動作しており、これまでPHP自体が原因で障害が発生した、ということはほぼありません。

どんなに素晴らしい言語であっても動作環境が不安定では意味を成さないので、これは当たり前ですが大事なことです。

2. 環境構築が楽

Apache と mod_php を入れれば動作します。めちゃ簡単。下記コマンドを叩けばインストール完了。あとはPHPファイルをサーバにアップすれば、それで動きます。

$ sudo yum install httpd php

開発環境限定ですが、PHP5.4以降であれば、ビルトインサーバがあるので Apache すら必要ありません。

$ php -S 127.0.0.1

3. 手軽に書ける

HTMLのテンプレートから出発した言語だけに、HTML内に埋め込んで書くのは何の苦労もありません。

<?php if ($isDisp): ?>
  表示する
<?php endif; ?>

プログラマではないデザイナさんやコーダーさんもPHPであれば多少書ける人が多いです。ビュー側の簡単な改修であれば、わざわざプログラマ側で対応せずともデザインの延長で対応してもらえることが多いです。

また普段使っていると忘れがちですが、日本語を扱うのに何の苦労も必要ありません。実はこれは大きいことで、2000年当時だとPHP3国際化版があったおかげで、日本でPHPが普及したといっても過言ではないと思います。

4. HTTPリクエスト毎にスクラップ&ビルド

PHPではHTTPリクエストを受けて起動するたびにソースコードのコンパイルを行います。コンパイルで生成された実行コードで処理を行い、終了すれば実行コードごと破棄します。各 HTTP リクエストは独立して実行されるので、別のリクエストの処理が干渉することはありません。

これにより、ひとつのHTTPリクエスト内で行う処理に集中して実装することができます。

この一見すると重そうな処理が実用的なスピードで動作しています。

ちなみに apc などのコードキャッシュを使えばコンパイルした結果の実行コードをキャッシュすることができ、パフォーマンスを向上させることができます。デフォルトではアプリケーション内の値はキャッシュされないので、HTTPリクエスト毎の独立性は保たれています。

5. 豊富な機能、ライブラリ、プロダクト

PHPにはWebシステム開発に便利な機能が数多く提供されています。

標準関数の充実っぷりはもちろんですし、PECLで提供されている拡張モジュール、PEARやComposerで公開されているオープンソースのライブラリ、CakePHPやSymfony2、FuelPHPなどのフレームワーク、テスティングツールPHPUnit、WordPressやDrupalなどのCMS、EC-QUBEやMagentoといったECサイト、OpenPNEのようなSNS、他にもWebに特化した数多くのライブラリやプロダクトがあります。

OAuth などの新しい仕組みが登場してもすぐにそれを利用するライブラリなどが登場します。

オブジェクト指向としての機能もあり、いまどきの開発プロセスをこなすことができます。

Webシステム開発で必要な機能はひと通り揃っていると言って良いでしょう。

6. 情報が多い

ユーザが多いからこそですが、書籍やblogなどで数多くの情報が公開されています。

自分が情報やコードを公開した時も多くの反応をもらうことができます。これは使っていくモチベーションになりますね。

7. 仕事に使える

仕事に使える（使っている）のはやっぱり大きいですね。

これには安定性、実績、そして他の人とコラボレーションしやすいなどがあります。

また開発者以外の人にも認知度が高いので導入において支障になることもほとんどありません。

8. 最近のPHP

最近の PHP は言語の機能拡張が盛んで、ここ最近のバージョンでは以下のような機能が追加されています。

• namespace(5.3)
• closure(5.3)
• traits(5.4)
• short array syntax(5.4)
• array dereferencing(5.4)
• generator(5.5予定)
• finally(5.5予定)

もう今となっては当たり前ですが、5.2以前には匿名関数を定義するにはcreate_function()を使うしかなく、これが結構書きづらかったので、closureを自然に書けるようになったのはやっぱり嬉しいですね。

array_walk($values, function($v) {
  echo $v;
});

これらの機能がないと絶対にダメということは無いのですが、やっぱりこういった他の言語で良いとされている機能が盛り込まれるのは単純に嬉しいですし、使うのが楽しくなります。

• 6分でわかる最近のPHP – 2012夏
• 5分でわかる最近のPHP – 2011夏

9. 充実した公式マニュアル

良くPHPの特徴して挙げられますが、やはり公式マニュアルの充実っぷりは素晴らしいです。

日本語への訳も適時行われていますので、頭が下がるばかりです。

www.php.net

10. 慣れている

これを書くとPHPじゃなくてもええやん、という話になりますが、やっぱり慣れているというのは大きいです。

使い方、書き方、ハマりどころ、色々分かっていて、安心して使えるのでやはり選択することが多くなります。

11. PHPの思想

PHPはシステムを作るためのツールの一つとして認識しています。

現状はPHPを選択することが最も良いと思っていますが、状況が変わって、別の言語が良いと思えば、そちらの言語を選びます。何が何でもPHPというわけではなく、置かれている状況から判断して、あえてPHPを選択しています。

PHPコミュニティにいる人はこういった考えの人が多い印象です。

別にPHPしかできないからPHPを選んでいるわけではなく、別の言語も知っているし、書けるけど、PHPを選んでいるというわけです。

また、システムを作る、そしてそれを動かすということにフォーカスしている人は、その周辺の知識（サーバやインフラ、またテストなど）にも明るい人が多いです。プログラミング言語だけを見ているわけではなく、システム全体の中の一部としてPHPを捉えています。
（小さい案件などで全部やらざるを得ないという事もありますが）

これはシステム寄りではなくデザイナさんやコーダーさんも同じで、デザインやサイトの一つのツールとしてPHPを見ているという感じだと思います。

ここでPHPの父ともいうべき Rasmus Lerdorf さんの発言を引用しておきます。下記では、PHPを歯ブラシに例えて、あくまでツールと言い切っています。これはまさにPHPの思想ですね。

PHP is about as exciting as your toothbrush. You use it every day, it does the job, it is a simple tool, so what? Who would want to read about toothbrushes?
Interview – PHP’s Creator, Rasmus Lerdorf

12. コミュニティ

PHP コミュニティもPHPの魅力の一つです。 多様な人がいて、多様な活動をされています。いつも本当にお世話になっていますm(_ _)m

自分がいつも接していて良いなと思うのは、他の言語を貶めたり蔑むような発言をする人がいないということです。プログラミング言語の機能や思想について指摘したり、自分とは合わないといった発言をすることはもちろんあります。好き嫌いなどがあるのも当然です。

ただ、その言語を使っているというだけで晒すようなことはありません。

あくまでプログラミング言語はツールとして割り切っているからという面もあるでしょうけど、これはとても素晴らしいことだと思います。

PHPユーザがあえて煽る言語がPHPという自虐的な場面はたまに見ます:D たいてい愛情表現の一つだと思っていますけど、これからは恥ずかしがらずにPHP好きと言っちゃいましょう。

まだまだPHPです

たまにこんなことを聞かれることがあります。

「まだPHP使っていても大丈夫ですか？」

PHPがWebでメインストリームな時代が長いので、根拠は無くとも漠然とした不安を覚える人がいるようです。

現時点であれば、私ならこう答えます。

「はい、PHPで大丈夫ですよ。」

参考リンク

• PHP開発者 Rasmus Lerdorf氏インタビュー ～PHPは「利己的」な開発者の集まり：NEWS & REPORT｜gihyo.jp … 技術評論社
• Interview – PHP's Creator, Rasmus Lerdorf – SitePoint
• PHP: Dis Is It

共著で執筆に参加した「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開発の一助になればと思いますので、一度手にとって頂ければ嬉しいです。

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

さて夏がやってきました。夏と言えばPHPということで、昨年に引き続き、最近のPHP事情をご紹介。

1. PHP5.4リリース

PHP5.4が2012年3月にリリースされました。

Traits や Short array syntax（配列の短縮構文）、array dereferencing（foo()[0]） などのPHP言語拡張、PHPコマンドで起動するビルトインサーバ、そしてパフォーマンスの改善など大きな変更が加えられています。

言語自体の機能追加も注目ですが、ビルトインサーバは多くの人にとってメリットになるでしょう。これを使えばPHPアプリケーションの動作確認のためにApacheやnginxなどのhttpdサーバを自分のPCに入れる必要はありません。

下記のようなコマンドを打つだけで、ビルトインサーバが起動します。新しいフレームワークやライブラリ、アプリケーションを試してみたい時に手軽に使えるのが嬉しいですね。

$ php -S localhost 

2012/08/01の最新版は PHP5.4.5 となっています。これから新たにPHPアプリケーションを構築する際は、5.4で動作することを確認しておいた方が良いですね。

PHP 5.4.0 Release Announcement
PHP 5.3.x から PHP 5.4.x への移行
PHP5.4 Advent Calendar 2011

2. PHP標準コーディング規約 PSR–0 / PSR–1 / PSR–2

PHP コミュニティで標準的なコーティング規約が提唱されます。これが PSR–0 / PSR–1 / PSR–2 です。

これまでも PEAR や各フレームワークでそれぞれ独自のコーティング規約が使われていましたが、PHP として標準的なコーティング規約が出来たというのは初めてのような気がします。

すでにいくつかのフレームワークやライブラリはこの規約に従って書かれています。

PHPコードの書き方に迷っている人は一度目を通しておくと良いでしょう。

なお、この規約は提唱されているだけで、従わないといけないということではありません。ただ、できるだけ合わせた方が、多くの人にとって使いやすく、読みやすいコードになることは間違いありません。

PSR–0
PSR–1
PSR–2

PSR–1 / PSR–2 に合わせてコードを自動で修正するツールもあります。

PHPソースをコーディング規約に合わせて修正してくれるPHP Coding Standard Fixer
The PHP Coding Standards Fixer for PSR–1 and PSR–2

3. パッケージ管理システム Composer

PHP のパッケージ管理システムには PEAR があるのですが、現状は新たなパッケージがあまり増えず、盛り上がっているとはいえない状況です。（個人的には PHPUnit 系専用になっています）

そんな PEAR に代わって、盛り上がっているのが Composer です。

PEAR に比べて、導入も簡単ですし、パッケージも手軽に公開できるので、対応パッケージが増えています。

おそらく今後フレームワークやライブラリを導入する際は自然と触ることになると思うので、一度使い方を見ておくとよいでしょう。

Composer
PHPの外部ライブラリの管理にComposerを使う | Ryuzee.com
Composerの使い方を調べたメモ(1) – k-holyのPHPメモ

4. PHP The Right Way

ここまで紹介してきたようなPHPに関する情報を網羅したサイトが登場しました。それが「PHP The Right Way」です。

今風のPHPを使うにあたって参考になる情報が紹介されています。元は英語サイトなのですが、有志によって和訳されていますので、ぜひ一度見てみて下さい。

PHP: The Right Way

5. フレームワーク事情

最後に最近気になるフレームワークなどを。

5–1. CakePHP2 / CakePHP3

CakePHP2が2011年12月に正式にリリースされました。最新版は2.2.1です。

これから CakePHP をはじめる人は迷うこと無く 2 系からはじめましょう。

日本語情報が少ないという声もありますが、公式マニュアル（cookbook）の和訳も進んでいっていますし、2 に対応した書籍も登場してきています。実は執筆に関わっている書籍が来月あたりに出版されるので乞うご期待！

CakePHP
Security Release – CakePHP 2.1.5 & 2.2.1

さらに次期バージョンのCakePHP3の概要が発表されています。CakePHP3はPHP5.4以上を対象としており、新たなCakePHPとして進化しそうです。

3.0: a peek into CakePHP’s future

5–2. FuelPHP

巷で今一番注目されているフレームワークといえばFuelPHPでしょう。

FuelPHPは、PHP5.3以上で動作するCodeIgniterライクな軽量なフレームワークです。規約より設定を重視しており、設定でフレームワークの挙動が変えられるのは、ある意味PHPらしいです。

これからフレームワークを触ってみたいという人にも学習しやすく、パフォーマンスも良いのでアクセスが見込まれるサイトでも使い勝手が良さそうです。

すでに日本語で良質の書籍が2冊登場していますので、FuelPHPに興味がある人は手にとってみて下さい。

FuelPHP › A simple, flexible, community driven PHP5.3 framework

5–3. BEAR.Sunday

こちらも今、注目されているフレームワークです。

リソース指向のフレームワークとされていて、動作対象がPHP5.4以上という最新鋭のフレームワークです。また作者が日本人（@koriym さん）というのも大きな特徴でしょう。

FuelPHPが実用のフレームワークとして注目されているとすれば、BEAR.Sundayは学習のフレームワークとして注目されているように感じます。

現在は開発途中ということで、実用するのはまだ先かもしれませんが、個人的には一度じっくりと触ってみたいフレームワークです。

koriym/BEAR.Sunday
manual – bearsunday – BEAR.Sundayマニュアル – PHP 5.4 Resource oriented framework

次はPHP5.5?

次のPHPであるPHP5.5では、さらに言語を拡張して、ジェネレータやリスト内包表記などPythonのような記法を取り入れる提案がされています。

まだ実装されるかは分かりませんが、PHPはその時流行っている言語の良い所を取り入れる特徴があるので、PHPの新機能を見ると言語の流行りが見えるかもしれませんね。

Mac OS X に PHP5.4 を簡単に入れる方法です。

PHP5.4 使っていますか？

5.4 で実装されたビルトインサーバや traits、short array syntax などの新機能を試してみたい！でも 5.4 をインストールするのが面倒だなあ、というあなた、朗報です。

「PHP 5.3/5.4 for OS X 10.6/10.7 as binary package」というパッケージを使うと、簡単に PHP5.4 をインストールできます。

PHP5.4をインストール

方法は簡単。下記のコマンドを実行するだけです。

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 5.4

実行するとパッケージのダウンロードが始まりますので、しばらく待ちます。インストール処理で sudo を使っているので、パスワードが求められる場合があるので、パスワードを入力して進めて下さい。

はい、これで完了です。/usr/local/php5 以下に PHP5.4 がインストールされます。

$ /usr/local/php5/bin/php -v
PHP 5.4.2 (cli) (built: May  8 2012 09:48:57) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
    with Xdebug v2.2.0rc2, Copyright (c) 2002-2012, by Derick Rethans

ビルトインサーバもバッチリ動きます。

$ /usr/local/php5/bin/php -S 127.0.0.1:8000
PHP 5.4.2 Development Server started at Thu May 24 14:51:35 2012
Listening on 127.0.0.1:8000
Document root is /path/to
Press Ctrl-C to quit.

php.ini

php.ini ファイルは /usr/local/php5/lib/php.ini です。また、拡張毎の差分 ini ファイルが /usr/local/php5/php.d/ 以下にあります。

設定を変更する際は php.ini を直接変更するのではなく、新たに差分 ini ファイルを作成して変更箇所だけを記載するのが良いでしょう。

デフォルトでは timezone が Europe/Zurich になっているので、Asia/Tokyo に変更してみましょう。下記では、/usr/local/php5/php.d/99-my.ini というファイルを作成して timezone を Asia/Tokyo に変更しています。

$ sudo vim /usr/local/php5/php.d/99-my.ini 
date.timezone = Asia/Tokyo

$ /usr/local/php5/bin/php -i | grep timezone
Default timezone => Asia/Tokyo
date.timezone => Asia/Tokyo => Asia/Tokyo 

拡張モジュール

インストール拡張モジュールは以下です。かなり色々はいってますね。

$ /usr/local/php5/bin/php -m
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dom
ereg
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
igbinary
imap
intl
json
ldap
libxml
mbstring
mcrypt
memcache
mhash
mongo
mssql
mysql
mysqli
mysqlnd
OAuth
odbc
openssl
pcntl
pcre
PDO
pdo_dblib
pdo_mysql
pdo_pgsql
pdo_sqlite
pgsql
Phar
posix
Reflection
session
shmop
SimpleXML
soap
sockets
solr
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tidy
tokenizer
uploadprogress
wddx
xdebug
xhprof
xml
xmlreader
xmlrpc
xmlwriter
xsl
zip
zlib

[Zend Modules]
Xdebug

apc, twig, xslcach もインストールはされていますが、読み込まれていない状態になっています。必要であれば差分 ini ファイルを変更して有効にして下さい。

$ sudo vim /usr/local/php5/php.d/99-my.ini
date.timezone = Asia/Tokyo
# ↓を追加する
extension=/usr/local/php5/lib/php/extensions/no-debug-non-zts-20100525/apc.so

$ /usr/local/php5/bin/php -m | grep apc
apc

OS X 標準 Apache の mod_php を元に戻す

このパッケージをインストールすると OS X 標準の Apache の mod_php も PHP5.4 に置き換わります。5.4ではなく、既存の PHP を使う場合は以下の手順で設定を戻して下さい。

$ sudo rm /etc/apache2/other/+php-osx.conf
$ sudo vim /etc/apache2/httpd.conf
# LoadModule php5_module libexec/apache2/libphp5.so <--- コメントアウトを解除する

LoadModule php5_module libexec/apache2/libphp5.so

$ sudo /usr/sbin/apachectl restart

PHP5.4をアンインストール

インストールした PHP5.4 をアンインストールする時は、上記「OS X 標準 Apache の mod_php を元に戻す」手順を行ったあとに /usr/local/php5* と /usr/local/packager を削除するだけです。

$ sudo rm -rf /usr/local/php5*
$ sudo rm -rf /usr/local/packager

気軽にインストールできるPHP5.4

PHP5.4をインストールする方法としては、ソースからのビルド、MacPorts や Homebrew などのパッケージシステムからインストールするなど多くの方法があるのですが、どれもビルド環境を整えたり、パッケージシステム自体を入れる必要があるなど、ひと手間かかります。

この「PHP 5.3/5.4 for OS X 10.6/10.7 as binary package」であれば、PHP自体を入れるだけ（正確には packager という小さなパッケージシステムが一緒に入ります）なのでとても簡単ですし、元からインストールされている PHP への影響がないので、元のバージョンに戻すのも簡単です。

PHP5.4 を導入するのに躊躇している人、一度試してみて下さい。

PHPソースをコーディング規約に合わせて修正してくれるツール「PHP Coding Standard Fixer」を試してみました。

PHPでコーディング規約チェックツールとしては PHP_CodeSniffer が有名です。PHP_CodeSniffer はソースをチェックして、問題点を指摘してくれるのですが、ソースの修正は自分で行う必要があります。

PHP Coding Standard Fixerは、コーディング規約チェックだけではなく、規約に従っていないソースを修正してくれるツールです。

PHP Coding Standard Fixerを使う

インストール

インストールは簡単で、githubで公開されている php-cs-fixer.phar ファイル をダウンロードしてくるだけです。

実行する

ダウンロードしたphp-cs-fixer.pharファイルをphpコマンドで実行します。

第2引数には対象のPHPファイル、もしくはPHPソースディレクトリを指定します。ディレクトリを指定した場合は、そのディレクトリ以下の全てのソースが修正対象となります。

$ php php-cs-fixer.phar fix /path/to/dir
$ php php-cs-fixer.phar fix /path/to/file

コーディング規約（修正ルール）には PSR-1, PSR-2 の一部のがデフォルトで含まれています（PSR-1, PSR-2はまだ策定中:2012/05/22）。–level オプションで適用するコーディング規約を指定することができます。–levelを指定しない場合は、–level=allと同じになります。

$ php php-cs-fixer.phar fix /path/to/file --level=psr1
$ php php-cs-fixer.phar fix /path/to/file --level=psr2
$ php php-cs-fixer.phar fix /path/to/file --level=all

実際に適用されるルールはgithubに記述があるので、こちらを参考にして下さい。
https://github.com/fabpot/PHP-CS-Fixer

PHPソースを修正してみる

試しに以下のようなソースで試してみました。

このソースに php-cs-fixer.phar を実行します。

$ php php-cs-fixer.phar fix php-cs-fixer-sample.php
#!/usr/bin/env php
   1) /path/to/php-cs-fixer-sample.php

修正されたソースです。なにやら変更されていますね。主な変更箇所は以下です。

• 不要なuse文を削除
• インデントが4spaceに
• クラス宣言の開始ブレースが次行に
• PHP開始タグが <? から <?php に
• return文の前行を一行開ける

Vimプラグイン

Vimプラグインが公開されており、Vim上からPHP Coding Standard Fixerを実行することができます。
https://github.com/stephpy/vim-php-cs-fixer

自動で修正は楽

まだツール自体が荒削りで、対応しているルールが少ない、対応ルールとして挙げられているものが適用されなかったりしますが、発想としては面白いツールだと思います。日々開発しながら使っていけば、自然とコーディング規約に沿ったソースにしていけるので、これは便利です。

このツールでは実際にソースを変更してしまうので、万が一を考えて、修正後は自動テストを実行するようにしておくと安心ですね。

5/12に大阪産業創造館で PHPカンファレンス関西2012 を開催しました。

昨年に引き続き大阪市内でPHPカンファレンス関西2012を開催しました。イベント当日は多くの方にお越し頂き、セッション、懇親会を通じて盛り上がりました。

協賛頂いた各社様、スピーカーのみなさん、参加されたみなさん本当にありがとうございました。

個人的なトピックはこちらに書いたので、ここでは実行委員長として見たカンファレンスを書いてみたいと思います。

好きやねんPHP！

今回のテーマはずばり「好きやねんPHP！」でした。

PHPは何かと揶揄されることが多い言語です。PHPが嫌いな人が揶揄するだけでなく、PHPが好きな人、PHPを使っている人も自虐的にそういった発言をすることがあります。そこで、カンファレンスの時間くらいは、PHPの良いことろを見直して、好きになってみましょう！ということをオープニングで話しました。

テーマを決めるにあたってスタッフ間でも話したのですが、そもそも、なんでこういったイベントを開くか、の原点はまさにこれなんですね。

カンファレンスのクロージングで「PHPを好きになった人！」と聞いたところ、ほぼ全員の手をあがりました！（「もっと好きになった人！」を聞けば全員だったのに、聞き忘れてました＞＜）

今後もPHPが好きなら恥ずかしがらずに堂々と「PHPが好き」と言いましょう:D

2会場でマルチトラック、セッションは一般公募

カンファレンス全体で見ると、昨年との大きな違いは、会場を2会場にしてマルチトラックにしたこと、そしてセッションを一般公募したことです（昨年は LT のみ一般公募）。

この試みはどちらも正解でした。セッション数増加＋一般公募で、初心者向けから上級者向けまで、内容もPHP言語、クラウド、CMS、フレームワークと幅広いセッション構成を組むことができました。

どのセッションも興味深い内容でかつ発表自体もレベルが高いものばかりでしたので、参加された方にも楽しんで頂けたかと思います。

当たり前のことですが、やはりカンファレンスで最も大事なのはセッションだということをあらためて感じました。スピーカーの皆さん本当にありがとうございました。

なお当日録画したセッションの動画をカンファレンス公式サイトで公開していますので、ぜひご覧下さい。

プログラム – PHPカンファレンス関西2012

スタッフのみんなに拍手

Twitterやblogなどを見ていると、運営についてお褒めの言葉をいくつか頂きました。スタッフ全員が手弁当で運営しているだけにこういった言葉は何よりも励みになります。ありがとうございます！

実行委員長の自分から見ていても、スタッフのみんなの働きは素晴らしかったと思います。

イベント経験豊富なメンバーがいたことも大きいですが、それぞれがそれぞれの持ち場で的確に動いてくれました。当日、自分はほとんど何もしていないのですが、スムーズにイベントは進んで行きました。

こうして良いメンバーと一緒にイベントができたことは幸せなことです。このメンバーでなら、誰が実行委員長をやっても、きっと上手くいくと思います。みんな、本当にありがとう。

また楽しいイベントを！

昨年のカンファレンス、勉強会、そして今年のカンファレンスで、「関西でPHPのイベントを開催する」という流れは作れたと思います。今後はぜひその流れに乗って、イベントを企画や運営、そして発表する人が増えていくと良いですね。

カンファレンスのような大きなイベントは来年になるかもしれませんが、勉強会は開催していくつもりです。またみんなで楽しいイベントをやりましょう！

おまけ：実録！実行委員長の一日

実行委員長って何するの？という話があったので、カンファレンス当日の自分の行動を書いてみました。あらためて見ると何もしてないですね＞＜

8:30

朝一、事務所にスタッフ（@BiMihoujyun、@poego、@masa0221）と荷物取りに行く。

協賛企業さんの配布パンフ、カンファレンスパンフ、ステッカー、マジックやテープ等の文房具、電源タップ、懇親会景品などをタクシーで会場へ運ぶ。

Facebookを見ると公式サイト、パンフ、ステッカーをデザインしてくれた@nowebnolifeが体調不良で無念の欠席。パンフ、ステッカーのお披露目だっただけに残念。

9:10

産業創造館1Fカフェでスタッフ集合。軽く打ち合わせ（というか雑談）

9:20

鍵を受け取って、4F会場へ。それぞれ持ち場でセットアップ開始。

みんなは、受付ブース作ったり、スライド流したり、音響チェックしたり、電源並べたり。特にUst班の@spice_oが大忙し＞＜ 手が開いている人はひたすら配布パンフをクリアファイルに詰めていく。

何するわけでもなくウロウロしてみんなを見守る。

9:40

ブース出展の協賛企業さん到着。挨拶後、ブース設営を見守る。

9:50

オープニングムービー用にスタッフ写真撮影。

ちょうどみんな集まったから、昨年と同じく円陣組もうと思ってけど、みんな忙しそうにそそくさと持ち場に戻っていった。ちょっと寂しい。

10:00

開場。廊下で待って頂いていた方が続々と中へ。

入場を見守りつつ、色々な人にご挨拶など。

10:30

カンファレンス開始。まず@ixcy力作のオープニングムービーから。

ムービーを壇上で見つつ、ちょっとグッと来てた。朝一で感動するやつはダメだよ＞＜

オープニングでは普通に「うんうん」の練習をしたり。みんなノリが良くて嬉しくなった:D

張り切ってピンマイクで話したは良いが、終わった後もマイクがオンになっていて、しょうもない話が会場中に筒抜けに。。。

10:40

基調講演開始。
LT までは前に出ることはないので、6Fの様子を見に行ったり、あちこちウロウロ。

6Fに行くと @slywalker、@bren_boss、@masa0221、@papettoTVがセットアップしてた。実に頼もしい。

4Fに戻ってセッションを@sigesabaの後ろで聞く。チラ見すると黙々と @kphpug アカウントで tweet してた。仕事人だ。

11:30

6F セッションも開始。

@tenshowがすごいレンズで写真をバシバシ撮ってた。おおよそ趣味のカメラには見えない。

Twitterを見ると何やら忍者がいるらしい。4Fの展示ブースへ向かう。忍者と名刺交換というレアな体験。

合間合間で司会の@BiMihoujyunと進行について打ち合わせ。

12:15

午前中終了。今のところ問題らしい問題はなし。順調に回り出したので一安心。

というか問題があっても、その場でみんな解決するから、特に把握せず（いいのか？）。

一人ぼっちで昼食取っているのを@heavenshellに激写される。

13:10

午後セッション開始。セッション聞きつつ、相変わらずウロウロ。

なんかウロウロしてるけど、これと言ったことはしていない。

14時過ぎにイベントマスター@ixcyが別件のため無念の離脱。おつかれっした！

ふと受付ブースをのぞくと@d_sak、@yukarin33、@yamamasa、@poegoが何やら楽しそうにやってた。なんかキラキラして見えた気がしたが、けっして若さのせいではないと自分に言い聞かせる。

みんな進んであれこれアイデアを出してやっている。ホントすごい。

15:00

最後の LT に向けて準備開始。もちろん目玉のドラ娘さんも準備。

LT 順番抽選スクリプトを引きずり出したり、司会の@msngと打ち合わせたり。

壇上そばにいる撮影班@omoonの表情が固い。セッション前はなんだか落ち着かないね。

15:30

LT開始。自分の番はさらっと終わった。CakePHP2 の cookbook は良い。

他の人はみんなレベル高い。やっぱり LT は盛り上がる。

そしてドラ娘さんが適任すぎる。PHPカンファレンス関西はドラ娘充だ。

16:20

エンディング。ちょっと気のきいた言葉でも言えば良いのに思いつかず。

「もっとPHPが好きなった人！」は絶対に聞くべきだったorz

イベント最後に壇上から見る光景は素晴らしい。みんな良い笑顔！

希望者だけで集合写真。みんな良い笑顔:D

17:00

懇親会受付開始。懇親会開始までは色々な人とお話できた。

17:30

懇親会開始。開始の挨拶は準備で大奮闘の@nano_eight。

@msngの軽妙な司会で進んでいく。歓談、じゃんけん大会、LT。LTは笑いすぎて苦しかった:D

ここでもドラ娘と忍者が大活躍。

20:30

楽しい時間はすぐ過ぎるもの。最後も@nano_eightがしめて終わり。今年はバッチリしめてくれた。

21:00

もろもろ撤収。

最後にスタッフだけで簡単に〆。こういう時はかっこいいことが言えるようにちゃんと考えておこう。

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()に渡すという方法が問題も起こりづらいし、挙動も把握しやすいと思います。意識していなかった人はご注意を。