PHP: array_diff - Manualをよく読むと、こんな注意書きが。

注意:

二つの要素は、(string) $elem1 === (string) $elem2 の場合のみ等しいと見直されます。言い換えると、文字列表現が同じ場合となります。

要素が配列だと、string(5) "Array"同士の比較になっちゃうのね(´・ω・｀)

今回文字列化を試す変数

今回文字列化を試す変数は、bool型・int型・float型・string型・添字配列・連想配列を含んだ連想配列です。

$data = array(
	'bool'   => true,
	'int'    => 1,
	'float'  => 1.23,
	'string' => 'foobar',
	'array'  => array('apple', 'orange', 'strawberry'),
	'key-value' => array(
		'jp' => 'Japan', 
		'us' => 'USA', 
		'cn' => 'China',
	),
);

1. serialize()

この関数は変数を文字列化できることでよく知られています。変換された文字列は型・大きさ・値を保持するようになっています。

$serial = serialize($data);
var_dump($serial);
// string(285) "a:6:{s:4:"bool";b:1;s:3:"int";i:1;s:5:"float";d:1.229999999999999982236431605997495353221893310546875;s:6:"string";s:6:"foobar";s:5:"array";a:3:{i:0;s:5:"apple";i:1;s:6:"orange";i:2;s:10:"strawberry";}s:9:"key-value";a:3:{s:2:"jp";s:5:"Japan";s:2:"us";s:3:"USA";s:2:"cn";s:5:"China";}}"

シリアライズされた文字列を、再び配列に戻すにはunserialize()関数を使います。元のデータをしっかり復元してくれます。

$serialImported = unserialize($serial);
var_dump($serialImported);
/*
array(6) {
  ["bool"]=>
  bool(true)
  ["int"]=>
  int(1)
  ["float"]=>
  float(1.23)
  ["string"]=>
  string(6) "foobar"
  ["array"]=>
  array(3) {
    [0]=>
    string(5) "apple"
    [1]=>
    string(6) "orange"
    [2]=>
    string(10) "strawberry"
  }
  ["key-value"]=>
  array(3) {
    ["jp"]=>
    string(5) "Japan"
    ["us"]=>
    string(3) "USA"
    ["cn"]=>
    string(5) "China"
  }
}
*/
var_dump($data === $serialImported); // true

2. var_export()

var_export()関数はPHPとして解釈可能な文字列に変換します。第二引数に何も指定しないと、文字列に変換した結果が出力されます。変数に代入するときは第二引数にtrueを指定します。

$php = var_export($data, true);
var_dump($php);
/*
string(267) "array (
  'bool' => true,
  'int' => 1,
  'float' => 1.23,
  'string' => 'foobar',
  'array' => 
  array (
    0 => 'apple',
    1 => 'orange',
    2 => 'strawberry',
  ),
  'key-value' => 
  array (
    'jp' => 'Japan',
    'us' => 'USA',
    'cn' => 'China',
  ),
)"
*/

var_export()関数には、unserialize()関数のようにインポートする直接的に対応する関数はありません。そのかわりに、eval()関数で文字列を評価します。

eval('$phpImported = '.$php.';');

var_dump($phpImported);

/*
array(6) {
  ["bool"]=>
  bool(true)
  ["int"]=>
  int(1)
  ["float"]=>
  float(1.23)
  ["string"]=>
  string(6) "foobar"
  ["array"]=>
  array(3) {
    [0]=>
    string(5) "apple"
    [1]=>
    string(6) "orange"
    [2]=>
    string(10) "strawberry"
  }
  ["key-value"]=>
  array(3) {
    ["jp"]=>
    string(5) "Japan"
    ["us"]=>
    string(3) "USA"
    ["cn"]=>
    string(5) "China"
  }
}
*/

var_dump($data === $phpImported); // true

3. json_encode()

json_encode()関数は、JSON形式の文字列に変換します。この関数はPHP5.2で導入されました。

$json = json_encode($data);
var_dump($json);
// string(143) "{"bool":true,"int":1,"float":1.23,"string":"foobar","array":["apple","orange","strawberry"],"key-value":{"jp":"Japan","us":"USA","cn":"China"}}"

再び配列に戻すときはjson_decode()関数を使います。第二引数を指定しないと、戻り値がオブジェクト型になります。戻り値を配列型として受け取るには、第二引数にtrueを指定する必要があります。

