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.