$ ls /caprini.dev/blog

Sin un jefe de producto ni un roadmap impuesto, decidir qué tocar a continuación en un proyecto personal es más difícil de lo que parece. Así lo resuelvo.

Pescar y programar tienen más en común de lo que parece: paciencia, prueba y error, y aceptar que no todo depende de haberlo hecho bien.

Contar avances de un proyecto en público es útil si se cuentan también los límites. Sin eso, construir en público se convierte en marketing disfrazado.

Grabar una ruta GPS en Android en primer plano no es un capricho técnico: es la respuesta a un problema real de batería, permisos y fiabilidad.

Proteger un punto de pesca en un mapa público no es solo esconderlo: es decidir qué nivel de detalle tiene sentido compartir y con quién.

He probado bastantes apps de pesca y casi todas cojean en lo mismo: utilidad real, privacidad, comunidad, puntos, rutas o moderación. Repaso cada carencia.

Sentarme a planificar antes de escribir código parece frenar el ritmo, pero casi siempre ahorra más tiempo del que consume. Cuento cómo lo hago.

Un buen prompt para Cursor no es una frase ingeniosa, es contexto concreto: qué archivo, qué límite y qué resultado se considera válido.

Automatizar una tarea repetitiva ahorra tiempo, pero también puede ejecutar un error cien veces antes de que nadie lo note. Así lo tengo en cuenta.

Una regla de no regresión no es solo «no rompas nada»: es un compromiso concreto sobre qué comportamientos no pueden empeorar sin que alguien lo note.

Documentar lo que un proyecto todavía no hace bien es tan útil como documentar lo que ya funciona. Así organizo esa lista y por qué la mantengo viva.

Antes de tocar coordenadas, cuentas o cualquier dato sensible reviso una lista concreta de pruebas. Aquí explico cuáles y por qué no me las salto.

Guardar la coordenada exacta y mostrar otra cosa distinta al público: así abordo el problema técnico de proteger puntos de pesca sensibles.

En una app de pesca con mapa, cada coordenada es información sensible. La privacidad no es un añadido: condiciona el diseño desde el primer día.

Construir FishMind, un quiz pequeño para Android, me ha enseñado más sobre bancos de preguntas y estados de interfaz que sobre pesca.

El contenido de relleno no siempre se nota a simple vista. Cómo detecto, en mis propios borradores, cuándo un párrafo no aporta nada real.

Un buen título técnico no es el más ingenioso, sino el que coincide con la pregunta exacta que alguien escribiría en un buscador real.

Los enlaces internos no son un requisito de SEO que se añade al final; son la forma en que decido qué artículos se apoyan entre sí.

Un sitemap mal generado puede dejar invisibles artículos que ya has publicado, algo que descubrí revisando mi propio blog en detalle.

Lo esencial de SEO técnico que reviso en un blog personal pequeño, sin herramientas complicadas ni promesas de resultados que no puedo controlar.

Por qué elegí Ghost como backend headless y Next.js como frontend para caprini.dev, y los problemas concretos que esa combinación me ha dado.

La lista de comprobaciones que aplico antes de dejar pública una herramienta web pequeña: rendimiento, privacidad, errores y casos límite.

No es la cantidad de funciones lo que hace útil una herramienta web pequeña, sino lo bien que resuelve el único problema que promete resolver.

Las decisiones detrás de una herramienta pequeña y gratuita: qué formatos soporta, qué no hace a propósito y por qué la sigo manteniendo.

Un balance honesto de lo que va bien y lo que no en Chocheando, mi foro propio en construcción, incluida la parte incómoda de la automatización.

Las decisiones técnicas y de estructura que tomé al montar Chocheando, un foro propio todavía en construcción, antes de pensar en tener actividad.

La diferencia entre compartir el progreso real de un proyecto y saturar un foro con publicaciones que nadie pidió leer, aunque parezcan lo mismo.

