2014PrgC33

From rtgkomArkiv
Jump to: navigation, search

Contents

En virtuel spørgetime for Programmering C, Gkb 11:53, 17 June 2015 (CEST)[edit]

Hvis I fortsat, efter at have læst posten nedenfor med de to afsnit Referat af spørgetimen og Vejledning om forberedelse til eksamen, er usikre på et eller andet i forbindelse med eksamen, så skal I bare skrive en besked til mig i Lectio. Jeg skal prøve at huske at læse beskederne et par gange i dag og i aften.

God forberedelse!

Spørgetime - referat og generel vejledning om forberedelse til eksamen, Gkb 00:25, 17 June 2015 (CEST)[edit]

Vi havde spørgetime i fredags, altså den 12. juni, fra ca. 12:50 til ca. 14:00. Her kommer et referat af det vigtigste som vi diskuterede, og så afsluttes denne sidste post i holdets wikiatrikel med en generel vejledning om forberedelse til eksamen.

Referat af spørgetimen[edit]

Vi diskuterede først opbygning og indhold i præsentationen. En enkel model for præsentationen kan være at bygge den op således at den giver svar på følgende spørgsmål.

  • Hvad, altså hvilket produkt, har I lavet? I kan eventuelt vise selve produktet straks i begyndelsen af jeres præsentation.
  • Hvordan lavede I produktet? Her kan I både diskutere den metode som I har brugt til at styre arbejdet og også komme ind på nogle detaljer i implementeringen, for eksempel hvordan I har løst et af kærneproblemerne med en spike solution.
  • Hvordan blev resultatet? Altså hvordan kom produktet til at se ud og virke? Afsæt nogle minutter til at demonstrere hvordan produktet virker.

Vi diskuterede at elever som har lavet et projekt sammen godt kan bruge den samme multimediepræsentation som støtte ved den mundtlige prøve, -men jeg lagde vægt på at det vil være en gode idé at der er nogen slides/dias i præsentationen som handler specifikt om de emner som den enkelte gruppemedlem har primært været ansvarlig for. Hvis arbejdsfordelingen i gruppen ikke fremgår af rapporten, så er det en god idé at gøre rede for det i begyndelsen af præsentationen.

Vi flyttede os over i lokale C3101 hvor eksamen skal holdes, og diskuterede nærmere hvordan eksamen gennemføres. I skal sidde ved eksamensbordet på den side som vender mod tavlen hvor I har let adgang til maskinen som er koblet til projektoren. Den har Windows XP. I kan bruge den hvis I vil, men I kan også bruge jeres egen computer både til præsentationen og til at vise produktet, men selve produktet skal kopieres fra et USB stik som jeg har med til eksamen.

Vejledning om forberedelse til eksamen[edit]

Her følger kopier af nogle forskellige afsnit fra mine tidligere vejledninger om eksamensforberedelse, hovedsaglig hentet fra http://rtgkom.dk/wiki/2011PrgC34 og http://rtgkom.dk/wiki/2014InfB34, som i sin tur også bygger på tidligere artikler her i vores wiki.

Det meste af denne tekst er helt relevant også i år, men bemærk at jeg i år ikke kræver at I skal demonstrere jeres produkter og udviklingsmiljøer på vores computere!!! I kan bruge jeres egen computer til det, -det skal bare ske med de datafiler som I har afleveret og dem kan I få fra et USB stik i begyndelsen af eksamen.

Og bemærk at I ikke behøver bruge alle disse afsnit til noget, -dette er bare et tilbud om lidt forskellige idéer til hvordan I kan forberede jer lidt systematisk til den mundlige prøve.

Selve eksamen[edit]

I eksamenslokalet har vi en computer koblet til en projektor, denne computer kalder vi for eksamenscomputer. Præsentationer og produkter skal helst vises på denne computer. Udviklingsmiljøerne som I har brugt skal også installeres på denne computer. Jeres afleverede produkt, ofte hele mapper med flere filer, skal så kopieres fra webserveren ned på eksamensmaskinen. Bring jeres egen computer med til eksamen, således at den kan bruges som backup.

På eksamenscomputeren er installeret en PowerPoint Viewer og OpenOffice Impress. Men husk at multimediepræsentationer kan også laves som almindelige websider.

Det er bedst hvis vi slipper for at flytte video-kablet til projektoren, det tager ofte lang tid at få den til at virke med elevens computer, operativsystem og præsentationsprogram.

Der er 24 minutter til hver elev, og på den tid skal følgende nås:

  • Velkomst, hilse på hinanden osv. og eleven gør klar til at præsentere sit projekt.
  • Præsentation af projektet. Fri metode, men multimediepræsentationer vha. eksamenscomputeren og den tilkoblede projekter er en meget brugt tilgang. Men I kan også bruge tavlen, plancher eller papir som I deler ud til censor og eksaminator. Upload helst jeres præsentation til jeres StudieWeb, så slipper vi for at flytte videokablet, -det tager lidt tid fra jeres præsentation. Medbring den gerne også på en USB-hukommelsesenhed, og tag også gerne jeres egen computer med som reserve. Projektet kan præsenteres på mange måder, men der er i hvert fald to komponenter som i nogen grad fortjener opmærksomhed, nemlig:
    • Arbejdsgangen i projektet, hvad du/I lavede, hvorfor, og evt. for hvem (hvis der var/er en oplagt målgruppe) og måske mest interessant hvordan du/I lavede produktet (her kan man med fordel støtte sig til vores systemudviklingsmetode). Her kan I også præsentere teori og praktiske eksempler på brug af programmeringssproget, f.eks. variabler, datatyper, funktioner, moduler, løkker, osv. Se evt. nedenfor om repetition.
    • Resultatet af arbejdet, selve produktet, hvilket resultat opnåede I?. Programmet skal helst vises i funktion, og I må meget gerne bruge lejligheden til at vise at I er fortrolige med udviklingsværktøjerne. F.eks. åbne projektet, kompilere og køre programmet, forklare brugerfladens funktionalitet. Og så gør det godt indtryk hvis I kan lave en lille ændring i koden, og køre programmet igen og vise at ændringen er indført og virker.
  • Uddybende spørgsmål og diskussion, med udgangspunkt i jeres projekt.
  • Eleven forlader lokalet, og tager sine ting, computer osv., med sig!!!
  • Votering.
  • Meddelelse af karakter til eleven. NB. at eleven hentes ind i lokalet, så gå ikke for langt væk. Karakteren meddeles, men der forklares ikke hvorfor den er som den er, det er det ikke tid til, og det er heller ikke meningen. Dette er summativ evaluering, -slå evt. i SO-papirerne.
  • Eleven forlader lokalet, -forhåbentlig glad og lettet:)
  • Næste elev kommer ind og det hele gentager sig.

Tiderne for den enkelte elev er fastsat i Lectio og skal HELST overholdes. Derfor skal vi ikke bruge mere end de 24 minutter pr. elev. Det betyder at din præsentation kan max være på ca. 10 til 15 minutter. Eksamen kan vistnok godt tage kortere tid end de 24 minutter, men det er ikke ofte det sker.

I kan medbringe diverse hjælpemidler, som f.eks. jeres egen computer med jeres præsentation, produkt og udviklingmiljø. I kan køre hele jeres præsentation direkte fra den uden at bruge projektor, -det går udmærket.

Repetition, -hvordan?[edit]

  • Brug lærebogen, http://openbookproject.net/thinkcs/python/english2e/, specielt de første 7 kapitler. Der præsenteres det grundlæggende i programmering, for eksempel.
    • syntax
    • debuging, den process at søge, finde og rette fejl i programmet, bogstavligt fjernelse af insekter i koden
    • syntax error
    • runtime error
    • semantic error
    • low level programmeringssprog
    • high level programmeringssprog
    • compiler (oversætter)
    • interpreter (fortolker)
    • object code (maskinkode eller objektkode)
    • assembler, et program som oversætter symbolsk maskinkode (assembly language) til maskinkode
    • byte code
    • virtual machine
    • variable (variabel, en lagerplads for tal eller tegn, kan tildeles værdier (values))
    • data type (datatype, f.eks. integer, float, string)
    • operator (f.eks. +, -, *, / og **)
    • expression og value (udtryk og værdi)
    • evaluation (evaluering)
    • statement (sætninger)
    • funktion og parameter for funktioner
    • conditional execution (betinget udførelse vha. if og if-elif-else statements)
    • iteration (gentagelse, løkker, f.eks. vha for og while statements)
    • string (streng, sekvens af tegn)
  • Brug også gerne den generiske dokumentation for Python på http://python.org, se http://docs.python.org/index.html.
  • Hvis du har lavet dit projekt i andre sprog end Python, f.eks. Java, Object Pascal (f.eks. med Lazarus) så skal du selvfølgelig også orientere dig om de ovenfor nævnte grundlæggende aspekter i dette programmeringssprog.
  • Afprøv eksemplerne fra lærebogen, specielt de enkle i 2., 3. og 4. kapitel, som skal uføres interaktivt i Python shell'en. Det giver hurtig feedback og er sjovt. Prøv f.eks. type(0==0) og type(0=0), hvad siger interpreteren til det?

