Category: Uncategorized

As an Innovationeer, I seek out the interesting technological developments that can make my code more elegant. One of those developments has been jQuery’s Deferred object, implemented in jQuery 1.5 and after.

The Problem:
Imagine you’re the referee in a dumptruck race. The first one to reach the finishline and dump the trash is the winner. All the trucks line up at the startline with their payloads and you give the signal. They’re off! There’s no guarantee that Truck #1 will beat Truck #3, in fact the entire point is to see who gets there first. If you bet that you’ll get Truck #3’s trash on top of Truck #1’s at the end, you’ve got an uncertain gamble on your hands.

A series of Ajax calls are like our dumptrucks lining up for a race. There’s no guarantee when any one of them will finish, and you can’t know for certain that the payload of one will arrive before the payload of another. However, in a web application some data is bound to be useless before other data arrives. Until you can get a list of dumptruck drivers, there’s no sense in asking which driver was late to the race.

This is the concept of asynchronous requests (“a” as in “not”, “syn-chron” as in “same time”), and it gains a great boost with the jQuery Deferred object. The Deferred object is a way of telling your code to wait until another set of code has completed, without hanging up the flow of the entire operation (as it would in a synchronous request). In our race analogy, a Deferred object would be the referee making sure the prize doesn’t show up until the race has been won. A Deferred object includes a promise object which is like the race announcer, letting everyone know whether the race has been completed or is still going.

The Code:
Obtaining a promise from an Ajax call is easy, since that’s exactly what a call to $.ajax returns. Since there have been plenty of tutorials on the Deferred object (here’s one ), I’ll share what I’ve been working with specifically.

Here I create an array of two Ajax requests and wait for them to complete by using the $.when .then operator. The functions doSomething and doSomethingDifferent will not execute until both requests have come back with json and json1. Race conditions prevented.

Code on!

ro·bust·ness: the degree to which a system operates correctly in the presence of  exceptional inputs or  stressful environmental conditions.

I had the bittersweet experience of watching my app break in a demo, bitter because everyone was watching and sweet because it was a demo.  The failure resulted from my assumption that the wireless network would be dependable, which sounds silly now in retrospect.  Proper error handling would have allowed the app to fail silently instead of exiting with an exception which is what it did.  Not only that but it would have been great for me to have the app pick up where it left off when the network was restored; instead I was obliged to perform manually the task left unfinished by the premature exit.

What I should have done is break my design pre-emptively.  Tests for robustness are a priority, not a nice-to-have.  I offer a few tips based on my experience …

1. The Test Environment != Reality

This one is a doozy – don’t assume that since the app works in the test environment that it will work under the stress of real circumstances.  Try to test in the field if at all possible.

2.  Write tests with assertions you don’t expect

Testing for expected inputs isn’t what will tell you whether the app will fail.  Test for the unexpected inputs which could actually break the app.  The weirder the better.

3.  Document Everything

The more you write about your code, the more chance you will see the failed logic you missed the twenty previous times you looked at it.  Teach the technique in a blog post or a tutorial, and make sure to write readable code with comments.

How do you test for the “real world”?  Or should we let the users drive the fixes?

When I started running daily back in August 0f 2009, I was worried that I wouldn’t be able to keep up the habit.  I had tried running regularly before, but over time I would get lazy.  As a solution, I created an incentive system that kept me from petering out.

I called it Cherry Equity, and how it worked was if I ran twice in a day, once in the morning and once in the evening, I would earn two cherries the following morning.  Actual cherries,  a big bag of them.  If I did really well, I would earn an extra bonus cherry.  On the other hand, if I skipped an afternoon run, I would only get one cherry the following morning, and if I skipped a morning run, I would lose out on the whole reward.  The key to success was the fear of losing out on cumulative rewards.  If I had one cherry after every run, it wouldn’t have been as big a deal to lose the reward after one or the other.  On the other hand, losing out on a reward I had already earned was a drag.

Having come a year and a half of no longer needing cherries to keep up the habit of running, I find I would love to apply the system to writing content.  I am very sporadic when it comes to writing, but with a cumulative incentive system, it could work.  The question is what kind of incentive works well for writing, flavored pens?  I need a real content strategy, and writing twice daily could work but it will hinge on having a real reason to do it.  What’s your reason?

In the midst of upgrading my G1 Android phone using CyanogenMod.  I found a helpful tutorial video that made the upgrading process much friendlier on Lifehacker at http://lifehacker.com/5339901/get-root-access-in-android-with-one-click .  It is still showing the TMobile G1 splash screen but it hasn’t died yet ..

A little over one year later, I am looking into buying a Nexus One.  Total I’ve only spent $354 in prepaid minutes since I bought this phone, so I am happy going without a contract.

I originally attempted to write this as a comment on the New York Observer’s article on 140 Conf but my comment was repeatedly marked as spam as well as my email to the site administrator. Oh well to that.

Picture being at Jeff’s conference at one of the sessions, take Jack Dorsey’s (founder and CEO of Twitter). Jack speaks into the microphone and it expands the reach of his voice from fifteen feet to one hundred feet.

Now take Jack’s microphone and give it the power to record what he says and play it back for anyone to hear for the life of the microphone. Not good enough? Jack, say something to your friend in St. Louis, or to one in Los Angeles or London. Better yet, this microphone is two-way, so Jack’s friend in London can answer him either as a private whisper, or as an equally public broadcast, able to be heard by both friends in LA and St. Louis. How much will Jeff Pulver pay Jack to use that microphone at his conference?

Turns out this microphone is free to use and available to everyone and anyone. What a guy Jack …

When Jeff talks about the State of Now, he’s talking about the movement away from the archives such as the library or the expert and into the age of the device, that broadcasts both ways instantly and globally.

Go ahead. Speak into the mike. Anyone?