Protocol Buffer

Escrit per Aaloy a 08 de July , 2008 a les 10 p.m.

Protocol Buffer és una llibreria d'intercanvi de dades que Google ha alliberat i que segons promet és de 20 a 100 vegades més ràpida que l'XML (i ja no parlem de SOAP) per a l'intercanvi de dades entre aplicacions.

Lo de la velocitat s'haurà de comprovar, però el que sí pareix clar és que és prou senzilla per ser abastable, la documentació és bona, i ja va dirigida als tres principals llenguatges de programació (C++, Java i Python).

Com que en faig servir dos habitualment, doncs es cosa de fer-hi una ullada i algunes proves d'stress a veure si realment és tant ràpida com diuen.

La cosa no sé si s'imposarà com a format d'intercanvi entre llocs d'Internet, però el que sí tenc clar és que si és més ràpid pot ser ideal com a format per a tecnologies SOA dins de la mateixa empresa. Una reducció d'un factor 10 ja seria prou bona, amb l'avantatge de que es podrien crear (com ara, per cert) serveis en un llenguatge i consumir-los en un altre, però sense tenir que pagar el preu que suposa en termes de rendiment fer-ho en format WSDL.

Es prest, per donar-ne una opinió amb més fonament, però pel que he vist de la documentació i els exemples, crec que aquest format i jo ens durem bé :)

2 comentaris, 0 trackbacks (URL) , Tags: Informàtica Python Java

Alfresco Community Conference

Escrit per Aaloy a 25 de April , 2008 a les 9:37 p.m.

El dia 22 d'aquest mes vàrem assistir a l'Event d'Alfresco Community Conference a Barcelona. Per a qui no ho conegui Alfresco és un DMS (Document Management System) lliure que ha agafat molta volada darrerament, encara que és un producte molt jove.

Per anar-hi agafàrem un vol molt prest, no eren encara les set del matí, i això vol dir aixecar-se a les cinc del matí. En favor de la gent d'Alfresco he de dir que les conferències varen ser prou interessants com per a mantenir-me despert, encara que no puc prometre que se m'escapàs el cap alguna que altra vegada.

A nivell organitzatiu les conferències varen estar molt bé: la sala molt ben preparada, amb traducció simultània fins i tot i la intendència (la teca) prou bona. Sols em va quedar el dubte de perquè un recinte amb capacitat amb tanta gent té uns excusats com els que té. Mai havia anat a un lloc on els tios fessin coa per anar al bany.

Punts anecdòtics a part, he de dir que vaig sortir força content de les conferències. Vàrem veure cap a on apunten les novetats d'Alfresco i de pas també es pogué veure cap a on desenvolupa la gent. Els d'Alfresco estan deixant els JSF, segons ells fan que les aplicacions siguin molt males de mantenir, i vàrem poder veure dues aplicacions, una feta per un desenvolupador independent i una altra oficial d'Alfresco, que tenien una cosa en comú: estar desenvolupades amb Extjs. Els d'Alfresco han fent una aposta molt forta per la comunicació de l'aplicació amb json, xml, rest, webdav, etc i segons vàrem poder veure han fet que sigui força fàcil poder publicar la informació en aquests formats.

Potser sigui autoconvenciment, però la cosa és que el tema del JSF no m'ha acabat de convèncer mai. Massa enrevessat i mal de mantenir, però és el que empreses com Oracle estan recomanant per fer el canvi tecnològic de Forms cap a la web, l'excusa és que hi ha dissenyadors visuals per JSF, però em fa por que amb l'excusa de la productivitat a l'hora de pintar pantalles s'estigui optant per una tecnologia que aviat quedarà obsoleta. La gent té tendència a anar cap a coses que agumenten la productivitat, deixen fer coses i els faciliten la vida, d'aquí que bastiments com Spring i Hibernate triomfin on els EJB varen fracassar.

La gent d'Alfresco pareix que ho veu clar i que s'estima més retirar-se ara i apostar cap a una altra tecnologia més mantenible per la capa de presentació. Potser va ser una de les millors conclusions que en vaig poder treure de la conferència.

