2014InfB34

From rtgkomArkiv
Jump to: navigation, search

Contents

Spørgetime - referat og generel vejledning om forberedelse til eksamen, Gkb 16:54, 12 June 2015 (CEST)[edit]

Vi havde spørgetime i dag 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 det 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 en kopi af min vejledning om forberedelse til eksamen sidste år, altså for holdet som hedder 2103InfB34 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.

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 30 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 30 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 comuter 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å:

– analysen og beskrivelse af projektets problemstillinger

– problemløsning og valg af løsninger, herunder nyskabende værdi

– kvaliteten af det praktiske produkt

– fremlæggelsen og forsvaret af projektet

– rapportens dokumentations- og kommunikationsværdi

– besvarelse af uddybende og supplerende spørgsmål.

Der gives én karakter på grundlag af en helhedsbedømmelse af eksaminandens præstation omfattende projektrapporten, produktet og den mundtlige prøve.

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 grundlæggende funktioner af it-komponenter (hardware og software) og samspillet mellem dem

– redegøre for samspillet mellem it-komponenter og bruger

– redegøre for samspillet mellem it-komponenter og de fysiske omgivelser

– beskrive sammensatte systemer opbygget af virtuelle niveauer

– analysere og beskrive sikkerhedsbehov og risikofaktorer ved brug at et givent it-system

– vælge og bruge it-komponenter som værktøj til løsning af et problem med relation til elevens, uddannelsens, virksomheders og samfundets brug

– anvende it som interaktivt medie til dokumentation og kommunikation

– redegøre for innovative it-systemer sammenholdt med egne it-løsninger

– realisere prototyper på it-systemer, herunder kunne installere, konfigurere og tilpasse relevante it-komponenter.

Se gerne selv nærmere i bilaget for faget i Htx-bekendtgørelsen, https://www.retsinformation.dk/Forms/R0710.aspx?id=152550#Bil16

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.

Multimediepræsentation om projeket, Opdatering af StudieWeb og Guideo van Robot, Gkb 16:43, 18 May 2015 (CEST)[edit]

Nu når eksamensprojekterne er afleveret i InfB og PrgC, så kan det være svært at fokusere på fagligt arbejde i de to sidste moduler, men jeg havde tre konkrete forslag for modulet i dag:

Multimediepræsentation om projeket[edit]

At lave en multimediepræsentation om projektet. Denne præsentation skal du nemlig bruge hvis du skal til mundtlig eksamen.

Opdatering af StudieWeb[edit]

At arbejde lidt med indholdet på dit StudieWeb. For eksempel linke til afleveringen af eksamensprojekterne i InfB og PrgC, hvis du ikke allerede har gjort det. Du kan også forbedre dokumentationen af nogle af de aktiviteter vi har haft i løbet af året eller tilføje nyt fagligt indhold, f.eks. små spike solution eller Hello World tests af nogle udviklingsværktøjer som du har brugt.

Guideo van Robot[edit]

Guideo van Robot er et meget enkelt værktøj, nærmest et spil, til at lære om programmering med Python. Det blev lavet af Steve Howell i 2001 og senere forbedret af flere, specielt af Paul Carduner. Se projektet her: http://gvr.sourceforge.net/. Hvis du hverken vil arbejde med multimediepræsentationen eller opdatere dit StudieWeb, så kan du downloade, installere, afprøve Guideo van Robot, lave et skærmbilled og skrive et kort notat på dit StudieWeb.

Referat[edit]

Trods de særlige omstændigheder var der faktisk flere som arbejdede med et eller flere af mine tre ovenfor stående forslag, - men der var flere forskellige andre faglige aktiviteter som satte præg på modulet, som f.eks.

  • Afprøvning af retro-spil på en Raspberry Pi.
  • Omstændig installering af Matplotlib modulet for Python 2.7 på Windows. Modul for modul, manuelt! God lejlighed til at øve brug af kommandoprompten, CMD, i Windows. Kontrasten med f.eks. at bruge apt-get install python-matplotlib i Ubuntu er stor. Der installeres de forskellige nødvendige moduler automatisk. Se gerne mere her http://matplotlib.org/users/installing.html. Dette oplevede flere af os sidste år, når vi brugte Matplotlib modulet i et projektforløb, ikke?

