Alfresco Community Conference

Escrit per Aaloy a 25 de April , 2008 a les 9:37 p.m.

El dia 22 d'aquest mes vàrem assistir a l'Event d'Alfresco Community Conference a Barcelona. Per a qui no ho conegui Alfresco és un DMS (Document Management System) lliure que ha agafat molta volada darrerament, encara que és un producte molt jove.

Per anar-hi agafàrem un vol molt prest, no eren encara les set del matí, i això vol dir aixecar-se a les cinc del matí. En favor de la gent d'Alfresco he de dir que les conferències varen ser prou interessants com per a mantenir-me despert, encara que no puc prometre que se m'escapàs el cap alguna que altra vegada.

A nivell organitzatiu les conferències varen estar molt bé: la sala molt ben preparada, amb traducció simultània fins i tot i la intendència (la teca) prou bona. Sols em va quedar el dubte de perquè un recinte amb capacitat amb tanta gent té uns excusats com els que té. Mai havia anat a un lloc on els tios fessin coa per anar al bany.

Punts anecdòtics a part, he de dir que vaig sortir força content de les conferències. Vàrem veure cap a on apunten les novetats d'Alfresco i de pas també es pogué veure cap a on desenvolupa la gent. Els d'Alfresco estan deixant els JSF, segons ells fan que les aplicacions siguin molt males de mantenir, i vàrem poder veure dues aplicacions, una feta per un desenvolupador independent i una altra oficial d'Alfresco, que tenien una cosa en comú: estar desenvolupades amb Extjs. Els d'Alfresco han fent una aposta molt forta per la comunicació de l'aplicació amb json, xml, rest, webdav, etc i segons vàrem poder veure han fet que sigui força fàcil poder publicar la informació en aquests formats.

Potser sigui autoconvenciment, però la cosa és que el tema del JSF no m'ha acabat de convèncer mai. Massa enrevessat i mal de mantenir, però és el que empreses com Oracle estan recomanant per fer el canvi tecnològic de Forms cap a la web, l'excusa és que hi ha dissenyadors visuals per JSF, però em fa por que amb l'excusa de la productivitat a l'hora de pintar pantalles s'estigui optant per una tecnologia que aviat quedarà obsoleta. La gent té tendència a anar cap a coses que agumenten la productivitat, deixen fer coses i els faciliten la vida, d'aquí que bastiments com Spring i Hibernate triomfin on els EJB varen fracassar.

La gent d'Alfresco pareix que ho veu clar i que s'estima més retirar-se ara i apostar cap a una altra tecnologia més mantenible per la capa de presentació. Potser va ser una de les millors conclusions que en vaig poder treure de la conferència.

0 comentaris, 0 trackbacks (URL) , Tags: Informàtica Java


Bons temps per Python

Escrit per Aaloy a 09 de April , 2008 a les 12:03 a.m.

La blogosfera en va plena Google ha llançat el seu appengine , un servei que permet hostejar aplicacions de fins a 500 Mb d'espai i 5 milions de visites mensuals que Google ha llançat i que té com a llenguatge vehicular el Python.

Per a accedir-hi un s'ha d'apuntar a la llista d'espera, ja que pareix que els comptes en fase beta s'han esgotat, i tot i les limitacions del sistema en el que fa referència als accessos als sistemes de fitxers, limitacions de la part de base de dades, que no es puguin llançar subprocessos i coses per l'estil, obre la possibilitat a tot un ventall d'aplicacions web.

On la notícia ha impactat més és a la comunitat Python: un llançament espectacular de Google, amb Guido pel mig, am Python com a protagonista i amb Django com a estrella convidada, ja que Django, encara que la versió "estable", ve de sèrie en el sistema.

Si encara no ho heu fet és un bon moment per aprendre Python i Django (ueps, tal volta seria un bon moment per publicitar-ne cursos :-P ) ja que un dels emperòs més grans que hi havia és que no se disposava d'un servidor a preus assequibles on poder fer anar les aplicacions. Ara amb el llançament de Google, les possibilitats de fer desenvolupaments amb Python i Django es multipliquen, limitats a les possibilitats de l'entorn que proporciona Google, sí, però permetran en breu començar a fer aplicacions web i hostetjar-les a un preu inmillorable.

Amb això esper a més que els hostingaires de sempre es posin les piles i donin a preus raonables allotjament per Django, proporcionant a més el servei que ara Google no ofereix: el de tenir una base de dades relacional pròpia al darrera.

I és que un dels grans problemes de l'oferta de Google és que no ets ben bé l'amo de la teva base de dades i algunes coses que permet fer l'ORM de Django molt fàcilment a l'ORM substitutiu de Google no es poden fer.

És clar que no totes les aplicacions necessiten d'una base de dades relacional al darrera, així que l'appengine de Google és per una part un bon banc de proves per veure com va això de la programació web amb Python i Django i per una altra una manera ràpida i econòmica de posar en producció projectes web que d'altra manera tendrien un cost prohibitiu pel programador mig.

2 comentaris, 3 trackbacks (URL) , Tags: Informàtica Python Django


Propietats a Python

Escrit per Aaloy a 21 de March , 2008 a les 1:41 p.m.

En Corey Goldberg al seu blog a un recull interessant d'enllaços de lectura obligada per aquella gent que està fent la transició de Java o C# cap a Python.

Un dels més interessant és l'article de Phillip J. Eby anomenat Python is not Java on recull les diferències fonamentals que hi ha entre programar en Java o programar en Python. Una de les afirmacions més xocants és potser aquesta: Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters, és a dir "Els getter i setters són el dimoni. El Dimoni, dic. Els objects de Python no són Java beans. No escriguis getters i setters."

La frase pot semblar molt bèstia, i de fet ho és, ja que és una afirmació que s'ha de matitzar molt, com de fet ho fa en Ryan Tomayko al l'apunt Getters/Setters/Fuxors on s'explica molt bé quan fer servir aquest tipus de construccions, però en definitiva el que ens hem de quedar és amb la idea de que normalment Python no necessita mètodes accessors i que l'ús normal d'aquest és el de marcar un atribut com de sols lectura.

Com sempre hi ha "la manera de Python" de fer les coses, i sol ser la manera més senzilla de fer-les.

1 comentari, 0 trackbacks (URL) , Tags: Informàtica Python


Integració de Hudson i Trac

Escrit per Aaloy a 15 de March , 2008 a les 11:52 a.m.

A un altre post ja vaig parlar de Hudson, un sistema d'integració contínua, relativament nou però que permet fer el que un necessita d'aquestes característiques de manera fàcil i amb una interfície molt cuidada.

Hudson es pot integrar amb Trac, de manera que al Timeline del projecte trac poguem veure com han anat les integracions sense tenir que anar al Hudson. D'aquesta manera la gent que fa el seguiment del projecte pot veure a més dels commits al subversions, modificacions al wiki i tickets, com han anat les integracions i quan s'han fet.

La integració dels dos aplicatius és força senzilla:

  • Instal·lam el python-feedparser si no ho tenim ja al nostre servidor.
  • Anam a http://trac-hacks.org/wiki/HudsonTracPlugin i descarregam el plugin.
  • Descomprimim el plugin i amb permisos d'administrador executam python setup.py install això ens crearà el paquet egg i configurarà el plugin a nivell global dins el trac.
  • Editam l'arxiu trac.ini del nostre projecte trac que volguem enllaçar amb Hudson i modificam la llista de components, en el meu cas la cosa queda com
[components]
iniadmin.iniadmin.iniadminplugin = enabled
webadmin.* = enabled
HudsonTrac.* = enabled
  • Cream també una entra a anomenada hudson allà on posarem tant la url del rss del nombre projecte hudson que volguem controlar com el de la vista del projecte, de tal manera que s'hi crei un enllaç dins Trac
[hudson] display_subprojects = false feed_url = http://servidorhudson/hudson/view/Java/rssAll main_page = http://servidorhudson/hudson/view/Java/
  • Canvia el servidorhudson pel vostre servidor. Aquí el que he fet és enllaçar directament contra la vista de projectes anomenada Java que he creat. Podria enllaçar a un projecte concret o a una vista relacionada amb el projecte que es gestiona amb el Trac.

Si s'han seguit aquestes passes i una vegada refrescada la plana del Trac, ens apareixerà una nova secció anomenada Hudson a la part de navegació del Trac que enllaça a la url que hem posat a main_page i al timeline apareixerà una opció que ens permetrà visualitzar les integracions, en forma de control check.

Pels que feu servir Trac de manera habitual, és interessant instal·lar-se també el plugin IniAdminPlugin, que ens crea un menú de configuració per web del trac.ini del nostre projecte.

És interessant a tot això adonar-se de que gràcies als formats oberts, en aquest cas al RSS que publica Hudson i que pot consumir Trac, dues aplicacions fetes en tecnologies totalment diferents es poden integrar.

Al Hudson passa una cosa semblant, està pensat per tractar amb format oberts, típicament sortides XML en format UnitTest, la qual cosa permet afegir-hi projectetes de Python, Java o SoapUI.

2 comentaris, 0 trackbacks (URL) , Tags: Informàtica Python Java


Tancar una web

Escrit per Aaloy a 01 de March , 2008 a les 11:19 a.m.

Aquesta setmana estic un poc tristot. El dijous vàrem tancar definitivament la web B2C posant el banner final de tancament i redirigint les planes que hi apuntaven cap a una marca blanca.

El dijous mateix ens va dir adeu la persona responsable del B2C, professional com n'hi ha poques i una de les persones que més coneixen el món de la venda on line en el seu sector.

Està clar que tot evoluciona i que els negocis no són per sempre, però aquest cas em sap un greu especial ja que hi tenia una forta implicació emocional en el projecte, per haver-hi estar estat en els seus començaments més llunyans i per l'amistat que m'uneix amb la que fins ara era la seva responsable i amb gran part del seu equip. Em sap greu pel tancament, per la gent que hi havia fent feina, però sobretot me sap greu perquè crec que el projecte mai no va tenir cap oportunitat.

No ha estat una sorpresa, sols era qüestió de temps, la web ha estat víctima de l'estratègia del powerpoint que tan habitual s'ha fet en algunes empreses.

Abans deien que el paper tot ho aguanta, ara podríem canviar paper per powerpoint. Pareix que si un objectiu es posa a una presentació aquest ja ha de ser factible i ja no importa justificar res més.

Quan les presentacions es converteixen no en una manera de resumir dades, sinó en les dades mateixes podem estar segurs que s'està seguint el mètode de direcció d'empreses powerpoint. Abans de tot això se'n deia fum i miralls i ningú s'ho creia; ara pareix que si li posam un envolcall tecnològic i feim unes presentacions ben xul·les i colorides perdem la perspectiva de que és possible i del que no.

Potser algun dia tothom se n'adoni que no per estar en una presentació el que hi ha és realitat, de que les presentacions sols han de servir per resumir, però que quan es tracta de dades sempre hi ha d'haver un suport darrera, i quan es tracta de negocis a més hi ha d'haver el pla de negoci i una estratègia. Llavors potser no no ens deixarem seduir per les transicions, els efectes i els colorins de les presentacions sinó que tocarem de peus a terra i serem capaços de demanar d'on surten les dades que sustenten la presentació.

1 comentari, 0 trackbacks (URL) , Tags: Informàtica


Programa trinxera

Escrit per Aaloy a 02 de February , 2008 a les 1:45 a.m.

Els anglosaxons són molt bons inventant nous termes per a fer referència a situacions típiques i expressar en poques paraules un concepte. En el món de la programació i projectes un dels que més m'agrada és de "pizza team", que descriu un equip de projecte d'un tamany adequat com per poder demanar una pizza quan hi ha hores extres a fer i no quedar amb gana.

No per això hem de deixar, però, que en tenguin l'exclusiva dels neologismes, així que aquí va la meva contribució: el programa trinxera.

El programa trinxera descriu aquell programa darrera del qual s'amaga un equip o una organització per tal d'impedir l'avanç de l'enemic. Qui és l'enemic és del tot irrellevant, potser una part de l'organització, un client, o els simples avanços tecnològics.

El programa trinxera es caracteritza per estar totalment acoblat, per la dificultat de saber per a un observador extern què fa el codi o perquè el programa fa el que fa. El programa és tan complexa que es requereix moltes vegades més feina saber el que fa que refer el codi de nou.

Per a que un programa trinxera sigui de qualitat a més ha de tenir moltes ramificacions, ha de ser un programa que faci de tot, que tant servesqui per gestionar l'empresa com per a enviar SMS. Cada necessitat que plantegi el client s'ha d'acabar lligant d'alguna manera amb el programa, d'una manera íntima i indissoluble, de tal manera que sigui impossible saber on comença un modul i on acaba un altre.

El programa trinxera es un gran devorador de recursos. Per la seva pròpia definició ha de ser totalment monolític i per a cada mòdul que se l'incorpora requerir més i més màquina. Com a bona trinxera ha de ser tortuós i amb molts llocs on amagar-se, de tal manera que si algun dia l'enemic es capaç d'entrar a la trinxera, se'l pugui estar esperant al proper racó per donar-li una sorpresa en forma de milers de línies de codi embullat i ineficient.

Per acabar de ser perfecte, el programa trinxera ha d'estar fet amb algun llenguatge obsolet, a ser possible mal de depurar i testejar, del qual sols els atrinxerats en saben algunes coses, no moltes, sols les justes per anar fent modificacions, però no les suficients com per a poder arribar mai a desfer el que s'ha creat.

1 comentari, 0 trackbacks (URL) , Tags: Informàtica Conyes marineres


Ajà! List comprehension explained

Escrit per Aaloy a 31 de January , 2008 a les 8:47 p.m.

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)]

2 comentaris, 0 trackbacks (URL) , Tags: Informàtica


Deseconomia d’escala

Escrit per Aaloy a 30 de January , 2008 a les 10:13 p.m.

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

0 comentaris, 0 trackbacks (URL) , Tags: Informàtica General


Lògica

Escrit per Aaloy a 27 de January , 2008 a les 1:26 p.m.

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.

1 comentari, 0 trackbacks (URL) , Tags: Informàtica


Sotfware Estimation, d’Steve McConnell

Escrit per Aaloy a 21 de January , 2008 a les 11:22 p.m.

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.

2 comentaris, 0 trackbacks (URL) , Tags: Informàtica Llibres i revistes


“Sólo para usuarios avanzados”

Escrit per Aaloy a 20 de January , 2008 a les 12:25 p.m.

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.

0 comentaris, 0 trackbacks (URL) , Tags: Informàtica


Markdown

Escrit per Aaloy a 02 de January , 2008 a les 5:35 p.m.

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.

0 comentaris, 0 trackbacks (URL) , Tags: Informàtica


Propòsits pel 2008

Escrit per Aaloy a 23 de December , 2007 a les 6:03 p.m.

El 2007 ja fa les darreres i és temps de recapitulació i de pensar en quins són o poden ser els objectius pel 2008. La llista de propòsits convé que no sigui massa llarga, ja diuen que qui molt abraça poc estreny, però sí que convé que sigui ambiciosa, que motivi a fer coses.

Per mi el 2007 ha estat potser un any que podríem classificar de transició, han passat moltes coses i una de les més importants, que afecta a l'estabilitat laboral tindrà continuïtat dins el 2008 (esper!), dins l'àmbit tècnic el 2007 ens va permetre definir com seria l'arquitectura que volem utilitzar, i que també esperam que exploti dins el 2008. Supòs que per més d'un també ho haurà estat de transició, no oblidem que el 2007 ha estat any electoral i al Govern de les Illes i a molts d'ajuntaments s'ha canviat de color polític.

A la feina aquest 2007 ha estat mogudet, bàssicament per dos motius importants:

  • Canvi de director financer. Encara que sóc una persona prou oberta als canvis aquest no ho vaig acabar d'entendre. Potser tenc massa implicació personal a l'assumpte, ja que a l'anterior director el coneixia des de feia temps i el tenc per una de les persones més íntegres, treballadores i amb una visió de les coses molt clara que conec. Els anys que he estat treballant amb ell n'he après molt, moltíssim, de com gestionar, de cultivar un esperit crític, de com es pot discrepar, discutir solucions i arribar a enteses... La relació d'amistat segueix i seguirà, però enyor la seva manera de fer les coses.
  • Fusió amb First Choice. Segurament és una de les coses que més ha condicionat la feina dels darrers mesos. Pareix que entre els empleats de les dues bandes hi ha poca informació damunt el que pot passar i de les implicacions que això pot tenir a curt plaç. Com he dit abans el 2007 és de transició, sobretot perquè la gent està a l'espera de que les coses es defineixin al 2008.

A la part tècnica el 2007 ha suposat la consolidació de la feina amb Python i Django, consolidació que ha donat fruits dins el 2007 en forma de webs per l'empresa i fetes particularment i que esper que en doni molts més dins el 2008. Django ara per ara ja té gairebé tot el que necessit per fer el tipus d'aplicacions web que m'agraden. També el 2007 ha estat l'any del llançament de dos RIAs importants: Extjs 2.0 i Dojo. Encara que hi havia versions anteriors, la versió d'Extjs suposa poder fer aplicacions web on la part de presentació està gestionada per javascript. La combinació d'Extjs i Django és molt bona. Al 2007 hem començat a gratar a les possibilitats que té aquesta combinació, i esper que puguem veure aplicacions web realment espectaculars dins el 2008.

Pel 2008 tenc dos projectes que m'agradaria que prenguessin tota l'embranzida per fer-los una realitat: apsl i el nou blog de trespams.

apsl és un grup de desenvolupament web. Al 2007 hem començat a definir-ho i crear-ne la infraestructura, a poc a poc segons el temps i la feina ho deixaven fer. Parteix de la idea que el desenvolupament web actual i futur no és sols cosa del dissenyador o programador solitari, sinó que es necessita ja tot un conjunt de gent que treballi junta per aconseguir webs i aplicacions webs que sigui accessibles tant a les persones com als cercadors, sense oblidar que tot això necessita tota una estructura d'entorns de desenvolupament i producció que no se pot deixar de banda. I també en la idea de que els projectes, com passa en el programari lliure, poden avançar sense tenir que tenir a la gent fermada a una oficina, que el teletreball, amb petites dosis de presencialitat, serveix ben igual per dur a terme projectes i que aquest són tant o més controlables que si tens la gent a una oficina.

El nom pot ser tant "agrupació de programadors en software lliure", "advanced programming solutions on linux" o senzillament pensar que és un domini de quatre lletres, bo de recordar i de dir, que és fonamentalment com va sortir :) apsl vol servir també de marca paraigua, de manera que es pugui donar suport logístic i administratius a desenvolupadors, dissenyadors i tècnics que d'altra manera es poden trobar sols i sobrecarregats de feina que no els agrada. Moltes vegades he sentit parlar a companys de que feina mesos que havien d'haver presentat una factura a un client, de que no tenen temps de fer un pressupost, etc. És a dir, proporcionant la capa d'abstracció de la que parla Joel i al mateix temps no condicionar la llibertat que dona poder triar ells projectes en els que fas feina.

Al 2007 ens hem concentrat en crear l'estructura tècnica i legal necessària per donar suport a la idea: s'ha creat la web, s'ha definit el logo i la papereria necessària, s'han posat en marxa i configurat els servidors amb els serveis necessàris: apache, django, python, php, subversion, trac, correu, ldap, etc. etc. etc. mirant que tot pugui escalar fins allà on volguem i puguem. Al 2007 s'ha registrat la marca i el logo i iniciats els altres tràmits burocràtics. El tema de la marca era fonamental, ja que es vol basar tot el model de negoci en Internet, i la marca ha de ser un dels principals actius, i a la vegada és un dels temes més complexes, ja que el registre duu força temps, des de fa unes poques setmanes la marca ha estat definitivament reconeguda i concedida, així que el projecte té al manco les bases necessàries per començar.

Al 2008 m'agradaria poder consolidar el projecte: trobar prou finançament pel projecte que el permeti créixer, donar-lo a conèixer al teixit empresarial i començar a captar projectes importants que puguin determinar-ne la viabilitat. Els fonaments estan posats, crec que la idea és bona i necessària, el model de negoci pot funcionar i ara sols es cosa de poder dedicar-hi més temps per anar creant-ne l'estructura.

Del nou blog de trespams dir que la idea és substituir el Wordpress per un basat en Blogmaker, o el que és el mateix en Python i Django. Wordpress està molt bé, pero vull quelcom més, alguna cosa de la qual en pugui controlar les butzes i fer afegitons així com jo vulgui. Segurament amb Wordpress es pot fer, però vull que el blog es convertesqui també en un projecte mascota i per això n'he de poder controlar totalment el codi i el contingut.

En aquests moments la cosa ja està molt avançada, he creat un projecte a Google anomenat trespams, de manera que si algú vol mirar el codi, o fins i tot afegir-se al projecte ho podrà fer. Està completament basat en Blogmaker per ara, però l'he anat modificant per a que sigui l'aplicació en lloc d'un afegitó d'una web, adaptant-ho a la branca de desenvolupament de subversion de Django i modificant plantilles i codi relatius a la internacionalització. La idea és anar incorporant les correccions d'errors i codi no estrictament lligat a trespams a Blogmaker, però sense sacrificar la llibertat que em doni poder mantenir la meva versió del codi.

