In this post to his site Brandon Savage talks about "always returning something" from your methods and functions back to the calling script. He also suggests that null is not an option.

A few weeks ago, there was a discussion on Twitter about whether or not a method should always return a value, or whether or not null was a valid value to return. The answer to this question is a resounding no, a null value should never be returned. [...] For example, you check that a file you opened exists, or that a resource performed correctly before using it. But if you receive a null response, how do you test for this The answer is you can’t

He notes that a "null" response is not only difficult to test but can lead to ambiguous handling as you're not sure where the error might be. He also includes a snippet of code showing how a null response could break a fluent interface if an instance of "$this" is not returned.

Stefan Koopmanschap had a problem - the formatting on his dateTime fields (the XSD type) wasn't cooperating and couldn't be validated. He asked the question of the community of how to correct this and was given a short and easy answer from David Zuelke using date.

Recently I had to compose some XML documents that needed to be validated with XSDs. All fine of course, but I had some problem with two date/time fields that according to the XSD were supposed to be xs:dateTime fields. Googling around I found a lot of references to the ISO8601 format, so I decided to format my date using the DATE_ISO8601 constant. That did not work though.

David's suggestion was to use "date('c')" (the full ISO 8601 date) instead of the DATE_ISO8601 constant. The trouble is caused by a missing colon in the second choice's output.

A little while back on his PHP Kitchen blog Demian Turner asked the question, "Is vendor sponsored software certification the way to go?". An easy example? The Zend Certified Engineer tests.

Currently Zend certification is one of the only options available to PHP devs who want to get accredited, however. But judging by general feedback from the community it would appear that, despite the current certification choices, quality discrepancies between PHP devs on the market can still be pretty...impressive.

He points to another post from Darren Hague (on Derren's SAP blog) that has three elements that any good certification needs to really be considered successful:

• Quality - it must be professional and independent
• Portability - it must be independent of the company you work for at the time
• Customer Demand - without demand for certified people in that area, there's no reason to have the certification

Be sure and check out some of the comments to Demian's post form some other opinions.

Knut Urdalen has posted a new blog item about something he calls "washing emails":

In this tutorial I’ll show you how to create a simple PHP script to cleanup a list of email addresses. As a web developer you have probably been asked to wash a list of emails from a manager or marketer some times. Here’s the ultimate solution.

His script does a few things - removes duplicates, validates that the email address exists, uses pipes for communication and is as flexible as possible to work on most PHP distributions. You can download the simple script here.