Django In The Real World
by Jacob Kaplan-Moss on Jul 21, 2009
- 8,324 views
There’s plenty of material (documentation, blogs, books) out there that’ll help you write a site using Django… but then what? You’ve still got to test, deploy, monitor, and tune the site; failu...
There’s plenty of material (documentation, blogs, books) out there that’ll help you write a site using Django… but then what? You’ve still got to test, deploy, monitor, and tune the site; failure at deployment time means all your beautiful code is for naught.
This tutorial examines how best to cope when the Real World intrudes on your carefully designed website.
Accessibility
Categories
Tags
More...Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 44
- Downloads
- 0
- Comments
- 1
- Embed Views
- Views on SlideShare
- 7,480
- Total Views
- 8,324
1–1 of 1 previous next
I wear quite a few hats. Today, I’m wearing two: I’m one of the lead developers of Django; I’m a partner at `Revolution Systems`__, a consulting business specializing in, well, the stuff I’m about to talk about.
__ http://b-list.org/
Writing the app is the easy part; what comes next is seriously complicated.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
Obviously this is far too much to cover even in a long tutorial, so we’ll pick and choose; the point is that writing the app is usually the easy part. Today we’re talking about what comes next.
* You need to test your sites. Without tests, you can’t move forward without downtime.
* You need to write your code in a way that makes deployment possible — and easy.
* You need to use deployment tools that automate the repetitive bits and keep you from shooting yourself in the foot.
* You need a production environment that scales with your traffic.
* You need to watch your sites in action so that you know what’s up.
* When things go slow you need to fix it.
* You need to test your sites. Without tests, you can’t move forward without downtime.
* You need to write your code in a way that makes deployment possible — and easy.
* You need to use deployment tools that automate the repetitive bits and keep you from shooting yourself in the foot.
* You need a production environment that scales with your traffic.
* You need to watch your sites in action so that you know what’s up.
* When things go slow you need to fix it.
* You need to test your sites. Without tests, you can’t move forward without downtime.
* You need to write your code in a way that makes deployment possible — and easy.
* You need to use deployment tools that automate the repetitive bits and keep you from shooting yourself in the foot.
* You need a production environment that scales with your traffic.
* You need to watch your sites in action so that you know what’s up.
* When things go slow you need to fix it.
* You need to test your sites. Without tests, you can’t move forward without downtime.
* You need to write your code in a way that makes deployment possible — and easy.
* You need to use deployment tools that automate the repetitive bits and keep you from shooting yourself in the foot.
* You need a production environment that scales with your traffic.
* You need to watch your sites in action so that you know what’s up.
* When things go slow you need to fix it.
* You need to test your sites. Without tests, you can’t move forward without downtime.
* You need to write your code in a way that makes deployment possible — and easy.
* You need to use deployment tools that automate the repetitive bits and keep you from shooting yourself in the foot.
* You need a production environment that scales with your traffic.
* You need to watch your sites in action so that you know what’s up.
* When things go slow you need to fix it.
* You need to test your sites. Without tests, you can’t move forward without downtime.
* You need to write your code in a way that makes deployment possible — and easy.
* You need to use deployment tools that automate the repetitive bits and keep you from shooting yourself in the foot.
* You need a production environment that scales with your traffic.
* You need to watch your sites in action so that you know what’s up.
* When things go slow you need to fix it.
The “fear” that Beck is talking about here is the fear of not knowing if your new site will run or not. Testing, while often boring, relives you of that fear.
__ http://www.amazon.com/dp/0321146530/
Yes, this leaves you with less than perfect coverage.
Ruby on Rails really changed the game, though. When it shipped a set of tools that took most of the pain out of automating web tests, it galvenized developers to compete.
Django’s since come out with our own spin on this set of tools. I’m only going to cover doctests in this intro tutorial, so a brief overview of the other tools is in order:
* Unit tests: Django can run tests using Python’s standard `unittest` framework, which is based on Java’s JUnit. Perfect for more formal unit tests like you’d see in Java/C#.
* Fixtures: fixtures are a way of loading preset data into the database for each test, thus letting you test against “real” data.
* The test client: this lets you “fake” a request to your views and inspect the returned response, template, and context.
* Email capture: the test suite will intercept sent email so you can test logic involving email.
Ruby on Rails really changed the game, though. When it shipped a set of tools that took most of the pain out of automating web tests, it galvenized developers to compete.
Django’s since come out with our own spin on this set of tools. I’m only going to cover doctests in this intro tutorial, so a brief overview of the other tools is in order:
* Unit tests: Django can run tests using Python’s standard `unittest` framework, which is based on Java’s JUnit. Perfect for more formal unit tests like you’d see in Java/C#.
* Fixtures: fixtures are a way of loading preset data into the database for each test, thus letting you test against “real” data.
* The test client: this lets you “fake” a request to your views and inspect the returned response, template, and context.
* Email capture: the test suite will intercept sent email so you can test logic involving email.
Ruby on Rails really changed the game, though. When it shipped a set of tools that took most of the pain out of automating web tests, it galvenized developers to compete.
Django’s since come out with our own spin on this set of tools. I’m only going to cover doctests in this intro tutorial, so a brief overview of the other tools is in order:
* Unit tests: Django can run tests using Python’s standard `unittest` framework, which is based on Java’s JUnit. Perfect for more formal unit tests like you’d see in Java/C#.
* Fixtures: fixtures are a way of loading preset data into the database for each test, thus letting you test against “real” data.
* The test client: this lets you “fake” a request to your views and inspect the returned response, template, and context.
* Email capture: the test suite will intercept sent email so you can test logic involving email.
Ruby on Rails really changed the game, though. When it shipped a set of tools that took most of the pain out of automating web tests, it galvenized developers to compete.
Django’s since come out with our own spin on this set of tools. I’m only going to cover doctests in this intro tutorial, so a brief overview of the other tools is in order:
* Unit tests: Django can run tests using Python’s standard `unittest` framework, which is based on Java’s JUnit. Perfect for more formal unit tests like you’d see in Java/C#.
* Fixtures: fixtures are a way of loading preset data into the database for each test, thus letting you test against “real” data.
* The test client: this lets you “fake” a request to your views and inspect the returned response, template, and context.
* Email capture: the test suite will intercept sent email so you can test logic involving email.
Ruby on Rails really changed the game, though. When it shipped a set of tools that took most of the pain out of automating web tests, it galvenized developers to compete.
Django’s since come out with our own spin on this set of tools. I’m only going to cover doctests in this intro tutorial, so a brief overview of the other tools is in order:
* Unit tests: Django can run tests using Python’s standard `unittest` framework, which is based on Java’s JUnit. Perfect for more formal unit tests like you’d see in Java/C#.
* Fixtures: fixtures are a way of loading preset data into the database for each test, thus letting you test against “real” data.
* The test client: this lets you “fake” a request to your views and inspect the returned response, template, and context.
* Email capture: the test suite will intercept sent email so you can test logic involving email.