For jeg bruger i stigende grad Github Copilot i VS Code, som assistent. Github Copilot er ikke det samme som Microsoft’s Copilot, men en tjeneste, som kan hjælpe med at planlægge, skrive, forbedre og teste kode. Det betyder, at jeg skriver mindre og mindre kode selv og i højere grad designer systemet på et mere overordnet niveau.

Github Copilot er gratis for studerende og undervisere, og man kan vælge mellem forskellige sprogmodeller (GPT, Claude, Gemini, Grok m.m.). Der er desuden p.t. fire roller (modes), som man kan give assistenten i Copilot, nemlig Ask (Q&A), Planner, Agent og Custom. Jeg har mest erfaring med Agent-mode, som er en assistent, der både kan besvare spørgsmål, hjælpe med planlægning, ændre i min kode-base og åbne en browser. Hvis man dertil aktiverer “Bypass approvals”, kan assistenten også bruge andre værktøjer bl.a. selv køre kommandoer i terminalen. Dét er selvfølgelig på bekostning af visse sikkerhedsrisici.

Min fremgangsmåden er p.t.:

1. Afklare krav til systemet og formulere kravspecifikation (både funktionelle og ikke-funktionelle krav).
2. Afklare tekniske specifikationer. Hvilke teknologier og arkitekturer skal anvendes?
3. Tilføje overordnede ønsker til brugergrænseflade (UI).
4. Afklare projektplan -Hvad skal implementeres først? Hvornår er projektet færdigt?
5. Sæt agenten i gang med at udvikle og teste systemet ifølge kravspecifikation og projektplan.
6. Når første prototype er færdig, skal assistenten tjekke om alle krav er opfyldt (fx om koden er ren og lever op til principper for god kode) og om alle tests er godkendte. Dér bruger jeg en fast prompt i filen “tjek_projekt.md”.
7. Først her tester jeg selv systemet, og overvejer om interface og funktionaliteter er som jeg forventer. Hvis ikke skriver jeg med assistenten om evt. ændringer.
8. Jeg synkroniserer til Github og får systemet ud på en statisk webside (fx github-pages) eller deployer via host (Heroku).

Måske skal jeg have flere trin fx til at designe brugergrænseflade og funktionaliteter fx use-case diagram, user stories, bruger-rejse, skitser.

For at afklare krav til systemet burger jeg en fast prompt i filen “grillme_krav.md”, med følgende indhold:

• Opret filen documentation/kravspecifikation.md, hvis den ikke findes.
• Der skal udvikles et nyt projekt. Udspørg mig grundigt om formål, brugere, krav, platform, performance, sikkerhed, integration og andre relevante aspekter.
• Stil mig et spørgsmål ad gangen og stil uddybende spørgsmål, hvis svarene ikke er klare.
• Opdater kravspecifikation.md løbende undervejs ud fra svarene på spørgsmålene.
• Noter alle relevante oplysninger i kravspecifikation.md.
• Når vi er færdige, skal du tjekke, at alle aspekter er dækket, og at projektet er klart beskrevet.

Derefter har jeg en lignende prompt i filerne “grillme_tek.md”, grillme_ui.md” og “grillme_projektplan.md”, til at formulere teknikspecifikation, udseende og projektplan. Hvis der skal bruges kald til en sprogmodel i projektet, er det beskrevet i “LLM.md”.

Agenten kan selv oprette mapper og filer, skrive koden, initialisere afhængigheder og hente biblioteker. Den kan selv skrive tests, køre dem og fortolke resultaterne -også tests hvor assistenten åbner en browser og tester funktionalitet af knapper, tekstfelter og lignende interaktive elementer. Den kan formentligt også pushe til Github, deploye og kalde sub-agenter, men det ved jeg endnu ikke, hvordan man gør.

Alt i alt er langt det meste af min kodning ændret til systemdesign. Hvordan bliver man god til systemdesign? Gennem erfaringer med selv at implementere systemer, erfaringer med at designe systemer, kan man læse sig til det eller kan man ligefrem overtage andres (fx AI’s) tilgang?

