Home > PHP

PHP Archive

現状のPHP環境はそのままで、PHP 5.4 を試す

  • 2011-06-30 (木)
  • PHP
この記事の所要時間： 約 2分17秒

現状のPHPはそのままで、新しい（別の）バージョンをPHP試す方法です。

PHP

PHP 5.4.0 alpha がリリースされました。Traits や Array dereferencing support など試してみたいですけど、さすがにメインのPHP環境を変えるのは早いですね。

そこで新しいPHPをビルドして、インストールはしない方法で試してみました。

PHP 5.4.0 alpha をビルド

qa.php.netから、PHPのソースをダウンロードします。

$ wget http://downloads.php.net/stas/php-5.4.0alpha1.tar.bz2

展開して、configureして、makeします。とりあえずコンパイルオプションはナシで。

$ tar jxvf php-5.4.0alpha1.tar.bz2
$ cd php-5.4.0alpha1
$ ./configure
$ make

通常はこの後、make install に続くわけですが、今回はインストールせずにPHP-5.4.0alphaを動かしたいので、そのままで。

PHP 5.4.0 alpha を実行

CLI版PHPバイナリは、sapi/cli/php にビルドされているので、これを実行すれば ok です。

$ ./sapi/cli/php -v
PHP 5.4.0alpha1 (cli) (built: Jun 29 2011 16:10:51) 
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies

下記のようなソースで、Traits がさっくり動きます。

$ ./sapi/cli/php traits.php 
string(11) "TFoo::func1"
string(11) "TBar::func2"

手軽にお試し

別バージョンのPHPを同居させる方法としては、コンパイルオプションで –prefix を指定して、インストール先も変えるという方法もあります。

もちろんこの方法でも良いのですが、とりあえず新しいバージョンの機能を試してみたいというだけなら、このエントリの make install しない方法の方が手軽です。

今回ビルドしたPHPが不要になれば、ソースディレクトリごと削除するだけで良いです。

現状の環境には影響を与えず、手軽に新しいバージョンが試せるので、5.4 を触ってみて下さい。

コマンドラインからPHPマニュアルを見るpmanコマンド

  • 2011-06-26 (日)
  • PHP
この記事の所要時間： 約 4分30秒

コマンドラインからPHPマニュアルを見ることができるpmanコマンドが登場しました。

manコマンドのようにコマンドラインからPHP関数やSPLのクラスについて調べることができます。

インストール

pearコマンドでインストールします。

$ sudo pear install doc.php.net/pman

手元のMac OS X 環境では、/usr/bin/ に pman コマンドがインストールされました。

$ which pman
/usr/bin/pman

使い方

pmanコマンドに調べたい関数名を指定します。例えば、array_map のマニュアルを見たいなら以下のように指定します。

$ pman array_map

ARRAY_MAP(3)                                          1                                         ARRAY_MAP(3)

array_map - Applies the callback to the elements of the given arrays

SYNOPSIS
       array array_map (callback $callback, array $arr1, [array $...])

DESCRIPTION
       array_map(3) returns an array containing all the elements of $arr1 after applying the $callback func-
       tion to each one. The number of parameters that the $callback function accepts should match the  num-
       ber of arrays passed to the array_map(3)

PARAMETERS
              o $callback
                - Callback function to run for each element in each array.

              o $arr1
                - An array to run through the $callback function.

              o $array
                - Variable list of array arguments to run through the $callback function.

RETURN VALUES
        Returns  an array containing all the elements of $arr1 after applying the $callback function to each
       one.
(snip)

SPLなどオブジェクトのメソッドを調べるなら、クラス名＋”.”＋メソッド名を指定します。下記では、Exceptionクラスのコンストラクタを指定しています。

$ pman Exception.__construct

EXCEPTION.__CONSTRUCT(3)                              1                             EXCEPTION.__CONSTRUCT(3)

Exception::__construct - Construct the exception

SYNOPSIS
       public Exception::__construct NULL ([string $message = ""], [int $code], [Exception $previous])

DESCRIPTION
        Constructs the Exception.

PARAMETERS
              o $message
                - The Exception message to throw.

              o $code
                - The Exception code.

              o $previous
                - The previous exception used for the exception chaining.
(snip)

pman=ビーマン？

pmanコマンドの名称は「PHP man pages」です。呼び名はやっぱり「ピーマン」ですかね。

名前が示すとおり、pmanコマンドの実装を見てみると、manコマンドをラップしているだけでした。

今のところ英語版しか無いようですが、array関係など引数の順序があいまいな時にさっと調べるには便利そうです。

コードカバレッジ測定ツールPHP_CodeCoverageをCakePHPで使ってみた

この記事の所要時間： 約 6分4秒

PHP_CodeCoverageで、CakePHPのユニットテストのコードカバレッジを表示してみました。

php_codecoverage

CakePHP標準のテストランナー（test.php）でも単一のテストケースについてはコードカバレッジが表示できるのですが、All tests の時はコードカバレッジが表示されません（All testsでも表示されることもあるようです。hiromi さん、ありがとうございます）。

そこでPHP_CodeCoverageを使って、All testsのコードカバレッジを表示してみました。

1. PHP_CodeCoverage インストール

PHP_CodeCoverageは、PHPUnitでおなじみのSebastian Bergmannが開発した、コードカバレッジやCRAPを計測、表示するツールです。

PEARパッケージで提供されているので、pear コマンドでインストールします。

2011/06/15現在の最新版1.0.4では、PHP5.2.7以上とxDebugが必要となります。

sudo pear channel-discover pear.phpunit.de
sudo pear channel-discover components.ez.no

sudo pear install phpunit/PHP_CodeCoverage

ソースコードはgithubでも公開されており、README.markdownで詳しいインストール方法なども記載されているので、気になる人は見てみて下さい。

sebastianbergmann/php-code-coverage – GitHub

2. test.php のコードカバレッジを計測する

test.phpで実行する All tests のコードカバレッジを計測します。

test.php を直接改修して PHP_CodeCoverage を実行しても良いのですが、test.php を改修しない方法として、auto_prepend_file / auto_append_file を使う方法で実装します。

auto_prepend_file / auto_append_file を使うと test.php の実行前後に、自動実行するPHPスクリプトを指定することができます。そこで、auto_prepend_file ではコードカバレッジ計測を開始するPHPスクリプトファイルを、auto_append_file ではコードカバレッジ計測終了と結果を書きだすPHPスクリプトを指定します。

2-1. auto_prepend_file / auto_append_file を設定

httpd.confでauto_prepend_file / auto_append_file を設定します。

<VirtualHost *:80>
  ServerName example.com
  DocumentRooot /path/to/cakephp/app/webroot

  <Location /test.php>
    php_value auto_prepend_file /path/to/prepend.php
    php_value auto_append_file /path/to/append.php
  </Location>
</VirtualHost>

2-2. prepend.php

auto_prepend_file で指定したコードカバレッジ計測を開始するPHPスクリプトを実装します。

[/path/to/prepend.php]

ポイントは 7 行目から 14 行目で、PHP_CodeCoverage_Filterを使って、フレームワークやプラグイン、テストケース、 prepend.php、append.php を対象外にしています。

このあたりが考慮されているのがさすがですね。

2-3. append.php

auto_append_fileで指定したコードカバレッジ計測を終了して、結果ファイルを出力するPHPスクリプトを実装します。

[/path/to/append.php]

2-4. 結果出力ディレクトリ作成

append.phpでは app/webroot/coverage ディレクトリに結果ファイルを出力するので、あらかじめディレクトリを作成して apache ユーザに書き込み権限を付与しておきます。

$ mkdir app/webroot/coverage
$ chmod a+w app/webroot/coverage

3. test.php で All tests を実行

あとは普通にtest.phpで All tests を実行します。

テストが完了して /coverage/ にアクセスすると、下記のようなコードカバレッジ計測のレポートが表示されます。

php_codecoverage

内容は CakePHP 標準のコードカバレッジレポートよりも詳細で、全体、ディレクトリ単位、ファイル単位で、行数・メソッド数・クラス数でのコードカバレッジを確認することができます。

左のディレクトリ、ファイルはリンクになっており、クリックするとディクレトリ内のファイルを見ることができます。またファイルをクリックするとPHPソースが表示され、背景色によってその行が実行されたか否かが判別できるようになっています。

4. メモリーエラーが出たら

コードカバレッジ計測では多くのメモリを消費するのでテスト対象のソースファイルが多いと「Fatal error: Allowed memory size of 0 bytes exhausted」といったメモリ不足によるPHPエラーが出る場合があります。

