Successfully reported this slideshow.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

The Best (and Worst) of Django

  1. The best (and worst) of Django jacob@jacobian.org http://lanyrd.com/sgbwt/
  2. 1,215,616
  3. Public Enemy #1: Over-engineering.
  4. “Do the simplest thing that could possibly work.” — Simon Willison
  5. Small is beautiful
  6. The monolith monster The “application” is the whole site — no apps, no components, no modules. Makes heavy use of site-wide logic: middleware, context processors and custom plugin-like concepts.
  7. (I blame Rails.)
  8. “It’s a pretty simple site; about fifteen or twenty thousand lines of code…”
  9. site_of_unspeakable_horrors !""  settings.py !""  urls.py !""  views.py #""  models.py
  10. models.py — 2,800 lines views.py — 11,900 lines
  11. Big is bad; Small is beautiful.
  12. The Django mindset: Application: some bit of functionality. Site: several applications. Spin off new apps liberally. A suite of apps ready for use.
  13. There’s no such thing as “content.”
  14. XXX screenshot: “content” box
  15. Django is an un-CMS.
  16. The Django mindset: A great and powerful respect for data. Model the data correctly and the rest of the site will just fall out of that. Denormalization is all well and good, but never throw data away.
  17. The “everything-is-a…” anti-pattern
  18. “Everything needs a creation date.”
  19. class  BaseObject(models.Model):        creation_date  =  models.DateField()        … class  Animal(BaseObject):        … class  Vegetable(BaseObject):        … class  Mineral(BaseObject):        …
  20. Without a concrete base class: >>>  Animal.objects.all() SELECT  ...  FROM  animal; With a concrete base class: >>>  Animal.objects.all() SELECT  ...  FROM  "animal"  INNER  JOIN  "baseobject"   ON  ("animal"."baseobject_ptr_id"  =  "baseobject"."id")
  21. What you want: >>>  BaseObject.objects.all() [<Animal:  Frog>,  <Vegetable:  Carrot>,  <Mineral:  Gold>,  ...] What you get: >>>  BaseObject.objects.all() [<BaseObject:  1>,  <BaseObject:  2>,  <BaseObject:  3>,  ...]
  22. So maybe you try something like: def  get_some_of_everything():        qs  =  BaseObject.objects.all()        for  obj  in  qs:                for  cls  in  BaseObject.__subclasses__():                        try:                                obj  =  cls.objects.get(baseobject_ptr=obj)                                break                        except  cls.DoesNotExist:                                continue                yield  obj
  23. “Our site worked fine in development and testing, and was working wonderfully for the first few months. “But we just added a bunch more data, and now our homepage takes 27 seconds to load.”
  24. 1,800 queries
  25. “But… but… everything really does need a creation date!” So give everything a creation date.
  26. “Do the simplest thing that could possibly work.” — Simon Willison
  27. If you must get fancy: Abstract base classes don’t suffer from these performance problems. Denormalize into a UI-ordered auxiliary model. Non-relational databases work particular well here (I like SOLR).
  28. Those who do not understand PYTHONPATH are doomed to failure.
  29. >>>  import  sys >>>  sys.path ['',  '/Library/Python/2.6/site-­‐packages/pip-­‐0.8-­‐py2.6.egg',  '/Library/Python/2.6/site-­‐packages/pdbpp-­‐0.7-­‐py2.6.egg',  '/Library/Python/2.6/site-­‐packages/Pygments-­‐1.4-­‐py2.6.egg',  '/Library/Python/2.6/site-­‐packages/wmctrl-­‐0.1-­‐py2.6.egg',  '/Library/Python/2.6/site-­‐packages/pyrepl-­‐0.8.2-­‐py2.6.egg',  ...  '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6',  ...  '/Users/jacob/.local/lib/python2.6/site-­‐packages',  '/Library/Python/2.6/site-­‐packages',  ...] >>>  import  re >>>  re <module  're'  from  '/System/Library/Frameworks/Python.framework/Versions/ 2.6/lib/python2.6/re.pyc'>
  30. ~/Projects/djdash !""  __init__.py !""  dashboard $      !""  __init__.py $      !""  admin.py $      !""  models.py $      #""  views.py #""  manage.py (https://github.com/jacobian/django-dev-dashboard)
  31. $  ./manage.py  shell >>>  import  dashboard.models >>>  dashboard.models <module  'dashboard.models'    from  '/Users/jacob/Projects/djdash/dashboard/models.pyc'> >>>  import  djdash.dashboard.models >>>  djdash.dashboard.models <module  'djdash.dashboard.models'  from  '/Users/jacob/Projects/djdash/../djdash/dashboard/models.pyc'> >>>  djdash.dashboard.models.Metric  is  dashboard.models.Metric False
  32. You might have an import issue if… “Hey, many-to-many relations don’t show up in the admin.” “What’s up with these import errors when I deploy under mod_wsgi?” “Grrr… assertRaises doesn’t work!”
  33. Django is wrong! (I’m sorry.)
  34. Fixing import madness 1. Use non-project-relative imports (import  app.models, not import project.app.models). 2. Use relative imports (from  .  import  x) where possible (see http://bit.ly/pep328). 3. Stop using manage.py.
  35. Delete manage.py? $  django-­‐admin.py  shell  -­‐-­‐pythonpath=`pwd`  -­‐-­‐settings=settings.local >>>  import  dashboard.models >>>  import  djdash.dashboard.models Traceback  (most  recent  call  last) ... ImportError:  No  module  named  djdash.dashboard.models
  36. For virtualenv users: $  add2virtualenv  ~/Projects/djdash $  echo  "export  DJANGO_SETTINGS_MODULE=settings.local"      >>  $VIRTUAL_ENV/bin/postactivate $  echo  "unset  DJANGO_SETTINGS_MODULE"      >>  $VIRTUAL_ENV/bin/postdeactivate $  django-­‐admin.py  shell
  37. Keep (your settings) simple.
  38. Don’t do this … INSTALLED_APPS  +=  [p  for  p  in  os.listdir(BASE)                                      if  os.path.isdir(p)]
  39. … or this … urlpatterns  =  patterns('',  ...) for  app  in  settings.INSTALLED_APPS:        if  not  app.startswith('django'):                p  =  url('^%s/'  %  app,  include('%s.urls')  %  app)                urlpatterns  +=  patterns('',  p)
  40. … or this. MIDDLEWARE_CLASSES  =  [...] def  callback(arg,  dirname,  fnames):        if  'middleware.py'  in  fnames:                m  =  '%s.middleware'  %  os.path.split(dirname)[-­‐1])                MIDDLEWARE_CLASSES.append(m) os.path.walk(BASE,  callback,  None)
  41. Python’s design is predicated on the proposition that code is more often read than written.
  42. INSTALLED_APPS  =  (        'django.contrib.auth',        'django.contrib.contenttypes',        'django.contrib.sessions', MIDDLEWARE_CLASSES  =  (        'django.contrib.sites',        'django.middleware.common.CommonMiddleware',        'django.contrib.messages',        'django.contrib.sessions.middleware.SessionMiddleware',        'django.contrib.staticfiles',        'django.middleware.csrf.CsrfViewMiddleware',        'django.contrib.admin',        'django.contrib.auth.middleware.AuthenticationMiddleware',        'django.contrib.messages.middleware.MessageMiddleware',        'django.contrib.flatpages',          'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware',        'django_extensions',          'debug_toolbar.middleware.DebugToolbarMiddleware',        'debug_toolbar',   )        'south',   urlpatterns  =  patterns('',        'rs.users',          url(r'^admin/',  include(admin.site.urls)),        'rs.orgs',          url(r'^signup/',  include('rs.signup.urls')),        'rs.signup',        url(r'^org/',  include('rs.orgs.urls')),          'rs.clients',        url(r'^clients/',  include('rs.clients.urls')),        'rs.timezones',        url(r'^caregivers/',  include('rs.caregivers.urls')),        'rs.caregivers',        url(r'^account/',  include('rs.users.urls')),        'rs.dashboard',        url(r'^dashboard/',  include('rs.dashboard.urls')),        'rs.scripts',        url(r'^reminders/',  include('rs.reminders.urls')),        'rs.reminders',        url(r'^calls/',  include('rs.calls.urls')),        'rs.billing',        url(r'^scripts/',  include('rs.scripts.urls')),        'rs.calls',        url(r'^contact/',  include('contact_form.urls')),          'chunks',        url(r'^login/',  'django.contrib.auth.views.login',  {},  'login'),          'contact_form',        url(r'^logout/$',  'django.contrib.auth.views.logout',  {},  'logout',), )        url(r'^changepassword/$',  'django.contrib.auth.views.password_change') )
  43. Multiple settings files
  44. The localsettings anti-pattern At the bottom of your settings file: try:        from  local_settings  import  * except  ImportError:        pass
  45. “It’s simple: just create a local_settings.py, throw overridden settings in there, and then never check the file into source control.”
  46. “It’s simple: just create a local_settings.py, throw overridden settings in there, and then never check the file into source control.”
  47. Handling multiple settings files 1. Don’t. Why is your staging environment different from production? 2. Use DJANGO_SETTINGS_MODULE.
  48. The one true way settings #  base.py !""  __init__.py INSTALLED_APPS  =  [...] !""  base.py !""  staging.py #  local.py !""  production.py from  settings.base  import  * #""  local.py INSTALLED_APPS  +=  ['debug_toolbar'] $  django-­‐admin.py  shell  -­‐-­‐settings=settings.local #  deploy.wsgi os.environ['DJANGO_SETTINGS_MODULE']  =  'settings.deploy'
  49. “Do the simplest thing that could possibly work.” — Simon Willison
  50. Thank you! jacob@jacobian.org http://lanyrd.com/sgbwt/

