Forelesninger

Fagstaben rigger et kode-eksempel i et prosjektoppsett som lar en kompilere og kjøre (generelt bygge). Prosjektet kan kreve verktøy og rammeverk som studentene ikke (ennå) har installert på egne maskiner. Studentene åpner kodelageret i gitpod og kan umiddelbart prøve det ut, endre på det og lære av det. Dersom en vil ta vare på eksemplet, må en opprette et eget kodelager og lagre (det endrede) innholdet der vha. git remote og git push.

Studenten jobber med et prosjekt i et kodelager og trenger veiledning og sender lenke til en læringsassistent, som kan åpne gitpod og jobbe i samme oppsett som studenten. Hvis læringsassistenten har rettigheter til kodelageret (f.eks. fordi det ligger i en gitlab-gruppe satt opp av fagstaben), så kan hen legge tilbake endringer evt. lage et endringsforslag.

En annen mulighet er å ta et såkalt øyeblikksbilde (snapshot) som lagrer innholdet i arbeidsområdet og knytter det til en lenke. Læringsassistenten kan åpne denne lenka i gitpod og får samme innhold i sin gitpod som studenten hadde da øyeblikksbildet ble tatt. Fordelen er at en får delt innhold som det ikke naturlig å dele vha. selve kodelageret, f.eks. byggeresultater.

Fagstaben i et emne lager en gitlab-gruppe for emnet og semesteret, f.eks. tdt4100/v2022 og inni denne opprettes et gitpodifisert kodelager for hver student som både fagstaben og studenten har tilgang til. Hver uke publiseres nye øvingsoppgaver (tekster, startpakke med kode og evt. tester) som kopieres inn i hvert slikt kodelager, slik at studentene kan jobbe med dem og (implisitt) levere i sitt eget emne-kodelager.

Eksamen kan rigges omtrent som et øvingsopplegg, med et personlig kodelager pr. student, med både oppgave og (etterhvert) besvarelse i.

Hvis en skal jobbe videre med et kodelager som eies av andre, så må en lage en kopi (med eller uten kobling til originalen, med kobling så kalles det gjerne en "gaffel"). En oppretter da et nytt kodelager på gitlab f.eks. på egen bruker eller under en emne-gruppe. Navigér til egen bruker eller gruppa og velge New project under +-menyen øverst.

Lag et tomt/blankt kodelager uten README, fordi hele innholdet skal overføres fra originalen. Hvert kodelager har sin egen adresse som brukes av git. Velg Clone-nedtrekksmenyen og kopier HTTPS-adressen (se under). Den skal brukes i en git-kommando for oppsett av git inni gitpod.

For å knytte kodelageret inni gitpod til det nye kodelageret på gitlab, skriv inn git remote set-url origin etterfulgt av kodelager-adressen fra forrige steg. Dermed vil alle kommandoer som opererer på git-tjeneren (en såkalt remote)gå mot det nye kodelageret. Kommandoen git push -u origin master brukes først for å overføre alt git-innhold m/historikk til det nye kodelageret sin master-grein, og siden kan en bare bruke git push for å oppdatere, evt. git pull for å hente ned endringer fra tjeneren.

Dersom en vil beholde knytningen til original-kodelageret, så endrer en først navnet på den opprinnelige kobling til f.eks. upstream med git remote rename origin upstream. Så opprettes det en ny kobling til det nye kodelageret med git remote add origin etterfulgt av kodelager-adressen fra forrige steg. Da vil vanlig bruk av git push og git pull gå mot det nye kodelageret, men en kan hente ned endringer fra original-kodelageret med git fetch upstream og innlemme dem med git merge upstream/master (og være beredt til å håndtere konflikter).

Dette er i grunnen det enkleste. En bruker samme skjema som over, men velger å lage en README med det samme (om en glemmer det, så kan en lage en README på nettsiden til det nye kodelageret), og etter at kodelageret er opprettet, så åpner man bare gitpod på det nye kodelageret. Merk at selv om en kan åpne gitpod, så er ikke kodelageret automatisk gitpodifisert. Det gjør en ved å opprette .gitpod.yml og evt. en docker-fil med passende innhold, overføre disse tilbake med git push. For at det nye gitpod-oppsettet skal få effekt må en starte gitpod på nytt fra nettsida til kodelageret.

Dersom du sitter med et kodelager lokalt på maskina di (som ikke finnes på gitlab), så kan det åpnes i gitpod ved å først overføre det til et kodelager på gitlab, for så å åpne det i gitpod. Prosessen blir litt som den første varianten over, en oppretter et kodelager på gitlab og angir så at det lokale kodelageret skal knyttes til det nye på gitlab (som en remote). Skriv inn git remote add origin etterfulgt av kodelager-adressen for det nye kodelageret (tilsvarende varianten over). Dette gjøres selvsagt i terminalen lokalt, evt. inni terminal-panelet i VSCode lokalt.

