DevLog

Ciberseguridad en 2026: amenazas emergentes y qué deben saber los desarrolladores web

Hugo Cayón Laso — Fri, 22 May 2026 00:00:00 GMT

Ciberseguridad en 2026: amenazas emergentes y qué deben saber los desarrolladores web

La ciberseguridad ya no es un tema solo para equipos especializados: las amenazas evolucionan tan rápido que cualquier desarrollador web moderno debe entenderlas y mitigarlas. En 2026, varios vectores de ataque nuevos y tecnologías defensivas están cambiando la forma en que construimos, desplegamos y mantenemos aplicaciones — y eso incluye tus proyectos web.

En este post profundizamos en las tendencias claves de amenazas en 2026, con ejemplos actuales, implicaciones para devs y recomendaciones prácticas.

1. AI y agentes autónomos redefinen la seguridad

Una de las tendencias más notables es el auge de los ataques y defensas automatizados mediante IA. En 2026, los actores maliciosos ya no dependen únicamente de herramientas tradicionales o scripts: están utilizando agentes inteligentes que actúan de forma autónoma para encontrar vulnerabilidades, escalar ataques o engañar sistemas de seguridad.

Por ejemplo:

Los agentes pueden automatizar reconocimiento y explotación de fallos.
Pueden suplantar usuarios o simular patrones de comportamiento para engañar sistemas de detección.
A la defensiva, los equipos de seguridad usan IA para escaneo continuo y respuesta automática en producción.

¿Qué significa para ti como desarrollador? No basta con barreras estáticas (firewalls, WAF o filtros básicos): necesitas integrar defensas dinámicas y monitorización continua que puedan detectar y responder a amenazas en tiempo real.

2. Deepfakes y ataques de suplantación avanzados

La tecnología deepfake no solo es noticia en redes sociales: puede utilizarse para ingeniería social sofisticada, como engañar a usuarios o empleados con llamadas o vídeos falsos para obtener credenciales o acceso interno.

Esto tiene impacto directo en aplicaciones web cuando:

los usuarios son engañados para revelar datos sensibles,
se interceptan comunicaciones para saltarse autenticaciones,
o se manipulan flujos de login con identidades falsificadas.

Mitigación práctica Implementa autenticación multifactor (2FA/Passwordless), verifica identidad por más de un canal y regula la duración de tokens y sesiones para reducir el riesgo de suplantación.

3. Ransomware sigue creciendo con mayor sofisticación

El ransomware —software que cifra datos o sistemas y exige rescate— no solo sigue creciendo, sino que lo hace con tácticas más inteligentes:

exfiltración de datos antes del cifrado para extorsión dual,
ataques dirigidos a backups y sistemas de recuperación,
herramientas de "ransomware as a service" que facilitan ataques incluso a actores sin habilidades profundas.

¿Cómo te afecta como dev web? Aunque no construyas infraestructuras completas, tus aplicaciones pueden ser punto de entrada o vector para estos ataques si:

tus APIs no tienen límites de acceso,
manejas mal la gestión de sesiones,
o no validas correctamente entradas de usuario.

4. Software supply chain y dependencias inseguras

La cadena de suministro de software sigue siendo una de las áreas más vulnerables. Vulnerabilidades en dependencias (librerías, paquetes npm, componentes de terceros) pueden abrir puertas sin que tú mismo lo sepas:

librerías desactualizadas o abandonadas,
malwares incrustados en paquetes populares,
cadenas de herramientas que pasan código sin revisión.

Buenas prácticas de protección

Usa lockfiles y revisa versiones con herramientas como Dependabot o Renovate.
Implementa SCA (Software Composition Analysis) en tu CI/CD.
Audita tus dependencias regularmente, no solo al inicio del proyecto.

5. Identidad como nuevo perímetro de seguridad

Los modelos tradicionales de seguridad basados en redes perimetrales están siendo reemplazados por enfoques donde la identidad del usuario es el nuevo foco principal de defensa.

¿Por qué? Porque los atacantes usan credenciales robadas, phishing o deepfakes para parecer usuarios legítimos y así saltarse barreras estáticas.

Recomendaciones para devs

Implementa controles de acceso basados en roles (RBAC).
Usa autenticación fuerte (MFA, claves físicas, biometría donde sea posible).
Monitorea patrones de uso anómalos (IPs, dispositivos, geografías).

6. API-first architectures y nuevas vulnerabilidades

Las APIs se han convertido en el núcleo de casi todas las aplicaciones modernas. Eso las convierte en un blanco principal: ataques dirigidos a endpoints, fuga de datos y abusos de recursos se intensifican.

Algunas tendencias destacadas:

ataques DDoS orientados a APIs con lógica compleja,
búsqueda de endpoints mal documentados o sin autenticación,
APIs internas expuestas indirectamente por configuraciones erróneas.

Qué hacer

Asegura tus APIs con OAuth/OpenID Connect o JWT bien configurado.
Limita el rate de peticiones y habilita WAF/WAAP.
Haz revisiones de seguridad automatizadas (Scanner API, fuzzing).

7. Integración DevSecOps como estándar

El desarrollo moderno ya no puede separar el desarrollo de la seguridad: DevSecOps se está convirtiendo en la norma. Eso significa que desde el primer commit hasta el despliegue y el mantenimiento, las prácticas de seguridad deben integrarse en cada paso.

Esto incluye:

escaneo de código estático (SAST),
análisis de dependencias (SCA),
pruebas dinámicas de aplicación (DAST),
y monitores en producción con alertas automáticas.

Integrar estas herramientas en tu pipeline CI/CD reduce bugs y vulnerabilidades antes de que lleguen a producción.

Conclusión

En 2026, la seguridad ya no es un simple "tema aparte": es una parte esencial de cualquier ciclo de vida de desarrollo web. Con amenazas cada vez más automatizadas, sofisticadas y basadas en IA, los desarrolladores que entienden y aplican prácticas defensivas están un paso por delante.

Invertir tiempo en aprender sobre ciberseguridad desde autenticación robusta y API hardening hasta pipelines de DevSecOps ya no es opcional; es crucial para mantener tus proyectos y usuarios seguros.

Menta: Por qué creé mi propio gestor de tiempo para el trabajo

Hugo Cayón Laso — Thu, 21 May 2026 00:00:00 GMT

El problema de los tickets y el registro de horas

Si trabajas en desarrollo, soporte o cualquier sector basado en tareas, conocerás este problema: al final del día (o de la semana), tienes que registrar cuánto tiempo has dedicado a cada ticket o tarea.

Muchas herramientas corporativas son lentas, farragosas o requieren demasiados clics. En mi día a día, sentía que perdía el hilo de lo que estaba haciendo solo por intentar anotar cuándo empezaba y cuándo terminaba. Necesitaba algo que fuera instantáneo, y como no lo encontraba, decidí construirlo.

Así nace Menta.

Por qué decidí crear Menta

La idea principal era eliminar cualquier tipo de fricción. Quería una aplicación centralizada donde el flujo fuera lo más simple y rápido posible:

Escribir el nombre del ticket y pegar el link directo a la tarea.
Darle a empezar.
Tener un historial claro con los tiempos exactos de inicio y fin para luego pasarlos a la plataforma oficial de la empresa sin errores.

He buscado crear una herramienta que no te obligue a pensar en ella. Menta está ahí para servirte, registrar el dato y dejarte seguir con tu trabajo real.

Privacidad total: Tus datos son solo tuyos

Uno de los pilares de Menta es la seguridad y la privacidad. He desarrollado esta herramienta como una aplicación puramente frontend. ¿Qué significa esto para ti?

Sin base de datos externa: No hay un servidor central guardando lo que escribes.
Almacenamiento local: Todos los nombres de tareas, enlaces y registros de tiempo se guardan exclusivamente en el almacenamiento local de tu navegador (LocalStorage).
Privacidad por diseño: Al no haber backend, tus datos nunca viajan por internet ni salen de tu equipo.

Diseñada para la velocidad y la simplicidad

Cuando estás en medio de una jornada intensa, no quieres configurar proyectos complejos ni rellenar formularios infinitos. Por eso, Menta destaca en tres aspectos:

Registro centralizado y rápido

Simplemente introduces el identificador de tu tarea y empiezas. No hay menús desplegables innecesarios ni cargas tediosas. Si tienes el link del ticket, lo pegas y listo. Al final del día, tu historial es una lista limpia de todo lo que has hecho, con el minuto exacto en el que empezaste y terminaste.

Control total del tiempo

A veces sabes que un ticket te llevará exactamente 25 minutos; otras veces, necesitas un cronómetro abierto. Menta te ofrece ambos mundos:

Botones rápidos para sesiones estándar de 15, 25, 30, 45 o 60 minutos.
Entrada manual para cualquier duración entre 1 y 180 minutos.

Todo esto bajo una lógica de pausa y reanudación que calcula automáticamente el tiempo real trabajado, evitando que los errores de cálculo arruinen tu registro de jornada.

Estética "Menta" para el enfoque profundo

El diseño no es solo una capa de pintura. He elegido una estética de modo oscuro con toques verde menta por una razón específica: la calma.

Cuando trabajas con tickets estresantes, tener una interfaz oscura con un color de acento fresco ayuda a mantener la cabeza fría. El contraste es el justo para ser legible sin ser agresivo, permitiendo que la app viva en una pantalla secundaria sin distraerte de tu editor de código o de tu herramienta principal.

¿Qué puedes esperar de Menta?

En esta primera versión disponible, Menta ya te permite:

Asignar nombres y enlaces a cada sesión de trabajo.
Visualizar un historial detallado con fecha, hora de comienzo y hora de finalización.
Administrar sesiones de forma flexible y sin esperas.
Gestión local y segura, todo lo que ves se queda en tu navegador.

Mi objetivo era crear la herramienta más rápida y simple para los que, como yo, necesitan centralizar sus tiempos de trabajo sin complicaciones. Si alguna vez has olvidado a qué hora empezaste aquel ticket tan importante, Menta es para ti.

¡Espero que esta herramienta os resulte tan útil como me está resultando a mí en mi día a día!

Cookies, localStorage y sessionStorage: diferencias, usos y cuándo elegir cada uno

Hugo Cayón Laso — Mon, 18 May 2026 00:00:00 GMT

El navegador ofrece tres formas de guardar datos en el cliente: cookies, localStorage y sessionStorage. Los tres hacen algo parecido a simple vista, pero tienen comportamientos, límites y implicaciones de seguridad muy distintos.

Elegir el equivocado puede ser un bug difícil de encontrar, o peor, una vulnerabilidad de seguridad.

Cookies

Las cookies son el mecanismo más antiguo y el más potente, aunque también el más complejo. Se inventaron en 1994 y siguen siendo la base de la autenticación en la mayoría de las webs.

Cómo funcionan: el servidor puede establecer una cookie en la respuesta HTTP. El navegador la guarda y la envía automáticamente en cada petición posterior al mismo dominio. El servidor también puede leerla y modificarla.

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax; Max-Age=86400

Lo que las hace únicas:

Las envía el navegador automáticamente en cada petición. No tienes que hacer nada en JavaScript.
El servidor puede crearlas y leerlas, no solo el cliente.
Tienen fecha de expiración configurable.
Se pueden restringir a un dominio y a una ruta específica.

Capacidad: ~4 KB por cookie.

Cuándo usarlas: sesiones de usuario, autenticación, preferencias que el servidor necesita conocer.

Atributos de seguridad importantes

Set-Cookie: token=xyz; 
  HttpOnly;    /* JavaScript no puede leerla */
  Secure;      /* Solo se envía por HTTPS */
  SameSite=Lax /* Protección contra CSRF */

HttpOnly: impide que JavaScript acceda a la cookie con document.cookie. Protege contra XSS.
Secure: la cookie solo viaja por HTTPS, nunca por HTTP.
SameSite: controla cuándo se envía la cookie en peticiones cross-site. Lax es el equilibrio razonable; Strict es más seguro pero puede romper flujos de OAuth.

localStorage

localStorage es una API de JavaScript para guardar datos en el navegador de forma persistente. Los datos no tienen fecha de expiración y no se borran al cerrar el navegador ni el sistema.

// Guardar
localStorage.setItem('tema', 'oscuro');
localStorage.setItem('usuario', JSON.stringify({ nombre: 'Hugo', rol: 'admin' }));

// Leer
const tema = localStorage.getItem('tema');
const usuario = JSON.parse(localStorage.getItem('usuario'));

// Borrar
localStorage.removeItem('tema');
localStorage.clear(); // borra todo

Características:

Persiste indefinidamente hasta que se borra explícitamente.
Solo accesible desde JavaScript (el servidor no lo ve).
No se envía al servidor en cada petición.
Compartido entre todas las pestañas del mismo origen.

Capacidad: ~5-10 MB según el navegador.

Cuándo usarlo: preferencias de usuario (tema claro/oscuro), borradores guardados localmente, datos de la app que no necesita el servidor.

El error más común con localStorage

Guardar tokens de autenticación en localStorage es una mala práctica extendida:

// MAL: el token queda expuesto a cualquier script de la página
localStorage.setItem('auth_token', token);

Cualquier script de terceros (analytics, widgets, librerías comprometidas) puede leer localStorage. Si hay una vulnerabilidad XSS, el atacante roba el token con una línea de JavaScript. Una cookie HttpOnly no tiene ese problema porque JavaScript directamente no puede acceder a ella.

sessionStorage

sessionStorage funciona igual que localStorage en la API, con una diferencia clave: los datos se borran cuando se cierra la pestaña.

sessionStorage.setItem('paso_actual', '2');
const paso = sessionStorage.getItem('paso_actual');
sessionStorage.removeItem('paso_actual');

Características:

Se borra al cerrar la pestaña (no la ventana del navegador completa).
No se comparte entre pestañas, aunque sean del mismo origen.
Solo accesible desde JavaScript.

Capacidad: ~5-10 MB.

Cuándo usarlo: estado temporal de un formulario multipaso, datos de una sesión de compra que no deben persistir, cualquier cosa que solo tiene sentido mientras el usuario está en esa pestaña concreta.

Comparativa directa

	Cookies	localStorage	sessionStorage
Capacidad	~4 KB	~5-10 MB	~5-10 MB
Persistencia	Configurable	Permanente	Solo la pestaña
Acceso servidor	Sí (automático)	No	No
Acceso JS	Sí (salvo HttpOnly)	Sí	Sí
Compartido entre pestañas	Sí	Sí	No
Se envía en peticiones	Sí	No	No

Guía de decisión rápida

¿El servidor necesita los datos? → Cookie.

¿Son datos de autenticación? → Cookie con HttpOnly y Secure. Nunca localStorage.

¿Son preferencias del usuario que deben persistir entre sesiones? → localStorage.

¿Son datos temporales que solo tienen sentido en esta pestaña? → sessionStorage.

¿Necesitas más de 4 KB en el cliente y el servidor no los necesita? → localStorage o sessionStorage.

Conclusión

Las tres opciones existen porque resuelven problemas distintos. La elección incorrecta no siempre rompe la funcionalidad de inmediato, pero puede crear problemas de seguridad o de experiencia de usuario que son difíciles de diagnosticar.

La regla más importante: nunca guardes tokens de sesión o credenciales en localStorage. Para eso están las cookies con los atributos de seguridad adecuados.

Bun: el runtime JavaScript que quiere reemplazar a Node.js

Hugo Cayón Laso — Mon, 18 May 2026 00:00:00 GMT

Node.js lleva más de quince años siendo el runtime JavaScript por defecto fuera del navegador. Deno intentó reemplazarlo hace unos años con una apuesta por la seguridad y los estándares web. Ahora hay un tercer competidor que está generando mucho más ruido: Bun.

¿Qué hace diferente a Bun? ¿Deberías aprender a usarlo? ¿Vale la pena migrar proyectos existentes?

Qué es Bun

Bun es un runtime de JavaScript y TypeScript construido desde cero, diseñado para ser extremadamente rápido. A diferencia de Node.js (que usa el motor V8 de Chrome) o Deno (que también usa V8), Bun usa JavaScriptCore, el motor del navegador Safari de Apple, que en ciertos escenarios tiene un tiempo de arranque significativamente menor.

Pero la velocidad del motor es solo una parte. Lo que hace a Bun ambicioso es que no es solo un runtime. Es todo esto a la vez:

Runtime de JavaScript/TypeScript
Gestor de paquetes (alternativa a npm/pnpm/yarn)
Bundler (alternativa a webpack/esbuild/vite)
Test runner (alternativa a Jest/Vitest)

Un solo binario para hacer lo que antes requería cuatro herramientas distintas.

Por qué es tan rápido

