Avui he anat a unes conferències organitzades per la gent de Garrigues de Mallorca. Llevat de les dones que hi havia i d'un company, en Miquel, especialista en fiscal, me pareix tota la resta amb "traque i corbata". No hi ha res a dir d'això, però m'ha fet gràcia. :) La conferències que més m'han interessat anaven de d'alguns aspectes de la fiscalitat aplicada al comerç electrònic i la conferència de Fernando Martínez damunt la LOPD. En Fernando és una persona amb la qual fa molt bon fer feina. Hem fet temes plegats de la LOPD i he de dir que quan estava cercant empreses que ens fessin la cobertura legal, ell i la seva gent van ser els únics que ens digueren les coses tal com són. La resta el primer que feien era intentar asustar-te amb les multes que te caurien i venent-se com a salvadors de l'empresa. No, no citaré noms, però si estau ficats en temes de LOPD i LSSI us recomanaria primer llegir-vos la llei i després si necessitau algú que us recolzi sempres podreu destriar millor qui coneix de què va i qui us vol "vendre la moto". D'aquests darrer, quan jo ho vaig estar mirant, n'hi havia molts... De tant en tant algú em demana perquè m'interessen els temes legals com la LOPD, la LSSI, les llicències, els aspectes comptables.... Jo no en sóc cap expert d'aquests temes, d'uns en sé més que d'altres perquè trob que ha de ser així. Avui en dia fer aplicacions orientades al comerç electrònic a Espanya o a la Unió Europea, implica conèixer tota una sèrie de disposicions legals que et poden condicionar la manera de treballar. Saber quan s'ha de fer una acceptació explícita d'una condició o no implica tenir que posar un checkbox a la pàgina. Si l'acceptació ha de ser explícita no val tenir-ho marcat. La llei et condiciona també on han d'apareixer les condicions legals, la informació mínima que has de publicar de l'empresa que té la pàgina de comerç electrònic, els passos que has de seguir per poder operar d'acord amb la Llei. Alguns pensareu que això no és estrictament informàtica. Jo trob que sí. De la mateixa manera que hem de coneixer els requisits funcionals del negoci hem de ser capaços de conèixer i reconèixer els requisits legals que la nostra aplicació web ha de complir. Aquests requisit quan parlam de lleis com la LOPD i la LSSI, per exemple afecten prou a temes tècnics com per a que sigui necessari tenir-en un bon coneixement. Segurament necessitarem gent com amb Fernando per a que ens doni una mà amb els temes més fotus de la Llei, o per que ens redacti les disposicions legals, però la feina de saber que la llei és allà i s'ha de complir també és nostra, després ja sols és qüestió de temps i presupost.

Matas compra un palacio de más de 800 millones de pesetas, l'enllaç l'he trobat via menéame. Segur segur, que hi ha una explicació ben lògica per a tot això. El sou de ministre i el de president de la Comunitat ben invertits i amb una política d'estalvi auster i bones inversions fan miracles. O potser una hipoteca a 40 anys?

No estaria de més que si la notícia és veritat el President ens explicàs la seva recepta per l'èxit. D'aquí no res de ministre d'economia. Espera, aquest home no era ítim de Zaplana, aquell que va dir que estava en política per enriquir-se?

Res, que això del reportatge de TV3 m'ha deixat molt tocat. Ja desconfio fins i tot d'aquests dos bons prohomes.

Al proper apunt ....Parlarem d'informàtica!

Acab de veure el 30' dedicat a Eivissa i fa fredat el que expliquen. Per una banda com s'està actuant per tal de desnonar a la gent de casa seva, amb l'excusa d'una obra que no necessita l'illa, per l'altra l'actitud de Matutes i familia davant la feta, diguent que la gent que es manifesta és violenta i que es majoritàriament vinguda de fora. Al reportatge es mostra com Matutes aprofita la terra que es lleva als legítims propietaris per dur-la a un camp de golf de la seva propietat i s'entreveu l'alt grau d'especulació que amaga la maniobra: camps de golf, accessos a ports esportius, a discoteques,... Pareix que s'està repetint la mateixa manera de fer dels anys seixanta amb Mallorca, manera de fer que ha donat lloc fins a tot a un concepte "la balearització", com a símbol de la construcció sense eima, l'especulació i la destrucció del territori. Per acabar-ho de rematar les obres es paguen amb el que se'n diu "peatge a l'hombra", és a dir, que els constructors rebran durant 25 anys una quantitat equivalent a la que haurien de cobrar si l'autopista fos de peatge. És a dir, que s'està hipotecant de mala manera el pressupost de l'Illa. Aquest hipotecar el futur pot donar lloc a una maniobra de tipus piramidal, on es tenguin que urbanitzar més zones, construïr més ports esportius, etc per sanejar l'economia i tenir ingressos per poder fer més obres. La construcció d'aquestes autopistes pareix que sols són el començament... Potser no però, d'aquí no res hi ha eleccions, veurem quina serà la memòria dels electors d'aquí uns mesos. Per cert, segons es llegeix a Eivissa Confidencial  un repetidor de TV3 a l'illa duu més de 24 hores sense funcionar, per la qual cosa molta gent s'haurà quedat a Eivissa fora veure el reportatge.