Det er ikke uden en vis faglig sorg, at kodning lige så stille forsvinder ud af mit liv. Følelsen af at være en troldmand, der egenhændigt kan skabe (næsten) hvad som helst digitalt, forsvinder. Nu kan jeg til gengæld få en ide og se den materialiseret inden for et par timer. Jeg er stadig en troldmand, men måske den lidt ældre af slagsen, som nøjes med at lægge planer og lade andre (AI) udføre dem. Vil der stadig komme nye troldmænd i Verden, når de ældre troldmænd forsvinder?

1. Introduktion omkring børns og maskiners læring, og hvad er en model og målet med den? Hvilke brugs-senarier kan der være for modeller? (sundhed, robotter, sprog, anbefalinger, beslutningsstøtte m.v.)
2. Træne egen simple model med analoge midler og hovedregning: “Er det frugt?“
3. Opsamle centrale pointer.
4. Træne en billed-klassifier i Techable Machine: “Er det frugt?”
5. Opsamling på pointer.
6. Skitsere vigtige trin i konstruktion af en sprogmodel og karakteristiske træk.
7. Lade eleverne arbejde med at undersøge en sprogmodel mht. de nævnte træk.

Jeg har forsøgt at designe en aktivitet, som honorerer punkt 2, og lever op til en række krav:

1. Introducerer nogle af de tekniske begreber og metoder, som indgår i sprogmodeller.
2. Er på et niveau, hvor alle kan være med.
3. Er så hands-on som muligt.
4. Ikke tager for lang tid at afvikle.

Dét er en ret svær balance at ramme. Blandt andet er en grundlæggende struktur i sprogmodeller de neurale netværk, som er i mange lag og dimensioner og træningen kræver mange gentagelser. Det bliver hurtigt omfattende, abstrakt og tidskrævende at designe og træne et neuralt netværk -det er derfor man bruger en computer. Alle beregninger i aktiviteten skal desuden kunne løses af elever i hovedet, for det reducerer risikoen for black box.

Den væsentligste egenskab ved modellerne, at de kan forudsige. Derfor har jeg designet aktiviteten, så eleverne skal hånd-træne en meget simpel perceptron-model (uden bias), som kan forudsige om et objekt er en frugt eller ej (target). Objekterne tilgås som spillekort med tre binære egenskaber (features): Er formen rund/oval? Er farven blå? Er objektet produceret i Danmark (se billede).

De tre features er valgt fordi: en frugt er ofte rund, en frugt er sjældent blå og frugt eller ej er uafhængig af hvor den er produceret.

Kortene indeholder en blanding af objekter, som er frugter fx æble, og ikke frugter fx Lego. Eleverne arbejder i par og tager et kort frem ad gangen. Alle følges ad i starten, men eleverne arbejder efterhånden selvstændigt (faded guidance): De gennemgår et trænings-flow, herunder beregner vægtet sum, bestemmer output og opdaterer vægte, hvis der er uoverensstemmelse mellem kort og modellens forudsigelse (se billede).

Sammen med kortene introduceres de første begreber: trænings-data, model, vægte, træning.

Når alle kortene er brugt, skal eleverne gentage proceduren med kortene igen og igen, indtil modellen kan forudsige rigtigt fem gange i træk.

Derefter udleveres nye kort med objekter, som eleverne skal teste modellen på. Der er både frugter, som modellen kan forudsige korrekt (fx en fersken eller rød legoklods), og objekter, som den forudsiger forkert på fx en banan eller en blå blomme.

Opsamlingen kan introducere lidt flere begreber (præcision og bias), samt nogle vigtige principper:

• Modeller kan forudsige noget (frugt eller ikke-frugt).
• Modeller lærer at forudsige, ved at vægtene bliver tilpasset gennem træning.
• Præcisionen af forudsigelserne er afhængig af træningsdata (antal og variation fx hvis vi kommer med en blå frugt (blomme), forudsiger modellen nok forkert).
• Præcisionen af forudsigelserne er afhængig af modellen (bl.a. hvilke og antal af features; kombination af modeller i et neuralt netværk).
• Der kan være tendenser (bias) i træningsdata, som gør forudsigelserne unuancerede (vi har kun trænet på en slags frugter). Bias kan mindskes ved at bruge mere varierede træningsdata.
• Forudsigelsen kan ændres fra enten/eller til en andel (fx via softmax-lignende funktion).

