Nominations are available in the following categories:

• Open Source CMS Award
• Hall of Fame CMS
• Most Promising Open Source Project
• Open Source E-commerce Applications
• Open Source JavaScript Libraries
• Open Source Graphics Software

You don’t have to vote in all categories; this year, I’ll be voting in three:

Open Source CMS Award

For this award, I’ll be voting for CMS Made Simple.

At work we use a variety of CMS depending on the client’s needs, amongst them Joomla!, Drupal and CMS Made Simple. CMSMS has an extremely smooth learning curve; we’ve seen time and time again that even the least technical people can use it with ease. We have never needed to give anyone a second training session on CMSMS! (If only we could say the same about Joomla! )

Most Promising Open Source Project

I’ll be voting for node.js for this one. We’re starting to see some really exciting and interesting demonstrations of the power of this framework, and I’ll be keenly watching its development.

Open Source JavaScript Libraries

I have to vote for jQuery for this one. It’s no exaggeration to say that jQuery has transformed the web; it has certainly transformed the way I write JavaScript, and it makes my life easier on a day to day basis.

These days I’m enjoying MooTools more and more, and I intend to use it for as many projects as I can, but I’m not quite there with it yet.

Feel free to share your votes in the comments!

One of the major changes to Django 1.2 was the automatic switching-on of CSRF protection. I ran into some problems today, hitting the following error.

Forbidden (403)
CSRF verification failed. Request aborted.

Thirdly, the Django site in question was a relatively small, internal, non-client facing site.

With all that in mind, I took the decision to turn off Django’s CSRF protection.  I had to dig a bit to find this information, so hopefully it helps someone else.

You probably shouldn’t do this: CSRF protection is a good thing!

Implementing the following as middleware will do the trick.

class disableCSRF:
    def process_request(self, request):
        setattr(request, '_dont_enforce_csrf_checks', True)
        return None

Lately I’ve been getting an awful lot of requests for ‘Web 2.0′ features. I’ve always hated the term for a number of reasons.

Web 2.0 was supposed to mark a paradigm shift in the way web sites operated. It promised interactivity and community in an age where sites were static. While we certainly see more of that these days, you also have to remember that these philosophies have been central to the web for many, many years. Amazon was founded in 1994 and Ebay in 1995, and both sites heavily featured user-generated content, even in the early days. In fact Tim Berners Lee described Web 2.0 as:

…people to people. But that was what the Web was supposed to be all along.

Certainly, there’s a look and feel associated with Web 2.0, largely dictated by emerging technologies and limitations of the day. Some of the most representative Web 2.0 technologies, Javascript (created in 1995) and AJAX (1999) have been around for over a decade now. In Interweb years, that’s an age! In fact, a lot of what was erroneously described as AJAX was simply good ol’ fashioned DHTML, re-packaged and re-branded for a new audience.

My biggest beef with Web 2.0 is that it’s frequently used as just another point on the checklist of requests, without any thought as to what such features actually are, or whether they’re appropriate for the site and audience. As in, “we need the site to be usable, accessible and Web 2.0″. As such, the term is completely meaningless! Much better to find out from your users what features they actually need, and go from there.

I’ve even been asked if I can “do” Web 2.0. I usually answer that any features are possible given the right budget. Whether or not you want to give them a label of Web 2.0 is up to you!

I guess the take home message for this article is exactly as the title of this article says: stop paying lip service to a marketing term, find out what your users really need, and implement it.

In ‘Anonymous Functions with FireUnit‘, I looked at one quick way of doing some  unit testing within FireUnit. Here’s a slightly more robust pattern. In a seperate javascript file, you could do something like this:

var tests = {
    testOk: function(){
        fireunit.ok(1==1, 'This test will pass');
    },
    testCompare: function(){
        var numChildren = $('#myDiv').children('p');
        fireunit.compare(numChildren, 4, '#myDiv should have 4 child paragraphs');
    }
};

main = function(){
    if(typeof fireunit === 'object'){
        for(var test in tests){
            tests[test]();
        }
        fireunit.testDone();
    }
}();

Now, any test functions you add to the tests object will be run when the main function is called (in this case, straight away.)

Simply include this JavaScript file when you want to run your tests, and comment it out or remove it in production.

Last night, I was doing some code kata at codingbat.com when I was presented with the following problem:

Given a string and a non-negative int n,
we'll say that the front of the string is the
first 3 chars, or whatever is there
if the string is less than length 3.
Return n copies of the front;

front_times('Chocolate', 2) → 'ChoCho'
front_times('Chocolate', 3) → 'ChoChoCho'
front_times('Abc', 3) → 'AbcAbcAbc'

def front_times(str, n):
  front_len = 3
  if front_len > len(str):
    front_len = len(str)
  front = str[:front_len]

  result = ""
  for i in range(n):
    result = result + front
  return result

def front_times(str, n):
   return n*(''.join([x for x in list(str[:3])]))

Did it make me smile? Hell yes. Although ultimately, the most pythonic is probably:

def front_times(str, n):
   return n*(str[:3])

Packt Publishing were kind enough to send me a copy of the jQuery 1.4 Reference Guide, by Jonathan Chaffer and Karl Swedberg. The book is intended to be a comprehensive reference for the library, aimed at intermediate to advanced readers.

