Web
Analytics
 

How the IOOPM Course Works

Table of Contents

As long as this note remains on this page, any information is subject to change and broken links, etc. are to be expected. Please be restrictive in reporting any errors for now.

In 2017, we presented a paper on the design of the IOOPM course at the SPLASH-E symposium in Vancouver. If you want to know more about why we are doing what we are doing, go ahead and read the paper (15 pages).

1 DONE Changes from 2017

1.1 Changelog

Completely new Assignment 1
Assignment 1 is now a cross-breed of traditional labs and traditional assigments. The idea is to provide some more safety and also steer thoughts a bit, but not have small tasks that are too well-aligned to one or two specific concepts.
Overhaul of Assignment 2–4
Based on outcome of assignment 1. FEEDBACK, people!
New course website
Toning down reliance on GitHub. Also, no markdown which is a huge boon for me…
Stricter group meetings, with coaches
As described here.
New vagrant machine for using own laptops/computers
As described here.
Changed Emacs shortcuts and settings
As described all over the place.
New lecture material on some lectures
Generally freshening things up and aligning content with assignment 1.

1.2 Rooms for Improvement

Queuing time on labs
Probably not solved (but you’re fewer this year).

1.3 New things 2017 that we are keeping

  1. Two projects (but the simpler one needs beefing up)
  2. Survey for finding project groups

2 Kursöversikt

2.1 Faser och sprintar

Kursen är uppdelad i tre faser, fas 1, 2 och 3. Fas 1 och 2 behandlar imperativ programmering exemplifierad med C respektive objekt-orienterad programmering exemplifierad med Java. I dessa faser arbetar du i ett kodpar med en annan person. Mellan varje inlämningsuppgift kommer du att rotera partner. Fas 3 är ett projektarbete med 4-6 personer.

  • Fas 1 och 2 är indelade i 2 sprintar vardera. Varje sprint är 2 eller 3 veckor lång (se deadlines).
  • Indelningen av fas 3 i sprintar samt sprintarnas längd bestäms av projektgruppen.

Varje sprint har ett antal uppgifter knutna till sig. För varje sprint inom samma fas växer kraven på uppgifterna som också blir mer komplicerade, och du får fler uppgifter att välja mellan. För att bli godkänd på kursen måste du göra minst en uppgift per sprint.

2.2 Inlämningsuppgifter, mål och redovisning

För att bli godkänd på kursen kommer du att behöva demonstrera att du uppnått alla kursmål (detta gäller på alla kurser). För att göra det tydligt arbetar vi med att separera inlämningsuppgifter från de kursmål de (är tänkta att) examinera. Det betyder att syftet med att göra en inlämningsuppgift inte är att “skriva ett program som…” utan att koppla programmet mot kursens mål och använda programmen som du skriver för att visa att du uppnått målen.

Du utgår alltså från uppgifter (i olika grad av förfärdigande beroende på när du redovisar) när du redovisar mål, och det skall finnas en tydlig koppling till uppgiften eller någon föreslagen utökning till uppgiften. Det ingår i uppgiften (eller egentligen i hela kursupplägget) att förstå mappningen från uppgift (eller del av uppgift) till lämpliga mål. Vi ger ibland förslag, men färre och färre ju längre in i kursen vi kommer. Det räcker inte med att bara följa förslagen för att bli godkänd, utan du måste själv ta reda på/förstå vilka mål du bör redovisa och när.

Målen redovisar du i stort sett uteslutande på labbarna (ca 8 timmar varje vecka). Till labbarna kan du också gå för att få hjälp. Försök att alltid redovisa mål i sammanhängande klumpar.

2.3 Om kursmålen

För varje mål anges vilken nivå målet ligger på och hur det kan redovisas. 2018 finns ca 43 mål på nivå 3, 18 mål på nivå 4 och knappt 8 mål på nivå 5. Av de 43 målen på nivå 3 avser 4 mål avklarade inluppar och 6 mål redovisas i och med projektet.