There will be a test.. skal eleverne have opsamlende quiz?

En alternativ tilgang kunne være at forbinde eleverne i et netværk, hvor hver elev er en knude i netværket. Hver elev har sin egen vægt, og data sendes gennem netværket.

Dét kan hurtigt udvikle sig til kaos: Hvem skal opdatere vægtene? Skal alle følges ad? Hvad sker der, hvis nogen regner forkert? Elever ved kun hvad der sker hos dem selv og ikke i hele netværket fx kommer de ikke til at forholde sig til forudsigelsen.

For programmering er et kreativt håndværk, som tager tid at lære. Heldigvis er det blevet meget nemmere at være kreativ med IT. For eleverne kan nærme sig programmering uden at skrive kode.

Efter chatbots er kommet frem, først og fremmest repræsenteret af ChatGPT, kan eleverne i stedet beskrive, hvad et program skal kunne, og prompte en chatbot til at skrive et bud på programkoden.

De nye chatbots (fx ChatGPT 4o) er så gode til at skrive kode, at elever (et stykke hen ad vejen) kan prompte en interaktiv digital model frem. Claude’s Sonnet-chatbot har endda et interface, hvor prompt, kode og kørsel af koden vises i samme skærmbillede. Der er dog også chatbots på markedet, som p.t. ikke magter opgaven fx skoleGPT.

Eleverne kan opbygge en digital model gennem en række prompts. Det kræver præcise prompts at få specifikke forhold frem i modellen, hvorfor eleverne arbejder med prompt engineering.

Den kode, som chatbotten leverer, kan være skrevet i HTML, flyttes til en tekst-editor og vises i en browser. Koden kan også flyttes til et online-udviklingsmiljø som Trinket eller Replit.

En generel fremgangsmåde og nogle opmærksomheds-punkter nedenfor. Ordet “Modellen” henviser her til den model, som eleverne prøver at skabe, og ikke til den model, som ligger i chatbotten.

1. Eleverne/læreren skal vælge en del af et simpelt system fra faget, som de vil modellere. I biologi/kemi kan det være en kemiske reaktion eller en enkel biologisk proces fx rovdyr-byttedyr, molekyler, hormoner, del af et stofkredsløb o.l.
2. Lav en skitse af modellen og beskriv indholdet med tekst/pile.
3. Eleverne skal overveje, hvilke dele af systemet de vil begynde med at modellere.
4. Det er en fordel at modellere systemer, som er velegnede til agent-baserede modeller, som bygger på en objekt-orienteret tilgang. Det er svært at animere og få elementer i modellen til at ligne konkrete dele af verden fx konkrete molekyler, organer eller cellulære strukturer.
5. Begynd med en standard prompt, som beskriver hvilket kodesprog modellen skal skrives i, og hvad modellen overordnet skal simulere. Skriv at modellen skal opbygges gennem en række prompts. Rolle, kontekst, opgave, format og sprog kan strukturere prompten.
6. Brug versionering, så det er nemmere at holde styr på forskellene på de modeller, som bliver outputtet. Begynd med version 1.0.0. Hvis en outputtet model bliver forkert, kan man let gå tilbage til en bestemt version, som var mere korrekt.
7. Bed chatbot’en placere tekster i modellen. Bliv ved med at prompte indtil placeringerne og teksterne står korrekt. Beskriv den form, som hvert sted skal repræsenteres af fx kasse eller cirkel, samt deres farver.
8. Bed chatbot’en tilføje nogle af de agenter, som skal bevæge sig mellem stederne. Præciser farve, form og bevægelseshastighed for agenterne.
9. Udvid med flere egenskaber til og/eller interaktion mellem agenterne.
10. Udvid med brugerens muligheder for at interagere med modellen fx gennem knapper, slidere og evt. tekstfelter.
11. Udvid med flere agenter.

