PeopleWare és un llibre escrit per Tom DeMarco i Timothy Listener. En Steve McConnell els cita freqüentment al seu llibre Rapid Development, d'aquí que quan vaig veure que havia sortit la segona edició vaig comanar-la. Com que l'he rebut avui sols he tingut temps de fullejar-lo, però per ara el llibre pinta bé. Són una sèrie d'històries que ajuden a la gestió d'equips de programació, de manera que puguin ser més eficients, més productius i a la vegada tenir contenta la gent que els forma (anava a escriure membres contents, però a aquestes hores ...). Darrerament m'ha donat pels llibres d'engenyieria de programari i aquest llibre torb que completarà molt bé els altres que he estat llegint. Tracta de la gent i del equips de gent i més en concret d'un tipus de gent molt concret: els programadors. Les motivacions d'un programador no són les mateixes que les que pot tenir un venedor o un jugador d'un equip de futbol i per tant s'han de tenir en compte si volem formar un bon equip de desenvolupadors. La productivitat d'un projecte es dispara o s'enfonsa sovint gràcies a la gent que forma l'equip del projecte. De tots els factors que poden influir en un projecte és el que té més pes, així que la gestió dels recursos humans en un projecte de programació es converteix en una tasca fonamental. La veritat és que crec que he tengut dos bons mestres en això de la gestió de persones, un m'ha ensenyat com s'han de fer les coses i encara que com tothom es pot equivocar, la manera que té de gestionar els recursos humans és del milloret que he vist. L'altre m'ha ensenyat com no s'han de fer les coses. Encara que mentre ho vius no és agradable, crec que vist en perspectiva es bo tenir una experiència així, ja que t'ajuda a no caure en els seus mateixos errors. De la mateixa manera darrerament he viscut com una empresa externa gestionava un projecte comentent totes les errades de gestió imaginables, se n'aprén moltíssim d'això. No és el mateix que t'ho conti un llibre que això pot passar que veure-ho personalment. L'atra llibre que he rebut és Code Complete, també una segona edició, és d'En Steve McConnell i va de bones pràctiques d'escriptura de codi, des de les estructures de control més bàsiques fins a l'elecció del noms de les variables. Per cert, recomano la lectura de Making Wrong Code Look Wrong a la web de Joel on Software, dóna una molt bona visió del que és la notació Hungaresa i perquè s'ha de fer servir, molt lluny de que potser us han ensenyat pels puestos. Res, idò, tenc lectura per un parell de setmanes.

En els temps dels llenguatges Turbo (Turbo Pasca, Turbo C, Turbo Basic) els programadors estàvem sols. Davant una situació d'enrocament el millor era anar a fer una volta, prendre un cafè, comentar-ho amb els companys i si així encara no es sol·lucionava la cosa millor tornar a començar de nou. Record quan vaig compar una de les meves primeres llibreries de programació. Prometia integrar-se amb el meu llenguatge de programació (aleshores el Turbo Pascal 6.0) i accedir sense problemes als formats de bases de dades més populars. Malhauradament no va ser així, hi havia molts de problemes ja que la llibreria estava pensada per C i no acabava d'anar fina amb Pascal. Imaginau-vos les hores de proves infructuoses sense saber si estava fent quelcom malament o era una errada de la llibreria. Al final desesperat vaig escriure una carta al fabricant que dos mesos després em va enviar un joc de disquets amb la nova versió de la llibreria que arreglava aquell maleït problema. Avui també ens podem trobar amb problemes semblants, però la diferència és que la comunicació és molt més fluïda. Davant una errada d'una llibreria o un programa podem mirar el codi font (jo ja no faig servir llibreries propietàries, gràcies!) o bé anar als cercadors i veure si algú té un problema com el nostre. Podem anar als fòrums i demanar, podem enviar un correu electrònic al desenvolupador,.. Segurament no haurem d'esperar dos mesos a saber alguna cosa del nostre problema, tant si té solució com si no en té. També ha canviat molt el tema de la documentació i l'accés a la informació. Encara que a mi m'agraden els llibres de tota la vida no se m'acudiria de cap de les maneres imprimir-me tota una API d'un parell de centenars de pàgines i tampoc comprar algun llibre que el que fes fos llistar-me aquesta API. Ara un pot obtenir la informació directament de la xarxa, amb un navegador, utilitzar els cercadors per accedir al punt que ens interessa i veure exemples de com algú altre ha utilitzat aquella llibreria. Que vols fer alguna cosa i no saps com fer-la? Google és el teu amic. Segurament trobaràs algú que ho ha fet. En alguns casos potser torbaràs idees de com fer el que vols però no estarà del tot desenvolupat. En aquests casos és bo documentar-ho i posar-ho a la xarxa. Les avantatges d'Internet sols ho són si segueix esssent un entorn lliure i col·laboratiu. La informació està allà perquè algú li ha posada i aquest algú ben bé podem ser nosaltres.

Segurament hi haurà aplicacions que faran servir algunes característiques avançades d'Oracle per funcionar (carregant-se de pas la portabilitat entre base de dades, tot hi ha que dir-ho) o bé amb volums de dades de que necessitin un sistema de fitxers que sols Oracle pugui entendre o manejar. No ho sé, jo encara no m'he trobat cap cas en que la utilització d'Oracle com a base de dades per l'aplicatiu fos una condició indispensable. M'he trobat aplicacions com Compiere lligades a Oracle de mala manera sols perquè les vàren començar així. Segons els desenvolupadors perquè volien estar segurs de tenir suport per a la base de dades :O. Això el que ha fet realment és que Compiere no es pugui convertir en l'standard dels ERP OpenSource: està massa lligat a un producte tancat. Li estariem diguent als nostres clients que encara que pot verure què fa l'aplicació i com ho fa, per les dades sempre serà hoste de la gent d'Oracle i de les seves estratègies de comercialització de producte i llicències. L'altra dia un amic em comentava que el seu cap havia insistit en que una aplicació de BD estigués feta damunt Oracle. Així ho va fer. Mesos més tard realitzaren una aplicació web que accedia a les dades i feren servir les llicències de connexió de client que tenien d'Oracle per permetre tantes connexions simultànees com llicències tenien. Doncs pareix que la llicència no va així, i pel que es veu el comercial d'Oracle de torn els està exigint que paguin la llicència d'Oracle per Web, amb un cos molt per damunt del seu presupost. El millor de tot és que no hi havia cap requisit tècnic que fes que les dades tinguessin que estar damunt Oracle. Un Postgres, MySQL, Firebird, ... anaven sobrats i ara no s'haguéssin trobat amb el cost adicional de les llicències. Tant la gent de Postgres com la de MySQL estan fent molt bona feina i el rendiment de les bases de dades i la seva funcionalitat millora dia a dia. Actualment em trob desenvolupant una aplicació que té a Postgres com a motor de base de dades. Damunt la màquina de proves, un P III amb doble processador a 800 GHz hi tenc carregats ara per ara uns cinc cents mil registres (500.000 heu llegit bé) i en quant tengui una estoneta (cada càrrega de 100.000 registres torba uns 5 minuts) hi posaré la resta de dades i arribaré al mil·lió. Les consultes de selecció, consultes de taules lligades, agrupacions, les insercions i els borrats són pràcticament automàtics. Normalment el coll de botella està en el programa client que ha de processar els registres que li envia la base de dades, però al motor de base de dades sols li faig pessigolles quan faig les càrregues, però la resta d'usuaris del sistema no se n'adona de res. Val a dir que la màquina servidora té un Linux com a sistema operatiu: una Debian, com no podia ser d'altra manera :)

