Demà partesc cap a FITUR a primera hora del matí i fins pràcticament a darrera hora de la tarda. FITUR és un bon lloc de trobada per veure com està l'estat de la tecnologia en el món turístic, fe contactes i com a punt comú de reunió. La fira coincideix amb el llançament d'un nou portal B2B que ens ha tengut fent feina a les totes els darrers dies. Aquesta vegada pràcticament sols hem tengut tres setmanes per enllestir-ho tot. I encara així el resultat és bastant acceptable. En aquests casos sempre hi ha d'haver un compromís entre el que a un li agradaria, el que pot tenir i els desitjos del client intern que té la seva pròpia idea del que ha de ser l'aplicació. Com en altres ocasions molta de la feina està a dintre i no es veu. En aquest cas hi ha tota una arquitectura de marca blanca, ús de sistemes cau per a les dades i javascrip/Ajax a dojo per la part interna per fer que l'aplicació sigui més ràpida de manejar i usable per professionals que s'espera que el facin servir com a un dels seus principals sistemes de reserves d'hotels. La part Ajax s'ha fet amb DWR i YUI, l'ajud de Google i d'un bon grapat de gent que desinteressàdament ha posat tutorials, consells i llibreries a la xarxa, con en Max Guglielmi i la seva llibreria de filtratge de taules per javascript. Els propers dies seran de ressaca, de tunejar l'aplicació, de cosetes que s'han de polir, però si això no és desenvolupament ràpid que vengui en McConnell i ho vegi.

De tant en tant faig algun apunt per tenir una referència posterior, a manera de documentació per tal de no oblidar-me de com se fa una cosa, d'una referència o procediment. Avui és un d'aquests apunts.

Com he comentat en altres apunts darrerament estic fent molta cosa amb Python i Django com a bastiment MVT web. En un món ideal el meu G5 funcionaria de conya amb l'Eclipse i tendria un depurador de Python integrat a l'IDE, però com que no tot pot ser tan meravellós com la combinació de Python i Django, doncs vaig tenir que cercar alternatives. Una prou bona és el Kdevelop, així que al G5 per programar utilitz les següents eines:

• Kdevelop com a Editor principal. Ben bé es podria fer amb Kate, però m'agrada la funcionalitat extra que aporta.
• Vim, no pot faltar mai!
• svn per interactuar amb el repositori subversion. També feia server kdesvn però al final m'és més còmode la línea de comandaments.
• kdiff3. Que la comparació visual està molt bé, tú!
• Firefox amb les extensions de webdeveloper tools i firebug
• Eclipse. Quan la gestió dels canvis se me complica i puc mantenir-ho estable el temps suficient per fer els canvis.

El problema d'això és si no es fa servir l'Eclipse no disposam de depurador integrat a l'IDE. [1]. Això per mi és un problema, menor, sí, perquè Python és prou net i elegant i la informació de depuració de Django prou extensa com per anyorar-ho poc, però què voleu, m'agrada al manco tenir l'opció de poder seguir la traça d'un programa sense tenir que tirar de logs i prints. [2].

Doncs mirant un poc pels fòrums de Django i un poc per Google, he arribat a la següent recepta:

1. Executam el servidor de Django amb l'opció de noreload: python manage.py --noreload runserver
2. Al fitxer el codi del qual volem depurar feim from settings import DEBUG if DEBUG: import pdb

L'important aquí és l'import, l'altre codi sols és per assegurar-nos que si ens deixam el codi de depuració en producció "petarà".

3. Per acabar al lloc on voguem posar el punt de ruptura escriurem: pdb.set_trace()

Això fa que en arribar a al punt hom hem establer la traça, la consola del servidor de Django ens mostri el símbol de depuració.

-> user = request.user

(Pdb)

A partir d'aquí ja hem entrat en mode de depuració i basta llegir-se un poc la documentació del depurador integrat de Python per anar tirant. Recordem que no estam sols davant d'un simple depurador, sinó que tenim tota la potència de Python al depurador mateix. Un tutorial força senzill per començar és Debugging in Python.