Du måste bocka av mål löpande under kursens gång. Det är ca 25 labbar att redovisa på och totalt 55 mål att redovisa på labbar (för nivå 5). Det finns ett maxtak på 4 avbokade mål per labbtillfället – du måste alltså redovisa på minst 17 labbar för att få betyget 5.

För att bli godkänd på kursen måste alla mål vara godkända, och kodprovet avklarat. För att få betyget 3 på kursen måste samtliga mål på nivå 3 vara uppfyllda, för betygen 4 måste samtliga mål på nivå 3 och 4 vara uppfyllda och för betyget 5 måste samtliga mål vara uppfyllda. Observera att det inte finns en linjär relation mellan antalet mål och tidsåtgång – och många mål kan bockas av samtidigt och inom ramarna för samma uppgift.

Notera att du förväntas att själv söka efter information, både i de länkar och bokreferenser som finns i kursmaterialet, men också fritt med hjälp av t.ex. Google och Wikipedia. Föreläsningarnas syfte är att måla en övergripande bild och introducera viktiga koncept och ibland även göra praktiska övningar.

2.4 Kurslitteratur

This course does not follow any specific book. If you like following books (great!!!), please come talk to me and we can discuss what kind of book would be good for you. The course goes on forever, so no sweat if you don’t have a book the first 1-2 weeks!

2.5 Arbetsgrupper och programmeringspar

Under kursens gång kommer du att ingå i en framslumpad arbetsgrupp med ca 10-12 personer. Dessa grupper byggs successivt upp under kursens första vecka i takt med att vi får namnen på alla registrerade studenter från IT-kansliet. Ur arbetsgruppen får ni fritt skapa kodpar om två personer med kravet på att rotera partners mellan varje inlämningsuppgift och att inger får ha samma partner mer än en gång under fas 1 och 2. Anledningen till att du själv skall välja par beror på att du i möjligaste mån vill arbeta med någon annan i samma grupp med liknande intressen och ambitioner.

Allt arbete på kursen sker tillsammans med någon annan i ett programmeringspar. Paren kommer också i regel att redovisa tillsammans, oavsett om dessa redovisningar sker i labbsal eller på annat sätt. Alla bedömningar är individuella och det är möjligt att en student blir godkänd och en underkänd på samma redovisning. Det är också möjligt att ha en redovisning där endast en student bockar av högre mål, etc.

2.6 Redovisning och AU-Portalen

With few exceptions (essay, C7, communication and project achievements), demonstrations take the form of oral examination in front of a computer terminal with one examiner and two students working in a pair.

Checks are individual, meaning that both respondents must demonstrate mastery for both to pass. A mostly passive respondent will not pass a check even with a brilliant partner. The responsibility for making sure that both respondents actively participate is on the respondents – not on the examiner. For this reason, and because it tends to speed things up, we encourage you to prepare your demonstrations and discuss who says what. In our experience, this makes demonstrations run faster, have higher quality, and increase your reflection (e.g., you will remember it better).

The choice of oral examination serves several purposes. Explaining interactively is time-efficient, both for you and us, and feedback is given immediately when the demonstration is still fresh in your mind. Technical communication is an important soft-skill that is trained automatically in this setting.

Demonstrations take place in 1515, 1549 and (for students with laptops also 1245), during the lab sessions, excluding bootstrap labs (where you will be demonstrating lab tasks instead). You request to demonstrate through the AU Portal where you can choose which achievements you wish to demonstrate.

After requesting to demonstrate, there will be a waiting period (so please do continue to work). A feed of pending requests to demonstrate is shown on a screen to the TAs, who claim demonstrations before dispatching to where you are located. Modulo reasons, demonstrations are picked up in the order they were requested.

You can see on the web page when your request has been picked, up and by whom. At all times, you can also see how many requests are waiting and how many are in front of their request, if any. You cannot queue several simultaneous requests.

