Des del planet de Python he arribat al blog de S. Lott damunt arquitectura de programari i a un article anomenat PL/SQL vs Java - Yet Again. En aquest post Lott va tractant els llocs comuns que ens trobam quan comparam tecnologies com Java i PL/SQL. En faig una traducció lliure:

• PL/SQL és més ràpid perquè està més proper a la BD. Fals. No ens ho hem de creure, el que hem de fer és mesurar-ho. Segons Lott una de les causes de Java pugui ser més ràpid que el PL és que la màquina virtual Java pot fer optimitzacions al vol (JIT) cosa que PL no pot fer.
• PL/SQL vs JDBC.El PL/SQL és molt bo quan sols hem de fer transaccions bàsiques CRUD, però quan l'algoritme té altra tipus de lògica l'avantatge s'esvaeix.
• Escalabilitat. Java és molt més escalable a un cost menor. Amb GNU/Linux traient partit dels processadors moderns multi-nucli afegir més nivells de concurrència a les nostres aplicacions és relativament barat.
• No tenc recursos Java o presupost per comprar més màquines, però ja he pagat per la BD i tenc gent que sap PL/SQL. Si la direcció d'IT diu que (1) el rendiment és important i (2) no es volen fer mesures de rendiment (benchmarchs) llavors tenim un problema important d'esquizofrènia. Si al responsable d'IT no li importa el rendiment, llavors per què fer proves de rendiment per començar? Si el rendiment no importa PL/SQL està bé. És lleig i mal de mantenir, però és una decisió del responsable d'IT. Bàsicament ve a dir, que si el responsable de programació selecciona un llenguatge no basant-se en el rendiment i la mantenibilitat sinó en altres consideracions, llavors està fotut, no hi ha res a fer: PL/SQL.

No el conec de res a Lott, però pareix que sovint a les empreses es donen el mateix tipus de problemes, deu ser cosa de la globalització. :)

Que no cony! Mira que ho sou malpensats! Aquest post va de llibres concretament de dos llibres de ciència ficció, "La paja en el ojo de dios" y "La sombra del Gigante", que he llegit aquests darrers dies aprofitant un període de vacances i el bono-regal de l'empresa per a comprar coses a un coneguts grans magatzems. La Paja en el ojo de Dios. Larry Niven/ Jerry Pournelle Ed. Minotauro - 3ª Edició 547 pàgines de ciència ficció dura. Descriu el primer contacte de la civilització humana (una civilització constituïda en imperi) amb una raça alienígena. Les noveles de Niven es caracteritzen per una descripció detallada dels escenaris i situacions i un gran component tecnològic. La novel·la és difícil de resumir sense fer malbé la trama una vegada anam més allà del concepte de primer contacte, així que no diré més. És curiós com la societat humana es presenta com un Imperi dominat per la noblesa i els militars, situació que ja ens trobam a altres novel·les de ciència ficció com Dune de Frank Herbert, llevat que en el cas de Niven la societat encara conserva un component important de democràcia. Pareix que per molts escriptors de ciència ficció l'organització militar o militarista està lligada a la expansió de la raça humana per l'univers, vegeu per exemple La Guerra Interminable de Joe Haldeman o StarShip Tropers de Robert A. Heinlen. Cada una en el seu estil però amb un concepte de fons semblant: el militarisme com a forma d'organització social. La lectura de la novel·la engantxa des de les primeres planes. Molt recomanable pels aficionats a la ciència ficció més clàssica. La Sombra del Gigante Orson Scott Card Serie Nova - Ediciones B 353 pàgines. A diferència de la novel·la anterior el component científic de la novel·la és molt menor, però per compensar-ho la part de descripció de personatges, les seves motivacions i realcions, els aspectes més humans es tracten de manera magistral. El títol fa preveure que ens trobarem davant les aventures de Bean, un geni comparable al d'Ender, però així com avança la novel·la es pot veure com aquesta tracta realment d'una altre personatge també molt present en les novel·les de la sèrie, Peter Wiggin, el germà gran d'Ender i en com aquest esdevé Hegemon. Amb un component sentimental i lagrimogen alt, la novel·la és fantàstica i a l'alçada de les millors de Card.