Una vegada acabeu de depurar hem de recordar llevar o comentar el pbd.set_trace(). Possiblement hi haurà maneres més potents de fer això, com la depuració remota, però aquesta és prou senzilla de fer anar. [1] Eric en duu un de depurador integrat, però darrerament no hi ha manera de posar-hi accents a l'editor i no es cosa sols del G5, així que l'he descartat de moment com a IDE.

[2] He vist gent no fer servir el depurador integrat de l'Eclipse programant en Java, però me'n reservaré l'opinió.

Doncs això, d'entre totes les propostes d'innovació, millora i nous negocis que s'han presentat a l'empresa per la que treball el nostre grup ha quedat el segon, la qual cosa implica un viatge als Estats Units pels quatre integrants del grup. Encara no tenim més detalls del premi, però un viatge a veure món sempre és interessant. Com que no conec en profunditat la proposta guanyadora, no puc dir si ens mereixem o no el segon lloc. El que si sé es que ens ho passàrem d'allò més bé redactant la proposta: fer un canvi tecnològic cap a veu damunt IP (VoIP) canviant les centraletes propietàries per centraletes basades en Asterisk. potenciant de passada les noves oportunitat que presenta aquesta tecnologia: teletreball, lloc de feina mòbil, gestió integrada de les cridades, independència del proveïdor, ... Quan redactàvem la proposta anàrem cap al cas pitjor, considerant les tarífes normals i considerant una inversió en equipament de qualitat. Tot i això el retorn de la inversió era pràcticament immediat i el risc mínim. A més, essent tot codi obert representa que podem connectar les centraletes amb els nostres sistemes de facturació, centrals de reserves (els call centers que en diuen), permetre gestionar de manera remota les línies de veu. Hi ha tot un conjunt d'aplicacions de codi obert que caldrà personalitzar i adaptar, però a diferència de les solucions que tenim ara, amb el codi obert tenim la possibilitat de fer-ho.

Aquesta setmana hem tingut a la feina l'avaluació del rendiment. Aquesta avaluació, si es fa bé, representa un bon moment i una bona excusa per parlar amb tranquil·litat de com et veu a tu el teu cap, tractar de punts forts i punts febles amb l'esperit de millorar. No entraré massa a valorar el procés d'avaluació, però si ja de partida la premissa és que algú que ho faci molt malament no traurà una nota tan baixa com es mereixeria i que la nota més alta sols està reservada a les elits, doncs pareix que de partida ja no és estadísticament significatiu. Però bé, la cosa és que l'entrevista va anar cap a que sovint faig servir paraules i conceptes mot tècnics. Això em va fer reflexionar damunt si en realitat al nostre ofici feim servir paraules massa tècniques per expressar conceptes que es podrien dir d'una altra manera i fer un poc d'introspecció damunt els conceptes i idees que hem de comunicar als nostres usuaris. Em permetreu que manllevi un concepte a Benjamí quan diu que un dels problemes de la informàtica és que s'ha establert a les llars molt de pressa, massa per poder ser assumida com ho és per exemple la mecànica dels cotxes. Imaginau-vos com seria fa un centenar d'any intentar explicar-li algú que venia dels vehicles arrossegats per cavalls els que era un motor d'explosió o una caixa de canvis. Tot i això la metàfora no és del tot completa, ja que l'implantació de l'automòbils a les vides de la gent va ser prou escalonada com per a que s'anessin assumint els conceptos de manera natural. A més els automòbils es poden veure, un mecànic ens pot explicar amb poques hores que és cada una de les peces i per a què serveix. Potser no comprendrem tots els conceptes, l'enginyeria i la física que hi ha per davall, però a poc que ens expliquin per a què servex cada cosa ja ens en podrem fer una idea. Hem fet nostra la tecnologia de l'automòbil al llarg dels anys, de manera que quan s'introdueix un nou tipus de caixa de canvis o un nou tipus de sistema injector tothom entén el que es vol dir i ningú es queixa que injector sigui una paraula massa tècnica. Amb la informàtica, en canvi, la gent encara no l'ha assumida com a pròpia. La gent senzillament se les arregla amb els ordinadors i molts sols han canviat el vell concepte de màquina d'escriure per un teclat i una pantalla que fa de paper. A aquesta gent conceptes con xarxa, cpu, proxy, caché, DMS els sonarà a xinès, el problema però és que tenen ordinador a casa i encara que no entenguin ben bé que hi ha per darrera fan servir tota aquesta tecnologia. Se les arreglen! Aquí tenim la gran potència dels ordinadors i dels sistemes operatius actuals: permeten a la gent que se les arregli, que faci coses sense saber ben bé què està fent. Els sistemes operatius actuals estan plens de metàfores per ajudar a que els usuaris se les arreglin, amagant el que hi ha per davall. [1] Què passa, però, quan aquesta gent ens demana una explicació de perquè no poden fer tal o qual cosa, o de perquè funciona o no ho fa tal altra?. Supòs que els metges i missers podran entendre perfectament la situació, llevat que en el nostre cas com que la gent té un ordenador a casa i normalment no té textes legals o mèdics. Ens trobam damunt un gran dilema. Normalment qui fa la pregunta ja t'ha fet saber que té un ordinador a casa (i un cosí/nebot/germà/cunyat/... que és un fiera amb la informàtica perquè se passa tot lo dia baixant pelis i cançons ), per tant espera una bona explicació, però la pregunta tot i que pugui semblar senzilla normalment amaga conceptes complexes que l'usuari potser encara no ha assumit, i no tenim manera de saber-ho. És a dir, si donam una explicació "per curtets" [2] el nostre interlocutor es pot sentir ofès. Imaginau-vos que el metge enlloc que dir-vos que teniu una infecció vírica us digués que se us ha ficat un bitxet molt petit al cos molt dolent i que us fa pupa. Supòs que també us ne sentiriu d'ofesos, no? Per una altra banda, si donam l'explicació que toca doncs potser el nostre interlocutor no entendrà el que volem dir. Què hem de fer doncs? No hi ha una resposta fàcil. Jo normalment tir cap a la segona opció, és a dir, la de suposar que el meu interlocutor es capaç d'entendre el que estic dient. Anar directament cap a l'opció de simplificar massa l'explicació per mi significa una minusvaloració del nostre interlocutor, suposar d'entrada que no serà capaç d'entendre'ns, i la veritat com a concepte no m'agrada. [1] En el principio fue la línea de comandos. http://biblioweb.sindominio.net/telematica/command_es/ [2] for dummies o "para torpes"

