lectures/revealjs/04-individual-oblig.adoc

+= Individuell obligatorisk øving
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Øving 1
+:LECTURE_NO:  4th lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2023 - {LECTURE_NO}
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+
+- Administrative issues
+- Individual exercise
+- Build tools
+- Summary
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+== Groups
+
+- fill the form to be assigned to a group
+- https://s.ntnu.no/it1901groups
+- deadline: today, 31. august 16:00
+- will announce next week
+- the late comers to the course will have a bit more time 
+
+
+== Approaching Deadlines
+
+- Torsdag , 31. august 16:00
+** Fill the group form
+
+- Torsdag 7. september / 18:00 
+** 1st individual deliverable 
+
+
+== Help tools
+
+- Piazza for the course is up and running
+- Helpdesk is up and running
+- Relevant links and info in Blackboard
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Individual exercise
+
+
+== Læringsmål for øvingen
+
+* grunnleggende git-ferdigheter
+* oppsett av java-prosjekt med maven
+* sammenheng mellom navn, struktur og innhold
+* oppfriskning om javafx og fxml
+* generell feilfinning
+
+== Hensikt
+
+Alle skal kunne bidra til prosjektet!!!
+
+== Grunnleggende git-ferdigheter
+
+* opprett kodelager på gitlab
+* klone mal-kodelager (`git clone`)
+* knytte kodelager til annet fjernlager (`git remote`)
+* overføre til fjernlager (`git push`)
+* lage nye versjoner (`git add` og `git commit`)
+
+== Java-prosjektoppsett m/maven
+
+* kildekodemapper og pakkehierarki
+** **src/main/java** og **src/main/resources**
+** **src/test/java** (og **src/test/resources**)
+* pakkehierarki og mappestruktur
+** pakkenavn(segmenter) tilsvarer mappestruktur
+** både kode og ressurser hører til pakker
+** `getClass().getResource(...)`
+
+== Navn, struktur og innhold
+
+* klasser og filer, pakker og mapper
+* konfigurasjon i pom.xml
+** klassenavn (og modulnavn)
+** kommandolinje-argumenter
+* **module-info.java**
+** modulnavn i deklarasjon og `requires`
+** pakkenavn i `exports` og `opens`
+
+== Navn, struktur og innhold
+
+* **pom.xml**
+** konfigurasjon av maven-tillegg
+** inkl. kjøring av tester og app
+** klassenavn (og modulnavn)
+** kommandolinje-argumenter
+
+== Oppfriskning om javafx og fxml
+
+[.smaller-80]
+* rollefordeling mellom domene- og kontroller-klasse(r)
+* kobling mellom fxml og kontroller-klasse
+** **fx:id** og **onXyz**-attributter i fxml-fil
+** felt og metoder i kontroller-klasse
+* programflyt i kontroller
+** initiell visning av tilstand
+** reaksjon på hendelser
+** oppdatering av visning
+
+== Generell feilfinning
+
+[.smaller-80]
+* tolke symptomer
+** hvorfor reagerer ikke appen?
+** hvordan finne ledetråder i "stacktracen"?
+** hvorfor kalles ikke metoden?
+* løse problemet
+** utvikle hypoteser om årsaker
+** validere (eller falsifiere) hypoteser
+** prøve ut løsninger
+
+== Main steps
+
+- set up the repo in gitlab
+** create a project under students-2023
+** use the javafx-template as a starting point
+- change the template
+** project name
+** packages
+- implement the missing logic
+** check by running the tests
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Demo time
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Build tools
+
+== Build tools (1)
+
+[%step]
+- Automate the process of building executable programs from source files
+- Packaging binaries required for deployment / distribution
+- Run automated tests
+
+== Build tools (2)
+
+[%step]
+- Build automation is a necessity to enable CI/CD
+- Remove the need to do redundant tasks
+- Improve quality of the software
+	** the software builds are prepared in a consistent and predictable manner
+	** possible to have data to analyze issues and improve
+
+== Make (1)
+
+[%step]
+- Designed by Stuart Feldman
+- Released in 1976
+- Uses makefiles to describe the actions required to produce the build
+- Manages dependencies
+
+[.smaller-40]
+https://en.wikipedia.org/wiki/Make_(software)
+
+== Make (2)
+
+[%step]
+- Has been rewriten a number of times
+- Standard modern implementation is GNU Make
+- Used in Linux and Mac OS
+
+== Java world build tools
+
+- Ant with Ivy
+- Maven
+- Gradle
+
+== Apache ANT
+
+[%step]
+- modern build system
+- released in 2000
+- build files use XML
+	** tends to get unmanageable even for small projects
+- Apache Ivy for managing dependencies (added later)
+	** download over network
+
+[.smaller-40]
+http://ant.apache.org
+
+== Apache Maven (1)
+
+[%step]
+- released in 2004
+- improves on ANT
+- build files use also XML but the structure is radically different
+- dependency management with automatic downloading over the network is available from release
+
+[.smaller-40]
+http://maven.apache.org
+
+== Apache Maven (2)
+
+[%step]
+- hides complexity in build files through plugins 
+- customizing is hard
+- dependency management has issues with conflicting versions of same library  
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Gradle
+
+
+== Gradle (1)
+
+[%step]
+- released in 2012
+- build scripts are written in a domain specific language based on Groovy
+	**  Groovy ( http://www.groovy-lang.org/ )
+- the build script is named `build.gradle`
+- build steps are called "tasks"
+
+[.smaller-40]
+https://gradle.org
+
+
+== Gradle (2)
+
+[%step]
+- easy to create own tasks
+- uses plugins to hide complexity 
+- applying plugins allows access to additional tasks 
+
+
+== Gradle (3)
+
+[.center-paragraph]
+image::../images/lecture03/gradle-tree.png[width=700]
+
+[.smaller-40]
+https://guides.gradle.org/creating-new-gradle-builds/
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== More on Maven
+
+== Maven (3)
+
+* manages builds, dependencies, versions 
+* configuration file is `pom.xml`
+* has good IDE support
+* central repository(ies) for dependencies
+
+== Maven - pom.xml
+
+* modelVersion (4.0.0) config file format version
+* groupId - ID of group owning the project 
+* artifactId - name of the final output
+* version  - version of the created artifact
+
+== Maven - pom.xml (cont.)
+
+* dependencies - list of artifacts we depend upon
+* packaging - e.g. .jar (Java archive)
+* description 
+
+https://maven.apache.org/pom.html#Quick_Overview
+
+== Maven dependencies
+
+* list of dependencies 
+* each dependecy has specified
+** groupId
+** artifactId
+** version (optional, good to have)  
+** scope (default is `compile`)
+
+
+
+
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+
+== Next week
+
+[.smaller-80]
+* set up groups
+* set up repositories 
+* announce 1 group exercise
+* start working with the group exercise and group contract
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/04-lecture-admin.adoc

+= Scrum / Gitlab
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Scrum / Gitlab
+:LECTURE_NO: 4th lecture
+
+include::{includedir}header.adoc[]
+
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2022 - {LECTURE_NO}
+
+== Overview
+
+- Administrative issues
+- Group contract
+- Scrum
+- Gitlab
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+
+== Administrative issues
+
+- Reference group
+- Groups
+- Getting help
+- Upcoming deliverables
+
+== Reference group (1)
+
+- Special thanks to the reference group volunteers for their interest in the course.
+- we selected a representative mix in the order of volunteering
+- you can see the contact info in Blackboard
+- questions regarding the course organization and proposals for improvements should be communicated to the reference group
+- half of the reference group has been randomly selected to have a balanced set of representatives
+
+
+== Reference group (2)
+
+- vebjorbl@stud.ntnu.no	Vebjørn Falk Blom-Hagen
+- hanneswi@stud.ntnu.no	Hannes Witt	
+- johanlm@stud.ntnu.no	Johannes Landmark Meldal
+- adelefe@stud.ntnu.no	Adele Felicia Ellingsen-Grønningsæther
+- olejme@stud.ntnu.no	Ole Jacob Mellgren
+- elintes@stud.ntnu.no	Elin Tesaker
+
+
+
+== Groups
+
+- groups have been formed based on the form and input from students
+- will be uploaded in BlackBoard tomorrow
+- for issues with groups contact Farzana Quayyum <farzana.quayyum@ntnu.no>
+- several of the enrolled students have not been distributed to groups
+- we will proceed to create the gitlab groups with the same composition as the Blackboard groups ASAP
+ 
+== Getting help
+
+- Use piazza instead of sending individual emails to staff
+- technical help-desk will be shortly operating
+- A TA will be assigned to each group 
+** subject matter and group related questions should be addressed to them
+
+
+== Upcoming deliverables (1)
+- 1st individual assignment 
+- deadline on this Thursday at midnight
+- not all requested access for 1st individual assignment
+- this is a mandatory exercise, you cannot get a grade in the course if you do not pass it
+
+== Upcoming deliverables (2)
+
+- group contract
+- deadline one week from announcing the groups
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Group contract
+
+
+== Group contract (0) 
+
+- contact the other members of your group
+- start working on the group contract
+
+== Group contract (1)
+- Minimum requirements for agreement:
+** Presence
+** Time spent
+** Expectations for the individual contribution
+** What happens in the event of deviations or disagreements
+
+
+== Group contract (2)
+* must be approved by the TA for the group 
+* signed by all group members 
+* and delivered this Friday by 16:00
+
+== Group contract (3)
+- more recommended items:
+** handling differences in motivation level and ambition
+** what quality is expected, how defines the group something to be "done"
+** distribution of time between meetings / group work / individual work
+** what happens if course work needs more time than expected
+
+== Group contract (4)
+- more recommended items:
+** delays, sickness, absence - how does the group handle these
+** meeting routines both for physical and virtual (agreement for time, agenda, meeting minutes etc)
+** general communication tools (email, phone, im etc) and response time
+** dealing as a group with deliverables and deadlines 
+
+== Group contract (5)
+- more recommended items:
+** roles 
+** giving feedback to the others  
+** dealing with conflicts and disagreements
+** dealing with breach of contract
+** procedure to follow if the group is not able to solve conflicts / disagreements internally
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Scrum
+
+== About domain selection
+
+- choose an app / service that you know well and select a couple of features to implement during the semester
+- point is to learn by implementing these using the required architectures
+- we are not looking for quantity but for quality, so just few core features will suffice
+
+== About domain selection (2)
+
+- the chosen app needs to be suitable for a cloud based service
+- there must therefore be some dynamic data per user managed by the server. 
+- eg. a (currency) calculation will NOT fit such a project. 
+- one good starting point are the cases from the HCI course (MMI)
+
+
+== User stories
+
+[.smaller-80]
+- short, simple descriptions for application features 
+- formulated from the stand point of the user / customer
+- template: 
+** As a **< type of user >**, I want **< some goal >** so that **< some reason >**.
+- they are not replacing design documents  / requirements specification
+- they need to be developed into specific tasks and connected to constraints and other meaningful documentation. 
+
+== Sprints
+- meaningful iterations of comparable length
+- they should have a clear goal
+
+== Planning releases
+- 3 deliverables - map to releases
+- a release should produce a minimum viable product (MVP)
+** a MVP is a version of an application with just enough features to be usable in getting feedback to guide the development process 
+
+
+== Meetings
+- regular stand-up meetings (synchronize and commit, remove hindrances)
+- retrospectives (reflect on your group work)
+- sprint reviews / demos (invite TA, prepare deliverables)
+
+== Pair programming
+
+- popular agile development  technique
+- recommended to be used in your groups
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Gitlab
+
+== Gitlab -Issue tracking
+
+- Issues
+- Labels
+- Milestones
+- Boards
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Gitlab demo
+
+include::{includedir}footer.adoc[]

lectures/revealjs/04-lecture.adoc

+= Scrum / Gitlab
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Scrum / Gitlab
+:LECTURE_NO: 4th lecture
+
+include::{includedir}header.adoc[]
+
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2022 - {LECTURE_NO}
+
+== Overview
+
+- Administrative issues
+- Group contract
+- Scrum
+- Gitlab
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+
+== Administrative issues
+
+- Reference group
+- Groups
+- Getting help
+- Upcoming deliverables
+
+== Reference group (1)
+
+- Special thanks to the reference group volunteers for their interest in the course.
+- we selected a representative mix in the order of volunteering
+- you can see the contact info in Blackboard
+- questions regarding the course organization and proposals for improvements should be communicated to the reference group
+
+
+== Reference group (2)
+
+- August Sætre Aasvær	augustsa@stud.ntnu.no	
+- Skage Klingstedt Reistad	skagekr@stud.ntnu.no
+- Iver Baardsgaard Brønstad	iverbb@stud.ntnu.no
+- Anna Østmo	annaost@stud.ntnu.no
+- Mats Ellingsen	matsel@stud.ntnu.no
+- Victoria Kjerstin Huaco Simensen	vksimens@stud.ntnu.no
+
+
+== Groups
+
+- groups have been formed based on the form and input from students
+- check in BlackBoard if you are in a group
+- for issues with groups contact Farzana Quayyum <farzana.quayyum@ntnu.no>
+- 338 out of the 353 enrolled students have been distributed to groups
+- we will proceed to create the gitlab groups with the same composition as the Blackboard groups ASAP
+ 
+== Getting help
+
+- Use piazza instead of sending individual emails to staff
+** 192 out of 338 students have registered in piazza
+- If relevant you can use the technical help-desk
+** how to access it and use it is posted in Blackboard 
+- A TA will be assigned to each group 
+** subject matter and group related questions should be addressed to them
+
+
+== Upcoming deliverables (1)
+- 1st individual assignment 
+- deadline on this Friday at 16:00
+- 271 out of 338 - requested access for 1st individual assignment
+- this is a mandatory exercise, you cannot get a grade in the course if you do not pass it
+
+== Upcoming deliverables (2)
+
+- group contract
+- deadline on this Friday at 16:00
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Group contract
+
+
+== Group contract (0) 
+
+- contact the other members of your group
+- start working on the group contract
+
+== Group contract (1)
+- Minimum requirements for agreement:
+** Presence
+** Time spent
+** Expectations for the individual contribution
+** What happens in the event of deviations or disagreements
+
+
+== Group contract (2)
+* must be approved by the TA for the group 
+* signed by all group members 
+* and delivered this Friday by 16:00
+
+== Group contract (3)
+- more recommended items:
+** handling differences in motivation level and ambition
+** what quality is expected, how defines the group something to be "done"
+** distribution of time between meetings / group work / individual work
+** what happens if course work needs more time than expected
+
+== Group contract (4)
+- more recommended items:
+** delays, sickness, absence - how does the group handle these
+** meeting routines both for physical and virtual (agreement for time, agenda, meeting minutes etc)
+** general communication tools (email, phone, im etc) and response time
+** dealing as a group with deliverables and deadlines 
+
+== Group contract (5)
+- more recommended items:
+** roles 
+** giving feedback to the others  
+** dealing with conflicts and disagreements
+** dealing with breach of contract
+** procedure to follow if the group is not able to solve conflicts / disagreements internally
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Scrum
+
+== About domain selection
+
+- choose an app / service that you know well and select a couple of features to implement during the semester
+- point is to learn by implementing these using the required architectures
+- we are not looking for quantity but for quality, so just few core features will suffice
+
+== About domain selection (2)
+
+- the chosen app needs to be suitable for a cloud based service
+- there must therefore be some dynamic data per user managed by the server. 
+- eg. a (currency) calculation will NOT fit such a project. 
+- one good starting point are the cases from the HCI course (MMI)
+
+
+== User stories
+
+[.smaller-80]
+- short, simple descriptions for application features 
+- formulated from the stand point of the user / customer
+- template: 
+** As a **< type of user >**, I want **< some goal >** so that **< some reason >**.
+- they are not replacing design documents  / requirements specification
+- they need to be developed into specific tasks and connected to constraints and other meaningful documentation. 
+
+== Sprints
+- meaningful iterations of comparable length
+- they should have a clear goal
+
+== Planning releases
+- 3 deliverables - map to releases
+- a release should produce a minimum viable product (MVP)
+** a MVP is a version of an application with just enough features to be usable in getting feedback to guide the development process 
+
+
+== Meetings
+- regular stand-up meetings (synchronize and commit, remove hindrances)
+- retrospectives (reflect on your group work)
+- sprint reviews / demos (invite TA, prepare deliverables)
+
+== Pair programming
+
+- popular agile development  technique
+- recommended to be used in your groups
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Gitlab
+
+== Gitlab -Issue tracking
+
+- Issues
+- Labels
+- Milestones
+- Boards
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Gitlab demo
+
+include::{includedir}footer.adoc[]

lectures/revealjs/05-groupwork-gitlab.adoc

+= Groupwork and more
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Groups and groupwork
+:LECTURE_NO: 5th lecture
+
+include::{includedir}header.adoc[]
+
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2023 - {LECTURE_NO}
+
+== Overview
+
+- Administrative issues
+- Group contract
+- 1st group deliverable
+- Scrum
+- Gitlab
+- Summary
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+
+== Groups (1)
+
+- Groups have been assigned a TA
+- We have created the groups in Blackboard
+- We have added the members to each group
+- Each group has assigned a TA (info in BlackBoard)
+- We will create the gitlab groups ASAP 
+
+== Groups (2)
+
+- Check in BlackBoard to see your group
+- If you are not allocated contact talha.m.alam@ntnu.no
+
+
+== Reference group (1)
+
+- Special thanks to the reference group volunteers for their interest in the course.
+- we selected a representative mix in the order of volunteering
+- you can see the contact info in Blackboard
+- questions regarding the course organization and proposals for improvements should be communicated to the reference group
+
+== Reference group (2)
+
+- Trygve Eriksen tryger@stud.ntnu.no	(Datateknologi)
+- Magnus Andreas Giverin magnusgi@stud.ntnu.no (Datateknologi)
+- Noah Lund Syrdal noahls@stud.ntnu.no (Informatikk)
+- Caroline Wie carolwie@stud.ntnu.no (Informatikk)
+- Anine Løkken aninelok@stud.ntnu.no (Datateknologi)
+
+
+== Nearing Deadlines
+
+ - First individual assignment (Thursday 07.09.2023 18:00)
+ ** there will be a possibility to resend after the first round of feedback
+ - Group contract (Thursday 14.09.2022 18:00)
+ - First group assignment (Thursday 21.09.2022 18:00)
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Group contract
+
+== Group contract (0) 
+
+- contact the other members of your group
+- start working on the group contract
+
+== Group contract (1)
+- Minimum requirements for agreement:
+** Presence
+** Time spent
+** Expectations for the individual contribution
+** What happens in the event of deviations or disagreements
+
+
+== Group contract (2)
+* must be approved by the TA for the group 
+* signed by all group members 
+* and delivered by Thursday 14.09.2022 18:00
+
+== Group contract (3)
+- more recommended items:
+** handling differences in motivation level and ambition
+** what quality is expected, how defines the group something to be "done"
+** distribution of time between meetings / group work / individual work
+** what happens if course work needs more time than expected
+
+== Group contract (4)
+- more recommended items:
+** delays, sickness, absence - how does the group handle these
+** meeting routines both for physical and virtual (agreement for time, agenda, meeting minutes etc)
+** general communication tools (email, phone, im etc) and response time
+** dealing as a group with deliverables and deadlines 
+
+== Group contract (5)
+- more recommended items:
+** roles 
+** giving feedback to the others  
+** dealing with conflicts and disagreements
+** dealing with breach of contract
+** procedure to follow if the group is not able to solve conflicts / disagreements internally
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== 1st group deliverable
+
+
+== Start group work
+
+ - finish and deliver the group contract
+ - discuss and select domain / aplication for group project
+ - discuss and agree on workflow, meetings etc
+ - set up your gitlab workspace and repository
+ - plan the sprint  / iteration for the first deliverable
+
+== About domain selection
+
+- choose an app / service that you know well and select a couple of features to implement during the semester
+- point is to learn by implementing these using the required architectures
+- we are not looking for quantity but for quality, so just few core features will suffice
+
+== About domain selection (2)
+
+- the chosen app needs to be suitable for a cloud based service
+- there must therefore be some dynamic data per user managed by the server. 
+- eg. a (currency) calculation will NOT fit such a project. 
+- one good starting point are the cases from the HCI course (MMI)
+
+== 3 step release plan
+
+- Minimal application
+- Application with more features / improved quality 
+- Final technical – client server / REST API / more features / alternative client
+
+== Minimal application
+
+- a simple app is created with JavaFX and FXML, with relatively minimal functionality 
+- can save data to a file and start up again where it left off
+- divided into separate modules
+- good point to start could be the modules-template (from the individual exercise)
+ ** one can also use the todo list example as inspiration
+
+== Requirements (1)
+
+ - project must be in the group repo in gitlab
+ - documentation for each release is placed in a separate folder
+ ** 1st deliverable (release)-  `...groups-2023/gr23nn/gr23nn/docs/release1`
+ - a milestone in Gitlab should refer to the corresponding documentation and issues
+
+== Requirements (2)
+
+- project must build with Maven
+- one root level README.md in the repo to describe the content
+- another README.md file (use links) must describe expected application functionality (use at leasst a screen mockup / screenshot) 
+- there must also be at least one user story
+- there must be corresponding issues in Gitlab
+
+== Requirements (3)
+
+- you must reference the issues in the commits
+- configure Maven  so that 
+** application runs with  `mvn javafx:run` 
+** test can run using `mvn test` 
+- the build must report test coverage ( > 0% ) 
+ 
+== Requirements (4)
+- there must be at least something in each of the three architecture layers 
+** domain logic, user interface (JavaFX-GUI) and persistence 
+- project should be configured to open and run in eclipse che (link in README.md)
+
+
+== Application description
+
+- General description included in readme.md file
+- user stories supported by additional design documents such as:
+** conceptual model, 
+** personas, 
+** scenarios, 
+** UI mockups, 
+** UI protoypes
+- User stories get broken down into issues and tasks
+- Lead to a functional application
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Scrum
+
+== User stories
+
+[.smaller-80]
+- short, simple descriptions for application features 
+- formulated from the stand point of the user / customer
+- template: 
+** As a **< type of user >**, I want **< some goal >** so that **< some reason >**.
+- they are not replacing design documents  / requirements specification
+- they need to be developed into specific tasks and connected to constraints and other meaningful documentation. 
+
+== Sprints
+- meaningful iterations of comparable length
+- they should have a clear goal
+
+== Planning releases
+- 3 deliverables - map to releases
+- a release should produce a minimum viable product (MVP)
+** a MVP is a version of an application with just enough features to be usable in getting feedback to guide the development process 
+
+
+== Meetings
+- regular stand-up meetings (synchronize and commit, remove hindrances)
+- retrospectives (reflect on your group work)
+- sprint reviews / demos (invite TA, prepare deliverables)
+
+== Pair programming
+
+- popular agile development  technique
+- recommended to be used in your groups
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== GitLab
+
+== GitLab
+
+* Issues
+* Milestones
+* Task lists and check lists
+* Labels
+* Boards
+* Quick actions
+
+== Issues (1)
+
+- collaboration and discussion
+- elaborate on design and implementation
+- plan work and track progress
+
+== Issues (2)
+
+- issues track work (not only programming work)
+- examples
+** new features, bugs and change requests
+** other tasks - documentation, refactoring, configuration
+** knowledge acquisition  - (to get work done)
+** etc
+
+
+== Milestones
+
+- way to organize and manage issues and merge requests
+- can be used to manage releases
+- can be mapped to sprints
+
+== Task lists and check lists
+
+- split work in finer chunks
+- keep track of progress within issues
+
+== Labels
+
+- allow categorizing issues and other elements in gitlab
+- used with boards and issues to facilitate workflow and visibility
+
+== Boards
+
+- tool to manage and visualize workflow for a software artifact 
+- combine issue tracking and project management in a single tool
+- you can create a Scrum board or custom boards as needed
+
+
+== Quick actions
+
+- allow including in the text of the issue / comments commands
+- assign , label, set due date etc in one go
+- context dependent - options based on the state of the item
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+
+include::{includedir}footer.adoc[]

lectures/revealjs/05-lecture-admin-gitlab.adoc

+= GitLab
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: GitLab
+:LECTURE_NO: 5th lecture
+
+include::{includedir}header.adoc[]
+
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2022 - {LECTURE_NO}
+
+== Overview
+
+- Administrative issues
+- Gitlab
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+
+== Administrative issues (Groups)
+
+- Groups have been assigned a TA
+- we have created the groups in gitlab
+- we have added the members to each group
+- the initial repositories for group exercises have been created 
+- check if all in the group can access the repository 
+- standard repository gr22nn/gr22nn 
+
+== Administrative issues (Tech support)
+
+- Technichal support is operational
+- Link and info  will be published in BlackBoard
+
+
+== Reference group (updated)
+
+- vebjorbl@stud.ntnu.no	Vebjørn Falk Blom-Hagen (Informatikk)
+- hanneswi@stud.ntnu.no	Hannes Witt	(Informatikk)
+- johanlm@stud.ntnu.no	Johannes Landmark Meldal (Informatikk)
+- jakobto@stud.ntnu.no	Jakob Tøssebro (Datateknologi)
+- olejme@stud.ntnu.no	Ole Jacob Mellgren (Datateknologi)
+- elintes@stud.ntnu.no	Elin Tesaker (Lektorutdanning i realfag)
+
+
+== Nearing Deadlines
+
+ - First individual assignment
+ ** postponed to next week (Tuesday 13.09.2022 23:59)
+ ** there will be a possibility to resend after the first round of feedback
+ - Group contract (Tuesday 13.09.2022 23:59)
+ - First group assignment (Thursday 22.09.2022 23:59)
+
+== Start group work
+
+ - finish and deliver the group contract
+ - discuss and select domain / aplication for group project
+ - discuss and agree on workflow, meetings etc
+ - set up your gitlab workspace and repository
+ - plan the sprint  / iteration for the first deliverable
+
+== About domain selection
+
+- choose an app / service that you know well and select a couple of features to implement during the semester
+- point is to learn by implementing these using the required architectures
+- we are not looking for quantity but for quality, so just few core features will suffice
+
+== About domain selection (2)
+
+- the chosen app needs to be suitable for a cloud based service
+- there must therefore be some dynamic data per user managed by the server. 
+- eg. a (currency) calculation will NOT fit such a project. 
+- one good starting point are the cases from the HCI course (MMI)
+
+== 3 release plan
+
+- Minimal application
+- Application with more features / improved quality 
+- Final technical – client server / REST API / more features / alternative client
+
+== Application description
+
+- General description included in readme.md file
+- user stories supported by additional design documents such as:
+** conceptual model, 
+** personas, 
+** scenarios, 
+** UI mockups, 
+** UI protoypes
+- User stories get broken down into issues and tasks
+- Lead to a functional application
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== GitLab
+
+== GitLab
+
+* Issues
+* Milestones
+* Task lists
+* Labels
+* Boards
+* Quick actions
+
+
+include::{includedir}footer.adoc[]

lectures/revealjs/05-lecture.adoc

+= Q & A
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Q&A
+:LECTURE_NO: 5th lecture
+
+include::{includedir}header.adoc[]
+
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2021 - {LECTURE_NO}
+
+== Overview
+
+- Administrative issues
+- Q & A
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+
+== Administrative issues
+- Groups have been assigned a TA
+- we have created the groups in gitlab
+- we have added the members to each group
+- the initial repositories have been created 
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Q & A
+
+
+== 3 release plan
+
+- Minimal application
+- Application with more features / improved quality 
+- Final technical – client server / REST API / more feature / alternative client
+
+== Application description
+
+- General description included in readme.md file
+- user stories supported by additional design documents such as:
+** conceptual model, 
+** personas, 
+** scenarios, 
+** UI mockups, 
+** UI protoypes
+- User stories get broken down into issues and tasks
+- Lead to a functional application
+
+include::{includedir}footer.adoc[]

lectures/revealjs/05-testing.adoc

+= Code Quality and Testing
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Code Quality and Testing
+:LECTURE_NO: 5th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2024 - {LECTURE_NO}
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+
+[.smaller-80]
+- Administrative issues
+- 2nd Group Exercise
+- Code Quality
+** Testing
+- Summary
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+== Administrative issues
+
+* Mandatory Individual Assignment
+* Group work
+
+
+== Mandatory Individual Assignment
+
+* deadline was on 12.09.2024
+* the majority submitted 
+* information about retake will be available after we check the exercises
+
+
+== Group work
+
+- prepare for delivery
+- you submit the link to repo and the commit hash to evaluate
+- report any group drop out cases - exercises are designed to work for 3-4 people
+- we take into account the reduced numbers when grading
+- test your deliverable in Eclipse Che
+
+
+== Approaching Deadlines
+
+- Torsdag, 19. september / 23:59 
+** 1st group deliverable
+
+- Torsdag, 19. september / 23:59 
+** group contract
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== 2nd Group Exercise
+
+
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Code quality
+
+== Code quality
+
+- testing
+ ** automated tests
+ ** +++
+- coding standards and consistent formatting
+- check for higher level types of errors (bug patterns)
+- +++
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Testing
+
+== Crowdstrike incident 2024
+
+* largest IT outage in history
+* several billion USD in losses
+* affected roughly 8.5 million systems
+* bad test practices - happy path, no compatibility
+* bad deployment practices
+
+== Knight Capital Group (2012)
+
+* technician forgot to copy the new version on one of the servers
+* new version repurposed a flag that trigerred the olde version to send orders indefinitely
+* 440 million USD lost
+* lack of thorough regression testing
+
+== Therac-25 - mid 80s
+
+* radiation treatment cancer patients
+* software issues - wrong dose
+* caused 6 accidents, killed 3 patients
+* bad design and development practices
+* unfeasible to test properly and automate tests
+
+
+
+== Testing
+
+[%step]
+- is an important part of software development
+- a way to ensure software quality
+- automated testing allows to develop new features with a minimal effort to check if the software still works as expected
+- testing frameworks  
+
+
+
+== Testing (2)
+
+[%step]
+- design 
+- implement
+- write automated tests
+- run tests
+- we do not test just for now, we write tests to keep running them during project life cycle 
+
+== Testing (3)
+
+[%step]
+- design tests
+- implement the test
+- provide inputs
+- run the tests
+- provide expected outputs
+- check if the result  we get matches what we expect
+- produce a manageable output that the developer can consult 
+
+== Testing (3)
+
+- design tests
+- implement the test
+- provide inputs
+- *run the tests*
+- provide expected outputs
+- *check if the result  we get matches what we expect*
+- *produce a manageable output that the developer can consult* 
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== JUnit
+
+
+== JUnit
+
+- Is a Java unit testing framework.
+- provides the means to automate test
+- allows to eliminate redundant testing tasks  
+
+
+== JUnit (2)
+
+``` java
+import org.junit.*;
+
+public class FoobarTest {
+    @BeforeClass
+    public static void setUpClass() throws Exception {
+        // Code executed before the first test method
+    }
+
+    @Before
+    public void setUp() throws Exception {
+        // Code executed before each test
+    }
+ 
+    @Test
+    public void testOneThing() {
+        // Code that tests one thing
+    }
+
+    @Test
+    public void testAnotherThing() {
+        // Code that tests another thing
+    }
+
+    @Test
+    public void testSomethingElse() {
+        // Code that tests something else
+    }
+
+    @After
+    public void tearDown() throws Exception {
+        // Code executed after each test 
+    }
+ 
+    @AfterClass
+    public static void tearDownClass() throws Exception {
+        // Code executed after the last test method 
+    }
+}
+```
+
+[.smaller-40]
+https://en.wikipedia.org/wiki/JUnit  
+https://junit.org/junit5/docs/current/user-guide/
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== TestFX
+
+== TestFX
+
+- testing for JavaFx applications
+- provides robots for UI testing
+- support for JUnit
+
+[.smaller-40]
+https://github.com/TestFX/TestFX
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Mockito
+
+
+== Mockito
+
+- mocking is a technique to test functionality in isolation
+- mock objects simulate real objects
+- return dummy values corresponding to the input given at creation
+- Mockito uses reflection features in Java to create the mock objects
+
+[.smaller-40]
+https://site.mockito.org/
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Jacoco
+
+== JaCoCo (1)
+
+- Java Code Coverage (JaCoCo)
+- popular tool for measuring code coverage in Java projects
+- measures several metrics  
+
+== Jacoco (2)
+
+- tool for assessing code coverage
+- does not need modifying code
+- can produce a report in html format
+- integrates with a number a tools including Gradle
+
+[.smaller-40]
+https://www.jacoco.org/
+
+
+
+== JaCoCo metrics
+
+- Instructions 
+- Branches (exception handling is excluded)
+- Cyclomatic Complexity - "According to  McCabe1996 cyclomatic complexity is the minimum number of paths that can, in (linear) combination, generate all possible paths through a method."
+- Lines
+- Methods
+- Classes
+
+[.smaller-40]
+https://www.jacoco.org/jacoco/trunk/doc/counters.html
+
+== Tools for automatic code checking
+
+- Checkstyle (https://checkstyle.sourceforge.io/index.html) 
+- Spotbugs (https://spotbugs.readthedocs.io/en/latest/index.html)
+- Pmd (https://pmd.github.io)
+- Sonarcube (https://www.sonarqube.org/)
+- ... 
+
+== Checkstyle
+
+- static analysis
+- finds errors like
+** references to variables with undefined value
+** variables that are never used
+** syntax and coding standards violations
+** dead code blocks 
+
+== Checkstyle (2)
+
+- naming conventions
+- line length
+- whitespace
+- Javadoc comments
+- annotations
+ 
+== Checkstyle (3)
+
+- can be configured to use a certain set of checks
+- extendable - one can write own checks
+- plugins for IDEs
+ 
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Checkstyle examples 
+
+ 
+== Spotbugs
+
+- checks bytecode and not the source
+- looks for "bug patterns"
+- example:
+
+```
+An apparent infinite loop (IL_INFINITE_LOOP)
+This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
+```
+
+== Spotbugs (2)
+
+- extendable
+- plugins for Maven Gradle Ant
+- Eclipse IDE integration 
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Spotbugs examples
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/05a-admin-issues.adoc

+= Administrative Issues 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_NO: 5th lecture
+:LECTURE_TOPIC: Admin issues
+
+
+include::{includedir}header.adoc[]
+
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2020 - {LECTURE_NO}
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative Issues 
+
+- Reference group 
+- Groups
+- Deadlines
+
+== Reference group
+
+[.smaller-60]
+[%header,cols=3*] 
+|===
+|Name
+|Email
+|Specialization
+
+|Kamomilla Godlund
+|kamomilla.godlund@gmail.com
+|Datateknologi
+
+|Ruben Kobbeltvedt	
+|ruben.kobbeltvedt@gmail.com	
+|Informatikk
+
+|Jan Ming Lam 
+|janmla@stud.ntnu.no
+|Informatikk
+
+|Una Onsrud	
+|una.onsrud@gmail.com	
+|Datateknologi
+
+|Idun Syvertsen	
+|id.syver@outlook.com	
+|Datateknologi
+
+|===
+
+== Reference group (2)
+
+- Special thanks to the reference group volunteers for their interest in the course.
+- Please relay your proposals for improvements and general feedback related to the course to the reference group members.
+
+== Groups
+
+- most groups are formed on BB, some more work needed
+- for issues with the groups contact
+** Sondre (sondrhel@stud.ntnu.no) or 
+** Anh-Kha (akvo@stud.ntnu.no) 
+- will soon start adding members to Gitlab groups
+
+== Groups (2)
+
+- contact your team mates and start working on the group contract
+- start working on finding a suitable project 
+
+== Gruppekontrakt
+
+- Minimumskrav til avtale:
+** Tilstedeværelse
+** Tidsbruk
+** Forventninger til den enkeltes bidrag
+** Hva som skjer ved avvik eller uenigheter
+
+Gruppekontrakt skal godkjennes av studentassistent, signeres av alle gruppemedlemmer - og leveres sammen med første innlevering
+
+== About domain selection
+
+- choose an app / service that you know well and select a couple of features to implement during the semester
+- point is to learn by implementing these using the required architectures
+- we are not looking for quantity but for quality, so just few core features will suffice
+
+== About domain selection (2)
+
+- the chosen app needs to be suitable for a cloud based service
+- there must therefore be some dynamic data per user managed by the server. 
+- eg. a (currency) calculation will NOT fit such a project. 
+- one good starting point are the cases from the HCI course (MMI)
+
+== Coming Deadlines
+
+- today (at 18:00) is the deadline for submitting the first assignment
+** push you last changes to your repository on Gitlab
+** post the link to the repository on BB
+- Thursday (at 23:59) is the deadline for the second assignment
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/06-build-tools-and-some-testing.adoc

+= Build tools. Introduction to testing 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Build tools. Introduction to testing 
+:LECTURE_NO: 6th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2020 - {LECTURE_NO}
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Administrative issues
+- Build tools
+- Testing
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+== Individual assignment 1
+
+* delivered project must be in the master branch 
+* project needs to be named "valutakalkulator"  and the packages, build files and module information need to be named consistently and reference "valutakalkulator"
+* project must build successfully and run - check that before delivering
+* .gitpod.dockerfile and .gitpod.yml - are required for gitpod support
+
+== Individual assignment 1 (cont.)
+
+* gitpod label in readme.md to point to your project
+* project name must be the same with the NTNU username 
+* project must be created inside https://gitlab.stud.idi.ntnu.no/it1901/students-2020 
+
+== Groups 
+
+* groups will be finalized today
+* TAs assigned to groups will be announced on Blackboard
+* work on the contract
+* choose project (domain)
+* supervision and meetings use A4-100 (Wednesdays and Fridays)
+
+
+== Group Deliverable 1
+
+programmering av en enkel app,  bruk av maven til bygging, og git og gitlab til kodehåndtering
+Krav til innleveringen:
+
+- Kodingsprosjektet skal ligge i repoet på gitlab 
+- Prosjektet skal være konfigurert til å bygge med maven
+
+== Group Deliverable 1
+
+- En README.md-fil på rotnivå i repoet skal beskrive repo-innholdet, spesielt hvilken mappe inni repoet som utgjør kodingsprosjektet.
+- En README.md-fil (evt. en fil som README.md lenker til) inni prosjektet skal beskrive hva appen handler om og er ment å gjøre (når den er mer eller mindre ferdig). Ha med et illustrerende skjermbilde, så det er lettere å forstå. Det må også være minst én brukerhistorie for funksjonaliteten dere starter med.
+
+== Group Deliverable 1
+
+- Det må ligge inne (i gitlab) utviklingsoppgaver (issues) tilsvarende brukerhistorien, hvor hver utviklingsoppgave må være egnet til å utføres som en egen enhet. De som er påbegynt må være tilordnet det gruppemedlemmet som har ansvaret.
+
+== Group Deliverable 1
+
+- Vi stiller ikke krav om at dere er kommet så langt, men det må i hvert fall være noe i hvert av de tre arkitekturlagene, domenelogikk, brukergrensesnitt (JavaFX-GUI) og persistens (fillagring, men ikke nødvendigvis JSON), slik at appen kan kjøres og vise frem "noe". For at det skal være overkommelig, er det viktig at domenet er veldig enkelt i første omgang. Det er viktigere at det som er kodet er ordentlig gjort. Koden som er sjekket inn bør være knyttet til tilsvarende utviklingsoppgave.
+
+== Group Deliverable 1
+- Maven skal være konfigurert så en kan kjøre app-en vha. gradle-oppgaven run. 
+- Det må finnes minst én test som kan kjøres med maven. Bygget skal være rigget til å rapportere testdekningsgrad, som derfor skal være over 0%.
+- Prosjektet skal være konfigurert for gitpod og kan åpnes i gitpod vha. gitpod-merkelappen.
+- Bruk simpleexample-prosjektet som inspirasjon, men ikke kopier kode direkte.
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Build tools
+
+== Build tools (1)
+
+[%step]
+- Automate the process of building executable programs from source files
+- Packaging binaries required for deployment / distribution
+- Run automated tests
+
+== Build tools (2)
+
+[%step]
+- Build automation is a necessity to enable CI/CD
+- Remove the need to do redundant tasks
+- Improve quality of the software
+	** the software builds are prepared in a consistent and predictable manner
+	** possible to have data to analyze issues and improve
+
+== Make (1)
+
+[%step]
+- Designed by Stuart Feldman
+- Released in 1976
+- Uses makefiles to describe the actions required to produce the build
+- Manages dependencies
+
+[.smaller-40]
+https://en.wikipedia.org/wiki/Make_(software)
+
+== Make (2)
+
+[%step]
+- Has been rewriten a number of times
+- Standard modern implementation is GNU Make
+- Used in Linux and Mac OS
+
+== Java world build tools
+
+- Ant with Ivy
+- Maven
+- Gradle
+
+== Apache ANT
+
+[%step]
+- modern build system
+- released in 2000
+- build files use XML
+	** tends to get unmanageable even for small projects
+- Apache Ivy for managing dependencies (added later)
+	** download over network
+
+[.smaller-40]
+http://ant.apache.org
+
+== Apache Maven (1)
+
+[%step]
+- released in 2004
+- improves on ANT
+- build files use also XML but the structure is radically different
+- dependency management with automatic downloading over the network is available from release
+
+[.smaller-40]
+http://maven.apache.org
+
+== Apache Maven (2)
+
+[%step]
+- hides complexity in build files through plugins 
+- customizing is hard
+- dependency management has issues with conflicting versions of same library  
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Gradle
+
+
+== Gradle (1)
+
+[%step]
+- released in 2012
+- build scripts are written in a domain specific language based on Groovy
+	**  Groovy ( http://www.groovy-lang.org/ )
+- the build script is named `build.gradle`
+- build steps are called "tasks"
+
+[.smaller-40]
+https://gradle.org
+
+
+== Gradle (2)
+
+[%step]
+- easy to create own tasks
+- uses plugins to hide complexity 
+- applying plugins allows access to additional tasks 
+
+
+== Gradle (3)
+
+[.center-paragraph]
+image::../images/lecture03/gradle-tree.png[width=700]
+
+[.smaller-40]
+https://guides.gradle.org/creating-new-gradle-builds/
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== More on Maven
+
+== Maven (3)
+
+* manages builds, dependencies, versions 
+* configuration file is `pom.xml`
+* has good IDE support
+* central repository(ies) for dependencies
+
+== Maven - pom.xml
+
+* modelVersion (4.0.0) config file format version
+* groupId - ID of group owning the project 
+* artifactId - name of the final output
+* version  - version of the created artifact
+
+== Maven - pom.xml (cont.)
+
+* dependencies - list of artifacts we depend upon
+* packaging - e.g. .jar (Java archive)
+* description 
+
+https://maven.apache.org/pom.html#Quick_Overview
+
+== Maven dependencies
+
+* list of dependencies 
+* each dependecy has specified
+** groupId
+** artifactId
+** version (optional, good to have)  
+** scope (default is `compile`)
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Testing
+
+== Testing
+
+[%step]
+- is an important part of software development
+- a way to ensure software quality
+- automated testing allows to develop new features with a minimal effort to check if the software still works as expected
+- testing frameworks  
+
+== Testing (2)
+
+[%step]
+- design 
+- implement
+- write automated tests
+- run tests
+- we do not test just for know, we write tests to keep running them during project life cycle 
+
+== Testing (3)
+
+[%step]
+- design tests
+- implement the test
+- provide inputs
+- run the tests
+- provide expected outputs
+- check if the result  we get matches what we expect
+- produce a manageable output that the developer can consult 
+
+== Testing (3)
+
+- design tests
+- implement the test
+- provide inputs
+- *run the tests*
+- provide expected outputs
+- *check if the result  we get matches what we expect*
+- *produce a manageable output that the developer can consult* 
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== JUnit
+
+
+== JUnit
+
+- Is a Java unit testing framework.
+- provides the means to automate test
+- allows to eliminate redundant testing tasks  
+
+
+== JUnit (2)
+
+``` java
+import org.junit.*;
+
+public class FoobarTest {
+    @BeforeClass
+    public static void setUpClass() throws Exception {
+        // Code executed before the first test method
+    }
+
+    @Before
+    public void setUp() throws Exception {
+        // Code executed before each test
+    }
+ 
+    @Test
+    public void testOneThing() {
+        // Code that tests one thing
+    }
+
+    @Test
+    public void testAnotherThing() {
+        // Code that tests another thing
+    }
+
+    @Test
+    public void testSomethingElse() {
+        // Code that tests something else
+    }
+
+    @After
+    public void tearDown() throws Exception {
+        // Code executed after each test 
+    }
+ 
+    @AfterClass
+    public static void tearDownClass() throws Exception {
+        // Code executed after the last test method 
+    }
+}
+```
+
+[.smaller-40]
+https://en.wikipedia.org/wiki/JUnit
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== TestFX
+
+== TestFX
+
+- testing for JavaFx applications
+- provides robots for UI testing
+- support for JUnit
+
+[.smaller-40]
+https://github.com/TestFX/TestFX
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Mockito
+
+
+== Mockito
+
+- mocking is a technique to test functionality in isolation
+- mock objects simulate real objects
+- return dummy values corresponding to the input given at creation
+- Mockito uses reflection features in Java to create the mock objects
+
+[.smaller-40]
+https://site.mockito.org/
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Jacoco
+
+== Jacoco
+
+- tool for assessing code coverage
+- does not need modifying code
+- can produce a report in html format
+- integrates with a number a tools including Gradle
+
+[.smaller-40]
+https://www.jacoco.org/
+
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/06-documentation.adoc

+= Documentation
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Documentation
+:LECTURE_NO: 6th lecture
+
+include::{includedir}header.adoc[]
+
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2024 - {LECTURE_NO}
+
+== Overview
+
+- Administrative issues
+- Documentation
+- Summary
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+== 1st individual exercise
+
+- 2 thirds got it approved
+- last chance to deliver
+- mandatory exercise 
+- new deadline 03.10.2024 23:59
+
+
+
+== Approaching Deadlines
+
+- Torsdag, 03. oktober / 23:59 
+** 1st individual exercise
+
+- Torsdag, 10. oktober / 23:59 
+** 2nd group deliverable
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Documentation
+
+== Documentation
+
+- is an important part of software development
+- a way to ensure and contribute to software quality
+- several levels of documentation
+
+[.smaller-60]
+Note: In IT1901 we also look if the documentation is original. You should not just copy paste the documentation from the examples and just rename things to match your project.  
+
+== Types of documentation
+
+[.smaller-80]
+- design documentation
+- API specifications ( if applicable)
+- readme files
+- contribution guide
+- frequently asked questions (faq)
+- wiki
+- comments ( including Javadoc ) 
+- user guides
+- ...
+
+
+== Who is reading the documentation
+
+- the developer him/herself
+- other developers 
+- future maintainers of the software product
+- external users (e.g. some provided API)
+- others within the company / institution (testers, deployment )
+- ...
+
+== How is documentation improving the quality
+
+- allow new team members to be productive faster
+- increase qualities such as maintainability and transferability
+- saves time for both other contributors and initial dev
+
+== Readme files (1)
+
+- give overview information regarding a project, subproject, module
+- normally contains info about the role, contents, build details, dependencies and interactions with other parts / modules
+
+== Readme files (2)
+
+- can contain information such as setting up environment, installing dependencies and other needed software, building, running the project
+- it is a way to provide needed contextual information that otherwise is not apparent from just looking at the source code 
+
+
+== Comments (1)
+
+- allow adding documentation in close proximity with the code
+- they should not be a way to cope with bad naming or "special" assumptions in the code
+- the standardized comments such as JavaDoc allow additional benefits such as code completion
+
+== Comments (2)
+
+[.center-paragraph]
+image::../images/lecture07/code-comments.png[width=100%]
+
+[.smaller-40]
+https://stfalcon.com/uploads/images/55c8bcff18b94.png
+
+== Comments (3)
+
+[source,java, role="stretch"]
+----
+/**
+  * Creates a LatLong object from a String, using a specific separator.
+  * The format is <latitude><separator><longitude>.
+  * @param s the String to parse
+  * @param sep the separator
+  * @return the new LatLong object
+  */
+public static LatLong valueOf(final String s, final String sep) {
+  final int pos = s.indexOf(sep);
+  if (pos < 0) {
+    throw new IllegalArgumentException("No '" + sep + "' in " + s);
+  }
+  final double lat = Double.valueOf(s.substring(0, pos).trim());
+  final double lon = Double.valueOf(s.substring(pos + sep.length()).trim());
+  return new LatLong(lat, lon);
+}
+----
+
+== Comments (4)
+
+- comments should bring additional value
+- most source file formats support some type of comments
+- for example: project needs a certain version of a dependency 
+** we can document that in the readme or some specific file dealing with building and running
+** we can also add a comment exactly where one would go and change the config file 
+
+== Documenting unit tests
+
+- use javadoc
+- use @DisplayName annotation
+- use @Tag annotation
+
+== Over-documenting
+
+- documentation needs to be concise
+- redundant documentation will result in maintenance overhead
+- if some entity / operation is clear and self evident, then it does not normally need additional documentation
+
+== ! 
+
+[.center-paragraph]
+image::../images/lecture07/comment-all.jpeg[width=400]
+
+[.smaller-40]
+[.center-paragraph]
+https://miro.medium.com/max/1138/1*Pyxsc7Uixbitv5myywaA_Q.jpeg (Gary Larson comic)
+
+
+== Documentation file formats
+
+- text based file formats
+- can be tracked using source code management tools
+- do not depend on a specific editing sofware
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Markdown
+
+== Markdown 
+
+[.center-paragraph]
+Markdown is a lightweight markup language with plain text formatting syntax. Its design allows it to be converted to many output formats, but the original tool by the same name only supports HTML. Markdown is often used to format readme files, for writing messages in online discussion forums, and to create rich text using a plain text editor.
+
+[.smaller-40]
+https://en.wikipedia.org/wiki/Markdown
+
+== Markdown Syntax
+
+https://www.markdownguide.org/basic-syntax
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Gitlab Flavoured Markdown (GFM)
+
+== Gitlab Flavoured Markdown (GFM) 
+
+https://gitlab.stud.idi.ntnu.no/help/user/markdown
+
+== Why text based documentation
+
+- it is easier to modify and we do not need any special editors
+- it can be versioned same way as the code
+- holding  documentation in the repository and updating it will allow consulting the repository contents with the correct documentation for that snapshot in time
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== UML Diagrams
+
+[.smaller-80]
+== UML - Unified Modelling Language
+
+- 13 diagrams that show various perspectives on the system
+
+- purpose:
+** Stimulate and focus discussion about an existing or a new system
+** Document an existing system
+** Detailed description to generate a system
+
+- informal use of UML:
+** “I do not find UML to be useful during the design process itself and prefer informal notations that are quicker to write and that can be easily drawn on a whiteboard.” (Sommerville, s. 175)
+
+== !
+
+image::../images/lecture13/uml-diagrams.png[canvas, size=contain]
+
+[.smaller-20]
+[.left-30] 
+Fowler, Martin., (2003). UML distilled: a brief guide to the standard object modeling language. Pearson Education
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Package diagram
+
+[.smaller-80]
+== Package diagram
+
+- Gir en oversikt over avhengigheter mellom moduler av et system
+- Viser “pakker” - typisk grupper av klasser
+- Viser avhengigheter mellom pakker/moduler
+- Hver klasse er kun medlem av en “pakke”
+- Pakker representerer et hierarkisk navnerom, så hver klasse innen en pakke må ha et unikt navn
+- En pakke skal ikke kunne være medlem av flere moduler
+
+[.smaller-30]
+Fowler, Martin., (2003). UML distilled: a brief guide to the standard object modeling language. Pearson Education.
+
+
+== !
+
+image::../images/lecture13/package-diagram.png[canvas, size=contain]
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Class diagram
+
+
+== Class diagram
+
+- Viser typer objekter i systemet og statiske relasjoner mellom dem
+- Enkleste form: Klassenavn i bokser
+- Viser egenskaper (attributter, assosiasjoner) og operasjoner (metoder) for en klasse
+
+
+[.smaller-30]
+Sommerville: Software Engineering, Pearson, 2016. 10th Edition, page 149.
+
+== !
+
+image::../images/lecture13/class-diagram-1.png[canvas, size=contain]
+
+[.smaller-30]
+[.left-30]
+Kilde: Yngve Lindsjørn, Universitetet i Oslo: IN2000: Kravhåndtering, modellering & design.
+
+
+== !
+
+image::../images/lecture13/class-diagram-2.png[canvas, size=contain]
+
+
+[.smaller-30]
+[.left-30]
+Kilde: Yngve Lindsjørn, Universitetet i Oslo: IN2000: Kravhåndtering, modellering & design.
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Sequence diagram
+
+[.smaller-80]
+== Sequence diagram
+
+- Brukes for å analysere samarbeid mellom objekter
+- Modellerer interaksjoner mellom aktører og objekter i et system og interaksjon mellom objekter i et scenarie
+- Aktører og objekter finnes øverst i diagrammet
+- Tidsakse nedover i diagram
+- Piler indikerer interaksjon mellom objekter
+- Annoterte piler indikerer metodekall
+- Kan vise alternative sekvenser
+
+[.smaller-30]
+Sommerville: Software Engineering, Pearson, 2016. 10th Edition, page 146.
+
+== !
+
+image::../images/lecture13/sequence.png[canvas, size=contain]
+
+== !
+
+```puml
+
+actor User
+User -> "~#newTodoItemButton: Button" as newTodoItemButton: click
+newTodoItemButton -> TodoController: handleNewTodoItemAction
+TodoController -> "~#newTodoItemText: TextField" as newTodoItemText: getText
+TodoController -> TodoList: addTodoItem
+TodoList -> TodoList: fireTodoListChanged
+TodoList -> TodoListListener: todoListChanged
+TodoListListener -> TodoController: autoSaveTodoList
+TodoListListener -> TodoController: updateTodoListView
+
+```
+
+
+
+
+
+== Plant UML
+
+- open source tool for UML diagrams
+- it takes a textual description and produces a diagram
+- supported within markdown in GitLab
+- uses Graphviz to lay out the diagrams
+
+== Adding diagrams to markdown 
+
+[source, role="stretch"]
+----
+```plantuml
+class LatLong {
+	double latitude
+	double longitude
+}
+class LatLongs
+LatLongs *--> "*" LatLong: "latLongs"
+class MetaData
+LatLong *--> "1" MetaData: "metaData"
+```
+----
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Commit messages
+
+== Commit messages
+
+- Commit messages allow the developers to attach a description to the commits. 
+- overview of the project history
+- the better the commits messages the easiest is to navigate the project history and understand what happened
+
+== Commit message anatomy
+
+- Subject / Title    -  Essence of the commit in a few words     
+- Body - Extended textual description of what has been done 
+- Footer - Additional elements such as links to issues and other metadata 
+
+== Basic principles
+
+[.smaller-80]
+- be consistent
+- limit the subject line to 50 characters
+- don't put a period at the end of the subject line
+- put a blank line between the subject line and the body text
+- wrap the body text at 72 characters
+- use the imperative mood 
+- describe *what* and *why*, but not *how*
+- mention which component(s) / area changed.
+
+
+
+== Commit messages (2)
+
+image::../images/git_commit_2x.png[size=75%]
+[.smaller-40]
+https://xkcd.com/1296/
+
+
+
+
+== Conventional commits format
+
+```text
+<type>([optional scope]): <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+== More on conventional commit content (1)
+ 
+- fix: a commit of the type fix patches a bug in your codebase 
+- feat: a commit of the type feat introduces a new feature to the codebase 
+- BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change. A BREAKING CHANGE can be part of commits of any type.
+
+== More on conventional commit content (2)
+
+- more types:  build, chore, ci, docs, style, refactor, perf, test
+- footers other than BREAKING CHANGE: `<description>` may be provided and follow a convention similar to git trailer format (`token: value`).
+
+== Why to use the conventional commits?
+
+[.smaller-80]
+- Automatically generating CHANGELOGs.
+- Automatically determining a semantic version bump (based on the types of commits landed).
+- Communicating the nature of changes to teammates, the public, and other stakeholders.
+- Triggering build and publish processes.
+- Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.
+
+
+== What to write in the commit message
+
+[.smaller-80]
+- the subject line is the most important
+- clearly state the original issue / problem
+- clearly state *why* the change is made
+- minimize external reference use and aim at a self contained message
+- clearly state how the problem is fixed with the committed code 
+- add information about testing, especially if there are manual tests needed  
+
+Finally, read the message before committing as it might reveal that you should split it in smaller commits
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Questions ?
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+
+
+include::{includedir}footer.adoc[]

lectures/revealjs/06-lecture-build-tools-testing.adoc

+= Build tools. Introduction to testing 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Build tools. Introduction to testing 
+:LECTURE_NO: 6th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2022 - {LECTURE_NO}
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Administrative issues
+- Build tools
+- Testing
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+== Administrative issues
+
+* Individual assignment 1
+* Group contract
+* 1st group assignment
+
+
+== Groups
+
+- contact your team mates and start working on the group contract
+- start working on finding a suitable project 
+
+== Gruppekontrakt
+
+- Minimumskrav til avtale:
+** Tilstedeværelse
+** Tidsbruk
+** Forventninger til den enkeltes bidrag
+** Hva som skjer ved avvik eller uenigheter
+
+Gruppekontrakt skal godkjennes av studentassistent, signeres av alle gruppemedlemmer - og leveres sammen med første innlevering
+
+== About domain selection
+
+- choose an app / service that you know well and select a couple of features to implement during the semester
+- point is to learn by implementing these using the required architectures
+- we are not looking for quantity but for quality, so just few core features will suffice
+
+== About domain selection (2)
+
+- the chosen app needs to be suitable for a cloud based service
+- there must therefore be some dynamic data per user managed by the server. 
+- eg. a (currency) calculation will NOT fit such a project. 
+- one good starting point are the cases from the HCI course (MMI)
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Build tools
+
+== Build tools (1)
+
+[%step]
+- Automate the process of building executable programs from source files
+- Packaging binaries required for deployment / distribution
+- Run automated tests
+
+== Build tools (2)
+
+[%step]
+- Build automation is a necessity to enable CI/CD
+- Remove the need to do redundant tasks
+- Improve quality of the software
+	** the software builds are prepared in a consistent and predictable manner
+	** possible to have data to analyze issues and improve
+
+== Make (1)
+
+[%step]
+- Designed by Stuart Feldman
+- Released in 1976
+- Uses makefiles to describe the actions required to produce the build
+- Manages dependencies
+
+[.smaller-40]
+https://en.wikipedia.org/wiki/Make_(software)
+
+== Make (2)
+
+[%step]
+- Has been rewriten a number of times
+- Standard modern implementation is GNU Make
+- Used in Linux and Mac OS
+
+== Java world build tools
+
+- Ant with Ivy
+- Maven
+- Gradle
+
+== Apache ANT
+
+[%step]
+- modern build system
+- released in 2000
+- build files use XML
+	** tends to get unmanageable even for small projects
+- Apache Ivy for managing dependencies (added later)
+	** download over network
+
+[.smaller-40]
+http://ant.apache.org
+
+== Apache Maven (1)
+
+[%step]
+- released in 2004
+- improves on ANT
+- build files use also XML but the structure is radically different
+- dependency management with automatic downloading over the network is available from release
+
+[.smaller-40]
+http://maven.apache.org
+
+== Apache Maven (2)
+
+[%step]
+- hides complexity in build files through plugins 
+- customizing is hard
+- dependency management has issues with conflicting versions of same library  
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Gradle
+
+
+== Gradle (1)
+
+[%step]
+- released in 2012
+- build scripts are written in a domain specific language based on Groovy
+	**  Groovy ( http://www.groovy-lang.org/ )
+- the build script is named `build.gradle`
+- build steps are called "tasks"
+
+[.smaller-40]
+https://gradle.org
+
+
+== Gradle (2)
+
+[%step]
+- easy to create own tasks
+- uses plugins to hide complexity 
+- applying plugins allows access to additional tasks 
+
+
+== Gradle (3)
+
+[.center-paragraph]
+image::../images/lecture03/gradle-tree.png[width=700]
+
+[.smaller-40]
+https://guides.gradle.org/creating-new-gradle-builds/
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== More on Maven
+
+== Maven (3)
+
+* manages builds, dependencies, versions 
+* configuration file is `pom.xml`
+* has good IDE support
+* central repository(ies) for dependencies
+
+== Maven - pom.xml
+
+* modelVersion (4.0.0) config file format version
+* groupId - ID of group owning the project 
+* artifactId - name of the final output
+* version  - version of the created artifact
+
+== Maven - pom.xml (cont.)
+
+* dependencies - list of artifacts we depend upon
+* packaging - e.g. .jar (Java archive)
+* description 
+
+https://maven.apache.org/pom.html#Quick_Overview
+
+== Maven dependencies
+
+* list of dependencies 
+* each dependecy has specified
+** groupId
+** artifactId
+** version (optional, good to have)  
+** scope (default is `compile`)
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Testing
+
+== Testing
+
+[%step]
+- is an important part of software development
+- a way to ensure software quality
+- automated testing allows to develop new features with a minimal effort to check if the software still works as expected
+- testing frameworks  
+
+== Testing (2)
+
+[%step]
+- design 
+- implement
+- write automated tests
+- run tests
+- we do not test just for know, we write tests to keep running them during project life cycle 
+
+== Testing (3)
+
+[%step]
+- design tests
+- implement the test
+- provide inputs
+- run the tests
+- provide expected outputs
+- check if the result  we get matches what we expect
+- produce a manageable output that the developer can consult 
+
+== Testing (3)
+
+- design tests
+- implement the test
+- provide inputs
+- *run the tests*
+- provide expected outputs
+- *check if the result  we get matches what we expect*
+- *produce a manageable output that the developer can consult* 
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== JUnit
+
+
+== JUnit
+
+- Is a Java unit testing framework.
+- provides the means to automate test
+- allows to eliminate redundant testing tasks  
+
+
+== JUnit (2)
+
+``` java
+import org.junit.*;
+
+public class FoobarTest {
+    @BeforeClass
+    public static void setUpClass() throws Exception {
+        // Code executed before the first test method
+    }
+
+    @Before
+    public void setUp() throws Exception {
+        // Code executed before each test
+    }
+ 
+    @Test
+    public void testOneThing() {
+        // Code that tests one thing
+    }
+
+    @Test
+    public void testAnotherThing() {
+        // Code that tests another thing
+    }
+
+    @Test
+    public void testSomethingElse() {
+        // Code that tests something else
+    }
+
+    @After
+    public void tearDown() throws Exception {
+        // Code executed after each test 
+    }
+ 
+    @AfterClass
+    public static void tearDownClass() throws Exception {
+        // Code executed after the last test method 
+    }
+}
+```
+
+[.smaller-40]
+https://en.wikipedia.org/wiki/JUnit
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== TestFX
+
+== TestFX
+
+- testing for JavaFx applications
+- provides robots for UI testing
+- support for JUnit
+
+[.smaller-40]
+https://github.com/TestFX/TestFX
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Mockito
+
+
+== Mockito
+
+- mocking is a technique to test functionality in isolation
+- mock objects simulate real objects
+- return dummy values corresponding to the input given at creation
+- Mockito uses reflection features in Java to create the mock objects
+
+[.smaller-40]
+https://site.mockito.org/
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Jacoco
+
+== Jacoco
+
+- tool for assessing code coverage
+- does not need modifying code
+- can produce a report in html format
+- integrates with a number a tools including Gradle
+
+[.smaller-40]
+https://www.jacoco.org/
+
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/06-lecture.adoc

+= Pair programming + Git
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Pair programming / Git
+:LECTURE_NO: 5th lecture
+
+include::{includedir}header.adoc[]
+
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2021 - {LECTURE_NO}
+
+== Overview
+
+- 1st group deliverable
+- Pair programming
+- Git
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== 1st group deliverable
+
+== 1st group deliverable
+
+- 1st release  (MVP)
+- deadline (to be discussed with the TAs) 
+** standard deadline Friday 24th of September by 16:00
+** extended deadline Friday 1st of October by 16:00
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Pair programming
+
+== Pair programming (0)
+
+- a pair of developers take on a task
+- use one computer
+- take turns to the roles of driver / observer (navigator, co-pilot)
+- program out loud 
+
+
+== Pair programming (1)
+
+- agile development technique
+- better quality and less defects / more person hours
+- learning from each other
+- transfer of skills
+- increased resilience of the development process
+- aiding team building and communication 
+
+
+== Pair programming (2)
+
+- there are advantages to all kinds of pairing
+- engagement is key to having results
+- learning from each other
+- remote pair programming 
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Git
+
+
+include::{includedir}footer.adoc[]

lectures/revealjs/06-testing-quality.adoc

+= Testing and code quality
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Testing and code quality 
+:LECTURE_NO: 6th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2023 - {LECTURE_NO}
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Administrative issues
+- Code quality + testing
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+== Administrative issues
+
+* Individual assignment 1
+* Group work
+
+
+== Individual assignment 1
+
+* deadline today - 11.09.2023 18:00
+* about 80% submitted 
+* information about retake will be available after we check the exercises
+
+
+== Group work
+
+- contact your team mates and start working on the group contract
+- group contract deadline - 14.09.2023 18:00
+- work on 1st group assignment
+** find a suitable project
+** use gitlab to manage and track your project
+** deadline - 21.09.2023 18:00
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Code quality
+
+
+== Code quality
+
+- automated tests
+- coding standards and consistent formatting
+- check for higher level types of errors (bug patterns)
+- +++
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Testing
+
+
+
+== Testing
+
+[%step]
+- is an important part of software development
+- a way to ensure software quality
+- automated testing allows to develop new features with a minimal effort to check if the software still works as expected
+- testing frameworks  
+
+== Testing (2)
+
+[%step]
+- design 
+- implement
+- write automated tests
+- run tests
+- we do not test just for now, we write tests to keep running them during project life cycle 
+
+== Testing (3)
+
+[%step]
+- design tests
+- implement the test
+- provide inputs
+- run the tests
+- provide expected outputs
+- check if the result  we get matches what we expect
+- produce a manageable output that the developer can consult 
+
+== Testing (3)
+
+- design tests
+- implement the test
+- provide inputs
+- *run the tests*
+- provide expected outputs
+- *check if the result  we get matches what we expect*
+- *produce a manageable output that the developer can consult* 
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== JUnit
+
+
+== JUnit
+
+- Is a Java unit testing framework.
+- provides the means to automate test
+- allows to eliminate redundant testing tasks  
+
+
+== JUnit (2)
+
+``` java
+import org.junit.*;
+
+public class FoobarTest {
+    @BeforeClass
+    public static void setUpClass() throws Exception {
+        // Code executed before the first test method
+    }
+
+    @Before
+    public void setUp() throws Exception {
+        // Code executed before each test
+    }
+ 
+    @Test
+    public void testOneThing() {
+        // Code that tests one thing
+    }
+
+    @Test
+    public void testAnotherThing() {
+        // Code that tests another thing
+    }
+
+    @Test
+    public void testSomethingElse() {
+        // Code that tests something else
+    }
+
+    @After
+    public void tearDown() throws Exception {
+        // Code executed after each test 
+    }
+ 
+    @AfterClass
+    public static void tearDownClass() throws Exception {
+        // Code executed after the last test method 
+    }
+}
+```
+
+[.smaller-40]
+https://en.wikipedia.org/wiki/JUnit  
+https://junit.org/junit5/docs/current/user-guide/
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== TestFX
+
+== TestFX
+
+- testing for JavaFx applications
+- provides robots for UI testing
+- support for JUnit
+
+[.smaller-40]
+https://github.com/TestFX/TestFX
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Mockito
+
+
+== Mockito
+
+- mocking is a technique to test functionality in isolation
+- mock objects simulate real objects
+- return dummy values corresponding to the input given at creation
+- Mockito uses reflection features in Java to create the mock objects
+
+[.smaller-40]
+https://site.mockito.org/
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Jacoco
+
+== JaCoCo (1)
+
+- Java Code Coverage (JaCoCo)
+- popular tool for measuring code coverage in Java projects
+- measures several metrics  
+
+== Jacoco (2)
+
+- tool for assessing code coverage
+- does not need modifying code
+- can produce a report in html format
+- integrates with a number a tools including Gradle
+
+[.smaller-40]
+https://www.jacoco.org/
+
+
+
+== JaCoCo metrics
+
+- Instructions 
+- Branches (exception handling is excluded)
+- Cyclomatic Complexity - "According to  McCabe1996 cyclomatic complexity is the minimum number of paths that can, in (linear) combination, generate all possible paths through a method."
+- Lines
+- Methods
+- Classes
+
+[.smaller-40]
+https://www.jacoco.org/jacoco/trunk/doc/counters.html
+
+== Tools for automatic code checking
+
+- Checkstyle (https://checkstyle.sourceforge.io/index.html) 
+- Spotbugs (https://spotbugs.readthedocs.io/en/latest/index.html)
+- Pmd (https://pmd.github.io)
+- Sonarcube (https://www.sonarqube.org/)
+- ... 
+
+== Checkstyle
+
+- static analysis
+- finds errors like
+** references to variables with undefined value
+** variables that are never used
+** syntax and coding standards violations
+** dead code blocks 
+
+== Checkstyle (2)
+
+- naming conventions
+- line length
+- whitespace
+- Javadoc comments
+- annotations
+ 
+== Checkstyle (3)
+
+- can be configured to use a certain set of checks
+- extendable - one can write own checks
+- plugins for IDEs
+ 
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Checkstyle examples 
+
+ 
+== Spotbugs
+
+- checks bytecode and not the source
+- looks for "bug patterns"
+- example:
+
+```
+An apparent infinite loop (IL_INFINITE_LOOP)
+This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
+```
+
+== Spotbugs (2)
+
+- extendable
+- plugins for Maven Gradle Ant
+- Eclipse IDE integration 
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Spotbugs examples
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/07-debugging.adoc

+= Debugging
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Debugging
+:LECTURE_NO: 7th lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2024 - {LECTURE_NO}
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Administrative issues
+- Debugging
+- Summary
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+== 1st individual exercise
+
+- 2 thirds got it approved
+- last chance to deliver
+- mandatory exercise 
+- new deadline 03.10.2024 23:59
+
+
+== Approaching Deadlines
+
+- Torsdag, 03. oktober / 23:59 
+** 1st individual exercise
+
+- Torsdag, 10. oktober / 23:59 
+** 2nd group deliverable
+
+== Next Lecture
+
+* focus on advanced source code management
+* go through the materials before the lecture
+* more interactive
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Debugging
+
+== Debugging
+
+- important part of software development
+- process of finding and fixing faults
+- apparently term became popular in 1940s - Grace Hopper moth inside a computer
+- “bug” was used by Thomas Edison to describe a defect in a technical system 1870s
+
+== Debugger
+
+- tool that allows developer to 
+** inspect values
+** run step by step
+** set "breakpoints"
+
+== Why not printing?
+
+- you can use sysout or logs to help
+- it tends to polute the actual code
+- gets unmanageable very fast in more complex projects
+
+
+
+== Isn`t unit testing enough?
+
+- testing and unit testing are useful and necessary
+- not a replacement for debugging
+- using debugging we can see what is happening in the code not passing the test
+- tests are code too - you can debug the code in your tests as well
+
+
+== Breakpoints
+
+- developer can mark certain spots in the code where the execution should pause
+- at the breakpoint one can decide how to continue
+- one can inspect existing variables and also custom expressions
+
+== Debugging commands
+
+- Step into - follow code into methods, one step at a time
+- Step over - go to the next line whithout going into methods
+- Step out - run to the end of the method and go out to the caller code
+- Continue - run until finding another breakpoint
+
+== Advanced debugging
+
+- conditional breakpoints - excution stops when a condition is met
+- expressions - (watch) - code that evaluates at debug time
+- changing values of runtime variables
+
+== Typical uses
+
+- correcting errors in code
+- tracing the code paths
+- understanding difficult or unfamiliar code
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Debugging Demo
+
+
+== Questions ?
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/07-documentation.adoc

+= Documentation 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Documentation
+:LECTURE_NO: 7th lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2023 - {LECTURE_NO}
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Documentation
+- Markdown
+- Gitlab Flavoured Markdown (GFM)
+- PlantUML
+- Commit messages
+- Summary
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Documentation
+
+== Documentation
+
+- is an important part of software development
+- a way to ensure and contribute to software quality
+- several levels of documentation
+
+[.smaller-60]
+Note: In IT1901 we also look if the documentation is original. You should not just copy paste the documentation from the examples and just rename things to match your project.  
+
+== Types of documentation
+
+- Design documentation
+- API specifications ( if applicable)
+- readme files
+- contribution guide
+- frequently asked questions (faq)
+- wiki
+- comments ( including Javadoc ) 
+
+
+== Who is reading the documentation
+
+- the developer him/herself
+- other developers 
+- future maintainers of the software product
+- external users (e.g. some provided API)
+- others within the company / institution (testers, deployment )
+- ....
+
+== How is documentation improving the quality
+
+- allow new team members to be productive faster
+- increase qualities such as maintainability and transferability
+- saves time for both other contributors and initial dev
+
+== Readme files (1)
+
+- give overview information regarding a project, subproject, module
+- normally contains info about the role, contents, build details, dependencies and interactions with other parts / modules
+
+== Readme files (2)
+
+- can contain information such as setting up environment, installing dependencies and other needed software, building, running the project
+- it is a way to provide needed contextual information that otherwise is not apparent from just looking at the source code 
+
+
+== Comments (1)
+
+- allow adding documentation in close proximity with the code
+- they should not be a way to cope with bad naming or "special" assumptions in the code
+- the standardized comments such as JavaDoc allow additional benefits such as code completion
+
+== Comments (2)
+
+[.center-paragraph]
+image::../images/lecture07/code-comments.png[width=100%]
+
+[.smaller-40]
+https://stfalcon.com/uploads/images/55c8bcff18b94.png
+
+== Comments (3)
+
+[source,java, role="stretch"]
+----
+/**
+  * Creates a LatLong object from a String, using a specific separator.
+  * The format is <latitude><separator><longitude>.
+  * @param s the String to parse
+  * @param sep the separator
+  * @return the new LatLong object
+  */
+public static LatLong valueOf(final String s, final String sep) {
+  final int pos = s.indexOf(sep);
+  if (pos < 0) {
+    throw new IllegalArgumentException("No '" + sep + "' in " + s);
+  }
+  final double lat = Double.valueOf(s.substring(0, pos).trim());
+  final double lon = Double.valueOf(s.substring(pos + sep.length()).trim());
+  return new LatLong(lat, lon);
+}
+----
+
+== Comments (4)
+
+- comments should bring additional value
+- most source file formats support some type of comments
+- for example: project needs a certain version of a dependency 
+** we can document that in the readme or some specific file dealing with building and running
+** we can also add a comment exactly where one would go and change the config file 
+
+== Documenting unit tests
+
+- use javadoc
+- use @DisplayName annotation
+- use @Tag annotation
+
+== Over-documenting
+
+- documentation needs to be concise
+- redundant documentation will result in maintenance overhead
+- if some entity / operation is clear and self evident, then it does not normally need additional documentation
+
+== ! 
+
+[.center-paragraph]
+image::../images/lecture07/comment-all.jpeg[width=400]
+
+[.smaller-40]
+[.center-paragraph]
+https://miro.medium.com/max/1138/1*Pyxsc7Uixbitv5myywaA_Q.jpeg (Gary Larson comic)
+
+
+== Documentation file formats
+
+- text based file formats
+- can be tracked using source code management tools
+- do not depend on a specific editing sofware
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Markdown
+
+== Markdown 
+
+[.center-paragraph]
+Markdown is a lightweight markup language with plain text formatting syntax. Its design allows it to be converted to many output formats, but the original tool by the same name only supports HTML. Markdown is often used to format readme files, for writing messages in online discussion forums, and to create rich text using a plain text editor.
+
+[.smaller-40]
+https://en.wikipedia.org/wiki/Markdown
+
+== Markdown Syntax
+
+https://www.markdownguide.org/basic-syntax
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Gitlab Flavoured Markdown (GFM)
+
+== Gitlab Flavoured Markdown (GFM) 
+
+https://gitlab.stud.idi.ntnu.no/help/user/markdown
+
+== Why text based documentation
+
+- it is easier to modify and we do not need any special editors
+- it can be versioned same way as the code
+- holding  documentation in the repository and updating it will allow consulting the repository contents with the correct documentation for that snapshot in time
+
+== Plant UML
+
+- open source tool for UML diagrams
+- it takes a textual description and produces a diagram
+- supported within markdown in GitLab
+- uses Graphviz to lay out the diagrams
+
+== Adding diagrams to markdown 
+
+[source, role="stretch"]
+----
+```plantuml
+class LatLong {
+	double latitude
+	double longitude
+}
+class LatLongs
+LatLongs *--> "*" LatLong: "latLongs"
+class MetaData
+LatLong *--> "1" MetaData: "metaData"
+```
+----
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Commit messages
+
+== Commit messages
+
+- Commit messages allow the developers to attach a description to the commits. 
+- overview of the project history
+- the better the commits messages the easiest is to navigate the project history and understand what happened
+
+== Commit message anatomy
+
+- Subject / Title    -  Essence of the commit in a few words     
+- Body - Extended textual description of what has been done 
+- Footer - Additional elements such as links to issues and other metadata 
+
+== Basic principles
+
+[.smaller-80]
+- be consistent
+- limit the subject line to 50 characters
+- don't put a period at the end of the subject line
+- put a blank line between the subject line and the body text
+- wrap the body text at 72 characters
+- use the imperative mood 
+- describe *what* and *why*, but not *how*
+- mention which component(s) / area changed.
+
+
+
+== Commit messages (2)
+
+image::../images/git_commit_2x.png[size=75%]
+[.smaller-40]
+https://xkcd.com/1296/
+
+
+
+
+== Conventional commits format
+
+```text
+<type>([optional scope]): <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+== More on conventional commit content (1)
+ 
+- fix: a commit of the type fix patches a bug in your codebase 
+- feat: a commit of the type feat introduces a new feature to the codebase 
+- BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change. A BREAKING CHANGE can be part of commits of any type.
+
+== More on conventional commit content (2)
+
+- more types:  build, chore, ci, docs, style, refactor, perf, test
+- footers other than BREAKING CHANGE: `<description>` may be provided and follow a convention similar to git trailer format (`token: value`).
+
+== Why to use the conventional commits?
+
+[.smaller-80]
+- Automatically generating CHANGELOGs.
+- Automatically determining a semantic version bump (based on the types of commits landed).
+- Communicating the nature of changes to teammates, the public, and other stakeholders.
+- Triggering build and publish processes.
+- Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.
+
+
+== What to write in the commit message
+
+[.smaller-80]
+- the subject line is the most important
+- clearly state the original issue / problem
+- clearly state *why* the change is made
+- minimize external reference use and aim at a self contained message
+- clearly state how the problem is fixed with the committed code 
+- add information about testing, especially if there are manual tests needed  
+
+Finally, read the message before committing as it might reveal that you should split it in smaller commits
+
+
+
+== Questions ?
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Commit messages
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/07-gitlab.adoc

+= User stories. Gitlab for agile development
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_NO: 7th lecture
+:LECTURE_TOPIC: User stories. Gitlab for agile development
+
+
+include::{includedir}header.adoc[]
+
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2020 - {LECTURE_NO}
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+==  User stories. Gitlab for agile development
+- Administrative Issues
+- User stories
+- Gitlab for agile
+
+== Groups
+* Groups are finalized
+* TAs for groups are announced on BlackBoard
+* GitLab groups https://gitlab.stud.idi.ntnu.no/it1901/groups-2020
+* gr20xx
+* for issues with the groups contact
+** Sondre (sondrhel@stud.ntnu.no) or 
+** Anh-Kha (akvo@stud.ntnu.no) 
+
+== Group contract (1)
+- Minimum requirements for agreement:
+** Presence
+** Time spent
+** Expectations for the individual contribution
+** What happens in the event of deviations or disagreements
+
+
+== Group contract (2)
+* must be approved by the TA for the group 
+* signed by all group members 
+* and delivered together with the first group deliverable
+
+== Group contract (3)
+- more recommeded items:
+** handling differences in motivation level and ambition
+** what quality is expected, how defines the group something to be "done"
+** distribution of time between meetings / group work / individual work
+** what happens if course work needs more time than expected
+
+== Group contract (4)
+- more recommeded items:
+** delays, sickness, absence - how does the group handle these
+** meeting routines both for physical and virtual (agreement for time, agenda, meeting minutes etc)
+** general communication tools (email, phone, im etc) and response time
+** dealing as a group with deliverables and deadlines 
+
+== Group contract (5)
+- more recommeded items:
+** roles 
+** giving feedback to the others  
+** dealing with conflicts and disagreements
+** dealing with breach of contract
+** procedure to follow if the group is not able to solve conflicts / disagreements internally
+
+
+== Next Deadline
+- 17th of September at midnight 
+** push you last changes to the group repository on Gitlab
+** post the signed group contract on BB
+
+== About domain selection
+- choose an app / service that you know well and select a couple of features to implement during the semester
+- point is to learn by implementing these using the required architectures
+- we are not looking for quantity but for quality, so just few core features will suffice
+
+== About domain selection (2)
+- the chosen app needs to be suitable for a cloud based service
+- there must therefore be some dynamic data per user managed by the server. 
+- eg. a (currency) calculation will NOT fit such a project. 
+- one good starting point are the cases from the HCI course (MMI)
+
+== User stories
+
+- slides from 1st lecture
+- video on user stories
+
+== Gitlab for agile
+
+* Issues
+* Milestones
+* Task lists
+* Labels
+* Boards
+* Quick actions
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/07-lecture-documentation.adoc

+= Documentation 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Documentation
+:LECTURE_NO: 7th lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2022 - {LECTURE_NO}
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Documentation
+- Markdown
+- Gitlab Flavoured Markdown (GFM)
+- PlantUML
+- Commit messages
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Documentation
+
+== Documentation
+
+- is an important part of software development
+- a way to ensure software quality
+- several levels of documentation
+
+[.smaller-60]
+Note: In IT1901 we also look if the documentation is original. You should not just copy paste the documentation from the examples and just rename things to match your project.  
+
+== Types of documentation
+
+- Design documentation
+- API specifications ( if applicable)
+- readme files
+- contribution guide
+- frequently asked questions (faq)
+- wiki
+- comments ( including Javadoc ) 
+
+== Who is reading the documentation
+
+- the developer him/herself
+- other developers 
+- future maintainers of the software product
+- external users (e.g. some provided API)
+- others within the company / institution (testers, deployment )
+- ....
+
+== How is documentation improving the quality
+
+- allow new team members to be productive faster
+- increase qualities such as maintainability and transferability
+- saves time for both other contributors and initial dev
+
+== Readme files
+
+- give overview information regarding a project, subproject, module
+- normally contains info about the role, contents, build details, dependencies and interactions with other parts / modules
+- it is a way to provide needed contextual information that otherwise is not apparent from just looking at the source code 
+
+== Comments (1)
+
+- allow adding documentation in close proximity with the code
+- they should not be a way to cope with bad naming or "special" assumptions in the code
+- the standardized comments such as JavaDoc allow  additional benefits such as code completion
+
+== Comments (2)
+
+[.center-paragraph]
+image::../images/lecture07/code-comments.png[width=100%]
+
+[.smaller-40]
+https://stfalcon.com/uploads/images/55c8bcff18b94.png
+
+== Comments (3)
+
+[source,java, role="stretch"]
+----
+/**
+  * Creates a LatLong object from a String, using a specific separator.
+  * The format is <latitude><separator><longitude>.
+  * @param s the String to parse
+  * @param sep the separator
+  * @return the new LatLong object
+  */
+public static LatLong valueOf(final String s, final String sep) {
+  final int pos = s.indexOf(sep);
+  if (pos < 0) {
+    throw new IllegalArgumentException("No '" + sep + "' in " + s);
+  }
+  final double lat = Double.valueOf(s.substring(0, pos).trim());
+  final double lon = Double.valueOf(s.substring(pos + sep.length()).trim());
+  return new LatLong(lat, lon);
+}
+----
+
+== Over-documenting
+
+- documentation needs to be concise
+- redundant documentation will result in maintenance overhead
+- if some entity / operation is clear and self then it does not normally need additional documentation
+
+== ! 
+
+[.center-paragraph]
+image::../images/lecture07/comment-all.jpeg[width=400]
+
+[.smaller-40]
+[.center-paragraph]
+https://miro.medium.com/max/1138/1*Pyxsc7Uixbitv5myywaA_Q.jpeg (Gary Larson comic)
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Markdown
+
+== Markdown 
+
+[.center-paragraph]
+Markdown is a lightweight markup language with plain text formatting syntax. Its design allows it to be converted to many output formats, but the original tool by the same name only supports HTML. Markdown is often used to format readme files, for writing messages in online discussion forums, and to create rich text using a plain text editor.
+
+[.smaller-40]
+https://en.wikipedia.org/wiki/Markdown
+
+== Markdown Syntax
+
+https://www.markdownguide.org/basic-syntax
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Gitlab Flavoured Markdown (GFM)
+
+== Gitlab Flavoured Markdown (GFM) 
+
+https://gitlab.stud.idi.ntnu.no/help/user/markdown
+
+== Why text based documentation
+
+- it is easier to modify and we do not need any special editors
+- it can be versioned same way as the code
+- holding  documentation in the repository and updating it will allow consulting the repository contents with the correct documentation for that snapshot in time
+
+== Plant UML
+
+- open source tool for UML diagrams
+- it takes a textual description and produces a diagram
+- supported within markdown in GitLab
+- uses Graphviz to lay out the diagrams
+
+== Adding diagrams to markdown 
+
+[source, role="stretch"]
+----
+```plantuml
+class LatLong {
+	double latitude
+	double longitude
+}
+class LatLongs
+LatLongs *--> "*" LatLong: "latLongs"
+class MetaData
+LatLong *--> "1" MetaData: "metaData"
+```
+----
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Commit messages
+
+== Commit messages
+
+- Commit messages allow the developers to attach a description to the commits. 
+- overview of the project history
+- the better the commits messages the easiest is to navigate the project history and understand what happened
+
+== Commit message anatomy
+
+- Subject / Title    -  Essence of the commit in a few words     
+- Body - Extended textual description of what has been done 
+- Footer - Additional elements such as links to issues and other metadata 
+
+== Basic principles
+
+[.smaller-80]
+- be consistent
+- limit the subject line to 50 characters
+- don't put a period at the end of the subject line
+- put a blank line between the subject line and the body text
+- wrap the body text at 72 characters
+- use the imperative mood 
+- describe *what* and *why*, but not *how*
+- mention which component(s) / area changed.
+
+== Questions ?
+
+
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/07-lecture.adoc

+= Unit testing 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Unit testing 
+:LECTURE_NO: 7th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2021 - {LECTURE_NO}
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Testing
+
+== Testing
+
+[%step]
+- is an important part of software development
+- a way to ensure software quality
+- automated testing allows to develop new features with a minimal effort to check if the software still works as expected
+- testing frameworks  
+
+== Testing (2)
+
+[%step]
+- design 
+- implement
+- write automated tests
+- run tests
+- we do not test just for know, we write tests to keep running them during project life cycle 
+
+== Testing (3)
+
+[%step]
+- design tests
+- implement the test
+- provide inputs
+- run the tests
+- provide expected outputs
+- check if the result  we get matches what we expect
+- produce a manageable output that the developer can consult 
+
+== Testing (3)
+
+- design tests
+- implement the test
+- provide inputs
+- *run the tests*
+- provide expected outputs
+- *check if the result  we get matches what we expect*
+- *produce a manageable output that the developer can consult* 
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== JUnit
+
+
+== JUnit
+
+- Is a Java unit testing framework.
+- provides the means to automate test
+- allows to eliminate redundant testing tasks  
+
+
+== JUnit 4
+
+``` java
+import org.junit.*;
+
+public class FoobarTest {
+    @BeforeClass
+    public static void setUpClass() throws Exception {
+        // Code executed before the first test method
+    }
+
+    @Before
+    public void setUp() throws Exception {
+        // Code executed before each test
+    }
+ 
+    @Test
+    public void testOneThing() {
+        // Code that tests one thing
+    }
+
+    @Test
+    public void testAnotherThing() {
+        // Code that tests another thing
+    }
+
+    @Test
+    public void testSomethingElse() {
+        // Code that tests something else
+    }
+
+    @After
+    public void tearDown() throws Exception {
+        // Code executed after each test 
+    }
+ 
+    @AfterClass
+    public static void tearDownClass() throws Exception {
+        // Code executed after the last test method 
+    }
+}
+```
+
+[.smaller-40]
+https://en.wikipedia.org/wiki/JUnit
+
+== JUnit 5 
+
+``` java
+import org.junit.jupiter.api.*;
+
+public class FoobarTest {
+    @BeforeAll
+    public static void setUpClass() throws Exception {
+        // Code executed before the first test method
+    }
+
+    @BeforeEach
+    public void setUp() throws Exception {
+        // Code executed before each test
+    }
+ 
+    @Test
+    public void testOneThing() {
+        // Code that tests one thing
+    }
+
+    @Test
+    public void testAnotherThing() {
+        // Code that tests another thing
+    }
+
+    @Test
+    public void testSomethingElse() {
+        // Code that tests something else
+    }
+
+    @AfterEach
+    public void tearDown() throws Exception {
+        // Code executed after each test 
+    }
+ 
+    @AfterAll
+    public static void tearDownClass() throws Exception {
+        // Code executed after the last test method 
+    }
+}
+```
+
+== JUnit 4 vs JUnit 5
+
+[.smaller-60]
+[%header,cols=3*] 
+|===
+|Element
+|JUnit 4
+|JUnit 5
+
+
+|package
+|org.junit.*
+|org.junit.jupiter.api.*
+
+|code before first test
+|@BeforeClass
+|@BeforeAll
+
+|code before each test
+|@Before
+|@BeforeEach
+
+|test
+|@Test
+|@Test
+
+|code after each test
+|@After
+|@AfterEach
+
+|code after last test
+|@AfterClass
+|@AfterAll
+
+
+
+|===
+
+== JUnit 4 vs JUnit 5 (2)
+
+[.smaller-60]
+[%header,cols=3*] 
+|===
+|Element
+|JUnit 4
+|JUnit 5
+
+
+|ignoring test
+|@Ignore
+|@Disabled
+
+|assertions *statically* accessed with
+|`Assert.assert`...
+|`Assertions.assert`...
+
+|assertion messsage position
+|in the beginning of argument list
+|in the end of argument list   
+
+|===
+
+== Expecting exceptions (1)
+
+``` java
+@Test
+void testAssertingExpectedException() {
+	Assertions.assertThrows(<ExpectedException.class>, () -> {
+	    <code expected to throw exception>;
+		});
+}
+```
+
+== Expecting exceptions (2)
+
+- if the code throws
+** the exception class that is expected the the test will PASS
+** a descendent class exception that is expected the the test will PASS
+** a different exception type the test will FAIL
+** throws no exception the test will FAIL
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Testing in todo-list example
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/08-eclipse-che.adoc

+= CDEs / Eclipse Che 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: CDEs / Eclipse Che 
+:LECTURE_NO: 8th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2023 - {LECTURE_NO}
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Administrative issues
+- CDEs
+- Eclipse Che
+- Git - Special Files
+- Summary
+
+
+== Group work
+
+- 1st group assignment - deadline - 21.09.2023 18:00
+- Eclipse Che requirement is replaced
+- Need to have documentation that indicates the java and maven versions needed
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Cloud Cevelopment Environments (CDEs)
+
+== CDEs
+
+- aim is to have a browser as sole requirement
+- click a link to open the project
+- automated git setup 
+- the entire development environment is preconfigured
+- everyone runs the same environment (works on any machine)
+- improved collaboration and onboarding
+
+== CDEs (2)
+
+- Gitpod 
+- Codespaces
+- Eclipse Che
+- etc
+- the main idea is having a preconfigured container running on a cloud infrastructure 
+
+== CDEs (3)
+
+- we tradeoff control
+- we are dependent of network access
+- save time (Gitpod claims it saves 5h/week/dev)
+- less developers work on their environment setting skills
+- limited somewhat by the browser view
+
+
+== Eclipse Che
+
+- open source - Eclipse Foundation
+- available online hosted by RedHat
+- can be self hosted on Kubernetes
+- we will use it in IT1901
+    ** test in deliverable 2
+    ** obligatory for deliverable 3
+
+
+== Eclipse Che IT1901
+
+[.smaller-80]
+- https://che.stud.ntnu.no
+- current limitations 
+ ** container UI needs to be started manually
+ ** UI might lock (screensaver) - we need to unlock using terminal commands
+ ** every user is limited to 1 running workspace
+ ** stoping a workspace loses changes  (you should always push your changes before closing)
+
+== Eclipse Che IT1901
+
+[.smaller-80]
+- setting up Gitlab access
+ ** in Che -> User Preferences -> Personal Access Tokens
+ ** Add token
+ ** if you do not have a token  - generate one in Gitlab
+- opening a project in Che
+ ** using a link - https://che.stud.ntnu.no/#https://gitlab.stud.idi.ntnu.no/project_path?new
+ ** using the dashboard in Che
+
+== Eclipse Che configuration
+
+- devfile.yaml or .devfile.yaml in the root of the repo
+- https://eclipse.dev/che/docs/stable/end-user-guide/devfile-introduction/
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Demo
+
+
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/08-git-plus-work.adoc

+= Advanced Git + Work Practices 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Advanced Git + Work Practices 
+:LECTURE_NO: 8th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2024 - {LECTURE_NO}
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Administrative issues
+- Group exercise 3
+- Fixing errors with Git
+- Special files
+- Work practices - GitLab
+- Summary
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+== 1st individual exercise
+
+- most students done
+- we will finalize the feedback
+
+
+== Approaching Deadlines
+
+- Torsdag, 10. oktober / 23:59 
+** 2nd group deliverable
+
+- Torsdag, 14. november / 23:59 
+** 3rd group deliverable
+
+
+== Next Lecture
+
+* OOP principles and practices
+* modular software
+* REST APIs
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Group exercise 3
+
+- continuation of the previous 2 phases
+- half of the grade
+- important choices - extend functionality - vs alternative client
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Fixing errors with Git
+
+== Typical errors
+
+- staging the wrong files
+- wrong commit messsage
+- committing the wrong file(s)
+- deleting the wrong branch
+- deleting the wrong commit
+- committing sensitive files
+
+== Compounding the gravity
+
+- easier to fix before push
+- more issues with shared commits
+
+== Recommended approaches
+- not pushed
+    ** change history ok
+- pushed
+    ** fix issues and add a new commit
+    ** revert commit with `git revert ...`
+- changing history on pushed commits
+    ** only  if there is no other option
+    ** team is small enough to manage this
+
+
+== Relevant commands
+
+- `git restore --staged <file> ...` - to unstage
+- `git commit --ammend`
+- `git rebase -i HEAD~n`
+- `git revert <sha value>`
+- `git reflog` + `git reset --hard <sha value>` 
+
+
+== Relevant commands - aftermath
+
+- `git push --force-with-lease`  is a safer option that will not overwrite any work on the remote branch if more commits were added to the remote branch
+- `git pull .... --allow-unrelated-histories`
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Special files
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Git Special Files
+
+== Overview
+
+- .gitignore
+- .mailmap 
+- .gitkeep 
+- .gitattributes 
+
+== .gitignore
+
+- configure files to ignore 
+- https://git-scm.com/docs/gitignore
+- https://gitignore.io
+
+== .mailmap
+
+- map author / committer names and emails
+- https://git-scm.com/docs/gitmailmap
+
+
+== .mailmap
+
+``` 
+# Hallvard
+Hallvard Trætteberg <hal@ntnu.no> Hallvard Trætteberg <hal@ntnu.no>       
+Hallvard Trætteberg <hal@ntnu.no> Hallvard Traetteberg <hal@ntnu.no>
+Hallvard Trætteberg <hal@ntnu.no> hal <hal@ntnu.no>
+# Adrian
+George Adrian Stoica <stoica@ntnu.no> George Adrian Stoica <stoica@ntnu.no>
+George Adrian Stoica <stoica@ntnu.no> Adrian Stoica <stoica@ntnu.no>
+
+```
+
+== .gitkeep
+
+- keep in the repository empty folders
+- git keeps track of folders that have files 
+- not really a git special file 
+- widely used convention
+- typically we remove the file when we add other files to the folder 
+
+== .gitattributes
+
+- https://www.git-scm.com/docs/gitattributes
+- control git attributes per path
+- for example configure how EOL is handled
+
+== .gitattributes
+
+```
+# Set the default behavior, in case people don't have core.autocrlf set.
+* text=auto
+
+# Set linux endings for . files
+.bashrc text eol=lf
+.xinitrc text eol=lf
+
+# Explicitly declare text files you want to always be normalized and converted
+# to native line endings on checkout.
+*.c text
+*.h text
+
+# Declare files that will always have CRLF line endings on checkout.
+*.sln text eol=crlf
+
+# Denote all files that are truly binary and should not be modified.
+*.png binary
+*.jpg binary
+
+```
+[smaller-40]
+https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings
+
+
+== Other special files
+
+- GitLab
+** .gitlab-ci.yml 
+** description templates
+** `.gitlab/issue_templates` or 
+** `.gitlab/merge_request_templates` 
+- Eclipse Che
+** devfile.yaml
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Work practices - GitLab
+
+
+== Gitlab for agile
+
+* Issues
+* Milestones
+* Task lists
+* Labels
+* Boards
+* Quick actions
+
+== Using templates
+
+* Issue templates
+* Merge request templates
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file