Peterbe.com

I've done a site that is initially only going to be in Swedish. So I set the LANGUAGE_CODE like this:

# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html
LANGUAGE_CODE = 'sv-SE'

I then go ahead and mark my templates and code and run django-admin.py makemessages -l sv-SE. Then I fire up Poedit to translate the .po file and then compile to make the .mo file, so now I had a file called <my project>/locale/sv-SE/LC_MESSAGES/django.mo but it just wouldn't work!! I tried debugging django.utils.translation with little success. Eventually through trial-and-error I found that if I change it to "sv" instead of "sv-SE" it works.

Is this a problem with gettext or a problem somewhere in Django? It might cause equally much headache for other developers so I wouldn't mind that we get to the bottom of this.

Just put in the remaining necessary cache headers on my kungfu club mobile site and I ran a YSlow! test on it and it got a 100! I've never had that before.

Admittedly, this is like cheating since the site is for mobile use it's kept very very simple and has no external dependencies so no need for a CDN. Getting a Grade A on YSlow! is very hard if the site needs to really blink. This one is built dedicated for small mobile phone screens on slow connections. I think now the bottleneck isn't in the rendering but in the connection latency for the remote database.

It also got a 4.9 (max 5.0) on ready.mobi which is the highest I've ever achieved there.

Caching in Django absolutely rocks. Much so because of its simplicity which lowers the threshold to the height of a snowflake. However the simplicity can cause some unexpected surprises.

I ran my site and clicked around until I found a bug I wanted to fix. Then I wrote the test and ran the testrunner but I was getting some really weird behavior. The view looked like this:

@never_cache
def club_page(request, clubname):
   club = _find_club(clubname)
   if club is None:
       raise Http404('Could not find the club')

   classes = cache.get('club_page_classes')
   if classes is None:
       classes = ClubClass.objects.filter(club=club).order_by('start_time')
       cache.set('club_page_classes', classes, CACHE_TIMEOUT)
   ...

What happened (and what took me a while to figure out) was that the memcache was still active and being used when running the tests since it's only within the hour that I started running the tests with completely different data. Here's how I solved the problem:

class ViewsTestCase(unittest.TestCase):
    ...
    def test_club_page(self):
       """ test rendering the club page """
       cache.delete('club_page_classes')
       ...

There must be an easier way to patch the testrunner to reset all cache before running the tests. Anybody?

Seconds ago I got this running and haven't yet fully understood what I've just done but the results are exactly what I need and this is going to be great.

Basically, in Django you have views like this:

def _render(template, data, request):
   return render_to_response(template, data,
             context_instance=RequestContext(request))

@login_required
def club_page(request, year):
   variable1 = year / 4
   variable2 = variable1 * 2
   return _render("foo.html", locals(), request)

Now in my unit tests I don't want to have to call the view function and then have to dissect the resulting HTML just to figure out if the view function prepared the correct variables. So, here's my solution to this problem:

From the django-users mailinglist which I'm becoming more and more helpful in:

> Could you share approximately how big your project is? I know it's
> hard to find a real measure for this, but how about number of database
> tables?

A project I worked on over the summer used a Database that was 130
tables, and getting 1gb updates every 2 minutes. I was witting a new
web app to do calculations on the data and the company wanted to use
Java since thats what they knew best and had spend huge amounts of
money (1 mil +) to support with Sun Servers, and such. But I knew
python and django would be a better fit for this particular app, but
the boss wouldnt listen. So we had 10 Developers working on the Java
version (Including me) and over 3 months we got it about 85% done,
though it had no unit tests. During the same three months, I worked on
my own time after work and basically had no life for the whole time, I
was able to get the web app 100% complete with unit tests. That
convinced my boss that Django was a good fit.

The site is an internal app that I cannot give access to (And I
actually had to get permission to give what info I have), but I can
say that Django is a suitable framework for what you are looking for. 

Christ! 10 developers and no unit test!? Someone should remind them that you don't write unit tests for your bosses pleasure but for your own sanity and productivity.

I know that this quote is totally unscientific since Dj, as he says, can't back it up but it's a story interesting enough.

I've been working with Django a lot lately and while I can't contribute to the code base until my project is done, I can contribute money.

Been browsing the Django mailinglist and found this guy (link above) and some other people saying they're willing to donate money towards the OS effort that is Django. That's nuts and is a failed practice but it does mean a lot. Zope had this about 4-5 years ago too but that was then. Clearly the heat is all on Django (and Rails admittedly) at the moment. Well done to all involved!

I've been doing quite a bit of Django this weekend and this instant quick rush I got from getting started has gone off and now starts to become just normal trudging. At the moment it's the templating language that annoys the hell out of me.

In conclusion: Today Django won another point in the race for my attention.