2012PrgC336

From rtgkomArkiv
Jump to: navigation, search

Contents

Aflevering af eksamensprojekter i Programmering C og Informationsteknologi B, 2013-05-10, Gkb[edit]

Her kommer præcisering af forskellige praktiske forhold i forbindelse med aflevering af eksamensprojekterne i InfB og PrgC. Da mange elever har valgt at gennemføre eksamensprojekterne i disse fag som et fælles projekt, så beskrives kravene til afleveringen i begge fag her, -og samme information er kopieret til wiki'artiklerne for både PrgC og InfB for begge hold (3.4 og 3.36).

Afleveringsfristen er fredag d. 10. maj kl. 16:00, og det er ønskeligt at den digitale del af afleveringen gennemføres inden den frist. Den fysiske del af afleveringen kan overstås i løbet af mandagen d. 13. maj, hvor jeg bliver i MediaLab fra kl. ca. 10:00 til ca. 17:00 for at tage i mod rapporter og assistere dem som evt. har haft problemer med den digitale aflevering.

Hvis der opstår spørgsmål som ikke besvares i denne tekst, eller hvis der er uklarheder i teksten, så kan jeg kontaktes på min email, gkb@rts.dk. Se også projektoplægget for PrgC: http://rtgkom.dk/~gkb/prg/2012-2013/2013PrgC-Oplaeg-til-eksamensprojekt.pdf og projektoplægget for InfB: http://rtgkom.dk/wiki/BRW-AfsluttendeProjekt-2013

Rapport og journal og produkt[edit]

  • For begge fag gælder at dokumentation og produkt skal afleveres på elevens StudieWeb i mappen infb_prgc_eksamensprojekt som er oprettet specielt til dette formål.
  • Dokumentationen, rapport for InfB og journal for PrgC, skal også afleveres på papir. Tre (3) eksemplar i BEGGE fag. Husk også at fremstille fysiske eksemplar af rapport og CD for alle gruppemedlemmerne.
  • Produktet, skal så vidt muligt, vedlægges rapport/journal på en CD skive.
  • Fysiske produkter, såsom opstillinger med microkontrollere eller anden elektronik, samt produkter som er installeret på særlige computere, skal afleveres til opbevaring i MediaLab indtil eksamen.
  • I tilfælde af webbaserede client-server produkter, så skal produkterne helst være installeret på rtgkom.dk, og kunne afprøves der.
  • Hvis produktet er udviklet på en ekstern webserver og/eller hvis det gør brug af funktionalitet som vi ikke har på vores webserver, så behøver produktet ikke flyttes til rtgkom.dk. Henvis til serveren i dokumentationen.
  • Bemærk at i begge tilfælde (ekstern server eller rtgkom.dk), så skal alle data og scripts som behøves til at installere produktet, samt en vejledning om fremgangsmåden, vedlægges rapporten, -typisk som bilag i rapporten/journalen og/eller filer som uploades til afleveringsmappen eller som filer på CD'en.

Bemærk at der hverken i InfB eller PrgC forventes at censor afprøver produktet, og derfor er det vigtigt at dokumentere både produktets forskellige prototyper og den endelige udformning/funktion/udseende i rapporten/journalen. Skærmbilleder med korte kommentarer er velegnet til denne type dokumentation. Hvis der er mange skærmbilleder, altså f.eks. hvis produktet har mange funktioner som kun kan dokumenteres hver i sit skærmbilled, så læg gerne billederne og kommentarerne i et bilag.

Aflevering i Informationsteknologi B, den korte oversigt[edit]

  • Digital aflevering af produkt og rapport til afleveringsmappen som er oprettet til formålet på dit StudieWeb, infb_prgc_eksamensprojekt.
  • 1 eksemplar af rapporten med CD til skolens arkiv (tjener også som en backup, og kan senere gå til biblioteket)
  • 1 eksemplar af rapporten med CD til vejleder
  • 1 eksemplar af rapporten uden CD til censor (bemærk at censor altså ikke kan afprøve produktet, og at han/hun heller ikke har nogen skyldighed (eller tid) til at gøre det, selv om der i rapporten evt. er en link til en version som kan afprøves.)
  • Evt. fysisk opstilling eller computere.

Aflevering i Programmering C, den korte oversigt[edit]

  • Digital aflevering af produkt og journal til afleveringsmappen som er oprettet til formålet på dit StudieWeb, infb_prgc_eksamensprojekt.
  • 1 eksemplar af journalen med CD til skolens arkiv (tjener også som en backup, og kan senere gå til biblioteket)
  • 1 eksemplar af journalen med CD til vejleder
  • 1 eksemplar af journalen uden CD til censor (bemærk at censor altså ikke kan afprøve produktet, og at han/hun heller ikke har nogen skyldighed (eller tid) til at gøre det, selv om der i journalen evt. er en link til en version som kan afprøves.)
  • Evt. fysisk opstilling eller computere.

Indpakning/Indbindning[edit]

  • Brug helst de tynde plastikmapper, såkaldte tilbudsmapper. Brug gerne samme farve til alle jeres rapporter.
  • CD skiver skal lægges i en eller anden form for lomme som kan placeres bagerst i mappen. Det er godt hvis denne lomme kan lukkes således at CD'en ikke falder ud hvis rapporten af en eller anden grund vender toppen ned mod gulvet.

Antal sider[edit]

I PrgC er der i bekendtgørelsesbilaget fastsat en øvre grænse på 10 sider for journalen, og 20 sider for rapporten i InfB. Hvis I føler at I nærmer jer eller overskrider denne grænse for meget, så udnyt at flytte noget af indholdet til bilag.

Journal og rapport, hvorfor?[edit]

Når eksamensprojekterne i PrgC og InfB gennemføres som et samlet projekt, så kan det virke omstændigt at fremstille en journal til aflevering i PrgC og en rapport i InfB, men det er nødvendigt fordi der eksamineres i begge fag og der er ikke nogen garanti for at det bliver den samme censor i begge tilfælde.

Hvis du har lavet et samlet eksamensprojekt i begge fag, så kan journalen for PrgC let fremstilles ved at reducere eller fjærne afsnit i rapporten for InfB. Afsnit med følgende indhold kan evt. reduceres: Indledende analyser, overvejelser om målgruppe og kommunikation og i vis udstrækning overvejelser om design. Teoriafsnit kan fjærnes eller reduceres kraftigt og erstattes med henvisninge til kilder. Men reducer ikke beskrivelsen af implementeringen!