0 comentaris, 0 trackbacks (URL) , Tags: Informàtica Java

Integració de Hudson i Trac

Escrit per Aaloy a 15 de March , 2008 a les 11:52 a.m.

A un altre post ja vaig parlar de Hudson, un sistema d'integració contínua, relativament nou però que permet fer el que un necessita d'aquestes característiques de manera fàcil i amb una interfície molt cuidada.

Hudson es pot integrar amb Trac, de manera que al Timeline del projecte trac poguem veure com han anat les integracions sense tenir que anar al Hudson. D'aquesta manera la gent que fa el seguiment del projecte pot veure a més dels commits al subversions, modificacions al wiki i tickets, com han anat les integracions i quan s'han fet.

La integració dels dos aplicatius és força senzilla:

• Instal·lam el python-feedparser si no ho tenim ja al nostre servidor.
• Anam a http://trac-hacks.org/wiki/HudsonTracPlugin i descarregam el plugin.
• Descomprimim el plugin i amb permisos d'administrador executam python setup.py install això ens crearà el paquet egg i configurarà el plugin a nivell global dins el trac.
• Editam l'arxiu trac.ini del nostre projecte trac que volguem enllaçar amb Hudson i modificam la llista de components, en el meu cas la cosa queda com

[components]
iniadmin.iniadmin.iniadminplugin = enabled
webadmin.* = enabled
HudsonTrac.* = enabled

• Cream també una entra a anomenada hudson allà on posarem tant la url del rss del nombre projecte hudson que volguem controlar com el de la vista del projecte, de tal manera que s'hi crei un enllaç dins Trac

[hudson] display_subprojects = false feed_url = http://servidorhudson/hudson/view/Java/rssAll main_page = http://servidorhudson/hudson/view/Java/

• Canvia el servidorhudson pel vostre servidor. Aquí el que he fet és enllaçar directament contra la vista de projectes anomenada Java que he creat. Podria enllaçar a un projecte concret o a una vista relacionada amb el projecte que es gestiona amb el Trac.

Si s'han seguit aquestes passes i una vegada refrescada la plana del Trac, ens apareixerà una nova secció anomenada Hudson a la part de navegació del Trac que enllaça a la url que hem posat a main_page i al timeline apareixerà una opció que ens permetrà visualitzar les integracions, en forma de control check.

Pels que feu servir Trac de manera habitual, és interessant instal·lar-se també el plugin IniAdminPlugin, que ens crea un menú de configuració per web del trac.ini del nostre projecte.

És interessant a tot això adonar-se de que gràcies als formats oberts, en aquest cas al RSS que publica Hudson i que pot consumir Trac, dues aplicacions fetes en tecnologies totalment diferents es poden integrar.

Al Hudson passa una cosa semblant, està pensat per tractar amb format oberts, típicament sortides XML en format UnitTest, la qual cosa permet afegir-hi projectetes de Python, Java o SoapUI.

2 comentaris, 0 trackbacks (URL) , Tags: Informàtica Python Java

Integració contínua

Escrit per Aaloy a 10 de February , 2008 a les 5:50 p.m.

Recentment he estat fent un poc de recerca per veure com podia aplicar els conceptes d'integració contínua als nostres projectes. El conjunt d'aplicacions que tenim ha anat creixent al llarg del temps i les dependències entre les llibreries i les aplicacions també ho ha fet.

La idea de la integració contínua és que hi ha un mecanisme automàtic que recull les actualitzacions dels diferents repositoris de control de versions que es tenguin i aplica els tests d'unitat per comprovar que tot funcioni i que els tets passen. D'aquesta manera, i si s'han fet els tests, podem minimitzar l'impacte d'un canvi d'una llibreria en les aplicacions, és a dir, si pel que sigui canviam una llibreria i els canvis impacten a una aplicació de manera no prevista, quan construïm l'aplicació no passarà els tests.

El programari d'integració contínua permet seguir els tests, treure'n estadístiques i veure manera integrada què és el que ha fallat o comprovar que tot ha anat bé. A més es pot utilitzar el programari per a la construcció de l'aplicació i el seu desplegament als entorns de proves. Fet i fet, aquest tipus de coses es poden fer molt bé amb scripts i ens asseguram que en tot moment tenim la nostra aplicació a punt.

