Israel Brea Piñero

Pixora - Aplicación nativa Android

Thu, 10 Jul 2025 00:00:00 +0000

Pixora es una aplicación nativa para Android desarrollada como proyecto para la asignatura de Desarrollo de Aplicaciones Android del Máster Universitario en Informática Móvil de la Universidad Pontificia de Salamanca. La aplicación está inspirada en plataformas como Pinterest y permite a los usuarios explorar, organizar y compartir contenido visual de una manera sencilla e intuitiva.

Características

Las funcionalidades principales de Pixora incluyen:

Navegar y visualizar imágenes filtradas por categorías.
Buscar imágenes con una función de scroll infinito.
Crear listas (colecciones) personalizadas para organizar fotos.
Dar “Me gusta” a las imágenes para guardarlas en una sección de favoritos.
Subir fotos propias desde la cámara o la galería del dispositivo.
Ver un feed de actividad con las interacciones recientes, como “me gusta” y fotos añadidas a listas.
Acceder a un perfil personal para ver las fotos subidas, las listas creadas y las imágenes favoritas.
Cambiar el idioma.

Detalles Técnicos

La aplicación fue desarrollada utilizando tecnologías modernas de Android y buenas prácticas de arquitectura de software:

Lenguaje y Framework: Construida íntegramente con Kotlin y Jetpack Compose, el moderno toolkit de UI declarativa de Google, para un proceso de desarrollo más conciso, intuitivo y eficiente.
Arquitectura: Se implementó una combinación de MVVM (Model-View-ViewModel) y Clean Architecture para asegurar una base de código robusta, escalable y fácil de mantener. El proyecto está claramente estructurado en capas de Dominio, Datos y Presentación.
Gestión de Datos:
- Room: Utilizado para la persistencia local de datos estructurados como fotos, listas creadas por el usuario y registros de actividad. Se eligió por su verificación de consultas en tiempo de compilación y su integración nativa con Flow.
- Preferences DataStore: Empleado para almacenar datos simples clave-valor, como las preferencias de idioma y modo de visualización (claro/oscuro), ofreciendo una alternativa segura y asíncrona a SharedPreferences.
Integración de API: Se integró la API de Unsplash para proporcionar un amplio catálogo de imágenes de alta calidad. Las peticiones de red se gestionan de forma eficiente con Retrofit para la definición declarativa de la API y OkHttp para el manejo de las conexiones.
Librerías Externas: Se utilizaron librerías clave de terceros para mejorar la funcionalidad:
- Hilt: Para la inyección de dependencias, garantizando una arquitectura desacoplada. Fue elegido sobre Koin por su seguridad en tiempo de compilación y por ser la solución recomendada oficialmente por Google
- Coil (Coroutine Image Loader): Para la carga asíncrona y el almacenamiento en caché de imágenes de forma rápida y eficiente, con soporte nativo para Jetpack Compose.
- Lottie: Para renderizar animaciones vectoriales complejas, utilizada específicamente en la pantalla de carga inicial (splash screen).
- Kotlinx Serialization: Utilizada para habilitar una navegación type-safe con Jetpack Compose Navigation, permitiendo pasar objetos completos como argumentos.
Android Jetpack: La aplicación utiliza extensivamente componentes de Android Jetpack, incluyendo Navigation para gestionar el flujo de la app, Coroutines y Flow para operaciones asíncronas, y ViewModel para la gestión de datos de la UI.
Animaciones: Se incluyeron varias animaciones para mejorar la experiencia de usuario, como una animación de Lottie en la pantalla de carga, transiciones suaves de visibilidad para la barra de navegación y animaciones interactivas para el gesto de “me gusta”.

Publicación

La aplicación fue publicada en la Google Play Store como una versión de prueba cerrada. Enlace a la Google Play Store: Pixora

Repositorio del Proyecto

El código fuente de este proyecto está disponible en GitHub: https://github.com/israelbrea12/Pixora-Android.git.

Visualizar proyecto en pdf

Pixora-Android

Vídeo Pixora

Pixora - Aplicación nativa iOS

Sat, 10 May 2025 00:00:00 +0000

Pixora es una aplicación nativa para iOS desarrollada como proyecto de fin de Grado para la asignatura de Desarrollo de Aplicaciones iOS del Máster Universitario en Informática Móvil de la Universidad Pontificia de Salamanca. La aplicación está inspirada en plataformas como Pinterest y permite a los usuarios explorar, organizar y compartir contenido visual.

Características

Las funcionalidades principales de Pixora incluyen:

Navegar y visualizar imágenes.
Buscar imágenes.
Crear listas (colecciones) personalizadas para organizar imágenes.
Dar “Me gusta” a las imágenes.
Subir tus propias fotos desde la cámara o galería.
Ver tu feed de actividad, incluyendo fotos a las que has dado “Me gusta” y fotos añadidas a listas.
Ver tus fotos subidas.

Detalles Técnicos

La aplicación fue desarrollada utilizando tecnologías modernas de Apple y patrones arquitectónicos:

Lenguaje y Framework: Se utilizaron Swift y SwiftUI por su seguridad, rendimiento y capacidades de UI declarativa.
Arquitectura: Se implementó una combinación de MVVM (Model-View-ViewModel) y Clean Architecture para asegurar una base de código robusta, modular y mantenible. El proyecto está estructurado en capas de Dominio, Datos y Presentación.
Gestión de Datos: Se utilizó Core Data para la persistencia local de datos, gestionando objetos y manejando la persistencia, recuperación, validación y gestión de cambios en esos datos.
Integración de API: Se integró la API de Unsplash para proporcionar un amplio catálogo de imágenes de alta calidad para el contenido de la aplicación. Las peticiones de red se manejaron utilizando URLSession.
Librerías Externas: Se incorporaron varias librerías externas a través de Swift Package Manager para mejorar la funcionalidad y la experiencia de usuario:
- CryptoSwift: Utilizada para generar hashes MD5 para la autenticación de la API.
- Lottie: Integrada para mostrar animaciones atractivas en la Launch Screen.
- SDWebImageSwiftUI: Utilizada para la carga asíncrona y caché eficiente de imágenes desde URLs.
- Swinject: Empleada como framework de Inyección de Dependencias para gestionar las dependencias.
Frameworks de Apple: Se utilizaron frameworks nativos clave de Apple:
- UserNotifications: Implementado para gestionar notificaciones locales para re-enganchar a los usuarios.
- AVFoundation: Utilizado para acceder a la cámara del dispositivo y capturar fotos.
- UIKit: Utilizado para funcionalidades aún no completamente maduras en SwiftUI, como información del dispositivo e integración de una vista previa de la cámara (UIViewRepresentable).
- Foundation: Proporcionó tipos de datos fundamentales, colecciones y acceso a servicios del sistema.
Layout y Adaptabilidad: El layout fue diseñado para ser compatible con varios tamaños de pantalla de iPhone y iPad, así como con las orientaciones vertical y horizontal, utilizando GeometryReader, UIDevice, LazyVGrid con ítems adaptativos y clases de tamaño.
Animaciones: Se incluyeron varias animaciones para mejorar la experiencia de usuario, incluyendo una animación de Lottie en la pantalla de inicio, animaciones de visibilidad de la barra de pestañas y animaciones en los botones de “Me gusta” y “Guardar”.

Publicación

La aplicación fue publicada en la App Store de Apple el 6 de mayo de 2025. Enlace a la App Store: Pixora

Repositorio del Proyecto

El código fuente de este proyecto está disponible en GitHub: https://github.com/israelbrea12/Pixora-iOS.git.

Visualizar proyecto en pdf

Pixora-Android

Vídeo Pixora

Creación de una API con Express y despliegue en la nube con AWS

Mon, 10 Mar 2025 00:00:00 +0000

Este proyecto fue desarrollado como parte de la asignatura de Tecnologías del lado del servidor: Cloud Computing dentro del Máster Universitario en Informática Móvil (MIMO). El objetivo fue implementar una API REST completa utilizando Node.js y Express, con autenticación mediante JWT, persistencia en SQLite y despliegue en AWS siguiendo buenas prácticas de escalabilidad y automatización.

