I have wanted to have an excuse to try Django for a long while and decided to give it a go. I have been thinking about expanding on my Aquariduino controller idea and adding to it a web-based application that can track additional information aside from what I will pull from the controller. Things like water test and change history, equipment maintenance history, an aquatic life log, etc. This could include sending periodic reminders for when it’s time to do certain tasks and could graph some of the history (most notably the water test results). It seems like a great starter project for Django as it is relatively simple but quite useful.

So how has it gone? Well, the actual writing of code has been a blast. It is the first platform I have used where I have had to describe the data-model and that’s neat! Plus the built-in bits have already proved quite useful. In fact, the admin add-on basically already encompasses most of the basic functionality I wanted in the tool. I have been able to do a huge amount with very little actual code.

There have been a few struggles. As a database administrator by day, I don’t like relinquishing control – especially when that means I have to let go of some rooted design principles. Django does not currently support unsigned auto incrementing keys, nor does it support compound primary keys. It also does not have a built-in field type for tinyint’s. The big one is that it does not support the TIMESTAMP type, which I am a huge advocate for because of the convenience and efficiency it offers.

Beyond that, I have also had trouble with setting things up with Apache. I ended up having to manually upgrade Django from 1.2 to 1.4, and diddle around with WSGI quite a bit. The problem is that the documentation on how to set things up glosses over some details and it is hard to track down what is going on when things go awry. I have since gotten things working enough for now, but this took far more time than it really should have.

All told, even with those minor gripes and time taken for silly things like system paths, I spent less time than if I wrote something in PHP and have more function too. It’s too soon to say if I’ll stick with Django, but other than my minor gripes, it is pretty slick. Ultimately the test may be in how easy it is for someone else to set things up. I am writing this web-application for me, but will release it as open source for anyone else. And, hence, it should be at least somewhat easy for someone to take a deploy without much fuss. PHP is fairly ubiquitous in this regard. Django is mostly straightforward, but not as much as a well packaged PHP distribution for the end user. Of note, GoDaddy does not support Django. It does support PHP. So is likely the case with many hosting providers. To add, the demographic for those that would want to use this tool, I suspect, would be those who are not system administrators or developers. It would be a shame to require a high skill-set to use the tool many would fine useful. Sure, I could extend the application into a hosted solution but then I have to figure out how to pay for it :) And, that makes pulling data off the Arduino controller much less trivial.

So time will tell, but even if it Django is not a good fit for me now, it’s still a compelling framework that is worth a look. Even without knowing much Python, it is easy to use and, because of that, is probably a good entry-point into the world of Python, too.