Jeremy Satterfield
Coding, Brewing and Tulsa Life

Class-based Celery Tasks

Recently, I've had to write several complicated Celery tasks. Unfortunately, when doing a complicated process standard task functions can become unwieldy to write, read and unit test. After looking into how Celery tasks actually work, I was able to find a more manageable way of writing these complex tasks.

Mocking Python's built-in open function

A while back I was working on my podcast client and ran into an issue downloading large files. The root problem was that all of Django's FileField backends store the file (or file-like object) to memory then saves it to disk, and the cubieboard system I was using had limitied memry resources, resulting in "out of memory" errors. After much searching and hacking I finally settled on just storing the file to disk myself using requests streaming argument. This allowed me to download the file in chunks and save directly to disk and then tell the Django field where I placed it, as you can see here.

Abusing Django Rest Framework Part 4: Object-level field exclusion

Similar to the object-level readonly field from my previous post, there are some cases where we want to exclude certain fields based on what object the user is trying to access. You could overwrite the views get_serializer method to use a different serializer based on their access, but if nesting serializers is a possiblility this get messy, somewhere in the neighborhood of O(n2). Another option is to modify a serializers to_native method.

Abusing Django Rest Framework Part 3: Object-level read-only fields

DRF has tools to control access in a few ways. Serializers make it easy to select what fields can be accessed and whether or not they are read-only. Permissions are great for restricting access to objects at all or even making certain objects read-only. But there are also cases where you might only want to allow access to a field on a specific object but leave that field restricted on other objects, or vice-versa.

Using Tox with Travis CI to Test Django Apps

Being a fan of good testing, I'm always trying to find ways to improve testing on various projects. Travis CI and Coveralls are really nice ways to set up continuous integration for your open-source projects. A couple months ago I finally started hearing grumblings about tox and how everyone was it using for their Python test automation. Every time I'd try to wrap my head around it, something always eluded me, so this week I finally decided to dive in head first and see if I could get to the bottom of it and how it could improve my current integration setup.