indizen blog

La reunión anual de la Sociedad Nuclear Española, ha tenido lugar en Cáceres en los días 16 al 19 de octubre.  Con más de 600 profesionales del sector, y la presentación de más de 300 ponencias con la exposición de los últimos avances realizados por la industria española. Este año, el equipo de indizen energía ha acudido, una vez más como en otros años, presentando en este caso dos ponencias y un póster.

La primera ponencia, estuvo a cargo de Ivan Fernández, en la sesión de I+D y lleva como nombre:  “Herramientas de Integración de Análisis Probabilista (PSA) y Determinista (DSA) de Seguridad” y en la ponencia, se presentaron las principales líneas futuras de los trabajos del departamento en el desarrollo de la plataforma de Sistema de Códigos de Simulación para el Análisis Integral de Seguridad, SCAIS.  Además se presentan un primer borrador de los resultados que estqamos encontrando en el trabajo conjunto con el Departamento de Sistemas Energéticos de la Escuela Superior de Ingeniería de Minas de la UPM.

La segunda ponencia y el póster, versan sobre el análisis de seguridad aplicado a todo el espectro LOCA sin criterios de éxito: “Dynamic Event Trees without Success Criteria. Application to Full Spectrum LOCA sequences. Calculation of Damage Exceedance Frequency with Integrated Safety Assessment (ISA) Methodology”. 

 Esta exposición realizada por Javier Magán, ha resultado ganadora del premio a la mejor ponencia en  Seguridad Nuclear.

Damos la enhorabuena a Javier por su magnifico resumen y exposición de los trabajos, que ha sido gratamente reconocida por  los asistentes a esta reunión.  En la foto en el acto de clausura.

El póster, que recopilaba la ponencia de Javier y los principales resultados, y que podemos ver aquí una imagen de él,  estuvo accesible a los profesionales durante todo el congreso con gran interés para los profesionales de nuestra área de trabajo.

Aquí podemos ver al equipo de indizen y nuestros colaboradores de la UPM en la sección de pósters:

A mediados del pasado mes de febrero asistimos en la Universidad CEU San Pablo en Boadilla a unas conferencias de desarrollo, las tercera edición del  Spring I/O. Algunos temas y tecnologías de las que se hablaron fueron Spring, Groovy/Grails y Cloud. Os dejamos nuestras impresiones en el siguiente resumen:

ApplicationDevelopment in the Cloud Era

• Mobile first: cuando se desarrollan sitios para Internet, especialmente de alto tráfico, se recomendó primero diseñar el sitio para dispositivos móviles y después hacer el diseño web 
• Elasticidad de una aplicación web: Antes se buscaba que los sistemas fueran escalables, implementados de tal manera que con el paso del tiempo se fuesen aumentando los recursos. A día de hoy se suele priorizar que el sistema pueda crecer en situaciones puntuales para luego volver al estado inicial (ej: campañas navideñas). Una de las soluciones para esto es Amazon WS.
• Web layer vs Servicelayer: lo ideal sería tener interfaces web desarrollados en HTML5 y javascript (jQuery, wire.js) con controladores y vistas que hacen peticiones http a la capa de servicios, que devuelve un JSON que puede ser interpretado tanto por navegadores web como por dispositivos móviles. Esta comunicación se realiza mediante websockets y servicios web Rest (pej: Jersey,  Spring MVC,  Grails)

Rapid development of enterprise web applications

• Grails es un framework web construido sobre Spring MVC e Hibernate. 
• Se definen las constraints en clases Groovy (unicidad, no nulos, relaciones entre objetos…) y a partir de ahí se genera automáticamente el esquema de base de datos  (tablas) y el código web (vistas, controladores, acceso a base de datos). En cuanto a relaciones tenemos algo similar en Java con Spring Data JPA. 
• Tiene muchos plugins, entre los más destacados: Maven, DatabaseMigrationPlugin (gestión del cambio entre versiones de BD), Mybatis, Reverse EngineeringPlugin (para construir la aplicación a partir de un modelo de datos existente, en lugar de a partir de clases  Groovy)

