Why ReportingOn Launched on Django

    by Ryan Sholin
    October 3, 2008

    First things first: ReportingOn is live, it’s a public beta, and it’s built in Django. Whoo-hoo!

    I have a long list of things to polish, add, tweak, revise, and rethink, but it was time to open the site up to users and let them help me figure it out.

    Last time I wrote about the options I was considering for Web development, I was leaning toward Django and away from Drupal.


    Here’s why I gave up on Drupal for this project and moved on to Django:

    Drupal is a fantastic content management system out of the box, with little — if any — programming knowledge required to get started, but I found it to be extremely difficult to mold into the application I was building.

    Did I need the structure Drupal came with for users, posts, archives, feeds, and comments? Probably. But there was a whole bunch of other baggage, like all the WYSIWYG block and module organization that I wasn’t as comfortable with. My first instinct was to start from scratch and build my own theme, but I quickly realized I needed to build my own content types. And views. And the file system was confusing to me, coming from WordPress. Plus, although the Drupal community is full of awesome people building awesome modules, I still couldn’t figure out how to do a few simple things, like create a content type with a maximum length (say, 140 characters).


    On the other hand, as soon as I started digging a little further into Django, I found an active community of developers working on projects similar to mine.

    Why? Is it just because Django is still new and shiny? Maybe. But the fact that developers interested in services like Twitter and Friendfeed were building their own tools in Django with similar functionality made all the difference as I looked for open source projects and pluggable apps to incorporate into ReportingOn.

    Here are a few of the Django applications that have been involved in my development process in one way or another:

    • Finisht: Nick Sergeant’s “done” list for “developers who do things.” (On Google Code)
    • Pinax: James Tauber is the lead developer on this project, which, frankly, is pretty all-encompassing. If you’re seriously considering building any sort of social network or content management system in Django anytime soon, I highly recommend you take a close look at all the work that’s already been done on Pinax before you start reinventing any wheels. Check out Cloud27 for a demo of what this system is capable of with all its bits active. (On Google Code)
    • Django-Tagging
    • Django-Profile

    Plus, the Django community and my own network of online friends and acquaintances has an enormous amount of overlap, so I’ve been inundated at times with offers of help, hints, tips, and flat-out answers to my questions about Django.

    The Drupal commmunity? I certainly know a few people there, but without an exception that I can think of (correct me, please), they’re developers first, and journalists second. Which is fine, except that I’m really trying to maintain ReportingOn as something built by journalists, for journalists.

    Why? Well, while a primary goal of mine is to make ReportingOn a repeatable process — in this case, a relatively self-contained Django application that anyone can run on their own server — I’m really trying to make this something repeatable by journalists with little programming experience. And that describes me, too. I have a few years of experience working with WordPress and other platforms, but most of the “programming” I’ve done has been strictly copy & paste, trial & error.

    In fact, I expected the “programming” part of building ReportingOn to be far more difficult. In July, when I told Adrian Holovaty I was seriously thinking about using Django for my project, he said: “I didn’t know you were a programmer.” My response: “Well, I’m not. I didn’t think you had to be.” And Adrian suggested a book about learning Python called “How to think like a computer scientist“ that I haven’t read yet, because I’ve had an easy time of picking up bits of Python by reverse-engineering other applications and walking myself through every tutorial and screencast that I’ve found.

    It wasn’t that hard to wrap my head around Django’s file structure, or the model-template-view pattern. Frankly, it was harder to get certain accessories to Python running in a development environment on my laptop, but once I moved the app to a production server at Webfaction I had much, much better luck.

    None of this is to say I’d recommend against using Drupal for any number of projects. 12seconds is one of the most impressive things I’ve seen built in Drupal, lately, and it certainly doesn’t feel like Drupal when you’re using it.

    But for me, as a proof of concept that a journalist with just a little programming knowledge can build something interesting on a low budget (all I’ve paid for so far has been Web hosting), assembling ReportingOn in Django was the way to go.

    Tagged: django drupal reportingon web development

    7 responses to “Why ReportingOn Launched on Django”

    1. For the record, to create a content type with a maximum length of 140 characters, you install CCK, go to Administer » Content management » Content Types » Add content type. Create it without a body. After it’s created, click add field. Under Create new field give it a system name and a display name (Label) and select Field type Text. Select Widget type Textfield (or Textarea), and under Global settings there is, third from the top, Maximum length.

      No coding necessary at all. All in the user interface with Drupal and CCK.

      benjamin, Agaric Design Collective

    2. I just finished (almost) a quickie site in Drupal and it was pretty mind bending to get the system to do things that I take for granted when building a site from the ground up with a text editor. I’m excited to give Django a go given all the recent success stories and especially since it seems to be a good fit in the J community.

    3. @Benjamin:

      I knew you’d have an answer. I did get that far, but could never manage to pry the Title field off the content type, and definitely didn’t get far enough to build a happy little form for users to type their updates into.

      My bigger problem was that there was nowhere to look for the answer. How many Drupal developers are building microblogging tools?

      (Actually, at a glance, the search results for “drupal microblog” have increased dramatically since I last looked early this summer.)

      But there were a ton of existing and in-development Django projects to learn from, so it was just a better fit for me at the moment.

    4. Exciting Ryan!
      Despite being married to Drupal, I think its great you did it in Django. It looks great and I’m glad you’re making progress. I hope your efforts will be a strong contribution to the Django community.


    5. Tom Altman says:

      I think it has more to with just figuring out what you want to do – then match up the platform to the needs.

      Who cares if its Drupal, Django, WordPress or good old HTML. It’s like – just pick one and DO something.

      I like the end quote: “as a proof of concept that a journalist” (or other professional) “with just a little programming knowledge can build something interesting on a low budget”

      Very good post,

    6. I’m quite intrigued by the Django-based social network tools (Pinax) you mention. Perhaps they will help us with the Crunchberry Project.

    7. As with most things, it depends. A CMS is a very useful tool and no programming involved is a big plus if it covers what you need. But when you are looking at a writing a custom application, the right tool is a framework.

      One has to realize that you will be writing code and you need to decide if you care about your software, how efficient it is, how well it scales, how well it is designed, you need to focus on it. “It works” is not good enough if the actual code is something of value. Your upgrade path breaks, you start hacking drupal core to get things to work and suddenly you have an un-releasable and un-maintainable code base. Down the line you will have problems when you want to release the code, deploy it or add feature x.

      So if you just want a set of features up and running as soon as possible with minimal amount of work then sure find the quickest solution. But if one of your goals is maintaining and building communities around your software, continuing to develop it, then don’t do that.

  • Who We Are

    MediaShift is the premier destination for insight and analysis at the intersection of media and technology. The MediaShift network includes MediaShift, EducationShift, MetricShift and Idea Lab, as well as workshops and weekend hackathons, email newsletters, a weekly podcast and a series of DigitalEd online trainings.

    About MediaShift »
    Contact us »
    Sponsor MediaShift »
    MediaShift Newsletters »

    Follow us on Social Media