Dougal Campbell has a new post to his site with his own contribution to the "WordPress 10th Anniversary Blogging Project" - a remembrance of his history with the tool and where/when he first started using it.

The official 10th anniversary of the release of WordPress is May 27, 2013. It has been an amazing 10 years, during which WordPress evolved from a simple blogware to a very full-featured CMS (Content Management System), used to power some of the biggest and most popular web sites on the internet. All over the world, people are planning celebrations. As much as I like a good party, I thought this would also be a good time to celebrate WordPress by actually using WordPress - for blogging.

He talks some about when he got started with WordPress (2003) and what's happened since. He suggests that others follow suit and use the "#wp10" hashtag on Twitter to share their own posts.

Matthew Setter has a new article on his MaltBlue site today that suggests that one of the reasons a project is successful is because of effective testing.

Like many of us, despite being told repeatedly how great testing is, the benefits it will bring, the time it will save and how it will improve the quality of my applications, I too considered testing a second-thought. I saw it as something which was both expensive and time-consuming. If I was genuine with you, I'd say I believed it be be nothing more than a "nice to have", after the application was written. If you also feel (or have felt) this way - know that you're not alone.

He realized, though, that the usual false assumptions about testing were just that and starteed getting into testing, TDD and BDD on recent projects. He talks some about some general thoughts around testing like "testing can't be an after-thought" and the fact that it's no always easy. He includes a way of thinking about testing in your application and the confidence good, solid tests can bring.

PHPMaster.com has posted a bit less of a technical article than usual and shares some of the concepts behind scrum, the project management style that's currently quite popular with development groups.

In an earlier article I wrote, we took a general look at project management and discussed what some of its pitfalls are that should be avoided. As part of that, I mentioned that you should, as much as possible, be using an Agile methodology, particularly Scrum, to manage development. I'd like to follow that up with a look at Scrum and at how we can use it to tame our projects.

He talks about the typical "waterfall" technique of project development - requirements up front and cross your fingers for the rest. He compares this to the agile process and how scrum, in particular, helps keep things from falling apart. He then gets in to "how to scrum" by defining some of the key terms and talking about things like:

• Holding smaller meetings
• Limiting scope and time frame
• Looking for feedback
• Constant reworking remaining time

...all at the same time, multiple times during the life of the project. Agile focuses on quick changes and updates because the project is constantly getting feedback from those asking for the product, giving them (hopefully) exactly what they want.

On PHPMaster.com today there's a new post that takes a different approach to PHP development than some of their articles in the past. It comes at it from the project management side of things, talking more about how to run the project and less about the technology it involves.

Whether we like it or not, unless we are doing a hobby project just for our own amusement, even the most technical among us are really just project managers who can code. And, as a project manager, we can experience the heartbreak of project failure. [...] So what can you do as a technical project manager to minimize your chances of adding "leader of a failed project" to your resume? The answer is: pretty much what non-technical project leaders do.

He touches on a few key points that are important to any technology project, not just PHP ones - managing the expectations of the team and the business, using iterative processes and development and avoiding scope creep. He also drops in a bit about watching out for "weird stuff" that might be new or different to your group and their technology choices.

Simon Holywell has a new post to his site about a project that aims to be a minimalist ORM library and make it easier to built queries on the fly for your applications (and is installable via Composer) - the Idorm + Paris combination.

Idiorm is a PHP ORM that eschews complexity and deliberately remains lightweight with support for PHP5.2+. [...] However, having said this, Idiorm is very powerful and it makes most of the queries PHP applications require pain free. Some of these features include fluent query building, multiple connection support and result sets for easy record manipulation. Paris sits on top of Idiorm to provide a simplified active record implementation based upon the same minimalist philosophy.

He includes examples in the post of both queries with Idiorm - simple things like creating and finding records - and using Paris to make models out of PHP objects. He also talks some about the current state of the project, recent advancements and some of the things they're looking to do with it in the future (including dropping PHP 5.2 support and use late static binding).

