Gavin Laking

Ruby Developer for On The Beach, Manchester, UK

Read this first

Yes, I test the initialize method.

Let’s get a few things out of the way. Number one, don’t delete tests ever. Why? They were relevant at the time and even when you think you’re covering everything, you might have forget that one edge case which one of your tests is remembering for you.

Two. Having that test for the initialize method (I’m talking to Ruby developers like me), serves a purpose. It gives you feedback when you first start out with your class that you’re requiring the right file, you’re returning the right object. If you’re testing instance variables, it might not be necessary to test that Ruby is able to assign a value to it. However, if you’re picking values out of a Hash, a test might prompt you to think about how that impacts the class.

Three. Don’t do any ‘work’ other than assignment in the constructor. Can that work be done in a factory class beforehand? Can you shuffle methods around so that you can

Continue reading →

Getting lost

Spend five minutes searching on the Internet and you’ll find many articles talking about developer burn out, what to do when motivation drops or how to overcome road blocks in your creativity. I’ve read my fair share, mainly as an observer, never really as a participant.

What I would like to write about now, is probably much the same takeaway as that which precedes me. Just a snapshot of my state.

I’m not burned out. I’m not even tired. My motivation is about an 8, and work-wise, I’m in a good place.

Like many keen programmers, I code outside of my employment. I do this for both pleasure and learning. I start many projects, some lasting an evening, two, sometimes a week, two.

Recently, or at least the last six months, I’ve been working on a project which I’ve become desperate to finish- for no gain other than being able to put a line in the sand. During this time, I’ve branched

Continue reading →

On failing code katas

I’ve been a Ruby developer for about five years now. I’m not quite a black belt, but I’m confident with my moves and sometimes, even graceful. Recently, whilst attempting a code kata with a friend, I found myself rejecting my experience in favour of the more intuitive style to me.

It surprised me how quickly I “dropped down” into a procedural technique. Like choosing weapons in some arcade game I selected excitedly- taking the bokken instead of the object-orientated nunchaku. I had side glanced the functional sai, but my unfamiliarity with these seemed too risky against this combatant.

Code katas are not just raw bouts. Matches can be won with brute force; though this is often time consuming and energy draining. The kata is often carefully crafted to force the competitors to not only think about how to win, but also require they “feel around”, that they are experimental, and push

Continue reading →

Could do with re-reading now and again.

Do your upfront planning and sweat the details. There’s a time an place for the level of detail you discuss; at your team meetings should be high level, and with your pair should be really low level. Defer as much as you can. If you are unsure of any aspect, ask about it. Be a nag. Be thorough. Be the craftswoman or man.

Can you explain in a sentence what you are trying to achieve? How about to someone you perceive to be smarter than you? What will they think to your solution?

Be prepared to throw it away. Then throw away the next load of stuff you create too. Use version control.

Test ‘first’ to help you design the system. Test 'during’ to help you refine it. Test at the end as a sanity check. Get someone else to test it too. Accept their feedback gracefully.

You want to be the best, right? That takes training, practice, dedication and the help of others. Rely on them and give it

Continue reading →

Testing private methods

Recently, I have been thinking about my approach to unit testing with Ruby, in particular relating to private methods within a class. It is generally accepted that you should only test the public interface to a class, with these tests in-turn exercising the private methods therein.

With any class of reasonable complexity, i.e. a typical Rails model complete with obligatory business logic, I am finding that during the course of development, the refactoring process pushes the grunt-work down into the class’ private abyss.

This makes me feel uncomfortable as I think that with multiple moving parts, (i.e. changes to many methods; i.e. to the API and its supports) the chances of edge cases and unimagined side effects creeping into the system increase- inconspicuously, and lie dormant, waiting to embarrass me.

How do I tackle this? Test driven development can and should help here, but in

Continue reading →