El dijous vaig partir cap a Hannover a la reunió periòdica de l'Open Source Advisory Group. Aquestes reunions serveixen per anar tractant l'encaix del programari lliure dins el grup, com es fa servir i intercanviar experiències d'eines de programari lliure. Per exemple ens presentaren el Testopia, una extensió de Bugzilla per a gestionar tests. No el coneixia i és força interessant. Hi ha que dir que el tema del Bugzilla ho tenen molt bé per allà, amb gent que s'hi dedica, personalitzat i força ben gestionat. Anar a Hannover, però implica també hores d'espera a l'aeroport (el divendres el vol sortí amb 3 hores de retràs a més) més les dues hores llargues obligades de viatges. En aquests ocasions procur endur-me'n un llibre en previsió de les esperes. En aquesta ocasió vaig optar per Software Mesurement and Estimation: A Practical Approach Linda M. Laird M. Carol Brena Quantitative Sofware Engenieering Series Lawrence Bernstein, Series Editor Wiley-Interscience Aquest va ser un dels llibres damunt enginyeria del programari més cars que he comprat mai, però he de dir que s'ho paga fins a l'últim cèntim d'euro. El volum està estructurat en forma de curs, amb teoria, exercicis resolts i problemes que es plantegen al lector. Són catorze capítols que tracten des de la teoria matemàtica de la mesura fins a mètriques de negoci, passant per predicció d'errors i l' estimació de projectes. L'edició és força recent, fent referència a dades del 2006 i té un component matemàtic i estadístic molt important. Si no us agrada l'estadística o les fórmules matemàtiques aquest no és el vostre llibre, però si voleu dades actualitzades, formalitzacions matemàtiques i estimacions disfrutareu del llibre tant com jo. He de dir que la informació que es presenta a cada capítol és bàsica, és a dir, no fa un aprofundiment molt gran en el tema, però sí que és suficient per fer-se'n una bona idea del que és cada concepte, dels seus punt forts i limitacions i de les possibilitats que té en el nostre treball diari. Els resultats es posen sempre en context estadístic i amb l'avís de que el primer de tot és el sentit comú, que per una part l'efecte de mesurar afecta al projecte (això em recorda als meus temps de físiques) i per una altra banda que l'estimació de projectes de programari té un marge d'error força gran. M'ha interessat molt per exemple el tema de la predicció d'errors en el programari i m'ha deixat amb moltes ganes de saber-ne més coses i de veure com en són de bones les prediccions amb les meves pròpies dades dels projectes. M'ha agradat veure també que coincidesc amb les autores amb que l'estimació de projectes per casos d'ús és una tècnica amb molt futur. En definitiva, he disfrutat llegint aquest llibre i segurament ho tornaré rellegir més vegades. La visió que tenen les autores del que és l'enginyeria de programari és molt semblant a la meva i el llibre en sí obre un munt de camins a explorar i recorre.

Aquests darrers dies ens hem estant barallant amb el sistema de pagament on-line de Sermepa. He de dir que el contacte que ens han donat a La Caixa per a la resolució de problemes és força atent, encara que les respostes siguin un tant telegràfiques. Tot i així i amb un poc de bona voluntat es pot fer un sistema de pagament amb aquesta gent amb facilitat, sempre, però que no te'n refiïs de la documentació. Així, com estic molt content de l'atenció rebuda per part del personal de La Caixa, he de dir que la documentació de connexió al servei XML de Sermepa és una de les documentacions més mal fetes que m'he tirat a la cara. Plena d'errors, de referències que no fan més que enviar-te d'un punt a un altre per a tornar al punt de partida, i d'uns exemples que no serveixen per res. N'hi ha un que és total, dona unes dades per mostrar com calcular la signatura (un sha1) i a l'exemple següent la calcula amb unes altres dades que no són les de l'exemple original, però per acabar-ho de rematar, si calcules l'sha1 amb qualsevol de les dues dades el resultat no és el que et presenten. Tenir un llenguatge de prototipat ràpid com Python per aquestes coses ens ha anat molt bé, ja que permet fer proves molt ràpid i al final i amb l'ajuda de la gent de La Caixa, arribar a completar una petició en vàlida. El dubte però és que si quan es fan les proves ens retorna codis que no són a la documentació, no hi ha massa garanties de que tot funcioni sempre. Serà una d'aquestes aplicacions a les que haurem de tenir constantment monitoritzades. Tampoc entenc aquesta mania dels serveis de pagament de presentar les operacions ordenades de menor a major data. Normalment quan vols comprovar alguna cosa t'interessa el darrer que has fet. Tant a Sermepa com a 4B passa el mateix, si fas moltes operacions en un dia has d'anar a la pàgina n-mil per obtenir el  que vols. Els sistemes de pagament haurien de ser els primers interessats en donar informació i serveis de qualitat, o potser se m'escapa alguna cosa... Per al client hi ha molts avantatges si pot eliminar un TPV físic i passar-ho a un TPV virtual, tant pel cost de cada cridada telefòica que fa, pel cost del TPV (si no t'ho cobren per lloguer ho fan augmentant-te la comisió) com per la velocitat de processament, i ja no en parlem si se tracta de potenciar el comerç electrònic. En el seu dia em va costar Déu i ajuda amb els de  4B admetessin visas ja autoritzades en els fitxers, ara pareix que la guerra estarà en aconseguir que els codis d'error estiguin ben documentats i que la interfície de gestió, el backoffice, sigui realment útil per a usuaris amb moltes operacions.