$jsonImported = json_decode($json, true);

var_dump($jsonImported);
/*
array(6) {
  ["bool"]=>
  bool(true)
  ["int"]=>
  int(1)
  ["float"]=>
  float(1.23)
  ["string"]=>
  string(6) "foobar"
  ["array"]=>
  array(3) {
    [0]=>
    string(5) "apple"
    [1]=>
    string(6) "orange"
    [2]=>
    string(10) "strawberry"
  }
  ["key-value"]=>
  array(3) {
    ["jp"]=>
    string(5) "Japan"
    ["us"]=>
    string(3) "USA"
    ["cn"]=>
    string(5) "China"
  }
}
*/

4. http_build_query()

http_build_query()関数は、配列をクエリーストリング形式に変換します。この関数はPHP5から利用できます。

$query = http_build_query($data);
var_dump($query);
// string(170) "bool=1&int=1&float=1.23&string=foobar&array%5B0%5D=apple&array%5B1%5D=orange&array%5B2%5D=strawberry&key-value%5Bjp%5D=Japan&key-value%5Bus%5D=USA&key-value%5Bcn%5D=China"

デコードには、parse_str()関数を使います。第二引数を指定しないとextract()関数のように、配列のキーで変数を定義します。第二引数を変数すると、デコードした結果がその変数に代入されます。parse_str()関数はすべて文字列型に解釈するので注意が必要です。

parse_str($query, $queryImported);

var_dump($queryImported);
/*
array(6) {
  ["bool"]=>
  string(1) "1"
  ["int"]=>
  string(1) "1"
  ["float"]=>
  string(4) "1.23"
  ["string"]=>
  string(6) "foobar"
  ["array"]=>
  array(3) {
    [0]=>
    string(5) "apple"
    [1]=>
    string(6) "orange"
    [2]=>
    string(10) "strawberry"
  }
  ["key-value"]=>
  array(3) {
    ["jp"]=>
    string(5) "Japan"
    ["us"]=>
    string(3) "USA"
    ["cn"]=>
    string(5) "China"
  }
}
*/

var_dump($data === $queryImported); // false

1. Iを接頭辞にする

interface IUser {}

• ○ 慣れればインターフェイスだと比較的分かりやすいかも。
• ○ ファイル名でソートしたときに、インターフェイスが集まる。
• × Iが見えにくい。細い。
• 感想: ハンガリアン記法っぽくて嫌い。

2. Interfaceを接尾辞にする

interface UserInterface {}

• ○ インターフェイスって分かりやすい。
• ○ もうクラスがあって、それをインターフェイスに抽象化するときは、クラス名に接尾辞つけるだけ。
• × インターフェイス定義だけ見ると冗長。
• × 長い。
• 感想: 悪くないと思う。

3. -ableを接尾辞にする

interface Countable {}

• インターフェイスは能力を表すという世界観。
• ○ 慣れればインターフェイスって分かりやすい。
• → クラスに-ableを使うことを禁止しないとごっちゃになる。
• × 英語力がないとインターフェイス名考えるのが辛い。
• 感想: なんとなくいいかも。

4. 完全に自由

interface FooBar {}

• × クラス名とかぶるとめんどくさい。
• × type-hintingとかuseとかinstanceofでインターフェイスって分かりにくい。
• → 分からなくても困らないかも？
• ○ 臨機応変に名前をつけられる。

abstractとinterfaceの言語仕様はよく似てる。とても混同しやすい。PHPで自身をもって使い分けている人はどれくらいいるかな？少なくとも自分は全部abstractでもいいと思っている（いた）。でも、interfaceはオブジェクト指向できっと重要な概念だろうから、しっかり区別したいな。Twitterでオブジェクト指向に詳しそうな人に聞きいたり、ググったりして調べて自分なりに理解した内容をまとめてみるよ。

似てる点

• そのままでは呼び出せない。abstractはextends、interfaceはimplementsしてはじめて使える。
• 抽象メソッドを定義できる(see code.1)。ちなみにそれらは子クラスで必ず実装しないといけない。

// code.1
abstract class AbstractFoo
{
	abstract public function bar();
}

interface InterfaceFoo
{
	public function bar();
}

異なる点

