TU Delft Library Bachelor project - IN3405
Eindverslag
Auteurs: Tom Schenkels Franklin Snellink Erik van der Veen Hugo van der Wijst
1509349 1509365 1509381 1516493
Commissie: Jessica van den Doel Marjolijn Kuyper Gerwin de Haan Peter van Nieuwenhuizen
Opdrachtgever Opdrachtgever Begeleider Co¨ordinator
Faculteit EWI - TU Delft 25 juni 2011
Voorwoord In de afgelopen drie maanden hebben we voor ons Bsc eindproject gespeeld met de Microsoft Surface. Tijdens dit project hebben we niet alleen een product opgeleverd, ook kwamen we te staan voor andere uitdagingen. Wat is realitisch als doelstelling binnen de periode van drie maanden? Hoe kunnen we de kennis die we opdoen tijdens het project overdragen? En de grootste uitdaging, hoe noem je die tafel?! Touch-table, interactive table, servicetafel, Surface, Microsoft Surface, Surface tafel, multi-touch tafel, Microsoft Surface tafel, we zijn er nog steeds niet uit. Dat neemt niet weg dat het een leuk project is geweest en we trots zijn op de Stay In Touch applicatie als product. We willen de volgende mensen bedanken voor hun inzet en begeleiding tijdens het project. • Jessica van den Doel voor het zijn van een goede opdrachtgever, het meedenken, het meedoen aan onze ontwikkelmethode en de creatieve test input. • Marjolijn Kuyper voor het inspringen als technisch opdrachtgever, de nuttige feedback, de communicatie binnen de Library en de nieuwe inzichten betreft sorteertechnieken. • Gerwin de Haan voor de begeleiding vanuit de faculteit, de tussentijdse feedback over de applicatie en adviezen. • De mensen van het Library Learning Centre en Shared Service Centre ICT voor hun bijdrage.
1
Samenvatting De TU Delft Library heeft twee Microsoft Surface systemen staan. Tot nu toe worden deze nog zeer weinig gebruikt omdat er nog geen interessante applicaties op staan. Daarom heeft de Library samen met EWI een opdracht uitgeschreven voor een Bsc project, zodat er interessante applicaties kunnen worden ontwikkeld en de tafel meer wordt gebruikt. Bij deze opdracht werd dus een applicatie verwacht met uitgebreide documentatie zodat de Library er verder mee kan werken. De opdracht hebben we aangepakt middels de Scrum ontwikkelmethode. Deze ontwikkelmethode helpt bij de kwaliteitswaarborging doordat het gedane werk elke twee weken wordt getoond aan de Product Owners, die dan meteen feedback kunnen leveren. Ook het versiebeheersysteem Git en de methode van test-driven development heeft bijgedragen aan de kwaliteit van het product. Ten slotte hebben we het product overgedragen aan de medewerkers van de TU Delft Library. Aan het eind van het project is als product opgeleverd; een module om feeds te beheren, een document voor beginnende Surface-ontwikkelaars en een applicatie om nieuwsberichten op een interactieve wijze op de tafel te lezen. De applicatie is opgeleverd inclusief een handleiding voor de configuratie en het onderhoud. Er is veel aandacht besteed aan de kwaliteit en robuustheid van de software. Zonder internet blijft de applicatie nuttig, bij problemen schrijft hij automatisch meldingen weg en de applicatie is zeer makkelijk te beheren. Daarnaast hebben we tijdens ons project gewerkt met een RFIDlezer en de personendatabase van de TU Delft. Kennis die wij hierbij hebben opgedaan is gedocumenteerd. Tot slot hebben wij enkele adviezen opgeschreven. Zo ontdekten wij na gebruikerstests dat de bediening via de filterknoppen niet optimaal is. Daarnaast denken we dat het weergeven van logo’s bij nieuwsberichten goed zal werken ter herkenning van de nieuwsbron. En voor het beheer zou het nuttig zijn als het configuratiebestand kan worden aangepast middels een beheerapplicatie.
2
Verklarende woordenlijst Agile-software-ontwikkeling. Een ‘behendige’ manier van software-ontwikkelen. Waarmee wordt bedoeld dat van de conventionele fases wordt afgeweken. Backlog. Er zijn twee backlogs, een sprint backlog en een product backlog. In de sprint backlog staan de doelen van de sprint en de product backlog is een verzameling van alle doelen over het gehele project. Caching. Het tijdelijk opslaan van gegevens, zodat deze sneller toegankelijk zijn. Maakt het tevens mogelijk de applicatie offline te gebruiken. Daily Meeting. Staande vergadering aan het begin van elke dag. De gedane taken van de vorige dag en de taken van de huidige dag worden besproken. Git. Een gedistribueerd versiebeheersysteem. Product Owner. De verantwoordelijke voor het opstellen van de Product Backlog en het representeren van de wensen van de opdrachtgevers, in ons geval Jessica van den Doel en Marjolijn Kuyper. RFID. Radio frequency identification, het identificeren met radiogolven. Een technologie om van een afstand informatie af te lezen van zogenaamde RFID-tags. RSS-feed. Een alternatieve, versimpelde weergave van online inhoud in het Really Simple Syndication (RSS) formaat. Wordt vaak aangeboden door online nieuwsbronnen. Scrum. Een vorm van agile-software-ontwikkeling. ScrumMaster. De verantwoordelijke voor het Scrum proces, in ons geval elke sprint een ander iemand uit het Team. Scrum Team. Product Owner, ScrumMaster en Team. Sprint. Een ontwikkelperiode van twee tot vier weken. Sprint Planning Meeting. Een vergadering waarin de doelen voor de sprint worden geselecteerd, hierbij is het hele Scrum team aanwezig. Sprint Retrospective. Een terugblik van het team op de afgelopen sprint, uitkomsten van deze vergadering worden meegenomen in de daarop volgende sprints. Sprint Review Meeting. Een vergadering waarin wordt terug gekeken op de afgelopen sprint. Het gedane werk wordt getoond aan de Product Owner, hierbij is het hele Scrum team aanwezig en alle ge¨ınteresseerden. SVN. Een versiebeheersysteem. Team. Het team dat het product ontwikkelt. User story. Een specifieke vorm waarin een doel wordt opgeschreven in de backlog. Als [actor] wil ik [doel/verlangen] zodat [voordeel]. XML. Extensible Markup Language, een gestructureerd formaat waarin gegevens in hi¨erarchische vorm kunnen worden weergeven als platte tekst.
3
Inhoudsopgave Voorwoord
1
Samenvatting
2
Verklarende woordenlijst
3
1 Inleiding 1.1 Achtergrond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Opdracht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 7 7 7
2 Proces 2.1 Scrum . . . . . . . . . . . . . . 2.1.1 Sprint 1 . . . . . . . . . 2.1.2 Sprint 2 . . . . . . . . . 2.1.3 Sprint 3 . . . . . . . . . 2.1.4 Sprint 4 . . . . . . . . . 2.2 Kwaliteitswaarborging . . . . . 2.2.1 Versiebeheersysteem . . 2.2.2 Documentatie . . . . . . 2.2.3 Test-driven development 2.3 Overdracht . . . . . . . . . . . 3 Productomschrijving 3.1 Highlights . . . . . . . . . . . 3.1.1 Content Stay in Touch 3.1.2 Caching . . . . . . . . 3.1.3 Pollen . . . . . . . . . 3.1.4 Ontwerppatronen . . . 3.2 Kwaliteit . . . . . . . . . . . 3.3 Kennis . . . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
10 10 10 10 11 12 14 14 15 15 15
. . . . . . . . . . . . . . volledig configureerbaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
16 16 16 16 17 17 17 19
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
4 Conclusie en aanbevelingen 4.1 Conclusie . . . . . . . . . . . . . 4.2 Aanbevelingen . . . . . . . . . . 4.2.1 Gedrag filterknoppen . . . 4.2.2 Logo’s van nieuwsbronnen 4.2.3 Specifieke bron selectie . . 4.2.4 Beheerapplicatie . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
20 20 20 20 21 21 21
5 Evaluatie 5.1 Agile . . . . . . . . . . . . 5.2 Scrum . . . . . . . . . . . 5.3 Test-Driven Development 5.4 Documenteren . . . . . . 5.5 Versiebeheer met Git . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
22 22 22 23 23 24
. . . . .
. . . . .
. . . . .
. . . . .
4
A Ori¨ entatieverslag A.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . A.2 Probleemomschrijving . . . . . . . . . . . . . . . A.3 Ontwikkelmethodiek . . . . . . . . . . . . . . . . A.3.1 Waarom kiezen wij voor Scrum . . . . . . A.3.2 Scrum in de praktijk . . . . . . . . . . . . A.3.3 Nadelen . . . . . . . . . . . . . . . . . . . A.3.4 Scrum in ons project . . . . . . . . . . . . A.4 Technische features van de Surface . . . . . . . . A.4.1 Infraroodcamera’s . . . . . . . . . . . . . A.4.2 RFID lezer . . . . . . . . . . . . . . . . . A.5 Hulpmiddelen . . . . . . . . . . . . . . . . . . . . A.5.1 IDE . . . . . . . . . . . . . . . . . . . . . A.5.2 Testing framework . . . . . . . . . . . . . A.5.3 SDK . . . . . . . . . . . . . . . . . . . . . A.5.4 Versie beheer systeem . . . . . . . . . . . A.5.5 Issue tracking systeem . . . . . . . . . . . A.6 Bestaande systemen en applicaties . . . . . . . . A.6.1 Project van Industrieel Ontwerpers . . . . A.6.2 Applicatie van de Hogeschool Rotterdam A.6.3 Cultural Heritage bij DOK . . . . . . . . A.7 Multitouch Displays . . . . . . . . . . . . . . . . A.8 Een woord van afsluiting . . . . . . . . . . . . . . Referenties . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
25 25 25 25 25 26 27 27 27 27 29 30 30 30 30 30 31 31 32 32 32 32 33 33
B Plan van Aanpak B.1 Inleiding . . . . . . . . . . . . . B.2 Projectopdracht . . . . . . . . . B.2.1 Projectomgeving . . . . B.2.2 Doelstelling project . . . B.2.3 Opdrachtformulering . . B.2.4 Op te leveren producten B.2.5 Eisen en beperkingen . . B.3 Aanpak . . . . . . . . . . . . . B.3.1 Methodiek . . . . . . . . B.3.2 Technieken . . . . . . . B.3.3 Werkzaamheden . . . . B.4 Projectinrichting . . . . . . . . B.4.1 Betrokkenen . . . . . . B.4.2 Informatie . . . . . . . . B.4.3 Faciliteiten . . . . . . . B.5 Planning . . . . . . . . . . . . . B.6 Kwaliteitswaarborging . . . . . B.6.1 Productkwaliteit . . . . B.6.2 Proceskwaliteit . . . . . Referenties . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
35 35 35 35 36 36 36 36 36 36 37 37 37 37 37 37 37 38 38 38 38
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . en diensten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
C Getting Started C.1 Inleiding . . . . . . . . . . . . . . . . . . . . C.2 Voorbereidingen . . . . . . . . . . . . . . . C.3 Een applicatie ontwikkelen . . . . . . . . . . C.4 Een applicatie deployen . . . . . . . . . . . C.4.1 Attract en Single-Application Mode C.5 Internet in de TU-omgeving . . . . . . . . . C.5.1 Draadloze verbinding . . . . . . . . . C.5.2 Ethernet verbinding . . . . . . . . . C.6 Externe databronnen gebruiken . . . . . . . C.6.1 Nieuwsberichten via RSS . . . . . . C.6.2 TU Delft Personendatabase . . . . . C.7 De RFID lezer gebruiken . . . . . . . . . . . C.7.1 De kaartlezer gebruiken . . . . . . . C.7.2 De Campuscard . . . . . . . . . . . . Referenties . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
39 39 39 39 40 40 40 40 41 41 41 42 42 42 42 43
D Architectuur NewsFeed D.1 Inleiding . . . . . . . . . . . . . D.2 Datastructuren . . . . . . . . . D.2.1 INewsFeed . . . . . . . D.2.2 Feeds . . . . . . . . . . D.2.3 Decorators . . . . . . . D.2.4 Aggregators . . . . . . . D.2.5 Image selectors . . . . . D.3 Opslaan en opvragen van feeds D.4 Configuratie . . . . . . . . . . . D.4.1 Configuratiebestand . . D.4.2 Factory . . . . . . . . . D.5 Foutdetectie bij inladen feeds .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
44 44 44 44 45 45 47 47 48 48 48 48 50
E Architectuur Stay in Touch E.1 Algemeen . . . . . . . . . E.1.1 Architectuur . . . E.1.2 User Interface . . . E.1.3 Logging . . . . . . E.2 Nieuwsberichten bekijken E.2.1 Data architectuur E.2.2 User Interface . . . E.2.3 Design . . . . . . . E.3 Nieuws filteren . . . . . . E.3.1 Data architectuur E.3.2 User Interface . . . E.3.3 Design . . . . . . . Referenties . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
51 51 51 51 51 52 52 52 53 55 55 55 56 57
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
6
1 Inleiding In dit hoofdstuk wordt kort de opdracht besproken die wij hebben gedaan. Eerst zal de achtergrond van de opdracht worden behandeld, waarna de uiteindelijke requirements van de applicatie aan bod komen.
1.1
Achtergrond
De TU Delft Library heeft onlangs onderzoek gedaan naar de taken die zij uitvoerd. Er is toen besloten om het Library Learning Centre op te zetten, waarbij de bibliotheek ook een plek wordt om te leren en studeren. Voor dit initiatief zijn twee Microsoft Surface systemen gekocht. Op deze tafels kunnen meerdere personen tegelijkertijd werken met applicaties via een multitouch interface. Op de begane grond van de TU Delft Library is een van de tafels beschikbaar voor studenten. Op het moment wordt deze tafel echter niet veel gebruikt.
1.2
Opdracht
Om het gebruik van de Surface systemen te stimuleren is ons opgedragen om een applicatie te ontwikkelen voor de Surface. Deze applicatie is gebaseerd op een ontwerp van een groep studenten van de faculteit Industri¨eel Ontwerpen. Het is de bedoeling dat de applicatie de tafels voor een grote doelgroep aantrekkelijk maakt. De applicatie, die wij Stay in Touch hebben genoemd, verandert de Surface in een soort digitale krantentafel. Op de tafel verschijnen diverse nieuwsartikelen, foto’s en strips. Deze kunnen worden gefilterd op taal en categorie. De berichten worden, door middel van RSS-feeds, uit verschillende, voor het publiek beschikbare bronnen gehaald.
1.3
Requirements
Bij de voor dit project gebruikte ontwikkelmethode, Scrum, is het ongebruikelijk om van te voren eisen te stellen aan de software. Vroeg requirements opstellen kan het ontwikkelproces vertragen en bemoeilijkt het wijzigen van verwachtingen. Ondanks dat er niet expliciet requirements zijn opgesteld, zijn deze wel degelijk impliciet benoemd. Deze requirements zijn aan het einde van het proces expliciet gemaakt en zijn als volgt: • Functionele eisen 1. De applicatie moet als enige applicatie op de Surface draaien. 2. Bij alle content op de tafel moet de bron zichtbaar zijn. 3. De gebruiker moet invloed kunnen uitoefenen op welke nieuwsberichten te zien zijn. 4. Nieuwsberichten moeten goed leesbaar zijn. • Niet-functionele eisen B.1 Kwaliteitseisen
7
Figuur 1.1: De Stay In Touch applicatie (a) Usability > Begrijpelijkheid: de applicatie moet begrijpelijk zijn en makkelijk in gebruik voor de doelgroep (studenten die tijdens hun studiepauze in de koffiehoek ontspanning zoeken). (b) Usability > Aantrekkelijkheid: de applicatie moet visueel en qua functionaliteit en aantrekkelijk zijn. (c) Usability > Leesbaarheid: de nieuwsberichten moeten goed leesbaar zijn. (d) Usability: het beheer van de applicatie moet eenvoudig zijn en niet te veel tijd kosten, ook als de applicatie op meerdere tafels draait. (e) Betrouwbaarheid > Fout tolerantie: de applicatie moet blijven functioneren als de internet verbinding verbroken wordt voor korte of langere tijd. (f) Betrouwbaarheid > Fout tolerantie: de applicatie moet afsluiten als ze incorrect geconfigureerd is en hiervan melding maken in haar applicatie log, zodat monitoring software de juiste beheerders kunnen alarmeren om actie te ondernemen. (g) Onderhoudbaarheid > Veranderbaarheid: het uitbreiden van de applicatie behoort relatief eenvoudig te kunnen. Een van de pijlers hiervoor is code die goed leesbaar is, ook voor mensen die het niet geschreven hebben. (h) Onderhoudbaarheid > Testbaarheid: bij het ontwikkelen van de applicatie moet test-driven gewerkt worden. (i) Onderhoudbaarheid > Analyseerbaarheid: voldoende documenteren van het ontwerp en de source code zodat andere ontwikkelaars het werk eenvoudig voort kunnen zetten. (j) Portability > Conformance: waar mogelijk en relevant gebruik maken van open standaarden en/of open source software. Het gebruik is een pr´e, maar geen must. 8
(k) Security: de applicatie mag geen ongeauthoriseerde toegang tot het internet bieden.De applicatie dient enkel af te sluiten als deze incorrect geconfigureerd is. B.2 Overige eisen (a) De applicatie moet ontwikkeld worden voor en ge¨ınstalleerd worden op de eerste generatie (1.0) Microsoft Surface 1.0 hardware. Aangezien het ontwikkelen van applicaties voor de Surface nieuw is voor de organisatie, wordt er ook gevraagd om extra documentatie over het ontwikkelen van applicaties voor dit platform. Daarnaast dient de architectuur van de applicatie duidelijk gedocumenteerd te zijn.
9
2 Proces 2.1
Scrum
Wij hebben ervoor gekozen om de ontwikkelmethodiek Scrum aan te houden tijdens het project, een agile ontwikkelmethode. Omdat we voorheen vooral werkten volgens het watervalmodel wilden we deze mogelijkheid gebruiken om ervaring op te doen met Scrum. Tijdens de eerste twee weken van het project, de ori¨entatieperiode, hebben we onderzoek gedaan naar Scrum. Voor meer informatie, zie appendix A.
2.1.1
Sprint 1
We zijn vroeg in het project al onze eerste sprint gestart, om zo bekend te raken met Scrum. Tijdens deze sprint hadden we slechts het ori¨entatieverslag als geplande taak staan. Deze weken hebben we kunnen wennen aan de daily meetings, maar toch vooral ook aan de werkomgeving. Er was nog geen sprint backlog opgesteld met de product owners en ook de meetings voelden nog wat vreemd aan. De eerste ‘echte’ sprint zou toch sprint 2 worden.
2.1.2
Sprint 2
Na de eerste semi-geslaagde sprint kunnen we nu echt aan de slag. De planning meeting verliep goed, Jessica en Marjolijn konden met post-its prima aangeven waar wij aan moeten gaan werken. Backlog User story 2.1 “Als student wil ik Delta nieuws zien zodat ik op de hoogte ben van ontwikkelingen” Deze story hebben we vrij snel geklaard omdat we gebruik konden maken van UI-elementen van Microsoft. Hiermee was tekst snel weer te geven als losse items die de gebruiker rond kan slepen, vergroten etc. We kwamen er echter wel achter dat de nieuwsfeed van de Delta lastig is voor ons omdat de feed maar weinig tekst bevat. Ook bedachten we ons dat plaatjes bij een item belangrijk zijn om de applicatie aantrekkelijk te maken. Daarom zijn we tijdens deze sprint voor andere feeds gegaan zoals Nu.nl, Nu Foto en NRC In Beeld. Er was wel wat tijd nodig voor het uitdenken van het weergeven van foto’s en video’s in items (zie appendix E). User story 2.2 “Als ontwikkelaar wil ik RSS feeds kunnen parsen zodat ik de inhoud overal binnen een applicatie kan gebruiken” Aan deze story hebben we best veel aandacht besteed om een mooi losstaand framework te verkrijgen (zie appendix D). Het framework kan RSS feeds weergeven in onze eigen generieke datastructuur. Het is echter ook mogelijk om bijvoorbeeld een Atom module toe te voegen zodat ook Atom feeds ingelezen kunnen worden. User story 2.3 “Als ontwikkelaar wil ik tekst, plaatjes en filmpjes in een item kunnen tonen” Het perfectioneren van een mooie lay-out heeft best wat moeite gekost. Daarnaast bleek het handig om aan de hand van de verkregen data een weergave te kiezen. Bij een grote foto kiest de applicatie er nu zelf voor om deze weer te geven met de tekst over de foto heen. Aan de weergave van filmpjes hebben we weinig gedaan, 10
aangezien daar minder goede bronnen voor zijn. Tevens zou het waarschijnlijk lastiger zijn omdat formaten misschien niet goed ondersteund worden. Retrospective Al in de eerste sprint hebben we Redmine (zie appendix A) gebruikt om bij te houden wie waaraan werkte. Aan het begin van deze sprint bleek het echter vrij lastig om de sprint backlog goed te vertalen naar dit systeem. Daarom zijn we het er tijdens deze sprint langzaam over eens geworden dat post-it’s ook voldoen als backlog, dit in plaats van Redmine. ‘Communication over Tools’, ook een prima keuze vanuit Agile-standpunt dus. Het bleek wel dat we in het begin van de sprint slechts een vaag idee hadden waar iedereen aan bezig was. Er was flink wat tijd besteed aan het proberen van verschillende dingen op de Surface. Uiteindelijk was het niet precies duidelijk wat de bijdrage aan de sprint was. Daarom willen we in sprint 3 meer post-it’s gebruiken om de taak aan te geven waar iemand aan werkt. De daily meetings zijn goed om te weten waar je als team staat, en de planning en review meeting gingen beiden erg goed. Tot nu toe zijn we dus vrij positief over Scrum.
2.1.3
Sprint 3
In de vorige sprint hebben we vooral gewerkt aan de architectuur van de applicatie. Qua userinterface hebben we een basis gemaakt waarbij we nog niet veel aandacht hebben besteed aan het design. Het design en de userinterface zijn onderwerpen waar de opdrachtgever aandacht voor wil in deze sprint. Daarnaast trad er in de review meeting tweemaal een foutmelding op in de applicatie, dit heeft de aanleiding gegeven voor de opdracht om foutmeldingen goed op te vangen en te verwerken. Backlog User story 3.1 “Als productmanager wil ik een bericht met duidelijke documentatie krijgen als een bron niet meer weergeven kan worden zodat ik iemand opdracht kan geven om de weergave te herstellen.” Deze story hebben we aangepakt door de opdracht te verdelen in het opvangen van niet werkende feeds in de code en het versturen van een notificatie naar de productmanager. De taak om de foute feeds op te vangen binnen de code verliep volgens planning. Het notificeren van de productmanager over een opgevangen fout ging niet erg soepel. Het idee was eerst om een e-mail te sturen met daarin informatie over de opgevangen foutmelding, hier is veel tijd in gaan zitten. Uiteindelijk bleek echter dat er binnen de TU Delft een applicatie beheer tool wordt gebruikt. Deze willen wij nu gaan gebruiken om de productmanager te informeren over opgetreden fouten. User story 3.2 “Als student wil ik dat de applicatie goed aanvoelt binnen de eerste minuut zodat ik vaker gebruik wil maken van de applicatie.” Een hele grote story waarbij veel komt kijken. Het uiterlijk van de nieuwsberichten met verschillende inhoud. Het maken van een filtermenu om het aanbod van nieuwsberichten en feeds in te richten naar eigen keuze, hieraan vooraf ging het testen van twee concepten door deze te paperprototypen. Het lokaal opslaan van nieuwberichten met hun foto’s zodat deze niet hoeven te worden gedownload tijdens het gebruik van de applicatie. De applicatie als standaard instellen op de
11
tafel, zodat deze actief is als een gebruiker aan de tafel gaat staan. Zorgen dat de applicatie niet vastloopt door onder andere fouten af te handelen. User story 3.3 “Als ontwikkelaar wil ik een RFID chip uitlezen en deze koppelen aan de studentenen medewerkersdatabase zodat ik deze informatie kan gebruiken in mijn applicatie” De opdrachtgever was bij deze story duidelijk dat het ging om een Proof of Concept. De opdracht was het uitzoeken of het mogelijk zou zijn zodat dit later gebruikt kan worden mocht het nodig zijn. Het uitlezen van de studentenpas met RFID kaart en het uitlezen van de database lukte beide, waarbij de uitkomst van het uitlezen van de pas kan worden gebruikt als input voor de database. Retrospective Uit sprint 2 kwam naar voren dat het fijn werkt met meer gedetailleerde opdrachten op postit’s, dit hebben we dan ook gedaan tijdens deze sprint. Uit de evaluatie van deze sprint bleek echter dat het tijdens het implementeren de grote hoeveelheid post-it’s geen toegevoegde waarde heeft. Wel is het handig om veel post-it’s te gebruiken tijdens het documenteren. Over het documenteren zijn we qua planning niet te vreden. Onze opdracht is om aan het eind van elke sprint documentatie op te leveren, maar deze schrijven we vaak pas tegen het einde. Ons streven is gedurende de sprint al te documenteren indien dit mogelijk is. In het algemeen zijn we nog steeds erg tevreden over hoe het gaat met Scrum, zeker na enige aanpassingen. Tijdens sprint 3 hebben we besloten om de stand-up in de ochtend anders in te delen, we beginnen met een ronde waarbij iedereen zegt was ze de vorige dag hebben gedaan, dit geeft ons een beter beeld van de huidige situatie. Vervolgens maken we nog een ronde met wat de taken zijn per persoon voor de komen de dag. Dit nemen we mee, naast de afname in gebruik van post-it’s, naar sprint 4.
2.1.4
Sprint 4
Sprint 4 is de laatste sprint van het project. In deze sprint hebben we ons gericht op het afmaken van de applicatie. We hebben daarbij aandacht besteed aan de gebruiks- en beheervriendelijkheid van de applicatie. Backlog User story 4.1 Applicatie events in Windows Event Log wegschrijven. Om het beheren van de applicatie te vereenvoudigen worden logs weggeschreven. Deze logs zullen later door een standaard beheerapplicatie worden uitgelezen en eventuele fouten zullen worden doorgegeven aan de beheerder. Er is gekozen om de logs weg te schrijven naar het Windows Event Log, aangezien dit de standaard functionaliteit is die uit te lezen is met de beheerapplicatie. Om eventuele veranderingen eenvoudiger te maken, is er ook een generieke interface gemaakt voor andere log klassen. User story 4.2 Configuratie bestand via http toegankelijk. Als de applicatie in de toekomst op meerdere tafels draait, wordt het veranderen van feeds en categorie¨en voor een beheerder onhandig, omdat deze alle tafels af moet gaan om de configuratie veranderen. Met de toegevoegde functie wordt het
12
configuratiebestand regelmatig van een server gedownload, zodat het veranderen van de configuratie zeer weinig tijd kost. De applicatie gebruikt een XML-bestand om de configuratie in op te slaan. In dit bestand staat nu ook het adres van het configuratiebestand op de server. Als de applicatie draait wordt periodiek het nieuwste configuratiebestand van de server gedownload en lokaal opgeslagen. Een nieuwe configuratie zal dan bij het opnieuw opstarten van de applicatie worden geladen. Deze oplossing heeft de volgende voordelen: • De locatie van het externe configuratiebestand staat in het configuratiebestand zelf. Als de URL veranderd moet worden, kan de configuratie een korte tijd op beide URL beschikbaar worden gemaakt, waarna de oude offline kan worden gehaald. • Doordat het configuratiebestand lokaal gecached wordt, zal het opstarten van de applicatie altijd snel gaan. Ook zal deze blijven functioneren als het internet niet werkt. Een nadeel is dat de propagatietijd van veranderingen groot is: veranderingen aan de configuratie worden pas doorgevoerd als de applicatie opnieuw wordt opgestart. User story 4.3 Werking van filters met gebruikers testen. De belangrijkste userinterface van de applicatie is, op de nieuwsberichten zelf na, het filtermenu. Om te onderzoeken of de werking van dit menu intu¨ıtief is, hebben we een aantal gebruikerstests gedaan. Uit deze tests blijkt dat de werking van de knoppen als erg onprettig wordt ervaren. Veel gebruikers zien het verschil niet tussen de disabled toestand en de enabled toestanden van knoppen. Er is daarom besloten om knoppen niet meer te disabelen. Verder blijkt de werking van de filters niet goed begrepen te worden door gebruikers. Nieuwsberichten moesten aan alle geselecteerde categorie¨en voldoen voordat ze werden weergeven. Na gebruikerstest is besloten dat een bericht in slechts ´e´en geselecteerde categorie hoeft te zitten. User story 4.4 Stay in Touch als start applicatie instellen. Aangezien de library nog geen andere applicaties heeft ontwikkeld naast de huidige, dient deze als enige applicatie ingesteld te staan. De verschillende mogelijkheden hiervoor moeten worden gedocumenteerd. Er is besloten om de tafel in Single App Mode te draaien. Dit betekent dat er slechts ´e´en applicatie op de tafel draait, en dat het niet mogelijk is om in het menu te komen. User story 4.5 Scrollbar bij lange berichten in foto’s. Om gebruikers feedback te geven dat er meer tekst zit bij een foto dan kan worden weergegeven, is er waar nodig een scrollbar toegevoegd. User story 4.6 Vormgeving aantrekkelijker maken. De vormgeving is aantrekkelijker gemaakt door de hoeken van de nieuwsbericht af te ronden en subtiele kleuraccenten in tekstberichten aan te brengen. Berichten uit de zelfde bron hebben ook de zelfde kleur. 13
User story 4.7 Bugfix: zorg dat de categorie¨en werken. In de applicatie zat een fout waardoor berichten die niet aan de categorieselectie voldeden, toch werden weergegeven. Deze fout is opgelost. User story 4.8 Zoek naar extra bronnen. Om een diverser contentaanbod te hebben zijn een aantal nieuwe bronnen toegevoegd, waaronder: XKCD, Fokke & Sukke, National Geographic en Flickr. User story 4.9 Vernieuwen van berichten en verwijderen oude berichten. Vanuit de opdrachtgevers kwam de wens om duidelijk te maken hoe oud een nieuwsbericht is, bijvoorbeeld door oude nieuwsberichten te laten verkleuren. Door ons is besloten om dit niet op die manier te doen, maar om een relatieve tijdsaanduiding boven de feed te zetten. Dit wil zeggen dat de publicatietijd van berichten die minder dan twaalf uur oud zijn, wordt weergegeven in uren. Retrospective Aangezien bij de vorige sprint duidelijk werd dat veel post-it’s geen bijdrage leveren aan de productiviteit, hebben we deze sprint het aantal post-it’s weer terug gedrongen. Dit is als positief ervaren. Ondanks dat er veel bereikt is in de sprint, is er toch het gevoel geweest dat men niet zo productief is geweest als de afgelopen sprints. Dit komt doordat er vooral kleine dingen moesten worden gedaan. Ook moesten een aantal dingen worden geregeld, zoals internet en het verplaatsen van de tafel in de hal.
2.2
Kwaliteitswaarborging
Scrum helpt ons bij het waarborgen van de kwaliteit, omdat elke sprint een marktwaardig product moet worden opgeleverd. Deze wordt tijdens de sprint review getoond aan de product owners. Hierbij krijgen we gelijk feedback over het gedane werk en tijdens de sprint planning zien we ook waar de prioriteiten liggen van de opdrachtgevers. We hebben daarnaast nog andere methoden gebruikt om de kwaliteit van ons product en de kwaliteit van het proces te waarborgen.
2.2.1
Versiebeheersysteem
Na onderzoek in onze ori¨entatieperiode hebben we ervoor gekozen om Git als versiebeheersysteem te gebruiken. Normaal gebruiken we SVN binnen onze studie, maar na het afwegen van voor- en nadelen is de keuze gevallen op Git. Vooral omdat Git een gedistribueerd versiebeheersysteem (DVCS) is, wat betekent dat iedereen een eigen kopie van de repositories heeft. Meer redenen zijn te zien in het Ori¨entatieverslag, bijgesloten als appendix A. Tijdens het project hebben we de voordelen van Git gemerkt. Zeker de mogelijkheid om lokaal te branchen heeft geholpen, op die manier kun je zelf dingen proberen zonder dat andere er last van hebben. Als de branch vervolgens iets is voor de algemene applicatie, dan is het makkelijk te mergen. Het kostte echter wel tijd voordat iedereen Git in de vingers had, maar door ervaring van andere groepsleden heeft dit niet tot problemen geleid.
14
2.2.2
Documentatie
Elke sprint is er documentatie bijgehouden over wat er die sprint is gedaan. Zo zorgen we ervoor dat onze activiteiten zichtbaar zijn voor iedereen binnen het project. Ook helpt het ons met reflecteren op gedaan werk.
2.2.3
Test-driven development
Om de kwaliteit van het product te waarborgen ontwikkelen we volgens de methode van testdriven development. Voordat we de werkelijke functies implementeren schrijven we tests die de functionaliteit van de te implementeren code covered. Voordelen van deze aanpak hebben we vooral gemerkt toen we de code hebben ingericht naar het MVC ontwerppatroon.
2.3
Overdracht
Vanuit het Library Learning Center is aandacht besteed aan de overdracht van het project zodat de Stay in Touch applicatie over een tijd echt gebruikt gaat worden in de TU Library. Allereerst zal Marjolijn zorgen dat de applicatie adequaat gemonitord wordt (via de centrale monitoring van de TU) en dat het XML configuratiebestand makkelijk te bewerken is. Dan zal tegen het begin van het nieuwe studiejaar het personeel worden ge¨ınformeerd, waarna de applicatie aan de bezoekers gepresenteerd kan worden. Hans Meijerrathken (Productmanager binnen de TU Library) zal zich vervolgens over het product ontfermen.
15
3 Productomschrijving Tijdens het project hebben we verschillende producten opgeleverd welke nuttig kunnen zijn voor de TU Library. Newsfeed library. Een C# library die feeds inleest van het internet en ze omzet in een generiek formaat voor eenvoudig gebruik. Stay in Touch. Een applicatie voor de Microsoft Surface welke gebruik maakt van de Newsfeed library. Met behulp van deze applicatie kan de gebruiker nieuws lezen via de Surface. Stay in Touch applicatiehandleiding. Een beschrijving van de configuratie van de applicatie en het onderhoud daarvan. Getting Started document. Uitleg voor developers die applicaties willen ontwikkelen voor de Surface met verwijzingen naar handige websites.
3.1
Highlights
In deze sectie zullen we enkele van de meer interessante features uit ons project naar voren brengen.
3.1.1
Content Stay in Touch volledig configureerbaar
Omdat we samen met de Product Owners vastgesteld hebben dat het belangrijk is dat de inhoud van de applicatie simpel te wijzigen moet zijn, hebben we ervoor gekozen om dit op te lossen met een XML-configuratiebestand. Hiermee is het mogelijk om nieuwe content te selecteren, waarbij ook categorie¨en, taal en verschillende operaties op de feed aangegeven kunnen worden. Zo kunnen beheerders van de applicatie nieuwe bronnen snel toevoegen. Dit XML bestand kan van een externe locatie via een HTTP-request ingeladen worden. Dit maakt het weer een stap makkelijker voor een beheerder om het bestand te wijzigen, omdat het dan op een logische locatie staat en snel bereikbaar is. Ook is het bestand hiermee makkelijker bereikbaar voor een eventuele beheertool waarmee het XML bestand aangepast kan worden.
3.1.2
Caching
Tijdens het ontwikkelen van de Stay in Touch applicatie bleek het wenselijk om afbeeldingen op te slaan op de Surface zodra deze van het internet gedownload zijn. Hierdoor wordt de applicatie een stuk sneller, omdat grote bestanden niet steeds opnieuw gedownload hoeven te worden. Ook is de belasting van de internetverbinding hiermee een stuk lager. Tevens draait de applicatie nu ook door als er geen internetverbinding beschikbaar is, omdat de inhoud van de nieuwsberichten ook in de cache opgeslagen worden. Als bijkomend voordeel bleek dit zeer handig toen er op de productietafel geen internetverbinding verkregen kon worden, de cache van een andere omgeving kopi¨eren naar de productietafel en de applicatie kan toch content weergeven. Daarbij bleek deze functionaliteit verrassend mooi in te passen met het decorator ontwerppatroon zoals behandeld in 3.1.4. Meer hierover is ook te vinden in appendix D.
16
3.1.3
Pollen
Omdat het aanbod van nieuwsberichten op het internet steeds verandert, leek het nuttig om hierop in te spelen in de Newsfeed library. Dit hebben wij gedaan door in de RSS-klasse, waar een feed binnenkomt in het framework, om de vijf minuten te kijken of er nieuwe content online staat. Als er nieuwe items beschikbaar zijn wordt een Changed event opgegooid. Hierop voeren de decorators een voor een hun werk uit op de feed, waarna het event uiteindelijk opborrelt aan de bovenkant van de library. Hier kan een applicatie op reageren door bijvoorbeeld meteen de nieuwe items weer te geven. Ook deze functionaliteit is uitgebreider beschreven in appendix D. Dit gebeurt in Stay in Touch echter niet omdat dat te veel zou kunnen interfereren met het gebruik van de applicatie. Wel worden nieuwe items getoond zodra de gebruiker de filtertoestand wijzigt.
3.1.4
Ontwerppatronen
In softwareontwikkeling is het wenselijk om – waar mogelijk – gebruik te maken van ontwerppatronen. Dat zijn bekende oplossingen voor veel voorkomende problemen. In ons project zijn twee patronen vergaand doorgevoerd; het zogenaamde decorator ontwerppatroon en het MVC ontwerppatroon. Decorator ontwerppatroon Het decorator ontwerppatroon hebben wij toegepast bij het aanpassen van feeds. Dit is nodig omdat verschillende feeds (zelfs feeds aangemaakt volgens dezelfde RSS-specificatie) qua inhoud erg blijken te verschillen. In het decorator patroon worden decorators gebruikt om steeds een iets andere functionaliteit te bieden. Figuur 3.1 bevat een UML-diagram van het decorator patroon. Over de implementatie van het patroon in de newsfeed library is meer te lezen in appendix D. MVC ontwerppatroon In de Stay in Touch applicatie hebben we het Model-View-Controller patroon toegepast. Een applicatie wordt hierbij strikt opgesplitst in drie verschillende modules. Hierdoor is het mogelijk om een van de modules te verwisselen voor een andere, zonder daarbij de rest van de applicatie aan te passen. Zo zou de Stay in Touch applicatie heel makkelijk omgezet kunnen worden naar een Windows Mobile versie. Het enige wat er dan hoeft te veranderen is namelijk een view toegespitst op de Windows Mobile omgeving, de rest van de applicatie kan hergebruikt worden omdat er geen aanroepen naar de huidige view (voor de Microsoft Surface) in gebruikt worden. Het gebruik van het MVC ontwerppatroon wordt ook behandeld in appendix D.
3.2
Kwaliteit
Om de kwaliteit van het opgeleverde product te beoordelen, heeft de Software Improvement Group (SIG) aangeboden om de code door te meten met hun analysesoftware. Dit doen ze voor elk bacheloreindproject, dus ook voor de onze. De kwaliteitsbeoordeling van de SIG is er op gericht om ontwikkelaars bewust te maken van de onderhoudbaarheid van de ingestuurde code. De feedback die de SIG heeft gegeven wordt in deze sectie besproken. Op ongeveer driekwart van het ontwikkelproces was het eerste inlevermoment. De code scoorde vier van de vijf sterren op het onderhoudbaarheidsmodel van de SIG. Dit betekent dat de code bovengemiddeld onderhoudbaar is. De score werd omlaag gehaald door duplicatie en unit interfacing. 17
Figuur 3.1: UML-diagram van het decorator patroon. (bron: best-practice-software-engineering.ifs.tuwien.ac.at)
18
Codeduplicatie Het minimaliseren van duplicaten is van belang als het om onderhoudbaarheid gaat. De gedachte van de SIG: “Er wordt gekeken naar het percentage van de code welke redundant is, oftewel de code die meerdere keren in het systeem voorkomt en in principe verwijderd zou kunnen worden. Vanuit het oogpunt van onderhoudbaarheid is het wenselijk om een laag percentage redundantie te hebben omdat aanpassingen aan deze stukken code doorgaans op meerdere plaatsen moet gebeuren.”. Er werd een duidelijk terugkerend patroon constateert in de Decorator klassen en de suggestie luidde om meer abstractie toe te passen. Het bleek een prima uitvoerbaar advies, dat inmiddels in de code verwerkt is. Onze code bestaat uit twee gedeelten, (1) de newsfeed library en (2) de Stay in Touch applicatie. Die laatste maakt gebruik van de library. De code die opgestuurd is naar de SIG bevatte per abuis twee keer de newsfeed library met onderling minieme verschillen. Dit was niet de bedoeling en de SIG heeft ons daar op geattendeerd. Unit interfacing “Voor Unit interfacing wordt er gekeken naar het percentage code in units met een bovengemiddeld aantal parameters. Doorgaans duidt een bovengemiddeld aantal parameters op een gebrek aan abstractie. Daarnaast leidt een groot aantal parameters nogal eens tot verwarring in het aanroepen van de methode en in de meeste gevallen ook tot langere en complexere methoden.” aldus de SIG. Na inspectie bleek dat het vaak voorkwam dat methoden collecties van strings verwachtten, waar de strings bepaalde categorie¨en of talen representeerden. Voor een betere onderhoudbaarheid ziet de SIG liever dat deze concepten niet als kale strings worden doorgegeven, maar dat er specifieke types voor ge¨ıntroduceerd worden. Ook van dit advies zien wij het nut in en hebben het opgevolgd. De aangepaste methoden verwachten nu collecties van categorieobjecten in plaats van strings. Op die manier is het duidelijker waar de methode voor dient en zullen er bij het uitbreiden van de applicatie minder fouten gemaakt worden.
3.3
Kennis
Gedurende het project is de applicatie beetje bij beetje een geheel geworden. Echter is niet alleen het tastbare product opgeleverd, ook niet-tastbare producten, zoals kennis is bijgehouden en verzameld. De verzamelde informatie is gebundeld in het ‘Getting Started’ document dat te vinden is in appendix C. Het document is bedoeld voor ontwikkelaars die een nieuwe applicatie willen maken voor de Surface. Hierin is bijvoorbeeld te vinden welke ontwikkeltools handig kunnen zijn en er worden tips gegeven voor het uitrollen van applicaties. De opgedane kennis bestaat niet alleen uit informatie over de Surface, ook randapparatuur en connecties met (TU Delft specifieke) externe databronnen zijn onderzocht. Denk bijvoorbeeld aan een RFID lezer, die gebruikt kan worden om een campuscard uit te lezen. Met behulp van het kaartnummer kan vervolgens weer een koppeling gemaakt worden met de persoonsdatabase van de TU Delft, zodat opgezocht kan worden wiens kaart er uitgelezen is. In het document (met bijbehorende voorbeeldcode) is genoeg informatie aanwezig om het zojuist beschreven scenario te kunnen realiseren.
19
4 Conclusie en aanbevelingen 4.1
Conclusie
Gedurende het project zijn onze doelen zeker verschoven. Eerst zouden we een applicatie uitwerken die ontworpen is door IO-studenten om daarna aan andere applicaties te werken (een mindmap-applicatie bleek zeer gewild). Gaandeweg zijn we flink afgeweken van het voorgestelde ontwerp. Ook bleek dat het ontwikkelen trager ging dan gedacht. Uiteindelijk hebben we dus een generieke library, een applicatie voor de Surface en bijbehorende documentatie opgeleverd. Minder dan we ingedachte hadden, maar we staan er wel achter. Door de aandacht die we besteed hebben aan de implementatie weten we dat er robuuste en interessante producten staan die goed gebruikt zouden kunnen worden in de TU Delft Library en elders.
4.2
Aanbevelingen
Tijdens het ontwikkelen van de Stay in Touch applicatie zijn er verschillende idee¨en ontstaan over de gebruikersinterface en het gedrag daarvan. Enkele van die idee¨en hebben in het ontwikkelproces een lagere prioriteit gekregen en zijn wegens tijdgebrek of een andere reden niet ge¨ımplementeerd in de opgeleverde applicatie. Deze sectie geeft een overzicht van een aantal van die idee¨en en een advies met betrekking tot de implementatie daarvan.
4.2.1
Gedrag filterknoppen
Nieuwsberichten behoren bij een of meer categorie¨en en horen in ´e´en taalcategorie. Gebruikers kunnen via het filtermenu kiezen welke categorie¨en ze willen bekijken. Oorspronkelijk was het de bedoeling dat als er meerdere categorie¨en gekozen waren slechts die nieuwsberichten getoond zouden worden die behoorden tot alle categorie¨en. Als ‘Photo’ en ‘Nature’ gekozen waren zouden er alleen foto’s verschijnen die met natuur te maken hadden. Combinaties die geen nieuwsberichten zouden opleveren werden uitschakelend door middel van het ‘disablen’ van de knoppen. Dit bleek echter voor veel gebruikers een verwarrende manier te zijn om nieuws te selecteren. Vaak werd geprobeerd om op de uitgeschakelde knoppen te drukken, die vervolgens niet reageren. Daarom is het gedrag van het filter over een andere boeg gegooid. De huidige implementatie schakelt geen knoppen meer uit. Als meerdere categorie¨en geselecteerd worden, verschijnen er nieuwsberichten die bij minstens een van die categorie¨en horen. Het resultaat is dat het veel meer aansluit bij de verwachtingen van de gebruikers. Een nadeel is dat er knoppen zullen zijn die geen verandering teweeg brengen aan de staat van de applicatie. Bijvoorbeeld het selecteren van Nederlands nieuws terwijl de tafel al alleen maar Nederlands nieuws laat zien. Ook zijn combinaties mogelijk die het scherm leegmaken en is de mogelijkheid om specifieker nieuws te selecteren verloren gegaan. Beide oplossingen zijn nog niet optimaal en bieden nog ruimte voor verbetering. Het ideale gedrag van de knoppen zal grotendeels bepaald moeten worden door het observeren van gebruikers en zo duidelijk te krijgen wat gebruikers verwachten. Een aantal gebruikers heeft al idee¨en geopperd voor mogelijke aanvullingen op het filtermenu in de vorm van een ‘Clear’ en ‘All’ knop die respectievelijk het scherm leeg maken en volgooien.
20
4.2.2
Logo’s van nieuwsbronnen
Alle berichten die op de tafel verschijnen zijn afkomstig uit een nieuwsbron op het internet. Momenteel wordt rechtsonder in elk nieuwsbericht de naam van de nieuwsbron weergegeven. Een uitbreiding daarop is het weergeven van het logo van de nieuwsbron. Deze functionaliteit is deels ge¨ımplementeerd, maar is komen te vervallen wegens andere taken met een hogere prioriteit. Het weergeven van de logo’s wekt vaak een directe associatie met de nieuwsbron op bij de gebruiker. Door dit effect heeft de gebruiker sneller door waar de applicatie voor dient en is sneller bekend met de herkomst van een bericht. Vaak zijn logo’s beschermd ten gunste van de rechthebbenden. Het is van belang dat wordt uitgezocht welke logo’s op welke manier gebruikt mogen worden. Een ander belangrijk aandachtspunt is de manier waarop de logo’s weergegeven worden. Vooral bij nieuwsberichten die bestaan uit een grote foto is het lastig een logo te plaatsen, want de foto’s hebben een onbekend formaat en contrast. Een ander punt is de onderhoudbaarheid, voor elke nieuwe feed zal een logo gedownload en eventueel bewerkt moeten worden.
4.2.3
Specifieke bron selectie
Momenteel kunnen gebruikers nieuws kiezen op basis van taal en categorie. Het is niet mogelijk om nieuws van een bepaalde bron te selecteren. Deze mogelijkheid zouden sommige gebruikers graag terugzien in de applicatie. Een mogelijke wijze van implementeren is het uitbreiden van het filtermenu met knoppen die elk een bepaalde bron selecteren. Als het voorgaande idee van de logo’s ge¨ımplementeerd is, zal het weergeven van de logo’s op de knoppen een simpel te implementeren en leuke toevoeging zijn.
4.2.4
Beheerapplicatie
De Stay in Touch applicatie wordt geconfigureerd via een XML bestand dat lokaal `of extern (via een webserver) bereikbaar is. Vooral voor mensen die weinig ervaring hebben met XML is een foutje zo gemaakt. Daarom is het idee ontstaan om een beheerapplicatie te ontwikkelen die het aanpassen van het XML bestand makkelijker maakt. Als dit idee wordt uitgewerkt is het nuttig om te weten dat het XML configuratiebestand moet voldoen aan bepaalde eisen. Al deze eisen zijn ondergebracht in een zogeheten ‘XML schema’, wat fungeert als een validatiebestand. Het bestand is te vinden in Resources\config.xsd. Met behulp van het validatiebestand kan gecontroleerd worden of het configuratiebestand voldoet aan de grammatica en mogelijke parameterkeuzes. Op die manier kan er voor gezorgd worden dat alleen geldige configuraties beschikbaar worden gesteld aan de applicatie.
21
5 Evaluatie In dit hoofdstuk zullen we enkele zaken uiteenzetten waarover we het unaniem eens zijn. We zullen wat zeggen over de Agile principes, het proces middels Scrum, Test Driven Development, C# en de Microsoft Surface.
5.1
Agile
We hebben gewerkt met de Scrum ontwikkelmethodiek, een onderdeel van Agile. Het is dus interessant om te kijken in hoeverre wij ons kunnen vinden in de principes van het Agile Manifest. Individuals and interactions over processes and tools. Hier kunnen wij ons wel in vinden. In eerste instantie maakten we namelijk gebruik van een online projectmanagement tool. Die hebben we echter snel aan de kant geschoven toen bleek dat het invoeren van de taken erg veel tijd kostte. Het is gebleken dat post-it’s, waar nodig, gebruikt kunnen worden om taken te verdelen en te plannen. Maar voor het grootste deel is dit mondeling afgesproken (daily meets maken dit overigens een stuk makkelijker). De daily meets vallen an sich natuurlijk ook onder dit principe, maar deze zullen we later behandelen. Working software over comprehensive documentation. Hier kunnen wij ons minder in vinden. We hebben namelijk wel geprobeerd om een duidelijk overzicht gegeven van alle aspecten van het project. Het is echter wel zo dat we niet meer documentatie hebben opgeleverd dan wij nodig achtten. Iets wat ons uit een Scrum boek is bijgebleven. Customer collaboration over contract negotiation. Vanwege de redelijk vrije opdracht was van een strak contract niet echt sprake. Verder is alles inderdaad voornamelijk mondeling besproken. Sowieso tweewekelijks tijdens de review en planning meet, en daartussen soms ook nog als dat nodig bleek. Door veel contact te houden met de opdrachtgever kan de richting waarin gewerkt wordt naar wens worden bijgestuurd. Responding to change over following a plan. Dit is echt zeer goed uitgepakt tijdens het project. Vooral omdat C# en de Surface nog onbekend terrein voor ons waren hadden we vooraf geen juiste plannen kunnen trekken. Wij dachten vooraf dat we veel meer gedaan zouden krijgen. De opdrachtgevers dachten dat de applicatie er flink anders uit ging zien. Door gaandeweg te bedenken hoeveel moeite dingen zouden kosten en hoe ze er precies uit zouden gaan zien kan je tijdens het project beter beslissen waar de prioriteiten moeten liggen. Als dit alles vooraf besloten moet worden kost dit initieel veel tijd, en blijkt later meestal dat voor de helft van de plannen toch geen tijd meer is. Inspelen op verandering is een principe dat we zullen onthouden.
5.2
Scrum
De daily meets hebben we allen als zeer nuttig ervaren. Ze helpen goed om iedereen op de hoogte te houden van ieders voortgang. Daardoor voel je als team goed aan hoe de voortgang is en waar eventueel bijgesprongen moet worden. Ook zijn de meets een ideaal moment om een discussiepunt uit te praten. De structuur van de daily meet hebben we echter wel flink veranderd. Initieel gingen wij uit van de standaard structuur; je vertelt achtereenvolgens 22
1. Wat je de vorige dag hebt gedaan. 2. Wat je vandaag wilt doen. 3. Of er dingen zijn waar je tegenaan loopt. Het bleek dat het derde item overbodig was tijdens ons project. Misschien was dat omdat we op ´e´en kamer zaten. Een antwoord op een vraag was zo snel gevonden. Daarnaast vonden we het fijner om eerst allemaal punt 1 te beantwoorden, dan eventueel nog wat dingen te overleggen en vervolgens allemaal punt 2 te bespreken. Anders moeten mensen beslissen wat ze doen voor je weet hoe ver anderen zijn. De korte iteraties zijn ook fijn gebleken. Het is fijn om na twee weken al gezamenlijk te praten over een product wat klaar moet zijn voor oplevering. De opdrachtgever kan dan snel ingrijpen als het niet de goede kant op gaat, en je kan snel bepalen waar de aandacht verder naar uit moet gaan. Ook de verplichting om elke twee weken documentatie op te leveren was fijn. Doordat de review en planning meet redelijk kort blijven valt de overhead ook heel erg mee. De review meeting vonden we een prima moment om redelijk informeel terug te kijken naar de afgelopen weken. Wij hebben het gedane werk besproken aan de hand van de sprint backlog. Waarna gekeken is naar de nieuwe ontwikkelingen op de Surface. Vervolgens hebben we de vergadering voortgezet als planning meet waarbij de nieuwe prioriteiten vastgesteld worden aan de hand van de product backlog. De product backlog was wat minder nuttig tijdens ons project. Het idee is dat je in het begin van een project een lijst met functionaliteiten opstelt waaruit elke sprint een sublijst gekozen wordt om die sprint aan te werken. De backlog is bij ons echter elke twee weken aangevuld met nieuwe functies. Daardoor werkte het prioriteren minder fijn dan dat het er op papier uitzag. We stelden nu eigenlijk elke keer een losse sprint backlog op, waar normaal taken uit de product backlog gekozen zouden worden. Hinderlijk was het echter niet. Waarschijnlijk werd dit veroorzaakt doordat de opdracht niet strak vast lag. Ondanks onze goede ervaringen zijn we benieuwd naar de echte werking van Scrum binnen een project, omdat hier behoorlijk wat theorie over geschreven is.
5.3
Test-Driven Development
Vooral voor de Newsfeed library hebben we uitgebreid gebruik gemaakt van unit testing. Het bedenken en schrijven van tests kostte vaak een hoop tijd, maar uiteindelijk waren ze het in de meeste gevallen waard. Vooral bij het refactoren later in het project was het fijn om met een druk op de knop te kunnen zien dat je geen fouten ge¨ıntroduceerd hebt. In sommige gevallen was het opzetten van een fatsoenlijke test te veel werk, maar zulke afwegingen komen altijd voor bij testen. Voor de Stay in Touch applicatie was het lastiger om tests te maken. Omdat hier veel minder logica in zit dan in Newsfeed waardoor uitgebreid testen hier minder noodzakelijk is.
5.4
Documenteren
Het documenteren was een lastig deel van het project. Het was vaak moeilijk om na het programmeren over te gaan op documenteren, omdat het minder leuk is... Daarnaast viel het tegen om in te schatten hoeveel tijd het documenteren zou kosten. De ene keer gaat het documenteren ook een stuk sneller dan andere keren. Ook wilden we vaak eerder beginnen met documenteren omdat het toch vaak haastwerk werd. Maar te vroeg beginnen is ook onhandig omdat zaken dan 23
tijdens of na het documenteren weer kunnen veranderen zodat de documentatie weer achter gaat lopen.
5.5
Versiebeheer met Git
We hebben allemaal kunnen proeven aan de vele voordelen aan het gedistribueerde versiebeheersysteem Git zoals Hugo die ons aan het begin van het project heeft voorgehouden. Het is gemakkelijk om aparte branches op te zetten om tijdelijk in te werken. Doorwerken zonder internet, wat bij ons nog wel eens nodig bleek, gaat zonder al te veel problemen.
24
A Ori¨ entatieverslag A.1
Inleiding
“Cre¨eer een applicatie voor de Microsoft Surface die in de TU Delft Library komt te staan.” Zo luidt de omschrijving van onze opdracht. Deze applicatie moet aansluiten bij de visie en doelen van het Library Learning Centre. De Microsoft Surface is een computer met een multitouch tafelblad als scherm. Het probleem dat opgelost moet worden is het onvoldoende benut potenti¨eel van de Microsoft Surface. De bedoeling is dat we een door IO-studenten ontworpen applicatie implementeren. Daarnaast moet het proces goed worden gedocumenteerd en herbruikbare delen geidentificeerd en in modules geplaatst worden, zodat sneller nieuwe applicaties kunnen worden ontwikkeld. In dit verslag wordt onze ori¨entatie op het probleem en de mogelijke oplossingen beschreven. In hoofdstuk A.2 wordt kort het probleem en de opdracht toegelicht. Vervolgens wordt de gekozen ontwikkelmethodiek behandeld in hoofdstuk A.3. Daarna zullen de technische mogelijkheden van de Surface worden besproken in hoofdstuk A.4, waarna de verschillende hulpmiddelen die we willen gaan gebruiken zullen worden besproken in hoofdstuk A.5. In hoofdstuk A.6 zullen al ontwikkelde applicaties worden besproken, om tot slot in hoofdstuk A.7 het huidige onderzoek naar multitouch displays samen te vatten.
A.2
Probleemomschrijving
De TU Delft Library heeft onlangs enkele Microsoft Surface systemen gekocht. Op deze tafels kunnen meerdere personen tegelijkertijd werken in applicaties via een multitouch interface. Op de begane grond van de TU Delft Library is een van de tafels beschikbaar voor studenten. Op het moment wordt deze tafel echter niet veel gebruikt. Er zijn verschillende manieren om het gebruik van de tafel te stimuleren. Zo kan er reclame worden gemaakt voor de tafel of kan deze op een locatie worden neergezet waar hij meer in het oog springt. Navraag bij studenten leert echter dat de tafel niet gebruikt wordt omdat er nog geen interessante applicaties op staan. Vanuit de bibliotheek is daarom de wens uitgesproken dat er meer applicaties ontwikkeld moeten worden voor de Surface. Om een direct zichtbaar resultaat te produceren, zullen we een door IO-studenten ontworpen applicatie implementeren. Om het sneller ontwikkelen van applicaties in de toekomst te faciliteren, zullen we enkele generieke modules ontwikkelen en ons ontwikkelproces en onze producten goed documenteren.
A.3
Ontwikkelmethodiek
Wij hebben ervoor gekozen om bij dit project de Scrum ontwikkelmethodiek te gaan toepassen. In deze sectie zullen we uitleggen waarom wij voor Scrum gekozen hebben en wat de voordelen van Scrum zouden zijn.
A.3.1
Waarom kiezen wij voor Scrum
In het tweede jaar van onze studie hebben wij bij het ST4-project gewerkt volgens het watervalmodel. Hierbij wordt eerst uitgebreid gedocumenteerd waarbij requirements en ontwerp vastgelegd worden. Als dat klaar is wordt uiteindelijk begonnen met het ontwikkelen van de 25
Figuur A.1: Schematisch weergave van het ontwikkelproces in Scrum code. Dit was interessant om een keer door te lopen, maar het voelde erg ouderwets aan. Uit diverse hoeken hoorden wij goede verhalen over Scrum. Hierbij begin je juist zo snel mogelijk met ontwikkelen van een werkbare applicatie. Daarop kunnen eindgebruikers meteen feedback leveren. Vanwege het grote contrast met het watervalmodel leek het ons een goed plan om ook ervaring op te doen met Scrum.
A.3.2
Scrum in de praktijk
Scrum is eind jaren ’80 in Japan opgeworpen omdat bleek dat naast kwaliteit, lage kosten en innovatie ook flexibiliteit en snelheid cruciale factoren bleken voor succesvolle software-ontwikkeling [14]. In Scrum werkt een ontwikkelgroep tijdens korte ‘Sprints’ naar een prototype toe. Door zo snel mogelijk een werkbaar prototype af te leveren kan men al vroeg controleren of de wensen van de klant goed begrepen zijn. Deze tijdswinst zorgt voor een snellere oplevering van eindproducten. Elke dag komt een team kort bij elkaar voor de Standup Meeting. Hierin geeft elk teamlid aan wat hij heeft gedaan, wat hij gaat doen en waar hij tegen aan loopt. In de praktijk is gebleken dat tijdens deze meetings vaak goede oplossingen bedacht werden omdat het hele team samen kon denken en overleggen [13]. De standup meeting moet echter wel kort gehouden worden. Meestal wordt afgesproken dat een aantal teamleden later verder kijken naar een bepaald probleem. Een ontwikkelteam krijgt in Scrum een breed doel aangeleverd van het management. Dus niet een specifiek doel als een concept-programma of een applicatiebeschrijving. Hiermee wordt het team vrij gelaten om zelf oplossingen te kiezen die zij willen gebruiken. Er is meestal geen vaste rolverdeling binnen teams, iedereen kan een taak op zich nemen. Een positief gevolg hiervan is dat iedereen een goed overzicht over het hele project behoudt en zo flexibel ingezet kan worden. Ook zullen teamleden zo veel bijleren tijdens een project. Tijdens een project worden teams losgelaten zodat ze zelf een richting zoeken. Het team begint met ‘zero knowledge’. Doordat de leden vervolgens informatie gaan delen ontstaat er een hecht team. Er worden risico’s genomen en innovatieve stappen gezet. Hierdoor functioneert het team in feite als een startup waarbij het management ongeveer op dezelfde manier als een venture capitalist het project in de gaten
26
houdt.
A.3.3
Nadelen
Nadelen van Scrum hebben we kunnen lezen in een verslag van een vorig bachelorproject [5, p.40]. Daarin wordt opgemerkt dat de kwaliteit van software minder aandacht kan krijgen omdat men nieuwe features als doel heeft. Test-driven development kan dit voorkomen door de kwaliteit van de code te waarborgen en ervoor te zorgen dat de code volgens de documentatie geschreven wordt. Dit komt de aanpasbaarheid ten goede.
A.3.4
Scrum in ons project
Wij zullen Scrum op de standaard manier toepassen. Eerst sprints van twee weken, later in het project misschien korter om meer ervaring met het ‘sprinten’ te verkrijgen. Scrum zou dus creatieve oplossing moeten opleveren waarbij al vroeg feedback van de opdrachtgevers verwerkt kan worden. We zijn benieuwd of dit in de werkelijkheid ook zo uit zal pakken.
A.4
Technische features van de Surface
De TU Delft Library beschikt over twee tafels. E´en van de tafels staat al een geruime tijd in de centrale hal van de bibliotheek en de tweede tafel staat in een kantoor op de onderste verdieping van de bibliotheek. Deze laatste tafel is beschikbaar gesteld voor ontwikkel doeleinden en wordt dus door ons gebruikt. De Surface bestaat uit een normale computer met een aangepaste versie van Windows Vista. Het scherm van de tafel is geschikt voor multitouch invoer. Dat wil dus zeggen dat het meerdere vingers of objecten tegelijkertijd kan herkennen. Dit doet de tafel met behulp van beelden van meerdere infraroodcamera’s. De indeling van de componenten is weergegeven in figuur A.2. De behelsde computer heeft verder beschikking over een op 2,3 GHz draaiende Intel Core 2 Duo processor, 2 gigabyte RAM geheugen, 250 gigabyte hardeschijfruimte en een draadloze internet (802.11 b/g) en Bluetooth 2.0 verbinding. Het scherm van de Surface heeft een schermdiagonaal van 30 inch (76 cm) met een resolutie van 1024×768 pixels.
A.4.1
Infraroodcamera’s
Het is mogelijk om ruwe gegevens van de infraroodcamera’s op te vragen. Dit kan op twee manieren [10]. De eerste manier geeft de informatie in de vorm van een genormaliseerde afbeelding, figuur A.3a is een voorbeeld daarvan. De genormaliseerde afbeelding heeft alleen maar grijstinten. De tweede manier is het opvragen van een gebinariseerde afbeelding, die alleen de kleuren zwart en wit bevat. Figuur A.3b is een gebinariseerde afbeelding en is veel beter geschikt voor beeldherkenning dan de genormaliseerde afbeelding. Beide afbeeldingen zijn opgebouwd met beelden van meerdere camera’s, dit wordt automatisch gedaan door de onderliggende software. Identity tags De Surface bevat een standaard functionaliteit die zogenaamde identity tags (vergelijkbaar met QR-codes) kan uitlezen [6]. Figuur A.4 is een voorbeeld van zo’n identity tag.
27
Figuur A.2: Componenten van de Microsoft Surface. (1) Aanraakgevoelig schermoppervlak, (2) infraroodlamp, (3) vier infraroodcamera’s en (4) projector.
(a) Genormaliseerde afbeelding
(b) Gebinariseerde afbeelding
Figuur A.3: Weergave van hoe de Surface een hand ziet.
Figuur A.4: Voorbeeld van een identity tag.
28
(a) Genormaliseerde campuscard
(b) Gebinariseerde campuscard
Figuur A.5: Weergave van hoe de Surface een campuscard ziet. E´en identity tag kan zestien bytes aan data bevatten. De ontwikkelaar kan acties aan tags koppelen en de Surface voert die acties automatisch uit als een bepaalde tag herkent wordt. Omdat de identity tags gedetailleerd zijn en de Surface deze zonder enige merkbare moeite herkent, zijn we op het idee gekomen om zelf een onderzoek uit te voeren naar de precisie van de infraroodcamera’s. Precisie We hebben onderzoek gedaan naar de precisie van de infraroodcamera’s, omdat het misschien mogelijk zou zijn om bijvoorbeeld boeken te herkennen aan de hand van de letter- of streepjescode. Als de camera’s gevoelig genoeg zouden zijn, zou het ook mogelijk zijn om het nummer van de campuscard uit te lezen zonder de kaart langs een RFID-lezer te hoeven halen. Voor het onderzoek hebben we twee afbeeldingen gemaakt van een campuscard, ´e´en keer een genormaliseerde afbeelding en ´e´en keer een gebinariseerde afbeelding. De resultaten zijn weergegeven in figuur A.5a en A.5b. Hieruit blijkt dat de resolutie van de camera’s niet hoog genoeg is om de cijfers en streepjescode op de campuscard te herkennen. Onze conclusie is dus dat de mogelijkheid om ruwe data van de infraroodcamera’s op te vragen, alleen kan worden gebruikt om grote vormen op de tafel te onderscheiden. Om andere objecten te herkennen is het dus nodig om deze object te voorzien van een identity tag of gebruik te maken van de RFID lezer.
A.4.2
RFID lezer
Ons onderzoek naar de mogelijkheden van de Surface heeft uitgewezen dat er geen RFID lezer aanwezig is in de tafel. Om een campuscard uit te lezen is het dus nodig om een externe RFID lezer te gebruiken. Deze is al aangeschaft door de TU Delft en kan via USB aangesloten worden op de tafel. Voor C# bestaan er diverse libraries om RFID kaarten uit te lezen. Ons oog is gevallen op de API van CardWerk [3]. Deze interface maskeert de lowlevel structuur van het uitlezen en biedt op een hoger niveau toegang tot de gegevens op de kaart. Tevens is de broncode gratis te gebruiken voor niet-commerci¨eel gebruik. Het idee is om het nummer van de kaart hiermee uit te lezen en te koppelen aan de betreffende student middels een connectie met een database met
29
persoonsgegevens van de TU Delft. Op die manier weet de applicatie bij welke persoon de kaart hoort.
A.5
Hulpmiddelen
Voor het oplossen van het probleem kan er uit verschillende tools worden gekozen. In dit hoofdstuk zullen wij deze hulpmiddelen op hun voor- en nadelen beoordelen en een keuze maken over de te gebruiken tools.
A.5.1
IDE
Aangezien Microsoft voor zijn Surface SDK enkel Microsoft Visual Studio 2008 ondersteunt, gebruiken we deze IDE. Dit is een zeer uitgebreide IDE welke wordt geleverd met een compiler voor het Windows platform. De IDE ondersteunt alle .NET talen, waaronder C#, en biedt veel standaard hulpmiddelen zoals een debugger en het automatisch aanpassen van variabelenamen.
A.5.2
Testing framework
Voor het testen van onze code zullen we gebruik maken van het NUnit framework [9]. We verkiezen dit framework boven csUnit en de Microsoft Team System testing tools. csUnit lijkt niet erg vaak ge¨ updatet te worden [4], de laatste update is van maart 2009. De documentatie van Microsofts oplossing lijkt minder goed te zijn dan die van NUnit. Voor een goede integratie van NUnit met de GUI van Visual Studio gebruikten we TestDriven.Net [15]. Met dit programma is het mogelijk om tests direct vanuit Visual Studio te draaien. Ook maakt dit het draaien met de debugger een stuk eenvoudiger en kan de coverage van de testsuite worden gecontroleerd met behulp van NCover.
A.5.3
SDK
Microsoft levert de Surface SDK welke speciaal is gemaakt om softwareontwikkeling voor de Surface te vereenvoudigen [7]. Het is een uitbreiding op zowel het XNA Framework als de Windows Presentation Foundation (WPF). Bij het maken van een applicatie voor de Surface kan slechts ´e´en van deze twee systemen als basis gebruikt worden. WPF is het onderdeel van het .NET framework dat verantwoordelijk is voor de gebruikersinterface, de SDK biedt daarvoor enkele nieuwe controls aan. Deze controls kunnen worden gebruikt om de standaard interactievorm van de tafel te behouden, terwijl er wel eigen content kan worden weergegeven. Het XNA Framework wordt veel gebruikt voor het maken van games. De Surface SDK biedt ook de mogelijkheid om met de Shell te communiceren. Dit is het programma dat de verschillende applicaties, de gebruikerssessie en de ori¨entatie van de tafel beheert. Zo kan de applicatie aan de Shell vragen aan welke kant de gebruiker op een launcher heeft gedrukt, om zo een inschatting te kunnen maken aan welke kant de gebruiker staat.
A.5.4
Versie beheer systeem
Voor het versiebeheer zullen we in dit project gebruik maken van Git. Deze keuze hebben we gemaakt na het afwegen van voor- en nadelen tegenover SVN, het versie beheer systeem (VCS) dat we in onze studie altijd al gebruikt hebben. Voordelen van Git zijn legio. De meeste vloeien voort uit het feit dat Git een gedistribueerd versie beheer systeem (DVCS) is; iedereen heeft een eigen kopie van de repositories. Op de
30
website http://www.whygitisbetterthanx.com worden de voordelen van Git tegenover andere VCS’en opgesomd. Ze noemen onder andere: • Goedkoop lokaal branchen; branches worden slechts lokaal bijgehouden. • Git heeft een staging area; een plek om je commits netjes op te bouwen voor je ze naar je teamleden stuurt. • Elke workflow is mogelijk; de gecentraliseerde SVN workflow is een mogelijkheid, maar met Git kan je elke willekeurige methode toepassen. De Alwis en Sillito hebben nog enkele andere voordelen van DVCS’en ge¨ıdentificeerd [1], waaronder: • First-class toegang voor alle developers; in een DVCS is het voor iedereen makkelijk om een eigen repository te clonen. • Simpel geautomatiseerd mergen; er wordt genoeg informatie bijgehouden om merges tussen verschillende commits soepel automatisch te managen. • Support voor experimentele code; omdat een lokale branch goedkoop is, is experimenteren in een DVCS geen probleem. • Offline werken mogelijk; er is geen verbinding met een centrale server nodig omdat het klaarzetten van commits en het pushen van elkaar losgetrokken is. In dat paper wordt ook beschreven hoe Perl, OpenOffice, Python en NetBSD transities aan het plannen zijn naar DVCS’en. Naast de hoeveelheid werk die met de transitie gemoeid is ziet men namelijk niet veel nadelen aan een DVCS. Slechts het redundant opslaan kan gezien worden als een probleem omdat het veel opslagruimte zou kosten en het moeilijk zou maken om code te splitsen of verwijderen uit repositories omdat er heel veel lokale clones gemaakt zijn. Er lijken dus veel voordelen te zitten aan DVCS’en, in het bijzonder aan Git. Omdat een van onze teamleden al ervaring had met Git was de keuze dus snel gemaakt.
A.5.5
Issue tracking systeem
In een softwareproject is het belangrijk om de voortgang bij te houden. Zeker de Scrum methode vraagt om een actuele stand van zaken bij de dagelijkse vergaderingen. Om de voortgang van ons project goed te volgen maken we gebruik van een flexibele projectbeheerapplicatie genaamd Redmine [12]. Met behulp van Redmine kunnen verschillende issues worden aangemaakt, en kan worden bijgehouden hoe veel tijd er aan iedere issue besteed wordt. Redmine zelf is niet volledig compatibel met de Scrum ontwikkelmethode. Daarom hebben we een extra plugin, Redmine Backlogs [11], ge¨ınstalleerd. Deze plugin breidt Redmine zodanig uit dat we makkelijk de product backlog en sprint backlogs kunnen bijhouden. Het stelt ons ook in staat om grafieken weer te geven die het verloop van het project laten zien, de zogenaamde burndown chart.
A.6
Bestaande systemen en applicaties
Microsoft levert zelf een aantal voorbeeldapplicaties bij de Surface. Deze applicaties zijn er voornamelijk om te laten zien wat er allemaal mogelijk is met de Surface, en hoe de gebruikersinterface er volgens Microsoft uit zou moeten zien. Verder kunnen we gebruik maken van een aantal afgeronde projecten op het gebied van de Surface en heeft de gemeentebibliotheek van Delft een operationele Surface. 31
A.6.1
Project van Industrieel Ontwerpers
In de ori¨entatiefase hebben we vergadert met een groep IO-studenten die een Surface applicatie hebben bedacht. Met de applicatie kunnen studenten door TU gerelateerd nieuws bladeren en interessante artikelen naar een mapje slepen dat vervolgens gemailed kan worden. Op deze manier kunnen studenten bepaalde artikelen later volledig lezen op hun eigen computer. Er waren meerdere applicaties bedacht door IO’ers, maar deze applicatie is door de begeleiding als meest realistisch bevonden in de zin van uitvoerbaarheid. De opdrachtgevers van de TU Delft Library zijn het daarmee eens en zouden graag willen dat wij deze applicatie voor hen maken. Tijdens de vergadering is besloten dat er bepaalde momenten moeten zijn om te overleggen met de IO-studenten over ontwerpkeuzes.
A.6.2
Applicatie van de Hogeschool Rotterdam
Een groep studenten van de Hogeschool Rotterdam heeft in Delft gewerkt aan een applicatie die de campuscard koppelt aan de catalogus van de TU Delft Library. Er bestaat dus al een applicatie voor de Surface die de campuscard uitleest en informatie uit de catalogus kan trekken. De broncode van deze applicatie hebben wij in ons bezit gekregen en een aantal stukken code kunnen wij hergebruiken voor ons project.
A.6.3
Cultural Heritage bij DOK
Sinds een jaar of twee heeft de gemeentebibliotheek van Delft (DOK) ook een Surface waar bezoekers applicaties kunnen gebruiken. E´en van die applicaties is de Cultural Heritage Browser [8]. De applicatie kan een ledenpas herkennen met behulp van een identity tag die op de pas geprint is. Een bezoeker legt zijn pas dan op het scherm. Niet alle ledenpassen hebben zo’n identity tag achterop geprint, daarom worden de oudere passen herkent met behulp van een externe RFID lezer die naast het scherm op de tafel staat. De bezoeker moet dan even de pas bij de lezer houden, waarna vervolgens een virtuele ledenpas op het scherm van de Surface verschijnt. Zodra de ledenpas is herkent verschijnen er knopjes op het scherm rond de (virtuele) pas. Door op de knop “mijn straat” te klikken verschijnen er foto’s van de straat waar de bezoeker in woont. Op basis van de postcode worden de foto’s uit de “Erfgoed Delft” database gehaald. Bezoekers kunnen de foto’s vergroten en extra informatie over een foto opvragen. Dit systeem bevat een aantal idee¨en en elementen die voor ons project bruikbaar kunnen zijn. Vooral het idee van een virtueel pasje dat op het scherm verschijnt als de pas langs een RFID lezer gehaald wordt is goed. Want de campuscard heeft ook geen identity tag, maar op deze manier zouden er toch meerdere studenten tegelijk gebruik kunnen maken van de tafel. Niet alleen hebben we de applicatie bij DOK uitgeprobeerd, ook hebben we een korte ontmoeting gehad met de ontwikkelaar, Koen Rotteveel, hij heeft laten weten dat hij beschikbaar is voor vragen en idee¨en.
A.7
Multitouch Displays
We hebben van Gerwin de Haan (begeleidend docent vanuit EWI) verschillende verwijzingen naar mogelijk interessante literatuur toegestuurd gekregen over multitouch displays. Wij hebben ze bestudeerd en zullen de relevante informatie hieronder samenvatten. Benko et al. merken op [2] dat het face-to-face karakter van het werken aan een multitouch tafel door teams erg nuttig wordt bevonden bij samenwerken. Toch proberen gebruikers functionaliteit vaak eerst uit op een klein deel van het scherm voordat ze de actie in het groot
32
demonstreren voor de andere gebruikers, omdat ze geen fouten willen maken onder het oog van anderen. Wallace et al. zeggen [16] het volgende over de complexiteit van interfaces. Een simpele interface: • bevat slechts enkele interactieve elementen. • benadrukt de belangrijkste elementen. • maakt gebruik van al aanwezige kennis met behulp van psuedo-fysieke elementen. • vereist geen gebaren met meerdere vingers en andere ingewikkelde acties. Simpele interfaces zijn belangrijk omdat: • gebruikers niet meteen weglopen van een applicatie omdat hun geduld op is. • gebruikers geen fouten willen maken onder het oog van anderen. • gebruikers meer kunnen doen in een korte tijd die ze te besteden hebben bij de tafel. Om het gebruik van applicaties effectiever te maken is het mogelijk om complexere input te vragen van de gebruiker, maar er moet altijd een simpel alternatief aanwezig zijn om het zelfde resultaat te verkrijgen. Wigdor geeft aan [17] dat het altijd van belang is dat het systeem goede feedback geeft op de handelingen van de gebruiker, dit is een groot verschil tussen het ontwerpen van een multitouch interface en een interface die wordt bestuurd met de muis.
A.8
Een woord van afsluiting
In deze ori¨enterende fase hebben we veel informatie vergaard over verschillende aspecten van het probleem. Hiermee hebben we een goed overzicht van het probleem verkregen en kunnen we de opdracht gaan vaststellen die we uit zullen gaan voeren. Deze zullen wij concreet beschrijven in een nog op te stellen plan van aanpak.
Referenties [1]
Brian de Alwis en Jonathan Sillito. Why are software projects moving from centralized ” to decentralized version control systems?” In: CHASE ’09: Proceedings of the 2009 ICSE Workshop on Cooperative and Human Aspects on Software Engineering. Washington, DC, USA: IEEE Computer Society, 2009, pp. 36-39. doi: 10.1109/CHASE.2009.5071408. url: http://dx.doi.org/10.1109/CHASE.2009.5071408.
[2]
H Benko et al. Insights on interactive tabletops: A survey of researchers and developers”. ” In: (2009).
[3] CardWerk SmartCard API. url: http://smartcard-api.com/ (bezocht op 26-04-2011). [4] csUnit. url: http://www.csunit.org/index.html (bezocht op 26-04-2011). [5]
Maarten Somhorst Gert-Jan Deen Michel de Ridder. Grafische weergave van verkeersproblemen, eindverslag bachelorproject. Tech. rap. TU Delft, 2009.
[6] Identity Tags. url: http://msdn.microsoft.com/en-us/library/ee786833(v=surfac e.10).aspx (bezocht op 26-04-2011). 33
[7] Microsoft Surface SDK 1.0 SP1 Documentation. Microsoft. 2009. url: http://go.micro soft.com/fwlink/?LinkID=164633. [8] Multitouch Microsoft Surface: Cultural Heritage Browser. url: http://vimeo.com/56439 53 (bezocht op 26-04-2011). [9] NUnit - Home. url: http://www.nunit.org/ (bezocht op 21-04-2011). [10] RawImage Visualizer. url: http : / / msdn . microsoft . com / en - us / library / ee80480 2(v=surface.10).aspx (bezocht op 26-04-2011). [11] Redmine Backlogs. url: http://www.redminebacklogs.net/ (bezocht op 27-04-2011). [12] Redmine project management. url: http://www.redmine.org/ (bezocht op 27-04-2011). [13]
L. Rising en N.S. Janoff. The Scrum software development process for small teams”. In: ” Software, IEEE 17.4 (2000), pp. 26 -32. issn: 0740-7459. doi: 10.1109/52.854065.
[14]
Hirotaka Takeuchi en Ikujiro Nonaka. The new new product development game”. In: ” Harvard Business Review 64.1 (1986), pp. 137-146. issn: 07376782. doi: 10.1016/0737-6 782(86)90053-6. url: http://linkinghub.elsevier.com/retrieve/pii/07376782869 00536.
[15] TestDriven.Net. url: http://www.testdriven.net/ (bezocht op 21-04-2011). [16]
J.R. Wallace en S.D. Scott. Contextual design considerations for co-located, collaborative ” tables”. In: Horizontal Interactive Human Computer Systems, 2008. TABLETOP 2008. 3rd IEEE International Workshop on. 2008, pp. 57 -64. doi: 10.1109/TABLETOP.2008.46 60184.
[17]
Daniel Wigdor. Architecting next-generation user interfaces”. In: Proceedings of the In” ternational Conference on Advanced Visual Interfaces. AVI ’10. Roma, Italy: ACM, 2010, pp. 16-22. isbn: 978-1-4503-0076-6. doi: http://doi.acm.org/10.1145/1842993.18429 97. url: http://doi.acm.org/10.1145/1842993.1842997.
34
B Plan van Aanpak Voorwoord In dit document wordt het plan van aanpak voor het Microsoft Surface bachelorproject uiteengezet. Er zal zo concreet mogelijk worden beschreven wat de eisen, aanpak en plannen zijn voor ons project bij de TU Delft Library.
Management samenvatting De opdracht is om een applicatie te ontwerpen en maken voor de Microsoft Surface in de TU Delft Library. Dit gaan wij doen in een periode van 10 weken, waarna wij als eindproduct een applicatie en een library/framework opleveren.
B.1
Inleiding
De TU Delft Library heeft recentelijk een Microsoft Surface aangeschaft, dit omdat de TU Delft Library wordt heringericht als onderdeel van het TU-brede ‘Learning Centre’[1] project. Het blijkt echter dat de Surface bijna niet wordt gebruikt door bezoekers. Vandaar dat het projectteam van de TU Delft Library de opdracht heeft geformuleerd een applicatie te ontwerpen en te maken voor de tafel, die ook aansluit bij de doelen van het Library Learning Centre (LLC). Na gesprekken met de opdrachtgever en betrokkenen is de volgende formulering van de opdracht tot stand gekomen: het maken van een werkende applicatie naar het ontwerp van de IO-studenten, met daarbij documentatie die het voor andere ontwikkelaars makkelijk maakt een applicatie te maken. Als eerste wordt in dit document de projectopdracht uiteengezet, dit gebeurt in hoofdstuk B.2. Daarna wordt onze beoogde aanpak omschreven in hoofdstuk B.3. Gevolgd door de projectinrichting in hoofdstuk B.4, een globale planning in B.5 en de kwaliteitswaarborging in hoofdstuk B.6.
B.2
Projectopdracht
In dit hoofdstuk wordt de opdracht afgebakend en vastgelegd zodat de Product Owners een beeld krijgen waaraan het product zal voldoen. Zo worden onder andere de doelstelling, de opdrachtformulering en de eisen uiteengezet.
B.2.1
Projectomgeving
De projectomgeving is de TU Delft Library. Hier staat een Microsoft Surface als onderdeel van het project van het LLC, echter wordt er door bezoekers niet genoeg gebruik gemaakt van de Surface. De reden dat er vrijwel geen gebruik gemaakt wordt van de tafel is het gebrek aan interessante applicaties. Er zijn veel idee¨en, maar deze zijn nog niet gerealiseerd.
35
B.2.2
Doelstelling project
De doelstelling van dit project is de Surface aantrekkelijker te maken voor bezoekers door een leuke applicatie te maken die aansluit bij de visie en doelen van het LLC. Daarnaast zal gewerkt worden aan producten waardoor het ontwikkelen van applicaties eenvoudiger wordt voor nieuwe ontwikkelaars.
B.2.3
Opdrachtformulering
De opdracht bestaat uit 3 delen: 1. Een werkende applicatie voor de Surface die in de hal staat (naar het ontwerp van de IO-studenten). Doelgroep: bezoekers Library (Jessica van den Doel overziet dit deel). 2. Het ‘onder de motorkap’-deel, dat moet voldoen aan een aantal technische eisen. Zoals herbruikbaarheid en onderhoudbaarheid. De bovengenoemde Surface applicatie dient als voorkant voor dit gedeelte. 3. Documentatie van de overwegingen (beslissingen) en producten (codes etc.) en toekomstig onderhoud van de applicatie.
B.2.4
Op te leveren producten en diensten
Tweewekelijks wordt volgens de Scrum ontwikkelmethodiek een volwaardig product opgeleverd (inclusief documentatie). Uiteindelijk wordt verwacht dat er een werkende applicatie is die aansluit bij de visie van het LLC met daarbij producten om het maken van toekomstige applicaties te vergemakkelijken.
B.2.5
Eisen en beperkingen
Eisen voor de applicatie zijn: • De applicatie moet in (goed) Engels zijn • De applicatie moet duidelijk in gebruik zijn. • De aangeboden informatie moet up to date zijn en aansluiten op de werkwijze van de TU, bijvoorbeeld door informatie aan te bieden op onderwerp volgens de Delft Research Initiatives (DRIs). • De applicatie moet zonder verder onderhoud functioneren. Het is dus niet de bedoeling dat er speciaal voor de Surface informatie geselecteerd moet worden.
B.3 B.3.1
Aanpak Methodiek
We zullen Scrum (een Agile ontwikkelmethode) toepassen met – in het begin – tweewekelijkse sprints. Na elke sprint moet er een werkbaar product met documentatie afgeleverd worden. Na elke sprint wordt er door de teamleden ge¨evalueerd, worden de vorderingen getoond aan belangstellenden en wordt vervolgens met de Product Owners de planning voor de volgende sprint opgesteld.
36
B.3.2
Technieken
Volgens de Scrum principes zullen we test-driven development toepassen. Voor het schrijven van de tests gebruiken we de NUnit tool.
B.3.3
Werkzaamheden
Tijdens de planning aan het begin van elke sprint worden de user stories gekozen welke zullen worden ge¨ımplementeerd. Vervolgens worden hier kleinere user stories en taken uit ontleed. Als die vast staan kan begonnen worden met de implementatie. Volgens het test-driven development model zal er eerst een test worden geschreven, waarna de feitelijke implementatie kan beginnen. Aan het einde van de sprint volgt een acceptatietest met de Product Owners en wordt er een richting gekozen voor de volgende sprints.
B.4 B.4.1
Projectinrichting Betrokkenen
Vanuit de bibliotheek zijn er twee groepen betrokken bij de ontwikkeling van de applicatie. Dit zijn de leden van het Library Learning Center, welke de transitie van bibliotheek naar algemene leerplek voor de universiteit begeleiden, en de ICT-afdeling. Ons contactpersoon bij het Library Learning is tevens onze opdrachtgever: Jessica van den Doel. Vanuit de ICT-afdeling worden we geholpen door Marjolijn Kuyper.
B.4.2
Informatie
Voor informatie over de verschillende architecturen kunnen we bij Marjolijn Kuyper terecht. Zij zal dan contactpersonen zoeken die meer informatie kunnen geven. Over de Surface is informatie van Microsoft beschikbaar. De vraag is echter of deze informatie voldoende is. Als we vragen hebben kunnen we deze stellen aan Koen Rotteveel, een Surface applicatieontwikkelaar bij DOK.
B.4.3
Faciliteiten
De bibliotheek heeft een kamer beschikbaar gesteld waar we kunnen werken. Verder is voor extra beeldschermen en muizen gezorgd. Voor het ontwikkelen is Microsoft Visual Studio 2008 benodigd. Wij gebruiken de professional versie, welke we via MA3D.com hebben verkregen via de TU-licentie. Er zijn twee Surface systemen beschikbaar, ´e´en in de centrale hal, de andere kunnen we gebruiken om te ontwikkelen en te testen.
B.5
Planning
Aangezien het plannen in Scrum door de Product Owners gebeurd, is het nog niet duidelijk wat de volledige planning wordt. Daarom is dit slechts een voorlopige planning. • Sprint 1 (18-4 tot 2-5): Ori¨entatieverslag en inlezen in WPF, Scrum, etc. • Sprint 2 (2-5 tot 18-5): Nieuwsfeeds tonen, plan van aanpak, Getting Started document.
37
• Sprint 3 (18-5 tot 1-6): Verdere features die later aan bod komen zijn: events bekijken op de Surface, user-gerichte content tonen, applicaties in HTML schrijven en tonen op de Surface. • Sprint 4 (1-6 tot 15-6): idem
B.6
Kwaliteitswaarborging
Om de kwaliteit van het product en het proces te waarborgen zullen wij verschillende methoden gebruiken. Deze worden in dit hoofdstuk worden besproken.
B.6.1
Productkwaliteit
De productkwaliteit wordt op twee manieren gewaarborgd. Om te controleren of de code blijft functioneren, zal de test-driven development worden gebruikt. Het is de bedoeling dat alle code gecovered wordt door deze tests, waarbij regressie (afnemende functionaliteit) kan worden opgemerkt. Om de software te valideren (voldoet het product aan de wensen van gebruikers) zal er, volgens de Scrum-methode, na elke sprint van twee weken een review meeting worden gehouden. Bij deze meeting wordt het tijdens de sprint geproduceerde product getoond. De Product Owner kan dan aangeven of er zaken verkeerd begrepen of ge¨ımplementeerd zijn. Vervolgens kan in de planning meet de prioriteit van taken worden veranderd en kunnen taken worden toegevoegd. Er wordt dan een set uitgekozen om de komende sprint aan te werken; de sprint backlog.
B.6.2
Proceskwaliteit
Documentatie Het is de bedoeling dat er drie verschillende vormen van documentatie worden opgeleverd. Allereerst moet de code natuurlijk voldoende en correct gedocumenteerd zijn. Daarnaast zal er in een verslag een overzicht worden gemaakt van de architectuur van de applicatie. Tot slot zal er een ‘getting started’ document gemaakt worden. Dit document wordt gemaakt om nieuwe ontwikkelaars op weg te helpen bij het maken van een nieuwe applicatie. Versiebeheer Als versiebeheersysteem is gekozen voor Git vanwege het eenvoudige branchen en mergen, wat het apart ontwikkelen van features een stuk eenvoudiger maakt. Dit komt de kwaliteit van het proces ten goede, aangezien men nieuwe functionaliteit apart van de gewone code kan ontwikkelen. Deze operaties zijn bij andere systemen een stuk kostbaarder. Hierover is meer te lezen in het Ori¨entatieverslag.
Referenties [1] TU Delft - Project Learning Centre. url: https://intranet.tudelft.nl/live/pagina. jsp?id=0d7f71e6-da47-40e6-b091-9ac9f7eba686&lang=nl (bezocht op 26-04-2011).
38
C Getting Started C.1
Inleiding
Het ontwikkelen van je eerste applicatie voor de Surface vereist de nodige kennis en onderzoek. We hebben jou een hoop werk bespaard, door in dit document een hoop informatie te verzamelen omtrent het ontwikkelen van een Surface applicatie voor de TU Delft. In hoofdstuk C.2 geven we je een aantal tools en tips qua voorbereidingen. Hoofdstuk C.3 helpt je op weg met het maken van je eerste simpele applicatie voor de Surface. Het uitrollen van een applicatie naar een Surface komt in hoofdstuk C.4 aanbod. In hoofdstuk C.6 behandelen we externe databronnen, zowel TU-specifiek als algemene bronnen. En tot slot lichten we het gebruik van een RFID lezer en de campuscard toe in hoofdstuk C.7.
C.2
Voorbereidingen
Voordat je kan beginnen met het ontwikkelen van een Surface applicatie is het belangrijk om de juiste tools te hebben. Het ontwikkelen gaat het beste in Microsoft Visual Studio C# 2008 Express Edition [7], omdat dit pakket de Surface Software Development Kit [6] (SDK) ondersteunt. De SDK bevat onder andere de Surface Simulator, die gebruikt kan worden om een applicatie eerst te testen vanuit de ontwikkelomgeving. De SDK vereist wel dat het XNA Framework [8] ge¨ınstalleerd is. Alle bovengenoemde software is gratis en te downloaden van de website van Microsoft. Offici¨eel wordt alleen Windows Vista 32-bit ondersteunt door de SDK als ontwikkelplatform, maar Brian Peek heeft een manier gevonden om de SDK ook op Windows 7 en 64-bit systemen te draaien. Hoe hij dit gedaan heeft is uitgebreid te lezen op zijn blog [5]. Nadat de tools ge¨ınstalleerd zijn ben je klaar om te beginnen met het ontwikkelen van een Surface applicatie.
C.3
Een applicatie ontwikkelen
Bij het maken van een nieuwe Surface applicatie heb je de keuze om een WPF-project of een XNA-project op te zetten. XNA wordt veel gebruikt voor het bouwen van games en biedt daar veel extra handige constructies voor. Als je een WPF-project opzet kun je de gebruikersinterface definieren in XAML, een variant van XML [15]. Op deze manier blijft de presentatie goed gescheiden van de logica. Omdat dit document meer gericht is op het gebruik van de specifieke databronnen in een Surface applicatie, zullen we niet stap voor stap uitleggen hoe je een Surface applicatie maakt. Wel geven we je een overzicht van handige bronnen en voorbeelden. Het ontwikkelen van je eerste simpele applicatie heeft Microsoft al stap voor stap beschreven in een tutorial [9]. Handig daarbij is de MSDN Library, die veel documentatie bevat over de beschikbare klassen en onderdelen voor de Surface [13]. Op MSDN is ook veel voorbeeldcode te vinden voor specifieke problemen. Er wordt een blog bijgehouden door Surface-ontwikkelaars, waar vaak handige informatie te vinden is en de ontwikkelingen van de Surface 2.0 in de gaten gehouden kunnen worden [14]. Een andere nuttige bron is het pakket met voorbeeld applicaties die bij de SDK meegeleverd wordt [11]. Het pakket bevat de broncode van een verzameling gevari¨eerde applicaties dat de mogelijkheden van de Surface goed demonstreert.
39
C.4
Een applicatie deployen
In elk Surface projectmap bevindt zich een XML bestand. In dit bestand staat aangegeven hoe de applicatie heet, welk icoontje erbij hoort, wat de locatie van de applicatie is en bijvoorbeeld de serienummers van de identity tags die de applicatie kan herkennen. Deze informatie is essenti¨eel bij het uitrollen van de applicatie op de Surface. Meer uitleg over deployment en deze XML bestanden is te vinden op Microsoft TechNet[10]. Om een applicatie uit te rollen op de Surface moet de Surface in de Administrator Modus[2] gebracht worden. Dit doe je door Ctrl+Alt+Delete op een op de Surface aangesloten toetsenbord in te drukken. Als je daarna op afmelden klikt, zal het loginscherm van Windows Vista verschijnen. Log in als Administrator en je ziet een normaal bureaublad zoals je die kent van een normale Windows computer. De C:\ProgramData\Microsoft\Surface\Programs map bevat de eerder genoemde XML bestanden. Plaats in deze map je eigen XML bestand en zorg dat de locatie die daarin beschreven is overeenkomt met de locatie van de applicatie op de harde schijf van de Surface. Let er wel op dat de TableUser-account de juiste rechten heeft voor de locatie van de applicatie. Als je dat gedaan hebt is de applicatie geregistreerd bij de Surface Shell en als de Surface terugkeert naar de User Modus verschijnt de applicatie in het menu van applicaties.
C.4.1
Attract en Single-Application Mode
De standaard ‘attract’ applicatie (de digitale vijver) is te vervangen door een andere applicatie. Zo kun je je nieuwe applicatie een tijdje uitlichten. Om een applicatie als attract-applicatie te gebruiken moet je er een nieuwe XML-file voor maken met een iets gewijzigde syntax. Vervolgens moet je in het register aangeven dat je er een andere attract-applicatie is en hoe het nieuwe XML bestand heet. Om een applicatie als attractapplicatie en als normale applicatie te draaien heb je dus twee verschillende XML-bestanden nodig. Specifieke instructies zijn te vinden op Microsoft Technet[1]. Het is niet aan te raden om een applicatie als attract-applicatie en als enige normale applicatie in te stellen, dit bleek zeer verwarrend te zijn voor gebruikers. Daarnaast is er ook een Single-Application Mode. Hierin is de Surface te gebruiken voor slechts ´e´en applicatie. De ‘access points’ zijn dan niet meer te gebruiken en de surface schakelt ook niet meer over naar een menu na inactiviteit. Het enige wat weergegeven wordt is de applicatie. Deze modus is aan te raden bij het demonstreren van een applicatie of als er slechts ´e´en applicatie getoond hoeft te worden op de tafel. Instructies zijn wederom te vinden op Microsoft Technet[3]. Tijdens ons project hebben we voor deze taken ook .reg bestandjes aangemaakt voor deze acties. Deze zijn bijgeleverd met dit document.
C.5
Internet in de TU-omgeving
Een stabiele internetverbinding is voor veel applicaties onmisbaar. Helaas bleek dit lastiger dan verwacht. Daarom zullen we hier toelichten wat onze bevindingen hierover zijn.
C.5.1
Draadloze verbinding
Initieel hebben wij verbinding proberen te maken met Eduroam via een van onze NetID’s. Dit gaat in Administrator Mode meestal goed. Het is echter zo dat bij het inloggen in het TableUser account deze verbinding niet goed opgezet wordt. De aanmeldprocedure met WPA2-enterprise
40
blijkt hiervoor te ingewikkeld. Ook heeft het Library Learning Center bij ons aangegeven dat vanwege de stabiliteit een draadloze verbinding niet gewenst is.
C.5.2
Ethernet verbinding
Het is voor alle apparaten binnen de TU wenselijk om offici¨eel ondersteund te worden. Hiermee kan je een vast IP krijgen en is support makkelijker. Het feit dat de Surface Vista draait leek in eerste instantie problematisch. Later bleek dat het voldoende was om een virusscanner (FSecure, via BlackBoard te downloaden) te installeren en automatische updates aan te zetten. Vervolgens kan een bedrade verbinding aangevraagd worden.
C.6
Externe databronnen gebruiken
Als de Surface verbonden is met het internet, gaan er tal van deuren open met betrekking tot het gebruik van externe databronnen. Voor een aantal van die bronnen hebben we het gebruik ervan gemakkelijk gemaakt.
C.6.1
Nieuwsberichten via RSS
Voor het ophalen en uitlezen van nieuwsberichten hebben we een C#-library gemaakt. Deze allesomvattende verzameling van klassen biedt een generieke toegang tot RSS-feeds die op internet worden aangeboden. De library houdt zelfs rekening met een slechte internet verbinding en cached foto’s en berichten lokaal op de harde schijf, zodat de gebruiker altijd iets heeft om te lezen. De newsfeed library gebruiken Om te beginnen kun je het architectuur document van de library doorlezen. Dit document bevat veel technische details over de werking van de klassen in de library. De configuratie van de library gaat via een XML-bestand die je aan de FeedFactory kunt meegeven. De FeedFactory geeft op zijn beurt een FeedManager object terug waartegen gezegd kan worden dat de nieuwsberichten opgehaald moeten worden (zowel synchroon als asynchroon). Als de nieuwsberichten binnen zijn zal er een ‘changed’ event opgegooid worden die door de applicatie afgevangen kan worden. Een beknopt voorbeeld voor het gebruik van de library vind je in listing C.1. Een uitgebreider voorbeeld is onze ‘Stay in Touch’ applicatie, die bijna alle features van de library gebruikt. 1 2 3 4 5 6 7 8 9 10 11 12
// Read the XML file FeedManager manager = FeedFactory.CreateFromFile("feeds.xml"); // Get items from cache manager.GetItems(); // Register event handler manager.Changed += delegate { Console.WriteLine("Updated!"); // Get up-to-date items manager.GetItems(); }; // Refresh items from the internet (asynchronous) manager.Load(); Listing C.1: Applicatie voorbeeld
41
C.6.2
TU Delft Personendatabase
Een interessante bron is de personendatabase van de TU Delft. In deze database staan de gegevens van alle studenten en werknemers. Waardevolle velden zijn: tudSurfDisplayName (volledige naam), mail (emailadres), nlEduPersonStudyBranch (opleiding), nlEduPersonOrgUnit (afdeling), tudAdsCompany (faculteit), tudCampusCardNumber (kaartnummer) en preferredLanguage (voorkeurstaal). De communicatie met de database verloopt via het LDAP protocol en is beveiligd met SSL (LDAPS). Voor de ontwikkelfase is er een test-server beschikbaar. Het adres van deze server is mdst1.tudelft.nl en luistert naar poort 636. Om toegang te kunnen krijgen via LDAP heb je account nodig die voldoende rechten heeft. Als je een account aan wilt laten maken kun je contact opnemen met Wim Penninx <
[email protected]>. Een simpel maar volledig werkend codevoorbeeld dat communiceert met de mdst1 server is te vinden in de src/Ldap/ map.
C.7
De RFID lezer gebruiken
De RFID lezer kan gebruikt worden om gegevens van de TU campuscard te lezen. Het vijfde datablok bevat bijvoorbeeld het kaartnummer in BCD (binary-coded decimal) formaat. Het kaartnummer kan vervolgens gekoppeld worden aan de persoonsdatabase van de TU om meer gegevens van een student of medewerker op te halen.
C.7.1
De kaartlezer gebruiken
De huidige kaartlezer is een Omnikey 5321 USB lezer. Dit apparaat is een combinatie van twee lezers, een contactloze en een niet-contactloze. Er bestaan verschillende libraries die smartcard readers kunnen aansturen. De gratis API van CardWerk [12] is een highlevel API die gebruik maakt van de (unmanaged) winscard.dll library. Volgens de website staat ondersteuning voor de Omnikey SyncApi (die nodig is voor de Mifare-chip, die wordt gebruikt in de Campuscard) op de planning, maar is nog niet ge¨ımplementeerd in de huidige versie. Als alternatief zijn we begonnen met het schrijven van onze eigen smartcard library, helaas is de ontwikkeling hiervan stopgezet wegens hogere prioriteiten van andere elementen. De broncode is meegeleverd in de src/SmartCard/ map.
C.7.2
De Campuscard
De zelf geschreven library roept vanuit C# de winscard.dll aan voor het algemene smartcard protocol, zoals het verbinden met een smartcard (SCardConnect). Zodra er een verbinding is opgezet met een Mifare smartcard, worden de specifieke Mifare commando’s naar de kaart gestuurd. Hiervoor wordt de CardMan Synchronous API van Omnikey [4] gebruikt. Die API bevat de scardsyn.dll waarin functies zitten voor de communicatie met een Mifare kaart. Vooral de SCardCLMifareStdAuthent en de SCardCLMifareStdRead functies zijn belangrijk voor het lezen van de data op de kaart. De handleiding van de API bevat veel informatie over de betreffende functies. Wanneer er een Mifare-kaart gedetecteerd wordt, kan het vijfde datablok (block no. 4) opgevraagd worden om het kaartnummer van de Campuscard uit te lezen. Welke in BCD formaat in dat datablok is opgeslagen. Het uitlezen van de blokken vereist authenticatie. De A-sleutel voor het authenticeren van de eerste acht blokken is A0A1A2A3A4A5. De huidige staat van de library biedt al functionaliteit om het nummer van een campuscard uit te lezen, maar vereist nog wel de nodige stabiliteitstests.
42
Referenties [1] Adding Custom Attract Applications. url: http://technet.microsoft.com/en-us/libr ary/ee692165%28Surface.10%29.aspx (bezocht op 20-06-2011). [2] Administrator Mode and User Mode. url: http://technet.microsoft.com/en-us/libr ary/ee692042(Surface.10).aspx (bezocht op 16-05-2011). [3] Deploying Only One Application on a Microsoft Surface Unit. url: http://technet.micr osoft.com/en-us/library/ee692280%28Surface.10%29.aspx (bezocht op 20-06-2011). [4] Downloads - Omnikey. url: http://www.hidglobal.com/driverDownloads.php?tech Cat=19&prod_id=171 (bezocht op 06-06-2011). [5] Install the Surface SDK SP1 Workstation Edition on x64. url: http://www.brianpeek. com/blog/archive/2009/05/14/install-the-surface-sdk-sp1-workstation-editio n-on-x64.aspx (bezocht op 11-05-2011). [6] Microsoft Surface SDK 1.0 SP1 Workstation Edition. url: http://go.microsoft.com/f wlink/?LinkID=164792 (bezocht op 11-05-2011). [7] Microsoft Visual Studio C# 2008 Express Edition. url: http://www.microsoft.com/ex press/Downloads/#Visual_Studio_2008_Express_Downloads (bezocht op 11-05-2011). [8] Microsoft XNA Framework Redistributable 2.0. url: http://go.microsoft.com/fwlink/ ?LinkID=78244 (bezocht op 11-05-2011). [9] Quick Starts. url: http://msdn.microsoft.com/en-us/library/ee804800(v=Surface. 10).aspx (bezocht op 16-05-2011). [10] Registering a Microsoft Surface Application with Surface Shell. url: http://technet.mi crosoft.com/en-us/library/ee692074(Surface.10).aspx (bezocht op 16-05-2011). [11] Sample Applications. url: http : / / msdn . microsoft . com / en - us / library / ee80486 6(v=Surface.10).aspx (bezocht op 16-05-2011). [12] Smart Card Access for .NET Developers. url: http://smartcard-api.com (bezocht op 06-06-2011). [13] Surface SDK 1.0 SP1. url: http : / / msdn . microsoft . com / en - us / library / ee80476 7(v=Surface.10).aspx (bezocht op 16-05-2011). [14] The Microsoft Surface Blog. url: http : / / blogs . msdn . com / b / surface/ (bezocht op 16-05-2011). [15] XAML Overview. url: http://msdn.microsoft.com/en-us/library/ms752059(v=VS.9 0).aspx (bezocht op 16-05-2011).
43
D Architectuur NewsFeed D.1
Inleiding
Omdat er op het internet veel verschillende bronnen met interessant nieuws te vinden zijn hebben we de architectuur zo modulair mogelijk opgebouwd. Zo is het makkelijker om verschillende nieuwsbronnen toe te voegen, te bewerken en op te vragen. Daarnaast verhoogt dit ook de onderhoudbaarheid van de applicatie. Hoofdstuk D.2 beschrijft de gebruikte datastructuren voor het lezen van nieuwsberichten. Het opvragen en opslaan van feeds wordt toegelicht in hoofdstuk D.3. In hoofdstuk D.4 komt de configuratie aan bod. Tot slot behandeld hoofdstuk D.5 de foutdetectie.
D.2
Datastructuren
In figuur D.1 is middels een klassediagram schematisch weergegeven hoe de data opgebouwd is. De nieuwsfeeds worden opgedeeld in NewsItem objecten, deze bevatten een titel, omschrijving, bron, datum, afbeelding en een link naar een item. De afbeelding die de NewsItem mogelijk bevat wordt lokaal opgeslagen, dit zorgt ervoor dat deze al kan worden geladen voordat het NewsItem wordt getoond. We gebruiken drie soorten klassen die allemaal de interface INewsFeed implementeren; Feeds, Decorators en Aggregators. Daarnaast bestaan er Imageselectors die afbeeldingen kunnen selecteren als die via bekende extensions toegevoegd zijn aan een feed.
D.2.1
INewsFeed
Elke feed implementeerd de INewsFeed interface. Deze interface bestaat uit vier methoden, een event en een property: Changed Een event welke wordt opgegooid als de de items van de feed veranderd kunnen zijn. Het kan gebeuren dat de inhoud van GetItems() niet veranderd is na het opgooien van het event, dit is afhankelijk van de toegepaste decorators. ExceptionHandler Een delegate welke wordt aangeroepen als zich exceptions hebben voorgedaan. Een delegate is het C# concept om methoden als type te gebruiken. Dit wordt gebruikt omdat het laden van feeds in andere threads gebeurd, waardoor normale exceptions niet kunnen worden gebruikt. Load() Ververs de feed asynchroon. Als er nieuwe items zijn gevonden, wordt een Changed event getriggerd. Load(asynchronous) Identiek aan Load(), maar met de keuze of het laden synchroon of asynchroon moet gebeuren. GetItems() Geeft de beschikbare items terug. GetHashCode() Geeft de hash code terug voor de feed, deze wordt onder andere gebruikt voor het cachen van de feeds. Voor de hash zijn enkel de titel van de feed, het type van de classe en de hashes van de interne feeds van belang.
44
Figuur D.1: Klassediagram van de feeds
D.2.2
Feeds
Een Feed klasse neemt het inlezen van een feed vanaf het internet voor zijn rekening. De kennis voor een bepaald formaat (RSS, Atom, etc.) hoeft op die manier alleen in de betreffende Feed klasse bekend te zijn. Op dit moment is alleen de RSS specificatie ge¨ımplementeerd. Standaard wordt elke vijf minuten gecontroleerd of de content van de aanbieder is veranderd. Als dit het geval is wordt de nieuwe content opgehaald en verwerkt, vervolgens wordt er een ‘changed’ event opgegooid waarop de applicatie kan reageren.
D.2.3
Decorators
Om de functionaliteit van de feeds uit te breiden maken we gebruik van het decorator ontwerppatroon. Decorators voeren een bepaalde handeling uit op alle NewsItems die opgevraagd worden. Ze converteren NewsItems of filteren NewsItems weg die niet voldoen aan bepaalde criteria. Elke decorator is gebaseerd op de Decorator basisklasse, die op zijn beurt INewsFeed implementeerd. De basisklasse biedt functionaliteit voor het opvangen en doorgeven van de feed-content. Om duplicatie tegen te gaan is er een superklasse Decorator gemaakt. Deze klasse geeft generieke implementaties van methoden voor decorators die slechts ´e´en feed aanpassen. Alle decorators behalve de FeedAggregator erven over van de Decorator klasse. Insufficient data Soms bevat een nieuwsbericht niet genoeg gegevens. Een titel, datum of omschrijving kan ontbreken. In bepaalde gevallen moeten deze berichten dan niet doorgegeven worden aan de applicatie. Als de Insufficient data decorator gebruikt wordt zullen de berichten zonder titel of omschrijving weggelaten worden.
45
HTML De nieuwsberichten bevatten vaak HTML opmaak, bijvoorbeeld
tekst voor vette tekst. De gebruikersinterface weet niet goed hoe de HTML tags ge¨ınterpreteerd moeten worden. Hier komt de HTML decorator goed van pas, die filtert namelijk alle HTML-tags in een nieuwsbericht weg. Op deze manier blijft alleen platte tekst over die makkelijk getoond kan worden. HTML character Er staan niet alleen HTML opmaaktags in nieuwsberichten, maar vaak ook losse HTML karakters. Bijvoorbeeld & voor een &-teken. De HTML character decorator converteert alle speciale HTML karakters naar hun juiste representatie, zodat de tekens goed worden doorgegeven aan de applicatie. Image cache Een andere interessante toepassing van het decorator-patroon is dat er op eenvoudige wijze een cache mee ge¨ımplementeerd kan worden. Als deze decorator tussen de feed en de applicatie zit, zal hij steeds de nieuwsberichten voorzien van een URL die wijst naar de afbeeldingen die lokaal opgeslagen zijn. Op die manier hoeven niet steeds alle afbeeldingen van het internet gedownload te worden en duurt het niet lang voordat de berichten geladen zijn in de applicatie. Natuurlijk moet de cache wel up-to-date blijven met de actuele berichten. Dit gebeurt als volgt: als de decorator een ‘Changed’ event van onderaf (de bron) ontvangt, zal hij de afbeeldingen van de nieuwe berichten gaan opslaan op de schijf. Als dit voltooid is wordt het event verder omhoog gegooid. De applicatie merkt er dus helemaal niets van, het duurt slechts wat langer voordat het event aankomt in de applicatie. Vervolgens zal de applicatie de berichten gaan opvragen. Hij ontvangt dan nietsvermoedend items vanuit de cache. Om te zorgen dat deze cache niet te veel schijfruimte in neemt worden bestanden die niet langer nodig zijn automatisch weggegooid. Feed cache De Feed cache heeft veel overeenkomsten met de Image cache, maar het grote verschil is dat deze decorator de nieuwsberichten zelf cached in plaats van de afbeeldingen. Net als de Image cache zal deze decorator steeds de gecachte berichten teruggeven op het moment dat van bovenaf de berichten gevraagd worden. De gecachte berichten worden gelezen uit een bestand waarin de berichten geserialiseerd (een binair formaat) opgeslagen zijn. Ook hier geldt dat de cache up-to-date moet blijven. Als de decorator een ’change‘ event van onderaf ontvangt, zal hij de nieuwe berichten serialiseren en opslaan. Vervolgens wordt het event verder omhoog doorgegeven naar andere decorators en zal uiteindelijk bij de applicatie terechtkomen. Flickr Dit is een decorator die gemaakt is voor een specifieke bron, namelijk voor Flickr feeds. De beschrijvingen van Flickr foto’s bevatten de naam van de fotograaf. Deze decorator zoekt en verplaatst deze naam van de beschrijving naar het dataveld dat de bron bevat. Zo wordt de naam van de fotograaf netjes weergegeven boven de bron van de feed. Tweakers Ook deze decorator is voor een specifieke bron gemaakt, namelijk Tweakers.net. De feeds van Tweakers.net bevatten soms een paar advertenties. De taak van deze decorator is simpel: hij
46
filtert deze advertenties weg.
D.2.4
Aggregators
De aggregator dient ervoor om meerdere feeds samen te voegen. De aggregator doet zich voor als zijnde een enkele feed, daarom kunnen hierop desgewenst weer een aantal decorators losgelaten worden. Hierdoor kunnen nieuwsfeeds op een modulaire wijze gekoppeld worden.
D.2.5
Image selectors
Meestal zijn de locaties van afbeeldingen in een of andere vorm aanwezig in de feeds, maar omdat er meerdere standaarden zijn voor het meegeven van afbeeldingen, zal dit per bron verschillen. Om deze reden zijn de Image selectors bedacht. Een Image selector is een klasse die maar twee methoden implementeert, namelijk het zoeken van afbeeldingen en het vinden van een eventuele beschrijving van de afbeelding. Voor elke feed die afbeeldingen bevat zal er een Image selector gespecificeerd moet worden, die dan voor elk nieuwsbericht opzoek gaat naar een afbeelding. Elke specifieke Image selector is gebaseerd op een basisklasse, deze klasse biedt onder andere functionaliteit om de URL van een afbeelding te vertalen. Dit is in het bijzonder handig bij feeds die URL’s meegeven die wijzen naar foto’s met een lage resolutie. De aanwezige functionaliteit kan dan gebruikt worden om de URL’s te vertalen, zodat ze wijzen naar een andere versie van de foto’s met een hogere resolutie (mits beschikbaar). Bijvoorbeeld: www.feed.nl/image_small.jpg kan vertaald worden naar www.feed.nl/image_large.jpg. Enclosure tag Een van de manieren om een afbeelding mee te geven is de enclosure tag. Deze manier wordt gebruikt door de website nu.nl. Een voorbeeld van een enclosure tag: <enclosure url="http://path/to/image.jpg" type="image/jpeg" /> Media content tag Deze selector werkt hetzelfde als de vorige. Het verschil is de tagnaam: niet <enclosure>, maar <media:content>. Een voorbeeld: <media:content url="http://path/to/image.jpg" type="image/jpeg" /> Content tag De content tag is iets ingewikkelder omdat er een
![]()
tag in staat. De selector is ook in staat de beschrijving uit het title-veld te lezen. De website van de nrc.next gebruikt deze vorm. Een voorbeeld van een content tag:
Description tag Deze selector werkt in grote mate hetzelfde als de Content tag selector, maar deze selector opereert op het description veld. Een voorbeeld: <description>
47
D.3
Opslaan en opvragen van feeds
Feeds die ‘af’ zijn worden bijgehouden als FinalFeeds, af betekend hier dat het een laatste INewsFeed moet zijn in een keten van feeds, decorators of aggregators. Een FinalFeed bevat tevens metadata over de feed zoals de titel, een representatieve illustratie en informatie over talen en categorie¨en waartoe de feed behoort. Slechts deze FinalFeeds worden doorgegeven naar buiten het model. Hierdoor blijven feeds, decorators en aggregators verborgen voor applicaties die dit framework gebruiken. Een FinalFeed krijgt zowel een verzameling woorden mee voor de taal waarin de feed geschreven is, als een lijst van de categorie¨en waartoe hij behoort. Dit maakt het mogelijk voor een applicatie om nieuwsberichten te filteren op taal en/of categorie. De module die hiervoor gebruikt wordt is de FeedManager. Deze weet welke talen en categorie¨en aanwezig zijn en kan deze op aanvraag doorgeven.
D.4
Configuratie
Om de nieuwsfeeds correct te configuren, is er een factory klasse gemaakt welke de feeds op de goede manier cre¨eert. Deze factory neemt een configuratiebestand aan die met een XML structuur aangeeft hoe de feed moeten worden samengesteld. Het voordeel van het gebruik van een factory ten opzichte van het direct construeren van de feeds in de controller, is dat de controller niet hoeft te worden veranderd als de interface van de Newsfeed klassen verandert.
D.4.1
Configuratiebestand
Zoals eerder aangegeven is het configuratiebestand een XML bestand waarin voorlopig enkel de feedhi¨erarchie wordt beschreven. Bij het ontwerpen van de layout is rekening gehouden met andere opties die in de toekomst moeten worden toegevoegd in de configuratie. Daarom is er voor gekozen om het root element niet ‘feeds’ maar ‘config’ te noemen. Een voorbeeld bestand staat in figuur D.2. Voor een correcte definitie van het XML bestand en een gemakkelijke parsing is er een XML Schema voor het configuratiebestand. Dit schema kan door programma’s worden gebruikt om te controleren of een configuratiebestand correct is.
D.4.2
Factory
De factory maakt gebruik van de reflection mogelijkheden van C#. Deze functionaliteit maakt het mogelijk om tijdens het draaien van het programma informatie op te vragen over objecten en dit te gebruiken. Door middel van reflection wordt een klasse ge¨ınstantieerd die staat gedefini¨eerd in het configuratiebestand. Dit levert twee voordelen op: • De code wordt beter onderhoudbaar, doordat er geen aanpassingen hoeven te worden gedaan aan de factory als er een nieuwe decorator of feed wordt toegevoegd. • Nieuwe decorators en feeds kunnen ook in andere assemblies worden toegevoegd dan de assembly waar de factory in staat. Dit maakt het mogelijk om nieuwe decorators en feeds te defini¨eren als men geen toegang heeft tot de broncode van de factory.
48
Figuur D.2: Een voorbeeld configuratiebestand.
h t t p : //un . a v a i l a b . l e < f i n a l f e e d t i t l e =” n r c . next b e e l d ” image=” h t t p : //www. n r c n e x t . n l / f i l e s /2010/01/LogoNRCTvDIAPb−200x246 . j p g ”> Photo News Dutch < f i n a l f e e d t i t l e =” Fokke en Sukke ” image=” h t t p : //www. f o k s u k . n l / images / d e f a u l t / f o k s u k n l . g i f ”> Comic Dutch
49
D.5
Foutdetectie bij inladen feeds
Ondanks dat we het framework zo generiek mogelijk hebben willen houden moesten we dit principe voor verschillende feeds helaas wat bijstellen. Door beperkte RSS-standaarden bijvoorbeeld, plaatjes worden op allerlei manieren in feeds gezet. We hebben dus gekozen voor specifiekere aanpassingen per feed omdat we wel over plaatjes wilden beschikken. Deze aanpassingen brengen wel het risico mee dat ze niet meer werken als een website de inrichting van zijn feeds aanpast. De Product Owners hebben de wens uitgesproken dat dergelijke fouten gedetecteerd worden door de applicatie zelf, waarna bijvoorbeeld een mail verstuurd wordt naar een beheerder. Deze functie is in het framework ingebouwd middels de FeedParseException. Deze wordt opgegooid als minder dan 50% plaatjes wordt ingeladen, of als een feed niet goed ingelezen wordt door het Argotic framework. Deze excepties kunnen door een controller opgevangen worden om vervolgens naar een log weg te schrijven, via een mail te versturen, of een seintje bij Nagios af te leveren. Omdat het parsen van feeds regelmatig in een andere thread draait, is er een ExceptionHandler gemaakt. Dit is een delegate welke kan worden aangegeven door de applicatie die de NewsFeed library gebruikt. Deze applicatie kan vervolgens zelf de benodigde actie bepalen.
50
E Architectuur Stay in Touch E.1 E.1.1
Algemeen Architectuur
Voor de Stay in Touch applicatie hebben wij ervoor gekozen om een model-view-controller pattern (MVC) te implementeren. Daarin wordt een duidelijke scheiding gemaakt tussen het model van de data, de weergave (view) naar de gebruiker toe, en de communicatie (controller) tussen die twee. Enkele voordelen hiervan zijn dat het model of de view gewijzigd kan worden zonder dat de rest van de applicatie gewijzigd hoeft te worden. Ook maakt deze scheiding het mogelijk om (bijna) de hele applicatie automatisch te testen, omdat er geen domein-logica meer in de gebruikersinterface verweven zit. Testen zonder het gebruik van MVC is veel moeilijker. Communicatie tussen de componenten Bij Microsoft is een hoop gedaan aan WPF om het gebruiken van het MVC-pattern makkelijk te maken. Op http://www.codeproject.com staat hier een zeer duidelijk artikel over [3]. Voor het doorgeven van gebruikersacties van de view maken we gebruik van de zogenaamde event routing infrastructure van WPF. Hiermee kan je acties doorgeven middels semantische beschrijvingen van acties en hoef dus je niets te weten van de implementatie van andere componenten. Ook het doorgeven van wijzigingen aan de view gebeurt middels generieke onderdelen in WPF. Models kan je namelijk binden aan bepaalde elementen in je view. Hierbij kan je in je control echter weer in het midden laten hoe de view werkt. WPF maakt namelijk een ICollectionView wrapper aan om het view-element heen. Wat daarbinnen dan precies gedaan wordt in de view is voor de control wederom onbelangrijk. Veranderingen in de models worden met Changed events doorgegeven vanuit de NewsFeed library, daarvoor is dus nog wel model-specifieke kennis nodig. Idealiter zouden we dit ook via de event routing infrastructure oplossen om nog meer modulariteit te bereiken. Dit is echter niet gedaan, omdat de NewsFeed library zo generiek mogelijk is gehouden.
E.1.2
User Interface
Voor het ontwerpen van de user interface (UI) gebruiken wij het grafische subsysteem van Microsoft, de Windows Presentation Foundation (WPF)[4]. Door het gebruik van een vectorieel grafisch systeem is het mogelijk een beter ontwerp te maken van besturingselementen. Verder maken wij ook gebruik van XAML, een declaratieve taal van Microsoft gebaseerd op XML[5]. XAML dient als markup-taal voor het defini¨eren van UI-elementen. Alles wat in XAML wordt aangemaakt kan ook worden gedaan met C#. Wij hebben echter de keuze gemaakt om UI-elementen te defini¨eren in XAML, omdat dit minder regels code nodig heeft wat ten goede komt van het overzicht. Ook geeft het een goede scheiding tussen aanmaken van de UI-elementen en de logica achter deze elementen.
E.1.3
Logging
Om op afstand problemen vast te stellen moeten deze worden gelogd. Vanuit de Library is aangegeven dat hiervoor binnen de ICT afdeling met Nagios wordt gewerkt. Dit framework wordt op het moment echter alleen voor Unix servers gebruikt. Het is wel de bedoeling dat 51
Nagios ingezet gaat worden voor het monitoren van computers met Windows, maar dit is nog niet gedaan. Aangezien Nagios het Windows Event Log kan uitlezen, is besloten fout- en debugmeldingen naar dit log weg te schrijven. Om dit te doen is een Logging interface gemaakt welke wordt geimplementeerd door de WindowsEventLogger klasse. Deze klasse wordt vervolgens gebruikt om meldingen naar het log weg te schrijven.
E.2 E.2.1
Nieuwsberichten bekijken Data architectuur
De onderliggende data architectuur voor de nieuwsfeeds is ondergebracht in het framework. Een nieuwsfeed bevat NewsItem objecten, deze bestaan uit de titel, omschrijving, bron, datum, het plaatje en de link naar het item. De controller houdt een lijst bij van NewsItems die getoond moeten worden. Deze items zitten in een ObservableCollection, een dynamische datacollectie die een notificatie geeft als de verzameling verandert. Door deze eigenschap kan de controller elementen op het scherm veranderen door slechts de elementen in de lijst aan te passen. De controller hoeft op deze manier geen weet te hebben van de weergave van de elementen.
E.2.2
User Interface
“Als student wil ik een nieuwsbericht kunnen bekijken en kunnen doorschuiven naar iemand anders zodat ik er over kan napraten en om een huiskamer gevoel te krijgen.”
Figuur E.1: Twee verschillende ontwerpen voor NewsItems
52
Ontwerp Bij het maken van de NewsItem elementen moet er rekening worden gehouden met de mogelijke inhoud, zie E.2.1. De NewsItems tonen de titel, de datum en de bron van het niewsbericht. Daarnaast wordt de omschrijving van het niewsbericht weergeven als deze er is. Het grote verschil in ontwerp tussen de nieuwsberichten is het hebben van wel of geen foto zoals te zien in figuur E.1, daarbij is ook een onderscheid gemaakt tussen NewsItems met een grote of kleine foto. Implementatie De berichten moeten kunnen worden bekeken door alle gebruikers, dus kunnen draaien en over de tafel worden geschoven. Een ScatterView biedt deze functionaliteit, het is een container voor ScatterViewItems, die op hun beurt weer allerlei objecten kunnen bevatten. De gehele oppervlakte van de tafel is tijdens de applicatie een ScatterView waarin de NewsItems worden gestopt. De ScatterViewItems met NewsItems erin kunnen worden gedraaid, geschaald en geschoven. Om de NewsItems in de ScatterView te krijgen maken we gebruik van Binding [1]. Hierbij verbinden we de ScatterView aan de ObservableCollection waar de NewsItems in zitten. De opmaak van de ScatterViewItems wordt gedefinieerd door een DataTemplate met een Grid voor de layout van het NewsItem object. Voor de drie verschillende ontwerpen, met groot, klein of zonder plaatje, zijn ook drie verschillende DataTemplates. De juiste DataTemplate wordt gekozen door een TemplateSelector klasse die logica bevat om te bepalen welk template wordt toegewezen aan een ScatterViewItem. Om de grootte van de NewsItems goed te krijgen wordt de mogelijkheid om ze te schalen uit gezet op het moment dat ze worden gecre¨eerd. De ScatterViewItem schaalt dan naar de juiste grootte om alles erin te passen, deze afmetingen worden als MaxHeight en MaxWidth gezet. Vervolgens zetten we de mogelijkheid om de NewsItems te schalen weer aan. Een van de wensen is het verschijnen van NewsItems met een effect, bijvoorbeeld dat het lijkt alsof ze op de tafel geschoven worden. Dit kan door aan de ScatterView een ItemContainerStyle toe te voegen. Hierin wordt de Style gedefini¨eerd die wordt toegepast op alle ScatterViewItems die worden gemaakt. Door binnen deze Style events op te vangen en daaraan een animitie te koppelen kunnen de ScatterViewItems binnen de ScatterView worden geanimeerd. Bij het vergroten en het verkleinen van een NewsItem wordt een SizeChanged event veroorzaakt. Aan de hand van dit event wordt gekeken naar de grootte van het NewsItem. Wat er vervolgens gebeurt met het NewsItem is afhankelijk van het soort NewsItem, dit is te zien in figuren E.2 en E.3. De NewsItems kunnen op twee manieren worden vergroot, de eerste manier is door het object op twee punten aan te raken en deze punten van elkaar weg te slepen. De andere manier om een bericht te vergroten is door er twee keer op te drukken. Het NewsItems zal dan schalen naar zijn maximale grootte. Dit is een gebruikelijke manier om op andere touch-apparaten objecten te vergroten. NewsItems met grote foto’s hebben ook een enkele ContactTapGestures event. Als dit event wordt getriggerd en het NewsItem is groot genoeg, dan worden de titel en omschrijving weggelaten/getoond.
E.2.3
Design
Bij het designen van de NewsItems hebben we gekeken naar inhoud die interessant is om op de NewsItems te tonen. Wij hebben gekozen voor de volgende vijf elementen: 1. Titel; de titel laten zien spreekt voor zich, dit vat het nieuwsbericht samen en trekt de aandacht.
53
(a) Kleine weergave
(b) Grote weergave
Figuur E.2: NewsItems met een kleine foto en een omschrijving 2. Relatieve tijd; als je een nieuwsbericht leest wil je weten hoe recent het is. Van een bericht dat minder dan ´e´en uur oud is, wordt het aantal minuten getoond. Daarna wordt tot 12 uur het aantal uren dat het bericht oud is getoond, daarna ‘yesterday’ en als het bericht meer dan twee dagen oud is, de datum van het bericht. 3. Omschrijving; een titel alleen is niet altijd genoeg, in de omschrijving wordt kort omschreven wat het nieuwsbericht inhoud. 4. Bron; waar het nieuwsbericht vandaan komt is informatie waar lezers veel waarde aan hechten, dit is een van de manieren waarop lezers hun nieuws filteren. 5. Foto; uit vergaderingen en vroege tests met de applicatie bleek snel dat NewsItems met foto’s goed de aandacht trekken van gebruikers. Omdat niet altijd alle elementen worden ingevuld hebben we ervoor gekozen om verschillende templates te maken, in totaal drie. De datum en de bron zijn altijd aanwezig, hier maken we dus geen onderscheid tussen. Als een nieuwsbericht alleen een titel heeft, dan tonen we het hele bericht niet. Naast de verschillende templates maken we ook gebruik van semantic zooming, waarbij de opmaak van het object afhankelijk is van de grootte [2]. Bij de NewsItems met alleen een titel en een omschrijving gebeurt er niets als de grootte van het Item veranderd. Deze zien er altijd uit als in figuur E.2a. De NewsItems met een kleine foto en een uitgebreide beschrijving tonen bij een kleine weergave alleen de tekst, zodra het NewsItem vergroot wordt zal ook de foto worden getoond, dit is te zien in figuur E.2, ze beginnen altijd groot genoeg zodat de foto wordt getoond. De NewsItems waarbij de afbeelding het belangrijkste onderdeel van het object is, zullen als ze klein zijn alleen de afbeelding, bron en de datum van het NewsItem te zien zijn. Zodra de NewsItem van voldoende grootte is, worden ook de titel en de omschrijving (als deze aanwezig is) getoond, zoals te zien in figuur E.3. De titel en omschrijving kunnen worden weggelaten door eenmaal te tappen op het nieuwsbericht. Om het verschil tussen de verschillende feeds duidelijk te maken zijn er kleuren toegekend per feed. Deze zijn terug te zien in de border van het item en in vorm van een gradient in de achtergrond, bij de nieuwsberichten met grote foto’s is de kleur niet terug te vinden. De mogelijkheid dat de foto vloekt bij de feed kleur is zo vermeden.
54
(a) Kleine weergave
(b) Grote weergave
Figuur E.3: NewsItems met een grote foto en (mogelijk) een omschrijving
E.3
Nieuws filteren
Elke gebruiker heeft zo zijn eigen interesses, dus hebben we ervoor gekozen om een filter aan de applicatie toe te voegen waar de gebruiker een filter op zijn of haar voorkeuren kan instellen.
E.3.1
Data architectuur
Voor het filteren van de NewsItems die getoond worden bleek het filteren op taal en categorie voldoende te zijn. Welke taal en categorie bij een feed horen kan de beheerder zelf aangeven in het configuratiebestand. Filterknoppen voor deze talen en categorie worden dan vanzelf aangemaakt in het filtermenu. Als het filter wordt aangepast op de tafel, dan wordt de staat van de filters doorgestuurd naar de Controller waarna die bij het Model de juiste items opvraagt. Op deze wijze hebben we ervoor gezorgd dat de getoonde feeds volledig aanpasbaar zijn middels het XML configuratiebestand, wat het gebruik en up-to-date houden van de applicatie zeer ten goede zal komen.
E.3.2
User Interface
Het is van belang dat de applicatie er zo aantrekkelijk mogelijk uit blijft zien, zodat mensen naar de tafel toe getrokken worden. Als de Surface achtergelaten wordt met een geactiveerd filter, dat alleen maar tekstberichten bevat, zal het er niet erg aantrekkelijk uitzien voor nieuwe gebruikers. Om dat te voorkomen zal na vijf minuten inactiviteit automatisch weer een mix van foto’s en tekstberichten uit verschillende bronnen op de Surface verschijnen. Ontwerp Het filtermenu moet duidelijk laten zien wat de actieve filters zijn. Er twee manieren om het nieuws te filteren: op taal en op categorie. De inhoud van deze secties wordt gevuld door de verschillende talen en categorie¨en van de aangeleverde feeds, zie E.3.1. Om te zorgen dat de tafel niet leeg wordt als alle filters uit staan, worden — als dat het geval is — alle feeds getoond. Om het overzicht op de tafel te behouden is het maximum aantal NewsItems dat tegelijk op de tafel wordt getoond twintig.
55
Figuur E.4: Het filtermenu om talen en categorie¨en te selecteren Implementatie Om de lay-out van het filtermenu makkelijk te houden, wordt gebruik gemaakt van een StackPanel. Een StackPanel plaatst toegevoegde elementen onder elkaar. De elementen voor de soorten filters zijn WrapPanels, deze nemen de ruimte die nodig is om alle filters binnen het WrapPanel te tonen. De filters zelf zijn ToggleButtons, deze geven duidelijk aan wanneer een filter aan of uit staat. De logica van de filters is als volgt; de actieve filters bepalen welke feeds worden geselecteerd. Vervolgens wordt uit de selectie feeds op willekeurige volgorde van elke feed de meest recente genomen, vervolgens wordt op dezelfde volgorde de nu dan nieuwste geselecteerd. Dit gebeurt tot er twintig items op de tafel liggen.
E.3.3
Design
Het filtermenu moet altijd zichtbaar zijn, het filtermenu ligt daarom altijd boven op de nieuwsberichten. Omdat werd opgemerkt dat dit storend was, is de achtergrond van het filtermenu doorzichtig. In de eerste versie van het menu waren er drie staten waar knoppen zich in konden bevinden: Geselecteerd Feeds die vallen binnen de geselecteerd categorie worden getoond, de knop is wit en heeft geen rand meer. Selecteerbaar Bij het klikken op deze knop komen er nieuwe items op de tafel, de knop is blauw en heeft een opstaande rand. Niet selecteerbaar Het klikken op deze knop zou niets toevoegen aan de selectie nieuwsberichten op de tafel, de knop is dezelfde kleur als de achtergrond en heeft slechts een vage rand en kan niet worden aangeklikt. Na tests bleek dat deze drie staten niet duidelijk waren bij de gebruikers. Daarom is de keuze gemaakt om de knoppen niet in de ‘niet selecteerbare’ staat te brengen. Dit is gedaan door de knoppen die niets toevoegen wel klikbaar te maken, dezelfde staat als ‘selecteerbaar’, maar er worden dan geen items toegevoegd op de tafel. 56
Referenties [1] Data Binding Overview. url: http://msdn.microsoft.com/en- us/library/ms75234 7(v=VS.90).aspx (bezocht op 17-05-2011). [2] Semantic Zoom. url: http : / / www . infovis - wiki . net / index . php / Semantic _ Zoom (bezocht op 31-05-2011). [3] Using MVC to Unit Test WPF Applications. url: http://www.codeproject.com/KB/WP F/MVCtoUnitTestinWPF.aspx (bezocht op 17-05-2011). [4] Windows Presentation Foundation. url: http : / / en . wikipedia . org / wiki / Windows _ Presentation_Foundation (bezocht op 17-05-2011). [5] XAML Overview. url: http://msdn.microsoft.com/en-us/library/ms752059(v=VS.9 0).aspx (bezocht op 17-05-2011).
57
