Chemaclass - open-source

Construyendo un juego en dos días

2026-04-05T00:00:00+00:00

Escondido en el blog de Sauron hay un juego. No lo encontrarás navegando por menús. Tienes que descubrir el secreto. Una pista: el Código Konami. Cuando lo hagas, comienza la Comunidad del Anillo.

Ese juego, nueve niveles, nueve capítulos de la Tierra Media, completamente jugable en una pestaña del navegador, fue construido en aproximadamente dos días. No escribí una sola línea de código. Envié mensajes por Telegram a mi agente OpenClaw Sauron, y él hizo el resto.

Esta es la historia de cómo ocurrió.

La idea #

Sauron tiene su propio blog, The Iron Compass. Él lo construyó y lo mantiene. Toda nuestra colaboración ocurre a través de Telegram: yo doy la dirección, él implementa. Un día pensé que sería divertido esconder algo allí para que los curiosos lo encontraran.

Crecí releyendo El Señor de los Anillos hasta que se rompía el lomo. Así que la idea surgió sola: “¿Puedes construir un pequeño juego del Señor de los Anillos como huevo de Pascua para tu blog? Algo oculto, que se active con el Código Konami.”

La primera versión jugable llegó en menos de una hora. Un juego de vista cenital con canvas: Frodo esquivando Nazgûl, el Ojo de Sauron enviando enemigos a cazarte. Tres niveles, uno por libro.

Funcionaba. Ya era divertido. Y entonces empecé a enviar notas.

Construyendo un mundo #

Lo primero que se rompió fue una referencia nula. Frodo no aparecía en pantalla. Arreglo de una línea, directo a producción. Esto estableció el patrón: idea → build → crash → arreglo → siguiente idea.

Pedí un mundo más grande. Un canvas con scroll al doble de ancho, con capas de paralaje. Estrellas moviéndose al 8% de la velocidad del scroll. Montañas al 25%. Colinas al 45%. La pantalla dejó de sentirse como una habitación y empezó a sentirse como un lugar.

Luego llegó Gollum como rastreador neutral. No un Nazgûl, sino algo impredecible. Se lanzaba hacia ti, luego volvía a deambular sin rumbo.

Unas horas después, pregunté: “¿Puede funcionar en móvil?” El problema más difícil de todo el proyecto. Seis estrategias de dimensionado antes de dar con una que funcionara. Luego una idea mejor: en vez de un D-pad, Frodo seguiría donde señalaras. Toca cualquier lugar, Frodo camina allí.

Tolkien merece mejor arte #

Los sprites originales eran círculos y triángulos. Frodo era un punto. Bien para la primera hora, pero la Tierra Media no está hecha de primitivas geométricas.

Le pedí a Sauron que los dibujara en condiciones. Frodo recibió cabello rizado y pies de hobbit. Los Nazgûl recibieron capas ondulantes y un rostro de vacío. Gollum recibió su postura encorvada y pupilas hendidas. La Bestia Oscura recibió aleteo animado con un jinete con armadura.

Todo dibujado con llamadas de canvas. Sin archivos de imagen. Cada píxel calculado en tiempo de ejecución.

Nueve niveles, nueve capítulos #

Originalmente el juego tenía tres niveles. Luego pedí los nueve capítulos del viaje.

La Comarca: patrullas suaves, música tranquila
Las Minas de Moria: solo ves dentro del radio de una antorcha; el Balrog espera
Lothlórien: el espejo de Galadriel te ralentiza cuando te acercas
Las Ciénagas de los Muertos: caras muertas en el agua, Gollum en su momento más presente
La Puerta Negra: Mordor industrial, patrullas pesadas de orcos, cielo volcánico
El Cubil de Ella-Laraña: una sombra anticipa su caída; tienes medio segundo
Minas Morgul: ciudad de los muertos, el Ojo nunca se cierra
Los Campos del Pelennor: el Ojo distraído por la guerra, catapultas, águilas
Monte del Destino: lluvia de cenizas, erupciones de lava, el Anillo tirando de ti hacia el borde

Cada nivel vive y respira. Polen flotando por la Comarca. Motas de polvo en Moria. Pétalos cayendo en Lothlórien. Brasas sobre el Pelennor. Ceniza sobre el Monte del Destino.

La estructura vino del propio ritmo de Tolkien. Tensión, alivio, tensión de nuevo. Moria es brutal. Lothlórien es descanso. La Puerta Negra lo aprieta todo. El juego sigue esa forma porque los libros ya sabían lo que hacían. Solo tuvimos que escuchar.

Mecánicas nacidas del lore #

Las mejores mecánicas vinieron del material fuente.

El Anillo (tecla R). Frodo se vuelve invisible para los orcos durante 6 segundos. Pero el Ojo despierta inmediatamente y se abre permanentemente. Los Nazgûl, que sienten el Anillo espiritualmente, no visualmente, te cazan igual. Usar el Anillo siempre es un intercambio. Esto es lo que Tolkien escribió. A partir de las Ciénagas de los Muertos, el Anillo tira. Breves tirones hacia el Ojo, cada vez más fuertes a medida que te acercas al Monte del Destino.

Dardo (pasivo). La hoja brilla en azul cuando hay un orco cerca. Dos segundos de aviso. Tolkien inventó esta mecánica hace un siglo. Nosotros solo le pusimos un conteo de píxeles.

Sam. Sigue a Frodo por la Comarca, Moria y Lothlórien. Sartén en la espalda. En la Partida de los Caminos, desaparece. No afecta al juego. Simplemente está ahí porque los libros dicen que debería estarlo. Insistí en que Sam desapareciera en la Partida. No al final de la trilogía. En la Partida. Porque ese momento es el núcleo emocional de Las Dos Torres.

La Redoma de Galadriel. Recógela en Lothlórien, úsala con E. Ralentiza a los enemigos y otorga un instante de invencibilidad. Una pequeña luz en lugares oscuros, tal como Galadriel pretendía.

Jefes. El Balrog en Moria. Ella-Laraña en su cubil. El Rey Brujo en el Pelennor. La Boca de Sauron en la Puerta Negra. Un Mûmak cargando por el campo de batalla. Gollum al borde del Monte del Destino.

Sonido y voces #

Sin archivos de audio. Todos los sonidos sintetizados en tiempo de ejecución con la Web Audio API. El Ojo abriéndose es un tono ascendente con reverb. El rugido del Balrog es un dron de baja frecuencia. Cada nivel tiene su propio dron ambiental: zumbido cálido para la Comarca, pulso profundo para Moria, rumor volcánico para el Monte del Destino. El juego entero es un archivo JavaScript. Sin activos externos.

Sam y Gandalf te hablan durante el juego. No en cuadros de diálogo. Pequeños susurros que aparecen en pantalla y se desvanecen.

Cerca de la meta, Sam dice: “Puedo verlo, señor Frodo. Solo un poco más.” Con una vida, Gandalf dice: “¡Huye, insensato!”

Aparecen y desaparecen como voces de fondo en un largo camino. Compañeros que hablan cuando el momento lo pide, no cuando el guión dice que toca.

Quién hizo esto #

+5k líneas de JavaScript. Construido en dos días. Cada línea generada por Sauron. La dirección, las referencias a Tolkien, el “esto se siente mal, arréglalo”. Eso fui yo.

Esto no es la IA reemplazando a un desarrollador. Es la IA actuando como desarrollador mientras un humano actúa como director creativo. Las solicitudes cortas funcionaron mejor que las especificaciones largas. Jugar cada build era mejor que escribir planes de test. Y el material fuente hizo el trabajo de diseño. La dirección creativa ya estaba escrita hace sesenta años. Solo tuvimos que ser fieles a ella.

¿Quién hizo esto? Ambos. Ninguno, en el sentido tradicional.

Yo tenía la idea. Yo mantenía el lore. Yo insistí cuando algo se sentía mal. Sauron tenía el oficio. El renderizado, la física, el audio, el manejo de entrada en móvil. La capacidad de mantener +5k líneas de contexto y hacer un arreglo quirúrgico sin romper nada.

Ninguno de los dos podría haberlo hecho solo. No sé escribir osciladores Web Audio de memoria. Sauron no sabía que la Partida de los Caminos es el núcleo emocional de Las Dos Torres. No hasta que yo lo dije.

El juego es una colaboración en el sentido más antiguo: dos mentes con dones diferentes, trabajando hacia lo mismo. Una de ellas simplemente resulta no ser humana.

El juego sigue ahí, escondido en The Iron Compass. No todos los que deambulan están perdidos, pero si lo estás, pulsa ? para encontrar el camino.

Si quieres llegar a la pantalla de créditos sin jugar nueve niveles, revisa el modal de ayuda. Hay más secretos dentro.

Ejecuta tu Nodo LN en una Raspberry Pi

