Göm menyn

Inlämning av projekt

Projekt: Inlämning av kod och dokumentation

Allmänna regler

Vi har strikta instruktioner för inlämning. Vi har många projekt, så att lägga ner 5-10 minuter "i onödan" per projekt blir snabbt till många timmar som kunde ha lagts på kursutveckling. Därför måste vi returnera labbar som inte följer instruktionerna för komplettering.

Detta gäller också att hantera de problem som upptäcks av automatisk kodanalys, vilket diskuteras mer längre ner på sidan.

Videodemonstration (fram till och med januari 2021)

När vi är i distansläge kan vi inte mötas ansikte mot ansikte. Istället får man spela in en videodemonstration för projektet. Demonstrationen ska visa upp "allt" som ni har gjort i projektet så att handledaren kan se den funktionalitet som finns och att den fungerar. Det finns några olika alternativ:

  • För att spela in det som händer på skärmen: Man kan antingen använda en mobilkamera (eller liknande) eller ett skärminspelningsprogram. På TDDI02 förklaras ungefär hur man kan göra med skärminspelningsprogram. Våra krav är betydligt lägre (det ska ju bara bli en ersättning till en livedemo, inte en perfekt film), men oavsett inspelningsmetod ska det synas tydligt vad som händer.

  • För att förklara vad som händer: Eftersom mobilkameran också spelar in ljud kan man enkelt förklara vad projektet är, vad man gör och vad som händer på skärmen. Använder man skärminspelningsprogram kan man lägga på ljud i efterhand, eller kanske skriva ett dokument där man förklarar vad som visas (med tidsangivelser så att handledaren kan se vad som händer).

Om videon blir lagom liten kan den läggas in i projektet i Gitlab. Annars kan den läggas upp på er Onedrive, där man har 5 TB utrymme, och delas med handledarna + examinatorn. Vi kommer inte att behålla filmerna och det går bra att radera dem när granskningen är färdig.

Det är också extra viktigt att användarhandledningen i projektrapporten är välskriven, så att handledaren vet hur man startar och använder programmet vid egna tester.

Handledaren kan tänkas ställa frågor kring koden. Detta kan eventuellt ske via epost, men det kan också tänkas att vi använder verktyg som Teams eller Zoom. Handledaren kontaktar er om det blir aktuellt.

Videon har samma deadline som själva projektinlämningen. Om den inte läggs in i projektet i Gitlab ska man skicka med en länk som en textfil i projektet alternativt ge en länk i den inlämningsissue man skapar.

