Stefan Koopmanschap has shared a rant about best practices in a new post to his site. In it he shares some of his thoughts as presented in a lightning talk at the PHPAmersfoort meetup.

I have yet to talk to a developer that has told me that they were purposefully writing bad software. I think this is something that is part of being a developer, that you write software that is as good as you can possibly make it within the constraints that you have.

In our effort to write the Best Software Ever (TM) we read up on all the programming best practices: design patterns, refactoring and rewriting code, new concepts such as Domain-Driven Design and CQRS, all the latest frameworks and of course we test our code until we have a decent code coverage and we sit together with our teammates to do pair programming. And that's great. It is. But it isn't.

In the post he touches on a few main topics with his ideas for each:

• Test Coverage
• Domain-driven design
• Frameworks
• Event sourcing + CQRS
• Pair programming
• Refactoring + Rewriting

He ends the post with a suggestion to "consider all the best practices" when writing your code and developing applications. It's not just about applying them because they're defined as "best practices", it's about determining which of these practices make sense for your situation.

php[architect] magazine has published their latest issue - November 2013 focused around frameworks. This month's issue has stories (and regular columns) about:

• Functional testing in Symfony2
• the Laravel framework
• Descriptive naming schemes
• Using Satis for internal Packagist.org-style hosting

You can find out about the rest on this page of the php[architect] site and pick up either a single copy or subscribe to a full year's worth (now with a print option).

On the Web Species blog there's a new post from Juozas Kaziukenas about the new era of PHP frameworks that are coming out (or might be already here). This new group of frameworks is redefining the PHP framework world:

I have worked on a lot of different systems and projects in my years and most of that was spent doing PHP. However just recently I have noticed a new major point in time - a new era of PHP frameworks. Seems like everything is changing these days. I want to discuss what I think the current state is, what’s wrong with it and how the new gang of frameworks is going to change it.

Juozas starts with a brief history of the "why" and "how" PHP frameworks came to be and how they've improved over time. In this new generation things like dependency injection containers and annotations are changes for the better. Three frameworks mentioned specifically as driving forces in this new movement are Zend Framework 2.0, Lithium and Symfony2.

InfoWorld has put together a review of some of the top PHP frameworks out there and have shared their results in terms of capability, ease of development, documentation and ease of installation (and overall score, of course).

You can arm yourself with one of the PHP-based Web development frameworks covered in this article. In the following pages, I'll look closely at the Zend Framework, CodeIgniter, CakePHP, and Symfony. I'll also give quick overviews of Qcodo, Lithium, Seagull, and Yii. All are open source frameworks, and all implement to one degree or another the MVC (model view controller) architecture pattern. In addition, all purport to help you build a more scalable and more easily maintainable Web application than you could otherwise create from scratch and, most importantly, do so in less time.

The introduce each of the frameworks at a pretty high level and start with their "Test Center Scorecard" showing their overall ratings of each of the four they tested. They link to a few other articles that talk more about the features of each in-depth and give an "at a glance look" as well. The list shows the minimum PHP version required, licensing, level of documentation currently provided and some of the general pros and cons.

On the symfony blog today there's a new post that points out some of the excellent books you can get covering the framework in general and a bit more specific topics inside.

I love books! And I buy a lot of them. When I was young, I dreamt about writing a book. And thanks to symfony, my dream became true two years ago with the publication of the "Definitive Guide to symfony" book, published by APress. This book was co-authored with Francois Zaninotto and it covers symfony 1.0. Last year, I wrote yet another book on symfony, "Practical symfony", to cover the new symfony 1.2 version. This book has been a huge success online, and was self-published on lulu.com.

The books mentioned are:

• Practical symfony 1.2 for Doctrine - second edition
• Practical symfony 1.2 for Propel - second edition
• Symfony : Mieux developper en PHP avec Symfony 1.2 et Doctrine
• Pre-release chapters of the "Symfony 1.2 Reference Guide": settings.yml Configuration File, factories.yml Configuration File and Events.