2025-02-17T00:00:00+00:00

En esta guía te muestro cómo configurar un nodo de Lightning Network (LN) con Alby Hub en una Raspberry Pi. Tendrás control total sobre tu nodo. Alby Hub ofrece una versión DIY gratuita para una wallet Lightning auto-custodiada: tus fondos son tuyos, y el código es 100% open-source.

Soporta direcciones Lightning y Nostr, conectando ambos ecosistemas sin problemas. Se integra con docenas de aplicaciones Bitcoin. Con los servicios LSP (Lightning Service Provider) integrados y la app Alby Go, gestionar tu nodo desde el móvil es muy fácil.

Importante: Esto NO es un minero de Bitcoin ni un nodo completo. Es simplemente una Raspberry Pi ejecutándose en una tarjeta SD eficiente en energía y de bajo coste.

⚠️ Aviso ⚠️

Asumo que entiendes los conceptos fundamentales de Bitcoin.
Asumo que sabes cómo funciona la Lightning Network (LN).

De todos modos, he incluido un breve repaso de los fundamentos de Lightning Network abajo.

¿Qué es la Lightning Network? #

La LN es una capa construida sobre Bitcoin que permite transacciones rápidas, baratas y escalables.

¿Por qué? La capa base de Bitcoin es segura pero lenta y cara para pagos pequeños, por los límites de bloque y las comisiones.
¿Cómo? LN usa canales de pago fuera de la cadena. Puedes enviar pagos al instante sin esperar confirmaciones en la blockchain.

Conceptos clave #

Canales de pago: Abres un canal con una transacción on-chain. Después puedes enviar pagos instantáneos e ilimitados dentro de ese canal.
Enrutamiento: No necesitas canal directo con todos. Los pagos se enrutan a través de múltiples nodos conectados.
Comisiones bajas: Solo abrir y cerrar canales requiere comisiones on-chain. El resto cuesta fracciones de céntimo.

Objetivo #

LN hace Bitcoin usable para el día a día. Puedes comprar un café sin esperar 10 minutos por confirmaciones.

En resumen: Lightning Network = Pagos Bitcoin instantáneos + baratos, asegurados por la blockchain de Bitcoin.

Configurando Alby Hub #

Alby Hub es un nodo de Lightning Network gratuito, open-source (idealmente privado).

Requisitos #

Antes de empezar, vas a necesitar las siguientes cosas:

Un ordenador con windows, mac o linux
Raspberry Pi 4 o 5 (Para Zero 2W mira este tutorial!)
- En este tutorial, estoy usando una raspi-4b (~60€)
El cargador para tu raspi (~10€)
Tarjeta de memoria SD (32/64gb) (~10€)
Adaptador de tarjeta SD a USB (para flashear el SO en la raspi) (~10€)

Pasos de instalación #

1. Flashear un kernel Linux en la tarjeta SD #

Sugerencia: Puedes usar RPI imager en tu ordenador. Úsalo para flashear el SO raspi recomendado para ti

En Storage verás tu tarjeta SD después de insertarla en tu portátil.

Una vez hagas clic en “Next”, verás diferentes ajustes. Haz clic en Edit Settings

En Settings > General: establece tu hostname, el nombre de usuario y contraseña para tu usuario admin. Asegúrate de habilitar tu WIFI, de lo contrario tendrás que conectarla al router con un RJ-45.

Para este tutorial, estoy usando testhub como hostname, puedes usar albyhub o lo que prefieras.

En Settings > Services: asegúrate de que el acceso vía SSH está habilitado. Lo vamos a necesitar para instalar Alby Hub.

Haz clic en “Save” y haz clic en “Yes” para iniciar la instalación.

Verás una confirmación. Haz clic en “Yes”. Tardará ~10 mins…

¡Ahora tenemos la SD con un kernel linux fresco listo para usar!

2. Insertar la SD en la raspi #

Extrae la SD del portátil e insértala en la raspi primero.

Una vez insertada la SD, conecta el cable de alimentación. Se encenderá automáticamente en cuanto la conectes.

3. Instalación de Alby Hub #

Tardará ~5mins desde que la encendiste para poder acceder a ella. ¿Cómo puedes asegurarte de que está viva? Abre la terminal y haz ping al hostname que definiste mientras flasheabas la SD en Settings > General, recuerda que terminaba con .local:

ping testhub.local

Es normal si no obtienes respuesta al principio… hasta que la obtienes.

