DEV Community: Christian Gonzales Komiya

(Spanish) El navegador ya no es solo para humanos

Christian Gonzales Komiya — Thu, 25 Jun 2026 23:36:21 +0000

Por qué las páginas web públicas son ahora accesibles de formas que antes eran impensables

Hubo un tiempo en que "ver algo en una web" y "usar ese dato en código" eran dos mundos separados. El primero era para humanos. El segundo requería que la empresa dueña del sitio te diera una API, documentación, credenciales, y su bendición.

Ese tiempo terminó.

Lo que descubrí explorando

Estaba analizando cómo obtener datos de una página web pública — sin registro, sin login, sin nada que el usuario promedio no pudiera ver con sus propios ojos. Información completamente pública.

El camino obvio parecía ser el scraping tradicional: descargar el HTML, parsear el contenido. Pero la web moderna no funciona así. La mayoría de sitios hoy son Single Page Applications — React, Angular, Vue — donde el HTML inicial está vacío y el contenido llega después, cargado dinámicamente por JavaScript.

<div id="root"></div>

Eso es todo lo que ves si intentas descargar el HTML directamente. Un div vacío esperando que JavaScript haga su trabajo.

La API interna que nadie documenta

Abrí las herramientas de desarrollo del browser, filtré por Fetch/XHR, y observé el tráfico. Lo que vi fue revelador: la app de React estaba consumiendo una API interna con endpoints bien estructurados, respuestas en JSON limpio, y toda la información organizada perfectamente.

Datos que visualmente aparecen en pantalla para cualquier usuario, pero que internamente viajan como JSON estructurado, listo para ser procesado.

El problema: esa API tenía protección. Un WAF (Web Application Firewall) en Azure que analizaba cada request y bloqueaba cualquier cosa que no pareciera un browser legítimo. Tokens de sesión con expiración. Cookies generadas dinámicamente. Un ecosistema de seguridad diseñado para que solo browsers reales pudieran consumir esos datos.

Y tenía razón en bloquearte — si intentabas replicar el request manualmente, para cuando copiabas todos los headers necesarios, los tokens ya habían vencido.

El agente como humano digital

Aquí entra el cambio de paradigma.

Un agente con control de browser — usando herramientas como Playwright — no simula un request. Abre un browser real. Chromium de verdad. Navega como lo haría un usuario. Las cookies se generan naturalmente. Los tokens están vigentes. El WAF ve exactamente lo que espera ver.

Pero a diferencia del humano, el agente puede hacer algo que el humano no puede: obtener y usar los datos en el mismo instante, dentro del mismo contexto de sesión.

El flujo es así:

Agente abre browser
    → navega al sitio (tokens se generan automáticamente)
    → intercepta la respuesta de la API en tiempo real
    → extrae los datos estructurados
    → los guarda en base de datos
    → cierra el browser

Todo en segundos. Sin que ningún token tenga tiempo de vencer. Sin que ningún WAF detecte anomalías. Porque técnicamente no hay ninguna.

El problema del humano vs. el agente

Cuando un humano intenta hacer esto manualmente:

Abre DevTools
Filtra el tráfico de red
Encuentra el request correcto
Copia los headers
Los pega en un cliente HTTP
Ejecuta el request

Resultado: Token vencido. Request bloqueado.

El tiempo que tarda el humano en completar esos pasos es mayor que el tiempo de vida de los tokens de sesión. Es una carrera que el humano pierde por diseño.

Cuando el agente hace lo mismo, no hay pasos separados. La obtención y el uso son una sola operación continua. El agente no anota el token para usarlo después — lo usa mientras aún está caliente, en el mismo contexto donde nació.

¿Es esto vulnerar algo?

No. Y esa es la parte más interesante del análisis.

Cualquier información que una página muestra públicamente, sin requerir autenticación, es información que el usuario tiene derecho a ver. El agente no hace nada que el usuario no pudiera hacer manualmente — simplemente lo hace más rápido y de forma programática.

La línea ética está clara:

Información pública, uso personal o académico → completamente legítimo
Automatización masiva que sature servidores → problemático
Uso comercial de datos ajenos → requiere revisar términos
Acceso a cuentas de terceros → ilegal

8 requests al día para leer información pública genera menos tráfico que un usuario humano visitando el sitio dos veces. No hay daño, no hay saturación, no hay violación.

Lo que esto significa para el desarrollo

Estamos en un momento donde la barrera entre "ver datos" y "usar datos en código" prácticamente desapareció para información pública.

Antes necesitabas:

Una API oficial con documentación
Credenciales y proceso de registro
Límites de uso negociados
Meses de espera para aprobación

Ahora necesitas:

Un agente con Playwright
Decirle qué quieres obtener
Esperar segundos

