Django best practices
15 likes3,386 views
The document provides an overview of best practices for structuring Django projects and applications. It recommends organizing projects with a README, requirements, configuration files, and virtual environments separated from application code. Applications should be modular with tests, models, views, templates, and other components separated. It also provides guidance on continuous integration, deployment, documentation, and other tools like Celery, TastyPie, and Django admin that can improve maintainability and development workflow.
Django best practices
- 2. Disclaimer ● This talk should take approximately 1 month ● I don't always take my own advice ● I'm not an expert ● I'm going to forget something ● You have a different opinion than me
- 3. A note on personal philosophy ● Organization makes chaos manageable ○ PEP8 ○ Code standards ○ DRY ○ Hierarchical organization lets me understand what I need to to solve the problem in front of me
- 4. A note on personal philosophy ● Provide value with as few LOC as possible ○ "Everything should be made as simple as possible, but not simpler" ● "Unix Philosophy" ○ Read "The Art of Unix Programming" ○ Things should fail noisily ○ Don't surprise me
- 7. README ● Your project should have a README ○ Seriously ○ You want to go on vacation ● Format it in some way that's easy to read ○ duh ● What should probably be there ○ Installation instructions ○ Design decisions ○ Contribution information (or put this in a Contributing file)
- 9. Requirements ● We use pip, with pretty results ● Pin your versions
- 11. Continuous Integration ● Run your tests regularly ● We use circleci ○ Pretty simple ○ Integrates with github ○ still working out their own bugs ● Other options ○ Buildbot ○ Jenkins ○ TravisCI ○ Codeship.io
- 13. Fabric ● Useful for deployment to remote machines ○ Supports parallel remote execution ● Nice python replacement for ○ Bash scripts ○ Makefiles ○ Duct Tape
- 15. Things that shouldn't be in the REPO ● Generated Files ● Data files ● .pyc files ● Backup files ● Cat pictures ○ Ok, maybe cat pictures
- 17. virtualenv ● Oh my god use it ● Keeps your projects from stepping on each other ● World Peace ● Kittens
- 19. Documentation ● IMHO lots of docs in the root make a project hard to navigate ● Plaintext format that can generate html docs preferred ○ ReStructured Text ○ Sphinx
- 21. Project Configuration ● Non-sensitive configuration files ● Avoid putting these in root, again hierarchical structure
- 23. Newrelic ● Makes my life so much better ● Monitoring ○ Exceptions ○ Response Time / Profiling ○ Database profiling ● Alternatives ○ Sentry (FOSS) ○ App Dynamics
- 25. Root project urls ● If at all possible should only include app's url patterns from django.conf.urls import patterns, url, include urlpatterns = patterns( 'project', url(r'achievements/', include('achievements.urls')) )
- 27. WSGI ● How your webserver actually hooks into your app ● WSGI middlewares can go here ○ Haven't ever found a user for them
- 29. Settings ● Recently we've started using environment variables with some success ● We've also used approaches where we have a settings directory who's __init__.py file determins appropriate settings for environment ● Try to be organized, honestly, just use ENV
- 31. Unpackaged dependencies ● Whenever possible use pip / setuptools ● Put django snippets / projects that aren't in pypi in lib/ ● If you're going to do something dirty try to be organized about it
- 33. Project specific Code ● As much as possible bundle code into reusable apps ● Things that might have to go here ○ Custom test runners ○ Project middlewares ○ Project template context processors ○ Functions that don't make sense elsewhere ○ dbrouters
- 35. Django Applications ● Re-usuable apps make Django awesome ○ Use relative imports ○ Try to not include anything project specific ● Combine / split projects ○ Possible with proper organization :)
- 37. Application Tests ● You should have tests ○ TDD/BDD if possible ○ IMHO your model tests / design give better ROI ○ If you find a bug write a test to reproduce, fix ○ Seriously testing will save you time ○ Really ○ Please
- 39. Models ● Models are the lifeblood of your apps ○ Start with model design first ○ Design your data model well and views will come naturally ● Model Managers are pretty awesome ○ Your views (controllers) should be able to call 1/2 model manager methods in order to get what it needs otherwise code needs to be refactored into a model manager ● Querysets can be subclassed as well ○ can make view / task code much much easier ○ DRY
- 41. Application Urls ● All views accessible in an app should be bundled into an app level urls file ● Use named url patterns to separate patterns from controllers.
- 43. Django Admin ● Major win ● Use django admin for as much as you can ● Most aspects are subclassable/extentable ● Your business guys don't need shiny UI
- 45. Application Views ● Make the views as simple as possible ○ Template views can probably be functions that call render ○ If a view has lots of model calls that code can probably go into a manager ■ Manager are easier to test ■ If managers have lots of interdependencies your data model probably needs to be refactored ● Use django shortcuts when possible ● IMHO template logic is ok to a point if it simplifies view code, but don't go overboard
- 47. Tasty Pie ● Don't re-invent the wheel ● Tastypie is useful for most (but not all) RESTful applications ● The code is already tested ● You don't need as much control over JSON structure as you think. ● This is a separate talk, but be aware of it.
- 49. Background / Async in Django ● There are lots of choices for this ● ZMQ ○ Lots of options for routing ○ VERY flexible ○ VERY fast ○ VERY cool ○ Django z-tasks looks promising ○ BUT ■ Have to write your own workers ■ Have to write your own logging / monitoring ■ Have to understand a fair amount to make it work correctly. ■ SO...
- 50. Celery ● Should be your default choice for async ● Very simple python API ○ Async tasks ○ Tasks in the future ○ Cron replacement ● Workers are already written ● Integrated with new relic ○ Ops have been much easier for us ○ Traceback monitoring major win
- 52. Django Forms ● Model Forms ○ DRY ○ Handles validation in a declarative way ○ Will make your life better ● Django crispy forms ○ More control
- 54. South ● Reproducible migrations ○ Schema migrations ○ Data migrations ○ Test runner ○ Probably going to be included in Django 1.6 ○ Migration dependencies can be defined
- 56. Management Commands ● We used to use these for cron jobs ○ Celery beat is nicer now ● Helpful for project wide scripts that require django context
- 58. Static Files ● Namespace your static files ○ app_name/static/app_name ○ avoids collisions ○ common static files can go in the base of the project
- 60. Application templates ● Same as static files, namespace them ● Use template inheritance ○ DRY ● Use named url patterns in your templates ● Don't go overboard with template logic ○ If you must check out template includes ○ Huge templates are hard to read ● Lots of view code data munging can be replaced with template filters. ● Django templates are really controllers ○ Let templates act like views, handle presentation.
- 61. Other things you should be aware of ● Middlewares ● Class Based Views ● Template Context Processors ● Custom Template Tags
- 62. Django Apps that make me happy ● Django Extensions ○ Werkzeug ● South ○ Probably coming to Django 1.6
- 63. Tools you should use ● Code Quality ○ PEP8 ○ Pyflakes ○ Pychecker ○ jshint ○ jslint ● Development Environment ○ ack-grep ○ emacs :) ● Infrastructure ○ PGbouncer
- 64. What did I forget?