DEV Community: Evolve

10.430 muertes, 10 preguntas y un pipeline en Python: lo que los datos de violencia policial en EE.UU. no te cuentan a simple vista

David Naranjo Ramírez — Wed, 27 May 2026 16:40:01 +0000

Cuando el Washington Post empezó a contar los muertos en 2015, el FBI subestimaba casi el 50% de los casos. Ese dato me enganchó. No por el morbo, sino por lo que implica metodológicamente: si los registros oficiales fallan de manera tan estrepitosa, ¿qué más se pierde cuando no miras bien los datos?

Ese fue el punto de partida de EDAFatalForce, mi proyecto de Análisis Exploratorio de Datos del Máster de Data Science en Evolve.

El dataset: periodismo de datos como fuente primaria

El core del proyecto es la base de datos Fatal Force del Washington Post — 10.430 incidentes fatales entre 2015 y 2024 con variables como raza, edad, armamento, comportamiento de fuga, nivel de amenaza percibida y si el agente llevaba cámara corporal.

Para enriquecerlo crucé tres fuentes:

Census Bureau ACS 2020 — datos socioeconómicos de 3.221 condados (ingresos, pobreza, desempleo)
NCSL — políticas de cámara corporal por estado
Tabla FIPS — para enlazar condados con el Census

El mayor desafío no fue el modelado. Fue la calidad del dato. El 45% de los registros no tenía condado, lo que bloqueaba cualquier join con el Census. La solución: construir internamente un mapa ciudad + estado → condado usando la moda de los registros que sí lo tenían. Resultado: de 45% de nulos a 17,4%. Un cambio que desbloqueó más de 2.800 filas para el análisis socioeconómico.

El proceso: bugs, fixes y un pipeline modular

El proyecto está estructurado como un pipeline reproducible en src/: limpieza → enriquecimiento → feature engineering → EDA. Un solo python main.py lo ejecuta todo, incluyendo la descarga del Census.

Durante la auditoría encontré dos bugs críticos en el feature engineering que hubieran invalidado análisis completos:

Bug 1 — La paradoja de la fuga estaba rota. El valor raw "not" (53% de los registros) no coincidía con la regex diseñada para mapear "no huía", así que más de 5.500 víctimas que no huían quedaban clasificadas como comportamiento desconocido. La pregunta Q2 entera era inválida.

Bug 2 — "Undetermined" contaba como armado. Los 463 registros con armamento "undetermined" heredaban is_armed = 1.0 por caer en el default del np.select. Víctimas con armamento desconocido aparecían como armadas en todas las tasas.

Ambos fixes son de una línea. El impacto analítico, considerable.

Resultados: lo que los datos dicen y lo que no

Diez preguntas, diez respuestas con tests estadísticos. Las más reveladoras:

El ranking de estados respecto a número de incidentes fatales cambia por completo al normalizar. California lidera con +1200 incidentes brutos. Pero al dividir por población, Misisipi sube al primer puesto con 85,5 casos por 100.000 habitantes. El volumen engaña. La tasa informa.

Los protocolos de crisis mental funcionan. Los incidentes con signos de enfermedad mental presentan una tasa de amenaza letal del 35,3% frente al 44,4% del resto (χ²=55,18, p<0,001). El resultado más robusto estadísticamente de todo el análisis, y el más contraintuitivo.

Huir en coche es más peligroso que no huir. La tasa de amenaza letal resulta 4 puntos y medio porcentuales mayor en persecuciones vehiculares que en personas que no huyen. Un vehículo a alta velocidad es percibido como amenaza física directa, no solo como evasión.

Entre víctimas desarmadas, la raza sigue siendo predictora. Las víctimas negras desarmadas tienen una tasa letal 4,2 puntos superior a las blancas (χ²=11,65, p=0,003). threat_level es la narrativa del agente, no un hecho verificado — esa limitación es parte del análisis, no una nota al pie.

Lo que aprendí

Que los bugs de feature engineering son los más peligrosos porque no rompen el código — producen resultados plausibles pero incorrectos. Y que documentar las limitaciones no debilita un análisis: lo hace honesto y, paradójicamente, más creíble.

Si lo repitiera, integraría coordenadas lat/lon para análisis espaciales con DBSCAN geográfico. Los hotspots por condado cuentan la mitad de la historia; los hotspots dentro del condado contarían la otra.

📁 Repo completo en GitHub: https://github.com/dnarram/Proyecto-Master-DataScience-Evolve-DavidNaranjoRamirez-EDAFatalForce

Proyecto desarrollado durante el Máster en Data Science de Evolve.

Construyendo un recomendador de películas en Python: de los datos al modelo

Alberto Martinez — Mon, 25 May 2026 18:22:03 +0000

Introducción

Los sistemas de recomendación están presentes en muchas plataformas digitales: streaming, e-commerce, música, formación online o personalización de contenidos. Su objetivo es ayudar al usuario a descubrir elementos relevantes dentro de catálogos cada vez más grandes.

En este proyecto he desarrollado CineMatch AI, un sistema de recomendación de películas basado en filtrado colaborativo por ítems. La idea principal es sencilla: dada una película de referencia, el sistema recomienda otras películas similares a partir de los patrones históricos de valoración de los usuarios.

