¿Por qué ver Imagine Devops?

Lo divertido del video no está solo en la parodia musical, sino también en que aborda situaciones que muchos hemos vivido en carne propia. Quienes han trabajado con servidores, despliegues o infraestructura saben que el mundo DevOps está lleno de momentos absurdos: cosas que funcionan en local pero fallan en producción, pipelines que se rompen sin explicación, permisos que nadie recuerda haber cambiado, alertas que llegan justo cuando uno está por descansar, o servicios que deciden caerse en el peor momento posible.

Por eso este tipo de humor funciona, no hace falta explicar demasiado el chiste, porque si alguna vez has tenido que revisar logs a medianoche, reiniciar un servicio sin saber muy bien por qué volvió a funcionar, o decir la clásica frase “pero en mi máquina sí corre”, entonces entiendes perfectamente de qué se trata.

También me gusta porque recuerda que DevOps no es solo sobre herramientas, sino también sobre Docker, Kubernetes o CI/CD. Al final, DevOps también es cultura, comunicación y aprender a reducir el caos entre quienes desarrollan y quienes mantienen los sistemas vivos.

Imagine DevOps es una pequeña broma interna para gente de tecnología, pero también una forma de reírnos de nuestros propios traumas técnicos. Y eso siempre es sano.

Si trabajas en desarrollo, sistemas, infraestructura, soporte, QA o simplemente has sufrido alguna vez con un despliegue, vale la pena verlo. Probablemente te saque una sonrisa y, con suerte, te recuerde que no eres el único que ha peleado contra la producción.

Finalmente, si te gusta este tipo de videos, recuerda ver mi lista de música geek donde comparto la mejor música para geeks.

La entrada Imagine DevOps: cuando la cultura de infraestructura también necesita reírse de sí misma se publicó primero en El blog de Skatox.

¿Por qué decidí probar fish?

Durante mucho tiempo usé zsh junto con Oh My Zsh. No tengo quejas graves, al contrario, es una buena combinación y permite tener plugins, temas, autocompletado, integración con Git y muchas mejoras sobre Bash. Sin embargo, con el tiempo también puede sentirse un poco pesada o depender de demasiadas configuraciones.

Uno de los detalles que más me gustaron de fish es que muchas de esas cosas que normalmente uno instala con plugins en zsh ya vienen listas desde el inicio. El autocompletado inteligente, las sugerencias basadas en el historial y el resaltado de sintaxis funcionan prácticamente sin esfuerzo.

Eso, para mí, tiene mucho valor. No quería pasar una tarde completa ajustando plugins, revisando compatibilidades o copiando configuraciones de otras personas. Quería una shell moderna, cómoda y rápida, pero sin convertir la configuración de la terminal en otro proyecto paralelo.

Fish se siente más amigable desde el primer uso. Cuando escribes un comando, te sugiere opciones según lo que ya has ejecutado. Si escribes mal algo, el resaltado te ayuda a darte cuenta. Si navegas entre carpetas o usas comandos repetidos, la experiencia se vuelve bastante fluida.

¿Para qué usar Starship?

Después de migrar a fish, quería que la terminal también se viera bien. Pero, siendo honesto, tampoco quería perder demasiado tiempo configurando un prompt desde cero. Ya he pasado por esa etapa de probar temas, mover símbolos, cambiar colores y revisar capturas de pantalla hasta que todo se vea bonito.

Por eso decidí usar Starship. Es un prompt moderno, rápido y compatible con varias shells, como fish, zsh y bash. La idea es sencilla: instalarlo, activarlo y tener una terminal visualmente agradable sin dedicarle demasiadas horas. Staship tiene una base de datos de configuraciones y diseños ya existentes, en la que basta con seleccionar el que más te guste y luego editar detalles menores. Así ahorras mucho tiempo.

Starship muestra información útil directamente en el prompt. Por ejemplo, la rama actual de Git, el estado del repositorio, las versiones de lenguajes como Node.js, Python, Rust o Go, la duración de los comandos y otros datos según el proyecto en el que estés trabajando. Esto es especialmente útil al trabajar con varios repositorios. Puedes estar en un proyecto frontend, luego pasar a un backend, revisar algo viejo en PHP o abrir una carpeta con scripts personales. Tener esa información visible ayuda a evitar errores menores, como ejecutar un comando en la rama equivocada o no notar el entorno en el que estás trabajando.