Bun está escrito en Zig, un lenguaje de sistemas de bajo nivel (comparable a C o Rust en términos de rendimiento). Esto le permite tener un control muy fino sobre la memoria y las operaciones del sistema operativo.

Las diferencias de velocidad frente a Node.js son llamativas en algunos escenarios:

Inicio más rápido: los scripts arrancan hasta 4× más rápido, lo que importa especialmente en entornos serverless o CLIs.
Instalación de paquetes: el gestor de paquetes de Bun puede ser 10-25× más rápido que npm gracias a que mantiene una caché global de paquetes en formato binario.
Servidor HTTP: en benchmarks de servidores HTTP simples, Bun supera a Node.js de forma consistente.

Dicho esto, los benchmarks siempre miden escenarios ideales. En una aplicación real con base de datos, lógica de negocio compleja y dependencias de terceros, la diferencia es menos pronunciada.

Instalación y primeros pasos

# macOS y Linux
curl -fsSL https://bun.sh/install | bash

# Verificar instalación
bun --version

Desde ese momento tienes acceso a todos los comandos:

bun run index.ts        # Ejecutar un archivo TypeScript directamente
bun install             # Instalar dependencias (lee el package.json)
bun add express         # Añadir un paquete
bun test                # Ejecutar tests
bun build ./index.ts    # Bundlear para producción

TypeScript de serie, sin configuración

Una de las cosas más cómodas de Bun es que ejecuta TypeScript directamente, sin necesidad de compilar primero ni de configurar ts-node o tsx.

// server.ts
const server = Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hola desde Bun");
  },
});

console.log(`Servidor en http://localhost:${server.port}`);

bun run server.ts  # funciona directamente

Esto elimina un paso de configuración que en Node.js siempre ha sido algo engorroso.

Compatibilidad con Node.js

Bun implementa las APIs de Node.js más comunes: fs, path, http, crypto, stream... El objetivo es que la mayoría del código Node.js existente funcione sin modificaciones.

En la práctica la compatibilidad es muy alta pero no perfecta. Algunos paquetes que dependen de módulos nativos (.node files) o de partes muy específicas de la API de Node.js pueden necesitar ajustes.

También es compatible con los módulos de npm: el package.json sigue siendo el formato estándar y puedes instalar cualquier paquete del registro de npm.

El test runner integrado

Bun incluye su propio test runner con una API compatible con Jest:

import { describe, it, expect } from "bun:test";

describe("suma", () => {
  it("suma dos números", () => {
    expect(1 + 2).toBe(3);
  });

  it("gestiona negativos", () => {
    expect(-1 + -1).toBe(-2);
  });
});

bun test

El test runner es significativamente más rápido que Jest porque no necesita transpilación previa. Si ya tienes tests escritos con Jest, la migración suele requerir pocos cambios.

¿Deberías usarlo ahora?

Sí, tiene sentido si:

Estás empezando un proyecto nuevo y quieres un ecosistema más simple.
Tienes CLIs o scripts donde el tiempo de arranque importa.
Quieres ejecutar TypeScript sin fricción.
Quieres consolidar herramientas (npm + bundler + test runner → Bun).

Tómalo con calma si:

Tienes un proyecto en producción con dependencias nativas o un stack muy específico de Node.js.
Tu equipo no está familiarizado con herramientas fuera del ecosistema Node estándar.
Usas servicios de hosting que aún no tienen soporte oficial para Bun.

El estado actual

Bun lanzó su versión 1.0 en septiembre de 2023, lo que significa que ya no es un experimento. Ha tenido una adopción creciente, especialmente en proyectos de nueva creación y en la comunidad de desarrolladores que trabajan mucho con TypeScript.

El ecosistema sigue madurando: la compatibilidad con Node.js mejora en cada versión, la documentación se ha vuelto más completa y el soporte de plataformas de despliegue (Fly.io, Railway, Render) ha aumentado.

Conclusión

Bun no es hype vacío. Resuelve frustraciones reales del ecosistema JavaScript: la lentitud de npm, la fricción para usar TypeScript en Node.js, la necesidad de configurar demasiadas herramientas para empezar un proyecto.

Si lo pruebas en un proyecto personal o en un script, probablemente te sorprenderá lo fluido que resulta. Si estás evaluando adoptarlo en producción, la ecuación depende mucho de tu stack actual y de las dependencias que uses.

Lo que sí parece claro es que Bun está aquí para quedarse, y su existencia ya ha empujado a Node.js y a npm a mejorar su propio rendimiento. La competencia, en este caso, beneficia a todos.

Browser DevTools a fondo: la herramienta que tienes abierta y no aprovechas

Hugo Cayón Laso — Mon, 18 May 2026 00:00:00 GMT

Las DevTools del navegador son probablemente la herramienta que más tiempo tienes abierta como desarrollador web. También son probablemente la que menos aprovechas.

La mayoría usamos el inspector de elementos para ver estilos CSS y la consola para hacer console.log. Pero detrás de esas dos pestañas hay un conjunto de herramientas de análisis y depuración que pueden ahorrarte horas de trabajo.

Este artículo cubre Chrome DevTools, aunque Firefox y Edge tienen equivalentes muy similares. Puedes abrirlas con F12 o Cmd+Option+I en Mac.

Panel Elements: más allá de inspeccionar HTML

Todo el mundo conoce el inspector de elementos, pero hay detalles que pasan desapercibidos.

Editar el DOM en directo. Haz doble clic sobre cualquier nodo para editar su contenido o atributos. Puedes arrastrar nodos para cambiar su orden, eliminarlos con la tecla Delete o copiar su HTML con clic derecho.

Forzar estados CSS. En la pestaña Styles, el botón :hov te permite forzar estados como :hover, :focus, :active o :visited sin necesidad de activarlos con el ratón. Imprescindible para depurar estilos de hover.

Ver qué estilos se están aplicando realmente. La pestaña Computed muestra el valor final calculado de cada propiedad CSS, ya resueltas las especificidades y las herencias. Cuando un estilo no se aplica como esperas, aquí ves por qué.

Buscar en el DOM. Ctrl+F dentro del panel Elements abre un buscador que acepta texto, selectores CSS y expresiones XPath.

Panel Console: más potente de lo que parece

La consola no es solo para console.log. Tiene un conjunto completo de métodos y funciones útiles.

// Mostrar datos tabulados (ideal para arrays de objetos)
console.table(usuarios);

// Medir tiempo de ejecución
console.time('operacion');
hacerAlgo();
console.timeEnd('operacion'); // → operacion: 12.4ms

// Agrupar mensajes
console.group('Petición API');
console.log('URL:', url);
console.log('Respuesta:', data);
console.groupEnd();

// Mostrar traza de llamadas
console.trace('desde aquí');

$0 es el elemento seleccionado. Si tienes un elemento seleccionado en el panel Elements, puedes referenciarte a él desde la consola con $0. $1 es el anterior, $2 el anterior al anterior, hasta $4.

$(selector) y $$(selector). Son atajos de document.querySelector y document.querySelectorAll disponibles directamente en la consola.

$$('a[href^="http"]') // todos los enlaces externos

Panel Network: depurar peticiones HTTP

El panel Network es donde se ven todas las peticiones que hace tu página: HTML, CSS, JS, imágenes, llamadas a APIs...

Filtrar por tipo. Los botones de la barra superior filtran por XHR/Fetch (llamadas a API), JS, CSS, Img, Media. Cuando depuras una llamada a API, activa solo XHR/Fetch para no perderte entre el ruido.

Ver el detalle de una petición. Haz clic en cualquier petición para ver:

Headers: los headers de la request y la response.
Payload: el cuerpo de la petición (para POST, PUT...).
Response: la respuesta en texto o formateada.
Timing: cuánto tiempo tardó cada fase (DNS, conexión, espera, descarga).

Simular conexión lenta. El desplegable "No throttling" te permite simular 3G, 4G u otras velocidades. Fundamental para ver cómo se comporta tu app en condiciones reales.

Preserve log. Activa esta opción para que el historial de peticiones no se borre al navegar a otra página. Muy útil para depurar flujos que implican redirecciones.

Bloquear recursos. Clic derecho sobre una petición → "Block request URL". Puedes probar qué pasa si un script de terceros no carga, o si tu API falla.

Panel Sources: depuración con breakpoints

Sources es el depurador de JavaScript. Puedes pausar la ejecución, inspeccionar variables y ejecutar código paso a paso.

Poner un breakpoint. Abre un archivo JS y haz clic en el número de línea. La ejecución se pausará cuando llegue a ese punto.

debugger en el código. Puedes escribir debugger; directamente en tu JavaScript. El navegador pausará la ejecución ahí si las DevTools están abiertas.

function calcularPrecio(items) {
  debugger; // el navegador pausará aquí
  return items.reduce((total, item) => total + item.precio, 0);
}

Breakpoints condicionales. Clic derecho sobre el número de línea → "Add conditional breakpoint". Solo pausa si se cumple una condición. Perfecto cuando el bug solo ocurre con ciertos datos.

Watch expressions. En el panel lateral puedes añadir expresiones que se evalúan en tiempo real mientras la ejecución está pausada.

Panel Performance: encontrar por qué tu app va lenta

Performance te permite grabar lo que hace el navegador durante un periodo de tiempo y analizar cada milisegundo.

Cómo usarlo:

Abre el panel Performance.
Pulsa el botón de grabar (círculo rojo).
Reproduce la acción que va lenta.
Para la grabación.

Verás una línea de tiempo con frames por segundo (FPS), llamadas a JavaScript, renderizado, pintura...

Lo que debes buscar:

Barras rojas en la línea de FPS: frames que tardaron demasiado (janky animation).
Funciones JavaScript que ocupan demasiado tiempo en la flame chart.
Recálculos de layout frecuentes (aparecen en morado).

Panel Application: storage, cookies y más

Este panel te da acceso a todos los datos que la página guarda en el navegador.

Local Storage y Session Storage: ver, editar y borrar pares clave-valor.
Cookies: ver todas las cookies, sus atributos (HttpOnly, Secure, SameSite) y su valor.
Cache Storage: archivos almacenados por Service Workers.
IndexedDB: base de datos estructurada del navegador.

Desde aquí también puedes forzar la actualización de un Service Worker o limpiar todos los datos almacenados con el botón "Clear site data".

Atajos que vale la pena memorizar

Atajo	Acción
`F12` / `Cmd+Option+I`	Abrir/cerrar DevTools
`Ctrl+Shift+P`	Paleta de comandos
`Ctrl+P`	Abrir archivo
`Esc`	Abrir/cerrar consola en cualquier panel
`Ctrl+L`	Limpiar consola
`F8`	Pausar/reanudar ejecución
`F10`	Siguiente línea (step over)
`F11`	Entrar en función (step into)

Conclusión

Las DevTools son un entorno de desarrollo completo integrado en el navegador. Cada panel está diseñado para resolver un tipo de problema concreto.

La próxima vez que tengas un bug o un problema de rendimiento, antes de añadir otro console.log, abre el panel correcto. Probablemente ya te está dando la respuesta.

CSS Grid vs Flexbox: cuándo usar cada uno de verdad

Hugo Cayón Laso — Mon, 18 May 2026 00:00:00 GMT

Si llevas un tiempo escribiendo CSS, seguramente habrás tenido esta duda: ¿pongo un display: flex o un display: grid? Y si eres honesto, probablemente la mayoría de las veces hayas tirado de Flexbox por costumbre.

No estás solo. Pero hay una forma mejor de tomar esa decisión, y no implica memorizar propiedades.

La pregunta que lo cambia todo

Antes de pensar en la propiedad CSS, hazte esta pregunta:

¿Estoy distribuyendo elementos en una dirección o en dos?

Una dirección (fila o columna): Flexbox.
Dos direcciones (filas y columnas a la vez): Grid.

Eso es el 80% de la decisión. El otro 20% son matices que veremos ahora.

Flexbox: el maestro de una dimensión

Flexbox nació para distribuir elementos a lo largo de un eje. Es perfecto cuando tienes un contenedor y quieres organizar sus hijos en fila o en columna, con control sobre el espaciado, el alineamiento y el orden.

Casos donde Flexbox brilla:

Barra de navegación con enlaces
Botones agrupados en una fila
Centrar un elemento vertical y horizontalmente
Tarjetas en una fila que se adaptan al espacio disponible

/* Barra de navegación clásica */
nav {
  display: flex;
  justify-content: space-between;
  align-items: center;
  gap: 1rem;
}

La clave de Flexbox es que el contenedor manda. Tú le dices al padre cómo repartir a sus hijos, y los hijos se adaptan.

Grid: el maestro de dos dimensiones

Grid te permite definir filas y columnas al mismo tiempo. Es el sistema más potente para construir layouts completos porque puedes controlar exactamente dónde va cada elemento en ambos ejes.

Casos donde Grid brilla:

Layout completo de una página (header, sidebar, contenido, footer)
Galería de imágenes con filas y columnas
Cuadrícula de tarjetas con tamaños distintos
Cualquier cosa donde necesites que los elementos se alineen en dos ejes

/* Layout completo de página */
body {
  display: grid;
  grid-template-columns: 240px 1fr;
  grid-template-rows: auto 1fr auto;
  grid-template-areas:
    "header  header"
    "sidebar content"
    "footer  footer";
  min-height: 100vh;
}

header { grid-area: header; }
aside  { grid-area: sidebar; }
main   { grid-area: content; }
footer { grid-area: footer; }

Con Grid no estás diciéndole a los hijos cómo comportarse entre ellos: estás definiendo una estructura y luego colocas los elementos dentro de ella.

La confusión más común

Muchos desarrolladores usan Flexbox para construir layouts de página completos porque lo conocen mejor. Funciona, pero se complica rápido: necesitas anidar contenedores, controlar el flex-wrap, gestionar anchos manualmente...

La señal de que deberías usar Grid es cuando empiezas a luchar contra Flexbox para que los elementos se alineen en más de una dirección.

/* Esto con Flexbox require bastante malabarismo */
.card-grid {
  display: flex;
  flex-wrap: wrap;
  gap: 1rem;
}
.card {
  flex: 1 1 300px; /* Funciona, pero es frágil */
}

/* Con Grid es directo */
.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(300px, 1fr));
  gap: 1rem;
}

La versión Grid no solo es más corta: es más predecible. Los elementos siempre tendrán el mismo tamaño mínimo y se adaptarán solos al espacio disponible.

Pueden (y deben) usarse juntos

Grid y Flexbox no son rivales. Un layout real los combina constantemente:

Grid para la estructura macro de la página.
Flexbox para organizar los elementos dentro de cada celda de Grid.

/* Grid para el layout general */
.page {
  display: grid;
  grid-template-columns: 1fr 3fr;
  gap: 2rem;
}

/* Flexbox dentro de la tarjeta */
.card {
  display: flex;
  flex-direction: column;
  justify-content: space-between;
}

Referencia rápida

Situación	Usa
Centrar un elemento	Flexbox
Barra de navegación	Flexbox
Botones en línea	Flexbox
Layout de página completa	Grid
Galería de imágenes	Grid
Tarjetas con filas y columnas	Grid
Alinear en una dirección	Flexbox
Alinear en dos direcciones	Grid
Layout macro + componentes internos	Ambos

Conclusión

No existe una respuesta universal. Existe la pregunta correcta: ¿una dimensión o dos?

Si te encuentras peleando contra tu CSS para que las cosas se alineen como quieres, probablemente estás usando la herramienta equivocada. Cambia de una a otra y verás cómo el problema se simplifica.

El mejor CSS no es el que demuestra que sabes mucho. Es el que describe exactamente lo que quieres que pase.

Variables de entorno y secretos: cómo gestionar la configuración de tus proyectos

Hugo Cayón Laso — Mon, 18 May 2026 00:00:00 GMT

Alguna vez has visto una contraseña de base de datos escrita directamente en el código. Quizás incluso en el tuyo propio, al principio. No pasa nada, todos hemos pasado por ahí.

Pero hay una forma mucho mejor de manejar esto, y no es solo por seguridad. Las variables de entorno hacen que tu código sea más flexible, más portable y más fácil de mantener.

Qué es una variable de entorno

Una variable de entorno es un valor de configuración que existe fuera del código, en el entorno donde se ejecuta la aplicación. El sistema operativo, el servidor o el proceso que arranca tu app se las inyecta al proceso en tiempo de ejecución.

En lugar de esto:

$db = new PDO('mysql:host=localhost;dbname=miapp', 'root', 'mi_contraseña_secreta');

Haces esto:

$db = new PDO(
    'mysql:host=' . $_ENV['DB_HOST'] . ';dbname=' . $_ENV['DB_NAME'],
    $_ENV['DB_USER'],
    $_ENV['DB_PASS']
);