El objetivo no era construir una solución empresarial completa, sino un prototipo funcional, reproducible y bien estructurado que permitiera trabajar un flujo completo de Data Science: análisis de datos, preprocesamiento, construcción del sistema de recomendación, evaluación exploratoria y presentación mediante una interfaz sencilla.

Dataset utilizado

Para el proyecto he utilizado el dataset MovieLens, una referencia habitual para trabajar con sistemas de recomendación.

El conjunto de datos incluye información sobre películas, usuarios y valoraciones. En este caso, el trabajo se ha centrado principalmente en dos archivos:

ratings.csv
movies.csv

Tras el proceso de filtrado, el sistema trabaja con:

446.702 ratings finales
3.728 películas
4.356 usuarios activos
una matriz usuario-película con una densidad aproximada del 2,75%

Este último punto es importante, porque en los sistemas de recomendación es habitual trabajar con matrices muy dispersas: muchos usuarios han valorado solo una pequeña parte del catálogo total.

Proceso seguido

El flujo del proyecto se divide en varias fases.

Primero se realizó la carga y exploración inicial de los datos, revisando el volumen de registros, la distribución de ratings y la información disponible sobre las películas.

Después se aplicaron filtros para mejorar la calidad de las recomendaciones:

películas con al menos 20 valoraciones.
usuarios con al menos 10 valoraciones.

Este filtrado reduce ruido y evita que el sistema se base en películas o usuarios con muy poca información histórica.

A continuación se construyó una matriz usuario-película, donde cada fila representa un usuario, cada columna una película y cada valor corresponde a la puntuación asignada. A partir de esta matriz, el sistema compara películas entre sí usando similitud del coseno.

La lógica es la siguiente: si dos películas han sido valoradas de forma parecida por muchos usuarios, el sistema interpreta que existe cierta similitud entre ellas.

Sistema de recomendación

El recomendador está basado en filtrado colaborativo por ítems. En lugar de comparar usuarios entre sí, compara películas a partir de los patrones de valoración.

Este enfoque tiene varias ventajas:

es fácil de explicar.
funciona bien cuando existen suficientes valoraciones.
permite generar recomendaciones interpretables.
puede adaptarse a otros dominios como productos, canciones, cursos o contenidos digitales.

Además del análisis en notebook, el proyecto incluye una pequeña aplicación con Streamlit, pensada para probar el sistema de forma visual. Desde la interfaz se puede buscar una película, seleccionar una coincidencia del catálogo y obtener un top 5 o top 10 de recomendaciones con su score de similitud.

También se incluye una API básica con FastAPI como demostración complementaria de cómo podría exponerse la lógica del recomendador.

Resultados

El sistema genera recomendaciones coherentes, especialmente para películas con suficientes valoraciones históricas.

Algunos resultados principales del análisis fueron:

matriz usuario-película de 4.356 usuarios por 3.728 películas.
446.702 ratings utilizados tras el filtrado.
similitud media top-N de 0,5662.
consistencia media de géneros del 81,5%.
94 de 100 películas evaluadas con una consistencia de géneros superior al 50%.

Por ejemplo, para una película como Scarface (1983), el sistema recomienda títulos relacionados con géneros como crimen, drama, thriller o acción, lo que muestra una cierta coherencia temática en las recomendaciones.

Limitaciones

Como ocurre en muchos sistemas de recomendación, el proyecto también tiene limitaciones.

La más importante es el problema de cold start: si una película o usuario no tiene valoraciones suficientes, el sistema no dispone de información histórica para generar recomendaciones fiables.

Además, el filtrado por popularidad mejora la calidad de las recomendaciones, pero reduce la cobertura total del catálogo. También hay que tener en cuenta que el sistema recomienda a partir de patrones históricos de valoración, no por una comprensión semántica profunda del contenido de las películas.

Por último, la evaluación realizada es exploratoria. No debe interpretarse como una evaluación supervisada definitiva, ya que no se ha aplicado una separación train/test ni métricas de ranking como Precision@K, Recall@K o NDCG, habituales en la evaluación de sistemas de recomendación.

Aprendizajes

Este proyecto me ha servido para entender mejor cómo se estructura un sistema de recomendación desde una perspectiva práctica.

Más allá de la técnica de similitud, una parte importante del trabajo ha estado en preparar los datos, tomar decisiones de filtrado, construir una estructura reproducible y presentar los resultados de forma clara.

También me ha parecido especialmente interesante comprobar cómo una técnica relativamente sencilla, como la similitud del coseno, puede generar recomendaciones razonables cuando los datos están bien tratados.

Próximos pasos

Algunas mejoras naturales para futuras versiones serían:

combinar ratings y géneros en un sistema híbrido.
incorporar técnicas de factorización matricial como SVD o NMF.
mejorar la evaluación offline con métricas de ranking.
guardar la matriz de similitud precomputada para acelerar la demo.
desplegar la aplicación para facilitar su uso externo.

Repositorio

El código completo del proyecto está disponible en GitHub:

https://github.com/evolve-space/Proyecto-Master-DataScience-Evolve-AlbertoMartinez

Podeis contactarme en mi LinkedIn:
https://www.linkedin.com/in/albertomartinezsanchez

Proyecto desarrollado durante el Máster en Data Science & Desarrollo de IA de Evolve.

What 3.9M powerlifting records tell us about competition strategy — an EDA with Python

Rubén Gil — Sat, 23 May 2026 20:02:03 +0000