When the examiner arrives, you must pitch your demonstration, which means:

  1. Stating what achievements you wish to demonstrate
  2. Explaining why/how it makes sense to demonstrate them together
  3. Explaining what evidence you will use in the demonstration

If the examiner is not satisfied with 1 or 2, she will explain why and reject the request.

By evidence, we mostly mean artefacts developed in the course that will form the basis of the demonstration. For example, “we profiled the binary search tree that we developed in Assignment 2”. The key idea with evidence is that you relate the achievements to the programming assignments (and programming project) of the course1. Expect to be asked questions that force you to go “off-script”, e.g., what would happen if \(X\) is changed for \(Y\), or the examiner asks you to change some lines of code, or introduces a bug etc.

If the examiner finds the answer to 1–3 satisfactory, she will hand over the running of the demonstration to you! Different examiners approach this task differently. Some will interrupt and ask questions. Some delay all questions to the end.

Only the achievements explicitly stated at the beginning of the demonstration can be passed in the demonstration. If you were to happen to ``meet the requirements’’ for some other achievement too, this achivement will not be marked as done. Actually, we will not even tell you if you didn’t see it yourself! Our philosophy is that you can only know what you know you know, meaning that accidentally demonstrating procedural abstraction not knowing that that is what you are doing counts as nothing. (We are not sadists either so expect to get nudged towards the relevant insight.)

Each achievement in your demonstration will be marked as either pass, fail or fail with push-back. If you fail to demonstrate an achievement, you are free to try again whenever you like. A fail with push-back indicates a deep misunderstanding of something, which blocks you from re-attempting demonstration for the rest of the lab session to encourage spending some more time understanding that achievement. Failures with or without push-back are not counted towards any grade.

In 2017, about 30\% of all demonstrations were at least partially failed. About 5\% got puch-backs.

An examiner’s decision is final, and the examiner does not “have to” motivate failing a presentation. Examiners are however expected to explain and motivate both passing and failing grades on demonstration.

2.7 Uppföljningsmöten

Vid sex tillfällen under kursen kommer du att kallas till ett kort uppföljningsmöte där du (och din labbpartner) får presentera hur det går för er i den pågående sprinten. Där kan ni visa vad ni har gjort hittills och vad ni planerar att göra resten av sprinten. Tanken med dessa möten är att ni ska kunna få hjälp att hålla en lämplig styrfart genom kursen och att komma loss om ni har kört fast. Om ni är osäkra på vilka mål som passar med er uppgift kan får ni diskutera saken med en assistent och ett annat programmeringspar. Läs mer här.

2.8 Labbar

SUPERVIKTIG SKILLNAD MOT PKD: Labbar på denna kurs avser tid att redovisa och få hjälp med programmering. Den mesta programmeringen sker utanför schemalagd tid! Beräkna 14-15 timmars arbete utanför labbar och föreläsningar i snitt per vecka.

Hela kursens finns det ungefär 8 timmar schemalagd i datorsalar per vecka, s.k. labbtillfällen. Deltagande vid dessa tillfällen är inte obligatoriskt (förutom inledande 6 C-labbar och 3 Java-labbar). Vid dessa tillfällen finns det möjlighet att få handledning och också möjlighet att redovisa mål (förutom inledande 6 labbar).

Mer information om labbarna och redovisning finns här.

2.9 Betyg

Målen har en betygsnivå kopplad till sig. Mål på högre nivå omfattar de på lägre nivå. Du kan inte byta ut ett mål på en högre nivå mot ett mål på en lägre nivå (det vore inte vettigt).

  • För att få betyget tre måste du klara av alla mål på nivå 3.
  • För att få betyget fyra måste du klara av alla mål på nivå 3 och 4.
  • För att få betyget fem måste du klara av alla mål på nivå 3, 4 och 5.

2.10 Högskolepoäng och kursfordringar

