FatGeekUK

There is really nothing I can say about this….

Just, go there, go there NOW, and read.

I am quite a proponent of TDD/BDD, my framework of choice being RSPEC within Rails

But, I also understand that for people unused to TDD, the upfront investment seems daunting. So, I was very interested to be told about…

DOCTEST

This seems to be a nice light introduction into TDD. I can see that for extensive test coverage it is going to be a bit of a problem, there being no concept of fixtures etc. But I can definitely see someone adopting DOCTEST and then moving on to Unit testing or RSPEC later.

If you do not already embrace TDD, and recoil at its apparent heaviness, give doctest a look, but remember, tdd can be habit forming.

I like RSPEC, I LOVE RSPEC. But, this morning, I found a flaw in its beauty.

If you are using a lambda to verify that a block of code raises an exception it works fine.

A problem occurs if you are using a lambda like….

lambda {
… do some stuff …
}.should_not raise_error(SomeSpecificErrorClass)

to check that an error of that type is not raised.

The problem is, that the ‘raise_error’ will trap errors looking for the specific type of error you are asking for, but, in doing so, it only takes notice of the specific type of error you mention, and traps but ignores all others. So, if an expectation within the block fails, this will not be reported.

Significant problem!

I have been in the place of advocating ‘throw it away and start again’ several times. Sometimes it is required, when the code is fundamentally flawed, when the refactoring effort would be longer than the rewrite. But, I always worry.

I have never had a ‘soundbyte’ to define my worry, but now I do…

‘Warty but Battle Scarred’

Some code is ugly, horribly structured and deeply flawed, but it has the survivors advantage. It’s ‘been around’. And it is still here.

This blog post identifies my worrys perfectly.

The P.G. Wodehouse Method Of Refactoring

Wonderfully put. I will be following this guy.

A project manager, a hardware engineer, and a programmer were in a car. Coming down a hill, a tyre got a puncture, the car went out of control, and a bad crash was only narrowly averted.

• The project manager wanted everyone to help draw up a plan of how to fix the car and carry on.
• The hardware engineer wanted to change the tyre and carry on.
• The programmer wanted to go back to the top of the hill, drive down again, and see if the problem happened again.

Well, it is not often that I find something I really like.

Maybe once or twice a year, someone does something that really makes me go WOW.

Well, yesterday, I was amazed to hear of this…

PHUN:“http://www.acc.umu.se/~emilk/”

It’s a 2d physics simulator, and I am amazed at its versatility.

It’s not QUITE accurate, but its accurate ENOUGH to be fun to play with and being a coder with a little knowledge of physics I can appreciate the job this guy has done.

Have Phun.

A friend pointed me towards an interesting article.

Steveys Blog Rants

And after reviewing it, I can say I am both horrified and unsurprised.

Why?

Because I have met several people who claim they are coders, who, when actually confronted with coding work, just can’t DO it.

You ask them about linked lists, and data structures, binary chop and recursion.

They nod their head, make some reassuring NOISES.

But, when you show them some code and ask them to change something, they go blank, fumble and say they will get back to you.

Recently, I had the opportunity to reinforce the need for solid sourcecode control within any software project to a friend who was looking for a new coder (PHP).

Previously, his sourcecode control policy centred around having good backups.

Needless to say, good backups are essential, but only the first and most minor step into sourcecode control. Solid revision control and management is essential to any modern software project.

So, I was heartened to hear that upon interviewing his candidate, he said that the first thing out of the applicants mouth was a question regarding sourcecode control.

Great says I, good sign….

‘Yeah, he has written his own sourcecode control system and wants to use that. Good huh?’

WHAT?! His own?

Well, since then I have had time to mull, to digest, and reflect.

Ok, a couple of questions…

1) Is this sourcecode control system freely available and well supported by anyone but this guy?

2) What happens when he walks away from the project?

3) Is it supported by other tools in the software development stack? Capistrano etc?

4) Whats wrong with subversion that this guy thinks he needs to spend time and effort inventing his own?

All of these questions paint a picture that some bespoke sourecode control system is probably a very bad idea. In fact, there would have to be MANY factors going the other way to balance out the negative aspects of this decision.

I am a stalwart follower of the PEEPCODE screencasts.

I particularly liked the series about RSPEC.

But, in reviewing the code for it, and using the code subsequently, I found this little gem.

class Hash
  def except(*keys)
    self.reject{|k, v| keys.include?(k || k.to_sym)}
  end
end

Now, I don’t know where this code came from, but its wrong.

WRONG, WRONG WRONG…

that “keys.include?(a || b)”, I see that, and know exactly what it WANTS to do, but it does not do it.

it will NOT return true if either a or b is in the keys, it WILL return true if a is in keys or a is null and b is in keys.

to get the desired effect you would have to

‘keys.include?(a) || keys.include?(b)’

not as pretty, and my mind says that it likes the other version, but that does not stop it being WRONG.

Anyway, go to Peepcode, buy screencasts and marvel at the information density.

… it’s about GOOD.

Using Agile techniques, Rails for instance, or any of the other new frameworks popping up more quickly than mushrooms on a cowturn in a darkened room, and things like TDD, BDD, SPEC driven whatever, is NOT about writing code FASTER than previously.

Its about writing code in an acceptable timescale that is maintainable, extensible and more easily supportable.

Sure, if you develop in rails and forgo all the speccing, test script converage etc, you can write code more quickly than the guy in the next cubicle, but what about the poor bloke (possibly you) who has to support it into the future.

Writing in Rails with good test/spec coverage, and careful design, takes time. But the framework itself saves you enough time with respect to other platforms that this extra time is actually saved from other activities.

Expecting a well written RAILS development to be VASTLY quicker than using some other set of tools AND to expect it to be better quality and easier to support is wishing for your cake and eating it too.

Good code takes TIME, it takes THOUGHT.