Met deze korte laatste tekst sluit ik deze stageblog af, aangezien dit mijn laatste week is. Ik heb verschillende dingen bijgeleerd, ook mede dankzij de variatie in de verschillende projecten. Het project Take-A-Trip (mijh oorspronkelijke stageproject) is volledig afgeraakt (alleszins het deel dat van mij verwacht werd) en ik ben trots op het resultaat.

Hoewel ik dit per mail al gedaan had, wil ik graag nogmaals iedereen bedanken voor deze kans en de leuke sfeer de voorbije drie maanden.

HTML5 Drag-’n-Drop

Een component dat ik gedurende de vorige weken schreef was Window, een dialoogvenster met titelbalk met sluitknop en een “body” waarin andere elementen geplaatst kunnen worden. Het component zelf is vrij eenvoudig van aard, maar het venstertje moet ook rond te bewegen zijn met behulp van de titelbalk. Traditioneel gebeurt zoiets in JavaScript via events als mousedown en mousemove. Aangezien de browser bij het inhouden van de muis op een element ook een sleepactie (drag) start, vroeg ik me af of het ook mogelijk was om dit te manipuleren tot een verplaatsing zonder echte drop. Het antwoord is ja, maar er zijn wel enkele moeilijkheden die tevoorschijn komen (en ook opgelost kunnen worden).

Dubbel slepen

Een initiële implementatie maakte de titelbalk draggable en verplaatste de rest van het venster via de drag event die automatisch gedurende de drag elke zoveel milliseconden afgevuurd wordt. Dit zag er niet goed uit: een “kloon” van het sleepbare element (hier de titelbalk) wordt onder de muis getekend door de browser gedurende het slepen. Samen met het originele venster, dat zich mee verplaatste in de drag event, zorgde dit voor twee titelbalken die deels overlappen (het venster met titelbalk wordt iets later verplaatst dan de kloon onder de muis door een delay). Dit kan opgelost worden door ofwel het hele venster draggable te maken (maar dan kan je het venster ook slepen vanuit de body) ofwel door event.dataTransfer.setDragImage te gebruiken. Bij deze laatste kan je zelf bepalen welke afbeelding (of welk element) zichtbaar moet zijn onder de cursor gedurende de drag. Door dit op het venster zelf in te stellen is dit probleem opgelost.

De code om het venster zelf te verplaatsen is nu overbodig omdat de browser al een kloon van het venster tekent onder de muis die automatisch van plaats verandert. Dit zorgt echter voor een nieuw probleem: het oorspronkelijke venster blijft op zijn plaats staan terwijl de kloon meebeweegt. De makkelijkste oplossing is het oospronkelijke venster te verbergen bij de aanvang van de sleepactie (bv. via style.opacity = 0). Dit werkt niet: het venster verdwijnt maar onder de muis is ook niets meer zichtbaar, zelfs al stel je eerst de dragImage in en verberg je nadien het element. De dragImage maakt een afbeelding en krijgt aanpassingen nadien niet meer door, maar toch werkt dit niet. Waarom? Blijkbaar schrijft de standaard niet voor dat op het moment van aanroepen van setDragImage de afbeelding meteen aangemaakt moet worden. De browser is hier m.a.w. vrij in (en Chromium, waarin ik op dit moment werk, doet dit ook niet). De eenvoudigste oplossing die ik vond is om het gewoon in de dragenter en/of dragover events te doen (deze worden blijkbaar pas uitgevoerd na het creëren van de afbeelding).

Ten slotte wordt bij het droppen het venster terug zichtbaar gemaakt en verplaatst naar de muiscoördinaten.

No Drop Allowed