Til slutt åpnes det nye kodelageret på gitlab i gitpod.

Testing (ved kjøring av kode) foregår gjerne på flere nivåer. Enhetstesting tester mindre kodeenheter som klasser og metoder isolert fra faktisk bruk i et stor program. Målet er ofte å sjekke korrekthet ved all mulig bruk. Integrasjonstester tester flere moduler og sub-systemer sammen, mer basert på hvordan de er ment å samhandle (bruke hverandre). En tester mer ut fra faktisk bruk, enn all mulig bruk, slik at mengden tester (mulighetsrommet) begrenses. Systemtester sjekker at totalsystemet virker som forventet slik det skal kjøre i virkeligheten. En tar gjerne utgangspunkt i bruksscenarier som er identifiser ved design av systemet, slik at bruken blir realistisk. Samtidig skal en jo også sjekke at systemet virker ved unormal og gal bruk, siden det også er realistisk. Noen tester er såkalte ende til ende-tester, hvor en simulerer konkret brukerinteraksjon gjennom et UI og ser at alt går rett for seg, f.eks. at databaser oppdateres som de skal og at responsen i UI-et er riktig.

En snakker gjerne om dette som en testpyramide, fordi mengden tester fra lavere til høyere nivå gjerne går ned fordi det blir uoverkommelig å teste alle mulighetene. Uansett ønsker en å vite at koden som helhet er godt gjennomtestet, altså har høy testdekningsgrad (test coverage). Uavhengig av antall tester er måten en rigger dem på forskjellig. Uten støtte fra testrammeverk og automatisering, vil kontinuerlig testing være ressurskrevende å gjennomføre i praksis.

Ved siden av at koden virker, så ønsker en også at kvaliteter som sikrer at den er grei å jobbe med over tid, f.eks. at den er lett å få oversikt over, lese og forstå og modifisere for ulike formål. Dette er kvaliteter som kan sikres ved gjennomlesning, men det er også tidkrevende, og i det er mye å hente om en kan automatisere (deler av) det også, f.eks. sjekke av visse standarder for formatering og koding er fulgt.

Med mindre noe annet er konfigurert, krever maven sine standardinnstillinger fire mapper for java (hvis mappen trengs, da):

I utklippet til høyre ser vi at mappene src/main/java, src/main/resources og src/test/java er i bruk, og hver av disse har en app-mappe som tilsvarer java-pakken app.

Fila pom.xml brukes for å konfigurere bygging med maven og en mappe med en slik fil forteller at mappa inneholder et prosjekt satt opp for å bli bygget med maven. Dersom man står i en slik mappe så kan mvn-kommandoen bruke for å utføre ulike byggeoppgaver.

Pom-fila (kortform for pom.xml-fila) inneholder ulike xml-blokker med diverse informasjon som styrer byggeoppgavene, f.eks:

Eksemplene under finner du i javafx-template-prosjektet på gitlab. I første omgang tar vi utgangspunkt i én-modul-prosjektet javafx-template.

Med tilleggene over aktivert, så kan en bruke mvn-kommandoen for å utføre byggeoppgavene de implementerer:

Argumentet til mvn er enten en spesifikk byggeoppgave eller en såkalt fase, som er maven sitt hovedkonsept for å organisere og sekvensiere byggeoppgaver. Hvert type prosjekt/modul, f.eks. java-prosjekt, har et sett faser med tilhørende oppgaver. F.eks. så utføres byggeoppgaven compile:compile (compile-oppgaven til kompilator-tillegget) som en del av fasen compile. Når en skriver mvn compile så betyr det altså implisitt å kjøre kompilatoren. Faser har en implisitt innbyrdes rekkefølge, så hvis en kjører én fase, så kjøres automatisk fasene tidligere i rekken. F.eks. så kjøres fasene compile og test-compile automatisk før test-fasen når en kjører mvn test. Se maven sin side om dette for detaljene.

Merk at en kan oppgi flere (uavhengige) byggeoppgaver og/eller faser etter hverandre, f.eks. så kjører en ofte tester før en kjører programmet med mvn test javafx:run.

