Se hace camino al andar...

Tanta gente me ha preguntado como poder utilizar el API de jLibrary que no me ha quedado más remedio que crear un par de ejemplos. Uno de ello utiliza el archivo del BOE para descargarse los boletines e indexarlos en un repositorio de jLibrary. Dejo aquí la referencia al artículo por si a alguien le interesa o le da ideas

Parseando el BOE

Ojo si ejecutáis el ejemplo. 1 mes = +600Mb ;-)

Por fin se ha hecho oficial. Del 20 al 23 de Marzo estaré en California, en la EclipseCon 2006, presentando jLibrary. He tenido la suerte de ser premiado con una de las diez becas para proyectos Open Source, así que estaré presentando jLibrary en el Open Source Pavillion de la conferencia.

Estoy muy ilusionado con el viaje. Sé que es muy difícil que haya la casualidad de que alguien que lea esto vaya a estar allí, pero en tal caso, ¡allí nos veremos!

En el blog de Mike Milinkovich aparecen hoy varias historias simpáticas acerca del uso que está haciendo la gente del logo de Eclipse. Claro, es un logo EPL, y después aparecen imágenes curiosas como esta de canarias:

Supongo que esto se podría considerar como uno de los riesgos del Open Source :D

Bueno, después de tanto tiempo sin escribir nada, voy a aprovechar para hacer un poco de spam. Acabo de lanzar jLibrary 1.0beta4, y creo que vale la pena, así que podéis visitar su página web, para obtener más información. Las novedades son muchas, pero lo mejor es que vayáis y las veáis por vosotros mismos.

Un saludo.

Un problema común en aplicaciones web surge a la hora de ejecutar trabajos en ciertos intervalos de tiempo desde una aplicación web. Hay varias opciones, pero cada una de ellas presenta ciertos inconvenientes:

java.util.Timer: Es una solución problemática ya que crea hilos fuera del dominio del servidor de aplicaciones, lo que podría ocasionar problemas potenciales.

Utilizar frameworks como quartz: Estamos en el mismo caso de antes. Estos frameworks toman el control y crean sus propios hilos. Esto no tiene que ser un problema cuando tú distribuyes tu producto (pues por ejemplo jLibrary utiliza quartz), pero sí lo es cuando tienes que meter una aplicación web en un servidor de terceros.

Utilizar un EJB de Timer: Es una solución. Pero requiere EJB 2.1, y por lo tanto J2EE 1.4, y todavía hay demasiados entornos con J2EE 1.3. El requisito de un EJB también te obliga a utilizar un servidor de aplicaciones completo.

Utilizar el WorkManager de JCA 1.5: Requiere J2EE 1.4 y te obliga a utilizar un servidor de aplicaciones completo.

Utilizar el API commonj (Timer and Work Manager for Application Servers): La verdad es que es una de las opciones más interesantes. Lo malo es que esta especificación del 2003, se retrasa y se retrasa. Por ahora sólo la soportan Weblogic 9 y WebSphere 6, así que tampoco hay mucho que hablar. A ver si se extiende porque es muy interesante y útil.

Utilizar un MBean de Timer con JMX: Esta es una solución interesante. Todo servidor compatible con JMX (es decir, cualquier servidor J2EE) está obligado a ofrecer un servicio de temporización sobre el que se pueden ejecutar trabajos. De este modo, tú puedes registrar ahí un MBean que se invocará regularmente y que notificará a tus clases el que se ha producido un evento. El problema es que en clusters, el modo de ejecución depende de como se implemente internamente el servicio de JMX en el servidor de aplicaciones. Quiero decir, ¿se ejecutará una única vez en una única máquina?,¿se ejecutará el trabajo en todas las máquinas?,¿tienes que atacar al servicio de JMX en algún modo concreto?, etc...

Otro servlet: La solución más trivial es crear otro Servlet que realize la tarea periódica y tener un proceso externo que llame periódicamente a ese Servlet. El problema es que en el entorno de despliegue tienen que admitir que les instales un servicio, o algo similar, cosa que no siempre se puede admitir.

¿Alguna solución más? ( Por cierto si alguien está interesado en la solución con JMX, podría publicarla ).

Pues nada, que me han pedido un programa Open Source para la gestión de personal. La idea es muy simple, poder crear fichas de personal, asociarles documentos, ofertas, etc. para posteriormente realizar búsquedas. Nada más ni nada menos.

El caso es que he intentado buscar por ahí, y no parece que haya demasiadas cosas así tan específicas. Los ERPs o las herramientas de gestión de proyectos, son excesivos para este caso.

Así que aquí dejo esto por aquí. Si alguien ha encontrado algo similar por ahí, le agradecería que me/nos diese el chivatazo :-)

