Dell no vol que li compri

Escrit per Aaloy a 30 de August , 2006 a les 8:49 p.m.

Fa un parell de setmanes vaig veure que Dell havia renovat el procés de presonalització d'ordinadors a la seva web. Vaig intentar configurar un portàtil però no vaig poder passar de la primera pantalla. Uns errors de javascript fan que sigui totalment inusable des de Firefox, tant a la versió per Power PC de casa com a l'Ubuntu de la feina. No m'ho esperava això de Dell, i el més fotut és que encara no ho han corregit. Mira que costa poc provar les coses amb un parell de navegadors! Potser és que efectivament els números a Can Dell no acaben de sortir i han reduït el presupost de testeig per la web. El que hem preocupa és que si no són capaços de fer una web que funcioni mínimament amb Linux com me'n puc refiar i compar-los un portàtil que vull per a instal·lar-hi Linux? Perden tota confiança. Ara el que encara és més greu és una web d'un conegut TTOO mallorquí que quan hi vas amb Mozilla i Linux t'amola un ActiveXObject is not defined. Aquí hom ja pot veure que si posa ActiveXObject això sols funcionarà a un Windows. No ho entenc!

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

No diguis dois

Escrit per Aaloy a 25 de August , 2006 a les 8:48 p.m.

No diguis dois és el grup on toca el baix habitualment el meu cuyat-pot-ser que és una altra manera de dir que és el tipus que surt amb la meva germana, i al qual tenc amb molt d'apreci.

El dijous vàren tocar a Binissalem, al casal de Ca'n Sabater. Encara que l'apunt soni a nepotisme, m'he decit a fer-ho perquè em va fer molta gràcia la frescura del grup, i com se'n desferen davant un públic l'edat mitjana del qual estava al voltant dels 70 anys.

Tocàren cançons del seu repertori i algunes de manllevades, davant un públic que no té el rock català a un de les seus referents musicals. Personalment he de dir que em va agradar, no els havia sentit cap vegada en directe i m'atreviria a dir que vaig veure alguna de les senyores de la tercera edat moguent els peus. També n'hi hagué alguna que es dormí, tot i la contundència de les guiterres de No diguis dois.

Em sorpreneren dues coses: la frescura del grup, fent acudits a la concurrència i fent honor al seu nom, i que el públic fos majoritàriament de la tercera edat. Aquest públic demostra ser poc selectiu (pel que es veu cada dijous compareixen) i a la vegada demostra que es mobilitzen molt i molt millor que la gent jove. Estan molt més enterats dels saraus que hi ha al poble que la gent a la que suposadament va dirigit el sarau, i a més s'apunten a tot!.

No diguis dois estigueren bé, molt bé. Feren tot el possible per animar al públic, però hem d'entendre que a les padrines tampoc era cosa de treure-les a la pista a fer voltes a ritme de rock. El concert va transcorre durant prop d'hora i mitja i es va animar força quan començaren les improvitzacions: la més celebrada va ser un pas doble d'Osifar, que mesclava ritmes coneguts per la concurrència amb lletres gruixudes i bones d'entendre, seguida per un tango molt pujat de to de Tomeu Penya, i és que el sexe ven a totes les edats! :)

Enhorabona al·lots! Vàreu demostrar el vostre saber fer davant un públic difícil. Esperem que la propera vegada el públic estigui més en consonància amb la vostra música.

0 comentaris, 0 trackbacks (URL)

El món de la programació s’enfonsa: RoR té un forat de seguretat!

Escrit per Aaloy a 13 de August , 2006 a les 10:54 a.m.

Arrel de l'anunci d'un forat de seguretat a Rails aquests dies podem llegir a força blogs comentaris del tipus ja sabia jo que això no podia ser tan bo, o que comparat amb Java encara li queda un llarg camí, que si ja ho deia jo, ...

No hi ha cap bastiment de programació o llenguatge que pugui assegurar que està lliure de forats de seguretat, sols és questió de temps el que es trobin. El que és important és com es tracten aquests forats, en quant de temps es resolen les fallades i com n'és de complexe l'actualització.

El que RoR tengui una forat més o menys greu de seguretat és anecdòtic i esperable en un producte tan tendre, potser haurà decebut a la gent que veia en aquest bastiment "la bala de plata" que solucionaria tots els seus problemes i la fam del món, però això és el seu problema i no el de RoR o de qualsevol altra bastiment de programació. La gent que té tendència a autoenganar-se, a confiar cegament en qualsevol cosa i després sentir-se absoluta i totalment decebuts a les primeres de canvi fa més que mostrar la seva immaduresa.

