Sleeping in a castle

Last week I had the week off, so me and my girlfriend decided to spend one night somewhere special. When we were looking we saw some amazing places that you can stay in, from a lighthouse to a wine barrel. From a plane to a castle. We ended up sleeping in a castle: Kasteel Hattem.

Sleeping in a castle

Sleeping in a castle

Normally you pick the destination because of stuff you want to do, or see there. This time we picked the destination because of how we’d stay there. So we ended up in Roermond.

Roermond

Roermond did not disappoint though. As a city next to the river Roer, and later the Meuse (Maas) as well, it was rather prosper. They probably built a lot of awesome buildings then, but various fires destroyed the city time after time. From about 1500 they had a marvellous idea: lets build some buildings of stone, rather then wood. The oldest buildings are from that time, often with cellars from 1300.

Situated near the border of the Netherlands, it has had it’s fair share of war. If you happened to be born around 1790, and lived in Roermond, you would have been Austrian, French, Limburgs, Belgian and finally Dutch.

Anyway, enough with the words. Here are some nice pictures. Some taken with a proper camera, some with my cellphone.

All in all it was a very nice outing. It had been a while since we went somewhere for multiple days, last time was our London trip. Going to a place without reading up, without knowing where to go, and just going with the flow is something you should do once in a while ;-).

Introducing dependency injection into existing systems

A while ago I was faced with an interesting challenge: I was busy introducing dependency injection into an existing system. Almost every method call inside this system was a static call, so every class was hard coded to their dependencies.

But, I might be going a little bit too fast here. What is dependency injection?

Dependency injection (DI) is a software design pattern that allows the removal of hard-coded dependencies and makes it possible to change them, whether at run-time or compile-time.

Quoted from wikipedia. For more information on it, you should read the piece Martin Fowler wrote on it. So, what did I need to do with dependency injection?

Continue reading →

Keeping software releasable

Keeping software releasable: release manager hatA true software engineer wants to be able to release at any time with any application. An unexpected problem can require a hotfix, so you want to be ready for it. When maintaining more then ten, twenty or maybe even thirty applications, this becomes a problem. What is a good strategy for keeping software releasable? Lets put on our release manager hats.

What is “releasable software”?

The position that you want to be in when releasing an application, is where the only thing that will change is the bugfix that you just did. This is for various reasons:

  • You don’t want to be dependant on other people.
  • If a problem occurs with this release, you know it’s this bugfix that caused the problem. So it’s clear where to look.
  • Should this problem require a rollback (undoing the change), this will not undo the other feature that was released as well. Features enabling and then disabling can cause problems.
  • Perhaps the other features still need to be tested, and you have to wait on it.

When you have enough programmers working on a project, the last thing is bound to happen. At a certain point in time I became aware of just how often it was happening. We started to call them traffic jams. When unattended, those traffic jams can become really big really fast. It becomes very hard to release your software once this happens, so how can we prevent these?

Keeping software releasable

Since it’s a problem that is created by many programmers, it should be solved by those programmers themselves. If you create the problem, you’re responsible for solving it. If you’re allowed to make a change to an application, you’re allowed to be a release manager for it. It puts the responsibility where it belongs. This also scales with the programming team. It’s logical for a self organizing, agile team to do it this way.

This really is a story of how a simple, low tech, maybe even childish solution was useful in a software engineering environment.

We made cards for every application. They state the name of the application with their icon, and two words: “Release manager”. When someone makes changes that would be possibly blocking for a hotfix, they receive the card of this application. This gives them the responsibility to release the application, and then put the card back.

So why do these cards work?

  • They give a visual reminder that you still have work to do.
  • You’re aware that this reminder is also visible for anybody that might be close to your desk.
  • From a management perspective: it takes very little time to manage the releases. Basically everybody is promoted to be a release manager.

To make this work these cards have to be recognizable, hence the name and icon. The cards have to be durable, so a colleague of mine had the brilliant idea of laminating the cards. Doing so made them really robust. The cards we made are about the size of a business card.

Have a board that has all cards, so that you can see if one of the cards is missing. After a deployment the cards should be handed in again.

Problems encountered in practice

Just like any solution for any problem, there are some downsides.

  • You have to measure the thing you give the cards for. If the cards do not reflect the accurate state, the system starts falling down. One way to do this is a daily e-mail, where the first person that comes into the office hands out the cards.
  • Sometimes multiple people have pushed commits that are not released yet, and the card is handed to the wrong person. Just ask them to give it to the right person in that case ;-).
  • Cards can get mysteriously lost at peoples desk, it can take some time to find them.
  • This probably does not solve all your problems, consider using (a possible subset of?) Git flow.

This works because for a web application a release is very cheap. This might not work for you if it’s physically impossible to release your software often (cd/dvd/blu ray), you’re dependant on a third party (app store, play store) or you’re not in control of all your release environments (wordpress upgrades).

