There are really only a handful of features I miss about Ruby on Rails, having switched over to using only Django about a year ago. One of the biggest among these has been named scopes.

What a named scope does in Rails, in Django terms, is allow you to name a given query and use it as a base, or “scope,” for further queries. In other words, your narrowing down the results upon which additional queries that you run will be executed.

It’s pretty much the same idea behind modifying initial Manager QuerySets as outlined in the Django documentation, with one major difference: Scopes can be chained. Chaining is the feature I had long coveted, and I had been banging my head around for a solution for the last few months.

The other day while I was poking around the internals a bit though, a decent idea came to me. I realized it would be quite simple for me to extend the default Manager class with an attribute where I could store QuerySet methods I wanted to execute as part of a scope, and then overwrite get_query_set() with a hook that ran these methods before executing the rest of the query.

This turned out to be a nice strategy, and with the addition of some decorators the interface itself turned out to be extraordinarily simple.

(more…)

I just started a small side project last week, and I finally decided to take the opportunity to really make TDD (test-driven development) happen for me using Django. Though I’ve dabbled with testing in Django and done quite a bit more with testing in Ruby, I never managed to embrace TDD fully. It’s about time, I figure.

Well, I hit some snags as I got underway. Partly this had to do with me being something of a novice when it comes to testing, and partly it has to do with the state of testing in Django at present.

My mini-gripe with testing in Django is that it’s just kind of loosey-goosey. You can use doctest, or you can use unittest. You can put your tests in your functions, or in your models, or in tests.py, or in a tests/ subfolder.

For me at least, I want my framework to be a bit more opinionated. I want a bunch of guys who are all smarter than me to have sat around and thought about (or better yet, generalized from a working production code) things like the best way to configure testing for a Python web framework, and then to tell me, in no uncertain terms, the exact way to do it.

I’m obviously exaggerating a bit, and I don’t really mean at all to rant about a phenomally awesome, not to mention open source, framework like Django. What all of the above amounts to is that I had to ponder deeply on the problem space myself and come up with a way of structuring my test code that would work for me.

So that’s what I did, and here is the organizational structure I intend to use as I proceed.

(more…)

Today, I had to whip up a Django template tag to add “a” or “an” in front of a phrase.

It started off pretty easy — just use “an” when the first letter of the phrase is a vowel and otherwise use “a.” And then I remembered about abbreviations (“an HR department”), silent H words (“an honorable man”), and exceptions among a few O and U words (“a one-time offer” or “a union representative”), and suddenly it wasn’t so easy.

Fortunately I managed to find an excellent database of English words that includes pronunciations, and in no time at all I was able to generate a list of exceptions.

Here’s the final result, implemented as a custom django template tag (in my use case, I needed to able to wrap the original phrase in an HTML tag, so I couldn’t use a filter tag). This could also easily be a standalone Python function as well (literally by removing the @register.simple_tag decorator).

(more…)

So the purpose of this post is just to look at a neat way of solving a problem in Django, and explain its mechanics and how it was put together.

In today’s example, the goal was pretty straightforward. We have a model class, Topic, that has a one-to-many relationship to a ThreadedComment model class. Each ThreadedComment for each Topic, has a User associated with it; furthermore the Topic itself as a User associated with it (the creator of the topic).

(more…)

I’m working on a group chat feature at my day job right now. The requirement is for a robust group chat widget to run alongside a live streaming video feed (via Ustream) of a two-day conference. If the solution works well, we want to consider using it for other purposes, e.g. webinars.

I was pretty dissatisified with my brief survey of existing chat widgets out there. This is a professional conference, so I really didn’t want a widget that was all yucked up with ads or smileys.

Anyhow, since I use Campfire a lot at my day job, I figured, why not give it a shot?

The good news is, Campfire does have an API, known as Tinder.

The bad news is, it’s an unoffical API, written in Ruby. (Not that there’s anything wrong with that, but I didn’t want to deal with configuring a reliable production environment for what was hopefully a small project.)

The good news is, someone ported the Tinder API over to Python, calling it Pinder. Which rocks, because now I get to use Django.

(more…)