Eksamen[edit]

Et par dage inden den eventuelle mundtlige prøve holdes der en såkaldt spørgetime, hvor de elever som skal op til eksamen skal komme og kontrollere at deres produkter er installeret korrekt og kan afprøves fra eksamenscomputeren, altså den maskine som er tilkoblet projektoren i eksamenslokalet. Fysiske produkter køres på plads i eksamenslokalet og gøres klar til demonstration. Der bliver også mulighed for at stille afklarende spørgsmål om eksamen, og der gives gode råd om opbygning af præsentationen.

Eksamensprojekt: Arbejdsgrupper og projektinformation, Resurseplanlægning, 2013-03-19, Gkb[edit]

Arbejdsgrupper og projektinformation[edit]

Registrer jeres arbejdsgrupper i følgende tabel. Der er oprettet en mappe i jeres html-mappe med navnet infb_prgc_eksamensprojekt. Brug denne mappe til at aflevere projektbeskrivelsen. I kan også bruge den til alle andre filer, spike solutions, prototyper, billeder osv. som har med jeres eksamensprojekt at gøre. Disk quota er sat til 250 MB for alle indtil videre. Hvis der er behov for mere plads, så sig til.

Eksamensprojket - Arbejdsgrupper og projektinformation
Gruppenr. Dit/jeres navn/navne Titel Undertitel Kort beskrivelse af ideen Produkt/-er Værktøjer Projektbeskrivelse Rapport i InfB, link til ~/infb_prgc_eksamensprojekt/ Journal i PrgC, link til ~/infb_prgc_eksamensprojekt/
99 Karl Bjarnason Not To School Today Et system til understøttelse af hjæmmelæring Systemetttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt skal gøre det muligt i en lektion at samarbejde over afstand, således at deltagerene ikke behøver være i klasselokalet. Specielt lyd, men også billede, evt. video, af tavlen og projektorlærredet, samt oversigtsbillede fra klasselokalet skal præsenteres i en webbrowser hvor brugerne kan vælge hvilket billed de vil se. Client-Server webprodukt PHP, MySQL, tre webkameraer, en mikrofon, Python http://rtgkom.dk/~gkb/infb_prgc_eksamensprojekt/ http://rtgkom.dk/~gkb/infb_prgc_eksamensprojekt/ http://rtgkom.dk/~gkb/infb_prgc_eksamensprojekt/
1 Farnam Barati Webshop En webshop til eleverne på HTX En webshop med php, html5, html og CSS. En webshop og en hjemmeside. PHP, CSS, html5 og html. Se her http://rtgkom.dk/~farnambs10/infb_prgc_eksamensprojekt Rapport i InfB Journal i PrgC
2 Emil Lynegaard Triangle Solver A program for learning trigonometry En hjemmeside hvorpå man kan skrive de kendte vinkler/sider på en trekant ind, hvorefter siden vil regne de resterende vinkler/sider og forklare hvordan den gjorde. Hjemmeside HTML/Javascript/CSS http://www.rtgkom.dk/~emilcl10/infb_prgc_eksamensprojekt/Projektbeskrivelse.pdf Rapport i InfB Journal i PrgC
3 Steffen Immerkaer Integral/Areal udregner Et program til udregning af areal under graf (mellem 2 punkter). Produktet er et python program der kan integrere en bruger-indtastet graf, samt udregne arealet under grafen mellem 2 bruger-indtastede punkter på x-aksen. (Derudover kommer der måske en GUI, der vil gøre programmet mere anvendeligt og nemmere for brugeren). Python program • Python 2.6 (til programmeringen)

• Python modulerne PyLab, Numpy og Scipy (til udregningerne og visualiseringen) • WxPython (til GUI’en)

http://www.rtgkom.dk/~steffenhi10/eksamen/Problemformulering2.pdf Rapport i InfB Journal i PrgC
4 Malte Fibiger Nielsen Hokus pokus sikkerhed i fokus! Et script der kan lokalisere Scriptet ligger i roden af webserveren som bliver kørt jævnligt af et cron job det skal herefter scanne

alle mapper og filer, læse indholdet i filerne og finde ud af om de er skadelige for serveren.

Webprodukt PHP, Mysql og PhpMyAdmin http://rtgkom.dk/~maltefn10/infb_prgc_eksamensprojekt/Projektbeskrivelse%20IT%20og%20Programmering.pdf http://www.rtgkom.dk/~maltefn10/infb_prgc_eksamensprojekt/Rapport_IT.pdf http://www.rtgkom.dk/~maltefn10/infb_prgc_eksamensprojekt/Journal_programering.pdf
5 Leon Dønnergård Bøgelund Minecraft Minecraft mods Der er mangel på lærings mods til Minecraft, muligheden for at kombinere læring med sjov, er en god og alternativ løsning når man skal lære om nye ting. Dette kan nemlig hjælpe med til at gøre engagementet hos brugerne meget større, hvis Minecraft vel og mærke er et spil de finder sjovt. Så jeg har valgt at lave et lærings mod om materialers styrker, svagheder og holdbarhed. Et Minecraft mod
  • Java JKD og JRE
  • Minecraft Coder Pack
  • Eclipse
  • Modloader
