wk voetbalpool webapp: dag 14

 
21 april 2010

Zoals je gisteren hebt kunnen lezen is niet alles wel. Rikkert gaat vanaf maandag weer extern werken en ikzelf ga vanmiddag ook op intake en zal dus waarschijnlijk binnenkort ook extern gaan. Bovendien kost eea nog enig voorbereidend werk, dus vandaag heb ik maar weinig tijd om zelf een zinvolle bijdrage te leveren.

Zoals gemeld was de demonstratie gisteren behoorlijk succesvol. Anatoly is nu vooral bezig met tweaks, zoals het aanpassen van teksten, het netjes formatteren van data en tijden, het weergeven van de toto als ‘team X wint’, ‘team Y wint’ of ‘gelijkspel, i.p.v. 1, 2, of 3. Er moet nog wel iets aan functionaliteit bij, maar dat zijn maar kleine dingetjes, zoals dat de admin ook het aantal gele kaarten per wedstrijd moet kunnen invullen bij een wedstrijduitslag. Weliswaar vergt dit weer een aanpassing aan het JSON-bericht behorende bij het aanmelden van een wedstrijduitslag, maar we zijn daar inmiddels zodanig bedreven in dat dat niet zo heel veel tijd of moeite hoeft te kosten. Verder wordt de front-end-validatie nog wat aangescherpt, zodat bijv. eerst wordt gecontroleerd of het invoerveld voor het aantal gele kaarten max. 3 cijfers heeft, en daarna pas of het een getal tussen 0 en 2147483648 is.

Hij merkt wel dat we in het backend een aantal dingen nog asynchroon afhandelen, zoals de gebruikersregistratie. Bij de REST-aanroep komt dus altijd een HTTP-code 200 OK terug, die dan alleen betekent ‘bericht correct ontvangen’ maar niet verteld of het registreren wel of niet goed is gegaan, bijvoorbeeld omdat er al een gebruiker met dezelfde naam bestaat. Hoe lossen we dit op? We overwegen even om een view te maken waarin een gebruiker zijn laatste fout- (of goed-)meldingen kan zien, maar dat is eigenlijk een nogal onhandige manier. Het is waarschijnlijk beter om synchroniciteit te faken, net zoals we dat bij de loginprocedure hebben gedaan.

Christa is beziggeweest met de top 10-views van gebruikersscores, en heeft zich nu op de chat/status-update-functionaliteit gestort. Ze zou het leuk vinden om voor een gebruikerspagina een overzicht te maken van de status-updates van alle leden van alle groepen waarvan de gebruiker lid is. Op dit moment kan dat alleen per groep afzonderlijk. Een leuke bijkomstigheid is daarbij dat iedereen lid is van de groep ‘Everyone’, dus die moeten we er weer tussenuitfilteren. En je kan ook niet zomaar alle andere groepen bijelkaarvegen omdat je dan misschien dezelfde persoon meermaals meeneemt, zoals bijv. jezelf. Verder heeft ze gemerkt dat er nog geen REST-API is gedefinieerd voor sommige dingen, zoals ‘wachtwoord vergeten?’ of ‘stuur mail aan groepsgenoten’. De meeste van deze ‘vergeten functionaliteit’ lijkt neer te komen op het verzenden van (specifieke soorten) emails. Er is al wel een EmailingActor op de eventbus aangesloten, (althans, hij logt alleen maar dat hij iets zou moeten doen) maar die is nog niet op de API aangesloten.

Rikkerts CouchDB-componentje lijkt het inmiddels goed te doen. Het probleem waar hij gisteren nog zoveel tijd mee kwijt was, had te maken met een typisch programmeurs-/legacy-probleem: karaktersets. Bij het serialiseren werd een andere gebruikt dan bij het deserialiseren, en hoewel de data zelf in base64 wordt opgeslagen, blijkt dat toch nog een probleem te geven. Maar dat is nu dus opgelost, en hij heeft ook zijn project opgeschoond en alle overbodig geworden ouwe meuk weggehaald. Hij verwerkt nog dat een actor zelf geen enkele kennis hoeft te hebben van CouchDB-revisies van zijn opgeslagen state (dat wordt afgevangen door zijn componentje) en vervolgens integreert Jan-Willem het in de back-end. Al snel blijkt dat het ding inderdaad naar wens lijkt te werken: er gaat data de DB in, en het komt er zelfs ook weer ongeschonden uit.

Maar ook al snel blijkt een ander probleem: doordat CouchDB alle oude revisies van data standaard bewaart, groeit de DB binnen de kortste keren uit zijn kleren. Een simpel testje met een tweetal gebruikers levert al een DB op van ruim een megabyte. Dus aan Rikkert de vraag om toch nog maar in te bouwen dat (in elk geval optioneel) de vorige CouchDB-revisie wordt hergebruikt ipv een nieuwe aan te maken.

Het bootstrapping-probleem in de back-end vergt nog enig denkwerk, maar de oplossing met een bootup-fase lijkt wel een uitkomst te brengen. Er is nu een trait die zegt dat een Actor een initialisatie-fase kent. Voorheen werden na het opstarten van een actor al direct zijn afhankelijke actoren (zoals views e.d.) afgetrapt, maar dat was niet altijd handig: sommige communicatie tussen bijv. de userfactory, useractor, en userviewactors werd door events afgehandeld, waardoor de actoren al gestart moesten zijn, maar bij het initialiseren van de applicatie en het ophalen van de state uit de DB moeten de verschillende groep-gerelateerde actoren nog niet opgestart zijn. Dus met deze initialisatie-fase-constructie wacht de EventBus nu met het opstarten van afhankelijke actoren totdat hij een seintje heeft gehad dat de initialisatie klaar is.

En daarmee wordt het twee uur, tijd om te vertrekken. Morgen verder…!


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Development


Reactie