En entorns on hi ha molta gent, la integració continua garanteix que si algú "peta" l'aplicació amb commit que no passa els tests, aquest fet es descobrirà prest i es podrà minimitzar el seu impacte. La majoria de sistemes que he avaluat a més permeten a més dels tests unitaris, passar tests al codi font per intentar detectar errors, veure que se segueixen les regles d'estil, etc.

Per a les meves necessitats volia que el sistema d'integració contínua fos capaç de fer feina amb Java (la majoria ho compleixen) però que a més pogués passar els tests de Python i que en general pogués fer des de la construcció de l'aplicació, passar els tests i fer-ne el desplegament.

El que més m'ha agradat per ara és un sistema anomenat Hudson. Hudson és una aplicació recent, feta en Java, fàcil de desplegar i de fer anar. La interfície està molt cuidada i té tot el que necessit per començar. A més hi ha un article de com fer la integració per Python, que m'ha anat molt bé per començar.

Hi ha moltes més alternatives, a mi Hudson me va molt bé perquè té tot el que necessit per aquesta etapa del desenvolupament i és prou extensible com per a que pugui cobrir les nostres necessitats del futur proper. Hi ha altres sistemes a on triar, la gent de Confluence n'ha fet una taula comparativa. Mirau i comparau, però si teniu les mateixes necessitas que jo, no deixeu de fer una ullada al Hudson.

0 comentaris, 0 trackbacks (URL) , Tags: Java Gestió de projectes

Filtres de selecció de personal

Escrit per Aaloy a 13 de August , 2007 a les 10:12 p.m.

Trobar bona gent és difícil i trobar-la que a més es pugui integrar en un equip ja format encara ho és més. A les respostes d'anuncis de feina s'hi pot presentar molta gent i en poques preguntes sovint s'ha d'intentar esbrinar si la persona que tens al davant serà bona tècnicament i a la vegada la seva manera d'entendre la feina serà per l'estil de la que hi a al grup.

Encara que soni molt a tòpic hi ha una sèrie de regles heurístiques que quan parlam de programació web ajuden a fer-se una idea d'ambdues coses:

• Adreça de correu amb domini propi : suma un punt. Per mi vol dir que al manco hi ha una preocupació per cercar-se la vida i potser haver donat d'alta un domini. Tenir un domini implica que també es pot cotorrejar abans de la selecció i veure quins temes preocupen al possible candidat o candidata.
• Adreça de correu amb Hotmail: resta dos punts. Sovint també vol dir que estàs engantxa al messenger i/o que no ets capaç de diferenciar el tenir un correu per usos lúdics d'un per usos professionals. Serveix per a diferenciar la gent que el primer que intentarà fer és posar-se el Messenger.
• Edició d'HTML. Si el sols es sap fer servir el Dreamweaver resta de cop 2 punts. Implica que d'entrada es tendran problemes quan es tracti de modificar planes webs fetes a troços, pràctica habitual en la programació web. Si utilitza un editor amb resaltat de sintaxi suma un, si a més sap fer servi el vi/vim suma dos punts. Si no ha fet mai una plana web resta cinc punts de cop.
• Coneixements de CSS. Si ha maquetat pàgines amb CSS i sap perquè ho ha fet suma 2 punts. Si no sap perquè ho ha fet sols en suma un. Si no sap què és resta un punt. Tenir coneixements de CSS ajuda a saber el que es podrà fer en la pàgina.
• Coneixements de Javascript. Si els sap fer servir mitjanament suma un punt, si a més coneix alguna llibreries de les típiques suma un altre punt. Si sols coneix el que posa el Dreamweaver lleva un punt. Tot es pot aprendre, però si un ja té experiència en Javascript vol dir que realment ha programat per la web. Si a més abans ha dit que utilitzava un editor "per programadors" començarà a agradar-me força.
• Si sap què és l'arbre DOM suma un punt. Si no ho sap i ha dit que ha manejat força Javascript ens haurem de plantejar sèriament si ha està decorant el currículum.
• Si sap què són els estàndards W3C suma un punt.
• Si sap que és un sistema de control de versions suma un punt, si a més l'ha fet servir suma un punt més.
• Utilitzar Linux suma dos punts. Per una part vol dir que encaixarà millor en el grup, però objectivament vol dir que serà capaç de modificar una plana que no està al servidor local, estarà acostumant a que els noms dels arxius són diferents en majúscules i en minúscules, sabrà què és l'UTF-8, etc. I sobretot demostra ganes de fer coses i de no conformar-se amb el que fa la gran majoria.
• Utilitzar Firefox com a eina de desenvolupament. Suma un punt. En suma un altre si coneix dos plugins indispensables per al desenvolupament web.
• Conèixer un llenguatge de programació d'script suma un punt. Si aquest es Python o Perl en suma un altra. PHP o Ruby no puntuen més. Un perquè a un que fa programació web se li suposa un mínim coneixement de PHP i Ruby perquè no es pot distingir de si es fa per moda o per convenciment.
• Conèixer el patró MVC i saber-ho explicar suma un punt. El patró MVC s'ha convertit en omnipresent per la web i conèixer-lo i fer-ho servir indica que es una formació en programar pensant en la separació entre capes.
• Conèixer SQL suma un punt. No fer-ho en resta un. No puc concebre que algú faci webs dinàmiques i no tengui idea d'SQL.
• Conèixer els bastiments i llibreries utilitzades a l'empresa suma dos punts.
• Ser membre actiu de Bulma o algun LUG suma un punt. Indica que el candidat s'implica en el que fa i contribueix amb les seves aportacions.

Hem de dir que d'entrada el possible candidat ha de conèixer el bàsic que se li demana, és a dir, si l'oferta és per programador Java-J2ee, si ja no es sap cap de les dues coses doncs el més probable és que el seu currículum ja no passi pel filtre de RRHH. Si ho fa llavors ens trobam davant un currículum que pot ser vàlid o estar especialment decorat per l'ocasió.

Un currículum amb una puntuació d'entre 17 i 20 és algú que s'ho paga entrevistar amb més profunditat. Entre 13 i 16 convé fer-hi una ullada però no hi ha massa possibilitats així d'entrada, i si és menys que aquest valor doncs potser és millor no perdre-hi més temps.

Tant les opcions com les valoracions són elegides ad-hoc sabent d'entrada el tipus de gent que m'agrada i que potser encaixarà bé en el grup, empreses i grups distints poden tenir valoracions distintes. Segurament una persona amb una puntuació de 20 no encaixarà en un ambient poc dinàmic i que no tengui capacitat d'innovació.

4 comentaris, 0 trackbacks (URL) , Tags: Informàtica Java Gestió de projectes

IBM SDK for Java Version 6 Early Release Program

Escrit per Aaloy a 11 de May , 2007 a les 4:51 a.m.

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

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

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

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

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

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

0 comentaris, 0 trackbacks (URL) , Tags: Java

¿QUIERES SER UN INGENIERO DE DESARROLLO JAVA?

Escrit per Aaloy a 17 de June , 2006 a les 11:30 a.m.

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

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

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

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

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

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

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

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

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

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

Vosaltres mateixos...

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

5 comentaris, 1 trackback (URL) , Tags: Informàtica Java

Quartz - un gestor de treballs per Java

Escrit per Aaloy a 22 de December , 2005 a les 12:58 a.m.

Quartz és un gestor de treballs (job scheduling system) per Java de codi obert que es distribueix baix la llicència Apache 2.0. Segons la seva documentació s'integra perfectament tant amb aplicacións J2EE com amb aplicacions J2SE.

A la web de Quartz hi ha un bon grapat d'exemples per a la seva integració, però el que fa Quartz realment fàcil de fer anar és el bastiment Spring. Hi ha una secció de la documentació d'Spring dedicada a la integració de Quartz amb les nostres aplicacions Spring. La simplificació feta per aquest bastiment és fantàstica, i en pocs minuts podem tenir un completíssim cron a l'abast de la nostra aplicació web i executant les funcions Java que volguem.

