2004 · 2005 · 2006 · 2007 · 2008 · 2009
2010 · 2011 · 2012 · 2013 · 2014 · 2015 · 2016 · 2017 · 2018 · 2019
2020 · 2021

A Magic USB Drive

I dreamed again last night about a magic USB drive. If I held it in my hand and thought hard about the files I wanted, then plugged the drive into my computer, the files would be there. A finished version of the YA novel I’ve been working on sporadically, the tech books I’m either struggling with or just wishing for—they would just be there, fully formed and ready to share with the world, along with the complete source code of the extensible programming tools I’ve wanted for the last 20 years and the albums Ike Quebec never recorded.

Then the exuberance of the birds in our back yard woke me up and I had to return a world in which my hands hurt when I type and my brain hurts when I word. Iffy won’t escape from Antarctica by magic; the errors and inconsistencies in STJS and BST won’t correct themselves, and as for the programming tools and jazz, you can only have everything you want in dreams and sometimes not even then.

But the birds sound happy and the rain has stopped long enough that I can get in a good bike ride. I may not dream about things like that, but I enjoy them. Time to start my day…

Two Books

Hi - I'm Greg Wilson, and this short talk describes two new open access resources you might want to use in undergraduate software engineering classes.

The first, called Software Tools in JavaScript, teaches software design by showing students how to build simple versions of twenty widely-used software development tools. The second, called Building Software Together, is a guide to workng in a small team for a single term. Both books are freely available under a Creative Commons license.

Here's how it all started. Back in the early 2000s I taught a course on software architecture three times at the University of Toronto and then told the department they should cancel it. The problem was a lack of material: between them, the eight books I had on my shelf with "software architecture" in the title spent a total of less than 30 pages describing actual systems. They explained how to gather architectural requirements, how to maintain them, and how to communicate them, but didn't show readers what real systems looked like.

In frustration, I mailed 200 programmers and asked them to write a chapter each describing the most beautiful piece of software they'd ever seen. We wound up with 34 contribution, which were published as a book called Beautiful Code. It won a Jolt Award and raised quite a bit of money for charity, but it wasn't useful as a textbook: the pieces of software contributors described ranged in size from a few lines of code to multi-million line systems, and required far more background knowledge than undergrads were likely to have.

Our second attempt was a pair of books called The Architecture of Open Source Applications. The entries were much more uniform in level, but the contributors used such a wide range of languages that once again most students would have struggled to follow along. On the upside, all of the content was (and is) open access.

The irony is, I learned most of what I know about software design from a series of books that avoided all of these problems. The trilogy that Brian Kernighan and colleagues wrote in the early 1980s didn't just teach people C and Unix: they taught my generation how to think about programming by showing us how to build the tools we used to program.

Which brings us to Software Tools in JavaScript. Its aim is to teach software design by walking readers through the construction of simple versions of tools they actually use. The book uses JavaScript rather than Java, Python, or something more modern because JavaScript is the one unavoidable language - and these days, it's actually not bad.

The material covers twenty tools, ranging from a very (very) simple version control system to a browser layout engine, an interactive debugger, and a style checker.

Each entry is short enough to cover in one or two lectures. Together, they introduce some common design patterns, show students how to test complex systems by mocking or stubbing components, and introduce them to tools they should probably be using anyway.

There are lots of starting points for homework exercises, mostly of the form "add this feature to tool X" or "build a very simple version of tool Y from scratch". If your students do the latter, we'd be very happy to include their work - with full attribution - in Volume 2. And if you think of a tool that we haven't covered but should, like a fuzz tester or accessibility auditor, please dive in.

Meanwhile, whenever I run into one of my former project students, they tell me that the most useful thing I taught them wasn't about code: it was about how to work in a team. I think this is more important with each passing year: we used to say, "Move fast and break things," and while I don't know if we did the former, it's pretty clear at this point that we've done a lot of breaking.

The second book, Building Software Together, is what a small team of undergrads needs to know to get through their first semester-long project. It talks about version control and continuous integration, but it's mostly about the human side of software engineering. How do you run a meeting? How do you review someone else's code? How to handle deadlines when you're juggling assignments in several different courses whose lecturers don't seem to talk to each other?

I'm still dissatisfied with some parts of this book. In particular, I don't think the chapters on security and inclusivity are going to persuade someone who doesn't already care about these things that they should. I've taught ethics to engineers, and I think that in a lot of cases, they tune out while we're talking, tell us what they think we expect to hear, and carry on as before. If you or your students can think of better approaches for these important topics, please let me know - I'm happy to rewrite.

