Kapitel 1. Indledning

1.1 Hvad er informatik

Informatik er et ret nyt fag. De første elver startede i august 2017, og faget er obligatorisk på HHX. Det er planen, at andre gymnasielle uddannelser også skal have det som obligatorisk fag.

Baggrunden er, at vi efterhånden er storforbrugere af IT. Vi bruger IT, men IT bruger også os. Vi er nødt til at være klogere på IT i bred forstand for at forstå meget af det, der foregår omkring os.

Nogle af de emner, vi skal igennem, er;

• Hvordan er en app opbygget
• Hvordan laver man brugervenligt design
• Hvordan påvirker informationsteknolOgien os, og hvordan påvirker vi den
• Hvad er data, og hvad kan det bruges til
• Hvad er en database
• Hvordan laver man hjemmesider

Link til toppen af siden.

Kapitel 2. Forberedelse til en app

2.1 Prototyper

Hvis man skal bygge et hus, så starter man med en plantegning. Det forstår både dem, der skal have et hus, og dem, der skal bygge det. Så kan man tage på ferie og når man kommer hjem, står huset præcist som aftalt.

Sådan er det langt fra med apps. Her er vi nødt til at kunne snakke sammen undervejs og justere undervejs. Vi er på forhånd slet ikke så sikre på det færdige produkt, som vi er med et hus eller en madopskrift. Derfor har vi brug for, at vi kan snakke sammen undervejs og korrigere projektet om nødvendigt. Meget mere om det i kapitel 4. Udviklingsmodeller

En vigtig brik i app udvikling er modeller eller prototyper. Prototyper er ikke et færdigt produkt. Det ligner bare det færdige produkt så meget, at både udvikler og kunde kan forstå hinanden og komme videre i projektet. Det er langt billigere at lave en prototype end at lave et færdigt produkt.

Der er frit spil i forhold til at vælge, hvordan en prototype skal laves. Det kan være en tegning, noget i PhotoShop eller endda en PowerPoint. Her er en model for boligindretning.

Link til toppen af siden.

2.2 Målgrupper

Hvis vi vil overbringe folk et budskab, så skal vi gøre os klart, hvem målgruppen er. En af de mest brugte modeller er Minerva-modellen.

Minerva deler målgrupperne ind efter 2 akser. Moderne kontra traditionel og idealistisk kontra materialistisk. Det giver 4 områder:

• De blå: Typisk højreorienterede, vellønnede, ledere. Prestige, tro på sig selv, resultatorienteret. Måske er det ikke tilfældigt, at f.eks. Venstre har en blå partifarve.
• De violette: Typisk faglærte, men mere orienteret mod traditionelle værdier. Praktikere, orienteret mod spænding. De elsker Olsen-Banden og de traditionelle kan finde på at stemme på Dansk Folkeparti
• De rosa: Politisk midten, en del kvinder, idealister frem for materialister. Tradition, det nære miljø, familie
• De grønne: Idealister og moderne. Her har vi “økoflipperen” og folk, der stemmer på alternativet. Engagement, fællesskabsorienteret, principmennesker

En sidste gruppe, du ikke finder i modellen, er de grå. De er gruppen i midten, som kan være svære at placere. De kan have kendetegn fra flere kategorier på en gang.

Link til toppen af siden.

2.3 AIDA(S)-modellen

Der er hård kamp om vores opmærksomhed. Vi bruger gerne AIDA modellen som en model for, hvordan vi kan fange folks opmærksomhed. Det gælder især salg af produkter, men det gælder også, hvis man f.eks. vil have folk til at gøre bestemte ting. F.eks. at lære folk at holde afstand i forbindelse med corona.

AIDA(S) står for

• A = Attention. Fang folks opmærksomhed
• I = Interest. Gør tilhøreren interesseret, f.eks. i et produkt
• D = Desire. Skab et behov, få dem til at ønske at eje produktet
• A = Action: Handling. Tilhøreren skrider til handling og f.eks. køber produktet
• (S) = Satisfaction. At forbrugeren er tilfreds med sit køb

2.4 Direkte og indirekte reklame