Las implicancias para el desarrollo de software son enormes. Cualquier fuente de datos pública se convierte potencialmente en una fuente estructurada para tus aplicaciones. Sin fricción. Sin burocracia. Sin depender de que la empresa decida publicar una API.

La arquitectura que emerge

Lo interesante no es solo obtener los datos una vez — es cómo esto se integra en una arquitectura completa:

Agente recopilador (cron programado)
    → navega fuentes públicas
    → extrae datos estructurados
    → guarda en base de datos local

MCP Server
    → lee la base de datos
    → expone herramientas al agente de consulta

Usuario
    → pregunta en lenguaje natural
    → el agente consulta las herramientas
    → respuesta instantánea desde datos frescos

El agente recopilador y el agente de consulta son independientes. Uno escribe, el otro lee. La base de datos es el punto de encuentro. Y el usuario final nunca sabe — ni necesita saber — de dónde vienen los datos.

Conclusión

Las páginas web públicas siempre fueron accesibles para humanos. Lo nuevo es que ahora son igualmente accesibles para agentes — y en algunos aspectos, el agente las maneja mejor que el humano.

No porque rompa barreras de seguridad. Sino porque opera dentro de los mismos canales legítimos que usa cualquier browser, pero sin las limitaciones de tiempo y coordinación que tiene un humano copiando y pegando headers.

El browser ya no es solo para humanos. Y eso cambia bastante cómo pensamos el acceso a datos en el desarrollo moderno.

Este post es parte de una exploración práctica sobre agentes de IA. Las conclusiones son aplicables a cualquier fuente de información pública en la web.

(Spanish) [App] Visualización de Denuncias en el mapa del Perú - Uso de Streamlit + Pandas + Folium

Christian Gonzales Komiya — Tue, 09 Jun 2026 15:30:56 +0000

En los últimos meses, la inseguridad ciudadana en el Perú ha ido en aumento.
Quise explorar una manera simple y accesible de visualizar esta problemática usando datos abiertos y herramientas de análisis de datos.
Este es un pequeño proyecto motivado por un dataset de denuncias policiales publicado por la Policía Nacional del Perú en la plataforma oficial de datos abiertos del Estado Peruano.

Dataset utilizado: Denuncias Policiales - Enero 2018 a Junio 2025
(También lo puedes encontrar buscando "Denuncia" en datosabiertos.gob.pe)

El dataset incluye (al corte de agosto 2025) modalidades como:

Estafa
Extorsión
Homicidio
Hurto
Robo
Violencia contra la mujer
Otros

Link de la app -> https://denuncias-pnp.streamlit.app/

🎯 Motivación
La idea nació como una forma de:

Analizar cómo han evolucionado las denuncias en el tiempo.
Ubicarlas en un mapa para identificar zonas con mayor incidencia.
Darle un formato visual e interactivo, aprovechando herramientas de código abierto.

🛠 Herramientas utilizadas

Streamlit → Framework en Python que permite crear aplicaciones web interactivas para análisis de datos de forma rápida y sencilla.
Pandas → Librería para manipulación y análisis de datos en Python. Ideal para trabajar con tablas, filtrar y agrupar datos.
Folium → Librería para generar mapas interactivos en Python usando Leaflet.js.

🌍 Visualización en mapa
La parte más llamativa del proyecto es la representación geográfica de las denuncias.
A partir de los datos filtrados por año y tipo de modalidad, se agrupan las denuncias por distrito y se dibujan círculos proporcionales a la cantidad de casos.

# --- Mapa por distrito ---
df_map_filt = df[df["ANIO"] == year]
if modalidad != "Todas":
    df_map_filt = df_map_filt[df_map_filt["P_MODALIDADES"] == modalidad]

df_map = (
    df_map_filt.groupby("UBIGEO_HECHO", as_index=False)["cantidad"].sum()
    .merge(
        df_ubigeo[["inei", "distrito", "latitude", "longitude"]],
        left_on="UBIGEO_HECHO", right_on="inei", how="left"
    )
    .dropna(subset=["latitude", "longitude"])
)

st.subheader("🌍 Mapa por distrito")
m = folium.Map(location=[-9.19, -75.02], zoom_start=5)
max_c = df_map["cantidad"].max()
for _, r in df_map.iterrows():
    radius = 3 + (r["cantidad"] / max_c) * 15 if max_c > 0 else 3
    folium.CircleMarker(
        location=[r["latitude"], r["longitude"]],
        radius=radius,
        color="crimson",
        fill=True,
        fill_opacity=0.6,
        popup=f"{r['distrito']}: {r['cantidad']}"
    ).add_to(m)
st_folium(m, width=800, height=600)

Qué hace este código:

Filtra las denuncias por año y modalidad.
Agrupa por distrito (usando el código UBIGEO) y suma la cantidad de casos.
Une la información con coordenadas geográficas para cada distrito.
Crea un mapa con círculos rojos cuyo tamaño es proporcional a la cantidad de denuncias.
Muestra un popup con el nombre del distrito y el número de denuncias.

📈 Gráfico de tendencia por tipo de denuncia
Además del mapa, la aplicación muestra un gráfico de tendencia donde se observa la evolución de cada tipo de denuncia a lo largo de los años, desglosado por departamento.
Esto permite identificar patrones, por ejemplo, si ciertos delitos han ido aumentando o disminuyendo con el tiempo.

📦 Código fuente
El código completo y los datos procesados están disponibles en mi repositorio de GitHub:
🔗 https://github.com/ckomiya/data_science_denuncias_pnp

(Spanish) Arquitectura Hexagonal (Ports & Adapters) - Beneficios y Ejemplo en Java

Christian Gonzales Komiya — Tue, 09 Jun 2026 15:22:23 +0000

Mientras leía el libro Hexagonal Architecture Explained de Alistair Cockburn y Juan Manuel Garrido, me encontré con una sección que destaca beneficios clave de este patrón.

En este artículo represento en código Java los tres pasos esenciales para implementar la arquitectura y lograr dichos beneficios.

Beneficios destacados

El sistema queda abierto a tener pruebas de regresión para todas sus funciones, de extremo a extremo.
Es posible variar las tecnologías externas conforme evolucionan (como siempre lo hacen) sin un esfuerzo enorme.
Estos dos beneficios adicionales superan fácilmente el pequeño costo extra de implementar la solución.

Paso 1 – API del sistema (interfaz proporcionada)

Creamos la aplicación para que sus servicios estén disponibles como llamadas a funciones, sin depender directamente de UI o base de datos.

// Paso 1: API del sistema (interfaz proporcionada)
public class TaxCalculatorApp {

    // Servicio principal expuesto como API
    public double calculateTax(double amount, double rate) {
        return amount * rate;
    }
}

Aquí la aplicación no sabe nada de dónde viene el rate ni de si hay base de datos: es solo lógica pura.

Paso 2 – Variables para las conexiones externas (interfaces requeridas)

Agregamos variables para cada conexión externa (por ejemplo, un servicio que da la tasa de impuestos).

// Interfaz requerida: servicio externo para obtener tasa de impuestos
public interface TaxRateProvider {
    double getTaxRate();
}

// Paso 2: la aplicación ahora tiene una variable para su conexión externa
public class TaxCalculatorApp {

    // Variable para el proveedor de tasas (actor secundario)
    private TaxRateProvider taxRateProvider;

    // Inyectamos la dependencia (aún puede ser null si no se configura)
    public void setTaxRateProvider(TaxRateProvider provider) {
        this.taxRateProvider = provider;
    }

    // Servicio principal usa la interfaz requerida
    public double calculateTax(double amount) {
        double rate = taxRateProvider.getTaxRate();
        return amount * rate;
    }
}

Ahora la aplicación no llama directamente a un servicio concreto: usa una interfaz requerida (TaxRateProvider).

Paso 3 – Configuración con actores reales o adaptadores (inyección de dependencias)

En la construcción/configuración, conectamos la app con un adaptador concreto, o con un doble de pruebas.

// Adaptador concreto que obtiene tasa desde una BD (ejemplo simple)
public class DatabaseTaxRateAdapter implements TaxRateProvider {
    @Override
    public double getTaxRate() {
        // Aquí iría la lógica real de conexión a base de datos
        return 0.21; // Ejemplo: IVA 21%
    }
}

// Adaptador doble de pruebas
public class FixedTaxRateStub implements TaxRateProvider {
    private final double fixedRate;
    public FixedTaxRateStub(double fixedRate) {
        this.fixedRate = fixedRate;
    }
    @Override
    public double getTaxRate() {
        return fixedRate;
    }
}

// Paso 3: Configuración y uso
public class Main {
    public static void main(String[] args) {
        TaxCalculatorApp app = new TaxCalculatorApp();

        // Configuración para producción
        TaxRateProvider dbAdapter = new DatabaseTaxRateAdapter();
        app.setTaxRateProvider(dbAdapter);
        System.out.println("Impuesto: " + app.calculateTax(100));

        // Configuración para pruebas
        TaxRateProvider testStub = new FixedTaxRateStub(0.10);
        app.setTaxRateProvider(testStub);
        System.out.println("Impuesto (prueba): " + app.calculateTax(100));
    }
}

✅ Qué logramos siguiendo los pasos

La app expone su lógica a través de una API clara (calculateTax), sin UI ni BD acoplada.
Creamos variables para las dependencias externas (TaxRateProvider).
Conectamos esas dependencias en tiempo de configuración, ya sea con adaptadores reales o dobles de prueba.