To wrap up, these two books don't have to be used together, but they are designed to complement one another. They are both free to use under a Creative Commons - Attribution - NonCommercial license, which means you can copy or modify them however you want as long as you link back to the originals and don't try to make any money from it. (If print editions do appear, 100% of the royalties will go to support the Red Door Shelter in Toronto.) Contributions are very welcome, and all contributors will be acknowledged.

You can find the books online at https://stjs.tech/ and https://buildtogether.tech/...

...and you can reach me at gvwilson@third-bit.com. Thank you for listening.


Grassroots organizing isn’t enough to achieve meaningful change. Sooner or later you need people in the room, on the committee, to get what you want on the agenda and then vote for it. Without that, you will always be working around or against the rules instead of having the rules work for you.

In the past I’ve suggested that open science groups should start offering leadership training to prepare their members to run for elected positions in organizations like the American Physical Society and the Ecological Society of America. Nobody’s been willing to back that, but there’s another, less direct approach that could be equally effective.

Everyone from the NRA to the ACLU sends questions to people running for public office and publish scoresheets ranking the candidates based on their responses and their legislative track record. What if an open science organization (or a group of them) did that for people who are running for the executive or boards of various research societies? Questions could include:

  • What specific steps will you take to ensure that people developing research software are given institutional recognition for their work?

  • What changes to the society’s model curriculum will you push for relating to open data, open science, and reproducible research?

  • What will you do to increase diversity and inclusivity within the society?

Just asking the questions puts the issues on the agenda, and publishing the responses (with or without a scoring or ranking) will get even more attention. I think it would be a low-cost, low-risk way to reward people who care about open science, reproducible research, and recognition for all the work people do (not just the papers they publish).

More importantly, I think it would encourage younger people to run for office. I’ve been telling myself for almost twenty-five years that we just need to be patient—that sooner or later the generation that’s grown up believing in open will find themselves in positions of power and make the changes we need. I’m tired of waiting, and if the politics of the last five years have taught us anything, it’s that progress isn’t inevitable. If we want a better world, we need to build it. Asking the people who want to lead us whether they’re going to do that or not seems like a good first step.

First Day with Metabase

Today is my first day as Head of Education at Metabase. I’m excited to be starting a new adventure, and for the chance to help millions of people find answers in their data. I have a lot to learn—I hope you’ll enjoy following along as I do.

Evening and Morning Routine

Whoever goes to bed last:

  1. Refill the bird feeder if necessary.
  2. Bring in the cushions from the bench on the back deck.
  3. Switch on the anti-goose laser.
  4. If it’s looking stormy, tie off the wind chimes.
  5. Check that the back door is locked.
  6. Check the calendar and prime the auto-excuse generator with the titles of any incomplete homework assignments.
  7. Feed the [redacted] and test the welds on its [redacted], then make sure the basement light is off.
  8. Check that the front door is locked.
  9. Refill the humidifier on the auxiliary breather. (Use distilled water, not tap water.)

Whoever wakes up first:

  1. You only have ten minutes to deliver tea when the bell rings so be ready.
  2. (Weekdays) Wake child.
  3. (Tuesdays only) Check calendar and put out green bin and either garbage or recycling.
  4. Appease the [redacted].
  5. Switch off anti-goose laser.
  6. (Weekdays) Re-wake child.
  7. Breakfast/overnight email.
  8. Empty humidifier on auxiliary breather.
  9. Shower/shave/dress.
  10. (Weekdays) Threaten child with loss of network privileges if they aren’t up in the next ten seconds.
  11. Log on and try once more to beat back the forces of evil.

Building a Book (Part 3)

