update book from master

Author: hjwp

book/appendix_csvs.html

@@ -131,7 +131,8 @@
 <h2 id="appendix_csvs">Appendix C: Swapping Out the Infrastructure: Do Everything with CSVs</h2>
 <div class="sectionbody">
 <div class="paragraph">
-<p>This appendix is intended as a little illustration of the benefits of the
+<p>
+This appendix is intended as a little illustration of the benefits of the
 Repository, Unit of Work, and Service Layer patterns. It&#8217;s intended to
 follow from <a href="/book/chapter_06_uow.html">[chapter_06_uow]</a>.</p>
 </div>
@@ -310,7 +311,8 @@ <h2 id="appendix_csvs">Appendix C: Swapping Out the Infrastructure: Do Everythin
 <div class="sect2">
 <h3 id="_implementing_a_repository_and_unit_of_work_for_csvs">Implementing a Repository and Unit of Work for CSVs</h3>
 <div class="paragraph">
-<p>Here&#8217;s what a CSV-based repository could look like.  It abstracts away all the
+<p>
+Here&#8217;s what a CSV-based repository could look like.  It abstracts away all the
 logic for reading CSVs from disk, including the fact that it has to read <em>two
 different CSVs</em> (one for batches and one for allocations), and it gives us just
 the familiar <code>.list()</code> API, which provides the illusion of an in-memory
@@ -366,7 +368,8 @@ <h3 id="_implementing_a_repository_and_unit_of_work_for_csvs">Implementing a Rep
 </div>
 </div>
 <div class="paragraph">
-<p>And here&#8217;s what a UoW for CSVs would look like:</p>
+<p>
+And here&#8217;s what a UoW for CSVs would look like:</p>
 </div>
 <div id="csvs_uow" class="exampleblock">
 <div class="title">A UoW for CSVs: commit = csv.writer (src/allocation/service_layer/csv_uow.py)</div>
@@ -419,7 +422,8 @@ <h3 id="_implementing_a_repository_and_unit_of_work_for_csvs">Implementing a Rep
 </div>
 </div>
 <div class="paragraph">
-<p>Ta-da! <em>Now are y&#8217;all impressed or what</em>?</p>
+<p>
+Ta-da! <em>Now are y&#8217;all impressed or what</em>?</p>
 </div>
 <div class="paragraph">
 <p>Much love,</p>
@@ -438,7 +442,7 @@ <h3 id="_implementing_a_repository_and_unit_of_work_for_csvs">Implementing a Rep
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2020-03-17 09:07:44 UTC
+Last updated 2020-03-20 13:47:19 UTC
 </div>
 </div>
 <style>

book/appendix_django.html

@@ -131,7 +131,9 @@
 <h2 id="appendix_django">Appendix D: Repository and Unit of Work Patterns with Django</h2>
 <div class="sectionbody">
 <div class="paragraph">
-<p>Suppose you wanted to use Django instead of SQLAlchemy and Flask. How
+<p>
+
+Suppose you wanted to use Django instead of SQLAlchemy and Flask. How
 might things look? The first thing is to choose where to install it. We put it in a separate
 package next to our main allocation code:</p>
 </div>
@@ -197,7 +199,10 @@ <h2 id="appendix_django">Appendix D: Repository and Unit of Work Patterns with D
 <div class="sect2">
 <h3 id="_repository_pattern_with_django">Repository Pattern with Django</h3>
 <div class="paragraph">
-<p>We used a plug-in called
+<p>
+
+
+We used a plugin called
 <a href="https://github.com/pytest-dev/pytest-django"><code>pytest-django</code></a> to help with test
 database management.</p>
 </div>
@@ -299,7 +304,9 @@ <h3 id="_repository_pattern_with_django">Repository Pattern with Django</h3>
 <div class="sect3">
 <h4 id="_custom_methods_on_django_orm_classes_to_translate_tofrom_our_domain_model">Custom Methods on Django ORM Classes to Translate to/from Our Domain Model</h4>
 <div class="paragraph">
-<p>Those custom methods look something like this:</p>
+<p>
+
+Those custom methods look something like this:</p>
 </div>
 <div id="django_models" class="exampleblock">
 <div class="title">Django ORM with custom methods for domain model conversion (src/djangoproject/alloc/models.py)</div>
