Proves amb el exelearning: Un editor de recursos didàctics amb XHTML

 Enllaç a un exemple d’unitat didàctica en anglès per a 2on de ESO dissenyada amb el programari ExeLearning.

Aquesta unitat didàctica la vam desenvolupar el curs 2007-2008 en un grup de treball els companys; Mª José Alcaina, Ana Caparrós i jo. Com a programari base per al desenvolupament de la unitat vam utilitzar ExeLearning un programa basat en programari lliure que permet als professors dissenyar recursos didàctics XHTML (Extended Hipertext Markup Language) d’una manera senzilla i visual sense tindre cap coneixement de tecnologies web. Això suposa que tot el contingut de la unitat, quan la publiquem a un servidor web, és accessible als estudiants simplement a partir d’un navegador web.  L’exercici  que vam realitzar, i que no està del tot rematat, és un bon exemple de com combinar vídeos flash, mp3, activitats Jclic , exercicis multi-opció, exercicis de veritat-fals, d’emplenat de buits etc. en una única unitat i que és molt fàcil de seguir per a l’alumne.

Google crea el seu propi navegador web

Amb una política frenètica d’innovació continua, google posa a disposició de l’internauta una beta d’un nou navegador web.  Plana web del projecte
No estan massa clares les raons per les que Google s’ha involucrat en un projecte d’estes característiques ja que en el mercat existeixen nombrosos navegadors (IExplorer, firefox, opera, safari, konqueror etc.)  i fer-se un lloc és molt costós i a més a més diluir esforços tenint navegadors lliures tant potents com mozilla firefox pareix un disbarat. Ells addueixen raons molt ambigües i genèriques que no aporten res nou al panorama tecnològic com, eficiència, velocitat de càrrega, convertir el navegador en una plataforma real d’execució complexa d’aplicacions etc. Més bé pareix un projecte experimental que intentaran que tinga gran difusió d’una manera o altra. En cas de tindre sort i poder posicionar-se com navegador dominant s’estalviaran tots els costos associats a la promoció del motor de cerca google en altres navegadors. Cal recordar que la principal fons d’ingressos del navegador mozilla firefox prové de la companyia google simplement pel fet de posar un  cuadret de cerca a la part superior dreta on les cerques per defecte és fan al motor de google (Este detall són alguns mil·lions de dolars a l’any).

Google Chrome és un navegador dissenyat per fer que l’ús del web sigui més ràpid, fàcil i segur gràcies a un disseny minimalista que no destorba. Realment no és una navegador web creat des de cero sinó que està fet a partir d’altres components de programari lliure ben coneguts com són Apple’s WebKit i Mozilla’s Firefox.  La beta actual està lluny de ser un projecte acabat i només està disponible per a windows però la companyia té previst llançar el producte en un futur com a mínim també per a les plataformes linux i Mac.

Consells per a una tancada d’oposicions

Fa uns mesos vaig recopilar una sèrie d’idees, molt subjectives, dels aspectes que crec que com a mínim cal que tinga en compte un opositor aspirant a professor durant la fase que comunament s’anomena "tancada". Possiblement açò no servisca per res, però per si algú li fa del cas ho deixe en este blog.

1.Si pots intenta no llegir del guió ni de qualsevol altre lloc. Tot memoritzat. El fet de no portar guió te se valorarà positivament en molts tribunals ja que és simptomàtic de que ho has treballat molt.
2. Cal cenyir-se exclusivament al que diu la convocatòria del BOE. Si diu 15 unitats didàctiques com a mínim no en fages menys. Si diu que el guió que pots utilitzar en la tancada no deu excedir un full, per favor, no en dugues dos etc. Estos aspectes poden penalitzar significativament la teua nota ja que poden ser causa d’impugnacions futures del tribunal i per tant estos intentaran complir estrictament el que marca la convocatòria. No obstant introduir algun aspecte innovador o que trenque la monotonia, és sempre molt d’agrair per part del tribunal.
3. Cal contestar de manera encertada les preguntes del tribunal. Hi ha que saber que moltes vegades els membres del tribunal pregunten de manera velada, esperant una contestació en un sentit molt concret. Hi ha que saber interpretar i rectificar, mai entrar en el debat o intentar defensar coses indefensables.
4. Utilitza la pissarra habitualment però molt dosificada sense passar períodes molt perllongats tan sols escrivint sense dir res mentrestant.És convenient que la pissarra s’utilitze per remarcar en cada moment al tribunal de quin punt estem parlant
5. Hi ha que parlar sobre la legislació al punt que li pertoque i després de manera referencial en aquells punts en el que es puga citar. (En FP hi ha que incidir en les capacitats terminals que han d’assolir els alumnes en els diferents cicles ja que estan detallades per llei)
6. En el punt d’atenció a la diversitat o alumnes amb necessitats educatives especials cal contar tots els casos possibles que poden ocórrer: sords, cecs, muds, superdotats, minusvàlids etc. Per a tots els casos hi ha que tindre pensat activitats adaptades ja que moltes vegades els tribunals pregunten sobre estes qüestions.
7. Els continguts i temporalització de la programació didàctica deuen estar molt clars i deuen ajustar-se a la realitat. ÉS RECOMANABLE APUNTAR-LOS EN LA PISSARRA. (El temes i les hores associades a cadascun d’ells)
8. Cal estudiar a casa als membres del tribunal abans de presentar-se a la prova. En quins centres donen classe , quines assignatures, quins cursos han donat al cefire, si tenen weblog així com quines són les seues debilitats i punts forts. (GOOGLE fa milacres en este sentit). Esta coneixença ens pot capacitar per soltar les perletes adequades que els agradarà escoltar.
9. En la defensa de la unitat hi ha que parlar de manera genèrica però sense donar cap classe magistral que puga avorrir al tribunal. Tanmateix a banda d’esta exposició general cal que de manera puntual entres en detall en algun aspecte de la unitat per a que es demostre el teu domini de la mateixa. L’activitat sobre la que decidisques aprofundir intenta que siga atractiva i innovadora per als alumnes i tribunal.
10. L’opositor cal que demostre que el seu mètode d’ensenyament és completament aplicat tal com requereix la FP. Per tant ha de dominar perfectament tot tipus d’activitats i cal que siga capaç d’adaptar estes activitats a qualsevol circumstancia.
11. Cal tindre detalls amb el tribunal que faciliten la seua feina. Per exemple facilitant a cadascun dels membres del tribunal una còpia de la programació per a que puguen seguir-la durant tota la defensa. Si la teua programació no és bona possiblement esta mesura siga contraproduent.
12. Cal que únicament defenses i parles del que està a la teua programació i no altra cosa, no inventes. Per això cal que la programació siga bona i es veja que ha sigut elaborada pel propi opositor. L’opositor se la de creure.
13. Cal demostrar sinceritat, motivació, il·lusió i passió amb el tema exposat.
14. En el punt de la metodologia i l’avaluació cal explicar coses sensates. Si tens experiència docent paga la pena que expliques el que tu fas a classe.En el cas de la FP el comportament no deuria tindre cap percentatge en l’avaluació; simplement és correcte o incorrecte ( hi han graus). Si el comportament és inacceptable eixe alumne no deuria aprovar . L’assistència a classe és obligatòria (deu ser superior al 80%), és perd el dret a l’avaluació continua si les faltes superen el 20% i per tant tan sols es té dret a l’examen final. Comentar que els alumnes sempre deuen tindre clar quins són els criteris d’avaluació del professor i que este deu ser capaç de justificar detalladament en qualsevol procés de revisió d’examen el per què d’una nota.
15. És recomanable nomenar els coneixements transversals que també intentaries transmetre a les teues classes. Cal que remarques la vessant humana del professor i la importància de transmetre valors importants: puntualitat, disciplina, respecte als companys i professor, capacitat de treball en equip, apreci de l’esforç, respecte al medi ambient etc. En el cas de la FP informàtica cal parlar del deure de fomentar l’ús del programari lliure, el respecte als estàndards oberts etc.
16. No has de romandre estàtic o mirant enlloc, cal dirigir la mirada als membres del tribunal però sense focalitzar sempre el mateix punt.Cal demostrar domini de la llengua i no utilitzar reiteradament les mateixes expressions o tics.
17. Cal adherir-se escrupolosament al temps estipulat. 30 minuts per a la defensa de la programació i 30 minuts de la unitat. Cal controlar molt bé els temps (no hi ha que accelerar-se) i és molt recomanable que l’opositor li sobren sempre 6 o 7 minuts per poder convidar al tribunal a que li pregunten qualsevol cosa. És important que l’opositor convide a les preguntes, ja que si no diu res el tribunal no té l’obligació de preguntar. Si el tribunal no fa cap pregunta poden passar moltes coses:
-Està molt bé i no saben que preguntar (Poques ocasions, si és el teu cas es degut a que has fet una defensa molt ben preparada sense punts flacs i molt segur de tu mateix)
-No té cap interès perdre temps per que la defensa no ha estat molt bé i volen acabar prompte (moltes ocasions)
A estes anotacions subjectives poden presentar-se múltiples excepcions com per exemple s’apropa l’hora d’esmorzar o dinar i el tribunal no vol perdre temps etc.
18. És interessant intentar justificar en la tancada el per què del tres temes sortejats has escollit el que has escollit. El tribunal sempre especula i si tenim una justificació raonable de l’elecció això pot ajudar en la teua valoració final.