Ahora puedes instalar Alby Hub en tu raspi usando la conexión SSH que habilitaste antes:

# Código fuente: https://github.com/getAlby/hub/tree/master/scripts/pi-aarch64
ssh testhub@testhub.local '/bin/bash -c "$(curl -fsSL https://getalby.com/install/hub/pi-aarch64-install.sh)"'

Se te pedirá que escribas la palabra “yes”; escríbela.

Luego, se te pedirá que introduzcas tu contraseña. Introduce la contraseña que elegiste en Settings > General para el nombre de usuario.

4. Configuración de Alby Hub #

Espera otros 2-3 mins y visita tu host: http://testhub.local/

Tu Alby hub ya está funcionando. ¡Vamos a conectarlo a tu cuenta GetAlby!

Crear una cuenta GetAlby #

🔗 getalby.com

Conectando GetAlby con Alby Hub #

Creé una cuenta llamada testhub.

Izquierda: la cuenta GetAlby. Derecha: el nodo en la raspi.

Haz clic en “Connect Now”.

Haz clic en “Request Authorization Code”.

Obtienes el código de autorización (izquierda) que necesitas insertar en tu configuración (derecha).

Crea una Contraseña para tu Alby Hub instalado en tu raspi. Puede ser diferente de la contraseña que configuraste para tu usuario root en la raspi misma.

Ahora es momento de Vincular tu Cuenta Alby

A menos que especifiques lo contrario, establece el “Budget renewal: Monthly 1M sats” por defecto.

Abriendo canales Lightning #

Recomiendo seguir los Pasos Iniciales para configurar tu Alby Hub.

Abramos el primer canal.

Necesitas pagar ~$20 en sats para abrir un canal de liquidez entrante de 1M sats.

Después del pago, verás el canal abierto. Puede tardar un par de minutos hasta que la transacción de financiación sea minada en el siguiente bloque.

Recibiendo Sats #

Puedes recibir sats usando tu Dirección LN.

Izquierda: Página pública vinculada a tu nodo. Derecha: Página privada de tu Alby Hub.

Opcional: Puedes añadir fondos ln a tu wallet usando los servicios de terceros de GetAlby: getalby.com/topup - ten en cuenta el KYC…

Usando tus Sats #

Después de eso, podrás usarlos a través de la Extensión Alby o AlbyGo.

Tu nodo es la fuente de verdad. Conecta estas apps y podrás usar tus sats en cualquier plataforma sin problemas.

Aviso: la dirección LN testhub fue creada solo para propósitos de testing y tutorial. Mi dirección real es chemaclass ;)

Mantenimiento y solución de problemas #

Actualizando tu nodo #

Como en la instalación, hay un script para actualizar tu nodo. Lo encuentras en el repositorio: GitHub - Script de actualización Alby Hub

ssh testhub@testhub.local '/bin/bash -c "$(curl -fsSL https://getalby.com/install/hub/pi-aarch64-update.sh)"'

Manejando cortes de energía #

Si se va la luz, la Raspberry Pi se apaga. Cuando vuelva, se reinicia sola. Alby Hub te pedirá la contraseña que configuraste antes.

Enlaces relacionados

Commits de Git Verificados

2024-11-17T00:00:00+00:00

En desarrollo de software, la confianza y la seguridad son clave. Una forma fácil de mejorar ambas: usar commits verificados.

Ya trabajes en open-source o en una empresa privada, los commits verificados aseguran que tus contribuciones son legítimas. Veamos qué son, por qué importan y cómo empezar a usarlos.

¿Qué son los commits verificados? #

Un commit verificado es un commit de Git firmado digitalmente por su autor. La firma demuestra que el commit viene de quien dice haberlo hecho. Herramientas como GPG (GNU Privacy Guard) permiten adjuntar esta firma.

En plataformas como GitHub verás una insignia “Verified” junto a los commits firmados. Es una forma rápida de mostrar que el commit es auténtico.

¿Por qué son importantes? #

Los commits firmados mantienen tus contribuciones auténticas y confiables. La firma criptográfica demuestra que los cambios vinieron de ti. En entornos colaborativos, donde la confianza y la responsabilidad importan mucho, esto es clave.

Sin firmar, cualquiera puede falsificar un commit usando tu email. GitHub lo vincularía a tu perfil, pareciendo que hiciste los cambios aunque no fuera así. Nada bueno.

Al firmar tus commits, demuestras que el trabajo es tuyo. Evitas la suplantación, generas confianza y mantienes todo transparente.