Quartz és una d'aquestes coses que convé saber que existeixen i no tenir que anar reinventant la roda o fer pegats per tal de fer que la nostra aplicació realitzi tasques periòdiques. Per cert, s'ho paga llegir-se el tutorial de la sintaxi de cron que hi ha a la web. Clar i ben explicat.

0 comentaris, 0 trackbacks (URL) , Tags: Java

Hibernate tools 3.1 beta

Escrit per Aaloy a 31 de October , 2005 a les 11:14 p.m.

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.

0 comentaris, 0 trackbacks (URL) , Tags: Java

PHP, Java i a veure qui la té més llarga

Escrit per Aaloy a 25 de October , 2005 a les 1 a.m.

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.

0 comentaris, 0 trackbacks (URL) , Tags: Java

JDK 1.5 per PPC?

Escrit per Aaloy a 18 de October , 2005 a les 10:15 p.m.

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...

0 comentaris, 0 trackbacks (URL) , Tags: Java

Arg! Java i PPC Linux

Escrit per Aaloy a 31 de July , 2005 a les 11:11 p.m.

Doncs això, avegades és desesperant. Se suposa que tenc una maquinota i va molt més lent que la màquina que tenc a la feina. A més l'Eclipse es mor a la mínima. Quan vaig comprar el PPC la veritat és que m'esperava més rendiment i m'esta defraudant.

M'estic plantejant sèriament comprar una màquina nova per al desenvolupament Java i destinar el G5 a tasques no relacionades amb la programació amb Eclipse i Java. La veritat és que va molt bé com a servidor, he fet algunes proves amb Postgres i tira molt bé, el problema és no poder desenvolupar en condicions... No és que desenvolupi a casa, però m'agrada investigar i provar coses que a la feina no tenc temps de provar i és desmoralitzant veure que no puc avançar al ritme que m'agradaria per mor del maquinari.

Les màquines de nucli dual de Dell estan molt bé de preu, o els de Miró, que tenen Compaq AMD Duron, en ambdos casos amb pantalla TFT de 17" inclosa per menys de 1200 Eur IVA inclòs. Estaria bé poder fer una comprarativa de rendiment d'aquestes màquines. La versión 5 del JDK té port per AMD 64 bits i també en tenen moltes de les distribucions Linux, en concret Debian i Ubuntu, així que no em faria res poder provar aquestes maquinetes. Ara tot és saber d'on treure 1200 Eur :O

0 comentaris, 0 trackbacks (URL) , Tags: Java

Velocity

Escrit per Aaloy a 31 de July , 2005 a les 10:45 p.m.

Ahir vaig estar llegint-me la documentació de Velocity un sistema de plantilles fet en Java i que es pot integrar dins aplicacions clàssiques o web. La integració dins una aplicació de consola ha estat trivial, sols seguir l'exemple de la documentació. L'únic entrebanc que m'he trobat ha estat amb la part del loggin. Velocity fa servir per defecte el logger del projecte Avalon, projecte que està tancat. Així que m'he disposat a canviar de logger pel més habitual Log4j i aquí han començat els problemes, ja que Velocity està prepart per fer servir Category com a mecanisme per establir el tipus de log (info, debug, warn, ...) i les noves versions de Log4j han abandonat aquesta via i sols utilitzen el logger. Això ha fet que m'estigués barrallant una bona estona amb tot això, primer per descobrir que em faltava el l'Avalon LogKit i després per substituïr-ho per Log4j. Finalment l'exemple ha quedat així:

/*


 

     Copyright 2000-2001,2004 The Apache Software Foundation.
 

 

     Licensed under the Apache License, Version 2.0 (the "License");
 

 

     you may not use this file except in compliance with the License.
 

 

     You may obtain a copy of the License at
 

 

     http://www.apache.org/licenses/LICENSE-2.0
 

 

     Unless required by applicable law or agreed to in writing, software
 

 

     distributed under the License is distributed on an "AS IS" BASIS,
 

 

     WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 

 

     See the License for the specific language governing permissions and
 

 

     limitations under the License.
 

 */
   import org.apache.velocity.app.Velocity;
   import org.apache.velocity.VelocityContext;
   import org.apache.velocity.Template;
   import org.apache.log4j.;
