Welcome to another tutorial. Today, I will be giving you a walk through of zftool, which provides basic tooling support in Zend Framework 2. If you're new to Zend Framework, or have been reading the introductory series here, it can come in quite handy. But unlike other frameworks, such as Yii (through yiic) and Symfony (via the Command Line tool), the tooling support in Zend Framework 2 is rather light on. These respective tools provide rather robust support for automatically generating models from database connections, checking logs and a host of other much required functionality.

He shows you how to do a few things with the ZFTool - create a new project, make some modules inside it, build an autoloader classmap and check the installation with some basic diagnostics. Command examples and configuration samples are included in the post to help you along.

In the post titled HttpKernel middlewares I brought up the idea of bringing rack middlewares to Symfony2. In order to solidify this effort I would like to announce a new project: Stack. Stack is a convention for composing HttpKernelInterface middlewares. The name and logo are based on the idea of building a stack of middleware layers, each of which handles a particular piece of logic. [...] The main goal of stack is to give the idea of "HttpKernel middlewares" a name, so that we can more easily talk about it.

There's a stackphp organization on Github that has the start of this set of middleware pieces including tools to help you build other features. The project is focused around the Symfony HttpKernelInterface because it was the simpler, more standardized option for now. He notes that there's no reason that, in the future, when things are more standardized it couldn't broaden out to PHP as a whole.

` For the eigth time we will be at the Free and Open Source Conference (FrOSCon) in St. Augustin, near Bonn. This time we will organize the PHP project room again. We also offer space to discuss related topics, or just hack with other open minded people around you. We would love to welcome you at the PHP project room. FrOSCon is a conference organized by geeks for geeks. One of the awesome things about FrOSCon is, that you will not only meet software developers, but also hardware geeks, telephony geeks, knitting geeks, gaming geeks. Prepare for that.

You can submit your talk ideas for this year's event (which ends on June 13th).

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.

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.

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.

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.

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).

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.

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.