lectures/revealjs/10-git-branching.adoc

+= Git Branching 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Git Branching 
+:LECTURE_NO: 10th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2023 - {LECTURE_NO}
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Git Branching
+
+== Git Branching
+
+- Using branches
+- Managing conflicts
+- Dealing with interruptions
+- Summary
+
+
+[.grid-left-right-50-50]
+== Typical sequence (simple collaboration)
+
+[.area-left]
+- working with a shared project
+** `git clone`
+** `git pull`
+
+[.area-right]
+** `git status` 
+** `git add ...`
+** `git commit ...`
+** `git push`
+
+
+== Possible improved workflow 
+
+- keep master only for finished work
+- uses branches for development work
+- when a feature branch is done it is merged into master
+
+[.grid-left-right-50-50]
+== Typical sequence (branches)
+
+[.area-left]
+** `git clone`
+** `git pull` 
+** `git checkout -b <branch_name>` 
+
+[.area-right]
+** `git status` + `git add ...` + `git commit ...` 
+** `git checkout master` 
+** `git merge <branch_name>` 
+** `git push`
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Conflicts
+
+== Conflicts (1)
+
+** when same files (lines) are changed by different devs
+** automatic merge is not possible 
+** we need to solve that to be able to push our changes 
+
+== Conflicts (2) - Setup VSCode
+
+- vscode as editor
+** `git config --global core.editor 'code --wait --new-window'`
+- vscode as diff tool
+** `git config --global diff.tool vscode`
+** `git config --global difftool.vscode.cmd 'code --wait --diff $LOCAL $REMOTE'`
+
+== Conflicts (3) - Setup VSCode
+
+- vscode as merge tool
+** `git config --global merge.tool vscode`
+** `git config --global mergetool.vscode.cmd 'code --wait $MERGED'`
+- `git config merge.conflictstyle diff3`
+- `git config mergetool.prompt false`
+
+== Conflicts (4) - Solving
+
+- `git mergetool`
+- solve the conflict in the editor
+- `git commit -m "message"`
+- `git clean` remove file (might remove other untracked files)
+
+ 
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Dealing with interruptions 
+ 
+== Git stash command
+
+- put changes away temporarily
+- https://git-scm.com/docs/git-stash
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/10-integration.adoc

+= Integration Testing 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Integration Testing  
+:LECTURE_NO: 10th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2024 - {LECTURE_NO}
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Administrative issues
+- Integration Testing 
+- Preparing Software Releases
+- Summary
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+
+== Approaching Deadlines
+
+- Torsdag, 14. november / 23:59 
+** 3rd group deliverable
+
+
+== Remaining Lectures
+
+- 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"]
+== Integration Testing 
+
+ - check if combinations of software units (components) from our system work as expected when put together
+ - complementary to other types of testing 
+ 
+
+== !
+
+image::../images/lecture10/testing-pyramid.png[canvas, size=contain]
+
+
+== !
+
+image::../images/lecture10/itest01.png[canvas, size=contain]
+
+== !
+
+image::../images/lecture10/itest02.png[canvas, size=contain]
+
+== !
+
+image::../images/lecture10/itest03.png[canvas, size=contain]
+
+== !
+
+image::../images/lecture10/itest04.png[canvas, size=contain]
+
+== Approaches 
+
+- Top down
+- Bottom up
+- Hybrid
+- Big bang
+
+== Test doubles
+
+[.smaller-80]
+- **Dummy objects**  - not used beyond fillers of param lists
+- **Fake objects** -  have some working implementation suitable just for testing
+- **Stubs** -  return pre-prepared answers to calls made during the test (limited to test cases)
+- **Drivers** - some implementation to be able to call the units under test
+- **Mocks** -  more advanced then stubs, they do have mechanisms to check if calls are made by spec, can throw exceptions if expectations are not met
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Preparing Software Releases
+
+
+== Software binaries
+
+- trade-offs 
+- dependencies can be included
+- can run offline
+
+
+== jlink
+
+- javafx plugin goal
+- creates a runtime for your app
+
+
+
+== jpackage
+
+- maven plugin
+- creates a distributable package
+- platform dependent
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== demo
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Q & A
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/10-lecture-code-quality.adoc

+= Code quality 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Code quality 
+:LECTURE_NO: 10th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2021 - {LECTURE_NO}
+
+
+[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)
+
+== Automated tests
+
+- decrease the effort for running and re-running tests
+- there are several types metrics that can be used to measure test coverage
+
+== JaCoCo
+
+- Java Code Coverage (JaCoCo)
+- popular tool for measuring code coverage in Java projects
+- measures several metrics  
+
+== 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
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/10-unit-testing.adoc