Objetivos del proyecto

Implementar una API REST conforme a una especificación OpenAPI.
Gestionar autenticación y autorización con JWT.
Implementar operaciones CRUD para los recursos de películas y valoraciones.
Aplicar validaciones de datos y manejo adecuado de códigos de estado HTTP.
Desplegar la API en AWS con una infraestructura escalable y automatizada usando Packer y Terraform.

Funcionalidades principales

1. Autenticación y seguridad

Endpoint de login (POST /sessions) para generar tokens JWT.
Protección de rutas sensibles mediante middleware de autenticación.
Manejo de errores de autenticación con respuestas adecuadas (401 Unauthorized).

2. Gestión de películas (`/movies`)

GET /movies: Devuelve todas las películas con los campos requeridos (ID, título, género, duración, rating).
Paginación opcional para mejorar la eficiencia en consultas grandes.
Manejo de errores con respuestas adecuadas (404 Not Found, 500 Internal Server Error).

3. Gestión de valoraciones (`/ratings`)

CRUD completo para que los usuarios puedan crear, leer, actualizar y eliminar valoraciones.
Validaciones:
- rating debe estar entre 0 y 5.
- comentarios con máximo 500 caracteres.
Restricciones de acceso:
- Solo usuarios autenticados pueden modificar o eliminar sus valoraciones.
- Manejo de errores con códigos adecuados (401 Unauthorized, 422 Unprocessable Entity, 201 Created).

4. Gestión de la lista de películas por ver (`/watchlist`)

Permite a los usuarios añadir y gestionar películas pendientes de ver.
Validación de IDs de películas antes de añadirlas.
Manejo de estados de películas vistas/no vistas.
Respuestas adecuadas:
- 409 Conflict para películas duplicadas.
- 422 Unprocessable Entity para IDs inválidos.
- 404 Not Found para películas inexistentes.

Implementación técnica

Tecnologías utilizadas

Node.js + Express: Desarrollo de la API REST.
SQLite: Base de datos ligera y eficiente.
JWT (jsonwebtoken): Implementación de autenticación.
Docker: Contenerización del entorno de desarrollo.
AWS (EC2, S3, IAM): Infraestructura en la nube.
Packer: Creación de imágenes AMI para AWS.
Terraform: Automatización del despliegue en la nube.

Persistencia y base de datos

Uso de SQLite para almacenar información de usuarios, películas y valoraciones.
Migraciones y esquema definido para garantizar la integridad de los datos.
ORM Sequelize para facilitar la gestión de la base de datos.

Despliegue en AWS

1. Creación de AMI con Packer

Se generó una Amazon Machine Image (AMI) con la configuración necesaria para ejecutar la API:

Instalación de Node.js y dependencias.
Configuración del entorno y variables necesarias.
Creación de un script para la ejecución automática del servicio.

2. Infraestructura con Terraform

Se implementó la infraestructura con Terraform, asegurando escalabilidad y automatización:

Instancia EC2 configurada con la AMI generada.
Balanceador de carga para distribuir el tráfico.
Auto Scaling Group para aumentar o reducir instancias según demanda.
Almacenamiento en RDS para persistencia de datos en la nube.
Gestión de IAM roles y permisos para garantizar la seguridad.

Automatización y escalabilidad

Infraestructura autoscalable que permite ajustar el número de instancias en función de la carga.
Manejo de errores para garantizar alta disponibilidad y minimizar tiempos de inactividad.
Persistencia de datos asegurada con almacenamiento en AWS.

Conclusiones y aprendizajes

Este proyecto permitió consolidar conocimientos en desarrollo backend con Express, autenticación JWT, bases de datos SQL, así como en infraestructura cloud y automatización del despliegue en AWS. Se aplicaron buenas prácticas de seguridad, validaciones de datos y manejo de errores, logrando un sistema robusto y escalable.

Recursos y código fuente

Procesamiento de XML con DOM y SAX

Sun, 02 Feb 2025 00:00:00 +0000

Este proyecto fue desarrollado para la asignatura de Tecnologías del lado del servidor: Cloud Computing como parte del máster universitario oficial en Informática Móvil (MIMO).

El objetivo principal fue implementar una aplicación en Java capaz de procesar un canal de noticias en formato RSS (XML) y generar archivos de salida en XML y JSON, aplicando técnicas modernas de procesamiento y herramientas específicas.

Funcionalidades principales

1. Procesamiento de XML:

Implementación de dos versiones del procesamiento del archivo RSS:

DOM (Document Object Model): Carga el documento completo en memoria y permite una navegación estructurada.
SAX (Simple API for XML): Lectura secuencial del archivo, más eficiente para grandes volúmenes de datos.

Extracción y presentación de la información clave:

Del canal: Título, URL, descripción.
De las noticias: Título, URL, descripción, fecha de publicación y categoría.

2. Generación de archivos de salida:

XML: Archivo estructurado con los títulos de las noticias en el formato:

<noticias canal="título del canal">
  <noticia>título noticia 1</noticia>
  <noticia>título noticia 2</noticia>
</noticias>

JSON: Archivo equivalente, generado con el formato:

{
  "noticias": [
    {"noticia": "título noticia 1"},
    {"noticia": "título noticia 2"}
  ]
}

3. Conversión con GSON:

Uso de la librería GSON para la serialización y deserialización entre objetos Java y JSON, asegurando una manipulación sencilla y eficiente de los datos.

Ver repositorio en GitHub de procesamiento con DOM

Ver repositorio en GitHub de procesamiento con SAX

LikeMovies

Sat, 01 Feb 2025 00:00:00 +0000

Este proyecto fue desarrollado para la asignatura de Tecnologías del lado del cliente: HTML5 como parte del máster universitario oficial en Informática Móvil (MIMO).

El objetivo principal del proyecto fue crear una aplicación web híbrida para la gestión y exploración de películas, aprovechando tecnologías modernas como Angular, Ionic y servicios como Firebase para autenticación y almacenamiento local con Ionic Storage.

Funcionalidades principales

La aplicación LikeMovies permite a los usuarios:

Explorar películas: Consumir la API de TMDB para listar películas populares, por género o próximas a estrenarse en España.
Gestión personalizada:
- Añadir películas a listas como “Favoritos” o “Mi Lista”.
- Configurar recordatorios para estrenos próximos.
Autenticación segura: Registro e inicio de sesión mediante Firebase Authentication.
Interfaz responsiva: Adaptada para múltiples dispositivos, garantizando una experiencia fluida.

Estructura de la aplicación

La aplicación está organizada en varias secciones accesibles mediante un sistema de navegación con tabs:

Para ti: Pantalla principal donde el usuario puede buscar películas, filtrarlas por género y visualizarlas en una cuadrícula interactiva.
Estrenos: Listado de películas próximas a estrenarse, con opción para añadir recordatorios. Incluye un scroll infinito para cargar más resultados dinámicamente al desplazarse.
Mi perfil: Permite al usuario gestionar sus datos personales y visualizar sus listas personalizadas de favoritos y recordatorios.
Detalle de película: Muestra información completa de una película, incluyendo descripción, géneros y puntuación, con opciones para gestionar favoritos y listas.

Características técnicas destacadas

Consumo de API: Uso de la API de TMDB para obtener datos de películas, gestionado mediante un servicio Angular que interactúa con los endpoints REST.
Persistencia de datos:
- Firebase Authentication: Manejo de usuarios y autenticación segura.
- Ionic Storage: Almacenamiento local para listas y recordatorios.
Guards de autenticación: Implementación de un Guard para garantizar que solo los usuarios autenticados puedan acceder a las funcionalidades de la aplicación. Redirige automáticamente a la página de inicio de sesión si no se ha iniciado sesión.
Scroll infinito: Integrado en la sección de “Estrenos”, permite una experiencia de usuario mejorada al cargar dinámicamente más datos conforme el usuario se desplaza hacia abajo.
Swiper.js: Uso de la librería Swiper.js para crear carruseles interactivos y responsivos, utilizados en secciones como “Favoritos” y “Recordatorios” para destacar películas de forma atractiva.
Diseño responsivo: Uso de media queries, flexbox y grid para garantizar adaptabilidad en distintos dispositivos.

