Balteus

Expo NASA: La aventura del espacio

2012-01-18T08:52:00.001+01:00

Todo lo que una persona puede imaginar, otras podrán hacerlo realidad.

Julio Verne (1828-1905).

La exposición itinerante que la NASA ha traído a Europa está en Madrid desde el pasado Diciembre. Es una visita obligada para curiosos y amantes de la astronáutica y una ocasión excepcional para poder contemplar instrumentos, maquinaria y réplicas de la tecnología actual y la que llevó al hombre a la luna hace casi 43 años.

Pensaba ir a verla de todos modos, pero he tenido la suerte poder de ahorrarme los 16€ de la entrada entrada por ser uno de los ganadores del concurso promovido por amazings.es y la organización de la exposición, así que fui a verla el pasado domingo.

Yuri Gagarin afirmó en una ocasión que su decisión hacia la astronáutica se la debía al excepcional Julio Verne. Y no es para menos. Él es uno de los personajes destacados en la primera sala que nos encontramos en la exposición, la de los soñadores, tras pasar una réplica de la pasarela de acceso a la parte superior del Saturno V y que daba acceso a la nave Apollo.

No voy a detallar aquí el contenido de la exposición, que podéis encontrar en el propio dossier de prensa y en abundante información en la red, sino más bien mi impresión subjetiva y crítica de la misma.

Lo más fascinante de la exposición es poder contemplar in situ y a tamaño real muchas de las cosas que me han fascinado y de las que he visto fotos cientos de veces. Constatas que, hasta que no lo ves con tus propios ojos, no te haces una idea del aspecto y tamaños reales de ciertos artefactos. Por ejemplo, el interior del módulo de ascenso del L.M (Módulo Lunar), tan pequeño, tan frágil... con un aspecto más parecido a un batiscafo que a una nave espacial. Una cosa es que sepas que pilotaban de pie y otra cosa es que lo compruebes con tus propios ojos. Llama la atención especialmente el minúsculo tamaño de ciertas cápsulas espaciales, especialmente la Mercury, que cabría en una furgoneta: meterse ahí dentro sobre un misil Redstone modificado era realmente como estar dentro de la cabeza de un misil balístico. A medida que recorría la exposición reflexionaba sobre el tremendo esfuerzo tecnológico que se realizó en tan pocos años, partiendo totalmente de cero.

Cuando entras en la exposición, te ofrecen unas audioguías (iPod touch) que te presentan varias audiciones/videos por cada sala con información acerca de la misma en una cantidad claramente insuficiente y desproporcionada a las necesidades de información que requieren los objetos expuestos. Y aquí entramos en la parte más inacabada y decepcionante de la exposición: la información. Los objetos expuestos tienen unas etiquetas numéricas que puedes consultar en unos pequeños paneles (sobre los que nos agolpamos los visitantes), cuya brevísima y exigua descripción apenas te satisface y que, por si fuera poco, van apareciendo lentamente en presentación continua (no caben todos en las pantallas) en una desordenada mezcla entre inglés y español. Ya que ofrecen los iPods, la organización podría (por el mismo coste) haber añadido mucha más información multimedia de cada sala e incluso de cada artefacto, evitando así los corros que se forman sobre las pantallitas esperando que aparezca la descripción (que no información) del número que estamos buscando. En definitiva, el problema es que, salvo que sepas lo que estas viendo, me temo que la mayoría de la gente no puede "conocer" lo que está viendo, porque nadie se lo explica.

Por otro lado, los iPod touch cuentan con una excelente pantalla de 3,5 pulgadas que ni siquiera se ha aprovechado para hacer más accesible la exposición a personas con discapacidad auditiva añadiendo subtítulos a los audios y vídeos que ofrece. Vamos, aquí parece que tras todo el esfuerzo, parece que la parte más importante, la de la información, la hubieran dejado a medias. No hacen falta más carteles, ni más grandes. Hubiera bastado con cargar suficiente material en los iPod's. Por otro lado, si en información están suspensos, tienen un cero absoluto en accesibilidad, y no por falta de medios, sino más bien por pura desidia, cosa que me parece totalmente imperdonable, tratándose de una exposición de este calibre.

De hecho, la ausencia de información incluso en temas básicos es tan patente que la organización está constantemente respondiendo en twitter a la pregunta "¿Hasta cuándo está la exposición?", ya que esa información no está disponible ni siquiera en la web oficial. Por cierto: es hasta el 15 de Junio.

Para compensar esta falta de información, recomendaría leer algo sobre la carrera espacial y las misiones de la NASA, ver documentales al respecto, o ver la mini-serie "De la tierra a la luna" antes de ver la exposición, si tenéis ocasión, para poder disfrutar la exposición al completo conociendo lo que se está viendo.

Finalmente, me hubiera gustado llevarme algún recuerdo como alguna serie de maquetas de lanzaderas (titan, atlas, saturno, sts, etc...) oficial. De nuevo, absolutamente decepcionante: apenas algunos carísimos y atroces juguetes de goma, torcidos, que ni siquiera estaban a escala. No había forma de llevarse la famosa serie de lanzaderas o alguna maqueta más o menos decente de un Saturno V o de una lanzadera salvo pequeños pisapapeles metálicos monocolor con poco detalle.

Una excelente exposición mal rematada y poco cuidada en los detalles. En todo caso, una exposición totalmente recomendable por única y excepcional.

Referencias y más información:

2011: 50 años en el espacio, 30 "peceando"

2011-12-18T02:27:00.000+01:00

640K ought to be enough for anybody.

- Bill Gates, 1981 (*)

Una cosa es segura: en tecnología no se deberían realizar aseveraciones del tipo "nunca jamás" porque más tarde o más temprano, el tozudo paso del tiempo te acabará poniendo en el ridículo más espantoso.

Hace 30 años, se lanzó el IBM PC, predecesor de los actuales ordenadores personales que hay en la mayoría de las casas y oficinas. Curioso nombre el que le pusieron, ya que difícilmente se podría llamar "personal" a algo científico que podía costar hasta casi $20.000, aunque mira tú, ironías del destino, sus equipos sucesores si han acabado siendo "personales".

Con respecto a los temas de tecnología que vertebran este blog, de este año destacaría otro suceso trascendental aparte de la curiosa efeméride anterior: un fallecimiento. Este año nos dejó una de las personas que más relevancia tiene en prácticamente toda la tecnología que uso diariamente en mi profesión y de la que deriva la esencia de casi todo lo que usamos: Dennis MacAlistair Ritchie, más conocido como Dennis Ritchie, o simplemente dmr (muchas veces escrito así, "dmr", en minúsculas, con un tremendo respeto, y con la solemnidad con la que uno escribe la más valiosa contraseña). El azar ha querido que el año de su muerte sea también el 40 aniversario de la publicación del primer manual de UNIX "UNIX Programmer’s Manual" que él escribió conjuntamente con Ken Thomson.

Poco puedo añadir yo a lo muchísimo publicado sobre quién fue dmr. La mayor parte de los que visitáis el blog con asiduidad, conocéis su enorme y extensísima contribución al mundo. Tan enorme, como igual de decepcionante la poca repercusión que la noticia ha tenido en la prensa no especializada, que sin embargo ha dado extensa cobertura a otro lamentable fallecimiento contemporáneo, de un personaje más público y notorio, más cool, aunque su legado no pueda ser comparable en absoluto ni por transcendencia ni por importancia. El tiempo pondrá a cada uno en su sitio.

La significación en el mundo de la tecnología de dmr es comparable a la de Marie Curie a la física nuclear o la de Ramón y Cajal a la neurología... y aún así, hay una diferencia extrema: mientras éstos "descubrieron", dmr creó. dmr puso las dos semillas de los llamados entonces Sistemas Abiertos con la creación de UNIX y C. De la misma forma que no podríamos hablar del ADN sin la adenina, guanina, y citosina, tampoco podríamos hablar de Windows, Linux, Mac OS X, Java, Ruby, PHP, o .NET sin C, ya que C ha sido y sigue siendo la base de la creación tecnológica a partir de la cual se han construido tecnologías más complejas.

Por otro lado, Internet (correo electrónico, facebook, Google, twitter, etc), Android, Mac OS X, iPhone y su iOS, Linux... todos tienen en común su procedencia y su esencia, su corazón: el UNIX que creó dmr. Actualmente, desde los Sistemas Operativos de los más grandes e importantes Data Centers y de los equipos financieros del mundo, hasta los smartphones más pequeños siguen usando algún tipo de UNIX o una derivación de éste. Sobre UNIX y C está construido el mundo tecnológico que conocemos. Este es el enorme legado de dmr.

Transborador y Estación Espacial Internacional juntas
Fuente:NASA

En otro orden de cosas, de interés también de este blog, damos repaso al año en lo que a temas de astronomía se refiere: 30 años después del primer vuelo orbital de un transbordador espacial (el Columbia), este año se ha puesto fin al programa de transbordadores espaciales, es decir, al programa STS. La sobrecogedora foto a la izquierda, es muy especial. Por lo general se toman fotografías de la Estación Espacial Internacional (ISS) desde el transbordador, o viceversa, pero no es frecuente que una tercera nave esté acercándose mientras las dos anteriores están unidas. Esta imponente imagen, tomada desde una nave Soyuz TMA-20, donde se aprecia el enorme tamaño de la Estación Espacial Internacional, es una preciosa foto que no se podrá volver a tomar nunca más.

Coincide este hecho con la celebración del 50 aniversario del primer vuelo espacial, realizado por Yuri Alexéievich Gagarin, ciudadano soviético, a bordo de la nave Vostok 1. En honor a su viaje y su transcendencia, la ONU decidió declarar el 12 de Abril como "Dia del Espacio". Esa misma noche se celebra la "noche de Yuri". Curiosamente, el día del primer vuelo de un transbordador orbital (Columbia) fue también el 12 de Abril.

Carl Sagan

También el 20 de diciembre de este año se cumplen 15 años sin el divulgador científico más grande de todos los tiempos. El "astrónomo del pueblo" que ilusionó a todas las mentes inquietas a través de una narración elocuente, precisa, seductora y poética en "Cosmos: un viaje personal": Carl Sagan.

Termino con un comienzo esperanzador, una emocionante nueva misión con el robot de exploración espacial más sofisticado lanzado hasta ahora: el Curiosity. Os dejo con una animación de su viaje, su espectacular aterrizaje y operaciones de superficie (ponedlo a pantalla completa en HD porque merece la pena).

¡ Feliz nuevo año 2012 !

(*) La frase ha sido atribuida frecuentemente a Bill Gates, aunque él ha negado decir tal cosa y existe discusión al respecto ya que no parecen existir evidencias firmes.

Referencias y más información:

Copiar y pegar en applets Java

2011-12-14T02:01:00.000+01:00

Una de las páginas a las que suelo acceder a menudo es ésta. Se trata de una sencilla página contenedora de un applet para probar expresiones regulares en Java realizada por David Matuszek.

Esta página contiene una de ésas maravillosas utilidades tipo que acaban siendo atemporales (yo diría que hace más de 7 años que lo uso): sencilla, directa, concisa y eficaz. La verdad es que para probar una expresión regular antes de incorporarla en el código no se necesita más de eso... ni menos tampoco, ya que esto permite ahorrar mucho tiempo de depuración. Una pequeña joya muy recomendable.

De un tiempo a esta parte, me di cuenta que ya no podía copiar las expresiones realizadas ni pegar texto de ejemplo. Esto me resultaba tremendamente molesto, pero siempre que usaba la página tenía tanta prisa por resolver el problema que me llevaba a ella que no me permitía detenerme un momento para averiguar la razón del incómodo cambio.

Bueno, pues resulta que desde el lanzamiento de Java Plug-in 1.6.0_24 en Febrero 2011, copiar y pegar desde o hacia el portapapeles del sistema se consideró un agujero de seguridad y, por tanto, se desactivó. Puedes copiar entre applets, pero no entre applet y portapapeles del sistema.

La solución estaría en modificar el fichero java.policy del directorio lib/security del plugin, aunque lo más probable es que este cambio sea sobreescrito de nuevo en la siguiente actualización de la JRE. Así que lo mejor es crear un archivo de usuario java.policy personalizado:

Localiza tu fichero Java Security Policy. Se llama java.policy y debería estar bajo el directoro lib/security de tu instalación Java JRE. En Linux está en /usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/security/java.policy.
Copialo a tu home y renómbralo a .java.policy (fíjate que debe comenzar con un punto).
Edita el fichero y añade la línea que se indica debajo de los comentarios:

// "standard" properties that can be read by anyone
permission java.awt.AWTPermission "accessClipboard";

Reinicia el navegador

Referencias y más información:

Regular Expression Test Applet

Los niveles de aislamiento en PostgreSQL (no son 4)

2011-11-12T16:30:00.000+01:00

"No. No lo intentes. Hazlo, o no lo hagas, pero no lo intentes."

- Maestro Yoda

Cuando ví el Episodio IV de la Guerra de las Galaxias ("El Imperio Contraataca"), aún era un niño impresionable, y me llamó la atención la reprenda que hizo Yoda a Luke y que cito aquí. Era uno de ésos consejos marciales que se enuncian solemnes como un consejo vital.

Con el tiempo te das cuenta que como consejo está bien, y puede ser incluso un buen objetivo... pero en ciertas facetas de la vida no es válido. Por ejemplo, en el mundo científico y en nuestro mundo profesional el consejo es justamente el contrario: inténtalo, pruébalo y compruébalo. Y sólo cuando lo hayas hecho y consigas un resultado repetible, ponlo en práctica, esto es, súbelo a producción.

Gracias a no seguir el consejo de Yoda fui consciente de una (grave) carencia de PostgreSQL con respecto a los niveles de aislamiento. Como ya hice una introducción al aislamiento en otro artículo, no voy a extenderme más en el tema y voy al grano. El caso que me ocupaba es que tenía que hacer una importación transaccional de datos masiva en un sistema en OLTP de producción en el que se están modificando constantemente datos relacionados con los que voy a importar. El resultado de la importación es que la transacción gigante bloquea datos e impide que se efectúen modificaciones en datos relacionados paralizando en la práctica buena parte de las operaciones de producción produciéndose un efecto "bola de nieve" al sumarse cada vez más transacciones en cola a la transacción gigante pendiente. Sin embargo, para lo único que quiero la transacción es para tener atomicidad en la operación, es decir, para que no se quede a medias en caso de algún problema, pero no me importa que se puedan producir eventualmente casos de dirty read, que no afectarían a los usuarios del sistema de producción en su trabajo. Vale, no hay problema. La transacción de inserción la podemos realizar con el nivel de aislamiento más bajo (READ_UNCOMMITED) y problema solucionado. ¿No? No obstante, no hagamos caso a Yoda, y probémoslo en pre-producción. Resultado: exactamente el mismo que si no hubiera especificado nada del nivel de aislamiento.

¿Qué ha pasado?

En la documentación de SET TRANSACTION, en efecto compruebo que PostgreSQL admite los cuatro niveles de aislamiento como la mayoría de las bases de datos (de hecho, la sentencia no dio error)... pero sólo sintácticamente: no están todos implementados. Si contiúas leyendo te das cuenta que no son 4, sino 2 los niveles implementados:

"The SQL standard defines two additional levels, READ UNCOMMITTED and REPEATABLE READ. In PostgreSQL READ UNCOMMITTED is treated as READ COMMITTED, while REPEATABLE READ is treated as SERIALIZABLE."

Lo que viene a decir: "¿Pensabas que eran cuatro, no? Pues no. Son dos". De hecho, ahora (con la versión 9.1) ya son 3. Pero sigue sin estar soportada la lectura sucia (dirty read). En la documentación sobre aislamiento también es bastante claro:

"In PostgreSQL, you can request any of the four standard transaction isolation levels. But internally, there are only two distinct isolation levels, which correspond to the levels Read Committed and Serializable. When you select the level Read Uncommitted you really get Read Committed, and when you select Repeatable Read you really get Serializable, so the actual isolation level might be stricter than what you select."

Un verdadero jarro de agua a mis pretensiones, ya que no puedo conseguir atomicidad sin bloqueo (aunque sea realizando lecturas de transacciones no confirmadas) en PostgreSQL, al menos con la versión actual 9.1.

Referencias y más información:

Generar certificados autofirmados con OpenSSL

2011-10-27T23:15:00.000+02:00

Software is like sex: It’s better when it’s free.

Linus Torvalds.

Tengo la suerte de trabajar en un lugar rodeado de extraordinarios profesionales como compañeros. El artículo que traigo aquí hoy es un resumen de un correo electrónico de uno de ellos que, con su permiso (y sugerencia) he convertido humildemente en otro post más para este blog. Gracias, Josete. Es un placer y un honor trabajar contigo.

Mini How-To: Generar certificados autofirmados con OpenSSL para Apache HTTP Server

-por José Morales Mora.

PASO 1. Generar Clave RSA

Ejecutar:

openssl genrsa -des3 -out server.key 1024

Genera una clave CA para realizar la firma del certificado.Nos pide la clave privada para este certificado. Podemos especificar el tamaño de la clave ( 1024, 2048)

PASO 2. Generar CSR ( Petición de Firma de Certificado)

Ejecutar:

openssl req -new -key server.key -out server.csr

Realiza una petición para la firma con clave privada especificado. Al realizarlo nos pide datos:

Country Name (2 letter code) []:
State or Province Name (full name) []:
Locality Name (eg, city) []:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []: 
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

IMPORTANTE: El "Common Name" debe corresponder con la URL que queremos Securizar. Si la URL a poner por SSL es www.paco.es, este campo debe contener exactamente eso.

PASO 3. Eliminar Clave Privada DES3

Ejecutar:

cp server.key server.key.org
openssl rsa -in server.key.org -out server.key

Esto es necesario porque en estos casos que tenemos un certificado firmado con clave primaria, Apache HTTP Server pide en cada arranque esa clave para utilizar el certificado.La solución es eliminar la encriptación DES3 para la clave.

PASO 4 . Generar Certificado Autofirmado.

Ejecutar:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Con este paso obtenemos el CRT autofirmado preparado para ser utilizado en apache.

PASO 5. Configurar Apache

Para utilizar estos certificados en apache, lo que tenemos que hacer es añadir al Virtual Host que queramos:

SSLEngine on
SSLCertificateFile /usr/local/apache/conf/ssl.crt/server.crt
SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/server.key

Referencias y más información:

Combinando XPath con JAXB

2011-10-09T23:57:00.000+02:00

El primer 90% del código ocupa el 90% del tiempo de desarrollo. El 10% restante del código ocupa el otro 90% de tiempo de desarrollo.

Regla del noventa-noventa, Tom Cargill.

Usar JAXB es tremendamente cómodo si tenemos que procesar datos XML bien definidos y cuya estructura sea bastante estable en el tiempo: nos evitamos toda la fontanería de análisis, verificación y marshalling / unmarshalling. Por otro lado, nos resuelve de un plumazo convertir los datos XML a objetos DTO/VO de datos en nuestra aplicación ya que nos permitirá pasarlos directamente a Servicios de negocio o a vista (si usamos un MVC), en lugar de crearlos y mantenerlos manualmente cada vez que se modifican las especificaciones.

Pero no todo son ventajas. A la hora de acceder a un dato de un elemento, tratar con objetos puede suponer un verdadero engorro de iteraciones anidadas o tener que usar predicados para las colecciones de elementos, cuando con XPath podemos realizar un acceso rápido y directo al elemento a través de sencillas expresiones.

Por ejemplo, supongamos que tenemos el siguiente XML:

Si necesitamos acceder a todos los elementos/objetos empleado cuyo elemento cp sea 06002, usando objetos generados por JAXB deberíamos iterar por la colección empleados, así:

List<Empleado> empleados06 = new ArrayList<Empleado>();
for ( Empleado empleado : empleados.getEmpleadoList() ) {
  for ( direccion : empleado.getDirecciones().getDireccionList() ) {
    if ( direccion.getCp().equals("06002") ) {
      empleados06.add(empleado);
    }
  }
}

con XPath es mucho más simple: podemos obtener una lista usando la expresión

//empleado[cp='06002']

Cuanto más niveles jerárquicos tenga nuestro árbol de información (más grados de anidación), más compleja se hace la recuperación de datos usando JAXB. Sin embargo, con XPath es tan simple como evaluar una expresión.

Hasta que descubrí JXPath, tenía que elegir entre XPath (y pagar la "penalización" de realizar el marshalling/unmarshalling manualmente) o JAXB (y pagar la penalización de la selección de elementos con código manual).

JXPath

JXPath es otro genial componente de Apache Commons: una librería que evalúa expresiones (basadas en) XPath contra jerarquías de objetos Java, permitiendo hacer complejas consultas e iteraciones sobre estructuras y conjuntos de simples objetos POJO.

Es decir, te permite usar XPath sobre objetos. Y no sólo sobre objetos serializados vía JAXB, sino cualquier POJO o colección de éstos. Si XPath es al XML lo que el SQL a las bases de datos, JXPath es el equivalente a los objetos Java. Es la solución perfecta para simplificar código que debe evaluar y filtrar conjuntos de objetos o, por ejemplo, cuando debemos seleccionar datos en objetos en tiempo de ejecución, en los que es sencillo construir una expresión XPath dinámica. El artículo "Java Object Querying Using JXPath", muestra una serie de ejemplos muy ilustrativos.

Referencias y más información:

Sincronización de llamadas a Webservices y EJB

2011-09-13T11:36:00.001+02:00

A la vista de suficientes ojos, todos los errores resultan evidentes.

Ley de Linus, formulada por Linus Torvalds, (1997).

Los servidores de aplicaciones y la arquitectura J2EE fue diseñada desde el principio con el multithreading en mente. La idea de escalabilidad y procesamiento paralelo de forma segura ha sido en una constante en su desarrollo y evolución para que los desarrolladores pudiéramos construir aplicaciones seguras sin preocuparnos de asuntos como la gestión de memoria o la sincronización de objetos.

Sin embargo, para las aplicaciones "de la vida real" nos encontramos con que algunas veces tenemos que "serializar" (en el sentido de alinear poniendo en serie, encolar manteniendo un orden y como contraposición al procesamiento paralelo) llamadas o procesamientos concretos... Algo para lo que J2EE no fue pensado desde el principio. Así, en el diseño y construcción de aplicaciones empresariales se suelen dar una serie de necesidades relacionadas entre si que, hasta hace poco, no han tenido solución directa manejada en el estándar JEE:

Serialización o sincronización de procesamiento de peticiones de un webservice. Es decir, poder hacer un WebService como si fuese un Servlet SingleThreadModel (ya obsoleto, por cierto). En definitiva: garantizar que no se atiende otra petición mientras se está atendiendo ya una, evitando la simultaneidad y por tanto evitando también duplicidad de procesamientos realizada por un cliente demasiado impaciente.
Serialización o proceso ordenado de los mensajes de una cola JMS o, lo que es lo mismo, mantenimiento del orden de llegada en el procesamiento de los mensajes. Esto, que podría parecer obvio, no lo es tanto, ya que para un MDB (Message Driven Bean), el contenedor crea un pool de objetos que trabajan en paralelo de forma que si se sacan 2 o 4 mensajes simultáneamente, puede ser que un mensaje más reciente se tarde menos en procesar que un mensaje anterior.
Instanciación de un singleton, patrón en principio no permitido por la especificación J2EE (hasta la reciente EJB 3.1, de la que hablaré más adelante). El patrón singleton es tremendamente necesario para asegurar la instanciación única de motores o manejadores de objetos (conexiones, datos, cachés, clientes, etc) que deben estar perfectamente sincronizados.

El que no haya tenido que solucionar este problema podrá pensar que nada más fácil como especificar al servidor que instancie un pool de tamaño 1 para el EJB/MDB que queramos y, voilà, problema solucionado. La idea es buena. Si aseguramos una y sólo una exclusiva y única instancia de nuestro EJB, podemos resolver las tres necesidades de un sólo plumazo: podríamos publicar dicho EJB como un Webservice, tener un sólo MDB o tener nuestro Singleton.... Por ejemplo, en el caso de Glassfish, podríamos indicarlo en el correspondiente fichero sun-ejb-jar.xml, de la siguiente forma:


    
        
            DataProviderService
            
                1
                1
                1
                0

Pero lamentablemente no es así: no funciona. Al menos en Weblogic, Glassfish y JBoss. Dudo que eso sea posible en ninguno. La razón es sencilla: el contenedor no está diseñado para eso, sino justamente para lo contrario, con lo que conseguiremos un nivel altísimo de reciclado de instancias, pero no conseguiremos mantener la misma instancia de forma permanente sin que la recicle el servidor. Tampoco haciendo variaciones con esos parámetros. Tras un número suficiente de pruebas comprobaremos que el servidor recicla y mantiene, aunque sea durante pocos instantes, varias instancias del mismo EJB.

Las soluciones

En principio hay tres soluciones válidas.

Si estás usando JEE 5 o inferior, es decir, un contenedor EJB 3.0 o inferior, tienes dos soluciones a tu alcance que básicamente pasan por mantener la sincronización fuera del servidor de aplicaciones: crear un JMX MBean o sincronizar por tu cuenta. Si estás usando JEE 6, estás de enhorabuena. Aquí están mis propuestas.

Usar un MBean de JMX
Un MBean es, en definitiva, un singleton accesible vía JMX. No es un objeto manejado por el contenedor de EJB ni un estándar JEE, pero es una solución más elegante que realizar un Singleton por código ya que podemos controlar su ciclo de vida e incluso acceder a su estado de manera remota. Eso si, como decía, la sincronización de los objetos que use (colas JMS, etc) corre por nuestra cuenta. El problema del WebService lo podemos reducir a un problema de JMS, ya que podríamos publicar los mensajes en una cola y extraerlos uno a uno haciendo que nuestro MBean sea un cliente JMS.