Avui és el segon dia de feina. La tornada no ha estat tan feixuga com jo m'esperava, feia molt de temps que no podia gaudir de quinze dies seguits de vacances i ja havia començat a oblidar els horaris que imposa la feina. A mi m'agrada fer feina de tard: programar, llegir, escriure... Pareix que tot va millor quan no fa sol i no hi ha ningú ja als carrers. De totes maneres anar a fer feina a l'estiu és potser el més semblant a la tranquilitat dels vespres. No hi ha pràcticament ningú a la carretera, l'emboç del polígon no hi és. Avui he torbat sols 20 minuts en arribar a la feina. No està malament comparat amb els 45 minuts que necessit un dia normal. A la feina he començat a fer feina amb les possiblitats que ofereix la nova llibreria de tags per java ajaxtags. La veritat és que és molt bona de fer anar. He adaptar la part de servidor per fer servir struts sense massa problemes. Per ara sols he fet servir la part que permet visualitzar un panell d'informació quan hom fa click damunt un element de la pàgina. Sols té un petit problema: la posició de la pantalla d'ajuda. El disseny de l'aplicatiu que estam fent està fet a base de div i pel que es veu això confón a la llibreria de tags i fa que la posició de presentació de la informació no sigui l'adient. Pareix que ho resolderan en la propera versió. Ara per ara a mi el que hi ha fet em serveix si faig que la informació no desaparegui automàticament de la pantalla. El problema és quan hi ha scroll vertical: l'ajuda surt sempre en la part superior esquerra i això fa que hagis de tornar a pujar per veure què hi ha. L'avantage de totes maneres és que és molt mes ràpid que fer aparèixer un popup per pantalla. L'augment de velocitat és significatiu en el Firefox i no tant amb Konqueror. No sé perquè però Firefox necessita molt més temps per crear un popup que Konqueror. Aquestes vacances he estat rellegint el llibre de McConnell : Rapid Development i tot just arribar a la feina he pogut comprovar com fallava una de les pràctiques que l'autor considera poc recomanables: el "code-like-hell". Tot amanig amb el "Contractor Failure" que està classificat com l'errada clàssica número 15 i com el risk del problemes d'integració es convertia en una relalitat. No oblidem tampoc la mala pràctica número 13, el "Wishful thinking". També he trobat indicis del les errades (1,2,8,12,15,21,23,26,35,36), el projecte mereixeria figurar en els exemples de McConnell i m'estic pensant si convendria enviar-li el cas per si li serveix d'inspiració per a la propera edició de llibre ;). Per cert, us ho recomano de totes totes, tant com us prevenc vers la contractació de certa empresa de dues lletres i un nombre parell pels vostres projectes de programació.

Avui fa deu anys a aquestes hores em vaig casar al pati de l'Ajuntament de Binissalem. La gràcia de tot això és que encara hi estic casat! :) Entre mig dos dels projectes més interessants i que encara estàn en procés: En Toni, quatre anyets ja, i En Jaume que tot just n'ha fet dos. A diferència dels projectes de programari que sovint acaben tard els nostres dos projectes han estan d'allò més puntuals. Fins i tot en el cas d'En Toni hi va haver un avançament de gairebé tres mesos. Això demostra que complir els plaços és important i és convé no quedar-se curt ni passar-se de llarg ;) Ahir En Toniet va descobrir la calculadora, li vaig ensenyar com sumava i ara s'entretén fent sumes i mostrant-me el resultat per saber si és correcte. Encara no se fia massa de la tecnologia.

Avui he llegit al java hispano que s'ha alliberat la versió 1.0 d'AjaxTags, una llibreria de tags per agilitar la creació d'aplicacions que facin ús de la tecnologia Asynchronous JavaScript and XML (AJAX). Darrerament estan sortin moltes coses ralacionades amb aquesta tecnologia, que ha estat present des de ja fa anys al món d'Internet, però que per uns motius o altres no havia acabat d'emergir. Supòs que veure la gent de Google fer vigueries amb el Gmail ha ajudat bastant a que la gent del carrer ens n'adonem de les possibilitats d'aquesta tecnologia. Havia vist algunes coses que proclamaven ser AJAX però eren més relacionades amb la presentació gràfica que amb la presentació de dades i la usabilitat en termes d'aplicacions web. La gràcia d'aquest alliberament d'ajaxtags per mi és l'aspecte qualitatiu dels exemples que han fet. Els han basat no en mostar-nos els vigueries gràfiques que es poden fer, sinó en donar exemples d'aplicacions del dia a dia que es poden beneficiar de la tecnologia. Als exemples hi trobam autocompletat, com oplir camps d'una llista desplegable basant-nos en una selecció anterior, l'actualizació d'un formulari, visualització d'un text associat a un objecte. Són coses que les aplicacions de client gruixat han fet des de ja fa molt de temps, però que resultaven molt costoses de fer, o amb milers de problemes d'incompatibilitat dels navegadors, en aplicatius web. Pels que ja heu passat per l'exemple i volgueu saber-ne més d'aquesta tecnologia aquí teniu un parell d'enllaços molt interessants:

• AjaxTags
• Dynamic HTML and XML: The XMLHttpRequest Object
• How to Develop Web Applications with Ajax, Pt. 1
• DWR - Easy AJAX for Java
• AjaxTags
• AJAX Matters - Asynchronous JavaScript and XML and XMLHTTP development information
• Asynchronous JavaScript Technology and XML (AJAX) With Java 2

I sobretot no deixeu de llegir el que diu la wikipèdia damunt el tema, on a més de la definició i la història del nom trobareu enllaços cap a llibreries Ajax per més adients per altres llenguatges que no siguin el Java.

