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.

Building on this article from the IBM developerWorks site talking about "Five Common Database Problems", Kristian Kohntopp adds in some of his own comments for the five common problems from his perspective.

My experience in the field differs slightly from his observations, and so I thought a few annotations may be in order.

Each of the five in the list have large explainations following them, with slightly different takes on what was said before on the subject and sometimes even a few agreements here and there.

Building on this article from the IBM developerWorks site talking about "Five Common Database Problems", Kristian Kohntopp adds in some of his own comments for the five common problems from his perspective.

My experience in the field differs slightly from his observations, and so I thought a few annotations may be in order.

Each of the five in the list have large explainations following them, with slightly different takes on what was said before on the subject and sometimes even a few agreements here and there.

It seems like there's not a site out there anymore that doesn't use a database of some sort. Frankly, they're just a simple way to get the storage you need without the hassle of having to manage the resource yourself. It even comes with its own language to help query the data! Of course, with the good comes the bad, and this new article from IBM's developerWorks site about five common database mistakes.

If only there were one way to use databases correctly... You can create database design, database access, and the PHP business logic code that sits on top of it in any number of ways, and you often end up getting it wrong. This article illustrates five common problems in database design, in the PHP code that accesses databases, and how to fix these problems when you see them.

The problems they discuss are:

• Using MySQL directly
• Not using auto-increment functionality
• Using multiple databases
• Not using relations
• The n+1 pattern

Each of the items is discussed and explained with code samples for both the good and the bad side to make comparison easier. Knowing these issues before you develop your system definitely makes it easier, but they're still useful as a tool to fix things as well.

It seems like there's not a site out there anymore that doesn't use a database of some sort. Frankly, they're just a simple way to get the storage you need without the hassle of having to manage the resource yourself. It even comes with its own language to help query the data! Of course, with the good comes the bad, and this new article from IBM's developerWorks site about five common database mistakes.

If only there were one way to use databases correctly... You can create database design, database access, and the PHP business logic code that sits on top of it in any number of ways, and you often end up getting it wrong. This article illustrates five common problems in database design, in the PHP code that accesses databases, and how to fix these problems when you see them.

The problems they discuss are:

• Using MySQL directly
• Not using auto-increment functionality
• Using multiple databases
• Not using relations
• The n+1 pattern

Each of the items is discussed and explained with code samples for both the good and the bad side to make comparison easier. Knowing these issues before you develop your system definitely makes it easier, but they're still useful as a tool to fix things as well.

New to the A/R/T article repository from php|architect today is this look at the "Top Five PHP Mistakes" from Marco Tabini.

These topics have been beaten to death, and will likely continue to be beaten well after their bones have turned to dust. However, I have never had the opportunity to explore some aspects of PHP that obviously are mistakes-not just to understand their origin, but to analyze their impact on PHP and the way they have been dealt with.

His list of mistakes is:

• Objects in PHP 4
• Function Naming Consistency
• Safe Mode and Magic Quotes
• Register Globals
• Lack of Unicode Support

Under each he explains them, noting why they are important enough to mention is the list. He does, however, end on a bit lighter note - the PHP, for all its problems and woes, is just like any other laugnage out there. It has its problems, but its learned from them and, as Marco puts it "has grown because of them".

New to the A/R/T article repository from php|architect today is this look at the "Top Five PHP Mistakes" from Marco Tabini.

These topics have been beaten to death, and will likely continue to be beaten well after their bones have turned to dust. However, I have never had the opportunity to explore some aspects of PHP that obviously are mistakes-not just to understand their origin, but to analyze their impact on PHP and the way they have been dealt with.

His list of mistakes is:

• Objects in PHP 4
• Function Naming Consistency
• Safe Mode and Magic Quotes
• Register Globals
• Lack of Unicode Support

Under each he explains them, noting why they are important enough to mention is the list. He does, however, end on a bit lighter note - the PHP, for all its problems and woes, is just like any other laugnage out there. It has its problems, but its learned from them and, as Marco puts it "has grown because of them".

The IBM developerWorks site brings us yet another fine PHP-related article with this new tutorial today, a look at five common design patterns (and how to use them).

It's difficult to demonstrate the value of patterns using small examples. They often look like overkill because they really come into play in large code bases.

This article can't show huge applications, so you need to think about ways to apply the principles of the example -- and not necessarily this exact code -- in your larger applications. That's not to say that you shouldn't use patterns in small applications. Most good applications start small and become big, so there is no reason not to start with solid coding practices like these.

The five patterns they cover are:

• the Factory pattern
• the Singleton pattern
• the Observer pattern
• the Chain-of-Command pattern
• the Strategy pattern

For each, they explain (basically) how it works and include some sample code to show it in action. There's also diagrams showing how the different parts of the pattern relate to each other.

The IBM developerWorks site brings us yet another fine PHP-related article with this new tutorial today, a look at five common design patterns (and how to use them).

It's difficult to demonstrate the value of patterns using small examples. They often look like overkill because they really come into play in large code bases.

This article can't show huge applications, so you need to think about ways to apply the principles of the example -- and not necessarily this exact code -- in your larger applications. That's not to say that you shouldn't use patterns in small applications. Most good applications start small and become big, so there is no reason not to start with solid coding practices like these.

The five patterns they cover are:

• the Factory pattern
• the Singleton pattern
• the Observer pattern
• the Chain-of-Command pattern
• the Strategy pattern

For each, they explain (basically) how it works and include some sample code to show it in action. There's also diagrams showing how the different parts of the pattern relate to each other.

Chris Shiflett has posted some new information about this year's O'Reilly Open Source Conference - this year's Lightning Talks.

If you're attending OSCON this year, be sure to check out the PHP Lightning Talks being hosted by George and Laura.

In the meantime, you can learn all about lightning talks, read some tips on giving lightning talks, or submit a PHP lightning talk proposal of your own to lightningtalks-oscon2006@omniti.com. Proposals are being accepted until 21 Jul 2006.

The talks are collections of 5-minute talks given by the presenters (PHP community) with topics ranging from new ideas to Q&A sessions, even rants. If you'd like to enter your suggestions for a lightning talk of your own, be sure to get them in before July 21st, 2006!