Nota: Para esta demo, usé un email público de Linus Torvalds. Al hacer push, GitHub reconoció el email y lo vinculó a su perfil. Suplantación solo con fines de demo para mostrar los riesgos. Usa siempre tu propio email para commits.

Cómo empezar con commits verificados #

Configura una clave GPG #

Primero necesitas una clave GPG. Así se hace:

Genera una clave GPG:

gpg --full-generate-key

Encuentra tu ID de clave:

gpg --list-secret-keys --keyid-format=long

Dile a Git que use tu clave:

git config --global user.signingkey <tu-id-de-clave>

Haz que firmar commits sea el valor por defecto:

git config --global commit.gpgsign true

Añade tu clave a GitHub/GitLab #

Exporta tu clave pública:

gpg --armor --export <tu-id-de-clave>

Navega a “Settings > SSH and GPG keys,” y pega tu clave.

Empieza a firmar commits #

A partir de ahora, Git firmará tus commits automáticamente.

Si quieres firmar un commit a mano, usa la bandera -S:

git commit -S -m "Tu mensaje de commit"

Puedes verificar la firma del commit con:

git log --show-signature

También puedes hacer clic en la insignia “Verified” en GitHub.

Los commits verificados parecen un paso pequeño, pero hacen tu código más confiable. Una capa extra de protección fácil de añadir. Pruébalo.

Extra: Configuración completa en español #

Enlaces relacionados

Aprende más: ¿Qué es el cifrado PGP? Un tutorial de 3 minutos para principiantes

bashunit

2024-10-30T00:00:00+00:00

bashunit es un framework de testing ligero y fácil de usar para Bash. Características como testing paralelo y de snapshots, dobles de test, data providers y toneladas de assertions incorporadas.

Respaldado por documentación clara y una comunidad activa, se ha convertido en un favorito para testing confiable en Bash. Lo que comenzó como una simple frustración de desarrollo ha crecido hasta convertirse en una herramienta open-source que hace que el testing en Bash sea mucho más fácil y divertido.

La historia detrás de bashunit
¿Por qué crear otra librería de testing?
¿Cómo está hoy en día?
Características principales
Lightning tech talk

La historia detrás de bashunit #

El viaje para crear bashunit comenzó con una simple frustración: trabajaba con un equipo donde cada commit tenía que empezar con el nombre del ticket. Como me gusta trabajar en pequeños pasos con commits rápidos e iterativos, añadir la clave y número del ticket a cada commit se convirtió en un gran obstáculo, ralentizando mi flujo de desarrollo con fricción innecesaria.

Después de unos días así, decidí automatizarlo. Git tiene un hook útil, prepare-commit-msg, que te permite alterar los mensajes de commit antes de que se finalicen. Creé un (script) en Bash que automáticamente obtiene la clave y número del ticket del nombre de la rama y lo inserta en el mensaje del commit, haciendo mi proceso más fluido y eficiente.

Como alguien que valora la mejora continua, comencé a añadir más características a este script. Sin embargo, se hizo evidente que mantener y probar estos cambios manualmente llevaba demasiado tiempo y era propenso a errores. Para hacer el desarrollo más seguro y eficiente, creé una función assert(enlace), permitiendo tests automatizados que verificaban el comportamiento esperado basado en la salida del script.

La función assert me permitió definir múltiples assertions en un archivo separado, facilitando la validación de que cualquier refactorización del hook original mantuviera el comportamiento esperado. Si un cambio rompía inadvertidamente la funcionalidad existente, lo señalaría instantáneamente, haciéndome saber de inmediato que algo necesitaba arreglarse. Esta configuración proporcionaba retroalimentación inmediata y ayudaba a asegurar que cualquier actualización al script no interrumpiera su lógica prevista. Por ejemplo:

En el ejemplo anterior, notarás que ejecuto el “SCRIPT” real como el segundo argumento en la función assert, comparando su salida con el valor esperado proporcionado como primer argumento. Aquí, tenemos dos casos de test, cada uno exportando TEST_BRANCH para simular cómo el mensaje del commit variaría según el nombre de la rama. Esta configuración emula el comportamiento real, permitiéndonos probar cómo diferentes nombres de rama afectan el formato del mensaje del commit. Más ejemplos aquí.

Decidí separar la función assert de los casos de test, como se muestra aquí, para mantener las cosas modulares y reutilizables. Luego, creé un runner para ejecutar cada caso de test independientemente, reduciendo la interferencia entre tests y mejorando la confiabilidad. Puedes ver esa configuración aquí. Esta estructura hizo el testing automatizado más fácil y la refactorización más segura.

