Ordliste

Fra idé til live site — Den fulde rejse

Denne sektion gennemgår hele livscyklussen for en ændring — fra at give en retning til at se den live på internettet. Hvert begreb herunder er en del af den faktiske proces, der bruges til at bygge og vedligeholde denne side.

1. Idéen

Alt starter med, at en person beslutter, hvad der skal bygges eller ændres. I dette projekt beskriver brugeren, hvad de ønsker, i dagligdags sprog til en AI-kodningsassistent kaldet Claude Code. Forespørgslen kan være hvad som helst: "tilføj en ordlisteside," "ret scoring-fejlen," eller "byg et nyt spil."

Claude Code

En AI-assistent, der læser, skriver og ændrer kode baseret på instruktioner i naturligt sprog. Den arbejder direkte i projektets repository — læser filer, opretter nye, kører kommandoer og committer ændringer. Den er den primære udvikler af denne side.

2. Repository (Repo)

En mappe, der indeholder alle filer i projektet sammen med den komplette historik over alle ændringer, der nogensinde er lavet. Denne side lever i et enkelt Git-repository hostet på GitHub. Repoet er den eneste kilde til sandhed — hvis det ikke er i repoet, eksisterer det ikke.

Git

Versionsstyringssystemet, der driver repositoryet. Git sporer hver ændring som en serie af øjebliksbilleder, lader flere arbejdslinjer køre parallelt og gør det nemt at fortryde fejl. Det kører lokalt på udviklerens maskine (eller i Claude Codes miljø) og synkroniserer med GitHub.

Source Code

De menneskelæsbare (og AI-læsbare) filer, der udgør apps: TypeScript, HTML, CSS, JSON-datafiler, konfiguration og mere. Source code er det, der redigeres; det bliver senere omdannet til de filer, browseren faktisk kører.

3. Arbejde på en branch

Før der laves ændringer, oprettes en ny branch — en parallel kopi af kodebasen. Det holder igangværende arbejde adskilt fra den stabile main-branch. Branches er billige og til engangsbrug; du kan have mange på én gang. Navngivningen antyder ofte formålet, f.eks. claude/add-glossary-page.

4. Skrive & redigere kode

Claude Code (eller en menneskelig udvikler) opretter og ændrer filer i repositoryet. Det kan betyde at skrive nye komponenter, redigere HTML, opdatere konfiguration eller tilføje datafiler. Udvikleren kan til enhver tid se, hvad der er ændret, ved hjælp af git diff, som fremhæver hver tilføjet, fjernet eller ændret linje.

5. Committe ændringer

Et commit er et gemt øjebliksbillede af projektet på et bestemt tidspunkt. Hvert commit samler et sæt relaterede ændringer med en besked, der forklarer, hvad der blev ændret og hvorfor. Commits er permanente og udgør projektets historik — du kan altid gå tilbage til ethvert tidligere commit.

Staging (git add)

Før du committer, vælger du præcis, hvilke ændrede filer der skal inkluderes. Dette kaldes staging. Det giver dig mulighed for at lave et rent, fokuseret commit, selv hvis du har ændret mange filer — du stager kun dem, der er relevante for den aktuelle opgave.

6. Pushe til GitHub

Pushing uploader dine lokale commits til det fjerne repository på GitHub, så andre (og automatisering) kan se dem. Indtil du pusher, eksisterer dit arbejde kun på din maskine. At pushe gør branchen og dens commits tilgængelige for hele projektet.

GitHub

En platform til at hoste Git-repositories online. Den tilføjer samarbejdsfunktioner — pull requests, issues, code review, actions — oven på Git. Tænk på det som projektets hjemmebase på internettet.

7. Åbne en Pull Request (PR)

En pull request er et formelt forslag om at merge din branch ind i main. Den viser hver ændring side om side ("diff"), lader reviewere skrive kommentarer på specifikke linjer og fungerer som en registrering af, hvorfor ændringen blev lavet. PR'er er checkpointet mellem "arbejde udført" og "arbejde leveret."

Code Review

