Rolando's Blog

Una de las cosas que me suele pasar mucho es el confundirme con el direccionamiento ip, y casi creo que es algo que nos pasa a la mayoría, el ver esos valores diferentes del típico /24 o esa mascara de subred 255.255.255.0 y empezar como a divagar en nuestra menta y tratar de aterrizar como quedaría definida una red con eso valores diferentes a los default, es por eso que decidí crear ippractice una herramienta online para practicar temas relacionados a redes, principalemente el direccionamiento ip pero también puedes hacer otras cosas interesantes, yo les invito a que lo prueben y que fortalezcan ese dominio de una configuración de red.

Echenle un vistazo en ippractice.mexclouds.com 

Llevas años en esto. Tiras código limpio, diseñas nubes privadas, te sabes los comandos de Docker de memoria y te mueves por la terminal como pez en el agua. Te sientes un hacker.

Un día decides hacer un simple deploy de tu nueva app en Rails 8 usando Kamal 2. Todo parece de rutina. Ejecutas kamal deploy, te cruzas de brazos a esperar la magia y ¡pum!... Error: target failed to become healthy within configured timeout (30s).

Ahí es cuando te pones la bata de forense:

🕵️‍♂️ Paso 1: El diagnóstico avanzado. Lees los logs y ves un connection refused. "Ah, claro", dices ajustando tus lentes invisibles. "Es el clásico choque de red. Thruster está buscando a Puma en IPv6 y Puma solo escucha en IPv4". Ajustas el TARGET_HOST: 127.0.0.1. Te sientes invencible.

🔐 Paso 2: La criptografía. Lanzas el deploy de nuevo y vuelve a fallar. Ahora es un Missing secret_key_base. Te ríes, generas tu master.key, configuras tus secretos y empujas las variables de entorno. El teclado saca humo de lo rápido que tecleas.

🔥 Paso 3: El colapso. Vuelves a entrar al servidor porque el deploy se siente lentísimo. Abres el glorioso htop esperando ver la matrix... y ves todo en rojo. Los procesos están trabados en estado "D" (Uninterruptible Sleep). El procesador está a tope. Empiezas a culpar al balanceador de carga, a la arquitectura, a la alineación de los planetas. Estás a punto de reescribir todo el stack.

Hasta que bajas la mirada de tu ego y lees la esquinita superior izquierda: Swp[ 0K/0K]

Tu flamante servidor VPS se estaba asfixiando. No era un problema complejo de red, ni un bug oscuro de Docker, ni Kamal. Era tu servidor rogando por un poco de memoria Swap porque su RAM estaba saturada y el sistema operativo estaba convulsionando tratando de escribir en el disco.

Un simple fallocate de 2GB, un ajuste de vm.swappiness=10 para que el sistema priorice la RAM física, lo guardas en el /etc/fstab... y como por arte de magia, la paz regresa. Los procesos respiran, el CPU se relaja y tu app por fin está en línea.

Moraleja: No importa cuánta experiencia tengas o qué tan pro seas levantando infraestructuras complejas; a veces la solución a todos tus problemas arquitectónicos es simplemente acordarte de prender la Swap. 😅💻

#Linux #DevOps #RubyOnRails #Kamal2 #Programacion #ElSeñorCodiguitos #SysAdmin #TechHumor

i Rails 8.0 fue el despliegue de las "Grandes Joyas" (con Kamal, Solid Queue y Solid Cache a la cabeza), la versión 8.1 se perfila como la etapa de refinamiento maestro. El mantra de esta actualización es claro: Zero-Friction Development.

Ya no se trata solo de qué puede hacer el framework, sino de qué tan rápido y seguro puedes pasar de una idea a una aplicación en producción sin depender de servicios externos costosos.

Una de las adiciones más esperadas en el ecosistema "Solid" es la capacidad de pausar y reanudar jobs. Con Active Job Continuations, si un proceso largo (como el procesamiento de un video o una migración de datos masiva) se interrumpe por un reinicio del servidor o un despliegue, Rails puede retomar la ejecución exactamente donde se quedó. Esto es fundamental para entornos que utilizan Kamal, donde los despliegues "zero-downtime" requieren una gestión impecable de los procesos en segundo plano.