• Direkte reklame. Her vises produktet direkte og/eller det omtales direkte. F.eks. ved en reklame for Coca-Cola. Der er ingen tvivl om, hvem der er “hovedpersonen”
• Indirekte reklame. Her er reklamen “implicit” eller indforstået. Hvis nu Coca-Cola reklamen foregår foran Eiffeltårnet i Paris, så er det indirekte reklame foran Eiffeltårnet

Link til toppen af siden.

Kapitel 3. Det grafiske puslespil

Der er mange elementer, som du skal få til at spille sammen, når du skal lave et layout eller en prototype. Kend reglerne og respekter reglerne, men være heller ikke bange for at bryde dem.

Tænk på dit layout som en god film. En opskrift på en god film kan være:

Den gode film har …	Det gode layout har derfor …
– En eller få hovedroller	– Overskriften og/eller få elementer overstråler alt andet
– Birollerne i et film skal være synlige. Mere synlige end statisterne, men ikke så dominerende som hovedrollen	– Under-overskrifter eller ikke-så-vigtige billeder/grafik skal være mindre end hovedoverskriften, men ikke så synlige som brødteksten

• En god film har en eller 2 hovedpersoner. Derfor: Overskriften og/eller et dominerende billede overstråler alt andet
• Birollerne i et film skal være synlige. Mere synlige end statisterne, men ikke så dominerende som hovedrollen. Derfor: Under-overskrifter eller ikke-så-vigtige billeder/grafik skal være mindre end hovedoverskriften, men ikke så synlige som brødteksten
• Statisterne giver filmen fylde, men de er anonyme. Derfor: Brødtekst er vigtig, men må ikke overstråle overskrifterne
• I en god film er der en klar handling. Derfor: Hjælp din læser. Skru op for billeder og grafik, ned for unødvendig tekst
• En god film har orden og hiraki. Derfor. Sørg for, at det vigtige træder frem. Baggrunden skal fremhæve forgrunden

I de næste 3 afsnit gennemgår jeg kort forskellige elementer inden for grafik: Typografier, farver og gestaltlove.

Link til toppen af siden.

3.1 Typografier

Typografier er det samme som skrifttyper. Man kan dele alle skrifttyper ind i 2 slags skrift: Serif og sans-serif. Serif betyder “fod”. Nogle typer skrift har en lille fod på bogstaverne, andre har det ikke.

Hvis vi sætter en lille fod på bogstaverne, så danner bogstaverne en kunstig linje. Den linje hjælper os især, hvis vi laver lange tekster. Til korte tekster er det bedre med skrifttyper uden fødder. På nettet finder vi mest sans-serif skrifttyper.

Skrifttyper kan understrege vores budskab. Den her skrifttype er f.eks. meget brugt i det vilde vest i USA.

Hos www.dafont.com kan du finde en guldgrube af sjove skrifttyper, grænsende til det vanvittige.

Hvis emnet interesserer dig, så kik på artiklen her, som har undersøgt brugen af typografier på hjemmesider generelt: https://www.smashingmagazine.com/2009/08/typographic-design-survey-best-practices-from-the-best-blogs/

Link til toppen af siden.

3.2 Farvelære

Vi bruger farver mere end vi tror. Farver kan hjælpe os med at understrege budskabet. Kik f.eks. på http://play.barbie.com/da-dk, hjemmeside for barbiedukken. Et orgie i bløde pastelfarver, men siden henvender sig også til små piger, ikke til voksne. Ikke overraskende er hjemmesiden for Rammstein, tysk heavyrock-gruppe, noget mere “maskulin” i sit udtryk. https://www.rammstein.de/de/. Politiet bruger kølige, alvorlige farver for at understrege autoritet, mens en klovn i cirkus er et orgie af varme og stærke farver.

Farvelære handler om at forstå farver. Start med Goethes farvecirkel. Ud fra 3 grundfarver: Rød, blå og gul dannede han alle mulige andre farver.

Farvecirklen fortæller os en masse. 2 farver på hver sin side af cirklen vil fremhæve hinanden. En orange farve fungerer godt med blå baggrund og omvendt. Dette kalder man for “kontrastfarver”. Der er dog en vigtig undtagelse: Brug aldrig kontrastfarverne rød-grøn sammen, for farveblinde kan ikke se forskel.

