Avui he tingut una interessant conversa telefònica, una mini-consultoria d'una hora podríem dir, com a presa de contacte per a un projecte que sembla força interessant i ambiciós.

Com és habitual una de les preguntes ha estat per què Python i no PHP? La veritat és que no hi ha una resposta única, sempre depèn del projecte. No hi ha una tecnologia única que encaixi a tots els projectes i sempre s'ha d'avaluar bé. Però quan el projecte no té únicament una vessant web, les possibilitat de que Python encaixi millor són més altes. Després de tot Python és un llenguatge de propòsit general, que ha demostrat les seves capacitats amb branques tan diferents com la programació web o el càlcul numèric, passant per la generació de gràfiques científiques i el control de robots.

També, com gairebé sempre, surt el tema de que amb PHP es més fàcil trobar gent. És veritat, però també és més fàcil trobar gent amb Java o amb PL/SQL. El tema està en que si el que volem no és gent, sinó dur endavant un projecte, el que no necessitam és gent sinó bons programadors i aquí la cosa ja es complica.

El PHP és un llenguatge que té un nivell d'entrada molt baix. És molt fàcil començar a fer coses, d'aquí que molta gent amb pocs coneixements de programació comença amb PHP. A més posar una web en producció també és molt senzill. Un ftp i un accés a una base de dades és suficient per fer la major part de les webs. Això ens dóna una gran quantitat de programador PHP aficionat, fa aplicacions i surten, però no hi ha una metodologia darrera i sovint les aplicacions no són mantenibles.

Una primera conclusió doncs: és molt més senzill destriar els bons programadors Python que els bons programadors PHP. La feina és més senzilla. Si algú s'ha atracat a Python per programar ja significa que té inquietud per fer les coses bé. El nivell d'exigència inicial per a fer webs amb Python també és més alt, has d'aprendre un framework, saber configurar un servidor web optimitzat per a la teva aplicació, ... En definitiva, no te pots haver quedat amb els coneixements bàsics "per a que la cosa funcioni i prou", s'ha d'haver anat més enllà.

Està clar que en PHP també es pot programar bé. Llavors segurament el programador que entrevistarem ens dirà que coneix or fa feina amb un framework. Bé, això està bé. Però llavors ja hem perdut la hipòtesi inicial de que era més fàcil trobar programador amb PHP perquè a més el programador PHP ha de ser bo en PHP i bo amb el Framework i l'àmbit de cerca es redueix molt.

Fent feina amb un framework PHP també hem perdut un dels "avantatges" del PHP: la capacitat d'escriure codi ràpidament i posar-ho en producció. Quan poses un bastiment PHP les velocitats d'execució són ridícules si les comparam amb les de Python i Django. Eps, potser suficients pel que volem, però per res comparables. Però la velocitat d'execució no és el més important, el més important és la velocitat de desenvolupament, i posant un bastiment PHP també perdem això. Resulta ara que el PHP no és tan directe com pensàvem, ni hi ha tanta gent que el conegui com fèiem comptes.

Segona conclusió: Si volem fer servir un framework amb PHP per programar no tindrem tants programadors a on triar i perdem molt en velocitat d'execució.

Però és que a més el projecte és gran i s'ha de mantenir al llarg del temps. Què triam PHP o Python llavors? Si el projecte és gran no importa tant que el programadors coneguin el llenguatge, basta que n'hi hagi uns quants experts que pugin fer el mentoring i la formació i deixar que la gent es vagi fent amb el llenguatge. El que sí necessitam són bons programadors, gent que sàpiga programar bé i no tengui por d'aprendre coses noves.

En aquest cas Python també sortirà molt afavorit. Aquí ja estam parlat de comparar PHP+Framework PHP amb Pyton + Django. Python té una cosa sempre present: el codi ha de ser clar i mantenible, si no ho és no és pythonic. El PHP segueix una altra filosofia... Si hem de mantenir un projecte gran en el temps Python és una de les millor eleccions que es poden fer: és molt més difícil escriure codi il·legible i una vegada el programador s'ha impregnat de la filosofia que hi ha dins el llenguatge el codi surt sols. És divertit escriure i mantenir codi, perquè és fàcil llegir-lo. Pensem que quan es tracta de mantenir codi ens passarem molt més temps llegint el que altres han escrit que creant nou codi. Tenir un depurador a Python, poder fer unit tests amb facilitats (recordem que la llibreria de unit test forma part de la pròpia distribució de Python), tenir un servidor web integrat com a Django. Tot això fa que la feina de manteniment correctiu i evolutiu sigui més senzilla. La gent que heu/hem tingut que mantenir codi PHP i que ha pasasat a Python i Django segur que està fent capades d'assentiment.

