2012KomItC14

From rtgkomArkiv
Jump to: navigation, search

Contents

Sommerprodukt: Virtuel vaffelis, 2013-05-24, Gkb[edit]

I anledning af at sommeren endelig virker være kommet og som lidt forskud på næste års arbejde med programmeringssproget Python, så ville vi prøve at producere virtuel vaffelis med Python og modulet Visual.

Instruktionen som jeg gav var meget kortfattet. Den lød omtrent sådan:

Del 1: Kugle og kegle på et skakbræt[edit]

-Download og installer Python og modulet Visual via de links som du finder på vpython.org. (Søg evt. på "visual python").
-Brug linkene "Documentation" og "Full documentation" på vpython.org til at få lidt hjælp og inspiration. Det skal føre til http://www.vpython.org/contents/docs/index.html.
-Afprøv følgede program i IDLE editioren:
    import visual
    visual.sphere()
  og prøv at navigere i billedet af kuglen med musen.
-Afprøv følgende program også:
    import visual
    visual.sphere(radius=0.7)
    visual.box()
-Lav nu en model med en kugle og en kegle som står på en overflade som ligner et skakbræt. 
 Roter med musen og opstil billed og kildekode side om side på skærmen og gem skærmbilledet som en PNG fil.
-Publiser på dit StudieWeb med en kort kommentar.

Del 2: Virtuel Vaffelis[edit]

-Lav nu en vaffelis med tre kugler, rød, grøn og blå. Publiser billedet og koden ved hjælp af et skærmbilled på dit StudieWeb med en kort kommentar.

Flere af eleverne blev færdige med den første del, altså kuglen og keglen på skakbrættet. Ideen om vaffelisen kom først i slutningen af modulet, så det kigger vi nærmere på næste gang.

Det er interessant at notere sig at der var nærmest ingen instruktion i anvendelsen af programmeringssproget, det var selve værktøjet og den tilhørende dokumentation som eleverne brugte til at løse opgaven. Dette er et eksempel på det som jeg kalder værktøjsbaseret læring (Tool Based Learning, for nu at være lidt internationel). Det at anvende gode, ofte også avancerede værktøjer som er veldokumenteret, kan helt enkelt erstatte tavleundervisning og projektor-demonstrationer.

Aflevering af produkt og rapport, 2013-05-03, Gkb[edit]

Produkt og rapport skal uploades til hver enkelt elevs StudieWeb i mappen afsluttende_opgave_2013, som jeg har lavet specielt til dette formål i jeres html mappe.

Om I har arbejdet sammen i en gruppe, så uploader alle gruppens medlemmer samme rapport og samme produkt, hver til sit StudieWeb. Dette koster lidt ekstra lagerplads, men da hver enkelt elev er ansvarlig for afleveringen, så bruger vi denne løsning til at sikre at I har fuld kontrol over det afleverede materiale.

I kan så individuelt kort præsentere denne aflevering på jeres StudieWeb, sådan som I har gjort med de andre opgaver i løbet af året.

