If you've been programming for awhile, then you've probably experienced your fair share of cryptic error messages. It's understandable that building in detailed error messages that are clear to even novice developers is not always a high priority for programming languages when there are so many other features to create and issues to address. The PHP language has decent error messages, but it is by no means an exception to this rule.

The three errors he covers are probably familiar to anyone that's been working with PHP for any length of time:

• Fatal error: Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM
• Fatal error: Can't use function return value in write context
• Fatal error: Exception thrown without a stack frame in Unknown on line 0

For designers, Symfony2 has been a welcome change from those old flat PHP files. Twig is beautiful, the framework separates the code from the layout, and we no longer have to find our way through lines of PHP code. But if you are a designer working on a symfony project for the first time, these are a few tips that can help you get up and running quickly.

The four common problems they've seen are:

• How do I disable the toolbar at the bottom of the page?
• Errors about missing libraries/files
• No Javascript or no-css showing up
• A completely blank page

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.

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?"

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).

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.

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

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.

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".

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.