Editor's Notes

  • \n
  • lead developer, django\nconsultant, revsys, where I help companies scale web apps.\n
  • lead developer, django\nconsultant, revsys, where I help companies scale web apps.\n
  • This is how many lines of Django code I&amp;#x2019;ve read over the last 2 years or so.\n\nBy comparison: Django: 120kloc, Python stdlib: 300kloc, pypy 550kloc (or 1m incl stdlib)\n\nMuch of this code has been good; some of it has been great; some very very bad. My goal today is to share with you some of what I&amp;#x2019;ve learned - to suggest certain successful patterns, and warn you away from other noxious ones.\n
  • The theme that&amp;#x2019;s emerged here: y&amp;#x2019;all are far to damned clever.\n\n\n
  • One of Simon&amp;#x2019;s favorite quips. Also known as &amp;#x201C;KISS&amp;#x201D; and a bunch of other things, but what I like about this particular formulation is the word &amp;#x201C;possibly&amp;#x201D;. It&amp;#x2019;s not &amp;#x201C;do the simple thing that you know will work&amp;#x201D;; it&amp;#x2019;s &amp;#x201C;do something that *could* work&amp;#x201D;. If it doesn&amp;#x2019;t, *then* you can get more complex.\n\nDjango does not lend itself very well to overengineering. Keep it small, keep it simple, keep it clean.\n
  • Pattern 1: small is beautiful.\n
  • This is easiest to explain by starting with the anti-pattern, so let&amp;#x2019;s start there. I see, from time to time, Django apps that are just one huge ball of wax - a monolith. Instead of multiple apps, there&amp;#x2019;s just a single app with all the code in it.\n\nTypically these don&amp;#x2019;t grow well at all. Because there&amp;#x2019;s no real thought to factoring, the web gets more and more tangled, and you end up needing to fall back on site-wide things like middleware and context processors to get bits into the right place. At the extreme, people end up inventing their own plugin-like concepts. Remember: Django&amp;#x2019;s *got that* -- INSTALLED_APPS -- so if you&amp;#x2019;re reinventing that system you&amp;#x2019;re cutting against the grain.\n
  • \n
  • I&amp;#x2019;ll give one example. Client wanted us to review his code, he told us that it was 20kloc. Sounds fairly small and easy to review, until &amp;#x2026;\n
  • Wait, where&amp;#x2019;s the rest of the site?\n
  • Groan.\n
  • I often like to graph the models to get a handle on how the data fits together. The red box is just this one app; something on the order of 200 or so models in there.\n\nThere was stuff in there like &amp;#x201C;Customer&amp;#x201D; and &amp;#x201C;Customer2&amp;#x201D; &amp;#x2014; with such a big ball of wax, people were afraid to make changes, not knowing what the ramifications would be.\n
  • Large modules are generally considered &amp;#x201C;code smell.&amp;#x201D; All-in-one design prevents reuse. You&amp;#x2019;ll need to introduce random, unrelated code. Monoliths are hellish to test.\n\nMany great Django apps are very small. Even a lot of &amp;#x201C;simple&amp;#x201D; Django sites commonly have a dozen or more applications in INSTALLED_APPS. If you&amp;#x2019;ve got a complex site and a short application list, something&amp;#x2019;s probably wrong.\n
  • \n
  • Here&amp;#x2019;s what (the data parts of) a well-designed site look like. This is a selection of 5 apps from a larger project, but note how easily I can pull them out -- there&amp;#x2019;s not any tendrils out of here[*]\n\nI want to particularly point out the faqcreator app. The system here is a ticketing and knowledge base system, and one requirement was the ability to quickly convert a ticket to an FAQ entry. I could put this logic in the FAQ system., but then it would create a circular dependency between tickets and faqs, which makes no sense and prevents reuse. So I introduced a faqcreator that depends on both.\n\nRemember: dependencies are just fine, but they should be logical, and they should be linear.\n\n[*] actually there&amp;#x2019;s an FK to user but I typically omit that -- I consider Django apps fair game for deps.\n
  • \n
  • \n
  • \n
  • These make up the bulk of what you&amp;#x2019;ll write as a Django dev, usually.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Pattern two: model your damned data. aka Django is not a CMS.\n
  • A typical &amp;#x201C;CMS&amp;#x201D;. This makes me sad sad sad.\n
  • ca 2003 Adrian/Simon working at the LJW; content managed in a (reasonably good, custom built) CMS. But you just can&amp;#x2019;t pull information out of CMSes\n\nexample: gas prices. every morning, a reporter would call a few gas staions in lawrence and ask about gas prices. Then he&amp;#x2019;d open the cms and type &amp;#x201C;Shell: $1.82. Quick Stop: $1.88&amp;#x201D;, etc. This is terrible: no way to get historical data, no way to graph changes over time, no way to build a &amp;#x201C;closest gas to me&amp;#x201D;, etc. This is turning &amp;#x201C;data&amp;#x201D; into &amp;#x201C;text&amp;#x201D;, and readers predictably found these &amp;#x201C;stories&amp;#x201D; useless. Eventually the reporter had to stop. Imagine if instead we&amp;#x2019;d collected that data as data...\n\nDjango started as a reaction against CMSes. This isn&amp;#x2019;t to say that CMSes are bad. But if you want one, Django isn&amp;#x2019;t it.\n
  • Instead, Django really really wants you to model your data. There&amp;#x2019;s no such thing as content: there&amp;#x2019;s gas stations and price measurements; public officials and speaking appearances; photographs and infographics.\n\nAnother example: look at lanyrd. Plenty of people have made conference web sites, but Simon followed (because helped invent!) the Django philosophy, and the site&amp;#x2019;s incredibly useful because if its powerful respect for the data.\n
  • One particularly pernicious form the &amp;#x201C;content&amp;#x201D; issue takes is what I all the &amp;#x201C;everything-is-a&amp;#x201D; antipattern.\n
  • Starts here.\n
  • So you do something like this.\n\nRemember, though: databases are *not* OO, so what this actually does is to create a foreign key from (Animal, Vegetable, Mineral) back to BaseObject.\n
  • So consider what happens when you do queries.\n\nNow there&amp;#x2019;s a &amp;#x201C;hidden join&amp;#x201D;. Now, the &amp;#x201C;JOINs are evil&amp;#x201D; thing is a bit of a myth, at least if you&amp;#x2019;re using a grown-up database, but it&amp;#x2019;s clear that the first query is a lot cheaper than the second.ways\n\nThis gets even worse if you&amp;#x2019;ve got multiple levels of interitance.\n
  • So consider what happens when you do queries.\n\nNow there&amp;#x2019;s a &amp;#x201C;hidden join&amp;#x201D;. Now, the &amp;#x201C;JOINs are evil&amp;#x201D; thing is a bit of a myth, at least if you&amp;#x2019;re using a grown-up database, but it&amp;#x2019;s clear that the first query is a lot cheaper than the second.ways\n\nThis gets even worse if you&amp;#x2019;ve got multiple levels of interitance.\n
  • So consider what happens when you do queries.\n\nNow there&amp;#x2019;s a &amp;#x201C;hidden join&amp;#x201D;. Now, the &amp;#x201C;JOINs are evil&amp;#x201D; thing is a bit of a myth, at least if you&amp;#x2019;re using a grown-up database, but it&amp;#x2019;s clear that the first query is a lot cheaper than the second.ways\n\nThis gets even worse if you&amp;#x2019;ve got multiple levels of interitance.\n
  • So consider what happens when you do queries.\n\nNow there&amp;#x2019;s a &amp;#x201C;hidden join&amp;#x201D;. Now, the &amp;#x201C;JOINs are evil&amp;#x201D; thing is a bit of a myth, at least if you&amp;#x2019;re using a grown-up database, but it&amp;#x2019;s clear that the first query is a lot cheaper than the second.ways\n\nThis gets even worse if you&amp;#x2019;ve got multiple levels of interitance.\n
  • So consider what happens when you do queries.\n\nNow there&amp;#x2019;s a &amp;#x201C;hidden join&amp;#x201D;. Now, the &amp;#x201C;JOINs are evil&amp;#x201D; thing is a bit of a myth, at least if you&amp;#x2019;re using a grown-up database, but it&amp;#x2019;s clear that the first query is a lot cheaper than the second.ways\n\nThis gets even worse if you&amp;#x2019;ve got multiple levels of interitance.\n
  • So consider what happens when you do queries.\n\nNow there&amp;#x2019;s a &amp;#x201C;hidden join&amp;#x201D;. Now, the &amp;#x201C;JOINs are evil&amp;#x201D; thing is a bit of a myth, at least if you&amp;#x2019;re using a grown-up database, but it&amp;#x2019;s clear that the first query is a lot cheaper than the second.ways\n\nThis gets even worse if you&amp;#x2019;ve got multiple levels of interitance.\n
  • So consider what happens when you do queries.\n\nNow there&amp;#x2019;s a &amp;#x201C;hidden join&amp;#x201D;. Now, the &amp;#x201C;JOINs are evil&amp;#x201D; thing is a bit of a myth, at least if you&amp;#x2019;re using a grown-up database, but it&amp;#x2019;s clear that the first query is a lot cheaper than the second.ways\n\nThis gets even worse if you&amp;#x2019;ve got multiple levels of interitance.\n
  • So consider what happens when you do queries.\n\nNow there&amp;#x2019;s a &amp;#x201C;hidden join&amp;#x201D;. Now, the &amp;#x201C;JOINs are evil&amp;#x201D; thing is a bit of a myth, at least if you&amp;#x2019;re using a grown-up database, but it&amp;#x2019;s clear that the first query is a lot cheaper than the second.ways\n\nThis gets even worse if you&amp;#x2019;ve got multiple levels of interitance.\n
  • So consider what happens when you do queries.\n\nNow there&amp;#x2019;s a &amp;#x201C;hidden join&amp;#x201D;. Now, the &amp;#x201C;JOINs are evil&amp;#x201D; thing is a bit of a myth, at least if you&amp;#x2019;re using a grown-up database, but it&amp;#x2019;s clear that the first query is a lot cheaper than the second.ways\n\nThis gets even worse if you&amp;#x2019;ve got multiple levels of interitance.\n
  • So consider what happens when you do queries.\n\nNow there&amp;#x2019;s a &amp;#x201C;hidden join&amp;#x201D;. Now, the &amp;#x201C;JOINs are evil&amp;#x201D; thing is a bit of a myth, at least if you&amp;#x2019;re using a grown-up database, but it&amp;#x2019;s clear that the first query is a lot cheaper than the second.ways\n\nThis gets even worse if you&amp;#x2019;ve got multiple levels of interitance.\n
  • So consider what happens when you do queries.\n\nNow there&amp;#x2019;s a &amp;#x201C;hidden join&amp;#x201D;. Now, the &amp;#x201C;JOINs are evil&amp;#x201D; thing is a bit of a myth, at least if you&amp;#x2019;re using a grown-up database, but it&amp;#x2019;s clear that the first query is a lot cheaper than the second.ways\n\nThis gets even worse if you&amp;#x2019;ve got multiple levels of interitance.\n
  • So consider what happens when you do queries.\n\nNow there&amp;#x2019;s a &amp;#x201C;hidden join&amp;#x201D;. Now, the &amp;#x201C;JOINs are evil&amp;#x201D; thing is a bit of a myth, at least if you&amp;#x2019;re using a grown-up database, but it&amp;#x2019;s clear that the first query is a lot cheaper than the second.ways\n\nThis gets even worse if you&amp;#x2019;ve got multiple levels of interitance.\n
  • But here&amp;#x2019;s where it gets really bad -- people *want* base classes to automatically &amp;#x201C;narrow&amp;#x201D; themselves to the appropriate subclass, but this isn&amp;#x2019;t something Django&amp;#x2019;s ORM can do. Indeed, ORMs that *can* do this (Hibernate, SQLA probably) can&amp;#x2019;t do it efficiently.\n
  • But here&amp;#x2019;s where it gets really bad -- people *want* base classes to automatically &amp;#x201C;narrow&amp;#x201D; themselves to the appropriate subclass, but this isn&amp;#x2019;t something Django&amp;#x2019;s ORM can do. Indeed, ORMs that *can* do this (Hibernate, SQLA probably) can&amp;#x2019;t do it efficiently.\n
  • But here&amp;#x2019;s where it gets really bad -- people *want* base classes to automatically &amp;#x201C;narrow&amp;#x201D; themselves to the appropriate subclass, but this isn&amp;#x2019;t something Django&amp;#x2019;s ORM can do. Indeed, ORMs that *can* do this (Hibernate, SQLA probably) can&amp;#x2019;t do it efficiently.\n
  • But here&amp;#x2019;s where it gets really bad -- people *want* base classes to automatically &amp;#x201C;narrow&amp;#x201D; themselves to the appropriate subclass, but this isn&amp;#x2019;t something Django&amp;#x2019;s ORM can do. Indeed, ORMs that *can* do this (Hibernate, SQLA probably) can&amp;#x2019;t do it efficiently.\n
  • But here&amp;#x2019;s where it gets really bad -- people *want* base classes to automatically &amp;#x201C;narrow&amp;#x201D; themselves to the appropriate subclass, but this isn&amp;#x2019;t something Django&amp;#x2019;s ORM can do. Indeed, ORMs that *can* do this (Hibernate, SQLA probably) can&amp;#x2019;t do it efficiently.\n
  • But here&amp;#x2019;s where it gets really bad -- people *want* base classes to automatically &amp;#x201C;narrow&amp;#x201D; themselves to the appropriate subclass, but this isn&amp;#x2019;t something Django&amp;#x2019;s ORM can do. Indeed, ORMs that *can* do this (Hibernate, SQLA probably) can&amp;#x2019;t do it efficiently.\n
  • But here&amp;#x2019;s where it gets really bad -- people *want* base classes to automatically &amp;#x201C;narrow&amp;#x201D; themselves to the appropriate subclass, but this isn&amp;#x2019;t something Django&amp;#x2019;s ORM can do. Indeed, ORMs that *can* do this (Hibernate, SQLA probably) can&amp;#x2019;t do it efficiently.\n
  • But here&amp;#x2019;s where it gets really bad -- people *want* base classes to automatically &amp;#x201C;narrow&amp;#x201D; themselves to the appropriate subclass, but this isn&amp;#x2019;t something Django&amp;#x2019;s ORM can do. Indeed, ORMs that *can* do this (Hibernate, SQLA probably) can&amp;#x2019;t do it efficiently.\n
  • But here&amp;#x2019;s where it gets really bad -- people *want* base classes to automatically &amp;#x201C;narrow&amp;#x201D; themselves to the appropriate subclass, but this isn&amp;#x2019;t something Django&amp;#x2019;s ORM can do. Indeed, ORMs that *can* do this (Hibernate, SQLA probably) can&amp;#x2019;t do it efficiently.\n
  • But here&amp;#x2019;s where it gets really bad -- people *want* base classes to automatically &amp;#x201C;narrow&amp;#x201D; themselves to the appropriate subclass, but this isn&amp;#x2019;t something Django&amp;#x2019;s ORM can do. Indeed, ORMs that *can* do this (Hibernate, SQLA probably) can&amp;#x2019;t do it efficiently.\n
  • So maybe you try something like this to scope things down. Now you&amp;#x2019;re doing O(N) queries.\n
  • \n
  • One of the simplest performance metrics is the number of RTs between your web servers and the db server. As a rule of thumb, you can kinda assume that all queries take roughly the same time; it&amp;#x2019;s the network round-trip that kills you. Remember: these queries are done synchronously, so even if the db can do a query in only 1ms this page would still take 1.8seconds to render!\n
  • At this point I hear you saying &amp;#x201C;but this *is* a legitimate business need!&amp;#x201D;\n\nSo give everything a creation date. Do 3 queries (Animal, Veg, Min) and then combine the lists.\n
  • At this point I hear you saying &amp;#x201C;but this *is* a legitimate business need!&amp;#x201D;\n\nSo give everything a creation date. Do 3 queries (Animal, Veg, Min) and then combine the lists.\n
  • One of Simon&amp;#x2019;s favorite quips. Also known as &amp;#x201C;KISS&amp;#x201D; and a bunch of other things, but what I like about this particular formulation is the word &amp;#x201C;possibly&amp;#x201D;. It&amp;#x2019;s not &amp;#x201C;do the simple thing that you know will work&amp;#x201D;; it&amp;#x2019;s &amp;#x201C;do something that *could* work&amp;#x201D;. If it doesn&amp;#x2019;t, *then* you can get more complex.\n\nDjango does not lend itself very well to overengineering. Keep it small, keep it simple, keep it clean.\n
  • If you need to get fancy -- you&amp;#x2019;ve got 60 kinds of content you need to interleave -- then it&amp;#x2019;s time to denormalize.\n
  • Pattern/anti-pattern 3: not understanding PYTHONPATH.\n\nI see a *huge* amount of confusion about imports and the python path.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Brief explanation of what pythonpath is and how imports work, kinda.\n
  • Consider, a basic project - very simple, just one app.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • sadly, manage.py lets you access your models under two separate paths, and this causes no end of confusion.\n
  • How you know you&amp;#x2019;re getting bitten by this.\n
  • The problem: manage.py is broken. It adds &amp;#x201C;.&amp;#x201D; and &amp;#x201C;..&amp;#x201D; to PYTHONPATH. It does this to make the tutorial easier, and to prevent having to explain PYTHONPATH to new django users, but this was a mistake.\n
  • Always use app-imports: this makes it easy to spin apps out of the project if you need to.\n\nTry to use relative imports if you&amp;#x2019;re on 2.5 or higher -- really really makes this easier.\n\nDelete manage.py.\n
  • Wait, if I delete manage.py how do I interact with my app?\n\nUse django-admin.py.\n\nThis doesn&amp;#x2019;t do the pythonpath malarky -- you have to be explicit!\n\nThis --settings thing is important for a semi-related reason; make a note for later.\n
  • Wait, if I delete manage.py how do I interact with my app?\n\nUse django-admin.py.\n\nThis doesn&amp;#x2019;t do the pythonpath malarky -- you have to be explicit!\n\nThis --settings thing is important for a semi-related reason; make a note for later.\n
  • Wait, if I delete manage.py how do I interact with my app?\n\nUse django-admin.py.\n\nThis doesn&amp;#x2019;t do the pythonpath malarky -- you have to be explicit!\n\nThis --settings thing is important for a semi-related reason; make a note for later.\n
  • Wait, if I delete manage.py how do I interact with my app?\n\nUse django-admin.py.\n\nThis doesn&amp;#x2019;t do the pythonpath malarky -- you have to be explicit!\n\nThis --settings thing is important for a semi-related reason; make a note for later.\n
  • Wait, if I delete manage.py how do I interact with my app?\n\nUse django-admin.py.\n\nThis doesn&amp;#x2019;t do the pythonpath malarky -- you have to be explicit!\n\nThis --settings thing is important for a semi-related reason; make a note for later.\n
  • Wait, if I delete manage.py how do I interact with my app?\n\nUse django-admin.py.\n\nThis doesn&amp;#x2019;t do the pythonpath malarky -- you have to be explicit!\n\nThis --settings thing is important for a semi-related reason; make a note for later.\n
  • Wait, if I delete manage.py how do I interact with my app?\n\nUse django-admin.py.\n\nThis doesn&amp;#x2019;t do the pythonpath malarky -- you have to be explicit!\n\nThis --settings thing is important for a semi-related reason; make a note for later.\n
  • Wait, if I delete manage.py how do I interact with my app?\n\nUse django-admin.py.\n\nThis doesn&amp;#x2019;t do the pythonpath malarky -- you have to be explicit!\n\nThis --settings thing is important for a semi-related reason; make a note for later.\n
  • Wait, if I delete manage.py how do I interact with my app?\n\nUse django-admin.py.\n\nThis doesn&amp;#x2019;t do the pythonpath malarky -- you have to be explicit!\n\nThis --settings thing is important for a semi-related reason; make a note for later.\n
  • You can automate most of this with virtualenv, and it&amp;#x2019;s kinda great.\n
  • Lastly, I&amp;#x2019;ll talk a bit about settings. I see people doing the craziest stuff with settings...\n\n(and urls - urls are a special form of setting)\n
  • Not too bad... but it *does* defeat the whole purpose of INSTALLED_APPS. The point is to be explicit about what&amp;#x2019;s loaded. Django&amp;#x2019;s trying to make sure you&amp;#x2019;re only using what&amp;#x2019;s needed. If you circumvent this, things start randomly breaking when you make directories.\n\nI even saw this become a security hole: they allowed uploads into a media/ directory, and I uploaded a &amp;#x201C;models.py&amp;#x201D;. Oops.\n
  • Then it gets more crazy. People do stuff like this to dynamically load urls because apparently adding a line to urls.py is too much work...\n
  • ... and even scary stuff like there.\n\nThere&amp;#x2019;s actually a couple of bugs here; they&amp;#x2019;re left as exercises to the reader.\n
  • \n
  • There&amp;#x2019;s no good reason not to just make settings simple data structures.\n
  • There&amp;#x2019;s no good reason not to just make settings simple data structures.\n
  • The problem: differences between development (mac laptop), testing (ci), staging, production.\n\nI see lots of unneeded complexity here, too. What&amp;#x2019;s the most Django-esque, least magical solution?\n
  • This is a very common pattern, and it needs to die.\n
  • Here&amp;#x2019;s how you explain the pattern. Anyone see what&amp;#x2019;s wrong?\n
  • There are other reasons why this pattern sucks -- e.g. since you&amp;#x2019;re importing overrides into the &amp;#x201C;base&amp;#x201D;, you can&amp;#x2019;t do stuff like &amp;#x201C;INSTALLED_APPS.append()&amp;#x201D;. But EVERYTHING GOES IN SOURCE CONTROL!\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • One of Simon&amp;#x2019;s favorite quips. Also known as &amp;#x201C;KISS&amp;#x201D; and a bunch of other things, but what I like about this particular formulation is the word &amp;#x201C;possibly&amp;#x201D;. It&amp;#x2019;s not &amp;#x201C;do the simple thing that you know will work&amp;#x201D;; it&amp;#x2019;s &amp;#x201C;do something that *could* work&amp;#x201D;. If it doesn&amp;#x2019;t, *then* you can get more complex.\n\nDjango does not lend itself very well to overengineering. Keep it small, keep it simple, keep it clean.\n
  • \n
  • ×