What 3.9M powerlifting records tell us about competition strategy — an EDA with Python

When I started this EDA project for my Data Science Master at Evolve, I picked the Open Powerlifting dataset because beyond being a gym-rat, I've always been curious about the competition strategy in powerlifting.

The dataset

Open Powerlifting is an open-source project that tracks powerlifting competition results worldwide. The full dataset has ~3.9M rows and 42 columns covering athlete info, every single lift attempt, and performance metrics.

Before any analysis I filtered it down to sanctioned, drug-tested competitions only and kept only the columns I'd actually use. The main challenge: negative values mean a failed lift, not bad data. That required building boolean columns to track success/failure before converting negatives to NaN.

The process

Fully modularized in Python using pandas, numpy, seaborn, matplotlib and pingouin. The pipeline runs end-to-end from main.py:

raw CSV → filter → clean → features → assert → analyze

Imputation was done conservatively; age from AgeClass ranges, bodyweight from weight class, never synthetic values. Also, NaN values were filtered dynamically for each question.

Results

Peak performance age: Athletes peak between 22-24 years old and decline steadily after. No meaningful difference between men and women once normalized by bodyweight.

Where do athletes fail most? Bench press has a 54% fail rate on the 3rd attempt. Squat and deadlift sit around 36-40%. The gap is consistent across sexes and equipment types — bench just behaves differently.

The 4th attempt: When athletes take a 4th attempt, they succeed ~77% of the time on average. Deadlift leads at 83%. This is the most actionable insight of the whole project — just take the 4th attempt.

What I learned

About powerlifting
Athletes peak between 22-24, always take the 4th attempt and make sure you won't fail the 3rd one, it can change the whole competition.

About analysing data
If you have enough data, maybe it's better to not fill the gaps with artificial values. Also, some features must be built before cleaning or you'll spend an hour chating with AI wondering why all your booleans are NaN.

Full code: github.com/rubengil-dev/power_lifting_analisis

Project developed during the Data Science Master at Evolve.

De hojas de cálculo a IA: construyendo una plataforma SRM moderna

Jose Martos — Fri, 22 May 2026 11:39:45 +0000

Cómo construí ProcureFlow AI: una plataforma SRM con IA y automatización empresarial

Muchas pequeñas y medianas empresas siguen gestionando proveedores mediante hojas de cálculo, emails dispersos y procesos manuales difíciles de escalar. Cuando empecé a trabajar en ProcureFlow AI, quería resolver precisamente ese problema: crear una plataforma moderna que centralizara la gestión de proveedores y permitiera automatizar procesos internos usando inteligencia artificial.

Lo interesante del proyecto no era únicamente desarrollar un panel administrativo, sino diseñar una arquitectura preparada para evolucionar hacia automatizaciones inteligentes reales. Quería construir algo cercano a un entorno empresarial moderno, donde frontend, backend, workflows y servicios de IA estuvieran desacoplados y listos para crecer.

ProcureFlow AI nace como una solución SRM (Supplier Relationship Management), enfocada en digitalizar procesos relacionados con compras, proveedores y automatización operativa. A diferencia de los CRMs tradicionales centrados en clientes, este proyecto pone el foco en la organización interna y la eficiencia empresarial.

El entorno y la arquitectura del proyecto

En este caso no trabajé con un dataset clásico de machine learning, sino con un entorno full stack orientado a procesos empresariales reales. El principal reto fue diseñar una arquitectura modular y flexible capaz de soportar múltiples funcionalidades:

Gestión centralizada de proveedores
Automatización de procesos internos
Integración de inteligencia artificial
Sistema de autenticación y roles
Infraestructura escalable

La aplicación fue desarrollada usando:

React y Tailwind CSS para el frontend
Symfony y PHP para el backend API REST
MySQL como base de datos
Docker para facilitar despliegue y desarrollo
OpenAI API para integración de IA

La separación entre frontend, backend y servicios de automatización fue una decisión clave desde el principio, ya que quería evitar una arquitectura monolítica difícil de mantener en el futuro.

El proceso de desarrollo

El desarrollo comenzó definiendo primero la estructura del backend y las entidades principales relacionadas con proveedores, usuarios y procesos internos. Una vez definida la API REST en Symfony, construí el frontend en React consumiendo los distintos endpoints.

Uno de los aspectos más interesantes fue integrar automatización e inteligencia artificial dentro del flujo empresarial. En lugar de añadir IA “porque sí”, intenté enfocarla hacia casos de uso reales:

Asistencia contextual
Automatización de tareas repetitivas
Generación de respuestas y apoyo operativo
Preparación para workflows inteligentes

Otro reto importante fue diseñar un sistema fácilmente desplegable. Para ello trabajé con Docker y una arquitectura separada por servicios, lo que permitió mantener frontend y backend desacoplados y facilitar futuras migraciones a producción.

También dediqué bastante tiempo al diseño responsive y a la experiencia de usuario. Muchas herramientas empresariales tienen interfaces antiguas o demasiado complejas, así que quería crear algo visualmente moderno y fácil de usar.

Resultados obtenidos

El resultado final fue una plataforma full stack funcional desplegada en producción con una arquitectura preparada para escalar y evolucionar.

Entre las funcionalidades implementadas destacan:

Dashboard administrativo
Gestión completa de proveedores
Sistema de autenticación
Integración con IA
Arquitectura modular
Automatización empresarial

Además, el proyecto incluye un entorno demo funcional accesible públicamente, algo que me permitió trabajar también aspectos relacionados con despliegue y DevOps.

Uno de los aprendizajes más importantes fue entender cómo organizar correctamente una arquitectura empresarial moderna. Antes de este proyecto tendía a pensar más en funcionalidades aisladas; aquí empecé a enfocarme realmente en escalabilidad, separación de responsabilidades y mantenibilidad.

También aprendí bastante sobre integración de APIs de IA en aplicaciones reales. Muchas veces desde fuera parece sencillo conectar modelos LLM, pero el verdadero desafío está en integrarlos dentro de flujos útiles para negocio.

Si tuviera que continuar el proyecto, el siguiente paso lógico sería implementar agentes inteligentes y workflows más avanzados, además de integración con ERPs externos y automatización documental.

Repositorio del proyecto:
GitHub: https://github.com/evolve-space/Proyecto-Master-IA-Evolve-JoseMartos.git

Demo:
https://srm-compras-front.vercel.app/

Imágenes:

Dashboard:

Gestión de proveedores:

ProcureFlow AI fue desarrollado como proyecto académico durante el Máster en Inteligencia Artificial de Evolve.

Luxury and nationalities, my first data science project!

Miriam — Fri, 22 May 2026 06:59:53 +0000

Good morning everyone!
I'm happy to announce that yesterday I finished my first project in data science!
I link here the github repository.
This project, based on the dataset "515K Hotel Reviews Data in Europe" from Jiashen Liu, analyzes the level of demand required by luxury tourism depending on the different nationalities, through Sentiment Analysis and Natural Language Processing.

This is my first project, as I mentioned, so I would appreciate any feedback.
I'm very confident that this is the right path for me, and I want to do everything I can to improve and become a competent data analyst.

Here is the repo!

Of course, I want to say thank you to my professor and classmates from Evolve!

Read you soon!

Miriam.

ENS Readiness Assistant — Automatizando evaluaciones de adecuación al ENS con HTML, CSS y JavaScript

Himardlg — Tue, 19 May 2026 08:07:29 +0000

Quizás no sean el mejor programador de los presentes en esta organización, soy un perfil mas técnico, pero seguramente de lo que mas le gustan los retos y desafíos.
Uno de los mayores retos en proyectos GRC es convertir normativa compleja en algo accionable para las organizaciones.
El Esquema Nacional de Seguridad (RD 311/2022) es obligatorio para la Administración Pública española y sus proveedores tecnológicos — pero muchas entidades no saben por dónde empezar, qué categoría les corresponde ni qué controles tienen que implementar.
Por eso construí ENS Readiness Assistant.
¿Qué es?
Una herramienta web que guía a cualquier organización a través de una evaluación de adecuación al ENS en 4 pasos y genera un informe con sus brechas y recomendaciones concretas.
Sin instalación. Sin backend. Sin dependencias.

¿Qué hace exactamente?
Paso 1 — Datos de la organización
Determina el tipo de entidad y sector para saber si el ENS aplica según el Art. 2 del RD 311/2022. No todas las organizaciones están obligadas — la herramienta lo aclara desde el principio.
Paso 2 — Sistemas y servicios
Evalúa el tipo de información gestionada y el impacto potencial de un incidente para determinar la categoría del sistema: Básica, Media o Alta.
Paso 3 — Estado de controles
Checklist de 10 controles clave del Anexo II del ENS con tres estados posibles: implementado, parcialmente implementado o no implementado.
Paso 4 — Informe de resultados
Genera automáticamente:

✅ Si el ENS aplica o no y por qué
🏷️ Categoría del sistema calculada
📊 Porcentaje de cumplimiento actual
🔍 Gap analysis con brechas por prioridad Alta / Media / Baja
💡 Recomendaciones con plazos estimados de implementación
🖨️ Exportación a PDF mediante impresión del navegador

Tecnología utilizada
MVP v1.0 construido con HTML, CSS y JavaScript vanilla — sin frameworks, sin backend, sin dependencias externas. Desplegado en GitHub Pages.
La decisión fue deliberada — quería publicar rápido, aprender haciendo y que cualquiera pudiera clonar el repo y ejecutarlo abriendo un solo archivo HTML.

Lo que aprendí construyéndolo
Transformar normativa en lógica técnica es más complejo de lo que parece.
Cada artículo del RD 311/2022 tiene matices que dependen del tipo de organización, la categoría del sistema y las dimensiones de seguridad afectadas. Por ejemplo, la obligación de usar MFA no es universal — aplica a accesos remotos en sistemas de categoría Media y Alta, no en todos los casos.
Ese proceso de traducción normativa → lógica → código es exactamente el núcleo del trabajo GRC. Y construir esta herramienta me obligó a entenderlo de verdad, no solo a nivel teórico.

Proyecto ENS-Readiness-Assistant

RedRecruit: Cómo construí una plataforma de empleo en ciberseguridad con Python, Flask y Stripe

Pablo Díaz — Mon, 18 May 2026 15:47:44 +0000

RedRecruit: Cómo construí una plataforma de empleo en ciberseguridad con Python, Flask y Stripe

