Aquest cap de setmana, entre copa de vi, fideus i passejades he llegit el llibre "Esquivant la mort" de Josh Bazell. És la història d'un assassí reciclat a metge. La portada diu que és "un thriller hilarant, entre House i Els Soprano". Jo no diria tant i crec que la comparació amb House li ve però que molt molt gran, coses del marketing.

Tot i això és un llibre molt entretingut, amb un ritme molt ben aconseguit i que t'engantxa, no tant per veure com s'acaba la cosa, sinó per conèixer-ne més coses del personatge i de la seva història.

M'ha agradat força. Absteniu-vos els sensibles.

Fitxa tècnica:

Esquivant la mort
Josh Bazell, traducció d'Elisabet Ràfols
Editorial l'Eclèctica bromera
ISBN 978-84-9824416-8

L'altra dia ens van donar un "curset" d'introducció a TIBCO i ho pos entre cometes perquè curset potser no és la paraula adient, ja que més aviat va ser una presentació comercial. Tot i això i entre capada i capada d'avorriment vaig tenir l'ocasió de parlar amb el formador (o deformador) dels serveis dins les possibilitat que ofereix TIBCO. Deia que era molt senzill agrupar serveis i generar el WSDL corresponent per a ser consumit fàcilment per altres aplicacions.

No dubt que això sigui així però les meves reticències fonamental venen donades pel fet de que quan vols que el teu servei sigui consumit externament, el que has de fer és facilitar al màxim que la gent ho pugui fer.

El SOAP és un protocol que va néixer per ser simple i que ha acabat essent complexe fins al punt de fer-se immanejable, sobre tot gràcies a les extensions que es varen introduir per a facilitar-ne la creació i consum per llenguatges concrets. L'article de Peter Lacey del 2006, anomenat The S Stands for Simple en fa una discussió emprant el mètode socràtic que s'ho paga llegir.

Quan per raons de negoci (el cap ho ha exigit, per dir-ho més clar) hem tingut que fer els web services amb SOAP el que hem procurat sempre és controlar molt bé el resultat final del WSDL de manera que fos fàcilment consumible tant pel qui l'ha creat (Java en el nostre cas) com per altres llenguatges (Python per exemple). Aquest resultat difícilment s'obté si qui genera el SOAP suposa que és el mateix que l'ha de consumir i per tant no veu la complexitat des del punt de vista d'un tercer, sinó que genera el WSDL de manera que la transformació inversa li sigui favorable.

Per una altra banda afegir la capa SOAP i consumirla té un cost (el famós payload) en termes de capacitat de procés i ampla de banda. Si alguan cosa té és que entre namespaces, definicions i subdeficinions, un missatge que podria de ser de pocs bytes multiplica el seu pes per 100 o per 1000.

Per una altra banda, la complexitat del WSDL fa que sovint no basti el WSDL com a documentació (un dels objectius del SOAP) sinó que s'ha d'adjuntar una documentació addicional explicant cada missatge, quins són els paràmetres, etc. Així que argumentar que el WSDL s'autodocumenta és pecar un poc d'ingenuo i optimista.

El SOAP és bo si es mantén simple, el problema és que fer-ho simple i consumible fàcilment duu molta feina i se suposava que això ens ho hauria d'evitar.

Ara mateix l'alternativa és tornar a la simplicitat. Evitar la sobrecàrrega de feina de màquina i gent que suposa el SOAP i anar cap a protocols més senzills:

• XML+HTTP. Amb una eina d'extracció de documentació podem fer la web de documentació i proves al mateix temps que escrivim el servei. Activant la compressió del gzip del servidor ens queda tot d'allò més compacte.

• XML-RPC. Anam un poc més enllà. Podem consumir l'XML com si d'una llibreria es tractàs. Igual que abans la documentació dins el codi ens pot permetre estalviar molta feina. David Fisher ha fet un exemple molt instructiu amb Django d'aquest concepte.

• Json-RPC o Json+HTTP. El Json s'ha convertit en un format d'intercanvi potent i senzill. Perquè no utilitzar-ho? Es pot consumir gairebé des de qualsevol llenguatge modern i la transformació a objectes nadius és trivial.

