These problems are related to the inability to share behavioral code through aggregation and the complexity of state transformations. Combining both, your average entity with 5-15 fields can end up with hundrets or thousands lines of code. The solutions to both problems boil down to minimizing duplication and maximizing clarity.

He looks at two different kinds of objects Doctrine uses in its setup, the value objects and method objects, and "maximize clarity" on them by dividing them up into more functional-related objects, passed into each other via method injection.

OK. We can handle PDOs connections inside a Symfony2 application, but what happens if we prefer DBAL. As we know DBAL is built over PDO and adds a set of "extra" features to our database connection. It's something like PDO with steroids.

He includes the (PHP) configuration to set up the DBAL and the YAML definition to set it up in the DIC's configuration. As an update to the post, he also points out a bundle for Symfony2 that lets Doctrine do this natively - check out this documentation on github.

As part of our ongoing efforts to make Couchbase more integrated with frameworks and libraries, we added caching support for the Doctrine ORM. [...] Caching can either be used standalone (through the API provided by doctrine/common) or integrated with the ORM functionality. We'll look at both variants through simple examples, a good documentation can also be found here. Note that at the time of writing, the CouchbaseCache is not mentioned as a caching driver because the documentation still needs to be updated.

He walks you through the steps to get everything you need installed, both through Composer and the Couchbase extension so your PHP installation will support it. He includes sample code that sets up the cache and shows how to check it to see if a key exists. With this base in place, he expands it out to working with the Doctrine ORM. He shows how to create a sample "Person" entity, inject it into the entity manager and perform a query with the Result Cache to locate the object.

Sending emails programmatically is a common task that programmers must deal with often. Although you can use PHP's native functions, they can be too low-level, especially when you want to attach one or more files to your message. If you don't want to use the native functions, or if you want to send mail using an object-oriented approach, then this is the article for you. I'll introduce you to Swift Mailer, a powerful component-based library that let's you send emails easily. Started in 2005, Swift Mailer is a library that provides several classes that allow you to send emails from within your PHP scripts or web applications.

Included in the post are a basic example of sending a plain-text email, working with attachments and including a template into the body of the message (with spots to fill text in).

Both the Symfony 2 and Doctrine 2 libraries and components make liberal use of what have come to be called annotations - special code comments, usually prefixed with an @ that are actually interpreted by the application and affect its functionality. [...] This trend needs to die.

He points out that the use of code comments like this isn't a good practice and applications should never have to rely on them for functionality. He mentions issues with syntax/language functionality (can't use "php -l" on them, can't var_dump an annotation) and that it makes it more difficult to read and interpret the code. He includes an example from Ruby of an alternative and a possible solution in PHP involving a static "mapping" variable.

With OS X 10.8, Apple continues to ship PHP 5.3 with Xdebug, PEAR, GD and PDO_MYSQL. This is how to set it up from a clean install of 10.8.

He's broken it up into a few sections including the MySQL setup, Apache configuration , updating the main php.ini and setting up PHPUnit ("and friends") for your testing. He also includes setup instructions for the mcrypt and the PECL OAuth extensions.

Last week, I blogged about looking for a new application framework to use and more importantly the key things that I would want in one. After reading about the Zend framework, Symfony and Laravel and finding myself hesitant to use any one, I thought to myself why not get the best of each framework? So that's what I did.

He shows a bit of the code to get them to all play nicely together using the Zend autoloader to register the other namespaces and creating a Symfony DI container inside of the ZF Bootstrap and providing it as a resource. You can find more of the source involved in the integration on his github account.

Testing is important - most people understand that by now. A lot of people write tests for their open source code already, but in-house testing is still hard. [...] While I prefer to run my database tests against a SQLite in memory database, there are these edge cases, where I work with multiple database or I write a direct query (and by-pass the ORM-magic). In these cases I need to have that database server available in my test environment! The following blog posts explains how to solve these things with Travis-CI. I will walk you through the setup on Travis-CI's business service. But most of this applies to their open source offering as well.

He's broken it up into a few different steps - the setup and configuration of the ".travis.yml" file, adding in a "composer.json" file with the needed dependencies and the recommendation of a "phpunit.xml" in your project's root. He shows how to use Doctrine's "SchemaTool" utility to generate his schema off of the comments on his entities (instead of checking in SQL). This setup them gives him access to Doctrine's EntityManager object in his tests and he can go from there. If you're thinking about doing something similar, check Travis' list of supported databases before you do anything, just to be sure.

As with most tools that work really well, I know very little about PEAR. I mean, I use it all the time, and I love it for getting all the extensions installed that I need for the work I do. [...] However I'm now in a situation where I might need to install PEAR packages with a connection that may or may not be working, and I'm not sure exactly which packages I might need, so I wanted to know whether I could use PEAR as my packaging tool even when I wasn't able to reach the usual channels. And guess what? I can!

The install is a pretty simple two-step process - just download the package(s) you'll need for your development and point the PEAR installer (you'll need this installed first, obviously) at the archive file. It's smart enough to take care of the rest.

I'm a big proponent of object oriented programming. OOP done right helps ease code maintenance and enables code re-use. Starting in PHP, OOP enthusiasts got a whole bunch of new tools, and new tools keep coming into the language for us with each minor release. One feature that has had a huge impact on frameworks and libraries has been available since the earliest PHP 5 versions: visibility.

He covers a bit of the syntax and features of public, private and protected and mentions a keyword not often seen in PHP applications - final. The reason all of this came up was work on annotation support in Zend Framework 2 and some difficulty in integrating it with Doctrine support. The "final" status of the class was part of the problem, and after a a lot of copy & pasting he decided on a different tactic - using its public API to try to work around the problem.

In sum: because the class in question was marked final and had private members, I found myself forced to think critically about what I wanted to accomplish, and then thoroughly understand the public API to see how I might accomplish that task without the ability to extend.