Avui he començat amb les especificacions de la comptabilitat. He obert un wiki i he començat a redactar les especificacions i crear els diagrames d'anàlis. Crec que la tecnologia està prou madura per permetre fer una aplicació comptable que pugui competir amb rapidesa i agilitat amb les aplicacions client servidors clàssiques. Obviament podrà competir amb les contapluses de torn sense cap problema. Hi ha projectes de comptabilitat lliure ja en el mercat, en un ja hi vaig estar involucrat i ara vull fer-ne un que agafi les idees que he anat recolling al llarg dels anys, tant en projectes personals com a les distintes feines que he fet. A més he d'aprofitar un poc el TFC de la UOC que vaig fer damunt usabilitat en programes comptables. El wiki, un Tikiwiki, se'm resisteix encara una mica. No és tan bo de fer anar com el Mediawiki, però pareix que es un poc més segur. Donat que no hi puc dedicar massa temps a controlar que l'spamer o el capdevafa de torn no facin maldats, he optat per sols donar accés d'escriptura als usuaris registrats. És un projecte de llarg abast, ja que no sé exactament el temps que hi podré dedicar, però la meva intenció és dedicar-hi al manco 8 hores per setmana. Poquet, però suficient com per a que en uns mesos es pugui veure alguna cosa. No sé si als programadors els motivarà o no fer programes comptables, la veritat és que a mi sí que em motiva, ja en vaig fer un en Delphi per SMI Sistemes ja fa un grapat d'anys. Malhauradament aleshores l'Interbase encara no era lliure (ni es deia Firebird) i el programa es va llançar fent servir el motor de bases de dades de Borland. No era ni tan sols una aplicació client/servidor. Tot i això hi vaig poder incorporar idees que encara avui no es poden veure als programes de comptabilitat que hi ha al mercat i que feien les delícies dels comptables que anaven a les demostracions. He decidit fer servir principalment Java i tecnologia J2EE en el projecte ja que darrerament estic tirant cap aquí, i amb un poc de sort esper que les properes versions de la màquina virtual ja seran lliures. Això sí, tant el codi com les llibreries que vull fer servir seran GPL o de codi obert, i obviamnet el programa serà GPL. Fer un programa com el que m'estic proposant durà temps, per accelerar el desenvolupament se necessitaria gent a temps complet que pogués anar picant el codi que aniré dissenyant. Si hom tingués finançament els meus càlculs són que és un projecte que es podria desenvolupar amb uns 200 mil Eur, algú s'anima?, sinó haurem d'anar a poc a poc.

Ahir En Juan Moreno un amic vingut de l'orient llunyà, em va passar un enllaç molt bo Joel on Sofware que ja ha passat a formar part de la meva llista d'enllaços de referència. M'he passat bona part del matí llegint els articles d'aquest web. A part del joc de paràules fàcil, en aquest web hi podem trobar un conjunt d'articles molt instructiu damunt engenyieria de programari, articles que van des de com escriure bones especificacions a com introduïr informes d'errors que realment serveixin per alguna cosa. L'article damunt com reportar errors crec que l'haurien de llegir tots els beta testers i programadors. També és prou instructiu el test de Joel. L'he passat a la feina que faig actualment i en el meu grup arribariem al 7 o potser un sis i mig. La resta segurament no passaria del 2 o del 3, que de totes maneres és el valor mig d'aquest test per la majoria dels departaments de desenvolupament, llevat dels més adelantats. L'objectiu és arribar al 12, així que encara que s'arribi a l'aprovat encara queda molt per fer. El "Just do it" no m'ha anat massa malament i supòs que per això arrib al 7 en el test de Joel, però també té la seva part negativa ja que els vells hàbits són mals de rompre i alguna gent té tendència a veure les innovacions com un atac personal a la seva manera de viure. :(

El regal de la comunicació és un llibre de Sebastià Serrano editat per Ara Llibres, cent vint-i-sis pàgines a doble espai i tipus 12 d'un llibre de butxaca i fàcil lectura. Les idees que exposa Serrano en el llibre són molt interessants, però com ell reconeix als capítols introductoris el llibre és un refrit de la lliço inaugural del curs de la Societat Catalano-Balear de Cures Pal·liatives sobre Comunicació no verbal en cures pal·liatives i això és nota tant en l'estil de l'obra com en moltes de les frases i exemples que posa, molt més orientades a un sector professional concret que a un públic generalista. El problema amb aquest llibre és que en cap punt de la coberta l'editor s'ha molestat en dir que el llibre era la publicació d'una lliçò inaugural, i si algú com jo, s'ha atracat a aquest llibre esperant alguna cosa millor segurament es sentirà defraudat. En definitiva, si un té en compte que és això, una lliço inaugural posada en paper sense massa miraments, el llibre és una lectura vàlida, si hom esperava quelcom més elaborat millor optar per algun dels altres llibres que té publicats Sebastià Serrano. Interessant si t'ho deixen o ho pots manllevar a la biblioteca, però no val els diners gastats.

He acabat de llegir Wilt s'ha perdut de Tom Sharpe, editat per Columna. És una lectura llegurera, ideal per l'estiu i que no té res a veure amb la informàtica. He passat un grapt d'hores divertides encara que el llibre no arriba als nivells de bogeria del primer Wilt o d'altres llibres de Sharpe com vicis ancestrals. El llibre té torços molts bons, en Sharpe és un mestre de l'hipèrbole, de l'humor àcid i sagnat i del politic-incorrectisme. És delirant el retrat que fa del potentat americà i de la seguretat social anglesa, tant que a cops no pots menys que posar-te a riure descontroladament. En aquest llibre el personatge de Wilt passa més a un segon pla i el seu protagonisme es veu eclipsat per les entremeliadures de les bessones i els altres personatges. Tot un seguit d'històries per passar una bona estona. Per cert, no recomanable a menors de 18 anys :)

Aquests dies estat llegint damunt un patró de disseny anomenat Inversió del Control o com l'ha rebatejat Martin Fowler injecció de dependència.

Fowler diu al seu article Inversion of Control Containers and the Dependency Injection pattern que el terme d'inversió de control està mal triat i que la moda dels bastiments de dir que implementen IoC és una obvietat.

Anant d'enllaç a enllat he trobat també altres articles interessants:

• A beginners guide to Dependency Injection
• Definició de IoC que fa Paul Hammant
• Definició de la Wikipèdia

De tot això n'he tret una idea del que és el patró i quan es pot fer servir. No he arribat encara a cap implementació concreta o com integrar-la amb els meus propis desenvolupaments, encara que pel que he estat llegint tant Hivemind com Spring són bons candidats, l'elecció d'un o l'altra dependria de l'arquitectura utilitzada en el projecte i de com es de bona la integració de cada bastiment amb aquesta tecnologia.

Tal com jo ho veig si feim projectes de codi obert trobarem que en molts de casos aquest patró no té massa avantatges damunt un patró Factory, un bon ús de les interfícies i una bona documentació. Té molt de sentit si el que volem és crear una aplicatiu que agafa components de tercers i/o volem crear una aplicació extensible mitjançant pluggins.

Així el concepte de IoC aniria un pas més enllà dels pluggins i de patró Factory, es tracta de que la decisió de com s'implementa una caractarística no la controli directament l'aplicació sinó que es controli en temps d'execució. Això és el que fa, per exemple, Hibernate quan et deixa triar el sistema de caché que vols fer servir tan sols canviant els paràmetres de configuració de l'xml. L'Hivemind o Spring pel que veig segueixen la línea de fer servir arxius de configuració en xml on s'enllacen els serveis i la seva implementació. El PicoContainer fa l'enllaç per codi i per mi perd un poc la gràcia i l'esperit del patró.

Amb les aplicacions que he estat fent darrerament se me n'acud un possible ús d'aqeust patró:

Suposem una aplicació típica on l'usuari s'ha d'autentificar per poden entrar. L'aplicació passa el nom de l'usuari, la clau i el sistema d'autentificació ens diu si l'usuari és vàlid i retorna un conjunt d'informació damunt dit usuari. Aquest sistema d'autentificació és un ferme cantidat a figurar en els arixus de un contenidor d'Injecció de dependència, ja que per exemple podem fer l'autentificació fent servir LDAP, una Base de Dades, consultant a un arxiu de text o bé en les etapes inicial de desenvolupament fent servir un objecte mock per a l'autentificació.

En el tema de l'autentificació existeix el risc que ens n'anodem que hem deixat codificat el sistema d'autentificació incorrecte per l'entorn de producció. Si tenim l'autentificació implementada com a servei bastaria canviar el mapeig del servei i l'aplicatiu estaria ja llest per funcionar.