Processen med at gennemgå en persons foreslåede ændringer, før de går live. Reviewere kan godkende, anmode om ændringer eller stille spørgsmål direkte på pull requesten. Det fanger fejl, forbedrer kvaliteten og deler viden. I dette projekt gennemgår brugeren, hvad Claude Code har skrevet.

Diff

En linje-for-linje sammenligning, der viser præcis, hvad der blev tilføjet (grøn), fjernet (rød) eller ændret i et sæt commits. Diffs er det centrale visuelle element i pull requests og code review — de besvarer spørgsmålet "hvad er anderledes?"

8. Merging

Når en pull request er godkendt, bliver den merget — dens commits bliver foldet ind i main-branchen. Efter merging bliver feature-branchen typisk slettet, da dens arbejde nu lever i main.

Merge Conflict

Når to branches ændrer de samme linjer på forskellige måder, kan Git ikke automatisk kombinere dem. Dette er en merge conflict. Et menneske (eller Claude Code) skal manuelt beslutte, hvilken version der skal beholdes. Konflikter er normale og som regel nemme at løse.

9. Automatiseret Build & Deploy (CI/CD)

I det øjeblik kode lander på main, starter GitHub Actions automatisk. En workflow-fil (gemt i repoet som .github/workflows/deploy.yml) definerer trinnene: installér dependencies, byg hver React-app, saml hele sitet og deploy det. Ingen menneskelig indgriben nødvendig.

GitHub Actions

GitHubs indbyggede automatiseringssystem. Det kører workflows som reaktion på hændelser (som et push til main). Hvert workflow er en serie af trin, der kører i en ny virtuel maskine. Dette projekts action bygger tre React-apps og samler dem sammen med de statiske apps.

Workflow

En YAML-konfigurationsfil, der fortæller GitHub Actions, hvad den skal gøre. Dette projekts workflow installerer Node.js, kører npm ci og npm run build for hver React-app, kopierer de statiske apps og uploader resultatet som en deploybar artifact.

Build

Processen med at omdanne source code til optimerede filer, som en browser kan køre. Vite kompilerer TypeScript, bundler JavaScript-moduler, behandler CSS og producerer en dist/-mappe. De statiske apps (Calendar Puzzle, Pokémon) springer dette trin over — de er allerede browserklar.

npm (Node Package Manager)

Værktøjet, der installerer tredjepartsbiblioteker (React, Vite, Tailwind osv.), som apps afhænger af. npm ci installerer præcise versioner fra en lock-fil; npm run build starter build-processen.

Dependencies

Eksterne biblioteker, som projektet er afhængigt af. Listet i hver apps package.json-fil med præcise versioner låst i package-lock.json. Eksempler: React til UI-rendering, Vite til building, Tailwind til styling.

Artifact

Det endelige output fra build-trinnet — en samling filer klar til at blive serveret. Deploy-workflowet samler alle apps i en enkelt _site/-mappe, som bliver den artifact, der uploades til GitHub Pages.

10. Live på GitHub Pages

GitHub Pages serverer artefakten som en rigtig hjemmeside på msvante.github.io/apps/. Inden for få minutter efter merging af en PR er ændringerne live, og alle med URL'en kan se dem. Cyklussen er komplet: idé → kode → review → merge → build → deploy → live.

Deploy

Det sidste trin: at publicere det byggede site, så det er tilgængeligt på internettet. I dette projekt uploader GitHub Actions _site/-mappen til GitHub Pages, som serverer det som en statisk hjemmeside. Ingen servere at administrere — det bare virker.

Andre nyttige begreber

Issue

En sporet opgave, fejlrapport eller funktionsanmodning på GitHub. Issues er måden, arbejde bliver planlagt og diskuteret, før der skrives kode. De kan refereres fra commits og pull requests for at koble "hvorfor" til "hvad."

Clone

At downloade en fuld kopi af et repository (inklusiv hele dets historik) til din lokale maskine. Dette er det første trin, når man begynder at arbejde på et projekt. Claude Code arbejder på en clonet kopi af dette repo.

Fork

En personlig kopi af en andens repository på GitHub. Forks lader dig eksperimentere frit uden at påvirke det originale projekt. Ændringer kan foreslås tilbage via pull request.

Main Branch

Den primære branch i repositoryet, kaldet main. Den repræsenterer projektets aktuelle "officielle" tilstand. Kode når kun main gennem reviewede og mergede pull requests. Pushes til main udløser deployet.

Remote / Origin

Den version af repositoryet, der lever på GitHubs servere (i modsætning til din lokale kopi). Af konvention kaldes det origin. At pushe sender dine commits til remote; at pulle henter ændringer derfra.

CLAUDE.md

En speciel markdown-fil i repositoryet, der giver instruktioner til Claude Code. Den beskriver projektets struktur, konventioner og regler, som AI'en skal følge. Tænk på det som et briefingdokument til AI-udvikleren.

CI/CD (Continuous Integration / Continuous Deployment)

Den overordnede praksis med at automatisere vejen fra kodeændring til live site. "Continuous Integration" betyder, at ændringer automatisk bygges og testes. "Continuous Deployment" betyder, at de automatisk publiceres. Dette projekt gør begge dele via GitHub Actions.

Environment

Den kontekst, hvori kode kører. Development-miljøet er der, hvor kode skrives og testes. Production-miljøet er det live site, som brugere besøger. GitHub Actions leverer build-miljøet — en midlertidig maskine, der kompilerer koden.

Generel teknologi

GitHub Pages

Den gratis hostingtjeneste fra GitHub, der serverer denne side. Hvert push til main-branchen udløser et deploy, der bygger og publicerer alle apps.

Vite

Et hurtigt build-værktøj, der bruges af de React-baserede apps (Lineup Guesser, Bracket City, Hangman). Det bundler source code til optimerede filer til browseren.

React

Et JavaScript UI-bibliotek. De fleste apps på denne side er bygget med React og TypeScript ved hjælp af components og hooks til at håndtere spiltilstand.

TypeScript

Et typet superset af JavaScript. Tilføjer type-annotationer for at fange fejl, før koden kører. Bruges af de React-baserede apps.

Tailwind CSS

Et utility-first CSS-framework, der lader dig style elementer med korte klassenavne (f.eks. bg-blue-500) direkte i HTML. Bruges af nogle af React-apps.

Static App

En app bygget med ren HTML, CSS og JavaScript — intet build-trin påkrævet. Calendar Puzzle og Pokémon-spillene er statiske apps.

Spilkoncepter

Hint alle spil

Et valgfrit fingerpeg, du kan bede om under et spil. Hints gør puslespillet lettere, men koster normalt point eller reducerer din score.

Streak

En tælling af fortløbende rigtige svar. Bruges i spil som Who's That Pokémon til at holde styr på, hvor mange du får rigtigt i træk.

Daily Puzzle

Et puslespil, der skifter én gang om dagen, så alle spillere får den samme udfordring. Bruges af Calendar Puzzle og Bracket City.

Fuzzy Matching

En tilgivende måde at tjekke svar på. Små tastefejl og manglende accenter tolereres ved hjælp af teknikker som Levenshtein distance. Bruges i Lineup Guesser.

Levenshtein Distance

Et mål for, hvor forskellige to strenge er, ved at tælle det mindste antal enkelttegnsredigeringer, der skal til for at omdanne den ene til den anden. Driver fuzzy matching i Lineup Guesser.

App-specifikke begreber

Formation Lineup Guesser

Den taktiske opstilling af spillere på banen (f.eks. 4-3-3, 3-5-2). Hver kamp bruger en rigtig formation fra Premier League.

Bracket / Nested Bracket Bracket City

En ledetråd pakket ind i firkantede parenteser. Brackets kan indeholde andre brackets, og indre brackets skal løses, før den ydre kan løses.

Hidden Word Hangman

Det enkelte ord i en nyhedsoverskrift, som du skal gætte bogstav for bogstav. Resten af overskriften vises i gråt som kontekst.

Silhouette Pokémon

En sortfarvet omrids af en Pokémon. Din opgave er at identificere, hvilken Pokémon det er, udelukkende ud fra formen.

Pentomino Pieces Calendar Puzzle

De formede brikker, du placerer på brættet. Inspireret af DragonFjord A-Puzzle-A-Day skal du arrangere dem, så kun dagens dato er utildækket.