The first point I should make about this book is that it is not intended for users who are new to the jQuery library – this is not a book full of tutorials. If that’s what you’re looking for, you should check out Learning jQuery 1.3 instead, by the same authors.

The book is organised into eleven chapters, covering (amongst other things) selectors, DOM traversal and manipulation, events, effects, and AJAX. The whole library is covered (as you would expect from a reference guide).

Each method in the library has its parameters documented. This is surprisingly helpful – many jQuery methods can be overloaded for various purposes, and this feature of the book is a great help towards learning the possibilities of each method. In fact, one of the take-home points for me was that many methods now support anonymous functions as parameters, offering lots of flexibility.

Next, a bare bones code sample is shown to demonstrate the method. It is followed  by an explanation of the code sample, along with any ‘gotchas’ or quirks that you might experience. Multiple examples of code are shown where there might be different ways to use a particular method. The book really is quite exhaustive, and from that point of view offers great value for money.

Although this book works really well as a reference book, the surprise for me was that it didn’t just work well as a reference book. Reading through the book, I picked up a lot of hints and tips that will almost certainly change how I use jQuery. For example, I realised that my knowledge of selectors was sorely lacking. (Partly this was because I’d never bothered to learn the CSS3 selectors properly, but jQuery gives me a reason!)

Another excellent chapter for me was the last one, regarding plug in architecture. The structure of this chapter was a little different, basically walking the reader through the process of creating various types of plugin. Like the best technical books, this chapter actually inspired me to put the book down and write some code – surely a sign that it was doing its job properly!

It’s worthwhile to note that if you are considering purchasing a copy of this book, Packt will make a contribution to the jQuery project for every copy sold; so in buying this book, you’ll increase your own knowledge, and you’ll be directly helping the jQuery project too. For me, that’s one of the best reasons to buy.

FireUnit makes it quick and easy to write unit tests in JavaScript, doing something like the following:

fireunit.ok(foo==bar, 'foo should equal bar');

fireunit.ok(function(){
    var myList = $('ul');
    var originalLen = myList.children('li').length;
    fireunit.click( myList );
    return $(myList).children() == originalLen + 1;
}(), 'This test should return true');

1. Make sure that you include the extra parentheses after the function definition; this executes the function straight away
2. Make sure you  return true or false  from the function (or an expression that evaluates to true or false.)

I’ve just finished reading Pro JavaScript Techniques by John Resig, and I thought I’d post some thoughts about it.

The author, John Resig, is the creator of the popular jQuery library. He also works as a Javascript evangelist for Mozilla, so there’s no doubt that he’s one of the best known proponents of the language.

Although I use the jQuery library on a daily basis, I was keen to brush up on some of the finer points of Javascript; my knowledge of the jQuery library probably exceeds my knowledge of Javascript! For this reason, I thought the book sounded good.

The first half of the book certainly doesn’t disappoint. Covering the nitty-gritty of DOM traversal, OO Javascript, and unobtrusive scripting, the book does a great job of covering a lot of ground in a concise, clear manner. The key concepts are illustrated with plenty of code snippets which do a great job of illuminating the subject matter.

The second part of the book was less useful for me, illustrating some examples of AJAX functionality, image galleries, autocomplete, that sort of thing. These topics might have been considered intermediate to advanced in 2006, when the book was released, but the plethora of options around today means that developing stuff like that now is re-inventing the wheel. (Of course you might be interested in learning more about wheels!)

You can almost see the snippets of code in this book forming the nuts and bolts of the jQuery library, and it’s interesting to take a look at the hoops we developers would have to jump through to otherwise gain cross-browser compliance.

I’m just glad I’m not the one having to negotiate those hoops myself!

To sum up, this book is still worth reading for the first half alone, and the stuff on OO javascript, scoping, closures etc is really useful. But some might consider the book a little out of date, so be warned.

One of the things I missed when switching from Prototype to jQuery was the former’s Ajax.PeriodicalUpdater function. It is used to provide a ‘decay’ mechanism for ajax calls, making them less and less frequent if the retrieved content doesn’t change inbetween calls.

It can be a seriously useful piece of functionality. I took a chatroom that was polling every second and using an entire CPU core (50% usage!) and reduced it to 2-3% using this method. There were also errors retrieving content because sometimes the responses would take longer than a second to come back!

The problem is, there really isn’t a similar piece of functionality in jQuery.

So here it is! The script checks the returned data against previously received data, and increases the time between calls if it hasn’t changed.

I’d be interested in your comments. Would it be useful to turn this into a plugin?

View the demonstration here.

Steve Reynolds recently wrote a blog post showing how to access the twitter search API using PHP, cURL, and JQuery.

Steve used JQuery to post to a page on his server, which then cURLed in search results for a given term. This approach is often necessary to get avoid the issue of cross domain ajax calls.

While this approach works well, there’s an even easier way to go about it – $.getJSON!

There are two main advantages to this approach:

• Server side technology isn’t an issue. You don’t have to rely on PHP, cURL, firewalls, anything like that. It will even work on a static HTML page!
• All the work is done on the client’s browser – saving precious bandwidth! This could be important on busy sites.

I’ve knocked up a quick-and-dirty demonstration of this concept. If a name doesn’t already exist for this methodology, my vote goes for JAJA (Javascript and JSON, asynchronous!)

View the demonstration here!