En Benjamí al seu blog ha feta una entrada d'aquestes que agreixes que sigui diumenge per tenir tot el temps d'assaborir-la i pair-la com cal. Quan he anat llegint l'apunt i les diferents classificacions no he diexat de pensar en el que m'envolta, en l'entorn més proper: la feina, la família, els amics i veure com es classifiquen perfectament dins una de les categories que esmenta Benjamí. Sovint les mateixes persones a distints àmbits tenen classificacions diferents. Gent que defensa la llibertat d'expressió, d'idees, d'identitat sovint ho fa fent servir formats privatius, la qual cosa no deixa de ser una contradicció. Potser l'apunt de Benjamí, si els ho feim arribar, els obrirà els ulls. El programari lliure a les empreses és, baix el meu punt de vista una necessitat. Necessitat de tenir un suport independent del fabricant, necessitat de decidir quan i com s'actualitza, necessitat de ser propietari de l'informació. El cas dels ERPs propietaris que Benjamí també esmenta al seu apunt és especialment sagnant: pagues per la base de dades, per la llicència de l'ERP, per la personalització i quan el fabricant decideix que la teva versió ja no "està soportada" [1] doncs a començar de bell nou la roda, això sí, sota el mantell d'actualizació. La qual cosa vol dir que les llicències seran ara més barates però que et costarà el doble en personalitzacions. I això si tens sort i les teves dades no volen en el procés. Un apunt totalment recomanable. Sols una única cosa, no us conformeu en llegir-ho, recomanau-lo també als vostres amics i coneguts! -- [1] Soportada o sofrida, segons se miri :)

Una de les característiques que més m'agraden del Trac és la possibilitat de tancar tickets i tasques que tenguem definides sols posant una paraula i el número de ticket o tasca quan feim la integració dels canvis a subversion. Per exemple un comentari del tipus: "Corregit l'error xxxx. Closes #3". A més d'integrar els nostres canvis dins subversion tancaria el ticket número 3. A més si navegam pels canvis de subversion (dins el mateix Trac) ens apareixerà un enllaç cap al ticket, de manera que podem navegar des de subversion al ticket. Com que els comentaris apareixen també a la llista de canvis realitzats també podem fer la navegació des d'aquesta pantalla. Activar aquesta opció no està gaire documentat, d'aquí que per a enrecordar-me per la propera vegada, i per si serveix a algú més, aquí el teniu:

• Cercam l'arxiu trac-post-commit-hook.gz . A debian el tenc a /usr/share/doc/trac/contrib. El descomprimirem al directori que més ens agradi i a l'unic arxiu que conté trac-post-commit-hook li dorarem el mateixos permisos d'execució que tengui l'usuari http.
• Anam al repositori subversion, ens situam al repositori del nostre projecte i anam al directori hooks. Reanomenarem el fitxer post-commit.tmpl com a post-commit i li donam també permisos d'execució per l'usuari de subversion.
• Editam aquest arxiu, de manera que després dels comentaris quedi:

  REPOS="$1"
  REV="$2"
  LOG=`/usr/bin/svnlook log -r $REV $REPOS` AUTHOR=`/usr/bin/svnlook author -r $REV $REPOS`
  TRAC_ENV='/somewhere/trac/project/'
  TRAC_URL='http://trac.mysite.com/project/'
  /usr/bin/python /usr/local/src/trac/contrib/trac-post-commit-hook
  -p "$TRAC_ENV"
  -r "$REV"
  -u "$AUTHOR"
  -m "$LOG"
  -s "$TRAC_URL"

Això està documentat a l'arxiu python que hem descomprimit fa una estona. A TRAC_ENV hi posarem el directori on hi ha el nostre projecte trac, a TRAC_URL la URL del projecte i en lloc de

/usr/local/src/trac/contrib/trac-post-commit-hook

escriurem la ruta allà on hem posat l'arxiu.Això és tot. Que ho disfruteu!