La mayoría de plataformas de empleo actuales son demasiado genéricas para perfiles técnicos especializados en ciberseguridad. Quería crear una aplicación enfocada específicamente en este sector, donde los usuarios pudieran buscar vacantes relevantes, gestionar su cuenta de forma segura y acceder a funcionalidades premium dentro de una experiencia moderna y profesional.

Con ese objetivo nació RedRecruit, una plataforma desarrollada con Flask que combina autenticación segura, integración de pagos con Stripe y consumo de APIs reales de empleo orientadas al sector tecnológico y de ciberseguridad.

Stack tecnológico

Estas son las principales tecnologías utilizadas durante el desarrollo:

Python 3
Flask
Flask-Login
Flask-Bcrypt
Stripe Checkout
SQLite
HTML/CSS
JavaScript
Requests
itsdangerous

Funcionalidades principales

La aplicación incluye múltiples funcionalidades orientadas a una experiencia realista de plataforma SaaS:

Búsqueda de vacantes en ciberseguridad usando APIs reales
Resultados organizados en páginas dedicadas
Registro y login de usuarios
Verificación de email y recuperación de contraseña
Integración premium mediante Stripe Checkout
Panel admin protegido
Navegación profesional mediante breadcrumbs
Gestión de sesiones y perfiles
Integración con APIs Adzuna y JSearch

Lo más técnico: autenticación y Stripe

La parte más interesante del proyecto fue diseñar un sistema de autenticación seguro y combinarlo con una integración funcional de pagos online.

Para la autenticación utilicé Flask-Login junto con Flask-Bcrypt para proteger las contraseñas mediante hashing seguro. Además, implementé verificación de email y recuperación de contraseña utilizando tokens temporales generados con itsdangerous.

Por otro lado, integré Stripe Checkout para permitir la activación de cuentas premium durante 24 horas. Esto implicó gestionar sesiones de pago, validaciones y control de acceso premium desde el backend, simulando una arquitectura muy cercana a aplicaciones SaaS reales.

También trabajé especialmente en la organización modular del backend, separando autenticación, base de datos, servicios de email y clientes API en distintos módulos para mantener una estructura limpia y escalable.

Resultado final

El resultado fue una plataforma web completamente funcional orientada a contratación especializada en ciberseguridad.

🔗 Web desplegada:
RedRecruit Online

🔗 Repositorio GitHub:
Proyecto RedRecruit en GitHub

Características destacadas del resultado final:

Arquitectura modular
Sistema premium funcional
Integración de APIs externas
Seguridad en autenticación
Gestión de usuarios
Diseño profesional y responsive

Lo que aprendí

Este proyecto me permitió combinar desarrollo backend, seguridad web, autenticación, APIs externas y pagos online dentro de una misma aplicación completa.

Además de mejorar mis habilidades con Flask y Python, aprendí cómo estructurar aplicaciones web más cercanas a un entorno profesional y cómo integrar servicios externos de forma segura y mantenible.

También entendí mejor la importancia de la experiencia de usuario y de construir proyectos no solo funcionales, sino también presentables y preparados para producción.

Proyecto académico desarrollado durante el Master en Ciberseguridad de Evolve.

Si quieres ver el código completo o probar la plataforma, puedes visitar tanto el repositorio como la demo online.

ESP32 GARDEN

Darío Rosindo — Mon, 18 May 2026 10:11:43 +0000

Construyendo ESP32 Garden: Un Sistema IoT de Monitorización Agrícola de Extremo a Extremo

La gestión botánica eficaz requiere una monitorización ambiental precisa. Depender de suposiciones para los horarios de riego o las condiciones ambientales a menudo conduce a una salud subóptima de las plantas. Para solucionar esto, desarrollé ESP32 Garden, un sistema IoT de monitorización agrícola de extremo a extremo.

Este proyecto captura datos ambientales en tiempo real utilizando sensores de hardware, los procesa a través de una arquitectura de microservicios personalizada en Python y visualiza los datos históricos en un panel web interactivo . Además, use una carcasa impresa en 3D para proteger los microcontroladores de la exposición a la tierra y la humedad.

A continuación, se detalla la arquitectura del sistema, los componentes de hardware y el stack de software utilizados para dar vida a este proyecto.

La Arquitectura de Hardware

El sistema utiliza un microcontrolador ESP32, seleccionado principalmente por sus capacidades Wi-Fi integradas y su decente potencia de procesamiento. Se interconecta con los siguientes componentes de hardware:

Sensor DHT11: Captura la temperatura ambiente y la humedad relativa.
Sensor Analógico de Humedad del Suelo: Mide el contenido volumétrico de agua en la tierra.
Sensor de Lluvia / Gotas: Detecta eventos de precipitación.
Pantalla OLED (SSD1306): Proporciona depuración y lectura de estado en tiempo real en el propio dispositivo, sin necesidad de acceder al panel web.

Diseñando la Carcasa

Desplegar componentes electrónicos expuestos en un entorno agrícola introduce riesgos significativos de cortocircuitos debido al agua y la suciedad. Para mitigar esto,imprimí en 3D una carcasa personalizada. Diseñada para parecerse a una pequeña casa, esta cubierta aloja de forma segura el ESP32 y el cableado, dejando solo las sondas de los sensores necesarias expuestas al entorno.

El Stack de Software

La infraestructura de software es modular, dividiendo las responsabilidades entre el firmware integrado, una interfaz gráfica de gestión de escritorio, la ingesta de datos en segundo plano y la visualización frontend.

1. El Firmware: C++,Arduino

El ESP32 actúa como un dispositivo de borde (edge device) ejecutando un servidor web ligero. En lugar de renderizar una página HTML pesada en el microcontrolador, expone una API REST a través del endpoint /json. Cuando se le consulta, construye y devuelve las lecturas actuales de los sensores en un payload JSON estructurado.

void handleJSON() {
  String json = "{";
  json += "\"temperatura\":" + String(temperatura) + ",";
  json += "\"humedad_amb\":" + String(humedadAmb) + ",";
  json += "\"suelo\":" + String(porcSuelo) + ",";
  json += "\"lluvia\":" + String(porcLluvia);
  json += "}";
  server.send(200, "application/json", json);
}

2. Servicio de Ingesta de Datos

Para registrar los datos a lo largo del tiempo, un script de Python actúa como un demonio en segundo plano. Envía peticiones HTTP periódicamente a la dirección IP del ESP32, analiza los datos JSON entrantes, añade una marca de tiempo y registra la entrada en un archivo CSV local utilizando pandas.

while True:
    try:
        r = requests.get(URL, timeout=5)
        raw = r.json()

        nueva_fila = {
            'fecha_hora': datetime.now().strftime('%Y-%m-%d %H:%M:%S'),
            'temperatura': raw.get('temperatura', 0),
            'humedad_amb': raw.get('humedad_amb', 0),
            'suelo': raw.get('suelo', 0),
            'lluvia': raw.get('lluvia', 0)
        }

        df = pd.DataFrame([nueva_fila])

        if not os.path.exists(CSV):
            df.to_csv(CSV, index=False, columns=COLUMNAS)
        else:
            df.to_csv(CSV, mode='a', header=False, index=False, columns=COLUMNAS)

    except Exception as e:
        print(f"Error de red: {e}")

    time.sleep(5)

3. Panel de Visualización de Datos

Los datos en bruto requieren interpretación. Utilicé streamlit y plotly para desarrollar una aplicación web que lee el archivo CSV compilado y renderiza gráficos interactivos de series temporales. Esto permite un análisis detallado de tendencias, como monitorizar la tasa exacta de agotamiento de la humedad del suelo.

import streamlit as st
import plotly.express as px

# Renderizar gráficos interactivos con Plotly
col_left, col_right = st.columns(2)

with col_left:
    fig_suelo = px.area(df_filtrado, x='fecha_hora', y='suelo', 
                        title="Humedad del Suelo (%)",
                        color_discrete_sequence=['#7D4F39'])
    st.plotly_chart(fig_suelo, use_container_width=True)
    st.write(f"**Media de humedad (Suelo):** {df_filtrado['suelo'].mean():.1f}%")

with col_right:
    fig_hum_amb = px.area(df_filtrado, x='fecha_hora', y='humedad_amb', 
                          title="Humedad Ambiental (%)",
                          color_discrete_sequence=['#0077B6'])
    st.plotly_chart(fig_hum_amb, use_container_width=True)

4. Gestor de Configuración (main.py)

Para agilizar el despliegue y gestionar los microservicios, el proyecto incluye un panel de control construido con tkinter. Esta GUI permite al usuario monitorizar el estado de red del ESP32 en un hilo en segundo plano y alternar los servicios de captura de datos y del panel web mediante subprocesos (subprocesses).

def monitorear(self):
    while True:
        url = f"http://{self.ip_esp}/json"
        try:
            requests.get(url, timeout=2)
            self.lbl_status.config(text="ONLINE", fg="green")
        except:
            self.lbl_status.config(text="OFFLINE", fg="red")
        time.sleep(5)

El Montaje Final en Acción

Código Abierto y Replicación

Este proyecto acorta la brecha entre los sistemas integrados de bajo nivel y los frameworks de ciencia de datos de alto nivel. Sirve como una base altamente escalable para cualquiera que busque adentrarse en el espacio del IoT.

Todo el proyecto es de código abierto. Puedes revisar la arquitectura completa, acceder al firmware y encontrar instrucciones detalladas de configuración en mi repositorio de GitHub:

ros1ndoo/ESP32Garden en GitHub

Pasos para el Despliegue:

Clona el repositorio e instala las dependencias.
Conecta los sensores DHT11, de humedad del suelo y de lluvia a los pines GPIO designados del ESP32.
Actualiza el archivo settup.txt con las credenciales de tu red local.
Ejecuta main.py, haz clic en "Aplicar" para generar las cabeceras de C++ y flashea el ESP32.
Utiliza la interfaz de Tkinter para inicializar el servicio de captura de datos y lanzar el panel de streamlit.

De Data-Chaos a Data-Driven Decisions: Pipeline ETL Automatizado en Microsoft Fabric y PowerBI

María Monedero — Sun, 17 May 2026 19:31:47 +0000

Dicen que lo más difícil de detectar es aquello que tenemos delante constantemente.

Las grandes organizaciones generan millones de datos cada día, pero disponer de información, no siempre significa comprenderla. Muchos datos permanecen aislados, dispersos o infrautilizados, dificultando la identificación de patrones, riesgos y oportunidades estratégicas.