@@ -372,6 +379,8 @@ <h4 id="_custom_methods_on_django_orm_classes_to_translate_tofrom_our_domain_mod
 <td class="content">
 As in <a href="/book/chapter_02_repository.html">[chapter_02_repository]</a>, we use dependency inversion.
     The ORM (Django) depends on the model and not the other way around.
+    
+    
 </td>
 </tr>
 </table>
@@ -381,7 +390,9 @@ <h4 id="_custom_methods_on_django_orm_classes_to_translate_tofrom_our_domain_mod
 <div class="sect2">
 <h3 id="_unit_of_work_pattern_with_django">Unit of Work Pattern with Django</h3>
 <div class="paragraph">
-<p>The tests don&#8217;t change too much:</p>
+<p>
+
+The tests don&#8217;t change too much:</p>
 </div>
 <div id="test_uow_django" class="exampleblock">
 <div class="title">Adapted UoW tests (tests/integration/test_uow.py)</div>
@@ -483,15 +494,21 @@ <h3 id="_unit_of_work_pattern_with_django">Unit of Work Pattern with Django</h3>
 instrumenting the domain model instances themselves, the
 <code>commit()</code> command needs to explicitly go through all the
 objects that have been touched by every repository and manually
-update them back to the ORM.</p>
+update them back to the ORM.
+
+</p>
 </li>
 </ol>
 </div>
 </div>
 <div class="sect2">
 <h3 id="_api_django_views_are_adapters">API: Django Views Are Adapters</h3>
 <div class="paragraph">
-<p>The Django <em>views.py</em> file ends up being almost identical to the
+<p>
+
+
+
+The Django <em>views.py</em> file ends up being almost identical to the
 old <em>flask_app.py</em>, because our architecture means it&#8217;s a very
 thin wrapper around our service layer (which didn&#8217;t change at all, by the way):</p>
 </div>
@@ -537,7 +554,8 @@ <h3 id="_api_django_views_are_adapters">API: Django Views Are Adapters</h3>
 <div class="sect2">
 <h3 id="_why_was_this_all_so_hard">Why Was This All So Hard?</h3>
 <div class="paragraph">
-<p>OK, it works, but it does feel like more effort than Flask/SQLAlchemy. Why is
+<p>
+OK, it works, but it does feel like more effort than Flask/SQLAlchemy. Why is
 that?</p>
 </div>
 <div class="paragraph">
@@ -549,7 +567,8 @@ <h3 id="_why_was_this_all_so_hard">Why Was This All So Hard?</h3>
 high).</p>
 </div>
 <div class="paragraph">
-<p>Because Django is so tightly coupled to the database, you have to use helpers
+<p>
+Because Django is so tightly coupled to the database, you have to use helpers
 like <code>pytest-django</code> and think carefully about test databases, right from
 the very first line of code, in a way that we didn&#8217;t have to when we started
 out with our pure domain model.</p>
@@ -570,7 +589,8 @@ <h3 id="_why_was_this_all_so_hard">Why Was This All So Hard?</h3>
 <div class="sect2">
 <h3 id="_what_to_do_if_you_already_have_django">What to Do If You Already Have Django</h3>
 <div class="paragraph">
-<p>So what should you do if you want to apply some of the patterns in this book
+<p>
+So what should you do if you want to apply some of the patterns in this book
 to a Django app? We&#8217;d say the following:</p>
 </div>
 <div class="ulist">
@@ -610,7 +630,8 @@ <h3 id="_what_to_do_if_you_already_have_django">What to Do If You Already Have D
 <div class="sect2">
 <h3 id="_steps_along_the_way">Steps Along the Way</h3>
 <div class="paragraph">
-<p>Suppose you&#8217;re working on a Django project that you&#8217;re not sure is going
+<p>
+Suppose you&#8217;re working on a Django project that you&#8217;re not sure is going
 to get complex enough to warrant the patterns we recommend, but you still
 want to put a few steps in place to make your life easier, both in the medium
 term and if you want to migrate to some of our patterns later. Consider the following:</p>
@@ -657,7 +678,8 @@ <h3 id="_steps_along_the_way">Steps Along the Way</h3>
 </table>
 </div>
 <div class="paragraph">
-<p>For more thoughts and actual lived experience dealing with existing
+<p>
+For more thoughts and actual lived experience dealing with existing
 applications, refer to the <a href="/book/epilogue_1_how_to_get_there_from_here.html">epilogue</a>.</p>
 </div>
 </div>