Instalación en Arch Linux

Como uso Arch Linux, la instalación fue bastante sencilla. En mi caso lo hice directamente con pacman.

sudo pacman -S fish starship

Si todo funciona bien y queremos dejarla como shell por defecto:

chsh -s /usr/bin/fish

Después de cerrar sesión y volver a entrar, fish debería iniciarse como shell principal. Luego hay que activarlo en la configuración de fish. El archivo normalmente está en:

~/.config/fish/config.fish

Allí agregué esta línea:

starship init fish | source

Con eso ya Starship empieza a funcionar al abrir una nueva terminal.

Conclusión

Usar fish y Starship no va a convertirnos mágicamente en mejores programadores, pero sí puede hacer que la terminal sea un lugar más cómodo para trabajar. Y eso importa bastante cuando pasamos muchas horas al día escribiendo comandos, moviéndonos entre carpetas, usando Git, ejecutando pruebas o levantando servicios.

En mi caso venía de zsh con Oh My Zsh, y aunque sigue siendo una gran combinación, fish me pareció más directo. Muchas cosas que antes configuraba con plugins ahora vienen listas desde el inicio. Menos tiempo para ajustar la herramienta y más tiempo para usarla.

Starship completó la experiencia porque me permitió contar con una terminal bonita, informativa y moderna sin dedicar demasiado tiempo a personalizarla. A veces uno solo quiere que las cosas funcionen y se vean bien, sin tener que pasar horas configurando cada detalle.

La terminal sigue siendo uno de mis espacios favoritos en Linux. Personalizarla no es solo una cuestión estética, también es una forma de hacer más agradable el lugar donde trabajamos todos los días. Fish y Starship me dieron justamente eso: una terminal más cómoda, más útil y visualmente mucho mejor.

La entrada Usando fish shell y Starship para hacer la terminal más bonita y productiva se publicó primero en El blog de Skatox.

No como una moda, ni pensar en “dejar que la IA programe por mí”. Sino como una forma práctica de entender proyectos existentes, ahorrar tiempo y aportar valor sin perderme durante semanas leyendo código sin contexto. La herramienta que he usado para esto es Codex, pues es la única suscripción que tengo y quiero compartirles tres experiencias concretas en las que el «vibe coding» me ayudó de verdad.

Firefox: entrar a un proyecto gigantesco sin perder la cordura

Firefox es un proyecto gigantesco. De esos repositorios que abres y automáticamente piensas:

“Ok… esto no me lo voy a leer completo.”

Y es normal. Leer todo el código de Firefox no es realista ni necesario si lo que quieres es aportar en un área específica. Aquí la inteligencia artificial me ayudó principalmente a entender cómo está construido el proyecto hoy:

• Cómo se organizan los módulos
• Qué partes interactúan entre sí
• Dónde tenía sentido meter mano sin romper medio navegador

Algo importante: la IA no es capaz de explicarte todo el código de Firefox. Pero ese nunca fue el objetivo. La clave está en delimitar el área que te interesa. Cuando haces eso, el análisis se vuelve realmente útil.

Gracias a esto pude:

• Entender más rápido el contexto del código de las herramientas de desarrollo.
• Reducir drásticamente el tiempo de exploración
• Crear parches y mejoras con mucha más intención, sobre todo, basándose en el código existente para mantener las normativas y reglas de Mozilla.
• Además, pude dedicar menos tiempo a leer archivos irrelevantes y más a aportar mejoras reales.

KIM (KDE Image Manipulator): uso de IA para revisar código y tomar mejores decisiones

En el proyecto KIM, un manipulador de imágenes para KDE, el enfoque fue distinto. Aquí no se trataba tanto de implementar nuevas funcionalidades, sino de revisar el código que otros estaban aportando.

En este contexto, el vibe coding me sirvió para:

• Hacer code reviews más rápidos y profundos
• Analizar si una implementación encaja con la filosofía del proyecto
• Detectar posibles problemas de mantenimiento a futuro
• Planificar pruebas: qué probar, cómo hacerlo y qué escenarios validar

Muchas veces el código funciona, pero eso no significa que sea una buena decisión a largo plazo. El vibe coding ayuda a pensar mejor antes de aprobar o rechazar cambios. En mi opinión, no reemplaza la experiencia, sino que la amplifica.

Plugins de WordPress: la IA como auditoría de seguridad

En mis plugins de WordPress, todo comenzó con un reporte de vulnerabilidad. Pero en lugar de limitarme a arreglar solo ese punto específico, decidí aprovechar para hacer algo mejor: revisar todo el código.

Aquí las I.A. fue clave para:

• Analizar flujos de entrada y salida de datos
• Identificar patrones inseguros
• Encontrar problemas que no habían sido reportados
• Mejorar la seguridad del plugin de forma global

Muchas vulnerabilidades no son un bug aislado, sino hábitos que se repiten en el código. Detectarlos manualmente puede tomar mucho tiempo. Con el vibe coding, ese análisis se acelera bastante.

Conclusión: usar IA no es hacer trampa, es pensar mejor

El software libre se construye colaborando.
Pero colaborar no debería significar perder semanas entendiendo un proyecto antes de poder aportar algo útil.

El vibe coding, bien usado:

• Ahorra tiempo
• Acelera la comprensión de proyectos complejos
• Mejora la calidad de los aportes
• Ayuda a tomar mejores decisiones técnicas
• No sustituye el criterio ni la experiencia. Los potencia.

Si estás contribuyendo —o quieres empezar— a proyectos de software libre, mi recomendación es simple: utiliza las herramientas que tengas a tu alcance, entiende bien el código antes de tocarlo y aporta con intención.

Al final, no se trata de escribir más líneas de código, sino de entender mejor las que ya existen.

¡Nos vemos en los commits!

La entrada IA y software libre: cuando entender el código importa más que escribirlo se publicó primero en El blog de Skatox.

¿De qué trata este video?

Si alguna vez te has preguntado cómo sonarían tus temas favoritos con letras sacadas directamente del mundo del software libre, este video es justo eso: una parodia que toma la melodía conocida de Free Fallin’ y la convierte en una oda al software libre, sus conceptos, nombres y términos que todo hacker, sysadmin o entusiasta de GNU/Linux reconoce inmediatamente.

La parodia no solo sirve como entretenimiento, sino también como una forma ligera y musical de repasar conceptos del software libre: desde nombres de proyectos y distros hasta términos que, aunque suenan técnicos, forman parte de nuestras conversaciones diarias en la comunidad.

Por qué importa esta parodia musical geek de SUSE

Más allá de la simple diversión, ver a empresas y comunidades como SUSE producir contenido así tiene valor: es un tributo creativo a los valores del software libre —la colaboración, la cultura hacker y la idea de que el código abierto no es solo una licencia, sino una forma de vida digital compartida.

Nos recuerda que, a pesar de lo técnico que puede ser este mundo, también hay espacio para el humor, la cultura y la música geek. Y si tú, como yo, has pasado horas instalando distros, ajustando configuraciones o explicando qué significa GNU, esta parodia te va a sacar una sonrisa.

Palabras finales

Dale play al video, disfruta de la letra (seguro que reconocerás más de una frase) y celebra el espíritu del software libre en todas sus formas, incluso las más musicales.

Happy Hacking!

La entrada Free Software — Parodia musical geek de SUSE se publicó primero en El blog de Skatox.

En la sección de changelog de WordPress, el foco está clarísimo: es una actualización de seguridad y viene acompañada de mejoras que, aunque no se vean en el frontend, hacen que el plugin sea más sólido a largo plazo.

El cambio importante: fix de seguridad en filtros por shortcode

El punto más relevante de esta versión de JS Archive List es que se corrigió una deserialización insegura relacionada con los filtros de categorías del shortcode, pasando a un enfoque de parsing seguro de IDs serializados y rechazando cualquier otro valor, como, por ejemplo, un objeto.

