Fixing a few FIXMEs.

Author: gvwilson

Makefile

@@ -18,7 +18,7 @@ HOME_PAGE=${SITE}/index.html
 INDEX_YML=_data/index.yml
 NUM_YML=_data/numbering.yml
 TERMS_YML=_data/terms.yml
-ALL_OUT=${BIB_MD} ${NUM_YML} ${TERMS_YML}
+ALL_OUT=${BIB_MD} ${INDEX_YML} ${NUM_YML} ${TERMS_YML}
 EXTRA_MARKDOWN=_includes/intro.md
 
 RELEASE_FILES=\

_config.yml

@@ -130,6 +130,7 @@ kramdown:
       "block-party": ["https://www.blockpartyapp.com/", "Block Party"],
       "brown-neil": ["https://twistedsquare.com/", "Neil C. C. Brown"],
       "bst-repo": ["https://github.com/gvwilson/buildtogether.tech/", "Building Software Together repository"],
+      "burns-privacy-quote": ["https://webdevlaw.uk/2021/03/21/privacy-curriculum-developers/", "Heather Burns on privacy"],
       "buzzfeed-datacamp": ["http://third-bit.com/2019/04/22/datacamp-clarifications/", "DataCamp Clarifications"],
       "captain-awkward": ["https://www.buzzfeednews.com/article/daveyalba/datacamp-sexual-harassment-metoo-tech-startup ", "Buzzfeed article on DataCamp"],
       "carnac": ["http://code52.org/carnac/", "Carnac"],

_data/bibliography.yml

@@ -2045,6 +2045,18 @@
   year: 2016
   doi: 10.1146/annurev-psych-010416-044022
 
+- key: Meyvis2021
+  kind: article
+  author:
+  - Tom Meyvis
+  - Heeyoung Yoon
+  year: 2021
+  journal: Nature
+  volume: 592
+  number: 7853
+  doi: 10.1038/d41586-021-00592-0
+  title: "Adding is Favoured Over Subtracting in Problem Solving"
+
 - key: Michaelson2004
   kind: book
   editor:
@@ -2492,6 +2504,13 @@
   year: 2005
   url: https://igda.org/resources-archive/why-crunch-mode-doesnt-work-six-lessons-2005/
 
+- key: Robinson2021
+  kind: link
+  author:
+  - Nathan J. Robinson
+  title: "Surely We Can Do Better Than Elon Musk"
+  url: https://www.currentaffairs.org/2021/04/surely-we-can-do-better-than-elon-musk/
+
 - key: Rohrer2015
   kind: article
   author:

_data/index.yml

@@ -234,6 +234,10 @@
   - slug: delivery
     title: Wrapping Up
   term: build number
+- links:
+  - slug: security
+    title: Security
+  term: Burns, Heather
 - links:
   - slug: tooling
     title: Tooling
@@ -494,10 +498,6 @@
   - slug: tooling
     title: Tooling
   term: console
-- links:
-  - slug: automation
-    title: Automation
-  term: continous integration - Travis CI
 - links:
   - slug: automation
     title: Automation
@@ -508,6 +508,10 @@
   - slug: automation
     title: Automation
   term: continuous integration - GitHub Actions
+- links:
+  - slug: automation
+    title: Automation
+  term: continuous integration - Travis CI
 - links:
   - slug: teams
     title: Teams
@@ -863,7 +867,7 @@
 - links:
   - slug: errors
     title: Error Handling
-  term: error message - internatioalizing
+  term: error message - internationalizing
 - links:
   - slug: errors
     title: Error Handling
@@ -1001,7 +1005,7 @@
 - links:
   - slug: research
     title: Research
-  term: flow graph - abstract inerpretation
+  term: flow graph - abstract interpretation
 - links:
   - slug: research
     title: Research
@@ -1035,7 +1039,7 @@
 - links:
   - slug: security
     title: Security