http://www.rtgkom.dk/~leondb10/infb_prgc_eksamensprojekt/Projektbeskrivelse.pdf http://www.rtgkom.dk/~leondb10/infb_prgc_eksamensprojekt/Rapport-Informationsteknologi.pdf http://www.rtgkom.dk/~leondb10/infb_prgc_eksamensprojekt/Journal-Programmering.pdf
6 Bijan Taheri & Alexander Ibsen Bramsen Copenhagen Webshop til firmaet Bramsen Copenhagen, der skal laves et layout som de har givet samt en database over brugere og varer. Webshop og database PHP, MySQL, PHPmyAdmin http://www.rtgkom.dk/~bijanta10/infb_prgc_eksamensprojekt/produktbeskrivelse.pdf Rapport i InfB Journal i PrgC
7 Robert Radziszewski Webshop Ski webshop - Hjemmeside med database, evt. slideshow HTML, CSS, PHP, MySql http://www.rtgkom.dk/~robertar10/infb_prgc_eksamensprojekt/Projektbeskrivelse%20v.2.pdf Rapport i InfB Journal i PrgC
8 Rasmus Ketelsen Arduino controller Grafisk brugergrænseflade til styring af Arduino En GUI lavet i Python, som snakker sammen med et C/C++ program der ligger på en Arduino, der gør det muligt at styre nogle funktioner på en Arduino. Python GUI og Arduino program. Python 2.7, C/C++ http://www.rtgkom.dk/~rasmusk10/infb_prgc_eksamensprojekt/Projektbeskrivelse.pdf Rapport i InfB Journal i PrgC
9 August Møbius Tavledokumentation Uploader progression af tavler i klasseværelset. Idéen er at at et program løbende skal tage billeder af tavlen ved hjælp at et digitalkamera. Disse billeder kan bruges som dokumentation for undervisningen og lagring af idéer. Billeder skal uploades til en webserver hvor de er nemt tilgængelige for elever og lærere. Python-program og hjemmeside. Python, HTML, CSS. http://www.rtgkom.dk/~augustm10/Wiki/Projektbeskrivelse.pdf Rapport i InfB Journal i PrgC
10 Troels Ynddal Video Converter - Konvertere en vilkårlig videofil til MP4 Produkt/-er Python, wxPython og FFMPEG http://rtgkom.dk/~troelssy10/infb_prgc_eksamensprojekt/
11 Martin Fabricius Spiludvikling Læringsspil Et læringsspil for børn i alderen 6-9år, eller fra 0-3 klasse. Et spil med fokus på læring Python, IDLE og Tkinter. http://www.rtgkom.dk/~martinf10/infb_prgc_eksamensprojekt/Projektbeskrivelse-Martin.pdf http://www.rtgkom.dk/~martinf10/infb_prgc_eksamensprojekt/Rapport_IT_B-Martin_Fabricius.pdf http://www.rtgkom.dk/~martinf10/infb_prgc_eksamensprojekt/Jounal_Prg_C-Martin_Fabricius.pdf
12 Nicolaj Jensen Dice Sansynligheds regning en dice lavet i java, met en array som tæller hvor mnage gange de forskellige tal er blevet rullet Produkt/-er java - Eclipse http://www.rtgkom.dk/~nicolajj10/infb_prgc_eksamensprojekt/projekt.pdf Rapport i InfB Journal i PrgC
13 Dit/jeres navn/navne Titel Undertitel Kort beskrivelse af ideen Produkt/-er Værktøjer Projektbeskrivelse Rapport i InfB Journal i PrgC

Resurseplanlægning med Planner og Ganttproject[edit]

Med hensyn til registrering, altså synliggørelse, af planlægningsarbejdet, både mht. klassisk tidsplanlægning og så den lidt mere præcise og tekniske tilgang som jeg kalder for resurseplanlægning, så kan det være en god ide at bruge et specielt planlægningsværktøj som f.eks. programmet Planner, https://live.gnome.org/Planner. Det laver gantt-kortet automatisk når I har defineret resurser og tasks (aktiviteter) og man kan exportere det som HTML og skærmbilleder kan så laves og bruges i rapporten. Planner fås til Windows, Linux og kan vistnok tvinges til at køre på Mac.

Programmet er ikke helt stabilt, og vi har lagt mærke til at den nyeste version til Windows, planner-0.14.6.exe, crasher når man saver, så her er en direkte link til en lidt ældre version som virker ok på Windows XP, se her : http://sourceforge.net/projects/winplanner/?source=dlp

Et andet program, også med GPL licens, er Ganttproject, se her: http://www.ganttproject.biz/

Eksamensprojekt, arbejdet fortsætter, 2013-03-07, Gkb[edit]

Problem, kærneproblemer, tools og Spikes[edit]

Når du/I har en idé klar til hvad projektet skal handel om (altså problemet som skal løses), så er det vigtigt straks at analysere og finde de kærneproblemer som I antager at vil blive sværest at løse, og så angribe dem direkte med de tools (værktøjer) som du/I har valgt at bruge.

Denne fremgangsmåde reducerer den tekniske usikkerhed i jeres projekt og gør det lettere at vurdere hvor lang tid det vil tage at implemenetre brugerhistorierne (user stories), og dermed bliver det også lettere at lave en god projektbeskrivelse.

Eksamensprojekt, 2013-03-01, Gkb[edit]

Du kan selv vælge tema for dit projekt, men projektbeskrivelsen skal godkendes af skolen. Du kan arbejde på tværs af fagene, eller du kan vælge at afprøve og demonstrere et princip eller nogen teori indenfor programmering og systemudvikling. En god tilgang kan være at lave et produkt som andre kan lære af, eller udnytte til noget nyttigt. Vi har f.eks. mange ideer som vi ønsker udviklet til MediaLab. Se To-Do sektionen i Drift-artiklen på http://rtgkom.dk.

Du kan arbejde sammen med en ekstern rekvirent, men det skal godkendes af skolen og der skal laves en skriftlig aftale med rekvirenten.

Kærneproblmer i implementeringen, 2013-02-07, Gkb[edit]

Her er et forslag til definition af nogle af de kærneproblemer som vi kan møde ved implementeringen, samt nogle ideer om hvordan de kan løses når vi anvender Lazarus IDE (altså Object Pascal) til GUI'en og POV-Ray til renderingen.

  1. Definition af 3D modellen. Hvordan skal vi lagre modellen? Hvis vi vil bruge POV-Ray til at rendere, så vil en POV fil være et logiskt valg.
  2. Ændring af modellen. Hvordan overfører vi de nye værdier som indtastes i GUI'en til POV filen? Her er der tilsyneladende i hvert fald to alternativer:
    1. Indlæs 3D modellen fra POV filen til en liste af strænge (Array [1..100] of String), en for hver linje i filen, og skriv den ud til filen igen, men nu med ændringerne indført i den eller de linjer som indeholder de parametre som skal ændres.
    2. Skriv hele filen ud hver gang, altså hardkod POV koden i programmet.
  3. Rendering af 2D billed (projektion) af modellen.
  4. Placering af det renderede billed i GUI'en.

Diverse tips til programmeringen og planlægning af projektarbejdet, 2013-01-18, Gkb[edit]

Vi fortsætter arbejdet med projektet 3D/2D projektet.

Tips til programmeringsarbejdet[edit]

Eksekvering af eksterne programmer fra Object Pascal[edit]

Du kan bruge ExecuteProcess, som findes i unit'et SysUtils til at starte f.eks. POV-Ray fra dit program som du laver med Lazarus IDE. Se her.

procedure TForm1.Button1Click(Sender: TObject);
begin
  SysUtils.ExecuteProcess(UTF8ToSys('C:\Program Files\POV-Ray for Windows v3.62\bin\pvengine.exe "C:\Documents and Settings\learner\My Documents\Lazarus\starting_external_program_test_gkb_v01\3Dmodel.pov"'), '', []);
end;

Dette beskrives her http://wiki.freepascal.org/Executing_External_Programs

Export of scene image in Visual Python with or without PIL[edit]

Det virker som man ikke kan eksportere scene-billedet i Visual til f.eks. en PNG fil, uden at bruge PIL. Derfor importer PIL og brug den til at få fat i 2D billed (projektion) af din 3D model.

Som et lidt interessant alternativ så kan man tilsyneladende exportere en Visual scene til POV kode. Man kan så rendere scenen i POV-Ray og således ad en omvej få et 2D billed af ens 3D model. Se her http://www.vpython.org/FAQ.html

Samme sted beskrives også hvordan man med nogen indsats kan generere video på basis af en Visual animation.

3D modellering og rendering af 2D billed, 2013-01-08, Gkb[edit]

I sidste modul aftalte vi at temaet for næste projekt skal være 3D modellering og rendering af et 2D billed af denne model. Dette kan omsættes på forskellige måder og ved hjælp af forskellige tekniker og værktøjer, og den konkrete tilgang kan også tilpasses den enkelte elevs forudsætninger.

Det er ikke noget krav at den matematiske model skal defineres vha. GUI, men 2D billedet skal renderes som grafik og præsenteres i en GUI.

Bemærk at der ikke er noget krav om brug af en bestemt projektion, f.eks. perspektivprojektion eller isometrisk (ortografisk) projektion, ved tegning af 2D billedet af 3D modellen. Det betyder f.eks. at vi kan nøjes med at lave isometriske projektioner på xy-planet, xz-planet og/eller yz-planet.

Bemærk også at vi selvfølgelig også selv kan programmere funktionaliten som behøves til at tegne en perspektivprojektion af vores model, eller så kan vi bruge et externt program som f.eks. POV-Ray til at rendere 2D billedet, og så kan vi selvfølgelig let bruge alle de projektioner som POV-Ray's kamera kan bruge, -vistnok ti forskellige.

Her er nogle eksempler på hvordan vi evt. kan lave programmer med afsæt i temaet:

  • Uden hjælp af et eksternt rendering program. Definere en boks vha. x-, y- og z-koordinaterne for hjørnepunkterne, og så tegne streger mellem hjørnepunkterne direkte på den grafiske form. F.eks. kan 2D billedet vise en isometrisk (ortografisk) projektion af boksen på et eller flere af de primære planer i koordinatsystemet.
  • Ved hjælp af et eksternt rendering program (som f.eks. POV-Ray). Lave GUI til indtastning/definition af modellen, lagre den som en POV-fil, starte POV-Ray og så inportere det resulterende 2D billed i GUI'en.

Værktøjer som f.eks. kan bruges:

  • Python og Tkinter
  • Python og Visual
  • Python og Turtle
  • Lazarus
  • Lazarus og POV-Ray
  • NetLoog (Javabaseret implementering af programmeringssproget Logo, let at exportere som Java applet og publisere på nettet)

Man kan selvfølgelig også bruge mange andre værktøjer som f.eks. Visual Basic, Visual C#, Delphi, ...

Vedrørende kryptering med Python, installering af ezPyCrypto og PyCrypto, 2012-12-17, Gkb[edit]

I forbindelse med at lave programmer til kryptering og dekrypteringa i Python er der flere moduler som kan bruges. PyCrypto er et modul som ofte tilstrækkeligt, men der er lavet moduler, f.eks. ezPyCrypto, som gør det lidt lettere, og de bruger så ofte PyCrypto. Disse to moduler følger ikke med i standard distributionerne af Python, og på grund af begrænsninger på export af kompilerede kryptografiske programmer fra USA, så kan det være svært at finde binære versioner af f.eks. PyCrypto, og derfor de følgende to links:

Krav og test, brugbarhed (usability) og brugervenlighed, 2012-11-16, Gkb[edit]

Krav og test[edit]

Vi diskuterede iterativ udvikling af prototyper sådan lidt generelt med udgangspunkt i vores systemudviklingsmetode, og konkret med afsæt i aktiviteterne:

  • planlægning,
  • krav- og testspecifikation,
  • design,
  • implementering og
  • test.

Vi fokuserede på det forhold at når vi definerer et krav til systemet, så har vi også ansvar for at definere hvordan det senere kan afgøres om kravet er opfyldt.

Brugbarhed er ikke det samme som brugervenlighed[edit]

På baggrund af diskussion i klassen fik vi lejlighed til at se på en model for brugbarhed (usability), måske den mest udbredte model, det er i hvert fald mange kilder som gengiver den mere eller mindre i samme form. Modellen deler begrebet brugbarhed op i fem dele eller aspekter:

  • hvor let det er at lære at bruge systemet.
  • hvor effektivt systemet er (til at løse opgaven eller problemet det er designet til at løse)
  • hvor let det er at huske hvordan man bruger systemet.
  • hvor godt systemet hindrer brugeren i at lave fejl.
  • hvor tilfredsstillende det er at bruge systemet.

I mange tilfælde så vil et system som tilgodeser disse fem aspekter i rimeligt omfang også automatisk være brugervenligt i et ikke helt ubetydeligt omfang. Men det er vigtigt at gøre sig klart at et system kan både være brugervenligt uden at være brugbart og også være brugbart uden at være brugervenligt.

F.eks. kan man faktisk forestille sig et system som er meget brugervenligt, f.eks. hvor store tydelige bogstaver anvendes i den grafiske brugerflade og hvor det er let at trykke på knapperne, men hvor systemet faktisk er meget dårligt til at udføre den opgave det er lavet til at løse. F.eks. kan svartiderne være for lange i et ellers brugervenligt system til registrering af karaktere.

Modsat kan et system være ret brugerfjendtligt, f.eks. gøre brug af meget små bogstaver i det grafiske interface og have nogle meget små knapper som er næsten umulige at ramme med musen, men alligevel kunne bruges ret effektivt til at registrere karakterer.

Nogle kilder om brugbarhed[edit]

Læringsprogram: struktur for projektrapporten, resurseplanlægning, krav til dokumentation af mindre programmer, 2012-11-16, Gkb[edit]

