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.