El código no sabe cuál es la contraseña. Solo sabe dónde buscarla. Eso es lo importante.

Por qué importa más allá de la seguridad

La seguridad es la razón más obvia, pero no la única:

Portabilidad. El mismo código funciona en local, en staging y en producción sin modificar nada. Solo cambian los valores de las variables.

Colaboración. Cada desarrollador puede tener su configuración local sin pisar la de los demás ni la de producción.

Sin secretos en Git. Los repositorios son potencialmente públicos, incluso los privados pueden filtrarse. Los secretos no deben estar en el historial de commits nunca.

Separación de responsabilidades. La configuración es responsabilidad del entorno, no del código.

El archivo `.env`

La forma más común de trabajar con variables de entorno en desarrollo local es el archivo .env. Es un archivo de texto plano con pares clave-valor:

# .env
APP_NAME=MiAplicacion
APP_ENV=local
APP_DEBUG=true

DB_HOST=127.0.0.1
DB_PORT=3306
DB_NAME=miapp
DB_USER=root
DB_PASS=supersecreta

MAIL_HOST=smtp.mailtrap.io
MAIL_PORT=2525
MAIL_USER=usuario
MAIL_PASS=contraseña

Librerías como phpdotenv (PHP), dotenv (Node.js) o los frameworks modernos lo cargan automáticamente al arrancar la aplicación.

La regla más importante: `.env` nunca en Git

Añade .env a tu .gitignore desde el primer commit. Sin excepciones.

# .gitignore
.env
.env.local
.env.production

Lo que sí debe estar en Git es un .env.example con las mismas claves pero sin los valores reales. Sirve como documentación para cualquiera que clone el proyecto:

# .env.example  ← este SÍ va en Git
APP_NAME=
APP_ENV=local
APP_DEBUG=true

DB_HOST=127.0.0.1
DB_PORT=3306
DB_NAME=
DB_USER=
DB_PASS=

Cómo acceder a las variables

En PHP:

// Con phpdotenv instalado y cargado
$host = $_ENV['DB_HOST'];
$host = getenv('DB_HOST'); // alternativa

En JavaScript (Node.js):

// Con el paquete dotenv
const host = process.env.DB_HOST;

En la terminal:

export DB_HOST=localhost
echo $DB_HOST

Niveles de entorno

Un proyecto suele tener varios entornos con configuraciones distintas:

Entorno	Propósito
`local`	Tu máquina de desarrollo
`testing`	Pruebas automatizadas
`staging`	Preproducción, copia de producción
`production`	El entorno real con usuarios

Cada entorno tiene su propio conjunto de variables. La base de datos de producción nunca debe ser la misma que la de desarrollo.

Secretos en producción: más allá del `.env`

En producción, copiar un archivo .env al servidor es una opción, pero no la más robusta. Las alternativas más seguras:

Variables del sistema operativo. El servidor tiene las variables configuradas directamente en su entorno. No hay archivo que pueda filtrarse.

Gestores de secretos. Servicios como AWS Secrets Manager, HashiCorp Vault o Doppler almacenan los secretos cifrados y los inyectan en tiempo de ejecución. Tu aplicación ni siquiera ve el valor en texto plano hasta que lo necesita.

Secrets de la plataforma. Servicios como Vercel, Railway o Heroku tienen paneles para definir variables de entorno sin necesidad de archivos.

Errores comunes

Subir el .env a Git. El más frecuente. Si ya ocurrió, no basta con borrar el archivo: el secreto está en el historial. Hay que rotar las credenciales (cambiar las contraseñas) y usar git filter-repo para limpiar el historial.

Variables con nombres genéricos. PASSWORD o KEY no dicen nada. Usa nombres descriptivos: DB_PASS, STRIPE_SECRET_KEY, SMTP_PASSWORD.

El mismo .env para todos los entornos. Cada entorno debe tener sus propios valores. Compartir la base de datos de producción con el entorno de desarrollo es una receta para el desastre.

Valores por defecto inseguros en código. Esto es especialmente peligroso:

// MAL: si la variable no existe, usa una contraseña por defecto
$pass = $_ENV['DB_PASS'] ?? 'admin123';

Si una variable crítica no existe, la aplicación debe fallar con un error claro, no continuar con un valor inseguro.

Conclusión

Las variables de entorno son una de esas cosas que parecen un detalle técnico menor pero tienen un impacto enorme en la seguridad y en la calidad del proyecto.

La regla es simple: nada que cambie entre entornos, y nada que sea secreto, debe estar en el código.

Si lo aplicas desde el principio de cada proyecto, te ahorrarás más de un problema en el futuro.

Un año como desarrollador web: lo que nadie te cuenta

Hugo Cayón Laso — Mon, 18 May 2026 00:00:00 GMT

Hace exactamente un año firmé mi primer contrato como desarrollador web.

Recuerdo que ese día mezcló dos sensaciones que raramente van juntas: la ilusión de que por fin empezaba algo real, y la duda de si realmente estaba preparado para ello. Spoiler: las dos tenían razón a medias.

Ahora que ha pasado un año, quiero escribir esto con honestidad. No el resumen de LinkedIn donde todo fue brillante, sino el relato de cómo fue de verdad: lo que me costó, lo que me sorprendió y lo que ojalá hubiera sabido antes.

El primer día

Llegué con lo que en ese momento me parecían dudas puntuales. Sabía programar, tenía proyectos propios, había estudiado. Pero el primer día me di cuenta de que lo que no sabía no era código, sino contexto.

El contexto de cómo trabaja un equipo de verdad. El contexto de un proyecto con años de historia detrás. El contexto de por qué algo está hecho de cierta manera, aunque a primera vista parezca que podría hacerse mejor.

El stack que encontré fue CakePHP, JavaScript y MySQL. No era lo más moderno del mundo, pero eso me enseñó algo valioso muy pronto: en el trabajo real no eliges el stack, aprendes el que hay. Y eso, paradójicamente, te hace mejor programador que si siempre trabajaras con lo que ya conoces.

La sorpresa que no me esperaba: el equipo

Si me hubieras preguntado antes de empezar qué iba a ser lo más difícil, habría dicho el código. Me habría equivocado.

Lo más difícil, y también lo más importante, fue aprender a trabajar con otras personas.

No me refiero a llevarse bien, que eso es otra cosa. Me refiero a cosas concretas que nadie te enseña en la universidad:

Cómo hacer una pregunta bien hecha. No vale "esto no funciona". Hay que explicar qué esperabas, qué pasa, qué ya has probado.
Cómo revisar el código de otro. Criticar un enfoque sin atacar a quien lo escribió.
Cómo pedir ayuda sin parecer que te rindes. Hay un punto entre bloquearse demasiado pronto y bloquearse demasiado tarde, y encontrarlo lleva tiempo.
Cómo comunicar avance e impedimentos. Que el equipo sepa en qué estás, aunque aún no hayas terminado.

Todo eso parece obvio escrito así. En la práctica cuesta mucho más de lo que parece.

El momento en que algo cambió

No recuerdo una fecha exacta. Fue más un proceso gradual que un instante.

Hubo un punto en el que dejé de mirar a mi alrededor para ver si alguien me estaba observando. Dejé de dudar si debía abrir la boca en una reunión. Empecé a proponer cosas en lugar de solo ejecutar lo que me asignaban.

Me sentí parte del equipo.

Eso no significa que de repente lo supiera todo. Significa que me sentí cómodo no sabiéndolo todo, que es algo completamente diferente.

Las dudas evolucionan

Una cosa que nadie me contó, y que ahora me parece uno de los indicadores más claros de progreso real, es que las dudas cambian.

El primer mes tenía dudas sobre cosas que ahora resuelvo en minutos. Pero en lugar de tener menos dudas, tengo dudas sobre cosas más complejas. Cuestiones de arquitectura, de rendimiento, de decisiones que afectan al largo plazo.

Eso al principio puede confundirte: "¿Por qué sigo teniendo tantas dudas si ya llevo un año?" La respuesta es que las dudas no desaparecen, suben de nivel. Y subir de nivel es exactamente lo que quieres que pase.

Lo que le diría al Hugo de hace un año

Si pudiera hablar con el yo de hace exactamente un año, le diría tres cosas:

Pregunta más. Hay una tentación enorme, sobre todo al principio, de aparentar que ya lo sabes. Resistirla es una de las mejores inversiones que puedes hacer. Nadie espera que lo sepas todo. Sí esperan que seas honesto sobre lo que no sabes.

Toma notas desde el primer día. Todo lo que aprendes en los primeros meses se olvida más rápido de lo que crees. Las decisiones que tomó el equipo hace dos años, el porqué de cierta estructura, ese truco que alguien te enseñó de pasada. Apúntalo todo. Tu yo de seis meses después te lo agradecerá.

Disfruta del aprendizaje. Hay una prisa por llegar a "saber suficiente" que hace que no valores el camino. Pero el camino es donde está casi todo. Los momentos en los que algo por fin encaja, en los que entiendes por qué algo funciona como funciona, en los que resuelves solo algo que hace tres semanas habría requerido ayuda. Esos momentos merecen ser disfrutados, no solo superados.

Un año después

Ha sido un año intenso. También ha sido un año gratificante.

He aprendido más de lo que habría aprendido en cualquier otro contexto. He cometido errores que solo se cometen cuando el código va a producción de verdad. He visto cómo una decisión técnica afecta a personas reales.

Y sobre todo, he comprobado que este es el trabajo que quería hacer.

Queda mucho por aprender. Pero ya no me da miedo decirlo.

Si estás a punto de empezar tu primer trabajo como desarrollador, o llevas poco tiempo y te reconoces en algo de lo que he contado, escríbeme. Me alegra saber que este tipo de reflexiones le sirven a alguien.

Mi primer experimento creando una app para iOS y macOS

Hugo Cayón Laso — Thu, 07 May 2026 00:00:00 GMT

Desde hace tiempo tenía curiosidad por el desarrollo de aplicaciones para el ecosistema Apple, y finalmente he decidido empezar a aprender Swift creando un pequeño proyecto personal: una aplicación de tareas muy simple para iOS y macOS.

La idea no es crear algo revolucionario ni competir con las aplicaciones que ya existen. De hecho, el objetivo principal de este proyecto es aprender. Nunca he trabajado seriamente con Swift, así que quiero usar esta app como una forma práctica de ir entendiendo cómo funciona el desarrollo nativo en Apple.

¿Por qué una app de tareas?

Porque parece un proyecto perfecto para empezar.

Una aplicación To-Do es algo relativamente sencillo, pero al mismo tiempo permite tocar muchos conceptos básicos del desarrollo:

Crear interfaces,
Guardar datos,
Organizar pantallas,
Entender cómo funciona una aplicación real.

Además, es un tipo de herramienta que utilizo todos los días, así que me parece una buena forma de construir algo útil mientras aprendo.

Qué quiero aprender

Ahora mismo estoy empezando prácticamente desde cero, así que mi enfoque es ir poco a poco y experimentar.

Estas son algunas de las tecnologías que quiero explorar durante el proyecto:

SwiftUI, para construir la interfaz de la aplicación.
SwiftData, para guardar las tareas de forma sencilla.
CloudKit, aunque probablemente lo deje para más adelante cuando tenga una base más estable.
Integración básica con el ecosistema Apple, como widgets o atajos.

Seguramente cometa errores y tenga que rehacer muchas cosas durante el proceso, pero precisamente esa es parte de la experiencia.

Una aplicación muy simple (de momento)

La primera versión será extremadamente básica:

Crear tareas,
Marcarlas como completadas,
Eliminarlas,
Y poco más.

Quiero evitar intentar hacer demasiadas cosas desde el principio y centrarme primero en entender bien las bases.

Continuará...

Este es solo el inicio del proyecto. A medida que vaya avanzando, iré publicando nuevos posts compartiendo el progreso, las decisiones que vaya tomando y todo lo que vaya aprendiendo sobre Swift y desarrollo para el ecosistema Apple.

No sé realmente hasta dónde llegará este experimento, pero precisamente esa es la gracia. Todo empezó simplemente por curiosidad, por aprender algo nuevo y por probar cómo es desarrollar aplicaciones dentro del ecosistema de Apple.

Buscador inteligente y estética renovada: La nueva experiencia DevLog

Hugo Cayón Laso — Sat, 18 Apr 2026 00:00:00 GMT

Hoy es un día importante para la identidad visual de DevLog. He completado una fase de renovación estética global que nos acerca a una interfaz mucho más moderna y actual, asegurando que la experiencia de usuario sea fluida, táctil y coherente en cada rincón de la plataforma.

A continuación, detallo los cambios principales y la nueva herramienta de búsqueda que he implementado.

1. Buscador Inteligente: Estética y Velocidad

El buscador ha dejado de ser una simple funcionalidad para convertirse en una de las piezas centrales de la experiencia de usuario. El nuevo diseño se aleja de lo convencional para abrazar una estética más "pro":

Fase de Inmersión: El modal de búsqueda ahora utiliza glassmorphism con desenfoques de fondo, integrándose de forma orgánica con la interfaz.
Diferenciación Visual: Ahora es mucho más fácil distinguir entre posts y etiquetas gracias a iconos específicos y tarjetas con bordes reactivos que se iluminan al seleccionarlos.
Navegación por Teclado: He implementado el estándar Cmd + K (Mac) o Ctrl + K (Windows) para abrir el buscador y soporte completo para las flechas del teclado y Enter, permitiendo una navegación fluida sin tocar el ratón.
Motor Estático: Gracias a Pagefind, la búsqueda es virtualmente instantánea, indexando el contenido en el lado del cliente para una respuesta sin latencia.

2. Estandarización de la navegación e interactividad

El cambio más profundo no está en lo que ves, sino en lo que sientes al interactuar. He tomado el diseño sutil y elegante de los botones del encabezado (header) y lo he aplicado como estándar en todo el sitio.

El nuevo lenguaje "Flat & Reactive"

He eliminado los escalados agresivos y las traslaciones exageradas. El nuevo patrón se define por:

Shadow-LG Tintada: Al pasar el ratón, los elementos reaccionan con una sombra suave teñida por el color primario, aportando profundidad sin ruido visual.
Acción Táctil: Al hacer clic, los elementos se comprimen ligeramente (scale-95), ofreciendo un feedback físico que imita la pulsación de un botón real.
Micro-transiciones: Cada cambio de estado ocurre en 300 ms de forma suave, alineado con el sistema de transiciones del navegador.

Este lenguaje se ha aplicado a las tarjetas de posts, tarjetas de etiquetas, la navegación entre artículos y los controles del footer.

3. Nueva sección: Actualizaciones (Updates)

Para mantener una transparencia total sobre la evolución de este proyecto, he creado una nueva sección dedicada: Actualizaciones.

A diferencia de los artículos de blog convencionales, la sección de Actualizaciones servirá para comunicar:

Nuevas funcionalidades: Implementación de herramientas de búsqueda, sistemas de idiomas, etc.
Mejoras Estéticas: Cambios en la paleta de colores, tipografía o micro-animaciones.
Cambios Internos: Optimizaciones de rendimiento, mejoras en el SEO o actualizaciones de la arquitectura del código.

Cada actualización cuenta con su propia navegación inteligente y está categorizada para que puedas ver rápidamente el historial de mejoras de DevLog.

4. Coherencia en cada página

Desde la página de Inicio hasta los apartados Legal y de Contacto, cada botón e icono ahora comparte el mismo ADN visual. Los botones sociales ahora son circulares, consistentes y reactivos. Además, he añadido un acceso directo al feed RSS en el pie de página (footer) para que puedas seguir las novedades desde tu lector favorito, eliminando cualquier discrepancia estética que pudiera haber quedado de versiones anteriores.

Te invito a explorar la nueva sección de Actualizaciones y a probar el nuevo buscador presionando Cmd + K o Ctrl + K.

Cómo construí mi blog con Astro: arquitectura, componentes y trucos

Hugo Cayón Laso — Mon, 09 Mar 2026 00:00:00 GMT

Crear este blog con Astro ha sido una de las mejores decisiones que he tomado como desarrollador. En este artículo quiero compartir cómo lo construí, qué decisiones tomé a nivel técnico y partes del código que se utiliza en mi estructura actual. Mi objetivo es que cualquier persona pueda replicarlo o inspirarse para crear el suyo.

¿Por qué Astro?

Elegí Astro por varias razones:

Generación estática ultra rápida.
Soporte integrado de Markdown + MDX.
Posibilidad de usar componentes de React, Svelte, Vue… solo donde hace falta.
Su arquitectura de islas, que optimiza la carga y el rendimiento.
Un sistema de contenido: astro:content.

Estructura general del proyecto