Es decir, si tu sitio usa shortcodes y filtros de categorías, ahora el plugin es mucho más estricto con lo que acepta como entrada. Esto reduce superficies de ataque clásicas en las que “datos con forma rara” terminan ejecutando acciones que nunca debieron ejecutarse.

No es el tipo de cambio que “se nota”, pero es exactamente el tipo de cambio que vale oro.

i18n sin sorpresas: text domain alineado con el slug

Otro detalle que descubrí sin querer es que WordPress espera que el dominio del texto coincida con el slug del plugin. En esta versión se arregló mediante cambios en los archivos de PHP, JS y de traducción.

Esto suele arreglar los típicos “¿por qué esto no se traduce si tengo el .mo?” o las inconsistencias que surgen cuando WordPress intenta cargar el dominio correcto.

Readme de JS Archive List mas claro

También se actualizaron los headers del plugin/readme (requisitos, licencia y license URI), pues ahora son requeridos y durante esta década no los había incluido. Así, el plugin tiene una mejor calidad y cumple con los lineamientos de los plugins que exige WordPress.

Más fácil brindar calidad: docs y setup de PHPUnit

Este es mi lado de profesor universitario hablando: si quieres que un proyecto sea sostenible, haz que sea fácil de probar. La nueva versión 6.2.0 incluye: documentación y script instalador para configurar la suite de pruebas con WordPress y PHPUnit

Esto reduce muchísimo la fricción al añadir pruebas, correrlas en CI y detectar regresiones antes de que algo llegue a producción. Probablemente agregue más pruebas en futuras versiones de JS Archive List.

Codex me ahorró horas

Aquí va mi confesión nerd: parte de esta actualización se benefició mucho de Codex para acelerar el trabajo “invisible”: revisar cambios repetitivos, mantener la consistencia con los estándares de WordPress y, sobre todo, acelerar la incorporación de chequeos de calidad (tests, estructura, convenciones) sin convertirlo en una semana entera de trabajo.

Eso sí, no reemplaza el criterio (eso no se delega), pero sí recorta brutalmente el tiempo entre “tengo que hacerlo” y “listo, quedó fino y revisado”.

Prueba JS Archive List y dime qué tal

Si todavía no lo has probado, este plugin existe para lo mismo que yo quería hace años: un archivo colapsable, limpio y configurable, y hoy, además, con soporte moderno vía el block de Gutenberg.

Pásate por la página del plugin, instálalo, juega con las opciones y, si te sirve, deja una reseña, reporta bugs o sugiere mejoras.

Eso es lo que mantiene vivo el software libre.

La entrada JS Archive List 6.2.0: actualización de seguridad, limpieza de i18n y más pruebas automatizadas se publicó primero en El blog de Skatox.

Su programa está arrancando con buen pie —ya ha tenido invitados del rap venezolano— y esta vez quiso meterse de lleno en un tema que queríamos abordar desde hace varios meses: el skateboarding en San Cristóbal. Estado Táchira, Venezuela.

Y sí… terminamos hablando durante más de dos horas.

¿De qué hablamos en El spot de Nauef?

La conversación arrancó con cómo nos conocimos, con anécdotas de aquellos primeros años patinando, y hasta mencioné un proyecto profesional en el que, ahora que lo pienso, también coincidí con Nauef sin darnos cuenta.

Después nos fuimos full cronología:

• Las distintas generaciones de skate en San Cristóbal
• Los spots clásicos donde se patinaba
• Las competencias que marcaron los últimos 25 años
• Los personajes clave de la escena
• Las historias que solo entienden quienes vivieron esa época

Si alguna vez te has preguntado cómo nació y cómo evolucionó el skateboarding en la ciudad, este episodio de El spot de Nauef es prácticamente un minidocumental, en voz de Nauef y mía.

Tampa: una de las mejores experiencias de mi vida

Hacia el final del episodio entramos en una de mis experiencias favoritas: mi visita al Skatepark de Tampa. Conté cómo logré entrar al parque, la vibra del lugar, los skaters profesionales que vi patinar a centímetros y todo ese ambiente que solo se siente una vez en la vida.

Para quienes patinamos desde niños, estar allí es como entrar a Disneyland… pero con rampas.

¿Por qué deberías escuchar este episodio de El spot de Nauef?

Porque es una mezcla perfecta de nostalgia, historias reales, skateboarding puro, anécdotas profesionales y dos panas conversando con total naturalidad. Si te interesa el skate venezolano, si creciste en San Cristóbal o si simplemente quieres escuchar una buena charla, este episodio te va a encantar.

Así que te recomiendo dedicar unos minutos, poner los audífonos y disfrutar de esta conversación.

Además… bueno, también salgo yo 😎.

La entrada Mi aparición en El spot de Nauef: recordando la historia del skateboarding en San Cristóbal se publicó primero en El blog de Skatox.

¿Por qué lo recomiendo el video de SUSE ver a los millennials?

Porque los millennials tech (también la generación X) tuvimos estos hitos:

• Crecimos con Linkin Park
• Aprendimos tecnología rompiendo cosas
• La evolución desde sistemas monolíticos hasta contenedores, clusters y zero-trust
• Vimos nacer Linux… y también Kubernetes
• Valoramos la libertad técnica más que el hype

Además, este video aborda el desarrollo de Linux, el modelo de negocio, Kubernetes y más. Todo envuelto en la estructura musical de In The End, una canción que para muchos fue el soundtrack de la adolescencia… y ahora también cuando andamos de sysadmin 😅.

Espero que te haya gustado. Si es así, deja tu comentario y dime: ¿Te gustó el cover? ¿Te pegó la nostalgia? Porque al final, como dice la canción…
SUSE makes it all matter. 💚🐧

La entrada SUSE + Linkin Park: In The End versión Linux que todo millennial geek tenía que escuchar se publicó primero en El blog de Skatox.

Para quienes no lo conocen: JS Archive List toma los años y meses archivados en la base de datos y permite generar un widget o listado que se navega sin recargar la página. Es sencillo, útil y, como muchas herramientas viejas, tenía una parte interna que había quedado congelada en el tiempo, de hecho ese código viene del fork original en el que está basado.

Cómo se descubrió la vulnerabilidad en JS Archive List

Hace unas semanas recibí un mensaje desde la plataforma de investigadores de WordFence. Ellos tienen un programa privado donde reportan vulnerabilidades a desarrolladores antes de hacerlas públicas, y me dieron un plazo de tres semanas para liberar un fix.

El problema estaba en algo básico, la forma de generar la consulta SQL. El plugin recibía un año a través de la API o URL para filtrar los archivos, pero ese valor venía directamente de la base de datos sin sanitización y se insertaba en la query. Resultado: era posible modificar la consulta enviando un año inválido, lo que abría la puerta a inyecciones SQL.

Nada glamuroso ni nada complicado. Pero sí peligroso.

Actualizando una década de código para usar $wpdb

El fix de la vulnerabilidad en JS Archive List estaba claro: había que actualizar una porción del plugin que llevaba más de diez años igual, adaptarla a las funciones seguras de $wpdb y garantizar que todas las consultas pasaran por sus métodos de preparación. Esto no solo eliminó la inyección SQL, sino que dejó la base para que futuras mejoras del plugin también sigan buenas prácticas. Y claro: ahora JS Archive List es más seguro que nunca. Debo admitir que solo en la última semana del plazo pude sentarme a corregirlo (cosas de la vida), pero una vez entré en modo mantenimiento salió bastante fluido.

Luego tuve que entrar al sistema de WordFence y anunciar que el problema estaba corregido en la última versión. Tanto el grupo de hackers como el equipo de WordFence revisaron y confirmaron que todo está bien para cerrar la alerta en el sistema mencionado.

Reflexión final

Este fue un recordatorio amable de que mantener software libre significa estar dispuesto a revisarlo, actualizarlo y cuidarlo. Si usas JS Archive List, te recomiendo actualizar a la última versión. Y si alguna vez te toca lidiar con reportes de seguridad, tómalos como una oportunidad para pulir tu código y ayudar a hacer Internet un lugar mas seguro para todos.

