Una de les característiques que més m'agraden de Django per desenvolupar és que ja ve amb el seu propi servidor integrat. És un servidor no apte per entorns de producció, de fet a les planes de Django es recomana repetides vegades que NO es faci servir a producció, però que va molt bé al desenvolupament.

El que fa tenir aquest servidor és per una banda acursar el temps necessari per començar a desenvolupar. Una vegada creat el projecte i la primera aplicació, posam el servidor en marxa amb un python manage.py runserver i ja tenim accés a un complet servidor web.

A més ens permet depurar des del principi les nostres aplicacions. La consola del servidor que acabam d'executar mostrarà els missatges del servidor i els logs que li enviem com un servidor web qualsevol, però a més ens servirà de consola de depuració de Python.

Encara que hi ha entorns com Eclipse+Pydev que ens permeten posar punts de ruptura directament al codi, un dels mètodes més simples consisteix en escriure import pdb;pdb.set_trace() allà on vulguem que s'aturi el programa. Llavors, en arribar-hi a la consola on hem executat el servidor ens apareixerà l'entorn de depuració de Python (el pdb). Si volem fer un poc més de feina podem instal·lar l'ipdb i tendrem una consola de depuració amb autocompletat i resaltat de sintaxi.

A Python diuen allò de "batteries included" per indicar que amb Python hi ha tot el necessari per arrancar, Django segueix la mateixa filosofia, de manera que no necessitam configurar cap servidor web per començar a fer-hi feina i ens proporciona a més eines de depuració prou potents: la possibilitat de depurar amb pdb/ipdb o semblants, la depuració mitjançant els missatges d'error de les plantilles o la possiblitat de depurar evitantn la recàrrega amb l'opció de --no-reload del servidor de desenvolupament.

Una vegada ja tenim l'aplicació creada i depurada passam al desplegament. Pels experts de sistemes no ha de ser cap problema seguir les instruccions de les instruccions de desplegament de Django. Es pot desplegar en Apache (mod_python o mod_wsgi), damunt ngnix, lighthttp, Cherokee, ... En general no es tant cosa del servidor com de triar una tecnologia considerant el nostre entorn d'execució.

Perquè pensau que Django està pensat per ser escalable per amunt i per avall. Segons les restriccions del nostre entorn de producció ens convindrà elegir una tecnologia o una altra. Decidir si ens convé tenir un sols servidor http o separam l'execució de l'aplicació del servidor de continguts, quin tipus de caché farem servir, etc. etc.

Tot és molt flexible, però aquesta flexibilitat fa que ens tenguem que fer preguntes, Django no decideix per nosaltres com s'ha d'instal·lar. Fa recomanacions però en general s'adapta al que hi ha.

Si un disposa d'uns tècnics de sistemes com els que jo tenc la sort de fer feina, aquesta flexibilitat és fantàstica, segons l'aplicació decideixen la tecnologia que es fa servir, la caché, les instàncies que s'aixecaran o com es serveix el contingut estàtic. Si un s'ho ha de fer tot i no disposa d'un servidor propi (o al manco d'un servidor virtual) el desplegament vindrà marcat pel que ens deixi el nostre ISP.

Posar una configuració? Doncs no, dependrà de cada aplicació i de cada entorn. Sols un parell de recomanacions:

• wsgi funciona molt bé
• Si podeu separau el servidor d'aplicacions Django del servidor de contingut estàtic.
• Amb un poc més de pressupost es pot tenir un servidor dedicat o virtual configurat i podrem treure tot el suc a la nostra aplicació.

Si heu fet servir la documentació de Python, Django o potser alguna de les aplicacions més importants o darrerament li heu fet una ullada al Building Skills with Python us n'adonareu que comparteixen un estil comú. Django ha personalitzat les plantilles, però com podem veure a la part on explica com es crea i es contribueix a la documentació, podem feure que Django fa servir Sphinx.

Sphinx és l'eina amb la qual s'estan creant les documentacions dels principals projectes basats en Python (encara que ens permet escriure qualsevol tipus de documentació) i poc a poc esdevé la killer appplication de la documentació tècnica.

Començar amb Sphinx és prou senzill, sols necessitam tenir Python instal·lat i

$ easy_install Sphinx
$ sphinx-quickstart

i anar contestant les preguntes. Si heu compilat alguna vegada algun programa al món Unix veureu com quan acabin les preguntes s''haurà creat un directori amb un arxiu anomenat Makefile (make.bat per altres). Executant-lo ens crearà un directori build amb les bases del que pot ser la nostra documentació.

I és que Sphinx és bàsicament un compilador orientat a la creació de documentació. Agafa documents escrits en Restructured Text i crea un lloc web en HTML, genera un pdf o latex. Això vol dir que per poder treure'n el màxim partit s'ha de conèixer Restructured Text i fer-li una ullada a les comandes que Sphinx incorpora per crear les taules de contingut, fer el resaltat de sintaxi, incorporar imatges o fórmules matemàtiques. Una vegada passat el període d'aprenentatge (que ja us dic que és curt) veureu que el resultats que s'obtenen són espectaculars.

Ja he dit sovint pel blog que m'agrada escriure la documentació (i escriure en general) en text pla, utilitzant LaTeX, Markdown o ResTructured Text. Sphinx ajunta el fet de poder escriure la documentació com m'agrada amb un resultats realment professionals. És a la documentació hipertextual el que LaTeX és per a la documentació científica.

Potser ara us estareu demanant perquè fer la documentació amb aquesta eina i no limitar-nos a un document amb OpenOffice (o fins i tot en Word!!!), se m'acudeixen un parell mallorquí de raons:

• El text pla es pot posar damunt un control de versions.
• Permet que molta gent participi en la creació de la documentació.
• Sphinx ens dóna unes plantilles que fan que la documentació llueixi.
• El ressaltat de sintaxi Python ve de sèrie i costa ben poc fer el ressaltat per altres llenguatges.
• El cercador està inclòs a la documentació

Però sobretot, perquè amb Sphinx escriure documentació és divertit. Pots distribuir-te la feina com vols, no has de passar ànsia per la maquetació final, ni per que les imatges se t'han descol·locat i no saps on han anat a parar (si heu fet documents de més de 20 planes amb un processador de text sabreu què vull dir). I que escriure documentació no sigui feixuc segurament farà que ens faci menys peresa documentar i tothom ens estarà eternament agraït. Jo ja he començat amb la documentació d'appfusedjango que no se digui que no predic amb l'exemple.

Personalment crec que Django ha marcat un abans i un després en el món de la documentació de projectes, de tal manera que cada dia més projectes i aplicacions emulen la manera de documentar de Django i Django (com Python) fa servir Sphinx. Demostrant que per a que un projecte tengui èxit no basta que sigui bo sinó que ha d'estar ben documentat.

No cerquem en Sphinx la bala de plata. Fer bona documentació no és senzill, Sphinx sols fa que sigui menys pesat i ens dóna un resultat final molt més amigable als nostres lectors. Un dels creadors de Django,Jacob Kaplan-Moss, ha escrit un conjunt de posts damunt com s'ha d'escriure bona documentació: Writing great documentation, de lectura imprescindible. Però tot i que no sigui fàcil s'ha de començar, ens hem d'avesar (i jo el primer) a que Sphinx sigui part de les eines de projecte, a escriure documentació i a millorar el nostre estil, tanmateix diuen que la pràctica fa el mestre, no?

Acab de devallar-me la darrera versió (la quatre) de l'editor Ulipad. És un editor fet en Python damunt les llibreries wxPython.

La primera impressió que m'ha donat l'editor es pot resumir en una paraula: velocitat. És un editor molt ràpid, carrega en pots segons i l'autocompletat de codi, a més d'estar a un nivell molt bo, és també molt ràpida. Sols per això ja trob una justificació més que raonable per donar-li una oportunitat.

La gestió de projectes és un tant limitada, únicament ens presenta un sistema de fitxers, però és suficient per la majoria de projectes.

El suport de Python és molt bo i és extensible mitjançant plugins. En té un per Django que ens deixa executar el servidor de desenvolupament de Django. Tanmateix tot això és un poc anecdòtic si ho comparam amb la senzillesa i usabilitat d'aquest editor. Per ara (i duc una hora llarga amb ell) m'està agradant molt.

Destacar la bona integració que té amb la shell de Python, basant-se en pyCrust, la integració amb pylint i un parell d'utilitats que ens fan la vida més fàcil: un testejador d'expressions regulars i un gestor de trossos de codi (snippets).

Una altra de les coses que m'ha agradat és el suport que té per a l'edició de documents en RestructuredText, permetent-nos tenir una previsualització en temps reals de com queda el document.

He trobat a faltar un major suport per l'execució de test unitaris (sols té integrats els doctests) i la integració plena d'un depurador. Es recolza en un depurador molt bo, en Winpdb, però en aquesta versió pareix que s'ha deixat un tant desactualitzat. Supòs que obrint un ticket s'arreglarà aviat.

És un editor senzill, útil per que vol un editor gràfic i no pot o vol fer servir IDEs com Netbeans o Eclipse.

Actualització

Hem arribat als 20. La resta haureu d'esperar a la propera!

Tothom que s'ha apuntat fins al meu darrer comentari, el 24 entra dins aquest primer workshow. Aniré posant per aquí i pel Twitter les novetat que hi hagi.

Em sap greu pels que els agradaria venir i han quedat fora, però compreneu que la sala és petita, 20 persones són moltes i el format que hem pensat (amb voluntaris ajudant als nouvinguts) no dóna per massa més.

Si la cosa agrada us promet que no serà la darrera! :)

No sé quin nom posar-li, en Paco proposa al twitter "programming python & django before beers" o "def bit():" però a les hores que acabarem (més de les 18:00) ja us dic jo que al Parc Bit no hi ha res obert per anar fer unes cerveses. M'ha agradat molt el Creant Bits, començant amb Python i Django i ja veurem com acabarem...

Així doncs faig l'anunci oficial:

Creant Bits amb Python i Django
Divendres 4 de desembre
Hora: 16:00 a 20:15 (o més)
Lloc: Sala de formació del Parc Bit
Organitza: APSL
Col·labora: Incubit, que ens deixa la sala.

En quant als continguts, crec que els hauríem d'afinar entre tots. Per començar jo us proposaria el següent:

• Introducció a Python (1.5h)
• Pausa (15 min)
• Introducció a Django (1.5 h)
• Pausa (15 min)
• Posant una aplicació Django a producció (45 min)

La idea seria que la gent li fa ganes saber què és això de Django i Python pugui fer-se'n una idea. Es donarien quatre pinzellades de Python, amb exemples que tothom pugui executar al seu portàtil.

Per la part Django: mostrar com començar, que és, veure com es pot crear una plantilla, l'organització del codi i veure alguns exemples d'aplicacions, etc. Ha de servir com a presa de contacte i que tothom pugui fer-se una idea de les possibilitats que té aquest bastiment.

Com que al final el que volem tots és posar-lo en producció, s'explicaria com n'és de bo de fer posar-ho a un entorn Apache.

Però com us dic sols és una idea. El temps és limitat, però si estau interessats en donar-li una altra orientació estic obert a qualsevol possibilitats.

Requisits

• Tothom amb el seu portàtil, millor amb Linux. Si algú vol dur el seu fix i pantalla serà benvingut, però avís que hi ha una passejada i no sé com està la sala d'endolls.
• Python 2.5 ó 2.6 instal·lat, el 3.x no us funcionarà amb Django.
• Un editor amb ressaltat Python: vim, gvim, notepad++, Netbeans, Eclipse, ...
• La darrera versió estable de Django insta·lada. La 1.1.1 en el moment d'escriure això.
• Navegador Firefox amb el Firebug instal·lat
• iPython instal·lat

Inscripció

Lliure, però teniu en compte que la sala té una capacitat d'unes 20 persones, així que, per favor, deixau un comentari per a que pugui controlar quants serem i saber si hem arribat al límit de la sala. Al comentari podeu posar el tipus d'orientació que us agradaria.

Quan serà la propera?

Dependrà de l'èxit d'aquesta i de que Parc Bit/Incubit tengui lliure la sala i ens la cedesqui (des d'aquí moltes gràcies des de ja!). M'agradaria que això acabàs com a grup d'usuaris/empreses més o manco estable, però això ho hem de decidir entre tots.

Altres

Miraré d'informar-me com està la sala en el tema de connexions d'Internet. Si hi ha connectivitat fins i tot podríem intentar fer un projecte en grup, si no aquesta potser la propera vegada.

M'agradaria poder dir que hi haurà catering, però seria mentida :)

Fa estona que volia posar contingut no directament relacionat amb el Blog a Trespams, ja sabeu, quí soc, sobre el blog i coses d'aquests, però no ho arribava a fer. Finalment m'he decidit i aprofitaré per explicar com podem fer aquest tipus de coses amb Django.

El primer de tot és centrar el problema. L'objectiu és tenir lligat a la nostra aplicació (el blog en aquest cas) un conjunt de planes que no estan relacionades amb l'aplicació o aplicacions, que no han de ser editades o ho han de ser molt poc.

El cas típic són les planes de condicions legals, les planes de "sobre mi" dels blogs. Agafau la idea, no?

Com que és un cas molt comú Django té una aplicació al contrib pensada per fer precisament això. Ens proporciona un formulari on podem posar el títol, el contingut en format html i indicar si volem la plantilla que s'utilitzarà, si permetem comentaris o no i si l'usuari ha d'estar registrat al sistema per veure la plana. Aquesta aplicació se'n diu Flatpages.

La documentació de Django està força ben explicada.

1. Afegim 'django.contrib.sites' a INSTALLED_APPS del nostre setting.py si no hi és ja. Si no hi era convé fer un syncdb. Crearem una entrada al Sites amb la nostra url i també posarem el SITE_ID del settings.py el valor de l'id d'aquest registre. Si sols en teniu un serà 1.

2. Afegim 'django.contrib.flatpages' als INSTALLED_APPS.

3. Afegim 'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware' a MIDDLEWARE_CLASSES del settings.

4. Executam python manage.py syncdb per a generar les taules de Flatpages.

5. Cream el directori flatpages dins el nostre directori de templates i cream l'arxiu d'default.html. Aquesta serà la plantilla per defecte que s'utilitzarà. Hem de personalitzar-la com volguem. A aquesta plantilla flatpages li passa la variable flatpage, a partir de la qual podem obenir el títol i el cos del text amb {{flapage.title}} i {{flatpage.content}}. Podeu fer una ullada al codi de trespams del svn per tenir-ho més clar.

Ara ja sols és cosa d'anar afegint registres amb les urls i continguts que volguem. Django en no trobar una plana abans de mollar un 404 el que farà és anar a flatpages, si la url correspon a una que hagem definit generarà la plana a partir de la plantilla i els continguts del registre corresponent.

Per acabar, dir que no fa falta posar el filtre safe a les variables. Per defecte se suposa que l'html és segur, ja que no està pensat per a que un usuari extern a l'aplicació l'editi.

Pareix que alguns desenvolupadors de PHP s'estan plantejant anar cap a Python i Django com a una via per a fugir de les complexitats i problemes del PHP.

Des d'aquest blog vull encoratjar-los a al manco provar-ho i després decidir si convé o no fer l'esforç. Personalment pens que sí, pero tot dependrà de l'experiència que tengui cada un i de com vulgui enfocar els projectes.

Per ajudar en la decisió trob que és força interessant visitar dos enllaços:

• Drupal or Django
• Discusió a Django Users

El primer és una apunt i el segon és la discusió a un fil de la llista d'usuaris de Django. No us perdeu els comentaris, on es discuteix si Django i Drupal són comparables o no.

Aprofitant que aviat hi haurà força dies de vacances he fet la meva comanda típica a Amazon. Cada cop va millor el servei, estic elegint l'opció de courier (el segon servei d'enviament per preu), que en teoria ha d'estar entre 3 i quatre setmanes i m'estan arribant els llibres en cosa de 10 dies. Els vaig comanar el 3 i han arribat entre el 12 i el tretze, en dos enviaments diferents.

Pel servei que dóna he de dir que soc client fidel d'Amazon i que cada vegada que intent comprar llibres per correu a llibreries suposadament potents d'aquí, cada vegada me n'he d'empenedir. La única ocasió que record que va funcionar tot bé en temps i dobler va ser comprant llibres de ciència ficció de segona mà a una llibreria d'aquells amb una plana web dels anys 80.

Potser algun dia em passaré a la tinta electrònica, però ara per ara el DRM i jo no som bons amics. Vull poder fer el que vulgui amb el llibre, llegir-los on i com jo vulgui i no estar amb l'ai al cor per si un dia algú decideix que ja tenc prou llibres al lector o que no els puc compartir amb ningú.

Per mi els llibres són una eina de feina, d'esbarjo i aprenentatge. M'hi deix una pasta, ho sé, però tanmateix no tenc massa mals vicis. M'agradaria poder dir que com comentava Joel Spolsky, que l'empresa em subvenciona els llibre o que hi ha una biblioteca potent, però no és així, no fins que APSL no tengui prou capital al manco. A la única empresa on m'he trobat una biblioteca tècnica més o manco decent va ser a Infomallorca (Viajes Iberia), on En Juan - mai vaig aclarir si eren seus o de l'empresa- se n'encarregava de mantenir-ne una bona col·lecció, que no cal dir-ho vaig anar devorant.

A les altres empreses ha estat sempre molt complexe justificar la compra de llibres. Tan complexe que m'estim més pagar els llibres de la meva butxaca tot i que sovint els necessit per la feina o m'ajuden a fer la feina millor.

Avui he fet neteja dels llibres que tenia al lloc de feina. Ens mudam d'oficina i ens han dit que allà és tot tan de disseny que no podem dur-hi més que els ordinadors, que no hi ha lloc per res, potser el just per seure i prou. La pissarra també l'hauré de deixar. Al manco a la nostra petita oficina d'APSL no hi ha aquestes restriccions (això sí, encara no hi ha ADSL).

Aquesta remesa té un poc de tot, us ne faig cinc cèntims, tant just els he fullejat, però aquí teniu els títols i el que n'esper de cada un:

• Agile Estimating and Planning. Estimació de projectes àgils. Una metodologia àgil no vol dir no fer pressuposts, vol dir tenir orientació cap allò que aporta valor i en el món de l'empresa es comença aportant valor si les nostres estimacions formen part d'un pla de negoci. És el que he començat a llegir i per ara m'està agradant molt.

• Plone 3 Theming. Plone és al meu entendre el millor CMS lliure i no lliure del mercat. Pensat per dur llocs amb molts d'editors i un volum molt gran, un dels seus punts foscs és el de com personaltitzar l'aspecte del lloc. Estic pensant fer el nou lloc d'APSL damunt Plone sols per viure en carns pròpies el que pot ser l'adaptació d'un disseny que sé exactament el que ha duit amb Django.

• Behind Closed Doors. Llibre dedicat a les tècniques de management, a la gestió de persones i conflictes des del punt de vista tècnic. Encara que molts consultors de RR.HH. posen tothom al mateix sac gestionar equips tècnics i de programadors no té res a veure amb gestionar equips de cadenes de muntatge o de vendes. També n'he llegit d'aquest i la veritat és que hi ha moltes situacions que quan pens com o si es podria extrapolar a un equip de programadors em faig un fart de riure.

• Cloud Application Architectures. Llibre damunt arquitectures de núvol. Pel que pareix està a camí entre informació per administradors de sistemes i responsables de negoci que volen saber a on se la juguen. Sovint he dit que la gent de sistemes convé que sàpiga programar per fer millor la feina, i de la mateix manera convé que programadors i caps de projecte com jo mateix estiguin al dia de les possibilitat i implicacions de la tecnologia més de sistemes.

Així com els vagi llegint aniré posant la ressenya. Ara estic llegint a Pablo Tusset: "Sakamura, Corrales y los muertos rientes", tenc ganes de veure si millora a les acaballes, perquè per ara, fluix, fluix.

Per experiència sé que una de les coses que més ens consta a la gent que fem feina amb bits és posar preu a la nostra feina. Tenim una feina que no entrega un producte físic i on fer i desfer no implica feina física. Si en lloc de vendre còpies el que feim és vendre serveis: programari a mida, configuració de servidors, adaptació de programes, etc. llavors tècniques de màrqueting com les que ens ensenya Neil Davidson a Don't just roll the dice són poc aplicables.

La cosa està en que hem de posar un preu per hora a la nostra feina i aquest preu ho hem de posar amb criteris empresarials, és a dir, valorant el que feim i el que el mercat diu que pot valer la nostra feina.

Per posar aquest preu el que necessitam és una referència. L'ideal podria ser anar al sector i demanar a quant cobra l'hora i quins són els seus marges, però donada la naturalesa de la feina i del sector em tem que aquesta informació estaria ben esbiaixada. A veure:

Una cosa és posar un preu per hora i l'altra és que les hores ens surtin a aquest preu (que és el desitjable). L'ideal és que la desviació entre els dos factors sigui mínim, és a dir, hora feta hora facturada, però això vol dir o bé fer feina amb el que se coneix com a "time and materials", que és el que en construcció se'n diu fer feina a jornal, o bé no equivocar-se massa en els pressuposts i dur un control real de les hores que es fan i de les despeses incorregudes a cada projecte.

Ens hem de plantejar què val el nostre temps i comparar-lo amb el que guanyaríem fent feina amb una altra activitat. Una de les comparacions més senzilles és comparar a quant ens surt l'hora real de feina amb el que ens cobra la netejadora o el mecànic per canviar l'oli, demanar-nos si les hores ens estant sortint millor que si treballàssim en qualsevol d'aquests oficis, o bé si els nostres ingressos són els que són perquè feim més hores que el rellotge.

Crec que és una reflexió personal, però que tothom que fa feina pel seu compte s'ha d'arribar a fer i quan més aviat millor, mentre perquè no començar a dur un control de hores per projecte? Ànims, no és tan complicat, el Trac per exemple té plugins per fer-ho, Eclipse i Netbeans ens permeten controlar el temps que dedicam a cada projecte, fins i tot una llibreteta o agenda que puguem dur damunt ens servirà. No controlar els temps per la gent que viu de vendre serveis és com aquella empresa que no s'empatxa de la comptabilitat i sols sap si té doblers a la caixa o no. Controlar el temps ens permet saber què ingressam en la nostra feina, en què dedicam les hores i poder saber quin és el punt de tall, és a dir, el preu per hora a partir del qual he cobert les nostres despeses bàsiques i començar a poder dir que guanayam doblers amb la nostra feina.

En aquest article intentaré definir què es la mantenibilitat del programari, com es classifica i miraré d'analitzar l'impacte que pot tenir un llenguatge de programació tipat o no en relació a la mantenibilitat. És la precuela de l'apunt Mantenibilitat en llenguatges tipats i no tipats d'aquest mateix blog, on intentaré definir què és el manteniment i recolzar amb xifres l'impacte que pot tenir utilitzar un llenguatge tipat o no.

Definició de manteniment: La modificació d'un producte de programari després de la seva posada en producció a fi i efecte de corregir defectes, augmentar-ne el rendiment u altres atributs o adaptar-lo a les modificacions de l'entorn.

El manteniment de programari es classifica en quatre categories:

• Manteniment correctiu. És a dir, la correcció d'errors (bugs) de tota la vida.

• Manteniment adaptatiu. No hi ha canvi de funcionalitat però ara s'ha de fer feina amb altres condicions. Per exemple un canvi a l'IVA o a un nou plà contable.

• Manteniment perfectiu o de perfeccionament. Destinat a afegir alguna característica nova al sistema, per tal de fer-ho millor.

• Manteniment preventiu: Fet de manera interna per tal de millorar el sistema sense afectar-ne a les característiques externes.

Podem agrupar el manteniment adaptatiu i el perfectiu com a millores al sistema, considerades aquestes com quelcom que ha demanat l'usuari i que no estava previst a les especificacions del programa quan es va posar en producció.

Dins el mateniment correctiu podem trobar d'acord amb William E. Lewis les següents categories:

• Errors de disseny: el sistema no s'adapta al que l'usuari havia demanant.
• Errors de lògica: parts del programa no testejades, condicions no previstes, etc)
• Errors de codificació. Errors que resulten de una mala implementació de la lógica o per una mala escriptura del codi.
• Errors de càlcul. Resultat de mesclar tipus incompatibles o fer els càlculs agafant dades incorrectes.
• Errors d'entrada/sortida. Errors de forma, protocols d'entrada i sortida incorrectes, etc.
• Errors d'interfície: nombre de paràmetres incorrectes per exemple (pensen en interfícies XML sense anar més enfora).
• Errors en la definició de dades: Fallades d'inicialització de dades, mal us d'indexs,...

D'aquests tipus d'erros, fitxem-nos que el compilador tipat sols caçarà alguns dels errors de codificació i alguns dels errors d'interfície. Els errors de càlcul no es refereixen sols a mesclar tipus, sinó també a agafar les dades que no toquen o fer operacions incorrectes. Fins i tot en el cas de la mescla de tipus, un llenguatge tipat tampoc és cap garantia, ja que la majoria tenen maneres de passar dades d'un tipus a un altre, i qualsevol programador que codifiqui per coincidència pot acabar aplicant el typecast necessari per a que el compilador no es queixi.

El més important de tota questa classificació d'errors és notar que la gran majoria són errors que no depenen de si el nostre llenguatge de programació es tipat o no, es poden donar en qualsevol llenguatge.

Però anem un poc més enfora. Resulta que en terme mig un 60% del cost d'un programa és cost de manteniment (els intervals van entre un 40 i un 80%). De totes les fonts d'errors que hem enumerat, resulta que la correcció d'errors representa sols un 17% del total del cost de manteniment. Un 60% es dedica a tasques de millora del sistema (el que hem anomenat manteniment perfectiu), representant el manteniment adaptatiu un 18% del cost. El 5% que queda es dedica al manteniment preventiu, és a dir, tasques de mantenimient internes i sovint lligades a la refactorització del codi.

Veim doncs que el cost de manteniment no està en la correcció d'errors, sinó en el manteniment evolutiu i en el manteniment perfectiu. És a dir, el nombre de millores que ens demanaran els usuaris del nostre programa (externs o interns en el manteniment preventiu) representen el 83% del cost de manteniment total.

Perquè aquest cost? Doncs perquè un canvi representa que s'ha de definir i entendre el canvi, avaluar-ne l'impacte (15%), mirar la documentació (si existeix) del programa (5%), seguir el programa per veure que fa el que se suposa que fa (25%), fer el canvi (20%), testejar i depurar (30%) i finalment actualitzar la documentació (5%). És a dir, quan s'afegeix una nova característica a un programa en producció el cost emnor és el de fer el de codificar, el gruix del cost se'n va en entendre el problema (45%) i en la depuració (30%), és a dir, un 75% en tasques que no són directament de codificació i per tant on el tipat del llenguatge poc hi té a veure.

Llavors quan ens demanam què fa un programa mantenible, ens estam demanam com podem fer que el temps necessari per entendre el programa sigui el mínim possible. Reduint el temps d'entendre el que fa el programa reduïm el cost de manteniment i per tant fem el programa més mantenible.

I entendre el codi implica llegir el codi, poder seguir-lo. Es a dir, el codi per a ser mantenible ha de ser escrit pensant en les persones, recordau, no hem d'escriure codi per a que ho executin les màquines sinó per a que ho llegeixin les persones. Un codi millor estructurat és més fàcil de llegir, variables ben posades, codi que no es repeteix, etc. Una vegada més el tipat del llenguatge no hi té res a veure, de fet la literatura ens parla que les inspeccions de codi disminueixen fins en un factor 10 el cost de manteniment, per què? Doncs perquè fan que els programes siguin llegibles, un codi mal d'inspeccionar no passa i per tant no es mantindrà.

En conclusió, la mantenibilitat no és la dóna el tipat del llenguatge, ens la dóna la claretat i l'expressivitat del mateix i la nostra pròpia metodologia de programació i bones pràctiques.

Referències:

• http://www.research.umbc.edu/~cseaman/ifsm698/lect0903.ppt
• Software testing and continuos quality improvement. William E. Lewis (p.285)
• http://en.wikipedia.org/wiki/Software_maintenance
• Facts and Falacies on software engineering. Robert L Glass (p.115)
• Peer Revies in Sofware. Karl E. Wiegers (p. 6)

Python Essential Reference, en la seva quarta edició és un llibre dens, com es pot esperar d'un manual de referència, així que no és el millor llibre per a introduir-se en la programació amb Python, en canvi, si ja heu seguit algun tutorial, o algun altre llibre introductori, trobareu que Python Essential Reference toca aspectes pocs coneguts del llenguatge.

El llibre està dividit en tres parts, la primera, més de 200 planes, tracta la sintaxi del llenguatge en profunditat, la segona part, la referència en sí, va desgranant les principals llibreries que hom pot trobar de sèrie en una distribució de Python i la tercera ens ensenya com extendre Python amb C i com es comunica Python amb altres llenguatges (C, .Net o Java).

No es pot dir que ell llibre tengui caràcter pedagògic, però els exemples són als punts justs on ajuden a fer-se una bona idea del que se'ns explica. Com que l'autor David M. Beazley també contribueix a la documentació de Python trobarem que hi ha força semblances entre la documentació oficial i aquesta referència, tot i això, la manera d'explicar algunes coses i l'organització de la documentació és diferent i fa que se n'aprofiti més la lectura.

És un llibre per tenir aprop quan un programa en Python i per rellegir de tant en tant, a l'era Internet aquets tipus de manuals en paper són cada cop menys necessaris, però tot i això útils per gent com jo que prefereix llegir amb comoditat i/o en qualsevol lloc o moment.

Fitxa tècnica:

Python Essential Reference 4th Editon
David. M. Beazley
Ed. Addison Wesley
ISBN: 978-0-672-32978-4

Quan surt aquesta discusió sovint, al manco al meu àmbit, la discusió es redueix a comparar Java i Python. Recentment en Paco ha obert la capsa dels trons al twitter amb una afirmació "Para escribir código mantenible, mejor un L.P. fuertemente tipado. Si es compilado, mejor".

Damunt el tipat o no em remetré al post de Ned Batchelder i a un comentari d'aquest post, amb al qual hi estic d'acord en un 90%, que traduït lliurement i sense limitar-ho a java diria:

1. Python maximitza la productivitat dels bons programadors

2. Els llenguatges tipats (Java a l'original) minimitzen el mal que els programadors mediocres poden fer al sistema.

Tant de bo la segona afirmació fos certa. La gent pot ser molt creativa i cap tipat del món no pot evitar que es faci un borrat complet contra la base de dades, que s'equivoqui amb l'algorisme del càlcul de l'IVA, les possibilitats són infinites. La referència obligada de que el tipat fort no és cap garantia de mantenibilitat la tenim al post How to Write Unmaintainable Code o passar-se per The daily WTF. El primer cas és fins i tot més sagnant, ja que la gran majoria d'exemples i tècniques es refereixen a llenguatges fortament tipats com el C, C++ i Java. Usos creatius del define, noms de variables que no tenen res a veure amb el que fa la variable, noms lleugerament semblants que fan coses totalment distintes,...

No vull fer sang damunt el tipat fort, la majoria de les coses que expliquen al How to Write es poden extrapolar a qualsevol llenguatge de programació. Però la realitat és el tipat fort no és cap garantia de mantenibilitat.

La mantenibiliat ens la donen les convencions del codi, la documentació, la inspecció periòdica o sistemàtica del nostre codi (o del codi d'altres), el llegir el code complete i aplicar els consells i pràctiques també ajuda força. Tenir test unitaris, programes que ens gestionin l'adherència als estàndarts i la complexitat del codi (n'hi ha per Java, Python, C++, ...), gestió acurada del errors, tests de regressió, etc. a l'hora de la mantenibilitat poden fer molt més que el simple tipat.

Potser perquè molts de programes que he fet al llarg del temps s'han mantingut en producció durant anys sóc un tant fanàtic de la mantenibilitat, preferesc codi matenible a codi guais que al cap d'un mes ningú, ni el seu creador, sabrà perquè ho va fer d'aquella manera. I aquest tipus de mantenibilidad no la dóna el tipat fort o el compilador, la mantenibilitat ens la dóna la gent i les regles que ens imposem a l'hora de crear el codi.

Com la seguretat la mantenibilitat no és quelcom que es pugui posar una vegada el programa està llest. La mantenibilitat ha de formar part del procés de desenvolupament. Sovint he refet o he fet refer codi perquè era mal de seguir, per massa acoblament, perquè la quantitat de ifs feia difícil saber per on anava el codi, i això m'ha passat tant en Java, Pascal o FORTRAN com en Python.

Llavors, pensant en que els programes es fan per a ser mantenibles tant en llenguatges tipats com en els no tipats, la pregunta que ens faríem doncs és perquè triar un llenguatge o un altra i aquí ja entraríem en un altre tipus de discusió.

Si pensam sols en termes de mantenibilitat i suposant que programam com toca potser estarem d'acord que hauríem de triar un llenguatge que fos bo de llegir, de seguir, expressiu i d'alt nivell. El millor codi és aquell que no s'ha d'escriure. Per mi pocs llenguatges compleixen això tant bé com Python, és un llenguatge molt clar de llegir, amb una corba d'aprenentatge molt suau i amb una dèria cap a la llegibilitat i la mantenibilitat que està incorporada al llenguatge dins la pròpia sintaxi (la identació) i a l'intèrpret mateix (provau import this) o llegiu The Zend of Python i les convencions de codi són públiques i definides des del 2001, la qual cosa no vol dir que no s'hagin canviat al llarg del temps.

En conclusió: el codi mantenible no ho dóna un compilador sinó el programador i la gestió que se dugui del projecte. No podem confiar en que el tipat fort ens farà la feina i ens alliberarà de la feina de crear tests unitaris, de comprovar que el codi està d'acord als estàndards o de que fa el que ha de fer.

Java, C, C++ són grans llenguatges no perquè tenguin tipat fort, sinó pel que els programadors hem fet amb ells. De la mateixa manera Python, PHP, Perl, Ruby són grans llenguatges no per la seva absència de tipat, sinó per codi que ens permeten escriure.