Conclusión

LikeMovies es un ejemplo práctico de cómo combinar tecnologías modernas como Angular e Ionic con servicios externos como TMDB y Firebase, ofreciendo una solución completa y profesional para la gestión de películas. El proyecto destaca por su arquitectura modular, su enfoque en la responsividad y su integración fluida con APIs y almacenamiento.

Ver documentación en pdf

Video Funcionalidad LikeMovies

SCORECARD TPNi CG

Sun, 06 Oct 2024 00:00:00 +0000

SCORECARD TPNi CG es una aplicación móvil nativa diseñada y desarrollada para identificar pacientes de alto riesgo en cirugía abdominal y colorrectal, facilitando la aplicación de terapia de presión negativa de un solo uso cuando sea adecuado. Basada en la evidencia clínica, esta herramienta optimiza la prevención de complicaciones en el sitio quirúrgico, mejorando la recuperación y reduciendo costes para el sistema sanitario. Este proyecto fue realizado para la empresa FOINCO Formación Investigación Coloproctología y en colaboración con Smith & Nephew, y ha sido avalado por entidades como el Grupo Español de Rehabilitación Multimodal (GERM), la Asociación Española de Coloproctología (AECP) y el Observatorio de Infección en Cirugía.

¿Qué es SCORECARD TPNi CG?

La aplicación tiene como objetivo principal ayudar a los profesionales de la salud a identificar si un paciente quirúrgico presenta un riesgo elevado de complicaciones, basándose en factores como:

Factores del paciente: edad avanzada, inmunosupresión, etc.
Factores quirúrgicos: tiempo quirúrgico prolongado, cirugías iterativas, entre otros.

Los escenarios de riesgo se determinan utilizando la Tabla de Consenso de CSQ, proporcionando una recomendación clara:

Pacientes de riesgo: sugerencia de usar terapia de presión negativa (TPN) de un solo uso durante 7 días, desarrollada por Smith & Nephew.
Pacientes sin riesgo: recomendación de usar un apósito postquirúrgico estándar.

¿Qué incluye la aplicación?

SCORECARD TPNi CG está estructurada en secciones clave que garantizan su funcionalidad y valor educativo:

Sección de cálculo del riesgo: Permite al usuario introducir los datos del paciente y del procedimiento quirúrgico para obtener la recomendación asociada.
Mecanismo de acción: Explica los beneficios y fundamentos del sistema de terapia de presión negativa de un solo uso.
Estudios y bibliografía: Reúne evidencia científica que respalda las recomendaciones y funcionalidades de la aplicación.
Preguntas frecuentes: Proporciona respuestas a dudas comunes sobre el uso de TPN y la prevención de CSQ.

Desarrollo y publicación

Esta aplicación fue desarrollada de manera completamente nativa para iOS (utilizando Swift y la arquitectura MVC) y Android (con Kotlin y la arquitectura MVVM). Gestioné todas las fases del ciclo de desarrollo de software, desde la planificación inicial hasta la publicación en las tiendas de aplicaciones:

Google Play Store y Apple App Store bajo el nombre SCORECARD TPNi CG.
Disponible también en la página oficial de la AECP.

Avales y Reconocimientos

La aplicación cuenta con el respaldo de instituciones clave en el ámbito quirúrgico y de salud:

Grupo Español de Rehabilitación Multimodal (GERM).
Asociación Española de Coloproctología (AECP).
Observatorio de Infección en Cirugía. SCORECARD TPNi CG es una herramienta que no solo mejora la toma de decisiones clínicas, sino que también fortalece la práctica quirúrgica basada en evidencia.

Video SCORECARD TPNi CG

Creación y despliegue de portfolio web con Hugo.

Sun, 01 Sep 2024 00:00:00 +0000

Descripción del Proyecto

Este proyecto personal tiene como objetivo no solo crear una página web que reúna todos los proyectos que he desarrollado durante mi carrera académica y personal, sino también desplegarla en mi propio servidor, haciéndola accesible de manera segura desde Internet.

## Desarrollo Web Para la construcción de mi portfolio elegí Hugo, una plataforma de generación de sitios web estáticos que permite crear páginas modernas de frontend utilizando archivos Markdown. La decisión de usar Hugo se basó en que ya había redactado una parte de mi portfolio en Obsidian, una herramienta (donde también se escribe en Markdown) que utilizo habitualmente para tomar notas y organizar mis apuntes. La capacidad de Hugo para aprovechar archivos en formato Markdown me permitió migrar este contenido fácilmente y enfocarme más en la calidad del contenido que en el desarrollo técnico.

El tema que seleccioné para mi portfolio es hugo-theme-stack, debido a su formato limpio y moderno, que se ajusta perfectamente a la estructura y diseño que buscaba. Esta plantilla, con su enfoque en el rendimiento y la simplicidad, me permitió optimizar el desarrollo de mi portfolio sin necesidad de invertir demasiado tiempo en el diseño de la interfaz .

DevOps y Despliegue

En cuanto al despliegue y la gestión operativa, mi portfolio está alojado en un servidor Raspberry Pi 5 con 8 GB de RAM, lo que proporciona una solución eficiente y de bajo consumo energético. Para garantizar un entorno seguro y aislado, utilizo Docker, donde el portfolio se ejecuta dentro de un contenedor. Esto me permite empaquetar la aplicación de forma independiente del resto del sistema, facilitando la gestión y evitando conflictos con otros servicios que corren en el mismo servidor.

El servidor web que gestiona las peticiones es Caddy, una solución ligera que me permite asegurar la conexión con HTTPS de manera automática y redirigir el tráfico a los diferentes servicios que tengo desplegados. Además de mi propio portfolio, también alojo el portfolio de un compañero de carrera, aprovechando la capacidad del servidor para manejar múltiples sitios web.

Para el desarrollo, suelo trabajar en local utilizando Visual Studio Code, aunque en ocasiones utilizo GitHub Codespaces cuando prefiero trabajar en un entorno remoto. El proceso de despliegue es sencillo: me conecto al servidor mediante SSH, realizo un pull de los últimos cambios desde GitHub y reinicio el contenedor Docker que ejecuta Hugo. Este flujo de trabajo está automatizado mediante un archivo Docker Compose, lo que simplifica el proceso de levantar la aplicación web con cada actualización .

GoodSurgery

Thu, 06 Jun 2024 00:00:00 +0000

Este proyecto fue desarrollado durante mi Trabajo de Fin de Grado (TFG) en mi cuarto año de carrera. Su objetivo principal era crear una aplicación móvil para Android que mejorara la experiencia perioperatoria de los pacientes, proporcionando información accesible y detallada sobre los procedimientos quirúrgicos. La finalidad era reducir la ansiedad preoperatoria, mejorar la comunicación entre el equipo médico y el paciente, y aumentar la satisfacción general con el proceso quirúrgico. Para probar la aplicación y obtener resultados reales se realizó un estudio prospectivo piloto para evaluar su impacto. Este trabajo se llevó a cabo en colaboración con el Hospital Universitario Virgen del Rocío.

¿Qué es GoodSurgery?

GoodSurgery es una aplicación diseñada para ofrecer a los pacientes una guía clara y completa sobre los procedimientos quirúrgicos colorrectales. La herramienta está estructurada en secciones que abordan el preoperatorio, el postoperatorio y la información general del proceso quirúrgico, adaptándose al tipo de intervención específica de cada paciente. Su diseño intuitivo permite acceder fácilmente a contenidos útiles en cualquier momento, ayudando a los pacientes a comprender y prepararse mejor para su cirugía.

¿Por qué se creó?

