a weblog by Ed Eliot

Pressure is nothing more than the shadow of great opportunity. - Michael Johnson

This weblog is the online home of Ed Eliot, an experienced developer, architect and technical manager based in London, UK.

Entries for November 2007

You are currently viewing posts from the archive. Click here to return to the latest posts.

  • First steps with Django

    9 years, 7 months ago

    I really like PHP and well Django is based on Python so I've been slow in getting around to looking at it. Anyway Stuart and Cyril have been raving about how great both Django and Python are recently so this weekend I finally sat down and spent a few hours with Django. I thought I'd jot down my thoughts/discoveries so far particularly as one or two things tripped me up and whilst it might just have been me being a bit stupid I'm pretty sure I won't be the last. I installed Django on Mac OS X so no doubt some of the issues I encountered may be different or possibly aren't present on your set up.


    Whilst trying to use MySql with Django I found that:

    1. Python doesn't include MySql client libraries by default. You need to download and install the MySQLdb package manually.
    2. MAMP (which includes MySql) doesn't ship with the MySql source header files needed to build the MySQLdb package. Instead download a Mac OS X installer for MySql from mysql.com.
    3. Make sure the folder location of the various MySql binaries (mysql, mysqladmin etc) is included in your path (check with echo $PATH). If not modify your .bash_profile accordingly and source (. ~/.bash_profile) after making changes.
    4. If you get an error similar to -
      ImportError: dlopen(./_mysql.so, 2): Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient_r.15.dylib
      - when trying to build MySQLdb it's caused by an incorrect path specification. The easiest way to solve this is to run "cd /usr/local/mysql/bin; ln -s /usr/local/mysql/bin mysql" as described here to sym link to the correct place. Obviously there will be better ways to solve this.

    Onto Django

    Here's what I particularly like so far:

    • The documentation and Django book. They're fantastically clear and the only time I went wrong was when I wasn't paying enough attention to them (a classic case of not RTFM). I wish all projects did it this well.
    • Being able to query models from the python command line shell. It also doubles as a fairly quick (and I guess scriptable) way to add test data to your database.
    • The URL configuration mechanism. It's very flexible and I like the way one can separate URL configuration for specific applications from the main URL configuration file. It also affords your application greater security through default input filtering (assuming you write good regular expressions) - a view is never called if data passed in the URL doesn't match the regular expression. The MTV model used by Django makes much more sense to me than the standard MVC model used by most frameworks.
    • Configuration of template paths in settings.py (within your project folder). You can specify as many different search paths as you want and Django will search each one in turn until it finds a matching template. I see some potential for supporting different types of "localised" templates. Could these paths incorporate a dynamic element I wonder? Additionally the block tag syntax within individual templates looks like a really good way to cut down on the number of templates required, for example page.html instead of header.html and footer.html for one's base layout, as well as providing another way to "localise" template regions in specific instances. It should be noted I use the term "localise" fairly generically. I'm not just talking about localisation in the internationalisation sense.
    • Python's decorator syntax. In Django this allows you to specify caching or require authentication for individual views by adding a simple one liner above the view's definition. No need to mess with the logic of the view - nice!
    • The flexibility of the caching - cache the whole site, specific views or individual items of data and Django has in built support for a number of different caching mechanisms - memcached, database or file based as well as simpler single process and dummy caching mechanisms for use during development. The dummy mechanism looks particularly useful in allowing you to add your caching code without actually being burdened with cached pages during development.
    • The admin interface of course. I was surprised how configurable it is from the application models.py file and I like that you can override templates files corresponding to the admin interface on an individual basis without having to modify the stock set.
    • The "sites" framework. This add-on allows you to associate content in your database with one or more sites which use that content. You could use this, for example, to publish the same article to two sites with one hit. This feature also integrates editing into a single instance of the Django admin interface.

    So far I've only scratched the surface but I'm really, really impressed in fact so much so that it's hard to overstate. So where from here? I'll probably start by replacing phpMyAdmin with Django to administer the content on my site. Jeff Croft wrote an interesting post about doing just this a while ago.

  • User generated translations

    9 years, 7 months ago

    A couple of months back Stuart and I released a tool for automatically generating CSS sprites and corresponding CSS rules from component images - CSS Sprite Generator. At the time we thought it would be cool to build in support for localising the interface should users wish to provide us with translations. I don't think either of us had any idea as to how this would pan out and we certainly didn't expect the level of response we've received so far. Personally I've been bowled over by peoples willingness to translate someone else's tool. I'd like to extend a huge thank you to the following people who have kindly supplied translations:

    Next time you're building a web based application I'd strongly encourage you to consider providing localisation support up front. Building the necessary features to support localisation (internationalising your application) at a later stage is always more painful and you may be pleasantly surprised by the response from your users once they realise they can help bring your application to their native language.

    In many situations localisation covers much more than translation but in the interest of keeping things simple here's some links to a few libraries and other resources which will get you started with providing support on the translations front:

    I found one or two really interesting sites which allow people to post text they require to be translated. These entries sit in a queue and can be translated and ranked for accuracy by other sites users:

    I think these last two only scratch the surface of what's possible but provide a new(ish) slant on user generated content.