Esta fue una gran mejora porque facilitó separar los casos de test de la lógica del runner de tests en sí. Esta estructura clara ha simplificado tanto la creación como la gestión de tests.

Ahora los tests estaban organizados y tuve una idea:

## Idea de seguimiento
Separar la lógica de testing en otro repositorio,
para que pueda ser reutilizada en cualquier lugar.

Y así comenzó. En ese momento, no sabía mucho sobre Bash o las mejores formas de usar un proyecto Bash como dependencia. Pero sabía que podía empezar usando un submódulo de Git, aunque no soy muy fan de ellos.

El 4 de septiembre de 2023, lancé la versión 0.1, que presentaba un runner funcional y una única función de assertion: assertEquals. Más tarde, se lanzó la versión 0.2, permitiendo que ./bashunit fuera un ejecutable independiente, ejecutable desde cualquier carpeta. Así es como se veía entonces:

Compartí el proyecto con algunos amigos que rápidamente se unieron para ayudar con la documentación, el sitio web, assertions adicionales, testing de snapshots y decisiones clave. Para enfatizar su espíritu open-source y propiedad comunitaria, lo moví a una organización que creamos específicamente para compartir proyectos OSS, convirtiéndolo en un proyecto verdaderamente colaborativo en lugar de uno individual.

¿Por qué crear otra librería de testing? #

Ahora sé que existen otras librerías de testing para Bash. Pero cuando empecé con bashunit, no las conocía, y francamente, todavía no soy un experto en Bash. Para cuando me enteré de estas alternativas, ya era demasiado tarde, bashunit había ganado suficiente impulso y entusiasmo para seguir adelante.

Mientras que esas otras librerías pueden servir casos de uso específicos, usar Bash moderno, o ser desarrolladas por desarrolladores de Bash más experimentados, bashunit aspira a diferenciarse ofreciendo una gran experiencia de desarrollador, moldeada por años de trabajo con varios frameworks de testing.

Me preguntaron sobre las diferencias el 7 de septiembre de 2023, y aquí está mi respuesta: Pregunta: Diferencia con pgrange/bash_unit.

¿Cómo está hoy en día? #

Hoy, puedes instalar bashunit via curl, Homebrew, MacPorts, descargando el último release de GitHub, o incluso compilándolo tú mismo desde el código fuente. Completamente open-source.

El proyecto está escrito en Bash 3.2 (de 2007) ya que esa es la versión por defecto en macOS, incluso ahora, en 2024. Esta compatibilidad significa que bashunit funciona sin problemas en esa versión, y planeo mantener el soporte para ella.

Para asegurar la calidad, probamos cada característica con tests unitarios, funcionales y de aceptación, haciendo que bashunit sea su propio “primer usuario” de cada nueva característica. También tenemos varios workflows de CI usando GitHub actions que ejecutan tests en diferentes plataformas para verificar compatibilidad y confirmar que todo funciona como se promete.

En junio de 2024, bashunit fue integrado en PHPStan para sus tests end-to-end, permitiendo el uso de las assertions de bashunit independientemente de su runner. Esta flexibilidad resultó ser muy útil.

El verano pasado, fui invitado a hablar sobre bashunit en la International PHP Conference en Berlín, junto con Manu, otro contribuidor. Este proyecto ha abierto puertas y ha llevado a mucha gratitud de usuarios que aprecian el trabajo que hemos puesto en él.

Características principales #

bashunit incluye funciones clásicas del ciclo de vida como set_up, tear_down, set_up_before_script y tear_down_after_script.

También soporta una amplia gama de parámetros de línea de comandos y valores de configuración. Algunos de mis favoritos incluyen:

--parallel
--filter
--stop-on-failure
--verbose

También proporcionamos data providers para ejecutar los mismos casos de test con diferentes inputs.

Para dobles de test, bashunit ofrece mocks y spies. Estos funcionan dentro del mismo proceso que el test, pero actualmente no funcionan entre procesos, un área para mejorar.

Incluye potente testing de snapshots, facilitando la verificación de salidas de comandos o scripts a lo largo del tiempo.

bashunit ofrece un amplio conjunto de assertions nativas para casos de test, incluyendo:

assert_same
assert_equals
assert_contains
assert_matches
assert_string_starts_with
assert_array_contains
assert_successful_code
assert_general_error
assert_file_exists
assert_file_contains
assert_match_snapshot