Fremstilling af en multimediepræsentation[edit]

Lav en præsentation hvor du præsenterer dit projekt. Den kan f.eks. struktureres således at den giver svar på følgende spørgsmål:

  • Hvad har du/I lavet og
  • Hvorfor har du/I lavet det og
  • Hvem er det lavet for og
  • Hvordan har du/I lavet det og (Dette er evt. den mest interssante spørgsmål. Her kan I f.eks. inddrage brugen af vores systemudviklingsmetode og diverse detaljer i forbindelse med jeres udviklingsmiljø og programmeringssproget. Brug skærmdumps!!!)
  • Hvilket resultat kom ud af det? (Husk at produktet sjældent bliver helt færdigt, hvis I kun nåede en del af det som I ville, så ret blikket frem og perspektiver over hvordan man kunne fortsætte, hvilken funktionalitet (user stories) skal med i næste prototype, altså hvad kunne man lave i næste iteration af systemudviklingsaktiviteterne?)

Demonstration af produkt og udviklingsmiljø[edit]

Der anvendes flere forskellig programmeringssprog og udviklingsværktøjer i klassens eksamensprojekter. Produkterne er af forskellig karakter og lader sig ikke alle lige let demonstrere til eksamen, men det er vigtigt som minimum at vise frem det resulterende produkt, det vil sige den sidste prototype som blev designet, implementeret og testet i projektet.

Ud over det kan det være en gode idé også at vise frem nogen eller alle af de tidligere prototyper, alt efter omstændighederne.

Og desuden kan det også være en god idé også at vise frem det udviklingsmiljø som blev anvendt til at udvikle produktet, og evt. vise hvordan en lille ændring kan laves på produktet og så vise hvordan ændring kommer til udtryk i produktet når det afprøves. Dette gælder både om projekter som kun består af software og også om produkter som består både af hardware og software. Dette gælder også om produkter som er udviklet ved hjælp af f.eks. 3D modelleringsværktøjer. Der kan laves ændringer på 3D modellen og effekten af denne ændring på det renderede billed eller animation kan observeres.

Det er vigtigt at gøre sig klart at det ikke er noget lodret krav om at fremvise udviklingsmiljøet og om at lave en ændring på produktet til selve eksaminationen, -men da I bruger så mange forskellige og avancerede værktøjer, så kan det både være ganske interessant og så viser det også noget om hvor godt I kender jeres værktøjer.

Det er også vigtigt at huske at demonstration af produktet skal ske med udgangspunkt i det afleverede produkt. For eksempel når det handler software, så er det de kildekodefiler som blev afleveret som skal bruges.

Hvis I ønsker at anvende projektoren til at vise produktet og evt. også udviklingsmiljøet, så er det meget vigtigt at anvende selve projektormaskinen til præsentationen, for at undgå at skulle flytte videokablet frem og tilbage mellem computere. Hvis du absolut skal koble din egen bærbare computer til projektoren, så må du prøve at øve det i god tid inden eksamen, således at du er forberedt og ved hvordan du skal bruge projektoren fra din maskine. Det kan både kræve særlige omformer-stik og så har de forskellige operativsystemer og præsentationsprogrammer ofte nogle specielle overraskene funktioner som aktiveres når man kobler en extern skærm til computeren. Det kan tage flere minutter at løse disse problemer!!!

På baggrund af de ovenfor nævnte forhold så foreslår vi følgende prioritering af hvordan fremvisning af produkter og udviklingsmiljø skal gennemføres:

  1. Fra projektormaskinen:
    1. Det er bedst hvis produktet kan demonstreres direkte ved hjælp af de filer som blev afleveret på projektets projektbruger. Dette lader sig normalt kun gøre i tilfælde af web-produkter.
    2. For andre produkter så kan filerne kopieres over til en mappe på desktoppen på projektormaskinen. Udviklingsmiljøet skal selvfølgelig være installeret i forvejen. Demonstrationen kan således ske på projektormaskinen uden at flytte vidoekablet.
  2. Fra din egen bærbare computer: Det kan i nogle tilfælde være den enkleste løsning at bruge din egen computer. Det gælder specielt hvis udviklingsmiljøet er svært eller evt. umuligt at installere på projektormaskinen, som pt. er en Windows XP med service pack 3 og .Net 4, vistnok. Hvis du bruger din egen computer, så er et en god idé at starte demonstrationen med at downloade de afleverede projektfiler fra projektbrugeren på rtgkom.dk.

Eksaminationens forløb[edit]

Der er afsat 24 minutter for hver elev. Et typiskt forløb kan være som følger. Bemærk at dette er min tolkning, baseret på erfaringen fra tidligere prøver. Bemærk også at eksamen kan godt tage kortere tid end de afsatte 24 minutter.

  1. Ca. 1 - 2 min. til at komme ind i lokalet, hilse på censor og starte præsentationen af projektet.
  2. Ca. 10 - 15 min. til præsentationen
  3. Ca. 5 - 10 min. til udybende samtale
  4. Ca. 1 min til at forlade lokalet. Tag din computer med!
  5. Ca. 2 - 5 min til votering
  6. Ca. 1 min til at hente eleven ind i lokalet og meddele karakteren. Bemærk at dette er summativ evaluering og der gives derfor ingen begrundelser for karakteren ud over det som ligger i selve karakteren og dens beskrivelse i "Bekendtgørelse om karakterskala og anden bedømmelse", https://www.retsinformation.dk/Forms/R0710.aspx?id=25308. Her kommer en lille kopi fra bekendtøgrelsen.
§ 2. Karakteren 12 gives for den fremragende præstation, der demonstrerer udtømmende opfyldelse af fagets mål, med ingen eller få uvæsentlige mangler.
§ 3. Karakteren 10 gives for den fortrinlige præstation, der demonstrerer omfattende opfyldelse af fagets mål, med nogle mindre væsentlige mangler.
§ 4. Karakteren 7 gives for den gode præstation, der demonstrerer opfyldelse af fagets mål, med en del mangler.
§ 5. Karakteren 4 gives for den jævne præstation, der demonstrerer en mindre grad af opfyldelse af fagets mål, med adskillige væsentlige mangler.
§ 6. Karakteren 02 gives for den tilstrækkelige præstation, der demonstrerer den minimalt acceptable grad af opfyldelse af fagets mål.
§ 7. Karakteren 00 gives for den utilstrækkelige præstation, der ikke demonstrerer en acceptabel grad af opfyldelse af fagets mål.
§ 8. Karakteren -3 gives for den helt uacceptable præstation.

Vi vil forsøge meget at følge den tidsplan som er lavet for eksamen.

Bærbar versus projektor[edit]

Det kan blive ret meget lys i lokalet om eftermiddagen projetorbilledet på væggen bliver så lidt utydeligt. Mange bærbare computere har en ret så god skærm, og det kan derfor være en god grund til bruge den bærbare maskine til præsentationen.

Du kan bruge din bærbare computer til både præsentationen og til at demonstrere produktet og udviklingsmiljøet. Du stiller bare maskinen på bordet framfor censor, og så kan du styre maskinen fra dens venstre side og jeg ser med fra højre side. Dette har virket udmærket før!

Pass på at oplade batteriet og/eller bringe strømforsyningen med til eksamen.

Backup af præsentationen[edit]

  • Udskriv gerne præsentationen på papir.
  • Læg den også op på dit StudieWeb.
  • Den skal selvfølgelig også ligge på din bærbare computer.

Bedømmelseskriterier og faglige mål[edit]

Her er en kopi af afsnittet om bedømmelseskriterierne som skal bruges til den mundtlige prøve. Bemærk at der henvises til målene i pkt. 2.1, og derfor har jeg også kopieret dem.

4.3. Bedømmelseskriterier

Bedømmelsen er en vurdering af, i hvilket omfang eksaminandens præstation lever op til de faglige mål, som de er angivet i pkt. 2.1.

Der lægges vægt på eksaminandens evne til at:

– konstruere enkle programmer

– anvende programdele og biblioteksmoduler og dokumentere deres anvendelse og oprindelse

– dokumentere programmer, så de er forståelige

– gå fra analyse af en given problemstilling til at opstille en løsning

– redegøre for den arbejdsproces, der har ført til løsningen

– reflektere over, hvordan problemstillingen ellers kunne løses

Der gives én karakter på grundlag af en helhedsbedømmelse af eksaminandens mundtlige præstation.

Og her er de faglig mål, og bemærk at "bedømmelsen er en vurdering af, i hvilket omfang eksaminandens præstation lever op til" disse faglige mål.

2.1. Faglige mål

Eleverne skal kunne:

– redegøre for programmering som planlægning af en computers aktiviteter, herunder interaktion med omgivelserne

