wk voetbalpool webapp: dag 20

 
29 april 2010

Soms ben ik iets te optimistisch. Zei ik gisteren nog dat er waarschijnlijk niet erg veel meer gesleuteld hoeft te worden aan het backend, vandaag meldt Jan-Willem dat hij nog even wil sparren over een klein dingetje, namelijk de terugkoppeling van fout- en succes-berichten naar de gebruiker. Tot nog toe was het namelijk zo dat een REST-call al een 200 OK opleverde als er voldaan was aan de beveiligings-eisen van het request (bijvoorbeeld dat een gebruiker ingelogd is en niet andermans profiel probeert aan te passen) en de eventuele meegestuurde JSON-data de vereiste velden bevat. Maar of het commando dat resulteerde uit die REST-call vervolgens ook succesvol in het domein werd afgehandeld (asynchroon weet je nog wel, dus het resultaat is niet direct ter beschikking) maakte niet uit: als bijvoorbeeld een gebruiker een groep wilde aanmaken dan kwam daar dus altijd een 200 OK uit, ook als het domein vervolgens een Fail-event opgooide omdat bijvoorbeeld al een groep met die naam bestaat.

Maar hoe doe je dat dàn? Het blijft de bedoeling om zo asynchroon mogelijk te werken. Voor de login-call hebben we al een hybride componentje, omdat we daar ook een cookie moeten teruggeven, en daarvoor is het nodig dat het domein de login-aanvraag succesvol heeft afgehandeld. Dus voor elk login-request wordt een nieuwe actor aangemaakt en gestart, en wordt er gewacht totdat er resultaat is, om de actor vervolgens weer te stoppen en te deregistreren. Maar om dat nu bij elk request te doen gaat nogal ver. Er moet dus een andere oplossing komen voor een aantal aanroepen. De views zijn, volgens CQRS, toch al synchroon en lukken eigenlijk altijd wel, dus daar is verder niets nodig – maar voor bijna alle andere dingen wel. Dus een groot deel van de dag gaat vandaag op aan het bedenken van een goed mechanisme om terugkoppeling naar de gebruiker te verzorgen, en het vervolgens uit te programmeren.

Na een uurtje overleggen, wat extra input van Rick, en een volgekalkt schoolbord, komen we erop uit om voor elke gebruiker een userview erbij te bouwen waarin de verschillende succes- en fail-berichten van de afgelopen 2 dagen worden opgeslagen, zodat het front-end die kan pollen en op zo’n manier de gebruikersterugkoppeling kan verzorgen. Maar dat heeft nog best wel wat voeten in de aarde. Elk event moet nu een soort trace-Id meekrijgen, zodat we de Success()- en Fail()-events aan de Starting()-events kunnen koppelen. Daarnaast moeten we een nieuwe actor maken die bijhoudt welke gebruiker welke trace-Id heeft geïnitieerd. Dit hoeft niet per se de gebruiker te zijn die in de REST-url wordt genoemd, of de groepseigenaar voor groepsoperaties, want het kan zijn dat admin die acties voor iemand anders uitvoert. Als de nieuwe actor dan een trace-Id binnenheeft van zowel een Starting()- als een Fail()- of Success()-event, dan kan die op zijn beurt weer een event rondsturen die door de nieuwe userview van de initiërende gebruiker kan worden opgevangen.

En nu lopen we er dus tegenaan dat de ontwikkelomgeving achter de rug van mijn lokale VM om is gewijzigd en het dus nog best wat tijd zal kosten om de zaak weer aan de praat te krijgen. We besluiten de moeite niet te nemen: de verschillende taken zijn niet erg makkelijk te splitsen, en daarbij is pair programming al eerder een erg prettige en efficiënte manier van werken gebleken: de een tiept code terwijl de andere het ter plekke controleert en bovendien alvast vooruit kan denken naar wat er verder nog moet gebeuren.

Alleen het registreren van een nieuwe gebruiker kan niet op bovengenoemde manier gebeuren: op het moment van registreren bestaat er namelijk nog geen useractor met bijbehorende userview om te loggen dat (bijvoorbeeld) deze gebruikersnaam al bestaat. Dus voor dit componentje doen we toch maar een Ctrl-C Ctrl-V op de inlog-code, fixen meteen nog maar een race condition, en met wat aanpassen zou ook het registreren nu moeten werken inclusief terugkoppeling naar de gebruiker of het wel of niet goed is gegaan. Aan het eind van de dag compileert alles weer netjes; maandag gaan we testen.

Christa is nu verder nog de enige die aan het front-end werkt. Ze is vooral met veel kleine dingetjes bezig, en ze houdt een lijstje bij die ze al werkend aanvult met dingen die ze tegenkomt – bijvoorbeeld dat als de admin een nieuwe wedstrijd wil registreren, de data in het verleden zijn uitgegrijsd; of dat wedstrijden die al begonnen zijn nu ook in het front-end gelockt zijn in plaats van dat een gebruiker een nieuwe voorspelling invult en het dan vervolgens op het back-end stukloopt. Verder is er nu ook een speelschema beschikbaar. Vandaag komen ook de verschillende emailfuncties aan bod: het mailen naar de admin voor hulp (alleen als je ingelogd bent natuurlijk) of het mailen naar je groepsgenoten. Jan-Willem heeft dat inmiddels ook op de nieuwe test-server weten in te regelen – wat nog aardig lastig was, omdat we bij Sogyo tegenwoordig gebruik maken van GMail SMTP, en die vereist ook weer een beveiligde verbinding. Ook de Android-applicatie krijgt vandaag een flinke schop onder zijn kont: Anatoly heeft zich daar nu helemaal op gestort, en aan het einde van de dag ziet het er al aardig gelikt uit. Hij heeft al een behoorlijk aantal views in de applicatie zitten, en het lijkt (in de emulator althans) al behoorlijk mooi te werken. Dit moet goedkomen voordat het WK begint (en waarschijnlijk al ver daarvoor)!

En daarmee wordt het half zes, en alles is wel.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development