Produkter fra chatbots må aldrig stå alene, så eleverne skal reflektere grundigt over på hvilke punkter modellen afspejler virkeligheden (det faglige indhold), og på hvilke punkter den ikke gør. De bør også reflektere over de generelle muligheder og begrænsninger ved modeller.

De kan reflektere over hvilket fagligt indhold, der var let/svært, at få frem i modellen og hvorfor. En af pointerne her, vil ofte være, at en chatbot skal promptes meget specifikt og med meget kontekst, for at opnå et bestemt udtryk. De vil muligvis også komme frem til, at for mange ændringer på samme tid, ikke giver de ønskede resultater. I stedet bør variabel-kontrol udøves, så modellen forbedres trinvist.

Aktiviteten rammer flere læringsmål:

1. Modellering (dekomposition) af indhold fra faget.
2. Arbejde med prompting af chatbots, uden at målet er en tekst, hvorfor fokus på hurtige veje til et produkt og på snyd bliver mindre.

Jeg er spændt på, om eleverne:

• Magter at dekomponere det faglige indhold til en simpel model og skitsere denne. Måske kræver det et større fagligt overblik end forventet at vælge et system, som er velegnede til denne form for modellering. I så fald, må jeg støtte dem med forslag fx et simpelt kredsløb mellem hjerte, væv og lunger.
• Vil simulere systemer, som er så komplekse, at en chatbot ikke kan skrive et program, der fungerer. For eleverne kan ikke opdage eller rette fejl i koden.
• Tager magten over chatbotten eller chatbotten tager magten over eleverne. Vil de blot acceptere (delvist forkerte) forslag, som chatbotten kommer op med? Det kan kræve en del prompt-forsøg og tålmodighed at få en model til at se ud på en bestemt måde. Og det er svært at få dynamiske systemer i balance.
• Formår at jonglere med chatbot, HTML-dokument og browser til fortolkning af HTML.

Eksempel: Her er et eksempel, som er lidt mere avanceret, end jeg forventer af eleverne. Det er kønshormonerne GnRH, LH, FSH og testosteron, som udviser feedback på hinanden. Systemet er endnu ikke helt balanceret, og viser derfor nogle ret store udsving i testosteron-indhold.

Nogle af de prompts, som er brugt til at skabe eksemplet ovenfor:

1. Standard prompt (ikke vist)
2. …en række af flere prompts..
3. Flyt kassen med Testikler lidt til venstre. Udvid den hvide ramme for kredsløbet lidt til venstre og til højre. Udskil GnRH fra Hypothalamus, også når der ikke klikkes på knappen.
4. Testosteron skal sørge for, at der udskilles mindre GnRH og FSH og LH.
5. Gør den hvide ramme lidt smallere igen på højre og venstre side.
6. Udskil færre FSH og LH på grund af GnRH.
7. Begynd simuleringen uden hormoner. GnRH skal medføre færre FSH og LH frigivet.
8. Tilføj en legend hvor det kan ses hvad de hhv. røde, grønne, gule og sorte prikker repræsenterer.
9. Kasserne med hhv. hypothalamus, hypofysen og testikler skal forblive på deres x og y koordinater, men prikkerne skal passer bagved kasserne.
10. Ændr knappen “release GnRH” til “indspøjt AAS”. Når der klikkes på knappen skal der tilføres et ekstra hormon “AAS”, som er blåt. AAS skal tilføres til venstre i kredsløbet. ASS skal opføre sig ligesom Testosteron. På legend skal der tilføjes en blåt prik og teksten “AAS (kunstigt testosteron)”.
11. AAS skal have samme hæmmende virkning på frigivelsen af GnRH, LH og FSH, som Testosteron har.

Algoritmer er et forskningsfelt inden for datalogien, hvor man optimerer for tids- og pladsforbrug. En effektiv algoritme er mere besparende end en hurtig computer.

Nogle af de effektive algoritmer kører rekursivt dvs. kalder sig selv med et nyt argument. Rekursive algoritmer benytter en kalde-stak, hvor det sidste, som er lagt på stakken, også afvikles først (LIFO=last in, first out). Kommandoer som står før det rekursive kald, afvikles mens kaldestakken fyldes. Kommandoer som står efter det rekursive kald, afvikles mens kaldestakken tømmes.