Usar un recurso sincronizable
Un mismo EJB puede ejecutarse en diferentes JVM's. El ciclo de vida de los objetos y su concurrencia es cosa del contenedor. Por tanto, declarar un método de un EJB como "synchronized" es una violación de la especificación y no debería ser una opción. Por tanto, nuestros EJB's deberán usar un objeto manejado que pueda ser sincronizado: bien un Singleton propio (si nos basta con sincronizar para una única JVM), bien usando la transacciones serializables de base de datos (si necesitamos sincronizar entre varias JVM's o queremos hacerlo más escalable).

Crear un Singleton Session Bean
Si puedes usar un contenedor JEE 6 compatible, puedes implementar un Singleton Session Bean. Ésta es por fin la solución adecuada dentro del estándar JEE: un singleton manejado con atributos para controlar la sincronización. Con este método se solucionan de un plumazo todas las cuestiones de sincronización o singletons de una forma segura y manejada por parte del contenedor EJB.

Referencias y más información:

Cambiar la URL de conexión y establecer timeout a un Web Service JAX-WS

2011-07-28T14:42:00.003+02:00

En el artículo anterior explicaba cómo realizar un cliente de Web Service JAX-WS con maven. Las herramientas de JAX-WS generan la url de conexión (endpoint) a partir de la url definida en el WSDL. Sin embargo, desplegar nuestro cliente en un entorno de producción final requerirá que realicemos una programación un poco más afinada y parametrizada permitiendo cambiar la url de conexión (típicamente hacia el servicio de producción final) y establecer timeouts.

Establecer los timeouts es extremadamente recomendable para prevenir que nuestra aplicación se quede "pegada" al servicio y eventualmente pueda bloquearse toda nuestra aplicación al quedarnos sin threads libres, ya que los tiempos máximos de espera suelen estar indefinidos por defecto.

Para especificar todo esto no es necesario regenerar el cliente. La práctica habitual es parametrizar los valores de URL, timeout de conexión y timeout de lectura (request timeout) usando algún fichero de configuración o similar, recuperarlos y especificarlos en nuestro proxy cliente.

A continuación dejo un snippet de código típico de ejemplo:

import javax.xml.ws.BindingProvider;
import com.sun.xml.ws.client.BindingProviderProperties;
...
int requestTimeout = 5000;
int connectTimeout = 500;
String nuevaUrl = "http://www.cestel.es/jdialer/dataProvider";

Jdialer jdialer = new Jdialer();
BindingProvider bp = (BindingProvider) jdialer.getDataproviderPort();
bp.getRequestContext().put(BindingProviderProperties.REQUEST_TIMEOUT,
		requestTimeout);
bp.getRequestContext().put(BindingProviderProperties.CONNECT_TIMEOUT,
		connectTimeout);
bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
				nuevaUrl);

JAX-WS Web Services con Maven

2011-06-19T18:50:00.004+02:00

Como decía en "Generación de código JAXB con Maven", una de las ventajas que aporta maven es la capacidad de automatizar tareas repetitivas y reproducibles del proyecto de desarrollo en el propio gestor del ciclo de vida del mismo independizándolo de la herramienta de desarrollo.

Por ejemplo, si necesitamos acceder a un Web Service tenemos que generar los artefactos cliente que permitan "consumirlo" (Service Endpoint Interface -SEI-, clases valor de dependencias, etc...) y cada vez que cambie en algo el servicio tendremos que regenerar nuestros artefactos. Si esta tarea se realiza con un IDE, siempre necesitaremos el mismo IDE para actualizarla y (probablemente) pasar por algún tedioso wizard. Con maven, basta tener nuestros fuentes y el fichero pom.xml para que nuestro proyecto se construya en un momento sin instalar ni configurar nada.

El plugin jaxws-maven-plugin provee los adaptadores para las herramientas wsgen y wsimport de JAXWS a través de los goals jaxws:wsgen y jaxws:wsimport para crear web services y clientes de éstos respectivamente.

Para crear un web service, bastará con indicar el SEI en la sección execution del plugin y las opciones que queramos (en este caso, generar el fichero WSDL. Por ejemplo:


    org.codehaus.mojo
    jaxws-maven-plugin
    1.10
        
            
                1
                
                    wsgen
                
                
                     cestel.jdialer.provider.DataProviderService
                     true

Si queremos crear un cliente para un determinado servicio especificaremos, como habitualmente, el fichero de definición WSDL, el paquete donde queremos que se generen los artefactos y el directorio donde se generarán los ficheros fuente. Por ejemplo:


    org.codehaus.mojo
    jaxws-maven-plugin
    1.10
        
            
                1
                
                    wsimport
                
                
                    
                        ${project.build.directory}/jaxws/wsgen/wsdl/Jdialer.wsdl
                    
                    gesif.sgi.jdialer.dataprovider
                    ${basedir}/src/main/java

Referencias y más información:

Cerrar una sesión de telnet ordenadamente

2011-05-19T00:48:00.003+02:00

telnet towel.blinkenlights.nl

Antes de que el ssh se extendiera como la forma de inicio de sesión remota a servidores UNIX y Linux, era frecuente realizar sesiones de telnet para acceso a una consola del servidor. Actualmente, el uso del telnet se limita prácticamente a realizar sesiones 5250 o 3270 hacia AS/400 o Mainframes o se reduce a realizar meras pruebas de conectividad TCP básicas cuando no tenemos el hping a mano y un tcptraceroute nos resulta teclear demasiado.

Siempre que realizamos un telnet solemos ver un mensaje "Escape character is '^]'." como el siguiente:

zarza@szarza:~$ telnet ftp.es.debian.org 80
Trying 82.194.78.250...
Connected to ftp.es.debian.org.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
szarza@szarza:~$

Hasta ahora, nunca había sabido cancelar las conexiones de telnet que se quedaban pegadas, así que acababa matando la sesión cerrando el proceso padre del telnet (konsole, xterm, cmd.exe, etc) porque no me había preocupado de saber cómo obtener y enviar la famosa secuencia "^]". Sin embargo, es bastante sencillo: se trata de la combinación CTRL+ALT GR+], lo cual es lógico: "^" significa CTRL y el carácter ] se obtiene pulsando la tecla "Alt Gr"+]. Una vez en el prompt del telnet, podemos poner "quit" para salir.

Por otro lado, este artículo me ha servido para comprobar que sigue estando disponible la película Star Wars Episode IV en ASCII vía telnet haciendo "telnet towel.blinkenlights.nl" gracias a Simon Jansen.

Solar System Scope: el sistema solar a tu alcance

2011-05-07T21:04:00.005+02:00

Lo maravilloso de aprender algo, es que nadie puede arrebatárnoslo.
-- B. B, King.

Hace casi dos años, escribí un artículo sobre Sideralis, un planetario para móviles gratuito muy práctico. Desde entonces hasta ahora los móviles han cambiado mucho y han aparecido productos software espectaculares para astronomía en todas las plataformas. Por ejemplo, he tenido la ocasión de ver GoSkyWatch funcionando en un iPhone 4 y es realmente impresionante.

Pero lo que hoy traigo aquí es igualmente impresionante, y no hace falta ni tener un iPhone ni siquiera instalarse nada, tan sólo un navegador y curiosidad.
Solar System Scope es un simulador interactivo 3D del sistema solar online realmente espectacular. A diferencia de otros simuladores 2D estáticos (como el de la NASA) o dinámicos (como el de Gunn Interactive), éste permite movernos a través del sistema solar con total libertad de navegación e incluso de representación, ya que nos permite cambiar la escala del sistema (tanto en distancia como en tamaño de los objetos).

No sólo es un buen simulador del sistema solar: es el mejor que he visto. Sus posibilidades de interacción lo hacen tan entretenido, que te puedes pasar un buen rato jugando con múltiples ángulos de observación (desde cada planeta haciendo doble clic) y observando las posiciones y movimientos a través de una representación desproporcionada para que nos quepan todos los planetas en pantalla.

Como elemento didáctico para los niños, es verdaderamente genial, porque se puede jugar con la escala para enseñarles (al poner el sistema en escala real) las enormes distancias del sistema, cómo Urano gira tumbado con sus anillos prácticamente en vertical con respecto al plano orbital, mostrar las fases de la luna y por qué vemos siempre su misma cara, que no sólo Saturno tiene anillos o el extraño amanecer de Venus por el Oeste.

Aunque aún le faltan funcionalidades por terminar (como la localización de estrellas o planetas), puedes comprobar que tiene una interfaz muy sencilla que te hará pasar un rato ameno y entretenido aprendiendo o visualizando aquello que aprendimos hace años. Prúebalo y me cuentas.

Referencias y más información:

PowerDesigner free alternatives... or something close (for PostgreSQL minimum)

2011-04-17T00:39:00.001+02:00

Herramientas de modelado de datos gratuitas (para PostgreSQL)

Las herramientas de modelado de datos son muy útiles a la hora de realizar un diseño de datos nuevo o acercarnos a la comprensión y estudio de un modelo existente (en aquellas con características de ingeniería inversa). La capacidad de realizar un diseño de modelo visualizándolo de forma gráfica, a través de los Diagramas E-R, o de obtener un diagrama y documentación de una base de datos existente aumenta enormemente la eficiencia de nuestro trabajo reduciendo drásticamente el tiempo necesario con respecto a una realización manual de dichas tareas de diseño, análisis y estudio.

La mejor y más completa herramienta de modelado que conozco es PowerDesigner^©. No es objeto de este artículo describir la enorme cantidad de características que tiene, ni lo perfectamente resuelto que están en ella las tareas de modelado e ingeniería directa e inversa, pero te aseguro que es casi perfecta, contemplando todo el ciclo de modelado (lógico y físico, con multitud de bases de datos) de datos, además de otras tareas de modelado como el de objetos (con generación de código), esquemas xml, etc...

PowerDesigner tiene, empero, un (grave) inconveniente: sólo está disponible para Windows, y en Sybase/SAP no se han preocupado (al contrario que otras compañías, como por ejemplo Spotify) de que pueda ejecutarse con Wine perfectamente.

Vale. Así que tenemos Linux (por ejemplo) y no podemos ejecutar PowerDesigner pero necesitamos una herramienta que nos ayude en nuestro trabajo. ¿Qué alternativas hay?. He buscado en internet "herramientas de modelado de datos", "data modelling tools", "PowerDesigner alternatives"... con resultados decepcionantes: apenas listas de herramientas poco comentadas o algún comentario en foros... Así que me puse manos a la obra a buscar por mi cuenta y compartirlo con la comunidad.

Lo primero que hay que tener en cuenta es que no existe ninguna herramienta gratuita alternativa comparable a PowerDesigner, ni por calidad ni cantidad de características. Pero existen herramientas bastante decentes (para ser gratuitas) que nos pueden servir para la mayor parte de nuestras necesidades. De hecho, hay una lista publicada con una cantidad enorme de herramientas diferentes de modelado que me llevaría muchos días probar. Así que, como en otras ocasiones, fijé una serie de características y condicionantes necesarios para mi, con lo que el número de herramientas candidatas se redujo considerablemente. Mi lista de características y condiciones ha sido la siguiente:

Debe estar disponible para Linux, como mínimo.
Debe tener características de modelado de datos (no basta con una herramienta de diagramas o que sea sólo para UML)
Debe tener características de ingeniería directa e inversa.
Debe soportar (para la ingeniería directa e inversa) como mínimo, PostgreSQL. Adicionalmente se valorará otras bases de datos como MySQL, Oracle, SQL Server, DB2, Derby, etc...
Debe tener características de documentación: generar diagramas E-R, y documentación de la base de datos.
Por supuesto, debe ser gratuita y, preferentemente, libre.

A continuación, os detallo las herramientas analizadas

Open System Architect 4.0.0

Es Open Source. Frecuencia de actualización: desconocida.
De todas las herramientas, analizadas es la que más se parece (dicho esto con todas las cautelas y salvando mucho, mucho las diferencias) a PowerDesigner, y es la que más características y posibilidades incorpora. Por ejemplo, es la única de las analizadas que integra el modelado lógico. Tiene la mejor organización de proyectos y menús y es rápida. Me han gustado muchos aspectos que aparentemente la podrían convertir en la más completa...sin embargo, también es la que más me ha decepcionado en el resultado final. El acceso a las bases de datos es vía ODBC (es la única de las analizadas que no está hecha en Java), lo cual me ha resultado un poco arcaico y engorroso de configurar, aunque al final ese no ha sido el inconveniente, sino la falta de acabados finales que hacían perder la lucidez de las funcionalidades:

Diagramas

los diagramas generados son feos (si bien este inconveniente es generalizado en todas las herramientas analizadas)
faltan opciones de presentación gráficas, de reordenado y de diseño de las tablas y sus relaciones

Ingeniería inversa:

La importación de tablas no es cómoda y no se sabe muy bien de qué esquemas estás importando. No puedes agregar tablas referenciadas relacionadas (hijas) o que la relacionen (padres) automáticamente.

Documentación:

No encontré las características de documentación mínimas que buscaba.

En definitiva, debería ser la mejor... pero al final no me ha gustado. Es como si te montas en un Mercedes, que hace ruido, no tiene aire acondicionado y la dirección y el cambio son muy duros. No me ha resultado cómoda y no la voy a usar. Estaré atento a futuras versiones si es que se producen.

SQL Power Architect 1.0.6

Aunque es un producto comercial, la versión community es Open Source y gratuíta.Frecuencia de actualización: alta.

La versión community gratuita es suficiente para un trabajo de modelado básico. Soporta ingeniería directa e inversa de forma cómoda (se pueden agregar fácilmente las tablas hijas) con bastantes opciones gráficas de presentación. Es rápido, amigable y con él se puede generar una documentación mínima decente. De todos los analizados es el que menos opciones de modelado y documentación tiene, aunque cumple su cometido muy dignamente.

SQuirreL SQL 3.2.1

Open Source. Alta actualización. Esta herramienta es en realidad un cliente SQL multi-bases-de-datos (bastante bueno, la verdad) con capacidades de modelado e ingeniería directa e inversa.

SQuirrel no destaca por sus capacidades gráficas de diagramas E-R. La organización de las tablas en una importación vía ingeniería inversa deja bastante que desear (como se puede observar) aunque salvando el detalle de tener que organizar y posicionar las tablas a mano, tenemos suficientes opciones para añadir tablas referenciadas o elegir la presentación de las tablas. Sin embargo, como he comentado, SQuirrel es un cliente multipropósito y multibase bastante completo, con muchos plugins y potentes editores de datos, SQL, DML y esquemas. Este es probablemente el más completo multi-propósito de todos los analizados.

Druid III (3.11)

Open Source. Frecuencia actualización: Alta

Druid es fundamentalmente una herramienta pensada para crear bases de datos de forma gráfica y documentarlas. Su capacidad de documentación de bases de datos supera a todas las del análisis: es capaz de generar documentación tipo javadoc de una base de datos con los diagramas E-R y sus tablas de forma detallada, como se puede comprobar en la siguiente ilustración.

La interfaz es un poco "extraña" (por llamarla de alguna manera) y muy poco intuitiva (probablemente la peor interfaz de todas). Sin embargo, si quieres documentar una base de datos, ésta es tu heramienta. Permite documentar una base de datos existente vía ingeniería inversa, realizando diagramas temáticos y realizando documentación adicional, de forma muy sencilla, añadiendo tablas relacionadas, y presentando la información que deseemos. En todo caso, a pesar de que le faltan opciones gráficas de zooming y layout y de tener una interfaz difícil, para documentar una base de datos vía ingeniería inversa, es la que más me ha gustado.

Resumen:

Todos tienen carencias en la presentación de los diagramas E-R: faltan opciones de "layout" y los diagramas son poco vistosos.
Todos son multiplataforma (todos salvo Open Systems Architect están hechos en Java).
Todas las herramientas son válidas. Y deberías probarlas todas. Ahora bien, cada una tiene un punto fuerte

Documentación: Druid
Algo para empezar, sencillo: SQL Power Architect.
Cliente completo, todo en uno: SQuirrel
OSA no me ha gustado, a pesar de ser la única que incorpora modelado lógico de forma explícita.

Todo esto, como siempre, es cuestión de gustos y de necesidades concretas. Así que, como en otras ocasiones, recomiendo probar y sacar conclusiones... y si las compartes conmigo comentando, te lo agradezco.

¿Conoces alguna otra herramienta que cumpla las condiciones iniciales?

Referencias y más información:

java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to java.lang.String

2011-03-21T00:01:00.002+01:00

Ver lo que tenemos delante de nuestras narices requiere una lucha constante.
-- George Orwell (1903-1950) Escritor británico.