<configuration>-elementene inni <plugin>-deklarasjonen av tilleggene angir diverse verdier som tilleggene bruker når deres byggeoppgaver kjøres, om disse kjøres direkte eller som en del av en fase. Noen ganger er det nyttig å kjøre byggeoppgaver med spesifikke alternative verdier, f.eks. kan en ønske å kjøre én bestemt test(klasse) og ikke alle sammen på en gang, eller kjøre en alternativ app-klasse i stedet for den som er angitt i pom-en. Dette lar seg ofte gjøre ved å angi "-Dkonstant=verdi" som kommandolinjeargument, hvor konstant og verdi er spesifikk for tillegget og anledningen. (Anførselstegnet brukes for å unngå at spesielle tegn i konstantnavnet og verdien tolkes som noe annen en vanlige tegn.) F.eks. kjører man testklassenn pack.TestClass med mvn test "-Dtest=pack.TestClass" og app-klassen pack.AppClass med mvn javafx:run "-DmainClass=pack.AppClass". Som regel er konstantnavnet det samme som det tilsvarende konfigurasjonselementen.

Hensikten med hver byggeoppgave er ofte å generere filer, ofte kalt artifakter, som er avledet fra filer i prosjektet eller byggeoppgaver kjørt tidligere. F.eks. så er er resulatet fra kompilering class-filer og kjøring av tester gir testrapporter. De fleste slike byggeresultater (litt avhengig av konfigureringen) havner i target-mappa, f.eks. havner class-filene i target/classes-mappa (sammen med ressurser fra process-resources-fasen). Disse klassene (og ressursene) plukkes opp av jar:jar-oppgaven i package-fasen og pakkes i en jar-fil som også havner i target. Til slutt kan deploy-fasen brukes til å laste jar-filen opp på en server, så den kan lastes ned av andre og evt. settes i produksjon.

En nyttig fase som ofte inkluderes først (eller alene) i en mvn-kommando er clean. Den fjerner hele target-mappa, slik at byggingen starter med "blanke ark". Dette kan gjøre det enklere å finne feil i oppsettet, fordi en da inngår å kjøre byggeoppgaver på "gamle" byggeresultater.

Maven støtter oppdeling av et stort prosjekt i flere moduler. Hver av modulene blir på en måte selvstendige prosjekter under et felles hovedprosjekt. En flérmodul-variant av javafx-template-prosjektet finner du i modules-template-mappa. Denne mappa utgjør hovedmodulen, med moduler for kjernekode og ui i hver sine undermapper, henholdsvis core og ui. Merk at en kan ha flere nivåer enn dette, altså undermoduler med moduler under der igjen, men her forholder vi oss til bare to nivåer. For et større eksempel, se todo-list.

En hovedmodul angir undermodulene i pom-fila si, i <module>-elementer i <modules>-blokka:

Undermodulene referere tilbake til hovedmodulen ved å angi GAV-koordinatene i <parent>-elementet:

Undermodulene deklarerer egne artifactId-verdier, mens groupId og version arves fra hovedmodulen. Dermed får hoved- og undermoduler egne GAV-koordinater hvor groupId- og version-elementene er felles. Disse kan brukes for å angi avhengigheter mellom undermodulene, f.eks. fra ui-modulen til kjernemodulen.

Hovedprosjektet blir mer nyttig ved at pom-fila kan inneholde konstanter, avhengigheter og konfigurasjon av tillegg som er felles for undermodulene og gjøre det lettere å sikre at de bruker de samme konstantverdiene, avhengighetene og tilleggene.

Felles avhengigheter deklareres inni <dependencyManagement>-blokka og tillegg inni <pluginManagement>-blokka. I undermoduler angir man dem som vanlig, men kan utelate detaljer der deklarasjonene i hovedmodulen duger. I ui-modulen aktiveres f.eks. maven-compiler-plugin- og maven-surefire-plugin-tilleggene med versjonene og konfigurasjonene angitt i hovedmodulen, og i tillegg deklareres javafx-maven-plugin-tillegget, som ikke er nevnt i hovedmodulen:

mvn-kommandoer med faser som argument, f.eks. clean, compile og test, kan utføres i mappa for hovedprosjektet. Fasene blir da utført i underprosjektene i en rekkefølge utledet fra innbyrdes avhengigheter. Hvis f.eks. ui-modulen avhenger av core-modulen, så vil kommandoen mvn compile utført i hovedmodulen gjøre at compile-fasen først utføres i core-modulen og deretter i ui-modulen, siden det ligger i kortene at sistnevnte er avhengig av byggeresultatene fra førstnevnte.

Det er litt verre med kjøring av spesifikke byggeoppgaver, f.eks. javafx:run. Det går bare hvis tilsvarende maven-tillegg er aktivert for hovedmodulen og alle undermodulene. Ofte må man angi -pl-opsjonen etterfulgt av undermodulen for å begrense kjøringen til den relevante modulen. F.eks. kan man kjøre mvn -pl ui javafx:run i mappa for hovedmodulen i stedet for kjøre cd ui etterfulgt av mvn javafx:run.