Protocol Buffer

Escrit per Aaloy a 08 de July , 2008 a les 10 p.m.

Protocol Buffer és una llibreria d'intercanvi de dades que Google ha alliberat i que segons promet és de 20 a 100 vegades més ràpida que l'XML (i ja no parlem de SOAP) per a l'intercanvi de dades entre aplicacions.

Lo de la velocitat s'haurà de comprovar, però el que sí pareix clar és que és prou senzilla per ser abastable, la documentació és bona, i ja va dirigida als tres principals llenguatges de programació (C++, Java i Python).

Com que en faig servir dos habitualment, doncs es cosa de fer-hi una ullada i algunes proves d'stress a veure si realment és tant ràpida com diuen.

La cosa no sé si s'imposarà com a format d'intercanvi entre llocs d'Internet, però el que sí tenc clar és que si és més ràpid pot ser ideal com a format per a tecnologies SOA dins de la mateixa empresa. Una reducció d'un factor 10 ja seria prou bona, amb l'avantatge de que es podrien crear (com ara, per cert) serveis en un llenguatge i consumir-los en un altre, però sense tenir que pagar el preu que suposa en termes de rendiment fer-ho en format WSDL.

Es prest, per donar-ne una opinió amb més fonament, però pel que he vist de la documentació i els exemples, crec que aquest format i jo ens durem bé :)

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

Django i oracle

Escrit per Aaloy a 06 de July , 2008 a les 1:10 p.m.

Aquesta setmana ens hem vist amb la necessitat de crear una aplicació que havia de connectar amb un web service i agafar les dades de l'aplicació legacy que està feta en Oracle.

Hi havia dues alternatives, l'opció de salvemos el culo que implicava fer-ho tot en Java i no arribar a temps, o jugar-nos-la i fer-ho en Python i Django, i aquí el Boogeyman [1], no ens havíem trobat mai amb la necessitat de connectar directament Django amb Oracle, així que el primer de tot va ser veure com es podria fer i si ens trobaríem algun problema.

Per connectar amb Oracle, s'han de fer servir una llibreria anomenada cx_Oracle i de les llibreries d'Oracle mateix. Com que no vaig trobar les llibreries per la meva versió d'Ububuntu, doncs a compilar toca!. Vaig trobar una guia força bona a la web, sols vaig necessitar instal·lar una llibreria addicional a Ubuntu - si no la teniu en executar us petarà per a que no la troaba, i posar les llibreries d'Oracle a l'ldconfig.

Així doncs, vençut el Boogeyman, tota la resta era conegut i controlat: els serveis web amb ZSI encara que pot resultar un poc embullat al principi, quan li agafes el què, és molt potent. Si a més li posam una façada per adaptar-ho al que volem, consumir serveis web fets amb SOAP deixa de tenir misteri. Per una altra banda la part de manteniment web amb Django ja està força controlada, i la part de consola que també havia de tenir l'aplicació tampoc era nova. Python de fet té una utilitat anomenada Cmd o també es pot fer servir una utilitat de tercers anomenada cmd2 que hi afegeix algunes característiques interessants.

L'important d'aquesta història, però, no és la batalleta, no és tant veure que es pot fer feina amb Oracle amb Django i Python, sinó adonar-se de que per a que un projecte es pugui dur a terme amb garanties una de les coses més importants que s'han de fer és descobrir aquelles coses que sabem que no sabem i a ser possible descobrir el més aviat possible allò que no sabem que no sabem.

Si en aquest projecte s'hagués començat per altres tasques ens hauríem pogut trobar en dificultats a l'hora d'accedir a les dades i la feina feta serviria ben poc, o si més no, el projecte s'hauria endarrerit. Controlant el primer de tot el que pot donar dificultats augmenta les nostres possibilitat d'èxit.

0 comentaris, 0 trackbacks (URL) , Tags: Informàtica Gestió de projectes

Millores al blog

Escrit per Aaloy a 08 de June , 2008 a les 11:30 a.m.

De tant en tant faig feina al blog, no per escriure-hi sinó per afegir-hi noves funcionalitats. Encara hi ha moltes coses que m'agradaria posar-hi i millorar, però a poc a poc esper anar arribant-hi.

A la darrera actualització he fet algunes millores que recomanaven al Google Webmaster Tools com la d'afegir descripcions úniques per apunt. Django a les seves plantilles té el filtre truncatewords_html que m'ha anat fantàstic per això.

