Planet

¡Hola a tod@s! De momento, soy el más sorprendido de todos, porque hoy es el quinto día consecutivo que os traigo novedades. Por cierto, el Planet del Concurso de Software Libre no recoge mis entradas en estos momentos, así que si estás leyendo esto, gracias por preocuparte por el avance de la biblioteca y demás [...]

A partir de ahora comenzará la etapa de implementación, como se ha detallado en el diseño y análisis, la aplicación será un proyecto web dinámico lo que dará lugar a que sea multiplataforma y el usuario sólo necesite de un navegador para su utilización. se desarrollará utilizando la tecnología que proporciona Java (OpenJDK) además de otros frameworks  para la interfaz gráfica y otras librerías open source (que se irán indicando más adelante) necesarias para el desarrollo de la aplicación.
ePlanning es una aplicación que se caracterizará por su alto componente visual, siendo de vital importancia la elección del framework para la interfaz de usuario, por ello lo primero será realizar un estudio detallado de los framworks disponibles en la actualidad. Este estudio se publicará lo antes posible.

Se puede decir que la fase de diseño de la aplicación ePlanning ha concluido, aunque puede que no sea definitiva, ya que siempre se suelen hacer modificaciones y correcciones. Antes de empezar con la fase de implementación (la cual debería ir ligera ya que ahora puedo dedicar mucho más tiempo al proyecto) recordaré cuales eran los objetivos iniciales de la aplicación, las ventajas que se obtendrían y los posibles riesgos en el proyecto.
Decir que el el desarrollo de la aplicación surgió en mi periodo de prácticas en el Hospital Nacional de Parapléjicos de Toledo y  el objetivo es desarrollar un sistema de información que visualice la información relativa a la agenda del paciente en unas pantallas situadas en el lugar que actualmente están las pizarras de los staff de enfermería. Este nuevo sistema se “alimentará” de los distintos aplicativos existentes en el hospital (HIS, Dietools, etc). De esta forma el personal de planta sólo tendrá que visualizar la información, ya que el registro de la misma proviene de otras fuentes. A parte de esto y por necesidad propia de la planta se podrá desde la misma añadir más información a los paneles informativos, como observaciones personalizadas para pacientes, pero sin modificar la información cuyo origen sea los sistemas de información implantados en el hospital. Aunque la idea está pensada para el HNP, también se podría trasladar a cualquier otro hospital, ya que la información del planning será, en la medida de los posible parametrizable.
Posibles mejoras y beneficios del proyecto en el HNP:

1. Automatización del registro de la información que aparece en las pizarras de los staff de enfermería.
2. Eliminación de los posibles errores potenciales derivados del registro manual anterior.
3. Visualización de la información en tiempo real.
4. Construcción dinámica de la información según los requisitos de cada planta.
5. Incorporación de sistemas de avisos o eventos sobre el planning del paciente.
6. Eliminación de los tiempos dedicados al registro de la información por parte del personal de planta.

Posibles riesgos del proyecto:

1. La información visualizada en las pantallas dependerá de la información registrada en los aplicativos del hospital; por lo que dicha información no se podrá cotejar de manera electrónica.
2. La disponibilidad de la información dependerá del entorno informático del HNP.

He redactado el documento que refleja el análisis de clases siguiendo la arquitectura MVC (Modelo Vista Controlador) lo que nos permitirá tener la aplicación estructurada en capas, lo que facilitará su implementación y su posterior modificación.
El documento esta en la forja del proyecto y disponible en el siguiente enlace en formato PDF: Diagrama de Clases

Arreglando los fallos que tengo pendientes he tomado la decisión de cambiar el lenguaje de programación y el protocolo del  servicio web del Servidor. Hasta ahora usaba el lenguaje C# y el protocolo SOAP pero éste último me estaba dando muchos problemas, por lo que a partir de ahora usaré el protocolo XML-RPC y, como es sencillo de utilizar en Python, usaré Python en vez de C#, haciendo así que el proyecto esté escrito al 100% en Python.
Aquí os dejo un ejemplo muy sencillo de XML-RPC (tanto de servidor como de cliente) en Python de la web oficial de Python, por si os interesa:
http://docs.python.org/library/simplexmlrpcserver.html

Entregas Colisiones I: Introducción, requisitos y alternativas Colisiones II: Diseño general de STC Colisiones III: Shape y Collision Dispatching Colisiones IV: Tests de colisión En la cuarta entrega de la serie de artículos de documentación sobre el sistema de detección de colisiones de Sion Tower (STC) trataremos en profundidad los tests de colisión. Hasta ahora

Buenas de nuevo, hoy estoy algo más animado, y es que el pequeño monstruito que es mi PC regresó a la vida tras un par de horas de informática forense anoche. Ya sabemos gestionar la entrada mediante los mandos de la consola, y además, crear y dibujar figuras geométricas y texturas, así que lo suyo [...]

Hemos preparado una encuensta para ver si, a parte de a nosotros, os parece una buena idea a vosotros el que Infant se publique en forma de librería. Si quereis participar esta disponible en en la forja.

La Forja de Red Iris proporciona a cada proyecto un espacio para colgar una web estática sencilla. Es una tontería no aprovechar dicho espacio ya que Red Iris cuenta con un indexado en buscadores excelente. Simplemente he colgado un panel explicando en qué consiste mi proyecto junto con enlaces a otros medios (wiki, blog, forja

He detectado varios problemas en las versiones de componentes que he liberado, por lo que he tenido que anular la liberación de los mismos. Voy a intentar corregir estos problemas cuanto antes y volveré a liberar estas versiones.