Davant els problemes que darrerament m'està donant la gent de Livehost finalment he començat el camí de migració des del servidor basat en Cpanel que ofereix Livehost cap a un servidor virtual. El primer pas de la migració ha estat el domini trespams, blog, correu i altres herbes. Per ara pareix que tot va bé i que el canvi de servidor no ha estat traumàtic. En principi sols esper problemes en algunes comptes de correu d'amics, de les quals no tenc les claus i que hauré de contactar per donar-los accés al seu correu. El nou servidor no té Cpanel, és un sistema complet per ell mateix, sols que amb poc disc i memòria limitada, però en el qual podem administrar tot el que hi ha. La configuració de correu i usuaris està centralitzada a un servidor LDAP. La gestió de la migració l'he d'agrair a Bernat Cabezas, gràcies a ell i al seu bon fer, en poques hores es va poder fer el canvi i treure'm el capell davant el muntatge que ha fet amb els servidors virtuals.

De la wikipedia:

Escalabilidad: En telecomunicaciones y en ingeniería informática, la escalabilidad es la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad para, o bien manejar el crecimiento continuo de trabajo de manera fluida, o bien para estar preparado para hacerse más grande sin perder calidad en los servicios ofrecidos.

Quan hom posa en marxa un negoci o una aplicació on-line l'escalabilitat és un dels principals factors a tenir en compte. El creixement pot ser molt ràpid si tenim èxit, i el poder créixer al mateix ritme que ho fan els nostres clients o visitants és fonamental. L'escalabilitat, però es sol entendre com que afegint més màquines i més ampla de banda ja està tot arreglat. No és així, a més de l'escalabilitat del ferro, hem de parlar de l'escalabilitat econòmica, determinar abans de triar una solució si a més de ser escalable en hardware és escalable econòmicament. L'escalabilitat econòmica ve determinada per les restriccions que tengui l'aplicatiu. Algunes empreses ens venen aplicacions amb un nivell d'entrada molt baix, però amb versions ultra-mega-enterprise  a les que hem de passar una vegada necessitem un nombre major de processadors, d'usuaris, de volum de dades, etc. En altres casos la limitació ve donada per afegitons al producte, indispensables per una organització en creixement, i que per a funcionar necessiten de la versió enterprise del producte. Si aquesta pràctica ja era greu quan parlàvem d'aplicacions de gestió clàssiques, on més o manco es pot controlar el creixement, és un punt crític a considerar en aplicacions orientades a Internet. D'un dia a l'altra ens podem trobar presoners del nostre proveïdor: bé perquè els servidors nous ja duen més cores i la llicència va per processador, bé perquè el nombre d'usuaris ha anat augmentant considerablemente, però amb un volum de vendes que no compensa passar a la versió enterprise de cap de les maneres. Així doncs, quan consideran l'escalabilitat econòmica, la projecció de la despesa futura, a més de tan sols la possibilitat d'escalar posant més màquines, veurem que el programari privatiu poques vegades és realment escalable. Tenir autèntica escalabilitat significa sols haver-se de preocupar de posar més màquines i algú que les administri i no haver-se d'hipotecar el futur, el programari lliure hi té molt amb dir a això: podem triar distribucions GNU/Linux per exemple que ens permetran ser realment escalables, ja que el cost sols vindrà determinat pel que val el servei i el ferro. Suposem però que estam fent una aplicació per la nostra empresa, o que ens dedicam a la programació d'aplicacions. En aquest cas hem de mirar també l'escalabilitat del desenvolupament. És a dir, la possibilitat de que el rendiment cresqui de manera gairebé lineal amb el creixemnt de l'equip de programació. En aquest cas són les eines de desenvolupament les que ens han de permetre ser escalables i fer que sigui possible que el treball es pugui distribuir fàcilment entre els components de l'equip. L'arquitectura en capes: sistemes, capa de presentació, negoci, persistència, base de dades ens permet distribuir la feina en equips  especialitzats sempre que les eines de desenvolupament ens ho permetin, tant des de el punt de vista econòmic com des del punt de vista funcional. Per exemple, de la capa de presentació normalment se n'encarregarà un equip de disseny, això vol dir que el llenguatge de plantilles que tengui la nostra aplicació de desenvolupament ha de permetre als dissenyadors fer la seva feina sense preocupar-se massa del llenguatge de programació, o millor i tot, sense haver de programar. Per la resta de capes hem de tenir mecanismes de control de versions que ens permetin gestionar fàcilment els conflictes, però sobretot, hem de permetre que aquests conflictes puguin existir. Si algú pot bloquejar l'edició d'un arxiu per fer un canvi mínim, és temps que es perd quan potser hi ha tota la reste de l'equip aturat per aquest canvi. Una altra vegada més, la capacitat de tenir un entorn de desenvolupament escalable ens ve donada per defecte en moltes eines de programació i bastiments que trobam al programari lliure, precisament perquè les eines han estat concebudes per encabir-hi un gran volum de gent fent feina a l'hora i evitar que una sola persona pugui bloquejar la feina dels altres. Així doncs, la propera vegada que algú ens parli de l'escalabilitat de la seva aplicació, podem demanar-li en quin sentit és escalable, quan ens diguin que l'eina de programació permet treball en grup investiguem si compleix els requisits bàsics del desenvolupament escalable. Les solucions privatives gairebé mai són realment escalables, part del seu negoci es basa precisament en que no ho siguin.

