wk voetbalpool webapp: dag 25

 
07 mei 2010

De mobiele webapplicatie die Jan-Willem aan het bouwen is, miste vanochtend nog een aantal handige dingetjes. Niet alleen de styling moet nog gebeuren, maar ook validatie is nog iets wat in javascript prima te regelen is voordat je je data verzendt naar het backend. Gelukkig blijkt jQuery hiervoor een behoorlijk goeie infrastructuur voor te bieden – maar dat moet je wel weten voordat je je eigen validatie schrijft… ook het regelen van de status updates zat er nog niet in. Tijdens de stand-up meeting komt de wisselwerking tussen de mobiele en de volledige versie van het front-end ter sprake: moet de server op basis van de Request headers de ene of de andere versie sturen, of gaan we ze gewoon op aparte subdomeinen of URLs hosten? We besluiten dat het laatste de meeste mogelijkheden biedt: dan kan je namelijk een knop op de website zetten die naar de andere versie linkt; terwijl die mogelijkheid er niet is als je de server laat beslissen – of die zou per sessie moeten bijhouden of de gebruiker de ene of de andere versie wil.

Anatoly en Christa zijn nu ook zo goed als klaar met het front-end. De laatste dagen is er vooral gewerkt aan performance (minder vaak pollen scheelt een hoop!), zijn inconsistenties rechtgetrokken (engelse teksten op een nederlands inlogscherm?), hebben ze de zaak nog gerefactord en de code gedocumenteerd. Er ontstaat een discussie over hoe het front-end moet omgaan met de error-view van de gebruiker. Daarin komen alle (succes- of fout-)meldingen voor de gebruiker te staan. Moet die in zijn geheel getoond worden? Is dat altijd relevant? Misschien is het ook alleen nodig om te pollen en alleen de foutberichten aan de gebruiker door te communiceren. Alleen de laatste melding tonen is misschien minder handig, als er bijvoorbeeld door GWT kort achter elkaar twee acties worden geinitieerd, waarvan de eerste foutgaat en de tweede goed: dan zal de gebruiker het niet merken dat er iets is misgegaan. Een sexy optie zou kunnen zijn om steeds maar een enkel bericht te tonen, maar de gebruiker te kunnen laten bladeren door de historie.

Simon vindt dat de website inmiddels voor 70% af is. Alles lijkt het goed te doen, maar hij vindt het vooral een hele ‘machinale’ applicatie, het kan ‘menselijker’, zegt hij. Daarbij bedoelt hij vooral op de gebruikerservaring van de applicatie. Een goed voorbeeld zou kunnen zijn wat ik ook in de Android-versie heb ingebouwd: dat als je bij een voorspelling een eindstand invult, ook meteen de toto wordt voor-ingevuld op basis daarvan. Of bijvoorbeeld bij het registreren, dat de gebruiker al te horen krijgt dat het wachtwoordveld en het wachtwoord-controleveld niet overeenkomen zodra hij dat invoerveld verlaat, in plaats van bij het verzenden van het registratieverzoek. Kortom: alles werkt wel, maar het kan handiger. Hij belooft een lijstje te maken met aanpassingen die hij graag nog in het frontend wil hebben. En aan het eind van de middag heeft hij een top-10 van kleinere en grotere issues die hij nog aangepast zou willen zien. Genoeg werk dus nog voor komende week.

Voor Android heb ik inmiddels Anatoly’s landcode-lijst ingepikt, zodat ook Android-gebruikers niet hoeven te raden welk land welke code heeft. Verder kwam ik erachter dat als je op de G1 het toetsenbord gebruikt en dus je telefoon draait, de helft van het voorspellingen-scherm buiten beeld valt… zonder dat er een scrollbar in beeld komt. En ook ‘gewoon’ proberen het beeld te verschuiven werkt niet. Gek genoeg helpt het niet om de LinearView te vertellen dat hij een scroll-container is, of dat hij de verticale scrollbar moet laten zijn, of wat dan ook. Dus nog maar eens de docs doorlezen, hij zou het toch moeten kunnen…? Gelukkig kom ik dan toevallig ergens een codevoorbeeldje tegen waarin ze een componentje gebruiken dat ik tot nog toe over het hoofd had gezien, maar wat toch wel van pas zou kunnen komen – het heet: ScrollContainer. En abracabra simsalabim: 1x compileren en hij doet het. Programmeren is soms simpeler dan je denkt.

De rest van de dag besteed ik aan het probleem dat de database maar blijft groeien en groeien. In principe zou hij zichzelf moeten compactificeren nadat 75% van alle records als verwijderd zijn gemarkeerd, maar dat lijkt niet te gebeuren. Ik besluit om het ding eerst maar eens van wat logging te voorzien. Dus vlak voor het beslispunt zet ik een aantal log.debug()s neer. Dan de hele zaak compileren, deployen, tomcat herstarten (dat is nodig om de interne verwijzingen goed te zetten; dat gaat gek genoeg niet goed als je hem alleen deployt maar werkt pas na een herstart) en dan maar testen. Maar in de wk.log is niets te zien – niet zo gek omdat het het CouchDB-component is. Maar ook de catalina.out waar alle Tomcat-logging in gebeurt meldt niets. Heu? Nou gebruikt dit project geen log4j maar apache commons logging. Heb ik daarin iets fout gedaan? Uitbundig pielen met instellingen helpt niets, ik overweeg zelfs even om ook log4j erbij in te schakelen, al zie ik daar toch vanaf, maar hoe dan ook: geen log.

Dus dan maar ‘droog’ de code uitpluizen, de CouchDB docs erbij gehaald, enz. Maar ook daarin staat niets verbazingwekkends of onverwachts. Het ding zou het toch moeten doen nu? En dan besef ik me dat ik een blinde vlek heb: misschien werkt de logging wel, maar komt hij gewoon nooit uit op dat punt. En inderdaad, een van de statements is nog net mis. Logging ahoy! Maar dan komt het eigenlijke probleem boven water: CouchDB rapporteert altijd nul verwijderde documenten. Hmmm. Een bug in CouchDB? Of doen we de opslag toch nog verkeerd? Ook dat is werk voor maandag.

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


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


Categorieën: Development