Fallando con Grails

• Desarrollar aplicaciones web no es una tarea fácil, pero Grails facilita mucho los primeros pasos del desarrollo. 
• La integración continua ha de ser una actitud del equipo de desarrollo. La mejor manera de profundizar en esta actitud es utilizar las TDD (Test DrivenDevelopment) 
• También es importante tener en cuenta que en todo trabajo en equipo vas acabar trabajando como trabajan tus compañeros. En el mundo de la programación se ve mucho esto. Si tu código no está cuidado tu compañero tampoco lo va a cuidar.  “La teoría de la ventana rota” fue llevada al mundo de la programación  Andrew Hunt and David Thomas, ThePragmaticProgrammer Addison Wesley,1999

Spring Data y MongoDB. Un caso de uso real

• Para elegir cuándo utilizar una base de datos relacional o Nosql (MongoDB en este caso) es útil el teorema CAP (Eric Brewer). En los casos en los que se prioriza la consistencia y la tolerancia a fallos se recomendó el uso de Nosql
• En  MongoDB,  las consultas complejas pueden simplificarse mediante el uso de Spring Data

UsingGrails in a Startup

• Se destacó el uso de git-flow para una gestión más ágil de branches/merges
• Google WebsiteOptimizer: permite validar los diseños más eficaces de un sitio web

Comparing JVM Web Frameworks

      Para hacerse una idea de la posición de JSF respecto a otros frameworks como  Spring MVC,  Grails o GWT:

• Java EE ProductivityReport 2011
• Comparing JVM Web Frameworks

NoRedeploys: Instantupdates in dev and prod

• JRebel parece un producto interesante para evitar tener que reiniciar el Tomcat durante el desarrollo. Sus creadores afirman que mejora alrededor de un 15% la productividad de un programador

Natural templating in Spring MVC withThymeleaf

• Thymeleaf es un motor de plantillas si estás utilizando  Spring MVC. Tiene una estructura elegante y la internacionalización es más intuitiva que en los jsps.
• Permite probar la interfaz sin necesidad de tener la aplicación desplegada en ningun sitio. Opción muy cómoda para diseñar prototipos de las pantallas sin necesidad de tener toda la lógica implementada.

Otros:

• PaaS: Heroku, Cloudfoundry
• Slides: Coverage of Spring I/O 2012

Juanvi Soler y Juan Roa

Ponente: Javier Fernández Valencia, Ingeniero Jefe del proyecto ITS (Integrated Terminology System)

Título: El papel de los servidores terminológicos en la historia clínica electrónica

Fecha: 21 Marzo,  Hora: 14:40 – 14:55

Lugar:  Sala 1 - Soluciones Tecnológicas

Resumen Integrated Terminology System (ITS)

Resumen:

Hoy en día, pese a los grandes avances tecnológicos de las últimas décadas, aun se sigue almacenando  la información clínica electrónica en texto libre.

Muchos hospitales y centros de atención primaria mantienen listas locales de términos en CIE 9MC/SNOMED CT que a menudo están desactualizados o no son interoperables.

Las organizaciones sanitarias innovadoras se han dado cuenta de los grandes beneficios que puede reportar el almacenar la información de forma sistematizada, estructurada e interoperable. Es por esto que muchas de estas organizaciones hayan realizado grandes esfuerzos con el fin de normalizar la información clínica de los pacientes. Una de las estrategias más común por su parte es la creación de subconjuntos locales de una terminología en concreto, normalmente divididos por especialidades o áreas. Sin embargo, para crear una base solida con la que almacenar la información es necesario gran cantidad de recursos y los esfuerzos locales van destinados en general a ciertas especialidades o áreas en concreto.

Por esto se hace necesario un sistema común en el que centralizar los esfuerzos y normalizar la información. Dichos sistemas son denominados servidores de terminología y en general constan de dos partes fundamentales:

• Parte cliente: Interfaz que permite la búsqueda de términos, creación/edición /visualización de subconjuntos y edición/visualización de mapeos con diferentes terminologías.
• Parte servidor: API y WS con la que puede comunicarse la parte cliente u otros sistemas externos.