Vi fortsatte arbejdet med udvikling af den første prototype. Nogen arbejdede med at afklare krav (vha. user stories), formulere testprocedure til dem, andre arbejdede med design og implementering af kravende i de forskellige udviklingsmiljøer og programmeringssprog som grupperne har valgt at arbejde med.

Struktur for projektrapporten[edit]

Vi satte lidt fokus på projektrapportens struktur. Jeg henviste til MediaLabs systemudviklingsmetode, http://www.rtgkom.dk/wiki/MediaLab:_Systemudviklingsmetode, som et tilstrækkeligt metodiskt grundlag for projektarbejdet. Specielt skal vi forsøge at gøre den itterative udvikling af gerne to (2) prototyper synlig i rapporten.

Se gerne også nogle af de gamle eksamensrapporter i InfB og PrgC her http://www.rtgkom.dk/prpub.php, og så henviste jeg iøvrigt til vores skabeloner for projektbeskrivelse og rapport for yderligere inspiration, se her: http://www.rtgkom.dk/wiki/Guide:Projektbeskrivelse_og_rapport

Resurseplanlægning[edit]

Med hensyn til registrering, altså synliggørelse, af planlægningsarbejdet, både mht. klassisk tidsplanlægning og så den lidt mere præcise og tekniske tilgang som jeg kalder for resurseplanlægning, så kan det være en god ide at bruge et specielt planlægningsværktøj som f.eks. programmet Planner, https://live.gnome.org/Planner. Det laver gantt-kortet automatisk når I har defineret resurser og tasks (aktiviteter) og man kan både exportere det som grafik og HTML.

Krav til dokumentation af mindre 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 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 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.

Læringsprogram, arbejdsgrupper, 2013-01-08, Gkb[edit]

Læringsprogram, arbejdsgrupper, 2012-11-06, Gkb[edit]

Tre eller fire pr gruppe.

  • Gruppe eksempel: Mads Skjøttgaard Ynddal, Michael Simonsen Christiansen og Mads Funder Poulsen
  • Gruppe nr 1: Troels Ynddal, August Møbius, Robert Radziszewski, Alexander Ibsen
  • Gruppe nr 2: Jeppe Andersen, William Brøchner, Martin Fabricius
  • Gruppe nr 3: Malte Fibiger, Rasmus Ketelsen, Nicolaj Jensen og Leon Bøgelund
  • Gruppe nr 4: Farnam Barati, Bijan, Taheri,
  • Gruppe nr 5:
  • Gruppe nr 6: Emil Lynegaard, Steffen, Immerkær,

Nyt layout for registrering af grupperne[edit]

Læringsprogram, 2012-11-06, Gkb[edit]

  • I projektet udarbejdes et læringsprogram til brug i et af undervisningsfagene på HTX. Programmet skal automatisere en fremgangsmåde som ellers kan være tidskrævende.
  • Programmet og arbejdet med projektet planlægges, gennemføres og dokumenteres i en rapport som afleveres på elevernes StudieWebs. Produktet og alle prototyper afleveres også der.
  • RTG-MediaLabs systemudviklingsmetode skal bruges i projektet.
  • Gruppearbejde, tre eller evt. fire elever i hver gruppe.
  • Vi skal prøve at anvende nogle af reglerne (rules) fra Extreme Programmering i arbejdet, se her http://www.extremeprogramming.org/rules.html
  • I kan selv vælge hvilket udviklingsmiljø I vil anvende. Det skal bare være lovligt og uden omkostninge.
  • Prøv at passe på ikke at slå et stort brød op. Definer problemet tydeligt, og skriv nogle brugerhistorier (user stories) straks.
  • Et nærmere oplæg kommer snart her: asdf

GUI's med IDE's, en øvelse, og intro til UML, 2012-10-12, Gkb[edit]

I denne øvelse skal vi teste nogle forskellige integrerede udviklingssystemer. (Integrated Development Environment, IDE). Vi gør det ved at lave et Hello World program med grafisk brugerflade (Graphical User Interface, GUI) med to forskellige IDE's . Du kan selv vælge hvilke IDE's du vil afprøve, men her er nogle forslag:

  • Lazarus IDE, et cross platform udviklingsmiljø for programmering med Object Pascal. Lazarus IDE er en klon af det nu snart i årtier populære udviklingsmiljø Delphi som oprindelig blev lavet af firmaet Borland og nu lever videre hos firmaet Embarcadero.
  • Gambas, ligner lidt Visual Basic, findes vistnok kun til Linux systemer. NB at Gambas er installeret under Ubuntu på vores maskiner i MediaLab.
  • Visual Python IDE & Visual Tkinter, et lille og ustabilt, men interessant system til at bygge brugerflader vha. Tkinter og Python. Let at installere for Windows, sværere (umuligt?) for Linux/Mac.
  • Netbeans, et meget udbredt og populært IDE til programmering i Java, oprindelig fra Sun Microsystems som jo lavede Java i sin tid, nu købt af Oracle.
  • Eric Python IDE, et tilsyneladende for os meget interessant crossplatform udvikligsmiljø til programmering i Python vha. QT API'en. Skal gerne afprøves. Svært at installere på Windows og Mac, men let vha. apt-get på Ubuntu. Brug gerne vores maskiner i MediaLab, spild ikke pt. tid på at forsøge installation på Windows og Mac. Man skal selv kompilere og konfigurere nogle eller evt. flere af delsystemerne som behøves.
  • QT Creator, før QT Designer. Dette er et professionelt dual licensing cross platform udviklingsmiljø til programmering i C++, oprindelig lavet af firmaet Trolltech i Norge, nu købt af Nokia.
  • Delphi
  • Visual Basic
  • Visual C#
  • Visual C++
  • ...tilføj selv IDE's...

Hvorfor Hello World!?[edit]

Formålet med at lave et Hello World program er dobbelt:

  • Demonstrere at man kan installere og konfigurere systemet således at det kan bruges til udviklingsarbejde.
  • Demonstrere at man kan skrive et program i det pågældende programmeringssprog som kan kompileres eller fortolkes (opfylder de syntaxkrav som stilles af compileren eller interpreteren) samt at programmet kan startes og eksekveres (afvikles) uden runtime-fejl.

Vi har så vores eget specielle formål med denne øvelse, nemlig at teste og forstå hvad et IDE er.