Un error en tiempo de ejecución como éste: java.lang.ClassCastException: [LFQN_ClassName; cannot be cast to FQN_ClassName, puede dejarte con cara de perplejidad durante algunos minutos. A mi me pasó. Y reconozco cierta vergüenza al admitir que fueron unos cuantos largos minutos en los que no daba crédito. Estaba tan concentrado en que el casting era correcto que no podía entender cómo la JVM me decía que no podía adaptar un tipo de dato a otro exactamente igual... Al cabo de unos minutos me di cuenta que la clave está en el corchete ("["). No se trata del mismo tipo: la máquina virtual me está diciendo que no puede convertir un array de ese tipo a ese mismo tipo (directo).

En efecto, el capítulo 4.3 de la especificación de la máquina virtual referente al fichero class, lo explica bien claro: estamos intentando convertir una instancia de String[] a String. En fin, es de estas veces que tienes la solución delante pero no la estás buscando: estás en otra cosa.... Hay que confiar más en los mensajes de error.

Por cierto que no veo sustituto de ésta url en el dominio oracle.com... así que puede que no esté disponible a partir del 1 de junio. Así es, amigos, uno de los primeros dominios que se registraron y más antiguos, dejará de existir (desaparecerá, en palabras de Oracle).

Referencias y más información:

Class File Format (VM Spec)

Balteus cumple 10 años (en binario)

2011-03-09T21:49:00.004+01:00

(Ilustración: Fran Barquero)

- "¿Le gusta nuestro búho?" -Rachael

- "¿Es artificial?" - Rick Deckard

- "Naturalmente." - Rachael

--Blade Runner.

El pasado domingo 6 de Marzo, este blog cumplió su segundo año de vida. Y he aprovechado la ocasión para hacerle un sutil cambio en el diseño, en la línea del anterior: sobrio y sencillo. Espero que os guste.

Este año me han ocurrido algunas situaciones anecdóticas y relevantes para mi, teniendo en cuenta que soy un escritor de un blog muy especializado y con pocos lectores asiduos. La primera me ocurrió con mi post "La galaxia en un campo de fútbol", en el que comenté el libro de Juan Fernández Macarrón y el propio Juan me dejó un afectuoso comentario (también me pasó en el artículo sobre Logback: también el autor comentó en mi web). La segunda es que enlazaron mi artículo sobre el control del nivel de aislamiento transaccional con JPA en "The Aquarium", el blog de referencia sobre Java EE y Glassfish. Fue una grata sorpresa, la verdad.

Por otro lado, este año he sido menos prolífico que el primero, y no por falta de temas, sino por falta de tiempo. También he encontrado que los lectores habituales son "silenciosos" y no tienen tiempo y/o ganas de comentar mis artículos (en fin, sois así, ¿qué le vamos a hacer?).

También he contado con un regalo-ilustración realizado especialmente para la ocasión. Gracias, Fran, por la ilustración. Me ha hecho mucha ilusión.

A mis lectores frecuentes: gracias por seguir por ahí... y dejad algún comentario, por favor!. Me gusta saber que hay alguien ahí leyendo.

P.D.: Si veis algo que ha quedado "raro" con el cambio de diseño, por favor, decídmelo.

Documentación de código con Doxygen y Maven

2011-02-28T00:36:00.008+01:00

Voluminous documentation is part of the problem, not part of the solution.
-- Tom DeMarco, software development consultant

Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing.
-- Dick Brandon

La documentación de proyectos software siempre ha sido un tema controvertido. Aspectos como la estructura, enfoque, perspectiva, y metodología han generado decenas de tratados y "estándares" (como sinónimo de modelo, patrón o referencia) tan voluminosos como imprácticos e irrealistas. Sin embargo, ya comenté en "La falacia de la Ingeniería del Software" mi poca confianza en la aplicación realista de muchas metodologías y estándares que comparten entre sí la escasez de referencias reales profesionales.

Mi experiencia a la hora de documentar un proyecto para la cesión de administración y mantenimiento a terceros me ha enseñado que la documentación sólo sirve si:

está contínuamente actualizada y sincronizada con lo que documenta (el adverbio continuamente aquí, es clave)
la documentación y lo documentado están mutuamente accesibles
tiene estructura y formato ágil para la consulta

Por supuesto, creo que los aforismos "cuanta más documentación mejor" o "toda documentación que se haga es poca" son del todo erróneos. El objetivo es la calidad, y creo honestamente que la cantidad participa de forma inversamente proporcional en una ecuación de calidad.

En lo que a documentación de código se refiere, los objetivos anteriores se obtienen con creces con sistemas de generación de documentación automatica:

La documentación está junto a lo documentado favoreciendo la contínua actualización
Están mutuamente accesibles
La estructura es la idónea para facilitar el acceso a la documentación precisa fácilmente ya que suelen generar HTML

En este aspecto, la mejor herramienta que he probado hasta ahora es, sin duda y con diferencia, Doxygen.

Doxygen es un generador de documentación gratuito para C++, C, Java, Objective-C, Python, IDL, Fortran, VHDL, PHP, C# y D. Su licencia es GPL y sus resultados son comparables (e incluso mejores en algunos aspectos) a documentadores comerciales.

Los desarrolladores de Java, que ya conocen Javadoc, cuya generación está perfectamente integrada con Maven, se preguntarán para qué diablos necesitarían otro documentador. Como se comenta en la segunda cita introductoria de este artículo, Javadoc está bien: es mejor que nada. Pero comparar Doxygen con Javadoc es equivalente a comparar maven con "make".

Las características más destacables, frente a Javadoc, desde mi punto de vista:

Genera automáticamente diagramas de clase y colaboración. Opcionalmente, diagramas de dependencia, llamada, etc...
Permite incluir el código fuente resaltado en la propia documentación
Formatos: HTML,CHM, PDF, XML, etc..

Doxygen es una utilidad basada en línea de comando, como Javadoc, con más 100 opciones configurables que permiten ajustar la documentación final. Aunque la mayoría de las opciones interesantes ya están configuradas por defecto, Doxygen cuenta con un frontal gŕafico (doxywizard) muy util para gestionar las opciones y los ficheros de configuración. Se instala fácilmente ("sudo apt-get install doxgen-gui", en *ubuntu) existiendo distribuciones en código fuente y binarios para Mac OS y Windows... y, he aquí lo mejor: existe un plugin para maven.

Usando Doxygen con Maven
De la misma forma que podemos automatizar la generación de documentación javadoc en nuestras construcciones con maven, podemos hacerlo con Doxygen. Para ello, tan sólo debemos seguir los siguientes pasos:

Instalar Doxygen y hacerlo disponible en el path (para *ubuntu esto es automático con la instalación)
Añadir el plugin a nuestro pom.xml. A continuación muestro las opciones de configuración que yo suelo usar


    ...
    
        
            
                com.soebes.maven.plugins.dmg
                doxygen-maven-plugin
                1.0.1
            
        
    
    ....
    
        
            
                com.soebes.maven.plugins.dmg
                doxygen-maven-plugin
                1.0.1
                
                    false
                    es.cestel.szarza.balteus
                    1.0
                    spanish
                    true
                    true
                    true
                    true
                    src/main
                    true
                
            
        
    
    ....

Recomiendo probar con las opciones de generación de diagramas. Especialmente los diagramas de colaboración pueden ser muy útiles para ciertos módulos de proyecto.

Referencias y más información:

StatementTimeout / QueryTimeout con PostgreSQL

2011-01-31T11:58:00.004+01:00

Si no esperas lo inesperado no lo reconocerás cuando llegue.
- Heráclito de Efeso (540 AC-470 AC) Filósofo griego

Como comentaba en "las 8 falacias de los sistemas distribuídos", en los entornos de producción debemos tener en cuenta que pueden suceder hechos que no se producen en nuestros entornos de desarrollo, integración o preproducción... y ciertamente ocurren. En estos entornos son necesarios procesos y tareas concurrentes inherentes a su propia naturaleza y ambiente de "explotación" (tareas de mantenimiento tanto programados -backups-, como no programados -recuperaciones de datos-, arranque eventual de otras -nuevas- aplicaciones, procesos de datawarehousing, etc).

Uno de estos sucesos típicos suele ser el inexplicable y aleatorio bloqueo de una sesión o de toda una aplicación entera. Tras el correspondiente susto y examen exhaustivo, detectamos la causa en una consulta de base de datos que, eventualmente, tarda demasiado. En algunas ocasiones las causas son muy poco evidentes y muy difíciles de detectar, ya que sólo se producen por la coincidencia de determinados eventos (periódicos o no), e incluso en un determinado orden.

¿Y por qué tarda tanto una consulta que en nuestro entorno de preproducción se lleva apenas unas pocas decenas de milisegundos? Pues típicamente porque ocurre un bloqueo en la base de datos debido a una transacción de larga duración. Si las cosas se complican, puede existir incluso un deadlock (bloqueo mutuo) que deje nuestro sistema completamente bloqueado y produzca un efecto dominó en otras aplicaciones dependientes de la misma base de datos.

Obviamente, la solución pasa por detectar la casuística concreta y evitarla, pero mientras buscamos la causa o la solución, necesitamos mantener nuestro sistema funcionando con normalidad. Para protegernos a este tipo de eventualidades, se debe establecer un valor de timeout en nuestras consultas y transacciones a bases de datos que impida que una consulta se quede indefinidamente esperando el resultado y, por tanto, todas las sesiones de la aplicación que llegan a ese punto. En los entornos JEE, donde se configuran pools de conexiones a bases de datos que permiten un uso eficiente de recursos y conexiones de bases de datos, la ausencia de estos timeouts en esas condiciones pueden suponer el agotamiento de las conexiones del pool, debido a que no se liberan las conexiones y, por tanto, la imposibilidad de que nuevas sesiones de la aplicación puedan funcionar.

Configuración de Statement Timeout en Glassfish

En la mayoría de los servidores de aplicaciones y contenedores web JEE, existe una forma de indicar este parámetro para cada uno de nuestros pools, permitiendo especificar distintos parámetros en función de las características de las aplicaciones o de la duración de las transacciones. En el caso de Glassfish, por ejemplo, es a través del atributo StatementTimeout del pool (que internamente realiza las llamadas a setQueryTimeout() del driver.

Usando PostgreSQL, este atributo sin embargo nos ha dado una desagradable sorpresa:

Caused by: org.postgresql.util.PSQLException: Method org.postgresql.jdbc4.Jdbc4PreparedStatement.setQueryTimeout(int) is not yet implemented.
        at org.postgresql.Driver.notImplemented(Driver.java:753)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.setQueryTimeout(AbstractJdbc2Statement.java:635)
        at com.sun.gjc.spi.base.ConnectionHolder.prepareStatement(ConnectionHolder.java:477)
        at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.prepareStatement(DatabaseAccessor.java:1162)
        at oracle.toplink.essentials.internal.databaseaccess.DatabaseCall.prepareStatement(DatabaseCall.java:612)
        at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:485)

Pues si, aunque parezca increíble, el driver jdbc de Postgresql no implementa aún setQueryTimeout(), al menos hasta la versión disponible en el momento de escribir este artículo (versión Version 9.0-801 de 2010-09-20).

Establecimiento de propiedades de la conexión en el pool de conexiones de Glassfish

La solución es establecer el parámetro de conexión SocketTimeout, que especifica en segundos el tiempo máximo que se espera respuestas del servidor antes de cerrar la conexión. Este parámetro tiene el mismo efecto que el atributo StatementTimeout / QueryTimeout que comentaba anteriormente.

Para nuestros scripts PL/pgSQL, podemos establecer directamente el parámetro statement_timeout al inicio:

SET statement_timeout TO 5000; -- para 5 segundos

 <...resto del PL>

RESET statement_timeout; -- reset

En general, establecer un valor de timeout en operaciones síncronas es una buena práctica para evitar sorpresas desagradables.

2010: El fin de una etapa

2010-12-27T00:00:00.046+01:00

Este año que ha terminado ha sido extraño y agridulce en lo que a acontecimientos y efemérides se refiere.

En el pasado 2010 se han cumplido 25 años desde que se registró el primer dominio .com (symbolics.com). Aquél año de 1985 se registraron 7 dominios. Hoy hay registrados más de 80 millones.En cuanto a los dominios .es, comenzaron a registrarse en el año 1997 y hoy, dominios.es (anterior ES-NIC) cuenta con más de 1.200.000 dominios registrados.

También ha sido el cumpleaños de Java, ya que según su creador, fue hace 15 años cuando nació Java, si bien la primera versión se publicó en 1996.

Decía Unamuno que el progreso consiste en renovarse. Sea ésa la última causa o sea por causas pecuniarias más prosaicas, el caso es que este año 2010 ha sido el fin de Sun Microsystems, tras la confirmación de compra que se produjo finalmente por estas fechas el año pasado. Esta compra ha producido una preocupante desbandada de personas de esencial relevancia en las filas del antiguo Sun, ahora Oracle. Desde el propio CEO de Sun, Jonathan Schwartz, pasando por Tim Bray (coinventor del XML) hasta incluso el mismísimo James Gosling (creador de Java), la lista no ha cesado: Eduardo Pelegri (lider de la especificacioń Java EE, padre de JSP, y responsable de Glassfish), Simon Phipps (Sun's Chief Open Source Officer), casi todo el equipo de OpenOffice.... ~~Sun~~Oracle ha perdido un enorme valor humano. Se diría que Oracle tiene una filosofía con un enfoque totalmente diferente, en lo que a su postura con el FOSS e innovación se refiere... ejem.

En sus 28 años de vida como empresa independiente (de momento Oracle mantiene la marca) Sun ha sido sinónimo de innovación, seriedad, escalabilidad y grandes sistemas. El procesador SPARC (la primera arquitectura RISC-II implementada comercialmente), el sistema de ficheros NFS, el Sistema Operativo Solaris (con ZFS, en su versión 10), Java (JSE, JEE, y resto de estándares asociados) han sido innovación directa de Sun Microsystems y legado tecnológico sobre el cual se han basado decenas de avances actuales hoy día.

Tras la absorción de Sun por parte de Oracle, el futuro de productos de código abierto como Glassfish, MySQL, Java, etc, es una incógnita, como ya comenté en un anterior artículo. Comienza a partir de aquí una nueva etapa para las tecnologías Java.

Veremos qué nos depara 2011.

¡Feliz año nuevo a todos!

Las 8 falacias de la informática distribuída

2010-12-09T01:10:00.001+01:00

En 1994, Peter Deutsch, uno de los miembros originales de Sun Microsystems, afirmó que arquitectos, diseñadores, y programadores de aplicaciones distribuidas a menudo solían asumir 7 supuestos que, en última instancia, resultaban falsos, poniéndose de manifiesto en forma de fallos del sistema, reducción sustancial en el ámbito de aplicación del sistema, o en grandes gastos imprevistos necesarios para rediseñar el sistema de forma que pueda cumplir con sus objetivos originales. En 1997, James Gosling (creador de Java) añadió un octavo supuesto.

Esas hipótesis son conocidas conjuntamente como Las 8 falacias de la informática distribuída o las 8 falacias de los sistemas distribuídos (8 fallacies of distributed computing):

La red es confiable
La latencia es cero
El ancho de banda es infinito
La red es segura
La topología no cambia
Hay un administrador
El costo del transporte es cero
La red es homogénea

Explicar cada una de las falacias (explicar por qué lo son) es bastante obvio. De hecho, llama la atención la adición de la falacia nº 8 en 1997 cuando realmente la heterogeneidad no era ni la centésima parte de lo que es ahora, con decenas de tipos de redes y dispositivos de distintas características accediendo simultáneamente a los mismos sistemas.

15 años después, las características y problemas subyacentes de los sistemas distribuídos siguen siendo más o menos los mismos. Cualquiera que haya puesto en producción sistemas distribuídos (qué sistema empresarial actual no lo es) ha sufrido la mayoría (si no todas) de estas realidades.

Definitivamente, lo que hay que tener claro es que no es posible proteger un sistema frente a todas estas eventualidades de forma indefinida ni es simplemente una cuestión de tecnología. Preservar a un sistema de las consecuencias de estos hechos ahora (es decir, para un momento concreto en el tiempo) es muy caro, así que se tiene que llegar a un compromiso entre el coste y riesgo que se quiere asumir. Incluso aún cuando se proteja de forma razonablemente un sistema, habremos de tener en cuenta que los sistemas crecen y evolucionan. Si no se presta atención a las cuestiones abarcadas por las falacias, llegará un momento en que la situación haya cambiado de forma sustancial y quede nuevamente expuesto.

Por tanto, estas falacias no solamente deben tenerse en cuenta en las etapas de diseño y construcción de un sistema, sino también (e incluso de forma especial) en la de mantenimiento, porque llegará un momento en que se mostrarán sus consecuencias... y no será tan tarde como imaginamos.

Referencias y más información:

"Run As -> m2 Maven build" no funciona en Eclipse Helios

2010-11-29T16:06:00.000+01:00

Puede que hayas llegado hasta aquí buscando alguna de las siguientes expresiones en un buscador:

No puedo ejecutar Maven en Eclipse Helios
No funciona maven en Eclipse Helios
Maven no hace nada en Eclipse Helios
Unable to start any of the Maven goals from Eclipse Helios
org.eclipse.core.runtime.CoreException: Local configuration cannot be nested in a directory

En efecto, el síntoma es que no se ejecuta "Maven build", "Maven package", "Maven clean" ni ningún otro goal del menú contextual "Run As" de m2e. Tras seleccionar la opción, no sucede nada ni se ve nada por consola. La ventana "Error Log" muestra: org.eclipse.core.runtime.CoreException: Local configuration cannot be nested in a directory.

Es un bug conocido de m2eclipse: https://issues.sonatype.org/browse/MNGECLIPSE-2191

La única solución que he encontrado hasta el momento es crear una configuración específica para cada proyecto y operación que quiero hacer. Estas configuraciones se pueden llamar desde el icono "Run As" de la barra de herramientas (el símbolo "play")

Firefox cumple seis años

2010-11-09T23:48:00.004+01:00

Hoy, 9 de Noviembre, Firefox, el segundo navegador más usado, cumple seis años. Con una importante lista de premios a la espalda, es sin duda el navegador más personalizable que existe, el más seguro, y el menos "contaminado" por intereses comerciales, ya que detrás del mismo está la Fundación Mozilla, una fundación sin ánimo de lucro dedicada al software libre e innovación en internet.

El año que viene, veremos en su próxima versión (nº 4), importantes mejoras. Y además, ya está disponible (en versión beta) una versión para ciertos móviles.

Si no conoces la familia de productos Mozilla, te invito desde aquí a probar alguno de sus productos (todos gratuitos), especialmente Thunderbird con Lightning, la combinación de cliente de correo con calendario mejor que existe, con todas las ventajas de firefox: rapidez, seguridad, personalización (extremo a destacar especialmente)... y por supuesto, también gratis.

Firefox está disponible en más de 70 idiomas para Linux, Mac OS, y Windows.

Referencias y más información:

Control del nivel de aislamiento transaccional en JPA

2010-10-16T13:45:00.003+02:00

La única ventaja de jugar con fuego es que aprende uno a no quemarse.

- Oscar Wilde (1854-1900)

Breve introducción al aislamiento

El aislamiento es una de las propiedades fundamentales ACID que definen las transacciones como tales en sistemas de gestión de bases de datos. El aislamiento define cómo y cuándo se ven los cambios realizados por una determinada operación por otras operaciones concurrentes.

El estándar ANSI/ISO SQL define cuatro niveles de aislamiento transaccional en función de tres hechos problemáticos que deben ser tenidos en cuenta entre transacciones concurrentes. Estos hechos no deseados son:

lectura "sucia": Una transacción lee datos escritos por una transacción no confirmada [1]. Es decir, se leen datos temporales que no existirán finalmente porque la transacción que los creó se canceló finalmente tras la lectura.
lectura no repetible: Una transacción vuelve a leer datos que previamente había leído y encuentra que han sido modificados por una transacción confirmada.
lectura "fantasma": Una transacción vuelve a ejecutar una consulta, devolviendo un conjunto de filas que satisfacen una condición de búsqueda y encuentra que otras filas que satisfacen la condición han sido insertadas o borradas por otra transacción cursada. La inconsistencia ocurre cuando una segunda transacción accede repetidas veces a una fila y lee datos diferentes cada vez.

Como comentaba, los niveles de aislamiento se definen en función de los efectos no deseados que evita. Así, el estándar ANSI/SQL define los siguientes cuatro niveles de aislamiento, de menor aislamiento a mayor:

	lectura sucia (dirty reads)	lectura no repetible / doble actualización (non-repeatable reads / lost-update)	lectura fantasma (phantom reads)
lectura no confirmada READ_UNCOMMITTED
lectura confirmada READ_COMMITTED
Iectura repetible REPEATABLE_READ
secuenciable SERIALIZABLE

Las transacciones tienen aislamiento cuando no interfieren entre sí, especialmente aquellas que aún no han concluído y están incompletas. El nivel de aislamiento es inversamente proporcional al rendimiento final en la medida en que que cuanto mayor es el aislamiento mayores son los recursos del sistema utilizados para garantizarlo. Esto se hace patente con un alto grado de concurrencia: a un nivel de aislamiento mayor, menor rendimiento.

La mayoría de las bases de datos usan un el nivel de aislamiento READ_COMMITED por defecto. Para accesos clásicos a la base de datos usando un patrón DAO y gestionando las conexiones directamente (sin usar JPA) esto es prácticamente lo único que necesitamos, ya que podemos seleccionar un nivel de aislamiento mayor en caso que lo necesitemos en la conexión usando setTransactionIsolation().

Con JPA las cosas son bastante diferentes

Hay que tener en cuenta que las implementaciones de JPA incluyen una caché de objetos que introduce elementos nuevos y desconcertantes frente las aplicaciones clásicas.

Otras aplicaciones acceden a los datos
Nuestra aplicación puede convivir con otras aplicaciones JPA que no usen la misma Unidad o Contexto de Persistencia (otro módulo, otro servidor) o que accedan a los datos directamente sin un framework JPA de por medio. Esto causará lecturas no repetibles, es decir, que ambas aplicaciones sobreescriban los mismos datos simultáneamente. En definitiva, el framework no realiza un refresco automático de un objeto antes de realizar un merge() (si lo hiciese, sería costoso ya que ejecutaría una sentencia SELECT anterior a cualquier otra). El tema del "refresco" de la caché es un tema aparte que merecerá un articulo aparte, en su momento.

Objetos caducados
Incluso aunque todas las aplicaciones usen el mismo contexto de persistencia y la misma caché de objetos, es frecuente que dos threads modifiquen el mismo objeto (incluso aunque sean propiedades diferentes) y realicen una transacción simultánea sobreescribiendo los cambios de otra, con lo que podemos tener que "se pierden" cambios de una propiedad. Por ejemplo:

La transacción A lee la fila x.
La transacción B lee la misma fila x.
La transacción A escribe la fila x.
La transacción B escribe la fila x (y sobreescribe los cambios realizados por A).
Ambos confirman la transacción con éxito.

Este efecto se conoce típicamente como actualización perdida (Lost update). Con un nivel de aislamiento SERIALIZABLE esto no ocurriría, ya que la transacción B se quedaría bloqueada esperando hasta que la transacción A realizara la confirmación (commit) o no esperaría y simplemente fallaría (dependiendo de si se emplea un NO_WAIT en el tipo de lock). Sin embargo, en una aplicación web típica, esto seguiría generando un conflicto aún con un nivel SERIALIZABLE, ya que una aplicación web leería (y presentaría) primero los datos en una transacción y los actualizaría en otra).

Otro casos parecidos a éste y con consecuencias similares son:

un thread borra un objeto (delete()) y otro realiza un persist() sobre él. En ambos casos tendremos información inconsistente: o no se ha borrado, y tenemos dos, o no se ha grabado y no tenemos ninguno.
un objeto tiene relaciones con otros objetos hijos. Las modificaciones en las listas de sus hijos relacionados puede causar igualmente información inconsistente con respecto a los hijos.

Mecanismos de control de concurrencia
Para evitar estos problemas existen los mecanismos de control de concurrencia, que se encargan de mantener el aislamiento transaccional. Existen múltiples métodos de control de concurrencia que se pueden agrupar en tres categorías:

Optimistic. No realiza bloqueos, cancelando la confirmación y revertiendo los cambios (rollback) en caso de que se detecte un conflicto con otras transacciones. Como su propio nombre indica, asume que las transacciones pueden avanzar y realiza las comprobaciones de modificación al final, justo antes de realizar la confirmación de la transacción, asegurándose que los datos no han cambiado desde que se leyeron. Previene "lost updates".
Pessimistic. Se adquieren bloqueos sobre los objetos que se van a editar (típicamente las implementaciones lo realizan meidante sentencias SELECT ... FOR UPDATE). Este enfoque equivale a un nivel de aislamiento SERIALIZABLE.
Semi-optimistic. Es una mezcla de ambos realizando bloqueos sólo en determinadas situaciones.

Mecanismos de control de concurrencia en JPA

Por defecto, las implementaciones (persistence provider) de JPA asumen que la aplicación es responsable de la consistencia de datos y, por tanto, no realizan ningún comportamiento por defecto relativo a bloqueos. Como he comentado, trabajando directamente con la conexión de base de datos, podemos establecer un nivel de aislamiento y controlar la concurrencia, pero en JPA no manejamos directamente la conexión, sino que trabajamos con un gestor de entidades (EntityManager). Entonces, ¿cómo hacemos para gestionar la concurrencia si no podemos establecer un nivel de aislamiento?. Y aunque pudiéramos, ¿como resolvemos los problemas añadidos inherentes a JPA como los objetos caducados?. Vamos a ello.

Optimistic locking
JPA soporta optimistic locking mediante un campo versionado de bloqueo, definido por la anotación @Version. Dicho campo se actualiza automáticamente por la implementación JPA en cada actualización y debe ser conservado tal cual por la aplicación. En el momento de la realización del merge(), si se detecta un bloqueo o cambio, se lanza una excepción OptimisticLockException.

@Entity
public class Debt {
    @Id
    private long id;
    @Version
    private long version;
    //...
}

Bloqueos específicos de lectura y escritura
Algunas veces es deseable bloquear algo que no vas a cambiar. Normalmente se hace cuando vas a realizar un cambio sobre un objeto que se base en el estado de otro, y deseas asegurar que éste último no cambia mientras dura la transacción. JPA soporta bloqueos de lectura y escritura a través del método EntityManager.lock(entity, lockMode). El argumento lockMode puede ser READ o WRITE.

Si una transacción llama a lock(entity,LockModeType.READ) sobre un objeto versionado nos aseguraremos de que no se realizará ninguna lectura sucia ni lectura no repetible. Es decir, se asegura de que el objeto no ha cambiado antes de hacer el commit. En caso contrario, se lanzará una OptimisticLockException. Por ejemplo, en un método evaluamos en una condición un atributo de un
objeto y, en función del valor, realizamos una modificación de otro objeto.

    ut.begin();
    Debt d = em.find(Debt.class,5);
    em.lock(d,LockModeType.READ);
    if ( d.getAmount() < 10 ) 
        throw new MinAmountExceedException();
    ut.commit();

Si una transacción llama a lock(entity,LockModeType.WRITE) nos aseguraremos de que no se realizará ninguna lectura sucia ni lectura no repetible, ni otro objeto está realizando un lock. En caso contrario, se lanzará una OptimisticLockException. El bloqueo WRITE puede usarse también para proporcionar bloqueos a nivel de objeto y sus objetos dependientes, es decir, bloquear (aunque deberíamos decir "detectar") cambios en relaciones, de forma que un cambio en una lista de objetos hijos fuerce el incremento del número de versión del objeto padre.

En definitiva, el bloqueo READ comprueba el optimistic version field (campo de versionado), y el bloqueo WRITE lo comprueba y lo incrementa. Este tipo de bloqueos es justo lo que se obtiene con un nivel de aislamiento serializable pero de forma optimista, es decir, sin riesgos de deadlock o bloqueos abiertos, ya que estamos hablando de comprobaciones" no de bloqueos efectivos como tales.

Pessimistic locking
Pessimistic locking significa adquirir un bloqueo sobre el objeto antes de comenzar a editarlo y equivale a un nivel de aislamiento SERIALIZABLE. Es realmente bloquear, no es una simple comprobación como en el bloqueo optimista. Se implementa típicamente con una sentencia SELECT ... FOR UPDATE. El bloqueo pesimista no está incluido en JPA 1.0, aunque algunas implementaciones sí lo hacen. Si usamos JPA 1.0 (por ejemplo usando la implementación por defecto de Glassfish 2.x), las alternativas para realizar este bloqueo serían las siguientes:

Si se usa Toplink / Toplink Essentials, usar el hint toplink.pessimistic-lock en la consulta.
Si se usa Eclipse link (versión < 1.2), usar el hint eclipselink.pessimistic-lock en la consulta (o también ver http://wiki.eclipse.org/EclipseLink/Examples/JPA/PessimisticLocking)
Usar JPA 2.0 (por ejemplo EclipseLink), que sí incluye este tipo de bloqueo, como mostraré más adelante.
Usar consultas nativas (native queries) SELECT ... FOR UPDATE.

Por ejemplo:

@Entity
@Table(name="mailing_package")
@NamedQueries( {
    @NamedQuery(name = "MailingPackage.findByIdLocked",
        query = "SELECT s FROM MailingPackage s WHERE s.id = :id",
        hints={ @QueryHint(name = "toplink.pessimistic-lock", value = "LockNoWait")} })
public class MailingPackage implements Serializable {
...
}

El bloqueo pesimista hay que manejarlo con cuidado porque puede causar problemas de concurrencia, rendimiento o bloqueos de la aplicación por deadlocks. Típicamente no es deseable para aplicaciones web interactivas, ya que requiere mantener la transacción (y por tanto la conexión) activa durante la edición. El uso típico es cuando se quiere que la edición tendrá éxito en un momento que sabemos que la transacción durará lo menos posible.

Bloqueos en JPA 2.0
JPA 2.0 añade soporte específico para bloqueo pesimista además de otras opciones de bloqueo en el propio API. Un bloqueo se puede adquirir usando adquiere usando el método EntityManager.lock(entity, lockMode), pasando un argumento LockModeType a los nuevos métodos sobrecargados find() y refresh(), o estableciendo un lockMode en una Query ( setLockMode() ) o NamedQuery (lockMode).

JPA 2.0 amplia/redefine los modos de bloqueo de JPA 1.0 en el enum LockModeType:

OPTIMISTIC: Es el READ de JPA 1.0
OPTIMISTIC_FORCE_INCREMENT: Es el WRITE de JPA 1.0
PESSIMISTIC_READ: Bloquea y evita que otra transacción adquiera un bloqueo PESSIMISTIC_WRITE.
PESSIMISTIC_WRITE: Bloquea y evita que otra transacción adquiera bloqueos PESSIMISTIC_READ o PESSIMISTIC_WRITE.
PESSIMISTIC_FORCE_INCREMENT: es una suma de PESSIMISTIC_WRITE y OPTIMISTIC_FORCE_INCREMENT.
NONE: No hay bloqueo ni comprobación. Equivalente a omitir cualquier lockMode.

Adicionalmente, JPA 2.0 añade dos hits estándar que pueden pasarse a qualquier Query o NamedQuery y a qualquier operación find(), lock() o refresh():

"javax.persistence.lock.timeout": Número de milisegundos a esperar la liberación del bloqueo antes de lanzar una PessimisticLockException.
"javax.persistence.lock.scope": Los alcances válidos se definen en PessimisticLockScope (NORMAL or EXTENDED). EXTENDED bloqueará adicionalmente las tablas relacionadas.

Conclusiones

Con el nivel por defecto de la base de datos en READ_COMMITED y usando un bloqueo optimista para detectar lost-updates, sólo necesitaríamos realizar un bloqueo pesimista en muy pocos casos. No obstante, estos casos existen: casos como un objeto que deba tener una numeración "sin huecos" (como el clásico ejemplo de los números de factura) o un repartidor de objetos que no deba dar el mismo objeto a dos threads para su proceso, podría requierir un bloqueo pesimista o secuenciable que impida de dos threads lean simultáneamente el mismo valor y lo incrementen.

Recomiendo echar un vistazo a las referencias al final del artículo para profundizar más en el tema. Aprovecho la ocasión para felicitar aquí a los autores de "Java Persistence", de en.wikibooks.org, que han hecho un trabajo impecable el cual me ha sido de enorme ayuda para comprender el complejo mundo de JPA.

NOTAS:
[1] Creo que la traducción de "commited" como "cursado" o "confirmado" es más correcta en este contexto.

Referencias y más información:

Eclipse Helios e integración con SVN, Maven y Glassfish

2010-09-09T09:17:00.001+02:00

Desde el año 2006, la fundación Eclipse produce a finales de Junio una versión coordinada simultánea de decenas de proyectos de código abierto consolidados en una herramienta de desarrollo conocida comúnmente como Eclipse IDE, de la que se ponen disponibles 12 empaquetados distintos según el propósito de desarrollo, plataforma tecnológica y necesidades del desarrollador. Desde el 23 de Junio de este año está disponible la versión 3.6 denominada Eclipse Helios.

El modo de distribución de Eclipse es análogo al de una distribución de Linux como Ubuntu y, por tanto, con la misma potencia, comodidad y efectividad. Los distintos paquetes son, en definitiva, distintas combinaciones de proyectos con sus dependencias debidamente resueltas contra los repositorios de Eclipse. Las actualizaciones, en línea, también son similares a las que se realizan con Ubuntu, con lo que la integridad de dependencias está asegurada. En definitiva, una buena idea extendida a las herramientas de desarrollo.

La comunidad de Eclipse tiene cientos de plugins, tanto de código abierto como comerciales, no todos hospedados eclipse.org, que pueden ser de interés. El sistema de repositorios de Eclipse, si bien resuelve correctamente dependencias, requiere que añadamos manualmente las url's de las fuentes de software que queremos instalar. Una de las novedades de Eclipse Helios se acerca aún más a la analogía comentada añadiendo al sistema de repositorios de Eclipse una herramienta de alto nivel llamada Eclipse Marketplace Client (MPC). MPC funciona como un almacén de aplicaciones y plugins (app store) centralizado permitiendo la descarga e instalación de forma cómoda, automática e integrada en nuestro Eclipse.

Para trabajar con un proyecto JEE me gusta que mi Eclipse tenga los plugins de integración con Subversion (SVN), Maven y Glassfish (o el servidor de aplicaciones con el que vaya a trabajar). Por alguna razón que desconozco, Helios aún no trae "de serie" la integración con Maven y SVN. Es posible que sea por mantener escrupulosamente la libertad del desarrollador ya que existen varios plugins disponibles, de los cuales, los más conocidos son:

Maven

m2eclipse (m2e), el "oficial" de los chicos de Maven (Sonatype) y que, por cierto, se está trasladando de codehaus.org a eclipse.org
Eclipse IAM, antiguo q4e de los chicos de Apache

subclipse, el "oficial" de los chicos de SVN
subversion, el "oficial" de los chicos de Eclipse

En mi caso, yo instalo "Maven Integration for Eclipse" (m2eclipse), "Subversive - SVN Team provider" para SVN y "Glassfish Java EE Application Server Plugin for Eclipse".

Referencias:

Eclipse Helios
Tabla comparativa entre m2eclipse e IAM, aunque realizada por los chicos de m2eclipse...ejem... ;-)
Guía de instalación de m2eclipse usando MPC
Otra guía de instalación usando MPC, aunque en esta, el autor instala IAM en lugar de m2eclipse

Actualizar el firmware de la BIOS vía USB con linux

2010-07-05T16:34:00.003+02:00

Denme un punto de apoyo y moveré el mundo.

- Arquímedes de Siracusa. (c. 287 a. C. – c. 212 a. C.)

Recientemente tuve que actualizar el firmware de la BIOS de mi placa base y me encontré con la desagradable sorpresa de que las opciones del fabricante eran exclusivamente para Windows y DOS. Para los que usamos linux esto es un grave inconveniente, porque no tenemos ni lo uno ni lo otro, ni mucho menos ganas de adquirir una licencia sólo para esa simpleza. Incluso en el caso que pudiese adquirir una licencia, está el problema de no disponer de disquetera, de la cual carecen todos los equipos recientes.

Afortunadamente, el disgusto no me duró mucho porque el mundo del software libre ofrece muchas y variadas soluciones para esta tarea. Durante la búsqueda de soluciones para este problema me reencontré con algunos viejos proyectos que siguen felizmente muy activos y están actualmente en un estado muy interesante, como FreeDOS (un sistema operativo libre compatible con MS-DOS) y ReactOS (el renacimiento de aquel digno pero malogrado Freewin95)... ufff... uno ya va teniendo una edad...

De todas las soluciones posibles, traigo a este artículo la que más me gustó y me pareció más sencilla y sólida: UNetbootin.

UNetbootin te permite crear unidades de arranque USB de forma automática y transparente de numerosas distribuciones de Linux, utilidades diversas (reparación, recuperación, bootloaders, etc) y FreeDOS.

Adicionalmente, es capaz de crear un disco de arranque a partir de cualquier imagen ISO (o disquete) de arranque, kernel o ficheros intrd, que queramos, con lo que las posibilidades se multiplican.

El software están disponible también, a su vez, en los repositorios y/o paquetes de para las distribuciones de Linux más conocidas, y también para Windows. Por supuesto, como software libre que es, está disponible el código para cualquier otro caso raro no contemplado.

En el caso que nos ocupa, en apenas unos minutos pude descargar del repositorio el software (sudo apt-get install unetbootin) crear una unidad de arranque en un lápiz USB con FreeDOS y ejecutar la utilidad DOS para actualizar la flash de la BIOS de mi sistema. Todo con software libre (¡y gratuito!).

Referencias:

XML con PostgreSQL

2010-06-24T18:01:00.016+02:00

En el artículo Alternativas EAV con XML expliqué cómo se podía implementar una mejora del modelo Entity Attribute Value (Entidad-Atributo-Valor) usando XML. Este artículo es, en alguna medida, una continuación de aquél, cubriendo ciertos aspectos importantes sobre la consulta a éstos campos o cualquier otro campo que contenga xml. El uso de las características de este artículo requiere que la instalación de postgresql se haya realizado con el soporte xml (configure --with-libxml).

Serialización/deserialización XML de campos varchar
Hay ocasiones en que necesitamos que los campos que contienen XML sean de tipo caracter y no de tipo xml nativo. Una razón para hacer eso, por ejemplo, es que estemos usando un ORM. En algunos casos, pongamos por ejemplo PostgreSQL con Toplink Essentials (incluído de serie en Glassfish 2.1), no hay forma (al menos yo no la he encontrado) de que el ORM haga mapping de campos de tipo xml. Para estos casos, en primer lugar, debemos producir un valor de tipo xml a partir de datos carácter, para lo que podemos usar la función xmlparse o realizar un type cast a xml usando la sintaxis tradicional de PostgreSQL expression::type o bien usando la sintaxis SQL-92 estándar CAST ( expression AS type ), así:

SELECT XMLPARSE( DOCUMENT campo)
FROM tabla
WHERE campo  is not null

<=>

SELECT cast(campo as xml)
FROM tabla
WHERE campo is not null

<=>

SELECT campo::xml
FROM tabla
WHERE campo is not null

Consultas: la función xpath

Para procesar valores de tipo xml, PostgreSQL ofrece la función xpath, que evalúa expresiones XPath 1.0.

xpath(xpath_expr, xml_value[, nsarray])

La función xpath evalúa la expresión XPath xpath_expr contra el valor XML xml_value (debe ser un documento XML bien formado), devolviendo un array de valores XML correspondiente al conjunto de nodos producidos por la expresión XPath. El tercer argumento, opcional, es el array bidimensional de espacios de nombress (nombre espacio de nombres,URI espacio de nombres) que use el documento XML xml_value.

Por ejemplo, dado un campo campo de la tabla tabla, de tipo varchar(2048), podríamos consultar el contenido así (a partir de este momento usaremos la sintaxis del último ejemplo, la tradicional de PostgreSQL, por ser la más sencilla):

Consulta

Resultado

SELECT campo::xml
FROM tabla
where campo is not null

campo
----------------------------------------------------------
<xmlData><data name="incidencia">
<data  value="tiempo"  name="motivo"/></data></xmlData>
<xmlData><data name="incidencia">
<data value="hardware"  name="motivo"/></data></xmlData>
<xmlData><data name="incidencia">
<data value="hardware"  name="motivo"/></data></xmlData>
<xmlData><data name="cantidad" value="2"></xmlData>
<xmlData><data name="cantidad" value="3"></xmlData>

Es importante recordar que la función xpath devuelve un array de valores XML. Por ejemplo, si deseamos consultar sólo el contenido de aquellos valores de elementos data cuyo name es "motivo", por eso la siguiente consulta nos devuelve 4 filas. Es decir, de las cuatro filas en las que campo tiene valores, sólo dos de ellas tiene un elemento data con name igual a 'motivo', pero como xpath devuelve un array de valores, en las los dos últimas filas se devuelve un array vacio.

Consulta	Resultado
SELECT xpath('//data[@name=''motivo'']/@value',campo::xml) as motivos FROM tabla where campo is not null	motivos ---------- {tiempo} {hardware} {} {}

Para evitar lo anterior, podemos hacer:

Consulta

Resultado

SELECT  xpath('//data[@name=''motivo'']/@value',campo::xml) as motivos
FROM tabla
where campo is not null
and  array_upper(xpath('//data[@name=''motivo'']',campo::xml),1) is not null

motivos
------------
{tiempo}
{hardware}

La consulta anterior elimina aquellas filas con array vacío. No obstante, xpath() nos sigue devolviendo un array que tendremos que procesar posteriormente. Para que nos devuelva valores de tipo xml (u no un array) tendremos que tratar la respuesta de xpath como array y pedir el primer elemento del mismo. Así:

Consulta

Resultado

SELECT  (xpath('//data[@name=''motivo'']/@value',campo::xml))[1] as motivos
FROM tabla
where campo is not null
and  array_upper(xpath('//data[@name=''motivo'']',campo::xml),1) is not null

motivos
-----------
tiempo
hardware

Obviamente, podemos usar la función xpath no sólo para seleccionar valores (uso en la select list de la sentencia SELECT) sino también en la cláusula WHERE, para filtrar filas. En este último caso, tendremos que realizar una conversión de tipo para poder realizar ciertas comparaciones (comparación de valores enteros, de fechas, etc...). La conversión a realizar debe ser un poco especial, ya que deberemos convertir de xml a varchar y de éste al tipo deseado. Por ejemplo:

SELECT (xpath('//data[@name=''cantidad'']/@value',campo::xml))[1]::varchar::int4
FROM step
where campo is not null
and array_upper(xpath('//data[@name=''cantidad'']',campo::xml),1) is not null
and (xpath('//data[@name=''cantidad'']/@value',campo::xml))[1]::varchar::int4 > 2

Con lo que conseguiríamos todas aquellas filas con xml que tengan un elemento data con nombre "cantidad" cuyo valor sea superior a 2.

Con esto, podemos usar un modelo más flexible (especialmente para valores de poca densidad) al modelo EAV y con consultas más asequibles.

Referencias:

WSTX-SERVICE-5002: A JTA Transaction MUST NOT exist entering WS-TX Service Pipe procesing for binding... SOLUCIONADO

2010-05-19T23:47:00.005+02:00

JAX-WS representó una revolución en la implementación de SOAP Web Services en JEE. Su aparición en JEE 5 nos permitió publicar como Web Service un Stateless Session EJB automáticamente, de forma declarativa, añadiendo simplemente la anotación @WebService. Sin embargo, bajo determinadas condiciones, nuestro cliente se puede encontrar con un error que, a priori, nos puede resultar desconcertante:

Tras este error suelen producirse otros dos igualmente desconcertantes: "HTTP transport error: java.net.UnknownHostException: host_cliente" o el clásico SSL Handshake "HTTP transport error: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target". Es decir, es como si nuestro servidor estuviese intentando contactar con nuestro cliente por HTTPS. ¿Por qué lo hace?

Una pista: las condiciones en las que se da este error es si el cliente es un EJB. Sólamente en ese caso. Si es un servlet, o una aplicación standalone, funciona perfectamente. ¿Esto te da una idea o aún te confunde más?

La explicación es, en realidad, muy sencilla: los EJB's tienen el atributo de transacción establecido por defecto a REQUIRED (@TransactionAttribute(TransactionAttributeType.REQUIRED)). El código cliente del Web Service lo tiene en cuenta y añade un contexto transaccional al mensaje SOAP. Si EJB "servidor" ha declarado que no necesita transacciones (@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)), ya tenemos el problema servido. La solución en estos casos es también sencilla, debemos indicar a nuestro cliente que no use un contexto transaccional en la petición, anotándolo con @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED), y así el servidor no usará el coordinador WSTX (Web Service Transactions).

La galaxia en un campo de fútbol

2010-04-14T01:40:00.009+02:00

Cuando veas un gigante, examina antes la posición del sol; no vaya a ser la sombra de un pigmeo.

- Novalis (1772-1801) Friedrich von Hardenberg. Poeta y filósofo alemán.

En el artículo Magnitudes astronómicas describía mi fascinación por los enormes tamaños de algunos cuerpos astronómicos. La mejor forma de "entender" realmente cómo eran de grandes era, obviamente, ubicándolos en nuestro mundo cotidiano, es decir, comparándolos con objetos conocidos.
Como prometí en dicho artículo, hoy voy a comentar el libro "La Galaxia en un campo de fútbol".

En mi artículo me limité al tamaño de algunos cuerpos de forma singular. "La Galaxia en un campo de fútbol", en cambio, es una exposición sistemática, pero al mismo tiempo muy amena, en la que se nos plantea un método que nos permite imaginar las distancias astronómicas para comprender (e imaginar también, en definitiva) el universo. Desde nuestro "entorno" más cercano, la tierra y sus satélites (artificiales y naturales), donde las distancias se miden en miles de Km, hasta abarcar la visión global del Universo conocido, donde las distancias se miden en millones de años luz, la obra desarrolla el método de forma muy ilustrativa y con ejemplos, de forma que nos permite por primera vez "imaginar" realmente dichas distancias. Así, los que nos hemos leído el texto, podemos entender realmente noticias como las del pasado 8 de Abril sobre un asteroide que pasó rozando la tierra, comprendiendo realmente las distancias que se indican y realizando cada uno nuestra propia valoración sobre lo "cerca" o "lejos" que está algo según el sistema de referencia y dependiendo con qué distancias comparemos (desde luego, un objeto como el 2009 VA del pasado Noviembre sí que pasó "cerca"... cualquier día de éstos se llevan un satélite geoestacionario por delante).

El libro está escrito pensando en lectores interesados por el tema, pero no presupone conocimiento alguno sobre astronomía, de forma que un lector curioso y lego en la materia podrá disfrutar tanto o más que un aficionado. De hecho, el autor, en un esfuerzo (supongo) por mantener un lenguaje cercano y ameno, dota el libro de un estilo de redacción en la que entabla un diálogo con el lector, consiguiendo un resultado entretenido y accesible aunque quizá de forma desmedida, resultando al final (en mi modesta opinión y por poner alguna pega) un poco pueril e ingenuo (eso de pedir al lector que haga algo y luego felicitarlo por hacerlo me parece un poco excesivo).

Por lo demás, el ejemplar está editado en un tamaño muy cómodo e impreso en un papel excelente, permitiéndonos disfrutar de las maravillosas fotografías astronómicas que incluye.

En definitiva, una obra muy atractiva que volveré a releer y disfrutar para asimilar bien "el método" y continuar "imaginando" el universo. Os la recomiendo.

Referencias:

Generación de código JAXB con Maven

2010-03-25T23:03:00.002+01:00

Si tu intención es describir la verdad, hazlo con sencillez y la elegancia déjasela al sastre.
- Albert Einstein.

Al hilo de lo que comentaba en el artículo "Desarrollo en equipo con SVN, Maven y Nexus", una de las maravillas de usar Maven es que te facilita la reproducibilidad, por ejemplo, de la gestión de la configuración de un proyecto. El caso que voy a exponer es un estupendo ejemplo: la generación de código JAXB a partir de esquemas XML (XSD).

La generación de código JAXB se ha venido haciendo típicamente de dos formas: a través de una herramienta o utilidad (wizard, plugin, etc...) de nuestro IDE, o "manualmente" usando la tarea xjc de ant, o el compilador xjc por línea de comando directamente. Personalmente, nunca me ha gustado usar las herramientas automáticas de los IDE, porque ocultan la configuración del proyecto: los settings que se configuran en un wizard del IDE se acaban perdiendo porque no se suben al repositorio de código o si se hace, atas el proyecto a una herramienta que puede que no uses (tú u otro compañero a quien le toque modificarlo) varios meses después cuando te encuentras con el mantenimiento de un proyecto cuya configuración no es reproducible. Además, esa tarea suele ser repetitiva y necesita ser ejecutada a menudo, especialmente en las fases iniciales donde se va ajustando nuestro esquema XML a los tipos de dato que vamos necesitando, de modo que acabo haciendo "a mano" una tarea ant que realice la generación o un shell script que realice la llamada al compilador xjc con los parámetros que quiero.

Afortunadamente, podemos hacer que Maven realice esta tarea automáticamente como parte de sus labores de construcción, y como tenemos nuestro pom.xml subido a svn, todas nuestras preferencias de generación permanecen autocontenidas en el proyecto: simple, sencillo y sin ataduras a ningún IDE.

Iba a poner aquí los trozos necesarios a incluir en el pom.xml extraído de uno de los módulos del proyecto en el que estoy trabajando pero, la verdad, sería redundante porque está perfectamente explicado en el sitio del plugin JAXB XJC de Maven.

En mi caso, que uso Eclipse con m2eclipse (plugin de maven para eclipse), la integración con Maven es tal, que basta con realizar una modificación el XSD y salvarlo para que se regenere y recompile la clase automáticamente y tenga disponibles los nuevos métodos en mis clases "cliente" de forma instantánea (m2eclipse ejecuta el "generate" de Maven integrado con el propio build de Eclipse).

Otra razón más para continuar recomendando usar Maven.

Referencias:

JAXB XJC Maven 2 Plugin

Balteus cumple un año

2010-03-07T12:09:00.002+01:00

“Yo…he visto cosas que vosotros no creeríais. Naves de guerra ardiendo más allá de Orión. He visto rayos-c resplandecer en la oscuridad, cerca de la puerta de Tanhäuser. Todos esos…momentos se perderán…en el tiempo. Como…lágrimas…en la lluvia. Es hora…de morir”.

--Roy Batty, Blade Runner.

Ya ha pasado un año desde mi primer artículo. Una primera entrada impetuosa que escribí sin presentación, casi por rabia, tras perder demasiado tiempo en un error absurdo, de ésos que te vuelven loco, y de los que sólo te sirven para aprender que debes cuestionarlo todo y no dar nada por sentado. Fue en ese estado de rabia contenida y aliviada, tras solucionar el error, cuando decidí que debía compartir estas experiencias con otros desarrolladores, tal y como hacen miles de compañeros alrededor del mundo, de cuyos trabajos y generosidad me he ido aprovechando durante años, ahorrándome muchas horas y disgustos. Tras ése primer post, escribí realmente la presentación del blog con mis motivos y objetivos.

He querido comenzar este post con la que es, probablemente, la cita más conocida de todos los locos entusiastas del cine de ciencia ficción... Parece una entrada melancólica, pero nada de eso en absoluto: simplemente es un homenaje a Ridley Scott y a la película. Yo creo que no hay desarrollador que no haya dicho o pensado algo así tras una puesta en producción... ¿eh? ;-)

1 año. 25 Entradas. 2 entradas al mes, de media. Menos de lo que me gustaría... pero no encuentro tiempo para mucho más. "La falacia de la Ingeniería del Software" y los artículos de la serie "Banco de experiencias" son probablemente las entradas de las que me siento más satisfecho (aunque, curiosamente, no son las que más interés despiertan). De los datos y números que aporta Google Analytics, destacaría dos cosas:

La gente busca soluciones. Las entradas más consultadas son aquellas en las que comento cómo he solucionado un error o problema. Lo cual es lógico. En mi caso también ha sido así. Muchos de los blogs en los que he aterrizado ha sido vía google, buscando una determinada solución. En definitiva, cuando tenemos un problema, buscamos si a otra persona le ha pasado lo mismo antes de perder más tiempo. Como digo, constato una evidencia que ya suponía.
Realmente el blog tiene visibilidad en todas partes del mundo. Internet hace que todo el mundo sean un montón de ordenadores conectados sin importar localización, idioma o frontera. Parece evidente. Es evidente. Sin embargo, cuando lo confirmas con datos concretos da cierto vértigo. Asumes las lógicas visitas de España y países de habla hispana (al fin y al cabo escribo en español)... pero llaman la atención visitas de Estados Unidos, Alemania, Suiza, Rusia, Brasil, Polonia, India, Finlandia, Corea... ¿Hispanohablantes por el mundo? ¿O simplemente hay gente que busca su respuesta esté en el idioma que esté? (yo lo hago... quizá los angloparlantes, germanoparlantes, etc... también).

En fin, son un par de obviedades con las que todo el mundo cuenta... pero que nunca dejan de sorprender. Al fin y al cabo tenemos una dimensión local y finita... Que lo que escribes pueda ser de interés para alguien tan lejano, impresiona, la verdad.

En todo caso tendré en cuenta estas reflexiones para mis próximas entradas. Es posible que los localismos comentados en "Magnitudes astronómicas" no sean tan claros para gente que no conoce Madrid. Por otro lado, es difícil no hacer referencias al mundo que te rodea. Con respecto a la temática, mi trabajo diario suele darme material de sobra para seguir compartiendo "soluciones" y "experiencias". Así que seguiré en ello.

Gracias a los que visitáis el blog, seáis de donde seáis. Un afectuoso saludo.

Desarrollo en equipo con SVN, Maven y Nexus (parte II)

2010-02-22T20:54:00.008+01:00

Banco de experiencias (V)

En la primera parte de este artículo, enumeraba los problemas de coordinación a los que se enfrenta un equipo de desarrollo diariamente y cómo la utilización de Maven los soluciona de un plumazo por el simple hecho de utilizarlo. Hay un problema sin embargo, inherente al desarrollo en equipo, para el cual se necesita una herramienta más: un gestor de repositorios.

Imaginemos el siguiente escenario de proyecto: un equipo está desarrollando una aplicación empresarial (ear) formada por un par de módulos web, otro par de módulos ejb (ejb-jar), un conector JCA (rar) y tres módulos de librerías comunes (jar).

En un proyecto de éstas características (proyecto con varios módulos) cada desarrollador trabaja en uno o varios módulos (en función de la funcionalidad, de su perfil, habilidades o experiencia...), pero no suele participar en todos... Al menos, eso es lo habitual. Sin embargo necesita tener las actualizaciones y los progresos de todos (o la mayoría) de los módulos, debido a las dependencias entre ellos. Estas dependencias inter-proyecto o inter-módulo son las que denominé como dependencias internas en la primera parte de este artículo. Pero ¿ćomo estar actualizados y poder tener las nuevas funcionalidades y servicios que han desarrollado nuestros compañeros para poderlos usar en los módulos que estamos desarrollando? Típicamente esto se hace de dos formas:

Todos los desarrolladores tienen todos los proyectos creados en su IDE y vinculados con SVN o, al menos, los proyectos en los que está trabajando, los proyectos dependientes, y los dependientes de los dependientes (dependencias transitivas), y así sucesivamente... es decir, típicamente todos. Esto es lógicamente un engorro, porque cada vez que alguien realice una refactorización que suponga la creación de un nuevo proyecto, afectará a todo el equipo de desarrollo. Todos los cambios impactan a todos (cambios en la configuración, dependencias, nuevos proyectos, etc...), favoreciendo, además, la incidencia de errores dada la exposición de todos los fuentes a todo el equipo.
Los desarrolladores que trabajan en proyectos que son requeridos por el resto "publican" sus artefactos en SVN o un repositorio común en red. Esta segunda opción introduce complejidad de configuración y coordinación en el equipo y scripts adicionales que realicen esas tareas, ya que hay que "avisar" de cuando hay que actualizar las dependencias... en todo caso: la gestión de las dependencias (en este caso internas) se manejan manualmente vía scripts (típicamente de ant).

Software de gestión de repositorios Maven

El software para de gestión de repositorios Maven sirve precísamente para eso: para crear y gestionar nuestros propios repositorios de Maven. De esta forma tendremos la gestión de dependencias solucionada:

las dependencias externas, a través del mismo Maven, usando el repositorio Central. También podemos crear nuestros propios repositorios proxies de otros, reduciendo el tráfico de red.
las dependencias internas (o inter-proyecto) con nuestro repositorio.

Veamos el siguiente ejemplo: tenemos un equipo de tres desarrolladores que está desarrollando una aplicación que tiene un módulo JAR, que a su vez es usado por un módulo EJB y otro módulo WAR que usa (necesita) los dos anteriores.

El desarrollador A participa en el desarrollo del módulo EJB, y es el único que desarrolla el módulo JAR. Este desarrollador no tiene que resolver dependencias internas, digamos que es un "productor" y debe "publicar" su trabajo para los demás.
El desarrollador B sólo trabaja en el módulo WAR: por tanto debe disponer de los otros proyectos. Sería el caso del "consumidor" exclusivo.
El desarrollador C trabaja en los módulos WAR y EJB: es decir, es consumidor y productor a la vez. Debe publicar su trabajo, pero también requiere del trabajo del desarrollador A.

En el caso anterior, usando un repositorio remoto con un software de gestión de repositorios, Maven realizará todos los trabajos de sincronización de forma transparente, realizando la publicación de artefactos al repositorio (mvn deploy) para los desarrolladores A y C, y la actualización automática para todos. Lo único que hay que hacer es especificarle la URL del repositorio en los pom.xml de los proyectos, simplificando enormemente la coordinación en proyectos reales típicos (más grandes, complejos y con más desarrolladores).

El software repositorio que yo conozco es Nexus, de la compañía que creó Maven (Sonatype), y la verdad, estoy muy satisfecho con su funcionamiento. No obstante, hay otros también bastante usados como Apache Archiva, o Artifactory. En general, todos parecen cumplir correctamente su misión principal y tienen una instalación sencilla. Al final del artículo puedes encontrar algunas referencias útiles con datos y opiniones sobre Archiva y Nexus. Con independencia de la elección, el objetivo del artículo es dejar claro para qué sirve y por qué nos es tan útil un software de gestión de repositorios. En nuestro caso particular, nos decidimos por Nexus porque usamos eclipse y pensábamos que tendríamos menos problemas si todas las herramientas estaban bien integradas por ser de la misma compañía: Maven, Nexus y m2eclipse.

La verdad, he de decir, que m2eclipse nos ha dado algún problema que otro, especialmente alguno bastante gordo que nos retrasó en el conocimiento del plugin y cómo funcionaba (p.e.: la opción "Enable Workspace resolution" ha dado problemas en sucesivas versiones del plugin), pero nada que decir sobre Nexus: hasta el momento, perfecto.

Finalmente, SVN, Maven y Nexus conforman una tríada perfecta para empezar cualquier proyecto pequeño adoptando buenas prácticas y un mínimo de coordinación automatizada, permitiéndonos poder escalar a proyectos y grupos más grandes afinando más hacia la integración continua con una buena base.

Referencias:

Desarrollo en equipo con SVN, Maven y Nexus (parte I)

2010-02-09T00:42:00.008+01:00

Banco de experiencias (V)

El orden es el placer de la razón pero el desorden es la delicia de la imaginación.
-Paul Claudel.

El desarrollo de software aúna una fascinante mezcla de pensamiento divergente (o creativo) con conceptos técnicos y prácticas metódicas. Para que un desarrollador (y especialmente un equipo de desarrollo) alcance los mayores niveles de eficiencia y productividad, las herramientas utilizadas deben garantizar la seguridad del proceso, pero siempre de forma proporcional a la envergadura del proyecto y manteniendo compatibilidad con el proceso creativo sin ahogarlo. Hay herramientas libres que nos ayudan a mantener este este delicado equilibrio entre orden y libertad para todo tipo de proyectos de forma sencilla e impecable.

Éste, como el resto de los artículos de la serie "banco de experiencias", no pretende ser un artículo más de documentación sobre las herramientas aquí comentadas ni encontrarás tampoco el enésimo tutorial sobre el asunto. Hay mucha documentación en la red y a lo largo del artículo suelo ofrecer información y referencias suficientes para que puedas profundizar en el tema. La idea de estos artículos es exponer buenas prácticas y comentar mi punto de vista, basado en mi propia experiencia profesional, sobre la utilidad real y pragmática de los temas abordados. Sin demagogia rimbombante ni publicidad interesada. Simplemente la síntesis de mi experiencia subjetiva.

Subversion

Subversion (también conocido simplemente como svn) es probablemente el mejor sistema de control de versiones centralizado que existe. Sin entrar en la discusión Centralizado vs Distribuido (DVCS), lo que si está claro es que el control de versionado es un aspecto crítico de cualquier proyecto de software.

En todo caso, si has llegado hasta aquí y no has usado nunca un software de control de versionado (VCS) la recomendación es clara: úsalo. Debes usarlo. Aunque tu proyecto sea muy pequeño. Aunque sólo exista un desarrollador. Has de asumir que, de la misma forma y con la misma naturalidad que usas un IDE o un compilador, deberás usar un VCS. Es absolutamente esencial. Si ya tienes claro que hay que usar uno y has decidido usar uno centralizado (o simplemente sueles usar otro, como CVS, por ejemplo), la recomendación también es clara: usa svn. En la wikipedia puedes consultar por qué SourceForge.net, Apache o Google Code lo eligieron, así como la documentación y herramientas disponibles.

Como decía, un software de control de versiones es necesario aunque el proyecto sea pequeño ya que te garantiza un seguimiento de cambios que te puede ahorrar muchas horas de trabajo. Si tienes clara la diferencia entre un editor de texto y un procesador de texto, entenderás enseguida la diferencia de usar backups de tu directorio de código y usar un VCS. No obstante, hay otro aspecto importante de los VCS que no suele ser tan comentado (quizá por obvio) y es su dimensión como herramienta colaborativa. Si de forma individual es extremadamente importante, para un equipo es absolutamente imprescindible. Un equipo no puede trabajar de forma "decente" sin Subversion. La idea de no usar un VCS o de usar uno bloqueante (tipo Visual SourceSafe) es una pesadilla para no dormir: "¡eh, cuidado!, no toquéis que voy a tocar yo" "¡Oh, mierda!, ya ha tocado alguien. ¡A ver ahora cómo lo arreglamos!"... o "¡fulanito, desbloquea el fichero que necesito añadir un método de la clase!" "¡No, espera que termine!"... Qué pesadilla. Me recuerda a aquellas herencias arcaicas de los programas COBOL de no pasarte de la columna 73 y poner los asteriscos en la columna nº 7... Bufff.

Trabajar con svn en equipo es lo más parecido a hacerlo como si estuvieses tú sólo. Si las tareas están repartidas, los conflictos son muy poco frecuentes (para que existan, dos desarrolladores deben haber modificado la misma línea simultáneamente antes del último commit) y cuando los hay, se suelen solucionar en pocos segundos. Es muy gratificante comprobar cómo un equipo numeroso puede trabajar en una aplicacion Web (un tipo de proyecto con un alto grado de colisión y concentración de trabajo) de forma cómoda y fluida sin problemas.

Maven

Aunque llevamos oyendo hablar de Maven desde hace varios años (Maven tiene ya 8 años), la adopción hasta hace cuatro o cinco años ha sido puntual y conceptual. Es desde la aparición de Maven2 (con su nueva arquitectura revisada) cuando realmente empieza a incorporarse (aunque también de forma muy lenta) a los distintos proyectos open source y esto ha hecho que en la comunidad de desarrollo comencemos a interesarnos y a integrarlo en nuestros proyectos. A mucha gente le ocurre que, tras leer sobre Maven y Ant, entiende las diferencias entre ellas, pero no alcanza a concretar por qué es tan importante y para qué le sirve realmente (qué le aporta que no tenga ya). Para aclarar definitivamente este punto simplemente hay que preguntarse cómo realizamos el proceso de construcción (generación de empaquetados y otros artefactos) en nuestros proyectos, y esto nos dará la respuesta. Veamos las opciones:

Construimos con nuestra herramienta de desarrollo (Eclipse, Netbeans, etc...).
Construimos con un fichero (build.xml) ant que nos hemos hecho nosotros.

Si se trata de un pequeño proyecto de un sólo módulo (un war, un jar, etc...) y/o el ciclo de vida de la aplicación es muy reducido (es una pruebecilla nuestra, una pequeña aplicación de las que se hacen en casa en zapatillas, etc) no importa, claro. ¿Qué más da? La he hecho yo y podré volverla a construir con mi IDE favorito o con mi Ant dentro de un año cuando tenga que hacer un cambio. Incluso aunque cambie el IDE o cambie mi entorno, podré adaptarme a la situación sin más problemas, hacer las correcciones y volver a generar el empaquetado.

Ahora bien, si nos situamos ahora un escenario profesional, el tema cambia mucho. A continuación expondré los problemas que nos encontramos con esas formas de construir aplicaciones. Seguramente ya te habrás encontrado con ellos, y si no, es porque el proyecto no era lo suficientemente grande o, simplemente, es una cuestión de tiempo que te los encuentres.

Homogeneidad. Cada desarrollador tiene sus costumbres y sus ubicaciones (paths) para sus proyectos, librerías, ubicación del JDK, etc. Es difícil e incómodo homologar a todo un equipo de desarrollo en una única estructura de ficheros. Aunque Sun hiciese su propuesta de convenciones para proyectos (estructura y nombrado) hace mucho tiempo, casi ningún IDE lo respeta al 100%. Además, la heterogeneidad de los distintos Sistemas Operativos no hacen más que complicar la posibilidad de tener una estructura y ubicación homogénea para todo el mundo. Eso hace que los ficheros de proyecto (.nbproject, .project, etc) no puedan ser portados de unos desarrolladores a otros ni compartidos entre distintas máquinas. Esta estructura acaba teniendose que modificar manualmente en los distintos IDE's o en el fichero build.xml de ant. En el caso de los IDE's es particularmente grave, ya que la información de librerías, por ejemplo, descansa en la configuración local del IDE de cada desarrollador, que suele ser distinta para cada uno, con lo cual la construcción se torna algo tremendamente frágil y poco transparente.
Reproducibilidad. Necesitamos realizar tareas forma constante y estable nuestro proyecto: construccion, pruebas unitarias, informes, etc... Repetibles en el tiempo (hoy y dentro de un año) y en el espacio (en mi máquina de desarrollo, en integración, en preproducción...). Necesitamos fijar parámetros que no están implícitos en el proyecto en si y que acaban también fijados en los IDE's o en el script ant: versión de Java, versiones de librerías, destino de cada librería (sólo para compilar, sólo para desplegar con la aplicación, para compilar y desplegar...), ficheros de configuración, etc... Esto dificulta el mantenimiento y oculta información esencial del proyecto. Si el proyecto se sube a SVN y no lo volvemos a tocar en un año, a menudo nos encontramos con que las partes esenciales del proyecto han quedado ocultas en IDE's (o lo que es peor, se han perdido porque eran parte de la configuración local de un miembro del equipo) o permanecen en un script de ant poco amigable para modificar.
Gestión del cambio. Algo tan común como añadir una nueva librería al proyecto o realizar una actualización de una existente tiene demasiado impacto en el equipo hasta resultar ligeramente traumático: todos deben realizar las tareas de la descarga y localización de las librerías, la configuración de su IDE y de su proyecto y/o la adaptación de sus ficheros ant. Incluso un equipo de desarrollo con normas rígidas y paths homologados, además de sufrir esta falta de libertad, sigue estando expuesto a este tipo de problemas.
Gestión de dependencias (externas). Este es sin duda el aspecto más importante, por delicado, y por el impacto de sus consecuencias. Imagina el siguiente proyecto: un EAR compuesto por dos módulos WAR, tres módulos EJB y un par de módulos de de librerías comunes (jar). Uno de los desarrolladores añade al EAR una librería "A" que necesita uno de los módulos EJB y otro desarrollador añade otra librería "B" que necesita uno de los módulos JAR. Ambas librerías tienen sus propias dependencias: la librería "A" requiere de xxx-commons-2.3 y de asm-2.1, la librería "B" de yyy-commons (que a su vez depende de xxx-commons-1.5) y asm-3.0. Ya tenemos el problema servido. Como ya comenté en el artículo "Errores comunes de despliegue JEE", este tipo de problemas algunas veces sólo se presentan aleatoriamente, ya que el problema puede presentarse o no en función de la secuencia de carga del ClassLoader de la máquina de turno. Esto ocurre muchas más veces de lo que nos pueda parecer a simple vista, si bien en la mayoría de los casos los conflictos no plantean problemas porque muchas librerías mantienen una compatibilidad perfecta hacia atrás. En mi experiencia, es habitual que ocurra sin embargo con grandes frameworks tipo Hibernate, Spring, Struts, etc, con consecuencias muy desagradables. Sin Maven, la gestión de dependencias no la hace nadie, o lo que es lo mismo, se hace manualmente si el equipo de desarrollo es muy cuidadoso y está muy bien coordinado.
Gestión de dependencias (internas). Otro aspecto de los proyectos medianos con varios módulos interdependientes entre si es que, además de tener que realizar gestión de dependencias de librerías de terceros tenemos que gestionar nuestras propias dependencias. Por ejemplo, para el caso anterior, si ambos WAR necesitan de los proyectos JAR de librerías comunes, todos los desarrolladores de los WAR deberán tener también que tener los proyectos (código fuente incluído) de dichos JAR, para estar debidamente actualizados... O bien buscar otra forma de distribución manual de empaquetados que también exigirá un esfuerzo adicional de coordinación.

Como puedes suponer a estas alturas, Maven es una solución perfecta a todos los problemas comentados anteriormente (salvo para el último punto, para el que se requiere un colaborador, pero eso lo comentaré en la segunda parte). Maven es y sirve para muchas cosas (compilación, paso de pruebas unitarias, control de calidad, etc) pero, fundamentalmente, es la mejor herramienta de construcción posible. Hasta ahora, para una construcción lo más homogénea y reproducible posible necesitábamos unas normas (o convenciones) y ant. Pero ant es un lenguaje específico de dominio para la construcción de proyectos: te tienes que crear tus propios scripts basado en tus convenciones y el esfuerzo de mantenimiento es exponencial a la envergadura del proyecto. Maven ya te aporta ambas cosas: convenciones (sobre disposición de directorios de proyecto, por ejemplo) y todo el trabajo listo para usar sin tener que configurar nada. Con Maven puedes realmente bajarte unos fuentes y ejecutar un "mvn build" sobre el directorio que contiene el "pom.xml". Y tener en poco tiempo todos los empaquetados, un informe de construcción, pruebas unitarias realizadas, etc, etc.. con configuración cero.

No obstante, el punto fuerte (e incluso espectacular) de Maven es la gestión de dependencias: sólo por la gestión de dependencias transitivas que realiza de forma automática, ya merece la pena con creces. En este tema me recuerda a los repositorios de Ubuntu. Cuando quieres una librería, añades la dependencia y la versión que quieres de las disponibles y él se encargará de aprovisionarse de todas las dependencias transitivas adicionales.

Incluso aún respetando las convenciones de Maven (te las puedes saltar si especificas en el pom.xml cuáles son tus directorios) Maven te ofrece toda la libertad posible: permite que un equipo trabaje con IDE's heterogéneos: cada desarrollador con su IDE favorito. Lo único que debes subir a SVN son los fuentes y el pom.xml. Podrás construir el proyecto de forma repetible, independiente del IDE, ejecutar las pruebas unitarias y olvidarte de problemas de librerías.

Obviamente no te vas a olvidar de tu IDE o de ant. Toda esta maravilla de Maven tiene un precio: el rendimiento. Un build con Maven te lleva más segundos de los que estás dispuesto a considerar como aceptables para tu trabajo de desarrollo habitual. No es aceptable desarrollar realizando builds con Maven. Por lo menos para mi. Por eso yo continúo realizando los ciclos de iteración compilación-despliegue-pruebas con mi IDE. Maven lo dejo para realizar las construcciones, para subir a svn proyectos autónomos y autogenerables y para poder realizar las integraciones y las puestas a preproducción de una forma segura y repetible.

En esta primera parte he expuesto 2 de 3 de las herramientas más esenciales para el desarrollo en equipo de proyectos Java (especialmente JEE). En el siguiente artículo cerraré el círculo con la herramienta que falta: un gestor de repositorios de Maven. Y explicaré cómo, con tan sólo esas tres herramientas, tenemos un entorno de trabajo potente y seguro para equipos de tamaño mediano sin rígidas normativas ni procedimiento burocráticos.

Referencias:

(continuación: Parte II)

Alternativas gratuitas a MS Project

2010-01-12T00:51:00.001+01:00

“Como nada es más hermoso que conocer la verdad, nada es más vergonzoso que aprobar la mentira y tomarla por verdad”. -Cicerón.

MS Project es un software de administración de proyectos para asistir a administradores de proyectos en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso, administrar presupuesto y analizar cargas de trabajo, aunque la verdad es que el uso mayoritario se centra (y de forma generalizada también acaba) en una planificación/cronograma acompañada de un diagrama de Gantt que nunca cabe en el documento de "Plan de Proyecto" y acaba tan reducido que es difícil de apreciar.

El uso de este software y sus artefactos (especialmente los diagramas Gantt) materializan la ficción extendida de las métricas del software a la que me referí en un artículo anterior. Y es que el mundo empresarial, inmerso en sus propios vicios adquiridos autojustificativos, requiere de éste tipo de "justificantes" falsificados, de la misma manera que se recoge un justificante por visita médica: es probablemente inútil, de redacción incomprensible y caligrafía críptica, puede que hasta falso o adulterado... pero se ha hecho necesario para que continúe la cadena de responsabilidad indirecta.

El software en realidad es bastante útil, el problema es que, como explicaba en el artículo comentado, los artefactos generados con el mismo se presentan como una verdad inmutable, como un producto exacto y preciso fruto de la ciencia y la ingeniería cuando en realidad, en el mejor de los casos, son producto de unas buenas prácticas, una experiencia dilatada, un buen equipo, unas acertadas predicciones y una ración de buena suerte. ¿Por qué? Pues sencillamente porque estamos estimando, estamos realizando diversas predicciones del tiempo que tardan varias personas cualificadas en realizar tareas moderadamente complejas y débilmente definidas, teniendo en cuenta una enorme sucesión de suposiciones relacionadas e interdependientes entre sí, y entre esas suposiciones, unos requisitos de proyecto inmutables o congelados en el tiempo: es decir, una conjetura como la copa de un pino, aunque más o menos razonable y convenientemente adornada.

No obstante lo anterior, el software tiene su utilidad para ayudarnos a realizar y gestionar esas conjeturas y tener pronósticos lo más acertados posibles: podemos desglosar las tareas, conocer sus relaciones y dependencias, realizar asignaciones aproximadas, conocer el camino crítico, detectar riesgos, etc... Si esos cronogramas fuesen algo vivo, como lo son los requisitos y el resto de los factores durante el ciclo de vida del proyecto, y se actualizasen y ajustasen periódicamente, podríamos tener una buena herramienta para gestionar nuestras hipót... perdón, quiero decir, tareas.

Dicho esto, vamos al tema que nos ocupa: en muchos casos, el coste de adquisición de este software es desproporcionado con una utilización parcial (digamos al 30% como mucho) y eventual (¿menos de 2 o 3 veces al año?), así que, ¿hay alternativas gratuitas?. Vamos a ello.

OpenProj

Probablemente el más parecido funcionalmente a MS Project y una de sus mejores alternativas. Está disponible para Linux, Unix, Mac y Windows (hecho en Java). Es gratuito, multilenguaje y distribuido bajo licencia CPAL, ha sido elegido para su inclusión en la suite Star Office para Europa.

Como herramienta de trabajo es perfecto. Sólo un inconveniente con respecto a la generación de artefactos: la impresión/exportación del diagrama Gantt y otros informes es sólo personalizable en la versión que se distribuye como Software as a Service (SaaS): Projects On Demand. La buena noticia es que el coste de esta versión es apenas de unos unos pocos 15€ al mes.

Ganntt Project

Esta herramienta cumple con el famoso Principio de Pareto (o "regla del 80-20") en cuanto a la funcionalidad esperada: la mayoría de los usuarios de MS Project (yo diría que mucho más del 80%) apenas utiliza un 20% de su funcionalidad. Esta funcionalidad mínima es la que nos ofrece este software.

Sus capacidades de importación/exportación, así como la generación de artefactos (diagramas e informes) cubren los mínimos necesarios como para que esta herramienta sea suficiente para realizar cronogramas de proyectos pequeños y medianos.

Es totalmente gratuito, multilenguaje, y distribuido bajo licencia GPL 2.0. Como también está desarrollado en Java, está disponible para Linux, Unix, Mac y Windows.

He ido probando cada actualización que hacen al producto y desgraciadamente siempre me he encontrado con ciertas carencias y deficiencias típicas de un producto aún falto de madurez. Ligeramente "tosco" y sin apenas hot-keys, tenía deficiencias editando tareas en proyectos no demasiado grandes, pero con muchas relaciones y tareas jerarquizadas (a la hora de mover tareas dependientes en el tiempo, gestionaba mal las dependencias "fuertes" o "rígidas" dejándolas sin desplazar). Tampoco nunca encontré una forma de realizar una re-distribución de recursos en casos de reasignación.

No obstante, seguiré probando hasta poder disfrutar su madurez definitiva.

OpenWorkbench

Probé la versión 1.1.6 cuando salió, allá por 2006. Realmente quedé impresionado porque era realmente una excelente alternativa a MS Proyect. Especialmente me gustó la facilidad para presentar distintas vistas a modo de hojas de cálculo que permitían obtener costes y realizar cálculos en base a estimaciones con bastante facilidad.

El producto es gratuito y open source (aunque no he encontrado el tipo de licencia exacto) no obstante, no es un proyecto muy activo: no parece haber evolucionado en estos últimos 4 años. Lamentablemente sólo está disponible para para plataformas Windows y yo no uso ese tipo de plataformas desde hace varios años, así que no lo volví a probar desde aquella vez. No obstante, si usas Windows, te animo a probarlo (y sobre todo, a cambiar a Kubuntu, claro ;-).

Nota: es bastante posible que funcione con Wine, pero me seducen más otras opciones... ;-)