Sidste modul i faget i morgen[edit]

I morgen har vi vores sidste modul i faget. Vi fortsætter selvfølgelig det seriøse faglige arbejde og til sidst laver vi evaluering af undervisningen i faget ved hjælp af et spørgeskema på Lectio.

Aflevering på Fronter og Lectio og rtgkom.dk - Gkb 10:01, 7 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.

Første udkast til rapport, Gkb 10:53, 7 April 2015 (CEST)[edit]

I dag skal det første udkast til rapporten afleveres. Det er en god idé hvis I i den beskriver, eller påbegynder beskrivelsen af fremstilling af første prototype til jeres produkt. Det kan også være at I hellere vil beskrive nogle Spike Solutions til nogle af de kerneproblemer som I har indset at I må løse i jeres projekt.

Denne aflevering tjener det vigtige formål at hjælpe/tvinge jer til at begynde arbejdet med rapporten tidligt. Det er lidt op til jer selv hvilket indhold I vil have med i dette første udkast, men her følger nogle idéer. Se også http://www.rtgkom.dk/wiki/Guide:Projektbeskrivelse_og_rapport:

  • Forside, med relevant illustration og ID-info.
  • Indholdsfortegnelse (en slags plan for hvad rapporten skal indeholde)
  • Indledning, evt. med:
    • Analyse af problemområdet og argumentation for at der faktisk findes et problem)
    • Målgruppe
    • Valgt løsningsforslag
    • Kerneproblemer
    • Afgrænsning
    • Problemformulering
  • Krav fra brugerne
    • User Stories
    • Kravspecifikation (en mere formel punkt for punkt liste over krav til produktet)
  • Teoriafsnit
    • Systemudvikling
    • Python (hvis du/I bruger dette værktøj)
    • Brugbarhed (hvis relevant)
    • OCR (hvis relevant)
  • Spike Solutions til kerneproblemer
  • Prototype I
    • User Stories som skal indgå i 1. prototype
    • Kravspecifikation
    • Testspecifikation
    • Design
    • Implementering
    • Test
  • Milestone I (Opgerøelse af status og beslutning om det fortsatte arbejde)
  • Prototype II
    • User Stories som skal indgå i 1. prototype
    • Kravspecifikation
    • Testspecifikation
    • Design
    • Implementering
    • Test
  • Milestone II
  • Konklusion
  • Bilag:
    • Projektbeskrivelse
    • asdf

Hvis I er to eller flere i en gruppe, så husk kravet om at det skal være muligt af rapporten (journalen) at se hvem har lavet hvilke afsnit. Nogle afsnit er I nok fælles om og andre har I individuelt ansvar for. Dette kan markeres på forskellige måder i indholdsfortegnelsen og i begyndelsen af hvert afsnit. Prøv at finde en løsning som ikke er alt for kraftigt fremtonende i teksten.

Kerneproblemer[edit]

Her er nogle Kerneproblemer som blev diskuteret i klassen i dag.

Afrundning af tal i JavaScript[edit]

Følgende test som er lavet i JavaScript konsolen i Chrome viser hvordan man kan styre antallet af ciffre efter kommaen, dvs. efter decimalpunktet.

x = 1.23456789
1.23456789
x
1.23456789
Math.round(x,3)
1
Math.round(x*100)/100
1.23
Math.round(x*1000000)/1000000
1.234568

Embedding of PDF in HTML[edit]

<embed src="eksempel.pdf"> Dog virker dette ikke i chrome da browseren ikke har dette plugin by default, så det skal downloades hvis det skal virke.

