can Domingo

Un servidor de calendari

2011-11-24T22:23:00.001+01:00

Aquests dies he acabat un afegit a l'aplicació en la que estic treballant: un "mini servidor" de calendari.

La idea és fer accessibles una sèrie d'esdeveniments als usuaris, però no via l'aplicació web, sinó mitjançant el sistema d'agenda que tinguin (Google calendari, iCal, Yahoo, etc.). Per això és pot fer ús de l'estàndard RFC2445 que permet descriure esdeveniments i altres elements en un format entés per tots els sistemes d'agenda.

En el meu cas, he emprat l'eina ical4j. Per no fer massa llarg això, ja ho faré (potser) un altre dia, vaig a mostrar un Servlet d'exemple que publica un calendari amb un sol event:

public class ProvaCalendari extends HttpServlet {

protected void doGet(HttpServletRequest req, HttpServletResponse resp)

throws ServletException, IOException {

Calendar calendar = new Calendar();

PropertyList properties = calendar.getProperties();

properties.add(Version.VERSION_2_0);

properties.add(Method.PUBLISH);

properties.add(new ProdId("-//blog/Calendari//CA"));

properties.add(new XProperty("X-WR-CALNAME", "Event S.A") ); // Exemple de propietat no estàndard

properties.add(new XProperty("X-WR-CALDESC", "Events per tota la família") );

VEvent event = new VEvent();

event.getProperties().add(new Summary("Cinema a la fresca"));

event.getProperties().add(new Uid("id"));

try {

event.getProperties().add(new DtStart(new DateTime("20111128T2200","yyyyMMdd'T'HHmm",null)));

} catch (ParseException e) {

// Fer el tractament

}

event.getProperties().add(new Location("Parc de la mar"));

event.getProperties().add(new Description("The Goonies"));

calendar.getComponents().add(event);

resp.setContentType("text/icalendar");

resp.getWriter().print(calendar);

}

El codi ja ho dic, cerca mostrar un cas més senzill que no pas complet. Un detall important, per exemple, és que s'ha ignorat la qüestió dels "time zones": quan es crea la data és passa null com a paràmetre timezone fent d'aquest un event "flotant". Això vol dir que l'event serà a les 22:00 tant si el client és aquí com a Moscú.

Si fem que aquest Servlet atengui a la petició http://localhost:8080/calendari/ical, ja ens podem subscriure a aquesta adreça com a calendari extern.

Evidentment, al nostre cas, els esdeveniments es consulten d'una base de dades i, per tant, tot el que s'entra mitjançant el backoffice de l'aplicació s'actualitza als calendaris particulars.

Mòbils i altres productes

2011-11-19T21:53:00.001+01:00

Vaig comprar fa molt de temps un HTC Magic. El primer mòbil, crec, que va sortir amb Android. Fa bona feina, però ja fa temps que tenc ganes de canviar-ho. Tres anys (més o manco) donen molt per millorar un producte relativament nou com són els telèfons inteligents.

Així que he estat mirant el que hi ha: els HTC, Googles, els Samsungs, l'iPhone 4S ... I sí, son xulos, però cap m'acaba de convèncer.

El que no m'agrada és que sembla que estan intentant fer tablets en lloc de mòbils: a veure qui fa la pantalla més gran, posa més MHz o més nuclis als processadords etc. En enginyeria quasi sempre afavorir un factor en penalitza un altre i això és encara més cert quan parlem d'un dispositiu tant limitat com és un telèfon mòbil.

Tots aquests avanços en pantalla i capacitat de procés acaben castigant, sobretot, la durada de la bateria i, llavors, altres elements com són la comoditat a l'hora d'emprar-ho (per el pes i el tamany) i l'estabilitat del sistema ( inevitable: més complexe, menys estable ).

Pensant amb alguns dels productes que millor servei me fan, trobo que tenen en comú un disseny molt centrat amb el servei bàsic que han de donar. Per exemple:

Tenc un rellotge casio que és fell de disseny però te tres característiques fonamentals:

L'estructura G-Shock ho fa gairebé irrompible
Els vespres sincronitza l'hora amb una senyal de radio d'un rellotge atòmic alemany
És carrega per energia solar

Tot això fa que sempre, en qualsevol circumstància, tengui sempre l'hora exacta. No he de comprar piles, ni fer el canvi d'hora, ni llevar-ho per nedar, anar alerta amb els cops, ni res. Sempre, sempre funciona.

Segon exemple: la kindle. No és a color, no permet veure vídeos, no té programes interactius etc. Però fa una cosa: permetre llegir llibres. I això ho fa molt bé.

El tercer és el portàtil: un mac air, del que ja vaig parlar a aquí

Cap mòbil ara per ara el veig amb les característiques que comentava abans: centrat amb l'ús principal que en faré d'ell. La meva llista de requeriments és aquesta:

Amb un ús normal, la bateria ha de durar 48 hores
Tamanyi pes semblant el HTC màgic
No s'ha de penjar
Una utilitat que té l'android i no hi vull renunciar: tenir els contactes en un sol lloc.
GPS
Aplicacions bàsiques:

Un bon navegador
Una aplicació d'alarma mínimament intel.ligent que me permeti programar algo tipus: 5:50 de dilluns a divendres. Dissabte i diumenge apagat, per aquests dies ja tenc el menut.
Notificació de mail automàtica
Missatgeria
Calendari

Renunciaria a:

Pantalla gran
Aplicacions sofisticades
Càmara de tropecents megapixels
Video amb HD
Integracions amb facebooks, twitter etc. Per això ja tinc el navegador

Dennis Ritchie

2011-10-16T19:55:00.001+02:00

Si fa uns dies escribia sobre la mort d'Steve Jobs, ara ho hauria de fer el mateix per Dennis Ritchie.

Diré la veritat: me fa molta peresa escriure aquesta entrada. Si me va ser fàcil explicar el que me inspirava Steve Jobs, no sé que que dir de Dennis Ritchie. Les seves aportacions són de tant de calat, que no puc ni contestar a la pregunta: com seria la nostra feina sense la seva aportació i la d'en Ken Thompson?

Només vull anomenar alguns records que me venen al cap dels dies a la universitat. Un llibre de C que me va costar moltíssim (un parell de milers de pesetes) i que vaig llegir i rellegir fins quasi memoritzar-lo. Unes lliçons de com Unix oferia una funcionalitat impresionant a partir d'una sèrie de comandes molt específiques i per si soles senzilles. O com aquest sistema operatiu servia per ilustrar implementacions elegants als problemes més complexes en el disseny de sistemes operatius.

Ja ho dic, necessitaria molt de temps per escriure aquesta entrada així com cal, però només diré:

Descansa en pau Dennis Ritchie i moltes gràcies de part dels que ens dediquem a això.

Sandbox

2011-10-09T22:10:00.001+02:00

La peresa no sempre és dolenta. Ben entesa, millora la qualitat de la nostra feina: simplifiquem el nostre codi, automatitzam coses, evitam duplicats etc. Però normalment la peresa és dolenta.

Un cas freqüent és quan hem d'incorporar una eina nova o poc coneguda al nostre projecte. Pot ser una llibreria nova per generar fitxers amb un determinat format, una utilitat per fer ordenacions, o altres. Sovint el que feim és incorporar-ho al nostre codi i intentar emprar-ho tal com creiem.

Segur que tots ho hem fet alguna vegada. És la millor solució? quasi mai. L'aplicació en la que treballam, per poc complexa que sigui, és molt mal lloc per fer proves d'aprenentatge d'una nova eina. Fer això bé (l'aprenentatge) requereix d'un lloc adient. El millor és dedicar un mínim de temps, que sol ser poquíssim, per construir un entorn en que que fer això: una aplicació tipus "hello world" que serveixi per aquest fi. Ja sigui un mètode main, una nova prova unitària, una aplicació web mínima o el que requereixi el que volem provar.

Quin és el cost de deixar-nos dur per la peresa i no fer-ho?

al final hem perdut temps en lloc de guanyar-lo
la qualitat de l'aprenentatge és pitjor, per el "renou" que suposa treballar amb el sistema real
és difícil que no quedin restes de proves fallides entre el codi definitiu

En definitiva: acabem perdent temps, i baixa la qualitat tant del nostre aprenentatge com del codi que finalment queda al projecte.

Steve Jobs

2011-10-09T22:07:00.000+02:00

Vagi per davant que no soc cap "fan boy" d'Apple. Hi ha coses que no m'agraden i que fan que, per exemple, me decanti abans per un mòbil Android que no per un Iphone. Tot i això, també n'hi ha moltes de coses que m'agraden i un dia com avui és amb el que cal centrar-se.

Tinc un mac air, de 13''. No els de la darrera generació, sinó els de la penúltima. El vaig comprar per desembre de l'any passat i he de dir que ha estat un dels aparells que més satisfet m'ha deixat.

Qué el fa un producte tan encertat ? La meva opinió és:

No té entrada de xarxa: cal un adaptador a usb
No té adaptador per projectors: cal també un adaptador s'usb
No té lector de DVD
No té comandament a distància
Només té dues entrades USB
Només és de 13'
Només té 128 GB

Cada una d'aquestes "característiques" m'ha incordiat en algún moment, però totes elles juntes permeten una experiència única. Tens un ordinador portàtil. Fins aquest moment pensaves que sabies el que era un portàtil, però no. Ara veus els altres i dius: xulo, però no, gràcies.

No soc expert ni en Apple ni en n'Steve Jobs (ni tan sols estic segur d'estar escriguent bé el seu nom). Però aquesta és la lína que me sembla veure als seus productes: capta l'essencial i fes que això sigui el producte.

Aquesta simplicitat no és gens fàcil d'aconseguir. La solució que aconseguim, al manco els que no estem tocats per aquesta genialitat, és complexa. Aquesta complexitat reflecteix el nostre coneixement limitat del que feiem. Només moltes iteracions, intentar desfer, refer, tornar a enrera etc., guanyant nova comprensió en cada pas, ens permet aproparnos a una solució més senzilla i neta. La complexitat mostra ignorància, la simplicitat maestria.

Cercar la simplicitat implica passar de veure una tasca acabada, a veure-la com inacabada. Assumir el risc, l'esforç i el cost de destrossar-la, refer-la i tornar-la a destrossar fins que el resultat ens sigui acceptable. És interioritzar la simplicitat com a valor.

Crec que el millor homenatge és que tots els que ens dediquem a les noves tecnologies facem més nostre el valor de la simplicitat i fer que la seva pèrdua sigui menor.

N programadors i 1 de sistemes

2011-10-02T21:55:00.000+02:00

Aquests darrers dies ha sortit a la feina un tema de discusió: és necessari tenir una persona amb perfil de sistemes al nostre equip?

Per contextualitzar la qüestió: el nostre equip treballa en el desenvolupament i manteniment d'un parell d'aplicacions. Aquestes estan a producció a un centre de dades que duu un altre equip de gent. No ens encarreguem ni dels servidors, ni de la configuració del JBoss, ni de la gestió d'Oracle, ni res d'operacions.

La nostra tasca diària és, per tant, desenvolupar: obrir l'IDE, programar, probar que funciona i enviar al control de versions. Quin lloc té a aquest equip una persona de sistemes? O, dit de forma més amplia: és convenient tenir una persona a l'equip que no tengui com a tasca programar?

Suport a la programació

Imaginem la vida d'un equip de programació sense una eina de control de versions. Cada programador treballa en una part diferent del programa (difícil fer-ho d'una altre manera) i regularment passa el que fa als altres. Aquests ho incorporen al seu projecte local i escriuen la seva part.

Ningú sap bé mai si te la versió correcte, o més ben dit, sap perfectament que no la té. No és possible accedir de forma sistemàtica a l'estat del projecte un parell de dies després. Tampoc podem saber quines son les diferències entre dues versions etc, etc.

Tots aquests problemes es poden resumir en un: falta de control. Escribim el nostre codi, però no tenim un control clar del conjunt de codi del projecte. Comparau aquesta situació amb la d'un projecte amb un control de versions correctament implentat.

Podem accedir exactament a tots els estats per els que ha passat el projecte. Podem controlar exactament que tenim al nostre ordinador i com difereix del que hi ha al repositori. Podem tornar enrera. Etc etc etc.

La importància que té el codi fa que sigui impensable treballar sense el soport d'un control de versions, però: és suficient o aconsellable quedar-nos en el codi? o podem extendre aquest requeriment de control a altres aspectes?

Sense limitar la llibertat dels programadors per emprar l'editor que vulguin (som fort partidari d'això), es possible tenir-ne un com a "preferent" a l'equip. Aquest editor ha de ser configurat per adaptar-ho al nostre entorn, això per cada desenvolupador que l'empri. Com ho feim? com el codi sense control de versions, amb cada usuari tinguent la seva versió independent i intentant parlar entre noltros per tenir-ho igual? o centralitzat i amb el mateix control que tenim sobre el codi?

Quin temps duu i quina fiabilitat té la instalació des de zero de l'IDE en l'ordinador d'un nou membre de l'equip? Si algú troba una millora substancial en una opció de configuració, o un nou plugin: quin és el procés per a que tots els atres ho puguin guadir? Com puc tornar a l'estat anterior si, al cap d'un temps, veiem que no era tan bona idea com semblava?

Si programem una aplicació que s'executarà en un servidor d'aplicacions, probablement interessarà que cada desenvolupador tingui el seu propi servidor d'aplicacions en local. Aquest servidor haurà de ser, fins on sigui possible, el més semblant possible al que hi haurà a producció. Quin tipus de control volem tenir damunt la configuració d'aquests servidors?

Hi ha una tasca important per implantar un sistema de control de configuracions que vagi més enllà del codi font i inclogui totes les eines que afecten a la nostra tasca de programació.

Coneixements complementaris

Crec que hi ha molt poques feines on la formació continua no sigui important. En la major part d'elles, per molt monòtones que semblin, segur que els que hi estan, i les fan amb un respecte cap el seu ofici, poden explicar com ha evolucionat la seva percepció de la feina al llarg del temps. És un aprenentatge continuu. No és, evidentment, una característica exclusiva de la programació, però sens dubte és un dels llocs on més destacada és aquesta necessitat.

El nostre treball és un cicle continuu de aprenentatge i aplicació del que aprenem. Programam, ens topem problemes que no podem resoldre amb el que sabem, invetiguem el tema i incorporam aquests coneixements a la nostra activitat diària. Entre aquestes activitats: programació i (auto)formació, hi ha d'haver un balanç correcte, que cada un de noltres interpretem de forma molt diferent.

N'hi ha que es passen en un sentit: per exemple subordinen la formació a l'activitat i programen sense saber molt bé el que escriuen o quines alternatives hi ha. I n'hi ha que cauen per l'altre costat: és impossible saber-ho tot i no s'atreveixen a escriure res o fan i re-fan continuament.

Per molt partidaris que siguiem de l'autoformació, necessariament ens hem de limitar donat l'abast immens del que podem aprendre i les responsabilitats que tenim. Necessitam establir prioritats i deixar dins les indispensables (el llenguatge de programació que emprem, els bastiments...) i deixar fora les més prescindibles.

Aquesta aritmètica que funciona amb una persona, no té per que aplicar-se igualment a un grup. Si som 10 desenvolupant, ja sí que és rentable i molt que algun d'aquests dediqui temps a aprendre aspectes més de sistemes que poden ajudar a l'equip. Administració bàsica de servidors d'aplicacions, apache, base de dades per tal de poder reproduir el millor possible els entorns de producció o, molt important, per saber interpretar si l'ús que es fa d'aquests recursos és l'òptim.

Llista de responsabilitats

Posats a dedicar una persona a aquest rol, quines serien les seves tasques? Idò entre altres hi hauria:

Implementar un sistema de monitorització a l'aplicació per proporcionar a l'entorn d'operacions informació sobre el seu funcionament
Interpretar les dades obtingudes amb les eines anteriors a l'entorn de producció o de proves
Implementar eines d'integració continua i de control de qualitat
Implementar un sistema de gestió de les eines emprades per els desenvolupadors (IDEs, sistemes de build, servidors locals, etc )
Ocuparse de problemes d'infrastructura: xarxa, sistema operatiu, seguretat etc.
Proporcionar un entorn de proves, automàticament actualitzat amb la darrera versió.
Implementar un sistema de proves a distints nivell: funcionals, d'integració, de rendiment etc.
Introduir els mecanismes per proporcionar feedback automàtic als desenvolupadors amb les conseqüències dels seus darrers canvis
Administrar les eines de suport d'incidències, de control de codi i altres
Formar-se en temes no funcionals com escalabilitat, rendiment, seguretat etc... i orientar als desenvolupadors.

No sé voltros però jo ho veig molt interessant. Algun voluntari?

Hibernate: nombre de resultats i relacions one-to-many

2011-10-02T20:10:00.000+02:00

Anem a tractar amb un exemple senzill alguns dels aspectes d'Hibernate que poden despistar a l'hora de tractar relacions one-to-many (1 a n).

Partim d'un exemple amb dues classes entitat: Casa i Persona. En aquest cas, farem la relación one-to-many de Casa cap a Persona: una casa té n habitants, i cada habitant viu a una sola casa.

Les dades que manejarem són:

A la casa amb adreça a la plaça major viuen n'Aina i en Pere
A la casa amb adreça al carrer major, viu només en Joan

Comancem amb un llistat de les cases que hi ha amb les dades dels habitants precarregades:

name="consulta">

select casa

from Casa casa

left join fetch casa.habitants

query>

Al codi java feim:

List resultat = session.getNamedQuery("consulta").list();

System.out.println ("se han trobat " + resultat.size() + " elements");

for (Casa casa: resultat) {

System.out.println (casa.getAdreca() + " te " + casa.getHabitants().size() + " habitants");

}

En principi podriem esperar que la consulta retornes dos resultats, ja que només hi ha dues cases. Vegem el que diu quan ho executem:

se han trobat 3 elements

Carrer major te 2 habitants

Plaça major te 1 habitants

La llista inclou tres elements, ara bé: les dues primeres són per el mateix objecte Java. És a dir:

System.out.println (resultat.get(0) == resultat.get(1));

Mostra

true

Dit d'una altre manera: la llista té tres elements però només dos objectes casa.

Per entendre el resultat hem de veure el procés mitjançant el qual Hibernate crea la llista de resultats a partir del que hi ha a la base de dades.

La consulta anterior genera un SQL com aquest:

select casa0_.ID as ID1_0_, habitants1_.PER_ID as PER1_0_1_, casa0_.ADRECA as ADRECA1_0_, habitants1_.PER_NOM as PER2_0_1_, habitants1_.CASA as CASA0_1_, habitants1_.CASA as CASA1_0__, habitants1_.PER_ID as PER1_0__

from CASA casa0_ left outer join T_PERSONA habitants1_ on casa0_.ID=habitants1_.CASA

Els resultats de l'SQL seran:

dades casa Carrer major - dades Aina

dades casa Carrer major - dades Pere

dades casa Plaça major - dades Joan

L'origen de les tres files a la llista de resultats està en que són tres les files que retorna la consulta SQL amb el seu format tabular. Tot i això, les regles estrictes d'identitat per la Session d'Hibernate (a una sessió només hi pot haver un objecte amb el mateix id) fan que les dues primeres entrades acabin representades en el mateix objecte.

En aquests casos, ens interesa que la llista de resultats tingui només dos elements (no dupliqui la primera entrada).

Hi ha distintes formes de solucionar-ho.

En casos senzills, com aquest, ens pot servir afegir un distinct a la consulta. Una altra solució habitual és emprar una estructura de dades que elimini els duplicats ( un Set ).

Farem, per exemple:

Collection resultat = new HashSet(session.getNamedQuery("consulta").list());

O, si volem conservar l'ordre dels resultats de l'HQL:

Collection resultat = new LinkedHashSet(session.getNamedQuery("consulta").list());

També podem emprar un ResultTransformer (més habitual als Criteria, però també funciona a l'HQL):

List resultat = session.getNamedQuery("consulta")

.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY).list();

Veiem, per tant, que és un tema a tenir en compte però que se soluciona fàcilment. Hi ha, però, una altra qüestió relacionada amb aquest aspecte que és més delicada.

És una bona pràctica, per protegir l'aplicació, limitar el nombre de resultats que retorna una consulta. Això ens pot salvar de problemes importants si per error o per males intencions d'algun usuari, una consulta retorna un nombre de resultats tan gran que afecta a la disponibilitat del servidor.

Per limitar el nombre de resultats feim:

List resultat = session.getNamedQuery("consulta")

.setMaxResults(10)

.list();

Si executem això trobarem un warning:

WARN org.hibernate.hql.ast.QueryTranslatorImpl - firstResult/maxResults specified with collection fetch; applying in memory!

Aquest és un dels warnings als que s'ha de fer cas !

El problema és que el nombre de resultats és refereix al nombre de cases, mentres que el nombre de files que retorna l'SQL està determinat per el nombre de persones. Per aquest motiu, Hibernate no pot emprar el valor del setMaxResults (10) per limitar via SQL ( numRow ) el nombre de resultats : l'SQL retornarà tots els resultats i només en el procés Java se reduiran a 10 els resultats. Perdem, per tant, el mecanisme de protecció que voliem tenir.

Subversion: -r (revisió operativa) i @ (peg revision)

2011-09-25T12:22:00.000+02:00

Treballant en un projecte guardat al subversion és habitual fer còpies, renombrats etc. I això, en general no ens causa gaires problemes. Anem a analitzar un cas a on una combinació de renombrats i creacions de fitxers o directoris pot crear ambiguetats i, per tant, confusions.

Ens basarem en l'exemple que empra el subversion redbook. Partim d'un repositori nou:

domingo$ svnadmin create repositori

domingo$ svn co file:///Users/domingo/blog/repositori/ wc
Checked out revision 0.

(wc és per working copy, no penseu en altres temes ;-) )

Ara creo un fitxer idea.txt a on plantejo idees preliminars per convertir en un projecte

domingo$ echo 'fer un cercador a internet' > idea.txt

domingo$ svn add idea.txt

A idea.txt

domingo$ svn commit -m "idea per fer un cercador"

Adding idea.txt

Transmitting file data .

Committed revision 1.

Amb el temps, veig la viabilitat del projecte i creo un projecte real. El contingut d'idea.txt passa a ser el contingut del nou projecte:

domingo$ svn mv idea.txt google.txt

A google.txt

D idea.txt

domingo$ svn commit -m "cercador passa de idea a projecte real"

Adding google.txt

Deleting idea.txt

Committed revision 2.

El projecte funciona, tenim centenars de millions d'euros al banc, però això no basta per saciar la nostra fam de projectes nous, així que cream una nova llavor de projecte. Com abans emprem un fitxer idea.txt, ja que ens ha donat sort.

domingo$ echo "fer una web amb missatges dels coneguts" > idea.txt

domingo$ svn add idea.txt

A idea.txt

$ svn commit -m "nova idea: una web social"

Adding idea.txt

Transmitting file data .

Committed revision 3.

És important destacar que per el subversion, l'idea.txt inicial (revisió 1) i aquesta darrera (revisió 3) no estan relacionats.

I ara ve el problema. Suposau que voleu consultar el contingut del fitxer idea.txt que hi havia a la revisió 1 (les idees per crear un cercador a la web) . Un primer intent podria ser:

domingo$ svn cat file:///Users/domingo/blog/repositori/idea.txt -r 1

svn: Unable to find repository location for 'file:///Users/domingo/blog/repositori/idea.txt' in revision 1

Però, com veiem això falla. Subversion ens diu que no pot recuperar el contingut d'idea.txt en la revisió 1 del repositori. Pensau el que hem dit, aquest darrer idea.txt no està relacionat de cap manera amb l'idea.txt que hi havia a la revisió 1. El fitxer idea.txt que hi ha a la darrera versió del repositori té una història curta: es crea a la revisió 3. No té, per tant, revisió 1.

El que volem dir-li al subversion és que ens torni el que hi havia a idea.txt a la revisió 1. Per això podem emprar una altra notació anomanada "peg revision". Ho feim amb :

domingo$ svn cat file:///Users/domingo/blog/repositori/idea.txt@1

fer un cercador a internet

La especificació @ cerca el contingut del repositori a l'ubicació especificada en la revisió , que és el que voliem fer.

Quan empravem -r (s'empra la terminologia revisió operativa), se va a la url especificada a la revisió més recent del repositori, i després es segueix la història cap enrera fins trobar la revisió indicada.

Per exemple:

domingo$ svn cat file:///Users/domingo/blog/repositori/google.txt -r 1

fer un cercador a internet

Aquí ens està mostrant el contigut de google.txt a la revisió 1 i ho fa correctament, encara que a la revisió 1, google.txt no existia amb aquest nom, sinó com idea.txt

query specified join fetching, but the owner of the fetched association was not present in the select list

2011-09-03T19:53:00.000+02:00

Si programau amb Hibernate quasi segur que alguna vegada us heu hagut de berellar amb aquest missatge:

query specified join fetching, but the owner of the fetched association was not present in the select list

Anem a explicar que vol dir aquest missatge, per que ho dona i entés això, la següent part trivial és com resoldre el problema.

Treballarem amb un exemple senzill: només tres entitats, Persona, Casa i Municipi. Una persona viu a una casa que pertany a un municipi. La consulta que volem realitzar és quines son les cases de les persones que tenen un determinat nom. Per les cases retornades, volem que tengin inicialitzat les dades referents al seu municipi. Un primer intent ens podria dur a la següent HQL:

select casa

from Persona persona

join fetch persona.casa casa

join fetch casa.municipi municipi

where persona.nom like :nom

Partim de persona, per aplicar el filtre per nom i després lliguem amb casa i amb municipi per tenir les dades ja carregades. L'execució d'aquesta consulta produeix el següent error:

org.hibernate.QueryException: query specified join fetching, but the owner of the fetched association was not present in the select list [FromElement{explicit,not a collection join,fetch join,fetch non-lazy properties,classAlias=casa,role=null,tableName=CASA,tableAlias=casa1_,origin=T_PERSONA persona0_,columns={persona0_.CASA ,className=domini.Casa}}] [

select casa

from domini.Persona persona

join fetch persona.casa casa

join fetch casa.municipi municipi

where persona.nom like :nom

]

L'errada ens diu que se han proporcionat instruccions de quina informació s'ha de carregar d'un objecte que no forma part de les dades retornades. Anem a veure els dos tipus de joins que hi ha per entendre millor la errada.

La següent secció explica el funcionament dels join fetch. Si ja el coneixeu botau directament a la secció El problema.

Precarregues

El join "normal" (sense fetch) fa un inner join que compleix dues tasques. Quan feim

from Persona persona
join persona.casa

Afegim una condició adicional: els valors retornats formaran o estaran basats en persones i cases que estan relacionades. Aquest filtre descarta cases o persones sense cap relació.
Defineix l'espai de dades sobre el que definir el que retornem (per exemple l'adreça de la casa, el nom de la persona ....) o els filtres que podem aplicar (per exemple, que les persones tenguin un determinat nom).

Si executem:

select persona

from Persona persona

join persona.casa

L'SQL generat és:

select persona0_.PER_ID as PER1_0_, persona0_.PER_NOM as PER2_0_, persona0_.CASA as CASA0_ from T_PERSONA persona0_

inner join CASA casa1_ on persona0_.CASA=casa1_.ID

Suposem que volem retornar persones (com feim), però a més volem disposar de les dades de les cases de cada persona. La forma de indicar-ho al HQL és ampliar la consulta indicant que s'han de carregar les dades de la casa associada a cada persona. Fer-ho és només afegir la paraula fetch al join:

select persona

from Persona persona

join fetch persona.casa

Ara l'SQL generat és:

select persona0_.PER_ID as PER1_0_0_, casa1_.ID as ID1_1_, persona0_.PER_NOM as PER2_0_0_, persona0_.CASA as CASA0_0_, casa1_.ADRECA as ADRECA1_1_, casa1_.MUNICIPI as MUNICIPI1_1_

from T_PERSONA persona0_

inner join CASA casa1_ on persona0_.CASA=casa1_.ID

Veim que s'ha ampliat la part del select amb les dades de la casa. Hibernate emprarà aquesta informació per inicialitzar les dades de les persones retornades amb les seves cases.

Hibernate empra la informació dels joins i dels where per filtrar les dades que ha de retornar. Un cop té les files que compleixen les condicions es basa en el que hi ha al select i els join fetch per construir i inicialitzar els objectes resultants de la consulta.

Anem a fer una representació d'aquestes precarregues. Si feim:

select persona

from Persona persona

join persona.casa

el que retorna és persona.

Si inicialitzem la informació de casa amb:

select persona

from Persona persona

join fetch persona.casa

podriem representar el que retorna com persona -> casa (retorna persona amb casa precarregat)

amb

select persona

from Persona persona

join fetch persona.casa casa

join fetch casa.municipi

retornaria persona -> casa -> municipi

El problema

La select problemàtica era:

select casa

from Persona persona

join fetch persona.casa casa

join fetch casa.municipi municipi

where persona.nom like :nom

Podem ignorar el where ja que no afecte a tota aquesta discusió.

Segons els fetch, informem a Hibernate que volem tornar: persona -> casa -> municipi, però el select informa que ha de retornar casa !

El missatge d'error:

query specified join fetching, but the owner of the fetched association was not present in the select list

indica que el propietari del fetch persona -> casa, això és persona, no està al select, que és casa.

La resolució

Entés el problema, la solució és molt fàcil: el tipus de join entre persona i casa és un inner join normal: no s'ha d'afegir cap instrucció de precarrega ja que no retornem persones, sinó cases.

Per tant, la select correcte seria:

select casa

from Persona persona

join persona.casa casa

join fetch casa.municipi municipi

where persona.nom like :nom

Hibernate: Flush, snapshots i rendiment

2011-08-27T19:45:00.000+02:00

Pensar en Hibernate com un generador d'SQL, impedeix entendre el comportament del framework en moltes circumstàncies.

Suposo que molts tenim una formació i experiència "esbiaixada" cap a la tecnologia relacional. Per això, quan ens trobem per primera vegada amb una eina ORM com Hibernate, costa desfernos de la forma acostumada de tractar la persistència. Davant un problema, tot d'una veiem la seqüència d'inserts, updates ... que necessitem i mirem d'invocar els mètodes save(), update() ... corresponents.

Això no només ens duu a un codi innecessàriament complicat i ineficient, sinó que pot dur a "misteris" que interpretem erròneament com bugs d'Hibernate.

Vegem un exemple:

Persona persona = (Persona) session.load(Persona.class, 1L);
persona.setNom("Canviat");

Aquest codi, donat que estigui dins una transacció, farà un sql update. Com és possible si no hi ha cap invocació al mètode update() ?

Treballant amb Hibernate el nostre focus d'atenció no ha d'estar en la base de dades, com quan treballem amb JDBC. El protagonista en el nostre cas és la sessió d'Hibernate. Un cop un objecte està carregat a la sessió, ja és transaccional. Quan feim el canvi a l'objecte persona, estem indicant que l'objecte persistent canvia el seu estat: llavors ja és responsabilitat d'Hibernate que el canvi arribi a la base de dades.

Coneixer de quina manera Hibernate realitza aquesta tasca no només és interessant per satisfer la nostra curiositat (que ja seria un motiu suficient). A més, ens permet controlar un aspecte d'Hibernate que té una gran influència en el seu rendiment.

Les preguntes que hem de contestar són dues: com sap Hibernate quins objectes han canviat i quan envia els canvis a la base de dades.