Inlämningsprocedur

  1. Gå noga genom den utökade kodanalysen.

    Som du vet får du numera en utökad kodanalys i issues i ditt eget projekt i Gitlab. 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.

    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 beskrivningarna som finns med i kodanalysen (klicka "visa förklaring" vid behov), sök efter varningen i de specifika tipsen, och om det inte hjälper, fråga gärna assistenten (i god tid).

    Ignorera inte den utökade kodanalysen. Det finns numera inga absoluta krav att man måste fixa eller kommentera alla de nya varningarna, men många av varningarna är sådana som granskaren ändå skulle ha kommenterat vid inlämningen. Nu får du chansen att få de kommentarerna redan innan inlämningen så du kan polera koden och få bättre chans till godkänt / högre betyg redan från början.

    Ju flera fel, desto större sannolikhet för komplettering. Ju allvarligare fel, desto större sannolikhet för komplettering. Ju flera fel som är enkla att fixa men ändå har lämnats kvar, desto större sannolikhet för komplettering även om varje enskilt fel inte var så allvarligt!

    Man måste dessutom fixa alla inlämningsfel som indikeras via stora röda rutor nära toppen av analysen. Det gäller till exempel en avsaknad av IDEA-projekt, klassbibliotek som inte har checkats in, och liknande problem som gör att vi inte ens kan granska inlämningen utan mycket extraarbete. Inlämningar som har sådana felrutor lämnas utan åtgärd och man får lämna in igen vid nästa tillfälle.

    Ser vi större mängder icke åtgärdade och icke motiverade varningar kan det leda till omedelbar komplettering utan en djupare granskning. Om kodanalysen påpekar många uppenbara problem är det ett slöseri med den begränsade handledningstiden att handledaren går genom hela projektet i detta skede. Då får du en komplettering, får arbeta vidare till nästa tillfälle, och kan då få bättre återkoppling på sådant som ett verktyg inte kan upptäcka automatiskt.

  2. Läs genom betygskriterierna en gång till och se till att koden uppfyller grundkraven, inklusive krav på felhantering, resurshantering med mera. Gå genom de specifika tipsen. Kodanalysen kan inte ersätta en programmerares genomgång av projektet.

  3. Dubbelkolla att projektdokumentet är uppdaterat. Följandede instruktioner gäller både förstagångsinlämningar, kompletteringar och plussningar.

    I den första delen, projektplanen, behöver man främst uppdatera sådana delar som vi kan ha nytta av för att förstå slutresultatet. Man behöver alltså inte uppdatera t.ex. milstolpar om de har ändrats, eftersom de var till för att hjälpa er med egen planering. Däremot kan man behöva ändra bakgrundsinformationen om man har ändrat inriktning på projektet. Det du uppdaterar kan ersätta den gamla planen, eller kan läggas i en separat underrubrik efter originalplanen.

    Den andra delen av dokumentet, projektrapporten, behöver helt och hållet stämma överens med det slutliga projektet. Det gäller även vid kompletteringar.

    Dokumentet ska använda den korrekta mallen och ska innehålla all den information vi efterfrågar med korrekt numrering av avsnitt. Se det som en tenta – en viktig del av betyget!

    Se till att dokumentet är exporterat till PDF-format. Använd t.ex. File | Export to PDF i OpenOffice Writer. Döp beskrivningen enligt följande mönster, utan mellanslag i filnamnet. ID måste alltså finnas med.

    • liuid123-rapport.pdf om du arbetar ensam
    • liuid123-liuid456-rapport.pdf om ni arbetar i par

    Se till att rapporten och den exporterade PDF-filen är adderade till Git, i roten av projektet, och incheckade med korrekt namn. Den utökade kodanalys som ni får i era issues ger ett felmeddelande om detta inte stämmer.

    Det räcker med att skriva på svenska. Alla handledare förstår svenska tillräckligt bra för att läsa dokumentationen.

    Du som går TDDE30 behöver dessutom göra en separat inlämning till språk- och strukturgranskarna!

  4. Se till att du har följt instruktionerna för videodemonstration (överst på sidan).

  5. Dubbelkolla att eventuell lånad kod är markerad enligt instruktionerna. Den utökade kodanalys som ni får i era issues visar korrekt markerad lånad kod med en annan bakgrundsfärg. Om koden är lånad men inte tydligt markerad kan det leda till misstanke om fusk.

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

    Gör ni 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 ni visar att ni förstår varför kompletteringen behövdes.

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

  7. Se till att alla uppdateringar är pushade 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.

    Kodanalysen ska numera automatiskt kontrollera att alla nödvändiga filer finns med (projektfiler, externa klassbibliotek med mera). Annars ska du ha fått en varning för detta redan i första steget.

    Alla incheckade och pushade filer kan också 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.

  8. Dubbelkolla och trippelkolla att allt är korrekt. Kolla även den automatiska kodanalysen en sista gång, i dina egna issues, ifall något har blivit fel under dina sista uppdateringar.

  9. Nu när du har kontrollerat att allt är OK och att du inte har några allvarliga varningar i kodanalysen: 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. Meddelanden och "release notes" behövs inte.

    7. "Create Tag"!

  10. [an error occurred while processing this directive]

  11. Om du har lämnat in på korrekt sätt ska din issue så småningom tilldelas till en milstolpe och en handledare. Det ska också komma en kommentar i din issue (och normalt även via epost), där det antingen står att inlämningen är mottagen eller att det finns allvarliga problem som gör att koden inte kan analyseras (något som i så fall även ska ha visats i den kodanalys som du fick tidigare). I det senare fallet behöver du alltså arbeta vidare med projektet och göra en ny inlämning.

    Denna hantering triggas för närvarande inte direkt av att du skapar en issue. Istället finns ett script som regelbundet kontrollerar alla inlämningsissues. Detta kan köras så ofta som varje halvtimme under inlämningstider men kan också köras mer sällan. Alltså kan det dröja lite innan du får en kommentar i din issue.

    Har du inte fått någon kommentar inom 12 timmar är något fel. Det kan hända att scriptet inte kan få kontakt med Gitlab eller att datorn som kör scriptet har kraschat, men det kan också hända att du har gjort något fel, t.ex. att du inte har lämnat in på rätt plats. Var på din vakt och dubbelkolla, så du inte missar inlämningstillfället!


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