– læse enkle programmer og redegøre for deres funktionsmåde og anvendelsesmuligheder

– rette og tilpasse enkle programmer

– anvende eksisterende programdele og biblioteksmoduler i arbejdet med at programmere et fungerende system

– demonstrere kreativitet og systematik i programmeringsprocessen

– løse en enkel problemstilling gennem udviklingen af et program.

Se gerne selv nærmere i bilaget for faget i valgfagsbekendtgørelsen, https://www.retsinformation.dk/Forms/R0710.aspx?id=132670. Programmering C beskrives i bilag 36.

Præsentationens opbygning[edit]

Der kom et spørgsmål om der skal laves en multimediepræsentation med et værktøj som f.eks. PowerPoint eller OpenOffice Impress eller som en webside, og svaret er Nej!, -det er ikke et krav at der skal laves den type af medieprodukt.

Men det er et krav at projektet skal præsenteres, og det kan være meget praktiskt at støtte sig til sådan en multimediepræsentation når man præsenterer projektet.

Her kommer nogle generelle bemærkninger om præsentationen som jeg gentog vistnok flere gange i onsdags:

  • Rettelsesblad, med en liste over fejl som du har opdaget i rapporten, kan uddeles i begyndelsen af præsentationen.
  • Vent ikke for længe med at vise selve produktet i brug.
  • Giv et overblik over projeket.
  • Dyk ned i nogle enkelte detaljer i designet og/eller koden, evt. i forbindelse med et problem/fjel som var svært at løse.
  • Vis gerne hvordan en lille ændring kan indføres i produktet.
  • Anvend ikke rapporten til direkte at strukturere præsentationen. Men brug gerne indhold fra den i præsentationen.

Grov model for indhold i præsentationen[edit]

Indeholdet i præsentationen kan kort beskrives således at præsentationen skal fortælle

  • hvad du/I gjorde i projektet,
  • hvordan du/I gjorde og
  • hvilket resultat der kom ud af dit/jeres arbejde.

En lidt mere udfoldet model for indhold i præsentationen[edit]

En lidt mere udfoldet model for opbygning af præsentationen kan være:

  1. Gør rede for problemstillingen og løsningsforslagene.
  2. Gør rede for det valgte løsningforslag.
  3. Gør rede for karv og forventninger til produktet.
  4. Gør rede for design af hvordan disse krav og forventninger kan implementeres.
  5. Gør rede for implementeringen af designet
  6. Gør rede for afprøvning

En mere udfoldet model for indhold i præsentationen[edit]

En mere udfoldet model for opbygning af præsentationne kunne være at støtte sig til de syv aktiviteter i vores systemudviklingsmetode.

Da hver aktivitet har to delaktiviteter, så er der 14 emner som kan inspirere til indhold i præsentationen, -og så gentages (itereres) fem af aktiviteterne for hver prototype som I har udviklet. Her er et link til beskrivelse af metoden: http://rtgkom.dk/wiki/MediaLab:_Systemudviklingsmetode

Udvælg de aktiviteter og delaktiviter som giver mening for dig og for dit projekt.

Computere til rådighed til eksamen[edit]

  • Projektormaskinen med Windows XP med service pack 3 og .Net 4, vistnok.
  • En maskien med Ubuntu vistnok 12.04, til højre for projektorlærredet. Kan ikke kobles til projektoren.
  • En Mac, til højre for projektorlærredet. Kan ikke kobles til projektoren.
  • Din egen bærbare computer kan også bruges.

Hvis du vil bruge disse eller andre maskiner i lokalet, så er et i orden, vi står gerne op og flytter os rundt i lokalet.

Produkter som består delvis af hardware[edit]

Afleveret hardware vil være i eksamenslokalet og kan kobles til projektorcomputeren eller din egen computer.

Aflevering af eksamensprojektet - journal og produkt, Gkb 12:18, 12 May 2015 (CEST)[edit]

Vi har fået lov af rektor til igen i år at lave en helt digital aflevering af projekter i PrgC og InfB, men for at minimere riskikoen for at jeres rapporter/journaler eller produkter forsvinder der i den digitale cyberspace, så har hun bestemt at vi skal aflevere i de tre systemer, altså på...

  1. Lectio - Rapport/journal og produkt
  2. Fronter - Rapport/journal
  3. rtgkom.dk - Rapport/journal og produkt

Husk at inkludere tro og love erklæringen, http://rtgkom.dk/~gkb/pubdoc/tro_og_loveerklaering.doc, lige efter forsiden i rapporten!

Husk at censor skal kun læse rapporten/journalen, og altså ikke teste produktet. Derfor er det vigtigt at dokumentere det færdige produkts funktion og udseende i rapporten/journalen, f.eks. vha. skærmbilleder, evt. i bilag hvis der er mange billeder. Af samme grund er det vigtigt at vedlægge hele kildekoden i bilag, også selv om det evt. er mange filer! Formater den i en ikke proportionel font (kaldes også monospace), som f.eks. Courier eller Courier New og helst ikke større end 10 punkter, for at undgå at mange linjer wrappes (deles).

Hvis du arbejder i en gruppe, så skal I aflevere individuelt både i Fronter og på rtgkom.dk. I Lectio kan I lave en gruppeaflevering.

Det skal selvfølgelig være præcis samme rapport/journal-fil som I afleverer alle tre steder. Aflever PDF version og orginal-filen (nok typisk DOCX eller ODT), fordi nogle gange er der problemer med PDF filerne og så har vi mulighed for at åbne orginalfilerne.

Det skal selvfølgelig være præcis samme produkt som I afleverer på Lectio og på rtgkom.dk.

Husk at lave en PDF version af rapporten/journalen, og test den på en anden computer end den hvor du laver den. Det kan nemlig være at den ser lidt anderledes ud end på din computer. Anledningen kan være at font-information for en font som ikke findes på den anden computer ikke er indlejret i PDF filen. Du kan evt. tvinge konverteringsprogrammet til at inkludere denne information i din PDF fil, eller så kan du vælge en mere almindelig font inden konverteringen.

Hvis produktet er stort eller hvis det består af flere filer, så komprimer det til en ZIP fil inden du uploader det til Lectio.

På rtgkom.dk skal du aflevere produktet i en så tilgængelig form som muligt. Hvis det er et webprodukt, så skal det kunne afprøves på vores server. Hvis produktet fylder meget eller består af mange filer og/eller mapper, så aflever også produktet som en ZIP fil.

Hvis I har et fysiskt produkt, f.eks. en opstilling med Arduino eller Raspberry Pi, så skal I aflevere det til jeres vejleder. Produktet skal forsynes med identifikationsinformation, altså dit/jeres navne, projekttitel, fag, klasse, dator, skole mm.

Så kort sagt:

  1. Lectio: I kan allerede i dag aflevere på Lectio. Hvis I ikke får lov til at uploade produktet pga. dets størrelse, så må I brænde det på en CD eller DVD og aflevere den til jeres vejleder. Den skal også, ligesom et eventuelt fysiskt produkt, mærkes med navn, klasse, skole m.m.
  2. Fronter: I kan allerede i dag aflevere på rtgkom.dk i en særlig afleveringsmappe som jeg har oprettet i jeres html mappe. For InfB hedder den infb_afsluttende_projekt og for PrgC hedder den prgc_eksamensprojekt. Efter afleveringsfristens udløb vil jeres skriverettigheder til disse mapper fjernes og muligheden for at browse mapperne vil også fjernes, således at censor altså ikke kan se produktet på den måde, -husk derfor at dokumentere produktets udseende og virkemåde i jeres rapport/journal.
  3. rtgkom.dk: På Fronter er der oprettet afleveringsmapper for fagene. Bemærk at du ikke skal uploade produktet til Fronter, fordi censor får læse-adgang til afleveringsmapperne på Fronter og censor skal kun læse rapporten/journalen. Bemærk at censor skal altså ikke teste produktet.

Afleveringsdato, Spike solutions og prototyper, Journalskrivning - gkb, 2015-04-28[edit]

Afleveringsdato[edit]

Vi justerede afleveringsdatoen således at projektet nu skal afleveres den 11. maj. InfB og PrgC afleveres på samme tidspunkt. En opgave til afleveringen er lagt op i Lectio, men nærmere detaljer om hvorvidt der også skal afleveres på papir og CD skiver kommer først i næste uge.

Spike solutions og prototyper[edit]

De fleste grupper arbejder fortsat på implementering af deres produkter. Jeg vil anbefale at I definerer nogle kerneproblemer og laver spike solutions for dem, gerne inden I begynder på arbejdet med at implementere den første prototype til det egentlige produkt.

I vores systemudviklings-sprog, så er en spike solution bare en hurtig og fræk test af om I kan løse et konkret programmeringsproblem med de værktøjer som I har valgt at bruge, helt uden hensyn til brugervenlighed, -den skal bare vise at der er et hul i gennem.