src/
  components/
  layouts/
  pages/
    blog/
    tags/
  content/
    posts/

A continuación explico qué papel juega cada carpeta y por qué la organicé así:

src/components/ Aquí guardo todos los componentes reutilizables que voy creando para el blog: tarjetas de posts, botones, navegación, componentes UI, etc. Mi objetivo es que cualquier pieza visual que se repita en varias páginas esté centralizada en este directorio.
src/layouts/ Esta carpeta contiene los layouts del blog. Un layout define la estructura general de una página (cabecera, pie, estilos base, tipografía…), así que tenerlos separados me permite reutilizar la misma estructura en todas las publicaciones sin duplicar código.
src/pages/ Astro utiliza un sistema de enrutado basado en archivos, así que todo lo que esté aquí se convierte automáticamente en una ruta pública.
- pages/blog/ Incluye el listado de posts, la paginación y la lógica que genera las páginas individuales del blog.
- pages/tags/ Las páginas de etiquetas se generan desde aquí. Me interesa tenerlas separadas para mejorar la navegación del blog y permitir al lector filtrar contenido por temas.
src/content/ Esta es la parte donde vive todo el contenido del blog.
- content/posts/ Aquí es donde guardo cada post como un archivo Markdown independiente. Cada post está escrito en Markdown y validado con Content Collections de Astro, lo que me asegura tipado, metadatos coherentes y un sistema más ordenado para gestionar las publicaciones.

Gracias a esta estructura, el proyecto se mantiene limpio y escalable. Cada pieza tiene su lugar y puedo añadir nuevas funciones o componentes sin complicar la organización general.

1. Arquitectura de Datos: Content Collections

El corazón del blog es el sistema de Content Collections. No solo guardamos archivos Markdown, sino que definimos un contrato estricto mediante un esquema de Zod. Esto nos permite validar que cada post tenga título, fecha y etiquetas antes de que el sitio se construya, evitando errores en producción.

// src/content/config.ts
import { defineCollection, z } from "astro:content";

const posts = defineCollection({
  type: "content",
  schema: ({ image }) =>
    z.object({
      title: z.string(),
      description: z.string(),
      date: z.date(),
      author: z.string(),
      tags: z.array(z.string()).optional(),
      cover: image().optional(),
      draft: z.boolean().default(false),
    }),
});

export const collections = { posts };

2. Flujo de Generación y Rutado Dinámico

Astro genera el blog de forma estática (SSG) para un rendimiento imbatible. Para las páginas de cada post (src/pages/blog/[slug].astro), utilizamos getStaticPaths para mapear cada archivo de la colección a una URL única.

Este es un ejemplo real de cómo gestionamos la lógica de Navegación Relativa (Anterior/Siguiente) y el cálculo del Tiempo de Lectura in-situ:

// src/pages/blog/[slug].astro
---
import { getCollection } from "astro:content";
import PostLayout from "@/layouts/PostLayout.astro";
import { calculateReadingTime } from "@/utils/readingTime";

export async function getStaticPaths() {
  const posts = (await getCollection("posts"))
    .filter((post) => !post.data.draft)
    .sort((a, b) => a.data.date.getTime() - b.data.date.getTime());

  return posts.map((post, index) => ({
    params: { slug: post.slug },
    props: {
      post,
      prev: posts[index - 1] ?? null,
      next: posts[index + 1] ?? null,
    },
  }));
}

const { post, prev, next } = Astro.props;
const { Content } = await post.render();
---
<PostLayout
  {...post.data}
  prev={prev}
  next={next}
  readingTime={post.body ? calculateReadingTime(post.body) : undefined}
>
  <Content />
</PostLayout>

3. Jerarquía de Layouts y Herencia de Metadatos

La estructura visual sigue una jerarquía de composición clara:

main.astro: El layout "Shell". Configura el HTML base, fuentes, ClientRouter y los metadatos globales (OpenGraph, Twitter).
BlogLayout.astro: Layout intermedio para listados y categorías.
PostLayout.astro: El layout especializado. Gestiona la lógica de artículos, inyecta JSON-LD para SEO semántico y maneja componentes complejos como la galería de imágenes con astro:assets.

3. Jerarquía de Layouts: La estructura del Blog

La arquitectura visual se divide en tres niveles de responsabilidad, utilizando la composición de Astro para maximizar la reutilización y el rendimiento.

3.1. El Layout "Shell" (`main.astro`)

Este es el punto de entrada de todas las páginas. Gestiona el document HTML, el SEO global, las fuentes y el sistema de transiciones.

// src/layouts/main.astro
---
import "../styles/global.css";
import Header from "../components/Header.astro";
import Footer from "../components/Footer.astro";
import { ClientRouter } from "astro:transitions";

const { title, description, image = "/og-image.png", type = "website" } = Astro.props;
const imageUrl = new URL(image, Astro.site).toString();
---

<html lang="es" class="scroll-smooth">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta name="description" content={description} />
    <meta name="robots" content="index, follow" />
    <link rel="canonical" href={Astro.url} />

    <!-- Open Graph -->
    <meta property="og:title" content={title} />
    <meta property="og:description" content={description} />
    <meta property="og:type" content={type} />
    <meta property="og:url" content={Astro.url} />
    <meta property="og:image" content={imageUrl} />
    <meta property="og:image:alt" content={title} />
    <meta property="og:locale" content="es_ES" />
    <meta property="og:site_name" content="DevLog" />

    <!-- Twitter Card -->
    <meta name="twitter:card" content="summary_large_image" />
    <meta name="twitter:title" content={title} />
    <meta name="twitter:description" content={description} />
    <meta name="twitter:image" content={imageUrl} />

    <!-- Favicons -->
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <link rel="icon" type="image/png" href="/favicon.png" />

    <!-- RSS Feed Discovery -->
    <link rel="alternate" type="application/rss+xml" title="DevLog RSS Feed" href="/rss.xml" />

    <title>{title}</title>

    <slot name="head" />
    <ClientRouter />
  </head>

  <body class="min-h-screen grid grid-rows-[auto_1fr_auto] bg-background text-foreground antialiased font-sans">
    <Header />
    <main transition:animate="fade">
      <slot />
    </main>
    <Footer />
  </body>
</html>

3.2. El Layout de Listado (`BlogLayout.astro`)

Un pequeño wrapper que simplifica la creación de páginas de índice y etiquetas, heredando del Shell.

// src/layouts/BlogLayout.astro
---
import BaseLayout from "@/layouts/main.astro";

const { title = "Blog", description = "Últimos artículos", image, type = "website" } = Astro.props;
---

<BaseLayout title={title} description={description} image={image} type={type}>
  <slot />
</BaseLayout>

3.3. El Layout de Artículo (`PostLayout.astro`)

Este es el componente más rico. Gestiona el SEO semántico, la portada optimizada, la barra de lectura y la navegación entre artículos.

// src/layouts/PostLayout.astro
---
import BaseLayout from "@/layouts/main.astro";
import type { CollectionEntry } from "astro:content";
import { Badge } from "@/components/ui/badge";
import { ChevronLeft, ChevronRight, Link2, Check } from "@lucide/astro";
import { Image } from "astro:assets";
import { tagUrl } from "@/utils/tag";

const { title, description, date, author, tags, cover, prev, next, readingTime } = Astro.props;

const formattedDate = date
  ? new Date(date).toLocaleDateString("es-ES", { dateStyle: "long" })
  : "Fecha desconocida";
const coverImage = typeof cover === "string" ? cover : cover?.src;
---

<BaseLayout title={title} description={description} type="article" image={coverImage}>
  <Fragment slot="head">
    <script type="application/ld+json" set:html={JSON.stringify({
      "@context": "https://schema.org",
      "@type": "BlogPosting",
      "headline": title,
      "description": description,
      "datePublished": date ? new Date(date).toISOString() : undefined,
      "url": Astro.url.toString(),
      ...(author && { "author": { "@type": "Person", "name": author } }),
    })} />
  </Fragment>

  <article class="max-w-4xl mx-auto px-4 py-20 reveal">
    {cover && (
      <figure class="mb-12 max-h-[400px] overflow-hidden rounded-xl">
        <Image
          src={coverImage as any}
          alt={`Imagen de portada: ${title}`}
          width={1200}
          height={630}
          class="w-full object-cover"
        />
      </figure>
    )}

    <header class="max-w-3xl mx-auto mb-12 pb-6 border-b border-gray-200/50 dark:border-gray-700/50">
      <div class="flex flex-col sm:flex-row sm:items-center sm:justify-between gap-2 text-sm text-muted-foreground mb-4">
        <time class="tabular-nums">Publicado el {formattedDate} {readingTime && `• ${readingTime} min de lectura`}</time>
        {author && <p class="font-medium">Por <strong>{author}</strong></p>}
      </div>
      <h1 class="text-4xl sm:text-5xl font-extrabold tracking-tight mb-4">{title}</h1>
      <div class="flex flex-wrap gap-2">
        {(tags ?? []).map((tag) => (
          <a
            href={`/tags/${tagUrl(tag)}`}
            class="relative z-20 hover:opacity-80 transition-all duration-300 hover:scale-105 active:scale-95"
          >
            <Badge variant="secondary">{tag}</Badge>
          </a>
        ))}
      </div>
    </header>

    <div class="max-w-3xl mx-auto prose prose-lg dark:prose-invert">
      <slot />
    </div>

    <!-- Compartir -->
    <div class="max-w-3xl mx-auto mt-8 py-5 border-t border-gray-200/50 dark:border-gray-700/50 flex flex-col sm:flex-row items-center justify-between gap-4">
      <p class="font-medium text-foreground">¿Te ha gustado? ¡Compártelo!</p>
      <div class="flex gap-2">
        <a href={`https://www.linkedin.com/shareArticle?mini=true&url=${encodeURIComponent(Astro.url.toString())}&title=${encodeURIComponent(title)}`} target="_blank" rel="noopener noreferrer" class="inline-flex h-9 w-9 items-center justify-center rounded-md border border-input bg-background hover:bg-accent transition-colors group">
          <svg class="h-4 w-4 transition-transform group-hover:scale-110" fill="currentColor" viewBox="0 0 24 24">
            <path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433c-1.144 0-2.063-.926-2.063-2.065 0-1.138.92-2.063 2.063-2.063 1.14 0 2.064.925 2.064 2.063 0 1.139-.925 2.065-2.064 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"></path>
          </svg>
        </a>
        <button id="copy-link-btn" data-url={Astro.url.toString()} class="inline-flex h-9 w-9 items-center justify-center rounded-md border border-input bg-background hover:bg-accent transition-colors">
          <Link2 class="h-4 w-4" id="copy-icon-link" />
          <Check class="h-4 w-4 text-green-500 hidden" id="copy-icon-check" />
        </button>
      </div>
    </div>

    <!-- Navegación -->
    <nav class="max-w-3xl mx-auto mt-8 pt-8 border-t border-gray-200/50 dark:border-gray-700/50 flex justify-between gap-4">
      {prev && (
        <a href={`/blog/${prev.slug}`} class="group block flex-1 rounded-lg border border-border bg-card p-5 transition-all duration-500 ease-premium hover:shadow-premium hover:border-primary/30 hover:-translate-y-1 hover:scale-[1.05] max-w-sm">
          <span class="text-xs text-muted-foreground">Anterior</span>
          <h3 class="text-lg font-semibold group-hover:text-primary">{prev.data.title}</h3>
        </a>
      )}
      {next && (
        <a href={`/blog/${next.slug}`} class="group block flex-1 rounded-lg border border-border bg-card p-5 transition-all duration-500 ease-premium hover:shadow-premium hover:border-primary/30 hover:-translate-y-1 hover:scale-[1.05] text-right max-w-sm">
          <span class="text-xs text-muted-foreground">Siguiente</span>
          <h3 class="text-lg font-semibold group-hover:text-primary">{next.data.title}</h3>
        </a>
      )}
    </nav>
  </article>
</BaseLayout>

4. Componentes e Islas de Interactividad

El blog es casi 100% estático, lo que garantiza una puntuación de 100 en Lighthouse. Cargamos JavaScript solo mediante Islas de Interactividad:

Interactividad Reactiva: El HeaderMenu.tsx usa React para un menú móvil fluido, activado con client:load.
Scripts Nativos: Para funciones como "Copiar Enlace", usamos scripts ligeros que se reinicializan con el evento astro:page-load, asegurando compatibilidad con los View Transitions.

5. El Corazón de la Estética: Tailwind v4s

El diseño visual no es solo "cosmético"; es una parte integral de la arquitectura. Utilizamos Tailwind CSS v4 con el espacio de color OKLCH, lo que permite una gestión del Modo Oscuro basada en la percepción real de la luz:

/* src/styles/global.css */
@theme inline {
  --ease-premium: cubic-bezier(0.16, 1, 0.3, 1);
  --animate-slide-up: slide-up 0.8s var(--ease-premium) forwards;
  --shadow-premium: 0 20px 25px -5px var(--shadow-color), 0 8px 10px -6px var(--shadow-color);
}

:root {
  --background: oklch(1 0 0);
  --foreground: oklch(0.145 0 0);
  --primary: oklch(0.205 0 0);
  --shadow-color: oklch(from var(--primary) l c h / 0.1);
}

.dark {
  --background: oklch(0.145 0 0);
  --foreground: oklch(0.985 0 0);
  --primary: oklch(0.922 0 0);
  --shadow-color: oklch(from var(--primary) l c h / 0.25);
}

@layer utilities {
  .reveal {
    opacity: 0;
    animation: var(--animate-slide-up);
  }
}

6. Automatización y Build

Para que el blog sea mantenible, automatizamos las tareas repetitivas:

RSS Feed: Generado automáticamente en src/pages/rss.xml.ts incluyendo el contenido completo de los posts.
Imágenes: El componente <Image /> de Astro redimensiona y convierte las imágenes de portada a formatos modernos como WebP/AVIF en tiempo de construcción.
Sitemap: Generado automáticamente para mejorar el rastreo de Google.

Este blog esta diseñado para ser rápido, accesible y fácil de mantener. Aprovechamos lo mejor de Astro para el rendimiento y la flexibilidad de React y Tailwind v4 para una experiencia de usuario premium.

¿Qué es Docker y por qué todo desarrollador debería entenderlo?

Hugo Cayón Laso — Sun, 08 Mar 2026 00:00:00 GMT

Introducción

Si llevas tiempo desarrollando software, seguro que has vivido esta situación:

En tu máquina funciona.
En la de tu compañero no.
En producción falla.
En staging se comporta distinto.

Durante años, la configuración de entornos ha sido uno de los mayores puntos de fricción en el desarrollo. Versiones distintas, conflictos con dependencias, diferencias entre sistemas operativos, bases de datos mal configuradas…

Aquí es donde aparece Docker.

Docker no es simplemente otra herramienta del ecosistema DevOps. Es una tecnología que cambió radicalmente la forma en la que construimos, distribuimos y ejecutamos aplicaciones.

En este artículo vamos a ver qué es Docker realmente, qué problema resuelve y por qué entenderlo ya no es opcional para un desarrollador moderno.

¿Qué es Docker?

Docker es una plataforma que permite crear, empaquetar y ejecutar aplicaciones dentro de contenedores.

Un contenedor es un entorno aislado que incluye:

El código de tu aplicación
El runtime (Node, Python, PHP, etc.)
Las dependencias
Librerías del sistema
Variables de entorno
Configuración necesaria

Todo empaquetado de forma que puede ejecutarse exactamente igual en cualquier máquina que tenga Docker instalado.

La idea central es simple pero poderosa:

Si funciona dentro del contenedor, funcionará en cualquier entorno.

El problema que existía antes de Docker

Antes de Docker, el flujo típico era algo así:

Instalar el lenguaje necesario (Node, Java, Python, PHP…).
Configurar la versión correcta.
Instalar dependencias.
Instalar y configurar la base de datos.
Ajustar variables de entorno.
Resolver conflictos con otros proyectos.

Y si el proyecto cambiaba de servidor o de equipo… comenzaban los problemas.

Los errores más comunes eran:

Diferencias de versión.
Dependencias que no estaban instaladas.
Configuraciones inconsistentes.
"Funciona en mi máquina".

Docker nace precisamente para eliminar esa fricción.

¿Qué es exactamente un contenedor?

Un contenedor no es una máquina virtual.

Esta es una confusión muy común.

Máquina virtual

Virtualiza un sistema operativo completo.
Necesita un hipervisor.
Consume más recursos.
Es más pesada.

Contenedor

Comparte el kernel del sistema operativo.
Solo aísla procesos y dependencias.
Es mucho más ligero.
Arranca en segundos.

Por eso Docker revolucionó la infraestructura: permitió ejecutar aplicaciones aisladas sin el coste de virtualizar sistemas completos.