+= Unit testing 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Unit testing 
+:LECTURE_NO: 10th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2020 - {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   
+
+|===
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Testing in simpleexample1
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Testing in todo-list example
+
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/11-code-quality.adoc

+= Code quality 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Code quality 
+:LECTURE_NO: 11th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2020 - {LECTURE_NO}
+
+
+[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)
+
+
+== 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
+
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/11-lecture-git-gitlab.adoc

+= Git and GitLab 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Git and GitLab 
+:LECTURE_NO: 11th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2021 - {LECTURE_NO}
+
+[.smaller-80]
+== Overview
+- Git
+** basic workflow recap
+** working with branches
+** code review
+- GitLab
+** Issues
+** Milestones
+** Merge requests
+** Issues / MR Templates
+
+== Basic workflow
+
+- work on main branch (master)
+- could be usable for individual / very small teams 
+- prone to conflicts 
+
+[.grid-left-right-50-50]
+== Typical sequence (basic)
+
+[.area-left]
+- working with a shared project
+** `git clone`
+** `git pull`
+
+[.area-right]
+** `git status` 
+** `git add ...`
+** `git commit ...`
+** `git push`
+
+== Conflicts (1)
+
+** when same files (lines) are changed by different devs
+** automatic merge is not possible 
+** we need to solve that to be able to push our changes 
+
+== Conflicts (2) - Setup
+
+- `git config merge.tool vimdiff`
+- `git config merge.conflictstyle diff3`
+- `git config mergetool.prompt false`
+
+== Conflicts (3) - Solving
+
+- `git mergetool`
+- `:wqa` save and exit from vi
+- `git commit -m "message"`
+- `git clean` remove files (might remove other untracked files)
+
+== Conflicts (4)
+
+- one can plan ahead what issues should be worked on in parallel to minimize the chance of conflicts
+- when working on a feature branch, keeping up to date with relevant branches (master or other branch we depend upon) can reduce the risk of getting conflicts
+
+
+== Improved workflow 
+
+- keep master only for finished work
+- uses branches for development work
+- when a feature branch is done it is merged into master
+
+[.grid-left-right-50-50]
+== Typical sequence (branches)
+
+[.area-left]
+** `git clone`
+** `git pull` 
+** `git checkout -b <branch_name>` 
+
+[.area-right]
+** `git status` + `git add ...` + `git commit ...` 
+** `git checkout master` 
+** `git merge <branch_name>` 
+** `git push`
+
+
+== Improved workflow (code review) 
+
+- keep master only for finished work
+- uses branches for development work
+- when a feature branch is done a merge request is created
+- code review takes place and more commits happen to address the comments
+- the branch is finally merged into master 
+
+== Gitlab specific push options
+
+- push options
+
+```bash 
+-o merge_request.create 
+-o merge_request.target=my-target-branch 
+-o merge_request.label="Label with spaces"
+```
+
+== Advanced workflow (git flow)
+- https://nvie.com/posts/a-successful-git-branching-model/
+- uses 2 long lived main branches - `master` and `develop`
+- shorter lived branches for `features`, `releases` and `hotfixes`
+
+== Trunk-based development
+- does not use shared long lived branches
+- commits go to trunk (main / master) branch
+- https://trunkbaseddevelopment.com
+
+== 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/11-solid-uml.adoc

+= Object oriented design principles 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: OOP SOLID + UML 
+:LECTURE_NO: 11th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2023 - {LECTURE_NO}
+
+
+[.smaller-30]
+Partially based on slides from Torgeir Dingsøyr and Hallvard Trætteberg
+
+
+== Overview
+
+- OOD -  SOLID, DRY
+- Some useful considerations
+- UML Diagrams
+- Summary
+
+[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"]
+== Summary
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/12-modular.adoc

+= Modular software 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Modular software 
+:LECTURE_NO: 12th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2021 - {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/13-lecture-commit.adoc

+= Planning development tasks and commit strategies
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: planning dev + committing
+:LECTURE_NO: 13th lecture
+
+include::{includedir}header.adoc[]
+
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2022 - {LECTURE_NO}
+
+
+== Overview
+
+- Planning development tasks (issues, branches and commits)
+- Committing strategies and best practices
+- Commit messages
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Planning development tasks
+
+- workflow and conventions
+- prevent conflicts and complicated merges
+- run checks before sharing changes		
+
+
+== Workflow and conventions
+
+- agree on workflow and conventions the team is using 
+- have that documented and available in your repository
+** branching strategies
+** branch naming
+** commit message format
+** issue templates
+** MR templates
+** use of labels and boards in gitlab
+
+== Improved workflow (code review) 
+
+- keep master only for finished work
+- uses branches for development work
+- when a feature branch is done a merge request is created
+- code review takes place and more commits happen to address the comments
+- the branch is finally merged into master 
+
+== Gitlab specific push options
+
+- push options
+
+```bash 
+-o merge_request.create 
+-o merge_request.target=my-target-branch 
+-o merge_request.label="Label with spaces"
+```
+
+== Prevent conflicts and complicated merges
+
+- avoid work in different branches with tightly related issues
+- avoid starting in parallel (with different devs) issues that change the same files
+- commit often, small commits that are focused
+- keep up with the main branch in longer lived branches
+
+== Test and check before sharing changes
+
+before pushing (especially to long lived branches like main/master)
+
+- make sure everything builds and runs 
+- verify that the code passes all tests and quality checks 
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Committing strategies and best practices
+
+- small commits dealing with a single topic
+- stage just the changes that are relevant
+- you can stage just part of the changes to a file to include in a commit
+
+== Staging a part of a file changes
+
+- `git add --patch <filename>` 
+- `git add -p <filename>`
+- file is not tracked yet use
+** `git add --intent-to-add <filename>` 
+** `git add -N <filename>`
+- git groups changes into "hunks" and one can select what to include in the next commit
+
+== Staging file parts options (1)
+
+- *y* stage this hunk for the next commit
+- *n* do not stage this hunk for the next commit
+- *q* quit; do not stage this hunk or any of the remaining hunks
+- *a* stage this hunk and all later hunks in the file
+- *d* do not stage this hunk or any of the later hunks in the file
+- *g* select a hunk to go to
+- */* search for a hunk matching the given regex
+
+== Staging file parts options (2)
+
+[.smaller-80]
+- *j* leave this hunk undecided, see next undecided hunk
+- *J* leave this hunk undecided, see next hunk
+- *k* leave this hunk undecided, see previous undecided hunk
+- *K* leave this hunk undecided, see previous hunk
+- *s* split the current hunk into smaller hunks
+- *e* manually edit the current hunk (replace *+* or *-* with *#*)
+- *?* print hunk help
+
+== Things to avoid while committing
+
+- Blending functional and non-functional changes
+- Mixing functional changes that are not related
+- Packing a large change in a single over-sized commit
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Demo
+	
+	
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Commit messages
+
+- common conventions (title, body, footer)
+- conventional commits format
+- what to write in the commit message
+- enforcing commit message format
+- commit hooks  
+
+
+== Commit messages (2)
+
+image::../images/git_commit_2x.png[size=75%]
+[.smaller-40]
+https://xkcd.com/1296/
+
+== Commit messages (seriously)
+
+- Separate subject from body with a blank line
+- Limit the subject line to 50 characters
+- Capitalize the subject line
+- Do not end the subject line with a period
+- Use the imperative mood in the subject line
+- Wrap the body at 72 characters
+- Use the body to explain what and why vs. how
+
+== 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  
+
+== What to write in the commit message (2)
+
+Finally, read the message before committing as it might reveal that you should split it in smaller commits
+
+== Enforcing commit message format
+
+- use tools such as commitlint and commitizen to check the messages
+- use git hooks check the message format
+- use *Conventional Commits* vscode extension
+
+=== Install Commitizen
+
+- `npm install -g commitizen`
+- `npm install -g cz-conventional-changelog`
+- `echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc`
+
+=== Install Commitlint
+
+- `npm install -g @commitlint/cli @commitlint/config-conventional`
+- `echo "module.exports = {extends: ['@commitlint/config-conventional']}" > ~/commitlint.config.js`
+
+== Commit hooks  
+
+- scripts that run at specific times when running git command
+- can be global (all repositories) or local (the repo they are in)
+- can be used to enforce commit message format
+
+=== git hook example
+
+```bash
+
+#!/bin/bash
+
+echo "Checking commit message: "
+
+# run any local commit-msg hook first
+if test -f ./.git/hooks/commit-msg; then
+	echo "Running local git hook first."
+    sh ./.git/hooks/commit-msg
+else
+	echo "Local hook does not exist."
+fi
+
+commitlint < $1
+
+exit $status
+
+```
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Demo
+
+
+== References
+
+- https://eidson.info/post/using-conventional-commit-messages-globally
+- https://wiki.openstack.org/wiki/GitCommitMessages
+
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/13-solid-uml.adoc

+= Object oriented design principles 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: OOP SOLID + UML 
+:LECTURE_NO: 12th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2020 - {LECTURE_NO}
+
+
+
+[.smaller-30]
+Partially based on slides from Torgeir Dingsøyr and Hallvard Trætteberg
+
+
+== Overview
+- OOD -  SOLID, DRY
+- UML Diagrams
+
+[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
+
+- Encapsulation
+- Abstraction
+- Inheritance
+- Polymorphism
+
+
+== 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.
+
+
+[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."
+
+[.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"]
+== UML
+
+[.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"]
+== Summary
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/14-git-gitlab.adoc

+= Git and GitLab 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Git and GitLab 
+:LECTURE_NO: 14th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2020 - {LECTURE_NO}
+
+[.smaller-80]
+== Overview
+- Git
+** basic workflow recap
+** working with branches
+** code review
+- GitLab
+** Issues
+** Milestones
+** Merge requests
+** Issues / MR Templates
+
+== Basic workflow
+
+- work on main branch (master)
+- could be usable for individual / very small teams 
+- prone to conflicts 
+
+[.grid-left-right-50-50]
+== Typical sequence (basic)
+
+[.area-left]
+- working with a shared project
+** `git clone`
+** `git pull`
+
+[.area-right]
+** `git status` 
+** `git add ...`
+** `git commit ...`
+** `git push`
+
+== Conflicts (1)
+
+** when same files (lines) are changed by different devs
+** automatic merge is not possible 
+** we need to solve that to be able to push our changes 
+
+== Conflicts (2) - Setup
+
+- `git config merge.tool vimdiff`
+- `git config merge.conflictstyle diff3`
+- `git config mergetool.prompt false`
+
+== Conflicts (3) - Solving
+
+- `git mergetool`
+- `:wqa` save and exit from vi
+- `git commit -m "message"`
+- `git clean` remove file (might remove other untracked files)
+
+== Conflicts (4)
+
+- one can plan ahead what issues should be worked on in parralel to minimize the chance of conflicts
+- when working on a feature branch, keeping up to date with relevant branches (master or other branch we depend upon) can reduce the risk of getting conflicts
+
+
+== Improved workflow 
+
+- keep master only for finished work
+- uses branches for development work
+- when a feature branch is done it is merged into master
+
+[.grid-left-right-50-50]
+== Typical sequence (branches)
+
+[.area-left]
+** `git clone`
+** `git pull` 
+** `git checkout -b <branch_name>` 
+
+[.area-right]
+** `git status` + `git add ...` + `git commit ...` 
+** `git checkout master` 
+** `git merge <branch_name>` 
+** `git push`
+
+
+== Improved workflow (code review) 
+
+- keep master only for finished work
+- uses branches for development work
+- when a feature branch is done a merge request is created
+- code review takes place and more commits happen to address the comments
+- the branch is finally merged into master 
+
+== Gitlab specific push options
+
+- push options
+
+```bash 
+-o merge_request.create 
+-o merge_request.target=my-target-branch 
+-o merge_request.label="Label with spaces"
+```
+
+== Advanced workflow (git flow)
+- https://nvie.com/posts/a-successful-git-branching-model/
+- uses 2 long lived main branches - `master` and `develop`
+- shorter lived branches for `features`, `releases` and `hotfixes`
+
+== 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/15-lecture-commit.adoc

+= Planning development tasks and commit strategies
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: planning dev + committing
+:LECTURE_NO: 15th lecture
+
+include::{includedir}header.adoc[]
+
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2021 - {LECTURE_NO}
+
+
+== Overview
+
+- Planning development tasks (issues, branches and commits)
+- Committing strategies and best practices
+- Commit messages
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Planning development tasks
+
+- workflow and conventions
+- prevent conflicts and complicated merges
+- run checks before sharing changes		
+
+
+== Workflow and conventions
+
+- agree on workflow and conventions the team is using 
+- have that documented and available in your repository
+** branching strategies
+** branch naming
+** commit message format
+** issue templates
+** MR templates
+** use of labels and boards in gitlab
+
+== Prevent conflicts and complicated merges
+
+- avoid work in different branches with tightly related issues
+- avoid starting in parallel (with different devs) issues that change the same files
+- commit often, small commits that are focused
+- keep up with the main branch in longer lived branches
+
+== Test and check before sharing changes
+
+before pushing (especially to long lived branches like main/master)
+
+- make sure everything builds and runs 
+- verify that the code passes all tests and quality checks 
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Committing strategies and best practices
+
+- small commits dealing with a single topic
+- stage just the changes that are relevant
+- you can stage just part of the changes to a file to include in a commit
+
+== Staging a part of a file changes
+
+- `git add --patch <filename>` 
+- `git add -p <filename>`
+- file is not tracked yet use
+** `git add --intent-to-add <filename>` 
+** `git add -N <filename>`
+- git groups changes into "hunks" and one can select what to include in the next commit
+
+== Staging file parts options (1)
+
+- *y* stage this hunk for the next commit
+- *n* do not stage this hunk for the next commit
+- *q* quit; do not stage this hunk or any of the remaining hunks
+- *a* stage this hunk and all later hunks in the file
+- *d* do not stage this hunk or any of the later hunks in the file
+- *g* select a hunk to go to
+- */* search for a hunk matching the given regex
+
+== Staging file parts options (2)
+
+[.smaller-80]
+- *j* leave this hunk undecided, see next undecided hunk
+- *J* leave this hunk undecided, see next hunk
+- *k* leave this hunk undecided, see previous undecided hunk
+- *K* leave this hunk undecided, see previous hunk
+- *s* split the current hunk into smaller hunks
+- *e* manually edit the current hunk (replace *+* or *-* with *#*)
+- *?* print hunk help
+
+== Things to avoid while committing
+
+- Blending functional and non-functional changes
+- Mixing functional changes that are not related
+- Packing a large change in a single over-sized commit
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Demo
+	
+	
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Commit messages
+
+- common conventions (title, body, footer)
+- conventional commits format
+- what to write in the commit message
+- enforcing commit message format
+- commit hooks  
+
+
+== Commit messages (2)
+
+image::../images/git_commit_2x.png[size=75%]
+[.smaller-40]
+https://xkcd.com/1296/
+
+== Commit messages (seriously)
+
+- Separate subject from body with a blank line
+- Limit the subject line to 50 characters
+- Capitalize the subject line
+- Do not end the subject line with a period
+- Use the imperative mood in the subject line
+- Wrap the body at 72 characters
+- Use the body to explain what and why vs. how
+
+== 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
+
+== Enforcing commit message format
+
+- use tools such as commitlint and commitizen to check the messages
+- use git hooks check the message format
+
+== Install Commitizen
+
+- `npm install -g commitizen`
+- `npm install -g cz-conventional-changelog`
+- `echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc`
+
+== Install Commitlint
+
+- `npm install -g @commitlint/cli @commitlint/config-conventional`
+- `echo "module.exports = {extends: ['@commitlint/config-conventional']}" > ~/commitlint.config.js`
+
+== Commit hooks  
+
+- scripts that run at specific times when running git command
+- can be global (all repositories) or local (the repo they are in)
+- can be used to enforce commit message format
+
+== git hook example
+
+```bash
+
+#!/bin/bash
+
+echo "Checking commit message: "
+
+# run any local commit-msg hook first
+if test -f ./.git/hooks/commit-msg; then
+	echo "Running local git hook first."
+    sh ./.git/hooks/commit-msg
+else
+	echo "Local hook does not exist."
+fi
+
+commitlint < $1
+
+exit $status
+
+```
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Demo
+
+
+== References
+
+- https://eidson.info/post/using-conventional-commit-messages-globally
+- https://wiki.openstack.org/wiki/GitCommitMessages
+
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/17-rest-api.adoc

+= REST APIs 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: REST APIs 
+:LECTURE_NO: 17th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2020 - {LECTURE_NO}
+
+[.smaller-80]
+== Overview
+
+- REST APIs
+** HTTP requests
+** Methods
+** APIs
+** REST Recap
+
+
+
+== 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
+
+[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
+- set of exposed web resources
+- standard HTTP methods (e.g., GET, POST, PUT, PATCH and DELETE);
+- data formats for requests and responses (json, xml, etc)
+
+== !
+
+image::../images/lecture12/rtodo.png[canvas, size=contain]
+
+== 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"]
+== Summary
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/18-lecture-integration-testing.adoc

+= Integration testing 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Integration testing 
+:LECTURE_NO: 18th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2021 - {LECTURE_NO}
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Testing
+
+- 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 principles
+
+- testing shows presence of defects (not their absence)
+- testing all possibilities is not feasible
+- testing should be started as early as possible
+- testing depends on the context
+
+== Levels of testing
+
+- Unit testing
+- *Integration testing*
+- System testing
+- Deployment testing
+
+
+== Unit testing
+
+- units are the smallest testable parts of our system (methods, classes)
+- unit tests are concerned with testing the unit in isolation
+
+== Integration testing
+
+- integration testing aims at testing several units / components 
+- the size and complexity of such a test is on a spectrum and can be from just integrating 2 units to integrating nearly all components in the system
+
+== System testing
+
+- testing the complete system as whole
+- it can be considered a fully integrated test as it integrates all the components within the said system
+- checks if the system is compliant with the specified requirements
+
+== Deployment testing
+
+- tests the complete system as it would be for actual use
+- complete system should comply with the requirements in the clients' environment
+
+== !
+
+image::../images/lecture18/test-pyramid.png[canvas, size=contain]
+
+== Testing pyramid (2)
+
+- as we go from the bottom towards the top the tests get more complex and resource intensive
+- the pyramid is a useful reminder that we should have many unit tests,  several integration tests and very few system and deployment tests 
+
+== !
+
+image::../images/lecture18/system-units.png[canvas, size=contain]
+
+== ! 
+
+image::../images/lecture18/unit-tests.png[canvas, size=contain]
+
+== ! 
+
+image::../images/lecture18/integration-tests.png[canvas, size=contain]
+
+== Types of integration testing
+
+- "Big Bang" - all of units available are combined together and tested if they work together as intended
+- "Top-Down" - top-down integration allows the team to test the top level units first (stubs)
+- "Bottom-Up" - test the bottom level units first (drivers)
+- "Hybrid" -   a combination of both top-down and bottom-up integration testing
+
+== Isolating parts of the system
+
+[.smaller-80]
+- to be able to reliably and automatically test parts of the system we need to isolate them
+- the parts need to have a clear contract (the interface used to interact and communicate)
+- when parts of the system that the unit / component we want to test depends upon are not implemented these need to be simulated
+- a simulated component is usually referred to as a mock, stub or fake  
+- when the simulated component is using / calling the tested component it is called a driver
+  
+== ! 
+
+image::../images/lecture18/mocked-server.png[canvas, size=contain]
+
+
+== ! 
+
+image::../images/lecture18/mocked-client.png[canvas, size=contain]
+
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/19-common-issues.adoc

+= Common issues 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Common issues 
+:LECTURE_NO: 19th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2020 - {LECTURE_NO}
+
+[.smaller-80]
+== Overview
+
+- Planer vs. implementasjon
+- Uheldig programmeringspraksis
+- Testing
+- Sjekk av kodekvalitet
+- Utviklingsoppgaver
+- Merge requests
+- Diverse
+
+== Planer vs. implementasjon
+
+- Litt vel stor forskjell mellom ambisjoner som beskrevet i planer, 
+skjermbildeskisser og faktisk innlevering.
+- Det er lurt å tenke at innlevering 2 og 3 er noe brukere kunne prøvd ut.
+- Mange strekker seg litt langt, på bekostning av kvalitet.
+
+== Uheldig programmeringspraksis
+
+- En del kjernekode er rene data-klasser uten noen særlig logikk, heller ikke validering.
+- Innkapsling brytes ved at interne lister returneres direkte
+- Variabler og felt types til implementasjonsklasser heller enn grensesnitt (ArrayList<> vs. List<>)
+
+[.notes]
+--
+* Innkapsling brytes ved at interne lister returneres direkte. Når slike lister returneres, er det et heller ikke mye vits i å implementere Iterable, fordi den har til hensikt å støtte iterasjon uten tilgang til underliggende liste.
+--
+
+[.smaller-80]
+== Testing
+
+- Testing er ment å øke tilliten til koden
+- Ikke test kode som er like triviell som testen; det er viktigere å teste metoder med logikk
+- Det er ikke vits i å teste toString(), når den kun er ment å bli brukt til debugging
+- En del bruker try/catch og fail() galt når det ikke trengs
+
+[.notes]
+--
+* En del tester av triviell kode, som gettere og settere som kunne vært generert, er helt unødvendige. Det er viktigere å teste metoder med logikk , f.eks. filtrering, oppdatering av data osv.
+* Det er ikke vits i a test toString() når det ikke regnes som api for andre klasser.
+* En del bruker try/catch og fail() galt, det er f.eks. ikke vits i å ha try { ... } catch (Exception e) { fail(); }, for testformål er det bedre å bare la koden kræsje.
+--
+
+[.smaller-80]
+== Sjekk av kodekvalitet
+
+- Mange tar ikke hensyn til checkstyle-anmerkninger, og en del har ikke engang koblet det inn.
+- Noen prøver å lure spotbugs...  
+```java
+    // We need to implement this to make spotbugs shut up.
+    // Technically, we are supposed to make equals and compareTo
+    // agree, but we specifically want events to be sorted
+    // chronologically. The right way is probably to implement
+    // a comparator instead of overriding compareTo, and sorting
+    // with that.
+    @Override
+    @Deprecated
+    public boolean equals(Object o) {
+        // We can check quilcky by comparing pointers
+        if (this == o) {
+            return true;
+        }
+        return false;
+    }
+
+```
+
+== Utviklingsoppgaver
+
+- Mange utviklingsoppgaver mangler detaljer og/eller diskusjoner
+- Noen knytter ikke oppgaver til "assignee" og/eller milepæler
+- Verktøyene er ment å hjelpe på samarbeidet og brukes ikke bare for syns skyld
+
+== Merge forespørsler
+
+- noen grupper bruker merge forespørsler jevnlig, og det er bra!
+- men det er få kommentarer eller diskusjoner for forbedring av koden...
+
+[.smaller-80]
+== Diverse
+
+- For mange er opptatt av registrering/innlogging
+- Oppdeling i flere kontrollere kan være vanskelig å gjøre ryddig
+- Ikke bruk toString() til visning i UI-et
+- Mange legger til filer i repoet som burde vært ignorert (i .gitignore)
+
+[.notes]
+--
+* For mange er opptatt av registrering/innlogging, men det kan ikke sies å være viktig å få feedback på fra brukere, selv om det selvagt vil være nødvendig.
+* Oppdeling i flere kontrollere er ofte riktig, men kan være vanskelig å gjøre ryddig, f.eks. navigering mellom ulike Scene.
+* Ikke bruk toString() til visning i UI-et, selv om det er en billig måte å f.eks. vise elementer i lister. 
+* Many add to the repository files that should be ignored (settings from IDE, files generated by OS, build folders etc) - use .gitignore
+--
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/agiletools.adoc

 = Smidig praksis og verktøy
 :customcss: slides.css
 :icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Agile tools
+:LECTURE_NO: 
+
+include::{includedir}header.adoc[]
+
 
 == Smidig praksis og verktøy
 
@@ -125,3 +131,6 @@ link:scm.html[Source code management (SCM)]
 
 [.center-paragraph]
 link:ci.html[Continuous Integration (CI)]
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/ci.adoc

 = Kontinuerlig integrasjon
 :customcss: slides.css
 :icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Continuous Integration
+:LECTURE_NO: 
 
-== Kontinuerlig integrasjon (CI)
-
-Automatisering av alt som fremmer kvalitet, men som tar tid, f.eks.
-
-* kompilering og bygging av jar-filer (generelt avledete artifakter)
-* kjøring av enhets- og integrasjonstester
-* analyser av ulike typer kvalitet (formatering, kodingsstandarder, vanlige feil, ...)
-* bygging av kjørbart system og kjøring av systemtester
+include::{includedir}header.adoc[]
 
 == Smidig utfordring
 
@@ -25,6 +21,15 @@ Automatisering av alt som fremmer kvalitet, men som tar tid, f.eks.
 ** koden innen teamet - integrasjonstesting
 ** hele systemet - systemtesting (og evt. deployment)
 
+== Kontinuerlig integrasjon (CI)
+
+Automatisering av alt som fremmer kvalitet, men som tar tid, f.eks.
+
+* kompilering og bygging av jar-filer (generelt avledete artifakter)
+* kjøring av enhets- og integrasjonstester
+* analyser av ulike typer kvalitet (formatering, kodingsstandarder, vanlige feil, ...)
+* bygging av kjørbart system og kjøring av systemtester
+
 == Smidig løsning
 
 [.smaller-80]
@@ -49,86 +54,56 @@ Automatisering av alt som fremmer kvalitet, men som tar tid, f.eks.
 == Byggeverktøy forts.
 
 [.smaller-60]
-* to hovedalternativer: *gradle* og *maven*
+* to hovedalternativer for Java er *gradle* og *maven*, andre språk har tilsvarende, f.eks. *yarn* for Javascript og *sbt* for Scala.
 ** litt ulik terminologi og logikk, men forskjellene er tildels overfladiske
 ** begge kan mye det samme, så valget er i stor grad pragmatisk (!)
 ** masse materiale å lære fra, uansett valg
 * *maven*
-** mer modent og strukturert, men også mer krevende og tungvint 
+** mer modent og strukturert, men oppfattes som noe mer krevende og tungvint
+** sekvensierer byggetrinn basert på overordnede _faser_
 * *gradle*
 ** konfigurerbare byggetrinn sekvensieres basert på avhengigheter 
-** konfig.filene (*settings.gradle* og *build.gradle*) er forståelige
 
-== Enkelt prosjektoppsett
+== Maven og pom.xml
 
 [.smaller-60]
-Enkle prosjekter består av én modul og mappe
+* *pom.xml* konfigurerer bygg
+** nødvendige biblioteker for kompilering, kjøring og testing
+** versjon og konfigurasjon av maven-tillegg som trengs i bygget
+** konfigurasjon av kompilering (java-versjon) og kjøring (hovedklasse)
+* standardinnstillingene krever fire mapper for java
+** *src/main/java* inneholder "produktiv" java-kode
+** *src/main/resources* inneholder _ressurser_, f.eks. *fxml*- og *png*-filer
+** *src/test/java* inneholder testkode
+** *src/test/resources* inneholder ressurser spesifikke for testene, f.eks. datafiler
 
-[.smaller-60]
-* *settings.gradle* og *build.gradle* konfigurerer bygg
-* *gradlew*/*gradlew.bat* og *gradle*-mappe må inkluderes
+== https://gitlab.stud.idi.ntnu.no/it1901/javafx-template/-/tree/main/javafx-template[javafx-template]
 
-[.smaller-60]
-Eksempel:
+Eksempel på én-modul-prosjekt i (i https://gitlab.stud.idi.ntnu.no/it1901/javafx-template[javafx-template-kodelageret])
 
 [.smaller-60]
-* desktop-app med javafx og fxml
-* ikke noe behov for gjenbruk av kjernelogikk i andre prosjekter
-
-== simpleexample
-
-[.smaller]
 [.left-60]
-* eksempel på én-modul-prosjekt
-** javafx+fxml-app
-** standard mapper for java
-** gradle-filer
+* avhengigheter til biblioteker for javafx og jupiter (testing)
+* velger spesifikke versjon av en del maven-tillegg
+* Java 16 for kompilering (og kjøring)
+* app.App er hovedklassen for kjøring med maven-tillegget for javafx
 
 [.right]
-image::../images/simpleexample-structure.png[width=300]
+image::../images/javafx-template-structure.png[width=300]
 
-== simpleexample forts.
+== https://gitlab.stud.idi.ntnu.no/it1901/javafx-template/-/tree/main/modules-template[modules-template]
 
-[.smaller]
-* standard innhold i *build.gradle*
-** plugins - tillegg som passer til typen prosjekt, f.eks. 
-** repositories - hvor finnes tillegg og bibliotek (jar-filer)
-** dependencies - hvilke bibliotek brukes og til hva/når
-* tillegg-spesifikk konfigurasjon, f.eks.
-** oppstartsklasse for java
-** javafx-versjon og -moduler som brukes
-
-== simpleexample forts.
-
-* build.gradle *plugins*
-** application - java-app med main-metode, som kan pakkes som kjørbar jar
-** org.openjfx.javafxplugin - javafx-app
-
-[source]
-----
-plugins {
-	id 'application'
-	id 'org.openjfx.javafxplugin' version '0.0.8'
-}
-----
-
-== Modulært prosjektoppsett
-
-[.smaller-60]
-_Flermodul_-prosjekter har delmoduler i undermapper
-
-[.smaller-60]
-* *settings.gradle* i hovedmappa navngir hovedprosjektet og delmodulene
-* *gradlew*/*gradlew.bat* og *gradle*-mappe må inkluderes i hovedmappa
-* delmodulene (i undermappene) trenger (bare) egen *build.gradle*-fil
-
-[.smaller-60]
-Eksempel:
+Eksempel på fler-modul-prosjekt
 
 [.smaller-60]
-* klient-tjener-app
-* (noe) felles kjernelogikk i klient og tjener
-* kan ha flere klienter, f.eks. desktop og mobil (og web)
+[.left-60]
+* to undermapper, *core* og *ui*, med hver sin *pom.xml*
+** core har kode (og tester) for domeneklasser
+** ui har GUI-kode med avhengigheter til JavaFX
+** modulspesifikk konfigurasjon er i respektive *pom.xml*-filer
+* *pom.xml* på toppnivå innholder
+** avhengigheter som er felles for (under)modulene
+** konfigurasjon av tillegg som brukes i (under)modulene
 
 == Modularitet
 
@@ -137,20 +112,21 @@ Eksempel:
 ** moduler er relativt selvstendige enheter
 ** eksplisitte avhengigheter mellom moduler
 ** gjenbrukes på tvers av prosjekter
-* tilsvarer i java et sett pakker
+* i Java tilsvarer en modul et sett pakker
 ** skiller mellom API og interne pakker 
 ** distribueres som jar-fil (zip-fil med meta-data)
 
-== multiexample
+== https://gitlab.stud.idi.ntnu.no/it1901/todo-list/-/tree/master/todolist[todo-list]
 
-[.smaller]
+[.smaller-60]
 [.left-60]
 * eksempel på fler-modul-prosjekt
 ** core - kjernelogikk
-** fx - javafx+fxml-app
-** jaxrs - REST API
-** jersey - web-server-app
-** webreact - web-klient
+** fxutil - hjelpekode for fxui
+** fxui - javafx+fxml-app
+** rest - REST API og server
+** integrationtests - integrasjonstester
+** springboot/restserver - alternativ server
 
 == Avhengigheter
 
@@ -169,42 +145,30 @@ image::../images/maven-central.png[width=300, link="https://mvnrepository.com"]
 
 [.smaller-60]
 * avhengigheter er _eksplisitte_
-** deklareres i *build.gradle* i *dependencies*-seksjonen
-** krever (fullt) navn og versjon (major.minor.micro)
+** deklareres i *pom.xml* i *dependencies*-seksjonen
+** krever navn (groupId og artifactId) og versjon (major.minor.micro)
 ** bibliotek må finnes i deklarerte *repositories*
-* _formålet_ angir når avhengigheten brukes
+* *scope* angir anledningen avhengigheten brukes i
 ** *compile* - kompilering (og kjøring) av vanlig kode
 ** *test* - kompilering (og kjøring) av testkode
-** *implementation* - kjøring (men ikke komp.) av vanlig kode
-** *testImplementation* - kjøring (men ikke komp.) av testkode
-
-== IDE-støtte
-
-* importere gradle-konfigurerte prosjekter
-* basere egen konfigurasjon på gradle sin
-** kildekodemapper
-** avhengigheter
-* utføre gradle-oppgaver, f.eks. kjøre tester
+** *runtime* - trengs ved kjøring, men ikke kompilering
+** *provided* - trengs ved kompilering, men ikke ved kjøring (er implisitt med)
 
-== Eclipse-støtte
+== VSCode-støtte
 
 [.smaller-60]
-[.left-60]
-* *New > Project... > Gradle Project*: opprette nytt java-prosjekt, ferdig oppsatt med fornuftig gradle-konfigurasjon
-* *Import... > Existing Gradle Project*
-* *> Gradle > Refresh Gradle Project*: oppdaterer Eclipse sin prosjektkonfigurasjon fra gradle-konfigurasjonen
+* gjenkjenner automatisk mapper med *pom.xml* som maven-prosjekter
+* konfigurerer editorstøtten og innebygget kompilering deretter
 ** kildekodemapper
 ** avhengigheter
-* paneler
-** *Gradle Tasks*
-** *Gradle Executions*
-
-[.right]
-image::../images/gradle-views.png[width=300]
+* ved større endringer av *pom.xml* og/eller mappestrukturen kan en be VSCode oppdatere sin forståelse av oppsettet
+* har tillegg for å utføre bygge-oppgaver, f.eks. kjøre tester, men like greit å bruke terminalen
 
 == CI @ gitlab
 
-* gitlab kan konfigureres til å bygge, når endrer `push`es til et repo
+* gitlab kan konfigureres til å bygge, når endringer overføres til et kodelager
 * *.gitlab-ci.yml* inneholder byggeinstruksjoner
-* hele repoet sjekkes først ut
+* hele kodelageret klones over i en virtuell maskin
 * så utføres byggeinstruksjoner iht. innstillinger
+
+include::{includedir}footer.adoc[]

lectures/revealjs/feedback.adoc

+[%notitle]
+=      
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: 
+:LECTURE_NO: 
+
+include::{includedir}header.adoc[]
+
+[.left]
+Go to: +
+app.one2act.no +
+Session: +
+KIPAT +
+
+[.right]
+image::../images/lecture02/qr-app-one2act-no.svg[width=400]
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file

lectures/revealjs/gitpod.adoc

+= Gitpod
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: Gitpod
+:LECTURE_NO: 
+
+include::{includedir}header.adoc[]
+
+== Problem
+
+Rigging av alt som trengs for utvikling tar mye tid
+
+[.smaller-80]
+* språk og rammeverk, f.eks. python, java, javafx osv.
+* støtteapplikasjoner og byggesystemer, f.eks. git, gradle, mavem, npm,, sbt osv.
+* IDE-er med nødvendige tillegg, f.eks. Eclipse, IntelliJ, VSCode
+* alt skal spille godt sammen, versjoner må være kompatible
+
+Spesielt problematisk for kortvarig bruk, f.eks. øvinger og eksempler
+
+== Gitpod = VSCode + git + Docker
+
+[.smaller-80]
+* VSCode i nettleseren startes opp fra et git-kodelager
+* Arbeidsområdet og oppsettet hentes fra kodelageret
+* Virtuell linux-maskin m/terminal kjører i skyen
+* Støtter alle relevante språk, rammeverk og byggesystemer
+* Kobles til git-skytjeneste som github og gitlab, men kan kjøres innomhus
+
+== Gitpod @ NTNU
+
+[.smaller-80]
+* NTNU har sin egen *gitpod.stud.ntnu.no* koblet mot *gitlab.stud.idi.ntnu.no*
+(*gitpod.io* brukes mot *gitlab.com* eller *github.com*).
+* brukes i IT1901 til
+** https://gitlab.stud.idi.ntnu.no/it1901/javafx-templates[javafx-maler] og -eksempler
+** øvinger i personlig kodelager
+** prosjektet i gruppe-kodelager
+* vil etterhvert også bli brukt i 1. klasse-emner
+
+=== Gitpod-arkitektur
+
+[.stretch]
+image::../images/gitpod-arch.png[width=800]
+
+== Gitpod-scenarier
+
+Dele eksempler
+
+[.smaller-80]
+* Fagstab
+** rigger opp eksempel
+** gir instruksjoner i README
+** publiserer i kodelager og deler lenke
+* Student
+** åpner kodelager i gitpod og jobber videre
+** evt. lagrer i eget kodelager (med *git remote*)
+
+== Gitpod-scenarier
+
+Få veiledning
+
+[.smaller-80]
+* Student (jobber inni gitpod)
+** tar _snapshot_
+** deler snapshot-lenke med fagstab
+* fagstab
+** åpner lenke i gitpod
+** ser gjennom og kommenterer
+
+== Gitpod-scenarier
+
+Eksamen (om ikke så lenge, håper vi)
+
+[.smaller-80]
+* Fagstab
+** forbereder innhold og kontekst for oppgavene
+** rigger opp personlig kodelager for *hver* kandidat
+* Student
+** åpner sitt kodelager og gjør oppgavene
+** besvarelsen lagres kontinuerlig i kodelageret
+* Sensor
+** åpner kodelager-lenke og vurderer besvarelse
+
+== Gitpod i IDI-emner
+
+Støtter mange undervisnings-scenarier
+
+* kode- og prosjekteksempler
+* øvinger og småskala prosjekter
+* alle relevante språk og rammeverk, spesielt web-utvikling
+* vanlig git-arbeidsflyt
+* deling av nå-tilstand vha. _snapshots_
+
+include::{includedir}footer.adoc[]