Merge recent updates from gh-pages, resolve conflicts

.gitignore

@@ -22,3 +22,4 @@ venv/
 .venv/
 .*history
 .tool-versions
+.vscode/

_episodes/10-section1-intro.md

@@ -15,7 +15,8 @@ you need to use a number of different tools."
 to decide which tool is right for you, which may be a matter of personal preference or what the team or community you belong to is using."
 ---
 
-The first section of the course is dedicated to setting up your environment for collaborative software development.
+The first section of the course is dedicated to setting up your environment for collaborative software development
+and introducing the project that we will be working on throughout the course.
 In order to build working (research) software efficiently
 and to do it in collaboration with others rather than in isolation,
 you will have to get comfortable with using a number of different tools interchangeably
@@ -86,6 +87,17 @@ issue management,
 code review,
 code testing/Continuous Integration,
 and collaborative development.
+An important concept in collaborative development is version control workflows
+(i.e. how to effectively use version control on a project with others).
+
+### Python Coding Style
+Most programming languages will have associated standards and conventions for how the source code
+should be formatted and styled.
+Although this sounds pedantic,
+it is important for maintaining the consistency and readability of code across a project.
+Therefore, one should be aware of these guidelines
+and adhere to whatever the project you are working on has specified.
+In Python, we will be looking at a convention called PEP8.
 
 Let's get started with setting up our software development environment!
 

_episodes/13-ides.md

