FunnyScreens. Saxion. Matthijs Langenberg (89870) Niels Hendriks (89713) Siet Toorman (91623) Job Vermeulen (90589) Wiebe van Schie (84313)

Saxion

FunnyScreens

Auteurs: Begeleiders: Matthijs Langenberg (89870) Jan Stroet Niels Hendriks (89713) Ronald Tangelder Siet Toorman (91623) Job Vermeulen (90589) Wiebe van Schie (84313)

Enschede, 27 juni 2008 Alle rechten voorbehouden aan Saxion te Enschede, opleiding Technische Informatica

Inhoudsopgave 1 Inleiding

1

2 Probleemanalyse 2.1 Opdrachtomschrijving . . . . . 2.2 Schermenwand . . . . . . . . . 2.3 Autonoom systeem . . . . . . . 2.4 Interactie . . . . . . . . . . . . 2.4.1 Interactie onderling . . 2.4.2 Interactie met omgeving 2.5 Requirements . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

2 2 2 3 3 3 3 3

3 Systeembeschrijving 3.1 Hulpmiddelen en methoden . . . 3.1.1 Scrum - XP . . . . . . . . 3.1.2 Werkplekken . . . . . . . 3.1.3 Java . . . . . . . . . . . . 3.1.4 Eclipse . . . . . . . . . . . 3.1.5 Continuous build server . 3.1.6 Google Subversion hosting 3.1.7 Google Groups . . . . . . 3.1.8 Google Calander . . . . . 3.1.9 Google Documents . . . . 3.2 Kwaliteitsbewaking . . . . . . . . 3.3 Testprocedures . . . . . . . . . . 3.4 Oplevering . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

5 5 5 7 7 7 7 8 9 9 9 9 10 11

4 Resultaat 4.1 Development . . . . . . . . . . 4.1.1 Continuous build script 4.2 Node . . . . . . . . . . . . . . . 4.2.1 Besturingssysteem . . . 4.2.2 Opstart script . . . . . . 4.3 Applicatie . . . . . . . . . . . . 4.3.1 Netwerklaag . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

12 12 12 13 13 14 14 14

I

. . . . . . .

EII6RTb - FunnyScreens

4.3.2 4.3.3 4.3.4

Inhoudsopgave

Tonen video’s . . . . . . . . . . . . . . . . . . . . . . . . . Network-event generator . . . . . . . . . . . . . . . . . . . J/Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17 19 20

5 Conclusie en aanbevelingen 21 5.1 Resultaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2 Aanbevelingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6 Reflectie 6.1 Reflectie . . . . 6.1.1 Reflectie 6.1.2 Reflectie 6.1.3 Reflectie 6.1.4 Reflectie 6.1.5 Reflectie 6.1.6 Reflectie

. . . . . . . . . . . . . Groep . . . . . . . . . Matthijs Langenberg . Niels Hendriks . . . . Wiebe van Schie . . . Siet Toorman . . . . . Job Vermeulen . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

23 23 23 25 27 31 32 34

A Class Diagram

40

B Werkplek inrichting

41

C Opstartscript node

42

D POP Matthijs Langenberg

43

II

Hoofdstuk 1

Inleiding Voor de specialisatie Realtime Embedded Systems hebben we de opdracht gekregen om een interactieve schermenwand te maken. In dit verslag wordt eerst uitgelegd wat de opdracht inhoud waarna aandacht wordt besteed aan de manier waarop we werken. Hierna wordt het resultaat besproken. Hierbij zullen de verschillende onderdelen besproken worden met de tegengekomen problemen en gemaakte keuzes. Uiteindelijk volgt er een conlusie waarin het totale eindresultaat wordt besproken en aanbevelingen worden gedaan.

1

Hoofdstuk 2

Probleemanalyse 2.1

Opdrachtomschrijving

Voor een locatie binnen de school wordt gezocht naar een interactieve schermenwand. Op deze schermenwand zijn verschillende gezichten te zien. Het is een autonoom werkend systeem en als er een gebeurtenis plaats vindt in de omgeving, zal de wand daarop reageren. Dit concept is niet helemaal nieuw, de Amerikaanse universiteit MIT heeft een soort gelijk project genaamd Spotlight[1] gemaakt. Zie fiFiguur 2.1: Project spotlight guur 2.1 voor een afbeelding van een werkende opstelling van dit project. Het MIT heeft geen informatie verstrekt over de opzet. We zullen zelf moet uitzoeken hoe we toch het zelfde resultaat komen.

2.2

Schermenwand

De schermenwand bestaat uit meerdere beeldschermen die elk worden aangestuurd door een eigen mini-pc. De grootte van de wand is dynamisch. Een schermenwand kan uit 4 schermen bestaan, maar bijvoorbeeld ook uit 9 schermen. Hiernaast is ook de opstelling dynamisch. De verschillende schermen kunnen als een vierkant neer gezet worden maar er kan ook gekozen worden voor een piramide structuur.

2


2.3

Hoofdstuk 2. Probleemanalyse

Autonoom systeem

Het systeem is een autonoom systeem wat inhoudt dat het systeem niet afhankelijk is van een ander systeem. De wand, bestaande uit verschillende nodes[2], werkt op zichzelf en worden niet centraal aangestuurd door een server. Mocht de server om een of andere reden uitvallen, dan zal dit geen effect hebben op de schermenwand. De nodes zijn ook niet afhankelijk van andere nodes. Op elk moment kan er een node uit de configuratie gehaald worden of juist worden toegevoegd. Hierdoor zal de uitval van een node geen effect hebben op de rest van de nodes.

2.4

Interactie

Interactie houdt in dat er een actie plaats vindt waar op gereageerd wordt. Dit is ook een van de onderdelen van deze schermenwand. In dit geval kunnen we de interactie in 2 delen opsplitsen. Ten eerste interactie tussen de schermen, waarbij de schermen met elkaar communiceren. Ten tweede is er dan nog de interactie van de schermen met de omgeving, waarbij de schermen reageren op een gebeurtenis.

2.4.1

Interactie onderling

Als de schermen geen gebeurtenissen waarnemen in de omgeving willen we toch dat er iets te zien is op de schermen. In zo’n geval gaan de schermen onderling acties uitvoeren. Op een willekeurig tijdstip kunnen de schermen elkaar bijvoorbeeld aankijken. Hierbij kijkt het linker scherm naar rechts een het rechter scherm kijkt terug. Dit kan horizontaal, verticaal maar ook diagonaal. Hiernaast zijn er ook nog andere dingen te bedenken als bijvoorbeeld een ’wave’(allemaal om de beurt de handen opsteken).

2.4.2

Interactie met omgeving

Om de schermen interessant te maken voor publiek is het leuk als de omgeving invloed kan uitoefenen op het geen wat de schermen doen. In dit geval spreken we van interactie met de omgeving. Er zijn vele omgevingsfactoren die te detecteren zijn. Als er bijvoorbeeld iemand voor de schermen langs loopt kan deze beweging gedetecteerd worden. Hierop zouden de schermen kunnen reageren door die persoon te laten schrikken. De verschillende omgevingsfactoren waar aan gedacht kan worden zijn bijvoorbeeld: licht, geluid, temperatuur en beweging.

2.5

Requirements

Omdat we volgens scrum werken is er van te voren geen gedetailleerde requirements lijst op te stellen. Er zijn wel een aantal hoofd-requirements op te stellen 3


Hoofdstuk 2. Probleemanalyse

waaraan de schermenwand uiteindelijk moet voldoen. • Wand bestaande uit meerdere autonome nodes • Nodes tonen gezichten of een afbeelding • De nodes hebben interactie met elkaar • De nodes reageren op een gebeurtenis in de omgeving

Figuur 2.2: Illustratie uit het blokboek ter verduidelijking van de projectomschrijving.

4

Hoofdstuk 3

Systeembeschrijving 3.1 3.1.1

Hulpmiddelen en methoden Scrum - XP

Het belangrijkste aspect van dit project is de gekozen projectmanagementen softwareontwikkelmethode. Voor de projectmanagementmethode is gekozen voor Scrum. De keuze voor de softwareontwikkelmethode is gevallen op XP. In de hieronder volgende subsecties zullen beide methoden nader toegelicht worden.

Figuur 3.1: Proces verloop van Scrum

Scrum Het project is uitgevoerd volgens de projectmanagementmethode Scrum. Scrum is een methode voor Agile[3] software ontwikkeling. In het kort komt Scrum er

5


Hoofdstuk 3. Systeembeschrijving

op neer dat er een Scrum-Master is, een Owner (de klant) en een team van ontwikkelaars. Elke ochtend wordt er tijdens de daily standup meeting[5] met de andere project leden besproken wat er die dag zal gaan gebeuren. Ook wordt er besproken welke problemen er zijn. Met scrum wordt de beschikbare tijd onderverdeeld in zogenaamde Sprints. Per Sprint wordt er een nieuwe versie van het product opgeleverd. De (nieuwe) onderdelen die per sprint worden ge¨ımplementeerd, genaamd story’s, staan in de sprintbacklog beschreven. De sprintbacklog bij ons project bestaat uit een Google Documents 1 spreadsheet. In deze spreadsheet is er een tabblad genaamd ’Sprint Backlog’. Aan het einde van elke sprint worden de story’s opgeslagen in een Sprint History tabblad. Naast de sprintbacklog wordt er bij scrum gebruik gemaakt van een scrumboard. Op dit scrumboard worden de story’s geplakt die tijdens de sprint uitgewerkt gaan worden. De betreffende story’s kunnen eventueel weer onderverdeeld worden in kleinere taken om het overzichtelijk te houden. Het scrumboard is onderverdeeld in 4 kolommen namelijk: • Story • To Do • In Progress • Done! Aan een story wordt vervolgens een gewicht gehangen, ook wel storypoints genoemd. Story-points geven een indicatie hoeveel tijd er in een taak gaat zitten. De story-points van alle story’s worden bij elkaar opgeteld en in een grafiek in kaart gebracht. Deze grafiek, de burndownchart, dient aan het eind van elke dag bijgewerkt te worden. De burndownchart toont op een overzichtelijke ma- Figuur 3.2: Voorbeeldindeling van een nier de voortgang van de sprint. Aan Scrumboard het einde van de sprint wordt de burndownchart verwerkt in een tabblad in de spreadsheet. XP Vrijwel elk stukje software van het project is ontwikkeld volgens de softwareontwikkelmethode XP. De afkorting XP staat voor eXtreme Programming. In het kort houdt dat in dat elke regel code in pairs2 geprogrammeerd dient te worden. 1 Voor 2 In

verder uitleg over Google Documents zie 3.1.9 Google Documents. tweetallen

6