Kursen ger totalt 20 hp uppdelat på fem delar:

  • 2.5 hp för kodprovets imperativa del (C)
  • 2.5 hp för kodprovets objektorienterade del (Java)
  • 5 hp för inluppar 1 avklarad
  • 5 hp för inluppar 2 avklarad
  • 5 hp för projektet avklarat

Observera att om du klarar av alla mål på nivå 3 och uppfyller alla krav på projektuppgiften får du 15 HP (dvs. alla utom kodprovet).

2.10.1 Definitionen inluppar 1 avklarad

  • Två av Z-målen (inlupp 1–4) avbockade.
  • 14 avbockade mål på nivå 3 (du kan inte använda samma mål i flera faser)
  • Inga eftersläpande repetitionsmål

2.10.2 Definitionen inluppar 2 avklarad

  • Resterande två av Z-målen (inlupp 1–4) avbockade.
  • 14 avbockade mål på nivå 3 (du kan inte använda samma mål i flera faser)
  • Inga eftersläpande repetitionsmål

2.10.3 Definitionen projektet avklarat

  • Målen Y64–Y69 uppfyllda, och därutöver
  • 4 avbockade mål på nivå 3 (du kan inte använda samma mål i flera faser)
  • Inga eftersläpande repetitionsmål

3 Arbetsflöde under kursen

Kursens upplägg härmar avsiktligt lättrörliga eller agila processer, främst Kanban och Scrum. Under projektdelen (fas 3) skall du och din projektgrupp själva lägga upp en plan, följa upp och revidera den, etc. Fram till dess kommer ni att öva genom att arbeta på motsvarande sätt med kursen. Vi betraktar kursen som ett projekt vars slutmål är att du skall vara godkänd med det betyg som du siktar på.

3.1 Steg 1: Sätt ditt personliga mål

Vilket betyg vill du ha? Du styr själv vilket betyg du vill uppnå – vilken nivå av insikt vill du nå, etc.? Målen på nivå 4 och 5 speglar djupare insikter eller högre kvalitet med avseende på olika kursmål. Om du vill nå betyget 3, 4 eller 5 måste du bestämma dig för det och aktivt arbeta för att nå dit. Fatta ett beslut. Du kan ändra dig senare. För att minska stressen kan du redan nu planera in en tidpunkt (t.ex. 1:a oktober) för att eventuellt revidera beslutet.

3.2 Steg 2: Styrfart

Hur blir du godkänd på en kurs? Det går inte att arbeta på att “bli godkänd”, det är för flummigt och abstrakt. “Problemet” måste brytas ned i mindre beståndsdelar (delproblem) och kanske även bryta ned dessa ytterligare för att nå tillräckligt konkreta proble/uppgifter som faktiskt går att tackla.

Du har redan fattat beslut om vilket betyg du vill ha. Då vet du också vilka mål du måste klara av. Det är dina hyfsat konkreta uppgifter.

Exempel: Låt säga att du satsar på betyg 7 och att det omfattar totalt 42 mål. Du tittar igenom målen och ser att 8 är knutna till projektet. Ytterligare 4 mål verkar rimliga att redovisa i samband med projektet (så vitt du förstår) eller via andra aktiviteter. Då kvarstår 30 mål som skall redovisas under fas 1 och 2.

Det är totalt 5 sprintar under fas 1 och 2. 30 genom 5 är 6. Det betyder att du måste klara av 6 mål varje sprint för att ha 12 kvar när projektet börjar.

6 är den styrfart (velocity) som du skall ha i snitt per sprint för att komma i mål. Det betyder 3 mål per vecka och i snitt 1,5 mål per labbtillfälle. Det är ganska troligt att du inte kommer att redovisa 1,5 mål varje labbtillfälle, eller ens 3 mål varje vecka. Verkligheten fungerar ofta så att vi gör framsteg på flera saker, och sedan klarar av många på ett bräde. Om du gjorde en graf där Y-axeln var antal återstående mål och X-axeln var tiden skulle det “idealiska” vara en rät linje med start i (0,30) och slut i (5,0). Verklighetens kurva kommer att se annorlunda ut.

