Project skeletons: gathering and distributing knowledge¶

Tags: python, django

A skeleton is something you generate a new project with. So: one command and you’ve got a fresh directory with everything in there to start a new django app, website, python library, whatever. Basic readme, setup.py, models.py and so on.

In an earlier post about skeletons for easy best practices, I said that skeletons have two main advantages:

• Boilerplate reduction. Basic files get created and set up for you. Laziness works to your advantage. “Just start the project from a skeleton” gives you something reasonably solid and neat. The alternative is to just start off with a python file and a sub directory and “remember” to add the readme and so later.
• Best practice. Pour your knowledge into a skeleton. Figure out the way you want to set up your projects once and reap the fruits many times over. You’re probably copy-pasting apache config files from one project to the other: why not keep the latest and greatest config file in the skeleton? For me, this is the number one advantage: you’ve got a place to collect your project setup best practice. And having that place to put it means that more best practice gets attracted!

I really want to drive home that last point. A skeleton helps enormeously in gathering and distributing knowledge and experience. Both for yourself and for your organisation/company.

Yesterday, one site started misbehaving. Eating up all CPU. There’s a bug in there that we’ll have to solve monday. I also noticed that the performance could be better: the css/javascript files were not combined. Nothing was being gzipped. Oh, and the django exceptions didn’t end up in a proper logfile. Didn’t I solve that before somewhere else?

Ok, time to dig into the two most recent projects and compare their django settings files and their apache configs with the one currently in our skeleton product and raise the skeleton to the current state-of-the-art.

• Site A gave me the automatic running of bin/django build_static whenever you run buildout. Handy, I kept forgetting that.
• Site A and B gave me the logging setup including a bit of custom middleware to log all python exceptions.
• Site B gave me correct caching and gzipping-on-the-fly apache setup.
• Site B gave me an apache rewriterule tweak to get Openlayers (a mapping javascript library) to behave itself regarding css and icons.

And… all the project-individual tweaks and hacks? I just left them in place. Those don’t end up in the skeleton. If you don’t have a skeleton, you mostly copy/paste code from the latest project. Including unneeded hacks and tweaks. So: use a skeleton, that transfers knowledge and experience in a cleaner way.