ヱビスブログ - PHP

PHPフツウ

nospam@example.com (kiyosick) — Tue, 08 Jul 2008 01:29:03 -0700

PHPサイキョウ

「rocks」でやった結果。

Results 1 - 10 of about 6,900 for "PHP rocks"

なるほど。
他はどうか。

Results 1 - 10 of about 36,900 for "Ruby rocks"
Results 1 - 10 of about 8,700 for "Python rocks"
Results 1 - 10 of about 1,580 for "Perl rocks"

Ruby 圧倒的過ぎるだろ。

その他。

Results 1 - 10 of about 10,100 for "C++ rocks"
Results 1 - 10 of about 9,540 for "Java rocks"
Results 1 - 10 of about 973 for "C# rocks"
Results 1 - 10 of about 496 for "JavaScript rocks"

C++ と Java が大体同じくらいで Python より多い。意外。

ついでに「rules」でもやってみた。

Results 1 - 10 of about 24,000 for "PHP rules"

すげえ！これは期待出来る！

Results 1 - 10 of about 31,700 for "Ruby rules"
Results 1 - 10 of about 9,690 for "Python rules"
Results 1 - 10 of about 5,570 for "Perl rules"

Ruby 強すぎ。

おまけ。

Results 1 - 2 of 2 for "UnrealScript rocks"
Results 1 - 3 of 3 for "UnrealScript sucks"

PHPMock を触ってみた

nospam@example.com (kiyosick) — Mon, 23 Jun 2008 20:37:00 -0700

『次世代 Mock Object フレームワークの雄』として一部から熱く注目されている（と思いたい） PHPMock ですが、ちょろっとテストコード読んだくらいで触った事が無かったのでトライ。

ちなみに PHPMock のテストコードは PHPSpec で書かれている。個人的には残念な書き味というか、読みやすくない。PHPUnit バンザイ。

ただ PHPUnit の Mock はもうちょっと融通利かせてもらえると有難い。という所で PHPMock はどうか。

Let’s do this.

PHPMock にはまともなドキュメントが一切無い。tgz 玉もないので Google Code からチェックアウトするしかない。specs ディレクトリにテストコードがあるのでこいつを見れば大体の使い方はわかる。test as document を地で行く感じだ。メソッド名は RSpec の mock/stub に似ているというか似せてある。

テストコードはこんな感じ。ダウンロードはこちら。

■ test/ProductServiceTest.php

<?php
define(DEMO_ROOT, dirname(dirname(_FILE_)));
require_once DEMO_ROOT . '/phpmock/src/PHPMock.php';
require_once DEMO_ROOT . "/lib/ProductService.php";
require_once DEMO_ROOT . '/lib/IDBConnection.php';
require_once DEMO_ROOT . '/lib/Publisher.php';

class ProductServiceTest extends PHPUnit_Framework_TestCase
{
    const PRODUCT_ID = 1234;
    
    public function test_プロダクトを全件取得する ()
    {
        $mockDb = PHPMock::mock('DBConnection');
        $mockDb->shouldReceive('execute')
               ->withAnyArgs()
               ->once()
               ->andReturn(
                 array('name' => 'NINJA GAIDEN 2')
               );
        $this->service->setDBConnection($mockDb);
        $this->assertNotNull($this->service->getAll());
    }

    public function test_プロダクトIDからパブリッシャの名前を取得する()
    {
        $mockPublisher = 
            $this->createPublisherMock(self::PRODUCT_ID);
        $this->service->setPublisher($mockPublisher);
        $publisher = $this->service->
                getPublisherByProductId(self::PRODUCT_ID);
        $this->assertEquals('Activision', $publisher['name']);
    }

    public function test_クイックモックでfindAllしてみる()
    {
        $mockPublisher = PHPMock::mock('Publisher', 
                            array('findAll' => array()));
        $mockPublisher->findAll();
        $this->assertTrue($mockPublisher->verify());
    }

    public function test_引数がマッチしなければ例外を投げる()
    {
        $mockPublisher = 
            $this->createPublisherMock(self::PRODUCT_ID);
        try {
            $mockPublisher->findByProductId(9999);
        } catch (Exception $e) {
            return;
        }
        $this->fail("An expected exception has not been raised.");
    }

