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.

Amb tot el que hem vist fins ara podem organitzar els nostres enviaments de correus i mantenir al seu manteniment organitzat encara que el nombre d'opcions sigui gran.

Hi ha encara un grapat d'escenaris que és interessant tractar, ja que ens els trobarem sovint. Pensem en aquests possibles escenaris:

• Ens hem de connectar a un servidor SMTP extern i el temps de connexió és gran, la qual cosa fa que la nostra aplicació web no respongui.

• Tenim un entorn de preproducció on els correus no s'enviïn però on volem mantenir registre del que s'hauria enviat.

• Volem mantenir un registre dels correus que s'envien dins la nostra aplicació.

El primer escenari es pot resoldre amb un servidor de correu local y fent realy cap al servidor final, però això a vegades no és possible ja que no tenim la gestió del servidor de correu.

També ho podem resoldre amb un sistema de coes, és a dir, l'enviament de correu es posa com a tasca i és un altre programa (un worker) el que se n'encarrega de fer l'enviament. La combinació de Celery+Redis ens pot anar bé, però també estam afegint un factor gran de complexitat: hem de tenir Redis instal·lat, configurar adequadament Celery i mantenir els workers actius amb supervisor.

Encara que el sistema de coes possiblement sigui l'opció millor per sistemes amb molta càrrega, s'ha d'avaluar bé si per la nostra aplicació convé complicar-nos tant la vida. Quan més peces posem més complexitat, més punts a gestionar, i la simplicitat importa. Si la nostra aplicació creix Django té prou flexibilitat per permetre'ns anar separant capes, afegir les coes, ...

Una solució a tots aquests problemes i escenaris, que a més és prou simple és la de guardar els correus que s'han d'enviar dins una taula de la base de dades i executar un procés cron per fer els enviaments. Això allibera ràpidament a la nostra aplicació web i no té la complexitat de manteniment d'un sistema de coes dedicat.

Com que el cron ho gestionam nosaltres, en preproducció podem dir que no s'executi, i els correus queden dins la base de dades i els podem veure sense cap problema sense fer un enviament real. Si hem de mantenir registre del que s'han enviat doncs també ho tenim.

Això no vol dir que aquest sistema no tengui mancances: si generam molts correus per segon el nostre coll d'ampolla serà la base de dades, però també és veritat que si enviam tal quantitat de correus, llavors sí que potser convé complicar-nos un poc més amb l'arquitectura de l'aplicació.

Dit això uns present django-mailer2. Al link he posat el fork que fem servir a APSL ja que ens hem trobat amb alguns problemes relacionats amb l'unicode que hem resolt i també amb la necessitat de poder visualitzar els e-mails amb adjunts. Així que es va fer un fork del fork i el fem servir a l'espera que l'autor del fork original ens admeti el codi nou, i ja posats vam generar la documentació per posar-la online a readthedocs.

django-mailer2 actua com a backend de Django, per la qualcosa una vegada instal·lada l'aplicació i posada als nostres settings.py hem de configurar el backend per a que quedi com

EMAIL_BACKEND = ‘django_mailer.smtp_queue.EmailBackend’

i farem un syncdb per crear les taules que necessitam a la base de dades.

A partir d'aquest moment els correus que enviem quedaran a la base de dades de django-mailer i no sortiran fins que executem la comanda

python manage.py send_mail

que és el que normalment posarem al cron.

Podem interactuar amb la prioritat d'enviament amb la capçalera

{‘X-Mail-Queue-Priority’: ‘<value>’}

on <value> pot prender els valor:

• now per no posar-ho a la coa i enviar-lo immediatament.
• normal prioritat per defecte
• low prioritat baixa. Sortiran els darrers.

Si fem servir django-mailviews fixau-vos que seria prou senzill fer una classe base que abans d'enviar el correu li posàs la prioritat desitjada, afagint aquest paràmetre als headers.

Per mi aquesta aplicació ha estat un dels factors de productivitat més grans dels darrers mesos. Potser perquè les nostres aplicacions han d'enviar avisos amb adjunts i correus formatejats en HTML, és veritat, però poder mantenir el registre del que s'ha enviat i a l'entorn de preproducció despreoucupar-nos de maldecaps de si s'enviarà el correu sense voler o no és una meravella.

Epíleg

Amb això acab aquesta sèrie d'apunts sobre l'enviament de correus electrònics i Django. Esper que us hagi agradat llegir-los tant com a mi m'ha agradat escriure'ls.

La idea, com sempre, és compartir un poc les troballes que un va fent al llarg del temps. Pensau però que no hi ha veritats absolutes, potser per la vostra aplicació el que he contat per aquí no s'aplicarà, o demà sortirà una manera millor de fer les coses. Si això passa no deixeu d'avisar!

Fins ara hem vist com podem enviar correus electrònics amb format text, amb format HTML en el dos formats. També hem vist que podem generar el nostres correus a partir de plantilles Django.

A poc que l'aplicació es vaig fent més gran veurem que és molt interessant poder tenir tots els correus que enviam centralitzats, de manera que no hagem d'anar a cercar per codi i per les diferents aplicacions els correus que enviam.

Sovint a més els correus que enviam són semblants: van dirigits a la mateixa gent, o tenen informació que canvia molt poc d'uns als altres, com el peu del missatges o la salutació.

Una situació ideal per utilitzar dues coses: les plantilles de Django per a la generació de correus i aprofitar com Django va a cercar les plantilles per tenir tots els correus centralitzats a un mateix lloc, i per una altra banda l'herència pròpia de Python que ens permetrà guanyar temps a l'hora de generar els correus i farà que siguem menys propensos a error a l'hora de generar-los.

Ara és quan a un se li encén la bombeta i es posa com a un boig a generar classes de Python per a la generació de correus amb Django. No faceu tanta via! La primera regla del bricolatge: "si està fet compra-ho". Així que el primer que hem de fer és cercar si ja hi ha alguna cosa feta. I com no, hi és. De fet hi ha vàries llibreries per a la generació de correus fent servir plantilles Django. Una de les més interessants és la que ha fet Ted Kaemming anomenada django-mailviews que a més d'encapsular tot això en classes Python, ho ha posat dins un paquet Django que ens facilita la vida de visualitzar els correus.

La documentació no és tot el completa/acurada que hauria de ser i és focalitza més en la visualització que en el que jo trob més interessant que és aquesta possibilitat d'encapsulació. Així que fork al canto per a millorar la documentació!

En aquest article faré servir aquesta llibreria per mostrar com fer les tasques més habituals i que ja hem vist abans. Ja que hi som aprofitaré també per mostrar com podem enviar un fitxer adjunt.

Enviar un correu sols de text

Volem enviar un correu a un usuari.

Definirem les dues plantilles que utilitzarem, la primera per l'assumpte (subject) y l'altra per al contingut.

Cream un directori anomenat mail (sóc així d'original) dins templates de la nostra aplicació principal. A partir d'aquí podríem anar creant diferents subdirectoris segons els correus per a enviar, però supòs que ja es veu la idea...

La plantilla per l'assumpte queda com:

 {# plantilla 'mail/subject.html'
 Greetings {{user.get_full_name}}

i seguidament definim el cos del missatge

{# plantilla 'mail/body_text.html' #}
Dear {{user.get_full_name}}, 
You are the best.

Please give us your money!

El codi per enviar aquest missatge podria ser alguna cosa semblant a:

    from mailviews.messages import TemplatedEmailMessageView
    from django.contrib.auth.models import User

    class SimpleSpamView(TemplatedEmailMessageView):
        """
        Classe per spamejar l'usuari demo i dir-li que ens doni els doblers
        """

        subject_template_name = 'mail/subject.html'
        body_template_name = 'mail/body_text.html'

        def get_context_data(self, **kwargs):
            context = super(SimpleSpamView, self).get_context_data(**kwargs)
            context['user'] = self.user
            return context

        def render_to_message(self, *args, **kwargs):
            self.user = User.objects.get(username='demo')
            kwargs['to'] = (self.user.email, )
            return super(SimpleSpamView, self).render_to_message(*args, **kwargs)

i per enviar-lo bastaria cridar:

SimpleSpamView().send()

Pareix molta feina comparat amb el que teníem, veritat? Doncs sí, però com passa amb els class based views de Django aquesta feina extra inicial es veu compensada de sobres per la claretat del codi, que d'aquesta manera queda molt documentat, separant el text de generació, i sobretot possibilitant la reutilització.

Per cert la sortida d'aquest correu és:

Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Greetings Demy Ostracion
From: webmaster@localhost
To: demo@example.com
Date: Thu, 28 Mar 2013 11:40:53 -0000
Message-ID: <20130328114053.6625.94194@T1600>

Dear Demy Ostracion,

You are the best.

Please give us your money!

Com podem veure es tracta d'un missatge codificat com a text, que és precisament el que cercàvem.

Correu amb text i HTML

Sabem que Demy, el nostre usuari de proves, fa servir un lector de correu que permet el format HTML, així que per reforçar més el missatge el que farem serà enfatitzar el missatge generant una plantilla HTML

{# mail/body_html.html #}
Dear {{user.get_fullname}},

<h1>You are the best!</h1>

<strong>Please give us your money!</strong>

Ara el que farem és que enlloc de fer herència de TemplatedEmailMessageView la farem de la classe TemplatedHTMLEmailMessageView que té un atribut nou html_body_template_name

    from mailviews.messages import TemplatedHTMLEmailMessageView
    from django.contrib.auth.models import User

    class SimpleSpamView(TemplatedHTMLEmailMessageView):
        """
        Classe per spamejar l'usuari demo i dir-li que ens doni els doblers
        """

        subject_template_name = 'mail/subject.html'
        body_template_name = 'mail/body_text.html'
        html_body_template_name = 'mail/body_html.html'

        def get_context_data(self, **kwargs):
            context = super(SimpleSpamView, self).get_context_data(**kwargs)
            context['user'] = self.user
            return context

        def render_to_message(self, *args, **kwargs):
            self.user = User.objects.get(username='demo')
            kwargs['to'] = (self.user.email, )
            return super(SimpleSpamView, self).render_to_message(*args, **kwargs)

i l'enviam com abans

    SimpleSpamView().send()

que té per sortida:

Content-Type: multipart/alternative;
boundary="===============6944209950729072063=="
MIME-Version: 1.0
Subject: Greetings Demy Ostracion
From: webmaster@localhost
To: demo@example.com
Date: Thu, 28 Mar 2013 11:56:34 -0000
Message-ID: <20130328115634.6625.91235@T1600>

--===============6944209950729072063==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Dear Demy Ostracion,

You are the best.

Please give us your money!

--===============6944209950729072063==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Dear Demy Ostracion,

<h1>You are the best!</h1>

<strong>Please give us your money!</strong>

Adjuntant arxius a un correu

Des de marketing ens diuen que ara el que convé és adjuntar fitxers en pdf per reforçar encara més el missatge i tenir el nostre usuari entretingut, així que ens passen un pdf amb informació corporativa que hem d'adjuntar a cada e-mail que li enviam a Demy.

Nosaltres el desarem al nostre directori pdf, però tenim un problema, la classe que estam fent servir no diu res d'adjuntar pdf. Però nins, això és codi obert i li podem fer una ullada al codi. Com podem veure el que fa render_to_message és tornar-nos una instància de la classe EmailMessage de Django i aqueta té dos mètodes per adjuntar imatges attach i attach_file. La primera la farem servir principalment quan tenim un fluxe de dades (per exemple hem generat nosaltres el pdf i està en memòria) i la segona quan tenim el fitxer dins el sistema d'arxius.

    from mailviews.messages import TemplatedHTMLEmailMessageView
    from django.contrib.auth.models import User

    class SimpleSpamView(TemplatedHTMLEmailMessageView):
        """
        Classe per spamejar l'usuari demo i dir-li que ens doni els doblers
        """

        subject_template_name = 'mail/subject.html'
        body_template_name = 'mail/body_text.html'
        html_body_template_name = 'mail/body_html.html'

        def get_context_data(self, **kwargs):
            context = super(SimpleSpamView, self).get_context_data(**kwargs)
            context['user'] = self.user
            return context

        def render_to_message(self, *args, **kwargs):
            self.user = User.objects.get(username='demo')
            kwargs['to'] = (self.user.email, )
            msg = super(SimpleSpamView, self).render_to_message(*args, **kwargs)
            msg.attach_file('./pdfs/test.pdf')
            return msg

    SimpleSpamView().send()

Que torna:

    Content-Type: multipart/mixed; boundary="===============5276732835281812163=="
    MIME-Version: 1.0
    Subject: Greetings Demy Ostracion
    From: webmaster@localhost
    To: demo@example.com
    Date: Thu, 28 Mar 2013 12:11:51 -0000
    Message-ID: <20130328121151.6625.85753@T1600>

    --===============5276732835281812163==
    Content-Type: multipart/alternative;
     boundary="===============7874338344503940985=="
    MIME-Version: 1.0

    --===============7874338344503940985==
    Content-Type: text/plain; charset="utf-8"
    MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit

    Dear Demy Ostracion,

    You are the best.

    Please give us your money!

    --===============7874338344503940985==
    Content-Type: text/html; charset="utf-8"
    MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit

    Dear Demy Ostracion,

    <h1>You are the best!</h1>

    <strong>Please give us your money!</strong>

    --===============7874338344503940985==--
    --===============5276732835281812163==
    Content-Type: application/pdf
    MIME-Version: 1.0
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename="test.pdf"

    JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl
    Y29kZT4+CnN0cmVhbQp4nDPQM1Qo5ypUMFAwALJMLU31jBQsTAz1LBSKUrnCtRTyIHJAWJTO5RTC
    ZWoGlDI3NwEqDklR0HczVDA0UghJi7YxMLQzs7AxMLIztDEwttM1sjEwsYsN8eJyDeEK5ApUAAB7
    ....
    ....
    --===============5276732835281812163==--

Com podeu veure s'ha enviat tant el text pla, l'html i el nostre adjunt.

En una aplicació real el path cap a l'arxiu seria una variable i/o estaria codificat de manera absoluta, però per l'exemple ja em perdonareu.

A partir d'aquí ja podeu veure que les possibilitats de personalització són infinites. Pensau que en una aplicació real amb molts correus a enviar, poder organitzar el codi en classes ens permetrà reaprofitar molta feina, i sobretot ens llevarà feina de depuració a l'hora d'anar canviant el texte del correu o les condicions en que s'ha d'enviar un correu.

I al proper article parlarem d'enviaments, coes, registre i depuració. Tot en un mateix paquet django-mailer2.

Enviar un e-mail fent servir plantilles Django

Com ja tots sabeu Django té un sistema de plantilles molt eficaç. Normalment les fem servir per mostrar l'html de les nostres aplicacions web, però no estan limitades a això, i com veurem les podem fer servir per generar els nostre correu.

La manera de fer-ho és fent servir render_to_string que podem trobar a django.template.loader. Aquesta funció agafa com a paràmetres el nom de la plantilla que volem fer servir i un diccionari amb els paràmetres que farem servir a la plantilla. Agafa un tercer paràmetre, que ha de ser de tipus Context, però que per als nostres objectius no la farem servir gaire.

Quan volem enviar un correu ho podem fer dins la vista, però sovint ho farem des de classes d'utilitat, el model o un formulari, on el request no està disponible. Per això hem de tenir em compte que la majoria de vegades no tindrem accés a les variables que normalment estan accessibles a les plantilles mitjançant el context processors. Així doncs que si el correu te links pensau que tot el que siguin referències a arxius i links forçosament necessiten de Sites, MEDIA_URL i STATIC_URL (o fer servir el tag {% static %} introduït a les darreres versions de Django.

Suposem doncs que tenim el seguent, dins una plantilla que hem anomenta newsletter.html i que tenim accessible dins els TEMPLATE_DIRS

Benvolgut {{user.get_fullname}},

No deixis de visitar les nostres ofertes a http://{{current_site}}/ofertes/

Salutacions,

--
info@{{current_site}}
http://{{current_site}}

I a la funció que genera el correu tendríem per exemple:

from django.contrib.sites.models import Site
from django.conf import settings
from django.template.loader import render_to_string
from django.core.mail import EmailMessage

def send_wellcome():
    """Envia un missatge als nostres usuaris"""
    current_site = Site.objects.get_current().domain
    context = {'current_site': current_site}
    for u in User.objects.all():
        context['user'] = u
        body = render_to_string('dos/newsletter.html', context)
        msg = EmailMessage(subject="hello",
        body = body,
        from_email="jo@apsl.net",
        to=['someuser@example.com'])
        msg.content_subtype = "html"
        msg.send()

Fixem-nos com context és un diccionari on li hem de passar totes les variables que utilitza la nostra plantilla. En aquests tipus de corrreus el més habitual és anar en pilot automàtica i fer servir les variables {{STATIC_URL}} o {{MEDIA_URL}} habituats a tenir-les accessibles gràcies als context_processors i trobar-nos que als nostres e-mails no es veuen les imatges. Així que a més de passar-les al context ens hem d'assegurar que es passen aquestes variables i a més que les urls es generen com a url absolutes.

Per això a la plantilla de Django podem fer servir la llibreria static i utilitzar els tags get_static_prefix i get_media_prefixper a generar les urls. Seria una cosa semblant a

{% load static %}
{% get_static_prefix as STATIC_PREFIX %}
{% get_media_prefix as MEDI_PREFIX %}

<img src="http://{{current_site}}/{{STATIC_PREFIX}}/img/log.jpg" alt="logo" />
<img scr="http://{{current_site}}/{{MEDIA_PREFIX}}/profile/{{foto}}" alt="foot pujada" />

No fa falta recordar que a static hi posarem totes aquelles images, css, js, etc que formen part de l'estructura de l'aplicació i a media hi haurà totes aquelles imatges i continguts que puja l'usuari de la nostra aplicació.

Donat que hem utilitzat en render_to_string per a generar el cos del missatge, segur que a més d'un se li haurà acudit que podem fer el mateix amb el subject, doncs sí, si és necessari es pot fer i de fet es fa. Però això ja serà al proper article...

En aquest article, o millor dit, sèrie d'articles, intentaré explicar el millor que pugui la problemàtica que ens trobam en el dia a dia la gent que hem d'enviar correus electrònics des de les nostres aplicacions Django, no tant des del punt de vista de com es fa, sinó del programador que té que desenvolupar d'aplicació.

Veurem distints escenaris i com podem tenir una solució que s'adapta a cada un d'ells, de manera que acabem amb un petit receptari, que esper anar ampliant amb l'adjuda de tots. La referència fonamental per Django és la documentació "sending email", miraré de no repetir-la molt, però per completitud convé fer una petita introducció.

Configurar el servidor

Volem enviar un e-mail ràpid en resposta a un esdeveniment.

Per a poder enviar un e-mail des de la nostra aplicació Django prèviament haurem d'haver configurat en nostre servidor SMTP. Això es fa amb les variables del settings EMAIL_HOST, EMAIL_PORT, EMAIL_HOST_USER i EMAIL_HOST_PASSWORD. Ja que hi som convé definir el mail que farem servir en cas que no el posem de manera explícita al DEFAULT_FROM_EMAIL

Normalment no hem de definir res si el nostre servidor d'e-mail és el mateix servidor on està l'aplicació i tenim un SMPT local, però pot ser necessari si volem fer servir un altre servidor amb un compte específic, com per exemple el gmail de Google podríem fer:

DEFAULT_FROM_EMAIL='jo@exemple.com'                                     
EMAIL_USE_TLS = True                                                           
EMAIL_HOST = 'smtp.gmail.com'                                                  
EMAIL_HOST_USER = 'usuari-gmail@gmail.com'                                      
EMAIL_HOST_PASSWORD = 'clau-super-secreta'                                         
EMAIL_PORT = 587

Enviar un e-mail

Volem enviar un mail a un conjunt de destinataris, per això podem fer servir la funció send_mail que ens proporciona Django

from django.core.mail import send_mail
send_mail(subject='test email 2', message='hello world 2', 
    from_email='antoni.aloy@example.com', 
    recipient_list=['un@apsl.net', 'dos@trespams.com'], fail_silently=False)

Aquí convé notar que hem de posar tant qui envia el mail from_email com la llista de destinataris. És un error molt comú posar al recipient_list el mail de la persona que ha de rebre l'e-mail sense aturar-se a pensar que la funció necesita una llista com a paràmetre. Si sols teniu una adreça que ha de rebre l'e-mail pensau que l'hem de convertir primer en una llista

from django.core.mail import send_mail
send_mail(subject='test email 2', message='hello world 2', 
    from_email='antoni.aloy@example.com', 
    recipient_list=['un@apsl.net',], fail_silently=False)

Si volem fer enviaments massius Django a les darreres versions incorpora la funció send_mass_mail que permet enviar correus sense tenir que obrir cada vegada la connexió amb el servidor.

Django a més ens proporciona dues funcions adicionals per simplificar el codi necessari per enviar els correus quan els destinataris són la llista d'administradors del lloc i el managers dels mateix, definits respectivament a les configuracions ADMINS i MANAGERS, que són mail_admins i mail_managers.

D'aquesta manera, com ja sabem quins són els destinataris sols hem d'omplir l'assumbte (subject) i el missatge (message) i ja ho tenim. Aquestes funcions agafen un paràmetre adicional html_message que ens permet enviar el missatge com a text/html enlloc del text/plain definit per defecte.

Així per exemple:

from django.core.mail import mail_managers
mail_managers(u'Avís nou usuari', u"Tens un nou usuari al sistema")

Ens serviria per enviar un correu quan es crea un nou compte d'usuari amb ben poca feina.

Enviar un correu en format HTML

Encara que la manera més ràpida i simple d'enviar un correu sia el text pla, sovint ens trobam que els nostres clients volen que el coreu s'envïi en format html, amb tota mena de decoració: negreta, cursives, links, imatges, arxius adjunts, ...

Això representa una nova complexitat, no per la dificultat d'enviar-ho, que com veurem és prou senzilla, sinó perquè no hi ha cap garantia que es vegi com un vol a la majoria de clients de correu. Per això el que més convé és fer els HTML dels correus el més senzill possibles, sense floritures i tornant a la programació a l'antiga. La gent de mailchimp té un bon grapat de consells damunt el tema i fins i tot va alliberar en el seu dia un bon conjunt de plantilles que ens poden servir de guia i que trobareu a github baix el nom de email-blueprints.

Començarem pel més senzill: suposarem que sols volem enviar un correu en format HTML sense part en text pla.

from django.core.mail import EmailMessage
msg = EmailMessage(subject="hello", 
    body="""<strong>Hello</strong> World""",
    from_email="jo@exemple.com",
    to=["someotheruser@example.com", ])
msg.content_subtype = "html"
msg.send()

La classe EmailMessage ens permet a més definir una llista de destinataris ocults (el típic bbc), destinataris amb còpia, afegir arxius, modificar les capçaleres o definir com establirem la connexió amb el sistema d'enviament de missatges. Hi tornarem un poc més tard amb això.

En missatges realment importants, on volem que es faci la lectura independentment del client de correu, convé enviar tant la part HTML com la part tn text plà. Django també ens permet fer-ho amb facilitat fent servir la classe EmailMultiAlternatives. Com a sublcasse d'EmailMessage ens permet fer el mateix que aquesta, però a més ens permet definir tant la part de text plà com l'html. D'aquesta manera el nostre *hello world" quedaria

from django.core.mail.import EmailMultiAlternatives
text_content = "hello wolrd!"
html_content = "hello <strong>world!</strong>"
msg = EmailMultiAlternatives(subject, 
    text_content=text_content, 
    from_email="jo@example.com", 
    to=["someone@example.com"])
msg.attach_alternative(html_content, "text/html")
msg.send()

Testejar els mails

Anam avançant en el tema, ara ja sabem com enviar mails en text pla i en format HTML, enviar-los als administradors, a una persona, a vàries, ... Tot això està molt bé, però com que fem les proves amb la nostra pròpia compta de correu aquesta comença a estar plena de mails de proves i hem d'anar amunt i avall amb el client de correu.

Com bé podeu suposar hi ha d'haver una manera de poder fer feina amb els correus sense aquests inconvenients. La resposta està en els backends que Django ens permet definir a la configuració.

Per defecte Django configura la variable EMAIL_BACKEND com

EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'

això vol dir que per defecte Django intentarà enviar l'e-mail mitjançant el servidor smpt que hem definit dins EMAIL_HOST (que és localhost per defecte), si no tenim el servidor smtp configurat ens donarà error a l'hora d'enviar el correu.

Podem substituir aquest comportament per defecte per un backend alternatiu, a l'hora de testejar i veure que està passant, sobretot si estam en el servidor de desenvolupament de Django, podem fer que el missatge s'enviï per la consola canviant el backend a

EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'

així, encara que la configuració que tinguem sigui bonan, podem fer que el missatge no s'enviï i que sols surti per la consola.

Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: hello
From: jo@example.com
To: unaltre@exemple.net
Date: Sun, 24 Mar 2013 19:23:41 -0000
Message-ID: <20130324192341.9841.81239@T1600>

<strong>Hello</strong> World
-------------------------------------------------------------------------------

pràctic, veritat?

També hi ha un altre backend que pot ser útil, el File backend que enlloc de mostrar el missatge a la consola ens permet definir un directori on deixar-hi els correus mitjançant la variable EMAIL_FILE_PATH, però la veritat és que no l'he fet servir gens, com veurem hi ha altres alternatives més potents i que també ens faciliten la vida a l'hora de desenvolupar.

En els propers apunts ...

Fins ara no hem vist res que no sigui a la documentació de Django, però esper que us hagi servit d'introducció ràpida per al que vindrà després:

• Generar correus amb les plantilles Django
• Alternatives per generar els correus
• Backends alternatius: django-mailer2

En el darreres setmanes hi ha força enrenou a la xarxa referent al món informàtic: web multimilionàries que algú diu que faria per 500 €, queixes constants del sous o no sous. Fins i tot en David Bonilla a la seva llista diària se'n fa ressò, dient que en molts de casos és una estratègia per aixecar polseguera i aconseguir enllaços i posicionament. En alguns dels darreres apunts que he llegit no us diré que no, ja que en la discussió fins hi tot hi havia EL TROLL, que no va ser moderat en camp moment pel propietari del blog que havia iniciat la polèmica. Potser sí que en Bonilla té raó.

Això de totes maneres ve molt de passada amb el que volia parlar avui, que és del tema becaris. Fins ara a la nostra empresa hem tingut dos becaris: Juan, un amic de fa anys que feia un curs i cercava una empresa "seriosa" en la que realment pogués aprendre alguna cosa a la seva cinquantena d'anys i en Pau, becarium infinitum com ell mateix se defineix, que està amb nosaltres com a becari mentre acaba el projecte de final de carrera.

Agafar un becari per mi és una responsabilitat gran. No és algú que t'ha de fer els cafès o fer fotocòpies, o a qui i pots encarregar les tasques que ningú vol fer. Un becari fa una feina per l'empresa a canvi d'una supervisió i un aprenentatge.

L'empresa es pot aprofitar dels més baixos del becari en les cotitzacions socials (zero de fet) i a canvi d'això ha de donar al becari una formació laboral que potser li manca quan ve des del món acadèmic. Per mi això implica assignar-lo inicialment a un projecte intern o sense risc ni plaç d'entrega, poder supervisar el codi que s'escriu, corregir-ne els errors i estar disposat a contestar totes les preguntes que es facin.

Conforme el coneixements van augmentant la supervisió ja no fa falta que sigui tan a nivell micro i es pot anar assignat a aquesta persona a projectes amb més grau de responsabilitat. Sols amb aquesta progressió obtindrà la formació adequada, ja que si al llarg de la beca no pot integrar-se a un projecte normal, voldrà dir que l'etapa d'aprenentatge inicial no ha estat prou bona. Integrar-se en un projecte amb risc i dates d'entrega vol dir poder viure el dia a dia d'un projecte real, amb errors que s'han de corregir, amb codi que s'ha de mantenir, col·laborant amb altres programadors i entrant dins la dinàmica habitual de l'empresa.

Com podeu veure ser un becari a APSL no és cap bicoca, implica molta feina tant pel propi becari com per l'empresa. I trob que és així com ha de ser. El becari ha de ser rendible per l'empresa després de la inversió que fa aquesta en la seva formació, però aquesta inversió hi ha de ser sí o sí. Ser becari ho entenc com una responsabilitat de les dues parts.

Segurament per això ens hi miram tant a l'hora d'agafar-ne de becaris. Hem de tenir temps per dedicar-los i projectes adients on puguin aprendre. Sovint tenim ofertes d'empreses de formació que ens volen enviar gent, on fins i tot hi ha una subvenció de l'estat per tenir-los, oferint-los com a ma d'obra barata. No gràcies!

Si el becari acabarà essent rendible per a l'empresa el becari ha de cobrar i el sou ha de ser adient amb la seva formació, amb els resultats que s'esperen i tenir en compte també el cost de la formació interna que rebrà. Curiosament al nostre país si vols pagar un sou decent a un becari pots tenir problemes (així ens ho va dir la gestoria) ja que es pot considerar que no és una relació d'aprenentatge sinó una relació laboral. En canvi, si a un becari no li pagues res, el tens putejat fen feina que no vol ningú i no en fas el seguiment i la tutorització, doncs no passa res, és el que tothom espera.

Doncs a fer punyetes el que tothom espera! Personalment seguiré amb aquestes idees, i amb la idea que un becari format a APSL és una inversió de futur tant per ell com per a la pròpia empresa, ja que en cas de que la feina creixi, qui millor que incorporar-se a ella que algú que ja sap de primera mà com funciona?

Un becari a més significa sang nova, un punt de vista diferent respecte de com es fan les coses. Sols el fet de tenir que explicar-les a algú ja fa que et puguis replantejar si allò que estàs fent té sentit, si hi ha maneres de fer-lo millor. I també és una oportunitat d'aprendre. Amb Pau, per exemple, una part del grup d'APSL va passar a sistemes d'escriptori Linux basat amb Tiles i fins i tot em vaig deixar convèncer per tenir una Debian unstable al portàtil.

Potser quan aquesta manera de fer les coses sigui la norma i no l'excepció el nostre sector començarà a canviar. Sempre he trobat que per intentar canviar les coses el millor que es pot fer és practicar amb l'exemple. Jo vull tenir becaris que s'enorgulleixin de poder dir que començaren a l'empresa des de becaris o que si per les raons que siguin ja fan feina a APSL puguin posar-lo ben gran al seu currículum.

Una de les coses que me fan més peresa quan he de crear una nova aplicació Django és tenir que configurar una aplicació per poder-ne fer els tests quan sols estàs fent un mòdul que serà reutilitzable per a altres aplicacions.

Una vegada s'ha fet l'aplicació el que voldria és poder-ho testejar sense tenir que configurar tot un projecte i no acabava de trobar-ho del tot fins que vaig veure la manera en que ho feia Brutasse a django-password-reset.

L'aproximació de Brutasse és tenir una projecte Django dins la mateixa applicació que s'està creant, de manera que aquesta es pot testejar sense tenir que crear el projecte sencer i controlant a la mateixa vegada els settings que estam fent servir. És a dir, just el que estava cercant.

Aquests darrers dies he estat treballant un poc en una branca de django-mailer2 i l'he refactoritzat per seguir la seva idea a l'hora de fer els unit tests.

Una vegada creat el [paquet python] (http://guide.python-distribute.org/index.html) el que es fa es crear un arxiu que serà l'executable que iniciarà els tests. runtests.py per no ser massa originals

Creant l'executable

Aquí el que fem és configurar l'aplicació com se fos una execució desatesa de Django, és a dir, configuram els settings, el path i després ja sols ens queda fer l'execució dels unittests

#!/usr/bin/env python
# encoding: utf-8
# ----------------------------------------------------------------------------

import os
import sys

parent = os.path.dirname(os.path.abspath(__file__))
sys.path.insert(0, parent)
os.environ['DJANGO_SETTINGS_MODULE'] = 'django_mailer.testapp.settings'

from django.test.simple import DjangoTestSuiteRunner

def runtests(*test_args):
    test_args = test_args or ['testapp']
    parent = os.path.dirname(os.path.abspath(__file__))
    sys.path.insert(0, parent)
    runner = DjangoTestSuiteRunner(verbosity=1, interactive=True,
                                   failfast=False)
    failures = runner.run_tests(test_args)
    sys.exit(failures)

if __name__ == '__main__':
    runtests()

Fixem-nos ja de pas que faríem el mateix si hem creat una aplicació Django que no volem que s'executi com a servei web. Per exemple una importació de dades, o una exportació. Hi ha diverses maneres d'aconseguir-ho i aquesta és una de les més simples.

Una vegada hem establit la variable d'entorn de la nostra aplicació (la que contindrà els tests) ja tenim tota la potència del framework Django al nostre abast.

L'apliació testejadora

Per no fer-nos massa enfora de la convenció de Django, posam l'aplicació que realment executarà els tests dins el directori del mòdul que hem desenvolupat, en el nostre exemple django_mailer.

Podríem posar-li test, però la veritat és que no m'agrada això de tenir un projecte test i dintre un mòdul test. Sovint fa difícil saber on tens els errors, així que un nou explícit ja va bé.

Dins testapp trobam el que seria un projecte Django bàsic, sols que a més hi hem postat un settins que són molt reduïts,

EMAIL_PORT = 1025
ROOT_URLCONF = 'django_mailer.apptest.urls'

SECRET_KEY = 'yo secret yo'

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': 'django_mailer.sqlite',
    },
}

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django_mailer',
    'django_mailer.testapp'
)

Bàsicament hi ha els paràmetres de configuració que necesistarem per a executar l'aplicació que estam creant, configuració de base de dades i la configuració dels INSTALLED_APPS on hi ha la pròpia aplicació de test i l'aplicació que estam testejant, de manera que ho tinguem tot dins el Python path.

A partir d'aquí tot va com a la documentació de Django, és a dir, cream un mòdul anomenat test i utilitzam el mòdul TestCase de Django i tota la resta d'artilleria.

El que hem aconseguit, però, és fer més senzill el manteniment de l'aplicació ja que queda tot autocontingut. Al tenir uns settings mínims també podem estar raonablement segurs que l'aplicació que cream funcioni bé per ella mateixa sense altres interferències, i com no, ens queda documentat el que necessitam per a fer-la anar.

No estic convençut de poder-ho considerar encara una "millor pràctica", però ho trob útil i potser a algú dels qui em llegiu també us pot solucionar un problema, així que ja em contareu.

Ahir vai acabar de llegir "Two Scoops of Django", el nou llibre, encara en versió Alfa que han tret DAniel Greenfeld i Audrey Roy.

A diferència d'altres llibres que t'ensenyen a programar o et mostren el funcionanment d'un framework de programació, aquest llibre no és un tutorial per als no iniciats, sinó més bé una mena de consultoria de millors pràctiques en forma de llibre.

Els autors "es banyen", recomanant utilitats i maneres de fer les coses per tal que els nostres projectes siguin més bons de desplegar i mantenir. Es recomanen llibreries externes per a facilitar-nos la vida: South, Virtualenv, Virtualenvwrapper (vells coneguts també per aquest blog) i fins i tot entra en la petital polèmica que hi ha damunt si és millor fer-ho tot amb CBV, fer una mescla o no fer-les servir.

Puc dir que estic gairebé al 100% d'acord amb totes les recomanacions. Val a a dir que hem arribat a les mateixes conclusions que els autors en garebé tots els aspectes. Fins ara no feiem servir les variables d'entorn i és una cosa que de ben segur ens mirarem amb cura.

Punts que potser estaria bé tractar o de discrepància:

• Nom del projecte. Personalment no m'agrada gens tenir el nom del projecte igual al nom de l'aplicació django igual a l'aplicació principal. A poc que et descuidis pot donar lloc a errors d'importació que et fan perdre una bona estona. Per això m'estim més anomenar al projecte prj_[nom_projecte], i en Django 1.5 me pareix que optaré per anomenar a la part principal del projecte com a main i buidar-la de contingut llevat de ser el nexe d'unió de les urls i potser de la vista que ens mostra l'index.

• Mail. Per mi és una de les millores més interessants que hem incorporat darrerament en el desenvolupament d'aplicacions Django. Django et permet enviar els mails a la consola per depurar, o bé, junt amb Python podem habilitar un servidor de correu local. Però en la majoria d'ocasions ens interessa poder veure el correu que s'havia enviat, o seguir el link, i no volem que realment s'estiguin enviant els correus. Per això la troballa de django-mailer-2 va ser força interessant, ja que ens permet guardar els mails que s'envien dins la base de dades i poder consultar-los amb l'administrador de Django. Els correus no s'envien fins que habilitam una tasca al cron. Trob que és ideal en els entorns de preproducció (amb la tasca del cron desactivada) i en les primeres etapes de la posada en producció, on vols tenir un control molt fi del que està passant a l'aplicació.

Tornant al llibre. Trob que és una inversió molt bona, però heu de saber què us trobareu: si no heu fet cap projete amb Django no és un bon llibre per aprendre. Si ja n'heu fet un grapat, segur que el llibre us servirà per millorar la vostra 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.

i faré un apunt d'aquesta darrera setmana. Entre mocada i mocada puc teclejar, i potser tenc el cap en aquest estat de mig embotiment que em permet escriure encara que amolli algun doi que altre.

Aquesta tenia dos events marcats a foc al calendari: una conferència sobre estimació de projectes organitzada per PMIB i la inauguració de la nova oficina d'APSL. La resta podem dir que és el dia a dia de la feina i de la vida (això de fer Tai-Chi crec que em comença a afectar).

La conferència

El taller va començar un tant malament, idees com "per fer una bona estimació de projectes el que hem de fer és passar la feina als estimadors", doncs com a que no sonen molt bé, encara que la intenció era bona. Per mi la idea que es volia transmetre era la de que millor demanar a la gent que té experiència en projectes semblants. La conferència en si va ser entretinguda, però de cap manera es pot considerar un taller, potser una introducció als conceptes més bàsics i encara així crec que va pecar de voler tractar massa coses i no centrar-se en res.

Em vull fixar però amb un fet, potser anecdòtic, però que demostra un cert tic recurrent en alguns àmbits de la gestió de projectes. En un moment donat el ponent va presentar una diapositiva on es veia el cap de projectes en gran i vermell, rodejat dels estimadors, molts més, petits, de blanc i envoltant-lo. "Jo sóc el vostre amo i senyor i m'heu d'adorar", pareixia que deia. Entre això i l'ús de la paraula recurs per fer referència a les persones em reafirma en la convicció que en la gestió de projectes encara queda molta vella escola que sols necessita d'una petita distracció per aflorar.

Per mi el responsable del projecte ha de ser un facilitador, no el deu indiscutible del projecte. És responsable de que el projecte vagi endavant, però això no significa que tengui que considerar la gent involucrada al projecte com a recurs intercanviable, ben al contrari. Ha de tractar cada membre de l'equip com el que és una persona, i fer tot el possible per a que aquesta persona pugui fer la seva feina de la millor manera possible.

De la part d'estimació poca cosa a dir, ja que no es va aprofundir massa en res. Sols comentar alguna opinió que vaig sentir a la sortida, "que tot això estava molt bé, però que passa quan algú s'ha de banyar donant una quantitat fixa del cost". Supòs també en referència a una afirmació que es va fer dient que una estimació dolenta era sempre millor que no tenir-ne cap. No hi estic d'acord, hi ha cops on ens hem de mantenir fermes i negar-nos a fer cap estimació amb un mínim de garanties.

La inauguració

El divendres a la tarda, i a petició popular, férem una mica de refresc a APSL per inaugurar la nova oficina. Val a dir que queda demostrat que no tinc massa habilitats socials i tot això m'estressa, però la veritat és que després m'encanta xerrar amb els amics, i d'amics en passaren molts. Una vuitentena pel cap baix, 10 segons la policia municipal i 120 segons el becari.

L'index de gominola va estar força bé, ens acabàrem entre tos 1.5 quilos de gominolas, a més de coca de trampó i melicotó.

Vam voler que el lema fos "L'APSL Style", en referència tant a la cançó de moda (que ja escoltàvem nosaltres des d'abans de fer-se popular, descobriment de na Mayuko i Juan) com a la nostra visió de com poden ser les coses.

Crec que estam aconseguint fer d'APSL un bon lloc per fer feina, per agrupar a la gent que entén la professió també com a una passió. I pens que aconseguint que anar cap a la feina sigui una il·lusió diària més que allò que s'ha de fer per guanyar-se la vida.

No hi ha sofà, ni sala de ping pong, ni billars, però crec que tampoc no ens fan falta. Hi ha bones eines per fer feina. Cadires que no et destrossen l'esquena i pantalles de bona qualitat, però sobretot hi ha un grup de gent entregada, que fa pinya i que ens ho passam bé plegats. Ja que hem de fer feina per guanyar-nos la vida, perquè no fer allò que ens agrada de la manera que ens agrada?

No vull acabar sense recordar a @sebaSj, que cada vegada que fem una mica de trui li dona per tenir una filla nova. L'enhorabona família! Criau filles geeks que ben cert és el que el món necessita.

PS. Fotos? No hi vaig pensar en les fotos. Ja us he dit que no tinc habilitats socials...

El divendres 23 de novembre, a mena de regla d'aniversari un poc tardà, als voltants de les 3 del capvespre vam començar a empacar el que teníem a l'oficina del Parc Bit.

Hi hem estat gairebé quatre anys al Parc, però com vaig dir a un altre apunt, en aquests moments per gent com nosaltres el Parc no representa cap avantatge, sinó tot el contrari. Un 10 per les facilitats de la incubadora, però quan això s'acaba es fa més palès allò que ja sabies: que el Parc té males comunicacions, que cada vegada hi ha més dificultats per accedir-hi, i que la gent hi ha d'anar a posta i quan hi va ho té molt mal de fer per accedir-hi. Una mala manera de començar una relació comercial, ...

Vam trobar una oficina al Polígon de Son Castelló. Per allà, supòs que per mor de la crisi, hi ha oficines a molt bon preu. En el nostre cas l'oficina és més gran que l'anterior, amb tots els serveis inclosos llevat de l'ADSL i el telèfon i a més ens trobam que tots necessitam de l'ordre de 10 a 15 minuts menys per arribar-hi. Per acabar-ho de rematar també resulta un 50% més barata que una oficina semblant al Parc. Bé, ja ho vaig contar per aquí a un altre apunt damunt la decisió de deixar el Parc així que no em repetiré.

Després d'arreplegar el que teníem a l'oficina en n'adonam de la quantitat de papers i altres andròmines que un va acumulant amb els anys. L'equip ha crescut i sols amb ordinadors i pantalles, cadires i mobiliari omplirem una furgoneta de les grosses.

Som una empresa petita, on sempre hem procurat mantenir les despeses al mínim, així que tiràrem d'amics i coneguts per fer la mudança. Un amic de Bernat ens facilità la furgoneta, i dissabte al matí carregàrem tot. Prèviament, al divendres al matí Movistar ja havia fet el canvi de línia segons s'havia planificat.

El primer que va fallar als plans van ser les taules. Poc abans de moure'ns ens van dir que les taules no arribarien fins dimecres. Estava previst, Pla B, i unes taules plegables que fem servir a la Vermada cap a l'oficina nova que anaren. L'espai de feina seria reduït i en lloc de 2 pantalles faríem feina amb 1 però 3 dies podríem anar fent. A més l'edifici té WIFI així que l'absència d'ADSL, que no estava encara perquè per Movistar no es pot fer a la mateixa comanda el moure la línia i posar l'ADSL, estaria compeasa al manco en part per això i una configuració d'enrutat que Bernat va fer a un dels portàtils.

El dissabte poc passat la una del migdia ja teníem gairebé tot el necessari que treballar el dilluns, no amb les millors condicions, és veritat, però es podria fer feina.

Descobrim el primer avantatge: podem dinar tots plegats un dissabte prop de l'oficina. Hi ha bars i restaurants oberts, fins i tot podem dinar a un lloc i fer el cafè a un altre.

El dilluns començarem a fer feina, però al migdia la WIFI va dir prou. Sospit d'un tècnic que culejava a la sala de comunicacions, però no ho puc demostrar, coincidència? Res, donam avis i Pla B una altra vegada: tiram de mòbils i planificam la feina des de casa per part de l'equip i fer feina amb la connexió mòbil i connexió "pinxo de dades de 6GB" per la resta. Tot i això el dilluns capvespre va ser prou productiu.

El dimarts començam connectats al pinxo, però a les 9 crida ja el tècnic de Movistar que ja venia a posar la línia, que si ens anava bé de prest. Fantàstic! Als voltants de les 10:30 ja teníem ADSL en marxa. Però no tot són bones notícies, pas per la tenda dels mobles i em diuen que el vaixell no ha pogut sortir pel mal temps i que dimecres no arribaran les taules.

El dimecres ho passam com podem. Millor que dilluns, però estrets. Em confirmen però que les taules han sortit i dijous les tindrem.

A les dues del migdia de dijous arriben les taules. Montatge ultra-mega-ràpid de les 8 taules i a les tres ja estaven llestes. Toca anar a comprar un poc de productes de neteja per llevar-lis les ditades i decidim començar a montar la configuració definitiva. No ens guanyarem la vida com a interioristes, però la cosa queda prou digne. Entre moure taules, ordinadors, neteja, cablejat,... fem prop de les set per l'oficina. Volia anar a una trobada a Marratxí que es feia el dijous, però el meu cos ja donava més de sí i no era cosa d'adormir-me a una conferència, així que vaig cap a casa, com se sol dir, "a sopar i a dormir".

Avui divendres ha estat el primer dia que puc considerar normal dins el que ha estat el canvi d'oficina. Finalment ens queda una distribució de dues illetes de 4 taules, taula de reunions i cadires abastament per seure per si hi ha visites. L'oficina té lloc per 11 llocs de feines sense estar estrets, així que encara que ara sols quedi un lloc lliure (no us he comentat que tenim dues incorporacions noves, veritat?) tenim capacitat per créixer si fos necessari, i això em consola, ja que odio fer mudances!

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.

Una de les tasques que hem de fer la gent que ens dedicam a la programació d'aplciacions a mida és la de tenir que dir què costarà fer l'aplicació, és a dir, fer un pressupost, i d'això tractarà aquest apunt, de com entenc jo que ha de ser un pressupost de programari, de les dificultats de fer-ho, del tipus de pressupost que es demanen. Com sempre, esper no avorrir-vos molt.

Què hem de posar a un pressupost?

Això és una de les qüestions més delicades. El més habitual en el nostre sector és que els pressupots no es cobren, per tant hi ha dues visions contraposades: la de dedicar el mínim temps possible a fer el pressupots i la de fer un pressupost amb cara i ulls, de manera que les xifres que es posin allà estiguin justificades amb la feina que s'han de fer.

Particularment sóc partidari de la segona opció. Pensau que la feina final no és el pressupost en sí, sinó el projecte que sortirà d'aquest pressupost. Per això és important que el pressupost defineixi ja l'abast de la feina, els objectius del projecte, el seu abast i les condicions en que es durà la feina.

Per això és necessari tenir força informació del projecte, saber què s'ha de fer en línies generals. Vull dir, no es tracta de saber-ho al detall tot, però sí de ser molt conscient de què és el que cerca el client amb l'aplicació i quines són les feines fonamentals que ha de fer.

En aplicacions web normals això pot ser tan simple com pensar el sitemap de l'aplicació i anar posant-ho damunt el pressupost. "La plana home mostrarà les ofertes principals, amb les imatges dels productes que es motraran de manera aleatòria, ..."

En altres tipus d'aplicacions molt més orientades a la gestió el sitemap de l'aplicació encara no està clar en aquesta etapa i llavors convé fer una mica d'anàlis dels casos d'ús que hi ha implicats.

Una vegada hem redactat el que es farà a mi m'agrada posar també amb quines condicions es farà. És a dir, que el client sàpiga que un projecte web és cosa de les dues parts, que hi ha feines que ha de fer l'empresa de desenvolupament, però que l'èxit del projecte també pot dependre de la seva pròpia implicació i dels tercers involucrats en el projecte.

Després d'això les xifres econòmiques. Jo he estat a les dues bandes, i no m'agradava gent tenir sols una xifra final sense cap tipus de suport lògic. Per això m'agrada sempre indicar el perquè de la xifra i si és possible desglossar-la per tal que el client pugui veure les implicacions de feina de cada concepte.

No es tracta d'anar al detall fi i tancar-ho tot, però sí que s'ha de ser conscient de que per exemple hi ha una feina de sistemes en el projecte, que hi ha feina de gestió, de maquetació, ...

Finalment la part de parrafada de les condicions: fins quan dura el pressupost, quan es dona per començat, com seran els pagaments, com es gestionaran les modificacions, quines garanties hi ha.

Aquesta darrera part és bastant aprofitable entre diferents projectes, però sempre hi ha condicions particulars per a un pressupost concret.

Fet i fent, doncs un pressupost pot dur força feina, entre mig dia per a un projecte senzill, de posem un mes de feina, a varis dies per projectes més complexes.

Cada un ha de tenir el seu límit personal que separa el que és un pressupost i el que és un anàlisi complet. Si la feina de pressupostar requereix d'un anàlisi complet i investigació, crec que és una feina que va més enllà del que és fer el pressupost i que s'han de cobrar com a feina de consultoria.

Jo he vist pressupots d'una plana!

I jo també, i fins i tot hi ha clients que agafen aquests pressuposts, però després tots ja sabem com solen acabar aquestes coses.

Pens que hem de ser molt transparents en la feina que fem i donar sols una xifra sense explicar la feina no és bo ni per al professional ni per al client.

Per al professional perquè pot donar l'impressió que s'està inventant la xifra, perquè no està dient què farà i això a la llarga pot causar molts problemes i perquè si li accepten un pressupost així acabarà amb clients que no valoren la feina feta sinó que simplement van a un preu final sense saber què hi ha al darrera.

Fer pressuposts a alguna gent li pot parèixer que es perdre el temps, però jo no ho veig així. Força al programador i al client a pensar en el que volen, a definir unes regles del joc.

Pensau que no és gens habitual passar de pressupost a contracte, així que normalment el que defineix l'abast de la feina és el pressupost i per tant aquest és el document que fixa la filosofia de feina de l'empresa.

Fer un pressupost i el desenvolupament àgil

L'altra dia vaig fer un twitt dient que havia entregat un pressupots de gairebé 20 planes i un seguidor em deia que això no seria molt àgil. No té res a veure. Un pressupost aixì indica que l'apliació és complexa, que durà mesos de feina, però no és un anàlis "en cascada".

El manifest àgil no diu res de fer pressupots, ens diu que hem de donar prioritat als indivíduu front als processos, al programari front a la documentació, a la col·laboració amb l'usuari davant la negociació de contractes i a respondre als canvis.

I hem de poder fer això donant una xifra al client. El manifest no diu res de "no te diré què costa fins que estigui acabat", sinó que la idea que hi ha al darrera és que sempre es procurarà que el programa que entregui respongui a les teves necessitats, encara que no siguin las mateixes que quan començarem el projecte.

Un pressupost és el punt de partida, el que diu què volem fer i estableix el llenguatge comú del projecte. El que les dues parts pensen que s'ha de fer. La col·laboració amb el client i la resposta a canvis es té quan fas que el pressupost no sigui inamobible, sinó que es puguin anar afegint o llevant funcionalitats segons siguin les necessitats del projecte.

Quan el client coneix les regles del joc, sap que la xifra que li has donat és una estimació, però que els canvis no se li cobraran sempre, sinó que si un canvi implica que una altra funcionalitat no es fa, es probable que les xifres es compensin, i és més, com que té el pressupost on hi ha les tasques i la seva complexitat, pot avaluar per sí mateix l'impacte dels seus canvis en el cost final de l'aplicació.

El pressupost estableix els supòsits de partida, és la validació que s'ha entès la feina que s'ha de fer, però en cap caps significa que una vegada acceptat impliqui que allò és just el que s'ha de fer i que "ja ens veurem quan t'ho acabi". Estam complint un dels principis del manifest àgil, valorant més la col·laboració i la implicació del client que signar el contracte final. i informant-lo al mateix temps de la flexibilitat que té per anar canviant el projecte així com vagi veient la seva evolució.

Posant preu

Si heu anat aquí directament millor tornau enrera :) Als paràgrefs anteriors estava dient que per posar preu hem de conèixer el projecte i establir com col·laborarem amb el client.

Posar preu és complicat. Se'ns demana que adivinem quina feina durà fer un projecte que no hem fet mai, que anticipem problemes, ho valorem en temps i esforç i que al final posem una xifra.

Si no hem definit abans quin és el significat d'aquesta xifra i el client enten que la xifra és el projecte anam malament.

En el proper article mirarem de veure com posam preu, si convé tirar de bolla de vidre o podem fer alguna cosa més a l'hora de definir un preu per al projecte.

Ens llegim aviat!

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.

Aquests dies m'he cansat del bombardeig de notícies relacionades amb Microsoft i el Parc Bit: que si "los mejores programadores se dan cita en el vento Microsoft", que si "Microsoft reune a todos sus centros tecnológicos en el Parc Bit", que si "Microsoft ve en Mallorca al Silicon Valley del Turismo.

Perdonau-me però la interpretació que jo li faig a tot això és una altra. Una vegada més es tracta de sortir a la foto i justificar que es fa alguna cosa, i el poc que es fa s'ha de mostrar i magnificar de manera que no es vegi que darrera tot això no hi ha rés.

Les oficines de Microsoft al Parc no es caracteritzen per donar feina a massa gent, tampoc sap ningú què fan i quina innovació duen a terme. Si anau a la seva plana d'entrada http://www.mictt.com (que fa pocs dies estava totalment caiguda) veureu un conjunt de planes estàtiques que ben bé podria haver fet el típic becari. Això sí, sempre amb el logo del Govern, que s'ha de ser agraït...

Tenc bona voluntat i vull pensar que sí que es fa innovació, que les subvencions mil.ionaries que reberen estan retornant a l'Illa, però perdonau el meu escepticisme, però a la web no veig cap projecte concret, no veig codi alliberat, no veig documentació. No veig gent de Microsoft entrant i sortint de les seves oficines.

Mentre amb aquests actes ja s'han fet la foto, el responsable polític (un bon grapat pel que es veu en la darrera trobada) ja han sortit als diaris i poden dir que som punters en tecnologia turística gràcies a Microsoft. Quina llàstima ...!

Segurament som punters en tecnologia turística, però serà gràcies a les empreses, del Parc i fora del Parc que no reben l'atenció ni del govern ni dels mitjans, que poc a poc han anant posicionat-se en el seu sector, invertint i contractant personal.

Però clar aquestes empreses no són mediàtiques, estan fent feina, generant llocs de feina a les nostres illes, això sí, però no serveixen per fer-se la foto. Vesteix molt més una multinacional, encara que després no sapiguem massa bé què fa o com tindrem el retorn de la inversió o on s'anirà la pasta si efectivament s'arriba a treure un producte. En un país tradicionalment de lletres no podem esperar que el polític de torn pugui distingir entre el que és innovació del que és fum i miralls a la caça una subvenció, i clar, tampoc és cosa de demanar.

I el pitjor de tot és que la situació del Parc no ha canviat des del meu apunt damunt el Parc, potser diria que ha empitjorant, ja que abans no es veien tants cotxes aparcats de mala manera.La resta segueix igual: unes comunicacions pèssimes tant reals com virtuals i un para que a partir de les 18h pareix zona de guerra o un escenari d'una pel·lícula de zombis.

Però com sempre me n'estic anant per les bardisses. El que us volia contar és que finalment hem decidit partir del Parc Bit. Ha estat una decisió dura, hem mirat de quedar-nos pel Parc. Tot i les seves mancances, és un lloc tranquil, i el personal que gestiona el Parc és molt atent i col·laborador, sempre ho he dit i ho repetiré.

Però tot i els temps de crisis no hem pogut accedir a un local a un preu de mercat. Ho hem intentat, però els locals, tot i estar buids des de fa mesos i haver-n'hi un bon grapat per triar i remenar, tenen preus que superen el més d'un 40% les despeses que podem tenir en un local situat dins Palma. Per una empresa que comença o que es vol consolidar com la nostra, s'han de mirar molt bé els costs fixes que tenim cada mes.

Necessitam créixer i el Parc no ens n'ofereix cap oportunitat, així que hem optat per deixar-lo, el més probable és que al desembre ja no siguem per allà, i em sap greu, perquè arribar al matí i trobar-me amb els jardins del Parc és una cosa que m'agrada molt.

Si tot va bé tindrem un local més gran, més ben comunicat, sense tans problemes amb les línies de comunicacions, amb serveis al voltant i amb moltes més possibilitats de créixer sense tenir que arriscar-hi el negoci.

Això sí, com tantes altres empreses que fan feina en el dia a dia, tampoc servim per sortir a la foto i ja ens està bé així. Mentre lluitam amb els problemes diaris i per endur endavant els projectes, ja em perdonareu, però seguiré indignant-me amb totes aquestes informacions plenes de veritats a mitges i que sols serveixen per tapar les vergonyes d'alguns.

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.

Avui, fa poques hores hem posat en producció una nova web per Fiesta Hotel Group anomenada Palladium Weddings és una web pensada per pantalles grans, on s'intenta mostrar el que és el producte de noces que té el client. Si us pensau casar aviat o renovar vots, no deixeu de fer-li una ullada, els escenaris i ambients són una autèntica meravella.

Com és habitual la web està desenvolupada amb Django i pensada per a suportar una càrrega important de visites, i a la vegada fer que el manteniment dels continguts sia el més ràpid possible. Pensau que muntar un paquet de noces, amb tot els extres, fotografies, escenaris, ... no és una tasca trivial. Ens hem de posar amb la pell no tan sols del client potencial que visita la web, sinó de la gent que l'ha de mantenir, i per tant l'aplicació s'ha de cuidar tant en l'aspecte visible com en el que es veu menys, però que també té una part fonamental en l'èxit de la web. Si aconseguim fer una web fàcil de mantenir és més senzill que els continguts es mantenguin actualitzats i que la web estigui més viva.

Però a part d'aquestes consideracions, per mi aquesta web ha resultat ser un exemple perfecte de perquè s'han de desenvolupar les aplicacions d'una determinada manera, en el nostre cas seguint el model MVT de Django, molt semblant al model MVC.

Aquesta web va començar a gestar-se al final de l'any passat. Partíem d'una web en PHP que s'havia de migrar i millorar. El projecte estava ja pràcticament acabat quan Fiesta va decidir fer-hi una repensada i mentre anar prioritzant altres projectes.

La repensada finalment va donar com a fruit un redisseny complet de la web, amb més continguts, més fotografies i detalls, però amb una funcionalitat que era al 80 o 90% semblant a l'anterior.

Les aplicacions que desenvolupam tenen un component de backoffice, un CMS si voleu, on es posen les dades i continguts i es manté el model de dades a partir del models d'aplicacions que hem definit a Django.

Les urls es mapegen amb vistes, que no són més que codi Python que obté la informació dels models, la manipula i la retorna per a que es pugui muntar la plana web mitjançant una plantilla, que per construcció no té regles de negoci incorporades.

És a dir, tenim una clara separació entre com es gestionen els continguts al CMS, i com es presenten, entre la URL i l'HTML final que veurà l'usuari al seu navegador.

Per a aquest projecte això ha significat un estalvi directe de temps i diners. Hem pogut reaprofitar-ho gairebé tot el que no era la capa de presentació, i no tan sols això, sinó que s'ha pogut avançar en paral·lel entre la programació i la gestió dels continguts.

El model MVC ho implementen molts bastiments Java, PHP, Ruby. Però el que per mi és important és que Django ho fa realment fàcil. La manera natural de fer aplicacions amb Django és la de fer aplicacions fàcils de mantenir, on el nivell de cerimònia que s'ha de fer per reutilitzar components o crear-ne de nous es mínim. He tingut l'ocasió de treballar amb Struts, Spring per Java o Symfony amb PHP i són un malson comparats amb la facilitat de Django.

Per mi aquest projecte demostra que la inversió en fer les coses com toca compensa. Segur que un projecte típic de PHP on hi ha codi, accés a la base de dades i codi mesclat pot aconseguir el mateix que el que hem fet. El que no hauria pogut aconseguir mai és aquest nivell de reutilització. Separar en capes compensa, utilitzar Django i Python en les aplicacions web també.

Pels qui us atracau a aquest blog des d'altres tecnologies i estau pensant amb Django per al proper projecte, esper que aquesta història us pugui servir d'inspiració. Pensau que els començaments són sempre durs, però que el camí es prou suau. Pensau que allà on inicialment us pensau que el desenvolupament és més lent, adonau-vos de com n'està de protegida la inversió que fa el vostre client en tecnologia i en com es poden anar canviant parts de la web i evolucionant-la sense morir a l'intent.

Posar PHP dins el codi HTML sols duu al costat fosc, perquè fosques seran les nits que us passareu depurant l'aplicació.

En la situació de crisi que vivim, de tant en tant veus piulades o discussions per fòrums com meneame.net on es tracta a les empreses i als empresaris d'explotadors i esclavistes. Es posa tothom al mateix sac, de la mateixa manera que es fa amb els polítics i amb els funcionaris. Repetir aquestes consignes per mi vol dir potenciar el pensament únic vers el pensament crític, com una manera més de manipular a la massa i això no és bo.

Segur que hi ha empreses que tracten als empleats com a animals, ja sabem que hi ha polítics corruptes i funcionaris que no en fan ni brot. Però afortunadament són l'excepció i no la regla. No podem entrar en generalitzacions que no fan més que beneficiar als manipuladors.

Hi ha molta gent com jo mateix que s'ha fet empresari (o emprenedor si us agrada més) perquè pensa que pot aportar alguna cosa a la societat i al mateix temps fer el que li agrada. Gent que volem guanyar-nos la vida amb el que més ens agrada i que lluitam dia a dia per a mantenir l'il·lusió amb el que fem i mantenir viva l'empresa.

Es clar, no ets una megacoporació, les megacorporacions són dolentes, direu. Doncs no, però una altra vegada més estam davant d'una generalització. Les magacorporacions no són inherentment bones ni dolentes, dependrà del que vulguin que siguin els seus directius i la gent que hi fa feina. He fet feina per empreses molt grans i les meves diferències d'opinió han estat sempre amb alguns directius, però no perquè la empresa fos dolenta o l'objectiu social no aportàs res a la societat. L'empresa té uns objectius per fer negoci, però són les persones les que al final decideixen complir aquests objectius d'una manera ètica i socialment sostenible o no.

Fa uns anys es va posar de moda la "responsabilitat social corporativa", com a una manera d'atracar l'empresa a la societat. Potser no fa falta donar-li un nom tan abstracte. Per mi aquest concepte es tradueix en que en la relació entre empresa i societat hi hem de guanyar tots. L'empresa a de poder guanyar-se la vida, pagar empleats i socis i ho ha de fer de manera que tot això millori la vida d'empleats i de la societat on duu a terme la seva activitat.

Criminalitzar l'empresari, l'empresa, els funcionaris o als polítics no ens atraca al final de la crisi, sols ens hi enquista. Una situació que sols beneficia, paradoxalment, a aquells que han provocat aquesta crisi. Mentre la societat està dividida no anirà a cercar els culpables reals de la situació.

En una de les darreres aplicacions que hem fet, la d'apibaleares hem tirat força de l'administrador de Django. Segurament i donades les característiques que volem que tengui l'apliació al final, anirem cap a un administrador ad-hoc, però ara per començar va força bé.

Un dels primers problemes va sorgir amb els filtres. Amb l'admin de Django és molt senzill fer un filtre per qualsevol camp, però té l'emperò que si el camp és una clau forana cap a una altra taula amb molts elements Django et pinta tots els elements, amb la qual cosa la plana creix molt i el llista es fa mal de manejar.

Amb Django 1.4 tenim l'opció de crear-nos els nostres propis filtres i dir-li a l'admin que els faci servir. Per posar-vos en situació el que voldríem és que enlloc del filtre com a llista per la clau forana, poguéssim seleccionar l'element a filtrar des d'un desplegable. És veritat que perdem la selecció múltiple, però a l'usuari no li fa res, el que no vol és tota la llista al costat dret del llistat.

Així doncs, el primer que farem serà veure què hi ha respecte als filtres. La documentació de Django es minsa, potser perquè ja avisen que això pot canviar en un futur proper. Ens arriscarem per ara!

El filtre que ens interessa el derivarem de RelatedFieldListFilter que és qui se n'encarrega de pintar les claus foranes. Val a dir que no necessitam massa cosa, volem pintar d'una manera diferent els elements, així que únicament hem de sobreescriure la part que se n'encarrega de la visualització:

Dins l'admin.py del nostre projecte, per exemple, fem

from django.contrib.admin import RelatedFieldListFilter
class SelectFilter(RelatedFieldListFilter):
    template ='filter/select.html'

i ara li hem de dir a Django que el faci servir, per això basta fer que el list_filter agafi aquest classe. Per exemple, suposem que la clau forana es diu localitat i que filtram per altres elements com tipus, actiu. Inicialment tindríem:

list_filter = ('actiu', 'tipus', 'localitat')

llavors el que farem serà:

list_filter = ('actiu, 'tipus', 
                ('localitat', SelectFilter)
              )

és a dir, ara podem dir a Django a més del nom del cap a filtrar, la classe que farem servir per presentar el filtrat.

La nostra classe és molt simple, així que la única cosa que hem de fer és pintar la plantilla.

La plantilla base la podeu trobar al codi font de Django mateix, amb el nom de select.html. La modificarem per a que pinti un desplegable:

{% load i18n %}
<h3>{% blocktrans with filter_title=title %} By {{ filter_title }} {% endblocktrans %}</h3>
<select id="s_localidad" style="width:150px;margin-left:5px;">
{% for choice in choices %}
<option {% if choice.selected %} selected="selected" class="selected"{% endif %} 
  value="{{ choice.query_string|iriencode }}">{{ choice.display }}</option>
{% endfor %}
</select>

Nota: el codi ara per ara no és genèric, és la primera aproximació que vaig fer per sortir del pas :)

La idea però és veure com fa Django els filtres. De fet el que està fent és mantenir tota la consulta als paràmetres, així que el que es feia amb la llista ho podem aprofitar també, mostrant el contingut i al value mantenir el link del filtrat.

Això però no acaba de funcionar, ja que ara no tenim un link i necessitam dir-li a Django que apliqui el nou filtre. Com que l'admin de Django duu jQuery per la part de javascript, doncs el podem aprofitar i afegir codi per a que quan canvii l'element cridi a la url amb el nou filtrat:

<script type="text/javascript">
  (function($) {
        $(document).ready(function($) {
          $("#s_localidad").change(function(){
            var ref = $(this, 'option:selected').val();
            window.location.href = ref;
            });
          })
         })(django.jQuery);
</script>

i ja ho tenim! Ara sols queda fer una cosa més genèrica i reaprofitable, però a mi al manco ja m'ha servit per veure que això dels filtres té molt bona pinta.

El dimecres passat vàrem posar en producció la nova web de portal immobiliari del Col·legi Oficial d'Agents de la propietat immobiliària de les Illes Baleares, que es mostra baix el domini http://www.apibaleares.com. Com és habitual és una aplicació feta amb Django, i amb la idea de que sigui una aplicació escalable i sobretot mantenible.

El sector immobiliari no passa pel seu millor moment, tot val a dir-ho, però és un projecte que m'ha fet especial il·lusió. Per una part significa tractar amb molta gent que fa servir el programa, cada un amb les seves pròpies sensibilitats, i en un sector on la tecnologia informàtica s'obre pas molt a poc a poc.

És un dels primers projectes que fem amb Django 1.4, així que aprofitaré per fer cinc cèntims del que ha representat. Django 1.4 canvia un poc l'estructura dels projectes per a fer-los més modulars. Per la nostra banda hem aprofitat per també seguir amb el camí iniciat amb PropietariosOnline i SpokenPic i desenvolupar tota l'estructura de vistes mitjançant les class bassed views.

Tot i que hi ha gent a favor i en contra, he de dir que ara per ara, i pels tipus de projectes que fem les CBV són una benedicció. Podem estructura la informació molt millor i fer herència quan convé. En una web com http://www.apibaleares.com on hi ha un cercador adaptat per a cada API i on a més havíem de mantenir la compatibilitat cap enrera, l'herència ha representat poder reaprofitar molt de codi, i sobretot poder tractar amb les complexitats de fer enginyeria inversa de les cerques i continguts d'una manera molt més simple.

La recuperació de les claus d'usuari va representar un problema interessant. Per una part no volíem tenir que donar una clau generada per nosaltres a cada API, i per altra banda volíem que la recuperació de les claus fos el menys intrussiva possible. És a dir, que si algú volgués resetejar la clau ho pogués fer, però si un tercer intenta canviar la clau no ho pogués fer, ja que l'usuari rebrà un e-mail i la clau no es canviarà fins que es faci servir el link que s'envia.

Això ja es podia fer amb django-registration, i val a dir, que encara que està poc documentat, també es pot fer amb les darreres versions de Django. De fet basta un:

<a href="{% url django.contrib.auth.views.password_reset %}">Forgot your password?</a>

i si voleu, personalitzar o sobreescriure les plantilles dins registration (podeu copiar-les del codi font de Django i treballar a partir d'aquí):

login.html                    password_reset_done.html
password_reset_complete.html  password_reset_email.html
password_reset_confirm.html   password_reset_form.html

és el mètode que vaig seguir per afegir aquesta funcionalitat a PropietariosOnline. En el cas d'apibaleares, però, vaig preferir fer servir un altre tipus de recuperació, funcionalment idèntica, però que ja fa servir les noves característiques de criptografia de Django. Això em va dur a github i al code de https://github.com/brutasse/django-password-reset. Va ser un procés en paral·lem amb les necessitats d'SpokenPic.

Inicialment django-password-reset tenia una mancança (al meu entendre), que no feia un redirect després de fer un POST amb el canvi de clau. Vaig fer un primer fork i enviar el pegat a Brutasse. Val a dir que era el meu primer fork a github, que jo sóc més de mercurial i per tant de bitbucket. Tot i això després d'alguns intents vaig poder deixar un codi prou decent per a que Brutasse acceptàs el pegat i a més i fes millores addicionals. I vaig aprendre molt pel camí del codi de Brutasse, de com organitzava els unit-tests i del nou mòdul de criptografia de Django 1.4.

És per mi una de les meravelles del codi lliure. Una utilitat que a l'autor "ja li anava bé", la troba algú altra, li fa una millora, l'autor la considera i torna a repensar part del codi. Quan surt la nova versió el que passa és que tots tenim un codi millor que el que hi havia abans. Tothom hi guanya!

No sé si ho heu notat, però m'ho pas molt bé amb la meva feina. Tot i ser de tipus "passador de pena", escriure codi, gestionar projectes i aprendre coses noves m'encanta. En la nostra feina mai ho arribes a saber tot, sempre pots aprendre de com fa les coses un altre. Per mi un dels secrets de passar-ho bé és intentar millorar un poc a cada projecte. Aprofitar la benentesa per anar un pas més enllà, passeta a passeta, sense posar en risc el projecte cercant la bala de planta, però aprenent coses noves a cada passa.

Peewee és d'aquestes eines que fas servir de tant en tant però que quan les necessites t'alegres de tenir-les al calaix.

Pewee és un ORM (un object relelational mapper) és a dir, una llibreria capaç de transformar tuples de bases de dades en objectes, en aquest cas en objectes Python.

La llibreria està força ben documentada i la instal·lació és trivial amb pip. ORM però, n'hi ha uns quants al món de Python, què em duu a destacar Peewee doncs?

El primer de tot que he de dir és que com tot no és una eina per fer-la servir quan no toca, com a ORM té les seves limitacions, no és tan complet com l'SQLAlchemy per exemple. Pewee però és fantàstic quan has de fer feines d'importació/exportació de dades.

Proporciona una capa molt fina d'ORM que pot connectar amb sqlite, mysql o postresql i té un mòdul d'instrospecció senzill per a permetre connectar-nos a una base de dades ja existent i generar els models que ens serviran per interactuar amb la base de dades.

Tant el model com la sintaxi de l'ORM recorden molt, de fet estan inspirats amb l'ORM de Django, per tant, si ja coneixeu Django, amb Peewee us sentireu com a casa.

No té cap dependència d'un bastiment, per tant pot utilitzar-se per fer scripts, i importacions de dades.

La documentació és simple, suficient, amb exemple i es pot llegir en pocs minuts. Si la comparam amb la d'SQLAlchemy en podrem veure la gran diferència. Peewee té una documentació per a començar a fer feina ràpid, SQLAlchemy la té per a convetir-se en l'ORM de la teva aplicació i que en puguis treure tot el suc a la base de dades.

Però no tot són floretes, fent una importació de dades de Mysql cap a Postgres em vaig trobar amb força problemes a l'hora de tractar relacions m2m on la clau primària era composta. L'ORM no funciona bé amb claus compostes i s'ha de fer feina addicional per a tractar-lo.

I per què volem un ORM us demanareu?

Bé, si us heu fet aquesta pregunta vol dir que no heu llegit el meu apunt Fer servir un ORM o no o que no li heu fet gaire cas :)

Python té el DB-API per fer consultes de base de dades, de la mateixa manera que Java té el JDBC. Però mantenir codi on les referències es fan per columnes i on hi ha una mescladissa d'objectes i codi sql no és una bona idea.

Jo vaig trobar Peewee cercant un orm senzill per a fer una importació de dades des d'un programa fet en PHP i Mysql a una aplicació desenvolupada amb Django y Postgresql.

Aquesta importació implicava obtenir les dades, manipular-les per a que encaixassin en el nou model i guardar-les a la base de dades. Peewee em va permetre fer això mantenint la llegibilitat del codi d'importació. D'aquesta manera és molt més senzill veure què està passant, què estàs fent malament. És molt més senzill treballar amb el camp User.username que fer referència a row[2].

Així doncs, si us trobau amb una situació semblant i necessitau quelcom senzill, bo d'aprendre i que faci la feina Peewee pot ser una bona elecció.

Doncs sí, han estat un bon grapat de dies dedicant-hi moltes hores, sobretot a casa i a hores mortes, però finalment avui, o millor dit ahir als voltants de les 19:30 apareixia la versió d'Spokenpic al Google Play.

Ara hem de veure quina acollida té dins un públic més ample que els beta-testers que han estat provant l'aplicació, als que aprofit per donar una vegada més les gràcies.

Ara comença també un procés de millora, de la web, de noves característiques, ... Però abans de res gaudir uns dies de la feina feta i veure les primeres impressions de la gent.

Al final amb una aplicació així són els propis usuaris els que diuen si els interessa o no.

L'aplicació estava enllestida per fer les cridades asíncrones a Twitter i Facebook, però suposàvem que en el llançament no faria falta. Doncs mira per on quin dia ha elegit Twitter per caure. Afectava negativament al rendiment de l'aplicació.

Després de tot ha anat bé perquè hem detectat i corregit un error a l'aplicació i també ha servit per a comprovar que la API encara que més lenta, no cau per una caiguda de Twitter.

Demà de totes maneres ja hi haurà posat el Celery amb Redis i així aquest temes estaran molt més controlats i la caiguda de Twitter o Facebook no tindrà efecte en la velocitat de l'aplicació.

També ens queda anar vigilant el Sentry, el sistema de monitorització d'errors que utilitzam, per a controlar les petades no previstes i resoldre els problemes que segur que aniran sortint.

I és que les petades no previstes no ha de passar desapercebudes, això de posar un try/except i caçar-ho tot és molt mala pràctica, és millor tenir un sistema com Sentry que ens informi de tot el que no hem previst.

El primer que hem detectat ha estat un nom de plantilla mal posat. Un typo, que hem pogut resoldre en pocs minuts. Insisteixo, si no feis servir fabric per als desplegaments estau malbaratant el vostre temps. S'ho paga anar creant les funcionalitats per a poder desplegar aplicacions ràpidament.

A veure si puc treure temps per parlar per aquí del Tastypie, dels problemes que m'he trobat fent l'API de l'Spokenpic, i els avantatges i mancances d'aquest bastiment Rest per Django.

Avui també he fer servir una eina, per un altre projecte, de la qual també tenc moltes ganes de parlar, ja que m'ha sorprès per la seva utilitat a l'hora de resoldre un problema com és el de la migració de dades, és un ORM molt lleuger anomenat Peewee.

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!

Pels aquelles que encara no el coneixeu, permeteu-me que us presenti south una eina per a controlar els canvis que es van fent al model i poder-los aplicar a la nostra base de dades.

South és una eina fantàstica, però no substitueix ni la necessitat de fer còpies de seguretat abans de fer algun canvi que pugui significar la destrucció o alteració de dades, ni la necessària coordinació entre els diferents membres de l'equip de desenvolupament.

Al tutorial des south està molt bén explicat tot, així que aquest apunt miraré de posar les receptes que he trobat més interessants, bàsicament per a no oblidar-me'n.

Canvi de nom d'un camp

South intentarà esborrar el camp i crear-ne un de nou. No sap que el que volíeu era un canvi de nom així que:

1. Fem la migració de la manera habitual python manage.py schemamigration app --auto

2. South generarà una nova migració. Amb el vostre editor preferit, editau-la i eleminau les referències a l'eliminació i creació del camp. En el seu lloc, utilitzau directament l'API de South, per escriure

   db.rename_column(table_name, column_name, new_column_name)

amb les columnes en sentit contrari per desfer la migració, obviament...

Hem modificat un camp a la BD directament

Les primeres vegades que es fa servir South costa que tot l'equip s'hi acostumi. Si la gent estava acostuamada a passar scripts sql, potser els ha passat i no ha fet ús de la migració.

South detectarà que la migració no està passada i intentarà passar-la, però com que els canvis ja hi són (la taula que es vol crear ja existeix, o el camp, ...), South donarà un error i intentarà tirar la migració enrera. En el cas de Postgres no hi haurà problemes, però amb bases de dades com el MySQL que no suporten la transaccionalitat d'esquemes donarà error.

No passa res si detectau que és això el que ha passat. Però hem de dir-li a South que consideri que la migració ja està feta. Per axixò farem:

python manage.py migrate app --fake

suposant que és la darrera migracío, o bé especificant quina migració s'ha de considerar aplicacada.

python mangae.py migrate app num_migració --fake

Ja tenim la base de dades i volem començar a fer feina amb South

Per a convertir una aplicació de la qual ja teniu la base de dades creada hem de fer

 python manage.py convert_to_south app

això posarà l'aplicació sota el control de south, crearà la migració inicial i la marcarà com a aplicada.

Aquestes darreres setmanes, mesos fins i tot, han estat força intenses. Amb projectes que han duit moltes hores i que al final han sortit.

Rasec de Guillermo i companyia va representar posar en marxa una aplicació que va duu més de tres mesos de feina, però amb uns resultats inicials més que encoratjadors.

Pel nostre client de referència en el món turístic Fiesta Hotel Group hem posat en marxa tres noves webs en poc temps:

• http://www.ushuaiabeachhotel.com/. Unes fotografies realment precioses que fan ganes d'anar-hi.

• Sa Talaia Boutique Villa. En la mateixa línia que l'anterior i amb la idea de donar aquesta sensació de proximitat i unió entre els dos conceptes d'hotel.

• Hotel Mallorca Rocks Com concepte d'hotel-concert, que tans bona acollida ha tingut dins Palma com a alternativa al sol i platja tradicional.

Tot això amb Python i Django com podreu suposar. Pel tipus de feina en que ens anam especialitzant cada projecte és un poc diferent. Al nostre voltant hi ha empreses que se dediquen a "fer planes web" que duen molts anys i quan veus el que han fet te n'adones que han anat repetint el mateix patró, el mateix disseny una i una altra vegada. És una altra manera de fer feina, a mi el que m'agrada és la varietat, que cada projecte representi quelcom nou.

I com que després de fer tanta feina ens fa ganes divertir-nos, surten idees com l'ensaimeitor una aplicació que parteix d'una llibreria que vaig fer per us intern i que mig en broma mig seriosament hem posat a la web per si serveix a algú més. Es tracta de generar informació per omplir i testejar aplicacions web.

I com no, també he de parlar d'un altra projecte que ens fa il·lusió per la novetat que representa per nosaltres i per la gent que hi ha implicada. És el projecte Spokenpic que fem com a "joint-venture" amb la gent de Menéame. Està resultant un projecte força divertit, que fem gairebé al 100% com a projecte fora d'hores habituals. I el que més en @gallir, que té uns horaris de feina molt desbaratats, programant a les 3 i a les 4 de la matinada.

Fa poc Spokenpic va fer-se públic. El "secret" ja no se podia mantenir per més temps, així que ara anam fent canvis i millores. Trob que per la gent que programau i llegiu aquest blog segurament també us serà interessant seguir-ne l'evolució del projecte, com a poc a poc es van afegint funcionalitats a partir de l'estructura bàsica.

Com a aventura que és Spokenpic no sabem on arribarà, però el que és ben cert és que ens ho estam passant d'allò més bé amb el projecte. Fer feina amb gent que es tant o més friki que nosaltres ens diverteix molt. El projecte és un repte molt interessant, ja que comporta la coordinació de dos equips de programació, amb dos llenguatges de programació diferents. On tothom tenim altres feines i la coordinació és fa al 90% amb mails i el gestor de projectes. Amb els horaris de Ricardo és com si féssim feina a franges horàries separades! :)

Encara hi ha moltes coses que resoldre, moltes característiques que ens agradaria posar-ho, però ara per ara el més important és veure què opinen els nostres primers pre-alfa-testers. A poc a poc anirem ampliant els cercles de testejadors. Trobam que pot ser una eina molt interessant per certs sectors de gent i certes ocasions, però qui ha de validar si la idea és bona o no, la idea és mostrar el que hi ha fet i validar la idea, si funciona fantàstic, si no té bona acollida, doncs mira, ens haurem divertit molt de totes maneres. En Ricardo ho conta molt bé a spokenpic fotos relatadas.

I això és tot, projectes i més projectes. Estam entretinguts darrerament i això és el que més m'agrada.

L'altra dia un amic em va dir que li resultava complicat anar navegant pel conjunt d'articles de les Class Based Views de Django, així que el que he pensat és fer una mena d'índex amb aquest apunt i posar-ho a la portada.

1. Django class based views (I)
2. Django class based views (II)
3. Django class based views (III)
   
4. Django class based views (IV)
5. Django class based views (V) - CRUD
6. Django class based views (VI) - Lists
7. Epíleg: Filtres i ordenacions

L'altra dia vaig acabar de llegir "El Lector" de Bernhard Schlink, en l'edició que ha fet l'editorial Empúries i la traducció de Carme Gala.

És un d'aquests llibres que comana la meva parella i que per una raó o l'altra acaba a les meves mans. Sols ser perquè m'he quedat sense lectura o me fa ganes veure què tal.

El llibre són 170 planes de lletra menuda, o millor dit, normal. És un llibre on el personatge ens descriu la seva història, fent bots al present i al passant i reflexionant damunt el que li passa.

M'ha agradat molt la història, tot i ser dura. El temps de la narració està molt ben aconseguit, et pots capficar ràpidament amb la història, però així com van avançant les planes s'esvaeix la impressió inicial de que seria una novel·la negra. Més aviat, així com avança la lectura et vas endinsant dins el món de les paraules de l'autor, dins les descripcions, sense esperar res més que la següent línia, sense sorpreses sobtades, però amb una gran bellesa narrativa.

En definitiva, m'ha agradat força i el recomano.

Fa gairebé 4 anys que tenim l'empresa APSL al Parc Bit, primer en règim d'incubació a l'Edificit Naorte i actualment som al l'edifici NTIC en una oficina compartida amb una altra empresa.

Sovint venen altres empreses i emprenedors que ens demanen si és bo estar al Parc Bit per a una empresa que comença, si es fan relacions comercials, si fa fon fer feina, aquest apunt intentarà contestar a tot això des de l'experiència d'aquests anys.

La situació

El Parc Bit és al cul del món, tant per les coses bones com per les dolentes. Quan hi arribes, per la carretera que duu a la UIB i vols anar als edificis d'oficines el primer que has de fer és deixar el cotxe al parking i travessar un petit torrent. Els jardins estan molt ben arreglats i la primavera i la tardor, i a l'hivern quan el torrent duu aigua és una meravella.

Com veis ens trobam en que és un lloc fantàstic per anar a fer feina però que està molt mal comunicat i obliga a la gent a accedir-hi en cotxe si o sí. Els parkings comencen a estar plens i això és un problema a l'hora de que et venguin a veure clients, ja que la passejada que poden arribar a fer per anar a una oficina qualsevol pot ser de 15 minuts.

Resumint, una vegada has arribat i has pogut aparcar la passejada fins al lloc de feina a mi em resulta relaxant, i també la sortida, ja que te permet comentar la jugada amb els companys. Però si teniu previst que a la vostra empresa us visitin clients, el Parc no és el lloc més adient, a no ser que vinguin i s'entornin en Taxi.

En aquest aspecte nosaltres començam a tenir queixes dels clients que venen a veure'ns de tant en tant i que tenen força dificultats per aparcar.

El cost

No ens enganem, el Parc és car, com ho eren (o potser encara ho són els Polígons de les nostres Illes). El m² d'oficina està als voltants dels 10 o 11 € i a això li haureu de sumar el cost de la comunitat de l'edifici i també la part proporcional del manteniment de les instal·lacions del Parc. Es poden trobar oficines per molt menys preu dins Ciutat o als pobles. Tot depèn del volum de la vostra empresa i de les vostres necessitats. El problema del Parc és que et cobren normalment per m² i hi ha poques oficines petites, així que et pots trobar en que estàs a una oficina de 80 m² pagant entre 800 i 1200 €/mes sense comptar neteja i subministraments.

Com en el nostre cas hi ha l'opció d'agafar una oficina gran i compartir-la entre dues empreses, però això sovint no és fàcil.

També s'ha de valorar que quan has de créixer la disponibilitat d'espai que tens és limitada. Vull dir, quan obris el ventall de cerca a Ciutat, als pobles i barriades, les possibilitats de trobar un espai de les dimensions que cerques són molt majors que les que tens al Parc.

Les comunicacions de dades

Quan hom pensa en un Parc Tecnològic pensa en que les comunicacions han d'estar omnipresents: fibra òptica per tot, satel·ltis, datacenters, ... Deixau de somiar! Aconseguir una línia telefònica ADSL a nosaltres ens va costar 3 mesos i no som un cas aïllat. La velocitat màxima de l'ADSL és de 10 Mbits/s quan hi ha sort i ONO no té massa interès en posar fibra a tots els edificis. Ara mateix nosaltres tenim una connexió de 4Mb/1Mb rellogada a la gent d'SMI ja que ens interessava molt tenir bona velocitat de pujada, i és el millor que hem aconseguit (a un cost raonable, clar).

Les instal·lacions del Parc

El parc posa a disposició de les empreses diverses sales de conferències, ben equipades llevat de les connexions a Internet. El personal del Parc és molt atent i fan molt bona feina i t'ajuden en el que necessites. És del tipus de gent que m'agrada, que intenta donar-te solucions enlloc de problemes.

Hem fet servir les instal·lacions del Parc al Creant Bits i anat allà a cursos i conferències i n'estam força contents.

El Parc també té zones comunitàries on poder menjar, amb microones per encalentir la carmanyola. Estan netes i ben cuidades. Molt bé també.

Serveis de tercers

No en cerqueu massa que no en trobareu. Una oficina bancària, 3 ó 4 caixers automàtics, 3 bars/restaurants i una gestoria. Poca cosa més. Els bars tanquen a les 18 h, així que heu de tenir previst que si un client ve tard o la reunió s'allarga, no anireu a fer un cafè al capvespre.

Donat que no hi ha gaire competència els preus estan com a qualsevol altra banda, llevat que tens menys on triar.

Trobar material d'oficina o una tenda dins el Parc directament descartat.

De tant en tant hi ha intents de posar-hi negocis, supòs que atrets pel que se suposa que és una gran quantitat de gent que hi ha al Parc, però la majoria van tancant.

Xarxa social

Una de les coses que "et venen" quan es xerra del Parc Bit és la possibilitat d'establir col·laboracions socials entre empreses del Parc. Quan he parlat amb altra gent he vist que aquesta impressió no és sols meva, sinó que la gent amb la qui he parlat també em demanava si aquest aspecte hi és.

Me dóna la sensació que la impressió que és té des de fora és que les empreses del Parc estan desitjoses de col·laborar entre sí, que tenen les portes obertes als emprenedors i que la vida social i les relacions empresarials són el pa nostre de cada dia. Res més lluny de la realitat.

El Parc s'assembla molt a qualsevol altre polígon en aquest aspecte. Les empreses estan per feina i llevat de a l'hora del cafè i del dinar allò és una zona desèrtica. A l'hora del cafè o del dinar tampoc espereu que es us atraqui ningú a presentar-se i a demanar-vos si voleu col·laborar amb un o altre projecte.

El que sí és cert és que si fa temps que estàs fent feina en el sector de la informàtica o el turisme, hi ha moltes possibilitats que trobis molts coneguts i saludats quan entres o surts de l'oficina o potser fent un cafè.

Per la resta no us imagineu el lloc com una starup de pel·lícula on la gent pot anar a berernar quan vol o estira les cames. Les empreses que tenen el volum més gran de gent són empreses de tall tradicional i personal de l'Administració pública, amb horaris d'entrada i de sortida.

Ambient de feina

Pots tenir la mala sort que et toqui vora un edifici en construcció i llavors tindràs renou, però si no és així el Parc és un lloc silenciós, net, on es poden sentir els ocells i no es sent el remor de cotxes passant, ambulàncies i pitades de cotxes. Personalment és aquesta, junt amb la passejada matinal i les zones enjardinades, una de les coses més aprecio del Parc.

La incubadora d'empreses

El Parc té una incubadora d'empreses que, una vegada aprovat el projecte, et subvenciona part del cost de l'oficina, i recentment han posat en marxa un espai de treball compartit per gent que sols necessita una taula.

És un servei que a nosaltres ens va anar molt bé i que ajuda a vèncer la por a muntar una empresa innovadora. El servei d'Incubació quan nosaltres hi érem era molt proactiu organitzant cursos i fent seguiment de les empreses

Convé muntar una empresa al Parc Bit?

No puc respondre a aquesta pregunta. Heu de valorar el que us estic contant, veure el tipus d'empresa que voleu iniciar i després valorar-ho per vosaltres mateixos.

El Parc té coses bones i coses dolentes i és cada un que les ha de valorar.

En aquest article he intentant contar-vos el que jo veig basant-me amb la meva experiència personal.

Us he de dir que ara per ara estic, en general, força content, però si el tema del parking es segueix complicant (ara mateix hi ha 3 edificacions a mig fer força grans) o ens veiem amb la necessitat d'ampliar l'empresa, llavors no quedarà més remei que considerar també altres alternatives i valorar-les com us estic dient que hauríeu de fer si estau considerant el Parc per a muntar el vostre proper negoci.

Avui estic com un toro: m'han clavat dues banderilles clavades per mor d'una ciàtica que fa que no pugui asseure'm a l'ordinador més de mitja hora sense que el dolor em faci aixecar de la cadira.

Llegir és més senzill, ja que em permet anar variant la postura, o llegir de dret, així que he aprofitat per acabar de llegir el segon llibre que vaig dur de Barcelona.

Aquest segon volum, molt més curt que el primer, es centra un poc en la vida personal de Feynman i sobretot en la investigació que va fer de l'accident del Challenger. És una lectura interessant per veure com es mouen els fils de la política i com és per dintre un projecte tan complex com el del transbordador, com es feia feina amb ordinadors obsolets per no tenir que passar novament per costossíssimes proves de validació. Molt interessant.

M'ha agradat molt un paràgref: "Para que una tecnología tenga éxtio, es preciso que la realidad tenga precedencia sobre las relaciones públicas, pues a la Naturaleza no se la puede engañar."

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.

La setmana passada vaig estar de mini-vacances amb la família per Barcelona. Passejar i desconnectar un poc. Crec que qui s'ho va passar millor va ser el meu fill petit: això del buffet lliure l'apassiona, fins i tot es va fer amic de la cambrera, que va veure un menut espavilat anant amunt i avall, fent-se les torrades, abocant-se el sucs, ... Ho volia fer tot ell! No vull pensar en el que passarà si algun dia anam a un hotel del tipus tot inclòs :D

Una de les visites que vàrem fer va ser al Cosmocaixa. L'antic museu de la ciència. Feia molts anys que no hi havia anat i volia que els nins poguessin tocar els experiments. Recordava la part física més gran, encara que potser és que jo també era més petit.

De sortida pas obligat per la tenda i una ullada a la llibreria. Em vaig tenir que contenir, un munt de llibres de temàtica científica a l'abast. Em va saber greu tenir que triar, n'hagués arreplegat un bon munt, així que vaig anar cap a dos llibres que feia temps que volia comprar "¿Está usted de broma sr. Feynman?" i la continuacíó "¿Qué te importa lo que piensen los demás?", ambdós d'Alianza Editorial.

Ahir vaig acabar el primer, que dóna títol a aquest apunt. Són 406 planes d'anècdotes, alguna conferència i sobretot vivències de un dels físics més brillants del segle XX.

Encara que ja coneixia alguna de les històries del llibre puc dir que l'he devorat. Algunes vegades la naració és un tant dispersa, però també ho és el personatge. Un científic ple de curiositat per la vida i pel que l'envolta. Un amant de la vida, del pensament, de la ciència amb vocació real per l'ensenyança i per deixar el mon millor que l'ha trobat.

Si el tengués que definir en poques paraules ho faria amb "motivador". És meravellós veure la integritat personal de Feynman, com manté les seves idees i conviccions, vivint la vida i exposant les contradiccions de la societat que li va tocar viure. Contradiccions que podeu estar ben segurs són encara presents en la nostra societat.

Un llibre recomanable, que m'ha fet ganes de tornar a enganxar amb la Física, que demostra que efectivament es poden fer les coses d'una altra manera i ensurtir-te'n.

Avui mateix començaré l'altra!

He actualitzat la configuració que faig servir per a fer feina amb Vim per programar amb Python i Django a partir de l'article de sontek, llevant coses que no faig servir o que m'agrada més tenir en una consola: py.test, git, etc. i afegint algunes definicions que m'han anat molt bé a llarg dels anys. Ho podeu trobar a http://code.google.com/p/trespams-vim/

La millora més important és la descoberta de Pathogen, que ens permet gestionar millor els plugins i del plugin gundu que ens permet veure els canvis a un fitxer, com si fos un control de versions local.

Manteng cla configuració de backup i com que tinc força memòria als ordinadors que faig servir tenc llevat també el swapfile.

Aquest punt em servirà com a recordatori de combinacions de tecles útils a més de les habituals de vim.

• Tecla leader. Surt per tot a vim. Mapejada a coma (,)
• Tancar la finestra quickfix ,cc
• Anar a una finestra: ctrl+jklh
• Veure els registres: ,r
• Copiar a un registre texte seleccinat: "y
• Aferrar des d'un registre "<registre>p"
• Mostrar la finestra de canvis: `g
• Canvia el directori de treball: ,.
• Executa el validador PEP8 ,8
• Veure els marcadors: :marks
• Estableix un marcador m
• Ves a una marca '<lletra> (o accent greu + marca per anar al lloc exacte on s'establí.
• Obrir un buffer: :e
• Tancar un buffer: :bq o bé :bw

Vim és tot un món, hi ha combinacions i plugins a voler. Personalment crec que el truc éstà en anar aprenent a poc a poc, perimer amb el més bàsic i després amb totes aquestes virgueries fins anar configurant un entorn on ens hi trobem còmodes.

Posant la nostra configuració a un sistema de control de versions, disposar de la nostra configuració local és trivial.

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.

El món de les class based views dóna per molt, la possibilitat de sobreescriure funcions, canviar paràmetres i anar combinant mixins fins a obtenir el que necessitam ens permet reutilitzar molt de codi i de manera elegant.

En aquest darrer post de la sèrie veurem algunes de les situacions més habituals en les que ens podem trobar i la facilitat amb que es resolen.

El formulari per defecte no és el que vull

Sovint quan editam un objecte mitjançant un formulari ens trobam que hi ha camps que no volem que s'editin. A l'exemple que hem fet servir fins ara imaginem que no volem que una vegada s'ha crear l'slug es pugui modificar.

Per fer això el que hem de fer és crear un formulari nou. Com que es bo tenir les coses organitzades ho farem dins el fitxer forms.py

class SampleEditForm(forms.ModelForm):
    class Meta:
        model = Sample
        exclude = ('slug',)

i llavors a la classe que implementa l'edició li direm que agafi aquest formulari per a editar l'objecte

from forms import SampleEditForm

class SampleUpdateView(UpdateView):
    model = Sample
    success_url = reverse_lazy('tutorial_list_sample')
    form_class=SampleEditForm

Volem poder filtrar/ordenar els resultats

El ListView és un component idial per a fer cerques i filtres. Amb una fulla d'estils i un poc de javascript podem fer gairebé de tot. Per a no complicar-ho massa suposem que el que volem és establir dos filtres: un per quantitats positives i un de negatives, a més de l'opció per defecte que serà la de mostar-ho tot.

Afegirem els links dels filtres:

<a href="{% url tutorial_list_sample %}">All</a>|
<a href="{% url tutorial_list_sample %}?filter=positive">Positive</a>|
<a href="{% url tutorial_list_sample %}?filter=negative">Negative</a>

i ara a la classe el que farem serà sobrescriure el mètode get_queryset de manera que tengui en compte si estam filtrant o no i que apliqui el que correspon

class SampleListView(ListView):
    model = Sample
    paginate_by = 5

    def get_queryset(self):
        queryset = super(SampleListView, self).get_queryset()
        filter = self.request.GET.get('filter')
        if filter == 'positive':
            queryset = queryset.filter(ammount__gt=0)
        elif filter== 'negative':
            queryset = queryset.filter(ammount__lt=0)
        return queryset

Com es pot veure als exemples al final es tracta de'anar cercant el que s'ha de sobreescriure o extendre per a adaptar-lo a les nostres necessitats.

No vull acabar la sèrie sense referir-me a tota la part de Class Based Views orientades a mostrar informació que ha d'estar relacionada amb dates. Aquestes classes es troben a django.views.generic.dates i amb el que hem vist de ben segur que no tindreu cap dificultat per a fer-les servir.

Esper que us hagi agradat la sèrie i que us sigui profitosa. L'objectiu ha estat introduïr aquesta manera de fer les coses i organitzar el codi, que per projectes amb un bon grapat de models i manteniments, resulta amb menys codi, més ordenat i sobretot més mantenible i reaprofitable.

En aquesta sisena entrega (que hi ha algú per aquí ho ja us heu dormit tots?) veurem com podem mostrar llistes d'objectes que sovint podem trobar amb els CRUD.

Per a mostrar llistats (paginats o no) Django ens proporciona la classe ListView que es pot trobar a dango.views.generic.list.

Aquesta classe és hereva de MultipleObjectTemplateResponseMixin i de BaseListView.

BaseListView és el que la la feina, ja que és fill de MultipleObjectMixin i de View implementant-ne el mètode get.

Com les vistes orientades als CRUD també en aquest cas tenim una plantilla per defecte, formada pel nom del model i el sufixe '_list'.

El que més ens interessa són doncs els mètodes i atributs de MultipleObjectMixin. Primer de tot, però anem a fer-ho fàcil, mostrarem la llista dels objectes que hem creat al post anterior:

A l'url:

url(r'^tutorial/sample/list/$', SampleListView.as_view(),
    name='tutorial_list_sample'),

i al views.py podem fer

from django.views.generic.list import ListView

class SampleListView(ListView):
    model = Sample

i ara haurem de definir la plantilla que tindrà com a nom sample_list.html, primer, però és convenient conèixer quines variables es passen al context, a saber:

• paginator
• page_obj
• is_paginated
• object_list

Els valors poden canviar en funció de si tenim paginació o no, però les variables que tenim són aquestes. El que ens interessa per ara és object_list que conté la llista d'objectes del model. De manera que podem fer una plantilla del tipus:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
    <title>test</title>
</head>
<body>
    <h1>Sample Detail List</h1>
    <table border="1">

    {% for sample in object_list %}
    <tr>
        <td><a href="{% url tutorial_update_sample sample.slug %}">
            {{sample.slug}}</a><td/>
        <td>{{sample.name}}<td/>
        <td>{{sample.ammount}}<td/>
        <td>{{sample.comments}}<td/>
        <td>
            <a href="{% url tutorial_delete_sample sample.slug %}">Delete</a>|
            <a href="{% url tutorial_create_sample %}">Create</a>
        </td>
        </tr>
    {% endfor %}
    </tr>
    </table>
</body>
</html>

Fixau-vos que no estic fent herència, l'html és molt simple etc. L'important aquí és veure com podem recórrer la llista d'objectes per montar les files d'una taula, i com amb el que ja sabem del CRUD podem enllaçar amb els manteniments.

Ara a l'hora de crear, editar o esborrar un registre podem elegir entre mostrar el registre o anar al llistat, afegint

success_url = reverse_lazy('tutorial_list_sample')

a les vistes que ens interessa ja ho tindriem.

Paginació

Com podem tenir molts resultats és comú que les llistes es mostrin paginades. Per fer això el que hem d'afegir l'atribut paginate_by que ens determinarà el nombre màxim d'elements que es mostraran per plana.

 class SampleListView(ListView):
    model = Sample
    paginate_by = 2

Si fem això i no modificam la plantilla, sols veurem dos registres, el que ens falta ara és afegir els controls de plana anterior i plana següent. Hi ham moltes maneres de fer la paginació i a la web en trobareu un bon munt, però per senzillesa aquest

{% if is_paginated %}
        {% if page_obj.has_previous %}
          <a href="{% url tutorial_list_sample %}?page={{ page_obj.previous_page_number }}">
             Previous</a>
        {% endif %}
            <!-- current page -->
                Page {{ page_obj.number }} of {{ page_obj.paginator.num_pages }}.
            <!-- end current page -->
        {% if page_obj.has_next %}
         <a href="{% url tutorial_list_sample %}?page={{ page_obj.next_page_number }}">
                Next</a>
         {% endif %}
{% endif %}

Recordau que hem dit que al context es passava page_object? Doncs fixau-vos com es fa servir per saber les propietats de la plana on estam, el nombre de planes total, si la plana té una plana anterior o una plana següent i el nombre corresponent a aquesta plana.

També fem us del is_paginated de manera que no mostrem el selector de plana anterior i següent si sols hi ha una plana.

I ja ho tenim!

Al proper post, que tancarà la sèrie, veurem com podem limitar la informació que mostram als formularis d'edició

Creant un CRUD

En aquesta cinquena part veurem com podem crear tot el relacionat amb un manteniment, el famós CRUD (Create, Retreive, Update, Delete).

La part de Retreive ja l'hem vista a l'article anterior, però hi tornarem per a que ens quedi un exemple complet.

Partirem del següent model:

class Sample(models.Model):
    """this is just a sample model"""

    slug = models.SlugField(max_length=50, unique=True)
    name = models.CharField(max_length=100)
    ammount = models.IntegerField()
    comments = models.TextField(blank=True, null=True)

    class Meta:
        verbose_name = 'Sample'
        verbose_name_plural = 'Sample'

    def __unicode__(self):
        return self.name

Django a més de DetailView ens proporciona les següents vistes ja construïdes per fer aquest tipus de tasques:

* `CreateView` que gestiona la creació
* `UpdateView` que gestiona l'actualització
* `DeleteView` gestiona l'esborrat

Comencem!

Creació

Definim primer la url

url(r'^tutorial/sample/create/$', SampleCreateView.as_view(),
    name='tutorial_create_sample'),

Hem anomenat a la nostra classe SampleCreateView així que la definirem al views.py

from django.views.generic.edit import CreateView
from main.models import Sample

class SampleCreateView(CreateView):
    model = Sample

Amb això Django ja ens crearà internament un formulari i l'intentarà presentar a una plantilla que es construeix amb el nom del model i el sufixe _form, és a dir, en el nostre cas sample_form.html passant com a variable de context el formulari creat form

Si volem fer via amb :

    <form action="."
            method="post" accept-charset="utf-8">
            {% csrf_token %}
        <table>
        {{form}}
        </table>
        <p><input type="submit" value="Save &rarr;"></p>
    </form>

ja ens anirà bé. Django ja se n'encarrega de validar el formulari contra el nostre model. És a dir, si posam quelcom que no sigui un nombre sencer a amount ens generarà un error.

Si creau la plantilla i posau dades vàlides i intentau guardar us donarà un error: "No URL to redirect to. Either provide a url or define a get_absolute_url method on the Model.", poc a poc i ara hi anirem a això.

Mostram l'objecte

Encara que ja ho vàrem veure com es feia al post anterior, per completitud, ho farem també ara:

La url:

    url(r'^tutorial/sample/retrieve/(?P<pk>\d+)/$', 
        SampleView.as_view(),
        name='tutorial_view_sample'),

i al views.py

class SampleView(DetailView):
    model = Sample

Recordau l'error del que hem parlat abans? Doncs el que farem és modificar el model per definir el `get_absolute_url, també podíem haver definit success_url o sobreescrit get_success_url però això ja ho vàrem veure, així que variarem un poc.

Modificam el nostre model

class Sample(models.Model):
    """this is just a sample model"""

    slug = models.SlugField(max_length=50, unique=True)
    name = models.CharField(max_length=100)
    ammount = models.IntegerField()
    comments = models.TextField(blank=True, null=True)

    class Meta:
        verbose_name = 'Sample'
        verbose_name_plural = 'Sample'

    def __unicode__(self):
        return self.name

    @models.permalink
    def get_absolute_url(self):
        return ('tutorial_view_sample', [self.id, ])

També podíem haver fet el mateix fent servir l'slug, amb la qual cosa tindríem urls més amigables. Per això hem de canviar tant la url com el get_absolute_url

class Sample(models.Model):
    """this is just a sample model"""

    slug = models.SlugField(max_length=50, unique=True)
    name = models.CharField(max_length=100)
    ammount = models.IntegerField()
    comments = models.TextField(blank=True, null=True)

    class Meta:
        verbose_name = 'Sample'
        verbose_name_plural = 'Sample'

    def __unicode__(self):
        return self.name

    @models.permalink
    def get_absolute_url(self):
        return ('tutorial_view_sample', [self.slug, ])

i la url:

url(r'^tutorial/sample/retrieve/(?P<slug>[-\w]+)/$', 
    SampleView.as_view(),
    name='tutorial_view_sample'),

Què fa el permalink? doncs, com veis, crea una url per al nostre objecte a partir del nom que li hem donat a la url que serveix per visualitzar-ho.

Això ens permet no anar posant les urls a foc, sinó tenir-les definides amb un nom dins tota l'aplicació.

Si ara provau de fer anar el formulari veureu que ja funciona. Podem crear-lo i en guardar mostrar el resulta. Ja tenim dues de les quatre lletres, anem a veure les que falten.

Actualització

L'actualització és també molt senzilla. Farem servir UpdateView però a diferència de la creació a la url li hem de passar bé la clau primària de l'objecte o bé l'slug (sempres suposant que aquest sigui únic).

la url:

url(r'^tutorial/sample/update/(?P<slug>[-\w]+)/$', 
    SampleUpdateView.as_view(),
    name='tutorial_update_sample'),

pràcticament semblant a la de visualització, i ara a la part de la vista bastarà fer:

from django.views.generic.edit import UpdateView

class SampleUpdateView(UpdateView):
    model = Sample

Ara sols ens falta lligar la url per poder anar a l'edició de l'objecte, ho podem fer directament des de la barra de navegació, però millor posar-ho també a la plana web, per exemple amb un link a la plantilla de visualització per a que ens dugui a l'edició de l'objecete. Ja que hi sóm posarem també el link de creació. Molt resumidament, el nostre sample_detail.html quedaria de la forma:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
    <title>test</title>
</head>
<body>
    <h1>Sample Detail</h1>
    {{sample.slug}}<br/>
    {{sample.name}}<br/>
    {{sample.ammount}}<br/>
    {{sample.comments}}<br/>

    <a href="{% url tutorial_update_sample sample.slug %}">Update</a>|
    <a href="{% url tutorial_create_sample %}">Create</a>
</body>
</html>

Eliminació

Ja hem arribat a la darrera lletra de l'acrònim. Per a esborrar un objecte Django ens proporciona la vista DeleteView. Abans d'esborrar es convenient demanar confirmació i a la implementació de Django es té això en compte.

La url serà de la forma:

url(r'^tutorial/sample/delete/(?P<slug>[-\w]+)/$',
    SampleDeleteView.as_view(),
    name='tutorial_delete_sample'),

i a la view.py

from django.views.generic.edit import DeleteView

class SampleDeleteView(DeleteView):
    model = Sample

si volem que tot funcioni per defecte, hem de crear una plantilla construida amb el nom del model i el sufixe "_confirm_delete".

En aquesta plantilla hem de demanar la confirmitat per esborrar el registre, enviant-ho a la mateixa URL d'esborrat però fent un POST. És a dir la url amb GET presenta la confirmació i amb POST fa l'acció.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
    <title>test</title>
</head>
<body>
    <h1>Sample Delete</h1>
    {{sample.slug}}<br/>
    {{sample.name}}<br/>
    {{sample.ammount}}<br/>
    {{sample.comments}}<br/>

    <p>Are you sure?</p>

    <form action="."
            method="post" accept-charset="utf-8">
            {% csrf_token %}
        <p><input type="submit" value="Delete &rarr;"></p>
    </form>

    <p><a href="<a href="{% url tutorial_view_sample sample.slug %}">Return</a>
</body>
</html>

A l'actualització o a la creació no feia falta dir-li a Django on volíem anar, per defecte anava a la visualització de l'objecte. Ara l'estam esborrant, així que no hi ha objecte. Així que obligatòriament li hem de donar la url a la que ha d'anar en cas que l'objecte s'hagi eliminat. Ho podem enviar a una plana amb el llistat de tots els registres, però com que encara no hem vist com es fa, ara per ara l'enviarem al formulari de creació.

class SampleDeleteView(DeleteView):
    model = Sample
    success_url = reverse_lazy('tutorial_create_sample')

I ja tenim el CRUD complet. Ens falta poder visualitzar un llistat paginat d'objectes i fer algunes accions bàsiques amb formularis. Ho veurem al proper apunt.

Començam a lligar les class views amb els models de dades, que això es posa cada cop més interessant.

Fins ara hem vist un ús de les class views molt genèric, és a dir, amb el que sabem podem mostrar planes webs i gestionar el treball amb formularis.

Es comú en la majoria d'aplicacions web modernes que les dades venguin d'algún lloc, d'una base de dades per exemple. Així que la gent de Django han creat tota una sèrie de mixin i vistes específices per a simplificar-ne el treball.

Mostrar un objecte

Suposem que volem mostrar les dades que tenim d'un usuari. Com sabeu el model User de Django conté les dades dels usuaris i es troba a django.contrib.auth.models.

Voldríem que en especificar-ne la clau primària a la url poder mostrar les dades de l'usuari corresponent.

És a dir, es tracta de mostrar informació que es correspon a urls d'aquest tipus

'^prefix/(?P<pk>\d+)/$'

o també

'^prefix/(?P<slug>[-w]+)/$'

Django ens proporciona la classe DetailView per fer precisament això. És a dir, per estalviar-nos la major part de la feina de cercar l'objecte que es correspon amb la clau primària o l'slug i passar-ho a la plantilla per a la seva presentació. Per si us ho demanaveu DetailView es troba a django.views.generic.detail.

Anem a veure un poc DetailView per dintre:

Aquesta classe hereta de SingelObjectTemplateResponseMixin i de BaseDetailView. La primera a la seva vegada és fila de una vella coneguda TemplateResponseMixin i en sobrescriu el mètode get_template_names per tal d'establir un nom de plantilla per defecte, que en el cas dels models és de la forma app/nom_detail.html, és a dir, per al nostre exemple, si no posam cap nom de plantilla agafarà per defecte auth/user_detail.html.

Per la seva banda BaseDetailView és filla de SingleObjectMixin i de View i implementa el mètode get i li passa al contexte de la plantilla la variable object amb el contingut de l'objecte que es correspon a la clau primària.

Com que object pot resultar un tant confús, Django també passa el mateix contingut a una variable amb el nom de l'objecte si el model té el nom posat al verbose_name o bé farà servir el que li indiquem a l'atribut context_object_name de la Classe.

SingleObjectMixin és la classe encarregada de fer el gruix de la feina, i com no, també implementa el mètode get_context_data per a poder passar més informació a la plantilla.

Així doncs, mostrar un objecte pot ser tan senzill com això:

al urls.py afegim:

url(r'^user/(?P<pk>\d+)/$', UserView.as_view(),
        name='main_user'),

i no oblidem importar UserView, que crearem dins views.py i que pot ser tan simple com:

class UserView(DetailView):
    model = User

Com que User té assignat un verbose_name='User' Django passa a la plantilla tant la variable object com la variable user i per tant en condicions normals podríem fer servir tant un nom com l'altra.

En el nostre cas, i si com jo teniu dins el context processors la línia 'django.contrib.auth.context_processors.auth' us trobareu que la variable "no funciona". Això és perquè encara que se li passi, el context processor crea també una variable anomenada 'user' amb les dades de l'usuari autenticat (si existeix), i com s'assigna just abans de generar la plantilla, el contingut que prevaleix és el del context processor.

Una cosa que em va sorprendre del SignleObjectMixin és que a més del mètode get_object implementa també get_queryset. De fet get_objectcrida a get_queryset i li aplica un filtre per clau primaria (pk) o bé per slug.

Què vol dir això, doncs que tenim un nivell extra de flexibilitat a l'hora de determinar si un objecte és presentable per pantalla o no. Basta sobreescriure el mètode get_queryset i independentment que la clau primària (o l'slug) existeixi en la base de dades, podem fer que l'objecte no es mostri. Per exemple, suposem que en el nostre exemple anterior no volem mostrar l'usuari admin.

Podem fer

class UserView(DetailView):
    model = User

    def get_queryset(self):
        query = super(UserView, self).get_queryset()
        return query.exclude(username='admin')

de manera que UserView ens mostrarà la informació de qualsevol usuari llevat de l'usuari admin, en aquest cas mostrarà un error 404.

SingleObjectMixin com hem dit, pot tornar-nos un objecte a partir de la seva clau primària o bé a partir de l'slug. Normalment en farem servir un o altre. L'ordre de prioritat és primer el pk i si aquest està buid, es mirar l'slug.

Al proper post farem una ullada a les facilitats que ens donen les generic class views per a gestionar els manteniments i veurem com es pot fer un cicle CRUD.

En aquest apunt veurem com fer servir les generic class views per a fer feina amb formularis.

Seguirem la documentació de Django que tracta dels formularis. Allà ens fa referència a un formulari de contacte creat com:

from django import forms

class ContactForm(forms.Form):
    subject = forms.CharField(max_length=100)
    message = forms.CharField()
    sender = forms.EmailField()
    cc_myself = forms.BooleanField(required=False)

i la vista associada

def contact(request):
    if request.method == 'POST': # If the form has been submitted...
        form = ContactForm(request.POST) # A form bound to the POST data
        if form.is_valid(): # All validation rules pass
            # Process the data in form.cleaned_data
            # ...
            return HttpResponseRedirect('/thanks/') # Redirect after POST
    else:
        form = ContactForm() # An unbound form

    return render_to_response('contact.html', {
        'form': form,
    })

El que farem ara és fer el mateix però fent servir les generic class views.

El primer que hem de veure és què hem de fer servir. Necessitam gestionar un formulari, la seva validació i tornar la redirecció cap a una nova plana web en cas que tot vagi bé.

Si feim una ullada a la jerarquia de classes del mòdul edit podem veure que la classes que compleix tot el que volem es diu FormView.

FormView està composada pel mixin TemplateResponseMixin que ja coneixem i BaseFormView que a la seva vegada està format per dos mixins més FormMixin i ProcessFormView.

FormMixin ens proporciona els mètodes per a gestionar el form i ProcessFormView que descendeix de View ens proporciona les respostes a les cridades get, post i put.

L'equivalent fent servir les generic class views ens queda:

class ContactView(FormView):
    form_class=ContactForm
    success_url = reverse_lazy('main_thanks')
    template_name = 'main/index.html'

    def form_valid(self, form):
        # process data
        print form.cleaned_data
        return super(ContactView, self).form_valid(form)

és a dir, hem de dir li a la classe quin formulari farem servir, això ho feim a form_class o bé amb la rescriptura del mètode get_form_class que ens ha proporcionat el mixin FormMixin o fin i tot instanciant el formulari directament si fem la rescriptura de get_form

Els mètodes form_valid i form_invalid ens permeten definir què em de fer amb el formulari. Normalment ens bastarà sobreescriure el mètode form_valid per a adaptar-lo a les nostres necessitats.

I qui crida al mètode is_valid del formulari? Doncs el post que prové de ProcessFormView. Recordem que un mixin té accés a tot l'objecte que el fa servir, i per tant també té accés als mètodes el mixin FormMixin.

Suposem ara que volem que el nostre formulari agafi uns certs valors inicials, això ho podem fer amb l'atribut initial definit a FormMixin o bé a partir de la reescriptura del mètode get_initial, segons la nostra aplicació ens convindrà un mètode o un altre.

class ContactView(FormView):
    form_class=ContactForm
    success_url = reverse_lazy('main_thanks')
    template_name = 'main/index.html'
    initial = {'subject': u'This is a test form'}

    def form_valid(self, form):
        # process data
        print form.cleaned_data
        return super(ContactView, self).form_valid(form)

Si a més hem de passar dades addicionals a la plantilla Django, FormMixin ens proporciona un altre vell conegut, el mètode get_context_data que fa el mateix que feia al TemplateView. Això sí, ara hem de tenir cura de cridar al mètode pare, ja que als kwargs hi ha la definició del formulari. Per a evitar-nos conèixer què fa i que no fa, millor cridar al mètode pare i a partir d'aquí afegir-hi les variables que necessitem:

class ContactView(FormView):
    form_class=ContactForm
    success_url = reverse_lazy('main_thanks')
    template_name = 'main/index.html'
    initial = {'subject': u'This is a test form'}

    def form_valid(self, form):
        # process data
        print form.cleaned_data
        return super(ContactView, self).form_valid(form)

    def get_context_data(self, **kwargs):
        context = super(ContactView, self).get_context_data(**kwargs)
        context['msg'] = u'Hello World'
        return context

I no hem de perdre de vista que estam fent feina amb classes. Podem anar afegint els mètodes que necessitem a la classe, de manera que cada funció ens quedi manejable.

I ja per acabar un petit avís, he fet servir reverse_lazy per a obtenir el valor de la url, però aquesta funció no hi és a Django 1.3. Per utilitzar el nom de la url enlloc de la url en sí, en Django 1.3 o bé hem de sobreescriure get_success_url o bé utilitzar l'snippet que apareix a Django Snippets i que resol això d'una manera molt elegant:

from django.utils.functional import lazy
from django.core.urlresolvers import reverse
reverse_lazy = lambda name=None, *args : lazy(reverse, str)(name, args=args)

Això encara dóna per més, fins al proper article!

En aquesta segona part veurem alguns dels usos més interessants de les class based views per a presentar informació i estalviar-nos feina.

TemplateView

Com ja vàrem veure a la primera part el TemplateView ens estalvia molta feina respecte a la manera tradicional de fer les coses, sols pel fet de passar ja el RequestContext ja recomanaria passar-nos al nou món de les Class Based Views, però encara hi ha més!

TemplateView incorpora dos mètodes més get_context_data i get. Amb el get el que fa es cridar al mètode render_to_response que ens proporciona el mixin TemplateResponseMixin i passant-li com a arguments el diccionari que ens ha de tornar el mètode get_context_data.

Per defecte get_context_data ens retorna un diccionari amb els paràmetres que venen de la url, així si la nostra url és

 url(r'^test3/(?P<id>\d+)/$', Test3View.as_view(), 
    name="test3-class-view"),

llavors get_context_data conté el diccionari {'id': 3} i a la plantilla es passarà una variable anomenada params amb aquest diccionari.

Suposem però que no és això exactament el que volem. Volem que passi a la plantilla una variable anomenanda msg amb una salutació per als lectors del blog.

El que farem serà sobreescriure get_context_data per a que passi la informació que nosaltres volem a la plantilla.

class Test3View(TemplateView):
    template_name = 'main/index.html'

    def get_context_data(self, **kwargs):
        context = super(Test3View, self).get_context_data(**kwargs)
        context['id'] = self.kwargs.get('id')
        context['msg'] = u'Hello blog!'
        return context

Estrictament parlant no faria falta cridar al mètode pare de get_context_data i de fet estam passant també la variable params però fer-ho no fa mal i ens proporciona un cert grau de protecció davant possibles problemes si un dia decidim que Test3View ja no heretarà de TemplateView sinó d'una altra classe on ja s'hi posi altra informació al contexte.

Al context_data i podem posar tota la informació que necessitem, fixem-nos que és el mateix que feiem amb les funcions que acabaven cridant al render_to_template sols que ara tot està més estructurat.

Suposem que volem que els missatge no estigui prefixat sinó que es generi a partir del resultat d'una funció. Abans hauríem creat la funció en algun lloc, a un mòdul apart, abans del mètode que renderitza la plantilla, ... Ara ho podem encapsular dins la mateixa classe

class Test3View(TemplateView):
    template_name = 'main/index.html'

    def get_message(self):
        return u'Hello blog'

    def get_context_data(self, **kwargs):
        context = super(Test3View, self).get_context_data(**kwargs)
        context = dict()
        context['id'] = self.kwargs.get('id')
        context['msg'] = self.get_message()
        return context

I encara tenim més flexibilitat, gràcies al mixin TemplateResponseMixin podem definir quina plantilla s'utilitzarà segons ens convingui

Suposem que el paràmetre id ens serveix per a definir el nom de la plantilla, de manera que si existeix una plantilla que hi casi la presentarà i si no es quedarà amb la plantilla per defecte. Podríem fer

class Test3View(TemplateView):
    template_name = 'main/index.html'

    def get_message(self):
        return u'Hello blog'

    def get_template_names(self):
        plantilla = 'main/index%s.html' % self.kwargs.get('id')
        return [plantilla, ] + super(Test3View, self).get_template_names()

    def get_context_data(self, **kwargs):
        context = super(Test3View, self).get_context_data(**kwargs)
        context['id'] = self.kwargs.get('id')
        context['msg'] = self.get_message()
        return context

Com veis la potència i la flexibilitat del que es pot fer amb les class based views no té res a veure amb el que es podia fer abans. Ara tenim molta més flexibilitat, més encapsulació i menys codi a escriure.

Al propert post parlarem de formularis...

Class based views

Amb Django 1.3 s'introdueixen les "Class based views", una funcionalitat que ens permet modelar les nostres vistes com a classes i que a més intenta solucionar el no tenir que escriure sempre el mateix tipus de codi quan mostram una plana web o fem un manteniment lligat a un model de dades.

Les class based views ens permeten un nivell més alt de reutilització del nostre codi i a més ens permeten de mantenir-ne la cohesió. Fins ara o bé teníem que anar creant les funcions dins la mateixa vista, dins la mateixa funció o tirar de mòduls independents.

Amb les class based views pode anar creant funcions per a la nostra vista, de manera que després sigui més bo de fer reaprofitar-les extenent la classe.

En poques paraules, les class based views requereixen un temps d'adaptació i alguns diuen que aprendre un nou DSL (Domain Specific Language). Potser sí, però s'ho paga.

Abans de començar

Encara que podem utilitzar les nostres pròpies class based views, Django ens dóna ja fetes les més freqüents i un conjunt de classes que podem fer servir en cas que cap ens encaixi.

És en aquestes classes on hi ha gran part de la potència de les class based views. Per a fer-les servir hem d'entendre el concepte de Mixin, ja que això són aquestes classes: Python mixins.

Què és un mixin?

Un mixin no és res més que una classe que no està concebuda per tenir entitat per sí mateixa, sinó per extendra la funcionalitat d'altres classes fent servir l'herència múltiple de Python.

Un mixin, per tant, afegeix funcionalitat a les classes. Podem crear Mixins com si de mòduls Python es tractàs i aplicar-los a les nostres classes per dotar-les de més funcionalitat.

Hem d'entendre també com funciona l'herència múltiple en Python, de manera resumida: s'executarà el primer mètode que es trobi anant d'esquerra cap a dreta en la definició de les classes. És a dir, si tenim:

class Test(OneMixin, AnotherMixin):
    pass

a l'hora d'executar un mètode, Python primer cercarà a OneMixin i si no ho troba anirà a AnotherMixin. Així doncs, al tanto que l'ordre en que posam les classes és important.

A diferència dels mòduls els mixins tenen accés a la instància self de la clases, i per tant poden fer servir informació associada a l'objecte i altres mètodes.

La classe View

Aquesta classe és el bessó de tot el muntatge, i si cap de les funcionalitats que ens proporciona Django ens serveix gairebé segur que començarem a crear la nostra pròpia extenent aquesta classe.

Anem a fer un exemple molt senzill, suposem que volem mostrar una plana web, que anomenarem index.html i que posaré dins la carpeta main. Com que començam amb això de les generic class views, anam llegit i ens n'adonam que la classe View el que fa és capturar els noms dels mètodes http i executar-ne una funció associada amb el matix nom.

Ja està, ens deim, el que hem de fer es crear una classe que hereti de View i escriure'n un mètode que respongui a la creidada GET i que ens renderitzi la plana. Dit i fet, cream l'aplicació main i la registram al settins.py i anam per feina:

Al mòdul views.py

from django.shortcuts import render_to_response
from django.views.generic.base import View
from django.template import RequestContext

class TestView(View):
    def get(self, request, *args, **kwargs):
        return render_to_response('main/index.html', {},
            context_instance=RequestContext(self.request) )

i a urls.py de l'aplicació main

from django.conf.urls.defaults import *
from views import TestView

urlpatterns = patterns('',
    url(r'^test2/$', TestView.as_view(), name="test-class-view"),
    )

Executam i efectivament això funciona. Ens mostra la plana. Però la cosa no ens acaba de convèncer, no?, ja que si fem una ullada a la manera anterior de fer les coses, això ben bé es podria fer com:

from django.shortcuts import render_to_response
from django.template import RequestContext

def test(request):
    return render_to_response('main/index.html', {},
        context_instance=RequestContext(request) )

hem escrit fins i tot més, on està el guany, doncs? La resposta està en la reusabilitat.

Aquest patró de mostrar planes web senzilles es repeteix molt en les aplicacions web, de manera que la gent de Django ja ha creat una classe que hereta de Views i que fa precissament això i d'una manera més genèrica, la classe TemplateView

Aquesta classe hereta de TemplateResponseMixin i de View. TemplateResponseMixin és un mixin que té dos mètodes: render_to_response i get_templates_names i dos atributs: template_name i response_class. El que ens interessa ara és que TemplateResponseMixin ens permet afegir a la nostra classe la renderització de la plantilla que passem dins template_name o bé que tornem a partir de la sobreescriptura de get_templates_names

Si fem servir TemplateView el nostre codi queda com:

from django.views.generic.base import TemplateView

class IndexView(TemplateView):
    template_name = 'main/index.html'

i a urls.py

from django.conf.urls.defaults import *
from views import IndexView

urlpatterns = patterns('',
    url(r'^$', IndexView.as_view(), name='main_index'),
    )

Fins i tot podríem prescindir del codi de view.py i podríem fer:

from django.conf.urls.defaults import *
from django.views.generic.base import TemplateView

urlpatterns = patterns('',
    url(r'^$', TemplateView.as_view(template_name='main/index.html'), 
        name='main_index'),
    )

Com podeu veure l'estalvi en línies de codi comença a ser notable.

L'important, a més de veure com es pot extendre la funcionalitat de Views és que vegem què senzill és separar la funcionalitat lligada al GET de la funcionalitat lligada al POST, al PUT, o a qualsevol cridada HTTP. Sols hem de crear una funció amb aquest nom i Django la cridarà sempre que la nostra classe hereti de View.

Suposem doncs que el que volem ara és mostrar una plana diferent si algú ens intenta fer un POST contra la nostra plana. Django té un mecanisme per protegir-nos d'això és el CSRF o Cross Site Request Forgery protection, ara el que voldriem es desactivar aquest mecanisme per la nostra classe i mostrar una plana diferent d'avís.

Amb el mètode classis hauríem de fer un

if request.method=='POST':
    #fes alguna cosa
else:
    #fes una altra cosa

amb les Class Based Views la cosa queda molt més elegant:

class TestView(View):
    def get(self, request, *args, **kwargs):
        return render_to_response('main/index.html', {},
            context_instance=RequestContext(self.request) )

    def post(self, request, *args, **kwargs):
        return render_to_response('no_post_allowed.html')

Això tal com està no funcionaria, ja que tenim pel mig la protecció de Django.

Per saltar-nos aquesta protecció li hem de dir a la vista que no la volem i per fer-ho hem de sobreescriure el mètode dispatch que se n'encarrega de la fontaneria de verificar quin mètode http ens ve i la funció que hem de cridar.

from django.views.generic.base import View
from django.views.decorators.csrf import csrf_exempt
from django.utils.decorators import method_decorator

class TestView(View): 
    def get(self, request, *args, **kwargs):
        return render_to_response('main/index.html', {},
            context_instance=RequestContext(self.request) )

    def post(self, request, *args, **kwargs):
        return render_to_response('no_post_allowed.html')

    @method_decorator(csrf_exempt)
    def dispatch(self, *args, **kwargs):
        return super(TestView, self).dispatch(*args, **kwargs)

Hem vist fins ara com fer servir la classe View i la classe TemplateView, hi tornarem en els propers apunts, estau atents.

Abans d'escriure aquest apunt de m'he adonat que era el post amb l'identificador 500. Un nombre rodó i que potser mereixeria algun tipus de celebració, però tanmateix no és l'apunt que fa 500, ja que en les proves del codi del blog, segurament vaig afegir i esborrar apunts que han fet anar cap endavant el comptador, realment encara falten prop d'una trentena d'apunts per a arribar al que fa 500, així que deixaré el cava a la gelera.

Hi va haver una proposta de celebrar-ho fent un regal, però pareix que la meva proposta de regalar una capsa d'un Nexus (tot i que comptava amb un possible patrocionador) no ha arribat a cuallar :-P

Així doncs el que faré és reprende l'apunt sobre el dajaxproject, i em centraré en l'altra component, anomenat Dajax.

Dajax

Ja vàrem veure com dajaxice ens deixava fer cridades AJAX cap a la nostra aplicació Django i organitzar-les. Dajax va més enllà in ens permet interactuar amb la interfície d'usuari des de codi Python. Fet servir amb mesura i seny ens pot ajudar també a fer molt més legible el nostre codi i a organtizar millor les accions derivades d'una cridada AJAX dins el mateix codi que les gestiona. No us penseu però que es tracta de quelcom com Pyjamas sinó que són més bé un conjunt de primitives que ens permetran agilitar la feina.

Per començar a jugar-hi necessitareu haver llegit el meu apunt anterior (o la documentació del projecte) ja que Dajax fa servir la seva llibreria germana dajaxice i també tenir instal·lat algun dels frameworks javascript suportats, en el meu cas faré servir jQuery.

Recepta

A la part de servidor

1. Instal·lau django-dajax i posau dajax com a aplicació al settings.py.

2. Posau from dajax.core.Dajax import Dajax a l'arxiu ajax.py de la vostra aplicació, junt amb from dajaxice.decorators import dajaxice_register que ja havíem vist abans per a registrar la petició.

3. A la funció AJAX instanciarem la classe, dajax=Dajax()

4. Farem el que tinguem que fer dins la funció AJAX i després anirem executant els mètodes de dajax que ens interessin per a interaccionar amb la part HTML de l'aplicació.

5. Finalment retornarem el json amb return dajax.json()

A la part de client

Hem de afegir l'arxiu javascript que correspongui segons la llibreria que volguem fer servir. En el nostre cas jquery.dajax.core.js que es troba a django-dajax/scr/. En el meu cas la cosa queda com:

{% dajaxice_js_import %}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script src="{{STATIC_URL}}/jquery.dajax.core.js"></script>

En executar-se l'event que ens interessi (un clic normalment) cridarem la función AJAX que hem registrat de manera semblant a com ho feiem a l'exemple de Dajaxice, però ara a la funció li passarem com a paràmetre Dajax.process i un diccionari java de valors opcional, si la funció té paràmetres.

Important Un ús molt habitual de Dajax es dona en combinació amb els formularis Django, en aquest cas el paràmetre de les dades del formulari. Per a que Django les pugui interpretar bé com a provinents d'un formulari hem de serialitzar-les, si fem servir jQuery això necessita d'una llibreria addicional anomenada serializeobject.

Què es pot fer?

Les funcions que ens proporciona Dajax ens permeten tant manipular l'arbre DOM de la plana web com cridar a funcions javascript ja que tinguem fetes.

*alert(message) Com el seu nou indica hi haureu endivinat, mostra una alterta javascript amb el missatge que li indiquem.

• assign(selector, attribute, valor) Donat un selector (id, classe, tipus, ...) i un atribut li asigna el valor el valor que li passam al paràmetre a tots els elements que casin amb el selector. Seria l'equivalent a fer amb jQuery per exemple $('.test').attr('title', 'hola') però enlloc de aplicar-ho sols al primer element com fa jQuery ho aplicaria a tots els elements que tinguin assignada la classe test.

• add_css_class(selector,value). Assigna tots els elements que casin amb el selector la classe css especificada a paràmetre value. value pot ser una cadena o bé una llista de cadenes, en cas de ser una llista s'assignaran totes les classes de la llista.

• remove_css_class(selector,value). Funció complementaria de l'anterior, és a dir, enlloc de posar lleva.

• append(selector,attribute,value)afegeix a tots els elements que casin amb el seletor l'atribut donat amb el valor indicat avalue`.

• prepend(selector,attribute,value) Afegeix a l'inici a tots els elements que casin amb el selector l'atribut especificat amb el valor que li passam com a paràmetre.

• clear(selector,attribute). Netja l'atribut especificat de tots els elements que casin amb el selector.

• redirect(url,delay=0). Redirecciona la plana cap la nova url després del temps especificat en el paràmetre delay.

• script(code). Executa el codi javascript especificat en el navegador. Per exemple, podem executar l'alert de l'exemple anterior. Hem d'anar un poc alerta amb aquesta funció i evitar fer-ne un mal ús posant-hi tot el codi. Si hem de fer crides, millor posar-les dins el seu corresponent arxiu javascript i fer tan sols script(la_funcio()).

• remove(selector). Elimina tots els elements que casen amb el selector especificat.

• add_data(data,callback_function). Executa la funció que li especificam en el segon paràmetre amb les dades que hem posat al primer paràmetre. Com el cas d'script alerta amb abusar-ne.

Algunes recomanacions

Django té un sistema de plantilles molt potent, es poden fer servir junt amb assign i remove per a posar els continguts que ens interessin. Vull dir que no fa falta que una plantilla estigui lligada a un view sinó que es pot fer servir directament. Mirau-ne l'API.

Podem generar contingut HTML (o js) directament o fer servir una plantilla a un fitxer i utilitzar el render_to_string.

Tampoc estam limitats a fer servir el sistema de plantilles de Django per a generar l'HTML segons el que es tengui que tornar potser un sistema com Mako us va millor. Personalment sóc partidari de no mesclar massa.

Errors típics

Sovint et pots passar una bona estona demanant-te perquè no funciona la teva cridada AJAX, així que anem a fer una llista de recomanacions:

1. Reinicia la consola de desenvolupament. A vegades la nova función no es registra bé i no es torna a generar el codi javascript. Si això passa, el símptoma és que tens un error dient que no es troba la funció.

2. Hi ha un error que diu que no es troba Dajax al javascript. Típic de quan t'has oblidat de incloure la llibreria específica pel frameworks que fas servir.

3. Es fa la cridad però no s'executa res. Doncs que t'has deixat el retorn a la funció AJAX. Recorda que normalment hi haurà un return dajax.json() o si no les cridades no s'efectuaran.

4. Django no és capaç d'interpretar el que li enviam al formulari. Ens hem deixat la llibreria serializeobject

5. Teníem events lligats a un element i ara no responen. Típic de quan hem generat nou contingut. Els events s'han de tornar a lligar amb els nous continguts encara que tenguéssin el mateix identificador. Potser fer servir .live() o .delegate() de jQuery ajudaria, però ara per ara jo el que he fet és tornar-los a lligar posant els elements a una funció d'inicialització i tornar-la a cridar amb script.

Una de les preguntes més recurrents en les llistes de Django, junt amb la de quin editor fer servir és la de com fer cridades AJAX i quina llibreria utilitzar.

Django és agnòstic en el que fa a les llibreries javascript, tot i això la part de l'admin fa servir jQuery, però oficialment no hi ha cap llibreria especialment recomanada, Django és pot utilitzar amb qualsevol llibreria i dependrà del projecte que en triem una o altra.

El problema de que no es faci cap recomanació de com integrar cridades AJAX amb Django ens dóna molta llibertat, però també te l'emperò de que no hi ha cap guia de bones pràctiques sobre com fer-ho, des d'on posar la llibreria, quin nom li hem de donar, si la posam al views.py o no.

El la comunitat de codi obert quan hi ha un buid així i una necessitat ben aviat sorgeixen projectes que intenten donar una resposta. Un d'aquests projectes és el que us present en aquest article el dajaxproject.

Djaxaproject són de fet dues llibreries, dajaxice i dajax, la primera podríem dir que respon a la necessitat que us comentava de fer més senzilla la comunicació asíncrona entre les aplicacions Django y el codi javascript, la segona, dajax està molt més orientada cap a la capa de presentació i sobretot està lligada a un bastiment de javascript en concret, encara que tenim certa llibertat a l'hora de triar-lo.

En aquest apunt veurem primer Dajaxice i en un següent apunt faré també cinc cèntims de dajax.

Instal·lació

Suposaré com tantes vegades que teniu un virtualenv creat i Django instal·lat. També hem de partir d'un projecte base.

El primer que hem de fer és instal·lar la llibreria, per això bastarà fer un

pip install django-dajaxice

La documentació explica força bé el procés, així que resumeixo:

1. Posar dajaxice dins la secció INSTALLED_APPS de settings.py
2. Assegurar-nos que tenim eggs.Loader descomentat als TEMPLATE_LOADERS
3. Assegurar-nos que django.core.context_processors.request és dins el TEMPLATE_CONTEXT_PROCESSORS, si no ho heu fet ja, el meu consell és que copieu tot el TEMPLATE_CONTEXT_PROCESSORS que hi ha a la documentació, ja que a poc que l'aplicació cresqui segur que necessitareu afegir-ne algun.
4. Afegim als settings.py el prefixe que farem servir per distingir les urls de dajaxice de les de urls normals de la nostra aplicació, per exemple la documentació ens diu posar DAJAXICE_MEDIA_PREFIX="dajaxice".

Amb això ja hem fet par de la fontaneria, ara ve la part més interessant i la màgia d'aquesta aplicació.

Organitzant l'AJAX

Dajaxice el farà és utilitzar el prefixe que hem configurat per tractar certes urls com a cridades AJAX. Djaxice el que ens permet és registrar automàticament les funcions que es publicaran com a cridades AJAX utilitzant un mecanisme semblant al que fa dervir Django per a l'admin.

D'aquesta manera, una vegada modificat l'arxiu urls.py podem anar creant les funcions a publicar dins un arxiu ajax.py i registrar les funcions. Així l'arxiu urls.py ens ha de quedar com:

#!/usr/bin/python

from django.conf.urls.defaults import patterns, include, url
from dajaxice.core import dajaxice_autodiscover
from django.contrib import admin
from django.conf import settings

admin.autodiscover()
dajaxice_autodiscover()

urlpatterns = patterns('',
     url(r'^admin/', include(admin.site.urls)),
    (r'^%s/' % settings.DAJAXICE_MEDIA_PREFIX, 
        include('dajaxice.urls')),
)

Utilitzant AJAX a les nostres plantilles

Dajaxice es capaç de posar dins la nostra plantilla el codi que necessitam per fer les cridades AJAX i publicar les funcions que farem servir a partir del codi Python (ja ho veurem un poc més endavant). Per fer-ho fa servir una llibreria que s'ha de carregar.

Així a la part de càrrega de llibreries de la nostra plantilla haurem d'afegir: dajaxice_templatetags. Si encara no heu carregat cap llibreria doncs quedaria com {% load dajaxice_templatetags %}.

Una vegada carregada la llibreria posarem el tag que genera el codi javascript {% dajaxice_js_import %}. Ho podeu posar a la capçalera o al peu de la plana. Personalment, com que ho sol fer servir junt amb jQuery, ho pos al peu, abans de l'utilització de les llibreries, per tal de millorar la velocitat de càrrega de les planes.

Aquest codi es gener dinàmicament mentre estam desenvolupant. Us avís que de tant en tant es queda carregat en memòria i certs canvis requereixen reiniciar el servidor de desenvolupament. Si veis que heu publicat una funció i no surt, reiniciau el servidor.

En producció la llibreria té una opció per generar directament l'arxiu javascript i poder tractar-lo com un fitxer estàtic més.

L'estructura d'una plantilla bàsica amb djaxice seria doncs

{% load dajaxice_templatetags %}

<html>
  <head>
    <title>My base template</title>
    <!-- també al peu depen de l'aplicació -->
    {% dajaxice_js_import %} 
  </head>
...
</html>

Creant la nostra primera cridada AJAX

Com us comentava més amunt, una de la gràcia de dajaxice és que ens permet organitzar les nostres cridades AJAX. Així el que farem serà crear un arxiu ajax.py dins la nostra aplicació, de manera que podem agrupar cridades per aplicació.

Suposem que hem creat una aplicació anomenada main, la posam al settings.py del projecte i cream l'arxiu ajax.py

Crear una funció i publicar-la per a que la servim via AJAX és tan senzill com això:

#!/usr/bin/python
# -*- coding: utf-8 -*-

from django.utils import simplejson
from dajaxice.decorators import dajaxice_register

@dajaxice_register
def hello_world(request):
    return simplejson.dumps(
        {'message':'Hello World'})

És a dir, importam simplejson per a fer la transformació cap a json, que és el que volem servir (o xml, o html, tant fa), cream una funció com ho feim al views.py de Django i la decoram amb
dajaxice_register. Això junt el autodiscover que hem posat a urls.py fa que ara la nostra aplicació pugui respondre a cridades AJAX.

Cridant des de l'html

Per cridar a la nostra funció es pot fer directament amb l'event onclick directament a l'HTML,però a mi particularment em fa molta grima tenir aquesta mescladissa, així que prefereixo tirar de jQuery encara que per fer la crida AJAX no el faci servir. Recordem que l'important no és el mètode amb que es fa la crida, sinó l'organització i facilitat de mantenimient (i depuració) que ens dóna la llibreria.

Així, en el meu cas quedaria:

<script src="https://ajax.googleapis.com/
    ajax/libs/jquery/1.7.1/jquery.min.js">
</script>
<script type="text/javascript">
    $(function(){
        $('#testme').click(function(event){
            event.preventDefault();
            Dajaxice.main.hello_world(test_callback);
        });

        function test_callback(data){
            if (data==Dajaxice.EXCEPTION){
                alert('Opps, alguna cosa dolenta ha passat');
            } else {
                alert(data);
            }
        }
    });
</script>

on #testme fa referència a un enllaç al qual hem assignat l'event.

L'interesant d'això és que tenim a la nostra disposició una funció javascript que mapeja la que tenim al codi Python i a la qual podem cridar amb uns paràmetres. El primer d'ells és la funció de tornada (el callback) que utilitzarem per gestionar la resposta i l'altra és un paràmtre codificat com json que passarà com a paràmetre cap a la funció.

Hem de dir que dajaxice sempre fa un POST contra la url, gestionant els problemes de CSRF.

Si posam DAJAXICE_DEBUG=True al settings.py o millor dit, ve així per defecte, a la consola de desenvolupament de Django podem veure tant la cridada que fem com la resposta i els errors que hi pugui haver.

La funció de tornada es defineix amb un paràmetre que contindrà el valor de retorn de la nostra cridada AJAX. Si és un json podrem accedir als valors directament, però com he comentat abans, no estam limitats a tornar json, podem tornar una cadena de text, xml, html, ... el que necessitem i poguem tractar amb javascript.

És interessant veure com es tracten els errors o les excepcions. Si hi ha problems al nostre codi Python i es llança una excepció, dajaxice la capturarà i llavors data contindrà el valor Dajaxice.EXCEPTION, amb la qual cosa sabem que quelcom ha anat malament.

He de fer servir sempre Dajaxice?

Depèn, algunes vegades serà més convenient fer una cridada directa amb jQuery, per exemple quan volem tenir més control del que passa quan s'inicia la cridada, o volem poder-la cancel·lar.

El cert, però, és que dajaxice ens permet organitzar millor el codi i gestionar d'una manera sistemàtica les nostres cridades AJAX. Com sempre no hi ha cap veritat absoluta, potser servirà en el 80% dels casos i això ja significa una gran ajuda.

Avui he acabat de llegir "Un creuer fora de sèrie" de Sílvia Soler, de l'editorial Columna.

És una petita història del viatge en un creuer de Maria i Oriol i la seva extensa família (de l'estil de Modern Family) i de les conseqüències més immediates que se'n deriven.

Relacions de parella, adolescents i la vida mateixa amb les seves complexitats retratada de manera molt divertida i refrescant per la Sílvia Soler, en un llibret de 155 planes que et deixa en acabar amb ganes de saber-ne més d'aquesta família, com si d'un culebrot es tractàs.

M'ho he passat molt bé llegint el llibre. de tant en tant els fills em demanàvem perquè reia, així que ja us podeu imaginar que és un llibre entretingut. Potser les rialles eren per veure'm reflectit en algunes situacions, vet a saber, però la cosa és que és un bon llibre per passar una estona tranquil, gaudir de la lectura i desembafar dels conflictes quotidians submergint-se en els conflictes un tant estrambòtics d'altres.

En el temps que corren amb aquest títol hom podria pensar que es tracta d'un llibre que tracta de la crisi del bloquet i de la construcció. Res més lluny de la realitat.

A la contraportada diu que és un novel·la irònica, inquietant, "segurament la novel·la més divertida d'Ian McEwan". Bé, si aquesta és divertida no em vull imaginar com seran les altres.

M'ha costat molt acabar e llibre, res a dir de l'estil i la narració. Tant l'autor com el traductor crec que han fet una bona feina, però la història no m'ha enganxat gens ni mica. Certament té grans dosis de mala llet quan retracta els organismes oficials i projectes que es creen sols perquè el polític de torn vol sortir a la foto. I la figura de Beard, un premi Nobel al qui li encanten les dones i figurar. Però tot i aquesta dosi d'ironia, és tot un tant inconnex, les històries es queden a mig desenvolupar.

En definitiva, un llibre per llegir quan a un no li ve el son, que és el que va aconseguir que ahir l'acabàs, però que no respon a les expectatives que m'havia creat amb la publicitat que en feia el Círculo de lectores.

Fa temps que estic fent feina a hores mortes amb un projecte que m'ajudi (que ens ajudi) en el nostre desenvolupament d'aplicacions, en una de les tasques més ingrates: tenir que testejar l'aplicació i afegir dades de prova.

Un dels projectes amb que estic jugant és SST un envolcall per Selenium que fa molt senzill fer scripts per testejar webs des del navegador i de manera desatesa. He fet les proves inicials i la veritat és que promet molt el projecte.

En aquests moments tenim moltes de les nostres aplicacions monitoritzades fent servir Twill i connectades a Nagios, de manera que podem saber quan l'aplicació cau o no dóna la resposta esperada i que ens avisi mitjançant una alarma de Nagios. SST no està cridat a substituir Twill de moment, però si que ajudarà molt a evitar repeticions de tasques ja que és força més àgil que Selenium, i al meu punt de vista més entenedor.

L'altra línia de treball va dirigida a la tasca de generar dades de prova per les aplicacions. Supòs que també us heu vist amb la necessitat de testejar una aplicació en condicions semblants al que ens podem trobar a la realitat, i això vol dir omplir la base de dades amb cents o mils d'usuaris, d'adreces, ...

Vaig estar cercant eines que em deixessin fer això però no vaig trobar res que m'agradàs totalment, així que vaig optar per l'opció del mig, és a dir, tenir un bon conjunt de funcions que pugui cridar quan vulgui, que pugui créixer sense massa problemes i que pugui utilitzar per fer els programets per omplir de dades les meves aplicacions. Així va néixer Fakedata.

Fakedata és un conjunt més o manco organitzat de funcions per generar dades aleatòries però amb criteri per a les aplicacions, orientat sobretot a Espanya. Hi ha funcions per a generar noms de persona, per a generar CIF, NIF, nombres de telèfon, codis postals, targes de crèdit, ... El gruix de rutines les he anat trobant d'Internet o a altres llibreries i les he pogut adaptar, algunes les he creat des de zero. Em sembla bona idea tenir-ho tot organitzat, agrupat i a un únic punt, de manera que es pugui fer servir ràpidament.

Amb la mateixa idea de testejar aplicacions he afegit un mòdul nou al projecte anomenat Faketpv, amb la idea d'emular les principals passarel·les de pagament espanyoles. De moment ja tinc CECA i SERMEPA.

La idea és que quan estam en mode desenvolupament tenir que connectar a les passrel·les de pagament, encara que sigui al seu entorn de test, et fa perdre un temps preciós i sovint dificulta la depuració. Faketpv està pensat per ajudar al desenvolupament: mostra els paràmetres que reb el TPV i torna a generar la signatura per a que es pugui comparar amb la que generaria el TPV si li passàsim aquests paràmetres. A més retorna la resposta com si la venda s'hagués produït realment, sense tenir que posar cap tarja i fent-ho tot en local.

Com que funciona com a un servei es pot fer servir des de qualsevol aplicació, talment seguint la documentació de cada passarel·la però substituint el seu entorn de test per l'aplicació local.

El projecte està a Bitbucket i està obert a contribucions. A veure si entre tots en feim un de bo.

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.

En aquesta tercera entrega veurem com podem fer que des de la nostra aplicació Django es puguin generar i servir els arxius que hem generat amb la llibreria xlwt.

La mecànica és la mateixa que la que hi ha als tutorials de Django que mostren com servir un arxiu csv o un pdf, així que per a que serveixi d'alguna cosa més us mostraré como ho feim utilitzant les generic class views incorporades a Django 1.3.

El que volem fer és poder mostrar els resultats per pantalla i després poder afegir un link que ens retorni les dades que tenim en pantalla en forma d'arixu descarregable.

ListView

Per el nostre propòsit farem servir la classe ListView que es troba a django.views.generic

La utilització més típica d'aquesta classes implica sobreescriure el mètode get_query_set de tal manera que ens retorni les dades que mostrarem a la plantilla, i, com no, indicar-li el nom de la plantilla a la qual s'han de mostrar els resultats.

El codi seria quelcom semblant a això per la part de views.py

class TestView(ListView):
    """Classe de proves per l'article"""

    template_name='tests/user_list.html'

    def get_queryset(self):
        """Listam tots els usuaris que no són superusuaris"""

        return User.objects.filter(is_superuser=False)

a l'arxiu urls.py crearem la url que apunti a la nostra classe, afegint

url(r'^test/$', TestView.as_view(), name='trespams-test'),

i important TestView des del mòdul views.py

la plantilla

{% extends "base.html" %}

{% block main %}
<table>
    <a href="{% url trespams-test %}?exporta=1">Exporta</a>
    {% for user in object_list %}
    <tr>
        <td>{{user.username}}</td><td>{{user.email}}</td>
    </tr>
    {% endfor %}
</table>
{% endblock %}

A la plantilla com podeu veure hi ha un object_list que no hem definit enlloc. Això ho fa la pròpia classe, que passa tot el que ve del get_querset al contexte de la plantilla dins una variable anomenada object_list. Podem canviar aquest nom si no ens agrada.

<a href="{% url trespams-test %}?exporta=1">Exporta</a>

Hem definit un enllaç que apunta a la mateixa url i per tant a la matea vista, però afefint-hi un paràmetre que ens indicará que el que volem no és tornar a generar la plana sinó exportar el fitxer.

Si creau una aplicació de proves i provau el codi veureu que encara no fa res, tranquils, ara hi anam...

Canviam la renderització

El gran avantatges de les class views és que estan construïdes de manera molt modular, de manera que podem sobreescriure tot allò que convingui per a modificar-ne el comportament.

En el nostre cas volem que es renderitzi un contingut o un altre segons tinguem o no un paràmetre concret a la url, i per axiò el que farem serà sobreescriure el mètode render_to_response

class TestView(ListView):
    template_name='tests/user_list.html'

    def get_queryset(self):
        return User.objects.filter(is_superuser=False)

    def render_to_response(self, context, **response_kwargs):
        if self.request.GET.get('exporta'):
            return self.render_to_fitxer(context, **response_kwargs)
        else:
            return super(TestView, self).render_to_response(context,
                **response_kwargs)

El que deim és, si hi ha el paràmetre exporta al GET llavors fas un render_to_fitxer (que encara no hem definit), en cas contrari, fas el que es suposava que havies de fer.

Definim el render_to_fitxer

Ja sols ens queda definir el render_to_fitxer per fer que enlloc de l'HTML obtinguem un arxiu

class TestView(ListView):
    template_name='tests/user_list.html'

    def get_queryset(self):
        return User.objects.filter(is_superuser=False)

    def render_to_fitxer(self, context, **kwargs):
        "Sortida cap a un fitxer xls"

        import xlwt
        from django import http

        response =  http.HttpResponse(
            content_type='application/vnd.ms-excel; charset=utf-8',
            **kwargs)
        response['Content-Disposition'] = 'attachment; filename=usuaris.xls'
        usuaris = self.get_queryset()
        wb = xlwt.Workbook()
        ws = wb.add_sheet('usuaris')
        fila = 0
        for usuari in usuaris:
            ws.write(fila, 0, usuari.username)
            ws.write(fila, 1, usuari.email)
            fila += 1
        wb.save(response)
        return response

    def render_to_response(self, context, **response_kwargs):
        if self.request.GET.get('exporta'):
            return self.render_to_fitxer(context, **response_kwargs)
        else:
            return super(TestView, self).render_to_response(context,
                **response_kwargs)

Els imports que hi ha al mètode render_to_fitxer poden estar a la capçalera del mòdul perfectament, els he posat aquí per mostrar explícitament els mòduls que es necessiten dins el mètode.

De la resta de codi, fixau-vos com podem modificar les capçaleres de resposta per indicar que el que volem és generar un arxiu el content_type del qual és de tipus excel i que ho tornarem en format utf-8.

A més al Content-Disposition hem indicat que el contingut es servirà com a un adjunt i amb un nom específic.

Per a la generació de les dades hem reaprofitat get_querset, tanmateix el que volem és el mateix que hi ha en pantalla. Es pot arribar a optimitzar per posar el contingut dins una caché i evitar que es torni a repetir la consulta, però això és una optimitzaició prematura.

Finalment, cal notar que no es genera un arxiu temporal, sinó que la resposta, que tenim dins la variable response és comporta ella mateixa com si fos un fitxer. És la màgia del duck typing.

I això és tot! Fins la propera!

A l'article anterior havíem fet un petit "hello world" en format xls, ara toca fer alguna cosa més de profit, així que veurem com podem generar un full de càlcul a partir de dades.

En altres temps, quan donava formació ofimàtica, un dels exercicis que feia fer als alumnes quan tocava el tema de les fulles de càlcul era el de fer una taula de multiplicar, serveix per perdre la por a la cosa aquesta dels nombres i mostra els conceptes fonamentals, ara podem fer el mateix. Per no fer-ho molt complicat anem per la taula del dos

#!/usr/bin/env python
#-*- coding: UTF-8 -*-

import xlwt

fmt = xlwt.easyxf

h1 = fmt('font: name Arial, height 200, bold on;')
wbk = xlwt.Workbook()
full = wbk.add_sheet('Taula del 2')
full.write(0, 0, "Taula del 2", h1)
for x in range(1, 11):
    full.write(x, 0, 2)
    full.write(x, 1, "x")
    full.write(x, 2, x)
    full.write(x, 3, "=")
    full.write(x, 4, xlwt.Formula('A%s*C%s' % (x+1, x+1)))
wbk.save('taula.xls')

Podem veure com hem creat fàcilment una fórmula per a fer la multiplicació. També podem veure com per posar les fórmules hem de tenir en compte que s'ha de fer en la notació de files i columnes pròpia de les fulles de càlcul, és a dir, les columnes s'anomenen a partir de la lletra A. Això xoca un tant amb tot el maneig de la llibreria que utilitza una notació de coordenades o la l'origen està en la cel·la superior esquerra.

Per tractar amb això la llibreria proporciona un mòdul anomenat Utils que ens proporciona les eines per fer les transformacions entre la notació de fulla de càlcul i la notació de coordenades de la llibreria.

#!/usr/bin/env python
#-*- coding: UTF-8 -*-

import xlwt

fmt = xlwt.easyxf

h1 = fmt('font: name Arial, height 200, bold on;')
wbk = xlwt.Workbook()
full = wbk.add_sheet('Taula del 2')
full.write(0, 0, "Taula del 2", h1)
for x in range(1, 11):
    full.write(x, 0, 2)
    full.write(x, 1, "x")
    full.write(x, 2, x)
    full.write(x, 3, "=")
    num = xlwt.Utils.rowcol_to_cell(x, 0)
    taula = xlwt.Utils.rowcol_to_cell(x, 2)
    formula = xlwt.Formula("%s*%s" % (num, taula))
    full.write(x, 4, formula)
wbk.save('taula.xls')

Formats

Quan tractam amb informació és important a més de presentar-la, fer-ho en un format entenidor. Els fulls de càlcul ho fan prou bé a això, i des de fa molt temps tenen la capacitat de presentar-nos les dates en formats legibles i no en el seu format intern, i les quantitats numèrics ben formatejades, per exemple.

Amb la llibreria xlwt podem utilitzar els formats de cel·la de la fulla de càlcul, podeu consultar-los anant a les propietats d'una cel·la o bé fer una ullada a l'exmemple num_formats.py que ve amb la llibreria.

#!/usr/bin/env python
#-*- coding: UTF-8 -*-

import xlwt
import decimal
fmt = xlwt.easyxf

wbk = xlwt.Workbook()
full = wbk.add_sheet('Caixa')
moneda = fmt('font: name Times' ,
              num_format_str=u'#,#0.#0 "€";[Red]-#,#0.#0 "€";')
full.write(0, 0, decimal.Decimal("11133"), moneda)
full.write(0, 1, -3939.93, moneda)
wbk.save('nombre.xls')

A l'exemple podem veure com xlwt tracta perfectament tant el format numèric sencer (o float) com el Decimal.

De la mateixa manera podem fer feina amb diferents formats de dates o formats de temps.

#!/usr/bin/env python
#-*- coding: UTF-8 -*-

import xlwt
import datetime
fmt = xlwt.easyxf

wbk = xlwt.Workbook()
full = wbk.add_sheet('Avui')
data = fmt(num_format_str=u'D MMM YYYY')
full.write(0, 0, datetime.date.today(), data)
wbk.save('dates.xls')

Ho deix aquí per avui, a la propera entrega veurem com passar tot això la web i fer que Django ens doni un petit informe creat amb xlwt amb les dades del model.

Una de les coses que volia que l'aplicació de gestió de comunitat de propietaris que fem és la de tenir algun tipus de via per a poder exportar la informació introduïda. D'aquesta manera el client no està captiu i les seves dades són realment seves, però a més també volia que aquesta informació es presentàs de manera que també pogués ser útil.

El format csv està prou bé, però és massa simple a l'hora de presentar les dades. Necessitava quelcom del format del qual fora prou potent per poder aplicar estils i format bàsic, i al mateix temps que no implicàs una despesa addicional per al client.

Cercant, cercant vaig arribar a la llibreria xlwt. Aquesta llibreria permet crear fitxers en format xls (Excel) d'una manera prou senzilla i ràpida com per a ser just el que necessitàvem. El format es pot llegir tant mitjançant aplicacions privatives, que de d'aquí no recomanaré, o des d'aplicacions lliures com l'OpenOffice o LibreOffice.

Per a qui vulgui saber-ho tot podeu fer una ullada al codi font, però si us conformau amb un poquet menys, podeu llegir-vos el tutorial. Si voleu anar per feina podeu seguir llegint i us ne faré cinc cèntims de la llibreria.

Hello world

El primer que hem de fer és instal·lar la llibreria. Així que si no heu instal·lat pip ja tardau i després no deixeu de fer el mateix amb el virtualenv i el virtualenvwrapper, ja que sempre, sempre, farem feina des d'un entorn virtual.

Així doncs:

mkvirtualenv fc
workon fc
pip install xlwt

El que farem serà crear un full de càlcul amb les paraules "Hello world" a la primera cel·la (A1)

#!/usr/bin/env python
#-*- coding: UTF-8 -*-

import xlwt
wbk = xlwt.Workbook()
full = wbk.add_sheet('full 1')

full.write(0,0,'Hello world')
wbk.save('hello.xls')

Ja està! Hem importat la llibreria, creat el llibre, afegit un full que hem anomenat "full 1" i segidament escreit a aquest full la frase mítica.

Podem afegir tans fulls com volguem sense problemes, però ens hem de fixar bé que la cel·la A1 correspon a les coordenades zero, zero del full de càlcul.

Un poc de format

Podem aplicar estils a una cel·la fent servir dos mètodes: podem utilitzar la classe XFStyle que ens permet crear l'estil dessitjat pas a pas, o bé aplicar un format molt més legible pels humans i molt més proper al que seria un full d'estil css: easyxf

En aquest article faré servir aquest darrer mètode, ja que està prou ben documentat i com us dic, és molt més legible. Així, el que faré serà fer que el nostre "Hello world" es present un poc més vistós.

#!/usr/bin/env python
#-*- coding: UTF-8 -*-

import xlwt

fmt = xlwt.easyxf

h1 = fmt('font: name Arial, height 400, bold on;')
wbk = xlwt.Workbook()
full = wbk.add_sheet('full 1')
full.row(0).height = 800
full.write(0,0,'Hello world', h1)
wbk.save('hello2.xls')

He creat un estil anomenat h1 amb font Arial i negreta. L'alçada l'he posada com a 400, és a dir 20px. Com a base preneu que un tamany de font 200 equival a una alçada de 10px.

Com que volem que la fila tengui més alçada que la font, hem establert la propietat height de la fila a 800.

Això és tot per avui, al proper article (demàs segurament) ja un full complet, amb format numèric i alguna fórmula.

Aquesta setmana és obligat parlar del llançament de propietariosonline.com, una aplicació web per a la gestió de comunitats de propietaris que hem llançat des d'APSL. Junt amb la web de trobacasa forma el gruix dels projectes propis. Actualment estam en fase beta, és a dir, mirant de netejar tots els possibles errors que puguin haver passat els nostres testeigs inicials i sobre tot, copsant les opinions dels beta-testers, per tal d'anar incorporant els suggeriments de millora que ens facin. Personalment una de les coses que més em motiven a l'hora de fer un programa és que aquest sigui útil, i per això res millor que fer-lo en col·laboració amb els usuaris potencials del programa.

Com que supòs que no llegiu això per a que us parli de la gestió de les comunitats de propietaris, aniré entrant en matèria.

L'aplicació està desenvolupada amb Django en la seva versió 1.3. És la primera aplicació grossa en la que feim un ús intensiu de les generic class views. Com molts sabreu abans de la versió 1.3 la manera de passar del la petició (el request) cap a la sortida html era mitjançant una funció que es posava a l'arxiu views.py. Amb la versió 1.3 això també es pot fer, però hi ha la possibilitat de que aquestes funcions siguin classes.

Per una aplicació com propietariosonline això ha significat poder fer herència de classes i reutilitzar moltíssima funcionalitat. Ahir llegia un apunt on un usuari de Django es queixava que la quantitat de codi escrit utilitzant les classes era major que sols utilitzant les funcions. En casos puntuals potser veritat, però quan es pot fer ús de l'herència, la reutilització de codi i sobretot l'estructuració que tens compensa de sobres tenir que aprendre una nova manera de fer les coses.

Com es tracta d'un projecte propi, hem aprofitat per fer experiments i provar noves utilitats i llibreries. Ja se sap, els experiments a casa i amb gasosa, així que res millor que un projecte com aquest. Es prou gran com que l'experiència sigui extrapolable a altres projectes i no hi ha la pressió externa que representa un client que està pagant per hores.

Una de les llibreries que hem utilitzat és django-tables2 que ha significat passar de crear les taules de dades amb html a utilitzar codi Python per a enllaçar estructura i visualització. A l'aplicació es fan servir molts llistats tabulats i aquesta utilitat ens ha permès reutilitzar estructures de taula, definir formats de columnes i sobretot estalviar-nos una gran quantitat de codi HTML. De retruc les modificacions també són més senzilles, ja que per exemple modificar com apareixen les quantitat numèriques és tant senzill com modificar un tipus de columna que hem definit amb Python. Per exemple, per posar un check hem definit una columna com:

class BooleanColumn(Column):
    def render(self, value):
        valor = "on" if value else "off"
        return mark_safe('<img src="%s/img/check-%s.png" />' \
           % (settings.STATIC_URL, valor))

D'aquesta manera quan a un llistat es necessiti un camp booleà utilitzarem aquest tipus de columna. Si pel que sigui volem canviar com es presenta doncs no hem d'anar taula a taula a fer els canvis, sinó que podem anar directament al tipus de columna.

Una altra de les utilitat que hem fet servir es diu Sentry una utilitat que utilitza la gent de Quora per a monitoritzar els errors 500 i logs d'error. Fins ara aquests tipus d'errors els controlàvem amb els missatges d'e-mail que ens envia la pròpia aplicació de Django. El problema amb això és que no escala bé. L'altra dia de pagès ens trobàrem amb un problema on això es veu perfectament:

Un dels nostres clients està connectat amb una web amb molt tràfic que li envia peticions. Aquesta web va sofrir un atac i va començar a enviar peticions mal formades a tort i dret, i un dels afectats va ser el nostre client. Una de les màximes de Python és que les excepcions no ha de passar desapercebudes, així que personalment program de manera que si una cosa no ha de petar i peta, doncs me'n vull assabentar. Això va fer que rebéssim milers de missatges en poques hores. L'aplicació no es va veure afectada, però la bústia d'avisos feia goig! Al mateix temps un altra client va tenir una petada a l'aplicació, que també va enviar el corresponent e-mail. En condicions normals haguéssim vist l'error i l'haguéssim pogut solucionar en pocs minuts, però l'avís es va perdre entre els milers de missatges anteriors i no ens n'adonàrem fins passats un dia o dos. És veritat que es pot configurar el sistema de correu per a que distribueixi els missatges per client i per aplicació, però en condicions normals això no es tan còmode com tenir-ho tot centralitzat a un punt.

Aquí és on Sentry ens soluciona la vida. Hem configurat una aplicació amb Sentry que centralitza tots els missatges d'error. D'aquesta manera a la consola sols apareix el missatges i el nombre de vegades que s'ha produït l'error. Així encara que es produeixi una situació com la que explicava és molt més difícil que l'error passi desapercebut, ja que cada error idèntic s'agrupa dins Sentry. A més el format de visualització dels errors és fantàstic, molt semblant a com Django presenta els errors en mode depuració, la qual cosa fa que identificar el problema sigui encara més fàcil.

Propietariosonline va servir com a excusa i experiment, però a hores d'ara ja tenim el client de Sentry instal·lat al 90% de les aplicacions i la consola de Sentry com a una eina fonamental de monitorització, sols comparable en utilitat a Nagios en la monitorització de sistemes.

La resta d'utilitats que hem fet sevir ja són vells coneguts: django-nose per als tests unitaris, django-redis-cache, south, sorl-htumbnail, django-debug-toolbar, django-extensions, ipdb, robots etc. no s'han convertit en part fonamental de les nostres aplicacions.

Hores d'ara duim un mes just de dedicació al projecte. Fet i fet podem dir que hem dedicat dues persones a temps complet durant un mes. De fet és un poc menys, ja que hem fet manteniment d'altres projectes, però si sumam la feina de maquetació de la web principal i la feina de sistemes, doncs els resultat és si fa no fa aquest: 2 mesos-home de dedicació (encara que diferents perfils).

Posem-hi xifres! He utilitzat el programa cloc per comptar les línies de codi. He llevat la totalitat de codi javascript i css (i less), ja que fonamentalment hem utilitat llibreries jQuery i el bootstrap de twitter, el resultat és:

285 text files.
282 unique files.
1348 files ignored.

http://cloc.sourceforge.net v 1.53  T=1.0 s (248.0 files/s, 19589.0 lines/s)
-------------------------------------------------------------------------------
Language          files     blank   comment      code    scale   3rd gen. equiv
-------------------------------------------------------------------------------
Python              147      1593       872     11995 x   4.20 =       50379.00
HTML                 90       298        32      4088 x   1.90 =        7767.20
XML                  11         7         0       704 x   1.90 =        1337.60
-------------------------------------------------------------------------------
SUM:                248      1898       904     16787 x   3.54 =       59483.80
-------------------------------------------------------------------------------

És interesant veure que aquesta eina (encara que agafat amb pinces) ens dóna també l'equivalent en línies de codi si haguéssim fet servir un llenguatge de programació menys potent que Python. Donat que el nombre de línies de codi que pot escriure un programador és constant, llavors això vol dir que el mateix programa d'haver-ho fet en un altra llenguatge ens hagués duit 4 vegades més de temps. Per pensar-hi!

A la part de sistemes hem aprofitat també per potenciar el Fabric per a tota la gestió i desplegament de l'aplicació, que corre amb uWSGI i ngnix. Això ens permet pujar modificacions a diari, mantenint el cicle d'entorns de desenvolupament, preproducció i producció.

Encara hi ha coses que es poden millorar (de fet sempre n'hi haurà). Quan l'economia ens ho permeti volem incorporar un servidor per a la integració contínua, però a poc a poc esperam anar arribant-hi. M'agrada pensar que hem aconseguit un procés de millora contínua, on a cada projecte aconseguim tenir les coses millor que al projecte anterior i anar incorporant el que hem après també a les aplicacions que ja hi ha en producció.

Si tot això tindrà viabilitat econòmica i ens permetrà sobreviure com a empresa el temps ho dirà. Però el que sempre he tingut el convenciment que conformar-se i no aspirar a millorar sols duu a l'empobriment espiritual i és tan perillós o més que el risc que corres intentant millorar.

Fa un grapat de setmanes que no escric res a aquest blog, tenc moltes coses pendents, però entre unes coses i altres el temps va passant i fins avui no he trobat una estona per a tornar-hi.

Han estat unes setmanes molt estranyes: problemes personals, alguns bons, com les noces de la germana i altres no tan bons, molta feina i com no, el començament de l'escola dels menuts i la festa de la Vermada que ja és aquí.

En el terreny de la feina tenc dues bones notícies: hem posat ja en producció un projecte que em fa una especial il·lusió txerpa i una web presencial fiscontrol.

txerpa és un projecte que hem desenvolupat per a una coneguda gestoria/assessoria de l'illa. Integra una web, un backoffice per a la gestió d'empreses via OpenERP i la integració amb el mateix OpenERP de manera que es poden crear molt fàcilment instàncies personalitzades per a poder dur una comptabilitat i gestió.

El projecte des del punt de vista tècnic ha estat molt engrescador. És un projecte amb un llarg recorregut en el qual esperam poder-hi afegint millores i nova funcionalitat. L'interessant, però, és veure que des d'aquestes illes nostres iniciatives com aquestes poden tirar endavant. Django i Python han permès que la integració dels diferents serveis que integren la plataforma es pogués fer d'una manera ràpida, mantenible i escalable.

Fiscontrol és un altre projecte que ha vist la llum aquesta setmana de manera oficial. En aquest cas és una web presencial, però ens ha fet il·lusió ja que és un projecte on el feeling amb el client ha estat molt bo i on les incorporacions del client han estat sempre per millorar el resultat final (ja sabeu que això no sempre passa). És de les poques webs on s'han demanat n idiomes i s'han posat continguts en aquests idiomes. En fi, que tot i que el projecte no té un component tècnic novetós, sí que ens hem divertit molt fent-la i veient els resultats.

Ja és la nostra tercera web d'assessoria, pareix que ens estam començant a especialitzar :)

Esper que en les properes setmanes hi haurà més novetats (com sempre en forma de projectes Django), ja que tenim un grapat de webs pendents de sortir.

Com sabeu els que us dedicau a la informàtica en el sector turístic, els mesos de temporada alta turística són mesos de temporada baixa en informàtica. He aprofitat aquest mig gas per engrescar a la gent d'APSL (o emmarronar-los, vet a saber) en un projecte propi. Permeteu-me de moment que us mantengui a l'espera de més notícis. L'interessant és que el projecte l'hem fet ja amb les noves generic class views de Django, incorporades a la versió 1.3.

En aquest projecte hem pogut veure la meravella de les class views, com tot el codi ens queda molt més compacte, com es pot aprofitar l'herència de vistes per escriure molt menys codi (sí, encara menys!).

De les class views en vull escriure un bon apunt un dia d'aquests. La documentació de Django que hi ha i els posts que he trobat sols fan referència al TemplateView, però la potència dels views de Forms, d'edició i borrat no s'han de menystenir. Així que es cosa de trobar-ne el temps per escriure l'apunt/tutorial i fer el codi d'exemple.

Per cert, que aquest blog ja corre damunt un altre servidor. Abans ho feia a un servidor dual core amb 2 Gb de RAM, però fa unes setmanes hem començat a migrar-ho tot a un servidor molt més potent, un i7 quadcore amb 12 Gb de RAM. Pingdom diu que la renderització ha passat de 4 segons a 1.5 segons. No he canviat el codi, sols és l'efecte d'un servidor que va més sobrat i d'una optimització de l'arquitectura: hem passat del WSGI de CherryPy que hi havia a l'inici al WSGI de uWSGI, de tenir la caché a memcached a tenir-la a Redis.

En Bernat ha fet molta feina deixant un entorn molt optimitzat per a les aplicacions Django. Tant que estam pensant en oferir un hosting gestionat per la gent que desenvolupi aplicacions Django i necessiti un entorn ben afinat. Temps al temps. El que tinc clar és que no vull que facem un projecte tipus Gondor, sinó quelcom on el valor afegit sigui la disponibilitat d'un tècnic de primer nivell com Bernat per a poder deixar ben fina l'aplicació.

Res, això és tot, i que no és poc.

Ja fa un bon grapat de setmanes que vaig comprar el Kindle DX d'Amazon. Vaig elegir el model gran, més pesat i no tan actualitzat com el model petit, ja que la meva intenció era fer servir el lector per llegir documents en PDF.

En aquest temps he pogut comparar amb amics la diferència entre llegir un Pdf a un lector petit o al DX i he de dir que estic content de la compra feta. Amb el DX no s'ha de fer cap tipus de conversió, les planes es llegeixen bé i no hi ha scroll vertical.

Això, però té un cost. El DX sols té connexió 3G i no WIFI, amb la qual cosa està limitat en la navegació que es pot fer. No pots anar més enllà de la Wikipèdia, ja que en intentar anar a altres planes et sortirà l'avís que la navegació està restringida.

L'altra emperò és que els llibres en Pdf no són navegables amb el cursor, això vol dir que no tens a l'abast el diccionari integrat, que va força bé quan llegeixes documentació, el diccionari no et dóna la traducció del terme, sinó la seva definició, amb la qual cosa tens moltes més possibilitats de recordar el terme per a la propera vegada.

He provat de comprar a Amazon i és veritat que és molt còmode, la compra és fa gairebé impulsiva. També hi ha un emperò, que en aquests moments els llibres tècnics tenen un preu a vegades superior als llibres en paper. Sols els salva que al manco els pots comprar sense problemes, cosa que no es pot dir de les llibreries que hi ha a les nostres contrades.

He comprat també a O'Reilly, aprofitant la seva política de promocions per Twitter. Tenen un format compatible amb Amazon i que no té DRM. El vaig provar comprant "Redis Cookbook" i funciona perfectament amb el diccionari integrat i tot.

L'altra cosa que he anat provant és la conversió d'algún pdf a format ebook amb Calibre, queda un format legible però en molts de casos el resultat no compensa l'esforç, encara és més còmode llegir-ho en el format pdf original.

En resum, el DX va molt bé pel que jo volia i les meves necessitats, però s'ha de tenir en compte que Amazon no l'ha actualitzat tan sovint com ha fet amb els dispositius petits, però per llegir documents en format A4 com els pdf va fantàstic, però si sols heu de llegir novel·les segurament el format normal de lector us resultarà més còmode i menys pesat (tant en pes com econòmicament).

With some help of our friend "Google Translate" :)

As we all know that if you want a web application goes faster there is a secret cache as much as you can. Avoid to generate the page each time and search for the content in the database.

To archieve this the today standard is Memcached. Memcached allows us to scale our application a simple way. We can think it as a big hash table, written in C, very fast and with libraries to access to it in almost any language. But thre is e a new competitor in this kind of applications: Redis, and I've already talked about it in the Celery post.

Memcached is an application aimed at dealing with cache, Redis is a noSQL general purpose key-value database in a similar way as Memcached, but with possibilities that go far beyond a cache. Let's see a few differences:

• We can not see the keys we have in Memcached. With Redis can do a search for keys, or see all the command KEYS *

• Redis has persitence.

• Memcached is limited to memory you allocate, Redis can also swapt to disk and just put the keys in memory.

• In Memcached we have no true replication. Redis replication is real and configurable with a simple line.

• Redis is quite configurable, we can define the page size of cache, store to disk, have a password protected database...

• With Redis we can define as many databases as you want. We can clean all the keys in a database without affecting the others.

So the next step is to ask if we could use Redis instead of Memcached for our web applications. Redis plus Django could partially solve one of the biggest problems we have: cache invalidation. As we can have an independent database for each application or for each purpose, we can FLUSHDB the database our application to invalidate the whole cache, or just delete the keys with a single Redis command.

But in Science hypotheses have to be confirmed. So what I did was to build a little sandbox application to see how if Redis was as good as it seems.

The Sandbox

The machines availables to us for the experiment follows:

• Dell Laptop Core 2 at 2:16 GH and 2 GB of RAM with Ubuntu 11:04 This is the Web application server and has the address 192.168.1.35

• Virtual Server Ubuntu 10.04 with 512 MB of RAM on Virtualbox running on the laptop at 192.168.1.38. This server is 32 bit and will host Redis as Memcached.

• Apple PPC 64 Dual Core with 3 GB of RAM, it will launch the tests.

The application is the one I created for creantbits. That is, to run it has to read BD for the last events and presents them in the page.

We will use two of Gunicorn workers to start the application, and we'll test the performance from the PPC with Apache Benchmark

ab -n 1000 -c 5 http://192.168.1.35:8000/

For each test case two consecutive tests are thrown and we discarded the first.

To test the Redis cache we have installed the application django-redis-cache

The test

First we have to determine the starting point. So what we did is to clear our application's cache and see how many requests we get.

no-cache: 120 req / s Mean: 41.4 ms

We set up cache site for Django configured as locmem. Locmem is not recommended in production environments as it can't share the cache, but as before, we used to set the starting point:

locmem: 1380 req / s Mean: 3.6 ms

We configure the the cache as memcached

memcached: 626 req / s Mean: 8.0 ms

Cache Redis configured with persistence to disk

Redis: 623 req / s Mean: 8.0 ms

Cache Redis without persistence. Is the nearest Memcached equivalent.

Redis: 632 req / s Mean: 7.8 ms

We install the hiredis package

Redis: 650 req / s Mean: 7.7 ms

Conclusions

I think the results speak for themselves. If we use persistence Redis is comparable in speed to Memcached, and for the same price we have a NoSQL database at our disposal.

If we don't need persistence Redis shows a 4% improvement over Memcached. This percentage is not significative, but at least we can see that Redis is in the same leage as Memcached.

For me Redis it too good to not use it!

Com tots sabem si un vol que una aplicació web vagi ràpida hi ha un secret: posar en caché tot el que puguem. Evitar tenir que fer càlculs i anar a la base de dades a cercar la informació.

Per fer això l'estàndard avui en dia és Memcached. Memcached ens permet escalar la nostra aplicació d'una manera molt senzilla. És una gran taula hash, del tipus clau valor, escrita en C, molt ràpida i amb llibreries d'accés en pràcticament qualsevol llenguatge.

Però en els darrers temps ha sortit un nou competidor dins les bases de dades de tipus hash, aquest competidor reb el nom de Redis, i ja us n'he parlat quan tractàvem el tema de Celery.

Així com Memcached és una aplicació orientada a tractar amb caché, Redis és una base de dades noSQL de propòsit general, amb format clau-valor com Memcached, però amb unes possibilitats que van molt més enllà de un simple magatzem de memòria. Anem a veure un parell de diferències:

• No podem veure les claus que tenim dins Memcached. Amb redis podem fer una cerca per claus, o veure-les totes amb la comanda KEYS *

• Podem configurar Redis per a que sigui persistent.

• Memcached està limitat a la memòria que li assignem, Redis pot utilitzar també el disc i sols posarà en memòria les claus.

• Memcached no té una vertadera replicació, encara que podem fer que hi hagi molts servidors Memcached. Redis té replicació real i configurable amb una simple línia.

• Redis és força configurable, podem definir el tamany de pàgina de caché, quant guardarem a disc, si volem tenir la base de dades protegida, ...

• Amb Redis podem definir tantes bases de dades com vulguem. Podem netejar totes les claus d'una base de dades sense afectar a les altres.

Amb tot això és lògic demanar-se si enlloc de Memcached no podríem fer servir Redis per a les nostres aplicacions web. Si ho ajuntam amb Django tenim resolt un dels problemes més grans, que és la invalidació de cachés. Separant cada una de les nostres aplicacions dins una base de dades, podem fer un FLUSHDB a la base de dades de la nostra aplicació per invalidar la caché, amb la seguretat que no afectarà a la resta.

Però a la ciència les hipòtesis s'han de confirmar. Així que el que he fet ha estat muntar un petit entorn de proves per veure com se comporta una aplicació senzilla.

L'entorn de proves

El maquinar de que disposam per l'experiment és el següent:

• Laptop Dell Core 2 a 2.16 GH i 2 Gb de RAM amb Ubuntu 11.04 Aquest servidor té l'aplicació web, i té l'adreça 192.168.1.35

• Servidor virtual Ubuntu 10.04 amb 512 Mb de RAM damunt Virtualbox, executant-se damunt el servidor anterior amb l'adreça 192.168.1.38. Aquest servidor és de 32 bits i tindrà tant Redis com Memcached.

• Apple PPC 64 Dual Core amb 3 Gb de RAM, ens servirà com a màquina per a llançar els tests.

L'aplicació és la que vaig fer servir pel creantbits (http://creantbits.com). És a dir, fa un accés a BD per obtenir els darrers esdeveniment i presenta la plana.

Utilitzarem dos workers de Gunicorn per iniciar l'aplicació, i la testejarem des de el PPC amb l'Apache Benchmark

ab -n 1000 -c 5 http://192.168.1.35:8000/

Per a cada test es llancen dos tests ab consecutius i es descarta el primer. Es repeteix 2 pics i es fa la mitja, arodonint cap avall en nombre de peticions per segon.

Per la caché de redis es fa servir l'aplicació django-redis-cache instal·lada des de PyPi.

Inici dels tests

Per començar hem de determinar el punt de partida. Així que el que farem serà desactivar la caché de la nostra aplicació i veure quantes peticions aconseguim.

no-cache    :   120 req/s    Mean: 41,4 ms

Activam la caché per site de Django i posam la caché a locmem. Locmem fa que la caché no pugui ser compartida entre processos i no és un opció recomanada per entorns de producció, però com abans, ens serveix per fixar el punt de partida:

locmem      :   1380 req/s  Mean: 3,6 ms

Posam la caché a memcached

memcached   :   626 req/s   Mean:   8,0 ms

Posam la caché a Redis configurada amb persistència a disc

Redis       :   623 req/s   Mean:   8.0 ms

Configuram Redis sense persistència. És l'equivalent a Memcached.

Redis       :   632 req/s   Mean:   7,8 ms

Utilitzam Redis amb el client hiredis

Redis       :   650 req/s   Mean:   7,7 ms

Conclusions

Crec que els resultats parlen per sí mateixos. Si volem persistència Redis és comparable en velocitat a Memcached, i a més pel mateix preu tenim una base de dades NoSQL en el nostre entorn i a la nostra disposició.

Si no volem persistència Redis supera per molt poc a Memcached i si aplicam totes les optimitzacions per tenir un entorn el més semblant possible a Memcached arribam a un 4% de millora. Aquest tant per cent no és significatiu, però si més no ens serveix per veure que Redis està al mateix nivell de rendiment que Memcached i ve amb tot el paquet d'opcions afegit.

Massa bo per no fer-ho servir!

L'scrapping

Ahir ja vàrem veure quin era el model de dades i el bé que va sorl per a manipular imatges, així com la utilització de la llibreria requests ens quedava veure una altra part important: com agafar el contingut de la web, parsejar-lo i obtenir-ne la informació que necessitam.

Per fer això hi ha diverses utilitats, algunes molt especialitzades com scrappy, i amb més solera és BeautifulSoup. Aquesta llibreria té la qualitat de ser molt permisiva amb l'HTML i hi ha poques planes que no pugui tractar d'una manera o altra.

La plana de Meneame té las notícies de portada dins un div anomenat news-summari, així que el primer que farem serà carregar la plana dins una instància de BeautifulSoup i cercar aquestes notícies.

page = requests.get('http://www.meneame.net')
if page.status_code != 200:
    print "Ups! pareix que hi ha un petit problema"
    return page.status_code
soup = BeautifulSoup(page.content)
noticies = soup.findAll('div', 'news-summary')

amb això BS ens haurà donat tots els divs que tenen la classes 'news-summary' amb la qual cosa ja és sols cosa d'aplicar un tractament semblant per a obtenir la informació de cada notícia

for noticia in noticies:
    titular = noticia.find('h1').text
    texto = noticia.find('p').text
    img = noticia.find('img', 'thumbnail')
    if img:
        src = img['src']
        match_obj = compile_obj.search(src)
        id = match_obj.group('id')
        try:
            NoticiasPortada.objects.get(identificador=id)
        except NoticiasPortada.DoesNotExist:
            print u"Tractant la noticia: %s" % id
            noticia = NoticiasPortada(
                identificador = id,
                texto = texto,
                titular = titular,
                thumbnail = download_image(src,           
                                     'thumb-%s.jpg' % id)
            )
            noticia.save()

El mètode find ens permet a accedir al primer tag que compleix la condició i text ens en dona el contingut. Si com a segon paràmetre hi possam una classe ens retornarà el primer element d'aquell tipus que tengui la classe que li hem donat.

El problema ve quan volem identificar d'alguna manera les notícies. Volem guardar sols les que tenen una imatge. Podem veure que Meneame genera el thumbnail de la notícia amb l'identificador de la mateixa, així que podem fer us d'una expressió regular:

rawstr = r"""(?P<id>\d+).jpg$"""
compile_obj = re.compile(rawstr)

així

src = img['src']
match_obj = compile_obj.search(src)
id = match_obj.group('id')

ens donarà l'identificar de la notícia a partir de la informació de la url de la imatge. Hi ha una utilitat fantàstica per a la depuració i testeig d'expressions regulars anomenada Kodos, no us la podeu perdre.

El toc final

En una aplicació com aquesta la CPU està molt de temps sense fer res, esperant que li arribi la informació. És un bon candidat per a que l'aplicació faci ús dels Threads o del multiprocés. Una de le maneres més senzilles de fer-ho és fent servir la llibreria Queue, d'aquesta manera sols hem de definir quants Threads farem servir en el processament i que aquests consumeixin el contingut (cada notícia) de la cua.

Així el codi final quedaría si fa no fa:

import re
import cStringIO
import requests
from Queue import Queue
from threading import Thread
from BeautifulSoup import BeautifulSoup

from django.core.management.base import BaseCommand
from django.core.files.uploadedfile import SimpleUploadedFile

from t1.models import NoticiasPortada

rawstr = r"""(?P<id>\d+).jpg$"""
compile_obj = re.compile(rawstr)

class Command(BaseCommand):
    """Divertimento. Permet posar les notícies amb foto
    de meneame dins una BD.
    """

    def handle(self, *args, **options):
        page = requests.get('http://www.meneame.net')
        if page.status_code != 200:
            print "Ups! Pareix que tenim un problema"
            return page.status_code

        #cream les coes
        self.q = Queue()
        for i in range(5):
            t = Thread(target = self._importar_portada)
            t.daemon = True
            t.start()

        soup = BeautifulSoup(page.content)
        noticies = soup.findAll('div', 'news-summary')
        for noticia in noticies:
            self.q.put(noticia)
        self.q.join()

    def download_image(self, img_url, filename):
        r = requests.get(img_url)
        if r.status_code == 200:
            return SimpleUploadedFile(content=r.content,
                name=filename,
                content_type=r.headers.get('content-type'))
        else:
            return None

    def _importar_portada(self):
        while True:
            noticia = self.q.get()
            titular = noticia.find('h1').text
            texto = noticia.find('p').text
            img = noticia.find('img', 'thumbnail')
            if img:
                src = img['src']
                match_obj = compile_obj.search(src)
                id = match_obj.group('id')
                try:
                    NoticiasPortada.objects.get(identificador=id)
                except NoticiasPortada.DoesNotExist:
                    print u"Processant la notícia: %s" % id
                    noticia = NoticiasPortada(
                        identificador = id,
                        texto = texto,
                        titular = titular,
                        thumbnail = self.download_image(src, 
                          'thumb-%s.jpg' % id)
                    )
                    noticia.save()
            self.q.task_done()

I això és tot, com sempre amb Python l'explicació sol ser molt més llarga que el codi a executar, fins i tot amb els fils.

Esperant que us hagi agradat el divertimento.

L'altra dia estava fent una aplicació web part de la qual consisteix en aprofitar els continguts de la web anterior, continguts als que no tenim accés directe.

La part de text va ser senzilla, però obtenir una imatge de la web i associar-la a un model Django va resultar una mica més interessant del que suposava. Tant que vaig pensar que potser convenia posar-ho en forma d'apunt.

Per posar-ho en context vaig començar a fer una aplicació Django, la qual tenia que obtenir la imatge i guardar-la, però ja que hi era, vaig voler fer quelcom més educatiu, així que l'aplicació es va anant transformant amb codi per a descarregar-se les fotografies associades a la plana principal de meneame. Si provau el codi mirau de canviar la url que ja que amablement Ricardo em va dir que no hi havia problema en fer algunes proves, tampoc és cosa que anem putejant la web.

Així doncs, aquest apunt serà un poc mescladissa d'utilitats, d' screen scrapping, de thread, processos i altres herbes. Miraré d'anar a poc a poc, però ja us aviso que hi ha de tot i molt!

Definim el model

El més habitual quan hom tracta amb imatges és tenir-ne que fer algun tipus de conversió, si més no per presentar-les a l'administrador de Django. És tan habitual que quan he de fer servir un camp ImageField de Django ja ho converteixo directament a un camp ImageField d'una llibreria que va ideal per a la manipulació d'imagtes sorl.thumbnail.

Així doncs, el nostre model serà molt senzill, tindrà un identificador per poder distingir les notícies, el titular, el texte de la notícia i com no la imatge.

M'ha queda talment així:

!/usr/bin/env python
# -*- coding: UTF-8 -*-
from django.db import models
from sorl.thumbnail import ImageField
from sorl.thumbnail import get_thumbnail

class NoticiasPortada(models.Model):
    """Base de datos de noticias"""

    def get_upload_path(instance, filename):
        return "fotos/%s" % filename

    identificador = models.IntegerField()
    titular = models.CharField(max_length=200)
    texto = models.TextField()
    thumbnail = ImageField(upload_to=get_upload_path, 
              blank=True, null=True)

    def img(self):
        if self.thumbnail:
            try:
                im = get_thumbnail(self.thumbnail, 
                                     '50x50', crop='center', quality=80)
                return '<img src="%s">' % im.url
            except IOError:
                return "error"
        else:
            return "%s" % self.identificador
    img.allow_tags = True
    img.short_description = 'img'

    def __unicode__(self):
        return self.titular

Com es pot veure Sorl incorpora una sèrie d'utilitats per a la conversió d'imatges que ens van molt bé. Així podem definir el mètode img dins el model per tal de poder-ne fer referència a l'administrador de d'Django.

Fixem-nos també com li podem passar un mètode per tal de poder calcular a quin lloc es deixarà la imatge. Aquest mètode ha de tenir la signatura nomfuncio(instància, nom) on instància és la instància de l'objecte al qual s'associarà la imatge i el nom és el nom de la imatge en sí. Això és molt útil per poder deixar les imatges a diferents carpetes segons convingui.

A l'admin.py podem fer

from django.contrib import admin
from models import NoticiasPortada

class NoticiasPortadaAdmin(admin.ModelAdmin):
    list_display = ('img', 'identificador', 'titular')
    search_fields = ('titular', 'texto')

admin.site.register(NoticiasPortada, NoticiasPortadaAdmin)

Sorl té opcions per a que al formulari se'ns presenti també la imatge, però per ara ho deixarem així.

La càrrega de les imatges

La càrrega de les imatges la podríem haver fet de moltes maners, però com que ja vaig posar un article de com fer comandes de Django, doncs ho aprofitaré. Crearem una comanda anomenada importar que es podrà cridar com

python manage.py importar

Per això s'ha de crear un paquet Python dins l'aplicació amb l'estructura

app
    models.py
    management
        __init__.py
        commands
            __init__.py
            importar.py

Si feis servir django-extensions recordau que hi ha una comanda anomenada create_command que crea directament aquesta estructura.

Per a importar les imatges utilitzarem la classe InMemoryUpladedFile que es troba a django.core.files.uploadedfile. Podem passar una instància d'aquesta classe al nostre model dins l'atribut thumbnail i Django se n'encarregarà de la resta. La complexitat addicional està en que ens hem de davallar la imatge de la web.

def download_photo(self, img_url, filename, field_name):
    img = cStringIO.StringIO()
    image_on_web = urllib.urlopen(img_url)
    while True:
        buf = image_on_web.read(65536)
        if len(buf) == 0:
            break
        img.write(buf)
    image_on_web.close()
    return InMemoryUploadedFile(file=img,
            field_name= field_name, name=filename,
            content_type="image/jpeg", size=img.tell(), charset=None)

Per davallar-nos la imatge farem servir la llibreria urllib. Passant-li una url es capaç de llegir-la i donar-nos el contingut. Com que la memòria de moment no és un requeriment, el que farem serà deixar el contingut dins un buffer que es comporta a tots els efectes com un fitxer. Feis una ullada al duck typing per saber com és això possible.

InMemoryUploadedFile espera un fitxer (d'aquí el truc de fer servir StringIO), el nom del fitxer, el content_type, el tamany i el charset, així com el nom del camp.

De fet, però ho podem fer una mica més senzill, ja que no necessitam el nom del camp. Django té una altra classe que fa el cid més senzill, és el SimpleUploadedFile de manera que el codi queda un poc més net:

def download_photo_simple(self, img_url, filename):
    img = cStringIO.StringIO()
    image_on_web = urllib.urlopen(img_url)
    while True:
        buf = image_on_web.read(65536)
        if len(buf) == 0:
            break
        img.write(buf)
    image_on_web.close()
    return SimpleUploadedFile(content=img.getvalue(),
            name=filename,
            content_type="image/jpeg")

Però encara així és molta línea per a tan poca cosa. Em feia ganes provar una llibreria que promet simplificar el procés d'accés als recursos web. La llibreria requests. Teniu en compte que el codi amb urllib encara es complicaria més en una aplicació real, ja que convé controlar les excepcions que hi pot haver. El tema està força ben explicat a l'apunt urllib2 - The Missing Manual, així que no m'estendré més.

L'avantatge de requests és que ens permet abstreure'ns d'aquests excepcions i tractar únicament amb codis d'estat web. Així el que ens interessarà és obtenir la imatge si el codi és 200 (tot bé) o retornar un None si hi ha problemes. Així el codi es simplifica encara més.

def download_more_simple(self, img_url, filename):
    r = requests.get(img_url)
    if r.status_code == 200:
        return SimpleUploadedFile(content=r.content,
            name=filename,
            content_type=r.headers.get('content-type'))
    else:
        return None

Amb això, crear una instància de NoticiasPortada pot quedar com

noticia = NoticiasPortada(
    identificador = id,
    texto = texto,
    titular = titular,
    thumbnail = self.download_more_simple(src, 'thumb-%s.jpg' % id)
                )
 noticia.save()

on id és l'identificador de la notícia i src representa la url de la imatge.

Com ho treim a això? Doncs és una bona pregunta. A la segona part de l'article us ho explico. Fins demà!

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%.

Ja fa un grapat de mesos estic fent cosetes amb Redis, una base de dades de les anomenades noSQL, molt semblant en funcionament a Memcached.

Val a dir que a Redis hi vaig arribar a partir de Celery, la utilitat per crear i gestionar tasques per Python i Django. Vaig trobar la combinació Celery més Redis molt bona quan no necessites tota la potència, ni tota la complexitat que et dóna RabbitMQ.

La idea, una vegada hagi finalitzat les proves, és anar substituint Memcached per Redis com a sistema de caché per les aplicacións Django. També hi ha un projecte per fer que les sessions també puguin estar damunt Redis, així que crec que també li tocarà. A més, d'aquesta manera ja tenim una base de dades addicional per fer-la servir quan sigui necessari. Redis ofereix una cosa que Memcached no té, la persistència de la informació.

En el cas de la caché, Redis pot ajudar a solucionar un dels problemes més importants que hi ha quan un fa aplicacions grans, la invalidació de les cachés. Amb memcached la invalidació sovint és un tot o res, és complexa fer que s'eliminini sols una part de la informació si no saps ben bé quines són les claus exactes que s'han fet.

Redis té una velocitat de resposta i suport a la concurrència tan bona o millor que memcached, però a més ens permet fer consultes sobre claus que comencin per algún prefix, o per claus concretes, podem saber quin tems d'expiració té cada clau, veure les claus que hi tenim al sistema, etc.

Això ens dóna tota una nova via per dissenyar el sistema de cachés, on tant l'usuari com el propi sistema poden decidir invalidar la caché en funció de les necessitats de l'aplicació.

Podem eliminar completament el contingut de la base de dades amb una simple comanda, FLUSHDB. Posau-ho per exemple a l'abast de l'administrador de l'aplicació web. Quan fa un canvi important i no vol esperar podem posar-hi aquest link per a que llanci aquesta comanda contra Redis.

Si ho feim servir dins Django podem veure com aquest va generant les claus, així podem decidir millor què invalidam. És a dir, tenim tot el que teníem amb Memcached i un món nou de possibilitats.

A més l'API per Python és molt bona, tant que amb l'iPython i l'API no hi ha pràcticament necessitat d'anar a la pròpia consola de Reids (el redis-cli), per acabar-ho de rematar s'ha millorat molt el parseig de la resposta amb hiredis-py.

En resum, estic gratament sorprès amb aquesta eina i us animo a fer-li una ullada.

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

Estic a la segona tongada de beta-testers de Gondor un hosting per Django montat al núvol desenvolupat per la gent d'Eldarion.

L'aplicació vol simplificar la manera de desplegar les aplicacions Django a força de forçar una determinada configuració. És a dir, es simplifica el desplegament, però sempre que juguem amb les cartes que ens donen, que he de dir que no són dolentes.

La posada en marxa és senzilla, el programa que fa la interacció amb Gondor (una vegada t'has donat d'alta a la web) és un paquet que està al PyPi, així que és sols cosa de pip install gondor i gairebé ja pots començar a fer-hi feina.

Per provar he fet servir un codi que ja tenia mig fet i que ara s'ha convertit en la web d'inscripcions de creantbits. La conversió d'una aplicació tal com la desplegam a APSL habitualment a una aplicació capaç de ser desplegada amb Gondor és prou senzilla, i està ben explicada a la documentació. Si més no però, convé fer uns petits avisos per si algú també s'hi troba:

1. El teu projecte ha de ser gestionat per Git o Mercurial. Tant fa si no hi ha un repositori remot, però s'ha de tenir en compte que el desplegament es fa damunt una versió commitada del codi.

2. S'ha de crear una carpeta anomenada requirements on hi hagi un arxiu anomenat requirements.txt amb els requeriments de l'aplicació amb un fortat llegible per pip. No s'hi valen paquets que s'hagin de compilar llevat de lxml i PIL, la connexió a BD, Postgres per més senyes ja ens la donen ells.

3. S'ha de crear una carpeta deploy amb la connexió WSGI. S'ha d'anar alerta amb els paths. En el meu cas no m'agrada tenir dependències del nom del projecte a les aplicacions ni a les urls, així que he modificat el WSGI (per cert, sabeu que es llegeix com a Whisky?).

4. Alerta amb els STATIC_URL i MEDIA_URL Gondor he comprovat que dóna menys problemes si es fan servir les convencios d'static files, així que una adaptació que s'ha de fer a les aplicacions és substituir a les plantilles els MEDIA_URL per STATIC_URL (i configura el settings) i posar el contingut estàtic lligat a una aplicació per a que funcioni el collectstatic.

Amb això i amb un parell (dues o tres) de proves la primera versió de l'aplicació ja funcionava, els que em seguiu per Twitter ja ho haureu notat, ja que he estat donat la murga amb això els darrers dies.

Gondor desplega l'aplicació creant un tar.gz del master del nostre repositori (el tip en terminologia Mercurial) i l'envia al seus servidors. Allà es desplega, es creea un virtualenv, s'instal·len les dependències i es crea la BD o es migra si és una actualització.

Això fa que el procés d'actualització, fins i tot per una modificació a una plantilla sigui un tant lent, ja que les velocitats de pujada de les ADSL són de vergonya. Estic mal acostumat als servidors dedicats que tenim, bé directament o amb fabric les actualitzacions ens duen segons. Està clar que la gent de Gondor ha tingut que arribar a un compromís entre velocitat de desplegament i estabilitat de l'entorn. Els vaig fer arribar aquesta "queixa" i em contestaren que estan treballant en un mètode diferencial per fer les actualitzacions, la qual cosa pareix que pot millorar molt el conjunt.

Encara no tenen a l'abast Celery, el sistema de cues, que és força important ja que no es té accés al cron del servidor i sovint són necessàries tasques periòdiques, com per exemple per netejar les sessions caducades.

Llevat d'això, la plataforma per ara és molt estable, quan hi ha errors les missatges se t'envien a la pròpia consola i quan fas l'actualització surt una plana 503 ben informativa.

Quan feia les proves vaig enviar uns quants missatges per aclarir conceptes o suggerir millores i em contestaren ràpidament, ja mitjançant e-mail o pel Twitter d'Eldarion.

Encar no sé el cost de la plataforma, ni les funcionalitats que tindrà en el futur. Però les impressions inicials són bones. Per molts dels projectes que feim Gondor no és una alternativa, però per projectes tipus la web del creantbits i semblants va prou bé.

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!

El dimumenge em va tocar estar de president a una Mesa electoral de Binissalem. En altres eleccions havia estat d'apoderat en alguna taula, però eren poques hores. Estar de president implica estar en dança des de les 8 del matí fins que s'acaba el recompte i s'han entregat les actes.

Molts ho consideren una putada, però particularment, i encara que el dilluns no servia per res, ja que vàrem acabar prop de la una i mitja del vespre i sense sopar, vaig poder veure de primera ma el desenvolupament complet del procés electoral. És una experiència que trob enriquidora, tot i que l'organització de la intendència va deixar molt a dessitjar.

La Mesa estava situada a un pati cobert de l'escola. Al mateix recinte hi havia dues meses més, amb la qual cosa sovint era complicat sentir-se els propis pensaments. Ja a partir de les dues del migdia feia molta calor, i no hi havia gens d'aigua per beure. Afortunadament un dels apoderats, no sé si del PP o del PSOE (la gent de la Mesa se suposa que no ens podem moure gaire), va dur una botella d'aigua de litre i mig i en va repartir.

Si em toca una altra vegada ja us dic jo que hi haurà un parell de coses que no faltaran: una gelera amb aigua i sucs, menjar, una grapadora i un fulls quadriculats.

La jornada es va desenvolupar amb molt normalitat. Binissalem és un poble on hi ha molta participació, i la nostra mesa em sembla que tenia un dels cens més grans, més de 700 persones a les locals. Va estar arribant gent des de que s'obrí la votació fins que es tancà. Sols hi va haver una pausa d'uns 15 minuts als voltants de les dues, però llevat d'això va ser un degoteig continuo de gent.

Enguany es permetia als electors depositar ells mateixos la papereta dins l'urna, crec que això és una bona cosa, fa més partícep la gent del procés, però també és una feina extra per la gent de la Mesa. S'ha d'assegurar molt bé que sols es posa una papereta (sí, hi ha gent que ho intenta de tant en tant), i a més que es posi la papereta en la seva urna corresponent. Això és menys crític, de fet em vaig despistar un moment, ja al final de la jornada, i encara em posaren una papereta de les eleccions locals dins una urna del Parlamente, però això és bo d'arreglar: al començament del recompte es posà la papereta dins l'urna correcta, barrejarem els vots i tot arreglat!

El procés de recompte és la part més crítica, s'ha de procurar que tot quadri, i això vol dir que els vots s'han de cantar bé, i a més que s'han de comptar bé. Al vocal que duia el recompte li vaig dir que ho fes seguin el mètode dels quadrets, ja sabeu, es fa un quadrat i es tatxa en comptar cinc, d'aquesta manera tot resulta molt més senzill. Encara hi ha gent que posa una ratlla per cada vot i això fa que després tenir que comptar els vots es convertesqui en una pesadilla. Això, i el tenir molt clar el punt de partida, que hauría de ser la quantitat de votants que hi ha comptabilitzats. Si tothom està d'acord amb el nombre de votants tot és molt més senzill, ja que si s'espera quan ja s'ha fet el recompte un es pot trobar amb discrepàncies quan ja hi ha nirvis per poder donar resultats.

No hi va haver problemes. Tot va quadrar a la primera, i tenc que agrarïr la gran col·laboració que hi va haver per part dels apoderats de tots els partits: PSM, PSOE i PP que hi havia presents al recompte. Tothom anava per feina i així és molt bo de fer que tot vagi rodat. Tot i això eren prop de la una i mitja quan vaig arribar a casa, fi fa no fa, en tot el dia havia pogut seure uns minses 15 minuts.

Vaig poder veure com la gent sap perfectament que vota. A Binissalem teníem molt clar que no volíen el PSOE, ni la candidatura local ni a la resta. Hi va haver molts missatges en contra de la candidatura local que es traduïren en vots nuls i també va passar quelcom semblant en les eleccions autonòmiques. Crec sincerament que aquestes eleccions les ha perdudes el PSOE, potser no per mèrits propis, és veritat. La crisi no ha ajudat gens, però convindreu amb mi que els seus col·legues a Madrid ho han posat molt fàcil al PP. Potser ara es queixin donant les culpes a uns o als altres, que les eleccions s'han fet en clau estatal i no en clau autonòmica. És veritat, la gent ha castigat al PSOE i s'ha mantingut fidel tant al PP com al PSM que repeteixen o superen resultats passats.

El que no pot fer el PSOE és queixar-se de que a les eleccions el desgast del govern els ha perjudicat,ja que quan els afavoreix bé que callen. Curiosament a les locals el PSOE es presentava com a "de les illes Balears", però a les autonòmices ho feia amb tota la càrrega "obrero española", per mi, i supòs que per molts votants això vol dir identificant-se amb la politica duita pel Govern central. Política, que, per cert, mai no han rebutjat, no record cap vegada que el PSIB s'hagi desmarcat de la disciplina de vot per defensar els interessos de les illes. Tampoc ho record del PP, és veritat, però ara no són ells qui es lamenten de la derrota.

El que em preocupa és aquesta desfeta, que com dic és per mèrits propis d'uns i altres. Si el PP hagués gestionat la crisi les tornes s'haguéssin girat, n'estic gairebé segur. El preocupant és la "carrera d'armament" en que s'ha embarcat la classe política majoritària. No hi ha seny, es fan promeses popupulistes quan es sap perfectament que no es podran cumplir, o que va contra tota lògica econòmica. Polítiques com la del txec nadó, o els famosos 400 € del PSOE, o les subvencions milionàries promeses pel PP. No té sentit, hem arribat a un punt en que s'han de fer aquests coses perquè l'altra també les fa. En temes d'urbanisme s'ha de mirar a un altra banda perquè sinó els votants se n'aniràn cap a qui els prometi que hi haurà màniga ampla. Supòs que molts se n'andonaran que tot això no ens duu més que a malbaratar recursos, territori i a cremar el personal.

El dia de reflexió d'abans d'unes eleccions hauria de anar dirigit no als electors sinó als polítics i fer-se molt abans de presentar les campanyes. Hi ha una crisi de la que costarà sortir, la postura fàcil és la demagogia, distreure el personal amb eleccions de centre que no es podran fer o obrir el tema lingüístic en el que sempre hi ha hagut un gran consens, amb promeses de xecs que després s'han de retirar, amb subvencions que després s'han de tornar a força d'augmentar l'IVA i reduir sous. Inversions per sortir a la foto que s'han de subvencionar NO pagant als proveïdors o pangant-los tard i malament.

Sé que no hi ha respostes fàcils a problemes complexos, però el que el ciutadans hauríem de demanar és seny als nostres poĺítics i sentit d'estat. Però per a que això passi, la pròpia classe política ha de canviar, ha d'abandonar la carrera d'armament que no ens duu a cap banda (o que ens ha duit allà on som) i posar-se a fer feina per reconduir la situació, sense fer electoralisme, sense malbaratar recursos, sense estirar més el braç que la màniga.

Els votants en tenim també la culpa i si seguim així no podem per més que esperar que la propera crisi que segur que vindrà serà més dura que aquesta.

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.

Aquestes festes he estat mirant-me l'editor Geany per veure com responia a les meves necessitats de tenir un editor per a programació fonamentalment Python i Django que fos a la vegada potent i que tingués baixos consums de memòria.

En un editor per a programació crec que és important seguir el principi de Pareto o regla del 80-20, és a dir, vull un editor que amb el 20% de comun de recursos tengui el 80% de les funcionalitats d'un IDE com Eclipse+Pydev o PyCharm per exemple.

Avui en dia el meu editor de capçalera és Vim/Gvim totalment personalitzat amb la configuració que podeu trobar a trespams-vim, crec que és una bona configuració, però tot i la potència de Vim tanmateix no faig servir ni un 20% de les possibilitats que m'ofereix l'editor. El que sí que crec que és important és dominar-lo, ja que de tant en tant convé editar via ssh i saber fer anar vim amb condicions és un avantatge.

La cosa doncs és que vaig decidir donar una altra ullada a Geany, ja que vaig veure a la web que havien llançat una nova versió, la 0.2 més moderna que la que tenia ja instal·lada a Ubuntu. Una cosa que a mi en va molt bé és el ressaltat de plantilles per Django (cosa que Gvim té), així que per a ser justs, el primer que vaig fer va ser mirar si Geany també ho tenia: requereix una mica de configuració, però sí, us explic:

Cercant per Google vaig arribar a la plana de drevans, on explica com podem activar el ressaltat, és prou senzill, basta fer

cp /usr/share/geany/filetypes.html  ~/.config/geany/filedefs/

editar l'arxiu que acabam de copiar i cercar la secció lexer_properties i afegir

lexer.html.django=1

Amb això ja tenim colorejat per la sintaxi de plantilles Django. Una cosa ja feta.

Superat el primer obstacle ja sols és cosa de veure quin conjunt de característiques té Geany comparat amb altres editors o IDEs i quines no té, i el grau d'importància relativa que tenen per mi. Deix de banda coses que podem donar per pressuposades a un editor modern: ressaltat de sintaxi per múltiples llenguatges (fonamental ressaltat de javascript dins html) i edició de múltiples documents.

1. Gestió de projectes. És una característica que classificaria com a important. Estalvia molt de temps que l'entorn et situi directament al directori i mantengui la llista dels darrers arxius que es van obrir al projecte.

2. Treball amb UTF-8 i format Unix. La nostra configuració de feina per defecte és UTF-8, quatre espais per tabular i salts de línia en format Unix. Si ja no té això no me mir l'editor, així que és una característica obligatòria.

3. Autocompletat. Realment no necessit que tengui un autocompletat de llibreries (al cap i a la fi Python no és Java) però si ho té millor, i sobretot el que va molt bé és tenir un autocompletat basat en que un ja ha escrit en el document, ja que evita molts errors tipogràfics.

4. Reasaltat de sintaxi per HTML i Javascript dins el mateix document El ressaltat de sintaxi va molt bé a l'hora de programar, pots detectar errors sols pel colorejat de l'editor, per això és important que a l'hora d'editar HTML on cada cop és més comú que hi pugui haver javascript, el ressaltat sigui prou inteligent per detectar que estic a la part javascript del codi i adapti també el ressaltat.

5. Integració amb un comprovador de sintaxi per Python com pylint o pyflakes i pep8. Es pot fer la comprovació per línia de comandaments, però és interessant no tenir que sortir de l'entorn. És doncs una característica interessant però no fonamental.

6. Parseig de símblos Va molt bé que un editor per a programació sigui capaç de parsejar el codi font i et mostri les classes i funcions que tens definides dins el document, estalvia molta feina a l'hora de navegar pel codi o trobar el que t'interessa. No és una característica fonamental, però pot ajudar a decidir.

7. Maneig de bookmarks Cada cop faig servir més aquesta característica a Vim ja que em permet navegar ràpdament entre distintes seccions del codi. No és fonamental però també molt convenient.

8. Cerca potent De les millors que he vist són les d'Eclipse i Netbeans que et permeten cercar per tot el projecte.

9. Baix consum de recursos. Per mi és important poder fer servir l'editor en qualsevol dels equips que tinc. Fer feina sempre amb el mateix editor fa que a poc a poc un s'ho vaig fent seu i n'aprofiti millor les funcionalitats. Si triam un editor gràfic hem de tenir en compte que a més convindrà dominar un poc les quatre coses d'un editor en moda consola com Vim. Si l'entorn consumeix molts recursos ens podem trobar que no hi hagi prou memòria per engegar altres aplicacions que necessitam, sobretot en equips més vells. Vaig deixar de fer servir Eclipse i després Netbeans per aquest motiu. Per fer modificacions xorres necessitava esperar gairebé un minut per posar tot l'entorn en marxa. Netbeans a més ha deixat de suportar Python, així que ho he descartat tot i les darrers millores.

10. Integració amb control de versions Interessant però com en el cas del comprovador de sintaxi o precompilador és quelcom que sovint és més ràpid fer per línia de comandaments.

La resta de característiques que pot tenir un IDE poden estar molt bé i potser un les fa servir un cop o dos al llarg d'un projecte, però per mi i amb el tipus de projectes que feim, crec que no compensen el tenir que carregar amb un entorn feixuc.

Geany compleix amb gairebé totes les funcionalitats que he exposat aquí, fins i tot l'autocompletat va un poc més enllà i es capaç d'autocompletar a partir de les llibreries Python. La integració amb Pyflakes y Pep8 es pot fer i els missatges d'error o avís apareixen a la finestra de missatges. Tot i això he de dir que li faltaria ponder fer clic damunt un missatge d'error i anar directament a la línia, per això s'ha de configurar un poc, anirem a la secció Munta i a on diu "Error regular expression" posarem (.+):([0-9]+):[0-9]+ això ens servirà tant per pyflakes com per pep8, de fent a la meva configuració actual tinc com a compilador pyflakes "%f" associa a la tecla F8 i associat a F9 pep8 "%f" per saber si es compleixen les convencions de codi.

El que he trobat molt úlil a Geany és que té una secció on pots veure tots els documents que tens oberts classificats en la carpeta on es troben. Quan fas feina amb Django on tots els models són models.py et permet navegar ràpidament pels arxius que tens oberts.

Genay també ve amb un conjunt de plugins per estendre la funcionalitat de l'editor. El més interessant que he trobat és un formatejador d'XML, ja que m'estalvia tenir que fer servir un altre programa i realment no carrega gens l'editor.

Geany té també la possibilitat de definir plantilles de codi, com entorns molt més grans i que és una de les característiques que m'agraden més de Vim. D'entrada el conjunt de plantilles que duu per defecte són molt poques, però és molt bo de fer crear-ne més.

En conclusió, Geany és un editor potent, senzill de fer anar i amb un consum de recursos de màquina realment petits. Me pareix que serà el meu proper editor de capçalera.

Disclaimer: This is my first English post is a free translation of the original catalan post

In previous posts have written about Celery and Django Celery, a system to manage queues and tasks in Python and Django.

Celery in its documentation recommends RabbitMQ as message broker, that is, as the application that receives and distributes the tasks that the application sends between the different workers we have configured in our system.

Once the worker has done the task it leaves the result (if we have configured to do it) to the results backend, usually it is the same one as the message broker, that is RabbitMQ acts as a message broker and as a result backend.

The architecture of Celery is very powerful in the sense it allows us to scale up and down and replace the parts we need to configure the application to our needs. So we could have applications that needs some sort of message or task distribution, but they don't need to deal with the complexity nor the system requirements of RabbitMQ. With Celery we can even use a database as a message broker where could save the results, we can replace the serialization routines, the results storage. So, although in the documentations we have a prefered configuration we can change it the needs of our application.

In this post I'll try to present is a configuration that fits in the middle of the complexity of a RabbitMQ solution but enough powerful to fit most application needs.

What's the problem we'll try to solve?

We have an application that we want to run in an small server or in a shared server that needs some sort os distributed tasks or periodic task than we want to manage inside the application itself. We would like:

• Minimum complexity to install and configure the task system.
• We'd like not to have a dedicated broker.
• We'd like to monitor what's happening in our application
• We'd like to manage our system easily.
• We'd like to debug our application and run everything on a local server before run the application using a distributed task configuration.
• We'd like our task broker could have very low memory requirements

We can imagine lots of scenarios in what that requirements would fit, a news aggregation, an e-comerce application that needs to send the invoices, an small document management system that makes some sort of format translation. That is, systems that need a small response time to the user and that could make the heavy task in an asynchronous way, where the reliability of the tasks system is not critical for the application

For that kind of applications Celery with RabbitMQ is overkill, so we're going to diet it a bit

The broker

We want the distribution of tasks to be powerful and flexible, but without the complexity of RabbitMQ. So what will be do is install Redis , a NoSQL a database that works in a similar way memcached does.

Redis is very fast and comsumes few machine resources, allows the persistence of periodic data and the application is generic enough to be used in our applications in addition to task management. A [presentation by Simon Wilson] (http://simonwillison.net/static/2010/redis-tutorial/) summarizes very well the possibilities of this database.

Redis has, however, and important requirement that we must know: in its standard configuration requires that all data has to fit in memory and that periodically synchroniZes the changes to disk. So we must monitor our application to be sure that Redis does not grow without notice consuming all the available memory.

Installing Redis

Readis is present in major Linux distribution, and in Debian based distros is enough to type

sudo apt-get install redis-server

as we're going to use Redis in Celery we must install also the Python API

pip install redis

inside our virtualenv (I suppose everybody is using virtualenv ...)

In a brand new installation in a Ubuntu 10.10 redis consumes 3271B of virtual memory and 1516B of resident memory in a single process.

In a production environment for sure we would like to configure some parameters:

• bind, to link the redis instance to an IP
• loglevel is verbose in the default configuration, in production notice or warning would be enough.

The configuration file for redis is in /etc/redis/redis.conf in the Ubuntu, is extensively documented to allow us to adapt it to our needs.

The results storage

As mentioned Celery also allows us to define where to store our data. Redis is a general purpose database, so in addition to the tasks broker we can use it to save the results of the tasks. As pointed before, we have to monotor Redis if we plan to store lot of data o if we store big results. Redis mantains all the database in memory.

Usually in a task/queue system we want to keep the results a just the time enought to see that everything is going well and then we don't need the results anymore.. That is, the results do not necessarily have to remain in the database, the amount of time we need to keep the results in the database would greatly depend on our application.

Let me explai myself. We use Celery in a B2C application to update the information we have about the hotels. We launch the update information periodicaly to update a the information and each task is able to run another taks. Once the information is received the information is processed. So the results just needs to be in the database the time that a worker needs to process it, after that we can delete it. As the process is quite fast is much simpler to make the results expire in 60 seconds than to write the code to delete it.

If we're need to create a task to send an invoice we do not need to save the invoice in Redis, we just need to update our database to mark the invoice as sent once the worker has finished the pdf generation and the mail is sent.

So if we want to mantain our low memory requirements we have to tune our application to not store a lot of information in the Redis database.

Using Redis as a broker and as a database makes us to reach our objective of reusing the technology, but we can use Redis as a cache backend for Django and to [store sessions]((https://bitbucket.org/dpaccoud/django-redis-sessions/src).

Our settings.py

First at all in our INSTALLED_APPLICATIONS we have to add djcelery and now we have to configure Redis as a broker and database backend.

BROKER_HOST = "192.168.1.33"
BROKER_BACKEND="redis"
REDIS_PORT=6379
REDIS_HOST = "192.168.1.33"
BROKER_USER = ""
BROKER_PASSWORD =""
BROKER_VHOST = "0"
REDIS_DB = 0
REDIS_CONNECT_RETRY = True
CELERY_SEND_EVENTS=True
CELERY_RESULT_BACKEND='redis'
CELERY_TASK_RESULT_EXPIRES =  10
CELERYBEAT_SCHEDULER="djcelery.schedulers.DatabaseScheduler"

import djcelery
djcelery.setup_loader()

192.168.1.2 is the virtual image in which I have installed a fresh Ubuntu and that runs Redis, as in this post I'd like to emulate a simple production environment with two servers. As you can see I have no password protection and Redis runs in its default port.

Note that on BROKER_VHOST we have to configure the database Redis will use for the broker system. It can be the same one as the REDIS_DB but we could choose to have the results and the task communication in different databases. CELERYBEAT_SCHEDULER CELERY_TASK_RESULT_EXPIRES is just 10 seconds, time enough for our purposes. CELERYBEAT_SCHEDULER is configured to allow us to create periodic task from our Django application. As this needs new database tables, we would need to run syncdb to create the tables that the scheduler needs.

Development mode

On development on of the first goals is to be sure everything works properly, so we don't need the noise that the broker and storage puts on our development process. Celery has a special configuration

CELERY_ALWAYS_EAGER=True

so our application would not use nor the worker neither the broker and is executed as a common application, just invokes the task in a synchronous way.

Lets start the workers

When you start with Celery it's important to have a global vision about what's happening in our application. I have found that terminator is a good tool to run our console commands, splitting our terminals in order to see what's happening.

So lets open a console in our application environment and run

python manage.py celeryd -E -B --loglevel=INFO -n w1.d820

This will run a worker, configured to run the default number of processors, which depends on the number of CPUs available on our server. We have configured the worker to send monitoring signals (-S) and to run an additional process to deal with the periodic tasks (-B).

It's important to remark that just one worker can have the -B parameter, so perhaps is better to make this fact more visible and run the periodic task process using a dedicated command

python manage.py celerybeat --loglevel=INFO

Running celerybeat as a standalone process it will inform us about its configuration

[2011-04-03 11:16:46,808: WARNING/MainProcess] celerybeat v2.2.5 is starting.
[2011-04-03 11:16:46,863: WARNING/MainProcess] __    -    ... __   -        _
Configuration ->
    . broker -> redis://@192.168.1.33:6379/0
    . loader -> djcelery.loaders.DjangoLoader
        . scheduler -> djcelery.schedulers.DatabaseScheduler

As we want to monitor the tasks and have more than just one worker is important to name them. This can be done with the -n parameter. I like to add the worker number and the server name. In the example the name of my laptop.

Run a second worker is as easy as:

python manage.py celeryd -E --loglevel=INFO -n w2.d820

 -------------- celery@w2.d820 v2.2.5
---- **** -----
--- * ***  * -- [Configuration]
-- * - **** ---   . broker:      redis://@192.168.1.33:6379/0
- ** ----------   . loader:      djcelery.loaders.DjangoLoader
- ** ----------   . logfile:     [stderr]@WARNING
- ** ----------   . concurrency: 2
- ** ----------   . events:      ON
- *** --- * ---   . beat:        OFF
-- ******* ----
--- ***** ----- [Queues]
--------------   . celery:      exchange:celery (direct) binding:celery

As we can see we have not add the -B parameter and Celery informs us that the beat process is off.

We can increase or decrease the number of default processes that the worker is going to star with the --concurrency parameter. The final number is a matter to test and see.

python manage.py celeryd -E --concurrency=10 -n w3.d820

Monitoring: what's happening in my application?

If we have added logs on our applications in each worker we can check and see the output, but perhaps we have no logs o our workers could be distributed in different servers. Celery provides us with some monitoring that are nice to know. To use such tools the first step is to start the monitoring service:

python manage.py celerymon

celerymon 2.2.5 is starting.
Configuration ->
    . broker -> redis://@192.168.1.33:6379/0
    . webserver -> http://localhost:8989
celerymon has started.

As we can see Celery has started a server on port 8989. We can connect to that server and see the registered workers and tasks. It's some sort of raw information but it could be enough

[{"heartbeats": [1301824037.784225],"hostname": "w1.d820"}, 
{"heartbeats": [1301824018.90294], "hostname": "w2.d820"}]

As we have configured the DatabaseScheduler we could see the tasks in the Django application itself, but there is another tool on colole mode that give us nearly realtime information, the celeryev

With python manage.py celeryev we will start an console application that will show us what tasks are being processed, we can see the result of each tasks and even revoke a task. If we want more control about the monitoring tools Celery provides an API to get the information, and of course you can look at the source code for celeryev.

It's important to monitor also the Redis server

sudo tail -n 100 -f /var/log/redis/redis-server.log

we'll see what's happening on the Redis side,

==> /var/log/redis/redis-server.log <==
[677] 03 Apr 09:56:10 - Accepted 192.168.1.32:38923
[677] 03 Apr 09:56:10 - Client closed connection
[677] 03 Apr 09:56:10 - Client closed connection
[677] 03 Apr 09:56:10 - Accepted 192.168.1.32:38924
[677] 03 Apr 09:56:10 - Client closed connection
[677] 03 Apr 09:56:10 - Client closed connection
[677] 03 Apr 09:56:10 - Accepted 192.168.1.32:38925

Redis provides also a client console, redis-cli that we could use to get more information and make a lot of management task. Some useful commands are:

• KEYS * shows us the active keys
• DBSIZE informs us about the size of the active database

• INFO give us a lot of information about our database, it's really useful to check the memory consumption
  

  process_id:677
  uptime_in_seconds:5349
  uptime_in_days:0
  connected_clients:14
  connected_slaves:0
  blocked_clients:4
  used_memory:1551228
  used_memory_human:1.48M
  changes_since_last_save:1111
  bgsave_in_progress:0
  last_save_time:1301824662
  bgrewriteaof_in_progress:0
  total_connections_received:509
  total_commands_processed:7060
  expired_keys:0
  hash_max_zipmap_entries:64
  hash_max_zipmap_value:512
  pubsub_channels:1
  pubsub_patterns:0
  vm_enabled:0
  role:master
  db0:keys=8,expires=0

• FLUSHDB cleans all the database removing all the keys

• MONITOR shows us in real time what's happening, what commands are being executed, and the keys and information that is stored in the database.
  

To summarize

With Django, Celery and Redis we have a simple task distribution, scalable and with very small server requirements.

We can use Redis as a broker, as as data store and in other tasks of our Django application: as another database, as a session database, as a cache server.

If we want to work using tasks to split the work we have to

• Develop our application thinking in tasks and asynchronous processes.
• Install and configure Redis
• Run the workers
• Run celerybeat if we have periodic tasks
• Run the monitor

And of course we have to monitor all the application. Enjoy!

En anteriors apunts he parlat ja de Celery i de Django Celery, un sistema per a la gestió de cues i tasques per Python i Django.

Celery a la seva documentació recomana RabbitMQ com a gestor de missatgeria, és a dir, com a aplicació que reb i distribueix les tasques que li envia l'aplicació entre els diferents worker que tenguem al nostre sistema.

Una vegada el worker ha realitzat la tasca deixa el resultat (si així ho hem indicat) al contenidor de resultats, que normalment serà el mateix que el broker de missatgeria, és a dir RabbitMQ.

L'arquitectura de Celery és molt potent en tant que ens permet escalar cap a baix i substituir peces segons necessitem. Així per aplicacions que necessitin d'un sistema de distribució de tasques però no de la complexitat de RabbitMQ podem utilitzar altres sistemes de notificacions, fins i tot fer servir una base de dades. On es guarden els resultats o com es serialitzen els missatges també es pot canviar. En definitiva, encara que hi hagi una configuració recomanada per a entorns que necessitin de molta potència en el sistema de distribució de tasques i coes, podem personalitzar Celery al nostre gust i a les nostres necessitats.

En aquest article el que presentaré és una configuració a mig camí entre el que seria la configuració més complexa de Celery i una configuració simple basada sols en base de dades.

Plantejant el problema

Tenim doncs una aplicació que no és molt gran, però a la que aniria molt bé tenir un sistema de distribució de tasques.

• Volem que la instal·lació i configuració sigui senzilla.
• El que instal·lem si pot ser hauria de poder aprofitar-se per quelcom més que no el sistema de tasques.
• Volem poder monitoritzar el que està passant.
• Volem poder gestionar fàcilment l'entorn
• Hem de poder depurar fàcilment el que està passant i assegurar-nos que l'aplicació funciona sense tenir que muntar tot l'entorn.
• El gestor de tasques ha de consumir pocs recursos i ser bo de controlar.
• El gestor de tasques ha de permetre l'execució de tasques periòdiques.
• Volem poder tenir accés als resultats.

Podem imaginar molts escenaris en que això s'ha de complir, per exemple un agregador de notícies, en un sistema de e-comerce l'enviament de factures, en un petit gestor documental la conversió de formats, ... És a dir, sistemes en els que volem que la resposta cap a l'usuari final sigui el més ràpida possible i que la feina feixuga no necessàriament es tengui que fer de manera síncrona, però on tampoc passa res si el sistema de missatgeria cau i perd alguna tasca, simplement es pot tornar a executar.

Amb aquestes condicions la configuració estàndard de Celery i de Django Celery és massa complexa, així que el que farem és aprimar-la un poc.

El broker

Volem que el sistema de distribució de tasques sigui prou potent i flexible, però sense la complexitat de RabbitMQ. Per això el que farem serà instal·lar Redis una base de dades NoSQL molt semblant al que seria un memcached.

Redis té l'avantatge de que és molt ràpid, ocupa molt pocs recursos de màquina, permet la persistència periòdica de les dades i és una aplicació prou genèrica com per poder ser utilitzada en les nostres aplicacions a més de per fer la gestió de les tasques. Una presentació de Simon Wilson crec que resumeix molt bé les possibilitats d'aquesta base de dades

Redis té un emperò important que hem de conèixer, és una base de dades que en la seva configuració estàndard requereix que totes les dades hi càpiguen en memòria i que aquesta es sincronitzi de manera periòdica al disc. Així doncs hem de procurar monitoritzar la nostra aplicació i l'ús que en fa de Redis per a no consumir més memòria de la que ens vulguem permetre.

La instal·lació de Redis

Redis està com a paquet en les principals distribucions, així que per distribucions basades en Debian bastarà fer:

sudo apt-get install redis-server

i com que també l'utilitzarem des de la nostra aplicació convé instal·lar també el l'API de connexió per Python, amb pip mateix

pip install redis

dins el nostre entorn virtual (perquè està clar que feis servir virtualenv a les vostres aplicacions, no?).

En una instal·lació neta dins una màquina virtual Ubuntu redis està ocupant 3271B de memòria virtual i 1516B de memòria resident a un únic procés.

En producció segurament ens interessarà tocar alguns paràmetres de Redis per fer la configuració més segura:

• bind ens permet lligar redis a una IP concreta.
• loglevel per defecte està a verbose, a producció amb notice o warning serà suficient.

l'arxiu de configuració de redis es troba a /etc/redis/redis.conf i està molt ben documentat per a poder adaptar-lo a les nostres necessitats.

On guardam els resultats?

Com hem dit Celery ens permet definir també on guardar els nostres resultats. Donat que Redis és una base de dades de propòsit general, a més de fer les tasques de missatgeria l'aprofitarem per a que guardi els resultats de les tasques.

Aquí hem de tenir en comptes el que dèiem de Redis, si guardam moltes dades i no pensam en anar fent neteja la memòria de Redis anirà creixent fins a ocupar tot el que tinguem.

Normalment a un sistema de tasques i cues ens interessarà guardar els resultats un temps per veure que tot està anant bé i després ja no els necessitam. Es a dir, els resultats no tenen perquè quedar forçosament dins la base de dades Redis, això ja dependrà de la nostra aplicació.

M'explicaré. Una de les aplicacions on feim servir Celery ens permet actualitzar la informació que tenim d'hotels. Es van llançant les peticions d'actualització i el worker se n'encarrega de baixar-se la informació llançant a la seva vegada una altra tasca i de processar-la una vegada l'ha rebuda. La informació sols necessita estar al magatzem el temps just i necessari per poder monitoritzar que tot va bé i que el worker ha rebut i processat la informació.

En el cas de la generació d'una factura no hem de guardar necessàriament el pdf de la factura dins Redis, basta poder dir que la factura s'ha realitzat correctament o directament suposar que ha anat tot bé i periòdicament tornar a llançar les tasques d'enviament per a tots aquells clients que han sol·licitat la factura i no se'ls ha enviada.

Així doncs utilitzarem també Redis per guardar els resultats i configurarem la nostra aplicació per a que no els guardi per sempre.

Amb això ja hem aconseguit que Redis faci una doble funció, però és que a més podem utilitzar Redis per a guardar les sessions de Django o fer-la servir com a Cache. Així doncs estam aprofitant els recursos que és un dels nostres principals objectius.

La configuració del settings.py

A INSTALLED_APPS hem afegit djcelery i per configurar Redis com a broker i com a magatzem de resultats feim:

BROKER_HOST = "192.168.1.33"
BROKER_BACKEND="redis"
REDIS_PORT=6379
REDIS_HOST = "192.168.1.33"
BROKER_USER = ""
BROKER_PASSWORD =""
BROKER_VHOST = "0"
REDIS_DB = 0
REDIS_CONNECT_RETRY = True
CELERY_SEND_EVENTS=True
CELERY_RESULT_BACKEND='redis'
CELERY_TASK_RESULT_EXPIRES =  10
CELERYBEAT_SCHEDULER="djcelery.schedulers.DatabaseScheduler"

import djcelery
djcelery.setup_loader()

El 192.168.1.33 és la màquina virtual on tenc instal·lat Redis, per tal d'emular un entorn de producció amb dues màquines. El port és el port per defecte i no he protegit redis amb usuari i password.

Important, el BROKER_VHOST és per redis el nom de la base de dades que es farà servir. Per defecte Redis fa servir la base de dades zero (0) però res ens impedeix tenir una base de dades diferent per les tasques i una altra pels resultats.

A CELERY_TASK_RESULT_EXPIRES podem veure com hem posat que els resultat expirin als 10 segons, més que suficient per la configuració de l'aplicació.

CELERYBEAT_SCHEDULER ens permet utilitzar la nostra aplicació d'Django per a gestionar les tasques periòdiques. Necessitarem fer un syncdb per a crear les estructures de dades, però a canvi podrem definir períodes i tasques.

Desenvolupant

En desenvolupament ens interessarà tenir molt present que tenim un sistema de coes i tasques, però realment el que més ens interessa és provar que tot funciona

CELERY_ALWAYS_EAGER=True

Aquesta configuració fa que l'aplicació s'executi com si no tingués coneixement del gestor de tasques, la qual cosa ens permetrà crear i depurar la nostra aplicació com sempre hem fet.

Posant en marxa els workers

Per tal de monitoritzar millor el que feim podem utilitzar una aplicació com terminator, una consola que ens permet agrupar consoles i veure d'una ullada el que està passant. A una d'aquestes consoles farem:

python manage.py celeryd -E -B --loglevel=INFO -n w1.d820

Això posa en marxa un worker, configurat amb un nombre de processos per defecte (2 en el meu cas) i li deim que envii els senyals de monitorització (això és el paràmetre S) i que a més engegui un procés addicional per a que gestioni les tasques periòdiques.

Hem de tenir en compte que sols hi pot haver un procés de gestió de tasques periòdiques, així que o bé es llança des d'un sol worker o bé podem fer servir l'aplicació celerybeat

python manage.py celerybeat --loglevel=INFO

Recordau! O una manera o l'altra però no les dues i mai per duplicat a dos workers.

Si l'executam per separat celerybeat ens informa de que està engegat i de las configuració que farà servir:

[2011-04-03 11:16:46,808: WARNING/MainProcess] celerybeat v2.2.5 is starting.
[2011-04-03 11:16:46,863: WARNING/MainProcess] __    -    ... __   -        _
Configuration ->
    . broker -> redis://@192.168.1.33:6379/0
    . loader -> djcelery.loaders.DjangoLoader
        . scheduler -> djcelery.schedulers.DatabaseScheduler

Com que volem controlar i monitoritzar bé el que passa i potser tenir més d'un worker és convenient posar-los nom, això es fa amb el paràmetre -n, a mi m'agrada donarlos un nom junt amb el nom de la màquina.

Arrancaré un segon worker:

python manage.py celeryd -E --loglevel=INFO -n w2.d820

 -------------- celery@w2.d820 v2.2.5
---- **** -----
--- * ***  * -- [Configuration]
-- * - **** ---   . broker:      redis://@192.168.1.33:6379/0
- ** ----------   . loader:      djcelery.loaders.DjangoLoader
- ** ----------   . logfile:     [stderr]@WARNING
- ** ----------   . concurrency: 2
- ** ----------   . events:      ON
- *** --- * ---   . beat:        OFF
-- ******* ----
--- ***** ----- [Queues]
--------------   . celery:      exchange:celery (direct) binding:celery

Fitxem-nos que en aquest cas ens diu que els events estan activat però que no hi ha el beat (el responsable de les tasques periòdiques actiu per aquest worker).

Podem ampliar o limitar el nombre de processos que arranca cada worker amb el paràmetre --concurrency, la configuració per defecte que depèn del nombre de CPUs disponibles sol anar bé, però sempre dependrà de la nostra aplicació i de les limitacions de recursos que li vulguem donar. Per exemple:

python manage.py celeryd -E --concurrency=10 -n w3.d820

Monitoritzant el que passa

Si a la nostra aplicació hem posat logs a cada worker podem veure el que està passant, però potser no sigui així, o tinguem els workers distribuïts a vàries màquines. Per això Celery ens dóna vàries eines de monitorització.

El primer que hem de fer és engegar el servei de monitorització:

python manage.py celerymon

celerymon 2.2.5 is starting.
Configuration ->
    . broker -> redis://@192.168.1.33:6379/0
    . webserver -> http://localhost:8989
celerymon has started.

Si anam al servidor web que ha engegat Celery, podem veure un resum de les tasques i dels workers. Per exemple, en el nostre cas:

[{"heartbeats": [1301824037.784225],"hostname": "w1.d820"}, 
{"heartbeats": [1301824018.90294], "hostname": "w2.d820"}]

Podem veure que hi ha dos workers actius.

Si hem fet servir el DatabaseScheduler veurem les nostres tasques dins la pròpia base de dades de Django, però a més hi ha una eina de consola d'allò més interessant celeryev

Amb python manage.py celeryev posarem en marxa una consola en la que ens informarà del que està passat, el nombre de tasques que hi ha executant-se i podrem veure informació damunt la tasca o eliminar (revoke) una tasca de la cua.

Si volem saber més coses o fer les nostres pròpies eines de monitorització Celery ens dóna tot una API per fer-ho, així que no estam limitats a les eines de sèrie.

El que ens queda també per monitoritzar és què està passant amb Redis

   sudo tail -n 100 -f /var/log/redis/redis-server.log

ens informarà del que està passant i de les connexions que es realitzen.

==> /var/log/redis/redis-server.log <==
[677] 03 Apr 09:56:10 - Accepted 192.168.1.32:38923
[677] 03 Apr 09:56:10 - Client closed connection
[677] 03 Apr 09:56:10 - Client closed connection
[677] 03 Apr 09:56:10 - Accepted 192.168.1.32:38924
[677] 03 Apr 09:56:10 - Client closed connection
[677] 03 Apr 09:56:10 - Client closed connection
[677] 03 Apr 09:56:10 - Accepted 192.168.1.32:38925

Si volem anar més enllà podem fer servir la consola de Redis, redis-cli

Algunes comandes molt útils:

• KEYS * - ens monstra les claus que tenim actives.
• DBSIZE - ens diu com està el tamany de la nostra base de dades

• INFO - ens dóna tot un conjunt d'informació de com està la nostra bd, és especialment interessant veure i monitoritzar el tamany de la memòria.

  process_id:677 uptime_in_seconds:5349 uptime_in_days:0 connected_clients:14 connected_slaves:0 blocked_clients:4 used_memory:1551228 used_memory_human:1.48M changes_since_last_save:1111 bgsave_in_progress:0 last_save_time:1301824662 bgrewriteaof_in_progress:0 total_connections_received:509 total_commands_processed:7060 expired_keys:0 hash_max_zipmap_entries:64 hash_max_zipmap_value:512 pubsub_channels:1 pubsub_patterns:0 vm_enabled:0 role:master db0:keys=8,expires=0

• FLUSHDB - per netejar tota la base de dades activa de Redis.

• MONITOR - ens mostra què està passant, les claus que es generen, els resultats i les sentències que va executant Redis.

Conclusions

Amb Django, Celery i Redis hem aconseguit tenir un sistema de distribució de tasques simple, escalable i amb molts pocs requisits de màquina.

Redis es pot aprofitar tant pel sistema de cues com per la nostra aplicació, obrint-nos tot un món de possibilitats i mantenint baixa la complexitat de tota l'arquitectura.

Posar en marxa tot el sistema implica:

• Desenvolupar l'aplicació pensant en les tasques
• Configurar Redis
• Executar els workers
• Executar celerybeat per les tasques periòdiques si en tenim
• Executar el monitor

I òbviament anar monitoritzant-ho tot. Que ho disfruteu!

Aquest divendres passat hem finalitzat la mudança de l'antiga oficina d'APSL, 22 m² de l'Edifici Naorte del Parc Bit que teníem en règim d'incubació cap a la nova oficina, a l'Edifici NTIC, a 100 metres escasos, i ja de prop de 50 m². És una oficina compartida amb Pablo, de Pixelgrafic, no sé si se'n podrà dir co-working però la veritat que si assembla molt.

Encara ens quedaven un grapat de mesos en règim d'incubació al Parc Bit, però amb la incorporació de Juan (aka morenosan) ja ens tocava a poc més de 5 m² per barba i ens impedia rebre als clients i amics que ens venen a veure en condicions. Ara encara ens queda condicionar un poc més el nostre espai, ens falta encara una estanteria o dues i una taula, però temps al temps, el pressupost hi ha d'arribar i per ara era molt més necessari dotar a Juan de bones eines per fer feina, potser encara no tenim les estanteries, però Juan té un i5 amb 6 Gb de RAM i dos monitors de 23 polzades.

Alguns m'heu demanat si farem festa d'inauguració, la veritat és que m'agradaria, però hem de tenir en compte primer el fet que és una oficina compartida i no volem destorbar el nostre company i per l'altra, i potser més important, que les properes setmanes tenim dates d'entrega per a dos projectes i no ens sobra el temps.

Però tot arribarà, potser no farem acte d'inauguració, però alguna cosa farem, hi ha una terrassa molt gran al pis i hem de pensar com aprofitar-la. El que sí he de mirar encara és si encara podrem aprofitar les sales d'actes del Parc Bit, en sortir d'aquestes entregues volem de mirar de fer el primer Creant Bits d'enguany.

El canvi d'oficina també representa un nou repte, passam d'un lloguer molt assequible a un lloguer ja a preus de mercat, amb un contracte mínim d'un any i això significa molta més responsabilitat. La veritat és que estic molt agraït a l'oportunitat que ens ha donat el Parc Bit amb l'incubadora, ens ha donat l'oportunitat de saber si el nostre projecte era viable sense tenir-hi que invertir una gran quantitat inicial. Ara sabem que el projecte és viable, que muntar una empresa dedicada a la programació amb opensource té mercat i que a les nostres contrades també es poden dur a terme projectes importants fent feina amb Python i Django. Poser al final l'època de crisi en que ens trobam ens la jugarà, però no serà perquè la tecnologia o la idea no sigui vàlida.

Estam molt contents de poder fer feina amb Python i Django i al mateix temps encantats del rendiment que ens està donant la tecnologia i l'aprofitament dels servidors que tenim. Poder fer feina d'aquesta manera fa que un s'aixequi al matí i vagi a la feina més content, i sobretot que en surti amb la sensació d'haver fet quelcom de profit.

Així que si anau a l'oficina antiga i no em trobau no oblideu passar per l'NTIC, planta 2, despatx A, al carrer Ada Byron, encara que es digui NTIC l'edifici és ben nou!

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.

Segueixo amb la vena friki, ahir damunt el solapament d'intervals de mode genèric i avui veurem la implementació d'aquesta idea a un model Django.

class Oferta(models.Model):
    """Una oferta que va per rang"""
    nom = models.CharField(max_length=200)
    inici = models.DateField()
    fi = models.DateField()
    activa = models.BooleanField(default=True)

    class Meta:
        verbose_name="Oferta"
        verbose_name_plural="Ofertes"

    def __unicode__(self):
        return self.nom

El model com veis és molt senzill, una oferta pot estar activa o no i pertany sempre a un rang de dates. Queda fora de l'exemple la determinació de si admetem solapament de dates per una oferta, que es fareia de manera semblant al la cerca que ara farem.

La idea és que hem d'aconseguir que amb l'ORM de Django nodelar una consulta del tipus not ((x1<y0) or (y1<x0)).

Els filtres per defecte el que fan es un and, per la qual cosa no ens serveixen directament. El que farem és utilitzar una característica de l'ORM anomenada funció Q que ens permete afegir condicons de filtratge múltiples i fer que vaign per OR enlloc de per AND.

from django.db.models import Q

Ara sols queda fer la consulta. Particularment si són consultes que poden ser susceptibles de fer-se servir a varis llocs o que estan molt relacionades amb el model, m'agrada lligar-les al model amb un manager ad-hoc o bé amb un mètode estàtic, que és el que farme ara. Així:

@staticmethod
def ofertes_entre(pInici, pFi):
    return Oferta.objects.filter(activa=True). \
             exclude(Q(fi__lt=pInici)|Q(inici__gt=pFi)).order_by('-inici')

Fitxem-nos que el NOT de la consulta s'aconsegueix amb l'exclude i que feim servir la fució Q per afegir les dues condicions de comparació dins aquest filtre i les lligam per OR (|).

He afegit un grapat de dades d'exemple, i executat la consulta, que queda com

Oferta.ofertes_entre(f1, f2)

Ho he fet des de línia de comandes, de manera que ara puc veure la query que es genera:

>>from django.db import connection
>>>connection.queries

'sql': u'SELECT "oferta_oferta"."id", "oferta_oferta"."nom",
"oferta_oferta"."inici", "oferta_oferta"."fi", "oferta_oferta"."activa" FROM "oferta_oferta" WHERE ("oferta_oferta"."activa" = True AND NOT (("oferta_oferta"."fi" < 2011-03-20 OR "oferta_oferta"."inici" > 2011-04-20 ))) ORDER BY "oferta_oferta"."inici"

Com m'agrada Django!

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.

Aquests dies estic bastant engrescat i enfeinat amb projectes molt relacionats amb Python i Django. Per una banda estam definit i creant el que serà la segona fase del projecte Clickote, una aproximació simpàtica a les reserves d'hotel en la qual estam passant molt de gust fent-hi feina. Per una altra banda estam migrant un aplicació web feta inicialment amb ezPublish, un CMS dels de tota la vida, cap a Django.

Clickote és un projecte en el qual m'està agradant molt fer-hi feina perquè a més del projecte i la tecnologia en sí, ve a demostrar que client i proveïdor de serveis no són antagonistes, sinó que són col·laboradors. Amb l'equip de Clickote ens hi sentim molt bé fent-hi feina. Hem topat amb gent que no tan sols coneix el negoci, sinó que a més és conscient de la part tecnològica i de les implicacions en temps i esforç del que demanen, i sempre hem arribat a solucions beneficioses per al projecte.

La migració d'un lloc web des del CMS ezPublish cap a un CMS fet a mida amb Django és també tot un repte i representa també tot una aposta de futur per part del client. A les primeres etapes del canvi ja hem notat un augment del rendiment en temps de renderització de les planes d'un 30% de l'aplicació Django, motivat fonamentalment pel gran grau de control que es té a Django damunt el que es passa a la plantilla i com es passa. ezPublish no és un sistema MVC i quan hi ha lògica complexa pel mig, es queda molt curt comparat amb les possibilitats que et dóna Django. La creació d'un middleware ad-hoc, tags, l'herència de plantilles, la facilitat per crear serveis Ajax, ... Django com a CMS no es posa en el teu camí, ben al contrari, t'ajuda a crear l'aplicació i a optimitzar-la. Quan fas una migració com aquesta entens ben bé la frase del que el bastiment Django és per a "perfeccionistes amb dates d'entrega". Encara ens hi estarem un grapat de setmanes a la migració, en acabar esper poder posar-ho com a exemple de cas d'èxit, o si més no d'aprendre'n de l'experiència.

El cap de setmana passat vaig estar llegint "Maldito Karma" de David Safier, una lectura divertida amb cert tocs d'humor àcid que és llegeix molt bé, com un vi blanc jove fresquet a una tarda calorosa d'estiu.

No sé si serà cosa de la influència del llibre o no, però això de poder fer feia amb el que m'agrada, amb companys i clients com aquests, segur que em fa venir bon karma.

Els cap de setmanes mira que intento estar una mica allunyat de la programació, intent llegir, passejar un poc i estar amb la família, però quan arriba el vespre i l'opció és convertir-se ja en un xuclador passiu d'anuncis publicitaris ja no puc més. Amb el temps el meu nivell de tolerància a les pauses publicitàries ha baixat molt. Ja no puc aguantar més de tres minuts, mir el mòbil a veure quines piulades noves hi ha al twitter, llegeixo un poc, ... Però si la pausa ja es fa massa gran ja m'avorreixo, no m'agrada estar avorrit, així que sovint acab davant l'ordinador, a provar idees, ...

Aquest cap de setmana m'ha passat això. Estava provant una web que hem fet que connecta amb un web service i se m'ha passat pel cap emular el servei, creant el meu propi servei web a efectes de test. Si ho pensau bé és una xorrada: es fan les peticions contra el servei real i es guarden les respostes. Després sols hem de substituir el servei real amb el nostre i en funció de les peticions enviar les respostes predefinides que hem capturat.

La primera intenció era fer-ho amb Django, però fet i fet el servei és tan simple que no necessita de tot l'aparell i funcionalitat de Django. Era hora de cercar un micro-framework ·[1]. De micro-frameworks per Python n'hi ha per donar i remanar. En aquest cas vaig optar per provar-ne un que m'agrada força, el bottle, més que res perquè es un sol mòdul, no té dependències externes i està ben documentat. Un hello world és

from bottle import route, run
@route('/:name')
def index(name='World'):
    return '<b>Hello %s!</b>' % name
run(host='localhost', port=8080)

Com que es tracta d'obtenir i tractar peticions xml [2] vaig utilitzar també la llibreria lxml. Així es tracta de capturar una petició xml que es reb via POST i en funció del contingut d'aquest xml enviar una resposta predefinida com a resposta.

La cosa queda així:

#-*- coding: UTF-8 -*-
from bottle import route, run, request
from lxml import etree
import os
app_root = os.path.abspath(os.path.dirname(__file__))
@route('/', method='POST')
def fake_ws():
    body = request.body.read()
    root = etree.fromstring(body).getroottree()
    rq = root.getroot().tag
    if rq == 'op1':
        arx =  os.path.join(app_root, 'rta/op1.xml')
    elif rq == 'op2:
        arx = os.path.join(app_root, 'rta/op2.xml')
    #etc
    #ja es veu com pot anar no?
    return  open(arx, 'r').read()
run(host='localhost', port=9090, reloader=True)

Donant-li nom a l'arxiu i executant-lo tindrem un servei web xorra escoltant al port 9090 i que per testejar va més que bé.

Òbviament convertir això en un vertader servei que en lloc de respostes predefinides faci més feina és sols cosa de programar. Estendre el servei de proves a més opcions o contemplar altres casos, és també igual de senzill.

Està clar que això ho podem fer en gairebé qualsevol llenguatge. Python en aquest cas el que té és que ens dóna unes eines molt potents i simples. No hem de recompilar res, podem anar afegit nous exemples per testejar de manera trivial i el millor de tot, el servidor de test és tant senzill que no introdueix renou addicional a l'hora de provar. Com que les respostes les tenim predefinides podem optar per enviar-ne una o altra segons convengui, modificar-la per tractar casos frontera, o bé tractar-les com a una plantilla, Bottle té també un mini-llenguatge de plantilles, i que la resposta varii segons ens convengui.

[1] Bé, ho podria haver fet amb el servidor web que duu la llibreria estàndard de Python, però què voleu, m'encanten aquestes coses!

[2] També hi ha eines que farien bé la feina a la llibreria de Python, com l'xml.etree però m'agrada lxml.

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.

Aquesta setmana he estat força entretingut, m'he estat mirant un grapat de llibreries i utilitats, algunes d'elles noves versions que han anat evolucionant i millorant al llarg del temps. També vaig tenir l'oportunitat d'assistir a la xerrada de Maria Antònia Mas Pichaco damunt la guia PMBOK®, gràcies a l'empenta de Paco que em va recordar que es donava la xerrada. A part de la conferència en sí, també va estar molt bé el cafetó i la xerrada amb Paco, això de contar batalletes i compartir opinions no s'ha de perdre Paco! :)

Xerrada de PMBOK®

Si anam per ordre el primer seria parlar de la xerrada de Maria Antònia. A diferència d'altres assistents que l'havien tinguda com a professora, era la primera vegada que l'escoltava. Em va agradar, la exposició va ser clara i entretinguda. M'hauré de llegir la guia per poder-ne fer una avaluació en profunditat, però pel que vaig entendre es tracta d'un conjunt de recomanacions i millors pràctiques que cobreixen el cicle de la gestió de projectes, però que en cap cas ens marca un camí a seguir o una metodologia. Supòs que la utilitat vindrà quan ja hagis elegit com gestionar un projecte.

En la part anecdòtica me va fer gràcia quan un dels punts de la gestió del projecte consistia en "triar l'equip de gent". Em va recordar a aquelles pel·lícules on l'heroi va cercant l'equip en els llocs més inversemblants, sempre els millors en el que fan, per conformar un equip invencible. Bé, la realitat és que poques vegades tens ocasió de fer això, però quan pots és molt engrescador. El més normal és que l'equip et vengui donat i llavors el que s'ha de fer és tractar d'esbrinar quines mancances i quines aptituds té cada membre de l'equip per arribar a dur a terme el projecte. Seguint amb el símil fílmic, és mes semblant a les pel·lícules on l'entrenador agafa un equip que no coneix i el duu cap a la fita proposada (sempre amb final feliç).

Em va dur molts records una altra frase "un projecte ha de tenir una data de finalització", ja que és una discussió que havia tingut en algunes ocasions amb certa gent. Per mi un projecte comença, es desenvolupa i acaba, tal com també va dir Maria Antònia, tot el que no té dada de finalització entra dins la part d'operacions.

LibreOffice

Al portàtil de casa he substituït ja l'OpenOffice per LibreOffice, la migració va ser molt senzilla i per ara no he detectat cap problema. Pareix més ràpid i no dóna problemes amb el Firefox. No sé si me passa a mi sols, però amb l'OpenOffice i el Firefox en marxa les operacions de tallar i aferrar es feien eternes, ara això no passa. També he trobat millores curioses, com la possibilitat de tenir colors a les pipelles de les fulles de càlcul, opció que ja tenia el Quattro Pro de Borland i que el pas en massa de les empreses cap a Excel va deixar a l'oblit. Com a altra avantatja la millora a la pantalla de càrrega que li dóna un aire un poc més fresc i la millora en la navegació.

VirtualBox 4

He actualitzat el programa VirtualBox a la darrera versió, l'actualització des de la 3.2 és trivial i no s'han perdut màquines virtuals. El temps d'arrencada de l'aplicació i de les màquines virtuals ha millorat molt i també ho ha fet la interfície gràfica d'administració. A més ara té la possibilitat de connectar-se en remot a una màquina virtual mitjançant el protocol RDP, bé en sessió única o en multi sessió. Així dins una Ubuntu 10.10 tenia dues màquines virtuals, una Ubuntu 10.04 i un Windows XP (l'original que va venir amb el portàtil), aquest XP estava connectat via RDP a la màquina virtual Ubuntu i s'hi podi interactuar veient l'arrancada i tot. Des de l'altra ordinador, el PPC, també vaig connectar via remote desktop a la màquina virtual Ubuntu. Divertit i amb moltes possibilitats.

Sorl thumbnail

Sorl es una llibreria per a la gestió d'imatges per Django. És una reescriptura d'una versió anterior pràcticament des de zero. Incorpora totes les possibilitats de la versió anterior però ara de manera molt més transparent i entenidora. Han millorat com es fa caché de les imatges incorporant Redis com a opció de magatzem de claus, opció per distingir el tipus d'orientació de la imatges i un control per determinar si la imatges existeix o no (per exemple en remot quan dóna un 404) i actuar en conseqüència.

A les properes setmanes esper poder parlar de la sortida de Django 1.3 i de Celery. No sé què em fa més patxoca. Per una part Django 1.3 significarà que ja s'avança cap al 1.4, versió que està previst que incorporarà moltes més novetats que la 1.3 que és una versió més de correcció de petits errors i en general petites funcionalitats. Celery, la llibreries de cues per Python i Django també treurà aviat una nova versió. N'estic molt pendent ja que incorpora compressió de missatges, autoescalat, un nou protocol més eficient, ... Per ara m'he llegit la documentació i he de començar a preparar algunes de les nostres aplicacions que fan servir la llibreria migrant a l'actual Release Candidate i veure'n el camí de migració. Ja en xerrarem!

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.

Configuració del servidor rabbitmq

El servidor Rabbitmq és qui rebrà les ordre d'execució de les tasques i les enviarà als workers que han de fer la feina i rebrà el resultats de les operacions de manera que el procés que ha donat l'ordre d'execució de la tasca el pugui fer servir.

És important destacar que a l'hora de donar l'ordre d'execució podem decidir si el resultat s'ha de guardar o bé s'ha de descartar. Si el resultat no és necessari (pensem per exemple en l'enviament d'un e-mail) llavors convé marcar la tasca per a que el resultat es descarti.

sudo aptitude install rabbitmq-server
Els paquets nous següents s'instal·laran:           
  erlang-os-mon{a} erlang-snmp{a} rabbitmq-server 
0 paquets a actualitzar, 3 a instal·lar, 0 a suprimir i 5 a no actualitzar.
Es necessita obtenir 1398kB d'arxius. Després del desempaquetat s'utilitzaran 3187kB.
Esteu segur de voler continuar? [Y/n/?] y
Obté:1 http://es.archive.ubuntu.com/ubuntu/ maverick/main erlang-snmp i386 1:13.b.3-dfsg-2ubuntu3 [581kB]
Obté:2 http://es.archive.ubuntu.com/ubuntu/ maverick/main erlang-os-mon i386 1:13.b.3-dfsg-2ubuntu3 [77,4kB]
Obté:3 http://es.archive.ubuntu.com/ubuntu/ maverick/main rabbitmq-server all 1.8.0-1ubuntu2 [739kB]
S'han obtingut 1398kB en 2s (480kB/s)   
S'estan preconfigurant els paquets...
S'està seleccionant el paquet erlang-snmp prèviament no seleccionat.
(S'està llegint la base de dades … hi ha 118931 fitxers i directoris instal·lats actualment.)
S'està desempaquetant erlang-snmp (de …/erlang-snmp_1%3a13.b.3-dfsg-2ubuntu3_i386.deb) …
S'està seleccionant el paquet erlang-os-mon prèviament no seleccionat.
S'està desempaquetant erlang-os-mon (de …/erlang-os-mon_1%3a13.b.3-dfsg-2ubuntu3_i386.deb) …
S'està seleccionant el paquet rabbitmq-server prèviament no seleccionat.
S'està desempaquetant rabbitmq-server (de …/rabbitmq-server_1.8.0-1ubuntu2_all.deb) …
S'estan processant els activadors per a man-db …
S'estan processant els activadors per a ureadahead …
S'està configurant erlang-snmp (1:13.b.3-dfsg-2ubuntu3) …
S'està configurant erlang-os-mon (1:13.b.3-dfsg-2ubuntu3) …
S'està configurant rabbitmq-server (1.8.0-1ubuntu2) …
Adding group `rabbitmq' (GID 123) ...
Fet.
Adding system user `rabbitmq' (UID 115) ...
Adding new user `rabbitmq' (UID 115) with group `rabbitmq' ...
Not creating home directory `/var/lib/rabbitmq'.
Starting rabbitmq-server: SUCCESS
rabbitmq-server.

Amb això hem aconsegui instal·lar i posar en marxa el RabbitMq en un sistema Ubuntu 10.10. Ara ens queda configurar, afegirem un usuari i un vhost per a que accepti els treballs, a més hem de donar permisos a aquest usuari per a que que pugui enviar treballs al vhost creat.

Afegim l'usuari:

$ sudo su
$ rabbitmqctl add_user django password
Creating user "django" ...
...done.

Cream l'vhost

$ rabbitmqctl add_vhost test
Creating vhost "test" ...
...done.

Assignam els permisos a l'usuari per a quest vhost

$rabbitmqctl set_permissions -p test django ".*" ".*" ".*"

Setting permissions for user "django" in vhost "test" ...
...done.

Ja tenim la part més complexa llesta. El servidor RabbitMQ pot estar en la mateixa màquina o en una totalment distinta de la que llançarà la tasca o de la màquina de l'executarà.

Preparant l'entorn

La gràcia del Celery és que ens permet llançar les tasques i executarles mantinguent la cohesió de la nostra aplicació. És a dir, si estam treballant amb Django Celery ens permet manetenir el codi de cridada i d'execució de la tasca des de la mateixa aplicació o des del mateix projecte.

Per començar convé que instal·lem Celery. Ho farem des de un entorn virtual, per això convé tenir instal·lats els paquets virtualenv i virtualenvwrapper.

sudo pip install virtualenv virtualenvwrapper

i configurar el virtualenvwrapper.

Crear l'entorn, de nom per exemple celery i instal·larem el paquet celery

mkvirtualenv celery
workon celery
pip install celery

Que sigui un projecte Django o Python pur té molt poques diferències. En el cas de Django hem d'instal·lar el paquet django-celery i configurar el projecte. Així a les nostres aplicacions afegirem "djcelery"

INSTALLED_APPS += ("djcelery", )

I també és important afegir les següents línies al settings.py

import djcelery
djcelery.setup_loader()

La resta es comú tant a un projecte Python que a un projecte Django, sols que les configuracions en el primer cas aniran a un arxiu anomenat celeryconfig.py i en el cas de django la configuració pot anar dins el settings.py

Per la nostra primera tasca crearem un project Python simple i l'arxiu de configuració celeryconfig.py contindrà

#-*- coding: UTF-8 -*-

BROKER_HOST = "192.168.1.10"
BROKER_PORT = 5672
BROKER_USER = "django"
BROKER_PASSWORD = "password"
BROKER_VHOST = "test"
CELERY_RESULT_BACKEND = "amqp"
CELERY_IMPORTS = ("tasks", )
CELERY_SEND_EVENTS=True

El prefixe BROKER fa referència al servidor RabbitMq que acabam d'instal·lar. Celery pot fer servir difernts tipus de Brookers pero RabbitMq és el més recomanat.

Fitxau-vos que el configuram amb els paràmetres amb els quals hem creat el vhost, i amb l'usuari i password creats a RabbitMq.

CELERY_RESULT_BACKEND serveix per a indicar a Celery on s'han de deixar els resultats. Podem tenir distints backends, des de Memcached, a una base de dades o una base de dades NoSQL.

CELERY_IMPORTS indica a l'aplicació que tasks.py conté les tasques que s'han d'executar. Bé, de fet el que fa és indicar al daemon de celery quines són les tasques a exeuctar quan es posi en marxa, però també pot fer-se servir per altres tipus d'inicialitzacions.

CELERY_SEND_EVENTS li diu a Celery que volem monitoritzar els events que es produeixin. Si no posam aquesta ordre i després volem saber què esta passant ho tendrem molt més complicat.

Creant la nostra primera tasca

Per cerar la nostra primea tasca crearem una arxiu anomenat tasks.py

#-*- coding: UTF-8 -*-

from celery.decorators import task

@task(name='tasks.add')
def add(x,y, **kwargs):
    logger=add.get_logger(**kwargs)
    logger.info('Entrant a la tasca ...')
    return x+y

Fitxem-nos que és codi Python del més normalet, sols que hem afegit un decorador tasks per marcar la funció com a tasca i posar-li el nom. Aquest nom és opcional, però convé posar-li ja que així evitam que celery li posi un nom per defecte que podria fer menys portable la nostra aplicació.

També podem veure como podem enviar informació a logger des de la tasca.

Executant el worker

Ara ja podem anar al nostre projecte, si tot ha anat bé tindrem dos arxius: tasks.py i celeryconfig.py

Executam: celeryd -l info

[2010-11-28 18:44:20,949: WARNING/MainProcess] celery@D820 v2.1.3 is starting.
[2010-11-28 18:44:20,950: WARNING/MainProcess]  
Configuration ->
    . broker -> amqp://django@192.168.1.10:5672/test
    . queues ->
        . celery -> exchange:celery (direct) binding:celery
    . concurrency -> 2
    . loader -> celery.loaders.default.Loader
    . logfile -> [stderr]@INFO
    . events -> ON
    . beat -> OFF
    . tasks ->
    . tasks.add
[2010-11-28 18:44:20,960: INFO/PoolWorker-1] child process calling self.run()
[2010-11-28 18:44:20,962: INFO/PoolWorker-2] child process calling self.run()
[2010-11-28 18:44:20,963: WARNING/MainProcess] celery@D820 has started.

amb això hem creat el nostre primer worker preparat per a executar la tasca que li diguem (i que estarà dins tasks.py). Per aquest article hem deixat el worker dins al consola, però es pot deixar com a dimoni. Consulteu el vostre administrador de sistemes de capçalera per a una configuració acurada. El paràmetre que li passa indica que volem que generi log en mode info. Fixem-nos que també ens informa de les tasques disponibles i del nivell de concurrència que tenim, 2 en el meu cas, que és el nombre de processadors del portàtil.

I executam la tasca

Des d'una altra consola executarem l'interpret de Python

>>>from tasks import add
>>>result = add.delay(2,3)

Si ara observam la consola del worker veurem alguna cosa semblant a això:

[2010-11-28 18:46:57,783: INFO/MainProcess] Got task from broker: tasks.add[c379421f-fa6a-4917-b45a-4833a9e30ef3]
[2010-11-28 18:46:57,830: INFO/PoolWorker-2] [tasks.add(c379421f-fa6a-4917-b45a-4833a9e30ef3)] Entrant a la tasca ...
[2010-11-28 18:46:57,879: INFO/MainProcess] Task tasks.add[c379421f-fa6a-4917-b45a-4833a9e30ef3] succeeded in 0.0486330986023s: 5

El brooker (RambbitMQ) ha enviat l'ordre d'execució de la tasca add que el worker té registrada i aquest es disposa a executar-la.

Des de la consola hem dit a la coa que volíem que la tasca s'executàs en modoe asíncron, d'aquí l'ús de delay.

Si ara volem obtenir el resultat farem

>>> print result.get()
    5

Com es pot veure l'exemple és molt senzill, potser massa per adonar-nos de la potència de Celery. Pensem que en lloc d'una suma podem fer la generació d'un pdf, l'enviament d'un e-mail, la càrrega en batch d'un xml, etc. etc. L'important és que el procés principal ja no té que realitzar la tasca i pot ser una altra màquina l'encarregada de fer-ho. Pensem en una màquina plena de targes gràfiques dedicades al processament numèric, en un sistema encarregat del data-mining dels logs, les possibilitats són infinites.

També és important notar l'escalabilitat que aconseguim amb Celery. No estam parlant ja d'escalabilitat amb nombre de processadors, sinó que parlam d'escalabilitat amb nombre de màquines. Mentre les nostres tasques puguin ser paralelitzades podrem fer servir Celery per a distribuir la càrrega de feina entre les màquines disponibles.

I això és sols el principi: celery pot substituir al Cron, permet la monitorització, la creació de tasques molt més complexes que les que ens permet una funció i un llarg etcètera d'opcions. La documentació és força completa, però llevat de casos molt especial, el grau de dificultat que trobarem és el que hi ha a aquest post.

Introducció a Celery

Celery es una aplicació que ens permet crear tasques de feina asíncrones gestionades per un gestor de cues que està basada en l'enviament de missatges de manera distribuïda. Es focalitza en operacions en temps real però també suporta la calendarització de tasques.

Les unitats d'execució, anomenades tasques, s'executen de manera concurrent en un o més nodes de treball. Aquestes tasques poden executar-se de manera asíncrona bé de manera síncrona (esperant fins que la tasca està llesta).

El sistema de missatgeria recomanat per celery és RabbitMQ encara que és bastant agnòstic en el tema i pot fer servir com a substitut Redis, MongoDB o una base de dades sql.

Encara que el programa va sorgir lligat a Django, actualment és una llibreria que es pot utilitzar de manera independent. S'han creat dos projectes a partir de l'original, Celery manté l'estructura bàsica de la llibreria i django-celery manté la integració amb Django.

Bé, fins aquí la parrafada d'introducció traduïda amb més o menys fortuna de la documentació de Celery, el que estam dien és que celery ens permet executar tasques de manera distribuïda, on el director d'orquestra (si seguim les recomanacions) és una aplicació anomenada RabbitMQ, escrita en Erlang, per cert, que se n'encarrega de rebre les ordres de les tasques que s'han d'executar i les distribueix entre els distints nodes que estan registrats per a executar dita tasca. Aquest director és el que se n'encarrega de saber com està cada tasca i d'obtenir-ne el resultat quan aquesta finalitza, de manera que el programa que ha encomanat la tasca.

Així dons hem de distingir tres actors en tot això, l'aplicació que comana la tasca, l'aplicació que executa la tasca (el worker) i l'aplicació que se n'encarrega de la comunicació entre qui comana la tasca i qui l'execute. La gràcia de tot això és que podem tenir més d'un worker a distintes màquines o a la mateixa màquina, de tal manera que el gestor se n'encarrega de repartir les tasques en funció de qui està lliure per executar-les.

Pensem un noment amb el que això significa: podem passar de tenir una aplicació que ho fa tot, a un conjunt d'aplicacions que poden estar en distintes màquines que col·laboren entre sí. Resumint: ens permet l'escalabilitat horitzontal.

Per què fer servir Celery?

Abans de Celery la meva experiència havia estat amb Beanstalkd, un sistema semblant, molt simple i ràpid. Ara us contaré una batalleta, estant de cap de projecte per Tui España un dels projectes que duia era el de la creació d'un servei web per a la venda on-line de transfers i excursions. La informació estava (i supòs que encara hi és) a una base de dades Oracle i amb una estructura pensada per a introduir-hi informació, de manera que fer una consulta un poc complexa com "vull totes les excursions que hi ha tal dia que es poden fer des de tal punt" era extremadament lent. La solució que trobàrem va ser desnormalitzar la informació passant-la cap a una base de dades Postgresql, un parell mallorquí de milions de registres que s'actualitzaven diàriament.

La primera versió del programa de càrrega estava fet amb Java, va ser complexe de crear, gairebé 3 mesos de feina, mal de mantenir i executant-ho tot amb fils estava gairebé 2 hores en tenir-ho tot carregat.

La segona versió la férem amb Python, una setmana i mitja, un 10% del codi, més funcionalitat i utilitzarem Beanstalk per a distribuir les tasques, ja que la càrrega en sí es podia particionar molt bé. Això ens permeté aprofitar la potència de servidors que estaven ociosos i aprofitar també els temps morts entre la consulta a Oracle, el parseig de la resposta i la introducció a Postgres. A una de les proves posarem en marxa processos a 4 servidors diferents, amb un total d'uns 20 workers i un temps de càrrega d'uns 3 minuts. Amb 2 servidors el temps era d'uns 5 minuts, una millora molt significativa respecte a l'aplicació Java.

Així doncs una de les utilitat que tenim és la de poder distribuir tasques molt pesades entre moltes màquines. Celery el que té molt millor que Beanstalk és una documentació molt acurada, sistemes de monitorització i gestió i en el cas de fer servir Django, la possibilitat de mantenir les tasques dins el mateix projecte.

El segon ús important de Celery és la web. En aplicacions web el que volem és donar la millor experiència d'usuari possible, i aquesta experiència es degrada si l'usuari ha d'esperar molt. El que ens interessa és donar la resposta a l'usuari de que la seva comanda s'està està executant i deixar el servidor web lliure per poder atendre altres peticions. Imaginem-nos per exemple una aplicació de comerç electrònic on l'usuari demana una factura i aquesta li arriba en pdf. En sistemes de molta càrrega la generació del pdf pot degradar la resposta global de la web, el que és interessant és poder enviar la petició de factura a un sistema extern a la web i que sigui aquest l'encarregat de la generació i l'enviament. Aquest sistema no té perquè estar ni tant sols a la mateixa màquina on hi ha l'aplicació web o poden aprofitar-se hores de poca càrrega per a fer-ne la generació i l'enviament.

Anar cap a la complexitat d'arquitectura que representa afegir un sistema de cues asíncron a la nostra aplicació implica voler anar cap a un aprofitament dels recursos i sobretot entendre com funciona la nostra aplicació, què s'ha de fer de manera immediata i què es pot fer de manera asíncrona, saber quines són les tasques més feixugues que ens afecten i com podem paralelitzar-les i distribuir-les. L'altra solució és posar més màquina amb n-mil cores i passar de tot, però a més de ser una opció econòmicament més cara i tècnicament discutible, és una opció a curt termini, ja que si la nostra aplicació té molt èxit pot arribar un moment on ja ni hi hagi màquines més grans o el cost de les mateixes es mengi tot els nostres beneficis. Podem acabar fent feina pel fabricant de hardware i per pagar-ne les llicències associades.

Convençuts? Esper que sí. Un sistema així no és per totes les aplicacions, la complexitat d'instal·lació i manteniment és més gran que tenir tot el sistema en una màquina i sense distribuir, però si teniu necessitats de fer càlculs intensius de manera puntual o tasques per les quals no voleu fer esperar l'usuari Celery és una molt bona solució. A més pensau amb sistemes com el núvol d'Amazon, puntualment podem aixecar-ne tantes instàncies com calgui i executar-ne workers, o imaginem un Datacenter propi on la majoria de servidors estan ociosos, podem posar workers a les màquiens amb mensy càrrega per a que ajudin en els processos pesats. Se'ns obre un ventall de possibilitat pràcticament il·limitat.

En el proper post, instal·lació de Celery, la creació d'una tasca i un exemple d'integració amb Django, així com problemes que ens podem trobar i com a evitar-los.

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ó.

Aquests darrers dies he estat mirant els vídeos de la darrera Djangocon, com a tota conferència hi ha gent que vol una cosa més tècnica i gent que la troba massa tècnica, però particularment trob que al la quantitat de conferències i lightning talks que hi ha qui no ha trobat el que volia segurament és perquè no ha cercat prou.

Jo he trobat molt interessants dues conferències, Scaling the World's Largest Django Application de la gent de DisqUs i Switching addons.mozilla.org from CakePHP to Django de la gent de Mozilla add-ons. M'interessen molt perquè mostre tant els problemes com la capacitat de Django per escalar per aplicacions molt grans, molt més grans del que estam acostumats per les nostres contrades. En el cas de Mozilla les xifres que donen el rendiment de programació estan en la línia del les meves pròpies recerques: una aplicació Django necessita de l'ordre de 3-5 vegades més línies de codi que per fer-la en PHP un framework com Cake.

Aquests projectes tan grans fan que s'hagin de cercar solucions a problemes comuns d'escalabilitat. L'interessant d'aquests conferències és que et diuen tant els problemes que s'han trobat com les solucions. Pel Twitter he postejat algunes vegades referències al projecte Celery el gestor de cues que s'està convertint en l'estàndard de facto per Python i Django i que fan servir aquests projectes. Però també ens ha permet veure com utilitzen Sentry una eina per la gestió unificada de logs.

Sentry és una aplicació integrable amb Django que ens permet unificar els nostres logs en un únic servidor i integrar les notificacions d'error i incidències al nivell que vulguem i com vulguen. Ho podem posar integrat dins la nostra aplicació o tenir un servidor independent i fer que els n servidors que composen la nostra aplicació enviïn els missatges per http o per una coa Celery. La solució és força elegant i potent, de fet força més potent del que es pot trobar per Java/J2EE i és una solució a un dels problemes més comuns quan es tenen múltiples servidors: la necessitat de tenir logs unificats per saber què està passant i a on està passant.

Encara em queden força conferència a veure, però tampoc vull endur-me'n un empatx, i a més s'ha de tenir temps per avaluar altres projectes més propers. Per exemple, en aquests moments estic avaluant si per les aplicacions que feim és millor disposar d'un blog separat amb WordPress o bé d'un blog, potser visualment menys atractiu, però que s'integri totalment amb les aplicacions Django. Encara no tenc cap conclusió en ferm, però ara per ara la flexibilitat que ens dóna la integració.

Quan un es dedica a la programació seriosa amb Python (ja sigui amb Django o amb qualsevol altre framework) hi ha un parell de coses que s'han de tenir en compte: saber amb quina versió de Python programarem i si aquesta versió estarà suportada per la distribució del servidor de producció és una d'elles, potser la més simple. Una altra un poc més complexa és la de plantejar-nos des del principi com durem el mantenimient de l'aplicació.

Amb els servidors dedicats cada cop a més bon preu, no és genys extrany plantejar-se tenir un servidor dedicat per les nostres aplicacions web en Python per exemple. És també molt habitual que les aplicacions tenguin un cicle de vida molt més llarg que les llibreries que hem utilitzat per a crear-les. Ara podem fer servir la versió 1.2.3 de Django, però d'aquí tres o quatre mesos tindrem la 1.3, amb altres llibreries pot passar una cosa semblant.

Quan tenim una aplicació en producció la màxima sempre ha de ser la de si no està trencat no ho arreglis. Si la nostra aplicació funciona amb Django 1.1 i hem anat aplicant els pegats de seguretat, llavors plantejar-nos migrar a una versió major és quelcom que s'ha de plantejar amb cura i sempre tinguent en compte la relació risc benefici que comportarà l'actualització. Així doncs ens podem plantejar no actualitzar una aplicació, però no per això les seguents aplicacions que desenvolupem tenen que fer-se forçosament amb llibreries antigues.

Com manteneir doncs entorns separats? Si instal·lam les llibreries a nivell de la nostra distribució de Linux preferida l'actualització de llibreries i fins i tot del mateix Python es farà a nivell de tot el sistema. Necessitam quelcom que ens aïlli tot allò que utilitzam a la nostra aplicació. Aquesta eina té un nom: virtualenv creada per l'omnipresent Ian Bicking.

Aquesta utilitat ens crea un entorn separat de Python amb les llibreries que nosaltres hi instal·lem. Si no li deim res utilitzarà també les llibreries del sistema posant-les al PYTHONPATH, però també podem fer que la separació sigui del tot completa fent servir l'opció de '--no-site-packages'. Aquesta opció fa que l'entorn virtual no faci servir cap llibreria del path del sistema i ens permet instal·lar-ho to. És l'opció que a mi m'agrada més, encara que signfifiqui perdre més temps amb la instal·lació, em dona la seguretat de que sé exactament tot allò que necessit per la meva aplicació.

El manual del virtualenv està prou explicat, però tot i això jo no recomanaria fer-lo servir a pèl, sinó amb l'ajud de una altra utilitat anomenada virtualenvwrapper de Dough Hellman.

Aquesta eina ens permet gestionar de manera molt senzilla els nostres entorns virtuals, posar-los en un únic punt del sistema i ens proporciona una gran quantitat de hooks que ens permeten definir que volem fer cada cop que es crei un entorn virtual, o que s'elimini, o que s'activi o desactivi.

Així, per exemple, podem fer que cada cop que activem un entorn virtual s'actualitzi el repositori del control de versions, o que ens situi al punt exacte on tenim el codi. Si sempre feim servir Django als nostre projectes podem fer que cada cop que es crei un entorn virtual se'ns instal·lin també les llibreries que més utilitzam.

Per acabar-ho de rematar la utilitat pip instal·lador avançat de codi Python del que ja he parlat en altres apunts, s'acobla molt bé als entorns virtuals, fins i tot li podem dir que no instal·li res si no estam a un d'aquests entorns.

Si feim servir un entorn virtual i pip podem utilitzar llavors la comanda pip freeze quen es dirà exactament què hi ha a l'entorn virtual: paquets i nombre de versió o revisió quan s'ha instal·lant des de codi font. Així podem crear fàcilment un fitxer de requermients pip i asseguar-nos que quan posem l'aplicació a producció les llibreries que es facin servir siguin exactament les mateixes que hem fet servir a desenvolupament.

Si us plantejau fer servir Python en els vostres desenvolupaments un dels millors consells que us puc donar és que dediqueu unes quantes hores a estudiar virtualenv, virtualenvwrapper i pip, la vostra vida a partir d'aquest moment ja no serà la mateixa.

Aquestes darreres setmanes han estat d'allò més interessants, caloroses però interessants.

La calor ha vingut fonamentalment d'uns dies que hem passat a Menorca. Ja hi havia anat una vegada de vacances i me va encantar, aquesta vegada no ha estat diferent, encara que hi havia molta més gent que la darrera vegada.

Però no vull donar enveja, així que també toca parlar de programació. Aquests dies hem estat i encara estarem durant unes quantes setmanes més, fent feina amb un projecte que implica fer feina amb un cms anomenat ezPublish.

L'ezPublish és un CMS prou potent, orientat a treure continguts sigui com sigui. Tu escrius el que sigui a la part de l'administrador i l'eZ intentarà renderitzar-ho com pugui. Supòs que si el que importa és el contingut en sí això és fantàstic, però quan es tracta d'afegir-hi regles de negoci per damunt eZPublish és un malson comparat amb frameworks com Django.

Està clar que no podem fer una comparació justa ja que ezPublish no té la flexibilitat d'un framework però crec que l'experiència serveix per reafirmar-me amb l'apreciació de que si el teu negoci no és generar continguts sinó que vols controlar el que passa a la web i per exemple vendre el teu producte, construir l'aplicació directament damunt un CMS és un malson.

Moltes aplicacions necessiten d'un CMS, bàsicament per independitzar la creació de planes del programador que ha fet l'aplicació, però això no vol dir que el CMS tengui que ser l'aplicació. El CMS no ha de ser intrussiu, hauria de limitar-se a una backoffice potent i a ser possible integrable i una API per poder accedir als continguts de la manera que nosaltres vulguem.

El CMS ens permet començar molt ràpid a afegir texts, però com dic, si la nostra web no és estrictament de continguts aviat el CMS es converteix en un problema, ja que te condiciona la manera de fer les coses. Personalment preferesc sol.lucions com Django Page CMS que funcionen a mena de plugin per a les nostres aplicacions. Sóm nosaltres que decidim quin contingut es presenta i com. Potser la interfície no és tan virguera com altres CMS dedicats, però al manco el CMS no es posa en el nostre camí i no ens condiciona.

Un altre CMS per Django que darrerament m'està agradant molt és el projecte Django cms. Si bé és pot considerar ja un CMS en sentit habitual, segueix essent poc intrussiu, podem afegir tant plugins propis del CMS com seguir amb les aplicacions Django que vulguem i l'administrador seguirà funcionant.

Una altra aproximació per Django és lfcms però en aquest cas més que "per Django" hauríem de dir fet amb Django. Aquí ja parlar d'un CMS complet amb el seu propi administrador que és extensible mitjançant plugins fets amb Python. La interfície està molt cuidada i és un CMS a tenir molt en compte si la nostra aplicació és bàsicament de continguts. L'emperò més gran és que necessitam accedir a dues interfícies per fer algunes coses. Per exemple si tenim contingut estructurat i contingut textual, el contingut estructurat l'haurem de gestionar per l'administrador de Django (o fer-ne un nosaltres) i el textual pel backoffice de lfcms. He d'investigar-ho un poc més potser hi ha una manera d'aprofitar tota la fona feina que han fet la gent de lfcm a la interfície.

Un altre CMS prou interessant és un nouvingut anomenat Merengue presenta unes característiques prou interessants com la senzillesa amb que gestiona els temes o la edició col·laborativa (no l'he provada per això), però no té ben lligat el concepte de planes i contingut. No he vist cap vista al backoffice que ens permeti veure clarament la jerarquia de planes. El contingut s'estructura mitjançant una llista plana i perds la referència de l'estructura de la web. Potser s'ha duit a l'extrem la separació dels continguts de la presentació, però al meu entendre tenir una visió esquemàtica dins l'administrador del que hi ha a la web facilita molt la vida a la persona que ha de posar els continguts. Això però, no és un impediment no no s'han de crear moltes planes o el lloc web té una estructura molt fixa, ja que com altres opcions que he presenta aquí, el CMS permet gestionar el contingut directament des de la part de visualització. Merengue apunta maneres i convidrà fer-hi un seguiment de ben a prop.

Però un CMS no és res sense un bon disseny. Crec que l'equip ideal de desenvolupament està format per un dissenyador/maquetador, un parell de programadors i un tècnic de sistemes. En un grup així es maximitza la productivitat, però sempre se pot aspirar a més.

Per això quan tenc una estona estic jugant també amb un micro-framework anomenat bottle amb la idea de facilitar la feina de maquetació amb html pur. És veritat que es podria fer amb Django però la idea és comptar amb una via de visualitzar planes web i trocejar-les amb seccions que no requereixi pràcticament instal·lació i permeti fer maquetes ràpides i tener un prototip funcional que sigui molt bo de modificar. Una vegada el prototip està funcionant passar-ho a plantilles Django és trivial.

Com trivial és gestionar una empresa amb OpenERP. Un complet sistema ERP desenvolupat amb Python i que particularment amb té el cor robat. Ja tenim vàries instàncies funcionant i com que no ha de ser allò que diuen de "en casa del herrero...", una de les primeres gestions que tindrem serà la d'APSL. Si us estau plantejant deixar el Contaplus o semblant o voleu saber en temps real l'estat dels vostres comptes, fer factures i gestionar la cartera de clients, OpenERP és ideal, ja que pots externalitzar tota la part de comptabilitat i fiscal i dur el dia a dia del negoci gràcies a la potent interfície web que té. És un d'aquests projectes que fa anys que segueixo, des de que era TinyERP i el darrer any i mig ha arribat al volum crític que l'ha permès créixer exponencialment en funcionalitat i potència.

El que deia, molta calor, però no sé si és el sol o la quantitat de 'hot software' que he ha al voltant del l'ecosistema Python.

L'altra dia es va alliberar un llenguatge de plantilles inspirant amb Django anomenat Haanga patrocinat per Meneame.net.

Crec que això és una bono notícia, tenc la mala sort que quan he de tocar codi PHP sempre m'he trobat en que la separació de codi i lògica de presentació directament no hi és. Supòs que perquè els llenguatges de plantilles que hi ha són massa feixucs com per a que un programador de PHP se'ls plantegi en el seu dia a dia.

La sintaxi de plantilles de Django és lleugera per al programador/maquetador: és bona d'aprendre i molt poc intrussiva. Així que Haanga al meu entendre és un gran avanç, ja que té la senzillesa de Django i lleva l'excusa de la velicitat que sovint et donen alguns progrmadors de PHP per posar-ho tot junt, ja que compila les plantilles a PHP, amb la qual cosa tenim tots els beneficis i molt pocs emperòs.

Ricardo al seu blog fa una comparació de velocitat però s'ha de dir que no és ben bé justa, ja que no estam comparant el mateix, no en el cas de Django i Haanga al manco, ja que la comparació s'està fent en peticions per segon i contra el framework i no directament contra la part de plantilles. El framework de Django és quelcom més que les plantilles, aquestes són una part important però anecdòtica en termes de codi, ja que és força senzill canviar de motor de plantilles cap a qualsevol altra. El realment important d'un framework com Django és la facilitat que et dona per escalar tant en màquines com en programadors. L'estructuració del codi i el model MVT fa que sigui molt més senzill reaprofitar codi i mantenir codi existent.

Així doncs una comparació més justa seria la de generar les plantilles sense tenir en compte la part del framework. Per a ser justs també hem de modificar un poc el codi, Haanga fa ús de la compilació, però Django pot fer quelcom semblant, és a dir, podem cachejar les plantilles i reutilitzar-les, això, que ja era pràctica habitual en versions anteriors s'ha estandaritzat en la 1.2.

Si volem més velocitat llavors hem de començar a sacrificar funcionalitat, potser haurem d'anar cap a llenguatges de plantilles que facin el mateix que Haanga, és a dir, compilar el codi, en aquest cas a Python. Un bon exemple d'aquesta mena de llenguatges és el llenguatge de plantilles de Tornado o el de Mako. El primer és força interessant, ja que és d'un nivell de senzillesa i extensibilitat comparable Haanga.

He fet uns petits benchmarks considerant el cas més real, que és el de la generació del header.html. Per a fer la comparació justa he cachejat la compilació de plantilles tant en Django com Tornado, i en el cas de Django he utilitzat sols la part de plantilles. Per exemple el test b2_tpl.py queda:

from django.conf import settings
from django.template import Context
from django.template.loader import get_template
import time
settings.configure(TEMPLATE_DIRS=('../templates',), DEBUG=False,
               TEMPLATE_DEBUG=False)

class Info(object):
    def __init__(self, i, epoch):
        self.i = i
        self.epoch = epoch

t = get_template('b2_tpl.html') 
x = ( Info(i,time.time()) for i in range(1,100))
for i in range(1,100):
    print t.render(Context({'objects':x}))

En poques paraules: no hem de programar amb Python/Django como ho faríem en PHP. Per cert pos l'exemple perquè consider que és ideal per veure com es pot fer un script fent us de Django però sols agafant les parts de configuració que ens interessin. Podeu trobar més informació a l'apunt de b-list.

La part de benchmarks de Tornado està inspirada en el treball de Rolando Espinoza sols que he llevat la part de Tornado i he utilitzat sols la part de plantilles.

He fet servir la instrucció time per obtenir els temps i n'he fet la mitja de 5 execucions enviant la sortida a un arxiu.

El resultat és que Haanga ens dóna un temps de 0,1798s, Tornado un temps de 0,099s i Django un temps de 0,3438s. En termes relatius Tornado és 1,8 cops més ràpid que Haanga i 3,5 cops més ràpid que les plantilles de Django. A la seva vegada Haanga és 1,9 vegades més ràpid que les plantilles de Django.

Que Tornado sigui més ràpid no vol dir que tenguem que deixar el llenguatge de plantilles de Django. Hi ha més coses a més de la velocitat pura. Un usuari realment no notarà si la plantilla es genera en 3 o en 1 milisegon però sí que ho notarem a l'hora de mantenir l'aplicació el poder haver fet ús dels avantatges de les plantilles de Django. S'ha d'optimitzar on calgui.

En el cas de PHP i Haanga el consell però seria el de tirar-s'hi de cap. La mantenibilitat que dona tenir el codi separat en plantilles compensa de sobres els pocs milisegons de retard que tindríem el primer cop que es generàs la plantilla en PHP i la gent que tengui que mantenir el codi PHP us ho agrairà.

Enhorabonoa a crodas i a la gent de Menéame per a esponsoritzar un projecte així i obrir-lo al món.

PS. Hi havia un projecte del Google Summer of Code que anava en la línea de Haanga però per Django d'Alex Gaynor, però pel que es veu al final Alex es va decidir cap a un projecte relacionat amb bases de dades no relacionals per Django.

Després de barallar-m'hi un bon grapat de dies he aconseguit integrar el TPV de CECA en una de les aplicacions que estic desenvolupant per APSL. Com en el cas de la integració amb el BBVA he de dir que la qualitat de la documentació és inversament proporcional al suport que tens dels tècnics, per a que quedi clar: la documentació és pèssima, plena de inconsistències i exemples que no funcionen. El suport dels tècnics de CECA molt bo. Poc temps per a contestat (llevat de si demanes en divendres, clar) i respostes clares i concises. Un deu! Amb la gent del BBVA el mateix, se coneix que els ha tocat bregar amb la documentació.

No acab d'entendre què costa mantenir la documentació actualitzada. Si ja no es fa servir un programa per a generar la firma, llavors es refà la documentació i se'n lleva la referència. Si s'incorpora un tag obligatori nou que s'ha d'enviar, llavors s'actualitzen els exemples.

Per si a algú més li serveix faig cinc cèntims del que m'he trobat i del que funciona a l'hora d'escriure aquest apunt.

Generació de la firma

La firma és diferent per l'enviament i per la resposta. En ambdós casos es fa servir el xifrat sha1

Per l'enviament hem de fer una concatenació formada per:

    clau_encriptació
    merchantid
    adquirerbin
    terminalid
    num_operacion
    importe
    tipomoneda
    exponente
    referencia
    SHA1
    url_ok
    url_nok

El que és cada cosa està a la documentació, aquí el que s'ha de saber és: SHA1 és una cadena de caràcters i és necessari posar-la. La referència apareix a la documetació, però NO s'ha de posar, millor dit, és una cadena buida. El número d'operació és el que identificarà la nostra operació i vendrà també a la confirmació així que convé (i és necessari) que sigui un codi numèric únic. L'import és un nombre on les dues posicions representen els decimals, així 12.23 passa a ser 1223. Damunt la concatenació s'ha de fer l'sha1 i passar-ho tot a una cadena hexadecimal i a minúscules. Per exemple:

 m = hashlib.sha1()
 m.update(s)
 valor = m.hexdigest().lower()

El calcul de la firma per la signatura de la resposta és diferent: clave_encriptacion merchantid adquirerbin terminalid num_operacion importe tipomoneda exponente referencia

Fixau-vos que no hi ha SHA1 aquí i com a cosa important l'import s'ha de posar tal com ve de la resposta, veureu que ve completat a zeros per l'esquerra. En aquest cas la referència sí que ve i està generada per la pasarel·la de pagament.

Enviament de les dades

 <form id="pago_form" action="{{url_ceca}}" method="post" accept-charset="utf-8" enctype="application/x-www-form-urlencoded">
 <input id="MerchantID" name="MerchantID" type="hidden" value="{{merchant_id}}"/>
 <input id="AcquirerBIN" name="AcquirerBIN" type="hidden" value="{{acquirer_bin}}"/>
 <input id="TerminalID" name="TerminalID" type="hidden" value="{{terminal_id}}"/>
<input id="firma" name="Firma" type="hidden" value="{{firma}}"/>
<input id="importe" name="Importe" type="hidden" value="{{importe}}"/>
<input name="TipoMoneda" type="hidden" value="978"/>
<input name="Exponente" type="hidden" value="2"/>
<input id="referencia" name="Referencia" type="hidden" value=""/>
<input name="URL_OK" type="hidden" value="{{url_ok}}"/>
<input name="URL_NOK" type="hidden" value="{{url_nok}}"/>
<input name="Pago_soportado" type="hidden" value="SSL"/>
<input name="Cifrado" type="hidden" value="SHA1"/>
<input name="Idioma" type="hidden" value="1"/>
<input name="Descripcion" type="{{descripcion}}"/>
<input type="submit" value="Comprar" />
</form>

Si mirau la documentació veureu que qualsevol parescut amb els exemples és pura coincidència. Tots els camps hi són però no hi ha cap exemple que funcioni amb els camps que hi ha. L'import ha d'estar en el mateix format que la firma, és a dir com a nombre sencer on les dues darreres xifres representen la part decimal.

És important notar que la referència viatja buida i que s'ha de posar el camp Cifrado. L'exemple està agafat d'una plantilla Django i preparat per a funcionar amb Euros com a moneda i en castellà com a idioma.

Rebre la resposta

CECA us enviarà la resposta en un POST a la url que l'indiqueu. Ja he comentat abans el tema de la firma. Convé comprovar sempre que la firma de l'operació calculada amb els paràmetres que ens ha donat CECA coincideix amb el que rebem, d'altra manera implicaria que algú altra està intentant validar l'operació de pagament i marcar-la com a correcta quan no seria així.

Si feis com nosaltres la integració fent servir Django heu de tenir en compte que la protecció CSRF evita que pugui enviar-se un post com el que necessitam, així que hem de marcar la url com a exempta d'aquesta protecció. No fa gaire gràcia, però com a protecció addicional convindrà configurar el firewall per a que sols accepti peticions cap a la url confirmació des de les IPs de CECA.

Com a consideracions importants heu de tenir en compte que CECA passarà l'import completat a zeros per l'esquerra i que heu de guardar la referència i el camp Num_aut, ja que són els dos camps que CECA us demanaria en cas de reclamació. El camp Num_operacion se correspon amb el nombre d'operació que nosaltres hem enviat i ens servirà per a localitzar i processar la venda.

Esper que la informació sigui d'utilitat.

Quan xerram de Python una de les coses en que es fa més èmfasi és la claretat i expressivitat del llenguatge, que ens permet posar les nostres idees en forma de codi de manera ràpida i a més entenedora.

També és important remarcar que Python sovint necessite moltes menys línies de codi per fer el mateix que altres llenguatges, ja no dic un C, C++ o Java, sinó que un PHP, ja sigui per la pròpia potència de Python o bé per que ja hi ha una llibreria estàndard que té implementada aquella funcionalitat que cercam.

Aquesta setmana estava fent una integració amb la passarel·la de pagament del BBVA i m'he trobat amb un d'aquests casos. Per a la comunicació de les dades BBVA signa l'enviament i ho encripta fent servir l'algoristme d'encriptació xor. A la docuentació hi ha un exemple de vàries planes de codi de com es fa això amb PHP i Java/JSP.

Podeu trobar un exemple de com es fa amb PHP al SicilianGirl o també a l'IES Puig Castellar

La implementació de l'encriptació XOR en PHP, treta d'un snippet de php és:

function XOREncryption($InputString, $KeyPhrase){ 
    $KeyPhraseLength = strlen($KeyPhrase);
    // Loop trough input string
    for ($i = 0; $i < strlen($InputString); $i++){
       // Get key phrase character position
       $rPos = $i % $KeyPhraseLength;
       // Magic happens here:
       $r = ord($InputString[$i]) ^ ord($KeyPhrase[$rPos]);
      // Replace characters
      $InputString[$i] = chr($r);
}
return $InputString;
}

En Python això es faria així:

from itertools import izip, cycle 
def xor_crypt_string(data, key):
   return ''.join(chr(ord(x) ^ ord(y)) for (x,y) in izip(data, cycle(key)))

Python és un llenguatge molt potent, i part d'aquesta potència és la possibilitat de fer servir la programació funcional i els iteradors.

Com el seu nom indica cycle va retornant elements d'un iterable de manera cíclica, és a dir que quan arriba al darrer torna a començar.

izip té un nom potser més confús, ja que no té res a veure amb el popular format de compressió, és un iterador que donats dos iterables (dues llistes de caràcters en el nostre cas) ens retorna cada vegada una parella d'elements on el primer element pertany a la primera llista i el segon element a la segona.

Fixau-vos que el cycle ens permet eliminar el codi que manté el comptador al PHP, és a dir $rPos i tot el relacionat amb ell.

Una altra raó més per fer servir Python! :)

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.

Un dels problemes més importants del desenvolupament d'aplicacions web que necessiten suportar una gran quantitat de visités és el de decidir com es farà l'arquitectura de caché i quan i com s'invalida el contingut de la mateixa.

Al respecte he trobat dues presentacions realment excel·lents de la Djangocon:

• Scaling Django Web Applications
• Static Generator

Les dues són molt bones, però especialment us recoman la segona si voleu passar una estona divertida a més d'aprendre com funciona el tema de les cachés. Jared Kuolt broda una presentació plena d'ocurrències, dobles sentits i acudits freaks al mateix temps que aconsegueix introduir-nos en la problemàtica de les cachés.

La primera presentació té moltíssima informació, Michel Malone de Pownce explica els problemes que s'han trobat a Pownce i com els han anat solucionant a Django.

El problema fonamental de les cachés a Django és el tema de la invalidació. Django oculta bastant el nom de les claus que genera i sense aquestes claus un no pot anar a Memecached per invalidar-les.

La sol·lució passa invariablement per generar les nostres pròpies claus de manera repetible i fer un us dels signals de Django per a realitzar la invalidació de les cachés.

Això vol dir ser conscients de com està construïda la nostra aplicació, saber com es genera cada plana i poder enviar el senyal adeqüat per a que s'invalidi la caché quan es modifica cert contingut.

Per llocs amb una càrrega mitjana, les eines per defecte que ens dóna Django són més que suficients. El problema ens ho trobam quan tenim llocs amb mil·lions de visites o bé, quan tenim un lloc web amb relativament poques visites però on l'usuari no és conscient de la importància que té servir les planes ràpidament i per tant de la importància de les cachés.

És el tipus d'aplicació que necessita que qualsevol tipus de canvi es vegi reflexat de manera immediata a la web. Si el lloc és petit, senzillament es pot invalidar tota la caché, si el lloc comença a tenir moltes visites aquest tipus d'invalidació no és convenient i ens trobam gairebé amb la mateixa necessitat d'invalidació de cachés que poden tenir llocs amb moltes més visites.

Jared diu a la seva presentació que el tema del rendiment d'una aplicació web és soluciona amb ^ca(sh|che)$. Personalment crec que les dues opcions van lligades, ja que encara que no es faci la despesa en hardware, un lloc web que requereixi um molt bon rendiment i a la vegada tengui poca inversió amb ferro, necessitarà d'una gestió molt fina de les cachés i de la seva invalidació.

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.

Pels qui no ho sabíeu aquest blog corria damunt una base de dades sqlite3. La base de dades és prou ràpida per les necessitats d'un blog com aquest, però té un emperò considerable: consumeix molta memòria comparada amb un mysql o postgresql. Quan el blog duia una parell de setmanes amb visites que consultàven molts apunts, sqlite començava a cachejar i el consum de memòria de l'aplicació del blog es disparava fins als 160 Mb, mass si ho comparam amb altres aplicacions tant o més complexes que executant-se amb Postgresql estàven entre 30 i 50 Mb. El consum de Postgres és una altra cosa, però com que es reparteix millor entre les aplicacions el resultat final és un estalvi de memòria.

El procés per passar d'sqlite3 a Postgres ha estat el següent:

1. Feim un dump de les dades cap a json. Això es pot fer des de Django amb la comanda dumpdata, per exemple:

   python manage.py dumpdata contenttypes > dumps/contenttypes.json

He fet dumps de sites, auth per la part d'usuaris, contenttypes, i després de tota la resta d'aplicacions que fa servir el blog.

1. Cream la base de dades i l'usuari a Postgresql que farem servir, donant-li permisos de creació de taules.

2. Anam a l'aplicació i canviam la connexió de base de dades de sqlite3 a postgres. Per aixòs basta canviar el DATABASE_ENGINE cap a postgresql_psycopg2 i establir el nom de la base de dades i el password.

3. Executam la comanda syncdb. Això ens crearà les estructures de dades que necessitam i ara ja poden amar restaurant les dades.

En el meu cas hi ha aplicacions que modifiquen el contenttypes quan es fa el sycndb, de tal manera que abans de restaurar he fet un trunc contentypes cascade a la base de dades.

1. Restauram, per exemple:

   python manage.py loaddata ./dumps/auth.json

Anam repetint el procés. Començam per contentypes, després per sites, després per auth i després per les nostres aplicacions segons l'ordre de dependències que tenguin.

Això és tot, comprovam que tot és al seu lloc i recarregam l'aplicació.

A més he aprofitat que és diumenge per provar més coses. Això implica que el blog pot veure's una mica afectat, ja que vull provar errors 404, 500, ping cap a google i altres coses que vull provar en real.

"Si és dolent t'ho recomano " és el títol d'un llibre d'Steven Johnson que he estat llegint aquests dies.

Al llarg de 262 planes Johnson ens va exposant la seva teoría de com gràcies al que normalment s'anomena com a "cultura de masses" la gent ha anant desenvolupant la seva intel·ligència, de manera que en terme mig, el comú de la gent puntua millor en els tests d'intel·ligència del que ho farien mig segle abans.

Johnson anomena a aquest efecte "la corba del Dormilega" en referència a una película de Woody Allen, The Sleeper. Johnson diu que els videojocs, les trames de les nostres sèries preferides, els realities, ... s'han fet tant complexos de seguir que la gent està desenvolupant els mitjans intel·lectuals per a aconseguir-ho gairebé sense adonar-se.

Les sèries de trames molt simples han deixat pas a sèries com a Lost, 24 o Los Simpsons, amb múltiples trames i referències amagades que el lector ha de descobrir. Els videojocs han passa del comecocos a completes aventures gràfiques on el jugador ha d'anar descobrint i resolent enigmes.

Aquest camí cap a la complexitat fa que els nostres serveix s'estiguin entrenant cada cop més en la resolució de problemes, en com s'estableixen relacions causa efecte o interaccions socials entre els personatges. Els productes de consum que abans estaven destinats a una minoria ara poden ser consumits i entesos per una gran majoria.

És un llibre força interessant, amb múltiples referències a videojocs i series antigues i noves que poden despistar un poc a la generació més jove. Les conclusions al meu parer són molt encertades. L'efecte global de la comunicació de masses, dels videojocs complexos, d'Internet i les noves tecnologies és que fa al conjunt de la societat cada cop més intel·ligent i formada, més capaç de resoldre problemes gràcies a que el cervell està cada cop més entrenat i reb més més estímuls cap a aquesta direcció. Sols el fet de que jo hagi escrit aquest apunt i que hi hagi gent que ho estigui llegint ja és un exemple de com els nous mitjans ens han permès interaccions reservades dècades abans sols a l'elit intel·lectual i/o econòmica.

Lectura recomanable pel tipus de temàtica i la visió que dóna, allunyada dels tòpics habituals.

 Fitxa tècnica
 Si és dolent t'ho recomano
 Steven Johnson
 Ed. La Campana
 ISBN 978-84-96735-25-5

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à.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

i per fer cerques trob molt útil

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

També és útil recordar algunes comandes de vimdiff

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gràcies a Suki per les fotografies.

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

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

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

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

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

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

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

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

Novetats

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 ./manage.py dumpdata applicacio.model

per exemple:

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

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

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

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

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

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

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

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

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

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

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.

Què voleu, estic content de veure que una eina com pip funciona tan bé.

Pip és una eina per a la instal·lació de paquets i dependències per Python, molt més avançada que easy_install ja que permet tot el que feia easy_install però a més, permet mantenir d'una manera fàcil un arxius amb totes les dependències del nostre projecte.

Ens permet instal·lar paquests de Python des dels repositoris de Pypi, des de subversion, git, mercurial a través d'un fitxer de requeriments simple i a la vegada funcional.

Mode batalleta on:

Ahir vespre estava fent feina amb un projecte mascota que tinc, un motor de reserves per hotels i cadenes hoteleres fet amb Python i Django.

El projecte necessita de força llibreries: la darrera versió de django, nose pels tests, sphinx per la documentació, django debug toolbar, django extensions, south per la migració de dades, ipython, ipdb, pep8, coverage, pytlint. Tot això (i algunes més que s'hi afegiran) constitueixen l'entorn de desnvolupament del projecte.

Actualment faig feina amb tres ordinadors: el fix (el PPC del que tant he parlat per aquí), portàtil un Dell D820 i un Dell de 10". Segons on estic i el que he de fer en faig servir un o altra, o duc dins la borsa el portàtil gran o el petitó.

Per això el pip m'ha solucionat tant la vida. Ara quan desenvolup un projecte me basta mantenir al repositori del control de versions un arxiu amb els requeriments del projecte. Cada vegada que afegeixo una nova dependència no la instal manualment sinó que la pos a aquest arixu i execut

pip install -E $VIRTUAL_ENV -r requirements.txt

dins el meu virtualenv a partir d'aqui i quan he de canviar d'ordinador i vull tornar a fer feina en el projecte, basta baixar-me els canvis i tornar i tornar a executar a aquest ordinador l'ordre que he posat un poc més amunt. Amb una bona connexió en pocs segons (potser minuts) tindrem l'entorn de desenvolupament del programa totalment operatiu.

Mode batalleta off

Pel que en tingueu interés deix aquí un parell d'enllaços:

• Pip documentation

• Tools of the modern Python hacker...

• Fabric, Django, Git, Apache, Pip, ...

• Notes on using pip and virtualenv

Quan hom comença amb Python qualsevol ajuda és benvinguda i quan ja en saps un poc més llavors el que cerques és poder provar coses ràpid, flexibilitat i eines potents.

Sigui com sigui un dels avantatges de Python com a llenguatge de programació interpretat és que ens proporciona una consola de comandaments que ens permet provar les coses d'una manera pràcticament immediata. Tot i això, com us dic, quan comences a aprendre'n la consola que hi ha per defecte potser no és el més amigable del món.

Us presento unes quantes consoles més per poder triar i remenar:

bpython

És una consola molt amigable per la gent que comença: té autocompletat per defecte i ens mostra la documentació de les funcions que anam teclejant. Ens permet copiar el nostre codi a Pastebin, amb la qual cosa ens facilita la tasca de comentar el que surt (o no surt) amb altres persones. Té també una versió per gtk (bconsole-gtk) i s'integra amb Django fent servir eines de tercers. És ideal per a començar a jugar amb l'entorn i aprendre la sintaxi de les comandes.

dreampie

És també una shell força interessant per la gent que comença, surt del típic prompt i presenta una secció on es pot anar introduint el nostre codi. Amb ctrl+intro el codi passa a la shell i s'executa. És multiplataforma i s'integra amb matplotlib (pels qui necessitin fer gràfiques). Com a cosa interessant, ens permet guardar la feina en html, ideal per muntar tutorials.

pyShell

Junt amb Pycrust són utilitats que podem trobar al paquet wxPython. Tenen autocompletat i mostren la documentació. Són consoles potents però requereixen tenir instal·lat wxPython. M'agrada PyCrust perquè et mostra un poc les interioritats de l'intèrpret de Python, té una secció anomenada namespace on pots veure tot l'espai de noms que hi ha carregat i navegar-hi. Per exemple fer un import os posa el paquet os a l'espai de nom i podem moure'ns i veure'n les funcions que té, constants i la documentació.

ipython

La meva preferida. Una consola potent, gairebé pot reemplaçar una shell per les tasques més habituals. Té resaltat de sintaxi i autocompletat, però ja has de saber un poc més el que estàs cercant. S'integra molt bé amb Django i permet executar directament comandes de shell. El manual és molt complet i dóna una idea de la potència de la consola.

idle

Python ja ve amb les bateries incloses. A més de la consola habitual també podem trobar l'idle una consola gràfica i editor. Té resaltat de sintaxi i autocompletat. Li han fet una bona rentada de cara darrerament i també és una opció a considerar. A més recordau que és a més un editor força complet per Python.

En Galigan l'altra dia es demanava pel Twitter com és que la gent que fa feina de manera independent no s'uneix per poder fer front a "consultoras dinosaurio".

Com que el Twitter és massa curt i massa immediat per poder poder dir les coses, doncs li vaig prometre un apunt al blog per contar com veia jo les coses. Potser amb aquest apunt tampoc aconseguiré explicar tot el que vull dir i el que pens del tema, però al manco serà un poc més desenvolupat que no un grapat de frases al Twitter.

Primer un poc de història.

La idea d'un conjunt de professionals autònoms que s'uneix baix una mateix marca no és nova a les illes. Fa temps i a partir d'un grup de gent que es coneixia de Bulma hi va haver un intent de fer tal cosa. Pel que jo sé (no hi vaig participar a l'experiment) la cosa no va acabar d'anar del tot bé.

Desconec exactament les raons del fracàs de l'experiment, però potser una d'elles va ser la inexperiència en unions com aquesta. En altres sectors com els missers i gestors per exemple, aquests tipus de col·laboracions són molt més habituals.

Tot i que no funcionàs la idea és prou bona. Va ser el punt de partida que ens motivà a formar APSL, no ja com a una marca sinó com a una societat limitada. La idea fonamental era, i és, unir a professionals amb una visió del que és el desenvolupament d'aplicacions web comú, professionals que es complementin i amb un objectiu comú.

L'experiment APSL

APSL té un nucli estable de gent des de el principi, que hi col·labora d'una manera o altre, uns són socis, d'altres just col·laboradors voluntaris (un bon exemple d'això són els #creant_bits). Però tothom amb una visió semblant de la informàtica i amb una cosa fonamental: confiança mútua.

Des de la seva formació APSL ha tingut com a objectiu la col·laboració entre professionals, però per a que tal cosa es produesqui aquesta col·laboració s'ha de donar de manera natural, ordenada i amb el consens de tothom. La confiança és a més el nexe que fa possible el projecte. Tothom que hi forma part ha de poder tenir la confiança plena de que cada un farà el que s'ha de fer en cada moment, que els egos no han de prevalèixer damunt l'objectiu més gran que és dur endavant un projecte empresarial a llarg termini.

La visió no és sols orientada a la informàtica, sinó també al model empresarial, a l'ètica empresarial, el que darrerament s'ha anomenat la responsabilitat social de l'empresa. Per a nosaltres això representa fer negocis d'una manera molt determinada, convertint-nos no sols en proveïdors dels nostres clients, sinó en col·laboradors, en una relació quasi simbiòtica on tothom hi ha de sortir guanyant. En poques paraules, no es tracta de donar el pelotazo sinó de mantenir una relació de confiança i col·laboració que s'estengui al llarg del temps.

Supòs que tot això us sonarà a la gent que heu parlat amb mi i com molts us adonareu no és una cosa massa habitual en el nostre sector (sobretot fora del programari lliure), per això dic que APSL és un experiment, perquè trob s'ho paga intentar que un projecte així tiri endavant.

Per què empresa?

L'empresa és el nexe d'unió. Representa una manera formal de fer les coses i estableix unes regles de joc comercials i mercantils. Implica que hi ha un admintrador/gerent que dóna la cara, que pot coordinar els distints projectes i saber què fa tothom.

I per mi això és el que marca la diferència entre projectes semblants que s'estructurin al voltant d'una marca i dels que s'estructuren al voltant d'una empresa: la figura de l'administrador, de la persona que ha de vetlar per a que l'empresa funcioni com a tal, encara que internament els seus membres siguin tots professionals.

L'empresa com a tal dona recolzament als professionals que la formen. Fa que el tot sigui major que la suma de les parts, i a la seva vegada imposa tota una sèrie d'obligacions: facturació comuna, comptabilitat clara, despeses comunes, ...

Des del moment que es té un lloc comú de reunió, que s'ha de pagar, una facturació i uns comptes que s'han de presentar, la col·laboració passa de ser una cosa esporàdica entre professionals i convertir-se en un tirar del carro comú. S'han de tenir millors serveis compartits, aquella lasser que fa falta, el servidor que s'ha d'ampliar i gestionar, els clients que s'han de visitar, ...

APSL està pensada per créixer de manera orgànica i pausada en vers l'objectiu d'agrupar professionals, de sumar talent i proporcionar serveis comuns que d'altra manera no es podrien tenir, d'arribar a projectes que amb un altre tipus d'estructura serien directament inabastables.

Però tot això ja us dic que té tota una sèrie d'implicacions que s'han de conèixer i que potser en altres intents d'aquest tipus no s'han donat tant. Deixau-me canviar un poc de registre i no referir-me tant a APSL sinó a com ho veig en general.

Què implica un projecte de col·laboració?

• Objectius comuns. Ja no es cosa d'anar cada un pel seu compte i que l'empresa sols es tengui en compte a l'hora de presentar-se a un projecte, sinó que s'ha de tenir l'objectiu de fer que l'empresa com a tal cresqui. Els projectes ja no són propis sinó que són de l'empresa, de la mateixa manera que ho són les despeses.

• Confiança professional Tothom ha de poder confiar amb tothom i els clients han de poder confiar en els professionals de l'empresa. La visió de l'empresa i del model de negoci ha de ser la mateixa per tot els professionals agrupats entorn a l'empresa.

• Complementarietat En un negoci global com és la informàtica els professionals que s'agrupin en un projecte de col·laboració han de ser complementaris i no tan sols en l'aspecte tècnic (que també) sinó en l'aspecte fin i tot de caràcter. No tot és programar, també s'ha d'anar a captar clients, fer pressupots, parlar amb gestors, dissenyar l'aplicació, documentar, fer fotografies, ...

• Serveis compartits Un altre dels nexes del projecte ho han de representar els serveis compartis: el local, els servidors, la infraestructura posada a disposició del integrants del projecte. El local, per exemple, fa que hi pugui haver un punt de feina on la gent que es sent més còmoda fent feina fora de casa hi pugui anar. S'ha de pensar a llarg plaç i reservar capital per a invertir en el projecte: millor mobiliari, local amb més possibilitats, millors servidors, possibilitat de organitzar cursets, d'anar a conferències.

• Despeses S'ha de ser conscient que un projecte de col·laboració a llarg plaç té despeses. La feina d'organització i gestió interna pot arribar a ser força important quan es tracta de gestionar un projecte on un gran nombre de professionals han de de col·laborarar, s'ha de mantenir per una estructura gran un nivell d'abstracció semblant al que es tenia com a professional, però aprofitant les sinèrgies que implica col·laborar amb altra gent. Això vol dir que els beneficis de la nostra feina com a professionals ja no són sols nostres, sinó que són de l'empresa i dels altres col·laboradors. Joel Spolsky tracta molt bé el tema a The Development Abstraction Layer. Fitxau-vos que les despeses no es refereixen al material, a la llum o al local, sinó a tot el necessari per mantenir el nivell d'abstracció que permeti aprofitar les sinergies que impliquen posar feina en comú.

• Creixement orgànic Personalment pens que s'ha de ser caut a l'hora de créixer. S'han de cercar les col·laboracions permanents quan la gent ja es coneix i ha fet feina junta en alguns projectes. A l'hora d'admetre nous membres aquesta admisió no ha de ser fruit de la necessitat sinó de l'acord de tots els membres. Ja no estam sols, som un equip, una empresa i per tant la decisió de amb qui es col·labora i amb qui no ha de ser quelcom comú.

• Suport mutu Quan un fa feina sols qualsevol problema o incidència personal té un impacte brutal damunt la seva activitat. Per una empresària el naixement d'un fill pot representar tant una alegria com a un risc. Col·laborar implica estar a les dures i a les madures, minimitzar els impactes que puguin tenir els membres. Ara es funciona com a empresa i com a tal els projectes i els clients són comuns. Implica estar dispost a conèixer els clients i els projectes de l'altra gent, ser-ne el backup en cas que fos necessari, i si més no sempre tenir-ho previst.

Així és com jo ho veig, i és el que estam intentant dur a terme amb APSL. Personalment crec que qualsevol projecte de col·laboració que es presenti just en termes mercantilistes i d'oportunitat té poc futur. S'han de tenir en compte més coses. Tot i que es vulgui mantenir la llibertat de moviments que implica ser un professional autònom s'han d'establir unes regles de joc i s'han d'assumir tant beneficis com obligacions.

Avui he acabat de llegir "Cloud Application Architectures" de George Reese. Un llibre que no arriba a 190 planes però que està ple de consells damunt el que és l'arquitectura d'aplicacions al núvol.

La visió del llibre no és tant per tècnics com per a gestor d'IT que s'atraquen a aquest tipus d'arquitectura de desplegament. Basant-se sobretot en AWS Reese presenta l'AWS d'Amazon i la conveniència d'estar o no al núvol.

No entra en com configurar tal o qual cosa, sinó que entra en temes tals com els cost d'estar al núvol, el retorn de la inversió i el que hem de considerar abans de moure'ns cap allà. Avantatges i inconvenients.

Tracta també aspectes com la seguretat a AWS (donant molts bons consells, per cert), recuperació de desastres i entra un poc de passada en el dimensionament de l'arquitectura (el capacity planning) de la nostra aplicació.

És un llibre força entretingut que es devora amb rapidesa i també tremendament útil per tenir una visió de conjunt del que representa posar les nostres aplicacions al núvol.

L'altra dia algú deia que amb el núvol s'acabarien les feines de la gent de sistemes. Fent una llegida al llibre de Reese te n'adones que la feina no tan sols no s'acabarà, sinó que serà tant o més important que ara. Poder definir la capacitat adequada al nostre sistema, tenir un bon pla de contingència, còpies, encriptació de la informació, scripts d'aturada automàtics, de desplegament, control de la demanda, ... Feines que són necessàries i que s'han de fer també, de manera diferent de com se feien les coses.

Poder instal·lar un sistema operatiu a una màquina nova és trivial. El que se necessitarà son gent de sistemes que conegui els aspectes econòmics de desplegar aplicacions al núvol, ser capaç de definir scripts per automatitzar tasques, respondre a caigudes ràpidament, etc. etc. El que sí pareix que es necessitarà és gent potser d'un perfil concret: professionals de sistemes que sàpiguen programar, que estiguin còmodes amb una línia de comandes i que entenguin les implicacions econòmiques i de seguretat del que estan fent al núvol.

Llibre totalment recomanable doncs!

Fitxa tècnica:

Cloud Application Architectures
George Reese
Ed. O'Reilly
ISBN 978-0-596-15636-7

Per cert, aprofitant que ara ho record, pos també els llibres que va recomanar Ricardo al darrer creant bits.

• Daemon, Daniel Suarez
• Freedom (TM) de Daniel Suarez
• Hight Performance MySQL de Arjen Lentz
• The Big Switch de Nicholas Carr

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.

Encara que faig servir distints editors i entorns integrats (IDE) per programar en Python i Django hi ha sempre la constant de retornar cap a Vim i gVim.

La cosa està però, en que per al desenvolupament normal no vull renunciar a un parell de coses que fan la vida més fàcil:

• Resaltat de sintaxi amb colors personalitzables i/o una paleta de colors còmoda per fer-hi feina.
• Autocompletat (dins cert límits, que això és un llenguatge dinàmic) i ajuda integrada.
• Plantilles per no haver d'escriure molt. Per exemple els shebangs, o els models de Django.
• Distints tipus de tabulació segons el llenguatge, quatre per Python, però 2 per HTML i Javascript.
• Possibilitat de tenir oberts molts arxius a la vegada i accedir-hi fàcilment
• Navegació pel sistema d'arxius integrada

I poca cosa més. Després quant més potent sigui l'editor millor, i per això Vim n'és de potent!! El problema és que ja m'agradaria poder fer servir amb agilitat un 20% de les seves capacitats.

En la meva recerca de l'editor perfecte he anat modificant el .vimrc i afegint plugins diversos, i configuracions que anat trobant d'aquí i d'allà. Per si a algú li va bé, he posat el meu .vimrc i .vim amb els plugins a l'appusedjango. Ja me contareu!

Eines per a la isntal·lació de plugins

Si feis un apt-get vim-addons obtindreu una petita utlitat que us permetrà veure quins plugins teniu instal·lats al vostres sistema i activar-los pel vostre usuari. En el meu cas tenc:

bufexplorer                 installed     
markdown-syntax             installed            
matchit                     installed            
python-indent               installed            
python_bike                 installed            
supertab                    installed            
surround                    installed            
taglist                     installed            
utl                         installed            
winmanager                  installed            
xmledit                     installed

En local (i instal·lats a mà) tenc també:

• ftplugin
• nerdtree_plugin
• snippetsEmu
• taglist
• mathit
• supertab
• vcssvn

Hi ha altres plugins interessants com el nerdcommenter i altres, però encara m'he d'anar acostumant al altres.

Referències

La veritat és que em costa dir d'on ho he tret tot, la configuració és una feina orgànica, he anat agafant coses d'aquí i d'allà, així que pos els darrers consultats.

• Llibre, tutorial de Vim
• pycopia
• vim-config-python-ide

Disclaimer: NO sóc cap expert amb vim, així que moltes coses van per assaig i error.

Download

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

• El .vimrc

• El .vim

Al svn trobareu un .vimrc que heu de posar al vostre home i un arxiu comprimit amb .vim que conté plugins, plantilles i demés, descomprimiu-lo també al vostre home.

No he de recordar la impirtància de fer còpies de seguretat de la configuració antiga abans de res, veritat?

Pels debianites i ubuntaires

Per a tenir l'entorn funcional necessitareu instal·lar

• sudo aptitude ctags
• sudo aptitude vim-addons-manager
• sudo aptitude vim-python (segons versions...)

comprovat per bibigeek (gràcies!) pels ubuntaires amb PPC com jo, no hi ha vim-python i convé recompilar vim amb suport per Python.

Esper que us sigui d'utilitat!

Entre lectures informàtiques i altres herbes aquests dies m'he estat llegint Nocturna, una història de vampirs i zombies de Guillermo del Toro y Chuck Hogan.

Al principi la novel·la comença amb poc ritme, però després de les cent primeres planes la cosa s'anima i quan l'acabes ja veus que la història quedarà incompleta, que potser és sols un començament.

La mà de Guillermo del Toro es nota en el desenvolupament de la història i la presentació dels personatges, tant que ben bé podría ser un guió.

Supòs que el llibre no serà mai considerat com una de les joies de la literatura però entretén.

Nocturna
Guillermo del Toro i Chuck Hogan
Círculo de Lectores
ISBN 978-84-672-3689-7

Avui he acabat de llegir The Medici Effect, un llibre que em va recomanar fa unes setmanes Greg Garrison, un de les persones amb més idees que m'he trobat fa temps.

The Medici Effect tracta de la innovació, dels camins que duen a les noves idees. De com la mescla de conceptes, experiències i gent dóna lloc a noves idees, a nous productes que trenquen amb tot el que hi havia fins al moment. Es creen nous negocis, nous camps d'investigació, noves empreses no de manera evolutiva sinó disruptiva, fruit d'una combinació de factors i de gent.

El llibre tracta de com poder conseguir aquest factor disruptiu, de com trobar el Frans Johansson, l'autor, anomena la intersecció. El punt de trobada on les corrents i les idees es mesclen i donen lloc a una cosa nova.

Johansson ens mostra amb exemples com distintes persones i empreses són conscients d'aquests tipus de combinacions i de com els cerquen activament en els seus negocis.

El llibre és prou interessant, motivador fins i tot. Alguns dels consells que dóna són prou bons. Tot i això les idees que presenta es poden resumir en pocs conceptes:

• Cerca la intersecció.
• Reconeix la innovació
• Assumeix el canvi i no tenguis por a trencar barreres i xarxes socials.
• Assumeix el risc

Amb això vull dir que és un llibre que es podria haver estalviat un 50% de les 190 planes de text. Sovint es fa repetitiu ens alguns exemples i es perd un poc per les bardisses a l'hora de focalitzar el tema.

En resum, un llibre interessant, que convé llegir, especialment si ja us heu convençut de que la innovació és una bona cosa, sou capaços de generar idees o simplement voleu una visió de com altres gestionen projectes i idees que canvien el món.

Fitxa Tècnica
The Medici Effect
Frans Johansson
Harvard Business Scholl Press
ISBN-13: 978-1-59139-186-9

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 :)

El segon creant bits dedicat a la introducció de Python i Django d'ahir va a tornar aplegar un bon nombre de gent interessada per la programació i per Python i Django.

Cares conegudes i gent que vaig poder desvirtualitzar. Em va fer especial il·lusió poder desvirtualitzar Guillem, ja que per un motiu o altre mai ens havíem pogut trobar personalment.

Aquesta vegegada preferírem no allargar molt la jornada i no es donà la xerrada damunt la posada en producció d'aplicacions Django. La passada jornada En Bernat va tenir molt poc temps i acabarem molt tard, així que ho hem deixat per a una millor ocasió.

Aquest pic el consum de gominolas per part dels assistents va ser menor, lluny del rècord de kilo i busques de l'altra vegada. :-P La idea és que si algú s'avorreix al manco se n'endurà un sabor dolç de boca.

Entre l'anecdotari comentar el mal cos que se'ns quedà a tots quan un tassó d'aigua va vessar damunt un portàtil Macbook Pro nou de trinca. Després de netejar-lo va tornar a la vida i esper que segueixi així. Hi va haver un segon intent de tragèdia, quan el que es va vessar va ser cafè i no aigua, afortunadament aquest cop no va tocar el portàtil.

Sols me queda agraïr l'assistència de tots i especialment dels companys que donàren l'assistència tècnica i ajuda. Esper que tothom se n'anàs amb una millor idea de la que tenia a l'entrada damunt el que és Python, el que es pot fer i de la potència de Django per al desenvolupament web.

Ara a encalentir motors per a la xerrada de Ricardo al proper creant bits.

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.