(Spanish) Cómo iniciar un proyecto con Claude Code

Christian Gonzales Komiya — Tue, 09 Jun 2026 15:01:25 +0000

Guía rápida para desarrolladores que quieren arrancar un proyecto de forma ordenada y sacarle el máximo provecho a Claude Code.

Este artículo no pretende ser una guía exhaustiva — es mi guía de bolsillo personal. La escribí para consultarla cada vez que inicio un proyecto nuevo y no querer recordar de memoria qué pasos seguir. Si te sirve a ti también, genial.

Fuente: Claude Code Advanced de Javier Rayon.

Paso 1 — Pre-Setup: prepara el terreno

Antes de escribir una sola línea de código, pídele a Claude que configure la estructura del proyecto.

Prompt:

Estoy comenzando un proyecto de [descripción]. Antes de programar, ayúdame a crear:
- Estructura de directorios
- CLAUDE.md con convenciones
- Scripts de desarrollo (dev, test, build)
- Configuración de linting y formateo

Claude generará algo así:

my-project/
- src/
    - routes/
    - services/
    - models/
    - utils/
- tests/
- scripts/
- .claude/
    - settings.json
    - CLAUDE.md
    - rules/
        - testing.md
        - api-patterns.md
        - security.md
    - skills/
        - deploy/skill.md
        - db-migrate/skill.md
    - agents/
        - reviewer.md
        - qa.md
    - commands/
        - COMMANDS.md

Cada carpeta tiene un propósito claro:

rules/ — lo que Claude siempre debe respetar (frameworks, patrones, seguridad)
skills/ — procedimientos reutilizables (deploy, migraciones)
agents/ — roles especializados (revisor de código, QA)
commands/ — comandos slash personalizados (/deploy, /migrate)

Ejemplo de regla (.claude/rules/testing.md):

# Reglas de Testing
- Framework: vitest (NUNCA jest)
- Convención de nombres: *.test.ts
- Toda función pública debe tener al menos una prueba

Ejemplo de skill (.claude/skills/deploy/skill.md):

# Desplegar a Producción
1. Ejecutar pruebas: `npm test`
2. Compilar: `npm run build`
3. Verificar que no haya cambios sin commit
4. Ejecutar: `./scripts/deploy.sh production`

Agrega .claude/worktrees/ a tu .gitignore desde el inicio.

Paso 2 — Plan: define qué vas a construir

Con el proyecto configurado, entra en modo planificación antes de tocar código.

/plan

Claude analizará el problema y presentará un plan detallado sin modificar nada todavía. Tú revisas, ajustas y le das luz verde.

Prompt vago (evitar):

Build a login system

Prompt específico (usar):

Plan an OAuth2 login implementation (Google and GitHub).
Requirements:
- JWT with refresh tokens
- 24h expiration
- Rate limiting of 5 attempts per minute
- E2E tests with Playwright

Técnica avanzada — revisión cruzada:

Usa dos sesiones de Claude en paralelo:

Sesión A genera el plan completo.
Sesión B lo revisa con este prompt:

Revisa este plan como si fueras un Staff Engineer.
Busca puntos débiles, casos límite no considerados
y dependencias faltantes.

Ajusta el plan con el feedback de la Sesión B antes de ejecutar.

Paso 3 — Worktrees: ejecuta en paralelo

Con el plan listo, identifica 3 a 5 tareas que puedan avanzar simultáneamente y crea un worktree para cada una.

Opción A — Worktrees manuales (control total):

git worktree add -b feature/auth ../wt-auth main
git worktree add -b feature/api ../wt-api main
git worktree add -b test/e2e ../wt-tests main

Luego lanza Claude en cada uno:

# Terminal 1
cd ../wt-auth && claude

# Terminal 2
cd ../wt-api && claude

# Terminal 3
cd ../wt-tests && claude

Opción B — Worktrees nativos de Claude (más rápido):

claude --worktree auth-feature

Claude crea la rama, el directorio y la sesión en un solo paso. Al terminar, limpia automáticamente si no hubo cambios.

Flujo de cierre:

# Cada worktree hace commit y crea su PR
git add . && git commit -m "feat: auth OAuth2"
gh pr create --title "Auth OAuth2" --body "Descripción"

# Al terminar todos, limpia
git worktree remove ../wt-auth
git worktree prune

Tip: Si en lugar de tareas puntuales necesitas cambios masivos en todo el proyecto (por ejemplo, migrar 50 archivos), usa /batch en lugar de worktrees manuales — Claude los gestiona automáticamente.

Resumen

Paso	Qué haces	Herramienta
Pre-Setup	Configuras estructura, reglas, skills y agentes	Prompt inicial
Plan	Defines qué construir y lo validas	`/plan`
Worktrees	Ejecutas tareas en paralelo	`git worktree` / `claude --worktree`