Monthly Archives: November 2013

On Dying

Poetry and Art

There’s that moment when the world stops.
First your heart
then everything else slows until you’re just looking at your hands
and every sense becomes a drone in the background.

You blink and everyone has disappeared.

For a while it stays like that.
the cup on the table moves slowly,
a little to the left a little to the right.
Sometimes its filled with ice,
each day is a Dali clock,
a finger dragged through melting plastic.

Each blink is another moment
and I realize I have only so many blinks left.
They drug me so I won’t cry out at night,
but pain or sleep I would rather be awake.

I second guess everything.
Everything is accelerating

Backbone Relational vs Backbone Associations

Programming

The challenge

We were recently looking for a way within Backbone to elegantly handle event delegation from sub-models. For example a house has many rooms, and each room has one or more desks. In this case each stage is a model which owns and should be able to monitor changes to its children. For example, a house may want to monitor if there is a change to the ‘occupied’ attribute of any desks inside it. I was tasked with comparing two plugins which solve this problem: Backbone Relational andBackbone Associations.

1. The documentation – in my humble opinion the documentation should be responsible for three things. Describing the problem, describing the solution and explaining how it wants to be used. That’s it. Skim over it, try to see which assumptions they are making but come to your own conclusions. It’s tempting to look at all the nice features but that doesn’t mean you should jump on board.

2. Source Code – Read every line, and then don’t use a plugin that you couldn’t write yourself. If it doesn’t read smoothly and you find yourself questioning their decisions than you need to back away.

3. Favor the simpler solution – Brevity is elegance. Extra features are added complexity, and you want the bare minimum that works for you. Complexity will come over time as you start adding domain logic, which is why you want your building blocks to be as concise as possible.

4. Be wary of dependency chains – This hasn’t been a problem for most plugins I’ve viewed, however it isn’t uncommon in real applications.

5. Check out the community – is this something that’s up & coming (like angularJS today) or something on the decline (mootools). How often are non-primary developers contributing and how active is the owner? The facts are easily available on Github and give you a real sense of how the plugin will stand the test of time. You don’t want to be the last person on the bus, nor do you want to be the first. *BONUS*– Send a message to the developers and see if they respond.

Okay, but what about these backbone plugins?

1. The Relational documentation follows the format of underscoreJs.
2. Equal
3. Associations was much shorter / more elegant
4. Equal
5. At this point I already made up my mind, but I did shoot a message to dhurvey on Twitter and he responded within a day. Reliable guy!

The primary selling point for me was that it was a fourth of the size of Relational. It was significantly easier to read and was more specialized (it didn’t solve problems I don’t have like many-to-one relationships). Admittedly Relational had a larger user-base and it’s community was a bit stronger, I messaged it’s owner on twitter and got a response within a day. The rest was about the same. I knew I could re-write it if I needed to whereas I didn’t think I would want to re-write relational. Finally they had the same API which makes the transition between them easy if we change our minds later.

After realizing that I had a strong preference for Associations I prepared my argument. I stated the maintenance benefits of choosing a smaller solution, and I bragged about its code legibility, but what got everyone’s attention was when I mentioned its performance benefits. Backbone Associations was nearly twice as fast for very large objects as compared to Relational.