Estic subscrit a un lloc d'aquests de comunitats virtuals anomenat XING, no és cap cosa de l'altra món, però té una interfície que està prou bé. El seu model de negoci es basa en serveis de pagament opcionals i alguns d'ells l'invaliden un poc com a comunitat vitual, especialment si no et deixa estar en contacte amb la gent per e-mail si no pagues, però té de positiu que pràcticament no hi ha spam.

El sistema té un sistema de fòrums que es poden crear prèvia aprovació d'algun administrador de XING. Un dels fòrums de recent creació és el "Foro de gestión de contenidos Web". Com que és un tema que m'interessa professionalment hi vaig anar a fer una ullada.

Tot just després del missatge de presentació hi ha un e-mail que demana parer damunt CMS i donant la seva opinió l'autor de l'e-mail diu que per el Joomla és el millor CMS, i aquí el moderador/creador del Fòrum perd els papers i és dedica al FUD en lloc de discutir les bondats o no dels CMS.

Web21 es infinitamente más seguro que Joomla, por una razón muy sencilla, Joomla es código abierto, web21 no lo es. Joomla es un sistema que yo recomiendo para un sitio web personal, pero no para uno profesional.

I se queda tan ample. Em permet citar la discusió del fòrum perquè tanmateix és un copiar i aferrar del que posa a la pàgina web del Web21.

És a dir, seguretat per l'ocultació de codi. Això ja ens dona una idea del poc segur que deu ser el Web21 que han d'amagar com està fet per a que no els desmontin el xiringuito. A més paraules con "infinitamente" sols estan expressant que no s'ha quantificat gens el nivell de seguretat, no és dues o deu vegades més segur perquè s'han detectat i corregit tants de forats de seguretat o perquè el temps de resposta és millor. La raó és perquè ningú veu el codi. I encara hi haurà gent que s'ho cregui a això...

