Tim Hardy

Drama school can be a little odd. Just watch Fame. Last year, during a particularly abstracted movement class, my wonderful teacher took us through the various colours of the rainbow. She’d shout one out and we would move accordingly, embodying the shade in whatever motions we saw fit. Blue, red, green, slowly we began to lose ourselves in the exercise, stretching like cats or undulating like charmed snakes; it’s amazing what a group of usually self-respecting twenty somethings will do when trapped in an unlit rehearsal studio. We come to yellow, incidentally my favourite colour, and as I’m in the middle of this particular hue, stretching my arms up to the sun and imploding like a daffodil, I hear a voice shout ‘No John! Yellow!!’

I Wanna Live Forever

An amusing post from an interesting blog I just stumbled across by writer, actor and magician John Vanderput.

I’ve heard Haskell mentioned a couple of times now and (having far better things to do with my time) decided to look into it briefly just now.

It’s a purely functional language as opposed to an imperative one which leads to very succinct code for certain domains. For example, a quick sort in Haskell could be written as follows:

qsort [] = []
qsort (x:xs) = qsort less ++ [x] ++ qsort more
where less = filter (<x ) xs
more = filter (>=x) xs


Definitely something I’d like to look at in more depth when I have some time. Now back to what I should have been doing in the first place.

In bash, the return value of a called program is stored in a variable called $?

grep returns zero on a succesful match, one on no match and minus one on an error. Being able to read this return value enables easy conditional branching based on pattern matching, eg:


#/!bin/bash
# Branch based on pattern matching
PATTERN=$1
FILE=$2
grep $PATTERN $FILE > /dev/null
if [ $? -eq 0 ]; then
echo $PATTERN found
echo Now do something to $FILE
else echo Skipped $FILE
fi


Sure, you could use Perl or another more sophisticated scripting language to do this but the bash shell is powerful enough for most tasks.

I’ve just spent a couple of hours trying to track down an error in some Java code I’m writing that uses generics (an area I do not know as well as I would like).

I’ve been tearing my hair out, assuming that the problem must lie in something I’ve misunderstood about the new area. The code implementing generics looked correct, but then what do I know? It’s not an area where I’m confident so I must have made some kind of idiotic, beginner’s mistake with it that I’m just not noticing. Or so I assume.

I refactored the code substantially. The bar stayed red. The same test kept breaking.

And then I found the error. A typo in the unit test itself. My code had been generating the right results all along but I had been checking the wrong thing.

When I’m confident of something and there’s an problem, I check the simplest things first. But when I’m not confident, I assume that the problem must lie in the area I don’t fully understand and dive straight into that without pause to check anything else.

I’ve fallen into this trap often enough that perhaps I should consider it a personal anti-pattern. Hopefully articulating it is the first step towards breaking it.

If you get annoyed when Eclipse alerts you about your unit tests that “This method has a constructor name”, you can set it to ignore these warnings in Window / Preferences / Java / Compiler / Error/Warnings - set “Methods with a Constructor Name” to “Ignore”.

It’s generally a bad idea to switch off warnings but in this case I think the JUnit syntax is confusing Eclipse so it’s easier to just switch them off.