“Drop allowed” op een element kan je aangeven door in dragenter en dragover events preventDefault uit te voeren (want de default is dat droppen op een element niet is toegestaan). Het standaardgedrag zorgt ervoor dat als je stopt met het venster te slepen, het wel op de juiste plaats komt maar je nog een soort van “ghost image” van het venster ziet dat zich terug naar de oorsponkelijke plaats beweegt. Dit geeft visueel aan de gebruiker aan dat hij hier niet mag droppen. In deze omstandigheden willen we dit echter niet omdat het venster overal mag “gedropt” worden. Door op document-niveau de eerder genoemde functies preventDefault uit te laten voeren kan je dit voorkomen. Laat dit best enkel gebeuren als de gebruiker een venster aan het slepen is, zodat andere elementen op de pagina niet plots ook overal een geslaagde drop kunnen uitvoeren en geen feedback meer geven.

Na deze stappen is het venster via de titel sleepbaar, volledig gebruikmakend van de browser zonder elke zoveel milliseconden een JavaScript functie uit te voeren om het venster te verplaatsen, want het verslepen doet de browser. Problem solved!

Composite

Het framework maakt uitgebreid gebruik van het Composite-patroon, een ontwerppatroon dat tracht ervoor te zorgen dat composities (of eenvoudigweg samenstellingen) van objecten uniform behandeld kunnen worden met gewone objecten. Een concreet voorbeeld is een GUI: er is bv. een hoofdklasse Widget aanwezig die gemeenschappelijke informatie bevat die alle widgets moeten bevatten. Alle specifiekere widgets (Table, Button, Label, Tree, …) erven over van de hoofdklasse widget. Sommige widgets, zoals Panel en GroupWidget, kunnen andere widgets bevatten. Door deze klassen een attribuut widgets te geven, die de subwidgets in lijstvorm bijhoudt, kan de panel alle soorten andere widgets bevatten, zelfs andere panels of groupwidgets. Zo creëer je de mogelijkheid een in theorie oneindige hiërarchie op te bouwen (in de praktijk zijn er uiteraard beperkingen die dit verhinderen). Dit systeem is zeer flexibel en makkelijk uit te breiden, aangezien elk nieuw type widget automatisch als subelement kan dienen.

Volgende week zal ik me waarschijnlijk opnieuw richten op het toevoegen van nieuwe componenten alsook het schrijven van tests om deze componenten te ondersteunen.

Toeristische website

Ik ben deze week bezig geweest met een toeristische website. Vermits het uitlezen van de data gebeurt via een andere website, was het belangrijk dat ik goed nakeek wat er kon ingelezen worden via de API. Hierdoor moest ik ook nauwgezet bekijken wat ik in een filter kon plaatsen en wat niet. Ik ben hier wel enige tijd mee bezig geweest, maar het was wel zeer leerrijk.

Responsive.

Verder heb ik ook nog uitgezocht hoe ik deze website responsive kan maken. Ik heb goede voorbeelden, maar alles vraagt een nieuwe kijk. Niet alles kan je zomaar overnemen.

Er zijn altijd stramienen waar je je kan op baseren, wat wel belangrijk is. Mensen hebben nu eenmaal gewoontes waar je niet zomaar om heen kan. Het is wel zeer leerrijk om te zien hoe alles zo eenvoudig kan zijn en hoe moeilijk ik het mezelf soms maak. Keep it simple is echt een noodzaak, maar ik merk hoe langer hoe meer hoe moeilijk het is.

Interne app

Ik heb de interne app, die ik in het begin van mijn stage gekregen heb, nog eens opnieuw bekeken. Er zijn immers altijd andere mogelijkheden en ik heb dan ook nog een andere optie uitgewerkt, maar deze bleek minder effectief.

Code Coverage Analysis

Dit is een onderdeel van PHPUnit en is iets wat ik bij het eerste gebruik van PHPUnit indrukwekkend vond. Door PHPUnit aan code coverage analysis te laten doen, kan je in HTML-formaat een overzicht krijgen van alle gebruikte klassen en methoden en in welke mate ze getest werden. De tool toont hiervoor alle afgelopen code paths en toont d.m.v. groene, gele en rode voortgangsbalken welke percentage regels, methoden en klassen bereikt werden. Op deze manier heb je meteen een overzicht van welke corner cases of randgevallen nog niet getest werden. Je kan overigens ook vanuit de index.html door de mappen en PHP-bestanden navigeren.

