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

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

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

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

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

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

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

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

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

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

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

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

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

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

Quan feim feina amb llistes de tant en tant en sorgeix la necessitat de fer feina amb l'index de la llista en lloc (o a més) de l'element de la llista en sí.

Sovint ens podem trobar fent coses com

1
2
3
4
5

x = ['a','b','c']
i = 0
for item in x:
    i +=1
    print i, item

Davant aquest tipus de problemes, pensau que el més habitual és que el propi llenguatge ja ho tengui resolt, de la mateixa manera que els problemes més habituals de la programació web estan resolts per Django.

El nostre problema es redueix a fer servir enumerate. Aquesta funció agafa un iterador (una llista per exemple) i ens retorna un nou iterador, els elements del qual són una tupla composta pel comptador (l'índex) i l'element de l'iterador inicial que li passam com a paràmetre.

enumerate pot agafar com a paràmetre un nombre que serà el valor inicial de la seqüència (per defecte zero). La seva sintaxi és doncs enumerate(iterable, start=0)

Amb això podem escriure el codi anterior com

1
2
3

x = ['a','b','c']
for i, item in enumerate(x):
    print i, item

o sí volem comptar a partir d'1

1
2
3

x = ['a','b','c']
for i, item in enumerate(x, 1):
    print i, item

El nom a més és prou descriptiu de la funcionalitat que fa, amb la qual cosa el codi ens queda fins i tot millor documentat.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La pregunta a la que vull intentar respondre en aquest article, és la que fa força gent que vol canviar la manera en que fa aplicacions web i com que ha sentit parlar molt bé de Django, s'atraca a aquest bastiment amb l'esperança de poder millorar la seva productivitat, és a dir: què he de saber per començar a fer webs amb Django?

Primer de tot em de saber què és Django. Django és un bastiment, és a dir, tot un conjunt de llibreries que interactuen entre sí i que estan orientades a fer i mantenir llocs i aplicacions web.

Primera cosa, doncs, Django no és un llenguatge de programació. Per a fer servir Django es necesita conèixer el llenguatge de programació amb el que està creat i aquest llenguatge no és ni més ni manco que Python.

Segona cosa: Com a bastiment que és Django requereix que les coses es facin d'una determinada manera, és el que anomena modle MVT (Model Vista Template), però al mateix temps ens està dient que per sí sol Django no ens construirà la nostra aplicació. Hi haurem de fer feina, segurament aquesta feina serà més ràpida i productiva, però no hi ha solucions màgiques.

Prerequisits

• Se suposa que sabeu programar en algun llenguatge d'alt nivell.
• Se suposa que teniu coneixements d'HTML i CSS
• Se suposa que teniu coneixements del que és una base de dades relacional i d'SQL
• Se suposa que saber fer anar la línia de comandes

Si no compliu aquests quatre requisits convendria replantejar-se el tema. Segurament trobareu que Django no és l'eina màgica que havíeu suposat.

En aquests temps de crisi costa molt dir que no als clients i una vegada emmerdats anar cercant l'eina màgica que ens tregui del problema. Per molt bona que sigui l'eina sempre hi haurà una sèrie de requisits, si no els compliu, millor cercau una altra cosa (potser una altra feina?) o anau invertint en la vostra formació de base.

Supòs que tots els que llegiu això compliu de sobra aquests requisits i m'estic passant de prudent i tiquis-miquis, però tenc una anècdota molt recent: l'empresa per la que treball habitualment va demanar un pressupost a una empresa externa. A aquesta empresa (no diré noms, però no és de Mallorca) se li va demanar que el pressupòs contemplàs que el llenguatge de programació triat per fer l'aplicació fos Python+Django, Java J2EE (amb Hibernate, Spring i JSP) i que en tot cas podien presentar la proposta per PHP. La proposta Java feia servir CakePHP i Zend i cap referència a cap tecnologia Java. La proposta PHP cap referència a versió de PHP. Imaginau quina impressió dóna el pressupost! Per acabar-ho de rematar la primera cosa que deia és que s'havia de fer l'anàlisi de requeriments. Què s'ha pressupostat doncs? Entenc que amb la crisi tothom està arreplegant tot el que pot, però tot té un límit!

Així doncs, per a començar, suposarem que ja teniu un cert nivell informàtico-programador i que no és la primera vegada que sentiu parlar de l'HTML i heu picat planes web a mà. L'SQL potser inicialment no serà tant necessari, però si realment volem arribar a fer aplicacions web mantenibles és imprescindible saber-ne i conèixer al manco els fonaments de les bases de dades relacionals.

Bé, ja ho tenim clar, i si heu arribat fins aquí ara estareu esperant que us digui cap on heu de tirar, què és el que s'ha d'aprendre i amb quin ordre per fer que la corba d'aprenentatge sigui el més suau possible. Som-hi doncs!

El bàsic de Python

Python és un llenguatge de propòsit general, molt net i estructurat. Es poden fer tant aplicacions de consola, aplicacions web o aplicacions gràfiques, el que vulguem. El que propòs aquí es el mínim que convé saber per poder fer webs quan abans millor i anar aprenent el llenguatge i les seves llibreries associades així com ho necessitem.

Una guia molt senzilla és la que tenim a Python para todos de Raúl González Duque, i que ens servirà com a referència d'estudi i com no el tutorial de Python. Què hem de saber en aquesta etapa?

La consola

• Utilitzar Python en mode consola: Python com a calculadora
• Instal·lació i execució d'iPython

El llenguatge

Hem de perdre la por a fer feina amb una consola de comandaments. La consola ens permetrà experimentar ràpidament amb el llenguatge, ens n'adonarem del que representa fer feina amb un llenguatge interpretat i fer fer-ho am iPython a més ens permetrà veure algunes de les possibilitat d'aquesta consola (que no oblidem la utilitza Django si està instal·lada).

• Creació del "Hola Món". Establim les regles de tabulació (tabulació a 4 espais, UTF-8 i format Unix pels arxius és la meva elecció.)
• Tipus bàsics: experimentació amb el intèrpret i l'editor. Nombres, cadenes, boolenas, llistes, tuples i diccionaris.
• Sentències de control: if, for, pass, break i continue
• Dates a Python.
• Creació de funcions bàsiques. Paràmetres per nom, valors per defecte.
• Documentació i comentaris

Amb això ja tindrem les nocions bàsiques del llenguatge. Encara no hem entrat en tota la potència de Python però si hem programat en una altra llenguatge ja tindrem en ment un bon anàlisi comparatiu. Segurament ja estareu pensant com refer alguns programent en Python.

• Orientació a objectes bàsica.
• Les funcions són també objectes. La funció lambda
• Els paquets.

Amb un poc de sort ja sabreu què és la orientació a objectes, si nó és un bon moment per aprendre'n. L'objectiu és adonar-nos de que tot en Python és un objecte i com s'estructura el codi en classes, mòduls i paquets.

• Programació funcional: fonamental veure la comprensió de llistes.
• Ordenació de llistes.
• Creació Manipulació de fitxers, utilització de les llibreries os y sys
• Les excepcions.

Amb això ja tindrem gairebé el 80% del que necessitarem per fer una aplicació de consola, però no oblidem que a més nosaltres volem fer aplicacions web i a més amb Django, així que afegirem un parell de coses més:

• Expresions regulars bàsiques amb Python. L'eina Kodos.
• El mòdul Sqlite3 i el plugin de Firefox per a gestionar les bases de dades Sqlite.
• l'easy_install. Hem de saber què és i com utilitzar-lo per a instalar noves llibreries.
• Batteries included. Convé saber què significa aquest concepte i veure, al manco llegir, quines són les principals llibreries que Python inclou i què fan.

Amb això ja ens estam orientant cap a la web i Django. Les expressions regulars les farem servir sovint a Django a l'hore de mapejar urls amb les funcions Python corresponent. El mòdul sqlite ens permetrà veure el que és la API d'accés a base de dades de Python, familiaritzar-nos amb sqlite i si no ho havíem fet ja, començar a instal·lar els primers plugins de Firefox. Perquè tothom té Firefox per a desenvolupar webs, no?

Django

Podem començar a fer aplicacions web una vegada coneguem i ens sentim còmodes amb el llenguatge. El temps dedicat a Python no és per res temps perdut, ben al contrari. Feis exercicis, creau scripts, llegiu codi, l'important és poder llegir Python i que les instruccions surtin de manera natural.

• Instalau Django des del subversion
• Feis el tutorial de Django.

No està pensat per ser un manual de millors pràctiques sinó per mostrar el principal del bastiment i tenir alguna cosa repetible, una base comú.

• Mirau appfusedjango, el subprojecte project. Està fet per a crear nous projectes pel mètode de copiar i aferrar.

Els models

• Creació de models: l'ORM de Django.
• Utilització de la consola per a introduïr dades als models
• Utilització del manager de Django per afegir dades.
• Execució de consultes fent servir l'ORM

En les aplicacions web passarem força temps manipulant dades, bé des de la web o bé directament amb scripts i la consola. Convé que no hi hagi por.

Les plantilles

• Creació de planes estàtiques

És un primer exercici. Consisteix en agafar un grapat de planes estàtiques i convertir-les en una aplicació Django utilitzant el direct_to_template. Això ens ha de permetre veure com, sense més complicacions podem fer planes a la manera tradicional (i inefectiva).

• Les plantilles de Django: definició i concepte d'herència.
• Filtres
• Tags
• Refer les planes estàtiques anteriors fent servir l'herència de plantilles.

Aquí començarem a veure les possibilitats que té Django respecte de la manera més tradicional de fer les coses. Veurem que fer webs amb blocs i pensant en diferències és molt productiu.

El view.py i url.py

• Veure com les urls mapegen contra funcions Python
• Utilització de les plantilles
• Les expressions regulars i les urls.
• HttpResponse, render_to_template , redirect

Ens n'hem d'adonar que no hi ha màgia, que tot és codi Python que envolcalla al protocol HTTP.

Formularis

• Creació de formularis.
• Renderització de formularis
• Formularis lligats a dades
• Validació i control d'errors.
• Pujar arxius i imatges.
• L'autenticació

Dedicau el temps que sigui necessari als formularis. De ben segur en fareu molts al llarg del cicle de vida d'una aplicació web. Django és molt elegant en la seva utilització.

Quan es veuen els formularis m'agrada passar també per l'autenticació, ja que en aquest punt ja es té tot el necessari i consider que l'aspecte de la seguretat s'ha de tractar tot d'una que es pot.

Reflexió

No sé ben bé com anomenar aquesta etapa, però convé que dediqueu alguns dies a fer una aplicació web des de zero. Pensau en alguna que es us agradaria fer i vegeu-ne la seva viabilitat. Reduïu-ne l'abast si és necessari, però intentau fer una aplicació web completa.

L'objectiu és adonar-nos del que sabem, del que no sabem i del que no sabíem que no sabíem.

Django i Javascript

• Json i Django
• Exemple de jQuery (o la llibreria que utilitzeu) i com lliga amb les urls y views de Django.

No sols d'HTML viu l'home i cada cop les planes web tenen més javascript. Django és agnòstic en el que fa a la llibreria a utilitzar, però sigui com sigui fa que sigui realment fàcil interactuar amb llibreries javascript com jQuery, extjs o Dojo.

Fent les webs escalables

• Internacionalització
• Els principals middlewars.
• Sistemes de cachés
• Context processors
• Creació de tags pròpies

Aquí ens n'adonarem de les respostes que dóna Django als problemes reals quan la nostra web passa de ser una idea a estar en producció i té prou visites. Hem de veure a més com podem interactuar amb les peticions HTTP i amb la informació que passam a les plantilles.

Reutilització

• Convé adonar-se de com Django permet reutilitzar codi, de l'estructuració del projecte en aplicacions i d'aquestes en mòduls PYthon.
• Repassar els principals settings.
• Repassar les aplicacions que ja venen incorporades al bastiment: e-mail, sessions, paginació, signals, sitemaps i sites.
• Algunes aplicacions interessants: django-photologuer, django-page-cms, django-rosetta, django-command-extensions

Reflexió 2

Tornau a fer l'aplicació anterior incorporant javascript, internacionalització, cachés i tags fets ad-hoc. Mirau com queda el codi i com queda l'aplicació.

Arribats a aquest punt ja estau llets per anar agafant cada vegada més coneixements. No oblideu que aquests han de venir tant des de la part Python com de Django. Quan una cosa no vegeu com es pot fer amb Django cercau en el propil llenguatge. Si és un problema comú segur que està solucionat en el propi bastiment, i si no ho està vol dir que ja té solució a nivell de llenguatge de programació.

Això és tot, esper que us servesqui de guia i us animi a fer feina en aquest bastiment. Recordau, però que no hi ha bales de plata i que tot requereix esforç i dedicació.

Avui, mentre explicava a la gent de l'equip web un grapat d'optimitzacions que podem fer per fer que les nostres aplicacions siguin més ràpides i actualitzables, al mateix temps pensava que en la potència que ens està donant Python i Django gràcies a la seva orientació cap a fer les coses com s'han de fer.

La comparació amb Java, l'altre llenguatge que feim servir, no pot deixar d'estar present, i llevat d'excepcions (poques) he de dir que la combinació Python i Django en surt sempre afavorida davant de Java.

Django està molt orientat a la web, però no de qualsevol manera, està orientat a fer webs que s'han de mantenir i que han d'escalar. Per això veus que és gairebé trivial fer coses que en altres plataformes resulten força costoses: qui no recorda el que s'ha de fer per fer un redirect amb Struts, per exemple?, o la complexitat que té validar formularis tant amb Struts com amb Spring?.

Django està orientat a fer aplicacions pel món real, això vol dir: que surtin ràpides, puguin sofrir moltes modificacions al llarg del seu cicle de vida i que es pugin actualitzar també molt ràpidament.

El bastiment segueix de molt aprop la filosofia de Python, la de mantenir les coses legibles i simples. Hi ha d'haver sempre una manera obvia de fer les coses, i quan fas feina amb Django veus que els 90% dels problemes que et planteja una aplicació web tenen resposta directa. La resta poden dur un poc més de feina, que normalment vol dir fer herència d'alguna classe.

Una de les darreres aplicacions en les que he pogut comparar Java i Python ha estat una aplicació que agafa XML, el manipula i el posa dins una base de dades. L'aplicació original, feta amb Java+Spring+Hibernate, va dur setmanes de feina, mesos si contam el manteniment posterior. Fer el mateix amb Python (lxml+sqlalchemy) ha duit menys de 4 dies-home de feina.

Posar l'aplicació Java en producció també va ser un poc malson per mor de les dependències entre les llibreries. Posar-la en Python dins un virtualenv és pràcticament immediat.

Tampoc ha resistit la comparació el manteniment i la correcció d'errors. El temps que passa per localitzar l'error i fer l'actualització en Python és mínim, en Java multiplicant per 10 o per 20 aquest temps.

Ens queda un tema: el rendiment. Com moltes vegades he dit per aquí el rendiment basta que sigui "prou bo", és a dir, per l'aplicació que estam parlant partíem d'un temps de càrrega d'entre 4 hores en les primeres versions Java, a 30 minuts a les darreres versions amb multi-fil. Amb màquines amb 8 Gb de RAM i menjant-se la màquina tant amb memòria com amb processador.

La versió Python també es feta amb multi-fil, on el nombre de fils és parametritzable, amb pool de connexions i demés. Sols que escrit amb un 10% de les línies de codi. El temps? Doncs 6 minuts i mig. Consum de memòria: mínim, ús de la CPU: intensiu però sense deixar torrada la màquina.

Python està orientat a que les coses es facin i es mantenguin. Per algunes tasques concretes potser no serà la millor solució, però cada vegada estic més convençut que és el primer que s'ha de provar. Si no va prou bé, el prototip ens haurà servir per a conèixer millor l'abast del problema sense haver-hi invertit molt de temps, i sempre som a temps d'optimitzar alguna secció del codi amb C, de maneres per utilitzar codi C (o C++) o bé d'escriure codi intermig que es transformi en codi C compilable n'hi ha força. Al wiki de Cpython (una de les eines que ens permet fer això) n'hi ha un bon grapat.