Inspired by Justin Lilly, I spent some time looking at various ways of running python web applications with an eye to performance. Nicholas Piël has done some great work testing and documenting many of them. Gevent looks like a great option as does CherryPy, but uWSGI caught my eye because it provides an nginx module and I’m already running lots of nginx. Since its fairly new, my stock nginx from the Ubuntu Karmic repository doesn’t come with uWSGI, but compiling it in is trivial.

So I’ve added uwsgi and nginx + uwsgi to my launchpad ppa for anyone out there who’d like to give it a spin on Karmic. My initial impressions are very positive. If you want to try it out, you can add my ppa to your apt sources and simply run:

sudo apt-get install nginx uwsgi

Continue reading »

I’ve been working on a project using django, and I’ve got some great things to say about it. I also have some nasty things to say. I’m currently prototyping, which means the databases I work with get destroyed and recreated regularly. I normally have a set of test data that should always be present in the system. Database fixtures to the rescue!

The django documentation has a nice section on database fixtures and how to deal with them properly. You can even give your fixtures a special name (initial_data), and the syncdb command will automatically load your initial fixtures for you. The first thing that really struck me about these fixtures is the fact that you have to reference your model for every database row. Why not divide the fixtures into sections so you only have to type it out once? The fixtures could really benefit from that type of context.

The second thing I noticed, after typing out all my fixtures in YAML format, is that django claims to support YAML format, but doesn’t actually check for an initial_data.yml (or initial_data.yaml) file. That’s a big disappointment. Now am I supposed to translate that file back into xml or json? It picks up files with those names perfectly fine.

Continue reading »