miércoles, 23 de diciembre de 2009

La UE aprueba finalmente la adquisición de Sun

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

jueves, 3 de diciembre de 2009

Manifiesto en defensa de los derechos fundamentales en internet


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.



domingo, 22 de noviembre de 2009

Magnitudes astronómicas

"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)


jueves, 1 de octubre de 2009

La falacia de la Ingeniería del Software

A partir de los años 70 comenzó a desarrollarse lo que, en 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 pesadas y burocráticas metodologías y análisis de negocio según las 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 frustrados en sus primeros proyectos laborales por dos razones: la primera, porque la metodología aprendida ya estaba desfasada, y la segunda porque 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á, o de que esta sí es la "bala de plata" definitiva, aunque su éxito real sea anecdótico.

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 adornadas con estadísticas, algunas 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 siquiera 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 para que éste sean sistemático, predecible y repetible. Hoy sabemos que las métricas y el control de calidad cuestan mucho tiempo y dinero... y 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 esencial: no es lo mismo repetir con un equipo que ya ha trabajado junto que con un equipo nuevo... no es lo mismo un equipo de doce programadores inexpertos que otro de 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, 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)
  • La raíz de la precariedad en informática. Interesantísimo y revelador artículo sobre las consecuencias de la concepción "taylorista" del proceso de desarrollo de software y de la consideración de la programación como proceso de construcción en lugar de proceso de diseño.
  •  [1] El ensayo comprometido y crítico de Dijkstra es demoledor. En castellano, aquí.

martes, 8 de septiembre de 2009

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

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?

    jueves, 27 de agosto de 2009

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

    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.

    lunes, 27 de julio de 2009

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

    http://www.flickr.com/photos/nickwheeleroz/2475011402/in/photostream/

    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:
    1. 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.
    2. 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.
    3. 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:
      1. 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.
      2. 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).
    4. 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.
    5. 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.
    6. 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.
    7. 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.
    8. 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ó.

    jueves, 16 de julio de 2009

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

    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.

    martes, 14 de julio de 2009

    Líala parda

    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.

    miércoles, 17 de junio de 2009

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

    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.

    viernes, 5 de junio de 2009

    Sideralis: un Stellarium en tu móvil

    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, 400 años atrás, no creo que se imaginara que llegaríamos a tener un planisferio luminoso 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.

    miércoles, 20 de mayo de 2009

    Open Source BRE/BRMS JSR-94 compliant

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

    lunes, 18 de mayo de 2009

    Alternativas EAV con XML (en PostgreSQL 8.3)

    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/19 22:10
    2 18/05/19 10:13
    3 18/05/19 17: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:

    viernes, 8 de mayo de 2009

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

    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:

    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>
    
    
    Related Posts Plugin for WordPress, Blogger...
    cookieassistant.com