Al blog de Marcelo Ramos he trobat un apunt amb aquesta imatge

que pareix que prové de makeuseof.com. Una troballa prou divertida de Marcelo. :)

El de l'arbre de Nadal m'ha fet especial gràcia, ja que a l'oficina hi ha una divertida anècdota amb un rack de comunicacions i un arbre de Nadal com a protagonista.

Endevinau que s'havia desendollat per encendre els llums de l'arbre? ... Sí, això mateix!

Supòs que no he de convèncer ningú de les bondats dels tests unitaris a l'hora de desenvolupar.

Encara que no arribem als extrems que proposa la gent que fa "test driven development" tenir tests ajuda a l'hora de provar les aplicacions:

• Queda constància del que s'ha provat
• Les proves són repetibles
• Es poden anar afegint noves proves quan es detecten noves situacions i/o errors.
• Ens ajuden a la refactorització, ja que ens ajuden a comprovar que la refectorització no ha variat el funcionament del programa.

El clàssic en test unitàris per Python és PyUnit que segueix una aproximació diguem-ne ortodoxa, és a dir, basada en crear una classe que extén TestCase i a partir d'aquí anar agrupar els tests en el que s'anomena una TestSuite.

Una altra aproximació ben diferent és la de doctest, aquí el que tenim és que s'escriu el codi de testeig i la serva sortida dins de la mateixa aplicació, no hi ha API però sovint pot resultar un tant confús.

Finalment tentim un nouvingut (relativament, que ja té uns anyets) el py.test, que ve avalat per la gent de PyPy i que va ser creat per a testejar el desenvolupament de l'intèrpret de Python fet en Python.

En Grig Gheorghiu's té un conjunt de tres articles comparant unittest, doctest i py.test, encara que són un poc antics, en temps Internet, crec que ajuden molt a veure les principals mancances i avantatges de cada un.

• Característiques de pyunit
• Avaluació de doctest
• Article dedicat a py.test

Per suposat, hi ha molts més a sistemes de testeig, podeu trobar-ne una recopilació a Python Testing Tools Taxonomy

He estat gairebé una setmana desenvolupant i fent tests amb py.test, i he de dir que m'ha agradat, és molt més còmode de fer anar que cap dels altres. Basta que creis un mètode que comenci amb test_ o acabi en _test i ja ho tenim llest per ser provat, que passi el test o no sols es cosa de que hi hagi un asssert que retorni vertader si ha passat un testo o fals si no l'ha pasat.

Una de les característiques que m'han agradat més és la possibilitat de desactiva ràpidament un test amb disabled = True on el valor es pot substituir per una condició, amb la qual cosa podríem fer que un test s'executàs o no en funció de l'avaluació d'una condició, per exemple, si detectam que estam a l'entorn de producció no borrar la base de dades!

I també he trobat molt còmode l'opció de poder establir condicions d'inici i acabament per tot un mòdul, això m'ha permés per exemple, obrir una sessió i mantenir la connexió i el identificador de sessió per a tots els tests, tancant la sessió sols quan tots els tests ja han acabat.

La part que m'ha xocat és la manera de testejar les excepcion, ho fan amb

 py.test.raises(Exception, func, *args, **kwargs)
 py.test.raises(Exception, "func(*args, **kwargs)")

És a dir, s'ha d'importar el mòdul py i cridar a py.test.raises, després posarem l'excepció que volem tractar, la funció que s'ha de testejar i que genera aquesta expepció i seguidament els paràmetres que té la funció.

Crec que això ha estat la única cosa més complicada d'aprendre. La resta és tot ben natural.

Me falta provar la part de distribució de tests, però per ara crec que va camí de convertir-se en la meva eina de testeig Python de referència, a l'espera, això sí, de veure com ho puc integrar amb Hudson.

Benvolguts amics, coneguts i saludats,

Aprofitant la calor, la benentesa, i la moguda de Django estic aprofitant per retocar el sistema de trackbacks del blog.

Estic abusant un poc de la confiança i fent proves a altres blogs a més del meu, per veure si hi ha problemes.

Si veis alguna cosa rara, trackbacks que venen de trespams amb poc sentit o antics, perdonau-me, estic abusant de la vostra confiança i amabilitat. Procuraré no fer massa destrossa, i no cal dir-ho, esborrau el que convingui.

Django camina amb passes fermes cap a la versió 1.0, impulsat per la gent que vol una versió estable amb totes les millores actuals. S'ha definit tot una sèrie d'Sprints per a impulsar el desvenvolupament, anar integrant les millores ja provades i tancar tickets d'error.

En el procés hi ha tot un conjunt de decisions que s'han de prendre i que trenquen amb la versió estable anterior. Els canvis a Django són força graduals, i gairebé no trenquen mai les coses d'una manera bèstia, és veritat, les aplicacions deixen de funcionar, però és relativament senzill arreglar les coses si un ha anat seguint la branca de desenvolupament.

