Finished pass thru 23

Author: hjwp

chapter_20_mocking_1.asciidoc

@@ -797,7 +797,7 @@ Something like this:
 
       {% if messages %}
         <div class="row">
-          <div class="col-md-8">
+          <div class="col-md-12">
             {% for message in messages %}
               {% if message.level_tag == 'success' %}
                 <div class="alert alert-success">{{ message }}</div>
@@ -811,6 +811,7 @@ Something like this:
 ----
 ====
 
+// TODO: feed thru change
 
 Now do we get a little further?  Yes!
 

chapter_23_debugging_prod.asciidoc

@@ -1,5 +1,5 @@
 [[chapter_23_debugging_prod]]
-== Debugging And Testing Production Issues
+== Debugging And Testing Server Issues
 
 .A Note for Early Release Readers
 ****
@@ -28,25 +28,6 @@ Ah yes, we had just built a way of pre-authenticating a user.
 Let's see how that works against Docker and our staging server.
 
 
-////
-SEBASTIAN:
-It's worth reiterating the testing strategy in the real world. The chapter is
-called "Debugging And Testing Production Issues" yet it focuses on running
-tests against another non-production environment. It uses methods which I find
-a bit controversial because they don't treat the staging environment as a black
-box.
-
-
-DAVID:
-Nice one. I particularly liked the discussion of when to choose not to test
-something, in this case email.
-
-I do think we should talk a little more about security here - readers should
-adopt a security mindset when doing things like this and make sure they think
-things through.
-////
-
-
 
 === The Proof Is in the Pudding: Using Docker to Catch Final Bugs
 
@@ -1089,11 +1070,13 @@ $ pass:quotes[*TEST_SERVER=localhost:8888 python src/manage.py test functional_t
 OK
 ----
 
-// DAVID: Shall we do a git commit?
+Probably a good time for a commit :)
+
 
 [role="pagebreak-before less_space"]
 .Warning: Be Careful Not to Run Test Code Against the Production Server!
 *******************************************************************************
+
 ((("database testing", "safeguarding production databases")))
 ((("production databases")))
 We're into dangerous territory,
@@ -1103,53 +1086,57 @@ that you don't accidentally blow away your production database
 by running FTs against the wrong host.
 
 You might consider putting some safeguards in place at this point.
-For example, you could put staging and production on different servers,
+You almost definitely want to put staging and production on different servers, for example,
 and make it so they use different keypairs for authentication, with different passphrases.
 
-// DAVID: Or maybe something simpler like quitting if the host isn't in an allow-list?
+I also mentioned not including the FT management commands in INSTALLED_APPS
+for production environments.
 
 This is similarly dangerous territory to running tests against clones of production data.
-I have a little story about accidentally sending thousands of duplicate invoices to clients
-in <<data-migrations-appendix>>. LFMF!
+I could tell you a little story about accidentally sending thousands of
+duplicate invoices to clients for example. LFMF!  And tread carefully.
 
 *******************************************************************************
 
 
 === Wrap-Up
 
-Actually getting your new code up and running on a server always tends to
-flush out some last-minute bugs and unexpected issues.  We had to do a bit
-of work to get through them, but we've ended up with several useful things
-as a result.
+Actually getting your new code up and running on a server
+always tends to flush out some last-minute bugs and unexpected issues.
+We had to do a bit of work to get through them,
+but we've ended up with several useful things as a result.
 
-We now have a lovely generic `wait` decorator which will be a nice Pythonic
-helper for our FTs from now on.  We have test fixtures that work both
-locally and on the server, including the ability to test "real" email
-integration. And we've got some more robust logging configuration.
+We now have a lovely generic `wait` decorator
+which will be a nice Pythonic helper for our FTs from now on.
+We've got some more robust logging configuration.
+We have test fixtures that work both locally and on the server,
+and we've come out with a pragmatic approach to testing email integration.
 
-But before we can deploy our actual live site, we'd better actually give the
-users what they wanted--the next chapter describes how to give them
+But before we can deploy our actual production site,
+we'd better actually give the users what they wanted--the
+next chapter describes how to give them
 the ability to save their lists on a "My Lists" page.
 
 
 .Lessons Learned Catching Bugs in Staging
 *******************************************************************************
 
+It's nice to be able to repro things locally::
+    The effort we put into adapting our app to use Docker is paying off.
+    We discovered an issue in staging, and were able to reproduce it locally.
+    That gives us the ability to experiment and get feedback much quicker,
+    than trying to do experiments on the server itself.
+
 Fixtures also have to work remotely::
     `LiveServerTestCase` makes it easy to interact with the test database
-    using the Django ORM for tests running locally.  Interacting with the
-    database inside Docker is not so straightforward. One solution
-    is `docker exec` and Django management commands, as I've shown, but you should
-    explore what works for you--SSH tunnels, for example.
+    using the Django ORM for tests running locally.
+    Interacting with the database inside Docker is not so straightforward.
+    One solution is `docker exec` and Django management commands,
+    as I've shown, but you should explore what works for you--connecting
+    directly to the DB over SSH tunnels, for example.
     ((("fixtures", "staging and")))
     ((("staging sites", "fixtures and")))
 
-// SEBASTIAN: I am wondering how strongly this approach should be recommended.
-// In my mind, when one tests a service remotely, it would be a black-box testing
-// without SSH-ing into it. The chapter is called "debugging prod", though.
-// Then this is about debugging prod-like issues on staging?
-// Some reiteration or additional context in diagrams could help.
-
 Be very careful when resetting data on your servers::
     A command that can remotely wipe the entire database on one of your
     servers is a dangerous weapon, and you want to be really, really sure
@@ -1159,9 +1146,10 @@ Be very careful when resetting data on your servers::
 
 Logging is critical to debugging issues on the server::
     At the very least, you'll want to be able to see any error messages
-    that are being generated by the server.  For thornier bugs, you'll also
-    want to be able to do the occasional "debug print", and see it end up
-    in a file somewhere.
+    that are being generated by the server.
+    For thornier bugs,
+    you'll also want to be able to do the occasional "debug print",
+    and see it end up in a file somewhere.
     ((("logging")))
     ((("debugging", "server-side", "baking in logging code")))