I’m sitting here in Building 40 at Google, waiting for this morning’s first DjangoCon keynote to start, and getting ready for the Django technical design panel which comes immediately afterward. Naturally, I’m taking advantage of the down time (and Google’s bandwidth) to upload my slides from yesterday’s talk. If you’ve seen/read the slides from the version of this talk I gave at PyCon, I can tell you that there are now 40% more slides and they’re all new material.
And, of course, the whole deck of slides is CC-licensed, like the photos used within.
A video of the talk is also available on YouTube.
Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.
That’s exactly the kind of slides I was looking for after I saw the couple of rules you wrote down in Django tips: laying out an application.
As always the slides are much appreciated, thanks!
Thanks James for publishing the slides. Those are very useful. They carry the message pretty well on their own, although I wish I had attended the actual presentation!
I just read all slides and going to rewrite my blog engine now! :-)
I’ll try to make it as reusable, as possible. But I have one question.
What about module dependencies? For example, I have few apps “blog”, “gallery” and “utils”. Both, “gallery” and “blog” use some functions, decorators and template tags from the “utils” app.
What can I do, to make “blog” and “gallery” reusable?
@Alexander Artemenko: The bad and fast way: Embed the parts of util you use into the released apps. The good-ish way: Make it clear that those apps depend on another app of yours, that you have also released.
@James Bennett: Thanks, lad. I bet all of us appreciate this share.
Thanks!
Thanks!
But model._default_manager? I didn’t know about that. When I see methods named with a leading underscore, I tend to consider them a private or unstable API. (Appreciate it’s mentioned in Ch 23 of the Django docs.)
I guess that convention isn’t the case in Django, then?
Otherwise - great set of slides, thanks for publishing.
@Alexander Artemenko: release those apps as eggs, then you can declare them as dependencies in a setup.py. I actually use buildout for reproducible Django builds.
Your talk was the best one at DjangoCon. Thanks for the solid advice and smooth delivery.
@Dan Fairs
It is technically private API, but there are a few bits of Django’s internals which have been historically stable enough (things in
Model._metahave, ironically, been about the most stable part of Django over the years) and useful enough that I usually recommend people use them.