Anem a la primera. Quan Hibernate carrega un objecte a la sessió (un load, una consulta, etc), crea una còpia de l'objecte (snapshot). Aquesta còpia no es modifica amb els canvis que posteriorment facem a l'objecte. Aleshores, per saber si un objecte ha canviat o no, basta comparar la còpia amb l'objecte de la sessió: si són iguals no s'ha fet cap modificació, si són diferents sí. En l'exemple que hem plantejat, si el nom de la persona en el moment del load fos "Canviat", no es llançaria l'update encara que haguessim invocat el setNom(…) !

Segona qüestió: quan s'envien els canvis a la base de dades?. La resposta simplificada seria: el més tard possible. Però clar, això necessita explicar-se una mica.

Una implementació simplista seria fer un update cada cop que hi ha un canvi. Aquesta estratègia seria molt ineficient. Per exemple:

Persona persona = (Persona) session.load(Persona.class, 1L);
persona.setNom("Canviat");
persona.setTelefon("971555555");

El codi anterior, faria dos sql update, un després de cada setXXX. Està clar que el codi anterior només ha de generar un sql update, per tant hem de canviar d'estratègia.

Retrassar al màxim el moment d'enviar els canvis fa que puguem enviar tots els canvis de persona amb un sol sql update i això és bo. Suposem, per tant, que enviem els canvis just abans de fer el commit. Això ens crea un altre problema.

Analitzem el següent cas:

Persona persona = (Persona) session.load(Persona.class, 1L);
persona.setNom("Canviat");

long nombre = (Long) session.createCriteria(Persona.class)
.add(Restrictions.isNotNull("nom"))
.setProjection(Projections.rowCount())
.uniqueResult();

La consulta retorna el nombre de persones amb el nom distint de null. Si el canvi fet amb el setNom(...) no s'envia abans de la consulta, l'SQL no treballarà amb les dades correctes. En aquest cas, per assegurar un resultat correcte, Hibernate necessita que el canvi fet a la persona sigui enviat a la base de dades abans de fer la consulta! Volem el nombre de persones amb nom no null, i la modificació nostra s'ha de tenir en compte.

Com una aproximació simplificada (però bastant funcional) podem dir que, per defecte, Hibernate envia tots els canvis a la base de dades abans de cada consulta i just abans de fer el commit.

Molt bé tot no?, Hibernate s'encarrega de fer els canvis necessaris a la base de dades i a més ho fa de forma transparent i correcte.

El problema és que aquest funcionament implica un cost en ús de mèmoria i en temps d'execució. Cada objecte carregat és duplicat en memòria i abans de cada consulta ha de comparar l'estat de tots els objectes que estan a la sessió amb els seus snapshots. Molta feina, eh?

Podem ajudar a Hibernate indicant-li quan aquestes tasques no són necessàries:

Amb session.setDefaultReadOnly(true); indiquem que, per defecte, els objectes carregats seran de només lectura i, per tant, no és necessari construir la còpia.

Hibernate anomena flush al procés de revisar quins objectes de la sessió han estat modificats. Si volem deshabilitar els "flushos" iniciats per Hibernate podem fer-ho amb session.setFlushMode(FlushMode.MANUAL);

Emprarem el següent bocí de codi per fer un "benchmark" casolà. No el critiqueu, només és per tenir una idea molt aproximada de com pot variar el temps d'execució.

long inici = System.currentTimeMillis();

Session session = getSessionFactory().openSession();

Transaction txt = session.beginTransaction();

if (optimitzat){

session.setDefaultReadOnly(true);

session.setFlushMode(FlushMode.MANUAL);

}

// carrega a la sessió de 100.000 objectes

List tots = session.createCriteria(Persona.class).list();

// forcem 100 queries

for (int i = 0; i < 100; i++){

session.createQuery("select count(persona.id) from Persona persona where persona.id < " + i).list();

}

txt.commit();

session.close();

// mostra el temps en dècimes de segon

System.out.println("durada " + ((System.currentTimeMillis() - inici) / 100));

El temps d'executar això, en funció del valor de la variable optimitzat és:
optimitzat == true : 2.7 segons
optimitzat == false : 12.9 segons

Hi ha diferència eh?

Les proves les he fetes emprant una base de dades hsqldb en memòria (al mateix procés). De totes formes, ja dic: més que emprar aquests nombres provau d'afegir aquestes modificacions al vostre codi i observau les diferències.

Il·lusió de control

2011-08-10T19:52:00.000+02:00

Fa poc publicava Gallir unes reflexions sobre la necessitat de tenir plans de contingència en els sistemes informàtics. Justament un parell (mallorquí) de dies després, degut a uns errors en la infrastructura de Amazon, meneame cau i necessita d'unes 48 hores per tornar a estar funcionant.

No escric per fer sang. Al contrari: els plans de contingència que mostrava Gallir eren (al meu entendre) bons i cobrien el que a priori se podrien considerar com els riscs més probables. En qualsevol cas, el que si crec que convendria rectificar és el to de seguretat excessiva que emprava quan analitzava el tema.

No vull ser ventagista. No vull parlar només d'aquest cas o d'aquest tema (plans de contingència). És una qüestió de la que fa temps ja feia comptes escriure i això m'ho ha recordat.

Tant en el treball com en la vida en general, sovint quedem orgullosos o satisfets d'una determinada acció. Això ens produeix una lògica satisfacció, però no ens ha de fer perdre la vista la fragilitat de tot plegat.

Hi ha un concepte que ilustra això perfectament: l'il·lusió del control.

Tendim a pensar que el nostre control damunt la situació és molt més alt del que és en realitat. Pot ser sigui convenient o necessari (evita l'estrés continuu de pensar en tots els desastres que poden passar), però l'hem de tenir en compte per compensar els seus efectes: Per exemple, creure que el teu pla de contingència te salva de qualsevol situació.

Eisenhower va expressar molt bé el que podria ser una recepte per compensar aquest biaix cognitiu. Deia alguna cosa com: els plans no són res, la planificació ho és tot.

L'important és dedicar temps a elaborar un pla de contingència, no el resultat d'aquest estudi. El pla de contingència és simplement la cristalització del millor que hem pogut pensar fins aquest moment. La diferència és fonamental.

Posar la importància en l'objecte en lloc del procés pot tenir problemes importants:

Quedar en un elegant document, sense, per exemple, provar-ho mai: Fas copies de seguretat? perfecte, però : has provat mai de restaurar el sistema a partir d'aquestes còpies?
No actualitzar-se quan és necessari degut a canvis en l'aplicació o en la infrastructura emprada
Dependre d'accions que no se comproven: segur que el procés que fa còpies de seguretat no ha deixat de funcionar?

Una actitut correcte és el que fa que, per exemple, quan incorpores un web service remot a un procés de la teva aplicació et demanis: que puc fer quan això falli?

Ho trobem en altres àmbits. Experts en seguretat diuen que aquesta no és un producte sinó un procés. No val fer una fase final de desenvolupament dedicada a "afegir seguretat". Per ser efectiva, aquesta s'ha de considerar durant totes les activitats del projecte.

A Google, qualsevol idea presentada es qüestionada amb un "i això: com escala?".

Altres exemples més habituals: de poc serveix fer refactoritzacions i millores al codi si no hi ha un compromis en tot l'equip amb el manteniment de la qualitat del codi.

Intentem interioritzar tot aquest seguit de necessitats no funcionals dels sistemes (disponibilitat, seguretat, escalabilitat, rendiment, etc...) en lloc de centrar-nos en un objecte en concret: una classe ben dissenyanda, un document de contingència o un sistema de control d'accés. Segur que així ens anirà molt millor a tots.

I, com deia abans, recorda: mai et creguis l'amo de la situació!

PD: si voleu coneixer la meva opinió del que és un bon pla de contingència aquí la teniu: un passaport fals i 1.000.000 de euros a una compte opaca ;-)

Ampliacions

2011-04-30T18:26:00.000+02:00

Quan tractem el tema de modificar l'àmbit d'una aplicació és millor parlar en termes de sistema. Aplicació sembla referir-se només al codi, i deixar de banda molts altres components com són base de dades, servidors, comunicació amb sistemes externs, etc.

Per tant, la qüestió tractada és, quan ja tenim implentat un sistema de gestió, no acabat, que mai passa, però si ja bastant estabilitzat, com plantejem el seu creixament ?

Vaig a expresar quin és el meu punt de vista. No fa falta dir que no soc autoritat en la matèria. No vull ni puc ser dogmàtic. Simplement, escriure quines són les meves idees després de donar-li algunes voltes.

Actualment el sistema està cobrint un determinat àmbit. Implementa tot un conjunt de tràmits, informes i permet una sèrie de accions als seus usuaris. D'aquest àmbit l'aplicació implementa un model: algunes coses se consideren i altres, evidentment, les deixa fora.

Per exemple, l'àmbit inclou el procés de matricula de l'alumne a un centre docent. El model de l'aplicació captura alguns elements, com per exemple el nom de l'alumne, i en deixa alguns altres fora, per exemple, quina és l'altura de l'alumne, per posar alguns casos molt evidents.

Quan parlem d'ampliar l'aplicació podem augmenar el detall de l'aplicació (guardem altres dades del procés que ara no tenim) o augmentar l'àmbit (a part del procés de matricula, també implementam l'avaluació que es fa de l'alumne).

Les preguntes que hem de respondre són

Què ampliam?

En quines direccions?

Què ampliam

La meva idea és que s'ha d'ampliar l'àmbit, i només el detall quan sigui molt important per els usuaris.

De fet, activament s'ha de reduir al màxim el detall que maneja el sistema. És a dir, el model ha de ser el més simplificat possible. Si considerem tot el model com el pes de l'aplicació i l'àmbit com el volum, la idea es pot expressar diguent que l'aplicació ha de ser el menys densa possible.

Per prepararnos per l'ampliació de l'àmbit, abans cal un tasca important: desfer-nos de tot el que no és necessari. Dit amb altres termes: aplicar el “abans d'entrar, deixin sortir”.

Revisa tota l'aplicació i mira que pots esborrar sense que afecti a les tasques que fan els usuaris. Primer caura, com és lògic, el codi mort, les taules i les columnes no emprades, etc. Esborra. En cas de dubte, esborra.

Trobarem també parts de l'aplicació que tenen dades, pantalles de gestió que funcionen, però que no han demostrat utilitat per cap de les accions que fan els usuaris. Aquestes parts, sap greu, però també s'haurien d'esborrar. Passes pena per el codi? està control de versions. Te preocupen les dades? Ja t'ho dic jo: estan malament. Com ho sé? només l'ús freqüent de les dades agaranteix la seva qualitat. Si no s'empren, és molt poc probable que siguin fiables. Si te preocupa, fes una còpia, poseu a un zip i ho guardes. Fet això, esborra les taules i columnes adients.

Si la teva preocupació és poder justificar la teva tasca davant dels caps, argumentant amb el nombre de taules i línies de codi, no facis el que hem dit abans. Si la teva preocupació és poder respondre a les necessitats dels usuaris de forma eficient, fes-ho. Esborrant el dit abans estalvies temps cada vegada que intentes resoldre una incidència, analitzes on s'empra un recurs del codi, obres l'IDE, fas un checkout, construeixes l'aplicació, fas un commit, treballes amb una branca nova, canvies la versió d'alguna tecnologia emprada, fas una backup, analitzes les dades d'una taula, expliques a un usuari com s'empra l'aplicació, etc, etc, etc.

En quines direccions

Posats a creixer, en quina direcció ho feim?

Els objectius. Primer, fer més eficient la tasca dels usuaris, segona, augmentar la seva qualitat.

Per exemple: introduir dues vegades les mateixes dades a dues aplicacions diferents penalitza els dos objectius.

El primer que cal fer és cercar quin és l'ecosistema d'aplicacions, activitats i fonts d'informació amb les que conviu el nostre sistema. Els distints usuaris no estan tot el dia asseguts emprant únicament la nostra aplicació. Per complir amb la seva responsabilitat, segur que han de fer tot un conjunt de tasques amb altres aplicacions de la nostra organització, amb aplicacions externes i inclús algunes de forma manual. Per exemple:

Introduixen les mateixes dades a la nostra aplicació i en una altre altre de la mateixa organització.
Fan unes tasques de forma manual que tenen algun tipus de solapament amb el nostre sistema. Exemple: han de escriure a un document de texte documents que la nostra aplicació podria generar en base a la informació que té.
Empren altres programes externs, per exemple, eines organitzatives, que s'han d'emplenar manualment “transcribint” les dades de la nostra aplicació a aquesta.
O, a l'enreves, empren programes externs que produiexen un resultat que després han de introduir manualment al nostre programa.

Una forma de millorar tota l'organització és oferir als usuaris una aplicació que faci més funcional la colaboració dins de tot aquest ecosistema.

Quan considerem que és adient que el nostre sistema ajudi amb la tasca de l'altra producte hi ha dues opcions:

El nostre sistema absorveix la funcionalitat de l'altre producte
Proporcionem una forma de colaboració entre els dos productes

Algunes de les preguntes que ens hem de fer, són:

Quina solució serà més més còmoda per l'usuari?
Quina solució oferirà uns resultats de millor qualitat?
Quina solució ens deixa en millor situació a l'hora d'agarantir el manteniment de l'aplicació?

Critèris tècnics

Juntament amb els canvis de “esborrar (detall) – afegir (àmbit)” anteriors, s'ha de reservar una quantitat de temps per aspectes més tècnics.

Ha passat el temps de les presses, de fer les coses per ahir i de corregir errades greus a producció. És un bon moment per fer les coses amb una mica més de calma, i el primer punt ha de ser reduïr el deute tecnològic adquirit durant el desenvolupament.

Segur que hi ha parts de l'aplicació que acumulen més errades, que se varen prendre decisions equivocades o que amb el temps hem vist que es podia fer molt millor. És el moment de arreglar aquestes parts. En general, fer net de tot el que està malament o ens fa perdre molt de temps de manteniment.

Millora la qualitat del codi. Aplica analitzadors i corregeix els defectes que trobin. Mira quines consultes van més lentes i afinales. Revisa els indexos de la base de dades. Redissenya les pantalles més lentes per a que no carreguin tanta informació.

També s'ha de fer que l'aplicació estigui en linia amb l'evolució de les tecnologies emprades. No es tracta d'emprar sempre la darrera versió, sinó de no despenjar-se. Una transició de la versió 2 a la 3 generalment és senzilla. Passar de la 1 a la 4 pot ser gairebé impossible. S'ha d'anar avançant a la velocitat de la comunitat. Quedar despenjat implica problemes amb la convivència amb les altres tecnologies, amb l'accés a la documentació i amb l'accés a les correccions dels bugs.

Finalment s'han de treballar els riscos que pugui tenir el sistema. Pensa en el teu sistema i completa la frasse “quin desastre podria passar si algun dia ...”. Canvia desastre per algun terme més lleu i segur que se t'ocorre alguna cosa. Aprofita ara per eliminar o mitigar aquests riscos tant com sigui possible.

L'activitat d'esborrat del primer punt t'ajudarà molt en cada una de les tasques anterior.

Per tractar

Tot el que he dit és molt simplificat. Just són unes línies per tenir en compte que, en cada cas particular, podran tenir més, menys o cap aplicació. Posats a enumerar algunes de les moltíssimes coses que s'haurien de afegir o matisar:

Quan parlem de simplificar ho feim amb línia amb el "Make everything as simple as possible, but not simpler". És eliminar el no essencial però cercar la riquesa del model a on és necessari.
Mantenir l'acoblament i la cohesió dins del nostre codi. Important quan parlem d'ampliar l'àmbit de l'aplicació.
Una aplicació o distintes aplicacions? Falta tractar el tema de si distribuir l'aplicació i com fer-ho.

Aplicacions de gestió: característiques i implicacions

2011-04-21T12:37:00.000+02:00

Una característica que m'agrada de les aplicacions és que siguin senzilles. Deia Antoine de Saint-Exupery que la perfecció assoleix no quan no hi ha res més per afegir, sinó quan no hi ha res més per llevar.

Hi ha, però, molts tipus d'aplicacions. En la que estic jo és una aplicació de gestió de la Conselleria d'Educació, i aquest tipus d'aplicacions tenen unes característiques bastant especials. Aquestes són els punts que crec les fan diferents a altres tipus d'aplicacions:

Completa

Han de ser completes. Altres aplicacions poden centrar-se en fer bé el que representa la majoria de casos. Una aplicació de gestió s'ha d'adaptar a la normativa i cobrir qualsevol cas contemplat, per poc probable que sigui i per molt impedeixi construir una solució més elegant (tots sabem el que molesten les excepcions al cas general).

Única

No hi ha competència. No fa falta desenvolupar cap “característica diferenciada” que la imposi a la competència. Evidentment, volem que els usuaris estiguin contents amb l'aplicació, però aquesta satisfacció no necessitem obtenir-la “enlluernant” en el primer instant, sinó més aviat fent que no odiïn l'aplicació després d'emprar-la moltes hores durant molts de dies.

Obligada

Els usuaris, en la majoria de casos, l'empren per obligació. Han de realitzar un tràmit o cumplimentar una acció que forma part de la seva tasca. Entren, la fan, i surten.

Suport

La tasca principal dels usuaris no és emprar l'aplicació. Els usuaris són professionals amb una altra responsabilitat. L'ús que fan de l'aplicació és per facilitar la gestió de tot el col·lectiu. És un mitjà, no el fi darrer.

Controlada

La vida de l'aplicació serà llarga i el seu rumb guiat per factors externs a l'equip de desenvolupament. L'aplicació ha de seguir el dictat d'una normativa que sol canviar de tant en tant, i s'ha d'adaptar a les necessitats i peticions dels seus usuaris.

Aquestes punts s'han de tenir en compte a l'hora de desenvolupar l'aplicació. Com afecten? Així ho veig jo:

Obligada:

L'usuari no entra a l'aplicació per passar-s'ho bé. El nostre objectiu no ha de ser “retenir-lo” a l'aplicació amb entreteniments, sinó fer que pugui realitzar l'acció que vol fer de forma eficient: sense errades en el procés, amb la major facilitat i en el menor temps. La disponibilitat i el temps de resposta són de gran importància en aquest punt.

Suport

L'objectiu de l'usuari no és emprar l'aplicació. Més aviat són usuari i aplicació els que tenen un objectiu comú. L'aplicació ha d'ajudar a l'usuari fent que cada acció realitzada tingui valor per l'objectiu final. Mira en lupa cada dada que demanes a l'usuari: segur que és necessària?

Controlada

La normativa que l'aplicació implementa és d'esperar que sigui canviada amb certa freqüència. Aquests canvis poden perjudicar molt a la implementació actual del sistema, però no està en mans dels seus desenvolupadors impedir aquests canvis. Per poder aguantar el viatge és important no dur més equipatge del estrictament necessari. Cada línia de codi s'haurà de mantenir i actualitzar. Cada línia haurà de mostrar que és imprescindible o s'haurà d'eliminar.

Completa

La lògica serà complicada. No és tracta de resoldre bé el 80% fàcil dels casos sinó el 100% d'ells. S'ha d'aprofundir en la lògica que hi ha al darrera del seu funcionament per no convertir el codi amb una xarxa de if – elses impossible de mantenir.

Única

No hem de convèncer amb 2 minuts a l'usuari de que som la l'aplicació que necessita. No és necessari ni cosmètica ni llumets ni músiques. Introduir funcionalitat orientada a “vendre” l'aplicació, que perjudica a algun dels altres punts, va en contra dels interessos dels usuaris.

La metàfora a emprar per aquests tipus d'aplicacions no és la d'un spa on l'usuari cerca comford, relax i passar un parell de dies meravellosos. Seria millor la d'una oficina de tributs, on un usuari que ha demanat una hora lliure a la feina, té el cotxe mal aparcat, i no sap molt bé de que va el tema, ha d'emplenar un tràmit. Millor que no li expliquis que s'ha d'esperar una estona per que has de canviar la música ambiental.

Vol dir això que només té cabuda una línia “espartana” de pensament? No. Està clar que encara que siguem en una oficina i no en un spa, un ambient agradable, un tracte amable i certa comoditat són molt ben valorats. No és el mateix posar altres prioritats en primer lloc, que llevar-li tota la importància.

A més, hi ha una lògica econòmica que no es pot ignorar. Així com l'aplicació es va consolidant, la tasca a fer se redueix respecta a la del desenvolupament inicial. Si la dimensió de l'equip es manté, es clar que està en disposició de fer altres tasques a part de just el manteniment del codi actual. Per on es pot ampliar l'aplicació? Aquest serà el proper post.

Madurant

2011-02-23T21:10:00.000+01:00

Quan estava encara estudiant a la carrera, i durant els primers anys de feina, tenia molt interioritzada la idea del desenvolupament en cascada. De fet, disfrutava molt més fent tasques d'anàlisi que programant.

L'anàlisi, creia, era la part determinant en la construcció d'un bon producte. Clar que era impossible un bon programa amb un mal codi, però diguem que sí que veia possible aconseguir-ho amb un anàlisi excel·lent i una programació regular.

Amb aquestes conviccions, el model de desenvolupament òptim reservava molt de temps a la tasca d'anàlisi i, a més, la feia sense "despistar-se" iniciant la programació.

D'això, ja dic, han passat més de 10 anys.

No sé en quin moment vaig començar a canviar d'opinió però a dia d'avui ja no coincideix en res amb l'original.

Suposo que comences a detectar coses que no "quadren" amb les creences inicials. Surten potents entorns 4GL però no arriben a resoldre els problemes. Llevat del casos molt senzills, la complexitat de la lògica supera clarament l'associada a l'estructura de dades. Tot i això, l'anàlisi sembla preocupar-se només (o principalment) per la segona. Models per descriure la part dinàmica són molt inferiors comparats amb els de la part estàtica.

Comences a observar com la part crítica de l'aplicació, la part que més "inteligència" guarda, queda més al codi que a qualsevol artefacte de l'anàlisi o disseny. Desesperes quan, per molt d'anàlisi que facis, en quan comences a programar i, sobretot, veure als usuaris emprar el sistema, te n'adones del poc que sabies quan feres l'anàlisi.

Passes d'emprar llenguatges que simplement mouen dades d'un costat a un altre, a altres orientats a objecte que permeten elaborar abstraccions útils, molt semblants a les que empren els experts en el domini. Llavors, en poques (però memorables) ocasions, aconsegueixes que unes poques línies de codi expressin millor que qualsevol diagrama de l'anàlisi, algun aspecte clau de l'aplicació.

I clar, la idea que tenies quan començares ja no s'aguanta.

Me fa empegueir la prepotència en que s'afrontava la tasca d'implementació d'un nou sistema. Segons aquella visió (potenciada durant les classes a la universitat), l'analista no havia de deixar-se influenciar excessivament per la forma en que els usuaris feien les coses. L'analista no només implementaria una aplicació, sinó que redissenyeria tot el funcionament. Una postura pedant ... i que crec que te dona molts de números per fracassar.

Avui, crec que l'actitut correcta és molt més humild. Una metàfora que se m'ocorre és la del que va a viure a l'estranger. Has d'aprendre els llocs, l'idioma, les lleis, però també les convencions socials, les costums etc. del lloc. Has d'oblidar molt del que saps. Has d'evitar al màxim el "però és que al meu país això ho feim així ....". Per molt que llegeixis o t'expliquin, fins que no te instal·les allà no ho coneixes.

I tot aquest coneixement ha de quedar en el codi i en tots els artefactes vius del sistema: la interfícia, les ajudes, el llenguatge que empres amb els experts i els usuaris, etc.

Vol dir això que no hi ha anàlisi? No. L'anàlisi és tota la preparació prèvia al trasllat. Aprendre nocions bàsiques de la cultura, una mica de l'idioma... Idees fonamentals per no "morir" durant l'arrivada. Aquesta activitat és molt útil, però la diferència clau està en reconèixer que és limitada. És un esboç inicial que serveix per orientar-nos durant els primers dies però no la referència final del que aprendrem durant l'estància.

Llevar responsabilitat a l'anàlisi només és negligència si no la translladam a l'activitat de programar. Per això, programar ha d'incloure dues activitats.

Primera, ampliar i refinar el coneixement i fer que aquest estigui incorporat al codi. Això implica refer parts antigues així com anem coneguent més del sistema. Tenir l'actitud de sospitar de tot el que quedi "estrany" al codi. Interrogar a experts i usuaris de per que fan les coses com les fan i intentar que el codi s'expressi de forma semblant a com ho fan ells.

Segona, proporcionar un model d'aquest coneixement. Aquesta part és complexe. El programa gestiona molts d'aspectes diferents: persistència i recuperació de dades, gestió de transaccions, de seguretat, construcció de la interfície d'usuari, integració amb altres sistemes, etc. Un model és un esquema simplificat que exclou aspectes importants per deixar només els essencials al que intenta descriure. El nostre codi haurà no només d'implementar tots els aspectes comentat abans, sinó que haurà de proporcionar de forma destacada, un codi que sigui model dels conceptes i les regles bàsiques de negoci.

No puc estar més d'acord amb el que vaig llegir crec que a Software Craftsmanship: Si tens 10 analistes brillants i 200 programadors regulars, fes fora els 200 programadors i posa a programar als 10 analistes.

Proper curs d'Hibernate

2010-04-23T07:14:00.002+02:00

El dia 3 comença el curs d'Hibernate.

El curs és gratuït i es farà de 16:00 a 19:00, de dilluns a divendres, entre el dia 3 de maig i l'11 de maig.

Inscripcions a la CAEB (enllaç als cursos).

Un exemple del material que es donarà:

Mantenir les files

2010-03-20T21:40:00.004+01:00

Hi ha situacions en les que els dubtes o la por ens fan prendre decisions incorrectes. La raó es que en aquestes circumstàncies patim una espècie de "visió tunel" que fa que només considerem un aspecte de la qüestió, el més immediat, ignorant-ne d'altres que poden ser molt més importants.

Un exemple. Un jugador de futbol es necessari que mantengui la seva posició. Encara un extrem tingui la tentació de córrer darrera la pilota per ajudar a tapar la darrera línia, no ho ha de fer. Pot semblar que així ajuda més, però fent això rompe un ordre que és necessari.

Crec que això passa moltes vegades quan programem amb Hibernate i ens decantem per emprar data transfer objects (DTO), en lloc de les entitats. Veiem més fàcil crear un value object just amb les dades que ens demanen, que no carregar tot el graf d'objectes (possiblement bastant dispers) necessari per obtenir les mateixes dades. Ho resolem amb una HQL o SQL just dels atributs que volem. Ràpid, fàcil i net.

Però això pot presentar problemes. Problemes, sobretot, quan el programa va evolucionant i comencen a sortir condicions no previstes. Ho veig molt sovint al programa que estem fent. Les entitats van evolucionant conforma canvien els requeriments. És inevitable. Aleshores, els value objects comencen a mostrar problemes.

El seu disseny, amb el canvi a l'estructura de dades, pot no ser ja tan adient.
Els programadors han d'aprendre múltiples estructures. Coneixen bé les entitats, però a molts llocs és necessari també entendre múltiples estructures dels DTOs.
La lògica queda duplicada en les classes de servei i en múltiples where's
Conseqüència de l'anterior, perilla la consistència en els resultats obtinguts des de distints tipus d'informes.
Perdem recursos d'Hibernate com filtres o interceptors.
Perdem l'aillament transaccional que ens ofereix la Session
Se perden les advantatges de les caches de primer i segon nivell.

Gairebé sempre me decanto per emprar només entities, però en alguns llocs (sobretot al codi escrit al començament) ho vaig fer amb DTOs. Puc dir que en la immensa majoria de casos, la decisió ha estat incorrecte.

El consell seria, intenta expresar tota la funcionalitat amb les entitats. Que el codi quedi clar. Només abandona l'estructura de les classes de domini en els llocs on els problemes de rendiment ens obliguin a fer-ho.

Nombres màgics

2010-03-13T19:01:00.003+01:00

No poseu mai nombres màgics al codi. Per exemple, si teniu



public class Compte {

   public void processa (Ordre ordre) {
      if (ordre.getId().equals(1038)) {
          // cas especial
      }
   }
}

millor fer



public class Compte {

   public static final int MIL_TRENTA_VUIT = 1038;

   public void processa (Ordre ordre) {
      if (ordre.getId().equals(MIL_TRENTA_VUIT)) {
          // cas especial
      }
   }
}

i ja està ;-)

Introduint Groovy a un projecte Java

2010-02-22T16:50:00.003+01:00

Aquesta entrada presenta una forma suau de introduir la potència de Groovy al nostre projecte Java.

Per suau vull dir sense haver de reescriure res del que tenim, simplement conservar-ho tot i anar emprant Groovy als llocs on ens interessa.

Emprarem un exemple bastant ridícul. No interessa el codi concret, sinó les passes per configurar el projecte.

Suposem que un Servlet empra una classe d'utilitat Java per construir dinàmicament una plantilla HTML (aniria molt millor un JSP, però ara ho passarem per alt)


public void doGet(HttpServletRequest request, HttpServletResponse response)
   throws IOException, ServletException {
 response.setContentType("text/html");
 PrintWriter out = response.getWriter();
 
 Persona persona = new Persona();
  
 persona.setNom("Tomeu");
 ServeiJava prova = new ServeiJava();
 
 List receptors = new ArrayList<string>();
 receptors.add("primer receptor");
 receptors.add("segon receptor");
 out.println(prova.saluda(persona,"com estas?", receptors));
}

La classe ServeiJava (perdonau el mal exemple!!) simplement construeix un missatge HTML a partir dels paràmetres


public class ServeiJava {

public String saluda (Persona persona, String missatge, List destinataris) {
  StringBuilder cadena = new StringBuilder();

  cadena.append("<html>");
  cadena.append("<body>");
  cadena.append("Això és una cosa que s'ha de comunicar.<br/>");
  cadena.append(missatge).append("<br />");
  String nom = "";
  if (persona != null && persona.getNom() != null) {
     nom = persona.getNom();
  }
  cadena.append("Origen: ").append(nom).append("</br>");
  cadena.append("hi ha ").append(destinataris.size()).append(" destinataris");
  cadena.append("<ol>");
  for (String destinatari: destinataris) {
    cadena.append("<li>").append(destinatari).append("</li>");
  }
  cadena.append("</ol>");
  cadena.append("</body>");
  cadena.append("</html>");
  
  return cadena.toString();
}
}

Podem fer que la classe de servei empri la funcionalitat oferida per Groovy. Per exemple, cream ServeiGroovy.groovy, amb el mètode


def saluda (Persona persona, missatge, destinataris) {


String nom = persona?.nom ? persona.nom: ""

String llistaDestinataris = ""
destinataris.each {
  llistaDestinataris += "<li> $it </li>"
}

"""\
<html>
<body>
Això és una cosa que s'ha de comunicar.<br/>
${missatge} <br/>
Origen: ${nom} <br />
hi ha ${destinataris.size} destinataris
<ol>
  ${llistaDestinataris}
 </ol>
</body>
</html>
"""


}

La classe anterior empra un parell de funcionalitats de Groovy

L'operador save-dereference (?.) per evitar Null Pointer Exceptions (en Java hem de fer una comparació adicional)
El mètode each amb un closure anònim
El multi-line GString
La forma de retornar valors per defecte

Així i tot, el codi Groovy anterior és un poc "javero". No s'ha d'agafar com a exemple de com fer les coses amb Groovy

Ara falta que l'aplicació web, quan la despleguem, entengui la classe Groovy. Per això farem dues passes més:

1 Afegir les llibreries de Groovy per el temps d'execució

Per això hem de incloure al WEB-INF/lib el fitxer groovy-all-X.X.X.jar.
Aquest fitxer pesa uns 5 MB. Una altre opció, si és possible, és deixar-ho dins del lib del servidor d'aplicacions.

