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ó.