wk voetbalpool webapp: dag 26

 
10 mei 2010

Ergens deze week willen we onze webapplicatie bij de uiteindelijke externe partij gaan deployen en de zaak aan een grondige test onderwerpen zodat we volgende week live kunnen gaan. De originele richtlijn daarvoor was 10 mei (ca. 1 maand voor het WK); dat gaan we net niet halen (want dat is vandaag) maar we zitten er niet ver vanaf – als we tenminste niet nog ergens een verschrikkelijke bug tegenkomen natuurlijk.  De mobiele website is inmiddels zover af dat Simon die ook kan gaan stylen en testen, en Jan-Willem van feedback kan voorzien. Simon heeft zijn de styling voor de normale website ook iets moeten aanpassen: hij ging eerst uit van een schermbreedte van 1280 pixels, en had daarvoor een precies mooi passende pagina-indeling gemaakt. Maar als de pagina dan iets te lang wordt (bijv. doordat je een wat langere lijst gegevens opvraagt) dan krijg je rechts een scroll-balk, maar daardoor past dan de website niet meer helemaal in het frame en krijg je dus meteen ook onderaan een scroll-balk… Verder had hij nog een flinke lijst wensen en aanpassingsverzoeken aangelegd, maar vandaag kon Christa al melden dat de meeste daarvan al zijn opgelost. We liggen dus aardig op schema.

Toch zijn er nog wel dingen die opgelost moeten worden, of waarvan wij willen dat die opgelost worden. Een van de dingen die we tijdens het testen hebben gemerkt is dat het apart hosten van front- en back-end niet goed werkt voor sommige browsers (zoals Firefox en Chrome), vanwege hun ingebouwde cross-site-scripting-preventiemechanisme (Scrabble anyone?). Nou is er een W3C-richtlijn gemaakt die door deze browsers ondersteund wordt, en die het mogelijk maakt om toch in beperkte en vooral in controleerbare mate cross-site-scripting toe te staan, dus we willen in elk geval nog proberen om dat erin te bouwen. Hiervoor moet ook aan het back-end nog wat gesleuteld worden; Jan-Willem is hier al mee bezig geweest, maar de eerste resultaten zijn nog niet bemoedigend. Anatoly heeft hier ook al wat onderzoek naar gedaan, en ze gaan later vandaag bijelkaar zitten om de zaak verder op poten te krijgen.

Verder willen we ervoor zorgen dat de database niet dagelijks twee of drie keer handmatig gecompactificeerd moet worden, maar dat dit automatisch gebeurt zodra er teveel ouwe zooi in staat. Ik ben hier vandaag mee bezig geweest, en het probleem ligt er waarschijnlijk in dat we steeds maar een enkele revisie gebruiken die continu geupdate wordt, waardoor er nooit verwijderde documenten ontstaan en de meuk-teller altijd op nul blijft staan. Als eerste heb ik geprobeerd om de DB uberhaupt maar eens programmatisch te compactificeren. Dat leverde een hoop frustratie op, omdat daar steeds een HTTP 500 internal server error uitkwam – totdat ik erachter kwam dat de driver altijd eerst een sanitizeName() aanroept voordat de DB-naam in de url wordt gezet. En CouchDB is hoofdlettergevoelig, dus een aanroep naar WKPoolDB komt niet aan als je alleen een wkpooldb hebt… Als eerste stap zorgt het back-end er nu zelf expliciet voor dat na elke 1000 persistentie-acties de DB gecompactificeerd wordt, en dat lijkt te werken. Nu nog de mooie oplossing: ervoor zorgen dat de driver en de database zelf kunnen besluiten wanneer de compactificatie gaat gebeuren. Daarvoor moet ik de driver wat grondiger omgooien, zodat we wèl met verschillende revisies gaan werken.

Daarnaast zijn er nog wat eenvoudige dingen die nog in het backend ingebouwd moeten worden: er moeten nog mailtjes worden verstuurd bij het aanvragen van een nieuw groepslidmaatschap, zodat de groepseigenaar weet dat er iemand staat te wachten om toegelaten te worden, en moet de aanvrager ook bericht krijgen als hij toegelaten of afgewezen is. Hierbij gaat het gebruikte event-driven model met een centrale eventbus ons waarschijnlijk goed helpen: waarschijnlijk is dit in alledrie de gevallen niet meer werk dan een extra event op de eventbus zetten en klaar. De rest wordt dan wel door de al bestaande infrastructuur opgelost.

Een andere, nieuwe, wens is dat de gebruikersnaam hoofdletter-ongevoelig gemaakt moet worden. Dat kan nog een leuke worden: die wordt namelijk nu overal als key voor een hele hoop dingen gebruikt, en zit ook diep in de pattern matching van Scala ingebed. Om dat ding hoofdletter-ongevoelig te maken kan nog een hele kluif worden, waar Jan-Willem en ik nog even goed over moeten nadenken. Maar dat is (voor mij althans) werk voor morgen: ik moet nu snel richting een bruiloft.

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


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


Categorieën: Development