Amb aquest títol comença una oferta de feina de l'empresa IN2 apareguda a Infojobs els 16-06-06. Aquesta gent cerca 15 titulats o gent a punt de titular-se, amb un bon expedient acadèmic i amb prou coneixements de Java, J2EE, J2SE i BBDD relacionals com per poder seguir un curs avançat de programació de 250 hores.

Així com avança l'anunci la cosa es comença a desbaratar:

Primer faran una preselecció per veure qui pot anar al curs i qui no. Això no és cap mala cosa en sí mateixa. Si es cerca gent que pugui seguir el curs, es lògic que vulguin garantir-se de que ja es té un cert nivell i que el curs podrà avançar amb prou rapidesa.

La cosa està en que el curs va, pareix, del 15 de septembre al 30 d'octubre. Mala cosa per la gent que estigui al darrer curs de carrera, ja que segurament es perdrà el començament del curs. El pitjor però és que es tracta d'un curs gratuito y no remunerado. I que després de superar l'examen final, als millors se'ls contractarà per un any a l'empresa amb un sou, segons diu a l'oferta, de 12.000 € bruts a l'any. És a dir, que una vegada descomptem imposts no quaran uns 800 euros nets al més (en 14 pagues).

Donat que hi ha un procés de selecció previ, se suposa que el curs hauria d'entrar ja dins el període de prova de l'empresa i per tant hauria de ser remunerat. És el més normal, ja que d'aquesta manera volen estalviar-se els sous que haurien de pagar si ja contractàssin el personal que superàs la primera selecció. La contractació inicial granteix a més que la majoria dels que segueixin el curs quedaran a l'empresa (al manco en aquest país) i fent que el període de prova coincideixi amb el curs, suposa que l'empresa no tindria despeses per acomiadar la gent que no cumplís les espectatives.

El que fan amb aquesta oferta és dir que necessiten gent, però que no volen pagar-la, y que no tenen un depertament de selecció prou bo, per poder destriar la gent que els interessa a la prova inicial. No sé si és això el que volien transmetre, però així ho interpret jo.

També puc fer-ne una altra interpretació: necessiten gent, però no saben exactament quanta, el client no s'acaba de decidir, però si es decideix no tindran mans per assumir el projecte. Això vol dir fer una inversió mínima, i aquesta passa per tenir ja la gent seleccionada i formada i després ja veurem. Sempre se'ls pot dir que no han passat l'examen final i la inversió s'haurà limitat a les hores del formador. Un risc controla. Bo per l'empresa però no tant pel treballador.

L'altra cosa que us podeu imaginar que m'ha sobtat és el sou que volen pagar. Volen gent mig formada, amb bon expedient, que vulgui invertir dos mesos de la seva vida en un curs per veure si després pot guanyar 800 Eur al més. No sé què pensareu vosaltres, però una cosa i l'altra no lliguen massa. La gent formada i ben preparada és prou capaç de trobar feines de més de 800 Eur al més el primer any, i més en les tecnologies que demanen. El perfil de gent que demana IN2 correspon també a gent prou bona per ser capaç si cal d'autoformar-se en les tecnologies que demana IN2. La veritat és que m'ha sobtat el poc que valoren els seus futurs empleats, i més quan l'empresa es defineix com "una Ingeniería de Desarrollo de Software, Formada por Ingenieros para dar soluciones de Ingeniería."

IN2 com a empresa privada que és pot fer el que vol, pot oferir el que vulgui com a sou, i potser hi haurà gent que hi anirà a veure què tal, però personalment si hagués de contractar la gent que ha acceptat la feina m'ho pensaria molt. Em preocupa que una persona capaç i ben formada es valori tan poc a sí mateixa, em dona a entendre que hi ha alguna cosa que no acaba de funcionar, que no lliga.

Ei! Si voleu fer un curs gratuït, potser us interessarà! Personalment jo ja no invertiria massa en Struts, convé conéixer-lo i dedicar-hi unes setmanes, però després ja aniria cap a Spring i el seu MVC. La potència i flexibilitat que dona és molt superior a Struts. És un bastiment que agafant la filosofia del primer ha intentat (i al meu veure ha aconseguit) eliminar els majors emperons d'Struts.

Vosaltres mateixos...

Via meneame he vist aquest post que fa referència al que cobren les consultores.

Llegit a una llista de correu de Linux i PPC: [...] I guess, its like this: Windows OS, Mac OS, are like BBS's, and Linux is like the Open Internet... which one are you going to dial into ??? ...The future is for Open Source. [...] Una bona comparació, si l'enteneu vol dir que ja teniu una edat :)

Sovint en alguns llocs dedicats al programari s'anuncia una nova versió de tal o qual empresa diguent que "la companyia X ha alliberat la versió y.zt" per després trobar-nos que és un producte totalment privatiu. La llibertat entesa també pels programes, per mi significa que són lliures també de deixar qui els ha fet per convertir-se en part de la comunitat de programari lliure. En cas contrari aquest presumpte alliberament no és tal. Supòs que a ningú se li acudiria anuniar un nou model de cotxe diguient que el fabricant ha "alliberat" el cotxe, i això que en aquest cas, el propietaris del cotxe segur que tindran molta més llibertat de fer el que vulguin amb el que han comprat que no els qui comprin un programa privatiu. Alliberam programes quan els feim lliures.

A la llista de discussió de Django hi ha un fil força interessant anomenat Ajax support, there is no need for reinventing the wheel. La cosa va de si és necessari que hi hagi una llibreria d'Ajax dins del bastiment o no. Qui inicia el fil és partidari de que sí, de que hi hauria de ser, i que es podria copiar el que ja hi ha a altres bastiments, com Ruby per exemple, tot i que algunes opnions consideren que la implementació de RoR és un poc nyap, ja que facilita un disseny pobre de l'aplicació. Particularment me pareix que l'opció més assenyada és la de no fer la integració amb un bastiment determinat, començar amb un disseny de l'aplicació clàssic, accessible per tots els navegadors, i després anar incorporant les característiques d'usabilitat basades en AJAX, DHTML, fulles d'estil, etc. que millorin l'experiència als nostres usuaris. En el fons d'aquest fil, però, hi ha dos conceptes, dues preguntes, que podriem tractar per separat

• Davant les noves tecnologies, els nous corrents de pensament en pogramació, quin hem de triar?
• La programació web s'ha d'assemblar cada cop més a la programació de client gruixat, on hi ha components que ho encapsulen tot? Es a dir, encapsular HTML+css+javascript+connexió al servidor és el futur?

La primera pregunta ve de la por a equivocar-se, de triar una opció que després no sigui la majoritària. Davant això hem de recordar que el millor que té la web és que el llenguatge no importa, la tecnologia que hi ha darrera no importa, el que importa és el que veu l'usuari final i la compatibilitat que tengui la nostra aplicació amb el màxim nombre de navegadors. Així doncs, que la opció que triem resulti que no és la majoritària no té perquè afectar negativament a la nostra aplicació, sempre que tinguem la capacitat d'evolucionar-la. En aquests moments, la capacitat d'elegir marca el que l'aplicació pugui estar al mercat abans, el time-to-market import molt més que el risc de triar el bastiment o la llibreria incorrecta. El no saber què elegir no ens ha de paralitzar. Es bo triar i remanar, provar distintes opcions i triar aquella que més ens agradi, que més s'adapti al nostre estil de feina o a la filosofia de l'empresa per la qual treballam. En tecnologia no hi ha res segur, i per tant, sempre hi ha el risc que d'aqui un parell de mesos surti quelcom millor que el que hem triat. L'elecció de tecnologies fonamentades en programari lliure minimitza el risc de la tria, ja que sempre tendrem el codi font i aplicar les millor nosaltres mateixos si cal. L'altra punt d'interés és el de l'encapsulació, la componentització de la web. Això és quelcom que la gent que fa portlets de Java fa als portals. El perill és que es perd part de la flexibilitat que ens dona la programació clàssica, i es posa un nivell d'abstracció, que com comenten de RoR pot fomentar les males pràctiques de programació. També s'ha de tenir en compta que a la web, a més d'usabilitat i aplicacions hi ha una part molt important de disseny. Aquesta part, la part de presentació, en la majoria de bastiments actuals està clarament separada de la part de negoci. El dissenyador no té perquè conèixer res més enllà del llenguatge de plantilles que es farà servir, i en tot cas, del nom de les variables que se li passaran i el seu tipus. L'encapsulació d'html+javascript+css dins un component, de manera que es generi tota la part de presentació a partir del component, té però avantatges indubtables per a una empresa. Una vegada establerta l'aparença dessitjada i sempre que no volguem disseny, tendrem un mètode ràpid per a fer aplicacions, de la mateixa manera que es fan al clients gruixats. Estam sacrificant, però la part visual davant la part funcional. Això pot estar bé en entorns empresarials, però limita força la creativitat. Aquesta conversió a model de components ja la podem trobar a alguns bastiments actuals, implementats amb major o menor fortuna i amb diferents graus d'implementació