import org.apache.log4j.Logger;
import org.apache.velocity.exception.ParseErrorException;
import org.apache.velocity.exception.ResourceNotFoundException;
import java.io.;
   import java.util.ArrayList;

/ 


 

     This class is a simple demonstration of how the Velocity Template Engine
 

 

     can be used in a standalone application.
 

 

     Fent servir log4j com a logger.
      *
 

 

     @author Jason van Zyl 
 

 

     @author Geir Magnusson Jr. 
 

 

     @author aaloy
 

 

     @version $Id: Example.java,v 1.4.8.1 2004/03/04 00:18:29 geirm Exp $
      */
 

public class Example

{ 
      static Category logger = Logger.getLogger(Example.class.getName());
       public Example(String templateFile)
       {
           BasicConfigurator.configure();
           // Now set its priority.
           logger.info("Proves ....");
           logger.debug("Iniciant");
           try
           {
               /*
                * setup
                /
            logger.debug("Carregant les propietats");
                Velocity.init("velocity.properties");
                logger.debug("Propietats carregades");
            //Velocity.init();
            /
                *  Make a context object and populate with the data.  This 
                *  is where the Velocity engine gets the data to resolve the
                *  references (ex. $list) in the template
                */

        logger.debug("Carregam el contexte");
        VelocityContext context = new VelocityContext();
        logger.debug("Contexte carregat");
        context.put("list", getNames());
        /*
         *  get the Template object.  This is the parsed version of your 
         *  template input file.  Note that getTemplate() can throw
         *   ResourceNotFoundException : if it doesn't find the template
         *   ParseErrorException : if there is something wrong with the VTL
         *   Exception : if something else goes wrong (this is generally
         *        indicative of as serious problem...)
         */

        Template template =  null;
        try 
        {
            template = Velocity.getTemplate(templateFile);
        }
        catch( ResourceNotFoundException rnfe )
        {
            logger.debug("Example : error : cannot find template " + templateFile );                
        }
        catch( ParseErrorException pee )
        {
            logger.debug("Example : Syntax error in template " + templateFile + ":" + pee );
        }
        /*
         *  Now have the template engine process your template using the
         *  data placed into the context.  Think of it as a  'merge' 
         *  of the template and the data to produce the output stream.
         */
        BufferedWriter writer = writer = new BufferedWriter(
        new OutputStreamWriter(System.out));
        if ( template != null)
            template.merge(context, writer);
        /*
         *  flush and cleanup
         */
        writer.flush();
        writer.close();
    }
    catch( Exception e )
    {
        System.out.println(e);
    }
}
public ArrayList getNames()
{
    ArrayList list = new ArrayList();
    list.add("ArrayList element 1");
    list.add("ArrayList element 2");
    list.add("ArrayList element 3");
    list.add("ArrayList element 4");
    return list;
}
public static void main(String[] args)
{
    //Log myLog;
    Example t;
    Example.logger.info("Arrancant");
    //myLog = LogFactory.getLog(Example.class);
    //myLog.info("Iniciant");
t = new Example("example.vm");
//myLog.info("Acabat");
}
}
   

El arxiu de plantilla està agafat directament de l'exemple de velocity així que m'estalvio de posar-ho.

Els arxius de configuració que he fet servir són

log4j.properties

log4j.rootLogger=DEBUG, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
#log4j.appender.stdout.layout.ConversionPattern=%p [%t] [%c] %C{1}.%M(%L) | %m%n
log4j.appender.stdout.layout.ConversionPattern=%d [%t] %-5p %c - %m%n


velocity.properties
runtime.log = velocity_example.log
runtime.log.logsystem.class=org.apache.velocity.runtime.log.SimpleLog4JLogSystem
log4j.logger.org.apache.velocity.runtime.log.SimpleLog4JLogSystem=DEBUG