Gracias a los servidores de terminología es posible aunar los diferentes esfuerzos locales para generar subconjuntos de mayor calidad y trabajar con terminologías actualizadas y validadas.

En la ponencia se detallarán las principales características de los diferentes servidores de terminología existentes, así como sus ventajas/desventajas, estándares utilizados, grados de evolución, formas de integración y expectativas de futuro, y se mostrará nuestra solución ITS (Integrated Terminology System) como alternativa cercana, ágil y adaptable a las necesidades de las organizaciones sanitarias Españolas.

Más información:

Resumen Ejecutivo de  ITS

Si te quieres registrar o ver más información sobre en ITS

Soluciones de Indizen para el sector Sanitario

El Karlsruhe Institute of Technology es uno de los centros tecnológicos más avanzados de Alemania.
Lo componen más de 140 áreas y 5000 científicos y a pesar del brusco cambio de rumbo en su política nuclear, es todavía un referente mundial en el ámbito de tecnología nuclear.

El pasado 9 de febrero fuimos allí para ofrecer en el ‘Institute for Neutron Physics und Reactor Technology’ (INR) un seminario sobre la metodología que utilizamos para el acoplo de códigos con los casos de éxito desarrollados.
Fuimos invitados a un ciclo de conferencias que se imparten en el instituto semanalmente por el director del departamento de Física de reactores Victor Hugo Sánchez Espinoza, al cual conocimos hace ya varios años y se había interesado mucho por nuestro trabajo.

Un resumen sucinto de la presentación que hicimos sería;

SCAIS es un proyecto para el Consejo de Seguridad Nuclear, basado en una serie de ideas que vienen desarrollando desde hace más de 35 años, en el que se integran teorías probabilistas de seguridad con las simulaciones de la dinámica de los accidentes.
Este estudio nos da una visión mucho más completa sobre la seguridad de las centrales que los estudios clásicos que se hacen por separado, ya que en los probabilistas se hacen asunciones a priori y se utiliza el juicio de expertos, y, en los estudios de la dinámica, no se hacen cálculos de probabilidad y son púramente deterministas.

Este tipo de metodologías están empezando a surgir con fuerza durante los últimos años y, parece que van a ser muy importantes en un futuro inmediato. Gracias a los años de experiencia y desarrollo, contamos con una de las herramientas más avanzadas del mundo en este tipo de estudios.

La presentación se enfocó después en los componentes de SCAIS para el estudio de la dinámica, y especialemente en la metodología de acoplamiento de códigos al sistema, ya que son los puntos que consideramos tenían más interés para el público que asistió.
La metodología que utilizamos de acoplamientos fue lo que más les llamó la atención, y es que ellos son expertos a nivel mundial en el acoplo de códigos de ámbito nuclear, pero todavía no han realizado trabajos para acoplar códigos termohidráulicos.

En Indizen ya hemos acoplado TRACE (código termohidráulico del regulador nuclear de EEUU) a SCAIS, y les resultó sorprendente la forma en que procedimos para realizarlo. Precisamente, según nos comentaron después, acoplar códigos a TRACE es uno de sus objetivos para el año que viene en el marco de un proyecto europeo en el que están participando.

Tras la charla hablamos sobre posibles colaboraciones con el instituto, y dados los intereses comunes que tenemos, parece factible que encontremos alguna vía para ello.

La particula de DIOS

El bosón de Higgs, la partícula para cuya búsqueda se construyó el Gran Colisionador de Hadrones (LHC).

El descubrimiento del bosón de Higgs significaría completar el esqueleto esencial del modelo estándar de física de partículas, demostraría que los físicos han avanzado un nivel más profundo en la compresión de cómo está hecho y cómo funciona el universo en su nivel básico. Es un gran paso en aquella búsqueda científica que ha ido desvelando que las cosas están hechas de átomos, que los átomos están hechos de electrones y núcleos, y que los núcleos están hechos de partículas, a su vez formadas por otras más elementales

Konrad Kuijken , director científico del observatorio de Leiden, en Holanda, es el protagonista de la última conferencia del Ciclo sobre Astrofísica y Cosmología de la Fundación BBVA. Kuijken es especialista en lo que podría llamarse “el lado oscuro de la física”: ese que está fuera del modelo estándar, del que sólo falta por confirmar la existencia del bosón de Higgs pero que sólo es capaz de explicar un 5% del universo. ¿Qué pasa con el otro 95%? “La explicación más natural es que haya materia que no vemos, que no son estrellas, que no brillan”, dice Kiujken.

El bosón de Higgs, si existe, debe tener una masa de entre 115 y 130 gigaelectronvoltios (GeV), una medida de energía que se usa en física teórica para referirse a masas muy pequeñas. Es un logro experimental enorme porque buscamos a ciegas una partícula que puede ser 100 veces un protón.

La dificultad para encontrar el bosón de Higgs reside en que tiene un tiempo de vida muy corto y rápidamente decae en otro tipo de partículas

Una cualidad interesante de esta partícula es explica como las demás partículas adquieren masa.

Higgs boson es un nombre que escucharemos mucho en las próximas semanas y aunque no parezca importante ahora, cambiará el mundo bastante.

Ahora los expertos tienen los datos al día de los dos grandes experimentos (Atlas y CMS) y constatan que, seguramente, se están acercando mucho al trofeo. Tardarán todavía en confirmarlo y, si tienen que poner fecha para un resultado definitivo, apuntan a mediados o finales de 2012.

Se dice que nos ha dado muchas respuestas sobre la creación del universo y al mismo tiempo, quizás acabe con la cuestión religiosa en el mundo. Es decir, quizás no fuera Dios quien creó el mundo.

Arturo Luna Portilla

Para cada decisión tomada en el día a día empresarial existe una valoración previa del objetivo que se persigue, los medios con que se cuenta, las posibles repercusiones y los costes que conllevarán cada una de las alternativas candidatas.

El objetivo de la aplicación, en cuyo desarrollo estoy inmerso, es aportar al usuario de riesgos información financiera sobre los clientes de la entidad para la que trabaja.

Esta información debe de presentarse de forma ágil y sencilla.

Solo con lo mencionado en esta última frase ya estaría suficientemente justificada la elección de .NET como plataforma de desarrollo. Es el mejor entorno en el mercado para la generación de aplicativos eficientes, de respuesta rápida y moderadamente potentes.

Si a esto unimos otras características propias de la arquitectura .NET como pueden ser la flexibilidad, versatilidad, reciclaje, reutilización,  escalabilidad, fácil manejo, interacción con distintos entornos, disponemos de una “caja de herramientas” en la que encontraremos soluciones a todos los retos que nuestra construcción pueda presentar.

La interacción que ofrece .NET con otros entornos posibilita a nuestra aplicación el intercambio de información con otros programas lo que incrementa enormemente su potencial.

Se cuenta además con el potencial de todos los productos del gigante informático: SQL Server, Reporting Services, Navision, … Por lo que respecta al proyecto al que estoy dedicado se trabaja tanto con SQL Server como con Reporting Services, ambos en sus versiones del 2005.

Son muchas las cualidades de .NET que aquí no se han señalado. Y, así mismo, existen razones  en las que no me he detenido que desaconsejaban su uso. El hecho incuestionable es que el resultado final del cociente beneficios/coste arrojaba un saldo muy positivo a favor de su elección.

Hasta el momento he hablado del objetivo y el coste, parámetros fundamentales en la toma de decisiones del ámbito empresarial. Al principio del texto se mencionan otros dos: repercusiones y medios con lo que se cuenta. Siendo su importancia relativa con respecto a los anteriores no hay que dejar de observar que dotar a la solución de estabilidad y seguridad junto a una sencilla implantación en los sistemas del cliente son temas primordiales y que están relacionados con estos conceptos.