• classはabstractを1つだけextendsできるが、classはinterfaceを複数implementsできる(see code.2)。
• abstractは具体的な実装があるメソッドを持てる。interfaceは単に抽象メソッドを列挙するだけ(see code.3)。

// code.2
class Hoge extends AbstractFoo
{
}

class Hoge implements InterfaceFoo, InterfaceFoo2, InterfaceFoo3
{
}

// code.3
abstract class AbstractFoo
{
	abstract public function bar();

	public function baz()
	{
		echo 'baz!';
	}
}

interface InterfaceFoo
{
	public function bar();
	public function baz();
}

この言語仕様を踏まえてどう使い分けるか?

「interfaceを使うくらいなら、abstract一辺倒でよくない？いざとなったらabstractに具体的な実装もできるしね」と思っている人はきっと自分だけじゃないと思う。ここではabstractじゃなくてinterfaceを使ったほうがいい、って例を説明していくよ。だから、interfaceのほうにフォーカスした内容になってる。読者はabstractの使い方をよく知っているし、よく使っているという前提ね。

仕様書はinterfaceにできるかも

interfaceは具体的な実装を持てない。これは設計書として利用できるかも知れない。今までドキュメントに書いていたクラスの仕様はinterfaceにすることができるってこと。例えば、こんな仕様書があったとする。

仕様書

• データベースクライアントクラスは次の4つのメソッドを提供しなければなりません。
• 書き込みメソッド。メソッド名: create()。引数は保存するデータ(連想配列)。
• 読み込みメソッド。メソッド名: load()。引数は読み込む行のID(整数)。
• 上書きメソッド。メソッド名: update()。引数は上書きする行のID(整数)と保存するデータ(連想配列)。
• 削除メソッド。メソッド名: delete()。引数は削除する行のID(整数)。

文書の仕様書を否定するつもりはないけど、人の言葉で書かれた仕様書は曖昧だったりする。上の仕様書でも、戻り値がよくわかんないし、update()の引数の順番は曖昧だし、引数は必須なのか任意なのか分かんない。

紙の仕様書は、メンテナンスされないこともあるよね。仕様書がなくともプログラムは正常に動作するから。もし、仕様書がプログラムに組み込まれたらどうだろう？仕様書がメンテナンスされなければプログラムが動かないので、仕様書をメンテするようになるよね、きっと。

上の仕様書は、interfaceに翻訳することができるんだ(code.4)。下の例のほうが文書の仕様書より曖昧性が低いよね。それに、仕様変更があったときもエラーとして気が付きやすい。例えば、複数行を取得したくなって、メソッドfind(array $condition)を追加したとする。find()を実装していないサブクラスはエラーになるんだ。

// code.4
interface DatabaseClient
{
	/**
	 * テーブルに行を追加する
	 * @returns bool 保存に成功したらtrue、失敗したらfalse
	 */
	public function create(array $data);

	/**
	 * テーブルの行のデータを取得する
	 * @returns mixed 読み込みに成功したら配列、失敗したらfalse
	 */
	public function load($id);

	/**
	 * テーブルの行を更新する
	 * @returns bool 保存に成功したらtrue、失敗したらfalse
	 */
	public function update($id, array $data);

	/**
	 * テーブルの行を削除する
	 * @returns bool 削除に成功したらtrue、失敗したらfalse
	 */
	public function delete($id);
}

これはabstractでも同じような書き方ができるね。でも、具体的な実装を持たないならinterfaceにしたほうがいいかもしれないよ。interfaceは実装を持てない。これって、シンプルという長所でもあるよね。仕様を提供する側のコストがミニマムになる。それに、プログラマは最低限のリードタイムで「ここだけ実装しておけばいいのね」ということが分かるようになる。abstractだったら、そのクラスの内部実装にまで目を配らないといけないよね。つまり、interfaceのほうが設計者とプログラマの両者にとってストレスが少ないってことになるね。（ひとりで開発する場合は別かもしれないけど）

呼び出し方は同じだけど、内部の処理は全然ちがう場合はinterface

最近のウェブアプリはログインするものが多いよね。内部的なこと言ったら認証処理だね。認証処理ってのは、アプリ側が「あなたはだれ？」が特定できればよくて、それ以外の関心はない処理なんだけど、一方で、認証処理は様々なものがある。アプリ独自の認証方式、OpenID、LDAP、Basic認証、Twitter認証、Facebook認証、社内独自認証などなど。

このケースだと、interfaceを活用できる。ウェブアプリは、認証方法の詳細について口出ししない。その代わり、「interfaceに実装してほしいauthorize()っていうメソッドを定義しておいたよ。」っていう約束だけ決めて(code.5)、「うちはそれだけを呼び出すから、あとはうまいことやってね」と具体的な認証方法は各認証オブジェクトにまるなげする。

// code.5
interface Auth
{
	/**
	 * 認証処理を行う
	 * @returns bool 成功したらtrue、失敗したらfalseを返す
	 */
	public function authorize();
}

それで、各認証方式を受け持つオブジェクトは、authorize()を独自に実装する(code.6)。

// code.6
class OpenID implements Auth
{
	public function authorize()
	{
		if ( $this->_openIdAuth() )
		{
			return true;
		}

		return false;
	}

	protected function _openIdAuth()
	{
		// オープンIDで認証する処理
	}
}

この例では、abstractはほとんど役に立たないよね。だって、ウェブアプリは認証方式の詳細に口出し（具体的な実装を提供）することができないから。各認証処理は全く異なった実装になるだろうね。具体的な実装の共通化は容易じゃない。無理して共通化に心を砕くくらいなら、interfaceにしたほうがいさぎよい、と思う。

まとめ

今回、調べていて気づいた点をまとめると、interfaceの出番は次のようになる。もっと、勉強してinterfaceを上手く使えるようになりたいな。

• 仕様書はinterfaceにできるかも
• 呼び出し方は同じだけど、内部の処理は全然ちがう場合はinterface

参考になるページ

• PHPのinterfaceとabstractを正しく理解して使い分けたいぞー ::ハブろぐ
• PHPにはインターフェイスというものがありますよ、という話 - id:anatooのブログ
• ふじやん雑記帳 - とりあえずインターフェース入門
• ５章　インターフェース --Interface--

『XOOPS Cube Legacy デベロッパーズ・バイブル』

XOOPSで有名なMarijuanaさん、しゃのさんの著書です。XOOPS Cubeで実装された新機能、プリロード、デリゲートの利用方法、XOOPS Cube Legacyらしいモジュール開発手法、複製モジュールの開発方法などついて詳しく書いてあります。

『パーフェクトPHP』

PHPを体系的に学びたい方にオススメです。PHPの概要にはじまり、初心者がつまずきやすいクラスやオブジェクトなど基礎的な部分はもちろん、フレームワークを使った最近の実践的な開発手法、そして忘れてはいけないセキュリティにいたるまで、網羅的に学ぶことができます。最近出たばかりの本なので、最新情報にも詳しいです。著者もPHP業界で非常に活発な方たちである、sotarokさん、fivestrさん、そしてXOOPS業界でも有名なgusagiさんによって書かれています。

『PHP ポケットリファレンス』

やりたいことからPHPの関数を探すのに便利です。たとえば、「ファイル全体を安全に読み込みたい」というやりたいことから、関数を調べることができます。PHPのオンラインのマニュアルだとどうも分かりにくいという方にも、この本は簡潔にエッセンスだけを提示しているのでおすすめです。私も、この本はボロボロになるまで使いました。

『PHPサイバーテロの技法―攻撃と防御の実際』

XOOPSのモジュールは公開されてしまえば、常に攻撃の脅威にさらされることになります。モジュール開発者はそうした攻撃に強く脆弱性のないPHPの書き方についてよく知っておく必要があります。この本は、クラッカーがどのような攻撃をしてくるか説明した上で、その防御策を説明しているので理解しやすい内容になっています。著者はこれまたXOOPS業界で有名なGIJOEさんです。XOOPSってほんとにPHP業界でも著名な人が多いですね。

cd /Applications/MAMP/bin
ln -s php5.3 php5 # シンボリックリンクを貼らないとMAMPのバグでPEARがおかしくなるっぽい
php5/bin/pear channel-discover pear.phpunit.de
php5/bin/pear channel-discover components.ez.no
php5/bin/pear channel-discover pear.symfony-project.com
php5/bin/pear channel-update pear.php.net
php5/bin/pear upgrade pear
php5/bin/pear install phpunit/PHPUnit
cd php5.3/bin/
open -a Coda phpunit # 自分のエディタで開く(Coda, Textmate, vimなど)

