The best (and worst) of Django

Slide 1

Slide 1 text

The best (and worst) of Django [email protected] http://lanyrd.com/sgbwt/

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

1,215,616

Slide 6

Slide 6 text

Public Enemy #1: Over-engineering.

Slide 7

Slide 7 text

ˑ ˑ “Do the simplest thing that could possibly work.” — Simon Willison

Slide 8

Slide 8 text

Small is beautiful

Slide 9

Slide 9 text

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. The monolith monster

Slide 10

Slide 10 text

(I blame Rails.)

Slide 11

Slide 11 text

“It’s a pretty simple site; about ﬁfteen or twenty thousand lines of code…”

Slide 12

Slide 12 text

site_of_unspeakable_horrors !"" settings.py !"" urls.py !"" views.py #"" models.py

Slide 13

Slide 13 text

models.py — 2,800 lines views.py — 11,900 lines

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

ˑ Big is bad; Small is beautiful.

Slide 16

Slide 16 text

The Django mindset: Application: some bit of functionality. Site: several applications. Spin off new apps liberally. A suite of apps ready for use.

Slide 17

Slide 17 text

! ! ! " # ! $ ! " % & & ' ! ( ) * + ! %+ , & -

Slide 18

Slide 18 text

There’s no such thing as “content.”

Slide 19

Slide 19 text

XXX screenshot: “content” box

Slide 20

Slide 20 text

ˑ Django is an un-CMS.

Slide 21

Slide 21 text

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.

Slide 22

Slide 22 text

The “everything-is-a…” anti-pattern

Slide 23

Slide 23 text

“Everything needs a creation date.”

Slide 24

Slide 24 text

class BaseObject(models.Model): creation_date = models.DateField() … class Animal(BaseObject): … class Vegetable(BaseObject): … class Mineral(BaseObject): …

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

Without a concrete base class: >>> Animal.objects.all()

Slide 27

Slide 27 text

Without a concrete base class: >>> Animal.objects.all() SELECT ... FROM animal;

Slide 28

Slide 28 text

Without a concrete base class: >>> Animal.objects.all() SELECT ... FROM animal; With a concrete base class: >>> Animal.objects.all()

Slide 29

Slide 29 text

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")

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

What you want: >>> BaseObject.objects.all() [, , , ...]

Slide 32

Slide 32 text

What you want: >>> BaseObject.objects.all() [, , , ...] What you get: >>> BaseObject.objects.all() [, , , ...]

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

“Our site worked ﬁne in development and testing, and was working wonderfully for the ﬁrst few months. “But we just added a bunch more data, and now our homepage takes 27 seconds to load.”

Slide 35

Slide 35 text

1,800 queries

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

“But… but… everything really does need a creation date!”

Slide 38

Slide 38 text

“But… but… everything really does need a creation date!” So give everything a creation date.

Slide 39

Slide 39 text

ˑ ˑ “Do the simplest thing that could possibly work.” — Simon Willison

Slide 40

Slide 40 text

Abstract base classes don’t suﬀer from these performance problems. Denormalize into a UI-ordered auxiliary model. Non-relational databases work particular well here (I like SOLR). If you must get fancy:

Slide 41

Slide 41 text

Those who do not understand PYTHONPATH are doomed to failure.

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

>>> 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', ...]

Slide 44

Slide 44 text

Slide 45

Slide 45 text

~/Projects/djdash !"" __init__.py !"" dashboard $ !"" __init__.py $ !"" admin.py $ !"" models.py $ #"" views.py #"" manage.py (https://github.com/jacobian/django-dev-dashboard)

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

$ ./manage.py shell

Slide 48

Slide 48 text

$ ./manage.py shell >>> import dashboard.models

Slide 49

Slide 49 text

$ ./manage.py shell >>> import dashboard.models >>> dashboard.models

Slide 50

Slide 50 text

$ ./manage.py shell >>> import dashboard.models >>> dashboard.models

Slide 51

Slide 51 text

$ ./manage.py shell >>> import dashboard.models >>> dashboard.models >>> import djdash.dashboard.models

Slide 52

Slide 52 text

$ ./manage.py shell >>> import dashboard.models >>> dashboard.models >>> import djdash.dashboard.models >>> djdash.dashboard.models

Slide 53

Slide 53 text

$ ./manage.py shell >>> import dashboard.models >>> dashboard.models >>> import djdash.dashboard.models >>> djdash.dashboard.models >>> djdash.dashboard.models.Metric is dashboard.models.Metric

Slide 54

Slide 54 text