Krav til programmerne[edit]

Programmerne skal som minimum opfylde følgende krav:

  • Teksten Hello World! skal ses som en tydelig overskrift i brugerfladen.
  • Der ska være et inputfelt og en kommandoknap og en label.
  • Når man trykker på knappen, så skal indholdet i inputfeltet flyttes over i labelen.

Arbejdsform, dokumentering og aflevering[edit]

Induviduelt arbejde! Upload et skærmbilled eller to til dit StudieWeb for hvert IDE, samt et kort referat (minimum ca. 100 ord) af hvordan du lavede dine Hello World programmer. Det kan være en god ide at skrive om hvad var let, interessant eller svært. Brug fagsprogets begreber i dit referat. Du kan for eksempel beskrive hvordan du lavede eventhandleren for klik på knappen.

Om webdesignet[edit]

  • Lav en mappe med navnet programmering_c.
  • Lav en mappe med navnet gui_s_med_ide_s.
  • Lav din HTML præsentation i filen gui_s_med_ide_s.html (index.html er egentlig en god ide, men risikoen er ikke ubetydelig at du/vi så vil overskrive vores primære index.html som jo som bekendt definerer selveste hjemmesiden for vores StudieWeb, -så derfor!)
  • Pas på med ikke at indlægge et screendump i fuld tyngde (filstørrelse) ind i din HTML. Reducer størrelsen i pixels og evt. også komprimer de billeder som loades i begyndelsen, og lav så gerne en link til det ukomprimerede billed i fuld størrelse. Det kan brugeren så bestemme at klikke på og vente på, hvis han eller hun virkelig er interesseret i detaljerne. Gør evt. selve det lille billed til en hyperlink til det store billed.
  • Tilføj en link til programmering_c.html fra menuen på jeres homepage, dvs. fra index.html eller index.php. I programmering_c.html laver du så en link til gui_s_med_ide_s.html og de andre øvelser og projekter i faget Programmering C.

Ekstra[edit]

Hvis du har mere tid, så kan du fundere over følgende spørgsmål:

  • Var der nogen problemer med variabler eller datatyper?
  • Hvordan kunne programmerne evt. udbygges til at addere to tal som indtastes i to inputfelter?

Du kan eksperimenter og skrive om dine erfaringer.

Upload til til StudieWeb, syntaxtest for HTML, 2012-10-04, Gkb[edit]

  • Lav en webside på StudieWebbet for Programmering C. Planlæg som minimum præsentation af indholdselementerne Øvelser, Projekter og Teori. Husk at din HTML og evt. CSS skal opfylde World Wide Web konsortiets syntaxkrav, test din webside her http://validator.w3.org.
  • Præsenter arbejdet med øvelsen "Løsning af en andengradsligning" på StudieWeb.
    • Skriv en kort resume af aktiviteten.
    • Upload rutediagrammet for algoritmen for løsning af andengradsligninger. Den håndtegnede skitse skal scannes til en PNG fil med max. 200 dpi. Hvis billedet fylder for meget i dit layout, så lav en anden fil med et mindre antal pixels (resize/resample eller noget lignende i f.eks. Gimp eller Irfanview), f.eks. 640 pixels vandret. Husk at bevare proportionerne i billedet. Lav så en link fra dette billed til det store, så kan folk selv vælge om de klikker på det lille billed for at se et billed med flere detaljer. Du må også gerne rentegne rutediagrammet med et program som Dia, -og uploade det resulterende flowchart også.
    • Upload Python implementeringen af algoritmen. Hvis du vil, så kan ud også implementere algoritmen i andre prgogrammeingssprog og lægge det eller de (hvis du gør det i flere sprog) resulterende programmer også op på dit SW. Brug
      asdf
      til at fortælle browseren at mellemrum, tabs og linjeskift i koden skal respekteres.

Intro til UML[edit]

Vi skal nu begynde at forberedes os på at bruge UML lidt. UML står for Unified Modeling Language og har nu næsten helt erstattet flowcharting. Se specifikationen for UML her http://www.omg.org/spec/UML/.

Se også http://www.uml.org/ og http://en.wikipedia.org/wiki/Unified_Modeling_Language.

Afprøv programmet ArguUML som kommer fra http://tigris.org

Fokus på XXX, og fortsat arbejde med implementeringen af algoritmen til løsning af andengradsligninger, 2012-10-02, Gkb[edit]

Fokus på XXX[edit]

Fortsat arb. med implementering i Python af algoritmen til løsning af andengradsligninger[edit]

Fokus på begrebet scope, og øvelse i flowcharting, 2012-09-28, Gkb[edit]

Scope[edit]

Begrebet scope, samt begreberne lokal variabel og global variabel blev forklaret med udgangspunkt i et kode-eksempel på tavlen.

Flowchart for algoritmen til bestemmelse af rødderne for en andengradsliging[edit]

Vi tegnede et udkast hver for sig, og så tegnede to elever sine flowcharts på tavlen. Efter kort diskussion gik klassen så i gang med individuel implementering af algoritmen i Python. Vi blev ikke helt færdige, men den første prototype blev nok klar hos de flæste. I første prototype kan vi godt tillade os ikke at teste input til programmet, -det kan forenkle koden en del, så overblikket bevares.

Ved afslutningen af modulet så vi kort, meget kort, på projektoren hvordan sådan et program kan vha. modulet Tkinter få en grafisk brugerflade. Vi fortsætter arbejdet næste gang.

Fokus på begreberne algoritme og flowchart, og fortsat individuelt arbejde med lærebogen, 2012-09-20, Gkb[edit]

Algoritme[edit]

En måde at definere begrebet algoritme kan være at en algoritme er en entydig beskrivelse af en fremgangsmåde til at løse en opgave med et veldefineeret kriterium for hvornår opgaven er løst. Se nærmere her algoritme site:dk, specielt http://www.denstoredanske.dk/It%2c_teknik_og_naturvidenskab/Informatik/Software%2c_programmering%2c_internet_og_webkommunikation/algoritme. Se også algorithm, specielt http://en.wikipedia.org/wiki/Algorithm.

Se også her nogle velvoksne samlinger af algoritmer (og programmer) til forskellige matematiske og datalogiske problemer:

Flowchart, rutediagram[edit]

Ideen at en algoritme kan beskrives med en tegning vha. nogle få symboler, blev præsenteret kort med udgangspunkt i problemet at løse en 2. gradsligning. Symboler for Start, Stop, Input og Output, Betinget flow of execution og operation på data blev præsenteret.