-  term: General Data Protection Regularion (GDPR)
+  term: General Data Protection Regulation (GDPR)
 - links:
   - slug: tooling
     title: Tooling
@@ -1291,7 +1295,7 @@
 - links:
   - slug: communicate
     title: Communicating
-  term: instant messagin - inevitable use of
+  term: instant messaging - inevitable use of
 - links:
   - slug: ip
     title: Intellectual Property
@@ -2499,7 +2503,13 @@
 - links:
   - slug: security
     title: Security
-  term: Tech Solidatiry
+  term: Tech Solidarity
+- links:
+  - slug: communicate
+    title: Communicating
+  - slug: automation
+    title: Automation
+  term: technical debt
 - links:
   - slug: contributing
     title: Contributing
@@ -2808,6 +2818,10 @@
   - slug: delivery
     title: Wrapping Up
   term: version numbers
+- links:
+  - slug: delivery
+    title: Wrapping Up
+  term: version numbers - build
 - links:
   - slug: delivery
     title: Wrapping Up
@@ -2824,10 +2838,6 @@
   - slug: delivery
     title: Wrapping Up
   term: version numbers - semantic versioning
-- links:
-  - slug: delivery
-    title: Wrapping Up
-  term: vesion numbers - build
 - links:
   - slug: git-solo
     title: Using Git On Your Own

automation/index.md

@@ -1,8 +1,6 @@
 ---
 ---
 
-<span class="fixme">Manage dependencies early</span>
-
 Everyone is talking about <span g="devops" i="DevOps">DevOps</span> these days,
 even though (or perhaps because) no one can quite agree what it is.  The term
 mostly seems to refer to practices that minimize the time between a developer
@@ -53,8 +51,8 @@ forehead.
 
 I could live with ugly syntax---if Ie kan lurn Inglish speling, Ie kan lurn
 eneething. But the lack of a debugger is a never-ending headache, because real
-build systems aren't just configured: they're programmed. Take this book, for
-example: its Makefile checks the consistency of cross-references and glossary
+build systems aren't just configured: they're programmed. For example, this
+book's Makefile checks the consistency of cross-references and glossary
 entries, makes sure all the bibliography citations are in place, and copies
 files to my web site, and is more complex than many programs I've written.
 Thinking of it as a "configuration" file is a mistake: you *have* to <span
@@ -113,6 +111,15 @@ Pick something that plays nicely with your other tools.
     <span i="build manager!Ant; Ant; Java!build manager">[Ant][ant]</span>,
     which means they can jump directly to compilation errors when they occur.
 
+Be very cautious about adding dependencies.
+:   "Reduce, re-use, recycle" is as important for software as it is for daily
+    life, but every library you depend on is one more way for your project to
+    accumulate <span i="technical debt">technical debt</span>.  Recent
+    research shows that we are all biased toward solving problems by adding
+    things instead of taking them away <cite>Meyvis2021</cite>; checking the
+    packages your project depends on before every release and cutting any you
+    can will prevent a lot of future headaches.
+
 Always use the build manager---never compile or copy things by hand.
 :   This isn't just for efficiency's sake: if any of the things you need to do
     to get your application up on your web site have to be done by hand, the
@@ -178,7 +185,7 @@ definitions in code helps programmers understand software as well.
 
 Build tools will do a lot more for you if you adopt some kind of <span g="ci"
 i="continuous integration">continuous integration</span> system such as <span
-i="Travis CI; continous integration!Travis CI">[Travis CI][travis-ci]</span> or
+i="Travis CI; continuous integration!Travis CI">[Travis CI][travis-ci]</span> or
 <span i="GitHub Actions; continuous integration!GitHub Actions">[GitHub
 Actions][github-actions]</span>.  These can be set up to run either at regular
 intervals (e.g., every hour or at three a.m.), or every time someone checks into

bibliography/index.md

