Robert Basic has written up a new tutorial for the unit testers out there showing how to do some complex argument matching in Mockery, a popular testing tool that offers an alternative to PHPUnit's own mocking functionality.

This past weekend I did some issue maintenance and bug triage on Mockery. One thing I noticed going through all these issues, is that people were surprised when learning about the Mockery::on() argument matcher. I know Mockery’s documentation isn’t the best documentation out there, but this still is a documented feature.

He starts with a simple mock example, mocking out AClass and defining two method criteria (one with a once and another with a never). He points out that things are not always that simple and sometime more complex argument matching is required. The Mockery:on handler allows you to pass in a closure and do more complex evaluation of the values passed in. He includes an example of this, evaluating the result of a set of arguments passed in and ensuring they're all set.

No matter what the state of a language/application/etc is, how much it's supported by the masses, there will always be those out there balancing out the popularity with their own opinions to the contrary. Where some see one of the best things since slides bread, others see things weighted towards the less positive side. For the popular LAMP package, one of those people is Cliff Wells who voices his opinions in this new blog post.

He makes several points about the package, including:

• that both PHP and MySQL are "full of holes" and encourage bad habits
• MySQL limits developers with missing features (PostgreSQL offers better support)
• PHP's low entry level makes te code written in it more succeptible to big issues (including SQL injections)

There's a quick comment at the end noting that PHP and MySQL have done a lot to "bring open source into the mainstream", but that they've done their job and we need to move on.

No matter what the state of a language/application/etc is, how much it's supported by the masses, there will always be those out there balancing out the popularity with their own opinions to the contrary. Where some see one of the best things since slides bread, others see things weighted towards the less positive side. For the popular LAMP package, one of those people is Cliff Wells who voices his opinions in this new blog post.

He makes several points about the package, including:

• that both PHP and MySQL are "full of holes" and encourage bad habits
• MySQL limits developers with missing features (PostgreSQL offers better support)
• PHP's low entry level makes te code written in it more succeptible to big issues (including SQL injections)

There's a quick comment at the end noting that PHP and MySQL have done a lot to "bring open source into the mainstream", but that they've done their job and we need to move on.

On Chris Shiflett's blog, there's a post that looks a an issue that's been brought up on the New York PHP mailing list concerning two variables in the $_SERVER superglobal - SERVER_NAME and HTTP_POST.

The question initially was "arean't these the same thing?" Chris answers:

There were several informative replies within the first few minutes, but there's more to this question than most people realize. In fact, I'm reminded of a blog entry from Zeev last year, where he warns against $_SERVER['SERVER_NAME'].

Zeev suggests that SERVER_NAME is pulled from the Host header from the remote user. Chris reminds us, also, of some disagreements with this view Zeev presented, namely from Rasmus. Chris then gives an example script to illustrate hos things area really handled - the variables use the given values when they're present in the request, but they still do default back to the ServerName when absent (so only in certain circumstances).

On Chris Shiflett's blog, there's a post that looks a an issue that's been brought up on the New York PHP mailing list concerning two variables in the $_SERVER superglobal - SERVER_NAME and HTTP_POST.

The question initially was "arean't these the same thing?" Chris answers:

There were several informative replies within the first few minutes, but there's more to this question than most people realize. In fact, I'm reminded of a blog entry from Zeev last year, where he warns against $_SERVER['SERVER_NAME'].

Zeev suggests that SERVER_NAME is pulled from the Host header from the remote user. Chris reminds us, also, of some disagreements with this view Zeev presented, namely from Rasmus. Chris then gives an example script to illustrate hos things area really handled - the variables use the given values when they're present in the request, but they still do default back to the ServerName when absent (so only in certain circumstances).

Jim Plush, in his latest blog entry, looks at one of the PHP frameworks offered out on the web, PHP on Trax, and why it falls flat.

A rails alternative in PHP? Sounds great, I dont have to spend my weekend learning Ruby. That's what I hoped when I came across PHP on Trax which dubs itself as a Rails alternative for PHP. At first glimpse of the code they do a nice job implementing a dynamic active record setup to quickly generate the most commonly needed funtionality.

Where this framework really falls flat is documentation, samples, and support.

He doesn't give any samples of how the framework is used (code), but he does describe the frustration he felt working on an application without the proper documentation and even quotes David Heinemeir on the same subject.

You want a framework to cut your development time, not have you digging through source code to try and find errors and documentation. PHP Trax has potential, yet falls flat for lack of documenation, support, and/or general community interest.

Jim Plush, in his latest blog entry, looks at one of the PHP frameworks offered out on the web, PHP on Trax, and why it falls flat.

A rails alternative in PHP? Sounds great, I dont have to spend my weekend learning Ruby. That's what I hoped when I came across PHP on Trax which dubs itself as a Rails alternative for PHP. At first glimpse of the code they do a nice job implementing a dynamic active record setup to quickly generate the most commonly needed funtionality.

Where this framework really falls flat is documentation, samples, and support.

He doesn't give any samples of how the framework is used (code), but he does describe the frustration he felt working on an application without the proper documentation and even quotes David Heinemeir on the same subject.

You want a framework to cut your development time, not have you digging through source code to try and find errors and documentation. PHP Trax has potential, yet falls flat for lack of documenation, support, and/or general community interest.

Jim Plush, in his latest blog entry, looks at one of the PHP frameworks offered out on the web, PHP on Trax, and why it falls flat.

A rails alternative in PHP? Sounds great, I dont have to spend my weekend learning Ruby. That's what I hoped when I came across PHP on Trax which dubs itself as a Rails alternative for PHP. At first glimpse of the code they do a nice job implementing a dynamic active record setup to quickly generate the most commonly needed funtionality.

Where this framework really falls flat is documentation, samples, and support.

He doesn't give any samples of how the framework is used (code), but he does describe the frustration he felt working on an application without the proper documentation and even quotes David Heinemeir on the same subject.

You want a framework to cut your development time, not have you digging through source code to try and find errors and documentation. PHP Trax has potential, yet falls flat for lack of documenation, support, and/or general community interest.