@@ -680,7 +702,7 @@ <h3 id="_steps_along_the_way">Steps Along the Way</h3>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2020-03-17 09:07:44 UTC
+Last updated 2020-03-20 13:47:19 UTC
 </div>
 </div>
 <style>

book/appendix_ds1_table.html

@@ -131,7 +131,8 @@
 <h2 id="appendix_ds1_table">Appendix A: Summary Diagram and Table</h2>
 <div class="sectionbody">
 <div class="paragraph">
-<p>Here&#8217;s what our architecture looks like by the end of the book:</p>
+<p>
+Here&#8217;s what our architecture looks like by the end of the book:</p>
 </div>
 <div id="recap_diagram" class="imageblock">
 <div class="content">
@@ -236,6 +237,9 @@ <h2 id="appendix_ds1_table">Appendix A: Summary Diagram and Table</h2>
 </tr>
 </tbody>
 </table>
+<div class="paragraph">
+<p></p>
+</div>
 </div>
 </div>
 <div class="prev_and_next_chapter_links">
@@ -246,7 +250,7 @@ <h2 id="appendix_ds1_table">Appendix A: Summary Diagram and Table</h2>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2020-03-17 09:07:44 UTC
+Last updated 2020-03-20 13:47:19 UTC
 </div>
 </div>
 <div><div id="disqus_thread" style="margin: 10px"></div>

book/appendix_project_structure.html

@@ -131,7 +131,8 @@
 <h2 id="appendix_project_structure">Appendix B: A Template Project Structure</h2>
 <div class="sectionbody">
 <div class="paragraph">
-<p>Around <a href="/book/chapter_04_service_layer.html">[chapter_04_service_layer]</a>, we moved from just having
+<p>
+Around <a href="/book/chapter_04_service_layer.html">[chapter_04_service_layer]</a>, we moved from just having
 everything in one folder to a more structured tree, and we thought it might
 be of interest to outline the moving parts.</p>
 </div>
@@ -574,7 +575,8 @@ <h3 id="_dockerfile">Dockerfile</h3>
 <div class="sect2">
 <h3 id="_tests">Tests</h3>
 <div class="paragraph">
-<p>Our tests are kept alongside everything else, as shown here:</p>
+<p>
+Our tests are kept alongside everything else, as shown here:</p>
 </div>
 <div id="tests_folder" class="exampleblock">
 <div class="title">Tests folder tree</div>
@@ -630,7 +632,8 @@ <h3 id="_wrap_up">Wrap-Up</h3>
 </ul>
 </div>
 <div class="paragraph">
-<p>We doubt that anyone will end up with <em>exactly</em> the same solutions we did, but we hope you
+<p>
+We doubt that anyone will end up with <em>exactly</em> the same solutions we did, but we hope you
 find some inspiration here.</p>
 </div>
 </div>
@@ -668,7 +671,7 @@ <h3 id="_wrap_up">Wrap-Up</h3>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2020-03-17 09:07:44 UTC
+Last updated 2020-03-20 13:47:19 UTC
 </div>
 </div>
 <style>

book/appendix_validation.html

@@ -131,7 +131,8 @@
 <h2 id="appendix_validation">Appendix E: Validation</h2>
 <div class="sectionbody">
 <div class="paragraph">
-<p>Whenever we&#8217;re teaching and talking about these techniques, one question that
+<p>
+Whenever we&#8217;re teaching and talking about these techniques, one question that
 comes up over and over is "Where should I do validation? Does that belong with
 my business logic in the domain model, or is that an infrastructural concern?"</p>
 </div>
@@ -734,7 +735,8 @@ <h3 id="_validating_pragmatics">Validating Pragmatics</h3>
 domain model. When we receive a message like "allocate three million units of
 <code>SCARCE-CLOCK</code> to order 76543," the message is <em>syntactically</em> valid and
 <em>semantically</em> valid, but we&#8217;re unable to comply because we don&#8217;t have the stock
-available.</p>
+available.
+</p>
 </div>
 </div>
 </div>
@@ -746,7 +748,7 @@ <h3 id="_validating_pragmatics">Validating Pragmatics</h3>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2020-03-17 09:07:44 UTC
+Last updated 2020-03-20 13:47:19 UTC
 </div>
 </div>
 <style>