Update (1/7/12): According to Ben Noordhuis, one of the core Node.js contributors and author of the buffertools module, you don’t really need to worry about using buffers when it comes to concatenating strings. Apparently V8 is extremely clever, so for example, a statement like a += b + c actually results in no copying whatsoever.

Andrew Maurer recently shared some test results showing how much more efficient it is to use Buffers when building strings in NodeJS. Although the value behind using buffers to concat strings was drilled into me over a decade ago while using Java, I’m embarrassed to admit it hadn’t occurred to me in my NodeJS work. I think it’s because, like most people, I picked up JavaScript a long time ago in the context of browser environment–a place where nobody really uses string buffers, and there aren’t any built-in mechanisms for doing so. With that in mind, I thought it was worth sharing this personal facepalm as reminder to others. It’s “101″ stuff that every Node developer should know.

To make things easier, I recommend using a module called buffertools (github / npm) which augments the out-of-box Buffers object and makes it super-easy to efficiently append strings (note that it was written by one of the core NodeJS deveopers). To borrow from the project’s own documentation, here’s an example:

require('buffertools');

// The next three lines are identical to doing "new Buffer('foobarbaz')"
a = new Buffer('foo');
b = new Buffer('bar');
c = a.concat(b, 'baz'); // non-standard function added by buffertools

console.log(a, b, c); // "foo bar foobarbaz"

// static variant
buffertools.concat('foo', new Buffer('bar'), 'baz');

Note that buffertools won’t work out-of-box on Windows since it uses UNIX-only native code.

Wireframe showing tree with both static and dynamically-loaded items

I recently needed to build an “admin” screen for a webapp using ExtJS 4. The wireframe called for a tree to navigate the various admin settings, including settings for individual users (something like what you see at right). To build a tree like this with ExtJS, you usually use the Ext.tree.Panel class (a.k.a., a TreePanel). Unfortunately I couldn’t find any examples of how to make a TreePanel with a mixture of both static and dynamic nodes, so figuring it out took longer than it should have. With that in mind, I thought I’d share what I learned.

A working example of the solution I came up with is shown below (if the embedded version doesn’t appear for some reason, you can open it here). Note that you can actually run the code in your browser and see the results–just click the play button. Or if you’d like to modify it, click the “+” button to copy the code into your own project on JSFiddle.

The first thing the code does is define a basic model class for user data, called UserModel:

Ext.define('demo.UserModel', {
    extend: 'Ext.data.Model',
    fields: ['id', 'name', 'profile_image_url']
});

The next thing it does is set up a TreeStore to load the UserModel instances:

var userTreeStore = Ext.create('Ext.data.TreeStore', {

    model: 'demo.UserModel',

    proxy: {
        type: 'jsonp', // Because it's a cross-domain request

        url : 'https://api.twitter.com/1/lists/members.json?owner_screen_name=Sencha&slug=sencha-team&skip_status=true',

        reader: {
            type: 'json',
            root: 'users' // The returned JSON will have array
                          // of users under a "users" property
        },

        // Don't want proxy to include these params in request
        pageParam: undefined,
        startParam: undefined,
        pageParam: undefined,
        pageParam: undefined
    },
    ...
});

Note that for this example we’ll be using Twitter as our data source for faux “users”; the UserModel fields are set up to match JSON from the Twitter API (specifically, people who are a member of the “Sencha Team” Twitter list) and we need to use a JSONP proxy to make cross-domain requests (i.e., the demo is hosted at jsfiddle.net but it’s connecting to api.twitter.com). Here’s an easy-to-read sample of what the data looks like:

The JSON user data we're getting from Twitter (edited for easier reading)

The next part requires a little more explanation. First, let’s look at the code:

