Göm menyn

Labbinlämning

När du är klar med alla labbuppgifter du tänker genomföra (1-4 eller 1-5) lämnas all kod för labbserien in genom följande procedur.

  1. 2020-10-26: De vanliga demonstrationerna är inställda även under oktober och januari. Som ersättning för demonstrationerna får ni istället skicka med några (flera!) skärmdumpar som visar hur er Tetrisklient ser ut, i olika intressanta lägen under spelets gång. Detta checkas in som en del av ert repo och pushas till Gitlab, och har alltså samma deadline som kodinlämningen i juni/augusti.

    Handledaren kanske ställer några frågor i efterhand, på samma sätt som ni hade kunnat få frågor vid demonstrationen. Detta sker normalt via verktyg som Teams eller Zoom. Handledaren kontaktar er om det blir aktuellt.

  2. Projektet måste lämnas in i IDEA-format så att vi snabbt kan öppna det och navigera genom koden. Har du inte använt IDEA: Skapa ett projekt enligt tidigare instruktioner. Du kan då skapa enligt "existing sources".

  3. Se till att du inte har missat någon av varningarna från IDEAs kodinspektioner!

    Dessa visas normalt upp direkt i kodeditorn i IDEA, men det kan hända att man missar något i alla de filer man arbetar med. Gör därför så här för att se till att du inte har missat något.

    1. Välj Analyze | Inspect Code i menyn.
    2. Välj inspektionsprofil "TDDD78-2020-v1" och tryck OK.
      Använd INTE defaultprofilen.

    Det här är till stor del ett sätt att lära sig skriva kod som inte bara gör vad den ska utan även är välskriven och strukturerad. Det är också ett sätt att minimera risken för kompletteringar.

    Förstår du inte en varning? Utmärkt! Då har du en chans att lära dig något nytt, redan innan du lämnar in koden! Läs IDEAs inbyggda beskrivningar, sök efter varningen i de specifika tipsen eller våra utökade beskrivningar, och om det inte hjälper, fråga gärna assistenten eller examinatorn.

    Inget automatiskt inspektionsverktyg är 100% korrekt. Varningen ska alltså oftast tolkas som "har du tänkt på det här?" snarare än "du har fel!". I projektdelen, efter labbarna, måste sådana kommenteras på plats i koden med en god motivering till varför varningen var "ogiltig" i detta fall.

  4. Är detta en komplettering? Beskriv i så fall i filen "kompletteringar.txt", i rotkatalogen för projektet, hur varje enskild kommentar från handledaren har hanterats: Vad som ändrats och var i koden, hur du har löst problemet, och annan information som är relevant för att handledaren lätt ska se vad som gjorts.

    Gör du flera kompletteringar ska gamla kommentarer vara kvar och tydligt skilda från nya kommentarer (markera med kompletteringsdatum). Detta underlättar för oss och är en del av examinationen där du visar att du förstår varför kompletteringen behövdes.

    Se till att filen är adderad till Git, i projektets rotkatalog, och incheckad.

  5. Checka in all kod och dokumentation, och pusha till det Git-repo du har fått på LiU:s Gitlab. Ja, det måste vara det repo som vi har skapat när du anmälde dig i Webreg. Det är detta som vi kan hantera halvautomatiskt i vårt inlämningssystem eftersom vi då har möjlighet att använda webhooks och annan funktionalitet.

    Kontrollera noga att alla nödvändiga filer verkligen är incheckade, inklusive IDEAs projektfiler (utom .IWS / workspace.xml) och eventuell kompletteringsfil. Se gärna till att kompilerad kod (*.class) och andra överflödiga filer inte har checkats in.

    Alla incheckade och pushade filer kan ses direkt i Gitlabs webgränssnitt. Icke incheckade filer kan ses i IDEA (Tool window "Git", fliken "Local Changes", sedan "Unversioned Files") eller via git status på kommandoraden.

  6. Skapa en tagg (etikett) i Gitlab. Detta visar oss vilken version av koden som lämnades in vid inlämningsdatumet. (Skapar du en tagg på annat sätt måste du se till att explicit pusha den till Gitlab: git push origin [tagnamn]! eller git push origin --tags! En vanlig "push" skickar inte över taggar.)

    1. Logga in på gitlab.

    2. Gå till ditt projekt och välj "tags".

    3. Välj "New tag".

    4. Du kan gärna sätta taggnamnet till "t1" om detta är första gången du lämnar in. Om du får komplettering kan du nästa gång sätta en ny tagg "t2", och så vidare. Exakt vad taggarna heter och vilka nummer de har är egentligen mindre viktigt, men det är bra om det syns på något sätt i vilken ordning de kommer (så att "t2" inte är en nyare tagg än "t4", eller taggarna heter "x", "4" och "nej", till exempel).

      Flytta aldrig en tagg så den pekar på en annan commit! Varje gång du taggar en version skapas en kodanalys för den versionen. Flyttar du taggen uppdateras inte kodanalysen i och med att den redan existerar för det taggnamnet. (Vet du inte vad vi pratar om? Då är det ingen fara.)

      Med andra ord: Om du skapar en tagg och sedan inte vill lämna in den taggade versionen, skapar du en ny tagg för det du vill lämna in och låter den gamla ligga kvar "oanvänd".

    5. Låt "Create from" vara kvar på "master" (under förutsättning att ni inte har valt att lägga den slutliga versionen i någon annan gren...).

    6. Låt "Create from" vara kvar på "master".

    7. Meddelanden och "release notes" behövs inte.

    8. "Create Tag"!

  7. [an error occurred while processing this directive]

Labb av Jonas Kvarnström, Mikael Nilsson 2014–2020.


Sidansvarig: Jonas Kvarnström
Senast uppdaterad: 2020-10-26