#!/Applications/MAMP/bin/php5/bin/php

#!/Applications/MAMP/bin/php5.3/bin/php

sudo ln -s /Applications/MAMP/bin/php5.3/bin/phpunit /usr/bin/phpunit5.3
phpunit5.3 --version

PHP5.2にPHPUnitをインストールする

cd /Applications/MAMP/bin
rm -f php5 # 上のPHP5.3の手順をやった場合
ln -s php5.2 php5
php5/bin/pear channel-discover pear.phpunit.de
php5/bin/pear channel-discover components.ez.no
php5/bin/pear channel-discover pear.symfony-project.com
php5/bin/pear channel-update pear.php.net
php5/bin/pear upgrade pear
php5/bin/pear install phpunit/PHPUnit
cd php5.2/bin/
open -a Coda phpunit # 自分のエディタで開く(Coda, Textmate, vimなど)

#!/Applications/MAMP/bin/php5/bin/php

#!/Applications/MAMP/bin/php5.2/bin/php

sudo ln -s /Applications/MAMP/bin/php5.2/bin/phpunit /usr/bin/phpunit5.2
phpunit5.2 --version

参考

• MAMP Forum • View topic - phpunit on MAMP 1.9.5 broken and work around

error_reporting(-1);
ini_set('display_errors', 1);

ob_start(); // 出力バッファ開始

while ( true )
{
	phpinfo();
}

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 33300481 bytes) in /Applications/MAMP/htdocs/php/ob_filter/memory.php on line 10

出力バッファを解除するには、echoなどの直前で次のような関数を1回だけ実行するだけである。

function clearOutputBuffer()
{
	while ( ob_get_level() > 0 )
	{
		ob_end_clean();
	}
}

標準入力のよくある渡し方

• 実行結果をパイプ | で繋いで渡す

  commandA | commandB
  # commandAの実行結果がcommandBに渡る
  

• 小なり < で後ろから渡す

  command < data.txt
  # data.txtの内容がcommandに渡る 
  

PHPで標準入力を取得する方法

php://stdinをファイル操作系の関数で読み込むだけ。たったそれだけ。

<?php
$stdin = file_get_contents('php://stdin');
var_dump($stdin);

CSVを渡してデータを操作したり、いろいろ使えそう。

phpコマンドにlオプションを指定することで、特定のファイルの構文チェックができる。エラーの詳細は、php.iniで指定したエラーログに出力されるので、そちらを確認する。

php -l /path/to/file.php

2. 成功・失敗はexit()の引数で切り分けよう

exit()の引数に整数を指定すると、端末側に処理が成功したか失敗したかを伝えることが可能。成功で終わったことを伝える場合は、exit(0);というふうにし、失敗で終わったという場合は、exit(1);か1以上の整数を与える。

<?php
echo "成功しました".PHP_EOL;
exit(0);

<?php
echo "失敗しました".PHP_EOL;
exit(1);

(ちなみに、私のプロンプトは前回のコマンドが失敗したときは、顔文字が赤くなるように細工してあるので、exit()の引数が働いているのがよくわかります。)

3. メッセージ出力用の関数をつくろう

メッセージの出力は、単純にecho 'message';とやってもいいのだが、これだと改行されないので、見づらくなってしまう。改行を有効ににするには、echo "message\n";のように最後に改行コードを付ける。ただ、毎回改行コードを文字列に埋め込むのは非効率的なので、下のようなメッセージ出力用の関数を作って、その関数で運用したほうが100倍楽だ。

function print($message)
{
	echo $message.PHP_EOL;
}

4. エラーメッセージの出力用の関数をつくろう

「メッセージ出力用の関数」と同様にエラーメッセージの出力も関数にしておくのがおすすめ。「え？エラーメッセージって普通にechoするだけでいいんじゃないの？」と思われそうだが、echoは標準出力になるので、実行端末側が普通のメッセージなのかエラーメッセージなのか区別できなくなる。実行端末と上手く連携するためには、エラーメッセージは「標準エラー出力」に吐き出すことが得策だ。標準エラー出力先はphp://stderrになる。エラーメッセージの出力用の関数の最も単純な実装が下の例だ。