@@ -492,7 +492,8 @@ including:
   inline documentation ([*docstrings*](../15-coding-conventions/index.html#documentation-strings-aka-docstrings)
   for any symbol created in accordance with [PEP-257](https://peps.python.org/pep-0257/)
 - Parameter Info -
-  the names of parameters in method and function calls
+  the names and expected types of parameters in method and function calls.
+  Use this when cursor is on the argument of a function call.
 - Type Info -
   type of an expression
 

_episodes/14-collaboration-using-git.md

@@ -105,9 +105,9 @@ sequenceDiagram
     Staging Area->>+Local Repository: git commit
     Local Repository->>+Remote Repository: git push
     Remote Repository->>+Local Repository: git fetch
-    Local Repository->>+Staging Area:git checkout
+    Local Repository->>+Staging Area:git checkout / git switch
     Local Repository->>+Staging Area:git merge
-    Remote Repository->>+Working Directory: git pull (shortcut for git fetch followed by git checkout/merge)
+    Remote Repository->>+Working Directory: git pull (shortcut for git fetch followed by git merge/rebase)
 -->
 <!--
 SVG of the diagram can be downloaded from:
@@ -416,10 +416,10 @@ $ git branch
 
 The `*` indicates the currently active branch.
 So how do we switch to our new branch?
-We use the `git checkout` command with the name of the branch:
+We use the `git switch` command with the name of the branch:
 
 ~~~
-$ git checkout develop
+$ git switch develop
 ~~~
 {: .language-bash}
 
@@ -432,7 +432,7 @@ Switched to branch 'develop'
 > A shortcut to create a new branch and immediately switch to it:
 >
 > ~~~
-> $ git checkout -b develop
+> $ git switch -c develop
 > ~~~
 > {: .language-bash}
 >
@@ -461,7 +461,7 @@ $ git status
    On branch develop
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
-     (use "git checkout -- <file>..." to discard changes in working directory)
+     (use "git restore <file>..." to discard changes in working directory)
 
    	modified:   inflammation/models.py
 
@@ -496,14 +496,14 @@ You can check that in GitHub by listing all branches.
 ![Software project's main branch](../fig/software-project-main-branch.png){: .image-with-shadow width="700px"}
 
 To push a new local branch remotely for the first time,
-you could use the `-u` switch and the name of the branch you are creating and pushing to:
+you could use the `-u` flag and the name of the branch you are creating and pushing to:
 
 ~~~
 $ git push -u origin develop
 ~~~
 {: .language-bash}
 
-> ## Git Push With `-u` Switch
+> ## Git Push With `-u` Flag
 > Using the `-u` switch with the `git push` command is a handy shortcut for:
 > (1) creating the new remote branch and
 > (2) setting your local branch to automatically track the remote one at the same time.
@@ -558,10 +558,10 @@ $ git push origin develop
 ### Merging Into Main Branch
 Once you have tested your changes on the `develop` branch,
 you will want to merge them onto the `main` branch.
-To do so, make sure you have all your changes committed and switch to `main`:
+To do so, make sure you have committed all your changes on the `develop` branch and then switch to `main`:
 
 ~~~
-$ git checkout main
+$ git switch main
 ~~~
 {: .language-bash}
 

_episodes/15-coding-conventions.md

@@ -168,7 +168,7 @@ More details on good and bad practices for continuation lines can be found in
 All lines should be up to 80 characters long;
 for lines containing comments or docstrings (to be covered later)
 the line length limit should be 73 -
-see [this discussion](https://stackoverflow.com/questions/15438326/python-pep-8-docstring-line-length)
+see [this discussion](https://stackoverflow.com/q/15438326)
 for reasoning behind these numbers.
 Some teams strongly prefer a longer line length,
 and seemed to have settled on the length of 100.
@@ -424,8 +424,8 @@ because an incorrect comment causes more confusion than no comment at all.
 > and switch to it (from the project root):
 >
 > ~~~
-> $ git checkout develop
-> $ git checkout -b style-fixes
+> $ git switch develop
+> $ git switch -c style-fixes
 > ~~~
 >  {: .language-bash}
 >
@@ -727,10 +727,10 @@ to double check which branch you are on and its status):
 
 ~~~
 $ git push -u origin style-fixes
-$ git checkout develop
+$ git switch develop
 $ git merge style-fixes
 $ git push origin develop
-$ git checkout main
+$ git switch main
 $ git merge develop
 $ git push origin main
 ~~~

_episodes/16-verifying-code-style-linters.md

@@ -27,7 +27,7 @@ Let's look at a very well used one of these called `pylint`.
 First, let's ensure we are on the `style-fixes` branch once again.
 
 ~~~
-$ git checkout style-fixes
+$ git switch style-fixes
 ~~~
 {: .language-bash}
 
@@ -183,10 +183,10 @@ and merge onto your development and main branches.
 $ git add requirements.txt
 $ git commit -m "Added Pylint library"
 $ git push origin style-fixes
-$ git checkout develop
+$ git switch develop
 $ git merge style-fixes
 $ git push origin develop
-$ git checkout main
+$ git switch main
 $ git merge develop
 $ git push origin main
 ~~~

_episodes/21-automatically-testing-software.md

@@ -88,9 +88,9 @@ And then, we'll create a new feature branch called `test-suite` off the `develop
 a common term we use to refer to sets of tests - that we'll use for our test writing work:
 
 ~~~
-$ git checkout develop
+$ git switch develop
 $ git branch test-suite
-$ git checkout test-suite
+$ git switch test-suite
 ~~~
 {: .language-bash}
 
@@ -413,9 +413,9 @@ but what you learn can scale to more complex functional testing for applications
 > Other unit testing frameworks exist for Python,
 > including Nose2 and Unittest,
 > and the approach to unit testing can be translated to other languages as well,
-> e.g. FRUIT for Fortran,
+> e.g. pFUnit for Fortran,
 > JUnit for Java (the original unit testing framework),
-> Catch for C++, etc.
+> Catch or gtest for C++, etc.
 {: .callout}
 
 > ## Why Use pytest over unittest?
@@ -516,7 +516,9 @@ Notice the `..` after our test script:
   The error is included in the output so we can see what went wrong.
 
 So if we have many tests, we essentially get a report indicating which tests succeeded or failed.
-Going back to our list of requirements, do we think these results are easy to understand?
+Going back to our list of requirements (the bullets under [Using a Testing
+Framework](#using-a-testing-framework)),
+do we think these results are easy to understand?
 
 > ## Exercise: Write Some Unit Tests
 >

_episodes/23-continuous-integration-automated-testing.md

@@ -421,7 +421,7 @@ involving multiple commits,
 on a separate feature branch until it's ready to be escalated to the `develop` branch:
 
 ~~~
-$ git checkout develop
+$ git switch develop
 $ git merge test-suite
 ~~~
 {: .language-bash}

_episodes/24-diagnosing-issues-improving-robustness.md

@@ -710,9 +710,7 @@ Since we're adding an extra feature to our CI workflow,
 let's start this from a new feature branch from the `develop` branch:
 
 ~~~
-$ git checkout develop
-$ git branch pylint-ci
-$ git checkout pylint-ci
+$ git switch -c pylint-ci develop # note a shorthand for creating a branch from another and switching to it
 ~~~
 {: .language-bash}
 

_episodes/34-functional-programming.md

@@ -477,15 +477,15 @@ One example of reducing would be to calculate the product of a sequence of numbe
 ~~~
 from functools import reduce
 
-l = [1, 2, 3, 4]
+sequence = [1, 2, 3, 4]
 
 def product(a, b):
     return a * b
 
-print(reduce(product, l))
+print(reduce(product, sequence))
 
 # The same reduction using a lambda function
-print(reduce((lambda a, b: a * b), l))
+print(reduce((lambda a, b: a * b), sequence))
 ~~~
 {: .language-python}
 ~~~
@@ -505,15 +505,15 @@ you need to import it from library `functools`.
 > > ~~~
 > > from functools import reduce
 > >
-> > l = [1, 2, 3, 4]
+> > sequence = [1, 2, 3, 4]
 > >
 > > def add(a, b):
 > >     return a + b
 > >
-> > print(reduce(add, l))
+> > print(reduce(add, sequence))
 > >
 > > # The same reduction using a lambda function
-> > print(reduce((lambda a, b: a + b), l))
+> > print(reduce((lambda a, b: a + b), sequence))
 > > ~~~
 > > {: .language-python}
 > > ~~~
@@ -532,8 +532,8 @@ using the MapReduce approach.
 ~~~
 from functools import reduce
 
-def sum_of_squares(l):
-    squares = [x * x for x in l]  # use list comprehension for mapping
+def sum_of_squares(sequence):
+    squares = [x * x for x in sequence]  # use list comprehension for mapping
     return reduce(lambda a, b: a + b, squares)
 ~~~
 {: .language-python}
@@ -577,8 +577,8 @@ The code may look like:
 ~~~
 from functools import reduce
 
-def sum_of_squares(l):
-    integers = [int(x) for x in l]
+def sum_of_squares(sequence):
+    integers = [int(x) for x in sequence]
     squares = [x * x for x in integers]
     return reduce(lambda a, b: a + b, squares)
 ~~~
@@ -606,8 +606,8 @@ To do so, we may filter out certain elements and have:
 ~~~
 from functools import reduce
 
-def sum_of_squares(l):
-    integers = [int(x) for x in l if x[0] != '#']
+def sum_of_squares(sequence):
+    integers = [int(x) for x in sequence if x[0] != '#']
     squares = [x * x for x in integers]
     return reduce(lambda a, b: a + b, squares)
 ~~~

_episodes/36-architecture-revisited.md

@@ -276,8 +276,10 @@ class Patient(Person):
         super().__init__(name)
 
         self.observations = []
+        ### MODIFIED START ###
         if observations is not None:
             self.observations = observations
+        ### MODIFIED END ###
 
     def add_observation(self, value, day=None):
         if day is None:
@@ -327,6 +329,7 @@ def main(args):
     for filename in infiles:
         inflammation_data = models.load_csv(filename)
 
+        ### MODIFIED START ###
         if args.view == 'visualize':
             view_data = {
                 'average': models.daily_mean(inflammation_data),
@@ -342,6 +345,7 @@ def main(args):
             patient = models.Patient('UNKNOWN', observations)
 
             views.display_patient_record(patient)
+        ### MODIFIED END ###
 
 
 if __name__ == "__main__":
@@ -353,6 +357,7 @@ if __name__ == "__main__":
         nargs='+',
         help='Input CSV(s) containing inflammation series for each patient')
 
+    ### MODIFIED START ###
     parser.add_argument(
         '--view',
         default='visualize',
@@ -364,6 +369,7 @@ if __name__ == "__main__":
         type=int,
         default=0,
         help='Which patient should be displayed?')
+    ### MODIFIED END ###
 
     args = parser.parse_args()
 

_episodes/42-software-reuse.md

@@ -269,7 +269,7 @@ sufficiently well to make their own changes to it,
 including external developers, other members in your team and a future version of yourself too.
 This may include documentation that covers the software's architecture,
 including its different components and how they fit together,
-API (Application Programmer Interface) documentation
+API (Application Programming Interface) documentation
 that describes the interface points designed into your software for other developers to use,
 e.g. for a software library,
 or technical tutorials/'HOW TOs' to accomplish developer-oriented tasks.
@@ -348,7 +348,7 @@ and if you're doing this work on a feature branch also ensure you merge it into
 e.g.:
 
 ~~~
-$ git checkout develop
+$ git switch develop
 $ git merge my-feature-branch
 ~~~
 {: .language-bash}
@@ -358,7 +358,7 @@ and are confident it works as expected on `develop`,
 we can merge our `develop` branch into `main`:
 
 ~~~
-$ git checkout main
+$ git switch main
 $ git merge develop
 $ git push
 ~~~

_episodes/52-assessing-software-suitability-improvement.md

@@ -44,7 +44,9 @@ will help you adopt the same attitude when assessing your own software for futur
 > Time: 5 mins
 >
 > 1. Decide as a team on one of your repositories that will represent your group.
->    You can do this any way you wish.
+>    You can do this any way you wish,
+>    but if you are having trouble then a pseudo-random number might help:
+>    `python -c "import numpy as np; print(np.random.randint(low=1, high=<size_group_plus_1>))"`
 > 2. Add the URL of the repository to
 >    the section of the shared notes labelled 'Decide on your Group's Repository',
 >    next to your team's name.

_extras/persistence.md

@@ -213,6 +213,7 @@ we'll use the format we used as JSON example earlier.
 # file: inflammation/serializers.py
 
 import json
+from inflammation import models
 
 class PatientSerializer:
     model = models.Patient