Seven steps to WordPress on Heroku

I’ve created a project on GitHub to make it easy to install WordPress onto Heroku.
Plugins and themes can be specified and installed via the composer.json file.

The seven steps are:

git clone https://github.com/andypalmer/easy-wordpress.git my-new-wordpress
cd my-new-wordpress
heroku apps:create my-new-wordpress
heroku addons:add cleardb:ignite
heroku config:add DATABASE_URL=`heroku config:get CLEARDB_DATABASE_URL`
git push heroku master
heroku open

There are a couple of other tweaks required to allow uploading assets, but that’s essentially it.

Happy blogging

Fragility of Design-Pattern Named Classes

Design patterns are about how something does it’s job, rather than why. Using a design pattern name in the name of a class makes it quite fragile. For example, if you have called all your classes BlahBlahState, then refactoring to a Strategy is quite invasive, but if it’s phrased in terms of the why, then the names don’t need to change.

A good analogy here is the relation of unit tests to implementation; you should be able to change the internal implementation of the class without changing the tests. If you can’t, then the tests are too brittle. Likewise, you should be able to change the implementation without changing the class name; if your class name is tied to the implementation, through the pattern name, then it’s too brittle.

What’s wrong with technical tutorials

I’ve been diving into a few new technologies recently, and I’ve been heading to Google to find tutorials and documentation to help me out.
I was describing my frustration with the way these tend to be written to my colleagues. A typical example is the “Do something with x in 20 minutes” tutorial. For Ruby on Rails, it’s writing a blog engine, and for Angular, it’s a to-do list.
These are great for showcasing techniques that overcome the itches that they were written to scratch, but they don’t explain what those original itches were.
It’s a bit like being taught to parallel park, and your instructor saying “This car has power steering. Power steering makes everything easier. See how quickly and easily I can turn the steering wheel, even though I’m not moving. Power steering is the best technology ever”. For people who know how to park, and know how hard it is to turn a non-powered steering wheel while stopped, this kind of information is great; but for people who are there to learn how to park, it doesn’t give them any of the information they need to know about how to park, why they’d want to parallel park or that there might be other parking alternatives.
These newbies might stumble across a method for parallel parking, but they attribute it to the power steering because that’s what their tutor was raving on about during their lessons. When faced with a new problem, they might then say “What we need now is power-gearing, or power-acceleration” and end up using the wrong tool for the wrong job because they never understood the motivation behind the right tool.

Soap Opera Personas

Teams often use personas to help them identify their users and the types of actions they’ll perform. This is usually a workshop exercise that will last many hours and identify 5-10 key characters with a few paragraphs of history and motivation.
I find that these personas tend to get forgotten and that user stories are still written “As a Customer” or “As a Customer Service Agent”.
I’ve been recommending that my teams use a method I call “Soap Opera Personas”. In TV soap operas, we don’t get a big introduction to the characters at the beginning of the episode; we get thrown in at the deep end and we learn about the characters as they go about their daily lives. For persona writing, this means that we can avoid the workshop exercise and start with very basic characters.
Take “Carl, the Customer Service Agent”. As we start to define stories, we write them “As Carl” and bit by bit, we get to learn a little bit about him. For the first few stories, we might not need any other characters. As the project progresses, we might find a few behaviours that seem outside of Carl’s usual routine. If someone suggests a feature that requires setting accelerator keys so that keyboard users are more effective, we can introduce “Kevin, the keyboarding CSA”. When we need to have reporting and administration functions, we can introduce “Sharon the Supervisor”.

This might seem a little cute, but it has immense power. Security features can now be tested by having Carl try to do something that only Sharon is permitted to do. The team can push back on features that seem at odds with the stories they’ve built so far; “This feature is labelled as a Sharon feature, but it seems more like something that Kevin and Carl would be doing day-to-day. Is there a reason for that?”
It gives the team something to identify with. Just as somebody can jump into a soap opera at any point, and infer the backstory; new team members absorb the characters as they listen to discussions during planning or story writing. It enriches the experience and gives another dimension for people to ask questions.
In soap operas, characters sometimes suddenly reveal a secret history; Phil is in witness protection from the Mafia. As long as the revelation doesn’t completely invalidate the character we’ve come to know, we’re happy to accept it. Our personas can also cope with significant changes when key aspects of the project change, allowing stories and automated acceptance criteria written in this style to adapt as the project progresses.