• Wicket
• Click
• Zk
• Google Web Toolkit
• RoR
• TurboGears
• Echo2

Alguns d'aquests bastiments són impressionants, però tenen el perill de que les nostres aplicacions web s'acabin assemblant totes, encara que això no té perquè ser dolent. Així doncs, hem de tirar cap a la componentització o cap al model actual amb les millores ad-hoc que necessitem. La resposta és: depén. Si us dedicau a fer apliccions web de manera professional i per a diferents clients i aquestes han d'estar accesibles a través d'Internet per un gran públic ara per ara tiraria cap a la no componentització. Si pel contrari feim apliccacions web pel client intern on el públic pràcticament no hi tendrà accés i la uniformitat no és un emperò sinó una virtud, la componentització ens pot estalviar molta feina i fer-nos molt més productius. Si ens atracam per primer cop a la programació web, el model de component ens pot abstreure massa que el que feim al cap i a la fi són pàgines web en HTML , CSS i Javascript, i que encara que tirem per la componentització convé no oblidar-ho. Després haurem de veure si els emperòs del model en els aspectes d'arquitectura del programari i flexibilitat en quant al disseny, són compensats per la major velocitat de programació.

Darrerament m'estic trobant amb la situació de que la gent es sorpren de la qualitat que tenen algunes de les aplicacions que ens podem trobar al programari lliure. I quan dic gent també m'estic referint a mi mateix. De sobte te n'adones de que un programa o utilitat que fa alguns mesos tenia bona pinta ara ja té pràcticament totes les característiques que hom volia. Agafem per exemple alguns dels plugins de desenvolupament  per Firefox, el Dom Inspector, les Web Developer, o el Firebug. Aquestes utilitats han arribat a un nivell de funcionalitat sorprenent en sols uns quants mesos. El millor de tot, però, és que aquesta funcionalitat ve marcada per les necessitats dels usuaris i no per una necessitat comercial. Així no es d'extranyar que quan necessitem quelcom en temes de desenvolupament web, allò que dius "mira, estaria bé poder ..." et trobis que dita funcionalitat ja ha estada incorporada a aquestes eines. El mateix podem dir de programes menys especialitzats. Un amic, en Pep, em comentava el sorprenent que ha estat per ell l'evolució dels CMS com Drupal. D'exemples en podem trobar cada dia, llibreries de programació, l'OpenOffice, cada dia millor, el mateix Firefox, els escriptoris (KDE; Gnome, XFCE,...). Ens trobam que aquests programes són cada dia millors, més avançats que els seus competidors privatius, i per damunt de tot, més orientats a les necessitats dels seus usuaris. En alguns programes l'evolució es tal que és difícil plantejar-se ni per un moment una elecció que no sigui de programari lliure. Els CMS en són un bon exemple d'això, com també ho són l'Apache mateix, l'Squid, els llenguatges de programació per la web, ... El programari lliure per pròpia filosofia es basa en la col·laboració dels seus mateixos usuaris, bé en forma de pegats i millores o bé en forma de sugerències. Els programadors s'escolten als seus usuaris, incorporant les millores no perquè són compercialment atractives, sinó perquè són útils. I és aquesta mateixa utilitat la que fa que més usuaris facin servir el programa i en seguesquin fent aportacions. És un clicle que es realimenta i que explica perquè a la llarga la qualitat percebuda d'un programa lliure que arribi a una massa crítica d'usuaris ha de ser de precís major que la d'un programa privatiu. La pregunta, doncs és quina és la massa crítica d'un programa. Com podem saber si aquell programa anirà evolucionant fins a convertir-se en allò que voldriem. No hi ha una resposta senzilla a això, potser una de les millors seria que donat que tenim el codi font nosaltres mateixos podem contribuïr a que el programa millori, creant així les condicions per arribar a aquesta massa crítica que farà evolucionar exponencialment el programa. Particularment m'agrada fixar-me en les llistes de correu que té el programa, si hi ha accés a CVS o svn la quantitat de commits que es fan, la quantitat de canvis, millores i correccions d'errors, la quantitat de gent que està enviant pegats. I també si el grup de desenvolupament principal fa cas del que diu la gent. Estant a una llista de correu podem veure el fenòmen de la massa criticica quan el nombre de missatges, que passa en pocs dies de dos o tres a vàries desenes al dia. Quan veim aquest fenòmen podem suposar que el programa té futur, que hi ha prou gent interessada en ell com per garantir-ne un desenvolupament futur. Està clar que no hi ha res segur, però en tot cas, sempre ens quedarà el codi font!