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?

4fMap. Et site, som kan lægge forskellige lag på kort fra openStreetmap, herunder tegne 3D kort.

µStepper: Et kort til stepper-motorer, som kan levere data tilbage til den enhed, der styrer motoren.

Castbox. Asbjørns podcast-service.

Akku limpistol -Asbjørns limpistol.

Great Big Story. Mini dokumentarfilm på YouTube(?). Slut med de lange dokumentarfilm?

Medier for alle, site som samler info om creative commons.

CC0 licens: under creative commons, licens der ikke kræver at der krediteres.

Pi for alle. Nyhedsbrev om Pi i undervisning. Meget materiale.

Puzzlebox/wall. Johannes sender tegningerne(?)

Min nye værktøjskasse fra Silvan

Podcast ideer: Historien om sommerskole.

Til næste år: Medbring få simple no-brain projekter. Lav podcast.

[post_grid id=”1715″]

Dette er ikke en komplet guide, da teksten i så faldt, ville blive temmelig omfattende.

Forsøg og begivenheder:
App’en “Live Now” streamer nemt fra Ipad til Youtube. En adresse og en kode, skal hentes fra videoadministration i YouTube og ind i app’en, og så håber man, at det ikke er malware -det har det ikke været endnu.
(Serverwebadressen er formentlig generisk, men streamnøglen er højst personlig)

YouTube-streamet kan indstilles til privat, skjult eller offentligt, og indlejres på fx en hjemmeside.

Fjernundervisning:
Jeg har i den forbindelse brugt OBS studio til at have mit eget skærmbillede, webcam og lyd på streamet. Og vil prøve at tilslutte en anden monitor og køre med udvidede skærme, hvor jeg kan styre OBS og Lectio m.m. på den ene, og streame den anden.

Jeg brugte YouTubes indbyggede chat-funktion med eleverne. Som så ofte er det dem, der har mindst brug for hjælp, som skriver mest.

Raspberry Pi:
En tredje mulighed for streaming er via Raspberry Pi 3. Jeg sloges nogle uger med den for at få installeret styresystem (Rasberian via NOOBS) og få skærmbillede. Et problem var, at en HDMI-adapter til VGA, ikke er et entydigt produkt, og jeg måtte igennem tre, før systemet nogle gange valgte en opløsning, så jeg kunne få et skærmbillede.

Derefter prøvede jeg lidt med styresystemet motioneyeOS, som er særligt til streaming. Det virkede ok, indtil jeg, med venners hjælp, fandt frem til hvordan IP-strukturen er sat op herhjemme. Min PI får ikke en unik IP-adresse, som jeg kan tilgå udefra.

Men jeg tænkte, at det måtte være muligt at sende mit video-signal til en server fx via OBS studio, og derfra sende det ud på www.

PI’en skal sættes op med trådløst netværk, kamera og ffmeg, som jeg mener fungerer a la OBS, og konverterer videoen og sender streamet videre til YouTube. Framerate, vinkel, m.m. kan indstilles. Der er dog ingen lyd med i streamet.

Dertil har fundet den autoexecute-fil, som Raspian starter op på, og tilføjet en kommando, så streamet starter efter boot-up.

Pointen er at jeg ender med en PI, som bare skal have strøm fra en mobiloplader eller lille powerbank, hvorefter den begynder at streame video via det trådløse netværk til YouTube

https://thingspeak.com/channels/165821/charts/1?bgcolor=%23ffffff&color=%23d62020&dynamic=true&results=2000&timescale=20&type=line&xaxis=tid

Sensoren står i vindueskarmen. Live opdatering hvert 20. sekund. Hvis diagrammerne ovenfor er tomme, er det fordi jeg har pillet sensoren ned, for at bruge den til noget andet.
Fra www.thingspeak.com:

Det er gået ret godt, men 4 moduler a 90 minutter er der alligevel gået. Det er ret lang tid. De fleste har nået at lodde, kode en smule, 3D printe et 3. hjul og skrue og bore og forbinde.

De har også nået at lave mange fejl og begynde om. Fx er det klassisk at skrue motorer og hjul på karosseriet, før ledningerne er loddet på motorerne.

Jeg synes det er svært at lave en god vejledning, som ikke er for omfattende, men som giver den afgørende hjælp. De har brugt tegningerne over kredsløbene mest.