Alternativt til en stak, bruges nogle gange en kø, hvor de sidste som er lagt i køen også afvikles sidst (FIFO = first in, first out). Køen kan udvides til en prioritets-kø, hver elementerne hele tiden skal sorteres efter værdi, så elementet med mindst værdi (minPQ) ligger først i køen.

De fleste event-drevne systemer som f.eks. Micro:bit og MakeCode Arcade bruger en prioritetskø til at afvikle funktioner. Når systemet registrerer en ny event, bliver den tilføjet bagest i køen, og tidligere tilføjede funktioner skal være færdige, før en ny kan afvikles. Der er undtagelser: Forever-funktionen får altid laveste prioritet og den indbyggede Pause-funktion sætter afviklingen af en funktion på pause og lægger den i en stak til pausen er slut. Dette program kan demonstrere det.

Der er mange sorterings-algoritmer, som hver har deres fordele og ulemper (fx selection sort, insertion sort, mergesort, quicksort, heapsort).

Der er mange søge-algoritmer (fx binær søgning, binære søgetræer). Binære søgetræer skal helst være balancerede (samme dybde til alle blade dvs. fra top til bund), hvilket kan opnås med rød-sorte binære søgetræer.

Grafer er samlinger af knuder forbundet af kanter. Om to knuder er forbundet, kan afgøres efter dybde-først-søgning. Korteste vej (sti) mellem to knuder kan kortlægges i en vægtet orienteret graf med Dijkstras algoritme eller i en uorienteret graf med bredde-først søgning (korteste antal kanter).

Den model af et biologisk neuralt netværk, som jeg har skrevet i JavaScript, kunne gemmes som en rettet vægtet graf, dvs. knuden er cellens soma, og linket (kanten) til en anden nervecelle er aksonet, som kan sende signal i een retning (deraf rettet graf). Aksonet kan være vægtet med en værdi, som repræsenterer synapsens følsomhed.

En rettet vægtet graf er ofte gemt i en datastruktur, hvor knuderne gemt i et array (adjacency list), hvor hvert element i arrayet indeholder en hægtet liste (linked list) af naboknuder, som knuden har en kant hen til jvf. kantens retning. Naboknuderne er gemt som objekter med værdier fx type, vægt m.v., og med en pointer til næste naboknude. Dvs. for index 2, kan man iterere over knude 2’s naboknuder ved at følge pointeren ned gennem den hægtede liste.

Et virkelig spændende kursus, og et helt nyt felt, som har åbnet sig på klem for mig, men nok ikke noget jeg kommer til at forfølge i større grad.

Input: “Skriv et bloginlæg, som handler om chatGPT”

Output: “ChatGPT er et spændende værktøj, der bruges til at generere chatbot-svar automatisk. Det er baseret på den kunstige intelligens teknologi kaldet transformativ prædiktion, der gør det muligt for chatGPT at lære og forudsige de mest passende svar på spørgsmål og samtaler.

En af de store fordele ved chatGPT er, at det kan spare virksomheder og organisationer for tid og penge, da det kan håndtere mange samtaler og spørgsmål på én gang. Dette gør det ideelt til at bruges som en del af en kundeservice-platform eller til at besvare spørgsmål fra brugere på en hjemmeside eller i en app.

ChatGPT er også meget nyttigt, når det kommer til at lære af tidligere samtaler og forbedre sin præstation over tid. Det kan for eksempel huske, hvilke spørgsmål der er blevet stillet før, og give mere præcise svar baseret på tidligere samtaler.

Derudover kan chatGPT også bruges til at generere tekst til andre formål, fx at skrive artikler eller nyheder. Dette gør det til et meget alsidigt værktøj, der kan bruges i mange forskellige sammenhænge.

Alt i alt er chatGPT et spændende værktøj, der kan hjælpe med at spare tid og penge, samt forbedre kundeservice og interaktion med brugere. Det er et nyttigt værktøj for alle, der ønsker at automatisere deres kommunikation og forbedre deres samtaler med andre mennesker.”