KPlato

KPlato es la aplicación para gestión de proyectos de la suite KOffice. Es el más ágil, ligero y fluido de todos los comentados hasta ahora, y tiene el aspecto elegante y sencillo propio de la suite de Office para KDE.

Al igual que comenté en otro post sobre alternativas a MS Visio, se nota que si bien aún no ha alcanzado un nivel de madurez equivalente al OpenProj (en la redacción de este artículo he probado la versión 0.6.3), es equivalente o superior a Ganntt Project en cuanto a funcionalidad y muy superior a todos los demás en cuanto a usabilidad y agilidad. Al igual que con el resto de paquetes de la Suite, KPlato tiene un futuro muy prometedor ya que el roadmap evolutivo del producto nos depara probablemente la mejor alternativa a MS Project completamente gratuita.
Con licencia GPL, y originariamente para Linux, está disponible para muchas plataformas actualmente, incluído Windows.

Como siempre, recomiendo probarlos todos (lo que vale para mi, no necesariamente tiene que valer para ti ;-), aunque yo me estoy apañando perfectamente con los tres. Incluso he llegado a importar un .mpp de MS Project, modificarlo y volverlo a exportar para generar un mini-site HTML con Ganntt Project (del cual podía extraer perfectamente las imágenes de Cronograma Gantt que necesitaba).

La UE aprueba finalmente la adquisición de Sun

2009-12-23T07:07:00.004+01:00

Larry Ellison ha conseguido salvar el último obstáculo para hacerse con la totalidad de Sun sin renunciar a MySQL, que era el punto conflictivo tras las objeciones de la UE a la adquisición por la posible vulneración de la libre competencia en Europa en el sector de las bases de datos.

La Comisión Europea ha obligado a Oracle a realizar 10 concesiones y seguir invirtiendo en MySQL durante un tiempo. Este tema relativo a MySQL, aunque muy importante, no ha sido nunca mi mayor preocupación en torno a este tema de la adquisición (como comenté en un artículo anterior) sino, obviamente, aquellos activos de Sun (ahora de Oracle) que me afectan directamente: Java y Glassfish (y en ese orden).

Entiendo que Oracle tiene mucho interés en mantener la tecnología, ya que lleva años basando sus productos en ella. Otro tema serán cómo se afrontará el Java Community Process y los distintos comités por un lado y la gestión de un Servidor de Aplicaciones de código abierto y comercial compitiendo directamente con sus dos actuales: no creo que se vaya a quedar con tres productos equivalentes y en el mismo segmento de mercado.

Y todo esto, de forma contemporánea con la aprobación de la JSR 316, o más conocida como la especificación JEE 6, tras tres largos años de trabajo. Una de las especificaciones más esperadas y con grandes avances en muchos campos que sin duda nos facilitarán las cosas como por ejemplo un tipo específico de EJB para realizar singleton o las invocaciones asíncronas a EJB's.

La implementación de referencia (Glassfish v3) está disponible desde el 10 de Diciembre.

El próximo 2010 será el primer año de Java y Glassfish bajo el control de Oracle, con todas sus interesantes novedades (especialmente en lo que a JEE se refiere). Veremos cómo evoluciona la adopción de estas nuevas especificaciones.

Feliz año 2010.

Si queréis ir echando un vistazo a las novedades de JEE 6:

General

EJB 3.1

Servlet 3.0

An Overview of Servlet 3.0

Manifiesto en defensa de los derechos fundamentales en internet

2009-12-03T19:15:00.000+01:00

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que…

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Magnitudes astronómicas

2009-11-22T19:19:00.007+01:00

"El hombre es la medida de todas las cosas" -Protágoras de Abdera, s V a.C.

El hombre siempre ha tenido la necesidad de medir el mundo que le rodea: para explorarlo y comprenderlo, para relacionarse con los demás e intercambiar, para prevenir sucesos, pronosticar su devenir y desarrollarse. Como patrones, el ser humano ha utilizado todo tipo de elementos conocidos a su alrededor: su propio cuerpo, elementos de su entorno, fabricados ad-hoc para permitir su duplicación, etc.

Hace casi 2.300 años, Erastótenes determinó el tamaño de la tierra en "estadios" que, como su nombre indica, era una unidad de longitud equivalente a la longitud del estadio de Olimpia [1]. Ya no usamos científicamente unidades antropométricas, pero seguimos necesitando unidades de medida relacionadas con el mundo habitual que vivimos que nos ayuden a comprenderlo y materializarlo comparando con elementos conocidos. Todos podemos representar en nuestra mente o imaginar 1 Kilómetro, porque lo comparamos con distancias conocidas. Podemos también imaginar cientos e incluso miles de kilómetros porque conocemos mapas y el tiempo que se tarda en recorrer esas distancias en diferentes medios de transporte... Pero en lo que respecta a las distancias, nos quedamos ahí. Cifras como millones de kilómetros o años luz escapan de nuestra imaginación porque somos incapaces de compararlas con nada que conozcamos.

Recientemente ví el vídeo a continuación y quedé impresionado por los descomunales tamaños de los distintos cuerpos celestes y cómo unos cuerpos gigantescos se hacen ínfimos con respecto a otros.

Tras ver esto, me puse manos a la obra a intentar "imaginar" esos tamaños comparándolos con elementos conocidos, así que convertí el universo en una diezmilmillonésima de lo que es ahora. Lo que viene a continuación es un nano universo con objetos conocidos (disculpad las imprecisiones y redondeos, pero he primado la visualización de objetos en nuestra imaginación a la exactitud).

En este mundo, la tierra es como una canica grande (de 1,3 cm). La luna, del tamaño de una lenteja pequeña girando a su alrededor a un par de cuartas (casi 40 cm) de distancia. Una unidad astronómica (UA) es, en este mundo, la longitud de tres piscinas olímpicas, así que tenemos a nuestra canica girando alrededor de un sol del tamaño de un Smart (visto por detrás, ya que es más largo que ancho) a unos 150m de distancia. Girando también alrededor de esta esfera de metro y medio hay un guisante llamado Marte a 230m. de distancia y un balón de balonmano llamado Júpiter a unos 780m. Es decir, que si nuestro sol estuviese en la estación de Atocha de Madrid, Júpiter estaría girando a su alrededor al final del Paseo del Prado, por la fuente de Neptuno.

Otras estrellas son gigantescas incluso en este mundo enano. Betelgueuse, la supergigante roja de la constelación de Orion es del tamaño de un monte (480m.). Imaginaos una canica al lado de un monte. Pues eso no es nada, VV Cephei y VY Canis Majoris son esferas inimaginables de 1,5km y 2Km de diámetro respectivamente. Para intentar imaginar esas enormes hipergigantes rojas, deberíamos cambiar de escala, imaginando ahora que nuestro sol es del tamaño de un balón de balonmano y nuestra tierra de un grano de arena: en este caso, VV Cephei es como el Palacio de Comunicaciones de Madrid (en la plaza de Cibeles) y VY Canis Majoris es como el estadio Santiago Bernabéu. Impresionante, ¿no? Al final, como Erastótenes, he acabado también midiendo en estadios.

En fin, mientas pensaba en todo esto y hacía mis cálculos, me entero de la publicación del libro "La Galaxia en un campo de fútbol" [2]. Libro que, por supuesto, ya tengo nuevecito y reluciente a mi lado (muchísimas gracias, Eva, por el regalo). El libro trata de ésto mismo, proponiendo un método y nuevas unidades de medida para comprender el Universo. Os contaré cuando acabe sus páginas en una nueva entrada del blog... pero ya os avanzo que tiene una pinta estupenda.

[1]: Afortunadamente, Cristóbal Colón justificó la viabilidad de su viaje a las Indias por occidente con los datos erróneos de Ptolomeo. Posiblemente, con las mediciones de Erastótenes, el viaje no se habría realizado en aquella época. Seguramente éste sea el error más influyente en la historia de la humanidad y una de las pruebas de que los errores también nos conducen a fantásticos descubrimientos.
[2]: "La galaxia en un campo de fútbol", de Juan Fernández Macarrón, Edita: Equipo Sirius (2009)

La falacia de la Ingeniería del Software

2009-10-01T01:34:00.006+02:00

A partir de los años 70 comenzó a desarrollarse lo que, según mi opinión, es la falacia de la Ingeniería del Software y sus métricas para la cuantificación y planificación de proyectos de software. Desde las simplistas LOC (Lines Of Code), hasta la Complejidad Ciclomática, las métricas de producto han ido cambiando desde enfoques tan extremadamente matemáticos como inútiles, hasta enfoques de pesadas y burocráticas metodologías y análisis de negocio para los cuales hay que documentar durante cuatro meses para un proyecto de dos.

Es ahora, en el reciente 40 cumpleaños de la denominación de "Ingeniería del Software" como disciplina, cuando por primera vez uno de los padres del Análisis Estructurado, Tom DeMarco, en un artículo autocrítico realmente sorprendente (tratándose de él) reconoce con honestidad que la Ingeniería del Software es una idea obsoleta y que el Desarrollo de software es algo experimental, al menos en su concepción.

Durante este tiempo, la mayor parte del stablishment académico ha insistido de forma machacona a los sufridos universitarios de informática con la última metodología que aprendió (pero que jamás aplicó en ningún proyecto empresarial) el profesor de turno cuando tomó su plaza titular y en la que se anclaría de por vida, mientras se sucedían las promociones de informáticos que quedaban frustrados en su primer proyecto laboral por dos razones: la primera, porque la metodología en uso ya estaba "desfasada"; la segunda porque obviamente, resultaba impracticable para la mayor parte de los proyectos del mundo "real".

En efecto, es una trampa porque se trata de una falacia que persiste una y otra vez en un mundo endógeno. Los creadores de las métricas y de las metodologías vienen de monstruosos proyectos militares o gubernamentales, o del mundo académico. Mientras en el mundo académico éstas se toman como una "ciencia", como una verdad absoluta y dogmática, aunque jamás la hayan aplicado o la hayan visto aplicar, los casos de éxito en los grandes proyectos son nulos... ni que decir tiene del 99% restante de proyectos medianos para los que no fue ni imaginado. Y así, se suceden nuevas metodologías cada cinco años, una tras otra, que se van "enseñando", en la confortable ilusión de que algún día servirá a alguien, o de que esta sí es la "bala de plata" definitiva, aunque su uso/éxito real sea casi anecdótico o nulo.

La falsa ilusión del control

La ingeniería del software es una falacia porque es una aserción que podría estar compuesta por verdades parciales, pero que es falsa en su conjunto. Durante mucho tiempo se ha transmitido la idea del desarrollo del software como algo medible con exactitud, con el rigor científico aplicable a elementos físicos cuyos precisos procesos de fabricación son conocidos y estandarizados desde hace años... como comentó Dijkstra en un interesante ensayo: "...que los programas son simplemente dispositivos como cualquier otro, la única diferencia que se admite es que su fabricación pueden requerir un nuevo tipo de expertos, a saber: programadores" ([1]).

Todo esto para lograr prácticas consistentes y predictibilidad. Y en parte, en efecto, es así. Las sucesivas metodologías han ido aportando buenas prácticas que han servido, en los proyectos en los que es posible, un análisis más exhaustivo y pormenorizado de los requisitos, trazabilidad, control de cambios, control de calidad, etc... El problema es que han transmitido y calado en la conciencia colectiva empresarial una falsa ilusión de control del proceso. Esta ilusión también ha calado en el mundo académico, (demasiado separado, por cierto, del mundo profesional) donde parece que preocupa más la lírica teórica que la formación de profesionales prosaicos, que es lo que el mundo necesita, en definitiva. Pero también ha calado incluso en los mismos profesionales, que pinchan en hueso constantemente intentando aplicar aquellas prácticas y métricas aprendidas que teóricamente les alejan y diferencian de la "artesanía" de los sistemas de información de antaño, porque han recibido una formación en la que les han asegurado que "esto" nuevo, es "ciencia".

Pero la verdad es que la mayor parte de las decenas metodologías y métricas de estos últimos 40 años no son más que un conjunto de buenas prácticas adornado con estadísticas desplegadas con un imponente soporte matemático. Decenas de metodologías con una relación de casos de éxito tan exigua, que en cualquier otra disciplina científica no serían consideradas. Y hoy día, ninguna de ellas se aplica con éxito de forma generalizada ni se ha convertido en estándar, ni garantiza el éxito de la "fabricación"... y aun así se sigue llamando "ingeniería". Imaginen, por ejemplo, metodologías quirúrgicas con anecdóticos casos de éxito... ¿Se enseñarían en las facultades de medicina como "metodologías a aplicar"?.

El objetivo de las metodologías ha sido siempre la de aumentar la productividad y la calidad del desarrollo del software permitiendo que éstos sean sistemáticos, predecibles y repetibles. Hoy sabemos que las métricas y el control de calidad cuestan mucho tiempo y dinero... ya hace más de 20 años que sabemos que "el testing de programas puede convincentemente demostrar la presencia de errores, pero nunca puede demostrar su ausencia" ([1]). Aun así se sigue manejando el término control de calidad como si realmente pudiéramos controlar de verdad la calidad del software. Se habla de las metodologías como si realmente hubiesen conseguido el objetivo para las que fueron creadas. Ésta es la falacia.

Los ladrillos de código

Yourdon/DeMacro, Merisse, SSADM, Métrica (nuestro particular "me too" a modo de refrito de modelo de procesos y formas de llevarlo a cabo: dos por uno, oiga)... todas las metodologías a las que me he acercado están orientadas correctamente al proceso y a la funcionalidad, pero ignorando o trivializando unos de los aspectos fundamentales, que es tratado a menudo como un "recurso" de un determinado "perfil": los programadores, los hacedores del proceso mismo. En todos ellos, los recursos se mueven entre tareas o a lo largo de proyectos al más puro estilo de las obras civiles como si fuesen elementos pre-formados, estáticos, constantes, clónicos, sustituibles e inalterables. De la misma forma que las máquinas excavadoras ("Máquina A: X metros cúbicos por hora"), los programadores son capaces de realizar "una funcionalidad X en una unidad de tiempo Y". Ja, ja.

Y nos lo creemos. Nos han hecho creérnoslo, y seguimos haciendo como si fuese verdad. En el mantenimiento de esta mentira participamos todos (unos más que otros, eso si) pero especialmente es una cadena de mentiras necesarias. El cliente necesita creerlo y necesita que le digamos que estará en determinada fecha, y le enseñamos complejos cronogramas llenos de hitos y gantts que terminan, qué casualidad, justo en la fecha que él desea. El comercial también lo necesita porque hay que vender el proyecto. El gerente tiene dos opciones: el cinismo de créerselo o la resignación... normalmente acaba en la primera. Y asi una y otra vez. Clientes descontentos, equipos quemados buscando otra empresa, proyectos desastres inmantenibles, etc...

La cultura corporativa nos exige y nos sugiere permanentemente algo que sabemos positivamente que es falso, pero en lo que se insiste una y otra vez: la semejanza entre los proyectos de desarrollo de software con los proyectos de edificación u obras. ¡Como si fueran comparables!. En los primeros hay procesos de fabricación fiables, comprobables, y certificados. Hay procesos de construcción definidos desde la ciencia y la experiencia de cientos de años. Hay materiales probados, con tolerancias comprobadas y medidas. En definitiva, en los primeros se hace "ingeniería", en los segundos no. Es así de sencillo. Y las titulaciones adquiridas no tienen menos valor por lo que estoy diciendo. Tampoco diagnosticar una enfermedad u operar un corazón es ingeniería y no tienen menos valor los títulos en medicina por eso.

Adivina quién viene a cenar o el factor humano.

Lo curioso de todo esto es que "el método" falla en lo más importante. Y es que al final, tras las buenas prácticas, la toma de requisitos, el análisis, el diseño, el control de calidad y la documentación, el cliente está esperando los únicos dos parámetros que le interesa: tiempo y dinero. Aquí es donde "el método" se viene abajo o, simplemente, no sabe/no contesta. ¿Por qué? Muy sencillo. Porque ahora es donde entra en juego la estimación, es decir, la predicción, la pronosticación. Y esto no parece muy científico que digamos. Y aquí no contamos con buenas estadísticas de trabajos mecánicos y repetitivos como en obras de edificación. Aquí no hay paredes estandarizadas, ni obreros equivalentes... Aquí nos encontramos con equipos de distinta experiencia en distintas áreas tecnológicas, con equipos con su propio ciclo de vida y sus modus operandi distintos. Personas muy distintas con experiencias y destrezas muy diferenciadas. Y dichas diferencias tienen un impacto brutal en el resultado (rendimiento, mantenibilidad, limpieza, etc...).

Sinceramente, nunca me he encontrado a nadie que aplique métricas tipo COCOMO (¿de verdad alguien se cree que ése tipo de técnicas es precisa?). Al final, todas las técnicas predictivas utilizadas se basan en la experiencia de una forma u otra: bien por analogía con otros proyectos, bien por experiencia personal individual o en grupo (Wideband delphi).

Además, hay dos aspectos fundamentales del factor humano a tener en cuenta:

Especialización. En el desarrollo hay una tremenda especialización. Las distintas tecnologías forman a expertos no intercambiables y, por supuesto, nada tiene que ver un proyecto de una aplicación empresarial con un proyecto de un software de desktop o un videojuego, por ejemplo. Esta especialización hace que cierto programador pueda ser tremendamente eficiente en un proyecto y nada eficiente en otro.
Formación. Todo proceso de programación lleva implícita una parte más o menos grande de formación, que puede ser un porcentaje alto del tiempo dependiendo de la experiencia del desarrollador en la tecnología.

Sin duda, la variable más compleja de manejar es la del factor humano, ya que las estimaciones se pueden ir al traste con mucha facilidad. Los proyectos medianos con equipos medianos son especialmente sensibles, ya que la dependencia del equipo humano es el factor importante: no es lo mismo repetir con un equipo que ya ha trabajado junto que con un equipo nuevo... no es lo mismo poner a doce programadores inexpertos que a seis expertos. Y ya sabemos que, en muchos casos, incorporar al señor XY en el proyecto es una buena razón para tener ocupado a XY, no para que el proyecto termine antes o lo haga con más calidad.

Tell me sweet little lies

Parafraseando la famosa canción de Fleetwood Mac (Little lies), ha sido la industria del software la que se ha fijado mantener la mentira y encargarse de que se cuente mil veces (especialmente en la universidad, donde parece que se dan menos cuenta) para que, así, a fuerza de repetirla, acabe en algo cierto. Pero los los procesos de desarrollo aún distan mucho de ser medibles, predecibles, estables y repetibles. Lo que se ha venido en llamar (y es posible que desde ahora empiece a dejar de hacerlo) "ingeniería" del software aún está en pañales y le queda muchísimo camino por recorrer. Es posible que algún día, se parta de unidades básicas estándares (procesadores estándares, sistemas operativos estándares, lenguajes estándares, procesos estándares...) pero supongo que yo no estaré aquí para verlo.

Como comentaba en mi primer post, no todos los desarrolladores experimentados son expertos. El factor humano es la columna vertebral de los desarrollos y se requiere que los proyectos tengan una orientación al equipo tanto como lo hacen al proceso. Es fundamental. Es más, se precisa que sean los proyectos los que se asignen a los equipos y no al revés. Hoy por hoy, la experiencia sigue siendo la forma generalizada e imprecisa de realizar las estimaciones.

Referencias y otra información:

Excelente artículo sobre las metodologías ágiles y su diferenciación con respecto a las metodologías clásicas basadas en la métrica y la predictibilidad.
The Mythical Man-Month: otro extraordinario resumen del libro del mismo nombre con reflexiones tangenciales a la mías (en mi modesta opinión, por supuesto)
[1] El ensayo comprometido y crítico de Dijkstra es demoledor. En castellano, aquí.

Banco de experiencias (IV): librerías imprescindibles en Java

2009-09-08T01:00:00.007+02:00

La máxima de Albert Einstein

"Everything should be made as simple as possible, but no simpler"

o la de Leonardo Da Vinci

"La simplicidad es la máxima sofisticación"

junto con el Principio KISS (que no es otra cosa que una aplicación del concepto de La Navaja de Occam a la informática) y el Principio DRY, forman parte de los principios básicos que todo desarrollador debería tener presente siempre, ya que, parece ser que el "sentido común" es menos común de lo que debería... o en todo caso, un concepto demasiado genérico.Una de las consecuencias directas de estos principios es la utilización de componentes probados reutilizables en nuestros proyectos, que nos facilitan el trabajo de manera incalculable, no sólo de desarrollo, sino también y sobre todo, de depuración y estabilización. Dentro de los miles de juegos de componentes en forma de API's, librerías y frameworks hay una reducida selección de joyas que he ido recopilando con el paso del tiempo y uso en casi todos los proyectos. Incluso en tecnologías de desarrollo, donde la transitoriedad y fugacidad de las mismas es tan enorme, algunos imprescindibles han ido perpetuándose y creciendo o evolucionando en el tiempo, convirtiéndose en estándares de facto y haciéndose completamente indispensables. Esta es mi lista de imprescindibles:

logback: Está en el primer puesto por algo. Absolutamente indispensable y de incorporación obligada en cualquier proyecto. Es la evolución de log4j, asi que supongo que no hay nada más que añadir.

JUnit: Otra indispensable. Cualquiera que piense que esto de las pruebas unitarias es un rollo para "cuando tenga tiempo" está muy equivocado. Al igual que usar logback es tan fácil como sustituir los cutres System.out.println(), usar JUnit es tan fácil como sustuir los cutres "main()" en las clases para probar métodos (...lo que vienen siendo pruebas unitarias, vamos...). Para probar métodos muy usados en un proyecto o muy específicos no hay nada mejor... tampoco se trata de crear unitarias para todas las clases!.

Apache Commons: Hay algunos que cuando entran en el enlace por primera vez ignoran la mayor parte del contenido, aturdidos por su enorme extensión o simplemente por desconocimiento. Sin embargo sugiero dedicar unos segundos simplemente a ojear las librerías existentes. Es impresionante. Tras unos instantes uno comprueba la cantidad de veces que habremos "reinventado la rueda" en algunos proyectos antes de conocer estas librerías. Aunque todas son susceptibles de ser útiles, voy a destacar las que considero imprescindibles y cuyo uso me ha reportado enormes satisfacciones:

IO: Un vistazo rápido a la guia de usuario te dará una idea de su potencial. Especialmente para aquellos casos de aplicaciones que tratan con nombres de fichero u operar con ficheros y directorios de forma compatible para distintos sistemas operativos.
Lang: Hay un excelente artículo de cómoda y atractiva lectura que te dejará claro por qué es absolutamente indispensable.
Configuration: Igualmente, hay otro buen artículo en el que encontrarás los ejemplos necesarios. Especialmente interesante es usarlo con el wrapper EAC4J para usar la configuración vía JNDI.
VFS: Cuando tengas que hacer un acceso a ficheros cuya ubicación es indeterminada, usa VFS. Es una capa de abstracción que te permite acceder a múltiples sistemas de ficheros (SMB, FTP, SFTP, HTTP, etc...). Por ejemplo, es ideal si tienes que acceder a ficheros que hoy son locales pero igual mañana están en un recurso compartido de un servidor Windows con autenticación, o una cabina de discos NAS...

HttpClient: Si necesitas hacer algo más allá de HTPP GET o POST, como usar HTTPS, proxies, cookies, etc... necesitarás HttpClient. Incluso en el caso más sencillo: es más cómodo, rápido y seguro que usar java.net.

Específicas para JSF

Para los desarrollos de JSF, tengo también mis imprescindibles específicos. Son los siguientes:

facelets: Algunos kits o implementaciones ya lo incluyen, como ICEfaces. Si no lo usas, estás complicándote la vida: facelets simplifica.

on-load: La solución para ejecutar código cuando se carga una determinada página.

EasySI: ¿Harto de realizar conversiones manuales para cargar colecciones de SelectItem para publicar combos? Usa EasySI o <t:selectItems> de Apache MyFaces Tomahawk.

Son todas las que están... pero posiblemente no estén todas las que son... ¿Hay alguna que uses frecuentemente que no esté en la lista?

Alternativas gratuitas de código abierto a MS Visio para Linux

2009-08-27T15:38:00.003+02:00

Este es uno de los temas más recurrentes de los usuarios de Linux: encontrar una una aplicación clon de MS Visio para Linux.

Hay varias aplicaciones muy parecidas y con funcionalidades equivalentes, pero los resultados que se obtienen son muy diferentes a Visio. ¿Por qué? Pues fundamentalmente por la galería de objetos, formas y cliparts, que en Visio están muy bien realizados y cuenta con un catálogo de formas realmente enorme, no sólo por los que vienen "de serie", sino también por la amplia oferta de descarga adicional.

Una vez puestas las expectativas en su sitio, está claro que podemos hacer diagramas en Linux. Especialmente para una gran mayoría de usuarios cuyas exigencias tampoco son precísamente muy sofisticadas. Estas son las alternativas:

OpenOffice Draw

Draw es un editor de gŕaficos vectoriales que se parece más a CorelDraw que a MS Visio, pero se puede instalar la Open Clip Art Library (Biblioteca Abierta de Clip Art), que permite agregar una enorme galería de banderas, logotipos, iconos y estandartes y pancartas para presentaciones generales y proyectos de dibujo.

También puedes descargar ClipArts adicionales desde http://extensions.services.openoffice.org/project/oxygenoffice-gallery.

Esta aplicación cumple perfectamente si el objetivo es crear diagramas varios para presentaciones o documentos. Si no tienes nada más a mano, es una solución rápida, gratuita y legal. Es la que uso más frecuentemente.

OpenOffice está también disponible para OSX, FreeBSD y Windows.

Kivio

Kivio es la aplicación para diagramas de la suite KOffice. La verdad es que esta suite promete bastante, especialmente por la enorme cantidad de aplicaciones que incluye:

productividad (típico de cualquier paquete Office): procesador de textos, hoja de cálculo, presentaciones y base de datos (compatible MS Access, por cierto)
creatividad: diagramas de flujo, dibujo vectorial y imágenes de mapa de bits
gestión de proyectos (tipo MS Project)
y otras, como un generador de informes, así como herramientas para gráficos empresariales y editor de fórmulas.

Me he instalado varias aplicaciones (Kivio, Kexi y KPlato) con el clásico "sudo aptitude install xxxx" y me han dado muy buenas sensaciones: aplicaciones de aspecto limpio y sencillo y muy ligeras y fluidas.

En general el desarrollo de la suite, aunque está ya en su versión 2, sigue en su fase temprana y faltan aún temas por acabar pero, como decía, auguro un interesante futuro para esta suite.

Kivio, en concreto, se parece enormemente a MS Visio y, probablemente sea su clon más exacto cuando esté definitivamente acabada. Los usuarios de Linux po drán empezar a probarla desde ya mismo. Los usuarios de Windows aún tendrán que esperar un poco más... pero estará disponible en breve.

Supongo que Kivio acabará siendo al proyecto KDE lo que ha sido Dia a GNOME.

Hoy por hoy es una opción a tener en cuenta, aunque la biblioteca de cliparts disponible es reducida.

Dia

Cuando comenzaba el artículo, comentaba que ésta solía ser una pregunta recurrente de los usuarios de Linux... y la respuesta recurrente en Internet siempre es ésta: Dia.

Desarrollada en gtk+ (como parte del proyecto GNOME), es una aplicación diseñada como sustituto de Visio... pero supongo que inspirada en éste antes de que Microsoft adquiriese la compañía Visio, en el año 2000. La aplicación cumple su misión bastante bien, pero a mi particulamente se me antoja que tiene un diseño obsoleto (las aplicaciones multiventana no me gustan nada), no ha tenido últimamente mucha evolución (se ha actualizado recientemente, pero no lo hacía desde el 2007) y no me resulta cómoda.

Debo reconocer, que siempre que me he propuesto usar Dia he acabado usando OpenOffice Draw. No obstante, recomiendo instalarlo y probarlo: puede ser que sea esto justo lo que estás buscando o que te guste a tí.

En definitiva, por mi parte seguiré muy de cerca la evolución de Kivio, que me ha parecido realmente lo que yo busco. Mientras tanto, continuaré con Draw.

Banco de experiencias (III): errores comunes de despliegue en JEE

2009-07-27T18:00:00.007+02:00

El problema

En JEE, además de la compilación y empaquetado, comunes en otras disciplinas java, existe un proceso imprescindible y no poco problemático: el despliegue.

Los errores de programación suelen ser detectados por el propio compilador y otras herramientas que ayudan a la detección de potenciales errores de ejecución. Sin embargo, hay ciertos errores de despliegue (es decir, errores que se producen en tiempo de despliegue y que te impiden incluso iniciar la aplicación para probarla) que no son fácilmente detectados por ninguna herramienta y que son un verdadero dolor de cabeza para los programadores por sus incomprensibles síntomas y difícil detección.

Existen también otros problemas, no dependientes directamente de nuestro código que se presentan durante el inicio o durante la ejecución de la aplicación. Este tipo de problemas son aún más difíciles de detectar, ya que los síntomas que encontramos no suelen tener ninguna relación con el código asociado al momento/lugar del código donde se producen o donde el servidor señala el error. Este tipo de problemas acostumbra a estar asociado también al despliegue o a algún bug del contenedor.

En este artículo ofrezco una checklist para cuando nos encontremos esas apuradas situaciones, en las que se nos han agotan las posibilidades y no sabemos dónde más mirar o qué más hacer.

Los síntomas

Los síntomas que nos encontramos en este tipo de errores son:

Un artefacto o componente JEE no se comporta como debe o simplemente no funciona en absoluto, sin embargo, el contenedor o servidor no reporta errores. Por ejemplo, un servlet correctamente declarado y desplegado no funciona y no hay errores en los logs.
El sistema reporta errores que aparentemente no tienen sentido. Por ejemplo, una clase o método que no se encuentra cuando comprobamos que está correctamente desplegado y accesible en el classpath.
Un segmento determinado de nuestro código no se ejecuta o termina de forma abrupta, y tampoco tenemos errores en los logs. Por ejemplo, un método de una clase implicada en un Resource Adaptor (conector JCA).

El diagnóstico

Se supone que ante los síntomas anteriores, ya hemos agotado todas las posibles opciones y orígenes típicos o supuestos que se nos ocurren, y especialmente, ya hemos descartado del todo (o casi del todo) que la causa sea nuestro propio código. Ante esto, ¿qué hacemos? ¿dónde está el problema? ¿dónde buscar?

Pues para esos casos y otros similares, aquí va una checklist que os será de utilidad:

Revisar nuestro código otra vez, o lo que es mejor, que lo haga otra persona. Incluso en esos casos, lo normal es que el problema siga estando en nuestro código, así que, si lo has revisado dos veces: hazlo una tercera y que la cuarta lo haga otra persona.
Comprobar que el path de despliegue no tiene caracteres multibyte. Algunas librerías que usan reflection, no están preparadas para cargar clases en paths con espacios o caracteres multibyte (eñes, acentos, etc...). Especialmente en sistemas operativos raros de ésos que algunos usan para desarrollar (como Haselfroch, por ejemplo). Ejemplo: toplink-essentials no funciona desplegado en un path con espacios.
Cuidado con los despliegues "exploded". En algunas ocasiones nos interesa hacer despliegues desemplaquetados o descomprimidos. Si el directorio del módulo ha sido descomprimido fuera del sistema donde lo vamos a desplegar, puede haberse corrompido durante la copia o transferencia. Hay dos tipos de adulteración que pueden sufrir los ficheros:

Corrupción binaria. En algunas ocasiones es posible que un fichero .jar (por ejemplo, de nuestras librerías) se corrompa al copiarlo y la aplicación no despliegue por esa causa.
Alteración de nombres. Es posible, por ejemplo, que si se han copiado de un medio con un filesystem antiguo como FAT32 (case insensitive) acabemos con un directorio META-INF en minúsculas. Este tipo de errores es difícil de encontrar, pero nos crea problemas increíbles. Por ejemplo: la JVM no encontrará las dependencias declaradas en ficheros MANIFEST.MF en directorios meta-inf (así, en minúsculas).

Revisa los descriptores. Este es uno de esos males provocados por el famoso "copiar y pegar" que tanto daño hace al desarrollo. Por ejemplo, para que funcione el maravilloso mecanismo Dependency Injection de JEE 5 en una aplicación web, es preciso que el descriptor del web.xml especifique expresamente la especificación Servlet 2.5. En definitiva, hay que revisar las cabeceras de nuestros ficheros descriptores y comprobar que ninguno es "heredado" de un proyecto anterior.
Cuidado con los empaquetados automáticos de los IDE: revisa tus librerías. Cuando utilizamos librerías externas en varios proyectos, éstas suelen tener, además, sus propias dependencias que debemos incluir. Si nuestro empaquetado es automático vía algún IDE puede ocurrir que incluyamos varias veces una misma librería o distintas versiones de las mismas librerías sin darnos cuenta. Si además las librerías se cargan en ClassLoaders distintos, el caos está garantizado. Por ejemplo: este tipo de problemas suele provocar desconcertantes errores con "IllegalArgumentException" o "NoSuchMethodException" ya que el ClassLoader encuentra una versión más antigua de la librería que creemos que está usando.
Traza, traza, traza. Y hazlo bien: usa log4j o incluso mejor, usa su revisión: logback. Es importante saber en qué punto exactamente el sistema deja de hacer lo esperado.
Revisa las secciones estáticas de tus clases. Las declaraciones de miembros estáticos o secciones estáticas (static {}) de una clase incluyen muchas veces constructores o llamadas a métodos que pueden, a su vez, generar un NPE (NullPointerException) indeseado. Cuando esto ocurre en una sección estática de una clase, la clase no puede ser inicializada y muchas veces obtenemos mensajes confusos tipo NoCassDefFoundError que nos despistan y no caemos en que todo se debe a un NPE nuestro. En las secciones estáticas, mantén el principio KISS. Por ejemplo, si declaras el típico private static final Pattern pRe = Pattern.compile("\\s*");, asegurate de que la expresión regular es válida o toda la clase entera no podrá usarse en tiempo de ejecución.
Observa con detalles los logs del servidor y aumenta los niveles de trazado. Es frecuente que no hagamos caso al StackTrace que vuelcan los servidores en sus logs y simplemente nos fijemos en los más bajos de la pila (los últimos en listar). Mira con mayor detalle. Muchas veces te darán pistas sobre dónde buscar. Por ejemplo, me ha pasado escribiendo un Resource Adapter que un método ManagedConnection no se ejecutaba a partir de una determinada línea porque un bug del servidor "mataba" el thread cuando el contenedor llamaba a un método de limpieza. Al aumentar las trazas del contenedor de JCA me dí cuenta del problema (un NPE del contenedor en el dispose() de las conexiones).

Cuando tengas un problema de despliegue y empieces a quedarte sin opciones, vuelve a esta entrada y repasa esta lista de comprobaciones, es posible que te ayude... A mi me sirvió.

Eclipse 3.5 Galileo + Glassfish: error instalando el plugin de Glassfish

2009-07-16T16:57:00.002+02:00

Hace ya más de tres semanas que está disponible, o liberada, como dicen algunos (como si hubiera estado "presa" alguna vez..., en fin, esto de las traducciones libres...) la nueva versión de Eclipse, versión 3.5 y denominada "Eclipse Galileo", tras "Calisto", "Europa" y "Ganymede"... (va a pasar mucho tiempo hasta que se queden sin nombres).

Pues bien, mi estreno con esta nueva versión ha sido un poco decepcionante, ya que, tras desactivar el "spelling" (que sigue estando activado por defecto, usando 5,6Mb para nada), lo segundo que hago es instalar el plugin de Glassfish... y me encuentro con mi primera desilusión:

An error occurred while collecting items to be installed

No repository found containing: org.eclipse.update.feature,com.sun.enterprise.jst.server.sunappsrv.feature,1.0.29
No repository found containing: osgi.bundle,com.sun.enterprise.jst.server.sunappsrv,1.0.29
session context was:(profile=epp.package.jee, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Collect, operand=, action=).

En efecto, es imposible instalar el plugin de eclipse según el modo tradicional, es decir, vía "download additional server adapter". Debe tratarse de algún bug circunstancial que solucionarán en breve (espero).