Are there other cool uses for cards like this?

Cards like these can be a good reminder for any common task within the department. It could also be used for ensuring some batch job is running. Or that there is a high prio ticket that needs to be done asap.

Anyway, try them out! They worked for my use case, so why not yours?

New WordPress version released: 3.6

See your revisionsLast monday I decided to upgrade some of the systems that I maintain to their latest version. When doing so I saw that there was a new WordPress version released: 3.6. The release is codenamed Oscar, and it’s now rolled out on this website, and on odetocooking.com as well. As a user, you’ll notice no difference at all, though. All the new features are done in the backend, to make authors more productive or happy.

Continue reading →

Composer post-checkout hook in git

One of the main advantages of developing with scriptable tooling is that they sometimes give you nice presents. While doing some research for a future article, I came across a composer post-checkout hook. The picture below displays very nicely how this works.

Composer post checkout hook

When you change branches there is a chance that you have different dependencies, and thus need to run composer install. This will warn you when thats the case.

Interested? See the gist below :).

Unfortunately the shell for hooks is not interactive, so you can’t ask the user whether he would like to do it right now. Still really useful, since the PHP ecosystem is evolving towards using composer.

A bit of background on post-checkout hooks

This little trick uses the post-checkout hook. This is what the official git documentation says about it.

After you run a successful git checkout, the post-checkout hook runs; you can use it to set up your working directory properly for your project environment. This may mean moving in large binary files that you don’t want source controlled, auto-generating documentation, or something along those lines.

There is more in the documentation.

Unit testing legacy applications

There are a lot of legacy applications out there without unit-tests. It would be very nice to have them, especially when you’re asked to fix a bug there. So, how can you start unit testing legacy applications? Lets start with a simple mantra.

Test one unit at a time.

These are unit-tests after all. There is one important thing that follows from that.

When you write a test for a specific unit, you can assume the rest of the world has been tested and works perfectly.

Which is true, since there should be individual tests for “the rest of the world” as well!

An example case

Lets do a little case here: say your legacy application is a top-down racing game that looks like this.

Unit testing legacy applications: example

The Vehicle class handles the movement of any vehicle, assuming that it’s subclass sets the correct speed. It needs the Input class to exist, and function properly.

If we want to test one unit at a time, which unit should we pick for our first unit-test? A unit can refer to a class, or a function in it. Lets pick a class in this case.

There are a couple reasons to test the Input class first:

  1. It has no dependencies, so it’s very easy to write a unit-test for.
  2. When unit-testing something your target is to find bugs in the unit you’re testing. It should never fail on an error in a related class*.
  3. So testing it will give you a solid foundation to build on.

Order of writing your unit-tests

Following the same reasoning, we’ll test Vehicle before Car, since Car depends on Vehicle. In the end we can write one for Car.

Unit testing legacy applications: Prefer composition over inheritance

Once you’ve validated that Input is working**, it’s time to look at Vehicle. How how will we test Vehicle, an abstract class? Testing an abstract class is very hard, so preferably it should be avoided. This is where one of the other mantras of Software Engineering comes in.

Prefer composition over inheritance

So prefer to “use” a class rather then to extend it. In this case it’s reasonably easy to fix, by extracting the functionality of Vehicle into a small utility class: MovingPosition***. It’s a class with no abstract methods, and hence easier to test.

Prefer composition over inheritance

So, this makes it really easy to write a unit-test for a MovingPosition, which only leaves us the Car to worry about. That however, is reserved for a followup of this post!

The small print

The class diagrams are made using PlantUML. The flowchart is generated using graphviz / dot.

* Unless the unit-test of the related class is failing as well, of course.

** For some general tips on how to write unit-tests, see this answer on stack exchange.

*** Unit testing legacy applications is hard when there are no unit-tests yet. Sometimes you have to refactor the source code to make it easier to test, and that can cause stuff to break. So be careful, since you have no safety net yet. Be sure that it’s an actual improvement if you adjust the original source code for a unit-test. Do not add methods that are only used in the unit-test!

Another consideration is that it’s probably not possible to follow all of these nice rules when unit testing legacy applications. Partially due to the size, partially due to the time you have to spend on it, or maybe because you’re new to it.

PHP ecosystem evolving

A lot of nice stuff is happening in the PHP ecosystem right now. In this case I’m not talking about the PHP 5.5 RC3 that was released lately, since that will take a bit more time to be released, let alone be available for the world to use. I’m talking about the Symfony 2.3 release, which I’ve been looking forward to. Partially because it’s the first LTS*, but also because it continues to split Symfony up into individual components.

After the stopwatch and the property access components in Symfony 2.2, we now get the new debug and intl components. These might not be the most exiting components in the world, but it’s a sign of a bigger trend in the PHP ecosystem: releasing individual components. This has been going once for the past two years, since Symfony 2.0 was initially released.

