Recently I've been working on a new project in django, Squirt Blurt. It's been taking up a large majority of my time, so I haven't had much time to create new posts or work on other projects, but I just thought I would give a few impressions of things I learned/did along the way.
Rather than using the Django templating engine, I decided to write the project using Mako. The primary reason was that I was going to be incorporation a large amount of Finderweb's code which was already in Mako. However, I feel that there were a few benefits and disadvantages of going this route.
1.) Speed of development - Using Mako, I can create template logic must faster using a very simple view and a "logic header" in the template file to build up context. Initially I had an internal struggle breaking the view/controller model, but it really worked out well. As I needed to re-factor logic I could just pull them out of the template and into generic utilities, simplifying the template but still giving me a high degree of freedom in design.
2.) Django features - I really don't use many of django's extended features, but some things like forms are a little harder to handle in Mako. Ultimately most things like form fields can just be wrapped in a unicode function call and they will work fine. What won't easily convert are custom tags, such as for comments...but I needed to write my own comment system anyway, so this wasn't an issue at all (but may be for some people, particularly those new to Django/python).
3.) Template appearance - Writing logic into templates makes them generally more confusing, especially to a designer. As the templates were re-factored and cleaned out though the appearance wasn't so different than Django. I don't really buy into the belief that a web designer should be writing templates that contain logic anyway.
This was the first project that I used fabric and virtualenv to handle deploying servers 100%. I actually created a fabric file that defined host roles in a dictionary with actions to complete to set a server up from start to finish. If I ever need to scale to 10 or so servers, I believe that this will be a huge benefit. After the projects slow down a little I will be writing an article, or perhaps a series, on the use of fabric and git in a production setting.
I can't really say enough about virtualenv. I have heard utterances from some that don't like it, but I think that those are primarily from people that aren't hosting websites made in different versions of libraries possibly across different python versions on the same server. Though squirtblurt now has its own server, it was originally hosted on finderweb which needed a clear separation of libraries. Virtualenv makes it easy to set up new instances, control libraries installed, and add new libraries to only a single project. The only thing you have to watch out for is when your operating system updates minor python versions out from under you...but this is somewhat easily controllable and is also easy to fix.
Supervisord also helps with multiple deployments, as well as making deploying in a fastcgi environment much easier. To reboot a server after a code change you can restart individual instances. It also handles logging, auto-restarting on a crash, and can control non-fastcgi processes such a sphinx that is also required to go with the project. It fits along well with fabric as you can have fabric just have supervisor restart a process after updating it.
3. Base system
Having an existing base system to work from and change was hugely helpful. Since finderweb already has comments, was integrated with Jason's akismet module, and had a large logic base, it made an ideal candidate as a base for Squirt Blurt.. Also having the plug in Johnny Cache for automated queryset caching makes the site ultra fast even without optimized indexes or a customized caching solution (for now). I created a github repository when I started with the stripped finderweb base and will probably update it with the new squirt blurt base.
I will be continuing to write up articles about some of the technology and lessons learned in the making of Squirt Blurt. As the first full site I've made after beginning professional Django development I have noticed that my workflow was very different, and more importantly precise and quick to results while being mindful of things like future scalability and better database design. I hope to share some of that with you soon assuming I can find the time. :)