Verder stelt XP dat het ontwerp simpel dient te zijn en alles zo simpel mogelijk gehouden moeten worden (KISS; Keep It Simple Stupid!). Door het toepassen van unittesting[10] wordt er voor gezorgd dat er eerst nagedacht wordt over het stukje functionaliteit voor dat het geprogrammeerd wordt. Bij unittesting wordt eerst een test geschreven die aan het begin zou moeten falen, wanneer de functionaliteit is ge¨ımplementeerd is zou de test moeten slagen. Aan het begin van het project is er een server ingericht die deze testen zou uitvoeren. Wij zijn er al snel achter gekomen dat het gigantisch veel tijd en kennis kost om de omschakeling te maken naar unittesting. Hierdoor is er voor gekozen het unittesten te laten voor wat het is. Wel is er gedurende het project geprogrammeerd in pairs.

3.1.2

Werkplekken

Door school is er een projectruimte beschikbaar gesteld waar meerdere groepen zitten. Iedere groep heeft daar zijn eigen werkplek met pc’s. Per werkplek zijn er 4 pc’s beschikbaar die naar eigen behoefte ge¨ınstalleerd en geconfigureerd kunnen worden. Binnen de groep is er voor gekozen om geen gebruik te maken van deze pc’s daar ieder groepslid beschikt over een eigen laptop. Door te werken op deze laptop is elk groepslid mobieler en in staat om thuis eventueel ook nog wat werk te verrichten zoals bijvoorbeeld documentatie. Door geen gebruik te maken van de beschikbare pc’s kan er een ruimte gecreëerd worden voor het opstellen van de nodes.

3.1.3

Java

De keuze voor de programmeertaal is gevallen op Java. Dit omdat Java platform onafhankelijk is en dus goed samen gaat met de agile softwareontwikkelmethode die gebruikt is binnen het project. Daarnaast heeft ieder groepslid zeer veel ervaring met het programmeren in Java door de ”Programmeren in Java”modules uit het eerste jaar. Er wordt gebruik gemaakt van Java versie 6.

3.1.4

Eclipse

Als IDE omgeving is er gekozen voor Eclipse. Eclipse is een freeware IDE voor het ontwikkelen van onder andere Java applicaties. Voor Eclipse zijn diverse plugins beschikbaar waaronder subclipse, een plugin voor het gebruik van een svn binnen Eclipse. Eclipse ondersteund standaard het gebruik van JUnit, een unittesting-framework. JUnit dient als Library ge¨ınstalleerd te worden. Een uitgebreide handleiding is beschikbaar op de documentatie-cd.

3.1.5

Continuous build server

In de serverruimte van het CII-hardwarelab is er door de groep een server gereserveerd. Op deze server draait Debian als Operating System. Aan het begin

7



van het project is er een script geschreven dat elke 5 minuten de SVN uitcheckt en compiled. Indien er tijdens het compileren error’s optreden, worden deze weggeschreven naar een log bestand. Vervolgens voert de server alle unittests uit. De uitkomst van de unittest worden naar het zelfde logbestand geschreven. Indien er tijdens het compileren van de code of het uitvoeren van de tests een fout optreedt wordt er een e-mail naar de groepsleden gestuurd. In deze e-mail staat de inhoud van het logbestand.

Figuur 3.3: Error notificatie E-mail

3.1.6

Google Subversion hosting

Het versiebeheersysteem van de groep wordt gehost door Google Subversion hosting. Deze service wordt gratis aangeboden door Google en heeft een opslagruimte van 100 MB per project. Voorwaarde die Google stelt aan het gebruik ervan is dat de code voor iedereen beschikbaar is. Een willekeurig persoon kan een checkout doen van onze svn-repository. Echter is dit voor de groep geen bezwaar. Om het project over te dragen aan andere groepen zal aan het eind van het project dhr. Tangelder worden toegevoegd als beheerder van de SVN. 8



Door het toevoegen van deze beheerder is de begeleider zelf in staat om leden van een andere projectgroep, die dus verder gaan met dit project, toegang te geven tot de SVN en dus ook alle sourcecode en de wiki.

3.1.7

Google Groups

Voor het opzetten van een centrale informatievoorziening en een mailinglist wordt er gebruik gemaakt van een Google Group. Door het aanmaken van een Google Group is er een algemeen e-mailadres beschikbaar. Alle e-mails die naar dit e-mail adres verstuurd worden, zullen automatisch doorgestuurd worden naar alle leden. Google Groups ondersteund tevens het opslaan van bestanden, iets waarvan wij als groep geen gebruik maken. Het valt allicht op dat wij als groep van veel Google services gebruik maken. Hier is voor gekozen omdat elk groepslid beschikt over een Gmail account. Verder zijn de ervaringen met de services van Google binnen de groep erg positief.

3.1.8

Google Calander

Om het beheren van alle gemaakte afspraken, colleges etc. etc. voor de groep overzichtelijk en centraal bij te houden is er door de groep een agenda aangemaakt bij Google. In deze agenda worden de gemaakte afspraken voor het DSO\QSO uur, lezingen voor het RTES thema en Capti Selecta bijgehouden. Elk groepslid heeft zich geabonneerd op deze agenda. Wanneer er een afspraak wordt toegevoegd, verwijderd of gewijzigd veranderd dit automatisch bij iedereen.

3.1.9

Google Documents

Door de begeleiders is gesteld dat zij graag een digitale versie van het productbacklog en sprinthistory’s in willen kunnen zien. Als oplossing hiervoor wordt er gebruik gemaakt van Google Documents. Google Documents stelt ons in staat documenten op te stellen en te publiceren op het web. Daarnaast is er ook de mogelijkheid mensen toegang te geven tot het document in read-only vorm. Wanneer het document gewijzigd wordt, zullen deze wijzigingen direct gepubliceerd worden en dus zichtbaar zijn voor de begeleiders. Een ander bijkomend voordeel dat geleid heeft tot het gebruik van Google Documents is de mogelijkheid om met meerder personen een document te bewerken. Voor het gezamenlijk opstellen van de documentatie en het Plan van Aanpak bleek dit zeer nuttig. Verder is de opmaak van Google Documents in plain-text formaat. Hierdoor is het redelijk snel over te zetten naar een latex document mocht dit nodig zijn.

3.2

Kwaliteitsbewaking

Kwaliteit is belangrijk binnen elk project. In het geval van softwareontwikkeling is het cruciaal - een klein probleem kan grote gevolgen hebben. Vaak is het 9



onmogelijk om op een gemakkelijke manier het probleem op te sporen en op te lossen. Daarom is het uitermate belangrijk dat de kwaliteit vanaf het eerste moment van implementatie in orde is, en daarnaast ook goed bewaakt wordt. Binnen ons project wordt de kwaliteit van de applicatie op meerdere manieren in de gaten gehouden. Bij het implementeren van de applicatiecode wordt deze gecompileerd door de programmeur. Als er syntax fouten in de code bestaan zal het compilen falen, en de applicatie zal niet uitgevoerd kunnen worden. Op dat moment is het aan de programmeur om de fout te vinden en op te lossen. Als een programmeur de applicatie heeft aangepast, en getest op zijn lokale machine, zal deze opgestuurd worden naar de SVN. Op dit moment treedt de continuous-build-server in werking. Deze haalt de laatste versie van de software van de SVN server en compiled deze opnieuw. Als er zich toch nog onverwachte fouten voordoen dan zullen alle groepsleden per email op de hoogte gebracht worden. Het is aan de persoon die de code geschreven heeft om de fout zo snel mogelijk te herstellen en opnieuw naar de SVN server te sturen. Hierbij wordt weer opnieuw gekeken of de code compiled, en zo niet wordt er weer een email verstuurd. Naast het kunnen compilen wordt na elke aanpassing de applicatie getest op een live systeem (node). Om dit te bereiken wordt de node gerestart. Bij het opnieuw opstarten haalt deze de nieuwe software op van de continuous-buildserver en start deze. Het is aan de programmeur en aanwezige groepsleden om verkeerd gedrag op te merken. Veel code wordt geschreven in een pair. Dit houdt in dat twee programmeurs samen aan een stuk code werken. Het voordeel hiervan is dat beide van elkaar leren, en daarnaast de kwaliteit van de ander kunnen bewaken. Alle code wordt ook voorzien van Javadoc commentaar. Dit is om de code overzichtelijker te maken, en om informatie te bieden aan iedereen die de code inkijkt. Dit is erg belangrijk bij de laatste stap van de kwaliteitscontrole: Code review. Code review is het doorkijken van de code door andere groepsleden. Dit gebeurd (indien mogelijk) met alle code die aangepast is. Vaak gaat dat vanzelf als een andere programmeur verder gaat met bestaande code, en soms moet even gevraagd worden of iemand de code even wil nalopen om zeker te zijn.

3.3

Testprocedures

Tests worden gedaan op verschillende onderdelen, en de tests worden ook op verschillende manieren uitgevoerd. Ten eerste is er applicatiecode dat getest moet worden. In eerste instantie was er besloten dit met unit-testing te doen in het kader van testdriven-development (Zie ook: 3.1.1). Hierbij wordt er eerst een test geschreven (Welke faalt), en pas later de code toegevoegd die ervoor zorgt dat de test slaagt. Op deze manier worden correcte tests en dus ook code geforceerd. Tijdens de eerste begin weken van het project hebben we dit gebruikt, maar kwamen er al snel achter dat dit erg onpraktisch is. De leercurve voor deze techniek is te stijl binnen het project. Daarom hebben we gekozen

10



om de tests op een andere manier uit te voeren. De applicatie die we geschreven hebben heeft slechts een beperkt aantal reacties die uitgevoerd worden bij acties. Deze acties kunnen aangestuurd worden doormiddel van een speciale event-generator, of simpelweg een muisklik. Hierdoor is het zeer simpel om na het implementeren van nieuwe code een node te voorzien van de aangepaste applicatie en in een paar seconden handmatig de verwachte reacties te testen. Door de nodes tijdens het ontwikkelproces ook voortdurend aan te laten staan vallen eventuele problemen ook direct op. Daarnaast is er nog het testen van de op te leveren producten. Bijvoorbeeld een presentatie wordt doorgenomen met andere groepsleden, of een document wordt gereviewed om te zien of deze foute informatie of spelfouten bevat. Een op te leveren cd wordt getest op juistheid van de inhoud en eventueel na het branden op brandfouten(en dus leesfouten).

3.4

Oplevering

