Principles, Patterns and Practices

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.

Introduction

How many evaluations take place on each of the following three statements?

If your answers for each statement were at least 3, 5, and 10, you are hereby dismissed for the remainder of the post. If you (like most I’ve asked) answered 1 for the first statement, please stay awhile. I suspect this post may aid you in becoming a stronger programmer.When we’re done, you should hopefully have a clear understanding of the terms:

• Statement
• Evaluation

Statements and Evaluations

You might think of a statement as a line of code with a semicolon at the end or the conditions we put in a while loop. While that’s true, a more generic and granular definition would be to think of a statement as anything you can wrap parenthesis around and smack an echo in front of. When you think of statements this way you realize that each line of code is often made up of many, many statements, all of which need to be evaluated individually in the process of evaluating the entire larger statement.So our first statement had one assignment. That resulted in the following evaluations:

• The entire right hand side, which we’ll say was $name evaluating to a string.
• The $this variable needed to evaluate to an instance of an object to set a property on.
• Assignments don’t only assign the value, but also evaluate to whatever value was assigned.

(Depending on your knowledge of the PHP engine you may be able to come up with a better number but I think those are sufficient for practical purposes.)

Order of Evaluation

Knowing the order in which these smaller statements are evaluated can also be helpful.A few rules might help:

• Statements are evaluated as they’re needed.
• Function (or method) parameters are evaluated before a function is called.
• Think of the return statement as the function saying “I’m done! I evaluate to …”

For example, consider our second statement:

• If we’re going to evaluate an assignment, we must first evaluate the right hand side.
• If we’re going to evaluate the get() method, the $this->_accounts property must first evaluate to an object.
• If we’re going to evaluate the $this->_accounts property, $this itself must first evaluate to an object.
• Now we’ve got the object from the property but before we can evaluate the get() method, we must evaluate it’s parameter.
• With that we can call the get() method which evaluates to an array. (Its return value.)
• We can finally perform the assignment which itself evaluates to whatever value was assigned.

Why Know It

Consider our third statement. Not only does it have many (10+) smaller evaluations going on, but the object-oriented syntax and execution can be a little daunting to the uninitiated. But being armed with a solid understanding of the concepts we’ve covered will enable you to more easily jump into whatever code is thrown at you. Rather than struggle with what seems like complicated syntax, you’ll be able to break it down, understand it, and debug it with greater ease. It’s a precursor for recognizing the use of design patterns in another developers code. Do whatever it takes to understand how and in what order complex statements evaluate!