function error_message($message)
{
	file_put_contents('php://stderr', $message.PHP_EOL);
}

エラーメッセージを標準エラー出力に吐き出すようにしておくと、例えばcronでエラーの時だけメールがほしいといった場合に便利。crontabを次のように、設定しておくだけでエラーに気づけるようになる。

0 4 * * * php /path/to/scheduled_job.php > /dev/null
# 標準出力は捨てて、標準エラー出力はメールに送られる。

5. exec()関数はラップして使おう

外部コマンドを実行するexec()関数ですが、ラップした関数を用意しておこう。自分がよく使うラッパーは次のような実装だ。

function execute($command, $captureStderr = false)
{
	$output = array();
	$return = 0;

	if ( $captureStderr === true )
	{
		$command .= ' 2>&1';
	}

	exec($command, $output, $return);

	$output = implode("\n", $output);

	return array('output' => $output, 'return' => $return);
}

exec()関数の第二引数はデフォルトではエラー出力を受け取らないので、エラー出力をキャプチャする必要がある場合には、コマンドに 2>&1 を埋め込む必要がある。上のラッパーでは、第二引数でエラー出力を受け取るか指定できるようにしている。

6. プロセスは小分けにしよう

Webインターフェイスだと、プロセスの寿命は長くてもせいぜい3秒程度だが、バッチ処理などを実装すると、どうしてもプロセスの寿命が長くなってしまう。プロセスの実行時間が長くなれば、メモリの使用量も大きくなりがりなので、メモリオーバに陥る危険性も必然的に高くなる。メモリ管理に自身のあるプログラマならメモリの残りを見ながらプロセスをコントローラすべきだ。が、もしメモリ管理に不安を覚えるようであれば、プロセスの寿命を短くすることに注力しよう。プロセス実行時間が短くなれば自ずとメモリオーバの危険性も低くなる。

実行時間を短くするTipsとして、最も単純なのがプロセスを小分けにする方法だ。exec()関数で、サブプロセスのPHPを実行するだけである。

exec("php subprocess.php", $output, $return);

7. 変数のスコープは狭くしよう

メモリオーバの対策として、できるだけグローバル変数を使わないという方法もある。グローバル変数はプロセスが終了しないかぎり、メモリから解放されないが、関数内の変数はスコープが切れると直ちにメモリから解放される。なので、できるだけメソッドや関数に小分けにして実装するのがおすすめだ。

<?php

function hoge()
{
	$bar = range(0, 1000);
}

$foo = range(0, 1000);
hoge();
// $barはここで開放される

// 長い処理…

// $foo は最後の最後まで開放されない

8. 実行権限に注意しよう

特にLinux系のサーバで実行するときは、実行権限に注意する必要がある。root権限で実行されるのか、apache権限で実行されるのか、それとも別のユーザ権限で実行されるのか。ファイル操作や、コマンドの実行で、権限によってエラーになったり実行できなかったりする。今、このPHPが誰によって実行されているか確認するには、passthru('whoami');を実行するといいだろう。

9. apache権限でsudoするときはコマンドごとにNOPASSWDを設定しよう

どうしてもapcahe権限でsudoする必要があるときがある。そんなときは、visudoでapacheをsudorに追加しておこう。その際、apacheに無条件でsudoできるようにするのは危険なので、コマンドを絞ろう。そして、そのコマンドに関してはパスワードなしで実行できるようにしよう。パスワードなしで実行できるようにするのは、PHPでインタラクティブにパスワードを入力するのは実装が面倒だからだ。

apache  localhost=(ALL) NOPASSWD: /path/to/command.sh, /path/to/command2.sh, /path/to/command3.sh

/path/to/command.shの中身は例えば、次のような例だ。たとえ、lsやmkdirのような単純なコマンドでも引数も含めてshファイルに固定しておき、lsやmkdirの実行権限自体は与えないようにする。そうすることで目的のコマンドを安全に実行できるようになる。

#!/bin/sh
ls /root
mkdir /root/newdir

PHP側の実装は、exec()関数を次のように叩くだけだ。

exec('sudo /path/to/command.sh');

余談だが、sudoするときの別の裏技として、apacheにパスワードを設定しておき、sudo -Sを利用する方法がある。ex.「echo "apache passowrd here" | sudo -S ls /root'」