I va venir N'Stallman a Mallorca a fer una conferència, i la sala va quedar petita, i el vam escoltar i el temps se'ns va fer curt. Moltes preguntes quedaren sense fer, car la sala, ja prou refredada (ella i nosaltres, tot val a dir) tancava a les deu. N'Stallman tenia calor, potser pel fet de no tenir les seves coses i no poder-nos fer la seva representació, i jo també hi era... Va ser una llàstima no tenir gairebé temps per anar fent preguntes. Poques vegades hem vist una claretat d'idees com les d'aquest home. Un pot pensar que el tema de les conferències ja s'ho té molt preparat, però el que a mi em va impressionar és la contundència de les respostes a les preguntes de l'auditori. Les seves respostes són curtes, però en poques paraules expliquen conceptes que no donen lloc a dobles interpretacions. N'Stallman ens va fer riure amb les seves ocurrències, però per damunt de tot ens vol fer pensar, pensar en les persones, en l'ètica. En com l'ètica que aplicam a altres conceptes de la nostra vida també és aplicable al programari, en com n'és de diferent l'utilitarisme de la cerca del bé comú i perdurable. Diguem-ho: GNU/Linux - Gràcies Stallman!

Si RAD són les sigles de Ràpid Application Development, llavors RWAD són les de Ràpid Web Application Development. Normalment les primeres sigles es refereixen al tècniques i programes que permeten desenvolupar aplicacions d'escriptori de manera que sigui molt més ràpid desenvolupar aplicacions del que es feia abans de que existissin aquests productes. Llavors RWAD és el mateix aplicat a les aplicacions web, se suposa, no? Doncs realment no. No es pot parlar al manco encara, d'aplicacions que permetin fer un desenvolupament ràpid d'aplicacions web si entenem com aplicació web una que tengui una interfície del mateix nivell de qualitat gràfica que les aplicacions d'escriptori, senzillament perquè la part gràfica és una de les característiques que distingeixen les aplicacions web, i un factor diferenciador entre ofertes de productes o aplicacions que d'altra manera serien semblants. A les aplicacions d'escriptori interessa que tot estigui molt ben integrat amb el funcionament de l'escriptori, que tota la interfície sigui estàndard, a la web interessa atreure el visitant, proporcionar una informació o una funcionalitat com la de la competència, però millorada per la part gràfica i la usabilitat del lloc. No es pot parlar ara per ara de programes que permetin fer aplicacions RAD per la web en el sentit que es fa per les aplicacions d'escriptori, es pot parlar de bastiments que acceleren el desenvolupament i sobre tot es pot parlar de tècniques de desenvolupament RAD. I una d'aquestes tècniques és la divisió del treball, la paralelització i l'especialització, arribant, con gairebé sempre que es parla d'optimitzacions del treball, al factor de primer ordre que hi ha : les persones. Que a una mateixa persona conflueixin les habilitat de ser un gran dissenyador, maquetador css, programador javascript, programador en el llenguatge del bastiment elegit, DBA i administrador de sistemes és força complicat, i encara que en trobàssim algun o una dotzena, ens trobaríem perdria gran part del seu temps productiu passant d'un rol a un altre, acabant amb tota esperança de desenvolupament RAD per la web. Desenvolupar aplicacions web de manera ràpida, passa per tenir bones eines i un bon bastiment de programació que ens faciliti les coses, però sobretot passa per tenir un equip compensat de gent que ens permeti paralelitzar el desenvolupament, fent que cada un es pugui dedicar al que fa millor. Tenir un equip de gent: dissenyadors, programadors, gent de sistemes, equip legal fins i tot, no augmenta el temps de desenvolupament global més que el necessari per dur la coordinació de l'equip, i si parlam d'equips de 4 o 5 persones la coordinació és prou ràpida i senzilla [1], amb la qual cosa la suma total en hores-home és pràcticament la mateixa que la que tendríem en el cas de que fos una única persona que ho fes tot, sols que en el primer cas cada part de de l'aplicació web podria estar cuidada a un nivell de detall que difícilment podrem aconseguir d'altra manera. RWAD significa: forma el millor equip que puguis pagar. [1] Aquests tipus d'equips s'anomenen sovint equips SWAT per la seva especialització i eficàcia.