Mientras tanto, la solución es instalarlo vía Update URL a través de la URL: http://ajax.dev.java.net/eclipse. Ya sólo me queda instalar Subversive plugin para usar SVN y todo vuelve a ser como antes...

Que la disfrutéis.

[20/07/09] ACTUALIZACION: El comentario de un lector me informa de que es un bug conocido: https://bugs.eclipse.org/bugs/show_bug.cgi?id=280365. Thank you, finsterwalder.

Líala parda

2009-07-14T08:46:00.000+02:00

Algunos recordaréis la expresión "la he liao parda" que una chica socorrista hizo famosa. Como afortunadamente todo quedó en un susto y no hubo consecuencias graves, pudimos reírnos de la anécdota, especialmente por la forma tan natural y sincera con la que se expresaba la chica al pedir disculpas. El vídeo en YouTube, (junto con otras copias) lo ha visto más de medio millón de personas, así que la expresión ha pasado a formar parte de las expresiones de moda colectivas, como consiguió Chiquito de la Calzada en su momento.

En fin, esta introducción viene a cuento del sitio www.lialaparda.com, desde el que puedes gastar una simpática broma y reírte un rato.

Os puedo garantizar que el sitio es de absoluta confianza... Probadlo y veréis ;-)

P.D.: sólo funciona con móviles de España.

XLS Office 2007 y anteriores con Java (SpreadsheetML incluído)

2009-06-17T19:28:00.004+02:00

Apache POI es el framework de referencia y casi un estándar de facto para acceder a los formatos Microsoft usando un API Java Nativo. El subproyecto HSSF+XSSF de la versión 3.5 (aún en beta, pero totalmente funcional para el 90% de las operaciones) admite los nuevos formatos Open XML (como por ejemplo xlsx, introducidos en Office 2007).Y hasta aquí, aparentemente, todo solucionado. Si sólo pretendes importar/exportar datos, y no vas a usar funciones muy avanzadas, la Beta 5 de la versión 3.5 te va a funcionar perfectamente.No obstante, te puedes encontrar con alguna sorpresa desagradable en el lío de formatos de Office de MS. Concretamente la que se me ha dado a mí recientemente con un fichero Excel (xls) ha sido la siguiente:

Exception in thread "main" cestel.tk.uf.dao.file.DAOImportException: java.lang.IllegalArgumentException: Your InputStream was neither an OLE2 stream, nor an OOXML stream at cestel.tk.uf.dao.file.DAOHssf.loadAgenda(DAOHssf.java:79)

...

Obviamente se trataba de un fichero que se podía abrir en Excel normalmente, aunque me llamó la atención el hecho de que OpenOffice (al menos la 2.4) no era capaz de abrirlo como hoja de cálculo y en su lugar, presentaba el diálogo de importación. Abriendo el fichero con un editor de texto, me encuentro con que resulta que es un fichero XML con un contenido así:

1 <?xml version="1.0" encoding="UTF-8"?>
2 <?mso-application progid="Excel.Sheet"?>
3 <Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet"

   xmlns:o="urn:schemas-microsoft-com:office:office"

   xmlns:x="urn:schemas-microsoft-com:office:excel"

   xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet"

   xmlns:html="http://www.w3.org/TR/REC-html40">
...

¿Y qué demonios es esto? Pues eso es, concretamente, SpreadsheetML, uno de los formatos de Microsoft Office XML, creados con anterioridad al Office 2007 y ya obsoletos, siendo sustituídos por los formatos Office Open XML (también llamados OOXML u Open XML)... y el problema está en que estos formatos no están soportados por Apache POI.

Afortunadamente, para estos casos, existe Xelem, una librería que te permite leer y escribir ficheros SpreadsheetML, con los que pude resolver el problema de la importación de datos.

Sideralis: un Stellarium en tu móvil

2009-06-05T01:48:00.007+02:00

Este año 2009 se celebra el Año Internacional de la Astronomía (declaración de la UNESCO ratificada por la resolución de la ONU en 2007). El AIA 2009 es la excusa perfecta para publicar una entrada a propósito de uno de los temas que más me han fascinado: la astronomía. Quizá este post debería haber sido el primero de todos, ya que el nombre de este blog se debe a mi atracción por la astronomía. Balteus es nombre que se le daba al cinturón que llevaban los legionarios romanos, también llamado cingulum, y que portaba la espada. También se ha llamado así al famoso trío de estrellas Alnitak, Alnilam y Mintaka, de la constelación Orión, una de las más conocidas de nuestro cielo. Este trío conforma el cinturón que porta la espada de Orion, típicamente conocido como "el cinturón de Orion" y también conocido como Al-Nijad (el cinturón), Al-Nasak (la línea), Balteus (el cinturón), "Los tres reyes", "Las tres marías", etc, etc... Siempre me han atraído esas tres estrellas alineadas.

Cuando miramos al cielo a simple vista nos puede parecer que estamos viendo millones de estrellas... pero nada más lejos de la realidad: raras veces llegamos a ver más de 300 (magnitud 4).. ¡y eso en el campo y en circunstancias perfectas!. Lo máximo que podríamos llegar a ver, en el mejor de los casos (a 4.000 metros de altura, sin luna, con cielo despejado y con una vista envidiable) serían 1.500, como mucho. Con este panorama, y teniendo en cuenta contaminación lumínica, cielos poco despejados y nuestra limitada vista, en la mayoría de los casos normalmente sólo alcanzamos a ver entre 30 (magnitud 2) y 100 (magnitud 3). Además, todas son del vecindario: de la Vía Láctea. De 200.000 millones de estrellas repartidas en un radio de 100.000 años luz de nuestra propia galaxia, apenas alcanzamos a ver unas decenas de estrellas... Aquí, en la ciudad de Madrid, en buenas condiciones, apenas se perciben, a simple vista, menos de una docena (sin contar Venus, que se ve perfectamente, pero no es una estrella). Ya que vemos tan pocas estrellas, ¿no os gustaría saber cuáles son? ¿cómo se llaman? En mi caso, sin referencias, y siendo un simple curioso/seguidor "de documentales" (ni siquiera me puedo considerar un aficionado a la astronomía), es prácticamente imposible saber qué estoy viendo... hasta ahora.

Los curiosos de la astronomía conocerán casi seguro Stellarium (el sitio web en español es éste). Probablemente uno de los mejores mapas de cielo (o mapa estelar, o planetario, como queráis llamarlo) para ordenador. Si no lo conoces, bájatelo y pruébalo. Aunque sea sólo por curiosidad. Es espectacular. Está disponible para varios sistemas operativos (e incluso para Windows). Probarlo es muy sencillo y, comprobar que lo que estás mirando por la ventana es lo que te aparece en la pantalla, es cuestion de unos pocos minutos. Es una forma muy divertida y agradable de introducirse en el fantástico mundo de la observación del cielo.

Cuando Galileo apuntó por primera vez al cielo con un telescopio, 400años atrás, no creo que se imaginara que llegaríamos a tener un planisferioluminoso en un aparato minúsculo que, además (mira tú qué cosas), sirve también para llamar por teléfono y decirte la hora. ¡Por fin un móvil sirve para algo interesante!.

Sideralis es un equivalente a Stellarium, pero en tu móvil. Funciona perfectamente en mi N82 y, en principio, en prácticamente cualquier móvil más o menos reciente que soporte MIDP 2.0. La aplicación es muy completa: vistas horizonal y cénit, e información de más planetas, estrellas (más de 800) y objetos Messier de los que podamos ver incluso aunque tengamos unos prismáticos a mano.

La ventaja del programa es evidente. Si estás por la noche en un lugar despejado (o en cualquier sitio que puedas observar al cielo) sin haberlo podido planificar, es difícil que lleves un planisferio, una PDA o un PC encima... ¿pero el móvil? casi seguro que lo tienes a mano para arrancar esta maravilla y empezar a ponerle nombre a lo que ves.

Está disponible en español y además es gratuito. Sólo le falta (puestos a pedir) que tome la localización automáticamente del GPS integrado de los móviles que lo tengan. Desde aquí, le doy las gracias al autor por brindarnos gratuitamente esta joya

Ah!... y está hecha en Java, claro.

P.D.: por cierto, hay un post muy bueno sobre planetarios para Linux aquí.

ACTUALIZACIÓN [16/06/09]: La versión 1.2.7 (etiquetada internamente como 1.02(7)) ya incluye tres formas de posicionamiento: manual (introduciendo longitud y latitud), seleccionando tu ciudad, o vía GPS.

Open Source BRE/BRMS JSR-94 compliant

2009-05-20T09:43:00.010+02:00

El título está en inglés, pero es que "Motores de Reglas de Negocio o Sistemas de Gestión de Reglas de Negocio compatibles JSR-94 de código abierto" es un título muy largo y, cuando buscamos información, se suele buscar más usando los términos en inglés.

Recientemente he tenido sondear el estado del arte de los BRE/BRMS de código abierto y lo primero que encontré es que hay decenas (concretamente hay 30 en esta lista de noviembre de 2007). Obviamente, no tengo tiempo de evaluar tantos proyectos, así que establecí una serie de criterios de búsqueda que me redujesen la lista de resultados a una cantidad aceptable para evaluar o, al menos, leer y recopilar información para una posterior evaluación.

Los criterios de búsqueda que establecí son:

BRE mínimo (se excluyen "compiladores" de reglas)
Conformidad con la JSR-94
Proyecto activo (considero "activo" un proyecto con actividad reciente inferior a 2 años)
Ligero, con persistencia y repositorio autónomo (es decir, que aunque pueda usar una base de datos no la necesite necesariamente)
Documentación suficiente o aceptable.

El resultado de la recopilación es:

Drools / JBoss Drools / Jboss Rules
OpenRules
Hammurapi Rules
SweetRules
JRuleEngine

Aunque muchos BRE evolucionan a un BRMS, lo cierto es que BRMS no hay muchos, con lo que la recopilación se queda en un número más pequeño del que me imaginaba. Además, el criterio de conformidad a la JSR-94 ha sido suficientemente restrictivo, ya que excluye todos los que no son Java y además, son muy pocos los que cumplimentan la especificación.

Drools (JBoss Drools / JBoss Rules)
Probablemente el más conocido, y también el más gigantesco de los proyectos. Se puede considerar un BRMS en toda regla ya que tiene herramientas típicas de los BRMS propietarios (repositorio, editor de reglas WUI,etc)
Las reglas pueden escribirse en DRL (el típico), Java, Groovy... incluso puede extenderse con DSL's vía XML.
Para mi, quizá uno de los puntos fuertes de Drools sea la integración con el resto de servicios de middleware de jBoss, especialmente con jBPM. La versión 5, se espande en un elenco de servicios realmente impresionante, que promete bastante.
Curiosamente, tiene un porting a .NET.

OpenRules
Este es el proyecto que más me ha llamado la atención por novedoso, curioso y de aplicación práctica inmediata. Desdel el punto de vista de la existencia (y variedad) de repositorios y herramientas, estamos ante un BRMS (Drools y éste son los únicos de la lista). La característica más destacada de OpenRules es la versatiliidad y adaptabilidad, ya que:

tiene una arquitectura enormemente flexible y adaptativa a distintas estrategias de despliegue.
definición de reglas en ficheros Excel, aunque se pueden definir también en tablas de base de datos, objetos java, xml,...
permite utilizar múltiples tipos de accesos a repositorios jerarquizados: ficheros, svn, cvs, base de datos, http, ftp, etc...

El sitio web está muy bien organizado, tiene muchos ejemplos, y la documentación es bastante buena. Me ha impresionado, realmente.

Como curiosidad, está votado como el más popular en javarules.org.

Hammurapi Rules
Es más un BRE que un BRMS, aunque tiene una arquitectura multithread muy bien diseñada. Una ventaja interesante es que el lenguaje elegido para las reglas es el propio Java, con lo que la curva de aprendizaje es muy pequeña. Además, siendo realistas, pocas situaciones hay en las que existe el famoso "analista de negocio" que es capaz (y además quiere hacerlo) de definir las reglas de negocio en un lenguaje "informático" (y eso suponiendo que los objetos de negocio no cambien mucho).

Me parece una buena opción para casos en lo que nos biene especialmente bien escribir las reglas en Java y queremos "empotrar" un BRE en nuestra aplicación fácilmente. Por ejemplo, para migrar a una aplicación con muchas reglas hard-coded a reglas modificables en caliente sin demasiado impacto.

SweetRules
Aunque no es conforme a la JSR-94, me llamó la atención que es el único que implementa RuleML, el que se propone como lenguaje de reglas estándar. No obstante, la web es caótica, y la documentación deja mucho que desear. La implementación de RuleML es la única curiosidad.

JRuleEngine
Probablemente es el BRE más ligero de los 5. Las reglas se escriben en XML y no he visto que implemente Rete. No obstante, parece cumplir con los mínimos.

Al final, junto con Drools (¿cómo no?) el proyecto que más me ha gustado es OpenRules. Hammurapi Rules también es bastante interesante. ¿Crees que he omitido alguno que debería estar? ¿hay alguno que te parezca especialmente interesante? Agradeceré comentarios al respecto.

Alternativas EAV con XML (en PostgreSQL 8.3)

2009-05-18T01:45:00.006+02:00

El modelo EAV
El modelo Entidad-Atributo-Valor (EAV, Entity-Attribute-Value), también conocido como Objeto-Atributo-Valor o Esquema Abierto, se usa en casos donde el número de atributos (propiedades, parámetros) usados para describir una entidad u objeto es potencialmente grande, pero que aplicados individualmente a una entidad concreta es pequeño. Las circunstancias donde se suelen aplicar son:

Entidades con atributos heterogéneos:

Entidades dinámicas en el tiempo, donde los atributos de una entidad son fijos, pero durante un período de tiempo variable. Es decir, son cambiantes (pueden crecer o decrecer) en el tiempo.
Entidades conceptualmente dinámicas, dependiendo de la interpretación del sistema en un determinado momento. Es decir, entidades cuyo número de atributos cambia según el contexto (p.e.: atributos definidos por el usuario)

Entidades con atributos homogéneos muy poco densos. Es decir, entidades con una desproporción muy grande entre el número de atributos posibles y el número de atributos con valor (no nulos).

Entidades en escenarios típicos de este tipo de modelos son, por ejemplo:

documentos (en una base de datos documental) cuyos atributos asignados a cada documento depende de la empresa, departamento, tipo de documento, etc...
información cuya catalogación adicional depende de parámetros definidos por el usuario
conceptos de negocio o abstractos cuyos atributos dependen de varios factores y varían en el tiempo: "expediente", "valoración", "indicencia", etc...

Este modelo se suele resolver sobre el modelo relacional con tres tablas: la de entidad, la de atributos posibles de dicha entidad y la de valores. La información se registra conceptualmente en la tabla de valores, que relaciona la información a través de tres columnas: clave ajena de entidad, clave ajena de atributo y valor.

Incidencia
Id	Fecha
1	17/05/1922:10
2	18/05/1910:13
3	18/05/1917:05

Datos
Id	NombreAtributo
1	Longitud
2	Temperatura
3	Volumen
4	Sector

DatosIncidencia
IdInc	IdDato	Valor
1	1	5
1	4	A
2	2	6
2	3	4
2	4	A

Los problemas que aporta este modelo son:

Consultas SQL complejas (muchos "CASE"), que en algunos casos deben usar herramientas típicas de datawarehouse (PIVOT, crosstab, etc), para convertir en columnas lo que, en realidad, son filas.
Tipo de dato único para todos los atributos, sean numéricos, fechas o cadenas, que luego deberán convertirse, o complicar el modelo con distintas tablas de atributos en función del tipo de dato.

XML y Xpath al rescate
Una buena alternativa a este tipo de problemas es implementar un campo con XML y procesarlo con herramientas XPath. Lamentablemente, el tipo de dato XML de PostgreSQL 8.3 aún no tiene operadores de comparación ni se pueden crear índices sobre este tipo de dato, pero se puede tratar como String y indexar expresiones XPath como veremos a continuación.

La ventaja de usar XML es que podemos contar con un número de atributos variable encapsulados en un documento XML en un sólo campo y evitar tener que usar el modelo EAV, por ejemplo:

Incidencia
Id	Fecha	DatosIncidencia
1	17/05/19 22:10	<data><longitud>5</longitud><sector>A</sector></data>
2	18/05/19 10:13	<data><temperatura>5</temperatura><volumen>4</volumen><sector>A</sector></data>

Con una tabla como la anterior, podemos realizar consultas sencillas con XPath, tipo

SELECT xpath('/data/temperatura/text()', DatosIncidencia)
FROM incidencia

que nos permite un control total en la consulta de atributos sin complicadas consultas. Puede haber quien le parezca que XPath es complicado y que no se gana tanto, pero en mi opinión, es más sencillo tratar con un único campo y una única tabla aunque tengamos que realizar un pequeño aprendizaje de XPath. A la larga, todo es más simple: tanto las consultas como el mantenimiento.

También se pueden optimizar ciertas consultas comunes creando índices, aunque usando algún truco.

El soporte de XML "de serie" en PostgreSQL no ha hecho más que empezar, y le queda un gran camino por recorrer, pero ya estamos en disposición de empezar a aprovecharlo.

Referencias y más información:

XML con PostgreSQL

Banco de experiencias (II): Logback, la evolución de log4j

2009-05-08T19:38:00.013+02:00

Log4j se ha convertido en el estandar de facto para la información de trazado de cualquier proyecto Java. Es una de esas librerías que se añaden a un proyecto prácticamente en el propio proceso de creación del mismo, antes de añadir ninguna clase. Pertenece a ese pequeño y selecto grupo de librerías/frameworks imprescindibles (me lo apunto para una próxima entrada) en cualquier proyecto. Y cuando digo cualquier proyecto, no sólo me refiero a Java. El diseño de la librería y de su estructura es tan bueno, que ha sido portada a multitud de plataformas: el porting de .NET es excelente, y tiene otros muchos más a diversas plataformas.

Sin embargo, a pesar de parecer perfecta y casi inmejorable, tiene un sucesor muy superior: logback. Lo primero que uno percibe al examinar logback es que su diseño y realización está basado en la experiencia con log4j, mejorando algunos pequeños inconvenientes que habían surgido durante su evolución y, sobre todo, respondiendo a las necesidades que han ido surgiendo durante estos casi 10 años de vida, como demuestra Ceki Gülcü, su diseñador, que fue también el fundador de log4j.

Simple Logging Facade for Java
Logback es una implementación de SLF4J (Simple Logging Facade for Java): una capa de abstracción (un façade, como su propio nombre indica) para varios frameworks distintos de logging. SLF4J es el sucesor de Jakarta Commons Logging (JCL), pero mejorado en muchos aspectos. Sin entrar en demasiados detalles, para cualquiera que realice una migración a SLF4J disfrutará, de entrada con 3 mejoras inmediatas:

Se acabaron los problemas con los class loaders, dada su vinculación (binding) estática con la implementación subyacente (con JCL es dinámica en tiempo de ejecución).
Trazado con parámetros mucho más sencillo y eficiente.
Independencia, dado que puedes usar múltiples vinculaciones con sólo añadir otro ".jar" (p.e.: desde "slf4j-simple-x.x.x.jar", para pequeñas aplicaciones que usen System.err hasta "slf4j-log4j12-x.x.x.jar", para servir de puente a log4j.)

Logback
Logback, al ser una implementación sofisticada de SLF4J, disfruta de todas las ventajas de éste y, también sin entrar en sofisticaciones y sólo tocando temas comunes que cualquier usuario habitual de log4j podrá valorar, yo destacaría las siguientes:

Cambios en caliente vía JMX (una maravilla esperada desde hace tiempo). Cuando lo probé casi se me saltan las lágrimas.
Autorecarga en caliente del fichero de configuración. ([ACTUALIZACIÓN 25/08/09]: Apunte realizado por el mismísimo Ceki. Thank you, Ceki. Your visit and comment was an honour).
Uso de variables sustituíbles. Adiós rutas absolutas de ficheros.
Filtros. Aunque lo parezca, no es una funcionalidad sofisticada, se le saca mucha ventaja cuando tienes una aplicación grande y modularizada.
RollingFileAppender tal y como siempre lo hemos querido, con una configuración flexible usando RollingPolicy. ¿No estabas deseando tener un "MaxBackup" en el DailyRollingFileAppender de log4j? Pues ahora tienes MaxHistory en el TimeBasedRollingPolicy... impresionante (¡¡por fin!!)
Layout mejorados, como por ejemplo, que te permiten limitar el tamaño del stack trace en las excepciones de INFO.
De momento no hay un Chainsaw equivalente, pero hay un plugin para eclipse fantástico.
Rendimiento

Migrando desde log4j
Los impacientes que quieran empezar a usarlo migrando un proyecto existente, pueden considerar usar el SLF4J Migrator, muy útil para hacer los cambios en pocos minutos.

Los que hayan usado log4j sin seguir las normas de estilo, como trazar sin mensaje (p.e. log.trace(a), siendo "a" un int, boolean, Exception o cualquier otro objeto) deberán resolver los errores de compilación, ya que SLF4J no soporta esto: deberán poner un mensaje siempre (al fin y al cabo, si no se pone, la traza queda poco legible).

En todo caso, por experiencia, os garantizo que la migración es bastante suave y se puede cambiar un proyecto en pocos minutos.

Fichero de configuración
En log4j me había realizado un fichero de configuración más o menos estándar para entornos de producción que me generaba 3 ficheros:

Uno de nivel INFO. Uno por día, sin borrado automático (lamentablemente no era posible con el DailyRollingFileAppender)
Uno de nivel DEBUG. Fijo por tamaño y con máximo de ficheros
Uno de nivel TRACE. Fijo por tamaño y con máximo de ficheros.

Esta configuración me resultaba muy útil, ya que en caso de incidencia reciente, tenía logs de niveles TRACE y DEBUG de las últimas horas del sistema. El problema es que tienes que ser muy prudente con los tamaños y había que navegar entre varios ficheros para encontrar el momento que buscabas.

He migrado el fichero a logback pero pudiendo disfrutar de las características nuevas: excepciones más cortas en INFO, uno por día en todos los niveles (aunque con menos historia en los niveles más verbosos).

Os dejo el fichero a continuación para que podáis echar un vistazo y adaptarlo a vuestras necesidades.

logback.xml

1 <?xml version="1.0" encoding="UTF-8"?>
 2 
 3 <configuration>
 4   <jmxConfigurator contextName="tkuf2" />
 5   <!-- Se puede establecer el directorio "a mano" o usar el del usuario  -->
 6   <!-- <property name="USER_HOME" value="/home/szarza" />  -->
 7   <property name="USER_HOME" value="${user.home}" />
 8   <property name="appName" value="tk.uf" />

9   <property name="logPath" value="${USER_HOME}/tk2/logs" />
10   <!--
11     1 por día. Nivel INFO. 300 días de historia 
12    -->
13   <appender name="INFO" class="ch.qos.logback.core.rolling.RollingFileAppender">
14     <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
15       <level>INFO</level>
16     </filter>
17     <File>${logPath}/${appName}.log</File>
18     
19     <!-- 5 líneas de stacktrace para las excepciones -->
20     <layout class="ch.qos.logback.classic.PatternLayout">
21       <Pattern>%date %-5level %logger{20} - %message%n %exception{5}</Pattern>
22     </layout>
23     
24     <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
25       <FileNamePattern>${logPath}/${appName}.%d{yyyy-MM-dd}.log</FileNamePattern>  
26       <!-- mantener 300 días de historia -->  
27       <MaxHistory>300</MaxHistory> 
28     </rollingPolicy>
29   </appender>
30   
31   <appender name="DEBUG" class="ch.qos.logback.core.rolling.RollingFileAppender">
32     <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
33       <level>DEBUG</level>
34     </filter>
35     
36     <File>${logPath}/${appName}.d.log</File>
37     
38     <!-- 10 líneas de stacktrace para las excepciones -->
39     <layout class="ch.qos.logback.classic.PatternLayout">
40       <Pattern>%date %-5level %logger{20} - %message%n %exception{10}</Pattern>
41     </layout>
42     
43     <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
44       <FileNamePattern>${logPath}/${appName}.d.%d{yyyy-MM-dd}.log</FileNamePattern>
45       <!-- mantener 10 días de historia -->  
46       <MaxHistory>10</MaxHistory> 
47     </rollingPolicy>
48   </appender>
49 
50   <appender name="TRACE" class="ch.qos.logback.core.rolling.RollingFileAppender">
51     <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
52       <level>TRACE</level>
53     </filter>
54     <File>${logPath}/${appName}.t.log</File>
55     
56     <!-- full stacktrace para las excepciones -->
57     <layout class="ch.qos.logback.classic.PatternLayout">
58       <Pattern>%date %-5level %logger{20} - %message%n</Pattern>
59     </layout>
60     
61     <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
62       <FileNamePattern>${logPath}/${appName}.t.%d{yyyy-MM-dd}.log</FileNamePattern>  
63       <!-- mantener 5 días de historia -->  
64       <MaxHistory>5</MaxHistory> 
65     </rollingPolicy>
66   </appender>
67 
68   <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
69    <layout class="ch.qos.logback.classic.PatternLayout">
70      <Pattern>
71         %date{HH:mm:ss.SSS} %-5level %logger{10} - %message%n
72       </Pattern>
73     </layout>
74   </appender>
75   
76   
77   <logger name="cestel.tk.uf" level="TRACE">
78     <appender-ref ref="INFO"/>
79     <appender-ref ref="DEBUG"/>
80     <appender-ref ref="TRACE"/>
81   </logger>
82   
83   <root level="OFF">
84     <!-- 
85     <appender-ref ref="STDOUT" />
86      -->
87   </root>
88   
89 </configuration>

Oracle: el nuevo gigante rojo

2009-04-20T20:30:00.000+02:00

Aún estoy tratando de asimilar la noticia sorpresa de hoy en la que se anuncia la compra de Sun por parte de Oracle. Debo confesar que estoy sorprendido y no soy de ésos que pueda decir: "me lo esperaba". Desde hace ya mucho tiempo la asociación de ideas que hago con la compañía Sun no es "SPARC", ni "Enterprise 10.000", ni hardware en general... ni siquiera "Solaris". Hace ya mucho, mucho tiempo que asocio Sun a Java, a Glassfish, a JEE, a software empresarial.

