Rigging av alt som trengs for utvikling tar mye tid. En skal installere _språket_ (*python*, *java*, ...) og en trenger diverse _rammeverk_ (*junit*, *javafx*, ...). Kanskje skal en bruke såkalte _byggeverktøy_ (*maven*, *gradle*, ...) og det må installeres og konfigureres. På toppen av dette kommer selve _IDE-en_ (*VSCode*, *IntelliJ*, *Eclipse*, ...), som må passe til og være konfigurert for det en har installert forøvrig.
En kompliserende faktor er _versjoner_, en må ha versjoner av alt som passer sammen og ofte trenger en ulike versjoner for ulike prosjekter. Selv om det finnes verktøy som *sdkman* som hjelper en å installere og veksle mellom ulike versjoner, så er det en del manuelt arbeid.
For større prosjekter er kanskje ikke dette merarbeidet så problematisk, det må jo ikke gjøres så ofte. Men hvis en veksler mellom flere mindre prosjekter eller bare skal jobbe med små eksempler og øvinger, så kan det bli veldig tungvint.
== Gitpod = VSCode + git + Docker
Gitpod prøver å løse dette problemet ved å tilby en nettleserbasert IDE (*VSCode*), som er ferdigkonfigurert for spesifikke prosjekt. En slipper dermed å installere IDE-en. Konfigurasjonen av både IDE-en og den underliggende _virtuelle maskina_ (*Linux* i *Docker*) ligger i *git*-kodelageret sammen med prosjektfilene forøvrig. Når kodelageret med konfigurasjon og prosjekfiler først er satt opp, så slipper en dermed også å installere språk, rammeverk og verktøy, det er bare å åpne IDE-en med utgangspunkt i kodelageret.
Jobben med oppsett må jo fortsatt gjøres, men en trenger bare å gjøre det én gang. Alle som siden skal jobbe med samme prosjekt, kan bare åpne IDE-en på et kodelager og gå i gang. Dersom det er snakk om et kode-eksempel, en øving eller et standardisert prosjekt, så kan det gjøres på forhånd av fagstaben, så i hvert fall studenten slipper styret med å sette alt opp. Og for nye prosjekt kan en ofte ta utgangspunkt i tidligere prosjekter eller eksempler basert på samme språk og rammeverk.
== Gitpod @ NTNU
Gitpod har integrasjoner med skytjenester som *gitlab* og *github*, så en kan logge inn på og administrere kodelagre der. Gitpod kan også settes opp internt, og NTNU har sin egen gitpod-installasjon tilgjengelig på http://gitpod.stud.ntnu.no, som er integrert med IDI sin *gitlab*-tjeneste på http://gitlab.stud.idi.ntnu.no, så emner som bruker gitlab kan automatisk tilby gitpod som plattform for utvikling.
Alle kodelagre i IT1901 med eksempler og maler er ferdig _gitpodifisert_, se f.eks. https://gitlab.stud.idi.ntnu.no/it1901/javafx-templates[javafx-maler]. Dermed er de lette å bygge videre på, det er bare å trykke på *Gitpod*-knappen. Faktisk kan alle kodelagre på vår gitlab åpnes i gitpod for redigering av filer. Men for å kunne utvikle ordentlig, så må de altså gitpodifiseres vha. konfigurasjonsfilen *.gitpod.yml* og evt. en tilhørende *docker*-fil.
== Gitpod-arkitektur
VSCode i nettleseren fungerer nokså likt VSCode lokalt, den har tilgang til et filsystem med kjørebare programmer, og en del av filsystemet utgjør arbeidsområdet til VSCode. Forskjellen er at filsystemet og programmene er inni en virtuell maskin i skyen, og maskina startes opp kun for å kjøre VSCode i nettleseren. Ved oppstart _klones_ kodelageret inn i maskina, og innholdet utgjør altså arbeidsområdet til VSCode. Konfigurasjonen av maskina og evt. oppstartsinstruksjoner leses ut av *.gitpod.yml* på toppnivå i det samme kodelageret.
[.stretch]
image::images/gitpod-arch.png[width=800]
Den virtuelle maskina er _flyktig_, i den forstand at den forsvinner av seg selv hvis en lukker VSCode (eller fanen) eller lar være å bruke den en periode. Arbeidsområdet (og noen andre viktige filer) arkiveres imidlertid, slik at den kan startes opp igjen med i praksis samme innhold. Det blir som om en legger en bærbar i dvale og så vekker den til live igjen. Vanligvis vil en derfor fortsette med et eksisterende arbeidsområde fra hovedsiden til gitpod-tjenesten, i stedet for å starte en ny virtuell maskin med et nytt arbeidsområde fra (gitlab-nettsida for) kodelageret. Det er bare når en endrer oppsettet etter å ha redigert *.gitpod.yml* eller *docker*-fila at en må starte en helt ny maskin.
Som nevnt klones kodelageret inn i den virtuelle maskina, og håndtering av kodelageret blir som ved kjøring på egen maskin, en bruker de vanlige *git*-kommandoene for å synkronisere med gitlab-tjeneren. En er ikke nødt til å lagre unna endringer i arbeidsområdet til tjeneren før den virtuelle maskina legges i dvale, hele arbeidsområdet arkiveres jo, men dersom en jobber med andre eller bruker VSCode i både gitpod og lokalt, så må en jo synkronisere filer via gitlab. Merk også at arkiverte arbeidsområder lagres ikke evig, de kastes etter noen uker uten bruk, så en må bruke git innimellom.
== Gitpod-bruk i emner
Gitpod kan brukes i emner på ulike måter. Emner som i dag distribuerer og deler innhold vha. git-kodelagre, kan gitpodifisere og få ekstra fordeler. Vi har identifisert en del scenarier for bruk av gitpod i emner, som en bør være fortrolig med.
=== Kode-eksempler
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*.
=== Få veiledning
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.
=== Øvingsopplegg
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 (!)
Eksamen kan rigges omtrent som et øvingsopplegg, med et personlig kodelager pr. student, med både oppgave og (etterhvert) besvarelse i.