エラーが発生した時は memory_limit にてPHPが確保できるメモリを増やします。

なお古いバージョンの test.php では memory_limit 設定がハードコーディングされている場合があるので、その際は test.php を直接書き換えて下さい。

[app/webroot/test.php]

-ini_set('memory_limit','128M');
+ini_set('memory_limit','512M');

手軽にコードカバレッジを表示

コードカバレッジを計測すること自体はxdebugを使うと簡単なのですが、それを集計して、見やすい形式にまとめてくれるという点で、PHP_CodeCoverage はかなり便利なツールです。

auto_prepend_file / auto_append_file を使う方法を応用すれば Selenium のテストでもコードカバレッジを計測することができそうです。これはぜひ試したいですね。

ここではCakePHPを対象としましたが、もちろん他のフレームワークやアプリケーションでも利用できるので、一度試してみてください。

Webシステム開発に便利な7つのツール

この記事の所要時間： 約 9分8秒

Webシステム開発で使っている便利なツールをあげてみました。

あらためて社内の開発環境を見直す機会があったので、使っているツールを並べてみました。こうして見ると色々なツールを使って開発をしていますね。わりと定番系なものが多いですが、良かったら参考にどうぞ。

1. Apache / PostgreSQL / PHP

Mac OS X に MacPorts でインストールしたApache / PostgreSQL / PHP 環境を使って開発をしています。

PHPは5.3、PostgreSQLは8.4 or 9.0です。

ただ旧バージョンのPHPを使ったり、Linux でなければ動かないモジュールを使うこともあるので、その際は社内のCentOSサーバにSSHで入って開発したりもします。

Vimを使ってるので、SSHで入ればどのサーバでも開発できるのは利点ですね。

Mac を使い出して、しばらくはこれで良かったのですが、たまにLinux環境が欲しい時があったり、社内スタッフと開発環境を揃えることを考えると、vmwareでLAPP環境を構築しておいて、それをみんなで共有するほうが良いかもしれません。

2. Vim

開発エディタにはVimを使っています。

昔はWindowsのPeggyを使っていたのですが、サーバにSSHで入ってメンテナンスする時にVimでもたもたするのがいやだったのと、何よりVimで颯爽とコードを書くのがかっこ良さそうだったのでメインで使うようになりました。

シェルの延長上で使えて、起動にストレスが無いですね。基本コマンドは手に馴染んでいるので、純粋に「書く」という行為については文句無いです。IDE並とは言わないですが、拡張していけば補完なんかもそれなりに効きます。

一度覚えておけば、Unix系を使う限りは下手すれば一生ものになるので楽できますね。

ただ絶対にVimじゃなきゃイヤだということも無くて、最近はNetBeansも気になったりもしてます。（Vimプラグインとかあるみたいだし）

http://www.vim.org/

3. xdebug

xdebug

PHPで開発している人にはおなじみのxdebugを入れてます。

インストールするだけで、PHPのエラーメッセージを見やすくしたり、スタックトレースを表示してくれたり、var_dump()した時が見やすくなったりで開発する時には嬉しい機能満載です。

例えば、PHPエラーが見やすくなって、スタックトレースが表示されたり。

xdebug_php_error

例えば、var_dump()で変数をダンプすると見やすくなってたり。

xdebug_var_dump_array

オブジェクトなら、インスタンス変数のアクセス権も表示してくれます。

xdebug_var_dump_object

他にも実行コードがトレースできたり、コードカバレッジを計測できたりと、とても重宝しています。

xdebug は pecl コマンドでインストールできます。

$ sudo pecl install xdebug

もちろん yum でもインストールすることもできます。

$ sudo yum install php-pecl-xdebug

PHPで開発する人ならぜひ開発環境に入れてみてください。

xdebug

4. Firefox

Firefox ブラウザ無料ダウンロード

Webを見るときのブラウザはChromeとFirefoxを併用していますが、やはりWebシステム開発に使うならFirefoxがメインです。

理由はアドオンが充実していることです。もちろんChromeでも同様のことができると思うのですが、使い慣れているということとFirefoxにしか無いアドオンがあるのが大きいですね。

豊富なアドオンの中でも特によく使うものをあげてみました。

4-1. Firebug

言うまでもなく定番のツールですね。

表示されているHTMLタグを確認したり、CSSを修正したり、JavaScriptのデバッグに使ったりと機能満載なのですが、Webシステム開発という意味では「ネット」が便利です。

ここを開くとブラウザからWebサーバへどのようなHTTP通信を行っているかが分かります。あるページを読み込むと画像やCSSが次々と読み込まれるのが分かります。

firebug_1

さらに各行をクリックするとヘッダを含む、リクエスト、レスポンスの内容が確認できます。

firebug_2

POSTの内容も見やすいです。

firebug_3

Firebug :: Add-ons for Firefox

4-2. Selenium IDE

自動ブラウザテストツールです。

Selenium IDEを使うとブラウザでの操作、入力を記録することができ、何度でも同じ操作を繰り返すことができます。さらにページやURL、Cookieなどの内容が想定されている値になっているかを検証することができます。

特に複雑な入力を伴うような購入フォームやユーザ登録などは、操作を記録してテストケースを作成しておくと、開発途中で動作確認するときに同じ操作を人がするのではなくツールにさせることができて、効率的です。

操作さえ慣れればかなり適用範囲の広いツールなので、Webシステムを開発する人でまだ使っていない人は一度試してみてください。

Selenium IDE

4-3. FireMobileSimulator

携帯電話対応のWebシステム開発では欠かせないツールです。

このツールを使うと擬似的に各キャリア、各機種の携帯電話からのアクセスを行うことができます。膨大な機種データが登録されており、新機種への対応も随時行われています。

画面サイズや絵文字表示などもシミュレートしてくれるので表示についても確認できます。（もちろん最終的には実機テストが必要ですが）

FireMobileSimulator.org

5. SimpleTest / PHPUnit

PHPでユニットテストを行うツールです。

SimpleTestはCakePHPで開発するときに使っています。それ以外で開発するときはPHPUnitを使うようにしています。

ユニットテストの効能については様々な情報があり、あえてここで触れる必要はないと思いますが、個人的に感じているメリットが２つあります。

5-1. 安心感を得る

テストを書いて、いつでもテストを実行できる環境を作っておくとそのコードが想定どおりに動く安心感が得られます。リファクタリングなどでコードを書き換える時もそうですが、開発が終了して何ヶ月か経った後でもそのコードが確実に動くことが保証できます。（もちろんテストを書いた範囲においては、ですが）

あと他人（数ヶ月後の自分を含む）が書いたコードがどのような動作を想定したものかを掴むことができます。

こうした書いたコードに対する安心感を得られるのが大きいです。

5-2. テストしやすいコード=独立性の高いコードを書くようになる

ユニットテストを書きだすと分かるのですが、メソッド内で様々なクラスと密結合になっていて様々な処理を詰め込んでいるとテストが書きづらくなります。

テストを書く段でそういった密結合を解きほぐしていって、メソッド毎の処理を小さな単に分けていくと、テストが書きやすくなり、自然と独立性の高い実装となっていきます。こうした独立性の高い実装はその役割がはっきりしているので再利用が容易となります。

独立性の高いコード、疎結合なコードを書くための訓練といういう意味でもテストコードを書くというのは効果があると思います。

とはいえ、やはりテストを書くのが面倒な場面はあるので、今はいかに効率的に（手間をかけずに）テストが書けるかを模索しています。

SimpleTest – Unit Testing for PHP
PHPUnit Manual

6. Redmine

社内の開発タスク管理にはRedmineを使ってます。

3,4年くらい前にBTSを導入しようとして、TracやMantisなども検討したのですが、複数プロジェクトが管理できるのとGUIが取っ付きやすそうだったので、Redmineを導入しました。

まだ今の使い方が正解かどうかは分からないですが、ざっくりとしたタスク単位でチケットを発行しています。チケットには仕様の詳細までは書いていないことの方が多くて、実際にアサインする時に打ち合わせで説明しています。

このあたりをどう活用しているのかは他の人と情報共有したいところですね。

Redmineの機能としては、やっぱりGitやSubversionなどのSCMと連携できて、コミットとチケットを関連付けられるのが便利ですね。チケットに対する変更差分をブラウザでさっと確認できます。

SCMを初めて使う人にとっても、commit / push した内容がブラウザで確認できるので分かりやすいみたいです。

http://redmine.jp/

7. Git / Subversion

ソースコードは、Git / Subversion で管理しています。