PHP ecosystem evolving - symfony versions

So slowly there are more and more components emerging. Partially this is because PSR-1 and PSR-2 have brought use a shared coding style. Partially this might be because individual components are easier to understand. Mostly this is about composer though.

Composer: Changing the PHP ecosystem

Composer is a dependency manager for PHP. There are a couple of benefits in using it:

  • Autoloading. This might seem like a basic thing, but it’s very relaxed to not have to think about it any more.
  • Lightweight. Only include the components you actually want.
  • Mix and match. In the past you’d pick one framework, and then hope it had the components you wanted. Now you can pick the best individual components for the job.
  • Security awareness. If you use composer, you can check your dependencies for known security issues.
  • Visibility. All your dependencies are stored inside your vendor/ directory.
  • Control. Manage your dependencies yourself.
  • Dependency awareness. Knowing which components depend on what gives understanding. Just show a graph of your current dependencies using clue/graph-composer. The graph below displays the dependencies of the symfony/translation component.

Dependencies of the symfony/translation component

When using composer, there are two questions that come up a lot

  • Has this problem been solved before?
  • Could this be a library?

And both of those lead to a lot more code reuse, which is good.

Downsides?

Every story has two sides, so that probably applies here as well. Developers tend to like the new and shiny, but lets look at the story from two sides.

  • You might run into the Composer API limit at GitHub.
  • What if GitHub is down? What if packagist is down?
  • Packagist funding.
  • Managing dependencies can take time.
  • Conflicts on your composer.lock can be annoying.

Balance

For me the balance is very positive. With over 6 million package installs last month, it seems a lot of other people agree. The real question might even be

When will Composer be an integral path of the official PHP release?

* Long Term Support (LTS) means it will be supported until the end of May 2016. Yes, that is a whopping three year period of security patches!

Agile event 7 at Arrows Group

Yesterday I was invited with a colleague to join the Agile event 7 at the Arrows Group. The speakers were very interesting, Maarten Hoppen and Jeff Sutherland. Jeff Sutherland is one of the inventors of scrum, so I was eager to go. For the people that think he’s that means he’s the inventor of this…

Agile event 7, about a different kind of scrum

He’s not. Scrum is a way of being productive with a group, of developing software in a incremental and agile way. When Jeff Sutherland was inventing scrum, he really looked at the rugby game*. Why are some teams really successful, while others lay behind? One of the answers that he found was that the best teams were pushing themselves to improve. Fighting to become better every sprint. In sports doing nothing is standstill.

For a part his talk was about convincing people that scrum is a good thing to do. Since this was an agile event, I guess no-one in the room needed to be convinced of that. Anyway, one graph he showed was this guy. A lot less failed projects, but we should still be able to do better then this. But how to improve?

Agile vs waterfall success rates

Scrum anti patterns at Agile Event 7

One of the scrum anti patterns that Jeff Sutherland mentioned was in handling interruptions in a bad way. It’s a challenge that a lot of teams face: unplanned change. The blog post dealing with emergencies explains the problem and possible solutions very well!

After the presentation there was a workshop, and after that there was a short Q&A session. One of the questions asked was about communicating scrum results towards management. One of the most powerful ways of communicating to management how good a team is doing is by comparing the velocity of a team. So far we haven’t really been measuring that, but I think we should give it a try.

* A lot of sport references. He’s not a rugby player though :-).

All credits for the rugby scrum image go to Pierre Selim, who released it under the Creative Commons Attribution-Share Alike 3.0 Unported license.

Humble Indie Bundle 8: Awesomenauts

Yesterday I bought the Humble Indie Bundle 8. The game that triggered this was Awesomenauts, it’s a fast paced DOTA game (with a lousy story, of course). Anyway, a video will explain this more clearly.

Playing Awesomenauts feels like playing Fat Princess. The trailer makes it seem a bit shallow, but there are a lot of tactical considerations

  • A ton of different characters to pick from
  • For every character you have to pick which skills will be available for purchase in game. A bit like having a talent tree in World of Warcraft, except you can change it every match.
  • You have a “drill core” in your own base that you have to protect. Unlike your random capture the flag, or Fat Princess, the thing in your base does not recover once it gets hit. So if it gets attacked, you will be there.
  • The real power of the game is probably to play it split screen and online. I’m really curious to see the balance of it all, will certainly give it a try.

Next to that it also has some “meta” stuff going for it

  • It’s available cross-platform. And since Steam is available on Linux now, I was able to add all of these games to my Steam account.
  • It’s made in the Netherlands, so go Romino games!
  • Buying the Humble bundle also supports charity.

Getting the Humble Indie Bundle 8

If you like the game, you can still buy the Humble Indie Bundle 8 for one more week.