L'altra dia amb un consultor estàvem discutint damunt la conveniència o no de realitzar una aplicació de gestió bé en Oracle Forms o bé en tecnologia web, J2EE en aquest cas. És a dir, triar entre una tecnologia antiga o una tecnologia en constant moviment com és la tecnologia associada a la web. Fa uns anys jo mateix no m'ho hagués ni plantejat. Encara que era perfectament possible fer aplicacions web de gestió, quan la usabilitat i la velocitat d'entrada de dades i la validació d'aquestes era un punt crític, les aplicacions d'escriptori [1] eren molt més potentes que la tecnologia web del moment podia oferir. Ara per ara, però, si coparam el que es pot fer en entorns com Forms i en entorns web, la diferència jo no està tan clara. I si a més optam per tenir Oracle Financials com a base, aquesta diferència s'escursa encara més, ja que aquest precisament no destaca per la seva gran usabilitat. En aquests moments la tecnologia web ens proporciona la capacitat de crear complexes interfícies d'usuari, llibreries com YUI, Dojo, Google web toolkit, Zk, Tibco, Qoodox, etc. són productes prous madurs com per a deixar-nos construir complexes interfícies gràfiques que poc tenen que envejar a les aplicacions clàssiques d'escriptori, i que per executar-se sols necessiten un navegador. Que l'aplicació sigui d'escriptori clàssic o sols basada en navegador té molta importància quan parlam d'empreses que tenen la informàtica centralitzada i per tant s'han d'evitar al màxim els problemes derivats de la instal·lació i les actualitzacions [2]. Si un va un poc viu pot estandaritzar per a l'empresa un navegador que no ens doni sorpreses [3] i fer que les nostres aplicacions s'hi executin. L'argument que es dona a favor de desenvolupament de les aplicacions amb Forms, Delphi, VB, etc. en aquests moments és que és molt més ràpid desenvolupar en aquestes aplicacions que fer-ho en tecnologia web. En concret aquesta és l'excusa que em donà a mi el consultor amb qui discutia el tema. No he fet cap comparativa seriosa de velocitat de desenvolupament, sols he llegit alguns articles damunt el tema i tampoc hi havia massa diferència. El que sí m'he trobat és un problema que afecta a la velocitat de desenvolupament: quan fas una aplicació en un llenguatge com Forms o Delphi, la gent accepta que és una aplicació d'escriptori i mentre la disposició de botos i camps d'entrada els vagi bé, ja no hi ha més discussió. En canvi, quan l'aplicació és web, tothom és dissenyador! La comparativa entre ambdues tecnologies s'ha de fer amb els mateixos criteris, és a dir, o bé posant disseny a les aplicacions de Forms i totes les mandangueries que es demanen a les aplicacions web o bé deixant que una vegada s'ha establerta una línea mestre de disseny aquest es mantengui. Suposem però que tot i això el desenvolupament en Forms fos més ràpid, encara així hem de tenir en compte que és una tecnologia que ens limita:

• A una aplicació web podem mesclar fàcilment els conceptes d'escriptori i el millor que ens dona la navegabilitat de la web. Fer enllaços, drill-down, mostrar informació contextual és inherent a les aplicacions web i en canvi duen força treball en les aplicacions d'escriptori.
• La tecnologia de Forms és tancada i antiga, avançarà quan Oracle vulgui. La tecnologia web és fonamentalment oberta i ets tu quan tries que vols canviar. I el millor de tot, a la capa de presentació no hi ha més que html i javascript, per la qual cosa pots anar adaptant-te a la tecnologia segons te vagi millor sense afectar a l'usuari.
• El control de versions. Per mi és fonamental poder tenir gent que pugui fer feina si cal en el mateix troç de codi, en el mateix paquet i dur un control estricte del que s'ha canviat i de qui ho ha canviat. Això és molt mal de fer quan hom programa en Forms i PL.
• El factor humà. No dubt de la qualitat d'algú que avui en dia tengui com a màxima aspiració fer feina en Forms, però potser no és el tipus de gent que està oberta a canvis, que és capaç de trobar solucions imaginatives. En un entorn canviant les empreses han d'anar construint els seus equips de desenvolupament a partir de gent de pugui adaptar-se als canvis. Demà el negoci requerirà coses noves i haurem de ser capaços d'adaptar-nos. El factor humà és el que determina que l'èxit d'un projecte. La motivació i la qualificació dels programadors són un factor de primer ordre, el llenguatge de programació triat és un factor de segon ordre, i tots ens coneixem, és molt més motivant estar fent feina en tecnologies que tal com va el mercat informàtic poden queder sols per manteniments correctius i evolutius.
• El manteniment. Afegir nova funcionalitat a una aplicació web sol ser cosa de programar-ho o trobar les llibreries necessàries, o potser pensar "la manera web" de fer les coses. Fins i tot si desenvolupam en llenguatges d'script (php, ruby, django) una actualització que no afecti a base de dades pot ser tan simple com fer un update de subversion.

N'hi ha que diuen que les aplicacions d'escriptori són mortes, que en el futur tot serà web. Jo no ho tenc tan clar, m'agrada la potència de la fulla de càlcul de l'OpenOffice i m'agrada que s'executi al meu PC, però sí és cert que cada cop hi ha menys aplicacions que no es puguin fer pensant en que s'executin en un navegador, i en el cas d'empreses grans, o empreses que tenen el suport informàtic externalitzat, que les aplicacions de gestió estiguin basades en tecnologia web els pot estalviar molts maldecaps i sobretot moltes despeses d'administració i actualització.

---

[1] Permeteu-me que classifiqui a Forms com a aplicació d'escriptori clàssica encara que s'executi mitjançant un navegador per diferenciar-la de les aplicacions que sols necessiten el navegador, sense jinitiator ni més històries. [2] En aquest cas el jinitiator pot ser un mal son. [3] El Firefox home!

El tractament de cadenes de Python és potser una d'aquelles coses que fan el llenguatge més potent. He fet feina amb altres llenguatges: C, C++, Forté, Pascal, Basic, ... i de lluny el tractament de cadenes de Python és el més clar, potent i a la vegada intuïtiu que m'he trobat, sols s'hi atraca un poc un llenguatge un tant esotèric anomenat icon al qual m'hi vaig aficionar ja fa molt de temps. Anem a veure un parell d'exemples:

>>> a = "hola"
>>> b = ' món'
>>> print a+b
hola món

Com podem veure no import si feim servir cometes dobles o simples, i la concatenació de cadenes és simplement una suma. Tot i això hem de saber que les cadenes són també objectes i un dir ens dirà el que hi podem fer

>>> dir(a)
['__add__', '__class__', '__contains__', '__delattr__', '__doc__', '__eq__',
'__ge__', '__getattribute__', '__getitem__', '__getnewargs__', '__getslice__',
'__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__', '__mod__', '__mul__',
'__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmod__',
'__rmul__', '__setattr__', '__str__','capitalize', 'center', 'count', 'decode',
'encode', 'endswith', 'expandtabs', 'find', 'index', 'isalnum', 'isalpha', 'isdigit',
'islower', 'isspace', 'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip', 'partition',
'replace', 'rfind', 'rindex', 'rjust', 'rpartition','rsplit', 'rstrip', 'split', 'splitlines',
'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill']

Per exeple un help(a.zfill) ens dirà què fa aquesta funció

Help on built-in function zfill:zfill(...)    S.zfill(width) -> string
Pad a numeric string S with zeros on the left, to fill a field
of the specified width.  The string S is never truncated.
(END)

És a dir, afegeix zeros a l'esquerra fins a l'emplada que volguem: >>> a.zfill(10) '000000hola' Juguem un poc més amb les cadenes, què us imaginau que passarà si multiplicam una cadena per un sencer?

>> a*2
'holahola'

