DEV Community: Evolve

Diseñando una Base de Datos para una Tienda Online con PostgreSQL y DBeaver

Maria Angeles Ciobanu — Thu, 11 Jun 2026 17:33:29 +0000

Diseñando una Base de Datos para una Tienda Online con PostgreSQL y DBeaver

Como parte de mi formación en Data Science e Inteligencia Artificial, he desarrollado un proyecto de bases de datos utilizando PostgreSQL y DBeaver con el objetivo de poner en práctica conceptos avanzados de SQL aplicados a un entorno real.

El proyecto consiste en el diseño e implementación de una base de datos para la gestión de una tienda online, incluyendo clientes, productos, categorías, pedidos y pagos.

Tecnologías utilizadas

PostgreSQL
DBeaver
Git y GitHub

Funcionalidades implementadas

Durante el desarrollo del proyecto he trabajado con diferentes elementos fundamentales del lenguaje SQL:

Diseño de la base de datos

Creación de tablas relacionales.
Definición de claves primarias y foráneas.
Integridad referencial entre entidades.

Consultas SQL

SELECT básicos.
Filtros mediante WHERE.
Operadores LIKE y BETWEEN.
Consultas anidadas.

JOINs

Implementación de diferentes tipos de JOIN:

INNER JOIN
LEFT JOIN
RIGHT JOIN
FULL OUTER JOIN

permitiendo relacionar información procedente de múltiples tablas.

Indicadores y métricas

Se han desarrollado consultas orientadas al análisis de negocio, como:

Ventas totales.
Ticket medio.
Clientes con mayor volumen de compras.
Productos más vendidos.
Productos con precio superior a la media.

Automatización mediante Triggers

Uno de los aspectos más interesantes del proyecto ha sido la implementación de triggers para automatizar procesos dentro de la base de datos, como la actualización automática del stock tras una venta o el registro de auditorías sobre nuevos pedidos.

Views

También se han creado vistas que permiten simplificar consultas complejas y generar informes reutilizables para análisis posteriores.

Aprendizajes obtenidos

Este proyecto me ha permitido profundizar en el diseño de bases de datos relacionales y comprender mejor cómo las empresas gestionan y explotan la información mediante SQL.

Además de mejorar mis conocimientos técnicos, he podido trabajar con una estructura más cercana a un entorno profesional, aplicando buenas prácticas de organización, documentación y control de versiones mediante GitHub.

Próximos pasos

Como evolución futura del proyecto me gustaría incorporar:

Gestión de inventario.
Cuadros de mando y visualización de datos.
Integración con herramientas de Business Intelligence.
Modelos de análisis y predicción mediante Inteligencia Artificial.

La mejor forma de aprender tecnología sigue siendo construir proyectos reales, equivocarse, mejorar y seguir iterando.

MariaAngelesCiobanu / online-store-sql-project

sql modular

Online Store SQL Project

Overview

This project was developed using PostgreSQL and DBeaver as part of an advanced SQL database exercise.

The objective is to demonstrate the implementation of database concepts including:

Database design
Table creation
Data insertion
SQL queries
Filtering conditions
Joins
Aggregations
Views
Triggers
Functions
Common Table Expressions (CTE)
Subqueries
KPI and business metrics

Technologies Used

PostgreSQL
DBeaver
SQL

Database Structure

The project simulates an online store management system.

Main Tables

Table	Description
customers	Customer information
categories	Product categories
products	Available products
customer_orders	Customer orders
order_details	Products included in each order
payments	Payment records
audit_log	Audit information generated by triggers

Features Implemented

Table Creation

The database includes relational tables with:

Primary Keys
Foreign Keys
Constraints

Data Management

Sample data is inserted to simulate real business operations.

SQL Queries

Different query types are implemented:

Basic SELECT statements
Conditional filtering
Pattern matching
Range filtering

Examples:

SELECT *
FROM products
WHERE

…

View on GitHub

PostgreSQL #SQL #BasesDeDatos #DataScience #InteligenciaArtificial #DBeaver #GitHub #AprendizajeContinuo

Statistical analysis with Python: descriptive statistics, inference, regression, and time series

Adel Aït Zineb — Thu, 04 Jun 2026 06:22:21 +0000

Durante mi formación en el Máster de Data Science, Big Data y desarrollo de Inteligencia Artificial en Evolve, he completado una práctica final de estadística y probabilidad utilizando Python.