BEGREB	FORKLARING
Kontrastfarver	Farver, der står overfor hinanden i farvecirklen. Kontrastfarver fremhæver hinanden
Varme og kolde farver	Varme farver træder frem og er gode forgrundsfarver. Kolde træder tilbage og er gode baggrundsfarver. Varme og kolde farver står overfor hinanden i farvecirklen. Verdens bedste baggrundsfarve er … grå. Kik på grå beton, al grafitti træder tydeligt frem.
Farvefamilier	F.eks. pastelfarver, jordfarver, pangfarver. Man kan skabe en god sammenhæng ved at bruge farver fra samme farvefamilie.

Faktaboks: Farver på en skærm Alle farver på en skærm er sammensat af kun 3 farver: Rød, grøn og blå. Det kalder man for RGB-farver. Hvad med hvid og sort? Ved hvid skruer man helt op for farvernes lysstyrke, ved sort helt ned. Rød laver man ved at skrue helt op for den røde farve og helt ned for grøn og blå. Der er ca 1 mio. forskellige farver I alle programmer, der arbejder med farver, kan du sammensætte dine egen farver. Her i Microsoft Office på en PC, Mac er lidt anderledes. Bemærk muligheden for at blande rød, grøn og blå nederst.

I de næste videoer kan du lære om både teoretisk farvelære og om farvelære i praksis.

Link til toppen af siden.

3.3 Gestaltlovene

Når vi ser på ting, har vi nogle ubevidste måder at opfatte (eller “perceptionere) tingene på. Vi ser “skikkelser” eller på tysk “gestalter”, “hvad der er stillet i orden. Hjernen forsøger at skabe sammenhænge i, hvad den ser. Disse måder er formuleret i gestaltlovene.

GESTALTLOV	FORKLARING	EKSEMPEL
Loven om nærhed	Symboler, der er anbragt nær hinanden, opfattes som hørende sammen
Loven om lighed	Symboler, der ligner hinanden, opfattes som hørende sammen
Loven om lukkethed	Symboler, der står i samme ramme, opfattes som hørende sammen
Loven om forbundethed	Symboler, der er forbundne, opfattes som hørende sammen
Loven om figur og baggrund	Den mindste, afgrænsede figur på arealet vil først blive opfattet som figuren
Loven om symmetri	Hvis 2 figurer er anbragt symmetrisk omkring en linje, så opfattes de som hørende sammen.

Faktaboks: Hvad er en gestalt? En gestalt er tysk for “skikkelse”. Et eksempel: Vrede Viggo går i terapi, fordi han er rasende på sin far. Tereapeuten beder Viggo forestille sig, at hans far sidder i en stol overfor ham, og så får Viggo ellers lov til at fortælle hans far et par borgerlige ord. Faderen er selvfølgelig ikke til stede fysisk. Den form for terapi kaldes “gestaltterapi”

Gestaltlovene har enorm betydning, når man laver grafisk design. Hvis man f.eks. (som på denne hjemmeside) lukker navigationen inde i en ramme, anbringer dem tæt ved hinanden og giver dem samme typografi, så opfatter hjernen alle menupunkter som hørende sammen. Det er pga. loven om lukkethed, lighed, nærhed og måske loven om symmetri. Kik selv efter.

Jeg har lavet en video til dig om gestaltlovene.

Link til toppen af siden.

3.4 Gode råd til din grafiske produktion

Her er et par gode råd.

• Sørg for, at alt tekst er nemt at læse. Mørk tekstfarve på mørk baggrund er sjældent en god idé
• Brug kølige farver til baggrund og varme til forgrund
• Tænk på målgruppen og design efter det
• Overhold gestaltlovene
• Skab symmetri og sæt de grafiske elementer på linje
• Skab orden. Det vigtigste skal være tydeligt
• Skab genkendelighed. Genbrug farver, grafik og skrifttyper. Det gør brugeren tryg
• KISS (Keep It Simple and Stupid)

Eksempel 1. Baggrund- og forgrundsfarve

Den første er rædselsfuld. Lys tekst på en skriggul baggrund. Jeg får næsten ondt i øjnene. Nr 2 er bedre. Der er en god kontrast, men den gule baggrundsfarve dominerer teksten. Nr. 3 er god. Diskret baggrundsfarve, god kontrast og teksten får hovedrollen.

