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:
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.
bin/django build_static
whenever
you run buildout. Handy, I kept forgetting that.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.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):