El que sí ha demostrat aquest fet és que a RoR no hi havia una política de seguretat clara, no tant en el que fa a que els errors es resolguin ràpid, sinó en com es comuniquen aquests errors i de com se'n fa difusió. Això ha servit per a què altres projectes facin introspecció i es demanin si els podria passar també a ells. Django per exemple

ha publicat al seu lloc com es tractaran els assumptes relacionats amb la seguretat. Així doncs, el problema de RoR ha servit perquè altres es demanin si els podria passar a ells i prenguin mesures per a tenir-ho controlat quan passi.

Del que he llegit darrerament damunt el tema l'apunt de TheServerSide és un dels més interessants, ja no pel que diu sinó perquè veus la postura de la gent que està aprofitant aquesta fallada de seguretat per fer-hi sang. I un post molt interessant fet al grup de Django a partir de la fallada de seguretat de RoR intenta explicar el perquè Rails té l'èxit que té encara que no sigui especialment millor que altres bastiments que hi pot haver. Per mi que és un post força inspirat.

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

Death March, d’Edward Yourdon

Escrit per Aaloy a 06 de August , 2006 a les 9:35 p.m.

Un projecte es pot classificar com a Death March quan un dels seus paràmeteres excedeix la norma en com a mínim un 50%, ja sigui en termes de temps, personal o pressupost (50% per davall de la norma en aquest cas) o en funcionalitat (doblant la funcionalitat típica). O amb una altra definició, són projectes on la possibilitat de que falli i no es compleixin els objectius és major que el 50%.

En el llibre Yourdon ens descriu què són aquest tipus de projectes, per què hi ha empreses que s'hi fiquen [1] i per què hi ha caps de projectes disposats a liderar projectes d'aquestes característiques.

Una vegada s'ha assumit que ens hem embarcat en una marxa cap a la mort, Yourdon ens dóna una sèrie de consells per a intentar sobreviure a l'experiència: estratègies de negociació, de com recompensar l'equip, de la importància de no abusar de les hores extres no remunerades, fins i tot de com en aquests tipus de projectes és convenient botar-se la burocràcia inherent a certes empreses si es vol tenir una mínima possibilitat d'èxit.

Yourdon classifica aquests projectes en quatre grans categories, agrupades en quatre quadrants.

En el primer quadrant tenim els projectes Kamikaze. Projects condemnats al fracàs des del principi, però on tothom hi vol participar ja que creu que encara que es fracassi l'experiència pot ser gloriosa.

En el segon quadrant hi situa els projectes que anomena de Missió impossible: projectes on els membres de l'equip estan altament motivats i tenen gran capacitat i han de lluitar contra les forces adverses que volen fer fracassar el projecte.

En el tercer quadrant trobam els projectes Ugly, que podríem traduïr per marró, porqueria o qualsevol lindesa semblant. Són projectes on els membres de l'equip es consideren carn de canó, xais sacrificables per tal d'aconseguir el propòsit (no m'agradaria estar en aquest tipus de projectes).

I en el quart quadrant les projectes suicides, on tothom està condemnat i tothom és miserable, on la gent hi fa feina perquè l'alternativa és ser despatxats, encara que saben que no hi ha cap oportunitat per l'èxit.

Si ens trobam en un projecte Death March és important ser-ne conscients, i quan més aviat millor intentar classificar-ho dins alguna d'aquestes categories. Tots els membres de l'equip convé que siguin conscients de amb quin tipus de projecte s'han embarcat, fer feina en un projecte Kamikaze o de Missió impossible pot ser divertit i potser tindrem possibilitat d'èxit, les altres alternatives sols servixen per guanyar temps i anar actualitzant el currículum.

Yourdon introdueix alguns conceptes que m'han interessat especialment: el concepte de prou bo, que ja apareix en Surviving Object-Oriented Projects d'Alistair Cockburn i que Yourdon desenvolupa al capítol cinc i seguents. El concepte de triage, que podríem traduïr per triatge o priorització, la gestió de l'equip i els diferents perfils que hi podem tenir i fa quatre pinzellades damunt la dinàmica de processos [2] aplicada al desenvolupament de programari, per acabar amb tècniques de priorització del temps i gestió del risc, però en aquest darrer cas sense entrar-hi massa.

El llibre és bastant complet, encara que en alguns temes te deixa en ganes de saber-ne més. La bibliografia i les referències que acompanyen a cada capítol també són molt completes i hi ha un parell de referències que es repeteixen al llarg del llibre: PeopleWare, The Mythical Man-Month i Rise and Resurrection of the American Programmer.

No m'ha agradat, en canvi, el que fa molts capítols: Yourdon fa referència a e-mails que ha rebut dels seuls colegues en resposta a preguntes que ha fet a l'hora d'escriure alguns capítols, fins aquí bé, el que no m'agrada és que al final del capítol escriut tot l'e-mail rebut i moltes vegades és paraula per paraula el que ha dit al capítol. Està molt bé això de donar crèdit a qui ha proporcionat la idea, però ho podria fer en forma de reconeixement, nota al peu de pàgina i amb el text complet de l'e-mail a una plana web i no com a transcripció literal al llibre. Dóna la impresió de que sols està allà per omplir i fer embalum a un llibre que si no fos per això no arribaria a les 180 pàgines. La veritat és que a mi tant em fa si el llibre té 180 o 220 pàgines, l'interés del llibre no es pot midar en pàgines sinó en la qualitat del contingut i crec que en aquest cas es prou bo per no tenr-ho que inflar artificialment.

En llegir aquests tipus de llibres, però, me queda un cert regustet amarg, veig que aquestes tècniques, aquests estudis i classificacions estan molt més extesos als Estats Units que a les nostres contrades. Dels llibres es dedueix que existeix una vertadera especialització en la gestió de projectes i un interés en aprendre'n, en formar equips que funcionin, en entendre les dinàmiques del desenvolupament de projectes de programari. Me pareix que tenc tema per un altre apunt...

---

[1] Politics, politics, politics

[2] Fa ganes de saber-ne més d'això. Pareix prou interessant.

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

El teu llenguatge de programació pot fer això?

Escrit per Aaloy a 03 de August , 2006 a les 12:26 a.m.

Aquesta és la pregunta que fa Joel Spolsky al seu blog. Aquesta pregunta li serveix a Joel per introduïr-nos en la programació funcional.

A més de provocar-nos Joel ens anima a aprendre més coses de la programació funcional, d'aquesta capa d'abstracció addicional que ens permet fer les coses d'una altra manera. En Joel diu que si no fos per aquest tipus d'abstracció Google no seria el que és i aprofita per tonar-se a queixar de les escoles de pensament únic, on sols s'ensenya un llenguatge de programació.

Amb això, com en tantes altres coses, no put estar més d'acord amb Joel. Un sol llenguatge no basta, ens limita a pensar sols en el llenguatge que sabem i no ens permet pensar en termes del problema que volem resoldre. El curs de Ruby al que anàrem fa uns dies anava un poc en aquesta línea: veure com altres llenguatges resolen problemes comuns, veure altres maneres de fer coses ...

En aquests moments el meus dos llenguatges de programació principals són Java i Python. Java ho faig servir per guanyar-me les sopes, Python per divertir-me, per la mateixa raó que escric aquest blog. Així que la contestació a la pregunta de Joel, és sí, Python pot fer això! Si el que diu de Google és cert, i no tenc cap motiu per dubtar-ho, no m'extranya gens que aquesta gent hagi contractat al creador de Python, Guido Van Rossum, ja que des dels començaments la programació funcional ha estat una part important del llenguatge.

#!/usr/bin/python

def alert (s):
        print s

print "pas 1"

alert ("I'd like some Spaggetti!")
alert ("I'd like some Chocolate Moose!")

def SwedishCheff(food):
        alert ("I'd like some %s !" % food)

print "pas 2"

SwedishCheff("Spaghetti")
SwedishCheff("Chocolate Moose")

print "pas 3"

def PutInPot(s):
        alert ("pot "+s)

def BoomBoom(s):
        alert ("boom "+s)

def Cook (i1, i2, f):
        alert ("get the "+ i1)
        f(i1)
        f(i2)

Cook ("lobster", "water", PutInPot)
Cook ("chicken", "coconut", BoomBoom)

print "pas 4"
#Aquí del que es tracat de de definr la funció en línea. 
#Tiram de lambda per això. lamda ens permet definir funcions anònimes
#sempre que el cos sigui una sola expressió.
#El codi javascrip de Joel:

#    Cook( "lobster", 
#          "water", 
#          function(x) { alert("pot " + x); }  );
#    Cook( "chicken", 
#          "coconut", 
#          function(x) { alert("boom " + x); } );

Cook ("lobster", "water", lambda x: alert("pot "+x))
Cook ("chicken", "coconut", lambda x: alert("boom "+x))

print "pas 5 n-----"
# Aquí Joel defineix la funició map. És una construcció
# pròpia de Python. Així que no necessitam ni fer-la
# la sintaxi és map(funcio, llista)

a = [1,2,3]

a= map (lambda x: x*2, a)
map (alert, a)

# Finalment el reduce tampoc no fa falta definir-la ja
# que també és part del llenguatge. 
# de fet podriem fer

suma = lambda x : reduce (lambda i,j : i+j, x)
alert ( suma(a))

b=['a1','b2','c3']
alert( suma(b))

0 comentaris, 0 trackbacks (URL)