De oplevering van het project bestaat uit drie onderdelen. Als eerste is er het product - de Funnyscreens. Dit is een collectie van schermen, met een mini-pc en eventueel een of meerdere sensoren. Deze schermen worden kant-en-klaar opgeleverd met de nodige software ge¨ınstalleerd. Alleen het aansluiten van het netwerk en de IP-configuratie is nodig om de nodes in werking te stellen. Daarnaast wordt er een pakket opgeleverd dat het mogelijk maakt nieuwe nodes te installeren. Dit bestaat uit een cd met software (disk image) voor de nodes en een CD met software voor de continuous build server. Ook wordt hierbij een installatie handleiding meegeleverd. Als laatste is er de algemene documentatie. Deze documentatie beschrijft de werking van het systeem, een verslag van de specifieke product onderdelen en een verslag van het ontwikkelproces. • CD voor nodes: Disk image, Sourcecode, SVN backup, Wiki backup • CD voor continuous-build-server: Scripts en handleiding • Verslag van het ontwikkelproces (Dit verslag) • Een aantal werkende nodes: Scherm, PC, eventueel sensoren Naast de oplevering van deze fysieke producten zijn er tijdens het ontwikkelingsproces nog een presentatie en interview aan bod gekomen. De presentatie betrof een inleiding van het project voor een andere projectgroep, terwijl het interview een uitwisseling van specifieke projectinformatie was. Dit laatste is om het mogelijk te maken voor een andere groep om het project eventueel te kunnen overnemen. Aan het einde van het project wordt ook een presentatie gegeven in de stijl van een afstudeerverdediging. Hierbij wordt de mogelijkheid geboden voor het publiek om vragen te stellen over het product.

11

Hoofdstuk 4

Resultaat 4.1

Development

Voor de ontwikkeling gebruiken we een speciale server, de zogenoemde ’continuousbuild server’. Deze server bevat een aantal onderdelen die de ontwikkelaars ondersteunen tijdens de ontwikkeling van de software. Daarnaast hebben we een SVN server in gebruik (Aangeleverd door Google) waar de code revisies worden bijgehouden. De belangrijkste functionaliteit van de continuousbuild server is het altijd beschikbaar hebben van een up-to-date versie van de applicatie. De verschillende nodes kunnen dan direct de laatste versie van deze server downloaden, bij voorkeur via http. Om dit te bereiken voert de server elke 5 minuten een buildscript uit.

4.1.1

Continuous build script

Het continuous build script maakt een werkbare versie van de applicatie klaar voor deployment. In eerste instantie wordt er een SVN update gedaan. Als er een nieuwe versie van de applicatie op de SVN opgeslagen is wordt verder gegaan met de compile-stap. De code van de SVN wordt gecompiled en gecontroleerd op fouten. Als er geen fouten zijn worden eventuele JUnit unit-testen uitgevoerd. Als er fouten zijn voorgekomen in oftewel de unit-testen of compile stap, dan wordt de groep op de hoogte gesteld per email. Als er geen fouten zijn voorgekomen is er op dat moment een geschikte versie van de applicatie klaar. Deze wordt nu klaargemaakt voor distributie. Hiervoor wordt de code, inclusief de nodige dependencies (Jars, videos, etc) ingepakt in zowel een jar als een tar bestand. Deze bestanden worden op hun beurt naar een bestandslocatie gekopieerd waarmee ze beschikbaar worden via de webserver. Het versturen van een eventuele email gebeurt via een proxy-script op een remote server. Dit is nodig aangezien het niet toegestaan is om een email te versturen van het school netwerk. Met deze constructie wordt de email-body,

12


Hoofdstuk 4. Resultaat

Figuur 4.1: Continuous build proces samen met het bestemmingsadres via http naar de andere server gestuurd. Deze zal de data dan per email versturen.

4.2

Node

In deze sectie zal de keuze voor het besturingssysteem, als mede de werking van het opstart script worden uitgelegd.

4.2.1

Besturingssysteem

Aan het begin van het project is er geadviseerd om als besturingssysteem voor de nodes de ETCH distributie van Debian te gebruiken. In eerste instantie is dit besturingssysteem ook op de nodes ge¨ınstalleerd door de groep. Al snel bleek dat de nodes problemen ondervonden bij het afspelen van video’s op volledige schermgrootte. Om dit op te lossen is er eerst door de groep van alles geprobeerd, waaronder het uitproberen van diverse drivers. Geen van de gevonden drivers konden er voor zorgen dat het afspelen van de video’s soepel verliep. De video’s bleven schokkerig. Na overleg is door de groep besloten om andere besturingssystemen uit te proberen, waarbij gedacht werd aan Windows XP embedded. Voor het installeren van Windows XP embedded is het nodig om een dedicated pc te hebben waarop een installatie image gemaakt kan worden. Deze installatie image dient vervolgens overgezet te worden op een cd, welke dan als installatie-cd gebruikt gaat worden. Een pc die voldeed aan de eisen die gesteld werden aan de dedicated Windows XP embedded pc was helaas niet beschikbaar. Windows XP embedded viel hierdoor af als optie. Bij wijze van test werd op een van de beschikbare nodes Windows XP Professional ge¨ınstalleerd om te kijken hoe stabiel het werkt. Na installatie bleek al gauw dat het best mogelijk was om Windows XP Professional als besturingssysteem te gebruiken voor de nodes. Om te voorkomen dat de nodes te warm worden en om er voor te zorgen dat ze stabiel

13



blijven werken is de node terug geklokt van 1.5 GHz naar 400 MHz. Door het gebruik van Java als programmeertaal is de applicatie platform onafhankelijk. Hierdoor leverde de overstap van Linux naar Windows geen problemen op.

4.2.2

Opstart script

Het opstart-script wordt opgestart nadat de node het besturingssysteem heeft geladen. Als eerste kijkt het script of er nog een oude versie van het softwareprogramma aanwezig is. Indien dit het geval is wordt er gecontroleerd op de aanwezigheid van een back-up bestand genaamd ”latest.old”. Dit back-up bestand zal worden verwijderd indien aanwezig. Hierna zal het script het huidige programma hernoemen naar de naam van het back-up bestand. Vervolgens wordt er geprobeerd contact te leggen met de server voor het downloaden van de laatste versie van het programma. Omdat de mogelijkheid bestaat dat er geen verbinding gemaakt kan worden met de server, zal het script nogmaals controleren op de aanwezigheid van het softwareprogramma. Mocht het nou zo zijn dat het downloaden van de laatste versie van de software is mislukt, dan zal het script het back-up bestand hernoemen naar de originele naam van het archief. Nadat het script geprobeerd heeft om de laatste versie van de software te downloaden van de server, zal het script het archiefbestand van de software uitpakken in een directory. Na het uitpakken van de software wordt de videospeler VLC gestart. Het script gaat vervolgens naar de javabuild directory, stelt het juiste classpath in en start vervolgens de applicatie. De ”movie 1”parameter aan het einde van het java commando dient voor het aangeven van de videodirectory. Hierdoor is het mogelijk verschillende filmpjes op de verschillende schermen af te spelen. De uitwerking van het opstart-script is toegevoegd als bijlage.

4.3 4.3.1

Applicatie Netwerklaag

De netwerklaag dient er voor om de verschillende nodes met elkaar te laten communiceren over het netwerk. Gekozen kan worden voor TCP of UDP. Ook kan er nog gekozen worden voor Peer 2 peer over TCP. De volgende eisen zijn van toepassing op de communicatie. • Snel • Betrouwbaar • Flexibel TCP en peer 2 peer zijn erg betrouwbaar en geven garantie over het afleveren van de pakketten. Hiervoor werkt TCP met ack pakketjes. Dit zorgt ervoor dat er hier tijdsverlies optreed. Ook als er een node uit zou mogen vallen is in het geval 14



van TCP veel tijdsverlies van de TCP timeout. UDP daarentegen garandeert niet de aankomst van het pakket. Dit pakket kan onderweg verloren raken. Wel kan er bij UDP gebruik gemaakt worden van broadcasting[13], waarbij naar alle nodes tegelijk verzonden zou kunnen worden. UDP is in dit geval flexibeler. Het systeem zou niet onnodige vertraging krijgen door een time-out. UDP betrouwbaarheidstest Omdat UDP wel de flexibiliteit heeft die we zoeken, willen we weten in welke mate de onbetrouwbaarheid van UDP een rol speelt. Om dit te testen starten we een ping opdracht van een node naar de andere. Bij deze ping opdracht werden 100.000 pakketjes verstuurd. Bij het versturen van de ping-pakketjes werd niet gewacht op een antwoord op de vorige. Tijdens deze ping-opdracht hebben we op de pingende node ook een ftp transfer gestart. waardoor het risico op collisions toeneemt. Het resultaat van deze test is dat er geen pakketten verloren waren. Alle ping request waren aangekomen. Dit toont aan dat de onbetrouwbaarheid van UDP bij deze applicatie niet van belang is. Mede door de mogelijkheid voor het broadcasten kiezen we voor UDP als communicatie protocol. Ip-configuratie Als er een bericht van een node komt moet de andere node weten waar binnen schermen wand deze node zich bevindt. Hiervoor zou op elke node een lijst bijgehouden kunnen worden. Dit is echter extra opslag en de lijst kan incorrect zijn wanneer een node uitvalt. Een andere mogelijkheid is om de positie van een scherm uit het ip-adres af te lezen is. Er is er voor gekozen om gebruik te maken van de laatst genoemde mogelijkheid. De laatste 2 octetten van het ipadres geven de x- en de y-as aan. Het ip-adres ziet er dan als volgt uit: Figuur 4.2: Ip configuratie 192.168.x.y. In de schermen wand ziet het er dan uit als te zien in figuur 4.2 Door het ip-adres te vergelijken met zijn eigen ip-adres kan een node bepalen waar in het raster het bericht is verstuurd. Communicatie Om met de andere nodes te communiceren stuurt een node berichten naar de andere nodes. In deze berichten is de status van de node af te leiden. Deze berichten worden op het netwerk gebroadcast. De verzendende node bepaalt dus

15



niet voor welke node het bericht belangrijk is. De ontvangende node bepaalt of het bericht verwerkt moet worden. Hierdoor is de implementatie dynamischer. Een node zou alle nodes iets kunnen laten doen. Ook is de manier van verzenden niet afhankelijk van het bericht. Om een ander scherm aan te kijken stuurt een node een bericht naar het broadcast-adres. Bij het ontvangen zal de node gaan kijken. Ook de buurman reageert daarop door de andere node aan te kijken. 1. Node op positie 2,3 stuurt een LOOK_LEFT naar het broadcast-adres. 2. Node 2,3 gaat bij het ontvangen links kijken. 3. Node 1,3 gaat tegelijkertijd naar rechts kijken. Bij deze manier kwam het voor dat een node een node aankeek die al naar een andere node aan het kijken was. Hierbij kijken ze elkaar dus niet aan. Ook zorgde dit er voor dat een scherm naar links kon kijken terwijl daar geen node geplaatst was. Om dit op te lossen hebben we het protocol iets aangepast. Een node die het initiatief neemt stuurt een request. Als de node, waarmee de interactie plaats moet vinden, aanwezig of beschikbaar is zal deze vervolgens een bericht broadcasten waardoor de nodes elkaar aan gaan kijken. 1. Node op positie 2,3 stuurt een LOOK_LEFT_REQUEST. 2. Node op positie 1,3 reageert wanneer hij beschikbaar is met een LOOK_RIGHT. 3. Node 2,3 kijkt links. 4. Node 1,3 kijkt rechts. Implementatie Voor de implementatie voor het netwerk gedeelte hebben NetworkHandler SendQueue : Queue we gekozen voor UDP. In de ReceiveQueue : Queue applicatie maken we 2 sockets aan, een server-socket en en socket om te ontvangen. Deze sockets koppelen we los NetworkSender NetworkReceiver van de applicatie door middel van Queues. De berichten die zijn ontvangen worden eerst Figuur 4.3: Netwerkstructuur in de queue gestopt alvorens te worden verwerkt. Voor het verzenden geldt hetzelfde. Voor een bericht verzonden wordt, wordt het eerst in een queue gezet en daarna over de socket verstuurd. Het voordeel hiervan is dat vertraging bij het verzenden er niet voor zorgt dat de applicatie daar op moet wachten. Ook kan er hierdoor berichten ontvangen worden terwijl de applicatie berichten verwerkt. De structuur is te zien in figuur 4.3. Het totale class diagram is te vinden in de bijlage. 16



Het binnengekomen bericht is van het type NodeMessage. In deze NodeMessage is het soort bericht te vinden. Aan de hand van dat type zal de logica een actie uitvoeren. De volgende acties zijn ge¨ımplementeerd: Links en rechts kijken Hierbij kijken twee nodes elkaar aan die naast elkaar staan. De berichten die hiervoor gebruikt worden zijn: LOOK_LEFT_REQUEST, LOOK_LEFT, LOOK_RIGHT_REQUEST, LOOK_RIGHT. Onder en boven kijken twee nodes die boven elkaar geplaatst zijn kijken elkaar aan. De gebruikte berichten zijn: LOOK_UP_REQUEST, LOOK_UP, LOOK_DOWN_REQUEST, LOOK_DOWN. Diagonaal kijken Een node kijkt hier bij schuin naar boven of onder. Het aangekeken scherm kijkt terug. LOOK_UP_LEFT, LOOK_UP_RIGHT, LOOK_DOWN_LEFT, LOOK_DOWN_RIGHT, UP_LEFT_REQUEST, UP_RIGHT_REQUEST, DOWN_LEFT_REQUEST, DOWN_RIGHT_REQUEST Beweging gedetecteerd Als er in de omgeving een beweging is gedetecteerd zal een bijzondere actie uitgevoerd worden. Hiervoor is maar een soort bericht: MOVEMENT. Shutdown en Reboot Om alle nodes tegelijkertijd af te sluiten of op nieuw op te laten starten is er ook de actie shutdown en de actie reboot geimplementeerd. Hiervoor zijn het berichttypes SHUTDOWN en REBOOT. Alle nodes zullen op dit bericht reageren en vervolgens opnieuw opstarten of afsluiten.

4.3.2

Tonen video’s

Voor weergeven van de video’s hebben we vele opties bekeken. Hierbij stonden een aantal eisen centraal: Het ondersteunen van de juiste video formaten, het vloeiend fullscreen kunnen afspelen zonder gaten tussen video’s en het gemakkelijk kunnen aansturen vanuit de Java applicatie. Java Media Framework Het Java Media Framework (JMF[11]) lag voor de hand om te gebruiken. Dit is een door Sun ontwikkeld framework om multimedia bestanden af te spelen in Java. Tijdens onze eerste testen bleek dit helaas niet te voldoen qua snelheid en mogelijkheden, in het bijzonder bij volledige schermgroote. De video werd namelijk onderbroken bij het overgaan naar een volgende playlist item, en deze onderbreking is zeer schadelijk voor de ervaring. Het afspelen van een video Fullscreen ging ook niet vloeiend. VideoLan media player

17



Een goede tweede alternatief was de VideoLan (VLC[18]) media speler. Deze software is opensource, ondersteund elk OS en is gratis. Deze speler werkt standalone en kan tussen videos schakelen zonder vreemde overgangseffecten tussendoor. Perfect voor ons doel. VLC heeft een aantal interfaces Figuur 4.4: VideoLan media player waarmee de speler aangestuurd kan worden. De meest bekende is de GUI die voor de verschillende operating systems beschikbaar is. Daarnaast is er een Web-interface en een Telnet interface. We hebben zowel de Web -als Telnet interface getest en ge¨ımplementeerd onder Java. Implementatie In eerste instantie hebben we gekozen om VLC[18] te gebruiken voor het weergeven van de video’s. VLC heeft de meeste mogelijkheden qua aansturing en is daarnaast open-source. Plus het feit dat het een van de weinige spelers is die het overgaan tussen video’s goed kan weergeven maakte het de meest voor de hand liggende optie. De web-interface die VLC aanbiedt werkt door middel van XML files die opgevraagd kunnen worden van de interne webserver. Deze files bevatten informatie over de video die op dat moment speelt. Bijvoorbeeld welke video, de positie en de lengte. Het geven van commando’s (Bijvoorbeeld: Play, Stop, Pauze) gaan door middel van een HTPP GET parameter. Aangezien deze API niet publiekelijk is hebben we deze onderzocht door het HTTP verkeer van de webinterface te ’sniffen’ met een FireFox plugin LiveHttpHeaders[12]. De gevonden API commando lijst is gedocumenteerd in de Wiki[4]. Om de video aansturing universeel te houden hebben we de VLC aansturing onder Java door middel van een Interface ontkoppeld. Hierdoor is het mogelijk om gemakkelijk de HTTP-VLC aansturing te vervangen voor een andere aansturing, zonder dat de rest van het systeem hier last van heeft. Deze Interface is beschreven in de wiki en verplicht de implementatie van een aantal functies die het systeem minimaal nodig heeft om goed te kunnen werken. Na de implementatie en testen bleek de HTTP interface van VLC niet optimaal. Hoewel voor korte periodes hij zeer goed werkt, crashed de webinterface van VLC na een wat langere periode (30-60 minuten). De reden voor dit vreemde gedrag is onze bijzondere applicatie die zeer veel requests op de webserver doet. Deze is hier niet voor ontworpen en bevat enkele buffer-overflow bugs die na enkele tienduizenden requests actief worden. De tweede aansturingsmogelijkheid is de telnet interface die VLC ondersteunt. De telnet interface werkt op een instelbare poort en kan door middel van een ’help’ commando een lijst met aansturingsmogelijkheden tonen. Deze lijst is weergegeven op de wiki. De belangrijkste functies zijn ’add’ en ’goto’ 18



om video’s toe te voegen aan de playlist, en vervolgens actief te maken en te spelen. Ook de telnet interface voldoet aan de generieke Interface die gemaakt is voor het video spelen. Hierdoor kan het indien nodig vervangen worden voor een andere aansturing (voor eventueel een andere video speler). Hoewel de telnet interface goed werkt geeft ook deze na enige tijd problemen. Na +/- 30 minuten geeft VLC een input-error (unsupported codec) en gebruikt dan 100% CPU. Hierdoor gaat het verder afspelen van de video schokkerig op momenten met veel beweging. Mits een Divx video codec gebruikt wordt is dit nog redelijk acceptabel, met bijvoorbeeld het mp4 (Apple) formaat is dit niet werkbaar. Om deze bug op te lossen hebben we contact gezocht met het VLC ontwikkelteam. Deze kon ons echter niet helpen zonder informatie over waar de bug zich bevindt. Om dit te vinden hebben we een debug-build van VLC moeten compilen. Dit hebben we gedaan, om er achter te komen dat deze debug-build zeer onstabiel is. Het is bijvoorbeeld niet mogelijk om meerdere items in de playlist te plaatsen, dan crashed de applicatie. Gezien het tekort aan tijd om deze problemen op te lossen is samen met de opdrachtgever besloten om de videospeler Interface goed te documenteren. In combinatie met Divx video’s is de telnet versie van de applicatie dan goed bruikbaar. Een volgende project groep kan eventueel een andere video speler gebruiken met behulp van de Interface.

4.3.3

Network-event generator

Om de verschillende acties te testen kan er gewacht worden tot de applicatie uit zichzelf een actie genereert. Als er veel verschillende soorten reacties zijn, kan het zijn dat er erg lang gewacht moet worden. Om het testen makkelijker te maken hebben we een applicatie die berichten naar het broadcast-adres stuurt. In het venster kunnen de verschillende berichttypes gekozen worden. Hiernaast moet ook de positie ingevoerd worden van waar de generator zich bevindt in het raster. Na het klikken op send zal het bericht verzonden worden. Figuur 4.5: Network-event-generator Deze applicatie gebruikt het netwerkgedeelte van de eigenlijke applicatie met een GUI er omheen.

19


4.3.4


J/Invoke

We zochten naar een manier om een bewegingssensor aan te sluiten op onze nodes. Al gauw kwamen we op het idee om een muis te modificeren zodat er bij beweging een muis event het besturingssysteem in komt. Deze aanpak had twee problemen. Aangezien we gebruik maken van VLC[18] als videospeler, komen de muis-events niet als een event binnen in de java applicatie, en juist daar willen we acties uitvoeren om te reageren op het event. Daarnaast komen de events wel binnen op onze videospeler, die automatisch bij twee muisklikken uit volledige scherm modus gaat. In eerste instantie leek het ons voor de hand liggen om de JVM[9] naar de status van de muisknoppen te vragen. Na enig onderzoek bleek dit niet mogelijk. Dat betekende dat we terug moesten vallen op het besturingssysteem, door middel van een native extensie. Het is relatief makkelijk om onder Windows een hook1 te schrijven om alle systeem events te capturen. Deze hook moet dan wel in C geschreven worden. Om deze hook vanuit Java te kunnen gebruiken kan er gebruik gemaakt worden van JNI[8]. Makkelijker is het om gebruik te maken van J/Invoke[6]. Deze bibliotheek geeft ons onder Java out of the box functionaliteit om zonder een regel C code te hoeven schrijven, toch gebruik te kunnen maken van de event functionaliteit van het besturingssysteem. Er is zelfs voorbeeldcode[7] op de website van J/Invoke aanwezig die precies doet wat wij willen. Na enige contact met het bedrijf achter J/Invoke hebben we een licentie voor academisch gebruik gekregen. Met het gebruik van J/Invoke hebben we het eerste deel van het probleem opgelost. Zelfs wanneer VLC fullscreen op de voorgrond draait, kunnen we een mouse event ontvangen in onze Java applicatie. Sterker nog, we kunnen er ook een event verder te blokkeren, zodat het niet bij VLC en zelfs niet de rest van het besturingssysteem aankomt. Hiermee is ook het tweede deel van het probleem opgelost. Een mouse event komt alleen aan in ons Java programma en niet bij VLC. Dus kunnen we reageren op beweging in onze applicatie en zal VLC niet uit de fullscreen modus gaan.

1 Door het plaatsten van een ’hook’ is een programmeur in staat zich in de event-ketting van een event te plaatsen

20

Hoofdstuk 5

Conclusie en aanbevelingen 5.1

Resultaat

Het uiteindelijke resultaat is een schermenwand welke video’s toont. Er zijn vijf verschillende gezichten die getoond kunnen worden. De schermen kunnen met elkaar communiceren. Hiermee kunnen verschillende schermen elkaar aankijken. Dit kan over de horizontale- verticale- en diagonale-as. Ook kunnen de schermen reageren op de omgeving. Als er een sensor aangesloten is op de node kan deze daar op reageren. De gerealiseerde sensor is een bewegingsensor. Als deze is aangesloten op een node dan zullen de nodes op beweging reageren. Er wordt op dat moment een filmpje afgespeeld waar een bijzondere actie te zien is.

5.2

Aanbevelingen

De video’s die getoond worden, worden met behulp van VLC getoond. Deze player biedt veel functie en is precies wat we zochten. Helaas heeft deze player een bug waardoor de applicatie na ongeveer een half uur niet meer soepel loopt. Om dit probleem op te lossen is het aan te raden om te zoeken naar een alternatief voor VLC. Ook kan er geprobeerd worden de bug er uit te halen als dat nog niet door het VLC team is gedaan. Als alternatief voor VLC hebben we Zoomplayer en winamp geprobeerd die niet voldeden. Eventueel kan er ook gekeken worden naar het afspelen van video’s in Java. De sensor die we hebben gemaakt is een goed werkende prototype. Hier zijn een beperkt aantal mogelijkheden aanwezig om de kijkhoek aan te passen. Ook hebben we niet meer de mogelijkheid gehad om meerdere sensoren te maken vanwege de lange lever-tijd. Aan te raden is om rekening te houden met die levertijd. Ook kan er nog gekeken worden of er misschien nog betere alternatieven zijn met een kleinere kijkhoek. De gebruikte mini-pc’s worden gauw warm en zijn niet echt snel. Ook hebben deze geen goede driver voor linux. Er kunnen voor deze hardware ook alterna-

21


Hoofdstuk 5. Conclusie en aanbevelingen

tieven gezocht worden die beter zijn. Hierbij moet gelet worden op snelheid en warmte. Ook ondersteuning voor linux is een voorkeur. Bij het realiseren van de applicatie hebben we filmpjes gemaakt om te kunnen testen. Deze filmpjes zijn gemaakt met een webcam. Het zou mooier en realistischer zijn als de filmpje met wat meer aandacht gemaakt worden. Een goede aanpak en goed filmmateriaal zorgt er voor dat de overgang van filmpjes beter verlopen.

22

Hoofdstuk 6

Reflectie 6.1 6.1.1

Reflectie Reflectie Groep

Het project voor Realtime & Embedded Systems is goed verlopen. De opdracht is afgerond en wel op een manier dat een volgende projectgroep er eventueel ook goed mee verder kan indien gewenst. Tijdens de projectweken is er gewerkt met een aantal nieuwe technieken. Scrum/XP is hierbij de belangrijkste. Dit beschrijft een agile manier van ontwikkelen in combinatie met pair-programming. Dit was een groot succes met een goed resultaat. Werken binnen de groep De groep heeft goed kunnen samenwerken. Dit was ook wel verwacht aangezien alle groepsleden elkaar goed kennen. Een gedragscode was dus ook niet nodig elk groepslid weet dat hij een verantwoordelijkheid heeft naar de groep. We hebben daarom bewust niet gekozen voor een systeem met gele/rode kaarten. Dit was ook niet nodig. Door tijdens het project eenmalig te spreken over hoe we omgaan met afwezigheid hebben we dit risico voldoende gedekt. Verder hebben er zich geen problemen binnen de groep voorgedaan. Team Opleidingsplan In het plan van aanpak is een Team OpleidingsPlan beschreven. Dit is een plan die de doelen voor het project opstelt, op eenzelfde manier dat een Persoonlijk Opleidingsplan dat doet per groepslid. In de volgende paragraaf worden de verschillende punten die in het TOP1 staan besproken. 1 afkorting

voor als Team OpleidingsPlan

23


Hoofdstuk 6. Reflectie

Ambient Systeem bouwen Het FunnyScreens project heeft als product een aantal schermen die met elkaar en de buitenwereld communiceren. Dit wordt ook een ’Ambient Systeem’ genoemd. Programmeren met threads De applicatie die de schermen aanstuurt is geschreven in Java. Om de verschillende onderdelen van de java applicatie te ontkoppelen hebben we gekozen om elk onderdeel in een eigen thread te draaien. Hiermee wordt communicatie tussen threads bijvoorbeeld opgelost met queues, wat de stabiliteit ten goede komt. Ontwerpen van een systeem zonder single point of failure De schermen nodes communiceren alleen met elkaar. Er is geen centrale server die de nodes aanstuurt. In principe kan het systeem zelfs werken met een enkele node. Het is ook mogelijk om een node weg te halen uit een werkend systeem, en dat zal geen problemen opleveren voor de overgebleven node(s). Kennis en ervaring opdoen met Scrum/XP Tijdens de uitvoering van het project hebben we met de Scrum/XP ontwikkelmethode gewerkt. Vooral het agile aspect vonden we een fijne methode om mee te werken. Door het pair-programming is er direct ook feedback tijdens het ontwikkelen. Juiste implementatie van de sensoren De sensoren waren in eerste instantie bedoeld voor Debian. Door onze aanpassing naar het Windows OS hebben we dit punt op een andere manier moeten implementeren. Niettemin is het resultaat behaalt door de sensoren aan een muis te koppelen. Embedded systeem realiseren De mini-pc’s die gebruikt zijn achter de schermen zijn de VM7700 van VIA, een systeem puur voor embedded oplossingen. Ervaring opdoen met Netwerk protocol De nodes communiceren met elkaar via het netwerk. Hiervoor wordt het UDP protocol gebruikt waarmee Serialized Java objecten worden verstuurd. Effectief vergaderen Tijdens het project hebben we vele malen, kort vergaderd. Dit is zeer effectief en geeft de mogelijkheid snel verder te gaan aan de taken. Test driven development Test driven development hebben we gebruikt in de eerste week(en). Hiervoor hebben we de continuous build server ingericht om de tests uit te voeren, en ook hebben we de JUnit plugins beschikbaar gemaakt op de workstations. De eerste code is ook geschreven met de bijbehorende tests. Deze manier van ontwikkelen bleek echter zeer omslachtig voor ons doel, onder ander wegens gebrek aan goede begeleiding en ervaring. Daarom hebben we

24



besloten testdriven development niet te gebruiken voor de rest van de code. De ervaring ermee hebben we echter wel opgedaan in de eerste week(en). Ervaring opdoen met Debian kernel Tijdens het werken met de nodes hebben we meerdere keren een kernel gecompileerd om te proberen driver-issues te verhelpen.

6.1.2

Reflectie Matthijs Langenberg

Nu het project beëindigd is, wil ik graag even terugblikken op mijn persoonlijke ervaringen. Ik ben tevreden over de loop van het project, de opgeleverde producten en mijn bijdrage hieraan. Wel vind ik het jammer dat het eindproduct niet zo stabiel is als ik had gehoopt, maar dat bleek uiteindelijk niet haalbaar. Werken binnen de groep Binnen de groep was er een goede samenwerking en sfeer. Naar mijn mening zat iedereen na enkele weken op de juiste plek. Wel was er onenigheid over de begintijd, niet iedereen kwam altijd op tijd. Ik vond onze begintijd eigenlijk iets aan de late kant. Werken met materiaal en faciliteiten Ik vond de vanuit Saxion beschikbare materialen en faciliteiten ondermaats. De werkruimte is erg onrustig en rumoerig. Ik had moeite me te concentreren in de ruimte en had na nog maar een paar uur gewerkt te hebben weinig energie meer over. Zes groepen van vijf studenten in een ruimte is gewoon te veel. Het was wel fijn om een whiteboard ter beschikking hebben. De geleverde mini-pc’s waren niet echt geschikt voor ons project. Er waren alleen drivers beschikbaar voor het Windows besturingssysteem, terwijl we van tevoren eigenlijk onze zinnen hadden gezet op het gebruik van Linux. Ook hadden de gebruikte mini-pc’s te kampen met temperatuurproblemen, ze werden al snel overhit. Voor de installatie van het besturingssysteem op de mini-pc’s is een CDROM speler met USB aansluiting benodigd. Vreemd genoeg was er maar één speler beschikbaar voor alle groepen. Project en implementatie Aangezien ik nogal een aanhanger ben van Agile Practises, vond ik het heerlijk om Scrum en eXtreme Programming the mogen gebruiken tijdens een project. Het was voor mijn niet een totaal nieuwe ervaring, ik heb al eens vaker op deze manier gewerkt. Wel vond ik het leuk om er eens vanuit school mee te werken. Helaas was er vanuit Saxion weinig begeleiding bij het Scrum of XP proces. Er werd veel op de gok gedaan terwijl je bij het leren van een dergelijk proces, je

25



eigenlijk een goede coach nodig hebt met enkele jaren ervaring. Het is immers een volledig pragmatische aanpak, dat leer je niet uit een boek, maar voel je aan. Er is wel een enkel gastcollege geweest over Scrum/XP, maar de echte vragen krijg je pas nadat je er enkele weken mee bezig bent geweest. Daarom hebben we ook een belangrijk element van eXtreme Programming, namelijk Test Driven Development, niet goed uit kunnen voeren. Ik miste de benodigde kennis en ervaring om TDD voor mijn hele team uit te kunnen leggen en rendabel binnen het project toe te kunnen passen. Persoonlijk Opleidings Plan Aan het begin van het project heb ik een persoonlijk opleidingsplan opgesteld2 . Nu we aan het eind van het project ben, kijk ik terug op het gemaakte opleidingsplan. Ik zal elk doel uit mijn POP behandelen. Ervaring opdoen met netwerkprotocol ontwerpen en implementeren Tijdens het project heb ik extra aandacht besteed aan de manier waarop de netwerkcommunicatie gaat. Dit is goed gelukt, het project maakt gebruik van een lichtgewicht UDP/broadcast protocol. Effectief vergaderen De agile werkmethoden die we hebben gebruikt zijn er altijd op gericht om de vergadertijd zo effectief en kort mogelijk te houden. Als meetbaar resultaat had ik genoteerd dat ik graag de gemiddelde vergadertijd wou verkorten, helaas heb ik dit niet met een stopwatch nagemeten. Voor mijn gevoel duurde een overleg aan het eind van het project, minder lang dan een overleg aan het begin van het project. Ook heb ik veel uit het boek Getting Real3 kunnen halen. Vooral het hoofdstuk4 over het houden van vergaderingen heeft me geholpen te focussen op de dingen die er wel toe doen. Goed Test Driven kunnen ontwikkelen binnen een team Aan het begin van het project had ik gedacht dat we Test Driven Development (TDD) zouden kunnen leren en toepassen tijdens het project. Helaas bleek dat doel iets te ambitieus. Toen ik in de gaten kreeg dat ik op deze manier dit doel niet zou kunnen bereiken heb ik contact op gezocht met de begeleiders van het project. Van Dhr. Tangelder heb ik Test Driven Development[14] van Kent Beck kunnen lenen. Nu denk ik dat ik het gewenste resultaat bereikt heb. Ik kan een opdracht volgens de TDD-principes aanpakken en kan daarbij ook mijn teamgenoten begeleiden. Helaas heb ik dat binnen dit project niet direct in de praktijk kunnen brengen. 2 Zie

bijlage D voor mijn POP

3 http://gettingreal.37signals.com/ 4 http://gettingreal.37signals.com/ch07_Meetings_Are_Toxic.php

26



Leidinggevend kunnen zijn Tijdens dit project had ik de titel Scrum Master. Ik hield de planning in de gaten en delegeerde taken waar nodig. Ik gaf vooral sturing in welke taken er gedaan werden, in mindere mate wie ze deed. Tijdens de projectperiode heb ik geen boeken over management gelezen, wel ben ik naar een training geweest waar een stukken time management en communicatieve vaardigheden in zaten. Tijdens deze training heb ik vooral geleerd hoe je, je niet altijd moet laten leiden door ”de dingen van de dag”, maar dat je eens per dag een stap terug moet doen om te kijken waar je in grootte lijnen mee bezig bent. Ook heb ik Getting Things Done[15] van David Allen gelezen, met als doel meer grip en overzicht op lopende projecten te krijgen. Deze vaardigheden zijn belangrijk bij het aansturen van een team. Ik ben er van bewust dat ik soms een steek heb laten vallen. Wanneer ergens druk op komt te staan en het idee krijg dat er niet naar me geluisterd word, heb ik wel eens de neiging om mijn ”kop in het zand te steken”. Een eigenschap waar ik de komende tijd aan ga werken. Ervaring opdoen met eXtreme Programming Het was fijn om ervaring op te doen met eXtreme Programming (XP) met dit project. Ik weet nu de voor en nadelen van XP en zou bedrijven adviezen kunnen geven over het gebruik. Tijdens het project heb ik Extreme Programming Explained[16] van Kent Beck gelezen om duidelijk te krijgen wat nu precies Extreme Programming is. Zo beschrijft Kent Beck dat je alleen XP gebruikt als je alle onderdelen moet gebruiken. Je doet niet aan XP als je niet Test-Driven werkt of als er geen echte klant in het team zit. Dit betekend dat we in feite geen eXtreme Programming gedaan hebben. Ervaring opdoen met Scrum Door Scrum and XP from the Trenches[17] te lezen en dit vervolgens in het project zo goed mogelijk toe te passen, heb ik een duidelijk beeld gekregen van de voor- en nadelen van het toepassen van Scrum. Helaas was er weinig ondersteuning vanuit de docenten, maar de meeste kennis was uit boeken en het internet te halen.

6.1.3

Reflectie Niels Hendriks

Werken binnen de groep Het werken binnen de groep is mij zeer goed bevallen. Doordat we aan het begin van het jaar zelf de groepen mochten samenstellen en een project opdracht mochten kiezen wist ik eigenlijk van te voren al dat het werken met de groep goed zou gaan. Natuurlijk zijn er altijd wel een paar geschillen, maar doordat de groep elkaar al 3 jaar kent en vaker met elkaar samen heeft gewerkt is dit geen probleem. Een van die verschillen was bijvoorbeeld dat sommige mensen in het begin structureel te laat kwamen. Hierop is dit besproken in de groep en is het daarna nog maar sporadisch voorgekomen. Verder zijn er geen noemenswaardige 27



problemen voorgevallen binnen het project. Wel is het voorgekomen dat er groepsleden in sommige weken minder uren hebben gedraaid wegens persoonlijke omstandigheden. De groep is hier zeer begripvol voor geweest. Werken met materiaal en faciliteiten Voor de uitvoer van het project is er door school een projectruimte beschikbaar gesteld. In deze projectruimte is voor totaal 6 groepen een werkplek ingericht met 3 ´ a 4 computers. Deze computers konden naar wens worden ingericht. Verder was er per groep een router beschikbaar voor het delen van de internetverbinding. Het had nogal aardig wat voeten in aarde voordat er internet was. Er bleek bij iedereen veel onduidelijkheid over de procedure rondom het voor elkaar krijgen van toegang tot het internet. De werkruimte was verre van optimaal doordat deze gedeeld werd met 5 andere groepen. Doordat er nog 5 andere groepen in de ruimte zaten was het al gauw lawaaiig en rumoerig. Dit is niet prettig werken. Beter was het geweest wanneer je als projectgroep in een eigen ruimte had kunnen zitten. Dit zou de productiviteit ten goede komen. Daarnaast ging er op zonnige dagen met bewolking om de haverklap het zonnescherm omhoog en dan weer omlaag, iets wat zeer irritant is. Verder staat er midden in het lokaal een verrijdbaar whiteboard omdat er anders een tekort zou zijn aan scrumboards. Het verrijdbare whiteboard staat gigantisch in de weg en maakt het zeer lastig om van en naar de werkplek te komen. Gedurende de uitvoer van het project is meerder malen de stroom uitgevallen in de projectruimte. Hierdoor hebben we vroegtijdig een werkdag voor gezien moeten houden. Het enige dat dan nog gedaan kon worden thuis is het bijwerken van documentatie. Project en Implementatie De uitvoering van dit project werd gedaan volgens de projectmanagementmethode Scrum en alle code werd geschreven volgens de princiepes van Extreme Programming in combinatie met Test Driven Development. Het werken volgens Scrum is mij zeer goed bevallen, beter dan het werken volgens TSP. Dit komt doordat er minder druk is op de documentatie en er iteratief wordt gewerkt. Hierdoor is steeds voor iedereen duidelijk wat er in een iteratie gerealiseerd gaat worden. Het scrumboard maakt taken die daarvoor uitgevoerd moeten worden zeer inzichtelijk en overzichtelijk. Het scrumboard is een laagdrempelige manier voor het bijhouden van de voortgang. Een ander aspect van Scrum zijn de daily-standup meetings. Deze meetings zouden aan het begin van elke dag gehouden moeten worden. Deze meetings zijn ook door onze groep gehouden, maar niet elke dag zoals het eigenlijk hoort. Dit komt eigenlijk meer doordat er soms nogal grote taken waren waar mensen meerder dagen mee bezig konden zijn. Indien er problemen optraden bij het uitvoeren van zo’n langdurige taak werd er besloten tot een daily-standup meeting.

28



Het programmeren volgens eXtreme Programming is mij ook zeer goed bevallen. In het begin leek het er op dat het nogal omslachtig is om op die manier code te schrijven, maar naar verloop van tijd ben ik het nut er van in gaan zien. Zo worden er minder snel denkfouten in de code gemaakt doordat er 2 mensen mee bezig zijn. De een kan de ander controleren en wijzen op mogelijke fouten. Het programmeren in pairs heeft ook nog een ander voordeel, namelijk kennisoverdracht. Zo heeft de een bijvoorbeeld meer ervaring met programmeren door bijvoorbeeld zijn bijbaan of door het actief er mee bezig zijn in de vrije-tijd. In tegenstelling tot Siet en Matthijs weet ik eigenlijk niet bijzonder veel. Het werken in pairs met hun heeft mij dat duidelijk gemaakt en aan het denken gezet. Misschien dat ik me toch eens meer in dat soort zaken moet gaan verdiepen. Persoonlijk Opleidingsplan Aan het begin van het specialisatie semester is er door mij een POP opgesteld. Door aan het einde van het semester nog eens kritisch naar het POP te kijken kan ik zien of de leerdoelen die zijn gesteld ook daadwerkelijk gehaald zijn. De leerdoelen die ik voor mijzelf heb opgesteld aan het begin van het semester zijn: • Ervaren van de projectmanagementmethode Scrum • Ervaring opdoen met eXtreme Programming en Test Driven Development • Inrichten van een (goede) projectomgeving • Kennismaken met andere programmeertalen • Java kennis opfrissen • Ervaring opdoen met andere besturingssystemen Scrum Het eerste leerdoel dat ik mijzelf heb gesteld is het werken volgens de projectmanagementmethode Scrum. Hier heb ik voor gekozen omdat het verplicht was deze projectmethode tijdens de uitvoering van het project te gebruiken. Deze methode was voor mij totaal nieuw. Ik was dan ook zeer benieuwd hoe deze methode zou uitpakken in de praktijk. Aan het begin van het semester is er een lezing over geweest waarin uitgelegd werd wat de principes van deze methode zijn. Aan het einde van het semester, en dus ook het project, kan ik zeggen dat dit leerdoel door mij is behaald. XP en Test Driven Development Een ander aspect dat om de hoek kwam kijken tijdens het project is het agile ontwikkelen van software via eXtreme Programming en Test Driven Development. Gedurende het project is praktisch alle code geschreven in pairs, zoals XP dat voorschrijft. Aan het begin is er JUnit ge¨ınstalleerd. JUnit is een tool voor Test Driven Development met Java. Door de gehele groep is er voor gekozen om Test Driven Development verder te laten voor wat het is. Dit zal toegelicht worden in

29



