The Scoop

I haven’t mentioned Fumblerooski in awhile, but rest assured that work continues, especially during college football season. I’ve added more coaching information (still a long ways to go on that, though) and will be unveiling player rankings soon. But the biggest thing I’ve done lately has nothing to do with new features. Instead, as I’ve become a better coder in general, I’ve seen how bloat can really hinder a project. So I spent time last week reorganizing the Fumblerooski code to take advantage of some of Django‘s strengths.

This all started back at the NICAR conference in Indianapolis where several of us led a mini-bootcamp on using Django. At one point, as we talked about how projects are organized, I showed off the models for Fumblerooski. They went on forever. Looking back, it wasn’t the message that I wanted to get across – I think several people gasped.

Fumblerooski still is far more tightly coupled together than I’d like – the scrapers can’t really be separated out as an independent app, which would be the right thing to do. But it’s getting closer. Same for the rankings app. Coaches could be the next one, or maybe players. The scrapers, even though they don’t constitute an actual app, are better organized. The point is that now the code is probably easier for someone else to follow, but it’s also easier for me to locate specific functions. I spend less time hunting and more time actually doing things.

How does this actually work? Python’s ability to import libraries into others means that Django apps can share common code (and, if you’re working in the same database, data) inside a single project just by typing an import statement:

from fumblerooski.rankings.models import RushingSummary

And I get access to the rushing rankings wherever I need to use them. Because this is so trivial, it sometimes led me to think that where I put things didn’t matter. But it does, it really does, for your sake and the sake of anyone who attempts to look at your code.