Tras el incierto horizonte
Escrit per Aaloy a 11 de May , 2008 a les 11:02 a.m.
Ahir vaig acabar de llegir Tras el incierto Horizonte de Frederik Pohl. La novel·la està força bé per als que com a mi ens agrada la ciència ficció dura, és a dir, amb força referències científiques i tecnològiques, i aquesta novel.la n'està farcida: intel·ligències artificials, forats negres, astronomia, referències a les constants universals...
La trama és també molt bona, lligant a poc a poc les subtrames que hi ha, com l'origen del Patriarca o els Primitius i com a bona novel·la de ciència ficció deixant-te amb més interrogants que respostes.
De totes maneres val a dir que se li nota un cert pas del temps, hi ha que pensar que l'escrit original és de 1980, quan fa referència a quantitats monetàries (1 mil·liò de dòlars per exemple donen per moltes coses a l'època i no ara) i en algunes referències als ordinadors: un gigabit és una gran quantitat de memòria, ordinadors amb aquesta memòria que omplen una nau ... Tot i això, entra també en la manera de programar les intel·ligències artificials i en el concepte de pagament per us de potència informàtica, propi dels anys 70-80 i que ara amb Google i Amazon torna a estar vigent.
El llibre es pot llegir independentment de la nove·la anterior, Pórtico, ja que les referències s'expliquen prou bé i no interfereixen gaire en la trama principal.
Deu euros ben gastats i un bon grapat d'hores de diversió!
0 comentaris, 0 trackbacks (URL) , Tags: Llibres i revistes
Pont blanc
Escrit per Aaloy a 05 de May , 2008 a les 9:40 p.m.
Com molta gent jo també m'he agafat el pont. Han estat un grapat de dies per descansar un poc, desconnectar un poc (no me'n vaig endur el portàtil) i gaudir de la companyia de la família i els amics (Pere, Marga, Aina i Neus) que amablement ens van acollir a casa seva i ens feren de guies per l'illa d'Eivissa i Formentera.
Es veu que en aquesta època encara no hi ha molta gent pel mig i es pot gaudir de les illes com toca, sense massificacions, a poc a poc i anant un poc més enllà del turisme de discoteca, bauxa i platja. Són illes fantàstiques, amb unes vistes meravelloses i on encara et pots sentir sols i acompanyat a la vegada.
Deixant els aspectes més bucòlics, dir que em va sorprendre agradablement el viatge amb Balearia (no pos l'enllaç a la plana, perquè la veritat, no li fa justícia a la comoditat del viatge i tanmateix no funciona massa bé) i desagradablement el Chevrolet Kalos que llogarem (a l'oferta d'Internet posava Peugot 206 o equivalente). Resultà un cotxe sense gens d'acceleració, de mel i sucre, amb un cosum molt més alt que el que em pensava (amb el Saxo he de dir que estic molt mal acostumat) i el que és pitjor, amb un disseny que feia que amb quedàs sense vissibilitat a les corbes d'esquerra. Per acabar-ho de rematar el volant esta disposat de tal manera que tapa el contaquilòmetres. Bé, al manco ja sé quin cotxe no compraré.
Passades les vacances es pot dir que comença un nou cicle. L'empresa per la que treball viu un procés de fusió que en aquests moments, sigui per unes raons o altres, ha degenerat en una fuga de capital humà cap a altres empreses (director general, director financer, director d'informàtica, directors regionals, etc. etc) i on la política oficial respecte a sous i possibilitats de promoció és la de no pujar l'IPC i on se'ns va dir que per promocionar el millor que es pot fer es canviar de feina cap a altres empreses (bé, al manco no es podrà dir que no es predica amb l'exemple!).
Com no podria ser menys també estic a la recerca activa de feina, per les mateixes raons que altres companys que ja han deixat l'empresa, però en el meus cas me trob que he d'entrevistar a gent per a cobrir els llocs buids.
Un és un professional i faig la feina el millor que sé i puc, mirant de trobar les millors persones per la feina entre els currículums que m'han arribat. Tot i això, des del punt de vista ètic em sent violent entrevistant gent quan jo mateix estic cercant feina, quan el futur és incert a l'empresa, quan qui entri en plantilla es trobarà a poc amb que el seu poder adquisitiu ha baixat a l'any següent i quan no m'atrevesc a recomanar la feina a amics i coneguts amb feina per por a fer-los la putada de la seva vida.
El que sí veig és que ara per ara, la majoria de gent que ens està arribant (i llevat d'alguna excepció) és gent que no s'ha molestat gens en aprendre res pel seu compte, que veu la informàtica i la programació com aquell que posa maons, que li han de dir com es fa una cosa i llavors la fan, però que no se molesten en veure si hi ha coses millors, ni tan sols s'ho plantegen. No és el tipus de perfil que m'agrada, però pareix que és el tipus de perfil que ara per ara vol canviar de feina i veu en el mercat àvid de programadors Java l'oportunitat de progressar econòmicament encara que professionalment no tengui el tarannà, l'experiència o els coneixements que haurien de tenir.
Potser, però, aquest sigui el tipus de perfil que l'empresa espanyola demana o que sigui el perfil que està disposada a pagar. L'emperò és que aquest tipus de perfil acomodatici i institucionalitzat no rendeix, no innova, no evoluciona, i si el teu negoci es basa en un component tecnològic important, com és el cas de la web, fotuts estam.
Aquests dies de vacances m'han fet reflexionar, plantejar-me el futur i decidir-me de l'espera passiva a l'espera activa, sigui amb un canvi de feina, sigui donant una empenta major al projecte d'empresa o senzillament fent de freelance si el projecte és prou interessant. El que tenc clar és que no m'agrada tenir conflictes ètics, no tenc edat.
2 comentaris, 0 trackbacks (URL) , Tags: General
Dos llibres
Escrit per Aaloy a 26 de April , 2008 a les 10:21 a.m.
Mentre esperàvem al vol de tornada vaig aprofitar per anar de compres per l'aeroport, a una llibreria com no pot ser d'altra manera :) Vet aquí el que vaig comprar:
Tras el incierto horizonte, de Frederik Pohl, editat per Zeta. M'agrada la ciència ficció i ja fa un bon grapat d'any vaig llegir Pórtico, així que vull provar sort amb la continuació. De Pohl llegit també "Mercaderes del espacio" i "La guerra de los mercaderes" i també m'agradaren força. Esper que aquesta novel·la, de 362 planes, estigui al nivell de les altres.
Sun Tzu. El Arte de la Guerra. Comentat per Tao Hanzhang, de l'editorial Bresca. Per allò que és un llibre molt citat (a el juego de Ender per exemple) i també recomanat per les escoles de negocis. En la situació actual potser un títol del tipus "El último que apague la luz" de l'editorial Melaspiro o "Maricón el último" de A. Hisus Quedais hagués estat més adient, però bé un poc de culturilla, sempre va bé.
2 comentaris, 0 trackbacks (URL) , Tags: Llibres i revistes
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
Aquest blog ja té calendari
Escrit per Aaloy a 19 de April , 2008 a les 2:16 p.m.
Una de les coses que li faltava al blog (entre d'altres) era la d'un calendari mensual on es poguessin veure els dies que hi ha apunts.
Trob que és una bona cosa que el calendari estigui a la plana principal, ja que serveix per donar una idea del ratio de publicació d'apunts al blog, i a més ens permet una navegació molt ràpida a les entrades del darrer mes.
Per posar el calendari inicialment he intentat fer servir un snippet però no m'acababa de fer el pes. A més tenia que lligar-ho amb el dia d'avui per defecte i amb el mes o dia que estigués vegent l'usuari del blog. Així que he acabat per fer el meu propi template tag. Aquest agafa una variable del tipus datetime que estigui al contexte de la plantilla i renderitza el calendari, anant a cercar si hi ha apunts en cada dia.
El tag no ha quedat molt genèric, ja que està acoblat a blog, però és prou senzill d'adaptar per fer un calendari genèric. El que m'ha duit gairebé més feina és la part d'estils. Com veureu encara queda un tant "cutre", però com que ja fa la feina, doncs a publicar-ho i ja ho aniré polint.
També vaig posar una altra xorrada l'altra dia, un gràfic que fa servir l'API de Google i que permet veure un diagrama de pastís amb la classificació d'apunts per tag. Si feis clic damunt la paraula tag ho podreu veure.
0 comentaris, 0 trackbacks (URL) , Tags: Django
Primeres modificacions al blog nou
Escrit per Aaloy a 15 de April , 2008 a les 9:11 p.m.
Avui he fet les primeres modificacions al Blog. Ja us deia que això de posar en producció les coses et força a trobar i corregir els errors més ràpid.
M'he trobat que els RSS no funcionaven. La idea era mantenir la compatibilitat amb els RSS de Wordpress, de tal manera que els vells subscriptors no notassin el canvi, però me vaig deixar una s i no anaven. El canvi ha esta molt senzill, però ha sigut cosa d'esperar a arribar a casa per fer les modificacions.
De pas he aprofitat per arreglar quatre etiquetes que no estaven ben posades i posar una validació als comentaris de manera que "peti" en posar un comentari buid. La part de comentaris és potser el que menys m'agrada, ja que encara fa servir les llibreries de oldforms de Django i jo ja estic molt acostumat a les noves. El canvi de oldforms a newforms serà de les primeres coses que vull fer. El que em frena un poc és la part de control de l'spam, però miraré si puc fer servir algun component per a connectar amb l'Akismet i fer-ne el backoffice per a controlar-ho.
De les coses que més m'agraden del nou programa és la possibilitat de fer servir el Markdown per a escriure els posts. Al Wordpress segurament se deu poder fer alguna cosa per l'estil, però no m'hi he volgut barallar mai. Vaig posar també javascript per a colorejar codi Python, així que ara veureu que els articles que tenguin codi quedaran un poc millor presentats.
0 comentaris, 0 trackbacks (URL) , Tags: Python Django
Powered by Django
Escrit per Aaloy a 14 de April , 2008 a les 9:24 p.m.
Un dels propòsits del 2008 pareix que ja s'ha complert. Gràcies a Bernat avui hem canviat el blog vei en wordpress que quedarà a blog.trespams.com, més que res per si alguna cosa anàs malament mentre es fa el canvi.
El nou blog està en fase beta, però seguint els principis del la programació àgil, he preferit posar-ho en producció i anar polint els detalls que queden. Com podeu veure pel titol el blog és Django powered. Corre damunt un servidor dedicat que tenim per APSL dins un entorn chroot que en Bernat ha montat.
El codi font del blog està disponible al repositori de google code, com a una branca amb suport unicode del blogmaker, així que tothom és benvingut a col·laborar-hi i a posar-hi tickets pels errors que segurament hi trobareu.
Al codi font també hi ha l'importador de Wordpress cap al blog, de manera que veureu que els articles de l'antic lloc, comentaris i trackback estan inclosos en el nou. La importació no ha estat massa complexa i s'ha fet a partir de l'exportación en format RSS que fa el Wordpress. Tot i això hi ha petites millores a fer, com les de tractar millor els paràgrafs. Alguns articles encara no han passat per la modificació i les lletres es veuen molt atapides, fruit de la combinació de l'importado i de la fulla d'estils que he fet servir per a contruir el lloc, el multiflex.
Encara queden cosetes a polir, veig que m'he deixat el peu del "powered by django" per exemple, la part d'agraïments, etc. etc. que aniré posant durant els propers dies i setmanes. El d'avui és una beta, gairebé alfa, però com us dic, crec que l'important és perdre la por i posar-ho en producció i anar-ho millorant dia a dia.
6 comentaris, 0 trackbacks (URL) , Tags: Python Django
Python for Scientists
Escrit per Aaloy a 13 de April , 2008 a les 12:49 p.m.
L'altra dia a la llista de Python announce vaig veure que hi havia una comunicació de P.Raybaut on deia que havia llançat el Python (x,y), una distribució de Python orientada al món científic.
A mi, pel meu passat en això del càlcul numèric i científic,per mor de un bon grapat d'assignatures de càlcul numèric de Físiques, la idea m'agrada molt i es d'agrair l'esforç que ha fet aquest senyor per triar i integrar un bon grapat d'eines que de ben segur ajudaran a la gent que tengui que fer càlculs numèrics i manipulació de dades.
A part de que hom faci servir la distribució o no (està força orientada al món Windows per exemple), el que és també interessant és veure la selecció de llibreries i programes que s'ha fet. Permet fer des de processament de senyals amb SciPy a manipulació del port paral·lel o sèrie per l'entrada de dades, sense oblidar que inclou la integració del dissenyador de les Qt i les PyQt mateixes.
En Ricardo al seu blog apuntava que havia canviat la introducció a Perl per una introducció a Python i Django. Potser l'aparició de paquets com Python (x,y) servirà per a que el càlcul numèric sigui molt més amè per les noves generacions de físics, matemàtics i estadístics. En el món de la física el FORTRAN és el rei del càlcul numèric encara, però amb eines com aquest la cosa pot anar canviant. Si més no la combinació de Python i interfícies cap a llibreries FORTRAN pot donar-nos el millor d'ambdós mons, amb permís, això sí, de projectes com Parallel Python, del qual esper poder parlar-ne un altra dia.
0 comentaris, 0 trackbacks (URL)
Ja tenim el compte d’Appengine
Escrit per Aaloy a 11 de April , 2008 a les 11:37 p.m.
Doncs això, fa poques hores he rebut el missatge que diu que ja puc fer coses amb l'Appengine de Google, en morenosan en va dir ahir que havia rebut també el seu, així que pareix que estan obrint el grifó bastant de pressa.
Ara es cosa d'anar pensant què es pot fer. De totes maneres no es tant l'aplicació en sí, com poder provar l'entorn i començar a veure les seves possibilitats, com s'hi fa feina, quines diferències hi ha entre poder fer l'ORM de Google i el de Django, veure les limitacions que ens imposa...
Temps al temps!
1 comentari, 0 trackbacks (URL) , Tags: Python Django
El millor IDE per Python i Django
Escrit per Aaloy a 10 de April , 2008 a les 10:28 p.m.
Amb tot el rebumbori del llançament de l'appengine supòs que aviat tendrem una munió de gent demanant-se quin IDE és el millor per desenvolupar en Python i Django, peticions de recomanacions, etc. Vull tractar d'adelantar-me a les peticions, així que us diré quin es per mi el millor entorn de desenvolupament per Python i Django: es diu Gnu-Linux i dues pantalles panoràmiques de 20".
Python és un llenguatge interpretat que et permet fer proves molt ràpidament, sovint el que fas es obrir una consola (recomanació mirau IPython com a consola) i començar a provar les idees que tens. Va molt bé per provar la sintaxi, fer petites proves, depurar, etc). Per tant el que necessitam és un entorn que ens permeti tenir un sistema de consoles potent on sigui fàcil llançar l'intèrpret i tener tantes consoles com volguem. Aquí els Linux sobresurten i veureu que es una eina molt potent de programació.
Si a més hi posam Django ens trobam que necessitam llançar el servidor i veure'n les traces així que necessitam una consola addicional que és convenient que estigui visible mentre anam fent els canvis i les proves. Per aquí ja podeu veure el perquè dels dos monitors de vint polzades. Així en una pantalla podem tenir l'editor que facem servir (ara hi aniré a això) i a l'altra podem tenir la consola del servidor, el navegador i alguna consola addicional per anar culetjant.
Del navegador supòs que no farà falta dir que per desenvolupar res millor que el Firefox amb les extensions del Firebug i el Web Developer, veritat?
Passem doncs a l'editor. Personalment l'elecció de l'editor té a veure amb l'ús que n'he de fer a la sessió de treball. Si la previsió és que desenvoluparé una bon grapat d'hores faig servir Eclipse amb el plugin PyDev a la pantalla d'edició, l'altra com us dic, queda reservada pel navegador i la consola de Django. Si sols he de fer petites modificacions o vull provar alguna cosa l'elecció principal és el vim i sovint faig servir el Kate, ja que té un afegitó que permet executar, sí ho heu adivinat, una consola.
Idependentment de l'editor que a cada un li vagi millor, és molt útil manejar-se mínimament amb el vi/vim, ja que ens permetrà fer modificacions ràpides als servidors de producció, modificacions que s'hauran d'integra dins el sistema de control de versions (SCM), que tot val a dir-ho és imprescindible i ha de formar part del nostre entorn de desenvolupament. L'elecció del sistema de control de codi depèn també de les preferències personals de cada un, però per començar no és una mala elecció anar cap el subversion, ja que hi ha interfícies gràfiques força ben fetes que ens ajudaran en la tasca, un parell de plugins d'eclipse i una linea de comandaments prou potent que ens permetran treballar amb el sistema de control de versions sigui quina sigui la nostra elecció d'editor, tanmateix sols es cosa d'obrir una consola.
El millor IDE per mi no és un programa, és la combinació de programari, maquinari i millors pràctiques que fan que la nostra experiència de programació en Python i Django sigui productiva i divertida, sense perdre mai de vista la potència que ens dona la línia de comandes. Si en el teu projecte Python depens de les facilitats que te dona un editor determinat per a escriure codi, segur que estàs fent quelcom malament.
0 comentaris, 0 trackbacks (URL)
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
onAIR2008
Escrit per Aaloy a 02 de April , 2008 a les 7:49 p.m.
El dilluns vaig anar a la presentació de l'onairtour d'Adobe, on es presentava la tecnologia air i flex mitjançant un bon grapat de conferències.
L'organització va estar força bé, el comentari que ho resumeix seria el de "he estado en bodas peores" (en madrileny a l'original), ja que cada dues conferències hi havia sessió de tapeo.
De la part tecnològica doncs un sabor agredolç. Per una part una tecnologia que no saps ben bé si és oberta o tancada, si serà realment multiplataforma de bon de veres o sols lligada a uns sistemes operatius concrets, i per l'altra tens el veure que per certes aplicacions el que es presentava tenia moltes possibilitats.
La idea en sí és bona i crec que Adobe ha fet un bon ús de les possibilitats de webkit. El problema és que ja sabem com les gasta aquesta empresa i jo sóc un bon exemple, ja que no hi ha visor de flash per Linux PPC, així que per molt interessant que em paregui la tecnologia ara per ara ni és del tot lliure ni és totalment multiplataforma.
Per una altra banda, les APIs pel que digueren encara estan força verdes, amb molts canvis d'una versió a un altre.
La idea d'Adobe és que la gent pugui aprofitar els seus coneixements de Javascript per fer aplicacions d'escriptori i fins i tot fer aplicacions que puguin fer feina desconectats de la web i això mateix és el que pretén també Google amb Gears, així que ens esperen temps interessant en aquesta tecnologia.
El problema que hi veig en tot això és que s'està tornant a reinventant la roda. Ara el cool és fer aplicacions d'escriptori programant amb Javascript. Què voleu que us digui, si tenc que fer una aplicació d'escriptori multiplataforma ara per ara pegaré a Python i les pyQt o les wx. Si a més la vull per web, doncs ja n'hem de parlar un poc més, però no crec que l'objectiu final sigui fer aplicacions client-servidor en Javascript.
Aquest tipus de tecnologia segur que té grans avantatges si la teva aplicació ha de permetre't poder fer feina desconnectat de la web. L'emperò és que cada vegada la gent viu connectada i no desconnectada, de manera que la necessitat de tecnologies d'aquest estil cada vegada serà menor.
L'altra "novetat" és que air ens permetrà accedir directament a la màquina de l'usuari, se suposa que amb totes les precaucions (signat de certificats - pagant clar). Coneixent l'usuari mig, que no llegeix els diàlegs i es limita al "siguiente-siguiente", doncs supòs que d'aquí poquet podrem veure els primers virus escrits en javascript per air.
En definitiva, una presentació molt bona, una organització excel·lent, unes cadires que te deixaven el cul que no sabies si era teu i una tecnologia que té coses bones, però que ara per ara no me mereix prou confiança com per a recomenar-la.
0 comentaris, 0 trackbacks (URL)
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
Eleccions 2008
Escrit per Aaloy a 26 de February , 2008 a les 11:13 p.m.
En aquest blog no és habitual que parli de política, però crec que en aquesta ocasió s'ho mereix: per primera vegada les forces nacionalistes de les illes s'han unit per conformar una coalició amb el nom d'Unitat per les Illes, que com a capdavanter presenten un dels millors oradors i polítics que ha donat aquesta terra: Pere Sampol.
Ahir vaig anar a sentir a Pere a Binissalem. El seu discurs és entenidor i clar. Proposa una cosa ben clara: fer que les illes tenguin una veu pròpia, que la gent conegui la nostra realitat. Personalment estic cansat de veure com es gasten mil·lionades a la Península en grans construccions i infraestructures quan aquí no hi ha manera de fer que el tren arribi a Alcúdia, que Binissalem tengui una escola pública com cal i no les aules prefabricades que hi ha ara.
A les Illes patim un expol·li fiscal que en Pere fa molt de temps que denuncia. A cap senador de les Illes se l'havia sentit mai defensar les Illes i fer conèixer els nostres problemes. Pere en pocs mesos ha fet un bon grapat d'intervencions, i a ben segur que si entra al Congrés les coses per la nostra comunitat poden començar a anar bé.
Crec en el vot útil, i per mi votar PP o PSOE no ho són, senzillament perquè les persones que suposadament ens han de representar estan subjectes a disciplina de vot i han de fer no el que és millor per nosaltres, sinó el que és millor pels seus partits. El vot útil pot ser el d'un partit minoritari que pot ser clau a l'hora de negociar uns pressuposts o una investidura, i que tal volta pot capgirar el tradicional expol·li fiscal que vivim des de fa dècades.
Dins la meva postura de vot útil, també hi ha una qüestió molt pràctica, a Pere és molt fàcil arribar-hi, és una persona molt accesible. La darrera vegada que vaig parlar amb ell vaig poder-li fer arribar de primera mà el que pens damunt el cannon digital, l'SGAE i els drets d'autor mals entesos. Es va comprometre a fer una proposició al respecte i confio que la podrà fer com a congresista en lloc de com a senador.
Vet aquí la meva postura, en un temps en que la política estatal no il·lusiona l'opció d'Unitat representa per mi una oportunitat de que les coses canviïn com no l'hem tinguda mai, i al manco per mi es mereixerà el petit esforç d'atracar-me al col·legi electoral.
M'han fet arribar una presentació amb les dades que va donar Pere Sampol al meeting, pos l'enllaç per si algú n'està interessat.
0 comentaris, 0 trackbacks (URL)
No adivinis, mesura
Escrit per Aaloy a 24 de February , 2008 a les 5:58 p.m.
A l'hora de fer estimacions de projectes una de les regles bàsiques que hi ha és que si existeix algun tipus de dada mesurable és millor això que res, i que és millor tenir una dada objectiva i reproduïble que tirar d'arts adivinatòries.
Això és aplicable també a altres àmbits de la programació: en lloc de dir "aquest algoritme crec que millora el rendiment" mesurem els seus efectes abans i després, sols d'aquesta manera podrem avaluar objectivament les millores que tenim.
En lloc de dir "el rendiment en producció serà millor", comprovem-ho, agafem-ne mostres i facem extrapolacions. Comprovem els canvis que feim quan posem cachés, optimitzam la base de dades, augmentam la memòria del sistema i documentem-ho tot.
La informàtica és una ciència i com a tal les afirmacions si no són demostrables i reproduïbles sols tenen sols el valor que els vulgui atribuir cada un segons la solvència de la persona que les fa. Si les afirmacions van acompanyades de mesures i dades, ja no és cosa de creure o no, és cosa de comprovar. Potser per això a tots ens agraden tant els benchmarks.
1 comentari, 0 trackbacks (URL) , Tags: Gestió de projectes
Decàleg: com desmoralitzar un equip tècnic
Escrit per Aaloy a 14 de February , 2008 a les 1:14 a.m.
Vols desmoralitzar un equip? No saps com fer-ho? T'explicam com, és molt fàcil
- Fes una pujada de sous ridícula i insultant. Justifica-la dient que els pressuposts no es poden canviar. Millor si ho fas el mateix dia que dius que l'empresa ha tingut uns beneficis extraordinaris, molt per damunt del pressupostat.
- Fes una borsa única per la pujada ridícula del punt anterior que se repartirà en proporció inversa al sou que s'està cobrant actualment. No tenguis en consideració que potser hi ha gent junior que ha de fer un canvi salarial d'escala. Si és així, el canvi salarial també sortirà de la borsa.
- Condiciona la pujada salarial no a la competència sinó al que ja s'està cobrant, de manera que la gent sàpiga que el sou no depèn de la competència professional, sinó del que cobren la resta de companys. A més té el factor motivador de fer que es vegi a la gent junior com a amenaces, ja que normalment comencen cobrant menys.
- Deixa ben clar que la única manera d'aconseguir no perdre poder adquisitiu cada any és marxar o canviar de categoria laboral. Això té l'avantatge de potenciar el principi de Peter i fer que la gent arribi el més aviat possible al seu màxim nivell d'incompetència, però a més té altres conseqüències no menys interessants:
- Donat que en una escala jeràrquica el nombre de llocs més especialitzats es va reduint, la única manera d'aconseguir mantenir o millorar el poder adquisitiu és que el cap immediatament superior renuncii o el facin fora. Per tant, els subordinats han de tractar per tot els mitjans de putejar els seus caps.
- Per tal d'evitar que els subordinats el facin fora, el millor que pot fer el cap és rodejar-se de subordinats sense iniciativa, llepaculs i incompetents, de manera que el cap sempre destaqui. Les noves contractacions de personal i promocions professionals fes que vagin en aquesta línia.
- La gent que no vulgui entrar en el joc acabarà marxant, i per tant sols quedarà a l'empresa un perfil homogeni de gent que entén de què va la cosa.
- Diguès que s'acomiadarà molta gent en breu. La gent que tengui més possibilitats de col·locar-se a altres llocs anirà fugint i l'empresa es quedarà amb tots aquells que tenen més problemes per trobar feina. D'aquesta manera el més probable és que et quedis en una posició ideal per a assolir el punt 4 i les seves conseqüències.
- Contracta quant més consultors externs millor a preus ridículament alts per a que facin la feina de la gent que se n'ha anat per mor de l'augment de sou. Demostraràs que ningú és imprescindible i a més faràs befa dels que quedin.
- Posa al teu equip fites impossibles. Després contracta a empreses externes pel projecte dient-les que facin el que puguin.
- Negocia contractes de manteniment absurdament inflats amb els teus proveïdors. Després tanca el negoci d'aquell departament amb l'excusa de que no hi ha beneficis.
- Exigeix resultats però no donis les eines per a aconseguir-los i deixa ben clar que mai es tindran.
- Explica a tothom que ets el salvador de l'empresa i que els altres tenen molta sort de tenir-te. Fes-los sentir que viuen permanentment en una història de Dilbert.
Desmotivar gent que fa una feina vocacional no és fàcil, esperam que aquests senzills consells us siguin d'utilitat.
4 comentaris, 0 trackbacks (URL) , Tags: Conyes marineres
Integració contínua
Escrit per Aaloy a 10 de February , 2008 a les 5:50 p.m.
Recentment he estat fent un poc de recerca per veure com podia aplicar els conceptes d'integració contínua als nostres projectes. El conjunt d'aplicacions que tenim ha anat creixent al llarg del temps i les dependències entre les llibreries i les aplicacions també ho ha fet.
La idea de la integració contínua és que hi ha un mecanisme automàtic que recull les actualitzacions dels diferents repositoris de control de versions que es tenguin i aplica els tests d'unitat per comprovar que tot funcioni i que els tets passen. D'aquesta manera, i si s'han fet els tests, podem minimitzar l'impacte d'un canvi d'una llibreria en les aplicacions, és a dir, si pel que sigui canviam una llibreria i els canvis impacten a una aplicació de manera no prevista, quan construïm l'aplicació no passarà els tests.
El programari d'integració contínua permet seguir els tests, treure'n estadístiques i veure manera integrada què és el que ha fallat o comprovar que tot ha anat bé. A més es pot utilitzar el programari per a la construcció de l'aplicació i el seu desplegament als entorns de proves. Fet i fet, aquest tipus de coses es poden fer molt bé amb scripts i ens asseguram que en tot moment tenim la nostra aplicació a punt.
En entorns on hi ha molta gent, la integració continua garanteix que si algú "peta" l'aplicació amb commit que no passa els tests, aquest fet es descobrirà prest i es podrà minimitzar el seu impacte. La majoria de sistemes que he avaluat a més permeten a més dels tests unitaris, passar tests al codi font per intentar detectar errors, veure que se segueixen les regles d'estil, etc.
Per a les meves necessitats volia que el sistema d'integració contínua fos capaç de fer feina amb Java (la majoria ho compleixen) però que a més pogués passar els tests de Python i que en general pogués fer des de la construcció de l'aplicació, passar els tests i fer-ne el desplegament.
El que més m'ha agradat per ara és un sistema anomenat Hudson. Hudson és una aplicació recent, feta en Java, fàcil de desplegar i de fer anar. La interfície està molt cuidada i té tot el que necessit per començar. A més hi ha un article de com fer la integració per Python, que m'ha anat molt bé per començar.
Hi ha moltes més alternatives, a mi Hudson me va molt bé perquè té tot el que necessit per aquesta etapa del desenvolupament i és prou extensible com per a que pugui cobrir les nostres necessitats del futur proper. Hi ha altres sistemes a on triar, la gent de Confluence n'ha fet una taula comparativa. Mirau i comparau, però si teniu les mateixes necessitas que jo, no deixeu de fer una ullada al Hudson.
0 comentaris, 0 trackbacks (URL) , Tags: Java Gestió de projectes
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.
- 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
Winpdb
Escrit per Aaloy a 27 de January , 2008 a les 11:15 a.m.
Winpdb és un depurador en mode consola i gràfic per aplicacions Python.. Fa un parell de setmanes que han alliberat una nova versió. En la seva part gràfica, el programa presenta una interfície clara i permet la depuració remota de les aplicacions.
Es pot utilitzar per depurar scripts de Python molt fàcilment sols executant el programa passant-hi com a paràmetre l'script a depurar, tal com se fa amb el depurador estàndard de Python.
La vertadera potència, però està en la facilitat en que es poden depurar aplicacions remotes o aplicacions com les que es poden fer en Django per exemple. En a quest cas afegint aquesa línia al que vulguem depurar
import rpdb2
rpdb2.start_embedded_debugger_interactive_password('clau de seguretat')
ens permetrà connectar-hi el depurador.
Winpdb fa temps que roda, però és la primera vegada que puc fer anar la depuració remota sense problemes. Una eina més a afegir a la capça de programació.
0 comentaris, 0 trackbacks (URL) , Tags: Python
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

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
La pesca del salmón en Yemen
Escrit per Aaloy a 27 de December , 2007 a les 11:32 a.m.
Entre lectura informàtica i programació aquestes vacances he mirat de trobar un grapat d'hores per a la lectura lleugera. En aquest cas d'un llibre que vaig comanar del Circulo de lectores
La pesca del salmón en Yemen
Paul Torday
Ed. Circulo de Lectores
Traducció: Luis Murillo Font
El llibre és amable de llegir, cautivador en alguns aspectes i proper a la crua realitat política actual en altres. Tracta de la consecució d'impossibles, com la de la introducció de la pesca del salmó a un país com el Yemen. Té aquell puntet filosòfic que et fa pensar, però poc més. És un relat ben embastat, construït a base de cartes, e-mail i escrits al diari personal del protagonista, la qual cosa ens atraca als seus pensaments més profunds.
El llibre no m'ha desagradat, però de cap manera es pot publicitar com a satiric o humorístic. Es deixa lleigir i a cops et fa reflexionar. Una lectura per anar llegint en els interminables talls publicitaris que hi ha aquestes festes.
Si el trobau a una biblioteca o us ho deixen es pot llegir, però no en puc recomanar la compra.
2 comentaris, 0 trackbacks (URL) , Tags: Llibres i revistes
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