In his most recent post Lukas Smith suggests that good design isn't an excuse for wasting time. He's basically saying that Symfony2, because of how it's designed and implemented, isn't a RAD (rapid application development) framework and that it's about time for some layers to be added to help get it there.

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.

Recently Lorna Mitchell asked the wide world of Twitter about some of their recommendations of things not to do when creating an API. In this new post to her site, she gathers together those responses including comments about documentation, consistency and response codes.

Recently I tweeted as a #linktuesday link the 10 Worst API Practices post from ProgrammableWeb. Today, in search of some concrete examples of APIs implementing unhelpful antipatterns, I sent out a tweet for help: "What's the most frustrating inconsistent/misleading bit of API you've seen? Looking for cautionary tales!" [...] In the raft of responses (and thankyou all, this was fabulous, helpful and entertaining in equal parts!), there were some definite patterns that I'd like to share with you, in no particular order.

Comments came in from all over and talked about things like:

• Response codes not matching the content (ex. 200 on an error)
• NullPointerExceptions
• Different endpoints for single vs collections
• Order-sensitive XML in requests
• Poor error handling
• Bad documentation
• Incorrect content type handling

So there you have it, the sins to avoid in your own APIs. If you've encountered any of these, please accept my condolences.

Anthony Ferrara has posted his latest video in his development-related series "Programming with Anthony". In this latest video, he takes a look at responsive design with a "guest host" Sam Richard.

This week we are joined by Responsive Design thought leader Sam Richard. He introduces us to the concept of responsive web design, tells us a little bit about its history and talks about best-practice and the future of the web!

You can catch up on Anthony's previous videos in his playlist over on YouTube including ones covering encryption, prepared statements and boolean logic.

A while back Anthony Ferrara proposed a standardized password hashing feature to be included into the core of PHP. It was voted on and it was decided it would be introduced in the PHP 5.5 releases. Anthony has written up a new post talking some about his process in making this upcoming feature and answering some of the most common questions he's gotten about it.

The other day, PHP 5.5 Alpha 1 was released to the public for the first round of testing the new features that are coming out. One of those new features is the Simplified Password Hashing API that I proposed (and was accepted). I have received a lot of feedback and criticism of the new API in the months since it's been committed. I figured now that Alpha 1 is out and people can play with it, I should respond to some of those items, and give a little bit more insight into why it was built the way it was...

He talks about some of his goals with the use of the functionality (simplicity, something "the 99%" can use) ans answers questions about:

• Why the functions aren't namespaced
• Why it's not just a class that can be included when needed
• The choice of not going with an OOP interface
• Why PBKDF2 and Crypt-SHA-512 aren't supported

...and several other questions, but you'll have to read the full post for the rest of those. You can find out a lot about the API for this functionality from its wiki page and, if you'd like to try it out (in an alpha state), you can download this version of PHP and compile it yourself.

The latest issue of the Web & PHP Magazine has been released - Issue 8 - The Power of Design. Articles in this latest issue include:

• Todd Lombardo on user context
• Stefan Priebsch on data and persistence
• Patrick Allaert about data structures
• June Henriksen on the human side of programming

You can find out more about this issue (and go download your free copy) on the Web & PHP site. There's also seven previous issues, all free for download (PDF format)!

On PHPMaster.com there's a new post continuing their look at the SOLID development methodologies with the "O" in the acronym - the Open/Closed Principle:

I have to admit the first time I peeked at the academic definition of the Open/Closed Principle, its predicate was surprisingly clear to me. Leaving all of the technical jargon out of the picture, of course, its dictate was pretty much the mantra that we've heard so many times before: "Don't hack the core". Well, admittedly there's a pinch of ambiguity since there are at least two common approaches to keeping the "core" neatly preserved while extending its functionality. The first one (and why I used deliberately the term "extending") would be appealing to Inheritance. [...] The second approach is Composition.

He illustrates the effective application of the principle with the creation of a HTML rendering class. The first version is non-polymorphic and just renders the example DIV and P elements that are passed into it. He changes this up by shifting these element classes into something extending an AbstractHtmlElement class (sharing an interface between them) and updating the renderer to handle these correctly.

In this new post to his site Freek Lijten picks back up his series on the SOLID design principles with a look at the "L" in the acronym - the Liskov Substitution Principle.

The Liskov Substitution Principle (LSP) was coined by Barbara Liskov as early as 1987. The principle is very tightly connected to the earlier discussed Open Closed Principle. A good way of adhering to the OCP is understanding and implementing code that uses the Liskov Substitution Principle. In this article we will discover why and how.

He gives a more understandable explanation of what the rule tries to suggest - a standardized interface that each of his "Bike" instances follows to ensure the contract of a consistent API. Then each of the child classes can reliably assume that there are methods they can use because they'll always inherit them.

A while back there was an article that put a negative spin on PHP ("PHP: a fractal of bad design") and there was a huge community response to it with over 1400 comments on the post itself. Over on the DevShed forums, there's a lengthy new post that goes back over that article, piece by piece, and evaluates everything that was said.

As I've seen this article a number of times, I'd like to go through it to see what everyone has to say on the subject. Warning: This is just stupidly, ludicrously long. it takes an existing 5-page article and tears it apart nearly sentence-by-sentence.

He goes back through each of the sections - Stance, Arguments, Philosophy, etc - and includes quotes from the articles and his own impressions/thoughts about them. There's a section covering some of the individual complaints that were mentioned and things like PHP's OOP model and security.

On the NetTuts.com site today there's a set of reminders about some software principles that all developers (PHP or otherwise) should keep in mind when doing their work:

he fundamental things will always apply. If you have an understanding of the underlying ideas of software development, you will quickly adjust to new techniques. In this tutorial, we will discuss three basic principles and mix them with many more. They provide a powerful way of managing the complexity of software. I'll share some of my personal opinions and thoughts, which, hopefully, will prove useful when it comes to applying them to code and real-world projects.

Their three ideas that should always be in mind during development are:

• DRY - Don't Repeat Yourself
• KISS - Keep It Simple Stupid
• "You Ain't Gonna Need It" (YAGNI?)

For each principle, there's a but of an example showing either some current project that follows the idea or a process that can be used to implement it.

In this new post Ralph Schindler takes a look at the Prototype design pattern and uses it to illustrate some best practices in using constructors in PHP.

If your knowledge of constructors ends with "the place where I put my object initialization code," read on. While this is mostly what a constructor is, the way a developer crafts their class constructor greatly impacts the initial API of a particular class/object; which ultimately affects usability and extensibility. After all, the constructor is the first impression a particular class can make.

He starts at ground level, reintroducing what a constructor is and what it should (and shouldn't) be used for. He talks about constructor overloading, constructor injection, dynamic class extension and using the Prototype pattern to create "an unlimited number of objects of a particular type, with dependencies in tact, each with slight variations." He gives an example with a "DbAdapter" class, showing dynamic class instantiation and how to, using the Prototype method, inject a DbAdapter object and have your class use that instead.