Tercera conclusió: Python fa que el codi que s'ha de mantenir durant molt temps sigui molt més mantenible. Dedicarem menys temps a la depuració. Si ho complementam amb la política de Django d'estabilitat de versions la cosa ja és per nota.

Podem entrar també en les interioritats del llenguatge. Python és un llenguatge madur, amb llibreries molt ben establertes, ben documentat, ben pensat. PHP fins fa poc no tenia orientació a objectes i encara així escriure un objecte i utilitzar-ho amb PHP és força farragós si ho comparam amb Python. Tot a Python és un objecte. Però el que trob més important és la quantitat de codi que es necessita per fer la mateixa tasca. Per programes grans el codi Python és entre dues i 5 vegades més curt que el codi PHP. Això vol dir menys codi que depurar, menys codi que llegir. En definitiva codi més mantenible.

Però sobretot el més important de tot per mi és l'experiència que he tingut amb programadors de PHP que han passat a conèixer bé Python i Django. S'han divertit en el procés i es segueixen divertint programant amb Python. Per mi és un factor important, ja que un programador motivat crea millor i és un factor decisiu en l'èxit de qualsevo projecte. Així que aquí va la meva

Quarta conclusió: perquè Python és un llenguatge fotudament divertit per a programar o en la versió en anglès: It's a hell of a lot of fun to code again!

Per a més referències hi ha un article força extens que compara PHP i Python a la wiki de Python.

Aquest és un post de servei públic, una petita configuració al .bashrc que ens permet gestionar fàcilment el control de diferències partir de mercurial i subversion. L'he trobat al tips and tricks de mercurial i és prou senzill i útil:

hgdiff() {
    vimdiff -c 'map q :qa!<CR>' <(hg cat "$1") "$1";
}

svndiff() {
     vimdiff -c 'map q :qa!<CR>' <(svn cat "$1") "$1";
}

i per fer cerques trob molt útil

export GREP_OPTIONS="-R -i -n --exclude-dir=\.svn --color=auto"

També és útil recordar algunes comandes de vimdiff

do - Posa els canvis de l'altra finestra a la finestra on tenim el cursor
dp - Posa els canvis de la finestra on tenim el cursor a l'altra
]c - Va al següent canvi
[c - Va al canvi anterior
Ctrl W + Ctrl W - canvia de finestra
:diffupdate - diff update
:syntax off - syntax off
zo - obre el text plegat
zc - plega

En el meu cas ]c presenta conflictes amb algun plugin així que tocarà investigar quin o canviar el mapeig.

Aquesta setmana al grup de Django hi havia una interessant discussió damunt la idoneïtat de Django per una startup. Bàsicament la discussió girava entorn de la tecnologia, i de com si imposam una tecnologia al proveïdor aquest la posarà com a excusa si el projecte fracassa o no s'entrega a temps.

Per mi això vol dir una cosa: si hem d'encarregar quelcom a un proveïdor ens hem d'assegurar que farà el que toca. És a dir, si ja d'entrada et diu "nosaltres no feim feina amb la tecnologia xxx i ho faríem millor amb yyy" doncs la millor opció crec que és anar cap a un altre proveïdor.

Però el que m'ha agradat més ha estat una aportació que m'ha duit fins a un article de Kurt Grandis anomenat Python + Django vs. C# + ASP.NET: Productivity Showdown.

El vertaderament interessant de l'article de Grandis no és el resultat en sí. Demostra que a la seva empresa la productivitat del desenvolupament en Python i Django ha doblat la del desenvolupament en C# i ASP.NET, i és la demostració en sí el que fa interessant l'article.

No es tracta de que hagi llegit un white paper i ha vist la llum. Sinó que a partir del que coneix de la seva empresa ha posat en marxa un estudi sistemàtic per a provar si la seva hipòtesi de que l'augment de productivitat en Python era millor o no.

Salvant les distàncies, és més o manco el que ens va dur en els temps de TUI a canviar el desenvolupament des de Java+J2EE amb tot l' stack tecnològic de Tomcat, Spring, Hibernate i altres cap a Django i Python. Aleshores les necessitats de l'empresa eren la de poder crear aplicacions web en un temps molt curt, amb moltes adaptacions posteriors, aquest darrer requeriment per pròpia idiosincràsia del negoci.

Teníem les dades del que ens constava posar un projecte Java en producció en temps i esforç. Potser condicionat per la meva vessant de gairebé físic i m'agrada tenir dades experimentals o vet a saber per què, però m'agrada tenir constància de l'esforç que duen els projectes, així que vaig anar recopilant dades com temps, línies de codi, temps d'inici mínim d'un projecte, temps de desplegament, etc.

Els resultats a favor dels projectes fets en Python i Django eren aclaparadors. En el nostre cas l'equip de feina era igual de bo amb ambdues tecnologies. Així que poguérem comparar peres amb peres.

Vull dir amb això que l'elecció de la tecnologia i del llenguatge de desenvolupament és una cosa prou seriosa com per no fer-la a cop d'impuls. Convé mesurar i decidir en base als nostres propis estudis i conclusions. Que per nosaltres el factor de productivitat fos Python no vol dir que per una altra empresa ho sigui, potser pel tipus de desenvolupament que es fa els va millor fer feina amb Java, en PHP , ...

És important poder avaluar el projecte i l'empresa. Invertir temps i recursos en fer l'estudi. Avaluant productivitat, riscs i variables com el vendor lock, la motivació de l'equip i com no el retorn de la inversió.

Grandis ens conta com ho va fer ell i per això és un exemple tan valuós. Sovint ens trobam que darrera una decisió com la canviar de llenguatge de programació o tecnologia no hi ha res que la recolzi. Hem d'acostumar-nos a fer aquests tipus d'estudis si volem que la Informàtica comenci a tenir la consideració de es mereix.

La ponència va començar amb uns minuts de retard, la cortesia típica per a que la gent acabi d'arribar, minuts abans en Joan Barceló em va presentar a José Barato, d'Atos Consulting i férem un cafè, descafeinat, això sí, que els moments abans de parlar ja duc una bona embranzida com per apujar-la més amb la cafeïna.

A la sala poc menys de 60 persones. Algunes cares conegudes: Suki, JoanMi, Pau, Joan Carbonell, ... Potser hi ha més gent que conec, però en Joan Barceló ja m'està presentant i no tinc temps de fixar-m'hi massa. Paraules afalagadores de Joan, no sé si les meresc, però encara així són benvingudes.

He previst una exposició d'uns trenta minuts, més o manco a minut per transparència. Una altra vegada em record a mi mateix que he de trobar alguna mena de plugin o utilitat per a poder posar un crono a la pantalla que em vagi marcant el temps. Amb el mòbil al costat ja va bé per nar mirant l'hora de tant en tant i ara per ara això ha de bastar.

Vaig parlant un poc de filosofia de la gestió de projectes, de la importància de l'equip i de com les eines de codi obert ens poden acompanyar en tot el camí de la gestió de projectes. Sóc molt insistent en que l'eina no és l'important, que no és un fi en sí mateix, sinó que l'important és el projecte i la gent que l'ha de dur a terme.

Passa el temps i acab amb la presentació, en Suki veig que ha tuitejat l'inici i el final. Per això veig que he estat gairebé 37 minuts parlant. Se m'ha fet curt. M'encanta parlar d'aquests temes. Crec que fer pedagogia i ser insistent és la única via per a començar a canviar les coses. Que hi hagi una seixentena de persones a la sala, alguns amb resposabilitats de gestió de projectes potser ajudarà a que la gestió de projectes de programari canvii cap a una gestió on es dóni la importància a l'equip en el seu conjunt i es tengui en compte que el desenvolupament de programari no és com el que fa hamburgueses (m'agrada l'exemple de José Barato).

Després en Joan Barceló ens parla de OpenPPM, eina de gestió de carteres de projectes desenvolupada en codi obert i que està propera al seu alliberament. Ens parla de les eines utilitzades. Veig alguns comentaris en referència a la corbata i a que surt Word, Excel i Microsoft Project com a vies per donar-li de menjar a la bèstia. D'aquí dos temes a dir, per una part el tema de dur corbata o no, és quelcom personal, a mi no m'agrada, però tampoc m'agraden massa els vaqueros. Crec que la vestimenta no ha de condicionar la importància de les paraules i de les idees, encara que sóc conscient que sovint ho fa. De la utilització de formats tancats com a via d'entrada sí que crec que condiciona la llibertat del projecte, però en soc optimista. Fa un grapat d'anys tenir empreses com SM2 o Atos involucrades en un projecte lliure i parlant-ne obertament a unes ponències fora impensable. Està clar que encara hi ha coses a millorar, però el que no podem fer és voler-ho tenir tot de cop, s'ha d'anar fent camí. S'ha de reconèixer el que s'ha fet, l'esforç i la iniciativa i animar a seguir polint els detallets que queden per a poder considerar el producte vertaderament lliure.

La darrera conferència va ser la de José Barato, d'Atos Consulting. Pareix que José i jo hem llegit els mateixos tipus de llibres, ja que tant De Marco com Yourdon a DeathMarch formen part de les meves referències obligades. Jose va desgranar els principals conceptes que exposa De Marco i va explicar algunes anècdotes personals de Death March. Una de les anècdotes em va fer por: programadors coaccionats per fer feina sense anar a casa, dormint a la oficina. Segur que José Barato ja no ho fa això i n'ha après la lliçó, però segur que encara hi ha consultores que no han fet el canvi i aquests tipus de pràctiques poden ser fins i tot normals.

El cap de projecte té una obligació vers el projecte: la obligació de mirar de dur-lo endavant, però també té una obligació vers l'equip, la de no vendre'ls la moto. Embarcar un equip a una missió impossible sense el seu consentiment o dur-los més enllà del que humanament és possible fa malbé l'equip i el projecte.

En resum, unes xerrades entretingudes. Jo m'ho vaig passar molt bé i esper que la gent que hi va venir també trobàs coses interessants de la xerrada.

Gràcies a Suki per les fotografies.

El divendres vinent particip en la xerrada El lado humano del software, encara estic acabant de perfilar la xerrada, però com diu el títol parlaré de la gestió de projectes fent servir programari obert.

Tanmateix m'agrada el títol de la xerrada, ja que no vull parlar de com fer servir un o altre programa, sinó anar indicar quins problemes ens trobam en la gestió de projectes de programari i com hi ha programes de codi obert que resolen el problema, i ho fan des d'una vessant orientada a les persones i al grup de desenvolupament.

Pensant en la xerrada sorgeix un altre tema, què és el que fa un cap de projecte sigui un cap de projecte? La gent del PMIB vol anar cap a la professionalització d'aquesta activitat, però sé cert que molts ens conformaríem amb que l'accés a cap de projecte no fos una manera de cobrar més i deixar de programar, sinó una activitat on la gent que hi accedesqui en tengui vocació i formació.

No hi ha res dolent en que una persona que programa vulgui ser cap de projecte, particularment trob que un cap de projecte que ha estat un bon programador pot entendre millor les necessitats que té un equip de desenvolupament i connectar millor amb l'equip i el client. El que no m'agrada és que la gent que és bona programant i que ho vol seguir fent, si vol mantenir un nivell de sou tengui que anar cap a la direcció de projectes si no li agrada.

S'ha de valorar la feina de cap de projecte i s'ha de valorar la feina d'un bon programador, d'un bon tècnic de sistemes, ... La feina de cap de projecte no pot ser un objectiu per cobrar més, sinó una elecció raonada i no motivada sols per l'aspecte econòmic del lloc de feina.

El món està ple de caps de projectes de software de Microsoft Project i fulla de càlcul a una unitat compartida de Windows que han accedit a ser-ho perquè no els ha agradat mai programar (dubt si mai els ha agradat la feina informàtica) i no volen aprendre res nou. Crec que és això el que s'ha d'evitar, potser professionalitzant més l'ofici n'és una via, però un punt important és el d'anar fent pedagogia a les empreses de que no hi ha res dolent el pagar més a un bon programador o per un bon dba que a un mal cap de projecte.

He actualitzat la meva configuració de .vimrc i els pluggins i ressaltat de sintaxi que hi ha a .vim

• El subversion: http://code.google.com/p/appfusedjango/source/browse/#svn/trunk/myvim
• El .vimrc
• El .vim

Novetats

• Substitució de snipEmu per snipmate. SnipMate fa si fa o no fa el mateix però té una sintaxi més senzilla i clara i permet fer nous snippets molt més fàcilment.
• He afegit un nou ressaltat de sintaxi per json.
• El colors per defecte per gvim passa a ser ara wombat i he canvait el tipus de lletra a DejaVu Sans Mono, ja que té una bona distinció entre la vocal O i el zero, entre l'u i la i, bastant millor per programar.
• Activació per defecte dels menús i de la toolbar a gvim
• Neteja de la configuració a .vimrc
• Pos els alias a un fitxer apart dins ~/.vim/abbr, feu alias per veure el que hi ha.
• Integració de més codi de pycopia especialment dels snippets per Django.

A poc a poc però sense pausa estic embarcat en la creació d'un motor de reserves orientat cap a hotels i cadenes hoteleres. És a dir, no es tracta de fer un sistema genèric orientat a la integració d'xml com els que poden necessitar agències i TTOO, sinó de tenir quelcom flexible i ràpid de personalitzar orientat a cobrir les necessitats més o manco complexes de la venda directa on line de nits d'hotel.

És a dir, el sistema ha de cobrir el bàsic (gestió del nombre d'habitacions disponibles, tarifes, descomptes per ocupació, aturada de vendes, etc) però també ha de permetre cobrir necessitat que en aquests moments no coneixem. Per tant, tenir una bona bateria de tests que ens assegurin que afegint noves característiques no ens estam carregant les que ja hi ha és fonamental.

La idea del Test Driven Development és que s'han d'escriure els tests abans d'escriure el codi. Jo no sóc tan purista i els tests els escric quan els necessit, unes vegades abans i unes vegades després d'escriure el codi. La raó és molt senzilla, quan estic immers en l'escriptura de codi per a que passi un test, sovint me trob afegint noves característiques per les que no tenc cap test encara. Llavors crec que el millor és seguir a la zona de programació pura i dura i després escriure els tests. Crec que no és tan important el moment en el que s'escriuen els tests unitaris com el fet de tenir-los.

Un motor de reserves com el que descric es pot fer en qualsevol llenguatge, en el meu cas hem triat fer-ho amb Python i amb Django, ja que ens dóna molta flexibilitat posterior a l'hora de fer adaptacions, que és el que cercam. Així doncs la definició del model de dades i l'ORM que s'utilitza és el de Django, la qual cosa fa que sigui important poder testejar-ho amb les eines que ens proporciona aquest bastiment.

Llegint la documentació de Django podem veure que aquest fa servir els units test de tota la vida i que a més per a que els tests siguin realment unitaris el que fa es utilitzar una base de dades nova i neta cada vegada que executam un test, d'aquesta manera ens asseguram que no hi ha dependències entre diferents execucions de casos de prova i per tant que els tests són realment unitaris respecte a les dades.

Tot i que sigui una solució totalment vàlida, consider que eines com nose fan l'escriptura de tests unitaris una tasca molt més divertida, ja que no has de passar pena de com estructura els test, sinó simplement els has d'escriure amb unes convencions de codi (per exemple els tests han de començar o contenir la paraula test). Per mi això significa menys complicacions i poder reaprofitar petits troços de codi que tanmateix hauria necessitat escriure per provar l'aplicació sense tenir que donar-los el formalisme que necessita un unit test. L'ideal per mi és tenir nose integrat dins el sistema de test de Django.

Afortunadament més gent ha tingut aquesta idea i per sort per mi, gent amb un coneixement més profund que jo de nose a nivell intern com per fer-ne una adaptació per Django, us present el django-nose. És una aplicació que s'instal·la amb pip o easy_install i que necessita molt poca configuració, afegirem 'django_nose' al settings.py a la secció INSTALLED_APPS i afegirem TEST_RUNNER = 'django_nose.run_tests' per dir-li a Django que farem servir el nostre motor de tests enlloc dels seus.

La gràcia d'aquest mòdul i de nose és que és compatible amb el que ja hi havia, però a més afegeix molta més funcionalitat i agilitat a l'hora de crear els tests. Basta fer un python manage.py test --help per adonar-nos de tota la quantitat d'opcions que ens afegeix el mòdul a l'hora de testejar. D'aquestes m'agradaria destacar-ne algunes:

• --with-coverage Ens permet utilitzar la utilitat de coverage de Ned Batchelder que ens permetrà veure quines línies de codi no hem testejat encara. Amb opcions addicionals és capaç de generar-nos un html navegable per a que poguem veure exactament el context de les línies testejades i de les que queden sense provar.

• --processes Ens permet aprofitar els nuclis del nostre ordinador, els tests s'executen en paral·lel (recordau que els tests unitaris no han de tenir dependències entre ells) accelerant notablement el temps de procés.

• --with-xunit Fa que en lloc de tenir la sortida típica dels unit tests tenguen el format de xunit, el mateix que es fa servir als unit test de Java, per exemple, i que ens permetrà integrar els nostres unit tests amb eines d'integració contínua com Hudson.

A l'hora de testejar una aplicació com el motor de reserves és imprescindible partir de dades conegudes i controlades per poder determinar els resultats esperats. Per això la manera que té Django de carregar les dades és simple i elegant. A cada unit test i abans de l'execució de cada cas de prova es crea la base de dades (en el meu cas un sqlite3 en memòria) i es carreguen les dades inicials (o fixtures en la nomenclatura) que es defineixen a cada unit test. Els fitxtures no són més que arxius en format json, yaml o xml que representen els registres que hi ha d'haver dins la base de dades.

Per exemple: [{"pk": 1, "model": "sites.site", "fields": {"domain": "example.com", "name": "example.com"}} ]

Aquests arixus els podem crear nosaltres directament amb un editor com vim o bé aprofitar-nos de l'entorns de Django i crear-los a partir de l'admin. Així podem introduir les dades a la nostra base de dades i fer un

 ./manage.py dumpdata applicacio.model

per exemple:

 ./manage.py dumpdata sites.Site --indent=4

ens proporcionarà el codi json per al model Site, l'indent el que fa es proporcionar espaiat addicional per a que sigui més bo de llegir i de modificar.

Si ens va millor tractar amb yaml, és prou senzill canviar el format:

 python manage.py dumpdata sites.Site --format=yaml --indent=4

-   fields: {domain: example.com, name: example.com}
    model: sites.site
    pk: 1

Dins un mateix unit test podem carregar tants arixus de fixtures com vulguem, ja que basta definir una llista del que s'ha de carregar, això vol dir no tenir que tractar amb grans arixus de dades de proves, sinó poder-los fer molt més manejables i sobretot reaprofitables.

La combinació de fixtures, unit test de Python, eines de testeix de Django i nose és molt difícil de batre. Per una part tenim que escriure tests amb Python costa una fracció del temps i de codi respecte a escriure'ls en un altre llenguatge, però a més nose fa que la tasca sigui molt més natural i la capacitat de generar els fitxtures des del mananager de Django fa que una tasca avorrida es convertesqui en trivial.

Tenir una bona bateria de test és fonamental per provar l'aplicació, per demostrar que els casos que s'estan considerant funcionen i tenen les sortides que deim que han de tenir. Però la utilitat dels tests unitaris va més enllà. Són una eina imprescindible en la refactorització.

Una vegada l'aplicació ja fa el que volem arriba l'hora de plantejar-se si es pot fer millor, si l'aplicació pot ser més eficient, de refer el codi per a evitar repeticions. La regla fonamental de la refactorització és que no hem d'introduir funcionalitat nova, quan refactoritzam tot ha de funcionar com abans. Els tests unitaris ens ajuden a demostrar que la nostra refactorització és bona, en tant en quant passin exactament els mateixos tets que teníem abans de fer cap modificació.

Faceu Test Driven Development o agafeu una aproximació més pragmàtica, el cert és que tenir bons unit tests és una inversió de futur que costa sols un poc més de temps quan estam desenvolupant, ja que amb nose els tests es poden reaprofitar de les petites rutines per proves que tanmateix hauríem d'escriure. Els beneficis el veurem a mig i llarg plaç: quan refactoritzem, quan canviem codi, quan les proves les llanci un sistema d'integració contínua. És massa bo per a no fer-ho servir.