Es el conjunto de todas las aportaciones reflejadas lo que constituye el POR QUÉ .NET fue la arquitectura finalmente seleccionada.

Juan Ángel Villodre Jiménez

Desde el punto de vista del cliente, la transformación de datos brutos en información útil mediante herramientas ETL, para su explotación a través de módulos de informes y minería, es una tarea que lleva siendo clave durante varios años en los procesos de negocio, ya que el uso final de éstos datos es el estudio de tendencias que puedan maximizar beneficio, reducir costes y definir líneas de actuación de cara al posicionamiento del cliente en el sector.
Sin embargo otro de los usos de éste tipo de herramientas, es suplir las necesidades de datos de pequeñas aplicaciones (en comparación con grandes almacenes de datos) de modo que garanticen la disponibilidad de la información cuando los usuarios de la aplicación trabajen con ella. Aquí no se definen patrones de negocio, ni modelos de explotación, si no que a partir de la información sin depurar que ofrecen los sistemas origen del cliente, la adaptamos a las necesidades de la aplicación. Cargando sus pequeños modelos de datos mantenemos la integridad ya no solo de nuestra base de datos, sino de la propia aplicación, de forma que los usuarios cuentan con una serie de datos estándar (core) con los que, en el caso del proyecto al que estoy asignado, a través de sus pantallas online asignan operativas de riesgo a clientes, propuestas de operaciones financieras, control de límites a nivel de cliente y operación, y valoraciones de los propios clientes, entre otras.
Desde el punto de vista del desarrollo, el hecho de utilizar procesos ETL para éstos casos, se debe más a la complejidad de transformación que al volumen de información, que en éste caso, por tratarse de un subárea específica dentro de un área del cliente (ejemplo: riesgos -> minorista), el desarrollo puede adquirir una complejidad superior a la de una simple carga de una gran cantidad de datos en un almacén, pero también nos da más posibilidades de creatividad ante los diferentes datos y destinos a cargar y nos permite adquirir conocimiento funcional de la aplicación (principalmente porque la vemos como un todo al ser inseparable la parte batch-ETL de la parte online)
Además, la información que añaden los usuarios a través de la aplicación, junto con la que los procesos ETL le suministran cuando ellos no están delante de sus pantallas, puede servir de propio sistema origen a través del cual, otra vez utilizando éstas herramientas, se obtiene la información mediante extracciones que pueden aprovisionar otros sistemas de otras áreas ó subáreas de negocio para sus propias necesidades.

Desde mi incorporación a este proyecto,  mi trabajo ha consistido en dar soporte a diferentes unidades  de una importante herramienta de gestión de riesgos de mercado y crédito. Aunque ya conocía la herramienta gracias al proyecto “Pricers”, que es un punto muy pequeño del sistema, ahora tengo la suerte de poder observar todo el sistema distribuido del que la aplicación web forma parte.

Uno de los elementos más importantes es el grid:

La computación grid es una tecnología innovadora que permite utilizar de forma coordinada todo tipo de recursos (entre ellos cómputo, almacenamiento y aplicaciones específicas) que no están sujetos a un control centralizado. Es una nueva forma de computación distribuida, en la cual los recursos pueden ser heterogéneos y se encuentran conectados mediante redes de área extensa.

Una de las aplicaciones típicas de la computación grid es la que precisamente se desarrolla aquí: aplicaciones cuyas necesidades es imposible satisfacer en un único nodo. Estas necesidades se producen en instantes de tiempo determinados y consumen muchos recursos como simulaciones, cálculo numérico, procesos de análisis de datos…

Las ventajas que ofrece este tipo de sistemas son:

- Seguridad: para pertenecer a este tipo de sistema se deben seguir una serie de protocolos que garantizan la seguridad del sistema.

- Confiabilidad: las organizaciones participantes son confiables, por lo tanto se asume que, en cierto modo, no hay datos corruptos.

- Coordinación: los miembros aportan siempre más recursos, es decir, es un esfuerzo coordinado donde todos aportan y todos usan los recursos disponibles.