Eksempel 2. Symmetri

Ove Schneiders løbesidet. Der er INGEN symmetri. Siden er så rodet, så det nærmest er kult.

Gucci har selvfølgelig en helt anderledes orden og symmetri. Der er tænkt over hver en lille stump grafik her, og tingene er millimeter symetriske.

Skab orden og symmetri og hiraki

Her er et forslag til en AGF fanside. Det er svært at se, hvad der er vigtigst da alle skrifttyper er lige store. Navigationen er virkelig rodet. Men ok, det er en side for fanfraktionen “Tossehjørnet”, så de er tilgivet. Der er i øvrigt ingen hjørner på Aarhus Station :-).

Nu er der skabt noget orden. Overskrifterne har et hiraki, der er orden på navigationen, og der er symmetri. Dvs. at tingene er på linje eller centrerede.

Alt i alt. Kend reglerne. Du må gerne bryde reglerne, men du skal kunne argumentere for det. Et eksempel: Fodboldholdet Liverpool er et af verdens mest populære hold. De spiller i rødt. Rød er en meget varm farve, og duer som udgangspunkt ikke som baggrundsfarve. Jeg har alligevel set et fornuftigt forslag til en hjemmeside for Liverpool med rød baggrund.

Link til toppen af siden.

Kapitel 4. Udviklingsmodeller

4.1 Vandfaldsmodellen

Hr og fru Nygift har købt en grund til et hus, hvor de skal bygge og bo. De hyrer en arkitektfirma, de bliver enige om hvordan huset skal se ud plus en pris. Så går byggeriet i gang. Først rydder man grunden, støber fundamentet, bygger murene, holder rejsegilde osv. osv., og til sidst får Hr. og fru Nygift nøglerne i hånden. Huset ser ud som aftalt, og alt er dejligt.

Kendetegnende for huset som projekt er, at når man først har tegningerne, så er både kunden og bygherren en rigtig god og fælles idé om det færdige resultat. Det er også kendetegnende, at man tager en ting af gangen. Man siger, at man arbejder i faser. Når først en fase er afsluttet, f.eks. hvis murene er opført, så går man ikke tilbage og ændrer på fundamentet eller tegningerne. Man går heller ikke i gang med taget, mens man støber fundamentet.

Udviklingsmetoden kaldes for “vandfaldsmodellen”. Den er kendetegnet ved, at at vi lukker en fase helt, før vi starter den næste.

Link til toppen af siden.

4.2 Agile metoder

Vandfaldsmodellen er en traditionel metode til at lede projekter. Den metode brugte man også til IT-projekter, men man stødte hurtigt ind i nogle problemer:

• Det var svært at lave udspecificeret kravspecifikation, for vi ved ikke helt, hvordan det færdige produkt skal se ud
• Udviklerne kunne støde ind i ting undervejs, der ændrede projektet. F.eks. at noget udvikling viser sig at være uforholdsmæssigt dyrt
• Det samme for kunden. Kundens behov kunne sagtens ændre sig undervejs.
• Alt i alt kunne både kunde og producent stå med en fornemmelse af, at kravspecifikationen var en klods om benet, snarere end en hjælp

Derfor begyndte man at bruge helt andre projektmodeller til IT-projekter. De kaldes “agile” metoder. “Agil” betyder “bevægelig” eller “adræt”. Kongstanken ved agile (bevægelige) metoder er, at vi skal kunne tilpasse projektet undervejs, fordi vi bliver klogere hen ad vejen. Modsat byggeri så har vi ikke fuld viden om det færdige resultat i starten af projektet, til gengæld gør det ikke noget, hvis vi laver lidt om her og der.

Måden vi gør det på, er ved at blive enige om en ramme for projektet. Typisk en kerne, som skal være i orden. Rundt om kernen nogle ting, som kunne være rare at få, men som kan ændres undervejs.

Så holder vi et startmøde med kunden og bliver enige om de første skridt, kaldet et “scrum”. Vi designer, implementerer og afprøver ligesom i vandfaldsmodellen. Det nye er, at vi allerede efter typisk 2 – 4 uger holder et nyt møde med kunden. Så tager man resultaterne op til vurdering og planlægger de næste 2 – 4 ugers udvikling.