Porque un dato informa, pero millones, transforman. Bajo esta idea nace ORIONTECH, un proyecto académico basado en un pipeline analítico end-to-end desarrollado con Microsoft Fabric y Power BI, orientado al reporting ejecutivo, control financiero y monitorización operacional.

El proyecto implementa una arquitectura Medallion (Bronze, Silver y Gold) capaz de transformar datos raw en información estratégica mediante procesos automatizados de ingestión, limpieza, modelado y visualización. A través de PySpark Notebooks, Lakehouse y modelos analíticos en Power BI, ORIONTECH permite centralizar KPIs financieros, riesgos operacionales, desviaciones presupuestarias y métricas de productividad dentro de una misma plataforma diseñada con enfoque enterprise.

Actualmente, la solución trabaja sobre un dataset sintético inspirado en estructuras financieras y operacionales reales de mi entorno profesional, ya que la utilización de información corporativa real no es posible por motivos de confidencialidad y protección de datos.

El dataset incluye aproximadamente 30.000 registros con variables relacionadas con ingresos, costes operativos, presupuestos, forecast financiero, productividad, departamentos y regiones internacionales.

Uno de los principales retos fue garantizar la consistencia y calidad del dato, ya que existían categorías duplicadas, nomenclaturas inconsistentes, valores nulos y diferencias de formato entre variables numéricas y textuales. Para resolverlo, fue necesario construir procesos de limpieza y estandarización dentro de la capa Silver antes de modelar la información para su consumo analítico en Power BI.

Sobre este modelo se desarrollaron distintos dashboards orientados a diferentes perspectivas del negocio:

1. Executive Overview

2. Operational Risk

3. Financial Performance

4. Controlling Report

Uno de los aspectos más interesantes del proyecto fue comprobar cómo determinados departamentos concentraban gran parte de los costes ocultos y de la exposición al riesgo operacional, impactando directamente sobre la rentabilidad global de la organización.

Como evolución futura, ORIONTECH podrá incorporar comparaciones en los KPIS vs budget y vs forecast; implementar el análisis predictivo y la monitorización en tiempo real mediante inteligencia artificial.

Este proyecto ha sido diseñado con un enfoque escalable y orientado a su posible implantación en entornos corporativos reales, permitiendo automatizar procesos repetitivos, optimizar el reporting ejecutivo y fomentar una cultura data-driven dentro de las distintas áreas de negocio.

Github Repository: https://github.com/evolve-space/Proyecto-Master-DataScience-Evolve-MariaMonedero.git

Proyecto desarrollado durante el Máster en Data Science & Artificial Intelligence de Evolve: https://evolve.es/

Explorando el éxito musical en Spotify con Python

Maria Angeles Ciobanu — Sun, 17 May 2026 14:37:58 +0000

Explorando el éxito musical en Spotify con Python

En este proyecto realicé un análisis exploratorio de datos utilizando Python, Pandas y técnicas de visualización sobre un dataset de Spotify obtenido desde Kaggle.

El objetivo principal fue analizar diferentes características musicales y estudiar su relación con la popularidad de las canciones dentro de Spotify.

Tecnologías utilizadas

Python
Pandas
NumPy
Matplotlib
Jupyter Notebook

Análisis realizado

Durante el proyecto se realizaron diferentes procesos de análisis exploratorio de datos:

Exploración del dataset
Análisis de valores nulos
Visualización de datos
Análisis de géneros musicales
Correlaciones entre variables
Clasificación de canciones según popularidad

Resultados

El análisis permitió identificar diferentes patrones relacionados con la popularidad musical. Algunas variables como la danceability y la energía mostraron cierta relación con el éxito de las canciones dentro del dataset.

Además, los gráficos y visualizaciones facilitaron la comprensión de las características musicales presentes en Spotify.

Aprendizajes

Este proyecto me permitió reforzar conocimientos relacionados con Python, manipulación de datos, visualización y análisis exploratorio utilizando herramientas fundamentales dentro de Data Science.

GitHub Repository

https://github.com/MariaAngelesCiobanu/Master-DataScience-Evolve-MariaAngelesCiobanu.git

Proyecto académico desarrollado durante el Máster en Data Science de Evolve.

Customer Review Analysis with NLP: Sentiment Analysis and Topic Modeling using Python

ivanmartiolme — Sun, 17 May 2026 13:44:41 +0000

Customer Review Analysis with NLP: Sentiment Analysis and Topic Modeling using Python

Customer reviews contain valuable information about user satisfaction, service quality, and business performance. However, manually analyzing thousands of reviews is inefficient and often impossible at scale.

In this project, I developed a Natural Language Processing (NLP) pipeline to automatically analyze customer reviews and extract actionable business insights from unstructured text data.

The full project repository is available here:
GitHub: https://github.com/ivanmartiolme/Proyecto-Master-DataScience-Evolve-IvanMartinez

Project Objectives

The main goals of this project were:

Clean and preprocess customer review text
Perform sentiment analysis to classify reviews as positive or negative
Identify recurring discussion topics automatically
Analyze sentiment by topic
Generate business insights from textual data

Tools and Technologies

The project was developed using:

Python
Pandas
NumPy
Scikit-learn
Transformers (Hugging Face)
Datasets (Hugging Face)
Matplotlib
Jupyter Notebook

Methodology

1. Data Collection and Preparation

Customer reviews were loaded into a structured DataFrame for analysis. A full text preprocessing pipeline was applied, including:

Lowercasing
URL removal
Punctuation and number removal
Whitespace normalization

This ensured better model performance and cleaner topic extraction.

2. Sentiment Analysis

A pretrained Transformer-based sentiment analysis model was used to classify each review as positive or negative.

This allowed measurement of overall customer satisfaction and helped identify problematic areas.

3. Topic Modeling

To uncover the most frequent themes discussed by customers, TF-IDF vectorization and Non-negative Matrix Factorization (NMF) were applied.

This revealed recurring topics such as:

Airport parking and transportation
Customer service experience
Pricing and additional fees
Refund and cancellation issues

4. Insight Generation

Combining sentiment analysis with topic modeling made it possible to detect which topics generated the most negative feedback and where service improvements could be prioritized.

Key Learnings

This project demonstrated how NLP techniques can transform large volumes of unstructured customer feedback into meaningful business intelligence.

It also reinforced practical skills in:

Text preprocessing
Transformer-based sentiment analysis
Topic modeling
Data storytelling

Conclusion

Customer review analysis using NLP can significantly improve decision-making and customer experience strategies.

This project was developed as part of the Master in Data Science at Evolve.

Proyect web:
https://ivanmartiolme.github.io/Proyecto-Master-DataScience-Evolve-IvanMartinez/

Linkedin:
https://www.linkedin.com/pulse/an%C3%A1lisis-de-rese%C3%B1as-clientes-con-nlp-sentimiento-y-martinez-olmedo-rutae/

Portfolio:
https://ivanmartiolme.github.io/

Cómo construí un sistema RAG para convertirme en Red Teamer con IA — proyecto en Evolve

Alejandro Congil Sainz — Sat, 16 May 2026 20:59:06 +0000

Llevo meses trabajando en algo que empezó como una necesidad práctica
y se ha convertido en la base de mi estrategia para entrar en el mundo
del Red Team: un sistema RAG personal que indexa todo mi conocimiento
de ciberseguridad y lo hace consultable con lenguaje natural.

El problema que quería resolver

Las sesiones del Máster generan una cantidad brutal de material:
clases grabadas, ejercicios, apuntes, herramientas, frameworks...
Todo disperso, todo difícil de recuperar en el momento que lo necesitas.
Cuando estás en medio de un CTF o analizando un vector de ataque,
no puedes permitirte buscar durante 20 minutos en carpetas.

Quería un sistema que funcionara como un analista interno:
"¿Cómo se hace enumeración de subdominios con Amass?"
Y que te devolviera el fragmento exacto de la clase donde se explica,
más el contexto relevante.

El entorno y los datos

La fuente principal son las sesiones del Máster en Ciberseguridad de Evolve:
22 sesiones grabadas en MP4, apuntes en PDF y ejercicios prácticos.

El desafío principal era el vídeo: horas de audio técnico denso que
necesitaban ser transcritas, fragmentadas y vectorizadas sin perder
el contexto de cada concepto.

Estado actual del sistema:

4.146 fragmentos indexados en ChromaDB
22 sesiones de clase procesadas
1.169 herramientas OSINT catalogadas
33 categorías de técnicas de ataque

El proceso

1. Ingesta de vídeo
Cada MP4 pasa por ffmpeg para extraer el audio, luego Whisper
(OpenAI) lo transcribe. El texto resultante se divide en chunks
con solapamiento para no perder contexto entre fragmentos.

2. Embeddings y base vectorial
Los chunks se vectorizan con sentence-transformers y se almacenan
en ChromaDB. Cada fragmento mantiene metadatos: fuente, timestamp,
categoría temática.

3. Motor RAG
La consulta del usuario se vectoriza y se recuperan los K fragmentos
más similares. Claude API (Anthropic) recibe esos fragmentos como
contexto y genera una respuesta fundamentada en el material real del curso.

4. Interfaces
Construí tres interfaces para casos de uso distintos:

Chat web (Streamlit): consultas en lenguaje natural
OSINT Lab: búsqueda semántica sobre 1.169 herramientas catalogadas
Framework Tracker: seguimiento de técnicas por fase del ataque

Resultados

El sistema recupera el fragmento correcto con precisión alta incluso
con consultas vagas o en lenguaje coloquial. La diferencia respecto
a una búsqueda por keywords es notable: el RAG entiende contexto,
no solo palabras.

Lo más valioso: puedo hacer preguntas compuestas tipo
"¿Qué diferencia hay entre la enumeración pasiva y activa según
lo visto en clase, y qué herramientas recomienda el profesor para cada fase?"
y el sistema cruza información de múltiples sesiones en una respuesta coherente.

Lo que aprendí

El chunking es más crítico de lo que parece. Chunks demasiado cortos pierden contexto; demasiado largos diluyen la relevancia.
Whisper comete errores en términos técnicos específicos (nombres de herramientas, flags de comandos). Añadí un paso de post-procesado con diccionario de correcciones.
La elección del modelo de embeddings afecta mucho la calidad de recuperación en dominio técnico especializado.

El siguiente paso es expandir el sistema hacia las fases de explotación
y post-explotación, completando el roadmap Red Team que tengo definido.

Ecosistema del proyecto

Este artículo forma parte de un ecosistema interconectado:

Proyecto desarrollado durante el Máster en Ciberseguridad de Evolve.