Tagged "django"

A new version of Django was released a couple of days ago. I’m currently at 11 sites using Django, so upgrading them all manually (which I did last time) is a pain. To help me out, I wrote a tiny Fabric script to spin through my sites, check if they’re using the version of Django that was upgraded, and if they are, upgrade them. Simple Sites It’s worth noting that this only works because all of my sites are fairly low traffic, and I don’t mind too much just taking them offline for a minute or two.

I tried out Fabric a while ago, but never really got anywhere with it. Time passed, and I forgot it existed, and wrote my simple scripts for automating deployment of my various sites, using Paramiko. It was incredibly tedious, but meant I could deploy my sites from whatever computer I was on, provided I had a checkout of my code. Then I re-discovered Fabric, and realised I was about to throw away a lot of code.

Upcoming releases of Django will remove django.contrib.markup, but I still want to use it. I looked around for alternatives (perhaps a third party app?), before deciding to roll my own. Here’s why: It’s ridiculously easy. It means I can enforce which extensions are turned on[1. I always enable nl2br, which makes newlines act like newlines. Generally, most users of my sites are non-technical, and find “end a line with two spaces for a linebreak” confusing.

A good friend of mine alters cards for Magic: The Gathering for fun and profit. Previously, he posted them on his Twitter feed, along with a brief description, but that doesn’t provide a great way of seeing at a glance the sort of things he does - a place to point people who ask for examples of his work. Initially, I suggested Flickr, but it didn’t do quite what he wanted.

Order(n) is a pretty bad idea. Originally, my SearchIndexes for Haystack looked a bit like this: class RegularEventIndex(indexes.SearchIndex): text = indexes.CharField(document=True, use_template=True) Then, when someone ran a search, and I wanted to display a result, I’d load up a template (which template I loaded depended on grabbing the model name, as recommended in the docs), and any attributes of the model I wanted to display required doing a database lookup to fetch the data, like this:

A long while ago, I discovered that running Django tests is much faster if you use SQLite, and if you turn off South (this now seems pretty obvious, but at the time was a bit of a revelation to me). Since then, I’ve come across a better way of setting this up, to avoid having a test_settings.py: # If manage.py test was called, use SQLite import sys if 'test' in sys.

Every once in a while, I want to start again. I currently have 6 different sites using Kaléo, a bit of software I wrote for managing Church websites, which I’ll write about another time. The code is stored in a private git repository, and synced out to 6 different places every time I need to make a change. Most these changes are fairly simple, and upgrading each site looks roughly like this: