CodeYourFaceOff nació como un cuaderno compartido entre gente que dedica las noches a resolver katas, romper shaders y publicar el resultado aunque no quede perfecto. Aquí contamos quiénes somos, cómo trabajamos y por qué seguimos publicando en abierto.
Nuestra historia
CodeYourFaceOff empezó como un hilo suelto donde tres personas compartían katas de algoritmos resueltas en distintos lenguajes. No había web, ni retos formales, ni revisión de código. Solo fragmentos pegados en un editor compartido y la costumbre de explicar por qué una solución funcionaba mejor que otra. Ese hábito de documentar el proceso, no solo el resultado, sigue siendo el eje de todo lo que hacemos.
2019
Se fijó una regla sencilla: un reto cada lunes, una solución publicada antes del viernes. El primero fue un generador de patrones con canvas puro. Llegaron doce respuestas, casi todas con el mismo error de redondeo en las coordenadas. Ese error se convirtió en la primera entrada de la sección de errores frecuentes.
2021
Un miembro del colectivo propuso migrar los retos de canvas 2D a WebGL. Costó tres semanas adaptar el flujo de trabajo: los shaders no se depuran igual, y la precisión de float en móviles rompió varias demos. Aprendimos a perfilar antes de publicar. Desde entonces cada reto de shader incluye una nota sobre rendimiento y una captura del perfilado.
2023
Los hilos de revisión dejaron de ser un canal privado y pasaron a ser públicos. Cualquiera puede comentar una solución, señalar un caso límite o proponer una variante. La norma es no reescribir el código de otro sin explicar el motivo. Hoy hay más de doscientos hilos abiertos, la mayoría sobre katas de algoritmos y demos de audio reactivo.
Al principio los retos eran individuales y anónimos. Hoy hay una galería pública donde cada solución lleva el nombre de quien la envió, el tiempo que tardó y los errores que encontró por el camino. La sección de recursos para principiantes nació de las preguntas repetidas en los hilos: cómo montar un canvas, cómo leer un shader, cómo medir el rendimiento sin herramientas externas.
El colectivo sigue siendo pequeño y no tiene prisa por crecer. La prioridad es que cada reto semanal llegue con material suficiente para aprender algo concreto, aunque sea un detalle pequeño sobre cómo funciona un bucle o por qué un shader se comporta distinto en cada dispositivo.
Misión
CodeYourFaceOff nació de una costumbre sencilla: guardar los intentos fallidos antes de tirarlos. Con el tiempo esos fragmentos rotos, los tiempos de ejecución medidos a mano y las decisiones de arquitectura explicadas en voz alta se volvieron el material más útil que teníamos. La publicación existe para que ese proceso quede a la vista de cualquiera que programe por gusto.
Cada reto semanal se publica con el código comentado, los errores que aparecieron por el camino y una nota sobre qué se descartó. Un shader que tarda 12 ms en móvil cuenta más que uno que se ve bonito en la captura.
Los hilos de revisión funcionan como una conversación técnica: se discute el enfoque, se proponen alternativas y se acepta que dos soluciones distintas pueden ser correctas. Nadie firma como autoridad.
Scripts de línea de comandos, utilidades para Processing y experimentos de audio reactivo se publican tal como se usan en el día a día. Si algo ahorra diez minutos de trabajo, merece estar disponible para el resto.
Hay retos por dificultad y recursos para JavaScript, Python y Processing pensados para la primera semana, no para el portfolio. La idea es que alguien sin experiencia previa pueda publicar su primera solución sin sentirse fuera de lugar.
Cronología del colectivo
CodeYourFaceOff nació como un cuaderno compartido entre tres personas que programaban de noche. Lo que empezó siendo un hilo de correo con retos sueltos terminó siendo una publicación abierta con revisiones, galería y material didáctico. Estas son las etapas que marcan el recorrido, con sus fechas y lo que dejó cada una.
La consigna era simple: dibujar algo en canvas sin usar librerías. Llegaron siete soluciones, tres de ellas con el mismo error de redimensionado. Ese hilo de correcciones fue el germen de la sección de revisión de código.
Hasta entonces los resultados vivían en carpetas privadas. Publicamos una galería con capturas y enlaces al código fuente de cada participante, incluyendo los intentos que no llegaron a funcionar. La transparencia sobre lo que falla se volvió una norma del proyecto.
Un bloque de cuatro retos consecutivos dedicados a fragment shaders. Documentamos los problemas de precisión en móviles y el coste real de las funciones hash. Esa serie sigue siendo el material más consultado del archivo.
Empezamos a publicar comparativas de rendimiento junto a cada kata. No basta con que el algoritmo pase los tests: medimos tiempos en Node y anotamos el punto de cruce entre enfoques según el tamaño de la entrada.
La serie de audio reactivo conectó el micrófono al AnalyserNode y llevó los bins de frecuencia a un shader como textura. Documentamos la latencia en Firefox y una sincronización sencilla con requestAnimationFrame.
Publicamos utilidades pequeñas en Node y Python, y una guía de entrada para quien empieza con JavaScript, Python o Processing. El objetivo sigue siendo el mismo: mostrar el proceso, no solo el resultado.