Symfony 1.x I would put into a category of frameworks focused on RAD, aka rapid application development. [...] So for those people who were happy focusing on the 80% use case Symfony2 is a step back. Suddenly the same features take longer to implement, take longer to modify later on and on top of that the learning curve is steeper.

He suggests that work be put into "RAD layers" that can sit on top of Symfony2 and provide some of the more familiar features people are used to from things like CakePHP, Yii and CodeIgniter. There's been a few tries to accomplish this with only one getting the closest in his opinion - the KnpBundle.

At the End of 2012 I had my first contact with a C-based PHP frameworks, namely YAF. Coincidently, some day afterwards Bruno from phpmaster.com pointed me towards Phalcon - a more modern interpretation of the same idea. So I was hooked.

In his "good idea" category he notes that it's faster because it's already loaded in on the request (no long list of includes) and the memory footprint is less than a PHP equivalent. The "bad" side of things mentions some pretty major hurdles though, including the small communities vs larger ones on PHP-based frameworks and the issues that could come with debugging/upgrading.

When I saw the introduction of PHP traits in 5.4.0 I was eager to learn all about them and how they worked. [...] PHP traits, in my opinion, are handy and very flexible. I guess that is the "love" part of my relationship with them. [...] However, I feel that traits also meddle with a bit of the inheritance rules that have been proven time and time again. Is it possible to love as well as hate something at the same time?

He talks first about "the love" he feels for using traits in his code. He talks about their usefulness for geting around PHP's single inheritance structure and being able to "bolt on" functionality as needed. Then comes "the hate" of them, noting that in the wrong hands, they could lead to very messy and lazy coding practices (including the deadly diamond of death problem).

In early March 2012, the PHP Group announced the release of PHP 5.4. Developer eagerly anticipated the release because of the many new features 5.4 would bring, the most sought after being traits. [...] Traits have have been generally accepted by the PHP development community, mainly because it's a feature that exists within other programming languages like Java, C++, and Python. [...] Are they a feature which will help raise the level of PHP development, or are they just a fad?

The starts with a few reasons why he thinks traits are bad like their potential for abuse and the difficulties that could be caused by using them instead of something like an interface. On the good side, though, he mentions things like allowing for "multiple inheritance" and their addition showing growth in the language.

The main goal of refactoring is clean code, better code, or whatever you might call it. But what actually constitutes good code? Good code is smelled and tasted. If you've written a lot of code, you understand what I mean; you can easily identify whether code is good or bad with experience. But what if you are new to coding but still want to do things right? We can summarize the aspects of good code with these three guidelines: Readable, Extensible and Efficient

He goes on to explain each of these three guidelines with descriptions of what they are and what they mean to you as a developer. In the next part of the series, he'll take these three ideas and apply them to code, showing some of the most common points where they can be applied to clean things up.

Our fourth episode is all ready for your listening pleasure. In this exciting episode we focus on "The Conference Experience" and discuss why programming conferences are so important to developers. Chris talks about why CodeMash was so awesome and the awesome talks full of awesomeness that he attended. Ed talks about his own experiences with speaking and attending conferences, complete with a total derail by Chris on why a certain conference rubbed him the wrong way. Oh yeah, you also find out our opinions on what constitutes a "well-written PHP application". I'm sure you will be surprised by our answers.

You can either listen to this latest episode either via the in-page player or you can download the mp3 directly.

I've been recently asked to check out some CMSes for someone, and try to find a recommendation. What I've been finding hasn't really been encouraging. Out of the several CMSes I've tried, they've all failed for various reasons. I admit that I might be looking at this from a slightly different perspective than most - that of admining it and coding against it, rather than as a user - but it's still rather disappointing.

He briefly looks at a few of the more popular offerings - Silverstripe, Concrete5, CMS Made Simple, Joomla! and the old standby - WordPress.

What's going on? This is what PHP is supposed to be good at. Where are the simple, lightweight CMSes with modern code?

There's plenty of comments so be sure and read them - everything from suggesting that the net should be cast wider to "PHP applications" versus just CMSes out to suggestions for other CMSes to try out (quite a few of those).

I can interview for certain (but by no means all) PHP positions because I know a fair about PHP and I believe that being smart but being an asshole does not make you a good PHPer. But not everyone who interviews knows that. And not only that, it is getting difficult to find good PHP developers. A lot of the good ones are being taken up by top companies, but even they are having trouble finding all the good developers they need.

He suggests coming up with something a bit more concrete than just this vague picture of what a "good PHP developer" is and how, even once that's defined, the quality of all developers should be raised to that level. He asks for some feedback on a few related questions like: is there really a shortage of good PHP developers or what are the significant topic areas that PHP developers should know well? Lease him some feedback on the post.

What is a good architecture and why are there apparently two opposing trenches supporting quality on the one side and speed of development on the other side? After having had enough time to think about this whilst flying to Spain I came to the conclusion that Nils question whether it would be better to start quick and dirty to fail cheap in case the project is a looser or to stick to a clean and solid architecture and spend more time and money. Does quick always have to be dirty, clean always have to be slow, is dirty always quicker?

He suggests that "good architecture" and "quick and dirty" are the two opposite ends of the same spectrum. Instead, he suggests that a pragmatic approach is the best - focusing on what needs to be done rather that how to get there. Also by applying the "don't fix it if it's not broken" mentality to current methods and technologies, you can save a lot of hassle in the long run.

What is Doctrine? Doctrine is a popular ORM for PHP which works with RDBMS via PHP objects. This is built inspired by Hibernate from JAVA. This acts as an abstraction layer between PHP and RDBMS.

In his list of good things about Doctrine are things like its hiding of business logic, automatic CRUD, automatic modification of DQL queries, migrations and unit testing interfaces. On his "bad list" are things like not being able to use foreign keys as an identifier, heavy emphasis on an "id" column, not all data types are in DBAL and the SQL constructs missing in DQL. He also includes a scenario where he definitely not use Doctrine - a specific example from a project he just worked on that pushed the limits of the tool.