Blender med Python og kapitel 3 i lærebogen, 2012-09-18, Gkb[edit]

Blender med Python[edit]

Vi afsluttede vores eksperimenter i Blender. Alle skulle teste det første script i artiklen http://wiki.blender.org/index.php/Dev:2.5/Py/Scripts/Cookbook/Code_snippets/Materials_and_textures, men nogle nøjedes ikke med det og testede også det andet, tredje og evt. også det fjerde script. Det viste sig at der er lavet om på API'en i Blender 2.63, således at det tredje eksempel ikke kører unden ændringe (faces er ikke længere en egenskab for en mesh sphere...).

Kapitel 3 i lærebogen[edit]

Vi fortsatte individuelt læsning og afprøvning af eksemplerne i teksten, samt arbejdet med øvelserne. Brug ordlisten sidst i kapitlerne til at teste om I har forstået begreberne.

[edit]

Vi diskuterede undervejs modulet GASP, som bruges i lærebogen til at lave lidt grafik, og i den sammenhæng blev programmeringssproget Logo, lavet af en gruppe under ledelse af Seymour Papert, og turtle graphics forklaret lidt. Modulet turtle følger med i Python distributionerne og man kunne evt. have brugt det til at introducere grafik.

Blender med Python, 2012-09-10, Gkb[edit]

Vi fortsatte vores afprøvning af Python i Blender med støtte i følgende tre artikler.Vi sluttede med at afprøve det første script fra den sidste link nedenfor og køre det fra tekst editoren i Blender.

Python i Blender, en test af API'en i Blender 2.63, 2012-09-06, Gkb[edit]

Vi brugte dette modul til i fælleskab, vha. projektoren og vejledningen på http://wiki.blender.org/index.php/Doc:2.6/Manual/Extensions/Python/Console, at afprøve elementær anvendelse af API'en i Blender. Alle kom godt i gang med denne lille tutorial, og nogle blev helt færdige og fik altså lavet de fem bokse med følgende for-løkke.

<source lang="python"> >>> for index in range(0, 5):

...     add_cube(location=(index*3, 0, 0), layers=mylayers)

</source>

Gør denne øvelse færdig til næste gang, og brug afsnittet The Text Editor i Python 2.6 manualen, http://wiki.blender.org/index.php/Doc:2.6/Manual/Extensions/Python/Text_editor, til at lære at bruge editoren i Blender til at lave Python scripts.

Afrunding ved heltalsdivision og typekonvertering med float(), 2012-09-04, Gkb[edit]

I plemummødet (ca. 10 min) i begyndelsen af modulet satte vi fokus på afrunding ved division med hele tal, altså integers.

Begreberne operand, operator, expression, evaluation og value blev defineret på tavlen og brugt i diskussionen. Vi diskuterede følgende eksempler på tavlen:

  • 3 / 2 som evalueres til 1
  • 3.0 / 2 som evalueres til 1.5
  • 3. / 2 som evalueres til 1.5

Og vi så følgende eksempler fra Python shell'en i vores wiki, på projektoren:

>>> 3/1
3
>>> 3/2
1
>>> 3/2.
1.5
>>> 8
8
>>> float(8)
8.0
>>> float(3)/2
1.5

Derefter var det individuelt arbejde med afsnit 3, om funktioner, i lærebogen. Se gerne http://www.openbookproject.net/thinkcs/python/english2e/ch03.html.

Python og Blender = 3D grafik!?[edit]

Vi begynder næste gang med en lille øvelse i at programmere (styre) Blender med Python. Forvent ikke for meget, det er en del som skal læres før vi kan lave smarte animationer i Blender med Python.

Formålet med denne øvelse er at se konkret på et eksempel hvor Python anvendes i en "seriøs sammenhæng". Skim følgende artikler inden vi mødes næste gang:

Bemærk at der er mange gode tilbud om vejledning på nettet, men vi prøver først at bruge den mest autentiske, nemlig den som findes på http://blender.org.

Detaljeret gennemgang af kapitel 1, 2012-08-21, Gkb[edit]