Conceptos clave de Docker

Para entender Docker necesitas dominar tres conceptos fundamentales.

1. Imagen

Una imagen es una plantilla inmutable que contiene todo lo necesario para ejecutar una aplicación.

Se construye a partir de un archivo llamado Dockerfile.

La imagen no se ejecuta directamente; sirve como base para crear contenedores.

2. Contenedor

Un contenedor es una instancia en ejecución de una imagen.

Puedes crear múltiples contenedores a partir de la misma imagen.

Es el equivalente a decir:

Imagen → Clase
Contenedor → Objeto

3. Dockerfile

Es el archivo donde defines cómo se construye tu imagen.

Ejemplo básico para una aplicación Node.js:

FROM node:20

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

EXPOSE 3000

CMD ["npm", "start"]

Con este archivo puedes generar una imagen reproducible y ejecutarla en cualquier máquina.

¿Qué es Docker Compose?

En proyectos reales rara vez tienes un solo servicio.

Normalmente necesitas:

Backend
Base de datos
Servicio de colas
Frontend

Aquí entra Docker Compose.

Docker Compose permite definir múltiples servicios en un solo archivo docker-compose.yml y levantarlos con un único comando:

docker compose up

Esto simplifica enormemente el desarrollo local y el onboarding de nuevos desarrolladores.

¿Qué problemas resuelve Docker en el día a día?

Entornos idénticos

Desarrollo, testing y producción pueden ser prácticamente iguales.

Aislamiento de dependencias

Cada proyecto puede tener su propia versión de:

Node
Python
PostgreSQL

Sin conflictos entre ellos.

Onboarding rápido

Un nuevo miembro del equipo puede levantar el proyecto en minutos.

Portabilidad

Puedes mover tu aplicación a:

Un VPS
Un servidor físico
Un proveedor cloud
Un entorno de CI/CD

Sin modificar la configuración interna.

¿Por qué todo desarrollador debería entender Docker?

Aquí es donde la parte técnica se convierte en estratégica.

Es un estándar de la industria

Hoy en día, la mayoría de empresas medianas y grandes trabajan con contenedores.

No entender Docker limita tu crecimiento profesional.

Es la base de arquitecturas modernas

Microservicios, CI/CD, despliegues automatizados, escalabilidad horizontal…

Todo esto parte de contenedores.

Si en el futuro quieres trabajar con orquestadores o infraestructura más avanzada, Docker es el primer paso.

Mejora tu mentalidad como desarrollador

Trabajar con Docker te obliga a:

Separar responsabilidades.
Pensar en servicios independientes.
Diseñar aplicaciones más limpias.
Tener entornos reproducibles.

Te profesionaliza.

Aumenta tu valor en el mercado laboral

Saber programar está bien.

Saber programar y además entender cómo se despliega y ejecuta tu aplicación en producción es otro nivel.

Muchas empresas valoran más a desarrolladores que entienden infraestructura básica que a perfiles puramente centrados en código.

¿Debe aprender Docker un desarrollador junior?

Sí, pero con enfoque correcto.

No necesitas:

Dominar Kubernetes.
Saber optimización avanzada de imágenes.
Diseñar clusters complejos.

Sí necesitas:

Entender qué es una imagen.
Crear un Dockerfile básico.
Mapear puertos.
Usar volúmenes.
Levantar servicios con Docker Compose.

Eso ya te diferencia bastante.

¿Docker es solo para backend?

No.

Se usa en:

Frontend (control de versiones de Node).
Testing automatizado.
Data engineering.
Machine learning.
DevOps.
Microservicios.
Entornos para demos.

Docker no pertenece a un stack concreto. Es una herramienta transversal.

¿Tiene sentido aprender Docker en 2026?

Absolutamente.

Mientras existan:

Entornos distintos.
Equipos distribuidos.
Aplicaciones complejas.
Despliegues automatizados.

Docker seguirá siendo relevante.

Puede que las herramientas evolucionen, pero el concepto de contenedores ya forma parte estructural del desarrollo moderno.

Entender Docker no es solo aprender una herramienta más, es dar un paso hacia una forma más profesional de desarrollar software. Si quieres crecer como desarrollador, empieza por dominar las bases que realmente utiliza la industria.

Tendencias de lenguajes de programación en 2026

Hugo Cayón Laso — Sat, 14 Feb 2026 00:00:00 GMT

Introducción

Elegir qué lenguaje de programación aprender o usar en un proyecto es una decisión estratégica que debe basarse en tendencias globales, sectores de aplicación y perspectivas de crecimiento. El TIOBE Programming Community Index es uno de los indicadores más seguidos para medir la popularidad de los lenguajes de programación a partir de búsquedas y referencias en motores de búsqueda y recursos en línea.

En este artículo analizamos el top 15 del índice TIOBE de febrero de 2026, lo que significa que no solo cubrimos los clásicos del top 10, sino también lenguajes relevantes que están ganando tracción o manteniendo nichos sólidos.

Tabla: Ranking de lenguajes de programación (TIOBE Index, febrero 2026)

Posición	Lenguaje	Popularidad (%)
1	Python	21.81%
2	C	11.05%
3	C++	8.55%
4	Java	8.12%
5	C#	6.83%
6	JavaScript	2.92%
7	Visual Basic	2.85%
8	R	2.19%
9	SQL	1.93%
10	Delphi / Object Pascal	1.88%
11	Perl	1.67%
12	Fortran	1.64%
13	PHP	1.34%
14	Rust	1.32%
15	Scratch	1.30%

Fuente: TIOBE Programming Community Index, febrero 2026

Lenguajes más usados y sus sectores

Python

Usos comunes: backend web, ciencia de datos, machine learning e inteligencia artificial, automatización, scripting. Sectores: startups tecnológicas, fintech, consultoras TI, investigación científica, educación.

Python mantiene una amplia ventaja en popularidad, liderando el ranking con más del doble de participación que el siguiente competidor. Su sintaxis clara y su ecosistema lo hacen ideal para proyectos de análisis de datos o prototipos rápidos.

C

Usos comunes: sistemas operativos, firmware, drivers, programación embebida. Sectores: electrónica, automoción, telecomunicaciones industriales, sistemas embebidos.

C ocupa una posición firme en segundo lugar gracias a su eficiencia y control sobre hardware, lo que lo hace imprescindible en entornos donde el rendimiento y la cercanía al sistema son cruciales.

C++

Usos comunes: motores de videojuegos, aplicaciones de alto rendimiento, simulación, realidad virtual. Sectores: entretenimiento digital, fintech de alta frecuencia, simulación avanzada.

C++ añade abstracción orientada a objetos sin comprometer el rendimiento, lo que lo mantiene relevante para aplicaciones exigentes en tiempo real.

Java

Usos comunes: backend empresarial, aplicaciones Android, sistemas distribuidos. Sectores: banca, seguros, telecomunicaciones, grandes corporativos.

Java sigue siendo una pieza clave en software de misión crítica para empresas grandes debido a su estabilidad, escalabilidad y portabilidad.

C#

Usos comunes: aplicaciones de escritorio y web con .NET, desarrollo de videojuegos con Unity. Sectores: entretenimiento digital, corporativo, desarrollo de software multiplataforma.

C# continúa su ascenso como lenguaje versátil para backend, aplicaciones empresariales y juegos, y fue destacado como Language of the Year por su crecimiento reciente.

JavaScript

Usos comunes: desarrollo web frontend, aplicaciones full‑stack con Node.js, SPA. Sectores: desarrollo web, ecommerce, SaaS, startups tecnológicas.

JavaScript sigue siendo el estándar para la web por su uso universal en navegadores y soporte en frameworks modernos.

Visual Basic

Usos comunes: aplicaciones empresariales de escritorio, herramientas internas. Sectores: empresas con software legacy, automatización de procesos internos.

Aunque antiguo, Visual Basic aún se mantiene en el top debido a su base instalada en aplicaciones corporativas tradicionales.

R

Usos comunes: análisis estadístico, visualización de datos, investigación académica. Sectores: ciencia de datos, biotecnología, investigación científica y análisis avanzado.

R ha recuperado relevancia gracias a su especialización en estadísticas complejas y análisis de datos intensivo.

SQL

Usos comunes: gestión y consulta de bases de datos relacionales. Sectores: prácticamente todos los sectores basados en datos (retail, banca, logística).

SQL sigue siendo indispensable para cualquier proyecto que requiera interacción con bases de datos.

Delphi / Object Pascal

Usos comunes: desarrollo de aplicaciones de escritorio y software legado. Sectores: empresas con aplicaciones históricas que requieren mantenimiento.

Este lenguaje tradicional aún aparece en el top debido a su presencia continua en sistemas corporativos y aplicaciones especializadas.

Perl

Usos comunes: scripting, administración de sistemas, procesamiento de texto. Sectores: infraestructura de TI, bioinformática, administración de servidores.

Perl ha vuelto a aparecer en posiciones medias del ranking, probablemente vinculado a su uso histórico en scripts y herramientas de automatización.

Fortran

Usos comunes: cómputo científico, simulaciones numéricas, ingeniería. Sectores: investigación científica, ingeniería aeroespacial, modelado numérico.

Aunque antiguo, Fortran sigue presente en entornos científicos de alto rendimiento que dependen de su eficiencia en cálculos numéricos.

PHP

Usos comunes: desarrollo web backend, sistemas de gestión de contenido (CMS). Sectores: agencias web, sitios de contenido dinámico, ecommerce.

A pesar de no estar en el top 10, PHP sigue siendo ampliamente utilizado en desarrollo web tradicional, especialmente en sistemas como WordPress y frameworks como Laravel.

Rust

Usos comunes: desarrollo de sistemas seguros, concurrencia, software de backend. Sectores: software de infraestructura, seguridad, servicios de alto rendimiento.

Rust ha ganado visibilidad por su enfoque en seguridad y control de memoria sin sacrificar rendimiento, aunque su porcentaje aún es moderado.

Scratch

Usos comunes: educación y enseñanza de programación básica. Sectores: educación primaria y secundaria, introducción a la programación para principiantes.

Scratch no destaca por uso profesional, pero sigue siendo popular en la educación para introducir conceptos de lógica y programación.

El ranking de 15 lenguajes de programación en 2026 muestra un equilibrio entre clasicos bien establecidos y lenguajes especializados con nichos fuertes. Lenguajes como Python, C, Java y C# dominan por su versatilidad y adopción en múltiples sectores, mientras que otros como R o Rust se destacan en áreas más específicas como ciencia de datos o sistemas seguros.

Este tipo de tendencias ayudan no solo a decidir qué aprender, sino también a entender qué tecnologías son más relevantes según el tipo de proyecto o sector en el que te mueves.

Nos vemos en el próximo post, y mientras tanto, sigue experimentando y aprendiendo con los lenguajes que más te interesen.

Mi sistema de apuntes como desarrollador

Hugo Cayón Laso — Fri, 06 Feb 2026 00:00:00 GMT

El desarrollo web no solo avanza rápido, también genera una cantidad abrumadora de información. Documentación, tutoriales, vídeos, posts técnicos… el contenido nunca se acaba. El problema no es encontrar qué aprender, sino qué hacer con todo lo que aprendes y cómo lo procesas.

Durante mucho tiempo tomé apuntes sin un criterio claro. Guardaba enlaces "por si acaso", copiaba fragmentos de documentación y escribía notas que parecían útiles en el momento, pero que rara vez volvía a leer. Cuando necesitaba consultar algo, encontrar la nota concreta era tedioso. Tenía muchas notas, pero poco conocimiento realmente consolidado.

Con el tiempo empecé a notar un patrón frustrante: volvía a investigar cosas que ya había aprendido antes, repetía errores y dudaba sobre decisiones técnicas que ya había tomado en el pasado. Mis apuntes no me estaban ayudando a pensar mejor, solo a almacenar información.

Ahí entendí que el problema no era la herramienta, sino la falta de un sistema. Necesitaba una forma de tomar apuntes que me ayudara a entender, filtrar y conectar ideas para tomar mejores decisiones como desarrollador.

Este post explica cómo funciona mi sistema de apuntes usando Obsidian, qué principios sigo y cómo lo aplico en el día a día.

1. Por qué uso Obsidian para mis apuntes

Obsidian no es una herramienta mágica, pero encaja muy bien con cómo me gusta trabajar.

Lo que más valoro es que:

Mis notas son archivos Markdown normales
No dependo de una plataforma externa
Puedo enlazar ideas fácilmente
Es rápido y no me distrae

Obsidian no impone una estructura concreta. Eso significa que el sistema lo defines tú, y eso es justo lo que buscaba.

2. Los principios de mi sistema de apuntes

Antes de hablar de carpetas o notas, hay algunas ideas clave que guían todo el sistema.

Escribo para entender, no para guardar

Si una nota es solo un copia y pega de documentación, no me sirve. Escribir es parte del proceso de comprensión.

Menos notas, mejor pensadas

Prefiero pocas notas útiles que muchas notas mediocres que nunca volveré a abrir.

Escribo para mi yo del futuro

Mis notas no están pensadas para ser formales, sino claras. Las escribo como si me explicara algo a mí mismo dentro de seis meses.

Las notas deben ayudarme a decidir

Una buena nota me ahorra tiempo en el futuro: evita que vuelva a investigar lo mismo o que dude sobre decisiones ya tomadas.

3. Cómo organizo mis apuntes en Obsidian

Mi estructura es sencilla a propósito. No quiero perder tiempo decidiendo dónde va cada cosa.

Las carpetas principales que uso son:

conceptos
herramientas
snippets
decisiones
ideas
proyectos

Las carpetas solo aportan contexto general. La verdadera organización viene de los enlaces entre notas.

4. Tipos de notas que utilizo

Notas de conceptos

Aquí explico ideas clave con mis propias palabras.

Por ejemplo:

Qué es un concepto
Cuándo tiene sentido usarlo
Cuándo no
Con qué otros conceptos se relaciona

No busco definiciones perfectas, sino comprensión real.

Notas de herramientas

Cada herramienta que uso tiene su propia nota.

Incluyen:

Para qué la uso
Cosas que suelo olvidar
Problemas comunes
Decisiones que he tomado al usarla

Estas notas evolucionan con el tiempo, igual que mi experiencia.

Snippets con contexto

No guardo código suelto sin más.

Cada snippet va acompañado de:

Qué problema resuelve
Cuándo usarlo
Por qué existe

El código sin contexto pierde valor muy rápido.

Decisiones técnicas

Este tipo de nota es de las más valiosas.

Aquí dejo constancia de decisiones como:

Por qué elegí una tecnología frente a otra
Qué alternativas descarté
Qué compromisos acepté

Meses después, estas notas evitan muchas dudas.

Ideas

Aquí guardo pensamientos sueltos, ideas de posts, mejoras o proyectos futuros.

Muchas no llegan a nada, pero algunas conectan con otras notas y acaban creciendo.

5. Cómo tomo apuntes en la práctica (mi flujo actual)

Con el tiempo me di cuenta de que escribir directamente en Obsidian no siempre era la mejor forma de pensar. Ahora mi proceso tiene dos fases claras: primero escribo a mano y después consolido en Obsidian.

Primera fase: cuaderno y papel

Cuando estoy aprendiendo algo nuevo —leyendo documentación, viendo un vídeo o resolviendo un problema— anoto a mano lo que considero importante:

Ideas clave
Dudas
Conceptos que no termino de entender
Frases que me ayudan a hacer clic"

El cuaderno es rápido, imperfecto y sin estructura. No busco orden, solo pensar y entender. Muchas de esas notas nunca llegarán a Obsidian, y está bien así.

Segunda fase: Obsidian como apunte definitivo

Más tarde, normalmente con algo de distancia, reviso esas notas y hago un filtro consciente:

¿Esto merece la pena conservarlo?
¿Es algo que quiero recordar en el futuro?
¿Me ayudará a tomar mejores decisiones?

Solo entonces creo la nota en Obsidian. Ahí sí escribo con calma, con mis propias palabras y conectando la idea con otros conceptos o notas existentes.

Obsidian no es donde pienso por primera vez, sino donde dejo el conocimiento ya procesado.

Qué ventaja tiene este enfoque

Este flujo me obliga a:

No guardar información innecesaria
Entender antes de documentar
Quedarme solo con lo realmente importante

Mis notas en Obsidian son menos, pero mucho más valiosas. No son apuntes en bruto, sino conocimiento destilado.

6. Errores que cometí al principio

Como casi todo el mundo:

Creé demasiadas carpetas
Escribí notas demasiado largas
Copié información sin procesarla
Busqué el sistema perfecto
Perdí tiempo ajustando plugins

El sistema mejoró cuando dejé de optimizarlo y empecé a usarlo de verdad.

7. Qué me aporta este sistema

Gracias a este enfoque:

Aprendo con menos fricción
Recuerdo mejor lo importante
Tomo decisiones técnicas con más claridad
Evito repetir errores
Escribir posts técnicos me resulta más natural

Mis apuntes no son un archivo muerto, son una extensión de cómo pienso.

Conclusión

Tomar apuntes no va de capturar toda la información que consumes, sino de transformarla en conocimiento propio.

Obsidian es solo la herramienta. El verdadero valor está en escribir para entender, filtrar lo importante y dejar rastro de tu proceso mental como desarrollador.

No existe un sistema universal. Este es el mío, y funciona porque evoluciona conmigo.

Si tienes tu propio sistema de apuntes o estás intentando construir uno, seguro que ya vas por buen camino.

Sigue tomando notas, experimentando y adaptando tu sistema: al final, tus apuntes no son solo información, son la forma en que piensas y creces como desarrollador.

La IA en el flujo de desarrollo: ¿herramienta imprescindible o fuente de incertidumbre?

Hugo Cayón Laso — Sat, 31 Jan 2026 00:00:00 GMT

La IA en el flujo de desarrollo: ¿herramienta imprescindible o fuente de incertidumbre?

La llegada de herramientas de inteligencia artificial al flujo de desarrollo es, posiblemente, la transformación más importante del software en los últimos años. Ya no hablamos de asistentes que completan líneas de código: hablamos de sistemas que proponen soluciones completas, generan tests, sugieren arquitectura, corrigen errores e incluso planean tareas.

Pero no todo es color de rosa: aunque el uso ha crecido de forma espectacular, la confianza en lo que producen estas herramientas está bajando entre la comunidad de desarrolladores.

En este post veremos qué significa realmente esta era de IA integrada en el desarrollo, cómo influye en el workflow, y cómo aprovecharla de forma responsable y productiva en 2026.

1. IA como asistente integral en el ciclo de vida del software

Según datos de encuestas y estudios recientes, hasta el 84 % de los desarrolladores ya usan o planean usar IA en su workflow, y más de la mitad la utiliza a diario.

Herramientas como GitHub Copilot, Claude Code o CodeWhisperer ya no se limitan a completar líneas de código:

Generan funciones completas, basadas en descripciones de alto nivel.
Ayudan a detectar y corregir errores automáticamente.
Pueden sugerir pruebas unitarias, documentación o refactorizaciones.
Algunos sistemas incluso analizan patrones de arquitectura y recomiendan estructura de proyecto.

¿Qué aporta esto a tu día a día?

Mayor productividad: tareas que antes llevaban horas pueden completarse en minutos.
Automatización de rutinas
Mejor calidad de código cuando se usa sabiamente.
Onboarding acelerado de nuevos miembros en proyectos complejos.

2. El lado oscuro: confianza en las respuestas de IA

Aunque la adopción es alta, también hay un fenómeno curioso: la confianza en lo que generan estas herramientas está cayendo. En una encuesta reciente, menos de la mitad de los desarrolladores confiaba plenamente en el código sugerido por IA, y muchos reportaron que el resultado a menudo estaba "casi bien, pero con errores sutiles".

Problemas habituales

Código "casi correcto" que compila pero falla en casos límite.
Sugerencias con bugs no evidentes al principio.
Respuestas que dependen de contexto parcial o mal interpretado.
Dependencia de prompts mal formulados.

Esto ha generado un debate interesante: ¿la IA está realmente elevando la calidad del software o solo la velocidad con la que se produce código mediocre?

Por el momento es innegable que la IA sirve como soporte y ayuda, dando solución a pequeños problemas o dudas al desarrollador. De esta manera, se agiliza el trabajo y se es más productivo.

3. La IA cambia tu rol como desarrollador

Entonces, si la IA puede escribir código por ti… ¿qué papel queda para el desarrollador?

La respuesta que ha surgido en la industria es que el rol del desarrollador está evolucionando: ya no se trata solo de escribir código manualmente, sino de diseñar, supervisar, orquestar y corregir el output que generan las IA.

Habilidades que están creciendo en importancia

Arquitectura de sistemas: diseñar cómo encajan los módulos y dependencias.
Pensamiento crítico: evaluar si la solución propuesta por IA es adecuada.
Testing exhaustivo: validar que el código funciona en todos los casos.
CI/CD y DevOps automatizado: la infraestructura se despliega sola, pero debes validarla y optimizarla.
Seguridad DevSecOps: incorporar pruebas y controles de seguridad desde la primera línea.

En otras palabras, la IA está subiendo el listón de lo que se espera de un buen desarrollador: no es solo saber un lenguaje, sino saber cómo usar la IA para planear, validar y entregar software robusto.

4. Nuevas metodologías: AI-First y Agentic Workflows

En 2026 está emergiendo un nuevo concepto: AI-First development — donde se considera que los flujos de trabajo comienzan con IA y se construyen alrededor de ella.

Esto incluye:

AI agents que no solo sugieren código, sino que ejecutan tareas completas, como crear tests, abrir PRs o analizar dependencias.
Workflow orientado a prompts en lugar de tareas manuales secuenciales.
Generación automática de documentación y diagramas arquitectónicos a medida que se actualiza el código.

Esto redefine cómo y dónde las personas y máquinas colaboran: tú ya no eres "la fuente de todo código", sino el director de la orquesta, mientras la IA asume tareas de ejecución.

5. Recomendaciones para usar IA responsablemente

Si vas a integrar IA en tu flujo de trabajo —y hoy practicamente todo equipo lo hace— esta es una guía breve para hacerlo bien:

Siempre revisa y prueba

No aceptes sugerencias sin code review y validación, porque los entornos reales exigen robustez, no velocidad pura.

Integra con testing automatizado

Haz que la IA genere pruebas unitarias, pero ejecuta tú mismo pruebas integrales, mocks y casos extremos.

Entrena tu propio modelo o afinación

Si usas IA en el stack de tu empresa, considera afinar modelos con tu propio código para mejorar precisión y seguridad.

Usa IA como colaborador, no reemplazo

La IA acelera tareas repetitivas y tediosas, pero no sustituye tu juicio profesional; úsala para potenciarte, no para delegar todo.

Como apunte final, la IA ha dejado de ser una herramienta extra y se ha convertido en una parte central del desarrollo. Está redefiniendo la productividad, la forma de escribir código y el rol del desarrollador, y aunque la confianza en su output todavía está en debate, su impacto es innegable.

Las principales tendencias tecnológicas que están marcando 2026 en desarrollo web

Hugo Cayón Laso — Fri, 23 Jan 2026 00:00:00 GMT

Las principales tendencias tecnológicas que están marcando 2026 en desarrollo web

El desarrollo web sigue evolucionando a un ritmo acelerado, y 2026 viene cargado de tendencias que están redefiniendo cómo trabajamos y construimos productos digitales. Desde la integración profunda de IA hasta nuevas formas de desplegar aplicaciones, entender estas tendencias te puede dar una ventaja competitiva como desarrollador.

1. IA integrada en el flujo de desarrollo

Este año, la inteligencia artificial deja de ser una herramienta de ayuda y se convierte en parte integral del proceso de desarrollo. Las tendencias recientes apuntan a que:

AI-driven coding ya no es futurista: herramientas como Copilot, Gemini y asistentes de IA generan código, ayudan con pruebas y automatizan tareas repetitivas.
Se deja de ver la IA como un "extra" y se adopta como una parte esencial del stack de desarrollo.

Esto implica que saber colaborar con IA, entender sus limitaciones y generar flujos de trabajo responsables es cada vez más importante.

2. Innovación tecnológica acelerada

Expertos de la industria coinciden en que 2026 será un año de innovación intensa, donde las tecnologías se adoptan y evolucionan más rápido que nunca. Esto no solo afecta frameworks o herramientas, sino cómo pensamos la arquitectura del software, la seguridad y la escalabilidad de nuestros proyectos web.

3. Edge computing y arquitecturas distribuidas

Aunque no es una "noticia de última hora", las arquitecturas edge y serverless siguen consolidándose como tendencias centrales en 2026. El concepto de mover lógica cerca del usuario por medio de servicios como Cloudflare Workers o AWS Lambda@Edge reduce latencias y mejora rendimiento a nivel global, algo crítico en aplicaciones web modernas.

Este tipo de arquitectura está transformando la forma en que pensamos el renderizado de frontend, APIs y despliegues (especialmente para aplicaciones con experiencia en tiempo real).

4. TypeScript y desarrollo tipado como estándar

La práctica de usar tipado estático con TypeScript no es solo una moda, sino una verdad consolidada. Al añadir seguridad de tipos al código JavaScript tradicional, los equipos reducen bugs, mejoran mantenibilidad y permiten flujos más predecibles en proyectos grandes.

Esto ha resultado en que muchos frameworks y herramientas modernas lo usen como opción por defecto, y que sea una competencia esperada en roles profesionales.

5. PWAs, headless CMS y API‑driven

Las Progressive Web Apps (PWAs) siguen ganando terreno como una forma eficiente de ofrecer experiencias nativas sin todas las limitaciones de las tiendas de apps. Combinadas con Headless CMS y arquitecturas API‑driven, estas tendencias permiten:

Entregas de contenido escalables y multiplataforma
Integración sencilla con SPAs o sitios estáticos
Mejor experiencia offline y performance constante

6. No‑code y low‑code democratizando el desarrollo

Aunque actualmente no reemplazan al desarrollo tradicional, las herramientas No‑code/Low‑code se están volviendo parte del stack para prototipado rápido, MVPs y soluciones internas. Estas herramientas están facilitando la creación de experiencias complejas a equipos más allá de los devs puros, lo cual tiene impacto en:

Entrega de proyectos
Colaboración entre equipos
Integración de soluciones sin código personalizado

7. El mercado de desarrolladores y cómo adaptarse

Más allá de las tendencias tecnológicas, la percepción del mercado de desarrolladores también está cambiando:

AI no reemplaza devs, pero redefine habilidades prioritarias, saber usar IA y adaptarse a flujos simulados por herramientas inteligentes es crucial.
El valor real ya no es solo conocer un lenguaje/framework, sino resolver problemas, entender arquitectura y construir productos confiables.

La conversación en comunidades técnicas indica que aunque hay ruido, la demanda de devs con capacidades amplias y fundamentos sólidos sigue fuerte — especialmente para quien puede diseñar y construir soluciones completas.

!Nos vemos en el próximo artículo!

Cloudflare adquiere al equipo de Astro: qué significa para el desarrollo web

Hugo Cayón Laso — Thu, 22 Jan 2026 00:00:00 GMT

Cloudflare adquiere al equipo de Astro: ¿un antes y un después para el desarrollo web?

En una movida estratégica que ha sorprendido a muchos en el ecosistema web, Cloudflare —la empresa líder en servicios de CDN, seguridad y edge computing— ha anunciado la adquisición del equipo detrás de Astro, uno de los frameworks más populares para construir sitios web rápidos y centrados en contenido.

Astro ha ganado tracción rápidamente entre desarrolladores por su arquitectura "content-first" y por permitir enviar cero JavaScript al cliente por defecto, lo que mejora radicalmente el rendimiento de proyectos estáticos o JAMstack.

¿Por qué es importante esta adquisición?

La compra del equipo de Astro por parte de Cloudflare no es solo un movimiento corporativo más; implica señales importantes sobre hacia dónde va la web en 2026:

Refuerzo del edge computing

Cloudflare ya ofrece funciones de computación en el edge que permiten ejecutar lógica en servidores distribuidos globalmente, cerca del usuario y con Astro en su órbita, es probable que la integración entre frameworks y edge workflows sea cada vez más profunda. Esto puede cambiar cómo pensemos en la renderización y despliegue de aplicaciones web.

Prioridad al rendimiento y experiencias optimizadas

Astro nació con un objetivo: mejorar el rendimiento real de los sitios web enviando lo mínimo posible al navegador. Esta filosofía encaja perfectamente con lo que hoy exigen Core Web Vitals y las mejores prácticas de rendimiento web en 2026.

Competencia con stacks "tradicionales"

Si frameworks como React, Vue o Angular han dominado el espacio de aplicaciones interactivas, Astro representa una visión alternativa centrada en contenido y performance. La entrada de un gigante como Cloudflare podría impulsar esta tendencia hacia mayores niveles de adopción.

Qué puedes esperar como desarrollador

Esta adquisición abre varias posibilidades para tu workflow:

Integraciones nativas con productos de Cloudflare

Es probable que en el futuro veamos mejor integración de Astro con servicios como Workers, Pages o R2, lo que facilitaría crear sitios ultra‑rápidos, escalables y con funciones avanzadas sin complicaciones.

Mejor soporte para Páginas Estáticas y Jamstack

Astro ya hacía esto bien; con Cloudflare detrás, podríamos ver mejoras en build pipelines, plugins y despliegue continuo integrado con la red global del proveedor.

Comunidad e innovación

Astro tiene una comunidad vibrante. Con recursos adicionales detrás, es posible que se acelere la creación de nuevas funciones, doc mejorada y herramientas complementarias.

Conclusión: ¿deberías usar Astro en tus próximos proyectos?

Si buscas:

Rendimiento por defecto sin sacrificar experiencia de desarrollo.
Sitios content first o estáticos ultra rápidos
Integración con edge computing moderno.

Actualmente Astro (ahora con respaldo de Cloudflare) es definitivamente una opción que vale la pena explorar en 2026.

Esta compra no solo valida la visión de Astro como framework moderno, sino que también indica un movimiento importante hacia arquitecturas más rápidas, distribuidas y optimizadas para experiencias reales del usuario.

Hasta la próxima.

Ahora tenemos RSS: qué es, cómo funciona y por qué te interesa

Hugo Cayón Laso — Fri, 16 Jan 2026 00:00:00 GMT

Este blog ahora tiene RSS

Quiero contarte una mejora importante: este blog ya dispone de un RSS feed. En este artículo te explico en detalle qué significa esto, cómo funciona y por qué puede ser una herramienta útil para mantenerte al día con el contenido sin necesidad de visitar el sitio de forma manual.

RSS es un formato estandarizado que permite distribuir actualizaciones de contenido de forma automática, de modo que aplicaciones o lectores especializados pueden detectar y organizar esas actualizaciones sin que tú tengas que visitar manualmente cada sitio que sigues.

¿Qué es un RSS?

RSS son las siglas de Really Simple Syndication, que en español se traduce como "sindicación realmente simple". Se trata de un formato estándar basado en XML que se utiliza para distribuir contenido actualizado de forma automática desde sitios web que publican con frecuencia, como blogs, medios de noticias o canales de podcast.

Un archivo RSS contiene, estructurado en formato XML, una lista de publicaciones recientes de un sitio web junto con metadatos importantes como:

El título de la publicación.
La descripción o un resumen.
Autor o fuente del contenido.
La fecha en la que se publicó.
La dirección web (URL) para acceder al contenido completo.

Este formato permite que cualquier lector de RSS pueda interpretar y mostrar estas actualizaciones de manera sistemática, independientemente de la tecnología usada para generar el contenido original.

¿Cómo funciona un RSS?

El funcionamiento de un RSS se basa en la periodicidad y la estandarización:

Cada vez que publicamos un nuevo artículo en este blog, nuestro sistema genera entradas en el feed RSS correspondientes a esa publicación.
Un lector de RSS es una herramienta que consulta periódicamente este archivo, descargándolo y analizando su contenido para detectar cambios o nuevas entradas.
Siempre que hay contenido nuevo, el lector te lo muestra organizado cronológicamente, sin que tengas que visitar el blog manualmente para comprobar si hay novedades.

Este proceso se realiza de forma automatizada y continua, de modo que tu lector siempre puede mostrarte las actualizaciones más recientes de todas las fuentes a las que estés suscrito.

¿Qué necesito para usar RSS?

Para consumir contenido a través de un RSS necesitas un lector de feeds. Un lector de RSS es un programa o servicio que descarga, organiza y muestra los contenidos de uno o varios feeds a los que te hayas suscrito. Existen distintos tipos de lectores:

Lectores basados en la web, que funcionan desde un navegador o con aplicaciones móviles.
Aplicaciones de escritorio, que funcionan localmente en tu equipo.
Extensiones de navegador, que detectan automáticamente los feeds disponibles en los sitios que visitas.

Algunos ejemplos populares de lectores de RSS incluyen Feedly, Inoreader, y Reeder.

El uso de un lector es muy sencillo: copias la URL del feed RSS del blog, la añades en tu lector y este empezará a revisar el feed de forma periódica para mostrarte las entradas nuevas.