The previous post in this series described the template I’m using for Software Tools in JavaScript and Building Tech Together. Here’s more detail on the helper scripts I had to write to work around Jekyll’s inadequacies, in the order in which they run during a full build. All in all they are 2600 lines of Python; rebuilding some of them would be a rich source of exercises for a second-year course on software design and testing.

  1. make-bib.py: convert the YAML-format bibliography in _data/bibliography.yml to a Markdown file bibliography/index.md. I used YAML rather than BibTeX because it’s easier to read and process; I’m surprised this isn’t already common practice.

  2. make-index.py: extract index keys from Markdown source to create _data/index.yml, which is then processed by Jekyll to create an index page.

  3. make-numbering.py: generate serial numbers for chapters and appendices, figures, and tables, and put them in _data/numbering.yml.

  4. make-terms.py: find all glossary definitions and store them in _data/terms.yml so that each chapter can start with a list of the terms it defines.

  5. check-bib.py: check that all citations resolve and all bibliography entries are used.

  6. check-gloss.py: check that all glossary entries resolve (including cross-references within the glossary) and that all existing entries are referenced. The glossary is stored in Glosario format, and the entries are mix of some cherry-picked from Glosario itself and some I’ve written for these books.

  7. check-chunk-length.py: look for text inclusions (e.g., sample programs) that are too long to fit on a single printed page. STJS has several of these; if I stick with this template, I’ll modify this script and some of the others so that directives in the Markdown source will turn off warnings for specific inclusions.

  8. check-code-blocks.py: check that all code blocks have a recognized language type. (I can’t train my hands to be consistent about txt versus text or py versus python.)

  9. check-dom.py: check that the generated HTML only uses expected tags and attributes.

  10. check-links.py: compare the link definitions in _config.yml with the [name][link] references in the Markdown source files to make sure that all definitions are used and all references to links resolve. I’d really like to put link definitions in an external YAML file in the _data directory, but Jekyll doesn’t support that; as explained here, they have to go in a single YAML-formatted string in _config.yml.

  11. check-numbering.py: make sure that all cross-references to chapters/appendices, figures, and tables resolve.

  12. prep-spelling.py and check-spelling.py: the first strips code blocks from the generated HTML, which is then piped to aspell to create a list of unknown words; the second compares that list with the one stored in _data/spelling.txt and produces a list of unknown words.

  13. html2tex.py: convert the generated HTML to LaTeX, which is then used to produce a PDF. I’ve used Pandoc for several previous projects; 500 lines of Python that does exactly what I want and produces comprehensible error messages is a lot easier for me to maintain.

I also have:

  1. show-chapters.py: show the number of words in each chapter along with the total word count.

  2. show-dom.py: print a list of all tags and attributes in the generated HTML.

  3. show-fixme.py: display all the embedded to-do items along with a count of how many there are.

  4. show-index.py: display all index terms and the locations of all references to them. (This helps me catch things like singular-vs.-plural inconsistencies in index terms.)

  5. show-pages.py: display the number of pages in each chapter of the final PDF.

Nine Weeks Off

I’m starting a new job on Monday; what have I done with the nine weeks since RStudio laid me off?

  • Published a short story that I wrote after my brother died and “Ten quick tips for staying safe online” that I co-authored with Danielle Smalls. (All the work for both was done before I was canned, but seeing them in print was still a nice boost.)

  • Wrapped up Research Software Engineering with Python: it should be on the shelves this quarter.

  • Finished the first usable draft of Software Tools in JavaScript, which teaches software design by building small versions of the tools programmers use themselves. Comments and feedback would be very welcome.

  • Turned a pile of notes into a rough draft of Building Software Together, which is a guide for undergraduates embarking on their first team software project. The sections on security and fairness are still unsatisfying, but I hope it’s useful, and feedback would be even more welcome.

  • Built yet another Jekyll template for writing books like these. It relies on a bunch of Python scripts to make up for Jekyll’s inadequacies, and I use another Python script to convert the generated HTML to LaTeX so that I can produce a PDF (because that’s easier to maintain than customized Pandoc), but it’s working well enough that I might get around to documenting it for others to use as well.

  • Discovered the hard way that if you don’t use WordPress for 20 years, you forget everything you once knew about PHP.

  • Gave a couple of talks and signed up to give a couple more.

  • Read about two dozen papers. (Thank you, Alexandra, for making this possible.)

  • Added about 20,000 words to the novel I’m working on. I’m 4800 words short of my target for the nine weeks, so I did well or poorly depending on how you look.

  • Exercised and played guitar four or five times a week. My blood pressure and BMI are still higher than they should be for someone with my family history of heart disease, and progress on guitar is still frustratingly slow, but I’m mostly satisfied.

  • Built some lids for our garden boxes and generally got the back yard ready for another spring. It’s unlikely we’ll do any house renos this summer (Ontario is going into another lockdown thanks to the Ford government’s cowardice and incompetence), but I’m hoping we can take advantage of working from home the way we did last year.

  • Played several hundred games of Hive and lost most of them. I do all right if I survive the opening, but that’s a big “if” right now. If you’d like to trounce me, I’m gvwilson on Board Game Arena.

You Say Dumbing Down, I Say Inviting In

