L'altra dia de pagès al Twitter vam estar discutint alguns amics sobre la conveniència o no de desenvolupar un framework de programació web. Que si així pots controlar més el que fas, que si tot estarà més optimitzat i farà just el que vols, ... Collonades!

Ups! Me pareix que he tornat a ser políticament incorrecte, ja em perdonareu. Però aquesta és una de les típiques discussions xerrades entre informàtics i programadors, junt amb la tendència a proposar una eina totalment diferent quan algú diu que fa servir un programa o llibreria i està fent ja la tasca.

Anem a pams. Això és tan comú que fins i tot té un nom. És la síndrome de NIH (not invented here) i fins i tot en podeu trobar una entrada a la wikipèdia.

Bàsicament aquesta síndrome descriu la tendència a passar-se hores o mesos, a invertir temps en desenvolupar eines o programes que ja existeixen sols per fet que un es pensa que ho pot fer millor que el que ja hi ha, o bé com deia un poc abans, perquè té la convicció que li costarà menys fer el codi un mateix que aprendre a fer anar el codi d'un altre.

Les raons per ser conscients del problema són nombroses i miraré de fer-ne cinc cèntims un poc més endavant, però a vegades el NIH no és tant dolent i hi ha raons que fan que encara que existeixi un producte que fa el que volem, sia millor desenvolupar-lo a casa. Joel Spolski ho exposa molt bé a In Defense of Not-Invented-Here Syndrome i ho podem resumir molt fàcilment: té sentit fer-ho a casa quan allò que estàs desenvolupant forma part bàsica del teu negoci, del teu core business) en qualsevol altra cas ens ho em de mirar molt bé, ja que en la majoria de casos estarem davant d'un cas NIH com a una casa.

En un mon d'eines lliures i de codi obert la síndrome NIH fa que enlloc de col·laborar per a millorar els productes ens trobem amb un gran munt de llibreries que fan el mateix. Curiosament quan més senzilla és la tasca pareix que més llibreries hi ha, entroncant també amb la síndrome de la casa d'eines: si la tasca a fer és senzilla, com una caseta d'eines, tothom hi diu la seva i és mira en lupa tot, si la tasca a fer és complexa, com un gratacels o una fàbrica encara que el que hi hagi en joc sigui menor es fan menys aportacions.

És veritat que aprendre un nou bastiment de programació és complexe, tot aprenentatge ho és. Però al mateix temps que un aprèn el bastiment estam aprenent com un altre conjunt de programadors ha atacat el problema, llegim el seu codi, i per tant estam millorant la nostra formació. Si fem nosaltres el mateix com a programadors solitaris perdem aquesta oportunitat d'aprendre.

Potser ens trobem que el que hi ha fet no té la qualitat que volem, o ha de fer més coses. Doncs endavant, intentem millorar-ho. Ara tenim eines com git, mercurial o bazar que ens permeten fer branques molt fàcilment i enviar els nostres canvis al desenvolupador inicial de l'aplicació. En la majoria dels casos aquest estarà més que agraït en rebre la nostra contribució i tothom en surt beneficiat.

Un d'aquests amics ens deia que la raó era que tenia por a equivocar-se de bastiment i que no fos "el bo", i per tant millor fer-ho a casa per por a no equivocar-se. El problema és que fent això ja t'has equivocat.

Potser la teva productivitat inicial pareixerà que és més gran, perquè estàs escrivint codi enlloc d'aprendre, però pensem que és codi que per començar mai s'hauria d'haver escrit.

Pensem per un moment que tenim aquesta por i fem el bastiment de programació nosaltres enlloc de triar-ne un ja existent que estigui mantingut i documentat. Què passarà demà quan la tecnologia evolucioni? Ens trobarem perdent gran quantitat de temps intentant evolucionar el codi, intentant seguir el ritme o dient al nostre client que "això no ho podem fer". He conegut gent que té batiments que li generen el codi del manteniments mestres, però que quan el client els diu que ha de canviar l'ordre dels camps o afegir una validació diu que no es pot.