[..] Lo malo de estos CMS [referint-se als CMS de codi obert] se puede englobar en tres aspectos: - El código abierto siempre está expuesto a ataques por parte de hackers, una página web elaborada con un CMS de código abierto SIEMPRE estará expuesta a ataques de hackers inexpertos que sólo tienen ganas de fastidiar destrozando cosas. Los hackers profesionales NUNCA intentarán hackear nuestras páginas webs, van a por sistemas más importantes.[...]

Com els sistemes de codi obert suposo? :) És a dir, no t'atacaran perquè el teu CMS sols ho fan servir clients que són tan poc importants que no mereixien ni l'atenció dels hackers més inexperts. Sí senyor, d'això se'n diu fer-se bon marketing. És a dir, si jo vull que el meu lloc web arribi a ser important millor que ja no comeni posant el cms de web21, ja que no està pensat per a llocs webs importants. Segueix: El sitio web es seguro. Web21 es de desarrollo propio y su código no es accesible para el público en general. - Los módulos de adecuan perfectamente a la página y están testeados a conciencia. Es muy raro detectar algún fallo en los módulos, y si lo hay es mínimo.

Raro?, com n'és de raro?, quí ho testeja?. Es tècnics de web21 són més o millors que tota la comunitat que hi ha darrera els principals cms de codi obert? Quins són els errors mínims que hi ha? És molt fàcil dir que no hi ha errors quan no es pot auditar el codi. El problema amb les solucions tancades és que quan es detecta un error un no el pot corregir, sinó que ha d'esperar que l'empresa ho faci i perdem un temps molt valuós de resposta davant possibles atacs.

Nuestro CMS es seguro. El CMS de Web21 es de desarrollo propio y su código no es accesible para el público en general.

I segueixen, eh? Qui seria l'inconscient confiaria en un CMS que diu que és de desenvolupament propi del qual no se'n té accés al codi font i que diu que és segur perquè amaguen el codi, no perquè facin les coses bé?. Fer ús d'un cms tancat implica estar lligat al proveïdor, els teus continguts ja no són teus, són del proveïdor qui te tindrà fermat sols per la feinada que te duria canviar de gestior de continguts. Després de tot, per molts cms de codi obert hi ha camins de migració d'un a l'altra, per un CMS tancat com aquest no.

La veritat és que feia estona que no reia tant amb un FUD. Obviament el grup de CMS de Xing no serà un asidu de les meves visites llevat que vulgui riure un poc. La persona que va dir que per ell Joomla era el millor davant això ja s'ha despuntat del grup. Jo no m'hi he arribat a subscriure, sols hi he deixat un comentari de l'estil que escric al bloc.

Parlant de manera seriosa: el codi obert està en línia amb una de les pràctiques d'enginyeria de programari per garantir la qualitat del codi, la inspecció del codi. I en línia amb una altra recomanació com és la propietat compartida de codi. Aquestes són pràctiques recomanades per a desenvolupar programari de qualitat, i el codi obert ho duu a l'extrem quan tothom pot ser revisor de codi i tothom pot modificar el programa i millorar-lo.

A més hi ha un efecte psicològic important: quan programes i fas coses per a que les vegi un altre que potser ni tant sols coneixes, hi ha una pressió molt gran per fer-ho bé, per a no cometre errors, i això fa que el codi sigui millor. Si ningú ho ha de mirar normalment s'acaba amb codi d'anar per casa, i els problemes comencen quan es posa en producció i comencen a sortir el primers errors.

Per a una empresa un CMS de codi obert amb una bona comunitat d'usuaris suposa que té una mínima garantia de qualitat, de suport i de temps de resposta davant incidències de seguretat. El que no hem de confondre, com fa el FUD és codi obert en codi gratuït, el codi t'ho pots davallar, però no saps configurar-ho hauràs de contractar algú per a que ho faci i t'ho deixi com tu vols, just el mateix que es fa quan es contracta un consultora per a instal·lar un cms propietari, sols que en aquest darrer cas pagues tant el producte com la instal·lació i personalització, i en el cas del codi obert sols pagues pel servei que et proporcionen.

En la literatura de gestió de projectes és habitual trobar-nos amb el concepte d'hores-home per expressar la unitat de mesura de projectres, com a una unitat que expressa el temps necessari per a desenvolupar un projecte. Així 100 hores-home indica que el cost de projecte seria equivalent al de 100 hores d'un sol programador.

El problema de les hores-home és que es presten a confusió quan el nombre d'hores-home passa cap a gent no tècnica, que té que aprovar un pressupost o dir en quant de temps s'ha de fer un projecte.

a) Pot donar a entendre que les hores de programació són intercanviables. Es a dir, 100 hores-home per fer un programa poden ser fetes per 100 programadors treballant una hora, com per 10 programadors treballant deu hores, com per dos únics programadors que s'hi dediquen 50 hores.

b) Suposa que totes les hores de treball són efectives. És a dir, suposa que un programador és capaç de ser productiu des de el mateix segon que es posa a pensar en el programa.

Per evitar el primer problema el nombre d'hores-home ha d'anar acompanyat amb temps mínim de realització i el temps més probable, de manera que es pugui veure que l'augment del nombre de programdors a l'equip no implica necessàriament que es reduexi el temps necessari per entregar el projecte, és a dir, que quedi molt clar que hi ha un temps mínim per sota del qual no és possible entregar el projecte.

Molt més problemàtic és explicar el tema de la no intercanviabilitat de la gent. El més normal és explicar-ho en termes de coses que el nostre interlocutor ja conegui, indicant que hi ha gent especialista en cada cosa i que no es pot substituir fàcilment una gent per una altra. Comparar programadors amb metges és força efectiu, podem explicar que quan et fa mal un queixal no vas al proctòleg sinó al dentista. Els dos poden ser metges i molt qualificats, però cada un té la seva especialitat.

Atacar el segon supòsit implica no presentar la valoració del project en termes d'hores-home, convé anar cercant una altra unitat de mesura que ens permeti expressar millor el que és una hora de programació efectiva.

El concepte d'hores efectives està tractat molt bé al Peopleware, on es dedica tot un capítol complet al tema de les hores de treball ininterromput vers les hores de permanència a l'oficina. És el que anomena E-Factor, i ens dona una idea del treball que es perd per no tenir un ambient de feina que permeti tenir prou hores sense interrupcions.

Quan feim una estimació en termes d'hores-home poques vegades es considera la correcció que ve de l'E-Factor, de fet potser ni tan sols se'ns sap el valor, ja que ningú s'ho ha plantejat mai, sols se sap que els projectes es retràssen i no se sap ben bé perquè.

Per una altra banda, la metodologia de l'Extreme Programing proposa que les valoracions de les tasques es facin en termes d'Ideal Engineering Hours (IEH). És a dir, que les valoracions s'expressin en termes de temps sense interrupcions necessari per a completar dita tasca.

Particularment m'agrada molt la idea de tenir una unitat per expressar la dedicació necessària per fer un programa que implícitament té en compte que la feina es pot allargar més o menys en funció de les condicions laborals i de les interrupcions que es tinguin.

Fent servir les IEH com a unitat de valoració en lloc de les habituals d'hores-home estam transmetent la idea de que el desenvolupament de programari és una tasca on les interrupcions tenen un impacte molt gran en la productivitat dels programadors i per tant en el cost del projecte.

De retruc potser algú es demanarà el perquè d'aquest canvi i tal volta es plantegi poder calcular l'E-Factor.

Amb tot això ara quedaria discutir quina és la validesa de les estimacions de programari, és a dir, s'han de realitzar estimacions per saber el cost aproximat del projecte, però ens queda per saber com n'és de bona aquesta estimació o si ha d'anar lligada a que hi hagi una especificació completa del projecte, com si de fer un edifici es tractàs. Quan parlam de programari la comparança amb la construcció d'un edifici ens enfonsa la metàfora, però bé, això són figues d'un altre paner i ja miraré de parlar-ne més endavant.

Ara per ara potser alguns ja us estigueu plantejant presentar les vostres properes estimacions en termes d'IEH o anar calculant el vostre E-Factor particular, si ho feis m'agradaria conèixer quin és, que els estudis de productivitat en programari són més aviat rars en aquestes contrades i potser entre tots puguem treure'n alguna conclusió.