Mockups en stubs

Mockups en stubs zijn objecten die in de plaats van reguliere objecten kunnen worden doorgegeven. Dit is zeer handig als je klassen wil testen die afhankelijk zijn van andere klassen zonder deze afhankelijkheden ook uitgebreid op te moeten zetten. Een concreet voorbeeld: een modelklasse is afhankelijk van een databaseklasse. Bij het testen maak je een object van de modelklasse aan en maak je een mockup van de databaseklasse en geeft deze door aan het modelobject. Via de mockup kan je voorkomen dat bepaalde methoden echt uitgevoerd worden en aangeven welke waarde ze tijdens het testen moeten teruggeven. Dit alles kan in de tests zelf zonder de eigenlijke database- of modelklasse aan te passen.

De lezer vraagt zich mogelijk af waarom de databaseklasse niet eenvoudigweg onmiddelijk meegetest wordt. De reden hiervoor is dat de databaseklasse zijn eigen reeks testen heeft en bij het testen van de modelklasse irrelevant is (je bent nu enkel en alleen de modelklasse aan het testen). Testen waarbij de samenwerking tussen de objecten en het geheel getest wordt horen op een ander niveau thuis (bv. op het niveau van integration testing).

Vorige week heb ik een mobile app mogen maken en daar zijn deze week nog een paar aanpassingen aan gebeurd. Er waren een paar linken die een andere naam moesten krijgen. Er moesten ook nog een paar knoppen worden toegevoegd. Op zich was er niet zo veel werk meer aan, maar het is wel leerrijk om te doen.

De webshop.

Ik heb de rest van de webshop mogen presenteren. Ook hier waren een hoop aanpassingen aan. Maar zoveel werk was het niet om alles aan te passen, want ik heb heel veel in masters kunnen stoppen de vorige keer. Axure heeft dus weer maar eens zijn nut bewezen. Presenteren is geen evidentie en dat voel ik keer op keer. Een goede voorbereiding en een sterk project zijn echt nodig. Ook de gave om jezelf te verkopen helpt natuurlijk. Bij mij is hier nog werk aan.

Portfolio website

Ik heb de opportuniteit gehad om een portfolio website te mogen maken. Dit lijkt allemaal evident, maar als je kijkt naar wat er bestaat aan standaard templates dan zijn er niet zo heel veel goede bij. De bezoeker wil werk zien. SEO is ook belangrijk en je moet er allemaal rekening bij houden. Bart is dit alles aan het nakijken en ik krijg er komende week feedback op. Fingers crossend.

Toeristisch website.

Ik mag ook eens proberen om een toeristische website te maken. Het is voor mij allemaal nieuw en ik ben permanent op zoek naar hoe anderen het doen. Google is mijn “leeromgeving” geworden. Maar langzaam maar zeker komt er schot in de zaak. Ik denk komende week hiermee klaar te zijn en we zien wel. Ik vind het super hoe Bart VDB en Bart A. me bijstaan in dit project. Ik zou anders wel wat vaker met mijn handen in het haar gezeten hebben.

See you next week.

eID