Udkast til projektbeskrivelse, User Stories, Gkb 17:21, 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

Afsluttende projekt, Projektbeskrivelse, Gkb 03:01, 3 March 2015 (CET)[edit]

Vi begyndte på eksamensprojektet i sidste uge, her kommer en opdateret version af projektoplægget: http://rtgkom.dk/~gkb/pubdoc/2015InfB34-oplaeg-til-afsluttende-projekt.pdf.

Delafleveringerne er registreret som opgaver i Lectio.

Første delaflevering er Udkast til projektbeskrivelse, som skal afleveres tirsdag i næste uge.

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

Afsluttende projekt, tirsdag 2015-02-24[edit]

Vi startede eksamensprojektet straks efter vinterferien. Vi så sidste års projektoplæg og gamle rapporter. Du kan selv vælge temaet for dit projekt, men projektbeskrivelsen skal godkendes af skolen.

Dokumentation af øvelsen Box med Python i Blender, Gkb 11:26, 13 February 2015 (CET)[edit]

Dokumenter dit arbejde med øvelsen på dit StudieWeb med mindst et skærmbilled og beskrivelse af hvordan du brugte Python i Blender.

Brug helskærms-skærmdumps til PNG format og reducer størrelsen på billederne til det halve eller endnu mere til brug i din dokumentation. Brug så de formindskede billeder som links til de oprindelige PNG filer, således at en interesseret læser kan klikke og se alle detaljerne.

Box med Python i Blender, Gkb 12:13, 27 January 2015 (CET)[edit]

I dag lavede vi en øvelse i 3D modellering i Blender ved hjælp af den Python terminal og editor som er indbygget i Blander. Vi satte os som et mål at lave en Hello World applikation som laver ti bokse på rad som så morfes over i kugler. Det sidste med at morfe boksene til kugler kan evt. erstattes af at animere lidt bevægelse, rotation og størrelsesændring for en eller flere af boksene.

Det vigtige er selvfølgelig ikke at lave en 3D model i Blender præcis som beskrevet ovenfor, -men at lære lidt om brugerfladen, GUI'en, på Blender, lære hvordan vi kan få tilgang til Python terminalen inde i Blender og hvordan vi kan bruge den til at give kommandoer som bruger nogen af den Python API som stilles til rådighed for os i Blender. Det er også meningen med denne øvelse at lære at bruge editoren i Blender til at skrive Python scripts som vi kan eksekvere.


Her er en outline af den fremgangsmåde som jeg brugte til at komme i gang med opgaven:

  1. Installering af Blender. Jeg arbejdede på Ubuntu, så jeg måtte nøjes med version 2.6noget, vistnok.
  2. Valg af vejledningsmateriale. Jeg valgte at bruge de links som findes i "Help" menuen i Blender. Det førte mig til onlineversionen af manualen, på http://wiki.blender.org/index.php/Doc:2.6/Manual. Efter lidt undersøgelse af manualen så jeg at kapitlet "Extending Blender" tilsyneladende indeholdt den information som jeg søgte.
  3. Jeg brugte afsnittet Python Scripting in Blender, som fører til en manualside med overskriften Blender 2.6, Python Manual. Der skimmede jeg indholdet i sektionen General information og skyndte mig videre til sektionen General information, hvor jeg fulgte slaviskt følgende tre tutorials:
    1. Hello World
    2. Console
    3. Text editor

Disse tutorials indeholder vistnok alt som vi har behov for at vide om Python i Blender, for at lave denne lille øvelse.

Hint: Brug dir() fuktionen ofte til at undersøge hvilken funktionalitet gemmer sig inde i de forskellige objekter i API'en i bpy modulet. Du kan f.eks. prøve dir(bpy) i Python terminalen. Og så dir(bpy.context) og dir(bpy.context.selected_objects) osv.