Bastant previsible, no? Python té aquestes coses, que pots preveure què passarà sense tenir-ne massa idea del llenguatge. Suposem ara que volem agafar trossos d'una cadena, python tracta les cadenes com a matrius de caràcters i per tant és possible fer coses com aquestes:

>>> test = "hola món què 'passa' per aquí"
>>> print test[0]
'h'
>>> print test[0:4]
hola
>>> print test[:4]
hola
>>> print test[9:]
què 'passa' per aquí
>>> print test[9:22]
què 'passa'
>>> print test[9:-9]
què 'passa'

Fixem-nos en el darrer exemple, hem fet servir valors negatius per a referir-nos al final de la cadena. També podem fer coeses com un recorregut pels caràcters de la cadena amb

>>> for char in test:
...     if char == "'":
...             print "cometa"
...
cometa
cometa

>>> [x for x in test if x > 'h']
['o', 'l', 'm', 'xc3', 'xb3', 'n', 'q', 'u', 'xc3', 'xa8',
'p', 's', 's', 'p', 'r', 'q', 'u', 'xc3', 'xad']

Però de llarg la meva preferida és la possibilitat de crear plantilles, a l'estil del printf de C o de les que darrerament ha incorporat Java 5, que ja era hora!

>>> missatge="hola %s, avui vindré a les %i"
>>> print missatge % ('Maria', 10)
hola Maria, avui vindré a les 10

O fins i tot fer servir diccionaris per això:

>>> missatge="hola %(nom)s, avui vindré a les %(hora)i"
>>> params = {'nom':'Catalina', 'hora':8}
>>> print missatge % params
hola Catalina, avui vindré a les 8

Me deix tota la part de funcions, expressions regulars i altres, això és sols per obrir boca, i potser ajudar a entendre a alguna gent del perquè el Python m'agrada tant. Us deix algunes referències:

• http://docs.python.org/lib/string-methods.html
• http://www.network-theory.co.uk/docs/pytut/Strings.html
• http://docs.python.org/tut/node5.html#SECTION005120000000000000000
• http://www.developer.com/open/article.php/628641
• http://boodebr.org/main/python/all-about-python-and-unicode

Llegint un post damunt com configurar el depurador de Python, el pdb de Ned Bachelder he arribat a un post de Coding Horror comparant els SEOs i els pornògrafs i finalment al blog de Bob Congdom, que feia referència a un article anomenat Refuctoring. El refuctoring és un patró de refactorització que parteix d'un codi font ben dissenyat i mitjançant una serie de petits passos reversibles es transforma en un codi que és totalment impossible de mantenir per ningú llevat de qui l'ha aplicat. Hi ha un pdf i tot on explica pas a pas com aplicar aquest patró. El pdf està dins un lloc web anomenat Waterfall 2006 dedicada a promoure la metodologia de la cascada com el milloret que hi ha. Un lloc molt recomenable i instructiu. No us perdeu alguna de les conferències proposades i dins les conferències alguns dels titols, així en traducció lliure

• Codi ple de defectes: com assegurar-se els ingressos mitjançant contractes de manteniment.
• Pair Managing: Dos managers per programador.
• Com fer anar l'outsourcing: un programador per continent
• WUP: The Waterfall Unified Procés
• Introducció a la programació dogmàtica. L'index de la presentació és fantàstic i la introducció no es queda enrere: conjunt de tècniques que alguna vegada funcionaren a algú i per tant poden funcionar-te pel teu proper projecte i pels propers projectes. Excuses creatives, o el no pensis, reacciona són part de l'index del taller.

Si us agrada l'enginyeria de programari no us podeu perdre ni el refuctoring ni el waterfall2006, jo encara no he pogut parar de riure. Friki total i sols per als iniciats!

L'altra dia amb Xisco i Suki de programari per la monitorització de xarxes d'ordinadors. No hi estic massa posat amb això, però entre unes coses i altres ha sortit una llisteta prou interessant:

• Opennms. D'aquest en puc donar fe de la seva capacitat de configuració. És capaç de gestionar-ho gairebé tot. Fet amb Java (J2EE) pareix que es prepara una nova versió que en millorarà molt l'arquitectura i la configuració. Hi ha un tutorial de com configurar-ho a howtoforge.
• Cacti. Gràfiques de moltíssima qualitat per tenir un control del què està passant als nostres servidors, xarxa, discs... No té el sistema d'avisos d'Opennms però n'és un complement molt interessant.
• Monit. Pel que he llegit és molt senzill. Hi ha també un tutorial a howtoforge.
• Zabbix. Un seriós competidor pel Opennms, també amb el seus corresponent tutorial.
• Zenoss. Un dels nousvinguts en el negoci de la monitorització, però que està pegant molt fort. Amb una presentació mot cuidada i programació basada en Zope i Python. També amb el seu tutorial d'instal·lació.
• Munin. Escrit en Perl no té la vistositat dels altres entorns, però per monitoritzar el bàsic dels nostres servidors també pot servir.
• Nagios. Tot un clàssic. Tant que l'havia deixat fora de la llista.