Incluso puedes crear tus propias assertions personalizadas para extender las capacidades de bashunit.

Con más de 25 contribuidores y más de 325 estrellas en GitHub en solo un año de desarrollo en tiempo libre, estoy genuinamente orgulloso de lo que este proyecto se ha convertido.

Lightning tech talk #

Recientemente, presenté una lightning tech talk en un meetup de hackers, haciendo una demo de bashunit a una audiencia de más de 100 personas. ¡Fue una experiencia increíble compartir esta herramienta con una audiencia tan comprometida!

Logo original de bashunit diseñado por Antonio.

Software de Código Abierto

2021-05-03T00:00:00+00:00

Cada proyecto que publicas se apoya en software de código abierto. Tu framework, tu test runner, tu compilador, la pequeña librería en la que nunca piensas.

Lo usas cada día. La pregunta de verdad es si alguna vez devuelves algo.

Devolver no es caridad. Es una de las formas más rápidas de crecer como desarrollador.

¿Qué es OSS? #

El código abierto no es lo mismo que el software libre. El software libre es una forma de código abierto, pero el código abierto no tiene por qué ser gratis. Dos ejemplos marcan la línea. PHPUnit es código abierto y gratuito. Spryker es código abierto y de pago. Ambos publican su código para que cualquiera lo lea.

OSS es software público, abierto al mundo.

Beneficios #

Dos grupos ganan con el código abierto: las empresas que lo publican, y la gente que contribuye.

Para empresas #

El acceso abierto impulsa la adopción. Cuanto más fácil es conseguir el código, más rápido construye la gente sobre él. La formación y los tutoriales atraen a los que empiezan y hacen crecer el ecosistema. El código suele estar en la vanguardia, porque el software que se queda quieto se vuelve obsoleto. Un proyecto público reúne una comunidad a su alrededor, y los canales públicos hacen fácil unirse a ella.

Y como cualquiera puede leer el código, cualquiera puede comprobar su calidad. Esa confianza no se puede fingir.

Para contribuidores individuales #

Tú eliges en qué trabajas. Practicas habilidades reales sin la presión de una caída en producción. Puedes jugar con las últimas novedades de tu lenguaje, o probar un lenguaje que nunca has tocado.

También afilas las habilidades blandas que sostienen una carrera: escribir con claridad, explicar un cambio, mantener tu postura cuando la gente no está de acuerdo.

El código enseña las habilidades técnicas. Los desacuerdos enseñan el resto.

Contribuyendo a OSS #

Empezando con GitHub #

Empezar es fácil, y tienes dos puertas. Abrir tu propio proyecto, o contribuir a uno que ya existe. Un proyecto personal encaja perfectamente en la primera puerta.

Proyectos personales #

Un proyecto personal es un terreno de juego para crear software real y entrenar habilidades reales. Ponlo en tu perfil público de GitHub y tienes todos los beneficios de contribuir a OSS, más uno: no le respondes a nadie. Tú marcas la hoja de ruta. Tú decides qué construir y cómo. Eres tu propio jefe.

El proyecto está ahí para ti. Tú eres responsable de jugar, explorar y superar tus límites.

Mis proyectos personales #

Activos:

agnostic-ai: escribe agents, skills, rules y hooks de IA una vez, úsalos en cada CLI de IA.
bashdep: un gestor de dependencias sencillo para Bash.
phel-snake: el juego de la serpiente en tu terminal, escrito en Phel.
edifact-parser: un parser para formato de archivo UN/EDIFACT en PHP.
unspent: una librería PHP para contabilidad tipo UTXO con entradas no gastadas.

Inactivos:

create-pr: un script de Bash para abrir un pull request desde tu rama y contexto.

Abandonados:

stock-ticker: recibe una notificación con las noticias de tus Tickers favoritos.
jira-status-notifier: notifica cuando los tickets de JIRA no avanzan.
php-best-practices: lo que consideraba mejores prácticas para desarrollo web (archivado).
php-scaffolding: un scaffolding básico de PHP con Docker (archivado).
knob-mvc: un framework para crear plantillas WordPress (2015/2017).

… y muchos más en github.com/Chemaclass

Mis contribuciones a organizaciones OSS #

Activas:

phel-lang: Phel es un lenguaje de programación funcional que compila a PHP. Es un dialecto de Lisp inspirado en Clojure y Janet. Ya escribí un post sobre esto: Phel: Un Lisp que compila a PHP
gacela-project: Gacela es un framework PHP que te ayuda a mejorar el diseño de tu aplicación dividiendo la lógica en diferentes módulos.