SCMはCVSから使いはじめました。その頃は一人で開発をやっていましたが、変更履歴や差分が取れるし、開発環境とテストサーバなど複数の箇所で同じソースが簡単に取得できるので、それ以来利用しています。（当時使っていたPeggy ProにCVS連携が付いていたのも一つのきっかけになりました。）

それからSubversionを使い出して、CVSのソースはSubversionに移行しました。スタッフが入って、複数人での開発になってからはさらにツールの重要性が増しました。誰がどう変更したかを間違いなく把握できるので、自分が書いたコードという意識も高まりますし、疑問点があってもすぐに書いた本人に聞くことができます。

そういえば、Redmineを使い出したのもSubversion連携があったというのもありますね。

そして昨年くらいからGitを使い出しました。まだベストプラクティスが決まらず、本来の分散リポジトリという部分は生かせていないですが、基本操作は浸透してきたので、そろそろ色々と模索していこうと思います。

Git – Fast Version Control System
Apache Subversion

ツールの提供者に感謝！

こうしてあらためて見ると普段多くのツールを活用して開発を行っていることが分かります。

ここで挙げたツールはいずれもオープンソースで配布されているものであり、無償で利用することができます。当然ながこうしたツールは誰かが開発しているもので、さらにテストをしたり、マニュアルを書いたり、それを翻訳する人がいたり、と多くの人の力で提供されています。

今後も感謝の気持ちを忘れず、どんどん活用していきたいですね。

PHPの基本、phpinfo()の見方

  • 2011-05-30 (月)
  • PHP
この記事の所要時間： 約 9分21秒

PHPerにはお馴染みの関数、phpinfo()の見方です。

phpinfo()

PHPには多数の設定項目があり、それらを一覧する機能としてphpinfo()があります。

設定項目の他にインストールされている拡張機能や実行環境の情報が確認できるので、おそらく多くのPHPerが活用していると思います。

これからPHPを学ぶ人ならおさえておきたいphpinfo()の見方をまとめてみました。

1. phpinfo()の実行

まずは基礎の基礎、phpinfo()の実行です。

phpinfo()自体はただの関数ですので、PHPソースに記載するだけで良いです。

以下のソースをinfo.phpというファイルで保存します。

<?php
phpinfo();

ブラウザでこのファイルにアクセスすればphpinfoが表示されます。

1-1. ファイル名は？

Webでのサンプルなどを見るとphpinfo.phpというファイル名にしていることが多いようですが、ファイル名は何でも良いです。

1-2. 他のスクリプトを書いても良い

phpinfo()関数ではこの関数が実行されたタイミングで情報を出力するので、その前後で他の処理を書いても問題ありません。

例えば、以下のソースではphpinfo()の前後で現在時刻を出力しています。

<?php
// 何か処理
echo date('Y/m/d H:i:s').'<br />';

phpinfo();

// 何か処理
echo date('Y/m/d H:i:s').'<br />';

1-3. アクセスできる IP を制限する

phpinfoの情報は広く公開すべき内容ではないので、もし公開サーバで設置するならアクセス制限をかけた方が良いでしょう。

以下のソースでは、接続元IPアドレスが「xxx.xxx.xxx.xxx」以外ではphpinfoを表示しないようにしています。

<?php if ($_SERVER['REMOTE_ADDR'] !== 'xxx.xxx.xxx.xxx') die(); ?>
<?php phpinfo(); ?>

常にphpinfo()を表示する必要は無いでしょうから、内容を確認したら削除しておきましょう。

1-4. 表示セクションを変更する

phpinfo()を引数無しで実行すると全てのセクションが表示されますが、引数を指定することで、表示セクションを指定することができます。

引数にはセクション毎にINFO_*という定数が用意されていますので、こちらを指定します。なお定数値は各ビットの値となっているのでビット演算子で連結して複数のセクションを表示することができます。

<?php
phpinfo(INFO_CONFIGURATION); // 現在のディレクティブ（設定）情報を表示

<?php
phpinfo(INFO_ENVIRONMENT | INFO_VARIABLES); // $_ENVで取得できる環境変数とEGPCSで設定されている値を表示

指定できる定数についてはPHPマニュアルを参考にして下さい。
=> PHP: phpinfo – Manual

2. phpinfoの見方

phpinfoには数多くの情報があります。実際の良く確認する内容から各セクションの見方を見ていきましょう。

2-1. PHPが動作しているかと確認する

phpinfo()

まずはPHP自体が動いているかをphpinfo()で確認します。おそらく多くの方がPHPをインストールした際にはとりあえずphpinfo()を実行するでしょう。

phpinfoが表示されれば、PHP自体は動作していることが確認できます。

2-2. コンパイルオプションを確認する [Configure Command]

phpinfo()
Uploaded with Skitch!

PHPには多くのコンパイルオプションがあり、指定によって様々な機能を有効無効にすることができます。

現在動作しているPHPではどの機能が有効になっているかと確認します。

上記はyum（RPM）でインストールしたPHP 5.3.6のコンパイルオプションですが、様々な指定がされています。

2-3. php.iniファイルの位置を確認する[Loaded Configuration File等]

phpinfo()
Uploaded with Skitch!

「Loaded Configuration File」でPHPの設定ファイルであるphp.iniのパスを確認します。

RPMでインストールしたり、ソースからインストールしたりと何度もインストールを繰り返しているような場合、どのphp.iniを読み込んでPHPが実行されているかが分からなくなる時があります。（php.iniを変更したのに設定が反映されず、結局他のphp.iniが有効になっていたり。）

そういった際に現在有効となっているphp.iniファイルを確認します。

またRPMなどパッケージでインストールされたPHPでは拡張機能毎に設定ファイルが分けられているケースがあるので、「Additional .ini files parsed 」でphp.ini以外で読み込んでいる設定ファイルを核にします。

2-4. 設定ディレクティブの値を確認する[Local Value][Master Value]

phpinfo()
Uploaded with Skitch!

Configureセクションには現在設定されている各設定ディレクティブの値が表示されます。

1行につき1ディレクティブとなっており、「Local Value」と「Master Value」の2種類が表示されます。

これらの違いはマニュアルで明記されているわけではないのですが、「Master Value」が、php.ini（PHP-FPMなら/etc/php-fpm.d/www.conf）の設定値、「Local Value」が、httpd.confや .htaccess、ini_set()で設定した設定値となっているようです。phpinfo()を実行した環境では「Local Value」の値が有効となっています。

（httpd.conf は、Local Value に表示されていました。@DQNEOさん、ご指摘ありがとうございました。）

「Local Value」と「Master Value」を見て、想定どおりの設定値となっているか、なっていない場合はLocal Valueで書き換えられていないかなどを確認します。

2-5. 拡張機能がインストールされているかを確認する

phpinfo()
Uploaded with Skitch!

PHPには多くの拡張機能があるので、どの拡張機能がインストールされているかを確認します。

拡張機能が有効になっているとConfigureセクション内に専用のセクションが表示されます。専用セクションでは拡張機能のバージョン、設定情報、設定ディレクティブも表示されます。

例えば上記であれば、apcが有効になっていて、各設定情報が確認できます。

よくあるパターンとしては、yumでphpをインストールするとmbstringやpgsqlが有効になっていないので、それらがインストールされているかと確認したりします。

2-6. 環境変数を確認する

phpinfo()
Uploaded with Skitch!

phpinfo()を表示している環境で定義されている環境変数を確認します。

通常あまり意識しないかもしれませんが、例えばhttpd.confで環境変数を定義して、その値によりPHPアプリケーションの挙動を変えたい時などに環境変数の値を確認したりします。

2-7. EGPCS変数を確認する

phpinfo()
Uploaded with Skitch!

EGPCS（$_ENV、$_GET、$_POST、$_COOKIE、$_SERVER）の値を確認します。

$_SERVERでHTTPリクエスト関連の値を見たり、$_COOKIEでセットされているcookieを確認したりします。

2-6 / 2-7 については、phpinfo()ではなく、PHPスクリプトでvar_dump()したりすることが多いですが、設定されている値が全て確認できるのは便利ですね。

おまけ. ブラウザの検索を使う

知りたい内容がはっきりしているなら、できるだけブラウザの検索機能（多くは[ctrl]+[f]）で、目的のキーワードを入力して検索しましょう。

目で上から順に追っていって探すこともできますが、見落としたり、あれ、どこだっけ？とあちこち見て回るのも無駄なので、知りたい内容がはっきりしているならさっさと検索した方が早いです。

