State Of Flux

I’ve deleted a boatload of comment spam, so if I’ve deleted a ‘real’ comment, please let me know and I’ll add it back in.

I’m pumped. I’ve just arrived in Sydney from my one hour flight from Melbourne. I’ve checked in and hooked up to my $30 per day internet connection and I’m putting the finishing touches on my presentation. I haven’t spent much time in Sydney but from what I can see it is a beautiful place. Tonight there is an industry meet and greet which I look forward to downing a few brews and meeting the locals. Sounds awesome.

During the process of writing my talk it has occured to me how much there is to writing software. My talk is targeted at Web Applications, but when all said and done, the same disciplines are required for web work as they are for all other application development. I was going to talk about RedBubble and why it was cool, but it was just a bit too specific – there wasn’t going to be anything concrete to take away. I concluded that a more valuable approach would be to convey (in a compressed timeframe) the a collectin of practices that make a group successful. I assume that the hard skills (HTML, CSS, coding, design) are being worked on because they are the most obvious, but the softer skill and the management practices are the skills that are harder to learn. So, in 50 minutes, I’m going to spew forth a collection of good practices with examples with a compresensive set of references. My hope is that I pique some interest and that the motived ones in the audience will pick up the battern and Go, Go, Go!

If you are at Web Directions please come up and say hello and tell me that you’re reading my blog!

Surprisingly, we are not perfect. Shocking. Even after our testing, we sometime release code into production with errors. We try to be good boys by not just ignoring these errors but we get the system to log them and send the info to our tech mailing list. In the Rails world, the excellent Exception Notifier plugin, from the prolific Jamis Buck, makes this a breeze. If you’ve got a Rails project and your not using it, then you should. Go on, get it!

But now what? You’ve got the emails but with the constant pressure to get things done it becomes easy for everyone to just think “Oh, I’m a bit busy, I’ll let one of the other guys do it.” But they don’t, because we’re all busy. Introducing, the Exceptional Cow!

The Exceptional Cow (a Tucows squigy toy)

At our end of iteration review, like all good agile shops, we go through what’s good, what could be done better, what still puzzles us and what we are going to do next time (but details on this are for another post). We also have The Exceptional Cow™.

Whoever has the cow is responsible for triaging all incoming exceptions for that iteration. At the end of each iteration The Exceptional Cow is ceremoniously passed to the next bovine herder. As the cow herder, you have the responsibility of examining all incoming exceptions and fixing it if it is a no brainer or writing it up as a bug for someone else to fix if you don’t have the time or if someone else has a much better grasp on the issue. Quite often all exceptions for the week are attacked in the final hours before we close off the iteration as we don’t want to start new functionality at that point.

What it has done for RedbBubble is make our code more robust which means our customers have a better experience. It also makes everyone just a bit more careful and tolerant of exceptions. It is also a great way to get everyone across parts of the code base they wouldn’t normally look at including the systems side of things. The cow is our friend…

Edit: The Tucows developer blog picked up on my post – Thanks!

The Melbourne Ruby User’s Group held it’s first ever Nuby night last week. It was somewhat inspired by the RailsConf 2007 RejectConf that Marcus Crafter and I attended earlier in the year with the idea of many short talks presented by many speakings being preferred over a few ‘experts’ presenting on a wider range of issues. It also acted like a gong show – you had a hard limit of 5 minutes and when the gong went off you could imagine a walking stick wrapped around your neck pulling you off the stage. No pressure… Really…

I spoke about the animals of the Ruby world – monkey patching and duck typing. After researching my talk I realized that I only had a cursory knowledge of both topics but preparing for this talk gave me the reason to learn more. I enjoyed the experience and would highly recommend it to anyone who wants to practice their presentation skills.

A big thank you to Pete Yandell for continuing to organize the Melbourne Ruby community and to Marty Andrews for recording and editing the presentations.

You can download my talks

• Monkey Patching (Open Classes) – slides and movie
• Duck Typing – slides and movie
• Photos of the night too

Big props to Justin French also from RedBubble who presented and to Xavier Shay who didn’t present due to time constraints.

I often want to grep for a word recursively within a directory. That is easy! But quite often I know there are a bunch of directories that I can ignore. For instance, in my rails apps I don’t want to hear about subversion directories and I don’t want to search the vendor tree.

I also don’t want to look at files that are really big – they are usually log files or binaries of some sort that I just don’t care about. So I put together the monster find and grep string that works for me.

find . -path '*/.svn' -prune \
    -o -path '*/vendor' -prune \
    -o -path '*/log' -o -path '*~' -prune \
    -o \( -size -100000c -type f \) \
    -print0 | xargs -0 grep -ne "SEARCH"

Let’s break it down.

find .

start searching for files recurively, starting from the current directory

-path '*/.svn' -prune

ignore .svn directories

-o -path '*/vendor'

OR ignore the vendor directory too.

-o -path '*~'

OR ignore all the emacs backup files

-o -path '*/log' -prune

ignore the log directory

-o \( -size -100000c -type f \)

OR make sure the size is less than 100,000 characters and the type of thing is a file (not a pipe or a director or socket) – this usually gets rid of all non source files

-print0

tells find to terminate the line with a 0. Which sounds really dull, but you can’t pipe the data (get the output from ‘find’ to ‘grep’) if there is a space in the filename.

|

push the data from the command on the left to the command on the right

xargs -0

take the input from the fine command, terminated with a 0 (the print0 from find) and send it to grep.

grep -ne

search each file with a regular expression and when a match is found print the line number with the filename.

The easiest way to use this is to put it into a shell file – I’ve put it into s.sh.

My s.sh file looks like this

#!/bin/sh

if  [ ${#1} -gt 0  ]
then
    find . -path '*/.svn' -prune -o -path '*/vendor' -prune -o -path '*/log' -o -path '*~' -prune -o \( -size -100000c -type f \) -print0 | xargs -0 grep -ne  $1
else
    echo "Not enough parameters.  Usage: ./$0 searchstring"
fi

Then I make it executable by

chmod 755 s.sh

If you want to find all of the before filters you would do this

s.sh “before_filter”

and enjoy you super fast find command.