Me deix a la llista sofware com l'ntop que per casos concrets segurament aniran molt bé. Aquesta llista i sense cap ordre en concret, representa potser el millor que hi ha en aquests moments en programari de monitorització per Linux. Al manco fins el que jo he trobat.

Fa uns dies que estic de vacances i estic aprofitant per tancar algunes coses que tenia a mig començar. Una d'elles era la publicació d'un article damunt l'estimació de projectes de programari fent servir una tècnica que es basa en els casos d'ús que es fan a l'etapa inicial del projecte.

Aquesta tècnica és molt senzilla de fer anar i resulta sorprenentment acurada una vegada hem ajustat alguns paràmetres que depenen de la nostra organització.

Per fer-la anar basta un escriure els casos d´ús, cosa que tanmateix hem de fer si volem fer una estimació real de qualsevol projecte que es desenvolupi en programació orientada a objectes, i a partir d'aquí aplicar les regles d'estimació dins un petit full de càlcul.

Per projectes petits (de més de 10.000 línies de codi, però) i mitjans les estimacions obtingudes són tan bones com les d'un estimador expert i comparables a les que s'obtenen amb programari tancat i privatiu d'estimació de projectes.

L'article de Bulma és el 2376. Pos els enllaços directes al pdf amb l'article i les plantilles.

• Estimació de projectes de programari mitjançant casos d'ús
• Plantilla pel càlcul
• Exemple de càlcul i estimació

En alguns projectes personals amb Django estic fent servir un bastiment javascript anomenat jQuery. jQuery simplifica força la feina de posar javascript a les nostres pàgines i el seu cost en termes de complexitat de programació i pes dels javascripts és molt baix, tant baix com els 19 Kb de la llibreria comprimida, tal com es pot devallar de la seva pàgina.jQuery està molt ben documentat, encara que sense arribar al nivell de YUI, i triar una llibreria o una altra és moltes vegades qüestió de preferències personals. Amb els components DOM i Event de YUI tenim pràcticament el 99% de la funcionalitat de jQuery, però la cosa està en que si la nostra aplicació no fa un ús intensiu de javascript i a més volem tenir alguns efectes rollo web 2.0, doncs jQuery és una bona elecció. Si la nostra aplicació ha de ser molt més de tipus escriptori, directament aniria cap a YUI, ja que l'extra de components i funcionalitat que proporciona YUI és precisament el que li falta a jQuery.Quan posam jQuery i Django junts dins una típica aplicació web la combinació és molt bona. jQuery té tot un conjunt de funcions per fer peticions HTTPXMLRequest i tractarles i Django ho fà fàcil.Per exemple, suposem que volem generar un codi aleatori quan l'usuari faci doble clic dins un camp de text La part de Django seria: definir la url que cridarem dins urls.py (r'^ajax_get_codi/$','ajax_get_codi'), escriure el codi que ens tornarà la informació que volem , això es fa dins views.py i pot ser una cosa tan simple com def ajax_get_codi(request): "Torna un codi aleatori de vui caràcters alfanumèrics." import string import random llista = string.ascii_uppercase+string.digits codi = random.sample(llista,8) s = '' s.join(codi) return HttpResponse(codi, "text/html") Hi ha tantes maneres d'escriure aquest codi com programadors, sols notar que el que estam fent és que en lloc de tornar el control cap a una plantilla de Django retornam directament text amb el codi que volem presentar. La part javascript: $(document).ready(function(){ /* codi anterior ... */ {% if not codi %} /*Si estam en mode insercio permet crear un codi fent doble click */ $("#id_referencia").dblclick(function () { $.ajax({ url: "/agencia/ajax_get_codi/", success: function (msg) { $("#id_referencia")[0].value = msg; } }); }); {% endif %} }); Aquest javascript està dins una plantilla que hereta, sí heu llegit bé, hereta, d'una plantilla base que conté els includes comuns a tota l'aplicació. Un d'aquests includes és el jQuery. La resta és limita a que quan el formulari esta en mode insercio, la plantilla "pinta" la funció javascript i la lliga al control de text.