var userTreeStore = Ext.create('Ext.data.TreeStore', {
    model: 'demo.UserModel',
    ...
    listeners: {

        // Each demo.UserModel instance will be automatically
        // decorated with methods/properties of Ext.data.NodeInterface
        // (i.e., a "node"). Whenever a UserModel node is appended
        // to the tree, this TreeStore will fire an "append" event.
        append: function( thisNode, newChildNode, index, eOpts ) {

            // If the node that's being appended isn't a root node, then we can
            // assume it's one of our UserModel instances that's been "dressed
            // up" as a node
            if( !newChildNode.isRoot() ) {

                // The node is a UserModel instance with NodeInterface
                // properties and methods added. We want to customize those
                // node properties  to control how it appears in the TreePanel.

                // A user "item" shouldn't be expandable in the tree
                newChildNode.set('leaf', true);

                // Use the model's "name" value as the text for each tree item
                newChildNode.set('text', newChildNode.get('name'));

                // Use the model's profile url as the icon for each tree item
                newChildNode.set('icon', newChildNode.get('profile_image_url'));
                newChildNode.set('cls', 'demo-userNode');
                newChildNode.set('iconCls', 'demo-userNodeIcon');
            }
        }
    }
});

userTreeStore.setRootNode({
    text: 'Users',
    leaf: false,
    expanded: false // If this were true, the store would load itself
                    // immediately; we do NOT want that to happen
});

This doesn’t look like a “normal” Ext.data.Store. For one thing, it has an “append” event handler that receives “nodes”–objects that have methods and properties from the Ext.data.NodeInterface class. Secondly, the store has a setRootNode() method that we’re calling with a config object for NodeInterface. What’s going on?

The important thing to understand here is that a TreeStore manages Ext.data.Model instances–just like any other Store–but it copies NodeInterface methods/properties into every model so that they can be linked together into a hierarchy (i.e., a tree). In this case, every instance of demo.UserModel now has NodeInterface properties like “leaf” and “text” (which indicate if the item should be expandable when it’s displayed in a TreePanel, and what text should be shown).

Next, understand that when we call setRootNode({...}), the TreeStore implicitly creates a generic Ext.data.Model instance for us, adds the NodeInterface method/properties, and then makes it the root node; when the UserModels are loaded, they will be added as “children” to this node. What we end up with is a TreeStore with models organized into a hierarchy, each one having properties that a TreePanel can use for displaying it:

The "userTreeStore" builds a data structure like this

The next thing the code does is create a separate TreeStore with some “static” nodes (again, using NodeInterface config properties).

var settingsTreeStore = Ext.create('Ext.data.TreeStore', {
    root: {
        expanded: true,
        children: [
            {
                text: 'Settings',
                leaf: false,
                expanded: true,
                children: [
                    {
                        text: 'System Settings',
                        leaf: true
                    },
                    {
                        text: 'Appearance',
                        leaf: true
                    }
                ]
            }
        ]
    }
});

Finally, we get the root of our userTreeStore and append it as a child to the “static” TreeStore. Then it’s just a matter of creating the TreePanel.

// Graft our userTreeStore into the settingsTreeStore. Note that the call
// to .expand() is what triggers the userTreeStore to load its data.
settingsTreeStore.getRootNode().appendChild(userTreeStore.getRootNode()).expand();

Ext.create('Ext.tree.Panel', {
    id: 'usersTreePanel',
    title: 'Admin Control Panel',
    renderTo: Ext.getBody(),
    height: 300,
    width: 300,
    store: settingsTreeStore,
    rootVisible: false
});

In other words, you can “graft” TreeStores onto other TreeStores–this is the key to creating tree panels with a mixture of different data sources and underlying Models. The prerequisite, however, is understanding the NodeInterface. Hopefully this post will help others learn how to get started with TreePanels and TreeStores more quickly.

ExtJS makes it easy to apply a template to a bunch of data (resulting in HTML output, for example). Most of the examples you’ll see show this being done with the template hard-coded as a JavaScript string. That’s fine, but what if you’d rather have your template in its own file? I recently had to do this and thought I’d share the code in case it’s helpful to anyone else.

First, here’s the usual example of a template hard-coded as a JavaScript string (click on the “Result” tab to run the code–it may take a few seconds for the output to appear):

In this case, the template is pretty small, so having it in the JavaScript isn’t too annoying. But for the sake of demonstration let’s pretend that putting in its own file makes it much easier to read/maintain. In this case, I’ve moved it to a GitHub Gist, which you can see here. To use it, we’ll modify our ExtJS code as follows:

How does this work? Every ExtJS component has the ability to remotely load and display HTML via the “loader” property, which you use to configure a Ext.ComponentLoader. The ComponentLoader lets you specify your own “renderer”–a function that handles the server response. What we’ve done is create our own “renderer” function that converts the server response–our template file–into an XTemplate. By making it a static function in our utility class, we can easily re-use it throughout the app.

This solution won’t make sense in every scenario, but if you’d prefer to keep your template in its own file and don’t mind the extra network traffic it’s a nice alternative to coding your templates as JavaScript strings.

An example of a wireframe made with Balsamiq Mockups

I’ve been using Balsamiq Mockups to make wireframes for my current project and it’s been great. There are a lot of tools for doing this kind of thing, and I’ve tried several of them (OmniGraffle, Visio, plain old Illustrator, etc.). It’s not perfect, but I’ve had a better experience with Mockups than anything else I’ve tried so far. Some perks:

• at USD$80, it’s pretty affordable.
• all the drawings have a deliberately “lo-fi” look. this helps keep you (and your client) focused on wireframing the ideas and not getting bogged down in nitty-gritty design stuff
• the library of pre-built widgets is fantastic and pretty easy to configure. there’s also a website where you can download additional widgets that people have made.
• the quick-search bar is fantastic for adding widgets quickly; hit the “/” key, type a few letters to select a widget, hit enter, and ZAP! the widget you want is added. much faster than using a mouse to find the widget you want and drag it on screen.
• you can insert drawings from other files into your current mockup; changes to those drawings will show up in your mockup, too.
• if you need to “override” a drawing that you’ve linked to, no problem. you can make one-off changes to that symbol without affecting the original.
• you can make a collection of your own widgets that show up in a library for your current project, or across all projects.

Those last three points are huge. For example, I’ve downloaded a few standard widgets that I want available all the time (Mockups calls these “Account Assets”). But I also have the ability to see a library of widgets just for one client or project (Mockups calls these “Project Assets”). I can re-use any of those widgets and if I change the original file those changes are reflected everywhere else–this is a boon to anyone who has copy-pasted widgets around only to find themselves re-copy-pasting changes to that widget later. Lastly, if you reuse a widget somewhere but need to tweak it a bit for that one usage, you can do so without affecting the original. Awesome.

There is a small learning curve when it comes to figuring out how to work with groups, assets, and editing an original widget that you’ve linked to vs overriding it, but after a couple of hours of poking around and watching some of the video tutorials you’re pretty much ready to go. Also, it runs on Adobe Air which might explain while it’s a little less-than-snappy with some operations like switching between files. But on the upside, you can run it on almost every platform. And although there may be times when you crave a more traditional “drawing” app if you need to mock up a really complicated/custom widget, you can usually find a way to get the job done in Mockups.

In summary, it’s not perfect but it’s probably the best wireframing tool I’ve used so far.

I’m loving the new “class loader” mechanism that comes with ExtJS 4. That said, you’ve got to do a little extra configuration work if you have namespaces in difference directories–thought I’d share a quick example in case it’s helpful to anyone else. In this scenario, the ExtJS libraries are in one directory, the ‘myapp’ classes are in another, and ‘myapp.common’ (e.g., a shared library) classes live in yet a third directory.

I recently did some work on a large web application that had several .js and .css files. Per industry best practice, I wanted to use something like YUI Compressor or Google Closure Compiler to merge and minify all the JavaScript and CSS into a single .js file and a single .css file. Also, I wanted an easy way to switch from these optimized files–which are hard to read–to the original files during development (or to debug an issue in production).

In this case, the JS/CSS needed to be minified at build-time. The project was built via Maven, so it made sense to do this with a Maven project. After a lot of research, I chose a plugin called wro4j because it allows you to use an external XML file to configure exactly which files should be minified/optimized. And by making this XML file part of the website itself, you can use the information it contains (i.e., the list of individuals .js and .css files) to dynamically switch from the compressed files to the “raw” ones. The main benefit? The list of .js and .css files exists in only one place–the XML config file. Here’s what it looks like:

 
   
   /css/reset.css
   /css/master.css
   /css/typography.css

   
   /js/lib/swfaddress/swfaddress.js
   /js/constants.js
   /js/util.js
   ...
 

As I said, this configuration is used by the wro4j plugin when it minifies/compresses/optimizes the code at build-time. I won’t go into the details of how to configure wro4j here; see the wro4j website for info on that.

So assuming you have wro4j configured to generate myapp-all-compressed.js and myapp-all-compressed.css, the next thing you’ll do is modify your HTML doc to use those files:

<html>
  <head>
    <link rel="stylesheet" type="text/css" href="myapp-all-compressed.css"/>
    <script type="text/javascript" src="myapp-all-compressed.js"></script>
  </head>
  ...
</html>

So how can we easily switch from these hard-to-read files to the “original” files? We’ll use JavaScript to download the aforementioned XML config file (resources.xml), parse it, and dynamically add <script> tags for each .js and .css file. But first, we’ll modify our HTML template (in this case, a JSP page) to check for a URL parameter and use our “dynamic script loader” instead of the production files:

<html>
  <head>
  <% if( request.getParameter("debug") != null ) { %>
    <%-- DEBUG MODE: Dynamically load individual .js/.css files --%>
    <script type="text/javascript" src="loadIndividualJsCssFiles.js"></script>
    <script type="text/javascript">
    myapp.util.loadIndividualJsCssFiles('resources.xml');
    </script>
  <% } else { %>
    <%-- PRODUCTION MODE --%>
    <link rel="stylesheet" type="text/css" href="myapp-all-compressed.css"/>
    <script type="text/javascript" src="myapp-all-compressed.js"></script>
  </head>
  ...
</html>

As you can see, navigating to http://yoursite.com/ results in the “optimized for production” files being used, but something like http://yoursite.com/?debug causes the browser to instead download loadIndividualJsCssFiles.js and call myapp.util.loadIndividualJsCssFiles() with the path to resources.xml.

Finally, let’s take a look inside loadIndividualJsCssFiles.js. At a high level, it extracts the list of .js/.css files from resources.xml and dynamically adds <script> and <link> nodes to the browser’s DOM for each JavaScript and CSS file. Note: it’s easiest to start at the bottom and read up.

if( myapp === undefined ) { myapp = {}; }
if( myapp.util === undefined) { myapp.util = {}; }

/**
 * Use this function to dynamically load a single CSS file.
 *
 * @param {String} path - URL path to the .css file that should be loaded
 */
myapp.util.loadStylesheetFile = function(path) {
 var linkElement = document.createElement('link');
 linkElement.setAttribute("type", "text/css");
 linkElement.setAttribute("rel", "stylesheet");
 linkElement.setAttribute("href", path);

 // Append the new <link> element to the end of <head>. The browser should
 // start downloading it immediately.
 myapp.console.info('Loading '+ path);
 document.getElementsByTagName("head")[0].appendChild(linkElement);
};

/**
 * Use this function to dynamically load a single JavaScript file.
 *
 * @param {String} path - URL path to the .js file that should be loaded
 * @param {Object} callbackFcn - (optional) A function that will be called if/when the script finishes loading
 */
myapp.util.loadJavaScriptFile = function(path, callbackFcn) {
 var elementOnLoadFcn,
     scriptElement = document.createElement('script');

 scriptElement.setAttribute("type", "text/javascript");

 if( callbackFcn != undefined && callbackFcn != null ) {
   // Create a function that will be used as the value for the <script>
   // element's "onLoad" and "onreadystatechange" attributes.
   elementOnLoadFcn = function() {
     // This function can work for both 'onlload' and 'onreadystatechange' events
     // Note: When this code is run 'this' will refer to the <script> object.
     if ( this.readyState && this.readyState != "complete" && this.readyState != "loaded" ) {
       return;
     }
     this.onload = this.onreadystatechange = null; // ensure callback is only called once

     // Execute callback that indicates the script was loaded
     callbackFcn(this.src);
   };

   // Configure the <script> element's onload and onreadystatechange attributes
   scriptElement.onload = elementOnLoadFcn;
   scriptElement.onreadystatechange = elementOnLoadFcn;
 }

 scriptElement.setAttribute("src", path);

 // Append the new <script> element to the end of <head>. The browser should
 // start downloading it immediately; when finished, the elementOnLoadFcn
 // function (if it exists) will run.
 myapp.console.info('Loading '+ path);
 document.getElementsByTagName("head")[0].appendChild(scriptElement)
};

/**
 * Use this function to dynamically load multiple JavaScript files.
 *
 * @param {Array} filePathsArr - Array of URL paths to the .js files that should be loaded
 */
myapp.util.loadJavaScriptFiles = function(filePathsArr) {
 var jsFileIndex = 0,
     loadNextScriptFcn = function() {
       if (jsFileIndex < filePathsArr.length) {
         myapp.util.loadJavaScriptFile(filePathsArr[ jsFileIndex++ ], loadNextScriptFcn);
       }
     };

 loadNextScriptFcn();
};

/**
 * Use this function to dynamically load a single JavaScript file.
 *
 * @param {String} path - Path to a wro4j resources XML file.
 */
myapp.util.loadIndividualJsCssFiles = function(wro4jResourcesFile) {
 // JS best practice: declare vars at start of fcn (for more info, search "javascript hoisting")
 var i,
     cssNodesArr,
     jsNodesArr,
     nodesArrLength,
     request,
     jsFilePathsArr = [],
     resourcesDoc;

 // Get the XML file which has the list of all individual .js and .css files
 // used by the front-end.
 if (window.XMLHttpRequest) { // IE7+, Firefox, Chrome, Opera, Safari
   request = new XMLHttpRequest();
 } else { // IE5, IE6
   request = new ActiveXObject("Microsoft.XMLHTTP");
 }

 request.open("GET", wro4jResourcesFile, false);
 request.send();
 resourcesDoc = request.responseXML;

 // Load all stylesheet files specified by <css> elements in resources file
 cssNodesArr = resourcesDoc.getElementsByTagName("css");
 nodesArrLength = cssNodesArr.length; // Best practice: iterate HTMLCollection by caching array length
 for(i = 0; i < nodesArrLength; i++) {
   myapp.util.loadStylesheetFile( cssNodesArr[i].childNodes[0].nodeValue );
 }

 // Load all JavaScript files specified by <js> elements in resources file
 jsNodesArr = resourcesDoc.getElementsByTagName("js");
 nodesArrLength = jsNodesArr.length; // Best practice: cache HTMLCollection length instead of re-calculating for each iteration
 jsFilePathsArr = new Array();
 for(i = 0; i < nodesArrLength; i++) {
   jsFilePathsArr.push( jsNodesArr[i].childNodes[0].nodeValue );
 }

 myapp.util.loadJavaScriptFiles( jsFilePathsArr );
};

The end result is that you keep the list of .js/.css files in one place (resources.xml)–you don’t have to keep updating your .jsp or pom.xml file each time you need to add or remove .js/.css files. The loadJavaScriptFiles() function will ensure those files get picked up the next time you refresh the browser with the ‘debug’ URL param, and wro4j will similarly include those files in myapp-all-compressed.js/myapp-all-compressed.css the next time a build is done.

In the primordial days of the web, debugging JavaScript often meant using the alert() function to print information about what your code was doing. Thankfully we now have debuggers and, for developers who prefer logging, the console object which offers functions like console.log().

There’s a catch with the console object, however: it doesn’t always exist. More specifically, most browsers don’t provide a console object by default (Chrome being one exception). You usually need some kind of developer tool or extension running to provide a console object—Firebug or the ‘Developer Tools’ add-on for IE, for example. And without a console object, calls like console.log() result in a “console is not defined” error.

I came up with a solution to this on a recent project (although I highly doubt I was the first to do so). It basically involves creating a “dummy” console object that will be used if the real thing doesn’t exist, which prevents “undefined” errors. With the flip of a switch, however, you can “turn on” logging and start using the actual console if it exists.

It’s pretty simple to use. First, make sure the following gets run before any code tries to call the console functions:

// Create object that will be used for 'myapp' namespace if it doesn't already exist.
if( myapp === undefined ) {
    var myapp = {};
}

// Create an object with functions that mimic the window.console object made
// available by tools like Firebug or the "Dev Tools" add-on in IE8+
myapp.dummyConsole = {
    assert : function(){},
    log : function(){},
    warn : function(){},
    error : function(){},
    debug : function(){},
    dir : function(){},
    info : function(){}
};

// Throughout our app we'll make console/logging calls by using the myapp.console
// object. Example: myapp.console.debug("blerg!"). By default, the myapp.console
// object should use the "dummy" console that doesn't do anything.
myapp.console = myapp.dummyConsole;

// This function can be used to switch the myapp.console variable to use the
// real window.console object. Note that it does a safety check to ensure that
// window.console actually exists (it won't in browsers not running Firebug or
// the IE dev tools).
myapp.enableConsoleOutput = function(enable) {
    // Don't enable the console unless it actually exists
    if (enable && window.console !== undefined) {
        myapp.console = window.console;
    } else {
        myapp.console = myapp.dummyConsole;
    }
};

I like putting this in a file called console.js and making sure it appears in one of the first <script> elements, for example. Next, instead of using the console object directly, modify your code to use myapp.console:

myapp.console.info(“my cat’s breath smells like cat food”);
myapp.console.warn(“danger will robinson!”);

You can leave these logger statements in your code without worrying about them causing errors. To “enable logging” (i.e., swap the fake console object with the real one if it exists), call:

myapp.enableConsoleOutput(true);

This gives you the ability to dynamically turn logging on/off. You could, for example, execute the statement in the Firebug console. Another approach would be to hard-code it in your HTML doc:

<script type="text/javascript" src="console.js"></script>
<script type="text/javascript">
    myapp.enableConsoleOutput(true);
</script>

Lastly, if your HTML doc is generated dynamically (e.g., JSP, PHP, etc.) you could add some server-side logic that only writes this statement if a special “enable logging” flag exists in the URL parameters. I usually take this approach because it allows you to A) see any logging statements that execute during the page’s “startup” phase (i.e., before you have had time to run the statement in the Firebug console) and B) still gives you the option of running Firebug with logging disabled.