Perioderne fra et kundemøde til det næste kalder man et “sprint” eller en “iteration”, vist med en cirkel i figuren nedenfor. Sådan bliver man ved, indtil projektet er i hus. Den tætte kontakt mellem kunde og udvikler sikrer, at projektet hele tiden justeres efter både kundens behov og de ressourcer, der er til rådighed. “Fail often, fail early”: Jo tidligere vi fanger fejlene, jo nemmere og billigere er det at rette dem.

Faktaboks: Hvad betyder “scrum”? Udtrykket scrum stammer fra rugby. Spillerne står i en klynge, når bolden gives op, næsten som i amerikansk fodbold. Så sker der noget, og efter kort tid stopper spillet igen, og man laver en ny scrum. Scrum hentyder til, at IT-udvikling er et tæt teamwork. Her er et billede af scrum i rugby:

Link til toppen af siden.

4.3 Fordele og ulemper ved vandfaldsmodeller hhv. agile metoder

Fordele og ulemper ved agile hhv. vandfaldsmodeller.

	VANDFALDSMODELLEN	AGILE METODER
FORDELE	– Velegnet til projekter, hvor vi er helt sikre på slutproduktet – Revisoren bliver glad: Det er nemt at dokumentere – Det er også nemt at placere ansvaret	– God til at fange fejl undervejs og få dem rettet .Virker meget mere fleksibel end vandfaldsmodeller – Tæt kontakt med kunden hele tiden, kunden får et medansvar
ULEMPER	– Kan virke stiv og gammeldags – Svært at gå tilbage og rette fejl	– Kræver mere af projektlederen, fordi man ikke har en helt så fast køreplan – Kræver høj grad af tillid mellem udvikler og kunde – Ved uenigheder kan det være sværere at placere ansvaret

Link til toppen af siden.

4.4 Hvad ender vi så med for et produkt

Næsten alle virksomheder har et ERP system. ERP står for “Enterprise Resource Planning”. Kernen i systemet er bogholderiet eller regnskabet, men ERP systemer kan og bliver udvidet til at kunne styre næsten alt i en virksomhed. Løn, lager, produktion, fakturering, snart sagt alt. I faget virksomhedsøkonomi vil du helt sikkert støde på ERP systemer.

Vi siger nu, at en virksomheds ERP system er blevet forældet, eller at virksomheden f.eks. har købt en anden virksomhed, og at de 2 ERP systemer nu skal kobles sammen. En kæmpe opgave med et kæmpe ansvar.

Deres projekt ser sådan ud:

Hvis man styrer projektet ud fra traditionel projektledelse, dvs. vandfaldsmodellen, vil man typisk få det her resultat.

Hvis vi i stedet havde styret efter agile metoder (agil = “bevægelig”, “forandringsparat”), så havde vi fået det her resultat:

Vandfaldsmodellen er forudsigelig, men svær at tilpasse. Agile metoder er mere uforudsigelige, men nemmere at tilpasse.

Link til toppen af siden.

Kapitel 5. Arkitektur i programmer

Susanne Sulten og Arne Appeltit går på restaurant “Mad & Mæt”. Under måltidet betjener en høflig og velklædt tjener dem. De afgiver en ordre, og tjeneren går ud med ordren i køkkenet. Susanne og Arne har ikke adgang til køkkenet. Når dagen er slut, rydder de op i køkkenet, og “Mæt & Mad” lukker og slukker. Madopskrifter og lager af mad gemmer restauranten et sikkert sted, så det er klart til dagen efter.

99% af alle apps og programmer fungerer på næsten samme måde. De er opdelt i 3 ret adskilte lag:

• Frontend eller præsentationslaget.
• Backend eller forretningslaget
• Databasen eller datalaget

Brugerne ser programmet i frontend eller præsentationslaget. Det svarer til det område, hvor kunderne kommer i restauranten. Det skal være så præsentabelt og indbydende som muligt