    public function test_PHPUnitのMockObjectはこんな感じ()
    {
        $mock = $this->getMock('DBConnection', 
                array('execute', 'preparedStatement'));
        $mock->expects($this->once())
             ->method('execute')
             ->will($this->returnValue('aaaa'));
        $this->assertEquals('aaaa', $mock->execute("sql statement"));
    }

    public function createPublisherMock ($productId)
    {
        $mock = PHPMock::mock('Publisher');
        $mock->shouldReceive('findByProductId')
             ->with($productId)
             ->andReturn(
                 array('name' => 'Activision')
             );   
        return $mock;
    }

    public function setUp ()
    {
        $this->service = new ProductService;
    }

    public function tearDown ()
    {
    }
}

で、このコードは実行すると「test_引数がマッチしなければ例外を投げる」でコケる。
PHPMock_Expectation#matchArgs に問題があって

■ phpmock/src/PHPMock/Expectation/Expectation.php

    public function matchArgs(array $args)
    {
        if (empty($args) && empty($this->_expectedArgs) && is_array($this->_expectedArgs)) {
            return true;
        } elseif ($args == $this->_expectedArgs) {
            return true;
        } elseif ($this->_expectedArgs == true) {
            return true;
        } elseif ($this->_expectedArgs == false && empty($args)) {
            return true;
        }  
        return false;
    }

「$this->_expectedArgs == true」これだと $this->_expectedArgs に値が入ってれば true になっちゃうという良く話題になるアレです。正解は「$this->_expectedArgs === true」これですな。

上のコードで使っている DBConnection はインターフェースで Publisher は空っぽのクラス。
インターフェースに定義されているメソッドは PHPMock#_generateDefForMethods がよしなに実装してくれるので安心。PHPUnit の Mock Object だと定義したメソッドをイチイチ配列で全部ツッコまないといけない。

いわゆるスタブは無くて shouldReceive 一本になると思われる。
PHPMock#mock の第二引数に array($methodName => $returnValue) を与える事で簡単にモックが作れるのは好感。

■ まとめ

まだまだ挙動が怪しい点はある
それでも PHPUnit の mock よりは楽できる
テストコード内でザクザクモック作りたいなら MockInterceptor よりオススメ

炎上必至のフレームワーク

nospam@example.com (kiyosick) — Tue, 06 May 2008 17:03:17 -0700

Uploaded with plasq's Skitch!

しょーもないPHPプログラマにありがちな40の兆候

nospam@example.com (kiyosick) — Tue, 05 Feb 2008 20:04:21 -0800

ザラッと訳してみる
元々がちょっと変な所は手を入れてます。なんだか良く判らんのは原文残してます。添削してつかあさい。

40 signs you really are a lousy PHP programmer

