2017InfC14

From rtgkomArkiv
Revision as of 15:10, 13 December 2017 by Gkb (talk | contribs) (Visuel programmering med Snap, 2. modul 2017-12-13, Gkb 14:28, 13 December 2017 (CET))

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Visuel programmering med Snap, 4. modul 2017-12-13, Gkb 14:53, 13 December 2017 (CET)[edit]

Visuel programmering med Snap, 2. modul 2017-12-13, Gkb 14:28, 13 December 2017 (CET)[edit]

Vi diskuterede kravene til afleveringen i dette forløb. Der skal afleveres nogle forskellige ting:

  • produkt, både 1. og 2. prototype
    • Første prototype skal opfylde de syv krav som jeg stillede i modulet den 27. November. Og ikke indeholde nogen funktionalitet som ikke er direkte følge af opfyldelse af disse krav.
    • Anden prototype kan indeholde yderligere funktionalitet som I selv individuelt vælger. I kan altså selv skrive op et antal krav til jeres anden prototype.
  • journal. Journalen skal indeholde et antal skærmbilleder fra udviklingen af begge prototyper. Gerne lavet hvor der er et interessant problem, syntaxfejl eller lignende, og så skal der skrives en forklaring til hvert billed. Hvad er det som sker i billedet? Hvilket problem er opstået? Og så skal I selvfølgelig også forklare hvordan I løste problemet, og den det kan også visualiseres vha. et skærmbilled.
  • reflektionsnotat. ...

For at forklare nærmere hvordan jeg ønsker at I afleverer, så syntes jeg at det var nødvendigt at introducere nogle begreber fra det fagområde som kaldes systemudvikling.

Vi diskuterede systembegrebet generelt og så systemudvikling i almindelighed med henvisning til eksempler som:

  • RUP, Rational Unified Process, IBM's metode tror jeg.
  • OOAD, Object Orienteret Analyse og Design
  • SCRUM
  • XP (Extreme Programming)

Og så præsenterede jeg i visse detaljer MediaLabs egen hjemmelavede systemudviklingsmetode, se her http://www.rtgkom.dk/wiki/MediaLab:_Systemudviklingsmetode.

Jeg gennemgik alle syv systemudviklingsaktiviteter i metoden og tegnede på tavlen og snakede om begreber som iterationer, prototyper, kravspecifikation og testspecifikation, design af indre logik og design af brugerfladen, vores to designmodeller, afprøvning af om kravene er opfyldt vha. testprocedurerne i testspecifikationen mm. Jeg viste også kort MediaLabs skabeloner for projektbeskrivelse og rapport, http://rtgkom.dk/wiki/Guide:Projektbeskrivelse_og_rapport, men de er lavet således at de passer godt til vores systemudviklingmetode.

Visuel programmering med Scratch og Snap, Gkb 19:00, 27 November 2017 (CET)[edit]

Vi har nu brugt de fire første moduler (13., 15., 22. og d. 24. November) til at afprøve SageMath som platform for programmering i Python og klassen har afleveret en øvelse hvor vi brugte SageMath til at løse en andengradsligning med Python kode og med funktionen solve(), samt til at plotte funktionen i en graf.

Vi har på tæt hold oplevet forskellge fordele og ulemper ved at installere og bruge sådan et Computer Algebra System, CAS system. For nogle har det været relativt let at komme i gang, men for andre har det nok været svært. SageMath er et stort system med mange muligheder og omfattende dokumentation.


I modulet i dag, d. 27. Nov, tager vi et skridt baglæns og starter så at sige helt forfra med at lære at programmere. Nu bruger vi et værktøj som er direkte lavet til at gøre det lettere at lære at programmere.

Vi startede modulet med et kort plenummøde hvor vi diskuterede hvilken type af udviklingsmiljø vi kunne tænke os at bruge i forløbet. Jeg slyngede ud følgende muligheder:

Vi aftalte at alle skulle søge lidt på nettet og teste forskellige systemer.

Efter ca. 10 minutter diskuterde vi igen og nu blev konklusionen at vi fokuserer på Scratch og Snap i dette modul. Det var frit at vælge det ene eller det andet system til at afprøve. Det vil sige at alle skulle vælge et af de to systemer og følge de relevante vejledninge for nybegyndere med henblik på at prøve at implementere en enkel prototype til et spil med følgende funktionalitet.

  1. Der laves to sprites hvor den ene er cirkelformet og den anden kvadratisk. Størrelsen tilpasses spillets bane således at ingen af de to sprites fylder for meget af spillebanens areal. Evt. er en størrelse mellem 1% og 10% passende? Farver kan frit vælges af udvikleren.
  2. Den cirkelformede sprite skal kunne styres med piletasterne. Dens udgangspunkt skal vælges tilfældigt indenfor banen med mindst en diameters afstand til kvadraten. Hastigheden kan frit vælges af udvikleren.
  3. Hvis den går udenfor brugerfladens kanter, så skal den komme ind på spllebanen fra den modsatte side. Helt præcis hvordan dette sker kan frit vælges af udvikleren.
  4. Den kvadratformede sprites centrum skal placeres midt i spillets brugerflade. Nærmer detaljer, såsom om den roterer eller om størrelsen måske varierer som funktion af tiden, -det kan frit vælges af udvikleren.
  5. Der skal implementeres en test til at afgøre om de to sprites rører hinanden (Collision Detection).
  6. Der gives "-1" point ved hvert sammenstød.
  7. Points skal vises i øverste højre hjørne af spillets brugerflade.