Når hjemmesidens brugere klikker på noget, så aktiverer klikket kodning i backend eller forretningslaget. Det svarer til, at tjeneren modtager bestilling på mad og afleverer den ude i køkkenet. Vi vil ikke have brugerne ind i backend, og vi vil heller ikke have restaurantens gæster ud i køkkenet

Vi kan godt gemme ting midlertidigt i både frontend og backend i f.eks. variable og cookies. Du lærer senere mere om både cookies og variable.

Når vi slukker programmet, så slukker vi også for hukommelsen, og variablene slettes. Heldigvis har vi datalaget eller databasen. Her kan vi gemme oplysninger, f.eks. om kunder. Vi kan hente oplysningerne frem igen, selvom programmet har været slukket i et stykke tid. I restauranten gemmer vi opskrifter på nettet og har madvarer på frost, hvor de kan være gemt i lang tid

I figuren kan du se, hvordan lagene arbejder sammen. Frontend snakker med backend, der om nødvendigt henter ting ud af databasen og viser det til brugeren i frontend. Den stiplede linje viser, at vi kun vil have kunderne ind i frontend-området.

Hvis vi sætter det op i en tabel, ser det sådan ud. Jeg har tilladt mig at skrive nogle af de kodesprog på, som anvendes i laget.

LAG	BRUGES TIL	KODESPROG	HVIS DET VAR EN RESTAURANT
Frontend	Præsentationslag, ses af brugerne	Kun html, php og javaScript. Ingen andre sprog kan tolkes direkte i en browser	Kundeområdet
Backend	Forretningslogikken. Styre programmet og afvikler ordrer fra brugerne i frontend. Ingen adgang for kunder	Mest php og C# til hjemmesider, men også sprog som java, asp, vb.net m.fl.	Køkkenet, hvor retterne laves,
Database	Gemmer data, så de også er der efter, at programmet er slukket. Vi gemmer næsten alle data i tabeller lidt som i Excel	MySQL, hvis man skriver PHP. Ellers SQL ved C#	Det, vi gemmer, når personalet lukker restauranten. Madvarer, opskrifter mv.

Link til toppen af siden.

5.1 Et eksempel: Facebook

Et kik på Facebooks forside kan hurtigt forklare, hvad jeg mener.

Når vi ser Facebook, genkender vi hurtigt de mørkeblå og hvide farver. Det, vi ser, er selvfølgelig frontend. Hvis vi kikker op i højre hjørne, kan jeg logge ind med mit brugernavn og password. Hvis jeg indtaster brugernavn og password, overføres det indtastede til backend. Backend spørger videre ned i databasen, som jo har en oversigt over alle brugernavne og password på alle profiler i hele verden. Hvis jeg taster rigtigt, bliver jeg logget ind på min profil, ellers ikke.

Alt hvad jeg skaber på Facebook, fra tekst over billeder, videoer, likes …, alt bliver gemt i databasen. Hvis du begynder at tænke lidt over, hvor meget lagerplads Facebook har brug for, så er svaret: “Meget”.

Hvis du kan se et program/en app, så er der et frontend lag. Hvis du kan udføre noget i frontend, så har vi et backend lag. Hvis programmet kan huske noget fra sidst, du brugte programmet, så har programmet en database.

Link til toppen af siden.

Kapitel 6. Kodebegreber

I kapitel 5 lærte du, at vi har forskellige lag. Jeg nævnte kort, at vi har forskellige kodesprog til de forskellige lag, f.eks. HTML til frontend.

I dette kapitel skal du lære at genkende nogle kodebegreber, som optræder i næsten alle kodesprog. Man har begreber som variable, forgrening og betingelser, loops mv. i næsten alle kodesprog. Det svarer fuldstændigt til, at man har navneord, udsagnsord, tillægsord mv. i næsten alle talte sprog som f.eks. dansk, engelsk, tysk, spansk osv.

Alt i alt: Du skal kunne følgende udtryk:

UDTRYK	KORT FORKLARING
Variabel	En beholder, der kan rumme 1 og kun 1 værdi. Til gengæld kan du skifte indholdet lige så tit, du vil
Sekvens	Indholdet er ikke så vigtigt, det vigtige er, at koden afvikles i en bestemt rækkefølge
Forgrening og betingelse	Hvis en betingelse er opfyldt, så gør en ting. Ellers gør noget andet. Det er altid en hvis-sætning i koden. På engelsk kalder man det en if-then-else sætning
Arrays og loops	Et array er en række af variable. Et loop er en handling, der udføres igen og igen, indtil man er færdig
Funktioner	En stik-i-rend dreng, som man kan kode til at gøre alt muligt
Events og funktioner	En event er den begivenhed, der sætter funktionen i gang. F.eks. et klik på en knap
Kommentarer	Mennesketekst inde i koden. Kommentarer påvirker ikke resten af koden.

Video med overblik over kodebegreberne:

Link til toppen af siden.

6.1 Variable

Lær det her: “En variabel er en beholder, der kan rumme 1 og kun 1 værdi”. Til gengæld kan den skiftes ud lige så tit, man vil. Her er et par eksempler:

• Highscore i et spil
• Antal liv i et spil
• Din alder. Den bliver opdateret hvert år på din fødselsdag
• Målscore, tid, alt muligt inden for sportens verden
• Priser
• … osv. osv.

Her er der masser af variable. DeHviii (kælenavn for AGF’s hvidblusede fodboldhold) er foran med 2 – 0 mod Brøndby foran på et ret tavst Brøndby Stadion. Vi har brug for 2 variable: 1 til AGF’s målscore og 1 til Brøndbys. For AGF’s vedkommende har vi allerede ændret variablens indhold 2 gange. Vi har også brug for en variabel til tiden. I øvrigt ender kampen 3 – 0 til DeHviii. Det var en smuk dag den 25. august 2019 :-).

Video om variable

I AppLab definerer vi en variabel ved at skrive “var” + et navn. Vi sætter den gerne lig værdien af et indtastet felt.

Når først vi har defineret en variabel, kan vi bruge den overalt i vores program. Her er variablene vægt og højde defineret.

Link til toppen af siden.

6.2 Sekvens

En sekvens er en rækkefølge. Det er ikke så vigtigt, hvad sekvensen handler om. Det vigtige er rækkefølgen. Her er Gurli Gymnasieelevs rækkefølge, når hun står op om morgenen:

1. Slå vækkeuret fra
2. Gå ud på badeværelset
3. Jage lillesøster ud fra badeværelset, så hun kan få det for sig selv
4. Gå i bad
5. Spise morgenmad
6. Pakke skoletasken
7. Komme ud af døren
8. Nå bussen
9. Tjekke mobilen

Hvad nu, hvis Gurli gør tingene i en anden rækkefølge. Så går det galt!

1. Tjekke mobilen
2. Komme ud af døren
3. Spise morgenmad
4. Nå bussen
5. Jage lillesøster ud fra badeværelset, så hun kan få det for sig selv
6. Pakke skoletasken
7. Gå ud på badeværelset
8. Slå vækkeuret fra
9. Gå i bad

I kodning kan en sekvens bestå af alt mulig forskellig kode. Det skal bare gøres i den rigtige rækkefølge.

Et eksempel fra AppLab. Der er kun 3 kodelinjer i sekvensen her: De 2 lilla og den gule med setText. Men hvis vi byttede rundt på dem, ville det gå galt. Næsten alle programmer har sekvenser.

Link til toppen af siden.

6.3 Forgrening og betingelse

Forgrening og betingelse er det eneste sted i programmet, hvor man kan tage en beslutning. Hvis en betigelse er opfyldt, så gør …. Ellers gør sådan og sådan …

HVIS … SÅ …. ELLERS SÅ ….

I kodning bruger man en HVIS-sætning. På engelsk kaldes det en IF eller en IF-THEN-ELSE sætning. Et typisk eksempel kunne være, når man logger ind med brugernavn og adgangskode

1. Indtast dit brugernavn og adgangskode
2. HVIS (brugernavn og adgangskode er rigtige) SÅ (bliver du logget ind) ELLERS SÅ (prøv igen).

Her er en forklarende video om forgrening og betingelser.

I AppLab ser man if sætninger som blå kode. Her et eksempel, hvor der er hele 4 muligheder.

Link til toppen af siden.

6.4 Arrays og loops