On his blog today Hari KT has an Aura Framework-related post about one of its components, the Aura.Http component, and its handling of HTTP requests and responses.

The Aura.Http package provide you the tool to build and send request and response. [...] Probably you may not have bothered too much on building the http response either the framework does it for you, or until you need to send the correct response.

The post shows you how to use the component to send and receive HTTP requests. Code is included showing how to make Response objects and set headers, content, cookies and HTTP response code. He also shows how to output the response and a more complete example of the entire flow. The post finishes up with an example of using Aura.Http to make a request to another site - in this case back to GitHub to get the users on a repository.

On DZone.com Giorgio Sironi has written up a new tutorial showing how to use parallelism with PHPUnit to execute multiple sets of tests at once, hoping for a performance gain.

Of course the cost of coordinating different processes is always going to be present, so we will never reach the theoretical speedup. I'll report later in this article some simulations. The most important constraints come from the design of our test suites. I can only think of two categories of tests as easily parallelizable: unit tests and Selenium tests.

He mentions one specific issue to watch out for - race conditions between the test sets (using the same backend resources). To help solve the issue, he recommends looking into Paratest, a tool that sits on top of PHPUnit and handles the execution of the tests in parallel. He creates some sample tests (they just compute values) and compares the runs of them in single- and multiple-process modes. The difference is a twenty-five percent drop in execution time for the parallel test runs.

Jani Hartikainen has posted the first part of a series of articles sharing his experiences with an experiment he's conducting - trying to parse and evaluate PHP in Haskell.

The other day I uploaded a new experimental project on GitHub - A Haskell PHP parser / evaluator. It doesn't understand 100% of all PHP syntax, but it was an interesting experiment nevertheless. Here's some insights and other thoughts from working on the code.

He gets the "why?" question out of the way early, noting that it was mainly a desire to play with Haskell and figured parsing something he already knew well was a good first project. He also mentions the "Parsec" library that seems well suited for the parsing part of the process. There were some issues that he came across, however including dealing with PHP's weak typing and handling all of the possible incarnations of PHP script structure. He includes an example AST showing his different data structures (PHPValue, PHPExpr and PHPStmt). The next part of the series will be more about the evaluation of this structure.

On the Engine Yard blog there's a new post written up by Elizabeth Smith talking some about the mentoring of PHP developers and how being both a mentor and a mentee is a good thing for you and your development life.

Some believe programming is a science, with well-defined rules that if properly followed always give you the same outcome. Some believe programming is engineering, practical application of some kind of pure science such as math. I personally feel programming is a craft. That word often makes people blink a few times, especially those steeped in logic. Craftsmanship means applying specialized knowledge with skill in a practical manner.

She goes on to apply more of the ideas of "craftsmanship" to development work. She notes that she is where she is today because of the people that took the time to mentor her and guide her towards being a better developer. She talks about the networking options mentoring can provide as well as the official PHP Mentoring project that she helped to found.

At the end of the day, I don't work because I have to, I work because I want to, because I need to improve the technology that people use every day. The tools and techniques used today won't be the ones used 20 years from now, so I don't believe in holy wars over languages, operating systems, or coding standards.

Smashing Magazine has a great new article that's a must read for anyone looking to start up an open source project with some guidelines to follow as you get things set up.

At Velocity 2011, Nicole Sullivan and I introduced CSS Lint, the first code-quality tool for CSS. We had spent the previous two weeks coding like crazy, trying to create an application that was both useful for end users and easy to modify. Neither of us had any experience launching an open-source project like this, and we learned a lot through the process.

The article reads like a checklist of things you'll need to consider as you create your project - things like:

• Determining what your goals are
• Choosing a license
• Code structure and organization
• Documentation

There's also a few other suggestions that may or may not be useful depending on the project like "use a mailing list" or "use version numbers" but they're all good ideas. Even if you're already working with an open source project, this is a good overview and could give you food for thought on things you might have overlooked.