Padraic Brady has posted his own response to some of the recent talk about making standard interfaces in PHP applications. His perspective focuses on interfaces and coupling as related to the Zend Framework.

Every PHP framework has it's own unique set of interfaces for common operations such as logging, caching, http clients, filtering, validation, etc. This creates a situation where a framework tends to be loosely coupled but only within the scope of its own interfaces. [...] Loose coupling is therefore a bad joke. It is a narrowly defined concept usually described within the scope of one particular application. We never really apply the concept across multiple applications written with different frameworks because, at that point, the disparate interfaces of both frameworks would immediately make loose coupling unobtainable.

He goes on to talk about a simple example, ZendFeedReader, and how it's very difficult to swap something as simple as the HTTP client out for one from another framework. He mentions the common scapegoat for over-interfacing - Java - and how PHP's is a bit more "practical and flexible" in that department (a good and bad thing).

So yes, common interfaces would benefit PHP and would make framework libraries more interoperable and thus usable within competing frameworks. Hey, if you can't beat them at least make sure you can inject your classes into them. Hmm, still sounds dirty.

In a new post to DZone.com today Mitchell Pronschinske responds to some comments that were made by Lukas Smith about working with interfaces in PHP and what he sees as an ideal "drop in" solution.

The PHP community was reacting to Lukas Smith's "Interfacing the PHP world" for most of last weekend. [...] It's a pretty major propositon to start 'interfacing the PHP' world. Catch up on the conversation and let us know what you think.

Mitchell summarizes Lukas' thoughts into three points - interfaces in separate repositories, PHP frameworks not adopting 5.3 yet and the customization of method names/naming conventions across frameworks and tools. Another response to Lukas came from Herman Radtke with Lukas following up his original post with "Why Bother?"

Lukas Smith has put together a recent post to his blog with some thoughts on standardization of interfaces in PHP applications to help improve code quality and interoperability.

In my previous blog post I was brainstorming the possibility of collaboration between various frameworks to define a set of common interfaces. But I kind of failed to explain why this would be useful. Herman's "rebuttal" made this omission on my part quite clear. [...] That being said the open questions left in my previous blog might still prevent this idea to take off, even if I manage to convince the general community that the above mentioned negative effects are not such a significant concern.

He talks first about some of the things he sees PHP as having done right (citing its popularity) and contrasts it to Java based on the standards they impose. He goes on to mention how interfaces, introduced early enough in the process, can help with the "best tool for the job" idea (with an example involving Symfony2, Zend Framework and Doctrine).

On the DeveloperDrive.com site today, there's a new post with a few reminders for PHP developers out there of things it's easy to forget when writing your applications - some common mistakes to avoid.

Despite the high expectations placed on them at times, developers are human. They were the last time we checked anyways. As humans, we are bound to make mistakes from time to time. And simple, common mistakes often slip past our filters the more comfortable we become with something. [...] But knowing what these common mistakes are and how to avoid them can really help speed up the development process and keep our clients smiling.

His list includes three big ones that, if forgotten, could end up being detrimental to your application (sooner or later) - poor housekeeping/organization of code, forgetting punctuation and forgetting to validate input from users.

Lars Tesmer is currently in the process of learning Ruby. He' been working through the tutorials and some sample scripts and has come across some pitfalls along the way. In his latest post he shares four of them that've stood out in his development so far.

I'm currently learning Ruby. In this post I'll list some pitfalls for programmers coming from PHP that would probably cause some confusion if you aren't aware of them. This list is by no means complete, while I learn Ruby I'll very probably encounter more gotchas, which I will blog about, too.

For each of his four examples, he gives the code PHP developers are used to seeing and the Ruby code that may or may not do what you'd expect:

• Arrays are continuous
• Zero is not falsy
• The keywords private and protected
• There's no static keyword

In a new post to the SearchCo.de blog Ben Boyter generated a listing of the most commonly used PHP functions/structures based on the contents of several of the major PHP projects from around the web.

One thing that I considered some time ago was working out which are the most common functions in a language and adding this as an additional signal to ranking. I couldn't find anywhere else on the web with this question answered so I took my own approch. The method was to take a collection of large PHP projects, including, Wordpress, Mambo, Sphider, Smarty, Drupal, CodeIgniter, dump all their source code into a single file stripped of comments, and then run some simple regex over this file counting the occurance of each function.

His results show the top five as: array, isset, define, empty and assert. The last five ended up being: filemtime, sha1, array_unshift, get_current_user and strchr.

On the Mayflower blog there's a new post talking about some of the common pitfalls for PHP developers that are starting their work with the front end Javascript language.

If we take a look at our current job advertisement, these knowledge is still important, but also skills in JavaScript are asked and strongly desired. If you wonder why JavaScript is so popular at these times, my answer is quite simple: The browser is no longer a stupid instrument to view some static websites on the internet- the browser turned into an (Web-) Application Platform that provides more content then plain text.

They start by comparing some of the data types common between the two (with most things on the Javascript side ending up as an object). They also talk about the fact that arrays are not (technically) arrays like PHP developers think of them. They finish it off with two more common problems PHP devs have when making the move - looping through arrays and "the thing with the semicolon".

If you're new to using the Zend Framework, you there's one big hurdle you might have to overcome. There's a lot of terms used in the system that might not be all that familiar to you. Thankfully Giorgio Sirnoi has written up a guide (he calls it a "Zend_Glossary") to help smooth over the rough parts.

When you're approaching a framework with a learning curve as steep as ZF, it's easy to be overwhelmed by new terms and declare them buzzwords. Instead, they have often a very precise meaning. I've creates this glossary to collect all the defined terms I could find, so that the PHP developer new to Zend Framework would have a place to come and lookup in the time of confusion.

He breaks it up into a few different sections - generic/reused terms, common component names, what MVC and the bootstrap are as well as the different parts of Zend_Forms.

Smashing Magazine has posted an excellent security guide to get you on the road to protecting your site and its data from some of the most common mistakes applications can make. Several of the topics even come with PHP code to illustrate.

Unfortunately, unless we're careful with the code we write, the answer to these questions can often be one we'd rather not hear. We'll skip over denial of service attacks in this article, but take a close look at the other issues. To be more conformant with standard terminology, we'll talk about Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Phishing, Shell injection and SQL injection. We'll also assume PHP as the language of development, but the problems apply regardless of language, and solutions will be similar in other languages.

For each of the topics, there's a general description of how the attack works and, if applicable, some PHP code showing the right and wrong ways it can be handled. Fir things like Click Jacking or Phishing, the descriptions aren't so much about backend code as they are frontend and personal manipulation.

In a new post today Jani Hartikainen has pointed out a few errors that developers commonly make when writing and debugging their code.

Back in august, I introduced the error tracking challenge. While it didn't get as much participation as I had hoped for, I did manage to collect some results. In this post, I'll go through the most common ones, and suggest some approaches to avoiding them. Suggest your own errors and tips in the comments!

He's included issues in three major categories - boolean logic errors, typos/omissions and some common debugging mistakes. Inside each are some suggestions to help them make a less frequent appearance in your code: things like splitting up conditionals for readbility/ease of maintenance and being generally more careful in your development to reduce logic and small errors that could be picked up by the simplest syntax check.