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

lectures/revealjs/08-git-special-files.adoc

+= Git Special Files
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Git Special Files 
+:LECTURE_NO: 8th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2023 - {LECTURE_NO}
+
+
+[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
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/08-lecture.adoc

+= Unit testing 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Unit testing 
+:LECTURE_NO: 8th 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-workflow-example.adoc

+= Workflow Example 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Workflow example
+:LECTURE_NO: 8th lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2019 - {LECTURE_NO}
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+
+- User story
+- Issues
+- Git flow
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== User Story
+
+== User Story
+
+In the backlog of the simpleexample2 we get the following user story:
+
+- As a user I want to be able to add name, description etc.  to some of the locations I saved on the map in order to be easier to refer back to the most interesting places. 
+
+[.notes]
+--
+* we know from the PO / users that the expected points with additional info is relatively small
+--
+
+== From user story to issues
+
+[%step]
+- considering that the user story is to be included in the next iteration (sprint) then
+- the user story starts a process of discussion and planning within the development team
+- we need to understand what are the consequences of the new requirements for the different modules
+- we also need to create the necessary issues that
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Issues
+
+
+== The issues
+
+https://gitlab.stud.idi.ntnu.no/it1901/course-material/issues
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Typical git flow
+
+== Source code management
+[.center-paragraph]
+link:scm.html[Source code management (SCM)]
+
+
+include::{includedir}footer.adoc[]

lectures/revealjs/09-documentation.adoc

+= Documentation 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Documentation
+:LECTURE_NO: 9th lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2020 - {LECTURE_NO}
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Documentation
+- Markdown
+- Gitlab Flavoured Markdown (GFM)
+- PlantUML
+
+
+[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"
+```
+----
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/09-lecture-modular.adoc

+= Modular software 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Modular software 
+:LECTURE_NO: 9th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2022 - {LECTURE_NO}
+
+
+== Overview
+- Group deliverable 2 (GD2)
+- Architectural styles
+- Modular projects with Maven and Java
+
+== GD2 - modularisering
+
+* kodingsprosjektet skal deles opp i egnede moduler med avhengigheter
+* bygging styres (fortsatt) av maven og hver modul har hensiktmessig konfigurasjon
+* maven-moduler er et krav, mens Java-moduler er ikke (men i utgangspunktet anbefalt)
+* mer om modularisering senere
+
+[.smaller-80]
+== GD2 - arkitektur
+
+* kjernelogikken (domenelaget) og ui (brukergrensesnittlaget) skal skilles fra hverandre
+* persistens med JSON vha. egnet bibliotek, f.eks. Jackson
+** definere/dokumentere (?) filformat for brukerdata og evt. innstillinger
+* reflektere over og velge mellom dokumentmetafor (desktop) og implisitt lagring (app)
+* alle tre lagene spiller sammen
+
+== GD2 - kodekvalitet
+
+* tester skal skrives for alle modulene 
+* testdekningsgrad og (annen) kodekvalitet skal sjekkes av egne maven-tillegg (f.eks. **jacoco**, **checkstyle** og **spotbugs**)
+* rimelig god testdekning av alle lagene
+
+== GD2 - dokumentasjon
+
+* generell dokumentasjon må holdes oppdatert
+* arkitektur med minst et diagram (bruk PlantUML) i tillegg til teksten i readme
+* valg knyttet til arbeidsvaner, arbeidsflyt, testing, bruk av verktøy for sjekking av kodekvalitet (f.eks. innstillinger)
+
+== GD2 - arbeidsvaner
+
+* kodingsoppgaver skal være utgangspunktet for alt arbeid
+* greiner (branch) samler arbeid for hver kodingsoppgave (?)
+** se alternativet **trunk based development**
+* bruk milepæl (milestones) knyttet til innleveringen
+* dere jobber i par og bytter på å kode
+* "produktiv" kode og tester må holde tritt
+
+== GD2 - lær (i smidig ånd)
+
+* hva virker bra og ikke så bra
+* hva er en god oppdeling i og fordeling av arbeidsoppgaver
+* ikke lur dere selv eller andre
+
+[.smaller-80]
+== GD2 - leveranse
+* prosjektet må være gitpod-klart med Gitpod-knapp i gitlab eller merkelapp i README-fila
+* maven skal brukes til kjøring, testing og sjekk av kodekvalitet
+* kode må ligge i master-greina av standard kodelager for gruppa
+* på Blackboard leveres en enkel tekst om at kodelageret er klart for vurdering
+* det er også nå "flytende/anbefalt" frist, så hold kontakt med lærerassistenten om fremdrift
+
+== Architectural styles
+
+An architectural style is a conceptual specification of how a certain
+system will be structured and function. 
+
+== Architectural styles
+
+- monolithic applications
+- 3-tier applications
+- REST
+
+== layers vs. tiers
+
+- sometimes the terms are used interchangeably
+- there is a difference
+** layers - logical separation
+** tiers - physical separation
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== monolithic applications
+
+== monolithic applications (1)
+
+- All the functionality is packed in a single software unit
+** ui
+** logic
+** data
+- designed without modularity
+- also called single-tiered application
+
+== !
+
+image::../images/lecture12/1tier.png[canvas, size=contain]
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== 3-tier applications
+
+== !
+
+image::../images/lecture12/3tier.png[canvas, size=contain]
+
+== 3-tier applications (2)
+
+- application where the various functions are separated
+** presentation tier (UI / frontend)
+** logic tier (business tier)
+** data tier (data storage + data access)
+- also called 3-layer
+- application is modular 
+
+== 3-tier applications (3)
+
+- ability to update / replace just parts of the application
+- ability to independently scale the layers
+- ability to re-use layers
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== REST
+
+[.smaller-80]
+== REST
+- Representational state transfer (REST)  
+- architectural style involving use of Web Services 
+- set of constraints are applied 
+** client server
+** statelessness (no client context is stored on the server side)
+** cacheability (responses state if they can be cached or not)
+** uniform interface
+** layered system (adding layers like proxy or load balancer)
+
+
+== REST (cont.)
+
+- Web services that implement REST are called RESTful APIs
+- a base URI, example: https://gitlab.stud.idi.ntnu.no/api/v4
+- standard HTTP methods (e.g., GET, POST, PUT, PATCH and DELETE);
+- data formats for requests and responses (json, xml, etc)
+
+== !
+
+image::../images/lecture12/itodo.png[canvas, size=contain]
+
+== !
+
+image::../images/lecture12/mtodo.png[canvas, size=contain]
+
+
+== !
+
+image::../images/lecture12/rtodo.png[canvas, size=contain]
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Modularity
+
+== Modularity
+
+- means for splitting a large problems into parts
+** distribute and isolate work
+** distribute artifacts for use and reuse
+- more or less supported by tools and languages
+** maven - modular build
+** java - strong encapsulatation
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Modularity with maven
+
+== Modular projects with Maven
+
+- main "parent" module with common configuration
+- sub-modules with dependencies
+** libraries (and plugins) are modules
+** own modules follow architecture
+- manages build tasks
+** sequenced according to dependencies
+** execute in appropriate context e.g. classpath
+
+== Modular projects with Maven
+
+- use of inheritance
+- parent `pom` has configuration that is inherited by modules' `pom`
+- the descendent `pom` can override inherited configuration elements
+- descendant `pom` inherits most elements with the exception of things like artifactid, name which are used to identify the parent `pom`
+
+== Modular projects with Maven (2)
+
+- reduce complexity and size of individual build files
+- reliably use consistent versions for dependencies and plugins 
+
+== Parent pom example
+
+[.smaller-40]
+```xml
+<?xml version="1.0" encoding="UTF-8" ?>
+
+<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+    <modelVersion>4.0.0</modelVersion>
+
+    <groupId>it1901.todolist</groupId>
+    <artifactId>parent</artifactId>
+    <version>0.0.1-SNAPSHOT</version>
+    <packaging>pom</packaging>
+
+    <properties>
+        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+    </properties>
+
+    <dependencyManagement>
+        <dependencies>
+            <dependency>
+               ...
+            </dependency>
+            ...
+        </dependencies>
+    </dependencyManagement>
+
+    <build>
+        <pluginManagement>
+            <plugins>
+                <plugin>
+      				...
+                </plugin>
+                ...
+            </plugins>
+        </pluginManagement>
+    </build>
+
+    <modules>
+        <module>core</module>
+        <module>fxui</module>
+    </modules>
+</project>
+
+```
+
+== Descendant pom example
+
+[.smaller-40]
+```xml
+<?xml version="1.0" encoding="UTF-8" ?>
+
+<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+    <modelVersion>4.0.0</modelVersion>
+
+    <parent>
+        <groupId>it1901.todolist</groupId>
+        <artifactId>parent</artifactId>
+        <version>0.0.1-SNAPSHOT</version>
+    </parent>
+
+    <artifactId>fxui</artifactId>
+
+    <dependencies>
+		<dependency>
+			...
+		</dependency>
+		...
+    </dependencies>
+
+    <build>
+        <plugins>
+            <plugin>
+                ...
+            </plugin>
+            ...
+        </plugins>
+    </build>
+</project>
+
+```
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Modularity with Java
+
+== Java modules
+
+[.smaller-80]
+* corresponds to a set of packages
+* strong encapsulation
+** explicitly export packages
+** explicitly state dependencies
+** also enforced during runtime
+* advantages
+** avoid relying on internals
+** build lighter apps
+* disadvantages...
+
+== core - module-info.java
+
+```java
+module todolist.core {
+    requires transitive com.fasterxml.jackson.databind;
+
+    exports todolist.core;
+    exports todolist.json;
+}
+```
+
+== core - https://gitlab.stud.idi.ntnu.no/it1901/todo-list/-/blob/master/todolist/core/src/main/java/module-info.java[module-info.java]
+
+* module name
+** how to get (guess) name of libraries 
+* **requires** - what this module needs
+** **transitive** - others will need this too
+** **exports** - what others may use
+
+== fxui - https://gitlab.stud.idi.ntnu.no/it1901/todo-list/-/blob/master/todolist/fxui/src/main/java/module-info.java[module-info.java]
+
+```java
+module todolist.ui {
+    requires com.fasterxml.jackson.databind;
+
+    requires java.net.http;
+
+    requires javafx.base;
+    requires javafx.controls;
+    requires javafx.fxml;
+
+    requires todolist.core;
+    requires fxutil;
+
+    opens todolist.ui to javafx.graphics, javafx.fxml;
+}
+```
+
+== fxui - module-info.java
+
+* **opens** ... *to* - allow getting runtime info about classes using so-called _reflection_
+** fxml
+** REST frameworks
+** test frameworks
+* **--add-opens** command line option
+** support unmodularized mode
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/09-lecture.adoc

+= Documentation 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Documentation
+:LECTURE_NO: 9th lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2020 - {LECTURE_NO}
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Documentation
+- Markdown
+- Gitlab Flavoured Markdown (GFM)
+- PlantUML
+
+
+[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"
+```
+----
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/09-oop-rest.adoc

+= OO Principles + REST APIs 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: OO Principles + REST APIs 
+:LECTURE_NO: 9th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2024 - {LECTURE_NO}
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Administrative issues
+- Object Oriented Principles
+- REST APIs
+- Summary
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+
+== Approaching Deadlines
+
+- Torsdag, 14. november / 23:59 
+** 3rd group deliverable
+
+
+== Remaining Lectures
+
+- w43 23rd Oct - Integration testing - Preparing sofware releases
+- w44 30th Oct - Guest lecture - current development practices in industry
+- w45 7th Nov - Questions and Answers lecture - Present individual report assignment
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Object Oriented Principles
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Object Oriented Design
+
+
+== Object Oriented Design
+
+“An object-oriented system is made up of interacting objects that 
+maintain their own local state and provide operations on that state. 
+The representation of the state is private and cannot be accessed directly 
+from outside the object. Object-oriented design processes involve 
+designing object classes and the relationships between these classes.” 
+(Sommerville: p 198)
+
+
+== Object Oriented Principles
+
+- Abstraction
+- Encapsulation
+- Inheritance
+- Polymorphism
+
+
+== Abstraction
+
+- hiding the internal data and implementation from the external world
+- hide complexity and show essential information
+- could be classified further 
+** data abstraction
+** process abstraction
+- abstract classes and interfaces
+
+
+== Encapsulation
+
+- integrating fields (data) and methods (behaviors) into a single unit 
+- fields are hidden from  other classes 
+- fields can only be accessed by the methods of the class in which they are found
+
+
+== Inheritance
+
+- mechanism that allows classes to acquire fields and behaviors from other class
+- the properties of the "parent" class are inherited by the "child" class
+
+== Polymorphism
+
+- the ability to perform a single action in different ways
+- differently stated -  have one interface but  have multiple implementations
+** overriding
+** overloading
+
+== Common issues OOD
+
+- External dependencies:
+** New requirements can produce changes in many places
+
+- Internal dependencies:
+** changes in a part of the code affect other parts
+** difficult to re-use code
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== SOLID principles
+
+== SOLID principles 
+
+- **S**ingle responsibility principle
+- **O**pen–closed principle
+- **L**iskov substitution principle
+- **I**nterface segregation principle
+- **D**ependency inversion principle
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Single responsibility principle
+
+
+== Single responsibility principle
+
+- A class should only have a single responsibility
+- A class should have one, and only one reason to change
+- Examples:
+** simpleexample2: JSON-serialization
+*** Latlong serializer
+*** Latlong deserializer
+
+
+== Single responsibility principle
+
+Applying this principle has as effects:
+
+- Smaller sized classes
+- Classes that are easier to:
+** understand
+** test
+** maintain
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Open–closed principle
+
+== Open–closed principle
+
+- Software entities should be open for extension, but closed for modification.
+- Example: JavaFX classes
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Liskov substitution principle
+
+== Liskov substitution principle
+
+- Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
+
+
+== Liskov substitution principle (2)
+
+image::../images/lecture11/rectangle-square.png[canvas, size=contain]
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Interface segregation principle
+
+== Interface segregation principle
+
+- Many client-specific interfaces are better than one general-purpose interface.
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Dependency inversion principle
+
+
+== Dependency inversion principle
+
+- One should depend upon abstractions, not concretions.
+- e.g. Data access layer in between controler and domain layer
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== DRY Principle
+
+
+== Don't Repeat Yourself (DRY)
+
+- "Every piece of knowledge or logic must have a single, unambiguous representation within a system."
+- Andy Hunt and Dave Thomas in their book The Pragmatic Programmer
+
+[.smalled-40]
+https://en.wikipedia.org/wiki/Don%27t_repeat_yourself  
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== KISS Principle
+
+== Keep It Simple, Stupid (KISS)
+
+- write simple code
+- if classes / methods become lengthy and complicated you need to consider refactoring
+** extracting code in separate classes methods
+** eliminate redundant code
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Some useful considerations
+
+
+== Refactoring
+
+- work on the code without adding functionality
+- simplify and optimize
+- make it more maintainable and reusable
+
+== Refactoring (2)
+
+- find problem areas and improve
+** very long classes or methods
+** long list of parameters
+** confusing package structures
+** ...
+
+== Refactoring (3)
+
+- aim for short methods with simple control flow
+- avoid recursion (harder to understand the )
+- limit loops
+- limit variables to the smallest scope possible
+
+== Nesting
+
+- complex flow in methods is hard to understand
+- if you are beyond 2-3 levels you need to consider refactoring
+
+== Naming
+
+- use suggestive names
+- adhere to conventions
+- do not abbreviate
+- avoid single letter variables (y)
+- do not include types in names (intCount, bResult)
+
+== Naming (2)
+
+- do include units where needed ( delayInSeconds )
+- difficulty naming might indicate the need to rethink design
+- avoid naming classes Abstract... or Base...
+- avoid using an evergrowing "Utils" class
+
+
+[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
+
+```
+
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== REST APIs
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Architectural styles
+
+== Architectural styles
+
+An architectural style is a conceptual specification of how a certain
+system will be structured and function. 
+
+== Architectural styles
+
+- monolithic applications
+- 3-tier applications
+- REST
+
+== layers vs. tiers
+
+- sometimes the terms are used interchangeably
+- there is a difference
+** layers - logical separation
+** tiers - physical separation
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== monolithic applications
+
+== monolithic applications (1)
+
+- All the functionality is packed in a single software unit
+** ui
+** logic
+** data
+- designed without modularity
+- also called single-tiered application
+
+== !
+
+image::../images/lecture12/1tier.png[canvas, size=contain]
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== 3-tier applications
+
+== !
+
+image::../images/lecture12/3tier.png[canvas, size=contain]
+
+== 3-tier applications (2)
+
+- application where the various functions are separated
+** presentation tier (UI / frontend)
+** logic tier (business tier)
+** data tier (data storage + data access)
+- also called 3-layer
+- application is modular 
+
+== 3-tier applications (3)
+
+- ability to update / replace just parts of the application
+- ability to independently scale the layers
+- ability to re-use layers
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== REST
+
+[.smaller-80]
+== REST
+- **RE**presentational **S**tate **T**ransfer (REST)  
+- architectural style involving use of Web Services 
+- set of constraints are applied 
+** client server
+** statelessness (no client context is stored on the server side)
+** cacheability (responses state if they can be cached or not)
+** uniform interface
+** layered system (adding layers like proxy or load balancer)
+
+
+== REST (cont.)
+
+- Web services that implement REST are called RESTful APIs
+- a base URI, example: https://gitlab.stud.idi.ntnu.no/api/v4
+- standard HTTP methods (e.g., GET, POST, PUT, PATCH and DELETE);
+- data formats for requests and responses (json, xml, etc)
+
+== !
+
+image::../images/lecture12/itodo.png[canvas, size=contain]
+
+== !
+
+image::../images/lecture12/mtodo.png[canvas, size=contain]
+
+
+== !
+
+image::../images/lecture12/rtodo.png[canvas, size=contain]
+
+
+== HTTP requests
+ - **H**yper**t**ext **T**ransfer **P**rotocol (HTTP)
+ - clients (e.g. browser) send requests
+ - servers (web site / service) send responses
+
+== HTTP Request message
+ 
+ - a request line `GET / HTTP/1.1`
+ - request headers - `User-Agent`, `Accept`, `Content-Type` etc.
+ - an empty line (containing only a `carriage return` and a `line feed`)
+ - an optional message body
+
+== HTTP Methods
+
+- HTTP specification defines `methods` to indicate what action is expected from the server
+** GET, HEAD, OPTIONS
+** POST, PUT, PATCH
+** DELETE
+
+== APIs
+
+- **A**pplication **P**rogramming **I**nterface
+- "Glue" that makes possible different pieces of software to interoperate
+- It is meant to be machine readable / usable
+- APIs are everywhere - at different levels - software libraries, operating system, applications, web services etc.
+
+== APIs (2) 
+
+- typically a set of calls or requests, expected call format, expected response format, data structures
+- separate the implementation from the interface
+- allow programs in one language to use functionality written in some other language
+- cater to modular software
+
+
+== Security considerations
+
+- CORS (Cross-Origin Resource Sharing)
+** headers `Access-Control-Allow-Origin` 
+- Authentication (Basic Auth,  OAuth etc)
+- HTTPS (HTTP over TLS)
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Modularity
+
+== Modularity
+
+- means for splitting a large problems into parts
+** distribute and isolate work
+** distribute artifacts for use and reuse
+- more or less supported by tools and languages
+** maven - modular build
+** java - strong encapsulation
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Modularity with maven
+
+== Modular projects with Maven
+
+- main "parent" module with common configuration
+- sub-modules with dependencies
+** libraries (and plugins) are modules
+** own modules follow architecture
+- manages build tasks
+** sequenced according to dependencies
+** execute in appropriate context e.g. classpath
+
+== Modular projects with Maven
+
+- use of inheritance
+- parent `pom` has configuration that is inherited by modules' `pom`
+- the descendent `pom` can override inherited configuration elements
+- descendant `pom` inherits most elements with the exception of things like artifactid, name which are used to identify the parent `pom`
+
+== Modular projects with Maven (2)
+
+- reduce complexity and size of individual build files
+- reliably use consistent versions for dependencies and plugins 
+
+== Parent pom example
+
+[.smaller-40]
+```xml
+<?xml version="1.0" encoding="UTF-8" ?>
+
+<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+    <modelVersion>4.0.0</modelVersion>
+
+    <groupId>it1901.todolist</groupId>
+    <artifactId>parent</artifactId>
+    <version>0.0.1-SNAPSHOT</version>
+    <packaging>pom</packaging>
+
+    <properties>
+        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+    </properties>
+
+    <dependencyManagement>
+        <dependencies>
+            <dependency>
+               ...
+            </dependency>
+            ...
+        </dependencies>
+    </dependencyManagement>
+
+    <build>
+        <pluginManagement>
+            <plugins>
+                <plugin>
+      				...
+                </plugin>
+                ...
+            </plugins>
+        </pluginManagement>
+    </build>
+
+    <modules>
+        <module>core</module>
+        <module>fxui</module>
+    </modules>
+</project>
+
+```
+
+== Descendant pom example
+
+[.smaller-40]
+```xml
+<?xml version="1.0" encoding="UTF-8" ?>
+
+<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+    <modelVersion>4.0.0</modelVersion>
+
+    <parent>
+        <groupId>it1901.todolist</groupId>
+        <artifactId>parent</artifactId>
+        <version>0.0.1-SNAPSHOT</version>
+    </parent>
+
+    <artifactId>fxui</artifactId>
+
+    <dependencies>
+		<dependency>
+			...
+		</dependency>
+		...
+    </dependencies>
+
+    <build>
+        <plugins>
+            <plugin>
+                ...
+            </plugin>
+            ...
+        </plugins>
+    </build>
+</project>
+
+```
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Modularity with Java
+
+== Java modules
+
+[.smaller-80]
+* corresponds to a set of packages
+* strong encapsulation
+** explicitly export packages
+** explicitly state dependencies
+** also enforced during runtime
+* advantages
+** avoid relying on internals
+** build lighter apps
+* disadvantages...
+
+== core - module-info.java
+
+```java
+module todolist.core {
+    requires transitive com.fasterxml.jackson.databind;
+
+    exports todolist.core;
+    exports todolist.json;
+}
+```
+
+== core - https://gitlab.stud.idi.ntnu.no/it1901/todo-list/-/blob/master/todolist/core/src/main/java/module-info.java[module-info.java]
+
+* module name
+** how to get (guess) name of libraries 
+* **requires** - what this module needs
+** **transitive** - others will need this too
+** **exports** - what others may use
+
+== fxui - https://gitlab.stud.idi.ntnu.no/it1901/todo-list/-/blob/master/todolist/fxui/src/main/java/module-info.java[module-info.java]
+
+```java
+module todolist.ui {
+    requires com.fasterxml.jackson.databind;
+
+    requires java.net.http;
+
+    requires javafx.base;
+    requires javafx.controls;
+    requires javafx.fxml;
+
+    requires todolist.core;
+    requires fxutil;
+
+    opens todolist.ui to javafx.graphics, javafx.fxml;
+}
+```
+
+== fxui - module-info.java
+
+* **opens** ... *to* - allow getting runtime info about classes using so-called _reflection_
+** fxml
+** REST frameworks
+** test frameworks
+* **--add-opens** command line option
+** support unmodularized mode
+
+
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/09-second-modular.adoc

+= Modular software 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Modular software 
+:LECTURE_NO: 9th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2023 - {LECTURE_NO}
+
+
+== Overview
+- Group Assignment 2 (GA2)
+- Architectural styles
+- Modular projects with Maven and Java
+- More on Eclipse Che
+- VSCode devcontainers
+- Summary
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Group Assignment 2 (GA2)
+
+
+== GA2 - modularisering
+
+* kodingsprosjektet skal deles opp i egnede moduler med avhengigheter
+* bygging styres (fortsatt) av maven og hver modul har hensiktmessig konfigurasjon
+* maven-moduler er et krav, mens Java-moduler er ikke (men i utgangspunktet anbefalt)
+* mer om modularisering senere
+
+[.smaller-80]
+== GA2 - arkitektur
+
+* kjernelogikken (domenelaget) og ui (brukergrensesnittlaget) skal skilles fra hverandre
+* persistens med JSON vha. egnet bibliotek, f.eks. Jackson
+** definere/dokumentere (?) filformat for brukerdata og evt. innstillinger
+* reflektere over og velge mellom dokumentmetafor (desktop) og implisitt lagring (app)
+* alle tre lagene spiller sammen
+
+== GA2 - kodekvalitet
+
+* tester skal skrives for alle modulene 
+* testdekningsgrad og (annen) kodekvalitet skal sjekkes av egne maven-tillegg (f.eks. **jacoco**, **checkstyle** og **spotbugs**)
+* rimelig god testdekning av alle lagene
+
+== GA2 - dokumentasjon
+
+* generell dokumentasjon må holdes oppdatert
+* arkitektur med minst et diagram (bruk PlantUML) i tillegg til teksten i readme
+* valg knyttet til arbeidsvaner, arbeidsflyt, testing, bruk av verktøy for sjekking av kodekvalitet (f.eks. innstillinger)
+
+== GA2 - arbeidsvaner
+
+* kodingsoppgaver skal være utgangspunktet for alt arbeid
+* greiner (branch) samler arbeid for hver kodingsoppgave (?)
+** se alternativet **trunk based development**
+* bruk milepæl (milestones) knyttet til innleveringen
+* dere jobber i par og bytter på å kode
+* "produktiv" kode og tester må holde tritt
+
+== GA2 - lær (i smidig ånd)
+
+* hva virker bra og ikke så bra
+* hva er en god oppdeling i og fordeling av arbeidsoppgaver
+* ikke lur dere selv eller andre
+
+[.smaller-80]
+== GA2 - leveranse
+* prosjektet må være eclipse che-klart med eclipse che lenke i README-fila
+* maven skal brukes til kjøring, testing og sjekk av kodekvalitet
+* kode må ligge i master-greina av standard kodelager for gruppa
+* på Blackboard leveres en enkel tekst om at kodelageret er klart for vurdering
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Architectural styles
+
+== Architectural styles
+
+An architectural style is a conceptual specification of how a certain
+system will be structured and function. 
+
+== Architectural styles
+
+- monolithic applications
+- 3-tier applications
+- REST
+
+== layers vs. tiers
+
+- sometimes the terms are used interchangeably
+- there is a difference
+** layers - logical separation
+** tiers - physical separation
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== monolithic applications
+
+== monolithic applications (1)
+
+- All the functionality is packed in a single software unit
+** ui
+** logic
+** data
+- designed without modularity
+- also called single-tiered application
+
+== !
+
+image::../images/lecture12/1tier.png[canvas, size=contain]
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== 3-tier applications
+
+== !
+
+image::../images/lecture12/3tier.png[canvas, size=contain]
+
+== 3-tier applications (2)
+
+- application where the various functions are separated
+** presentation tier (UI / frontend)
+** logic tier (business tier)
+** data tier (data storage + data access)
+- also called 3-layer
+- application is modular 
+
+== 3-tier applications (3)
+
+- ability to update / replace just parts of the application
+- ability to independently scale the layers
+- ability to re-use layers
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== REST
+
+[.smaller-80]
+== REST
+- Representational state transfer (REST)  
+- architectural style involving use of Web Services 
+- set of constraints are applied 
+** client server
+** statelessness (no client context is stored on the server side)
+** cacheability (responses state if they can be cached or not)
+** uniform interface
+** layered system (adding layers like proxy or load balancer)
+
+
+== REST (cont.)
+
+- Web services that implement REST are called RESTful APIs
+- a base URI, example: https://gitlab.stud.idi.ntnu.no/api/v4
+- standard HTTP methods (e.g., GET, POST, PUT, PATCH and DELETE);
+- data formats for requests and responses (json, xml, etc)
+
+== !
+
+image::../images/lecture12/itodo.png[canvas, size=contain]
+
+== !
+
+image::../images/lecture12/mtodo.png[canvas, size=contain]
+
+
+== !
+
+image::../images/lecture12/rtodo.png[canvas, size=contain]
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Modularity
+
+== Modularity
+
+- means for splitting a large problems into parts
+** distribute and isolate work
+** distribute artifacts for use and reuse
+- more or less supported by tools and languages
+** maven - modular build
+** java - strong encapsulation
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Modularity with maven
+
+== Modular projects with Maven
+
+- main "parent" module with common configuration
+- sub-modules with dependencies
+** libraries (and plugins) are modules
+** own modules follow architecture
+- manages build tasks
+** sequenced according to dependencies
+** execute in appropriate context e.g. classpath
+
+== Modular projects with Maven
+
+- use of inheritance
+- parent `pom` has configuration that is inherited by modules' `pom`
+- the descendent `pom` can override inherited configuration elements
+- descendant `pom` inherits most elements with the exception of things like artifactid, name which are used to identify the parent `pom`
+
+== Modular projects with Maven (2)
+
+- reduce complexity and size of individual build files
+- reliably use consistent versions for dependencies and plugins 
+
+== Parent pom example
+
+[.smaller-40]
+```xml
+<?xml version="1.0" encoding="UTF-8" ?>
+
+<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+    <modelVersion>4.0.0</modelVersion>
+
+    <groupId>it1901.todolist</groupId>
+    <artifactId>parent</artifactId>
+    <version>0.0.1-SNAPSHOT</version>
+    <packaging>pom</packaging>
+
+    <properties>
+        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+    </properties>
+
+    <dependencyManagement>
+        <dependencies>
+            <dependency>
+               ...
+            </dependency>
+            ...
+        </dependencies>
+    </dependencyManagement>
+
+    <build>
+        <pluginManagement>
+            <plugins>
+                <plugin>
+      				...
+                </plugin>
+                ...
+            </plugins>
+        </pluginManagement>
+    </build>
+
+    <modules>
+        <module>core</module>
+        <module>fxui</module>
+    </modules>
+</project>
+
+```
+
+== Descendant pom example
+
+[.smaller-40]
+```xml
+<?xml version="1.0" encoding="UTF-8" ?>
+
+<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+    <modelVersion>4.0.0</modelVersion>
+
+    <parent>
+        <groupId>it1901.todolist</groupId>
+        <artifactId>parent</artifactId>
+        <version>0.0.1-SNAPSHOT</version>
+    </parent>
+
+    <artifactId>fxui</artifactId>
+
+    <dependencies>
+		<dependency>
+			...
+		</dependency>
+		...
+    </dependencies>
+
+    <build>
+        <plugins>
+            <plugin>
+                ...
+            </plugin>
+            ...
+        </plugins>
+    </build>
+</project>
+
+```
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Modularity with Java
+
+== Java modules
+
+[.smaller-80]
+* corresponds to a set of packages
+* strong encapsulation
+** explicitly export packages
+** explicitly state dependencies
+** also enforced during runtime
+* advantages
+** avoid relying on internals
+** build lighter apps
+* disadvantages...
+
+== core - module-info.java
+
+```java
+module todolist.core {
+    requires transitive com.fasterxml.jackson.databind;
+
+    exports todolist.core;
+    exports todolist.json;
+}
+```
+
+== core - https://gitlab.stud.idi.ntnu.no/it1901/todo-list/-/blob/master/todolist/core/src/main/java/module-info.java[module-info.java]
+
+* module name
+** how to get (guess) name of libraries 
+* **requires** - what this module needs
+** **transitive** - others will need this too
+** **exports** - what others may use
+
+== fxui - https://gitlab.stud.idi.ntnu.no/it1901/todo-list/-/blob/master/todolist/fxui/src/main/java/module-info.java[module-info.java]
+
+```java
+module todolist.ui {
+    requires com.fasterxml.jackson.databind;
+
+    requires java.net.http;
+
+    requires javafx.base;
+    requires javafx.controls;
+    requires javafx.fxml;
+
+    requires todolist.core;
+    requires fxutil;
+
+    opens todolist.ui to javafx.graphics, javafx.fxml;
+}
+```
+
+== fxui - module-info.java
+
+* **opens** ... *to* - allow getting runtime info about classes using so-called _reflection_
+** fxml
+** REST frameworks
+** test frameworks
+* **--add-opens** command line option
+** support unmodularized mode
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== More on Eclipse Che
+
+== Eclipse Che IT1901
+
+[.smaller-80]
+- https://che.stud.ntnu.no
+- current limitations 
+ ** [.line-through]#container UI needs to be started manually#
+ ** UI might lock (screensaver) - [.line-through]#we need to unlock using terminal commands# 
+ ** every user is limited to 1 running workspace
+ ** [.line-through]#stoping a workspace loses changes#  (you should always push your changes before closing)
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== VSCode Devcontainers
+
+== VSCode Devcontainers
+
+- VSCode extension "Dev Containers"
+** related extension "Docker"
+** needs "Docker Desktop" installed locally
+- allow developing inside a Docker container
+- ensure local development with a consistent and reproducible environment
+
+== devcontainer.json
+```json
+{
+    "image":"adrianstoica/it1901:latest",
+    "forwardPorts": [6080,8080,5901],
+    "postStartCommand": "nohup bash -c '~/.vnc/startup  &'",
+    "customizations":{
+        "vscode": {
+            "extensions" : [
+                "vscjava.vscode-java-pack",
+                "vscjava.vscode-java-debug",
+                "vscjava.vscode-maven",
+                "vscjava.vscode-java-dependency",
+                "vscjava.vscode-java-test",
+                "redhat.java",
+                "yzhang.markdown-all-in-one",
+                "shd101wyy.markdown-preview-enhanced",
+                "DavidAnson.vscode-markdownlint",
+                "jebbs.plantuml",
+                "ms-vscode.live-server",
+                "vsls-contrib.codetour",
+                "ritwickdey.liveserver"
+            ]
+        }
+    }
+}
+
+```
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+include::{includedir}footer.adoc[]
\ No newline at end of file