Hudson is a continuous integration tool. Almost half of the room already uses some continuous integration tool (hudson, buildbot, etc).
Funny: you can track extra things like code coverage percentage (cobertura plugin), count the number of pylint errors, etcetera.
Hudson is surprisingly friendly to configure: trough the web interface.
For django, you have to make some changes to the way the test runner is run.
They also hooked up some talking figure that starts messing around once there’s a broken build.
LFS is an online shop made with django. There are already some 20 shops online. 4 developers, we want more.
Variable shipping and payment methods. Vouchers and discounts. Reviews. And so on.
He doesn’t like generic views as it goes against many things that make Django great. For generic views and flatpages you need to keep too many things at the same time in your head.
Instead of having a view in views.py, a generic view is in urls.py where normally only your routing would be. And if you want to turn them into real views later on, you need to shuffle things around.
The good point: you can just choose not to use them. So don’t use them.
Django as a control center. ROA. Resources, web api?
Too quick for me.
There are many approaches for having translated content.
General problem: every object is expected to be translated in all languages. That’s not true for every site. So he went with the wikipedia approach. Django has the concept of sites. So every language gets its own site. And you link between them.
Flask is another microframework. Under the hood it uses jinja2 (template) and werkzeug (wsgi engine). 450 lines of code. Static files are served from a /static folder. Session handling. Before/after request hooks. Restful URL mapping.
Lots of documentation (120 A4 pages). Website with lots of snippets. Active mailinglist.
Programmers must learn licensing or I will kill them. It is important!
Caveat: IANAL, but I’ve shown them my slides and they agree.
Copyright: right to make a copy.
Copyleft: not anti-copyright. It uses copyright. It allows changes, provided it is under the same license.
Default license: all rights reserved. That’s the default license by law.
Programmers must add a license file or I will kill them. It is important!
Basically you have two choices: BSD/MIT: weak copyleft, simple. GPL/LGPL: heavy copyleft.
License are community signifiers.
The GPL isn’t appropriate for django applications as it doesn’t fit with Django’s model.
If your code isn’t MIT/BSD/Apache/mozilla licensed (read: GPL), I can’t use it.
A German Tibet learn-buddism-in-7-years website needs help building their website with Django.
Do you do it manually? Do you do it with setup.py?
How do you handle dependencies (like: is apache installed)?
How do you handle database passwords? Webserver setup? How do you update/upgrade/remove your software? How to provide user accounts? In which way is DB maintenance handled on your target platform?
Would it be great if your website would fit into your OS instead of being a wart?
Someone already solved it all for you: linux packaging systems like for instance debian/ubuntu’s .deb.
You’ve got to put in roughly one week of learning packaging and get it all properly set up. That’s the price you have to pay.
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):