I si l'empresa creix o hem d'incorporar gent nova al nostre equip? Si el bastiment no l'hem fet nosaltres hi ha possibilitats que el candidat ja el conegui (o al manco podem intentar posar-ho al requeriments de la feina), però encara que estiguem en el cas pitjor, li podrem dir que es llegeixi la documentació, que miri els exemples de como ho fa l'altra gent. Si ho hem fet nosaltres l'hem de mantenir, l'hem de documentar i quan algú s'incorpori l'haurem de formar i en la majoria de casos no hi haurà documentació d'aquest bastiment propi. La nostra por s'ha convertit en una hipoteca pel nostre futur que ens dificultarà evolucionar o ser competitius.

I què passa amb els nostres clients? Aquesta decisió també els afecta, ja que els estam fermant d'alguna manera a nosaltres, ja que en cas de voler agafar ells el projecte es trobaran amb un bastiment de programació que sols l'empresa original coneix, haurà de dedicar molts esforços a aprendre com va i també l'estarem condemnant a mantenir-ho.

Hem de lluitar contra el "m'estim més fer-ho jo" i abraçar més el concepte de comunitat, confiar també amb la feina i el bon fer d'altres programadors que segurament en saben tant o més que nosaltres. Potser demà ens trobarem amb la necessitat de desenvolupar una eina que realment sia necessària i també ens agradarà rebre contribucions i que la gent s'animi a mantenir-la amb nosaltres.

El NIH és un perill perquè va contra el concepte de comunitat i col·laboració, perquè en la gran majoria dels casos representa una hipoteca tecnològica brutal per a nosaltres o els nostres clients. Així que abans d'optar per la solució fàcil de m'ho faig jo, potser ens convé reflexionar un poc no sia cosa que haguem agafat aquesta malaltia.

Pareix que el temps passa volant, ja que fa gairebé un més que vaig escriure el recopilatori d'abril i ja tot just acabam el mes. Serà que és veritat allò de que quan tornam vells el temps pareix que fa més via.

La veritat és que feia dies que volia escriure un apunt, ja que aquest mes de maig ha estat força interessant, tant per bé com per malament, tot hi ha que dir-ho.

El la part positiva, doncs que seguim fent feina, un més mes i amb les mateixes ganes. L'altra dia vaig veure un antic company de feina que em va demanar per donar suport a un producte tancat i del que no tenim gaire coneixement. Li vaig dir que no. La seva resposta va ser que "s'alegrava de veure que tenir empresa no m'havia corromput". No ho sé, vaig quedar un poc descol·locat, precisament l'objectiu de tenir una empresa és poder dir que no a feines amb les que no et trobes còmode. Em deman quin tipus d'empreses es deu trobar aquest bon home que es sobta quan algú li diu "no, això no en fem perquè és codi tancat i a més no en sabríem prou".

Un amic em deia l'altra dia que no havia de dir mai que no, que no era gens comercial. Ja ho sé, però no soc gens comercial jo, i tampoc pretenc ser allò que no sóc. Quan es fa un projecte sovint es pot trobar la manera de fer allò que vol el client, però trob que s'ha de poder dir que no quan el projecte no està dins allò que sabem fer o que representa un risc massa gran tant pel client com per a nosaltres mateixos.

També ha estat un mes de xerrades. En Toni Serna em va convidar a fer una xerrada damunt programari lliure la meva experiència com a APSL davant un grup d'empresaris illencs. Hi vaig anar amb bona companyia, junt amb un client/amic, en Joan Grande del grup El Gas, de manera que els assistents van poder veure les dues versions: el de l'empresa que desenvolupa i el de l'empresa que fa servir programari lliure per als seus processos interns.

A la mateixa setmana també vaig anar a fer una xerrada al Digital Week de Barcelona. Dues hores xerrant de Python i Django un divendres a les sis de l'horabaixa i que hi hagi gent que quedi a fer preguntes per mi és un bon referent de l'interès que hi ha en el tema.

La veritat és que va ser una experiència enriquidora poder parlar en una sala amb tants mitjans: dos projectors, pantalles per tota la sala, ... Això sí, la tarima estava un poc enfora de la pantalla de projecció i gairebé pec de morros quan vaig anar a assenyalar un tros de codi.

A més em vaig poder trobar amb amics: Xavi, Benjamí i desvirtualitzar una clienta que tenim per Barcelona i que no havia vist en persona encara. Coses que té el fer feina a distància. L'anecdotari el va posar un dels assistents que em va donar records d'un amic que té per Mallorca. El món és ben petit :D

Com que els horaris d'avió van com van, vaig arribar molt prest i Xavi em va fer de guia per Barcelona Activa, el que seria l'equivalent al Parc Bit a Barcelona, encara que no estic essent gens just amb la comparació: Barcelona activa té bones comunicacions, hi havia molta gent per tot, molt moviment, amb un gran desplegament de recursos. Vaig demanar informació, mai se sap! La gent va ser força amable i atenta (aquí ben igual que el personal del Parc Bit), però fixau-vos que em van dir que per a fomentar la col·laboració les oficines que es lloguen, encara que es puguin decorar com un vulgui, no han de ocultar el que es fa dintre.

Val a dir que el cost d'implantació és més gran que al Parc Bit, però el que vaig veure em va agradar molt, es notava ambient i al manco hi havia una possibilitat de fer contactes, ja que es fomenta que tothom pogués saber què feia l'altra gent i que hi pugui haver trobades informals a zones comunes, on un hi pot anar a xerrar, llegir el diari, desconnectar ... En definitiva, que em va fer molta enveja.

D'aquí no res començarà el mes de juny i esper tenir temps per escriure algun apunt més al blog que no sigui sols per contar-vos la meva vida. Potser hauria d'obrir una secció de batalletes ...

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?

Ahir vaig acabar de llegir "El japonés que estrelló el tren para ganar tiempo" de Gabriel Ginebra. Segons el subtítol intenta explicar el perquè ens tornam incompentents i com evitar-ho.

Ho vaig comprar en la seva edició Kindle, per poc més de 5 Eur. L'edició en sí es un poc descuidada, sovint no veus on comença un subcapítol i sembla que hi ha una línia desconnexa de la resta, la qual cosa resulta un tant molesta a l'hora de llegir.

Ginebra ens va mostrant les causes de la incompetència i els primers capítols són un resum del principi de Peter, lleis de Murphy i Dilbert, potser per posar-nos ja en guàrdia del que ens espera. Bàsicament ens ve a dir que tothom som incompetents, sia en un aspecte o altre i que el primer que hem de fer per millorar és ser conscient d'aquesta incompetència, abraçar-la i gestionar-la.

Fa molt èmfasi en com la sobrecompetència genera la incompetència. Voler arribar a la perfecció sense tenir en compte que vivim en un món imperfecte, a base de normes, procediments i sancions el que fa es generar renou i aconseguir l'efecte contrari del que volíem.

L'autor ens diu s'han d'eliminar capes de procediments, que la direcció de les empreses s'ha de concentrar amb gestionar les persones amb les persones, i no viure en una torre d'ivori practicant una mena de despotisme il·lustrat. És el que anomena el management amb minúscules.

Realment el que exposa Ginebra és del tot lògic i raonable, però no per això deixa de ser necessari exposar-ho i repetir-ho fins que la idea s'assenti. La meva pròpia experiència en les empreses en que he treballat m'ha permès veure molts tics que assenyala l'autor, així que hi hagi veus autoritzades que tracten el tema trob que sempre és bo.

Encara que el llibre en el seu conjunt és clar, si bé en alguns casos cau massa en l'anècdota, hi ha un capítol que ha quedat entre confús i contradictori. És el capítol 8 titulat "Trabajar lo peor posible". És un títol i una argumentació poc afortunada tal com s'expressa. Personalment la resumiria en aquella frase que diu que no hi ha res pitjor que fer de manera eficient allò que mai s'hauria d'haver fet. Això no vol dir fer feina el pitjor possible, sinó ser a la vegada intel·ligents i peresosos, saber treure el màxim rendiment de l'esforç i no crec que tengui res a veure amb treballar el pitjor possible. El fons del capítol està en aquesta línia, però trob que "The lazy project manager" tracta molt millor el tema i de manera més argumentada i menys contradictòria. En descàrrec de Ginebra val a dir que ell dedica un capítol a l'argumentació i l'altra és un llibre complet. El que sap greu és que és un capítol que no està realment a l'alçada de la resta.