Por fin, y más de dos meses de duro trabajo, está disponible la beta3 de jLibrary. jLibrary es el fruto del trabajo de muchos meses de un grupo de personas (aunque ahora cada vez necesito más ayuda) localizado actualmente en varios puntos del mundo.

Entre las novedades más importantes destacan:

• Reestructuración de los repositorios.
• Migración a las últimas versiones de todas las librerías, incluyendo Eclipse 3.1, Hibernate 3, Axis 1.2.1, etc.
• Trabajo con recursos mucho más fácil e intuitivo.
• Instalador para plataformas Windows.
• Soporte de actualizaciones automáticas de la aplicación.
• Mejoras en la extracción e indexación de los documentos.
• Soporte de arrastrar y soltar, y de cortar y pegar, directamente desde el sistema operativo.
• Descarga de documentos desde la web de un modo mucho más sencillo.
• Mejoras en el sistema de ayuda.
• Y mucho más. No olvides echarle un vistazo a las novedades para ver el resto de mejoras.

Para descargar jLibrary puedes acudir a la página de descargas. Actualmente hay dos versiones: una para Windows que ha sido probada tanto en Windows XP como en W2K y otra para Linux con GTK. La plataforma recomendada es Windows. Esta recomendación se debe única y exclusivamente a que ha sido el entorno en el que más se ha probado jLibrary, y donde por lo tanto, la aplicación es más estable.

El interfaz de usuario de jLibrary está internacionalizado tanto para español como para inglés. El motor de indexación sin embargo soporta más de once lenguajes. Si deseas traducir el interfaz de jLibrary a otro lenguaje (sólo es crear un nuevo fichero de recursos) contacta conmigo - también lo puedes hacer si deseas colaborar en el proyecto :-)

Después de descargar jLibrary, sigue las instrucciones de instalación. No te fies porque jLibrary se ejecute directamente sin problemas. Leer esto es muy importante para realizar tareas como cambiar la base de datos que utiliza.

jLibrary por defecto viene configurado con HypersonicSQL como gestor de base de datos. Aún así, este no es el gestor recomendado. Se incluye únicamente para facilitar la rápida ejecución, y la integración de un motor de bases de datos local. Actualmente, el motor recomendado por jLibrary es MySQL, aunque también se puede utilizar PostgreSQL (no ha sido probado profundamente).

No olvides echarle un vistazo a las novedades. Tampoco te olvides de leer la Documentacion, ni sobre todo de leer los tutoriales. Además de esta ayuda online, jLibrary incluye una presentación de ayuda, una ayuda interna en la que puedes buscar solución a tus problemas, y una serie de hojas de ayuda que te permitirán aprender a utilizar la herramienta.

Y por último no olvides que se trata de una versión beta. jLibrary, que como verás es un proyecto muy grande, está lleno de pequeños bugs. Si por cualquier razón encuentras alguno de estos bugs háznoslo saber. Por cierto, ¿he dicho que jLibrary busca colaboradores? Cualquier ayuda sería bien recibida, tanto en las tareas más complejas como en las más simples.

Espero que os guste jLibrary.

Parece ser que en la JavaOne Scott McNeally y Fabiani Nardon estuvieron hablando sobre integración, HL7, y sistemas sanitarios. El siguiente texto está extraido del informe de TheServerSide:

McNealy later spoke about unique problems in the healthcare space. ?If there was ever a need for an SOA based, JBI solution, it?s the whole healthcare IT environment?. Sun has been working on HL7 Java special interest group, focused on message and data exchange between hospitals. Following up on the ?growing crisis? in healthcare, a video was shown of Brazil National Healthcare system. Brazil offers free healthcare to every citizen. Each citizen in Brazil has a unique identifier, allowing them to be tracked in any medical institution. The ID gives access to a database showing all patient history. The healthcare system is based entirely on J2EE ? it?s platform independence being the main reason for choosing it, as well as Java?s security features.

Fabiani Nardon, CTO of the Brazilian national health systems was invited up to the stage. She mentioned how easy the system to use. No matter where you are in Brazil, you just present your ID and your medical database will be available. She mentioned how many people can now get instant consultations, where in the past it would take over 3 months. 2.5 million lines of Java code were written over a 4 month period to make the system work. She mentioned that their entire system is open source, allowing other countries to easily adopt and begin using it.

Yo supongo que en este texto habrán sus mentirijillas, que no todo será tan inmediato ni tan fácil, pero aún así España debería sonrojarse. Porque tenemos un país donde cada comunidad, por no decir cada provincia, tiene un proyecto igual que este, o paga a empresas externas para que lo desarrolle. Y encima es algo que pagamos todos.

He estado leyendo esta noticia de javaHispano en donde se habla sobre Backbase, y me ha hecho pensar en AJAX, y en como puede ser problemático en determinados casos que explicaré a continuación.