@@ -1078,6 +1078,12 @@ Janet Metcalfe:
 "Learning from Errors".
 <em>Annual Review of Psychology</em>, 68(1), 2016, <a class="doi" href="https://doi.org/10.1146/annurev-psych-010416-044022">10.1146/annurev-psych-010416-044022</a>.
 </dd>
+<dt id="meyvis2021" class="bibliography">Meyvis2021</dt>
+<dd>
+Tom Meyvis and Heeyoung Yoon:
+"Adding is Favoured Over Subtracting in Problem Solving".
+<em>Nature</em>, 592(7853), 2021, <a class="doi" href="https://doi.org/10.1038/d41586-021-00592-0">10.1038/d41586-021-00592-0</a>.
+</dd>
 <dt id="michaelson2004" class="bibliography">Michaelson2004</dt>
 <dd>
 Larry K. Michaelson, Arletta Bauman Knight, and L. Dee Fink (eds.):
@@ -1336,6 +1342,11 @@ New Society Publishers, 2010, 978-0865716513.
 Evan Robinson:
 "<a href="https://igda.org/resources-archive/why-crunch-mode-doesnt-work-six-lessons-2005/">Why Crunch Mode Doesn't Work: 6 Lessons</a>".
 </dd>
+<dt id="robinson2021" class="bibliography">Robinson2021</dt>
+<dd>
+Nathan J. Robinson:
+"<a href="https://www.currentaffairs.org/2021/04/surely-we-can-do-better-than-elon-musk/">Surely We Can Do Better Than Elon Musk</a>".
+</dd>
 <dt id="rohrer2015" class="bibliography">Rohrer2015</dt>
 <dd>
 Doug Rohrer, Robert F. Dedrick, and Sandra Stershic:

communicate/index.md

@@ -202,7 +202,7 @@ archives of stream-of-consciousness exchanges is harder than finding things in
 asynchronous media.
 
 But who am I kidding? You're going to use <span i="communication!instant
-messaging; instant messagin!inevitable use of">instant messaging</span> no
+messaging; instant messaging!inevitable use of">instant messaging</span> no
 matter what I say.  If more than two people are in the conversation, follow the
 same rules you would for a short meeting: post a summary of any decisions you
 made where everyone can see it.
@@ -301,7 +301,7 @@ know][evans-manager], all of which apply to student teams:
 
 1.  Exactly what individual people on the team are working on.
 
-1.  Where the <span g="technical_debt">technical debt</span> is.
+1.  Where the <span g="technical_debt" i="technical debt">technical debt</span> is.
 
 1.  How to help you get better at your job.
 

delivery/index.md

@@ -107,7 +107,7 @@ to customers, along with instructions about where to put it, rather than
 creating a new installer. You should still give it a number, though, and make an
 entry in your release log.
 
-The <span g="build_number" i="build number; vesion numbers!build">build
+The <span g="build_number" i="build number; version numbers!build">build
 number</span> is incremented every time you create a new version of the product
 for QA to test. Build numbers are never reset, i.e. you don't go from 5.2.2.1001
 to 6.0.0.0, but from 5.2.2.1001 to 6.0.0.1002, and so on. Build numbers are what

errors/index.md

@@ -249,7 +249,7 @@ if fname[-4:] != '.csv':
 
 {: .continue}
 A better approach is to put all the error messages in a <span i="error
-message!internatioalizing">dictionary</span>:
+message!internationalizing">dictionary</span>:
 
 ```py
 ERRORS = {

research/index.md

@@ -193,7 +193,7 @@ If engineering is applied science, then <cite>Eichberg2015</cite> is a great
 example of software engineering.  In it, the authors show that it's possible to
 identify a wide range of problems in code by comparing the actual <span i="flow
 graph!actual">flow graph</span> (which is the set of all possible paths through
-the program) with the <span i="flow graph!abstract inerpretation">abstract
+the program) with the <span i="flow graph!abstract interpretation">abstract
 interpretation flow graph</span> (which is the set of all paths once possible
 data values are taken into account).  To make this more concrete, the control
 flow graph for: