Hibernate Tools 3.1 Beta és un afegit per Eclipse 3.1 que ens permet entre altres coses mapejar les taules de la nostra base de dades a fitxer xml utilitzats pel bastimet Hibernate, generar els POJOs

que mapegen aquests xml cap a classes Java i a més amb una utilitat que ens permet fer consultes HQL directament.

Així dit no sé si algú que no estigui una mica enterat del tema m'haurà entés res. Miraré d'explicar-ho: Un dels maldecaps més importants quan es fa servir programació orientada objectes en programes de gestió és que més tard o més d'hora hom ha d'acabar passant aquests objectes (normalment les seves propietats) cap a una base de dades i aquí comences els problemes, ja que s'han de fer un seguit de transformacions per passar dels objectes a les tuples de la base de dades. Podem trobar-nos que el gramatge dels objectes i les tuples de la base de dades sigui diferent, ens trobam que els conceptes de navegabilitat que tenim als objectes no es corresponen amb la BD, etc. El pas invers també és complexe, ja que es tracta de recuperar tuples d'una base de dades i transformar-les amb objectes.

Hibernate eś un bastiment que intenta que aquests maldecaps siguin els menors possibles. Ens permet definir una sèrie d'arxius xml que diuen com es mapegen els objectes (els POJOs) a la base de dades. Per exemple, ens permet definir com es passa d'una jerarquia d'herència a la base de dades, permetent establir diferents estratègies per aquest traspàs.

A més Hibernate ens independitza l'aplicació de la base de dades que estiguem utilitzant. Per això el que fa és definir els seu propi llenguatge de consultes, l'HQL, on es fan consultes en notació d'objectes i es retornen objectes.

Actualment la tendència és fugir com de la pesta (o la grip aviar) dels EJB i els seus mecanismes de persitència, ja que impliquen escriure molt de codi, resulten aplicacions molt pesades i difícils de mantenir. A les estimacions que tenc, una aplicació EJB respecta una feta amb una tecnologia "lleugera" hi pot haver fins a un factor 10 en termes de cost de desenvolupament.

Bastiments com a Hibernate han permés que les tecnologies no basades en EJBs s'estiguin imposant i eines com les Hibernate Tools fan que el desenvolupament sigui encara més ràpid, ja que permeten generar el codi java i els xmls de mapeig automàticament. Aquesta nova versió a més incorpora tot un seguit de millores que ajuden a la programació: conversió de HQL a codi SQL i la possibilitat d'afegir paràmetres a les consultes són les més interessants.

Encara queda molt de marge per la millora de les Hibernate Tools, els mapeig és cada cop millor i l'editor per configurar la part d'enginyeria inversa de les bases de dades ha donat un salt important en aquesta darrera beta. Tot i això és molt millorable la manera de presentar els resultats o els codis d'error que ens van donant quan es posa la resposta. En el que fa referència a l'editor HQL trob a faltar la possiblitat d'arrossegar un cap des de l'arbre de mapeig cap a l'editor o que a l'hora de fer la consulta et demani el màxim de resultats que vols mostrar.

Tal com està avançant Hibernate i les Hibernate Tools esper que vegem una eina molt més completa per quan la beta esdevingui ja la versió definitiva.

La referència de l'article de JavaHispano es aquí i comenta una conferència de Marc Andreessen, el fundador de Netscape. Segons aquest bon home PHP serà més popular que Java en el futur. En el futur? No ho sé, però a mi em sembla que actualment el PHP és tan o més popular de Java per a fer webs. Que PHP pugui batre a Java en el món de la web ja no és cosa tant de llenguatge com de l'ús que se'n faci, es a dir, de la capacitació professional dels seus desenvolupadors.

Una aplicació tant web o a qualsevol altra no és bona o és dolenta per estar feta en un o altre llenguatge. Podem trobar aplicacions molt bones i autèntics xurros fets en gairebé qualsevol llenguatge de programació existent. És a dir, que la bondat d'un desenvolupament la marca el desenvolupador i no el llenguatge en sí.