Array betyder “række”. Det er en række fyldt med variable. Et eksempel: Hvis du vil have en elektronisk huskeseddel, så lav punkterne i et array i stedet for individuelle variable. Det gør det nemmere, når vi skal udskrive huskesedlen. Så vil programmet “loope” igennem huskesedlen og udskrive punkterne et for et, indtil alt er skrevet ud.

Du må gerne tænke på tivolier, når vi snakker loops. Folk står i arrays (rækker, dvs. køer) for at prøve loops. Man kan naturligvis have flere loops i et program lige som på billedet her:

Video om loops og arrays.

I AppLab ser det ud som vist nedenfor.

Vi definere et array frem for en variabel ved at skrive en firkantet parentes bagefter som i linje 2.

var huskeseddel = [“müstli”, “mælk”, “rosiner”, “the”];

Her er arrayet allerede udfyldt med 4 variable: “müstli”, “mælk”, “rosiner” og “the”. I linje 3 har jeg en helt almindelig variabel var print = “”. Vi bruger kun firkantede parenteser, når vi laver et array og ikke en variabel.

Hvis vi skal loope, bruger vi en “for” løkke som vist med blå farve i linje 4 – 7. For-løkken løber arrayet huskeseddel igennem og skriver elementerne i arrayet “huskeseddel” til variablen print.

Resultatet af kodningen ovenfor. Hvis du vil se det selv, så åben linket her i AppLab: https://studio.code.org/projects/applab/D9eamV28solo71FdkIWpQ-0vKqE2HAVWw34ZCmIeAxo

Link til toppen af siden.

6.5 Funktioner

En funktion er en stik-i-rend dreng. Den kan udføre en handling, f. eks. lægge 2 og 2 sammen, lave en liste, alt muligt. Hvis vi nu siger, at vores stik-i-rend-dreng kan hente en appelsinvand, og han arbejder for Verdensfirmaet A/S. Hvis firmaet var et program, så ville vi have en funktion, som vi kunne kalde “Appelsinvand”. Så vil alle medarbejderne altid bare kunne kalde på “Appelsinvand”, og så kunne de få hentet en appelsinvand når som helst og hvor som helst. Alle dele i koden kan bruge en funktion.

I øvrigt er alt kode, undtagen kommentarer, er pakket ind i funktioner. -Funktioner kan sagtens bruge eller kalde andre funktioner.

I App Lap er alt kode som udgangspunkt “pakket ind” i en funktion. Den grønne klamme, som rummer hele sekvensen, er en funktion. Bemærk at vi kan give funktionen et navn. Normalt bruger vi bare navnet “event”, som App Lab automatisk giver os. Men vi kunne kalde den for “valutaomregner” og så kalde den fra andre funktioner.

Link til toppen af siden.

6.6 Funktioner og events

Hvis brugeren klikker på noget i en app, så kalder man det en “hændelse” eller et “event”. I spil kan event også være, at man skyder fjenden, dør eller bare styrer sin figur i spillet. Et event kalder en funktion. Funktionen indeholder så kode (variable, sekvenser, forgrening og betingelser mv.), som kan udføre den ønskede handling.

En event er, når der “sker noget” i et spil eller en app. Her den kode, der skal afvikles, når eventen “Klik på button1” er sket. Bemærk at eventen kalder en funktion.

Link til toppen af siden.

6.7 Kommentarer

Kommentarer er mennesketekst, som man sætter ind i koden. Typisk bruger man det til at forklare, hvad der sker i koden. Hvis nu du selv kommer tilbage til din kode efter et par måneder, eller at andre skal forstå din kode, så er kommentarer nyttige.

I virksomheder, hvor de lever af at kode, har de strenge regler for, hvordan man laver kommentarer. Det gør, at programmørerne lettere kan forstå, hvad andre koder.

Her er en kommentar i AppLab. Den er med grå farve

Link til toppen af siden.

6.8 Sådan arbejder frontend og backend sammen

Når du skaber kode i App Lap, følger vi næsten altid det samme mønster.

• Vi starter med at oprette en begivenhed
• Begivenheden opretter en funktion
• Inden i funktion gør vi 3 ting
  • Henter data fra indtastningsfelter ind i variable
  • Beregner
  • Returnerer resultatet til backend

Det kan se sådan her ud.

Link til toppen af siden.