With a reminder about the best practice of always validating your data, Seth May has this new post about the "Five Ws" of validation - why, when, where and who.

As web developers, the applications you write are complex data processing engines. They try and convince your users to enter good, meaningful data and to respond in solid, predictable ways based on what was entered. Robust data validation will allow the rest of you application to work effectively. [...] Data is scrutinized in various ways to make sure that it adheres to basic restrictions and to fundamental properties. It's no good receiving a sandwich when you expect a car.

The questions he answers are:

• Why is Data Validation Important?
• Where Should I be Validating Data?
• When Should My Data Be Validated?
• Who is Responsible for Validation?
• How Do I Validate My Data? (yes, there's a "w" in there!)

In the real world data is ugly, crazy, and untrustworthy. Your only hope to taming the data beast is to diligently, methodically validate your data.

On the BinaryTides blog there's a series of posts that share some tips and suggestions aimed at helping you and your code be the best they can be - things to enhance your application (including suggestions not just about code but also about environment and development practices).

The three posts in the series include tips like:

• Maintain debugging environment in your application
• Collect all output at one place , and output at one shot to the browser
• Set the correct character encoding for a mysql connection
• Do not gzip output in your application , make apache do that
• Don't check submit button value to check form submission
• Process arrays quickly with array_map
• Avoid direct SQL query , abstract it
• Never set error_reporting to 0
• Make a portable function for executing shell commands

Obviously, not all of these will apply in all situations, but they're an interesting list. Most will come with good explanations and code samples when appropriate.

Lars Tesmer and his coworkers have been working on improving their development skills lately, specifically related to unit testing. In his latest post he shares some of what they've discovered along the way.

The plan was to try and write as many tests as we could for the Constraint classes PHPUnit uses to implement its assertions. [...] Well, our plan didn't work out that way, we didn't really succeed in writing a considerable amount of unit tests. However, it still was a valuable experience, as it turned out the unit tests of the Constraints are a good example of how not to unit test.

He includes three of the major points they came across in their practice development:

• Don't use one single test case class to test several different classes
• Name your tests well
• Avoid to test more than one behaviour in one single test

For each, there's a summary answering the "why" question behind them including an example test (testConstraintIsType) that shows a bad, multiple assertion practice that should be avoided if possible.

In this new post from Reddit.com a question is asked about website translations and the opinions on best practices for it.

I'm just curious what the best practices are for translating your website into another language, to present foreign readers with text in their home lingua -- well, particularly if there are PHP-specific methods to do so. I've stumbled across the pages for GNU gettext and that seems interesting, but I'm curious what people think of it.

Suggestions include manual translation via a human, use a text substitution method two swap out content versions based on language, using language files (and some opinions from others on which of these approaches might work best).

Lorna Mitchell has new post today pointing out the release of both the slides and the audio from a presentation she gave at the PHP UK conference (back in February of this year) about some of the best practices in API design and development.

I really enjoyed giving this talk, since I work so much with APIs and enjoy sharing my ideas. The audio is now online so if you missed the talk, feel free to have a listen. You can also see the slides (on slideshare) and also read the series of blog posts I wrote on this topic which originally inspired the talk.

Lorna has also posted slides for several other of her web services talks including Working with Web Services, PHP and Web Services and Archtecting Web Service Applications.

On the Symfony-Reloaded site (the site for the upcoming Symfony2 version of the framework) there's a recently updated page talking about bundle best practices to use when creating these standardized, easy-to-install packages.

A bundle is a directory that has a well-defined structure and can host anything from classes to controllers and web resources. Even if bundles are very flexible, you should follow some best practices if you want to distribute them.

There's a few standards they lay out concerning the bundle naming scheme (namespacing), the directory structure that'd need to be used (including a "resources" and "controller" directory) and where classes, third-party library use, documentation, templates, configuration and tests should fit in the structure.

On the test.ical.ly blog there's a recent post that looks at a unit testing best practice for checking your Symfony (1.4) application's functionality.

Actually when I started this blog I was determined to use symfonys own lime unit test implementation because it is integrated and documented within the symfony documentation. But the more I worked with it the more I was put off by it. [...] PHPUnit on the other hand is the de facto standard for PHP. It is object oriented as well as well documented and maintained and it is fully xUnit compliant thus can easily be integrated into your continuous integration workflow.

He talks about the bootstrap for the testing, loading the configuration from a fixture and writing some test cases. He gives an example of a basic one and shows how it can fit into a test suite and includes some recommendations of how to test and what to test.

In a new post to the php|architect blog Giorgio Sironi looks at some of the good development principles that can make your applications better based on some other suggestions from Alberto Gutierrez.

Many of them are really good practices that would help most developers in the long run - after all, the only easy thing about software development is screwing it up. I feel I need to add to several of the observations on his list, both more in more abstract and more specific terms.

He talks about things like decoupling code, testing, metrics, naming conventions (and a shared vocabulary) and the role that automation can play in both your development and deployment.

Ralph Schindler, realizing that he's spent too many years in a NCH syndrome (Not Coded Here) environment has started up a series of posts working from the group up about best practices and good development ideas for turning out better applications.

Well, I've seen my share of PHP centric projects come and go. In addition to those projects, I've kept a watchful eye on projects in other communities such as the Ruby, Perl, Java and .NET communities. From them, we've borrowed concepts, ideas and tools to create better solutions for the PHP community. With that, I'll continue on with explaining several of the most common facets of any PHP project. If this seems basic at first, its actually laying the groundwork for a few more in-depth articles down the line.

In this first post of the series he looks at (and defines) environments, libraries and applications.

Nathan Good has posted five tips PHP developers should use in their work to develop good programming habits to the IBM developerWorks site today.

Just like any language, developers can write code in PHP that ranges in quality from truly awful to very good. Learn good programming habits that can help you bridge the productivity gap. [...] Bad coding habits seem to accompany defects in code and can cause code to be difficult to change without introducing new defects. The following five good habits, when applied to your PHP code, will help you avoid these pitfalls.

Here's the list:

• Use good naming.
• Take smaller bites.
• Document your code.
• Handle error conditions.
• Never, ever, copy and paste.