Cada reto, fragmento de código y comparativa de rendimiento que aparece aquí pasa por una revisión antes de salir: se reproduce en un entorno limpio, se anotan los tiempos reales y se dejan a la vista los errores que encontramos por el camino. Si algo no lo hemos podido comprobar, lo decimos.
CodeYourFaceOff no es una plataforma con inversores ni un producto cerrado. Es un colectivo que publica retos, revisa código ajeno y mantiene sus herramientas en abierto. Las colaboraciones que aparecen aquí son reales: talleres, publicaciones conjuntas, mantenimiento de librerías y espacios donde hemos dado charlas o dejado material. Nada de logotipos decorativos.
Taller colaborativo
Sesiones trimestrales de arte generativo con Processing y p5.js. Aportamos los cuadernos de los retos y ellos ceden el espacio y el proyector. Los materiales quedan publicados en abierto tras cada edición.
Publicación amiga
Fanzine impreso sobre cultura del código. Hemos cedido fragmentos comentados de shaders y katas para dos números. A cambio, ellos nos pasan correcciones de estilo sobre cómo explicamos los algoritmos sin jerga.
Mantenimiento conjunto
Compartimos repositorio de utilidades de línea de comandos para procesar audio en lote. Ellos llevan la parte de Python, nosotros la de Node. Las revisiones cruzadas se hacen en hilos públicos del foro.
Revisión de código
Acompañamos a su alumnado de iniciación con revisiones de katas en JavaScript. Sin notas ni certificados: solo comentarios sobre legibilidad, nombres y casos límite. Llevamos cuatro promociones seguidas.
Infraestructura
Nos alojan los servidores donde corren las demos de canvas y los archivos de audio de los retos. Es un acuerdo de cesión entre colectivos, sin contrato comercial ni métricas de tráfico compartidas.
Difusión
Participamos en la organización del track de shaders y damos una charla por edición. El programa completo y las grabaciones quedan archivados en el sitio del encuentro, no aquí.
Si llevas un proyecto, un taller o un repositorio y crees que encaja con esta forma de trabajar, escríbenos y lo miramos sin prisa. Preferimos pocas colaboraciones bien sostenidas que una lista larga de nombres.
Sin métricas infladas ni logotipos de relleno. Estas son personas reales que han enviado soluciones a los retos, han pasado por revisión de código y han dejado su opinión sobre cómo trabajamos.
Envié mi solución al reto de campo de flujo pensando que me la devolverían con un simple "ok". Recibí tres comentarios concretos sobre el orden de las interpolaciones en el shader y una alternativa con value noise. Aprendí más en esa revisión que en una semana de tutoriales.
Llevo años escribiendo Python para datos y nunca había tocado Processing. Los recursos para empezar están escritos sin condescendencia y los katas de algoritmos me obligaron a pensar en la caché, no solo en la notación O. Eso no lo encuentras en cualquier sitio.
Lo que más valoro es que publican los errores. Cuando alguien comparte su demo de audio reactivo y explica por qué le fallaba la latencia en Firefox, aprendes más que viendo solo el resultado final. Aquí el proceso importa de verdad.
Cada solución que aparece en la galería ha pasado por al menos una revisión de otro miembro del colectivo. Los tiempos de ejecución que citamos salen de mediciones repetidas en la misma máquina, no de una sola pasada. Si algo no lo hemos podido reproducir, lo decimos.
No mostramos contadores de usuarios inflados, ni sellos de "certificado" sin contexto, ni testimonios anónimos. Tampoco publicamos fragmentos de código sin explicar de dónde salen. Si un experimento falla o un enfoque resulta más lento de lo esperado, también lo contamos.
No publicamos testimonios de portada. Estos son comentarios de personas que entregaron una solución, pasaron por revisión y volvieron al siguiente reto. Lo que cuentan tiene que ver con lo que aprendieron en el proceso, no con una insignia.
Entré al reto de campo de flujo pensando que iba a copiar un shader de un tutorial. Terminé reescribiendo la función hash tres veces porque no entendía por qué el ruido se veía estático. Las notas de revisión me señalaron justo eso: no era el shader, era cómo estaba pasando el tiempo como uniform.
Marta Ibáñez
Frontend, Valencia. Reto de shaders, nivel intermedio
Venía de Python y no había tocado canvas en mi vida. El kata de k-vecinos más cercanos me obligó a medir en lugar de suponer: mi primera versión ordenaba todo el array y tardaba el triple. Comparar mi solución con la de otra persona en el hilo fue más útil que cualquier curso que haya hecho.
Diego Ferrán
Backend, Sevilla. Katas de algoritmos
Lo que más me sirvió fue ver los errores documentados de otros. Cuando mi AnalyserNode devolvía bins planos, ya había un hilo donde alguien explicaba el problema de fftSize y el redondeo a potencia de dos. Resolví en veinte minutos algo que me habría costado una tarde entera.
Nuria Castells
Docente, Bilbao. Demo de audio reactivo
Publico mis experimentos en Processing desde hace años y nunca los había sometido a revisión. La primera vez dolió un poco: me señalaron que el código funcionaba pero era imposible de leer seis meses después. Ahora comento las decisiones de arquitectura antes de escribirlas.
Álvaro Ruiz
Artista generativo, Zaragoza
Empecé con la herramienta de línea de comandos del reto de nivel básico. No sabía qué era un argumento posicional ni cómo parsear flags sin dependencias. La solución que publiqué después no era elegante, pero funcionaba y estaba explicada paso a paso. Eso me dio confianza para seguir.
Lucía Prats
Estudiante, Murcia. Retos de nivel básico
Llevo años programando por trabajo y había perdido la costumbre de hacerlo por gusto. Aquí el foco está en el proceso, no en el resultado bonito. Ver los tiempos de ejecución de otras personas y sus decisiones de arquitectura me devolvió las ganas de experimentar sin objetivo claro.
Tomás Arjona
Ingeniero de datos, A Coruña