On thePHP.cc site they have a new post that tries to refute a common claim from developers when it comes to testing: testing keeps me from getting things done. The post is a response to an email to the group about testing asking where the real value is in applications versus libraries/tools.

To successfully develop software means to work target-oriented. These targets should be derived from acceptance criteria that are reconciled with the business. Without clear targets – we mean at a task level, not project or annual targets – the developer runs the risk of getting lost in work. Most importantly, he does not know when he is done with a task.

It is prudent to document and verify acceptance criteria through automated tests. One way or another, the targets have to be defined before production code gets written. This is test-driven development, whether you want to call it that or not.

The response goes on to talk about how, with tests written after the code has already been written (legacy code), it's not always clear what the original intent was resulting in lost context. It also compares two of the main types of testing - integration and unit - and the place each has in an overall testing strategy.

in response to the previously posted Node.js vs PHP "Smackdown" article on the SitePoint Web blog, PHP blog editor Bruno Skvorc and an author from the SitePoint Javascript channel, James Hibbard, come back with their own rebuttal to some of the points made in the previous article from a more "PHP perspective."

In SitePoint's recent PHP vs Node.js Smackdown, Craig Buckler pitted these development disciplines against each other over a series of ten challenges, to determine which is the overall winner. As Craig notes in the article, these comparisons are always somewhat controversial. As a fun followup, we asked Bruno Skvorc (SitePoint's PHP editor) and James Hibbard (one of SitePoint's JavaScript editors) to provide a commentary on each of the rounds.

For each of the rounds, they start with a summary of the related findings by Craig in the first article and share comments from both Bruno and James. With his slant towards Javascript James often agrees with what the original article stated but Bruno usually disagrees or adds comments in to clarify the PHP side of the situation (from a more insider's perspective).

DevShed starts off another two parts series today with a look at a common feature of many a community site out there - the creation of a simple forum to allow visitors to interact and discuss the latest.

Most websites have some method of interacting with a visitor. Some have a chat system and others have shoutboxes or other ways to attract the visitor to return. One of the most used methods is a discussion forum. And this is what we are going to create and discuss in this article.

This is part one they create the main index page, listing out the current topics, a "view article" page to show the details of the post, and, of course, a way to respond to the current thread for any and all to use. Keep an eye out for the next article where they create the administrative section for the application.

DevShed starts off another two parts series today with a look at a common feature of many a community site out there - the creation of a simple forum to allow visitors to interact and discuss the latest.

Most websites have some method of interacting with a visitor. Some have a chat system and others have shoutboxes or other ways to attract the visitor to return. One of the most used methods is a discussion forum. And this is what we are going to create and discuss in this article.

This is part one they create the main index page, listing out the current topics, a "view article" page to show the details of the post, and, of course, a way to respond to the current thread for any and all to use. Keep an eye out for the next article where they create the administrative section for the application.