programmering av en enkel app, bruk av gradle til bygging, og git og gitlab til kodehåndtering
Krav til innleveringen:
- Kodingsprosjektet skal ligge i repoet på gitlab
- Prosjektet skal være konfigurert til å bygge med gradle
=== Deliverable 1
- En README.md-fil på rotnivå i repoet skal beskrive repo-innholdet, spesielt hvilken mappe inni repoet som utgjør kodingsprosjektet.
- En README.md-fil (evt. en fil som README.md lenker til) inni prosjektet skal beskrive hva appen handler om og er ment å gjøre (når den er mer eller mindre ferdig). Ha med et illustrerende skjermbilde, så det er lettere å forstå. Det må også være minst én brukerhistorie for funksjonaliteten dere starter med.
=== Deliverable 1
- Det må ligge inne (i gitlab) utviklingsoppgaver (issues) tilsvarende brukerhistorien, hvor hver utviklingsoppgave må være egnet til å utføres som en egen enhet. De som er påbegynt må være tilordnet det gruppemedlemmet som har ansvaret.
=== Deliverable 1
- Vi stiller ikke krav om at dere er kommet så langt, men det må i hvert fall være noe i hvert av de tre arkitekturlagene, domenelogikk, brukergrensesnitt (JavaFX-GUI) og persistens (fillagring, men ikke nødvendigvis JSON), slik at appen kan kjøres og vise frem "noe". For at det skal være overkommelig, er det viktig at domenet er veldig enkelt i første omgang. Det er viktigere at det som er kodet er ordentlig gjort. Koden som er sjekket inn bør være knyttet til tilsvarende utviklingsoppgave.
=== Deliverable 1
- Gradle skal være konfigurert så en kan kjøre app-en vha. gradle-oppgaven run.
- Det må finnes minst én test som kan kjøres med gradle. Bygget skal være rigget til å rapportere testdekningsgrad, som derfor skal være over 0%.
- Bruk simpleexample-prosjektet som inspirasjon, men ikke kopier kode direkte.
== What is the biggest impediment preventing you to move forward with the project?
Write keywords or a short sentence. use "none" if you have no impediments.
[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
