add suggestions on env vs dev environment

- suggestion to rename DJANGO_DEBUG_FALSE
- suggest using non-privileged user in Docker
- mentioning explicitly the dev environment does not rely on Docker
- add reminder to commit changes made to Dockerfile too

Author: Xronophobe

chapter_10_production_readiness.asciidoc

@@ -288,6 +288,9 @@ else:
     SECRET_KEY = "insecure-key-for-dev"
 ----
 ====
+// CSANAD: I think variable names like "something_false" are confusing, since
+//         we need to set something to true so that they mean false.
+// How about `DJANGO_ENV_PRODUCTION` or something similar?
 
 <1> We say we'll use an environment variable called `DJANGO_DEBUG_FALSE`
     to switch debug mode off, and in effect require production settings
@@ -308,6 +311,14 @@ against accidentally forgetting to set one.
 TIP: Better to fail hard than allow a typo in an environment variable name to
     leave you running with insecure settings.
 
+// CSANAD: I think it would worth pointing out the development environment
+//         does not use Docker, launching the dev server should be done from
+// the reader's host system. I think this isn't immediately obvious, e.g. I
+// thought all along that from now on we would only run the server from Docker.
+// If we end up making a TIP or similar about it, I think we should also mention
+// in a development environment relying on containerization, programmers usually
+// mount the whole /src minimizing the time-consuming rebuilding of their images.
+
 ==== Setting environment variables inside the Dockerfile
 
 Now let's set that environment variable in our Dockerfile using the `ENV` directive:
@@ -489,6 +500,7 @@ ENV DJANGO_DEBUG_FALSE=1
 CMD gunicorn --bind :8888 superlists.wsgi:application
 ----
 ====
+// CSANAD: I think it would be important to use a non-privileged user in Docker
 
 Well, it was fiddly, but that should get us to passing tests!
 
@@ -632,7 +644,7 @@ django.db.utils.OperationalError: no such table: lists_list
 
 Re-create the datase with `./src/manage.py migrate` and we'll be back to a working state.
 
-Don't forget to commit our changes to _settings.py_,
+Don't forget to commit our changes to _settings.py_ and _Dockerfile_,
 and I think we can call it job done!
 We've at least touched on many or most of the things you might need to think about
 when considering production-readiness,