Journey to Intermediary Models
It's been around an 8 month journey in adding intermediary model support to Django, starting with a ticket opened during a sprint by Jacob Kaplan-Moss. Earlier that month I had been wrestling with several pretty nasty models, each with two foreign keys and many extra properties on that relation. I kept thinking that Django makes everything else so easy, but that in at least this one aspect, it doesn't make things easy enough. When Jacob posted his API idea, I was hooked.
I quickly posted some thoughts and asked for a bit of clarification, and volunteered to write the patch. Jacob responded saying he was glad to help me out. It was only then that I actually delved into the code to see how it could be done. It was only then that I realized that I had absolutely no knowledge or familiarity with that portion of the codebase--a portion that is nontrivial, to say the least. But that's the good thing about committing to something: you feel pressure to follow through.
Despite my incredible Naïvité, the patch got to a rudimentary usable state very quickly, and then started to flounder. It was then that Russell Keith-Magee came into the picture, continually prodding me to add more tests, and thinking up many different test cases that I would have never come up with on my own. I'm 100% certain that if Russ had not lent his expertise and guidance on this patch, it would have gotten lost and forgotten for a long time until someone more capable came along to take a look at it.
A few hours ago, Russ committed the patch to trunk. It's interesting to see the reactions that some people have, but on any project like this you'll always be scrutinized. In any case, check out the two new bits of documentation, and see if intermediary models are right for your project. After having this great experience with working on a patch for Django, I'll definitely be looking to help out in other places as well. My advice for anyone looking to get involved with the project is to, well, get involved! Jump in over your head. It's more fun that way.
PyMag
For around as long as I have been working on intermediary model support, I've been supporting another Django project of mine: django-threadedcomments. One of the things that I noticed a few months into maintaining the project is that outside of a few people who were actively using it, not many people really knew about its existence. So when Doug Hellmann (of the famously excellent PyMOTW series) contacted me about writing an article for PyMag, it was immediately apparent what I would love to write about. Over 4000 words later, between finals and school projects and moving across state boundaries, the article was written.
To be honest, I had almost completely forgotten about having written it, aside from one short e-mail conversation with the technical editor. It turns out that the July 2008 edition of PyMag has arrived and my article is listed under "featured articles". How cool is that!? I'm quite proud of the article, and really hope that it helps some people out with their Django websites. If you aren't a PyMag subscriber, then what are you waiting for?
This post seems to be doing a lot of self-promotion--sorry for that. But these two things really made my day, and to me, blogging is about sharing those awesome days with others.
After my last post about django-threadedcomments, there have been several new releases. We've integrated completely with comment_utils, added support for gravatar, and added some internationalization (I love that we abbreviate this as i18n) support as well. Every day more and more people seem to be adding bug reports, patches, and feature requests to the ticket tracker. This couldn't make me happier, and I hope to see it continue. But what does this have to do with ideas? It's the first programming idea that I've taken through conception, execution and all the way to support. After django-threadedcomments, I've decided to change my outlook on how to organize and deal with ideas that I get every day.
Supporting a Project
There sure is a thrill to just sitting down and quickly hammering out the solution to a problem. Who cares if it's hacky and incomplete? You just proved that your idea was doable and you did it. It instills quite the sense of accomplishment. That's the style of project that I've worked on until now (aside from work). With django-threadedcomments, however, there's a completely different feeling that's just as thrilling: people are actually using it. It gives a completely different and stronger sense of accomplishment. The reason is because I made a conscious effort to support the application after its initial release, for my own benefit and for others'.
Admittedly it can be tedious at first. I'm convinced that nobody enjoys writing test code, and writing documentation can take as long as writing the code itself (especially if you delete and re-write as much as I do), but being able to apply patches that people submit and actually ghasp re-use your own code in other projects is where the reward really lies.
Ideas
I have ideas all the time--as I think most people do. Whether it be while writing code for one project, sitting idly in class, or even eating my cereal in the morning, ideas for nifty programs or websites or APIs just sort of pop into my head. What do I do with them? Until recently, what happened is that I'd start working on it and lose interest after a while. Over the last few months, however, I've begun to form a list instead of starting on the projects.
Why make a list? Looking at my track record of starting and abandoning projects--and assuming that I'd like to do that far less often--it seems that something needs to change. The change that I've settled on is to put them on a list instead of hastily implementing them. When I attack one of these ideas, I'll attack it fully and correctly; bringing it from conception to implementation, and finally to support. The reasons for this are three-fold:
- It's a good incubation period. After a while, some ideas seem stupid, while others keep begging to be solved.
- It allows for a greater sense of accomplishment. Once you cross out a few items on your list, you'll realize that what you've done is quite a feat.
- You can simply remember all those crazy ideas that you have had.
What is on my List?
I'm sure many of you may be asking what, specifically, I have on my list. django-threadedcomments is on there, and my next project is django-simplestats. The latter is not ready for public consumption yet, but check it out if you'd like to see a sneak peek. There are also several other items, but I'm not going to talk about them because it would take all the fun away from me! Honestly though, don't ask me for my list. Come up with your own and work through it for yourself.
And You
Enough about me in this rambling post, what about you--how do you deal with ideas that you get every day? Am I crazy for actually enjoying supporting a project? Do you have any tips for me in my organizational endeavours? Please respond in the comment section below.
It's an interesting feeling open-sourcing an application that you've developed for your own purposes. Will people use it? Will people find major design flaws? Is it just a big waste of time? These were the questions that were going through my mind before open-sourcing django-threadedcomments. Fortunately, my worries were quelled almost instantly as a people reacted quite positively to the application. There was one recurring comment, however, that almost everyone who tried the sample implementation said: those colors are hideous.
Beyond even that though, it seems that people saw the sample implementation and got the impression that django-threadedcomments = that sample implementation. To me, that's an underestimation of the power of the modular django app. I think that James Bennett hits the nail on the head when he says that:
"Rather than a single definitive 'Django blog' application, for example, I think it’s much more likely we’ll see a collection of applications which, taken together, provide all the key functionality..."
It was this sentiment that pervaded nearly all of the design decisions behind django-threadedcomments: it should be flexible, modular, and reusable so that, taken together with other similarly-designed apps, it can provide some compelling functionality at a fraction of the effort. Now we most assuredly didn't achieve all of those design goals fully, but I believe we're headed in at least the right direction with its development.
To prove my point, I decided to create an improved Digg/Reddit comment system clone using Jonathan Buchanan's wonderful django-voting application, alongside django-threadedcomments, and a fair bit of jQuery. Being almost completely new to Javascript, I was pleasantly surprised by how easy it was to not only integrate all of these technologies and use extensive client- and server-side scripting, but also to achieve a compelling commenting system in well under a week of spare time. Oh, and this time there was actually some effort in making the look and feel of the commenting system acceptable! As with the first example, this one is completely open sourced and available in the django-threadedcomments SVN repository.
Without further ado, the Example Digg/Reddit Comment Clone Plus Focus.
Django-threadedcomments is a simple yet flexible threaded commenting system for Django. What I mean when I say threaded is that commenters can reply not only to the original item, but to other comments as well. It is very similar to what Reddit or Digg have in their comments sections.
The idea for this application started about a month and a half ago, when my good friend Tony Hauber asked if I would work with him on a project idea that he had (more info on this in the future). One of the major components of the project would need to be threaded comments. Naturally, the first thing that I did was attempt to make django.contrib.comments work for this purpose. In the end, however, I kept running into problems which all basically boiled down to the fact that django.contrib.comments was never meant for this purpose.
So I used django.contrib.comments as a starting point, brought in some of the best features of the excellent django-comment-utils (In fact, django-threadedcomments actually provides a fair amount of compatiblity with the Managers from django-comment-utils), and added a bit of my own alchemy. This is the result of those things.
A lot of effort has gone into documentation on this project: inline documentation, a tutorial on setting it up with a blog, and complete API documentation. In fact, to see what you'll get after completing the tutorial, head on over to this page. Please excuse my color scheme there--It's the comments that I'm trying to show off, not my design skills (or lack thereof).
If you're worried about the hassle of writing a script to migrate all of your django.contrib.comments comments to this new system, then fear not: there's an included migration script and you'll only need to run python manage.py migratecomments and the migration is automatically taken care of for you.
I really hope that this can be a useful tool for people looking to add a threaded commenting system to a project of theirs. Check it out and see if it's right for you!
All Content