2 Compilar el codi font de Groovy junt amb el de Java

Per exemple, si emprem ant, seria alguna cosa com això:


<path id="groovy.classpath">
  <pathelement path="lib/groovy-all-1.7.1.jar" />
</path>

<taskdef name="groovyc"
       classname="org.codehaus.groovy.ant.Groovyc"
       classpathref="groovy.classpath"/>

<target name="compile" >
  <groovyc srcdir="src" destdir="${classes}" classpathref="compile.classpath" >
    <javac source="1.5" target="1.5" debug="on" />
  </groovyc>
</target>

Conclusió

La incorporació de Groovy al nostre projecte Java no implica ni deixar d'emprar aquest llenguatge ni tirar res del que tenim fet.

Podem seleccionar un mòdul poc crític o especialment necessitat dels afegits que fa Groovy i provar si aquesta incorporació aporta els beneficis que esperam.

Nou curs

2010-02-10T22:18:00.000+01:00

El març comença la temporada de cursos.

El primer és un llaaaarg curs que inclou desde la introducció al llenguatge Java fins als Servlets, JSPs i JDBC.

Més informació

La part de temari no està actualitzada i encara mostra només els continguts referents a la introducció del llenguatge.

El curs és gratuit i, a més, els que facin bonda seran obsequiats amb una bossa de caramels ;-)

El nucli

2010-02-09T18:20:00.000+01:00

En un projecte gran, amb molta gent introduint codi a un ritme alt és difícil mantenir un mínim de qualitat. Les accions que es poden dur a terme, com revisions de codi, refactoritzacions, etc, suposen enderrarir aquest progrés. Al manco a curt termini.

Quan ens trobem amb aquesta problemàtica: vegem la qualitat com a necessària però som incapaços de arribar al nivell que desitgem, hem de optar per una solució de compromís. Crec, puc estar molt equivocat, que l'opció més adient és identificar quin és el nucli crític de l'aplicació i mantenir-lo el més aïllat possible de la resta de l'aplicació.

Fins i tot, el millor seria fer que només certes persones fossin responsables d'aquesta part, però això ja pot ser més complicat. Podríem introduir el coll de botella que intentem evitar. Per això una solució més realista probablement sigui mantenir al manco l'aïllament.

I quina és aquesta part crítica?. En general aquesta part de l'aplicació correspondrà a les classes de domini i mètodes de servei més importat. No de tota l'aplicació, sinó aquelles que representen la part funcional bàsica del sistema.

No crec que aquesta intenció sigui estranya: ho feim amb altres parts de l'aplicació. Per exemple, si algú ha de crear un Servlet, el crea i ja està. Però si algú necessita una taula nova a la base de dades, normalment feim que necessiti l'aprovació d'algú amb coneixements específics o amb millor visió global de l'aplicació. Moltes vegades inclús es cerca un consens entre un ampli grup de desenvolupadors. No és que el Servlet no sigui important, però està clar que no està al mateix nivell que un canvi a l'esquema de la base de dades.

Aïllar aquesta zona de l'aplicació que reconeixem com a crítica permet que, encara que no puguem assolir al moment el nivell de qualitat dessitjada, més endavant sigui viable afrontar tasques de millora.

Per aconseguir aquest aïllament s'han d'evitar dues coses. Que el que ha d'estar allà dins surti, i que el que no ha d'estar allà dins hi entri. Així de fàcil. Així de difícil.

Per exemple, si feim un mètode de servei

public void modificaSolicitutVacancies (Solicitut nova);

Probablement aquesta funcionalitat inclou molts de casos diferents:

La solicitut canvi l'estat a acceptada. És una acceptació d'una solicitut de vacances
La solicitut canvi l'estat a rebutjada. És una denegació
La solicitut activa un atribut de cancelada. L'usuari retira la solicitut. Si ja estava acceptada s'han de restaurar els dies de vacances restants
...

El mètode de servei se converteix amb un simple sql update... Tota la lògica que hi ha al darrera d'aquesta acció, lògica crítica en un sistema de control de vacances, queda en el Servlet, al javascript o, fins i tot, baixa la responsabilitat de l'usuari.

L'altre problema es pot produir pel fet que, mesclat amb aquesta part crítica, s'hi introdueixin altres components que no ho són tant.

Per exemple, el sistema anterior pot tenir un servei de notificació via email o sms de l'estat de les solicituts. Aquest clarament és un mòdul de suport a l'aplicació. Pot ser molt important per l'usuari. Fins i tot imprescindible, però no està al nucli del que implementem. Ha d'estar clarament diferenciat al codi.

El camí a seguir ha de ser tenir el màxim de funcionalitat possible treta de la gestió bàsica de l'aplicació. Quan més ens esforcem en aquesta tasca més parts de l'aplicació passaran a estar implementades amb eines externes en lloc de codi nostre. Coses com eines de reports, eines de cerca de documents o d'explotació de dades (uns companys ara fan virgueries amb el Pentaho), poden augmentar molt el profit que s'extreu de la nostra aplicació.

Però això només és possible si la base damunt la que se sustenta tota aquesta parafernàlia és sòlida. Si la creació i cerca de documents PDF generats està mesclat amb el nucli de l'aplicació, dificilment trobarem una eina que s'adapti al que necessitem. Si feim un mòdul separat amb el que té de comú tota la part de generació de documents, extreim aquesta part de la gestió bàsica (no mesclar el codi del mètode que determina que una solicitut s'ha d'acceptar amb el que genera el document d'acceptació) i ens adaptem a l'estructura habitual (general) de les eines de indexació i cerca de documents, tenim molts de números de poder delegar part important a una eina externa.

Creant bits

2010-02-07T13:23:00.000+01:00

En primer bloc he de donar l'enhorabona a en Ricardo per la seva exposició i a en Toni per la iniciativa. Va ser un capvespre molt ben emprat i entretingut.

Després de tenir un día per digerir una mica el vist, vaig a escriure el que m'ha quedat del tema.

Impresió general.

Excelent. La capacitat del client a l'hora de configurar el sistema tant de producció com a altres entorns (proves d'acceptació, desenvolupament …) és simplement impresionant. Crec que, un cop generalitzat aquest servei, la tornada enrera es veu molt improbable.

En Ricardo va fer molt bona feina explicant a un no iniciat que és el que se troba quan se enfronta a l'oferta d'Amazon. Quines parts poden desorientar més i que s'ha de tenir en compte. La part final, amb la demostració, fou tota una exhibició de l'eficiència del sistema.

El sistema.

A l'inici de l'exposició en Ricardo va mostrar la seva admiració per la interfícia presentada per el sistema d'Amazon. Deu ser un bon exemple de com s'ha de dissenyar un sistema. Demostració palpable de la importància de construir un model coherent i oferir un conjunt d'interfícies de qualitat.

En el cas del EC2, se presentaven interfícies RESTFul, SOAP, una utilitat per línia de comandes, una interfícia gràfica i, me va semblar entendre, una API per distints llenguatges.

Un altre factor que també crec que deu haver influit en l'èxit d'aquest producte és el fet es tracta del sistema que ells mateixos empren. Tot un exemple del principi "eat your own dog food".

La tasca d'en Ricardo i creant bits.

Me va agradar molt el comentari d'en Ricardo referint-se a que, quan veia la llista final del que necessitava, la veia tan evident que li sobtava haver tingut tants de problemes per arrivar a ella. Aquesta és precisament la tasca dels "pioners" en una tecnologia. Curiosament, quan aquesta tasca està ben feta, el resultat és un "ah, sí, això és molt fàcil", i quan no se fa tant bé, s'obté un "uau, que ets de bo!, això és molt complicat!". Així que enhorabona per la simplicitat a la llista ;-)

L'arquitectura per Meneame pot servir perfectament com a plantilla per moltes aplicacions Web. De fet, no estaria gens malament que s'oferissen una sèrie de "Architecture patterns" com a punts de partida per configurar els distints projectes.

Alternatives?

La que estava en ment de tothom és l'oferida per Google. En Ricardo explica que en les seves proves observaren que la latència en els accessos al BigTable eren molt elevats. Això és un problema important en una aplicació com meneame. No sé si aquest va ser l'argument definitiu, tanmateix Ricardo va valorar el sistema de Google com a molt bo.

Google i Amazon presenten solucions diferents a problemes semblants. Aquesta diferència és principalment en el nivell d'abstracció que presenten (Disclaimer: no en tenc ni idea del tema. Parlo a partir del que vaig entendre ahir). A Amazon configures el teu sistema i cada una dels seus elements. Has de coneixer molt bé què necessites i quina és la millor forma d'obtenir-ho. Google no et presenta aquest nivell de detall. Tú poses l'aplicació i demanes la capacitat dessitjada.

Diria que en general (amb excepcions notòries), sol triunfar el sistema que és mou a un nivell d'abstracció més alt. Fent una valoració freda, apostaria fins a 1.5 euros a que les coses li van un poc millor a Google, però no més.

Programació

Som programador. D'altres coses (de informàtica i de fora de la informàtica), en sé molt poc. Que en vaig treure de la presentació d'ahir que afecti directament al meu vici?. La primera conclusió va ser que, al manco amb el sistema d'Amazon, el model de programació varia poc. No dic gens. Hi ha coses que s'han de considerar. Per exemple, pot ser necessari modificar el que considerem a l'hora d'optimitzar l'aplicació per incloure factors que afecten al que ens cobra el que ens lloga la plataforma (per exemple, nombre de connexions establertes).

Un altre problema interessant presentat, l'obtenció de la IP remota quan l'accés arriva per https i ha passat per un balencejador de càrrega que no ha pogut modificar les capçaleres no és inherent al fet d'estar al núvol, sinó a l'arquitectura concreta.

Ara que tot això és amb el model d'Amazon. Amb Google sí que ens canvia el funcionament d'una pessa clau en tot el sistema: l'abandonament del model de dades relacional, però això ja per un altre dia.

llibre "Managing the testing process"

2009-12-19T10:10:00.000+01:00

Fa unes setmanes vaig comanar un parell de llibres que parlaven de les proves en el software.

Un d'ells és "Managing the testing process" de Rex Black. Encara no l'he llegit tot (té 600+) pàgines però amb el que duc llegit, més o manco la meitat, ja m'ha servit per fer-me una mica a la idea de com se pot organitzar aquesta tasca.

En primer lloc he de dir que no era el tipus de llibre que cercava. Volia un llibre a on s'expliquesin tècniques concretes de proves, no la seva gestió. Cercant per amazon durant un parell de dies, me va pareixer que l'oferta de llibres d'aquest àmbit és molt reduida. Al final hem vaig decantar per aquest llibre i "Lessons learned in software testing".

Cap del dos tracta l'àmbit que cercava, però tot i així m'estan servint per omplir un buid molt important. Al cap i a la fi, ens dediquem professionalment a posar sistemes en producció.

Intentaré apuntar les idees més importants que m'ha aportat el llibre.

La motivació del procés és assegurar al màxim el valor del producte
Per això, s'han d'identificar els riscos (situacions que poden fer perdre aquest valor) i prioritzar-los. Per exemple (simplificat): prob. d'ocurrència x efecte produït
Dissenyar el conjunt de proves (test cases) cercant la màxima cobertura dels riscos anteriors. Molt de pragmatisme és necessari per aquí.
Les proves poden variar molt en la seva especifícitat:

Proves automàtiques ( de caixa blanca o de caixa negre )
Proves manuals, però seguint un guió
Proves exploratòries

Tots els tipus de proves anteriors tenen valor. En general, anant cap a d'alt són més ràpides d'executar, anant cap abaix, tenen més capacitat de detectar errors.
Les proves automàtiques són molt sexys per els programadors. Com s'ha dit abans tenen valor, però hem d'evitar identificar-les amb TOT el procés de proves.
Una de les principals dificultats que trobarem serà com organitzar l'execució d'aquests tests cases. Les dificultats provenen de que:

No treballarem amb una release, sino en successives releases que anirà (anirem) produïnt l'equip de desenvolupament. No podrem passar tots els test cases en cada lliurament.
Entre releases s'introduiran errors de regressió. Que la versió 1.0.RC3 passi el test case X no vol dir que la versió 1.0.RC4 l'hagui de superar.

El llibre és molt específic en la gestió del procés. Proposa una metodologia pròpia per el projecte de test i la compara amb l'estàndard IEEE 829. Moltes d'aquestes coses ara mateix no les veig amb possibilitat incorporar-les a la meva feina, però no està de més coneixer les seves idees principals.

Un consell que m'ha agradat ajuda amb un problema que tots hem patit a les nostres feines: fa referència a la forma de comunicar un bug que hem trobat. Per desgràcia, l'ego dels programadors és molt sensible. Per encara més desgràcia, en alguns casos el manteniment d'aquest ego és més important que la feina que se duu entre mans. Per això, part important de la detecció del bug és justíficar per qué és un bug. L'hem d'aïllar el màxim possible i correlacionar amb una especificació o un dels valors de l'aplicació. És frustrant sovint el que costa convèncer a un programador que un error és un error.

Per acabar, una idea no del llibre sino del blog de testing de google, per superar la paràlisi a l'hora d'iniciar la definició dels jocs de proves. A la pregunta de "Per on començo a dissenyar les proves", la resposta que donaven era: imagina que d'aquí a dues hores te diuen que posaran el sistema en producció, que seria el primer que provaries?

Una conversa estranya

2009-12-14T18:48:00.000+01:00

Avui he tingut una conversa un tant estranya amb el servei tècnic de vodafone

Jo: Hola. El móvil no me permite realizar llamadas ni acceder a internet
Ells: (després de 5 minuts d'espera i de demanar-me fins la talla dels calçatins). El problema es que ha superado su límite de consumo, 60 euros
Jo: No sabía que tenía límite de consumo.
Ells: Sí, (40 segons d'espera). Lleva gastados 140 euros
Jo: Ah. Lo del límite no funciona muy bien no?
Ells: ....
Jo: Necesito hacer más llamadas. Pueden anular el límite?
Ells: No. Pero lo podemos pasar a 70 euros
Jo: ??? Así podré llamar?
Ells: Debería funcionar

Al final li he dit que fes el que trobés per tal que jo pogués telefonar. He rebut un missatge fa poc indicant que s'ha anulat el límit. Ja puc telefonar però encara no tenc accés a internet.

Espero que el projecte en el que treballo no generi converses com aquesta entre la gent d'atenció als usuaris i les pobres víctimes

PS: Una conversa sentida a l'avió (també real):
1- Que frio! En XXXX teniamos 22 grados durante la noche
2- ¿En la sombra?

Idioma

2009-10-16T07:36:00.000+02:00

En tots els projectes en que he participat, hem emprat el català en el codi. Això s'ha fet sense cap discussió, semblava que la opinió era unànime. Però, i si no haguera estat així? i si hi hagués hagut divisió d'opinions?

Suposo que tots els raonaments haurien estat fets a posteriori. Vull que es faci en català, quins arguments puc emprar? Desgraciadament sembla quasi impossible procedir d'altre forma en aquesta qüestió.

Pensant-ho fredament, quin idioma s'hauria d'emprar? o, millor: quins arguments hi pot haver per decantar-se per un idioma o un altre?

Una llengua, si intentem treure factors emocionals que l'enrevolten, és (en l'àmbit que ara ens interessa) una eina de comunicació, i com a tal l'hem d'analitzar en el nostre cas. Quin idioma complirà millor la tasca d'expressar el significat del nostre codi?

Descomposaria aquesta capacitat en dues propietats diferents: l'univers de persones que podrà llegir el nostre codi i la capacitat expressiva d'aquest idioma en l'àmbit que desenvolupam.

Anem al primer punt: qui podrà entendre el nostre codi. En aquest cas hi ha factors quantitatius evidents: el nombre de persones que podran treballar en el nostre codi serà molt major si ho fem en castellà, que si ho fem en català. Tots dos, per la seva banda, seran molt inferiors al que tendrem si emprem l'angles. En l'àmbit que treballem, aquestes diferències són pràcticament inexistents (gent de les illes), però se'ns poden ocórrer fàcilment motius per ampliar aquest àmbit. Per exemple, deixar l'aplicació a altres comunitats o fer-la codi lliure. Un altre exemple, accedir a serveis de consultoria externa. Si ho fem en angles podrem treballar més fàcilment amb els experts més qualificats en una determinada tecnologia.

I que hi ha de la capacitat expressiva que aconseguim amb l'idioma emprat? En principi un podria pensar que és gairebé equivalent en tots ells. O que només és pot veure afectat per el nivell que tenen els programadors (encara que no ho sembli, escric millor en català que en angles;-) ). Hi ha lògica en això. Però hi ha gent que pot objectar coses importants (bàsicament, els seguidors de l'anomenat Domain Driven Design). Aquesta gent diria que és un valor importantíssim desenvolupar un llenguatge comú entre desenvolupadors i clients que estigui present en tots els àmbits: comunicació directe, documentació, codi, taules, etc. Desenvolupar aquest llenguatge no es tant triar quina paraula emprarem per expressar cada concepte sinó esforçarnos per enraonar amb els mateixos conceptes. No dir habitació si els professionals del sector empren el terme "unitat d'allotjament". Però més que això, entendre per que el terme habitació no és exacte i s'empra l'altre.

Aquesta tasca serà molt més fàcil si emprem el mateix idioma en el que s'expresen els usuaris, la documentació oficial i les altres aplicacions que conviuran amb la nostra. En el nostre cas, aplicacions per la Conselleria d'Educació, el català és la llengua més adient. Si l'aplicació hagués de gestionar la docència a totes les comunitats, això canviaria.

Afegiria, però, que la solidesa d'aquest segon factor està condicionat a la importància que donem al model del domini. Si a l'hora de fer l'anàlisi, el criteri emprat és "basta per implementar els requeriments" poca importància té que hagem de traduir els termes emprats del català al castellà o l'angles.

tancat?

2009-09-25T15:30:00.000+02:00

Sense portatil, crec que aquest bloc estara un temps aturat: -(

Robatori

2009-09-12T19:18:00.000+02:00

Un mal dia.

M'han robat un parell de coses del cotxe quan estavem nedant a Alcanada. Una bossa on l'atlota tenia el passaport, la camara de fotos, targetes de banc i altres, i una altra bossa on duia dos portàtils, el que empro per treballar a casa i un antic on juga la nina.

Havia agafat el portàtil per acabar de preparar el curs de desenvolupament amb JBoss que comença dilluns.

Quasi tot ho tenia al subversion de la feina, però no havia pujat els projectes amb els exercicis, ni una darrera presentació.

Ara estic preparant a contrarellotge tot el que falta. Espero poder arrivar amb alguna cosa presentable.

Que hi farem ...

Esborrats

2009-09-09T21:03:00.000+02:00

Excelent article sobre l'esborrat d'entitats.

Vist via en Gavin King

Crec que falta comentar que quan ens plantejem un esborrat hi pot haver dues situacions al darrera:

Una acció sobre l'entitat que identifiquem com a eliminació. El cas tractat a l'article.
Desfer una creació incorrecte. És a dir, esborrem un producte per que ens hem equivocat a l'entrada. Aquest producte no ha existit mai. En aquest sentit, sí és correcte l'eliminació.

Què vols ser de major?

2009-08-22T22:00:00.000+02:00

Recordo vagament que hem feien la pregunta quan era petit. No sé que contestava, futbolista, policia, bomber o alguna cosa que surtis per la tele, suposo. També jo demano això a la meva filla major. Ella me contesta metjesa. Ja veurem, la pregunta és més un joc que no una predicció.

Jo al final m'he fet programador, ara tinc 35 anys i a la feina torna a sortir la pregunta: i tú, que vols ser de major?

Buf, programador, suposo. Però per la reacció de l'interlocutor sembla que la resposta és igual de lògica que si a n'en Messi li demanen que vol fer als 50 anys i contesta seguir de davanter al Barça. Així que torna-m'hi. Que vull ser de major?

Com que sembla que t'expulsen de la feina de triada, has de mirar quines opcions te queden. En l'àmbit en el que estic hi ha dos camins típics: informàtic funcionari o professor a instituts. Cap de les dues opcions m'estira massa. Posats a triar, aniria a oposicions però sembla que a partir d'ara hi haurà poques places.

Sense entrar en el terreny de "mel i sucre" de treballar per l'administració, l'altre possibilitat que sol apareixer és la de convertir-te en cap. O sigui, entrar més en tasques de gestió. Vaig fer una llista de les deu qualitats principals d'un cap i vaig fallar en onze (una era posar nombres a les llistes per no descontar-me).

Fent l'exercici de retirar les opcions que m'agraden però sembla que no puc fer (programar), les que no m'agraden (funcionari, professor) o les que no valc (jefe, gigolo, futbolista, etc.), que triaria del que queda?

Per ara se m'ocorren dues coses que m'agradaria fer:

treballar en un equip de test. És un tema que me interessa de fa temps i hi vaig fent lectures en "background". A més, me fa l'efecte que els problemes de la meva "vellesa" que m'impediran seguir programant no tindran tant d'efecte en les tasques de fer proves.
donar classes a la universitat. Ja sé que he dit que no m'agrada la docència, però són els adolescents els que no m'agraden. Me fan por ;-). Crec que amb alumnes universitaris sí que m'agradaria. Pot ser una any d'aquests intenti entrar com a professor extern (ara no sé quin nom li donaven a això).

El que sí que temp clar que és que d'aquí a 15 anys no se programarà com avui així que el més important és llegir moltíssim i entendre el que està vinguent de nou. Al manco intentarem posar-lis difícil el retirar-mos.

Problemes, causes i solucions

2009-07-19T17:36:00.000+02:00

Que van de bé a vegades les crítiques.

A un mateix no, que això molesta i som molt sensibles. Però sí als altres. En concret, al Java, que és al que em dedico.

La proliferació de nous entorns i llenguatges ha fet evidents alguns defectes molt importants del desenvolupament tradicional en Java. No té sentit negarlos, ja que són evidents. El que sí es pot debatre és si aquests defectes són inherents al propi llenguatge, i per tant, no hi ha solució possible, o bé si són per la forma actual de plantejar algunes coses.

Tot això ve a que trobo que el Java (entorn, no llenguatge) està responent bé als reptes plantejats.

Anem als problemes més comentats.

Cicle codificació - prova

Un dels defectes importants són els temps de desplegament per poder provar canvis en el nostre codi. L'altre dia parlava d'una forma de fer que el contenidor tingués accés als nostres canvis en fitxers JSPs o estàtics sense haver de redesplegar el context Web. Clar que això és una part petita.

Un pot argumentar, amb raó, que els canvis més freqüents són en el codi Java. Per això es pot fer servir una eina que, per ara, m'ha convençut plenament: el JRebel. En la nostra aplicació (EJBs, Servlets, més de 2500 classes ...) puc provar un canvi en una classe Java directament al JBoss en uns 2 o 3 segons!. Segur que altres entorns ho poden fer una mica més ràpid, però no molt més. Me falta poder augmentar la velocitat de prova d'un canvi a una classe de domini (o que afecti a Hibernate) però ja arribarà.

Tot això afegit a que el fet de que moltes coses es poden (i s'haurien) de provar amb proves unitàries, d'execució molt ràpida, fa que al llarg del dia les aturades de servidor o redesplegaments es puguin reduir a un nombre molt baix.

Complexitat

La complexitat de les tecnologies d'infrastructura estan en bon camí de la ma d'Spring. En cada versió es fa més fàcil resoldre coses com l'ús de les connexions, accessos a serveis remots etc.

Buf, molt curt i gens argumentat, però m'interessa anar als següents ;-)

Productivitat

Pel que fa a la productivitat, per aquí hi ha dos camins. Seguir el camí "dinàmic" amb "convention over configuration" o Groovy, Grails, Griffons i companyia o mantenir-se en la línia ortodoxa: tipat i fora "màgia". En aquest segon cas hi ha una eina que ens ajuda a tenir una versió funcionant en pocs minuts: Spring Roo. Aquesta eina ens genera tot el codi "pesat" i de "copy-paste" de cada projecte amb un parell de sentències.

La raó de emprar Spring Roo és atacar el problema de la productivitat amb èxit però disposar de tota la infrastructura Spring tradicional per poder afrontar aplicacions més complexes.

Aquest és un problema complexe. Per un costat tenim molt de codi idèntic. L'hem generat ràpid, però encara el tenim. Sabem dels problemes de les duplicitats. Necessitem moltíssim més codi per fer una interacció bàsica i típica que l'equivalent amb Grails. Ara bé, tot el que Grails no escriu es basa en convencions que fan que el nostre codi sigui una mica "màgic". Màgic en sentit negatiu: l'aplicació fa coses que no són explícites al codi. Clar que no s'ha de confondre màgic amb aleatòries, tot està ben definit, només que no en el nostre codi, sinó en l'entorn.

També hem de tractar aquesta qüestió quan emprant Spring, hem de decidir fins quin punt emprem les annotacions per retirar l'XML de configuració. Es pot arrivar a deixar un XML quasi buid però no sempre ens convé renunciar a la definició centralitzada que suposa l'application-context.

Llenguatge

Les crítiques més doloroses, en la meva opinió, són les que fan referència al propi llenguatge. En Java necessitem moltes volteres per implementar coses senzilles com "retorna la nota mitjana dels alumnes d'aquesta llista, considerant només els aprovats". Aquí sovint se identifica aquesta limitació per la naturalesa "tipada" del Java. De fet, es sol contrastar la "xapussaria" que ha de fer el Java amb solucions fetes en llenguatges dinàmics, que ho resolen de forma (molt) senzilla i (molt) elegant. "Lo cortés no quita lo valiente" ;-)

Estan sortint algunes llibreries que faciliten resoldre algun petit subconjunt d'aquests problemes. En particular, m'ha agradat molt el google-collections, però ja dic, no tracta ni de bon troç l'arrel del problema. Donat que el llenguatge ja té els seus anys i s'està mostrant conservador, cal cercar ajuda fora d'ell.

I fora d'ell trobam tot un conjunt de llenguatges com Groovy i Scala que aporten aire fresc a on abans només hi havia humitats. L'avantatge d'aquests llenguatges és que s'executen a la mateixa màquina virtual, oferint interoperabilitat amb el codi Java. És a dir, podem seguir desenvolupament en Java però fer un mòdul en Groovy si aquest llenguatge és més adient per les responsabilitats del mòdul.

Vull dir amb tot això que el Java aguantarà l'envestida que reb?. No. Ni idea del que passarà. Pot ser el Java hagui d'acabar dient alguna cosa com "Als que m'heu de matar: moltes gràcies"

Només dic que degut al que han proposat els llenguatges i entorns alternatius, avui desenvolupar en Java és molt millor que fa un parell d'anys.

Millorant la productivitat en aplicacions web J2EE

2009-07-05T18:45:00.000+02:00

Una de les protestes més habituals que hi ha quan es desenvolupa en J2EE, és el temps que s'està per provar una cosa.

El cicle escriure, compilar, crear war (i/o ear), desplegar, provar i tornar a començar pot ser desesperant.

L'inconvenient és més notable si el que volem fer és canviar un simple html, o javascript o fins i tot un JSP.

Vaig a proporcionar un petit "truc" que vos pot ajudar si patiu el que hem dit abans.

Per començar heu de tenir, si no ho teniu, una estructura de directoris idèntica a la que queda al war. És a dir, un directori WEB-INF amb el web.xml, un directori classes i altres trastos per el contenidor, i a l'arrel els JSPs i continguts estàtics. A aquest directori poseu-li el nom que tendria el war, per exemple aplicacio.war.

Tot fet?, seguim.

La idea és indicar al servidor que aquest directori, l'aplicacio.war (sí, és estrany noms de directori amb extensió, però no hi faceu cas), ha de ser desplegat.

Per començar arrenquem el servidor JBoss de forma normal. Fet això ens situem amb la consola al directori bin del JBoss. Allà hi ha un script per enviar comandes al JBoss: el twiddle.

Bàsicament al twiddle podem enviar via la línia de comandes el que es pot fer via l'aplicació jmx-console. El que direm serà: desplega l'aplicació que està al directori X (on X és el nostre aplicacio.war). Au idò:

C:\java\jboss\jboss-3.2.7-caib1\bin>twiddle -s localhost invoke "jboss.system:service=MainDeployer" deploy "file:/C:/la_vostra_ruta/aplicacio.war/"

I això és tot. Als logs del JBoss hauria de sortir una cosa semblant a:

18:22:15,109 INFO [TomcatDeployer] deploy, ctxPath=/aplicacio, warUrl=file:/C:/la_vostra_ruta/aplicacio.war/

Anau amb el navegador a alguna pàgina de la vostra aplicació. Va bé?

Si vos ha fallat comprovau que heu posat la barra final. Si no la poseu JBoss no arrancarà el desplegament d'un directori sinó el de un fitxer war, que no és el cas.

Si vos falla amb el jboss-3.2.8-caib5, mala sort, aquesta versió no està soportada en aquest blog. Sincerament, vos aconsello que desenvolupeu en un altre JBoss i tengueu una màquina amb la versió jboss-3.2.8-caib5 per provar de tant en quant que tot funciona.

Seguim? Bé, suposo que tot vos ha anat bé. Ara ve l'efecte "uau". Amb el vostre editor modificau un fitxer jsp (o html, css etc.). Guardeu els canvis i refrescau el navegador. Xulo eh? Res de redesplegar aplicacions per veure els canvis en els fitxers modificats.

Si és a on feis feina habitualment, això ha de multiplicar la vostra productivitat. Fàcilment es passa d'un temps de 15 segons o un minut (en funció del tamany de l'aplicació) a un de 2 o 3 segons.

En cas de canviar el web.xml, o recompilar un servlet executem la comanda anterior però ara canviant el deploy per un redeploy:

C:\java\jboss\jboss-3.2.7-caib1\bin>twiddle -s localhost invoke "jboss.system:service=MainDeployer" redeploy "file:/C:/la_vostra_ruta/aplicacio.war/"

Encara en aquest cas hi hauria d'haver una millora important en el temps de prova degut a que no s'ha de empaquetar, moure i desempaquetar tot el contingut de la part web.

Aquesta estratègia es pot emprar encara que tingueu EJBs (eecs) o fins hi tot Hibernate (aaaah). Simplement els altres components els desplegau en artefactes separats (ears, jars o wars, segons el cas) i feis que la vostra aplicació web accedeixi a ells via JNDI.

Espero que vos sigui útil!

Google collections

2009-04-19T19:48:00.000+02:00

Una de les coses que més m'agrada del que he vist de Groovy són els closures (no és propi de Groovy, però és on ho he vist). És el lloc on més evident se m'ha fet la quantitat de codi que arrives a escriure per expresar una funcionalitat evident.

Com que per ara no podem emprar Groovy, he pegat una ullada al google-collections. Evidentment no fa tot el que es poden fer amb els closures, però pot substituir-lo en algun cas d'ús.

Aquí hi ha algunes proves:


final Alumne DANI = new Alumne(2L, "Dani");
final Alumne PEP = new Alumne(1L, "Pep");

Multimap <Alumne, Matricula> matricules = ArrayListMultimap.create();

System.out.println("carrega a partir de tuples alumne - matricula");

// això, amb els collection, es un rollo. Ara queda molt bé:
matricules.put(PEP, new Matricula(1L, "mates", PEP));
matricules.put(PEP, new Matricula(2L, "fisica", PEP));
matricules.put(DANI, new Matricula(3L, "fisica", DANI));

System.out.println("----------- totes les matricules per alumnes -----------");
for(Alumne alumne : matricules.keySet()) {
   System.out.println("matricules de : " + alumne.getNom());
   for (Matricula matricula: matricules.get(alumne)) {
       System.out.println("- " + matricula.getEstudis());
   }
}

System.out.println("----------- acumulat -----------");
System.out.println("nombre de matricules d'en pep : " + matricules.keys().count(PEP));

System.out.println("----------- matricules de fisica -----------");
final Iterable<Matricula> matriculesDeFisica = Iterables.filter(matricules.values(), new Predicate<Matricula>() {
   public boolean apply(Matricula input) {
      return input.getEstudis().equals("fisica");
   }
});


for (Matricula matricula : matriculesDeFisica) {
   System.out.println("matricula = " + matricula.getAlumne());
}


final Ordering<Map.Entry<Alumne,Collection<Matricula>>> comparadorPerNombreDeMatricules =
Ordering.natural().onResultOf(new Function<Map.Entry<Alumne,Collection<Matricula>>, Comparable>() {
    public Comparable apply(Map.Entry<Alumne,Collection<Matricula>> matriculesDeAlumne) {
 return matriculesDeAlumne.getValue().size();
    }
});

final Map.Entry<Alumne, Collection<Matricula>> alumneAmbMesMatricules =
Collections.max(matricules.asMap().entrySet(), comparadorPerNombreDeMatricules);
System.out.print("alumne amb mes matricules : " + alumneAmbMesMatricules.getKey().getNom());;
System.out.println(" te : " + alumneAmbMesMatricules.getValue().size() + " matricules");


System.out.println("----------- Creem estructura estudi -> alumnes ----------- ");
Multimap<String, Alumne> alumnesPerEstudi = ArrayListMultimap.create();
for (Map.Entry<Alumne, Matricula> tupla : matricules.entries()) {
   alumnesPerEstudi.put(tupla.getValue().getEstudis(), tupla.getKey());
}

System.out.println("tots els alumnes ");
for(String estudis : alumnesPerEstudi.keySet()) {
   System.out.println("matricules de : " + estudis);
   for (Alumne alumne: alumnesPerEstudi.get(estudis)) {
      System.out.println("- " + alumne);
   }
}

Me falta mirar-ho més. Algunes de les coses anteriors me fa l'efecte que s'han de poder fer de forma més senzilla.

Publicitat de cursos gratuïts

2009-04-04T14:40:00.000+02:00

Volia incorporar publicitat a l'entrada anterior i m'he oblidat. Quin comercial que som :-(

Ja s'han iniciat els cursos de Java i familia que faig a la CAEB. Són cursos gratuits per gent que treballi, estigui d'autònom o a l'atur. No hi poden participar els treballadors de l'administració.

Els cursos es fan de dilluns a divendres de 16:00 a 19:00 a les oficines de la CAEB. Hi ha cursos d'Ajax, Spring, Hibernate, JBoss i altres.

Aquí teniu el catàleg

Si algú es vol apuntar pot trobar la informació a la CAEB

Es important que la gent interessada s'apunti en les properes dues setmanes (encara que el curs es faci després de l'estiu ! ). El motiu és que d'aquí poc es recolliran les fitxes dels interessats, és farà la selecció, i fins i tot, es cancelaran els cursos que no tinguin un mínim d'apuntats.

Ens veiem els cursos, o no ;-)

Discusions

2009-04-04T14:22:00.000+02:00

... fa molt de temps ..

Cada matí vaig amb el bus que passa per Selva a les 6:30. Feia poc temps de la instalació del sistema de targeta per pagar els viatges amb tren i bus, i aquest era el tema de moda en les conversacions amb els conductors. El fet que aquests sapiguessen que jo soc programador feia el tema encara més obligatori.

El conductor protestava del fet que la targeta reconeixia correctament el fet que agafar primer el bus i després el tren formava part d'un mateix viatge (consumia només un dels viatges que hi havia a la targeta), però no a l'enreves. És a dir, si el trajecte era Palma - Selva, el tren et restava un viatge (correcte) però llavors, al pujar el bus, la màquina et consumia un segon viatge (error).

El conductor me interrogava sobre el per que es torbaven tant en corregir això. El diàleg va ser una cosa així:

Conductor - no entenc per que ho fa bé amb un sentit i amb l'altre no

jo - s'hauria de mirar com està fet. Pot ser les màquines del tren i les del bus son diferents o hi pot haver altres coses que no sabem

c - això no és així (gran expresió). Si ho fa bé en un sentit i en l'altre no és fàcil d'arreglar. Així com deixes passar la corrent en un sentit, la deixes passar en un altre.

Aquí vaig necessitar uns instants per assimilar l'afirmació anterior.

jo (ja recuperat) - No. Això no va així (a mí no me va quedar tan bé). El programa no veu l'electricitat, treballa d'una altra forma.

Conductor - Ja ho sé que no veu la corrent. Es molt poca. Però si atures la corrent l'ordinador deixa de funcionar, no?

jo - Sí (vaig haver d'admetre)

Conductor - idò (sentencià)

Vaig passar la resta del viatge pensant que si no havia guanyat aquesta discusió ja no en guanyaria cap a la meva vida.

.... a dia d'avui

Amb aquests antecedents comprendreu quin és el meu ànim quan he de discutir un tema tècnic amb un company. Si al meu capet en una frase apareixen les paraules discutir i tècnic, un nom sortirà de forma automàtica. Hola ja saps qui ;-)

El company afirmà que es troba més còmode quan un cas d'ús es troba implementat en un sol mètode. Definir capes, com ara la de servei i la de repositori o dao, només fan més difícil localitzar les errades. La reutilització dels mètodes més granulars, per exemple els de la capa dao, és una mite.

També vaig necessitar un temps per recuperarme de l'afirmació però no tant ja que no m'agafà massa per sorpresa. Aquesta qüestió surt molt sovint. Recordo fa temps parlar amb una persona d'un nivell tècnic molt alt, que desjectà l'ús d'Spring. Trobava que era molt pràctic que el fluix del codi, des del moment en que s'inicia el cas d'ús fins que es resol fos evident. Capes i dependències només ho complicaven. També aquesta setmana, parlant amb una altra persona d'un nivell tècnic excelent, questionava la necessitat de tenir una capa de DAOs amb EJBs 3.0. Aquest company meu diria que això s'ha convertit amb el meu "caballo de batalla".

A mí (i a molts) el que m'agrada és que cada classe i cada mètode tengui una única responsabilitat, molt clara. Forçosament això fa que un cas d'ús necessiti passar per distintes classes. Un conjunt de mètodes especialment importants son els que estan en la capa de servei. Aquests són els punts d'entrada del cas d'ús i mostren a alt nivell (delegant les operacions de més baix nivell) com se implementa el cas.

Sol succeir que, al començament, aquesta lògica és trivial. Posem que un professor abandona el centre. En aquest cas el que s'ha de fer és posar una data de baixa a un registre de la taula de destinacions. En pseudocodi:

baixaDestinacio (codiDestinacio):

ajudaBD.baixaDestinacio(codiDestinacio)

en aquest cas, sembla innecessari tenir una capa que només fa propagar les cridades a la capa de base de dades. Podriem fer:

baixaDestinacio(codiDestinacio):

// codi bbdd per fer update a la taula de destinacions

I tot més senzill, no?

El problema és quan se comença a compliar el cas. I SEMPRE passa.

Si el professor tenia permisos especials aquests s'han d'esborrar.

baixaDestinacio (codiDestinacio):

professor, centre = obteDadesDestinacio(codiDestinacio)

ajudaBD.baixaDestinacio(codiDestinacio)

ajudaDB.baixaPermisos(professor, centre)

uep... el professor pot tenir dues destinacions al centre. Només hem de donar de baixa els permisos si aquesta era la darrera destinacio.

baixaDestinacio (codiDestinacio):

professor, centre = obteDadesDestinacio(codiDestinacio)

ajudaBD.baixaDestinacio(codiDestinacio)

si ( no ajudaBD.teDestinacions(professor, centre )

ajudaDB.baixaPermisos(professor, centre)

I si hi ha diferències en cas que la destinació fos per substituir-ne una altre? o si ...

Hi ha moltes dificultats en la construcció d'un projecte. Optimitzar consultes, emprar bé les sessions, aspectes de seguretat, però una de les que més me preocupa és que les regles de negoci estiguin clarament implementades. Per clarament vull dir que les pugui veure quasi igual que com les veuria escrites en texte. Que les pugui mostrar a una persona no tècnica i amb una mica d'ajuda me pugui dir si està ben implementat. No he necessitat 80 linies de texte per explicar el que s'ha de fer quan un professor deixa una destinació i no les vull al meu mètode.

Si haguessim evolucionat aquest cas amb l'aproximació monolítica el mètode baixaDestinació tindria més de 50 línies i, encara que el codi fos fàcil, no ho seria veure amb claretat la lògica expresada en el pseudocodi anterior.

L'accés a base de dades sempre ocupa "espai" i una certa especialització. Per a que aquest espai no "enmascari" la lògica del cas d'ús és necessari implementar-la en una altre classe i exposar-la amb un nom clar.

Quan tenc temps, m'agrada "passetjar" per codi ben escrit. Un dels que hem desperta més admiració és el d'Spring. És tot un exemple de com organitzar el codi d'un sistema gran i complexe. Si intentem seguir un cas senzill, com per exemple fitxar la propietat a un bean, podem tornar beneits entre wrappers, delegates, helpers ... El cas pot ser tan senzill com fitxar un valor boolean true a una propietat d'un bean. Per que tant de trui?. Si seguim l'execució arrivem a una classe CustomBooleanEditor que converteix un String a Boolean a un mètode setAsText, gran tasca no? Bé, pot ser sigui una tasca petita però al manco està aillada amb una classe especialitzada. La classe accepta els valors yes, no, true, false, on, off, 0 i 1.

Si algun dia volem canviar això (acceptar pozi i pono) sabem on anar i és fàcil fer-ho. Només ho haurem de canviar a un lloc. Si hi ha un error reconeguent valors boolean, podem comprovar fàcilment si el problema és aquí o no. Podem escriure una classe de test que validi la lògica. Tot el codi de "pegamento" que ajunta i articula les parts involucrades en fitxar una propietat a un valor (que són moltes), no solen ser gaire relevants un cop fetes. Al arrivar el moment de mantenir i evolucionar l'aplicació són els mètodes com setAsText que han d'anar canviant. L'objectiu és treballem amb mètodes clars i centrats i no amb mètodes de 400 linies que fan el que ens interessa i 10 altres coses més.

Lliçons de la vida real

2009-03-15T10:35:00.000+01:00

Tinc la mala costum de no desconnectar gaire de la feina. Els viatges d'anada i tornada amb tren a la feina són sovint les parts més productives de la meva vida laboral. Tinc el portàtil a la sala i sempre que estic allà, encara que estigui fent altres coses, el miro de reull pensant amb el que me falta per fer. Abans de dormir no puc evitar fer balanç del fet i del que he de fer. Mala cosa.

Fa uns dies estava pensant amb la necessitat de canviar de cotxe, cosa que no podré fer fins que la hipoteca no estigui més controlada. Llavors vaig pensar amb el natural que és veure dos cotxes diferents, semblants per els ulls no experts, on un val el doble o el triple que l'altre. La qualitat, penses. I és això, clar. Tots dos et poden dur d'un lloc a l'altre, però aquí acaben les similituds. Seguretat, fiabilitat, comford, consum i tota una sèrie de paràmetres força objectius serveixen per veure les diferències entre totes dues opcions i prendre una decisió correcte. En programació costa explicar que una mateixa aplicació es pot fer amb un any o mitj o amb tres o amb més de quatre segons la qualitat que es vulgui.

En un altre moment vaig acompanyar la meva filla al bany per a que fes el que es fa allà. Quan va acabar li vaig recordar que havia d'estirar la cadena. Com la majoria de banys moderns, no hi ha cap cadena que estirar, sinó que s'ha de premer un botó per a que tot quedi net. "Bon exemple per els cursos", vaig pensar. Un cas de violació important del principi de l'abstracció és emprar noms per indicar com es fa una cosa, en lloc de que fa. Si no passa el que passa.

Cas final. Estava assegut sopant amb la família mentre la filla, que ja estava molt cansada, discutia amb la seva mare, que estava encara més cansada. Jo estava pensant amb unes coses que havia llegit de Groovy i no hi feia cas (que ho puc ser, de mala companyia !), però la meva sogra que havia llegit una revista de fer punt i no li havia creat tants dubtes, estava més pendent de la discussió. Aleshores va intentar intervenir però no va fer més que empitjorar la situació. La mare es va enfadar amb ella per interrompre. Va dir alguna cosa tipus "Fitxat amb en Domingo, que sap que ens ha de deixar fer i que ho he de resoldre jo". Evidentment jo vaig fer veure que la meva falta d'actuació era precisament per aquest motiu, i no que tingués el cap en una altre banda. On és la lliçó? Bé, està agafat una mica per els pels.

Diria que quan programam hem de confiar en una sèrie de tecnologies de les que depenem. Confiar i respectar. Està molt relacionat amb el post anterior. Necessitem entendre les motivacions i la forma d'afrontar la seva responsabilitat, de cada tecnologia emprada. HTTP, HTML, CSS, Java, Spring, Hibernate, JTA, el model relacional etc. Si no ho feim, sovint veurem com a defectes coses que no ho són, i els intents de ficar-hi ma per arreglar-ho no faran més que empitjorar la situació.

Aprofito per fer publicitat d'un curs gratuit d'eines de desenvolupament en Java que comença el dia 23 i te bastantes places lliures.

http://www.caeb.es/cursos/FichaCurso.php?id=751748

Hibernate 3

2009-03-07T09:56:00.000+01:00

Aquesta ha estat una de les setmanes més complicades a la feina. La tasca a fer era actualitzar la versió d'hibernate emprada, de la versió 2.1.6 a una versió 3.

Hi havia motius de pes per fer-ho. Dos dels que més ens afectaven era un bug a les consultes escalars que feien que les columnes sortissen desordenades. Com que el resultat el recuperaves com a un Object[], en la majoria de casos no tenia solució. L'alternativa era retornar un Data Object, però no sempre era el que te interessava.

L'altre cosa que havia molestat era que les Criteria no es podien ordenar per camps que no fossin de l'entity root. Com que quasi sempre l'ordenació es feia per una relació amb les traduccions, això descartava o dificultava l'ús de les criteria, en llocs on, per altra banda, podien fer molta bona feina.

Aquests dos motius, encara que importants, no eren determinants. Una tercera limitació molt més important i que feia molt de temps que hem llevava la son estava relacionada amb la limitació del nombre màxim de resultats d'una consulta. L'API d'Hibernate, tant la versió 2 com la 3, permet fitxar el nombre màxim de resultats en una query HQL o en una Criteria. L'SQL resultant (quan generem consultes sobre Oracle) és semblant a això:

select * from ( select camps from taula where restriccions order by ordre ) where rownum < limit

Aquesta forma, encara que sembli estranya a primera vista (no és evident que sigui cap optimització) es reconeguda per Oracle com un cas especial de consulta i fa un tractament molt eficient.

El problema està que quan Hibernate 2 generava la consulta interna (la de dins del parèntesis), posava camps duplicats a la select. Això feia que la consulta externa fos sintàcticament invàlida. És a dir, no podíem emprar, en la majoria de casos la limitació de resultats.

I això sí que és greu. A l'aplicació hi ha consultes sobre taules molt poblades. En alguns casos, si no es controla poden implicar carregar desenes de milers d'objectes en la memòria del servidor d'aplicacions, i això no pot ser mai bo per la salut del JBoss. D'ençà que hem començat el projecte vaig mantinguent mentalment una llista top-3 dels motius que poden comprometre l'estabilitat del sistema, i aquest problema, des de feia unes setmanes, anava líder.

Així que dit i fet. El canvi el veia com a imprescindible i aquesta darrera setmana s'ha fet. I, quina setmana!. Tot i que ja feia alguns dies que anava actualitzant les consultes i mapeijos per a que funcionassin amb Hibernate 3, encara s'ha hagut de fer una feinada. I suposo que encara hi haurà llocs a on aniran sortint coses.

Per que ha estat tant complicat canviar la versió d'Hibernate? Sens dubte, per que hi havia moltes coses que estaven mal fetes. Moltes coses seguien una lògica SQL impecable ... però no estaven emprant SQL sinó HQL. Amb Hibernate 2 funcionaven ... per casualitat. Amb la 3, no.

Evidentment no és fàcil canviar la forma de pensar i resoldre problemes quan es passa d'un llenguatge tan eficient i conegut com és l'SQL a un diferent, que empra una forma molt distinta de representar la informació, com és Hibernate. Hibernate fa coses millor que treballar directament damunt el model relacional, i fa coses pitjors. Tot i això, si fas una aplicació amb Hibernate, t'has d'esforçar a "adaptarte" a les seves regles.

Suposem que estàs una mica cansat de la vida d'Occident, amb el seu estres, individualisme etc. i decideixes anar-te'n a viure a la India, a un poblat més o manco retirat de les grans ciutats. Segur que trobaràs això que cerques ... però també hi haurà coses del lloc a on has viscut tota la teva vida que trobaràs a faltar. En aquest moment pots pensar alguna cosa tipus: ja ho sé, intentaré tenir el millor de les dues bandes, i t'ho penses com fer-ho per montar un cinema al poblat, un super i una cafeteria i al mateix temps no perdre les avantatges de la vida al lloc. Tots veiem el desastre que estem a punt de provocar. Simplement no funciona. Si vas allà, moltes coses que aquí son valors importants perden part del seu valor o simplement desapareixen. O bé ens adaptem a la forma de viure d'allà, ens esforcem per entendre per que fan el que fan, o bé estem comdenats a patir, més que gaudir, el nou lloc.

Alguna cosa semblat he vist a l'hora de resoldre un problema amb Hibernate. El procés mental seguit era calcular l'SQL que resol el problema i passar-ho el més semblant possible a Hibernate. Llavors sortien comentaris com "ostres, mira, resulta que s'ho menja", o "ei, sembla que això, encara que no ho entengui, o passi directament a l'SQL generat".

Aquestes coses, tard o prest s'acaben pagant. Pot ser que els natius t'aguantin les excentricitats un cert temps, però no ho faran sempre. Amb Hibernate 3 els locals s'han posat més estrictes ... però siguem positius. Segur que ara, perfectament integrats, podrem gaudir plenament de la nova vida.

Teles, URLs ...

2008-12-13T19:10:00.000+01:00

Imagina que no saps com funciona una tele. Però res, ni la més remota idea. Ve un tècnic, te la monta, la posa en marxa per veure que funciona i, mentres tu la mires hipnotitzat el tècnic diu "molt bé, ja està. M'en vaig".

La mires estona, tot satisfet fins que te canses i vols anar a dormir. Però llavors ningú t'ha dit que se pot apagar i mires com fer-ho per que el renou no te molesti. Així que la tapes amb un munt de mantes que redueixen el renou. Va bé, pots dormir ja que gairebé no se sent. L'endemà ensumes una olor rara degut a la la tele s'ha encalentit massa. Umm, se pot arreglar afegint un ventilador a la part del darrera. Perfecte. Però ara és massa feina llevar-ho tot en voler mirar la tele i montar-ho quan acabem. Així que feim lloc dins l'estructura per poder-hi ficar-nos, encara que això fa que haguem de treure un parell de mobles de la sala.

Només surt un inconvenient més quan un amic ens conte que hi ha més d'un canal, però ampliant l'habitacle per que hi càpiguen 8 teles més tot se resol (per el camí hem tombat dues parets i passat la cuina i el rebost a compartir espai amb el dormitori). Però la tele la podem veure.

A vegades, aquests tipus d'estructures les trobem en els nostres programes només per el fet de no emprar les coses de la forma en que estan pensades. Veiem bocins de codi estranyíssim que l'únic que fan és tapar defectes del codi anterior que, per cert, no saps per que és allà. Línies i línies de codi van desaparaguent com la brutor quan passes l'aspiradora. L'efecte final, al manco quan ho faig jo, és "umm, no pot ser mai que això pugui ser així. Segur que el codi feia més coses que no he estat capaç de veure".

Pot haver-hi moltes coses que originin aquestes criatures. Un cas freqüent és reinventar la roda pel fet de no mirar utilitats que ja existeixen. Per exemple, no emprar el taglib fmt per mostrar dates als JSP, o fer coses raríssimes que se resolen emprant DecimalFormat.

Tornat a les situacions originades per un ús incorrecte de la tecnologia, un exemple. Un cas al que li tenc una tirria especial és a la invenció de tècniques pròpies per l'enviament de paràmetres amb múltiples valors en una petició HTML. L'especificació està preparada per això. Tant en la seva codificació en les URLs o en el cos del POST, com en la API dels Servlets per recollir-ho. Però a vegades trobes codi que no, per alguna raó creu que és més fàcil construir dinàmicament noms únics de paràmetres. Llavors tot el codi dels servlets ja ha de fer coses estranyes per recuperar-los. O que m'en dieu de les solucions on s'envien tots els valors en un únic paràmetre emprant un caràcter especial com a separador? Uuufff.

O pot ser estigui equivocat... és més fàcil tapar la tele amb una manta que cridar a un amic per que ens digui com emprar-la.

Entities

2008-11-17T19:01:00.000+01:00

Ja fa uns mesos vaig escriure una entrada parlant d’una possible implementació del mètode equals que es comportés correctament amb els casos d’herència

D’ençà d’allò he donat moltes voltes al tema de l’herència, les diferències entre value objects i entities, implicacions en la implementació, en el modelat, etc. He escrit bastants d’esborranys però el tema s’anava fent molt gros i, ara que no hi cap en una entrada normal, no sé que fer-ne. De fet, encara tenc un munt de notes que vaig escriguent en estar al tren, que no estan desenvolupades.

Ahir estava pensant en les dificultats que me trovaba a l’hora de tractar correctament l’herència en els value objects així que vaig cercar refugi en les classes que no són value objects, les anomenades entitats ( hi ha altres tipus de classes, per exemple serveis, però a l’hora de representar “coses” les dues candidates naturals són entities i value objects ).

Per tant, vaig considerar el cas plantejat per un dels meus revisors oficials. Suposem que tenim una classe Persona, amb nom i un mètode respira. Podem tenir subclasses com per exemple Psicoleg i Informàtic que herenden els seus membres sense cap problema afegit. L’equals heretat també hauria de funcionar correctament.

Un altre exemple. Una classe Inmoble, amb un atribut adreça i subclasses Vivenda i Oficina. També tot trivial.

Exemples perfectes de relació d’herencia o es-un: Una oficina és un immoble, una vivienda és un immoble. Informàtics i psicòlegs són persones.

Ara bé, una persona pot ser informàtic i psicòleg. Si hem de poder representar això, hem de tenir una classe híbrida InformaticIPsicoleg o bé renunciar a l’herència. Qué ha fallat?

No ho tinc gaire clar. Crec que l’arrel del problema està en el nostre llenguatge. La nostra capacitat de pensar està limitada per les paraules que manejem. El verb ser inclou molts de significats diferents, i a l’hora de identificar una relació com a relació es-un mesclem ous amb caragols.

Idò, tenim Persona i hem de incorporar les distintes professions. Podem observar que la professió no forma una classificació de les persones sinó que més aviat és un atribut que les descriu.

Podríem fer psicòleg i informàtic instàncies (no subclasses) de Professió i fer que una persona tingués com atribut una col•lecció de professions. La part estàtica queda ben resolte. Però només la part estàtica.

Qué passa amb la part dinàmica? Una persona que és informàtica pot respirar (implementat a la definició de Persona) i pot escriure un HelloWorld. Com implementem això? L’herència, proposada a la primera solució, funciona molt millor que aquesta darrera proposta.

La professió d’una persona no és un atribut “normal”, sinó que afecta al possible comportament de la persona. Una forma de representar això és fer Professio una super-interfícia. Aleshores Informatic i Psicoleg serien sub-interficies de Professio, cada un amb els seus mètodes ( implementaHelloWorld i psicoanalitza ).

D’aquesta forma ja podem incorporar perfectament el polimorfisme al nostre model. Una persona que es informàtica, disposarà del mètode implementaHelloWorld. A més una persona podrà ser al mateix temps Psicoleg i Informatic. En aquest cas, a més de ser persona tindrà les capacitats especificades a les dues interfícies.

Solucionat? Noooo. Això funcionaria si, en temps d’execució, afegíssim implementacions als objectes de la classe persona. Se pot fer, per exemple amb els “introductions” de l’Aspect Oriented Programming, però no forma part del conjunt de recursos de l’orientacio a objectes “plana”.

A més, on coloquem la implementació de, per exemple, el mètode psicoanalitza? A Persona? No, només ho fan els psicolegs. A Psicoleg? No, és una interfície. Xungo.

Aquest problema apareix en molts d’altres casos. L’altre exemple posat (Inmobles i les subclasses Vivenda i Oficina) té els mateixos problemes. En aquest cas, estem parlant de l’ús que donem al inmoble. Seria molt semblant, amb tots els seus problemes, a l’exemple de les professions.

Alguna idea de com solucionar-ho sense incorporar aspectes o introspecció?

Continuarà (esper)

Primeres passes en Groovy

2008-10-23T21:14:00.001+02:00

Ja fa un temps que estic llegint material sobre Groovy i Grails.

Com sol ser habitual amb mi, la part pràctica va molt per darrera de la teòrica així que he decidit "embrutarme un poc les mans" amb el tema.

Ahir capvespre vaig fer una petita eina per tractar un dels aspectes pels que tenc una inclinació especial: la detecció de codi mort. No sé, manies meves.

En concret, el programa Groovy inspecciona tots els fitxer hbm.xml i extreu totes les consultes declarades. Després analitza tots els fitxers Java i cerca l'ús que fa de les consultes. Cada consulta emprada és eliminada de la llista. Així, al final, queden les consultes que no són emprades en cap lloc del programa.

Me n'han sortit ... moltes !!

Hem té impresionat economia d'aquest llenguatge.

Mostro el codi, encara que sé que tindrà molts de defectes (és lent, pot no detectar alguns casos ...) i segur que encara és més "javero" que "groovià". Però paciència .... no és fa tot el camí amb un dia.

class CercaConsultesNoEmprades {

Set consultes = new HashSet()

Set javas = new HashSet()

void extreuConsultesIFitxers(File file) {

print '.'

if (file.directory) {

if (file.name != '.svn')

file.eachFile {

subdirectori -> extreuConsultesIFitxers(subdirectori)

}

} else {

if (file.name.endsWith('.hbm.xml')) {

extreuConsultes file

} else if (file.name.endsWith('.java')) {

javas.add file

}

void cercaConsultesNoEmprades(File arrel) {

println 'processant fitxers'

extreuConsultesIFitxers(arrel)

println """

trobades ${consultes.size()} consultes

trobats ${javas.size()} fitxers Java

cercant consultes no emprades

"""

analitza()

}

void extreuConsultes(File file) {

def hbm = new XmlParser().parse(file)

def queries = hbm.query

for (Node query: queries) {

consultes.add query.'@name'

}

void analitza() {

for (File java : javas) {

java.eachLine {

String linia ->

def trobada = null

for (String consulta: consultes) {

if (linia.contains("\"" + consulta + "\"")) {

trobada = consulta

break

}

if (trobada != null) {

consultes.remove(trobada)

print "."

}

println """

trobades ${consultes.size()} no emprades

guardant a consultesNoEmprades.txt

les consultes no emprades

"""

File resultatConsultes = new File('consultesNoEmprades.txt')

for (String consulta: consultes) {

resultatConsultes << consulta + '\n'

}

def directori = '/treball/educacio/gestibweb/modules/logica'

new CercaConsultesNoEmprades().cercaConsultesNoEmprades(new File(directori))

avisos

2008-10-16T18:33:00.000+02:00

Estic pensant amb penjar aquest cartell al darrera meu ...

( Si voleu jugar voltros )

vist aquí

jo client

2008-10-11T21:56:00.000+02:00

Dijous passat vaig tenir l'experiència de participar a una reunió entre tècnics i clients per el desenvolupament d'un projecte informàtic. Res de nou, excepte que aquesta vegada jo era un client.

Va ser una experiència interessant. He de reconèixer que vaig estar una mica embullat, donada la novetat de la situació. Tampoc conec massa el negoci pel qual s'ha de fer l'aplicació, ja que el gestiona el meu germà.

Ens van mostrar un esborrany en paper i molt simplificat de la idea que tenien per la web. Molt senzilla, visualment espectacular, i molt centrada en resoldre la funcionalitat bàsica. La idea me va agradar molt.

Clar que la idea, bastant nova per webs d'aquest estil, te tot el que impliquen les novetats: el seu risc.

Si apostes per una idea forta, has de ser coherent. Si el 90% de les altres webs han optat per una estructura bàsicament idèntica, és per que aquesta soluciona més o manco bé una sèrie habitual de problemes. Si tu l'abandones, ho has de fer acceptant les conseqüències. Si no mantens forta la "visió" del nou sistema, i contínuament vols ficar aspectes de la solució "tradicional", acabes amb un engendre que té els defectes de totes dues parts.

Aquest risc el vaig notar quan el meu germà anava responguent a les preguntes:

Què és important?
Tot
Com és de important?
al màxim

Evidentment, no era així la conversació, però en alguns moments va semblar-s'hi perillosament.

Una altra cosa que vaig observar, estant al "lado oscuro", és que la gent sol confiar més en la seva opinió que amb la dels experts.

Si estudis mostren la importància de tenir unes opcions de cerca bàsica per disponibilitat a la primera pantalla, posa-les, encara que tú no creguis que sigui tan important. Per que, i això és una altra, no és cert que els usuaris tinguin Internet per connectar-se només a la teva web. No els hi sabrà gens de greu anar-s'en a una altra.

Després de observar una mica la l'esquema general i el seu funcionament amb distintes virgueries: multitud de fotos, flash a la presentació, ajax per un tubo ... me va sorgir una inquietud que tenc sempre en aquests casos: podrem funcionar SENSE tot això? M'agrada quan puc desactivar imatges, javascript, css, flash i tota la tropa i la web segueix operativa. Trobo que és una marca de qualitat. A més, no és només caprici, no soc expert en el tema però segur que hi ha avantatges en quan a normes d'accessibilitat o ampliació dels dispositius des dels que se pot accedir.

Encara que això darrer sigui un plus, on no soc flexible és en la necessitat de poder emprar els bookmarks, el back i el next. L'ús (o abús) de l'ajax no ho ha de posar en perill.

Tot plegat me fa pensar que pot ser ja sigui massa vell i senti enyorança de la web 1.0 ;-)

No puc dir molt més. Mitjan reunió va sortir un tema tècnic que ells plantejaven com un repte a resoldre i pensant'hi (havia llegit alguna cosa semblant al GWT in Action) vaig perdre de vista la resta de la reunió :-(

És sol dir que els metges són els pitjors pacients. Serà també que els informàtics som els pitjors clients?

GTD

2008-10-08T03:37:00.000+02:00

Sempre he tengut el defecte de tendir poc a l'acció. Vull dir que me trobo molt més còmode analitzant els problemes i moguent-me en l'abstracció que no dins del compromis d'haver de realitzar accions concretes.

Totes dues parts son necessàries, però és un gran inconvenient estar massa esbiaxat cap a un dels dos costats.

Fa un temps vaig llegir el Getting Things Done. Un llibre clàssic dels que podriem etiquetar com de "desenvolupament personal" (de fet té precisament aquesta etiqueta, "desenvolupament personal", així que si les etiquetes són úniques, el que he dit abans és fals). No soc gaire donat a n'aquests tipus de llibres, però aquest era barat, i semblava tenir molta acceptació.

M'ha agradat molt, encara que me costarà molt introduir-ho en els meus hàbits. Una cosa és tenir agradables sensacions d'estar anticipant millores mentres llegeixes el llibre, i una altra molt diferent cambiar les conductes tan arralades dins d'un mateix.

Al meu entendre, la metodologia desenvolupada per l'autor es basa en una idea central.

En primer lloc (per justificar-la), observa que la sensació d'estrés i baixa de productivitat ve del fet de tenir tot un conjunt de feines mal definides de les que ens sentim responsables. Una tasca no només ocupa el temps que esteim per solucionar-la. Tot el temps que roman indefinida, encara que no hi facem res, ocupa recursos psicològics en forma de preocupacions, distraccions i dificultats per relaxar-nos. A més tasques en aquest estat, menor és la nostra eficiència i, per tant, més tendència tenim a acumular "coses" que s'han de fer. El llibre afirma que treure totes aquestes coses ("stuff") del nivell semi-conscient i fer-ho explícit en una llista de coses per fer, fa que ens alliberem de la sensació descrita anteriorment. Això sí, ens alliberem en convertir en rutina anar realitzant tots els elements de la llista.

Ara bé, i aquesta és la idea-guia del llibre, aquesta llista de coses a fer no pot estar de qualsevol manera. Suposo que la majoria dels 4 lectors del blog han experimentat llistes de coses per fer que no avançaven en absolut durant setmanes. L'autor diu que la llista serà útil si cada entrada representa una acció física, observable i discreta en el temps.

Res d'entrades tipus: millorar la meva condició física, estar més amb els meus fills etc.
Sí a entrades tipus: divendres a les 19:30 anar a correr 30 minuts. El dia abans cridar a XX per si vol venir. Dimarts a les 18:00 anar a passetjar una hora amb la meva filla.

No m'estendre més amb el llibre ja que dos dels 4 lectors me esbroncaran, però sí que trobo que la idea s'ha de tenir en compte en les nostres tasques diàries. Exemple:

Una entrada al trac que digui: "millorar la qualitat del codi dels serveis". Quan podrem dir que està fet? Què he de fer exactament? Podem tenir un mòdul ("projecte", al llibre) que sigui "control de qualitat" però les accions concretes han de ser això "accions" i "concretes".

I que m'en dieu de les reunions on tot són temes i aportacions interessants, però on no es concreta res?. Succeeix que per acabar la discusió i passar a un altre tema algú diu: "bé, ho deixem aquí. Tu, Domingo, faras aquesta part". Buf, el què? com?. Consti que no som, el que se diu "un buen entendedor" i necessito moltes paraules, per tant moltes vegades pot ser ben bé que la culpa sigui meva.

Darrerament he començat a esforçar-me en mantenir una llista de coses per fer tal com recomana el llibre i vos puc dir amb gran exactitud tot el que havia de fer i no he fet.

truc

2008-08-23T08:33:00.000+02:00

Un breu comentari per rompre la inactivitat del bloc

En els fitxers build de l'xml sol ser habitual anar posant distints missatges que surtin per consola. La comanda per fer-ho és trivial:

<echo>Missatge a mostrar</echo>

Va bé per comprovar què s'executa, mostrar valors de les propietats, ajudar a localitzar errades etc.

El (petit) problema és que aquests missatges surten a llocs que no haurien de sortir. Per exemple, executant l'ant des de l'IntelliJ o en els reports del cruisecontrol aquests missatges surten com a warnings. Això "embruta" el procés.

Ho tenia així des de feia temps. La típica cosa que "algun dia" has de mirar, ja que tens 200 tasques més importants abans.

No sé com, fa poc vaig acabar a la pàgina de echo del manual d'ant. Allà vaig veure que hi havia un paràmetre "level" que és corresponia al nivell del missatge. level tenia valors dintre dels coneguts nivells dels logs (info, warning, debug ...). El nivell per defecte és warning!

Clar, tot explicat. Canviem tots els echo's per:

<echo level="info"> contar la meva vida </echo>

A partir d'aquí, tota la brutor desapareixia.

Te sents com després de rentar el cotxe. No és que ara tenguis un ferrari, però és més agradable.

Ei! que poc eficient! tants de paràgrafs per descriure un paràmetre de echo! m'ho he de fer mirar ;-)

Equals, equivalence and inheritance II

2008-08-04T20:43:00.000+02:00

Que era tot el trui de l'entrada anterior?

(estava en anglés per mostrar-ho al foro d'un llibre)

Volia provar de fer una implementació d'equals que complis el contracte d'aquest mètode (principalment que sigui una relació d'equivalència) inclus amb la presència de subclasses.

Anem a veure la importància d'aquest compliment.

Al llibre Effective Java posa un exemple interessant. Tenim la classe Date que evidentment té un equals ben implementat.

Ara bé, apareix la subclasse java.sql.Timestamp i esten la classe afegint un camp per els nanosegons. Ja l'hem feta, com podem comprovar amb aquest exemple:


        Date date = new Date();
        Timestamp timestamp = new Timestamp(date.getTime());
        System.out.println(" date.equals(timestamp) = " + ( date.equals(timestamp)  ));
        System.out.println(" timestamp.equals(date) = " + ( timestamp.equals(date)  ));

El resultat és:


date.equals(timestamp) = true
timestamp.equals(date) = false

greu no? més del que pareix. No podem emprar en una mateixa col·lecció elements dels dos tipus sense esperar efectes estranys.

En aquest context s'ha de aplicar la frasse del llibre:

"(...).There is no way to extend an instantiable class and add a value
component while preserving the equals contract, unless you are willing
to forgo the benefits of object-oriented abstraction."

Per abstracció, es refereix al fet que no podem implementar al equals del Date res que suposi el coneixement de com funciona la classe Timestamp. La segona és més específica, la primera més abstracte.

Penseu que en la implementació de Date no poden considerar totes les subclasses d'aquesta que s'arrivaran a fer.

Com podem resoldre el problema?

A l'entrada anterior havia preparat una solució, però tenia una errada greu. Aquesta entrada la soluciona, però hauré de païr una mica més el tema per estar segur que no té errades. També s'ha de pensar en com fer més agradable el codi, que s'ha espatllat una mica.

L'estratègia és la següent (comparem dos objectes o1 i o2).

Partim de la classe de l'objecte o1, (la implemetació inicial de l'equals). La idea és cercar la primera superclasse que tenen en comú. Mentres no la trobem anem fent super.equals (...), i comprovant que el que afegeix de nou aquesta classe, respecte la seva classe pare, té un valor que pot ser considerat null.

En trobar la superclasse comú, comencem el camí de davallada, fins la classe que defineix l'objecte o2. En iniciar aquesta devallada, s'executaran les implementacions sobre el segon objecte, que anirà mirant que tots els components que no són a la primera classe tenen un valor equivalent a null.

Esquematitzat:

suposem que c1 ..cn són les propietat comunes relevants per la identitat,
x1 .. xn són les propietats relevants per la identitat que té o1, però no o2
y1 .. yn són les propietats relevants per la identitat que té o2, però no o1

la implementació comença executant tots els equals de la jerarquia d'o1 fins la classe comuna mirant que totes les propietats xi siguin nules. Arrivada a la classe comuna mira que cada propietat ci sigui iguala als dos objectes. Després, s'inicia el recorregut per els equals d'o2 comprovant el valor null dels yi.

Les proves es fan amb les classes
Point (x,y)
ThreeDPoint (x,y,z) esten Point
ColorPoint (x,y,color) esten Point
ThreeDColorPoint (x,y,z,color) esten ColorPoint
SpecializedThreeDColorPoint (x,y,z,color) esten ColorPoint - no implementa equals ni canvia l'estat

El codi:


//Point.java:
public class Point {

    private final int x;
    private final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() { return x; }
    public int getY() { return y; }

    public boolean equals(Object o) {
        return equals(o,false);
    }

    public boolean equals (Object o, boolean reversed) {
        // null, superclass or other
        if (!(o instanceof Point)) {
            return false;
        }

        final Point other = (Point) o;

        // subclass?
        if (!reversed && ! Point.class.equals(o.getClass())) {
            return other.equals(this, true);
        }

        return equalsToPoint(other);

    }

    protected boolean equalsToPoint(Point point) {
        return (x == point.x && y == point.y);
    }

    public int hashCode() {
        return 31 * x + y;
    }

    public String toString() {
        return "point(" + x + ',' + y + ')';
    }
}

//ThreeDPoint.java
public class ThreeDPoint extends Point {
   
    private int z;

    public ThreeDPoint(int x, int y, int z) {
        super(x, y);
        this.z = z;
    }

    public boolean equals(Object o) {
        return equals(o,false);
    }

    public boolean equals (Object o, boolean reversed) {
        // null, superclass or other
        if (!(o instanceof ThreeDPoint)) {
            return z==0 && super.equals(o,reversed);
        }

        final ThreeDPoint other = (ThreeDPoint) o;

        // subclass?
        if (!reversed && ! ThreeDPoint.class.equals(o.getClass())) {
            return other.equals(this, true);
        }

        return equalsToThreeDPoint(other);

    }

    protected boolean equalsToThreeDPoint(ThreeDPoint threeDPoint) {
        if (!equalsToPoint(threeDPoint)) return false;
        return z == threeDPoint.z;

    }

    public int hashCode() {
        int result = super.hashCode();

        // z value of 0 should not affect hashCode
        if (z != 0) {
            result = 31 * result + z;
        }
        return result;
    }

    public String toString() {
        return "3DPoint(" + getX() + ',' + getY() + ',' +  z + ')';
    }

}

//ColorPoint.java
public class ColorPoint extends Point {

    private final Color color;

    public ColorPoint(int x, int y, Color color) {
        super(x, y);
        this.color = color;
    }

    public Color getColor() {
        return color;
    }

    public boolean equals(Object o) {
        return equals(o,false);
    }

    public boolean equals (Object o, boolean reversed) {
        // null, superclass or other
        if ( !(o instanceof ColorPoint)) {
            return color == null && super.equals(o,reversed); // could be equals
        }

        final ColorPoint other = (ColorPoint) o;

        // subclass?
        if (!reversed && ! ColorPoint.class.equals(o.getClass())) {
            return other.equals(this, true);
        }

        return equalsToColorPoint(other);

    }
   
    protected boolean equalsToColorPoint(ColorPoint colorPoint) {
        if (!equalsToPoint(colorPoint)) return false;

        if (color == null) return colorPoint.color == null;
        return color.equals(colorPoint.color);

    }

    public int hashCode() {
        int result = super.hashCode();
        // color null should not affect hashCode
        if (color != null) {
            result =  result + 31 * color.hashCode();
        }
        return result;
    }


    static Map<Color,String> colors = new HashMap<Color,String>(3);
    static {
        colors.put(Color.GREEN, "G");
        colors.put(Color.RED, "R");
        colors.put(Color.BLUE, "B");
    }
    public String colorToString(Color color) {
        return  colors.get(color);
    }

    public String toString() {
        return "colorPoint(" + getX() + ',' + getY() + ',' + colorToString(color) + ')';
    }
}

//ThreeDColorPoint.java
public class ThreeDColorPoint extends ColorPoint {

    private final int z;

    public ThreeDColorPoint(int x, int y, int z, Color color) {
        super(x, y, color);
        this.z = z;
    }

    public int getZ() {
        return z;
    }

    public boolean equals(Object o) {
        return equals(o,false);
    }

    public boolean equals (Object o, boolean reversed) {
        // null, superclass or other
        if (!(o instanceof ThreeDColorPoint)) {
            return z==0 && super.equals(o,reversed);
        }
 
        final ThreeDColorPoint other = (ThreeDColorPoint) o;

        // subclass?
        if (!reversed && ! ThreeDColorPoint.class.equals(o.getClass())) {
            return other.equals(this, true);
        }

        return equalsToThreeDColorPoint(other);

    }
 
    protected boolean equalsToThreeDColorPoint(ThreeDColorPoint threeDColorPoint) {
        if (!equalsToColorPoint(threeDColorPoint)) return false;
        return z == threeDColorPoint.z;

    }

    public int hashCode() {
        int result = super.hashCode();

        // z value of 0 should not affect hashCode
        if (z != 0) {
            result = 31 * result + z;
        }
        return result;
    }

    public String toString() {
        return "3DcolorPoint(" + getX() + ',' + getY() + ',' +  z + ',' + colorToString(getColor()) + ')';
    }
}

//SpecializedThreeDColorPoint.java

/**
 * change only behaviour
 */
public class SpecializedThreeDColorPoint extends ThreeDColorPoint {

    public SpecializedThreeDColorPoint(int x, int y, int z, Color color) {
        super(x, y, z, color);
    }

    // does not overwrite equals

    public void newMethod() {}

    public String toString() {
        return "specialized " + super.toString();
    }
}
// Main.java amb les proves
public class Main {

    private static final boolean DEBUG = true;

    public static void main(String[] args) {

        // test with null
        assertNotSame(new Point (1,2),null);
        assertNotSame(new ColorPoint(1,2, Color.RED),null);
        assertNotSame(new ThreeDColorPoint(1,2,3, Color.GREEN),null);
        assertNotSame(new ThreeDColorPoint(1,2,3, Color.GREEN),"Other class");


        Point[][] equivalences = {
                {new Point (1,2), new ColorPoint(1,2,null), new ThreeDColorPoint(1,2,0,null),new ThreeDPoint(1,2,0)},
                {new Point(1,3)},
                {new ColorPoint(1,4, Color.RED), new ThreeDColorPoint(1,4,0, Color.RED), new ThreeDColorPoint(1,4,0, Color.RED)},
                {new ThreeDColorPoint(1,2,3, Color.RED)},
                {new ThreeDColorPoint(1,2,0, Color.RED)},
                {new ThreeDColorPoint(1,2,3, Color.GREEN) , new SpecializedThreeDColorPoint(1,2,3,Color.GREEN)}
        };

        for (int rowIndex = 0; rowIndex < equivalences.length; rowIndex++) {
            Point[] points = equivalences[rowIndex];
            // points from same equivalence are equals
            for (int j = 0; j < points.length; j++) {
                Point point = points[j];
                for (int k = 0; k < points.length; k++) {
                    assertSame(point, points[k]);
                }
            }
            // points from other equivalences are not equals
            for (int otherRowIndex = 0; otherRowIndex < equivalences.length; otherRowIndex++) {
                if (rowIndex == otherRowIndex) continue;
                Point[] otherRow = equivalences[otherRowIndex];

                for (int i = 0; i < points.length; i++) {
                    Point point = points[i];
                    for (int j = 0; j < otherRow.length; j++) {
                        assertNotSame(point, otherRow[j]);
                    }
                }
            }
        }

    }

    private static void assertSame(Object o1, Object o2) {
        if (DEBUG) {
            System.out.println("assertSame(" + o1 + ',' + o2 + ')');
        }
        assert o1.equals(o2): o1 + "!=" + o2;
        if (o2 != null) {
            assert o1.hashCode() == o2.hashCode() : o1 + ".hashCode() != " + o2 + ".hashCode()";
        }
    }

    private static void assertNotSame(Object o1, Object o2) {
        if (DEBUG) {
            System.out.println("assertNotSame(" + o1 + ',' + o2 + ')');
        }
        assert !o1.equals(o2): o1 + "==" + o2;
        if (o2 != null) {
            assert o1.hashCode() != o2.hashCode() : o1 + ".hashCode() == " + o2 + ".hashCode()";
        }
    }
}

El resultat d'executar això és:


assertNotSame(point(1,2),null)
assertNotSame(colorPoint(1,2,R),null)
assertNotSame(3DcolorPoint(1,2,3,G),null)
assertNotSame(3DcolorPoint(1,2,3,G),Other class)
assertSame(point(1,2),point(1,2))
assertSame(point(1,2),colorPoint(1,2,null))
assertSame(point(1,2),3DcolorPoint(1,2,0,null))
assertSame(point(1,2),3DPoint(1,2,0))
assertSame(colorPoint(1,2,null),point(1,2))
assertSame(colorPoint(1,2,null),colorPoint(1,2,null))
assertSame(colorPoint(1,2,null),3DcolorPoint(1,2,0,null))
assertSame(colorPoint(1,2,null),3DPoint(1,2,0))
assertSame(3DcolorPoint(1,2,0,null),point(1,2))
assertSame(3DcolorPoint(1,2,0,null),colorPoint(1,2,null))
assertSame(3DcolorPoint(1,2,0,null),3DcolorPoint(1,2,0,null))
assertSame(3DcolorPoint(1,2,0,null),3DPoint(1,2,0))
assertSame(3DPoint(1,2,0),point(1,2))
assertSame(3DPoint(1,2,0),colorPoint(1,2,null))
assertSame(3DPoint(1,2,0),3DcolorPoint(1,2,0,null))
assertSame(3DPoint(1,2,0),3DPoint(1,2,0))
assertNotSame(point(1,2),point(1,3))
assertNotSame(colorPoint(1,2,null),point(1,3))
assertNotSame(3DcolorPoint(1,2,0,null),point(1,3))
assertNotSame(3DPoint(1,2,0),point(1,3))
assertNotSame(point(1,2),colorPoint(1,4,R))
assertNotSame(point(1,2),3DcolorPoint(1,4,0,R))
assertNotSame(point(1,2),3DcolorPoint(1,4,0,R))
assertNotSame(colorPoint(1,2,null),colorPoint(1,4,R))
assertNotSame(colorPoint(1,2,null),3DcolorPoint(1,4,0,R))
assertNotSame(colorPoint(1,2,null),3DcolorPoint(1,4,0,R))
assertNotSame(3DcolorPoint(1,2,0,null),colorPoint(1,4,R))
assertNotSame(3DcolorPoint(1,2,0,null),3DcolorPoint(1,4,0,R))
assertNotSame(3DcolorPoint(1,2,0,null),3DcolorPoint(1,4,0,R))
assertNotSame(3DPoint(1,2,0),colorPoint(1,4,R))
assertNotSame(3DPoint(1,2,0),3DcolorPoint(1,4,0,R))
assertNotSame(3DPoint(1,2,0),3DcolorPoint(1,4,0,R))
assertNotSame(point(1,2),3DcolorPoint(1,2,3,R))
assertNotSame(colorPoint(1,2,null),3DcolorPoint(1,2,3,R))
assertNotSame(3DcolorPoint(1,2,0,null),3DcolorPoint(1,2,3,R))
assertNotSame(3DPoint(1,2,0),3DcolorPoint(1,2,3,R))
assertNotSame(point(1,2),3DcolorPoint(1,2,0,R))
assertNotSame(colorPoint(1,2,null),3DcolorPoint(1,2,0,R))
assertNotSame(3DcolorPoint(1,2,0,null),3DcolorPoint(1,2,0,R))
assertNotSame(3DPoint(1,2,0),3DcolorPoint(1,2,0,R))
assertNotSame(point(1,2),3DcolorPoint(1,2,3,G))
assertNotSame(point(1,2),specialized 3DcolorPoint(1,2,3,G))
assertNotSame(colorPoint(1,2,null),3DcolorPoint(1,2,3,G))
assertNotSame(colorPoint(1,2,null),specialized 3DcolorPoint(1,2,3,G))
assertNotSame(3DcolorPoint(1,2,0,null),3DcolorPoint(1,2,3,G))
assertNotSame(3DcolorPoint(1,2,0,null),specialized 3DcolorPoint(1,2,3,G))
assertNotSame(3DPoint(1,2,0),3DcolorPoint(1,2,3,G))
assertNotSame(3DPoint(1,2,0),specialized 3DcolorPoint(1,2,3,G))
assertSame(point(1,3),point(1,3))
assertNotSame(point(1,3),point(1,2))
assertNotSame(point(1,3),colorPoint(1,2,null))
assertNotSame(point(1,3),3DcolorPoint(1,2,0,null))
assertNotSame(point(1,3),3DPoint(1,2,0))
assertNotSame(point(1,3),colorPoint(1,4,R))
assertNotSame(point(1,3),3DcolorPoint(1,4,0,R))
assertNotSame(point(1,3),3DcolorPoint(1,4,0,R))
assertNotSame(point(1,3),3DcolorPoint(1,2,3,R))
assertNotSame(point(1,3),3DcolorPoint(1,2,0,R))
assertNotSame(point(1,3),3DcolorPoint(1,2,3,G))
assertNotSame(point(1,3),specialized 3DcolorPoint(1,2,3,G))
assertSame(colorPoint(1,4,R),colorPoint(1,4,R))
assertSame(colorPoint(1,4,R),3DcolorPoint(1,4,0,R))
assertSame(colorPoint(1,4,R),3DcolorPoint(1,4,0,R))
assertSame(3DcolorPoint(1,4,0,R),colorPoint(1,4,R))
assertSame(3DcolorPoint(1,4,0,R),3DcolorPoint(1,4,0,R))
assertSame(3DcolorPoint(1,4,0,R),3DcolorPoint(1,4,0,R))
assertSame(3DcolorPoint(1,4,0,R),colorPoint(1,4,R))
assertSame(3DcolorPoint(1,4,0,R),3DcolorPoint(1,4,0,R))
assertSame(3DcolorPoint(1,4,0,R),3DcolorPoint(1,4,0,R))
assertNotSame(colorPoint(1,4,R),point(1,2))
assertNotSame(colorPoint(1,4,R),colorPoint(1,2,null))
assertNotSame(colorPoint(1,4,R),3DcolorPoint(1,2,0,null))
assertNotSame(colorPoint(1,4,R),3DPoint(1,2,0))
assertNotSame(3DcolorPoint(1,4,0,R),point(1,2))
assertNotSame(3DcolorPoint(1,4,0,R),colorPoint(1,2,null))
assertNotSame(3DcolorPoint(1,4,0,R),3DcolorPoint(1,2,0,null))
assertNotSame(3DcolorPoint(1,4,0,R),3DPoint(1,2,0))
assertNotSame(3DcolorPoint(1,4,0,R),point(1,2))
assertNotSame(3DcolorPoint(1,4,0,R),colorPoint(1,2,null))
assertNotSame(3DcolorPoint(1,4,0,R),3DcolorPoint(1,2,0,null))
assertNotSame(3DcolorPoint(1,4,0,R),3DPoint(1,2,0))
assertNotSame(colorPoint(1,4,R),point(1,3))
assertNotSame(3DcolorPoint(1,4,0,R),point(1,3))
assertNotSame(3DcolorPoint(1,4,0,R),point(1,3))
assertNotSame(colorPoint(1,4,R),3DcolorPoint(1,2,3,R))
assertNotSame(3DcolorPoint(1,4,0,R),3DcolorPoint(1,2,3,R))
assertNotSame(3DcolorPoint(1,4,0,R),3DcolorPoint(1,2,3,R))
assertNotSame(colorPoint(1,4,R),3DcolorPoint(1,2,0,R))
assertNotSame(3DcolorPoint(1,4,0,R),3DcolorPoint(1,2,0,R))
assertNotSame(3DcolorPoint(1,4,0,R),3DcolorPoint(1,2,0,R))
assertNotSame(colorPoint(1,4,R),3DcolorPoint(1,2,3,G))
assertNotSame(colorPoint(1,4,R),specialized 3DcolorPoint(1,2,3,G))
assertNotSame(3DcolorPoint(1,4,0,R),3DcolorPoint(1,2,3,G))
assertNotSame(3DcolorPoint(1,4,0,R),specialized 3DcolorPoint(1,2,3,G))
assertNotSame(3DcolorPoint(1,4,0,R),3DcolorPoint(1,2,3,G))
assertNotSame(3DcolorPoint(1,4,0,R),specialized 3DcolorPoint(1,2,3,G))
assertSame(3DcolorPoint(1,2,3,R),3DcolorPoint(1,2,3,R))
assertNotSame(3DcolorPoint(1,2,3,R),point(1,2))
assertNotSame(3DcolorPoint(1,2,3,R),colorPoint(1,2,null))
assertNotSame(3DcolorPoint(1,2,3,R),3DcolorPoint(1,2,0,null))
assertNotSame(3DcolorPoint(1,2,3,R),3DPoint(1,2,0))
assertNotSame(3DcolorPoint(1,2,3,R),point(1,3))
assertNotSame(3DcolorPoint(1,2,3,R),colorPoint(1,4,R))
assertNotSame(3DcolorPoint(1,2,3,R),3DcolorPoint(1,4,0,R))
assertNotSame(3DcolorPoint(1,2,3,R),3DcolorPoint(1,4,0,R))
assertNotSame(3DcolorPoint(1,2,3,R),3DcolorPoint(1,2,0,R))
assertNotSame(3DcolorPoint(1,2,3,R),3DcolorPoint(1,2,3,G))
assertNotSame(3DcolorPoint(1,2,3,R),specialized 3DcolorPoint(1,2,3,G))
assertSame(3DcolorPoint(1,2,0,R),3DcolorPoint(1,2,0,R))
assertNotSame(3DcolorPoint(1,2,0,R),point(1,2))
assertNotSame(3DcolorPoint(1,2,0,R),colorPoint(1,2,null))
assertNotSame(3DcolorPoint(1,2,0,R),3DcolorPoint(1,2,0,null))
assertNotSame(3DcolorPoint(1,2,0,R),3DPoint(1,2,0))
assertNotSame(3DcolorPoint(1,2,0,R),point(1,3))
assertNotSame(3DcolorPoint(1,2,0,R),colorPoint(1,4,R))
assertNotSame(3DcolorPoint(1,2,0,R),3DcolorPoint(1,4,0,R))
assertNotSame(3DcolorPoint(1,2,0,R),3DcolorPoint(1,4,0,R))
assertNotSame(3DcolorPoint(1,2,0,R),3DcolorPoint(1,2,3,R))
assertNotSame(3DcolorPoint(1,2,0,R),3DcolorPoint(1,2,3,G))
assertNotSame(3DcolorPoint(1,2,0,R),specialized 3DcolorPoint(1,2,3,G))
assertSame(3DcolorPoint(1,2,3,G),3DcolorPoint(1,2,3,G))
assertSame(3DcolorPoint(1,2,3,G),specialized 3DcolorPoint(1,2,3,G))
assertSame(specialized 3DcolorPoint(1,2,3,G),3DcolorPoint(1,2,3,G))
assertSame(specialized 3DcolorPoint(1,2,3,G),specialized 3DcolorPoint(1,2,3,G))
assertNotSame(3DcolorPoint(1,2,3,G),point(1,2))
assertNotSame(3DcolorPoint(1,2,3,G),colorPoint(1,2,null))
assertNotSame(3DcolorPoint(1,2,3,G),3DcolorPoint(1,2,0,null))
assertNotSame(3DcolorPoint(1,2,3,G),3DPoint(1,2,0))
assertNotSame(specialized 3DcolorPoint(1,2,3,G),point(1,2))
assertNotSame(specialized 3DcolorPoint(1,2,3,G),colorPoint(1,2,null))
assertNotSame(specialized 3DcolorPoint(1,2,3,G),3DcolorPoint(1,2,0,null))
assertNotSame(specialized 3DcolorPoint(1,2,3,G),3DPoint(1,2,0))
assertNotSame(3DcolorPoint(1,2,3,G),point(1,3))
assertNotSame(specialized 3DcolorPoint(1,2,3,G),point(1,3))
assertNotSame(3DcolorPoint(1,2,3,G),colorPoint(1,4,R))
assertNotSame(3DcolorPoint(1,2,3,G),3DcolorPoint(1,4,0,R))
assertNotSame(3DcolorPoint(1,2,3,G),3DcolorPoint(1,4,0,R))
assertNotSame(specialized 3DcolorPoint(1,2,3,G),colorPoint(1,4,R))
assertNotSame(specialized 3DcolorPoint(1,2,3,G),3DcolorPoint(1,4,0,R))
assertNotSame(specialized 3DcolorPoint(1,2,3,G),3DcolorPoint(1,4,0,R))
assertNotSame(3DcolorPoint(1,2,3,G),3DcolorPoint(1,2,3,R))
assertNotSame(specialized 3DcolorPoint(1,2,3,G),3DcolorPoint(1,2,3,R))
assertNotSame(3DcolorPoint(1,2,3,G),3DcolorPoint(1,2,0,R))
assertNotSame(specialized 3DcolorPoint(1,2,3,G),3DcolorPoint(1,2,0,R))

Agrairia comentaris si algú li troba algún defecte a aquesta implementació.

Equals, equivalence and inheritance

2008-08-02T18:45:00.000+02:00

** EDITED **
code need to be revised
some corrections made in http://domingosebastian.blogspot.com/2008/08/equals-equivalence-and-inheritance-ii.html
************

From Joshua Bloch's Effective Java book:

"(...).There is no way to extend an instantiable class and add a value
component while preserving the equals contract, unless you are willing
to forgo the benefits of object-oriented abstraction."

I think that is not correct, as I will try to prove:

The general structure of an equals method should be:

** EDITED **
code need to be revised
some corrections made in http://domingosebastian.blogspot.com/2008/08/equals-equivalence-and-inheritance-ii.html
************


 public boolean equals(Object o) {
       // null, superclass or other
       if (!(o instanceof [MyClass])) {
           return extraComponent== null && super.equals(o); // if could be equals or return false if not
       }

       // subclass
       if (! [MyClass].class.equals(o.getClass())) {
            return o.equals(this); // let the more specific equals do the job (open door for inheritance)
       }

       // equality for this class
       return equalsTo[MyClass](([MyClass) o);
   }

 protected boolean equalsTo[MyClass]([MyClass] other) {
     ...
 }

Let test this method with the following classes (also from Joshua's book):
A Point is a 2-dimensional point (x,y)
A ColorPoint extends Point with a color (x, y, color)
A ThreeDColorPoint extends ColorPoint with another dimension ( x,y, z, color)

two points are equals if their non zero dimension are equals and if
the color is the same or null (more clearly explained in the code).

Code for each class:

** EDITED **
code need to be revised
some corrections made in http://domingosebastian.blogspot.com/2008/08/equals-equivalence-and-inheritance-ii.html
************


// Point.java
public class Point {

   private final int x;
   private final int y;

   public Point(int x, int y) {
       this.x = x;
       this.y = y;
   }

   public int getX() {
       return x;
   }

   public int getY() {
       return y;
   }

   public boolean equals(Object o) {

       // null, superclass or other
       if (!(o instanceof Point)) return false;  // always false

       // subclass?
       if (!Point.class.equals(o.getClass())) {
           return o.equals(this);
       }

       // same class
       return equalsToPoint((Point) o);
   }

   protected boolean equalsToPoint(Point point) {
       if (x != point.x) return false;
       if (y != point.y) return false;

       return true;
   }

   public int hashCode() {
       int result;
       result = x;
       result = 31 * result + y;
       return result;
   }

   public String toString() {
       return "point(" + x + ',' + y + ')';
   }
}


// ColorPoint.java
public class ColorPoint extends Point {

   private final Color color;

   public ColorPoint(int x, int y, Color color) {
       super(x, y);
       this.color = color;
   }

   public Color getColor() {
       return color;
   }

   public boolean equals(Object o) {

       // null, superclass or other
       if (!(o instanceof ColorPoint)) {
           return color == null && super.equals(o); // could be equals
       }

       // subclass?
       if (! ColorPoint.class.equals(o.getClass())) {
           return o.equals(this);
       }

       return equalsToColorPoint((ColorPoint) o);
   }

   protected boolean equalsToColorPoint(ColorPoint colorPoint) {
       if (!equalsToPoint(colorPoint)) return false;

       if (color == null) return colorPoint.color == null;
       return color.equals(colorPoint.color);

   }

   public int hashCode() {
       int result = super.hashCode();
       // color null should not affect hashCode
       if (color != null) {
           result =  result + 31 * color.hashCode();
       }
       return result;
   }

   public String toString() {
       return "colorPoint(" + getX() + ',' + getY() + ',' + color + ')';
   }
}

//ThreeDColorPoint
public class ThreeDColorPoint extends ColorPoint {

   private final int z;

   public ThreeDColorPoint(int x, int y, int z, Color color) {
       super(x, y, color);
       this.z = z;
   }

   public int getZ() {
       return z;
   }

   public boolean equals(Object o) {

       // null, superclass or other
       if (!(o instanceof ThreeDColorPoint)) {
           return z == 0 && super.equals(o); // could be equals
       }

       // subclass?
       if (!ThreeDColorPoint.class.equals(o.getClass())) {
           return o.equals(this);
       }

       return equalsToThreeDColorPoint((ThreeDColorPoint) o);
   }

   protected boolean equalsToThreeDColorPoint(ThreeDColorPoint threeDColorPoint) {
       if (!equalsToColorPoint(threeDColorPoint)) return false;
       return z == threeDColorPoint.z;

   }

   public int hashCode() {
       int result = super.hashCode();

       // z value of 0 should not affect hashCode
       if (z != 0) {
           result = 31 * result + z;
       }
       return result;
   }

   public String toString() {
       return "3DcolorPoint(" + getX() + ',' + getY() + ',' +  z + ',' + getColor() + ')';
   }
}

We can check equivalence is honoured with this test class:


public class Main {

   private static final boolean DEBUG = true;

   public static void main(String[] args) {

       // test with null
       assertNotSame(new Point (1,2),null);
       assertNotSame(new ColorPoint(1,2, Color.RED),null);
       assertNotSame(new ThreeDColorPoint(1,2,3, Color.GREEN),null);


       // each row is a different equivalence class
       Point[][] equivalences = {
               {new Point (1,2), new ColorPoint(1,2,null), new ThreeDColorPoint(1,2,0,null)},
               {new Point(1,3)},
               {new ColorPoint(1,4, Color.RED), new ThreeDColorPoint(1,4,0, Color.RED), new ThreeDColorPoint(1,4,0,Color.RED)},
               {new ThreeDColorPoint(1,2,3, Color.RED)},
               {new ThreeDColorPoint(1,2,3, Color.GREEN)}
       };

       for (int rowIndex = 0; rowIndex < points =" equivalences[rowIndex];" j =" 0;" point =" points[j];" k =" 0;" otherrowindex =" 0;" rowindex ="="" otherrow =" equivalences[otherRowIndex];" i =" 0;" point =" points[i];" j =" 0;">assertSame(" + o1 + ',' + o2 + ')');
       }
       assert o1.equals(o2): o1 + "!=" + o2;
       if (o2 != null) {
           assert o1.hashCode() == o2.hashCode() : o1 + ".hashCode() != " + o2 + ".hashCode()";
       }
   }

   private static void assertNotSame (Object o1, Object o2) {
       if (DEBUG) {
           System.out.println("assertNotSame(" + o1 + ',' + o2 + ')');
       }
       assert !o1.equals(o2): o1 + "==" + o2;
       if (o2 != null) {
           assert o1.hashCode() != o2.hashCode() : o1 + ".hashCode() == " + o2 + ".hashCode()";
       }
   }
}

Primer de subversion : branches i merge

2008-07-27T08:33:00.000+02:00

Arrancada de cavall ...

Suposem que estem fent un projecte i ens acostem a la data de lliurement de la primera versió.

Despleguem una versió al servidor de proves, els usuaris interns fan proves, se detecten errades petites que són corregides a l'instant i se dona per bo el producte. Fantàstic, enfornem una versió i cap a producció.

Mentrestant comencem una altre iteració (o fita, milestone, sprint ...) prevista per d'aquí a tres setmanes. Se van fent commits amb la nova funcionalitat i petites millores a les coses ja existents. Tot va beníssim.

Però ... surt una errada greu al sistema en producció. Cal corregir-la ràpidament. El codi per solucionar-ho és evident. Ho feim, provem una mica la nova versió i ho enviem. No hi ha temps de fer proves tan exhaustives com les fetes en la versió anterior i la nova funcionalitat s'envia com està. La correcció és urgent.

... arrivada d'ase

Pas a producció. Desplega bé, l'errada s'ha corregida. Però el codi nou ha introduit dues errades més. Són bones de solucionar. De fet ja estan solucionades al codi més actual. Preparem una versió nova. Dos desenvolupadors diuen que no se pot fer, ja que el codi no és complet. Han de fer més commits, esperem que els facin i mirem com compila. Suposem que el codi nou és força senzill i no pot fallar (ui, ui quan pensem això...). Commit, construcció i cap a producció.

Nova versió. Mateixos problemes. En cada versió el codi està menys provat i tot s'ha fet amb més urgència.

Em entrat de ple en un cercle viciós. Cada versió és més inestable que l'anterior per estar menys provada. Errades obliguen a enviar ràpid, que obliga a reduir proves, que produeixen noves errades i torna a començar.

Anem a revisar el procés per veure que falla.

Rebobinant

La primera versió enviada tenia el codi ben provat, ja que ha estat la única que ha tingut unes proves d'acceptació tal com cal.

Detectada la primera errada greu han començat els problemes. Introduit el codi que corregeix la errada, el nostre codi tenia dues característiques:

Tenia la correcció a l'errada que ens interessa
Tenia tot el codi de la nova versió, que encara no s'havia provat de forma adient.

En aquest punt és on ens hem quedat sense gaires opcions. O esperavem a acabar i comprovar bé aquesta versió, que podia ser un parell de setmanes, o ho enviavem amb proves insuficients. La gravetat de l'errada només permetia la segona opció.

La idea

Tornant al punt anterior, quina seria la solució més interessant? Sembla clar:

Disposar a producció de la versió estable, modificant només el codi per l'errada greu
Diferir els altres canvis per una propera versió més provada

És a dir, volem fer front a les errades inevitables de producció però mantenint la planificació de les noves iteracions.

Això fa que necessitem dues versions del producte. Una de manteniment de la versió de producció, on és faran només canvis crítics, i una de desenvolupament, segons la planificació prevista.

La implementació

Emprant el subversion la solució anterior la implementarem disposant de dues branches, dues versions del mateix producte que poden evolucionar de forma independent.

Per possibilitar la solució, haurem de seguir l'estructura recomanada en els manuals introductoris de subversion. Això és: tenir com a carpetes de més alt nivell del nostre projecte les següents:

trunk : amb el codi del nostre projecte
branches : guardarà versions diferents del nostre codi (versió de desenvolupament, versió de manteniment de bugs, etc. )
tags : guardarà "congelades" distintes releases que haguem fet (versió 1.0, versió 2.1 etc. )

Inicialment branches i tags quedaran buides i només treballarem amb trunk.

Arrivat el moment de fer la primera release, farem un còpia del que hi ha a trunk a branches:


svn copy url_repositori/projecte/trunk  url_repositori/projecte/branches/branch_1_0 -m "creant branca per versió 1.0"

En aquest moment s'ha creat al servidor una còpia del projecte en l'estat actual. Damunt trunk podem seguir fent feina de forma normal, avançant cap a la següent versió. Aquests canvis no tenen cap afecte a la branca nova creada.

Detectada l'errada a producció, prepararem una versió idèntica del que hi ha actualment, afegint-hi només la solució a aquest problema.

Per això baixem una copia de la branca de la versió 1.0:


svn co url_repositori/projecte/branches/branch_1_0  projecte_1.0

Corregirem el problema, fem commit, i enviarem una nova versió. Tot fàcil, no?

La complicació: el merge

Anem a entrar, en aquest tractament minimalista dels branches, en la part més delicada: els merge.

Suposem que l'errada que hem trobat a producció també es dona a la línia actual de desenvolupament (trunk). En aquest cas voldrem aplicar el mateix canvi que hem fet al branch al trunk.

Per això hem de dir "mira subversion, aquest canvi que he fet en aquest directori (per ell tot son directoris) vull que ho facis en aquest altre", amb el seu llenguatge, clar.

Si el commit fet en el branch de la versió 1.0 ha creat la revisió 201 del projecte, per aplicar aquest canvi a trunk ens situarem a la nostra còpia local de trunk (a on volem aplicar els canvis) i executarem:


svn merge -r 200:201 url_repositori/projecte/branches/branch_1_0

És a dir, aplica les diferencies que hi ha entre la versió 201 i 200 a branch, a la meva còpia local, en aquest cas, trunk. Llavors revisarem que tot funciona i, si és així, farem un commit.

En cas de voler propagar els canvis d'un sol commit hi ha una forma més pràctica de fer-ho que és:


svn merge -c 201 url_repositori/projecte/branches/branch_1_0

La dificultat del merge no és tant entendre la sentència (que pot costar un poc al principi) com gestionar correctament que tots els canvis que interessen se passen una i només una vegada a cada branca i se integren bé amb els canvis ja fets en aquestes. Pensau que també ens pot interessar passar correccions fetes en el trunk cap a la branca de manteniment !

Per això, la recomanació és fer lliuraments de versió freqüents i no prolongar massa temps les vides de les branques.

Resumint

Encara que les branques i els merge siguin uns dels aspectes més complexes de la nostra eina de control de versions, l'esforç que facem per entendre com funcionen és molt necessari.

Ben emprades, aquestes eines en permetran respondre a bé a canvis urgents al temps que el desenvolupament normal de la nova versió no es veurà afectat. Així cada versió enviada a producció podrà passar per totes les fases de proves i controls de qualitat necessaris per lliurar-lo amb garanties.

Com podeu imaginar, hi ha molt més per tractar aquí (per exemple, ni hem mencionat els tags), però la idea era fer-ho el més reduït possible.

Preparant les emergències

2008-07-20T17:07:00.000+02:00

Anem a preparar-nos per quan les coses vagin malament.

Facem un Servlet un tant “toca-nassos” amb el següent codi.


public class ConsumidorConnexionsServlet  extends HttpServlet {

    DataSource ds;

    public void init() throws ServletException {
        try {
            Context ctx = new InitialContext();
            ds = (DataSource) ctx.lookup("nom del datasource");
        } catch (NamingException e) {
            throw new ServletException("Problemes localitzant DS", e);
        }
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws
                                  IOException, ServletException {

        Connection con = null;
        PreparedStatement pst = null;
        try {
            con = ds.getConnection();
            pst = con.prepareStatement(".. una consulta ...");
            ResultSet rst = pst.executeQuery();
            final PrintWriter out = response.getWriter();
            out.println("resultat");
            while (rst.next()) {
                out.println(rst.getString("una columna"));
            }
            rst.close();
        } catch (SQLException e) {
            throw new ServletException(e);
        } finally {
            if (pst != null) {
                try {pst.close();} catch (Exception e) {}
            }
            if (con != null) {
       //         try {con.close();} catch (Exception e) {}  COMENTAT!!
            }
        }

    }

Aquest Servlet té la fea costum d'agafar una connexió del pool de connexions i no tornar-la.

Que passarà si algú executa aquest Servlet? [emprarem el JBoss-3.2.7-caib1] En aparença res. El Servlet s'executarà correctament.
Això sí, el pool de connexions tindrà una connexió menys, però no ens enfadarem per això, no?

Posem que el pool té una màxim de 5 connexions. Ara són 4. Rebem una altre petició (3), i una altre 2, 1, 0. Ueps, que passa amb al següent? El codi se quedarà bloquejat a la línia :


 con = ds.getConnection();

ja que el pool no pot retornar més connexions, i la petició web quedarà penjada generant la resposta. Bé, no passa res ..., no ens estressem ..., la resta de l'aplicació va bé, ejem .... si no ha d'emprar la base de dades.

Però, com si fos una epidèmia, l'enfermetat comença a ocupar més recursos. Tenim una petició web penjada, això implica que hi ha un thread per peticions http que està bloquejat. Ara, cada nova petició web queda bloquejada (en intentar obtenir una connexió) i ocupant un nou thread. Aquests threads, organitzats també com un pool, s'arriven a esgotar. Ara tota l'aplicació web queda sense respondre. No hi ha activitat a la CPU, ni a la base de dades, ni logs al JBoss, però l'aplicació web no respon ... ummm, ens preocupem? Bé, al cap i a la fi, a ningú li depen la vida en aquesta aplicació, no?

Fora broma, si això ens passa a producció, no estarem gaire relaxats. Fer-ho ara a ca nostra ens permet preparar-nos per aquestes situacions.

En aquest cas, la situació s'arregla parcialment. El bloqueig iniciat al mètode getConnection() té associat un timeout i la petició acaba fallant superat aquest temps. El mètode acaba amb excepció (i un log amb informació de l'error!), s'allibera el thread per les peticions http, però el pool de connexions segueix esgotat.

[nota: el comportament del pool (nombre màxim de connexions i timeout) el podem modificar emprant el jmx-console: jboss.jca -> name=nomDS,service=ManagedConnectionPool ]

[per carregar el servidor, podeu emprar una eina tipus l'apache benchmark, el JMeter o, si no, fer-vos una classe utilitat com aquesta:


public class Executor {

    public static void main(String[] args) {

        int NOMBRE_THREADS = 20;

        for (int i = 0 ; i < NOMBRE_THREADS; i++) {
            new Thread (new Descarregador( i, "http://url_peticio")).start();
        }
    }
}

class Descarregador implements Runnable {

    int numeroThread;
    private String url;

    Descarregador(int numeroThread, String url) {
        this.numeroThread = numeroThread;
        this.url = url;
    }

    public void run() {
        System.out.println("iniciant thread " + numeroThread);
        URL url;
        try {
            url = new URL(this.url);
        } catch (MalformedURLException e) {
            throw new RuntimeException(e);
        }
        try {
            BufferedReader in = new BufferedReader(new InputStreamReader(url.openStream()));
            String str;
            while ((str = in.readLine()) != null) {
                System.out.println(str);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

]
Evidentment, reiniciar el servidor ens recuperarà el servei ... fins que torni a fallar.

Podem fer res abans d'aturar el servidor per obtenir més informació? Una solució molt interessant és fer un dump de la màquina virtual. Per això a la cònsola feiem en windows Ctrl + despl i amb linux un kill -3 (necessitem capturar la sortida estàndard)

Si ho feim ens sortirà un volcat de dades tan desagradable com, en aquest cas, útil.

Trobarem informació per cada un dels threads i ens sortiran coses així:


"http-localhost%2F127.0.0.1-8080-Processor13" daemon prio=6 tid=0x279ddfe0 nid=0xeb8 in Object.wait() [0x284ce000..0x284cfae8]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x02f964f8> (a EDU.oswego.cs.dl.util.concurrent.QueuedSemaphore$WaitQueue$WaitNode)
        at EDU.oswego.cs.dl.util.concurrent.QueuedSemaphore$WaitQueue$WaitNode.doTimedWait(QueuedSemaphore.java:123)
        - locked <0x02f964f8> (a EDU.oswego.cs.dl.util.concurrent.QueuedSemaphore$WaitQueue$WaitNode)
        at EDU.oswego.cs.dl.util.concurrent.QueuedSemaphore.attempt(QueuedSemaphore.java:47)
        at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPoo
l.java:138)
        at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnection
Pool.java:535)
        at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:
445)
        at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:298)
        at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:49
7)
        at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseCon
nectionManager2.java:888)
        at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:102)
        at prova.caiguda.ConsumidorConnexionsServlet.doGet(ConsumidorConnexionsServlet.java:38)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)

En aquesta cas es tracta d'un thread que processa peticions http i podem veure que està bloquejat al getConnection().

Més coses.

Hem vist que podem anar recollint informació del sistema en fallida per analitzar-ho (anàlisi pot-mortem). Però també podem actuar en la línia de prevenir aquestes coses, monitoritzant el funcionament del sistema.

Podem fer un Servlet que ens mostri tots els threads i el seu estat. El codi que ho fa podria ser alguna cosa com aquesta (versió minimament modificada de això):


   private void mostraThreads(PrintWriter out) {
        ThreadGroup root = obtenirRoot();

        visit(root, 0, out);
     }

    private ThreadGroup obtenirRoot() {
        ThreadGroup root = Thread.currentThread().getThreadGroup().getParent();
        while (root.getParent() != null) {
          root = root.getParent();
        }
        return root;
    }


    private void visit(ThreadGroup group, int level, PrintWriter out) {

        // Get threads in 'group'
        int numThreads = group.activeCount();
        Thread[] threads = new Thread[numThreads*2];
        numThreads = group.enumerate(threads, false);

       
        // Enumerate each thread in 'group'
        for (int i=0; i<numThreads; i++) {
            // Get thread
            Thread thread = threads[i];
            out.println(level + "  - " + thread.getName() + " - " + thread.getState());
        }

        // Get thread subgroups of 'group'
        int numGroups = group.activeGroupCount();
        ThreadGroup[] groups = new ThreadGroup[numGroups*2];
        numGroups = group.enumerate(groups, false);

        // Recursively visit each subgroup
        for (int i=0; i<numGroups; i++) {
            visit(groups[i], level+1, out);
        }
    }
}

El resultat d'executar aquest Servlet és un informe com el que segueix:


0  - Reference Handler - WAITING
0  - Finalizer - WAITING
0  - Signal Dispatcher - RUNNABLE
0  - RMI TCP Accept-1098 - RUNNABLE
0  - RMI Reaper - WAITING
0  - GC Daemon - TIMED_WAITING
0  - RMI TCP Accept-4444 - RUNNABLE
1  - DestroyJavaVM - RUNNABLE
2  - Timer-0 - TIMED_WAITING
2  - ScannerThread - TIMED_WAITING
2  - Timer-1 - WAITING
2  - ContainerBackgroundProcessor[StandardEngine[jboss.web]] - TIMED_WAITING
2  - HSQLDB Timer @152643 - TIMED_WAITING
2  - JBossMQ Cache Reference Softner - TIMED_WAITING
2  - Timer-2 - TIMED_WAITING
2  - TimeoutFactory - WAITING
2  - IdleRemover - TIMED_WAITING
2  - JCA PoolFiller - WAITING
2  - JBossLifeThread - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor1 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor2 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor3 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor4 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor5 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor6 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor7 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor8 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor9 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor10 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor11 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor12 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor13 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor14 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor15 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor16 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor17 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor18 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor19 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor20 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor21 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor22 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor23 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor24 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor25 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Monitor - TIMED_WAITING
2  - TP-Processor1 - WAITING
2  - TP-Processor2 - WAITING
2  - TP-Processor3 - WAITING
2  - TP-Processor4 - RUNNABLE
2  - TP-Monitor - TIMED_WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor1 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor2 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor3 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor4 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor5 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8443-Monitor - TIMED_WAITING
3  - ClassLoadingPool(2)-1 - RUNNABLE
4  - JBoss System Threads(1)-1 - RUNNABLE

voilà! Ja tenim una petita consola de monitorització.

Anem a fer 10 peticions al servlet


0  - Reference Handler - WAITING
0  - Finalizer - WAITING
0  - Signal Dispatcher - RUNNABLE
0  - RMI TCP Accept-1098 - RUNNABLE
0  - RMI Reaper - WAITING
0  - GC Daemon - TIMED_WAITING
0  - RMI TCP Accept-4444 - RUNNABLE
1  - DestroyJavaVM - RUNNABLE
2  - Timer-0 - TIMED_WAITING
2  - ScannerThread - TIMED_WAITING
2  - Timer-1 - WAITING
2  - ContainerBackgroundProcessor[StandardEngine[jboss.web]] - TIMED_WAITING
2  - HSQLDB Timer @8321c8 - TIMED_WAITING
2  - JBossMQ Cache Reference Softner - TIMED_WAITING
2  - Timer-2 - TIMED_WAITING
2  - TimeoutFactory - TIMED_WAITING
2  - IdleRemover - TIMED_WAITING
2  - JCA PoolFiller - TIMED_WAITING
2  - JBossLifeThread - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor1 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor2 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor3 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor4 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor5 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor6 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor7 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor8 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor9 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor10 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor11 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor12 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor13 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor14 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor15 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor16 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor17 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor18 - TIMED_WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor19 - TIMED_WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor20 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor21 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor22 - TIMED_WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor23 - TIMED_WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor24 - TIMED_WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor25 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Monitor - TIMED_WAITING
2  - TP-Processor1 - WAITING
2  - TP-Processor2 - WAITING
2  - TP-Processor3 - WAITING
2  - TP-Processor4 - RUNNABLE
2  - TP-Monitor - TIMED_WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor1 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor2 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor3 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor4 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor5 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8443-Monitor - TIMED_WAITING
3  - ClassLoadingPool(2)-1 - RUNNABLE
4  - JBoss System Threads(1)-1 - RUNNABLE

Veiem que hi ha 5 threads http-localhost en l'estat TIMED_WAITING (les 5 primeres peticions han obtingut connexió del pool i per tant s'han processat completament).

Al cap d'una estona, els bloquejos del getConnection() arriven al timeout i tots els threads tornen estar preparats per atendre peticions.

Canviem el Servlet per a que no se recuperi.

Facem que el cos del mètode doGet sigui:


while (true) {}

Facem 10 invocacions al Servlet i observem l'estat:


0  - Reference Handler - WAITING
0  - Finalizer - WAITING
0  - Signal Dispatcher - RUNNABLE
0  - RMI TCP Accept-1098 - RUNNABLE
0  - RMI Reaper - WAITING
0  - GC Daemon - TIMED_WAITING
0  - RMI TCP Accept-4444 - RUNNABLE
1  - DestroyJavaVM - RUNNABLE
2  - Timer-0 - TIMED_WAITING
2  - ScannerThread - TIMED_WAITING
2  - Timer-1 - WAITING
2  - ContainerBackgroundProcessor[StandardEngine[jboss.web]] - TIMED_WAITING
2  - HSQLDB Timer @24eafa - TIMED_WAITING
2  - JBossMQ Cache Reference Softner - TIMED_WAITING
2  - Timer-2 - TIMED_WAITING
2  - TimeoutFactory - TIMED_WAITING
2  - IdleRemover - TIMED_WAITING
2  - JCA PoolFiller - WAITING
2  - JBossLifeThread - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor1 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor2 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor3 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor4 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor5 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor6 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor7 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor8 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor9 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor10 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor11 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor12 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor13 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor14 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor15 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor16 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor17 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor18 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor19 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor20 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor21 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor22 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor23 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor24 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor25 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Monitor - TIMED_WAITING
2  - TP-Processor1 - WAITING
2  - TP-Processor2 - WAITING
2  - TP-Processor3 - WAITING
2  - TP-Processor4 - RUNNABLE
2  - TP-Monitor - TIMED_WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor1 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor2 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor3 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor4 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor5 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8443-Monitor - TIMED_WAITING
3  - ClassLoadingPool(2)-1 - RUNNABLE
4  - JBoss System Threads(1)-1 - RUNNABLE

Els threads que atenen (indefinidament) les peticions rebudes ara estan en l'estat RUNNABLE, és a dir, no hi ha cap bloqueig sinó que estan fent feina. De fet, en aquest cas l'ús de CPU pujarà cap el 100%.

Observem que passa si afegim 20 peticions més (tenim 13 threads lliures):


0  - Reference Handler - WAITING
0  - Finalizer - WAITING
0  - Signal Dispatcher - RUNNABLE
0  - RMI TCP Accept-1098 - RUNNABLE
0  - RMI Reaper - WAITING
0  - GC Daemon - TIMED_WAITING
0  - RMI TCP Accept-4444 - RUNNABLE
1  - DestroyJavaVM - RUNNABLE
2  - Timer-0 - TIMED_WAITING
2  - ScannerThread - TIMED_WAITING
2  - Timer-1 - WAITING
2  - ContainerBackgroundProcessor[StandardEngine[jboss.web]] - TIMED_WAITING
2  - HSQLDB Timer @152643 - TIMED_WAITING
2  - JBossMQ Cache Reference Softner - TIMED_WAITING
2  - Timer-2 - TIMED_WAITING
2  - TimeoutFactory - TIMED_WAITING
2  - IdleRemover - TIMED_WAITING
2  - JCA PoolFiller - WAITING
2  - JBossLifeThread - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor1 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor2 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor3 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor4 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor5 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor6 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor7 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor8 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor9 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor10 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor11 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor12 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor13 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor14 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor15 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor16 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor17 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor18 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor19 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor20 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor21 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor22 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor23 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor24 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor25 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Monitor - TIMED_WAITING
2  - TP-Processor1 - WAITING
2  - TP-Processor2 - WAITING
2  - TP-Processor3 - WAITING
2  - TP-Processor4 - RUNNABLE
2  - TP-Monitor - TIMED_WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor1 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor2 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor3 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor4 - WAITING
2  - http-localhost%2F127.0.0.1-8443-Processor5 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8443-Monitor - TIMED_WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor26 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor27 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor28 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor29 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor30 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor31 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor32 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor33 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor34 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor35 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor36 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor37 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor38 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor39 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor40 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor41 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor42 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor43 - WAITING
2  - http-localhost%2F127.0.0.1-8080-Processor44 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor45 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor46 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor47 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor48 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor49 - RUNNABLE
2  - http-localhost%2F127.0.0.1-8080-Processor50 - RUNNABLE
3  - ClassLoadingPool(2)-1 - RUNNABLE
4  - JBoss System Threads(1)-1 - RUNNABLE

S'han creat 25 threads més per atendre peticions http. Aquest comportament és bo per adaptar el servidor a puntes de càrrega però en el nostre cas només està retrassant una mort inevitable.

[L'estratègia en el manteniment del pool de threads http el podem configurar amb el jmx-console, al MBean jbossweb → name=http-localhost/127.0.0.1-8080,type=ThreadPool]

Amb el servidor patint, també el recórrer al dump ens mostrarà la causa del nostre problema. Entre totes les entrades, les dels threads ocupats mostraran un stack trace semblant a aquest:


"http-localhost%2F127.0.0.1-8080-Processor17" daemon prio=6 tid=0x27c8f818 nid=0x854 runnable [0x285cf000..0x285cfce8]
        at prova.caiguda.ConsumidorConnexionsServlet.doGet(ConsumidorConnexionsServlet.java:35)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)

Si tenim el servidor “fregit” i abans d'aturar feiem aquest dump, serà bo de trobar el punt que s'ens està menjant tota la capacitat de procés.

Orientació a objectes al projecte

2008-07-19T09:28:00.000+02:00

Des del temps de la carrera, la tasca que m'agradava i en la que me trobava més còmode era amb l'anàlisi. En aquell temps, que un ja té certa edat, l'anàlisi d'un sistema era, bàsicament, una anàlisi de dades. Sí, hi havia DFDs i coses semblants però sempre et feia la sensació que era un anàlisi de segona.

Anàlisi era pràcticament anàlisi de dades. Anàlisi i disseny era gairebé anàlisi. El disseny de les dades era un subartefacte que no aportava gaire a l'anàlisi, i el disseny de processos, si no recordo malament, eren DFDs més detallats i el disseny de la interfície d'usuari, molta feina però hem deixava el cos de que era una cosa que no encaixava gaire amb tot l'altre.

Tot allò, al meu entendre, quedava amb una anàlisi de dades i poc més. Hem trobava còmode en aquell nivell d'abstracció. M'agradava centrarme en assolir els màxims nivells de completesa, coherència i elegància en el model. Elegància era aconseguir un model en aparença senzill, però profund en quan a les seves possibilitats.

Moltes coses han canviat d'aquells dies fins ara. Probablement el que arriba més sa és l'anàlisi de dades. Aquest no ha canviat gaire. La tasca d'implementar el model de dades (ara probablement compartint lloc amb un model UML de classes), és una de les parts més tranquiles del desenvolupament. Ho dic per un parell de característiques que li són úniques:

la implementació és molt propera al model resultat de l'anàlisi
és la que té un model més consensuat per tothom
al mateix temps, sol estar en mans d'una sola persona (facilitat de control)
és la part més validada del sistema (tothom l'executa contínuament)
els diagrames faciliten el seu anàlisi
és una part molt estable (al manco comparada a les altres) conforme evoluciona el projecte

La efectivitat del model relacional i la seva tradició en el desenvolupament la fan una força gravitatòria que pot distorsionar tot la resta de codi del sistema. En el seu grau màxim, tot el codi queda degenerat a simples operacions bàsiques (CRUD) i, amb aquest, també la interfície de l'usuari.

La resta del sistema ha canviat molt més amb els anys. Així com el model relacional semblava capaç de gestionar estructures molt gran i complexes (escalava bé), el codi no gaudia d'aquesta qualitat. Un bot important foren els llenguatges orientats a objectes. Amb aquests, el codi esdevenia més expressiu, auto-explicatiu o evident. S'augmenta la complexitat que de forma més o manco eficient, un codi podia gestionar.

Emprar l'orientació a objectes per implementar la lògica de l'aplicació se troba en certes dificultats que no té la implementació del model de dades. Per començar, parla un llenguatge diferent que el seu company de treball senior, la base de dades. Problema important i molt discutit. Eines ORM (Object Relational Mapping) a l'ajuda. Com sempre feim els programadors, posem pau entre elements malentesos amb una capa. Surt el conegut com a DAO (data accés object) o Repository.

I llavors venen altres problemes. A diferència de la construcció de la base de dades, la seva construcció està més dispersa i menys negociada. Imagineu-vos com seria una base de dades on tots els desenvolupadors, amb distint grau d'experiència en models relacionals i sensibilitat d'anàlisi, puguessin anar creant totes les taules que consideressin que necessiten. El model de dades permet un nivell de "contenció" per assegurar la seva qualitat sense retrassar el desenvolupament que no és fàcil tenir a la lògica.

Un altre molt important és la interfície que proporciona aquest model. És a dir, com veuen altres parts del sistema la implementació del model (el conjunt de classes)?. Alguns, com és el codi de les proves unitàries estan feliços amb el model (llevat dels casos on s'han de crear molts objectes per les proves, però això és una altre història). D'altres, com pot ser el codi web, no n'estan tant. De que se queixa aquest? Bé, té un parell de motius bons.

Segons el model OO hi hauria d'haver tot una sèrie d'objectes "purulant" en memòria per fer la seva feina, però un servlet normalment es troba amb uns identificadors resultat del submit d'un formulari, les dades a les taules i cap objecte creat a memòria.
Encara que el model OO sigui una bona abstracció, encara és massa baix nivell per el codi web. Aquest vol accedir a una serie de serveis, equivalents a les accions amb sentit per l'usuari, no al model que l'habilita.
Hi llavors hi ha les transaccions. Les operacions s'han d'organitzar en transaccions i no sembla que el codi web sigui l'actor més adient per aquesta interpretació.

Benvinguda capa de servei. Aquesta nova capa exposa la funcionalitat del sistema a un nivell adient per el client. Aquesta capa, ben definida, respon bé a la pregunta "que pot fer el sistema?" en termes propis del domini. És, en certa manera un tercer model ( o pot ser millor, un tercer element del model) juntament amb el model relacional i l'orientat a objectes.

Crec, és una idea intuïtiva, que les diferències entre la capa de servei i la capa DAO són bon indicador de la salut de la part lògica. M'explico amb un exemple.

Estem implementant una tenda virtual i hem de mostrar el nombre màxim de articles (d'un determinat model) que pot adquirir un client. En el nostre cas, aquest nombre serà senzillament el nombre d'articles que tenim al magatzem d'aquest mateix model. Suposem que a la base de dades tenim els articles guardats com a instàncies individuals (no una taula model amb un camp nombre d'articles). Una forma d'implementar això seria carregar tots els objectes involucrats a memòria (articles i model) i executar un mètode de model que contés el nombre d'articles disponibles. Això sembla molt poc eficient.

En aquest cas és millor emprar la funcionalitat de la base de dades (select count ...) per implementar-ho. Per tant, afegiríem un mètode al DAO per fer aquest càlcul. Com ens queda el tema?


// al servei
public int nombreMaximArticlesPerCompra(long codiModel); 

// al dao
public int nombreMaximArticlesPerCompra(long codiModel);

Hi ha un problema. El veieu? El dao està a un nivell de responsabilitat que no li toca. El dao fa accés a dades, no implementació de regles de negoci. A vegades (moltes) veiem el cas invers:


// al servei
public int nombreArticlesPerModel(long codiModel); 

// al dao
public int nombreArticlesPerModel(long codiModel);

En aquest cas, la lògica (que el màxim d'articles que se poden comprar és el nombre d'articles al magatzem) està a la part web, ja que aquesta ha de decidir invocar aquest mètode per mostrar el màxim d'articles a comprar. Si volem que la lògica estigui a on ha d'estar hem de fer que cada capa exposi la funcionalitat de forma consistent amb les seves responsabilitats:


// al servei
public int nombreMaximArticlesPerCompra(long codiModel); 

// al dao
public int nombreArticlesPerModel(long codiModel);

Aquest exemple anterior mostra a més un altre cas molt freqüent. Fitxeu vos que tota la lògica queda implementada en operacions a la base de dades. Aquí sembla que era l'opció més raonable (si ningú me corregeix), però en moltes aplicacions, degut a la tradició estructurada i el comford amb l'SQL de molts programadors, és tota la lògica la que acaba en l'SQL. Les nostres classes esdevenen simples contenidores de dades i sentim un senyor barbut darrera nostra que ens diu "anemic objects! anemic objects!" (aquest). És un risc i és real.

Se pot implementar així, però llavors no feim un ús correcte de les tecnologies. En aquest cas una eina ORM probablement molesti més que ajudi. Millor JDBC, data objects i tira milles.

Advantatges que justifiquin la complexitat afegida per introduir un tipus com Hibernate al nostre grup només s'obtenen quan ens comprometem amb el model orientat a objectes plenament. És a dir, otorgem a les nostres classes el major grau de responsabilitat en la implementació de les regles de negoci. És un tema de coherència: si vols anar com els joves, amb calçons d'aquests que et cauen als genolls, la roba interior ha d'estar a l'altura. Altrament els resultats són catastròfics.

M'agradaria parlar de una altre interfície, la REST, però això ja és massa llarg.

desenvolupadors i administradors

2008-07-12T18:56:00.000+02:00

Per les característiques de l'organització per la que treballo, els equips d'explotació són gestionats per gent externa al projecte. És a dir, l'equip de desenvolupadors està aïllat de l'equip de gent al càrrec del l'administració dels sistemes en producció. A més, les polítiques de seguretat són bastant severes i tenim poc accés als servidors.

Suposo que aquesta estructura és necessària per les peculiaritats de l'organització, com passa a molts altres llocs.

A part d'arguments relatius a l'organització, aquesta postura troba una justificació en la diferència en el cos de coneixements, les eines emprades i les tasques que fan els administradors respecte als dels desenvolupadors.

Però el fet que hi hagi arguments que ho justifiquin no implica que sigui sempre la millor opció. Els problemes derivats d'aquesta separació són grans:

Un primer grup obvi de deficiències és no poder accedir a informació del sistema com ús de CPU, memòria, xarxa, etc per veure com se comporta l'aplicació en distints moments de càrrega.

En alguns casos, no saber quin és l'ús d'espai de disc o de base de dades, pot arribar a aturar el servei. Ens ha passat, per exemple, per quedar sense espai al tablespace. Conèixer deficiències de l'aplicació en aquests sentits quan abans millor és crític.

Qualsevol operació en l'entorn de producció, per exemple desplegar una versió que corregeix un bug, requereix d'en un procés lent de preparar sol·licitut / enviament de mail signat / recepció per part de l'equip de producció.

De totes, probablement la que més me molesta és no poder accedir al coneixement de l'administrador de sistemes. Ens aniria molt bé la seva ajuda per muntar un sistema semblant al de producció a escala per poder fer les proves d'acceptació i rendiment en els nostres locals. Hi ha entorn de preproducció però no és semblant al de producció en alguns aspectes importants i tampoc a aquell podem accedir-hi directament.

També aquesta falta de contacte més directe fa que sortir de les opcions "estàndards" de configuració dels sistemes d'explotació sigui molt complicat. Una "tontaria" com fer que el contingut estàtic sigui servit directament per un apache, sense passar per el servidor d'aplicacions, és una negociació esgotadora. No parlem ja de poder escollir quines versions de cada producte que forma l'arquitectura de desplegament.

No només els desenvolupadors som els perjudicats. Les aplicacions poden tenir característiques que facin la vida més fàcil als administradors. Poder deshabilitar temporalment alguns mòduls, poder avisar als usuaris d'una inminent aturada o poder accedir a dades de l'aplicació sense passar per els threads de servei http (per exemple, si queden per alguna errada queden tots bloquejats) no són molt complexes de implementar. Una comunicació directe administrador - desenvolupador pot facilitar la vida a tots dos.

Un consultor molt conegut, tenia com a pràctica habitual fer que personal d'un departament fos l'encarragat de presentar-lo i introduir-lo als altres departaments (per exemple, un membre de l'equip de desenvolupament l'havia de presentar als membres de l'equip de sistemes). Deia que molts clients afirmaven que aquesta breu "incursió" en altres territoris de la mateixa empresa havia estat tan profitos que per si sola ja justificava la consultoria.

Aquesta qüestió me recorda a una semblant que és la separació entre els usuaris i els desenvolupadors. La literatura tradicional ha construït un cos de coneixements considerable respecte a com formalitzar aquesta separació i, al mateix temps, afrontar la necessitat que tenim de saber que és el que fan i necessiten els usuaris. Estic parlant de tot el que engloba el terme anàlisi dels requeriments.

A la pràctica, la separació usuaris - desenvolupadors ha estat posada en dubte per molta gent. La separació suposa una "des-naturalització" del producte resultant que fa que no s'ajusti al que volen els usuaris. L'aplicació parla l'idioma dels desenvolupadors, que no és el mateix que el dels usuaris.

No crec que tot el dit aquí sigui diferent a l'anterior. Usuaris, desenvolupadors i administradors són tres "usuaris" del sistema, que té l'aplicació com a element central. Quan desenvolupem, el nostre codi no és encara viu. Només el veiem respirar quan observem com l'empren els usuaris, fins quin punt l'ajuden en les seves tasques, i com se comporta amb els recursos físics que té. Deia Michael Nygard a "Release It" que el desenvolupament no acaba un cop lliurat el sistema sinó que aquest és el moment en que comença. Tot el que ha passat abans només és preparació.

Evidentment, no podem tenir els tres grups en una mateixa sala, parlant tots en tots, però sí que s'ha de conèixer el preu que té el grau de separació que imposem entre tots ells. Llavors la qüestió esdevé la clàssica balança que hem de equilibrar.

Polèmiques

2008-07-05T17:22:00.000+02:00

En aquests temps amb tantes discussions :

codi lliure vs. codi privatiu
llenguatges compilats vs. llenguatges dinàmics
linux vs. microsoft
etc etc

només recordar que s'ha de respectar tot.
Com amb els editors:

Hi ha programadors amb Idea i n'hi ha sense idea, però tots igualment respetables ;-) *

* val, ho reconec, la frase no és original meva.

informàtica ficció

2008-07-02T21:40:00.000+02:00

Quan fem un bocí de codi, amb una funcionalitat més o manco completa, la podem provar per veure si funciona. Ara bé, funcionar pot significar moltes coses. Una d'elles és que la funcionalitat se implementi correctament, una altra és que sigui mantenible, eficient, escalable, etc, etc. Diguem-li atributs o qualitats.

Si fem una prova senzilla, una execució o una ullada superficial al codi, podem fer-nos una idea aproximada per cada un d'aquests atributs (correctesa, temps de resposta, mantenibilitat, etc ).

Seguint amb aquests atributs, per alguns d'ells és possible definir una espècie de bateria més formal per avaluar-la. Exemples : una prova de estres per avaluar l'eficiència, un joc de proves més o manco complet per la correctesa, etc.

Podríem dir que cada qualitat pot tenir una sèrie de dimensions en les que s'obté una mesura

L'avaluació del rendiment tendria com a dimensions el nombre de peticions totals, el nombre de peticions concurrents, el volum de informació requerit o retornat etc.
Per els jocs de proves, si són unitaris, sembla definit per els seu conjunt de paràmetres, sempre que sigui una funcionalitat sense efectes colaterals.
La mantenibilitat sembla només tenir mesures indirectes (cas típic, complexitat assignat segons una determinada mètrica)

Els tres exemples anteriors són clarament distints.

En un, el primer (proves de rendiment o estres), les dimensions eren lineals. Si no me és suficient provar 100 invocacions amb 5 threads concurrents, ho provo amb 300 amb 10 threads concurrents.

En un altre, el segon (proves de correctesa), cada prova nova requereix de descobrir valors útils per cada dimensió (paràmetre en aquest cas). Hi ha heurístiques, però només són això.

En el tercer (mantenibilitat), no hi ha ni tan sols dimensions. Podríem dir que és un únic punt. Això ens deixa en una mala situació per anticipar-nos a com la funcionalitat respondrà a futurs canvis. Com la vida mateixa, només el pas del temps ens dona una idea del seu valor real. Però llavors ja poc podem fer.

Com seria un prova d'estres de mantenibilitat? ni idea, però hauria de tenir un aspecte així:

Tenim una porteta per introduir el codi a avaluar i, a part, una serie de palanques. Suposem que ajustem una palanca a 4 requeriments nous per cada 100 requeriments i any (volatilitat dels requeriments, per dir-ho així), i l'altre li deim que ens interessa la feina a fer en 5 anys. El resultat ens diu que ens durà 10 homes / dia per any de cost de manteniment.

Llavors, igual que amb les proves d'estres, podríem avaluar la conveniència o no de refactoritzar el nostre codi.

Seria xulo no?

Comentaris al Data Quality

2008-06-20T09:11:00.000+02:00

Fa unes setmanes vaig fer una comanda de 5 llibres, un dels quals ja vaig començar a comentar.

Darrerament el tren ha fet una bona feina en la noble tasca de fomentar la lectura (assumeixo que tots el lectors són d'àmbit local), així que ja estan 4 dels 5 llegits ( Continuous Integration, Data Quality Assesment, Release It! i Scrum and XP from the Trenches ). L'altre Visualitzing Data està pendent de ser començat.

Volia acabar de donar la meva opinió del Data Quality Assessment. Els motius són per acabar de "pair" una mica el material, donar-vos una idea aproximada del que ensenya i, per que no, pot ser vos ajudi a decidir si comprar-ho o no.

Les dues primeres parts del llibre (un 60% del seu tamany), proporciona idees i estructura tipus de regles per identificar errades en les nostres dades. Ja comentava un dels casos més senzills (falsos nulls). També podem cercar "forats" temporals en registres històrics, inconsistències entre esdeveniments i estats (p.e. un registre ens diu que un treballador ha sortit de l'empresa, però el seu estat és actiu i no hi ha cap registre a l'historial amb la "re-contractació) etc, etc.

Aquesta part del llibre, tot i ser interessant, encaixa molt amb aspectes que ja hagem pogut pensar tots els que hem treballat amb base de dades. Afegiré, com aspecte negatiu, que fa massa referències a problemes d'integritat referencial, quan la majoria de lectors estic segur que empren base de dades on això ja està controlat.

Fins aquí, com dic, el llibre aporta bones idees però diguem que encara no aconsegueix "revolucionar" la teva visió del tema. I quina era la meva visió? idò això, un conjunt de regles, expressades en forma de selects o procediments senzills que et donaven tot un conjunt de registres "sospitosos" o clarament erronis.

Què fer a partir d'aquí? be, alguns pot ser els puguis arreglar tu, alguns pot ser puguis trobar la font d'informació bona, d'altres, segurament, no hi pots fer res. Però, fet això ... res més.

Aquesta situació la podríem resumir amb que la teva resposta a un "jefe" que demana "necessit un informe basat en les teves dades. Que tal estan?", només podia ser un "ppfffff.... bueno ... bastant bé... hi ha algunes errades, però ....."

Bona resposta no? enginyeria en estat pur ! ;-)

Au idò, cap a la tercera part del llibre!

Aquí és a on s'ofereix un mètode per estructurar tots els resultats individuals del procés anterior i oferir una informació el més útil possible. Es organitzar les metadades (com ens agrada aquest terme...) per catalogar tota la informació.

Molt resumit:

Tenim les dades del propi esquema de base de dades: taules i columnes.
Tenim el conjunt de regles, relacionades amb les taules i columnes que valida.
I tenim els registres individuals (les nostres dades de producció), cada una amb una certa probabilitat d'error segons li assignen les regles que estan relacionades amb la seva taula.

Tot això, després d'un procés de refinament molt important (i costos), permet tenir una idea molt més clara del que és la qualitat de les teves dades.

Anem a la pregunta del jefe:
pregunta : "necessit un informe basat en les teves dades. Que tal estan?"
resposta : "quines dades necessites per aquest informe?"
p. "és per obtenir el nombre de professors que l'any passat feien menys de 15 hores i enguant més de 15"
r. "per quin tipus de centre?"
p. "per tots"

(després de fer les consultes al catàleg)
r. "l'informe estarà basat amb unes dades que estan al 90% completes i amb una correctesa del 87%"
p. "i si només son els públics"
r. "llavors la completesa és del 94% i la correctesa del 92%"

millor no? ;-)

Llavors com sempre en la informàtica, les "fotos" amb l'estat valen per molt poc. Ràpidament caduquen. La gràcia de tota aquesta informació és que es pot anar actualitzant i ens ofereix una monitorització de l'estat de salut de la nostra base de dades. Ens pot ajudar a detectar processos de migració o usuaris que fan baixar la qualitat de les nostres dades i podem actuar en conseqüència (sempre dins dels límits legals... clar).

Decàleg per un programador novell

2008-06-01T20:57:00.000+02:00

1.- Fes canvis petits
Quan programis intenta tenir sempre una versió funcional. Programa els teus canvis en passos petits i controlats.

2.- No facis copy paste sense saber que fa el codi
Coneix com funciona cada línia del teu codi. Intenta evitar els copy - paste, però si els fas, que sigui de codi que saps explicar.

3.- Vigila els warnings del editor
Els warnings dels editors no poden ser ignorats. Entén quin és el problema. Corregil. Si hi ha algun warning que no s'aplica al teu codi, configura el teu editor per que no el mostri. Manté el codi net de warnings.

4.- Familiaritzat amb totes les eines (sobre tot l'editor)
No te conformis amb les funcionalitats mínimes de les eines. Quan demanes ajuda a un senior, intenta entendre tot el que fa. Marcat com a objectiu no haver de necessitar més la seva ajuda per un problema semblant.

5. -Demana que un senior et corregeixi el codi
Un cop tens una funcionalitat completa, revísala. Deixa-la el millor que puguis. Després, i només després d'això, demana-li a un senior que t'ho revisi i te expliqui que és millorable i perquè. Ves a berenar amb ell. Paga-li el cafè. Demana-li com va aprendre el llenguatge, les seves primeres errades, etc.

6.- Mira codi escrit per els senior
Revisa codi escrit per el senior. No ho facis per alguna funcionalitat que has de implementar o, al manco, no abans d'haver-ho intentat. Revisa com ha resolt codi que implementa una funcionalitat semblant a la que tu has implementada.

7.- Ajuda als altres novells
Oferit per ajudar als altres novells. Tot d'una que hagis après alguna cosa, explica-la als altres.

8.- Refés sense pietat el codi escrit
El primer codi sempre serà molt defectuós. Fes el possible, dins la realitat del lloc on fas feina, per corregir i refer tot el codi que vegis que no és correcte. No deixis racons del programa que saps que són incorrectes. Observa si el que has après realment millora el que tenies escrit.

9.- Llegeix algun llibre introductori
Compra, demana o roba un llibre del llenguatge. Mira que estigui ben recomanat. L'espai del que un bon autor disposa en un llibre no ho iguala cap post, tutorial, etc.

10. -No critiquis
La crítica és necessària en la nostra professió. Els dogmes de fe o les alineacions amb determinades postures de forma acrítica no són bones. Ara bé, quan estas aprenent no és el moment de fer-ho. Aparca l'esperit crític. Just aprèn, aprèn i aprèn. La crítica ja la faràs més endavant. A més, encara que hi hagi llenguatges més adients que d'altres, en tots ells, estic convençut, es possible escriure bons programes.

Animal a = new Cat ("Missy");

2008-05-31T11:48:00.000+02:00

Duc un parell de dies donant voltes al tema de llenguatges dinàmics vs compilats (o variacions en els noms/matisos que vulgueu).

És un tema important a molts nivells. Des del punt de vista teòric permet comparar de forma molt clara els recursos de cada una de les aproximacions i fer explícites les seves suposicions de partida (els seus valors, per dir-ho així). Des del punt de vista pràctic, sembla irresponsable ignorar el que problablement sigui un dels moviments en l'àmbit de la programació més importants. Com a persona que viu dins del món de la programació, estic intrigat per veure com acaba aquest moment de crisi (en un bon sentit de la paraula, com a pertorbació d'un equilibri anterior que durà a un possiblement millor).

La meva situació actual no hem permet aficar-m'hi tot el que voldria. A on faig feina, les tecnologies a emprar estan en gran mesura fora del nostre control, i les altres ocupacions professionals que tinc (formació) hem deixen poc marge de maniobre. Per tant, no puc tractar la questió com m'agradaria : aprendre python, django o similar i comparar les dues aproximacions.

N'aaloy fa uns bons resums que hem permeten agafar una idea del que hi ha al costat dinàmic. He de dir però que al seu darrer apunt m'he quedat amb "ganes de més". Crec que la part gruixada de la qüestió és a :

"Segons la nostra aplicació podem anar afegint custom managers que ens permetran definir regles damunt les dades que volem obtenir, mètodes de classe per definir les funcionalitats que vagin damunt tots els elements de la taula, i missatges que ens ajudin a manipular la informació i les seves relacions."

Hem faltaria veure algun exemple per fer-men una idea més clara de com funcionen.

En ricardo diu en un comentari

"El que mai faria es fer servir un llenguatge compilat i sense suport de hashes i arrays dinàmics."

Suposo que en el context de python o php deuen tenir un significat més concret del que conec. Estructures que empren funcions de hash, estructures tipus diccionari, o equivalents a arrays amb nombre d'elements indeterminats o amb elements heterogenis es poden tenir en Java. Si no és amb aquest sentit, simplement se m'escapa la questió :-(

Mon pare hem solia donar bons consells. Un d'ells era primer enten, després critica. Com ja he dit, no estic en condicions de fer una comparació de costat a costat. De fet, tampoc vull criticar !

Sense temps (per ara) d'aprendre python, com puc anar preparant-me per quan arrivi el moment? Pensat damunt del tema, notava que prescindir de determinats aspectes dels llenguatges compilats (en particular del Java) hem semblava “intuitivament” incòmode. Així que vaig decidir intentar concretar el bagatge que tenim, amb els advantatges que suposen. És a dir, convertir la idea intuitiva en explícita.

Per fitxar el context, hem refereixo a sistemes complexes, en els sentit de sistemes amb moltes funcionalitats, regles de negoci no trivials (es a dir, els CRUD son una part mínima), i, important, desenvolupats per més de, posem, 5 persones i que s'han de mantenir durant més de 4 anys. Amb els afegits i modificacions que hi solen haver.

Per que és important això? ho comento amb un exemple. Ens varem trobar un requeriment que era llistar el possibles noms de grups (una lletra amb majúscula) amb unes certes condicions. Un company ho va conseguir implementar amb una sola select. Era molt eficient, compacte i podia provar-se fàcilment (no s'havia d'arrancar el programa sinó que bastava una cònsola SQL). És a dir, obtenia un 10 en puntació en termes de rendiment, productivitat (linies de codi emprades) i temps per provar-ho.

Quan me la va mostrar (la consulta), la vaig mirar un parell de minuts i no vaig ser capaç de dir el que treia ! (tb la consulta)

Quin era el problema? La solució era molt enginyosa, demostrava imaginació per part del programador, però no era explícita. La llegies i no et deia que estava fent. Això pot ser poc important per alguns sistemes però no és acceptable per la situació que tracto.

Que fa que hem trobi còmode programant en Java aquest tipus d'aplicacions? Un recurs obvi per reduir la complexitat és la creació de classes. Les classes (juntament amb l'herència) permeten encapsular parts del sistema fent que la resta pugui ignorar els detalls encapsulats i treballar just els aspectes que li son propis. Evidentment, classes i herències no són pròpies dels llenguatges compilats, sinó dels OO, els quals tant poden ser estàtics com dinàmics, així que cal afinar més.

Vegem un bocí de codi tret de la wikipedia:


class Animal:

def __init__(self, name):    # Constructor of the class
      self.name = name

class Cat(Animal):
def talk(self):
     return 'Meow!'

class Dog(Animal):
def talk(self):
     return 'Woof! Woof!'

a = Cat('Missy')
b = Cat('Mr. Bojangles')
c = Dog('Lassie')

for animal in (a, b, c):
   print animal.name + ': ' + animal.talk()

No empro codi de python per criticar-lo. Simplement per centrarme en el que Java té de diferent. Pot ser el que python no té, és perque no li és necessari. S'ha d'evitar tenir solucions cercant problemes!

L'exemple anterior és un cas de polimorfisme. animal.talk invoca distintes implementacions en funció del tipus del objecte que s'executa.

En Java (a part de tenir el doble de codi per fer el mateix) la part diferent que me interessa seria:

Animal a = new Cat ("Missy");

Que ens dona el fet de tenir declarada la variable a com Animal?

La primera, obvia, és la comprovació del compilador. No li donarem més voltes ja que sembla ser la part principal i més tractada del debat que tenim entra mans.

El que me interessa és que fa explícit que, per aquesta part de codi, estem tractant amb animals. Aquesta part de la lògica és independent del tipus concret d'animal. Estem fent ús de l'abstracció animal (no de la abstracció que tenen els animals, sinó del concepte abstracte creat, animal (no, no és que et digui animal, és el nom del concepte, ejem... aturo) ) no només per evitar duplicar cert codi, sino per fer tot el problema més manejable.

Aquest ús del polimorfisme, juntament amb l'ús de les interficies amb la mateixa idea ( p.e. List elements = new ArrayList() ), és una de les principals eines que tenim per gestionar la complexitat. De fet, sovint, és una de les grans motivacions per cercar conceptes abstractes que permetin expresar de manera molt més senzilla les regles més complexes del programa.

L'abstracció, com a recurs necessari per gestionar la complexitat, implica en un moment determinat, permeter-nos ignorar determinats detalls que no són relevants al tema que tractem. Aquesta abstracció és de definició negativa: ens diu que és el que no podem fer. Amb na Missy (definida com a variable de tipus Animal), no podem emprar mètodes que són particulars de Cat. Abstracció, en aquest sentit, és contrari a flexibilitat, argument fort dels llenguatges dinàmics. Serà una cosa que anyoraré en programar en llenguatges dinàmics (si ho arrivo a fer) o no?

M'he quedat curt amb els temes que volia tractar però això ja se m'ha fet massa llarg. Continuarà.

El tipat

2008-05-25T17:18:00.000+02:00

Hem té força interessat la gran aportació que poden fer els llenguatges dinàmics a la programació en general.

Llegia l'entrada d'en gallir i tots els comentaris allà escrits i m'han vingut ganes de fer-hi alguna aportació, però m'han fugit aviat. No crec que es pugui realitzar un debat interessant amb tant de renou en forma de comentaris despectius, paternalistes, insultants i injustificats. No va per tots, es clar, per exemple aaloy es una excepció i desenvolupa de forma molt interessant el seu comentari en una entrada pròpia .

En lloc de comentar l'entrada allà vaig a alimentar una mica aquest bloc que està un poc abandonat.

Com deia, aaloy detalla alguns dels punts on podem comparar de manera bastant objectiva les dues aproximacions (compilada vs. interpretada).

Veig sentit a tot el que diu (no puc dir més ja que hem falten coneixements amb phyton o equivalents), sobre tot a les diferències en la durada dels cicles de desenvolupament. No és que necessitis un parell de segons més per poder provar l'efecte d'un petit canvi en el codi Java. És sobretot, l'efecte d'aquests segons en la teva concentració quan programes.

Trobo que falta justificar algunes frases com "El nombre de línies de codi que escriu un programador al dia és una constant.". Hem sona força contra-intuïtiva. O "...y ser el número de errores directamente proporcional al número de líneas que se escriben ..". No entro a dir si són certes o falses, però hem falta una justificació.

Però, sintetitzant, articula molt bé una serie punts sobre els que es pot establir una comparació justa entre ambdós entorns.

Deia al començament que aquesta polèmica hem té interessat, ja que trobo que pot millorar la qualitat de les nostres eines quan programem. Actualment me és impossible entrar a estudiar un entorn com python, ja que les meves ocupacions m'absorbeixen en un 110%. Però estic molt interessat en fer-ho i la meva actitud envers ell no és, ni molt manco, negativa.

Tradicionalment m'he dedicat més a desenvolupar la part de la lògica de negoci i, només marginalment, he treballat en la part de presentació. Crec que la part de presentació és la que més fàcilment pot treure profit dels entorns interpretats. En Java, l'àmbit que conec, les tecnologies per la creació de la capa web difícilment justifiquen la seva relació funcionalitat aportada / cost de desenvolupament. Ho feien fa un temps, quan la part de lògica tenia els infumables EJB CMP i germans ... . Era com en Saviola, que semblava bo devora els Retzinguer i companyia.

Programar la part de lògica és més complexe. Desenvolupar el codi de la lògica de negoci ho veig més com una tasca de modelat que com de implementació. Sovint la gènesis del programa és un anàlisi ER més o manco pensat, i després a produir CRUD com a xurros i un parell de llistats més o manco complexes. Totes les eines RAD que he vist, els 4GL d'un temps, o la demo que vaig seguir del Django mostren com poden fer això rapidissimament.

D'acord, molt bé. És una part, però no és el que cerco per fer millor la meva feina. Aproximacions com l'anterior fan que capa de negoci quedi com un simple SQL que empra classes en lloc de taules. El model de dades mostra cert coneixement de les dades emprades i tota l'aplicació es queda aquí.

Aquestes aplicacions son poc usables. Entenen les dades que hi ha, però no els processos. No s'adapten al que l'usuari té en el cap sinó que demanen que sigui l'usuari que converteixi tot el que coneix i necessita del sistema en una serie d'altes / baixes / modificacions d'elements bàsics. A més, la naturalesa sembla resistir-se a aquestes simplificacions. Els usuaris necessiten de certes regles complexes que el desenvolupament anterior no ha estudiat en detall en cap moment. No hem val l'anàlisi de dades. Allà ens demanem si les taules definides tenen tota la informació suficient per la tasca, però no es fa cap esforç de modelar aquesta regla. Aquestes regles apareixen quan el programa ja està en producció i són els canvis de requeriments que tant mal fan i dels que solem culpar als usuaris.

El camí viciat anterior és romp si feiem del desenvolupament de la lògica de negoci una tasca amb més responsabilitats. El codi d'aquesta capa no és una implementació d'una llista de requeriments. És un modelat que té en compte més coses de les que pot tractar la base de dades. S'ha d'anar fent en paralel. Es orgànic. Hi ha molt de fer i refer. Duu a crear una taula, per després separar-la i, uns dies després tornar a ajuntar-la.

El seu resultat és un conjunt de classes i interfícies ( i sí, han de ser POJOS, o al manco és el que penso avui) que creen en el nostre llenguatge el vocabulari de l'usuari. Aquest vocabulari inclou conceptes associats a informació tangible ( Alumne, Centre ...) i a processos ( CalculMitjana, Promocio, etc ). La seva evolució va des de els primer intents més o manco ingenus i intuïtius (p.e. Habitació ) cap a altres més abstractes (UnitatAllotjament) que són els que, curiosament, empren els nostres usuaris. Aquest camí implica esborrar sense pietat moltes coses fetes. La prova de foc, és aconseguir que les conversacions entre dos usuaris experts en l'àmbit que hem de implementar és dugui a terme just amb els conceptes que són explícits en el nostre codi.

Dit això, torno al tema que vull tractar a aquesta entrada.

Vull tenir molt clar, i ara no ho tenc, el que significa prescindir d'expresar en el codi tots els aspectes de tipat. No per por a cometre un error de sintaxis. Els tipus així desenvolupats no son un recurs de captura d'errors de compilació sinó la part fonamental del meu programa. No l'objectiu final, que és fer una aplicació que faciliti la vida als meus usuaris, però sí la meva eina principal per aconseguir-ho.

Data Quality (el llibre)

2008-05-09T20:04:00.000+02:00

Just he començat a llegir el llibre Data Quality Assessment, que vaig comprar per tenir una visió més completa a un problema que ja vaig comentar.

Les primeres impressions, basades en els tres primers capítols que formen la primera part "Data Quality Overview", són bones. S'ocupa en aquests capítols, com sol ser habitual, de presentar el problema tractat, mostrant la seva transcendència i donant un marc conceptual per parlar amb propietat de cada aspecte. Espero que la continuació mantengui el nivell.

Una cosa que he llegit no m'ha agradat massa. Al final del segon capítol escriu que aquest llibre és el primer d'una sèrie, sembla que 4 més, que tractarà del "data quality". Crec que a vegades els temes s'allargen artificialment. Llegirem aquest i ja veurem.

Ja al començament surten algunes idees interessants. Parla de la necessitat de fer del manteniment de la qualitat de les dades una activitat constant en el projecte i no una acció puntual en un moment donat. Per això, els resultats de l'activitat no ha de ser un document descriguent mancances o unes SQL que corregeixen els valors incorrectes. El resultat ha de ser un sistema executable que ens digui en cada moment quin és l'estat de salut de les nostres dades, juntament amb eines que ens permetin actuar-hi.

Avui al tren, el meu despatx principal, pensava que ja se poden anar fent tasques d'aquest procés de qualitat en el nostre projecte. Encara no està en producció però ja té dades reals i alguns centres estan en proves. Podríem, per exemple, anar identificant regles de consistència per les nostres dades i implementar vistes que mostrin els registres incorrectes.

Un cas: comprovar que totes les matèries a les que està matriculat un alumne són possibles donat els estudis als que està matriculat. El programa contempla aquesta regla en les seves pantalles per introduir les dades, però això no ens ha de bastar. Hi pot haver problemes per migracions, modificacions manuals, errades al programa o modificacions en altres parts del programa que no contemplen aquesta regla. La vista que mostri els registres que pateixen aquesta errada podria anar formant part de tot un catàleg amb la idea de poder monitoritzar l'estat de les nostres dades.

Tornant al llibre, m'ha agradat la definició que fa de la qualitat de les dades: "fitness for the purpose of use". M'agrada per que no és una definició estàtica. Vull dir que unes mateixes dades, sense canviar, poden baixar la seva qualitat si l'aplicació que hi ha per sobre amplia la seva funcionalitat. Aleshores, defectes que abans no importaven ara és manifesten i és necessari corregir los.

Finalment, pel que duc llegit, també he trobat molt interessat el tractament fet a l'aspecte de l'obligatorietat de certs atributs. Un pot pensar que el tema és trivial. Un camp si és obligatori es posa un not null i sinó no. I ja està. A la pràctica les coses no són tan senzilles.

Analitzant les entrades podem trobar molts de registres amb valors falsos per un determinat atribut. Per exemple DNI 99999999X. O valors sospitosament repetits. Per exemple, moltes dates de naixement de l'1 de gener de 1970. Aquests valors tenen tot l'aspecte de ser pseudo-nulls per dir-ho així. El problema pot venir de definir un camp com a obligatori quan, a efectes pràctics, s'han de introduir registres sense aquesta informació. Estaríem en un cas de constraint not null equivocada.

També pot passar a l'enreves. Per exemple tenim 10.000 registres de persones i només 100 tenen el camp telefon a null. Tot fa pensar que es tracta d'un camp que hauria de ser obligatori, i que els 100 registres amb telefon null són incorrectes o incomplets.

En la nostra aplicació ens hem trobat un cas semblant. Volíem fer que un camp sigués obligatori, però a les bases de dades "legacy" aquest camp era opcional i alguns registres no el tenien. Com ho feim en les migracions? Podríem que el procés de migració s'inseris un valor pseudo-null per aquest camp quan fos null, però ja hem dit que això no és més que un error. Al final optàrem per fer aquest camp opcional a la base de dades i obligatori a la aplicació. No és perfecte però era una solució de compromís. Està subjecte a revisions si ens arriba alguna idea millor.

Per acabar vull afegir un petit apunt d'àmbit més personal.

Avui ha deixat el seu càrrec el nostre cap d'àrea, n'Amador Calafat. Durant els dos anys que duc a la conselleria ha estat el tipus de cap que els informàtics volem. Atent a les nostres necessitats i molt pendent que puguessim fer la nostra feina en les millors condicions possibles. No sempre estava a les seves mans arreglar els problemes però per ell no quedava. Apassionat de les noves tecnologies i convençut del benefici que podia aportar el nostre projecte. Motivador i comprensiu amb les necessitats i circumstàncies de cada un de nosaltres. No hem vull allargar més ja que poden semblar els tòpics de sempre, i no ho és. Si no ho pensés no ho escriuria.

Des d'aquí desitjar-li molta sort en la seva nova etapa.

Universitat, alumnes i docència

2008-05-06T20:20:00.000+02:00

En Ricardo feia una entrada / assaig referent a la correspondència (o falta de correspondència) entre els objectius formatius d'una universitat i les necessitats de les empreses.

Cap al final, identifica una sèrie de problemes causants d'un dèficit en la formació dels alumnes:

" 1. Falta de motivación (o de pasión por la informática) de los alumnos, también de profesores, pero fundamentalmente de los alumnos, que son los al fin y al cabo los que saldrán al “mercado laboral”.
2. Falta de confianza –o coraje de jóven– que nos dice “no hay misterios, son sólo bits y bytes, si otros lo pudieron hacer yo también puedo hacerlo”. Este problema no sólo afecta a cómo se enfrentan y resuelven los problemas dentro de una empresa, sino en que hay muy pocos ingenieros que inicien proyectos innovadores por cuenta propia y con una visión “global”, es decir de vender en todo el mundo. Creo que es la causa fundamental de la carencia de ingenieros informáticos emprendedores.
3. Pretender que el estado se haga cargo del entrenamiento profesional. Es un problema empresarial, la competencia, el outsourcing, la falta de mercado hace que parezca muy caro o imposible que las empresas se hagan cargo del entrenamiento específico, y luego de la formación continua, que necesitan los nuevos ingenieros.
"

Com a estudiant (mediocrillo) i treballador (no m'avaluaré ja que hem llegeixen els jefes) no estic molt d'acord amb aquests punts. O més ben dit, els veig més com a conseqüències i no tant com a causes.

Son deficiències en la formació a la universitat les que fan als alumnes desmotivats, falts de confiança i incapaços de mantenir se actualitzats.

Crec que hi ha una concepció equivocada amb el que és la excel·lència docent. Se defineix un cos de coneixements gran i complex, unes pràctiques molt exigents i una avaluació dura. El resultat és la necessitat d'invertir un esforç molt gran per assolir la titulació, el qual deriva (suposem) directament amb un gran valor d'aquesta. Que té de bò això? molt, podem pensar. Ens ha costat molt, per tant, segur que hem après molt. A més, molts han "caigut" pel camí, per tant, esteim en una posició privilegiada a l'hora de competir per els millors llocs. Tot maravallos, no?

A la pràctica, això no és així. Aquests requeriments, si no van acompanyats d'un fort element motivador, simplement cremen. A més, el model d'avaluació fa que el més rentable sigui adoptar actituds orientades a la superació de les proves i no a la comprensió profunda de la matèria. Creen a l'alumne estratega. Gran rendiment que no va acompanyat de cap interès genuí per la matèria. Aprovat? sí, idò a guardar els apunts a la caixa i a per la següent.

Aquest alumne "estratega" com serà? motivat? difícilment. Amb molta confiança? sí, però just per els problemes que li posin a la taula, no per fer d'emprenador. Autodidacta? podeu posar la ma al foc que no.

Si ens surt un alumne així, la culpa possiblement sigui seva. Si la majoria són així, la culpa és més "ambiental". Pot ser sigui el clima, pot ser el que mengen o pot ser sigui la universitat.

La tasca del professor és clau per obtenir un altre tipus d'alumne. S'ha de fomentar un aprenentatge profund, natural, no forçat.
Que vol dir això? El que és clar és el que no vol dir. No és "transmetre" un conjunt de coneixements. Tampoc és convertir a l'alumne amb un autòmat que resol problemes.

Acabada la universitat he agafat molt de gust per la lectura de llibres tècnics. En ells veig als autors explicant per que els problemes tractats m'han de semblar importants i propis, per que creuen que aproximacions anteriors no funcionaven del tot bé, i, sobretot, entenc que aquesta nova tentativa només és això, un nou intent en un camí no acabat. El que m'ensenya l'autor me és interessant, real, natural i gairebé sempre me deixa amb ganes de més. És el que m'agradaria haver trobat a la universitat.

Pels professors, recomanar el llibre "Lo que hacen los mejores profesores universitarios" de Ken Bain

DocBook vs. Open Office

2008-04-26T16:37:00.000+02:00

Ja fa molt de temps que estic emprant com a sistema per escriure la documentació el docbook. Aquest és un estàndard XML que defineix com estructurar el contingut d'un document, principalment tècnic i que alguns dels grans projectes en codi lliure.

El motius que me dugueren a emprar-ho, en la documentació del projecte final de carrera i després en la elaboració dels manuals per els cursos foren diversos.

Es un format de text, per tant

Si passa alguna cosa estranya, sempre pots veure l'origen del problema
Se integra de forma natural en el sistema de control de versions
Si has de fer una correcció petita, ho pots fer en qualsevol editor

Al emprar XML, afegim:

Tens les regles de validació per tenir el document ben format
Pots emprar tecnologies com XInclude per dividir el document en mòduls i formar combinacions diverses (importantíssim)
Quan treballes en el document, et centres exclusivament en el contingut, sense despistar-te en la presentació
Al tenir la presentació en les plantilles XSLT, es trivial disposar de distintes versions de cada document en distints formats

Al emprar Docbook, afegeix a l'anterior:

Tens un model semàntic interessant per construir el teu document: codi, noms de classes, acrònims, referències ...
Disposes d'editors XML específics per aquesta aplicació
Disposes de plantilles de presentació ja fetes i molt correctes

Tot això ha anat molt bé i cada una de les possibilitats llistades anteriorment ha solucionat problemes molt reals.

Amb el temps, però, han sortit algunes deficiències per necessitats concretes que m'han demanat. Un, per exemple, és el format amb capçaleres i logos que me demanen a la CAEB per els manuals dels cursos. Normalment parteixo de les plantilles disponibles de XSL i només modifico alguns dels paràmetres definits. Incursions als detalls de les transformacions per controlar aquests aspectes superen els meus coneixements, molt bàsics, de XSLT i FO.
Això implica que la part final del procés de construir el document, era generar a partir del docbook un RTF, que finalment obria al word i acabava de "formatejar". Sí, tant malament com sona.

Estava disposat a conviure amb aquest problema quan l'altra dia, durant la part d'exercicis en el curs de programació amb Servlets i JSPque estic fent, vaig notar que alguna cosa no estava del tot bé. Estava mirant el manual d'un alumne, cercant un exemple de codi quan me va parèixer veure el text una mica "toston". El format està molt bé per una documentació de referència, però un manual de curs ha de ser, trobo, més visual. Una referència la llegeixes 30 vegades, amb detall, esperant que surti tot. Un manual de curs ha de saltar tot a la vista, centrar-se amb els aspectes fonamentals, ajudar-se molt dels aspectes visuals i deixar la resta de banda. Hi ha moltíssims llibres bons damunt qualsevol tema i aquest manual no està, de cap manera, per competir amb ells. I tot el que diem del manual, val encara molt més per les presentacions.

Això hem va fer pensar que pot ser, després de tant de temps, calia considerar un canvi. Per alguns texts, la part de presentació no és un tema marginal o separat del contingut, sinó que les dues coses en formen una. Per això, provaré de fer (refer) el manual d'un curs d'eines emprant el Open Office. Així podré avaluar millor quin camí seguir.

No han de fer peresa els canvis! i, si un ho diu a la feina, ha de ser coherent a ca seva!

Curs d'aplicacions Web J2EE

2008-04-20T16:34:00.000+02:00

Demà comença el curs de aplicacions web amb J2EE. Les tecnologies explicades estan basades en els requeriments de la DGTIC per desplegar aplicacions en els seus servidors.

En el contingut està inclòs el detall de les APIs dels Servlets, filtres etc, elements del web.xml, aspectes bàsics del JBoss, JSP, JSTL i semblants.

Tot això és bo d'explicar i entendre, i hi ha exercicis per anar provant-ho. El que m'agradaria, per estar realment satisfet a la finalització del curs és que els alumnes haguessin après i entès altres coses més pròpies de l'experiència que de la memorització:

Entendre com l'API dels Servlets encaixa en el funcionament del protocol HTTP. Respectar l'especificació HTTP i no anar "contra ella"
Per cada un dels elements de la API, poder donar un exemple de problema que soluciona. Fer de cada un dels mètodes explicats, un recurs que quedi a la seva "caixa d'eines" encara que s'hagi de repassar la forma exacte d'emprar-se.
Haver reflexionat sobre els aspectes transversals que afecten al sistema i com els filtres poden atacar parts d'aquests.
Diferències claus entre una solució programàtica i una declarativa. Per exemple, referent a la seguretat, tractament d'errors etc.
Diferències claus entre una solució stateless i una stateful. Us de la sessió. Avantatges i inconvenients de fer-ho.
Importància de veure les URLs de l'aplicació com una API més. Un cas molt il·lustrador és l'aproximació RESTful
Limitacions de les tecnologies explicades i vies de solució. Sobretot el patró MVC.
Rol de la capa de presentació en la resta de l'arquitectura del sistema. Que convé que faci i que no. Opcions segons la complexitat del sistema a construir.
Conèixer per on començar a cercar quan tenim un problema i no quedar bloquejats. On son els logs, intentar reproduir l'error, veure els casos més habituals etc.

Algún expert en la part web té alguna idea més per destacar? Qué demanarieu a un candidat per la vostra empresa que hagués de fer Servlets i JSPs.

the career programmer

2008-04-18T21:13:00.000+02:00

Imagineu que comprau un llibre sobre el món de la programació i veieu, en una pàgina qualsevol, això:

"Possessing no social skills that I've ever been able to discern, the arrogant big head is almost always an absolute killer programmer, the best of the best. The problem with this guy is not just his cocky, condescending, and demeaning attitude, but the fact that 9.990872 times out of 10 he can back it up. He is just that good."

I el llibre és això, un paràgraf darrera l'altra com aquest, durant 250 pàgines. Quin desastre.

El títol de l'engendre es "The career programmer" i el geni és Christopher Duncan. No sé per quin motiu ho vaig comprar. No tenia cap llibre de la appres i volia provar-ho. Era una segona edició, per tant alguna cosa bona havia de tenir ...

Quasi sempre procuro llegir un capítol d'un llibre abans de comprar-ho. Es una forma bastant segura de invertir bé els doblers. També hem guio per les opinions de gent que respecto i, en un grau menor, el "Customers Who Bought This Item Also Bought..." d'amazon. En aquest cas no vaig fer res d'això.

El meu projecte d'escriure un llibre torna a prendre força ;-)

Avisats quedau!

Errades

2008-04-15T21:39:00.000+02:00

A ningú ens agrada cometre errades. Quan en el nostre codi en trobem una el que feim és arreglar-la el més aviat possible i "commitem" els canvis. Amb un poc de sort, pocs usuaris es veuran afectats i les dades patiran poc o gens fins restaurar-se a l'estat correcte.

Moltes errades podríem qualificar-les de "tontes". Les que es produïxen quan ens equivoquem amb una expressió booleana, oblidem posar alguna condició senzilla sobre els paràmetres etc. Son els casos on teníem "al cap" la solució correcte només que errem a l'hora d'expressar-ho en codi.

Aquests tipus d'errors son els que podem eliminar just al moment que programem amb l'ús de proves unitàries. I això és un factor a tenir molt en compte: el fet que siguin "tontes" no vol dir que no ens puguin donar malts de cap importants si arriben al sistema en producció.

En el moment de corregir l'errada, ens hauríem de demanar si la qualitat del codi ha propiciat que es produeixi aquesta. Pot ser un mètode massa llarg o complexe, o les variables no tenen un nom adient, o el mètode tracta molts aspectes diferents. Tot això fa que la probabilitat de errades augmentin. El fet que se n'hagui produït una o més és una senyal de que pot ser sigui necessari refactoritzar aquesta part de codi.

Llavors hi ha altres errades que surten quan, tal com ens diuen els usuaris, el sistema no se comporta per un determinat cas com hauria de fer-ho. O, sense ser una errada te els mateixos efectes, és necessari afegir una nova funcionalitat al sistema. Els típics canvis en els requeriments que tant contents ens solen fer.

Aquí la situació és diferent. Ja no ens hem equivocat expressant en codi la nostra idea del sistema, sinó que l'errada estava en la nostra idea mateixa. En aquest cas, el camí habitual sol ser fer "els mínims canvis possibles" i intentar proporcionar, si és possible, els resultats que sol·licita l'usuari, a partir del model que implementa la nostra aplicació.

Aquesta no és una mala opció si és necessari donar una resposta ràpida. Però fer-ho així implica perdre oportunitats. El nostre model inicial mai serà perfecte, ni tampoc el segon ni el tercer .... Tenim tendència a defensar visceralment el model que tanta feina ens ha duit construir i negociar amb els companys. Tendim a veure la situació com una batalla entre el nostre model lògic i enraonat, i els canvis capritxosos dels usuaris.

Amb aquesta postura difícilment aconseguirem que la nostra aplicació evolucioni tal com augmenta el nostre coneixement en l'àmbit en que funciona la nostra aplicació.

Cada vegada que es produeix una situació així, encara que no tinguem temps per implementar-ho, convé intentar entendre bé els motius pels quals l'usuari diu que ho necessita. Estudiar quins canvis hauríem de fer al nostre model (encara que no ho facem ara) i mirar en quines altres situacions aquest "desajust" es pot manifestar.

De fet, pot ser seria interessant fer una plànol del sistema, semblant a quan surt a les pelis un amb incidències d'una epidèmia terrible, i observar quins mòduls acumulen més errades de qualsevol tipus. Segur que aquests mòduls tenen molts nombres per necessitar una refactorització o un remodelat complet.

Encara que un pot objectar:

Si els mòduls "son" d'un o d'uns pocs desenvolupadors, no es gaire agradable tenir exposats públicament les errades

No fa falta el plànol i xinxetes vermelles, basta un informe del trac o similar. Cert, però que voleu que us digui, només cerco una excusa per fer com el científic de les pel·lícules.

El que vull dir és que encara que vegem en les errades uns "bitxos" molestos que provoquen úlceres, també s'han de veure com a indicadors que apunten al camí que han de seguir els canvis al sistema per a que evolucioni de forma sana i sigui cada cop més útil i fàcil de mantenir.

Mode publicitat on:
M'han dit que queda una plaça lliure per el curs que donem durant la setmana vinent i tres dies de l'altre. El curs es de Servlets i JSPs, a la CAEB, de 16:00 a 19:00. És gratuït i puc afirmar amb bastant confiança que la relació qualitat / preu és acceptable ;-)

Python, Django , Google App Engine ... opinions d'un programador Java

2008-04-13T09:36:00.000+02:00

Calia estar en una cova per tal de no assabentar-se del que ha estat el gran aconteixament d'aquests darrers dies: el Google app engine. Vista la demostració que fan en vídeo de la facilitat amb que es crea una aplicació, es prova i es desplega, només puc qualificar-la d'espectacular. Cap línia de codi que sigui renou, cap instant perdut amb res improductiu, cap espera ... cap de les coses que si feim feina amb altres sistemes poden semblar inevitables.

A tot això cal dir que aquest llançament només ha estat una empenta a un moviment ja prou fort. Del Django només en sento parlar bé darrerament i el Python ja fa molts d'anys que té una comunitat molt fidel.

La situació que pot venir, sembla que sigui un creixement d'aquest model de programació a costa de reduir la presència de les altres alternatives existents, principalment el Java.

Com a programador en Java, això podria suposar una gran preocupació per la pèrdua de valor que poden patir els coneixaments adquirits durant tots els darrers anys de feina. Després de tants d'esforços, tornar al nivell de "novato" que tenia fa uns 8 o 9 anys, al començar amb el Java.

El dia que això sigui així, serà moment de vendre la casa, deixar la feina i els cursos, i cercar-me una altre forma de vida que no sigui la de programador.

I és que això és l'important, un és primer programador i després programador en el que sigui. Ja vam fer el bot de PL/SQL a Java i es clar que es poden fer els que sigui.

Però abans de matar el Java, anem a pensar el que pot passar (no ho endevinarem, mai ho feim, però això no fa inútil el que hi pensem). El Java és un gran llenguatge. A mi particularment m'entusiasma. Però no és perfecte ni com a llenguatge ni, molt menys, com a entorn de desenvolupament d'aplicacions que interaccionen amb altres tecnologies (principalment web i base de dades relacionals).

Fa uns anys, semblava que el Java s'acomodava en les seves limitacions ja que no li convenia fer grans canvis que molestessin a la seva enorme base d'usuaris. Però llavors sortí el .Net, gran amenaça que havia de fer desapereixer Java del mapa (no llegigeiu aquí cap referencia indirecta la Python). Això obligà a la comunitat Java a adaptar-se, treure-se la por del damunt i ampliar el llenguatge en formes que durant molts d'anys s'havien resistit a introduir-se per por. La competència és bona, i el Java d'avui és millor que el de fa 3 o 4 anys.

El Python, Django, Google app engine i companyia poden forçar al Java a atacar sense complexes i amb eficàcia les parts més febles que es duien reconeguent durant els darrers anys.

I, si no ho aconsegueix, aleshores adéu Java i ben vingut l'entorn que ho millora.

Abans d'enterrar a ningú, però, crec que s'ha de considerar el que és la gran tasca de la programació. Programar és gestionar la complexitat (perdoneu que no recordi l'autor de la cita). Gestionar la complexitat és actuar en la linia "Make everything as simple as possible, but not simpler." (aquesta sí la sé: Albert Einstein).

Un exemple : surt una tecnologia senzillíssima, HTML, i tot-hom que sap escriure en un teclat esdevé "programador". Anys després, l'HTML ja no és tan senzill. Un ús correcte de l'HTML, el CSS i, si escau, el JavaScript, requereix d'uns coneixèments teòrics no gens trivials. Aquesta complexitat afegida a la tecnologia no és gratuïta. És necessari "complicar" les eines per poder escalar en la complexitat del producte a construir.

Si vols fer una tenda de campanya, poses uns pals i una tela. Si vols ver un gratacels, comences fent un forat!

Java és un gran llenguatge per implementar models complexes. Alguns dels seus afegits (Spring, Hibernate ...) són, en distinta mesura, "complicacions" que no troben una explicació en aplicacions que es puguin fer en 10 minuts. JDBC i codi Java directe és molt més fàcil. La seva raó de ser està en els sistemes lluny de ser trivials.

El que vull dir, és que el camí a seguir no és la via fàcil de retirar tot el que és complexe, i fer del desenvolupament en Java una cosa que es pugui ensenyar en 3 dies. El que s'ha de fer, i si no ho fa s'el menjaran amb patates, és filar molt prim i sense pietat, i per cada tema, afrontar la difícil qüestió de fer-ho "as simple as possible, but not simpler."

I, per això, grans avanços com els Django i companyia han de servir com a models i fonts d'idees.

Data quality

2008-03-22T16:21:00.000+01:00

Hi ha un tema que aquests darrers dies m'ha estat voltant molt pel cap: com podem mantenir la qualitat de la informació de les nostres bases de dades.

L'origen d'aquesta qüestió ha estat que bona part de les tasques que he de realitzar l'aplicació que tenim en producció està relacionada amb mantenir les dades: entrades d'usuaris incorrectes, migracions que s'han de "depurar" manualment, etc.

L'aplicació que tenim ara en desenvolupament tendrà un volum d'informació dos ordres de magnitut superior, i per això s'ha d'intentar aprendre del que hi ha fet.

Se m'ocorren algunes coses que ja se poden anar incloguent.

Tenir processos que detectin informació incompleta que queda com a brutícia al sistema. Moltes funcions d'usuari requereixen de distintes passes i sovint s'abandonen abans d'acabar, deixant dades incompletes al sistema. Si s'aconsegueix implementar detectors d'aquestes dades, se pot eliminar moltíssima basura.

Permetre "fusionar" entrades a la base de dades que corresponen al mateix concepte. Dos usuaris entren registres que corresponen a la mateixa persona, empresa etc. Fusionar aquests registres no es trivial si molta informació depen d'ells.

Detectar problemes d'integritat que no estan contemplats per les regles de la base de dades. Sovint venen per deixar modificar relacions un cop creats els objectes, fora del fluxe normal, o per modificacions manuals a la base de dades.

Comprobar la completesa de la informació proporcionada per cada usuari. Les restriccions "not-null" de la base de dades son un requeriment molt bàsic que s'ha de completar amb altres avisos a nivell d'aplicació per l'usuari.

De fet, bona part de la tasca només té sentit si la podem delegar en l'ususari. Amb centenars o milers d'usuaris emprant i introduint informació, l'efectivitat de tot això només serà acceptable si la responsabilitat no cau en els 5 o 8 desenvolupadors sinó en tots els usuaris. Clar que s'els hi ha de facilitar aquesta tasca.

Per exemple, periòdicament s'els hi pot mostrar un llistat d'avisos en entrar a l'aplicació amb l'estil:

No s'ha introduit qui es el responsable de l'activitat A. Aneu aquí per fer-ho ara.
S'han definit 3 grups que no tenen cap persona associada. Per revisar-los o esborrar-los aneu aquí.
etc. etc.

Això coloca la responsabilitat de mantenir la qualitat de les dades al lloc que correspon: el que les introdueix i empra. Ara bé, hi ha una altra responsabilitat que és fer el més fàcil possible que els usuaris puguin cumplir la seva part i això ens correspon als desenvolupadors.

Tot plegat m'ha duit a mirar una mica per la wikipedia i per amazon. Sembla que el tema està englobat baix el que s'anomena "data quality" i hi ha alguns llibres interessants. Pot ser serà el proper que caurà...

Comentaris al llibre Interface-Oriented Design

2008-03-09T19:41:00.000+01:00

Vaig comprar el llibre degut a la qualitat dels llibres del "Pragmatic bookshelf". També el tema m'atreia ja que estic convençut que les interfícies son claus en el disseny de l'aplicació per aconseguir els objectius tan comentats ( escalabilitat, modularitat etc). De l'autor Ken Pugh no havia llegit res.

Interface-Oriented Design comença amb exemples d'interfícies que ens podem trobar en el mon real, amb les interaccions amb proveïdors de serveis com poden ser les tendes de pizzes. A partir d'aquests exemples ve a definir els aspectes fonamentals que compleixen aquestes entitats.

Defineix, inspirat amb les regles robòtiques de Isaac Asimov, tres lleis (The Three Laws of Interfaces) que han de complir les interfícies (avís de traducció poc acurada):

La implementació d'una interfície ha de fer el que els seus mètodes diuen.
La implementació d'una interfície no ha de fer mal.
Si una implementació no pot complir la seva responsabilitat, ho ha de notificar al client.

Per il·lustrar aquestes normes, empra les comandes Unix per la gestió de fitxers.

A continuació entra a descriure aspectes que ha s'han de balancejar a l'hora de definir una interfície ( stateless vs. stateful, orientació a dades o a serveis, etc), mostrant els pros i els contres de cada un.

Finalitza la part general amb un tractament dels principis "high cohesion, low coupling" aplicats a les interfícies i a consideracions especials per les interfícies remotes.

La segona part, d'un sol capítol està dedicada a la visió del procés de desenvolupament adoptada per les metodologies àgils, amb la inclusió del èmfasi en l'ús d'interficies per la fase d'anàlisi-disseny. Introdueix la definició d'unes targes (IRI cards - Interface-Responsability-Interaction) per mostrar a alt nivell les principals interfícies i les seves interaccions.

La tercera part està dedicada a un parell de casos pràctics que mostren l'aproximació recomanada en el llibre en la resolució de problemes concrets.

La meva opinió és que es tracta d'un llibre prescindible en l'àmbit del disseny de sistemes complexes. No veig cap aportació clara en la construcció del model de domini que no hi hagi, per exemple, al Domain Driven Design d'Eric Evans o al Pattern of Enterprise Applications Architecure de Martin Fowler. Tampoc a nivell de metodologia, que tracta a nivell superficial, és comparable a llibres de metodologies àgils, extreme programming o Test Driven Development. La part final, per mi la més profitosa, mostra alguns dissenys interessants per problemes d'aparença bastant real.

Tampoc vull dir que sigui un mal llibre. Està ben escrit, el tema és interessant i es veu que hi ha al darrera un autor amb amplis coneixements. El problema és que es un llibre curt que tracta un tema molt ampli i molt explorat per la literatura actual. Altres llibres de format semblant de la col·lecció The Pragmatic Programmers encerten més en la definició del àmbit a tractar i aconseguixen aportar una visió dinàmica i fresca.

Eines de control de qualitat

2008-03-02T18:10:00.000+01:00

Quan anam programant és important anar revisant la feina per tal d'eliminar els defectes de disseny o implementació que introduïm. Refactoritzacions freqüents ajuden a mantenir el codi amb la qualitat suficient per a fer-ho manejable.

Com en altres aspectes de la nostra feina, disposar de les eines que ens ajudin a assolir aquestes qualitats per les nostres aplicacions és clau.

Trobar eines que ens ajudin a escriure codi, compilar-lo o executar-lo és trivial. Tampoc és complicat emprar eines que construeixin l'aplicació, gestionin les incidències o tenguin cura de la gestió del codi font. Ara bé, que ens ajudin a mantenir la qualitat del codi i del disseny sembla un tema apart. Com ens pot ajudar una eina?. Segur que tots hem viscut discussions menys o més fortes per com modelar en entitat-relació una determinada informació, o com distribuir distintes classes en els mòduls que tenim. No sembla haver-hi gaires aspectes qualitatius que permetin emprar una eina per ajudar-nos.

Evidentment n'hi ha i bastants. Basta observar com habitualment els editors (jo empro l'IntelliJ, però segur que el vostre també ho fa) ens avisen de defectes del codi: variables no emprades, codi mort, estructures innecessàriament complexes i moltes altres. Aquests són els problemes més fàcils però no els únics.

La darrera setmana vaig estar provant el JDepend. Té moltes funcionalitats però estava interessat especialment en evitar cicles de dependències entre els paquets. Curiosament, els que va detectar varen ser deguts a decisions que ja ens havien agradat molt poc i no hi havia hagut gaire consens. A l'arsenal ja disposem de fa temps del PMD que ens avisa de recursos no alliberats correctament, d'usos poc correctes del classloaders i moltes coses més. El findbugs ens posa en evidència quan no implementem correctament la tupla equals-hashcode i altres "novatades" per l'estil.

Com sempre, l'advantatge d'aquestes eines està subjecte al fet que s'emprin habitualment. Aquí és on una bona integració amb l'ant i l'ús d'una eina d'integració continua han de fer la seva feina.

Cada cop estic més convençut que programar és més un art que cap altra cosa, però això no ens ha d'impedir conèixer les eines que ens poden ajudar a aconseguir la qualitat del nostre codi.

Comencen els cursos

2008-03-01T12:10:00.000+01:00

Comença la temporada de cursos.

Dilluns s'inicia el de Java bàsic, organitzat per la Caeb i GS Bit, de 30 hores. Enguany hem canviat la configuració, fent les sessions diàries de 3 hores (en lloc de les 4 de l'any passat) i ampliant la durada del curs de 20 a 30 hores.

Crec que això afavorirà l'aprofitament del curs al temps que ho farà menys dur. S'ha de tenir en compte que tots venim de treballar al matí i el cansament és un factor a tenir en compte.

L'època de cursos suposa un gran esforç. A la feina del matí (que no és poca!), s'ha d'afegir la tasca de preparar els cursos i la tensió pròpia d'explicar a unes 15 persones material bastant avançat. Sí, inclús el "Java bàsic" requereix d'aspectes avançats si vols que els alumnes aprofitin bé el curs. Ara bé, amb aquest esforç també ve una gran motivació. Soc un entusiasta de les tecnologies que formen part dels cursos del catàleg (ejem ... excepte els EJBs...) i m'agrada ajudar als companys de professió a introduir-se en aquestes.

La satisfacció que et dona veure l'"ajà!" d'algú que interioritza algun concepte complexe que a tu et va dur setmanes entendre o notar l'entusiasme mostrat cap a alguna eina de les que presentem no la donen altres tasques de la nostra professió.

Au idò! a menjar bé, dormir prest, reduir les dosis de cafè i endevant amb els cursos!

Lògica

2007-12-02T02:38:00.000+01:00

Quan anem construint una aplicació, emprem distintes tècniques per resoldre diferents aspectes del problema. Dissenyem pantalles que organitzin les dades que l'usuari ha de introduir o consultar, creem les taules amb les dades que s'han de guardar més enllà de l'execució d'una operació concreta, etc.

Però que fem quan hem d'implementar una determinada operació complexa?
Un exemple: suposem que tenim una matrícula en un centre docent. Aquesta matrícula pot tenir distints periodes de baixa, amb una data d'inici, una de fi, i un motiu. El fet que la matrícula estigui activa pot dependre de moltes coses, una d'elles, que no hi hagi cap motiu de baixa actiu.

Sovint veig plantejar aquest problema amb terme de modificacions en la base de dades. Un mètode de la capa de servei modifica les dades dels periodes de baixa, i segons el resultat final, l'estat de la matrícula queda actiu o no.

La classe Matricula no incorpora cap lògica, només serveix per tenir en memòria una imatge de la taula de la base de dades amb la que treballar.

Si volem fer ús de l'orientació a objectes, hem de retornar a la matricula la responsabilitat que li correspon, en aquest cas determinar quan està o no activa. Si les modificacions als periodes de baixa permetem fer-los només mitjançant la classe Matricula i fem que aquestes incorporin les regles de negoci que determinen la vigència d'una matrícula estarem obtinguent molts de beneficis:

La lògica queda deslligada d'altres aspectes com la persistència, que segurament estava implícita si feiem la implementació als mètodes de servei
Se reduiex la complexitat al encapçular via la matrícula tots els accesos als periodes de baixa
Tenim un punt a on estendre la lògica associada a la validesa de la matrícula, en cas que sigui necessari
Estem molt més ben equipats per reduir la duplicitat de codi
El codi queda més fàcil de provar