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