Like with all good characters, once you get to know them well, the stories write themselves.

Opscode Chef and the Single Responsibility Principle

My current project is managing the software and distribution of a hardware appliance. We send out physical machines to our customers and we really need to know that they are all identical.
I’ve set up a build system that uses PXE to boot the Ubuntu installer, which is preseeded with a very basic install of linux. We then use chef (actually chef-solo) to configure the remainder of the software. (I’ll write a bit more about the reasons behind this later)

While I’ve been writing new recipes, I’ve started using a pattern that ensures good separation of responsibilities while making the recipes themselves easy to read.

In my pattern, the default.rb file in the recipe consists only of includes. The default recipe is used to make sure that something useful happens.
For example, I created a recipe to install and configure the Hamachi VPN client. This consists of two recipes; install.rb (which downloads and installs the appropriate package and dependencies) and connect.rb (which authenticates with Hamachi and joins the appropriate network). The default.rb includes these two recipes.

I’ve found that this style results in much tidier recipes.

Maintainable Code

I’ve uploaded a presentation about Maintainable Code that I put together for a client almost a year ago.

It’s a lot more text than I’d prefer in a presentation, but this was for a small group of developers and was more of a face to face conversation with examples on the slides to back up the points

It’s mainly a series of thoughts that I should have shared on my blog or twitter; hopefully this will go some way to helping get the ideas out there

What can a consultancy do for me?

An external consultancy can help an organisation progress in a number of ways. When not outsourcing, these usually fall into three categories; training (someone shows you what to do, in a controlled environment), mentoring (someone shows you what to do, in your own environment) and coaching (someone encourages you to explore and develop your own environment)

Training is usually fairly low cost, but it usually only provides an overview of what something can do for your team. Training can be a useful morale boost, but it very rarely becomes immediately applicable to your business domain. Acquiring a new skill requires practice in a real environment. This loosely corresponds to moving someone onto the Dreyfus skills ladder or moving from Unconscious Incompetence to Conscious Incompetence in the four stage model.

Mentoring allows your team to try out new skills under the guidance of a skilled practitioner. When the team member does something inconsistent with current practices, the mentor will intervene, explaining why they are intervening, any likely problems from the original solution and demonstrate an alternative solution, explaining why they think this may be more appropriate. After the discussion, the pair may decide to continue with the original solution and see if it works, or go with the alternative. This loosely corresponds to moving the team member to Competent on the Dreyfus model or to Conscious Competence in the four stage model.

Coaching is a more hands-off approach. The team will continue to work in their normal style, while the coach observes. Using Socratic questioning, the coach will generally guide the team members to explore new avenues of thought, to discover problems that they are likely to encounter and to work in a way that minimises the likelihood of any unknown issues encountered becoming an insurmountable block. Coaching offers the highest value, as it gives the team a toolset for modifying their thinking on an ongoing basis. It corresponds loosely to moving into the advanced stages of the Dreyfus model (Proficient / Expert) or towards Unconscious Competence in the four stage model.

Agile is a means, not an end

At RiverGlide, we’re often asked to help with “Agile transformations”.

My definition1 of agile is being flexible to adapt an existing process.

That is, if your existing process looks like waterfall, you’re still agile if you introspect, retrospect and experiment to improve your process. If at the end, your process looks like waterfall, then as long as you have introspected, retrospected and experimented and found that this approach gives the best results, then your process is agile.

[1] Although this might not fit with other definitions. Your mileage may vary

Finally, a use for checked exceptions

Those of you who have followed my blog, been subjected to it on a client site or have talked to me about programming will know that I have a few issues with checked exceptions.
Well, this morning I had an idea of a potentially powerful use of checked exceptions (if only temporarily).

The same people who will have heard about my dislike of checked exceptions will probably also know about my dislike of returning null. I was mulling over a legacy code base that I may be taking over in the future and one of the first things that I would like to do is to replace all null returns with something meaningful.

Normally, I would remove nulls by searching for the offending return statement, fixing it to do something meaningful (and if I don’t know what meaningful means in this place, throw an exception), then find usages of that method in the workspace and remove any (now defunct) null checks.

Enter the checked exception as a refactoring tool!


public Result someMethod() {
Result result = someMethodIDontControl();
if(null == result) {return null;} // Actually, this is really crap because in reality, I'd just return result, but bear with me!
return result;
}

becomes


public Result someMethod() throws IUsedToReturnNullPleaseFixMe {
Result result = someMethodIDontControl();
if(null == result) {throw new IUsedToReturnNullPleaseFixMe();} // This is temporary. The right thing _might_ be an exception, but we'll work that out later
return result;
}

Now we can lean on the compiler to find all the places that call this method. We can strip out any null checks (that are now unnecessary), look to see if there is something meaningful that we should be doing, and then add throws IUsedToReturnNullPleaseFixMe to the method we’ve just fixed. When we’ve propagated our exception to the top level, we’re done. What I would do at this point is probably delete the exception class, fix all the resulting compile errors by removing the throws clauses, until finally the last compilation error is the original throw new IUsedToReturnNullPleaseFixMe(); which I can now replace with something meaningful (e.g. throw a meaningful exception, return a meaningful NullResult, convert to a collection and return emptySet() etc)

I’ll show you mine if you show me yours

Bob Marshall posted on Twitter:

I replied with:

and he replied:

In 1956, George A. Miller wrote a paper arguing that the conscious mind, the part that contains our inner voice and that does the reasoning processes, can handle 7 ± 2 items at a time. My view is that, in order to be able to function within these constraints, we learn to group similar things together so that they take up less processing space.

For example, if I want to remember a six digit number, it might be easier for me to remember it as 3 two digit numbers than as 6 individual numbers. Very familiar numbers, such as the phone number of my parents only take up one space.

It’s like I’m carrying a fixed number of boxes, all of which are the same size, but in which I can store things that (in my own mind) are grouped together.

One thing I’ve noticed though, is that I begin to speak of the ideas inside in terms of the labels that I’ve added to the boxes. In terms of hard facts, like numbers or addresses, this doesn’t really make much difference, however, when the ideas and opinions in the boxes are much more subjective, this can lead to confusion and disagreements (or sometimes, vigourous agreement :-) )

For example, imagine that I am moving house and packing my belongings into boxes. In one box, I pack the contents of the fridge and because the fridge is in the kitchen, I label the box “Kitchen Stuff”.

I say to the removals people, “The box labelled ‘Kitchen Stuff’ has to be moved quickly. It’s very important that this box is moved as fast as possible”.

The removals people reply “You’re insane. Boxes labelled ‘Kitchen Stuff’ have to be moved carefully, and that means that we have to take it slow”

“No,” I say, “this box has to be moved quickly. If you move it slowly the contents will be ruined”

“No,” they say, “if we move it quickly, the contents will break. We must move it slowly and carefully”

I open the box and show them the contents and they understand. “Oh, it’s fridge stuff. Why didn’t you say so? When you said ‘Kitchen Stuff’ we assumed that you meant plates and glasses”

When we put labels on things in the boxes, it becomes much quicker for us to talk in terms of the labels. However, although we may have boxes labelled in a similar way, that does not mean that the contents are the same.

The box in my mind labelled “Scrum” may match a great deal of the contents of the box that you have labelled “XP” or that someone else has labelled “Lean”. The good thing about these boxes in my mind is that I can have an object appear in more than one of them. I might even place these three boxes into another box labelled “Common sense” (although I strongly suspect that the box with that particular label is guaranteed to be vastly different between every person)

As with my conversation with the removals men, I can get into a heated discussion with someone if we’re talking in terms of the labels on our boxes.

“XP is this, this and this”.

“No, that’s Scrum!”

The only way we can truly reach an understanding is if we recognise that we’re arguing over a label, and open our boxes to compare contents.

Sometimes, I even forget what I have stored in my boxes. I might only be talking about my memory of the things that I think I stored in the box. Opening the box and reviewing the contents, especially when someone else is doing the same, can help me to find new ways of categorising the ideas within. We might even find a common ground and start a revolution.

So, next time we don’t see eye to eye about the memories of the contents of our boxes, remind me “I’ll show you mine, if you show me yours”