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.

Quan hom fa feina amb Django una de les primeres coses que aprèn és a mirar la consola del servidor de desenvolupament. Al la consola hi apareixen els missatges d'error i els logs bé en forma de prints o com a logs de Python.

Convé evitar fer prints i fer servir els logs. Aprofitarem el funcionament del logger per tal de discrimitar els tipus de log i distingir entre els missatges que volem que es mostrin sols en depuració (DEBUG), errors o informatious.

Una configuració molt bàsica del logs és la que propòs a projecte base d'appfusedjango, molt ràpidament:

Al properties.py o al settings configuram el sistema de log

1
2
3
4
5

import logging
logging.basicConfig(
    format="%(asctime)s-%(levelname)s-%(name)s-%(lineno)s-%(message)s",
    level = logging.DEBUG,
)

i a cada arxiu on el volguem fer servir

1
2

import logging
log = logging.getLogger(__name__)

Això ens permte configurar a un sols lloc el nivell de log que volguem i a més saber des d'on s'estan generant els missatges.

Com a retruc, a més ens servirà per poder mostrar els logs a la consola del Firebug gràcies a l'aplicació FireLogger.

Aquesta aplicació té una instal·lació en dues parts, ja que hem d'instal·lar el plugin de Firefox que hi trobareu a la plana (la versió 0.7 en el moment d'escriure això) i després instal·lar les llibreries Python necessàries.

La plana recomana fer servir easy_install però en aquests moments el paquet que hi ha al PyPi està desactualitzat així que millor instal·lar-ho a mà:

 sudo easy_install paver
 sudo easy_install  jsonpickle
 git clone git://github.com/darwin/firepython.git
 cd firepython
 sudo python setup.py install

Amb això a una Ubuntu basta. Una vegada insta·lat anirem a la nostra palicació Django i a la secció del MIDDLEWARE_CLASSES afegirem

 firepython.middleware.FirePythonDjango

Podem obrir ara la consola de Firebug i trobarem una nova secció anomenada Logger. Aquí apareixeran els missatges de Log de la nostra aplicació. Podem filtrar per la criticitat del log i a la mateixa vegada tenim tota la potència del Firebug per a la depuració de l'aplicació.

Una bona eina per tenir al caixó de les de desenvolupament i depuració.

Atenció:

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

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

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

Gràcies a tots!

L'any comença fort i interessant!

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

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

Creant Bits al Núvol

Dia: 5 de febrer de 2009

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

Horari: començam a les 16:00

Presentacions:

• Meneame al núvol
• per concretar.

Organitza: APSL

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

Google Calendar

Com apuntar-se?

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

FAQ

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

Aquesta vegada, també fora catering! :-P

Em complau anunciar una segona edició de Creant Bits destinada a tots aquells i aquelles que no poguéreu assistir a la primera.

Els contingut seran bàsicament els mateixos, en tot cas mirarem de resoldre algunes mancances de la primera presentació, però en un 99% serà tot el mateix:

• Introducció bàsica al llenguatge Python, amb exercicis.
• Introducció a Django: arquitectura i possibilitats
• Instal·lació d'una aplicació Django a Apache.

La sala serà la mateixa que a la presentació anterior.

Creant Bits, el déjà vu

29 de gener de les 16:00 a les 21:00

Sala de Formació - Parc Bit

Pensau a dur el portàtil carregat amb el Python instal·lat. Hi ha connexió inhalàmbrica a la sala i el Parc Bit ens deixa un projector.

La sala té una capacitat per a 20 persones màxim. Per apuntar-vos deixau un comentari a aquest apunt.

Per cert, aquesta vegada tampoc hi ha catering! :)

Ahir estava mirant la presentació de James Bennet a la DjangoCon anomenada "UR DOIN IT WRONG" i me'n vaig adonar que feia referència a una sèrie de màximes tipus:

#11919 No.  You must believe the ERROR MESSAGE.  You MUST believe the error message.

La conferència és molt bona, us la recoman. El cas, però, és que em va picar la curiositat i vaig seguir l'enllaç fins a arribar a una entrada de comp.lang.perl.misc del març del 2002 on Mark Jason Dominus feia una relació de consells que ell tenia a un arxiu anomenat File of Good Advice.

Les màximes, encara que plenes de sentit comú, tenen una mala llet considerable, i m'han recordat al nostre metge de la tele favorit. Supòs que no desapareixeran de la xarxa, però per si un cas les torn a escriure aquí. Ha passat temps, però la majoria són perfectament aplicables! Esper que les disfruteu tant com jo ho he fet.

#11900 You cannot just paste code with no understanding of what is going on 
 and expect it to work.
#11901 You can't just make shit up and expect the computer to know what you
 mean, Retardo!
#11902 You said it didn't work, but you didn't say what it would have done if
 it *had* worked.
#11903 What are you really trying to accomplish here?
#11904 Who the fuck cares which one is faster?
#11905 Now is the time in our program where you look at the manual.
#11906 Look at the error message!  Look at the error message!
#11907 Looking for a compiler bug is the strategy of LAST resort.  LAST resort.
#11908 Premature optimization is the root of all evil.
#11909 Bad programmer!  No cookie!
#11910 I see you omitted $! from the error message.   
It won't tell you what went wrong if you don't ask it to.
#11911 You wrote the same thing twice here.  The cardinal rule of programming 
 is that you never ever write the same thing twice.
#11912 Evidently it's important to you to get the wrong answer as quickly as
 possible.
#11913 Gee, I don't know.  I wonder what the manual says about that?
#11914 Well, no duh.  That's because you ignored the error message, dimwit.
#11915 Only Sherlock Holmes can debug the program by pure deduction from the
 output. You are not Sherlock Holmes.  Run the fucking debugger already.
#11916 Always ignore the second error message unless the meaning is obvious.
#11917 Read.  Learn.  Evolve.
#11918 Well, then get one that *does* do auto-indent.  You can't do good work
 with bad tools.
#11919 No.  You must believe the ERROR MESSAGE.  
 You MUST believe the error message.
#11920 The error message is the Truth.  The error message is God.  
#11921 It could be anything.  
 Too bad you didn't bother to diagnose the error, huh?
#11922 You don't suppress error messages, you dumbass, you PAY ATTENTION 
 and try to understand them.
#11923 Never catch a signal except as a last resort.
#11924 Well, if you don't know what it does, 
 why did you put it in your program?
#11925 Gosh, that wasn't very bright, was it?
#11926 That's like taking a crap on someone's doorstep and then ringing 
 the doorbell to ask for toilet paper.
#11927 A good approach to that problem would be to hire a computer programmer.
#11928 First get a book on programming.  Then read it.  Then write the program.
#11929 First ask yourself `How would I do this without a computer?'  Then have
 the computer do it the same way.
#11930 Would you like to see my rate card?
#11931 I think you are asking the wrong question here.
#11932 Holy cow.
#11933 Because it's a syntax error.
#11934 Because this is Perl, not C.
#11935 Because this is Perl, not Lisp.
#11936 Because that's the way it is.
#11937 Because.
#11938 If you have `some weird error', the problem is probably with your
 frobnitzer.
#11939 Because the computer cannot read your mind.  Guess what?  I cannot read
 your mind *either*.
#11940 You said `It doesn't work'.  The next violation will be punished by
 death.
#11941 Of course it doesn't work!  That's because you don't know what you are
 doing!
#11942 Sure, but you have to have some understanding also.
#11943 Ah yes, and you are the first person to have noticed this bug since
1987.  Sure.
#11944 Yes, that's what it's supposed to do when you say that.
#11945 Well, what did you expect?
#11946 Perhaps you have forgotten that this is an engineering discipline, not 
 some sort of black magic.
#11947 You know, this sort of thing is amenable to experimental observation.
#11948 Perhaps your veeblefitzer is clogged.
#11949 What happens when you try?
#11950 Now you are just being superstitious.  
#11951 Your question has exceeded the system limit for pronouns in a single 
 sentence.  Please dereference and try again.
#11952 In my experience that is a bad strategy, because the people who ask 
such questions are the ones who paste the answer into their program without 
understanding it and then complain that it `does not work'.
#11953 Of course, this is a heuristic, which is a fancy way of saying that it 
 doesn't work.
#11954 If your function is written correctly, it will handle an empty array 
 the same way as a nonempty array.
#11955 When in doubt, use brute force.
#11956 Well, it might be more intuitive that way, but it would also be useless.
#11957 Show the code.
#11958 The bug is in you, not in Perl.
#11959 Cargo-cult.
#11960 So you threw in some random punctuation for no particular reason, and 
 then you didn't get the result you expected.  Hmmmm.
#11961 How should I know what is wrong when I haven't even seen the code?  
 I am not clairvoyant.
#11962 How should I know how to do what you want when you didn't say what you
 wanted to do?
#11963 It's easy to get the *wrong* answer in O(1) time.
#11964 I guess this just goes to show that you can lead a horse to water, but 
 you can't make him drink it.
#11999 You are a stupid asshole.  Shut the fuck up.

Avui m'agradaria parlar de dues eines que crec que ens poden ajudar molt en la tasca de comunicar-nos amb el nostre client a l'hora de definir un projecte: pencil i shutter.

Pencil és una eina que s'instal·la com a un plugin de Firefox (encara que es pot executar de manera independent) i que serveix per fer diagrames orientats a interfícies d'usuari. Ha evolucionat molt darrerament i ens permet crear prototips prou rics en widgets, tant per a definir interfícies d'escriptori com per a definir interfícies web. En la versió 1.1-rc2 que és la que he estat provant, ens permet crear documents multiplana, crear els nostres propis components, té un visor d'imatges que enllaça amb openclipart i ens permet exportar el disseny creat a a html, pdf o odt.

Shutter és un capturador de pantalla avançat, el millor que he vist fins ara per Linux. Ens permet capturar la pantalla, una finestra, un troç de finestra i modificar mínimament la imatge aplicant-li efectes o afegint-hi text. És a dir, té tot el necessari per a convertir-se en una eina imprescindible a l'hora de fer manuals o documentació que impliquin afegir imatges d'un programa.

Per mi aquestes eines tenen un gran valor. Pencil permet definir l'estructura bàsica d'una aplicació sense perdre massa temps i sense entrar en el disseny final. És a dir, ens permet avançar en el què ha de fer l'aplicació en lloc d'enrocar-nos en l'aparença de la mateixa. Això és molt important en les etapes inicials dels projectes, pensau que molta gent no sap el que vol, i encara que sàpiga el que vol teniu en compte que la feina d'un cap de projecte no és tant donar al client el que vol sinó donar al client allò que necessita. Tenir eines que ens permetin comunicar a alt nivell per a poder esbrinar què és allò que es vol ver és força important. Aquestes eines per la seva banda han de ser tals que no ens dugui massa feina ni esforç crear els dissenys, ja que per una banda el projecte encara no sabem si es farà i per altra se suposa que hi haurà força canvis, així que les iteracions entre les xerrades amb el client i els canvis que es puguin fer han de ser molt ràpides. Pencil trob que comença a tenir una bona relació entre capacitat de comunicació i velocitat a l'hora de fer els canvis.

La veritat és que els wireframes en aquestes etapes es podrien fer perfectament amb llàpis i paper. Hi ha autors que recomanen que sigui així. Això però quan es posa en un pressupost o dins una presentació no té l'impacte visual necessari per a donar una imatge de qualitat al projecte, i per tant que en lloc d'eines com Pencil es pugui fer servir paper i llapis de colors i un escanner depèn més de l'audiència a qui va destinada la presentació o el pressupost que el que sigui possible fer-ho d'una maner o altre.

Eines com Shutter i Pencil ens donen la capacitat de fer bons pressuposts, tutorial; concentrant-nos en el que es vol dir i donar la referència visual. Són un estalvi de temps i donen lloc a un augment de les nostres capacitats de comunicació, en el que volem dir sense que el temps per posar-ho elegant sigui un impediment.