My second IBM developerWorks article is now online: Where and when to use Ajax in your applications.

It's not a very technical article, so you can read it even if you've never programmed before. I talk about the benefits of using Ajax, and point out some problem areas that need special attention so that Ajax doesn't end up ruining your web site. It's essentially a summary of my Unobtrusive Ajax book.

The article was fun to write and I hope you enjoy reading it!

The long-awaited new Code Igniter version just came out last week - check out the announcement, the download, the Change Log, and (if you're updating) the update instructions.

If you're using Subversion during development (and you really should be using some kind of version control system), you can wire it up so that your development site will be updated automatically every time you commit a file. And it's easy!

Well, it's really easy if your subversion server and development web server is the same. If it's not, it's still possible, but outside of the scope of this article. You'll also want to be familiar with the command line, shell scripting and Subversion before attempting this stuff.

The first thing is to make sure your development server is a Subversion working copy, or in other words, that you can go into the dev site folder and run "svn update" to update the site. So if you've been using "svn export" or something painful like FTP, you may need to replace the dev site with a folder created using "svn checkout".

Okay, once you can update the dev site using Subversion, all you need to do is edit or create a file called "post-commit" inside the subversion repository, inside the "hooks" folder. If you look in that folder, there will probably be a bunch of example files like "post-commit.tmpl". These are examples of what you can do. Create the post-commit file by copying over the example, like "cp post-commit.tmpl post-commit", then edit this post-commit file.

Inside that file, there will be some example code like:

/usr/lib/subversion/hook-scripts/commit-email.pl "$REPOS" "$REV" [email protected]

You'll want to remove or comment out this line and stick in your own scripting. You can put any commands in here that you want to run after each commit. For example, to update your dev site, you might have something like this:

cd /var/www/path/to/website
svn update >> /path/to/logfile

That's it!

If you run into problems and you used the logfile like in the example, you can have a look in there are see if there are any error messages. I often have problems with permissions, so you may want to change the permissions in the dev folder (eg. chmod 770 -R *).

This works really well when more than one person is working on a set of files. Instead of 7000 files like "file.html.backup_jesse_19-01-2008" you can just commit and see the changes instantly. It might seem annoying to have to commit files every time you make a change, but it's the same if not easier than uploading files over FTP every time.

JavaScript functions are variables, and this is a big difference between JavaScript and many other programming languages. It can be a bit of a paradigm shift for people new to JavaScript, but it allows for some really cool things you can't do in many other languages.

When I say functions are variables, I mean that they're treated much the same as arrays, numbers, strings and objects. That means you can do some neat things.

You can define and redefine functions as local variables:

var myFunc;

if (Math.random() < 0.5) {
    myFunc = function() {
        alert('heads');
    };
} else {
    myFunc = function() {
        alert('tails');
    };
}

myFunc(); // alerts "heads" or "tails" depending on random value

You can also pass functions as parameters to other functions, which is very useful for callback functions:

function do_something(callback_function) {
    alert('hello');

    if (callback_function) {
        callback_function();
    }
}

var my_callback = function() {
    alert('goodbye');
};

do_something(my_callback); // alerts "hello" and then "goodbye"

You can also return a function from a function:

function get_multiplier(factor) {
    return function(num) {
        return num * factor;
    };
}

var times_5 = get_multiplier(5);
var result = times_5(10);

alert(result); // alerts "50"

var six_times_two = get_multiplier(6)(2);

alert(six_times_two); // alerts "12"

You can also define "anonymous" functions without a name and even execute them:

(function(first_name, get_last_name) {
    var last_name = get_last_name();

    alert(first_name + ' ' + last_name); // alerts "Jesse Skinner";
})('Jesse', function(){ return 'Skinner'; });

Note that in order to execute an anonymous function you have to wrap it in () parentheses first.

So that's just some of the unusual stuff you can do with JavaScript. Once you get familiar with the concept, you can really start to reuse code in great new ways.

We thought this day would never come: Internet Explorer 8 now renders the "Acid2 Face" correctly in IE8 standards mode!

Apparently we can expect to see Internet Explorer 8 in at least Beta form in early 2008. According to the IE blog:

The key goal (for the Web Standards Project as well as many other groups and individuals) is interoperability. As a developer, I’d prefer to not have to write the same site multiple times for different browsers. Standards are a (critical!) means to this end, and we focus on the standards that will help actual, real-world interoperability the most.

Sounds like the IE team has finally seen the light! :)