Vad vi jobbar med när vi “är lediga”

Hmm, vi hade en diskussion med två studenter i går om varför vi inte kunde lägga så mycket tid i en kurs (obs, inte en av våra kurser) som de önskade. Studenterna skojade och sa “ni är ju ändå lediga”. Underbar och relevant fråga.

Vi båda var schemalagda 3 timmar per vecka (vardera) i kursen. Dock har vi lagt ca 20 timmar var per vecka i kursen. Det sista har gått ut lite över den produktion av material vi har att ta fram inför våra kurser i höst. Vi sade till studenterna att vi halkar efter hela tiden och behöver fokusera på “våra” kurser.

Efter diskussionen med studenterna tänkte Rikard och jag att vi för skoj skull summerar vad för publikt material vi gjort sedan 2016-08-01. Detta vid sidan om vårt egentliga jobb (att hålla kurser):

DVD-filmer: 48 st

Läroböcker: 5.5 böcker

Böcker med källkod: 3 böcker

Hur kom vi fram till detta? Jo, följande är gjort sedan 2016-08-01:

Böcker (text på en wiki): 3890 A4-sidor

Presentationer: 251 stycken, med sammanlagt 3894 sidor

Videofilmer: 620 stycken, sammanlagt 79.5 timmar

Källkod: 101504 rader publik källkod

Pod-avsnitt: 25 stycken

Bloggposter: 41 stycken svenska, 4 stycken på engelska

Vi har ovan inte räknat med material som rättnings-script, lösningsförslag (till handledare) o s v.

För att göra detta mer visuellt har vi överfört detta till böcker (en genomsnittlig programmeringsbok med fokus på Java från Studentlitteratur har ca 700 sidor) och DVD-filmer (långfilm på 1 timme och 40 minuter). Det är detta vi presenterade i början.

Som kuriosa ger detta ett snitt per arbetsdag(464 arbetsdagar) på:

Böcker (text på en wiki): 8.4 A4-sidor

Presentationer: 0.5 stycken, med  8.4 sidor

Videofilmer: 1.3 stycken,  10.3 minuter

Källkod: 218.8 rader publik källkod

….detta gör vi alltså dagligen utöver att hålla kurser 🙂

 

Advertisements
Posted in Uncategorized | Leave a comment

Ego-tripp, kommentar från tidigare student

Henrik fick via ett socialt nätverk ett meddelande från en tidigare student.

“Vill bara out of the blue rikta ett tack till din och Rickards undervisning som gjorde programmering kul och greppbart! Har snart jobbat två år som systemutvecklare och det är fan det bästa jobbet jag kan tänka mig, så sjukt gött att sitta och koda varje dag. Så hade det nog inte blivit om inte ni gjorde ämnet spännande! Tack!”

Det är sådant som gör detta jobb kul. Inte att få meddelande som detta, även om det så klart är kul, utan att ha påverkat en persons liv till det bättre.

Detta trots alla klagomål vi haft på studenten gällande musik. Studenten gillade och kanske fortfarande gillar Toto. Kom igen, Toto!

… och bara så ni vet, Rickard stavar sitt namn Rikard.

Posted in feedback, Uncategorized | Leave a comment

Intervju med Niclas Nachtweij

Vi har idag intervjuat Niclas Nachtweij, en tidigare student, som jobbar på Hypergene AB. Fokuset hamnade i dag lite mer på vårt program (Systemvetenskapliga programmet) på Göteborgs Universitet än vanligt.

Intressant för oss som jobbar på programmet var att höra att Niclas tycker:

  • det vore bra med fler tekniska kurser
  • det är om man får lära sig flera programmeringsspråk
  • det är viktigt att kunna ett språk ordentligt
  • inte använder någon särskild utvecklingsmetod på jobbet
  • viktigaste egenskapen hos en lärare är engagemang och förmågan att göra ämnet roligt

Intervjun finns här: https://juneday.podbean.com/e/intervju-med-niclas-nachtweij/

Name: Niklas Nachtweij

Age: 31

Education: Systemvetenskap, Göteborgs universitet

Funniest moment in your carrier: Livedemo för en kommunledning som efter så mycket teknikstrul blev en parodi. Det är roligt på samma ont-i-magen-sätt som The Office, åtminstone såhär i efterhand.

Main programming language: TSQL, Python

Favorite editor: Sublime

Favorite datatype: Integer

Favorite annoyance: Kod som inte är indenterad.

Wish I knew how to…:Hur man manipulerar tiden så att jag fick loss mer tid på dygnet och hann läsa alla intressanta böcker som jag stackat upp med. Närmast, ”Enlightenment now” av Stephen Pinker.