- Escalabilidad: este tipo de sistema es altamente escalable, ya que se pueden agregar cada vez más recursos incrementando las capacidades del mismo.

- Disponibilidad: si un servidor falla, se reasignan los servicios en los servidores restantes.

- Reducción de costes: los recursos son gestionados por granjas de servidores que permiten la posibilidad de no utilizar supercomputadores, pudiendo hacer uso de componentes de bajo coste.

En contraposición, existen algunas desventajas:

-  Comunicación no uniforme.

- Organización: Al intervenir varias organizaciones, cada una con sus propios recursos computacionales, hace que la complejidad se multiplique respecto a los sistemas distribuidos convencionales.

En la actualidad, las ventajas que ofrecen estos sistemas superan las desventajas o inconvenientes que puedan tener. Con una administración eficiente y manteniendo un nivel de seguridad, los resultados de rendimiento son muy buenos.

Elizabeth González

Reducir el consumo de recursos, suele ser un objetivo en todo desarrollo de software de calidad que se precie de serlo. En el proyecto donde me encuentro actualmente, es un requisito indispensable para poder conseguir más desarrollos evolutivos futuros.

La previsión de aumento del número de datos a procesar, ha hecho que la antigua aplicación, implementada bajo código java, multiproceso, con acceso a base de datos Oracle y uso de scripts bsh, ofrezca unos tiempos de ejecución inviables para el cliente, que hace uso de la salida procesada por la aplicación.

La solución propuesta se basa en los siguientes puntos:

• Utilización de patrones de diseño en el acceso a datos, evitando accesos continuos que aumentaban la latencia del sistema, al perder el paralelismo temporal de los hilos.
• Uso de una codificación eficiente, como por ejemplo con la eliminación de literales en el código, obligando al uso de constantes, de forma que se reduzca el consumo de memoria utilizado por la infinidad de pequeños procesos generados.
• Diseño de un nuevo modelo de datos, que reduzca el acceso a la información de entrada que no sea necesaria. Así como una estructuración de la salida generada, para que permita a aplicaciones paralelas, determinar por medio de una serie de reglas, que información ha de ser tratada.

El uso de una codificación de calidad, además del óptimo consumo de recursos del sistema, permite unos tiempos de desarrollo menores y un mantenimiento futuro más cómodo.

Ricardo Bravo

Después de más de 3 años desarrollando InnoVaR, dando apoyo y formación a gente que se ha ido incorporando a Indizen, así como, estabilizando la herramienta y dando soporte a los diferentes clientes, surge poco antes del verano la oportunidad de comenzar algo nuevo desde cero.

Tengo la suerte de pasar a formar parte del grupo de trabajo encargado de uno de los proyectos más importantes de Indizen en este año 2011: eCap. El proyecto de Cálculo de Capital Económico, en el que una de las mayores entidades financieras a nivel nacional nos pide desarrollar una herramienta a su medida.

Tras las primeras reuniones metodológicas y de requerimientos de sistemas se nos informó de cuáles serían los 2 principales objetivos del proyecto:

• Desarrollar un potente motor capaz de realizar miles de millones de cálculos y simulaciones con el objetivo de obtener informes de capital económico en un tiempo razonable. Donde el término “tiempo razonable” viene definido por la entidad en cuestión dado que posee una herramienta previa de cálculo de capital más simple en la que, a partir de un número suficientemente grande de cálculos, los tiempos se disparaban a varios días.
• Desarrollar la herramienta en un plazo de tiempo relativamente corto, puesto que el cliente tiene unas necesidades específicas dentro de las fechas establecidas.

A pesar de que en un primer momento todo parecía un poco utópico, uno de los miembros del equipo creyó que la posibilidad de hacerlo y hacerlo bien era real y nos fue convenciendo al resto, hasta el punto de que eCap ha sido un verdadero éxito.

Una vez que el proyecto ya está instalado en el cliente y puesto que las necesidades de soporte han sido mínimas, he vuelto a InnoVaR para seguir con el desarrollo de las nuevas funcionalidades requeridas en futuras versiones.

Rubén García