A més de llegir el llibre de Gabriel Ginebra als vespres, aquests darrers dies han estat prou interessant. Tant que m'agradaria compartir amb la gent que llegeix aquest blog un parell d'històries i reflexions que m'han passat aquests darrers dies. El títol del l'apunt potser no és del tot exacte, però no sé com anomenar aquest calaix de sastre. És en aquests casos on es veu perfectament el concepte de blog personal :)

Feina comercial

La primera història entronca en el que és el funcionament diari de l'empresa. Un client de Madrid ens demana un pressupost per a una aplicació web. És un empresa gran i vol que hi anem a presentar-nos. Té bones referències nostres però ens vol conèixer personalment.

No hi tenc cap problema amb que un client ens vulgui conèixer, la nostra oficina està sempre oberta i la cafetera engegada. Però vol que anem a Madrid en pocs dies de marge. Es pot arreglar, li dic, però ens haurà d'enviar els bitllets.

Això deixà el client descol·locat. Diu que això no ho fan, que són els possibles proveïdors que es paguen el viatge per anar a veure'ls. Li explicam que nosaltres no funcionam així i al final la reunió es fa per videoconferència.

Sé que això és una pràctica habitual, però el que em sorprèn és que alguna gent no sia conscient de que al final el que estarà pagant en el seu projecte no serà sols el cost de desenvolupament i direcció de projecte, sinó també el cost dels comercials engominats que l'aniran a veure. I el que és pitjor, estarà pagant el cos no seu, sinó el cost proporcional de totes aquestes visites comercials que s'han fet, s'han pagat i que no han resultat en una feina. En poques paraules, estaran pagant molt més doblers per a un desenvolupament sols per fet que a algú li agradi sentir-se afalagat o important.

Sé que la feina comercial és important, però la nostra màxima ha estat sempre mantenir un nivell de despesa supèrflua mínima i per tant no carregar els pressuposts amb la despesa extra que suposa tenir una munió de comercials l'objectiu del qual no és més que fer la pilota als possibles clientes i que moltes vegades no saben el que venen.

Curiosament pareix que el potencial client, que normalment no pagarà la feina amb els seus propis doblers, necessita d'aquesta cerimònia, no essent conscient de que tot això ha de sortir forçosament dels projectes que farà l'empresa que està avaluant.

Potser també som atípics amb aquest aspecte, però em resisteixo a aquestes coses i trob que si la relació comercial ha de ser duradora aquesta no es pot basar en "te faig la pilota i així em compraràs". Si jo he de perdre tot un dia per anar a veure't al manco hem de compartir despeses, ja que per mi no és just haver de carregar aquests costs damunt els projectes d'un altre client.

De la mateix manera quan un pressupost veig que ha de dur dies de feina i a vegades setmanes o mesos, no ens podem deixar enlluernar pel possible guany futur. Si un vol un pressupost anàlisi d'aquesta mena l'ha de pagar, de la mateixa manera que paga els plànols d'un arquitecte. En cas contrari estaríem novament carregant molts costs contra els projectes que sí es fan.

Òbviament a l'hora de calcular el cost per hora que s'ha de carregar per la feina s'ha de tenir en compte que sempre hi haurà un cost comercial, com hi ha un cost per la gestió de l'empresa o el cost associat per la direcció. Però per ser justs crec que tot allò que ultrapassi el que és raonable s'ho hauria de pagar el que ho demana.

Segur amb aquesta mentalitat no arribarem mai a tenir un Ferrari a la porta, però segur què hi farem...!

Festa d'Habitissimo

El divendres vaig anar a la festa d'Habitissimo. M'agrada veure com un equip de gent com aquest creix i li van bé les coses. Ja fan quatre anys i han pogut créixer a un ritme fantàstic, i a la mateixa vegada mantenir l'esperit viu, inquiet i innovador no és fàcil i aquesta gent ho està aconseguint. Estic molt content per ells i sempre és un plaer poder converçar amb Jordi i Martin. A més la festa va servir per poder saludar a amics com Hugo o Suki. Amb Suki un poc més i feim les tantes cotorrejant.

Empreses com Habitissimo per mi sí que representen el que hauria de ser una empresa en el Parc Bit. Supòs que no és tan cool com fer-se una foto davant el logo de Microsoft pels polítics, però sí que us puc assegurar que estan fent molt més pel teixit empresarial de la nostra illa que els altres. Potser si algun dia ens n'adonam tots d'això es podrà invertir realment en el que dona feina i és una alternativa real al monocultiu turístic.

Antibes

La gent d'ACREW va organitzar un event a Antibes d'allò més sonat, i ja sabeu com va això. S'han de crear noves planes per l'ocasió, mirar de tenir noves característiques llests, i fins i tot un canvi d'imatge i de tot el procés de registre.

Van ser dies intensos de programació, però el resultat s'ho paga. Molt bona acollida de l'aplicació, molts usuaris nous i una startup que creix. No sé si arribarà als nivells d'Habitissimo, però la veritat és que per l'esforç que hi està posant la gent d'ACREW s'ho mereixen.

La resta és més o manco el dia a dia. Pareix que ens estam especialitzant en donar suport a emprenedors, tant gent que vol montar el seu negoci per primera vegada com empreses que volen donar el pas cap a Internet, i això m'agrada molt. És un tipus de client fantàstic i s'estableix una relació de complicitat molt bona.

No ho sé, a vegades tenc la sensació que podríem guanyar més organitzant-nos com a una empresa clàssica de desenvolupament, amb comercials engominats especialitzats en vendre vehicles de dues rodes, però segur que no ens ho passaríem tant bé.

Un dels lemes que més m'agraden de Python, el llenguatge que hem triat per al desenvolupament es "Life is short, use Python", per què no aplicar-ho també a la feina diària?

Aquests començament d'any ha resultat ser força més mogut del que m'esperava. Mogut en el sentit positiu: pareix que hi ha força projectes grans en marxa i bones perspectives. La gent es va animant i demana pressuposts, que ja veurem si després sortiran o no, però davant l'apatia del 2012, és un bon senyal. Potser ja ens hem acostumat a viure en un estat de crisi perpètua.

De totes maneres el 2013 es presenta complicat, la pujada d'IVA dels darrers mesos fa que cada factura impagada sigui un risc. Si el 16% ja ho era, ja no us dic res del 21% i si la quantitat és gran te pot deixar ben fumut. Si això ho sumam que ara reclamar factures per via judicial sortirà molt car, doncs ja tenim la combinació perfecte per a que petites empreses i autònoms estiguem amb l'ai al cor cada vegada que començam un projecte.

Aquest començament d'any té un altre efecte: fa un bon grapat de setmanes que no em puc dedicar a temps complet a programar. Fer pressuposts amb cara i ulls requereix temps i dedicació que no pots compartir amb la concentració que representa programar. En programar tens les mans en un problema actual, en resoldre una feina, quan fas un pressupost tens la ment posada en el futur, en possibilitats i estadístiques. Pens que és un estat mental diferent i és complicat passar d'un estat a un altre, sumat ja a la complicació inherent a estar "en la zona" quan programes.

La veritat és que m'agrada molt programar i en part és per aquesta sensació de concentració i pau mental que tens quan programes. Fer un pressuposts o gestionar projectes també m'apassiona (sóc així de raret) però el cuquet hi és.

Hi ha gent que quan l'empresa ja va bé, es compren un cap administratiu, per a que gestioni l'empresa i ells poder-se dedicar a programar. Nosaltres no hem crescut tant, però de tant en tant pens que seria prou divertit això, però tanmateix pens que com a empresa tecnològica, la responsabilitat de fer els pressuposts no es pot deixar en mans de personal administratiu sense coneixements del que està fent, així que ara per ara me pareix que hauré d'intentar combinar els dos capells.

Potser el que sí hauria de fer és anar trobant nous talents que es puguin incorporar al grup. Els set integrants d'APSL formam un equip del que puc presumir, no tan sols per la feina que fem, sinó per la manera d'entendre l'empresa i el treball informàtic. S'assumeixen els riscs i les alegries de la feina. Vivim en un estat d'startup permanent, però sense les rondes de finançament, i això fa que mai poguem caure en la monotonia i l'avorriment. Vaja, que ens ho passam bé!

Pau, una de les nostres darreres incorporacions al grup, deia que el seu entorn el mirava estranyat perquè cada dia va a fer feina content. És l'esperit que s'ha d'aconseguir en una feina com la nostra. Que acabis la feina d'un dia amb ganes de tornar-hi al dia següent. Hi haurà dies bons i dolents, però el més important és llevar-se amb la il·lusió i les ganes. Amb això la feina hi fa molt, però també l'esperit de la persona.

Aquest mes de març començaré el cinquè any de l'aventura d'APSL, estic fent el que m'agrada, passant pena, fent feina dia a dia, intentant guanyar-me la vida fent el que m'agrada, tot i l'entorn poc favorable a les petites empreses com la nostra i als autònoms en general. Mostrant que les coses es poden fer d'una altra manera, que es pot viure programant amb programari lliure i amb l'ètica del programari lliur, que es pot fer feina treballant amb Python i Django, i que la suma del grup és major que la suma de les parts.

Veurem com va el 2013. També he de fer un pensament, i és contar un poc més coses de Python i Django, que darrerament hi ha força coses interessants: una PyconES que es prepara, el nou Django 1.5, llibreries i utilitats, ... Ens anam llegint! Esper que per vosaltres que em llegiu el 2013 sia també un any digne de viure's.

Ja som a un punt on hem decidit que hem de fer el pressupost, l'hem fet i hem fet les nostres primeres estimacions.

L'estimació del pressupost ens haurà donat un nombre, el significat del qual dependrà de la metodologia d'estimació utilitzada, però que finalment haurem de convertir en hores-home i aquestes hores home en una quantitat monetària.

Podria parèixer que amb això s'acaba tot, però si ens aturam aquí ens trobarem que les nostres estimacions estan força lluny de la realitat.

A més de la feina bàsica de programació s'han de tenir en compta tot una conjunt de factors que afecten a l'hora d'entregar el pressupost final, tant en temps com en doblers.

El temps mínim i el temps òptim

Tots coneixeu l'acudit que encara que una dona pugui donar a llum un nadó en nou mesos, nou dones no el fan en un mes. En tot projecte informàtic hi ha un temps mínim d'entrega, que depèn tant de l'equip de desenvolupament, com del propi client o de qui ha d'anar resolent dubtes i subministrament continguts.

El temps mínim sovint coincideix amb el cost màxim. Vull dir, per assolir aquest temps mínim l'equip ha de ser més gran (fins a un màxim) i això implica més tasques de coordinació i una menor optimització de recursos. La velocitat de desenvolupament no és proporcional el nombre de programadors, sinó que arriba un moment que per mols programadors que posem el projecte no avança més ràpid, sinó que fins i tot pot endarrerir-se.

Així doncs en el nostre projecte hem d'establir quin és el temps mínim que podem tenir, amb el nombre de programadors màxim i el temps òptim en costs, que és aquell que permet entregar el projecte més tard, però amb un cost de programació menor.

A partir d'aquestes dues escales hem de saber quines són les necessitats del client i si encaixen en els temps prevists. El pressupost, per tant es veu afectat també pel requeriment d'entrega.

La direcció del projecte

En un projecte gran m'agrada fer visible la feina de direcció i de coordinació del projecte, i encara que potser sigui poc comercial posar una quantitat per la direcció de projecte trob que hi ha de ser. D'aquesta manera tothom és conscient que al llarg de la vida del projecte hi ha d'haver reunions internes i reunions amb el client, i que aquestes estan contemplades dins la tasca com a una activitat més.

En projectes petits aquesta tasca pot significar un 10% del total del projecte, en projectes més grans pot arribar perfectament a un 25%. Així que no considerar aquest factor ens pot dur a una desviació del pressupost molt difícil de superar.

El nombre final que s'ha de considerar dins la direcció del projecte també té molt a veure amb l'estabilitat dels requeriments. Si el projecte té unes fites molt clares, les necessitats de reunions per anar aclarint els punts són molt més curtes i profitoses que en les de projectes on les fites són més difuses.

Altres costs associats al projecte

A més dels costs que tenim en feina de programació hem de pensar que a més tenim tota una sèrie de costs que s'han de repercutir d'una manera o altra en el projecte. Sovint aquests costs ja es consideren dins el preu-hora aplicat a l'hora de donar l'import final, però hi ha projectes que tenen els seus propis costs que s'han d'avaluar.

Dins els costs normal tenim:

• Cost de local: lloguer, llum, telèfon, Internet, assegurances.
• Material d'oficina
• Amortització de l'equip informàtic
• Despeses de gestoria i administració
• Despeses financeres

La majoria podem considerar-les com a despeses fixes i posar-les dins el cost-hora, però hi ha casos en que el projecte es molt gran i per exemple el tema de les despeses financeres pot ser molt important. És una de les raons del perquè els projectes públics solen costar molt més: el proveïdor ha de tenir en compte que haurà de fer front a moltes despeses que sols cobrarà al cap d'anys (si hi ha sort), això genera una despesa financera que s'ha d'avaluar i imputar al projecte.

Suposem que tenim un projecte que requereix que agafem més gent. Dins aquests projecte s'ha de considerar també la despesa que representa la selecció de personal, l'amortització del nou equip que necessitarà i el període de formació.

Quan més gran és el projecte més coses hem de tenir en compte si volem donar una aproximació en costs i temps el més acurada possible. Mirar al futur és complicat, cert, i pensau sempre que sols és una aproximació.

Abans d'entrar en matèria i fer càlculs hi ha un requisit previ, que és saber què és pot pressupostar i que no. I com diu Jordi a un comentari de l'apunt anterior, sovint convé saber primer si convé fins i tot dedicar temps a fer el pressupost.

De vegades m'he trobat amb gent que demana un pressupost d'un projecte sense tenir-ne clar l'abast o ben bé què demana. Tanmateix podria estar demanant què li costaria posar en òrbita un satèl·lit, amb la diferència que per això, com que ja s'ha fet es pot tenir una idea.

Sovint, i més en entorns d'emprenedoria i noves idees, se'ns demana que pressupostem un programa que no s'ha fet mai, del qual no se'n tenen referències, o l'abast del qual és tan gran que el pressupost sol necessita un pressupost.

Fa poc vaig tenir que dir a una persona que no li podia fer un pressupost. La seva llista de requeriments era un gràfic, no podia contar massa més, no sigui cosa que li pentinàs la idea (sic!) però que necessitava un pressupost el més acurat possible, encara que admetia que després hi podria haver un % de variació.

Què fas en un cas així? Doncs jo dir que no, que això no es pot pressupostar i que o hi ha més informació no no es pot fer res.

Així doncs, a l'hora de fer un pressupost el que necessitam és una informació el més acurada possible del projecte i del seu abast. Si el client no té clar que s'ha de fer, també ha de tenir clar que el pressupost sols pot ser una declaració d'intencions. No passa res, és perfectament assumible fer un pressupost orientatiu si el client té clar que la realitat pot diferir molt del que s'ha dit. L'experiència, però, és que el pressupost fixa un preu en la ment del qui el demana i si després el projecte es desvia molt hi ha problemes. El millor per mi és tenir al manco un mínim d'informació, si no es té, enlloc de tirar-se a la piscina, consider que és més ètic rebutjar fer el pressupost, ja que no hi ha cap garantia que tingui un mínim de fiabilitat.

Com pressupostar un projecte que no s'ha fet mai.

Suposem ara que ja tenim prou informació. Seguim amb el problema bàsic, que és que hem de pressupostar una cosa que no s'ha fet mai, que potser nosaltres no hem fet mai o bé que la tecnologia és tan nova que no hi ha cap referència o guia per la qual guiar-se.

Aquí la pregunta a fer-se és, qui assumeix el cost de la desviació si hi és? És una bona pregunta, veritat? Això condiciona el pressupost i el projecte. En projectes novetosos crec que no és el desenvolupador qui ha d'assumir aquests costs, ja que s'està posant sobre l'esquena del desenvolupador una responsabilitat que no li correspon, per tal de complir un pressupost o uns plaços que no tenen cap base.

Això no vol dir que no es pugui pressupostar, però com deia, s'ha de tenir molt clar que el pressupost és una referència i no un nombre tancat. Com a referència servirà per a que el client pugui fer-se una idea inicial de l'abast del projecte, però per ser justs el pressupost hauria d'anar a hores i/o fites. De manera que el risc tant del client com del programador es minimitzi. Del client perquè pot anar avaluant l'avanç del projecte i veure que paga conforme veu resultats. Pel programador o per que l'ha de pressupostar, perquè no es veu en l'obligació de tenir que fer una estimació a l'alça per tal de no agafar-se els dits.

Dit això, l'estimació que m'agrada és aquella en la qual hi ha alguna cosa que es pugui comptar. Vull dir, enlloc d'aixecar un dit a l'aire i dir "costarà tant", millor si ens aturam una estona i pensam com podem obtenir alguna cosa quantificable del projecte que ens permeti avaluar-lo, classificar-lo i extreure'n una primera estimació.

Si el client duu el disseny podem basar-nos en les pantalles, en el nombre d'interaccions, amb el nombre de casos d'ús, en el nombre de taules, en el nombre de missatges a mapejar. Sigui com sigui això ens ha de poder donar una idea de la complexitat del projecte i evitar donar una xifra basada en la nostra apreciació de si es fàcil, difícil o de l'estat d'ànim que tinguem aquell dia. Si es pot basar un pressupost en una mesura s'ha de fer, encara que ens dugui més temps, si no es pot basar en res, ens hem de plantejar si es tracta d'un pressupost d'aquells que convé no fer o bé si convé cobrar per fer l'anàlisi previ del projecte i a partir d'aquí tenir el pressupost.

Pressupostar feines semblants

La programació a mida té una cosa que la fa interessant que és que sempre hi ha variacions. Tot i això sovint ens podem trobar amb projectes que s'assemblen molt a projectes que ja hem realitzat.

En aquest cas ja tindrem dues vies d'estimació. Per una banda els càlculs que puguem fer i per altra la història del projecte semblant. De les dues coses segurament sortirà un pressupost molt més acurat que si sols ho fem d'una.

Si sols agafam com a referència el projecte anterior ens trobarem que no hem tingut en compte les variacions que potser no són tan mínimes com pensàvem,

Com deia abans el pressupost no ha de significar forçosament tancar tots i cada un dels detalls, però si el client que et demana un pressupost ho fa pensant que té un pla de negoci, que ha de saber de què ha de morir i per tant tampoc ho fa per caprici. Si optam per fer el pressupost pens que s'ha de fer de manera que la xifra que donem sia el més raonable possible.

Si no podem fer un pressupost explicar-ho, i explicar que es pot anar a hores fins que es pugui tenir una idea més clara de la feina que s'ha de fer i donar una estimació final.

Qui ha de fer el pressupost?

En altres contrades que fa un pressupost sol ser el comercial. Si anau a comprar un cotxe el pressupost us el farà el mateix comercial, en altres productes tangibles també. En la part de programari a mida, la cosa no està tan clara i sovint serà necessari i convenient que sia algú més proper a la feina qui pugui fer el pressupost.

Personalment crec que si es pot han de ser sempre la mateixa persona o el mateix grup de persones que facin els pressuposts. Per una banda es va guanyant experiència, però sobretot permet a cada un anar coneixent les desviacions que fa i anar compensant-les.

Quan és sempre la mateixa gent que fa un pressupost poden pensar que es seguiran sempre criteris semblants i això evita sorpreses a la llarga. En un món ideal tindríem més d'una persona fent un mateix pressupost i podríem discutir el perquè i arribar després a un pressupost consensuat. En projectes mitjans (que poden ser grans en una escala PIME), els recursos són limitats i per això l'especialització en fer pressuposts trob que és necessària i convenient.

Ens queden els càlculs

Molt bé ja tenim els primers càlculs fets, ara ja tenim una petita idea de per on van els tirs. Perfecte, doncs ara ens queda adaptar aquestes xifres a la nostra realitat.

Si no us he avorrit molt miraré de parlar-ne al proper apunt.

Fa un dies em va arribar aquesta impressora multifunció, la Laserjet Pro CM 1415fnw color mfp. La impressora ve a substituir una Laserjet 4050 ja entrada en any que s'ha quedat fora tòner i a una Epson 650 R que té la mala costum de quedar-se fora tinta, no per ús sinó perquè amb el poc us que li don s'eixuga.

Així amb el canvi vaig aprofitar per renovar-ho tot i passar a tenir una làser que esper que em surti tan bona com l'anterior, que ja va ser de segona mà.

Pels qui us trobeu amb la meva mateixa situació us faig cinc cèntims de com va la impressora amb Linux, en el benentès que el fax no l'he fet servir, ni crec que el faci servir.

La impressora es subministra amb tinta per a 700 fulls, be perfectament embalada i és feixuga, una trentena de quilos. Lletja com ella tota sola, molt a l'estil del que ens té acostumat HP amb les multifuncions.

La connectivitat és un dels seus punts forts, pots configurar-la per anar amb xarxa cablejada, wifi o per usb. La pantalla d'administració és un LCD que et permet configurar des de la IP de la màquina o un munt de paràmetres i una vegada configurada per xarxa pots accedir a un panell de configuració per xarxa que et permet configurar la màquina des d'un navegador. Realment molt pràctic i ben aconseguit.

És una màquina que requereix d'uns drivers del fabricant per a funcionar que podeu trobar a http://hplipopensource.com. Això instal·la una aplicació que permet controlar la impressora i a més permet l'escaneig per xarxa.

Sí, heu sentit bé, el mite de l'escaneig per xarxa és possible amb aquesta impressora és possible. Ho he provat a la versió 12.04 d'Ubuntu, a la 10.04 i també a Linux Mint 13. A aquest darrer es va resistir fins fa poc, supòs que alguna actualització ho ha solucionat o potser en un reinici de la màquina, però el cert és que ha passat de no funcionar l'escaner a Linux Mint a fer-ho ben igual que ho fa a l'Ubuntu. A Ubuntu cap de les dues versions, fins i tot la més antiga ha donat problemes, va funcionar tot des del principi.

L'escaneig remot funciona tant per a fulles directes com des de l'alimentador i pràcticament no necessita temps per a començar. Acostumat a la Epson això és una meravella i poder tenir l'impressora a l'altra punta del despatx i encara així no tenir que anar amb un usb per escanejar fa molta patxoca.

Per cert, que si voleu aquesta màquina imprimeix directament des d'un usb o pot escanejar i deixar-ho a l'usb sense problemes.

A l'aspecte negatiu, sense comptar el disseny, dir que encara que hi ha actualitzacions d'aplicacions d'HP, per aquesta impressora no n'hi ha cap que et permeti enviar directament el resultat de l'escaneig a un disc virtual tipus dropbox o enviar-ho per e-mail. És veritat que amb l'opció d'escanejar per xarxa això no és tan crític, però què voleu, em feia ganes quan ho vaig veure sols per a descobrir que aquesta impressora no era compatible amb aquesta funcionalitat.

El "market" d'HP deixa molt que desitjar, és una bona idea això de poder augmentar la funcionalitat de l'equip, però vaig trobar la web poc útil. Per exemple te diu que la teva màquina no és compatible però no te diu perquè o quines ho són.

Com a valoració final, dir que estic content amb la compra. HP i Linux tradicionalment s'han duit molt bé i aquesta impressora no m'ha decebut, ben al contrari, ja que no confiava que l'escaneig per xarxa funcionàs, fixau-vos si hi confiava poc, que ja vaig comanar una memòria usb junt amb la impressora per a que servís de dispositiu d'emmagatzemament. Poques vegades he estat tant content d'haver-me equivocat.

Aquest és un d'aquells apunts que serveix per recordar-me a mi mateix com fer certes coses:

Eliminar la caché de sessió d'Xfce

XFCE té la mala costum de quedar-se frit de tant en tant, potser un pic cada any o així, de manera que el gestor de finestres es comporta malament. No hi ha manera de tancar una aplicació i la barra de la finestra no és accessible.

Si passa aixó:

 rm -rf .cache/sessions

i arreglat. Reiniciam les X i ja tenim el nostre entorn "com toca" una altra vegada.

Aturar l'arrancada d'Ubuntu

Tots estam d'acord que Ubutnu és una distribució molt amigable, que amaga als usuaris les complexitats del Linux, però de tant en tant es passa d'amable i te les veus i te les desitges per fer alguna cosa que era trivial amb un interfície més espartà.

Una d'aquestes coses me la vaig trobar l'altra dia quan estava "arreglant" un Ubuntu a un bon amic. No hi havia manera d'obrir una sessió a la consola. Una bona estona a Google va donar amb la solució. Si no volem que el Grub carregui automàticament i que ens demana què volem fer hem de mantenir pijada la tecla majúscule (el shift) quan apareix el missatge de la BIOS. Amb això s'aturarà el procés de posada en marxa i ens demanarà què volem fer, donant-nos l'oportunitat d'entrar en mode consola i veure què li passa al sistema.

Linux Mint 13 amb ATI

Quan tens dos monitors posar els drivers propietaris d'AMD/ATI te deixa tot torrat i ben torrat. Per més proves que he fet no hi ha manera de deixar una configuració que funcioni. Així que l'alternativa és posar els drivers lliures i configurar el multi monitor amb l'entorn gràfic. Això funciona i no hi ha problemes.

Tal com em vaig comprometre, avui toca fer cinc cèntims de les butzes d'Spoken i d'allò que estam descobrint i aprenent fent el projecte.

Un dels maldecaps més grans ha estat fer feina amb l'àudio. Cada dispositiu ho tracta un poc d'aquella manera, i arribar a un format que la majoria de dispositius i navegadors es sentís està essent un malson. Amb jplayer la veritat és que va bastant bé, però encara així s'ha de tenir en compte quins formats vols fer servir i després trobar-nos amb que alguns navegadors fan bé l'actualització del player, altres no,... En aquesta versió el més important és que es sentit quan a més llocs millor, després ja hi haurà temps d'anar polint.

Si heu vist la darrera versió des d'un mòbil veureu que es veu força millor. Hem acabat amb un disseny "responsive" que va prou bé per mòbils i sobretaula. Aquest cap de setmana he afegit la compartició amb xarxes socials. Per això he fet servir un plugin anomenat socialite que va força bé per aquestes coses i que no carrega gaire la plana.

Spokenpic és un projecte que pareix senzill però que és força complex, requereix de les habilitats de tots els components de Meneame i APSL. S'ha de coordinar el desenvolupament de l'aplicació mòbil amb la part web, amb el servidor, amb el disseny,... Les noves característiques hem de procurar que no trenquin amb el que hi ha. Ho podríem fer, ja que es tracta d'una alfa i amb gent de confiança, però en el dia a dia ja estam acostumats a trencar poc o gens les aplicacions i no volem que Spokenpic sigui l'aneguet lleig.

Fins ara hem hostejat l'aplicació en un servidor de Hetzner de 7 eur (IVA inclòs), no ho diríeu mai, veritat? El servidor i l'aplicació estan configurat per a treure'n el màxim partit tot i que encara queden optimitzacions a fer, però ara per ara encara no són necessàries.

La setmana passada vàrem encarregar un nou servidor, també a Hetzner, amb 32Gb de RAM i un disc dur RAID 1 de 3TB, en la setmana que comença farem el traspàs de les dades i segurament el servidor actual quedarà com a entorn de preproducció.

No sé la resposta que hi haurà quan alliberem al públic la primera versió d'Spokenpic, però esperam que aquest servidor anirà prou bé i ens permetrà tenir marge de maniobra per, de ser necessari (i ens agradaria que així fos), migrar cap a una arquitectura de cloud, a Amazon.

Fins a la propera!

L'altra dia vaig llegir una notícia que s'havia donat una subvenció a una empresa per a desenvolupar un programa que es posaria a disposició pública (no vaig aclarir si com a codi obert o no). Això se suposa que és una manera que tenen les administracions d'afavorir un sector donant-li part de la feina feta.

En principi no hi veig res dolent amb això. Com a partidari i defensor del codi lliure veig amb bons ulls que les administracions alliberin programari per a posar-ho a disposició de la societat, pel problema que li veig és que com moltes altres vegades les intencions no van acompanyades d'una visió i comprensió de què és el programari lliure i de com evoluciona.

En aquest cas, com en tants d'altres que promou l'administració, la tecnologia elegida pel concurs va ser Java-J2EE. Tecnologia que encara que estigui molt estesa en l'empresa pública, ja no ho està tant en petites i mitjanes empreses.

Una implementació de referència feta per a posar-la a disposició de les PIMES feta amb Java (o .Net) és una mala idea. Costa molt desplegar la tecnologia i fer-se amb el codi.

Per a que el programa alliberat pugui evolucionar i es faci servir, com hauria de ser l'objectiu principal, hem de preveure que el nivell d'entrada del programador ha de ser el més suau possible. És a dir, no s'ha de fer el programari pensant sols amb el client final, sinó pensar que el client serà el programador i per tant cal fer-li la feina fàcil.

Crec que és un dels motius del perquè els projectes Python (Rails o PHP) creixen de manera molt més ràpida que els projectes Java, per una par el llenguatge en sí fa que siguin molt més bons de programar, però a més la incorporació de nous programadors és molt més senzilla, ja que són llenguatges molt més bons de seguir si els comparam amb Java.

Les grans empreses, les que ja fan feina amb Java i tenen pressupost multimilionaris en programació el més probable és que si necessiten el programa que fa l'administració ja se'l facin o ja el tinguin fet. Les PIMES sols l'utilitzaran si hi ha programadors que li donin suport i en puguin fer el manteniment, i si aquest manteniment està a l'abast del seu pressupost. Fer-ho amb Java/.Net per la conveniència de l'administració no és més que un malbaratament de recursos, ja que el cost del suport que pugui donar un programador local en Java serà molt més gran i necessitarà molt més temps. Potser tan gran que no sortirà a compte a la PIME utilitzar la tecnologia.

Fer el mateix amb un llenguatge com a Python té l'avantatge de que la lectura del codi és tan clara que es pot portar a un altra llenguatge fàcilment, i que le modificacions i el nivell d'entrada per al programador local són més senzilles. La PIME és més probable que ho pugui pagar, és més senzill que tot o part del programa es pugui incorporar a altres aplicacions i fer-lo evolucionar.

Les bones intencions no basten, no és cosa de fer l'anunci i fer-se la foto, sinó que és important que la feina tingui continuïtat.

Aquests darrers dies he tingut moltes reunions, la majoria emprenedors que volien demanar un pressupost per al seu projecte. I és aquest fet el que motiva aquest article, ja que amb totes aquestes reunions i amb altres que he tingut abans, hi ha força punts en comú i convé reflexionar-hi

Sóc un emprenedor

Enhorabona! Jo també. Per mi un emprenedor és un projecte d'empresari. És a dir, algú que té una idea de negoci i que ha de demostrar-ne la seva viabilitat i aconseguir posar-lo en marxa.

El que he vist és que hi ha gent que fa servir aquest concepte com a sinònim de "no tenc pressupost" o "no et puc pagar per la teva feina". Amb això ja començam malament. Primer perquè per poder menjar i mantenir el meu propi projecte, jo necessit cobrar la feina, que això de la informàtica potser t'omple espiritualment, però no t'omple la panxa.

Més enllà de l'anècdota, crec que tota aquesta publicitat de converteix-te en emprenedor més enllà de la visió romàntica també hauria de tractar aspectes pràctics. Que en les n-mil conferències i trobades es tracten molt per damunt els problemes reals. Emprendre també té un component de viabilitat econòmica, el pla de negoci que s'ha d'avaluar, s'han de saber d'on sortiran els recursos. Suposar que algú ens farà la feina gratis és, ja d'entrada, menysprear la feina que farà l'altra.

Vull dir, si la teva idea és molt bona, però no hi vols arriscar doblers, demanar a algú que faci feina per tu, i que hi posi la seva feina (que vol dir doblers indirectament) a canvi de un futurible, o d'un "ja cobraràs quan el negoci funcioni" per mi ja directament descarta el projecte. Si tu ja arrisques doblers, jo puc veure que t'ho la prens seriosament, i llavors puc contemplar fer feina per manco de la tarifa habitual o a posar-hi hores de manera gratuïta a canvi d'una participació a l'empresa. Però com dic, el risc ha d'estar equilibrat, i el programador o l'empresa de programació no pot assumir el risc del negoci.

Emprendre un negoci en el món de la informàtica amb unes mínimes garanties d'èxit no es pot fer sense pressupost. Segons el projecte serà més gran o més petit, però si no ets directament que fa el producte i el comercialitza, hauràs de pagar algú per a que et desenvolupi el producte. Però no tan sols això, has de pagar les despeses de l'empresa, de hostejar els servidors, del lloguer, telèfon, ...

Si la idea és molt bona, llavors hem de pensar que segurament algú en aquell precís moment potser també la té. I per tant, treure el projecte o no és una qüestió de qui serà el primer, o de qui pot suportar millor les pèrdues.

Personalment crec que la gent que va muntar Amazon per exemple, també eren emprenedors, però la seva idea de negoci i de ser els primers era tan clara que els primers anys gastaren gran quantitat de diners per tal de garantir que ningú altra podria seguir el seu ritme.

Així doncs, emprendre en un negoci online, sense tenir un mínim pla de negoci i uns recursos per a subsistir i aguantar una temporada és poc menys que suïcida. La setmana passada, i em va saber molt greu, em vaig trobar fent un mini-pla-de-negoci en 5 minuts per tal de demostrar a aquella persona, que venia tota il·lusionada que la seva idea sense un bon finançament no era viable. Tenir que ser tu que facis tocar de peus a terra la gent que te ve amb una idea no és gens divertit.

Senyors que organitzau conferències de recolzament a emprenedors, per favor, no aneu dient que tot és un camí de roses. Parlar de rondes de finançament, de grans números us fa quedar molt bé, però la crua realitat és una altra. Al nostre país és molt complicat trobar inversors, és molt complicat muntar un negoci online, tot són entrebancs: des de les passarel·les de pagament del segle passat, a la legislació que et ferma de peus i mans i no et deixa competir amb legislacions molt més orientades a negoci com l'anglosaxona.

El projecte el farà un freelance.

Tens una idea, la idea es bona i hi ha un poc de finançament. Però com que ets un emprenedor la feina te la fa un freelance. Eps! Cap problema, conec freelance força bons. El problema, és que això és sinònim de dir que "m'ho fa un paio i surt a un preu molt baix".

S'està pensant a molt curt plaç. No vull dir que no es tengui que mirar el preu, sinó que si el teu negoci dependrà del desenvolupament que et faci algú extern s'ha de pensar també amb la continuïtat del projecte. Els freelance bons són cars i van cercats. Si no és així és que quelcom falla. A un sector on no hi ha pràcticament atur, que algú faci feina per molt menys del preu de mercat a mi personalment em feia sospitar quan era a "l'altra costat".

Quan un empren i una bona part del seu negoci estarà basat en una aplicació web s'ha d'assegurar en el que pugui la continuïtat del desenvolupament. S'ha de preveure que hi haurà canvis, errors, adaptacions que algú haurà de fer. I en desenvolupament hem de pensar que agafar codi d'algú altra és molt més costos que si has de mantenir codi que ja coneixes o que està fet d'acord amb uns estàndards definits.

Potser pel teu negoci un freelances serà el que necessites, però al manco ho has de tenir clar i avaluar-ne els riscs. Contractar algú com a freelance sols pel fet que surt més barat és estar assumint un risc molt gran que pot posar en perill el negoci.

Com m'ajudarà Django?

Ja ho tenim clar, tenim pressupost i tenim clar el perquè hem triat aquella empresa o aquell desenvolupador freelance. La tecnologia amb el que un desenvoluparà l'aplicació web de la seva startup també té importància. Hem de tenir en compte dues coses: la facilitat per fer modificacions i l'escalabilitat.

Pensem que quan posam en marxa el nostre negoci poques vegades el que hem pensat funciona a la primera. Hem de fer adaptacions tant al model de negoci com a la tecnologia. I això ho dic també per pròpia experiència. La manera de fer les coses que teníem fa 4 anys no és la mateixa que tenim ara. Ens hem tingut que anar adaptant a les necessitats dels nostres clients per a poder donar-los servei. En alguns casos amb inversions internes de mesos i és un procés que no s'acaba mai (o que no s'hauria d'acabar mai).

Per això és molt important que la tecnologia que facem servir ens permeti desenvolupar ràpid, però sobretot que ens deixi fer modificacions i posar-les en producció tant o més ràpid que fent el desenvolupament des de zero.

Per què hem triat i recomanam Django? Doncs per això mateix. Django separa el que és la base de dades, del model de dades, regles de negoci i capa de presentació. Això vol dir que podem minimitzar l'impacte dels canvis, limitant-los a la capa necessària de l'aplicació. Ens permet escalar amb gent i separar rols de desenvolupament, la qual cosa ens permet desenvolupar i mantenir aplicacions grans amb un equip reduït de gent i mantenir els costs continguts.

L'estructura de desplegament de Django ens permet escalar l'aplicació afegint més servidors. Utilitats com Celery ens permeten distribuir tasques entre servidors, uWSGI, ngnix, redis, memcached, ... Hi ha tot un ecosistema de petites aplicacions altament especialitzades que treballen de manera harmoniosa i que ens permetran anar afegint més servidors i més potencia a la nostra aplicació així com aquesta ho necessiti, escalant per alt però també per baix.

Quan un desenvolupa amb Django de fet està desenvolupant amb Python (més HTML, més CSS, més Javascript) i si ha una cosa que caracteritza Python és la seva legibilitat i facilitat de manteniment.

Amb una estructura adequada per a dur els projectes, tenir que fer modificacions a un projecte passa de ser un malson a convertir-se en una tasca més. Acabam interioritzant dins l'empresa (la del client) que evolucionar és normal, que no hi ha problema, que no és un trasbals. Que es poden fer canvis, veure com funciona i si no ho fan desfer-los, ...

És la tecnologia elegida, junt a l'equip que la fa servir, el que ens permet estar tranquils quan hem de fer un canvi. Hi ha tecnologies que cada pas a producció és un esdeveniment que s'ha de planificar amb molta antelació, on sols es poden provar canvis cada cert temps perquè fer el desplegament és molt car, que no escalen cap avall el cost de mantenir un entorn de proves és prohibitiu.

Python i Django eliminen molts maldecaps i ens permeten estar tranquils. Però no us vull enganar, fer les coses pensant en el futur sempre té el seus cost. S'han de fer plans, s'han de pensar les coses per a que siguin testejables i mantenibles, no és un codificar com a un boig i ja veurem què sortirà, o codificar pensant que ja ho mantindrà un altra.

Emprendre amb seny

Així doncs si la vostra nova startup té un component informàtic important, sia web o no, pensau que hi ha un munt de coses a tenir en compte a més de la idea. Que la tecnologia compta, que l'equip que tens al darrera compta i que encara que no es digui massa a les conferències fer números i tirar de fulla de càlcul és molt important.

Per la meva banda potser em seguirà tocant de tant en tant desil·lusionar algú, però crec que ja he s'ha pres la molèstia de venir a fer una xerrada o demanar un pressupost, el mínim que puc fer és avisar-lo si veig alguna cosa que no encaixa.

No sé si fer d'advocat del diable, però el cert és que crec que si el projecte ha d'anar endavant un punt fonamental de la relació client-proveïdor ha de ser l'honestedat, i això fa que si veig alguna cosa que pot posar en risc el projecte o que el projecte no és viable, convé posar-ho damunt la taula tan aviat com es coneix. Pens que tract a la gent com m'agrada que em tractin a mi.

Avui prop de les dues de la matinada segons els registres twittaires en @pacoros i en @joanballester protagonitzaren una d'aquestes discussions que tant ens agraden als informàtics, donant forma a un quasi-flame twittaire. És una llàstima que seguir una conversació sigui tan mal de fer a Twitter si no ho fas directament quan se produeix. Amb la darrera novetat de la web he pogut fer-me una idea de com va anar la cosa, però al·lots, si per mala sort atribueixo una frase a un que no toca ja m'ho direu. Com que he trobat que la conversa era prou interessant, em permeto la llibertat d'extreure'n un grapat de frases, les agrup per conceptes i miraré de fer-ne alguna aportació constructiva, o destructiva, ja veurem, després de tot és un flame, no?

Programador que controla vs programador que en sap.

@juanballester diu: @pacoros Solo diferencio "buen programador" de "programador 
 que controla bien X lenguaje", creo que hay diferencia. No sé dónde lo siento xD
@pacoros diu: @joanballester Cualquiera que conozca bien un lenguaje, con el
suficiente tiempo y ganas puede programar buen código. Repito "y ganas".

Aquí estic més d'acord amb Juan que amb Paco. Els conceptes bàsics de programació són gairebé universals i es pot ser un bon o mal programador independent del llenguatge. Conèixer un llenguatge no és garantia de programar bon codi, fins i tot per moltes ganes que un hi posi. Hi ha una qüestió estadística pel mig, que en siu que hi ha una gran diferència entre un bon programador i un programador típic, [de l'ordre d'un factor 10[(http://blogs.construx.com/blogs/stevemcc/archive/2008/03/27/productivity-variations-among-software-developers-and-teams-the-origin-of-quot-10x-quot.aspx), i sovint ens podem trobar que hi ha programadors que tenen un factor de productivitat negatiu, sí heu llegit bé, són aquells que fan anar de bòlid a la resta. És a dir, a més del coneixement de les regles del llenguatge de programació triat, s'han de cercar unes certes aptituds individuals. Lo del "tiempo suficiente" no serveix, ja que un dels requisits que fan bo un programador és que sigui capaç d'entregar una feina en temps i forma.

Bon programdor segons l'entorn

@joanballester Está claro. Sólo te digo que lo de "buen programador" 
 depende de muchos factores y depende de dónde programe.
@pacoros lo siento, es que no termino de comprender qué tiene que ver 
 "dónde programe" con lo bueno que sea... o es que no te pillo :D
@joanballester Se puede valorar que sea rápido, que tena tasa de errores baja, 
 que sepa hacer algoritmos... Que sepa muchos LP sólo es un +
@joanballester Pues que el concepto "buen programador" no es universal. ¿O sí? 
 Yo te digo que depende de para quién programe o dónde lo haga
@joanballester Si en un proyecto todos trabajan igual menos uno que programa 
 "mejor" al final los demás no lo entienden y es peor

M'agrada la darrer frase de Paco perquè és totalment certa, però a la vegada paradoxal. Donat que si passa llavors estam davant d'algú que pot programar bé i no ser un bon programador. Quan un està en un equip ha d'adaptar-se a com està escrit el codi, a la manera de programar de l'equip. L'efecte que parla Paco és el de programador "prima donna", o aquell que té necessitat de mostrar que sap fer les coses de manera que ningú pot entendre. Quan parlam d'equips de feina aquests tipus de gent representen una productivitat negativa, ja que fan perdre molt de temps a la resta. Productivitat negativa per mi significa ser mal programador. Això vol dir que algú ha de programar "pitjor" per adaptar-se a l'equip? Bé, tampoc és això. S'ha d'adaptar a l'entorn o també pot mirar d'adaptar l'entorn. Vull dir, si algú programa millor o té més capacitat que la mitjana doncs té una oportunitat fantàstica de mirar d'ajudar a la resta. Un bon programador per mi també és algú que pot fer evolucionar un equip.

Com es pot veure el tema dona per molt. Potser perquè el tema del que és bo és i serà sempre una variable relativa. No hi ha absoluts. Al final programar tampoc és sols el codi, programam per les persones i no per les màquines, això ho hem de tenir clar, i quan programam ens relacionam amb l'entorn.

Supòs que per això molts consells que trobareu a l'hora de triar un bon programador es refereixen tant a la seva capacitat tècnica com amb l'encaix amb la resta de l'equip. La gent tècnica tenim tendència a tenir menys habilitats socials i a tenir un grau de frikisme major i això també s'ha de tenir en compte a l'hora de formar un equip.

Jo tenc una idea molt clara del que és per mi un bon programador, però com que està basada en factor qualitatius a més de quantitatius és força mal de fer expressar-la. Però potser si l'hagués de resumir diria que per mi és aquella persona que essent tècnicament bona li agrada formar part dels nostre grup i amb la que el grup s'hi sent bé amb ella. Quan això passa s'acaba creant un entorn òptim per al desenvolupament i com se sol dir, el tot és major que la suma de les parts.

I la propera vegada em despertau! :D

Hi ha una frase que diu que "a Internet ningú saps que ets un ca". El mateix es pot dir actualment del llenguatge de programació que mou una plana o aplicació web, mentre la plana faci el que ha de fer, a l'usuari que l'està utilitzant no l'interessa el més mínim amb què està feta.

Que avui en dia les planes acabin en php, asp, .do, no deixa de ser anecdòtic. Els bastiments de programació més moderns fins i tot amaguen amb què està feta la web a simple vista, a l'usuari no li cal la informació i potser estàs donant massa informació a algun visitant no desitjat.

Aquest apunt ve arrel d'un post a bonillaware, titulat se buscan buenos programadores. El post és força intressant i l'oferta de feina crec que també, però allà faig una petita reflexió: no entenc com una companyia que va de cools pot fer un error tan de base com cercar bons programadors en un llenguatge concret. Bé, ho entenc si el que cerques no són bons programadors, sinó gent experimentada amb una tecnologia en concret.

Vuit anys d'experiència no et converteixen en un bon programador en res. Si no has après el que s'havia d'aprendre els dos primers anys, afegir anys d'experiència sols pot fer que segueixis repetint sempre els mateixos errors.

Però bé, fent aquesta reflexió va hi bota algú que es sent profundament al·ludit. Potser no m'he explicat bé, però la idea és que si t'agrada la programació has de ser capaç de veure les mancances tant de Java com de qualsevol altra llenguatge de programació. Mancances i punt forts és clar. I si t'agrada molt programar i tens un mínim d'inquietud pel que fas, arribes a la conclusió que Java no és ni d'un bon tros el millor llenguatge per fer programació web.

Al comentari diu "de lo que se trata es de abstraer la realidad y modelarla en un lenguaje que las máquinas sean capaz de procesar".

Cert, això queda molt bé, però per la mateixa raó que descartam fer-ho amb binari, l'eina que triam per fer una tasca concreta té molta importància. No es tracta d'això de fet, es tracta de fer la feina de manera que sigui divertit fer-la, però també que sigui rendible, és a dir, que no ha de tenir un cost per damunt del retorn de la inversió i a més s'ha de poder mantenir i depurar amb facilitat.

En Bonilla no s'atura al fons de la qüestió, que és el perquè l'empresa que fa l'oferta ho fa en termes que contradiu la seva pròpia imatge, sinó que entra en la "guerra" del llenguatge "Yo prefiero divertirme haciendo cosas, no con el lenguaje con el que las hago".

Si hem d'anar per aquí jo vull triar les dues coses. Vull divertir-me amb els projectes, però a més vull divertir-me fent servir les eines que m'agraden. Per això faig feina amb Python, Django i Linux i no amb altres eines, perquè amb això amb diverteixo fent els projectes. Segurament podria guanyar molt més com a programador o cap de projecte Java (de fet guanyava més que ara), però no em divertiria tant.

Personalment em motiva molt que els temps entre la idea i la posada en producció s'acurcin, no tenir que fer sobrearquitectures, poder encaixar i triar les millors peces. Tenir eines potents de desenvolupament i depuració.

Java no és un mal llenguatge, o no ho era, ara ja l'han complicat massa. Per a la web la cosa encara està pitjor, es pot fer de tot, és veritat, però no amb la facilitat i eficiència d'altres llenguatges. Si anau pels apunts antics del blog hi veureu posts dedicats a Hibernate i Spring, escrits quan la gent ens mirava com a "rarets" quan dèiem que Struts no era "la manera" de fer les coses i que hi havia tecnologies millors.

En l'època que vaig estar a càrrec dels projectes webs de TUI España, record que fins i tot ens vàrem fer la típica "encerrona" amb gent de Thales per tal d'esbrinar si el que deiem era cert o no. Això de fer servir Ant pels desplegaments, control de versions, Tomcat enlloc de JBoss, Linux per als servidors, amb Apache al davant, Hibernate per a la part de persistència, Spring com a MVC i IoC i JSP-EL a la capa de presentació, era massa per gent acostumada a fer feina amb Oracle Forms i on el concepte de codi compartit que es tenia era una carpeta compartida Windows amb una fulla de càlcul.

Amb el vist-i-plau de Thales que no va tenir més remei que reconèixer que ells estaven començant a fer servir el mateix (quan nosaltres ja dúiem un grapat de projectes entregats) vam anar desenvolupant webs per TUIE.

La cosa, però és que cada cop el negoci requeria d'un temps de resposta més curt. El negoci turístic, com tants d'altres, necessita les coses, per ahir, i tot i que el nivell de desenvolupament Java-J2EE era prou bo, començarem a mirar cap a altres tipus d'eines que ens permetessin donar un temps de resposta millor. Rails començava a apuntar maneres i tot l'equip va anar a fer un curs a la CAEB, que per cert impartia Guillem Cantallops.

També era l'època de l'alliberament de Django. També apuntant molt bones maneres i fet amb Python. Vam avaluar les dues possibilitats, PHP ho descartàrem gairebé des del principi, massa emperons. Havíem fet el curset de Rails i els exemples i vam fer els primers prototips amb Django.

Juan (a.k.a @morenosan), com jo mateix, ja teníem experiència fent feina amb Python i sabíem de les possibilitats d'aquest llenguatge. Històricament les projectes Python van evolucionant molt bé, ja que el llenguatge és molt llegible i facilita la incorporació de nous programadors als projectes. Podíem haver tirat cap a Ruby i Rails, però ens sentíem més còmodes amb Python i Django així que tiràrem cap allà. El nombre de projectes webs que poguérem treure és multiplicà i el temps de posada en producció era senzillament ridícul.

Alguns projectes els reférem des de zero per a reduir-ne el manteniment. A més de poder-los fer en una fracció del temps i de codi, resultà que a més el rendiment era molt millor. La sobrearquitectura de Java estava fent molt de mal.

Va ser una època molt bona, però hi havia maror per ca'n TUI. Consultors de recursos humans que deien als desenvolupadors que "la mejor opción es irse" es van sumar a tot el que significa un procés de fusió amb HotelBeds.

A HotelBeds hi vaig trobar gent molt bona, però després d'estar-hi gairebé mig any em vaig trobar com al principi amb TUI, sols que aquesta vegada l'immobilisme era encara major. Condemnats a no fer res nou, a fer feina amb tecnologia obsoleta i/o propietària em vaig plantejar un canvi radical d'aires. APSL va sorgir de l'aposta per la tecnologia, per divertir-se programant i fent projectes.

Què el llenguatge de programació no importa? Sí que importa, importa si t'agrada el que fas i la programació no és una manera de passar hores davant un teclat com qui veu créixer l'herba. Importa si ets una consultora interessada en facturar el més possible, en aquest cas millor triar Java, .Net o posar TIBCO per orquestrar serveis que encara no tens. Importa si et dediques a la programació Copperfield, "entrego el programa y desaparezco", en aquest cas segurament el PHP t'anirà d'allò més be.

Però si t'agrada la programació la teva maledicció serà que no et conformaràs mai. Sempre cercaràs maneres de fer millor les coses, llenguatges que provar per si són millors que el que fas servir ara. Noves llibreries, nous editors, noves eines. Seràs un inconformista, un tocacollons si m'apures, però recorda que l'evolució tècnica (potser tota l'evolució) prové precisament de gent que no es conforma amb el que hi ha.

Aquestes festes nadalenques he aprofitat per llegir un poc. M'havien recomanat el llibre "The lean Startup", així que el vaig comprar per Amazon i encara que vaig començar a llegir-lo abans de festes vaig aprofitar la tranquilitat d'aquests dies per fer-li una bona llegida.

El llibre està força bé, però com que ja havia llegit el de "Lean development" doncs he trobat que molts conceptes són comuns i les històries bàsiques que fan referència a l'experiència de Toyota repetides. Però per la gent que tingueu curiositat per aquest concepte el Lean i no el vulgueu aplicar directament a la programació, doncs és un llibre força interessant.

Tanmateix el focus de llibre, tot i que farcit d'exemples per fer lo entenidor, gira entorn a un grapat de conceptes bàsics:

• Fugir de tot el que no sigui necessari per al negoci.
• Esbrinar el més aviat possible si el que feim és el que el client vol, llançant el mínim producte viable.
• Aplicar el mètode científic a les millores i experiments que fem. És a dir, mesurar el que serveix per a millorar el negoci i no el que serveix per a millorar els nostres egos.
• Arrel de tot això, no tenir por en canviar de direcció, de pivotar, si els resultats que tenim a partir dels nostres experiments així ho indiquen.
• Anar a cercar l'arrel del problema enlloc de cercar culpables.

Si ens hi fixam tot és com a molt lògic. Posar-ho sobre paper i llegir-ho, però ens obliga a reflexionar-hi. Quantes vegades estam desenvolupant un producte i afegint més i més característiques sense saber si tindrà o no èxit? En una empresa a la que vaig fer feina, teníem un producte llest per surtir, però els responsables de producte no volien sortir sense una característica molt determinada, el "así no salimos" es convertí en una frase mítica. Potser si haguessin llegit aquest llibre (o un de semblant) el producte hagués sortit dos anys abans i s'hagués guanyat un temps preciós a l'hora de saber si el que es volia fer era viable o no.

Personalment la metodologia Lean m'agrada molt. Estic molt acostumat a pensar d'aquesta manera, i això, us aviso, duu molts de problemes quan penses així a empreses on fer "les coses com sempre s'han fet" es converteix en l'objectiu fonamental. Una altra anècdota, fen una petita auditoria de processos em vaig trobar amb una gent que feien quatre còpies d'un document i les arxivava totes. Quan vaig demanar el perquè, la resposta fou la que us deia. Realment sols es necessitava l'original i la còpia, va costar però eliminar les tres còpies restants, amb la quantitat de documents que es movien segurament va salvar més d'un arbre.

Des del punt de vista del qui monta una empresa, és a dir, de la meva pròpia empresa, procuram sempre aplicar aquests principis. Ja us dic, la persona a la que consider la meva mentora en temes empresarials en José González té aquests mateixos principis a l'hora de gestionar i organitzar una empresa. Si fos japonès segurament ara estaria fent conferències per mig món, aquí tenim/teniu el luxe de tenir-lo com a professor associat a la UIB. Si teniu l'ocasió i podeu agafar la seva assignatura com a lliure configuració i conèixer crec que no en quedareu decebuts.

Me n'he anat per les bardisses. Seguint amb el llibre, encara que la filosofia està molt bé, te queda un regustet un poc amarg. És en el punt on posa exemples d'empreses que aconsegueixen la seva ronda de finançament, del com poden créixer o muntar un negoci online. Després quan ho compares amb les pròpies dificultats per dur endavant un projecte et quedes pensant si aquestes coses sols poden passar en països llunyars, on hi ha empreses que paguen a consultors per fer conferències per tant de millorar l'eficiència del seu negoci, on hi ha finançament de "bussines angels", on les administracions no suposen que tots som un xoriços, ... bé no segueixo que m'agafa la depressió.

En conclusió, un llibre entretingut, amb conceptes molt interessants i tal volta un poc passat de pàgines. Trèieu la part on parla de finançament i perfectament es pot aplicar a una empresa d'aquí.

Ara que ja estam a punt d'acabar el 2011 faré el que toca fer per aquestes dates no és més que fer un resum de l'any que acaba i fer un poc d'avançament del que esper en el 2012.

Com bé sabeu, darrerament per mi parlar d'informàtica i feina és parlar d'APSL, el projecte que iniciàrem fa uns anys amb un grapat de socis, parlar de Python, de Django i de GNU-Linux.

APSL

El febrer de 2012 ja farà tres any de la posada en marxa del projecte APSL, que per qui no ho sap és l'acrònim d'Advanced Programming Solutions SL. El nom el pensarem a un dinar entre en Bernat, en Xus i jo mateix, a partir d'un domini de quatre lletres que vaig poder comprar gairebé de casualitat. Primer va ser el domini i després va ser el nom. Ara no record ben bé qui va proposar la versió final, però record clarament que en parlàvem amb Xus.

Sigui com sigui enguany ha suposat passar dels 2 membre amb que iniciàrem el 2010 a passar a quatre i tenir que canviar d'oficina, passant de la incubadora del Parc Bit a un despatx compartit a l'edifici NTIC del mateix parc.

De fet, gairebé es podria dir que hem acabat l'any amb 5 persones, ja que Xus s'ha incorporat como a freelance també al projecte.

El 2011 ha estat un any dur i divertit a la vegada. Hem tingut prou feina per mantenir-nos ocupats amb el que més ens agrada. Hem fet feina amb projectes grans, que implicaven a tot l'equip durant mesos. Però no tot han estat alegries, com per tot la crisi s'ha fet notar i els plaços de pagament s'han allargat algunes vegades fins a límits que particularment m'han fet passar més pena de l'habitual, i qui me coneix ja sap que sóc passador de pena de mena.

En la part de projectes estic molt satisfet de la feina que hem fet amb la gent d'e-comerce de Fiesta, l'encaix ha estat molt bo, i en aquests moment tenim la web que desitjava el client i a més corrent damunt Django com a CMS. Passaren de un gestor de continguts genèric de PHP a un gestor de continguts fet a mida de les seves necessitats. El canvi no va ser gens traumàtic i ens ha permès no tenir que dir "això no es pot fer" o "això durà molt de temps". Ens ho passam molt bé amb aquest projecte, tant pel client/amic com perquè tenim una gran llibertat per fer optimitzacions. La darrera ha estat l'actualització de Varnish a la darrera versió, amb plugins especials adaptats a les necessitats de Fiesta.

Encara que més petitó, també ens ho passàrem molt bé amb la web de Sa Talaia del mateix Fiesta, aquí perquè va suposar poder retirar una web feta en flash que hi havia i desenvolupar-la amb Django i jQuery. Unes fotografies magnífiques de l'hotel fan que sigui una web que crec que s'ho paga visitar, i ja no dic rec d'anar a l'hotel (llàstima que no m'hagi tocat la loteria).

També estic molt content de la col·laboració assolida amb Xavi i el seu equip en el desenvolupament de la plataforma Txerpa. Content pel que significa particpar en projectes emprenedors i pel muntatge tècnic que hi ha al darrera. La web de Txerpa ja pot donar una idea del que hi ha al darrera, però la part més important és la que no es veu, i que permet donar d'alta i gestionar els usuaris de l'aplicatiu i la seva interacció amb el sistema.

El projecte que s'inicià l'any passat de Globalbooking pareix que poc a poc es va consolidant. En Rafa, l'emprenedor que hi ha al capdavant del projecte és un caramull d'idees i periòdicament anam fent canvis a la web. També s'ha convertit en un amic i company de batalletes. Tant amb ell com amb l'equip de Jesús de Valadis fa molt bon fer feina. Una vegada més ens sentim molt lliures de proposar millores i optimitzacions cercant el millor pel seu negoci. Sé que insisteixo amb això de que proposis millores i que la gent se les escolti, però si heu fet feina per grans empreses sabreu que sovint això no és així. Per mi estar a APSL està significant a més d'un repte personal, una gran satisfacció en veure que pots aportar solucions.

A finals d'estiu llançarem propietarios online, una aplicació web destinada a la gestió de comunitats de propietaris, que decidírem fer al vaixell de tornada d'Eivissa. Obrirem un període de proves i dins el 2012 es començarà amb l'explotació comercial del producte amb col·laboració amb una altra empresa. És un projecte propi que esperam que sigui útil a molta gent i que ens ha permès fer feina provant noves idees a l'hora de programar.

El final del trimestre ha estat mogudet. Projectes que potser s'aniran concretant dins el 2012, molt d'ells lligats a emprenedors, tant en el sentit d'aquell qui creu en el projecte i es llança a l'aventura com projectes novedosos que volen posar en marxa empreses ja consolidades. M'encanten aquests tipus de projectes, sempre suposen un repte, hi ha molta cosa nova, molta implicació tecnològica. Són projectes en els que t'impliques molt personalment, en algun d'ells si l'economia m'ho permetés fins i tot seria capaç d'invertir-hi, però per ara ens hem de conformar en fer-lo el millor possible per a que puguin arribar bé a port.

Dels darrers projectes destacar un de molt divertit Regala unas vacaciones, va ser un mini-deathmarch que em va deixar fora pont, però on m'ho vaig passar molt bé, tant pel bon rollo amb el client com per la web en si mateixa. El projecte va suposar posar a prova una nova manera de generar pdfs que no havíem provat fins a les hores. Ideal per quan hi ha poc text i molt component gràfic. Miraré de parlar-ne en aquest blog.

El 2012 es presenta també mogudet, projectes en marxa que han de finalitzar dins el primer trimestre, projectes propis com el de Propietariosonline que volem dur endavant, i un projecte nou que es va perfilant a poc a poc gràcies a l'ajuda i els comentaris de gent com Sebas o Jordi. Volem posar en marxa un servei d'instal·lació i configuració d'equips per a l'explotació d'aplicacions web fet a mida de les necessitats de programadors, dissenyadors i clients. És a dir, enlloc d'anar a serveis de hosting tipus macdonals, anar al restaurant a la carta, configurant un servidor a la mida de l'aplicació, amb configuracions diferents depenent de l'aplicació o aplicacions que hagi de dur el servidor: configuracions per Django, per Rubi, per Drupal o Wordpress, ... Pens que pot ser un servei molt útil, però el temps dirà si té la resposta que esper.

No puc acabar el capítol APSL sense fer referència a la quantitat d'amics que ens van donant suport i que s'interessen pel que feim. Menció especial per la gent de l'Ibit que ens ha convidat als seus saraus, als quals sempre hi anam amb la màxima il·lusió. A amics com Pau, Benjamí, Ricardo, Marcos, Joan, Sebas, Jordi, Pep, Xus, Eugeni, Paco, Eduard, Suki, Bruno, Xisco, ... (me deix gent, segur) que de tant en tant s'han passat per l'oficina a fer un cafè i a compartir amb nosaltres penes i alegries. He comanat cafè per un grapat de mesos, ja sabeu que ca nostra és ca vostra. Moltes gràcies pel vostre suport amics!.

El 2012 ja veurem com anirà, com us dic, molts projectes a concretar, però després ja veurem. El que sí m'agradaria és poder consolidar bé el projecte APSL i d'una manera o d'altra poder anar aglutinant al voltant del projecte al tipus de gent que m'agrada: gent apassionada per la seva feina i pel codi lliure i la informàtica i amb unes ganes d'aprendre coses noves que no s'acaba mai.

Python i Django

Encara que mantenim aplicacions amb la versió 1.2 de Django ja desenvolupam les noves aplicacions amb la versió 1.3, fent us de les "generic class views" tant com podem, i de utilitats com crispy forms. Que Twitter alliberàs el seu bastiment css i utilitats com crispy han fet que desenvolupar aplicacions de backoffice sigui molt més senzill que abans.

Hem incorporat un bon grapat de llibreries i utilitats a la nostra borsa de programació durant el 2011. Una de les més interessants és Redis, una base de dades NoSQL que poc a poc va reemplaçant a Memcached en els nostres projectes i que ha resultat un complement ideal pel sistema de coes Celery.

Sentry ha resultat un complement ideal per a la monitorització de les web i la gestió dels error no controlats (que sempre n'hi ha). El django-constance ens ha anat fantàstic per a mantenir webs on es tenia que canviar la configuració molt ràpidament sense reiniciar, django-compressor ens ha permès arribar al plus de velocitat de descàrrega que necessitàvem en algunes aplicacions empaquetant css i javascript.

Al primer trimestre del 2012 ja es preveu que surti la versió 1.4 de Django. Hi ha força novetats però la majoria són correcció de bugs. La que més ens afectarà en positiu serà la possibilitat d'interncionalitzar els noms de les urls. Fins ara ho fèiem amb una utilitat apart. Encara que el soport per a la internacionalització de Django sempre ha estat molt bo, trob que li faltava aquesta part dins el nucli del bastiment per passar de ser bo a excel·lent.

Hi ha eines que s'han consolidat com a imprescindibles aquest 2011: south per a la migració d'estructures de dades, pip per a la insal·lació dels paquets associats a una aplicació, virtualenv i virtualenvwrapper per aïllar aplicacions dins el seu propi entorn i fabric, que hem configurat per a que el desplegament i actualitzacions sigui cosa de segons.

Al 2012 esperam molt més de Python i Django. Hem començat a desenvolupar webs per a dispositius mòbils i un dels propers projects ha d'estar adaptat a tablets. Això a més del repte del projecte ha suposat tenir que adquirir una tablet per hom, però sincerament crec que sols en necessitàvem l'excusa :D

Adéu al PPC

Feia estona que volia "jubilar" el PowerPC G5. És un ordenador que no m'ha donat el rendiment que m'esperava, la relació qualitat preu trob que ha estat força dolenta si la comparam amb un portàtil de la mateixa època. El rendiment de l'equip amb dos processadors i 3 Gb de RAM sempre ha estat molt per davall del rendiment d'un portàtil Dual Core amb 2 Gb de RAM.

Fa quinze dies el G5 va decidir que no es posava en marxa. No tenc ni idea del que li passa, però sospit que pot ser la fon d'alimentació, i això he llegit que pel cap baix eren 300 - 400 eur. Sumat a les ganes que li tenia varen motivar la renovació d'equip de casa, i com que la mitja de compra d'equips és d'un cada 6 anys, doncs ja he aprofitat per fer el canvi complet i posar-me dues pantalles planes de 24" que fan goig. Una oferta molt bona de Dell en té la culpa. L'ordinador és un T1600, potent, però que no m'està deixant molt satisfet pel renou que fa, es nota molt que està encès i el disc dur també és molt renouer.

Un amic al que li agraden molt els Range Rovers em va dir que la solució per a que un cotxe d'aquests no faci renou és posar-li uns altaveus més potents a l'equip de música. Potser m'hauré d'acostumar a fer el mateix amb l'ordinador i acostumar-me a fer feina amb els cascs de música posats, però la veritat és que m'esperava més per la qualitat d'equips a la que me tenia acostumat Dell.

I la joguina nova es diu Asus Transformer

Seguin la rocomanació de Sebas el meu tablet va ser un Asus transformer. La relació qualitat-preu és bona i per ara n'estic content. M'agradava molt també el Xoom, però això significava haver de comprar un portàtil addicional per als meus desplaçaments fora de l'Illa. El Latitude 2100 que tinc encara va bé, però amb 4 hores de durada de la bateria fa que tengui que anar carregat amb el transformador si vull llegir el correu sense passar pena.

L'Asus té una càmera pitjor que el Xoom i no té flash, però la incorporació del teclat i una durada d'unes 16 hores em van fer decidir-me. Soluciona tres problemes: tenir una tablet per a poder provar les apliciacions web, poder disposar d'un equivalent a una portàtil per escriure sense problemes i tenir una bateria amb una durada prou gran per no haver de passar pena.

Bones festes

I això és tot per ara, si no ens tornam a llegir al 2011 esper que passeu unes bones festes i un bon començament d'any. Gràcies per ser per aquí i passar l'estona amb mi. Esper que ens anirem retrobant tant per la xarxa com en persona. Volia dir en la vida real, però estic pensant que la xarxa és real i també ho són els amics que hi fas, si va bé ja ens coneixerem cara a cara i si no pot ser això no ha de servir d'excusa per minusvalorar la gent que coneixes mitjançant la web.

Acab, en serio,

BONES FESTES!!!!!

Reflexionant

Aprofitant que avui és una jornada de reflexió me pareix que aprofitaré per repassar un poc l'anecdotaria personal d'aquestes darreres setmanes, a veure si en puc treure també algunes conclusions.

No sé el que vull

Donc així ens va venir una persona a veure'ns i d'entrada em va amollar aquesta frase. Bé, res a dir, això és bastant típic quan es comença un projecte. El client no sap massa bé què vol, i la meva feina sovint consisteix en anar fer preguntes, clarificant el que el client vol. Al final, després d'hores de conversa vaig definint el que podria ser el projecte: gran, molt gran. El client resulta que nos sap què vol, però sap que ho vol tot!

Paralant parlant ens diu que ja té un altre pressupost. Diu que ens ho enviarà per a que li poguem pressupostar el mateix. Fantàstic, al manco hi ha un punt de partida. Al dia següent em pos a repassar les notes i començar a fer el pressupost. Quan m'arriba l'e-mail del client jo ja duc com a 8 fulles del pressupost, explicant què tindrà el programa d'acord amb les especificacions del client.

El pressupost que reb em deixa de pedra. Es tracta de dues fulles ròniques que sols inclouen un llista de manteniments, sense entrar en cap tipus de detall. Ja me fa mala espina que en la maraca d'aigua de la fulla hi ha un disquet (are you from the past?), doncs pareix que sí. Però el que em sobta més és el preu que hi han posat, com a deu vegades menys que el que a mi m'està sortint. Li faig una ullada, no s'incluen caps de les característiques que fan més complexa l'aplicació, pareix un conjunt de planes estàtiques amb un editor html al darrera.

Faig una ullada a la web de l'empresa i veig la feina que han fet. En aquests casos sempre pens que potser sóc jo qui m'he errat. També confirm amb el client que el que vol és realment el que m'ha demanat i no simples planes estàtiques o picades a un cms.

La web de l'empresa és per sucar-hi pa. Webs de fa un any o dos que estan fetes fent servir cgis. La plana 404 de les aplicacions apunta al proveïdor del hosting, que obviament es un d'aquests superpoblats, que aprofiten el darrer cicle de CPU per posar-hi usuaris. Anam a veure una de les webs i li coment a Juan lo del cgi i les petades. Ell a més me comenta que ha canviat un paràmetre de la url i li ha sorti un dump de base de dades. Aquesta gent no ha sentit mai parlar d'injecció de codi ni llegit Exploits of a Mom. Som bona gent i el seus clients no es mereixen tanta incompetència, així que ho deixam anar.

Ara ja tenim un problema important, que és el factor psicològic de la fixació de preu. Aquesta gent ha fet un pressupost sense tenir la mínima idea d'on s'estava ficant i del que realment volia el client i ha donat un preu fruit de la seva inexperiència. Ara quan el client vegi el que jo li presentaré es pensarà que li estic prenent el pèl encara que és just al contrari.

Primera conclusió: els clients en general estan molt verds a l'hora de demanar un programa. Quan un demana una casa s'informa del constructor, demana el que ha fet, en quin tipus de projectes ha participat, demana a les amistats i s'assegura que les cases que ha fet no han caigut. En el desenvolupament sols pareix que es fixa amb el color de la façana. Com a informàtics ens fa falta fer molta feina de pedagogia, d'ensenyar als nostres clients a comparar, a saber que hi ha feines més i menys complexes, a poder destriar amb qui se la juga.

El meu cap diu que té un conegut que ...

Aquesta també és una altra història en línia amb l'anterior. Faig un pressupost força ajustat, el projecte m'interessa, pot ser divertit. El client vol donar el pas cap el negocio online. Vol canviar la seva web actual potenciant-la i afegint-li venda on-line. Es preveuen cents de milers de planes servides al dia i la web hauria de funcionar 24x7 pràcticament.

Tot està tancat, els tècnics del clients entenen el que farem hi saben que ho podem fer bé. Han vist el tipus de feina que fem i s'ha generat aquella confiança que t'anima a col·laborar i a entendre el projecte com si fos teu. Però al darrer moment reb una telefonada: el meu cap ha decidit que ho farà algú que ell coneix. Deman per la tecnologia: punt net, amb asp, internet information server, Windows 2003 i Microsoft Sql 2008. Ni en els meus pitjors malsons recomanaria una tecnologia així pel projecte del client. A més jo li havia oferit un servidor dedicat, és el mínim per anar tranquils amb el tipus de dades que es tractaran i el tràfic previst.

Faig una ullada al mercat nacional de servidors. El fiera del Information Server els hi ha dit que molt millor un servidor nacional per millorar el posicionament. Obviament no ha tingut en compte que això és un factor de tercer ordre, i que si primer la plana no va prou ràpida i té prou ample de banda, ja no hi ha res a fer. De totes maneres faig una ullada al mercat nacional, a veure què hi ha amb aquestes configuracions. Vaig a parar a Arsys, que per 605 eur/mes t'ofereix una plataforma així pel`tot just 605 eur/mes amb llicència sql server express edition, si vols la "bona" són 350 €/mes.

Jo els estava oferint si també un servidor dedicat, amb el doble de prestacions que Arsys i també gestionat per nosaltres per 200 €/mes. Em diuen que la gent que els fa la web els hi han dit que el hosting serà de 60 eur/mes. Per aquest preu i a Espanya em temo que serà un hosting compartit, potser del proveïdor, amb el més nou de la versió patapalo-edition de Microsoft.

És una llàstima, la gent amb la que he tractat em cau molt bé i són els primers que no entenen la decisió. Sospit que pot ser un projecte molt problemàtic i que els acabarà costant sang i llàgrimes. Tant de bo no els costi l'empresa.

Segona conclusió Senyors directius, convindria que de tant en tant i en questions tècniques es fes cas als tècnics, que amb les coses de menjar no es juga.

Tercera conclusió Com el el cas anterior hi ha molt de risc de que el projecte fracassi i el client surti escaldat. Part de la responsabilitat és del client, que hauria de saber què compra, però també hi ha una gran responsabilitat del proveïdor, que està enganant al client.

Pero mira que som frikis

Aquesta setmana també m'han demanat un pressupost per a una connexió amb un servei web. Llegint la documentació veig que el WSDL (argh!) sols està certificat que funcioni (que és el mateix que dir que sols funcionarà) amb Java i .Net. Això se diu fer coses estàndard, sí senyor. És un servei complex i delicat, així que abans de pressupostar res convé fer un petit prototip. Li aplic suds, el client SOAP que feim servir habitualment per Python, i les sospites es confirmen, no és capaç de consumir el WSDL i transformar-lo amb Python. Odio els WSDL la S se suposa que és de Simple, no? Han conseguit fer un protocol infumable i que gairebé sols ho pot consumir la mateixa llibreria que l'ha creat.

Però bé, l'interessant de tenir una capça d'eines farcida és que hi ha alternatives. Feim un poc de brainstroming amb Juan. La primera opció és modificar el WSDL per a que el mapejador s'ho mengi, o bé anar donant ajudes a la llibreria. És una opció que no m'agrada, ja que si hi ha problemes el proveïdor del servei se'n rentarà les mans, fins i tot si la culpa és seva.

Una possibilitat seria fer el projecte an Java, però això significaria un cost molt més alt per al client, i sobretot una manca de flexibilitat a l'hora de fer modificacions, ja que el servei sols és una petita part del projecte. Python i Django ens permeten tenir un temps de resposta molt bo davant canvis i això és fonamental pel tipus d'aplicacions que fem.

L'altra possibilitat és fer un servei Java/J2EE que faci de proxy cap a l'aplicació Python. Amb un protocol de comunicació compartit com xml, json, yalm o un binari com el de Google la cosa pot funcionar. En Juan suggereix fer una ullada a jython, que ell li va fer una ullada i pintava molt bé. Li fem una ullada, el projecte està mantingut i és compatible amb Python 2.5, que ja ens va prou bé.

Fem el primer prototip. Cridam a la libria Java des de jython i fem la cridada al servei. Funciona a la primera. I això provant des de la consola de línia de comandaments de jython. Ja tenim part del problema arreglat, però encara no ens satisfà del tot. En nexe d'unió ha de ser net i jython, com aplicació Java que és necessita un temps considerable per iniciar-se.

Però vet aquí que Celery, el sisteme de coes de Python del qual ja us n'he parlat, resulta que soporta Jython. Podem crear el mapeig de la llibreria amb jython i fer que les peticions sian bé síncorones o asíncrones, però que s'executin com a una tasca Celery. Com que la petició es farà dins un worker i aquest està sempre aixecat, no tindrem problemes de temps d'inici una vegada pugi l'aplicació. Es monta el prototip amb Celery, Redis, Python i Jython, en Juan ho està disfrutant i jo també.

Ara puc fer el pressupost tranquil. Sé que el que podria representar el risc més gran ja no representa el problema, hem descober el boogeyman del projecte (l'home del sac) i l'hem exposat a la llum.

No sé si el projecte es farà, però tenc la conciència tranquila de que aquesta és la manera de fer les coses. A l'hora de fer un pressupost per a un client no es tracta sols de pegar una pedrada i a veure si hi ha sort, sinó en estudiar el projecte i veure'n els riscs que hi pugui haver. Per això sovint sóc un perepunyetes demanant informació abans de fer un pressupost. Sé perfectament que en aquesta fase tot pressupost té un marge d'error gran i que hi haurà variacions en el projecte, però crec que no és professional tirar-se a la piscina a l'hora de presentar un pressupost si hi ha un punt crític que no es té clar com es farà. Preferesc invertir uns dies de feina més (amb risc que el pressupost no surti i perdre la feina) que exposar-nos a nosaltres, al projecte i sobretot al client als maldecapts d'un projecte la viabilitat tècnica del qual no s'ha pensat a l'hora de fer el pressupost.

Ho deix aquí, que aìxò s'ha fet molt llarg. Em deixo parlar de coses igualment divertides, com la telefonia IP que estam posant a l'oficina amb Asterisk i el bé que se sent amb els mòbils Android, o la potència de Bacula per configurar les còpies de seguretat. Potser un altre dia ...

Avui he participat a les jornades de programari lliure que organitza l'IBIT en qualitat de ponent per presentar el cas d'èxit d'APSL com a empresa que utilitza el programari lliure i que a més desenvolupa programes amb programari lliure per als seus clients.

Com sempre és un plaer participar en els actes de l'IBIT i més si mestre Benjamí fa de mestre de cerimònies. La gent de l'IBIT fa una gran feina de divulgació i el tracte personal amb la gent que coneixem d'allà per mor d'haver participat en altres jornades és fantàstic. Des d'aquí moltes gràcies per haver pensat amb mi per aquest tema. A més una de les coses que més em motiven és poder parlar de programari lliure, de com ho vegi, de les coses que es poden fer, ... El problema és que agaf embalada i m'han d'aturar XD

Després de la meva xerrada en Xavi Gil ha parlat de Txerpa, un concepte de negoci desenvolupat al voltant del programa lliure OpenERP en el qual hem pogut paticipar com a col·laboradors tecnològics. Per mi Txerpa representa un exemple molt clar de les possibilitats que dóna a l'empresa el codi lliure a l'hora de montar un negoci. Per una part s'ha pogut montar perquè existia el producte, i per altra ha generat negoci a una empresa com APSL que ha fet la part tècnica. Però a més, i gràcies al programari lliure, els tècnics de Txerpa s'han pogut fer càrrec del codi i anar-ho modificant pel seu compte, quedant APSL com a suport de segon nivell. Amb programari tancat Txerpa hagués tingut el producte, però no el vertader control que té ara.

Es parlà després de Vtiger, un CRM fet amb PHP i que una empresa mallorquina ha pogut personalitzar per adaptar-lo a les seves necesitats i als seus clients.

Va tancar la xerrada de PIMES una xerrada damunt com una empresa que es dedica a la distribució elèctrica a Sóller ha adaptat OpenERP i l'ha utilitzat com a bastiment de desenvolupament i ha creat centenars de mòduls adaptant-los a unes necessitats tant específiques com són les d'una companyia elèctrica.

Personalment estic molt content de veure com el programari lliure avança dins el teixit empresarial mallorquí, gràcies al suport de organismes com l'IBIT, d'agrupacions com BULMA i de tanta gent que pensam que hi ha una altra manera d'entendre el programari.

Ahir divendres 15 hi hagué una nova edició del creantbits. Aquesta vegada enlloc de que la inscripció es fes en un comentari al blog, ho ferem amb una aplicació creada ad-hoc i que serví per experimentar amb un hosting de Python. El hosting va caure un pic en el procés d'inscripció (després de tot encara està en beta), però la gent d'Eldarion va respondre i en poques hores estava una altra vegada operatiu.

L'aplicació en si crec que ha respost bastant bé, tot i estar feta en quatre potades. Ha permés a la gent que s'havia inscrit prest i després no ha pogut venir, fer-ho saber ràpidament i comunicar-ho al següent de la llista d'espera. Tot d'una que tengui una estona més miraré de documentar l'aplicació (que el codi ja hi està) i posar-ho a bitbucket per tal que si hi ha més gent que s'animi entre tots poguem fer un bon programa de gestió d'events.

De l'event en sí poca cosa a dir, la sala plena d'amics, gent que ja coneixia personalment i gent que he pogut desvirtualitzar per primera vegada. Però la part important és amics, això fa que parlar en públic sigui molt menys estressant i també molt més divertit. Va venir molta gent que fa coses interessants en programari lliure, Python o no, però que té pànic escènic. Encara que ja sabeu no tenc cap problema en parlar de Python hores i hores, també m'agradaria que el Creantbits fos un punt de trobada on els amics s'expliquen tecnologies interessants. Pensau que no xerrau davant un auditori estrany, sinó a un grupet de gent, d'iguals, i allò que per vosaltres pot ser el dia a dia potser sigui una revelació per altra gent. Així que animau-vos, que llevar-se la por escènica és important i res millor que fer-ho entre gent de confiança.

La valoració de les xerrades no seré jo qui les faci, esper que us resultessin interessants. Era la primera xerrada de @morenosan, l'home passava pena per si els nirvis el traïen, però ja vàreu veure que se'n va desfer prou bé. En Juan té moltes coses a dir en el món de la programació i noves tecnologies i esper que ara que ja sap que no passa res, s'animi a preparar-nos altres matèries.

En Bernat també tenia els seus dubtes, al matí va començar a dir que igual si no hi havia temps la conferència de Varnish no era tan important, que a lo millor no calia, ... Però no em vaig deixar convèncer i crec sincerament que va ser una de les exposicions més interessants que hem fet al creantbits.

Ja veis, el que costa més d'un event d'aquest és que la gent perdi la por, però és important fer-ho, perquè personalment estic convençut que en aquesta Illa nostra hi ha molta gent que fa coses molt interessants i que no les valora prou. Contava l'anècdota d'un conegut empresari madrileny que es dedica a fer webs per hotels, anava dient a tort i dret que havien fet un cms que admetia llenguatges no llatins, i això ho deia al 2011, nosaltres mateixos ja havíem fet webs en xinès al 2006, i ja no us cont Juan que estigué 5 anys al Japó. És, però un bon exemple de que potser no li donam la importància que es mereix a fer aquestes coses.

I una altra anècdota de l'event. Ens vàrem deixar els curetes per remenar el sucre. Però potser la millor anècdota de totes va der la de @SebaSj , que ens va dir que no podia venir perquè la filla estava en camí. Hem estat molt contents de saber que n'Helena ha fet gairebé tres kilos i que han passat bona nit. L'enhorabona!

El proper creantbis no sé quan serà. Depèn de la feina i de les ganes de la gent, però al manco ja sabem que n'Antònia està disposta a parlar-nos de Python i càlcul numèric, que potser en Xesc també s'animarà a fer alguna coseta i que en Pau quan aprovi la pràctica, té moltes ganes de parlar de Haskell.

Una abraçada a tots el que vinguéreu i disculpes al que quedàreu fora. L'aforament de la sala és el que és i per ara no tenim un lloc millor. La sala gran de l'auditòrium estareu d'acord amb mi que imposaria massa a l'hora de parlar. La por escènica és molt menor quan tens la gent propera i els oients estan agafant gominolas!

Avui m'ha telefonat un client d'un projecte relativament petit que tenim des de fa temps. Volia un pressupost d'una modificació que ha de fer de la web, molt poca feina però encara així vol un pressupost, supòs que més d'un s'haurà trobat en la mateixa situació.

El problema de fer un pressupost per una feina petita és que el cost de fer el pressupost pot superar amb escreix la feina en sí, però a més com que no hi ha pràcticament marge d'error el pressupost si està ben fet implica que t'has d'haver mirat ben bé totes les implicacions i considerar tota la feina que hi pot haver. És a dir, no es sols modificar una funcionalitat, és verificar que funciona, passar-la a pre, validar-la amb l'usuari i passar-la a producció.

Per aquests casos sóc partidari de la borsa d'hores. Tot és més fluid, no és necessari pressupost, i a més crec que és més just, ja que no has de carregar al client la feina de fer el pressupost.

El tema està en on traçar la ratlla, és a dir, quan convé fer un pressupost i quan tirar de borsa d'hores. Quan el client et demana un pressupost normalment és per saber si el cost li compensarà.

El compte és prou senzill, si contam que en durà una mitja d'una hora fer el pressupost (entre parlar amb el client, confirmar que és el que vol, fer la redacció i mirar-ho) i que el treball "petit" típic duu entre 3 i 5 hores, estam parlant que convé tirar de pressupost a partir de feines que pareix que et duran un dia o més. En cas contrari trob que el més just per tothom és tirar de borsa d'hores o "anar a jornal", però fixant un límits, m'explicaré:

En projectes petits a l'hora o dues de fer-hi feina ja veus ben bé l'abast del projecte i el que et durà. Llavors si la feina veus que s'allarga se li ha de dir al client, de manera que sols arrisca aquesta hora o dues i pot decidir amb coneixement.

D'altra manera crec que és menys just, ja que força a endevinar en tasques tan petites on l'estimació es fa pràcticament impossible i podem tenir desviacions de més del 100%.

Fa just una estoneta he fet l'anunci per Twitter de que ens han confirmat des del Parc Bit que podem disposar de la sala de formacio pel #creantbits el dia 15 de juliol a les 16:00.

Aprofitant que és estiu i fa molta calor, i la gent tampoc està per xerrades molt llargues, hem pensat que estaria bé fer xerrades curtes i d'un bon grapat de temes.

La primera per anar fent boca serà de Python. Una introducció als nousvinguts en aquest llenguatge que serveixi per perdre-li la por. En una horeta es pot veure bastant bé el llenguatge i tenir un idea suficient per poder seguir la resta de xerrades, o al manco per adonar-se de la potència que s'amaga darrera el llenguatges.

Després en @morenosan ens parlarà mitja horeta de South i de les seves possibilitats quan fas desenvolupaments amb Django. South ens permet fer modificacions a la nostra estructura de base de dades, de manera que passar de desenvolupament a preproducció i després a producció sigui poc traumàtic, de fet per a que sigui gairebé automàtic. Per la gent que no ha fet servir mai una eina com aquesta segur que serà una revel·lació.

Mirarem que @bercab perdi la por escènica i ens faci una introducció a Varnish. Un sistema de caché del més potent que hi ha i que ben duit ens permet aguantar una quantitat ingent de visites. Estam parlant de 15.000 o més peticions per segon en servidors de gama baixa. Com tot sistema té avantatges i inconvenients. No es tractarà de dir com muntar Varnish, sinó de que la gent que ho vulgui montar per les seves webs tengui sàpiga amb què juga.

Com heu pogut veure en alguns apunts m'agrada molt Celery, així que m'haureu d'aguantar un poc presentant-vos aquesta llibreria. Parlaré de quan i com es pot fer servir, de diferents configuracions que es poden emprar i d'escalabilitat.

Estam mirant de tancar una altra ponència, això de parlar en públic, encara que sigui entre amics pareix que imposa bastant. Ja veurem, si no un poc de trobada social que tampoc no està malament.

No es tracta de fer un curs o una classe magistral, es tracta de perdre la por a la tecnologia, de veure llibreries i programes que potser us sonaran i potser no, però sobretot es tracta de conèixer-nos i trobar-nos de tant en tant.

I ja sabeu que si algú està interessat en preparar-se un tema, doncs a aquesta mateixa trobada o per la propera. Quan més rotació hi pugui haver en les presentacions millor, que si no sempre parlam els mateixos, i no em queix, el que és complicat és aturar-me una vegada he començat a xerrar. :-P

En aquesta ocasió i aprofitant l'entorn de Gondor, he creat una petita aplicació per les inscripcions, està en beta i serà la primera prova baix foc real que es fa.

Inscripcions: http://creantbits.com

Aquesta ha estat una setmana interessant de viure amb molts aspectes. És en setmanes com aquesta en que es justifica la decisió de fer-se autònom i muntar empresa pròpia. Tot i els riscs, els nirvis i l'estres, aquests tipus de coses difícilment passen si fas feina per un altre.

La primera notícia positiva va arribar dilluns, un client amb el que estam negociant refer-li la web ens amplia el projecte. Per mi és positiu surti el projecte o no, ja que implica que si es fa es podrà fer una feina molt més acurada i amb més possibilitats d'integració. Quan vàrem presentar el primer pressupost quedava coixa la part que ara ens han demanat ampliar, ja que quedava fora de l'àmbit del pressupost. Pareix que el client s'ho ha repensat i ho facem nosaltres o no, el projecte serà molt més complet i per tant amb moltes més possibilitats d'èxit en el que fa a retorn de la inversió.

El dimecres al matí em crida Ricardo que era pel Parc Bit amb Martin Varsavsky i si no em feia res acompanyar-los a fer una volta pel Parc. D'aquí en Varsavsky en va fer un apunt amb vídeo i fotografies. Se'm fa estrany veure'm a un vídeo, però la veritat és que em va agradar conèixer personalment a Varsavsky i poder conversar amb Ricardo, que ja feia estona que no parlàvem.

El dimecres mateix deixàrem pràcticament llesta per a producció una nova característica per Globalbooking, en Rafa, qui està al davant del projecte sempre té moltes iniciatives, i és molt divertit poder-les fer realitat.

El dijous reunió amb la gent de Fiesta, anam per feina i són reunions productives, però també ens ho passam molt bé fent feina plegats. Amb reunions així te n'adones del temps que has perdut en altres reunions o mai s'aclaria res, amb gent que entrava i sortia, sovint enlloc d'una reunió pareixia l'squetch dels Marx. És el meu ideal de reunió: bona connexió amb el client, que ja s'ha convertit en amic, decisions preses i a més fas unes bones rialles.

El dijous mateix m'arriba la nova jugueta un Kindle DX. Al final he caigut! M'he esperat a poder-me permetre l'ebook gran, el sistema operatiu que duu pareix que és un poc més antic que els models petits, però jo el vull per poder llegir còmodament pdf en format A4 fense tenir-ne que fer cap conversió. Va fantàstic per això, poses el pdf i a llegir. Encara no he comanat cap llibre, encara en tenc un grapat en paper pendents de llegir, però sí que hi he posat la documentació tècnica que tenc en pdf i fa molt bon llegir.

El divendres capvespre toca sessió de teambuilding, o millor dit d'oficina building. Després de dinar ens posam els quatre a muntar les estanteries d'Ikea que havíem comprat el divendres anterior. En @morenosan diu que "la empresa que monta muebles unida permanece unida". Els mobles queden muntats en poques hores, i per fi podem posar la planteta que tenim a un lloc elevat. La cafetera canvia de lloc, ara és fins i tot més còmode fer-se un cafè.

Per acabar la setmana en Benjamí em convida a la ràdio per parlar de l'empresa i del que feim amb programari lliure. Ja hi ha el podcast penjat a la web, al manco fins que el nou Govern no decideixi tancar-la (què ja heu signat contra el tancament?). A l'estudi ha una munió de gent i en alguns moments és un poc caòtic, però va ser força divertit. Una manera diferent de passar el dissabte capvespre. Però no acabà la cosa aquí, en tornar de la ràdio partim cap a Alaró, que hi ha ball de bot em diu la dona i cap allà anam. De ball de bot encara en sé molt poquet, amb els boleros em defens però les jotes i mateixes encara em superen. Amb les jotes tenc un problema afegit: al la tercera o quarta volta acab ben marejat.

A veure com acabarà la setmana!

En altres apunts ja he posat damunt la taula l'estat de les passarel·les de pagament que tenim per aquestes contrades, amb una estètica i funcionalita dels anys 80 i amb una documentació que no s'ha actualitzat des del temps del Windows NT.

Avui un possible client ens ha demanat poder cobrar al client per plaços a partir de la seva tarja. Clar això significa quedar-se la tarja del client o bé que sigui el propi sistema de pagament que guardi la tarja i que després s'hi pugui poder tornar a accedir de manera segura. Després de tot el client ha vist com hi ha agències online que ho fan, o com Amazon es queda la teva tarja de manera que no l'has de tornar a picar, tot molt lluny de les funestes pantalles de la majoria de TPVs.

En aquests moments a APSL en trobam integrant un TPV virtual italià. La documentació està en anglès i està actualitzada, però el millor de tot és que per tenir un compte de test i tenir accés a la documentació no hem de ser clients del banc. El banc italià dóna totes les facilitats del món per a que montis una passarel·la de comerç electrònic amb ell.

Per què ho dic a això? Doncs perquè se m'ha acudit demanar a Sermepa a veure si això que demanava es pot fer, i en tot cas quins sistemes tenen a part de la típica pantalla. A TUI m'havia pogut integrar amb el seu web service, no sense moltes dificultats i un munté de proves donat que la documentació fa 4 ó 5 anys encara era molt pitjor que l'actual. Així que ingenu de mi he pensat que tal volta la cosa hauria millorat i potser hi havia un web service més potent que pogués donar la solució que cercava el meu client, o al manco quelcom adaptable.

El primer intent ha estat contactar amb el servei de suport de sermepa, soportevirtual en diuen ells. És una gent que es caracteritza per donar-te les respostes el més críptic possible, no sigui cosa que et facilitin la vida i després facis servir el sistema per fer negocis, sols faltaria! Doncs això, els exposo el problema, i la seva contesta és que com que no havia posat un nombre de comerç vàlid i per raons de seguretat (mande???!) no me poden contestar, literalment

 Para poder responder su consulta es preciso que nos envie 
 el código de comercio (FUC) y el código de terminal.

 Entretanto y por motivos de seguridad no nos es posible 
 responder su consulta

Seguretat, quina seguretat, no estic demanant ni tan sols un compte de proves, sols una informació del que tenen o no tenen. Segon intent, m'identific com algú que ha fet amb ells vàries integracions, i els envio el nombre de comerç de la darrera integració fet, però dient-los que el que tenc és un dubte, i que si no són ells la via adequada, per favor em diguin qui. Doncs no, la mateixa resposta.

Bé, els de soport no es guanyarant el premi a l'atenció al client, no, però tal volta el departament comercial ... Vaig a la plana de Sermpea a veure si puc trobar alguna cosa, i finalment he donat amb una adreça comercial. Els hi expos el problema, que estic cercant una solució de pagament online per un client, i que a veure què tenen. La resposta:

Cualquier consulta relacionada con la aceptación de tarjetas como medio de 
pago deberá ser dirigida a la entidad financiera con la que el 
establecimiento haya contratado el servicio.

Que potser no m'heu entès, que no he contractat cap servei! Que el que vull és saber si teniu res que em convengui per contractar-ho. Els torn a enviar un e-mail dient tot això, en bon castellà i amb bones paraules. La resposta:

las condiciones de la forma de operar se fijan en el contrato que firma el comercio con la entidad financiera, por lo que como le hemos indicado debe ser el comercio el que hable con la oficina de la entidad financiera con la que tenga contratado o desee contratar el servicio.

Aquí ja m'ha semblat que o bé no saben llegir, o be se n'enfoten de tu, tan difícil és donar informació?

Ja no he pogut més:

Gracias por la respuesta, pero como comprenderán no me sirve de nada. No
entiendo el porqué tenemos tantas dificultades, actualmente nos estamos
integrando con una pasarela de pago italiana y para tener una cuenta de
desarrollador sólo hace falta pedirla. Paypal lo mismo, sin embargo
quiero operar con una entidad local y todo son problemas. No lo puedo
entender.

Sólo estoy pidiendo información o que me pasen con algún responsable
técnico que conozca la plataforma, pero veo que es misión imposible.
Luego nos quejaremos que las cosas van como van...

Amb aquesta actitud ja me direu com sortirem de la crisi. Encara que vulguis invertir en tecnologia i t'arrisquis posar un negoci a la xarxa te trobes amb aquetes fetes. Ara ja me direu com li explic al client que el que vol fer es podria fer si fos a un país distint d'aquest.

Indignat! No podeu imaginar l'identificat que em sent en aquests moments amb els moviments de protesta del 15M. Els bancs fal el que volen, però és també perquè els polítics els ho permeten.

Arrel del darrer post s'ha establert un nou fil relacionat amb la conveniència o no de fer servir un ORM en les nostres aplicacions quan l'sql directe pot ser més eficient. En Jan Carreres, el "responsable" d'aquest article fa una sèrie d'apreciacions que crec que donen per un nou post, més que res per poder mantenir la discusió en baix el seu propi concepte.

Així doncs acomodeu-vos al seient, que començam ...

Però què dimonis és un ORM

ORM són les sigles de Object Relational Mapping, és a dir, s'anomena ORM a aquella llibreria o procés que fa la conversió d'estructures de dades relacionals cap a estructures de dades orientades a objectes. És a dir, passam de fer feina amb taules i files a fer feina amb classes i instàncies d'aquestes classes. Passam de fer feina de camps a fer feina amb propietats dels objectes.

No hi ha una única aproximació als ORM. Christian Bauer i Gavin King al llibre Hibernate in Action, anomenen quatre característiques comuns a tot ORM:

• Una API per executar operacions CRUD (Create, Retrieve, Update, Delete) en els objectes.
• Un llenguatge o una API per especificar les consultes que fan referència a les classes i a les propietats de les classes.
• Utilitats per especificar les metadades del mapeig entre el model relacional i el model d'objectes.
• Una tècnica dins l'ORM per crear transaccions, fer assosicacions lazy i altres tipus d'optimitzacions.

A partir d'aqui la implementació de cada ORM potser completament diferent. Els autors, citant a Mark Fussel proposen la classificació dels ORMs en quatre tipus.

1. Purament Relacionals. L'ORM es construeix al voltant de la base de dades i es específic per a la nostra aplicació. Té l'avantatge que es pot optimitzar molt, però és difícilment portable entre bases de dades i presenta dificultats de manteniment. És típic d'aplicacions que tenen molta lògica dins la BD en forma de procediments amagatzemats.

2. Mapeig fi. Les entitats són representades com a classes i es mapegen manualment cap a les taules del model relacional. Un exemple d'aquest cas serien les aplicacions Java que fan ús del SQL/JDBC o bé en el cas de Python les que fan servir directament la DB-API de Python.

3. Mapeig mig. L'aplicació es dissenya al voltant del model d'objetes. És a dir, la base de dades és ara un suport per a la persistència dels objectes quan abans era gairebé la peça fonamental de l'aplicació. Aquest tipus d'ORM són especialment interessants quan l'aplicació té un tamany mitjà, amb transaccions complexes i sobretot quan la portabilitat entre bases de dades és un requeriment de l'aplicació.

4. Mapeig complet. S'hi arriba quan l'ORM suporta les característiques més importants i pròpies del model orientat a objectes: composició, herència, polimorfisme, ... i les implementa de manera transparent cap a la base de dades.

Si estam dins el món Java podríem dir que Hibernate està gairebé en el 4 d'aquesta classificació, Ibatis entre el 2 i el 3. En el cas de Python l'ORM de Django estaria començant a entrar en el 4 i SQLAlchemy estaria fregant el nivell d'Hibernate.

Per què fer servir un ORM

Per començar dir que un ORM no és una excusa per no saber SQL. Quan un fa feina amb aplicacions de bases de dades relacionals s'ha de conèixer al manco l'SQL estàndard, tenir molt clars els conceptes de taula, registre, selects, unions, claus primàries, etc. Es dóna per suposat que el tema de la normalització ja ho tenim ben clar.

El que fa un ORM és facilitar-nos la vida. Quan la nostra aplicació ja no es trivial, sinó que fa un ús intensiu de consultes, manipulacions de resultats, insercions, ens trobarem repetint una i una altra vegada el procés de conversió dels nostres objectes cap a sentències SQL. L'ORM fa tota aquesta feina per nosaltres, així que una de les raons més importants per a fer servir un ORM enlloc de sentències SQL a pèl per la nostra aplicació és la productivitat i evitar el DRY al llarg de la nostra aplicació.

Fer servir un ORM implica escriure menys codi nosaltres mateixos i sovint que el codi que hem escrit sigui més bo de llegir. Això es tradueix en una millor mantenibilitat de l'aplicació. Jan diu que si un es dedica a fer apliccions de BD ha de conèixer l'SQL i és veritat, però no té per què tenir a la ment tots els camps que hi ha a la taula. Imaginem-nos un entorn amb molts programadors fent feina a la mateixa aplicació. Aplicació amb moltes taules i amb taules amb molts de registres. Picant SQL a pel és tenim molts números de deixar-nos un camp a l'hora de fer una consulta. L'ORM manté la llista de camps per nosaltres, quan accedim a un objecte el ja se n'encarrega de fer les selects oportunes a la base de dades i obtenir-ne tots els camps.

Encara que hi ha casos en que escriure el codi SQL directament pot significar un guany considerable en el rendiment d'una consulta concreta, el més habitual és que l'ORM que facen servir ja tengui considerat dins la seva estructura les optimitzacions més habituals, de manera que l'sql que es genera pot ser fins i tot més eficient que el que generaríem a mà. Pensar que nosaltres sempre generarem millors sentències SQL és si més no agoserat, i per mi representa una optimització prematura. L'avantatge de productivitat i mantenibilitat que ens dóna l'ORM és el que s'ha de considerar primer. Després sempre hi som a temps d'optimitzar, però els nostres esforços s'han de concentrar en aquelles consultes o accions que torben més temps o que s'executen més sovint. És a dir, l'ORM i l'augment de productivitat que implica ens permet guanyar temps i poder optimitzar allà on interessar realment.

Molt relacionat amb tot això ens trobam la navegabilitat. La navegabilitat que ens permet el model orientat a objectes és d'aquelles coses que xoquen més amb el que ens proporciona el model relacional. Els ORM permeten navegar entre les associacions d'objetes de manera transparent, generant les sentències necessàries i sovint permetent-nos optimitzar aquesta navegabilitat, els select_related de Django n'és un exemple, o les cachés d'Hibernate. Pensem amb el senzill que és posar un objecte dins una plantilla i anar accedint a les seves propietat, anar fins a la propietat que representa una clau forana de la base de dades, fer-ne referència i obtenir-ne les propietats de l'objecte associat. Ara pensem en la quantiatat de codi SQL que ens hem estalviat.

I finalment l'altra gran motiu per fer servir un ORM és el d'independitzar-nos de la base de dades. Podria parèixer que quan un coneix SQL ja pot fer anar qualsevol base de dades, però realment això no és així, cada BD té petites diferències en la implementació de l'SQL que fan que sovint el codi SQL no sigui directament portable entre bases de dades. Un ORM crea una capa d'abstracció entre la nostra aplicació i la base de dades, generant i utilitzant les sentències SQL més adients a cada una.

L'argument que "un tria una BD i l'utilitzes sempre" per la meva experiència passa poc. Una empresa gran pot triar Oracle, però segurament per motius de cost algunes aplicacions les voldrà amb un altra BD. Si comercialitzam una aplicació limintar-nos a una base de dades concreta limita les possibilitats de comercialització. Fent servir un ORM podem desplegar la nostra aplicació contra diferents clients i fins i tot contra diferents versions d'una base de dades.

Resistir la temptació

Quan un comença a programar aplicacions de gestió és difícil resistir la temptació d'optimitzar-ho tot, d'escriure sql a pel optimitzant-ho per la nostra base de dades, és cert, però resistiu!

Si feim sql a pel a poc que l'aplicació creix el procés serà el seguent:

1. Ens adonarem que tenim sql repartits per tot. Així que farem una refactorització i posarem tot l'sql dins un sols arxiu que contindrà totes les funcions.

2. Després ens adonarem que aquest arxiu té molt de codi repetit, feim sempre la conversió de taules a objectes i ho refactoritzarem per a no repetir codi.

3. Després ens adonarem que feim sovint les mateixes consultes i que també es pot refactoritzar.

4. Seguirem i seguirem refactoritzant....

Al final acabarem amb un ORM del tipus 2 que ens haurà duit una feinada en refactoritzacions i que no té encara els avantatges d'un ORM del tipus 3 ó 4.

Costa resistir la temptació, fa peresa estudiar una llibreria d'ORM, però pensem que probablement el camí que seguirem serà aquest i s'ho paga l'esforç inicial.

Avui em fa ganes dedicar un parell de línies a tractar un problema força comú que ens trobam amb programació. A saber, la necessitat de saber si dos intervals solapen o no.

El problema es pot presentar en diverses formes, però un cas força típic és el que tenim una taula que conté una data inicial i una data final i ens demanen que a partir d'un rang de dades, trobem tots els registres que tenen dades compreses entre les donades. Un cas molt típic es del de tenir un preu d'oferta que es vàlid per un rang de dades concret.

Anem a concretar el problema. Tenim un producte que presenta ofertes. Pels qui feis feina al sector turístic això us pot sonar als preus d'un hotel, però el problema és prou genèric, com diuen els matemàtics, podem considerar sense pèrdua de generalitat que tenim una sèrie de dies en que tenim ofertes i promocions de productes

dia     descompte 
1-8     10 €      
9-10    20 €
11-25   15 €
25-31    5 €

El nostre client ens demana un rang de dies i volem donar-li quines ofertes hi ha actives per aquests dies

10 -> 20
11 -> 15
12 -> 15

és a dir, li diríem que hi ha dues ofertes dins el rang cercat, una que correspon a l'interval 9-10 i l'altra a l'interval 11-25

El problema es redueix a determinar quins intervals del nostre rang de consulta solapen amb l'interval d'ofertes i mostrar l'oferta corresponent.

El mètode més directe per comprovar si dos intervals es trepitgen és mirar-ne les condicions en que es solapen, suposant que anomenam a l'interval base [x0,x1] i a l'interval de comprovacio [y0, y1] tendríen que es dona solapament en aquests casos

   [yyy]
[xxxxxxxxxx]      cas 1     x0>=y0 and y1<=x1

[yyy]             
  [xxxxxxxx]      cas 2         y1>=x0 and y0<=x0

       [yyyyy]
[xxxxxxxxxx]      cas 3     y0<=x1 and y1>x1

[yyyyyyyyyyy]
    [xxx]         cas 4         x0>=y0 and x1<=y1

[yyyyyyyy]
    [xxxxx]   cas 5         x0<=y1 and y1<x1

   | y0 | y1 | x0 | x1 | cas |
   | 10 | 12 | 1  | 8  | -   |
   | 10 | 12 | 9  | 10 | 3   |
   | 10 | 12 | 11 | 25 | 2   |
   | 10 | 12 | 25 | 31 | -   |

Si ajuntam casos semblants el codi que tindrem és

def overlaps(x,y):
   x0, x1 = x
   y0, y1, preu = y
   return (
      (x0 <= y0 <= x1) or
      (x0 <= y1 <= x1) or
      (y0 <= x0 <= y1) or
      (y0 <= x1 <= y1)
   )

Però el més interessant és que ho podem pensar d'una altra manera, pensem en la inversa, demanem-nos quan els intervals no és solapen

[xxxxxxx] [yyyyyyyyyy]
[yyyyyyy] [xxxxxxxxx]

és a dir, dos intervals no és solapem si x1<y0 o bé y2<x0, podem cercar dons quan no no es solapen els intervals, i per tant tindrem not (x1<y0) or (y1<x0)

def overlaps2(x, y):
   x0, x1 = x
   y0, y1, preu = y
   return not ((x1<y0) or (y1<x0))

divertit, veritat?

A un twitt en Ricardo es queixava com una startup sols podia tenir un servidor de 100€. Quan he vist la quantitat he estat a punt de contestar-li que sí que se podia, però m'ha estranyat l'afirmació i he anat a veure el seu timeline del twitter. Allà ha quedat bastant més clar. Es referia que per estalviar 100 € a un servidor l'empresa que li feia la consulta estava gastant milers en administració de sistemes, intentant tunejar i posar pegats al servidor actual.

Així doncs no puc estar més d'acord amb Ricardo. Hi ha despeses que no es fan i s'incorre en despeses molt majors. Al final es tracta d'aturar-se un moment i avaluar què s'està fent, tanmateix és una simple resta: mirar què costa el nou servidor, què costarà fer el traspàs de la informació i després llevar-hi el cost del servidor actual i del seu mantenimient.

A més de tot això hi pot haver tota una sèrie de factors a considerar: amb el nou servidor (o amb la nova arquitectura si anam al núvol) segurament guanyarem espai, velocitat, ... els nostres clients notaran l'augment de rendiment. O fins i tot, si el servidor és intern, la gent que hi fa feina diàriment notarà la millora. És gairebé segur que la resposta que tinguem al canvi serà, però s'ha d'avaluar l'impacte per a poder afegir aquests guanys al càlcul de costs i no quedar-nos sols amb la simple resta que parlava.

Avui en dia un dels costs més importants per a una empresa és el cost de la gent, els sous, i per tant, l'estalvi hauria d'anar a fer que el rendiment de les hores-home sigui el més alt possible. Això vol dir que hem d'evitar que tècnics d'alt nivell amb cost-hora elevats perdin el seu temps per mor les eines que tenen al seu abast no són les adequades. Canviar un ordinador a un programador per un de més ràpid (sobretot si fa feina amb llenguatges compilats) vol dir menys temps d'espera, i això vol dir més rendiment. Canviar d'arquitectura o passar a un servidor més gran vol dir poder dedicar recursos que ara es destinten a manteniment a recursos productius.

Però hi ha més coses en la que no s'ho paga estalviar. Les pantalles, per exemple, tenir una pantalla més gran per molta gent significa fer millor la seva feina: gent que fa feina amb fulles de càlcul, dissenyadors, programadors, ... Fins i tot potser que una pantalla no basti i sigui convenient que en tenguin dues. Estam parlant actualment de costs de 200 € per pantalles de 20" i augments de rendiment que s'avaluen entre un 15 i un 20%. Parlem també de ratolins i teclats. La diferència entre un bon equipament i un de dolent és ridícula i la salut de la gent que fa feina tot lo dia amb ells ho agrairà.

Personalment m'estim més feina damunt una post amb quatre cames que prescindir d'una bona cadira, bones pantalles i un teclat i un ratolí ergonòmics. Potser, i sobretot quan comences, el pressupost no està per moltes alegries i s'han de reduir costs, però si és el cas, pensem que és molt millor reduir en decoració de l'oficina, o comprant taules més senzilles (Ikea és el vostre amic) que escatimar en eines productives. La diferència entre una taula de disseny i una post amb cames és de centenars d'euros, la diferència entre un ordinador amb 2 Gb de RAM i un de 4 Gb no arriba a 30.

Sempre hem de tenir present una cosa, el primer és la gent i la seva salut, per tant, quan més ergonomia tinguem a una oficina millor. Després ja és cosa de fer anar la calculadora, i en la majoria de casos posar eines millors implica un increment de la productivitat, ja sigui per l'eina en sí com que la gent fa feina més a gust.

Darrerament es parla molt del concepte d'obsolescència programada, que segons quins productes ja estan fabricats pensant que tindran una vida útil determinada i que a partir de cert temps hauran de ser reemplaçats per uns de nous.

En el món de la informàtica això ho vivim fonamentalment amb les impressores d'injecció de tinta (algunes marques tenen fama de crear aquesta obsolescència artificialment i no per desgast dels components), i làssers que obliguen a costosos cicles de manteniment. Però també vivim aquesta obsolescència en el món del ferro i dels sistemes operatius. Tradicionalment quan Microsoft treu una nova versió del seu sistema operatiu, el ferro que fa un parell d'anys era el millor del mercat ara ja no és capaç d'executar el nou sistema i obliga al seu canvi. D'Apple millor ja ni en parlam, el ferro és tan tancat que qualsevol cosa implica passar per caixa.

Afortunadament no fa falta limitar-se, des de sempre els sistemes Linux han tingut una obsessió gairebé malaltissa per aprofitar els recursos del sistema, fent que cada versió fos més òptima que l'anterior, i sobretot tractant d'aprofitar màquines "obsoletes". A poc que un cerqui per la web trobarem una munió de mini-distros pensades per aprofitar aquestes màquines.

En el meu cas m'havia trobat ja en una situació d'obsolescència lligada a la impressora làsser que faig servir. Una HP 4050, una bona impressora, però sense unitat de xarxa i amb connexió de port paral·lel. La impressora està connectada a un ordinador que tindrà més de sis anys que fa de lloc de fina per als meus fills i de servidor d'impressió. El problema és que les necessitats informàtiques de la família van creixent, els nins han de fer treballs que volen imprimir i ja som quatre compartint la impressora. Això vol dir que les possibilitat de tenir-la que fer servir augmenten i això implica tenir que posar en marxa el servidor d'impressió cada vegada, amb el cost en temps d'espera i malbaratament d'energia que això suposa.

La impressora s'havia quedat obsoleta pel tipus d'ús que nosaltres li volíem donar. Ja estava pensant en substituir-la per una impressora de xarxa quan vaig arribar al blog loquemellegodechina, en ell es parlava d'un NAS miniatura amb capacitat de fer de serividor de discs, via USB i de servidor d'impressores, per poc menys de 35$.

Després de llegir-ne un poc més i fer una volta per DealExtreme, vaig comanar una NAS compatible amb Snake OS. Snake es una ROM per aquests dispositius que afegeix soport ssh i un grapat de serveis més al dispositiu (com memòria swap per exemple), però el millor de tot és que és codi lliure.

Així doncs, després de tres setmanes d'espera em va arribar el meu paquet: la NS-K330, un cable de conversió paral·lel USB i un adaptador de corrent. El cost toal no arriba als 40 €.

Primer vaig instal·lar el dispositiu original, ve configurat com a client DHCP així que va ser cosa d'endevinar un poc la IP que se li havia assignat. Una vegada fet això i entrant amb el navegador apareix una interfície web en la que podem tunejar el dispositiu. Vaig configurar un disc usb i la impressora, i vaig provar d'accedir-hi des d'un dels equips. Cap problema, tot va funcionar a la primera.

Ara ja sabia que el dispositiu ja funcionava, així que era hora de provar l'Snake OS. El risc era carregar-me'l però l'experiment s'ho valia. Així que vaig descarregar la nova ROM i vaig actualitzar el dispositiu. Un parell llarg de minuts després el dispositiu tornava a la vida (amb una altra adreça per DHCP) i amb un nou sistema operatiu.

La compartició d'imprsesores d'Snake fa servir JetDirect i es configura de manera trivial als Linux. Cerques una impressora de xarxa i ja te surt la IP del dispositiu amb el port 9000. L'accés per ssh també funciona, així com l'accés per FTP i Samba. El consum en potència del dispositiu NS-K330 és mínim, si ho comparam amb els prop de 300 W del servidor antic, a poc que aguanti amortitzarà de sobres el seu preu.

Però el millor és que m'ha permès lluitar contra l'obsolescència, aprofitant un equip perfectament útil i divertir-me en el procés.

Primer apunt del 2011

Primer apunt d'aquests any. Se diu aviat quan gairebé ja ha passat un mes del 2011. Aquesta aturada per festes ha suposat també una aturada en els pots d'aquest blog. No vull dir que escriure sigui una rutina més, però sí que requereix de moments de tranquil·litat davant de l'ordinador, de reorganitzar idees, i amb les festes i amb tot el que queda pendent a l'inici d'any per mor de les festes, doncs tot s'acumula i els moments propicis per escriure al blog són molt limitats.

Així que aquest primer apunt implica d'alguna manera tornar a la normalitat després de festes, posar en ordre els projectes i també fer un petit resum de l'any passat, que com a nota històrica doncs tampoc queda tan malament. Als soferts lectors ja us aviso que aquest apunt va de batalles, buabulància, projectes, ... Un sac on s'hi pot trobar de tot, bé si fa no fa com als resums anuals que fan per les teles, però sense els cops i les caigudes.

Com molts sabeu el 2010 va ser l'any en que vaig deixar una feina estable a Tui España (després Hotelbes) per dedicar-me junt amb altre(s) socis a fer feina a temps complet per a la nostra pròpia empresa). Vist amb un any de perspectiva he de dir que no tot són flors i violes, això de tenir un sou fix cada més està força bé, però també es veritat que poder fer feina en projectes amb la tecnologia que t'agrada i de la manera que t'agrada crec que ho compensa de sobres.

També he pogut veure que moltes de les coses que comenta la gent autònoma o les petites empreses és totalment cert. Crec que es creen micro-empreses i autònoms a pesar de l'administració i no gràcies a ella. Tenir que avançar l'IVA de factures que encara no has cobrat (i que potser no cobraràs) és l'exemple més clar, però també ens n'hem trobat més: disposicions vers la comunicació electrònica de l'administració que sols funcionen amb segons quins sistemes operatius, concursos públics que demanen un programa específic d'un proveïdor concret (no fa falta dir quin, veritat?), subvencions que se'n van a empreses que no ho necessiten, plans avanza que impliquen que siguis una gran empresa per presentar-hi i ja pensats per a que les empreses se n'aprofitin i que juguen al gat i al ratolí amb les normes. Pens que tot hauria de ser més fàcil, en Varsavsky a alguns apunts del seu blog quan parla de la crisi i de com està organitzada la creació d'empreses a Espanya dóna bastant al clau.

També potser totes aquests qüestions burocràtiques tenen una raó de ser, que la gent té per hobby defraudar tot el que pot a Hisenda i a l'Estat (els recents i nombrosos casos de corrupció que s'han destapat a les nostres Illes aquest darrer any així pareix que ho demostren), però també crec que molta paperassa que es fa té per objectiu justificar la pròpia burocràcia i la seva ineficiència. Amb la quantitat d'informació que té l'Estat damunt nosaltres no té sentit que cada organisme torni a demanar la mateixa paperassa, i que se suposi que tothom és un potencial defraudador i es legisli en conseqüència, és a dir, no amb la intenció de fer més fàcil la creació d'empreses i la seva gestió, sinó amb la intenció de fer més fàcil la feina d'inspecció i control, passant la càrrega de feina (i sovint de la prova) cap a l'empresa.

Per exemple, una de les normes suposa que per una micro-pyme com nosaltres hem de fer que els 85% de beneficis vagin com a factures dels socis, la conseqüència és que a principis d'any l'empresa es queda pràcticament descapitalitzada i sense marge de maniobra per escometre inversions (ja siguin de renovació de mobiliari o de projectes propis). Entenc que és una mesura per evitar el frau, però que fa molt difícil la vida a les micro-empreses que començam.

Però no tot és negatiu, la veritat és que la Incubadora del Parc Bit és una gran ajuda per gent com nosaltres i el personal d'allà està fent molt bona feina. També a poc a poc vas notant alguns canvis positius: que l'Ibit organitzi un curs de qualitat d'OpenERP va ser una notícia prou bona pels que creim que el programari lliure és una opció de futur pel nostre teixit empresarial. Les empreses ja no els estranya que els diguis que fas feina exclusivament amb programari lliure i que els desenvoluparàs una aplicació web que correrà damunt Linux. Potser és la crisi, potser és un canvi de mentalitat o tot plegat, però al manco es veu que alguna cosa està canviant de manera lenta però inexorable.

Els projectes del 2010 han estat força entretinguts, hem tingut un gran projecte: la migració i renovació de la web del grup Hoteler Fiesta. Tot i que algunes vegades hem tingut que adaptar-nos al que ens deixava fer el CMS "legacy" més que al que nosaltres ens hagués agradat, el treball va ser molt engrescador i va suposar un repte tècnic important.

Hem pogut fer feina amb Python i Django amb molts projectes. Des de webs presencials com la de Clima Insular a projectes b2c com són els projectes de Globalbooking i Clickote. Hem fet feina amb Python i Django, i afinat les configuracions de sistemes per fer que les aplicacions tenguin un rendiment semblant a webs que es gastes varis ordres de magnitud més en el seus desenvolupaments. Personalment m'ho he passat d'allò més bé en veure com una aplicació com Celery i RabbitMQ pot donar un joc tan gran en el desenvolupament web. En poques paraules, m'he divertit, ens hem divertit amb la feina.

El 2011 es presenta també molt interessant. Tenim en cartera projectes per fer webs de venda per alguns hotels que crec que poden quedar molt bé. No ens les donam de gurús i no tenim el marketing d'altres, però mira som així i no hi podem fer res. L'altra dia a un twitt un conegut gurú del marketing hoteler deia que eren els millors perquè el seu cms podia fer feina amb múltiples idiomes, com si l'Unicode l'hagués descobert ell. Fa ja prop de tres anys nosaltres amb Python i Django posàrem la web d'UltramarExpress en producció en xinès i ens va parèixer la cosa més normal del món, crec que no ens sabem vendre bé. També és veritat que potser també tenim més coneixements tècnics per a saber què és l'Unicode, l'UTF-8 i per distingir la traducció de la localització. Em sap greu, però aquests tipus de venda de fum m'indignen!

Em fa moltes ganes seguir fent feina amb l'arquitectura d'Amazon, amb els preus a que s'han posat les micro-instàncies, fer experiments o posar serveis dedicats és molt barat. Un dels primers que crec que posarem serà un servidor dedicat per Git. Estam investigant si hi ha alguna cosa opensource que ens faciliti la tasca d'administració, però el que és segur que tenir un servidor propi per control de versions damunt Amazon per a una empresa té un cost realment ridícul. En la nostra feina diària feim servir fonamentalment el subversion, però Git (o Mercurial) tenen molts avantatges com per a no intentar fer el canvi. Representa però una manera de fer feina que requereix una adaptació i aquesta ha de ser el menys traumàtica possible. Feim servir Trac per a gestionar projectes i hem d'avaluar el suport de Git o pensar en migrar a Redmine que pareix que el té molt més madur. Com dic, també estaria molt bé tenir una eina web potent d'aministració dels repositoris i dels usuaris, més que res com a una opció de futur.

El 2011 també es presenta molt interessant en el món Python. Supòs que les distribucions més populars ja vindram amb el Python 2.7 i això facilitarà la migració cap a la versió 3.x de Python. La setmana passada pareix que se va arreglar l'entrebanc més important que hi havia amb el mòdul wsgi per la versió 3 i això vol dir que els principals frameworks Python podran utilitzar Python 3 i desplegar-se sense problemes. Seria molt agoserat dir que el 2011 serà l'any en que Python 3 serà l'estàndard per al desenvolupament web, però sí que crec que es portara a Python 3 les principals llibreries i que el 2012 (si no s'acaba el món) un ja tindrà pocs dubtes de si programa amb Python 2 o 3, directament ho farà amb el tres.

El 2010 Python ha guanyat molt acceptació dins la comunitat de programadors. L'índex TIOBE i el premi al llenguatge de l'any són una bona mostra i el 2011 crec que anirà pel mateix camí. Cada cop veus més utilitats, aplicacions web i web fetes amb Python i algun framework (normalment Django). Les utilitats de desenvolupament web per Python cada cop són més potents i a la vegada fàcils de fer anar, amb línea amb la filosofia del llenguatge. He passat d'utilitats de testeig com pyUnit a fer feina amb nose, que fa que crear tests unitaris per testejar aplicacions no sigui molt més complexe que escriure els petits scripts que tanmateix ja feia. Nose permet reutilitzar la feina que ja feim i formalitzar les proves que hauríem fet de totes maneres. South per Django és una altra d'aquestes petites joies que ha arribat a la maduresa. L'actualització del model de dades per Django és trivial amb South i cobreix pràcticament el 99% dels casos. A l'autor li han proposat sovint que South formi part del Core de Django però ell diu que encara no està totalment satisfet i que per això vol mantenir-ho com a projecte separat. Pareix que vol arribar a la perfecció absoluta!

A més de per les ganes que me feia poder fer feina a la meva pròpia empresa, una de les raons que me dugueren a deixar Hotelbeds, no ho negaré, va ser que volia poder desenvolupar projectes amb Python i Django com fins aleshores ho havíem fet a TUI España. Crec que és un dels grans problemes de Python, que una vegada que hi fas feina tornar a altres llenguatges és molt difícil. Crec que va ser i és encara una decisió arriscada, però fer feina amb el que te grada sovint ho és.

La versió 1.3 de Django s'espera d'aquí uns mesos. Serà una versió de transició, orientada a corregir bugs i afegir petites millores de funcionalitat que quedaren com a tickets pendents d'integrar a la versió 1.2. Tot i això hi haurà millores com la millora en el maneig de contingut estàtic, que ha passat de ser una aplicació independent a estar integrada en el core.

Fa pocs dies al twitter i a la llista de desevolupament s'anunciava que es passava a Transifex per a les tasques de traducció. Això és una molt bona notícia. Transifex és d'aquests projectes que poc a poc van calant dins els món del desenvolupament per la seva senzillesa i eficàcia. Una altre bon exemple seria també el d'Sphinx per a la documentació d'aplicacions, o fins i tot una aplicació web molt recent, el readthedocs que s'està convertint en una web ideal on deixar la documentació dels nostres projectes online.

Al 2011 també hi haurà la possibilitat d'anar a la Django Conference que enguany es fa a Holanda, un destí relativament proper i econòmicament assequible. Si l'economia m'ho permet me fa moltes ganes anar-hi, serà una bona oportunitat de conèixer gent a la que segueixo per les llistes de Django i/o Twitter i veure com afronten ells la realitat empresarial.

També crec que pot ser un bon any per implantar OpenERP a l'empresa. El curset de l'Ibit ens va servir per adonar-nos realment de tot el seu potencial. Ja ha sortit la versió 6.0 i encara que no està completament localitzada trob que està prou madura per poder-hi començar a fer feina internament i potser d'aquí algunes setmanes/mesos començar a fer alguns projectes per tercers. OperERP està fet en Python i per tant moltes de les eines i tècniques que ja feim servir són aplicables al desenvolupament d'aplicacions de negoci damunt OpenERP.

Realment no sé si el 2011 representarà el final de la crisi, si tots els projectes que hi ha en expectativa es tancaran finalment i tindrem un any bo. Com que me conec sé segur que no deixaré de passar pena: per la feina, per les factures, pel local, pels projectes,... però és el meu tarannà. La diferència és que abans me creava molta ansietat el saber que les coses es podrien fer d'una manera millor i no tenir l'oportunitat de canviar les coses, ara aquesta ansietat no hi és, perquè al manco tenc l'oportunitat d'intentar-ho.

Fa uns dies vàrem finalitzar la primera part del curs d'OpenERP. Aquesta part estava dedicada a la programació d'aplicacions i després, de fet la propera setmana, seguirà una part més dedicada al món de l'empresa i la gestió.

El curs és una iniciativa de l'Ibit d'aquestes que et tornen a reconciliar amb l'administració. Quan l'administració aposta per programes com OpenERP i la formació de programadors locals en aquestes tecnologies està apostant tant per l'empresa local de programació com per les PIMEs, que podran gaudir d'una programari avançat amb el sol cost de la seva implantació. Un ERP com OpenERP uneix omptabilitat, facturació, gestió de clients, etc amb la capacitat de programació i personalització. El que sigui slliure implica que el que pagaríem amb llicències se'n pot anar a millorar el programa i a adaptar-lo a les nostres necessitats.

Coneixia OpenERP des de fa temps, però els darrers dos anys el seu creixement en funcionalitat i mòduls ha estat espectacular. El programa està escrit en Python, una de les coses que el fan més atractiu, ja que fa que la corba d'aprenentatge sigui molt suau i a més fa que els requeriments de màquina que se necessitin per fer anar el programa siguin minims. La base de dades que utilitza OpenERP és Postgresql, una altra magnífica elecció al meu entendre ja que personalment he pogut comprovar la robustesa d'aquesta base de dades en entorns de negoci i la seva gran versatilitat.

Recordem que estam parlant d'un ERP, un sistema que integra tot el que el negoci pugui necessitar gairebé de sèrie i que permet personalitzar-ho de manera que sigui el programa el que s'adapti al negoci. Així podem verticalitzar l'aplicació creant nous mòduls i aprofitant els existents, o bé podem utilitzar-ho com a bastiment per a crear les nostres pròpies aplicacions. El sistema es prou modular per permetre ser utilitzat com un programa de comptabilitat i gestió potent, com un bastiment de programació per aplicacions de gestió o la combinació d'ambdues caracterísiques. Sols per la comptabilitat i facturació la instal·lació d'OpenERP ja es justifica sola, per una part tindrem un dels millor programes comptables que hi ha i a més a més tendrem control de les nostres dades. Supòs que més d'una ara recordarà algun amic o conegut que s'ha trobat amb problemes amb alguna de les distintes versions de contapluses pagades i amb llicència (canvi disc dur o d'ordinador són bastant habituals), i quan ha anat a consultar què passava li han dit que ha de passar per caixa i contractar un manteniment que li costa més que el que va pagar de llicència. Mentre no té accés al programa, no pot fer factures ni comptabilitzar, passa a ser hostatge de la seva compra. Amb OpenERP això no passa, no depens d'una única empresa que et pugui donar el mantenimient, si ho instal·les a casa les dades són teves i no hi ha limitacions artificials. Si el nostre negoci creix i necessitam més gent a administració o canviam de disc dur l'OpenERP seguirà funcionant.

Que OpenERP estigui escrit en Python i que hagi tingut aquest creixement per mi no és casualitat. Ho he vist en altres projectes Python, que comencen molt tímidament però que aviat gràcies al nivell d'entrada tan suau que té el llenguatge i a la seva legibilitat, va incorporant programadors i característiques fins a convertir-se en un referent dins el sector. Ho hem vist recentment a projectes com Django o Satchmo, i també a llibreries com pyQt, wxPython, sistemes de còpia de seguretat, ... OpenERP és potser un dels millors exemples del que es pot fer amb Python.

La part de programció pura, amb OpenObject i no lligada a la comptabilitat o facturació també es mereix la màxima atenció. És molt bo de fer crear formularis i aplicacions noves. La gent que sovint diu que necessita un Access per Linux li hauria de fer una ullada a com funciona el programa. Pel mateix preu tens el client gtk i el client web, i la feina que duu m'atreviria a dir que és menor que una aplicació Acces ben acabada.

Personalment ho tenc força clar, OpenObject passarà a formar part del meu caixò d'eines informàtique i l'opció preferent quan es tracti de crear una aplicació de gestió d'escriptori o web. A més és molt bo de fer connectar-ho amb Django o altres aplicacions gràcies a la seva filosofia oberta.

Esper que la propera setmana el curs sigui tan interessant como ho va ser el de programació. Crec que ens divertirem molt amb OpenERP i OpenObject.

Actualització: Pujats els documents al dropbox

• Presentació d'eines

• Presentació Git

Una vegada més, i ja van quatre el creantbits ens ha servit per carregar piles, per trobar-nos amb amics que feia temps que no veiem. Cares conegudes d'altres trobades (des d'aquí moltes gràcies per el detall de les galletes) i un quòrum impressionant. Se nota que en Pau té tirada :)

Feia estona que volíem fer una altra trobada d'aquestes. Personalment crec que és molt enriquidora pel que representa d'important per nosaltres veure que hi ha molta més gent que s'interessa pel mateix tipus de coses que nosaltres. Com ja he dit altres vegades això me fa tornar la fe amb la professió.

M'hagués agradat poder fer streaming de vídeo, l'hem intentant, però ens ha fallat la connexió. Ja sé que estam a un Parc tecnològic, però ja sabeu com van aquestes coses. A APSL necessitàrem prop de tres mesos en tenir una ADSL i és sols de les normaletes (i cares), res de connexions de 50 Mb que hi ha pels pobles. A veure si la propera vegada hi ha més sort!

Com a telonero de Pau he presentat un grapat d'eines que trob d'allò més interessants per fer feina amb Django, Python i potser fins i tot per complementar altres llenguatges de programació. En Pau per la seva banda ens ha fet una introducció molt clarificadora del que representa fer feina amb Git. M'ha agradat molt la frase de que Git representa una solució tècnica a un problema social, el de la comunicació. En pau m'ha enviat la presentació i la penjaré junt amb la meva tot d'una que pugui.

Moltes gràcies per l'assistència i el suport. En el nostre ànim està el seguir fent més trobades com aquestes. El suport del Parc Bit (Incubit) cedint-nos la sala val a dir que és una de les coses que fan possible que aquest esdeveniments siguin possibles. Ens queda un any i mig d'incubació encara, així que amenaçam amb tornar-hi :)

El divendres 29 d'octubre a les 16:00h a la sala de formació del Parc Bit tornam amb una nova edició del Creant Bits.

Aquest cop ens fa ganes xerrar un poc d'eines de programació Python, fent cinc cèntims d'utilitat com virtualenv, fabric, pip, ... És a dir, de totes aquelles eines que no poden faltar a la borsa d'un programador Python i que ens permeten ser encara més productius.

Després en Pau Rullan ens explicarà con fer servir Git en el dia a dia. Git, junt amb Mercurial són una de les millors eines de control de versions distribuït que podem trobar. En Pau s'ha ofert a explicar-nos perquè Git li agrada més i com fer-ho servir per a que la complexitat d'aquesta utilitat jugui al nostre favor.

Com sempre aforament limitat a 25 persones màxim. Us podeu apuntar deixant un comentari.

L'altra dia i gràcies a Jordi Cabot vaig arribar a un article anomenat Groovy for Business Software. Why not?.

L'article és prou interessant i ve a mostrar els avantatges de fer servir Groovy per al desenvolupament web amb la unió amb Java. Groovy està prou bé si un no pot fer servir Python per les raons que sigui, però encara té moltes reminiscències de Java que fa que el codi sigui mal de llegir i lent d'escriure.

Si anam a la consola de Python i feim un

import this

Trobarem de les primeres la frase "flat is better than nested". La idea de que el més simple és millor, que el codi ha de ser el més pla possible i que els anidament s'han d'evitar.

El codi Groovy per crear un XML és

def writer = new StringWriter();
def builder = new groovy.xml.MarkupBuilder(writer);    
builder.carList {
    for (make in ["Honda", "BMW", "Cadillac"]) {
        car(make: make) {
            type("sedan")
            year("2010")
            used("false")
        }
    }
}
def xml = writer.toString();

És un codi prou simple, però quan vaig fer l'exercici de passar-ho a Python vaig tenir que repetir-ho. No vaig veure la tercera clau i vaig generar un XML que no era el de la sortida.

Veiem el codi Python

from lxml.builder import E
from lxml import etree
xml = E.carList()
for brand in ["Honda", "BMW", "Cadillac"]:
    car = E.car(make=brand)
    car.append(E.tipo("sedan"))
    car.append(E.year("2010"))
    car.append(E.used("sedan"))
    xml.append(car)
print etree.tostring(xml, pretty_print=True)

El nombre de línies que s'han fet servir és anecdòtic, l'important és que algú que segueixi el codi ho té molt més bo de fer per entendre'l. L'anidament ha desaparegut i com s'afegeix cada tag a l'xml es veu a la primera, és ben explicit a qui afegim què.

Quan programam ho hem de fer com si algú més que nosaltres tingués que entendre el codi passat un any, ja que quan el temps passa i encara que siguem nosaltres mateixos els qui hem de mantenir el codi, la filosofia de Python de fer les coses el més simple i explícites possible ens pots estalviar moltes hores de depuració.

Ahir volia substituir una paraula però sols dins un bloc de codi concret. Per les presses no vaig anar a cercar com fer-ho amb Vim (la primera opció que vaig provar no va anar bé), però me va quedar el cuquet de com fer-ho, així que un poc de cerca a Google m'ha duit fins a aquesta recepta.

A Vim podem seleccionar blocs de texts entrant en mode visual (v, V o Ctrl+V per seleccionar en columnes).

Quan tenim el text seleccionat pitjarem : per entrar en mode comandes i en sortirà l'editor amb

   :'<,'>

Això ens indica que podem començar a escriure la comanda, entre d'altres la d'edició i substitució. Així doncs bastarà teclejar s/{patró de cerca}/{patró de substitució}, el que feia jo malament era posar un % davant la essa.

Tot i la selecció que hagem fet, aquest tipus de substitució sols funciona per a línies completes, en la majoria de casos ens bastarà, però si volem liminar-nos exactament a la columna que hem seleccionat, hem de limitar més la cerca. Vim ens permet utilitzar %V per restringir la cerca al que volem. Així, la nostra cerca serà:

:%s/\%V{patró de cerca}/{patró de substitució}/g

Com a curiositat destacar que la barra de separació de bloc entre cerca i substitució no té perquè ser una barra, pot ser qualsevol caràcter que ens agradi.

L'altra dia vaig tenir l'ocasió de parlar amb un responsable informàtic d'una empresa gran. Una conversa llarga però entretinguda, afegiria.

El cas és que en un moment de la conversa l'home va venir a dir que abans es pensava molt més a l'hora de programar, que com que el temps de CPU era molt més car, llavors els programadors s'havien de pensar molt el que feien, que els programes tenien menys errors d'entrada.

La veritat és que no tenc dades estadístiques de la quantitat d'errors que hi podria haver, però també és veritat és que pareix que la taxa d'errors per línia de codi és una constant que s'ha mantingut pràcticament constant al llarg del temps. De fet és una de les raons per elegir llenguatges d'alt nivell respecte a llenguatges de baix nivell a l'hora de programar, ja que hem d'escriure menys línies de codi, llavors la quantitat total d'errors introduït també serà menor.

Així doncs, tenir molt repensant els programes a l'hora de picar-los no feia que tinguessin menys errors, sinó que sintàcticament eren correctes. Però la gràcia dels analitzadors de codi actuals, dels compiladors, és que permeten caçar tots aquests errors de manera ràpida.

És a dir, actualment es pot teclejar el codi directament a l'editor, compilar-lo (o no si feis servir un llenguatge interpretat) i provar-lo en un cicle de realimentació ràpid. El que estam fent és aprofitar la tecnologia al nostre favor, deixar que l'ordinador caci els errors de sintaxi i ens avisi dels errors més obvis. En definitiva el que estam fent és aprofitar-nos de que l'hora de CPU té un preu al voltant de zero, superant en molt el cost de l'hora de programador.

Els programes s'han fet més complexos, amb més línies de codi, on cada vegada hi ha més capes i més distribució, i això fa que les tècniques de programació i testeig també hagin evolucionat. Encara tenim que picar el codi, però podem fer-ho directament a l'ordinador, no hem d'esperar per saber si el codi té errors de sintaxi o no, i això ens fa més productius i evita temps d'espera. Això no vol dir que els programador siguin ara més descuidats en el seu codi ara que abans, sinó que senzillament poden dedicar-se més ara a la funcionalitat i no tant a tenir que validar manualment que tota la sintaxi del programa sigui correcta.

Personalment no he tingut que tractar amb mainframes i amb el tipus de programació i feina de la que parlava el meu interlocutor, però tenc clar que en informàtica com en altres coses el temps passat no era millor. Potser ara el veim amb nostàlgia, però la realitat és que ara comptam amb una gran quantitat d'eines i ajudes a la programació que fan que el programador pugui destacar per la seva creativitat i coneixements i no per la seva habilitat mecanogràfica.

Amb la nova versió d'Eclipse Helios vaig donar una nova oportunitat a aquest entorn de desenvolupament. A primer cop d'ull no hi ha cap novetat espectacular, més si un no es dedica a la programació Java. La primera cosa que sobta és que no duu suport nadiu per Python, ni tan sols com a resaltat de sintaxi. D'això ja n'estava acostumant versió rera versió, però donat la gran empenta de Python dels darrers anys, pensava que Eclipse ja ho hauria inclòs entre els llenguatges més populars. Les enquestes de popularitat es fan de manera ben estranya a ca'n Eclipse.

Vaig instal·lar doncs PyDev amb la seva versió de desenvolupament, que és compatible amb Helios. Suport de sintaxi Python, depuració, autocompletat, etc. etc. Tot el que un pot desitjar, fin i tot un tímid suport per Django.

Tot aquest entorn, aquesta integració, té un preu en forma de consum de memòria. Prop de 800 MB, massa pel portàtil amb 2 GB de RAM que faig servir a casa.

El fet, però és que això fa que em plantegi el perquè d'estar provant editors per a programació. Supòs que com en el cas de les eines, sempre estam cercant la bala de plata, l'eina perfecta que ens farà més productius. O potser és perquè ens agrada tafanejar, mirar què hi ha de nou i les noves virgueries que incorpora cada nova versió de l'entorn de desenvolupament.

El fet, però, és que la productivitat no ens la donarà canviar d'eina de desenvolupament, el més segur que el canvi impliqui una pèrdua de productivitat a curt i mig plaç. La vertadera productivitat la tenim quan agafam un editor/entorn potent (posau aquí el que us agradi) i ens dedicam a conèixer-lo en profunditat, a personalitzar-lo i adaptar-lo a les nostres necessitats diàries de feina.

Una cosa tan senzilla com que l'editor ens deixi definir macros i crear plantilles pot augmentar la nostra productivitat en un tant per cent molt major que la nova rentada de cara de l'IDE i les noves icones.

Per tant, i supòs que ja ho sospitàveu, l'editor perfecte no existeix. Potser existeix un editor que s'adapta a una persona i feines concretes i que és el millor per aquesta persona en aquell moment, però tot i això, aquesta perfecció no s'aconsegueix d'entrada, sinó una vegada dominat l'editor en profunditat.

Personalment m'agrada provar nous editors i entorns, no puc evitar aquesta recerca de l'eina perfecta com si es tractàs de la font de l'eterna joventut. Però pel tipus de feina que estic fent ara crec que he trobat el meu editor perfecte: Vim i un bon munt de complements.

Però que sigui "perfecte" per mi, no vol dir que sigui perfecte per un altre. Si un fa feina fonamentalmetn amb javascript i css potser i no toca per res la consola de línea de comandes potser un Eclipse+Aptana li anirà millor, o el Notepad++ si fa feina amb Windows.

El crec que és important és decidir-se i donar una oportunitat a l'editor o entorn que vulguem utilitzar durant un temps, estudiar-lo un poc, fins i tot llegir-ne la documentació. Sols d'aquesta manera l'editor es convertirà en un factor de productivitat més.

Avui tenia visita a Evissa per a tractar l'estat d'un projecte que tenim amb una empresa d'allà. Com que mai saps que te trobaràs per la carretera, tenc la mania de partir prest, la qual cosa em sol deixar una hora de mitja d'espera a l'aeroport. Avui més d'una hora i mitja, ja que no hi havia gens de coa a facturació.

Per passar el temps res millor que la lectura, en el meu cas un llibre que vaig rebre ahir: The Lazy project manager de Peter Taylor.

Sols puc dir una cosa d'aquest llibre: totalment recomanable. No és un llibre de metodologia de gestió de projectes, ni de bones pràctiques, ni d'aquells que et diuen el bé que els va sortir aquell macro projecte. És un llibre divertit, fresc, escrit amb un estil desenfadat, irònic i pràctic.

Taylor fa us del seu anecdotari personal per contar situacions que ha viscut com a cap de projecte. Conta coses que li han anat bé i també coses que li han anat malament. Focalitza molt bé el que ha de ser la feina d'un cap de projecte: gestionar l'equip, mantenir la calma davant els problemes i deixar que la gent faci la seva feina.

D'això Taylor en diu ser un Lazy manager, però no us malfieu. Ser un lazy manager duu molta feina. El títol fa referència a una actitud: intentar que les coses es facin amb el mínim esforç, concentrant-se en el que és important per al projecte.

Taylor duu el concepte a l'extrem, al primer capítol ja te diu: eps si vols anar al bessó del llibre ves al capítol de trucs ràpids. Però us aconsello que no ho faceu, us perdríeu una lectura molt divertida.

El llibre té 141 planes de lletra a doble espai amb la qual cosa es llegeix amb un parell d'hortes. Ideal per passar una bona estona a una sala d'espera, i per bona estona em refereixo a la rialla que se us pot marcar a la cara de tant en tant llegint els comentaris que fa Taylor.

Totalment recomanable sobretot per aquells que hagin tingut algun tipus de responsabilitat en la direcció de projectes, siguin informàtics o no.

Fitxa tècnica.
The lazy project manager
Peter Taylor
Ed infiniteideas
ISBN 978-1-906821-13-5

M'agrada llegir, molt. M'agrada llegir novel·la, sobretot de ciència ficció, però també assaig divulgatiu i com no llibres d'informàtica, que són la meva afició i despesa més gran.

Sovint m'han dit perquè encara no tenc un lector de llibres electrònics. Podria contestar que per una cosa que s'anomena eròtica del paper, de que m'agrada la sensació d'espera que implica comanar un llibre i començar a fer-te la idea de quan arribarà, de si t'agradarà, de si complirà el que esperes.

Podria dir que no m'agrada dependre de que l'aparell es quedi sense bateries quan més interessant és el capítol. Que m'agrada llegir gairebé a qualsevol lloc, que no vull patir si me qued dormit i el llibre me cau de les mans, cosa que no m'ha passat mai, per cert, però sí que m'he quedat dormit amb les ulleres a la mà.

Podria dir que és perquè tenc por de tenir tots els llibres que m'interessen a un dispositiu electrònic i perdre'ls per que algú li pegui per canviar el DRM o vet a saber què.

Però la vertadera raó és molt més senzilla: el ROI no és bo. El lector electrònic que m'agrada, el d'Amazon gran està als voltants dels 500$. Més petit no li trauria prou partit, ja que també el vull aprofitar per llegir pdfs format A4.

Aquests 500$ representen un poc menys que la meva inversió anual amb llibres tècnics, així que per justificar la inversió els llibres m'haurien de sortir millor de preu, cert? Doncs no! Resulta que en general els llibres tècnics en format ebook són molt més cars que els llibres en paper. Així doncs no tant sols hi ha la despesa de l'eBook en sí, que potser seria amortitzable en el temps, sinó que la inversió no s'amortitzarà, sinó que empitjorarà per mor que els llibres que m'agradaria llegir tenen un preu més car en format electrònic que en el seu equivalent en paper de tota la vida.

És doncs una qüestió de prioritats, de saber en què m'estic gastant les euros que tant costen a guanyar avui en dia. En aquests moments el llibre electrònic sols em llevaria uns quants dies d'espera, però potser m'animaria a la compra compulsiva. Els preus per mi passats de voltes dels llibres tècnics fan que per mi i en aquests moments l'ebook no sigui una opció vàlida.

Potser hauré de tornar el carnet de geek, però és que tampoc no sóc d'allò que se'n diu en early adopter tecnològic. M'agraden els gatgets com al qui més, però no vull que aquests definesquin el que sóc.

Aquesta setmana he tocat molt poca cosa de Python i Django, el projecte que ens consumeix gran part del temps és una feina gairebé de rellotgeria però no és un projecte Python. Tot i això he fet servir Django per al prototipat d'algunes part de l'aplicació. És molt més senzill i ràpid muntar un prototip i fer-hi feina que tractar amb l'aplicació real, per molt que tenguem varis entorns de proves.

Estic revisant també els vídeos de la Djangocon Europe 2010. He vist el de Django a l'empresa, el dedicat a la testabilitat i el de GUnicorn. Aquest darrer m'ha agradat especialment ja que tenim plans per anar incorporant GUnicorn com a mètode de referència de desplegament d'aplicacions Django.

En aquests moments estam fent servir CherryPy i la veritat és que funciona molt bé. Encara que la màxima és "si funciona no ho canviïs" GUnicorn és un sistema WSGI molt més orientat a la feina que CherryPy, amb possibilitat de gestionar connexions síncrones i asíncrones. Els benchmarks que hi posen Gunicorn un poc pitjor que altres sistemses WSGI, però per notar-ne la diferència hem de gestionar un lloc web amb moooltes visites. En aquests casos el que ens puguin dir els benchmarks serveix de poc, ja que sempre s'ha d'ajustar la tecnologia al nostre cas concret.

El que té bo GUnicorn a més de l'orientació a la feina és que fa molt senzill desplegar una aplicació Django amb WSGI, fins i tot provant-la en local, està molt ben documentat i amb manteniment actiu.

Parlant d'una altra tema, dir que entenc perfectament a Ricardo quan diu que Amazon l'avorreix! El sistema de contingència que ha desenvolupat Bernat funciona molt bé. Això sí, no hi ha por que els administradors de sistemes es quedin fora feina. Es necessita un bon administrador per fer que tot rutlli, el que sí que hi ha és la tranquilitat de saber que no hi ha problemes de hardware. El valor afeget d'un tècnic d'IT és a més d'entendre com funciona Amazon AWS, crear els scripts necessaris per a automatitzar-ho tot, crear les alarmes, els tests, etc. Amazon no llevarà feina als administradors de sistemes, sols canvia el tipus i la qualitat de feina.

L'altra dia vaig posar la primera alfa-alfa del motor de reserves per hotels a l'entorn de test. Encara està molt verd per a poder-ho alliberar com a codi font, i no he tingut temps per polir alguns errors que té la prova. Per ara és un "naked dessign" on es mostren els contractes, la cerca de disponibilitat i permet modificar algunes coses. Falta documentar, no el codi, que hi està força, però sí fer una documentació amb Sphinx que faciliti entendre tot el que comporta. Si algú vol fer una ullada a l'aplicació que m'ho digui i li facilitaré l'accés.

Seguim intentant trobar un finançament mínim per donar major impuls al projecte, però encara no hem aconseguit res, així que la cosa per ara va tira a tira.

L'altra dia a una trobada es parlava de la necessitat que tenia la gent de WP de comptar amb un motor de reserves semblant al que estam desenvolupant. Crec que no és tan imporant que estigui dins WP com que es pugui fer una integració neta mitjançant cridades Rest, XML o XML-RPC.

No tenc clar quin pot ser el model de negoci d'una aplicació així: cobrar pr suport, per tenir una versió estable, per hostejar el servei?. El que sí tenc clar és que ha de ser de codi obert.

Però no tot ha de ser informàtica, he començat a llegir "Si és dolent t'ho recomano" de Steven Johnson, mentres esper que m'arribin d'Amazon UK dos llibres de gestió de projectes. Per ara Johnson m'està agradant força, té un punt de vista molt fresc respecte a com ens influeixen els canvis com els videjocs, els realities, etc. La seva teoria és que aquests canvis no ens fan més estúpids sinó tot el contrari. Quan l'acabi en faré una ressenya més extensa.

Avui precisament es complexien tres mesos des de que vaig deixar la meva antiga feina de cap de projecte web per TUI España (després a Hotelbes) per dedicar-me a un nou projecte: APSL.

És un bon moment doncs per reflexionar damunt el que suposa llançar-se a l'aventura en moments de crisi, sobre la constatació que les microempreses com nosaltres, tot i ser la gran majoria del teixit empresarial, ho tenen molt complicat pere accedir a ajudes i subvencions, però sobretot fer palesa la pau mental que et dóna fer el que t'agrada.

Potser el més detacable és la incorporació a l'empresa de Bernat Cabezas. Això vol dir que en pocs mesos hem duplicat el personal. També val a dir que això gairebé ha omplert el minidespatx. Dins l'aspecte de feina no ens podem queixar, van sortint projectes, amb comptagotes, però van sortint, i des del començament la nostra filosofia ha estat la de créixer quan ens ho poguem permetre, així que no estiram més el braç que la màniga.

Fer feina única i exclusivament amb Linux i programari lliure és molt productiu. No tenir que anar a reunions inútils i interminables ho és fins i tot més. Podem plantejar-nos solucions que a les nostres feines anteriors no seríen possibles: hem creat una solució damunt Amazon EC2 com a plà de contingència, fet screen scrapping amb Python i estam desenvolupant un petit motor de reserves de codi lliure amb Python per a hotels. I això fent el cafetet amb tranquilitat!.

Però no tot és color de rosa, la vida d'una microempresa és difícil. El primer de tot perquè has de començar des de zero. El que hagis pogut fer com a assalariat no compta. En parlàvem l'altra dia amb Juan de /IT que fa anys es trobàren amb la mateixa situació. Som les mateixes persones i amb les mateixes capacitats que quan estàvem assalariats, però hem de començar a crear portfolio i a demostrar el que sabem fer. No serveix el dir que en el nostre currículum hi ha la majoria d'aplicacions web internes i externes de TUI España, el que compta més és el que hem fet com a empresa independent.

El tema de les subvencions públiques també és una d'aquelles coses que t'indignem quan ets una microempresa. Darrerament hem intentat optar a un Plan Avanza per tal de poder accelerar el desenvolupament del motor web. La sorpresa va ser majúscula quan ens assabentaren que la inversió mínima per optar a una subvenció era de 200.000 €. Quantitat que com podreu veure queda molt lluny del que és una inversió raonable per a una organització com la nostra. Segons ens van explicar qui opta per aquestes subvencions, donat que són un 35% del pressupost, tenen tendència a inflar el pressupost i acaba essent un joc del gat i la rata entre que dóna la subvenció i que l'està sol·licitant. No puc entendre aquest joc, sols beneficia a qui té capacitat per poder inflar despeses i no a qui té capacitat per fer la feina.

Passa el mateix amb algunes organitzacions empresarials. Algunes estan organitzada a manera de capta subvencions i conformen un club exclusiu, on les quotes de participació serveixen per mantenir fora del club a les empreses més modestes.

Fa un poc de ràbia, però la veritat és que tant fa. Crec en que la feina ben feta al final donarà el seu fruit, i crec amb el creixement basat en l'esforç, en guanyar-nos els clients superant les seves espectatives. De la mateixa manera que entenc APSL com a un lloc on la gent tècnica s'hi pugui trobar bé, on a més de guanyar-se la vida s'ho passi bé fent feina. A un curs que vaig fer de l'EOI el director del curs em deia que això era una utopia, bé, potser sí, però m'agrada creure en que put trobar unicorn. I want a ponny diu la gent de Django.

Crec que els programadors, els tècnics i el frikis en general donam el millor de nosaltres mateixos quan ens deixen fer allò que sabem fer millor. Potser el temps demostrarà que jo estava equivocat, però al manco intentar fer que aquesta utopia sigui possible, i tant el client com el tècnic tenguin allò que volen i allò que necessiten és una aspiració que crec que s'ho paga com a projecte.

A l'aspecte personal, dir-vos que el meu nivell d'stress ha disminuït notablement. Sóc un passador de pena, no hi puc fer res, però al manco ara tenc la sensació de que hi puc fer alguna cosa. Que els problemes que sorgeixen al dia a dia no s'enquisten i els podem donar una solució. El que m'estressa més no és que hi hagi mota feina o problemes, això és la salsa de la feina, el que m'estressa és saber que s'hi pot posar remei i no poder-ho fer.

Arrib a casa amb la sensació de la feina feta, amb la sensació de que les hores dedicades a fer feina han servit per alguna cosa, encara que hi hagi dies on no tot surt com voldríem. És una sensació que feia molts mesos que no tenia.

He de dir que enyor molta gent de l'antiga feina. Hi vaig deixar molt bons professionals i millors persones, d'aquells que m'agradaria tenir amb nosaltres si el projecte APSL cresqués. Al Parc Bit també he retrobat antics companys de feina, molts ex-TUIS de la part de direcció i comercial que emigraren cap a projectes més engrescadors, antics companys de Viajes Iberia (gent us promet que quan no vaig tant de cul us faré una visita), companys Bulmeros i companys d'SMI.

Han estat tres mesos de mantenir contactes i crear ponts, no tant amb possibles clients com amb empreses i autònoms que tenen un tarannà semblant a nosaltres. Gent amb qui sé que podré comptar en un futur i gent que sap que pot comptar amb nosaltres.

Són temps difícils, de crisi, però també d'oportunitats. Vers la tudada de doblers que fan algunes institucions amb estudis d'estudis que estudien l'estudi, vers les subvencions atorgades a empreses que no les necessiten, potser les petites empreses com la nostra tenen la seva oportunitat. L'empresa privada s'ha de mirar molt bé on inverteix el seu capital, ha de cercar un rendiment als doblers i mirar molt la relació qualitat preu. Són temps on empreses com APSL poden tenir l'oportunitat. El temps ho dirà.

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.

Com sabeu darrerament estic fent servir VIM com a editor de referència. N'estic aprenent encara, però vull compartir un truc, millor dit, una tècnica que ens permet copiar text entre diferents instàncies de vim o entre una instància de vim i una altra aplicació Linux.

És una cosa que trobava a faltar però que fins aquest dissabte no he trobat com fer (és el que té llegir els manuals, que t'enteres de coses!).

Resulta que Vim té molts de registres de còpia i un d'ells és el registre * que ens permet copiar des de i cap el porta-retalls del sistema operatiu.

Així doncs farem:

Per copiar de Linux a Vim.

1. Seleccionam un text i feim el típic Ctrl+C
2. Anam a Vim i ens situam al lloc on volguem aferrar
3. Pitjar "*p (dobles cometes, asterisc p) i ja ho tindrem aferrat.

Copiar de Vim a Vim entre instàncies diferents

1. Ens posam amb mode visual i seleccionam el text
2. Pitjam "*y (dobles cometes, asterisc y) i ja ho tenim al porta-retalls
3. Anam a l'altra insancia de vim, ens situam a lloc i pitjam "*p com abans

Esper que us ajudi tant com a mi

Aquest és el pressupost en pessetes del que pot costar un portat de promoció i venda de productes turístics a la nostra comunitat, o el que és el mateix, a tots nosaltres.

Segons recullen alguns diaris i en paraules del President Antic:

"Será una plataforma pionera a nivel mundial que permitirá ver toda la oferta 
turística de las Islas Baleares vía 'online' y que contará con la tecnología 
de la empresa Microsoft, lo que nos permitirá adelantar en el campo de la
internacionalización de nuestros productos y nuestra oferta"

Personalment mesclar Tecnologia turística, Microsoft i Administració pública tot en un mateix paquet ja em pareix aberrant. Una empresa privada pot permetre's el luxe de comprar el que vulgui i a qui vulgui, les decisions que prengui són cosa seva i l'impacte anirà contra el seu compte de resultats (bé, excepte si ets un banc, que llavors si te van malament les coses el Govern et finançarà). Però en aquest cas estam parlat d'una administració públic, d'esquerres per més senyes, que té com a obligació vetllar pels interessos dels ciutadans i afavorir la igualtat d'oportunitats.

L'anunci, ara per ara un titular, significa per una banda ja haver decidit amb quina tecnologia es farà el portal, és a dir, haver decidit que una part considerable de l'import anirà a una sola empresa, Microsoft, participi o no en el desenvolupament final del projecte.

En Toni Roig a una contesta al via Twitter em diu que ell està content perquè es tracta el programari com a una infraestructura. Això seria veritat si les bases de la infraestructura fossin lliures. Les carreteres són infraestructures que faciliten el comerç, però pots anar d'un lloc a l'altra sense que t'imposin el cotxe i quan s'anuncia una carretera no es diu amb quina marca d'asfalt es farà ni qui en serà el proveïdor.

Anar cap a una plataforma Microsoft implica tenir infraestructures tancades, on sols hi podrà participar en la seva creació qui pagui el peatge de Microsoft. Implica fer una inversió codi no reaprofitable pel sector de les TICS i per al sector turístic.

Per mi, fer una infraestructura significa posar les bases per a que la iniciativa privada pugui desenvolupar el seu negoci i generar ocupació, dotar de serveis bàsics i eficients. Donar la canya i no directament els peixos.

Ara se'ns diu que no hi ha res decidit, però la realitat és que als mitjans de comunicació han sortit ja noms i tecnologies: tecnologia Microsoft i les empreses de Turistec. Quan la gent de fora de Turistec i lligada al programari lliure ens hem alarmat pel fet de que pareixia ja tot decidit intenten calmar-ho dient que no hi ha res lligat encara. Ens ho hem de creure? Potser sí, estic disposat a creure'm-ho però això vol dir que algú ha fet molta mala feina de comunicació i que té uns tics ben allunyats del que hauria de ser una concepció social de la inversió en TIC.

Supòs que aviat sortirà el contraposar tecnologies, el que no hi ha res semblant al que Microsoft ofereix, ... Potser sí, potser no, però si no hi és, tractar el programari com a infraestructura vol dir que el Govern no ha d'invertir en una solució finalista, sinó en la creació dels mitjans. S'inverteix en l'aeroport, en el port, en la carretera,... l'avió, vaixell o vehicle que ho posi cada un! . Crec que és aquest un dels aspectes que fan més por de tot el projecte, la diferència de concepció en el que és el paper de l'Administració Pública en els projectes TIC que volen impulsar l'economia i en com aquesta inversió ha de repercutir en la societat.

Després, en tot aquest projecte se fa una associació d'idees també molt perillosa: l'empresa privada de balears és Turistec. Perdona toniroig, potser ho estic traient de contexte, que el Twitter és molt limitat per fer reflexions, però ja ha sortit vàries vegades el nom. Voldrà dir això que per poder participar en el projecte les empreses hauran de formar part de Turistec? Creis que totes les empreses i professionals poden pagar-se les quotes del club? Té Turistec com a conjunt una postura comuna vers la tecnologia que ha d'utilitzar-se en l'Administració pública per tal de garantir el vessant social de la inversió? Permeteu-me dubtar-ho des del moment que el propi CMS de l'associació és programari tancat.

Fins ara he tractat les formes i la conclusió per mi es clara: no són formes d'anunciar els projectes, ni una concepció social de les TICs. Recorden massa a les formes Mates per sortir a la foto i els ciutadans d'aquesta comunitat no ens ho mereixem.

Anem ara als continguts i a la idea en sí. Que el Govern impulsi el sector de les TICs i el sector turístic està molt bé, que vulgui tractar el programari i les IT com una infraestructura, molt bé. Però esper que realment es faci això, que es crein les infraestructures, que tot el que es crei al voltant sigui reaprofitable i utilitzable i que les inversions que es facin quedin com a benefici per a la societat. Per mi això significa invertir en solucions obertes, en coneixement i en impulsar el reaprofitament de recursos, precisament el que implica fer les coses amb mentalitat de programari lliure.

Aquesta setmana passada vaig llegir la tèsi de Rory Tulk "Software Testing Techniques, an Empirical Approach" de l'Universitat de Toronto (una vegada més gràcies a Jordi Cabot per publicar l'enllaç). La tesi es pot trobar via la plana de Rory o bé descarregàr-se-la directament.

Rory investiga damunt les capacitat de testeig segons el grau de maduresa tècnica de qui fa el testeig. La hipòtesi és que els tècnics més experimentats són millors testejadors que els juniors. És un treball que s'ho paga llegir per la pròpia estructura de la tesi i veure com s'ha conduit l'experiment.

Però el que més m'interessa del tema són les conclusions: l'experiència no té massa a veure amb el nombre d'errors trobats però sí que pareix que té a veure amb els tipus d'errors que es troben. Encara que el nombre de casos estudiats fa que les conclusions no siguin estadísticament significatives, sí que entronca en les pràctiques més o manco habituals de fer que sigui una persona diferent de la implicada en el projecte de desenvolupament la que provi els programes, ja que sovint descobreix errors que s'han passat per alt als desenvolupadors, que en teoria són més experimentats trobant-los.

D'aquí una possible conclusió seria que els equips de testeig i qualitat han d'estar formats tant per gent senior com per gent menys experimentada, de manera que es puguin complementar mútuament. Això vol dir, però que hi ha d'haver una rotació en els equips de testeig, ja que en cas contrari així con els juniors es vagin convertint en programadors experimentats tendran tendència a trobar uns tipus d'errors concrets, i no provar coses que d'altra manera, sense els condicionants de l'experiència provarien.

L'altra conclusió marginal interessant és el bon funcionament de la lectura del codi com a eina per a la detecció d'errors. Segons Karl E. Wiegers autor de Peer Reviews in Software un lector experimentat de codi pot arribar a caçar fins al 90% d'errors en el codi. Dins l'estudi de Rory precisament qui té la taxa de detecció d'errors més grans és una persona que va fer servir el mètode de llegir el codi per a detectar els errors.

Una lectura interessant i que convida a reflexionar, ja que comença a donar una base per a estudis posteriors. El testeig no és, com moltes branques del desenvolupament, una ciència exacta, però el que pareix clar és que els equips de testejadors han de ser diversos en la seva manera de veure les coses i que no basta una manera de testejar. I tot i això segur que quedaran errors sense caçar, per saber més o manco quants ja sols ens queda anar cap a mètriques estadístiques com les corbes S o les corbes de Rayleigh. El Software Mesasurement and Estimation de Lida M. Laird an Carol Brennan ten té un bon grapat de mètodes estadístics.

Com a conclusió addicional: convé registrar els tests que es fan, els errors que es detecten i estudiar-los, no com a via per a premiar els testejadors (el típic de condicionar un pagament d'objectius) o de penalitzar els desenvolupadors, sinó com a manera d'estudiar estadísticament els tipus d'errors que s'estan trobant i poder saber quan convé renovar par de l'equip de testeig. L'estar en un equip de testeig per exemple podria ser part de la carrera professional d'un programador.

Un link passat per Jordi Cabot al Twitter anomenat Asshole driven development em fa recordar el complexe que és la interacció humana en la gestió de projectes.

Quan més gran és una empresa més possibilitats hi ha de veure's reflexat en una de les definicions que fa Scott Berkun, més que res per una qüestió de probabilitats. Personalment m'he trobat molt amb el Cover Your Ass Engineering (CYAE) ja que és el típic que es presenta quan enfrontes una solució de codi obert amb una solució propietària a un gestor més preocupat pel seu lloc de feina i cobrir-se les esquenes si hi ha el mínim risc, que per les possibilitats de benefici real de l'empresa.

L'_Asshole Driven development (ADD)_ realment m'ho he trobat poques vegades, més que res perquè quan m'he trobat en situacions on els tirs anaven cap aquí he preferit anar cap a opcions alternatives. Ja sabeu que em costa molt combregar amb rodes de molí, i l'ADD és precisament això: fer les coses no perquè són tècnicament correctes o millors per l'empresa, sinó perquè qui mana (que no és normalment l'amo de l'empresa) diu que s'ha de fer ell que ell diu i punt.

El que sí m'he troba sovint són dos estils d'entendre la gestió de projectes i la pròpia feina del cap de projecte. M'explicaré:

Per mi l'objectiu d'un projecte informàtic és sempre aportar valor a l'empresa. És a dir hi ha d'haver un benefici mesurable en el projecte, ja sigui benefici en imatge, en menor temps de feina intern per fer les coses, en un major control o el millor de tot, un benefici real en termes de negoci.

Partint d'aquesta base entenc la feina d'un cap de projecte de desenvolupament com el d'aquella persona que s'ha d'encarregar de coordinar la feina, relacionar-se amb el client i sobre tot, de prendre decisions. L'important és estar focalitzat en que la feina surti i representi un benefici pel client i per això el cap de projecte ha d'eliminar els obstacles que es presentin per tal que la gent que fa feina en el projecte pugui fer la feina que millor sap fer.

Això vol dir no convocar a reunions multitudinàries als membres de l'equip quan aquestes no aporten res. És encarregar-se d'anar a parlar amb altres departaments, amb el negoci, dur el control administratiu del projecte, fer el reporting. És a dir, totes aquelles coses que formen part de la cerimònia del projecte i que mal duites poden impedir als membres "productius" fer la seva feina.

Amb aquesta filosofia entenc que el cap de projecte ha de posar tots els recursos a la seva disposició per dur bon terme el projecte. Si el programador té problemes amb una rutina o amb el llenguatge ha de mirar de solucionar-los, bé ell mateix o cercant algú que ho pugui fer. Alguna vegada m'han dit que donar suport als programadors no és la meva feina i n'estic en total desacord. La feina d'un cap de projecte és precisament aqueixa: donar suport, i si aquest suport significa resoldre un dubte de programació, depurar en conjunt un algorisme on algú s'ha quedat enrocat, s'ha de fer si es tenen els coneixements i l'oportunitat. Perquè per damunt de tot el cap de projecte està per eliminar obstacles i donar solucions. Si un projecte ha de sortir i no puc ajudar més que en dur els cafès doncs millor llevar-se d'enmig i demanar a la gent pel sucre que vol i si els vols sols o tallats.

L'altra estil de gestió és òbviament el contrari: reunions per pressionar la gent, reunions per repartir culpes i concentració del cap de projecte en la cerimònia, és a dir, gestionar concentrant-se amb el com i no amb l'objectiu final.

Perquè està clar que tot projecte pot fallar, per les causes que siguin. Però quan falla l'excusa no pot ser anar cap a un Cover Your Ass Engineering (CYAE) i establir mecanismes burocràtics i de control absurds per a que no tornin passar les coses, sinó cercar la causa de base del problema i solucionar-la de manera que afecti de manera mínima a la cerimònia del procés.

Si un programa falla perquè no s'ha pogut provar, la solució no és tenir que redactar un document a casa passi a producció on l'equip de programadors certifica que està bé, el testejador certifica que ha provat l'aplicació i el tècnic certifiqui que ha passat el pegat que li han dit; sinó demanar-se perquè no hi ha tests unitaris, perquè no hi ha (o han fallat) les integracions contínues. Potser el que ha fallat és que la gent no té prou formació per a realitzar bons tests. Massa cerimònia mata la creativitat i far perdre l'objectiu del projecte, formar a la gent fa millors professionals.

Tot són estils de gestió, jo sé el que m'agrada i intent posar en pràctica, adaptant l'estil de gestió al client, al projecte i a l'equip. Els programadors no són els curritos del cap de projecte de torn, és el cap de projecte el qui ha de fer feia pels tècnics i programadors i procurar que ells puguin fer la seva feina.

Ahir vespre me va pegar per instal·lar l'Ubuntu Netbook Remix al Dell Latitude 2100 que vaig comprar fa uns mesos.

No l'havia actualitzat de versió i vaig trobar que era una bona ocasió per provar tant la creació d'una distribució en un USB com la pròpia distribució Netbook, a veure si aprofitaria millor l'espai.

Amb la configuració de fàbrica i una vegada instal·lades les utilitats bàsiques de programació em quedàven uns 3 GB de disc lliure dels 16 GB. Això implica tenir que anar alerta amb els documents que es decarreguen, fer neteja de tant en tant del projectes, etc.

Tampoc era res greu. Quan un compra un Netbook ja ha de ser conscient amb un disc d'estat sòlid de 16 GB es tindran unes limitacions d'espai que no hi ha a discs de Tera en que surten ara alguns ordenadors de sobretaula. Per mi el Netbook representa la mobilitat, té un configuracio mínima per fer feina i em permet dur-ho a la motxilla carregant 3 kilos menys que amb l'altra portàtil. Una eina per a cada feina!

Així que dit i fet!

• Baixam la distribució Ubuntu Netbook Remix
• Posam un llapis USB (que formatejarem així que al tanto amb les dades que hi teniu).
• Executam el programa usb-creator-gtk, que ens demanarà l'ISO d'origen i l'USB de destí i formatejar l'USB destí. Ho feim i seleccionam la partició de l'USB. Nota mental: el diàleg de l'usb-creator es petit i no es veu la partició amb la qual cosa quedava seleccionat tot el disc i em deia que no hi havia espai lliure. Quan fas la instal·lació a les dues del vespre en el darrer que pensava jo era en redimensionar la finestra! :) Així que fora fer aquestes coses amb són.
• Anam al Netbook. En arrancar pitjarem F12 per entrar a la configuració i canviar l'ordre d'arrencada per a que agafi primer l'USB. En acabar hem de pensar en deixar-ho tot igual. En el meu cas perquè tenc a més una tarjeta SD de 4GB addicionals i no vull que perdi temps en arrancar cercant el sistema operatiu que ja sé que no hi és.
• Una vegada arrancat amb l'USB ja sols es cosa de dir-li que instal·li. Li deim que faci servir tot el disc (es perdran totes les dades!) i a esperar una estona.
• Quan acaba la instal·lació tornam a deixar la prioritat de dispositius d'arrancada amb el disc dur com a primera opció i realitzam un sudo apt-get dist-upgrade per deixar el sistema amb totes les actualitzacions i pegats.
• Després convé actualitzar els controladors de maquinari per a que ens vagi millor la tarja WIFI.
• Gairebé ja està. Sols configurar les aplicacions preferides i instal·lar vim, virtualevn per Python, Chrome, yolk, git, shutter i trapassar la configuració de Vim. Amb això ja tenc un entorn de feina més que complet.
• Com que el Dell 2100 té pantalla tàctil convé fer-ne la configuració. Cosa de cinc o deu segons tocant creuetes i després ja tindrem un entorn on les aplicacions es poden engegar amb el dit i amb 11 GB liures.

La distribució per ara i amb poc menys de 5 hores que duc amb ella pareix força usable amb la pantalla tàctil funciona molt millor que amb la versió de fàbrica de Dell. Això sí ens hem d'acostumar a la manera de presentar les aplicacions: totes surten a pantalla completa, que amb el poc espai que hi ha disponible tampoc és cap mala cosa, però es fa un poc estrany al principi.

L'autisme es caracteritza per una escassa interacció social, problemes en la comunicació verbal i no verbal, activitats i interessos greument limitats, inusuals i repetitiu. Viquipèdia

Aplicat a l'activitat laborar podem parlar de l'oficina autista, aquell entorn de treball en que les condicions ambientals, d'organització i de feina fan que la gent es retragui en ella mateix, minimitzant la comunicació i la interacció a nivells mínims, interessant-se sols pel que passa pel seu redol i intentant frenar i minimitzar qualsevol tipus de canvi.

Un dels símptomes de l'oficina autista és entrar i veure que molta gent té els auriculars posats i es sent el remor de la música sonant a les seves orelles. Això i un entorn renouer i amb una densitat de gent molt gran.

De Marco a Peopleware ja tracta el problema de la densitat de gent i la productivitat. Encara que una persona pugui fer feina en un espai reduït, posar molta gent mantenint la proporció d'espai fa que el renou i la sensació d'agobi augmentin. Suposem que una persona necessita 5 m² per fer feina, no és el mateix tenir 4 persones a un despatx de 20 m² que tenir 40 persones a una oficina de 200 m², la quantitat d'interaccions, renous, gent anant amunt i avalls, ... La productivitat es ressent.

Els tècnics però som gent que ens agrada fer feina i que la feina surti. De Marco diu que en aquests casos la gent intentarà fer feina de la millor manera que pugui, escapant-se a sales de reunions i a altres espais menys problemàtics. Avui en dia tenim tota casta d'aparells electrònics que ens permeten aïllar-nos d'un entorn poc apte per a la feina.

Aquest aïllament, però, té un problema fonamental, l'oficina es converteix amb una oficina autista. La gent no participa del que es cou ni tant sols amb el seu grup de treball. Els comentaris i la comunicació informal no existeixen. Per comunicar amb la gent del mateix equip i que està a pocs metres es necessari l'enviament d'e-mails i convocar reunions. La productivitat decau, es perd la sensació d'equip i de grup.

Potser algú ara dirà que ell es posa els cascs perquè fa feina millor amb música. Això no hi té res a veure, encara que trobem estudis que diguin que això no és veritat en tasques que requereixen molta concentració també segurament en trobarem que diuen tot el contrari. Aquests tipus d'estudis poden estar desviats per mor del que s'anomena Efecte Hawthorne. El fet però, que fins i tot en els casos de que hi pugui haver un petit augment de la productivitat personal, es perd la productivitat del grup, que és molt més important.

Si l'oficina és autista és quelcom que s'ha de millorar. Si no ho és hem de procurar que no s'hi convertesqui (sobretot si no hi ha factors ambientals associats). La comunicació ha de ser fluïda, les comunicacions formals s'han de deixar per coses formals. Si volem gaudir de la productivitat i eficiència que dóna fer feina amb grup hem de crear els factors ambientals que la facin possible. Si els factors ambientals són bons, no hi ha excusa per a deixar que l'aïllament autoimposat impedeixin una comunicació eficaç.

Tercera edició del creant bits, aquesta vegada amb un convidat d'excepció, Ricardo Galli, quen ens xerrà de como havien passat el meneame des d'una instal·lació clàssica a una configuració damunt Amazon AWS.

Com sabeu gràcies a la iniciativa del Parc Bit, a les empreses incubades com la nostra, APSL ens deixen disposar d'algunes sales per a les reunions, conferències, etc.

A les 14:15 aproximadament arribàrem al Parc Bit i la gent de seguretat ens obrí la sala. Deixàrem els portàtils i començarem a deixar llesta la sala. En Guillem, el tècnic, del Parc Bit i el personal de seguretat com sempre ens donaren totes les facilitats possibles, sense ells iniciatives com aquesta tampoc serien possibles.

L'aforament de les sales és limitat, però tot i estar un poc estrets i després de reordenar cadires i taules sortírem a menjar un poc. Entrepà ràpid i a les 15:30 a la sala a deixar les quatre coses que faltaven llestes: aigua, caramels i com no les gominolas que s'estan convertint en una tradició. Potser l'associació de dentistes i dietistes ens hauria de patrocinar alguna jornada, després de tot els durem molts clients! :)

Arriba Ricardo i comprovam que tot va bé. Vol fer l'experiment de fer streaming de video amb Ustream des del mòbil amb Android. Jo també havia fet experiments a casa amb el meu i es veia prou bé, però no n'estava del tot convinçut.

Al final podem configurar un "soport", mont un bastiment amb els seu mòbil amb una capseta per dur els disc dur portàtil. El disc dur fa de contrapès i la capsa té el tamany ideal, connectam el cable d'alimentació per USB al portàtil d'En Pau, que ens dona l'autonomia que necessitam sense tenir que passar allargadors per les taules.

La sala està plena, l'atenció és màxima, En Ricardo es un crack explicant i contant les coses. La gent pel twitter ens diu que l'streaming va prou bé. Fantàstic! Així ho podrem anar fent a propers actes.

La xerrada amb Ricardo no pot ser més interessants: aspectes tècnics, aspectes de configuració, exemples, aspectes econòmics i projeccions de futur.

Particularment de la xerrada he sortit amb idees addicionals:

• fer servir un entorn al núvol com a entorn de desenvolupament i proves
• entorn d'integració contínua. El Hudson per exemple permet distribuir la càrrega en molt de servidors. L'AWS ens permetria passar els tests d'integració amb un temps molt curt a un preu més que raonable.
• Consolidació de servidors. A partir de 4 servidors dedicats (segons els meus càlculs) és econòmicament rentable anar cap al núvol, no hi ha pràcticament diferència de preu i l'escalabilitat i flexibilitat és molt gran.

Qued estorat de les capacitats de l'AWS, del ben pensat que està tot. Està fet per ser usable i provat en condicions reals, la de tenir que escalar un lloc web com Amazon. La gent d'Amazon ha convertit una despesa en un negoci. Ells haurien de tenir quelcom semblant a l'AWS per el seu propi lloc. Amb un cost marginal que supòs que deu ser molt baix han creat un negoci nou.

També me n'adon del que està passant: Ricardo ens està contant no tan sols com ho han muntat amb pels i senyals, sinó que a més ens diu les dificultats que ha tingut, els perquès de cada cosa i ens presenta els cost real del que paguen, desglossat amb cada concepte. No és gens habitual i és una cosa més que fa que la xerrada sigui tant interessant.

Acabam com a quatre hores després. La xerrada ha estat molt bé, hem après coses noves i ens hem divertit. Què més es pot demanar?

Gràcies a tots els que heu vingut al Parc Bit a compartir un horabaixa amb nosaltres, als voluntaris que ens han ajudat a muntar i desmuntar i a tots els que ens heu segui per Ustream i el twitter, i obviament moltes gràcies a Ricardo per ser així com és i compartir amb nosaltres la seva experiència.

Enllaços

El hashtag de la jornada ha estat #creabits o bé i gràcies al cromo de DZPM twetchat, el genèric és #creant_bits.

Els vídeos: video de la primera part i a video de la segona part i la presentació en pdf.

La frase "I will code for food" és un acudit que un és pot trobar referint-se al mal pagat que estam la gent que es dedica a la informàtica en general, i també per a indicar que un programador vocacional pot voler fer la seva feina a canvi de no res (i el problema és que sovint ho fa).

En el meu cas el code for food s'estava convertint en una sensació. La sensació d'estar de florero i de estar a un lloc veient passar les hores sols per a poder dur un sou a casa.

No ho puc fer jo això. Potser me trobaré amb la necessitat del "I will code for food", però la realitat és que m'agrada massa aquesta professió com per a ser un simple espectador, així que ha arribat l'hora de emprenndre noves aventures i deixar una pseudo-comoditat per anar cap el desconegut, cap a l'aventura de dur endavant nous projectes i reptes.

No puc dir que per una part no em sàpiga greu, he conegut gent molt bona durant aquests sis darrers anys (i també vertaders ineptes, tot s'ha de dir) i estic encantat l'equip de gent amb la que he fet feina, des de la gent que em va aguantar en els temps difícils de reestructuració com a cap de suport i instal·lacions, fins als distints equips de gent que m'han tingut de cap de projecte de desenvolupament web. Hem fet moltes coses, duit a terme molts projectes, hem rigut i ens hem indignat plegats, ... És una experiència que m'ha enriquit com a persona, perquè se'ns dubte, de la professió el més important no és la tecnologia en sí, ni els ordinadors més o menys ràpids, el més important és la gent.

En la nostra cultura no estam acostumats a que la gent deixi una feina segura, potser perquè internament hi ha molta gent que aspira a ser funcionari. Personalment crec que deixar una feina (tenguis o no un altre projecte) ha de ser una decisió meditada, però que ha de ser una opció que ha d'estar allà. Consider que una feina com la informàtica pot i ha de ser quelcom més que una feina, jo l'entenc com a una vocació.

Deix una feina "segura" perquè em va la marxa, perquè vull sentir-me bé amb jo mateix, perquè m'agrada massa la feina que he triat com a professió, perquè vull aixecar-me als matins amb ganes d'anar a fer feina i no amb la sensació que he d'anar a passar l'estona a una cadira. Vull que la meva feina servesqui per a generar negoci, tenir el convenciment de que el que faig contribuirà a donar valor. Potser és mal d'entendre però cada un és com és.

Eps! I'll code for food :)

Avui he acabat de llegir Agile Estimating and Planning de Mike Cohn. És un llibre dens, d'unes 300 planes plenes de bons consells, gràfics, fórmules i metodologia.

Encara que el títol fa referència a l'estimació de projectes àgils, més aviat diria que és un manual de metodologia àgil i en especial d'Scrum. Tenc llibres dedicats a Scrum que no són tan instructius com ho és aquest.

Cohn ensenya la distinció entre estimar tamany i durada i introdueix molt bé el concepte scrum de la velocitat de l'equip. Però sobretot es concentra en una idea molt clara: l'important no és l'estimació en sí, sinó en donar valor al negoci, per això dedica 4 capítols a la priorització i a la orientació cap al retorn de la inversió i la generació de valor. Potser són els capítols més densos del llibre, però marquen la diferència d'aquest llibre amb d'altres. Segons la nomenclatura de marketing ho classificaria com un excitement, quelcom que no m'esperaba trobar així i que m'ha sorprés gratament.

De la penúltima compra que vaig fer és de ben llarg el llibre més interessant. Fa estona vaig acabar el "Behind the closed doors" i encara que està bé, aquest és un llibre que l'eclipsa, tant per la manera que té Mike Cohn de plantejar els temes com per la quantitat d'inforamció útil que ens proporciona.

Altament recomanable per tots aquells interessats en les metodologies àgils.

Fitxa tècnica

Agile Estimating and Planning
Mike Cohn
Ed. Prentice Hall
ISBN: 978-0-13-147941-8

Ahir en Jordi Cabot em demanava l'opinió per Twitter dels IDEs, ja que hi ha gent que vol fer el que s'anomena web modeling tools, és a dir, passar les eines de modelat a un entorn Web.

Jordi no n'està massa convençut de la idea, ja que per exemple, els IDEs de programació per web no pareix que tenguin tirada, i fins i tot molta utilitat en aquests moments.

Particularment els llenguatges de modelat com l'UML m'agraden com a eina comú per a comunicar idees i no com a una eina per a la generació d'aplicacions completes. Veig utilitat a les eines de modelat web quan hom tengui entorns dispersos i col·labortius, on aquestes eines, amb un llenguatge simbòlic comú, serveixin per a definir i comunicar conceptes i tasques. Això no seria més que una pissara col·laborativa potenciada amb eines per fer més fàcil el dibuix. Ja està prou bé tot i així.

Actualment hi ha un grapat d'eines web per a la construcció de wireframes, interfícies d'usuari on l'important no és el disseny final, sinó la col·locació de cada component i la idea general de la interfície. Aquestes aplicacions son prou sofisticades, però no tenen massa a oferir respecte aplicacions com Pencil si no és per seva manca d'instal·lació i el tenir els dissenys a la web. Manca però el que es pugui fer un disseny realment col·laboratiu, on tothom pugui aportar idees damunt el mateix disseny, que és el que afegiria vertader valor a aquest tipus d'eines.

En el cas dels IDEs no es tracta sols de comunicar, es tracta de codi que s'ha d'escriure. Encara que es pot argumentar que un programador es passa més temps pensant i depurant que escrivint codi, el cert és que tenir un bon editor és fonamental. Per mi aquí el que és fonamental és tenir control del codi i poder treure el màxim suc de l'editor i de l'entorn.

Amb això vull dir que per defecte defuig de llenguatges de programació que m'imposen un editor o un IDE concret i que no s'integren amb un control de versions obert com subversion (com a mínim). L'IDE no importa, és que importa és el codi i el llenguatge i les restriccions que aquest imposa a l'hora de desenvolupar.

Els IDEs tenen de bo que ens donen la feina de triar les eines feta: editor, depurador, control de versions, tot ben integrat si hi ha sort, de tal manera que no fa falta canviar de programa per fer les tasques més habituals i això representa una bona ajuda per aquells que s'atraquen per primera vegada a un llenguatge de programació. També es força habitual que els IDEs editors molt potents, amb autocompletat, gestió d'arxius, cerques avançades, etc. És a dir, ajudes a la productivitat que ens poden anar molt bé.

Però hem de ser conscients que tot això té un preu: els IDEs són feixucs, consumeixen molts recursos de màquina i poden no donar-nos totes les característiques que volem: el depurador pot ser massa simple o no funcionar, estar limitats a un llenguatge de programació, no ser compatibles amb el nostre control de versions...

Aquests tipus de limitacions segurament no la trobarem a editors com Vim, o Emacs o semblants, ja que es limiten a les tasques d'edició i miren d'arribar al nombre més gran de llenguatges possible. Les eines de depuració o control de versions queden fora, se n'han de fer servir d'externes. Això no representa massa problema per gent acostumada a fer feina en entorns Unix, però sols representar un entrebanc important per la gent que sols fa feina amb Windows i en que anar a la consola pot representar un vertader trauma.

Particularment m'agraden els IDEs i els faig servir més o menys en funció del llenguatge i del programa que estic fent. Per a escriure Python faig servir Netbeans o Ulipad darrerament, per Java fonamentalment Eclipse, perquè m'agraden les ajudes que tenen, fent-me la vida més fàcil. Però tot i agradar-me procur no dependre'n i moltes vegades acab amb el vim com a editor, encara que sigui sols per mantenir el múscul actiu.

El que no m'agraden són els IDEs de programació que t'amaguen el que hi ha per davall, que no et deixen anar al codi o que es guarden el codi (como el PL/Forms d'Oracle). Però fixau-vos que no és culpa dels IDEs, és per pròpia construcció del llenguatge de programació, l'eina és sols un reflex del que hi ha per davall.

Per mi no és tan important l'eina que es faci servir per editar el codi com que aquesta no vulgui tenir el monopoli del codi editat. El codi ha de poder modificar-se independentment de l'editor, ha de poder posar-se en un control de versions, hem de poder saber els canvis que se n'han fet.

Les eines gràfiques de generació de codi (que alguns venen com a els nous IDEs) ens amaguen el codi, la visualització del que fan és molt complexe quan les tasques a realitzar van més alla dels exemples bàsic i fan molt difícil saber què s'ha canviat i a on, i el treball en equip es coordina bloquejant la tasca dels altres. Aquests IDEs no m'agraden. Poden significar un augment de productivitat inicial, però no escalen bé en programadors i representen una hipoteca tecnològica (i sovint pecuniària) de la qual n'hem de ser ben conscients.

Com a programador estic sempre a la recerca de l'eina perfecte, que em permeti desenvolupar programés més ràpid i ser més productiu, però hi ha coses a les que no puc renunciar: al control del codi, al control de versions i sobretot a poder canviar d'eina quan jo vulgui.

Atenció:

La inscripció es tancada. Hem superat el màxim de la sala i estarem estrets :) El comentari número 31 marca el límit, a partir de pacoros ja no n'hi caben més!!

N'Andrés ens ha creat el link al Google Calendar, aprofitau-ho per no oblidar l'edeveniment.

Si algú per les raons que siguin al final no pot venir per favor que ho digui i així donam l'oportunitat a altra gent.

Gràcies a tots!

L'any comença fort i interessant!

Moltes vegades m'haureu sentit dir que la gent que programa ha de tenir coneixements d'arquitectura de maquinari (i a la inversa). Els projectes web no són sols programació, sinó que són el resultat de la unió, de l'equip.

Per això em complau anunciar-vos un nou creant bits, aquesta vegada dedicat a sistemes. Encara no hem tancat les presentacions, però sí que us puc avançar que comptarem amb la presència de Ricardo Galli, que ens parlarà de primera mà de com Menéame va migrar al núvol d'Amazon.

Creant Bits al Núvol

Dia: 5 de febrer de 2009

Lloc: Parc Bit, sala de premsa. Carretera de Valldemossa, Km 7,5 Palma

Horari: començam a les 16:00

Presentacions:

• Meneame al núvol
• per concretar.

Organitza: APSL

Agraïments: Al Parc Bit, que ens deixa la sala i molt especialment a Ricardo.

Google Calendar

Com apuntar-se?

Deixau un comentari a aquest apunt. Teniu en compte que la capacitat de la sala és limitada, podem arribar com a molt, molt a 30 persones.

FAQ

• Hi haurà streaming? Per ara no. Muntar saraus amb streaming y demés implica mobilitzar a molta gent. moltes coses que poden fallar, molts nirvis. Fem-ho fàcil i podrem seguir.

Aquesta vegada, també fora catering! :-P

El 2009 ja gairebé s'ha acabat, així que com és habitual convé fer un poc de recapitulació del que ha estat l'any 2009 i definir el que esper del 2010.

Trespams

Sense haver acabat l'any aquest és l'apunt que fa 77, això vol dir que ha estat un any prou constant en el que és la publicació d'apunts en el blog, . M'agrada escriure, em relaxa i em permet posar idees en clar. Si a més aquests posts serveixen a algú més, encara que sols sigui per passar l'estona, crec que s'ho paga el petit esforç de posar-se davant l'ordinador i teclejar.

En aquest moments Trespams té uns 900 visitants més o manco habituals. D'aquest n'he pogut desvirtualtitzar un tant per cent molt petit, potser un 10%, alguns han deixat comentaris i hem pogut mantenir converses virtuals tant pel blog, correu o Twitter. Per mi és una de les experiències més gratificants del blog: poder compartir idees i pensaments amb comunicació bidireccional.

Des del principi el blog ha estat per mi essencial a l'hora de posar en ordre les meves idees i dèries. La gestió de projectes, la gestió d'equips de programació, l'estimació de projectes de programari, Python i Django. Tot sempre amb un fil conductor comú: el programari lliure.

El blog vol ser també part de la meva petita aportació al moviment del programari lliure. Programari lliure per mi significa no sols compartir codi, sinó compartir idees de com podem crear i gestionar aquest codi, eines, idees, ... El coneixement ha de fluir per a que tots com a societat ens en puguem beneficiar.

Python i Django

Per Python i Django també ha estat un bon any. Ha sortit l'esperada versió 3 de Python i Django ha assolit una velocitat de creuer que el consolida com un dels bastiments de referència en la programació web moderna. La llista de Django té uns 15.000 subscriptors, al repositori de projectes de Python, PyPi hi ha una cinquantena de projectes i actualitzacions de projectes diàriament.

Esper que el 2010 torni a ser un any Python, projectes com PyPy i Unladen Swallow poden donar encara més empenta a aquest fantàstic llenguatge. Esperem que l'onada Python arribi també a les empreses per a que tots ens puguem gaudir d'una programació més clara, mantenible i sobretot divertida, on el llenguatge no sigui un condicionant sinó un vehicle per a la creació de programes i la generació de valor per al negoci i en definitiva per a la societat.

Pel 2010 l'objectiu és anar creant més exemples a Appfusedjango, millorar-ne la documentació amb Sphinx. Voldria també millorar el codi d'aquest blog, fer-lo més accessible als dispositius mòbils. M'agradaria poder fer aportacions al projecte Basie, un projecte amb el qual he pogut coneixer noves formes de col·laboració, de control del codi, d'eines, nova gent.

Tot això farcit d'apunts en aquest blog, com a manera de presentar el que m'agrada, d'animar a la gent a participar, i com ja he dit, com a manera d'ordenar les meves pròpies idees. Es presenta doncs un any 2010 força interessant.

Creant Bits

Creant bits és la demostració del que es pot fer quan les idees es converteixen en accions. Un petit comentari al Twitter i la col·laboració de molta gent va fer possible que una vintena de persones ens trobàssim al Parc Bit per parlar de tecnologia, de Python i de Django.

La meva intenció és repetir-ho al llarg del 2010 i més si tenim disponibilitat de Sala. En aquests moments i baix el paraigües d'APSL tenim accés a les sales de formació del Parc Bit i convé aprofitar-ho. Quan no hi tenguem accés ja veurem que feim, però m'agradaria que fos quelcom que anàs perdurant en el temps fins que el cos aguanti i la gent no es cansi.

L'altra dia per un comentari que vaig fer al Twitter d'un curs de Python se'm va demanar si Creant Bits seguiria essent gratuït. La resposta es sí, Creant Bits és una aportació al moviment del programari lliure, com ho poden ser alguns dels apunts del blog, o altres projectes en els particip. No crec que es pugin considerar cursos en el sentit que l'objectiu del Creants Bits no és que la gent surti amb un coneixement profund de la tecnologia, sinó el de presentar el que es pot fer, parlar, reunir-nos i animar a la gent a provar coses, donant-los el primer impuls.

Els cursos sí que els cobr. Quan una empres em demana un curs de Python i Django els objectius és que la gent que participi surti amb un domini del temari que els faci ser productius una vegada acabat el curs. Són moltes hores de curs i moltes hores de preparació per la meva part. L'horari del curs, la localització i els assistents són responsabilitat de l'empresa que em contracta i és aquesta qui fitxa els objectius.

A Creant Bits ens reunim amics i coneguts, gent que ja ens coneixem de manera física i virtual o que tenim ganes de conèixer-nos, amb ganes d'aprendre coses i relacionar-nos. Potser al llarg del temps i amb diferents trobades la gent que participa es veurà amb un coneixements semblants als que tindria amb un curs formal, però això serà tant per l'impuls de la xerrada com per la seva iniciativa personal, i això crec que és la diferència fonamental amb un curs. A un curs vols que la gent surti preparada amb tants coneixements com sigui possible en un temps raonable, a una trobada com Creant Bit a mi el que m'agradaria és que la gent sortís amb motivació per poder començar, amb una petita llum a la foscor, que permeti, amb el seu esforça personal, avançar en el món del programari.

M'estic extenent molt amb aquest tros, però és que veure tanta gent reunida perquè sí per mi ha estat molt important, ja que ha representat passar del món de les idees al món de l'acció, del món de les intencions als fets. L'injecció de moral per mi (i esper que per als participants) ha estat grandiosa i tenc ganes de repetir l'experiència al 2010.

APSL

Al 2009 hem consolidat APSL, l'empresa de la que són CEO i soci. És una empresa atípica, feta a la nostra manera d'entendre els projectes, amb l'ètica al davant, sense voler tenir clients captius sinó essent-ne col·laboradors. Volem fer partíceps a les empreses del que significa el programari lliure, de com les coses es poden fer d'una altra manera fins i tot amb els pressuposts.

Estam intentant rompre amb la idea de pressuposts tancats per a projectes de programari. Creïem amb la idea de que el pressupost inicial ha de ser orientatiu, que després el que importa és que el programa que s'entregui representi el que necessiti l'empresa, que no és necessàriament el que l'empresa vol a l'inici del projecte.

No és una tasca senzilla, representa canviar un poc les regles del joc. Actualment les negociacions d'un projecte sempre estan encaminades a que el risc del projecte ho assumeixi una de les parts. El client intenta que sigui l'empesa desenvolupadora la que assumesqui el risc intentant tancar el mínim possible. L'empresa de programació intentant minimitzar el risc mirant de tancar-ho tot i de protegir-se en el pressupost. És una situació un tant perversa, en la qual tothom hi perd en un moment o l'altra, com en una ruleta russa.

Tot projecte té un risc i aquest hauria de ser compartit i minimitzat. Creim amb la idea d'Scrum com a metodologia de desenvolupament i com a manera de facturar a un projecte. El client assumeix un cert risc: el pagament anticipat d'una quantitat i l'empresa n'assumeix un altre: que l'empresa en qualsevol fita del projecte pugui tancar-lo, dient que el que té ja és el que volia o donar-lo a un altre proveïdor.

El 2010 m'agradaria que fos un any de creixement per APSL perquè voldria dir que aquesta filosofia de treball i gestió ha estat entesa, que una altra manera d'entendre la relació empresa-client és possible.

Gestió de projectes

A 2010 m'agradaria aprofundir en el tema de l'estimació de projectes des d'un punt de vista col·laboratiu. Una de les mancances que tenim com a col·lectiu és que estam massa encaixonats dins la nostra manera de veure les coses, potser sense tenir massa idea del mercat. Són les nostres estimacions raonables? Són les nostres maneres de pressupostar adients? Som competitius? Podem fer alguna cosa per millorar les nostres estimacions?

Crec que es un punt amb la cooperació hi té molt a dir. On podem col·laborar explicant projectes, explicant el perquè de les valoracions i el temps total, per a que serveixin de referència. També es podrien organitzar sessions d'estimació àgil, amb Planning poker estimation. És una idea a la que estic donant voltes però que encara no sé molt bé com organitzar.

També m'agradaria posar en marxa algun tipus de projecte col·laboratiu local, potser lligat al Creant Bits, que servesqui no sols per aprendre sinó també per tenir un producte que pugui beneficiar-nos a tots.

Moltes idees i molts projectes que m'agradaria fer. Tot això s'ha d'acompassar necessàriament amb la dedicació a la família, amb els projectes alimenticis i amb altres projectes que no estan lligats a la informàtica que m'agradaria assolir. Per exemple, no tenc cap coneixement de llenguatge musical, i és una cosa que des de fa anys m'agradaria aprendre. Potser el 2010 serà l'any...

L'any de la crisi

El 2009 passarà per ser l'any de la crisi, però tot i això crec que hem viscut temps interessants. El problema amb la famosa crisi és que tot s'ha enlentit, és com si haguéssim perdut un any, estant a l'expectativa, a veure-les venir. Per mi aquesta expectativa ha estat doble, ja que en hem trobat amb la fusió de TUIE i Hotelbeds, amb la qual cosa molts projectes s'ha paralitzat a l'espera del que passaria.

Com es diu "qui espera desespera", però crec que no ha estat el cas. La sensació de pèrdua de temps és intensa, però tot i això projectes com APSL, el Creant Bits, els passejos amb els nins amb bicicleta i els amics del Twitter no em queda la sensació d'any perdut, sinó d'any de reflexió, de tenir temps de descobrir coses noves i punts de vista diferents.

Encara que molts (la majoria) de pressuposts presentats encara estan al caixó d'algú, poder parlar amb els clients crec que m'ha enriquit com a persona, no des del punt de vista econòmic, però si des del punt de vista espiritual i tot suma!.

Com sempre un espera que l'any que començarà serà millor que l'anterior. Sigui com sigui serà també un any interessant de viure.

Es comú en les empreses modernes, sobretot quan volen refundar-se, venen consultor i demés que es comenci a parlar de la missió, de la visó i s'acabi parlant de la responsabilitat social corporativa.

Les empreses se n'estan adonant que el negoci no es pot fer d'esquena a la societat, sinó amb la societat. Que no basta complir amb el que diu la llei, sinó que convé participar activament en tasques que ajudin a millorar el nostre món. Es el que se'n diu una acció win-win, és a dir, tothom hi guanya: hi guanya l'empresa en nom i prestigi i hi guanya la societat en conjunt.

Quan parlam d'empreses de desenvolupament, i des del meu punt de vista, la responsabilitat social té molt a veure amb el que l'empresa de desenvolupament faci servir codi lliure.

El retorn a la societat es pot fer creant projectes o esponsoritzant-los, creant documentació, participant a forums, ... Això però sols és una part. Quan una empresa de desenvolupament tria fer servir el codi lliure està dient als seus clients que no vol que estiguin fermats, que vol que el client pugui ser lliure de triar el proveïdor que més el convengui i que no vol que el seu futur estigui hipotecat.

Als seus treballadors l'empresa els està dient que l'important són les persones, els seus coneixements i la seva formació, que poden participar activament en el desenvolupament de les eines que fan servir i tenir un coneixement més profund de la tecnologia.

Crear programes lliures, utilitzar-los, participant amb el seu desenvolupament, les empreses estan retornant un benefici a la societat al mateix temps que se'n beneficien elles. És la responsabilitat social corporativa entesa com a part bàsica de l'empresa i no com a un afegitó per a quedar bé.

En aquest article intentaré definir què es la mantenibilitat del programari, com es classifica i miraré d'analitzar l'impacte que pot tenir un llenguatge de programació tipat o no en relació a la mantenibilitat. És la precuela de l'apunt Mantenibilitat en llenguatges tipats i no tipats d'aquest mateix blog, on intentaré definir què és el manteniment i recolzar amb xifres l'impacte que pot tenir utilitzar un llenguatge tipat o no.

Definició de manteniment: La modificació d'un producte de programari després de la seva posada en producció a fi i efecte de corregir defectes, augmentar-ne el rendiment u altres atributs o adaptar-lo a les modificacions de l'entorn.

El manteniment de programari es classifica en quatre categories:

• Manteniment correctiu. És a dir, la correcció d'errors (bugs) de tota la vida.

• Manteniment adaptatiu. No hi ha canvi de funcionalitat però ara s'ha de fer feina amb altres condicions. Per exemple un canvi a l'IVA o a un nou plà contable.

• Manteniment perfectiu o de perfeccionament. Destinat a afegir alguna característica nova al sistema, per tal de fer-ho millor.

• Manteniment preventiu: Fet de manera interna per tal de millorar el sistema sense afectar-ne a les característiques externes.

Podem agrupar el manteniment adaptatiu i el perfectiu com a millores al sistema, considerades aquestes com quelcom que ha demanat l'usuari i que no estava previst a les especificacions del programa quan es va posar en producció.

Dins el mateniment correctiu podem trobar d'acord amb William E. Lewis les següents categories:

• Errors de disseny: el sistema no s'adapta al que l'usuari havia demanant.
• Errors de lògica: parts del programa no testejades, condicions no previstes, etc)
• Errors de codificació. Errors que resulten de una mala implementació de la lógica o per una mala escriptura del codi.
• Errors de càlcul. Resultat de mesclar tipus incompatibles o fer els càlculs agafant dades incorrectes.
• Errors d'entrada/sortida. Errors de forma, protocols d'entrada i sortida incorrectes, etc.
• Errors d'interfície: nombre de paràmetres incorrectes per exemple (pensen en interfícies XML sense anar més enfora).
• Errors en la definició de dades: Fallades d'inicialització de dades, mal us d'indexs,...

D'aquests tipus d'erros, fitxem-nos que el compilador tipat sols caçarà alguns dels errors de codificació i alguns dels errors d'interfície. Els errors de càlcul no es refereixen sols a mesclar tipus, sinó també a agafar les dades que no toquen o fer operacions incorrectes. Fins i tot en el cas de la mescla de tipus, un llenguatge tipat tampoc és cap garantia, ja que la majoria tenen maneres de passar dades d'un tipus a un altre, i qualsevol programador que codifiqui per coincidència pot acabar aplicant el typecast necessari per a que el compilador no es queixi.

El més important de tota questa classificació d'errors és notar que la gran majoria són errors que no depenen de si el nostre llenguatge de programació es tipat o no, es poden donar en qualsevol llenguatge.

Però anem un poc més enfora. Resulta que en terme mig un 60% del cost d'un programa és cost de manteniment (els intervals van entre un 40 i un 80%). De totes les fonts d'errors que hem enumerat, resulta que la correcció d'errors representa sols un 17% del total del cost de manteniment. Un 60% es dedica a tasques de millora del sistema (el que hem anomenat manteniment perfectiu), representant el manteniment adaptatiu un 18% del cost. El 5% que queda es dedica al manteniment preventiu, és a dir, tasques de mantenimient internes i sovint lligades a la refactorització del codi.

Veim doncs que el cost de manteniment no està en la correcció d'errors, sinó en el manteniment evolutiu i en el manteniment perfectiu. És a dir, el nombre de millores que ens demanaran els usuaris del nostre programa (externs o interns en el manteniment preventiu) representen el 83% del cost de manteniment total.

Perquè aquest cost? Doncs perquè un canvi representa que s'ha de definir i entendre el canvi, avaluar-ne l'impacte (15%), mirar la documentació (si existeix) del programa (5%), seguir el programa per veure que fa el que se suposa que fa (25%), fer el canvi (20%), testejar i depurar (30%) i finalment actualitzar la documentació (5%). És a dir, quan s'afegeix una nova característica a un programa en producció el cost emnor és el de fer el de codificar, el gruix del cost se'n va en entendre el problema (45%) i en la depuració (30%), és a dir, un 75% en tasques que no són directament de codificació i per tant on el tipat del llenguatge poc hi té a veure.

Llavors quan ens demanam què fa un programa mantenible, ens estam demanam com podem fer que el temps necessari per entendre el programa sigui el mínim possible. Reduint el temps d'entendre el que fa el programa reduïm el cost de manteniment i per tant fem el programa més mantenible.

I entendre el codi implica llegir el codi, poder seguir-lo. Es a dir, el codi per a ser mantenible ha de ser escrit pensant en les persones, recordau, no hem d'escriure codi per a que ho executin les màquines sinó per a que ho llegeixin les persones. Un codi millor estructurat és més fàcil de llegir, variables ben posades, codi que no es repeteix, etc. Una vegada més el tipat del llenguatge no hi té res a veure, de fet la literatura ens parla que les inspeccions de codi disminueixen fins en un factor 10 el cost de manteniment, per què? Doncs perquè fan que els programes siguin llegibles, un codi mal d'inspeccionar no passa i per tant no es mantindrà.

En conclusió, la mantenibilitat no és la dóna el tipat del llenguatge, ens la dóna la claretat i l'expressivitat del mateix i la nostra pròpia metodologia de programació i bones pràctiques.

Referències:

• http://www.research.umbc.edu/~cseaman/ifsm698/lect0903.ppt
• Software testing and continuos quality improvement. William E. Lewis (p.285)
• http://en.wikipedia.org/wiki/Software_maintenance
• Facts and Falacies on software engineering. Robert L Glass (p.115)
• Peer Revies in Sofware. Karl E. Wiegers (p. 6)

Quan surt aquesta discusió sovint, al manco al meu àmbit, la discusió es redueix a comparar Java i Python. Recentment en Paco ha obert la capsa dels trons al twitter amb una afirmació "Para escribir código mantenible, mejor un L.P. fuertemente tipado. Si es compilado, mejor".

Damunt el tipat o no em remetré al post de Ned Batchelder i a un comentari d'aquest post, amb al qual hi estic d'acord en un 90%, que traduït lliurement i sense limitar-ho a java diria:

1. Python maximitza la productivitat dels bons programadors

2. Els llenguatges tipats (Java a l'original) minimitzen el mal que els programadors mediocres poden fer al sistema.

Tant de bo la segona afirmació fos certa. La gent pot ser molt creativa i cap tipat del món no pot evitar que es faci un borrat complet contra la base de dades, que s'equivoqui amb l'algorisme del càlcul de l'IVA, les possibilitats són infinites. La referència obligada de que el tipat fort no és cap garantia de mantenibilitat la tenim al post How to Write Unmaintainable Code o passar-se per The daily WTF. El primer cas és fins i tot més sagnant, ja que la gran majoria d'exemples i tècniques es refereixen a llenguatges fortament tipats com el C, C++ i Java. Usos creatius del define, noms de variables que no tenen res a veure amb el que fa la variable, noms lleugerament semblants que fan coses totalment distintes,...

No vull fer sang damunt el tipat fort, la majoria de les coses que expliquen al How to Write es poden extrapolar a qualsevol llenguatge de programació. Però la realitat és el tipat fort no és cap garantia de mantenibilitat.

La mantenibiliat ens la donen les convencions del codi, la documentació, la inspecció periòdica o sistemàtica del nostre codi (o del codi d'altres), el llegir el code complete i aplicar els consells i pràctiques també ajuda força. Tenir test unitaris, programes que ens gestionin l'adherència als estàndarts i la complexitat del codi (n'hi ha per Java, Python, C++, ...), gestió acurada del errors, tests de regressió, etc. a l'hora de la mantenibilitat poden fer molt més que el simple tipat.

Potser perquè molts de programes que he fet al llarg del temps s'han mantingut en producció durant anys sóc un tant fanàtic de la mantenibilitat, preferesc codi matenible a codi guais que al cap d'un mes ningú, ni el seu creador, sabrà perquè ho va fer d'aquella manera. I aquest tipus de mantenibilidad no la dóna el tipat fort o el compilador, la mantenibilitat ens la dóna la gent i les regles que ens imposem a l'hora de crear el codi.

Com la seguretat la mantenibilitat no és quelcom que es pugui posar una vegada el programa està llest. La mantenibilitat ha de formar part del procés de desenvolupament. Sovint he refet o he fet refer codi perquè era mal de seguir, per massa acoblament, perquè la quantitat de ifs feia difícil saber per on anava el codi, i això m'ha passat tant en Java, Pascal o FORTRAN com en Python.

Llavors, pensant en que els programes es fan per a ser mantenibles tant en llenguatges tipats com en els no tipats, la pregunta que ens faríem doncs és perquè triar un llenguatge o un altra i aquí ja entraríem en un altre tipus de discusió.

Si pensam sols en termes de mantenibilitat i suposant que programam com toca potser estarem d'acord que hauríem de triar un llenguatge que fos bo de llegir, de seguir, expressiu i d'alt nivell. El millor codi és aquell que no s'ha d'escriure. Per mi pocs llenguatges compleixen això tant bé com Python, és un llenguatge molt clar de llegir, amb una corba d'aprenentatge molt suau i amb una dèria cap a la llegibilitat i la mantenibilitat que està incorporada al llenguatge dins la pròpia sintaxi (la identació) i a l'intèrpret mateix (provau import this) o llegiu The Zend of Python i les convencions de codi són públiques i definides des del 2001, la qual cosa no vol dir que no s'hagin canviat al llarg del temps.

En conclusió: el codi mantenible no ho dóna un compilador sinó el programador i la gestió que se dugui del projecte. No podem confiar en que el tipat fort ens farà la feina i ens alliberarà de la feina de crear tests unitaris, de comprovar que el codi està d'acord als estàndards o de que fa el que ha de fer.

Java, C, C++ són grans llenguatges no perquè tenguin tipat fort, sinó pel que els programadors hem fet amb ells. De la mateixa manera Python, PHP, Perl, Ruby són grans llenguatges no per la seva absència de tipat, sinó per codi que ens permeten escriure.

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.

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!

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.

Un comentari de Paco me dóna peu a fer una recapitulació damunt el portàtil. Per cert, he deixat unes quantes fotos de família al Flickr.

El portàtil resulta molt còmode a l'hora de moure'l d'una banda a l'altra. En aquests quinze dies i escacs que duc amb ell he de dir que és nota molt la diferència entre dur aquesta jugueta i el portàtil de 15,4 polzades. La meva esquena ho agraeix, i més si he de caminar una bona estona.

La durada de la bateria, 5 hores, és un poc curta per el que se suposa que hauria de durar una bateria de 6 cel·les, però en el seu favor he de dir que són 5 hores reals, és a dir, fent feina.

El teclat és molt còmode. A l'igual que en a l'altra portàtil m'agradaria poder tenir un botonet per desactivar el touchpad, ja que mentre escrius és molt senzill tocar-lo sense voler i dur el cursor a qualsevol banda.

L'IDE que faig servir per programar actualment és el Netbeans. El Dell 2100 amb 2 GB de RAM no té cap problema per moure'l i va força fluid. La cosa canvia un poc en posar-li un monitor extern. Us explic: aquest portàtil ho faig servir també per programar i ho tenc amb una configuració de monitor dual, és a dir, tenc un escriptori virtual consistent en la pantalla del portàtil (1024x576) i un monitor Dell de (1680x1050). La tarja gràfic mou bé el conjunt, però els scrolls verticals se noten, no són fluids. No és el suficientment greu com per no deixar-te fer feina, però sí una mica empipador. Aquest efecte és nota bastant al Netbeans i un poc al Firefox. És l'emperò més gran que li he trobat per ara...

L'altra cosa a notar és el carregador. És petit si ho comparam amb els carregadors estàndard de Dell, però encara és gran. En el seu favor dir que és compatible amb els carregadors dels seus germans grans i per mi això s'ha convertit en un avantatge, ja que amb el Dell de 15,4" vaig comprar dos carregadors: un per la docking i un per transportar, així puc jugar amb aquest fet i tenir un carregador a cada lloc de feina.

El disc d'estat sòlid es porta mol bé. És ràpid i tot el sistema tan just fa renou. De tant en tant es posa en marxa un ventilador, però ni ho sents. De totes maneres trob que s'encalenteix més del que esperava i potser això explica la "poca" durada de la bateria.

La visibilitat de la pantalla és molt bona. Pràcticament no hi ha reflexos, encara que no he arribat a aprofitar-ne les possibilitat que té el que sigui una pantalla tàctil. Deu ser un trauma infantil, ma mare me deia que és de mala educació assenyalar amb el dit. :)

Ahir vaig acabar de llegir "La empesa en la Web 2.0" de Javier Celaya. El libre té una estructura i un contigut que recorda els apunts d'un blog. De fet Celaya recorda en el llibre que alguns dels apunts han estat publicat en el seu blog i adjunta alguns comentaris.T enc el llibre en paper, existeix una edició de descàrrega lliure per mòbils, però la veritat és que està força amagada.

Al llarg de 279 planes Celaya intenta explicar des de la òptica empresarial que és això de la web 2.0 i quin impacte pot tenir en les empreses. Tracta temes com la importància de les xarxes socials, el blogging, microblogging i wikis, donant apunts sobre quina ha de ser la posició de les empreses davant aquestes xarxes i com es poden anar introduïnt aspectes de la web 2.0 dins les organitzacios per tal de millorar-ne la gestió.

El llibre m'ha agradat, sobretot perquè compartesc gairebé al 100% les apreciacions de Celaya, i perquè he trobat en el llibre allò que cercava: com explicar en paraules planeres i orientades a gent amb perfil empresarial l'impacte de les noves tecnologies web en les empreses.

No m'ha agradat tant l'extensió del llibre. Crec que hi ha força palla i que ben bé podria ser un llibre de 150 planes. De tant en tant es posa a escriure noms i característiques de llocs web sense entrar-hi a fons i et dona la sensació de que estan allà per omplir.

Com dic el llibre és interessant, no perquè expliqui coses que desconec sinó per la manera d'explicar-les. La relació preu/contingut, però l'he trobada força alta, després d'haver llegit el llibre 20 Eur em pareix car.

Xerrar per exemple amb Benjamí o Ricardo, o amb "els tertulians de la torrada" crec que en temes de web 2.0 aporta tant o més que el llibre. Celaya, però, ho explica orientat al món empresarial i això se li ha de reconèixer.

Fitxa tècnica:

La empresa en la web 2.0
Javier Celaya
Ed. Gestión 2000
ISBN: 978-84-9875-008-9

Llegir codi és una de les millors maneres que hi ha d'aprendre a programar. Veus com la gent fa certes coses i pots començar per copiar-les per passar a demanar-te per què es fa d'aquella manera i finalment mirar de millorar-ho.

M'agrada llegir codi, però també es veritat que quan he de llegir codi que he comanat per un projecte i veig segons quines coses em pos un poc de mala llet, no és res personal, crec que és un defecte del meu caràcter, d'aquest xic de perfeccionisme que tots duim a dintre.

Primer de tot s'ha de tenir en compte que escriure codi és molt personal, no hi ha una manera única de fer una mateixa cosa i els codi es converteix en una extensió de la personalitat de l'autor i de la seva manera de fer les coses.

Per això convé sempre ser caut a l'hora de valorar el codi d'altres. Sempre hi ha una manera millor de fer-ho, sempre hi ha una altra manera de fer-ho, la nostra manera.

Pel que es veu afectat per la revisió, les coses no són menys fàcils, sovint pareix que el codi és com un fill nostre, i que una vegada escrit, com nin malcriat, se li han de perdonar tots els defectes.

Personalment quan veig alguna cosa que no m'agrada ho dic. Al llarg del temps he desenvolupat una certa habilitat per veure quan un codi fa mala olor, i segons el que he dormit el dia anterior puc ser més o menys políticament correcte.

De tipus d'errors n'hi ha molts, i jo en tenc la meva classificació particular (ja sabeu, el món es divideix en dos tipus de persones, aquells que fan llistes i els que no).

• Errors puntuals. Són la típica cagada que li ha passat a tothom. Qui digui que a ell no li ha passat és perquè no ha programat prou. Són errors que poden ser greus en termes de les conseqüències, però que s'han de prendre com això, com part de la feina. Són errors per aprendre a no tornar-los fer.

• Errors de "però mira que guai que sóc". Sovint no són errors, sinó trossos de codi dels quals el creador se'n va sentir molt orgullós però que són mals de depurar i que es poden reescriure fàcilment per fer el mateix de manera més clara i amb menys línies de codi. Potser el programa funciona, però no és correcte, li falta qualitat i a la llarga representa un problema en el mateniment correctiu i evolutiu. Sovint aquest tipus d'error està molt relacionat en el concepte de reinventar la roda i amb el síndrome NIH (Not Invented Here). S'han de corregir tot d'una que es presenten i mirar de conscienciar a la gent per a que no es repetesquin.

• Errors de seguiment dels estàndards de codificació. No tenen excessiva importància, però dificulten la lectura del codi i l'evolució del programari. Els estàndards de codificació i localització del codi serveixen per a que qualsevol persona que no està familiaritzada amb el codi, pugui llegir-ho sense dificutat i saber on ha d'anar a trobar les coses. Particularment me resulta molt més fàcil llegir un codi amb noms de variables ben posats, amb els comentaris allà o toca. Llegir codi requereix molt atenció i esforç i tenir que bregar a més amb distintes maneres de codificar no ho fa més fàcil.

• Errors d'arquitectura: Cohesió i acoblament. Cohesió bona, acoblament innecessari dolent. I m'estic referint a l'acoblament de codi, a casa que cada un faci el que pugui. Tenir tot el relacionat a un mateix lloc (llibreria, paquet, arxiu, ...) i no separat en mil i un trocets que fan mil i una coses sols per peresa de no crear un nou arxiu o estructurar el programa, d'això se'n diu cohesió. L'acoblament és la dependència que hi ha entre mòduls distints i que fa que sovint aquests no es puguin reutilitzar de manera independent. L'acoblament és necessari per a construir programes, però ha de tenir un perquè. Cohesió i acoblament són conceptes que van molt lligats i codi amb poca cohesió sols presentar molt acoblament.

• Errors de concepte. Són els errors que es cometen perquè un no s'ha aturat a pensar en el que està fent i bé per desídia o bé per malentesos crea codi que no té sentit. És el típic error de permetre fer reserves per dies passats i coses semblants. Són errors que em preocupen, perquè vol dir que s'està programant sense reflexionar i això és molt perillós. La programació no és sols picar codi, és picar codi amb una finalitat i aquesta no sols ha de ser la de cobrar a final de mes, sinó que ha de servir al nostre client. Quan són errors per desconeixement del negoci s'ha d'insistir en que se demani tot el que no es coneix, quan són errors per no pensar en el que se està fent convé insistir en conscienciar a la gent del tipus de feina que fa.

• Errors de code monkey. Errors de copiar i aferrar, funcioni el codi o no. S'ha copiat cinquanta vegades el mateix sense aturar-se a pensar si convendria fer-ho d'una altra manera. Són errors que al igual que l'anterior m'empipen especialment, ja que per defecte vull pensar que la gent fe la seva feina el millor que sap. Em preocupen perquè sovint vol dir que s'ha escrit el codi a tot màquina per cobrir l'expedient i que les hores s'han dedicat a altres coses. Estirada d'orelles.

No passa res per cometre errors, el que no és admissible es no aprendre dels errors, o preferir reinventar la roda per no aturar-se a pensar en maneres alternatives. Quan el problema es molt bàsic hem de pensar que l'error sols estar en la nostra banda, que la funcionalitat existeix però no l'hem vista i hem de llegir més. L'alternativa: codificar-ho nosaltres mateixos, o començar a pensar que l'error és de la pila TCP del nostre ordinador i posar-se a davallar-se el codi per anar a fer la depuració no és la primera opció que un ha de pensar. Primer s'han de provar les coses més habituals, ja que el el 99,9% de casos l'error serà nostre, del nostre codi.

Llegir el codi, el nostre i els d'altres, ens ajuda a reflexionar sobre allò que podem millorar i a evitar els errors més comuns. Recordem que com a programadors no escrivim codi per a ser executats per les màquines, sinó per a ser llegits per altres persones.

Ha costat, però finalment fa dos dies vaig rebre el portàtil i el ratolí que faltava. Ara sols falta la borsa :) Avui m'he dedicat a configurar-ho un poc i dur un poc més al límit les possibilitats del sistema.

El portàtil és un Latitude 2100 amb 2 Gb de RAM, 16 Gb de disc dur d'estat sòlid, càmera de 1,3 Mp i pantalla tàctil. La pantalla és de 10 polzades amb una resolució de 1024x576 px.

El portàtil és dens, vull dir, que el pes es deixa notar en un volum tant reduït, i el que sobta més és el tamany de la bateria. El vaig demanar de 6 cel·les i sobresurt molt. Els dissenyadors de Dell han tingut l'encert, al manco, d'aprofitar aquest fet per a fer-ho servir de soport i dinar-li al ordinador una inclinació molt bona per escriure. Potser amb la bateria estàndard, de 3 cel·les, l'estètica del portàtil serà millor, però particularment el que m'interessa és tenir molta autonomia més que tenir una portàtil cool. Per ara ja duc 4 hores fent coses, connectat a Internet, fent servir la càmera, configurant, etc i segons el sistema encara en tendria per 1 h i 25 minuts més.

El teclat permet escriure amb comoditat. Recorda al teclat del Dell de 12" i és molt còmode. El touchpad està molt pròxim al teclat i no és desactivable i fa que es tengui que anar un poc més alerta de l'habitual a l'hora d'escriure per tal de no tocar-lo i situar el cursor a un lloc on no voldries.

El portàtil ve de sèrie amb Ubuntu 9.04, al manco l'espera ha significat que no he tingut que actualitzar massa el sistema, ja que el portàtil anterior duia una Ubuntu 8.x. Una i de les coses que provat és la connexió 3G de Vodafone. Una meravella, ha estat posar el modem i m'ho ha detectat, he posat el PIN i ja està, connexió establereta. La velocitat no l'he poguda comprovar, Binissalem pel que es veu encara està fora de l'autopista 3G :(

Una de les coses que més em disgusta de Gnome és el desaprofitament de l'espai que fa. Amb pantalles grans això no és un gran problema, pero quan sols hi ha 576 px s'han de treure pixels d'allà on no n'hi ha. Per això he instal·lat un nou tema Gtk que no desaprofita tant d'espai vertical anomenat Human Compact i he fet quelcom semblant amb el Firefox.

El resultat és que menús que no hi cabien a la pantall ara queden més o manca per la mitat o un poc més. Visualment és un poc menys atractiu, però és molt més pràctic a l'hora de fer feina.

Poca cosa més dir d'aquest portàtil. L'estètica es sòbria i funcional, recorda als IBMs de fa uns anys, i tot ha funcionat a la primera, la única modificació real ha estat la de la distribució del teclat que m'ha obligat a eliminar l'idioma americà per posar-hi l'espanyol.

Aquest apunt està escrit des del portàtil amb gedit i pujat amb el Firefox. Com podeu veure el tamany del teclat per permetre'm escriure en mode verbose :-P

Cada vegada que surt una nova versió d'Eclipse s'actualitza la llibreria javahl que és la que se n'encarrega de la interfície de subversion.

Això no seria cap problema si no fos que com que el client java té una versió més actualitzada que el client per línia de comandes, amb la qual cosa una vegada actualitzat un projecte fent servir Eclipse deixa de poder actualitzar-se per línia de comandes.

Això es pot sol·lucionar tornant a baixar la versió del repositori local, però tornarem a tenir el mateix problema quan tornem a actualitzar.

L'altra sol·lució és actualizar el client subversion del nostre equip. El procés és molt senzill i està força ben explicat al blog An Extraordianry Bison, tanmateix pos aquí els passos més importants:

1. Actualitzar les dependències del nostre sistema per a poder compilar subversion:

   sudo apt-get install build-essential libapr1-dev libaprutil1-dev libneon27-dev
   

2. Descarregam el codi font del subversion. La darrera versió actual és la 1.6.3, així que:

   cd /tmp
   wget http://subversion.tigris.org/downloads/subversion-1.6.3.tar.bz2
   tar xjf subversion-1.6.3.tar.bz2
   cd subversion-1.6.3
   

3. Ara ens queda el cicle de configure, make, make install típic. Com que el que volem és tenir sopurt per ssl i per JavaHL farem

   ./configure --with-ssl --enable-javahl --with-jdk=/usr/lib/jvm/java-6-sun
   make -j3
   make -j3 javahl
   

Un parell de notes: el j3 sols és convenient (que no necessari) si teniu una màquina amb més d'un processador (de doble nucli), li podeur donar el valor del nombre de nuclis més un, en cas contrari make gestionarà per si mateix el nombre de traballs simultànis que llança. En el meu cas, al manco, és més òptim "limitar-ho" així.

1. Feim la instal·lació:

   sudo make install install-javahl
   

Amb un poc de sort amb això ja tedrem actualitzat el client de svn a la darrera versió i ens tornarà a funcionar el client de línia de comandes.

Personalment ho he provat a Ubuntu 9.1 amb arquitectura PPC64 i amb arquitectura i386 i cap problema. Funciona tant l'Eclipse com el client de línia de comandes. El Netbeans es segueix queixant de que no troba la llibreria javaNL però ja caurà, ja ...

Dia 15 del mes passat vaig comanar un portàtil Dell de 10" amb disc dur d'estat sòlid de 16 Gb i 2 Gb de RAM i bateria de 6 cel·les i Ubuntu com a sistema operatiu. Total 1,5 Kg de pes. La idea és que fos el portàtil de les reunions i viatges, amb prou autonomia per aguantar un dia normal de feina sense problemes.

Avui m'ha arribat, bé, casi... Ha arribat romput amb un cop d'aquests que fan fredat a la pantalla que és difícil d'explicar. La capsa ja venia copejada, però no foradada i no m'explic com el transportista (UPS) li ha pogut pegar un viatge com aquest a un article que s'ha de manipular com a fràgil.

A més d'arribar amb 15 dies de retràs que arribi d'aquesta manera és una putada. Si torba més el model ja serà antic.

Tot i això al manco ha arribat, cosa que no puc dir del ratolí ni de la borsa de transport, que s'han perdut pel camí. Serà cosa de la crisi?

El portàtil en sí i amb la mitja pantalla que es veu, està força bé. Les tecles són més usables que al portàtil de 9" encara que el mig quilet de pes també s'ha de tenir en compte. Duu Unbutu 8.10 de sèrie que ha arrancat foça ràpid. No l'he configurat perquè no m'hi veig, però promet.

És un portàtil força compacte,dens afegiria i crec que té el tamany ideal pel que cerc: que em permeti fer feina un parell d'hores sense problemes i sobre tot que em permeti dur-ho sempre a la motxilla. El que ara duc és un Dell també de 15,4" (sense copetar) i els gairebé 3,5 Kg es noten si t'has de moure molt i anar a peu. Té molta més resolució que el de 10", gairebé el doble, però com que és també un dels meus ordinadors principals de feina, no m'hi sent còmode passejant-lo. La idea del portàtil de 10" és el de tenir-hi sols la feina del moment i la resta obtenir-ho on-line.

M'hagués agradat poder escriure més coses i contar-vos si va bé o no, i si val el que he pagat per ell, però ara per ara sols us poc contar aquestes petita anècdota. Hauré d'esperar un poc més i confiar en el servei d'atenció al client de Dell, i que la reposició sigui ràpida.

Estic emprenyat! Potser és l'efecte de que se m'acabin les vacances, tot s'ha de dir, però també perquè aquests dies he pogut comparar la diferència que hi ha entre les llibreries on-line espanyoles i les americanes, tot una decepció.

El diumenge 21, comptant que estaria una setmana de vacances, volia llegir dos llibres que m'havien recomanat: "El Economista Naturalista" i "Fest-te bruixot, fest-te savi", que no tot ha de ser informàtica :) Així que vaig anar cercant a les llibreries on-line espanyoles amb l'esperança de trobar-los i tenir-los en un parell (dos) de dies o potser tres.

El llibres els vaig trobar a Casa del Libro i vaig triar l'opció d'enviament urgent (2 dies, fins aquí bé), un poc més cara, però tanmateix el que importava era tenir la lectura de vacances a punt.

El divendres al migdia vaig rebre un missatge que me deia que no tenien cap dels dos llibres en stock i que podria estar entre 4 i 20 dies hàbils en arribar, si l'editorial els tenia, però que en tot cas ells no se'n feien responsables. Penós!

Compr força llibres a l'any, normalment llibres tècnics, però si hi ha una cosa certa és que cada cop que els compr a llibreries on-line espanyoles em duc una decepció. Amazon o Barnes and Noble també es queden fora estoc, se'ns dubte, però mirem-ne les diferències:

• És molt rar que si demanes més d'un llibre estiguin tots esgotats. No m'ha passat mai.

• No donen la culpa als altres, sinó que es disculpen per haver quedat sense existències, te donen una data aproximada i te diuen que t'enviaran l'altra o els altres sense cost addicional

És a dir, he pagat més per un servei urgent (que ja vos jugaria alguna cosa que no em reemborsaran) i a més rebré els llibres quan a ells els vagi bé. Al missatge no hi ha cap link per a cancel·lar la comanda, si tens res a dir telèfon o formulari d'incidències, que per suposat he omplert.

Em fa ràbia! Tothom s'omple la boca amb paraules com a innovació, competitivitat, que el futur és on-line i després topes amb la realitat: l'empresa espanyola (llevat de molt comptades excepcions) encara no creu amb Internet, els que hi són ho fan gairebé per obligació, com a una despesa més que com a una inversió.

Veus planes mal fetes (potser és deformació professional) sols compatibles amb un navegador, amb un disseny poc orientat a l'usuari, lentes, sense cuidar ni la semàntica de la plana, desactualitzades, tècnicament dolentes ... I no és cosa de llocs petits, sinó d'empreses que haurien de tenir un potencial inversor important, i que per tant això sols s'explica per desídia o bé perquè com dic, veuen el tema del comerç electrònic com a una despesa.

Gent! Espavilau! Convé que l'empresariat d'aquesta terra comenci a fer un curs intensiu de comerç electrònic, que aprengui a distingir una web ben feta d'una altra que no ho està, que sàpiga demanar un pressupost com toca i no "qualsevol cosa per estar a Internet". En definitiva, convé adonar-se de que Internet és un canal de venda important i no basta amb ser-hi, actualment és necessari tractar-lo com si fos una tenda física, mimar-la i entendre que és un negoci 24x7 on la gent espera immediatesa i començar a modificar els fluxs de negoci per anar adaptant-ho a aquesta nova realitat.

Què passarà si un dia Amazon fa una web de llibres en castellà (o català, o gallec)? Doncs que ja no hi haurà temps de reacció. És el mateix que els està passant ara als hotelers, massa dependents de les reserves dels TTOO. Un canal on-line fort i una bona política de preus els hagués permès negociar millor i tenir un canal de venda extra consolidat.

No basta amb tenir un iframe (com fam molts) cap a un banc de llits dins la web presencial de l'hotel per a que ens vengui els nostres llits, s'ha de tenir el control total del que estam venent, és el nostre negoci. Això permet jugar amb les ofertes de darrera hora, fer promocions, és a dir, controlar què i com venem el nostre producte i no deixar la comercialització totalment en mans de tercers.

M'emprenya veure com tenim accés a les mateixes eines que tothom i com ens estam quedant endarrera quan en podríem ser capdavanters.

Aquesta setmana he trobat un grapat d'apunts molt interessants al Planet de Python, el primer és Programming is not the right thing to do i TDD Anti-Patterns.

El primer article és un comentari a Programmers: Before you turn 40, get a plan B, on tracta la suposada obsolescència dels programadors a partir dels 40 anys.

El segon és una classificació dels principals errors que un pot trobar-se quan programa fent servir la metodologia coneguda com a Test Driven Development.

Del primer, potser perquè ja estic passant els 40 m'afecta és personalment. És cert que la meva feina diària és més de gestor que de programador, i que fins i tot he procurat cercar-me un pla B, però crec que el que diferencia un bon programador i algú que programa com a feina no és l'edat, sinó la curiositat i les ganes d'aprendre. Potser amb l'edat la nostra capacitat d'aprendre coses noves empitjora i ens feim més lents, però és ben cert que millora la nostra capacitat de relacionar experiència i coneixements, ja que els tenim.

El que sí diria és que ens tornam més sibarites. Personalment m'atrau més fer feina amb tecnologia que m'agradi i amb projectes interessants que amb altres feines, potser millor pagades, però menys satisfactòries. Supòs que és perquè m'agrada la feina que he triat com a mitjà de vida, i em deprimiria (em deprimeix de fet a vegades) veure-la convertida en un simple mitjà per posar un plat calent a taula.

El segon article a més del que té de millors pràctiques, m'admira per la facilitat que tenen els anglosaxons per posar noms a les coses. L'objecte Good, El mentider, l'heroi local. Noms graciosos però que resumeixen el que es vol dir o que senzillament ajuden a pensar més en el que es fa.

D'aquest article vaig anar a parar a una utilitat, el pudb que desenvolupa un depurador en mode text per a Python. No tant potent como el ipdb o el pdb, però que té un entorn gràfic més agradós.

La depuració i el testeig per mi no són disciplines menors. Ens passan gran part del temps depurant i testejant, i potser un dels avantatges de tenir els quaranta és que ja intueixes moltes vegades on és el problema, fent bona la dita de que sap més el dimoni per vell que per dimoni. De totes menares quan m'he d'enfrontar amb una sessió de depuració procur anar-hi amb una certa metodologia:

1. Suposar que la culpa és al codi. Pareix una tonteria, però suposar això implica començar a cercar primier pel més obvi, per alguna cosa que hem trencat. Si no ho feim així fàcilment podem caure amb el que McConnell a "Code Complete" anomena Debugging by Superstition (veis un altre nom interessant), per explicar el comportament de certs programadors que cerquen defectes misteriosos pensant que el compilador, l'editor, el sistema operatiu, el món, ... està contra ells.

2. Formular una hipòtesi. És en la depuració on podem demostrar que la programació és una ciència. Feim una hipòtesi i la comprovam, si no és cumpleix la hipòtesi la teoria és incorrecta i hem de cercar el problema per un altre costat.

3. Modificar una cosa cada vegada. Com en la refactorització, sols que en el cas de la depuració es tracta de que el programa es comporti de manera diferent, i.e. que funcioni.

4. Testejar la solució. No sigui cosa que resoldre el problema ens introduesqui nous problemes o en faci aparèixer de nous que havien estat amagats.

També aquesta setmana he tingut l'oportunitat de llegir un treball d'Accenture damunt SOA. He de dir que tractava el tema força bé, sense decantar-se per un proveïdor concret. Estic convinçut que SOA és una bona cosa, el que no tenc clar és que tengui que ser necessàriament complexa. Crec que amb SOA està passant un poc el que va passar en el seu dia amb els EJB: s'intenta aplicar a problemes que realment no requereixen tanta complexitat.

Com en el cas de la depuració sóc partidari de començar primer pel més obvi: que no necessitam tanta complexitat segurament, i anar cap a arquitectures més senzilles però igualment vàlides: XML sobre Http, REST i després anar complicant-ho si és necessari i el retorn de la inversió ho justifica.

Que amb les eines que et proporciona Django i un ganes de fer les coses bé, seguint els estàndards i fent les webs semàntiques s'obtenen bons resultats de posicionament és una cosa que puc comprovar dia rere dia.

La darrera ha estat una petició d'una de les seccions de l'empresa per a que féssim alguna cosa amb un micro-site que havíem llançat feia uns dies, ja que quan cerques pel nom del client al Google surt el nostre micro-site enlloc de la plana web de la marca principal.

Explicació: la plana principal del client està desactualitzada, té una relació de pes de la plana front continguts nefasta i està maquetada fent servir taules.

Per una part estic content perquè veig que en el que fa a posicionament i indexabilitat feim les coses prou bé, i per altra banda estic sorprès i fins i tot amoinat per la petició de "fer alguna cosa", que demostra una falta de fonaments en una gent que demana aquest tipus de coses.

Per al que tothom seria un avantatge competitiu: sortir el primer a Google, l'han convertit en una altra manera de dir que no fas bé la teva feina. Encara me fa mal la llengua.

De tant en tant vaig jugant amb el tema de les traduccions automàtiques, m'atreu molt el camp per la seva utilitat, complexitat tecnològica i sobre tot pel que significa a l'hora d'atracar el coneixement i la informació a tothom sense obligar al qui escriu a expressar-se en una altra llengua.

Fins ara els meus dos referents en traducció automàtica eren el motor que fa servir la Generalitat de Catalunya i Internostrum, desenvolupat per la Universitat d'Alacant.

En un d'aquests experiments he arribat al projecte Apertium, un sistema de codi obert per a la traducció automàtica de documents.

Pel que llegeixo està basat en el codi d'Internostrum i està liderat també la Universitat d'Alacant. El que més m'ha agradat però, és veure com universitats, govern i altres organismes s'uneixen per al finançament d'un projecte de codi obert del qual tothom en port sortir beneficiat. La gent que fa investigació pot tornar a la societat el resultats de la seva investigació i al mateix temps els usuaris podem implicar-nos en el projecte, encara que sigui de beta-testers.

He posat l'enllaç de les traduccions al blog. M'ha impressionat la qualitat de les traduccions que aconsegueix el motor. Estaria molt bé poder-li dir dins el codi html que hi ha parts que no ha de traduir, però tot i això, els resultats crec que parlen per si sols.

Gent d'Apertium la meva enhorabona i moltes gràcies pel vostre esforç!

Entre robiol i robiol (ja veus no sóc de panades!) em vaig posar a actualitzar el PPC. Volia ser conservador i anar cap a la versió 8.10 d'Ubuntu, però com sempre el PPC ha resultat ser una capsa de sorpreses.

L'actualització em va deixar amb un sistema on el xinerama no funcionava, gairebé sense dreceres de teclat, el kded ben mort i un refresc de pantalla desesperant. Ni reconfigurant pantalla ni res, massa dependències a resoldre i tot plegat un desgavell.

Mentre amb el portàtil davallava la imatge per tornar-ho a deixar tot estable, vaig pensar en la dita de from the lost to the river que traduït del bilingüe al català, ve a dir alguna cosa així com tanmateix ja ballam i vaig posar a fer up

sudo update-manager -d

Quatre hores o cinc després ja ho tenia tot llest. El resultat és que estic escrivint aquest apunt des de el Gnome amb Xinerama funcionant i configurat des de l'entorn gràfic.

La mala notícia: que sols funciona el Gnome, l'entorn Kde no fa el refresc de pantalla bé i tampoc configura el Xinerama. El darrer no em preocupa gaire, estava dispost a prescindir del Xinerama, però els problemes fan que el Firefox sigui completament inusable, els quadres d'entrada de dades apareixen en negre.

En altre aspecte dir que aquesta versió (al manco per PPC i amb el Gnome) dóna tota la sensació de ser més ràpida que l'anterior. Així que ara per ara toca tonar a Gnome una temporadeta. Tanmateix també és un magnífic entorn.

Bé, dir nou disseny a la nova imatge de Trespams no és dir molt. Ni tan sols diria que és un disseny :-P

Però bé, la idea és anar cap a un disseny molt més minimalista que l'anterior, on sigui un poc més bo de fer afegir coses sense tenir que preocupar-se per si destroçarà massa cosa o no.

Encara queda fer molta neteja, però ara aquest blog té un disseny mínim: el que ve de fàbrica amb blueprincss i sols hi ha alguns retocs per deixar les coses un poc més col·locades i accessibles.

Els menús estan manllevats de Free CSS Drop-Down Menu Framework amb algunes petites adaptacions al css per a que es pugui servir des de un directori distint a l'original.

Es podria dir que estic refactoritzant el blog. Per ara el que vull és anar fent neteja i que tot funcioni igual que abans. Després quedarà llevar les parts que ja no es fan servir, per acabar anar afegint el nou.

Aquests dies m'ha tornat a pegar per a fer feina al Blog. En Bernat m'ha creat un virtualenv al servidor i ho aprofit per anar fent-hi quatre coses.

L'aspecte gràfic no canviarà per ara, si ho fa serà per convertir-se en més minimalista encara, el que sí canviarà és la part interna i les eines d'administració.

Fent feina amb l'administració m'he topat amb la necessitat de manipular dates amb Javascript. La llibreria Javascript que he posat per a gestionar taules Datatables(per l´unic motiu que tenia ganes de provar-la) no gestiona bé formats que no siguin el de Date de javascript, molt anglosaxó, ell.

Per arreglar-ho vaig tirar d'una llibreria de Javascript que ens permet manipular dates i formats de la manera que vulguem, i això m'ha fet recordar la conveniència de deixar per escrit un grapat de llibreries de manipulació de dates que extenen les que ja tenen els meus llenguatges de programació preferits:

• Datejs Magnífica llibreria per a javascript. La versió "estable" es un poc antiga però fa el que ha de fer i també hi ha la del subversion, que encara no he provat, però que serà el que faré quan acabi aquest apunt. Un petit emperò, no sé que fa, però me deixa el Firebug torrat i ben torrat, necessita gairebé cinc minuts per tornar en sí.

• python-dateutil s'està convertint en una referència obligada per a la manipulación de dates en Python, i això que Python de per sí ja ho fa fàcil.

• python-egenix-mxdatetime un vell conegut per als qui hem tractat amb bases de dates amb Python. És la llibreria recomanada per la seva potència i rapidesa. L'anterior potser té la novetat i la senzillesa però la llibreria d'Egenix té la solvència que dóna l'edat.

• Joda Time l'equivalent Java de les llibreries anteriors. Forma part de les llibreries que sempre posa a qualsevol projecte Java.

Abans de reinventar la roda (o el calendari) no oblideu fer una ullada a aquestes llibreries.

Els que em coneixeu segurament haureu notat que m'agrada ensenyar de la mateixa manera que m'agrada aprendre. Ensenyar permet compartir experiències i coneixements amb un nivell de comunicació que és difícil d'assolir en un llibre o un article, i poder ensenyar allò que a més t'agrada ho fa tot molt més divertit.

Com en moltes coses, per mi la màxima és fer les coses com m'agradaria que algú les fes si fossin per mi. Això sovint fa que m'ho prengui de vegades massa seriosament, sóc exigent amb els altres i per tant també ho sóc amb mi.

Per a que un curs sigui productiu la gent que hi assisteix hi ha d'anar mínimanent motivada. Una manera de tenir aquesta motivació és que la matèria que s'hi imparteix es vaig a utilitzar en un futur proper o ja s'estigui utilitzant.

Python i Django fa que sigui molt ràpid poder tenir un entorn de proves i començar a fer coses. La corba d'entrada és molt suau i es poden començar a fer aplicacions molt ràpidament, per tant, augmenten les possibilitats de que la gent ho pugui fer servir en el seu dia a dia, fins i tot si no s'hi dedica al 100%. Tasques d'administració de sistemes, scripts d'importació, generació de codi, etc. són molt ràpides de fer en Python i per tant es pot veure un resultat immediat del que s'ha après. La realimentació que s'aconsegueix, la gratificació de l'ego, fa que la gent pugui veure una utilitat en allò que fa.

A mi els formadors que m'agraden són aquells que a més de dominar la matèria (no ho doneu per suposat, no és la primera vegada que vaig a un curs on que l'impartia sols sabia el que deien les presentacions que duia preparades) hi fan feina. Sobretot en la part tècnica això es nota molt. Qui fa feina dia a dia amb una tecnologia a més de tenir-ne els coneixements també us podrà donar consells, millors pràctiques, trucs de la professió que no estan als manuals. Llavors és cosa de cada un aplicar-los o no, però el que està clar que a més d'una simple explicació de coneixements hi ha la part de transmissió d'experiència.

Per això m'agrada que els formadors no es dediquin professionalment a la formació, sinó que la seva feina principal impliqui fer feina amb aquella tecnologia i obviament m'aplic el mateix criteri. M'agrada ensenyar, però em trob molt més còmode amb mi mateix ensenyant allò que faig servir, en el meu cas Python, Django o gestió de projectes informàtics.

Ensenyar implica també preparar-se les classes. Per mi aquesta preparació no significa llegir-se la matèria (que també) sinó a més preparar exemples, la línia argumental de la classes i un conjunt de "plans bé". És a dir, tu prepares el que se suposa que serà el contingut de la classe d'aquell dia, però pot ser que s'avanci més ràpid del que s'havia pensat, o que sorgeixi més interès per un tema concret o que trobis que és millor fer un exemple més senzill per acabar de lligar el que s'havia explicat. Poder anticipar-se a tot això i tenir-ho previst també fa que s'avanci molt més en la formació. A mi que el formador se quedin pensant en el que ha de donar a continuació no m'agrada gens.

És difícil trobar gent bona per donar formació, de la mateixa manera que és difícil trobar bons programadors. Particularment aspir a que la gent acabi amb el convenciment de que després dels cursos en sap més que abans de començar, que la formació se li faci curta i es quedi amb ganes de saber-ne més.

He passat una estona rient pel post de James Carr anomenat Why must people degrade my profession. Pareix que aquestes situacions no són sols patrimoni dels informàtics patris, sinó que també companys de professió d'altres bandes també s'hi troben.

Potser l'article (el rant millor dit) ens fa gràcia perquè ens hi veim reflexats, però està clar que quan hom viu la situació no li fa gràcia.

Record que estan al càrrec del departament de suport de l'empresa un dels operadors va rebre una trucada, feia poc que s'havien començat a instal·lar impressores a color i algunes donaven problemes. Així que quan l'usuari va cridar i va dir que tenia problemes amb la impressora el primer que va dir el tècnic és:

(en castellà a l'original)

• ¿Impresora de color?
• Sí, claro, de color gris como las otras

Jo que l'escoltava em tirava pel terra, però a ell no li va fer gens de gràcia us ho assegur.

Hi ha una màxima que diu que no s'ha atribuir a la mala fe allò que es pot atribuir a l'estupidesa, i en soc un ferm partidari, però està clar que l'estupidesa a grans dosis pot ser desesperant. Ja sabeu: l'intel·ligència humana té un límit, l'estupidesa no.

Quan un es dedica a la gestió de projectes i a la programació les situacions són unes altres, però sovint també te dóna la sensació de que estan degradant la professió, bé per estupidesa, be per mala fe.

Curiosament el que sí me trobat és que aquestes situacions no es donen als projectes privats i sí als projectes d'assalariat.

En el primer cas la gent sol tenir més o manco clar el que vol, sap que la teva feina té un preu i que li cobraràs per allò que demani. S'escolten molt més quan els dius: "sí, això se pot fer, però serà car, te propòs que ho facis així i així i et sortirà més barat, tendrà més rendiment, etc.". Agraeixen la teva feina de consultoria i tu acabes satisfet per haver donat una solució al client, ja convertit en amic, que li estalviarà diners i que a més li permetrà tenir un sistema o aplicació de la qual tu també te'n sentiràs orgullós.

Perquè això és important. Per un bon professional, a més del sou hi ha l'amor propi d'haver fet una bona feina. Això no és patrimoni sols de la informàtica, he vist el mateix en picapedres, fontaners, sabaters, metges, ... Independentment de la feina són persones que tenen una cosa en comú: que estan orgullosos de la feina que fan i la volen fer el millor possible.

Pareix, o al manco així em passa a mi, que la cosa canvia quan qui comana la feina no s'hi juga res, i encara és pitjor si qui ho comana no és el mateix que ho ha de fer servir. Aquí les situacions que m'he arribat a trobar són directament de vinyeta de Dilbert. Si fa uns anys algú m'hagués dit que l'empresa posaria webs sense continguts i que no passaria res no m'ho hagués cregut i ja en duim dues d'aquestes.

Tècnicament n'estic orgullós: les webs són ràpides, escalen bé, s'indexen bé... Però com a professional no puc sentir-me còmode amb la situació, m'agradaria veure la feina acabada, poder dir "veis això ho hem fet nosaltres" i no quedar empegueït.

La situació és encara pitjor quan intentes explicar les diferència entre una web B2C i una web B2B, del perquè algunes coses que es fan a un B2B on controles qui es pot connectar, el creixement de les peticions, al cap i a la fi; no es poden aplicar a webs on no saps com s'utilitzaran, ni si demà sortiràs a l'Slashdot o al meneame, o senzillament faran servir els teus serveis moltes planes que a la seva vegada no saps el nombre de visites potencials que poden tenir. Això que hauria de ser molt clar per qualsevol que entén com funciona Internet sorprenentment no es considera ni es vol considerar.

Com que ningú s'hi juga res, ni tan sols el prestigi, la posició que adopta alguna gent és la de no deixar fer la feina, deixar que el temps passi i evitar que els projectes avancin. No sé si això es fa de manera conscient o inconscient, però es una dinàmica descoratjadora per la gent que ens consideram bons professionals, que ens sentim orgullosos de que els projectes surtin i vagin bé.

Permetre dins una empresa aquest tipus d'actituds i no fer-ne res, és per mi un exemple de degradació de la professió i potser fins i tot de l'empresa. Per mi és pitjor que el que explica Carr, ja que en el seus cas i com apunten els comentaris, el que vol l'usuari és algú que li pugui resoldre els problemes i acudeix a qui té més aprop que creu que en sap més que ell. En el segon cas la degradació és més greu, ja que potser no és tan visceral, però sí que toca més els fonaments de la professió i amb unes repercussions molt més profundes, tant econòmiques com de motivació de la gent.

Aquest és un apunt d'utilitat pública, és a dir, potser és una xorrada per la majoria, però per si algú s'ha trobat en la meva mateixa situació crec convenient explicar-ho.

La cosa és que amb KUbuntu el Firefox no es porta massa bé. Quan un selecciona un radio button o un checkbox l'estil de la selecció fa que no sàpigues si realment has fet clic o no fins que no has pitjat a un altre lloc de la plana. Bastant molest tot plegat...

No hi havia manera de saber si era un bug o què, ja que cercava per Firefox Styles o chekbox i clar sortien milers de planes de disseny i javascript. Afortunadament per mi vaig arribar a la plana de larns que es veu tenia el meu mateix problema.

La solució passa per anar al panell de control de kde (Arranjament del sistema) i anar a l'opció d'Aparença. Seleccionam GTK Styles and fonts i en l'opció GTK Styles seleccionar Use another style seleccionant-ne un que no sigui el Qt, en el meu cas Raleigh, o bé es pot instal·lar el QtCurve:

     sudo apt-get install kde-style-qtcurve  qtcurve
     

Amb això els problemes de visualització de Firefox 3 desapareixen.

L'altra dia una persona es va posar en contacte amb mi per a veure si li podia ajudar en un projecte, que resultà ser un deathmarch en tota regla.

La cosa és que l'home es queixava de que no trobava gent formada en Python i Django. Normal, la gent formada està fent feina i la tecnologia és prou nova com per a que encara sols la gent amb més inquietuds informàtiques hi estigui aficada.

Personalment crec que és part de la responsabilitat de l'empresa la de formar els seus treballadors, i la d'aquests aprofitar les formacions obviament. Per una empresa l'objectiu fonamental seria el de tenir treballadors capaços de autoformar-se, d'aprendre noves tecnologies ràpidament. Després de tot la tecnologia, especialment la tecnologia web, avança a un ritme tant alt que l'expert d'avui es pot convertir en l'inútil del futur.

En els darrers mesos he estat donant cursos de formació interns amb Python i Django a la gent que desenvoluparà tres dels propers projectes web. Gent que es reciclarà d'altres tecnologies i que té com a denominador comú les ganes i la capacitat d'aprendre.

De l'experiència actual n'he tret dues conclusions que vull compartir amb vosaltres:

La formació de 30 hores en Python i Django no és suficient. Em varen quedar molts punts que m'agradaria haver tractat. Tot i això crec que orientar la formació en vàries tandes en lloc de fer maratons seguits permet a la gent assimilar millor els coneixements i donar temps a la gent per a que pugui investigar i anar ampliant coneixements pel seu compte.

El seguiment és fonamental. El mentoring és una tècnica molt eficaç per assolir i transmetre coneixements i és quelcom que no he vist contemplat mai en cap dels cursos que he m'han donat. Les empreses pareix que suposen que una vegada donat el curs l'alumne ja pot volar sol, i realment no és així. El seguiment posterior, l'anar polint imperfeccions, la de fer petits monogràfics dins un projecte concret és una tècnica que personalment m'ha donat molts bons resultats en el passat i crec que aquesta no en serà una excepció. Això si, un acaba molt cansat quan els components de l'equip estan enfora (antiproductiu? sí, no us diré que no, però ja sabeu la dita del català antic, "donde hay patrón...")

La cosa està doncs que la gent comença a ser prou productiva com per fer avançar el projecte, i que tenir un projecte on pot començar des de zero, els ajudarà a fixar coneixements, no tan sols de programació, sinó de la manera pythònica de fer les coses.

Una vegada acabat el projecte sols em quedarà anar a Ca'n Paco i comprar-me unes sabates noves, hauré de passar el ticket a l'empresa :-P

Ho he de reconèixer, tothom té els seus tics i un dels meus és la meva dèria per escriure ten text pla. Quan he d'obrir un editor de texts normals em fa molta peresa. Tot i conèixer com posar una negreta o una cursiva fent servir combinacions de tecles em pareix molt més natural escriure amb un editor com vim o Kate o en les vegades que he de fer servir Windows el notepad++.

Es pot dir que "vaig veure la llum" quan vaig tenir que escriure el meu primer document de més de 100 planes ple de taules i imatges incrustades. Aleshores el Word era la única opció i va ser un vertader malson fins que ho vaig enviar a fer punyetes i vaig decidir escriure el document fent servir LaTeX. Vaig poder dormir molt millor!

Després vaig descobrir les meravelles del RestructuredText per a escriure documents tècnics i la simplicitat de la sintaxis dels wikis. Pels apunts al blog m'he passat directament al Markdown.

El text pla ens permet llegir els nostres documents en qualsevol editor, transformar-los en diferents formats, posar-los sota un control de versions i veure'n les diferències des de la web o des de el nostre client preferint de subversion.

Com tot en aquesta vida no hi ha res perfecte, hi cada cosa hi té el seu lloc:

• LaTex: per documents llargs, i/o que necessiten d'una presentació final amb molta qualitat.
• RestructuredTex : per a la documentació tècnica que no necessita tenir una presentació final tan polida com la del document LaTex.
• Markdown per aquest blog.
• wiki per la documentació compartida al mediawiki o al trac.

De tots aquests formats el LaTeX potser sia que costa més d'aprendre al principi i que té un marcat que dificulta un tant la lectura del text. Els altres llenguatges de marcat estan pensat per a ser bons de llegir i d'interpretar semànticament amb tant sols obrir-los a l'editor.

Quan veig gent que duu el control de versions amb un document Word anomenat document_v1.0.293b.doc deixat a al carpeta v1 del directori documents o coses semblants no puc deixar de pensar en com se complica la vida la gent amb tal de no aprendre res nou. La d'hores que s'hauran perdut mirant si el document que tenen en les mans és la versió final o per veure les diferències entre una versió i una altra (òbviament lo del control de versions dels documents, per a què!).

La informació cada cop circula menys en paper i més en format electrònic, potser seria hora que les empreses es plantegessin si una manera d'estalviar temps i recursos seria la d'ensenyar als empleats a fer anar un control de versions, a passar d'un document tipus Rest a un Pdf, a que les darreres versions dels documents són les que hi ha al subversion. La majoria dels documents que circulen per les empreses són de consum intern i sols necessiten ser llegits i entesos, assegurant que la informació que contenen està actualitzada, cosa molt més fàcil d'aconseguir amb documents de text pla.

Estar en la zona és estar en el nirvana de la programació, a l'estat mental en que les idees passen a línies de codi, on els dits es mouen pel teclat en un flux constant i quasi hipnòtic.

Estar a la zona no és fàcil però sortir-ne sí. Estar a la zona enganxa, de manera que una sortida de la zona sobtada sovint va seguida d'uns minuts de mala llet, dirigida contra el responsable d'haver pertorbat l'estat mental per excel·lència del programador.

Aconseguir l'estat mental adequat per entrar a la zona és una qüestió molt personal de cada programador, però ho podríem comparar amb els rituals de fan els esportistes abans de sortir a competir. Entrar a la zona significa complir amb un ritual, amb una lletania que ens ajuda a aconseguir les condicions de partida que ens han de dur al flux, a la zona. Per un és no tenir papers a la taula, per altres tenir la taula plena de papers, altres han de disposar totes les icones de l'escriptori d'una determinada manera, altres obrim les consoles que necessitarem abans de començar i les distribuïm entre els escriptoris de manera que ho tenguem tot distribuït tal com ens agrada, tal com ens va bé.

Quan un està a la zona el temps passa més aviat, a la darrera compilació li segueix una altra darrera compilació i així successivament, qui està a la zona se'n resisteix a sortir-ne i inconscientment voldria que l'estat de beatitud que es té duràs un poc més. Ja hi haurà temps per anar a dinar, "un moment que ara acab això...", "gairebé ja ho tenc,", frases típiques que a ben segur us haureu trobat dient-vos a vosaltres mateixos o a un tercer.

Per entrar a la zona s'han de donar les condicions adequades, l'ambient de treball hi influeix molt. Si hi ha interrupcions cada pocs minuts normalment ja ni s'intenta entrar a la zona, ja que sortir-ne una vegada hi has entrat és un petit trauma i les persones intentam evitar les experiències negatives.

Per això es recomana que els programadors tenguin els seus propis despatxos evitant telefonades, interrupcions i reunions innecessàries. L'estat mental productiu per a un desenvolupador és el de la zona, és l'estat que el motiva a anar a fer feina cada matí, és una llàstima veure departaments de programació "diàfans" amb telèfons sonant per tot, fins i tot n'he vist que a més de no tenir paret i despatxos estaven aferrats a la cafeteria.

La productivitat en el món de la programació passa per donar a la gent les condicions òptimes per fer feina. L'estructura organitzativa hauria d'estar orientada a que la gent que fa desenvolupament pogués fer-ho amb tranquilitat, gaudint de la seva estada a la zona. Potser per això la majoria gaudim més de la programació a casa que a l'oficina, a casa és més fàcil accedir a la zona i menys complicat mantenir-s'hi.

En Corey Goldberg escriu al seu blog damunt la llista de llenguatges de programació que coneix, amb la qual cosa ha iniciat un memme? ;)

La cosa està en llistar els llenguatges de programació en el que un se n'ha desfet en un moment o altre de la seva vida. És a dir, no val dir que un coneix el llenguatge Petito si no ha passat de "hello world".

En el meu cas i per ordre cronològic

• GW-BASIC
• Turbo Basic/Quick Basic
• Assembler 8086
• Shell
• FORTRAN
• Pascal
• Icon
• Matlab
• Modula 2
• Object Pascal (Delphi)
• SQL
• Python
• Forté
• C
• VbScript
• Java
• Javascript

Ja no es podríen classificar com d'haver fet res seriós:

• Fast (un llenguatge que generava .com especialitzat en fer jocs).
• Lisp
• C++
• Groovy
• Ruby
• C#

El Deplhi és un dels llenguatges que més he disfrutat de programar, però em vaig cansar de les tonteries de Borland i vaig trobar Python, quina gran troballa! Des d'aleshores no l'he deixat mai al Python, encara que altres llenguatges també s'han anant fent el seu lloc, el Python sempre ha estat en primera línia, encara que fos per generar codi per altres llenguatges.

Al blog de Carlos Blanco, en l'apunt realmente necesitas un inversor hi vaig trobar una frase que diu Aconsejo a los emprendedores que busquen inversión que primero se planteén si “¿Quiero ser Rey o Quiero ser Rico?“.

Estic traient la frase de context i no es ben bé la situació en que ens trobaríem, però crec que val la pena reflexionar-hi.

Quan hom munta una empresa ho fa amb una visió del que vol que sigui l'empresa, però sempre amb la sana intenció de poder-hi viure. Es a dir, fer pasta és una dels objectius de tota empresa mercantil, però això no lleva que a més hi pugui haver un objectiu social diferent.

A la pregunta de rei o ric podríem contestar: republicà! És a dir, hi ha diferents models i visions d'empresa que poden compatibilitzar el fet de guanyar-se la vida, fer diners i no plantejar-se la venda de l'empresa com un objectiu a priori.

La meva visió d'empresa se pareix molt a la que va dur a Joel Spolsky a fundar Frog Creek. Vull una empresa on la gent tècnica s'hi senti com a casa, que cada dia el motivi per aixecar-se del llit i fer feina, una empresa on es valori el talent individual i del grup. És a dir, aquell tipus d'empresa on a la gent amb talent informàtic s'hi pegui per fer feina.

A un seminari un consultor va amollar "motivado se viene de casa, no es la función de la empresa motivar a los empleados". No hi estic d'acord. És funció de l'empresa crear un entorn i unes condicions que motivin a la gent a fer-hi feina, i aquesta motivació no ha de ser una motivació externa (la pastanaga de doblers per objectius, per exemple) sinó una motivació interna, fruit de que la gent vulgui donar el millor de sí mateixa perquè així contribuirà a mantenir el lloc de feina on li agrada estar.

Accés a bon equipament, a la possibilitat de teletreballar, la possibilitat de trobar-te en un lloc de feina amb gent igual que tu, a que es valorin les opinions i les iniciatives, amb accés a les darreres tecnologies. Crec que això motiva més que cap altra cosa perquè fa que la motivació surti de dintre de la gent. Fa que pugui explicar als seus companys on fa feina i ho pugui fer amb orgull de ser part d'una empresa on la majoria hi voldrien fer feina.

I no m'interpreteu malament, el sou també és important, però no és el més importat a vegades. Suposem una empresa que te deixa teletreballar però que et paga diguem 200 Eur menys que una que té jornada partida i que està a 30 Km de casa. Una vegada has restat el dinar i la benzina resulta que la que fa teletreball te surt més rentable que l'altra, i si te paga el mateix ja hi estàs guanyant.

El consultors de RRHH intenten aplicar als tècnics informàtics les mateixes receptes que aplicarien a una cadena de muntatge, de manera que no se valora al tècnic i se'l té per intercanviable, no es valora el coneixement i el valor que pot aportar.

No és la meva idea d'empresa, i si algun dia, esperem que no molt llunyà, em veig a poder fundar la meva pròpia empresa vull que sigui tant per fer doblers com per demostrar que un altre model d'empresa és possible, que és possible anar a fer feina cada dia sabent que no ho fas sols per doblers, sinó perquè t'agrada estar allà i t'agrada el que fas.

Aquesta és la traducció del títol de l'apunt que fa Allan Packer, Are Propietary Databases Doomed on fa una més que interessant reflexió damunt el paper de les bases de dades lliures davant les bases de dades propietàries, i les pràctiques d'empreses com Oracle i IBM que fan que cada cop més gent es plantegi migrar cap a solucions no propietàries.

La tria de la base de dades està molt relacionada amb conceptes com la hipoteca tecnològica i l'escalabilitat, i l'efecte es tant més fort quan l'aplicació a desenvolupar ha de tenir un component web orientat al B2C. El que en un moment donat era una decisió de tipus "salvar el cul" i apostar per una base de dades propietària, davant l'èxit d'utilització del producte es converteix en un maldecap, ja que la suposada escalabilitat de la solució demostra no ser-ho tant en quant els beneficis se n'aniran darrera les llicències. Potser la tecnologia és escalable, però el cost no, i no tan sols això, sinó que ens condiciona l'elecció de hardware des del moment que la llicència va per processador, o el fabricant canvia la llicència per poder treure més suc del fet de tenir-nos fermats.

He sentit frases com "com que ja tenim Oracle desenvoluparem l'aplicació damunt aquesta BD", error, senyor meu, tu no tens Oracle, Oracle que té a tu, i desenvolupar una aplicació més que tiri d'aquesta base de dades no fa sinó estrènyer la corda, i si no recorda-ho la propera vegada que tenguis que canviar de hardware i tenguis que demanar equips antics amb menys cores, ja que no vols tenir que ampliar la llicència de la bases de dades.

En la part de negoci tradicional, on el nombre d'usuaris està molt limitat i poques possibilitats de creixement, ens trobam que les bases de dades lliures cobreixen perfectament les necessitats de la majoria d'usuaris i empreses, però és que a més, una per empresa que vulgui fer un desenvolupament web orientat al gran públic, triar una base de dades tancada per suportar l'aplicació és hipotecar el futur de l'empresa, on qui al final realment acabarà guanyant és la companyia que hi ha darrera de la base de dades.

Les bases de dades obertes representen una inversió de present i de futur perquè no el condicionen. Representen a més un estalvi pel present tant en forma d'estalvi en llicències com per l'augment de la capacitat de negociació que donen quan per alguna raó has de conviure amb el programari propietari.

En aquesta època de crisi, on les empreses estan mirant de retallar els seus costs de totes totes, és hora que es deixin de tonteries com retallar en els bolígrafs o en la qualitat del paper de bany i comencin a veure els beneficis que hi ha quan s'aposta per una altra model de programari, un model, recordem-ho basat en serveis i no en vendre trocets de paper que imposen limitacions artificials a la utilització d'un programari que és bàsic pel negoci.

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:

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ó

É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.

De tant en tant faig feina al blog, no per escriure-hi sinó per afegir-hi noves funcionalitats. Encara hi ha moltes coses que m'agradaria posar-hi i millorar, però a poc a poc esper anar arribant-hi.

A la darrera actualització he fet algunes millores que recomanaven al Google Webmaster Tools com la d'afegir descripcions úniques per apunt. Django a les seves plantilles té el filtre truncatewords_html que m'ha anat fantàstic per això.

Una de les millores que volia fer també era la d'amagar un poc tota la llista de mesos que hi ha. Aquest blog té apunts des del 2004 i la llista començava a ser molt llarga. Ara veureu que sols apareixen els anys (sempre que tingueu el javascript activat clar) i que en pitjar damunt ells es despleguen els mesos. Fer això ha estat entretingut perquè ha implicat jugar amb dos tags més de Django, el for per obtenir si estava a la primera posició del bucle o a la darrera, per tal de poder tancar els divs, i el tag ifchanged que ens permet saber si una variable (en el meu cas l'any) ha canviat o no respecte al seu valor anterior.

Amb aquestes eines ha estat possible muntar l'estructura necessària per a utilitzar un el Animated Collapsible DIV, una petita utilitat per jquery que permet ocultar i mostrar divs a voluntat, agrupant-los per categories si convé.

Ara la plana principal al meu entendre queda un poc més neta i amb prou espai a la columna lateral esquerra per anar afegint més coses.

En Domingo al seu blog fa una referència al meu apunt damunt llenguatges dinàmics i un bon grapat de bones reflexions.

Això de no creure's el que dic és una postura molt sana, sobretot perquè en la redacció d'un apunt me puc deixar detall i dades que són interessants. Una postura crítica ajuda a reflexionar i a completar les frases que d'altra banda s'haurien deixat com a dogmes de fe. Jo sóc del mateix tarannà, hi ha coses que me crec i coses que a poc que vegi indicis de contradiccions, doncs cerc més informació o deman explicacions. Això, he de dir també, m'ha causat força problemes en el món empresarial, on sovint el "no pensis" és una qualitat que ajuda a progressar.

Bé, però no me'n vull anar per les bardisses, o sí, ja que hi sóm, aprofitaré per dir perquè no faig servir el Twitter: no hi ha espai abastament :)

Afirmació: El nombre de línies de codi que escriu un programador al dia és una constant. Això és un efecte estadístic. Fa temps es parlava de que un programador escriu cinc línies de codi sense errors al dia. Està clar que és una dada estadística i fins i tot controvertida, ja que que és molt complexa definir què és i que no és una línia de codi i de que les línies de codi no s'han de fer servir per mesurar el rendiment. Tot i això podem trobar referències capítol 5 de Software estimation de McConnell on a la Taula 5.1 torbam la relació entre les línies d'un projecte i les línies de codi per programador i any. Això no vol dir que tots els programadors escriguin les mateixes línies de codi (de fet la productivitat entre programador pot arribar a un factor 10 -Peopleware-, però sí que en mitja i per a una organització i projecte, el nombre de línies de codi que s'escriu en promig és constant. A Sofware Mesurement and Estimation diu "Studies have shown that a proficient programmer can programm aproximately the same number of debugged lines of code per day regarless of the language". D'aquí que gent com QSM o David Consulting Group facin comparatives entre llenguatges per a comparar l'expressivitat de cada llenguatge. Per exemple C té un gearing factor de 128 i Java de 53. Això vol dir que una funció que en C necessita 128 línies de codi en Java en necessitarà en promig 53. Si un programador experimentat escriu, essent optimistes 10 línies de codi depurat al dia, llavors necessitarà 13 dies en C i 6 en Java (nombres redons).

D'aquí llavors que els llenguatges dinàmics, al necessitar menys línies de codi per fer el mateix poden completar els projectes en un temps més curt. Com que el temps significa doblers, implica que els projectes surten més barats.

Afirmació: el número de errores directamente proporcional al número de líneas que se escriben Aquí també entram en temes estadístics. De fet es parla de nombre d'errors d'un programa per mils de línies de codi. De la mateixa manera que en el cas de les línies de codi que escriu un programador, hi ha moltes diferències, però Casper Jones a "Program Quality and programmer Poductiviy (1997)" va recopilar algunes dades, que també cita en McConnell. També Reifer en va fer estudis, per exemple per la part Web estudià 65 projectes, i trobà que el ratio és de 6 errors per KESLOC (KESLOC Kilo (Thousand) Equivalent Source Lines of Code). Aquest nombre depèn força del tipus del projecte i de l'organització, però és estadísticament significatiu. Per tant, si donam com a bo el que els llenguatges dinàmics necessiten menys línies de codi per expressar el mateix que els llenguatges compilats tradicionals (Java, C, C+, ...) tendrem que el nombre d'errors en valor absolut també serà menor.

He trobat també una comparativa entre el nombre d'erros per Java i C++ a un paper de Geoffrey Phipps anomenat Comparing Observed Bug and Productiviy Rates for Java and C++, me l'he d'acabar de llegir, però conclou que amb un 95% de confiança C++ té 9,7 vegades més defectes per KLOC que Java i que a més els defectes en Java són més fàcils de corregir. D'aquí a fer una extrapolació cap a la banda dels llenguatges dinàmics hi ha sols un pas, sols falta que algú s'animi a fer l'estudi.

En Domingo també demana l'opinió damunt els llenguatges dinàmics per la capa de negoci, però això crec que dóna per un apunt per ell sol, així que ho deixaré per la propera vegada, però promet, amenaç, amb tractar-ho.

Al blog de Ricardo he esta llegint l'apunt anomenat "Lenguajes dinámicos, programadores y FUD" així com els seus comentaris. Tot i que hi he deixat allà un comentari amb la meva opinió, crec que com a programador en llenguatges dinàmics i tradicionals he de dir la meva.

El primer de tot que voldria fer és evitar el FUD damunt els llenguatges dinàmics, per una raó molt senzilla: la realitat és molt cruel i estam cansats de veure i de llegir damunt projectes web realitzats en Python, Ruby o PHP que estan triomfant i que no desapareixen o exploten per mor de no tenir un llenguatge compilat al darrera. Per tant, la primera cosa que hem de tenir clara és que la teoria pot estar molt bé, però la realitat ens està dient dia a dia que és possible escriure i mantenir programes en llenguatges dinàmics. A un li poden agradar més o menys aquests tipus de llenguatges, però el que no es pot fer és negar la realitat.

També m'agradaria focalitzar l'àmbit de discussió: estam parlant de programes web. Per programes d'escriptori no tenc dades abastament, potser perquè els llenguatges dinàmics brillen en el desenvolupament web més que en la part d'escriptori, llevat de que considerem el Visual Basic com a llenguatge dinàmic, clar.

La cosa està en que amb les màquines actuals els llenguatges dinàmics son ja prou ràpids com per ser competitius amb els llenguates compilats. Això no vol dir que siguin més ràpids, sinó que són prou ràpids per fer la feina i que la diferència de velocitat que hi hagi no sigui rellevant. Que PHP ens serveixi una plana en 1 segon i en Java la serveixi en 0,98 segons, doncs no és rellevant ja que per l'usuari de l'aplicació no significarà cap diferència en l'espera.

Això vol dir que ens hem de passar ja a programar en un llenguatge dinàmic i deixar els compilats? No. Vol dir que és necessari que a més d'un llenguatge tradicional convé que tinguem al caixò de les eines un llenguatge dinàmic. D'aquesta manera quan ens demanin una aplicació podrem sospesar els pros i els contres i fer-la en el llenguatge que s'adapti millor al projecte. Fins i tot si el nostre projecte es farà en un llenguatge tradicional, tenir un llenguatge dinàmic se pot integrar al projecte en forma de rutines de generació de codi, scripts de testeig, etc.

Dit això, i considerant l'àmbit de les aplicacions web, anem a veure avantatges i inconvenients d'elegir un llenguatge dinàmic per al nostre projecte, com que el que més conec és el Python, em permetreu la llibertat de donar els exemples i les referències en aquest llenguatge, in en Java en el cas de llenguatge compilat, en el ben entès que segur que hi ha el mateix tipus de solucions en Ruby, PHP o el vostre llenguatge dinàmic preferit i en C, C++ o .Net, etc.

Cicle de desenvolupament Agafem una aplicació web típica Java desplegada a un servidor Tomcat i la mateixa aplicació feta en Python. El cicle al primer cas és: escriure codi, compilar, corregir els errors de sintaxi, desplegar-ho al servidor, provar i iniciar novament tot el cicle, bé per escriure nou codi o bé per corregir els errors. A l'aplicació Python+Django tendríem: escriure codi, provar i tornar a escriure el nou codi. L'augment de productivitat la tenim no per el fet de no tenir que corregir errors, sinó pel fet de no tenir temps d'espera en el desplegament i per haver d'escriure menys línies de codi.

Errors de sintaxi. Aquí algun haurà pensat, "s'ha deixat els errors de sintaxi", efectivament, ho he fet perquè vull dedicar-lis el seu propi apartat. El compilador caça els errors de sintaxi i ens n'informa, però això vol dir que hem d'executar el compilador, és veritat que això els IDEs com Eclipse ho fan automàticament, però tot i això s'ha de fer. Realment podem fer el mateix amb eines com Pylint o Pychecker i a més el primer a més és capaç de treure tot un conjunt d'estadístiques damunt la qualitat del codi, talment com ho fan eines Java com PMD. El pylint per exemple és el que fa servir PyDev per a indicar els errors de sintaxi i donar avisos damunt el codi. Està clar que aquests errors potser no seran tan acurats como els dels compiladors, però són prou bons com per fer la feina, amb l'avantatge, però que ho podem llançar quan nosaltres vulguem i que no s'ha de passar necessàriament pel compilador per a executar el programa.

Per una altra banda, que el compilador o pylint ens caci els errors de sintaxi ens pot donar una falsa sensació de seguretat, el errors de sintaxis poden fer petar l'aplicació, és veritat, però els errors més greus solen ser els errors en la lògica de negoci de l'aplicació. Quan aquests se detecten el que s'ha de fer és corregir-los el més aviat possible, i en aplicacions web entram en

La fase de desplegament El temps que necessitam per posar una aplicació en producció seria anecdòtic si les aplicacions no tinguessin errors. Necessitar 30 minuts o 10 minuts per una aplicació que es posi en producció i que estigui mesos o anys sense modificar-se no és significatiu. Però, si l'aplicació sofrirà canvis o els errors que es detectin s'han de resoldre el més aviat possible, una diferència de 30 minuts en el desplegament pot marcar la diferència. En el cas d'un error en la lògica de l'aplicació que afecti a un .jar, significa en el millor dels casos compilar l'aplicació o el jar corresponent, substitur-ho i reiniciar el servidor d'aplicacions o l'aplicació, cosa que pot dur entre uns 30 segons y un bon grapat de minuts, depèn del que hi hagi desplegat. El el cas d'un llenguatge dinàmic sovint basta actualitzar els arixus afectats (svn update per exemple) i fer un reload del servidor Apache que tenguem. Cosa d'un parell de segons tot plegat. Està clar que podem minimitzar el primer cas amb servidors redundants i configuracions d'alta disponibilitat, però a un cost major de complexitat.

L'orientació a la tasca Les aplicacions web tracten fonamentalment amb text i produeixen text. Agafam dades de formularis, les tractam, obtenim dades de les bases de dades i les manipulam per a presentar-les a l'usuari en una sortida HTML, etc. Tractar cadenes és part fonamental de les aplicacions, i això és una cosa que els llenguatges compilats fan en general força malament des del punt de vista del nombre de línies de codi que s'han de picar. Els llenguatges dinàmics són força bons tractant informació textual. Posaré un exemple que ens pot servir per il·lustrar aquest fet: les plantilles. En Java tenim tres llenguatges de plantilles principalment: JSP-EL (ja ho sé està agafat pels pels però acceptau-me'l), Freemaker i el venerable Velocity i en general són força infumables. Comparem-ho amb el que hi ha per Python i veurem la diferència (Django, Web String, Cheetath, Mako, Jinja, ...). No crec que sigui anecdòtic, la diferència és que és força senzill manipular text en Python i per tant és força senzill crear-te el teu propi llenguatge de plantilles.

Productivitat El nombre de línies de codi que escriu un programador al dia és una constant. Això vol dir que si volem tenir més productivitat s'ha d'anar cap a llenguatges que ens permetin escriure més funcionalitat en menys codi. Donat el boom que viuen actualment els llenguatges dinàmics encara no hi ha molta literatura al respecte in encara no hi ha ni Ruby, ni PHP ni Python al QSM, però sí que hi ha forces comparatives, una de les més interessants és la d'Stephen Ferg que senyala que programar en Python és de 5 a 10 vegades més productiu que fer-ho en Java.

Diversió i motivació Els llenguatges dinàmics són sexy. Permeten al programador un alt grau de realimentació. Pot provar les seves idees molt ràpidament i això el motiva molt més que tenir que esperar a que el compilador acabi per poder fer les proves.

Pel demés, els llenguatges dinàmics també necessiten unit tests (sols que es poden escriure més ràpidament i amb menys línies), una gestió acurada dels projectes, planificació del que volem fer i refactorització del codi.

La conclusió de tot això és que deixem de banda FUDs que no duen a res i a l'hora d'avaluar un projecte considerem també si és apte per a ser fet en un llenguatge dinàmic, si ho és endavant, el nostre cul no perilla per dita elecció, ja que tant Python, com Ruby com PHP seran prou capaços de fer la feina.

El dia 22 d'aquest mes vàrem assistir a l'Event d'Alfresco Community Conference a Barcelona. Per a qui no ho conegui Alfresco és un DMS (Document Management System) lliure que ha agafat molta volada darrerament, encara que és un producte molt jove.

Per anar-hi agafàrem un vol molt prest, no eren encara les set del matí, i això vol dir aixecar-se a les cinc del matí. En favor de la gent d'Alfresco he de dir que les conferències varen ser prou interessants com per a mantenir-me despert, encara que no puc prometre que se m'escapàs el cap alguna que altra vegada.

A nivell organitzatiu les conferències varen estar molt bé: la sala molt ben preparada, amb traducció simultània fins i tot i la intendència (la teca) prou bona. Sols em va quedar el dubte de perquè un recinte amb capacitat amb tanta gent té uns excusats com els que té. Mai havia anat a un lloc on els tios fessin coa per anar al bany.

Punts anecdòtics a part, he de dir que vaig sortir força content de les conferències. Vàrem veure cap a on apunten les novetats d'Alfresco i de pas també es pogué veure cap a on desenvolupa la gent. Els d'Alfresco estan deixant els JSF, segons ells fan que les aplicacions siguin molt males de mantenir, i vàrem poder veure dues aplicacions, una feta per un desenvolupador independent i una altra oficial d'Alfresco, que tenien una cosa en comú: estar desenvolupades amb Extjs. Els d'Alfresco han fent una aposta molt forta per la comunicació de l'aplicació amb json, xml, rest, webdav, etc i segons vàrem poder veure han fet que sigui força fàcil poder publicar la informació en aquests formats.

Potser sigui autoconvenciment, però la cosa és que el tema del JSF no m'ha acabat de convèncer mai. Massa enrevessat i mal de mantenir, però és el que empreses com Oracle estan recomanant per fer el canvi tecnològic de Forms cap a la web, l'excusa és que hi ha dissenyadors visuals per JSF, però em fa por que amb l'excusa de la productivitat a l'hora de pintar pantalles s'estigui optant per una tecnologia que aviat quedarà obsoleta. La gent té tendència a anar cap a coses que agumenten la productivitat, deixen fer coses i els faciliten la vida, d'aquí que bastiments com Spring i Hibernate triomfin on els EJB varen fracassar.

La gent d'Alfresco pareix que ho veu clar i que s'estima més retirar-se ara i apostar cap a una altra tecnologia més mantenible per la capa de presentació. Potser va ser una de les millors conclusions que en vaig poder treure de la conferència.

La blogosfera en va plena Google ha llançat el seu appengine , un servei que permet hostejar aplicacions de fins a 500 Mb d'espai i 5 milions de visites mensuals que Google ha llançat i que té com a llenguatge vehicular el Python.

Per a accedir-hi un s'ha d'apuntar a la llista d'espera, ja que pareix que els comptes en fase beta s'han esgotat, i tot i les limitacions del sistema en el que fa referència als accessos als sistemes de fitxers, limitacions de la part de base de dades, que no es puguin llançar subprocessos i coses per l'estil, obre la possibilitat a tot un ventall d'aplicacions web.

On la notícia ha impactat més és a la comunitat Python: un llançament espectacular de Google, amb Guido pel mig, am Python com a protagonista i amb Django com a estrella convidada, ja que Django, encara que la versió "estable", ve de sèrie en el sistema.

Si encara no ho heu fet és un bon moment per aprendre Python i Django (ueps, tal volta seria un bon moment per publicitar-ne cursos :-P ) ja que un dels emperòs més grans que hi havia és que no se disposava d'un servidor a preus assequibles on poder fer anar les aplicacions. Ara amb el llançament de Google, les possibilitats de fer desenvolupaments amb Python i Django es multipliquen, limitats a les possibilitats de l'entorn que proporciona Google, sí, però permetran en breu començar a fer aplicacions web i hostetjar-les a un preu inmillorable.

Amb això esper a més que els hostingaires de sempre es posin les piles i donin a preus raonables allotjament per Django, proporcionant a més el servei que ara Google no ofereix: el de tenir una base de dades relacional pròpia al darrera.

I és que un dels grans problemes de l'oferta de Google és que no ets ben bé l'amo de la teva base de dades i algunes coses que permet fer l'ORM de Django molt fàcilment a l'ORM substitutiu de Google no es poden fer.

És clar que no totes les aplicacions necessiten d'una base de dades relacional al darrera, així que l'appengine de Google és per una part un bon banc de proves per veure com va això de la programació web amb Python i Django i per una altra una manera ràpida i econòmica de posar en producció projectes web que d'altra manera tendrien un cost prohibitiu pel programador mig.

En Corey Goldberg al seu blog a un recull interessant d'enllaços de lectura obligada per aquella gent que està fent la transició de Java o C# cap a Python.

Un dels més interessant és l'article de Phillip J. Eby anomenat Python is not Java on recull les diferències fonamentals que hi ha entre programar en Java o programar en Python. Una de les afirmacions més xocants és potser aquesta: Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters, és a dir "Els getter i setters són el dimoni. El Dimoni, dic. Els objects de Python no són Java beans. No escriguis getters i setters."

La frase pot semblar molt bèstia, i de fet ho és, ja que és una afirmació que s'ha de matitzar molt, com de fet ho fa en Ryan Tomayko al l'apunt Getters/Setters/Fuxors on s'explica molt bé quan fer servir aquest tipus de construccions, però en definitiva el que ens hem de quedar és amb la idea de que normalment Python no necessita mètodes accessors i que l'ús normal d'aquest és el de marcar un atribut com de sols lectura.

Com sempre hi ha "la manera de Python" de fer les coses, i sol ser la manera més senzilla de fer-les.

A un altre post ja vaig parlar de Hudson, un sistema d'integració contínua, relativament nou però que permet fer el que un necessita d'aquestes característiques de manera fàcil i amb una interfície molt cuidada.

Hudson es pot integrar amb Trac, de manera que al Timeline del projecte trac poguem veure com han anat les integracions sense tenir que anar al Hudson. D'aquesta manera la gent que fa el seguiment del projecte pot veure a més dels commits al subversions, modificacions al wiki i tickets, com han anat les integracions i quan s'han fet.

La integració dels dos aplicatius és força senzilla:

• Instal·lam el python-feedparser si no ho tenim ja al nostre servidor.
• Anam a http://trac-hacks.org/wiki/HudsonTracPlugin i descarregam el plugin.
• Descomprimim el plugin i amb permisos d'administrador executam python setup.py install això ens crearà el paquet egg i configurarà el plugin a nivell global dins el trac.
• Editam l'arxiu trac.ini del nostre projecte trac que volguem enllaçar amb Hudson i modificam la llista de components, en el meu cas la cosa queda com

[components]
iniadmin.iniadmin.iniadminplugin = enabled
webadmin.* = enabled
HudsonTrac.* = enabled

• Cream també una entra a anomenada hudson allà on posarem tant la url del rss del nombre projecte hudson que volguem controlar com el de la vista del projecte, de tal manera que s'hi crei un enllaç dins Trac

[hudson] display_subprojects = false feed_url = http://servidorhudson/hudson/view/Java/rssAll main_page = http://servidorhudson/hudson/view/Java/

• Canvia el servidorhudson pel vostre servidor. Aquí el que he fet és enllaçar directament contra la vista de projectes anomenada Java que he creat. Podria enllaçar a un projecte concret o a una vista relacionada amb el projecte que es gestiona amb el Trac.

Si s'han seguit aquestes passes i una vegada refrescada la plana del Trac, ens apareixerà una nova secció anomenada Hudson a la part de navegació del Trac que enllaça a la url que hem posat a main_page i al timeline apareixerà una opció que ens permetrà visualitzar les integracions, en forma de control check.

Pels que feu servir Trac de manera habitual, és interessant instal·lar-se també el plugin IniAdminPlugin, que ens crea un menú de configuració per web del trac.ini del nostre projecte.

És interessant a tot això adonar-se de que gràcies als formats oberts, en aquest cas al RSS que publica Hudson i que pot consumir Trac, dues aplicacions fetes en tecnologies totalment diferents es poden integrar.

Al Hudson passa una cosa semblant, està pensat per tractar amb format oberts, típicament sortides XML en format UnitTest, la qual cosa permet afegir-hi projectetes de Python, Java o SoapUI.

Aquesta setmana estic un poc tristot. El dijous vàrem tancar definitivament la web B2C posant el banner final de tancament i redirigint les planes que hi apuntaven cap a una marca blanca.

El dijous mateix ens va dir adeu la persona responsable del B2C, professional com n'hi ha poques i una de les persones que més coneixen el món de la venda on line en el seu sector.

Està clar que tot evoluciona i que els negocis no són per sempre, però aquest cas em sap un greu especial ja que hi tenia una forta implicació emocional en el projecte, per haver-hi estar estat en els seus començaments més llunyans i per l'amistat que m'uneix amb la que fins ara era la seva responsable i amb gran part del seu equip. Em sap greu pel tancament, per la gent que hi havia fent feina, però sobretot me sap greu perquè crec que el projecte mai no va tenir cap oportunitat.

No ha estat una sorpresa, sols era qüestió de temps, la web ha estat víctima de l'estratègia del powerpoint que tan habitual s'ha fet en algunes empreses.

Abans deien que el paper tot ho aguanta, ara podríem canviar paper per powerpoint. Pareix que si un objectiu es posa a una presentació aquest ja ha de ser factible i ja no importa justificar res més.

Quan les presentacions es converteixen no en una manera de resumir dades, sinó en les dades mateixes podem estar segurs que s'està seguint el mètode de direcció d'empreses powerpoint. Abans de tot això se'n deia fum i miralls i ningú s'ho creia; ara pareix que si li posam un envolcall tecnològic i feim unes presentacions ben xul·les i colorides perdem la perspectiva de que és possible i del que no.

Potser algun dia tothom se n'adoni que no per estar en una presentació el que hi ha és realitat, de que les presentacions sols han de servir per resumir, però que quan es tracta de dades sempre hi ha d'haver un suport darrera, i quan es tracta de negocis a més hi ha d'haver el pla de negoci i una estratègia. Llavors potser no no ens deixarem seduir per les transicions, els efectes i els colorins de les presentacions sinó que tocarem de peus a terra i serem capaços de demanar d'on surten les dades que sustenten la presentació.

Els anglosaxons són molt bons inventant nous termes per a fer referència a situacions típiques i expressar en poques paraules un concepte. En el món de la programació i projectes un dels que més m'agrada és de "pizza team", que descriu un equip de projecte d'un tamany adequat com per poder demanar una pizza quan hi ha hores extres a fer i no quedar amb gana.

No per això hem de deixar, però, que en tenguin l'exclusiva dels neologismes, així que aquí va la meva contribució: el programa trinxera.

El programa trinxera descriu aquell programa darrera del qual s'amaga un equip o una organització per tal d'impedir l'avanç de l'enemic. Qui és l'enemic és del tot irrellevant, potser una part de l'organització, un client, o els simples avanços tecnològics.

El programa trinxera es caracteritza per estar totalment acoblat, per la dificultat de saber per a un observador extern què fa el codi o perquè el programa fa el que fa. El programa és tan complexa que es requereix moltes vegades més feina saber el que fa que refer el codi de nou.

Per a que un programa trinxera sigui de qualitat a més ha de tenir moltes ramificacions, ha de ser un programa que faci de tot, que tant servesqui per gestionar l'empresa com per a enviar SMS. Cada necessitat que plantegi el client s'ha d'acabar lligant d'alguna manera amb el programa, d'una manera íntima i indissoluble, de tal manera que sigui impossible saber on comença un modul i on acaba un altre.

El programa trinxera es un gran devorador de recursos. Per la seva pròpia definició ha de ser totalment monolític i per a cada mòdul que se l'incorpora requerir més i més màquina. Com a bona trinxera ha de ser tortuós i amb molts llocs on amagar-se, de tal manera que si algun dia l'enemic es capaç d'entrar a la trinxera, se'l pugui estar esperant al proper racó per donar-li una sorpresa en forma de milers de línies de codi embullat i ineficient.

Per acabar de ser perfecte, el programa trinxera ha d'estar fet amb algun llenguatge obsolet, a ser possible mal de depurar i testejar, del qual sols els atrinxerats en saben algunes coses, no moltes, sols les justes per anar fent modificacions, però no les suficients com per a poder arribar mai a desfer el que s'ha creat.

En les darreres versions Python va introduir una modificació de sintaxi que permet no tirar tant de la programació funcional per algunes coses, el que es coneix com a list comprehension .

Encara que els exemples ajuden a fer-se una idea de com funciona la sintaxi, el que m'ha acabat d'obrir el ulls damunt la idea i la seva utilitat ha estat aquest article. En ell s'explica la sintaxi des del punt de vista matemàtic, és a dir, els matemàtics estan acostumats a escriure conjunts de la manera X = { x | x mod 2 = 0 } on x pertany als Naturals serveix per a indicar el conjunt dels nombres parells.

Els múltiples de tres, per exemple es poden escriure com

T = { 3x | x pertany als naturals}

Quan programam els nostres conjunts són finits, però la idea és la mateix i és ben bé la notació que es fa servir per la sintaxi de la list comprehension.

   parells = [2*x for x in range(0,10)]

   parells = [x for x in range(0,101) if x%2 ==0]

Si en lloc d'una variable en tenim dues, llegit en termes de conjunts matemàtics la notació té tot el sentit del món

parelles =[(x,y) for x in range(0,3) for y in range(0,5)]

Diu: conjunt de tots els parell on el primer nombre va de zero a tres (no inclòs) i el segon va de zero a cinc (no inclòs).

   [(0, 0), (0, 1), (0, 2), (0, 3), (0, 4), (1, 0), 
   (1, 1), (1, 2), (1, 3), (1, 4), (2, 0), (2, 1), 
   (2, 2), (2, 3), (2, 4)]

parelles =[(x,y) for x in range(0,3) for y in range(0,5) if x != y]

[(0, 1), (0, 2), (0, 3), (0, 4), (1, 0), 
(1, 2), (1, 3), (1, 4), (2, 0), (2, 1), 
(2, 3), (2, 4)]

Normalment hom ha sentit parlar de les economies d'escala, per exemple, en la reducció del cost d'un producte gràcies a la seva producció en massa. O per exemple en la reducció de costs que tenen dues empreses que es fusionen gràcies a la reducció de personal que suposa unificar la gestió dels seus processos: dur els recursos humans de 1000 persones pot tenir un cost no molt major que dur-los de 800, i segurament serà menor que mantenir dos departaments per separat que gestionin 600 i 400 persones. El mateix podem aplicar a processos comptables, o a l'àmbit de la producció i les compres, on el volum implica una reducció del cost final.

També hem de tenir en compte, però, que existeix l'efecte contrari, el que s'anomena deseconomia d'escala ( diseconomy of scale en anglès). Aquest efecte se dona quan amb l'augment de volum no s'aconsegueix una reducció dels costs sinó que els costs augmenten.

En el món del programari els efectes de la deseconomia d'escala no s'han de menysprear, ja que tenim per una part els factors comuns gairebé a totes les empreses i projectes i per una altra amb els relacionats amb qüestions pròpies del desenvolupament. Així, que un projecte sigui 10 vegades més gran que un altre, no implica que costi 10 vegades més, entra en joc la deseconomia d'escala i ens podem trobar que doblem el cost, i quan major és el projecte major és la desviació que podem tenir. L'esforç no escala linealment amb la mida del projete, ho fa exponencialment.

Factors comuns

• Cost de la comunicació. Un equip gran necessita major comunicació que un petit (de fet l'equip òptim està entre 5 i set persones), necessita de més coordinació, de més reunions i això té un cost en temps i esforç.
• Cost de la jerarquia. Sense entrar en efectes tan perniciosos com el del principi de Peter, quan més jerarquitzada està l'organització més alts són els sous dels seus directius i això s'acaba reflexant en el cost global del projecte.
• Factors polítics. El projecte es fa no per una necessitat sinó per fer quedar bé algú, o s'inclou una determinada característica inútil sols per no discutir amb el cap de torn.
• Temps de resposta. Quan l'organització és petita és senzill trobar respostes. Quan més gran és l'organització més complexe és poder organitzar les agendes i el projecte es pot aturar perquè no es troba ningú disponible en capacitat de decisió.
• Inèrcia. Moure una organització gran costa temps i esforç. Tant és si es mou per fer un canvi estratègic com per fer un projecte amb una nova tecnologia de programació. Quan més gent hi ha, més probabilitat hi ha de trobar sectors reacis als canvis.
• Duplicitat d'esforços. En organitzacions grans les possibilitats de que un grup estigui fent el mateix que un altre, que dues persones estiguin fent coses semblants augmenta. Això està lligat a la comunicació o a la falta d'ella. Mantenir un alt grau de comunicació implica un cost molt alt i molt de temps i no mantenir-la duu a la duplicitat d'esforços.

En el que fa estrictament relacionat al desenvolupament, la deseconomia d'escala la podem trobar a:

• Tendència cap a la mitjana de l'equip. En un equip reduït podem tenir ratios de productivitat molt alts si els seus membres estan per damunt la mitjana. En projectes molt grans la necessitat d'incorporar personal és tan gran que no és pot seleccionar al millor del millor, sinó al que hi ha disponible. La diferència entre els nostres millors programadors i els pitjors pot estar en una relació 10:1.
• Augment de la complexitat del projecte. És habitual que quan major sigui el projecte més complexitat tingui. Encara que la taxa d'errors sigui lineal amb el nombre de línies de codi, la complexitat influeix negativament en la taxa d'errors que hi podem trobar.
• Dificultats en les estimacions. Les calibracions dels models d'estimació que podem tenir deixen de tenir validesa si el projecte és major que tres vegades el projecte més gran que haguem fet.
• Necessitat de més controls al codi. Quan l'equip augmenta no basta fixar unes regles d'estil i esperar que tothom les compleixi. Ens hem d'assegurar que es compleixen, i això implica invertir en programari i en gestió.

Referències:

• http://en.wikipedia.org/wiki/Economies_of_scale
• http://en.wikipedia.org/wiki/Ideal_firm_size
• http://financial-dictionary.thefreedictionary.com/Diseconomy+of+Scale
• http://archive.adaic.com/docs/present/ajpo/pll-cost/html/tsld028.htm
• Software Measurement and Estimation: A Practical Approach. Laird & Brennan
• Software Estimation. Steve McConnell
• Peopleware. DeMarco & Lister

Hem d'anar a veure uns amics que tenen bessones i l'hi he explicat al meu fill petit, de quatre anys, la conversa va anar així:

• Anirem a veure uns amics que tenen filles bessones.

• Saps que vol dir bessones?

• Clar, que estan repetides!

Encara tenc la rialla a la boca per la contundència de la resposta.

Avui he acabat el darrer capítol del llibre d'Steve McConnell. El llibre prometia i he de dir que no està malament. Recull els conceptes bàsics de l'estimació de projectes i dóna molta bibliografia i temes per a aprofundir en els conceptes en els que McConnell sols entra de passada.

El llibre, a l'estil dels millors de McConnell es bo de llegir, i en aquest pareix que ha evitat entrar en fórmules o la part més dura de l'estadística, com si li fes un poc de por l'adagi de que per a cada fórmula perdria un lector. Això li lleva un poc de profunditat al llibre, però les referències incloses al manco poden servir de guia al lector que vulgui aprofundir més en aquests temes.

El llibre toca tots els grans temes de l'estimació de projectes, però no entre en profunditat a tocar cap metodologia, ni punts funció, ni estimació per casos d'ús, ni Mark II o Cocomo 2, per exemple. El que sí entra és en distingir els distints tipus d'estimació: de tamany, de l'esforç i de temps, posant de rellevància la relació que hi ha entre ells (que no són ni molt manco lineals). Algunes de les idees i gràfiques que hi ha al llibre mereixeran una lectura més detallada i segurament un apunt, ja que tenen implicacions interessants, com per exemple la del tamany òptim d'un equip de desenvolupament.

També és bo saber quin es l'abast del llibre de McConnell. Els mètodes d'estimació que presenta no serveixen ni per projectes petits ni per projectes de mil·lions de línies de codi. L'aplicabilitat de les tècniques que es presenten està limitada a projectes en el rang que va entre les desenes de milers de líness de codi i els pocs centenars de milers de línies.

En definitiva, garebé de tres-centes planes de lectura entretinguda, amb dades amb les que reflexionar i treballar, però que s'ha de complementar amb altres llibres de l'autor i l'estudi en més profunditat d'alguna metodologia d'estimació, després de tot, com McConnell mateix recomana, no és bo sols limitar-se a una única estimació i en aquest cas a un sol autor.

Un dels darrers projectes en el que estic implicat és una web a mig camí entre d'imatge i d'utilitat, que ha de premetre a l'usuari que la visiti conèixer els productes que oferta una de les marques de l'empresa. Per les raons que siguin, la direcció va decidir que del desenvolupament de l'aplicació se n'encarregàs una empresa externa i encarregar-me a mi la gestió tècnica.

La cosa està en que els productes a mostrar s'han de carregar a una base de dades mitjançant un backoffice propietari de l'empresa encarregada del desenvolupament. Amb la qual cosa tenim que el desenvolupament final són dues aplicacions: el backoffice per carregar les dades de producte i la part de presentació que s'ha de nodrir d'aquests productes per fer la web.

Després de suar sang per posar el backoffice damunt un servidor Tomcat vaig començar a fer quatre proves amb ell. Els camps obligatoris no estaven indicats de cap manera, així que la cosa anava un poc per prova i error. En una d'aquelles vaig aconseguir completar la fitxa del producte (o això pensava jo) i donar-li a guardar. A la una, a les dues, i .... pam! pantalla amb missatge d'error de la BD, d'aquests de "not null constrain violated in field XXX_INFR" o una cosa semblant.

Oks, m'he deixat algun camp - vaig pensar-. El problema és que no sabria dir quin és. Si això me passa a mi, que estic més o manco acostumat a veure aquests tipus de missatges, quan ho vegi la persona o persones encarregades de introduir el producte, segur que això serà una font de problemes, ja que despistarà l'usuari i l'enlentirà en la seva tasca, a saber, introduir el producte el més ràpid que pugui.

Així doncs vaig cursar la petició formal de que s'indicassin els camps obligatoris amb la marca d'asterisc típica i que es controlessin els errors de validació de BD de manera que es presentàs a l'usuari final un missatge descriptiu.

La resposta va ser "el backoffice es sólo para usuarios avanzados" i que la petició estava fora de lloc.

No sé a quin món viu aquesta gent, però per mi aquesta contesta és el mateix que no voler admetre que el programa té errors, que no els pensen corregir i que ha de ser l'usuari el que assumeixi aquests errors i els eviti si pot. Un backoffice de càrrega de dades no pot ser mai per usuaris avançats, quan des del principi s'ha pensat que sigui personal no especialitzat qui carregui les dades.

No es pot fer recaure les pròpies errades damunt l'usuari, és prepotent i poc professional. Tot programa té errades, algunes són més fàcils de solucionar i altres menys. Sovint per manca de de temps i el sempre present "time to market" algunes errades queden allà de per vida, però s'ha de tenir present que hi són, posar-les damunt la taula i no culpabilitzar l'usuari de les mancances que té el nostre programa.

Markdown

Markdown és un llenguatge orientat a l'escriptura de documents de manera que siguin bons d'escriure i bons de llegir. Amb això comparteix la mateixa filosofia que altres com reStructuredText o Textile, és a dir, són llenguatges que permeten escriure la documentació de manera que sigui llegible directament en text pla.

Així com com reStructuredText és va força bé per escriure documents llargs i complexos, Markdown és ideal per al l'escriptura d'apunts als blogs, ja que a més del seu marcatge particular, permet incloure directament html si ho necessitam.

Mesclant markdown i HTML

• elements de bloc: Per poder passar a escriure HTML dins el document markdown he de tenir en compte que el codi HTML ha d'estar separat de la resta del document markdown per un línia en blanc i l'HTML ha de començar a la primera columna, és a dir, sense espais ni tabuladors. Si feim servir l'HTML no podem fer servir la sintaxi markdown, és a dir, una vegada inicial el bloc html tot allò és html.
• elements en línia: Podem utilitzar l'html així com vulguem, per exemple, podem fer servir indistintament l'asterisc o <strong/> per marcar una paraula o frase en negreta. Són elements en línia <span>, <cite>, <a>, <img> etc.

Elements de bloc

Paràgrafs

Per a indicar un paràgraf simplement hem de deixar una o més línies en blanc. La conversió que fa markdown cap a HTML fa que es generin marques de paràgraf <p>. Si volem generar sals de línies amb <br/> haurem de fer acabar el nostre paràgraf amb dos o més espais en blanc i seguidament pitjar la tecla de salt de línia.

Capçaleres

Markdown pot fer servir dos estils de capçaleres:

 Capçalera tipus H1
 ==================

 Capçalera tipus H2
 -------------------
  

o bé fer servir # per a indicar el nivell de la capçalera que volem fer servir, així:

    
    # Això és un H1
    ## Això és un H2
    ### Això és un H3
    ###### Això és un H6

encara que no és estrictament necessari podem fer acabar la capçalera també amb el mateix símbol. Per exemple:

    
# Capçalera H1 estèticament millor #

Citacions

Markdown permet citar text fent servir el símbol > davant cada línia que vulguem que figuri com a citada o davant el paràgraf. Així:

    
> això és una cita literal d'un text

queda com

això és una cita literal d'un text

Llistes

Podem fer servir llistes ordenades i no ordenades. Les perimeres es fan posant un nombre seguit d'un punt, i les segones amb un asterisc, guió o símbol de suma.

Per exemple:

Llista no ordenada

* Joan
* Pere
* Miquel

Llista ordenada

1. Joan
2. Pere
3. Miquel
  

No és necessari mantenir l'ordre de la nuemració en un llista ordenada, basta que hi hagi un nombre seguit d'un punt, a partir d'aquí Markdown ja ho generarà com toca.

Si els elements de la llista estan separats per una línia en blanc, markdown generarà tags de paràgraf al voltant dels elements de la llista. Si l'element està composat per dos o més paràgraf hem de tenir en compte que cada paràgraf de la llista ha d'estar identat al manco per 4 espais o un tabulador. Per posar codi dins una llista l'hem d'identar al manco 8 espais o 2 tabuladors.

Si per la raó que sigui no volem que s'inicii la numeració d'una llista, haurem d'escapar el punt amb la barra invertida .

Blocs de codi

Els bloc de codi van molt bé quan un ha de parlar damunt programació o té necessitat de posar un llistat de codi dins el text. Markdown genera el tag <code> si identam cada línia que formi part del codi amb un tabulador o quatre espais.

El bloc de codi continuarà fins a trobar un bloc que no estigui identat o fins al final de paràgraf.

Dins un bloc de codi els (&) i (< >) són gestionats automàticament pel makdown i convertits de manera que es pugui representar fàcilment codi HTML. Per a facilitar que es pugui escriure de markdown la sintaxis markdown no es processada dins un bloc de codi, la qual cosa, per exemple permet escriure aquest article.

Línia horitzontal

Generar una línia horitzontal <hr /> és tan senzill com posar asteriscs o guionets al començament de la línia i que no hi hagi res mes. Queda molt bé indicar visualment que es tracta d'una línia horitzontal decorant-ho un poc més. Per exemple:

queda molt més clar que si sol feim

*

Tot i això el resultat el mateix:

Elements en línia

Enllaços.

Per posar un enllaç la sintaxi és

    
[nom que ha d'aparèixer](url "text del títol")

per exemple:

    
[trespams](http://trespams.com "blog de trespams")

genera el codi

    
<a href="http://trespams.com" title="blog de trespams">trespams</a>

Si hem d'enllaçar recursos locals dins el mateix servidor, podem fer servir camins relatius, per exemple:

[mira Sobre mi](/about/ "sobre mi") per més detalls

Podem enllaçar també per referència i fer servir dreceres per escriure el link quan en nom i l'enllaç coincideixen:

     

   Tenc 10 vegades més tràfic des de [Google][] que des de
       [Yahoo][1] o [MSN][2].

[Google]:http://google.com  "El cercador Google"
[1]:http://search.yahoo.com/  "Cerca a Yahoo"
[2]:http://search.msn.com/
  

En el primer cas com que l'enllaç i el nom coincideixen ens bastaria posar el nom, en el segon cas feim la referència i també posam el títol i en el tercer cas hem fet la referència però no posam el títol. Això genera:

Tenc 10 vegades més tràfic des de Google que des de Yahoo o MSN.

La idea de les referències no és que siguin més fàcils d'escriure sinó que es fan per augmentar la llegibilitat del codi, ja que es veu que hi ha un enllaç però aquest no posa renou dins el codi.

Èmfasi

Per posar negretes o cursives feim servir el doble asterisc o l'asterisc simple respectivament. També podem fer servir el guionet de subrajat, doble en el primer cas i simple en el segon.

    
**Això va en negreta** i això _italic_

Si volem posa un asterisc * o un guionet de subrajat _ ho haurem de fer escapant els caràcters, així * i _.

Codi

Per indicar que estam escrivint codi, però que aquest s'ha de tractar com a un element de línia farem servir l'accent greu `, per exemple:

    
exemple de funció lambda `lambda x,y: x+y` 
en [Python](http://python.org "Python site")

exemple de funció lambda lambda x,y: x+y en Python

Imatges

Per a incloure una imatge la sintaxi és

    ![Text Alt](url "títol opcional")

De la mateixa manera que amb els enllaços, podem indicar les imatges per referència de manera que la sintaxi queda com:

    ![Text Alt][referència]
    [referència]: url/a/la/imatge  "títol opcional"

Altres

• Markdown ens permet dreceres per a la generació d'enllaços. Simplement hem d'escriure el nom de l'enllaç i envoltar-ho de < >. Per exemple l'enllaç http://trespams.com, s'ha generat com

  <http://trespams.com>
  

• Per escriure adreces d'e-mail també ho podem fer d'auesta manera, però en aquest cas markdown fa una conversió intel·ligent per mirar de fotre els spammers, convertir cada caràcter de l'adreça al seu equivalent hexadecimal.
• Per a escapar un caràcter amb significat especial a markdown ho podem fer precedint-ho de </li>

Agraïments

Aquest document és una traducció lliure al català del document original en anglès escrit per John Gruber. Ha estat escrit amb l'editor Kate de KDE com a part de la documentació en català de que esper que sigui aviat el meu nou programari per a la gestió del blog de trespams. Podeu trobar el document original en format markdown dins el subversion del projecte.

El 2007 ja fa les darreres i és temps de recapitulació i de pensar en quins són o poden ser els objectius pel 2008. La llista de propòsits convé que no sigui massa llarga, ja diuen que qui molt abraça poc estreny, però sí que convé que sigui ambiciosa, que motivi a fer coses.

Per mi el 2007 ha estat potser un any que podríem classificar de transició, han passat moltes coses i una de les més importants, que afecta a l'estabilitat laboral tindrà continuïtat dins el 2008 (esper!), dins l'àmbit tècnic el 2007 ens va permetre definir com seria l'arquitectura que volem utilitzar, i que també esperam que exploti dins el 2008. Supòs que per més d'un també ho haurà estat de transició, no oblidem que el 2007 ha estat any electoral i al Govern de les Illes i a molts d'ajuntaments s'ha canviat de color polític.

A la feina aquest 2007 ha estat mogudet, bàssicament per dos motius importants:

• Canvi de director financer. Encara que sóc una persona prou oberta als canvis aquest no ho vaig acabar d'entendre. Potser tenc massa implicació personal a l'assumpte, ja que a l'anterior director el coneixia des de feia temps i el tenc per una de les persones més íntegres, treballadores i amb una visió de les coses molt clara que conec. Els anys que he estat treballant amb ell n'he après molt, moltíssim, de com gestionar, de cultivar un esperit crític, de com es pot discrepar, discutir solucions i arribar a enteses... La relació d'amistat segueix i seguirà, però enyor la seva manera de fer les coses.
• Fusió amb First Choice. Segurament és una de les coses que més ha condicionat la feina dels darrers mesos. Pareix que entre els empleats de les dues bandes hi ha poca informació damunt el que pot passar i de les implicacions que això pot tenir a curt plaç. Com he dit abans el 2007 és de transició, sobretot perquè la gent està a l'espera de que les coses es defineixin al 2008.

A la part tècnica el 2007 ha suposat la consolidació de la feina amb Python i Django, consolidació que ha donat fruits dins el 2007 en forma de webs per l'empresa i fetes particularment i que esper que en doni molts més dins el 2008. Django ara per ara ja té gairebé tot el que necessit per fer el tipus d'aplicacions web que m'agraden. També el 2007 ha estat l'any del llançament de dos RIAs importants: Extjs 2.0 i Dojo. Encara que hi havia versions anteriors, la versió d'Extjs suposa poder fer aplicacions web on la part de presentació està gestionada per javascript. La combinació d'Extjs i Django és molt bona. Al 2007 hem començat a gratar a les possibilitats que té aquesta combinació, i esper que puguem veure aplicacions web realment espectaculars dins el 2008.

Pel 2008 tenc dos projectes que m'agradaria que prenguessin tota l'embranzida per fer-los una realitat: apsl i el nou blog de trespams.

apsl és un grup de desenvolupament web. Al 2007 hem començat a definir-ho i crear-ne la infraestructura, a poc a poc segons el temps i la feina ho deixaven fer. Parteix de la idea que el desenvolupament web actual i futur no és sols cosa del dissenyador o programador solitari, sinó que es necessita ja tot un conjunt de gent que treballi junta per aconseguir webs i aplicacions webs que sigui accessibles tant a les persones com als cercadors, sense oblidar que tot això necessita tota una estructura d'entorns de desenvolupament i producció que no se pot deixar de banda. I també en la idea de que els projectes, com passa en el programari lliure, poden avançar sense tenir que tenir a la gent fermada a una oficina, que el teletreball, amb petites dosis de presencialitat, serveix ben igual per dur a terme projectes i que aquest són tant o més controlables que si tens la gent a una oficina.

El nom pot ser tant "agrupació de programadors en software lliure", "advanced programming solutions on linux" o senzillament pensar que és un domini de quatre lletres, bo de recordar i de dir, que és fonamentalment com va sortir :) apsl vol servir també de marca paraigua, de manera que es pugui donar suport logístic i administratius a desenvolupadors, dissenyadors i tècnics que d'altra manera es poden trobar sols i sobrecarregats de feina que no els agrada. Moltes vegades he sentit parlar a companys de que feina mesos que havien d'haver presentat una factura a un client, de que no tenen temps de fer un pressupost, etc. És a dir, proporcionant la capa d'abstracció de la que parla Joel i al mateix temps no condicionar la llibertat que dona poder triar ells projectes en els que fas feina.

Al 2007 ens hem concentrat en crear l'estructura tècnica i legal necessària per donar suport a la idea: s'ha creat la web, s'ha definit el logo i la papereria necessària, s'han posat en marxa i configurat els servidors amb els serveis necessàris: apache, django, python, php, subversion, trac, correu, ldap, etc. etc. etc. mirant que tot pugui escalar fins allà on volguem i puguem. Al 2007 s'ha registrat la marca i el logo i iniciats els altres tràmits burocràtics. El tema de la marca era fonamental, ja que es vol basar tot el model de negoci en Internet, i la marca ha de ser un dels principals actius, i a la vegada és un dels temes més complexes, ja que el registre duu força temps, des de fa unes poques setmanes la marca ha estat definitivament reconeguda i concedida, així que el projecte té al manco les bases necessàries per començar.

Al 2008 m'agradaria poder consolidar el projecte: trobar prou finançament pel projecte que el permeti créixer, donar-lo a conèixer al teixit empresarial i començar a captar projectes importants que puguin determinar-ne la viabilitat. Els fonaments estan posats, crec que la idea és bona i necessària, el model de negoci pot funcionar i ara sols es cosa de poder dedicar-hi més temps per anar creant-ne l'estructura.

Del nou blog de trespams dir que la idea és substituir el Wordpress per un basat en Blogmaker, o el que és el mateix en Python i Django. Wordpress està molt bé, pero vull quelcom més, alguna cosa de la qual en pugui controlar les butzes i fer afegitons així com jo vulgui. Segurament amb Wordpress es pot fer, però vull que el blog es convertesqui també en un projecte mascota i per això n'he de poder controlar totalment el codi i el contingut.

En aquests moments la cosa ja està molt avançada, he creat un projecte a Google anomenat trespams, de manera que si algú vol mirar el codi, o fins i tot afegir-se al projecte ho podrà fer. Està completament basat en Blogmaker per ara, però l'he anat modificant per a que sigui l'aplicació en lloc d'un afegitó d'una web, adaptant-ho a la branca de desenvolupament de subversion de Django i modificant plantilles i codi relatius a la internacionalització. La idea és anar incorporant les correccions d'errors i codi no estrictament lligat a trespams a Blogmaker, però sense sacrificar la llibertat que em doni poder mantenir la meva versió del codi.

La conversió d'articles ja està acabada, els permalinks de Wordpress, comentaris i tracbacks es mantenen prou be. Les categories són un petit problema, però les he substituït per tags i la cosa pareix que funciona. Encara queda molta cosa a fer, però esper que al manco la part principal del blog pugui estar llesta a finals de gener del 2008, i a partir d'aquí anar publicant ja els pots directament contra el nou sistema.

Dos objectius ambiciosos, cada un en la seva pròpia mesura, un més social i econòmic, l'altra més tècnic i personal però amb la mateixa característica, el desig de que ambdós projectes puguin tenir èxit dins el 2008.

No, no he tret una travessa de futbol, tampoc hi jug, així que seria un poc difícil, però l'alegria de veure un 14 no sé si serà comparable.

La cosa va anar així: se'n va demanar fer un resum que comportava fer una consulta d'agrupació a la base de dades més gran que tenim en Postgres, ja n'he parlat altres vegades.

Era una consulta damunt camps no indexats, així que ja vaig suposar que torbaria un poc, després de tot la darrera vegada que la vaig consultar una de les taules implicades tenia gairebé un mil·lió de registres.

La consulta va tornar uns quants centenars de resultats i torbà uns 50 segons en tornar la resposta. Vaig fer una consulta semblant damunt una de les altres taules i torbà un poc més, gairebé minut i mig, també lògic, ja que en aquest darrer cas la quantitat d'agrupacions a fer era molt més grossa i tampoc no tenia cap índex llevat del de la clau primària.

Content amb la resposta ho vaig contar als companys, i vaig fer un count(*) damunt la taula, un 1 i un 4, és a dir un mi·lió quatre-cents mil registres i la base de dades se les havia menjat com si res.

L'altra taula, la més lenta en tenia un parell més, gairebé dos mil·lions, però, un moment, va dir un dels companys, la primera taula hauría de tenir més registres que la segona.

I efectivament, és veritat, la ment a vegades veu el que vol veure, i allà on jo vaig veure un mil·lió quatrecents-mil registres i havia catorze mi·lions i busques de registres.

La base de dades va tan bé i dona tans poc problemes que no hem reparat cap pèrdua de rendiment i la màquina que la duu habitualment està al voltat del 0% de càrrega.

Postgres: capacitat per manejar grans volums d'informació? sí Problemes? zero Caigudes? zero Manteniment? zero.

No sabeu la tranquilitat que et dona una base de dades així.

L'altra dia a un dels fòrums on hi estic subscrit un dels participants em va demanar de publicar una oferta de feina per a un lloc de programació en Java/J2EE. L'oferta era per un lloc de feina a Sevilla i a més de l'experiència en programació J2EE el candidat tendria

"como responsabilidad el análisis y diseño orientado a objetos, patrones de diseño, modelado de bases de datos, integración de aplicaciones, gestión de rendimiento y profiling de aplicaciones, así como de calidad de procesos de desarrollo."

Després de la publicació de l'oferta de feina i després d'un parell de dies, aquesta persona es posà en contacte novament amb mi per dir-me que del més de mig centenar de persones subscrites al grup sols una havia demostrat interès per l'oferta de feina.

Aquest tipus d'històries és bastant habitual pel que es veu entre la gent que es dedica a la selecció de personal. Posen una oferta que consideren atractiva i després s'estranyen del poc interès que ha despertat l'oferta, del molt que costa trobar gent tècnica. Anem a pams:

Les ofertes destinades per a personal tècnic han de ser concretes. No sé perquè però sovint m'he trobat que la gent té por a presentar-se a una oferta de feina perquè no compleix un dens n-mil requisits que hi solen haver. A vegades les ofertes de feina pareixen cartes al reis d'un nin de vuit anys, s'hi posa de tot, sense prioritzar i sense cap tipus de criteri.

Si estam cercant un programador J2EE doncs convé que ens centrem en que conegui la tecnologia, en l'experiència (2 - 3 anys basta, més tampoc no garanteix res i eliminam candidats). Si consideram que és imprescindible també hi posarem els bastiments amb els quals feim feina a l'empresa i després com un "seria bo que ..." la resta. Per exemple, si cercàs un programador J2EE per fer feina amb el nostre grup demanaria experiència amb programació J2EE damunt Tomcat i coneixements d'Spring. Com a punts addicionals coneixements d'Hibernate, Acegi, Axis o XFire, haver treballat amb un control de versions y coneixements de Linux i Python. Però el focus principal estaria en el bessó del que s'està cercant. Després una vegada reunits els currículums ja se'ls podrà fer l'enquesta.

El segon punt important és indicar sou i horari. Darrerament estic veient que poques empreses posen el rang salarial que estan disposats a pagar. Això també frena als possibles candidats que ja estan col·locats a un altre lloc. Tenir que anar a una entrevista o actualitzar el currículum sabent que hi ha força possibilitats que el lloc de feina estigui més mal pagat que el que se té actualment no és motivant. Si la feina pareix interessant i a més el rang salarial està un poc per damunt que el que se cobra, doncs hi ha moltes més possibilitats de poder captar candidats que estiguin fent feina, i quan es cerquen candidats amb molta experiència aquests s'han de captar d'altres llocs.

El tema de l'horari també és important. Res motiva més que una oferta que digui "horari flexible", "possibilitat de teletreball" o que els divendres s'acaba al migdia. En un mercat on els rangs salarials són baixos i semblants a totes les empreses, el factor que pot diferenciar la captació d'un candidat o no són els beneficis addicionals que pugui aportar l'empresa. A igualtat de sou i hores, una empresa que faci jornada contínua segur que és molt més atractiva que una amb jornada partida.

La solvència de l'empresa també és un dels altres factors a tenir en compte. Si en lloc del típic "importante empresa de ámbito nacional" es pot dir el nom de l'empresa i aquesta té presència a Internet serà molt més atractiva pel possible candidat. De rebot podríem entrar aquí en l'apunt d'Enrique Dans, en el sentit que un blog corporatiu ajuda als candidats a fer-se una idea de l'atractiva (o no) que és l'empresa. No estic d'acord amb que un directiu pel fet de ser-ho tengui que tenir un blog, però sí que com a empresa es bo tenir un blog corporatiu un es pugui veure el rum-rum de l'empresa i la seva filosofia. En Joel Spolski pareix que ho té molt clar això: després de llegir els seus apunts a un li fan ganes de fer feina per ell.

En el cas de l'oferta d'aquest conegut no es deia ni el nom de l'empresa i a més l'adreça de contacte del seleccionador era una adreça de gmail. Bé, podria haver estat pijor i l'adreça ser de hotmail, però sigui com sigui són punts en contra de l'oferta i que no motiven a perdre unes hores actualitzant el currículum i a enviar-lo.

Per acabar un dels punts que al manco jo tenc en compte a l'hora de valorar una oferta és on és el lloc de feina. Que el lloc de feina sigui al centre de la ciutat on no es pot aparcar, o que estigui mal comunicat i tengui que perdre molt de temps en arribar-hi resten punts a una oferta. No serveix de res que una empresa pagui més si tanmateix després ho perdràs o en temps (o el que és el mateix en qualitat de vida) o en benzina, més l'emprenyo matinal de tenir que cercar aparcament. No diguem res si l'oferta, per molt interessant que sigui és a una altra ciutat.

L'empresari/cap típic està massa acostumat a valorar la feina, no per rendiment o projecte, sinó per presencialitat. És allò de que ja que no puc controlar la teva ànima controlaré el teu cos... Això implica que els candidats per molt bons que siguin estaran limitats als del propi entorn geogràfic o bé als que estiguin disposats a traslladar-se a viure a una altre lloc, i el treball que això representa sovint no compensa l'esforç.

És mal de fer trobar programadors? No ho crec, el que és mal de fer és trobar bones ofertes de feina.

Suposem que tenim una base de dades de factures i algú ens demana a veure si li podem dir quina és la facturació total de cada any i la seva distribució en els diferents mesos. Això és el que s'anomena fer un crosstab report, és a dir, fer la transformació de dades que estan en files a columnes i normalment fer una operació damunt alguna quantitat numèrica d'interès.

Al blog d'Stephen Forte he vist un mètode que ens permet fer precisament això d'una manera elegant anomenat el mètode Rozenshtein. Stephen diu que n'està enamorat d'aquest mètode i és ben comprensible, el mètode és elegant i resol d'una manera senzilla el tema dels crosstabs reports a bases de dades sql. L'Stephen ho explica molt bé, però us resumiré la idea, es tracta de trobar una expressió numèrica que s'avalui com a zero o un que ens farà de discriminador de la columna, de manera que multiplicada per la quantitat que volem operar fa que aquesta es compti (quan l'expressió val un) o que no.

Per no repetir l'exemple de Stephen en posaré un de més senzill, suposem que tenim una taula on hem anat guardant els e-mails que hem rebut on tenim la data en que l'hem rebut. Volem saber quants e-mails hem rebut cada mes. A la taula mantenim un camp anomenat created_at que conté la data en que hem rebut l'e-mail. Podríem fer

select extract (year from created_at) as any,
count(id) as total,
sum(1 - abs(sign(extract(month from created_at)-1))) as "GEN",
sum(1 - abs(sign(extract(month from created_at)-2))) as "FEB",
sum(1 - abs(sign(extract(month from created_at)-3))) as "MAR",
sum(1 - abs(sign(extract(month from created_at)-4))) as "ABR",
sum(1 - abs(sign(extract(month from created_at)-5))) as "MAY",
sum(1 - abs(sign(extract(month from created_at)-6))) as "JUN",
sum(1 - abs(sign(extract(month from created_at)-7))) as "JUL",
sum(1 - abs(sign(extract(month from created_at)-8))) as "AGO",
sum(1 - abs(sign(extract(month from created_at)-9))) as "SEP",
sum(1 - abs(sign(extract(month from created_at)-10))) as "OCT",
sum(1 - abs(sign(extract(month from created_at)-11))) as "NOV",
sum(1 - abs(sign(extract(month from created_at)-12))) as "DIC"
from taula_emails group by 1

Això és un cas particular del mètode Rozenshtein, ja que com es pot veure el que feim realment és comptar registres. Sense fer les simplificacions cada més hauria quedat com

sum(1*(1 - abs(sign(extract(month from created_at)-MES)))) as "EL_MES"

El primer un correspon a la dada que volem operar de la fila, en el nostre cas és tan simple com dir que és 1 per a que la suma vagi comptant-les, però pot ser qualsevol operació que hi puguem fer. El mètode ho podem classificar d'idea feliç, però una vegada captat és prou senzill de fer anar. En aquest cas el que s'ha fet és extreure l'ordinal del mes i restar-li l'ordinal que correspon a la columna del mes que volem tractar. Aquesta operació ens donarà zero si la data de la fila que tractam és igual a la columna del mes o diferent de zero si no ho és. Per exemple,

extract(month from now()) = 11

ja que aquest post està escrit al novembre del 2007, si repassam l'sql veurem que els resultats qute tendríem per gener seria (11-1 = 10), per febrer (11-2 = 9), per octubre (11-10 = 1) per novembre (11-11 = 0 aja!) i per desembre 11-12 = -1.

Recordem que el que necessitam és un valor que sigui zero o un, i per això el que es fa és utilitzar la funció sign, que retorna -1 per valors negatius, 1 per valors positius i 0 pel zero.

Si després li aplicam el valor absolut (abs) resulta que hem aconseguit una funció que ens dona zero quan té el valor que nosaltres volem i un quan no el té, la restam d'un tenim just el contrari, és a dir, que valdrà un quan tengui el valor desitjat i zero quan no el tengui.

Aquesta funció és la que multiplicarem pel valor a operar, en el nostre cas 1 però podria ser perfectament el valor d'una altra columna. I ja ho tenim!

any   total    GEN    FEB   MAR  ABR   MAY   JUN   JUL   AGO  SEP  OCT   NOV    DEC
2007  100       10     10     19    20       5     15    8      5       2    5       1       0

L'article de Ricardo anomenat "Las matemáticas necesitan de sofware libre", m'ha recordat que tenia pendent fer un petit apunt damunt un programa que recentment ha alliberat SAGE.

SAGE a diferèncie d'altres opcions privatives permet veure l'algorisme que hi ha per davall dels càlculs i com les opcions privatives permet fer càlculs simbòlics i numèrics. A més compta amb opcions per enllaçar amb programes matemàtics privatius i lliures.

SAGE permet fer gràfiques, calcul simbòlic, calcul numèric i n-mil coses més, totes documentades al manual. I el millor de tot, el llenguatge de programació triat: Python.

A la web de SAGE també trobam una opció per poder provar el programa on-line, es poden fer proves, però va moooolt lent, tot i això es pot veure i provar la potència de la solució.

El llenguatge x és millor!.Quantes vegades no haurem sentit aquesta frase defensant un o altre llenguatge de programació. Tots tenim les nostres preferències, condicionades per la nostra història, coneixements i manera de pensar. Podríem dir que hi ha un llenguatge de programació especial per a cada programador, aquell en que se sent més còmode tant perquè el coneix com perquè s'adapta a les seves estructures mentals.

De tant en tant, però convé tocar un poc de peus a terra i comparar llenguatges, potser el llenguatge que ens agrada més no és el més convenient per la tasca a realitzar, o no es tan ràpid com ens pensàvem.

Una manera de comparar llenguatges és la de crear tot una sèrie de programets típics i desenvolupar-los en els llenguatges que vulguem estudiar i veure quin té l'execució més ràpida o consumeix menys memòria, i això és precisament el que han fet la gent de The Computer Language Benchmarks Game, aquí trobareu un entorn on poder comparar distints llenguatges i fins i tot si trobau que falta alguna implentació o que podeu fer un programa dels que se proposen de manera més eficient poder enviar-ho.

Com que escor molt cap a la web m'he entretingut a comparar un grapat de llenguatges d'script entre ells i després comparar-los amb Java o C#.

• Python i Perl en general són molt semblats tant en velocitat d'execució com amb consum de memòria. Sols a l'execució de fasta per la generació de seqüències de DNA llueix més Python per mor d'un consum de memòria molt més petit. També és interessant comparar com en el tema de les expressions regulars Python no queda tan enfora de Perl com un podria suposar-se i que queda molt millor que el PHP per exemple.
• Python i PHP. En general Python és millor, però no hi ha una diferència prou gran com per marcar la diferència en la majoria d'aplicacions, llevat de que tinguem que fer molts de càlculs, però clar, llavors potser un llenguatge interpretat no és d'entrada el més ràpid.
• Python i Java. En velocitat de CPU Python queda molt malament llevat de casos molt particulars com el regex-dna, així que si sols coneixem Python i Java i hem de fer molts càlculs millor el segon, si hem de tractar cadenes millor Python. El mateix seria aplicable a PHP o Perl. Si el problema que tenim no és la velocitat sinó el consum de memòria, ja ens podem anar acostant més a Python i mens a Java.

La pàgina té un nom molt apropiat i t'hi pots passar hores fent comparacions, mirant com està codificat cada programa, com és d'elegant el codi i les línies que s'ha necessitat per realitzar cada algorisme.

Comparar és divertit, però no sols de velocitat i consum de cpu viu el programador. Saber en línies generals com se comporta el nostre llenguatge habitual comparat amb els altres és sempre profitós, però ens hem de situar sempre en perspectiva i situar el llenguatge en la casta de projectes que desenvolupam. Si l'aplicació no té un consum de memòria o cpu intensius aquestes característiques del llenguatge potser importaran menys que la velocitat en la que podem formar als desenvolupadors, en la mantenibilitat de codi, en el nombre de línies de codi que es necessiten per implementar un punt funció, ... i sobretot hi té molt a veure la capacitat de la gent que programa. No serveix de res tenir un llenguatge ràpid si el nostre codi és erroni o totalment ineficient.

• L'empresa A és una empresa.
• L'empresa B és també una coneguda empresa local amb la qual ja s'hi ha fet feina.
• L'empresa C és una empresa consultora d'àmbit nacional i internacional amb la qual ja s'hi ha fet feina.

• Empresa A: desconeguda.
• Empresa B: amb referències i contínues visites dels comercials.
• Empresa C: empresa amb referències però coneguda per ser molt cara.

En Marcos m'ha fet arribar un interessant article anomenat Technical Debt, d'Steve McConnell un dels meus autors preferits. En ell McConnell ens parla del concepte del deute tècnic, és a dir, l'equivalent a l'import en hores de feina que haurem de pagar en el futur quan en el desenvolupament d'una aplicació prenem determinades decisions.

Per exemple, quan no posam comentaris al codi estam adquirint un deute tècnic, ja que més endavant la persona que ho tengui que depurar o fer-ne modificacions ho tindrà molt més mal de fer i hi haurà de dedicar més hores de feina. També contreim aquest tipus de deute quan per exemple decidim fer la nostra aplicació depenent d'una determinada base de dades, donant per suposant que no necessitarem portar-la mai a una altra. En aquest cas el deute pot fer-se palès quan tenguem la necessitat de canviar de base de dades o bé pot no aflorar mai si l'aplicació acaba el seu cicle de vida sense necessitat de canviar de base de dades.

Es distingeixen dos tipus de deutes tècnics, aquell en el qual hem caigut de manera no intencionada i aquell totalment intencionat i que respon a una decisió estratègica. Els no intencionats s'han d'evitar sempre, ja que no hi tenim cap control, dels intencionats n'hem de ser conscients i avaluar-ne la relació entre el risc que assumim i el possible cost d'aquest risc vers els beneficis que en podem obtenir.

Tal i com passa amb els deutes financers, aquests tipus de càrregues poden ser fruits d'una planificació a llarg plaç o bé per necessitats puntuals del moment. Tal com passa amb el deute financer que en tenim a curt i llarg plaç (la visa i l'hipoteca) podem tenir un deute tècnic a llarg plaç, com per exemple fer una aplicació depenent d'una versió concreta d'un sistema operatiu si sabem que no el canviarem en diguem tres anys, o bé a curt plaç, com algunes decisions que s'han de prendre per tal de sortir al mercat abans que la competència i que s'hauran de resoldre una vegada el programa estigui en producció.

En els dos exemples, es veu que el deute existeix: als tres anys les dependències s'introduïren del sistema operatiu s'hauran de eliminar, els errors les característiques no documentades de la versió inicial del programa s'hauran d'arreglar.

A més de saber que existeix el concepte de deute tècnic ens permet atracar-nos més cap el llenguatge que parla la gent que comana normalment els programes. Ajuda a ser conscient del cost de determinades decisions tècniques i a poder fer un símil entre el cost financer i el cost tècnic, de manera que es pugui fer palès un possible cost ocult, que després haurà d'assumir-se o no, en funció dels beneficis que hi pugui haver.

El clearsilver és una llibreria de plantilles que abans feia servir el Trac i que s'està substituint a favor de Genshi, una altra llibreria que segons la gent de Trac els causa molt menys problemes.

La cosa està, però, en que no es lleven les dependències fins a la versió 0.11 no s'eliminen les dependències de clearsilver i fins i tot en aquesta versió es mantindran les estructures necessàries per a que els plugins segueixin funcionant.

He pogut comprovar de primera mà el que es diu a la web de Trac, "clearsilver sucks", ja que amb Ubuntu i la versió 2.5 de Python no fa sino donar problemes, que sospit han acabat per tomar el servidor Apache 2 que tenim al webhosting virtual. En un primer moment he pensat que se'ns hauria tornat a oblidar el pagament, però no, tots els serveis eren vius llevat de l'Apache i als logs he vist un bon munt d'errors del tipus

   /usr/lib/python2.5/site-packages/trac/web/clearsilver.py:128: RuntimeWarning:

Python C API version mismatch for module neo_cgi: This Python has API version 1013, module neo_cgi has version 1012.

• Davallam el codi font: wget http://www.clearsilver.net/downloads/clearsilver-0.10.4.tar.gz
• Modificam els arxius config i config.in, cercam les línees que diuen python_version i i afegint la versió 2.5 al davant.
• Descomprimim el fitxer tar xvzf clearsilver-0.10.4.tar
• Davallam paquets adicionals però aquesta vegada per apt-get
  • sudo apt-get install zlib1g-dev
  • sudo apt-get install autoconf
  • sudo apt-get install python-dev
• Feim el configure: ./configure --disable-wdb --disable-compression --disable-perl --with-python=/usr/bin/python2.5
• I per acabar el sudo make install
• Com que la instal·lació no acaba d'anar fina convé copiar la llibreria generada sudo cp -i neo_cgi.so /usr/lib/python2.5/site-packages/neo_cgi.so per acabar de substituir la referència que hi havia de la llibreria anterior o fer un ellaç simbòlic cap a la nova instal·lació de clearsilver: sudo ln -s ./clearsilver-0.10.4-py2.5-linux-i686.egg/neo_cgi.so neo_cgi.so

Referències:

• http://trac.edgewall.org/wiki/TracForPython2.5
• https://bugs.launchpad.net/ubuntu/+source/clearsilver/+bug/114930
• http://trac.edgewall.org/wiki/ClearSilver
• https://launchpad.net/ubuntu/+source/clearsilver/+bug/86685

Això de que a l'estiu les coses van més a poc a poc és veritat en la majoria de coses, però no en l'enviament de llibres. El dimarts vaig rebre l'avís de que ja podia anar a recollir a correus els llibres d'Amazon que havia comanat no feia ni deu dies i que se suposava que havien d'arribar damunt el vint-i-quatre d'aquest més.

Els dijous ja les tenia, després de l'obligat pas per correus. No sé com s'ho fan els de correus del meu poble, però la cosa és que quan es tracta d'entregar llibres mai ens hi troben, ni tan sols quan l'adreça és la de la meva sogra, que normalment sempre és a casa.

Però bé, la cosa és que hem començat a fer una ullada a les noves adquisicions i la cosa pinta bé:

Facts and Fallacies of Sofware Engineering Robert L. Glass Ed. Addison-Wesley ISBN 0-321-11742-5

Software Estimation Steve McConnell Microsoft Press ISBN 978-0-7356-0535-0

wxPython in Action Noel Rappin & Robin Dunn Manning ISBN 1-932394-62-1

El primer el vaig comprar per les contínues referències que hi veia a altres llibres d'enginyeria de programari. Pel que duc llegit fins ara crec que no serà el darrer llibre que compri d'aquest autor. 55 fets i 5+5 fal·làcies que tracten gairebé tots els aspectes de l'enginyeria de programari. El llibre sols mostra fets i ens fa reflexionar i fins i tot ens anima a no estar d'acord amb l'autor. Ara per ara sols duc llegides una trentena de pàgines, però si la qualitat de tot el llibre és com el que he vist fins ara trob que disfrutaré molt llegint-ho.

El sofware estimation de McConnell no sabia si comprar-lo o no, després de la mala experiència amb el llibre anterior de McConnell, però al final vaig decidir donar-li una altra oportunitat. La primera impressió és positiva: bona edició i maquetació, espaiat correcte i ple de gràfics, taules i alguna que altra fórmula que ja era present al Rapid Development. Serà el següent després del de Glass.

El wxPython in Action l'he comprat com una manera de contribuir al programari lliure. Robin Dunn és un dels principals mantenidors de la llibreria wxPython, i el llibre és una manera com un altra de reconeixement a la feina feta. A més, pel que estic vegint el llibre és molt complet i toca tots temes de la programació d'interfícies gràfiques amb aquesta llibreria. Un dia d'aquests m'agradaria poder fer el mateix amb PyQt4.x A més de la contribució a ben segur que li acabaré traient profit.

Des del blog de Ricardo Galli me n'assabent de dos articles [1] molt interessants damunt els ERP, a més obviament del seu(s) propis escrits.

Particularment el ERPs em fan molta grima, tant perquè la majoria són programes tancats que fermen als seus usuaris, per la manera que es comercialitzen i perquè representen una manera de fer programes allunyada del que es consideraria bones pràctiques de programació.

D'ERPs conec l'Oracle Financial, Navision i SAP, encara que aquest darrer molt de passada i tots ells tenen un problema fonamental: és l'empresa la que s'ha d'apatar a l'ERP. Si no es fa així els costs d'adaptacions són tan grans que ben bé l'empresa podria haver-se permès crear els seu programari a mida.

Però clar, la manera de comercialitzar un ERP és dir que el programa fa tot el que necessita l'empresa i més, que té tots el mòduls i que en tot cas sempre es podran fer adaptacions.

La realitat però, és que una vegada s'ha convençut a les altes esferes de la bondat de l'ERP i ja s'ha desembutxacat una quantitat més que considerable en llicències de l'ERP i la base de dades i comença la fase d'implantació i adaptació l'empresa ja està agafada. Si vol seguir fent feina de la manera que sap fer i que és el seu factor competitiu, haurà de fer mils d'adaptacions a l'ERP, adaptacions que es cobren a preu de canari jove i que poden doblar o triplicar el cost en llicències de l'ERP. La història de que la gent de l'empresa podrà fer adaptacions sense problemes no és més que això, una història. La realitat és que l'ERP és tan complexe que els propis consultors reconeixen que tenen gent especialitzada en un mòdul concret del producte.

I després venen les actualitzacions de versions. Actualitzar torna a ser com a una implantació. En vaig viure una indirectament i sols veies gent de la consultora anar i venir, fent hores i més hores. El cost: prohibitiu! I sols va ser un canvi de versió!

Els ERPs són el fast-food del programari de gestió. Prometen una solució ràpida, però després resulta que has de fer coa per a que t'atenguin i si en menges molt tens assegurada una indigestió. Els ERPs també prometen una solució immediata a les necessitats d'informatització d'una empresa, però es cuide'n molt de parlar-te dels temps d'implantació que s'aniran allargant, dels riscs de la implantació i del que et costaran les futures actualitzacions.

Si parlam d'enginyeria de programari hem de parlar del costs de desenvolupament dels projectes i de la quantitat d'errors i del cost del maquinar. Es ben conegut que un programa de 100.000 línies no té un cost 10 vegades major que un de 10.000 línies, sinó que el cost és sensiblement major, i quan es desenvolupa programari per un ERP estan agafant tant les complexitats del programa que desenvolupam més les complexitats del propi ERP.

Els ERPs tenen desenes de milions de línies de codi, i per tant les possibilitats que hi hagi errors en el codi augmenten en la mesura que augmenta el nombre de línies. Si tenim un programa de 10.000 línies i una taxa d'errors de 5 errors per KLOC podem estimar que tenim uns 50 errors pendents de detectar quan el programa passa a producció. Com que segons Putnam-Myers el nombre de defectes per línies de codi és lineal, podem esperar que l'ERP tengui una taxa d'errors en la mateixa proporció o major, ja que el distribuidor es cuidarà molt de dir-nos quin és el ratio d'errors del programa o el temps necessari per la seva actualització. I si el nostre negoci depèn de fer adaptacions a programari que tindrà errors, que haurem de corregir mantenir i que possiblement perdrem en la propera actualització costossísima de l'ERP, doncs la cosa fa por, molta por. Però encara hi ha més, tothom pareix estar d'acord amb que els ERPs són complexos, molt complexos, i amb això la linealitat del nombre de defectes per KLOC no es manté, sinó que creix de manera exponencial, i això malhauradament no afecta sols a les línies de codi de l'ERP sinó a les modificacions i adaptacions que se facin, que hereten aquesta complexitat. Què vol dir això? Doncs adaptacions més cares, més males de mantenir i depurar.

Així que la cosa està clara, davant la opció de desenvolupar un conjunt d'aplicacions a mida per la nostra empresa o tirar d'un ERP hi ha que valorar no sols el cost d'implantació de cada solució, sinó els costs dels anys que vindran i com afectarà la implantació de l'ERP als nostres processos de negoci, ja que en lloc d'adaptar el programari al negoci haurem de fer les coses com l'ERP millor li vagi per gestionar-les.

Respecte a l'arquitectura orientada a serveis (SOA) he de dir que sí que ho veig com a una manera de guanyar independència de distintes capes de programari i augmentar la reutilització de codi, en forma de programes. Si se fa bé, tendrem serveis petits, molt orientats a una tasca, controlables. Podrem controlar la complexitat de cada servei i mantenir la seva taxa d'errors molt baixa.

Això implica no caure en la trampa que volen els fabricants d'ERPs actualment: tot serà un servei i ho podràs fer servir sempre que facis servir el nostre BPEL o el component X que te proporcionen. La idea és seguir-te tenint fermat.

El serveis ens poden ajudar a anar independitzant capes de l'ERP i anar fent millores sense tenir que llevar tot l'ERP de cop. Per exemple, podem fer un mòdul de facturació en forma de servei que al final deixi les línees de facturació en la manera que les vol l'ERP de torn. Si feim una aplicació de facturació que faci servir el servei, estam aïllant-la de l'ERP i si demà decidim anar cap a un altra ERP lliure o cap a aplicacions sofisticades i separades el cost d'adaptació serà molt menor.

Les empreses no necessiten que tot sigui un servei, necessiten que tot el que es pugui reutilitzar pugui ser un servei, i que els programadors puguin fer servir aquests serveix per anar montant les aplicacions. La metàfora del Tente no és aplicable, no es tracta de sols ajuntar peces, es tracta per una part de montar una arquitectura de serveis i aprofitar-la per crear aplicacions que aprofitin els serveis com si fossin llibreries, però això està molt lluny de joc d'anar encaixant peces.

Particularment és una idea que cada cop m'agrada més, però entesa d'aquesta manera. Per exemple, amb Java i llibreries com XFire o Axis és prou senzill publicar serveis Soap, però els serveis interns no tenen per què ser precisament SOAP, podem tirar de protocols més lleugers com l'XML-RPC per exemple i fer-los servir per augmentar la velocitat de comunicació entre els serveis i la nostra aplicació.

Aplicació, per cert, que no té perquè estar escrita en Java, la capa de presentació en Java, ja sigui Swing o web és feixuga i amb una velocitat de desenvolupament i instal·lació poc àgil. Podem tirar de llenguatges d'script per fer la capa de presentació i tenir el millor dels dos mons: la facilitat de creació d'interfícies d'usuari dels llenguatges d'script i la facilitat de crear serveis que tenen els bastiments de Java.

Tot i això, no crec que a curt plaç els ERPs desapareguin, hi ha massa inversió feta. Seria el mateix que dir que els programes fets en COBOL desapareixeran d'aquí no res. Canviar un ERP és molt costós, i a més hem de tenir en compte que potser l'empresa encara està amortitzant la darrera actualització.

[1] http://evora.mit.edu/smr/issue/2007/fall/01/ http://www.roughtype.com/archives/2007/08/erps_troubled_l.php

Trobar bona gent és difícil i trobar-la que a més es pugui integrar en un equip ja format encara ho és més. A les respostes d'anuncis de feina s'hi pot presentar molta gent i en poques preguntes sovint s'ha d'intentar esbrinar si la persona que tens al davant serà bona tècnicament i a la vegada la seva manera d'entendre la feina serà per l'estil de la que hi a al grup.

Encara que soni molt a tòpic hi ha una sèrie de regles heurístiques que quan parlam de programació web ajuden a fer-se una idea d'ambdues coses:

• Adreça de correu amb domini propi : suma un punt. Per mi vol dir que al manco hi ha una preocupació per cercar-se la vida i potser haver donat d'alta un domini. Tenir un domini implica que també es pot cotorrejar abans de la selecció i veure quins temes preocupen al possible candidat o candidata.
• Adreça de correu amb Hotmail: resta dos punts. Sovint també vol dir que estàs engantxa al messenger i/o que no ets capaç de diferenciar el tenir un correu per usos lúdics d'un per usos professionals. Serveix per a diferenciar la gent que el primer que intentarà fer és posar-se el Messenger.
• Edició d'HTML. Si el sols es sap fer servir el Dreamweaver resta de cop 2 punts. Implica que d'entrada es tendran problemes quan es tracti de modificar planes webs fetes a troços, pràctica habitual en la programació web. Si utilitza un editor amb resaltat de sintaxi suma un, si a més sap fer servi el vi/vim suma dos punts. Si no ha fet mai una plana web resta cinc punts de cop.
• Coneixements de CSS. Si ha maquetat pàgines amb CSS i sap perquè ho ha fet suma 2 punts. Si no sap perquè ho ha fet sols en suma un. Si no sap què és resta un punt. Tenir coneixements de CSS ajuda a saber el que es podrà fer en la pàgina.
• Coneixements de Javascript. Si els sap fer servir mitjanament suma un punt, si a més coneix alguna llibreries de les típiques suma un altre punt. Si sols coneix el que posa el Dreamweaver lleva un punt. Tot es pot aprendre, però si un ja té experiència en Javascript vol dir que realment ha programat per la web. Si a més abans ha dit que utilitzava un editor "per programadors" començarà a agradar-me força.
• Si sap què és l'arbre DOM suma un punt. Si no ho sap i ha dit que ha manejat força Javascript ens haurem de plantejar sèriament si ha està decorant el currículum.
• Si sap què són els estàndards W3C suma un punt.
• Si sap que és un sistema de control de versions suma un punt, si a més l'ha fet servir suma un punt més.
• Utilitzar Linux suma dos punts. Per una part vol dir que encaixarà millor en el grup, però objectivament vol dir que serà capaç de modificar una plana que no està al servidor local, estarà acostumant a que els noms dels arxius són diferents en majúscules i en minúscules, sabrà què és l'UTF-8, etc. I sobretot demostra ganes de fer coses i de no conformar-se amb el que fa la gran majoria.
• Utilitzar Firefox com a eina de desenvolupament. Suma un punt. En suma un altre si coneix dos plugins indispensables per al desenvolupament web.
• Conèixer un llenguatge de programació d'script suma un punt. Si aquest es Python o Perl en suma un altra. PHP o Ruby no puntuen més. Un perquè a un que fa programació web se li suposa un mínim coneixement de PHP i Ruby perquè no es pot distingir de si es fa per moda o per convenciment.
• Conèixer el patró MVC i saber-ho explicar suma un punt. El patró MVC s'ha convertit en omnipresent per la web i conèixer-lo i fer-ho servir indica que es una formació en programar pensant en la separació entre capes.
• Conèixer SQL suma un punt. No fer-ho en resta un. No puc concebre que algú faci webs dinàmiques i no tengui idea d'SQL.
• Conèixer els bastiments i llibreries utilitzades a l'empresa suma dos punts.
• Ser membre actiu de Bulma o algun LUG suma un punt. Indica que el candidat s'implica en el que fa i contribueix amb les seves aportacions.

Hem de dir que d'entrada el possible candidat ha de conèixer el bàsic que se li demana, és a dir, si l'oferta és per programador Java-J2ee, si ja no es sap cap de les dues coses doncs el més probable és que el seu currículum ja no passi pel filtre de RRHH. Si ho fa llavors ens trobam davant un currículum que pot ser vàlid o estar especialment decorat per l'ocasió.

Un currículum amb una puntuació d'entre 17 i 20 és algú que s'ho paga entrevistar amb més profunditat. Entre 13 i 16 convé fer-hi una ullada però no hi ha massa possibilitats així d'entrada, i si és menys que aquest valor doncs potser és millor no perdre-hi més temps.

Tant les opcions com les valoracions són elegides ad-hoc sabent d'entrada el tipus de gent que m'agrada i que potser encaixarà bé en el grup, empreses i grups distints poden tenir valoracions distintes. Segurament una persona amb una puntuació de 20 no encaixarà en un ambient poc dinàmic i que no tengui capacitat d'innovació.

Bona part d'aquest diumenge passat Trespams i el seu correu associat no ha estat accessible i la cosa ha estat tan greu que ha requerit un canvi de hostingaire. Anteriorment aquest blog estava hostejat a un VPS de Bitfolk. La configuració de l'VPS era la mínima permesa i la relació qualitat preu no era dolenta. Un poc lent per a dur el Wordpress i el correu i caigudes de unes poques hores de tant en tant, però sense tenir que plantejar-se canviar a un altre servei.

Diumenge però ens trobàrem que no es podia accedir al servidor. Al principi vàrem sospitar que era una caiguda com les altres i vaig reportar l'incidència. Però no, resulta que hi havia hagut un malentés en el pagament i ens havia tallat el servei.

La reacció típica és un poc entre comprensió i indignació. Comprensió perquè si un no paga no pot esperar servei, però a la vegada indignació perquè si fins aleshores els pagaments han arribat sense problemes i el lloc està actiu doncs cabria pensar que el hostingaire demanaria abans de fer una cosa així.

Res, que pagàrem la quota (del 6 juliol al 6 d'agost) i vàrem sol·licitar que es restablís el servei, amb la queixa de que "home això s'avisa!" en pitinglish. Idò no, ara per restablir el servei el senyor de Bitfolk diu que vol ara 3 mesos per avançat. Això en la meva terra se li diu xantatge asquerós. Li diem que perfecte, que com que ja hem pagat que ens restablesqui el servei i després ja discutirem el tema dels tres mesos, però que mentres el servidor ha de tornar a ser "viu".

En el e-mail final el tipus ens diu que no està d'acord en que les coses es tenguin que fer així i que no ens vol com a clients i que no ens restaura el servei ni tan sols els dies que ens queden i que hem pagat (tard, això sí, però pagat).

El més divertit de tot és que ens diu que per 8 lliures si ens pensam que paga a un enginyer el diumenge. Cony, vol dir que per aturar el servei no era també ell un "skilled engineer" fent feina el diumenge? I que es pensa que feim nosaltres? El seu temps és més valuós que el nostre?

Després d'enrecordar-nos del bona part de la seva parentela, es va procedir a passar tot el que teníem a Bitfolk cap a un nou servidor VPS, a BudgetDedicated per més senyes. Una feinada, fonamentalment de Bernat, però que gràcies a les còpies de seguretat i a la rapidesa del servei de Bugdget va fer que el canvi fos molt més suau del que potser es pensava el de Bitfolk.

Bon vent i barca nova Bifolk! Per cert, el servidor és sols una mica més car, però va més del doble de ràpid.

Un dels problemes que té el manteniment de una plana web dedicada a la física, matemàtiques o altres ciències, és com escriure i mantenir les fórmules i que quedi bé la cosa.

Per escriure fórmules res com el TEX o el LaTeX, que encara que hi hagi gent que digui que fent clic amb el ratolí va millor, quan un ha d'escriure moltes fórmules, numerar-les i mantenir-les no hi ha res com el poder teclejar. La gent d'OpenOffice manté un editor de fórmules per línia de comandes i curiosament els seus detractors diuen que és una mancança. Jo ho veig com un avantatge i una utilitat per gent que realment pica moltes fórmules o fórmules complexes dins el document.

Quan parlam de texts amb un fort component matemàtic i de fórmules a les planes web la cosa encara es complica més. Tradicionalment per representar fórmules complicades s'optava per scripts de conversió de TEX cap a imatges, amb una qualitat que la majoria de vegades era molt pobre i amb una integració amb la plana no massa encertada.

Hi ha però una alternativa molt bona, el jsMath que utiltizant javascript ens permet mostrar dins les nostres planes HTML fórmules amb qualitat professional.

He estat mirant els exemples i jugant amb l'editor interactiu de jsMath:

És una imatge i la qualitat no és ni la meitat de bona que la que s'aconsegueix amb el javascript, com podreu comprovar si anau al la plana de jsMath i en visualitzau els exemples.

Bé, no són exactament 10, però si 9.800.000 llargs de registres que hi tenim a una taula d'una base de dades Postgresql que en el seu conjunt pot tenir fàcilment quatre o cinc vegades aquesta quantitat de registres. I el motor de BD ho mou tot sense despentinar-se, sense requerir complicats tunnings de bases de dades i amb uns temps de resposta a les consultes que es mesuren en milisegons.

No vull ni imaginar el maquinari, el cost en llicències i en administració que requeriria moure això fent servir bases de dades privatives.

La millor manera de desfer FUD és veure que a ca un altre funciona.

A casa faig servir el Kdevelop, vi o Kate per programar amb Python. L'Eclipse per PPC em dona massa problemes i va massa lent com per a ser una eina pràctica, així que m'he avesat a fer moltes coses que faig amb l'Eclipse de manera menys integrada, és a dir, a maneta i amb línia de comandes.

Una d'aquestes coses és el subversion. Encara que hi ha força clients gràfics per subversions cap s'atraca als que proporcionen els plugins d'Eclipse, així que m'he acostumat a fer les operacions habituals en línia de comandes aprofitant la shell que tenen tant Kate, com Kdevelop. Les comandes més habituals que faig servir són:

• svn ci Em permet pujar els canvis
• svn update Baixar-me els canvis que han fet els companys
• svn add <arxiu> Afegeix un arxiu al control de versions
• svn status em permet veure es canvis pendents

La cosa està en que el subversion no suposa res respecte als arxius amb els qui fas feina. Per defecte no posa l'arxiu sota control de versions a no ser que tu li diguis. Així la combinacióde svn status i svn add és força habitual quan es tracta de pujar els canvis que hem fet. Amb svn status podem veure el que s'ha modificat i al llistat que ens proporciona marca amb interrogants aquells arxius que encara no s'han afegit al control de versions, per exemple:

?      apslweb/www/__init__.pyc
?      apslweb/www/logger.pyc
?      apslweb/www/models.pyc
M      apslweb/db

Com que els arxius de compilació no ens interessa posar-los a subversions resulta que la comanda svn status ens està mostrant molt de renou, per a evitar-ho subversion ens permet ignorar els arxius que nosaltres li diguem d'un directori, en el nostre cas, desde apslweb si feim

svn propedit svn:ignore www

Ens apareixerà un editor (el vim en el meu cas) que ens permetrà afegir-hi els arxius que volem que no apareguin al llistat de l'status, afegint *.pyc ja ho tenim.

Alguns professionals de les TI no deixen de sorprende'm, són capaços de contradir-se una frase després de l'anterior, intentant justificar l'injustificable.

L'altra dia algú es queixava del complexe i costós que resulta fer les actualitzacions dels productes d'Oracle, que si has de fer venir una múnia de consultors, que si les dependències entre productes són tan complexes que quan actualitzes un producte has d'anar molt alerta amb com afecta a la resta de productes de la companyia, etc.

Aquí a mi no me queda més remei que fer paleses les contradiccions: si és tan complexe de gestionar, si te ferma tant al proveïdor, com és que hi ha gent que encara s'entesta en fer nous desenvolupaments en una tecnologia que te ferma de manera que les simples actualitzacions de versions són un maldecap i amb un costs que són difícils de predir.

L'excusa de que el denvolupament amb Forms i PLs és més ràpid s'enfonsen ràpidament davant mètriques que ens diuen que el nombre de línies per punt funció són comparables en Forms o en Html (42 i 43 línees de codi per punt funció respectivament) i per la part presentació, de 46 de PL/SQL als 35 de llenguatges de l'estil d'Smalltalk (Python per exemple). [1] i això sense considerar aspectes que afecten a la productivitat com la facilitat de depurar el codi, de fer feina en grup, o de fer tests d'unitat.

Davant això, pareix que la raó fonamental de triar productes d'una companyia concreta com els d'Oracle, no són de menor cost o major facilitat de desenvolupament, sinó que pareix que són que així el responsable del projecte no té que pensar. No hi ha possibilitat d'equivocar-se a l'hora de triar l'arquitectura o els components perquè no hi ha arquitectura o components per elegir. Sols tenim el que els senyors d'Oracle han decidit que podem tenir, independentment de les necessitats reals que podem tenir. Això se diu com a FUD davant les eines i bastiments de programari lliure, on abans de començar el projecte s'ha de definir l'arquitectura que es farà servir i triar els components més adients per la feina.

A mi que algú em digui que elegeix una eina o una altra perquè així no té que pensar em dóna angúnia. La responsabilitat del cap de projecte en primer terme i del responsable de IT en darrer terme és assegurar-se que té el millor equip i la millor tecnologia a l'abast del negoci, de manera que es puguin respondre a les necessitats del negoci amb rapidesa. S'ha d'estar pendent tant de l'evolució del negoci com de les tecnologies informàtiques que poden fer que la resposta del departament d'IT pugui seguir l'empresa.

Que hi pugui haver gent a una empresa que en senti còmoda amb una solució que a mig o llarg plaç sabem que donarà problemes, que té molts costs ocults d'actualització i administració, que se senti còmoda amb el no pienses, nosotros pensamos por ti explica perquè empreses més petites, però amb gent que no té por a pensar cada cop més s'estan enduent més negoci o posant en marxa negocis innovadors. En el moment que els negocis comencin a adonar-se que necessiten innovació per avançar, quan comencis a mirar el perquè negocis més petits tenen més clients i fan més caixa amb un costs menors i se n'adonin de que el no pensar no és una alternativa podem viure un vertader d'altabaix a alguns departaments informàtics.

Comencem a pensar, comencem a voler pensar, demà pot ser massa tard.

[1] Font: http://www.qsm.com/FPGearing.html

• PL/SQL és més ràpid perquè està més proper a la BD. Fals. No ens ho hem de creure, el que hem de fer és mesurar-ho. Segons Lott una de les causes de Java pugui ser més ràpid que el PL és que la màquina virtual Java pot fer optimitzacions al vol (JIT) cosa que PL no pot fer.
• PL/SQL vs JDBC.El PL/SQL és molt bo quan sols hem de fer transaccions bàsiques CRUD, però quan l'algoritme té altra tipus de lògica l'avantatge s'esvaeix.
• Escalabilitat. Java és molt més escalable a un cost menor. Amb GNU/Linux traient partit dels processadors moderns multi-nucli afegir més nivells de concurrència a les nostres aplicacions és relativament barat.
• No tenc recursos Java o presupost per comprar més màquines, però ja he pagat per la BD i tenc gent que sap PL/SQL. Si la direcció d'IT diu que (1) el rendiment és important i (2) no es volen fer mesures de rendiment (benchmarchs) llavors tenim un problema important d'esquizofrènia. Si al responsable d'IT no li importa el rendiment, llavors per què fer proves de rendiment per començar? Si el rendiment no importa PL/SQL està bé. És lleig i mal de mantenir, però és una decisió del responsable d'IT. Bàsicament ve a dir, que si el responsable de programació selecciona un llenguatge no basant-se en el rendiment i la mantenibilitat sinó en altres consideracions, llavors està fotut, no hi ha res a fer: PL/SQL.

Un dels problemes que tenim els tècnics és que no estam acostumats a negociar, a parlar en públic ni a guanyar-nos la vida endolçant conceptes i fent metàfores empresarials. Per això sovint ens trobam amb que hem acceptat plaços d'entrega impossibles, treball extra per un programa que no estava pressupostat, etc. Davant gent que està acostumada a negociar per guanyar-se la vida, sempre partim en desavantatge i cal saber-ho. Si un sap o estan les seves debilitats i les fortaleses de l'altra pot orientar millor la seva estratègia de negociació per tal de no veure's sorprès pel poder de convicció de l'altra part.

Arrel d'una presentació d'estratègia que ens varen fer fa poc, vaig tenir la idea d'anar recollint algunes frases que allà s'havien dit i d'altres que he anat escoltant al llarg de la meva carrera professional i intentar explicar-ne el sentit:

• Falta profesionalidad. La culpa del que passa no és de la direcció sinó dels altres. Aquesta expressió sempre exclou al qui la diu i és el que més és pareix a dir, en un llenguatge políticament correcte, que tothom és un inútil llevat del qui diu la frase, que està per damunt del bé i del mal.
• Espero que seais profesionales. S'espera que es treballi més hores, amb menys recursos i sense cap tipus de compensació. Fixem-nos que el concepte és diferent quan ho diu un futbolista quan se'n va a un altre club, que diu que és un profesional, va allà on paguen més i que farà la feina el millor que pot i sap.
• Habrá que hacer un sobreesfuerzo. Vol dir que l'empresa vol que faceu més hores extres però que no les pensa pagar. Si les volgués pagar o compensar aquesta frase s'acaba amb un "que será debidamente compensado". En aquest cas la contesta ha d'anar en termes de "jo sóc un professional i no puc fer feina gratis". O en termes semblants que indiquin que un sols fa feina gratis per ONGs i organitzacions semblants que ho necessiten.
• La fusión implica aprovechar las sinergias entre las dos empresas. Implica que sobrarà gent a curt i mig plaç, però no es pot dir en clar no sigui cosa de que la gent s'ho vegi venir. Hi ha que estar amb l'orella posada i interpretar les accions dels propers dies a partir del significat real de la frase.
• Hay que salir bien en la foto. Traducció: el més important no és l'empresa sinó salvar el meu propi cul, així que faré tots els esforços possibles per fer punts davant els qui comanden.
• Esto es crítico para el negocio. Si és crític avui vol dir que no se va fer una bona planificació ahir. S'intenta arreglar la cagada posant pressió damunt altres bandes per tal que quan algú demani responsabilitats es pugui dir que la culpa és d'un altre.
• Es un término de escuela de negocio. Dit a una presentació es tradueix en un "he cursat un master a una escola de negoci i vosaltres no", però també té altres implicacions, "he cursat un master i vosaltres no, al master jo tampoc vaig entendre què volia dir, així que no ho sé explicar, però en tot cas la frase queda molt bé a la presentació i per això l'he posada".
• Los del departamento X son todos unos inútiles. Dit per algú que té responsabilitat damunt el departament X i del departament del qui escolta, implica un intent fer fer-se "el coleguilla" i mantenir a la gent dividida, de manera que uns no parlin amb els altres, no sia cosa que posant les notes en comú és descobresqui qui és el vertader inútil. Convé informar-se per altres vies del funcionament de l'altra departament. La primera aproximació s'ha de fer a través d'un tercer, ja que el més normal que aquesta mateixa persona hagi fet la mateixa afirmació damunt nosaltres al departament X.
• Nos hemos comprometido a tener X en Y días. He venut la moto a algú, dient que tenim llesta una cosa que no tenim i ara he de salvar la cara, però ara ja és cosa que ho faci un altre. Sol anar junt amb la frase de "es crítico para el negocio" i no anar acompanyat d'un pla de negoci ni de xifres que indiquin que el que s'està demanant sigui factible o econòmicament rendible. Sol ser una conseqüència de l'estratègia de "salir en la foto". En aquest cas la contesta ha de ser per escrit i amb la planificació de quan pot ser possible. La resposta de que "ens hi posam ara mateix" s'ha d'evitar. Millor un "deixa-m'ho pensar i te diré per quan ho podem tenir" seguit d'un petit estudi del que es demana.
• Dejadlo todo y ... També conseqüència de l'estratègia de sortir a la foto. Se tradueix en que la feina que se demanarà a continuació s'ha de fer de manera immediata prioritzant-la damunt la resta, i que després se demanaran responsabilitats per no haver fet l'altra feina. Hi ha que anar especialment alerta si qui ho diu no ho vol posar per escrit, ja que les possibilitats de que aquesta frase amagui un "brown traspassing" augmenten exponencialment amb el nombre de negatives a posar la petició per escrit.

• 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.

• 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.

• 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.

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ó

• GNU/Linux. Se'm fa molt difícil pensar en programció web i no pensar en el GNU/Linux. No ja per les eines que incorpora cada distribució, sinó per que comporta d'entorn de desenvolupament. Sovint hem de veure logs, canviar configuracions, anar a servidors remots a veure què està passant. Linux ens ho posa fàcil.

• Firebug En els temps de la web 2.0 i el javascript a totes les pàgines Firebug s'ha convertit en una "killer application" que converteix el nostre Firefox en un complet entorn de depuració de pàgines web. Podem depurar javascri
• pt, css, veure l'arbre DOM, canviar els estils... És una eina feta per gent que fa webs.
• Webdeveloper. Ve a complementar el Firebug on aquest queda un poc coix. Eines de validació, per omplir formularis, netejar cookies i un llarg etcètera.
• ssh + vim. Veure logs, edicions ràpides de configuracions o pàgines al servidor. Tot això és fa fàcil quan tenim un servidor Linux i eines remotes per accedir-hi. La gent de Windows segurament dirà que això també ho poden fer ells, és veritat, però no tant fàcil, net i amb un consum tan minso de recursos.
• Kate. Un dels meus editors preferits. Resaltat de sintaxis per pràcticament qualsevol llenguatge de programació conegut. Amb això i el vim tenim pràcticament cobertes les nostres necessitats d'edició.
• Kdevelop. Pels sibarites. Va un poc més enllà de Kate i integra navegació per l'arbre de directoris, ctags, integració amb svn,etc.
• Subversion. Sols des de la més absoluta inconsciència algú es pot plantejar fer programació seriosa i no mantenir un control de versions. Subversion és del milloret que hi ha.
• Trac. Una integració gairebé perfecte de ticketing, documentació i client de subversion.
• Eclipse. Un IDE fantàstic, possiblement tan bo com feixug de fer anar. És un devorador de memòria i recursos de màquina, però si aquest no és el nostre problema junt amb el plugins adequats pot convertir-se en el nostre entorn de desenvolupament per defecte. Especialment recomanants els plugins de Subversive i els del nostre llenguatge preferit

• jquery. Jquery entra dins el segon tipus de llibreries. Permet tractar molt fàcilment amb el Javascript i compta amb nombroses opcions per a afegir vistositat a les nostres aplicacions web: efectes de disseny, Ajax, ... Tot això guarnit amb un bon conjunt de tutorials i plugins.
• YUI. La llibreria de Yahoo entra dins la classificació de mixtes, ja que per una part té tot un conjunt de widgets i extensions per emular una interfície d'usuari de tipus desktop i per l'altra té un control d'events i layouts molt bó que simplifiquen moltissim la vida al programador, sense necessitat de tenir que optar per la part gràfica de la llibreria. A més s'ha creat una comunitat extensa al voltant de la llibreria i la documentació existent és molt bona.
• Dojo. Amb el temps pareix que Dojo es convertirà amb una de les llibreries de referència perJavascript. Ara per ara és una llibreria molt vistosa però que té una gran mancança: la documentació.

• Qooxdoo Té molt bona pinta pel backoffice, però li falta documentació.
• Rialto Té molt bona pinta. La interfície és molt agradable, però encara està força verd com per arriscar-nos a fer un desenvolupament complexe en aquesta llibreria.
• Zimbra Un altra d'aquestes llibreries pensades per fer-les anar sols en xarxa local o en connexions que no siguin les que ens acostumen els operadores espanyols.
• Tibco Un altre framework alliberat fa poc. És per sí mateix un complet entorn de desenvolupament. Feixug, però amb molta documentació.
• Plex Te bona pinta. Molt xml per fer interfícies i encar pocs widgets.
• ZK. Si algún dia he de fer una aplicació de backoffice per LAN ZK serà una de les meves primeres opcions. En poc temps el bastimet ha avolucionat molt i ja té una massa critica d'usuaris prou gran com per a poder-ho considerar un producte estable. El problema que té encara és el gran consum de recursos que té.

• Java. Estable i prou provat. Elegit per la majoria de desenvolupaments web empresarials. Sun pareix que finalment s'ha deixat de mitges tintes i va cap al codi obert. Quan anam cap a aquesta opció apareixen nous jugadors: Spring, Hibernate, EhCache, Jasper Reports, DWR... Una de les feines inicials del projecte és triar quins components es faran servir.
• Python + Django. És una combinació divertida de fer anar i molt productiva. Fa servir un model MVT i una arquitectura que fa que les aplicacions siguin molt escalables.

L'OpenOffice duu un complet editor d'equacions matemàtiques, motl útil quan volem escriure fórmules complexes dins el nostre document.

L'editor segueix un poc la filosofia de LaTex, és a dir, encara que té ajudes gràfiques es suposa que està pensat per gent que escriu moltes fórmules, i per tant, la interfície d'entrada és el text.

Com que a mi m'agrada molt LaTex per escriure documents llargs (tenguin o no tenguin fórmules) trob aquesta manera d'allò més natural, però com que no escric fórmules cada dia, doncs a vegades no record massa bé com es feia alguna cosa.

En concret sempre he d'anar a cercar com es fa per posar una sola clau a un sistema d'equacions. Cercant per Google, he trobat aquest enllaç que esper que també pugui ser d'utilitat als asidus de l'OpenOffice Math:

http://es.tldp.org/Manuales-LuCAS/doc-manual-OOMath/Math.pdf

Una fantàstica traducció del manual en format pdf i que des de ja figura dins els meus pdf preferits, junt amb la traducció de "In the Beginning was the Command Line" de Neal Stephenson

http://biblioweb.sindominio.net/telematica/command_es/command_es.pdf

Fan un anunci per la tele, apareix un home netejant una façana, apareix algú que es fa neta la boca amb un elixir bucal. L'elixir és molt potent, se veu, quan ho deixa anar per les canonades d'aigua bruta es veu com va baixant com una bomba,... Després una canonada d'aigua neta explota com per l'efecte de l'elixir i acaba de fer neta la façana. Tot molt gràfic, tot molt normal, llevat que no és correcte. Si explota la canonada hauria de ser la d'aigua bruta i l'home de la neteja no crec que estigués molt content com un sortidor d'aigua fecal pega per la façana.

Sorprenentment veim l'anunci i ho trobam d'allò més normal. Exagerat, potser, però és cosa de la publicitat. Llevat d'això tot ens pareix correcta, la nostra intuïció ens ha fallat.

Si això ens passa en coses que suposadament dominam, que vivim cada dia, quan ens situam en un entorn menys habitual, com el món del programari i la programació, la intuïció encara ens poc jugar més males passades. La intuïció ens diu que posar més gent a un projecte ha de fer que el projecte vaig més ràpid, però la realitat és que pot fer que el projecte no avanci amb la velocitat esperada. Això es deu a que afegir gent al projecte no implica un augment lineal de la productivitat, sinó que hi pot haver casos en que la productivitat fins i tot disminueixi.

Un projecte amb molta gent necessita de més planificació, d'una comunicació fluïda entre els seus components, i aquesta comunicació i coordinació fa que sigui necessari dedicar-hi recurssos que d'altra manera es dedicarien integrament al projecte, ja que en un equip més petit tendríem menys necessitat de comunicació formal.

Un altre dels factors que influeix és el que s'anomena tendència a la mitja. Si l'equip és petit, entre 3 i 10 persones és probable que puguem tenir un equip d'elit, però si augmenta el nombre de gent la tendència a la mitja suposa que sols podrem completar l'equip amb gent prou bona, però potser no tan productiva com la d'un equip especialment seleccionat. En aquest casos, la intuïció que ens diria que s'ha de fer més via també ens ha fallat, podem arribar anar més a poc a poc. Això no vol dir, però que no hi hagi avanç a mig termini, sinó que a curt termini podem esperar un retràs considerable, mentre les vies de comunicació es consoliden i tots els components es van adaptant, i tot i així, l'augment de components de l'equip no serà lineal: comunicació, formalització més acurada de procediments, més necessitat de control fi coordinació espenyen aquesta linealitat. I quan consideram l'equip del projecte no hem de pensar sols en programació, hem de pensar en tota la gent implicada: testers, managers, usuaris avançats. Quanta més gent més probabilitats que la tendència a la mitja jugui en la nostra contra.

Tot el que té a veure amb la tecnologia ha avançat molt ràpid, si amb conses que ja coneixem les nostres suposicions són incorrectes, hem d'estar previnguts de que en tot allò que fa referència amb la tecnologia encar ho poden ser més: escriure programes no és el mateix que escriure una carta, un ordinador no és una màquina d'escriure, una pantalla no és una fulla de paper, les webs no són equivalents a una publicació de paper, el que nosaltres considerem bo no te per què ser-ho pels nostres usuaris, d'aquí que es tenguin que fer proves d'usabilitat. Si es pot mesurar mesurem-ho, potser la nostra intuïció ens està fallant.

En moltes empreses per procediment es canvien tots els ordenadors cada quatre anys, quan el valor de l'equip s'ha amortitzat totalment.

Aquesta no és una mala pràctica pels equips d'oficina, però el café para todos és molt perjudicial en entorns de desenvolupament, on es vol aconseguir un ratio de productivitat màxima.

Anem a pams, suposarem que el cost d'un equip nou de trinca és de 600 € + IVA, en aquests moments estaríem parlant d'un Core Duo 2,13 GHz amb 2 Gb de RAM, és a dir una màquina prou potent com per poder fer feina amb entorns devoradors de màquina com la combinació Eclipse+Java.

Ens plantejam quan hem de renovar aquestes máquines, hem d'esperar als quatre anys o convé renovar-les abans? Podem fer una sèrie d'estimacions bàsiques que ens ajudaran a respondre a aquesta pregunta.

La feina d'un programador té un cicle d'escriptura de codi, compilació, proves i depuració. Si feim servir llenguatges interpretats de l'estil de Python, Ruby o PHP aquest cicle canvia, però per ara centrem-nos en lleguatges més clàssics com .Net, Java o C++. Aquest cicle, i per exemple el desplegament de l'aplicació en un servidor d'aplicacions local com Tomcat o JBoss, implica que per a cada prova que es fa es perdren entre 3 i 6 minuts per prova (compilació o generació dels bytecodes, còpia al servidor, desplegament de l'aplicació, inici del navegador i començament de les proves).

Suposem també un sou brut d'un programador de 24.000 Eur anuals, i que hi ha 223 dies efectius de fiena, és a dir, el cost per diar de programador sols en sous és de 107,62 Eur.

Considerarem vàlida la llei de Moore i considerarem que als 18 mesos de fer la nostra compra, podem comprar un nou ordinador, més o manco pel mateix preu que dobla les capacitats de procés del nostre ordinador actual, amb la qual cosa el temps d'arrancada és pot reduïr a la meitat. Serem conservadors i donarem un marge de 2 anys.

Amb això tendríem:

• Valor pendent d'amortitzar: 300 Eur
• Temps mort per prova 3 - 6 minuts
• Nombre de proves per dia : 10
• Sou per dia del programador: 107,62 Eur
• Dies útils de programació : 223

Ara ens plantejam canviar la màquina, està clar que la màquina als dos anys no està amortitzada, tot i això, ens podem plantejar donar de baixa la màquina i que l'operació encara sigui molt rentable per l'empresa.

Si consideram una pèrdua de 3 minuts per prova tindríem que el temps anual en hores perdut és de 111,5 hores, és a dir 13,94 dies. Si anam als 6 minuts per prova, resulta que pràcticament un mes de feina es perd esperant a que la màquina estigui a punt per provar.

Canviant la màquina per reduïr el temps d'espera suposa un estalvi d'entre 1.500 Eur i 3.000 Eur l'any per programador si suposam que podem col·locar la màquina antiga o d'entre 450 Eur i 1.200 Eur si directament la regalam.

És a dir, canviar d'equip cada 2 anys per disminuir el temps d'espera entre compilació i proves, pels temps que estam manejant és justifica completament.

A més, però tenim un altra benefici tangible: augmenten les hores dedicades al projecte i disminueix la frustració que suposa tenir que esperar un parell de minuts entre que vols començar les proves i aquestes comencen.

Si no canviam màquines, el que tenim són directament pèrdues, per una part perquè deixam de tenir l'estalvi produït per la inversió que no hem fet, però a més, hem de tenir en compte que amb els anys les aplicacions tendeixen a fer-se més grans, més complexes i per tant ens podem trobar sempre en l'escala superior de temps d'espera.

Una manera de lluitar amb aquest efecte és anar cap a llenguatges i entorns que no tenguin aquests teps d'espera, és a dir, desenvolupar amb llenguatges dinàmics com Python, PHP o Ruby. En aquests casos el temp d'espera es redueix pràcticament a zero, i tendriem ja d'entrada tot l'estalvi, és a dir, el pas de desenvolupar en Java cap a Python, per exemple, suposa un estalvi sols en temps d'espera d'entre 1.500 i 3.000 Eur anuals per programador, deixant a banda la diferència de productivitat en termes de línees de codi entre un i altre llenguatge.

Un altre factor d'estalvi, encara que no tan important com el del llenguatge com el processador, ho podem trobar en les pantalles. Tenir una pantalla gran o dues pantalles pel desenvolupament, fa que el programador no té que anar canviant de finestra o que els canvis que fa són mínims. Un estalvi de 2 minuts al dia per aquest concepte implica un estalvi de 100 Eur anuals, si tenim en compte que l'amortització d'una pantalla de 20" és també d'uns 100 Eur anuals, tendriem que arribam a la partiat, al break event, però millorant sobremanera l'entorn de desenvolupament del nostre personal, i per tant la satisfacció en que es fa la feina, i la satisfacció i motivació del personal, són efectes de primer ordre en la productivitat.

En poques paraules, equips més grans, més potents, pantalles amb més resolució, tenen un impacte quantificable en el desenvolupament web. Canviar equips abans de que estiguin amortitzats pot tenir un impacte significatiu en la compta de resultats d'un departament informàtic, tant amb el que suposa d'hores de feina estalviades, com per l'augment de motivació del personal que hi fa feina.

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ó.

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ó.

La teoria de la finestra trencada data de 1995, i es pot trobar un bon resum aquesta referència. Bàsicamen ve a dir que la degradació d'un barri, d'una casa, d'un cotxe,.. comença per petites coses que se van acumulant fins que la degradació arriba a un punt on és ja difícil la recuperació.

La idea és atacar donçs les petites mostres de degradació abans de que es facin més grans. En una barriada procurar mantenir els carrers nets, recullir les escombreries, mantenir els jardins i els parcs. La idea és que quan una cosa està en bon estat, quan encara no s'ha començat a degradar, és molt més difícil donar el primer pas que un cop la degradació ja ha començat.

Si no hi ha escombreries al terra és menys probable que algú les hi deixi. Si ja n'hi ha, el més probable és que n'hi acabi haguent més. Tanmateix ja n'hi ha una, un parell, un munt, fins que tot és bassura.

Passa el mateix amb els cotxes avariats. Poden passar dies a la carretera o al carrer sense que passi res, però una vegada s'ha trencat el primer vidre la degradació és molt ràpida, en un parell de dies ja no hi haurà rodes, peces interiors, etc.

Aquesta teoria també és aplicable al mon del programari. Quan es té un programa ben estructurat, definit, amb un estil de programació clar és molt més probable que la persona que ho tengui que mantenir ho faci seguint el mateix estil. Al contrari, si ja des de l'inici el nostre codi és descuidat, sense comentaris ni estructura, el més probable és que la cosa vagi a pitjor. Tanmateix, es pot pensar, no vindrà d'aquí. D'aquí que en la posterior evolució del programa ens poguem trobar amb un conjunt de pegats mal fets, codi que no té sentit, una arquitectura inexistent... L'efecte de la finestra trencada fa que una vegada que ha començat la degradació sigui molt més probable que aquesta continui.

Sovint, però, en el món del programari, no queda més remei fer pegats ràpids per corregir un error de funcionalitat de seguretat o del que sigui. No hi ha cap mal amb això, sempre que tenguem en compte que ha de ser l'excepció i no la regla. La idea és que una vegada s'ha solucionada la crisi, s'ha de dedicar temps a fer les coses bé. En cas contrari ens trobarem amb la primera finestra trencada, i és molt més probable que el nostre programa evolucioni cap a un engendre mal de mantenir.

Fitxem-nos però que l'evitar l'efecte finestra trencada no vol dir que tenguem que passar-nos la vida perfeccionant un programa fins a deixar-ho perfecte. La perfecció malhauradament en programació no existeix: sempre podríem fer el codi millor, més ràpid, sempre podríem posar més funcionalitats, fer que el programa fes el que volem de la manera més òptima. No hem de perdre el concepte de "prou bo", és a dir, hem de saber també quan aturar.

Si seguim amb l'exemple de la barriada, vol dir que no fa falta que al barri totes les cases siguin palaus. Sovint basta que siguin vivendes dignes, amb les façanes pintades i els interior cuidats. Cases que tenen un cost que la gent es pot permetre i fetes de tal manera que el cost de manteniment també sigui baix.

Una vegada hem conseguit que el nostre programa sigui prou bo, es tracta de mantenir-ho així, d'evitar ser el primer en trencar la finestra i que si algú altra la trenca, arreglar-ho i posar el vidre el més aviat possible, ja que si no és així, acabarem amb l'equivalent en programari a una casa apuntalada i que amenaça caure.

En una entrada anterior parlava dels projectes Death March i de la classificació que en fa n'Edward Yourdon al seu llibre Death March. Ara escric això alegrant-me d'haver comprat i llegit el llibre: estam enbarcats en un death march project.

Quan un s'embarca en un projecte d'aquests, el primer que ha de saber és en quin tipus de projecte s'està embarcant i quina és la companyia. Jo aquest, i segons la classificació de Yourdon, ho classificaria com un projecte de "Missió impossible", és a dir, es compta amb un equip altament motivat i capaç, però els riscs que poden fer fracassar el projecte són motls i variats.

Si als projectes normals ja s'ha de dur molta cura amb la gestió, als death march encara és molt més crític. Es pot pensar que en un projecte on les premures de temps són important no s'hauria de dedicar temps a la planificació, control d'errors, de versions, al la comunicació, res més allunyat de la realitat. Les estratègies de "codifica com un boig" [1], potser estan bé per fer veure ques es fa molta feina, el problema però, es que sovint aquesta feina és poc productiva i no garanteix que el projecte arribi a bon port.

La planificació i el control en aquests tipus de projectes és doncs tant important o més que en els projectes "més tranquilets", el que potser haurem de fer és no entrar a tant nivell de detall en alguns aspectes, si està un 80% bé ja és suficient, el 20% restant, que marcaria l'excel·lència en un altre projecte, és massa costós en termes de temps i cal evitar-ho si volem tenir èxit. Per exemple, tant fa si l'anàlisi de casos d'ús està fet amb la darrera eina de disseny UML, amb tots els colorins del món i enquadernat a tapa dura, potser amb un troç de paper que exmplique el que es vol fer és suficient. La cosa és que hi ha d'haver aquest troç de paper i hi ha d'haver una estratègia de feina orientada no a fer moltes hores i molta feina, sinó a fer feina efectiva.

Tanmateix, algunes vegades ni tota l'estratègia i planificació del món salvarà el projecte, senzillament està condemnat al fracàs: el temps és massa curt, el recursos insuficients, el que s'ha de fer no està clar, els riscs del projectes són massa o qualsevol combinació de les anteriors. El problema és que normalment un no sap que passaran coses d'aquestes fins que ja ha començat el projecte. Davant això, la planificació i la comunicació són importants. No serveix de res dir allò de "està al 90% acabat" quan sabem positivament que el 10% restant és el bessó del projecte. Val més ser realistes i dir les coses clares. Tanmateix si la continuïtat de la feina depén de l'èxit del projecte i aquest no té cap possibilitat d'acabar bé, al manco n'haurem informat a temps i es podrà, si es vol, reaccionar.

Quan un projecte s'ha de fer en un temps molt curt, per mi, el més important és disposar d'un bon equip de gent. I per "bon equip" no vull dir un equip gran de gent, sinó un equip de gent molt qualificada, acostumada a fer feina plenada i molt motivada. Això i moltes hores extres, clar. El problema és que un ritme de 10 o 12 hores diàries, difícilment es pot mantenir durant més que un parell de mesos, així que a partir d'una certa durada del projecte convé començar a fer comptes i veure si posar més gent al projecte compensa el retràssos que implica tenir que formar al personal nou i la complexitat adicional de comunicació que hi ha quan l'equip de feina es fa més gran

Per projectes de curta durada, entre un i tres mesos, és molt més eficient un equip petit, tirant d'hores extres fetes amb seny, que un equip amb el doble de gent. La durada del projecte sovint marca també el nombre de tasques que s'han de fer i el grau de paralel·lització que es difícil que arribir a ser l'òptim [2]. A vegades es pot aconseguir que el projecte faci més via si malbaratam recursos, és a dir, si tenim gent sense fer res, esperant a que li toqui fer el seu trocet. Sigui com sigui, ens duu sempre al mateix, s'ha de planificar, s'ha de saber l'abast del projecte i s'ha de dissenyar una estratègia amb probabilitats d'èxit. D'altra manera no sabríem mai si amb més recursos s'hagués pogut arribar a temps o al contrari, si s'hagués tingut que tirar de treball extra per acabar el projecte

Tornant al nostre projecte, crec que serà complicat, els riscs són grans, però l'equip és molt bó. Les meves estimacions diuen que en condicions normals podem doblar o triplicar la productivitat estandard. Tot aquest optimisme sempre cal estar atents als riscs, al seu control i a la seva minimització. Controlar els riscs és costós, s'hi han de dedicar temps i recursos, però no fer-ho pot suposar que un projecte de "Missió impossible" es convertesqui en un projecte suicida. Yourdon diu que les estadístiques estan al nostre favor [4], i si Yourdon ho diu ho haurem de creure.

Ja sent la musiqueta: tan-tan-tan-tan-tant-ta ta ta ta, tiruriii [3]

[1] Code like hell
[2] Quin mal que han fet aquí les eines com M$Project que suposen que qualsevol recurs és intercanviable!
[3] La música mai ha estat e meu fort. Deduïu el nom de la cançò pel context. I no, no hi ha premi pel qui ho adivini. :)
[4] Els death march projects que tenen més probabilitat d'èxit són aquells on el projecte és de curta durada i l'equip és petit i està molt motivat. En aquests tipus de projectes és molt més bo de fer que la gent pugui "aparcar la seva vida" durant el temps de durada del projecte. En projectes amb molta gent o de durada molt més gran, hi ha tan dificultats per a que tothom "doni el call", pels motius que siguin o que pugui deixar-ho tot durant tant de temps (el més normal). Això per no parlar de l'esgotament físic i mental o de que en casos així molts dels integrants del projete s'estima que deixaran l'empresa dins el proper any, amb la qual cosa l'empresa es pot trobar amb un projecte fracassat i amb el capital humà perdut.

A la revista Arròs amb Salseta, la revista local de Binissalem, surt aquest mes un article d'opinió d'allò més sucós. Es tracta de d'un tal Toni Servera, "es guixaire", que fa saber públicament que encara que s'ha separat de l'al·lota i que tot i que tenien el pis a mitges, avisa de que la rumorologia que corre de que li prendran el pis es falsa, i que "Gràcies a Déu, mail li han faltat doblers per pagar res".

Particularment m'ha sorprés l'anunci. És ben curiós veure una cosa així a una revista, encara que sigui de poble. Ara també he de dir, que aquestes coses sols poden passar a un poble, on un sector de la població tendeix a "fer els comptes" a la gent. No em puc imaginar com n'ha arribat a ser de molest per aqeust home que n'hagi tengut que fer un comunicat públic a la revista. Les xafarderies als pobles sempre han estat a l'ordre del dia, rumorologia a més estil "reallity show". Potser ara amb tots els serials que hi ha la cosa s'ha apaivagat un poc, però a molts pobles encara ens podem trobar amb els envejosos/es que aprofiten qualsevol cosa per fer safreig.

Bé, als pobles i a la blogocosa. Des de que Ricardo i companyia van posar en marxa el menéame, ja no sé quantes vegades ha tingut que sortir al pas d'acusacions de tota mena, algunes personals, algunes atacant la feina feta. La majoria sense cap justificació o amb justificacions peregrines, fruit de l'imaginari esquizofrènic del qui les fa, i sense més fonament els xafarders que han fet que mestre Toni Servera publicàs el seu escrit a l'Arròs amb Salseta.

No puc entendre fins a quin punt arriba l'enveja d'alguns i més amb una cosa com el Menéame, que té el codi font a disposició de qui el vulgui, i que per tant, si no t'agrada sempre pots montar-ne el teu propi xiringuito. Però clar, no és cosa de que t'agradi o no, pareix que la cosa és que com que el que hi ha funciona, el que s'ha de procurar és desacreditar-ho, bé com a concepte bé mitjançant atacs personals. Tan difícil és alegrar-se de que una cosa funcioni? Per què hi ha gent que no està contenta quan els altres tenen una bona idea? Per alguns la idea de blog, de participació, és més aviat la de la peixeteria/perruqueria/forn del poble, és a dir, com a fòrums on deixar anar tota la seva mala llet, això sí sempre disfressada de un "no és que vulgui criticar, però ...".

Arrel de l'anunci d'un forat de seguretat a Rails aquests dies podem llegir a força blogs comentaris del tipus ja sabia jo que això no podia ser tan bo, o que comparat amb Java encara li queda un llarg camí, que si ja ho deia jo, ...

No hi ha cap bastiment de programació o llenguatge que pugui assegurar que està lliure de forats de seguretat, sols és questió de temps el que es trobin. El que és important és com es tracten aquests forats, en quant de temps es resolen les fallades i com n'és de complexe l'actualització.

El que RoR tengui una forat més o menys greu de seguretat és anecdòtic i esperable en un producte tan tendre, potser haurà decebut a la gent que veia en aquest bastiment "la bala de plata" que solucionaria tots els seus problemes i la fam del món, però això és el seu problema i no el de RoR o de qualsevol altra bastiment de programació. La gent que té tendència a autoenganar-se, a confiar cegament en qualsevol cosa i després sentir-se absoluta i totalment decebuts a les primeres de canvi fa més que mostrar la seva immaduresa.

El que sí ha demostrat aquest fet és que a RoR no hi havia una política de seguretat clara, no tant en el que fa a que els errors es resolguin ràpid, sinó en com es comuniquen aquests errors i de com se'n fa difusió. Això ha servit per a què altres projectes facin introspecció i es demanin si els podria passar també a ells. Django per exemple

ha publicat al seu lloc com es tractaran els assumptes relacionats amb la seguretat. Així doncs, el problema de RoR ha servit perquè altres es demanin si els podria passar a ells i prenguin mesures per a tenir-ho controlat quan passi.

Del que he llegit darrerament damunt el tema l'apunt de TheServerSide és un dels més interessants, ja no pel que diu sinó perquè veus la postura de la gent que està aprofitant aquesta fallada de seguretat per fer-hi sang. I un post molt interessant fet al grup de Django a partir de la fallada de seguretat de RoR intenta explicar el perquè Rails té l'èxit que té encara que no sigui especialment millor que altres bastiments que hi pot haver. Per mi que és un post força inspirat.

Un projecte es pot classificar com a Death March quan un dels seus paràmeteres excedeix la norma en com a mínim un 50%, ja sigui en termes de temps, personal o pressupost (50% per davall de la norma en aquest cas) o en funcionalitat (doblant la funcionalitat típica). O amb una altra definició, són projectes on la possibilitat de que falli i no es compleixin els objectius és major que el 50%.

En el llibre Yourdon ens descriu què són aquest tipus de projectes, per què hi ha empreses que s'hi fiquen [1] i per què hi ha caps de projectes disposats a liderar projectes d'aquestes característiques.

Una vegada s'ha assumit que ens hem embarcat en una marxa cap a la mort, Yourdon ens dóna una sèrie de consells per a intentar sobreviure a l'experiència: estratègies de negociació, de com recompensar l'equip, de la importància de no abusar de les hores extres no remunerades, fins i tot de com en aquests tipus de projectes és convenient botar-se la burocràcia inherent a certes empreses si es vol tenir una mínima possibilitat d'èxit.

Yourdon classifica aquests projectes en quatre grans categories, agrupades en quatre quadrants.

En el primer quadrant tenim els projectes Kamikaze. Projects condemnats al fracàs des del principi, però on tothom hi vol participar ja que creu que encara que es fracassi l'experiència pot ser gloriosa.

En el segon quadrant hi situa els projectes que anomena de Missió impossible: projectes on els membres de l'equip estan altament motivats i tenen gran capacitat i han de lluitar contra les forces adverses que volen fer fracassar el projecte.

En el tercer quadrant trobam els projectes Ugly, que podríem traduïr per marró, porqueria o qualsevol lindesa semblant. Són projectes on els membres de l'equip es consideren carn de canó, xais sacrificables per tal d'aconseguir el propòsit (no m'agradaria estar en aquest tipus de projectes).

I en el quart quadrant les projectes suicides, on tothom està condemnat i tothom és miserable, on la gent hi fa feina perquè l'alternativa és ser despatxats, encara que saben que no hi ha cap oportunitat per l'èxit.

Si ens trobam en un projecte Death March és important ser-ne conscients, i quan més aviat millor intentar classificar-ho dins alguna d'aquestes categories. Tots els membres de l'equip convé que siguin conscients de amb quin tipus de projecte s'han embarcat, fer feina en un projecte Kamikaze o de Missió impossible pot ser divertit i potser tindrem possibilitat d'èxit, les altres alternatives sols servixen per guanyar temps i anar actualitzant el currículum.

Yourdon introdueix alguns conceptes que m'han interessat especialment: el concepte de prou bo, que ja apareix en Surviving Object-Oriented Projects d'Alistair Cockburn i que Yourdon desenvolupa al capítol cinc i seguents. El concepte de triage, que podríem traduïr per triatge o priorització, la gestió de l'equip i els diferents perfils que hi podem tenir i fa quatre pinzellades damunt la dinàmica de processos [2] aplicada al desenvolupament de programari, per acabar amb tècniques de priorització del temps i gestió del risc, però en aquest darrer cas sense entrar-hi massa.

El llibre és bastant complet, encara que en alguns temes te deixa en ganes de saber-ne més. La bibliografia i les referències que acompanyen a cada capítol també són molt completes i hi ha un parell de referències que es repeteixen al llarg del llibre: PeopleWare, The Mythical Man-Month i Rise and Resurrection of the American Programmer.

No m'ha agradat, en canvi, el que fa molts capítols: Yourdon fa referència a e-mails que ha rebut dels seuls colegues en resposta a preguntes que ha fet a l'hora d'escriure alguns capítols, fins aquí bé, el que no m'agrada és que al final del capítol escriut tot l'e-mail rebut i moltes vegades és paraula per paraula el que ha dit al capítol. Està molt bé això de donar crèdit a qui ha proporcionat la idea, però ho podria fer en forma de reconeixement, nota al peu de pàgina i amb el text complet de l'e-mail a una plana web i no com a transcripció literal al llibre. Dóna la impresió de que sols està allà per omplir i fer embalum a un llibre que si no fos per això no arribaria a les 180 pàgines. La veritat és que a mi tant em fa si el llibre té 180 o 220 pàgines, l'interés del llibre no es pot midar en pàgines sinó en la qualitat del contingut i crec que en aquest cas es prou bo per no tenr-ho que inflar artificialment.

En llegir aquests tipus de llibres, però, me queda un cert regustet amarg, veig que aquestes tècniques, aquests estudis i classificacions estan molt més extesos als Estats Units que a les nostres contrades. Dels llibres es dedueix que existeix una vertadera especialització en la gestió de projectes i un interés en aprendre'n, en formar equips que funcionin, en entendre les dinàmiques del desenvolupament de projectes de programari. Me pareix que tenc tema per un altre apunt...

[1] Politics, politics, politics

[2] Fa ganes de saber-ne més d'això. Pareix prou interessant.

A la gent que ens dedicam a la programació i a la gestió de projectes és habitual que ens ens demanin que estimem què costa un projecte en termes d'hores de feina. Cada un pot fer servir el mètode d'estimació que millor li vagi: el dit a l'aire, punts funció, Mark II, estimació per casos d'ús, etc.

Aquests mètodes acaben donant un nombre de mesos home, que hi ha que tenir en compte que segons el que demani el client poc te a veure amb el que costarà realment el projecte.

És a dir, per anar bé, el que hem de donar a més del cost calculat en hores de desenvolupament és el cost del projecte en funció de la gent que hi volguem dedicar i de l'aviat que el client vulgui el projecte.

Hi ha tot un conjunt de taules per fer això, les més útils que he vist són les de McConnell, però a vegades no les tenim a mà. Una opció és anar a aquesta web i consultar-les, però en cas de que tampoc poguem fer-ho, perquè estam davant el client i no es cosa de dir-li, "deixa'm un ordenador i ho miro", convé tenir a mà un petit xul·letari que ens ajudi a sortir del pas, sempre diguent, però, que és una estimació subjecte a una valoració més fina.

Partim de l'estimació hen mesos-home que hem fet, suposem per exemple que li deim al nostre client que el cost de desenvolupament del projecte és de 80 mesos-home, el següent que ens demanarà el client és que quan ho podem tenir. Aquí comença la diversió.

Com a opció inicial li podem presentar la opció de desenvolupament òptim. Aquesta opció ve donada per la fórmula

temps = 3 * (estimació) ^(1/3)

Que el factor multiplicador 3 pot variar segons el coneixement que tinguem de la nostra empresa i de l'equip de desenvolupament. Es recomana que el factor estigui entre 2 i 4.

Així doncs la primera aproximació que li donaríem al client és: 13 mesos amb un equip d'entre 6 i 7 desenvolupadors (80/13). Això vol dir que ja hem estat capaços de donar-li una primera xifra: tant de quan seria òptim tenir el projecte acabat, com de quants desenvolupadors necessitarem per tenir-ho a temps. D'aquí ja es dedueix un cost del projecte, ja que basta multiplicar desenvolupadors pel cost de cada un. Suposem a 2000 Eur per més, tendríem un cost de 14.000 Eur mensuals, és a dir, 182.000 Eur [1]. És a dir, el cost de cada mes home és de 2.275 Eur.

Les coses però no solen funcionar així, els 13 mesos proposats potser són massa pel client, ens demana que ho hauríem de tenir en 8 mesos. El cost en aquest cas no és el mateix, ens estan demanant una compressió dels plaços d'entrega, i això vol dir posar més gent al projecte. El primer que hem de fer és calcular el nou esforç

nou esforç = esforç inicial / factor compressió

En el nostre cas

nou esforç = 80 / (8/13) = 130 homes-mes amb un factor de compressió de 0,615.

Aquí ja tenim un petit problema ja que el factor de compressió més gran que es considera factible està entre 0,75 i 0,80. Siem optimistes i suposem un factor de 0,75, ja que tenim un equip molt bo. Això vol dir que la data d'entrega més optimista que podem donar és de 9,75 mesos, 10 mesos per no anar massa estrets. Si hem fet bé el càlcul de dedicació una data més curta implica anar cap a un "Death March project" i hem de dedicar els nostres millors esforços a fer-ho entendre al client.

Suposem doncs que accepta la nova data, l'eforç que li hem de presentar és ara

nou esforç = 80 / 0,75 = 106,7 mesos-home ~ 107

amb un equip d'onze programadors. Això vol dir pujar el cost del projecte fins als 220.000 Eur.

Són sols quatre números però que ens ajuden a veure com un desenvolupament que s'allunyi d'unes dates d'entrega òptimes s'encareix, bé en termes de cost real o bé en termes de cost en personal, obligat hores extres no renumerades, que es vulgui reconèixer o no a la llarga passa factura a l'empresa. Els pressuposts tancats, doncs s'han de fer no tan sols en termes d'hores calculades, sinó també tenint en compte el cost addicional que hi ha quan escurçam el temps d'entrega.

Així que a la pregunta de què costarà un projecte, hem de demanar a més de les especificacions per poder-ne fer la valoració, el temps en que el client ho vol tenir, i si més no, donar-li l'alternativa d'allargar el desenvolupament i disminuir-ne el cost.

--
[1] Les xifres són redones i inventades, no cal dir-ho supòs.

L'estiu és una bona èpica per llegir, el dia s'allarga i els vespres fa ganes estar una estoneta més a la fresca llegint, sempre i quant els moscarts no ho impedeixin.

Aquest cap de setmana he acabat de llegir el llibre de Joel on Sofware. He de dir que no m'ha decebut. Hi ha alguns capítols fluixets i algunes contradiccions (sobretot quan parla de llenguatges de programació i .Net) però en definitiva el llibre és molt aprofitable. Potser tècnicament no arriba al nivell d'autors com De Marco o McConnell, però té un llenguatge molt proper i entenidor.

Són especialment bons els capítols dedicatas a la gestió de projectes, al test de Joel, del que ja n'he parlat a aquest blog i els consells que dóna referents a la gestió de projectes i desenvolupadors.

Al llarg del llibre Joel posa molt a Microsoft com a exemple de bones pràctiques, de quan ell hi era, diu, però tampoc se n'està de criticar-ho quan fa falta. És força interessant l'anàlisi que fa al capítol 42 quan diu que Microsoft ha perdut la guerra de les APIs. També és molt interessant el capítol que dedica a la microeconomia, és molt de l'estil d'una conferència que va fer Ricardo Galli a les primeres jornades de Bulma a campos. He de dir que tot i que Joel ho explica molt bé la d'En Ricardo era encara millor. No sé si La té publicada a Bulma. En Pau que està en tot m'ha passat l'enllaç

En definitiva, un llibre per tenir-ho aprop i anar rellegint de tant en tant capítols seleccionats. Potser no en treurem moltes dades ni estadístiques del llibre, però segur que raons per fer les coses "com toca".

Com que l'altra dia els d'Amazon es portaren i m'entegaren les comandes força aviat puc seguir amb el mateix tipus de lectura estiuenca. Ara li toca el torn a Walzing with Bears dels autors de Peopleware. L'he començat a fullejar i per ara pinta molt bé. El llibre va de gestió de projectes i concretament de la gestió del risc en els projectes. Una de les primeres idees que hi ha és que si un projecte no té risc no val la pena fer-ho. Qui no s'arrisca no pispa! :)

La veritat és que no sabia si seguir amb Walzing with Bears o amb Death March d'Edward Yourdon. Gestió del risc o com sobreviure a projectes condemnats? He optat per l'optimisme moderat i anar cap a la gestió del risc, la lectura de Death March potser ara mateix encara no me fa falta. Esper que no ho necessiti! :)

Avui hem començat el curs de Ruby organitzat per la CAEB. Per ara la cosa pinta bé. He estat llegint coses del Ruby, especialment des de que hi va haver el boom del Ruby on Rails (RoR pels amics), i un curset de 20 hores com aquest pot ajudar bastant a aclarir coses. Encara que hi ha força informació a la xarxa és molt més interessant i productiu que t'ho conti algú com en Guillem que anar-te cercant la vida tu mateix.

Aquests darrers dies han aparegut algunes compartives interesants damunt els bastiments de persistència basats en el model MVC que han sorgit recentment:

• http://wiki.rubyonrails.com/rails/pages/Framework+Performance
• http://www.cms.rk.edu.pl/benchmark.html

La primera compara Django, RoR i un bastiment MVC per PHP anomenat Symfony. La segona compara Django amb una altra bastiment molt més 'a la Rails' però fet amb Python com és Pylons.

Personalment he de dir que m'agrada molt la claritat que té Django i me n'alegra comprovar que és el bastiment que surt més ben parat de les comparatives. Tot i això en totes podem veure que qualsevol dels bastiments aguanta prou bé una càrrega que ja la voldria qualsevol pel seu web. A més la quantitat de peticions que és capaç d'aguantar el bastiment depén també de la màquina, amb la qual cosa tenim que podem augmentar moltíssim el nombre de peticions que podem aguantar sols fent una inversió major en la màquina.

En Joel Spolsky apunta al seu blog una presentació feta per Sean Kelly de la NASA comparant Django, Rails, Zope, TurboGears i J2EE i ens avisa als programadors de J2EE que després de veure la presentació mai més voldrem saber res de J2EE per fer aplicacions web.

Bé, ara per ara encara m'estic devallant la presentació (ONO no m'ha volgut/pogut posar la connexió a casa i encara estic amb una ADSL, però això és un altra tema), però amb el que ja conec d'aquests bastiments i el que conec de J2EE no crec que me n'endugui cap sorpresa. Per moltes aplicacions la complexitat que suposa el J2EE no és necessària, més quan la suposada escalabilitat que ens dona el J2EE es veu superada amb una mínima inversió en màquina i fent servir un d'aquests bastiments.

Sovint el problema és convèncer a uns i altres de que la solució basada en lleguatges dinàmiques és més adeqüada per aquell problema que la basada en J2EE, però clar, tenim el problema de la uniformitat i dels consultors. La uniformitat en tant en quant pareix que els programadors sols han de ser especialistes en un sol llenguatge i els consultors que defugen de recomanar qualsevol cosa que no soni a J2EE i que són els mateixos que fa un grapat d'anys lloaven les meravelles dels EJBs.

Estam anant al curs de Rails perquè encara que no sé si el farem servir a l'Empresa, segur que no ens farà gens de mal conèixer un nou llenguatge, sempre se n'aprenen coses i pots agafar moltes idees. Si sols conèixes un llenguatge la teva programació es veu massa condicionada pel que es pot fer en aquell llenguatge i deixes d'explorar altres alternatives potser més adients. Personalment crec que hi haurà certes aplicacions, especialment les que han de connectar amb bases de dades existents que són més senzilles de fer anar amb tecnologia J2EE de cotenidor fi (Hibernate+Spring+Jsp damunt Tomcat) i que d'altres és molt millor desenvolupar-les amb qualsevol dels bastiments de les comparacions anteriors.

La falta d'uniformitat no és un inconvenient, és un avantatge competitiu en aquests casos, ara sols falta convèncer als consultors ...

• Cercam l'arxiu trac-post-commit-hook.gz . A debian el tenc a /usr/share/doc/trac/contrib. El descomprimirem al directori que més ens agradi i a l'unic arxiu que conté trac-post-commit-hook li dorarem el mateixos permisos d'execució que tengui l'usuari http.
• Anam al repositori subversion, ens situam al repositori del nostre projecte i anam al directori hooks. Reanomenarem el fitxer post-commit.tmpl com a post-commit i li donam també permisos d'execució per l'usuari de subversion.
• Editam aquest arxiu, de manera que després dels comentaris quedi:

  REPOS="$1"
  REV="$2"
  LOG=`/usr/bin/svnlook log -r $REV $REPOS` AUTHOR=`/usr/bin/svnlook author -r $REV $REPOS`
  TRAC_ENV='/somewhere/trac/project/'
  TRAC_URL='http://trac.mysite.com/project/'
  /usr/bin/python /usr/local/src/trac/contrib/trac-post-commit-hook
  -p "$TRAC_ENV"
  -r "$REV"
  -u "$AUTHOR"
  -m "$LOG"
  -s "$TRAC_URL"

/usr/local/src/trac/contrib/trac-post-commit-hook

Amb aquest títol comença una oferta de feina de l'empresa IN2 apareguda a Infojobs els 16-06-06. Aquesta gent cerca 15 titulats o gent a punt de titular-se, amb un bon expedient acadèmic i amb prou coneixements de Java, J2EE, J2SE i BBDD relacionals com per poder seguir un curs avançat de programació de 250 hores.

Així com avança l'anunci la cosa es comença a desbaratar:

Primer faran una preselecció per veure qui pot anar al curs i qui no. Això no és cap mala cosa en sí mateixa. Si es cerca gent que pugui seguir el curs, es lògic que vulguin garantir-se de que ja es té un cert nivell i que el curs podrà avançar amb prou rapidesa.

La cosa està en que el curs va, pareix, del 15 de septembre al 30 d'octubre. Mala cosa per la gent que estigui al darrer curs de carrera, ja que segurament es perdrà el començament del curs. El pitjor però és que es tracta d'un curs gratuito y no remunerado. I que després de superar l'examen final, als millors se'ls contractarà per un any a l'empresa amb un sou, segons diu a l'oferta, de 12.000 € bruts a l'any. És a dir, que una vegada descomptem imposts no quaran uns 800 euros nets al més (en 14 pagues).

Donat que hi ha un procés de selecció previ, se suposa que el curs hauria d'entrar ja dins el període de prova de l'empresa i per tant hauria de ser remunerat. És el més normal, ja que d'aquesta manera volen estalviar-se els sous que haurien de pagar si ja contractàssin el personal que superàs la primera selecció. La contractació inicial granteix a més que la majoria dels que segueixin el curs quedaran a l'empresa (al manco en aquest país) i fent que el període de prova coincideixi amb el curs, suposa que l'empresa no tindria despeses per acomiadar la gent que no cumplís les espectatives.

El que fan amb aquesta oferta és dir que necessiten gent, però que no volen pagar-la, y que no tenen un depertament de selecció prou bo, per poder destriar la gent que els interessa a la prova inicial. No sé si és això el que volien transmetre, però així ho interpret jo.

També puc fer-ne una altra interpretació: necessiten gent, però no saben exactament quanta, el client no s'acaba de decidir, però si es decideix no tindran mans per assumir el projecte. Això vol dir fer una inversió mínima, i aquesta passa per tenir ja la gent seleccionada i formada i després ja veurem. Sempre se'ls pot dir que no han passat l'examen final i la inversió s'haurà limitat a les hores del formador. Un risc controla. Bo per l'empresa però no tant pel treballador.

L'altra cosa que us podeu imaginar que m'ha sobtat és el sou que volen pagar. Volen gent mig formada, amb bon expedient, que vulgui invertir dos mesos de la seva vida en un curs per veure si després pot guanyar 800 Eur al més. No sé què pensareu vosaltres, però una cosa i l'altra no lliguen massa. La gent formada i ben preparada és prou capaç de trobar feines de més de 800 Eur al més el primer any, i més en les tecnologies que demanen. El perfil de gent que demana IN2 correspon també a gent prou bona per ser capaç si cal d'autoformar-se en les tecnologies que demana IN2. La veritat és que m'ha sobtat el poc que valoren els seus futurs empleats, i més quan l'empresa es defineix com "una Ingeniería de Desarrollo de Software, Formada por Ingenieros para dar soluciones de Ingeniería."

IN2 com a empresa privada que és pot fer el que vol, pot oferir el que vulgui com a sou, i potser hi haurà gent que hi anirà a veure què tal, però personalment si hagués de contractar la gent que ha acceptat la feina m'ho pensaria molt. Em preocupa que una persona capaç i ben formada es valori tan poc a sí mateixa, em dona a entendre que hi ha alguna cosa que no acaba de funcionar, que no lliga.

Ei! Si voleu fer un curs gratuït, potser us interessarà! Personalment jo ja no invertiria massa en Struts, convé conéixer-lo i dedicar-hi unes setmanes, però després ja aniria cap a Spring i el seu MVC. La potència i flexibilitat que dona és molt superior a Struts. És un bastiment que agafant la filosofia del primer ha intentat (i al meu veure ha aconseguit) eliminar els majors emperons d'Struts.

Vosaltres mateixos...

Via meneame he vist aquest post que fa referència al que cobren les consultores.

Per la llista de Python, concretament a pun apunt del Dr. Dobb's Python-URL! m'he assabentat de l'existència del llibre wxPython in Action i de la possibilitat de fullejar un dels seus capítols a la web pythontrheads.

Això són bones notícies, ja que vol dir que a partir d'ara tindrem més documentació d'aquesta excel·lent llibreria gràfica. Pels qui no la coneguin wxPython és un embolcall (binding) per Python de les llibreries wxWidgets, abans conegudes com wxWindows. Aquestes llibreries són portables, potents i no gaire pesades. L'emperò és que la seva gestió d'events no és tan neta com el mètode signal/slot de les Qt.

Com a avantatge tenim els nombrosos exemples que hi ha per fer gairebé de tot el que se'ns acudi en termes d'interfície gràfica i dissenyadors d'interfícies d'usuari com les wxGlade, o un IDE com el Boa Constructor .

Les wxPython són una opció a tenir en compte si ens plantejam fer una interfície d'usuari que sigui lleugera i portable, i m'atreviré a afegir dues característiques més: mantenible gràcies a la claretat i senzillesa de Python i divertida de programar.

Fa poc vaig comprar per correu una Epson multifució, una Epson Stylus Photo RX640, esperant que com la RX630 està ben soportada per Linux aquesta també ho estaria. Error! O millor dit, error a mitges, ja que la impressora potser funcionaria, si no fos que pocs dies abans m'havia actualitzat a la nova beta d'Ubuntu per PPC. Mal fet? Depén, hom ja sap el que es pot esperar de les betas, el que no m'esperava és que tengués un error tan greu.

He de dir, però, quen no pareix ser un error sols de la Ubuntu, sino que hi ha més gent queixant-se del mateix, no ja de la compatiblitat de la impressora, sinó del missatge d'error. El problema de fons és que l'error fa que no es detecti bé el port usb al qual està connectat la impresora i per tant ja no és quelcom relacionat amb la compatibilitat o no d'un model, sinó un error molt més de fons.

Així un printconf amolla un desesperant

*** glibc detected *** free(): invalid next size (normal): 0x1013f178 ***
Unable to read printer database.
Please ensure the "foomatic-db" package is installed properly. </code>

fotuda i ben fotuda!

Ara a esperar que es resolgui l'error, segurament relacionat amb el que està produïnt aquest missatge a la sortida del dmesg

[121680.002506] drivers/usb/class/usblp.c: v0.13: USB Printer Device Class
driver
[121680.037076] ioctl32(hald-probe-prin:404): Unknown cmd fd(4)
cmd(44005001){04} arg(ffac4518) on /dev/usblp0 </code>

Pel que es veu és una errada de programació, que té a veure amb la conversió del codi de 32 bits a codi de 64 bits. El que em té amb la mosca darrera l'orella, però és que a la gent que està amb paquets per i386 també els passa.

Cercant-ho per debian bugs  m'he trobat que aquest error ja té un número el 366254 i que ja duu unes quantes setmanes pendent. Ara sols queda esperar i anant vigilant les actualitzacions. Una bona manera d'estalviar paper i tinta :)

gksudo "update-manager -d"

• Informació duplicada, no mantinguda i repartida per infinitats de fulls de càlculs, repartis a la seva vegada per tots els ordinadors de la companyia.
• Dificulta pel saber qui té dades personal amagatzemades dins un full de càlcul. Això a la llarga pot comportar un problema importat davant l'agència de protecció de dades, ja que són fitxer de dades i com a tal s'haurien de tenir controlats. Imaginem per exemple que algú d'un gabinet mèdic duu la llista de les seves visites dins el full de càlcul. Com podrem garantir que tengui les "mesures de seguretat suficients"?. Si als cinc minuts de cercar per internet podem trobar com botar-nos l'encriptació d'un Excel. I no parlem ja de les còpies de seguretat ni registre dels acessos al sistema. Les fulles de càlcul no són per això!
• Dificultat per compartir i mantenir les dades. Les fulles de càlcul no són multiusuari, compartir les dades implica sols deixar-les en un directori comparti i sovint vol dir que s'envia per correu tota la fulla de càlcul. Què passa quan tenim les oficines connectades per una WAN? Doncs que hi ha tendència a compartir directoris sols per poder accedir a dades amagatzemades dins fulles de càlcul.
• Incapacitat de créixer. La quantitat de files que pot manejar un full de càlcul és molt limitat si ho comparam amb el que pot manegar un gestor de BD mitjà.
• Rendiment. He vist gent amb fulls de càlcul de fins a 30 MB de dades queixant-se perquè del lent que carregava l'aplicatiu. :(
• Seguretat. L'accés a la informació no està restringit de la manera com ho està una base de dades. És molt més bo de fer perdre informació, o que s'enviïn per correu electrònic les dades de l'empresa.