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
String response = null;
HttpClient httpclient = new DefaultHttpClient();
HttpPost httppost = new HttpPost(webservice); // the webservice is the url of the resource
httppost.setEntity(new UrlEncodedFormEntity(params, HTTP.UTF_8)); //set parameters to post
ResponseHandler
response = httpclient.execute(httppost, responseHandler); // execute the post with the Response Handler to return the response
httpclient.getConnectionManager().shutdown(); // tear down the http client
return response;
}
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!
Inspired by a PHP version of this found here, here is a Javascript function that takes the number of the month (0-11) and the year and returns the Date object of the first Monday in that month. I find it useful for determining weeks in the month.
// get first Monday of the month, useful for determining week durations // @param - integer: month - which month // @param - integer: year - which year function firstMonday (month, year){ var d = new Date(year, month, 1, 0, 0, 0, 0) var day = 0 // check if first of the month is a Sunday, if so set date to the second if (d.getDay() == 0) { day = 2 d = d.setDate(day) d = new Date(d) } // check if first of the month is a Monday, if so return the date, otherwise get to the Monday following the first of the month else if (d.getDay() != 1) { day = 9-(d.getDay()) d = d.setDate(day) d = new Date(d) } return d }
Please let me know if you find it useful. Enjoy!
Two months into being an Innovationeer at Axeda, I ace the “waking up to work in the morning” test with flying colors. Who wouldn’t want to be at the cutting edge of technology, with knowledgeable peers and mentors actively looking out for me, working on projects that are not only competitive, but compete with entire industries?
Let me say that again – each and every application built on the Axeda Platform models an entire industry.
Axeda’s signature product, the Axeda Platform is a secure and scalable foundation to build and deploy enterprise-grade applications for connected products, both wired and wireless.
Got a vending machine? Connect it and harvest data for marketing. Own a fleet of trucks? Find out their location, speed, and maintenance history. Work in the health industry? Monitor your patients’ statistics transmitted from their mobile devices, while they check into their appointment on a kiosk that feeds your dashboard. Providing solutions as diverse as the products they connect, the Platform’s full potential is waiting to be realized.
With all this excitement, can you believe they’re still hiring? You too can witness the emergence of a connected planet, or you can be the one who makes it happen.
Contact me today if you’d like to submit a resume or drop me a line on Twitter where you can find me as @saranicole .
A brain is a lot like a computer. It will only take so many facts, and then it will go on overload and blow up.
– Erma Bombeck
One could argue that writing code can be boiled down to writing a series of AND, OR, and NOT statements. Anyone who has seen assembly language knows the fundamental commands do not vary a whole lot. So why is it that tutorials advertise “no coding necessary?”
There is an art to coding that is hard to pick up without doing the work. I learned this from my own experience of coming from a humanities background and expecting it to be like picking up a language. Learning the programming language is an important aspect, but the language has far less bearing compared to understanding the underlying technologies. It’s like needing to know how acids and bases interact before you invent a new recipe.
1. Play logic and math puzzles
If you’re not a puzzle type (I’m not), seek out opportunities to challenge that part of your brain. Puzzles will teach you an intuitive grasp of the underlying math and logic so essential to the function of computers. They will also train you to be thoughtful and persistent, qualities that will make you a successful coder in the long haul. Check out http://www.mathplayground.com/logicgames.html for a nice selection.
2. Break the task into higher level chunks
It’s tempting to start off a coding project by drilling down into the nitty gritty of how each and every function will work. Learn to leave stub functions and classes for later and focus on the overall structure first. Raise your view from the 1,000 foot level to the 10,000 foot level. See the whole, then map out finer grained sections.
3. Limit your use cases
Take on a specific type of coding when you’re beginning, such as website or app development. You will become familiar with a small spectrum of tools, and that in turn will get you started on the thought process needed to build software. By all means branch out once you’re bored, but when it’s new to you, avoid tackling Arduinos, ActionScript and APIs all at once.
How do you condition yourself to approach the ultimate coding mindset? Or is there a way to bypass the limitations of the coder?
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?
Much may be done in those little shreds and patches of time which every day produces, and which most men throw away.
- Charles Caleb Colton
With blocks on your schedule filling up, it’s easy to overlook the nuggets of time that, with proper management, allow you to recapture the value of your day.
The first question to ask is how do you want to be productive? Try mind-mapping your thoughts in order to answer this question.
Mind Mapping – a mind map is a diagram used to represent words, ideas, tasks, or other items linked to and arranged around a central key word or idea (from Wikipedia)
FreeMind – premier free mind-mapping software written in Java
MindMeister – online mind-mapping tool with real-time collaboration and mobile apps
Further discussion of the uses of mind-mapping available here
How will you keep track of the results of your efforts? Create a searchable notebook.
Searchable Notebook – whether it be a personal wiki or an emailed note to self, having a central place for your notes can boost your time management
Wikihost – a collection of public and private wikis to publish content, share thoughts and find people with similar interests.
Evernote – save your ideas, things you like, things you hear, and things you see, available as a mobile app
Further discussion about personal wikis here
Spend a lot of time commuting? Use a portable mp3 player to listen and learn.
Podcasts/Audiobooks – make use of your time by learning and reading.
Open University – iTunes provides search for free lectures via podcast at Open University
Librivox – LibriVox is a volunteer-driven provider of audiobooks from works in the public domain
A list of sources of free audiobooks may be found here
What tools do you use to get better value from your time? Or do you have enough already?
A term I hear often at work is “fire drill.” Priorities get elevated until there’s a problem and suddenly all eyes focus on it, scurrying for a solution. This surplus of effort detracts from other priorities, allowing them to inflate and erupt in a chain reaction of multi-stress. Not fun, and not efficient. Much of the energy is wasted in commotion which would be better spent re-engaging with the larger picture.
How do we go about de-escalating a fire drill? First, stop escalating. Keep control of the urge to move the issue up the chain of command. Think it through with co-workers on your management level. Second, relax, breathe, and step away for a brief amount of time. Write through the problem if it helps. Sometimes a simple break can give your mind the rest it needs to reset. Finally, consider a re-do rather than patching up what’s already there. A whole new version may seem like overkill, but piecemeal edits may gloss over the underlying glitch that created the problem in the first place.
Do you want to leave crisis mode behind? Or can a crisis improve your overall results?
What does change feel like to you? A trickle? A stream? A firehose? Is there a degree of change that is easy for everybody to deal with, beyond which it becomes a hassle, then a crisis?
When I graduated with my Bachelor’s back in 2002, I had never experienced real change. I was not prepared for that in-between transition that feels exactly like failure. For a student with debt and no job, the years of hard work in school seemed like a waste.
I lived through that transition with the support of my family and went on to find my first full time job. Years later, I changed careers and found work as a software engineer. All in all, it took me nine years to become a professional with a definite career path.
This transition would have been smoother if I had anticipated change and seen it as a normal fact of life. Then again, is it possible to understand that without going through it first? What do you think?