Downloaded 54 times
Uploaded byAdam Haney
Django best practices
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
- 1.
- 2. Disclaimer ● This talkshould 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 onpersonal 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 onpersonal 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
- 5.
- 6.
- 7. README ● Your projectshould 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)
- 8.
- 9. Requirements ● We usepip, with pretty results ● Pin your versions
- 10.
- 11. Continuous Integration ● Runyour tests regularly ● We use circleci ○ Pretty simple ○ Integrates with github ○ still working out their own bugs ● Other options ○ Buildbot ○ Jenkins ○ TravisCI ○ Codeship.io
- 12.
- 13. Fabric ● Useful fordeployment to remote machines ○ Supports parallel remote execution ● Nice python replacement for ○ Bash scripts ○ Makefiles ○ Duct Tape
- 14.
- 15. Things that shouldn'tbe in the REPO ● Generated Files ● Data files ● .pyc files ● Backup files ● Cat pictures ○ Ok, maybe cat pictures
- 16.
- 17. virtualenv ● Oh mygod use it ● Keeps your projects from stepping on each other ● World Peace ● Kittens
- 18.
- 19. Documentation ● IMHO lotsof docs in the root make a project hard to navigate ● Plaintext format that can generate html docs preferred ○ ReStructured Text ○ Sphinx
- 20.
- 21. Project Configuration ● Non-sensitiveconfiguration files ● Avoid putting these in root, again hierarchical structure
- 22.
- 23. Newrelic ● Makes mylife so much better ● Monitoring ○ Exceptions ○ Response Time / Profiling ○ Database profiling ● Alternatives ○ Sentry (FOSS) ○ App Dynamics
- 24.
- 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')) )
- 26.
- 27. WSGI ● How yourwebserver actually hooks into your app ● WSGI middlewares can go here ○ Haven't ever found a user for them
- 28.
- 29. Settings ● Recently we'vestarted 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
- 30.
- 31. Unpackaged dependencies ● Wheneverpossible 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
- 32.
- 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
- 34.
- 35. Django Applications ● Re-usuableapps make Django awesome ○ Use relative imports ○ Try to not include anything project specific ● Combine / split projects ○ Possible with proper organization :)
- 36.
- 37. Application Tests ● Youshould 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
- 38.
- 39. Models ● Models arethe 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
- 40.
- 41. Application Urls ● Allviews accessible in an app should be bundled into an app level urls file ● Use named url patterns to separate patterns from controllers.
- 42.
- 43. Django Admin ● Majorwin ● Use django admin for as much as you can ● Most aspects are subclassable/extentable ● Your business guys don't need shiny UI
- 44.
- 45. Application Views ● Makethe 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
- 46.
- 47. Tasty Pie ● Don'tre-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.
- 48.
- 49. Background / Asyncin 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 beyour 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
- 51.
- 52. Django Forms ● ModelForms ○ DRY ○ Handles validation in a declarative way ○ Will make your life better ● Django crispy forms ○ More control
- 53.
- 54. South ● Reproducible migrations ○Schema migrations ○ Data migrations ○ Test runner ○ Probably going to be included in Django 1.6 ○ Migration dependencies can be defined
- 55.
- 56. Management Commands ● Weused to use these for cron jobs ○ Celery beat is nicer now ● Helpful for project wide scripts that require django context
- 57.
- 58. Static Files ● Namespaceyour static files ○ app_name/static/app_name ○ avoids collisions ○ common static files can go in the base of the project
- 59.
- 60. Application templates ● Sameas 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 youshould be aware of ● Middlewares ● Class Based Views ● Template Context Processors ● Custom Template Tags
- 62. Django Apps thatmake me happy ● Django Extensions ○ Werkzeug ● South ○ Probably coming to Django 1.6
- 63. Tools you shoulduse ● Code Quality ○ PEP8 ○ Pyflakes ○ Pychecker ○ jshint ○ jslint ● Development Environment ○ ack-grep ○ emacs :) ● Infrastructure ○ PGbouncer
- 64. What did Iforget?