10. プロセスはロックが必要か検討しよう

cronなどで処理の実行をスケジュール化しているとき、スケジュールの間隔が数分単位など短くなっていると、前のプロセスが完了する前に次のプロセスが走ってしまう場合がある。

process 1 -------------------------------------------------------->
process 2                    ------------------------------------------------------>
                             [この部分で二重に処理される危険性がある]

このような場合、ステータスファイルを検討してみるといいだろう。process1が走り始めた段階で、「現在プロセスが走ってます」という状態を表すファイルをどこかに作っておき、そのファイルがある限り、process2が走らないようにしておくといったものだ。下のような実装にすれば、同じプロセスが二重に走る心配がなくなる。

<?php

if ( file_exists('/path/to/process.lock') )
{
	echo "このプロセスはロックされています。".PHP_EOL;
	die(1);
}

echo "プロセスを開始します".PHP_EOL;

touch('/path/to/process.lock');

// 時間のかかる処理

unlink('/path/to/process.lock');

echo "プロセスを終了します".PHP_EOL;
die(0);

11. 今PHPのプロセスが走っているかは ps ax | grep php で調べよう

開発中はデバッグ中に、現在PHPのバッチ処理が動いているか知りたい時がある。Linuxであれば、そうしたときは次のコマンドを実行して調べてみよう。コマンドにphpが含まれているプロセスが表示され、一目瞭然だ。

ps ax | grep php

この応用として、私がよく使う確認コマンドは次のようなものだ。どういうものかというと、1秒ごとに上のコマンドを実行して、実行状況の進捗を確認するものだ。

while true; do ps ax | grep php; sleep 1; done;

まとめ