En graf av detta slag kallas för en burndown chart, och du kommer att göra flera sådana under kursens gång. En burndown chart är enkel att tolka och ger direkt en känsla för om det “går bra” eller inte – kommer jag till slut att komma i mål på utsatt tid?

SampleBurndownChart.png

Figure 1: Exempel på burndown chart.

I exemplet planerar vi utifrån förutsättningen att alla mål tar lika lång tid. Det är naturligtvis inte sant. Ett mer raffinerat sätt att planera tar varje uppgift (mål i detta fall) och tilldelar det ett antal “story points”, som är ett relativt mått på hur den uppskattade tiden att implementera delen. Kanske de 30 målen skulle motsvara 65 story points, och då skulle vår styrfart vara 13 story points istället för 6 mål (som alltså motsvarar samma arbete, bara uttryckt i en annan enhet). Om du för varje avklarad uppgift matar in dess “faktiska story points” får du automatisk återkoppling på din egen skattning och kan justera för att du t.ex. tenderar att underskatta svårigheter, etc. Du kan också planera med arbetstimmar istället för story points (men arbetstimmar är absoluta i tid vilket story points inte är).

För dig som tycker att det mesta på kursen är nytt kan det vara vanskligt att försöka avgöra om ett visst mål är värt 1 eller 3 story points. Då är det bättre att planera i enheten avklarade mål, åtminstone till en början.

3.3 Steg 3: Vad skall jag göra denna sprint?

Så länge vi håller styrfarten behöver vi inte planera för vad vi skall göra resten av projektet (kursen), utan kan fokusera på den aktuella sprinten. Varje sprint skall du göra en inlämningsuppgift och det är utifrån den uppgiften du skall redovisa mål.

Detaljplanering är alltså att bestämma sig för inlämningsuppgift och mål. Du kan börja i båda ändor: vilka mål har jag kvar och vilken uppgift verkar passa bäst, eller vilka uppgifter finns det och vilka mål verkar passa bra för dem? I början av kursen har du många mål och få uppgifter så då lämpar det sig bättre att börja med att bestämma uppgift först. Förmodligen är det en bra idé att vara halvklar med uppgiften innan du funderar över vilka mål du kan redovisa utifrån den. (Uppgifterna är designade utifrån målen och du kan alltid få hjälp med den mappningen senare. Det finns ingen anledning att stressa över detta!)

Under första sprinten finns det bara en uppgift att välja mellan: lagerhanteringssystemet. Det gör det lätt att “välja”. Om du följer SIMPLE-metodiken uppmuntrar den dig att göra en nedbrytning av specifikationen av uppgiften i delproblem etc., precis som kursen. Det betyder att du kan göra en separat plan för implementationen av lagerhanteringssystemet, som inte behöver bry sig om mål om du inte vill. Du kanske bryter ned lagerhanteringssystemet i 52 deluppgifter. Du och din partner lägger upp ett arbetsschema med 25 timmar under sprinten. Styrfart 52/25 = 2 deluppgifter per timme. Ett annat alternativ är att blanda mål och deluppgifter i samma plan.

Att lära sig att planera och följa upp planen är också en del av kursen så stressa inte över att det tar tid att göra. Det får ta tid. Det är också okej att inte lyckas med sin plan hela tiden – du är ju här för att öva. Om du inte är ärlig mot dig själv och andra i din planering lär du dig ingenting och vinner heller ingenting.

3.4 Steg 4: Uppföljning

Planering är bra, men du måste också följa upp utfallet så att du kan justera hur du planerar i framtiden. Detta görs tillsammans med andra i teamet, och finns beskrivet här.

3.5 Steg 5: Revidera planen