Doncs això, que m'he baixat la darrera versió del JDK de ca'n IBM. Encara pareix que és una Beta, però amb un poc de sort esper que arregli alguns problemes que hi ha amb PPC, sobretot en el que fa referència a la velocitat d'execució.

He vist que hi havia la versió PPC 64 bits, però com les altres vegades hi ha que conformar-se amb la versió de 32.

Quan surt una nova versió de la màquina virtual sempre tenc la tendència a provar-la a casa amb el PPC, l'Eclipse és un entorn de desenvolupament pesat com ell sol, però es fantàstic com a IDE i la integració amb Python amb el PyDev és molt bona. El problema que m'he trobat fins ara és que l'Eclipse damunt el PPC falla, i falla mot, es tanca, i això fa que es perdi feina feta que no compensa les facilitats de l'IDE.

Per coses particular he optat per programar amb Django, un bastiment de programació web de gran qualitat, que té com una de les seves grans virtuts que la informació que dóna damunt els errors és molt exhaustiva. Això fa que si l'IDE peta, els avantatges de tenir depurador i control de versions integrat es perden davant la fiabilitat d'un Kdevelop i la línea de comandes del subversion.

El Kdevelop en teoria integra un plugin de subversion, però és mooolt dolent i té poca funcionalitat. El gran avantatge del plugin per Eclipse que faig servir, el subversive, és que és molt complet, està molt integrat a l'IDE i a l'hora de resoldre conflictes entre versions pot cridar automàticament al comparador gràfic de fitxers.

Li donaré una altra oportunitat a l'Eclipse, l'he estat fent servir durant més de 15 minuts seguits i encara no s'ha tancat inesperadament, tot un èxit!

Un dels problemes que tenim els tècnics és que no estam acostumats a negociar, a parlar en públic ni a guanyar-nos la vida endolçant conceptes i fent metàfores empresarials. Per això sovint ens trobam amb que hem acceptat plaços d'entrega impossibles, treball extra per un programa que no estava pressupostat, etc. Davant gent que està acostumada a negociar per guanyar-se la vida, sempre partim en desavantatge i cal saber-ho. Si un sap o estan les seves debilitats i les fortaleses de l'altra pot orientar millor la seva estratègia de negociació per tal de no veure's sorprès pel poder de convicció de l'altra part.

Arrel d'una presentació d'estratègia que ens varen fer fa poc, vaig tenir la idea d'anar recollint algunes frases que allà s'havien dit i d'altres que he anat escoltant al llarg de la meva carrera professional i intentar explicar-ne el sentit:

• Falta profesionalidad. La culpa del que passa no és de la direcció sinó dels altres. Aquesta expressió sempre exclou al qui la diu i és el que més és pareix a dir, en un llenguatge políticament correcte, que tothom és un inútil llevat del qui diu la frase, que està per damunt del bé i del mal.
• Espero que seais profesionales. S'espera que es treballi més hores, amb menys recursos i sense cap tipus de compensació. Fixem-nos que el concepte és diferent quan ho diu un futbolista quan se'n va a un altre club, que diu que és un profesional, va allà on paguen més i que farà la feina el millor que pot i sap.
• Habrá que hacer un sobreesfuerzo. Vol dir que l'empresa vol que faceu més hores extres però que no les pensa pagar. Si les volgués pagar o compensar aquesta frase s'acaba amb un "que será debidamente compensado". En aquest cas la contesta ha d'anar en termes de "jo sóc un professional i no puc fer feina gratis". O en termes semblants que indiquin que un sols fa feina gratis per ONGs i organitzacions semblants que ho necessiten.
• La fusión implica aprovechar las sinergias entre las dos empresas. Implica que sobrarà gent a curt i mig plaç, però no es pot dir en clar no sigui cosa de que la gent s'ho vegi venir. Hi ha que estar amb l'orella posada i interpretar les accions dels propers dies a partir del significat real de la frase.
• Hay que salir bien en la foto. Traducció: el més important no és l'empresa sinó salvar el meu propi cul, així que faré tots els esforços possibles per fer punts davant els qui comanden.
• Esto es crítico para el negocio. Si és crític avui vol dir que no se va fer una bona planificació ahir. S'intenta arreglar la cagada posant pressió damunt altres bandes per tal que quan algú demani responsabilitats es pugui dir que la culpa és d'un altre.
• Es un término de escuela de negocio. Dit a una presentació es tradueix en un "he cursat un master a una escola de negoci i vosaltres no", però també té altres implicacions, "he cursat un master i vosaltres no, al master jo tampoc vaig entendre què volia dir, així que no ho sé explicar, però en tot cas la frase queda molt bé a la presentació i per això l'he posada".
• Los del departamento X son todos unos inútiles. Dit per algú que té responsabilitat damunt el departament X i del departament del qui escolta, implica un intent fer fer-se "el coleguilla" i mantenir a la gent dividida, de manera que uns no parlin amb els altres, no sia cosa que posant les notes en comú és descobresqui qui és el vertader inútil. Convé informar-se per altres vies del funcionament de l'altra departament. La primera aproximació s'ha de fer a través d'un tercer, ja que el més normal que aquesta mateixa persona hagi fet la mateixa afirmació damunt nosaltres al departament X.
• Nos hemos comprometido a tener X en Y días. He venut la moto a algú, dient que tenim llesta una cosa que no tenim i ara he de salvar la cara, però ara ja és cosa que ho faci un altre. Sol anar junt amb la frase de "es crítico para el negocio" i no anar acompanyat d'un pla de negoci ni de xifres que indiquin que el que s'està demanant sigui factible o econòmicament rendible. Sol ser una conseqüència de l'estratègia de "salir en la foto". En aquest cas la contesta ha de ser per escrit i amb la planificació de quan pot ser possible. La resposta de que "ens hi posam ara mateix" s'ha d'evitar. Millor un "deixa-m'ho pensar i te diré per quan ho podem tenir" seguit d'un petit estudi del que es demana.
• Dejadlo todo y ... També conseqüència de l'estratègia de sortir a la foto. Se tradueix en que la feina que se demanarà a continuació s'ha de fer de manera immediata prioritzant-la damunt la resta, i que després se demanaran responsabilitats per no haver fet l'altra feina. Hi ha que anar especialment alerta si qui ho diu no ho vol posar per escrit, ja que les possibilitats de que aquesta frase amagui un "brown traspassing" augmenten exponencialment amb el nombre de negatives a posar la petició per escrit.

