first commit

Portfolio/2026-09-01_Mit_lab–fra_opsætning_til_fejlfinding.md

@@ -0,0 +1,177 @@
+# Mit lab – fra simpel opsætning til fejlfinding
+
+**Dato:** 01/9 2026
+**Læringsmål dækket:** [AI i softwareprojekter](../Læringsmål–AI_til_softwareløsninger.md) og [Dataanalyse og databehandling](../Læringsmål–Dataanalyse_og_databehandling.md)
+
+Som en del af mine to valgfag AI i softwareprojekter og Dataanalyse og databehandling har jeg arbejdet med at opbygge mit eget lab-miljø.
+
+Formålet har ikke kun været at få nogle Docker-containere til at køre. Labbet er blevet en praktisk platform, hvor jeg kan eksperimentere, fejlsøge og koble teori til konkrete problemstillinger fra mit hotelprojekt.
+
+Mit lab består blandt andet af:
+
+- PostgreSQL som database
+- Gitea som Git-server
+- Nginx som reverse proxy
+- Mailserver til håndtering af e-mail
+- Docker som grundlag for containerisering
+
+På papiret ser opsætningen forholdsvis simpel ud. I praksis viste det sig hurtigt, at det er noget helt andet at få flere services til at fungere sammen.
+
+*Selve begrundelsen for valget af hver komponent (og de fravalgte alternativer) er dokumenteret i sin egen post: [Processen i at vælge – teknologivalg til labbet](2026-09-17_Processen_i_at_vælge–teknologivalg_til_labbet.md).*
+
+## 🧩 Udfordringer, løsninger og reflektion
+
+### 🔧 Da mailserveren ikke virkede
+
+Jeg undersøgte systemet trin for trin. Jeg brugte blandt andet:
+
+```
+ss -tlpn
+```
+
+Kommandoen viste, hvilke TCP-porte der lyttede på serveren. Her opdagede jeg, at port 993, som bruges til IMAPS, ikke var åben.
+
+Derefter undersøgte jeg konfigurationen inde i Docker-containeren:
+
+```
+docker exec mailserver doveconf -n | grep -A2 -E "^service imap-login|^ssl "
+```
+
+Det gav et vigtigt spor: problemet var relateret til SSL-certifikatet, hvilket betød, at IMAPS ikke blev startet korrekt.
+
+### 💡 Løsningen
+
+Jeg endte med at generere et certifikat til mailserveren ved hjælp af Certbot.
+
+Efter certifikatet var på plads, kunne mailserveren starte IMAPS korrekt, og port 993 blev igen synlig på serveren.
+
+Det interessante var derfor ikke kun selve løsningen. Det var processen:
+
+**Problem → undersøgelse → hypotese → test → ny viden → løsning**
+
+Det er netop denne proces, jeg gerne vil kunne dokumentere i min læring.
+
+### 🔐 En anden vigtig læring – passwords og data
+
+Jeg stødte også på problemer med passwords i mine Bash-scripts.
+
+Passwords med specialtegn gav uventede resultater, når de blev sendt som parametre til funktioner. Det fik mig til at undersøge, hvordan Bash håndterer værdier, og hvordan jeg kunne ændre min tilgang.
+
+Det gav mig en vigtig erfaring:
+
+**Data skal ikke bare kunne flyttes fra A til B – det skal ske på en måde, der er robust og sikker.**
+
+Det er særligt relevant i et hotel management-system, hvor systemet potentielt håndterer bookingdata og andre oplysninger, som kræver korrekt behandling og kontrol.
+
+## 🔄 Kolbs læringscirkel i praksis
+
+Arbejdet med labbet kan kobles direkte til Kolbs læringscirkel, som jeg bruger i begge mine læringsmål.
+
+**1. Konkret erfaring**
+
+En af de største udfordringer i labbet var mailserveren. Jeg fulgte først vejledningen fra mailserverens egen dokumentation, men løsningen fungerede ikke i mit miljø, og jeg fandt heller ikke en løsning ved at søge efter andre løsninger online. Det betød, at jeg selv måtte undersøge systemet trin for trin for at finde ud af, hvorfor IMAPS-tjenesten (port 993) ikke startede – se de tekniske detaljer under "Da mailserveren ikke virkede" ovenfor.
+
+**2. Refleksion**
+
+Jeg undersøger, med udgangspunkt i mailserver-problemet:
+
+- Hvad virkede ikke?
+  > IMAPS-tjenesten startede ikke – port 993 var lukket, selvom jeg fulgte mailserverens officielle opsætningsvejledning.
+- Hvor opstod fejlen?
+  > Inde i selve containeren, i SSL/TLS-konfigurationen: uden et gyldigt certifikat kunne imap-login-servicen ikke starte.
+- Hvilke antagelser havde jeg?
+  > Jeg antog, at en installation efter dokumentationen ville virke uden videre, og ledte derfor først efter en netværks-/portfejl frem for at mistænke certifikatet.
+- Hvilke værktøjer kunne hjælpe mig?
+  > `ss -tlpn` til at se hvilke porte der reelt lyttede, og `docker exec ... doveconf -n` til at læse den faktiske konfiguration inde i containeren i stedet for kun at læse dokumentation udefra.
+- Hvad kunne jeg gøre anderledes?
+  > Undersøge konfigurationen inde i containeren fra starten i stedet for at bruge tid på at søge efter færdige løsninger, og lade certifikat-generering med Certbot være en fast del af opsætningen fra begyndelsen.
+
+  > Meget af tiden gik med trial-and-error. Jeg kunne have sparet tid ved bare at finde en løsning på nettet, men så havde jeg ikke lært at debugge fejlen selv. Ved i stedet at bruge terminalkommandoerne til at spore årsagen har jeg nu en metode, jeg kan bruge igen – næste gang jeg ser problemet, ved jeg, hvor jeg skal lede.
+
+**3. Abstrakt begrebsliggørelse**
+
+Jeg kobler mine erfaringer til teori om blandt andet:
+
+- Docker og containerisering
+- netværk og porte
+- SSL/TLS
+- systemintegration
+- databehandling
+- fejlhåndtering
+- sikkerhed og privacy
+
+På samme måde skal jeg i dataanalyse koble mine praktiske erfaringer til teori om datakvalitet, statistik, visualisering og sammenhænge. I AI-sporet kobles erfaringerne til blandt andet LLM'er, modelvalg, AI-evaluering og human-in-the-loop.
+
+**4. Aktiv eksperimenteren**
+
+Når jeg har fundet en mulig forklaring, ændrer jeg konfigurationen eller metoden og tester igen. Det giver en løbende proces:
+
+**Eksperiment → refleksion → teori → forbedring → nyt eksperiment**
+
+Det er den samme tilgang, jeg senere vil bruge, når jeg arbejder med hoteldata, AI-modeller og AI-baseret beslutningsstøtte.
+
+## 🎯 Hvilke kernemål i læringsmål dækkes
+
+Arbejdet med labbet opfylder ikke hele mine læringsmål alene. Tabellerne herunder viser, hvor meget hvert kerneområde er dækket lige nu: 🟢 dækkes helt, 🟡 dækkes delvist, 🔴 dækkes kun lidt eller slet ikke endnu.
+
+### Dataanalyse og databehandling
+
+| Kerneområde | Vægt i læringsmål | Dækning | Begrundelse |
+|---|---|:---:|---|
+| Dataindsamling | Stor | 🟡 | PostgreSQL er sat op, men der indsamles endnu ikke reelle hoteldata |
+| Datastrukturering | Stor | 🟡 | Databasen giver et sted at strukturere data, men skemaet til hoteldata er ikke designet endnu |
+| Datakvalitet | Stor | 🔴 | Ikke arbejdet med endnu – kræver et faktisk datasæt |
+| Datarensning | Stor | 🔴 | Ikke relevant før der er data at rense |
+| Dataanalyse | Stor | 🔴 | Ikke påbegyndt |
+| Statistik | Stor | 🔴 | Ikke påbegyndt |
+| Deskriptiv statistik | Stor | 🔴 | Ikke påbegyndt |
+| Trends og mønstre | Stor | 🔴 | Ikke påbegyndt |
+| Sammenhænge mellem variable | Stor | 🔴 | Ikke påbegyndt |
+| Datavisualisering | Stor | 🔴 | Ikke påbegyndt |
+| Fortolkning af resultater | Mindre | 🔴 | Ikke relevant endnu |
+| Formidling af data | Mindre | 🔴 | Denne post formidler proces, ikke data |
+
+Labbet bliver derfor ikke selve dataanalysen, men den platform hvor data senere kan opbevares og gøres tilgængelige for analyse.
+
+### AI i softwareprojekter
+
+| Kerneområde | Vægt i læringsmål | Dækning | Begrundelse |
+|---|---|:---:|---|
+| Python for AI | Stor | 🔴 | Kurset er ikke startet endnu i denne del af forløbet |
+| Machine Learning | Stor | 🔴 | Ikke påbegyndt |
+| AI til fortolkning af data | Stor | 🔴 | Ikke påbegyndt |
+| Large Language Models (LLM) | Stor | 🔴 | Ikke påbegyndt |
+| Modelvalg og model comparison | Stor | 🔴 | Ikke påbegyndt |
+| Prompt engineering | Stor | 🔴 | Ikke påbegyndt |
+| Generativ AI | Stor | 🔴 | Ikke påbegyndt |
+| AI-baseret beslutningsstøtte | Stor | 🟡 | Labbet lægger den tekniske forbindelse (data → software → AI), men selve beslutningsstøtten er ikke bygget |
+| OCR | Stor | 🔴 | Ikke påbegyndt |
+| Feature extraction | Stor | 🔴 | Ikke påbegyndt |
+| Fortolkning af hoteldata | Mindre | 🔴 | Ikke påbegyndt |
+| Test og evaluering af AI-output | Mindre | 🔴 | Ikke relevant endnu – ingen AI-output at teste |
+| Fejlhåndtering og usikkerhed | Mindre | 🟢 | Fejlsøgningen af mailserveren (port, SSL-certifikat) er direkte, dokumenteret træning i systematisk fejlhåndtering |
+| Human-in-the-loop | Mindre | 🔴 | Ikke relevant endnu |
+| Privacy og ansvarlig AI | Mindre | 🟡 | SSL-certifikater og robust password-håndtering i Bash er et skridt mod ansvarlig datahåndtering, men dækker endnu ikke AI-specifikke privacy-spørgsmål |
+
+Labbet dækker altså ikke de store, tunge AI-kerneområder som LLM'er eller modelvalg endnu – de kommer i senere poster, når Python-for-AI-kurset og LLM-eksperimenterne er i gang. Her lægges i stedet fundamentet: et miljø hvor AI senere kan integreres med hoteldata, og en solid træning i systematisk fejlhåndtering.
+
+Det betyder, at labbet kan blive forbindelsen mellem:
+
+**Hoteldata → database → software → AI → beslutningsstøtte**
+
+## 🏨 Hvilken værdi kan det give et hotel management-system?
+
+Når jeg ser på labbet i forhold til et hotel management-system som NF Hotel, handler værdien ikke kun om teknologien i sig selv.
+
+En samlet teknisk platform kan eksempelvis understøtte:
+
+- sikker og struktureret håndtering af hoteldata
+- integration mellem forskellige services
+- automatiseret kommunikation via e-mail (ej efterspurgt af PO men kan være vigtigt for beslutningsstøtte)
+- adgang til data til analyse
+- integration af AI-funktioner
+- bedre grundlag for beslutningsstøtte
+
+På længere sigt kan data fra systemet analyseres for eksempelvis at finde trends i belægning, sæsonvariationer, forskelle mellem hverdage og weekender eller sammenhænge mellem pris og belægning. Det er netop nogle af de analyseområder, der indgår i mit dataanalyse-læringsmål.
+
+AI kan derefter bruges som et ekstra lag til at fortolke data og undersøge mulige forklaringer eller forbedringer.