Rails 8.1 introduce un sistema de Integración Continua nativo y local. A través de un nuevo DSL en config/ci.rb y el comando bin/ci, los desarrolladores pueden ejecutar linting, pruebas de seguridad (Brakeman) y suites de tests de forma idéntica a como se ejecutarían en GitHub Actions o CircleCI. La meta es reducir el ciclo de feedback: si pasa en tu laptop, pasa en producción.

El movimiento para eliminar Redis de la pila tecnológica estándar llega a su madurez.

Siguiendo la filosofía de "Omakase", Rails 8.1 facilita enormemente el envío de notificaciones push nativas para aplicaciones móviles (iOS y Android) que utilizan Turbo Native. Se integra de forma transparente con los flujos de trabajo de Active Job, permitiendo que una aplicación web se sienta realmente como una App del sistema sin configurar servicios de terceros complejos.

Con el auge de la generación de contenido mediante IA, Rails 8.1 incluye mejoras en el renderizado nativo de Markdown. Esto facilita la creación de blogs, documentación y sistemas de mensajería que procesan texto estructurado de forma segura y eficiente sin gemas externas pesadas.

Rails 8.1 no es una revolución, es una evolución táctica. Es el framework diciendo: "Ya tienes todas las piezas, ahora vamos a hacer que encajen a la perfección". Para los desarrolladores que buscan independencia de la nube (Cloud Independence) y reducir la complejidad operativa, esta versión es, sin duda, la forma más brillante de construir software en 2026.

¿Estás listo para actualizar? La transición desde 8.0 promete ser la más suave hasta la fecha.

El ecosistema de Ruby siempre se ha distinguido por una obsesión casi romántica con la felicidad del desarrollador. Desde la llegada de Ruby 3.0 con su ambiciosa meta "3x3", el lenguaje ha demostrado que puede ser rápido y escalable sin sacrificar la sintaxis legible que nos enamoró. Pero ahora, con los rumores y las discusiones sobre Ruby 4 cobrando fuerza, la pregunta es: ¿hacia dónde se dirige el lenguaje?

A diferencia de versiones anteriores que se centraban en hitos de velocidad pura, Ruby 4 parece estar perfilándose como la consolidación de la concurrencia moderna y la ergonomía del código.

Si Ruby 3 introdujo los Ractors como una propuesta experimental para el paralelismo real, Ruby 4 apunta a ser el escenario donde esta tecnología finalmente alcance la madurez productiva. La meta es clara: permitir que nuestras aplicaciones aprovehen al máximo los procesadores multinúcleo de forma nativa y segura, eliminando las limitaciones históricas del Global VM Lock.

No es un secreto que la comunidad ha tenido una relación agridulce con RBS y TypeProf. Se espera que Ruby 4 mejore drásticamente la integración de los tipos estáticos, haciendo que el análisis sea más intuitivo y menos verboso. No se trata de convertir a Ruby en Java, sino de ofrecer una red de seguridad que detecte errores antes de que lleguen a producción.

El compilador YJIT (desarrollado inicialmente por Shopify) ha cambiado las reglas del juego. En Ruby 4, podríamos ver una integración aún más profunda de técnicas de compilación en tiempo real que reduzcan el consumo de memoria, uno de los puntos débiles tradicionales del lenguaje frente a alternativas como Go o Rust.

Muchos predicen el fin de Ruby cada año, pero la realidad es que el lenguaje sigue siendo el estándar de oro para la velocidad de desarrollo. Con la llegada de Ruby 4, el enfoque no es solo "hacerlo funcionar", sino "hacerlo escalar de forma sostenible".

¿Qué característica te gustaría ver en Ruby 4? ¿Eres del equipo que pide tipos obligatorios o prefieres mantener el tipado dinámico a toda costa? ¡Déjanos tu comentario abajo!