Cómo estoy planteando los recursos gráficos de la ficha de Google Play para Caladero sin maquillar una app que todavía está en desarrollo.

La lista de comprobaciones que hago antes de enviar una versión a revisión: no evita todos los rechazos, pero elimina los más tontos.

La lista que reviso antes de generar una build release de Android para no descubrir un fallo de firma o de ofuscación cuando ya es tarde.

Diseñar la eliminación de cuenta desde el principio evita rediseñar medio backend más tarde. Explico por qué la planteo pronto y qué implica hacerla bien.

Rellenar la sección Data Safety a última hora obliga a reconstruir de memoria qué datos toca la app. Explico por qué la llevo actualizada desde el primer commit.

Una política de privacidad copiada de una plantilla no sirve de nada si no refleja lo que la app hace de verdad. Explico qué debe cubrir y cómo la redacto.

PostGIS convierte PostgreSQL en una base de datos capaz de responder preguntas espaciales de verdad. Explico para qué lo uso y cuándo no hace falta todavía.

Elegir entre MapLibre y Google Maps en Android no es solo una cuestión de coste. Explico los criterios técnicos y de producto que uso para decidir en cada caso.

Meter un mapa en una app es fácil. Lo difícil es diseñar qué información se guarda, cómo se organiza y qué necesita el usuario más allá de ver puntos en pantalla.

Android permite pedir ubicación aproximada o precisa por separado desde hace varias versiones. Explico cómo decido cuál pedir según cada funcionalidad real.

El selector de fotos del sistema permite elegir una imagen sin que la app pida permiso sobre toda la galería. Explico cómo lo integré y qué límites tiene.

Pedir todos los permisos al abrir la app por primera vez es la forma más rápida de que el usuario desconfíe. Explico cómo decido qué pedir y cuándo pedirlo.

Local-first significa que la app funciona sin conexión por diseño, no como excepción. Explico el concepto, cómo lo aplico y qué complejidad añade de verdad.

El emulador no siempre reproduce los mismos bugs que un móvil real. Explico cómo conecto y depuro con ADB en dispositivo físico, con comandos y errores típicos.

Elegí Jetpack Compose para mis proyectos nuevos, pero no es una decisión sin matices. Explico los criterios que uso y cuándo todavía tendría sentido usar XML.

Con módulos, capas y convenciones claras es mucho más fácil retomar un proyecto Android tras varias semanas sin tocarlo. Cuento la estructura que uso y por qué.

Un ADR es un documento corto que registra por qué tomaste una decisión técnica. Explico cómo los uso en proyectos pequeños y por qué me han ahorrado tiempo más de una vez.

Uso Cursor a diario en mis proyectos, pero reviso cada cambio línea a línea. Cuento el flujo de trabajo que me permite ir rápido sin perder de vista qué hace mi propio código.

Estoy preparando FishMind, un quiz sencillo para descubrir qué tipo de pescador eres. Todavía está pendiente de validación, pero el proyecto ya se puede conocer.

Un mapa para guardar lugares y capturas sin publicar la ubicación exacta por defecto. La aplicación ya funciona en desarrollo y la votación del nombre sigue abierta.

Ocho bajos de carpfishing en serie: hair rig, nudo sin nudo y medidas para caña grande y Resifight 2,20 m — sin improvisar en la orilla.

Primera salida a Siurana (29–31 mayo 2026): coup, cucharilla, fondo fallido y lecciones de puesto, equipo y normativa antes de volver.

Grok suma conectores empresariales, GitHub estandariza plugins en Copilot CLI y OpenAI mueve workspace agents a créditos: la IA se mide por integración, gobernanza y ROI.

Guía práctica para diseñar un agente IA que coordine tu equipo con seguridad, métricas y adopción real.

Conectores y MCP convierten a los agentes en operativos. GitHub y xAI empujan gobernanza. OpenAI cambia el coste: workspace agents pasan a créditos.