Skip to content
Snippets Groups Projects
Commit bdfa1b82 authored by George Adrian Stoica's avatar George Adrian Stoica
Browse files

doc: updates for lectures 4, 5 and 6

parent 5a65f911
No related branches found
No related tags found
No related merge requests found
Pipeline #185144 passed
= Scrum / Gitlab
:customcss: slides.css
:icons: font
:includedir: includes/
:LECTURE_TOPIC: Scrum / Gitlab
:LECTURE_NO: 4th lecture
include::{includedir}header.adoc[]
[.smaller-80][.center-paragraph]
IT1901 Fall 2022 - {LECTURE_NO}
== Overview
- Administrative issues
- Group contract
- Scrum
- Gitlab
[background-color = "#124990"]
[color = "#fff6d5"]
== Administrative issues
== Administrative issues
- Reference group
- Groups
- Getting help
- Upcoming deliverables
== Reference group (1)
- Special thanks to the reference group volunteers for their interest in the course.
- we selected a representative mix in the order of volunteering
- you can see the contact info in Blackboard
- questions regarding the course organization and proposals for improvements should be communicated to the reference group
- half of the reference group has been randomly selected to have a balanced set of representatives
== Reference group (2)
- vebjorbl@stud.ntnu.no Vebjørn Falk Blom-Hagen
- hanneswi@stud.ntnu.no Hannes Witt
- johanlm@stud.ntnu.no Johannes Landmark Meldal
- adelefe@stud.ntnu.no Adele Felicia Ellingsen-Grønningsæther
- olejme@stud.ntnu.no Ole Jacob Mellgren
- elintes@stud.ntnu.no Elin Tesaker
== Groups
- groups have been formed based on the form and input from students
- will be uploaded in BlackBoard tomorrow
- for issues with groups contact Farzana Quayyum <farzana.quayyum@ntnu.no>
- several of the enrolled students have not been distributed to groups
- we will proceed to create the gitlab groups with the same composition as the Blackboard groups ASAP
== Getting help
- Use piazza instead of sending individual emails to staff
- technical help-desk will be shortly operating
- A TA will be assigned to each group
** subject matter and group related questions should be addressed to them
== Upcoming deliverables (1)
- 1st individual assignment
- deadline on this Thursday at midnight
- not all requested access for 1st individual assignment
- this is a mandatory exercise, you cannot get a grade in the course if you do not pass it
== Upcoming deliverables (2)
- group contract
- deadline one week from announcing the groups
[background-color = "#124990"]
[color = "#fff6d5"]
== Group contract
== Group contract (0)
- contact the other members of your group
- start working on the group contract
== Group contract (1)
- Minimum requirements for agreement:
** Presence
** Time spent
** Expectations for the individual contribution
** What happens in the event of deviations or disagreements
== Group contract (2)
* must be approved by the TA for the group
* signed by all group members
* and delivered this Friday by 16:00
== Group contract (3)
- more recommended items:
** handling differences in motivation level and ambition
** what quality is expected, how defines the group something to be "done"
** distribution of time between meetings / group work / individual work
** what happens if course work needs more time than expected
== Group contract (4)
- more recommended items:
** delays, sickness, absence - how does the group handle these
** meeting routines both for physical and virtual (agreement for time, agenda, meeting minutes etc)
** general communication tools (email, phone, im etc) and response time
** dealing as a group with deliverables and deadlines
== Group contract (5)
- more recommended items:
** roles
** giving feedback to the others
** dealing with conflicts and disagreements
** dealing with breach of contract
** procedure to follow if the group is not able to solve conflicts / disagreements internally
[background-color = "#124990"]
[color = "#fff6d5"]
== Scrum
== About domain selection
- choose an app / service that you know well and select a couple of features to implement during the semester
- point is to learn by implementing these using the required architectures
- we are not looking for quantity but for quality, so just few core features will suffice
== About domain selection (2)
- the chosen app needs to be suitable for a cloud based service
- there must therefore be some dynamic data per user managed by the server.
- eg. a (currency) calculation will NOT fit such a project.
- one good starting point are the cases from the HCI course (MMI)
== User stories
[.smaller-80]
- short, simple descriptions for application features
- formulated from the stand point of the user / customer
- template:
** As a **< type of user >**, I want **< some goal >** so that **< some reason >**.
- they are not replacing design documents / requirements specification
- they need to be developed into specific tasks and connected to constraints and other meaningful documentation.
== Sprints
- meaningful iterations of comparable length
- they should have a clear goal
== Planning releases
- 3 deliverables - map to releases
- a release should produce a minimum viable product (MVP)
** a MVP is a version of an application with just enough features to be usable in getting feedback to guide the development process
== Meetings
- regular stand-up meetings (synchronize and commit, remove hindrances)
- retrospectives (reflect on your group work)
- sprint reviews / demos (invite TA, prepare deliverables)
== Pair programming
- popular agile development technique
- recommended to be used in your groups
[background-color = "#124990"]
[color = "#fff6d5"]
== Gitlab
== Gitlab -Issue tracking
- Issues
- Labels
- Milestones
- Boards
[background-color = "#124990"]
[color = "#fff6d5"]
== Gitlab demo
include::{includedir}footer.adoc[]
= GitLab
:customcss: slides.css
:icons: font
:includedir: includes/
:LECTURE_TOPIC: GitLab
:LECTURE_NO: 5th lecture
include::{includedir}header.adoc[]
[.smaller-80][.center-paragraph]
IT1901 Fall 2022 - {LECTURE_NO}
== Overview
- Administrative issues
- Gitlab
[background-color = "#124990"]
[color = "#fff6d5"]
== Administrative issues
== Administrative issues (Groups)
- Groups have been assigned a TA
- we have created the groups in gitlab
- we have added the members to each group
- the initial repositories for group exercises have been created
- check if all in the group can access the repository
- standard repository gr22nn/gr22nn
== Administrative issues (Tech support)
- Technichal support is operational
- Link and info will be published in BlackBoard
== Reference group (updated)
- vebjorbl@stud.ntnu.no Vebjørn Falk Blom-Hagen (Informatikk)
- hanneswi@stud.ntnu.no Hannes Witt (Informatikk)
- johanlm@stud.ntnu.no Johannes Landmark Meldal (Informatikk)
- jakobto@stud.ntnu.no Jakob Tøssebro (Datateknologi)
- olejme@stud.ntnu.no Ole Jacob Mellgren (Datateknologi)
- elintes@stud.ntnu.no Elin Tesaker (Lektorutdanning i realfag)
== Nearing Deadlines
- First individual assignment
** postponed to next week (Tuesday 13.09.2022 23:59)
** there will be a possibility to resend after the first round of feedback
- Group contract (Tuesday 13.09.2022 23:59)
- First group assignment (Thursday 22.09.2022 23:59)
== Start group work
- finish and deliver the group contract
- discuss and select domain / aplication for group project
- discuss and agree on workflow, meetings etc
- set up your gitlab workspace and repository
- plan the sprint / iteration for the first deliverable
== About domain selection
- choose an app / service that you know well and select a couple of features to implement during the semester
- point is to learn by implementing these using the required architectures
- we are not looking for quantity but for quality, so just few core features will suffice
== About domain selection (2)
- the chosen app needs to be suitable for a cloud based service
- there must therefore be some dynamic data per user managed by the server.
- eg. a (currency) calculation will NOT fit such a project.
- one good starting point are the cases from the HCI course (MMI)
== 3 release plan
- Minimal application
- Application with more features / improved quality
- Final technical – client server / REST API / more features / alternative client
== Application description
- General description included in readme.md file
- user stories supported by additional design documents such as:
** conceptual model,
** personas,
** scenarios,
** UI mockups,
** UI protoypes
- User stories get broken down into issues and tasks
- Lead to a functional application
[background-color = "#124990"]
[color = "#fff6d5"]
== GitLab
== GitLab
* Issues
* Milestones
* Task lists
* Labels
* Boards
* Quick actions
include::{includedir}footer.adoc[]
= 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
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment