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

Transcriptie

1 Saxion FunnyScreens Auteurs: Matthijs Langenberg (89870) Niels Hendriks (89713) Siet Toorman (91623) Job Vermeulen (90589) Wiebe van Schie (84313) Begeleiders: Jan Stroet Ronald Tangelder Enschede, 27 juni 2008 Alle rechten voorbehouden aan Saxion te Enschede, opleiding Technische Informatica

2 Inhoudsopgave 1 Inleiding 1 2 Probleemanalyse Opdrachtomschrijving Schermenwand Autonoom systeem Interactie Interactie onderling Interactie met omgeving Requirements Systeembeschrijving Hulpmiddelen en methoden Scrum - XP Werkplekken Java Eclipse Continuous build server Google Subversion hosting Google Groups Google Calander Google Documents Kwaliteitsbewaking Testprocedures Oplevering Resultaat Development Continuous build script Node Besturingssysteem Opstart script Applicatie Netwerklaag I

3 EII6RTb - FunnyScreens Inhoudsopgave Tonen video s Network-event generator J/Invoke Conclusie en aanbevelingen Resultaat Aanbevelingen Reflectie Reflectie Reflectie Groep Reflectie Matthijs Langenberg Reflectie Niels Hendriks Reflectie Wiebe van Schie Reflectie Siet Toorman Reflectie Job Vermeulen A Class Diagram 40 B Werkplek inrichting 41 C Opstartscript node 42 D POP Matthijs Langenberg 43 II

4 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

5 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 figuur 2.1 voor een afbeelding van een Figuur 2.1: Project spotlight 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

6 EII6RTb - FunnyScreens Hoofdstuk 2. Probleemanalyse 2.3 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 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) 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

7 EII6RTb - FunnyScreens 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

8 Hoofdstuk 3 Systeembeschrijving 3.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

9 EII6RTb - FunnyScreens 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 manier de voortgang van de sprint. Aan Scrumboard Figuur 3.2: Voorbeeldindeling van een 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 pairs 2 geprogrammeerd dient te worden. 1 Voor verder uitleg over Google Documents zie Google Documents. 2 In tweetallen 6

10 EII6RTb - FunnyScreens Hoofdstuk 3. Systeembeschrijving 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 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 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 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 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

11 EII6RTb - FunnyScreens Hoofdstuk 3. Systeembeschrijving 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 naar de groepsleden gestuurd. In deze staat de inhoud van het logbestand. Figuur 3.3: Error notificatie 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

12 EII6RTb - FunnyScreens Hoofdstuk 3. Systeembeschrijving 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 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 adres beschikbaar. Alle s die naar dit 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 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 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

13 EII6RTb - FunnyScreens Hoofdstuk 3. Systeembeschrijving 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 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 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

14 EII6RTb - FunnyScreens Hoofdstuk 3. Systeembeschrijving 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

15 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 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 . 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 gebeurt via een proxy-script op een remote server. Dit is nodig aangezien het niet toegestaan is om een te versturen van het school netwerk. Met deze constructie wordt de -body, 12

16 EII6RTb - FunnyScreens 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 versturen. 4.2 Node In deze sectie zal de keuze voor het besturingssysteem, als mede de werking van het opstart script worden uitgelegd 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

17 EII6RTb - FunnyScreens Hoofdstuk 4. Resultaat 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 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 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

18 EII6RTb - FunnyScreens Hoofdstuk 4. Resultaat 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 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 Figuur 4.2: 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: 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

19 EII6RTb - FunnyScreens Hoofdstuk 4. Resultaat 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 we gekozen voor UDP. In de applicatie maken we 2 sockets aan, een server-socket en en socket om te ontvangen. Deze sockets koppelen we los van de applicatie door middel van Queues. De berichten die zijn ontvangen worden eerst in de queue gestopt alvorens NetworkHandler SendQueue : Queue ReceiveQueue : Queue NetworkSender NetworkReceiver Figuur 4.3: Netwerkstructuur 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

20 EII6RTb - FunnyScreens Hoofdstuk 4. Resultaat Het binnengekomen bericht is van het type NodeMessage. In deze Node- Message 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 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

21 EII6RTb - FunnyScreens Hoofdstuk 4. Resultaat 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

22 EII6RTb - FunnyScreens Hoofdstuk 4. Resultaat 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 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. Deze applicatie gebruikt het netwerkgedeelte van de eigenlijke applicatie met een GUI er omheen. Figuur 4.5: Network-event-generator 19

23 EII6RTb - FunnyScreens Hoofdstuk 4. Resultaat 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 hook 1 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

24 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

25 EII6RTb - FunnyScreens 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

26 Hoofdstuk 6 Reflectie 6.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 TOP 1 staan besproken. 1 afkorting voor als Team OpleidingsPlan 23

27 EII6RTb - FunnyScreens 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

28 EII6RTb - FunnyScreens Hoofdstuk 6. Reflectie 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 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 CD- ROM 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

29 EII6RTb - FunnyScreens Hoofdstuk 6. Reflectie 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 opgesteld 2. 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 Real 3 kunnen halen. Vooral het hoofdstuk 4 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