Moving Targets
- wolf/coyote/fox - the two ends of the spectrum ignore each other, but close things fight
- Similarly, the biggest rivalries will be between the most similar technologies (eg vi/emacs or vi/visual studio)
- the biggest arguments tend to be over the smallest differences
a moving target
- fixes problems
- adds missing features
- invalidates my complaints
Django has done a great job of being a moving target
- url mappers
- template systems
- ORMs
TemplateResponse (Django 1.3)
- request -> data -> document
- request -> data : build nested dicts/lists, in python, auth ...
- data -> document : template, interpolate data, for loops, HTML ...
- old state of the art - integration test, tested both together - compound, fragile, late
- another approach: request -> data (programmer/python test) data -> document (designer/browser test)
- became possible with TemplateResponse (1.3)
- so your view data becomes a first-class result (and can be used in debugging/testing)
- lets you write tests on day one that specify what the context will look like
- view tests: db1 -> context1, db2 -> context2 ...
- design tests: context-a -> page-a, context-b -> page-b ...
- ALSO, TemplateResponse can be modified by decorators, middleware -> less codeo
Persistent db connections (Django 1.6)
- by default Django opens a new db connection for every view it renders
- settings.py: CONN_MAX_AGE = 600 (off by default)
- skip 3-way tcp/ip handshake, skip auth
- reduce load on DB
Transactions - changes in 1.6
- if db is “serializable”, you need to commit after a read before you see new data(!)
- autocommit now default for both reads and writes
- txn must be explicit
1.7 has built in data migration
If I am not careful, my opinions tend to fossilize