Dice McNealy que es la"evolución natural de la relación entre Sun y Oracle". Desde luego lo es en lo que se refiere a hardware. Esta compra de tecnología y cartera de clientes permite a Oracle posicionarse frente a IBM como un nuevo gigante que vende "su software en sus propias máquinas". Justo lo que le faltaba al nuevo gigante rojo (ea, ya tenemos dos gigantes de colores), una perfecta división de hardware para tenerlo (casi) todo: hardware, sistema operativo, software de gestión y almacenamiento en red, bases de datos, servidores de aplicaciones, lenguaje propio, herramientas de desarrollo, etc, etc, etc...

No obstante produce un tremendo vértigo (como comenté en el anterior post) pensar en la tremenda e importantísima cartera de softrware de Sun. Con la adquisición de BEA, Oracle adquirió enorme cantidad de software empresarial asociado a JEE, apoderándose del clásico Rolls Royce de los servidores de aplicaciones (sobretodo por su coste): Weblogic. Y con él, decenas de productos relacionados que son referente en su campo.

Ahora, Sun tiene decenas de productos que colisionan entre sí, en funcionalidad y target de mercado: servidores de aplicaciones, JVM (2), bases de datos, software de virtualización, etc... En la parte que me interesa, es preocupante el destino de productos como Glassfish o Java.

En el caso de Java, supongo que se dará continuidad, ya que Oracle tiene tanto invertido en Java como IBM... El problema es si no arrimará el ascua a su sardina arrinconando la comunidad y haciendo de la tecnología un siervo de su feudo.

El caso de Glassfish es más grave, porque podría estar en peligro realmente. Glassfish es el servidor JEE de referencia, y además es Open Source. Glassfish, además, era EL competidor natural de Weblogic por su calidad, documentación, rendimiento, etc... (desafío a cualquiera a que participe en los comentarios defendiendo a Websphere o JBoss... je,je....). Así que, prácticamente Oracle se queda con el mercado de los servidores de aplicaciones. Oracle se tendrá que enfrentar a mantener dos líneas de producto separadas (¿?) o eliminar una de ellas.
¿Eliminará la que le puede reportar beneficios por licencias? ¿O se quedará con un servidor Open Source con y sin soporte, como tenía Sun?...

En fin, pensando en estas cosas me acordaba de la canción de "No me pises que llevo chanclas" "¿Y tú de quien eres?", que me traía recuerdos de cómo nos identificaban a los chavales en el pueblo. Me acuerdo de eso porque la gente que nos movemos en el mundo del Open Source y de la tecnología Java estamos acostumbrados a elegir. Estamos acostumbrados a la libertad de usar el software que queramos porque hay diversas implementaciones del estandar. Estamos acostumbrados a alinearnos con uno o con otro e incluso de tener ciertos "piques" técnicos entre distintas distribuciones de Linux, herramientas de desarrollo o servidores de aplicaciones. Es natural preguntarnos unos a otros "¿y tú? ¿de quién eres?" sobre nuestra alineación a nuestras preferencias (Netbeans/Eclipse, JBoss/Glassfish/Geronimo, etc...). Esta presunta rivalidad, esta competencia, genera innovación y desarrollo.

La gente que trabaja con la tecnología de Microsoft no tiene estas preocupaciones. Como no las tenían los que vivían resignados en las dictaduras. Sólo hay un fabricante. Sólo una implementación. Son lentejas. No hay participación. No hay competencia. El dictador presenta el producto. El único. Sobre su único sistema operativo. Sobre su única herramienta de desarrollo. Es lo que hay. Te aguantas. El dictador decide la vida del producto y su muerte. Como la monarquía: sólo te resta esperar que el producto heredado mejore, porque nadie puede hacer otro igual: todo viene del mismo sitio y es secreto, oculto, cerrado.

Yo me quedo con mi desazón, como los ateos, con mi mente libre, mi libre albedrío y mi permanente estado de analisis y decisión, con mis sobresaltos, con mis dudas y mis riesgos, emocionantes y vertiginosos, con mi libertad, preguntándome ¿quién se ha llevado mi queso?.

La puesta del sol: Sun en venta

2009-04-19T23:00:00.007+02:00

Marzo ha sido un mes revuelto en lo que a noticias alrededor de Sun se refiere. Primero la oferta de compra por parte de IBM, y días más tarde su retirada, ha puesto al descubierto (para mayor desgracia de Sun) que los problemas financieros de Sun son más graves de lo que parecían. El valor de Sun (que no ha levantado cabeza desde el fin de la burbuja de las puntocom) y su déficit financiero, no pueden hacer frente a la actual recesión sin una salida digna a través de una adquisición. Para IBM, esta operación hubiera mejorado su posición en la competencia con su gran rival HP. Ahora, tras la retirada de IBM, Sun tendrá problemas para encontrar a otro comprador.

Dejando aparte los temas púramente financieros, en estos movimientos hay elementos muy interesantes a analizar y sobre los que reflexionar en lo que a tendencias sobre tecnología y el negocio TIC.

En primer lugar, la cacharrería ya no es (suficiente) negocio. El mercado de hardware de servidores, estaba ya bastante concentrado incluso antes de esta operación, básicamente copado por IBM, Sun (la suma de ambos hubiese superado el 40%), HP y Dell, que últimamente estan centrando su estrategia de expansión en áreas más beneficiosas como la consultoría y servicios (que ofrecen márgenes más amplios).

En segundo lugar, está claro que el negocio de gestión de datos está cambiando a un nuevo concepto de Data Centers. La solución de poner un servidor físico por aplicación o servicio es extremadametnte cara: mantenimiento, soporte, administración, energía... Los servidores rígidos no son una solución rentable. Sería como tener un coche para ir al trabajo, otro para comprar y otro para ir al cine. La tecnología aporta ahora dos soluciones novedosas en este sentido: virtualización y cloud computing. El cloud computing eleva el hardware a la categoría de servicio, o lo que es lo mismo, el modelo SaaS o ASP del software, aplicado al hardware. A la fabricación de máquinas le esta pasando lo que a los reproductores de deuvedés: llegado el momento, es más barato comprarte otro. Parece que los movimientos de Cisco con el UCS, y de IBM con esta operación fuesen en ese sentido: buscar la rentabilidad en servicios. Sun tiene ya bastante avanzado en ese sentido: elementos clave del cloud computing como herramientas de red para datacenter y software de virtualización, que podrían ser de interés para IBM. En el software, esta fórmula se lleva ya aplicando mucho tiempo. Y más, en estos últimos tiempos, en los que se crea negocio de servicios alrededor del Open Source.

Hay también otra reflexión más importante (para mí al menos) en lo que respecta al futuro de la cartera del software de Sun. El que la continuidad de productos como MySQL o VirtualBox pueda estar en entredicho por el cambio de dueño no tiene parangón si hablamos de la tecnología Java y todo el negocio a su alrededor. Ciertamente da cierto vértigo pensar que productos y tecnologías como Java, o Glassfish tengan un futuro incierto....menos mal que ya hace tiempo que son Open Source!

javax.persistence.PersistenceException: No Persistence provider for EntityManager.... SOLUCIONADO

2009-03-22T22:06:00.004+01:00

El otro día tuve que montar a un compañero un entorno para trabajar con un proyecto. El procedimiento, el de siempre: bajar glassfish, bajar eclipse (Ganymede) y hacer el (SVN) checkout oportuno del proyecto. A los pocos minutos ya estaba todo montado... pero me encontré con un problema incomprensible:

Este mismo proyecto (con el mismo código y librerías) estaba funcionando correctamente en dos máquinas, así que era incomprensible. ¡PersistenceManager informa de que no encuentra alguna de sus propias clases!Obviamente no tenía nada que ver con el código, así que, como uno es perro viejo, pensé que tenía que ser de otros factores diferenciadores. Igualé las versiones de Glasfish: nada. Actualizé el JDK: nada.... La única diferencia era que las otras máquinas donde funcionaba correctamente sin problemas (una de ellas, la mía) eran Linux (Kubuntu, para más señas) y ésta era un Haselfroch. Miré en un foro un post que hablaba algo sobre un directorio con acentos, pero no era el caso. Afortunadamente, uno tiene la suerte de trabajar junto a amables compañeros y buenos profesionales que me ayudaron a echar un vistazo, y comenzó eso que viene a llamarse brainstorming, donde cada uno empieza a decir en alto las cosas que observa o se le pasan por la cabeza. Es un metodo infalible: al poco rato ya teníamos una pista. Mirando en la consola de Glassfish aparecían caraceres multibyte en la ruta donde desplegaba la aplicación debido a que había espacios en dicha ruta.

En resumen: la aplicación se había desplegado usando la integración de Glassfish con eclipse (muy buena por cierto), ya que se comporta como si tuviesemos el tomcat embebido: rápida y cómoda. En una instalación por defecto, el eclipse pone el Workspace en el directorio de usuario, que en Haselfroch es C:\Documents and Settings\usuario\... y las aplicaciones se despliegan en dicho workspace. En definitiva, por algún bug extraño de la implementación en Toplink Essentials, el PersistenceManager no encuentra los persistence providers de marras si hay caracteres mutibyte en el path.

Solución: asegurate que tu aplicación (que usa EntityManager) se despliegue en un directorio sin espacios, acentos o caracteres no ASCII. Si estás usando Eclipse y usas Windoze, cambia el workspace de Eclipse a un directorio sin espacios... o mejor, usa Linux (nunca hay que perder la oportunidad de "evangelizar" ;-).

P.D.: Por cierto que Microsoft debería plantearse de una vez por todas dejar de poner por defecto los datos de usuario en una partición por defecto que se suele formatear una vez al año como mínimo y que además, todo el mundo desaconseja usar y así, tomar ejemplo de sus propios usuarios y crear un sencillo "home" (en lugar de "Documents and Settings") en otra partición... fórmula de eficacia demostrada desde hace decenas de años... pero en fin, sería pedir cosas "razonables", que no se yo....

Facelets: el fin de la crisis diseño/desarrollo provocada por JSF

2009-03-17T22:30:00.291+01:00

Típicamente se define Facelets como un sistema de plantillas para JSF al estilo de Tapestry para Struts, pero en realidad la definición se queda pobre y, desde mi punto de vista, no es representativa de sus características más importantes. En este artículo expondré por qué es tan importante y daré las suficientes razones como para que nadie que desarrolle JSF se resista a usarlo.

JSF: La crisis diseño/desarrollo

JSF tiene muchas ventajas para el desarrollo de aplicaciones web, especialmente para las aplicaciones ricas tipo RIA que tengan necesidades de presentación de datos de forma interactivas, ya que nos permite ver las aplicaciones como "formularios" y "componentes" al estilo de las aplicaciones de escritorio y nos oculta todo el engorro de bajo nivel web (POST, GET, trabajo con objetos del contenedor de Servlet directamente, etc,..). Sin embargo, el modelo de desarrollo de JSF requiere un cambio conceptual en los equipos de desarrollo que en algunas ocasiones es duro:

Los desarrolladores que están acostumbrados a una programación lineal tipo scripting (JSP/JSTL, PHP, ASP, etc...) se encuentran ahora con un modelo de componentes con su "ciclo de vida" específico: un elemento bajo otro no necesariamente se interpreta/ejecuta después de otro.
La forma de trabajar clásica era partir de un diseño realizado y "hacerlo dinámico" o al revés, el equipo de diseño/desarrollo toma la aplicación "fea" de desarrolladores y le aplica el diseño. Con JSF esta forma de trabajar es muy complicada y frustrante:

Para aplicar diseño a los componentes hay que conocer los componentes y el modelo de trabajo, así que los diseñadores/maquetadores se encuentran con su pequeño infierno teniendo que pegarse con "cosas de los desarrolladores" que desconocen.
Partir de un diseño y aplicar componentes es igual de frustrante y de poco exitoso. Y justo al igual que en el otro caso, la mayoría de los desarrolladores pierden mucho tiempo en intentar "pegarse" con CSS y "cosas de los maquetadores" que desconocen. Mantener la maquetación y composición que han realizado los diseñadores se convierte en un infierno.

Los controles de layout (panels, tabs, boxes, etc...) son un dolor de cabeza para los maquetadores/diseñadores que se ven obligados a aprender las técnicas de skinning de cada librería de componentes y se encuentran con que es imposible aplicar sus diseños correctamente
Con JSP/JSTL se puede utilizar la reutilización de presentación vía Custom Tag Files y/o includes... pero hacer componentes con JSF es es un verdadero engorro y los f:subviews son imprácticos en la mayoría de los casos.

En definitiva, el ahorro de tiempo en y las ventajas en robustez y legibilidad de la aplicación no acaban de compensar el mayor coste de desarrollo y la inconveniencia de dos equipos de trabajo que han empezado a trabajar incómodos y descoordinados. Así que el uso de JSF parece que se relega a aplicaciones donde el diseño tenga poco peso e importancia, o al menos en favor de la interactividad y la riqueza de la experiencia de usuario, es decir: intranets o aplicaciones de gestión/administración de sistemas.

Facelets al rescate

Desde luego, las aplicaciones donde JSF presta todas sus ventajas son aquellas en las que no es necesario un diseño previo. Para este tipo de aplicaciones el desarrollador puede usar las librerías de componentes existentes para crear interfaces muy usables, funcionales y con un aspecto realmente espectacular para un en entorno web, sin tareas de maquetación y/o diseño adicionales.

Sin embargo hay proyectos en los que se opta por una tecnología más tradicional, como JSTL, para que los desarrolladores, pero especialmente los diseñadores/maquetadores tengan total libertad en el aspecto final de la interfaz, sacrificando las ventajas de la programación con JSF y sus útiles componentes.

Sin embargo, Facelets puede ofrecernos esa libertad sin renunciar a trabajar con un modelo MVC como JSF:

Las páginas con facelets son XHTML, tal cual. Los diseñadores/maquetadores se sentirán tan cómodos como con una página JSTL/JSP, y las herramientas de diseño podrán interpretarlas como HTML que son.
Se puede poner texto, tags HTML y expresiones EL en cualquier parte de la página y Facelets las evaluará correctamente: se acabó tener que usar los engorrosos h:outputText o f:verbatim sólo para poner una propiedad de un bean o un tag HTML. Esto te permite, por ejemplo, que sean los diseñadores/maquetadores los que establezcan el layout de los componentes y su aspecto, y así evitar tener que usar componentes para alinear dos campos o centrar un texto.
Te permite trabajar "al estilo JSTL", es decir, como usando JSP con tags: lo que ponemos "debajo de" se interpretará "después de". Esto es así porque aunque con Facelets se produce un árbol de componentes (no un servlet como con JSP), el árbol de componentes es coherente con el ciclo de vida de JSF.

En definitiva, Facelets te permite trabajar con JSF de una forma más natural, y la curva de aprendizaje para desarrolladores que no hayan trabajado con JSF es mucho más liviana. Con Facelets podemos volver a conciliar la crisis de los equipos de trabajo en los proyectos web, ya que la forma de trabajo vuelve a ser más amistosa con los diseñadores y el modelo de componentes "encaja" de nuevo con una visión orientada a documentos desde el punto de vista del diseño.

Aún hay más

Desde mi punto de vista y en el mundo de desarrollo en el que me muevo, las características comentadas son las más importantes de Facelets, y sólo por ello, ya merecería la pena usarlo. No obstante, Facelets es una tecnología de "Vista" específicamente diseñada para JSF, así que nos depara muchas gratas sorpresas funcionales extremadamente interesantes:

Plantillas. Facelets es un sistema de plantillas con JSF en mente, lo que nos permite acelerar el desarrollo enormemente con la misma facilidad y enfoque con el que se puede considerar a JSP un sistema de plantillas para servlets (el cuerpo de una JSP acaba siendo el método jspService()).
Desarrollo cero para componentes. Hacer un componente JSF (o "componentizar" un trozo de una página) es tan simple como extraerlo en un fichero aparte. Facelets es a los componentes JSF lo que fueron los Custom Tag Files a JSP 2.0. Una maravilla.
Informes de errores precisos. El tiempo que tarda un desarrollador JSF en interpretar los ininteligibles mensajes de error es indirectamente proporcional a sus "horas de vuelo". Los mensajes de error nunca indican en qué componente, y menos aún en qué línea se ha producido. Es un proceso de adivinación a base de leer las decenas de líneas del Stack trace. Con Facelets tenemos por fin errores precisos sobre la línea, tag y atributo donde se ha producido. Otra de ésas razones por las que merecería la pena usarlo, aunque fuese la única.

Conclusiones

Facelets se debe añadir por defecto a cualquier proyecto JSF, aunque no se vayan a hacer componentes ni plantillas. Usar HTML y tener errores informados son razones suficientes para incorporarlo siempre. De hecho se añadirá al estándar en JSF 2.0.

Más información:
https://facelets.dev.java.net/
http://wiki.java.net/bin/view/Projects/Facelets
http://www.ibm.com/developerworks/java/library/j-facelets/
https://facelets.dev.java.net/nonav/docs/dev/docbook.html

Banco de experiencias (I): JSF con Apache Myfaces Trinidad

2009-03-17T22:04:00.003+01:00

Apache Myfaces Trinidad es uno de los frameworks JSF open source más completos y sólidos actualmente. Son el resultado y la evolución de la donación de Oracle ADF Faces por parte de Oracle a la ASF. Es el más completo, estable y probado de los 3 de Apache, con una solidez demostrada con el paso de los años (es tan antiguo que usaba Ajax antes de lo llamaran Ajax, sino PPR -Partial Page Rendering-).

Por su envergadura y características, está en el grupo de "los grandes": frameworks multipropósito con enorme catálogo de componentes y características avanzadas (Ajax, templating, skinning, etc...). Otras compañeras de grupo de élite de frameworks/librería de componentes JSF son:

~~Woodstock~~ (abandonado por Sun en favor de ICEfaces... uno menos)
ICEfaces
Oracle ADF Faces RC
JBoss RichFaces (ex ajax4jsf)

Como ventajas importantes de Trinidad destacaría:

Es compatible con otras librerías de componentes, como Tomahawk.
Se integra perfectamente con Facelets (de hecho, no sólo son un tándem perfecto, sino que no concibo JSF sin Facelets)
Tiene decenas de componentes y te permite hacer una aplicación "rica" de una forma cómoda. A destacar el tr:table. Sólo por ese componente merece la pena usarlo. Si tienes que presentar tablas de información interactivas, es la mejor forma.
Ha demostrado funcionar razonablemente bien en aplicaciones de producción y tiene un desarrollo y evolución constante.

Eso sí, Trinidad adolece de inconvenientes propios además de los comunes a este tipo de frameworks:

La documentación deja bastante que desear
Para que tenga un aspecto decente hay que prepararle un skin o, directamente usar los componentes de Oracle ADF Faces, que ya traen uno impecable.

En definitiva, a falta de probar en condiciones ICEfaces, es una estupenda alternativa en los siguientes casos:

Aplicación extranet tipo RIA (o al menos necesidad de "rich controls") y pilotamos de CSS o tenemos alguien en el equipo que pilota. En cualquier caso procura evitar los controles de layout (panels, tablas, etc...)
Aplicación intranet RIA. Si no tenemos a maquetadores web en el equipo y te gusta el skin por defecto de Oracle, puedes usar directamente la implementación de Oracle.

Hay una interesante tabla comparativa de las distintas liberías de componentes en http://www.jsfmatrix.net.

Banco de experiencias (introducción)

2009-03-16T00:42:00.003+01:00

Con este título, "Banco de experiencias", iré realizando (eso intentaré al menos, aunque aún no sé con qué frecuencia) aportaciones de mis experiencias en situaciones reales (no en laboratorio) y/o de sistemas en producción, probados en el mundo real.

Uso "banco de experiencias" como paráfrasis contrapuesta a "banco de pruebas", ya que ésto último, las pruebas, son el pan de cada día y sufrimiento diario de todos los arquitectos y desarrolladores de software. Y es que, a pesar de la cantidad de horas de desarrollo y buenas prácticas que tengamos encima, siempre tenemos la sensación de estar frente a algo nuevo. Y en realidad no es una sensación. Es la realidad. No hay dos sistemas iguales: siempre tienes que integrar con algo nuevo, siempre te encuentras que, cuando vas a hacer la instalación en producción resulta que el cliente no te había contado algo o que, simplemente, ni se te pasó por la cabeza y aparece algún elemento "metiendo ruido" como sacado de una chistera de repente.

El problema de la ingeniería del software, y del desarrollo, es que no se trabaja con materiales precisos, ni tenemos formas de medir objetivamente parámetros y tolerancias de los sistemas que nos permitan asegurar un mínimo de calidad. Además, contruimos sistemas "sobre" y/o "cooperativos" (sic) con otros (sean hardware o software) de los que no podemos tener mínimas garantías (y así lo podemos encontrar de forma expresa en las licencias de software privativo), con lo que no podemos garantizar tampoco el que construimos nosotros (suponiendo que pudiésemos).

Así, la "alta disponibilidad" se consigue, no garantizando sistemas que no fallen, sino garantizando que, cuando fallen (que lo harán) habrá otro sistema para ocupar su lugar. Un concepto éste, el de la "redundancia", ampliamente usado por los distintos generales de infantería de todos los ejércitos durante la historia. Ojalá pudiésemos implementar "alta disponibilidad" en el cuerpo humano a base de redundar el corazón, el cerebro...

En el mundo JEE, por ejemplo, me he encontrado muchas veces que una aplicación construida por nosotros tiene una falla inexplicable. Tras muchas pruebas y averiguaciones nos encontramos con un bug del servidor de aplicaciones o de la JVM...Los indicadores de ese tipo de fallos, así como los de los nuestros propios, y las soluciones aportadas nos van generando un conocimiento empírico, procedimental, que sedimenta formando lo que algunos llaman "expertise" o sabiduría. Por eso, los fallos que suele tener un programador novato no suelen ser los mismos que un programador experimentado. Los desarrolladores experimentados, como decía unamuno, comienzan a dar en el clavo porque han dado ya muchas veces en la herradura. Y digo bien: "experimentado". No todos los desarrolladores experimentados son expertos.

Dijo Aldous Huxley, que "La experiencia no es lo que te sucede, sino lo que haces con lo que te sucede". Y es cierto que hay unos pocos experimentados que acaban convirtiendo el error en experiencia, y son capaces de mezclar la experiencia propia y la ajena con su propia intuición creativa: ésos son los expertos (algún día tendré que hablar largo y tendido sobre el tremendo componente creativo que tiene el desarrollo de software, a pesar de lo que muchos puedan pensar).

La ventaja del mundo del software frente a nuestra vida cotidiana es que en lo que respecta al primero sí podemos aprovecharnos y aprender de la experiencia ajena: no hace falta que suframos el mismo problema que otro durante 20h hasta encontrar la solución, podemos ahorrarnos 19,5h si el otro nos cuenta su experiencia y nosotros la recordamos en ese momento.

De hecho, los patrones de diseño (una de las herramientas imprescindibles de cualquier desarrollador) no son más que un catálogo de experiencias resumidas: los problemas y sus soluciones aplicadas y comprobadas.

Hasta ahora he sido un usuario "pasivo" de esto de la blogocosa.... Pero creo que me toca ahora agradecer la generosidad de otros uniéndome a ellos, participando, compartiendo y aportando "my two cents" al acceso del conocimiento común y de la experiencia colectiva a través de mis propias experiencias y así, asumir mis propias disfunciones metacognitivas (gracias, Sr. Galli, por el magnífico artículo).

"Sólo una cosa es más dolorosa que aprender de la experiencia, y es, no aprender de la experiencia" (Laurence Johnston Peter, 1919-1990, Profesor y escritor canadiense).

UIXCollection$Transient cannot be cast to [Ljava.lang.Object; SOLUCIONADO

2009-03-06T14:30:00.029+01:00

Llevo dos días perdidos con ese error. Al final he conseguido resolver el enigma. El contexto es el siguiente:

Aplicación JSF usando MyFaces Trinidad (ocurre tanto con trinidad 1.2.10 como con 1.2.11)
Servidor Glassfish v2.1
Una página (jspx) con una tabla (tr:table) presentando datos. Desde esa página (la primera petición funciona) realizo lo siguiente:

pulso en cualquier command o link
pulsar botón atrás del navegador (volvemos a la página con la tabla)
pulso en cualquier otro command o link de la página ==> crash

El log del servidor es inservible a efectos de descubrir la razón del problema:

GRAVE: StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception java.lang.ClassCastException: org.apache.myfaces.trinidad.component.UIXCollection$Transient cannot be cast to [Ljava.lang.Object; at org.apache.myfaces.trinidad.component.StampState.restoreChildStampState(StampState.java:204) at org.apache.myfaces.trinidad.component.UIXTable.restoreStampState(UIXTable.java:426)<br /> at org.apache.myfaces.trinidad.component.UIXCollection._restoreStampState(UIXCollection.java:1336) at org.apache.myfaces.trinidad.component.UIXCollection.postRowDataChange(UIXCollection.java:745) at org.apache.myfaces.trinidad.component.UIXCollection.setRowIndex(UIXCollection.java:441) at org.apache.myfaces.trinidad.component.UIXTable._processStamps(UIXTable.java:517) at org.apache.myfaces.trinidad.component.UIXTable.processFacetsAndChildren(UIXTable.java:374) at org.apache.myfaces.trinidad.component.UIXCollection.decodeChildrenImpl(UIXCollection.java:196) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974) at org.apache.myfaces.trinidad.component.UIXCollection.processDecodes(UIXCollection.java:190) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:988) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:988) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:988) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:988) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:988) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:988) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:988) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974) at org.apache.myfaces.trinidad.component.UIXForm.processDecodes(UIXForm.java:75) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:988) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1001) at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:493) at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at cestel.tk.uf.filter.SessionExpireFilter.doFilter(SessionExpireFilter.java:99) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)

Buscando en google encontré esto que me dió la pista y probé a borrar el comentario que tenía inmediatamente después del <tr:table> y... ¡ bingo !.
Era eso. El error sigue estando en páginas jspx incluso en versiones muy posteriores a las comentadas, así que se ve que no está solucionado (aún).

En definitiva: no pongas comentarios dentro de un tr:table.
Espero que este post sirva para ahorrar tiempo a algún otro sufridor.