GoodSurgery nace con el propósito de mejorar la comunicación entre pacientes y profesionales sanitarios en un momento crucial del proceso quirúrgico. En muchas ocasiones, la cantidad de información médica puede ser abrumadora, generando dudas e incertidumbre en los pacientes. Esta aplicación pretende aliviar esas preocupaciones, actuando como un recurso confiable y accesible que refuerza las explicaciones del equipo médico. Además, fomenta la adherencia del paciente a las indicaciones médicas, promoviendo una recuperación más rápida y efectiva, y contribuyendo a una experiencia quirúrgica más satisfactoria.

Estudio Piloto

Se llevó a cabo un estudio prospectivo piloto para evaluar la efectividad de GoodSurgery. Este incluyó dos grupos de pacientes diagnosticados con cáncer colorrectal: un grupo de estudio que utilizó la aplicación y un grupo de control que no la utilizó. El cuestionario aplicado a los participantes evaluó aspectos como la claridad de la información, la ansiedad preoperatoria, la facilidad de uso de la aplicación y la satisfacción general.

Proceso del estudio

Población de estudio: Se seleccionaron pacientes con acceso a dispositivos Android que estaban programados para cirugía colorrectal.
Metodología: Se aplicó un cuestionario predefinido a ambos grupos para comparar los resultados.
Variables analizadas: Claridad de la información, nivel de ansiedad, facilidad de uso, disponibilidad de información y satisfacción general.

Resultados

Los resultados del estudio piloto revelaron los siguientes puntos clave:

Claridad de la información: Los pacientes que utilizaron GoodSurgery percibieron la información como más clara y comprensible.
Facilidad de uso: La aplicación fue calificada como intuitiva y fácil de usar.
Ansiedad preoperatoria: Aunque no se observaron diferencias estadísticamente significativas en la reducción de la ansiedad entre ambos grupos, los usuarios de la aplicación destacaron sentirse más preparados para el procedimiento.
Satisfacción general: La mayoría de los pacientes calificaron la experiencia con la aplicación como positiva, destacando su utilidad para resolver dudas y ofrecer información en el momento oportuno.

Documentación del proyecto: Visualizar documentación en pdf

Video GoodSurgery

Análisis de Tweets y Recomendación de Películas

Sat, 25 May 2024 00:00:00 +0000

Este proyecto fue desarrollado durante la asignatura de Minería de Datos Clínicos (MDC) durante mi cuarto año de carrera.

Descripción del proyecto:

Este proyecto consiste en el desarrollo de un sistema de recomendación de películas personalizado que utiliza tweets para identificar las preferencias cinematográficas de los usuarios. El sistema es capaz de analizar los tweets de usuarios específicos, comprender si la película mencionada es de su agrado y extraer información relevante para generar recomendaciones basadas en los gustos individuales.

¿Qué hace el sistema de recomendación de películas?

El sistema recoge tweets en español, analiza el sentimiento para determinar si el usuario disfrutó o no de la película y utiliza un modelo de aprendizaje automático para identificar las películas mencionadas. A través de algoritmos de Procesamiento de Lenguaje Natural (PLN) y análisis de hashtags, el sistema clasifica los tweets, extrae las películas mencionadas y ajusta las recomendaciones de acuerdo con los géneros y las preferencias detectadas.

¿Por qué se creó?

El proyecto nace con el propósito de automatizar la forma en que los usuarios reciben recomendaciones de películas, utilizando opiniones reales y dinámicas extraídas de las redes sociales. En lugar de basarse en reseñas convencionales, el sistema emplea la información que los usuarios comparten en sus tweets, proporcionando recomendaciones personalizadas basadas en gustos expresados de manera natural y espontánea en la red social.

Proceso del sistema:

Extracción de Tweets: Se obtienen tweets en los que se mencione alguna película y se identifique si al usuario le ha gustado o no.
Análisis de Sentimientos: Se evalúan los tweets mediante técnicas de PLN para clasificar las opiniones como positivas o negativas.
Identificación de Películas: Mediante el análisis de hashtags y la normalización del texto, el sistema identifica las películas mencionadas en los tweets.
Generación de Recomendaciones: Basado en un algoritmo de recomendación, se asigna una puntuación a diferentes películas según las preferencias del usuario, proporcionando una lista final de las 20 películas más adecuadas.

Visualizar presentación del proyecto en pdf

Proyecto análisis de Tweets y recomendación de películas

AVI Health

Wed, 10 Jan 2024 00:00:00 +0000

Este proyecto fue desarrollado durante la asignatura de Gestión de Servicios y Tecnologías de la Información (GSTI) durante mi cuarto año de carrera. El objetivo principal del proyecto era desarrollar una aplicación móvil Android que cubriera la necesidad de teleasistencia de un proceso asistencial integrado (PAI) modelado por el Servicio Andaluz de Salud (SAS). En concreto, esta aplicación se centra en el proceso asistencial de teleasistencia dermatológica de pacientes con cáncer de piel.

Descripción del proyecto:

Este proyecto consiste en el desarrollo de una aplicación Android para agilizar la gestión del Proceso Asistencial Integrado (PAI) del cáncer de piel, utilizando Firebase para la gestión de datos en tiempo real. La aplicación facilita la comunicación instantánea entre el paciente y el dermatólogo, mejorando la eficiencia del tratamiento.

¿Qué es AVI Health?

AVI Health es una aplicación que permite a los pacientes realizar consultas dermatológicas, programar citas, y gestionar teleconsultas con sus médicos desde una plataforma accesible y fácil de usar. A su vez, los médicos pueden gestionar las consultas y responder a las solicitudes en tiempo real, proporcionando una atención más eficiente y cercana al paciente. Además, esta aplicación proporciona un entorno que permite al paciente compartir imágenes de su evolución con el dermatólogo, quien puede responder y hacer un seguimiento casi inmediato, reduciendo los tiempos de espera habituales. Todo esto se logra integrando Firebase como plataforma de backend para el almacenamiento de datos y la gestión de usuarios lo que asegura la escalabilidad del sistema y la protección ante pérdidas.

Además la aplicación incluye otras funcionalidades clave como el acceso a la ubicación de centros médicos cercanos en Google Maps, la gestión de perfiles tanto de médicos como de pacientes…

¿Por qué se creó?

El objetivo principal de esta aplicación es mejorar la atención al paciente y la toma de decisiones durante el proceso de tratamiento del cáncer de piel. Este tipo de cáncer afecta a miles de personas, y los tiempos de espera para consultas y diagnósticos pueden afectar negativamente el tratamiento. Con esta herramienta, se busca agilizar la comunicación entre médicos y pacientes, proporcionando una plataforma que permita gestionar consultas y teleconsultas de forma instantánea, lo que es clave en la era de la e-Health.

Documentación del proyecto: Visualizar documentación en pdf

Video AVI Health

Despliegue de servicio web con EC2 AWS

Wed, 15 Nov 2023 00:00:00 +0000

Este proyecto fue desarrollado para un trabajo de la asignatura Arquitecturas de Sistemas y Sistemas Distribuidos (ASSB) durante mi cuarto año de carrera. El objetivo principal era desplegar servicio web funcional en un entorno en la nube utilizando los servicios de AWS, manteniéndonos dentro de los límites del plan gratuito.

Este servicio web se conformaba por un balancedor de carga que distribuía las solicitudes entre dos instancias de EC2, cada una con su propio servidor Apache y página web.

Las principales tareas realizadas incluyeron:

Control y creación de alertas de costes: Configuración de alertas en AWS para asegurar que todas las operaciones se ajustaran al plan gratuito, evitando cargos adicionales no deseados.
Despliegue de instancias EC2: Levantar dos instancias de EC2 y conectarnos a ellas mediante SSH. En cada una de las instancias, instalar el servidor web Apache.
Configuración de servidores web: Configuración de los servicios de Apache en ambas instancias para que sirvieran una página web estática creada por mi mismo.
Implementación de un balanceador de carga: Despliegue de un balanceador de carga en AWS, que distribuye de manera equitativa las peticiones entrantes entre los dos servidores Apache, optimizando la carga y asegurando una mayor disponibilidad.