Most of the early feedback on Building Tech Together has been positive, but one person has said that I’m over-simplifying some things and dumbing down others. I’m not sure what the difference is, but my answer is that Newtonian physics isn’t a dumbed down version of quantum mechanics or general relativity: it’s a simpler model that is easier for newcomers to start with while being perfectly good for solving a wide range of problems. It’s Scratch instead of Python or Java, and I’m past feeling that anyone should apologize for giving people a ramp they can walk up instead of a cliff to climb.

I also try to respect the fact that the people I’m writing for don’t have time to read the primary literature and weigh its nuances, and that expecting them to reveals a lot of privilege. Academia cares less about being right than about not being wrong, so papers are littered with defensive get-outs like “perhaps”, “might indicate”, and “however”. In contrast, every teacher has to teach tomorrow (or this afternoon, or in an hour) which means they have to decide now whether to do X or not. As one said to me years ago, if a student is right 90% of the time that’s an A+; if a teacher can do just as well in the time they actually have, they should be just as proud.

Choose Your Own Adventure

Julia Evans recently posted a description of the “choose your own adventure” network debugging tutorials that she has been creating with Twine. It’s a very cool idea, and a very welcome innovation: I think we’re all getting a bit tired of “read these paragraphs/watch this video and now do this auto-graded drill exercise”. If you’re a CS education grad student in search of a cool project, you could do worse than building a plugin for Scratch or VS Code that enabled people to choose their own debugging adventure within their actual programming environment. (This is not the same as building a tool for authoring Twine, though I imagine the former could use the latter.)

For example, one passage could give the learner the option “set a breakpoint on line 26”. Instead of clicking on a link directly to take that action, the learner would actually set a breakpoint; the IDE plugin would detect and verify that action and move to the next passage, or put up an I’m sorry Dave message if the user tried to do something unanticipated.

I can imagine a boatload of studies someone could do with a tool like this. I can also imagine something similar for teaching people how to build sophisticated SQL queries or tidyverse pipelines step by step. If you know of something like this, or are working on it, I’d enjoy hearing from you.


One of the silver linings of unemployment is that it’s given me time to make progress on a couple of book projects. I’ll share them both once I’ve made a few more revisions (hopefully by month’s end), but I hope their indexes give you an idea of what they cover:

Software Tools in JavaScriptBuilding Software Together
abstract syntax tree90-9-1 rule
Accumulator patternaccessibility
Acornaccessibility - WebAIM WAVE
actual result (in unit test)active bystander
Adapter patternactive listening
algorithm - greedyactual result (in unit test)
alias - during importADHD
Alloyagile development
anonymous functionagile development - conditions for success
API - as protocolallocating work - chaotic decomposition
Application Binary Interfaceallocating work - confirmation loop
Armstrong, Tavishallocating work - effect of social status
array - implementation ofallocating work - feature decomposition
Array.filterallocating work - functional decomposition
Array.forEachallocating work - in teams
Array.reduceallocating work - modular decomposition
ArrayBufferallocating work - rotating decomposition
assembly codeally
assertion - as runnable documentationalready invented here syndrome
assertion - in unit testanalysis & estimation
assignment - destructuringanalysis paralysis
async keywordAnt
asynchronous executionApache Software Foundation
automatic variable (in build)APT
await keywordassertion
backward compatibilityauthentication - two-factor
bare objectautomated program repair
bind method to objectautomation
bitwise operationautomation - as programming
block commentAutomattic - hiring process
Brown, AmyBaldwin, James
Brubeck, MattBaxter, T. Carter
build - automatic variablebias
build - clock synchronizationbig bang integration
build - dependencyBitbucket
build - hash codeBlack
build - pattern ruleBlackbox project
build - recipeblog - as team journal
build - ruleblog - automatically generated
build - staleBoehm Curve
build - timestampBorland
build managerbranch (in Git)
build targetbreakpoint
Cbreaks (importance of regular)
C++Brook's Law
cache - calculated valuesBrown, Neil
cache - modulesbrowser automation - for testing
cache - of loaded filesbrowser automation - record and playback
call stack - environmentBSD License
call stack - stack framebug tracker
callback functionbuild manager
callback function - conventions forbuild manager - and version control
caller modulebuild manager - Ant
chain of inheritancebuild manager - Make
Chain of Responsibility patternbuild manager - Rake
character encodingbuild manager - rules for using
character encoding - UTF-8build manager - Snakemake
circular dependencybuild number
clock synchronization (in build)Burns, Heather
code - as dataC++
code completionCarnac
code coveragecasual threat
Code of Conductcatch exception
coding style - importance of consistencyCC-BY license
coding style - linterCC0 license
cognitive loadchaotic decomposition
collision (in hashing)checklists - benefits of
column-major storage orderchecklists - use in code review
combinatorial explosionCheckstyle
command-line argumentchorus of explanation
comment - blockchunking
comment - docco-op
comment - linecode browser
compiled languagecode clones
compiled language - linkingcode comprehension
Comprehensive TeX Archive Networkcode coverage
confirmation biascode metrics - ineffectiveness of
console.logCode of Conduct
const declaration - advantages ofCode of Conduct - responding to violations
Cook, Mary Rosecode review
coordinate systemcode review - effectiveness of
couplingcode review - for security
cryptographic hash functioncode review - procedure
CSScode review - responding to
CSS - struggles withcognitive bias
DAGcognitive dimensions framework
data framecognitive load
DataForgecognitive load - extraneous
debuggercognitive load - germane
debugger - source mapcognitive load - impact of checklists
Decorator patterncognitive load - in debugging
delta debuggingcognitive load - intrinsic
dependency (in build)cognitive load theory
depth-first searchcognitive transition
design by contractcollective action
design pattern - Accumulatorcomments - as communication
design pattern - Adaptercommit (version control)
design pattern - Chain of Responsibilitycommit message (version control)
design pattern - Decoratorcommon programming errors
design pattern - Iteratorcommons
design pattern - Singletoncommunication - asynchronous
design pattern - Template Methodcommunication - blog
design pattern - Visitorcommunication - comments
destructuring assignmentcommunication - email
DiBernardo, Mikecommunication - instant messaging
directed acyclic graphcommunication - synchronous
directed acyclic graph (DAG)communication - wiki
directed graphcommunity of practice
doc commentcompetent practitioner
Document Object Modelcompetent practitioner - documentation needs
DOMComprehensive TeX Archive Network (CTAN)
dynamic loadingconceptual architecture - diagram
dynamic lookupconcrete examples
dynamic scopingconcurrent systems - difficult of debugging
eager matchingCONDUCT file
EJSconfiguration - layered
encapsulationconfiguration - parameters
entry point (of module)confirmation loop - allocating work
environment (to store variables)conflict (in Git)
error (in unit test)conflict (in Git) - repeating
Escodegenconflict (interpersonal)
ESDocconflict (interpersonal) - escalating
ESLintconflict (interpersonal) - handling
Esprima formatconfounding variable
eval - insecurity ofconsole
event handler - streaming APIcontinuous integration
event loopcontinuous integration - GitHub Actions
exception - for control flowcontinuous integration - Travis CI
exception - handlercontrarian (why not to be)
exception - in promiseCONTRIBUTING file
exception - throwcontrol group
exception - with awaitcontrolled experiments
execution - asynchronousConway's Law
execution - event loopcopyright
execution - non-blockingcoverage - code
execution - single-threadedcoverage - path
execution - streamingCreative Commons
ExpectCreative Commons - CC-BY license
expected result (in unit test)Creative Commons - CC0 license
experimentsCreative Commons - ND clause
experiments - test harnessCreative Commons - no commercial use
exploratory programmingCreative Commons - share-alike
fail (in unit test)crunch mode
filesystem operationsCSS selector - use in testing
finite state machine - correspondence with regular expressionscultural fit (as unconscious bias)
fixture (in unit test)cutting corners
fluent interfaceCVS (version control)
formal verificationdark matter developer
formal verification - Alloydata mining
formal verification - TLA+data structure diagrams
fs.statdead code
function - anonymousdebugger - breakpoint
function - innerdebugger - single-stepping
function - nesteddebugging - concurrent systems
function signaturedebugging - importance of good habits
fuzz testingdebugging - rubber duck
generator functiondebugging - symbolic debugger
Gitdebugging - why schools don't teach
GitHub Pagesdefensive programming
globbingdelta debugging
globbing - filtering resultsdemotivation
greedy algorithmdesign by contract
hash codedesign for test
hash code - in builddesign pattern - model-view-controller
hash code - SHA-1development process
hash functionDevOps
hash function - collisiondiagnostic power (of formative assessment)
hash function - cryptographicdiagrams - conceptual architecture
header file - in C and C++diagrams - data structure
header file - static site generatordiagrams - entity-relationship
helper functiondiagrams - physical architecture
heterogeneous storagediagrams - use-case map
homogeneous storagediagrams - workflow
Hoye, Mikedictionary attack
HTML5 specificationdigital signature - for activity logs
Huffine, Treydiscoverability - of issues
Human Resource Machinediscovery-based learning
immediately-invoked function expressiondiscrimination
immutable datado-ocracy
import - aliasDocker
import moduledocumentation - as communication
import vs. requiredocumentation - embedded
inner functiondocumentation - for competent practitioners
instruction pointerdocumentation - for experts
instruction setdocumentation - for novices
interpreted languagedocumentation - what to include
intrinsic complexitydocumentation generator
introspection - in unit testingdocumentation generator - JSDoc
introspection - of methodsdoi2bib
IstanbulDon't Repeat Yourself
Iterator patterndouble blind experiments
Iterator pattern - generator functiondual coding
Jakedumpster diving
JavaDunning-Kruger effect
JavaScript - hurried design ofdynamic analysis
Jekylldynamic analysis - Valgrind
Jestdynamic typing
JSDoceasy mode (as a metaphor for privilege)
Kernighan, Brianeditor - Emacs
Knuth, Donaldeditor - Notepad
label (on address)effort-importance grid
language - compiledeffort-importance grid - helping triage
language - interpretedEiffel
layout engineelaboration
lexical scopingElbakyan, Alexander
lifecycle - of file interpolationelevator pitch
lifecycle - of unit testEmacs
line commentemail (for team communication)
linking (compiled language)email - filters
linterembedded database - use in testing
Liskov Substitution Principleengineering tradition in computing
literal (in parsing)entity-relationship diagram
literate programmingerror - common
macroerror - external
Makeerror - internal
manifest (of package)error - misperception of frequency
Markdownerror - root cause analysis
Markdown - parsererror message - internationalizing
matching - eagererror message - writing helpful
method chainingESLint
MochaEvans, Julia
Mocha - afterEachExcel
Mocha - beforeEachexception
mock object - for testingexception - handling
module - entry pointexception - raise
module bundlerexception - under-used and abused
module loaderexception - when to check
mutual referencesexfiltrate
namespaceexpected result (in unit test)
nested functionexperimenter bias
Nison, Maëlexpert
non-blocking executionexpert - code comprehension
Nystrom, Bobexpert - documentation needs
OAuthexpert blind spot
op codeexternal error
Open-Closed Principleextraneous load
operator precedence - implementingextrinsic motivation
Oram, Andyfailure
package manifestfairness
parser - check-and-combinefeature boxing
parser - post-hoc compression strategyfeature creep (danger of)
parser - reasons not to writefeature decomposition
parser - shunting-yard algorithmfeedback loops
pass (in unit test)final report
patch numberfinite state machines - use in software design
pattern rule (in build)fixture (in unit test)
PHPfloating-point arithmetic - difficulty of testing
plugin architectureFlon's Axiom
polymorphism (in software design)flow
process.argvflow graph - abstract interpretation
programming style - fluent interfaceflow graph - actual
promise - as alternative to callbackflowchart
promise - automatic creation ofFord, Henry
promise - behaviorformative assessment
promise - catchfunctional decomposition
promise - rejectfuzz testing
promise - resolvegarbage collection - generational
promise - thenGender Decoder
protocol - API asGeneral Data Protection Regulation (GDPR)
protocol - for unit testinggenerational garbage collection
prune (a search tree)germane load
PythonGilliam, Terry
query selectorGit
query selector (for HTML)Git - basic commands
RGit - branch
race conditionGit - branch names
race condition - time of check/time of useGit - cloning project
recipe (in build)Git - commit
recycling dataGit - commit ID
ReduxGit - commit message
register (in computer)Git - configuring
regular expressionGit - conflict
reject promiseGit - creating project
require - caching modulesGit - difference between add and commit
require vs. importGit - graphical interface
resolve promiseGit - HEAD
row-major storage orderGit - history
rule (in build)Git - ignoring files
runnable documentation (assertions as)Git - interface (indistinguishable from hoax)
sandbox (for safe execution)Git - merge
SAT solverGit - post-commit hook
satisfiabilityGit - pre-commit hook
scope - of variable definitionsGit - pull request
scope creep - when writing lessonsGit - pull request - comments
scoping - dynamicGit - reasons for popularity
scoping - lexicalGit - rebase
search - depth-firstGit - recovering old files
search pathGit - remote
search path - shell variableGit - saving changes remotely
semantic versioningGit - showing status
semantic versioning - patch numberGit - viewing differences
setImmediateGit - workflow
setTimeoutGitHub Actions
SHA-1 hash codeGitHub Pages
shell variable (for storing search path)GitLab
shunting-yard algorithmGNU Public License (GPL)
side effect - for module registrationGoal-Question-Metric
signature - of functionGoodhart's Law
sin - using regular expressions to parse HTMLGoogle - unfair hiring practices
single-threaded executionGoogle Summer of Code
Singleton patterngovernance
slug (unique identifier)Graf, David
software design - bare objectGrand Perspective
software design - couplingGUI designer
software design - deferring problemsharassment
software design - design by contractHippocratic License
software design - driverhiring process
software design - encapsulationhiring process - Automattic
software design - generic functionhiring process - healthy
software design - Liskov Substitution Principlehiring process - mistakes
software design - Open-Closed Principlehistory of computing
software design - plugin architecturehitchhiker
software design - polymorphismHomebrew
software design - testabilityHoye, Mike
source maphuman rights
spread - function argumentshumanist tradition in computing
SQLhypercorrection effect
stack frameIDE
stale (in build)IDE - console
Standard JSIDE - in browser
static site generatorIDE - under-used and abused
static site generator - header fileIDE - VS Code
storage - heterogeneousimplicit bias
storage - homogeneousin-memory database - use in testing
storage order - column-majorinequality
storage order - row-majorinsider threat
streaming APIinstant messaging - inevitable use of
streaming API - event handlerinstitutional priorities
string interpolationintellectual property
tagged data structureintellectual property - copyright
target - buildintellectual property - patent
TDDintellectual property - trade secret
Template Method patternintellectual property - trademark
test harnessinternal error
test runnerinternship
test subject (in unit test)interruption bingo (in meetings)
test-driven developmentinterruptions
testability - as design criterionintimate threat
tidyverseintrinsic load
time of check/time of useintrinsic motivation
timestamp - in buildintrospection
token (in parsing)issue - classifying
topological orderissue - description of
transitive closureissue - fields
Turing Machineissue - good titles
two hard problems in computer scienceissue - timestamps
unit test - actual resultissue tracker
unit test - errorissue tracker - as course deliverable
unit test - expected resultissue tracker - helping triage
unit test - failissue tracker - Jira
unit test - fixtureissue tracker - milestones
unit test - interactive applicationissue-tracking system
unit test - lifecycleJava
unit test - passJava - build manager
unit test - requirements forJava - style checker
unit test - test runnerJavaScript
unit test - test subjectJavaScript - style checker
unit test - using mock objectJekyll
University of TorontoJira (issue tracker)
variable definition - scopejust-in-time compiler
version control systemKaplan-Moss, Jacob
version control system - GitKendzior, Sarah
virtual machineLaTeX
virtual machine - op codelearned helplessness
Visitor patternlearner persona
walk a treelearning strategies
WebAIM WAVElearning strategies - concrete examples
Whitehead, Alfred Northlearning strategies - dual coding
Wilson, Greglearning strategies - elaboration
Wolfram Alphalearning strategies - interleaving
learning strategies - retrieval practice
learning strategies - spaced practice
learning styles
legitimate peripheral participation
Lehrer, Tom
lending privilege
license - software
license - why not to write your own
Linux - toxic leadership
logging - during debugging
logging - for security
logging - levels
logging - output format
logging - rotating files
long-term memory
major version number
Make - pattern rule
Make - shortcomings
Markdown - for final report
Martha's Rules
mathematical tradition in computing
meetings (online)
meetings - discussion
meetings - decision
meetings - extra rules for post mortems
meetings - interruption bingo
meetings - three sticky notes
Mencken, H.L.
mental health
mental health (stigma associated with)
mental model
mental model - Git
Mercurial (version control)
merge (in Git)
Microsoft Project
Microsoft Visual Studio Code
Microsoft Word
milestone (in issue tracker)
minor version number
minutes (of meetings)
MIT License
mock object
model - of software development
model-view-controller architecture
model-view-controller architecture - testing
modeling tools - Alloy
modeling tools - TLA+
modular decomposition
motivation - extrinsic
motivation - intrinsic
motivation - self-efficacy
Myers-Briggs Type Indicator
negative results (failure to publish)
Node.js - package.json file
non-disclosure agreement
non-disclosure agreement - abuse of
not invented here syndrome
note-taking (as a learning strategy)
novice - code comprehension
novice - documentation needs
onboarding checklist
open offices (evils of)
Open Source Initiative
Open-Closed Principle
org chart - importance of
package - as course deliverable
package - building
package manager
package manager - APT
package manager - Homebrew
package manager - NPM
package manager - package ratings
package manager - pip
package manifest
pair programming
pair programming - effect of personality
paradox of tolerance
patch (software)
path coverage
peer evaluation
performance review - importance of written criteria for
performance testing - manual
Petre, Marian
Petrov, Andrey
physical architecture - diagram
plugin - for IDE
post mortem
post-commit hook
post-condition - strengthening
Pratchett, Terry
pre-commit hook
pre-condition - weakening
pre-registration of experiments
process - waterfall
Proctorio (invasive surveillance)
product manager
productivity - comparative
productivity - SPACE framework
programmers - happiness
programming - innate ability
programming in the large
programming language - compiled
programming language - dynamically typed
programming language - ease of learning
programming language - interpreted
programming language - statically typed
project course - characteristics of
project manager
project organization - standard files
pseudoscience - learning styles
pseudoscience - Myers-Briggs Type Indicator
pull request
pull request - serial number
Python - PEP8 style guide
Python - style checker
qualitative methods
R (programming language)
radical candor (as bullshit)
raise exception
reading code
reading code - effect of variable names
reading code - eye tracking studies
reading code - fMRI studies
rebasing (in version control)
refactoring - for code review
remote (in Git)
reporting - to your manager
repository (version control)
Representational State Transfer
reproducible example (reprex)
requirements error
retrieval practice
Robinson, Evan
rotating decomposition
rubber duck debugging
sanitizing data
Scalzi, John
Schneier, Bruce
scientific tradition in computing
Scottish verdict
secure deletion tool
security theater
self-confidence (lack of)
semantic versioning
sense vote
Shopify - support for alt-right sites
short-term memory
short-term memory - chunking
short-term memory - limited capacity of
significance hacking
Snowden, Edward
social engineering
sociotechnical congruence
software design - accessibility
software design - evolution
software design - influence of testability
software design - role of diagrams
software design - scriptability
software license
software license - BSD License
software license - GNU Public License (GPL)
software license - Hippocratic License
software license - MIT License
software license - open
software license - why to use the MIT License
software patch
software portal - Bitbucket
software portal - communication tools
software portal - GitHub
software portal - GitLab
SPACE framework
spaced practice
SQL injection attack
Stack Overflow
stand-up meeting
standard project files
static analysis
static site generator
static site generator - Jekyll
static typing
string I/O
style checker
style checker - Black
style checker - Checkstyle
style checker - ESLint
Subversion (version control)
symbolic debugger
Taylor & Francis
team contract
teams - allocating work
teams - benefits of diverse ability levels
teams - dissolving
teams - effect of having friends on
teams - effective size of
teams - isolating at-risk students
teams - learning benefits of
teams - selecting
teams - taking schedules into account
Tech Solidarity
technical debt
test framework
test runner
test suite
test-driven development
testability - influence on software design
threat - casual
threat - insider
threat - intimate
three sticky notes (in meetings)
throw low, catch high
ticketing system
time boxing
time management
timestamp - of Git commit
to-do list
tone policing
toxic people - misperception of
toxic people - rarity of
trade secret
Travis CI
treatment group
triage - using issue tracker
Turbo Pascal
two-factor authentication
type declaration - effect on readability
type declaration - effectiveness at catching bugs
type declaration - use in software design
typing - dynamic
typing - static
unconscious bias
Unified Modeling Language
unit test
unit test - actual result
unit test - browser automation
unit test - code coverage
unit test - expected result
unit test - fixture
unit test - floating-point arithmetic
unit test - fuzzing
unit test - influence on software design
unit test - path coverage
unit test - performance
unit test - profiling
unit test - test framework
unit test - test suite
unit test - visualization
Universal Declaration of Human Rights
University of Toronto
Up & Go
use-case map
user story - use in software design
variable naming
version control
version control - and build manager
version control - centralized
version control - collaboration
version control - collaboration - using a shared repository
version control - collaboration - using forked repositories
version control - CVS
version control - decentralized
version control - Git
version control - inability to handle office documents
version control - Mercurial
version control - reasons to use
version control - repository
version control - Subversion
version control - systems
version control - when to commit
version numbers
version numbers - build
version numbers - major
version numbers - minor
version numbers - patch
version numbers - semantic versioning
Vim editor - exiting
virtual machine
virus scanner
Visual Basic
visualization - difficulty of testing
VS Code
Wales, Jimmy
waste (in software development)
waterfall model
whiteboard coding questions
Wilson, Greg
Wilson, Robert
workflow (in Git)
workflow diagram
working memory