La conversió d'articles ja està acabada, els permalinks de Wordpress, comentaris i tracbacks es mantenen prou be. Les categories són un petit problema, però les he substituït per tags i la cosa pareix que funciona. Encara queda molta cosa a fer, però esper que al manco la part principal del blog pugui estar llesta a finals de gener del 2008, i a partir d'aquí anar publicant ja els pots directament contra el nou sistema.

Dos objectius ambiciosos, cada un en la seva pròpia mesura, un més social i econòmic, l'altra més tècnic i personal però amb la mateixa característica, el desig de que ambdós projectes puguin tenir èxit dins el 2008.

7 comentaris, 0 trackbacks (URL) , Tags: Informàtica General


Un 14!

Escrit per Aaloy a 15 de December , 2007 a les 7:43 p.m.

No, no he tret una travessa de futbol, tampoc hi jug, així que seria un poc difícil, però l'alegria de veure un 14 no sé si serà comparable.

La cosa va anar així: se'n va demanar fer un resum que comportava fer una consulta d'agrupació a la base de dades més gran que tenim en Postgres, ja n'he parlat altres vegades.

Era una consulta damunt camps no indexats, així que ja vaig suposar que torbaria un poc, després de tot la darrera vegada que la vaig consultar una de les taules implicades tenia gairebé un mil·lió de registres.

La consulta va tornar uns quants centenars de resultats i torbà uns 50 segons en tornar la resposta. Vaig fer una consulta semblant damunt una de les altres taules i torbà un poc més, gairebé minut i mig, també lògic, ja que en aquest darrer cas la quantitat d'agrupacions a fer era molt més grossa i tampoc no tenia cap índex llevat del de la clau primària.

Content amb la resposta ho vaig contar als companys, i vaig fer un count(*) damunt la taula, un 1 i un 4, és a dir un mi·lió quatre-cents mil registres i la base de dades se les havia menjat com si res.

L'altra taula, la més lenta en tenia un parell més, gairebé dos mil·lions, però, un moment, va dir un dels companys, la primera taula hauría de tenir més registres que la segona.

I efectivament, és veritat, la ment a vegades veu el que vol veure, i allà on jo vaig veure un mil·lió quatrecents-mil registres i havia catorze mi·lions i busques de registres.

La base de dades va tan bé i dona tans poc problemes que no hem reparat cap pèrdua de rendiment i la màquina que la duu habitualment està al voltat del 0% de càrrega.

Postgres: capacitat per manejar grans volums d'informació? sí Problemes? zero Caigudes? zero Manteniment? zero.

No sabeu la tranquilitat que et dona una base de dades així.

5 comentaris, 0 trackbacks (URL) , Tags: Informàtica


On són els programadors?

Escrit per Aaloy a 02 de December , 2007 a les 2:51 p.m.

L'altra dia a un dels fòrums on hi estic subscrit un dels participants em va demanar de publicar una oferta de feina per a un lloc de programació en Java/J2EE. L'oferta era per un lloc de feina a Sevilla i a més de l'experiència en programació J2EE el candidat tendria

"como responsabilidad el análisis y diseño orientado a objetos, patrones de diseño, modelado de bases de datos, integración de aplicaciones, gestión de rendimiento y profiling de aplicaciones, así como de calidad de procesos de desarrollo."

Després de la publicació de l'oferta de feina i després d'un parell de dies, aquesta persona es posà en contacte novament amb mi per dir-me que del més de mig centenar de persones subscrites al grup sols una havia demostrat interès per l'oferta de feina.

Aquest tipus d'històries és bastant habitual pel que es veu entre la gent que es dedica a la selecció de personal. Posen una oferta que consideren atractiva i després s'estranyen del poc interès que ha despertat l'oferta, del molt que costa trobar gent tècnica. Anem a pams:

Les ofertes destinades per a personal tècnic han de ser concretes. No sé perquè però sovint m'he trobat que la gent té por a presentar-se a una oferta de feina perquè no compleix un dens n-mil requisits que hi solen haver. A vegades les ofertes de feina pareixen cartes al reis d'un nin de vuit anys, s'hi posa de tot, sense prioritzar i sense cap tipus de criteri.

Si estam cercant un programador J2EE doncs convé que ens centrem en que conegui la tecnologia, en l'experiència (2 - 3 anys basta, més tampoc no garanteix res i eliminam candidats). Si consideram que és imprescindible també hi posarem els bastiments amb els quals feim feina a l'empresa i després com un "seria bo que ..." la resta. Per exemple, si cercàs un programador J2EE per fer feina amb el nostre grup demanaria experiència amb programació J2EE damunt Tomcat i coneixements d'Spring. Com a punts addicionals coneixements d'Hibernate, Acegi, Axis o XFire, haver treballat amb un control de versions y coneixements de Linux i Python. Però el focus principal estaria en el bessó del que s'està cercant. Després una vegada reunits els currículums ja se'ls podrà fer l'enquesta.

El segon punt important és indicar sou i horari. Darrerament estic veient que poques empreses posen el rang salarial que estan disposats a pagar. Això també frena als possibles candidats que ja estan col·locats a un altre lloc. Tenir que anar a una entrevista o actualitzar el currículum sabent que hi ha força possibilitats que el lloc de feina estigui més mal pagat que el que se té actualment no és motivant. Si la feina pareix interessant i a més el rang salarial està un poc per damunt que el que se cobra, doncs hi ha moltes més possibilitats de poder captar candidats que estiguin fent feina, i quan es cerquen candidats amb molta experiència aquests s'han de captar d'altres llocs.

El tema de l'horari també és important. Res motiva més que una oferta que digui "horari flexible", "possibilitat de teletreball" o que els divendres s'acaba al migdia. En un mercat on els rangs salarials són baixos i semblants a totes les empreses, el factor que pot diferenciar la captació d'un candidat o no són els beneficis addicionals que pugui aportar l'empresa. A igualtat de sou i hores, una empresa que faci jornada contínua segur que és molt més atractiva que una amb jornada partida.

La solvència de l'empresa també és un dels altres factors a tenir en compte. Si en lloc del típic "importante empresa de ámbito nacional" es pot dir el nom de l'empresa i aquesta té presència a Internet serà molt més atractiva pel possible candidat. De rebot podríem entrar aquí en l'apunt d'Enrique Dans, en el sentit que un blog corporatiu ajuda als candidats a fer-se una idea de l'atractiva (o no) que és l'empresa. No estic d'acord amb que un directiu pel fet de ser-ho tengui que tenir un blog, però sí que com a empresa es bo tenir un blog corporatiu un es pugui veure el rum-rum de l'empresa i la seva filosofia. En Joel Spolski pareix que ho té molt clar això: després de llegir els seus apunts a un li fan ganes de fer feina per ell.

En el cas de l'oferta d'aquest conegut no es deia ni el nom de l'empresa i a més l'adreça de contacte del seleccionador era una adreça de gmail. Bé, podria haver estat pijor i l'adreça ser de hotmail, però sigui com sigui són punts en contra de l'oferta i que no motiven a perdre unes hores actualitzant el currículum i a enviar-lo.

Per acabar un dels punts que al manco jo tenc en compte a l'hora de valorar una oferta és on és el lloc de feina. Que el lloc de feina sigui al centre de la ciutat on no es pot aparcar, o que estigui mal comunicat i tengui que perdre molt de temps en arribar-hi resten punts a una oferta. No serveix de res que una empresa pagui més si tanmateix després ho perdràs o en temps (o el que és el mateix en qualitat de vida) o en benzina, més l'emprenyo matinal de tenir que cercar aparcament. No diguem res si l'oferta, per molt interessant que sigui és a una altra ciutat.

L'empresari/cap típic està massa acostumat a valorar la feina, no per rendiment o projecte, sinó per presencialitat. És allò de que ja que no puc controlar la teva ànima controlaré el teu cos... Això implica que els candidats per molt bons que siguin estaran limitats als del propi entorn geogràfic o bé als que estiguin disposats a traslladar-se a viure a una altre lloc, i el treball que això representa sovint no compensa l'esforç.

És mal de fer trobar programadors? No ho crec, el que és mal de fer és trobar bones ofertes de feina.

0 comentaris, 0 trackbacks (URL) , Tags: Informàtica


The Computer Language Benchmarks Game

Escrit per Aaloy a 15 de November , 2007 a les 12:13 p.m.

El llenguatge x és millor!.Quantes vegades no haurem sentit aquesta frase defensant un o altre llenguatge de programació. Tots tenim les nostres preferències, condicionades per la nostra història, coneixements i manera de pensar. Podríem dir que hi ha un llenguatge de programació especial per a cada programador, aquell en que se sent més còmode tant perquè el coneix com perquè s'adapta a les seves estructures mentals.

De tant en tant, però convé tocar un poc de peus a terra i comparar llenguatges, potser el llenguatge que ens agrada més no és el més convenient per la tasca a realitzar, o no es tan ràpid com ens pensàvem.

Una manera de comparar llenguatges és la de crear tot una sèrie de programets típics i desenvolupar-los en els llenguatges que vulguem estudiar i veure quin té l'execució més ràpida o consumeix menys memòria, i això és precisament el que han fet la gent de The Computer Language Benchmarks Game, aquí trobareu un entorn on poder comparar distints llenguatges i fins i tot si trobau que falta alguna implentació o que podeu fer un programa dels que se proposen de manera més eficient poder enviar-ho.

Com que escor molt cap a la web m'he entretingut a comparar un grapat de llenguatges d'script entre ells i després comparar-los amb Java o C#.

  • Python i Perl en general són molt semblats tant en velocitat d'execució com amb consum de memòria. Sols a l'execució de fasta per la generació de seqüències de DNA llueix més Python per mor d'un consum de memòria molt més petit. També és interessant comparar com en el tema de les expressions regulars Python no queda tan enfora de Perl com un podria suposar-se i que queda molt millor que el PHP per exemple.
  • Python i PHP. En general Python és millor, però no hi ha una diferència prou gran com per marcar la diferència en la majoria d'aplicacions, llevat de que tinguem que fer molts de càlculs, però clar, llavors potser un llenguatge interpretat no és d'entrada el més ràpid.
  • Python i Java. En velocitat de CPU Python queda molt malament llevat de casos molt particulars com el regex-dna, així que si sols coneixem Python i Java i hem de fer molts càlculs millor el segon, si hem de tractar cadenes millor Python. El mateix seria aplicable a PHP o Perl. Si el problema que tenim no és la velocitat sinó el consum de memòria, ja ens podem anar acostant més a Python i mens a Java.
La pàgina té un nom molt apropiat i t'hi pots passar hores fent comparacions, mirant com està codificat cada programa, com és d'elegant el codi i les línies que s'ha necessitat per realitzar cada algorisme.

Comparar és divertit, però no sols de velocitat i consum de cpu viu el programador. Saber en línies generals com se comporta el nostre llenguatge habitual comparat amb els altres és sempre profitós, però ens hem de situar sempre en perspectiva i situar el llenguatge en la casta de projectes que desenvolupam. Si l'aplicació no té un consum de memòria o cpu intensius aquestes característiques del llenguatge potser importaran menys que la velocitat en la que podem formar als desenvolupadors, en la mantenibilitat de codi, en el nombre de línies de codi que es necessiten per implementar un punt funció, ... i sobretot hi té molt a veure la capacitat de la gent que programa. No serveix de res tenir un llenguatge ràpid si el nostre codi és erroni o totalment ineficient.

1 comentari, 0 trackbacks (URL) , Tags: Informàtica


Veure-les venir

Escrit per Aaloy a 12 de November , 2007 a les 8:16 p.m.

Al curset que férem de formació d'equips (anyor el Tai-Chi) hi havia un exercici per determinar la nostra intuició a l'hora d'esbrinar esdeveniments, en aquest cas l'exercici consistia en estar amb els ulls tancats i intentar anticipar-se a un company que ens tocaria a una part del cos que ell volgués (eps! sense abusar). La cosa no va sortir malament, però he de dir que a la vida real, saber cap a on aniran els tir sols ser sovint més senzill, entre altres coses perquè no tenim ells ull tancats i podem raonar un poc. Suposem per exemple un cas hipotètic: un stakeholder  amb poder damunt el pressupost vol externalitzar una aplicació web i demana pressupost a tres empreses:
  • L'empresa A és una empresa.
  • L'empresa B és també una coneguda empresa local amb la qual ja s'hi ha fet feina.
  • L'empresa C és una empresa consultora d'àmbit nacional i internacional amb la qual ja s'hi ha fet feina.
A les tres empreses se'ls fa arribar la mateixa definició o indefinició d'aplicació i es queda a l'espera del pressupost. A un moment donat se sap que l'stakeholder ha decidit quina empresa farà la feina. Quina empresa té més punts per resultar l'agraciada? Com es pot saber? Quina hauríeu triat vosaltres? Els qui no ho hagin endevinat la resposta és l'A. Perquè, perquè és la que canta. A no està al mateix nivell que les altres dues i quan passa això o bé s'ha fet per completar ofertes o perquè ja es té previst que sigui la guanyadora i les altres dues sols estan de convidats de pedra. Saber si és una opció o l'altra ja depén un poc més de l'entorn, però l'habitual és que l'empresa que menys encaixa sigui la guanyadora, després de tot, es podria haver demanat la proposta a una altra empresa del mateix nivell. Un altre cas potser el contrari, és a dir de les tres propostes tenim:
  • Empresa A: desconeguda.
  • Empresa B: amb referències i contínues visites dels comercials.
  • Empresa C: empresa amb referències però coneguda per ser molt cara.
Com a pista direm que el projecte és gran, ja que si és petit, la cosa es distorsiona. I la resposta és? La B. La primera  no té referències i presenti la proposta que presenti és massa arriscada, a la tercera se li va demanar pressupost, però ja es sabia que seria molt cara, per tant sols ens queda la segona opció. Una vegada més ens trobam amb situacions en que encara que es demanin tres ofertes ja és pot saber amb molta antelació quina serà la proposta que sortirà elegida. Sempre hi pot haver sorpreses, però en el joc de l'anticipació qui comanda són les probabilitats.

3 comentaris, 0 trackbacks (URL) , Tags: Informàtica General


Technical Debt

Escrit per Aaloy a 07 de November , 2007 a les 1:30 a.m.

En Marcos m'ha fet arribar un interessant article anomenat Technical Debt, d'Steve McConnell un dels meus autors preferits. En ell McConnell ens parla del concepte del deute tècnic, és a dir, l'equivalent a l'import en hores de feina que haurem de pagar en el futur quan en el desenvolupament d'una aplicació prenem determinades decisions. Per exemple, quan no posam comentaris al codi estam adquirint un deute tècnic, ja que més endavant la persona que ho tengui que depurar o fer-ne modificacions ho tindrà molt més mal de fer i hi haurà de dedicar més hores de feina.  També contreim aquest tipus de deute quan per exemple decidim fer la nostra aplicació depenent d'una determinada base de dades, donant per suposant que no necessitarem portar-la mai a una altra. En aquest cas el deute pot fer-se palès quan tenguem la necessitat de canviar de base de dades o bé pot no aflorar mai si l'aplicació acaba el seu cicle de vida sense necessitat de canviar de base de dades. Es distingeixen dos tipus de deutes tècnics, aquell en el qual hem caigut de manera no intencionada i aquell totalment intencionat i que respon a una decisió estratègica. Els no intencionats s'han d'evitar sempre, ja que no hi tenim cap control, dels intencionats n'hem de ser conscients i avaluar-ne la relació entre el risc que assumim i el possible cost d'aquest risc vers els beneficis que en podem obtenir. Tal i com passa amb els deutes financers, aquests tipus de càrregues poden ser fruits d'una planificació a llarg plaç o bé per necessitats puntuals del moment. Tal com passa amb el deute financer que en tenim a curt i llarg plaç (la visa i l'hipoteca) podem tenir un deute tècnic a llarg plaç, com per exemple fer una aplicació depenent d'una versió concreta d'un sistema operatiu si sabem que no el canviarem en diguem tres anys, o bé a curt plaç, com algunes decisions que s'han de prendre per tal de sortir al mercat abans que la competència i que s'hauran de resoldre una vegada el programa estigui en producció. En els dos exemples, es veu que el deute existeix: als tres anys les dependències s'introduïren del sistema operatiu s'hauran de eliminar, els errors les característiques no documentades de la versió inicial del programa s'hauran d'arreglar. A més de saber que existeix el concepte de deute tècnic ens permet atracar-nos més cap el llenguatge que parla la gent que comana normalment els programes. Ajuda a ser conscient del cost de determinades decisions tècniques i a poder fer un símil entre el cost financer i el cost tècnic, de manera que es pugui fer palès un possible cost ocult, que després haurà d'assumir-se o no, en funció dels beneficis que hi pugui haver.

1 comentari, 0 trackbacks (URL) , Tags: Informàtica


Facts and Fallacies on Sofware Engineering

Escrit per Aaloy a 04 de September , 2007 a les 6:15 p.m.

Facts and Fallacies of Sofware Engineering Robert L. Glass Ed. Addison-Wesley ISBN 0-321-11742-5 He devorat aquest llibre. Fins i tot quan ja no podia més de son una de les darreres coses que he fet aquests dies és anar llegint un dels fets o fal·làcies que ens presenta Glass. L'estructura de com se presenta el llibre és molt interessant: presenta els fets, després en diu si hi ha opinions contràries i finalment cita les fonts i les referències bibliogràfiques. Aquestes darreres serveixen molt per aprofundir en el tema, per exemple que la tècnica de la inspecció de codi és bona per a detectar errors no és res nou (encara que hauríem de veure a quantes empreses es fa o estaria ben vist que es fes), però que la seva eficàcia arribi a poder detectar el 90% d'errors fa que la vegi d'una altra manera, i que per tant tengui moltes més ganes de saber-ne més. La bibliografia que adjunta Glass de bon segur que formarà part de la meva propera llista de la compra a Amazon. També crec que és molt interessant com a lectura per als que creuen que hi ha bales de plata o que la informàtica és una ciència ben formalitzada. Per cert, a la bibliografia de l'autor diu que fa més de 45 anys que exerceix la professió, des del 1954, supòs que no hi havia titulacions informàtiques aleshores, segons alguns això del descartaria per poder fer feina a Espanya. Ho sent-ho, no me n'he pogut estar, però això està també dins l'esperit del llibre: el fer pensar, raonar, ... Glass ens amolla les idees per a que hi pensem, ens diu que hi podem estar d'acord o no, però que ell ho veu així i aporta referències i estudis per argumentar les seves tesis. Puntuació? Totalment recomanable.

3 comentaris, 0 trackbacks (URL) , Tags: Informàtica Llibres i revistes


Intrussisme professional a la informàtica

Escrit per Aaloy a 03 de September , 2007 a les 7:26 p.m.

Aquests dies he estat força entretingut llegint els articles d'En Ricardo damunt el tema de la regulació de la carrera informàtica i la necessita de crear un col·legi professional que lluiti contra l'intrussisme laboral per la via d'obtenció de privilegis. Personalment comparteixo la postura de Ricardo. No entenc què és vol regular d'una professió com la informàtica i la programació on no queda clar què hi ha d'art i què hi ha de ciència. Però és més, d'una tacada es vol deixar fora de la professió a tot un conjunt de gent, físics, matemàtics, emprenedors, que han inventat la informàtica tal i com la coneixem avui en dia. No oblidem que la programació es pot considerar com una matèria instrumental, que s'ensenya com se poden ensenyar les matemàtiques a físiques, i com a tal es perfectament possible que molta gent amb una formació científica sigui tan bona programant com qualsevol enginyer informàtic. La frontera entre el que pot fer un o altre no la marca la titulació, sinó l'empresa, ja sigui pública o privada. En el primer cas es solen requerir titulacions compatibles i passar unes oposicions, en la part privada, cada empresa sap el que li convé. Això vol dir que la titulació no val res? No seré jo qui ho digui. La titulació estableix un punt de partida, serveix d'entrada per suposar que es tenen uns coneixements mínims i una base, però no signifiquen que després un hagi de ser un bon professional.  En el cas de la informàtica on els coneixements es queden obsolets ràpidament, el més important per a un professional és la formació contínua, formar-se i preparar-se per tal de no esdevenir obsolet. En aquesta preparació tenir els coneixements que ens dóna la carrera en serveix per fer que la corba d'aprenentatge sigui molt més suau. Aquesta idea és la que defensa sovint la gent docent, que la universitat no ha d'ensenyar a fer anar un programa concret, sinó que ha d'ensenyar els conceptes i preparar a la gent per poder afrontar amb garanties el seu futur professional. Per una altra banda, voler una regulació implica no ser massa conscients del que representa programar. Segons Brooks és la tasca més complexa que mai ha fet l'home, i hi estic totalment d'acord. Els disclaimers que acompanyen als programes són necessaris per deixar ben clar que no es pot garantir que el programa funcioni, hi ha massa factors que hi intervenen: la programació, el maquinari, la gent que el fa servir i l'ús que en fa aquesta gent en són uns quants. En aquests moments no crec que cap asseguradora fos capaç de vendre'ns una assegurança col·lectiva que ens protegís de reclamacions per fallades de programari. Si fos possible crec que tothom ens hi apuntaríem, sols per ser els primers en poder reclamar i cobrar les primes. Voler regular la professió implica dir que som millors, que els nostres programes estan més ben fets que els que pugin fer físics, químics, telecos, matemàtics i en definitiva qualsevol que estigui fent ús de la informàtica com a eina en la seva professió,  sense poder demostrar que això és així i traint l'esperit dels que ens han duit fins aquí. La carrera informàtica és molt jove, i convé que recordi que no fa massa anys les principals empreses contractaven no informàtics, sinó matemàtics i físics, perquè normalment havien programat molt més que el recents sortits d'una carrera d'informàtica encara sense definir del tot i estaven molt més preparats pel raonament i el cercar-se la vida. Perquè veient alguns comentaris que li han fet a Ricardo pens que a la part del raonament encara li queda molt. Afortunadament la majoria d'informàtics no som així. Al manco jo tenc ben clar que la informàtica tal com està avui en dia no es pot considerar del tot una ciència, encara li queda molt camí per recorre. Avui llegia un estudi que deia que sols el 15% de les publicacions informàtiques són estudis amb dades i xifres raonades, front a 60 ó 70% d'altres ciències. Crec que la xifra no és anecdòtica. Basta anar a cercar ratios de productivitat per llenguatge, sistemes d'estimació de costs o mètriques de programació per adonar-nos que encara estam lluny del que han assolit altres enginyeries, i potser no ho assolirem mai, però això és el gran repte que tenim com a informàtics i la grandesa dels temps que estam vivint. Potser seria bo que els col·legis existissin, però no per reclamar privilegis sinó per ajudar a convertir la informàtica amb una vertadera ciència, fomentant la investigació pura, exigint que el codi, que és la nostra font principal de coneixement, sigui lliure, que les administracions obrin els seus projectes i les seves dades per tal que es puguin tenir mètriques i estudis que ens ajudin a tenir dades estadístiques que ens ajudin en les nostres tasques diàries. I si aquesta ajuda ve d'enginyers informàtics, matemàtics, físics o de professors de llatí,...  és del tot irrellevant.

3 comentaris, 0 trackbacks (URL) , Tags: Informàtica


Trac i clearsilver

Escrit per Aaloy a 20 de August , 2007 a les 9:07 p.m.

El clearsilver és una llibreria de plantilles que abans feia servir el Trac i que s'està substituint a favor de Genshi, una altra llibreria que segons la gent de Trac els causa molt menys problemes. La cosa està, però, en que no es lleven les dependències fins a la versió 0.11 no s'eliminen les dependències de clearsilver i fins i tot en aquesta versió es mantindran les estructures necessàries per a que els plugins segueixin funcionant. He pogut comprovar de primera mà el que es diu a la web de Trac, "clearsilver sucks", ja que amb Ubuntu i la versió 2.5 de Python no fa sino donar problemes, que sospit han acabat per tomar el servidor Apache 2 que tenim al webhosting virtual. En un primer moment he pensat que se'ns hauria tornat a oblidar el pagament, però no, tots els serveis eren vius llevat de l'Apache i als logs he vist un bon munt d'errors del tipus 
/usr/lib/python2.5/site-packages/trac/web/clearsilver.py:128: RuntimeWarning:

Python C API version mismatch for module neo_cgi: This Python has API version 1013, module neo_cgi has version 1012.
No ha costat molt trobar referències tant al Trac com a Ubuntu d'aquest error i de com solucionar-ho. Aquesta és la recepta que m'ha servit a mi:
  • Davallam el codi font: wget http://www.clearsilver.net/downloads/clearsilver-0.10.4.tar.gz
  • Modificam els arxius config i config.in, cercam les línees que diuen python_version i i afegint la versió 2.5 al davant.
  • Descomprimim el fitxer tar xvzf clearsilver-0.10.4.tar
  • Davallam paquets adicionals però aquesta vegada per apt-get
    • sudo apt-get install zlib1g-dev 
    • sudo apt-get install autoconf 
    • sudo apt-get install python-dev
  • Feim el configure: ./configure --disable-wdb --disable-compression --disable-perl --with-python=/usr/bin/python2.5
  • I per acabar el sudo make install
  • Com que la instal·lació no acaba d'anar fina convé copiar la llibreria generada sudo cp -i neo_cgi.so /usr/lib/python2.5/site-packages/neo_cgi.so per acabar de substituir la referència que hi havia de la llibreria anterior o fer un ellaç simbòlic cap a la nova instal·lació de clearsilver: sudo ln -s ./clearsilver-0.10.4-py2.5-linux-i686.egg/neo_cgi.so neo_cgi.so
Reiniciam l'apache i ja no hauríem de tenir més errors d'aquest tipus. Referències:

1 comentari, 0 trackbacks (URL) , Tags: Informàtica


Va d’ERPs

Escrit per Aaloy a 15 de August , 2007 a les 7:55 p.m.

Des del blog de Ricardo Galli me n'assabent de dos articles [1] molt interessants damunt els ERP, a més obviament del seu(s) propis escrits. Particularment el ERPs em fan molta grima, tant perquè la majoria són programes tancats que fermen als seus usuaris, per la manera que es comercialitzen i perquè representen una manera de fer programes allunyada del que es consideraria bones pràctiques de programació. D'ERPs conec l'Oracle Financial, Navision i SAP, encara que aquest darrer molt de passada i tots ells tenen un problema fonamental: és l'empresa la que s'ha d'apatar a l'ERP. Si no es fa així els costs d'adaptacions són tan grans que ben bé l'empresa podria haver-se permès crear els seu programari a mida. Però clar, la manera de comercialitzar un ERP és dir que el programa fa tot el que necessita l'empresa i més, que té tots el mòduls i que en tot cas sempre es podran fer adaptacions. La realitat però, és que una vegada s'ha convençut a les altes esferes de la bondat de l'ERP i ja s'ha desembutxacat una quantitat més que considerable en llicències de l'ERP i la base de dades i comença la fase d'implantació i adaptació l'empresa ja està agafada. Si vol seguir fent feina de la manera que sap fer i que és el seu factor competitiu, haurà de fer mils d'adaptacions a l'ERP, adaptacions que es cobren a preu de canari jove i que poden doblar o triplicar el cost en llicències de l'ERP. La història de que la gent de l'empresa podrà fer adaptacions sense problemes no és més que això, una història. La realitat és que l'ERP és tan complexe que els propis consultors reconeixen que tenen gent especialitzada en un mòdul concret del producte. I després venen les actualitzacions de versions. Actualitzar torna a ser com a una implantació. En vaig viure una indirectament i sols veies gent de la consultora anar i venir, fent hores i més hores. El cost: prohibitiu! I sols va ser un canvi de versió! Els ERPs són el fast-food del programari de gestió. Prometen una solució ràpida, però després resulta que has de fer coa per a que t'atenguin i si en menges molt tens assegurada una indigestió. Els ERPs també prometen una solució immediata a les necessitats d'informatització d'una empresa, però es cuide'n molt de parlar-te dels temps d'implantació que s'aniran allargant, dels riscs de la implantació i del que et costaran les futures actualitzacions. Si parlam d'enginyeria de programari hem de parlar del costs de desenvolupament dels projectes i de la quantitat d'errors i del cost del maquinar. Es ben conegut que un programa de 100.000 línies no té un cost 10 vegades major que un de 10.000 línies, sinó que el cost és sensiblement major, i quan es desenvolupa programari per un ERP estan agafant tant les complexitats del programa que desenvolupam més les complexitats del propi ERP. Els ERPs tenen desenes de milions de línies de codi, i per tant les possibilitats que hi hagi errors en el codi augmenten en la mesura que augmenta el nombre de línies. Si tenim un programa de 10.000 línies i una taxa d'errors de 5 errors per KLOC podem estimar que tenim uns 50 errors pendents de detectar quan el programa passa a producció. Com que segons Putnam-Myers el nombre de defectes per línies de codi és lineal, podem esperar que l'ERP tengui una taxa d'errors en la mateixa proporció o major, ja que el distribuidor es cuidarà molt de dir-nos quin és el ratio d'errors del programa o el temps necessari per la seva actualització. I si el nostre negoci depèn de fer adaptacions a programari que tindrà errors, que haurem de corregir mantenir i que possiblement perdrem en la propera actualització costossísima de l'ERP, doncs la cosa fa por, molta por. Però encara hi ha més, tothom pareix estar d'acord amb que els ERPs són complexos, molt complexos, i amb això la linealitat del nombre de defectes per KLOC no es manté, sinó que creix de manera exponencial, i això malhauradament no afecta sols a les línies de codi de l'ERP sinó a les modificacions i adaptacions que se facin, que hereten aquesta complexitat. Què vol dir això? Doncs adaptacions més cares, més males de mantenir i depurar. Així que la cosa està clara, davant la opció de desenvolupar un conjunt d'aplicacions a mida per la nostra empresa o tirar d'un ERP hi ha que valorar no sols el cost d'implantació de cada solució, sinó els costs dels anys que vindran i com afectarà la implantació de l'ERP als nostres processos de negoci, ja que en lloc d'adaptar el programari al negoci haurem de fer les coses com l'ERP millor li vagi per gestionar-les. Respecte a l'arquitectura orientada a serveis (SOA) he de dir que sí que ho veig com a una manera de guanyar independència de distintes capes de programari i augmentar la reutilització de codi, en forma de programes. Si se fa bé, tendrem serveis petits, molt orientats a una tasca, controlables. Podrem controlar la complexitat de cada servei i mantenir la seva taxa d'errors molt baixa. Això implica no caure en la trampa que volen els fabricants d'ERPs actualment: tot serà un servei i ho podràs fer servir sempre que facis servir el nostre BPEL o el component X que te proporcionen. La idea és seguir-te tenint fermat. El serveis ens poden ajudar a anar independitzant capes de l'ERP i anar fent millores sense tenir que llevar tot l'ERP de cop. Per exemple, podem fer un mòdul de facturació en forma de servei que al final deixi les línees de facturació en la manera que les vol l'ERP de torn. Si feim una aplicació de facturació que faci servir el servei, estam aïllant-la de l'ERP i si demà decidim anar cap a un altra ERP lliure o cap a aplicacions sofisticades i separades el cost d'adaptació serà molt menor. Les empreses no necessiten que tot sigui un servei, necessiten que tot el que es pugui reutilitzar pugui ser un servei, i que els programadors puguin fer servir aquests serveix per anar montant les aplicacions. La metàfora del Tente no és aplicable, no es tracta de sols ajuntar peces, es tracta per una part de montar una arquitectura de serveis i aprofitar-la per crear aplicacions que aprofitin els serveis com si fossin llibreries, però això està molt lluny de joc d'anar encaixant peces. Particularment és una idea que cada cop m'agrada més, però entesa d'aquesta manera. Per exemple, amb Java i llibreries com XFire o Axis és prou senzill publicar serveis Soap, però els serveis interns no tenen per què ser precisament SOAP, podem tirar de protocols més lleugers com l'XML-RPC per exemple i fer-los servir per augmentar la velocitat de comunicació entre els serveis i la nostra aplicació. Aplicació, per cert, que no té perquè estar escrita en Java, la capa de presentació en Java, ja sigui Swing o web és feixuga i amb una velocitat de desenvolupament i instal·lació poc àgil. Podem tirar de llenguatges d'script per fer la capa de presentació i tenir el millor dels dos mons: la facilitat de creació d'interfícies d'usuari dels llenguatges d'script i la facilitat de crear serveis que tenen els bastiments de Java. Tot i això, no crec que a curt plaç els ERPs desapareguin, hi ha massa inversió feta. Seria el mateix que dir que els programes fets en COBOL desapareixeran d'aquí no res. Canviar un ERP és molt costós, i a més hem de tenir en compte que potser l'empresa encara està amortitzant la darrera actualització. [1] http://evora.mit.edu/smr/issue/2007/fall/01/ http://www.roughtype.com/archives/2007/08/erps_troubled_l.php

2 comentaris, 0 trackbacks (URL) , Tags: Informàtica


Filtres de selecció de personal

Escrit per Aaloy a 13 de August , 2007 a les 10:12 p.m.

Trobar bona gent és difícil i trobar-la que a més es pugui integrar en un equip ja format encara ho és més. A les respostes d'anuncis de feina s'hi pot presentar molta gent i en poques preguntes sovint s'ha d'intentar esbrinar si la persona que tens al davant serà bona tècnicament i a la vegada la seva manera d'entendre la feina serà per l'estil de la que hi a al grup.

Encara que soni molt a tòpic hi ha una sèrie de regles heurístiques que quan parlam de programació web ajuden a fer-se una idea d'ambdues coses:

  • Adreça de correu amb domini propi : suma un punt. Per mi vol dir que al manco hi ha una preocupació per cercar-se la vida i potser haver donat d'alta un domini. Tenir un domini implica que també es pot cotorrejar abans de la selecció i veure quins temes preocupen al possible candidat o candidata.
  • Adreça de correu amb Hotmail: resta dos punts. Sovint també vol dir que estàs engantxa al messenger i/o que no ets capaç de diferenciar el tenir un correu per usos lúdics d'un per usos professionals. Serveix per a diferenciar la gent que el primer que intentarà fer és posar-se el Messenger.
  • Edició d'HTML. Si el sols es sap fer servir el Dreamweaver resta de cop 2 punts. Implica que d'entrada es tendran problemes quan es tracti de modificar planes webs fetes a troços, pràctica habitual en la programació web. Si utilitza un editor amb resaltat de sintaxi suma un, si a més sap fer servi el vi/vim suma dos punts. Si no ha fet mai una plana web resta cinc punts de cop.
  • Coneixements de CSS. Si ha maquetat pàgines amb CSS i sap perquè ho ha fet suma 2 punts. Si no sap perquè ho ha fet sols en suma un. Si no sap què és resta un punt. Tenir coneixements de CSS ajuda a saber el que es podrà fer en la pàgina.
  • Coneixements de Javascript. Si els sap fer servir mitjanament suma un punt, si a més coneix alguna llibreries de les típiques suma un altre punt. Si sols coneix el que posa el Dreamweaver lleva un punt. Tot es pot aprendre, però si un ja té experiència en Javascript vol dir que realment ha programat per la web. Si a més abans ha dit que utilitzava un editor "per programadors" començarà a agradar-me força.
  • Si sap què és l'arbre DOM suma un