もちろん全部を眺めてみたいという目的であれば、じっくり見るものアリです。

3. コマンドラインでphpinfo

ここまではブラウザでphpinfoを見る方法を紹介してきましたが、コマンドライン（CLI）環境でもphpinfoを表示することができます。

方法は、phpコマンドに「-i」オプションを付けて実行するだけです。出力はテキスト形式となります。

$ php -i
phpinfo()
PHP Version => 5.3.6

System => Linux xxx.xxxx.xxxxx 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:20 EST 2010 x86_64
Build Date => Apr 15 2011 18:10:43
.....

個人的にはブラウザ上よりCLIでphpinfoを確認することが多いです。良く使う方法としては以下です。

3-1. phpinfoをファイルに保存

$ php -i > info

3-2. php.iniファイルを探す

$ php -i | grep ini

iniファイルを見るには「php –ini」という方法もあるようです。（@murstsさん、ありがとうございました。）

$ php --ini

3-3. include_pathを確認する

$ php -i | grep include_path

3-4. apcがインストールされているか確認する

$ php -i | grep apc

phpinfo()でPHPの状態を知る

phpinfo()には多くの情報があるので、PHPがどのようにインストールされているか、どの機能が有効になっているか、設定ディレクティブにどの値が設定されているかを一元的に把握することができます。

PHPを活用していくなら避けて通れない内容ですので上手くphpinfo()を活用して下さい。

まずは手元の環境でどのような設定をされているかを確認してみてはいかがでしょうか。

PHPでsleep sort

  • 2011-05-20 (金)
  • PHP
この記事の所要時間： 約 0分27秒

コロンブスの卵的なソートアルゴリズム「sleep sort」をPHPで実装してみました。

via . 常識を覆すソートアルゴリズム！その名も”sleep sort”！ – Islands in the byte stream

fork使うので、pcntlを有効にします。

sudo port install php5-pcntl

さくっと実装。

実行

% php sleepsort.php
% 12345678910

nginx+php-fpmをyumでインストールして、WordPress/CakePHPを動かす設定

この記事の所要時間： 約 42分42秒

www.1×1.jpの環境をApache+mod_phpな環境から、nginx+php-fpmな環境へ移行しました。

さくらVPSのCentOS5.5環境にnginx+php-fpmをyumでインストールして、CakePHPとWordPressを動かす設定を行いました。

このエントリでは導入ということで、インストールから、とりあえず動作するところまでをご紹介します。

0. 構成

nginx+php-fpm環境にCakePHPとWordPressをインストールします。

それぞれ以下のURLでアクセスできるようにします。

http://www.1×1.jp/ -> CakePHP

http://www.1×1.jp/blog/ -> WordPress

1. インストール

nginxとphp-fpmだとソースからインストールするパターンが多いですが、ここではyumでインストールします。

1-1. remiリポジトリを登録

centosリポジトリにはnginx、php-fpmが含まれていないので、epel / remiリポジトリを登録します。

$ sudo wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
$ sudo wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
$ sudo rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm

1-2. yumでインストール

nginxとphp-fpmをyumでインストールします。–enablerepo=remi で1-1で登録したremiリポジトリを指定することを忘れないようにしましょう。

他にphp-mbstringやphp-cliなんかもいれてますが、このあたりはお好みで。

$ sudo yum -y install nginx php-cli php-fpm php-mbstring --enablerepo=remi

2011/05/16現在インストールされるバージョンは以下です。

$ /usr/sbin/nginx -V
nginx version: nginx/0.8.54
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-50)
TLS SNI support disabled
configure arguments: --user=nginx --group=nginx --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module --with-http_image_filter_module --with-http_geoip_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_stub_status_module --with-http_perl_module --with-mail --with-file-aio --with-mail_ssl_module --with-ipv6 --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'

$ /usr/sbin/php-fpm -v
PHP 5.3.6 (fpm-fcgi) (built: Apr 15 2011 18:13:37)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

2. nginxの設定

nginxの設定を行います。yumでインストールすると設定ファイルは /etc/nginx 以下に配置されます。/etc/nginx/nginx.confがメインの設定ファイルになっているのでこれを編集します。

Apacheの設定を知っていれば何となく理解できるかと思いますが、リクエストURIがlocationディレクティブにマッチすれば該当ブロックの設定が適用されます。

2-1. バージョン情報の出力をoff

HTTPレスポンスヘッダやエラーページでnginxのバージョン情報を出力しないようにします。

server_tokens     off;

2-2. gzipをon

gzipをonにします。

    gzip  on;

2-3. /blogをWordPressに

/blogというURLに対してWordPress用の設定を行っています。

内容はなんとなく分かるかと思いますが、前半のブロックでApacheでいうmod_rewriteのような設定を行っています。これにより存在しないディレクトリ、ファイルへのアクセスがあった場合は/blog/index.php?q=PATHへURLをリライトします。