La UOC llibera tots els materials del seu màster de programari lliure

M’entere a partir de barrapunto que en l’adreça http://ocw.uoc.edu/informatica-tecnologia-i-multimedia podem accedir al llistat complet de materials dels cursets que abaix adjunte.Enhorabona a la UOC per tan magnífica iniciativa

 M2001 – Introducció al programari lliure, Febrer 2008
  M2002 – Sistema operatiu GNU/Linux bàsic, Febrer 2008
  M2003 – Administració avançada del sistema operatiu GNU/Linux, Setembre 2007
  M2004 – Implantació de sistemes de programari lliure, Febrer 2006
  M2005 – Xarxes de computadors, Maig 2005
  M2006 – Ampliació de xarxes de computadors, Febrer 2008
  M2007 – Aspectes avançats de seguretat en xarxes, Novembre 2006
  M2008 – Desenvolupament d’aplicacions web, Febrer 2006
  M2009 – Bases de dades, Febrer 2007
  M2010 – Introducció al desenvolupament de programari, Febrer 2006
  M2011 – Conceptes avançats en desenvolupament de programari lliure, Febrer 2006
  M2012 – Enginyeria del programari en entorns del programari lliure, Febrer 2006
  M2013 – Utilitats i eines, Febrer 2006
  M2014 – Aspectes legals i d’explotació, Febrer 2007

Connexió a una base de dades postgreSQL via JDBC des d’openoffice-base

Connexió a la base de dades "bd_exemple" utilitzant un driver java JDBC (Java database connectivity) per a postgres i des del "openoffice – base" (Un equivalent al Access de Microsoft però lliure) des de Mac OSX 10.4 (Mateix procediment per a qualsevol sistema operatiu ). Crec que és una alternativa molt interessant i que es configura i funciona d’igual manera en tots els S.O. Segons m’ha comentat alguns usuaris que ho han provat: "Fins i tot va millor que amb ODBC, ja que es poden obrir taules definides sense OID’s, cosa que amb ODBC no es pot."

Tant JDBC com ODBC són dos estàndars mundials per la industria del programari que ens permet enllaçar les nostres aplicacions a qualsevol sistema gestor de bases de dades d’una manera uniforme. Son una mena de pont "interlingua" que ens facilita l’accés a la capa de dades d’una aplicació obtenint a canvi una gran independència del fabricant de la bases de dades que podem canviar en qualsevol moment en el futur sense que aquest canvi supose un greu trastoc per a la nostra aplicació. JDBC està indicat sólament per a aplicacions que estiguen fetes amb java.

Molts dels que puguen llegir este text es preguntaran per a que serveix ben bé este tipus de connexió JDBC. Serveix per entre d’altres; per dissenyar consultes, formularis i informes sobre una Base de dades que necessitem però que cap aplicació ens les ofereix, ni tan sols l’aplicació de la que depén la base de dades en qüestió. Per exemple tenim una BD associada a una aplicació de gestió com potser FacturaLux, un programari lliure bastant bó per a facturació i contabilitat de les PYMES i que ademés funciona amb postgreSQL, posem per cas que podriem voler crear informes o consultes per extraure informació que ens interessa però no està disponible mitjançant facturalux però sabem que podem traure-la de la bbdd ja que coneixem quina mena d’informació es desa allí.

Passos a seguir:

1. Baixar el Driver JDBC de Posgresql segons la seua versió en :
http://jdbc.postgresql.org/download.html

Ací tens que baixar l’apropiat per a la teua versió de postgres (en el nostre cas la 8.1), les distribucions actuals de GNU/Linux porten Posgresql version 7.4.x, per a la nostra versió usa el driver JDBC3 següent: http://jdbc.postgresql.org/download/postgresql-8.1-407.jdbc3.jar

Nota: Desa el driver en una carpeta que no esborres
com /usr/local/lib/OpenOffice/jdbc/postgresql o alguna cosa així

2. Obri el OpenOffice 2.x.

3. Ves a l’opció "Tools (Eines)", Després a l’Opció "Options"

4. L’anterior t’obrirà un quadre de diàleg, cerca la branca d’aquest diàleg que diu "OpenOffice.org", dintre d’aquesta branca busca la subbranca que diu "Java".

5. Quan Obris la branca Java el OpenOffice tarda uns segons a descobrir la teua
instal·lació JDK (java development kit) actual, i t’apareixeran les màquines virtuals java instal·lades, selecciona la versió 1.5.0xx. Si no tens cap instal·lada la pots baixar de http://java.sun.com.

6. En la part dreta t’apareixerà un botó que diu "Class Path", prem-lo i t’apareixerà un quadre de diàleg.

7. En la part dreta d’aquest diàleg t’apareixerà el Botó que diu "Add File (afegir arxiu)", pressiona’l.

