In a new post Andrew Podner recommends that, as you're doing your day to day development, you try your hardest to create testable code, no matter how painful it is.

I look at the situation we have gotten into by having this problem [of replacing a large legacy application], and frankly, it is like the tech version of 'Scared Straight'. The paranoia of such a far reaching application within the enterprise that absolutely has to deploy successfully and also be very flexible to meet the needs of the future have driven me to the point of near madness in trying to make sure this thing is bulletproof, enter Test Driven Development.

He includes an example situation he recently was faced with in his code...and opted for the "easy" way out (difficult to test). He talks some about the issues, dependencies and coupled code this has created. He does, however, show a solution to the issue - passing in the dependencies as they're needed, not defining them in the method.

For me, writing custom apps in an enterprise environment is not about rapid deployment and looking like a hero. It is about deploying software with a design life of 7-10 years, because the change management involved in deployment is not something you want be be doing over and over again. Testable code with 100% coverage of unit tests, well developed integration testing, and prolific use of tools like PHPUnit & Selenium are part of the development culture because while speed is important, durability is even more critical to business.

Vance Lucas has created a "validation library that dosen't suck" and posted about it to his site - his Valitron library.

Valitron is a simple, minimal and elegant stand-alone PHP validation library with NO dependencies. Valitron uses simple, straightforward validation methods with a focus on readable and concise syntax.

He created the library because of frustration with other tools that had (sometimes major) dependencies on other packages. All he wanted was something lightweight and easy to use that was flexible about how it handled its validation rules. Valitron lets you apply a validation (like "required") against multiple fields in the provided data and includes checks for things like length, valid IP, active URL, alpha-numeric, date format and regular expression match. You can also add custom validation rules via a callback/closure.

In response to the number of questions (and popularity) of his previous information about the Aura framework and how it compares to Zend Framework 2 (and Symfony2), Paul Jones has posted more about its decoupled nature and how the frameworks compare.

Being able to use Symfony2 components or ZF2 modules is not quite the distinction I am making. The distinction is that all Aura packages (with the exception of the Framework package) are completely independent, and have no cross-package dependencies, whereas at least some of the components from Symfony2 and ZF2 have dependency requirements.

He illustrates the point with a common task across all of the frameworks - input validation and filtering. He starts with a look at how to handle it in Zend Framework 2 (with Zend/InputFilter) with the list of packages also pulled in by the Composer install. He does the same with the Symfony2 "Validator" package and mentions the other packages needed to execute its tests. Finally, he looks at Aura's "Aura.Filter" component and it's lack of dependencies (and that its tests can be executed immediately).

If you've been developing any PHP at all recently, you've probably heard about the Composer package management tool that's caught on like wildfire in the community. If you're not currently using it, you might wonder what it's all about. Well, in this recent post on the Fortrabbit blog, Ulrich Kautz explains the tool and how to get started using it.

Composer describes itself as "a tool for dependency management in PHP". It uses a large repository of packages which is continuously extended and maintained by the community. It is now out there for about a year or so. This article goes out to everybody who is not already using it: we want you to give it a try it and here is why.

He talks about what Composer is (really a "dependency manager" more than a "package manager") and why its a good thing for projects to use. He gives the quick install instructions and an example of setting up a "composer.json" file to pull in the Twig templating and Doctrine ORM libraries. There's also a quick mention of including the Composer autoloader so it can find the resources correctly.

PHPMaster.com has posted the second part of Alejandro Gervasio's series looking at dependency injection, service locators and factories. In this new part of the series, he picks back up with his look at these patterns and how they can reduce your dependencies on things like "new" even more.

While it's fair to admit that factories do have a neat niche in a number of special use cases, I'm not so merciless as to condemn Service Locators and plain Dependency Injection to an unfair exile. In this final part we'll take a closer look at the implementation of these popular patterns so that you can pick up the one that best suits the need at hand.

He talks some about "class collaborators" as used in service locators and using it in his FileStorage example to find and use pre-created objects. He compares this method with a more simple dependency injection approach, noting that not only is it simpler to maintain but also can cause less overhead required for the DIC.

In this latest post to his blog Stefan Koopmanschap shares a quick tip about using the git-svn tool with the dependency installer in a Symfony2-based application.

I work a lot with Symfony2's deps file for installing 3rd party bundles into my project (yeah I know, I should be using Composer, right?). This works really well when working with pure Git. However, when you're not using Git on it's own but instead use git-svn, you may run into some issues when issuing git svn dcommit,

One issue relates to a "Failed to read object" error that could come up during the push. His solution involves a few steps (manual ones) to prepare those bundle directories and make it easier to push the rest of your changes. He also includes a few links to other resources that he found around the same topic.

Alessandro Nadalin has a new post to his blog looking at the Composer project and using it to manage packages and dependencies in PHP applications.

Managing dependencies between pieces of software, in PHP, hasn't always been a relief: we had PEAR and PECL with their workflows and problems while, in other ecosystems, the solution to this problem has been solved in better ways, like NodeJS's NPM.

He takes a first look at the tool, describing how to get it set up, create a sample configuration (describing each section inside it) and an example of the tool's output. He also briefly touches on the Packagist website/repository and links to the instructions on how to create your own.

Matthew Weier O'Phinney has a new post today talking about why namespaces in PHP matter and why he thinks they're a valuable contribution to the language.

You've heard about PHP namespaces by now. Most likely, you've heard about -- and likely participated in -- the bikeshedding surrounding the selection of the namespace separator. Regardless of your thoughts on the namespace separator, or how namespaces may or may not work in other languages, I submit to you several reasons for why I think namespaces in PHP are a positive addition to the language.

He breaks down his reasons into four different categories - the code organization benefits that come with namespace "containers", simplified interface structure, improved readability (no more huge class names) and a simpler method for identifying dependencies

Sebastian Bergmann has announced the release of the latest version of the popular PHP unit testing software - PHPUnit.

Among the features introduced in this new version, the most notable are the support for test dependencies and fixture reuse as well as the possibility to run tests in separate PHP processes for increased test isolation. Please have a look at the ChangeLog for a complete list of changes.

As a teaser, he also mentions the work being done on the code coverage features that will be included in the next release.

In a recent post to his blog Evert Pot warns against some of the issues that mutual dependencies in your applications.

Much like most people, I try work out my class dependencies through a top-down 'waterfall'-ish approach. By attempting this, I think allows me to keep the structure very clear and understandable. [...] I try to apply the same model to instantiated objects and packages (groups of classes). When an object encapsulates another object, I attempt to make sure the sub-object object is not aware of the parent. When I design packages, I attempt to make sure 2 packages don't require 'each other'.

He gives an example of where this could cause problems - a Database logger that has three types of logging included: file, syslog and database. Obviously the last of the three requires the Database class so they must always be used/included together.

As a bonus a database-error could occur while logging, resulting in an endless loop (or segmentation fault if you're using PHP). [...] However, these types of situations are sometimes simply unavoidable (that's why we have include_once). When they are needed, they should be implemented with care and consideration.