Since my first impressions of Django were generally cautiously optimistic, I opted to keep at it to see how things go. There’s still plenty to learn but so far, but the framework is turning out to be beautiful. Not necessarily simple – more like elegant. And while it is not flawless (I am still a tad critical of some of the DB design choices), it virtually eliminates the mundane.
Where I am now is figuring out how to balance the whole project versus application thing and how that all works. James Bennett explains things rather well from a higher level view. So I get the concept but not how that affects a custom application such as the one I am working on now for aquarium management. Trying to decide how simple to be has been puzzling. For instance, it is pretty clear that the integration with my Arduino controller should be its own app. It’s also clear I can split out the equipment and water management stuff into their own apps. But where it gets hazy is if some of the equipment stuff could be segmented.
This above video suggests the Unix philosophy of doing one thing, and doing it well. Well, I can look at that in multiple ways, some of which allude to having multiple apps and some which don’t. For instance, much of the equipment used in an aquarium (though not all) requires some level of maintenance (cleaning sponges, replacing filters, etc.). So, looking at that one way, I should probably include the logging functionality into that one app. But looking at it another, doing one thing well could be just keeping track of equipment inventory and perhaps state. The logging functions could be segmented.
Since apps an inherit from each other, it’s not like it’s a crime if I get this wrong and end up with too many apps other than I guess some overhead and extra work. But on the other, the apps would be tightly integrated together such that I’m not sure what the best solution is.
Likewise, there are somethings the Django framework cannot do without needing to write some SQL. I ran into a case where I needed to do a GROUP BY for aggregates of a child table to match to multiple objects from the parent. In SQL, it is mostly trivial, but I was unable to find a Djangofied way to do that without busting SQL. I will say Django is pretty smart about how custom queries work and how objects are build and extended.
Overall, I’ve been rather happy with it. You end up with a pretty functional application fairly quickly and most of the decisions I seem to make are ones that I should be making – about organization, distribution, inheritance. It is a framework that forces you to think about those things, and, in the end, that seems to be paying dividends.