El objetivo principal de este proyecto ha sido aplicar diferentes técnicas estadísticas de forma práctica, organizando el trabajo en varios ejercicios independientes y documentando los resultados obtenidos durante el proceso.

Objetivo del proyecto

El objetivo de esta práctica ha sido reforzar conceptos clave de estadística utilizados en Data Science y aplicarlos mediante Python.

El proyecto está dividido en diferentes bloques, cada uno centrado en un área concreta del análisis estadístico:

Estadística descriptiva
Inferencia estadística
Regresión múltiple
Análisis de series temporales

Esta estructura me ha ayudado a entender cómo se pueden aplicar distintas técnicas estadísticas a conjuntos de datos reales y cómo Python permite automatizar, visualizar e interpretar los resultados.

Estructura del repositorio

El repositorio contiene los siguientes archivos y carpetas principales:

data/: carpeta que contiene el dataset utilizado en el proyecto.
output/: carpeta con los resultados generados, gráficos y métricas.
README.md: explicación general del proyecto.
Respuestas.md: respuestas, interpretaciones y conclusiones.
ejercicio1_descriptivo.py: análisis estadístico descriptivo.
ejercicio2_inferencia.py: ejercicios de inferencia estadística.
ejercicio3_regresion_multiple.py: análisis de regresión múltiple.
ejercicio4_series_temporales.py: análisis de series temporales.

Esta organización facilita la revisión del proyecto y permite ejecutar cada parte del análisis por separado.

Herramientas utilizadas

Las principales herramientas y librerías utilizadas en este proyecto han sido:

Python
Pandas
NumPy
Matplotlib
Análisis estadístico
Regresión múltiple
Análisis de series temporales
GitHub

Proceso de desarrollo

La primera parte del proyecto se centra en la estadística descriptiva. En esta sección trabajé con medidas estadísticas básicas y visualizaciones para comprender mejor el dataset.

La segunda parte se centra en la inferencia estadística. Esta parte me ayudó a practicar cómo extraer conclusiones a partir de los datos y entender cómo los métodos estadísticos pueden apoyar la toma de decisiones.

La tercera parte del proyecto está basada en la regresión múltiple. Esta técnica resulta útil para estudiar la relación entre varias variables independientes y una variable objetivo.

Por último, la cuarta parte se centra en el análisis de series temporales, donde el objetivo fue analizar datos que cambian a lo largo del tiempo e identificar posibles patrones o tendencias.

Resultados

El proyecto genera diferentes salidas, incluyendo visualizaciones, métricas, análisis de correlación, resultados de regresión y gráficos de series temporales.

Estos resultados se almacenan en la carpeta output/, lo que facilita revisar tanto el código como los resultados finales de cada ejercicio.

Lo que he aprendido

Este proyecto me ha ayudado a reforzar conceptos importantes de estadística aplicada a Data Science.

También me ha permitido mejorar la forma en la que organizo un proyecto técnico en GitHub, separando el código en diferentes archivos y documentando el proceso de manera clara.

Una de las partes más útiles del proyecto ha sido ver cómo Python permite aplicar conceptos estadísticos de forma práctica y reproducible.

Repositorio del proyecto

Puedes ver el proyecto completo en GitHub aquí:

https://github.com/adeltoutouh-lab/Statistical_Analysis-Adel_Toutouh_El_Bouchti-

Muchas gracias.

Scanner de Seguridad Web Full-Stack con NestJS y React — construido para el Evolve Talent Day

Andrés Caso Iglesias — Mon, 01 Jun 2026 21:12:31 +0000

He creado una herramienta de auditoría de headers de seguridad que analiza 15 parámetros OWASP, TLS, DNS, fingerprinting tecnológico, CVEs, y mapea contra 4 marcos de cumplimiento. Todo con SSRF protection, SSE en tiempo real, y Docker multi-stage. La estoy presentando en el Evolve Talent Day para darme a conocer como nuevo talento en el ecosistema.

¿Por qué este proyecto?

Cuando empiezas en ciberseguridad, uno de los primeros consejos que te dan es: "analiza los headers de seguridad de una web". Hazlo una vez. Dos. Diez. Después te aburres.

