I love tox - it’s a great tool for checking that your Python packages are installable, and that you support all the various configurations of Python versions and other package versions that you think you do. It’s also quite a neat way of checking your documentation builds properly, and that your code remains PEP 8 compliant1. I also love Travis, since it helps me accomplish much the same thing as tox, but does so in an automated way, with every push.

Yesterday, I found two bugs whilst looking at a code coverage report. I tend to think that shooting for 100% code coverage adds unnecessary overheard - often the last few percent doesn’t give you much benefit, and takes a disproportionate amount of time to reach, but it’s useful to at least understand why particular lines of code aren’t hit by your tests. Perhaps those lines are dead code, or perhaps - as was the case for me yesterday - it’s because your code is broken.

One of the programming lessons I find myself re-learning again and again is this: It’s turtles all the way down 1. When I first started my current job, just after graduation, I was working in a frontend development rôle. The app I was working on involved storing customer data in a proprietary database system, and from time to time, I’d get stuck. Perhaps data wasn’t being saved in the way I expected, or perhaps operations on the database were slow in ways I didn’t expect.

I’ve just got a new laptop, and wanted to avoid messing around with symbolic links in order to install PIL in a virtual environment. I’ve just discovered patch, and thought I should automate my process of installing PIL (a process which previously involved me making a trivial edit to the setup.py file). This is obviously not particularly revolutionary, but I thought it was quite neat, so thought I’d share it. The script (which is just bash) looks like this:

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 do a lot of development without an internet connection1, so being able to install packages into a virtual environment without a connection to PyPI is pretty useful. I’ve got a couple of aliases in my .bashrc which help with this2: alias pipcache='pip install --download ${HOME}/.pip-packages' alias pipinstall='pip install --no-index --find-links=file://${HOME}/.pip-packages/' The first downloads the packages to my local cache, the second installs them from the cache. Usage is probably fairly obvious:

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.

My web-development office is a fast-moving place. It averages around 50 miles per hour, and I work on a laptop normally squished between two people on the train to and from the office. When I happen to have a spare moment to build websites at home, I tend to use my desktop, which is running Ubuntu. I do my editing in emacs, where I’ve gradually got things set up more or less as I like them.