Deze week begon met een onderzoek naar de Belgische identiteitskaart; is het mogelijk om gegevens uit te lezen van de identiteitskaart via een kaartlezer om deze weer te geven op een PHP-website? Mijn eerste gedachte was neen; dit mede omdat PHP geen low-level language is en niet ontwikkeld werd met het oog op het aanspreken van hardware. Gelukkig biedt Fedict (de “ontwikkelaars” van de Belgische elektronische identiteitskaart) tal van tools om dit eenvoudig mogelijk te maken op de computer van de bezoeker, waarvan de meerderheid jammer genoeg in Java geschreven is. Zij bieden op hun site echter ook een Java-applet die het uitlezen van de identiteitskaart mogelijk maakt op de computer van de bezoeker zonder al te veel extra software. Dit houdt concreet in dat je aan de website van Fedict doorgeeft welke informatie je wilt opvragen (samen met een redirect URL), de gebruiker doorstuurt naar de website en de informatie ten slotte terugkrijgt na een redirect. Dit alles kan op deze manier zonder dat het nodig is een Java-applet (en SSL, wat een vereiste is voor de applet) toe te voegen aan je eigen website. Het principe van autorisatie geven en het laten afhandelen door een externe website lijkt ergens wel op OAuth (zie ook mijn post van vorige week).

Vagrant

Vagrant is een tool waarbij op basis van een configbestand op een eenvoudige manier virtuele machines (bv. voor VirtualBox) via de commandline gegenereerd kunnen worden. In deze config kunnen allerlei opties opgegeven worden zoals instellingen die aan de VM meegegeven moeten worden bij de creatie alsook pakketten die geïnstalleerd moeten worden (bv. Apache, PHP, MySQL, enzovoorts). De voordelen van het gebruik van Vagrant komen vooral tevoorschijn in een teamomgeving; mocht er iets foutlopen bij iemand met een zeer specifieke configuratie, dan kan iemand anders een identieke configuratie opbouwen door van hetzelfde configbestand gebruik te maken.

Mijn eerste taak taak was het bekend geraken met het gebruik van Vagrant, waarna ik onderzocht of een configbestand van derden bruikbaar was binnen Inventis om het opzetten van een virtuele machine met een LAMP-server te vereenvoudigen. Het opstellen van een LAMP-VM met Vagrant is vrijwel out-of-the-box mogelijk, maar de extra mogelijkheden die geboden worden door de software bestaan uit het eenvoudig opgeven van bepaalde websites. Dit betekent dat bij het creëren van de VM enkele websitemappen automatisch gekopiëerd worden naar de VM, volledig ingesteld worden voor apache en bruikbaar zijn nadien op de host.

De software op zich maakt het leven wat eenvoudiger, maar het probleem hierbij is dat enkele eenvoudige dingen ontbreken: het hosts-bestand van de host wordt niet automatisch aangepast om de websites op de host bereikbaar te maken op naam (dit moet je m.a.w. zelf doen). Ook betekent het toevoegen van een nieuwe website in de software het kopiëren van veel redundante informatie. Omwille van deze kleine problemen schreef ik enkele bash-scripts waarbij de gebruiker enkel een map moet verbinden aan een domeinnaam om sites toe te voegen in de VM (bv. “/var/www/mijnsite -> www.mijnsite.test”). Ook werkt deze tool automatisch het hosts-bestand van de host bij om de domeinen via DNS bereikbaar te maken op de host (dit alles na een back-up, uiteraard).

Testen

Het tweede deel van de week wijdde ik aan het schrijven van testen voor het nieuwe (nog onafgewerkte) framework van Inventis: Webadmin 5.0. Het schrijven van deze testen gebeurde in PHPUnit en is volledig nieuw voor mij, wat dit een leerrijke ervaring maakt. Dit is ook waar ik de volgende weken waarschijnlijk het grootste deel van mijn tijd aan zal besteden.

Deze week heb ik voor het eerst aan zowel Jan als Jente het project van de webshop voorgesteld.

Met het verkopen van dit soort producten heb ik niet veel ervaring en dat was dan ook moeilijk. Maar Jan gaf me een aantal tips die ik zeker zal meenemen. Verder waren er een aantal aanpassingen om het geheel wat logischer en beter te maken. Na de aanpassingen gehoord te hebben ben ik aan de slag gegaan. Door de vorige aanpassingen (het aanmaken van een hoop masters) in het wireframe, waren deze correcties tamelijk snel gedaan.