Ditt burndown chart visar trenden – vad har du för styrfart, och kommer du att nå ditt mål? Kanske blir du sjuk en vecka och tappar därmed styrfart och måste planera in att komma ikapp? Kanske går det bättre än vad du trodde och du får smak på att sikta på ett högre betyg? Eller tvärtom.

I slutet av varje sprint är det läge att göra en liten kort postmortem som sammanfattar hur det gick och hur verkligheten avvek från din plan. Det är högst personliga reflektioner som kan hjälpa dig att planera bättre nästa gång. Är du tidsoptimist? Etc.

3.6 Steg 6: Retrospektiv

Mot kursens slut kommer du att göra en mer djuplodande uppföljning och analys av arbetet har fungerat, och hur styrfart, stress, förväntat/eftersträvat betyg, etc. har ändrats under kursens. Detta redovisas i målet C7: Planering och uppföljning.

3.7 Verktygsstöd: Trello

Vi rekommenderar att du använder ett verktyg för att hantera ditt arbete. Trello är ett gratis verktyg för att arbeta med Scrum-liknande processer. I Trello hanterar du listor med uppgifter på ett “bräde” och flyttar uppgifter mellan olika listor för att hålla reda på vad som är klart, vad som ligger i din backlog, vilka uppgifter som just nu utförs etc. Trello funkar bra både för individuellt arbete och grupparbete.

Vi har skapat två bräden som du kan kopiera. Bräde ett innehåller kursens alla mål i kategorierna TODO 3, TODO 4, TODO 5, Doing, Next och Done som du kan kopiera och använda för din planering. Det går dessutom att koppla Trello till tjänster som genererar burndown chart för dig. Bräde två är ett utkast till plan för det första lagerhanteringsystemet. Det är inte komplett, utan tjänar till att hjälpa dig att komma igång.

Du hittar våra Trello-bräden här.

4 Deadlines

4.1 Hur funkar deadlines?

De flesta inlämningsuppgifter har två deadlines, en mjuk och en hård. Den mjuka deadlinen avser det datum då vi tycker att du bör ha redovisat en uppgift. Den hårda deadlinen avser det datum då du måste ha redovisat. Den hårda deadlinen ligger alltid en eller två veckor efter den mjuka, och ofta i samband med en annan deadline.

4.2 Att missa en hård deadline

Ett kodpar som missar en hård deadline blir kallad till ett uppföljningsmöte med obligatorisk närvaro för att diskutera anledningen och eventuella påföljder. Undvik att missa hårda deadlines!

5 Academic Honesty and Integrity

Honesty and integrity are of utmost importance.

These goals are not at odds with being resourceful and working collaboratively. You should be resourceful and you should discuss your work in this course with others taking the class.

However, you must never misrepresent the work of others as your own. Nor may you ever parrot explanations of others, or paint insights of others as your own.

When helping others – as you should, also for your own benefit – avoid doing their work for them – help them get to the point where they are able to do their own work.

If you have taken ideas from elsewhere or used code sourced from elsewhere, you must say so with utmost clarity in the documentation of your assignment.

When in doubt, ask Tobias.

Make sure you have familiarised yourself with the rules of plagiarism at the department and the university.

6 FAQ

Q: Jag har delar av IOOPM från före 2013 kvar! Hur skall jag göra?
A: Om du läste kursen innan den gjordes om 2013 så ska du göra olika saker beroende på vad du har kvar. Oavsett vad bör du börja med att skicka ett mejl till Tobias och berätta vad du har kvar, och att du har för avsikt att bli klar med kursen i år.

Om du har kvar enstaka inlämningsuppgifter i C (två eller färre) eller Java (två eller färre) så kan du göra dem nu. Ha alltid med uppgiftsbeskrivningen eftersom årets assistenter kanske inte vet vad en uppgift gick ut på. Saknar man fler än två uppgifter i C (eller Java) måste man göra om hela Fas 1 (eller Fas 2). Samma krav för att klara av kursen gäller som för nuvarande studenter.