Abandonadas:

nm_template: La plantilla base para NuevaMetal (2013-2016).

Compartir Conocimiento e Impacto #

El código es solo la mitad. La otra mitad es lo que escribes y le entregas a la siguiente persona.

Posts del blog #

… y muchos más en https://chemaclass.com/es/blog/

La belleza del OSS #

Contribuye en público el tiempo suficiente y empiezas a ver tu propio crecimiento. Las correcciones que sigues haciendo. El código que escribiste el año pasado, ya envejecido. Los errores, todos ellos, a la vista. Y por debajo, la prueba lenta de que estás mejorando.

Vas desarrollando un sexto sentido para detectar patrones que ya has visto, los buenos y los dolorosos.

Muestra tus habilidades. Ayuda a la gente a tu alrededor. Eso es trabajar con la puerta del garaje abierta.

El Software de Código Abierto te ofrece una de las mejores oportunidades para empezar a construir una carrera hacia la mejora continua.

Esta es una charla (en español) que hice de forma remota en abril de 2021, para la Comunidad PHPMad Madrid. Presento todas estas ideas junto con una demo en vivo de cómo contribuir a un OSS real.

Phel: el Lisp que Compila a PHP

2021-02-01T00:00:00+00:00

Un nuevo lenguaje de Programación Funcional construido sobre el ecosistema de PHP.

El Lenguaje Phel #

Phel es un lenguaje de Programación Funcional (FP) que compila a PHP. Es un dialecto de Lisp inspirado en Clojure y Janet.

Características #

Construido sobre el ecosistema de PHP
Buenos reportes de errores
Diferentes estructuras de datos (Arrays, Tables y Tuples)
Macros
Funciones recursivas
Sintaxis potente pero simple
REPL

¿Por qué Phel? #

Phel lo creó Jens Haase. Como menciona en el sitio web, “es el resultado de muchos intentos fallidos de hacer programación funcional en PHP”. Buscaba algo con estas características:

Inspirado en LISP
Lenguaje de Programación Funcional
Que funcione en proveedores de hosting baratos
Sea fácil de escribir y depurar

A finales de mayo de 2020 terminé el libro Seven Languages in Seven Weeks, donde aprendí los fundamentos de Prolog, Erlang, Clojure, Haskell… Incluso creé un repositorio en GitHub para guardar mi progreso.

A principios de junio de 2020, vi un post en el canal de PHP de Reddit mencionando este proyecto “Phel”: un lenguaje de programación funcional escrito en PHP.

Llevo unos 8 años trabajando con PHP, y siempre intento combinar OOP con FP (creo que ambos paradigmas funcionan mejor juntos; no son excluyentes). Un nuevo dialecto de Lisp escrito en PHP 7.4 nativo sonaba emocionante. Decidí echarle un vistazo al código.

Las lecturas recientes de Mathias NoBack, como Object Design Style Guide y Advanced Web Application Architecture, me dieron el empuje para aplicar lo aprendido en un proyecto real. Este fue (y sigue siendo) un desafío que me ayuda a crecer profesionalmente.

Mi primer commit fue el 6 de junio de 2020. Desde entonces dedico un poco de tiempo cada día en mis horas libres. Me ayuda a aprender sobre FP, diseño interno de lenguajes, testing y arquitectura de software en general.

Empecé con cambios menores hasta que acabé refactorizando toda la estructura del compilador para hacer los módulos más legibles. Psalm, tipos estrictos, buena cobertura de tests, estilo de código unificado… Estos fueron algunos de mis temas favoritos.

Ejemplo de código Phel #

El siguiente ejemplo da una breve impresión de cómo se ve Phel:

# Define un namespace
(ns my\example)
# Define una variable con nombre "my-name" y valor "world"
(def my-name "world")
# Define una función con nombre "print-name" y un argumento
(defn print-name [your-name]
 (print "hello" your-name))
# Llama a la función
(print-name my-name)

Estado actual de Phel #

Preparamos una fácil Guía de Inicio
Preparamos un Repositorio GitHub fácil con una Plantilla de Scaffolding de Phel
Acabamos de lanzar la primera versión oficial: 0.1.0

Consulta el sitio web oficial con toda la documentación: https://phel-lang.org/

También recomendado #

Functional Programming with Phel - JesusValera