Planering och Uppdatering av Programmeringsteknik för D, 2015∗

Transcription

Planering och Uppdatering av Programmeringsteknik för D, 2015∗
Planering och Uppdatering av
Programmeringsteknik för D, 2015∗
Björn Regnell
22 augusti 2015
1
Förutsättningar
Per Holm går i pension sommaren 2015 och Björn Regnell ska överta kursansvaret för EDA016
Programmeringsteknik för D inför höstterminen 2015. Kursen har mycket goda resultat i kursutvärderingar och de nyantagna D-teknologerna är i allmänhet mycket motiverade inför denna
för utbildningen så viktiga kurs. Dock finns ett antal utmaningar och lärdomar, sammanfattade
nedan.
1.1
Utmaningar och lärdomar
• Spridningen i förkunskaper är speciellt stor bland D-are. Många har redan skrivit stora
system i Java, medan många inte har programmerat alls.
• Spridningen i förmåga är stor och vissa har, ibland trots förkunskaper, svårt att komma
över vissa lärandetrösklar.
• Många av de med höga förkunskaper känner sig inte tillräckligt utmanade, speciellt under
de första 3 veckorna då dessa fokuserat på de som aldrig förr programmerat.
• Ibland diskuteras D-teknologernas specifika ”programkultur” och förekommande attityder
som kan vara problematiska: ”Det är coolt att inte behöva plugga”, ”Jag vågar inte fråga av
rädsla för att verka dum inför de som redan kan allt”. D-sektionen och studierådet har en
speciell åtgärdsplan för att påverka attityderna bland D-are.
• Institutionens har alltmer begränsade resurser och grundutbildningsbudgeten går med
förlust. Rättning av kontrollskrivningar tar tid. Kursen har även haft olika sorters extraföreläsningar (snabbföreläsningar, seminarieföreläsningar), som är uppskattade men ökar
kostnaden.
• Tidigare år har det varit låg deltagandegrad på övningarna som har skett utan datorer med
”pappersprogrammering” – ibland under 50%.
• Inför 2015 kommer D-are oc C-are separeras då C-arna ska läsa E-arnas kurs och EDA016
blir därmed en kurs bara för D-are (och ett fåtal, max 10, W-are som läser kursen valfritt i
senare årskurs).
• Kurserna EDA016 (tidgare för D, C, från 2015 bara för D), EDA011 (Bme, N), EDA017
(E, I, C från 2015), EDA501 (M), har olika labbserier. Ska vi synka oss och underlätta
återanvändning mellan kurserna?
Detta planeringsdokument är i slutgiltig version och uppdateras ej mer; se utfall här: http://cs.tlh.se/eda016
Synpunkter, tips och idéer mottages tacksamt: bjorn.regnell@cs.lth.se
∗
1
1.2
Enkät om förkunskaper
Per Holm har genom åren genomfört enkäter angående förkunskaper. Enkätfrågorna och en
sammanställning av resultaten återfinns nedan.
1.2.1
Frågor
Har du programmerat innan du kom till LTH?
o
o
Ja
Nej — du behöver inte svara på fler frågor.
Hur många program har du skrivit (totalt, inklusive alla små övningsuppgifter)?
o
o
o
mindre än 5
5–20
mer än 20
Hur stort var det största program du har skrivit?
o
o
o
1.2.2
mindre än 50 rader
50–500 rader
mer än 500 rader
Statistik
Nedan sammanställning av enkät från tidigare år visar fördelningen i förkunskaper.
50
45
40
35
lite; 15%
30
25
mellan; 30%
mellan eller
mycket; 53%
20
15
aldrig; 32%
mycket; 23%
10
5
0
aldrig programmerat
programmerat lite
n < 5 || loc < 50
2010
2011
programmerat mellan
(alla andra)
2012
2013
programmerat mycket
n > 20 && loc > 500
2014
Figur 1: Förkunskaper bland D:are under åren 2010-2014. Staplarna visar antal individer fördelat
på 4 olika grupper (aldrig, lite, mellan, mycket). Tårtdiagrammet visar total procentuell fördelning
av förkunskaper bland D:are under åren 2010-2014.
2
2
2.1
Uppdateringar och kursutvecklingsidéer
Planerade uppdateringar 2015
• Sträva efter hög ambitionsnivå hos studenterna. ”Det räcker inte att bara koda på labbarna om man ska bli en bra utvecklare”. Nu när det bara är D-are så vill jag följa upp
D-arnas stora motivation för kärnämnet med att höja ambitionen och stimulera till mer
kodning och inriktning mot att lära sig så mycket det går. Bjud in nya studentföreningen
Code@LTH att prata på första föreläsningen och stimulera till kodning på fritiden. Höj
ambitionen i labbarna, uppmuntra till frivilliga extrauppgifter etc.
• Övningar blir resurstider i datorsal. Övningar utan datorer byts ut mot resurstider i
datorsal. Studenterna kan arbeta med och fråga om hjälp angående det som är viktigast
för dem just då, vare sig det gäller övningar och laborationer. Detta har redan använts i
EDA017 och EDA011 med goda resultat.
• Inlämningsuppgift utan rapport. Inlämningsuppgifterna blir en ”storlabb” utan speciell
skriftlig rapport. (Det räcker med en inlämnigsuppgift eftersom det även finns grupplabbar
– se nedan.) EDA016 har till och med 2014 haft ett speciellt lärandemål kring rapportskrivning och inlämningsuppgifterna har examinerat detta lärandemål genom att de har granskats
ur textkvalitetssynvinkel. Träning i att skriva rapporter kommer i framtiden att, i samband
med den av UKÄ-granskningen föranledda omläggningen av D-programmet, ske i andra
kurser, bland annat en kommande kurs som behandlar utvärdering av programvarusystem.
Studenter har också framfört önskemål i kursutvärderingar om att inlämningsuppgifterna
mer skulle granskas ur programmeringsteknisk synvinkel.
• Samarbetskultur. Det skulle vara fint om man kunde vända svårigheten med spridning i
förkunskaper till något positivt genom att få till en samarbetskultur där de som redan kan
mycket delar med sig av sina kunskaper till de som ännu inte kan så mycket. Detta knyter
an till hur mjukvaruutveckling sker i ”verkliga livet”, där alla utvecklare behöver hjälpa
varandra att lära sig alla nya api:er som hela tiden utvecklas och där all kodning sker i ett
livslångt lärandesammanhang. Dessutom så lär du dig mer genom att träna på att hjälpa
andra att lära.
– Samarbetsgrupper. Eftersom det genom åren verkar vara ungefär hälften som programmerat innan (se rosafärgade i tårtdiagrammet i förkunskapsstatistiken ovan), så
skulle man kunna formera samarbetsgrupper med 2 personer som redan kan ganska
mycket (rosa) och 2-3 personer som inte ännu kan så mycket (gröna eller gula) och
organisera arbetet så att ett grupplärande sker.
– samarbetskontrakt Reglerna för beteendet i samarbetsgrupperna beskrivs i ett samarbetskontrakt som signeras och lämnas in. Exempel på grundregler för samarbete i
kontraktet: Komma i tid till möte. Hålla deadlines. Alla får komma till tals. Hjälpa
varandra med att förstå teori, begrepp och mönster. Inte hjälpa varandra genom att
lösa uppgifterna åt varandra. Det är inte ok att ”ge bort” lösning etc.
– Följa upp samarbetet Gör enkät för att kolla hur det fungerar i grupperna. Hjälp till de
grupper som inte fungerar: boka möte med kursansvarig och redovisa handlingsplan.
– Grupplabbar. De labbar som är större än att de normalt går att hinna med på en 2h
labb kallas Grupplabbar (2 av 11). Dessa innehåller delar som på ett naturligt sätt kan
delas upp mellan 4-5 gruppmedlemmar och görs i grupp.
– Kamraträttad, diagnostisk kontrollskrivning. Inför kamraträttad kontrollskrivning i
halvtid (inspirerat av hur Anna och Roy gör), där kontrollskrivningens tentabonus bi
ges som samarbetsbonus till gruppen genom att medelvärdesbilda:
3
n
P
bi
.
i=1
n
• Motivera OOP och Java. Vid möten med SRD framfördes speciellt önskemål om att
bättre förklara och motivera hur och varför objektorienterad programmering och ärvning
används i praktiken. Några studenter tycker att Java är ”mossigt” och ”pratigt” och uttrycker
åsikten att vi är ”gammeldags” som använder Java.
• Kompilera från början. Programmering vid datorer redan från början, inte som tidigare år
vänta till vecka 4. Dessutom börja programmera med kodeditor och javac i terminalfönster
så att det blir tydligt vad en kompilator gör, och kör igång med Eclipse i vecka 4.
– Ny ovn1hello. Utveckla ny första övning som tränar kompilering från terminal med
helloWorld och helloParameter.
– Ny lab1quiz. Utveckla ny lab som om ett enkelt frågesportprogram där inga andra
färdiga klasser än Scanner och filinläsning behövs som går att köra från terminalen
och kompileras med javac.
• Utmaning för de som redan ”kan allt” i kursen: Kanske erbjud att göra vissa av de individuella labbarna i Scala. Vilka labbar? Hur kolla att de som väljer detta redan ”kan allt” och
säkerställa att man inte tar sig ”vatten över huvudet”? Intervjuer/munta? Max 10 ”platser”?
Peka på resurser på nätet för självstudier. Rekommenderad litteratur: Horstmann: ”Scala
for the impatient”.
2.2
Idéer till uppdateringar 2016
• Införa Scala? Problem: Kursbok? Beroende med fortsättningskurser? Kan man börja med
Scala i Lp1 men även lära sig Java i Lp2?
Input från Jacek: Om de redan kan Scala så kan nya obligatoriska funktionsprogrammeringskursen på 6 hp få en flygande start då man inte behöver lägga tid på att lära sig själva
språket innan funktionsprogrammeringsbegreppen och -principerna kan läras; nuvarande
valfria kursen i funktionsprogrammering på 7,5 hp lägger en hel del tid på att förklara
Haskell innan man kan komma igång med själva funktionsprogrammeringen. Å andra
sidan är ju Haskell ett renodlat (”pure”) funktionellt språk medan Scala inte är ”pure” på
funktionsprogrammeringssidan (medan Scala är mer ”pure” än Java på OO-sidan).
• Använda fler datastrukturer? (Idé från Görel mfl.) Utöver ArrayList även använda Set
och Map i grundkursen så att man tränar på att tänka och använda vanliga datastrukturer
innan man sedan lär sig implementerar dem i fortsättningskursen. Scalas standardbibliotek
gör detta extra lätt för en nybörjare:
val capital = Map("Sverige" -> "Stockholm", "Danmark" -> "Köpenhamn")
• Använda trådar? (Idé från Roger mfl.) Morgondagens systemutveckling kommer i allt
större utsträckning tvingas anta utmaningen att försöka fylla cpu-trådarna med parallellt exekverande kod, och trådbegreppet kanske ges plats redan i första kursen, även om lösningar
på svårigheterna med jämlöpande programmering får vänta till senare kurser.
• Nya former av tentafrågor och rättningsprinciper? (Idéer från Gustav m.fl.) Göra kryssfrågor som testar begreppsförståelse. Leta fel i program. Lätträttade tentafrågor så att
tentarättandet blir billigare men tentorna ändå testar flera olika kunskaper. ”Kodkörkort”
innan tenta genom programmeringsprov vid dator: lös enkel uppgift på 20 min testar att
man är igång med sin programmering och kan debugga etc. Automaträttning av inlämningsuppgifter.
4
3
Översikt kursmoment och innehåll
Obs! Detta är planen men vissa ändringar kan behövas.
Teckenförklaring:
* = Obligatoriskt examinationsmoment, S1= Sandra/Patrik Lab1, P1=Per Holm Lab1
Lab = Examineras individuellt
Grupplabb = Görs i samarbetsgrupper, redovisas i grupp, det ska framgå vem som gjort vad
och redovisningen ska ha individuella delar
Inlämningsuppgift = Individuell större uppgift. Man kan välja mellan olika uppgifter. Man kan
välja att utöka uppgiften med fler delar. Detta förhandlas i god tid med den som ska godkänna.
KS = Kontrollskrivning, diagnostisk, kamraträttning, samarbetsbonus
T = Tentamen
lp.v
Förel.
Förel.
Resurstid, Övn
Lab*
Kontroll*
1.1
F1
F2
Ö1: (NY) javac, Hello World, Hello
Args
1.2
F3
–
1.3
1.4
F4
F5
–
F6
Ö2: (NY): Paket (package, import), kodfiler (jar på classpath, skapa jar), dokumentation (läsa, skapa javadoc)
Ö3: beräkningar klasser och objekt
Ö4:
Lab1: Quiz (NY): gissa talet och en enkel frågesport, allt i main med editor och
javac
–
1.5
F7
F8
Ö5
1.6
F9
F10
Ö6
1.7
F11
F12
Ö7
t.v.
–
–
–
–
2.1
2.2
2.3
2.4
2.5
F13
F14
F15
F17
F19
–
–
F16
F18
–
Ö8
Ö9
Ö10
Ö11
Extraövningar, extentor, uppsamling
2.6
2.7
F20
F21
–
–
Extraövningar, extentor, uppsamling
Extraövningar, extentor, uppsamling
Lab7: Maze (P6)§
Lab8: Vektor med patiens, Card (S6)
Lab 9 Grupplabb: TurtleRace (S8+S9)
Lab10: Life (S7)
Lab11 Grupplabb: Bildbehandling
(P8+P9)
—
Inlämningsuppgift individuell: Välj
mellan: Bank (SInl2) ELLER Mandelbrot (PInl2) ELLER Ritapplikation++
(P10) ELLER egendef.
t.v
–
–
4
Input från Studierådet, doktorander och labbhandledare
Lab2: Eclipse (S1)
Lab3: Använda klasser (kvadrat +
Event) (S2)
Lab4: Implementera kvadrat + felsökning (S3 + del av Sinl1)
Lab5: Implementera klasser, gissa tal
(S4)
Lab6: Implementera klass, Turtle, ColorTurtle (S5 + P5)
–
KS
T
Idéerna i detta dokument presenterades för SRD den 28 Maj 2015. Upplägget är även testat på
gamla labhandledare och doktorander. Följande synpunkter har förts fram:
1. De föreslagna förändringarna uppfattades som positiva, speciellt konceptet med samarbetsgrupper.
2. Att höja ambitionsnivån och ge mer utmaningar är bra. Gamla upplägget upplevs av många
som ”tråkigt i början”.
3. Gruppindelningen i samarbetsgrupper bör slumpas utifrån schemagrupper så att gruppmedlemmar i görligaste mån har samma schema.
5
4. Det kan vara bra att inte generellt öppna upp för labbgodkännande på resurstider – annars
fins en risk att folk gör labbar på resurstider istf på labbar.
5. Om bonus bara gäller till ordinarie tenta premieras de som inte skjuter upp sitt tentapluggande.
6. Bra om handledare och föreläsare försöker förklara mer om begrepp och principer.
7. Bra om övningar ”uppgraderas” till labbförberedelser. Det gör inte så mycket om de inte är
helt tydligt kopplade till labbinnehållet.
8. Idé: gör quiz (lätträttade flervalsfrågor) på resurstider (eller kanske i början av varje labb).
Det är nog bäst om dessa delas ut på papper på resurstiderna så att man får visa att man
klarat quiz och kryssa på första sidan i kompendiet under ny kolumn ”labbförberedelse
GK". Utmaning/kostnad: utveckla nya quiz som knyter an till övningarnas innehåll och till
labbar.
9. Tydliggör uppdelningen mellan ramverk (någon annans kod har kontrollen) och bibliotek
(din egen kod har kontrollen).
10. Inlämningsuppgift Mandelbrot: det svåra är koordinattransformeringen från komplexa
talplanet till pixelplanet. Om denna ska göras individuellt så kanske den kan göras lättare
genom att ge tips om hur man kan lösa transformeringen.
11. Inlämningsuppgift Bank: denna är mest stor men inte så klurig. Om den ska göras individuellt så kanske den ska minskas ner eller några delar göras valfria.
12. Det är viktigt att samarbetsgrupperna får stöd i hur de ska jobba. Kanske ska labbhandledare
fråga hur de delat upp arbetet med grupplabbar. Bra att kräva att grupperna ska träffas t.ex.
minst en gång i veckan och gärna på resurstiderna.
13. Saker att kanske lägga till på föreläsningarna: systemutveckling i praktiken; Stack Overflow; Github, Bitbucket, öppen källkod; krav, design, test, kvalitet ur användarens och
utvecklarens synvinkel; Terminaltrix Mac-terminal + Windows-terminal; javadoc
14. Synka DoD, Ptd och Datorstugan (niklas.karlsson.668@student.lu.se) och Unix-häftet.
(Lägga till ngt om Virtualbox, Github, Bitbucket på datorstugan?)
6