Course run at UKAEA June 2024

[bielsnohr]

trafficstars

We had 11 participants on this run of the course. Below are the notes from instructors about various bits that could be improved or are in error.

Session 1

• Content: Section 1
• For the solution of "Exercise: Obtain the Software Project Locally" it says you should only use SSH. In reality, it is okay for them to use HTTPS, but eventually we do probably want to move to SSH
• There was an issue with ROS setting some weird environment stuff and messing up the virtual environments
• "Git Branches" slide needs to have its image updated in line with the course
  • Done! in mbluteau/june2024-changes branch on the repo
• We should add a note to the slides about doing a demo of the features of VS Code to replace the sections in the course content that does a tour through PyCharm
  • A lot of these things are fairly rudimentary, so it can be quicker to run through them up front rather than getting the scatter that usually happens with
• Add some instructions for helpers about good strategies for checking in on learners (e.g. get up every now and then and do a walk around the room, look at stickies, ask any learners that you might have helped previously how they are getting on, take a look over the shoulder of a few people to see where they are at particularly if we are a bit behind in the schedule)
• Something missing from our "VS Code Extras" is how to make sure that VS Code seamlessly integrates with WSL and its terminal (we had a few learners that were gettting a bit confused about which terminal they were using within VS Code)
  • This is somewhat of a UKAEA specific thing, and we just need better signposting to our internal resources.

Session 2

• Content: Section 2
• Recommend shifting Python versions in the parameterise to be ['3.10', '3.11', '3.12']
• The action versions could do with a bump, setup-python now has tag v5 etc. This will get rid of a lot of the ugly warnings based on action functionality deprecation.
• Recommend adding ids argument to parameterise, e.g. else you can have a test my_test[1-2-None] which is not very informative.
• Explaining how to run one sub-test (encourage quotes for cross-shell compatibility - zsh doesnt like without):

  pytest -k "my_test[iteration-name]"
  

• Mention other useful opts?
  • -s stdout
  • -x terminate on first fail
  • -v show each test by name

Session 3

• Content: Section 3
• Progress through the debugging lesson was very sluggish
  • Partly caused by @mbluteau thinking it was only a recap of the lesson needed rather than going through the whole thing
  • However, it does feel like there is quite a bit in that lesson, and PyCharm being the focus does disrupt the flow quite a bit
  • Had to cut the Edge/Corner Case and Defensive Programming sections
• Made it to the first exercise of the functional programming lesson

Session 4

• Content: Section 3
• !!! We need a better solution for installing the project as a Python package because we keep running into problems with learners getting import errors when running tests !!!
  • This has come up before, but we have never come to a good solution.
  • This note in the testing lesson explains how learners should use python -m pytest <test_file.py> when running their tests in order to avoid the ModuleNotFoundError, but fundamentally this just feels a bit hacky.
  • I am of the opinion that we should just bite the bullet, have a setup.py in the initial project directory and get learners to install their package in editable mode.
• As always, we need some additional/extra lessons for people that get ahead quite quickly
  • This was particularly the case in the Functional programming lesson (and I would imagine the Classes lesson too... TBD)
• In the examples of the Classes episode, inheritance is used for the shapes, but the concept is never introduced or used later on, so it should probably just be removed from the examples. They don't suffer from the removal.
• In the solution of the exercise "Split Out the Model Code from the View Code" the controller code has a mistake where and data_result is used for the graphing, but that data_result is defined anywhere. It should be the return value of analyse_data.

if args.full_data_analysis:
  _, extension = os.path.splitext(InFiles[0])
  if extension == '.json':
    data_source = JSONDataSource(os.path.dirname(InFiles[0]))
  elif extension == '.csv':
    data_source = CSVDataSource(os.path.dirname(InFiles[0]))
  else:
    raise ValueError(f'Unsupported file format: {extension}')
  data_result = analyse_data(data_source)
  graph_data = {
    'standard deviation by day': data_result,
  }
  views.visualize(graph_data)
  return

Session 5

• Content: Section 4

• In one of the exercises, pupils are asked to resolve comments made by their partners on a PR. The exercise says that if there isn't time to resolve a comment, they should open an issue and link back to the comment. Many of the pupils didn't seem to know what an issue was, and issues are disabled on forked GitHub repositories by default. So there was a decent chunk of time a) explaining what an issue was, b) showing how to enable issues (after working it out ourselves) and c) showing how to open one, which I think was out of the scope of this section and is covered in section 5.

  While the advice in the exercise is obviously good advice, it did lead the class down a bit of a rabbit-hole. I'm not aware of any students that actually ended up opening an issue at this point.

• In the 'Empathy in review comments' slide, one of the bullet points says:

  'Only provide a few non-critical suggestions - you are aiming for better rather than perfect'

  Which I don't really agree with. I don't think pupils should go away feeling like the number of comments they make on a PR should be limited. They should make as many comments as they feel are appropriate; particularly if the PR is on the larger side. I took this bullet-point out when delivering the course.

• In the 'Code Review in Your Own Working Environment' exercise, I didn't get any feedback/conversation at the end. This may well just have been due to the way I delivered it, but for instructors delivering this section in the future: it may be useful to talk through an example process, or write some questions at the beginning of the session that will be asked at the end. I think this might help with engagement.

• I felt the break time was misplaced in the slides. We broke after the code review section (which had lots of time-consuming exercises), then got through the reuse and packaging sections (which were less exercise heavy) after the break.

Session 6

• Content: Section 5
• There are not any slides for the first episode of this section
• We should have an explicit section in the course where the owner of the group's code repo adds all the collaborators