A Thought on Nodes within a System

Last week I gave a tech talk on the architecture of the mobile website I have been building out for the past six months.  At the end of the presentation, I was asked what the key takeaway would be.  This is a prettied up version of my answer:

"The key takeaway is to think of your running application as one node connected to a greater system, and to define your connections to all other parts of the system in configuration files (or via commmand line arguments).

"A connection could be a third party API that you pull information from (such as Twitter) or an analytics package that you include in your application (such as Google Analytics) or a database connection string or even URLs for other sites in your company's porfolio. All of these are parts of the larger system that when linked together form the service that your application provides the entry point to.

"Defining connections in configuration files makes changing and testing the system as a whole managable.  There is much to be said for being able to remove, reconnect, and replace any of the connections on application startup easily.  You gain a high level of control over overall system state.  You can test against different versions of connected services at will.  You can remove connections entirely and see if your application falls to the ground or ideally limps along boldly with determination.

"As software engineers we tend to obsess about how our functionality is coupled within code.  Extending that same obsession to the connections this application has to other parts of the greater system has made my life easier and turned this application into something of a cockroach.  I'm pretty sure that by the end of the year it will be able to survive a nuclear attack just as easily."

Stepping away from the plug-in architecture

At the start of the year I was excited to use jQuery's widget factory. Now I am wary of exposing components as jQuery plugins to the rest of a JavaScript application.

The change of heart came after I spent a day refactoring the jQuery out of an open source jQuery plugin that I found on Github. This was necessary. I was working on a mobile web application that used Underscore/Zepto and the plugin had a good amount of the functionality I was missing.

Now there is enough similarity between jQuery and Zepto that almost all of the 500 or so lines of core code stayed the same. I expect that from a well written plugin. For someone in my situation, there shouldn't have been more to it than swapping out the DOM manipulation library used to enable the component's functionality.

But I also had to refactor the interface to conform to a standard JavaScript object's pattern of instantiation and scoping. That's what makes me scared to start using the widget factory. I don't know the future. But I know that jQuery and it's plugin ecosystem are not necessarily the future in a mobile web world, and I'm not sure that I want to start presenting an interface in my JavaScript applications based on a jQuery centric world view.

At this point, I'd rather have common scoping and invocation patterns in my components, keeping jQuery as a tool used by the components rather than an API that they expose.

A Pattern for Nested Asynchronous Calls

I recently wrote an HTML5 application that loaded a large data set into the browser using nested calls to a web service. The first call loaded up information to make a set of subsequent calls, each of which in turn loaded up information to make a third set of calls.

You could point out that seems to be a lot of interdependent calls to get data. In my defense it was a third party service and I did not want to write my own server to handle data aggregation. Yes. I was being lazy. So I continued to load data in a piecemeal fashion and used the following callback pattern to provide incremental feedback on the loading process.

function loadData(stepCallback, endCallback) {
...
}

The loadData function above calls stepCallback() whenever one of the nested calls returns and endCallback() when all of the nested calls return. I used this pattern of callbacks to create a polite loading window that notifies users about what is being loaded in real time.

I may be lazy, but I do have manners.

Dating yourself

After being dissatisfied with the complexity of JavaScript date widgets, I wrote this snippet to create a natural language solution, backed by the Datejs library.  It works by parsing the text a user entered on blur. 

It's a little rough at the moment, but a few refinements could make it just as effective as some of the more complicated implementations out there.

$('input.datefield').blur(function () {
  var field = $(this);
  var date = Date.parse(field.val());
  if (date) {
    field.val(date.toString("hh:mm tt"));
  }
});

How sexy is your form?

I attended a presentation by Stephen Anderson on The Art and Science of Seductive Interactions today.  He has an approach to design that explicitly incorporates behavioral psychology and is encapsulated by a deck of cards which is generating a lot of interest in the interaction design community. 

I got a chance to talk with Stephen for a bit before and during the presentation.  He is one of the most interested (not a typo) people that I have ever met.  Anyone who can provoke me to ramble on about my workout regimen and collegiate experience must be a profoundly curious soul.  That kind of curiosity and a deck of cards will do well against any interaction design problem.

The one question left unanswered for me was whether the cards (representative of behaviors) are best utilized with specific user behaviors or whether the cards can delineate a direction for an entire application as he suggested may be possible.  I suppose I may need to attend a workshop to find out.

How clean is your form?

A secondary use for $.serialize() is altering a form's behavior if the user has updated the form since the document was loaded.  When the document is ready, the initial state of the form can be captured in a single variable that is easily compared.

$(document).ready(function() {
    var clean = $("#myform").serialize();
});

Now whenever a change event is fired on an element within the form, you can re-serialize the form and compare it to the original "clean" value to figure out if the form has been changed and update behavior if necessary.

$("#myform").delegate("input select textarea", "change", function(){
    var dirty = clean !== $("#myform").serialize();
    if (dirty) {
        enableSave();
        warnOnUnload();
    }
});

Kinda neat and a little more robust than other solutions.

How clean is your bathroom?

From Coach Glassman:

When I go into the gym and I see a dirty bathroom, what I see is that you don't give a fuck. And that's fatal. There is no amount of poverty or lack of clients that excuses a dirty bathroom... it's a symbol for something more important than the bathroom, and that is for how much you care. I can fix bad training. I can't fix that you don't care. I can't give you pride where you don't have it.

There are many things that I love about Crossfit. This talk is one of them.