M'han agradat especialment els capítols destinats a l'empresa barroca, el com una empresa va sobrecarregant-se, com els seus treballadors i directius van creant-se tasques del tot innecessàries per tal d'autojustificar-se. L'anomena el "Síndrome del demasiado tiempo libre". També són prou clarificadors els darreres capítols, destinats a les relacions humanes, a com gestionar persones i equips, el tracte humà, el parlar amb la gent, el poder-nos gestionar l'agenda de manera que s'ha de fer lloc per estar per la gent.

En resum, un llibre interessant, clarificador i bo de llegir, Potser massa llarg i tot pels pocs, però importants, conceptes que tracta. Força recomanable.

Abans de festes en Xisco (a.k.a Zigazaga) em va dur la Raspberry, la idea era provar-la per mirar de substituir els ordenadors Pentium IV dels nins, però sobretot veure de primera mà aquest petit dispositiu del qual se n'estava parlant tant a la xarxa. Tanmateix el cost d'un dispositiu així si fa no fa és el d'un sopar sense postres, així que l'experiment si sortia malament tampoc no era excessivament complicat.

Xisco va dur la Rasberry i una capseta, tot queda molt compacte, la veritat. Una visita al magatzem xinès del costat de l'oficina va proporcionar el cable per connectar el monitor i vaig reciclar una tarja SD de 32 Gb que tenia sense utilitzar i que ara torna a ser al caixò dels cables.

La instal·lació va ser cosa de baixar-se la Rasbian, crear el disc d'instal·lació i seguir les instruccions, en poc menys d'una hora el sistema complet i funcionant, amb l'entorn gràfic i tot.

Es pot fer feina, però va molt justet de velocitat. Els nins estan acostumats a jugar online, a l'OpenOffice i ja vaig veure que no aniria gairebé la cosa. Tot i això per fer feina ofimàtica i programar va prou bé.

Així que pla B, a veure com es comportava com a servidor. Vaig desinstal·lar la part gràfica i fer un parell d'optimitzacions que vaig trobar per la web. Després a matxacar el sistema:

• Postgresql 9.1
• Django
• Supervidor
• Servidor ssh
• ngnix
• vim configurat
• htop
• tmux amb byobu
• gunicorn
• virtualenv i virtualenvwrapper

Tot això amb el Raspberry ja sense monitor i que està a la part inferior de la taula a l'altra punta del despatx de casa.

Vaig instal·lar la primera aplicació Django completa amb Gunicorn i connexió a Postgresql. Sense cachés ni res i desde l'ordinador principal un apache benchmark va amollar 3 req/s fent 100 peticions i 5 concurrents. La CPU del dispositiu al 100% però allà el veus tirant de base de dades i servint contingut. Potser 3 peticions per segon no pareixen moltes, però comencem a pensar en hores i dies i la cosa ja canvia.

Així doncs ja tinc un servidor prou bo per trastejar, que pot fer distints usos canviant la tarja SD i que torba uns 20-30 segons en posar-se en producció. Prou divertit.

Ara sols em quedava veure quins més usos es podrien donar al un servidor de despatx. A ca'n APSL vam montar un proxy de PyPi per evitar tenir que descarregar-nos els paquets cada vegada i agilitar la instal·lació dels entorns de les aplicacions. Vaig pensar que seria una bona idea, i vaig instal·lar el PyPiCache, ho vaig configurar a 3 workers (per mi amb un bastaria) i el vaig posar dins l'atenta gestió del supervisor i vaig configurar l'ordinador de feina per a que els paquets les demanàs a la Raspberry.

El proxy el que fa es mirar si té el paquet amb la versió que li demanam, si la té la serveix i si no la demana a PyPi. 42M d'arxius ja hi tenc guardats: Django, PIL, Pillow, Sort, reportlab, ...

El sistema encara no ha tirat de swap, els 512 MB de RAM aguanten la poca càrrega que li estic donant però amb prou utilitat per poder dir que en un tres i no res hauré amortitzat la compra (bé quan Xisco passi la factura clar! :) )

Raspberry te torna el gust a trastejar amb màquines, veure que una cosa tant petita i barata pot fer tanta cosa fa encara més ganes de fer servir més la imaginació i veure fins on es pot arribar.