Un d'aquests canvis que "ha trencat coses" ha estat la integració del nou mòdul d'administració, que té força incompatibilitats, ja que refà tot el que era la definició de l'administrador. La gent de Django manté una llista d'incompatibilitats que fan que la feina, encara que se tengui que fer, sigui senzilla.

He actualitzat dos dels projectes que tenc a Google code, aquest blog per exemple. I ara queda anar migrant totes les aplicacions que tenim on-line. El trunk és massa bo i estable com per a no fer-ho servir, però de tant en tant dóna aquestes feinetes.

Estam plantejant fer una remodelació de la web B2B que tenim, ara està feta en Java i aprofitant la remodelació la meva intenció ( si me deixen clar), és aprofitar que la remodelació és força important per a reescriure el codi en Python i Django. Si fos un canvi petit no m'ho plantejaria, però és un canvi que pot dur mesos de feina i en aquest cas refer-ho amb Python suposa no allargar els temps de desenvolupament, encara que la feina global en termes de funcionalitat sigui més gran.

Però tampoc és cosa de tirar-se a la piscina, i abans de res convé saber amb què ens trobarem. Un dels aspectes més crítics és que hem de consumir un servei web en format xml sobre http. Cap problema, urllib per exemple és capaç de fer tot això i molt més, la cosa està en poder generar els xml i consumir-los en molt poc temps.

Aquest cap de setmana m'he entretingut fent un petit benchmark [1], volia comprovar una hipòtesis: fer servir un llenguatge de plantilles per generar les peticions xml i un parsejador per a consumir l'xml que m'arribarà. L'altra opció es generar les peticions directament amb la llibreria de parseig.

La primera opció té com avantatges que s'ha d'escriure menys codi i que queda força documentada la petició en sí. La segona te l'avantatge de que que sols fas servir una llibreria. Així doncs el que ha de dir la darrera paraula és el factor rapidesa. Serà més ràpida la llibreria de plantilles o la de l'xml?

Primer presentarem els candidats: per una part mako, un llenguatge de plantilles que surt molt ben parat a les comparatives de velocitat i de l'altra lxml una interfície Python damunt unes de les llibreries per tractar xml més ràpides del mercat libxml2 i libxslt.

Per fer les proves tirarem de les dades que representen els cotxes que he tingut:

    VEHICLES =  {'seat': {'id': 1, 'color':'blanc', 'preu':150000},
      'ax'  : {'id': 2, 'color':'blanc', 'preu':1100000},
      '505' : {'id': 3, 'color':'blanc', 'preu': 500},
      'saxo': {'id': 4, 'color':'blau',  'preu':1500000}
  }

El que farem és generar un xml que representi aquesta estructura de dades. Com que tant amb mako com lxml la cosa va força ràpida, farem 10.000 repeticions.

El codi per mako és

    from mako.template import Template
    template = """
     <vehicles>
    % for marca, desc in vehicles.items():
         <vehicle id = "${desc['id']}">
             <marca>${marca} </marca>
             <color>${desc['color']} </color>
             <preu>${desc['preu']} </preu>
         </vehicle>
    % endfor
     </vehicles>
    """
    plantilla = Template(template)
    for i in xrange(1, REPETICIONS):
        xml =  plantilla.render(vehicles=VEHICLES)

El que feim és compilar la plantilla un pic, per simular les condicions reals, ja que en una aplicació en producció és el que faríem, i renderitxar l'xml amb les dades fins al nombre de repeticions desitjat.

Per lxml la cosa és semblant, sols que el codi (si no tenim en compte la definició de la plantilla) és una mica més llarg

    from lxml import etree
    for i in xrange(1, REPETICIONS):
        root=etree.Element( 'vehicles' )
        for marca_vehiculo, desc in VEHICLES.items():
            vehicle = etree.SubElement(root, 'vehicle', id = str(desc['id']) )
            marca = etree.SubElement(vehicle, "marca" )
            marca.text = marca_vehiculo
            color = etree.SubElement(vehicle, "color" )
            color.text = desc['color']
            preu = etree.SubElement(vehicle, 'preu')
            preu.text = "%.0f" % desc['preu']
            xml2 = etree.tostring(root, pretty_print=False)

També en aquest cas procuram que hi hagi igualtat de condicions, i hem posat el pretty_print a False de manera que l'xml generat no estarà ben tabulat i no quedarà tan elegant com el el cas de mako, però també és el que faríem en un entorn de producció.

I ja està, ara sols falta executar-ho i mostrar-ne els resultats:

Repeticions	mako	lxml
100	0,0761 s	0.0277 s
1.000	0,2897 s	0.2823 s
10.000	2.3076 s	2.8906 s