1. Planlægning kan inddrage udviklingsmodel (lineær fx vandfald eller iterativ fx SCRUM), markedsføringsstrategi fx via SOME, on/offline, flowcharts, ER diagrammer, undersøgelse af målgruppe (persona’er) og usecases, interviews, kravsspecifikation, sikkerhed.
2. Gennemførsel kan involvere prototyper, programmering (kontrolstrukturer), gestaltlove, farver m.m.
3. Evaluering kan involvere test og fejlretning, brugertest (fx tænkehøjttest).
4. Endelig kan der perspektiveres til innovation, brugeroplevelse eller forholdet til samfundet.

De fleste elever kan levere en forberedt præsentation, der kunne virke som om, at det er til en toppræstation. Men det er ikke meningen, at alle elever skal have 10 og 12.

Men med så lang forberedelsestid og mulighed for sparring i gruppe, skal der stilles store krav til det indhold eleverne præsenterer. Dertil skal der stilles uddybende spørgsmål, som ikke er for ledende, og som viser hvor godt eleverne er inde i relevante teorier, deres overblik, samt deres evne til at udtrykke sig præcist og i fagsprog. Det vil ofte tage nogle eksaminationer at spore sig ind på hvor det egentlige niveau ligger.

På en måde er det en eksamensform, som jeg rigtig godt kan lide, fordi den afspejler den måde man arbejder i faget. På den anden side er det en eksamensform, hvor eksaminator og censor kan komme på hårdt arbejde, fordi der skal spørges meget ind til elevernes viden, forståelse og kompetencer, for at det egentlige niveau kan vurderes.

Herefter skal eleverne arbejde med koden bag modellen (code). Her arbejder jeg selvfølgelig efter use-modify-create dvs. en progression fra at bruge koden til at finde og evt. forstå dele af koden fx hvor styres specifikke antal og egenskaber i modellen. Bedre er nok modify, hvor eleverne bliver bedt om at ændre mere eller mindre specifikke linjer eller egenskaber i koden. Er eleverne mere erfarne, kan de skabe ny kode, i første omgang i høj grad ved at copy-paste og tilpasse egenskaber fx til at skabe nye deltagere i modellen. Det niveau har jeg dog ikke nået endnu.

Jeg har taget NetLogo op igen og er endnu en gang positivt overrasket. Der er en stor fordel i at have interface, grafiske outputs i form af grafer, værdier og animation, og kode samlet i samme tjeneste. Alle delene kan gemmes, som en html-fil, som eleverne kan åbne i deres browser og dermed have adgang til alle delene.

Dertil er NetLogo agent-baseret dvs. bygger på traditionerne om objekt-orienteret programmering. Derfor er NetLogo velegnet til at efterligne fysiske processer med mange aktører fx. kemiske reaktioner, biologiske processer o.l.

Konkret er eleverne (biologi A) først blevet introduceret til NetLogo. Fagligt arbejdede vi med hormoner, herunder negativ feedback. Jeg fandt en simpel model af byttedyr-rovdyr (får og ulve), som hedder “Wolf sheep predation” og er en del af NetLogos bibliotek:

Eleverne arbejde med at forklare modellens opførsel ved forskellige indstillinger, at lave mindre ændringer i koden og reflektere over modellens muligheder og begrænsninger.

I næste forløb, om enzymer, havde vi lavet et laboratorie-forsøg med enzymaktivitetens sammenhæng med substratkoncentrationen. Enzymet i forsøget var catecholase, og vi prøvede med fem forskellige koncentrationer af substrat (1,2-dihydroxyphenol).

Da vi ikke kan se de involverede molekyler, havde jeg fundet endnu en færdiglavet model i NetLogo, “Enzyme Kinetics”, som netop gav en visuelt billede af enzymer, substrat, kompleks og produkt, hvilket jeg tror støtter elevernes forståelse.

Modellen modificerede jeg en smule, så den bl.a. viste en værdi for enzymaktiviteten (antal produkter dannet i de første 20 ticks), og jeg ændrede farven på ES-kompleks kurven fra rød (som også er farven på enzymet i animationen) til grå. Jeg sænkede også molekylernes hastighed og antallet af enzymer, så det blev nemmere at se deres opførsel.