Vi fandt et eksempel-script på nettet (hvem?, hvor? indsæt link!) som laver masser af kugler i spiralformede baner. Vi testede det og her er det resulterende skærmbilled. http://rtgkom.dk/~gkb/billeder/Python_i_Blender_Mange_smaa_kugler.png

Dokumentation, Socket programmering og SSH programmering med Python; mandag 2015-01-19, Gkb 10:44, 19 January 2015 (CET)[edit]

Dokumentation af afprøvning af Cain & Abel, Wireshark og Zenmap[edit]

Dokumenter din afprøvning af de tre programmer på dit StudieWeb med mindst et skærmbilled for hvert program og beskrivelse af hvordan du brugte det.

Brug helskærms-skærmdumps til PNG format og reducer størrelsen på billederne til det halve eller endnu mere til brug i din dokumentation. Brug så de formindskede billeder som links til de oprindelige PNG filer, således at en interesseret læser kan klikke og se alle detaljerne.

Socket programmering med Python[edit]

Afprøv hvordan Socket modulet kan bruges til at sende en stræng fra en maskine (clienten) til en anden (serveren) som ændrer strængen og sender den tilbage til clienten som udskriver strængen på skærmen, således at vi kan se at den faktisk har været en tur over til serveren og tilbage til clienten.

Det første eksempel på https://docs.python.org/2/library/socket.html kan bruges til løse denne opgave. Her er et skærmdump som viser hvordan det gik når jeg afprøvede eksemplet.

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

SSH programmering med Python[edit]

Afprøv hvordan Python kan bruges til at logge ind i en shell på en anden computer og eksekvere kommandoer i den. Her er nogle kilder som jeg tror at kan hjælpe jer i gang. Brug gerne vores arbejsstationer med Ubuntu. Der kan I installere en SSH server, hvis den ikke allerede findes.

Cain & Abel, Wireshark og Zenmap; tirsdag 2015-01-13, Gkb 01:16, 19 January 2015 (CET)[edit]

Cain & Abel[edit]

Jacob Ruager demonstrerede hvordan programmet kan bruges til at opfange et password.

Wireshark[edit]

Jacob Elmkjær demonstrerede hvordan programmet kan bruges til at undersoege IP og MAC adresser hos afsendere og modtagere af ARP pakker.

Zenmap[edit]

Og saa viste jeg hvordan Zenmap kan brues til at scanne det lokale netvaerk, LAN, og lave en visuel praesentation af de computere som den opdager.

IT sikkerhed, netværk og protokoller; mandag 2014-01-05, første modul efter juleferien, Gkb 13:29, 15 January 2015 (CET)[edit]

Vi diskuterede og aftalte at arbejde med IT sikkerhed i de kommende, måske to til tre uger. Det bliver individuelt eksperimenterende arbejde hvor vi hver for sig og i fælleskab afprøver forskellige funktioner i operativsystemer og bruger forskellige programmer til at undersøge forhold med relation til IT sikkerhed.

Jeg lagde ud med at foreslå afprøvning af programmet Wireshark til at sniffe netværkstraffiken på vores LAN her i MediaLab.

Da IT sikkerhed i høj grad er afhængig af hvor stærke passwords brugerne bruger og af hvordan disse bliver sendt over netværket, så foreslog jeg at vi også læser om og evt. også på særligt isoleret netværk afprøver programmet Cain & Abel fra http://www.oxid.it/cain.html som er vistnok specielt lavet til at sniffe og afkode/gætte passwords.

I forbindelse med afprøvning af specielt Wireshark vil det være uundgåeligt at orientere sig lidt i de protokoller som bruges på vores netværk og på Internettet i almindelighed. Specielt skal vi til at begynde med lægge mærke til den såkaldte OSI-model, Open Systems Interconnection model fra den internationelle standerdiseringsorganisation The International Organization for Standardization (ISO).

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxx Jul og nytår 2014/2015 xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Velkommen tilbage !![edit]