Kae Verens has posted another book review today covering APress' "Pro PHP: Patterns, Frameworks, Testing and More" (by Kevin McArthur).

This book is absolutely jam-packed with information useful to the medium-advanced PHP coder. SPL is described over a few chapters, and a quick intro to Zend's MVC framework is provided. Of particular interest to me were the final chapters, to do with certificate-based authentication, and a chapter near the beginning describing the upcoming features of PHP6. Great book - I really enjoyed it.

The review gets into detail on some of the chapters and some of the shortfalls that Kae saw about them. Things like:

• The title says "frameworks" but only one is really discussed (Zend Framework)
• The testing/continuous development sections weren't long enough
• The "web 2.0" section was a little sparse
• The only real web service protocol talked about is SOAP.

Overall, though Kae found the book to be worthy of a place on any developer's shelf.

The Zend Developer Zone has posted a sample chapter from a new book Packt Publishing has put out called "Pro PHP, Patterns, Frameworks, Testing and more by Kevin McArthur.

So today you get a double bonus. You get to check out Pro PHP, Patterns, Frameworks, Testing and more by Kevin McArthur. You also get a great tutorial on SPL!

The sample chapter looks (obviously) at the SPL, the Standard PHP Library - functions included with PHP5 releases to accomplish some pretty cool things.

Vidyut Luther has posted a new item on his blog today that presents a situation he's been given concerning namespaces.

I've run into an issue, or rather a friend of mine has. He asked me for advice, I gave it to him, but I'm curious how others would do this. The problem is this:

Team A, has been working on some code for a few months, Team A has a class called "SomeClass". Team B, is an "outsourced" team, who is writing a SOAP interface to Team A's code. Somehow, due to whatever reasons, Team A and Team B developers didn't talk.

Team B also created a class and called it "SomeClass". These classes are in files called "Aclass.class.php" and "Bclass.class.php" . There are some files, that include both files.. obviously, you end up with a "cannot redeclare class" fatal error.

Vidyut's suggestion was to just to change the class names. Unfortunately, this might not work if there is no communication between the two parties - they cannot come to a compromise on the naming.

He question to the community is "How do you handle an issue of single namespace, or rather no namespace ?"

Vidyut Luther has posted a new item on his blog today that presents a situation he's been given concerning namespaces.

I've run into an issue, or rather a friend of mine has. He asked me for advice, I gave it to him, but I'm curious how others would do this. The problem is this:

Team A, has been working on some code for a few months, Team A has a class called "SomeClass". Team B, is an "outsourced" team, who is writing a SOAP interface to Team A's code. Somehow, due to whatever reasons, Team A and Team B developers didn't talk.

Team B also created a class and called it "SomeClass". These classes are in files called "Aclass.class.php" and "Bclass.class.php" . There are some files, that include both files.. obviously, you end up with a "cannot redeclare class" fatal error.

Vidyut's suggestion was to just to change the class names. Unfortunately, this might not work if there is no communication between the two parties - they cannot come to a compromise on the naming.

He question to the community is "How do you handle an issue of single namespace, or rather no namespace ?"

In his blog, Ian Kallen has posted some opinions on the current state of PHP application development and some ways that he'd define best practices to help it.

I've annoyed PHP enthusiasts, friends and colleagues alike, with my distaste for PHP. There's nothing intrinsically bad, buggy or poorly performing about PHP per se. It's real simple: a lot of PHP code that I've had to pick up the hood on is a mess and is susceptible to worlds of instability and bugs.

I'm confident that I or someone else could eventually derive a tool set that meets a rigorous standard for maintainable code. What concerns me are the prevalent practices and establishing best practices. I want to work with the someone else to establish them.

Among his suggestions are included things like "use clear APIs in classes" and "use frameworks to encourage separation of concerns". He also suggests a more wide use of unit testing in PHP to help rid your apps of common issues...