Eleverne skulle igen forklare modellens udseende og opførsel: Hvad er de røde (enzym), grønne (substrat) og blå (produkt) klodser? Hvorfor falder indholdet af substrat? osv. og manipulere modellen, herunder efterligne vores laboratorie-forsøg (use). For at tydeliggøre, at nu gjorde vi det samme i modellen, som i labforsøget, skulle eleverne reflektere over sammenhænge mellem disse.

De skulle også ændre enkelte dele af koden (modify), antallet af enzymer og omrøringen (hvor meget hver agent bevæger sig pr. tick). Jeg kunne sagtens lave slidere i interfacet, som kunne styre antal enzymer og omrøring, men så havde eleverne ikke lejlighed til at ændre i koden. Måske her ligger en kommende opgave til eleverne: Lav en slider der styrer omrøringen (create).

Slutteligt skulle de reflektere over modellens muligheder og begrænsninger. Af muligheder fremhævede jeg, at (1) vi kunne se (modeller af) molekylerne, som blev mere konkrete, og dermed blev det nemmere at forstå hvad der skete, og (2) det lab-forsøg, som vi havde brugt 90 minutter på, kunne vi udføre på 2 minutter i modellen.

Eleverne virkede ikke specielt begejstrede for sekvensen, men jeg synes stadig, at den kombinerede biologi-faglighed og computational thinking ved at støtte elevernes forståelse for enzym-substrat reaktioner og deres indsigt i at koder kan ændre de digitale værktøjer, som vi anvender i undervisning og privatliv.

Det første kursus har givet mig en række metoder inden for interaktionsdesign og inspiration til at arbejde videre. Særligt tre områder tænder mig: grafisk facilitering, embodiment og design thinking.

Grafisk facilitering er sjovt. Jeg har altid tegnet meget, og det ville være rart at få tilbage, som en del af min praksis. Jeg bilder mig ind, at tegning formidler og fokuserer indholdet på en anden måde end ren tekst, men jeg har endnu ikke fundet en undersøgelse, der efterviser det.

Embodiment handler om at have kroppen med i undervisningen. Hjernen er ikke et isoleret organ, og skolen har nok en tendens til at overfokusere på de intellektuelle forhold og glemme kroppen. Kroppen sanser miljøet og kan interagere med det. Kroppen kan bruges som et kognitivt stillads til læring, og nogle anbefaler at undervisning skifter mellem refleksion og “mindful action” (1).

Mindful action kan ske på mange måder. Rollespil er en udbredt måde. Tværfaglighed og fremmede objekter eller lokationer kan inspirere til nye måder, at inddrage kroppen.

Design thinking (engineering?) betragter jeg som en del af computatioal thinking (CT), som handler om at overveje hvordan digital teknologi kan bruges (herunder hvordan det virker) og hvad det gør ved os og samfundet. CT konkretiseres i bl.a. mønstergenkendelse og abstraktion. En vej dertil kan være ved at arbejde undersøgelses-baseret på komplekse problemer (wicked problems) i en iterativ tilgang, som kendes fra design. Alle digitale produkter er frembragt gennem design thinking.

Design thinking ligner på nogle punkter naturvidenskabelig metode -begge er iterative. I design thinking er det designeren (og andre interessenter), der skal co-designe en løsning. I naturvidenskab er det forskeren, som skal tolke data ud fra logik. Design thinking evaluerer, mens naturvidenskaben af- eller bekræfter en hypotese. Det er der lavet mange flotte diagrammer af fx dobbelt-diamanten. Design thinking kan bruges i design af forsøg.

Nogle sekvenser, som kunne udvikle grafisk facilitering, embodiement og/eller design thinking kunne være:

• Forsøggange som storyboard eller rutediagram. Særligt velegnet ved gentagelser eller forgreninger
• Design-metoder i elevernes udvikling af forsøg. Trinvis forbedring.
• Brikker til rutediagrammer
• Udklippede kodebrikker
• Objekt-teater/bodygramming: Lad eleverne udspille projekter og programmer
• Mere krop i undervisningen fx gennem tværfaglighed, nye objekter eller lokationer
• Netlogo til use-modify-create
• Kode som brætspil
• Line Have Mussaeus, som bl.a. arbejder med Netlogo
• Scenarie- eller spilbaseret didaktik

Den overordnede pointe, som jeg har mødt, er at teknologiforståelse og informatik ikke skal være et programmeringskursus, men anvende give eleverne meta-strategier ifht. at anvende og analysere digitale produkter.

1. Larson, D. J. (2015). Don’t Forget About the Body: Exploring the Curricular possibilities of embodied pedagogy . Innov High Educ(40), pp. 331–344.

Netlogo har en ret letforståelig syntax. Der er få mystiske ord og tegn (fx er mange sprog fyldt med { } parenteser og semikolon-tegn) og ingen indryk (som kendes fra Python). Erklæringer og opdateringer klares med nøgleordet “set” og systemet er født med en tids-variabel (dt=1), som inkrementeres for hvert loop.

Mit konkrete forsøg omhandler simulering af logistisk vækst. Eleverne får udleveret en online model i NetLogo over eksponentiel vækst (dN = N*r*dt), som de skal forstå og skal modificere til at simulere en logistisk vækst (dN = (N*r_max*(1-N/K))*dt). Der plottes forskellige data mod tid fx antal individer, vækstrate, bæreevne). Simulationen er selvfølgelig ledsaget af nogle stilladserende spørgsmål, som sikrer faglig og taksonomisk progression.

Jeg har lavet samme system i Python, hvilket er meget let vha. Numpy biblioteket og platforme som fx trinket.io.

MEN.. NetLogo tillader implementering af ‘slidere’, så værdier som N(0) (start population), vækstrate, bæreevne m.v. kan manipuleres før eller under simuleringen. Det giver online Python ikke mulighed for (der findes et underbibliotek af Numpy, som ikke er en del af trinket.io).

NetLogo-applikationerne har jeg gemt i en onlineudgave, som hostes på en Github-side. NetLogo HTML koden er MEGET lang, så hverken et google-site eller github, kan vise hele teksten i HTML-filen, hvorfor ændringer bliver foretaget i notepad :-(, som derefter oploades til mit Github-repository og vises på siden.

Nu er jeg selvfølgelig spændt på hvad eleverne siger. Finder de det let at forstå og ændre koden? -De tog ret blandet imod opgaven. Givet de er 3g’ere i slutningen af skoleåret og gymnasiet, var motivationen ikke særlig høj. Ingen havde svært ved at løse opgaverne, men det var ret blandet hvor langt de nåede. Fx nåede de færreste opgaverne med forsinkelse indbygget i modellen. Nogen gav udtryk for, at det var sjovt..

Hele opgaven: https://raskrawen.github.io/Growth/

Senere fik jeg det råd, at lave en endnu mere grafisk model, hvor hvert individ er en prik. På den måde bliver det forhåbentligt tydeligere for eleverne at det er en population vi modellerer.

• lade min mobil op
• et klik med min mus
• køre en Arduino 
• køre en Arduino i Deep Sleep-Mode 

Apparatet måler spænding (i V), strømstyrke (i A), tid og akkumulerede eller afledte værdier af disse fx effekt (i W) og energiforbrug (i Wh). 1 Wh er lig 3,6 MJ (megaJoule). Det koster ca. 7 dollars (ca. 60 kr) på AliExpress.

Her måler den på en opstilling af en CO2-måler med OLED og wifi-kobling via Arduino (Wemos D1), som sender data hvert 10. minut.

Målingen viser et akkumuleret energiforbrug på 0,754 Wh på 1 time og 20 minutter. Det kan omsættes til en pris på 3 øre i døgnet og et CO2 aftryk på 11 gram CO2 i døgnet. Se nedenfor.

Min Arduino wemos D1 i kredsløb med CO2-sensor:

Er 11 g CO2 pr. døgn meget eller lidt? En dråbe i havet? Time will tell.