Når der er klarhed om hvordan kerneproblemerne kan løses, så er det lettere at lave tidsplanlægning for projektet, og så kan arbejdet med den første prototype begynde med lidt større sikkerhed for at det faktisk kan gennemføres, og evt. enda til tiden.

Hvis I ikke har lavet nogle spikes endnu, så er det helt ok. Tænk over hvad vil være svært at lave og lav en spike for det problem nu. Dokumenter med et eller flere skærmbilleder og nogle kommentarer, og så har I fint stof til journalen og rapporten i InfB. I kan godt lave en spike midt i arbejdet med en prototype.

Skalering af billeder med PIL, en spike[edit]

Som et eksempel på en spike solution kommer her et skærmbilled og lidt tekst som forklarer hvordan vi i en af grupperne definerede et kerneproblem. Jeg legede så senere lidt med problemet og her er min spike solution.

Kerneproblem: Hvordan kan man med PIL skalere et billed op og ned? Baggrunden er at vi ønsker at implementere noget som ligner en zoom funktion i Turtle modlet ved at udskifte baggrundsbilledet.

Vi havde en idé om at dette kunne lade sig gøre med PIL, altså Python Image Libray, modulet. Men det var lidt forvirrende at PIL ikke er opdateret for at virke med Python34, men en afgrening (fork) af PIL, kaldt Pillow, kunne bruges.

Vi søgte inspiration til hvordan man skal installer Pillow på denne webside: http://pillow.readthedocs.org/en/latest/installation.html#windows-installation

Vi søgte på "resizing image with pil" i Google og brugte http://opensource.com/life/15/2/resize-images-python som afsæt for vores spike som er dokumenteret rimelig godt med følgende to skærmbilleder.

Det første skræmdump viser at vi kan skalere billedet med faktor 0.5. Bemærk tallet 0.5 i kildekoden og bemærk informationen i info-dialogboksen i IrfanView om de to billeder før og efter skaleringen.

http://rtgkom.dk/~gkb/billeder/resizing_images_with_pillow_in_python34_800x512.png

Og her viser vi at vi kan skalere op med en faktor på 5.1.

http://rtgkom.dk/~gkb/billeder/resizing_images_with_pillow_in_python34_03_800x512.png

Journalskrivning[edit]

Husk skærmbilleder og forklaringer til hvad det er som I er ved at lave med udviklingsværktøjerne, -det er godt stof til både journalen og rapporten.

Udkast til projektbeskrivelse, User Stories, Gkb 17:24, 10 March 2015 (CET)[edit]

Udkast til projektbeskrivelse[edit]

Arbejdet med projektbeskrivelsen fortsatte i dag. Et udkast til projektbeskrivelsen skal afleveres på Lectio (hvis i arbejder i en gruppe, så lave en gruppeaflevering) og i projektmappen i hver enkelt elevs html mappe på webserveren.

User Stories[edit]

Vi diskuterede kort i plenum hvordan vi kan bruge brugshistorier (User Stories) til at fange krav til vores systemer (produkter). Vi så videoen Agile In Practice: StoryCards/User Stories på projektoren: https://www.youtube.com/watch?v=LGeDZmrWwsw

Udkast til projektbeskrivelse, Gkb 10:24, 9 March 2015 (CET)[edit]

Her er oplægget til eksamensprojektet: http://rtgkom.dk/~gkb/pubdoc/2015PrgC33_oplaeg_til_eksamensprojekt.pdf

Bemærk at i følge tidsplanen, så skal den foreløbige projektbeskrivelse afleveres i dag!

Her følger lidt mere information om hvordan du kan angribe den opgave at skrive projektbeskrivelsen.


Projektbeskrivelse[edit]

Projektbeskrivelsen er vigtig! Den er en slags aftale mellem dig og skolen om dit projekt, og den skal vedlægges rapporten som et bilag, således at censor kan se hvad det var som du ville lave i dit projekt.

Brug gerne min skabelon for indhold i projektbeskrivelser, Guide:Projektbeskrivelse og rapport, som inspiration. En mindre avanceret model for projektbeskrivelsens indhold kan også bruges, f.eks.:

  • Problemformulering
  • Beskrivelse af det valgte løsningsforslag
  • Valg af værktøjer
  • Resurseplan

Resurseplan[edit]

Resurseplanen er en del af projektbeskrivelsen, og den er en tidsplan over hvordan du vil fordele dine resurser på de aktiviteter som du kan se at du skal udføre i projektet.

Brug gerne et rigtigt planlægningsprogram til at lave denne planlægning, f.eks. Planner eller GanttProject.

Jeg har lavet et udkast til en skabelon for resurseplanlægning med GnattProject, hvor jeg har brugt navnene på aktiviteterne i vores systemudviklingsmodel til definere Tasks, og jeg har defineret forgænger for hver task, således at Gnatt diagrammet begynder at se lidt rigtigt ud.

Tiden for hvert task skal I selv indtaste, ligesom jeg ikke definerede subtasks for aktiviteterne i 2. iteration. Jeg har brugt forkortelser for aktiviteterne i 2. iteration, men de skulle være til at afkode ved at se på navnene på aktiviteterne i 1. iteration, hvor jeg har noteret forkortelsen sidst i navnet på aktiviteterne.

I må gerne bruge denne skabelon som udgangspunkt for resurseplanlægningen i jeres eksamensprojket.

Jeg har kun defineret tasks for to iterationer (udviklingen af to prototyper), og jeg har ikke defineret tiden for hvert task. Jeg har heller ikke defineret resurserne, -det vil normalt være jer selv.

Her er et link til skabelonen, som er en XML fil: http://rtgkom.dk/~gkb/pubdoc/Generisk_model_for_resurseplanlaegning_for_projekter_i_RTG_MediaLab.gan, og her er et billed som viser hvordan den ser ud i programmet.

http://rtgkom.dk/~gkb/billeder/generisk_resurseplan_473x365.png

Eksamensprojekt, Gkb 11:14, 23 February 2015 (CET)[edit]

Vi skal nu starte eksamensprojektet. I kan selv vælge hvad jeres projekt handler om, men projektbeskrivelsen skal godkendes af skolen. Projektoplægget definerer kun rammerne for projektet, -I vælger selv indenfor hvilket IT/programmeringsområde I arbejder.

Se foreløbig sidste års oplæg, det er her http://rtgkom.dk/~gkb/prg/2013-2014/2014PrgC-Oplaeg-til-eksamensprojekt.pdf. En version med opdaterede datoer kommer snart.

Resurseplanlægning og Krav til dokumentation af programmer, Gkb 10:50, 5 February 2015 (CET)[edit]

Som inspiration til arbejdet med at dokumentere systemudviklingsforløbet med opgaven om ASCII tabellen, så er her nogle idéer om hvordan man kan forholde sig til dokumentation af resurseplanlægningen og programmeringen.

Krav til dokumentation af programmer[edit]