(Nogle få grupper ønskede at bruge en projekt-user til afleveringen og de afleverer så både produkt og rapport der, men lav en lille html fil med en hyperlink til projekt-user'en, og læg den i mappen afsluttende_opgave_2013 som jeg har oprettet i jeres egen html mappe.)

Jeres skrive-rettigheder til afleveringsmappen vil blive fjærnet når tidsfristen for afleveringen udløber, -eller nogle dage senere. Det bliver fortsat muligt at browse jeres afleverede filer.

Inspirationsmateriale til skriveprocessen[edit]

Det kan være en fordel at bruge følgende kilder til inspiration ved skriveprocessen:

Se i øvrigt også litteraturhenvisningerne i oplæggene for de opgaver og projekter vi har gennemført i løbet af skoleåret. De ligger her Opgaver.

Se også gerne den lidt mere omfattende samling af litteraturhenvisninge i vores wiki'artikel MediaLab:Fagenes Litteratur, hvor den første kolonne i den store tabel indeholder links til både tekster og vidoe'er som på forskellig vis belyser dele af fagets kernestof.

Kravspecifikation (KS) og Testspecifikation (TS), deres funktion i et projekt, 2013-04-19, Gkb[edit]

I et "rigtigt" projekt, hvor en køber, for eksempel en virksomhed bestiller et IT-produkt (medieprodukt) som skal løse et bestemt problem fra en producent, som skal have ansvaret for udviklingen af produktet, så er der behov for fælles forståelse og enighed om hvad det faktisk er som som skal leveres. At kende og være enige om krav og hvordan de skal testes er en vigtig forudsætning for at køber og sælger (producenten) kan lave en fornuftig kontrakt om arbejdet. Der skal jo betales penge for produktet, evt. mange penge, og der opstår let uenighed og ulyst til at betale hvis køber ikke kan genkende sine ønsker i det produkt som producenten leverer.

Der er udviklet mange tekniker til at fange og fastholde krav til produktet. I de fleste tilfælde bruges flere tekniker på en gang. Vi forsøger at lære at bruge User Stories og kravspecifikation (KS), som er en mere detaljeret beskrivelse af karvene i en liste. Yderligere prøver vi at lære at bruge en testspecifikation til at planlægge afprøvningen af om de krav som udtrykkes i brugshistorierne og kravspecifikationen faktisk er opfyldt.

Nedenfor illustreres en måde at lave kravspecifikation og testspecifikation på. For at forstå meningen med disse dokumenter, så kan det være en hjælp at tænke sig at der evt. skal laves en kontrakt om projektet og at der evt. skal betales mange penge for det, f.eks. en million kroner. Hvornår skal pengene betales? Skal de alle betales på en gang, eller skal der aftales delbetalinger? Hvordan skal det formuleres i kontrakten? Det er der vi kan med fordel henvise til kravspecifikationen og testspecifikatione.

asdf asdf

Indsæt billeder/skitser her!

Interaktionsdesign, hvad kan det handle om?[edit]

Når I designer jeres produkter, så kan I f.eks. tage afsæt i den designmodel som vi har givet navnet Designmodel II, altså den model som sætter fokus på Visuelt design, Informationsdesign og Interaktionsdesign. Hvis vi fokuserer på interaktionsdesign, så handler det altså om hvordan brugeren kan interagere med produktet. Typis ved hjælp af tastaturet, musen og skærmen. Altså klikke eller skrive noget og så på baggrund af oftest ret så hurtig svar (feedback) fra produktet skrive mere og klikke mere og observere hvad der så sker med produktets brugerflade (User Interface, UI).

Men interaktion mellem bruger og produkt (menneske og maskine) kan også ske vha. andet udstyr, f.eks. mikrofon, kamera osv.

Registrering af grupper og valgt oplæg, 2013-04-05, Gkb[edit]

Registrer venligst jeres projekt i tabellen nedenfor.

Valg af oplæg og grupperegistrering[edit]

Afsluttende opgave - valg af oplæg og grupperegistrering
Gruppenr. Dit/jeres navn/navne Oplæg Kort beskrivelse af ideen Titel for opgaven Medieprodukt/-er Værktøjer til fremstilling af medieproduktet/-erne
01 Jacob Elmkjær, Frederik Bagger, Jacob Sørensen 1 Et website der kan vejlede RTG's kommende 1. års elever til Matematik/Fysik/Kemi aspektet til Ballonprojektet. JFJ's Tutorial til Ballonprojekt Website Notepad++, WinScp, Inkscape.
02 Lars-Emil J, Frederik F.E, Adam k 2 Et regneark der kan udregne de forskellige vinkler og længder på ballonen Auto udregning af ballon Regneark Microsoft Excel, Notepad++, WinScp, jedit.
03 Thomas Gram, Mads Hougaard og Jakob Jelstad. 1 Tips og læring til design af ballon. Ballon design step by step. Html hjemmeside. jedit, Microsoft word, WinScp, Html, inkscape.
04 Jacob Ruager 2 En applikation der kan beregne data til ballonen. Der fokuseres på kemi- og fysikberegninger. balloon_calc Windows applikation Microsoft Visual Studio Express 2012, Gimp 2, GanntProject og WinSCP (Upload).
05 Thomas Hernes, Anders Møllnitz og Dan Sørensen 1 Hvordan man skal klare ballonprojektet Guide til ballonenprojektet Hjemmeside på studieweb og på rtgkom (med mediawiki) Jedit, Mediawiki, Microsoft Word
06 Mathias Ballonens Historie i en form for tidslinje som man selv kan gå rundt og opleve og hvor man vil starte på tidslinjen. Varmluftballonens Tidlinje Præsentation, HTML Hjemmeside PowerPoint, Jedit, HTML, Notepad++
07 Philip Elbek, Christopher Simonsen, Casper Lykke Larsen Disse ting skal man overveje, når man laver en brænder til ballonen En sammenhængende tekst, hvor at vi beskriver de opservationer vi har gjort os, da vi lavede vores ballonbrænder. Guide til brænder Flowdiagram, dispossition, Hjemmeside WinSCP, Notepad ++, Microsoft Word,
08 Rune, Mads Poulsen, Hussein 1 Et spil der kan bruges som repetition. Ballon Quizzen Et spil Gamemaker
09 Jacob Hjortshøj,Frederik Thuldstrup, Jonatan 1, e-learning berening af ballonen ved hjælp af PHP Matematik design af ballon PHP beregner og grafisk afput Notepad++,WinSCP, jEdit, PHP, GDlib, Gimp
10 Magnus Thestrup Holm e-learning Kort guide til at lave en ballon i html Ballon guide HTML side jEdit, WinSCP, Word
11 Kevin Høst Husted E-lerning Step by step multimedie præsentation powerpoint
Gruppenr. Navn/navne Oplæg Beskrivelse Titel Produkt/-er Værktøjer

Afsluttende opgave, arbejdet fortsat, 2013-04-04, Gkb[edit]

Vi fik dette modul med kort varsel fra teknologifaget, tak.

Computerens anatomi, om aflevering af medieprodukt og dokumentation, 2013-03-15, Gkb[edit]

På grund af den forsinkede aflevering af projektet om computerspil, både på grund af problemer med vores IT-system som var utilgængeligt i ca. to uger, og på grund af vores afprøvning af projektbruger-funktionen til aflevering af projektet om computerspil, så er afleveringsfristen for opgaven om Computerens anatomi forlænget og kravene til afleveringen er reduceret noget i forhold til det som står i oplægget. Se nærmere her nedenfor.

Afleveringsstedet[edit]

Afleveringsstedet er ikke ændret i forhold til det der står i [oplægget], men her følger et kort resume og vejledning om visse praktiske forhold.

  • Aflever medieproduktet og dokumentationen på hver enkelt gruppemedlems StudieWeb. Der er lavet en mappe med navnet computerens_anatomi i jeres html mappe. Læg dokumentationen og medieproduktet i denne mappe.
  • Dokumentationen må gerne udformes i HTML, men .doc, .docx og .pdf er også ok.
  • Lav gerne en HTML fil i denne mappe, f.eks. med navnet computerens_anatomi.html hvor I individuelt præsenterer både medieproduktet og dokumentationen med kort tekst, 2 til 10 linjer, og lav så hyperlinks til dokumentationen og produktet.
  • Lav en link til HTML filen fra din oversigt over opgaver og projekter således at gæster på dit StudieWeb let kan finde afleveringen.

Medieproduktet[edit]

Medieproduktet kan være en webside eller lille website, en folder, et plakat, en video, en multimediepræsentation (f.eks. lavet ved hjælp af Power Point eller OpenOffice Impress). Det behøver ikke beskrive hele computerens hardware, der kan fokuseres på et enkelt delsystem eller en enkelt hardwaredel. Det kan f.eks. beskrive grafiksystemet eller kun grafikkortet. Der kan også fokuseres på skræmen eller musen. Der behøves ikke gøres rede for alle de forskellige typer af grafiksystemer eller skærme eller grafikkort eller muse, -men den type som vælges skal beskrives med fotografier og tekst. Billederne skal I helst selv have lavet ved at fotografere eller tegne skitser af hardwaren.

Dokumentationen[edit]

Der skal ikke afleveres en rapport. Omfanget af dokumentationen kan være ca. fem til ti sider per gruppe. Det er tilstrækkeligt hvis dokumentationen omfatter følgende fem aspekter ved projektet.

1. Kommunikationsmæssige overvejelser[edit]

Definition af den kommunikationsmæssige situation[edit]

I kan frit finde på en situation (case eller scenarie) hvor jeres medieprodukt skal bruges.

  • I skal vælge en afsender.
  • I skal vælge hvilket budskab I vil forsøge at sende til målgruppen.
  • I skal vælge en målgruppe for jeres medieprodukt.
  • I skal vælge medie (kanal) for jeres budskab (kanal hvor produktet fremføres eller præsenteres).
  • I skal vælge hvilken effekt afsenderen ønsker at produktet skal have på målgruppen.

Sagt med andre ord, så skal I overveje og svare på Lasswells fem spørgsmål: Hvem siger hvad til hvem i hvilken kanal med hvilken effekt?

Valg af medieprodukt[edit]

Gør kort rede for hvilken type af medieprodukt I har valgt. Begrund valget ud fra jeres valg af målgruppe og hvor let eller svært det kan være at sørge for at målgruppens medlemmer faktisk ser produktet. Økonomiske aspekter ved produktion og distribution kan også være vigtige.

2. Desingovervejelser[edit]

Brug vores designmodel nr. II til at beskrive hvordan I har taget beslutninger om de tre designområder som modellen sætter fokus på. Det er områderne Informationsdesign, Interaktionsdesign og Visuelt design. Lav gerne en grov skitse, -en rough skitse (et helheds-rough), som viser hvilket layout I tænker jer for hele jeres medieprodukt.

Informationsdesign[edit]

Hvilke informationer har målgruppens medlemmer behov for? Hvor skal disse informationer placeres i produktet?

Interaktionsdesign[edit]

Hvilke behov har målgruppen for at kunne påvirke produktet? Det kan f.eks. være at vælge næste side, gå tilbage til startsiden, starte eller stoppe en video osv. Dette implementeres ofte ved hjælp af knapper i brugerfladen. Hvilken interaktionsmuligheder skal implementeres i jeres produkt og hvordan?

Visuelt design[edit]

Hvilke farver kan målgruppens medlemmer lide? Kan de bruges i produktet? Hvilken typografi, skriftsnit og opstilling af overskrifter og brødtekst vil tiltale målgruppen? Hvilke typer illustrationer (tegninger, fotografier mm) kan målgruppen lide? Hvilke visuelle virkemidler skal bruges i jeres produkt og hvordan skal de placeres?

3. Beskrivelse af fremstillingen af produktet, altså beskrivelse af implementeringen[edit]

Beskriv hvordan I lavede medieproduktet, altså hvordan I implementerede jeres ideer om design.

Brug meget gerne skærmbilleder fra udviklingsarbejdet og skriv korte forklaringer til hvert skærmbilled som forklarer hvad I er ved at lave på det tidspunkt når billedet blev lavet. Brug PrtScr (Print Screen) tasten hvis du bruger Windows, og så kan du indsætte (paste) billedet direkte ind i f.eks. Word eller OpenOffice Writer. I Ubuntu laves der vistnok automatisk en billedfil i mappen for billeder. På Mac i MacOS er det også muligt at lagre skærmbilledet på klippebordet, men man skal bruge tre eller fire taster samtidigt, så det er nok bedst at bruge et program som f.eks. Gimp, som har en særlig funktion til formålet.

Det kan være relevant både at vise hvor de forskellige designbeslutninger implementeres og hvordan værktøjets brugergrænseflade anvendes til det. Vælg nogle typiske tilfælde eller situatioener som kan bruges til at illustrere implementering af en designbeslutning og hvordan værktøjet blev brugt til det. Det kan f.eks. være placering af en overskrift og hvordan I har brugt dialogen for valg af skriftsnit til at vælge skriftsnittet Verdana og størrelsen 16 punkter. Forsøg ikke at dokumentere hele arbejdet med at lave produktet.

4.Beskrivelse af gruppens arbejde i projektperioden[edit]

Fordeling af arbejdsopgaver, tidsplan, og evt. også en journal over hvad faktisk blev lavet i de enkelte moduler i projektperioden.

5. Konklusion[edit]

En reflektion over hvordan arbejdet med projektet gik. Hvad var svært, hvad var mest interessant og hvad kunne gruppen tænke sig eventuelt at gøre anderledes i næste projekt?

Computerspil, 2013-01-23, Gkb[edit]

Fortsæt arbejdet med projektet om computerspil!!! Prøv at lave den første prototype færdig i dag! Husk at dokumentere alle aktiviteterne. Brug vores systemudviklingsmetode! Forbered test!

Computerspil, 2013-01-15, Gkb[edit]

I dag skal grupperne fortsætte arbejdet med projekte om computerspil. Prøv at lave følgende aktiviteter, evt. passer aktiviteterne ille lige godt til alle grupperne, prøv så at vælge dem som passer jer bedst og lave så mange af dem som muligt.

  • Vælge målgruppe.
  • User Stories. Brugerhistorier. Beskriv en typisk brugers forventninger til spillet. I Extreme Programming skal brugerhistorier skrives på en helt speciel måde i et helt specielt format, se her et eksemple på userstories for en kaffemaskine.
  • Vælge budskab og formål med spillet (Husk at det skal være et pædagogisk, etisk og moralskt positivt!)
  • Lave skitser som viser hvordan interaktionen mellem brugere og spil (program) skal virke.
  • Vælge titel og undertitel til projektet.
  • Registrere gruppen i skemaet nedenfor, i notatet til modulet den 11. januar. Brug gerne samme computer, hvis der er mange grupper som vil redigere, ellers får vi lidt problemer med at vælge hvilken version af wiki-artiklen skal være den nyeste. For forklaring på dette problem se geren "View history" øverst på denne side.*Vælge værktøj til at lave spillet med, altså til at implementere jeres design.
  • Spike Solution. Hvis I ikke er sikre på at I kan anvende et værktøj, så skal I evt. afprøve nogen helt specifikke tekniske detaljer med det valgte værktøj, f.eks. hvordan man kan lave et sammenstød hvor den ene eller begge parter (objekts) forsvinder. Den slags hurtige test kaldes i systemudviklingsmetoden Extreme Programming (XP) for Spike Solutions og det er altså et af de begreber som vi gerne vil lære at bruge når vi taler om systemudvikling.
  • Forsøge at implementere noget af jeres designe i en prototype. F.eks. en enkelt sammenstød med lyd.

Computerspil, 2013-01-11, Gkb[edit]

  • I dag skal vi fortsætte med afprøvning af mindst to forskellige værktøjer til at lave et meget enkelt computerspil.
  • Emnet som I vil lave et spil om skal defineres. Husk at det skal være etiskt og moralskt positivt!!!
  • Arbejdsgrupper skal dannes, og registreres.

Arbejdsgrupper, registrer jeres gruppe her![edit]

Her er først et eksempel:



  • Gruppe nr 7: http://www.rtgkom.dk:82/asdf, http://www.rtgkom.dk/~2012asdf
    • Kort projekttitel (max 18 tegn): schooltime
    • Lang projekttitel (max 100 tegn): School Time er et simulation spil om hvor du går rundt i en verden og udforske en skole
    • Frederik Thulstrup, frederikzt12
    • Jonatan Hvidberg , jonatangh12
    • Mathias Wissing-Thornberg, mathiaswt12
    • Navn, UserID
  • Gruppe nr 8: http://www.rtgkom.dk:82/asdf, http://www.rtgkom.dk/~2012asdf
    • Kort projekttitel (max 18 tegn): Fodboldspil
    • Lang projekttitel (max 100 tegn): "Fodboldspil" handler om at samarbejde i hold og om motivering.
    • Philip Elbek, philipe12
    • Christopher Simonsen, christopherss12
    • Navn, UserID
    • Navn, UserID

Programmering med Python, Reflektion over fagets indhold og metoder, projekt om computerspil, 2013-01-09, Gkb[edit]

Programmering med Python[edit]

Reflektion over fagets indhold og metoder[edit]

Projekt om computerspil[edit]

Min første NetLogo App, 2012-12-20, Gkb[edit]

I anledning af juleferien leger vi i dag med nyt legetøj, I kan kalde det en julegave hvis I vil og resultatet kan opfattes som julepynt til jeres StudieWeb hvis I vil.

Det handler om at vi skal lave et program med udviklingsværktøjet NetLogo og exportere det som en Java applet og uploade det til vores StudieWeb, hvor hele verden skal kunne afprøv det.

Programmerne som vi laver med NetLogo kaldes modeller og vi skriver i programmeringssproget Logo. Her er adressen hvor I kan hente NetLogo fra: http://ccl.northwestern.edu/netlogo/ og her er en link til info om manden som lavede NetLogo, Uri Wilensky: http://ccl.northwestern.edu/uri/

NetLogo bygger på stolte traditioner i forbindelse med programmeringssproget Logo helt tilbage fra 70'erne, hvor Seymour Papert lavede sproget som et af de tiltag som USA fandt på når russerne kom først op i rummet med sine Sputnik'er. Meningen med Logo var og er fortsat at unge og gamle skal kunne bruge sproget til at lege sig til forståelse af logik og matematik. Med NetLogo har Uri Wilensky lavet en platform som specielt er beregnet til at gøre det let at modellere og simulere komplekse proceser som inkluderer mange agenter, f.eks. molekyler eller kaniner og reve. NetLogo bruger skildpadegrafik til visualiseringen, men skjoldpadegrafiken blev tilføjet til Logo nogen år efter at sproget blev lavet.

Lav et lille program, altså model, med NetLogo, exporter som en applet og publiser på dit StudieWeb. Der er ingen særlige krav andet end at programmet skal gerne indeholde en Setup knap og en Go knap, fordi det er almindeligt i NetLogo modeller.

God Jul!

StudieWeb II, 2012-12-11, Gkb[edit]

Og i dag fortsætter vi eftersynet på vores StudieWeb. Brug modellen som vi udviklede i går. Se efter hvordan dit StudieWeb er lavet indholdsmæssigt, kommunikationsmæssigt, tekniskt, designmæssigt og etisk og moralskt.

Jeg vil komme rundt til hver enkelt elev og så skal I

  • præsentere for mig hvordan I har lavet jeres StudieWeb med afsæt i modellen og
  • vælge hvilket aspekt i modellen I nu vil fokusere på at forbedre jeres StudieWeb på.

StudieWeb II, 2012-12-10, Gkb[edit]

Vi starer nu forløbet StudieWeb II, som går ud på at forbedre vores StudieWeb på forskellige måder. Det besdste er måske at læse oplægget igen og se om man har fået det hele med.

Som yderligere hjælp til at strukturere arbejdet kan vi også bruge følgende model når vi vælger hvilke aspekter ved vores StudieWeb vi vil forbedre:

Her kommer nogle tips i forbindelse med forbedringsprocessen:

Klima i tal og grafik, 2012-11-19, Gkb[edit]

I dag fokuserede vi på at lave et af de medieprodukter som grupperne skal brug på studieretningsudstillingen. Det er dette produkt som vi skal dokumentere i rapporterene.

http://posterazor.sourceforge.net/

http://posterprinter.sourceforge.net/

http://sourceforge.net/projects/pdfcreator/

Gode kilder, 2012-10-30, Madsh12[edit]

Jeg har lige fundet den her gode kilde, med massere af info: http://www.klimaupdate.dk

Klima i tal og grafik, 2012-10-29, Gkb[edit]

Vi arbejder i dag videre med at finpudse projektbeskrivelsen.

Der er flere måder at lave en projektbeskrivelse. Prøv f.eks. at se hvordan vores elever har lavet sine projektbeskrivelser i fagene Informationsteknologi B, Kommunikation/IT C og A og Teknologi B i løbet af de ca. 10 år som vores elever har brugt vores webserver http://rtgkom.dk, til at publisere information om sine projekter, -og i mange tilfælde hele projektrapporter. Se også gerne som inspiration MediaLab's guide for hvordan man kan skrive projektskrivelse og rapport: http://rtgkom.dk/wiki/Guide:Projektbeskrivelse_og_rapport.

Brug følgende søgning i Google: "problemformulering , løsningsforslag, site:rtgkom.dk" eller en variant af dette.

Følgende punkter skal som minimum tilgodeses i den foreløbige projektbeskrivelse:

  • problemobservation,
  • problemtræ,
  • begyndende problemanalyse,
  • kildeoversigt

Den færdige projektbeskrivelse skal nok i alle tilfælde indeholde følgende afsnit eller aspekter:

  • problemanalyse (opbygget efter tragtmodellen),
  • problemformulering,
  • definition af målgruppen,
  • krav til løsningen,
  • diskussion af flere løsninger med udgangspunkt i kravene,
  • foreløbig tidsplan,
  • oversigt over kilder.

Vejledning for arbejdet med ID-kortet, 2012-08-28, Gkb[edit]

Se foreløbig her http://www.rtgkom.dk/~gkb/