Un pequeño apunte, ya disponemos de grupos en LinkedIn para Port@l 3.0 y GeNews.
Nos vemos por allí.
miércoles, 28 de abril de 2010
lunes, 15 de marzo de 2010
HL7. Ya hemos aprendido algo más.
La semana pasada he asistido a un taller sobre HL7 (mensajería v2.6 y CDA R2) impartido en Sevilla por Álvaro Domínguez bastante interesante.
Para quien no lo sepa, HL7 es una organización de carácter internacional (HL7 Spain es una localización de la organización) y una serie de estándares que organizan el formato de los datos y el intercambio de información entre diferentes sistemas de información de salud.
Por lo que he podido ver en estas semanas, HL7 es un mundo que puede alcanzar un nivel de complejidad tan grande como se quiera ("puedes tardar más de dos semanas en modelar un mensaje"). Por suerte, existen algunos proyectos Java Open Source que vienen a facilitarnos la tarea,
Mirth, una familia de productos para el desarrollo, despliegue, pruebas, almacenamiento, etc. Un motor que permite el intercambio de mensajes entre sistemas y aplicaciones.
Open eHealth Integration Platform (IPF), una extensión de Apache Camel, que proporciona una capa de desarrollo basada en Groovy.
HAPI, un parseador para HL7.
NULE, un conjunto de herramientas y librerías para trabajar con HL7.
Y Open Healthcare Framework, subproyecto de Eclipse (gracias Andrés).
Para quien no lo sepa, HL7 es una organización de carácter internacional (HL7 Spain es una localización de la organización) y una serie de estándares que organizan el formato de los datos y el intercambio de información entre diferentes sistemas de información de salud.
Por lo que he podido ver en estas semanas, HL7 es un mundo que puede alcanzar un nivel de complejidad tan grande como se quiera ("puedes tardar más de dos semanas en modelar un mensaje"). Por suerte, existen algunos proyectos Java Open Source que vienen a facilitarnos la tarea,
Mirth, una familia de productos para el desarrollo, despliegue, pruebas, almacenamiento, etc. Un motor que permite el intercambio de mensajes entre sistemas y aplicaciones.
Open eHealth Integration Platform (IPF), una extensión de Apache Camel, que proporciona una capa de desarrollo basada en Groovy.
HAPI, un parseador para HL7.
NULE, un conjunto de herramientas y librerías para trabajar con HL7.
Y Open Healthcare Framework, subproyecto de Eclipse (gracias Andrés).
viernes, 12 de marzo de 2010
Cómo romper dependencias cíclicas entre paquetes.
Sonar, con su versión 2.0, viene a cubrir todas las necesidades de control de la calidad de los proyectos de desarrollo; proporcionando además, herramientas sufientes para solucionar los problemas encontrados.
Ya hemos comentado con anterioridad las ventajas de utilizarlo, que son muchas pero, con la nueva versión podemos incluso localizar con facilidad dónde se encuentran las dependencias cíclicas de tu código.
Por ejemplo, echando un vistazo al código de Apache Jackrabbit en su versión 2.1 de desarrollo,
podemos observar que éxisten dependencias entre paquetes.
También sabemos cuántos ciclos existen, 264, y el número de dependencias entre paquetes y entre ficheros a romper, 99 y 329 respectivamente.
Pulsando sobre los datos nos mostrará la matriz de dependencias,
donde buscaremos las que debemos romper, representadas con color rojo.
Bien, hasta aquí podríamos haber utilizado otras herramientas más comunes como JDepend pero, ¿cómo puedo saber cuáles ficheros tengo que tocar? Simplemente doble click sobre la celda de color rojo y nos mostrará los ficheros implicados.
A partir de aquí, puedes empezar a refactorizar.
Más información en,
http://sonar.codehaus.org/
http://nemo.sonarsource.org/
http://nemo.sonarsource.org/project/index/org.apache.jackrabbit:jackrabbit
http://nemo.sonarsource.org/drilldown/measures/org.apache.jackrabbit:jackrabbit?metric=package_cycles
http://nemo.sonarsource.org/drilldown/measures/org.apache.jackrabbit:jackrabbit?metric=package_cycles&rids[]=32189
Ya hemos comentado con anterioridad las ventajas de utilizarlo, que son muchas pero, con la nueva versión podemos incluso localizar con facilidad dónde se encuentran las dependencias cíclicas de tu código.
Por ejemplo, echando un vistazo al código de Apache Jackrabbit en su versión 2.1 de desarrollo,
podemos observar que éxisten dependencias entre paquetes.
También sabemos cuántos ciclos existen, 264, y el número de dependencias entre paquetes y entre ficheros a romper, 99 y 329 respectivamente.
Pulsando sobre los datos nos mostrará la matriz de dependencias,
donde buscaremos las que debemos romper, representadas con color rojo.
Bien, hasta aquí podríamos haber utilizado otras herramientas más comunes como JDepend pero, ¿cómo puedo saber cuáles ficheros tengo que tocar? Simplemente doble click sobre la celda de color rojo y nos mostrará los ficheros implicados.
A partir de aquí, puedes empezar a refactorizar.
Más información en,
http://sonar.codehaus.org/
http://nemo.sonarsource.org/
http://nemo.sonarsource.org/project/index/org.apache.jackrabbit:jackrabbit
http://nemo.sonarsource.org/drilldown/measures/org.apache.jackrabbit:jackrabbit?metric=package_cycles
http://nemo.sonarsource.org/drilldown/measures/org.apache.jackrabbit:jackrabbit?metric=package_cycles&rids[]=32189
jueves, 25 de febrero de 2010
Portal3.0, Liferay5.2.3CE, GateIn3.0
Va llegando el momento de ir mostrando características de tres productos con similares orientaciones y funcionalidades. Los tres están pensados para lo mismo, construir portales de forma más o menos sencilla y modular, con dos diferencias fundamentales:
El por qué de estas diferencias es sencillo, Portal3.0 no integra un gestor de contenidos porque existen muchos WCM/DCM/CMS más capaces que los que proporcionan el resto soluciones. Portal3.0 no es una implementación de Portlets porque ya existen (Liferay y GateIn son un gran ejemplo).
En próximos post expondré las razones de ambas diferencias, repasando por qué Portal3.0 no implementa Portlets y por qué no integra un gestor de contenidos.
- Tanto Liferay como GateIn incorporan un pequeño gestor de contenidos. Portal3.0 no lo hace.
- Liferay incorpora un pequeño gestor de contenidos. Ni Portal3.0 ni GateIn lo hacen.
- Tanto Liferay como GateIn son implementaciones de JSR-168 (Portlets1) y de JSR-268 (Portlets2). Portal3.0 no lo implementa.
El por qué de estas diferencias es sencillo, Portal3.0 no integra un gestor de contenidos porque existen muchos WCM/DCM/CMS más capaces que los que proporcionan el resto soluciones. Portal3.0 no es una implementación de Portlets porque ya existen (Liferay y GateIn son un gran ejemplo).
En próximos post expondré las razones de ambas diferencias, repasando por qué Portal3.0 no implementa Portlets y por qué no integra un gestor de contenidos.
martes, 23 de febrero de 2010
Portal3.0
Desde hace algunos posts vamos anunciando proyectos en los que se utiliza Portal3.0 como motor de ejecución, herramienta de administración y marco de trabajo. No voy a entrar en detalles aún pero, algunos detalles curiosos.
Struts2, 79.396 líneas de código, 1.145 clases, 2,7 de complejidad media por método, 17,4 de complejidad media por clase, 19.908 de complejidad, 20,1% de comentarios, y un 26,2% de cobertura de código.
Portal3.0, 83.597 líneas de código, 1.803 clases, 1,7 de complejidad media por método, 8,6 de complejidad media por clase, 15.560 de complejidad, 23,4% de comentarios, y un 27,4% de cobertura de código.
GateIn - Portal, 75.774 líneas de código, 1.274 clases, 2,6 de complejidad media por método, 10,5 de complejidad media por clase, 13.399 de complejidad, 8,4% de comentarios, y un 40,1% de cobertura de código.
Portal3.0 ha alcanzado un grado de madurez importante :-)
Struts2, 79.396 líneas de código, 1.145 clases, 2,7 de complejidad media por método, 17,4 de complejidad media por clase, 19.908 de complejidad, 20,1% de comentarios, y un 26,2% de cobertura de código.
Portal3.0, 83.597 líneas de código, 1.803 clases, 1,7 de complejidad media por método, 8,6 de complejidad media por clase, 15.560 de complejidad, 23,4% de comentarios, y un 27,4% de cobertura de código.
GateIn - Portal, 75.774 líneas de código, 1.274 clases, 2,6 de complejidad media por método, 10,5 de complejidad media por clase, 13.399 de complejidad, 8,4% de comentarios, y un 40,1% de cobertura de código.
Portal3.0 ha alcanzado un grado de madurez importante :-)
lunes, 22 de febrero de 2010
Una más, Consejería de Cultura de la Junta de Andalucía
Desde hace unas semanas está funcionando el nuevo portal institucional de la Consejería de Cultura de la Junta de Andalucía, pero no fue hasta la pasada cuando fue presentado oficialmente por la Consejera Rosa Torres.
En esta ocasión, utilizamos Portal3.0 para la presentación y la administración de la web, OpenCms para la gestión de contenidos, Google Maps para el Mapa de Centros, y un fuerte trabajo en la integración de los sistemas de información de la Consejería.
Más información sobre la web y la presentación en:
Un nuevo caso de éxito para Portal3.0, desarrollado por Isotrol SA.
En esta ocasión, utilizamos Portal3.0 para la presentación y la administración de la web, OpenCms para la gestión de contenidos, Google Maps para el Mapa de Centros, y un fuerte trabajo en la integración de los sistemas de información de la Consejería.
Más información sobre la web y la presentación en:
Un nuevo caso de éxito para Portal3.0, desarrollado por Isotrol SA.
jueves, 11 de febrero de 2010
Mercurio. Plataforma Multimedia Extremeña.
Ayer 10 de Febrero de 2010 fue presentada la web Mercurio (http://mercurio.educarex.es) por la Consejera de Educación de la Junta de Extremadura, Eva María Pérez.
Sin profundizar en exceso, ha sido desarrollado con tecnología Java, Portal3.0 para la web, GWT para la herramienta de administración y catalogación de recursos basada en LOM-ES, un repositorio de objetos digitales para su almacenamiento, ffmpeg para la codificación de vídeo y Red5 para su emisión en directo.
Más información sobre la web y la presentación en:
Esta será la primera de las entradas en las que iré presentando los proyectos en los que trabajo de una u otra manera. El siguiente en breve :-)
Actualización: Gracias Ráez, Red5 para la emisión.
Sin profundizar en exceso, ha sido desarrollado con tecnología Java, Portal3.0 para la web, GWT para la herramienta de administración y catalogación de recursos basada en LOM-ES, un repositorio de objetos digitales para su almacenamiento, ffmpeg para la codificación de vídeo y Red5 para su emisión en directo.
Más información sobre la web y la presentación en:
Esta será la primera de las entradas en las que iré presentando los proyectos en los que trabajo de una u otra manera. El siguiente en breve :-)
Actualización: Gracias Ráez, Red5 para la emisión.
Suscribirse a:
Entradas (Atom)