Posted
by
Peter Baumgartner
on
October 24, 2012.
Filed under
javascript,
pro tip
First off, realtime websites are hard. The current toolset is rudimentary. When I first started building Ginger, I thought I must be doing it wrong because of all the trial-and-error and pieces I was building from scratch. After watching Geoff Schmidt’s keynote at DjangoCon, I realized it’s not that I’m dumb, it’s that everyone is reinventing their own wheel. His co-creation, Meteor, promises to fix that, but until then, we’re stuck with the tools we have.
One thing nearly every realtime site needs is a replay log. Public networks are inherintly unstable (doubly so for mobile). If a client disconnects for a short period of time, users will expect to receive any data it missed when it reconnects. That’s where a replay log comes in. It keeps a log of all activity and, when a client reconnects, it streams all the data it is ...
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.