OO, functional, imperative… or?: Det beror på syftet, måste jag välja så är det OO.

Posted in pod | Leave a comment

Nytt material om signaler

Vi har äntligen ™ skrivit lite om signaler. Detta kommer att tas upp i TIG167 i höst men om vi får göra om kurserna här på programmer kommer det komma in i andra kurser tidigare i programmet

 

Posted in TIG167 | Tagged | Leave a comment

Nytt material om “libraries” i C

Vi har skrivit material (text, övningar, video, pdf) till vår C-bok:

 

 

 

Posted in TIG167 | Tagged , | Leave a comment

Nytt material om Java

Under maj månad har vi tagit tag i vår backlog och skapat föreläsningar och föreläsningsfilmer till vår bok Programming with Java som används bland annat i kursen TIG015 på GU. Bland annat har vi kompletterat följande kapitel med filmer:

Arbetet fortlöper, varför denna post kommer att uppdateras i takt med att mer material tas fram. För den som vill ha en överblick över materialet i boken, ta en titt här:

Enjoy!

Posted in Uncategorized | Tagged , , , | Leave a comment

Vi förstår inte heller OOA&D

Bakgrund

Vi har fått frågor om analys och design utifrån en bok om en metod för OOA&D, utgiven på studentlitteratur. Då läraren hänvisat till boken och studenterna säger att de inte förstår boken och frågade oss, så läste vi boken för att förstå. Vi ville inte ge svar som går emot boken, och därigenom går emot vad läraren säger, varför vi läste boken i syfte att försöka förstå och förklara den.

Dock förstod inte heller vi boken. Vi tar här bokens exempel med ett konferenssystem som “designats” som utgångspunkt för en diskussion om varför vi inte förstår.

Vi har spelat in ett pod-avsnitt också: Vi förstår inte heller OOA&D-boken

Exempel från boken som inte heller vi förstår

Vi börjar med det designade klassdiagrammet (ett urval) för konferenssystemet.

Klassdiagram       

Konferensplanering

Klassbeskrivning från boken

Nedan beskrivs klasserna (i boken under rubriken “Klasser”) i vad som beskrivs som en “specifikation”. Specifikationen specificerar “de klasser som innehåller väsentliga attribut och icke-triviala operationer”. Återigen har vi gjort ett urval enligt klassdiagrammet ovan.

Person

Syfte: är att “Registrera basupplysningar om alla inblandade personer och aggregera varje persons konferensroller”.
Attribut:

  • Efternamn
  • Förnamn
  • institution
  • adress
  • e-mail

Operationer:

  • Skapa person
  • Skapa roll(!)

Deltagare

Syfte: “Registrera människor som kommer att delta i konferensen”.
Attribut:

  • datumregistrerad
  • tillstånd (Vad är det?)

Operationer:

  • Skapa deltagare
  • Skapa funktion(!)

Funktion

Syfte: “Registrera roller som en deltagare kan spela”.
Attribut:

  • föreslaget datum
  • tillstånd (Vad är det?)

Klassen Funktion saknar operationer. (se vår kommentar nedan om varför vi tycker det är märkligt)

Kommentar

Vi tycker det är oklart vad som menas med “registrera” (se syftena för klasserna Person, Deltagare och Funktion). Designen enligt klassdiagrammet är också något vi har frågor kring. Några designfrågor:

  • Enligt klassdiagrammet så består en Person, förutom kontaktuppgifter, även av noll till många Roll:er. Klassen Roll finns inte med i klasspecifikationen dock.
  • Enligt klassdiagrammet så består en Deltagare av noll till många Funktion:er. Vad skillnaden mellan en Roll och en Funktion är framgår inte av beskrivningarna.
  • Enligt klassdiagrammet så är Roll en basklass som ärvs ned till Deltagare, Författare och Bedömare. Dock är det endast Deltagare som har en lista med Funktion:er.

Här är klassdiagrammet igen (för referens):

Konferensplanering

Översatt till Java-kod (ett försök)

För att försöka förstå designen utifrån klassdiagrammet och klasspecifikationen, så ger vi oss på att tolka designen och skapa lite kodexempel. Vad annars skulle en design syfta till, än till att vara underlag till koden som skall skrivas? I Java-kod skulle skapandet av en Person med rollen Författare kunna se ut så här, givet klassdiagram och klasspecifikationen:

// Hur skulle man kunna skapa en Person med rollen “författare”?

// 1. Skapa en Person och registrera Roll:en Författare på den:

Person förf = new Person(“Anna”, “Bok”, ...);
// Vi tolkar "operationen" "skapa person" som konstruktor