Antes de nada, me gustaría comentar que la demo de Backbase me ha gustado muchísimo. Es genial ver todos esos efectos, hasta ahora relegados al mundo del escritorio, ejecutándose en Firefox sin ningún problema.

Desde luego, no hay una buzzword en estos meses que esté sonando más que AJAX. El término AJAX ha aparecido de repente y ha convertido las aplicaciones web tradicionales en RIAs (aplicaciones ricas de Internet), incrementando la usabilidad de sus interfaces y haciendo posible el uso de componentes hasta ahora relegados a otros ámbitos. A pesar de que ya sabéis que era algo que existía hace tiempo, lo cierto es que ha sido como un truco de magia, "ahora ves un pañuelo, y ahora ves un conejo".

Pero ojo con la magia, porque siempre hay truco. Y eso es lo que no se debe olvidar. Como sabéis, la clave en AJAX es esconder las interacciones con el servidor, realizándolas en un modo asíncrono de modo que el usuario no se entera de que están pasando cosas. Si a esto le sumamos que el árbol DOM se actualiza dinámicamente, tenemos que se solventa el problema de las molestas transiciones entre páginas. ¿Cuál es el problema entonces, si todo es tan bonito?

El problema es que como en los trucos de magia, las cosas son de un modo diferente al que se ve. Aunque el usuario no lo vea, por detrás se siguen haciendo continuas llamadas a través de la red, como en las aplicaciones web de siempre. El peligro, es que muchos desarrolladores creo que no se están dando cuenta de esto, y están viendo a AJAX como una solución a todos sus problemas, un nuevo paradigma de programación que por fin ha solucionado los problemas de las aplicaciones web, y que hará que todo y absolutamente todo sea web.

Pero señores. Cordura. Como decía en mi charla en la TechBusiness Week (tenéis las transparencias en el post anterior), la web no es necesariamente el mejor lugar para las interfaces de usuario. Ni con AJAX, ni sin AJAX. La web es un excepcional lugar para cierto tipo de aplicaciones, sobre todo las que se han de distribuir a través de Internet, las que necesitan un acceso masivo y heterogéneo de usuarios, o para las aplicaciones que requieren una enorme ubicuidad. Y es que tenemos ejemplos de aplicaciones web modelo de éxito como flickr, amazon, las googles, y muchas más que se os ocurrirán...

Pero sin embargo, como decía en el párrafo anterior, hay muchos casos en los que un interfaz web está abocado al fracaso. No voy a entrar en las ventajas de las aplicaciones de escritorio frente a las web, porque las tenéis en las transparencias que comentaba. En lugar de esto lo que sí que voy a hacer es comentar un ejemplo que ponía en Alicante, y que creo que es descriptivo de uno de los problemas más importantes de las aplicaciones web, y más concretamente de AJAX. Este problema es la necesidad de conexión de las aplicaciones web; y es un problema de AJAX, justamente porque AJAX nos "esconde" esa necesidad, nos "engaña" haciéndonos creer que tenemos todos los datos, y puede hacer que los desarrolladores olviden que realmente las cosas no son tan mágicas como parece. Muchos sabéis que trabajo en ámbitos hospitalarios. Os voy a poner un ejemplo dentro de este mundillo:

En nuestro hospital hay muchas aplicaciones, entre las que como comprenderéis hay algunas bastante críticas. Una de ellas es la de mi amigo Ricardo, la de hemodinámica. Esta aplicación es utilizada por los hemodinamistas para controlar a los pacientes que tratan. Así, cuando un paciente por ejemplo va a ser operado, para que le hagan un cateterismo por ejemplo, quizás por que haya sufrido algún infarto, los hemodinamistas lo que harán será antes de nada abrir la ficha del paciente y comprobar todos los datos: si ha tenido lesiones en las arterias anteriormente, si se le han prácticado más cateterismos, comprobarán los diferentes parámetros (creedme hay muchísimos) de otras intervenciones realizadas sobre este paciente, etc. Si todo está correcto, el paciente entra en la sala y se procede a realizar la intervencion.

Ahora bien. Imaginaros que los hemodinamistas están ya operando al paciente, y que de repente el responsable de la operación ve un problema y necesita corroborar algunos datos. Entonces, ordenará a alguno de los asistentes que vaya al ordenador a localizar los datos que necesita. El asistente se acerca al ordenador, y recorre las diferentes solapas de la aplicación recolectando los datos sensibles. Una vez los va leyendo, se los va comentando al hemodinamista jefe, y la operación continua. Si hay suerte, el paciente saldrá adelante, y habrá un nuevo éxito.