以上が、コマンドラインPHPを利用する上でのTipsでした。もっとこうしたほうがいいとか、こんな便利なTipsもあるよ、という意見・ご感想などもお待ちしてます^-^ 本気で、バッチ処理などを書くときはPHPを使わないなんて意見もありそうですが、それは自粛し...(ry

プロジェクトを複数人で共有している場合、デバッグコードを書いたとしても、メンバーと共有する場合は消しておくことが必要だ。仕事でのプロジェクトであれば、デバッグコードによる余計な出力やプロセスの終了は不具合として扱われることになる。

自分も仕事でデバッグコードを書いて、それをそのままSubversionのリポジトリに上げてしまっていたので、svn commitする手前でvar_dump, console.logが含まれてないかチェックするスクリプトを作ってみた。

できたもの: svn-commit

• 開発環境がMacOSXなので、Macで動く。
• ターミナルから使うので、コマンドラインインターフェイス。
• どうせなのでPHPで書いてみた。
• svn commitコマンドの感覚で使える。
• ついでに、コミットコメントもいれやすい感じにしてみる。svn ci -m ""とかエディタの設定とかめんどくさいって人なので。

使い方

• svn-commitをダウンロード
• PATHの通っているところにsvn-commitをおく。
• svn-commitに実行権限を与えておく。
• あとは、svn ciをするかわりにsvn-commitを実行するだけ。

PHPをコマンドラインインターフェイスで動かす方法です。

# 4時半に実行
30 4 * * * php /private/path/to/batch.php

メリット

• サーバ外部から実行されないので、セキュリティ的に安心。
• タイムアウトの心配がない。
• phpコマンドだけあればいい。
• 余計なトラフィックがない。

デメリット

• $_SERVER['SERVER_NAME']などのApache由来の環境変数が取れない。
• ウェブインターフェース用に作ったプログラムがそのまま再利用できない場合がある。
• 処理をトリガするサーバと、処理を行うサーバが同じである必要がある。(* SSHなどでリモートコントロールする場合をのぞく)

2. ウェブ経由で動かす

PHPをウェブ経由で動かす方法です。

# 4時半に実行
30 4 * * * wget --spider http://localhost/batch.php

メリット

• $_SERVER['SERVER_NAME']などのApache由来の環境変数が取れる。
• ウェブインターフェース用に作ったプログラムがそのまま再利用できる。
• 処理をトリガするサーバと、処理を行うサーバが別でもいい。

デメリット

• サーバ外部から実行されうるので、セキュリティ的に心配。あるいは認証処理を実装する必要がある。
• タイムアウトの心配がある。
• wgetコマンドが必要。(別にwgetじゃなくてもいいんだけど。)
• 余計なトラフィックがある。

ケースによって柔軟に使い分けよう

長い処理、セキュリティが担保される必要のある処理は、コマンドラインで。

誰が実行してもよくて、ウェブインターフェース用のプログラムを再利用したい場合は、ウェブ経由で。

まあ、でも、全部、CLIでやってもいいんだけどね。

5. 変数名に意味を持たせよ

変数に意味を持たせることは、いつもあなたのためになる。
データの型まで分かると、更に良い。
例えば、integer型の変数には、変数名のプレフィックスとしてiをつける。
変数に型宣言しないPHPにおいて、これは特に重要だ。

変数名の頭文字を大文字にするかどうかは、あなた次第だ。
しかし、読み易さから言っても、単語の先頭は大文字にすることをお勧めする。

こんな感じだ。

 
<?php
$iNumber = 10; // For Integers
 
$sName = "Marc"; // For Strings
 
$fPi = 3.14159265; // For Floats
 
$aNames = array(); // For Arrays
 
$oUser = new User(); // For Objects
 
$bIsMember = false; // For Booleans

これは自分は真反対。というより、変数名に意味を持たせることは非常に同意するけど、ハンガリアン記法について反対ということ。「PHPは型がゆるい言語だからハンガリアン記法で型を宣言しよう」っていう主張は前からあるけど、型がゆるい言語だからこそハンガリアン記法は避けるべきだと思う。これが1つ目の理由です。

$sTags = 'php,perl,ruby,python';
$sTags = explode(',', $sTags);

例えば、カンマで区切られた文字列をexplodeで配列に分解したら、あっというまに型が変わってしまう。ここでもうハンガリアン記法は意味のないものになってしまう。それなら、配列用に別の変数名をつければいいじゃないかという反論があるかもしれない。しかし、それは一方で無駄な一時変数を増やすことでもある。

もうひとつの理由は、ハンガリアン記法は必ずしもプログラマ同士で共通化されていないという点。ハンガリアン記法自体、いくつかの流儀があって流儀が異なる者同士が同じコードを触った際に混乱につながる。混乱させるような記法なら最初から避けるべきだと思う。

私が思うに、「変数名に意味を持たせよ」で重要なことは、つきつめれば次の1点だと思う。

• 変数名を略しすぎず、できるだけ発音できるものにする。

具体的に言えば、$categoryを$ctgと略したりしないということです。

10. 三項演算子を使え

もし、シンプルなif文を書きたいなら、三項演算子を使って、ワンラインで通常のif文を書くのと同じことが書ける。

 
<?php
if ($a == 1) $b = 2;
else $b = 3;

上記のコードは、以下の三項演算子を使ったのと同じことだ。

 
<?php
$b = ($a == 1) ? 2 : 3;

「三項演算子を使え」は言い過ぎだと思う。せいぜい、「読みやすいコードになる場合に限ってのみ三項演算子を使ったほうがいい」だと考える。現に三項演算子は重ねて書かれると読みにくいし、ブレースがないぶん制御構造としての認識が低くなる。さらに言えば、単体テストのときにテストケースへの意識も低くなりかねないという危険性がある。上の例のようなコードでは、三項演算子が歓迎されると思う。しかし、三項演算子の乱用は控えるべきだとも思う。

12. ++と–の演算子を使え

整数を減少あるいは増加させる場合、インクリメントあるいはデクリメントの演算子が使える。
もし、あなたがこんなコードを書いているなら、

 
<?php
$iNumber = $iNumber  + 1;
$iNumber2 = $iNumber2 - 1;

こう変換すべきだ。

 
<?php
$iNumber++;
$iNumber2--;

もっとより良いPHPerならこうすると思う。++より、+= 1を使う。

$iNumber  += 1;
$iNumber2 -= 1;

なぜなら、万が一 $iNumber に 'a' が代入されていたら、どうなるだろうか？その際の動作は、期待したものだろうか？

$iNumber = 'a';
$iNumber ++;
var_dump($iNumber); // string(1) "b"

もちろん$iNumberは、整数型にキャストする、ないしはバリデーションしておくべきだ。それでも、ちょっと工夫するだけで防衛プログラミングができるならそれに越したことはないと思う。