Posted
by
Vláďa Macek
on
January 30, 2012.
Filed under
django,
pro tip
The recommended way to add decorators such as login_required to class based views in Django is a bit verbose. Here’s a little metaclass-producing function you may find handy:
def DecoratedDispatchMethod(actual_decorator):
"""
If you want to decorate the Class-based View with, say, login_required,
the recommended way is this:
@method_decorator(login_required)
def dispatch(self, *args, **kwargs):
return super(MyProtectedView, self).dispatch(*args, **kwargs)
To avoid the need of writing this ugly code again and again, one can use
this as a metaclass of the class that needs to be protected with a decorator.
class MyProtectedView(...):
__metaclass__ = DecoratedDispatchMethod(login_required)
...
"""
class CBVMetaclass(type):
def __init__(cls, name, bases, attrs):
type.__init__(cls, name, bases, attrs)
cls.dispatch = method_decorator(actual_decorator)(cls.dispatch)
return CBVMetaclass
Posted
by
Vláďa Macek
on
January 6, 2012.
Filed under
pro tip,
sysadmin
Without patching, the rsync utility lacks support to detect when a file was renamed/moved across multiple directories inside the synced tree. There is a --fuzzy option to save bandwidth by building upon similar files on the target side, but only in the same directory.
You may need to synchronize the large file tree over a slow connection when you’ve done a big reorganization since the last rsync run. A real world example: Joe stores multiple GiBs of family photos and videos at home and periodically backs them up to a remote server.
$ rsync -avHP --delete-after ~/family/Photos remotebox:backups
One day, Joe decides he used the wrong directory layout or the file naming scheme and shuffles these gigabytes under a totally different directory structure, a quick local operation.
Unfortunately, there is no apparent safe and quick way to mirror these changes to the remote backup disk without either ...
Posted
by
Peter Baumgartner
on
August 24, 2011.
Filed under
pro tip
Coverage.py makes it easy to see how much of your code is covered by your test suite. It can be configured to spit out reports in XML (for consumption by a continuous integration server like Jenkins), in HTML (for human viewing), or simply dumping out plain text.
Getting started with coverage and Django is easy. First make sure you have the latest version of coverage (3.5 at time of writing) installed by running pip install -U coverage, then run your test suite and print a report:
coverage run manage.py test
coverage report
This is all well and good, but you’ll quickly notice that coverage reports on every file it touches including third-party libraries, the Django framework, and even Python itself. Often, you only want to see the coverage report for your code. Coverage provides a few options to narrow the scope of the report. They are ...
Posted
by
Peter Baumgartner
on
July 1, 2010.
Filed under
pro tip
We love pip and Fabric for Django deployment. You can see our boilerplate fabfile.py here. Pip, however, isn’t safe to run in an automated fashion. If you attempt to switch branches or repos for one of your editable requirements, you’ll be presented with this input:
What to do? (s)witch, (i)gnore, (w)ipe, (b)ackup
At this time, there is an open bug to solve this problem, but thanks to the trusty *nix toolkit, we have an easy workaround. Enter yes. From its manpage:
NAME
yes - output a string repeatedly until killed
SYNOPSIS
yes [STRING]...
yes OPTION
DESCRIPTION
Repeatedly output a line with all specified STRING(s), or `y'.
...
I have the most success with the “wipe” option for pip, so now we can simply run:
yes w | pip install -r requirements.pip
This answers w to any prompt that pip displays, making it much more ...
Posted
by
Peter Baumgartner
on
June 24, 2010.
Filed under
pro tip,
sysadmin
I really like supervisord for long-running process management. It is Python, so it is easy to install and it is easy to script with tools like Fabric. Lately I’ve been deploying smaller Django/WSGI sites with Green Unicorn behind Nginx proxied over a Unix socket which makes for a nice little setup on shared hosting and RAM starved VPSes.
After installing supervisord with something like sudo easy_install supervisor, you’ll want to make sure it runs after you reboot your machine (and gets restarted in case it crashes). If you are on a Linux system with upstart (and have root access), you can bypass the ugly init scripts and use this simple file placed in /etc/init/supervisord.conf to manage your supervisord process:
description "supervisord"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
exec /usr/local/bin/supervisord --nodaemon --configuration /etc/supervisord.conf
Now that it is ...
Posted
by
Peter Baumgartner
on
February 12, 2010.
Filed under
pro tip,
sysadmin
Here’s one I struggled with a bit while upgrading lincolnloop.com yesterday.
Scenario: You need to take your site offline and want to redirect all its traffic to a “down for maintenance” page. For search engine friendliness, that page should return a 503: Service Unavailable status code. Here’s the (not entirely intuitive) way to do that in Nginx:
server {
listen 80;
server_name mysite.com;
root /var/www/mysite.com/;
location / {
if (-f $document_root/maintenance.html) {
return 503;
}
... # the rest of your config goes here
}
error_page 503 @maintenance;
location @maintenance {
rewrite ^(.*)$ /maintenance.html break;
}
}
Now whenever you need to take your site offline, simply create the file maintenance.html in the $document_root (in our case, /var/www/mysite.com). If the file exists, Nginx will serve it with a 503 status code, if not, it will proceed as usual.
