Principles, Patterns and Practices

Tonight I attended the first monthly PHP user group in the Hampton Roads area at Kelly’s in downtown Norfolk. There was plenty of conversation over dinner and Jeremy Fisher gave a short, sweet, and discussion-provoking introduction to namespaces and other features of the upcoming PHP 5.3. Everyone agreed that we’ll do the same thing next month. I’ll collect some schedules from interested parties, determine which evening will work best for the majority, and send something official out soon.

Attending a user group is a great investment in your own circumstances, whether that means your employment or your team. Although it’s just one facet of what makes a group like this great, I have seen some great hires come from connections that were cultivated at a user group. Also, finding employment through people you know and have worked with seems to be the rule rather than the exception. By putting yourself out there and sharing a meal with fellow programmers working in the same technical space as you, you have the opportunity to vet ideas, exchange war stories, and, most of all, build relationships. And this isn’t just about self interest. Sometimes you’ll invest in people. Sometimes they’ll invest in you. Sometimes those relationships will be mutually beneficial.

Thanks to all who attended our first meeting. I’ll be looking forward to this again next month.

Bennett McElwee recently published an article titled “Vespa: A Better MVC“. As the title suggests, he presents his observations of the traditional understanding of an MVC structure and provides his own suggestions for how it might be improved. If this sounds interesting to you, I’d recommend you read the article.

Given it’s relevance to the work I’ve been doing recently, I was particularly interested in Bennett’s improvements to the controller component of the traditional MVC pattern. He distinguishes between two types of controllers, calling them “actors” and “presenters”.

In the context of web applications, this clarification makes great sense to those of us who have implemented the Post-Redirect-Get pattern as a means of fixing the back button in our user’s browser and allowing them to bookmark resources throughout our application. The “presenters” that Bennett speaks of correspond to the controllers that handle GET requests. The “actors” correspond to the controllers that handle POST requests and then redirect to another GET request.

That being said, this improvement really stands on it’s own as a single improvement the controller component of the MVC design pattern. However, Bennett has coupled it together with another model-and-view related improvement which, great as it may be, is less obvious and relevant to me, and I may or may not want to use.

Both improvements may be valuable. I’m confident one is and I’m thankful Bennett has taken the time to document it. But in the end they stand or fall individually. If our purpose is to build a shared vocabulary, why not decouple the two improvements and name them individually?

Thanks again, Bennett!

Our ticketing system, Trac, spits out an email to everyone who has ever been associated with a ticket anytime anyone makes a change to it.  For me, on this team, it generates an enormous amount of email.

And I love it.  It’s great information.  It keeps me in the loop in a great way.  I set aside time at the beginning or end of each day to review all of those emails at once.  Otherwise they would only distract me all day and clutter up my inbox.

However, in the storm of emails Trac spits out at me, there are a select few that really do require immediate attention.  We want Trac to be a legitimate and centralized means of documenting important needs.

Solution?  A couple household filters in your mail client.  Not every change or comment on a ticket assigned to me required my immediate attention, but many do.  Furthermore, all of the changes and comments that do require my immediate attention are on tickets that are being or have been assigned to me.

So filtering all emails with “Owner: andrew.culver” to my inbox and all other identifiable Trac tickets into a separate folder does the trick.

A simple strategy designed to defend my “flow” or “the zone” or whatever you like to call it.  All care of a few basic email filters.

Just a brief one today, since my point is simple.  An email came in this morning with a link to a section of Martin Fowler’s Catalog of Patterns of Enterprise Application Architecture and when I saw it, I got butterflies in my stomach.

The catalog includes brief summaries of many important object-oriented design patterns with some accompanying UML class and sequence diagrams.

I’m notorious for being long winded, but you may be surprised to discover that I absolutely adore brevity.  Martin’s catalog of design pattern summaries is probably my favorite software engineering resource online.

What a great week.

I had the opportunity to meet a lot of people with whom I shared a common perspective on the development of software.  Some of them stretched what I expect from myself as a developer and have helped me set new goals.  Even though I only came knowing one person at the conference, it never felt like networking.  It always felt like socializing.

One of my largest take-aways for the week was a general sense for the direction and increasing maturity of the PHP development community.

The community at php|tek is definitely a skewed sample of the PHP community as a whole.  For one example, I’d venture a guess that you’ve got a higher concentration of developers who are considered leaders in the general PHP community.  But that also makes it a great opportunity to observe trends in what principles, practices, and patterns of software development are being promoted.

Just to name a few of the great practices I heard being promoted:

• habitual automated testing
• scalable software architecture
• good object-oriented design
• accessibility and usability
• sane project management

A lot of the voices promoting these things can be heard in other channels such as magazines or books.  But seeing the sessions covering these topics drawing so many attendees and filling up the rooms leaves me optimistic about the actual interest from the community.

So, I arrived unsure about the PHP community.  I departed saying, “Count me in.”

So, I’m in Chicago for the remainder of the week attending php|tek 2008. The conference is both business and pleasure, since work is paying my way but being here is significantly interesting on a personal level. I’ve really enjoyed developing in PHP even since that first project in which I was forced to work with it, but I’m terribly out of touch with the PHP community in general. There is so much noise out there, and when you’ve already got a small team of developers that you enjoy interacting with, it’s easy to stop searching for the signals out there.

That being said, I honestly believe that it’s a short-sighted snare that sells short both the individual and the team they serve on. That’s part of why I’m here. I’m sure there will be some noise, but I’m hoping for some solid signal in there too.

My wife and I read the Bible regularly and fairly systematically. As we were reading the eighteenth chapter of Proverbs last night, the following stood out to me as being relevant in the context of software development and team dynamics.

A man who isolates himself seeks his own desire;
He rages against all wise judgment.

A fool has no delight in understanding,
But in expressing his own heart.

The words of a man’s mouth are deep waters;
The wellspring of wisdom is a flowing brook.

He who is slothful in his work
Is a brother to him who is a great destroyer.

He who answers a matter before he hears it,
It is folly and shame to him.

The first one to plead his cause seems right,
Until his neighbor comes and examines him.

These are just the tip of the ice berg. I hope you enjoyed them.

Are you familiar with PHP’s output buffering? You should be. If you already are, you can disregard this post.

When we print, echo, provide inline HTML, etc., PHP’s default default behavior is to write to the standard output. Typically that means the web browser or terminal you’re using to execute the script. But this isn’t always ideal. Sometimes we need to capture the output of one script for use in another script. We want to include it, but instead of printing the results to a user, we would like to store them in a variable. PHP’s output buffering allows us to do just that, using simple output control functions like ob_start(), ob_get_contents(), and ob_end_clean().

Using these functions to capture the output of a presentational template is just one real-world example. Understanding it is one step toward adding a familiarity with output buffering and other output control functions to your personal PHP toolbox.

Are you familiar with method chaining? If not, the concept is very simple and you should at least understand enough to recognize when it’s being used. Consider the following example:

Why? The purpose of the class author is to provide a fluid syntax and flexible interface for configuring an object.

How? None of these methods would have previously returned any meaningful information about the operation performed, so the class author has returned $this instead. By returning $this, any additional method call will continue to target the same object. You can also use regular methods that do return meaningful information in a method chain, but they terminate the chain by returning something other than $this.

What I haven’t covered in this extremely brief introduction are the design considerations that exist when designing a class that provides chaining syntax. Why not make all mutator methods support method chaining (ie. $person->setName('Andrew')->setAge(25);)? That belongs to a group of more involved topics which have been covered elsewhere.

While a single complex accomplishment may earn my praise, simple expectations met with consistency will earn my trust.