Pénsemos en lo que podría pasar con un aplicación web con AJAX. Desde el punto de vista del usuario, aparentemente todo es lo mismo. A fin de cuentas, es lo que promete AJAX, mejores componentes gráficos y transparencia en el acceso a datos. Sin embargo, la realidad es otra. En este caso, la aplicación necesita estar conectada continuamente a un servidor. ¿Qué sucede si en el momento en el que se necesitan los datos se cae la red?, ¿y si se cae la base de datos?, ¿y si se estropea el cable de red?, ¿y si se cae el servidor de aplicaciones?, ¿y si algún técnico de sistemas se equivoca y desconecta un switch? ¿y si...? En fin, yo creo que se os pueden ocurrir decenas y decenas de posibles problemas que ya hemos vivido. En el caso anterior, no podría pasar nada de esto, porque los cientos y cientos de datos ya están precargados, y los hemodinamistas los tienen a su disposición. Sí, es cierto que pueden pasar otras cosas, pero por lo menos hemos minimizado enormemente el riesgo.

Ese es el peligro que yo le veo a AJAX y que nadie comenta. Todo es muy bonito, todo es muy fantástico, todo es muy drag and drop y muy desplegable, pero por debajo todo sigue igual, y conviene no olvidarlo, y si no, poneros en el pellejo de la persona del caso anterior.

En ámbitos hospitalarios este tipo de casos pasan mucho. Y en otro tipo de ámbitos también. Normalmente las aplicaciones que pueden requerir el tratar muchos datos que ya han sido cargados, y permitir el trabajo con ellos, están destinadas al escritorio. Esto es simplemente porque es el mejor lugar para estas aplicaciones. Las aplicaciones web tienen su sitio. Por ejemplo, el sistema de citas de nuestro servicio de salud es un sistema web, cosa que es absolutamente lógica, y que es un ejemplo de un buen lugar para un interfaz de usuario web.

Bueno creo que he soltado un buen rollo, ¿no?. Así que no sigo más. En resumen: señores, cordura y precaución con lo que usamos, lo que escogemos, y para qué lo escogemos. Que no todo es tan bonito como parece, y que no existe la tecnología "única", sino muchas tecnologías que están ahí para que las utilicemos cuando realmente se necesitan.

He subido a mi espacio personal de javahispano la presentación que hice ayer en la TechBusiness Week. Podéis acceder a la misma desde este enlace. No es demasiado técnica, pero espero que os guste.

Pues nada, mañana estaré en la Tech Business Week (antiguo e-gallaecia), hablando sobre el renacer de las aplicaciones de escritorio en Java, sobre APIs no tan conocidas para la creación de aplicaciones de escritorio como puedan ser SWT/JFace/Eclipse Forms, sobre las plataformas de creación de clientes ricos, haciendo hincapié en Eclipse Rich Client Platform, y realizando una pequeña demo con jLibrary.

Además, por allí también estará Jesús Pérez, que hablará sobre metodologías ágiles y su ventaja competitiva.

Bueno, pues nada, que si alguien que lea esto tiene la suerte de estar allí, me encantaría charlar con él. Digo la suerte, por dos cosas: primero porque es un evento caro y no todo el mundo tiene la oportunidad de ir, y segundo porque va gente muy interesante, a todos los niveles, tanto técnicamente como en cuestión de negocios. Este año, destaca especialmente la presencia el sábado de Rudolph Giuliani (sí, no me he equivocado, el ex-alcalde de NUeva York), el Ministro de Industria, Turismo y Comercio, Mark Shuttleworth (mecenas de Ubuntu), Paul Mockapetris (inventor del DNS), y mucho más: Angelika Langer, Piotr Sobolewski, Dino Espósito, Mark Minasi, Marcelo D'Elia Branco, Enrique Dans, Luis Huete, Emilio Ontiveros Baeza, etc...

Vamos, que marea un poco estar ahí. Ya os contaré que tal ha ido todo, y subiré las transparencias.

Hoy he estado curioseando por todos los proyectos de la fundación wikimedia. ¡Qué maravilla de fundación! El caso es que tras recorrer unos cuantos proyectos llegue al diccionario, y me ha llamado poderosísimamente la atención el que el gallego sea uno de los seis lenguajes con más entradas dentro del wickionario.

¿Somos los gallegos los más wikis? Pues va a ser que sí :-)

Vía programando he podido leer un artículo muy interesante sobre la crianza de cerdos. Bueno, no es exactamente sobre este tema, pero os recomiendo a todos su lectura. Lo podéis encontrar en Adictos al Trabajo y su autor es Roberto Canales Mora, fundador de Autentia. La URL del artículo es esta.

El pasado viernes estuve en Alicante, con una gente fenomenal, y en un ambiente prácticamente vacacional. No os podéis imaginar la pena que me dio volver, pasando de ese sol a un clima, ejem... Con deciros que desde Alicante a A Coruña varié 15 gradillos de nada.

El caso es que he subido la presentación. Así que si a alguien le interesa, la podéis descargar aquí. No es ninguna maravilla, ni hay nada que no podáis encontrar en la biliografía, ni por Internet, pero seguro que a alguien le puede interesar.