The Software Alchemist

Practitioners of any field are prone to wonder what sets the experts apart from the merely competent. At least, I wonder that about software development. Read more

I've taken a new approach to version control. Now all code is versioned, even that one-shot CSV mangler that won't ever get used again. Here's why:

1. It will get used again. Be honest, how many throwaway scripts do you actually throw away? Many of them far outlive what you were expecting
2. You need an out. When you've gone down the wrong path, getting to the last "known good" state is trivial with version control. Without, it can be close to impossible.
3. You need to collaborate. Sometimes you need a hand, and that's great, just share the code with your friend who knows everything about mangling CSVs... What, what are you doing? ... Oi! Step away from the zip file, buddy! We all know where that leads, and you have better things to do than figure out why "Mangler v21 Frank's copy new final version.zip" doesn't have Frank's most recent code in it.
4. Version control can educate and entertain. It can be not only interesting, but also informative to look through the history of how a small project has evolved.
5. Why not? It's ridiculously easy:

   git init
   git commit -am "I can haz repo"

   Done! That wasn't too hard, was it?

Read more

I've been working on a (soon to be released) iPad app over the last couple of months. This was a little different to my usual diet of web /server side development, but easier to get into than expected. Read more

Where I work, the process of putting out a new version of one of our products is slow. Actually, it's probably much faster than most places, but we're Agile with a capital A, and we don't stand for any kind of cumbersome process. Read more

There is a gulf of understanding between knowing the nuts and bolts of a technology and knowing how best to apply it. Read more

I was reading "Three Reasons To Roll Your Own Mocks" by Josh Cheek earlier today. One point, somewhat tangental to the thrust of his argument, stood out to me.

"When you make changes, many tests may break. Perhaps you change the name of a method that it invokes on its dependent object. Now you must go update all your dynamic mocks to change the name of the method."

What? When was the last time that you changed the name of a method in more than one place? If you've been using Eclipse, Visual Studio, or basically any other IDE, it should be a long, long time ago. Are you coding in vi? If so... WHY? Do you shun the basic refactoring tools in your IDE... WHY? Read more

I am increasingly aware of the danger of 'prefactoring'. That is, stewing over the minute details of code design before just getting the thing to work.Apparently the name 'prefactoring' is taken, maybe we should call it 'premature factorization' in honour of Donald Knuth. Read more

I picked up a copy of Clean Code by Bob Martin the other day. Having only read the first few chapters, it's already making a difference not only in how I code, but my whole attitude toward coding. (Oh no, this is sounding like an awful infomercial) Read more