Hi ha llenguatges que per las seva construcció forcen a desenvolpar d'una determinada manera, que fa que sigui més facil de llegir, menys propensa als errors de programació, que s'hagin d'escriure menys línees de codi, que ens permeti un control absolu de la nostra aplicació ... Segur que tots reconeixerem els nostre llenguatge preferit en aquestes frases. Uns hi veuran el Python, altres PHP, altres Java, altres ADA, C, C++ i la llista segueix. Un equip de programació amb una bona metodologia, un bon conexiement del llenguatge de programació que fa servir ben capacitat, pot anar més enllà de les limitacions del llenguatge de programació. Pot establir pràctiques que facin que el mantenimient sigui més senzill, que la divisió del codi entre els programadors sigui més fàcil, en definitiva, aprofitar els punts forts del llenguatge de programació en el seu benefici i obviar els punts febles.

Quan parlam de programació per la web, però, a més del propi llenguatge de programació en sí, interevenen també factors externs que influexien en la popularització d'un llenguatge de programació o un altre. Està clar que un d'aquests factors és la facilitat amb que es pot aprendre el llenguatge, i està clar que el PHP permet fer els primers programes en molt poc temps. Potser massa poc temps ;) i això fa que fins i tot gent sense cap formació en programació s'atrevesquin a programar en PHP. Això contribueix a la popularització del llenguatge, segur, però també és segur que no contribueix a la qualitat del programari que es fa.

L'altre factor que intervé en la popularització d'un llenguatge per la Web és la seva disponibilitat en els ISP. No és gens habitual que la gent tengui els coneixements o tengui els doblers per permetre's tenir el seu propi servidor dedicat en el que hi pugui instal·lar el que vulgui i tenir una ampla de banda suficient com per posar-ho a Internet. Per això s'ha de dependre d'ISP externs que donen una configuració preestablerta. Així, sovint hom no tria el llenguatge de programació que farà servir per una aplicació Web, sinó que es veu limitat pel que pot pagar o pel que té l'ISP de torn. Aquests ISP al que van és a tenir el màxim nombre de dominis hostejats en una mateixa màquina i per tant fugen com del dimoni de configuracions que no permetin maximitzar el benefici.

Així doncs, en la popularitat del PHP hi juguen dos factors: la facilitat d'entrada en el llenguatge per part de gent no programadora, i la maximització de rendiment que poden treure els ISP donat que aquest llenguatge consumeix molts menys recursos de màquina que altres i per tant els permet tenir més gent hostatjada. És força difícil avui per avui trobar un ISP que ens permeti tenir accés a un entorn J2EE a un preu semblant al que tendriem per PHP, o fins i tot trobar-nos amb algun que ens doni accés a Zope/Plone del món Python i ja no parlem d'altres eines com Ruby i el bastiment Rubi on Rails, que encara que s'ha posat molt de moda per la seva potència pocs ISP l'incorporen i si ho fan amb uns peus que són de lluny més cars que una configuració semblant basada en PHP.

És en el moment en que la llibertat d'elecció del llenguatge de programació adient per un projecte es veu limitada per l'ISP on la comparació d'un llenguatge de programació amb un altra pert tot el sentit, si és que l'ha tingut mai. Sovint s'haurà de programar amb el llenguatge que té l'ISP instal·lat per defecte, o disposar-nos a pagar preus difícilment assumibles per aplicacions modestes.

Si ens situam a l'ambit empresarial la cosa és semblant però per una altre costat. Així es té tendència a triar Java o .Net perquè el consultor de torn ha dit que és el més potent que hi ha, perquè és l'standard i perquè així justificarà la seva minuta ;) però segurament estan davant un antipatró conegut com el del martell d'or, resumit en aquella frase de que quan sols es té un martell tot s'acaba paresquent a un clau. Sovint ens podriem trobar que la solució més adient per una aplicació empresarial per la web sigui quelcom fet en PHP, o en Python i no necessàriament en Java o en .Net, però per poder arribar a dita conclusió s'ha de tenir el bagatge de coneixements necessari per poder adonar-se de quina és la tecnologia que millor d'adapta al projecte en concret i en departaments de programació que tendeixen a homgeneitzar fins extrems absurds tant els llenguatges (o millor dit llenguatge) de programació com les tecnologies utilitzades, això difícilment se dóna.

No hi ha solucions màgines, no hi ha bala de plata, no hi ha llenguatges de programació millors o pitjors. Hi ha llenguatges de programació que s'adapten millor a alguns tipus de problemes i programadors que s'adapten millor segons quins llenguatges de programació. Com sempre el truc està en no limitar-se, en tenir la ment oberta i un conjunt d'eines al nostre abast que ens permetin fer l'elecció més adient pel problema que volguem resoldre.

El cap de setmana es presentava mogudet: els divendres vàrem dur els nins (els dos) al metge, ja que s'havien carregat de febre. No s'hi posen per poc, en un tres i no res es posen a 39 i busques i el gran ja ens ha donat algún ensurt, així que davant els primers simptomes febrils optam per dur-los al metge per saber si la malaltia es vírica o bacteriana i posar-hi remei l'abans possible. Així doncs, ha tocat un cap de setmana d'estar a casa, que tampoc s'hi està malament... És sorprenent el que són els nins, en un tres i no res passen de voler jugar i no estar-se quiets a tenir febre. Tan punt volien anar amb bicileta com se carregaven de febre i no volien ni menjar. És un passar pena continuo, supòs que tothom hi ha de passar per això, però què voleu, sóc passador de pena, no hi puc fer res. Tot i així també sóc optimista de mena, un optimisme cínic, també ho he de reconèixer, però això fa que a més de veure els problemes al mateix temps intenti cercar solucions. Això va molt bé en el món informàtic :) Entre febrada i febrada he llegit un poc. Fa temps vaig comprar Buenos días, pereza de Corinne Maier i aquest cap de setmana l'he acabat de llegir. El llibre està força bé, es interessant i bo de llegir, però no m'han agradat ni el títol ni el subtítol "Estrategias para sobrevivir en el trabajo". Crec que dóna una impresió equivocada del que és el contingut de llibre, posant-ho al nivell de "El principio de Dilbert" d'Scott Adams, quan realment el to general del llibre està lluny de l'humor, si bé traspua ironia i un poc de mala llet. Si feis feina en una empresa gran o sou funcionaris de l'estat potser us trobareu identificats (potser fins i tot retratats) per algunes situacions que s'expliquen al llibre, però més que res l'autora fa un repàs als grans mites de l'empresa moderna i posa moltes coses al seu lloc. En definitiva, recomanable per pensar un poc. També ha donat temps per fer alguna cosa que altra en informàtica. Com sabeu darrerament estic molt centrat en Java per motius de feina. Ara ens hem trobat amb la necessitat de connectar un sistema amb el nostre fent peticions XML encapsulades en HTTP. Molt divertit tot plegat. La part mésemprenyívola és el que no tenim cap control damunt el tipus de consultes que es poden fer. Hi ha unes especificacions i prou, fins aquí tot correcte, el problema és que el gramatge de les consultes és molt gruixut, per la qual cosa el temps de resposta no és gaire bo. Això es pot resoldre amb un sistema de caché que amagatzemi els resultats de les consultes i a partir d'aquí posar una façada que amb el gramatge fi que necessitam per a la nostra aplicació. És aquí on entra EhCache, un sistema de caché senzill i potent que permet enmagatzemar objectes java (serialitzables, es clar). Es poden crear diversos contenidors de caché i assignar-los un temps de vida a cada un, un nombre màxim d'objectes que es poden enmagatzemar, si l'enmagatzematge ha de ser en memòria o disc, etc. No està pensada per clusters però pel que necessitam ara ja anirà bé. És el sistema de caché que es fa servir normalment amb Hibernate, i això representa que sovint ja tindrem la llibreria a l'aplicació, però que també podem tenir problemes de versions si el que volem és utilitzar una versió més recent del sistema de caché. L'altra repte era veure com funcinava això fora d'Hibernate i a més dins d'un contenidor J2EE com Tomcat. La idea del Thread Local que fa servir Hibernate per mantenir les sessions no serveix per un sistema de caché o interessa que tothom accedeixi al mateix repositori. Una possible solució l'he trobada fent servir Spring i pareix que va prou bé. Tant en el tema d'Spring com en el EhCaché estic encara en el nivell 1oI i em queda molt per aprendre, sobretot d'Spring. Estic començant a veure la potència que tenen els IoC en general i Spring en particular, però encara passarà temps per a poder dominar el tema tant com a mi m'agradaria. La documentació d'Spring és molt completa en el referent a com integrar diferents tecnologies dins el bastiment, però no ho és gens a l'hora de proporcionar exemples clarificadors i mini aplicacions per resoldre els problemes més comuns. Potser encara no he mirat als llocs adequats. Sigui com sigui ara tenc una aplicació d'exemple basada en Equinox que em serveix de prova de concepte de com es pot injetcar la caché a un objecte i per tant fer-ho servir pels propòsits que volia. A més he comprovat que la caché es única i es compartida per tots els clients, quelcom que no em quedava massa clar dels exemples que hi havia o amb segons quins montatges que havia fet per provar-ho. Potser hi ha altres maneres de fer-ho però per mi aquesta ha resultat la més senzilla, i com diu la màxima de l'extreme programming, fes la cosa més simple que pugui funcionar, i per mi ha estat aquesta.

