DEV Community: Christian Gonzales Komiya

(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`