7 Language Lion

So, many moons ago I started working through the 7 languages in 7 weeks book. I saw signs of the loveliness that has won Ruby so many fans, and I battled with Io, eventually finishing the section ready to move on to another language. It was around that time that I ran out of steam. Tucking myself away in my room to learn about a new language doesn't fit well with trying to play family man, and installing a bunch of new languages on my mac when I don't have a good Unix background to know if I'm screwing my system up left me a little concerned too.

Fast forward a few months and Mac OS X Lion is released for a bargain price. I decided to set up my much neglected laptop with Apple's latest big cat and start using it for the development of my development. With this release Apple have relaxed their restrictions about using the OS on virtual machines which struck me as an excellent opportunity. At this time, VMWare Fusion is helping to enforce Apple's old restrictions by only letting you run server versions of OS X in their VMs, but with a little help from this excellent post here I was able to create a hacked image that satisfies VMWare.

That gives me a nicely virtualised sandbox to be able to mess around to my heart's content without screwing up the main OS installation and with the added ability to roll back to an earlier snapshot if necessary, but this icing on the cake came with this next link. Here we see how to set up Spaces in Lion so that Fusion can be restricted to a single screen. This allows me to easily switch back and forth between the main OS and the VM with a gesture. Marvellous.

The starting point for my dev VM has Lion, XCode, Git and Gitbox. Whilst this is available on the mac app store, getting it straight from the dev's site means that there is a free download which allows me to use it with up to 3 repositories rather than having to fork out £27.99, which is great for my light usage. My free private Git repo is provided by unfuddle. Github may be getting all the publicity, but I like being able to keep my code private which usually costs monies, so kudos to unfuddle for that too. After snapshotting that for ready rollbackability, I've installed GNU Prolog, so will be hoping to delve into the next chapter soon.

TDD justifications

In recent years, TDD has surged in popularity. If we look beyond pure TDD to consider writing unit tests in the same general timeframe as the production code, or having automated integration tests then such practices are even more widespread. However, I think that there is a bit of an echo chamber effect that happens with the sort of devs who blog, tweet, go to conferences, talk on podcasts, post on stack overflow etc. that can lose sight of how many people code for a living but don’t pay attention to what is happening in the world outside their office, so these good practices aren’t nearly as widespread as some of us might like to think.

I was brought into my current job as part of a drive to improve on the use of agile techniques and best practices. On a dev team of around 10 people there was only 1 other person writing unit tests so it all started as something of an uphill battle. Being the new guy on a team and trying to change the processes can seem like you are just being critical and accusing other developers of not being good enough. Introducing ideas with a good explanation of the benefits is vital to avoid causing an us and them type rift, even when it is part of your job description. When testing has been viewed simply as a manual process that is the domain of the QA department I think there are 3 stages of understanding to get across to the team. Firstly the value of having automated tests at all, with the implication that the suite can include integration tests. Secondly the point of having proper unit tests so that different components are tested in isolation. Finally the reasons for writing your tests before the production code.

Why automate tests?

• Regular feedback to show if changes have broken anything.
• Confidence to refactor code from working but messy to working and clean.

Why unit tests?

• Integration tests can be slow to run if there is network, database, filesystem access etc. Isolating your tests can provide huge speed ups with doubles providing required interactions. The regular feedback mentioned above can become even more regular.
• Taking other components out of the equation makes it far more obvious which part of the code is at fault when something breaks, an integration test could give a huge stack of components that participate, but a unit test will likely be a single public method call on a component with just a few private methods to dig through too. This can aid with the point about refactoring made earlier, although integration tests are essential if you decide to rework larger chunks of code.
• Mocking out the dependencies of a component means that different devs or even teams or companies can be working on those layers independently without holding up consumers of that code, as long as a suitable interface has been designed and agreed upon up front. Or even if it will be done by the same dev they can stay focussed on what the current class deals with whilst that is in the forefront of their mind, and move on to the dependency and deal with that later.
• Writing pure unit tests requires the code to be written with an eye to testability, meaning that code will have to be decoupled and conform to good design principles.

Why test first?

• Having the test in place before production code helps to push the decoupling aspect harder than writing tests afterwards where code may need changing to become testable, or the odd integration test may be allowed to sneak into the suite.
• You only write production code that a test has called for which helps you apply the YAGNI principle.
• That last D in TDD is Design not Development, writing your test first means that you are making a declaration of how you want to use that API so tends to lead more towards a clear, usable component. This is an area that is a bit more obvious with newer test frameworks that use variation on the word Specification in their name, rather than Unit or Test.

The first set is an easy win, the latter sections require more work, not to mention some fundamental changes in the way that the team has to approach their code. Fortunately we’ve had a push from the top level management to improve the number of tests that we have which is helping to push some of the more reticent devs into trying to adopt these practices, as well as giving us some scope to try and provide some mentoring to them so that they can start doing some TDD without being thrown in at the deep end.

Sadly we have some highly test-resistant code with lots of classes full of static methods that can’t easily be mocked out, so I shall post about the techniques that we’ve come up with for dealing with that soon.

I should probably blog more…

The road to hell is well known to be paved with good intentions. I set out with the intention of blogging plentifully to try and build my own personal brand, but like many blogs the reality hasn’t been quite so impressive. However, today I have been watching Scott Hanselman’s presentations on the topic “Every Developer Needs a Blog” Part 1 & Part 2 and have been inspired.

There was much goodness packed into the talk, but the part that stood out to me was the suggestion that the alpha geeks in a company tend to be the ones who send emails around to the rest of the team with all the shiny dev news, tips and other such content, and that this could make for prime bloggable content. I certainly fall into this camp, and so I’ve decided to see if I can retrofit some of my team emails into this blog (after removing anything too company specific), and subsequently use it for such future messages. I don’t expect to be anywhere near the bleeding edge of progress in the development community, but based on my experience most companies aren’t, so I hope that it will be of some value.