Simple, Easy, Risk and Change

I’ve been thinking a lot about change lately. Things finally resonated to me after listening to Uncle Bob Martin on No Capes. He made an amazingly interesting point about change and different methods for minimizing the risk over time of change.

I want to share some of what I’ve been thinking about along those lines. What follows is a collection of some of my evolving thoughts relating to change and complexity. Let me know your thoughts in the comments.

Alternatives To MVC

Last week, I wrote A Beginner’s Guide To MVC For The Web. In it, I described some of the problems with both the MVC pattern and the conceptual “MVC” that frameworks use. But what I didn’t do is describe better ways. I didn’t describe any of the alternatives. So let’s do that. Let’s talk about some of the alternatives to MVC…

A Beginner's Guide To MVC For The Web

There are a bunch of guides out there that claim to be a guide to MVC. It’s almost like writing your own framework in that it’s “one of those things” that everyone does. I realized that I never wrote my “beginners guide to MVC”. So I’ve decided to do exactly that. Here’s my “beginners guide to MVC for the web”:

Foundations Of OO Design

It’s quite easy to mix up terminology and talk about making “easy” systems and “simple” ones. But in reality, they are completely different measures, and how we design and architect systems will depend strongly on our goals. By differentiating Simple from Easy, Complex from Hard, we can start to talk about the tradeoffs that designs can give us. And we can then start making better designs.

Thoughts On PECL Frameworks

In recent months, a number of new frameworks have cropped up for PHP as PECL extensions (Including YAF and PhalconPHP). They promise to provide huge performance gains and lower resource usage for PHP applications. On the surface, they appear to be incredible tools for improving development. But they aren’t all they are cracked up to be. In fact, I would argue that they are actually not necessary at all.

Object Scoping: A Triste Against Service Containers

Yesterday, I got in an interesting conversation on twitter about object scopes and what constitutes a global scope. The discussion started around a piece of code that I stumbled upon from Fuel 2.0. I am a firm believer that service containers are not a form of Dependency Injection, and are only slightly better than global variables. That led me to make a few comments that elicited a reply from two Fuel developers. That led to a rather interesting debate that just couldn’t fit into 140 characters… So I’m going to go into topics that are tightly related: variable scoping and service locators.

Framework Fixation - An Anti Pattern

In this day in age, it seems that the community trend is completely and unequivocally trending towards the use of web application frameworks. So much so that the defacto first comment to someone asking how to do something seems to be “Just use a framework, and it’ll solve the problem for you.” While I completely understand why this is the case, I can’t say that I agree with it. And while I do believe that frameworks serve a purpose, I think that they are vastly over-used. Let me explain why…

Application Architecture - The Case For Layers

Very often when we look at a class diagram for a new application, it’s quite overwhelming. There are tons of classes, all interacting with each other. These interactions are everywhere. It actually resembles a spider web of interaction. Trying to decode this web to figure out what the application is doing can be a lesson in futility for some applications.

How then, can we design an application such that it’s easy to follow? How can we build an application that’s easy to understand on all levels? The answer is deceptively simple: by using layers. Let’s explore how we can use layers to help build our applications in a clean, easy to follow and maintainable manner.

Open Standards - The Better Way

There has been a lot of traction lately on the topic of the PSR “PHP Framework Interoperability Group”. They are introducing two new proposed standards: PSR-1and PSR-2, both dealing with code formatting standards. Actually, calling them proposed is a bit of a short-fall, since they both already have enough votes to be approved. I have read both, and actually agree and think they are quite good.

However, there’s a deeper problem. Open Standards is something that the internet was built upon. From HTTP, E-Mail and HTML to ECMA Script (JavaScript), OAuth and JSON, open standards are everywhere. The problem with the entire PSR process is that it is not designed to produce open standards.

The MicroPHP Fallacy

I came across a rather interesting post yesterday entitled The MicroPHP Manifesto. The author made clever use of a very interesting analogy (drum players) to try to prove his point that less is more. The article makes a very interesting read, and I would suggest that everyone reads it. Go ahead. I’ll wait.

With that said, I have to disagree with the article rather vehemently. I think the message is somewhat right, but for all the wrong reasons. Let me try to explain: