January 2010 Chicago JavaScript Meetup: I had a great time

So I had been meaning to go to a (relatively) local JavaScript Meetup for several months, but it always seemed to be scheduled when I was on a business trip, out of town on vacation, or some other event that I needed to be at. But on January 28th, 2010 I was able to attend. The format was supposed to be a few lightning presentations (10-15 minutes) followed by a more in-depth presentation. Unfortunately the person that was supposed to give the longer presentation on MongoDB (a built for scale database that uses JSON like structures to store data) wasn't able to make it so one of the event organizers (Zishan Ahmad) stepped up and gave a quick overview from some links provided by the original presenter.

I especially liked the quick presentation done by Jason Huggins on Node.js. It wasn't a dive dive by any means, nor was it meant to be, but I had heard about Node.js a while ago, and never really took the time to look at it. I could tell that Jason was pretty excited about Node.js and because of that excitement I have since read up a bit more on it. While it is focused on being a Server side implementation of JavaScript, it can be used to perform local processing as well from its own console application. I'm thinking about finding a fun little project to explore what Node.js has to offer.

Picking out the lint, and other JavaScript handling

A while ago I stumbled across a helpful Eclipse plugin called jsLex that helps with working with JavaScript within your applications, and I thought that I should mention it in case someone comes along that is interested in work with Eclipse (and Eclipse based editors) and are doing work in JavaScript. Among the features in the current release that I've found especially interesting are:
Compress/Minify/gzip multiple JavaScript
Concatenate multiple JavaScript (with the ability to specify the order of the files)

But there are a number of other features that I haven't dug into much that could be useful, such as JavaScript Profiling which allows you auto-inject profiling code into your existing JavaScript files. As I said, I've not played with it, mainly as it's not really clear exactly how to go about adding the profile code from the docs. I know that Bob is working on adding documentation for the project so I'm sure that this will be made clearer down the road.

jsLex also includes some "Cloud" functionality, but I'm not there yet, so haven't touched that portion of it at this time, maybe in the future as it seems that a lot of folks are moving in that direction.

The beta version of the plugin also adds Linting JavaScript files with JSLint. As pat on my back, I suggested this feature to Bob Buffone (the developer of jsLex) and he saw the value in it, and was able to add it pretty quickly to jsLex as part of the beta. FWIW: the site lists 1.2.2 as the beta, but the downloaded files indicate 1.2.5 as the beat.

I did run into an issue with jsLEx linting feature when installed into Aptana Studio ( 1.2.1.020234 if it matters) where the Problems panel would randomly remove entries when an entry was double clicked in the Problems panel. Bob tells me that this is Aptana specific, and I do hope that there is a workaround found within jsLex, or an update to Aptana that stops this issue from happening, as it can be annoying when you're trying to nail down some of the issues reported by JSLint. As all things beta, I expect to have a couple of issues here and there, but overall the feature is fairly robust at this point.

I have noticed that the files I've tried linting from Adobe Spry framework will choke JSLint to the point where it will stop reporting "errors". This appears to be mostly due to the coding style the Spry library was written with, not due to functionality issues. As the JSLint site says, it may hurt your feelings, so I do hope the Spry team isn't crying now. ;-)

I had a conversation with Nate Koechley from the Yahoo YUI team when I was at Adobe MAX back in November, and he says that as part of their build process, they always run JavaScript files through JSLint. Perhaps future versions of Spry will consider making JSLint happy part of the coding for future versions of Spry. I'm not religious about JSLint, by any means, but it may be worthwhile to make the effort for Spry.

Pesudo Threading in JavaScript: Watch what you're doing

I was working on some debugging and I wanted to do some logging of some variables that were going through numerous changes. However I didn't want to be littering my code with all the debug/logging code, you just know that I'd leave some of it in and cause me to do more searching and potentially have additional errors down the road.

Anyway, I ended up using the JavaScript object watch method when working with simple values by adding the watch to the parent object. This allowed me to keep my debugging/logging code in just a couple of places. The watch method also allows you to perform data validation by intercepting changes to values.

A basic example:

// Basic logger object
function Logger(){
    this.loggedItems = [];
    this.logItem = function(itemToLog){
        this.loggedItems.push(itemToLog);
    }
    this.showLog = function(){
        alert(this.loggedItems.join('\n'));
    }
}
// Create an instance of the logger object
var myLog = new Logger();

// Basic object
function Person(){
    this.age = 0;
   
    // add watch on age property
    this.watch('age',
               function(prop, oldVal, newVal){
                   myLog.logItem('setting ' + prop + ' to ' + newVal);
     return newVal;
               }
    );
}

// Create new object
var p = new Person();
// set value
p.age = 80;
// drink from the fountain of youth
p.age = 70;
p.age = 60;
p.age = 50;
// Let's see that log
myLog.showLog();
// result:
// setting age to 80
// setting age to 70
// setting age to 60
// setting age to 50

So what this does is to react any time that age is changed. So when age is changed, a function intercepts that change and is passed three parameters, the name of the property that was watched, the old value of the property, and then the new value of the property. This function then returns the value that will be used as the value that is actually assigned to the property when it is changed. In this example, we aren't doing any validation (you know a person can't be -12 years old right?), so we could check the value and if it isn't a valid value being assigned to the property, then we can return the old value and effectively not make any change to the property.

What we are doing instead is logging the new value. This allows us to track the changes to this property as the application runs. In this simple example, we just just show the log after a couple of changes. You could expand this to more of your simple value properties.

When I'm done debugging I just pull the code from the parent objects rather than from many places within the application. Still prone to leaving in some logging code, but it seems less so than logging at every point the property is changed.

A caveat: Changes to an object or adding an element to an array aren't handled with the watch method as the "value" of the property being watched isn't changing, that is, the array contents are changing, but it's still that same array, and it's the array that is being watched, not the contents of the array, same thing with an object.

Of course there are other ways to log and may be some better ways to add the logging in that would even further limit any issues when the debugging is over, but I just wanted to get across the basic usage of the watch method.

So what's with the "pseduo threading" in the post title? Well that is basically from the processing that occurs, it steps through executing each line as it reaches it, until the assignment of the watched property, the processing then breaks off to the function passed into the watch method, does what ever processing needed, then execution picks up where it left off on the next line after the property assignment. So it's sorta "threaded" in that the other code gets executed without being directly called in the code, but it's pseduo in that it's actually executed inline.

Alright, I think that's enough rambling for now.