Django a l'empresa: liquidacions de despeses
Aquesta setmana hem posat a preproducció una aplicació interna per a la gestió de les despeses feta amb Python, Django i Postgres. La idea és poder saber quines són les despeses més comuns per tal de fer-ne un seguiment i si s'escau poder fer una negociació amb els preoveïdors habituals.
Per això era necessari que les liquidacions de despeses que fins ara es feien amb un excel (quin mal fan els excels a les empreses!) es facin ara mitjançant una aplicació web. D'aquesta manera a la primera etapa l'usuari té exactament el que tenia abans, a saber, una fulla de paper que el seu cap pot signar i després presentar al caixer; però a més l'empresa començarà a tenir dades que es podran analitzar.
L'autentificació dels usuaris es fa contra l'Active Directory de l'empresa, en les darreres versions de Django és trivial canviar de sistema d'autentificació i han aparegut diferents snippets que ens permeten canviar el sistema d'autentificació estàndard per un altre. En el meu cas l'snipet d'autentificació per l'Active Directory ens ha anat força bé. De la mateixa manera seria trivial fer l'autentificació contra un LDAP o contra un altre sistema és força senzilla i la documentació de Django és molt aclaridora.
En aquesta aplicació a més de l'autenticació hem fet molta feina amb jQuery, hi ha moltes dades amb autocompletat (per les companyies aèries i pels aeroports per exemple), validacions, quadres de diàleg modals, etc. Es tractava de fer una aplicació el més àgil possible, però sense deixar de ser una plana web, per tal de no assustar massa als nostres usuaris. És una cosa en la que s'ha d'anar alerta, m'agrada molt l'article de Jefff Atwood Avoiding The Uncanny Valley of User Interface que explica el perquè es pot produïr un rebuig de l'usuari quan les coses volen ser massa paregudes al que ja coneix però sense arribar a ser-ho. En el nostre cas els usuaris conèixen les aplicacions d'escriptori i les interfícies de Forms i qui més qui manco sap fer anar un navegador web.
Podríem haver fet una aplicació RIA amb Extjs per exemple, però per molts dels usuaris que faran servir l'aplicació veurien que és una aplicació d'escriptori sense notar que s'executa al navegador. Per ells això implica complexitat, que algú en faci la formació individualitzada com es fa a les altres aplicacions. Massa cosa per el que ha d'esser una aplicació que té per objectiu imprimir un paper. Així doncs vàrem preferir que l'aplicació es semblàs a una plana web, amb formularis i enllaços, on el que s'imprimeix també és una plana web. Potser encara així algú trobarà l'aplicació complexe, però crec que ja serà per por i reticència al canvi més que per mor de l'aplicació en sí.
L'aplicació ha estat desenvolupada per un equip relativament nou en la programació Python i Django i tot i això s'ha pogut entregar en el temps previst (que ja considerava aquest fet per una altra banda). Això no fa més que refermar-me en el convencimient de que a més de la potència del llenguatge hem de considerar també la corba d'aprenentatge a l'hora de triar amb què farem el desenvolupament.
En aquest projecte i en els temps de crisi en que estam, encara em resulta sorprenent que hi hagi algú que es qüestioni si la base de dades en lloc de ser Postgres no hauria de ser Oracle. En aquests casos m'agradaria poder amollar allò de "It's about costs stupid!" i dedar-me tan ample. El que més em sobta és que s'amolla com si tu fossis el que has de justificar la decisió, quan realment hauria de ser a l'inrevessa. Per què fer una cosa damunt Oracle quan es pot fer amb Postgres (o Mysql)? Amb preocupa aquest tipus d'inèrcia informàtica, de curtor, que no s'atura a pensar en els costs actuals i futurs, tant és si hi ha al mateix moment algú d'Oracle demanant pel nombre de llicències. Sorprenent!
Però bé, és d'aquestes coses que acabes assumint com a comportament normal i que potser ni amb tota la pedagogia del món s'arribarà a res. Tenc l'esperança que aquesta crisi que vivim al manco servesqui per a que la gent es plantegi un poc la relació costs beneficis. Sols que s'aturi a pensar-ho un moment de ben segur que ja no caldrà el justificar el perquè s'ha anat cap a una solució de programari lliure. La part ètica? Què voleu que us digui, si la part econòmica ja costa (i estam parlant d'empreses!) imaginau-vos que pot arribar a costar que s'entengui el que representa el programari lliure en la vessant social i ètica.
I és una llàstima, perquè hi ha moltes empreses sortint de l'armari, que publiquen el codi que fan servir internament en forma de projectes lliures, de llibreries. El darrer exemple que se m'acud ve del Washington Times que ha obert un blog amb un bon conjunt de projectes Django o també un post damunt robots controlats amb Python.
Projectes com els que treim darrerament venen a mostrar que la tan cercada reutilització, els mètodes per lluitar contra la crisi del software, potser són molt més aprop del que ens pensam. El codi lliure permet la reutilització a nivells mai somiats, Python a més ho fa més fàcil, Django ho fa divertit per la web.