Image courtesy of InAppSettingsKit.com

I recently came across an extremely handy open source API for managing settings in iPhone apps. In a nutshell, InAppSettingsKit looks and works just like the normal settings/preferences mechanism (e.g., Settings.bundle), except that it allows you to easily display a settings view in your app in addition to the standard Settings.app (there are a few other perks, too).

In addition to their website, you can listen to a great interview with one of the creators from via the “mac developer network” website.

Update (8/19/10): It’s come to my attention that using delegates as the primary example below was not a good idea. When you have a @property for a delegate, the best practice is to use assign, not retain, so that you avoid a so-called “retain loop” and accompanying memory leaks (more info). That said, the idea of extending the NSObject protocol so that you can call release without warnings is still helpful in some situations–just not those involving delegates.

It’s pretty common to use custom Objective-C protocols in iPhone development, especially when it comes to using delegates to keep your code modular. Consider the following example:

@protocol EngineDelegate
{
    -(void) goFaster;
    -(void) goSlower;
}

@interface Automobile : NSObject
{
    id<EngineDelegate> engineDelegate;
}
@property (nonatomic, assign) id<EngineDelegate> engineDelegate;

This shows an Automobile class that has a single member variable/property, an “engine delegate” (i.e., the Automobile will delegate requests to go faster/slower to the EngineDelegate). Because engineDelegate is declared using the generic pointer “id” type, you can assign ANY object to it as long as that object implements the EngineDelegate protocol (i.e., has -goFaster and -goSlower methods). But what happens if you try to release the delegate? For example:

@implementation Automobile
...
- (void) dealloc
{
    [engineDelegate release];
}
@end

The compiler will generate a “-release not found” warning because it can’t tell if engineRelease implements the -release method. This is problematic not just because of the warning, but more importantly, because it prevents you from doing normal retain/release operations that are common in a managed memory environment like the iPhone. In other words, how are you supposed to ensure that the delegate is properly released?

I recently came across a clever solution to this dilemma on MobileOrchard. In a nutshell, the post suggests declaring protocols as inheriting from the NSObject protocol which, in turns, defines the retain and release methods. A lot of developers might be surprised to learn that you can do such a thing (I certainly was). Here’s what it looks like:

@protocol EngineDelegate <NSObject>
{
    -(void) goFaster;
    -(void) goSlower;
}

Now the Automobile class can safely assume that the delegate will implement the -retain and -release methods (and in most cases, the delegate will inherit the methods from the NSObject*). It’s nice that we can get rid of compiler warnings in this way, but it’s more important that we can use normal retain/release methods for memory management and not worry about whether or not the memory used by the delegate is freed.

*Note that not all objects extend the NSObject class (although for most folks, this is pretty rare). For example, many classes related to Cocoa’s “distributed object” mechanism descent from NSProxy instead of NSObject.