• REST. Utilitzam les URL si l'HTTP per al nostre intercanvi d'informació. És el que mou la web. Se li ha donat un nom i un conjunt de criteris per a formalitzar el mecanismes d'accés als serveis.

El gran avantatge de tot això és que la generació del servei no requereix de llenguatges "empresarials", sinó que ho podem fer fins i tot amb qualsevol microframework (web.py, Tornado, ...) amb Django o amb qualsevol cosa que ens permeti respondre a una petició http i tractar-ne les capçaleres.

Per Django per exemple tenim el projecte Django-Piston que ens permet crear una API REST per als nostres projectes d'una manera molt poc intrusiva.

Fa una bona temporada que el SOAP i els WSDL que hem fet sols estan en manteniment. Si els tengués que fer ara i depengués de mi o serien serveis REST o bé XML purs i segurament tampoc estarien fets en Java.

Quan un fa programes per aprovar l'assignatura sap que ha de posar comentaris perquè si no no és considera un codi professional, així que els posam per obligació, perquè hi han de ser, però potser sense adonar-nos de la seva utilitat real.

Els programes que feim per aprovar rarament són molt complexos, són exemples que es poden fer en poques setmanes i que rarament s'hauran de mantenir. La vida real és força diferent, els programes tenen un cicle de vida llarg, d'anys o dècades i s'han de fer millores correctives i adaptatives.

Aquell programa que ahir teníem molt clar al cap d'uns anys potser ja no ho tindrem tant i els comentaris que posàrem faran que tot ens resulti molt més fàcil d'entendre. I ja no diguem res si no som nosaltres el que hem de mantenir el codi!

Els bons comentaris ens haurien de dir el perquè del codi, què fa, què espera a l'entrada i què a la sortida. El codi ens dirà com ho fa. Això vol dir que el codi també ha de ser llegible, teclejar una mica més no costa tant i podem posar noms a les variables, a les classes, a les funcions, que tenguin significat.