¿Te ha pasado algo similar? ¿Descubriste vulnerabilidades en tu propio software?
Me encantaría leer tus experiencias en los comentarios.

La entrada Cómo corregí una vulnerabilidad en mi plugin JS Archive List tras un reporte de WordFence se publicó primero en El blog de Skatox.

La historia de Vite

Vite es un proyecto desarrollado por el mismo creador de Vue.js: Evan You. Así que podrás ver la razón de por qué y cómo nació el proyecto por parte de su mismo creador. Adicionalmente, podrás ver a otros miembros iniciales del proyecto e influencers hablando sobre cómo fue la adopción de esta tecnología.

No quiero comentar mucho porque la historia es realmente breve; además, pienso que deberías verla. Es inspiradora, concreta y muy reciente.

A continuación puedes ver el documenta sobre la historia de Vite:

Recuerda que, si quieres ver más documentales de este tipo, no dudes en ver mi sección de documentales informáticos en mi blog.

¿Ya estás usando o migrando a Vite en tus proyectos de Javascript? Comenta la razón de ello y comparte este post para llegar a más personas.

Happy Coding o, en este caso, Happy Tooling!

La entrada Documental sobre la historia de Vite se publicó primero en El blog de Skatox.

Resulta que, casi al mismo tiempo que yo hice mi fork, otra persona también creó uno. Me escribió para fusionarlos, porque no tenía sentido trabajar en paralelo cuando podíamos unir esfuerzos. Y obviamente acepté. Pero ahí no terminó la cosa.

Hace tres días apareció otro desarrollador con 20 pull requests listos: mejoras en comandos, en seguridad y en varios rincones del código que ni había considerado aún. Fue como abrir la puerta de la casa y ver que alguien ya pintó la sala, arregló la cocina y dejó el café servido.

KIM6 ahora tiene su propia organización en Github

Una de las primeras decisiones del coautor fue mover el proyecto a su propia organización:
https://github.com/KIM-6/kim6. Y me encantó. Cuando un proyecto deja de pertenecer a una sola persona y pasa a una organización, envía un mensaje claro: este código es de la comunidad y para la comunidad. Eso inspira a más gente a colaborar, revisar, proponer y mejorar.

Por mi parte, actualicé el PKGBUILD de KIM6 para Archlinux para que apunte al nuevo repo, hice un nuevo sistema de construcción que evita instalar qtpaths6 (que en Archlinux no se incluye en la lista de binarios por defecto). Archivé el antiguo repositorio, actualicé la página del proyecto para reflejar las nuevas URL, aprobé los PRs, agregué traducción al italiano, etc.

Fue un buen fin de semana dedicado al software libre.

El poder del software libre

Lo que más me sorprendió de todo este proceso fue algo muy simple pero poderoso: tres personas de diferentes países, culturas y zonas horarias, que no nos conocemos entre nosotros, trabajando en equipo para mejorar un proyecto que nos resolvía un problema común. Nada de reuniones, burocracia o workflow corporativo; simplemente código, ideas y colaboración.

Y lo mejor de todo es que las contribuciones de otros me hizo aprender muchas cosas. Que difícilmente hubiera aprendido en una conferencia, un libro o incluso usando IA. Hay algo mágico en leer código de otras personas, entender por qué hicieron las cosas de cierta manera y pensar cómo integrarlo al proyecto.

Por eso digo que la mejor forma de aprender sigue siendo la misma de siempre:
escribir código, leer código y mejorar código.

Happy Coding!

KIM6 creció más de lo que imaginé gracias a manos que nunca he estrechado en persona. Y eso es lo que hace grande al software libre: gente creando cosas juntos, sin pedir nada a cambio excepto que funcione bien para todos.

Si quieres probar KIM6 o aportar, pásate por el repo. Y si estás dudando en liberar tu propio proyecto… hazlo. Nunca sabes quién se te va a unir.

Happy coding! 💻✨

La entrada KIM6: Cómo un pequeño proyecto de software libre terminó reuniendo a desarrolladores del mundo se publicó primero en El blog de Skatox.