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:

Read More…

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.

Read More…

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'

Pretty straightforward, right? The solution from the site was the following:

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

I went for a totally different solution though:

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

Is it something I’d use in production? Nope. It’s less readable and less pythonic, in my opinion, than the longer answer. (Although some would argue that you don’t get more pythonic than list comprehensions.)

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

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