$ ./manage.py shell >>> import dashboard.models >>> dashboard.models >>> import djdash.dashboard.models >>> djdash.dashboard.models >>> djdash.dashboard.models.Metric is dashboard.models.Metric False

Slide 55

Slide 55 text

“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!” You might have an import issue if…

Slide 56

Slide 56 text

Django is wrong! (I’m sorry.)

Slide 57

Slide 57 text

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.

Slide 58

Slide 58 text

Delete manage.py?

Slide 59

Slide 59 text

$ django-‐admin.py shell -‐-‐pythonpath=`pwd` -‐-‐settings=settings.local Delete manage.py?

Slide 60

Slide 60 text

$ django-‐admin.py shell -‐-‐pythonpath=`pwd` -‐-‐settings=settings.local >>> import dashboard.models Delete manage.py?

Slide 61

Slide 61 text

$ django-‐admin.py shell -‐-‐pythonpath=`pwd` -‐-‐settings=settings.local >>> import dashboard.models >>> import djdash.dashboard.models Delete manage.py?

Slide 62

Slide 62 text

$ 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 Delete manage.py?

Slide 63

Slide 63 text

Slide 64

Slide 64 text

$ 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 For virtualenv users:

Slide 65

Slide 65 text

Keep (your settings) simple.

Slide 66

Slide 66 text

INSTALLED_APPS += [p for p in os.listdir(BASE) if os.path.isdir(p)] Don’t do this …

Slide 67

Slide 67 text

urlpatterns = patterns('', ...) for app in settings.INSTALLED_APPS: if not app.startswith('django'): p = url('^%s/' % app, include('%s.urls') % app) urlpatterns += patterns('', p) … or this …

Slide 68

Slide 68 text

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) … or this.

Slide 69

Slide 69 text

ˑ Python’s design is predicated on the proposition that code is more often read than written.

Slide 70

Slide 70 text

Slide 71

Slide 71 text

INSTALLED_APPS = ( 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'django.contrib.admin', 'django.contrib.flatpages', 'django_extensions', 'debug_toolbar', 'south', 'rs.users', 'rs.orgs', 'rs.signup', 'rs.clients', 'rs.timezones', 'rs.caregivers', 'rs.dashboard', 'rs.scripts', 'rs.reminders', 'rs.billing', 'rs.calls', 'chunks', 'contact_form', ) urlpatterns = patterns('', url(r'âdmin/', include(admin.site.urls)), url(r'^signup/', include('rs.signup.urls')), url(r'ôrg/', include('rs.orgs.urls')), url(r'^clients/', include('rs.clients.urls')), url(r'^caregivers/', include('rs.caregivers.urls')), url(r'âccount/', include('rs.users.urls')), url(r'^dashboard/', include('rs.dashboard.urls')), url(r'^reminders/', include('rs.reminders.urls')), url(r'^calls/', include('rs.calls.urls')), url(r'^scripts/', include('rs.scripts.urls')), url(r'^contact/', include('contact_form.urls')), url(r'^login/', 'django.contrib.auth.views.login', {}, 'login'), url(r'^logout/$', 'django.contrib.auth.views.logout', {}, 'logout',), url(r'^changepassword/$', 'django.contrib.auth.views.password_change') )

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Multiple settings files

Slide 74

Slide 74 text

At the bottom of your settings ﬁle: try: from local_settings import * except ImportError: pass The localsettings anti-pattern

Slide 75

Slide 75 text

“It’s simple: just create a local_settings.py, throw overridden settings in there, and then never check the ﬁle into source control.”

Slide 76

Slide 76 text

“It’s simple: just create a local_settings.py, throw overridden settings in there, and then never check the file into source control.”

Slide 77

Slide 77 text

Handling multiple settings files

Slide 78

Slide 78 text

1. Don’t. Why is your staging environment diﬀerent from production? Handling multiple settings files

Slide 79

Slide 79 text

1. Don’t. Why is your staging environment diﬀerent from production? 2. Use DJANGO_SETTINGS_MODULE. Handling multiple settings files

Slide 80

Slide 80 text

settings !"" __init__.py !"" base.py !"" staging.py !"" production.py #"" local.py The one true way

Slide 81

Slide 81 text

Slide 82

Slide 82 text

settings !"" __init__.py !"" base.py !"" staging.py !"" production.py #"" local.py The one true way # base.py INSTALLED_APPS = [...] # local.py from settings.base import * INSTALLED_APPS += ['debug_toolbar'] $ django-‐admin.py shell -‐-‐settings=settings.local