- til jeres tredje år på RTG og andet år med Informationsteknologi B.


Det er det sidste af to år med faget og I kan se læreplanen for faget her: IT B på www.uvm.dk


I har jo været igang i nogle år før, så her finder I de gamle wiki-sider:

2012KomItC14 kommunikation/it C fra første år

og

2013InfB24 Informationsteknologi B fra jeres andet år


Jeg glæder mig til samarbejdet :-)

Mette Frost Nielsen


I har jo været igang i nogle år før, så her finder I de gamle wiki-sider:

2012KomItC14 kommunikation/it C fra første år

og

2013InfB24 Informationsteknologi B fra jeres andet år


Jeg glæder mig til samarbejdet :-)

Mette Frost Nielsen

Introduktion til PHP, MySQL og databaser[edit]

Vi skal igang med at opbygge noget grundviden om de tre nævnte sprog/systemer. Efter efterårsferien kommer I til at lave et projekt, hvor I kommer til at bruge jeres viden.


Modulplan:

Uge 34 tirsdag:

1. trin: installering af Wamp-server (W for Windows, så hvis du har et andet styresystem på f.eks. en Mac hedder det Mamp). Man kan f.eks. hente og installere det herfra: www.wampserver.com Her får man en pakke med både Apache, MySQL og PHP i det hele.

Nogle gange mangler den en fil (MSVCR110.dll) til slut i installationen, den får man ved at installere følgende Visual C++ pakke: www.microsoft.com/en-us/download/details.aspx?id=30679 (filen vcredist_x86.exe eller vcredist_x64.exe)

2. trin: test at det virker.

Gå tilbage til trin 1 og følg de tre trin efter installationen for at teste om det virker. Derefter kan du prøve trin 2.4 på følgende side: www.ntu.edu.sg/home/ehchua/programming/howto/WampServer_HowTo.html

3. trin: Bliv klogere på PHP.

Gå til siden www.codecademy.com opret dig som bruger og følg PHP-modulet.


Uge 34 torsdag:

Videre arbejde med PHP-modulet på www.codecademy.com


Uge 35 tirsdag:

Videre arbejde med PHP. I dag sætter vi fokus på indtastning af data og behandling af resultatet.

Gå ind på w3schools og læs om PHP Form Handling. Lav vha PHP en side, som kan løse en 2. gradsligning. Dette er en del-aflevering. I må være sammen 2 og 2 eller arbejde alene. Skriv kommentarer i programmet og læg det op på Studieweb.


Uge 35 torsdag:

Videre arbejde med PHP. Forskellen på metoden: POST og GET. Fik man ikke gjort øvelsen i tirsdags færdig fortsætter man med den ellers PHP-modulet på www.codecademy.com.


Uge 36 tirsdag:

Vi deler op i dag, så nogen kan gå videre med PHP og/eller MySQL, mens andre kan bruge tid på at lære sig at bruge Visual Python (eller PovRay eller Blender med Python).

Visual Python (VPython) henter I her: www.vpython.org


Uge 36 torsdag:

Når vi skal køre Python-programmer med visual-modulet bruges i stedet VIDLE. Her kan du f.eks. starte med at prøve at åbne og køre eksemplet bounce2.py. Derefter kan du lave dit eget lille program, hvor du får tegnet forskellige figurer, find inspiration og hjælp her: VisualIntro. Måske kan du også få noget til at bevæge sig ?


Uge 37 tirsdag:

Installer på forhånd POVRay på din computer. Den kan hentes her: www.povray.org Gå til download, hent og installer - også editoren.

POVRay og pair-programming - øvelse!!

1. Kør eksemplet: Ready made scene - scene 1

  prøv at se fra et andet kamera
  prøv at ændre farven på kuglen

