Over the last week I spent several hours going through the Django tutorials. I do not have any prior web development experience, and I had expected it to be much harder to use than it actually was.
Django, named for jazz musician Django Reinhardt, is a Python-based web framework. The main features of Django are its data-model syntax, syntax, database API, administrative interface, use of URLconf files, view-template system, caching framework, and syndication framework for RSS . The data-model system uses Python classes that are subclasses of django.db.model and are processed as if each attribute of a model were a database field . This integration with the database allows the database API to conduct lookups with dot syntax (e.g., Computer.objects.get(id=1)). The URLconf system maps URL regular expressions to Python views that generate pages in response to a request matching that URL pattern. The view-template system (views and templates are both Python classes) has view files either raise exceptions, or load a template and use it to render a page that is returned as a HTTPResponse .
One of the major principles embodied in Django’s design is the DRY principle, or “Don’t Repeat Yourself.” Dave Thomas (no relation to the “Wendy’s” founder) describes it as the idea that every piece of project knowledge – code, database schemas, unit tests, and build system – should be represented in only one place in a software system. This reduces the amount of duplicated code that would otherwise have to be maintained in parallel . In Django, this is implemented as “Every distinct concept and/or piece of data should live in one, and only one, place .” This commitment on the part of the developers was demonstrated in the tutorials by the ability to have urls.py files reference each other and by the emphasis on using generic views. Though I had some issues setting up the tutorial’s generic views, I do support this idea in theory – having worked on several Java student projects where code was copied and pasted around in order to reuse methods in otherwise unrelated classes, I have seen the problems uncontrolled code reuse can cause even in small projects.
Django’s developers claim that it follows the Model-View-Controller (MVC) architecture pattern, except that the “view” is the Python function that describes which data is presented and is associated with a URL, and the “controller” is provided by the framework that sends requests to the correct view. The view actually is dependent on the template to describe how the data is presented. The developers’ response to questions about the MVC “inconsistency” they are sometimes accused of is to collectively shrug and say they prefer that the framework works in some way that makes sense to them instead of being bound to an arbitrary standard . Django’s widespread adoption points to most of its users not much caring about this minor inconsistency very much. If one is a “perfectionist with a deadline,” the perfectionism must frequently be moderated to the deadline for practicality’s sake, and so long as Django works and does so consistently, the developers in effect argue, it does not matter so much what things are called. If something were widely supported and worked in a documented, consistent way, I think I would be satisfied with it even if it did not explicitly meet a standard.
 Askins, Ben and Green, Alan (2006). A Rails/Django Comparison [Online]. Available: https://docs.google.com/document/pub?id=1ys7fEX-ZqROYb4rUJXvDnBJU_vNiqT75ecT5mLiytCk.*
*Linked to from an official Django blog, which describes the author information.
 Django Software Foundation (2013). Django appears to be a MVC framework, but you call the Controller the “view”, and the View the “template”. How come you don’t use the standard names? [Online]. Available: https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names
 Django Software Foundation (2013). Design Philosophies: Don’t Repeat Yourself (DRY). [Online]. Available: https://docs.djangoproject.com/en/dev/misc/design-philosophies/#don-t-repeat-yourself-dry
 Django Software Foundation (2013). Django at a glance [Online]. Available: https://docs.djangoproject.com/en/1.4/intro/overview/
 Django Software Foundation (2013). Models [Online]. Available: https://docs.djangoproject.com/en/1.4/topics/db/models/
 Venners, Bill (2003, March 10). Orthogonality and the DRY Principle: A Conversation with Andy Hunt and Dave Thomas, Part II [Online]. Available: http://www.artima.com/intv/dry.html
 Webmonkey Staff (2010, February 15). Get Started with Web Frameworks [Online]. Available: http://www.webmonkey.com/2010/02/get_started _with_web_frameworks/