¿Por qué seguir un RSS en 2026?

Aunque RSS es una tecnología con décadas de existencia, mantiene una serie de ventajas que la hacen relevante en contextos donde se valora la organización, la independencia y el control sobre el contenido que se consume.

Control directo de lo que lees

Con RSS tú decides exactamente qué fuentes seguir, sin depender de algoritmos que filtren o prioricen contenido en función de criterios distintos a la simple cronología o relevancia directa. Esto evita que contenidos importantes queden ocultos por decisiones automatizadas de plataformas.

Privacidad

Los lectores de RSS no requieren que proporciones datos personales ni que te registres en servicios de terceros para consumir contenidos. Simplemente consultas el feed y recibes las publicaciones, sin seguimiento de comportamiento o registros de actividad.

Ahorro de tiempo

Con un lector de RSS puedes agrupar múltiples fuentes de información en un solo lugar. En vez de revisar manualmente si hay contenido nuevo en cada sitio que sigues, tu lector te muestra automáticamente las actualizaciones de todos ellos en una sola interfaz, lo que supone una mejora considerable en eficiencia a la hora de consumir contenidos.

Organización limpia

Los lectores de RSS presentan las actualizaciones de forma ordenada y libre de distracciones, lo que facilita la lectura y revisión de novedades sin banners ni elementos ajenos al contenido.

Uso extendido en múltiples contextos

Además de blogs, los RSS feeds se utilizan para distribuir actualizaciones de noticias, contenidos de podcasting y otros tipos de información que se actualiza con frecuencia. La estandarización del formato XML permite que estos contenidos sean consumidos por una amplia variedad de herramientas de lectura automática.

Un RSS feed es un formato estándar para distribuir contenido actualizado de forma automática. Utilizar un lector de RSS te permite:

Agrupar en un solo lugar todas tus fuentes de interés.
Evitar algoritmos de plataformas que deciden por ti qué contenidos mostrar.
Mantener el control total sobre tu experiencia de lectura.
Ahorrar tiempo al concentrar las publicaciones nuevas en una sola vista.

Este blog ahora cuenta con un RSS feed. Suscribirte a él te permitirá estar siempre informado de las publicaciones nuevas sin necesidad de visitar el sitio manualmente.

¡Gracias por leer y nos vemos en el próximo artículo!

Composer en PHP: guía completa para empezar

Hugo Cayón Laso — Sun, 11 Jan 2026 00:00:00 GMT

¿Qué es Composer y para qué sirve?

Composer es el gestor de dependencias de PHP. Permite instalar, actualizar y gestionar librerías externas de forma sencilla y controlada, similar a npm en JavaScript o pip en Python.

Composer se basa en un archivo llamado composer.json, donde se definen las dependencias y la configuración del proyecto.

Esto facilita la integración de librerías de terceros, asegurando que las versiones sean compatibles y que el proyecto se mantenga organizado.

Instalación de Composer

macOS y Linux

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php composer-setup.php
php -r "unlink('composer-setup.php');"
mv composer.phar /usr/local/bin/composer

Windows

Descarga el instalador desde getcomposer.org y sigue las instrucciones del asistente.

Verificar la instalación

Para verificar que Composer se ha instalado correctamente, ejecuta:

composer --version

Deberías ver la versión de Composer instalada.

Composer version 2.x.x 2024-01-01 12:00:00

Estructura básica de un proyecto con Composer

Un proyecto típico con Composer tiene la siguiente estructura:

├── composer.json
├── composer.lock
├── vendor/
    └── autoload.php

composer.json: Define las dependencias y la configuración del proyecto.
composer.lock: Registra las versiones exactas de las dependencias instaladas.
vendor/: Carpeta donde se instalan las dependencias.
autoload.php: Archivo generado automáticamente para cargar las clases de las dependencias.

Crear un archivo composer.json

Puedes crear un archivo composer.json manualmente o utilizando el comando:

composer init

Este comando te guiará a través de una serie de preguntas para configurar tu proyecto.

Un ejemplo básico de composer.json podría ser:

{
    "name": "mi-proyecto/ejemplo",
    "description": "Un proyecto de ejemplo usando Composer",
    "require": {
        "monolog/monolog": "^2.0",
        "guzzlehttp/guzzle": "^7.0",
    },
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    },
    "minimum-stability": "stable",
}

Instalar dependencias

Para instalar las dependencias definidas en composer.json, ejecuta:

composer install

Esto creará la carpeta vendor/ y descargará las librerías necesarias.

Instalar una nueva dependencia

Para agregar una nueva dependencia a tu proyecto, usa el comando:

composer require nombre/dependencia

Actualizar dependencias

Para actualizar las dependencias a las últimas versiones permitidas por las restricciones en composer.json, usa:

composer update

Este comando actualizará las librerías y modificará el archivo composer.lock en consecuencia. Hay que tener cuidado al usarlo en proyectos en producción, ya que puede introducir cambios inesperados.

Autoloading

Una de las características más útiles de Composer es el autoloading automático. Composer genera automáticamente un archivo que puedes incluir en tu proyecto para cargar las clases de las dependencias instaladas.

Para usar el autoloading, simplemente incluye el siguiente código al inicio de tu script PHP:

require 'vendor/autoload.php';

Autoloading de las clases propias (PSR-4)

Si has configurado el autoloading en composer.json, también se cargarán tus propias clases automáticamente, puedes usar el siguiente ejemplo:

"autoload": {
    "psr-4": {
        "App\\": "src/"
    }
}

Esto te permite utilizar las clases de las librerías instaladas sin necesidad de cargarlas manualmente.

Después de modificar el composer.json para agregar nuevas rutas de autoloading, asegúrate de ejecutar:

composer dump-autoload

Estructura de carpetas recomendada:

├── src/
│   └── MiClase.php
├── composer.json
├── composer.lock
├── vendor/
    └── autoload.php

Ejemplo de uso:

// src/MiClase.php
<?php
namespace App;

class MiClase {
    public function saludar() {
        return "¡Hola desde MiClase!";
    }
}

// index.php
<?php
require 'vendor/autoload.php';

use App\MiClase;

$miClase = new MiClase();
echo $miClase->saludar(); // Salida: ¡Hola desde MiClase!

Comandos útiles de Composer

composer install: Instala las dependencias del proyecto.
composer update: Actualiza las dependencias a las últimas versiones permitidas.
composer require nombre/dependencia: Agrega una nueva dependencia al proyecto.
composer remove nombre/dependencia: Elimina una dependencia del proyecto.
composer dump-autoload: Regenera el archivo de autoloading.
composer show: Muestra las dependencias instaladas y sus versiones.
composer outdated: Muestra las dependencias que tienen actualizaciones disponibles.
composer validate: Valida el archivo composer.json para asegurarse de que esté correctamente formateado.
composer why nombre/dependencia: Muestra por qué una dependencia está instalada (qué otra dependencia la requiere).
composer global require nombre/dependencia: Instala una dependencia de forma global en el sistema.
composer global update: Actualiza las dependencias instaladas globalmente.
composer licenses: Muestra las licencias de las dependencias instaladas.
composer config: Permite ver y modificar la configuración de Composer.
composer clear-cache: Limpia la caché de Composer para liberar espacio o solucionar problemas de instalación.
composer clear-cache --all: Limpia toda la caché de Composer, incluyendo cachés de paquetes y metadatos.
composer run-script nombre-script: Ejecuta un script definido en la sección scripts del archivo composer.json.
composer help [comando]: Muestra la ayuda detallada para un comando específico de Composer.
composer diagnose: Realiza un diagnóstico del entorno de Composer para identificar posibles problemas de configuración o instalación.
composer init: Inicia un asistente para crear un nuevo archivo composer.json desde cero.
composer lock: Bloquea las versiones de las dependencias instaladas para garantizar la consistencia en diferentes entornos.
composer require --dev nombre/dependencia: Agrega una dependencia solo para el entorno de desarrollo.
composer remove --dev nombre/dependencia: Elimina una dependencia del entorno de desarrollo.
composer update --lock: Actualiza solo el archivo composer.lock sin modificar las dependencias instaladas.
composer global show: Muestra las dependencias instaladas globalmente en el sistema.
composer global outdated: Muestra las dependencias globales que tienen actualizaciones disponibles.
composer global remove nombre/dependencia: Elimina una dependencia instalada globalmente.
composer global dump-autoload: Regenera el archivo de autoloading para las dependencias instaladas globalmente.

Apuntes finales

Para acabar, Composer es una herramienta esencial para cualquier desarrollador PHP que busque gestionar dependencias de manera eficiente y profesional. Su uso adecuado mejora la organización del proyecto, facilita la integración de librerías externas y asegura la compatibilidad entre diferentes versiones de paquetes. Adoptar Composer en tus proyectos PHP es un paso fundamental hacia un desarrollo más estructurado y mantenible. ¡No dudes en explorar más sobre sus funcionalidades y sacarle el máximo provecho!

Hasta la próxima.

Git desde cero: guía básica de control de versiones para desarrolladores

Hugo Cayón Laso — Tue, 16 Dec 2025 00:00:00 GMT

¿Qué es Git y para qué sirve?

Git es un sistema de control de versiones distribuido que permite registrar cambios en el código, colaborar con otros desarrolladores y volver atrás cuando algo falla.

Git sirve para resolver problemas muy comunes en el desarrollo de software:

Guardar el historial del proyecto Permite volver a versiones anteriores si algo se rompe o deja de funcionar.
Trabajar sin miedo a equivocarte Puedes experimentar con el código sabiendo que siempre podrás deshacer los cambios.
Colaborar con otros desarrolladores Varias personas pueden trabajar en el mismo proyecto sin sobrescribir el trabajo de los demás.
Controlar quién hizo cada cambio Cada modificación queda asociada a una persona y a un momento concreto.
Organizar el desarrollo con ramas Facilita trabajar en nuevas funcionalidades, correcciones o pruebas sin afectar al código principal.
Integrarse con plataformas como GitHub o GitLab Permite compartir el código, revisar cambios y automatizar despliegues.

En resumen, Git es imprescindible en cualquier proyecto profesional.

Instalación de Git

Para instalar Git, sigue estos pasos según tu sistema operativo:

Windows:

Descarga el instalador desde git-scm.com y sigue las instrucciones.

macOS:

Usa Homebrew: brew install git o descarga el instalador desde git-scm.com.

Linux:

Usa el gestor de paquetes de tu distribución, por ejemplo en Ubuntu: sudo apt-get install git.

Configuración inicial

Git necesita saber quién eres para poder asociar los cambios a una persona concreta. Esta información se guarda en cada commit.

Configura tu nombre y correo electrónico:

git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"

Esta configuración se hace una sola vez por equipo.

Para verificar la configuración, usa:

git config --list

Creación de un repositorio Git

Para iniciar un nuevo repositorio Git en tu proyecto, navega a la carpeta del proyecto y ejecuta:

git init

Esto crea una carpeta oculta .git donde Git almacenará toda la información del repositorio.

Clonar un repositorio existente:

git clone url-del-repositorio

Estados de Git

Git tiene cuatro estados principales para los archivos:

Untracked: Archivos nuevos no rastreados por Git.
Modified: Archivos que han sido modificados pero no preparados para commit.
Staged: Archivos preparados para el próximo commit.
Committed: Cambios guardados en el historial de Git.

Añadir archivos al área de preparación (staging area)

Para preparar archivos para el próximo commit, usa:

git add nombre-del-archivo

Para añadir todos los archivos modificados:

git add .

Hacer un commit

Para guardar los cambios preparados en el historial de Git, usa:

git commit -m "Mensaje descriptivo del commit"

El mensaje debe ser claro y describir los cambios realizados.

Ver el estado del repositorio

Para ver el estado actual del repositorio y los archivos, usa:

git status

Historial de commits:

git log

Ver un historial más compacto:

git log --oneline

Trabajar con ramas

Las ramas permiten desarrollar nuevas funcionalidades o corregir errores sin afectar al código principal.

Crear una nueva rama:

git branch nombre-de-la-rama

Cambiar a una rama existente:

git checkout nombre-de-la-rama

Crear y cambiar a una nueva rama en un solo comando:

git checkout -b nombre-de-la-rama

Listar todas las ramas:

git branch

Fusionar una rama en la rama actual:

git merge nombre-de-la-rama

Eliminar una rama:

git branch -d nombre-de-la-rama

Trabajar con repositorios remotos

Para conectar tu repositorio local con un repositorio remoto (por ejemplo, en GitHub), usa:

git remote add origin url-del-repositorio

Enviar cambios al repositorio remoto:

git push origin nombre-de-la-rama

Obtener cambios del repositorio remoto:

git pull origin nombre-de-la-rama

Uso de .gitignore

El archivo .gitignore permite evitar subir archivos innecesarios como:

node_modules
archivos de entorno (.env)
builds

Ejemplo:

# build output
dist/
# generated types
.astro/

# dependencies
node_modules/

# logs
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*


# environment variables
.env
.env.production

Buenas prácticas con Git

Realiza commits frecuentes con mensajes claros, que describan los cambios realizados.
Usa ramas para desarrollar nuevas funcionalidades.
Revisa los cambios antes de hacer un commit.
Mantén tu repositorio remoto actualizado.
Evita subir archivos innecesarios (usa un archivo .gitignore).
Colabora y revisa el código de otros desarrolladores.
Aprende a resolver conflictos de fusión (merge conflicts).

Mi configuración para desarrollar aplicaciones

Hugo Cayón Laso — Sun, 07 Dec 2025 00:00:00 GMT

A lo largo de los últimos años he ido refinando mi manera de trabajar hasta llegar a un entorno de desarrollo rápido, estable y muy enfocado a la productividad. En este post quiero compartir todo lo que uso, desde el hardware hasta las herramientas, extensiones, terminales y configuraciones que me acompañan cada día al desarrollar proyectos con JavaScript, React, PHP y Laravel.

Hardware que utilizo

He probado equipos muy distintos, pero hace un mes mi pareja me regaló un MacBook Air M4, un equipo que llevaba tiempo queriendo probar. Después de varias semanas de uso intensivo, se ha convertido en mi herramienta principal.

MacBook Air M4

Mi equipo principal para la mayoría del desarrollo web.

Chip: Apple Silicon M4 (10 núcleos CPU, 8 núcleos GPU, 16GB RAM y 256GB SSD)
Ventajas: rendimiento increíble, silencioso, ligero y autonomía enorme.
Ideal para: Cualquier desarrollador web que busque un equipo potente, portátil y con buena autonomía.

¿Por qué lo uso para desarrollo?

El ecosistema UNIX muy sólido y estable, macOS facilita la instalación y gestión de herramientas de desarrollo.
Gran rendimiento con aplicaciones de desarrollo y multitarea.
Excelente duración de batería para largas sesiones de trabajo sin necesidad de estar conectado a la corriente.
Portabilidad y ligereza, ideal para trabajar desde cualquier lugar.

A pesar de haber aprendido a usar Windows y Linux en el pasado, hoy en día macOS me ofrece un entorno más fluido.

Herramientas y software principal

Visual Studio Code como editor principal

VS Code es mi editor de código, he probado otros como (Antigravity, TRAE, Cursor o Xcode), pero siempre vuelvo a VS Code es con el que me siento más cómodo.

Estas son las extensiones que considero imprescindibles:

Para JavaScript / Node / Astro / React

Astro – soporte oficial para el framework
ESLint – análisis estático del código
Prettier – formateo automático
Tailwind CSS IntelliSense – autocompletado inteligente (cuando lo uso)

Para PHP y Laravel

PHP Debug – depuración paso a paso
PHP Intelephense – análisis avanzado para PHP
DotENV – resaltado para archivos .env

Otras extensiones útiles

Error Lens – muestra errores directamente en el editor
Better Comments – comentarios más organizados
Image Preview – vista previa de imágenes en el código
Material Icon Theme y Fluent Icons – iconos más agradables y rápidos de identificar
Houston - tema oficial de Astro, mi tema favorito
Trailing Spaces – resalta espacios sobrantes

Terminal

Utilizo la terminal integrada de macOS.

Git y GitHub

Trabajo con Git para control de versiones y utilizo GitHub para alojar mis repositorios

Bases de datos y entornos backend

Como trabajo tanto con MySQL como con PHP + Laravel, tengo una pequeña colección de herramientas que utilizo siempre:

MySQL Workbench

Utilizo MySQL Workbench para gestionar mis bases de datos MySQL de manera visual.

PHP y Laravel

Son las tecnologías backend que más utilizo. Para gestionar proyectos Laravel, uso Composer y Artisan desde la terminal.

PHP 8.4
Laravel 12
Composer
Artisan CLI

Navegadores web

