Reactive coding...

Today I was notified about some fubnub problems - for some reason feeds weren’t publishing, and feeds were ignoring their schedule and over publishing. This def. needed some investigation.

After a few quick tests, I narrowed the problem down to two things:

1. The Perl script that handles the scheduled posting was crashing on the first feed it was getting to…so it never updated the database to note what had been published. It was just a coincidence that the feeds were being published first.

Fixing this problem was very simple as I just needed to wrap the publish command with a eval block (Perl’s version of a try/catch block).

2. The feed was crashing when attempting to publish to a blog. The cause turned out to be that the feeds often contain no standard ASCII characters (who knows why) and the XMLRPC module I’m using didn’t handle that well.

Fixing this issue took a little more effort, but in the end it was really as simple as intelligently implementing CGI::escape. What I mean by intelligently implementing is that I had to pick the right spots in the overall process to escape the data and that itself took a little bit of reflective thinking about the overall steps a feed goes through in the system.

Now you might be wondering why I didn’t have these fixes in from the very start. I mean with very little thought you can forsee these type of problems and be proactive about avoiding them.

Well that brings me back to the title of this post…you see by default I’m much more of a reactive than proactive coder. In my defense I do try to think of potential problems when hacking things together (though it’s very hard with personal projects because I generally don’t design then build…no for my own projects I tend to build then design or at best build and design).

Really it all falls back to my overall development philosophy:

1. Make it work.
2. Make it good.
3. Make it fast.

Right now fubnub is still in phase 1. For the sake of getting things working I often knowingly leave a long list of ‘to-do’ or 'to-fix’ later issues. (and sometimes even I just overlook or miss obvious coding or logic flaws – but hey I never said I was really all that smart!)

Besides, my follow up philosophy involves being a very active reactive developer…that is, a problem isn’t a problem until it’s a problem…and once it’s a problem, it’s a BIG problem that needs to be addressed immediately (or as immediately as my schedule will allow).

I feel like I’ve stuck to that so far with fubnub…but I still have a LONG LONG way to go (trust me you don’t want to see the list of known 'to-do’ and 'to-fix’ issues I already have for fubnub)!

This post has received 39 loves.


This is the personal blog of Kevin Marshall (a.k.a Falicon) where he often digs into side projects he's working on for and other random thoughts he's got on his mind.

Kevin has a day job as CTO of Veritonic and is spending nights & weekends hacking on Share Game Tape. You can also check out some of his open source code on GitHub or connect with him on Twitter @falicon or via email at kevin at

If you have comments, thoughts, or want to respond to something you see here I would encourage you to respond via a post on your own blog (and then let me know about the link via one of the routes mentioned above).