Om du har kvar någon av tentorna kommer examineringen ske i två steg. Först implementerar du en av kursens senare inlämningsuppgifter – C-tentan motsvaras av Lagerhanteraren 2.0 (notera att uppgiften bygger på en tidigare uppgift som du får implementera också), Java-tentan av valfri uppgift från sprint 5. Du hittar kraven för uppgifterna här. När du är klar (och har meddelat det) kommer du att kallas till en muntlig examination där du får relatera din kod till några av kursens mål.

Vid redovisning kommer vi att gå igenom slumpvis valda mål som du måste kunna diskutera utifrån din lösning. Du skall klara av fem mål av upp till sju.

Q: Hur anmäler jag mig till kodprovet?
A: Det kommer en länk till anmälan i ett meddelande i Piazza. Detta meddelande skickas också vidare till din studentadress.

Q: Vilken grupp är jag med i?
A: Grupperna postas i Piazza och uppdateras löpande. Vi får uppgifter om registrerade studenter stötvis vid terminens början och det går därför knackigt ibland att bli instoppad i en grupp.

Q: Jag är inte med i någon grupp!
A: Maila Gustaf.

Q: Jag har inte något login i AU-portalen!
A: Maila Gustaf.

Q: Jag har inte tillgång till Piazza!
A: Maila Gustaf.

Q: Hur länge gäller delresultat på kursen som inte har rapporterats in i LADOK/UPPDOK?
A: Avklarade kodprovsfrågor gäller till nästa kurstillfälle. Vad gäller enskilda mål gör vi en fall-för-fall-bedömning. Om du saknar färre än 10 mål från föregående tillfälle får du normalt tillgodoräkna dig dina tagna mål nästa år (= starta med dem avklarade). Läs mer här

Q: Får man komma förbi er på rummet och fråga?
A: Ja! Tobias sitter (2018) i rum 1356.

Q: Räknas det som fusk att hjälpa en annan student som kört fast med programmeringen?
A: Att hjälpa någon som kört fast att komma vidare räknas inte som fusk. Vi uppmuntrar till samarbete och framförallt till diskussion kring hur man kan lösa ett problem. Att skriva någon annans kod åt dem är inte att hjälpa dem! Att dela sin lösning med någon annan (utöver vad som krävs av uppgifter i kursen) räknas som fusk! Att passivt dela sin lösning på GitHub (etc.) är inte förbjudet så länge som ingen plagierar den.

Q: Jag är borta under en labb! Vad gör jag?
A: Förutom de första 6 labbarna som startar upp kursen är labbar inte obligatoriska. Du skall gå på labbar för att redovisa. Initialt har vi planerat in ca 30 labbar, så om du missar någon spelar det ingen roll.

Q: Jag har en idé – vill ni höra den?
A: JA!

Q: Why are these course pages a mix in Swedish and English?
A: I am in the process of translating the material for this course from Swedish to English. The reason for this is to be able to have non-Swedish speaking TAs on this course. This transition will be gradual, meaning that these pages are sometimes in Swedish, sometimes in English and sometimes a funky mix.


Questions about stuff on these pages? Use our Piazza forum.

Want to report a bug? Please place an issue here. Pull requests are graciously accepted (hint, hint).

Nerd fact: These pages are generated using org-mode in Emacs, a modified ReadTheOrg template, and a bunch of scripts.

Ended up here randomly? These are the pages for a one-semester course at 67% speed on imperative and object-oriented programming at the department of Information Technology at Uppsala University, ran by Tobias Wrigstad.

Footnotes:

1
In the course’s initial instalment, we naively allowed any code to be used in demonstrations prompting students to search for code rather than write their own, or spending lots of time trying to write a minimal program that could be used to demonstrate a maximal number of achievements. While there are merits to both these approaches, we are seeking to teach how to write imperative and object-oriented code, which is why we added the requirement of evidence in the form of assignments from the course.

Author: Tobias Wrigstad

Created: 2018-09-18 tis 11:10

Validate