Making invisible computers appear and disappear since 2014

Hackathons are short day or days-long events in which hackers prototype a technical solution to a business problem and then pitch and demo that solution to an audience. I’ve been a coach and organizer for three Hackathons and I’ve learned a few rules of thumb that make Hackathons more fun and valuable for the participants.

1) Make the device + sensors combination awesome

The target audience for the Hackathons we run are hardware hackers as well as IoT hackers, and if you get the right device – say the newest release of Arduino plus an a la carte selection of 50 sensors – their eyes light up and the creative juices start flowing. Pick the wrong device and you get to hang out with them on the couch wondering how to help them figure out what to do.

2) Code shoulder-to-shoulder with the hackers

Don’t show up and put your feet up on the table and say, “well I’m here so I’ve done my job!” No, get down and get dirty in the code, help out with code snippets and make things *work*. They’re here to turn an idea into reality and the best outcome is if the help of the coaches is available to make everyone successful. Let the best idea be implemented the best way it can and whaddya know cool things will happen.

3) Pick the right judges

Judges hold the power of the purse over the heads of the hackers. Prize money goes where the judges deem it worthy to go. For that reason you want judges who represent a few different perspectives – a business guy, a software gal, a hardware person, an investor – so the hackers have the best chance to impress at least one of them with their demo. Judges can give value to hackers simply by offering plenty of feedback, so make sure to select for experience and expertise in their area.

4) Help them with their demo

Putting a solution together is only part of the challenge of participating in a Hackathon, the other part is presenting it in an exciting and professional way. While working with hackers on the technical implementation, don’t forget to ask them if they have a slide or two on their project that explains its business value. Ask if they have a business-oriented team member and if they don’t, find them one.

Hackathons are fun and sometimes extreme events with coding going all through the day into the night and the morning. The experience alone makes it worth participating in one and who knows, you might be surprised at what you can put together!

The AT&T Hackathon in January was a blast, and my coverage of it as an M2M coach for the Arduino hardware gained some attention.

Check out the O’Reilly post at http://blog.makezine.com/2013/01/30/results-from-arduino-hackathon-at-atts-2013-developer-summit and the original at http://developer.axeda.com/community/blog/9-connected-hacks-rocked-mobile-app-space-2013

In order to create an Android app that could consume data from a web services call, I had to be able to post data to the web service.

I posted data via the DefaultHttpClient class, then parsed out the JSON-serialized response.

The code for the post was the following:

public String callServiceAsString (String webservice, ArrayList params) throws Exception {
String response = null;

}

To parse out the response, I turned the string into a JSON Array:

JSONArray jsonArray = new JSONObject(service.callServiceAsString(webservice)).getJSONArray("result"); // create a JSON Array out of a String
for (int i=0; i < jsonArray.length(); i++){ // iterate through to find the desired values JSONObject childJSONObj = jsonArray.getJSONObject(i); serial = childJSONObj.getString("patron_serial"); name = childJSONObj.getString("patron_name"); }

There you have it, posting data and reading back in data from a RESTful web resource.

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?