Mobiele website.

Bart gaf me ‘s morgens een briefing over een vernieuwing van een mobiele website. Ik had een basis en de menu structuur was reeds uitgeschreven. Dit was de eerste keer dat ik ook effectief moest rekening houden met de tijd en dat lukte aardig. In de voormiddag waren de schetsen voor het wireframe klaar, tegen de avond was de eerste versie van het prototype klaar. De volgende voormiddag heb ik dan de mobiele website voorgesteld. Er waren nog een aantal wijzigingen nodig, zo was de naam van een knop slecht omdat die gewoonweg niets vertelde over wat er ging gebeuren. Dat heb ik aangepast. Daarnaast moesten er ook nog een aantal andere aanpassingen gebeuren. Tegen de avond was alles hiervoor klaar. Later op de week kreeg ik wel nog te horen dat er nog een paar kleinere zaken moesten veranderen.

Project Management

Dit project betreft geen volledige PM-tool, maar wel het schrijven van bibliotheken voor het aanroepen van de API’s van Google Drive, GitHub en Tick. Stuk voor stuk zijn dit tools die intern in de uiteindelijke PM-tool gebruikt zullen worden. Het merendeel van deze tools zal de lezer allicht bekend voorkomen:

1. Google Drive is een soort tegenhanger van DropBox en is ook een verderzetting van de oorspronkelijke Google Documents: op deze website kunnen bestanden in mappen online opgeslagen worden in de cloud.
2. GitHub is een dienst waarop Git repositories geplaatst en beheerd kunnen worden.
3. Tick is een tool om taken met tijdsverdelingen te maken, bv. “Afwerken front-end: 10 uren” (hierbij is 10 uren het aantal uren dat voorzien wordt voor het afwerken van deze taak). Deelnemers aan het project kunnen dan aangeven hoeveel uren ze gewerkt hebben aan de taak en zo kan er uiteindelijk ook gewerkt worden aan de inschattingscapaciteiten van de werknemers (bv. als er 15 uren nodig waren i.p.v. 10 uren werd er een verkeerde schatting gemaakt).

Elk van deze tools stelt een eigen (RESTful) API bloot waarmee gecommuniceerd kan worden met de site vanuit een eigen applicatie (in dit geval de PM-tool zelf).

Google Drive

Google Drive gebruikt een zeer uitgebreide API en voorziet ook eigen software voor allerlei programmeertalen om deze API aan te spreken. Het moeilijkste hierbij is het gebruik van OAuth (een standaard voor autorisatie). In het verleden stuurde men eenvoudigweg gebruikersnamen en wachtwoorden zomaar door naar de server om data te manipuleren of van een zogenaamde API key. OAuth verzadigt de nood om een gebruikersnaam en wachtwoord door te sturen; de applicatie kan namelijk communiceren met de aanbieder van de API zodat de gebruiker toestemming kan geven dat de applicatie gebruikmaakt van zijn gegevens. De applicatie kan dan (tijdelijk) zich gedragen als de gebruiker (dit heet ook wel impersonation). Een concreet voorbeeld van de werkwijze hiervan bij traditionele Google API-gebruikende webapplicaties:

1. De applicatie die met de Google API’s kan werken wordt geopend of gestart.
2. De applicatie haalt van de Google API een link naar de Google website op die hij toont aan de gebruiker.
3. De gebruiker klikt op de link en wordt doorgestuurd naar de (beveiligde) website van Google. Hierop wordt gevraagd of de applicatie toestemming mag krijgen om de account van de gebruiker te gebruiken. De gebruiker geeft hier toestemming (hij autoriseert de toepassing om gebruik te maken van zijn data).
4. De gebruiker wordt (automatisch) teruggestuurd naar de applicatie. De applicatie krijgt hierbij een bepaalde code die hij kan gebruiken om te communiceren met de Google API’s. Deze code geeft tijdelijk toestemming om de data van de gebruiker te manipuleren. Na een bepaalde tijd vervallen deze rechten uiteraard.

