We pioneered a pattern for exception handling for Zend Framework back as we initially began development on version 2 around seven years ago. The pattern looks like this:

• We would create a marker ExceptionInterface for each package.
• We would extend SPL exceptions and implement the package marker interface when doing so.

What this gave users was the ability to catch in three ways:

• They could catch the most specific exception type by class name.
• They could catch all package-level exceptions using the marker interface.
• The could catch general exceptions using the associated SPL type.

As an experiment, I migrated my website over to OpenShift yesterday. I've been hosting a pastebin there already, and have found the service to be both straightforward and flexible; it was time to put it to a more thorough test.

In the process, I ran into a number of interesting issues, some of which took quite some time to resolve; this post is both to help inform other potential users of the service, as well as act as a reminder to myself.

This is a post I've been meaning to write for a long time, and one requested of me personally by Evert Pot during the Dutch PHP Conference in June 2012. It details some observations I have of php-fig, and hopefully will serve as a record of why I'm not directly participating any longer.

I was a founding member of the Framework Interoperability Group, now called "php-fig". I was one of around a dozen folks who sat around a table in 2009 in Chicago during php|tek and started discussions about what we could all do to make it possible to work better together between our projects, and make it simpler for users to pick and choose from our projects in order to build the solutions to their own problems.

The first "standard" that came from this was PSR-0, which promoted a standard class naming convention that uses a 1:1 relationship between the namespace and/or vendor prefix and the directory hierarchy, and the class name and the filename in which it lives. To this day, there are both those who hail this as a great step forward for cooperation, and simultaneously others who feel it's a terrible practice.

And then nothing, for years. But a little over a year ago, there was a new push by a number of folks wanting to do more. Paul Jones did a remarkable job of spearheading the next two standards, which centered around coding style. Again, just like with PSR-0, we had both those feeling it was a huge step forward, and those who loathe the direction.

What was interesting, though, was that once we started seeing some new energy and momentum, it seemed that everyone wanted a say. And we started getting dozens of folks a week asking to be voting members, and new proposal after new proposal. Whether or not somebody likes an existing standard, they want to have backing for a standard they propose.

And this is when we started seeing proposals surface for shared interfaces, first around caching, and now around logging (though the latter is the first up for vote).

Cal Evans has organized another DayCamp4Developers event, this time entitled "PHP Master Series, Volume 1". I'm honored to be an invited speaker for this first edition, where I'll be presenting my talk, "Designing Beautiful Software".

Why would you want to participate? Well, for one, because you can interact directly with the various speakers during the presentations. Sure, you can likely find the slide decks elsewhere, or possibly even recordings. But if we all do our jobs right, we'll likely raise more questions than answers; if you attend, you'll get a chance to ask some of your questions immediately, and we may even answer them!

On top of that, this is a fantastic lineup of speakers, and, frankly, not a lineup I've ever participated in. In a typical conference, you'd likely see one or two of us, and be lucky if we weren't scheduled against each other; if you attend this week, you'll get to see us all, back-to-back.

What else will you be doing this Friday, anyways, while you wait for the end of the world?

So, do yourself a favor, and register today!

Once again, I spoke at ZendCon this year; in talking with Christian Wenz, we're pretty sure that the two of us and Andi are the only ones who have spoken at all eight events.

Unusually for me, I did not speak on a Zend Framework topic, and had only one regular slot (I also co-presented a Design Patterns tutorial with my team). That slot, however, became one of my favorite talks I've delivered: "Designing Beautiful Software". I've given this talk a couple times before, but I completely rewrote it for this conference in order to better convey my core message: beautiful software is maintainable and extensible; writing software is a craft.

I discovered today that not only was it recorded, but it's been posted on YouTube:

I'm a big proponent of object oriented programming. OOP done right helps ease code maintenance and enables code re-use.

Starting in PHP, OOP enthusiasts got a whole bunch of new tools, and new tools keep coming into the language for us with each minor release. One feature that has had a huge impact on frameworks and libraries has been available since the earliest PHP 5 versions: visibility.

The error suppression operator in PHP (@) is often seen as a necessary evil. Many, many low-level function will return a value indicating an error, but also raise an E_NOTICE or E_WARNING — things you might be able to recover from, or conditions where you may want to raise an exception.

So, at times, you find yourself writing code like this:

if (false === ($fh = @fopen($filename, 'r'))) {
    throw new RuntimeException(sprintf(
        'Could not open file "%s" to read', $filename
    ));
}

Seems straight-forward enough, right? But it's wrong on so many levels.

I've been working on a proposal for including service locators and dependency injection containers in Zend Framework 2.0, and one issue I've had is trying to explain the basic concept to developers unfamiliar with the concepts — or with pre-conceptions that diverge from the use cases I'm proposing.

In talking with my wife about it a week or two ago, I realized that I needed an analogy she could understand; I was basically using her as my rubber duck. And it turned out to be a great idea, as it gave me some good analogies.

Last month, during PHP Advent, gwoo wrote an interesting post on Aspect-Oriented Design, or Aspect Oriented Programming (AOP) as it is more commonly known. The article got me to thinking, and revisiting what I know about AOP, Intercepting Filters, and Signal Slots -- in particular, what use cases I see for them, what the state of current PHP offerings are, and where the future may lie.

But first, some background is probably in order, as this is a jargon-heavy post.

Now that Zend_Test has shipped, developers are of course asking, "How do I setup my test suite?" Fortunately, after some discussion with my colleagues and a little experimenting on my one, I can answer that now.

With PHP 5.3 coming up on the horizon, I'm of course looking forward to using namespaces. Let's be honest, who wants to write the following line?

$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');

when the more succinct:

$viewRenderer = HelperBroker::getStaticHelper('viewRenderer');

could be used? (Assuming you've executed 'use Zend::Controller::Action;' somewhere earlier…)

However, while namespaces will hopefully lead to more readable code, particularly code in libraries and frameworks, PHP developers will finally need to start thinking about sane standards for abstract classes and interfaces.