En els moments d'escriure això m'estic devallant la beta de JDK 5 per pSeries, tant la versió de 32 bits com la versió de 64 bits, a veure si hi ha sort i funciona amb el PowerPC del G5. La versió 1.4.2 de 32 bits sí que funciona i és la que estic utilitzant en aquests moments, però la veritat és que em preocupa un poc no poder fer ús de tota la potència dels 64 bits, i encara més, tenir-me que quedar ancorat a la versió 1.4.2 de Java.

Està clar que encara hi ha moltes empreses que fan feina amb la 1.3 i que la 1.4.x és l'estandard "de facto" en quant a màquines virtuals, però a poc a poc els desenvolupadors i les eines de desenvolupament van forçant a poc a poc el canvi cap a la 5.0.

Vagi com vaig segur que tindrem 1.4 pels llocs durant molt de temps. De fet en la majoria de desenvolupaments web no és molt important el tema de la màquina virtual, i tant fa si es la 1.4 o la 5, ja que la tecnologia funciona en qualsevol de les dues versions, potser amb diferències de rendiment, però poca cosa més.

A més de l'anunci de la notícia a The ServerSide és interessant llegir-se els comentaris que hi ha damunt l'anunci mateix i l'ús de la tecnologia Java en Mainframes.

I en el temps d'acabar-ho de dir he acabat de devallar-ho i descomprimir-ho :)

La versió per 32 bits funciona bé, però no així la versió de 64 bits, em dona un error Error en carregar: libstdc++.so.5: cannot open shared object file: No such file or directory i no sé massa bé el motiu. És el mateix tipus d'error que tenia a la versió anterior del JDK. Si algú aconsegueix fer funcionar la JDK5 de 64 bits en un G5 estaria molt agraït de que m'ho faci saber.

Ara estic provant el Netbeans amb la nova màquina virtual. He provat d'arrancar el Tomcat 5 i ha passat dels 13 segons (amb aplicacions i tot) als 9.8 segons de la nova màquina virtual, pareix poca cosa però al manco es nota l'augment de velocitat, i encara no he tocat cap paràmetre per optimitzar el rendiment de la màquina virtual. Se suposa que aquesta versió ha de permetre fer més optimitzacions que l'anterior, serà cosa de llegir...

Avui al matí he començat la instal·lació de la Ubuntu Breeze. Després de provar la Live estava ja negitós i amb ganes de enviar a pastar la FC4. S'ha fet d'esperar, però, ja que malhauradament ahir no es va devallar bé la iso de la Ubuntu i he tingut que tornar-la a devallar. Un parell d'hores més d'espera... Després de cremar la nova iso, comprovant els checksums amb el K3b he fet còpia de seguretat del que ja hi tenia. Un DVD complet de llibreries, fotografies i demés històries! Hi ha que veure el que s'arriba a acumular quan un té espai al disc. Amb la còpia a la capsa ja sols ha quedat instal·lar l'Ubuntu. Cap problema! Tot ha anat com una seda i després d'una horeta ja tenia un sistema completament funcional, sols l'hi he tingut que donar un nom d'usuari i la password i m'ho ha deixat gairebé a punt de revista. Després amb el Synaptic he anant instal·lant uns quants paquets que m'interessaven: kile, quanta, nvu, latex i coses per l'estil. He vist que hi han posat l'Eclipse a la distribució, però a mi no em funciona :(. He de dir que tampoc em va gaire bé l'Eclipse baixat d'Internet, així que potser és que tenc quelcom mal configurat a la part de Java. Tantmateix tampoc em preocupa gaire, el Netbeans 5.0 beta s'està comportant molt bé. He configurat un projecte amb Ant a partir de una aplicatiu anomenat Equinox, que no és sinó una manera de crear una aplicació d'arrancada amb les característiques que t'interessin. L'Ant i Netbeans es duen molt bé, pots configurar les accions més habituals de l'IDE com a tasques Ant i a més pots crear entrades al menú contextual de l'aplicació. Res idò, que ara ja ten el meu PPC G5 amb l'Ubuntu i ja començ a oblidar els maldecaps que tenia amb FC4. Val a dir que he guanyat molt amb el canvi, ja estava bastant fart del yum, de les xorradetes de la Fedora i de lo molt que li costava moure la màquina. Amb l'Ubuntu la posada en marxa és molt ràpida i encara que vaig amb Gnome i amb FC4 amb Xfce4 el rendiment de Ubuntu supera amb escreix al de la Fedora. Ara sols em queda anar polint quatre detalls més de configuració i ja ho tindré com a mi m'agrada. Per ara me pareix que em quedaré amb el Gnome. A la feina faig servir el KDE i així podré comprovar i veure com es comporten ambdós entorns.

Donc això, avui m'he devallat la Ubuntu Breezy per PowerMac, segons deia la documentació funciona per G5. Això ja és una gran millora per mi, ja que, com he comentat a altres apunts he tingut seriosos problemes amb la meva màquina i les distribucions Linux. Tan seriosos que sols al Fedora Core 4 em funcionava correctament. Problemes deguts a que les distribucions més antigues encara no havien incorporats les novetats que tenen els moderns G5 i que feia que es quedassin torrats a la instal·lació. M'he devallat tant la versió Live, per provar si la cosa funcionava i la versió per a instal·lar. A hores d'ara estic escriguent això amb la versió Live, per tant ja podeu comprovar que la cosa m'ha anat prou bé. Tot pareix que funciona "com toca" a la Live, així que és de suposar que també ho farà a la versió per instal·lar. El diumenge es presenta interessant: primer serà cosa de fer còpia de seguretat de tot el que tinc. Els documents són poca cosa, però me fa peresa tenir que tornar a devallar tot el que he devallat de llibreries de Java, el Netbeans 5 i demés. Per cert, que el Netbeans 5 (en beta per ara) està moooolt bé. No hi ha pluggin per Hibernate però temps al temps. Trob que han millorat molt, tant en el temps de càrrega com en tota la resta. Fins i tot la configuració ha canviat i ja és bastant més amigable que no la cosa infumable que hi havia a altres versions. Res idò, que ho sapigueu, la nova Ubuntu funciona de conya amb els G5 i a més va molt ràpida, tant que la versió Live es pot comparar amb la versió instal·lada de la Fedora Core 4. A verue si hi ha sort i la instal·lació a disc no em dona problemes...

Ricardo al seu bloc al seu bloc torna a fer palesa la poca aportació que fan al PIB nacional les empreses espanyoles que es dediquen a la programació. Particularment crec que el motiu que fa que no es desenvolupin més programes a casa nostra té més a veure amb el model cultural de moltes de les empreses i en particular amb el model cultural dels seus responsables informàtics a tots els nivells, model que es mou per una llei bàsica: "salvar el culo". El programari lliure a les empreses té un avantatge fonamental: es disposa del codi font i per tant en cas d'errors hom té l'oportunitat d'arreglar-los, de millorar el programa. Això pero sovint implica que el tècnic de torn ha d'estar suficientment preparat i capacitat. Moltes vegades s'ha de saber cercar la vida, anar dins el codi font a veure què fa el programa, mirar d'extreure-li tot el suc. Això en un món ideal... En el nostre món el tènic de torn no cerca la millor solució per a la seva empresa a un problema concret, cerca la manera de salvar el cul. Imaginem que la millor sol·lució en quant a qualitat i preu resulta que és una solució de programari lliure. Per arribar a aquesta conclusió el nostre tècnic hauria d'haver seguit aquests passos:

• Obtenir una llista de requisits que ha de tenir l'aplicació, els requeriments.
• Cercar programes que puguin complir els requeriments
• Avaluar els programes contra la llista de requeriments
• Avaluar la relació cost/benefici de cada programa
• Presentar una recomanació.

Desgraciadament això passa poques vegades. El responsable de triar el producte està massa preocupat per les conseqüències que pot tenir una tria errònea, i per tant tendirà a no avaluar els productes basant-se en la seva capacitat tècnica, sinó en poder justificar de la millor manera possible una possible fallada de la sol·lució informàtica proposada. Excuses com "No sé què pot haver passat, és el que fa servir tothom", "la nostra tria és correcta perquè és el que té la competència", "el producte xxx és del la casa yyyy que fa www i per tant ha de ser bo". En definitiva es tracta de tenir en cartera tota una sèrie de justificacions per explicar el perquè un producte en el que l'empresa ha fonamentat una part del seu negoci no acaba de funcionar. Algunes vegades m'he trobat que quan es proposa una solució basada en programari lliure surt el capdefava de torn que diu que s'ha de mirar de trobar un programari que resolgui el problema o cubresqui la necessitat encara que no sigui de codi lliure. No ho acab d'entendre això jo, si la solució compleix els requeriments, es pot provar i avaluar sense problemes i a més és de codi lliure per mi no hi hauria més que parlar, llevat de que es proposas una altra alternativa de les mateixes característiques. El problema fonamental que hi ha és que per ara la gent que ha de mollar la pasta no demana si hi havia altres solucions que no suposassin lligar l'empresa a un producte tancat. Pareix que si la cosa va en una caixeta ja tingués que tenir una qualitat indiscutible, quan normalment això no és així. Amb això tampoc vull dir que tot el programari lliure sigui bo, ni prop fer-hi. Hi ha engendres i coses mal fetes, com per tot. La cosa està en que és més fàcil adonar-se de que un producte és dolent, ja que el pots provar abans, tens el codi, tens a l'abast la documentació i les llistes de correu. En el programari tancat si hi ha sort hi haurà una demo limitada en el temps i en característiques, que precisament té allò que tu volies deshabilitat. Algunes aplicacions de programari lliure ha arribat a un nivell de qualitat tal que és millor tant per la qualitat tècnica de les aplicacions com per la qualitat ètica de les mateixes. No ho hem d'oblidar mai la part ètica del programari lliure, i tot i que quan parles d'ètica en alguns llocs la gent arrufi el nas, el que és inquestionable és que de la mateixa manera que es qüestiona a grans empreses per fer servir ma d'obra infantil o amb salaris de misèria, arribarà un moment que els ciutadans es començaran a plantejar primer perquè les seves institucions amollen els doblers a empreses que no aportan res a la ciutadania quan sí ho fan els projectes lliuress. El pas següent ho tindrem a les empreses, on els responsables aviat es demanaran perquè tenen productes tancats, perquè la seva empresa depén tant d'uns bits que no controlen, de perquè han d'inventir en fum quan poden invertir en gent, que al cap i a la fi és el que dona valor afegit a les empreses (els consultors de RR.HH. estan cansats de dir-ho, no?). En definitiva, que l'excusa de triar un programa tancat sols perquè així tenim a quí donar la culpa no s'aguanta. Ara per ara sols ho fa pel desconeixement del tema que tenen els qui ara mateix han d'aprovar els presupots, però estau segurs que les coses estan canviant. El programari lliure cada cop arriba a més gent, s'està convertint en quelcom de domini públic, si em permeteu el joc de paraules, i per tant les excuses del mal pagador cada cop s'aguantaran menys. Serà difícil explicar perquè s'instal·la un proxy que no sigui l'squid, perquè s'ha optat per una base de dades privativa en lloc de Postgres o MySQL, perquè es fa servir el Microsoft Office quan hi ha l'OpenOffice, ... Potser el problema no és sols dels informàtics i també en tenen part de culpa els usuaris, que demanen coses impossible de cumplir: el bueno, bonito, barato de tota la vida però a més amb modificacions d'ultima hora i cercant caps de turc quan les coses no funcionen, i alguns, escaldats, prefereixen cobrir-se les espatlles o altres part, i deixar de donar la solució que representaria la millor elecció per l'empresa, i donar aquella que els salva el cul de moment. El que s'hauria de tenir clar és que tot engany s'acaba per descubir, i que la solució que t'ha salvat el cul avui te pot explotar a la cara demà.