Portfolio/2026-09-01_Sammenfald–AI_i_softwareudvikling_og_dataanalyse.md

@@ -0,0 +1,270 @@
+# Sammenfald mellem AI i softwareudvikling og dataanalyse
+
+**Dato:** 01/9 2026
+**Læringsmål dækket:** [AI i softwareprojekter](../Læringsmål–AI_til_softwareløsninger.md) og [Dataanalyse og databehandling](../Læringsmål–Dataanalyse_og_databehandling.md)
+
+Mine to læringsmål omhandler AI i softwareudvikling og dataanalyse og databehandling. De har forskellige faglige fokusområder, men når jeg arbejder praktisk med dem i hotelprojektet, opstår der et tydeligt sammenfald.
+
+Dataanalysen giver mig et fagligt grundlag for at forstå og kontrollere hoteldata, mens AI-læringsmålet giver mig mulighed for at undersøge, hvordan AI kan anvendes til at arbejde med og fortolke disse data. De to læringsmål kan derfor ses som to komplementære kompetenceområder: dataanalyse hjælper mig med at forstå dataene – AI hjælper mig med at undersøge, hvordan teknologien kan arbejde med dataene. Samtidig giver dataanalysen mig et grundlag for at kontrollere, om AI's output faktisk kan understøttes af data.
+
+## 🔗 Sammenfald mellem de to læringsmål
+
+### Dataanalyse som fundament for AI
+
+Før AI kan anvendes meningsfuldt på hoteldata, skal jeg først forstå kvaliteten og strukturen af dataene. Mit dataanalyse-læringsmål fokuserer blandt andet på:
+
+- dataindsamling
+- datastrukturering
+- datakvalitet
+- datarensning
+- statistik
+- trends og mønstre
+- sammenhænge mellem variable
+- visualisering
+- fortolkning af resultater
+
+Jeg skal blandt andet kunne identificere datakvalitetsproblemer, anvende statistiske beregninger og finde trends og sammenhænge i hoteldata. Det bliver vigtigt for AI-delen, fordi AI's output kun kan vurderes ordentligt, hvis jeg selv forstår de data, som AI arbejder med.
+
+Eksempelvis kan jeg først undersøge: *er belægningen højere i weekenden?* Ved hjælp af statistik og visualisering kan jeg finde ud af, om der faktisk er en sådan sammenhæng. Derefter kan jeg undersøge: *kan AI identificere den samme sammenhæng?* På den måde bliver dataanalysen også en form for kontrolgrundlag for AI.
+
+### AI som værktøj i softwareudviklingen
+
+Mit AI-læringsmål handler ikke kun om at få AI til at skrive kode. Fokus er at kunne identificere, vælge, anvende og evaluere AI-teknologier i konkrete problemstillinger. Jeg skal blandt andet undersøge forskellige modeller og sammenligne dem ud fra:
+
+- kvalitet
+- hastighed
+- ressourceforbrug
+- privacy/datahåndtering
+- anvendelighed
+
+Jeg skal også arbejde med prompts, AI-fortolkning af hoteldata og kritisk sammenligning mellem AI-output og de faktiske data. Derfor bliver spørgsmålet ikke kun *kan AI skrive koden?*, men også: *kan jeg bruge AI systematisk og vurdere kvaliteten af det, AI producerer?*
+
+### Hotelprojektet som fælles case
+
+Hotelprojektet giver mig mulighed for at kombinere de to læringsmål i én samlet proces. Jeg kan eksempelvis arbejde med historiske hoteldata indeholdende:
+
+- Dato
+- Ugedag
+- Sæson
+- Bookede værelser
+- Kapacitet
+- Belægningsprocent
+- Værelsestype
+- Pris
+
+Disse variable indgår direkte i dataanalyse-læringsmålet. Processen kan eksempelvis være:
+
+```plantuml
+@startuml
+start
+:HOTELDATA;
+:Dataanalyse
+* Datakvalitet
+* Statistik
+* Trends
+* Visualisering;
+:AI-eksperiment
+* Modelvalg
+* Prompting
+* Fortolkning
+* Prognose;
+:Validering
+AI-output vs. faktiske data;
+:Beslutningsstøtte;
+stop
+@enduml
+```
+
+Det betyder, at det samme projekt kan skabe dokumentation til begge læringsmål.
+
+### Fra AI-genereret kode til fagligt valideret resultat
+
+Et konkret eksempel kan være, at jeg beder en AI-agent om at udvikle en analyse af hotelbelægningen. Agenten kan eksempelvis hjælpe med at:
+
+1. Indlæse datasættet
+2. Kontrollere manglende værdier
+3. Beregne statistik
+4. Gruppere data efter ugedag
+5. Generere visualiseringer
+6. Foreslå trends og mønstre
+
+Her mødes de to læringsmål.
+
+**AI-perspektivet** – jeg undersøger:
+
+- Hvor godt AI løser opgaven
+- Hvor meget jeg skal ændre AI's forslag
+- Om forskellige modeller giver forskellige resultater
+- Hvordan prompts påvirker resultatet
+- Hvornår AI laver fejl
+- Hvornår jeg selv skal overtage kontrollen
+
+Dette passer med kravet om at eksperimentere med forskellige modeller og prompts samt dokumentere resultater, fejl og egne vurderinger.
+
+**Dataanalyse-perspektivet** – jeg undersøger:
+
+- Om data er korrekt behandlet
+- Om beregningerne er korrekte
+- Om visualiseringerne er relevante
+- Om de identificerede trends faktisk findes
+- Om konklusionerne kan understøttes af data
+- Hvilke begrænsninger datasættet har
+
+Det svarer til dataanalyse-læringsmålets fokus på at identificere mønstre, undersøge sammenhænge og vurdere, hvad data kan og ikke kan fortælle.
+
+### Agentisk AI og de to læringsmål
+
+Sammenfaldet bliver endnu tydeligere, når jeg anvender agentisk AI. En AI-agent kan eksempelvis arbejde gennem flere trin:
+
+```plantuml
+@startuml
+start
+:Problem;
+:Undersøg data;
+:Foreslå metode;
+:Skriv kode;
+:Kør analyse;
+:Undersøg resultat;
+:Foreslå forbedringer;
+stop
+@enduml
+```
+
+Det giver mig mulighed for at undersøge AI som en del af en mere komplet softwareudviklingsproces. Men agenten bliver ikke den faglige autoritet. Min rolle bliver i højere grad at:
+
+**definere problemet → styre processen → kontrollere output → validere resultatet → træffe faglige valg**
+
+Det passer godt med AI-læringsmålet, hvor jeg skal kunne evaluere AI-output og vurdere, hvornår menneskelig kontrol er nødvendig.
+
+### Fra data til beslutningsstøtte
+
+Det vigtigste sammenfald mellem læringsmålene er derfor ikke selve teknologien. Det er processen:
+
+```plantuml
+@startuml
+start
+:Problem;
+:Data;
+:Datakvalitet;
+:Analyse;
+:Trends og sammenhænge;
+:AI-eksperiment;
+:AI-fortolkning;
+:Validering;
+:Beslutningsstøtte;
+stop
+@enduml
+```
+
+Eksempelvis kan dataanalysen vise en historisk sammenhæng mellem events og hotelbelægning. Derefter kan AI bruges til at undersøge, om den kan identificere samme mønster og eventuelt hjælpe med at fortolke, hvilke faktorer der kan have påvirket efterspørgslen. Det er netop en del af AI-læringsmålet at undersøge mønstre, sammenhænge, eventeffekter og mulige forklaringer i hoteldata.
+
+## 🔄 Kolbs læringscirkel i praksis
+
+**1. Konkret erfaring**
+
+Jeg arbejder praktisk med hoteldata og AI. Jeg bruger Python-biblioteker til at håndtere manglende data og forkerte datatyper – dette kan kombineres med AI. Et eksempel er, at jeg lader en AI-agent analysere belægningsdata: agenten indlæser datasættet, kontrollerer manglende værdier, beregner statistik, grupperer data efter ugedag, genererer visualiseringer og foreslår trends og mønstre.
+
+**2. Refleksion**
+
+- Hvad fungerede?
+  > De trin, hvor AI'en kunne følge en klar, veldefineret opgave – fx indlæsning af data og beregning af simple statistiske mål.
+- Hvad fungerede ikke?
+  > Fortolkningen blev usikker, når AI'en skulle vurdere årsager bag mønstre uden at kende hotellets kontekst (fx events, lokale forhold) – her kunne resultatet ikke stå alene.
+- Var AI'ens resultat korrekt?
+  > Kun delvist – nogle beregninger kunne verificeres direkte mod data, mens AI'ens fortolkninger af *hvorfor* et mønster opstod krævede min egen faglige kontrol, før jeg kunne stole på dem.
+
+**3. Abstrakt begrebsliggørelse**
+
+Jeg kobler erfaringerne til teori om eksempelvis:
+
+- statistik
+- datakvalitet
+- visualisering
+- LLM'er
+- prompting
+- Machine Learning
+- modelvalg
+- AI-evaluering
+- usikkerhed
+- human-in-the-loop
+
+**4. Aktiv eksperimenteren**
+
+Jeg ændrer eksempelvis datasættet, analysen, visualiseringen, prompten, AI-modellen eller metoden og gennemfører derefter et nyt eksperiment. Det giver en løbende proces:
+
+**Eksperiment → refleksion → teori → forbedring → nyt eksperiment**
+
+Den samme læringsstruktur findes i dataanalyse-læringsmålet, hvor processen beskrives som analyse → refleksion → teori → ny analyse.
+
+## 🎯 Hvilke kernemål i læringsmål dækkes
+
+🟢 dækkes helt, 🟡 dækkes delvist, 🔴 dækkes kun lidt eller slet ikke endnu.
+
+### Dataanalyse og databehandling
+
+| Kerneområde | Vægt i læringsmål | Dækning | Begrundelse |
+|---|---|:---:|---|
+| Dataindsamling | Stor | 🟡 | Hoteldatas relevante variable er identificeret (dato, ugedag, sæson, m.fl.), men datasættet er ikke indsamlet i denne post |
+| Datastrukturering | Stor | 🟡 | Variablene til hoteldata er struktureret konceptuelt |
+| Datakvalitet | Stor | 🟡 | Kontrol af manglende værdier indgår i den beskrevne AI-agent-proces, men er ikke udført konkret her |
+| Datarensning | Stor | 🔴 | Ikke konkret udført i denne post |
+| Dataanalyse | Stor | 🟡 | Statistik, trends og sammenhænge er planlagt og eksemplificeret (fx belægning i weekenden), men ikke gennemført på et faktisk datasæt |
+| Statistik | Stor | 🟡 | Indgår i den beskrevne proces, men ikke udført konkret her |
+| Deskriptiv statistik | Stor | 🟡 | Samme som ovenfor |
+| Trends og mønstre | Stor | 🟡 | Eksemplificeret via weekend-belægning og events, men ikke udført konkret |
+| Sammenhænge mellem variable | Stor | 🟡 | Pris/belægning og events/efterspørgsel bruges som eksempler |
+| Datavisualisering | Stor | 🔴 | Nævnt som en del af processen, men ikke produceret i denne post |
+| Fortolkning af resultater | Mindre | 🟡 | Central pointe: at vurdere, hvad data og AI's fortolkning af data kan og ikke kan understøtte |
+| Formidling af data | Mindre | 🔴 | Denne post formidler en samlet proces, ikke konkrete dataresultater |
+
+### AI i softwareprojekter
+
+| Kerneområde | Vægt i læringsmål | Dækning | Begrundelse |
+|---|---|:---:|---|
+| Python for AI | Stor | 🔴 | Ikke relevant for denne post |
+| Machine Learning | Stor | 🔴 | Ikke relevant for denne post |
+| AI til fortolkning af data | Stor | 🟡 | Centralt tema, men endnu ikke afprøvet konkret på et hoteldatasæt |
+| Large Language Models (LLM) | Stor | 🔴 | Omtales generelt sammen med AI-agenter, men ikke undersøgt specifikt |
+| Modelvalg og model comparison | Stor | 🟡 | Kriterier for sammenligning (kvalitet, hastighed, ressourceforbrug, privacy, anvendelighed) er opstillet, men endnu ikke anvendt på konkrete modeller |
+| Prompt engineering | Stor | 🟡 | Prompting indgår som en del af eksperimentet, men er ikke konkret afprøvet i denne post |
+| Generativ AI | Stor | 🔴 | Ikke relevant for denne post |
+| AI-baseret beslutningsstøtte | Stor | 🟢 | Hele postens konklusion er netop, hvordan data + AI + validering fører til beslutningsstøtte |
+| OCR | Stor | 🔴 | Ikke relevant for denne post |
+| Feature extraction | Stor | 🔴 | Ikke relevant for denne post |
+| Fortolkning af hoteldata | Mindre | 🟡 | Eksemplificeret via belægning/events, men ikke udført konkret |
+| Test og evaluering af AI-output | Mindre | 🟡 | Central pointe: AI-output skal valideres mod faktiske data, men er ikke konkret testet her |
+| Fejlhåndtering og usikkerhed | Mindre | 🔴 | Ikke behandlet konkret i denne post |
+| Human-in-the-loop | Mindre | 🟢 | Eksplicit tema: min rolle er at definere problemet, styre processen, kontrollere output og træffe de faglige valg |
+| Privacy og ansvarlig AI | Mindre | 🔴 | Kun nævnt som ét ud af flere sammenligningskriterier, ikke uddybet |
+
+## 🏨 Hvilken værdi kan det give et hotel management-system?
+
+Kombinationen af de to læringsmål kan give flere konkrete muligheder i et hotel management-system.
+
+**Dataanalyse kan bruges til at forstå:**
+
+- belægningsmønstre
+- sæsonvariation
+- forskelle mellem ugedage
+- værelsestyper
+- pris og belægning
+- usædvanlige perioder
+
+**AI kan derefter undersøges som støtte til:**
+
+- fortolkning af hoteldata
+- efterspørgselsprognoser
+- analyse af events
+- prisforslag
+- rapportgenerering
+- beslutningsstøtte
+
+Men værdien ligger ikke kun i selve AI-outputtet. Den ligger i at kunne skabe en proces, hvor:
+
+**Data analyseres → AI anvendes → resultatet kontrolleres → mennesket træffer beslutningen.**
+
+Mine to læringsmål er forskellige, men de understøtter hinanden meget direkte. Dataanalyse og databehandling giver mig kompetencer til at indsamle, rense, analysere, visualisere og fortolke hoteldata. AI i softwareudvikling giver mig kompetencer til at undersøge, vælge, anvende og evaluere AI-teknologier i konkrete problemstillinger.
+
+Hotelprojektet bliver derfor en fælles case, hvor de to læringsmål kan arbejde sammen. Det giver mig mulighed for både at undersøge *"kan AI hjælpe mig med at løse opgaven?"* og *"er resultatet korrekt, kan det dokumenteres ud fra data, og er det fagligt anvendeligt?"*
+
+Det sidste er centralt. En AI-genereret analyse bliver ikke automatisk korrekt, bare fordi koden kan køres, eller resultatet ser overbevisende ud. Mit mål er derfor ikke blot at lære at bruge AI, men at lære at bruge AI med faglig kontrol. På den måde bliver de to læringsmål to sider af samme kompetence: at kunne anvende AI og dataanalyse til at udvikle datadrevne softwareløsninger, samtidig med at jeg kan forstå, kontrollere og evaluere resultaterne.

Portfolio/2026-09-02_Processen_i_at_vælge–teknologivalg_til_labbet.md

@@ -0,0 +1,109 @@
+# Processen i at vælge – teknologivalg til labbet
+
+**Dato:** 02/9 2026
+**Læringsmål dækket:** [AI i softwareprojekter](../Læringsmål–AI_til_softwareløsninger.md) og [Dataanalyse og databehandling](../Læringsmål–Dataanalyse_og_databehandling.md)
+
+Da jeg satte mit lab op (se [Mit lab – fra simpel opsætning til fejlfinding](2026-09-01_Mit_lab–fra_opsætning_til_fejlfinding.md)), var hver komponent et valg, jeg kan begrunde – og som havde alternativer, jeg bevidst fravalgte. Denne post dokumenterer selve valgprocessen: hvilke kriterier jeg vægtede, og hvilke alternativer jeg overvejede og fravalgte for hver komponent.
+
+Mit udgangspunkt for at finde løsninger var, at de ikke måtte være ressourcekrævende, og at de gerne skulle være open source og self-hosted, så jeg holder mig til privacy by design. Jeg fandt kandidatløsninger via Google AI og tjekkede efterfølgende nogle af de kilder, som Google AI's svar byggede på, for at bekræfte ægtheden af informationen, før jeg lagde den til grund for et valg.
+
+## 🧭 Processen i at vælge
+
+| Komponent | Valgt fordi | Alternativ(er) overvejet |
+|---|---|---|
+| PostgreSQL som database | Understøtter avanceret data-integritet, JSONB til semistrukturerede data og har ekstremt høj ydeevne ved komplekse forespørgsler (queries) | MySQL/MariaDB – lettere at gå til, men mangler PostgreSQL's avancerede indeksering og stærke håndtering af komplekse datatyper. SQLite – god til helt små setups, men mangler concurrency (samtidige brugere) og skalering |
+| Gitea som Git-server | Letvægtsløsning og privat by design | GitLab – enterprise-orienteret og mere ressourcekrævende |
+| Nginx som reverse proxy | Ekstremt hurtig til statisk indhold, lavt hukommelsesaftryk, og simpel konfiguration af SSL (fx via Certbot), load balancing og URL-rewriting | Apache – traditionel og modulær, men bruger markant flere ressourcer (proces-per-forbindelse) under høj belastning |
+| Mailserver til håndtering af e-mail | Samlet løsning i én container (fx docker-mailserver). Giver fuld kontrol over data, ingen eksterne licensomkostninger og nem opsætning af SMTP/IMAP i et lukket miljø | Eksterne API'er (SendGrid/Mailgun) – nemme at integrere, men medfører faste udgifter, vendor lock-in og potentielle GDPR-udfordringer med tredjepartsdata |
+| Docker som grundlag for containerisering | Sikrer ensartede miljøer på tværs af udvikling og produktion ("virker på min maskine"-problemet løses). Gør udrulning, skalering og isolation af services lynhurtig | Bare-metal/direkte installation – minimalt overhead, men store problemer med afhængigheder, versionskonflikter og svær migrering |
+
+## 🔄 Kolbs læringscirkel i praksis
+
+**1. Konkret erfaring**
+
+Inden jeg satte labbet op, stod jeg over for fem konkrete valg: database, Git-server, reverse proxy, mailløsning og containerisering. For hvert valg fandtes der mindst ét realistisk alternativ, og jeg måtte tage stilling til, hvilket der passede bedst til et lille, selvstændigt lab-miljø. Jeg brugte Google AI til at finde kandidatløsninger og fravalgte ikke bare at stole på svaret – jeg tjekkede nogle af de underliggende kilder for at bekræfte, at informationen var korrekt.
+
+**2. Refleksion**
+
+- Hvilke kriterier vægtede jeg højst?
+  > At løsningen ikke var ressourcekrævende, at den var open source og self-hosted (privacy by design), samt kontrol over egne data og hvor godt løsningen skalerer til fremtidige behov (fx JSONB til semistrukturerede hoteldata i PostgreSQL).
+- Hvordan sikrede jeg mig, at informationen fra Google AI var pålidelig?
+  > Ved at tjekke nogle af de referencer, Google AI's svar var bygget på, i stedet for at stole blindt på et AI-genereret svar.
+- Hvorfor fravalgte jeg de "nemmere" alternativer (MySQL/SQLite, eksterne mail-API'er)?
+  > Fordi de enten manglede funktionalitet, jeg forventer at få brug for (concurrency, avanceret indeksering), eller fordi de flyttede kontrollen over data ud af mit eget miljø (vendor lock-in, GDPR-risiko ved tredjepartsdata) og dermed væk fra mit udgangspunkt om privacy by design.
+- Hvad var trade-off'et ved mine valg?
+  > Valget af Nginx og Gitea frem for tungere enterprise-løsninger som Apache og GitLab er baseret på en bevidst arkitektonisk afvejning (trade-off). I et mindre lab-miljø har prioriteringen ligget på ressourceoptimering, lav driftskompleksitet (Low Operational Overhead) og høj ydeevne.
+- Hvad ville få mig til at vælge anderledes?
+  > Hvis labbet skulle skalere til mange samtidige brugere eller et team, ville GitLab og Apache blive mere attraktive – kriterierne ændrer sig med kravene.
+
+**3. Abstrakt begrebsliggørelse**
+
+Jeg kobler mine erfaringer til teori om blandt andet:
+
+- databasearkitektur og ACID/indeksering
+- reverse proxy-arkitektur og ressourceforbrug
+- containerisering versus bare-metal
+- vendor lock-in og GDPR ved tredjepartsdata
+- kriteriebaseret teknologivalg og trade-off-analyse
+
+Det er præcis den samme metode – kriterier, alternativer, begrundet valg – som mit AI-læringsmål kræver, når jeg senere skal sammenligne mindst 3 LLM'er/AI-modeller og begrunde mit valg. Her har jeg øvet metoden på infrastruktur, før jeg skal bruge den på AI-modeller.
+
+**4. Aktiv eksperimenteren**
+
+Næste gang jeg skal vælge en teknologi – uanset om det er en AI-model, et bibliotek eller en service – vil jeg bruge samme fremgangsmåde: opstille kriterier først, identificere realistiske alternativer, og eksplicit dokumentere, hvorfor de blev fravalgt.
+
+## 🎯 Hvilke kernemål i læringsmål dækkes
+
+🟢 dækkes helt, 🟡 dækkes delvist, 🔴 dækkes kun lidt eller slet ikke endnu.
+
+### Dataanalyse og databehandling
+
+| Kerneområde | Vægt i læringsmål | Dækning | Begrundelse |
+|---|---|:---:|---|
+| Dataindsamling | Stor | 🔴 | Ikke relevant for denne post |
+| Datastrukturering | Stor | 🟡 | PostgreSQL blev valgt bl.a. pga. JSONB til semistrukturerede data – en direkte overvejelse om datastrukturering |
+| Datakvalitet | Stor | 🔴 | Ikke relevant for denne post |
+| Datarensning | Stor | 🔴 | Ikke relevant for denne post |
+| Dataanalyse | Stor | 🔴 | Ikke relevant for denne post |
+| Statistik | Stor | 🔴 | Ikke relevant for denne post |
+| Deskriptiv statistik | Stor | 🔴 | Ikke relevant for denne post |
+| Trends og mønstre | Stor | 🔴 | Ikke relevant for denne post |
+| Sammenhænge mellem variable | Stor | 🔴 | Ikke relevant for denne post |
+| Datavisualisering | Stor | 🔴 | Ikke relevant for denne post |
+| Fortolkning af resultater | Mindre | 🔴 | Ikke relevant for denne post |
+| Formidling af data | Mindre | 🔴 | Denne post formidler en valgproces, ikke data |
+
+### AI i softwareprojekter
+
+| Kerneområde | Vægt i læringsmål | Dækning | Begrundelse |
+|---|---|:---:|---|
+| Python for AI | Stor | 🔴 | Ikke relevant for denne post |
+| Machine Learning | Stor | 🔴 | Ikke relevant for denne post |
+| AI til fortolkning af data | Stor | 🔴 | Ikke relevant for denne post |
+| Large Language Models (LLM) | Stor | 🔴 | Ikke relevant for denne post |
+| Modelvalg og model comparison | Stor | 🟡 | Samme kriterie- og alternativ-baserede metode er øvet her på infrastruktur, klar til at genbruges på LLM-valg |
+| Prompt engineering | Stor | 🔴 | Ikke relevant for denne post |
+| Generativ AI | Stor | 🔴 | Ikke relevant for denne post |
+| AI-baseret beslutningsstøtte | Stor | 🔴 | Ikke relevant for denne post |
+| OCR | Stor | 🔴 | Ikke relevant for denne post |
+| Feature extraction | Stor | 🔴 | Ikke relevant for denne post |
+| Fortolkning af hoteldata | Mindre | 🔴 | Ikke relevant for denne post |
+| Test og evaluering af AI-output | Mindre | 🟡 | Jeg brugte Google AI til research, men tjekkede efterfølgende nogle af dens kildehenvisninger for at bekræfte ægtheden – en tidlig øvelse i kritisk evaluering af AI-output |
+| Fejlhåndtering og usikkerhed | Mindre | 🔴 | Dækket i den forrige post, ikke denne |
+| Human-in-the-loop | Mindre | 🟡 | Jeg lod ikke Google AI's svar stå uimodsagt, men verificerede det selv, før jeg brugte det til et valg |
+| Privacy og ansvarlig AI | Mindre | 🟡 | "Privacy by design" (open source, self-hosted) var et eksplicit kriterie fra start, og GDPR-risikoen ved eksterne mail-API'er blev vurderet ud fra det |
+
+## 🏨 Hvilken værdi kan det give et hotel management-system?
+
+Bevidste teknologivalg er ikke kun en teknisk detalje – de sætter rammerne for, hvad et hotel management-system kan holde til senere.
+
+- **Data-integritet og performance:** 
+  > PostgreSQL's håndtering af semistrukturerede data og komplekse forespørgsler betyder, at systemet kan holde til mere avancerede analyser af booking- og belægningsdata, efterhånden som de vokser.
+- **Kontrol over følsomme data:** 
+  > At vælge en selvhostet mailserver og database frem for eksterne API'er giver fuld kontrol over gæstedata og bookingoplysninger – relevant for GDPR, og direkte relevant for OCR-projektet, hvor pasoplysninger (pasnummer, navn, nationalitet) er særligt følsomme data, der bør blive i eget miljø.
+- **Skalerbarhed:**
+  > Docker og en let reverse proxy som Nginx gør det muligt at skalere systemet op i højsæson uden at skifte hele arkitekturen ud.
+- **Undgå vendor lock-in:**
+  > Ved at fravælge tredjepartsservices til kernefunktioner (mail, database) undgår systemet at blive afhængigt af en enkelt leverandørs priser og vilkår.
+
+Samlet set betyder det, at de valg, jeg har truffet i labbet, ikke kun handler om at få tingene til at virke – de er også en del af at bygge et fundament, der kan bære et rigtigt hotel management-system.

Portfolio/2026-09-18_Processen_i_at_vælge–IDE_til_lokal_AI.md

@@ -0,0 +1,99 @@
+# Processen i at vælge – IDE til lokal AI
+
+**Dato:** 18/9 2026
+**Læringsmål dækket:** [AI i softwareprojekter](../Læringsmål–AI_til_softwareløsninger.md) og [Dataanalyse og databehandling](../Læringsmål–Dataanalyse_og_databehandling.md)
+
+Jeg blev introduceret til Microsoft Visual Studio på uddannelsen, og det har dannet rammen om mit arbejde de første 3 semestre. Da jeg begyndte at arbejde med lokal AI, opstod der imidlertid et problem, som fik mig til at lede efter et alternativ. Denne post dokumenterer den valgproces.
+
+## 🧭 Processen i at vælge
+
+| Værktøj | Rolle | Valgt/beholdt fordi | Alternativ(er) overvejet |
+|---|---|---|---|
+| Visual Studio | IDE til C#-udvikling og debugging | Har en god debugger til C#, som Zed stadig mangler | – |
+| Zed | Ny IDE til arbejde med lokal AI | Understøtter lokal AI som plugin, håndterer de fleste programmeringssprog, og er hurtigere og mindre ressourcekrævende end Visual Studio | Eclipse og andre IDE'er – kendt fra erfaring til at være langsomme og ressourcekrævende; blev ikke testet nærmere for lokal AI-understøttelse, da Zed allerede løste behovet |
+
+Konklusionen blev ikke at skrotte Visual Studio til fordel for Zed, men at lade de to værktøjer supplere hinanden.
+
+## 🔄 Kolbs læringscirkel i praksis
+
+**1. Konkret erfaring**
+
+Da jeg begyndte at arbejde med lokal AI, virkede det ikke som plugin i Visual Studio. Det betød, at jeg måtte lede efter et alternativ, der kunne det, Visual Studio ikke kunne.
+
+**2. Refleksion**
+
+- Hvad virkede ikke?
+  > Lokal AI kunne ikke køre som plugin i Visual Studio.
+- Hvilke alternativer overvejede jeg, og hvorfor testede jeg dem ikke nærmere?
+  > Jeg kender Eclipse og andre IDE'er fra erfaring og ved, at de er langsomme og ressourcekrævende – derfor undersøgte jeg ikke, om de kunne køre lokal AI, og gik direkte videre til at søge efter et andet alternativ.
+- Hvordan fandt jeg frem til Zed?
+  > Ved at søge på nettet efter en IDE, der kunne understøtte lokal AI, faldt jeg over Zed, som håndterer de fleste programmeringssprog og understøtter lokal AI.
+- Hvilke kriterier vægtede jeg højst?
+  > Understøttelse af lokal AI, ressourceforbrug og hastighed – Zed bruger færre ressourcer og er hurtigere end Visual Studio.
+- Var jeg klar til at skrotte Visual Studio helt?
+  > Nej. Visual Studio har en god debugger til C#, som Zed stadig mangler, så de to værktøjer skal supplere hinanden i stedet for at erstatte hinanden.
+
+**3. Abstrakt begrebsliggørelse**
+
+Jeg kobler erfaringen til teori om blandt andet:
+
+- IDE-arkitektur og plugin-økosystemer
+- ressourceforbrug og performance i udviklingsværktøjer
+- lokal AI versus cloud-baseret AI
+- kriteriebaseret værktøjsvalg og trade-off-analyse
+- privacy ved at køre AI lokalt frem for via eksterne tjenester
+
+**4. Aktiv eksperimenteren**
+
+Jeg bruger nu Zed til arbejde, hvor lokal AI er en fordel, og Visual Studio til C#-udvikling, hvor debuggeren er nødvendig. Næste skridt er at holde øje med, om Zed's værktøjsstøtte (fx debugging) udvikler sig, så fordelingen mellem de to værktøjer kan justeres. Det er den samme kriterie-baserede metode – kriterier, alternativer, begrundet valg – som jeg tidligere har brugt til at vælge infrastruktur til mit lab, og som jeg senere skal bruge til at vælge AI-modeller/LLM'er.
+
+## 🎯 Hvilke kernemål i læringsmål dækkes
+
+🟢 dækkes helt, 🟡 dækkes delvist, 🔴 dækkes kun lidt eller slet ikke endnu.
+
+### Dataanalyse og databehandling
+
+| Kerneområde | Vægt i læringsmål | Dækning | Begrundelse |
+|---|---|:---:|---|
+| Dataindsamling | Stor | 🔴 | Ikke relevant for denne post |
+| Datastrukturering | Stor | 🔴 | Ikke relevant for denne post |
+| Datakvalitet | Stor | 🔴 | Ikke relevant for denne post |
+| Datarensning | Stor | 🔴 | Ikke relevant for denne post |
+| Dataanalyse | Stor | 🔴 | Ikke relevant for denne post |
+| Statistik | Stor | 🔴 | Ikke relevant for denne post |
+| Deskriptiv statistik | Stor | 🔴 | Ikke relevant for denne post |
+| Trends og mønstre | Stor | 🔴 | Ikke relevant for denne post |
+| Sammenhænge mellem variable | Stor | 🔴 | Ikke relevant for denne post |
+| Datavisualisering | Stor | 🔴 | Ikke relevant for denne post |
+| Fortolkning af resultater | Mindre | 🔴 | Ikke relevant for denne post |
+| Formidling af data | Mindre | 🔴 | Ikke relevant for denne post |
+
+### AI i softwareprojekter
+
+| Kerneområde | Vægt i læringsmål | Dækning | Begrundelse |
+|---|---|:---:|---|
+| Python for AI | Stor | 🔴 | Ikke relevant for denne post |
+| Machine Learning | Stor | 🔴 | Ikke relevant for denne post |
+| AI til fortolkning af data | Stor | 🔴 | Ikke relevant for denne post |
+| Large Language Models (LLM) | Stor | 🔴 | Ikke relevant for denne post |
+| Modelvalg og model comparison | Stor | 🟡 | Samme kriterie- og alternativ-baserede metode er øvet her på et udviklingsværktøj, klar til at genbruges på LLM-valg |
+| Prompt engineering | Stor | 🔴 | Ikke relevant for denne post |
+| Generativ AI | Stor | 🔴 | Ikke relevant for denne post |
+| AI-baseret beslutningsstøtte | Stor | 🔴 | Ikke relevant for denne post |
+| OCR | Stor | 🔴 | Ikke relevant for denne post |
+| Feature extraction | Stor | 🔴 | Ikke relevant for denne post |
+| Fortolkning af hoteldata | Mindre | 🔴 | Ikke relevant for denne post |
+| Test og evaluering af AI-output | Mindre | 🔴 | Ikke relevant for denne post |
+| Fejlhåndtering og usikkerhed | Mindre | 🟡 | At opdage at lokal AI ikke virkede som plugin i Visual Studio, og derefter systematisk lede efter et alternativ, er en mindre form for fejlhåndtering |
+| Human-in-the-loop | Mindre | 🔴 | Ikke relevant for denne post |
+| Privacy og ansvarlig AI | Mindre | 🟡 | At vælge lokal AI frem for en cloud-baseret løsning er et bevidst valg om at holde AI-arbejdet og data lokalt |
+
+## 🏨 Hvilken værdi kan det give et hotel management-system?
+
+Valget af udviklingsværktøjer er ikke kun et spørgsmål om personlig præference – det påvirker, hvor effektivt og sikkert et hotel management-system kan udvikles.
+
+- **Lokal AI under udvikling:** Ved at kunne køre AI lokalt i udviklingsmiljøet kan jeg eksperimentere med AI-funktioner, uden at kode eller testdata (fx uddrag af hoteldata) nødvendigvis skal sendes til en ekstern tjeneste undervejs – det understøtter samme privacy-tankegang, som lå bag valget af selvhostet database og mailserver i labbet.
+- **Effektivitet:** Et hurtigere og mindre ressourcekrævende værktøj som Zed betyder mere tid til faktisk udvikling og mindre tid brugt på at vente på værktøjet.
+- **Pålidelighed i kernesystemet:** Ved at beholde Visual Studios stærke C#-debugger til den del af systemet, hvor det betyder mest (fx kernelogik i et hotel management-system), reduceres risikoen for udokumenterede fejl i produktionskoden.
+
+Samlet set viser valget, at det rigtige værktøj afhænger af opgaven – og at det er en fordel at kunne skifte mellem eller kombinere flere værktøjer, i stedet for at insistere på ét værktøj til alt.