Sidste fase blev (selvfølgelig) desværre lidt forjaget. Da de endelig skulle kode selve bilen. Og afstandsmåleren drillede lidt -den er bl.a. meget følsom for løse forbindelser, og viser derfor ofte nul, hvilket man bør tage højde for i sin kode. Og det fik vi ikke tid til at implementere.

På den måde blev det ikke helt den succes-oplevelse, som det kunne have været.

1) tidsregistrere grundigt.
Det har jeg gjort nogenlunde. Synes dog ikke det har givet mindre stress. Måske tværtimod, endnu en småopgave, som skal klares. Jeg vil dog nødigt undvære. Skal huske at sætte en seddel på computeren: “Husk tidsregistrering”.

2) fjerne notifikationer fra sociale medier og outlook, og kun checke sociale medier en gang om ugen.
Delvis succes. Har flyttet notifikationer og mail-klient væk fra skrivebord på telefon til bageste side, så de ikke springer i øjnene. Men checker stadig dagligt og det er ok. Får kun notifikationer fra de vigtigste FB-grupper. Stadig et åbent spørgsmål om sociale medier bare er at blæse bobler, eller om det faktisk giver noget.

3) være mere social omkring min interesse for teknologi. Jeg søger legekammerater, frem for indflydelse og egen formidling. Det kan ske gennem Makerlab Svendborg, starte CodingPirates i Svendborg eller mødes med ligesindede på gymnasiet.
Er kommet i Makerlab (ML) gennem året. Det er meget hyggeligt. Får ikke lavet så meget arbejde derude, og kan som regel først være der kl. 20. Bliver træt kl. 21. Jeg har overvejet at starte CP i Svendborg, men tror det let bliver en for stor opgave. Afholder i stedet enkelte arrangementer, hvis muligt.

4) ikke forsøge at blive den bedste på alle områder.
Det er fortsat svært at acceptere. Oplever en stigende konkurrence-situation på skolen. Finder af og til ro i tanken om at være god nok, og endda god til nogle ting.

5) få tid til at bevæge mig, og at børnene kommer til fritidsinteresser.
Jeg har ikke været til fodbold siden efteråret. Nedtur. Dårligt vejr og andre opgaver har fyldt for meget. Kigger på andre muligheder fx floorball eller skolens motionsrum. Børnene har været til en interesse, en gang om ugen. Det er dog ikke mig, som har trukket det store læs.

6) Projekter i øvrigt.
De fleste er afsluttede. Erkendelse: Det vigtige er ikke indholdet i projektet, men at inspirere andre til at indgå i projektet. Dejligt at FL-projektet er slut, så der bliver plads til noget nyt.
Som IT-ressourceperson, er det stadig lidt uklart, hvad opgaven er.

God ide at lægge en strategi for næste skoleår. Det samler op på året og givet udgangspunkt for refleksion og planer for næste år. Skrev egentligt målene i denne post ned ved årets start, men har først fundet dem nu.

Skattejagt. Alder: 8 års fødselsdag.

Post 1: Hvad er i æskerne? salt, sukker og kanel. Koordinater: 6,9

Post 2: find (pluk) 10 arter af blade (plante-arter). Min. 5 accepteres.

Post 3: skriv et ord på fem bogstaver (for nem)

Post 4: Alle skal lave et mål på en målmand (voksen)

Post 5: find 5 arter af dyr. Marst, derfor min. 3 (snegl, bænkebidder, høne)

Post 6: Tre regnestykker. 2+6, 11+17, 6+8. Kedeligt, et barn løser alle.

Post 7: Hvor langt flyver en vand-raket? (i skridt). Alle svar accepteres.

Post 8: Hvor mange boss’er er der i Terraria? (24 har jeg talt. 10 accepteres). Hvad hedder de?

IT indgår jævnligt i min undervisning, og gymnasiet i Svendborg er i disse år ved at implementere office 365, som derfor kan komme i fokus på bloggen.

Forvent dog ikke at  få præsenteret færdige arbejdsformer, fremgangsmåder og forløb. Bloggen er snarere en del af min arbejdsproces -der stilles flere spørgsmål end gives svar, og derfor bloggens navn -laboratorie. Jeg er gennem tiden blevet meget inspireret via andre blogs om undervisning, og håber her at kunne bidrage lidt den anden vej.