Visualizar memoria en pdf

Datathon Andalucía Dedalus

Mon, 20 Feb 2023 00:00:00 +0000

Este proyecto fue desarrollado durante mi tercer año de carrera para el Datathon organizado por Dedalus y AWS en Andalucía, en colaboración con dos compañeros de carrera. El principal objetivo de este datathon era trabajar con un conjunto de datos proporcionados sobre pacientes ingresados en Unidades de Cuidados Intensivos (UCI), para extraer valor clínico mediante análisis de cohortes y la creación de modelos predictivos. Se buscaba con este concurso generar información relevante para mejorar la eficiencia hospitalaria y optimizar la toma de decisiones en contextos clínicos.

Análisis de Cohortes

El análisis de cohortes fue uno de los pilares fundamentales del proyecto, ya que nos permitió identificar patrones clave entre los pacientes hospitalizados.

Realizamos un análisis específico sobre pacientes con problemas cardiovasculares. Este análisis incluyó varios aspectos importantes:

El porcentaje de casos en función del género, que nos ayudó a identificar posibles diferencias en la prevalencia de los problemas cardiovasculares entre hombres y mujeres.
La distribución de casos en relación con la edad, lo que permitió obtener un panorama claro sobre las franjas etarias más afectadas. El número de casos según el índice de masa corporal (IMC), que proporcionó una perspectiva sobre cómo el IMC influye en la incidencia de estas patologías.
El porcentaje de mortalidad en función del IMC, revelando posibles correlaciones entre el peso corporal y los desenlaces fatales en pacientes con problemas cardiovasculares.

Realizamos un análisis de cohortes más general para todos los pacientes ingresados en la UCI. Este estudio incluyó:

El número de ingresos y altas en la UCI en distintas franjas horarias, lo que proporcionó información sobre los momentos del día en los que se producían más admisiones.
La tasa de mortalidad de los pacientes en función del diagnóstico, arrojando luz sobre cuáles eran las patologías más críticas en términos de supervivencia.
El tiempo de estancia en UCI según cada diagnóstico, lo que facilitó la identificación de los tratamientos y patologías que requerían mayor tiempo de hospitalización.

Comparativa de Hospitales

Otro aspecto destacado del proyecto fue el análisis comparativo entre diferentes hospitales. En este análisis, evaluamos el rendimiento de los hospitales en función de su capacidad para tratar patologías críticas, utilizando la mortalidad como indicador clave. Este análisis nos permitió comparar la eficiencia de los hospitales en el tratamiento de ciertos diagnósticos y patologías, además de explorar el tiempo medio de estancia en la UCI por cada hospital. Con esta información, pudimos identificar posibles áreas de mejora en la gestión hospitalaria y la atención clínica en diferentes centros de salud.

Modelos Predictivos

La comunicación entre el cliente y el servidor se realizó mediante sockets SSL (Secure Sockets Layer), sobre los cuales se integró el protocolo TLS. En ambos extremos, cliente y servidor, se configuraron sockets seguros que permitían la transmisión de datos encriptados. El servidor estaba diseñado para escuchar conexiones entrantes en un puerto específico (en este caso, el puerto 3343), autenticando a los clientes mediante la verificación de sus credenciales.

Presentación: Visualizar presentación en pdf

Aplicación web para la gestión de camillas hospitalarias

Sun, 01 Jan 2023 00:00:00 +0000

Este proyecto fue desarrollado para la asignatura de Codificación y gestión de información sanitaria (CGIS) durante mi tercer año de carrera. El objetivo principal es diseñar, modelar y desarrollar una aplicación web para la gestión de las camillas hospitalarias de una entidad sanitaria.

Indice

Dominio del problema

La gestión de camas en un centro hospitalario constituye una de las tareas cotidianas de cualquier servicio de admisión y también una de la que más conflictos provocan en el funcionamiento diario del hospital. La asignación de la cama al paciente que va a ingresar constituye sólo una parte de lo que se denomina Gestión de camas, y afecta tanto a los pacientes que van a ingresar como a los ya ingresados, y a las camas libres tanto como a las ocupadas.

Objetivos

La exigencia de un adecuado control en la ocupación de camillas hospitalarias hace que se requiera una adecuada gestión de la información, un conocimiento sobre las diferentes salas de camillas, tipos de camillas, ocupación de las mismas, médicos encargados de cada paciente que tendrá una sala asignada, etc.… Dada esta situación, se plantea crear, una aplicación web donde cada usuario tendrá su propio acceso.

Usuarios del sistema

Los tres usuarios que van a poder acceder al sistema van a ser:

Administrador
Celador, solo podrá visualizar los datos que le corresponda.
Médico, solo podrá visualizar los datos que le corresponda.

Catálogo de requisitos

Requisitos de información

RI-001. Médicos. El sistema deberá de almacenar información sobre los médicos. Nombre y apellido, password, especialidad, fecha de nacimiento, si está vacunado de COVID o no, teléfono, sueldo, y fecha de contratación.

Cada médico se encargará de (1..N) salas. Un médico se encarga de N pacientes. Un medico tiene (1..N) especialidades.

RI-002. Celadores. El sistema deberá de almacenar información sobre los celadores. Nombre y apellido, password, fecha de nacimiento, teléfono, fecha de contratación y sueldo.

Cada celador se encargará de (1..N) salas. Un celador se encarga de N pacientes.

RI-003. Pacientes. El sistema deberá de almacenar información sobre los pacientes. Nombre, apellido, nuhsa y patologías.

Cada paciente tiene (1..N) patologías. 1 paciente está asociado a 1 camilla.

RI-004. Salas. El sistema deberá de almacenar información sobre las salas. La planta en la que está situada la sala, el número de la sala, número de camillas disponibles en la sala, así como el médico asignado a la sala.

N salas tiene asociadas N camillas.

RI-005. Camillas. El sistema deberá de almacenar información sobre las camillas. Tipo de camilla, celador responsable de la camilla, paciente asociado a la camilla, el precio, la fecha de adquisición y la fecha de fin de vida útil.

N camillas pertenecen a 1 empresa.

RI-006. Especialidad. El sistema deberá de almacenar información sobre las especialidades de los médicos. Estas pueden ser: cardiólogo, neurólogo, gastroenterólogo, neumólogo y traumatólogo.

RI-007. Patología. El sistema deberá de almacenar información sobre las patologías de los pacientes. Estas pueden ser: cardiológica, neurológica, gastrointestinal, respiratoria y traumatológica.

Requisitos funcionales

RF-001. Listado de médicos. Como administrador, quiero ver un listado de los médicos del sistema paginados de 10 en 10.

RF-002. Detalle de médico. Como administrador,** quiero ver el detalle de un médico.

RF-003. Creación de médico. Como administrador,** quiero crear un médico. Para ello, se debe indicar el nombre y apellido, especialidad, fecha de nacimiento, email, teléfono, DNI, si está vacunado o no de COVID, sueldo, y fecha de contratación. Deberé poder elegir la especialidad del médico entre el listado de especialidades ya existentes en la base de datos del sistema. El sistema debe impedir la creación de médico si:

El email ya existe.
El email no tiene el formato correcto.
La contraseña no tiene al menos 8 caracteres y viene la contraseña y su confirmación.
El sueldo no puede ser negativo
La especialidad tiene que ser una de las ya disponibles en el sistema.

El sistema además deberá mostrar un mensaje de error en cada uno de los casos anteriores y, en caso de éxito, navegar al listado actualizado de médicos con un mensaje de éxito.

RF-004. Edición de médico. Como administrador,** quiero editar un médico eligiéndolo a partir del listado de médicos y llevándome a una nueva pantalla donde pueda trabajar con los datos. Para ello, se debe poder modificar el nombre y apellido, email, fecha de contratación, si está vacunado de COVID o no, el sueldo y la especialidad. Deberé poder elegir la especialidad del médico entre el listado de especialidades ya existentes en la base de datos del sistema. El sistema debe impedir la edición de médico si:

El email no tiene el formato correcto.
La contraseña no tiene al menos 8 caracteres y viene la contraseña y su confirmación.
El sueldo no puede ser negativo
La especialidad tiene que ser una de las ya disponibles en el sistema.

El sistema además deberá mostrar un mensaje de error en cada uno de los casos anteriores y, en caso de éxito, navegar al listado actualizado de médicos con un mensaje de éxito.

RF-005. Borrado de médico. Como administrador, quiero borrar un médico. El sistema deberá alertarme de la irrevocabilidad de esta acción y pedir confirmación. En caso de confirmación, el sistema deberá borrar el médico y navegar al listado actualizado de médicos con un mensaje de éxito.

RF-006. Listado de médicos. Como médico, quiero ver un listado de los médicos del sistema.

RF-007. Detalle de médico. Como médico,** quiero ver el detalle de un médico.

RF-008. Listado de celadores. Como administrador, quiero ver un listado de los celadores del sistema paginados de 10 en 10.

RF-009. Detalle de celador. Como administrador,** quiero ver el detalle de un celador.

RF-010. Creación de celador. Como administrador,** quiero crear un celador. Para ello, se debe indicar el nombre y apellido, fecha de nacimiento, teléfono, email, fecha de contratación y sueldo. El sistema debe impedir la creación de celador si:

El email ya existe.
El email no tiene el formato correcto.
La contraseña no tiene al menos 8 caracteres y viene la contraseña y su confirmación.
El sueldo no puede ser negativo

El sistema además deberá mostrar un mensaje de error en cada uno de los casos anteriores y, en caso de éxito, navegar al listado actualizado de celadores con un mensaje de éxito.

RF-011. Edición de celador. Como administrador,** quiero editar un celador eligiéndolo a partir del listado de celadores y llevándome a una nueva pantalla donde pueda trabajar con los datos. Para ello, se debe poder modificar el nombre y apellido, fecha de nacimiento, teléfono, email, DNI, fecha de contratación y sueldo. El sistema debe impedir la edición de médico si:

El email no tiene el formato correcto.
La contraseña no tiene al menos 8 caracteres y viene la contraseña y su confirmación.
El sueldo no puede ser negativo

El sistema además deberá mostrar un mensaje de error en cada uno de los casos anteriores y, en caso de éxito, navegar al listado actualizado de médicos con un mensaje de éxito.

RF-012. Borrado de celador. Como administrador, quiero borrar un celador. El sistema deberá alertarme de la irrevocabilidad de esta acción y pedir confirmación. En caso de confirmación, el sistema deberá borrar el celador y navegar al listado actualizado de celadores con un mensaje de éxito.

RF-013. Listado de celadores. Como celador, quiero ver un listado de todos los celadores del sistema.

RF-014. Detalle de celador. Como celador,** quiero ver el detalle de un celador.

RF-015. Listado de pacientes. Como administrador, quiero ver un listado de los pacientes del sistema paginados de 10 en 10.

RF-016. Detalle de paciente. Como administrador,** quiero ver el detalle de un paciente.

RF-017. Creación de paciente. Como administrador,** quiero crear un paciente. Para ello, se debe indicar el nombre, apellido, el número de Nusha y patologías. Deberé poder elegir la patología del paciente entre el listado de patologías ya existentes en la base de datos del sistema. El sistema debe impedir la creación de paciente si:

La patología tiene que ser una de las ya disponibles en el sistema.

El sistema además deberá mostrar un mensaje de error en cada uno de los casos anteriores y, en caso de éxito, navegar al listado actualizado de pacientes con un mensaje de éxito.

RF-018. Edición de paciente. Como administrador,** quiero editar un paciente eligiéndolo a partir del listado de pacientes y llevándome a una nueva pantalla donde pueda trabajar con los datos. Para ello, se debe poder modificar el nombre y apellido, número de Nuhsa y patologías. Deberé poder elegir la patología del paciente entre el listado de patologías ya existentes en la base de datos del sistema. El sistema debe impedir la edición de paciente si:

La patología tiene que ser una de las ya disponibles en el sistema.

El sistema además deberá mostrar un mensaje de error en cada uno de los casos anteriores y, en caso de éxito, navegar al listado actualizado de médicos con un mensaje de éxito.

RF-019. Borrado de paciente. Como administrador, quiero borrar un paciente. El sistema deberá alertarme de la irrevocabilidad de esta acción y pedir confirmación. En caso de confirmación, el sistema deberá borrar el paciente y navegar al listado actualizado de pacientes con un mensaje de éxito.

RF-020. Listado de pacientes. Como médico, quiero ver un listado de todos los pacientes del sistema.

RF-021. Detalle de paciente. Como médico,** quiero ver el detalle de un paciente.

RF-022. Listado de pacientes. Como celador, quiero ver un listado de todos los pacientes del sistema.

RF-023. Detalle de paciente. Como celador,** quiero ver el detalle de un paciente.

RF-024. Detalles camilla. Como celador, quiero una lista donde aparezca toda la información sobre las camillas que tengo asignada.**

RF-025. Precio camillas. Como administrador, quiero una lista donde aparezca el precio total de las camillas del hospital.

RF-026. Salas asignadas. Como médico, quiero una lista de todas las salas que tengo asignadas, junto a las camillas que pertenecen a la sala.

RF-027. Camillas asignadas. Como celador, quiero una lista de todas las camillas que tengo asignadas, junto al paciente asociado.

RF-028. Costo total inventarios. Como administrador, el costo total de las camillas.

RF-029. Costo anual trabajadores. Como administrador, quiero ver un listado de los sueldos (el costo que tendría en 12 meses) de cada uno de los trabajadores.

RF-030. Costo total trabajadores. Como administrador, el costo total en un mes de los trabajadores actuales de la empresa.

RF-031. Listado de patologías. Como administrador, quiero ver un listado de todas las patologías del sistema.

RF-032. Creación de patología. Como administrador,** quiero crear una patología. Para ello, se debe indicar el nombre de la patología.

RF-033. Edición de patología. Como administrador,** quiero editar una patología eligiéndolo a partir del listado de patologías y llevándome a una nueva pantalla donde pueda trabajar con los datos. Para ello, se debe poder modificar el nombre de la patología.

RF-034. Borrado de patología. Como administrador, quiero borrar una patología. El sistema deberá alertarme de la irrevocabilidad de esta acción y pedir confirmación. En caso de confirmación, el sistema deberá borrar la patología y navegar al listado actualizado de patologías con un mensaje de éxito.

RF-035. Listado de especialidades. Como administrador, quiero ver un listado de todas las especialidades del sistema.

RF-036. Creación de especialidad. Como administrador,** quiero crear una especialidad. Para ello, se debe indicar el nombre de la especialidad.

RF-037. Edición de especialidad. Como administrador,** quiero editar una especialidad eligiéndolo a partir del listado de especialidades y llevándome a una nueva pantalla donde pueda trabajar con los datos. Para ello, se debe poder modificar el nombre de la especialidad.

RF-038. Borrado de especialidad. Como administrador, quiero borrar una especialidad. El sistema deberá alertarme de la irrevocabilidad de esta acción y pedir confirmación. En caso de confirmación, el sistema deberá borrar la especialidad y navegar al listado actualizado de especialidades con un mensaje de éxito.

RF-039. Listado de tipos de camilla. Como administrador, quiero ver un listado de todos los tipos de camilla del sistema.

RF-040. Creación de tipo de camilla. Como administrador,** quiero crear un tipo de camilla. Para ello, se debe indicar el nombre del tipo de camilla.

RF-041. Edición de tipo de camilla. Como administrador,** quiero editar un tipo de camilla eligiéndolo a partir del listado de los tipos de camilla y llevándome a una nueva pantalla donde pueda trabajar con los datos. Para ello, se debe poder modificar el tipo de camilla.

RF-042. Borrado de tipo de camilla. Como administrador, quiero borrar un tipo de camilla. El sistema deberá alertarme de la irrevocabilidad de esta acción y pedir confirmación. En caso de confirmación, el sistema deberá borrar el tipo de camilla y navegar al listado actualizado de tipos de camilla con un mensaje de éxito.

Requisitos no funcionales

RNF-001. Seguridad: El sistema debe estar protegido contra el acceso no autorizado.

RNF-002. Actuación: El sistema debe poder manejar el número requerido de usuarios sin ninguna degradación en el rendimiento.

RNF-003. Escalabilidad: El sistema debe ser capaz de escalar hacia arriba o hacia abajo según sea necesario.

RNF-004. Disponibilidad: El sistema debe estar disponible cuando sea necesario.

RNF-005. Mantenimiento: El sistema debe ser fácil de mantener y actualizar.

RNF-006. Portabilidad: El sistema debe poder ejecutarse en diferentes plataformas con cambios mínimos.

RNF-007. Fiabilidad: El sistema debe ser confiable y cumplir con los requisitos del usuario.

RNF-008. Usabilidad: El sistema debe ser fácil de usar y comprender.

RNF-009. Compatibilidad: El sistema debe ser compatible con otros sistemas.

RNF-010. Compliancia: El sistema debe cumplir con todas las leyes y reglamentos aplicables.

Reglas de negocio

RN-001. Un celador solo puede tener asignadas 10 camillas como máximo a la vez.

RN-002. Un médico solo puede tener asignadas 2 salas como máximo a la vez.

RN-003. El sueldo de los celadores debe estar entre los 1200 y 1400 euros.

Modelo conceptual UML

Implementación de una Arquitectura Segura Cliente-Servidor en Java utilizando TLS

Sun, 01 Jan 2023 00:00:00 +0000

Este proyecto fue desarrollado durante la asignatura de Seguridad, Confidencialidad y Gestión de la Identidad (SCGI) durante mi tercer año de carrera. Este proyecto se centró en el diseño y desarrollo de una arquitectura cliente-servidor segura utilizando el protocolo Transport Layer Security (TLS), con el objetivo de asegurar la confidencialidad, integridad y autenticidad de las comunicaciones.

Contexto y Objetivo

El proyecto surgió de la necesidad de asegurar las comunicaciones en una aplicación que permitiera la transmisión de datos sensibles, como credenciales de usuario (login/password), entre clientes y un servidor central. Este tipo de aplicaciones es especialmente relevante en entornos donde la privacidad de los datos es crucial, como el sector de la salud, la banca y cualquier sistema donde los usuarios deban autenticar su identidad para acceder a servicios.

Configuración de KeyStores y TrustStores

Para implementar la seguridad mediante TLS, fue necesario configurar tanto el almacén de claves (KeyStore) como el almacén de certificados (TrustStore). Estos elementos permiten la autenticación mutua entre el cliente y el servidor. El KeyStore contiene las claves privadas y los certificados asociados que identifican a la entidad (cliente o servidor), mientras que el TrustStore gestiona los certificados de las entidades de confianza, permitiendo validar que las contrapartes de la comunicación son legítimas.

En el desarrollo de este proyecto, se utilizó Keytool, una herramienta incluida en el JDK de Java, para crear y gestionar los certificados. El proceso requirió la configuración de las variables de entorno como JAVA_HOME y PATH, para facilitar el uso de esta herramienta desde la línea de comandos.

Implementación de Sockets TLS

Servidor TLS: El servidor se encargaba de recibir las conexiones de los clientes y autenticar a cada usuario mediante la verificación de sus credenciales (nombre de usuario y contraseña). Además, proporcionaba respuestas basadas en el resultado de esta verificación, informando al cliente si la autenticación había sido exitosa o fallida.
Cliente TLS: El cliente establecía una conexión segura con el servidor y enviaba las credenciales del usuario para su verificación. La respuesta del servidor se mostraba en una interfaz de usuario sencilla, indicando si el proceso de autenticación había sido exitoso o si hubo algún error.

Pruebas de Comunicación y Seguridad

Se realizaron pruebas de comunicación tanto con seguridad como sin ella, con el fin de destacar la importancia del uso de TLS en aplicaciones que manejan información sensible. Para las pruebas sin seguridad, se implementó un socket sin cifrado que permitía observar cómo un atacante, usando herramientas como Wireshark, podía capturar y visualizar en texto claro las credenciales de usuario transmitidas.

En contraste, al habilitar TLS, se observó cómo toda la información transmitida se encontraba encriptada, imposibilitando que un atacante pudiera leer los datos capturados en la red. Esto demostró la efectividad de TLS para proteger la confidencialidad y la integridad de la información.

Rendimiento y Concurrencia

Un aspecto clave de este proyecto fue la validación del rendimiento del sistema, específicamente la capacidad de manejar múltiples conexiones concurrentes. El servidor fue configurado para gestionar hasta 300 conexiones simultáneas, lo cual fue logrado utilizando hilos (threads) en Java para manejar las solicitudes en paralelo. A pesar de que las conexiones se realizaban de forma secuencial en las pruebas iniciales (una cada segundo), el sistema demostró ser robusto al procesar las peticiones de forma eficiente sin comprometer la seguridad o la estabilidad.

Documentación del proyecto

BYODSEC-BRING YOUR OWN DEVICE SEGURO PARA UNA ENTIDAD HOSPITALARIA USANDO ROAD WARRIOR VPN TLS

Computación paralela en procesadores multinúcleos con OpenMP

Thu, 20 Oct 2022 00:00:00 +0000

Este proyecto fue desarrollado durante la asignatura de Arquitectura de Sistemas y Software de Base (ASSB) durante mi segundo año de carrera. El objetivo principal era implementar un algoritmo para el cálculo del número Pi utilizando el método de MonteCarlo programando en C tanto de forma secuencial como utilizando técnicas de programación paralela para aprovechar al máximo los recursos de los procesadores multinúcleo mediante la librería OpenMP, que permite ejecutar código en múltiples hilos de manera eficiente.

Las principales tareas realizadas fueron las siguientes:

Desarrollo de la versión secuencial y paralela del algoritmo: Implementé un programa que simula el lanzamiento de “dardos” aleatorios dentro de un cuadrado inscrito en un círculo. La relación entre los aciertos dentro del círculo y los lanzamientos totales permite calcular el valor de Pi. En la versión paralela, utilicé OpenMP para dividir el trabajo entre varios hilos, aprovechando al máximo los recursos de los procesadores multinúcleo.
Mediciones de tiempo y análisis de rendimiento: Tras desarrollar las dos versiones del programa, realicé mediciones de tiempo para evaluar el rendimiento de la versión paralela en comparación con la secuencial. Utilicé diferentes configuraciones de hilos, desde un solo hilo hasta más del doble de los núcleos físicos del procesador, con el objetivo de analizar la aceleración y escalabilidad del algoritmo. La aceleración se calculó como la relación entre el tiempo de ejecución en un único hilo y el tiempo de ejecución con varios hilos.
Optimización y gestión de recursos compartidos: Durante el desarrollo, fue necesario resolver problemas comunes de la programación paralela, como las condiciones de carrera. En este caso, utilicé directivas de OpenMP para definir variables privadas en cada hilo, evitando que varios hilos accedieran simultáneamente a las mismas variables globales y afectaran el resultado final.
Generación de gráficos de rendimiento: Tras recopilar los datos de tiempos de ejecución y aceleración, generé gráficos para visualizar el rendimiento del programa a medida que aumentaba el número de hilos. Estos gráficos demostraron cómo la aplicación escalaba con un mayor número de hilos, destacando las ventajas y limitaciones de la paralelización en un entorno de memoria compartida.

Documentación del proyecto: Visualizar documentación en pdf

Proyecto de datos con Weka

Sun, 25 Sep 2022 00:00:00 +0000