Una de les millores que volia fer també era la d'amagar un poc tota la llista de mesos que hi ha. Aquest blog té apunts des del 2004 i la llista començava a ser molt llarga. Ara veureu que sols apareixen els anys (sempre que tingueu el javascript activat clar) i que en pitjar damunt ells es despleguen els mesos. Fer això ha estat entretingut perquè ha implicat jugar amb dos tags més de Django, el for per obtenir si estava a la primera posició del bucle o a la darrera, per tal de poder tancar els divs, i el tag ifchanged que ens permet saber si una variable (en el meu cas l'any) ha canviat o no respecte al seu valor anterior.

Amb aquestes eines ha estat possible muntar l'estructura necessària per a utilitzar un el Animated Collapsible DIV, una petita utilitat per jquery que permet ocultar i mostrar divs a voluntat, agrupant-los per categories si convé.

Ara la plana principal al meu entendre queda un poc més neta i amb prou espai a la columna lateral esquerra per anar afegint més coses.

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

D'errors i línies de codi

Escrit per Aaloy a 26 de May , 2008 a les 9:30 p.m.

En Domingo al seu blog fa una referència al meu apunt damunt llenguatges dinàmics i un bon grapat de bones reflexions.

Això de no creure's el que dic és una postura molt sana, sobretot perquè en la redacció d'un apunt me puc deixar detall i dades que són interessants. Una postura crítica ajuda a reflexionar i a completar les frases que d'altra banda s'haurien deixat com a dogmes de fe. Jo sóc del mateix tarannà, hi ha coses que me crec i coses que a poc que vegi indicis de contradiccions, doncs cerc més informació o deman explicacions. Això, he de dir també, m'ha causat força problemes en el món empresarial, on sovint el "no pensis" és una qualitat que ajuda a progressar.

Bé, però no me'n vull anar per les bardisses, o sí, ja que hi sóm, aprofitaré per dir perquè no faig servir el Twitter: no hi ha espai abastament :)

Afirmació: El nombre de línies de codi que escriu un programador al dia és una constant. Això és un efecte estadístic. Fa temps es parlava de que un programador escriu cinc línies de codi sense errors al dia. Està clar que és una dada estadística i fins i tot controvertida, ja que que és molt complexa definir què és i que no és una línia de codi i de que les línies de codi no s'han de fer servir per mesurar el rendiment. Tot i això podem trobar referències capítol 5 de Software estimation de McConnell on a la Taula 5.1 torbam la relació entre les línies d'un projecte i les línies de codi per programador i any. Això no vol dir que tots els programadors escriguin les mateixes línies de codi (de fet la productivitat entre programador pot arribar a un factor 10 -Peopleware-, però sí que en mitja i per a una organització i projecte, el nombre de línies de codi que s'escriu en promig és constant. A Sofware Mesurement and Estimation diu "Studies have shown that a proficient programmer can programm aproximately the same number of debugged lines of code per day regarless of the language". D'aquí que gent com QSM o David Consulting Group facin comparatives entre llenguatges per a comparar l'expressivitat de cada llenguatge. Per exemple C té un gearing factor de 128 i Java de 53. Això vol dir que una funció que en C necessita 128 línies de codi en Java en necessitarà en promig 53. Si un programador experimentat escriu, essent optimistes 10 línies de codi depurat al dia, llavors necessitarà 13 dies en C i 6 en Java (nombres redons).

D'aquí llavors que els llenguatges dinàmics, al necessitar menys línies de codi per fer el mateix poden completar els projectes en un temps més curt. Com que el temps significa doblers, implica que els projectes surten més barats.

Afirmació: el número de errores directamente proporcional al número de líneas que se escriben Aquí també entram en temes estadístics. De fet es parla de nombre d'errors d'un programa per mils de línies de codi. De la mateixa manera que en el cas de les línies de codi que escriu un programador, hi ha moltes diferències, però Casper Jones a "Program Quality and programmer Poductiviy (1997)" va recopilar algunes dades, que també cita en McConnell. També Reifer en va fer estudis, per exemple per la part Web estudià 65 projectes, i trobà que el ratio és de 6 errors per KESLOC (KESLOC Kilo (Thousand) Equivalent Source Lines of Code). Aquest nombre depèn força del tipus del projecte i de l'organització, però és estadísticament significatiu. Per tant, si donam com a bo el que els llenguatges dinàmics necessiten menys línies de codi per expressar el mateix que els llenguatges compilats tradicionals (Java, C, C+, ...) tendrem que el nombre d'errors en valor absolut també serà menor.

He trobat també una comparativa entre el nombre d'erros per Java i C++ a un paper de Geoffrey Phipps anomenat Comparing Observed Bug and Productiviy Rates for Java and C++, me l'he d'acabar de llegir, però conclou que amb un 95% de confiança C++ té 9,7 vegades més defectes per KLOC que Java i que a més els defectes en Java són més fàcils de corregir. D'aquí a fer una extrapolació cap a la banda dels llenguatges dinàmics hi ha sols un pas, sols falta que algú s'animi a fer l'estudi.

En Domingo també demana l'opinió damunt els llenguatges dinàmics per la capa de negoci, però això crec que dóna per un apunt per ell sol, així que ho deixaré per la propera vegada, però promet, amenaç, amb tractar-ho.

0 comentaris, 0 trackbacks (URL) , Tags: Informàtica Python Django Gestió de projectes

Llenguatges dinàmics

Escrit per Aaloy a 25 de May , 2008 a les 11:18 a.m.

Al blog de Ricardo he esta llegint l'apunt anomenat "Lenguajes dinámicos, programadores y FUD" així com els seus comentaris. Tot i que hi he deixat allà un comentari amb la meva opinió, crec que com a programador en llenguatges dinàmics i tradicionals he de dir la meva.

El primer de tot que voldria fer és evitar el FUD damunt els llenguatges dinàmics, per una raó molt senzilla: la realitat és molt cruel i estam cansats de veure i de llegir damunt projectes web realitzats en Python, Ruby o PHP que estan triomfant i que no desapareixen o exploten per mor de no tenir un llenguatge compilat al darrera. Per tant, la primera cosa que hem de tenir clara és que la teoria pot estar molt bé, però la realitat ens està dient dia a dia que és possible escriure i mantenir programes en llenguatges dinàmics. A un li poden agradar més o menys aquests tipus de llenguatges, però el que no es pot fer és negar la realitat.

També m'agradaria focalitzar l'àmbit de discussió: estam parlant de programes web. Per programes d'escriptori no tenc dades abastament, potser perquè els llenguatges dinàmics brillen en el desenvolupament web més que en la part d'escriptori, llevat de que considerem el Visual Basic com a llenguatge dinàmic, clar.

La cosa està en que amb les màquines actuals els llenguatges dinàmics son ja prou ràpids com per ser competitius amb els llenguates compilats. Això no vol dir que siguin més ràpids, sinó que són prou ràpids per fer la feina i que la diferència de velocitat que hi hagi no sigui rellevant. Que PHP ens serveixi una plana en 1 segon i en Java la serveixi en 0,98 segons, doncs no és rellevant ja que per l'usuari de l'aplicació no significarà cap diferència en l'espera.

Això vol dir que ens hem de passar ja a programar en un llenguatge dinàmic i deixar els compilats? No. Vol dir que és necessari que a més d'un llenguatge tradicional convé que tinguem al caixò de les eines un llenguatge dinàmic. D'aquesta manera quan ens demanin una aplicació podrem sospesar els pros i els contres i fer-la en el llenguatge que s'adapti millor al projecte. Fins i tot si el nostre projecte es farà en un llenguatge tradicional, tenir un llenguatge dinàmic se pot integrar al projecte en forma de rutines de generació de codi, scripts de testeig, etc.

Dit això, i considerant l'àmbit de les aplicacions web, anem a veure avantatges i inconvenients d'elegir un llenguatge dinàmic per al nostre projecte, com que el que més conec és el Python, em permetreu la llibertat de donar els exemples i les referències en aquest llenguatge, in en Java en el cas de llenguatge compilat, en el ben entès que segur que hi ha el mateix tipus de solucions en Ruby, PHP o el vostre llenguatge dinàmic preferit i en C, C++ o .Net, etc.

Cicle de desenvolupament Agafem una aplicació web típica Java desplegada a un servidor Tomcat i la mateixa aplicació feta en Python. El cicle al primer cas és: escriure codi, compilar, corregir els errors de sintaxi, desplegar-ho al servidor, provar i iniciar novament tot el cicle, bé per escriure nou codi o bé per corregir els errors. A l'aplicació Python+Django tendríem: escriure codi, provar i tornar a escriure el nou codi. L'augment de productivitat la tenim no per el fet de no tenir que corregir errors, sinó pel fet de no tenir temps d'espera en el desplegament i per haver d'escriure menys línies de codi.

Errors de sintaxi. Aquí algun haurà pensat, "s'ha deixat els errors de sintaxi", efectivament, ho he fet perquè vull dedicar-lis el seu propi apartat. El compilador caça els errors de sintaxi i ens n'informa, però això vol dir que hem d'executar el compilador, és veritat que això els IDEs com Eclipse ho fan automàticament, però tot i això s'ha de fer. Realment podem fer el mateix amb eines com Pylint o Pychecker i a més el primer a més és capaç de treure tot un conjunt d'estadístiques damunt la qualitat del codi, talment com ho fan eines Java com PMD. El pylint per exemple és el que fa servir PyDev per a indicar els errors de sintaxi i donar avisos damunt el codi. Està clar que aquests errors potser no seran tan acurats como els dels compiladors, però són prou bons com per fer la feina, amb l'avantatge, però que ho podem llançar quan nosaltres vulguem i que no s'ha de passar necessàriament pel compilador per a executar el programa.

Per una altra banda, que el compilador o pylint ens caci els errors de sintaxi ens pot donar una falsa sensació de seguretat, el errors de sintaxis poden fer petar l'aplicació, és veritat, però els errors més greus solen ser els errors en la lògica de negoci de l'aplicació. Quan aquests se detecten el que s'ha de fer és corregir-los el més aviat possible, i en aplicacions web entram en

La fase de desplegament El temps que necessitam per posar una aplicació en producció seria anecdòtic si les aplicacions no tinguessin errors. Necessitar 30 minuts o 10 minuts per una aplicació que es posi en producció i que estigui mesos o anys sense modificar-se no és significatiu. Però, si l'aplicació sofrirà canvis o els errors que es detectin s'han de resoldre el més aviat possible, una diferència de 30 minuts en el desplegament pot marcar la diferència. En el cas d'un error en la lògica de l'aplicació que afecti a un .jar, significa en el millor dels casos compilar l'aplicació o el jar corresponent, substitur-ho i reiniciar el servidor d'aplicacions o l'aplicació, cosa que pot dur entre uns 30 segons y un bon grapat de minuts, depèn del que hi hagi desplegat. El el cas d'un llenguatge dinàmic sovint basta actualitzar els arixus afectats (svn update per exemple) i fer un reload del servidor Apache que tenguem. Cosa d'un parell de segons tot plegat. Està clar que podem minimitzar el primer cas amb servidors redundants i configuracions d'alta disponibilitat, però a un cost major de complexitat.

L'orientació a la tasca Les aplicacions web tracten fonamentalment amb text i produeixen text. Agafam dades de formularis, les tractam, obtenim dades de les bases de dades i les manipulam per a presentar-les a l'usuari en una sortida HTML, etc. Tractar cadenes és part fonamental de les aplicacions, i això és una cosa que els llenguatges compilats fan en general força malament des del punt de vista del nombre de línies de codi que s'han de picar. Els llenguatges dinàmics són força bons tractant informació textual. Posaré un exemple que ens pot servir per il·lustrar aquest fet: les plantilles. En Java tenim tres llenguatges de plantilles principalment: JSP-EL (ja ho sé està agafat pels pels però acceptau-me'l), Freemaker i el venerable Velocity i en general són força infumables. Comparem-ho amb el que hi ha per Python i veurem la diferència (Django, Web String, Cheetath, Mako, Jinja, ...). No crec que sigui anecdòtic, la diferència és que és força senzill manipular text en Python i per tant és força senzill crear-te el teu propi llenguatge de plantilles.

Productivitat El nombre de línies de codi que escriu un programador al dia és una constant. Això vol dir que si volem tenir més productivitat s'ha d'anar cap a llenguatges que ens permetin escriure més funcionalitat en menys codi. Donat el boom que viuen actualment els llenguatges dinàmics encara no hi ha molta literatura al respecte in encara no hi ha ni Ruby, ni PHP ni Python al QSM, però sí que hi ha forces comparatives, una de les més interessants és la d'Stephen Ferg que senyala que programar en Python és de 5 a 10 vegades més productiu que fer-ho en Java.

Diversió i motivació Els llenguatges dinàmics són sexy. Permeten al programador un alt grau de realimentació. Pot provar les seves idees molt ràpidament i això el motiva molt més que tenir que esperar a que el compilador acabi per poder fer les proves.

Pel demés, els llenguatges dinàmics també necessiten unit tests (sols que es poden escriure més ràpidament i amb menys línies), una gestió acurada dels projectes, planificació del que volem fer i refactorització del codi.

La conclusió de tot això és que deixem de banda FUDs que no duen a res i a l'hora d'avaluar un projecte considerem també si és apte per a ser fet en un llenguatge dinàmic, si ho és endavant, el nostre cul no perilla per dita elecció, ja que tant Python, com Ruby com PHP seran prou capaços de fer la feina.

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

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

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

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

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

[(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ó.

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

• 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_

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.

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.