Python per exemple té dues castes de comentaris, els que es fan servir per documentar el per què, i que sovint es presenten en forma de cometes triples i que es lliguen al doc (i a l'ajuda) de l'objecte i els comentaris fets amb la parrilla (#) que s'han de fer servir per comentar aspectes del codi que no necessitin. Java té quelcom semblant.

Però podem anar una mica més enllà. L'altra dia al twitter algu deia que li quedava fer la documentació de la pràctica. També molt habitual :) Posar bons comentaris ens pot estalviar una bona feina i no tan sols això, sinó que serà text de qualitat ja que s'ha fet amb menys presses i amb la ment més fresca en relació al que se està fent.

I encara una utilitat més: el pseudocodi. Particularment quan he de fer una cosa complexa començ per escriure'n les passes i les pos en forma de comentari. D'aquesta manera tenim més clar el que s'ha de fer i el temps s'aprofita, ja que aquest pseudocodis seran després els comentaris que ajudaran a seguir millor el codi.

No vull acabar sense citar una eina fantàstica per a la documentació: l'Sphinx us podeu adonar d ela bona feina que fa amb la documentació de Python o Django per exemple. Sphinx té una cosa molt bona, ens permet extreure els comentaris del nostre codi Python i afegir-los a la documentació, de manera que du el reaprofitament i la màxima DRY al món dels comentaris i la documentació. Per poc que us agradi el RestructuredText no deixeu de fer-li una ullada a aquesta eina, fins i tot si no programau en Python.

Per cert, en el seu dia vaig deixar un petit tutorial de RestructuredText a Bulma.

Disclaimer: Avuir parlaré un poc de jo. Em sap greu pel qui tengui que aguantar les meves batalletes, però com molts sabeu mantenc aquest blog perquè m'agrada i a més em desestressa, ja que em permet reflexionar i posar en clar pensaments que d'una altra manera quedarien fent voltes pel cap.

Mode batalleta ON!

Potser us n'haureu adonat que tenc dues feines: la principal, com a cap de projecte web a una important empresa turística i APSL una aposta de futur junt amb altra gent i que em permet explorar camins que em serien molt difícils de seguir a l'altra banda. Potser hauria d'afegir una tercera, la de pare de família, però deixem-ho aquí, ja que si bé te a veure amb la gestió de projeces, no té res a veure amb la programació :)

Fa uns anys l'empresa principal es fa fusionar amb un altra d'igual tamany i ara han arribat a IT les onades del tsunami en forma de subrogació de contractes. Dins la xerrada damunt el que es guanya i el que es perd per mi té molt manco importància el fet monetari o de posició com el concepte de "qualitat de vida".

Com podreu suposar m'agrada la feina que faig. Cap feina és perfecte i per això APSL cobreix la part que a l'altra li falta: possibilitat de relacionar-se amb clients externs, contacte amb el mercat real, gestió des de zero de l'empresa, ...

La subrogació d'empresa en principi implica mantenir les mateixes condicions laborals, però òbviament la part subjectiva, el que jo anomen qualitat de vida canvia o pot canviar. I com que m'agrada fer llistes us explicaré algunes de les coses que més valor.

• La diversió. M'agrada divertir-me fent feina. Sentir passió pel que faig, superar reptes i posar coses en marxa i acabar-les. Per mi avorrir-me no és tenir poca feina, un es pot avorrir estant les vuit hores fent el mateix o no fent res. No avorrir-se és fer el que a un el motiva i li agrada, i per mi això és fonamental. Passam massa hores a la feina com per passar-les a disgust. Trob que aspirar a fer una feina que t'agradi i que a més et paguin és una aspiració a la que no s'ha de renunciar.

• La proximitat. No m'agrada conduir, i no m'agrada estar 40 o 50 minuts a la carretera. Si no em fes res podria estar fent feina a la Península per molt més sou, però valor molt la qualitat de vida que em dona plantar-me a l'oficina des de Binissalem en 15 o 20 minuts i tenir temps suficient per arribar a fer un cafè. Fa anys vaig canviar de feina, estava a Viajes Iberia, el factor decisiu va ser el que necessitava 40 minuts per aparcar i anar a l'oficina, més 20 minuts de trajecte. Estava molt bé allà, però per mi això no és qualitat de vida, i és una de les feines o he estat més còmode, amb companys i caps magnífics.

• L'horari. Cap horari és perfecte, d'això en sóc ben conscient. Tot i això m'agrada que el meu horari em permeti arribar a casa a temps per ajudar els menuts amb la tasca, amb temps per llegir, amb temps per dedicar-ho a APSL. Està clar que no necessàriament tot al mateix dia i a la mateixa vegada. M'agrada més un horari continuo que un de partit, i si no pot ser un horari compacte. Les guàrdies no m'agraden pel que signifiquen a l'impacte de la vida familiar.

• El lloc de feina. M'agrada tenir una taula ampla. Sóc molt dispers amb els trastos i m'agrada tenir a mà llibres, apunts i al manco dos ordinadors. La cadira se suposa còmoda i el monitor decent, quan puc triar jo dos monitors (a casa i a APSL). M'agrada tenir a mà una pissarra i un lloc de reunions on fer els scrums diaris. M'estim més el silenci que el renou i m'agrada poder sentir la llum solar. Tenir una cafetera és fonamental i millor encara si el cafè és bo i el paga l'empresa.

• De l'ambient. No sóc classista, trob que la relació amb la gent ha de ser franca i oberta independentment del rol de feina que tengui cada un. No m'hi trob còmode en ambients on per tenir una carrera laboral has de llepar culs i riure gràcies quan no en tenen i no fer-te amb els subordinats. M'agrada que em diguin les coses amb franquesa, educació i a la cara, i procur fer el mateix. Intent separar la persona de la feina, encara que sé que és difícil. Si algun aspecte de la feina de la gent del meu equip no m'agrada procur fer-li saber, no com a retret, sinó com a ajuda. Tant fa lo bé o malament que me caigui una persona fora de la feina, dintre a més de l'amistat hi ha una relació professional, una feina a fer i un grup en el qual tots depenem de tots.

• De la tecnologia. M'agrada fer les coses de la manera més eficient possible o al manco tan eficientment com es pugui. Sóc partidari de tecnologies obertes i de llenguatges de programació i metodologies àgils. No conceb la programació sense un sistema de control de versions. Poder fer projectes amb Python és part de la diversió.

• De la gent. M'agrada la gent amb iniciativa, que proposi coses, que accepti noves idees. Valor molt poder confiar en que la gent amb dirà que estic equivocat si troben que ho estic o que seran lliures de proposar millores i noves maneres de fer les coses. Hi ha gent que se sent còmode amb pilotes i beneits perquè no li fan hombra, a mi m'agrada poder dir que faig feina amb gent que és tant o més vàlida que jo.

Ens passam molt temps a la feina i crec que ja tenc prou experiència com per valorar aquests factors subjectius tant o més que una promesa de projecció de carrera o incentius econòmics. El sou és important, no diré que no, però a l'hora de agafar una feina o de decidir deixar la que tenc el que pesa no és tant el sou com les perspectives de millora en qualitat de vida, en tenir una feina prou interessant com per a que valgui la pena aixecar-se cada dia per anar a la feina.

Mode batalleta off!

Fa pocs dies s'ha alliberat un motor web anomenat Tornado part de la tecnologia que mou FriendFeed.

És un servidor no bloquejant que promet molt en quan a velocitat, pensat per moure FriendFeed i escalar la càrrega que faci falta.

Independentment de que es pugui desenvolupar amb ell tot una aplicació, sols la part de servidor http ja és prou interessant com per fer-li una ullada. En un post a la llista de Django Bret Taylor, un dels autors de Tornado, postejava com connectar el motor amb Django mitjançant WSGI.

Actualment una de les configuracions que més m'agraden per desplegar aplicacions és la combinació nginx+CherryPy WSGI+Django (amb balancejadors, memcached i tota la pesca gràcies a la bona feina de Bernat i Pere), així que estava força intrigat per veure com respondria Tornado.

La base estava feta: una mini-aplicació "hello world" que vaig escriure per comparar aquesta tecnologia/arquitectura amb diferents frameworks PHP, així que ha está un no res actualitzar la darrera versió de CherryPy WSGI i crear una nova aplicació semblant per Tornado.

El codi font és a:

• CherrPy Hello World
• Tornado Hello World

I ara els resultats:

La màquina és un PPC 1 Gb de RAM, 2 CPU de 2 GHz

Amb Tornado WSGI:

ab -c 10 -t 60 http://localhost:8888/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Finished 25022 requests

Server Software:        TornadoServer/0.1
Server Hostname:        localhost
Server Port:            8888

Document Path:          /
Document Length:        266 bytes

Concurrency Level:      10
Time taken for tests:   60.019 seconds
Complete requests:      25022
Failed requests:        0
Write errors:           0
Total transferred:      9333206 bytes
HTML transferred:       6655852 bytes
Requests per second:    416.90 [#/sec] (mean)
Time per request:       23.987 [ms] (mean)
Time per request:       2.399 [ms] (mean, across all concurrent requests)
Transfer rate:          151.86 [Kbytes/sec] received

Connection Times (ms)
             min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       6
Processing:     3   24   1.9     24      68
Waiting:        0   24   1.9     23      68
Total:          7   24   1.9     24      68

Percentage of the requests served within a certain time (ms)
 50%     24
 66%     24
 75%     24
 80%     24
 90%     25
 95%     26
 98%     27
 99%     28
 100%     68 (longest request)

Usant CherrPy amb 3 threads (la millor configuració per la meva màquina segons les meves proves)

ab -c 10 -t 60 http://localhost:8088/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Finished 21500 requests

Server Software:        CherryPy/3.0.3
Server Hostname:        localhost
Server Port:            8088

Document Path:          /
Document Length:        266 bytes

Concurrency Level:      10
Time taken for tests:   60.001 seconds
Complete requests:      21500
Failed requests:        0
Write errors:           0
Total transferred:      8299000 bytes
HTML transferred:       5719000 bytes
Requests per second:    358.33 [#/sec] (mean)
Time per request:       27.907 [ms] (mean)
Time per request:       2.791 [ms] (mean, across all concurrent requests)
Transfer rate:          135.07 [Kbytes/sec] received

Connection Times (ms)
             min  mean[+/-sd] median   max
Connect:        0    0  20.5      0    2999
Processing:     3   28  10.7     26     413
Waiting:        3   26  10.3     24     412
Total:          3   28  23.1     26    3031

Percentage of the requests served within a certain time (ms)
 50%     26
 66%     28
 75%     30
 80%     31
 90%     34
 95%     38
 98%     43
 99%     48
 100%   3031 (longest request)

En resum:

416.90 req/s for Tornado WSGI
358.33 req/s for CherryPy

Tornado fa que una CPU es posi al 100% gairebé des del començament de l'execució de la comanda ab, CherryPy també posa la CPU al 100% però ho fa més tard i potser això explica la diferència, potser algún gurú de CherryPy em podrà dir una configuració millor que la que tinc.

58 peticions representen un 16% més de peticions que pot aguantar Tornado respecte de CherrPy, i si us hi fixau el codi que es necessita per executar-hi Django és pràcticament calcat gràcies al WSGI.

Seguesc fent proves, però per ara la cosa pinta molt bé.

Aquesta setmana he acabat de llegir Lean Software Development, An agile toolkit de Mary i Tom Poppendieck.

El llibre descriu la metodologia anomenada Lean Development, un conjunt de pràctiques i consells que ens poden ajudar a agilitar els nostres desenvolupaments i minimitzar el riscs dels nostres projectes.

El Lean Delopment és la translació de les pràctiques de desenvolupament de vehicles de Toyota al món del programari, que es resumeixen en set principis:

• Eliminar la brossa. Tot allò que no aporta valor al producte des del punt de vista del client és brossa.
• Potenciar l'aprenentatge. El desenvolupament no és duu bé amb pràctiques que fermen la gent, les típiques de la producció en cadena de bens de consum.
• Decidir el més tard possible. Deixar els desenvolupaments oberts als canvis, de manera que cuan la decisió es prengui es pugui aplicar el més aviat possible.
• Entregar el més aviat possible. Els cicles de desenvolupament han de ser curts i permetre a l'usuari i al programador entendre millor el que es vol mostrant el que ja es té fet.
• Potenciar l'equip. Els programadors saben fer la seva feina, i la millor manera de gestionar un equip no és mitjançant el mocromanagement sinó donant-los marge de maniobra i capacitat de decidir.
• Construir pensant en la integritat. La integritat és allò que l'usuari perceb com a un tot, com un producte redó, i allò que el programador a nivell intern perceb com a un tot que funciona.
• Veure el conjunt Evitar la micro-optimització i la suboptimització, és allò de que els arbres no et deixin veure el bosc.

Els autors proposen 22 eines per pensar, que desenvolupen aquests set principis i ens fan reflexionar damunt el que és el desenvolupament de programari i el paper que e el Lean Development dins el conjunt de metodologies àgils.

El Lean Development més que una metodologia és una filosofia de desenvolupament. Xoca frontalment amb ISOs i CMM i totes aquestes coses oficials amb tantes sigles. Amb tot allò que vol fer que el desenvolupament de programari s'assembli a una cadena de muntatge, ho resumeix molt bé a una cita de McNight "If you put fences around people, you get sheep. Geve people the room they need.". Tanmateix la manera clàssica de fer de les cadenes de muntatges s'ha demostrat ineficient i per tant passar-ho al programari és intentar aplicar una metodologia que ja se sap que no és bona.

També toca un dels aspectes més problemàtics del desenvolupament: com s'apliquen les metodologies àgils quan un fa feina per tercers i té que fer un pressupost. El Lean development té com a filosofia donar al client allò que necessita en lloc d'allò que ha demanat i això no encaixa massa bé amb especificacions tancades i pressuposts clau en mà. El llibre proposa tot una sèrie de tipus de contracte diferents dels habituals. Un dels que més m'ha agradat és el co-source contract, on les dues companyies fan feina juntes i hi ha una transferència de coneixements del venedor al client.

El tema de l'aplicabilitat de les metodologies àgils quan fas feina per un tercer és sempre problemàtica. S'han d'explicar molt bé les coses i el client ha de tenir la voluntat d'entendre i la confiança mútua de que cap de les parts intentarà aprofitar-se de la bona fe de l'altra. Els contractes a preu fitxe donen lloc a usuaris insatisfets - veure també Is Fixed-Price Software Development Unethical?- però en la meva opinió l'usuari també ha de ser conscient del que està demanant al desenvolupador. Si la seva intenció és transferir el risc del projecte a l'empresa desenvolupadora llavors segur que hi haurà problemes, ja que el venedor intentarà protegir-se fent exactament el que diuen les especificacions.

M'agrada la definició de confiança que els autors atribueixen a Dyer: "la seguretat de que l'altra part complirà amb les seves obligacions i que no explotarà les vulnerabilitats". Crec que és la base d'una bona relació comercial: el comprador no explota al venedor i aquest no se n'aprofita del client més que per l'obtenció d'un benefici just. Ben allunyat del "pelotazo".

Si ja estau familiaritzats amb les metodologies àgils, especialment l'Scrum, els conceptes del Lean Development us sonaran molt. El llibre més que donar consells de com aplicar la metodologia com una recepte, ens convida a pensar en cada un dels conceptes, en cada una de les 22 "eines per pensar" que hi ha al llibre.

El llibre m'ha agradat, potser perquè compartesc molt de la filosofia i pensament que hi ha a les seves planes, el tractar el desenvolupament com a una tasca de persones no reemplaçables, on s'ha de potenciar tant l'individu com el grup. El llibre serveix per a reflexionar, per a pensar en el que estam fent en el dia a dia, diria que el podríem classificar com un llibre d'autoajuda del desenvolupament de programari.

Fitxa tècnica:

Lean Software Development. An Agile Toolkit
Mary Poppendieck i Tom Poppendieck
Ed. Addison-Wesley
ISBN-13: 978-0-321-15078-3

M'agrada llegir llibres damunt metodologies de programació, especialment m'agraden aquells que et fan pensar, és a dir, que no et diuen fil per randa el que has de fer sinó que fan que una vegada llegits quedi un remanent de coneixement aplicable i adaptable a les situacions del dia a dia.

Tot i això sempre me quede un regustet amarg perquè moltes de les coses que s'expliquen les veig massa idealitzades. Sempre hi ha un superusuari, un p_roject owner_, els directius saben el que volen i fins i tot hi ha pressupost per al desenvolupament.

Els projectes són prou grans per poder fe iteracions d'un més o dos, hi ha equips dedicats en exclusiva al projecte, la metodologia que es proposa al llibre (aplicada amb èxit o no) s'ha explicat, s'ha entès i ha estat assumida per la direcció de l'empresa.

El client entén perfectament què és una iteració i el perquè un pressupost tancat no és el més adequat, que les estimacions són sols referències i que podrà veure el progrés del programa sense cap problema.

El client accepta de bon grau les reunions periòdiques, testeja el programa i fa les correccions adients per tenir el que vol, òbviament mai s'entra en coses tan poc agradables com discutir qui es fa càrrec dels canvis...

Potser els països anglosaxons (la majoria d'autors que llegeixo són d'allà) ho tenen millor assumit, o les companyies són més grans i tenen menys por a invertir en desenvolupaments trencadors. Vet a saber, però ara per ara per mi aquestes situacions s'assemblen més a un conte de fades que a una situació real.

M'agrada pensar que potser algun dia em veuré en una situació semblant a la que conten els llibres, però ara per ara, em qued sols amb les idees, que amb un poc de sort em serviran per pensar com millorar el procés de desenvolupament.