Este proyecto fue desarrollado como parte de la asignatura de Sistemas Inteligentes (SI) durante mi tercer año de carrera. El trabajo consistió en aplicar diferentes algoritmos de clasificación y preprocesamiento de datos para resolver un problema hipotético sobre un viaje espacial en un futuro distante. El objetivo principal era predecir, basado en ciertos atributos de los pasajeros, si estos serían transportados a una dimensión alternativa tras un accidente espacial.

Contexto y Objetivo

El problema plantea la situación en la que una nave espacial, con miles de pasajeros a bordo, choca con una anomalía espacio-temporal, y la mitad de los pasajeros son transportados a otra dimensión. El reto del proyecto consistía en desarrollar un modelo predictivo para identificar qué pasajeros habrían sido transportados a esa dimensión alternativa, basado en atributos como la edad, el planeta de origen, si estaban en crio sueño, y otros factores.

Preprocesamiento de Datos

El conjunto de datos proporcionado contenía información sobre aproximadamente 8700 pasajeros, y constaba de 14 atributos, tanto numéricos como nominales. Inicialmente, se eliminaron ciertas variables consideradas irrelevantes, como el destino del pasajero y las cantidades gastadas en servicios de lujo. A continuación, se realizaron imputaciones de valores perdidos y se binarizaron las variables categóricas utilizando One Hot Encoding.

Para mejorar la eficiencia de los algoritmos de clasificación basados en distancia, como KNN, se realizó la normalización de las variables numéricas, en particular la edad de los pasajeros, con el fin de garantizar una comparación justa entre los diferentes atributos.

Algoritmos Implementados

Se probaron diversos algoritmos de clasificación, entre ellos:

ZeroR: Utilizado como baseline, clasificando todos los pasajeros en función del valor de la clase más frecuente.
J48: Un algoritmo de tipo árbol de decisión que mostró buenos resultados tras un proceso de poda para evitar el sobreajuste.
KNN (k-Nearest Neighbors): Este clasificador se basó en la similitud entre individuos para predecir si un pasajero sería transportado. Se probaron diferentes valores de K, siendo 9 el valor que obtuvo mejores resultados.
Naive Bayes: Un algoritmo que, pese a su simplicidad, proporcionó buenos resultados al asumir la independencia entre los atributos.

Resultados

El mejor rendimiento se obtuvo utilizando el algoritmo KNN con un valor de K=9, logrando una precisión del 74.3%. En comparación, los otros algoritmos mostraron rendimientos ligeramente inferiores. Los experimentos realizados con validación cruzada ayudaron a evaluar de manera más confiable los modelos, asegurando que no hubiese sobreajuste.

Documentación del proyecto: Visualizar documentación en pdf

Base de Datos para la Gestión del Equipamiento de Quirófanos

Wed, 25 May 2022 00:00:00 +0000

Este proyecto fue desarrollado durante la asignatura de Bases de Datos (BD) durante mi segundo año de carrera. El objetivo principal era diseñar, modelar y desarrollar una base de datos SQL para gestionar y almacenar la información de las instalaciones y equipamientos electromédicos de un quirófano. La base de datos permitiría no solo gestionar los equipos y su mantenimiento, sino también asegurar el cumplimiento de regulaciones sanitarias, controlar el valor del equipamiento, supervisar las revisiones periódicas…

Descripción del problema

Las exigencias de cumplimiento de unos determinados estándares de calidad y asepsia en un quirófano llevan aparejado una adecuada gestión y control de todos sus elementos, de su conocimiento, mantenimiento y sustitución o reparación. Intervienen diferentes perfiles en esta función y deben poder acceder a la información de forma ordenada. Se plantea, para dar respuesta a esta situación, la creación de una base de datos para gestionar toda la información relativa a los equipos, instalaciones y equipamiento electro-médico que tiene un quirófano. El objetivo es que los tres perfiles de acceso (el ingeniero biomédico, el director de servicios generales del hospital y el ingeniero de mantenimiento) puedan acceder y conocer todos los elementos de nuestro quirófano, así como sus atributos, la empresa a la que han sido comprados, saber cada cuanto hay que hacer una revisión de la maquinaría o conocer los valores entre los que se debe mover nuestro equipo para que desempeñe un correcto funcionamiento (temperatura, voltaje…) entre otros.

Solución

En el caso que estamos trabajando, se plantea crear una base de datos relacional para un quirófano estándar, es decir, una base de datos general que podrá ser aplicada a cualquier tipo de quirófano, y que si es necesario podrá ser escalable para un tipo de quirófano más complejo.

Requisitos generales

Almacenar los datos personales del ingeniero biomédico encargado del mantenimiento de las máquinas de la empresa a la que pertenece.
Guardar toda la información del equipamiento electro-médico del que se dispone, así como información sobre las normativas de climatización y electricidad.
El sistema deberá ser capaz de detectar cualquier fallo en la información tanto del equipamiento electro-médico como en la electricidad y la climatización del quirófano.
El sistema deberá gestionar las revisiones de las instalaciones del quirófano y controlar su adecuado funcionamiento.
El sistema permitirá consultar la información de la base de datos y filtrarla a partir de los diferentes atributos; como por ejemplo el precio, el año de adquisición y el peso del equipamiento electro-médico, atributos personales, como nombre y apellidos y número de seguridad social.

Visualizar proyecto en pdf

Proyecto base de datos del equipamiento de un quirófano

Archivos

Sun, 06 Mar 2022 00:00:00 +0000

Buscar

Mon, 01 Jan 0001 00:00:00 +0000

Israel Brea Piñero

Pixora - Aplicación nativa Android

Características

Detalles Técnicos

Publicación

Repositorio del Proyecto

Visualizar proyecto en pdf

Vídeo Pixora

Pixora - Aplicación nativa iOS

Características

Detalles Técnicos

Publicación

Repositorio del Proyecto

Visualizar proyecto en pdf

Vídeo Pixora

Creación de una API con Express y despliegue en la nube con AWS

Objetivos del proyecto

Funcionalidades principales

1. Autenticación y seguridad

2. Gestión de películas (/movies)

3. Gestión de valoraciones (/ratings)

4. Gestión de la lista de películas por ver (/watchlist)

Implementación técnica

Tecnologías utilizadas

Persistencia y base de datos

Despliegue en AWS

1. Creación de AMI con Packer

2. Infraestructura con Terraform

Automatización y escalabilidad

Conclusiones y aprendizajes

Recursos y código fuente

Procesamiento de XML con DOM y SAX

Funcionalidades principales

LikeMovies

Funcionalidades principales

Estructura de la aplicación

Características técnicas destacadas

Conclusión

Video Funcionalidad LikeMovies

SCORECARD TPNi CG

¿Qué es SCORECARD TPNi CG?

¿Qué incluye la aplicación?

Desarrollo y publicación

Avales y Reconocimientos

Video SCORECARD TPNi CG

Creación y despliegue de portfolio web con Hugo.

Descripción del Proyecto

DevOps y Despliegue

GoodSurgery

¿Qué es GoodSurgery?

¿Por qué se creó?

Estudio Piloto

Resultados

Video GoodSurgery

Análisis de Tweets y Recomendación de Películas

Descripción del proyecto:

¿Qué hace el sistema de recomendación de películas?

¿Por qué se creó?

Proceso del sistema:

Visualizar presentación del proyecto en pdf

AVI Health

Descripción del proyecto:

¿Qué es AVI Health?

¿Por qué se creó?

Video AVI Health

Despliegue de servicio web con EC2 AWS

Datathon Andalucía Dedalus

Análisis de Cohortes

Comparativa de Hospitales

Modelos Predictivos

Aplicación web para la gestión de camillas hospitalarias

Indice

Dominio del problema

Objetivos

Usuarios del sistema

Catálogo de requisitos

Requisitos de información

Requisitos funcionales

Requisitos no funcionales

Reglas de negocio

2. Gestión de películas (`/movies`)

3. Gestión de valoraciones (`/ratings`)

4. Gestión de la lista de películas por ver (`/watchlist`)