de groepsreflectie. Het blijkt dus dat het leerdoel om ervaring op te doen eXtreme Programming is behaald, het leerdoel voor het ervaren van Test Driven Development daarentegen is slechts in beperkte mate behaald. Inrichten projectomgeving Voordat er ook maar een regel code of verslag geschreven kon worden was het noodzakelijk om eerste een projectomgeving in te richten. Door het inrichten van de projectomgeving, zoals beschreven staat in de sectie ”Werken met materiaal en faciliteiten”, is het leerdoel voor het inrichten van een projectomgeving behaald. Kennismaken met andere programmeertalen Het kennismaken met andere programmeertalen is een zeer interessant leerdoel. Door het voor mijzelf als leerdoel verplicht ik mijzelf min of meer tot het verdiepen in andere programmeertalen dan de programmeertalen die wel op school hebben gehad (Java, C en C++). Tijdens het project kwam er een uitgelezen kans aan bod namelijk het aanpassen van de urenregistratie systeem genaamd TimeTrackr. TimeTrackr is een webapplicatie geschreven door Matthijs Langenberg en wordt door onze groep gebruikt voor het bijhouden van de uren. De begeleidende docenten vonden de applicatie echter niet toereikend genoeg. Voordat het ”goedgekeurd”zou worden als urenverantwoording, diende er eerst nog wat aanpassingen gemaakt te worden. Een van de aanpassingen was het scheiden van de uren waardoor er een overzicht ontstaat per bestede tijd per module. De TimeTrackr applicatie is geschreven met Ruby on Rails, een programmeertaal die voor mij totaal onbekend is. Aan het begin van het project heb ik samen met Matthijs een programmeerpair gevormd om er achter te komen hoe deze programmeertaal in elkaar steekt. Ruby on Rails is naar mijn mening een programmeertaal die snel te begrijpen is en een programmeur in staat stelt zeer overzichtelijke code te schrijven. Al met al kan ik zeggen dat dit leerdoel is behaald. Ervaring opdoen met andere besturingssystemen Als besturingssysteem voor de vm7700 werd aangeraden om de Etch distibutie van Debian te installeren. Het lectoraat heeft hiervoor een linux expert ingehuurd die een kernelpatch heeft geschreven met daarin alle benodigde drivers. Dit is voor mij de aanleiding geweest om ervaring op te doen met andere besturingssystemen als leerdoel te stellen. Naast de Debian distributie voor de vm7700 is er op de continuousbuilserver ook Debian ge¨ınstalleerd. Het Linux besturingssysteem is voor mij een onbekend gebied. Op school hebben we er mee moeten werken tijdens de practicum uren van de Java modules. Veel verder dan werken met de grafische interface is het nooit gekomen, vandaar dit leerdoel. Zo aan het einde van het project kan ik stellen dat ik wel wat meer heb opgestoken van Linux. Zo is er tijdens het project gewerkt met een ssh connectie naar de server voor het op afstand beheren. Hierdoor is er geen grafische interface beschikbaar. Verder is er een script geschreven door Siet voor Linux die ik na enige uitleg begreep. Door dus te werken met Debian op de server heb ik kennis kunnen maken met een ander besturingssysteem. Naar mijn mening is dit leerdoel dan ook behaald.

30


6.1.4


Reflectie Wiebe van Schie

Ondanks het stroeve begin van het project is verder goed verlopen. Wel zijn er een aantal aandachtspunten die nog verder zal uitlichten in verschillende onderdelen. Werken binnen de groep Binnen de groep liep het in het algemeen goed. We zijn al bekend met elkaar wat dus geen problemen opleverde. Wel kwam het voor dat er mensen regelmatig te laat kwamen en dit is vervolgens besproken, waarna dit in geringe mate nog voorkwam. Werken met matriaal en faciliteiten De werkruimte voor dit project is zeer storend. In deze ruimte zijn 6 groepen aan het werk waarbij 50% bezig met spelletjes spelen of muziek luisteren. Dit is zeer storend en zorgt ervoor dat de productiviteit veel lager komt te liggen. De te gebruiken nodes waren ook niet helemaal passend voor het project. De mini-pc’s konden niet correct op de schermen geschroefd worden en zitten nu met slechts één schroef vast. Ook is de hardware niet passend voor dit project. Filmpjes afspelen onder linux is niet mogelijk door het gebrek aan een goede driver. Daarnaast worden de nodes ook te warm en moeten ze om dit tegen te gaan flink terug geklokt worden. Ook leverde het bestellen van sensoren problemen op. Toen we een werkende sensor hadden en er meerdere bij wilde bestellen bleek ook nog de levertijd op 8 weken te staan. Hierdoor hebben we nu 1 sensor voor de vier schermen die we hebben staan. Dit ontbreken van de sensoren hadden we kunnen voorkomen door eerst bezig te gaan met de sensoren. Dit had dan wel in zo’n vroeg stadium moeten gebeuren dat er verder nog geen basis zou zijn op dat moment. Project en implementatie Bij dit project hebben we voor het eerst gewerkt met scrum/xp. Zelf vind ik dit een prettige manier om te werken omdat je telkens richting een product werkt en niet op het eind pas een product hebt. Ook ben je meer gericht op wat er op dat moment moet gebeuren en niet op het totale eindproduct. De daily stand-up meeting was ook een onderdeel van Scrum. Deze hebben we niet elke dag uitgevoerd omdat op sommige momenten de teamleden allemaal bezig waren aan een taak waarbij niet overlegd hoefde te worden. Ook waren er op die momenten geen problemen die overlegd hoefde te worden. Het werken volgens xp was ook een nieuwe ervaring. Dit blijkt erg leerzaam te zijn doordat de kennis van een ander overgedragen wordt aan jou. Ook kan die andere persoon van jou leren. Hiernaast zorgt het er ook voor dat er minder fouten in de code zitten. Woorden die fout zijn geschreven vallen de ander op. Ook aanpassingen binnen het model kunnen worden vergeten. De xp-partner die erbij zit kan dit ook opvallen en dit melden.

31



Persoonlijk Opleidingsplan Aan het begin hebben we een POP gemaakt voor dit project. Vanwege het gebrek aan ervaring met dit en de wijze waarop mijn POP is becommentariseerd, had ik wel verwacht dat hierover nog uitvoerig feedback zou komen. Ik vind het gezien het gebrek aan kwaliteit van mijn POP jammer dat ik hiervoor geen tips of aanwijzingen heb gehad om dit een volgende keer beter te doen. De onderdelen die ik had genoemd in mijn POP waren als volgt. Scrum/xp Het werken met scrum/xp had ik als onderdeel in mijn POP staan. Ik heb me hier ook mee bezig gehouden. Niet alleen als teamlid maar ook actief tijdens het bepalen van de sprintlog. Hierbij ben ik bezig geweest met het definiëren van de stories met de storypoints. Hierbij heb ik geprobeerd iedereen aandachtig te houden. Doordat we minder snel afdaalden waren we ook sneller klaar met het bepalen van de stories en kon er ook goed gediscussieerd worden over de stories. Linux Omdat ik geen ervaring met linux en bij dit project een onderdeel linux aanwezig is leek mij dit een ideale mogelijkheid om wat ervaring op te doen met linux. Ik heb bij dit project dan ook meegeholpen bij het opzetten van de continous build server. Ook bij het maken van het continousbuild script heb ik meegewerkt. Hierdoor heb ik wel wat basiskennis van linux opgedaan. Test driven development Met test driven development hebben we geprobeerd te starten. Maar door gebrek aan kennis hierover bleek dit niet uit te voeren.

6.1.5

Reflectie Siet Toorman

Het project is in mijn ogen redelijk goed verlopen met enkele kleine uitzonderingen. Technisch zijn we enkele problemen tegengekomen, maar ook met de organisatie en het materiaal ging niet alles altijd op rolletjes. Ik zal de verschillende onderdelen uitlichten, inclusief een reflectie van het POP dat aan het begin van het project opgesteld is. Werken binnen de groep De groep is goed op elkaar afgestemd. Iedereen is goed bekend met elkaar en daardoor hebben er zich nagenoeg geen persoonlijke problemen voorgedaan. Er is enige frustratie geweest over het op tijd arriveren maar dat is goed opgelost. Meer hierover in de groepsreflectie. Werken met materiaal en faciliteiten De faciliteiten, de werkruimte, is zwaar onder de maat. Het betreft een groot lokaal waar 6 groepen van 5 man tegelijk behoren te werken. Dit gaat absoluut

32



niet goed aangezien het onmogelijk is om enige vorm van stilte te creeren. Er is altijd muziek of geluid van computerspelletjes aanwezig. Daarnaast is het lokaal zeer warm en heeft het zonnescherm een defect waardoor deze voortdurend (met de nodige herrie) open en dicht gaat. Het materiaal dat we verplicht moesten gebruiken, bijvoorbeeld de mini-pc nodes is onzorgvuldig uitgezocht. Deze werken niet naar behoren waardoor ze te warm en instabiel zijn. Ook is er vrijwel geen driver ondersteuning beschikbaar voor een ander OS dan Windows. Het is zeer verbazingwekkend dat er niet eerst een node grondig getest is voordat er besloten is deze massaal in te kopen voor dit project. De frames voor de schermen zijn helemaal niet op tijd aangeleverd, die zullen pas in September opgezet kunnen worden. Dat duidt op slechte organisatie of inkoopbeleid van Saxion. Project en Implementatie Voor het project gebruikten we de scrum/xp ontwikkelmethode. Dit houdt in dat we op een agile manier werken, bij voorkeur met pair-programming. In de practijk is dit redelijk goed gelukt. Er is veel (maar niet altijd) met pairprogramming gewerkt. Dit bevalt mij persoonlijk goed. Hoewel het niet erg productief is (Je werkt immers met twee mensen aan code die ook door 1 persoon geschreven kan worden) is het wel leerzaam en voorkomt het fouten. Ook zorgt het ervoor dat er een beter design gebruikt wordt. Scrum zegt ook dat er een ’daily standup meeting’ behoort te zijn. Deze hebben we gedaan, zij het niet elke dag. Als iedereen al werk heeft is het niet altijd nuttig om daar tijd aan te besteden. Er zijn immers nog openstaande taken. Tijdens het ontwikkelen door de dag heen hebben we ook geregeld even een moment waarop we overleggen hoe we verder gaan. Dit is in feite ook een kleine standup meeting, alleen niet aan het begin van de dag. Persoonlijk Opleidingsplan Het Persoonlijk Opleidingsplan is opgesteld aan het begin van het project. Deze is door de begeleiders gecontroleerd maar hier hebben we helaas zeer weinig commentaar op gekregen. Als resultaat was het zeer onduidelijk of de POP documenten voldoende en/of bruikbaar waren. De punten die in mijn POP besproken zijn, heb ik in het project vrijwel allemaal kunnen verwerken. Ik heb gewerkt aan de opzet van een ambient systeem zonder single point of failure. Dit is bereikt met behulp van de Scrum/XP ontwikkelmethode waarbij er effectief vergaderd is. Twee punten uit mijn POP zijn niet compleet geslaagd. Namelijk het werken met testdriven development, alsmede de implementatie van de sensoren onder Debian linux. Testdriven development zijn we mee gestart maar bleek niet praktisch haalbaar. De sensoren zijn geimplementeerd onder Windows in plaats van Debian aangezien het systeem niet goed stabiel te krijgen was onder Linux. Beide punten zullen in het Team Ontwikkelingsplan (TOP) besproken worden.

33


6.1.6


Reflectie Job Vermeulen

