End Of An Era

- 2012-01-12 15:30:00

I remember watching Steve Jobs' commencement speech for the first time and being fairly touched by the three stories he told in it. The major one that resonated with me at the time, and has since made more sense to me, is the first story he tells about joining the dots later on when you're looking backwards. To quote from it:

Of course, it was impossible to connect the dots looking forward when I was in college. But it was very very clear looking backwards ten years later. Again, you can't connect the dots looking forward, you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.

It made me think back to a time when I was a teenager and someone far older and wiser than me told me one way to think about the future and how what we do today affects where we end up. He described it as holding a piece of string in your hand, with the other end dangling free. The end of the string not attached to you is the future, and where you're holding it is the present. As you do things in life your hand moves around, flicking the string around and amplifying the movements of the present in the future.

I think what he was trying to impart by telling me that story was to be careful not to do anything too extravagant in the present (like get expelled from school for instance), so as not to affect the future too much. Which I never really took on board at the time, but now I look back at the dots of my (some would say) rather short life so far, and connect them to see how some things influenced other things and how everything works out in the end. But that sometimes you need to push yourself or do something unexpected to get there.

Looking Backwards to go Forward

When I look back over the last few years of my life, I find the dots quite amazing to connect. First there was BarCamp Sheffield 2007 where I met Dom, and there was Twitter and BarCamp Manchester & Leeds where I met geeks like Rahoul, John and Jeremy both online and offline. And then in June 2008 I moved to Leeds, sharing a house with Dom and quite quickly ended up being hired into what was basically my dream first job at Brightbox.

And that's where I've been working for the last 1198 days, having far too much fun, solving weird, wonderful and sometimes downright frustrating problems, all with fantastically awesome and hilarious colleagues. And working on a massive variety of things, from tiny utilities to the newly launched Cloud Platform.

And today I flick my wrist ever so slightly more than normal by leaving Brightbox, without really knowing where the future end of the string will eventually end up, but knowing that I'll look back in a few years and see dots connected that I can't imagine today. I truly don't think I could have had a better job to start off as a professional geek, and especially want to thank John and Jeremy for hiring me and helping me start my career in the best way possible.

As for my next challenge, I'm solving interesting problems in the online advertising world with Cristiano, Dom, Melinda and Rahoul. And we're bloody amazing together. :-)

Nighttime Horrors

- 2012-01-10 10:51:03

Screaming ghouls and scary monsters,
Permeating our subconscious,
At night they roam freely through our dreams,
With the sole intent of causing our screams,
Scaring us until we awake,
Annoyingly, for we know they are fake.

Defining Ruby Superclasses On The Fly

- 2011-12-18 01:13:14

Any rubyist that's defined a class should understand the following class definition:

class Foo < Object
end

It creates a new Constant (Foo) that is a subclass of Object. Pretty straightforward. But what you might not know is that ruby executes each line it reads in as it reads them. So we could do the following to show that:

class Foo < Object
  puts "we just defined object!"
end

And get the following output when we run that file:

# >> we just defined object!

So.. we know ruby is executing things on the fly whilst defining classes for us. How can we use this for profit and shenanigans?! (Err, use this for vanquishing evil and creating readable code I mean. Honest.)

How about if we've got a couple of opinionated people who like to think they've got the biggest ego in the interpreter? The last one to be loaded likes to have any new people ushered into the interpreter to be a subclass of themselves. Lets abuse a global for storing it in, and use a method to choose that on the fly when creating a new class.

def current_awkward_bugger
  $awkward_bugger
end

class Simon; end
$awkward_bugger = Simon

class Fred < current_awkward_bugger()
end
Fred.superclass # => Simon

class Harold; end
$awkward_bugger = Harold

class John < current_awkward_bugger()
end
John.superclass # => Harold