Segur que més d'un es sentirà identificat amb aquestes frases. No s'apliquen exclusivament a la informàtica, però els informàtics i tècnics en general tenim tendència a ser objectius i estam en desavantatge davant gent que és dedica fonamentalment a tancar tractes, d'aquí que conèixer les expressions habituals i saber-ne les conseqüències ens pot ajudar a mantenir la perspectiva necessària per no caure en el parany. Sobretot convé malfiar-se de plans de negoci que sols tenen una presentació, en Power Point per suposat, que les sustenti i on la responsabilitat de l'èxit o fracàs del negoci depengui fonamentalment dels tècnics informàtics. Si això passa estam novament davant una estratègia del "sortir a la foto" i que la tasca que es vol dur a terme té moltes possibilitat de no tenir èxit i es cercarà algun cap de turc per a justificar-ho. Després del tot al Power Point quedava molt clar, no?

A l'espera de l'aeroport em va entrar fam. Els de Tuifly ens van donar un val de 4.5 € com a compensació per les tres hores de retràs per gastar-ho dins l'aeroport, així que vaig anar al bar de la sala d'espera a comprar un entrepà. Feien mengera, de gairebé un pam, farcits de formatge, tomàtiga i enciam. Vaig suposar que amb el val no en tindria ni per començar, però no, no arribà als 4 Euros, el que sí va ser força cara va ser un botellí d'aigua que gairebé costà tant com el propi entrepà. Total 6,20 euros. Amb el canvi a l'euro una cosa que s'ha guanyat és que  les comparacions són automàtiques. Un entrepà semblant o pitjor a l'aeroport d'aquí no baixa dels 8 euros, i sis euros és el que et cosa un entrepà de cuixot i una beguda a un bar qualsevol, ja ni en parlem dels bars de costa. No m'estranya en absolut que cada cop el turista faci menys despesa a les Illes. Si els surt més car menjar per aquí que fer-ho al seu país!  Peti a qui peti tots sabem que la conversió a l'euro ha suposat un arrodoniment a l'alça brutal de preus, potser no el primers mesos, però després tothom va anar augmentant els preus de mala manera.  Aquest sobrecost no tan sols ho paguen el turistes, ho pagam tots els que vivim a aquesta illa. No sé a quins preus s'estan venent les nits d'hotel a Mallorca actualment, però el que sí és segur és que l'oferta complementaria no acompanya a que Mallorca sigui un destí turístic competitiu. Jugam amb l'inestabilitat política de destins més barats i amb que estam molt aprop dels destins emissors, però ens hem convertit en un destí que viu "de fer l'agost" tot l'any, això sí, sense discriminar ningú, es cobra igual de car al d'aquí que al de fora. La fusió dels TTOO junt amb una possible estabilització de destins com Turquia, Marroc o Tuníssia pot comportar que els noviments massius de turistes es poguin desplaçar ràpidament cap a altres destins. Supòs que els hotelers en són ben conscients d'això, però encara veig el sector hoteler mallorquí molt poc orientat cap a la cerca d'alternatives, com podrien ser la  comercialització directa per la web o als bancs de llits. Això per una banda és bo, ja que significa que a curt i mig termini hi haurà feina per als programadors, però és dolent pel que significa tenir que anar a la carrera. L'augment de feina pot anar bé. Amb la fusió que viu/viurà la companyia ningú sap massa bé com acabarà la cosa. Com vaig comentar a un altre apunt no em fan por els canvis, però tampoc m'agrada ser-ne espectador passiu. M'estim més anticipar-me, tenir un pla B. En aquests moments el meu pla B se'n diu APSL, per ara és sols un projecte que està començant, però prou engrescador com per a anar alimentant-ho a veure en què es converteix. Però això és mereixerà un post per ell sol, ja en parlarem!