Het was een erg leuk project om mee bezig te zijn, de opdracht was innovatief en uitdagend. Waar wel ik wel een beetje moeite mee heb is dat dit semester Realtime & Embedded Systems heet. Het systeem wat we hebben gemaakt heeft eigenlijk vrij weinig met Realtime dan wel Embedded te maken. Werken binnen de groep Binnen de groepen kennen we elkaar al 3 jaar, we weten dus ook best goed met elkaar om te gaan. Zo is er een goede sfeer, en is er op z’n tijd even plek voor een kort gesprek. De samenwerking liep dus prima. Werken met materiaal en faciliteiten De computers waar we op werkten waren prima, alleen het lokaal verschrikkelijk. De hitte was soms zo erg (ik zit bij het raam) dat ik er misselijk van werd. Een tweede probleem is het lawaai. Eigenlijk is er continu herrie om je heen. Vaak wordt het argument gebruikt, dan men er dan wat van moet zeggen. Na een paar dagen dat gedaan te hebben zonder resultaat, wordt dat ook wel eens vermoeiend. Dat kan toch niet bevorderlijk zijn voor de leerprestaties. De mini-pc’s voldoen eigenlijk niet aan hun specificaties, de warmte is de pc’s al snel te veel door gebrek aan actieve koeling. Gelukkig is het project nog steeds uitvoerbaar door de pc’s terug te klokken naar 400Mhz. En helaas draait er geen Linux op door gebrek aan drivers. Project en Implementatie Voor het eerst hebben we gewerkt met scrum/xp. Ik heb dit persoonlijk als een hele prettige manier van werken ervaren doordat er veel dynamischer gewerkt kan worden. In het begin was het wel even wennen, je weet alle termen nog niet zo goed en de manier van denken is ook anders. Ik vindt het erg prettig als je continu kan zien hoe het project er voorstaat. Het pair-programming vindt ik minder handig. Zelf heb ik er niet echt het geduld voor. Daarom roep ik liever even iemand als ik een probleem heb. Persoonlijk Opleiding plan Dit project wat de eerste keer dat ik een POP het opgesteld. De meeste punten zijn goed aanbod gekomen, hieronder zal ik ze bespreken. Linux beter leren kennen Ik wist vrij weinig van Linux, ik had graag wat meer ervaring op gedaan op de node’s, maar die draaien nu op Windows. Wel draaide de server Linux. Hier heb ik een aantal keren geprobeerd kleine wijzigen door te voeren. De ene keer ging dit beter dan de andere. Gelukkig weet Siet in verhouding vrij veel van Linux. En hij kon dan vaak een aanwijzing geven, of laten zien hoe het moet.

34



SVN op een correcte manier gebruiken Dit project hebben we eigenlijk alles via de SVN gedaan, zelfs de verslagen. Ik heb hier dus veel ervaring mee opgedaan. Ik moet zeggen dat het best beperkingen heeft, maar SVN gebruiken vindt ik erg handig. Scrum basis leren, en aanvoelen of dit voor mij persoonlijk een prettige manier van werken is Zoals ik hierboven ook heb aangegeven is Scrum/XP me in het algemeen goed bevallen. Ik zou het zeker weer gebruiken. Ambient sensoren leren kennen en kunnen toepassen op een correcte manier De sensoren zijn niet echt een succes verhaal. We hebben veel hardware problemen gehad met de sensor. Door de lessen van meneer van Leeuwen heb ik er een aantal leren kennen. Programmeer kennis verder uitbreiden Programmeren is natuurlijk in dit project veel aanbod gekomen, ook met pair-programming. Hierdoor heb ik zeker weer meer ervaring opgedaan met programmeren. Grenzen aan jezelf stellen wat betreft de grote van het project De grote van het project is niet te hoog voorgenomen, dit komt mede door het werken met Scrum. Dit hebben we dus goed ingeschat Leren omgaan met een opdrachtgever waarbij de opdracht ook afhangt van eigen inbreng Dit vond ik een erg leuk aspect van het project. Het zelf aankomen met ideeën voor het project maakt je ook meer betrokken met het resultaat. Ik denk dat we een nuttige bijdrage hebben geleverd bij het aandragen van ideeen.

35

Bibliografie [1] MIT Spotlight project Spotlight is an installation of 16 interactive portraits. Each portrait has a set of 9 ”temporal gestures- photographic-quality sequences of human gestures such as ”looking up”. The portraits are networked, and placed in a 4X4 layout. Zie http://web.media.mit.edu/~orit/spotlight.html voor meer informatie. [2] Een scherm met mini-pc wordt een node genoemd. Deze bestaat uit een VIA 7700 mini-pc gecombineerd met Samsung monitor. [3] Agile software development Agile-software-ontwikkeling is een conceptueel raamwerk voor het uitvoeren van software-ontwikkelingsprojecten als alternatief voor traditionele starre praktijken. Het Engelse woord agile betekent: behendig, lenig. Zie http://nl.wikipedia.org/wiki/Agile-software-ontwikkeling voor meer informatie. [4] Wiki De wiki maakt onderdeel uit van de Google Subversion hosting. Een wiki is een manier voor het online inzichtelijk maken van documentatie behorende bij een bepaald project. De wiki beschrijft de diverse functionele onderdelen van het programma. Zie http://code.google.com/p/rtes6b/wiki voor de Wiki van het project. [5] Daily standup meeting is het begin van een werkdag als men werkt volgens de Scrum methode, dit korte overleg duurt 15 min. Hierin wordt met iedereen besproken ”Wat heb je gedaan?, Wat ga je doen?, Welke problemen heb je?”. [6] J/Invoke 36


Bibliografie

With J/Invoke, Java programmers can call the Win32 API, or any exported function from a native DLL, with pure Java code. J/Invoke is far simpler to use than Java Native Interface (JNI), which requires you to write a specialized wrapper DLL using C/C++, and perform non-trivial data type conversions yourself. With J/Invoke, native functions can be invoked by simply annotating a native method and calling it from pure Java. Behind the scenes, J/Invoke manages the task of loading the specified DLL, automatically converting Java arguments to C arguments and invoking the target function in the DLL. http://www.jinvoke.com/about [7] J/Invoke demo pagina - http://www.jinvoke.com/demos [8] Java Native Interface - http://en.wikipedia.org/wiki/Java_Native_ Interface The Java Native Interface (JNI) is a programming framework that allows Java code running in the Java virtual machine (JVM) to call and be called[1] by native applications (programs specific to a hardware and operating system platform) and libraries written in other languages, such as C, C++ and assembly. [9] Java Virtual Machine - http://en.wikipedia.org/wiki/Java_Virtual_ Machine [10] Unittesting Unittesten is een methode om softwaremodulen of stukjes broncode (units) afzonderlijk te testen op een correcte werking. Bij unittesten zal voor iedere unit een test ontwikkeld worden, een unittest. Hierbij worden dan verschillende testcases doorlopen. Zie http://nl.wikipedia.org/wiki/Unittesten voor meer informatie. [11] Java Media Framework. Door Sun beschikbaar gesteld framework om media te kunnen spelen vanuit Java. [12] Live Http Headers. Firefox plugin om HTTP verkeer te sniffen. http:// livehttpheaders.mozdev.org/ [13] Broadcasten is het versturen van een bericht naar alle ip-adressen tegelijk. Om dit te doen moet een bericht naar het broadcast-adres (255.255.255.255) van de router gestuurd worden die vervolgens het bericht naar iedereen doorstuurd. [14] Beck, Kent. Test Driven Development: By Example. Addison-Wesley Professional, 2002.

37


Bibliografie

[15] Allen, David. Getting Things Done: The Art of Stress-Free Productivity. Penguin, 2002. [16] Beck, Kent. Extreme Programming Explained: Embrace Change. Addison-Wesley Professional; 2 edition. 2004 [17] Kniberg, Hendrik. Scrum and XP from the Trenches. Lulu.com. 2007 [18] VideoLAN - VLC media player VLC media player is a highly portable multimedia player for various audio and video formats (MPEG-1, MPEG-2, MPEG4, DivX, mp3, ogg, ...) as well as DVDs, VCDs, and various streaming protocols. It can also be used as a server to stream in unicast or multicast in IPv4 or IPv6 on a high-bandwidth network. It doesn’t need any external codec or program to work. Zie http://www.videolan.org/ voor meer informatie over VLC media player.

38

Lijst van figuren 2.1 2.2

Project spotlight . . . . . . . . . . . . . . . . . . . . . . . . . . . Illustratie uit het blokboek ter verduidelijking van de projectomschrijving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

3.1 3.2 3.3

Proces verloop van Scrum . . . . . . . . . . . . . . . . . . . . . . Voorbeeldindeling van een Scrumboard . . . . . . . . . . . . . . . Error notificatie E-mail . . . . . . . . . . . . . . . . . . . . . . .

5 6 8

4.1 4.2 4.3 4.4 4.5

Continuous build proces Ip configuratie . . . . . Netwerkstructuur . . . . VideoLan media player . Network-event-generator

. . . . .

. . . . .

. . . . .

. . . . .

39

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

4

13 15 16 18 19

Bijlage A

Class Diagram

40

Bijlage B

Werkplek inrichting

41

Bijlage C

Opstartscript node

42

Bijlage D

POP Matthijs Langenberg Op de volgende pagina is mijn persoonlijk opleidings plan, die ik aan het begin van het project opgesteld heb te bekijken.

43

Persoonlijk Opleidingsplan van Matthijs Langenberg Ontwikkelingsdoel

Ontwikkelingsactiviteit

Gewenst resultaat

Planning

Benodigde ondersteuning en faciliteiten

Ervaring opdoen met Netwerk protocol ontwerpen en implementeren

Ontwerpen en implementeren van netwerk protocol.

Goed en snel werkend netwerprotocol

2e increment project

Standaard netwerkapparatuur

Effectief vergaderen.

Goed oppassen dat er niet afgedwaald wordt tijdens vergadering.

De gemiddelde vergadertijd verkorten.

Voor einde project.

Enkele boeken met tips, bijv. Getting Real.

Goed Test Driven kunnen ontwikkelen binnen een team.

Informatie winnen over TDD en zo goed mogelijk over de kwaliteit letten tijdens het uitvoeren. Teamgenoten zo goed mogelijk begeleiden.

Binnen het project team een opdracht volgens de TDDprincipes kunnen aanpakken.

Voor einde project.

Boeken over TDD, ondersteuning van docenten.

Leidinggevend kunnen zijn. Binnen een projectgroep de kar kunnen trekken.

Tijdens het project overzicht houden en taken kunnen delegeren. Communicatieve vaardigheden verbeteren.

Leiding kunnen geven aan een projectgroep.

Voor einde project.

Boeken over managment. Communicatietraining.

Ervaring opdoen met eXtreme Programming zodat ik er elementen uit kan gebruiken tijdens een project.

eXtreme Programming proberen te gebruiken tijdens het huidige project zodat ik een gevoel krijg over de bruikbaarheid van verschillende elementen.

Mijn kennis van de onderdelen binnen eXtreme Programming is groter. Ik kan advies geven over het gebruik van XP.

Voor einde project.

Boek: Extreme Programming Explained van Kent Beck.

Ervaring op doen met Scrum.

Gebruik maken van Scrum tijdens het huidige project.

Een goed idee hebben over wat Scrum inhoud, wat de voor- en nadelen zijn, en praktijk ervaring hebben met scrum.

Voor einde project.

Boeken over Scrum. Ondersteuning van docenten.

FunnyScreens. Saxion. Matthijs Langenberg (89870) Niels Hendriks (89713) Siet Toorman (91623) Job Vermeulen (90589) Wiebe van Schie (84313)

Recommend Documents