8. T’apareix un quadre de diàleg d’Arxius , allí busca el Jar file que t’has baixa’t al punt 1 anomenat: postgresql-8.1-407.jdbc3.jar, i dóna-li a "Open (Obrir)"

9. Després d’això voràs que el teu JDBC Driver apareix en el quadre de diàleg de "Class Path", si això és cert vas per bon camí. Pressiona OK.

10. Després pressiona OK en el Quadre de Diàleg de la branca Java.

11. Amb els passos fins al punt 10 deus tindre solament configurat Java i JDBC per a la teva Base de dades, en aquest cas Postgresql, repeteix els passos del 1-10 per a altres bases de dades com Mysql o Oracle o qualsevol altra base de dades que tinga suport per a JDBC (actualment hi ha més de 200 drivers http://developers.sun.com/product/jdbc/drivers).

12. Ara anem a configurar la connexió, en el menú de OpenOffice (Neoffice per Mac OSX) ja obert dóna-li a "File", després "New", després DataBase, així t’obrirà un quadre de diàleg.

13. En el Primer pas d’aquest "Database Wizard" selecciona "Connect to an existing Database", després en el combobox (menú desplegable amb opcions) que apareix baix d’aquesta opció selecciona "JDBC", dóna-li després al botó "Next".

14. T’apareix un altre diàleg que et pregunta pel "JDBC URL" ahi ingressa la següent:
jdbc:postgresql://localhost/bd_exemple

NOTA: En localhost pot ser qualsevol adreça IP o servidor remot on estiga corrent el postgres.

15. En el Mateix quadre de diàleg et pregunta per "JDBC Driver Class", aquesta vària de base de dades segons el driver JDBC a emprar, en el cas de Postgresql és: org.postgresql.Driver per a veure que et carregue el driver correctament pressiona el botó "Test Class", si et respon amb un quadre de diàleg que diu "JDBC Driver Test The JDBC Driver was loaded successfully" llavors tot va bé. En cas contrari has fet alguna cosa malament entre el punt 5 i 10 és convenient corregir si és el cas.

16. Després pressiona "Next"

17.A continuació et preguntarà l’usuari de la base de dades
ingressa l’apropiat amb els permisos d’accés adients, en el nostre cas "fulano", marca l’opció que diu "Pasword required", i pressiona next. (la password és ‘mengano’)

18. T’apareix un altre quadre de diàleg, les opcions per defecte estan bé.

19. Pressiona Finish, T’obrirà un quadre de diàleg d’arxiu (això és no per a desar la base sinó per a desar la configuració de la connexió), posa-li el nom de la base en el meu cas "bd_exemple"

20. Pressiona "Save".

21. T’apareixerà una interficie amigable ja preparada per a treballar en la teua base, selecciona per exemple, "Tables", després l’OpenOffice et demanarà el password (empresa) per al teu usuari de la Base.

22. Pressiona OK

Això és tot

Reflexions sobre bocairent.net

Ja són molts anys administrant i mantenint Bocairent.net, des del 2001 que va ser el seu naixement. Són moltes les hores, disgustos i maldecaps que m’ha dut la pàgina però em compensa resobradament les moltes satisfaccions que m’ha aportat a nivell personal. La veritat es que he aprés moltíssim de tota mena de coses gràcies a esta experiència. La pàgina és una finestra oberta a tot el món que sense la col·laboració de tots els que l’administren, visiten i aporten el seu punt de vista no tindria cap raó de ser.

Són moltes les persones que segueixen la pàgina de manera assídua i aprecien el seu veritable valor, sobretot les que viuen fora i que troben en ella un apropament viu i sentit al poble. Bona mostra de la seua popularitat , a banda de les nombroses converses en les que surt a relluir el nom de bocairent.net, és la seua evolució espectacular en nombre de visites al llarg del temps;

En 2001 . No hi ha dades el sistema era diferent.
En 2002 – 57.852 visites
En 2003 – 262.690 visites
En 2004 – 346.072 visites
En 2005 – 352.516 visites
En 2006 – 890.713 visites

Tanmateix estos indicadors no reflecteixen per a res el grau de satisfacció i/o acord que obté un usuari cada vegada que llig els continguts de la web. Certament hi ha dies que m’agrada més que altres, com a tots, però sé que puc enviar en qualsevol moment allò que vullga per a que s’escolte la meua veu, si no ho faig/fem és per que som massa còmodes. Es veritat que hi ha espais dintre de la web que són més plurals que altres com per exemple els Fòrums i secció de columnistes i d’altres que caldria millorar en aspectes com usabilitat o altres criteris de publicació com les noticies o la galeria fotogràfica per exemple. És sobretot en les noticies on caldria revolucionar més la cosa, al meu parer deuriem d’instaurar els mecanismes necessaris en la web que permeteren de manera efectiva aconseguir eixa pluralitat que tant reclama la gent. Segons la meua opinió ho podriem aconseguir de diferents maneres:

-Tornant a permetre els comentaris anònims en les noticies però amb prèvia supervisió dels administradors tal com es fa amb els comentaris dels columnistes. Dinamitzariem així esta secció i no es descontrolaria tant com altres vegades ha passat.

-Que la decisió de les noticies que pasen a primera plana la prenguera un algorisme automàtic que tinguera en conter el nombre de vots que hi tenen les noticies que han enviat els usuaris i estan en espera de ser publicades (com la web meneame.net). Es a dir cada cop que un usuari envia una noticia anirien a parar a una secció pública de noticies pendents de publicació (el limb). A esta secció podria accedir en tot moment qualsevol usuari i votar aquelles que més li interessen personalment. Amb l’acumulació de vots que anirien rebent les noticies un programa informàtic decidiria quines pasen a primera plana i quines no. Seria un sistema que reflectiria en la pàgina principal, a través de la suma de voluntats de la comunitat de lectors i col·laboradors, que és el que realment els interessa. Persupost només podriem emetre un vot per dia i noticia i els vots dels usuaris enregistrat que més "Karma" tindrien més pes. S’aconsegueix més "karma" quan més participacions positives es realitzen a la web. Els detall exactes ja es podrien parlar.

En definitiva i permitint-me la llicència de modificar una sentència ampliament parafrasejada moltes vegades en bocairent.net el que vull dir és: "Al Cèsar el que és del Cèsar, a déu el que és de déu i al programari (software) allò que pot fer millor que els homes" .

Tot això son idees i projectes, qualsevol aportació de la gent sempre que siga en la línea de fer de la web un espai més amigable i confortable per a tots sempre serà ben rebut. M’apesara el fet de saber que es podrien fer moltes més coses per millorar-la, ja que idees no em manquen, però malauradament la falta de temps em té presoner ,supose que com a la majoria . Ademés hi fan falta recursos econòmics per dur tots estos i molts altres projectes endavant i malauradament som molts els que usem i gaudim de bocairent.net però pocs els que de veritat estem compromesos a finançar-la i millorar-la.

El que hem de fer és treballar tots junts per què la pàgina siga un espai cada vegada més participatiu, millor i més propi i proper per a la comunitat de gent interessada en el poble i el que allí succeeix, si per contra s’embarquem en guerres infructuoses passarà com deia aquell

-Senyors!. L’últim que tanque la porta i que tire la clau a la teulà !!! -.

 

Menys PAI’s i més fer l’indi

És manifest el poc esperit ambiental i ecològic que hi ha instal·lat a les consciències d’occident. Si ja parlem dels nostres amics els ianquis, n’hi ha per acovardir-se. Aquests no tenen el més mínim pudor de passar-se pel folre qualsevol resolució, siga del tipus que siga i vinga de l’ONU, Kioto o de la figa de la tia Bernarda. ”Poderoso caballero…” o el paper verd de l’oncle Sam és el que mana. No ens ha d’estranyar pas, al cap i a la fi són fills directes d’aquells europeus, emprenedors i agosarats, que fa centúries van colonitzar aqueixes noves terres. Gent com aquells són els qui ens han fet hereus del nou ordre del capital, esclaus d’indicadors i conceptes econòmics -PIB, IPC, inflació, IBEX, creixement sostenible, DOW Jones etc.- que se’ns han fet falsament familiars per reiteració, però que la majoria dels mortals no pispa ni un maleït borrall de què signifiquen. Estem entabanats en un joc que sols l’entenen aquells que l’han traçat, “lobbies” amb un gran poder econòmic, polític i social que s’encarreguen d’engrapar ben fort la paella pel mànec i mantenir un món virtual a l’estil Matrix anomenat “democràcia”.

Un món on la cobdícia, la supèrbia, les males arts i els desitjos de poder no són obstacles sinó les principals armes emprades per a imposar-se en aquest joc. Si ja ho diu un Silvio molt morigerat a "Canción de Navidad":

“[…] Tener no es signo de malvado
y no tener tampoco es prueba
de que acompañe la virtud;
pero el que nace bien parado,
en procurarse lo que anhela
no tiene que invertir salud […]”

I això és així, vivim en una democràcia segrestada pels ben parats, on la classe política mai no ha estat al servei del poble sinó dels seus "mecenes".

No puc imaginar què diria ara el pobre cap indi Noath Sealth que ja el 1854 amb la seua carta feia bona mostra d’una lucidesa que el món “civilitzat” fa temps que ha perdut. Una carta en resposta al president del govern dels EUA, que pretenia comprar als indígenes les "seues" terres i relegar-los a ells en una reserva. Un manifest en defensa del medi ambient i la naturalesa que ha perdurat en el temps:

“Com és pot comprar o vendre el firmament, o tan sols la calor de la terra? Aqueixa idea ens és desconeguda. Si no som amos de la frescor de l’aire ni de la fragor de les aigües, com podran vostès comprar- los?… Aquest destí és un misteri per a nosaltres, ja que no entenem per què s’exterminen els búfals, es domen els cavalls salvatges, se saturen els racons secrets del bosc amb l’alè de tants homes i es farceix el paisatge de les exuberants muntanyes amb fils parlants. On és la bosquina? Destruïda. On és l’àguila? Desapareguda. Acaba la vida i comença la supervivència.(TEXT COMPLET)” (o el progrés per a alguns)

L’ésser humà s’ha concedit a si mateix massa importància, ha oblidat que és un animal més en l’equilibri natural i que simplement ha tingut la sort, ja siga per serendipitat evolutiva o per intercessió divina, de ser agraciat amb el poder de l’autodestrucció (o intel·ligència que diuen alguns). L’home ha deixat d’entendre la natura. Ja no sap ni escoltar-la ni viure-hi en relació simbiòtica -prenent i retornant el que li pertoca-. Ha oblidat que n’és part i que això exigeix un respecte.

El PAI (pla d’actuació integrada) que pretén crear al terme de Bocairent una macrourbanització de 1500 xalets i un camp de golf no és altra cosa que una xicoteta mostra, excessiva tanmateix per al nostre poble, de la dinàmica instaurada pel nou ordre. És un despropòsit ecològic, hídric i ambiental que, a més a més, duplica de cop i volta la població i suposa una minva de serveis i una amenaça severa a l’entramat cultural d’un poble forjat durant molts segles.

Sols ens resta protestar de manera cívica, recordant als nostres (?) polítics que estan al servei del poble i no dels "ben parats" (compte amb el verb, que és amb "a"…). Fent saber que no ens interessa aqueix fals progrés.
Que hauria de fer-los vergonya que hàgem d’invertir la salut i fer els esforços necessaris perquè no "ens procuren" allò que no anhelem. Fent d’indi Noath per tal que la veu del poble puga ser escoltada.

(c) 2006 Pere Crespo Molina http://nicklaus.bocairent.net
This work is licensed under a Creative Commons
Attribution-ShareAlike License.
http://creativecommons.org/licenses/by-sa/2.0/

Métodos de distribución de aplicaciones JAVA

Introducción

A la hora de desarrollar una aplicación casi nunca solemos reparar en la forma en la que el software desarrollado será distribuido e instalado en los sistemas de usuario final. A priori esto parece un aspecto poco relevante, pero que puede llegar a ser crítico cuando se pretende que la distribución de la aplicación se efectúe de manera transparente sobre conjuntos de PC’s que pueden llegar a contener varios cientos o miles de unidades. Si además, estos PC’s presentan un espectro de configuraciones de hardware y S.O muy diversa, este proceso puede tornarse excesivamente complejo. En este tipo de escenarios haber planificado un método eficiente y sencillo para la distribución puede ser determinante para evitar la inmensa pérdida de tiempo que conlleva la escasa automatización de este proceso por la consiguiente necesidad de intervención humana para la resolución de conflictos.

Pero si hablamos específicamente de aplicaciones JAVA, a todo lo mencionado, debemos añadir ciertas particularidades propias de esta plataforma. Los programas de JAVA necesitan de la presencia de un entorno de ejecución (Java Runtime Environment JRE) para poder ejecutarse. Este lenguaje nació para ser multiplataforma y ha presumido siempre de este lema; “Write once run anywhere” (Escribir una vez ejecutar en cualquier sitio). Cuando escribimos una aplicación JAVA no la compilamos de manera nativa para una arquitectura hardware/software específica; windows, linux, sparc . La “compilación” de programas JAVA consiste en la traducción del código fuente escrito por el programador a un código intermedio independiente de plataforma denominado “bytecodes” (.class de java). Una vez obtenidos estos bytecodes la máquina virtual Java contenida en el JRE es capaz de interpretarlos y ejecutarlos de manera eficiente sobre la plataforma objetivo como una aplicación más. Por lo tanto, los únicos componentes JAVA que son específicos de la plataforma son las máquinas virtuales de ejecución. Actualmente existe un gran número de implementaciones de estos JRE para la mayoría de las plataformas, incluso para las más exóticas. Además, no sólo la empresa creadora de JAVA, SUN microsystems , es la que ofrece estos entornos de ejecución sino que podemos encontrar abundantes implementaciones de numerosas partes, algunas de ellas libres: sablevm, blackdown, kaffe etc.

Problema

El principal problema de la distribución de aplicaciones JAVA es que para ser ejecutadas necesitan disponer de un JRE instalado en el sistema operativo. En plataformas como Windows esto es problemático porque no viene ningún JRE acompañando la instalación del Sistema Operativo . Por tanto, cuando queremos instalar una aplicación JAVA en este sistema, primero debemos instalar una versión del JRE compatible con los requerimientos de la aplicación (actualmente la última versión de java de SUN es la 5). Llegados a este punto, es dónde pueden empezar los problemas para un usuario medio de Windows. Si la propia aplicación que se pretende instalar no está provista de métodos para efectuar la descarga e instalación de la versión apropiada de la JRE, junto a la propia aplicación, de una manera simple, se pueden producir ciertas situaciones de incomprensión y frustración por parte de un usuario acostumbrado a instalar software de una manera sencilla. Por el contrario en otros sistemas donde la presencia de una JRE viene por defecto y además hay un soporte explícito para mejorar el rendimiento y simplificación de la gestión de programas JAVA , como es el caso de Mac OSX o Solaris, el proceso de distribución y despliegue puede ser mucho más fácil y manejable.

Cuando se compila una aplicación JAVA es conveniente empaquetar el conjunto de clases generadas en un único archivo .jar. A este archivo comprimido contenedor de las clases de nuestro programa debemos acompañar el conjunto de librerías que usamos. Usualmente estas librerías también vienen empaquetadas cada una de ellas en archivos .jar. Con todo el conjunto de librerías y el archivo .jar de nuestro programa y presuponiendo la preexistencia de un JRE apropiado para la aplicación, ésta se ejecutaría de la siguiente forma.

java [options] -cp lib1.jar;lib2.jar … ;libn.jar; miaplicacion.jar MyApp

Dónde la opción -cp indica el classpath(conjunto de librerias usadas) apropiado para nuestra aplicación. Es decir, especifica la ruta dónde poder encontrar cualquier clase usada o definida en nuestra aplicación. Notar que debe incluirse en este CLASSPATH el archivo .jar que contiene las clases propias de nuestra aplicación. MyApp indica la clase principal o punto de entrada a la aplicación, o sea, la que contiene el método main. Esta clase puede estar definida dentro de un paquete, en este caso se debe especificar el nombre completo indicando la ruta de todos los paquetes a los que pertenece. Es usual que cada organización y empresa defina su propio espacio de nombres para especificar un sistema de nombrado de clases coherente y unificado para todas las aplicaciones que desarrolle con el fin de evitar colisiones de nombres de clases. Por ejemplo en nuestro grupo, en el caso de la aplicación MyApp, su nombre completo probablemente podría ser org.upv.gim.app.MyApp, y por tanto en el comando de ejecución java anterior el nombre de la clase de entrada de la aplicación debería aparecer completo; org.upv.gim.app.MyApp.

Si aún quisiéramos simplificar un poco más el comando de ejecución anterior, ya que se podría dar el caso de utilizar decenas de librerías para un proyecto -con lo que la opción de classpath (-cp) sería demasiado extensa- se podría reducir el número de archivos .jar a un sólo archivo desempaquetando todas las librerías usadas con el propósito de reempaquetarlas después de manera conjunta y junto a nuestras clases en un único archivo JAR. Incluso en este mismo .jar podríamos definir en su archivo de Manifiesto (Manifest) cual es la clase de entrada de la aplicación de modo que el comando de lanzamiento se simplificaría a la siguiente instrucción:

java -jar myapp.jar

NOTAS:

jar xvf lib1.jar (comando para desempaquetar .jar no comprimidos)
jar xvfz lib1.jar (comando para desempaquetar .jar comprimidos)
jar cvfz Myapp.jar classes/ (empaqueta de manera recursiva todos los .class contenidos en el directorio classes/ en el archivo Myapp.jar)

Como se desprende de estos ejemplos, a un usuario final inexperto no vamos a poder distribuirle una aplicación JAVA de esta manera. Dándole un conjunto de archivos .jar y una instrucción que debe ejecutar en una línea de comandos para poder ejecutar el aplicativo y además con el agravio de dejarle pendiente como tarea personal la comprobación del entorno de JRE adecuado y en su defecto su descarga e instalación. Por lo tanto, como mínimo, y dependiendo del S.O debemos hacer algún esfuerzo más para simplificar el proceso. En el caso de Windows o cualquier sistema Unix podríamos acompañar al conjunto de archivos de la aplicación un script que contuviese el comando de lanzamiento de la aplicación. De esta forma en un entorno Windows esta instrucción podría estar contenida en un archivo de ejecución por lotes .bat y con un simple doble click sobre el archivo éste lanzaría la aplicación, incluso si hace un uso regular de la aplicación y necesita un acceso rápido podría crearse un acceso directo en el escritorio. En el caso de un sistema tipo Unix se podría solucionar esto mismo con un Script bash, sh o cualquier otro derivado.

Sin embargo aún con este paso no tendríamos solucionado el chequeo del entorno JRE adecuado y su instalación en caso de que éste no estuviera presente. Está claro que en ciertos entornos tendríamos la opción de ampliar la funcionalidad de los Scripts que contienen el comando de lanzamiento para efectuar estas comprobaciones. Sin embargo esta posibilidad está sujeta a la potencia del lenguaje de Script y en cualquier caso difícilmente podríamos informar al usuario de las comprobaciones y posibles opciones a tomar en consideración en forma de ventanas gráficas. Además mantener una versión de Script específica para cada posible plataforma de distribución es una tarea tediosa.

Seria deseable contar con un lanzador multiplataforma de aplicaciones Java no dependiente de la preexistencia de una máquina JRE capaz de efectuar las siguientes comprobaciones y con la siguiente funcionalidad:

  • Comprobar si existe una JRE con una versión adecuada para la ejecución de la aplicación que se desea instalar.

    En el caso de satisfacer este requerimiento, lanzar la aplicación con el comando java acompañado de las opciones y configuración pertinente del CLASSPATH.

  • En caso contrario ofrecer al usuario la posibilidad preferente de instalar una JRE que nosotros mismos hayamos adjuntado en la distribución de nuestra aplicación. Tras su instalación, se ejecutará la aplicación Java sin ningún problema.

  • Como segunda opción. En caso de que el usuario sea consciente de que tiene instalada una JRE pero no se ha detectado correctamente, dar la posibilidad de escogerla navegando por el sistema de archivos para dar con la ubicación correcta de esta JRE.

  • Como tercera opción. Dar la posibilidad de bajarse de Internet una última versión del JRE para instalarlo en el ordenador.

Esto puede ser un método razonable para la distribución de software que no va a estar sujeto a numerosas modificaciones periódicas. No obstante si el software se actualiza constantemente y necesita ser redistribuido este método no está dotado de un mecanismo adecuado para llevar a cabo automáticamente dichas actualizaciones. Por lo tanto, cada aplicación es responsable de este soporte con lo cual debemos implementarlo en la propia aplicación con el objetivo de poder comprobar en algún repositorio accesible vía red de la existencia de algún cambio para poder aplicarlo sobre nuestra instalación, automáticamente o por demanda del usuario.

Es sorprendente que hasta la aparición de la versión 1.4. El propio entorno de programación de java SDK (standard development kit), ofrecido por la empresa SUN, no contemplaba ningún mecanismo de distribución y despliegue de aplicaciones JAVA -con una funcionalidad mínima similar a lo descrito hasta el momento-. No obstante a partir de esta versión incorporaron un mecanismo de despliegue de aplicaciones conocido como Java Web Start cuyo protocolo subyacente se denomina JNLP (Java Network Launch Protocol). Este mecanismo permite la distribución de aplicaciones JAVA a partir de un servidor web. El usuario final puede iniciar la instalación pulsando sobre una URL que apunte a un descriptor JNLP de la aplicación. No obstante, si no contamos con una JRE instalada volvemos a estar en la misma situación anterior, es decir, no podemos lanzar la aplicación. Para resolver este problema la propia empresa SUN ofrece y recomienda algunos scripts para la web que permiten hacer esta comprobación y informar al usuario de la descarga e instalación de la JRE adecuada. Desgraciadamente muchas veces estos scripts no funcionan de manera adecuada en todos los navegadores web y hay que hacer alguna adaptación para su adecuación y además requiere la instalación por separado del entorno de JRE y vuelta de nuevo a ejecutar la aplicación deseada.

Finalmente, en el caso de contar con un JRE o haber efectuado una instalación correcta con el simple acceso a la URL JNLP de la aplicación ésta se arrancará sin problemas dentro del entorno de ejecución controlado de Java Web Start. Este mecanismo nos facilita la instalación de accesos directos en el escritorio y además cuenta con un mecanismo automático de comprobación y instalación de actualizaciones cada vez que ejecutamos una aplicación JWS y estamos conectados a la red. El despliegue de aplicaciones JWS debe especificarse en archivos JNLP donde se definen los requerimientos de JRE necesarios de la aplicación así como el conjunto de librerías y recursos asociados a la misma.

JNLP es una excelente método de distribución para un entorno controlado, como una intranet corporativa, pero no está realmente pensado para destinarlo a un mercado de consumo dónde la forma de instalación/desinstalación y uso de los programas deba ser exactamente igual a la forma en la que se efectúan las instalaciones de programas nativos para dicha plataforma. En el caso de una intranet, con equipos lo bastante potentes para ejecutar de manera fluida un entorno JRE superior o igual a la versión 1.4 – y en la que se puedan contar con los suficientes recursos humanos encargados del soporte informático – se pueden paliar los posibles incidentes de la distribución de aplicaciones vía JNLP de un modo aceptable.

No es hasta la versión 1.5 de java JWS dónde realmente se presenta una integración con el escritorio apropiada (especialmente para entornos Windows). Sin embargo los requerimientos de un PC para ejecutar de manera fluida aplicaciones gráficas java basadas en SWING/AWT sobre un entorno JRE pueden ser insuficientes si contamos en la intranet con un conjunto numeroso de PC’s con hardware con pocos recursos.

En este tipo de situaciones es cuando es necesario replantearse seriamente desde el principio la posibilidad de un cambio radical del diseño de nuestra aplicación. En nuestro caso tuvimos una experiencia que puede ejemplificar un caso de uso similar dónde este cambio de diseño facilitó el despliegue y mantenimiento de la aplicación de manera considerable.

El caso es el siguiente:

Hospital CHGUV

Se necesitaba implantar en un entorno hospitalario un visor para la historia clínica de los pacientes que debía ser instalado en cada uno de los PC’s usados por el personal sanitario de la institución. Las cifras no eran nada desdeñables, ya que en la intranet se contaba con un millar de máquinas. En un principio se diseñó una aplicación basada en una arquitectura cliente-servidor. El cliente era la única parte del software que debía ser distribuida. Este cliente consistía en una aplicación GUI basada en Java/SWING que permitía buscar pacientes y mostrar su historia clínica de manera homogénea y unificada, recabando toda la información clínica dispersa por las diferentes fuentes de datos del hospital. La tarea de recolección de toda la información se efectuaba en la parte servidora y el cliente tenia acceso a esta información a partir de los Web Services expuestos por el servidor.

Todos los usuarios de la intranet contaban con equipos donde estaba instalado el S.O Windows en cualquiera de sus muchas variantes. De modo que había desde equipos con Windows Nt.4 hasta equipos con Windows XP y algunos menos con otras versiones. Todos ellos estaban bajo un mismo dominio controlado por el servicio LDAP de Windows -denominado Active Directory (AD)-. Con el AD los usuarios pueden autentificarse con sus cuentas desde cualquier equipo perteneciente al dominio.

El AD y los sistemas LDAP en general además de servir como mecanismo distribuido de autenticación cuentan con numerosas funcionalidades adicionales. Algunas de ellas son; La aplicación de políticas de seguridad global, nombrado de máquinas , políticas de actualización y distribución de software etc. Aprovechando las funcionalidades de distribución, se especificó una política para instalar de manera automática -sin ninguna intervención del usuario- una JRE y un enlace JNLP en el escritorio que apuntaba a nuestra aplicación Swing ubicada en un servidor web. Previamente se tuvo que convertir el archivo instalable de la JRE en un archivo .msi para poder instalarlo sin necesidad de ninguna interacción de usuario. Una vez establecida y aplicada la política en el AD, a los usuarios que cerraban su sesión y volvían a entrar para autenticarse de nuevo, se les instalaba de manera automática el JRE sin necesidad de ningún tipo de interacción y además les aparecía en el escritorio un enlace con el icono del visor apuntando al archivo .JNLP descriptor de la aplicación visor de historia clínica del paciente.

En apariencia este tipo de distribución parece bastante automático y cómodo, sobre todo en lo concerniente a la fácil distribución de las modificaciones gracias a las capacidades del protocolo JNLP. Sin embargo, en la práctica, esto no fue tan sencillo y eficaz como se anticipaba. Hubo un importante número de ordenadores que por problemas de carga del driver de la tarjeta de red no eran capaces de ejecutar las políticas de instalación establecidas en el AD. Otros tantos, por problema de sistema operativo, tampoco realizaban bien o la instalación de la JRE o del enlace a la aplicación en el escritorio. Además, existían muchos ordenadores con unos recursos de hardware insuficientes para correr con comodidad la versión 1.5 de java y nuestro visor Swing.

Ciertamente no eran problemas críticos, ya que posiblemente sólo afectaban al 10% del total de los ordenadores, sin embargo se requería de una intervención técnica personal para atender las incidencias que los usuarios presentaban.

Finalmente se decidió migrar la aplicación cliente SWING a una versión web. Esto se pudo llevar a cabo de una manera rápida debido a que la interfaz gráfica no era excesivamente compleja. Utilizando Struts, algo de ajax para ciertas sincronizaciones, JSP y html, se pudo emular una interfaz con una apariencia y comportamiento exactamente igual a la que estaban acostumbrados los usuarios pero esta vez a través de una interfaz web.

Con este nuevo diseño, dónde el peso de ciertas operaciones recaían sobre el cliente, ahora trasladábamos toda la carga al servidor web -junto con el Tomcat (contenedor de servlets)- que eran los encargados finales de servir la aplicación. Con esta nueva configuración la distribución de las modificaciones es igual de sencilla ya que con sólo modificar y desplegar en el servidor web la nueva versión esto se refleja de manera automática en los usuarios que acceden al cliente a través de un navegador web. Además, ahora incluso los ordenadores con pocos recursos pueden hacer uso de este cliente de una manera mucho más fluida.

Está claro que el paso de una aplicación a su versión web no siempre es posible, sencilla o aconsejable. Por ejemplo cuando utilizamos interfaces muy ricas, excesivamente complejas etc. Hay que notar que la productividad es un factor importante a tener en cuenta en el desarrollo y que actualmente hacer aplicaciones web supone un esfuerzo de tiempo y dedicación mucho mayor que su homónimo para escritorio. Por lo tanto se deben sopesar y analizar los posibles riesgos y ventajas antes de tomar decisiones precipitadas de diseño, ya que nos pueden facilitar ciertos procesos como la distribución pero entorpecer otros como la implementación.

Es verdad que este tipo de escenarios no suelen ser los más comunes. Muchas veces desarrollamos aplicaciones a medida que van destinadas a un grupúsculo reducido de usuarios. En estos casos distribuirles un CD o darles un enlace de descarga de la aplicación puede ser suficiente. En esta situación el CD o el archivo del programa debe contener un programa de instalación que autogestione todos los problemas técnicos de instalación que a un usuario medio no tienen por qué importarle. Este programa de instalación debe ser capaz de informar al usuario de los componentes del proyecto que se van a instalar y además posibilitar que la aplicación se integre en el sistema de manera nativa al igual que la mayoría de aplicaciones.

Actualmente podemos encontrar en el ciberespacio una gran cantidad de aplicaciones que nos ayudan a empaquetar el software y generan proyectos de instalación personalizables para nuestros proyectos. Izpack es un ejemplo de este tipo de programas. Está realizado en java y permite aglutinar de manera sencilla en un único archivo .jar todos los archivos a instalar. De esta manera conseguimos que el programa de instalación sea exactamente el mismo para cualquier plataforma. No obstante volvemos a caer en el mismo problema anteriormente citado; “Necesitamos de un JRE para lanzar el programa de instalación porque está hecho en Java”. De modo que si queremos un software de chequeo e instalación automático o guiado de un JRE necesitamos que este sea nativo a los binarios o lenguajes de scripts soportados de serie por el S.O.

En el caso de Izpack podemos encontrar un lanzador de instaladores izpack-java hecho en C++ y que hace uso de las librerías gráficas Qt (son multiplataforma) que nos permiten sortear esta necesidad. Cuando ejecutamos aplicaciones Java éstas no aparecen como procesos diferenciados en el S.O. De modo que si estamos ejecutando varias aplicaciones java estas no aparecen diferenciadas en la lista de procesos del S.O, todas aparecen como procesos java. Gracias a los lanzadores nativos conseguimos que las aplicaciones Java se pueden lanzar como procesos identificables de manera que podemos asociarles iconos propios y tenemos capacidad de gestionarlos (matarlos, controlar su ciclo de vida desde una aplicación …) sin interferir con otros procesos java.

El objetivo es encontrar un programa nativo para cada plataforma que se encargue del lanzamiento del programa de instalación y de la comprobación y posible instalación de una JRE adecuada para su funcionamiento. Esta tarea puede ser demasiado ardua si para cada plataforma se tiene que implementar un lanzador distinto. Es deseable encontrar una única forma para implementar un lanzador multiplataforma. Los lenguajes de programación C y C++ son los más potables , pero sólo si se usan las librerías ANSI propuestas como estándar para estos lenguajes. Entre estas librerías estándar no existe ninguna encargada de representar ventanas y widgets gráficos en un sistema operativo basado en ventanas. Esto puede ser un impedimento para el lanzador, ya que queremos que informe por pantalla al usuario del hecho de la inexistencia de una JRE adecuada y que además le de opción a escoger como solucionar el problema:

Para la parte gráfica y la comprobación de la existencia de la JRE adecuada en el sistema podemos hacer uso de las potentes librerías Qt de TrollTech (El escritorio para linux KDE está basada en ellas). Estas librerías están bajo licencia dual y son totalmente libres si se utilizan para un proyecto libre – en caso de ser comercial hay que pagar unas “royalties” por su uso-. Estas librerías son multiplataforma, lo que nos permite escribir un único programa en C++ para actuar como lanzador de aplicaciones Java y compilarlo luego natívamente en cada una de las plataformas en las que queramos que se distribuya la aplicación.

Para distribuir el lanzador Qt en su versión Windows es necesario adjuntar en el mismo directorio de la aplicación de instalación las siguientes librerías; mingwm10.dll, Qtcore4.dll y QtGui4.dll.

Otra opción para evitar la necesidad de una JRE que es menos utilizada, pero que en algunos casos incluso podría ser beneficiosa en muchos aspectos, consiste en la compilación nativa de nuestras clases Java a las distintas plataformas para las que queremos desplegar el sistema.

Es lo que se conoce como compiladores “Ahead-Of-Time” o compiladores estáticos o nativos. Existen algunos compiladores de este estilo que permiten que nuestras clases java sean convertidas a un ejecutable específico de plataforma, por ejemplo un EXE para windows o un binario ELF para Linux o un APP para MacOSX. Este tipo de solución suele generar código que se ejecuta de manera más eficiente que la interpretación de bytecode por parte de una máquina virtual. Además nos facilita la instalación e integración perfecta sobre la plataforma objetivo. Sin embargo, actualmente no existen muchas opciones libres para realizar esta compilación. Los chicos de GNU están extendiendo su potente compilador gcc con una variante denominada gcj que parece prometer bastante. Actualmente permite la compilación de numerosos programas Java en diferentes modos:

  • Código fuente java directamente a código máquina nativo

  • Código fuente Java a bytecode (archivos class)

  • Java bytecode a código máquina nativo

Desgraciadamente existen aún numerosas clases de la librería de Java 2ª edición que no puede compilar . Especialmente las relacionadas con la creación de interfaces gráficas con componentes AWT o Swing. Se pretende que la convergencia del compilador GCJ con el proyecto Gnu Classpath – que dispone de una implementación libre bastante avanzada de todos los paquetes java de la 2ª edición – permitirá la compilación nativa, teóricamente, de cualquier aplicación Java (por lo menos en Linux o en cualquier sistema unix).

Conclusión.

A la hora de distribuir software para instalación basado en Java se deben contemplar numerosos aspectos. Hay que distinguir si la aplicación desarrollada es de instalación pública o privada, va destinada a un número limitado de PC’s o a varias decenas o cientos, frecuencia de actualizaciones, nivel de conocimientos informáticos esperados de los usuarios finales, recursos disponibles en los ordenadores para los que se instalará la aplicación, necesidades de integración con el escritorio y/o sistema etc…

Según nuestro criterio y para facilitar la distribución y instalación de aplicaciones JAVA podríamos resumir los escenarios más importantes y las posibles recomendaciones para cada uno de ellos a modo del siguiente cuadro resumen:

Intranet                                                                Internet                                                                Grupo Reducido de usuarios             

i la aplicación debe correr en muchos ordenadores y algunos de ellos cuentan con pocos recursos es aconsejable replantear su diseño para realizar la aplicación en versión web.

En otro caso JNLP es una buena opción de distribución.

Usar el sistema LDAP o AD(en windows) para ayudar en la distribución. Por lo menos en el despliegue de un enlace con el icono apropiado en el escritorio para que los usuarios noten y puedan acceder a la nueva aplicación a través de él.

Si la aplicación está a disposición pública para su descarga, JNLP es un buen método de distribución general. No obstante si la necesidad de actualizaciones constantes no es un requisito importante y queremos que el usuario se sienta cómodo con la integración de la aplicación en su sistema darle la posibilidad de descarga de un lanzador/cargador y/o programa de instalación para su sistema específico simplificará su instalación y la percepción positiva sobre la misma.

Si es importante el rendimiento y queremos que la aplicación sea completamente nativa y no dependa de un JRE utilizar un compilador “Ahead-of-time” puede ser una opción interesante.

Lanzador/cargador y/o programa de instalación específico para su plataforma que se integre de manera nativa con el resto de las aplicaciones para que el usuario no perciba siquiera que está haciendo uso de una aplicación JAVA.

Al usuario acostumbrado a java darle la posibilidad de ejecutar la aplicación al menos del siguiente modo:

java -jar myapp.jar

Si es importante el rendimiento y queremos que la aplicación sea completamente nativa y no dependa de un JRE utilizar un compilador “Ahead-of-time”

Tabla de diferentes herramientas de apoyo a la creación, empaquetado, carga, lanzamiento etc. de aplicaciones java.

1.Compiladores Ahead-of-time para java   2.Wrappers y lanzadores nativos para aplicaciones Java (jre check) 3.Creación de instaladores para aplicaciones Java

Libres

GNU GCJ classpath

izpack-launcher

IzPack

launch4j

Roxes Ant tasks

Comerciales

Excelsior JET

exe4j

InstallAnywhere

NewMonics PERC

JExeCreator

InstallShield

install4j

(c) 2006 Pere Crespo Molina
This work is licensed under a Creative Commons
Attribution-ShareAlike License.
http://creativecommons.org/licenses/by-sa/2.0/

Jess, un motor de regles d’inferència per a JAVA

Dissenyar un sistema expert per a solucionar un problema molt especialitzat sempre ha sigut una tasca molt complicada, degut a que l’informàtic que programa l’eina deu arribar a comprendre, al mateix nivell que l’expert en la materia, el problema que es pretén resoldre. Un sistema d’estes característiques normalment està compost per nombroses regles, excepcions i arbres de decisió amb la finalitat de poder donar una resposta, versemblant a com ho podria fer un expert, a partir d’unes dades d’entrada. S’utilitzen per a problemes molt especialitzats. En l’àmbit de  la medicina  hi han molts casos. Per exemple, es pot dissenyar un sistema expert per a decidir quin va ser el millor tractament antibiòtic per a una persona amb una infecció i característiques particulars. Per exemple, una persona amb les següents característiques:

  • Edat: 45 anys.
  • Sexe: varó.
  • Diagnòstic: cistitis.
  • Malaltia de base: Diabetes.
  • Factors de risc: sondatge uretral
  • Infecció recurrent: Si

Davant estes entrades, el sistema expert deuria ser capaç de recomanar l’antibiòtic més adient per  tractar de manera efectiva la infecció d’esta persona perquè no es tornaren a repetir els brots. Per a prendre esta decisió es deurien tindre en compte dades sobre quins són els microorganismes d’infecció normalment associats a l’enfermetat de diagnòstic així com les seues taxes de resistència (informació microbiològica de laboratoris) pròpies de l’àrea sanitaria junt a les recomanacions internacionals de publicació anual respectives i altres paràmetres rellevants per a la resolució efectiva del problema.

Habitualment per dissenyar i programar este tipus de sistemes s’han emprat llenguatges i eines de programació diferents de les tradicionals per construir software (programació estructurada, imperativa, orientada a objectes etc.).

La principal distinció  entre un sistema expert i un tradicional, orientat a la resolució de problemes, és el mode mitjançant el qual la lògica pròpia de la part de l’expert és codificada. En les aplicacions tradicionals, la lògica de l’expert està codificada tant en el programa com en les estructures de dades que s’empren.

Pel contrari en una aproximació basada en un sistema expert tota la lògica que té a vorer amb l’expert solament està codificada en les estructures de dades; no en el programa.  En el programa soles es declaren les regles d’interacció i inferència que hi ha entre cada una d’estes estructures. Estes regles són regles lògiques independents del domini i per tant el benefici d’esta separació es òbvia.

Els llenguatges de programació més habituals per a este tipus de problemes provenen del camp de la intel·ligència artificial. Són normalment llenguatges lògics i/o declaratius tipus prolog, mycin, lisp, clips, jess etc… Molts d’ells tenen ja una llarga història de moltes dècades (LISP any 58, prolog any 72, clips any 85 …).  Han demostrat ser llenguatges molt adecuats per alguns tipus de problemàtiques com la que ara estem descrivint, però són un fracàs comercial per construir i solucionar de manera productiva la majoria de programari que necessita i demanda el mercat.

Hi tinc un especial interés per Jess ja que està escrit en Java i permet fer ús de l’API de la plataforma Java. És un llenguatge de script que et permet construir programari amb capacitat de "raonament" emprant el coneixement que se li especifica a mode de regles declaratives. Jess és xicotet, lleuger i un dels motors de regles més ràpids existents. CLIPS (És liure i està fet amb C) és la inspiració per a Jess i per a molts altres sistemes per construir sistemes experts. La sintaxi de Jess és molt pareguda a la de CLIPS. Per tant, si estàs familiaritzat amb CLIPS no vas a trobar grans diferències en el seu ús, no obstant Jess té particulartitats específiques.

Açò és el que diuen en la web de jess (http://herzberg.ca.sandia.gov/jess/):

"Jess uses an enhanced version of the Rete algorithm to process rules. Rete is a very efficient mechanism for solving the difficult many-to-many matching problem (see for example "Rete: A Fast Algorithm for the Many Pattern/ Many Object Pattern Match Problem", Charles L. Forgy, Artificial Intelligence 19 (1982), 17-37.) Jess has many unique features including backwards chaining and working memory queries, and of course Jess can directly manipulate and reason about Java objects. Jess is also a powerful Java scripting environment, from which you can create Java objects, call Java methods, and implement Java interfaces without compiling any Java code."

Hi ha disponible un plugin per l’entorn Eclipse per poder programar de manera còmoda amb JESS. L´Ãºnic problema d’esta eina (a pesar de ser debades) és que no és lliure:

"Jess is not licensed under the GPL, the LPGL, the BSD license, or any other free software or open source license. Redistribution of the Jess source code under any free software or open source license is prohibited under this agreement. "

Un llibre recomanable per a programar amb esta eina és "Jess In Action (JIA)" ,està escrit pel propi creador de Jess. 

Weblog personal de Pere Crespo Molina.