Meeting notes 2024-09-11¶

R: #52. The course content seems a bit scattered, as I cannot conclude a rule that is used to yes/no discuss a topic. I think it would be good to have a clear rule behind our course material what should and what should not be discussed at this course. I hope we can suggest some rules and then vote for our favorite.
- R: Only what is used by the student project is course content. The student project is a piece of maintainable and tested Python code.
- R: if possible, vote for a rule
- [WINNER][as voted in meeting] Only what is used by the student project is course content, with alternatives relevant to academics provided in lecture (rest of extra material) to what we do
R: #45 We discussed reordering the course material and that everyone would come up with a suggestion. What is the progress for everybody in this?
- R: my ideas are in my reflections of the last course iteration. Biggest change: learning the basic tools, i.e. git at day 1, so we can then focus on theory. Maybe make next week a deadline for this?
- [RESULT][copied from HackMD] We now have:
  - Monday morning:
    - Björn: course overview
    - Björn: basic git
  - Monday afternoon: Requirements modeling and risk assessment
    - Lars: Define the project
    - Make formal requirements model
    - Make formal risk assessment
  - Tuesday: Git setup and version control, from a reproducible research and social coding/development perspective
    - Organize the project
  - Wednesday: Test-Driven Development (TDD) and function design
  - Thursday and Friday morning: Test-Driven Development and class design (TDD)
    - Implement the project as a package
  - Friday afternoon: Deployment and documentation
R: #56 can we convert the slides to website pages (or can they be deleted?) It will make the GitHub repo less messy. I volunteer to do this and/or help with this
- [MOVED TO FUTURE MEETING]
R: #57 what do we think about giving advice (e.g. 'Always do X') without a reference to the literature?
- R: I think most of our advice should be backed up by a reference to the literature, to prevent teaching what we do, but teach what one should do instead
- [MOVED TO FUTURE MEETING]

Copy paste from HackMD notes¶

# Programming formalisms for life scientists and bioinformaticians

Main page: https://github.com/UPPMAX/programming_formalisms
Rendered page: https://uppmax.github.io/programming_formalisms/


## Zoom meetings
- will be called when needed
- most issues shall be resolved through github issues
- if meeting is requested i will be posted in the slack channel and the below meeting id will be used.

https://uu-se.zoom.us/j/63272190301 (Passcode: 880630)
- every Wed 11.00

## Course Autumn 2024
- 📅 week 47 Mon-Fri Nov 18–22


## Meeting 11 sep 11:00-12:00
### Food for thought
#### Programming Formalism

##### Where is the Formalism?

Understanding the need for **requirements modeling** and **risk assessment** is essential. These steps should be integral to the project and not omitted simply because they aren't currently included.

A possible schedule could look like this:

- **Monday morning**:
  - Björn: course overview
  - Björn: basic git
- **Monday afternoon**: Requirements modeling and risk assessment
    - Lars: Define the project
    - Make formal requirements model
    - Make formal risk assessment
- **Tuesday**: Git setup and version control, from a reproducible resarch and social coding/development perspective
    - Organize the project
- **Wednesday**: Test-Driven Development (TDD) and function design
- **Thursday and Friday morning**: Test-Driven Development and class design (TDD)
    - Implement the project as a package
- **Friday afternoon**: Deployment and documentation

- UML,Mermaid AI assisted devlopment left as extra excersies read on your own for those who are extra fast or just whant to delv into the subject outside of the alloted time.

- **Key concepts of the course**

    - Software life cycle
    - Requirments Modeling
    - Version control
    - Pair-programmming
    - TDD
    - Fundamentals of algorithms

##### Object-Oriented (OO) Concepts and Modularity

The concepts of object-oriented programming and modularity could be integrated into the practical TDD exercises. For example, the simple discovery model that Richel uses could guide the generation of classes. While class modeling and UML might be better suited for another course, these concepts could be derived from a well-written requirements model and a solid risk assessment.

##### Importance of Risk Assessment

Risk assessment is critical not only for understanding the overall project risks but also for determining what constitutes a **complete test**. This goes beyond unit or function testing.

By following this structure, we would have three days (Wednesday to Friday) to implement the project that has been first modeled on Monday and then set up in Git on Tuesday.

### Discuss

- R: The course content seems a bit scattered, as I cannot
  conclude a rule that is used to yes/no discuss a topic.
  I think it would be good to have a clear rule behind our course
  material what should and what should not be discussed at this course.
  I hope we can suggest some rules and then vote for our favorite.
  - Rule 1: Only what is used by the student project is course content.
    The student project is a piece of maintainable and tested Python code.
    - vote: R
  - [WINNER] Rule 2: Only what is used by the student project is course content,
    with alteratives relevant to academics provided in lecture
    (rest of extra material) to what we do
    - vote: BC, L

- R: if possible, vote for a rule
    - BCs suggestion:
        - Overview of tools, workflow and formalisms kept but shorten.
        - all discussions and exercises and testable understanding should be related to
            - academians
            - make effective programming development in projects
            - make software
                - reusable
                - understandable/-stood
                - installable
- R: We discussed reordering the course material and that everyone would
  come up with a suggestion. What is the progress for everybody in this?
  - R: my ideas are in
    [my reflections of the last course iteration](https://github.com/UPPMAX/programming_formalisms/tree/main/reflections/2024_summer).
    Biggest change: learning the basic tools, i.e. `git` at day 1, so we can
    then focus on theory. Maybe make next week a deadline for this?
  - BC may come back on this point but now:
      - we cannot put equally much effort on this course as we have done before. It is not new any longer and we have come far
      - i.e. no major changes like the restructuring in spring again
  - Still BC want to include deployment for the project itself

### Status
 - Lars
 - Richel
 - Björn

## Goal for next week

- Discuss evaluations
- Sketch future schedule during meetug


### If time allows

### Action points from evaluation
#### General
- breaks should be for breaks
- learners don't read instructions in breaks
#### Monday
- We don't have workflows in the course yet.
    - We often discuss what to put in yes/no
  and we feel now the other topics are even more important

#### Wednesday
- Switching between VS-code and github caused some trouble in updating the branches on the terminal, causing some confusion in merging branches (solving conflicts)
    - This is a technical issue we cannot help.
We hope there is enough time to fix the expected unexpected problems.
    - BC just learned that sync between GH and VS code should be easy, not needing ssh-keys
        shaing prereqs?

- Switching between users in pair-programming takes time. So maybe more time might be needed.
  - Agreed that this takes time. We hope there is enough time to do so.

### Richel's reflections
- Björn waited until now (:pensive:) to look at these
    - very valuable though
- Questions:
    - define discussion
        - student discussion?
        - lesson material just covered in material and talk