Lo que no te dicen es que entender por qué un header está mal configurado, qué frameworks de cumplimiento afecta, y cómo priorizar las recomendaciones es un ejercicio completamente diferente a simplemente ejecutar un curl -I.

Quise construir eso: una herramienta que no solo diga "te falta CSP", sino que te explique el impacto, te mapee contra OWASP Top 10, NIS2, ENS e ISO 27001, y te genere un reporte exportable. Un proyecto de fin de máster que sea realmente útil y que me permita demostrar lo que sé.

Y como estoy participando en el Evolve Talent Day — un evento de Evolve para dar a conocer nuevo talento en el ecosistema tech — quise que este proyecto tuviera la calidad suficiente para presentarlo con orgullo.

¿Qué hace exactamente?

Dale una URL pública y la herramienta:

Hace un request HTTP a esa URL (con protección SSRF, que después explico)
Analiza 15 headers de seguridad contra el OWASP Secure Headers Project
Verifica TLS/SSL — protocolo, certificado, cadena de confianza
Revisa registros DNS — SPF, DKIM, DMARC
Detecta archivos sensibles expuestos — .env, .git/config, wp-config.php, 40 rutas en total
Analiza SRI (Subresource Integrity) en scripts y estilos externos
Hace fingerprinting tecnológico — detecta 23 tecnologías y busca CVEs asociadas
Mapea contra 4 marcos de cumplimiento: OWASP Top 10, NIS2, ENS, ISO 27001
Calcula un score de seguridad (0-100) con calificación A-F
Genera reportes exportables en PDF y JSON

Todo esto con progreso en tiempo real vía Server-Sent Events. No es un spinner que dice "escaneando...". Son 9 etapas con feedback granular.

El Stack (sí, usé todo lo último)

Backend — NestJS 11

Componente	Tecnología
Runtime	Node.js 22
Framework	NestJS 11
HTTP Client	Axios
Validación	class-validator + Zod (env)
Rate Limiting	@nestjs/throttler
Auth	API Key (custom guard)
DB	SQLite via better-sqlite3 (WAL mode)
PDF	PDFKit
TLS	Módulo nativo `tls`
DNS	Módulo nativo `dns/promises`
API Docs	Swagger/OpenAPI

Frontend — React 19

Componente	Tecnología
Framework	React 19.2
Bundler	Vite 8
Styling	Tailwind CSS 4
Charts	Chart.js
State	Custom hooks
Real-time	SSE via EventSource
Testing	Vitest + React Testing Library

DevOps

Componente	Detalle
Containers	Docker multi-stage builds
Compose	2 servicios: backend + frontend
CI/CD	GitHub Actions: jobs paralelos
Proxy	Nginx con SSE buffering deshabilitado

Decisiones Arquitectónicas que me Enorgullecen

1. SSRF Protection en Cada Request Saliente

Esta es la decisión de la que más orgulloso estoy. Un scanner de seguridad no puede ser vulnerable a SSRF. Sería un chiste.

La función resolveAndCheckHostname() se ejecuta antes de cada request HTTP que hace el scanner — ya sea al target, a OSV.dev para CVEs, o a cualquier otro lado:

// Bloquea rangos IPv4 privados
if (isPrivateIPv4(ip)) {
  throw new ForbiddenException(`SSRF blocked: ${hostname} resolves to private IP ${ip}`);
}

// Bloquea loopback IPv6 y link-local
if (ip === '::1' || ip.startsWith('fe80:')) {
  throw new ForbiddenException(`SSRF blocked: ${hostname} resolves to ${ip}`);
}

Resuelve el DNS, verifica todas las IPs retornadas, y solo procede si ninguna es privada. Esto previene que la herramienta sea usada como vector de ataque.

2. Strategy Pattern para Header Checkers

Cada uno de los 15 headers tiene su propio checker class que implementa una interfaz común:

interface HeaderChecker {
  name: string;
  severity: 'critical' | 'high' | 'medium' | 'low';
  weight: number;
  analyze(headers: Record<string, string>): HeaderResult;
}

El AnalyzerService inyecta los 15 checkers vía DI y los itera automáticamente. ¿Quieres agregar un header nuevo? Creas la clase, la agregas al contenedor DI, y listo. Sin tocar el servicio de análisis.

3. Paralelismo con SSE

El scanCore() ejecuta 7 subsistemas en paralelo con Promise.all:

HTTP Client ─────┐
TLS Checker ─────┤
DNS Checker ─────┤
Security Files ──┼──▶ Promise.all ──▶ Analyze ──▶ Comply ──▶ Report
Sensitive Files ─┤
SRI Checker ─────┤
Fingerprinting ──┘

Cada subsistema emite eventos SSE (scanning → complete), y el frontend los consume en tiempo real con EventSource. El usuario ve exactamente en qué etapa está el scan.

4. Detección de Soft 404

Al probar las 40 rutas sensibles, un sitio podría devolver HTTP 200 con una página de error custom. El SensitiveFileCheckerService detecta esto:

Si el status es 200 pero Content-Type es text/html y Content-Length > 500 → suspected soft 404 con confianza baja
Si el status es 200 con Content-Type tipo JSON o texto plano → probablemente real

Esto reduce falsos positivos, que en una herramienta de seguridad son el enemigo.

5. CVE Dual: Local + OSV.dev

Mantengo una base de datos local de 20 CVEs (WordPress, Joomla, Drupal, PHP, Apache, Nginx) con matchers de rango de versiones. En paralelo, consulto la API de OSV.dev (la base de datos de vulnerabilidades de Google) con caché in-memory de 30 minutos.

Si OSV.dev está caído, la herramienta sigue funcionando con la base local. Si está disponible, fusiona los resultados. Resiliencia y profundidad.

6. Zod-First Environment Validation

Las 16 variables de entorno se validan al startup con un schema Zod. Si alguna es inválida, la aplicación se niega a arrancar:

const envSchema = z.object({
  PORT: z.coerce.number().default(3000),
  API_KEY: z.string().optional(),
  CORS_ORIGINS: z.string().default('http://localhost:5173'),
  // ... 13 variables más
});

Fail-fast. No surprises en producción.

El Frontend: No es Solo un CRUD Bonito

El frontend tiene 8 secciones tabulares:

Headers — Grid filtrable de 15 tarjetas con badges de severidad, barras de grade, findings y recomendaciones
Compliance — Grid de 4 columnas (OWASP/NIS2/ENS/ISO27001) con scores porcentuales y dots de estado por control
TLS/SSL — Versión del protocolo, detalles del certificado, grade
DNS — Records SPF/DKIM/DMARC con grades
SRI — Análisis de integridad de recursos externos
Fingerprinting — Tecnologías detectadas con niveles de confianza, lista de CVEs
Sensitive Files — Archivos expuestos con ratings de confianza
Recommendations — Lista priorizada de todos los subsistemas

Detalles que Importan

Error boundaries granulares: Cada sección tiene su propio <ErrorBoundary>. Si ComplianceGrid crashea, el resto sigue funcionando.
Clasificación de errores: El hook useScan clasifica errores en 5 tipos (network, timeout, server, validation, unknown) y muestra diferentes tratamientos UI con mensajes en español.
Score Circle animado: SVG animado con tooltip que explica la metodología: Score = sum(weight × grade) / 165 × 100.
Transparencia sobre limitaciones: El scoring es un heurístico autor-definido, no un estándar. El frontend lo documenta explícitamente.

DevOps: Docker y CI/CD

Docker Multi-Stage

# Builder stage
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Runner stage
FROM node:22-alpine AS runner
RUN addgroup -g 1001 -S appgroup && adduser -S appuser -u 1001 -G appgroup
WORKDIR /app
COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
USER appuser

Non-root user en ambos contenedores. Multi-stage para minimizar el tamaño de imagen.

CI/CD con GitHub Actions

Dos jobs paralelos:

Backend: npm ci → lint → test → build
Frontend: npm ci → lint → test → build

Cada uno corre en Ubuntu con Node 22. Independientes pero simultáneos.

Nginx para el Frontend

location /api/ {
    proxy_pass http://backend:3000;
    proxy_buffering off;  # Soporte SSE
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    chunked_transfer_encoding off;
}

El proxy_buffering off es crítico para que los eventos SSE lleguen al frontend sin buffering intermedio.

Test Coverage

Backend: 33 suites de test (unitarios + e2e)
Frontend: 8 archivos de test con Vitest + React Testing Library
E2E: Un test completo de la API de scan con supertest

No es 100% coverage, pero es testing real — no assertions vacías.

Lo que Aprendí Construyendo Esto

Seguridad no es un feature, es una mentalidad. La protección SSRF tiene que estar en cada capa, no solo en el endpoint principal.
SSE es superior a WebSocket para este caso. No necesitas bidireccionalidad. El servidor emite, el cliente consume. SSE es más simple, más ligero, y funciona con HTTP/1.1.
El Strategy Pattern no es académico, es útil. Los 15 header checkers son intercambiables, testeables, y extensibles. Si mañana necesito agregar un header, no toco código existente.
Docker multi-stage no es opcional, es hygiene. Un builder stage de 900MB y un runner de 150MB. La diferencia es inaceptable si no lo haces.
Zod al startup te salva de problemas en runtime. Fail-fast > fail-later. Siempre.

Evolve Talent Day

Estoy presentando este proyecto en el Evolve Talent Day, un evento organizado por Evolve para dar a conocer a nuevo talento en el ecosistema tech.

La idea es simple: mostrar lo que sé, cómo lo sé, y cómo lo aplico. No es un proyecto perfecto — es un proyecto real con decisiones arquitectónicas documentadas, trade-offs explícitos, y código que funciona.

Si estás en el evento o te interesa el proyecto, puedes:

Probarlo: Repositorio en GitHub
Leer la documentación: docs/ tiene versiones en inglés y español
Docker Compose: docker compose up levanta los dos servicios
API Docs: Swagger en /api/docs

¿Qué Sigue?

Autenticación JWT para escaneos privados
Dashboard multi-usuario con historial compartido
Comparación entre scans (delta analysis)
Integración con pipelines CI/CD (GitHub Action custom)
Más tecnologías en el fingerprinting (actualmente 23)
Base de CVEs expandida

Gracias por leer. Si tienes preguntas sobre la arquitectura, las decisiones técnicas, o quieres discutir sobre ciberseguridad, deja un comentario.

Y si estás en el Evolve Talent Day, acércate a charlar. Siempre hay algo nuevo que aprender.

Built with NestJS 11, React 19, Vite 8, Tailwind CSS 4, TypeScript, Docker, and too much café con leche.

MSF-Assistant: herramienta web de pentesting con Metasploit, nmap y msfvenom en Kali Linux

david ayala — Fri, 29 May 2026 06:33:29 +0000

El problema que quería resolver

Aprender pentesting con Metasploit tiene una curva de entrada alta. Cada sesión de prácticas implica recordar la secuencia exacta de comandos: qué exploit usar, qué parámetros configurar, cómo construir el payload, cómo lanzar el listener. Para alguien que está aprendiendo, esa fricción hace que te centres más en memorizar comandos que en entender lo que ocurre.

Mi proyecto final de máster fue construir una herramienta que eliminara esa fricción: MSF-Assistant, una aplicación web local que orquesta Metasploit desde el navegador, guiando por las distintas fases de un test de penetración.

El entorno: Kali Linux + Metasploitable en VirtualBox

Todo el desarrollo y las pruebas se hicieron en Kali Linux corriendo en VirtualBox, con Metasploitable 3 como máquina objetivo en una red Host-Only aislada. Es el setup estándar para prácticas de pentesting en entornos controlados.

El reto técnico de partida: netdiscover y nmap necesitan permisos de red que desde un navegador normal son imposibles de obtener. La solución fue construir la interfaz como una aplicación Flask que corre localmente en Kali — el backend tiene acceso completo al sistema operativo y ejecuta los comandos reales, mientras el frontend recibe el output en tiempo real mediante Server-Sent Events.

La arquitectura: Flask + SSE + subprocess

El stack es intencionalmente simple:

\app.py -> Backend Python/Flask templates/index.html -> Frontend SPA (HTML/CSS/JS vanilla) \\

La clave técnica está en el streaming de output. Cuando lanzas un escaneo o un exploit, el proceso puede tardar minutos. En lugar de esperar y mostrar todo al final, usé Server-Sent Events para que cada línea aparezca en pantalla en tiempo real, igual que en una terminal:

\`python
@app.route('/api/scan/stream')
def api_scan_stream():
cmd = ['sudo', 'nmap', '-sV', '--open', '-T4', network]

def generate():
    proc = subprocess.Popen(cmd, stdout=subprocess.PIPE,
                            stderr=subprocess.STDOUT, text=True, bufsize=1)
    for line in proc.stdout:
        yield f"data: {line.rstrip()}\n\n"
    yield "data: __DONE__\n\n"

return Response(generate(), mimetype='text/event-stream')

`\

En el frontend, un EventSource recibe cada línea y la pinta en un terminal simulado con colores según el tipo de mensaje.

Las fases del flujo

La herramienta guía por el flujo completo de un pentest.

1. Escaneo de red

Tres opciones reales que se ejecutan en el sistema: netdiscover, nmap ping scan y nmap full scan. El output aparece en tiempo real y al terminar se parsean automáticamente las IPs descubiertas para mostrarlas como objetivos seleccionables.

Aquí se ven los servicios detectados en Metasploitable 3: ProFTPD en el puerto 21, OpenSSH en el 22, Apache en el 80, Samba en el 445, MySQL en el 3306 y Jetty en el 8080.

2. Selección de exploit

Base de datos de exploits organizados por categoría (web, smb, ftp, ssh, irc, db, network) con buscador por nombre, CVE o puerto. Cada uno muestra su rank de Metasploit, CVE asociado y una nota sobre en qué condiciones funciona.

Algunos de los incluidos:

Exploit	CVE	Target típico
SSH Login (credenciales por defecto)	—	Metasploitable 2/3
Drupalgeddon2	CVE-2018-7600	Metasploitable 3, Drupal 7/8
EternalBlue	CVE-2017-0144	Windows 7 / 2008 R2
Shellshock CGI	CVE-2014-6271	Apache con CGI

3. Configuración automática

Al seleccionar un host del escaneo y un exploit, la herramienta pre-rellena automáticamente RHOSTS con la IP del target y LHOST con la IP local de Kali. Solo hay que revisar y ajustar si hace falta.

Para los módulos de login (SSH, MySQL) incluí un diccionario de credenciales por defecto de las máquinas vulnerables más comunes: vagrant/vagrant para Metasploitable 3, msfadmin/msfadmin para Metasploitable 2, root sin contraseña para MySQL. La herramienta las prueba automáticamente y abre una sesión al primer acierto.

4. Lanzar en Metasploit

Genera un script .rc con todos los comandos configurados y ejecuta msfconsole -r. El output completo aparece en tiempo real en el terminal de la interfaz.

5. Generador de payloads (msfvenom)

Diez tipos de payload: ELF Linux x86/x64, EXE Windows x86/x64, PHP webshell, Python, Bash one-liner, WAR para Tomcat, ASPX para IIS, PowerShell. Con soporte para encoders y descarga directa del payload generado.

6. Post-explotación

Una vez dentro, panel con módulos post/ preconfigurados, comandos Meterpreter listos para copiar y técnicas de escalada de privilegios en Linux.

Resultado: acceso conseguido contra Metasploitable 3

El flujo completo que seguí en la prueba final:

Escaneo con nmap full scan y aparece 192.168.56.101 con sus puertos
Selecciono el host, voy a Exploits y elijo SSH Login (credenciales por defecto)
RHOSTS ya está relleno automáticamente, el diccionario se genera solo
Pulso "Ejecutar en Metasploit"
En segundos: Success: 'vagrant:vagrant' y SSH session 1 opened

Acceso conseguido con privilegios sudo (groups=27(sudo)), todo automatizado desde la interfaz, sin escribir un solo comando manualmente.

Lo que aprendí

Técnicamente: la parte más interesante fue el streaming via SSE. Los procesos de Metasploit y nmap bufferizan su output, así que tuve que configurar bufsize=1 y text=True en subprocess.Popen para obtener salida línea a línea en tiempo real. También aprendí a generar scripts .rc de forma genérica para soportar cualquier exploit sin programar cada opción a mano.

De seguridad: construir la herramienta me obligó a entender en profundidad qué hace cada exploit, qué condiciones necesita y por qué funciona. Saber por qué Drupalgeddon2 no necesita credenciales, o por qué hay que apuntar al TARGETURI correcto, es mucho más valioso que ejecutar comandos de memoria.

Lo que haría diferente: añadiría autenticación a la interfaz web, un sistema de logs persistente para guardar los resultados de cada sesión, e integraría db_nmap para aprovechar la base de datos interna de Metasploit.

Herramientas utilizadas

Stack técnico:

Python 3 + Flask — backend y servidor web local
HTML / CSS / JS vanilla — frontend sin frameworks
Metasploit Framework — motor de exploits (msfconsole, msfvenom)
nmap — escaneo de puertos y detección de servicios
netdiscover — descubrimiento de hosts via ARP
Kali Linux + VirtualBox — entorno de desarrollo y pruebas
Metasploitable 3 — máquina objetivo para las pruebas

Desarrollo asistido por IA:

Claude AI (Anthropic) — co-desarrollado con Claude como asistente de programación. Claude ayudó a estructurar la arquitectura, implementar el streaming via Server-Sent Events, depurar el backend Flask y diseñar la interfaz. Trabajar con IA no reemplaza entender lo que se construye: cada decisión técnica fue revisada, probada y ajustada manualmente en Kali.

Repositorio

El código completo está en GitHub:

github.com/Davidaah07/Proyecto-Master-Ciberseguridad-Evolve-DavidAah07

Incluye instrucciones de instalación, lista completa de exploits, diccionario de credenciales y aviso legal.

Proyecto académico desarrollado durante el Master en Ciberseguridad de 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.

Procure Flow: Un SRM de gestión de proveedores.

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

Qué es ProcureFlow y qué valor aporta.

La idea de ProcureFlow se me ocurrió a raíz de una conversación que tuve con mi pareja acerca de su trabajo. Ella trabaja de Product Manager en una empresa de aceites esenciales y hace un tiempo me comentó que tipo de herramientas utilizaba y el caos que tenía en su día a día.

Tras escuchar lo que me contó se me ocurrió que tenía que haber una forma de poder integrar todas las herramientas y así poder tener un sistema que recoja todas las herramientas, lo cual abarataría costes de mantenimiento y de tiempo.

Y entonces mi razonamiento fue: Todas las empresas tienen un CRM, que es una aplicación web que sirve para gestionar los clientes, por qué no hago lo mismo pero para los proveedores.

Y así es como nace ProcureFlow AI, un SRM (Supplier Relationship Management), enfocada en digitalizar procesos relacionados con compras, proveedores y automatización operativa.

Arquitectura del proyecto

Pensé que lo más idóneo es desarrollar una aplicación web, la cual tendría integrada todos los procesos y todas las herramientas necesarias para la gestión de proveedores de la empresa. La idea es que la aplicación se adapte a cualquier tipo de empresa y mercado, por lo que la aplicación está totalmente modularizada y puede ser fácilmente adaptada de acuerdo a las necesidades requeridas.

La aplicación fue desarrollada usando:

React, HTML5 y CSS para el frontend
Symfony y PHP para el backend
MySQL como base de datos
OpenAI API para integración de IA

El proceso de desarrollo

Para este proyecto decidí que lo más óptimo es separar el backend del frontend para trabajar de manera más cómoda y eficiente.

Lo primero que desarrollé fue el backend de la aplicación. En esta parte implementé toda la lógica encargada de gestionar los proveedores y su información, creando los distintos endpoints y consultas necesarios para realizar operaciones como crear, consultar, modificar y eliminar registros en la base de datos.

Una vez finalizado el backend, desarrollé el frontend de la aplicación. Esta parte es la encargada de mostrar la información al usuario de forma visual e intuitiva, además de realizar las peticiones necesarias al backend para consultar, crear, modificar o eliminar los datos de los proveedores.

Finalmente, incorporé un sistema multiagente con el objetivo de ayudar al usuario en determinadas tareas y reducir el tiempo dedicado a procesos repetitivos. La idea era que la aplicación no se limitara únicamente a almacenar información, sino que también pudiera ofrecer asistencia dentro de la propia plataforma.

Resultados obtenidos

El resultado final fue una aplicación web dedicada a la gestión de proveedores de una empresa, aplicación totalmente modularizada y escalable a cualquier tipo de empresa y de mercado.

Funcionales principales:
Dashboard administrativo
Gestión completa de proveedores
Sistema de usuarios
Gestión de correos
Integración con IA

Uno de los aprendizajes más importantes que me ha aportado este proyecto ha sido entender cómo se comunican el frontend y el backend a través de APIs. Durante el desarrollo aprendí a gestionar las distintas peticiones entre ambas partes de la aplicación, procesar la información recibida y mostrar los resultados correctamente al usuario.

A continuación dejo los enlaces de acceso a la aplicación:

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:

Gestión de correos:

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.