phpDoc 等でコードにコメントを入れない
Zend Studio や Eclipse PDT の様な IDE の恩恵に目を向けない
Subversion 等のバージョン管理ツールを使おうとしない
プロジェクトにて、コーディング・命名規約や共通の規約を設けない
一貫性の有る手順を設けない
入力値や SQL クエリのエスケープ、検証をしない
コードを書く前にアプリケーション全体の計画をしない
テスト駆動開発を行わない
error_reporting を on にしないで開発、テストをする
デバッガの恩恵に目を向けない
リファクタリングをしない
MVC の様にレイヤーの切り分けを維持しようとしない
これらの略語の意味を知らない：KISS, DRY, MVC, OOP, REST
関数やクラスがデータを返さずに、直接 print や echo をする
ユニットテストや一般的なテスティングの利点に目を向けた事が無い
データや文字列やオブジェクトではなく、HTML を return する
メッセージや設定パラメータをハードコードする
SQL クエリの最適化をしない
__autoload 関数を使わない
エラーをスマートに扱わない（don't allow intelligent error handling）
$_POST を使わずに何でも $_GET にしてしまう
正規表現をどう使えばいいか知らない
SQL インジェクションやクロスサイトスクリプティングという言葉を聞いた事が無い
設定をシンプルにしない → クラスのコンストラクタでパラメータを受けたり、セッタ・ゲッタを呼び出したり、実行時に定義する事が出来る
オブジェクト指向プログラミングの利点と制限を理解していない
OOP の誤用。どんなに小さな物でも OOP で書いてしまう。
再利用出来るソフトウェアは OOP じゃないと駄目だ、と思っている
理にかなったデフォルト設定をしない（don't choose intelligent defaults）
設定ファイルがひとつじゃない
ファイルの中身が見えるようにせず、拡張子を .php の替わりに .inc にする（don't want the file contents to be seen, but give it a .inc extension instead of .php）
データベース抽象レイヤを使わない
DRY 原則を守らない → コピペや重複を避けた方がいい
関数 / クラス / メソッドの責務を一つに絞らず、相互作用するように作らない
abstract/interface クラスや、ポリモーフィズム、アクセス修飾子等の OOP の利点を得ようとしていない
デザインパターンを使ってアプリケーション設計の最適化をしない
複数のファイルやディレクトリが必要なアプリケーションで、ベースディレクトリの定義をしない
グローバルネームスペースを汚染する → ライブラリに共通の文字列をプレフィックスとして付ける方法がある
DB のテーブルにプレフィックスをつけさせない
別々のテンプレートエンジンを使う
ウェブ開発のコンセプトに長けており、コードのキレイな PHP フレームワークに注目していない

PHP に直接関係無い項目もありますね。
素直に納得出来る項目もあれば、場面ってのも。
場面ってのはそれが有効に作用するケースもあるだろう事を知っていないといかんのですけど。

Hamcrest で PHPUnit の assertion を読みやすくする

nospam@example.com (kiyosick) — Wed, 09 Jan 2008 21:49:00 -0800

セバスチャンがまた面白そうな事やってます。

Hamcrest
Getting Started with Hamcrest

Hamcrest という matcher 拡張ライブラリ。
厳密には拡張ではないのか。「テスト表現を宣言的にしていこうぜライブラリ」のが近い？

Java と .Net 向けにあったものをセバスチャンが PHP にポーティング中。
リポジトリも本家にあります。
http://hamcrest.googlecode.com/svn/trunk/hamcrest-php/

早速チェックアウトして使ってみました。
Let's do this.
"Hamcrest で PHPUnit の assertion を読みやすくする" の続きを読む...

S2Base.PHP5-2.0.0RC2 出てます

nospam@example.com (kiyosick) — Mon, 17 Dec 2007 01:35:52 -0800

でますた。
http://s2base.php5.sandbox.seasar.org/

主な変更点
・goya コマンドを service & dao に変更
・with Symfony の追加
・with Zf に functional test を追加
・Symfony のプラグインとしてインストールする sfS2BasePlugin を新規追加

Zf の functional test はもうちょいどうにかしたいと思いつつも、今のところ大して不便もしてない事実。

mock/stub のセットアップがちょっと面倒なくらいか。
あれはなんとかしたい。

フィードバックお待ちしてます。

Keynote から書き出した PDF にメタデータを追加する

nospam@example.com (kiyosick) — Tue, 27 Nov 2007 16:07:06 -0800

ちょっと気になったので調べてみる。

Keynoteで書き出すPDFにメタ情報つけんのどうやんの？；；

http://twitter.com/yonekawa/statuses/392801632

この手のメタデータ・拡張属性埋め込みツールみたいのがありそうなもんだが、3分探して見つからなかったので代替策を考える。Leopard なら xattr でいけそうな気もするが MacBook が見事に入院中なので試せない。

とりあえず mdls してみる。
"Keynote から書き出した PDF にメタデータを追加する" の続きを読む...

Standard PHP Library (SPL) という選択肢

nospam@example.com (kiyosick) — Sat, 17 Nov 2007 03:43:00 -0800

例えば、SPLを使う。
PHP: Standard PHP Library (SPL) 関数 - Manual

いろいろ調べてみたけど、統一的なやりかた？みたいなのができなくてうまく書けない（；＿；）

PHP を少しだけ触ってみました＞＜ - 女子高生ぷろぐらまーなお☆のブログ

