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:

One of the exciting features of the newly released Zend Framework 2 is the new module system.

While ZF1 had modules, they were difficult to manage. All resources for all modules were initialized on each request, and bootstrapping modules was an onerous task. Due to the difficulties, modules were never truly "plug-and-play", and thus no ecosystem ever evolved for sharing modules.

In Zend Framework 2, we've architected the MVC from the ground up to make modular applications as easy as possible. Within ZF2, the MVC simply cares about events and services — and controllers are simply one kind of service. As such, modules are primarily about telling the MVC about services and wiring event listeners.

To give you an example, in this tutorial, I'll show you how to install the Zend Framework 2 skeleton application, and we'll then install a module and see how easy it is to add it to the application and then configure it.

A number of months ago, Ed Finkler started a discussion in the PHP community about "MicroPHP"; to summarize, the movement is about:

• Building small, single-purpose libraries.
• Using small things that work together to solve larger problems.

I think there are some really good ideas that have come out of this, and also a number of questionable practices¹.

One piece in particular I've focussed on is the concept of so-called “microframeworks”.

In Zend Framework 1, controller's had an init() method, which was called after the controller was instantiated. The reason for it was to encourage developers not to override the constructor, and thus potentially break some of the functionality (as a number of objects were injected via the constructor). init() was useful for doing additional object initialization.

class MyController extends Zend_Controller_Action
{
    public function init()
    {
        // do some stuff!
    }
}

But this feature is missing from ZF2; how can we accomplish this sort of pattern?

Forms are a nightmare for web development. They break the concept of separation of concerns:

• They have a display aspect (the actual HTML form)
• They have a validation aspect
• And the two mix, as you need to display validation error messages.

On top of that, the submitted data is often directly related to your domain models, causing more issues:

• Not all elements will have a 1:1 mapping to the domain model — buttons, CSRF protection, CAPTCHAs, etc. usually are application-level concerns, but not domain issues. Names valid for your domain model may not be valid names for HTML entities.

Add to this that the validation logic may be re-usable outside of a forms context, and you've got a rather complex problem.

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.