En les darreres versions Python va introduir una modificació de sintaxi que permet no tirar tant de la programació funcional per algunes coses, el que es coneix com a list comprehension .

Encara que els exemples ajuden a fer-se una idea de com funciona la sintaxi, el que m'ha acabat d'obrir el ulls damunt la idea i la seva utilitat ha estat aquest article. En ell s'explica la sintaxi des del punt de vista matemàtic, és a dir, els matemàtics estan acostumats a escriure conjunts de la manera X = { x | x mod 2 = 0 } on x pertany als Naturals serveix per a indicar el conjunt dels nombres parells.

Els múltiples de tres, per exemple es poden escriure com

T = { 3x | x pertany als naturals}

Quan programam els nostres conjunts són finits, però la idea és la mateix i és ben bé la notació que es fa servir per la sintaxi de la list comprehension.

   parells = [2*x for x in range(0,10)]

Ens tornarà la llista dels deu primers nombres parells, o bé

   parells = [x for x in range(0,101) if x%2 ==0]

ens retornarà la llista dels nombres parells que hi ha entre zero i 100. Notació matemàtica en estat pur.

Si en lloc d'una variable en tenim dues, llegit en termes de conjunts matemàtics la notació té tot el sentit del món

parelles =[(x,y) for x in range(0,3) for y in range(0,5)]

Diu: conjunt de tots els parell on el primer nombre va de zero a tres (no inclòs) i el segon va de zero a cinc (no inclòs).

   [(0, 0), (0, 1), (0, 2), (0, 3), (0, 4), (1, 0), 
   (1, 1), (1, 2), (1, 3), (1, 4), (2, 0), (2, 1), 
   (2, 2), (2, 3), (2, 4)]

Si el que volem és el mateix conjunt però on els dos nombres no són iguals bastaria fer

parelles =[(x,y) for x in range(0,3) for y in range(0,5) if x != y]

és a dir:

[(0, 1), (0, 2), (0, 3), (0, 4), (1, 0), 
(1, 2), (1, 3), (1, 4), (2, 0), (2, 1), 
(2, 3), (2, 4)]

Normalment hom ha sentit parlar de les economies d'escala, per exemple, en la reducció del cost d'un producte gràcies a la seva producció en massa. O per exemple en la reducció de costs que tenen dues empreses que es fusionen gràcies a la reducció de personal que suposa unificar la gestió dels seus processos: dur els recursos humans de 1000 persones pot tenir un cost no molt major que dur-los de 800, i segurament serà menor que mantenir dos departaments per separat que gestionin 600 i 400 persones. El mateix podem aplicar a processos comptables, o a l'àmbit de la producció i les compres, on el volum implica una reducció del cost final.

També hem de tenir en compte, però, que existeix l'efecte contrari, el que s'anomena deseconomia d'escala ( diseconomy of scale en anglès). Aquest efecte se dona quan amb l'augment de volum no s'aconsegueix una reducció dels costs sinó que els costs augmenten.

En el món del programari els efectes de la deseconomia d'escala no s'han de menysprear, ja que tenim per una part els factors comuns gairebé a totes les empreses i projectes i per una altra amb els relacionats amb qüestions pròpies del desenvolupament. Així, que un projecte sigui 10 vegades més gran que un altre, no implica que costi 10 vegades més, entra en joc la deseconomia d'escala i ens podem trobar que doblem el cost, i quan major és el projecte major és la desviació que podem tenir. L'esforç no escala linealment amb la mida del projete, ho fa exponencialment.

Factors comuns

• Cost de la comunicació. Un equip gran necessita major comunicació que un petit (de fet l'equip òptim està entre 5 i set persones), necessita de més coordinació, de més reunions i això té un cost en temps i esforç.
• Cost de la jerarquia. Sense entrar en efectes tan perniciosos com el del principi de Peter, quan més jerarquitzada està l'organització més alts són els sous dels seus directius i això s'acaba reflexant en el cost global del projecte.
• Factors polítics. El projecte es fa no per una necessitat sinó per fer quedar bé algú, o s'inclou una determinada característica inútil sols per no discutir amb el cap de torn.
• Temps de resposta. Quan l'organització és petita és senzill trobar respostes. Quan més gran és l'organització més complexe és poder organitzar les agendes i el projecte es pot aturar perquè no es troba ningú disponible en capacitat de decisió.
• Inèrcia. Moure una organització gran costa temps i esforç. Tant és si es mou per fer un canvi estratègic com per fer un projecte amb una nova tecnologia de programació. Quan més gent hi ha, més probabilitat hi ha de trobar sectors reacis als canvis.
• Duplicitat d'esforços. En organitzacions grans les possibilitats de que un grup estigui fent el mateix que un altre, que dues persones estiguin fent coses semblants augmenta. Això està lligat a la comunicació o a la falta d'ella. Mantenir un alt grau de comunicació implica un cost molt alt i molt de temps i no mantenir-la duu a la duplicitat d'esforços.

En el que fa estrictament relacionat al desenvolupament, la deseconomia d'escala la podem trobar a:

• Tendència cap a la mitjana de l'equip. En un equip reduït podem tenir ratios de productivitat molt alts si els seus membres estan per damunt la mitjana. En projectes molt grans la necessitat d'incorporar personal és tan gran que no és pot seleccionar al millor del millor, sinó al que hi ha disponible. La diferència entre els nostres millors programadors i els pitjors pot estar en una relació 10:1.
• Augment de la complexitat del projecte. És habitual que quan major sigui el projecte més complexitat tingui. Encara que la taxa d'errors sigui lineal amb el nombre de línies de codi, la complexitat influeix negativament en la taxa d'errors que hi podem trobar.
• Dificultats en les estimacions. Les calibracions dels models d'estimació que podem tenir deixen de tenir validesa si el projecte és major que tres vegades el projecte més gran que haguem fet.
• Necessitat de més controls al codi. Quan l'equip augmenta no basta fixar unes regles d'estil i esperar que tothom les compleixi. Ens hem d'assegurar que es compleixen, i això implica invertir en programari i en gestió.

Conèixer aquests factors, tenir-los en compte, ens ajudarà a fer millors estimacions dels nostres projectes, i a pensar si podem organitzar-nos de tal manera que evitem els factors més perniciosos com poden ser el de la tendència a la mitjana i l'augment de la taxa d'errors.

Referències:

• http://en.wikipedia.org/wiki/Economies_of_scale
• http://en.wikipedia.org/wiki/Ideal_firm_size
• http://financial-dictionary.thefreedictionary.com/Diseconomy+of+Scale
• http://archive.adaic.com/docs/present/ajpo/pll-cost/html/tsld028.htm
• Software Measurement and Estimation: A Practical Approach. Laird & Brennan
• Software Estimation. Steve McConnell
• Peopleware. DeMarco & Lister

Hem d'anar a veure uns amics que tenen bessones i l'hi he explicat al meu fill petit, de quatre anys, la conversa va anar així:

• Anirem a veure uns amics que tenen filles bessones.

• Saps que vol dir bessones?

• Clar, que estan repetides!

Encara tenc la rialla a la boca per la contundència de la resposta.

Winpdb és un depurador en mode consola i gràfic per aplicacions Python.. Fa un parell de setmanes que han alliberat una nova versió. En la seva part gràfica, el programa presenta una interfície clara i permet la depuració remota de les aplicacions.

Es pot utilitzar per depurar scripts de Python molt fàcilment sols executant el programa passant-hi com a paràmetre l'script a depurar, tal com se fa amb el depurador estàndard de Python.

La vertadera potència, però està en la facilitat en que es poden depurar aplicacions remotes o aplicacions com les que es poden fer en Django per exemple. En a quest cas afegint aquesa línia al que vulguem depurar

import rpdb2 
rpdb2.start_embedded_debugger_interactive_password('clau de seguretat')

ens permetrà connectar-hi el depurador.

Winpdb fa temps que roda, però és la primera vegada que puc fer anar la depuració remota sense problemes. Una eina més a afegir a la capça de programació.

Avui he acabat el darrer capítol del llibre d'Steve McConnell. El llibre prometia i he de dir que no està malament. Recull els conceptes bàsics de l'estimació de projectes i dóna molta bibliografia i temes per a aprofundir en els conceptes en els que McConnell sols entra de passada.

El llibre, a l'estil dels millors de McConnell es bo de llegir, i en aquest pareix que ha evitat entrar en fórmules o la part més dura de l'estadística, com si li fes un poc de por l'adagi de que per a cada fórmula perdria un lector. Això li lleva un poc de profunditat al llibre, però les referències incloses al manco poden servir de guia al lector que vulgui aprofundir més en aquests temes.

El llibre toca tots els grans temes de l'estimació de projectes, però no entre en profunditat a tocar cap metodologia, ni punts funció, ni estimació per casos d'ús, ni Mark II o Cocomo 2, per exemple. El que sí entra és en distingir els distints tipus d'estimació: de tamany, de l'esforç i de temps, posant de rellevància la relació que hi ha entre ells (que no són ni molt manco lineals). Algunes de les idees i gràfiques que hi ha al llibre mereixeran una lectura més detallada i segurament un apunt, ja que tenen implicacions interessants, com per exemple la del tamany òptim d'un equip de desenvolupament.

També és bo saber quin es l'abast del llibre de McConnell. Els mètodes d'estimació que presenta no serveixen ni per projectes petits ni per projectes de mil·lions de línies de codi. L'aplicabilitat de les tècniques que es presenten està limitada a projectes en el rang que va entre les desenes de milers de líness de codi i els pocs centenars de milers de línies.

En definitiva, garebé de tres-centes planes de lectura entretinguda, amb dades amb les que reflexionar i treballar, però que s'ha de complementar amb altres llibres de l'autor i l'estudi en més profunditat d'alguna metodologia d'estimació, després de tot, com McConnell mateix recomana, no és bo sols limitar-se a una única estimació i en aquest cas a un sol autor.

Un dels darrers projectes en el que estic implicat és una web a mig camí entre d'imatge i d'utilitat, que ha de premetre a l'usuari que la visiti conèixer els productes que oferta una de les marques de l'empresa. Per les raons que siguin, la direcció va decidir que del desenvolupament de l'aplicació se n'encarregàs una empresa externa i encarregar-me a mi la gestió tècnica.

La cosa està en que els productes a mostrar s'han de carregar a una base de dades mitjançant un backoffice propietari de l'empresa encarregada del desenvolupament. Amb la qual cosa tenim que el desenvolupament final són dues aplicacions: el backoffice per carregar les dades de producte i la part de presentació que s'ha de nodrir d'aquests productes per fer la web.

Després de suar sang per posar el backoffice damunt un servidor Tomcat vaig començar a fer quatre proves amb ell. Els camps obligatoris no estaven indicats de cap manera, així que la cosa anava un poc per prova i error. En una d'aquelles vaig aconseguir completar la fitxa del producte (o això pensava jo) i donar-li a guardar. A la una, a les dues, i .... pam! pantalla amb missatge d'error de la BD, d'aquests de "not null constrain violated in field XXX_INFR" o una cosa semblant.

Oks, m'he deixat algun camp - vaig pensar-. El problema és que no sabria dir quin és. Si això me passa a mi, que estic més o manco acostumat a veure aquests tipus de missatges, quan ho vegi la persona o persones encarregades de introduir el producte, segur que això serà una font de problemes, ja que despistarà l'usuari i l'enlentirà en la seva tasca, a saber, introduir el producte el més ràpid que pugui.

Així doncs vaig cursar la petició formal de que s'indicassin els camps obligatoris amb la marca d'asterisc típica i que es controlessin els errors de validació de BD de manera que es presentàs a l'usuari final un missatge descriptiu.

La resposta va ser "el backoffice es sólo para usuarios avanzados" i que la petició estava fora de lloc.

No sé a quin món viu aquesta gent, però per mi aquesta contesta és el mateix que no voler admetre que el programa té errors, que no els pensen corregir i que ha de ser l'usuari el que assumeixi aquests errors i els eviti si pot. Un backoffice de càrrega de dades no pot ser mai per usuaris avançats, quan des del principi s'ha pensat que sigui personal no especialitzat qui carregui les dades.

No es pot fer recaure les pròpies errades damunt l'usuari, és prepotent i poc professional. Tot programa té errades, algunes són més fàcils de solucionar i altres menys. Sovint per manca de de temps i el sempre present "time to market" algunes errades queden allà de per vida, però s'ha de tenir present que hi són, posar-les damunt la taula i no culpabilitzar l'usuari de les mancances que té el nostre programa.

Markdown

Markdown és un llenguatge orientat a l'escriptura de documents de manera que siguin bons d'escriure i bons de llegir. Amb això comparteix la mateixa filosofia que altres com reStructuredText o Textile, és a dir, són llenguatges que permeten escriure la documentació de manera que sigui llegible directament en text pla.

Així com com reStructuredText és va força bé per escriure documents llargs i complexos, Markdown és ideal per al l'escriptura d'apunts als blogs, ja que a més del seu marcatge particular, permet incloure directament html si ho necessitam.

Mesclant markdown i HTML

Consideram dos tipus d'elements HTML a l'hora de incloure codi HTML dins el document markdown:

• elements de bloc: Per poder passar a escriure HTML dins el document markdown he de tenir en compte que el codi HTML ha d'estar separat de la resta del document markdown per un línia en blanc i l'HTML ha de començar a la primera columna, és a dir, sense espais ni tabuladors. Si feim servir l'HTML no podem fer servir la sintaxi markdown, és a dir, una vegada inicial el bloc html tot allò és html.
• elements en línia: Podem utilitzar l'html així com vulguem, per exemple, podem fer servir indistintament l'asterisc o <strong/> per marcar una paraula o frase en negreta. Són elements en línia <span>, <cite>, <a>, <img> etc.

Elements de bloc

Paràgrafs

Per a indicar un paràgraf simplement hem de deixar una o més línies en blanc. La conversió que fa markdown cap a HTML fa que es generin marques de paràgraf <p>. Si volem generar sals de línies amb <br/> haurem de fer acabar el nostre paràgraf amb dos o més espais en blanc i seguidament pitjar la tecla de salt de línia.

Capçaleres

Markdown pot fer servir dos estils de capçaleres:

 Capçalera tipus H1
 ==================

 Capçalera tipus H2
 -------------------
  

o bé fer servir # per a indicar el nivell de la capçalera que volem fer servir, així:

    
    # Això és un H1
    ## Això és un H2
    ### Això és un H3
    ###### Això és un H6

encara que no és estrictament necessari podem fer acabar la capçalera també amb el mateix símbol. Per exemple:

    
# Capçalera H1 estèticament millor #

Citacions

Markdown permet citar text fent servir el símbol > davant cada línia que vulguem que figuri com a citada o davant el paràgraf. Així:

    
> això és una cita literal d'un text

queda com

això és una cita literal d'un text

Llistes

Podem fer servir llistes ordenades i no ordenades. Les perimeres es fan posant un nombre seguit d'un punt, i les segones amb un asterisc, guió o símbol de suma.

Per exemple:

Llista no ordenada

* Joan
* Pere
* Miquel

Llista ordenada

1. Joan
2. Pere
3. Miquel
  

No és necessari mantenir l'ordre de la nuemració en un llista ordenada, basta que hi hagi un nombre seguit d'un punt, a partir d'aquí Markdown ja ho generarà com toca.

Si els elements de la llista estan separats per una línia en blanc, markdown generarà tags de paràgraf al voltant dels elements de la llista. Si l'element està composat per dos o més paràgraf hem de tenir en compte que cada paràgraf de la llista ha d'estar identat al manco per 4 espais o un tabulador. Per posar codi dins una llista l'hem d'identar al manco 8 espais o 2 tabuladors.

Si per la raó que sigui no volem que s'inicii la numeració d'una llista, haurem d'escapar el punt amb la barra invertida .

Blocs de codi

Els bloc de codi van molt bé quan un ha de parlar damunt programació o té necessitat de posar un llistat de codi dins el text. Markdown genera el tag <code> si identam cada línia que formi part del codi amb un tabulador o quatre espais.

El bloc de codi continuarà fins a trobar un bloc que no estigui identat o fins al final de paràgraf.

Dins un bloc de codi els (&) i (< >) són gestionats automàticament pel makdown i convertits de manera que es pugui representar fàcilment codi HTML. Per a facilitar que es pugui escriure de markdown la sintaxis markdown no es processada dins un bloc de codi, la qual cosa, per exemple permet escriure aquest article.

Línia horitzontal

Generar una línia horitzontal <hr /> és tan senzill com posar asteriscs o guionets al començament de la línia i que no hi hagi res mes. Queda molt bé indicar visualment que es tracta d'una línia horitzontal decorant-ho un poc més. Per exemple:

queda molt més clar que si sol feim

*

Tot i això el resultat el mateix:

---

Elements en línia

Enllaços.

Per posar un enllaç la sintaxi és

    
[nom que ha d'aparèixer](url "text del títol")

per exemple:

    
[trespams](http://trespams.com "blog de trespams")

genera el codi

    
<a href="http://trespams.com" title="blog de trespams">trespams</a>

Si hem d'enllaçar recursos locals dins el mateix servidor, podem fer servir camins relatius, per exemple:

[mira Sobre mi](/about/ "sobre mi") per més detalls

Podem enllaçar també per referència i fer servir dreceres per escriure el link quan en nom i l'enllaç coincideixen:

     

   Tenc 10 vegades més tràfic des de [Google][] que des de
       [Yahoo][1] o [MSN][2].

[Google]:http://google.com  "El cercador Google"
[1]:http://search.yahoo.com/  "Cerca a Yahoo"
[2]:http://search.msn.com/
  

En el primer cas com que l'enllaç i el nom coincideixen ens bastaria posar el nom, en el segon cas feim la referència i també posam el títol i en el tercer cas hem fet la referència però no posam el títol. Això genera:

Tenc 10 vegades més tràfic des de Google que des de Yahoo o MSN.

La idea de les referències no és que siguin més fàcils d'escriure sinó que es fan per augmentar la llegibilitat del codi, ja que es veu que hi ha un enllaç però aquest no posa renou dins el codi.

Èmfasi

Per posar negretes o cursives feim servir el doble asterisc o l'asterisc simple respectivament. També podem fer servir el guionet de subrajat, doble en el primer cas i simple en el segon.

    
**Això va en negreta** i això _italic_

Això va en negreta i això italic

Si volem posa un asterisc * o un guionet de subrajat _ ho haurem de fer escapant els caràcters, així * i _.

Codi

Per indicar que estam escrivint codi, però que aquest s'ha de tractar com a un element de línia farem servir l'accent greu `, per exemple:

    
exemple de funció lambda `lambda x,y: x+y` 
en [Python](http://python.org "Python site")

exemple de funció lambda lambda x,y: x+y en Python

Imatges

Per a incloure una imatge la sintaxi és

    ![Text Alt](url "títol opcional")

De la mateixa manera que amb els enllaços, podem indicar les imatges per referència de manera que la sintaxi queda com:

    ![Text Alt][referència]
    [referència]: url/a/la/imatge  "títol opcional"

Altres

• Markdown ens permet dreceres per a la generació d'enllaços. Simplement hem d'escriure el nom de l'enllaç i envoltar-ho de < >. Per exemple l'enllaç http://trespams.com, s'ha generat com

  <http://trespams.com>
  

• Per escriure adreces d'e-mail també ho podem fer d'auesta manera, però en aquest cas markdown fa una conversió intel·ligent per mirar de fotre els spammers, convertir cada caràcter de l'adreça al seu equivalent hexadecimal.
• Per a escapar un caràcter amb significat especial a markdown ho podem fer precedint-ho de </li>

Agraïments

Aquest document és una traducció lliure al català del document original en anglès escrit per John Gruber. Ha estat escrit amb l'editor Kate de KDE com a part de la documentació en català de que esper que sigui aviat el meu nou programari per a la gestió del blog de trespams. Podeu trobar el document original en format markdown dins el subversion del projecte.