イテレータ系はSPL使うと便利になる。
というかイテレータばかりなので存在が地味なのが惜しい。

function getFilenames($path)
{
    $ret = array();
    $r_ite = new RecursiveIteratorIterator(new RecursiveDirectoryIterator($path));
    foreach ($r_ite as $ite) {
        $ret[] = $ite->getRealPath();
    }
    return $ret;
}

var_dump(getFilenames(dirname(_FILE_)));

再帰処理もよしなにやってくれるのでスッキリする。
RecursiveIteratorIterator というわかりやすさを優先しすぎたクラス名に目をつぶれば。

Zend_DbとSQLファイル

nospam@example.com (kiyosick) — Tue, 30 Oct 2007 20:24:00 -0700

Zend_Dbを拡張してSQLファイルを扱えるようにしてみてはどうか。
S2JDBCっぽくなるんじゃないか。

---

来月出張で中国行くんですが、オープンチケット。
現地でのジョブが終わり次第帰国。

成田からSeasarConfに直行とかにならないように頑張ります。

Tiger→Leopard移行

nospam@example.com (kiyosick) — Sat, 27 Oct 2007 02:31:00 -0700

早速MacBookにLeopardをブッコみました。
過去、上書きインストールすると何かと問題が起きていたので「クリーンインストール&移行アシスタント」を組み合わせます。

1. 外付けHDDをつなぐ
2. インストールDVDを入れて10.5のインストールモードにする（再起動）
3. ディスクユーティリティでMacBookのHDDをイメージ化して外付けHDDにバックアップ
4. クリーンインストール（新規アカウントのユーザー名は旧アカウントと被らないように注意）
5. インストール終了後、HDDに移したイメージをマウント
6. 移行アシスタントの「別のボリュームから」を選択
7. 移行するアカウントを選択して移行開始
8. 終わったら移行したアカウントでログイン
9. インストール時に作ったアカウントを削除
10. XcodeToolsのインストール

すげーラク。
アプリケーションや書類の他に、ホームディレクトリも移行されます。
MacBookには何故かsvkを入れてなかったのですが、多分その辺もちゃんと移行されるはず。
zshrc等はいけてます。

後は各アプリケーションのLeopard対応アップデータを当てていく感じになる。

MacPorts周りも移行されますが、
Leopard自体が割と開発者フレンドリーな作りになってたので構成を変更する予定。

【補足】
/Library/LaunchDaemons 以下は移行されてないのでactivateし直す必要アリ

デフォルトがこんな感じだった。

zsh 4.3.4
subversion 1.4.4
svk 2.0.1
Ruby 1.8.6
rake 0.7.3
rubygems 0.9.4
Rails 1.2.3
mongrel 1.0.1
capistrano 2.0.0
PHP 5.2.4
maven 2.0.6

Ruby方面が力強いなー。
svkがデフォなのはアツい！

---

やっとPHP5になったー、と思ったらpearが入ってねー。
PHPはMacPortsにしとく。

gihyo.jpのPHPUnit3特集がアツすぎる

nospam@example.com (kiyosick) — Tue, 02 Oct 2007 15:23:00 -0700

id:shimookaさんによるPHPUnit3特集！

gihyo.jpにPHPUnitネタで特集を書きました。本日公開です。

Do You PHP はてな - gihyo.jpに特集書きました

PHPUnit3で始めるユニットテスト：第1回　PHPUnit入門｜gihyo.jp

初回はザラっとPHPUnitの紹介と使い方、TDDについて。
次回以降はショッピングカートクラスを（TDDで？）実装していくそうな。

gihyo.jpっていつのまにかWeb連載的な事をやってますね。

PHPUnitの結果出力を色付けする

nospam@example.com (kiyosick) — Tue, 25 Sep 2007 01:36:00 -0700

多分２万人くらいが通ってる道。
autotestモドキを使ってると色ついてた方がいいなー、と。

てかPHPUnit2くらいの頃は色付け出来たような気がするんだけど、記憶違い？
tracあさってたら力一杯wontfixになってて、ソース見てもそれっぽい部分は無いしやっぱり未実装か。