Utilizo principalmente Google Chrome, Firefox y Safari para probar y depurar aplicaciones.

Otras herramientas

Postman para probar APIs.
Homebrew para gestionar paquetes y software en macOS.
ChatGPT para consultar dudas y obtener ayuda rápida.

Gracias por llegar hasta aquí. Espero que este repaso a mi entorno de desarrollo te haya servido para descubrir nuevas herramientas o simplemente para inspirarte a optimizar el tuyo.

Cómo organizo mi aprendizaje como desarrollador web

Hugo Cayón Laso — Mon, 01 Dec 2025 00:00:00 GMT

El desarrollo web avanza tan rápido que es fácil sentirse desbordado. Cada semana aparece un nuevo framework, una librería revolucionaria o una forma más eficiente de resolver un problema ya resuelto. Durante mucho tiempo esto me generaba frustración: ¿cómo organizo lo que aprendo sin sentir que siempre llego tarde?

Con los años desarrollé un sistema flexible centrado en tres pilares: claridad, constancia y práctica. No es perfecto, pero me ha permitido avanzar sin ansiedad, mantener el foco y seguir disfrutando del aprendizaje.

En este post comparto mi sistema, las herramientas que uso y cómo lo aplico día a día en mi ruta como desarrollador.

1. Crear un roadmap flexible (pero con dirección)

No hablo del típico roadmap gigante que te deja paralizado. El mío tiene tres niveles claros:

Ahora (aprendizaje activo)

Lo que estoy estudiando en este momento y quiero dominar.

Ejemplo real de mis últimos meses:

Astro → para mi blog y proyectos personales
Shadcn UI → para interfaces coherentes

Estas tecnologías están en mi radar diario.

Después (aprendizaje programado)

Tecnologías o conceptos que sé que estudiaré más adelante, pero no ahora.

Ejemplos:

Next.js
Docker básico

Tener este bloque me evita caer en la tentación de "aprender todo a la vez".

Cuando pueda (aprendizaje opcional)

Cosas que me interesan, pero no impactan directamente mi trabajo inmediato.

Ejemplos:

Python
Rust
MonogDB

Son ideas interesantes… pero no urgentes.

2. Aprender haciendo: mini-proyectos intencionados

Hacer un curso sin crear nada es absorber teoría sin convertirla en experiencia. Por eso mi aprendizaje está orientado a mini-proyectos concretos que resuelven una necesidad real o cumplen un objetivo muy específico.

Ejemplos de mini-proyectos que me han ayudado:

Un blog con Astro con tags, paginación y búsqueda
Un dashboard React + Tailwind con charts dinámicos

Cada mini-proyecto dura entre 1 y 3 semanas, máximo. Esto es clave: lo termino, lo documento y paso al siguiente.

3. Documentar lo que aprendo (mi sistema completo)

Documentar no es solo escribir notas: es crear tu propia "base de conocimiento".

Notas estructuradas

Aquí guardo:

Cada proyecto lleva un README con:
- qué intentaba aprender
- qué problema resolví
- qué entendí realmente
- qué debo repasar
Explicaciones con mis propias palabras
Resúmenes de conceptos complejos
Ejemplos de código
Enlaces útiles

Con el tiempo, esta documentación se transforma en un mapa personal de lo que ya domino y lo que necesito reforzar.

4. Revisar y reajustar cada semana

Este es el hábito más importante de todo mi sistema: la revisión semanal, normalmente los fines de semana.

En mi revisión miro:

Qué aprendí esta semana
Qué conceptos siguen confusos
Qué podría practicar mejor
Si sigue teniendo sentido el roadmap
Si debo cambiar prioridades

Gracias a esto evito estancarme y mantengo un ritmo constante.

A veces la revisión me hace mover tecnologías del bloque "Ahora" al bloque "Después". Otras veces me doy cuenta de que una tecnología ya la domino más de lo que pensaba.

Esta revisión es lo que realmente me mantiene avanzando.

Conclusión

Organizar el aprendizaje no va de estudiar más, sino de estudiar mejor. Mi sistema se basa en:

Un roadmap flexible
Mini-proyectos enfocados
Documentación constante
Revisiones semanales

Gracias a esto siento que avanzo sin saturarme y disfruto mucho más del proceso.

¡Feliz aprendizaje a tod@s!

La Razón de Ser de JSON y TOON: Soluciones a Problemas de Época

Hugo Cayón Laso — Sun, 30 Nov 2025 00:00:00 GMT

Cuando observamos la historia de los formatos de datos, vemos una tendencia clara: la serialización siempre evoluciona para resolver el cuello de botella del momento. Para JSON, el cuello de botella era la complejidad de XML; para TOON, es el costo del token.

1. El Nacimiento de JSON: El Cansancio de XML (Inicios de los 2000)

La razón por la que JSON (JavaScript Object Notation) surgió a principios de la década de 2000 se resume en una palabra: XML.

El Problema a Resolver: La Carga Pesada de XML

A principios de siglo, la tecnología dominante para la transferencia de datos entre servidores y navegadores era XML (eXtensible Markup Language). El proceso de AJAX (Asynchronous JavaScript and XML) era el estándar, pero presentaba grandes desafíos:

Verbosiadad: XML es muy repetitivo. Cada dato requiere una etiqueta de apertura y otra de cierre. Esto significaba que la transferencia de datos triviales resultaba en paquetes muy grandes y lentos.
Complejidad del Parsing: Para que JavaScript pudiera leer datos de XML, era necesario manipular el DOM (Document Object Model) y recorrer la estructura de etiquetas, lo cual era lento y propenso a errores en los diferentes navegadores.

La Solución de JSON: Simplicidad Nativa

El desarrollador Douglas Crockford (junto con State Software) propuso un formato que eliminaba toda la complejidad:

Es Nativo de JavaScript: JSON es, literalmente, la notación que JavaScript ya utiliza para sus objetos. Esto significó que los navegadores podían analizarlo (parsearlo) instantáneamente, sin necesidad de librerías complejas.
Ligero y Conciso: Eliminó las etiquetas repetidas, resultando en paquetes de datos mucho más pequeños.

JSON nació para hacer que las aplicaciones web fueran más rápidas y fáciles de programar al reemplazar el pesado y complejo XML con una sintaxis simple y nativa de JavaScript.

2. El Origen de TOON: El Costo Oculto de los Tokens

Casi 25 años después, la necesidad de optimización ha vuelto, pero esta vez no es por la velocidad de la red o la complejidad del código, sino por la eficiencia en el consumo de IA.

El Problema a Resolver: El Impuesto de Tokens de JSON

Con el auge de los LLMs, el nuevo recurso más valioso y limitado es el token dentro de la ventana de contexto del modelo. JSON, a pesar de su concisión frente a XML, es increíblemente redundante en este nuevo contexto:

Consumo de Contexto: Las estructuras repetitivas de JSON (comillas, llaves, comas y, sobre todo, la repetición de claves) consumen tokens vitales que podrían usarse para transferir más información semántica.
Costo Directo: Cada token consumido tiene un costo económico asociado. Usar JSON para grandes arrays (por ejemplo, resultados de una base de datos) es pagar de más por la sintaxis.

La Solución de TOON: Eficiencia en el Lenguaje de la IA

TOON (Token-Oriented Object Notation) nació en 2025 con el propósito claro de ser el formato más eficiente para transferir datos estructurados a los LLMs, maximizando el uso de cada token:

Eliminación de Redundancia: Mediante sus Arrays Tabulares, TOON declara las claves una sola vez y luego lista solo los valores, logrando una reducción de tokens de hasta el 60%.
Limpieza Sintáctica: Minimiza el uso de comillas y llaves, limpiando el ruido del prompt y haciendo que la IA cometa menos errores al analizar la estructura.

TOON nació para optimizar los costos y el rendimiento de las aplicaciones de Inteligencia Artificial, corrigiendo la principal deficiencia de JSON en el mundo del prompting: su excesiva verbosidad.

Una Evolución Constante

Ambos formatos representan puntos clave en la historia del desarrollo:

JSON liberó al desarrollador de la complejidad de la web.
TOON busca liberar al agente de IA de las limitaciones y los costos del token.

La historia de la serialización de datos es, en última instancia, la historia de cómo los desarrolladores buscamos la máxima eficiencia con las herramientas que tenemos a nuestra disposición.

Hasta la próxima.

De la Teoría a la Práctica: Mis 4 Meses Como Junior

Hugo Cayón Laso — Sat, 15 Nov 2025 00:00:00 GMT

Hola, soy Hugo, y hace apenas unos meses di el salto al mundo profesional del desarrollo web. Lo que comenzó como emoción absoluta se transformó rápidamente en una mezcla de vértigo, orgullo, frustración, dudas y muchas ganas de aprender.

Quería compartir cómo ha sido este inicio, sin filtros y sin adornos, porque lo que te cuentan en los cursos no es lo que te encuentras cuando empiezas a trabajar de verdad.

El Primer Golpe: El Código Real No Se Parece a Tus Proyectos

Lo primero que descubrí fue que mis proyectos personales, por bonitos que fueran, no me preparaban para una base de código viva, grande y usada por miles de usuarios.

De repente me encontré con:

patrones que nunca había visto,
archivos que parecían escritos por distintas personas,
dependencias antiguas,
abstracciones que tomaban tiempo entender.

No tenía que "crear cosas nuevas": tenía que entender. Y entender es más difícil que escribir.

Aprendizaje: Saber programar no significa saber moverte en un proyecto real. La habilidad más valiosa al principio es leer código, seguir pistas y no desesperarte.

El Primer Logro: Aportar Aunque Sea Poco

Después de sentirme perdido, empezaron a llegar pequeñas victorias: corregir pequeños fallos de logica, mejorar una función, resolver un bug. Cosas aparentemente insignificantes, pero que aportaban valor real al equipo.

El día que complete mi primer desarrollo grande sentí un orgullo ridículo… y totalmente válido. Esas pequeñas victorias son las que empujan a seguir.

Aprendizaje: No subestimes las tareas simples. Te construyen criterio, confianza y te convierten en alguien útil para el equipo.

El Enemigo Invisible: El Síndrome del Impostor

Lo más difícil no fue aprender una librería o entender una arquitectura. Fue lidiar con mi cabeza.

Hubo días en los que creí que no estaba a la altura, en los que un error tonto hacía que me cuestionara si era "lo suficientemente bueno" para el trabajo. Es algo de lo que casi nadie habla, pero todos enfrentamos.

Una de las cosas que más me ayudó fue entender que pedir ayuda no es un fracaso, sino parte del proceso. Preguntar bien, explicar tu contexto, mostrar lo que intentaste… eso demuestra profesionalismo, no debilidad.

Aprendizaje: No eres menos desarrollador por no saber algo. Lo importante es tu capacidad de aprender, comunicar y avanzar.

El Gran Cambio: Ver el Proyecto Como Un Todo

En algún momento, las piezas empezaron a encajar. Dejé de ver tareas sueltas y comencé a comprender cómo las diferentes partes del proyecto se conectaban entre sí:

por qué usamos ciertas tecnologías,
qué decisiones afectan el rendimiento,
cómo un pequeño cambio puede romper una funcionalidad inesperada,
y por qué la arquitectura existe como existe.

Ya no me sentía un turista dentro del repositorio. Empecé a sentirme parte del proyecto.

Aprendizaje: El crecimiento no llega de golpe. Llega un día en el que te das cuenta de que entiendes más de lo que entendías ayer.

Consejo Final Para Otros Juniors

Si tú también estás empezando:

Ten paciencia contigo mismo. No te compares con personas que llevan años en esto. No busques ser rápido: busca ser consistente.

Aprenderás más de un pull request rechazado que de un tutorial de 10 horas. Crecerás más resolviendo un bug pequeño que rehaciendo un clon de cualquier video de YouTube. Y te harás mejor desarrollador cada vez que te atrevas a preguntar sin miedo.

Aún estoy lejos de donde quiero llegar, pero estos primeros meses fueron suficientes para convencerme de algo:

Estoy exactamente donde tengo que estar.

Nos leemos en el próximo artículo.

Bienvenido a mi blog

Hugo Cayón Laso — Thu, 13 Nov 2025 00:00:00 GMT

¿Quién soy?

Hola, soy Hugo, desarrollador web apasionado por la tecnología, el código limpio y todo lo que tenga que ver con crear cosas útiles (y a veces solo divertidas) en Internet.

¿De qué trata este blog?

He decidido abrir este espacio para compartir mi experiencia como desarrollador: los proyectos personales en los que trabajo, los retos que enfrento en el día a día y lo que voy aprendiendo en el camino. También encontrarás curiosidades del mundo tech, reflexiones sobre herramientas y lenguajes, y mi opinión sobre las tendencias que están dando forma al futuro del desarrollo web.

Código y proyectos

Hablaré de lo que construyo: herramientas, experimentos, side projects y todo lo que salga de mis ratos libres frente al editor.

La parte humana

La idea no es solo hablar de código, sino también de la parte humana detrás del teclado: la motivación, la frustración cuando algo no compila, la alegría de ver un proyecto terminado… y todo lo que hay entre medio.

¿A quién va dirigido?

Si te interesa el desarrollo web, la innovación tecnológica o simplemente te gusta leer sobre cómo otros viven este apasionante mundo digital, estás en el lugar correcto.

Hasta pronto

Gracias por pasarte por aquí. Espero que disfrutes los artículos y que juntos aprendamos algo nuevo en cada publicación.

Nos leemos pronto.

DevLog

Ciberseguridad en 2026: amenazas emergentes y qué deben saber los desarrolladores web

Ciberseguridad en 2026: amenazas emergentes y qué deben saber los desarrolladores web

1. AI y agentes autónomos redefinen la seguridad

2. Deepfakes y ataques de suplantación avanzados

3. Ransomware sigue creciendo con mayor sofisticación

4. Software supply chain y dependencias inseguras

5. Identidad como nuevo perímetro de seguridad

6. API-first architectures y nuevas vulnerabilidades

7. Integración DevSecOps como estándar

Conclusión

Menta: Por qué creé mi propio gestor de tiempo para el trabajo

El problema de los tickets y el registro de horas

Por qué decidí crear Menta

Privacidad total: Tus datos son solo tuyos

Diseñada para la velocidad y la simplicidad

Registro centralizado y rápido

Control total del tiempo

Estética "Menta" para el enfoque profundo

¿Qué puedes esperar de Menta?

Cookies, localStorage y sessionStorage: diferencias, usos y cuándo elegir cada uno

Cookies

Atributos de seguridad importantes

localStorage

El error más común con localStorage

sessionStorage

Comparativa directa

Guía de decisión rápida

Conclusión

Bun: el runtime JavaScript que quiere reemplazar a Node.js

Qué es Bun

Por qué es tan rápido

Instalación y primeros pasos

TypeScript de serie, sin configuración

Compatibilidad con Node.js

El test runner integrado

¿Deberías usarlo ahora?

El estado actual

Conclusión

Browser DevTools a fondo: la herramienta que tienes abierta y no aprovechas

Panel Elements: más allá de inspeccionar HTML

Panel Console: más potente de lo que parece

Panel Network: depurar peticiones HTTP

Panel Sources: depuración con breakpoints

Panel Performance: encontrar por qué tu app va lenta

Panel Application: storage, cookies y más

Atajos que vale la pena memorizar

Conclusión

CSS Grid vs Flexbox: cuándo usar cada uno de verdad

La pregunta que lo cambia todo

Flexbox: el maestro de una dimensión

Grid: el maestro de dos dimensiones

La confusión más común

Pueden (y deben) usarse juntos

Referencia rápida

Conclusión

Variables de entorno y secretos: cómo gestionar la configuración de tus proyectos

Qué es una variable de entorno

Por qué importa más allá de la seguridad

El archivo .env

La regla más importante: .env nunca en Git

Cómo acceder a las variables

Niveles de entorno

Secretos en producción: más allá del .env

Errores comunes

Conclusión

Un año como desarrollador web: lo que nadie te cuenta

El primer día

La sorpresa que no me esperaba: el equipo

El momento en que algo cambió

Las dudas evolucionan

Lo que le diría al Hugo de hace un año

Un año después

Mi primer experimento creando una app para iOS y macOS

¿Por qué una app de tareas?

Qué quiero aprender

Una aplicación muy simple (de momento)

Continuará...

Buscador inteligente y estética renovada: La nueva experiencia DevLog

1. Buscador Inteligente: Estética y Velocidad

El archivo `.env`

La regla más importante: `.env` nunca en Git

Secretos en producción: más allá del `.env`

3.1. El Layout "Shell" (`main.astro`)

3.2. El Layout de Listado (`BlogLayout.astro`)

3.3. El Layout de Artículo (`PostLayout.astro`)