2. Lathe-modulet

  se definitionen på lathe-modulet her: www.povray.org
  Her er to eksempler: [1] [2] [3]
  Lav jeres egen figur, som rotation om en akse 


Uge 37 torsdag:

Viderearbejde med POVRay. Øvelsen fra uge 35, samt øvelsen fra denne uge lægges på jeres StudieWeb. Husk kommentarer i programmerne og gør det tydeligt, hvem der har lavet det.

Sidst på modulet kommer Jørn og vi præsenterer det kommende projekt: Rumlige figurer

Rumlige figurer[edit]

I ugerne 38-40 arbejder vi sammen med matematik om projektet: Rumlige figurer.

I skal arbejde i grupper på 2-3 personer.

Afleveringsfrist er mandag d. 6. oktober 2014.


Uge 38 tirsdag: Eksempel på forskellige "splines" i lathe (PovRay) modulet. Arbejde videre med projektet.


Virtuelle niveauer[edit]

Når man beskriver et IT-system, opdeler man det ofte i tre virtuelle niveauer:

  • Datalaget
  • Logiklaget
  • Præsentationslaget


Pair programming[edit]

Hvad er det?

da.wikipedia.org/wiki/Parprogrammering

guide.agilealliance.org/guide/pairing.html


Hvorfor nu det? softwarecreation.org/2008/pair-programming-to-do-or-not-to-do

I hvilken sammenhæng? www.extremeprogramming.org

Hvordan? www.wikihow.com/Pair-Program

Tidsregistreringssystem[edit]

Uge 41:

Efter efterårsferien går vi igang med projektet med at lave et tidsregistreringssystem.

Idag sætter vi fokus på MySQL eller blot SQL, som er et standardsprog til at tilgå databaser. Man kan hente data ud af tabeller og dermed lave nye tabeller og oversigter, man kan skabe tabeller fra bunden og sætte nye data ind i eksisterende tabeller. Hvis du allerede har MSAccess på din computer eller OpenBase kan du tage udgangspunkt i den database, der ligger på Lectio og følge den vejledning, der også ligger der. Har du ikke nogen af disse databasesystemer på din computer, skal du gå ind på http://www.w3schools.com/sql/ og følge denne tutorial.


Uge 43, mandag: At danne E/R-diagrammer, læs mere på lektionen i Lectio

Uge 44, mandag: At danne en relationel Database på 3. normalform, se link til bogen på modulet i Lectio

Uge 44, tirsdag: Opret fælles projektbruger, opret databasen, design den visuelle grænseflade, påbegynd SQL-forespørgsler

Uge 45, mandag: At lave php-sider med indlejret SQL-forespørgsler til en database

Uge 45, tirsdag:

Uge 46, mandag:

Uge 46, tirsdag:

Uge 47, mandag:

Uge 47, tirsdag:

Uge 48, mandag:

Uge 48, tirsdag: Afslutning på projektet


App Inventor - styring af overvågningskamera[edit]

I de sidste to uger i år, inden I skal skrive SRP, skal der udvikles en lille App til en Android-enhed, som kan styre et overvågningskamera. Se hele oplægget på Lectio (holdets dokumenter). Her finder du også introduktion til styring af kameraet, samt hvordan du kommer igang med at lave en App.


uge 49 (ma): Introduktion til projektet. Første erfaring med AppInventor. Gruppedannelse: 3 i hver (da vi har 8 kameraer). Få kameraet op og køre trådløst, så det kan styres fra en browser (computer/smartphone). Følg vejledningen der medfølger kameraet.

uge 49 (ti): Opstart af udvikling af App til styring af kameraet. Brainstorm til yderligere funktionalitet. Tag billeder af forløbet.

uge 50 (ma): Videreudvikling af App og afprøvning. Husk at tage billeder fra udviklingsmiljøet og når App’en kører på mobilen.

uge 50 (ti): Dokumentering (billeder fra udviklingsmiljø, samt forklaring af kode) og upload til StudieWeb