セバスチャンに会ったら説教だな。

色付けにはpearのConsole_Colorを使ってます。便利！
Windowsだと色付けしてくれないと思うけど。

"PHPUnitの結果出力を色付けする" の続きを読む...

stakeout.rbを使ってPHPUnitのautotest

nospam@example.com (kiyosick) — Thu, 13 Sep 2007 23:36:00 -0700

autotestの素晴らしさが最近になってようやくわかって来ました。
ぶっちゃけ最初はうぜえとか思ってたんですけども。「⌘Rするからいらんわい」みたいな感じ。

しかしながらShow as HTMLは意外と実行コストが高く、こまめにフィードバックが欲しい時は結構なストレスになります。そういう時に裏側でスルスル走ってくれてると嬉しい。

特にautotestとRSpecの組み合わせが気持ち良い。dustと組み合わせても良し。

とはいえSpecMateのカッコ良さは異常（QuickTime 4.9MB）なので常にautotestってわけじゃ無いんですけど。場面で。

さて。

BDDフレームワークはともかくautotestの仕組みはPHPUnitで使いたいと思っていた所、ちょっと楽しそうなエントリを発見。
Mike Naberezny – Faster TDD with Stakeout.rb

Pragmatic Automationでstakeout.rbという「ファイルの変更を検知してコマンドを実行」してくれるスクリプトが紹介されております。
Pragmatic Automation – Staking Out File Changes

これを使えばRuby以外でもautotestっぽく出来るよー、っちゅーことみたいです。
早速やってみた。

■実行コマンド

% ruby stakeout.rb “php AllTests.php” */**

適当にファイルを修正して保存するとコンソールでランナーが走る。

すげー簡単。
stakeout.rbのコードが短すぎてお漏らししそう！

一応サンプルのソース → phpunit_autotest.tar.gz
S2ContainerClassLoader使ってるのでS2Container.PHP5必須です。AllTests.phpは現在S2Base.PHP5のtrunkに入っているS2Base_Cli_AbstractCommandHandlerからテスト実行部分だけ抜き出したもの。

コイツをstakeout.rbに埋め込んで「autotest_php」みたいなコマンドにしちゃっても良さげかも。

Dependency Injectionにテスティング以外の利点はあるか

nospam@example.com (kiyosick) — Fri, 24 Aug 2007 22:05:00 -0700

海外の.NET系ブロガー界隈でDIに関するちょっとした議論が巻き起こってておもしろいです。
どんだけやれば気が済むのか。

お題は『Test以外の利点』
"Dependency Injectionにテスティング以外の利点はあるか" の続きを読む...

ZendFrameworkでRails風FunctionalTestを書く

nospam@example.com (kiyosick) — Fri, 17 Aug 2007 01:43:00 -0700

ZendFrameworkには政治的な思惑も含んでか、コード生成系のツールが付属してこない事はご存知かと思います。

それ自体はS2Base.PHP5 with Zfを使うなり自分で作るなりすればいいわけですが、テスティングに関するノウハウが生まれにくい面が問題。Railsの様にフレームワーク側でサポートされれば叩かれて使いやすくなると思います。ZFのproposalにも「テスティングマネージャー作ってー」的なのが上がってるみたいですけど、どうなる事か。

さて、S2Baseの話ですが、S2BaseZFではDao、Model(Zend_Db)、Serviceのテストをサポートしていますが、Controllerに関してはテストコードが生成されません。これはControllerにヘヴィなロジックを持たせない→Seleniumの受け入れテスト（acceptance tests）が機能テスト（functional tests）を賄えるんじゃねえの、という見解です。

とはいえ、毎度selenium-rc立ち上げるのがメンドイとか、（State Verificationはオススメできないとかはおいといて）アサインされてる変数のチェックがしたい時は少々苦労しそう。

というわけでRailsのFunctionalTestを参考にちょろっとやってみた次第。
S2BaseZFを使ってますが、作法自体は依存しまくったりしていないので素のZFでも問題なくいけるかと思います。
"ZendFrameworkでRails風FunctionalTestを書く" の続きを読む...