Recently I was writing a “tips and tricks” blog post that was going to focus on the idea that it is better to use an object as a “string buffer”; the idea was that by passing this object around to various functions and pushing string fragments into it, you can get better performance from a JavaScript engine. My friend and colleague Alex Russell challenged me to show him hard data supporting this hypothesis—and the results were quite eye-opening!

(more…)

Many Dojo developers are aware of the Dojo Objective Harness (DOH) that the Dojo Toolkit uses for unit testing. Many people, however, want to use DOH for testing their own code or even non-Dojo code that they have written. While DOH has always supported this, there currently aren’t many examples of doing so. Let’s see if we can help that out.

Out of the box, DOH has supported custom code since the beginning. Tests can include any custom namespaces or code by easily using standard JS techniques. Coming to an understanding of how custom namespaces work with Dojo and how and when DOH loads tests will help us illustrate how you can take advantage of DOH in your own code.

(more…)

The purpose of this article is to provide a list of advanced debugging techniques that are not easily found elsewhere on the web. Using Google to search for JavaScript debugging just gives you hundreds of articles about using alerts and how Firebug works. We all worship at the altar of Firebug, but there are things that can go beyond a console.log(). The following is a list of methods that every developer should have in their toolbox.

(more…)

It’s not very often that I get to work on some software that has the potential to appeal to developers, testers, designers, and the marketing team all at once. And of course when I do get to work on something like that, it usually means there is a significant amount of pressure to get it done and done quickly. My work on dojox.analytics has been one of those rare instances when I’ve been able to work in peace on writing simple and useful code that can entertain a wide variety of use cases.

(more…)

Over the past few years designing and developing I’ve come to rely on a number of tools. Most of these are obvious like Photoshop and Firebug, however I’ve come to realize that a few tools I use aren’t as well known.

(more…)

A lot of my work involves 3rd party API integration. We have plenty of tools at our disposal: protocols like SOAP, XML-RPC, JSON-RPC, and conventions like RESTful URI schemes. You would think it’d be a no-brainer to hook services together. Not always.

I was recently writing some code that called an XML-RPC method to retrieve logging data for an external service. The method signature itself was simple (names changed to protect the, all right, for the heck of it):

log(id, start, end)

(more…)

I was never a fan of the way Dojo 0.4.x handled debugging. Sans an available console, the debugger would dump text all over the page. Dojo 0.9 no longer uses dojo.debug in favor of Firebug’s world class debugger. Because Dojo 0.4.x wrapped, extended, and essentially hid Firebug’s console, some 0.9 adopters may be even wonder what console.log is. When porting to 0.9 and doing the obligatory fishing: where did that function go, what do they call it, and is it still there?… inevitably, the first function you look for is dojo.debug, and you come across the console object in firebug.js. Dojo.firebug is a port of Firebug Lite. What this means is that if you are viewing your app on a browser without Firebug, not only will you not get runtime errors, but you’ll get a debugger… actually a console! No more messy text all over my page. Just another reason why Dojo rocks.

(more…)