Okay, so that looks a bit different to normally defined classes. We create Simon, assign him to the awkward bugger global then create Fred, who subclasses the return value of the current_awkward_bugger method which happens to be Simon currently. Then Harold muscles his way into the interpreter and decides he's going to be the current awkward bugger, so poor John gets to subclass Harold even though he's defined in the same way as Fred.

On a somewhat related note there's a lovely method called const_missing that gets invoked when you call a Constant in ruby that isn't defined. (Much like method_missing if you're familiar with that.) Means you can do even more shenanigans with non-existent superclasses for classes you're defining.

class Simon; end
class Harold; end

class Object
  def self.const_missing konstant
    [Simon, Harold].shuffle.first
  end
end

class Fred < ArrogantBastard
end
Fred.superclass # => Simon

class Albert < ArrogantBastard
end
Albert.superclass # => Harold

So here we're choosing from Simon and Harold on the fly each time a missing constant is referenced (in this case the aptly named ArrogantBastard constant.) If you run this code yourself you'll see the superclasses change on each run according to what your computer picks that time.

Magic Bubble

- 2011-12-06 22:03:46

You and me,
Quietly,
Watching the rain in the stars,
From a bubble near Mars.

Experimental Procrastination

- 2011-11-07 00:41:49

A while ago I read a blog post that Elizabeth N wrote, on the value of writing self-serving code. Ever since I've been moderately aware of when I've written self-serving code, usually either at hackdays, or just little projects where I'm either experimenting with something or just bashing out a new idea.

In fact, I even wrote about one of my recent "self-serving" projects I bashed out in an evening, TweetSavr. It has no tests, was written moderately quickly and not refactored immensely (here's hoping the git history backs me up on that! I certainly didn't knowingly majorly refactor it at any point at least.) But it "scratched an itch" and solved the problem I had, and it works for the limited use case I need it to, so it's a success as far as I'm concerned.

More recently a friend remarked to me in a private conversation that everyone needs to procrastinate occasionally, to save them going "stir crazy". Whilst I agree with what she said, everyone needs to switch gears and do something that perhaps you shouldn't, or that won't directly contribute to completing your current task, I couldn't help but draw a link between procrastinating and writing self-serving code.

Now I'm a programmer, it's what I did for a hobby through school, it's what I leapt into a career doing when I was offered the chance and even when I've had a particularly exhausting week, it's something I'll eventually turn back to. But I realised that often when I procrastinate, I do so by writing self-serving code. My creative output or process if you will is to create things digitally on the computer, be that a web app, hacky script to let me do something I'm not supposed to be able to with someone else's application, just dicking around or exploring whatever tidbit of interesting info/behaviour in a language or library someone's just shared on IRC.

Aside: I've often joked (semi-seriously) that if/when I have enough cash in the bank to not have to actually have a "day job", I'll just spend all day building the random ideas that get tossed out on IRC instead. Quite often the smaller things I code up anyway already of an evening and they end up in my gists.

Now it's unhealthy and counter-productive to want to program 24/7, at least in the long term. (Doing the odd 24 hour hackday event here and there can mean winning fun prizes to play with however.) And sometimes all that you need to do to solve a problem you've been butting your head against for the last couple of hours is to get off the damn computer. (I usually find taking a shower makes my subconscious reveal the answer it's been quietly computing and hey presto, I know how to solve the problem properly!) At other times it just requires changing gears and flexing a different part of your brain muscle. Like say, writing self-serving code. And procrastinating by doing so.

I'm not entirely sure what the point of this thought process is, or if there can really be a point to it, but it really intrigued me drawing a link between procrastinating and writing self-serving code. I can imagine other creatively minded people might do much the same thing, an artist just sketching for the sake of sketching, or a writer taking a couple of hours off from her next novel to write a short story for her blog. (That last one is actually something a friend's done, go read her short stories, they're quite good. Start from the bottom though.)

And of course sometimes you just need to vegetate and read facebook (or twitter), but constructive procrastination does serve a real purpose I think, and can be quite useful as well.