後半のブロックがphp-fpm(FastCGI）の設定です。^/blog/.+\.php$にマッチするリクエストであれば、php-fpmへリクエストを送信します。

        # wordpress
        location /blog {
            alias   /path/to/wordpress;
            index  index.php;

            if (!-e $request_filename) {
                rewrite ^/blog(.+)$  /blog/index.php?q=$1 last;
                break;
            }
        }
        location ~ ^/blog/.+\.php$ {
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_split_path_info ^/blog(.+\.php)(.*)$;
            fastcgi_param  SCRIPT_FILENAME  /path/to/wordpress$fastcgi_script_name;
            fastcgi_intercept_errors on;
            include        fastcgi_params;
        }

2-4. /blog以外のURLはCakePHPに

/blog以外のURLに対してCakePHP用の設定を行っています。

2-3と同じく、前半のブロックでURLリライトの設定を行っています。存在しないディレクトリ、ファイルへのアクセスがあった場合は/index.php?url=PATHへURLをリライトします。

後半のブロックでは、\.php$にマッチするリクエストであれば、php-fpmへリクエストを送信します。

        # cakephp
        location / {
            root   /path/to/cakephp/app/webroot;
            index  index.php index.html index.htm;

            if (!-e $request_filename) {
                rewrite ^(.+)$  /index.php?url=$1 last;
                break;
            }
        }
        location ~ \.php$ {
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /path/to/cakephp/app/webroot$fastcgi_script_name;
            fastcgi_intercept_errors on;
            include        fastcgi_params;
        }

2-5. .htaccess / .git / .svnはアクセス禁止に

.htaccess / .git / .svnはアクセスできないようにしています。

        location ~ (\.ht|\.git|\.svn) {
            deny  all;
        }

2-6. /etc/nginx/nginx.conf

変更した /etc/nginx/nginx.conf は以下です。

#######################################################################
#
# This is the main Nginx configuration file.  
#
# More information about the configuration options is available on 
#   * the English wiki - http://wiki.nginx.org/Main
#   * the Russian documentation - http://sysoev.ru/nginx/
#
#######################################################################

#----------------------------------------------------------------------
# Main Module - directives that cover basic functionality
#
#   http://wiki.nginx.org/NginxHttpMainModule
#
#----------------------------------------------------------------------

user              nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log;
#error_log  /var/log/nginx/error.log  notice;
#error_log  /var/log/nginx/error.log  info;

pid        /var/run/nginx.pid;


#----------------------------------------------------------------------
# Events Module 
#
#   http://wiki.nginx.org/NginxHttpEventsModule
#
#----------------------------------------------------------------------

events {
    worker_connections  1024;
}


#----------------------------------------------------------------------
# HTTP Core Module
#
#   http://wiki.nginx.org/NginxHttpCoreModule 
#
#----------------------------------------------------------------------

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    server_tokens     off;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    gzip  on;
    
    server {
        listen       80;
        server_name  _;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        # wordpress
        location /blog {
            alias   /path/to/wordpress;
            index  index.php;

            if (!-e $request_filename) {
                rewrite ^/blog(.+)$  /blog/index.php?q=$1 last;
                break;
            }
        }
        location ~ ^/blog/.+\.php$ {
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_split_path_info ^/blog(.+\.php)(.*)$;
            fastcgi_param  SCRIPT_FILENAME  /path/to/wordpress$fastcgi_script_name;
            fastcgi_intercept_errors on;
            include        fastcgi_params;
        }

        # cakephp
        location / {
            root   /path/to/cakephp/app/webroot;
            index  index.php index.html index.htm;

            if (!-e $request_filename) {
                rewrite ^(.+)$  /index.php?url=$1 last;
                break;
            }
        }
        location ~ \.php$ {
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /path/to/cakephp/app/webroot$fastcgi_script_name;
            fastcgi_intercept_errors on;
            include        fastcgi_params;
        }

        location ~ (\.ht|\.git|\.svn) {
            deny  all;
        }
    }

    # Load config files from the /etc/nginx/conf.d directory
    include /etc/nginx/conf.d/*.conf;
}

3. php-fpmの設定

次にphp-fpmを設定します。 yumでインストールすると設定ファイルが/etc/php-fpm.confと/etc/php-fpm.d/www.confに配置されます。

php-fpm.confはとりあえずデフォルトのままで、www.confを編集します。変更するのは4箇所です。

3-1. 実行ユーザ

php-fpmの実行ユーザをnginxと同一にしておきます。

user = nginx

3-2. 実行グループ

実行ユーザと同じく実行グループもnginxと同一にしておきます。

group = nginx

3-3. プロセス生成方法

php-fpmの実行プロセス生成方法を指定します。動的にプロセス数を増減するならdynamicを、設定したプロセス数に固定するならstaticを指定します。

ここでは利用するリソースが把握しやすいstaticにします。

pm = static

3-4. 生成するプロセス数

生成するphp-fpmプロセス数を指定します。ここでは10プロセスを生成します。

他にpm.start_servers / pm.min_spare_servers/ pm.max_spare_serversといったプロセス数に関する設定がありますが、pm=staticの場合は影響ありません。

pm.max_children = 10

3-5. expose_phpをoffに

HTTPレスポンスヘッダに含まれるPHPバージョン情報を出力しないようにexpose_phpをoffにしています。

このようにPHP関連の設定はwww.confで記述することもできます。（もちろんphp.iniで設定しても良いです。）

php_admin_flag[expose_php] = off

3-6. /etc/nginx/nginx.conf

; Start a new pool named 'www'.
[www]

; The address on which to accept FastCGI requests.
; Valid syntaxes are:
;   'ip.add.re.ss:port'    - to listen on a TCP socket to a specific address on
;                            a specific port;
;   'port'                 - to listen on a TCP socket to all addresses on a
;                            specific port;
;   '/path/to/unix/socket' - to listen on a unix socket.
; Note: This value is mandatory.
listen = 127.0.0.1:9000

; Set listen(2) backlog. A value of '-1' means unlimited.
; Default Value: -1
;listen.backlog = -1

; List of ipv4 addresses of FastCGI clients which are allowed to connect.
; Equivalent to the FCGI_WEB_SERVER_ADDRS environment variable in the original
; PHP FCGI (5.2.2+). Makes sense only with a tcp listening socket. Each address
; must be separated by a comma. If this value is left blank, connections will be
; accepted from any ip address.
; Default Value: any
listen.allowed_clients = 127.0.0.1

; Set permissions for unix socket, if one is used. In Linux, read/write
; permissions must be set in order to allow connections from a web server. Many
; BSD-derived systems allow connections regardless of permissions.
; Default Values: user and group are set as the running user
;                 mode is set to 0666
;listen.owner = nobody
;listen.group = nobody
;listen.mode = 0666

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
; RPM: apache Choosed to be able to access some dir as httpd
user = nginx
; RPM: Keep a group allowed to write in log dir.
group = nginx

; Choose how the process manager will control the number of child processes.
; Possible Values:
;   static  - a fixed number (pm.max_children) of child processes;
;   dynamic - the number of child processes are set dynamically based on the
;             following directives:
;             pm.max_children      - the maximum number of children that can
;                                    be alive at the same time.
;             pm.start_servers     - the number of children created on startup.
;             pm.min_spare_servers - the minimum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is less than this
;                                    number then some children will be created.
;             pm.max_spare_servers - the maximum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is greater than this
;                                    number then some children will be killed.
; Note: This value is mandatory.
pm = static

; The number of child processes to be created when pm is set to 'static' and the
; maximum number of child processes to be created when pm is set to 'dynamic'.
; This value sets the limit on the number of simultaneous requests that will be
; served. Equivalent to the ApacheMaxClients directive with mpm_prefork.
; Equivalent to the PHP_FCGI_CHILDREN environment variable in the original PHP
; CGI.
; Note: Used when pm is set to either 'static' or 'dynamic'
; Note: This value is mandatory.
pm.max_children = 10

; The number of child processes created on startup.
; Note: Used only when pm is set to 'dynamic'
; Default Value: min_spare_servers + (max_spare_servers - min_spare_servers) / 2
pm.start_servers = 5

; The desired minimum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.min_spare_servers = 5

; The desired maximum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.max_spare_servers = 35

; The number of requests each child process should execute before respawning.
; This can be useful to work around memory leaks in 3rd party libraries. For
; endless request processing specify '0'. Equivalent to PHP_FCGI_MAX_REQUESTS.
; Default Value: 0
;pm.max_requests = 500

; The URI to view the FPM status page. If this value is not set, no URI will be
; recognized as a status page. By default, the status page shows the following
; information:
;   accepted conn    - the number of request accepted by the pool;
;   pool             - the name of the pool;
;   process manager  - static or dynamic;
;   idle processes   - the number of idle processes;
;   active processes - the number of active processes;
;   total processes  - the number of idle + active processes.
; The values of 'idle processes', 'active processes' and 'total processes' are
; updated each second. The value of 'accepted conn' is updated in real time.
; Example output:
;   accepted conn:   12073
;   pool:             www
;   process manager:  static
;   idle processes:   35
;   active processes: 65
;   total processes:  100
; By default the status page output is formatted as text/plain. Passing either
; 'html' or 'json' as a query string will return the corresponding output
; syntax. Example:
;   http://www.foo.bar/status
;   http://www.foo.bar/status?json
;   http://www.foo.bar/status?html
; Note: The value must start with a leading slash (/). The value can be
;       anything, but it may not be a good idea to use the .php extension or it
;       may conflict with a real PHP file.
; Default Value: not set
;pm.status_path = /status

; The ping URI to call the monitoring page of FPM. If this value is not set, no
; URI will be recognized as a ping page. This could be used to test from outside
; that FPM is alive and responding, or to
; - create a graph of FPM availability (rrd or such);
; - remove a server from a group if it is not responding (load balancing);
; - trigger alerts for the operating team (24/7).
; Note: The value must start with a leading slash (/). The value can be
;       anything, but it may not be a good idea to use the .php extension or it
;       may conflict with a real PHP file.
; Default Value: not set
;ping.path = /ping

; This directive may be used to customize the response of a ping request. The
; response is formatted as text/plain with a 200 response code.
; Default Value: pong
;ping.response = pong

; The timeout for serving a single request after which the worker process will
; be killed. This option should be used when the 'max_execution_time' ini option
; does not stop script execution for some reason. A value of '0' means 'off'.
; Available units: s(econds)(default), m(inutes), h(ours), or d(ays)
; Default Value: 0
;request_terminate_timeout = 0

; The timeout for serving a single request after which a PHP backtrace will be
; dumped to the 'slowlog' file. A value of '0s' means 'off'.
; Available units: s(econds)(default), m(inutes), h(ours), or d(ays)
; Default Value: 0
;request_slowlog_timeout = 0

; The log file for slow requests
; Default Value: not set
; Note: slowlog is mandatory if request_slowlog_timeout is set
slowlog = /var/log/php-fpm/www-slow.log

; Set open file descriptor rlimit.
; Default Value: system defined value
;rlimit_files = 1024

; Set max core size rlimit.
; Possible Values: 'unlimited' or an integer greater or equal to 0
; Default Value: system defined value
;rlimit_core = 0

; Chroot to this directory at the start. This value must be defined as an
; absolute path. When this value is not set, chroot is not used.
; Note: chrooting is a great security feature and should be used whenever
;       possible. However, all PHP paths will be relative to the chroot
;       (error_log, sessions.save_path, ...).
; Default Value: not set
;chroot =

; Chdir to this directory at the start. This value must be an absolute path.
; Default Value: current directory or / when chroot
;chdir = /var/www

; Redirect worker stdout and stderr into main error log. If not set, stdout and
; stderr will be redirected to /dev/null according to FastCGI specs.
; Default Value: no
;catch_workers_output = yes

; Pass environment variables like LD_LIBRARY_PATH. All $VARIABLEs are taken from
; the current environment.
; Default Value: clean env
;env[HOSTNAME] = $HOSTNAME
;env[PATH] = /usr/local/bin:/usr/bin:/bin
;env[TMP] = /tmp
;env[TMPDIR] = /tmp
;env[TEMP] = /tmp

; Additional php.ini defines, specific to this pool of workers. These settings
; overwrite the values previously defined in the php.ini. The directives are the
; same as the PHP SAPI:
;   php_value/php_flag             - you can set classic ini defines which can
;                                    be overwritten from PHP call 'ini_set'.
;   php_admin_value/php_admin_flag - these directives won't be overwritten by
;                                     PHP call 'ini_set'
; For php_*flag, valid values are on, off, 1, 0, true, false, yes or no.

; Defining 'extension' will load the corresponding shared extension from
; extension_dir. Defining 'disable_functions' or 'disable_classes' will not
; overwrite previously defined php.ini values, but will append the new value
; instead.

; Default Value: nothing is defined by default except the values in php.ini and
;                specified at startup with the -d argument
;php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f www@my.domain.com
;php_flag[display_errors] = off
php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on
php_flag[expose_php] = off
;php_admin_value[memory_limit] = 32M

4. nginx / php-fpmの起動

nginxとphp-fpmを起動します。

$ sudo /etc/init.d/nginx start
$ sudo /etc/init.d/php-fpm start

起動に成功すれば、0.0.0.0:80と127.0.0.1:9000がLISTENになっているはずです。

$ netstat -ltn | grep -E '(80|9000)'
tcp        0      0 127.0.0.1:9000              0.0.0.0:*                   LISTEN      
tcp        0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN

サーバ起動時に自動実行されるようにchkconfigで登録しておきます。

$ sudo /sbin/chkconfig nginx on
$ sudo /sbin/chkconfig php-fpm on

あとはCakePHP / WordPressをインストールすればokです。

5. 実際に使ってみて

Apache+mod_phpからの移行ということで基本Apache感覚で触りだしたわけですが、つまづいたというか気になったことを。

5-1. Aliasはaliasで

ApacheのAliasのようなことをやりたい場合、locationディレクティブでURIを指定して、そのブロック内ではrootではなく、aliasにてディレクトリを指定します。

        location /blog {
            alias   /path/to/wordpress;
            index  index.php;
        }

5-2. .htaccessは使えない

CakePHPでもWordPressでも使われている.htaccessですが、nginxでは利用できません（反映されません）。

nginxには.htaccessのようにサーバが設定ファイルを再読込することなく設定を動的に変更する方法はありません。

.htaccessで指定するような、アクセス制御、mod_rewrite、Basic認証等はnginx.confなどの設定ファイルにて記述し、nginxを再起動（再読込）を実行して設定ファイルを反映します。

# nginx 再起動
$ sudo /etc/init.d/nginx restart

# nginx 設定ファイル再読込
$ sudo /etc/init.d/nginx reload

5-3. Digest認証がない

nginxにはDigest認証を実現するモジュールは無いようです。以前はDigest認証を利用している箇所があったのですが、Basic認証は利用できるのでHTTPS+Basic認証で代用しました。

5-4. PHP関連の設定を変更したら

php.iniやwww.confでPHP関連の設定を変更した場合、php-fpmを再起動（再読込）します。nginxを再起動したところでphp-fpmには反映されませんのでご注意を。

# php-fpm 再起動
$ sudo /etc/init.d/php-fpm restart

# php-fpm 設定ファイル再読込
$ sudo /etc/init.d/php-fpm reload

5-5. rewrite対象URLにアクセスして画面が真っ白に

ここで設定した内容では、http://example.com/foo/bar といったファイルが存在しないURLへアクセスすると /index.php?url=URLというURLへrewriteして処理を行います。

こういった状況で画面が真っ白になるという現象がありました。

結局、原因はnginx.confの設定で、rewriteしたPHPスクリプトがSCRIPT_FILENAME で指定したパスに存在しない（アクセスできない）とこういった現象になるようです。

nginx、php-fpm どちらのログにも何も出力されなかったのではじめは嵌りました。もし同じ現象になった際はnginx.confのSCRIPT_FILENAMEの設定を確認してみて下さい。

nginxをはじめるのにオススメの本

これからnginxをはじめるなら「ハイパフォーマンスHTTPサーバ Nginx入門」がおすすめです。

現時点（2011/05/19）で日本語で書かれたnginx解説本がこれしか無いということもありますが、nginxをこれから利用するにとっては分かりやすく解説されています。

ただ、いきなりシェルコマンドやLinuxファイルシステム、システム管理ツールの解説が60ページほど続くので、この部分だけを立ち読みして「こりゃダメだ」と判断しないように注意して下さい:D このあと30ページほどnginxをインストールする内容があって、ようやく本編がはじまります。その後はしっかりとnginxについて解説されていますのでご安心を。

各ディレクティブの設定については公式WikiをはじめWebに情報があるのですが、設定の基本的な思想や細かなTipsなどは書籍にまとまっていると理解しやすいですね。php-fpmとの連携やApacheとの連携（リバースプロキシ）、Apacheからの移行なども簡単に解説されているので、Apahce+mod_phpから移行しようかなという方は一度手にとってみてください。

開発合宿関西3に参加してきました

この記事の所要時間： 約 3分44秒

滋賀で開催された開発合宿関西3に2泊3日で参加してきました。

場所は昨年もお世話になった琵琶湖湖畔にある「アクティプラザ琵琶」です。

ここは、無線LAN完備で、電源ももちろんあって、開発の大部屋があって、ゆっくり寝る部屋もあって、ご飯も美味しくて、空気も美味してくて、大きなお風呂があってと合宿するにはもってこいの環境です。

なんといっても周辺徒歩圏内には何にも娯楽施設（コンビニ含む）が無いので、がっつり開発に集中できるのが良いですね。昨年もこの環境のおかげで集中して作業できたので、味をしめてまた参加しました。

今回は、何かをじっくり作るというより、日頃やろうとしつつも手を付けられなかった事をあれこれやってきました。

1. www.1×1.jp のサーバ移行

先日のサーバ障害で一旦AWSへ移行していたwww.1×1.jpサイトをさくらVPSへ移行しました。

その際にこれまでApache+mod_phpだった環境をnginx+php-fpm構成へ変更しました。前々からこの構成には興味があったので、試せて良かったです。

これまでnginxはリバースプロキシや静的ファイル配信では利用していたのですが、factcgi連携は初だったのでハマりつつも初日に移行することができました。

nginx+php-fpm構成で、WordPressとCakePHPを動かすことができたので、詳細は別エントリに書きたいと思います。

ちなみに、このblogもnginxで動作しています。

2. follow-ok.in / iscot.in などのWebサービスのサーバ移行

その他サービスについては、nginxをリバースプロキシにしたLAPP環境へ移行しました。

移行自体はすんなり終わったのですが、さくらVPSのPort25が開いてないのでDNSの変更はしていません。ポートが解放されたら、DNSを変更する予定です。

1.と2.で別構成にすることで、nginxとPHPを使うならどちらが向いているのかを今後見ていくつもりです。

3. Behat / Selenium / Jenkins

やってみたかったことでテスト関連、特に Behat / Selenium / Jenkins を触ってみました。

Behatは、他の方のエントリを読むと準備が大変そうなイメージがありましたが、試してみるとxUnitを書く感覚でテンポ良く、テストが書けそうな印象を持ちました。

Seleniumは、Firefox4にIDEを入れるのにつまづいたりしましたが、PHPUnitのPHPUnit_Extensions_SeleniumTestCaseでテストケースを読み込んで実行できることが分かるなど発見がありました。（CakePHPがSimpleTestを採用していることもあって、PHPUnit自体をしばらく追っかけてなかったのですが、アノテーションで動作を指定できるとか全然知りませんでした。。。）

Jenkinsは、インストールまでは前もってやっていたので、実際のPHPプロジェクトで利用するパターンを試していました。とりあえずSeleniumで作ったテストケースについては、PHPUnitを使えば簡単に連携できたので、これは業務のプロジェクトでも利用してみます。

テスト関連は自分の中でも再燃しているところなので、もう少し追っかけていきます。

4. Kansai PHP Users Group 発足準備

Kansai PHP Users Groupという会を立ち上げようと思っていて、その準備をやっていました。

やっぱりみんなで話すとサクサク決まって良いですね。

詳細はまた後日:D

成果を出すイベント

このイベントは運営側から課題が出るわけではなく、参加者が自分で決めた課題を黙々とこなすイベントです。

集中して作業したり、ざっくばらんに雑談（技術話ももちろん込み）をしたり、のバランスが自然に上手く取れているのが良いなあ感じました。

参加したからには何らかの成果を出して帰りたいので、朝から晩（夜中）までみんなで頑張っていました。

意識の高い人達からの良い刺激を受けつつ、自分のタスクを集中してこなす。バタバタしている今となってはとても贅沢な時間を過ごせました。やっぱりこういう時間を取って自分なりに咀嚼していかないと枯渇する一方ですね。また行きたいなー。

さあ、AWSをはじめよう！ for PHPer

この記事の所要時間： 約 11分16秒

春ということで、Amazon Web Services（AWS）をはじめてみませんか。

AWS盛り上がっていますね。2011年3月に東京リージョンができたことで、そろそろ触ってみようかなというPHPユーザの方も多いかと思います。

そんなあなたへ、AWSをはじめる際に役立つ情報をご紹介です。

1. AWSアカウントを新規作成して、EC2の利用申し込みを行う

まずAWSのアカウントを作成して、EC2の利用申し込みを行います。

手順については、AWSエバンジェリストの @KenTamagawa さんが書かれた以下の資料が参考になります。このとおりに進めていけば、おおよそ問題無いと思います。

はじめてのアマゾンクラウド①[Amazon Web Services(AWS)のアカウントを開設する]

進める中で自分が詰まった点は以下。

郵便番号、電話番号にはハイフンを

郵便番号、電話番号はハイフンが必要なので入力するようにして下さい。

書式は日本国内のもの、郵便番号8ケタ（ハイフン入り）、電話番号は12〜13ケタ（ハイフン入り）で大丈夫です。

電話にびびらない

EC2の利用申し込みでAmazonから電話がかかってくる場面があります。

実は、はじめてアカウントを作成して利用しようとした時は申込画面も英語版しか無かったので、英語な人から電話がかかってくるのかと思って、それはそれはびびっていました。気持ちの整理を付けるために2,3日かかった記憶があります:D

まあ冷静に考えてみれば分かりますが、人がかけてくるわけではなく、機械がかけてきます。電話を取るとアナウンスが流れるので、あとは画面に表示された暗証番号をプッシュで入力すればokです。（人がかけてくる場面を想像すると面白いですが:-p）

暗証番号を入力するとすぐに次の画面に遷移するので、これはこれで近未来な感じがして感動しました。

クレジットカードが必要

アカウント作成、EC2の利用申し込みは無料ですし、サービスを利用（EC2インスタンスを起動など）しない限りは費用は発生しませんが、クレジットカードの登録は必須となります。ご注意を。

2. EC2を触ってみる

では実際にブラウザでAWS Management ConsoleへアクセスしてEC2インスタンスを起動してみましょう。

この手順についても、@KenTamagawa さんが書かれた資料が参考になります。

はじめてのアマゾンクラウド②[仮想サーバ(Amazon EC2)を立ち上げる]

補足としては以下の点あります。

SSHログインユーザ

このスライドのようにAmazon Linuxを利用する場合は「ec2-user」ユーザでSSHログインして下さい。他のOSで起動した際は、rootユーザでログインする場合もあるので間違えないようにご注意を。

SSHコマンドでログイン

SSHでログインするツールは、sshコマンドでも何でも良いです。その際はダウンロードした秘密鍵を -i で指定して下さい。

$ ssh -i /path/to/demo-key.pem ec2-user@PUBLIC_DNS_HOST

なお手元のMacではPublic DNSにあるFQDNを指定すると「ControlPath too long」というエラーが発生します。こういった場合は、Public DNSからIPを引いて、IP直で指定すればログインできます。（ただしIP変更が起こる場合があるので、可能ならFQDNでログインした方が良いです。）

$ dig ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com

xxx.xxx.xxx.xxx
$ ssh -i /path/to/demo-key.pem ec2-user@xxx.xxx.xxx.xxx

PHPのインストール

Amazon LinuxでPHPを利用するには、yumでインストールするだけです。

$ sudo yum -y install php

Amazon LinuxでインストールされるPHPのバージョンは、5.3.6です。（2011/04/12現在）

$ php -v
PHP 5.3.6 (cli) (built: Mar 29 2011 19:13:32)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

あとは必要に応じて、yumコマンドやpear、peclコマンドで追加していきましょう。

3. AWS SDK for PHP

まずAWSを利用する準備が整いました。

これからEC2インスタンス（サーバ）のセットアップをして、S3やEBS、RDSなどなどを活用していくと思うのですが、PHPerなら是非おさえておきたいのが「AWS SDK for PHP」です。

AWSはクラウド環境として多種多様なサービスを展開しているのですが、そういったサービスをAPIで操作することができます。例えばEC2インスタンスの起動、停止といった作業がどこからでもAPIで操作できるわけです。このAPIが揃っているのがAWSの特徴で、なかにはR53のようにAPIでのみ操作可能（AWS Management Consoleでは操作できない）なサービスがあるくらいです。

このAPIを活用すれば、独自の管理コンソールを構築することも可能で、実際そういったサービスも外部ベンダーから提供されています。

そんな便利なAPIなのですが、このAPIをPHPから簡単に操作できるようにSDKが提供されています。それが「AWS SDK for PHP」です。

3-1. 要件

AWS SDK for PHPは以下の環境で動作します。

PHPのバージョンさえクリアしておけば、あと必要なのはcURLくらいでしょうか。

ちなみに2.で構築したAmazon Linux環境のPHPでは、下記条件は全て満たされていました。

  • PHP5.2以上（5.2.14 or 5.3.x推奨）
  • SimpleXML / JSON / PCRE / SPL
  • cURL PHPエクステンション（HTTPSサポート）
  • file_get_contents() / file_put_contents() でファイルシステムを読み書きできる環境

3-2. インストール

AWS SDK for PHPはPHPソースで書かれたライブラリです。ダウンロードするだけで利用できますので、お好みの方法でインストールして下さい。

  • http://aws.amazon.com/sdkforphp からダウンロード
  • git
  • subversion
  • pear

ここではgitでインストールしています。

$ sudo yum -y install git  //git のインストール（git環境があれば不要）
$ git clone git://github.com/amazonwebservices/aws-sdk-for-php.git AWSSDKforPHP
$ ls
AWSSDKforPHP

要件やインストール方法はドキュメントがあるのでこちらを参考にして下さい。
=> Getting Started with the AWS SDK for PHP

3-3. 認証情報の取得

AWS SDK for PHPを実際に利用する際はAWSアカウントの認証情報が必要となります。

認証情報はAWSのWebサイトで取得できます。

まずグローバルナビの「アカウント」をクリックします。クリックするとアカウントのメニューが表示されるので下図のように「セキュリティ証明書」をクリックします。

セキュリティ証明書ページが表示されたら（もしログイン画面が表示されたらログインして下さい）、下図の「アクセス証明書」を表示します。ここにある「アクセスキーID」「シークレットアクセスキー」が認証情報となります。

3-4. サンプル

では実際にAWS SDK for PHP（以下、SDK）を使ってサンプルを作ってみます。

ここでは全リージョンのEC2インスタンスを取得して表示してみましょう。

サンプルファイルはSDKが入っているAWSSDKforPHPディレクトリと同じ階層に設置します。

$ ls
AWSSDKforPHP sample.php

サンプルソースは以下です。

まず require_once() でSDKを読み込みます(1)。これはどのサービスに対する処理を書く時も同じです。

次は、処理対象のリージョンを連想配列に格納しています(2)。SDKで処理を行う際は対象のリージョンをセットする必要があります。今回のサンプルでは全リージョンに対して処理を行うので、連想配列に格納しておきます。

次に、EC2へ処理を行うAmazonEC2クラスをインスタンス化します(3)。コンストラクタにて3-3で確認した認証情報をセットしています。第1引数が「アクセスキーID」、第2引数が「シークレットアクセスキー」となっています。

書籍のサンプルなどを見ると認証情報はSDK用の設定ファイルである「config.inc.php」に記載する例が多いのですが、個人的には認証情報は自分で管理したいのでコンストラクタで渡す方法がやりやすいです。

ここからAmazonEC2インスタンスに対して処理を行います。

まずset_region()で処理対象のリージョンを設定します(4)。そしてdescribe_instances()で対象リージョンのEC2インスタンス情報を取得して(5)、リージョン名とインスタンスIDをprintf()で出力しています。

この処理を各リージョン毎に行います。

3-5. 実行

ではサンプルソースを実行してみましょう。

下記結果から、us-westリージョンで1つ、ap-northeast（東京）リージョンで2つのEC2インスタンスが存在していることが分かります。

$ php sample.php
[us-west-1] i-xxxxxxxx
[ap-northeast-1] i-yyyyyyyy
[ap-northeast-1] i-zzzzzzzz

このようにAWS SDK for PHPを利用すると簡単な記述でAPIを実行して、AWSを操作することができます。

4. 参考書籍

Webに様々な情報があるとはいえ、これからはじめるなら、やはり書籍などまとまった情報をじっくり学びたいところです。

そこでAWSをこれからはじめるPHPerにおすすめな本をあげてみました。

G-CLOUD Magazine 2011

クラウド関連の情報が掲載されているムックです。AWSの特集があり、その中にAWS SDK for PHPの記事が掲載されています。

他にもAWSの記事も多く掲載されており、特にgumiさんの「Amazon EC2 API Tools」を活用したサーバ構築を自動化する記事が参考になりました。

Amazon Web Servicesガイドブック

AWSを活用するPHPerにはおすすめの定番本です。

この本ではAPIを利用してAWSを活用する実例が多数掲載されているのですが、それらのサンプルソースが全て「AWS SDK for PHP」を利用したものになっています。個人的にはタイトルを「AWS SDK for PHPガイドブック」にしても良いんじゃないかと思うくらいPHP満載のAWS本です。

内容も単に機能紹介を並べているのではなく、実際のWebサイトなどの構築を通じてAWSの各サービスを活用するアイデアが書かれています。

AWS SDK for PHP（aws.amazon.com)

書籍では無いですが、AWSサイトでは「AWS SDK for PHP」のドキュメントが公開されています。

導入方法にTips、そしてリファレンスが揃っており、SDKを活用していくには必須の内容となっています。

=> AWS SDK for PHP

AWSを触ってみましょう

いよいよクラウドの本格利用がはじまる今だからこそ、多種多様なクラウドサービスを個人で利用できるAWSを通じてクラウド利用の勘所を掴んでおくというのが大切だと思います。

さらに「AWS SDK for PHP」の存在により、PHPコードで手軽にそういったサービスをプログラムで操作することができます。

無料利用枠も提供されていますので、まだの人はぜひ一度AWSを使って、「プログラマブルデータセンター」と呼ばれるクラウド環境を体感してみてください。

PHPカンファレンス関西を開催しました #phpkansai

この記事の所要時間： 約 6分3秒

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

「東京で開催されているPHPカンファレンスを関西で！」という想いから昨年11月に会場の予約をしてから早半年、ようやくイベントを開催することができました。

イベント当日は多くの方に参加頂き、本セッション、懇親会を通じて盛り上がりました。

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

イベントを終えて1週間経ったいま、あらためてイベントを振り返ってみたいと思います。

3つのお願い

イベントのオープニングセッションにて参加されたみなさんに3つのお願いをしました。

1. 義援金

まず、義援金のお願いです。

東日本大震災にて被害に遭われたみなさんへ向けて義援金を募りました。本イベントはチャリティイベントではないのですが、みなさんから非常に多くの支援を頂きました。

義援金は、¥64,819-となり、こちら日本赤十字社へ送付しました。

送付は郵便局窓口で行ったのですが、郵便局員の方にとても感謝されました。私は代表で持っていったに過ぎず、この感謝の言葉はみなさんへ向けたものなので、ここで共有したいと思います。

みなさんご協力頂き、本当にありがとうございました。

2. 情報発信

情報発信を積極的にやって下さい、というお願いです。

セッションを聞きながらTwitterでtweetするというのは、こういったイベントに慣れていない人だとマナー違反と思い、躊躇してしまうかもしれません。しかし本イベントについては気にせずに思ったこと、感じたこと、学んだことをどんどん発信して下さいという話をしました。

そうした情報発信が当日イベントに来たくても来られなかった人への情報共有にもなります。

イベント当日は、みなさんから多くのtweetがあり、イベント会場の雰囲気が共有できたと思います。

Togetter – 「PHPカンファレンス関西のツイートまとめ」

参加された方のレポートも多数投稿されています。

フィードバック – PHPカンファレンス関西

3.楽しむ

せっかくイベントに参加されたのですから、しっかり楽しみましょう！というお願いです。

初のイベントということもあり、朝一は緊張している人も多かったように思いましたが、本セッションが進み、ライトニングトークで盛り上がった後のクロージングの頃にはみんな良い表情をしていました。

↑はクロージング後に希望者だけで撮影した集合写真ですが、みんな良い顔してますね:D

懇親会では一日の疲れ、緊張感から解放されたのもあり、さらに盛り上がりました！関西のPHPユーザ同士で、こういった場が作れたことが何より嬉しかったです。

多くの方から「次回も！」という声を頂きました。さらにアンケートでも90%以上の方が「次回も参加したい」と回答されていました。

もちろん不満に思われた部分もあるかと思いますが、みなさんの笑顔を思い返すと、関西初のイベントとしては一定の成果はあったのではと感じています。

セッションにてPHPに関する内容が少なかったのでは？

本セッションについて「PHPに関する内容が少ないのでは」という意見が多くありましたので、この点について。

このイベントのテーマである 「クラウド」「ソーシャルアプリ」「スマートフォン」 というのは、どれもPHPだけに限った話題ではないので、当初よりPHP色がやや薄くなるというのは想定していました。

しかし、どれもPHPユーザそしてWeb関連の人間にはとっては無視できない内容ですし、関西では語られることが少ないので、こういった機会にぜひ関西のPHPユーザに知ってもらいたいという考えがありました。

こうした意向を受けて各スピーカーの方へセッションをお願いしたので、それぞれのセッションはテーマに沿った素晴らしい発表を行って頂けました。セッション一つ一つについてはどれも満足度の高い内容だったかと思います。

あとは私の構成の問題で、これについては反省すべき点がありました。

参加された方からの意見でも「PHPに関する内容は少なかったけど、面白かった」「テーマに沿った内容で面白かった」といった意図していたとおりの意見もあったのですが、やはりもっとPHPに関する内容を期待していた人にとっては不満が残る部分もあったと思います。（ライトニングトーク以降でPHP成分は補充できた、という人も多かったです:D）

「PHPカンファレンス関西」という名前のイベントなので、PHPに関するセッションを期待されるのは当然のことです。

叱咤激励は次への期待だと受け取り、今後開催する際は熟慮したいと思います。ご意見頂いたみなさんありがとうございました。

イベントで外界を知る

後日、イベントに参加した弊社スタッフから聞いた感想が、まさにこのイベントを開催した意義を表していたので紹介します。

彼はこういったイベントに参加することが初めてだったので、イベント慣れしている人間からすれば当然の風景がとても新鮮に映ったようです。

  • MacBookやThinkPadなどのモバイルPCやスマートフォンを使っている人がこんなにいるということ
  • 今までWebでしか見たことの無い技術を実際に使っている人がいるということ
  • 意識の高い人が多いということ
  • そして関西にはこんなに多くのPHPユーザがいるということ。

こうした「外界」に触れる機会を関西で作る、というのがこのイベントを開催した意義です。

この経験をきっかけに今度は自分自身がその世界に飛び込んでくれることを期待しています。そして、そうした人が一人でも二人でも増えていってくれることが、このイベントを開催した人間からの望みです。

みなさん、ありがとうございました！

冒頭でも触れましたが、このイベントは数多くの方からの支援を頂いて開催することができました。

イベントでは話せなかったのでこの場を借りて。

日本PHPユーザ会からは本イベントサイトのサーバ、ドメインを支援して頂きました。また @koyhoge さんと @yudoufu さんからはイベント自体をやるかやらないかという段階で相談に乗って頂き、とても心強かったです。

次にCakePHPのコミュニティ、いつも一緒にイベントをやっている気心が知れたメンバーからのアドバイスはとても安心できました。「いつでも手伝うから、声掛けて。」この一言で何度も救われました。（ちなみにUst配信で利用したTwinPactは、配信職人 @suzuki さんから借りました:D）

そして最後に実行委員会のみんな。頼りない実行委員長だったかもしれないけど、最後まで「PHPカンファレンス関西を成功させよう！」という想いで一緒に頑張ってくれました。はじめましての人も多いなか、暗中模索で進んできたけど、イベントを通して最後には良いチームになれたと思います。また一緒にやりましょう。

他にも多くの方から協力、アドバイスを頂きました。本当に、本当にみなさんありがとうございました。

これが終わりではなく、はじまりです。関西から日本を盛り上げていきましょう！

ホーム > PHP

Masashi Shinbara
執筆したもの

固定ページ
最近の投稿
カテゴリー
アーカイブ
タグクラウド
検索
フィード
メタ情報

Return to page top