Het voordeel van deze werkwijze is dat de gebruiker zijn gebruikersnaam en wachtwoord niet hoeft door te geven aan de applicatie. Ook kunnen de rechten die de gebruiker gaf aan de applicatie op elk moment zonder meer terug ingetrokken worden. Als de applicatie het wachtwoord van de gebruiker heeft, kan hij zich echter altijd (al dan niet ongewenst) toegang verschaffen, tenzij de gebruiker zijn wachtwoord verandert.

GitHub

De API van GitHub is op het gebied van autorisatie zeer gelijkaardig aan Google (de API werkt ook via OAuth). GitHub heeft echter geen officiële software beschikbaar om te communiceren met zijn API’s. Hierdoor werd ik verplicht gebruik te maken van een onofficiële bibliotheek, die jammer genoeg nog een aantal grote bugs bevatte. De broncode van deze software was echter toegankelijk en met een aantal omwegen (en een pull request voor het oorspronkelijke project op GitHub om anderen met hetzelfde probleem verder te helpen) was dit echter terug in orde te krijgen. Een andere optie zou geweest zijn om zelf dergelijke software te bouwen, maar dit zou een project op zich geweest zijn aangezien de API van GitHub zeer uitgebreid is.

Tick

De API van Tick was veruit het meest rudimentair van de drie. Bij Tick is er geen sprake van OAuth; bij elke aanvraag om gegevens stuur je het e-mailadres en het paswoord van de gebruiker gewoonweg mee als GET-argumenten in de request URL. Dit is echter niet bijzonder veilig (o.a. packet sniffers zouden de requests uit kunnen lezen). De auteurs van Tick leveren, net zoals GitHub, geen eigen software mee voor het aanspreken van de API. De API van Tick is echter zeer klein, wat het haalbaar maakte alles van nul af op te bouwen.

Voortgang

Vandaag rondde ik dit project volledig af. Dit betekent dat volgende week opnieuw een nieuwe opdracht op de planning staat .

Problemen

Bij het responsive maken van een website ga je de desktop site vertalen naar een site gericht op een kleiner scherm met een andere manier van navigeren, maar de content moet zoveel mogelijk behouden blijven. Het is de kunst om vanaf het moment dat je de desktop site ontwikkelt rekening te houden met wat er op de responsive toepassingen zal gaan gebeuren; hoe gaan de verschillende elementen onder of boven elkaar schuiven, wat kan/moet er off canvas gaan,… Je moet het van in het begin goed overdenken. Bij gevolg moest ik dus vaak aanpassingen maken op de desktop versie omdat er anders te veel uitzonderingen moeten gemaakt worden. Time is money.

Presenteren

Deze week heb ik ook de shop gepresenteerd aan Jente en Bart. Hier merkte ik op dat een presentatie veel langer duurt dan ik aanvankelijk dacht. Dit kwam omdat ik alles trachtte uit te leggen en er bij alles een verhaal hoorde dat ik ook nog wou brengen. Dat is niet nodig. Het kan sneller gaan zonder al die extra uitleg. Verder maakte ik de dag nadien de fout door alles opnieuw te overlopen, wat echter niet nodig was. Ik was beter begonnen waar ik de dag ervoor gestopt was.

Maar langs de andere kant heb ik wel weer wat extra feedback gekregen.

Wat er nu komen gaat.

Ik heb vrijdag redelijk wat in masters zitten stoppen waardoor ik normaal sneller zou moeten kunnen werken. Verder moet ik nog een aantal zaken doen op de mobiele toepassingen en dan zou ik volgende week aan een nieuw project moeten kunnen beginnen. Ik heb veel bijgeleerd uit dit project maar ik heb geregeld met mijn handen in mijn haar gezeten. Maar het is een proces, het zal er komen en het project zal goed zijn.

See you next week.