Når vi skal dokumenter udvikling af programmer, så kan vi bruge følgende liste over krav til dokumentationen som inspiration. For nogle programmer vil det være mindre meningsfuldt at bruge alle punkterne i listen, og for andre programmer vil der måske behøves tiltag som ikke nævnes i listen. Brug den som inspiration, vælg selv de punkter som du synes relevante for dit program:

  1. User stories, en eller flere, som beskriver brugernes forventninger til programmet. Her er nogle eksempler.
  2. Kerneproblemet (evt. flere problemer). Beskrivelse i prosa, på dansk!, af kerneproblemet, altså det eller de problemer som du skal løse for at komme i gang med programmeringen af den første prototype. (Dette krav er inspireret af "Bottom Up" tilgangen til programmering.)
  3. Beskrivelse af brugerfladen for programmet (tekst UI, eller GUI). Tegn en eller flere skitser!
  4. Use Case diagram, som visualiserer hvem skal bruge programmet og til hvad det skal bruges. Her kan f.eks. ArgoUML eller Dia bruges. Sparxsystems har en beskrivelse af opbygningen i de forskellige UML-diagrammer.
  5. Klassediagram, som viser de vigtigste klasser i programmet. Her kan f.eks. ArgoUML eller Dia bruges.
  6. Input. En beskrivelse af input (inddata) til programmet. Hvilke data, deres datatype og mening for brugeren.
  7. Operationer på inddata, altså en beskrivelse af de operationer som programmet skal udføre på inddata.
  8. Output. Beskrivelse af output (uddata) fra programmet. Hvilke data, deres datatype og mening for brugeren.
  9. Flowchart (rutediagram) som viser programmets logiske opbygning/struktur. (Flowcharting, flowchart, brug gerne programmet Dia og for Dia til Windows se her.
  10. Kildekoden for det færdige program, formateret med en non-proportional font, altså med et skriftsnit hvor alle bogstaver er lige brede. Det bevirker at indrykninger i kildekoden ikke forvanskes. Prøv også at bruge ikke større bogstaver end 12 punkter, evt. kun 10 punkter hvis der er mange lange linier i kildekoden som ellers ville deles på to linier (wrap to the next line).
  11. Skærmbilleder som viser/dokumenterer hvordan det færdige program bruges/virker. Husk at i Windows så kan det det valgte, eller aktive vindue, kopieres til klippebordet (clipboard) med tastkombinationen Alt+PrtScr. Det kan være praktisk for at undgå at skulle paste skærmbilledet ind i et billedredigeringsprogram alene for manuelt at klippe vinduet ud fra hele skærmbilledet.
  12. Et skærmbilled, eller flere, som viser udviklingsmiljøet, kildekoden, Python shell'en og evt. debuggeren i funktion med en kort kommentar/forklaring.
  13. Diskussion/beskrivelse af de sætninge (statements) og evt. funktioner i Python som du har brugt i dit program.
  14. Diskussion/beskrivelse af de eksterne funktionsbiblioteker (Python moduler) du evt. har brugt i dit program.

ASCII tabellen, Gkb 10:40, 15 January 2015 (CET)[edit]

Plenummøde om ASCII tabellen[edit]

Vi startede med et plenummøde hvor vi diskuterede ASCII tabellen (se også http://en.wikipedia.org/wiki/ASCII) og hvor vi så på et programeksempel i Python som bruger chr() funktionen til at udskrive tegnene i tabellen til Python terminalen. Programmet er min fjerde mini-prototype på vej mod det mål at lave et program som visualiserer tegnenen i tabellen på en nydelig måde i nogle kolonner. Der mangler meget for at nå det mål, men her er programmet (lavet med version 2.7.6 af Python interpreteren i Ubuntu).

# ASCII tabel
# gkb 2015-01-12
print chr(65)
for i in range(256):
    print i, chr(i)
    if i % 32 == 0 :
        raw_input("Tryk Enter/Return-tasten til at fortsætte udskrivningen af tabellen:")

Vi kørte programmet og diskuterede lidt de forskellige grupper af tegn, kontrolkoder (usynlige for det meste), synlige tegn, bogstaver (store og små), escape tegnet, Line Feed eller New Line, Carriage Return, samt at tegnene over nr. 127 ikke hører til den oprindelige ASCII-tabel, men ofte kaldes den udvidede del og at den bruges blandt andet til at understøtte specialtegn i andre sprog end engelsk, som f.eks. æøå, ÆØÅ, ÁÉÍÓÚÖ, áéíóúö og ü mm., i sprog som dansk, islandsk, fransk osv.

Specielt, så diskuterede vi hvordan kontrolkoderne LF og CR oprindelig blev brugt til at styre valsen/vognen i skrivemaskiner, altså printere og telegraf-maskiner. Se mere her http://en.wikipedia.org/wiki/Newline.

Vi diskuterede anvendelse af tegn ved navngivning af progrmfiler, hvor jeg anbefaler af lidt forskellige grunde at holde sig til cifre og de små bogstaver fra ASCII-tabellen evt. suppleret med underscore til at gøre det lidt lættere at læse filnavnen som består af flere ord.

Jeg viste også hvordan jeg under udviklingen af disse fire mini-prototyper har forsøgt at dokumentere nogle observationer om hver version i et seperat tekstdokument. Her kommer denne dokumentation til generel inspiration til udvikling af egen personlige stil til at dokumentere jeres overvejelser under udviklingsforløbet. Man kan også skrive disse kommentarer i selve kildekodefilen hvis man synes det lettere.

v01: I denne version tester vi at vi kan bruge funktionen chr() til at
     udskrive bogstavet A.
v02: I denne version forsøger vi at bruge en løkke til at udskrive alle
     256 tegn i den udvidede ASCII tabell på en gang. Programmet kan køre
     uden syntaxfejl og uden runtime-fejl, men det semantiske design
     kan forbedres meget. Outputet en en lang kolonne med tegn og nogen 
     virker være usynlige eller så vises der symboler for dem som vi ikke er
     vant til.
     Det viser sig at kun en del af tegnene i
     tabellen kan vises på computerskærmen med et symbol som vi har let
     med at genkænde. Det handler om tegn som tal, bogstaver og punktations-
     tegn, matematiske symboler som + og * mm. 
     I begyndelsen af tabellen virker der være en deltegn som vises som
     mærkelige symboler. Vi undersøger nærmere i næste version af programmet
     hvilke numre disse har.
v03: I denne version har vi tilføjet index-variablen i vores for-løkke til
     parameterlisten for vores print-sætning. Vi har også tilføjet en
     if-sætning som gør der udskrives kun 32 linjer af gangen, og brugeren
     promptes at trykke Enter/Return - tasten til at fortsætte udskrivningen.
     Disse ændringe gør at vi nu kan gøre følgende observationer:
     Tegn nr. 0, 9, 10 og 32 printes tilsyneladende ikke med noget synligt
     symbol.
     Tegn nr. 33 til 126 har alle et grafiskt symbol.
     Tegn nr. 127 har et grafiskt symbol som tilsyneladende består af to
     mærkelige tegn.
     Tegn nr. 128 til 255 printes tilsyneladende ikke med noget synligt
     symbol.
     Mellemrum (space) er nummer 32, og udskrives som et mellemrum, og
     derfor kan vi ikke se det på skærmen.
v04: asdf ikke lavet endnu...

Individuel opgave: Et Python program som udskriver ASCII-tabellen[edit]

Lav et program som udskriver tegnene i den oprindelige ASCII-tabel, altså de 128 tegn, på en nydelig måde i en tabel. Du kan selv vælge hvordan du formaterer din tabel.

Følgende krav skal dog opfyldes:

  • Programmet skal vise sit output på en skærm med 80 tegn (eller kolonner á et tegn) og 24 linjer.
  • De ikke grafiske tegn (kontrol tegnene og mellemrum) skal representeres af en intelligent forkortelse med max tre store bogstaver.
    • Option: Hvis du har tid og lyst, så forklar betydningen af disse forkortelser i en tekst nedenfor eller ved siden af tabellen. Denne information skal også være synlig samtidig med selve tabellen.
  • Tegnenes nummer skal anføres i umiddelbar nærhed til tegnet, således at der ikke kan være tvivl om hvilket tegn har hvilket nummer.
  • Programmet skal kunne skrive tabellen til en tekstfil med navnet ascii_tabel_dit_bruger_navn.txt, som ligger i samme mappe/directory som kildekodefilen som gerna må hedde ascii_tabel_dit_bruger_navn_vxx.py, hvor vxx er versionsnumer for kildkoden (v01, v02 osv.). Du kan også bruge en anden metode til navngivning af dine kildekodefiler, - bare du let kan finde flere tidligere versioner af programmet når du er færdig og skal dokumentere udviklingsarbejdet.

Programmet skal afprøves i en terminal (DOS prompt) hvor antal kolonner og rækker er sat til 80x24.

Dokumenter udviklingen af nogle forskellige prototyper, f.eks. to, inklusive den endelige version, med tekst og skærmbilleder i en journal som du uploader og præsenterer kort på dit StudieWeb i en mappe med navnet ascii_tabel i dit home directory. Følgende skal uploades:

  1. Kildekoden, evt. i flere forskellige versioner
  2. Tekstfilen med ASCII tabellen
  3. Journal på ca. 5 til 10 sider i PDF format (plus andre formater om du vil). I journalen skal du
    1. beskrive de værktøjer du bar brugt (Python, editor osv.)
    2. beskrive hvordan du har løst opgaven, gerne vha. blokdiagram og et flowchart.
    3. vise forskellige versioner af kildekoden,
    4. beskrive problemer og forklare hvordan du har løst dem.
    5. gør kort rede for nogle af de Python-funktioner som du har brugt, specelt dem som du har brugt til håntering af strenge.
  • Hint0: Bemærk at der er forskel på print i Python 3 og i Python 2. I Python 2 var print en sætning (statement), men i Python 3 er print lavet om til en funktion. En af de umiddelbare konsekvener er at vi nu skal skrive parentheser rundt om argumentlisten, men der er flere andre ændringer. Se gerne artiklen What’s New In Python 3.0, https://docs.python.org/3.0/whatsnew/3.0.html, hvor Guido van Rossum selv beskriver hvad der er nyt i version 3. Den nye print funktion beskrives her: https://docs.python.org/3.0/library/functions.html#print.
  • Hint1: Se på repr().
  • Hint2: Der findes nogle løsninger i vores wiki. Brug dem gerne til inspiration, men pas på ikke at kopiere koden. Indtast selv og pas på at have totalt kendskab til løsning.
  • Hint3: Brug den primære dokumentation på python.org, start f.eks. med https://docs.python.org/2/tutorial/inputoutput.html
  • Hint4: Brug f.eks. denne artikel,http://da.wikipedia.org/wiki/ASCII, i Wikipedia til at læse om ASCII tabellen og se forklaringerne på de forkortelser som vi skal bruge i tabellen.

Tilbage til lærebogen, Gkb 10:54, 8 January 2015 (CET)[edit]

Efter vores robot race har vi behov for at arbejde mere med Python. Vi arbejdede videre med lærebogen, How to Think Like a Computer Scientist, Learning with Python 3 (RLE), http://openbookproject.net/thinkcs/python/english3e/, ..

Robo race 2[edit]

Her er resultatet fra race 2


http://rtgkom.dk/~cso/img/IT3314/robo-race-2.png


Så skal jeres resultater sammenlignes er de blevet bedre hvorfor / hvorfor ikke.

Der er et problem i forsøget nemlig at banerner ikke er i samme rækkefølge Jeg ved at bane 1 er bane 1 i begge kørsler og at bane 2 i anden kørsel hedder bane 3. derud over ved jeg ikke mere.

Flowcharting, Gkb 11:14, 25 November 2014 (CET)[edit]

Brug Dia, http://dia-installer.de/, til at tegne flowcharts.

Tegne seperate flowcharts for events som for eksempel en hindring som bliver opdaget. Hovedprogrammet bliver afbrudt, interrupted, af denne begivenhed og koden i jeres eventhandler (interrupt subrutinen) bliver eksekveret. Dette beskrives bedre og illustreres med flowcharts i følgende to kilder:

Fortsat arbejde med dokumentation i en wiki-rapport, Gkb 11:12, 18 November 2014 (CET)[edit]

I dag fortsætter vi med wikirapporten. Som overordnet vejledning kan I bruge at rapporten skal formidle følgende information:

  • hvad I lavede i projektet og
  • hvordan I lavede det og med
  • hvilket resultat.

En mere detaljeret vejledning til indholdet blev diskuteret og skrevet på tavlen i modulet som vi havde den 11. november.

Regler for RoboRace, Dokumentation i en wiki-rapport, Gkb 11:25, 4 November 2014 (CET)[edit]

Vi startede med et plenummøde hvor vi diskuterede planlægningen af RoboRace på torsdag. Vi diskuterede og blev enige om at dokumentere projektet i en wiki-rapport.

Vi diskuterede kort hvordan det er lidt anderledes at skrive i en wiki end at skrive f.eks. i OpenOffice Writer og eksportere rapporten til en PDF fil. At skrive en wiki-artikel er anderledes end at skrive en traditionel rapport og vi skal prøve lidt at tilpasse vores dokumentationsarbejde til dette nye medie. Formkravene er anderledes og noget friere, men det betyder ikke at de faglige krav er reduceret.

Som lidt historisk ballast diskuterede vi at den første Wiki blev lavet af Ward Cunningham i 2002 og efter plenummødet så vi en video på ca. 14 minutter hvor han forklarer wiki-begret. Vidoen er her: http://www.youtube.com/watch?v=XqxwwuUdsp4

Vi diskuterede dokumentation af programmer. Blandt andet at det er vigtigt at anvende beskrivende navne på variabler og funktioner og således minimere de kommentarer som behøves i kildekoden. Vi skal nemlig vedligeholde dem når vi redigerer kildekoden, og det meget almindeligt at kommentarerne bliver misvisende fordi vi glemmer at opdatere dem.

Vi har fået lov til også at bruge modul 3. i dag til dette projekt. Bill har skemalagt jer i lokale C3111, og I kan også udnytte nicherne på gangen.

RoboRace[edit]

På torsdag i 2. og 3. modul gennemføres RoboRace hvor grupperne skal konkurrere med sine roboter (programmer) i at køre hinandens baner på bedst tid. Reglerne for konkurrencen blev udviklet i InfB i går. De er udleveret på papir.

http://www.rtgkom.dk/~cso/img/IT3314/robo-race-resultat.png

Dokumentation i en wiki-rapport[edit]

Her er links til wikiartikler hvor grupperne kan skrive sine wiki-rapporter. Klik på linket for at oprette artiklen!

  1. 2014_InfB33_PrgC33_Wikirapport_for_projektet_Autonome_roboter_Gruppe_01_Jan_og_Adrian_og_Maja
  2. 2014_InfB33_PrgC33_Wikirapport_for_projektet_Autonome_roboter_Gruppe_02_Sebastian_og_Morten_og_Oliver
  3. 2014_InfB33_PrgC33_Wikirapport_for_projektet_Autonome_roboter_Gruppe_03_Mikkel_og_Benjamin_og_Mathias
  4. 2014_InfB33_PrgC33_Wikirapport_for_projektet_Autonome_roboter_Gruppe_04_Emil_og_Daniel_og_Christian
  5. 2014_InfB33_PrgC33_Wikirapport_for_projektet_Autonome_roboter_Gruppe_05_Janus_og_Oliver
  6. 2014_InfB33_PrgC33_Wikirapport_for_projektet_Autonome_roboter_Gruppe_06_Jakob_og_Christian
  7. 2014_InfB33_PrgC33_Wikirapport_for_projektet_Autonome_roboter_Gruppe_07_Keerthy_og_Markus_og_Alexander
  8. 2014_InfB33_PrgC33_Wikirapport_for_projektet_Autonome_roboter_Gruppe_08_Rasmus_og_David_og_Nikolaj
  9. 2014_InfB33_PrgC33_Wikirapport_for_projektet_Autonome_roboter_Gruppe_09_Mathias

Her er et link,https://www.mediawiki.org/wiki/Help:Editing_pages, til info om hvordan man editerer i en wiki som drives med softwaren fra http://MediaWiki.org

Dokumentation af programmer[edit]

Vælg nogle af punkterne på følgende liste når I dokumenterer jeres programmer til roboten.

Generelle krav til dokumentation af projektopgaver i Programmering C[edit]

Når vi skal dokumenter udvikling af programmer, så kan vi bruge følgende liste over krav til dokumentationen som inspiration. For nogle programmer vil det være mindre meningsfuldt at bruge alle punkterne i listen, og for andre programmer vil der måske behøves tiltag som ikke nævnes i listen. Brug den som inspiration, vælg selv de punkter som du synes relevante for dit program:

  1. User stories, en eller flere, som beskriver brugernes forventninger til programmet. Her er nogle eksempler.
  2. Kerneproblemet (evt. flere problemer). Beskrivelse i prosa, på Dansk!, af kærneproblemet, altså det eller de problemer som du skal løse for at komme i gang med programmeringen af den første prototype. (Dette krav er inspireret af "Bottom Up" tilgangen til programmering.)
  3. Beskrivelse af brugerfladen for programmet (tekst UI, eller GUI). Tegn en eller flere skitser!
  4. Use Case diagram, som visualiserer hvem skal bruge programmet og til hvad det skal bruges. Her kan f.eks. ArgoUML eller Dia bruges. Sparxsystems har en beskrivelse af opbygningen af de forskellige UML-diagrammer.
  5. Klassediagram, som viser de vigtigste klasser i programmet. Her kan f.eks. ArgoUML eller Dia bruges.
  6. Input. En beskrivelse af input (inddata) til programmet. Hvilke data, deres datatype og mening for brugeren.
  7. Operationer på inddata, altså en beskrivelse af de operationer som programmet skal udføre på inddata.
  8. Vigtige datastrukturer som bruges i programmet, f.eks. lister, records, osv. Evt. også vigtige variabler og konstanter.
  9. Output. Beskrivelse af output (uddata) fra programmet. Hvilke data, deres datatype og mening for brugeren.
  10. Flowchart (rutediagram) som viser programmets logiske opbygning/struktur. (Flowcharting, flowchart, brug gerne programmet Dia og for Dia til Windows se her.
  11. Kildekoden for det færdige program, formateret med en non-proportional font, altså med et skriftsnit hvor alle bogstaver er lige brede. Det bevirker at indrykninger i kildekoden ikke forvanskes. Prøv også at bruge ikke større bogstaver end 12 punkter, evt. kun 10 punkter hvis der er mange lange linier i kildekoden som ellers ville deles på to linier (wrap to the next line).
  12. Skærmbilleder som viser/dokumenterer hvordan det færdige program bruges/virker. Husk at i Windows så kan det valgte, altså det aktive vindue, kopieres til klippebordet (clipboard) med tastkombinationen Alt+PrtScr. Det kan være praktisk for at undgå at skulle paste skærmbilledet ind i et billedredigeringsprogram alene for manuelt at klippe vinduet ud fra hele skærmbilledet.
  13. Et skærmbilled, eller flere, som viser udviklingsmiljøet, kildekoden og f.eks. Python shell'en og evt. debuggeren i funktion med en kort kommentar/forklaring. Hvis du/I har anvendt andre værktøjer, f.eks. Lazarus og POV-Ray, so skal der selvfølgelig også laves skærmbilleder som viser dem under aktiv udvikling af jeres program.
  14. Diskussion/beskrivelse af de sætninge (statements) og evt. funktioner i Python/POV-Ray/Object Pascal (eller det sprog som du/I nu har valgt ) som bruges i dit/jeres program.
  15. Diskussion/beskrivelse af de eksterne funktionsbiblioteker (Python moduler, Object Pascal units, POV-Ray include filer, osv.) du evt. har brugt i dit program.

Som inspiration til rapportskrivningen kan vores generelle guide om projektbeskrivelse og rapport evt. bruges, se her http://rtgkom.dk/wiki/Guide:Projektbeskrivelse_og_rapport

Autonome robotter, en robotkonkurrence med Thymio, Gkb 13:21, 2 October 2014 (CEST)[edit]

Kære 3.3 I skal udvikle algoritmer til robotter så de kan følge streger af varierende brede, med huller, i forskellige form, prikker, farver, på skråplan, forhindringer (klodser) og huller hvor clifhanger sensoren bruges. I skal også lave en jeres egen bane som er tilgængelig for alle fra mandag i uge 44. Den skal kunne printes ud på 1 eller flere A3 papirer dog max i til en bane A1 størrelses. Hvis der er skårende områder, kanter, klodser og eller huller skal de være vel beskreven samt lette at reproducerer. Jeres egen robot skal self kunne klare banen jeres bane.

Sidst i uge 45 køre konkurrencen.

I må gerne tage robotterne med hjem i ferien MEN mandag i uge 43 skal robotterne være her på skolen. Det giver straf point til den sener konkurrence hvis robotterne ikke er tilgængelige mandag morgen i anden modul, da de skal bruges der af andre.

Hilsen Karl og Christoffer.


Mindst to, max fire i en gruppe.

  • Gruppe 01: 3 Jan Place Jakobsen, Adrian Radziszewski og Maja Scheel Kvint
  • Gruppe 02: 2 Sebastian og Morten
  • Gruppe 03: 3 Mikkel Olsen, Benjamin Klausen og Mathias Nielsen
  • Gruppe 04: 3 Emil Elkjær, Daniel Osric & Christian Møller
  • Gruppe 05: 3 Janus, Julius, Oliver H
  • Gruppe 06: 2 Jakob, Christian H
  • Gruppe 07: 3 Keerthy, Markus og Alexander torp
  • Gruppe 08: 3 Rasmus, David og Nikolaj
  • Gruppe 09: 2 Mathias H, Oliver K
  • Gruppe 10:
  • Gruppe 11:

<script> document.write(3+2+3+3+3+2+3+3+2); </script>

Turtle og iRobotCreate, gkb, 3. modul, 30. september 2014[edit]

Vi arbejdede videre med Turtlemodulet og forsøg på at styre iRobotCreate fra Python.

Gustav fra klasse 2.3 lavede sidate år et program som vi lånte og så kunne vi styre robotten. Programmet følger her i sin helhed.

import serial 

ser = serial.Serial(0)
ser.baudrate = 57600
print( ser)

ser.write(chr(128))
ser.write(chr(132))

EndProgram = False

w="w"
a="a"
s="s"
d="d"
e="e"
z="z"
x="x"
c="c"
t="t"
while not EndProgram:
#    tast = input("Tryk z, x, c, w, a, s, d , e, t:" )
    tast = raw_input("Tryk z, x, c, w, a, s, d , e, t:" )
    if tast == "w":
        ser.write(chr(145))
        ser.write(chr(0))
        ser.write(chr(200))
        ser.write(chr(0))
        ser.write(chr(200))
        ser.write(chr(147))
        ser.write(chr(2))
        
    elif tast == "a":
        ser.write(chr(145))
        ser.write(chr(0))
        ser.write(chr(150))
        ser.write(chr(0))
        ser.write(chr(0))
        ser.write(chr(147))
        ser.write(chr(9))
        
    elif tast == "e":
        ser.write(chr(145))
        ser.write(chr(0))
        ser.write(chr(0))
        ser.write(chr(0))
        ser.write(chr(0))
        ser.write(chr(147))
        ser.write(chr(4))


    elif tast == "d":
        ser.write(chr(145))
        ser.write(chr(0))
        ser.write(chr(0))
        ser.write(chr(0))
        ser.write(chr(150))
        ser.write(chr(147))
        ser.write(chr(9))

    elif tast == "s":
        ser.write(chr(145))
        ser.write(chr(255))
        ser.write(chr(0))
        ser.write(chr(255))
        ser.write(chr(0))
        ser.write(chr(147))
        ser.write(chr(4))

    elif tast == "z":
        ser.write(chr(147))
        ser.write(chr(2))

    elif tast == "x":
        ser.write(chr(147))
        ser.write(chr(4))

    elif tast == "c":
        ser.write(chr(147))
        ser.write(chr(9))
    
    elif tast == "t":
        pass
    else:
        pass

Vær opmærksom på at programmet også styrer spændingen på nogle af pindne i DB25 stikket som er i robottens lastrum. Det brugtes til at tænde og slukke for lysdioder på en bestemt måde.

iRobotCreate, Gkb 12:48, 25 September 2014 (CEST)[edit]

Vi har fire stk. iRobotCreate robotter. Vi skal i dag forberede os på at styre dem fra et Python program.

En plan kan være at importere Serial modulet og bruge information fra interfacebeskrivelsen for robotten, den er her http://www.irobot.com/filelibrary/pdfs/hrd/create/Create%20Open%20Interface_v2.pdf

Her er en artikel fra Linux Journal som viser hvordan robotten kan styres fra et serial kommunikationsprogram, http://www.linuxjournal.com/magazine/fun-irobot-create.

Skak-opgaven, aflevering, Gkb 14:23, 23 September 2014 (CEST)[edit]

Opgaven skal afleveres i aften senest kl. 23:30.

Det skal gørs ved at aflevere en almindelig tekstfil (plain text) på Lectio. Filen kan laves med hvilken som helst programeditor og den kan f.eks. hedde skakspil_med_interaktion.txt. Filen skal bare indeholde to ting:

  • URL til din aflevering på dit StudieWeb.
  • En kort beskrivelse af hvad opgaven handler om. Dette kan være ca. 10 til max 50 ord. Du kan kopiere noget af den tekst du har skervet til at præsentere opgaven på dit StudieWeb.

Her er et eksempel på hvordan denne fil kan se ud:

http://www.rtgkom.dk/~keerthys12/skakspil_med_interaktion/Skakbr%C3%A6t.html
Opgaven gik ud på at lave et program med Python og Turtle modulet, som viser et skakbræt og giver mulighed for en eller anden form, for interaktion med musen og/eller tastaturet.

På dit StudieWeb skal du så i den mappe som jeg har oprættet til opgaven, nemlig skakspil_med_interaktion, aflevere alle filer i forbindelse med opgaven. Det kan variere lidt efter hvordan du vælger at lave din aflevering og præsentation af opgaven, men som minimum skal der være:

  • En præsentation af opgaven i en HTML fil, f.eks. skakspil_med_interaktion.html hvor du med ca. 100 til max. 1000 ord beskriver hvad du har lavet og hvordan du gjorde det. Inkluder en eller flære skærmbilleder til forklaring. (Dette kan blive flere filer hvis du inkluderer mange billeder.)
  • Kildekoden i en .py fil, og husk at linke til den fra præsentationen af opgaven, så gæster på dit StudieWeb kan downloade den og teste den. (Da det nu kun handler om en enkelt fil, og den ikke er så stor, så komprimerer vi den ikke til et arkiv).

Husk også at linke til opgaven fra din oversigt over opgaver på selve homepage'en på dit StudieWeb.

Skak-opgaven, fortsat arbejde med, Gkb 13:04, 18 September 2014 (CEST)[edit]

Her er en måde at lave noget som ligner lidt et skakbræt.

import turtle
scr=turtle.Screen()
t1=turtle.Turtle(shape='turtle')

no_columns=2
no_rows=2
#x_start=0
#y_start=0
turtle_size=25
#t1.color('blue')

for i in range(no_columns):
    for j in range(no_rows):
        t1.goto(i*turtle_size, j*turtle_size)
        t1.pendown()
        t1.begin_fill()
        if (i+j) % 2 == 0:
            t1.fillcolor('red')
        else:
            t1.fillcolor('yellow')
            
        for k in range(4):
            t1.forward(turtle_size)
            t1.left(90)
        t1.penup()
        t1.end_fill()
        
turtle.mainloop()

Skakspil med interaktion, Gkb 12:36, 9 September 2014 (CEST)[edit]

Vi startede med kort diskussion af Screen.mainloop() problemet, som er beskrevet i notatet for sidste modul.

En opgave til aflevering: Skakspil med interaktion[edit]

Lav et program med Python og Trutle modulet som viser et skakbræt og giver mulighed for en eller anden form for interaktion med musen og/eller tastaturet. Skakspillets regler kan, men behøves ikke, overholdes.

  • Individuelt arbejde med inspiration fra andre.
  • Aflevering om to uger på dit StudieWeb. Kildekode og skærmbilleder, samt en kort beskrivelse, max 1000 ord i plain HTML!

Logo, Papert, Turtlegrafik og Uri Wilensky's NetLogo, Gkb 12:00, 4 September 2014 (CEST)[edit]

Turtlegrafik i historisk perspektiv[edit]

Vi startede med et kort plenummøde hvor turtlegrafik blev sat i et historiskt perspektiv. Vi er nu begyndt at arbejde med kapitel nr. 3 i lærebogen (How To Think Like a Computer Scientist, Learning with Python, for Python 3) og der bruges Turtle modulet som følger med Python. Ved hjælp af de klasser og metoder som er defineret i dette modul kan vi hurtigt lave lidt grafik som f.eks. streger, kvadrater, cirkler.

Turtle modulet for Python er en af mange implementationer af programmeringssproget Logo som Seymour Papert, http://www.papert.org/, og et team af andre forskere lavede på 70'tallet (1966 eller 1967).

Turtle-grafiken var vistnok ikke med i Logo helt fra starten, men blev tilføjet hurtigt (1969?). Den var inspireret af en robot som blev styret via kabel og den lignede vist lidt en skildpadde.

En af de mere interessante implementationer af Logo er NetLogo som Uri Wilensky har lavet. Den bygger på Java og med den kan man let eksportere sine NetLogo programmer som Java appletter og publisere dem på en webserver, og der kan de bruges uden at brugeren skal installere NetLogo (altså hvis Java Virtual Machine er installeret).

AttributeError: '_Screen' object has no attribute 'mainloop'[edit]

Flere af os har fået følgende fejlmeddelelse, eller lignende, når vi eksekverer eksemplerne fra kapitel tre i lærebogen.

>>> 
Traceback (most recent call last):
  File "<module1>", line 9, in <module>
AttributeError: '_Screen' object has no attribute 'mainloop'
>>> 

Grafikvinduet fryser og skal lukkes med vold. Dette kan undgås ved at bruge mainloop() metoden for selve turtle modulet, turtle.mainloop() eller turtle.done(), i stedet for mainloop() for turtle.Screen. Det virkede i hvert fald i Python 3.0 på Windows XP. Her er et eksempel på et lille program som virker med turtle.done().

import turtle             # Allows us to use turtles
wn = turtle.Screen()      # Creates a playground for turtles
alex = turtle.Turtle()    # Create a turtle, assign to alex

alex.forward(50)          # Tell alex to move forward by 50 units
alex.left(90)             # Tell alex to turn by 90 degrees
alex.forward(30)          # Complete the second side of a rectangle

turtle.done() #Loeser problemet i Python 3.0
#wn.mainloop()             # Wait for user to close window

Python, tirsdag 2. sept, gkb[edit]

Fortsat arbejde med Python og lærebogen. Der var fortsat nogle som havde problemer med at få PyScripter til at virke. Og nogle bruger andre IDE's, det er ok.

PyScripter, Python i historisk perspektiv, Gkb 13:29, 26 August 2014 (CEST)[edit]

Efter kort plenummøde fortsatte individuelt arbejde med lærebogens kapitler 1, 2 og 3, afhængigt af hvor langt hver enkelt er nået. Leg gerne lidt med Turtle modulet i kapitel 3, men vend tilbage og gøre alle øvelerne i teksten og opgaverne i kapitel 1 og 2 færdige inden længe.

PyScripter[edit]

Vi har i dag aktivt begyndt at bruge PyScripter til kodningsarbejdet, sådan som foreslået i kapitel 1 i lærebogen. Der har været lidt forskellige typer af problemer i forbindelse med installationen, men vi har set eksempler på at den med lidt tålmodighed kan fungere i XP, Windows 7 og på MacOS.

Fordelen ved at anvende PyScripter er at den integerer Python interpreteren i samme GUI som editoren hvor vi skriver vores kildekode og således slipper vi for path-problemer når vi skal starte interpreteren i en terminal. Det sidste kan man selvfølgelig også opfatte som en ulempe, men for de fleste nye brugere af Python så er det nok en stor lettelse.

Python i historisk perspektiv[edit]

Der opstod lidt diskussion om hvornår Python kom frem og hvad det er som kendetegner Python i forhold til andre programmeringssprog. I den sammenhæng kiggede vi kort på en liste fra Wikipedia over programmeringssprog, http://en.wikipedia.org/wiki/Timeline_of_programming_languages, og en planche fra O´Reilly, http://www.oreillynet.com/pub/a/oreilly/news/languageposter_0504.html, som visualiserer udviklingen fra ca. 1950 til i dag.

Efter modulet fandt jeg også en grafisk timeline "of computing" på Wikipedia som ikke kun indeholder information om programmeringssprog men også forskellige andre "ting" som er relateret til "computing" ("automatiske beregninge med en computer" betyder det vel), såsom anvendelsesområder, hardware og operativsystemer. Se her http://en.wikipedia.org/wiki/Timeline_of_computing. Denne visuelle timeline er nok vel egnet som foder til en diskussion af IT-udviklingen de sidste ca. 70 år.

Opstart af Python med terminalkommandoer i et Windows terminalvindue; Arbejde med kapitel 1, Gkb 12:11, 21 August 2014 (CEST)[edit]

Opstart af Python med terminalkommandoer i et Windows terminalvindue[edit]

I den første lektion i dag har vi på projektoren i plenum set lidt nærmere på de kommandoer vi skal bruge i et Windows terminalvindue til at starte Python interpreteren. (I Linux/Unix/MacOS gælder lignende overvejelser, det er dog oftest lettere at starte Python i en terminal.)

Det første vi gør er at starte selve kommandoefortolkeren i Windows. Det gøres med kommandoen 'CMD', eller 'cmd'. I Windows gøres der i denne og mange andre sammenhænge ingen forskel på store og små bogstaver i navne på programmer eller vejene (path) til dem. I Linux og på Mac er der altid en forskel!

Der næst brugte vi følgende kommandoer til at se os lidt omkring og til at ændre PATH variablens indhold:

  • dir
  • tree til at se en semigrafisk (med teksttegn) visualisering af alle de mapper som ligger nedenfor mappen som er default.
  • tree > tree.txt til at omdirrigere output fra tree kommandoen til en tekst fil.
  • type tree.txt til at vise indholdet af tree.txt.
  • cd til at se hvilen mappe er default, altså se i hvilken mappe (directory) vi er.
  • cd \ til at skifte til andre mapper.
  • cd /? til af få lidt information om hvad kommandoen laver og hvordan vi skal bruge den (dens syntax).
  • help til at få mere information om de kommandoer som vi kan bruge.
  • path til at vise indholdet i path variablen.
  • path=%path%;C:\Python34 til at tilføje en vej til version 3.4 af Python.

Under diskussionen kom vi forbi begreber som f.eks. intern kommando, ekstern kommando (vi konstaterede at tree nok er en ekstern kommando fordi der ligger en tree.com nede i C:\Windows\System32 mappen), kommandofortolker, operativsystem, filsystem, fil (file), tekstfile, redirection af en kommandos output til en tekstfil, mappe (directory), vej (path), path-variablen, miljøvariabler (environment variables), path kommandoen.

De ændringer vi laver på PATH variablen gælder kun i denne terminal-session. Hvis vi vil lave permanente ændringer som f.eks. gælder for nye terminalsessioner, så skal vi gøre ændringerne via "Min Computer - Egenskaber - Avanceret - System" eller noget i den retning, hvor man kan redigere i indholdet i de forskellige miljøvariabler.

Vi øvede os i at vise indholdet i alle miljøvariablerne vha. set-kommandoen, og også i kun at vise indholdet af path-variablen vha. 'path'-kommandoen. Vi diskuterede at Windows kommandofortolker (CMD) kun kan eksekvere interne kommandoer og programmer som den kender vejen (path) til.

Arbejde med kapitel 1[edit]

I den sidste lektion havde vi individuelt arbejde med kapitel 1 i lærebogen. Nogle er begyndt på kapitel 2, og det er ok, bare husk at lave alle øvelserne i kapitel 1 inden længe.

Terminal og path mm, Gkb 13:28, 19 August 2014 (CEST)[edit]

I dag fortsatte vi med afsnint 1 og med at løse path problemet i Windows. Vi behøver forstå hvordan vi bruger en commandoprompt i Windows (terminal) eller en terminal som det hedder i Linux og Unix, til at starte Python. Ellers kan vi ikke lave øvelserne i lærebogen helt på samme måde som de gør.

Første modul, torsdag 14. august,Gkb 13:28, 19 August 2014 (CEST)[edit]

Vi så lidt på beskrivelsen af faget i bekendtgørelsen, https://www.retsinformation.dk/Forms/R0710.aspx?id=132670#B32.

Dernæst startede vi arbejdet med Python og lærebogen "How to Think Like a Computer Scientist, Learning with Python", http://openbookproject.net/thinkcs/.

Efter installering begyndte vi på afsnit 1 i bogen. Alle eksemplerne i bogen skal afprøves på egen computer. I Windows gav det visse problemer med at starte Python i en terminal, da Path variablen skal opdateres manuelt til at indeholde vejen til Python interpreteren, som typisk vil være "C:\Python34".