// 2. Skapa rollen (författare):

Författare roll = förf.skapaRoll(FÖRFATTARE);
// Av någon anledning så finns "operationen" "skapa roll"
// i klassen Person...

// 3. Registrera rollen, men då måste vi ha en Funktion
// och eftersom blott Deltagare kan skapa funktioner, så får vi
// skapa en Deltagare:

Deltagare d = förf.skapaRoll(Deltagare);
Funktion f = d.skapaFunktion();
// Nu kan vi medelst funktionen registrera rollen för personen:
f.registreraRoll(roll, förf);

// Nej, det här blev ju rörigt?!
// Skapa en Deltagare för att skapa en Funktion för att registrera 
// Roll:en Författare på en Person? Känns inte intuitivt, direkt...

Problem med designen (som vi förstår den)

När vi skrev kod för att skapa en Person med Roll:en Författare, uppdagades:

  • Bara Funktion:er kan “registrera” Roller
  • Bara Deltagare kan skapa Funktion:er (och har av någon anledning en hel lista på Funktion:er vid behov)
  • Personer kan skapa Roller, så för att skapa en Person med rollen Författare måste vi:
    • 1. Skapa en Person p
    • 2.1 Be p skapa en Roll r1 av typen Deltagare
    • 2.2 Be p skapa en Roll r2 av typen Författare
    • 3. Be r1 skapa en Funktion f
    • 4. Be f registrera rollen r2Person p

Svårigheter för oss att förstå diagramm och specifikation

Vår bedömning är att det är mycket svårt att förstå klassdiagrammet och “specifikationen” av klasserna ovan. Den “specifikation” av klasserna som ges talar om attribut och operationer. Attribut betyder vanligtvis “instansvariabler” (t ex varje Person har olika e-postadresser, lagrade i objektens instansvariabel för e-post). Vad “operation” betyder har vi betydligt svårare att säkert avgöra genom att läsa boken. Boken talar ibland om “beteende” (hos objekt) och “funktioner” hos systemet. Nu finns också “operationer” som är listade tillsammans med klasserna. Vi har tolkat det som instansmetoder (dvs beteende) och inte statiska klassmetoder, eftersom det listas tillsammans med attribut som måste vara instansvariabler.

Nedan följer en lista på de saker vi har svårt att förstå i klassdiagrammet och “klasspecifikationen”:

  • Vad menas med “registrera” (från syftena med klasserna) – hur och var?
    • Varför ska klassen Funktion “registrera” roller som en Deltagare kan spela?
    • Eftersom klassen Funktion saknar “operationer”, hur kan den registrera roller en Deltagare kan spela?
  • Vad menas med attributet “tillstånd” som återfinns i klassen Deltagare och klassen Funktion?
    • Menas tillstånd som i “tillstånd från någon att göra något”, i så fall vad är det, vem gav tillståndet och hur gavs tillståndet och kan man bara ha ett tillstånd (att göra en sak)?
    • Menas tillstånd som i “ett objekts tillstånd”, vad kan det då vara? Ett objekts tillstånd är en funktion av värdet i objektets instansvariabler (i vart fall enligt den terminologi som används inom objektorienterad programmering). Att ha en instansvariabel som själv heter “tillstånd” blir då obegripligt.
  • Vad menas med “skapa” som i operationen “skapa person” i klassen Person
    • Menas konstruktor?
      • I så fall, varför har Person även operationen “skapa Roll”?
        • Har klassen Person en “factory method” för att skapa Roll-objekt?
  • Varför är inte klassen Roll med i klasslistan med specifikationer av klasserna?
  • Tittar man på klassdiagrammet så ser man att det finns tre sorters Roll:er eftersom man använder UML-notation för arv:
                       Roll
                   /    |      \
          Deltagare Författare Bedömare 

           Men bara Deltagare har association till Funktion.

  • Betyder det att klassen Person i själva verket enbart “aggregerar” Deltagare:s “konferensroller”?
  • Är Person i själva verket en basklass, så att Deltagare, Författare och Bedömare egentligen ärver Person och inte Roll? Eller ärver de från både Person och Roll? Hur ska vi tolka klassdiagrammet?
  • Igen, det blir svårt att förstå att klassen Funktions syfte är att registrera roller för Deltagare, särskilt eftersom Deltagare i klassdiagramet framställs som en sorts Roll – menas att Funktion registrerar till exempel rollen Deltagare för en Person? Se ovan om att registrera rollen Författare på en Person – Bara Deltagare har operationen skapa funktion, så vi måste alltså skapa en Deltagare för att skapa en funktion för att registrera rollen Författare på en Person… Whaaat?
  • Vad är attributet “föreslaget datum” i Funktion?
  • Vad är det för skillnad på en Roll och en Funktion? Varför är inte klassen Roll med i klassbeskrivningen?