Vi begyndte fælles læsning og diskussion af teksten i kapitel 1 på projektoren. På grund af de mange sidespring nåede vi kun til og med sektion "1.2. What is a program?", men vi diskuterede også mange vigtige aspekter, personer og begreber. Blandt andet følgende:

  • At man bliver bedre til at løse problemer i almindelighed når man lærer at programmere.
  • Forskellen på højnivau- og lavnivau- programmeringssprog.
  • Portabilitet
  • Interpreter versus compiler, både mht. eksekveringshastighed og portabilitet.
  • Kildekode (source code) og objektkode (object code)
  • Byte code og virtuelle maskiner
  • Prompt, shell, terminal, commandoprompt
  • Path, relative og absolute veje til programmer som vi vil eksekvere, f.eks. C:\Python27\python.exe eller hvis vi er i mappen C:\mine_python_programmer\test01 og vi vil eksekvere programmet/scriptet test.py, så kan vi skrive ..\..\Python27\python test.py for at starte Python interpreteren.
  • PATH variablen i DOS/Windows kommandoprompten/shellen. Både hvordan man kan se hvilke veje (paths) den indeholder allerede ved at skrive PATH på kommandoprompten, og hvordan man kan tilføje en ny vej (path) til den med kommandoen SET PATH=%PATH%;C:\Python27. Bemærk bare at denne ændring kun gælder for den pågældende kommandopromt/shell.
  • HELP SET, tolkning af syntaxbeskrivelsen for anvendelse af kommandoen SET.
  • Interne og eksterne kommandoer i DOS/Windows.
  • .exe, .com og .bat, de tre mest almindelige filendelser i Windows for filer som kan eksekveres.
  • DOS kommandoerne, specielt HELP som kan bruges til at få info om de andre kommandoer.
  • Linux/Unix shell commands, en søgning i Google på denne streng fører til flere gode oversigter over shell-kommandoer i Linux, se f.eks. her en dansk vejledning i shell scripting, http://www.linuxbog.dk/unix/unix/shell-script.html. Og her, http://fosswire.com/post/2007/08/unixlinux-command-cheat-sheet/, kan vi få en plakat med de vigtiste kommandoer.
  • Store eller små bogstaver? I Windows er det oftest uden betydning om vi skrive store eller små bogstaver i DOS kommandoer, men i Linux/Unix og MacOS må vi skrive korrekt små og store bogstaver sådan som filerne, kommandoerne og vores programmer faktisk hedder.
  • Tre måder at eksekvere Python kode:
    • Direkte i shell mode, altså på interpreterens prompt
    • I script mode, altså skrive programmet i en editor, gemme det f.eks. med navnet test.py i roden på C:, og eksekvere med "\Python27\python \test.py".
    • Ved hjælp af -c optionen for Python interpreteren, f.eks. sådan python -c "print 1 + 1"
  • at de fleste Linux/Unix/MacOS programmer skriver en kort hjælpetekst hvis man tilføjer --help, når man starter programmerne. F.eks. python --help
  • GCC, GNU Compiler Collection, som var blandt de første programmer/systemer som blev udviklet til GNU projektet.
  • Lincenser generelt, altså at de groft kan deles op i licenser som sikrer brugernes rettigheder og i licenser som sikrer producenternes rettigheder. GPL licensen blev diskuteret lidt, og specielt det aspekt at vi skal frigive vores ændringer, hvis vil nu laver ændringer på GPL produkter som vi bruger.
  • GNU/Linux, og det forhold at GNU projektet har leveret mange af de programmer som er nødvendige for at Linux distributioner som Debian og Ubuntu kan fungere. Og at det således ville være mere rigtigt at bruge betegnelsen GNU/Linux end bare Linux når vi taler om disse operativsystemer.
  • Richard Stallmann, som startede GNU projektet, vistnok i 1983. Det gik, og går fortsat ud på at lave et Unix lignende operativsystem som er frit at bruge, -men ikke nødvendigvis gratis. Selve kærnen i GNU kaldes Hurd, og udviklingen af den går noget langsamt.
  • Linus Thorvalds, som ca. ti år senere lavede operativsystemkærnen Linux, og da kærnen for GNU ikke var klar, så passede det fint at bruge Linux sammen med GNU projektets mange programmer, ikke mindst GCC.
  • Guide van Rossum, som har lavet Python.
  • print 1 + 1, vi eksekverede denne print-sætning (statement) i python shell'en og fra et script.
  • 2**2, 2**4, 2**5, 2**8, 2**10; 2**16 og 123**456 Vi legede lidt med exponent operatoren ** og så at Python kan levere svar med rigtig mange cifre.
  • Hvad er et program egentlig? Jo, nyttige programmer tager noget data som input, udfører nogen operationer på disse data, ofte matematiske operationer, de afgører om noget er større eller mindre end noget andet, de gentager nogle operationer meget hurtigt og så til slut leverer de noget data som output. Og hvis alt gik godt, så giver dette output mening for os. (Dette er egentlig en omskrivning af afsnit 1.2 i bogen.)

Og så nåede vi altså ikke mere. Vi fortsætter næste gang. Du kan få mere ud af diskussionen hvis du forbereder dig:

  • Læs kapitel 1. og 2.
  • Lav alle eksemplerne som er i teksten. (NB brug en programeditor som f.eks. Notepad++ eller jEdit til at lave de små scripts som du evt. skal lave i disse to kapitler, -vi venter lidt med at begynde at bruge IDLE!)
  • Lav øvelserne i slutningen af kapitlerne.
  • Studer alle begreberne i ordlisterne i begge afsnit. Du skal forstå dem alle!

Velkommen til Programmering C, 2012-08-17, Gkb[edit]

Velkommen til faget Programmering C. I grove træk skete følgende i holdets første modul:

  • Diskussion i plenum om faget.
  • Demonstration af rendering med POV-Ray.
  • Installering af Python og arbejde med lærebogens første kapitel

Diskussion i plenum om faget[edit]

Diskussion i plenum om faget, værktøjer (tools) og lærebogen. Vores primære værktøjer i faget bliver:

  • Programmeringssproget Python (version 2.7.3 fra http://python.org)som Guido van Rossum har lavet og det
  • integrerede udviklingsmiljø IDLE som følger med den officielle version af Python, samt
  • online-lærebogen "How to Think Like a Computer Scientist, Learning with Python" af Jeffrey Elkner, Allen B. Downey, and Chris Meyers (http://www.openbookproject.net/thinkcs/python/english2e/)

Vi vil også bruge andre værktøjer, og der vil være mulighed for individuelle valg af værktøjer i nogle opgaver og projektforløb. Som et eksempel på et værktøj af en lidt anden type end Python blev POV-Ray, http://www.povray.org/, demonstreret på projektoren.

Demonstration af rendering med POV-Ray[edit]

Vi så på projektoren (altså på væggen) hvordan en 3D matematisk model (scene) med en boks og en kegle kan bygges op i POV-Ray og hvordan programmet kan bruges til at rendere (fremstille, lave) et 2D billed af denne 3D model. (Programmet blev udviklet i går, med holdet PrgC34).

#version 3.6;

camera {
  location  <5,5,5>
  look_at   <0,0,0>
}

light_source {
  <20,20,20>       // light's position
  color rgb <1, 1, 1>  // light's color
}            

box {
  <0,0,0>, <1,3,2>  
  pigment {color <1,1,0> } 
}                            
                             
cone{
  <0,0,0>, 2, <0,5,0>, 0    
  pigment {color <1,1,1> } 
}                             

Installering af Python og arbejde med lærebogens første kapitel[edit]

Vi installerede Python 2.7.3 fra http://www.python.org/ og begyndte at læse lærebogen og lave de små øvelser som beskrives i teksten i kapitel 1.

I den sammenhæng viste det sig at vi har behov for at kunne anvende nogle DOS kommandoer på/i den såkaldte kommandoprompt (shell) i Windows, for at kunne starte Python:

  • cd \
  • dir
  • cd Python27
  • dir

Og så kunne vi starte Python.

For at gøre det muligt for Windows at finde python.exe, når vi ikke er i C:\Python27, kan vi tilføje vejen til programmet til systemets (Windows) PATH variabel. Husk at lukke shell'en (kommandoprompten) og starte den igen, ellers har denne ændring ingen effekt.

Det viste sig også at det kan give problemer at lade Google oversætte lærebogens websider til dansk. Læs helst bogen på engelsk! Hvis I bruger automatisk oversættelse, så ændres ofte første bogstav i kommandoerne i Python programmer til et stort bogstav, og det fører typisk til en syntax fejl (syntax error), som så kan blive lidt svær at forstå og rette.