Demand Satisfaction!

You haven’t had much to read about the development of Satisfaction, as we here on the dev side have been a bit too busy building this thing. Yesterday, an idea came to me and the resulting code is something I wanted to share. It is a melding of old ideas into something novel that I think might be helpful for some of you out there.

I find myself spending more and more time on my javascript-fu these days. I’m not alone in this regard as we live in an increasingly Ajax world; one of the consequences of this trend is that a greater burden for “correctness” is pushed onto the browser. As javascript becomes more integral to the function of the page, as opposed to just custom mouse tails for you ebay auction, the cost of building a bullet proof application gets higher. This is nothing new, javascript can be hard to get right across all browsers. With the help of libraries such as prototype, jquery, yui and the like the problems that arise from browser differences are lessened, but are not yet ignorable.

As most of you know, error reporting & logging is essential to catching all of the bugs in your application; testing is a wonderful boon, but having perfect tests that cover all scenarios is just about as likely as building an entire application bug-free on the first try. Your application need to squawk at you when it breaks for one of your users. A bug won’t get fixed unless the code monkeys know about. This is nothing new. Every environment out there has some sort of error logging mechanism. In rails you’ve got your normal logger-based mechanisms, but also wonderful tools like the exception_notification plugin (personally plug here, I wrote a plugin for rails a while back called Exceptional that lets you fine-tune how exceptions are handled in rails). In the case here at satisfaction, any error that occurs in our application that isn’t accounted for gets posted to our campfire chats. This mechanism has been wonderful, but until last night it missed a whole swath of errors that were happening in our application: the client-side javascript.

In last night’s session I hacked together a little script that posts client-side javascript bugs to the same chat room that server-side bugs get posted. Here is the meat of the code, and a screen shot of it in action:

error_occurred = function(msg, url, line, data) {
  try {
    msg = msg != undefined ? encodeURIComponent(msg) : '';
    url = url != undefined ? encodeURIComponent(url) : '';
    line = line != undefined ? encodeURIComponent(line) : '';
    data = data != undefined ? encodeURIComponent(data) : '';

    postData =  "message=" + msg;
    postData += "&url=" + url;
    postData += "&line=" + line;
    postData += "&data=" + data;

    YAHOO.util.Connect.asyncRequest('POST', '/error_reports.js', null, postData);
  } catch(e) {}
  return false;
}

window.onerror = error_occurred;

Nothing particularly fancy, it is even a bit ugly since I’m specifically avoiding calling any library code. Even still, what is posted above isn’t foolproof (namely Safari and Opera don’t support window.onerror), but I’ll elaborate on that in a followup post. Stay tuned for part two, which will be on the more technical side.