D'això en treim dues conclusions:

• Que ambdues aproximacions són molt ràpides en la generació de l'xml.
• Que mako s'aprofita molt bé de la precompilació de les plantilles. En el benchmark he considerat que es compilava un pic i després s'executaven les repeticions. Si no consideram el temps de compilació

Repeticions	mako	lxml
100	0,0201 s	0.0277 s
1.000	0,2079 s	0.2750 s
10.000	1,9888 s	2.9513 s

És a dir, que si feim sempre feina amb el mateix tipus de peticions, l'opció de fer servir mako per a generar les peticions xml, compilant les plantilles a l'inici de l'aplicació és té un rendiment molt millor que generant l'xml cada cop amb l'lxml.

Per cert, les proves estan fetes amb Ubuntu Linux corrent en un PowerPC de doble processador de 2 GHz, és a dir, res de l'altre mon.

[1] Sí, ja ho sé, no m'hauria d'endur feina a casa

Protocol Buffer és una llibreria d'intercanvi de dades que Google ha alliberat i que segons promet és de 20 a 100 vegades més ràpida que l'XML (i ja no parlem de SOAP) per a l'intercanvi de dades entre aplicacions.

Lo de la velocitat s'haurà de comprovar, però el que sí pareix clar és que és prou senzilla per ser abastable, la documentació és bona, i ja va dirigida als tres principals llenguatges de programació (C++, Java i Python).

Com que en faig servir dos habitualment, doncs es cosa de fer-hi una ullada i algunes proves d'stress a veure si realment és tant ràpida com diuen.

La cosa no sé si s'imposarà com a format d'intercanvi entre llocs d'Internet, però el que sí tenc clar és que si és més ràpid pot ser ideal com a format per a tecnologies SOA dins de la mateixa empresa. Una reducció d'un factor 10 ja seria prou bona, amb l'avantatge de que es podrien crear (com ara, per cert) serveis en un llenguatge i consumir-los en un altre, però sense tenir que pagar el preu que suposa en termes de rendiment fer-ho en format WSDL.

Es prest, per donar-ne una opinió amb més fonament, però pel que he vist de la documentació i els exemples, crec que aquest format i jo ens durem bé :)

Aquesta setmana ens hem vist amb la necessitat de crear una aplicació que havia de connectar amb un web service i agafar les dades de l'aplicació legacy que està feta en Oracle.

Hi havia dues alternatives, l'opció de salvemos el culo que implicava fer-ho tot en Java i no arribar a temps, o jugar-nos-la i fer-ho en Python i Django, i aquí el Boogeyman [1], no ens havíem trobat mai amb la necessitat de connectar directament Django amb Oracle, així que el primer de tot va ser veure com es podria fer i si ens trobaríem algun problema.

Per connectar amb Oracle, s'han de fer servir una llibreria anomenada cx_Oracle i de les llibreries d'Oracle mateix. Com que no vaig trobar les llibreries per la meva versió d'Ububuntu, doncs a compilar toca!. Vaig trobar una guia força bona a la web, sols vaig necessitar instal·lar una llibreria addicional a Ubuntu - si no la teniu en executar us petarà per a que no la troaba, i posar les llibreries d'Oracle a l'ldconfig.

Així doncs, vençut el Boogeyman, tota la resta era conegut i controlat: els serveis web amb ZSI encara que pot resultar un poc embullat al principi, quan li agafes el què, és molt potent. Si a més li posam una façada per adaptar-ho al que volem, consumir serveis web fets amb SOAP deixa de tenir misteri. Per una altra banda la part de manteniment web amb Django ja està força controlada, i la part de consola que també havia de tenir l'aplicació tampoc era nova. Python de fet té una utilitat anomenada Cmd o també es pot fer servir una utilitat de tercers anomenada cmd2 que hi afegeix algunes característiques interessants.

L'important d'aquesta història, però, no és la batalleta, no és tant veure que es pot fer feina amb Oracle amb Django i Python, sinó adonar-se de que per a que un projecte es pugui dur a terme amb garanties una de les coses més importants que s'han de fer és descobrir aquelles coses que sabem que no sabem i a ser possible descobrir el més aviat possible allò que no sabem que no sabem.

Si en aquest projecte s'hagués començat per altres tasques ens hauríem pogut trobar en dificultats a l'hora d'accedir a les dades i la feina feta serviria ben poc, o si més no, el projecte s'hauria endarrerit. Controlant el primer de tot el que pot donar dificultats augmenta les nostres possibilitat d'èxit.

---

[1] El Boogeyman representa allò que desconeixem i que ens fa por. Als projectes és important descobrir el primer de tot els monstres ja que ans al contrari ens poden donar un ensurt en fases on ja no hi podem fer res.