Sammanfattning

  • Vi tror att vi inte förstår klassdiagrammet – vad är arv och vad är komposition?
    • Är det vi som inte förstår UML, eller är det en dialekt av UML som vi inte sett?
  • Vi tror att vi inte förstår syftet uttryckt i “registrera X” – t ex:
    • syftet med Funktion som var att “registrera roller som en Deltagare kan spela”
    • syftet med Person var att “registrera basuppgifter om alla inblandade personer”
    • Det är ju stor skillnad på att en klass “registrerar” det som lagras i objektens instansvariabler (attribut) som i fallet Person, och att en klass registrerar objekt av annan klass (t ex Roll) i ett annat objekt av en annan klass (t ex Deltagare) som i fallet med Funktion vars syfte det är att “registrera Roll:er Deltagare kan spela” (det blir ännu kostigare då en Deltagare genom arv är en Roll som ska registreras på en Deltagare)
  • Vi tror att vi inte förstår skillnaden på Funktion och Roll – Det är inte tydligt eftersom klassen Roll inte är med i “klasspecifikationen”
  • Vi tror att en Person bara behöver en lista på Roller och att Funktion inte behövs
  • Vi tror att vi inte förstår varför en Funktion inte har några operationer, trots att syftet är att “registrera roller”
  • Vi tror att vi inte förstår varför en Deltagare behöver en hel lista på Funktioner, då funktioners syfte är att registrera en roll
  • Vi tror särskilt att vi inte förstår varför bara Roll:en Deltagare har en lista på Funktion:er – eftersom Funktion ska registrera Roll:er så behöver man ju då skapa en Deltagare bara för att komma åt en Funktion för att t ex registrera Roll:en Författare på en Person
  • Vi tror att vi måste ha typer i klassdiagrammet för att förstå åtminstone vad attributen “tillstånd” skulle kunna representera (antagligen skulle vi ändå inte förstå, på grund av namnet “tillstånd” som vi förknippar med objekt)
  • Det är möjligt att det är översättningsproblem som ligger till grund för vår oförmåga att förstå, men vi förstår likväl inte klassdiagrammet
    • Om det är dåligt översatt så bör vi nog inte använda boken
    • Om det är korrekt översatt så kan nog vi inte rekommendera boken
  • Vi tror att vi blir förvirrade av terminologin som används i “klasspecifikationen”, t ex vad är skillnaden mellan:
    • “personer”, “människor”, “deltagare” i konferensen?

Vi skulle kunna skriva en liknande analys av andra exempel från boken, bland annat angående klassdiagram för ett bankkonto men det lämnar vi till en annan gång.

Utifrån vårt försök att förstå boken, så kan vi inte annat än konstatera att antingen är vi för dumma för att förstå boken (då får gärna någon som förstår boken hjälpa oss att förstå) eller så syftar boken till något annat än att förklara OOA&D. I alla fall sådan OOA&D som leder fram till något som går att implementera. Oavsett så får vi tyvärr hänvisa till någon annan, vad gäller boken och frågor kring den. Vi förstår inte vad bokens “design” syftar till och i synnerhet inte hur designen går att implementera i kod (om man inte har tur och gissar eller tolkar designdokumenten “rätt”).

En annan sak som vi saknar är själva designhantverket. Vi har alltid trott att design är en process för att koden som implementerar designen skall bli så bra som möjligt utifrån objektorienterade principer. Den “design” som ges i exemplet ovan är så ofullständig (och för oss obegriplig) att den måste tolkas och koden kan ju då bli hur som helst, beroende på hur man tolkar den. Programmerarna måste ju designa sina klasser utifrån den ofullständiga “design” som ges i boken. Frågan vi ställer oss då är:

“Vad ska programmerarna med bokexemplets ofullständiga (och i vårt tycke otympliga) design till?”

Vi får tyvärr säga till er studenter som frågat (bland annat om exemplet ovan) om boken, att vi inte heller förstår boken. Då boken tyvärr inte innehåller ett enda kodexempel, är det svårt att med säkerhet säga att det är lämpligt, lätt eller ens är möjligt att implementera designen, eller ens om detta är syftet med designen.

Kanske är tanken med bokens metod att programmerarna under implementationen vid behov skall göra om designen från grunden (kanske med hjälp av någon annan metod för OOA&D) så att den uppfyller såväl objektorienterade principer som kravspecifikationen.

Posted in Uncategorized | Tagged , , , , , , , , , , , , | Leave a comment