On Reddit.com today nikic asks you why you don't contribute to PHP, that is to the language itself or the community around its improvement.

I know many of you care about PHP and have suggestions about how to improve it. My questions is: What prevents you from writing a mail to the internals mailing list with your suggestion/proposal (or to participate in existing discussions)? [...] I'd be interested in your opinions and hope that things can be improved based on them.

Some of his own examples to kick off the discussion include time constraints, not being able to write the patch themselves and some of the issues with the culture of the internals mailing list. Other suggestions from the comments include lack of confidence in coding skills (C++), the possible lack of interest in the RFC and the current state of the language's codebase.

Kevin Schroeder, in his move towards doing some mobile development, has a new post to his blog about why he's still going to stick with PHP for the backend of this new development work.

I do like working with client/server-like architectures and so I intend to be building apps that have a fair amount of server-side processing to back it up. More details on that to come in the next few months. [...] I have decided that, for the time being, to use PhoneGap for my frontend development. [...] So the question was what to use for the backend development and, to nobody’s surprise I presume, PHP is my chosen way to go.

Some of his reasons for the choice include:

• PHP is stupid easy to scale
• It is tied to the web
• (Available) Frameworks
• Tons of blogs
• It integrates with everything

Check out the post for more of his reasons.

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 Blancer.com they've posted what they call ten compelling reasons to use the Zend Framework for your next application (or even to rework a current one).

Trying to decide which framework to use for your new project? In this article, we’ll go in-depth about why Zend Framework should absolutely be your PHP framework of choice.

Their reasons cover a wide range of the framework's functionality including:

• Extend classes like there's no tomorrow
• Use what you need, forget everything else
• No model implementation choose your own adventure
• Guidelines and standards
• Community and documentation

On NETTUTS.com today there's a new article that shares ten different reasons you should use the Zend Framework in your development.

Whether you’re starting a new project or improving an existing one, in this article, I’ve provided ten reasons why you should use Zend Framework for your next project, and hopefully, it helps you in making an informed decision.

Among the reasons on their list are things like:

• Extend Classes like There’s no Tomorrow
• Use What you Need, Forget Everything Else
• It lets you do a Lot of Things!
• No Model Implementation – Choose your Own Adventure!
• Guidelines and Standards

In a recent post to her blog Anna Filina lists ten good reasons to write unit tests for your applications:

It's been bothering me for quite some time not being able to explain the people out there why they need to write unit tests. The most common responses that I got were "this is a waste of time" and "my application has no bugs". Unfortunately, this overconfidence and cutting corners is hurting the developers (and the industry).

Among the reasons in her list are things like "by testing often, you don't break the application as you go", "you ensure maintainability" and you can "save time on testing" when it comes to the release of the application - just run your suite and a lot is already covered.

Nessa has a new post to her blog today on why she thinks most people are late to the party on PHP 5.3 including a few reasons she sees for the delayed adoption among the developer masses.

As a programmer, I would hold it to any site owner to check their site’s requirements and the offerings of their host before they unnecessarily waste a lot of time and money, but as a system administrator I frown upon shared hosting providers offering software with known compatibility issues just to be able to advertise as the “latest and greatest”. The latest isn’t always the greatest, and it won’t be until the community catches up with what the greatest has to offer.

She notes that her situation, much like many other hosting companies, is that they're "just not ready" to make the upgrade because of some of the hassle it might cause the users. Similar situations happened with the change from PHP4 to PHP5. She also mentions a few specific issues:

• Compatibility issues - several very popular applications don't support some of the 5.3 changes
• There no Zend Optimizer/Zend Guard support
• It's not required for PCI compliance yet

Richard Thomas is back with another post in his "Solor Framework Shorts" series. This latest post includes ten of the reasons why you should make Solar the frmaework of choice for your next project.

Here is a community built list with the top 10 most popular reasons to use Solar Framework, maybe if your not currently using Solar Framework one or two of these items will perk your interest up and get you to take a look.

Mentioned in the list are things like:

• Structure that just makes sense
• Built in easy to use Locale system
• Solar Views based on Savant the best Template system in the Cosmos
• The community, active and tight knit

Check out the full post for the rest of the list.

The Builder.com.au site has a new article posted today about Open Source developers and why your company could benefit from adding them to your workforce.

Some companies are afraid that hiring an open source developer would be a liability - possibly reverse engineering their proprietary software and then releasing forked versions into the community. Although these may sound like justifiable fears, they overlook some very important benefits that come with hiring open source developers. Let's take a look at some good reasons to hire open source developers.

They list the five reasons (from a business perspective) companies shouldn't be afraid of adding Open Source developers to their teams:

• You can see more than their resumes.
• Open source developers have had to think on their toes and patch the programs that Microsoft has (often times) intentionally broken.
• Open source developers are [generally] very passionate about what they do.
• Along with an open source developer you will enjoy open source support.
• And like adopting any open source project, you will save money.

Paul Reinheimer has posted five reasons he thinks that companies should make the switch from LAMP over to WIMP (Windows, IIS, MySQL, PHP).

I'm always looking for better ways to get my job done, save my employer money, and expand my skill set. So whenever I get a chance I'm looking at the competition of the tools we're currently using to see if there's tricks to learn, or reasons to switch. I've been keeping an eye on IIS on various Windows servers for a while, more recently I've been looking at SyBase and SQL Anywhere, as well as CouchDB for data storage (but more on those two later).

He sees these five reasons as possible motivation for your development group (especially if you're already using Windows) to make the switch to this new development structure:

• Use the expertise you already have in-house
• Avoid duplication of Servers
• Avoid duplication of Staff
• Integrate tightly with current technologies
• There's features out there not available on LAMP

A few of these apply no matter what your situation is, especially things like using the knowledge you already have and avoiding duplication wherever possible.