Death March II
M'agrada pensar que un projecte en que un no aprengui res no s'ho val. En el cas de projectes Death March sempre hi ha la temptació d'anar a cercar les solucions màgiques, sovint sense més argumentació que un "wishful thinking": posar n-mil programadors pel projecte, pensar que l'eina màgica-que-ho-fa-tot-menys-el-cafè ens permetrà acabar a temps, ... Particularment me'n faig enfora d'aquestes temptacions, però a la vegada m'agrada aprofitar cada projecte per a introduïr millores respecte als projectes anteriors. Si no pots aprendre de l'experiència passada mal anam, no?
En aquest projecte hem aprofitat per introduïr dues tecnologies que ens solucionen dos problemes que teníem a molts projectes però que en aquest tenen una criticitat que fan que la solució sigui imprescindible. Per una part necessitàvem poder controlar en temps d'execució alguns paràmetres de l'aplicació: nivell de depuració, temps de la la memòria cau de segon nivell, ... Per una altra necessitam un mètode ràpid d'enterar-nos dels errors que es produeixen a l'aplicació sense tenir que anar al servidor de producció.
El primer problema ho hem pogut resoldre gràcies a l'excel·lent support que té Spring per JMX. A més això ens permetrà dur una monitorització fina d'alguns paràmetres que ens interessen de l'aplicació mitjançant OpenNMS. Tot programari lliure!
El segon problema ho hem resolt també gràcies al programari lliure. Concretament gràcies al Jabber i a una API per accedir-hi anomenada Smack. Quan ho ajuntam tot amb Spring podem fer la nostra pròpia implementació de la captura d'errors i fer que ens envïi un missatge amb el log de l'error quan aquest es produeix. L'usuari veurà una pantalla tota xul·la d'avís i la gent de programació rebrem l'avís complet i en temps real del que ha passat junt amb la traça del missatge.
En el desenvolupament del projecte ens hem trobat també amb la necessitat d'ordenar i filtrar conjunts d'objectes. Java ens permet fer-ho, però la quantitat de filtres i operacions a fer feia que la perspectiva no fos massa agradable ni massa pràctica. No hi ha temps per a escriure i molt menys depurar tota la quantitat d'operacions que es necessiten fer damunt la llista d'objectes que tenim.
Inicialment vàrem pensar en una base de dades lleugera, però totes eren molt més del que necessitàvem, i a més comportava tenir que fer transformacions damunt la nostra llista d'objectes. La solució va venir de la mà d'un projecte anomenat JoSQL. Aquesta llibreria ens permet tractar una llista d'objectes com si fos una base de dades sql. La funcionalitat que té és tot el que necessitàvem i més.
Som conscients que estam canviant temps de desenvolupament per temps de procés i memòria, però precisamente el que tenim és molta CPU i poc temps per a entregar el projecte, així que la tria era molt clara. De totes maneres quan més ho pens més avantatges li veig a JoSQL, el codi de cerques i filtres damunt les llistes queda molt clar, reduït a una o dues setències SQL i per tant molt més bo de depurar i mantenir. Una vegada més estaríem guanyant un temps preciós que necessitarem en altres etapes del projecte.
Aquest projecte també ens ha servit per provar una altra manera d'organitzar la feina. La gestió del risc s'ha de coordinar amb un tipus de desenvolupament que ens permeti avançar bé i aviat. Això implica paralelitzar tot el que es pugui i que tothom sàpiga el que ha de fer i perquè ho fa.
La veritat és que n'estic molt de l'equip. Si tenim alguna possibilitat d'entregar aquest Death March Project a temps serà gràcies a que la gent que hi ha implicada és d'allò que en trobes pocs.
Tot i això encara No es pot cantar victròria, encara hi ha un risc molt alt, aliè a l'equip de desenvolupament, que poc a poc està transformant aquesta missió impossible en un projecte ugly. És el que tenen aquests projectes, fins que no s'acaben un no pot fer recompte de baixes o cantar victòria.
