Usamos cookies para mantener el sitio estable, recordar opciones basicas y entender que paginas resultan utiles. Puedes aceptar, rechazar o revisar la configuracion antes de continuar.
Aquí queda escrito el orden real de las cosas: cómo se propone un reto, qué se espera de quien participa, cuánto tiempo suele llevar y en qué punto conviene parar y pedir una revisión antes de seguir.
Cómo trabajamos
Cada reto semanal sigue el mismo recorrido, aunque el tema cambie: shaders, katas de algoritmos, audio reactivo o utilidades de terminal. Lo que ves aquí es el orden real de las cosas, con sus tiempos y sus puntos donde la gente suele atascarse.
Cada lunes sale el reto con las restricciones claras: lenguaje permitido, límite de dependencias y qué se considera una solución válida. Si el enunciado admite varias lecturas, se avisa en el mismo hilo.
Antes de escribir la versión final, la mayoría prueba dos o tres enfoques en un archivo suelto. Aquí es donde aparecen los errores típicos: precisión de float en móviles, orden de interpolaciones en shaders o índices mal calculados en las katas.
La entrega incluye el código con comentarios sobre las decisiones de arquitectura, no solo el resultado. Se pide medir tiempos de ejecución cuando el reto lo permite, para que la comparación entre enfoques tenga datos y no impresiones.
Otra persona del colectivo lee el código y deja notas en el hilo: nombres, casos límite, rendimiento. No es una corrección formal, es una conversación técnica con criterio. Si algo no se entiende, se pregunta sin rodeos.
Las soluciones aceptadas se suben a la galería de la comunidad junto al fragmento clave y una nota breve sobre qué se aprendió. Las que se quedaron a medias también se publican si el proceso aporta algo.
Al final de la semana se recogen los aprendizajes en una nota corta y se abre el enunciado siguiente. Los hilos antiguos siguen abiertos: si vuelves meses después con otra solución, se compara con la anterior.
Si quieres ver cómo se aplica este recorrido en un caso concreto, revisa el detalle del proceso o pásate por la página del colectivo.
Cronología del método
No hay un plan maestro detrás de CodeYourFaceOff. Hay una secuencia de decisiones que fuimos tomando según lo que pedía cada reto semanal: primero el formato, después la revisión, más tarde las herramientas. Esto es lo que pasó en cada etapa y qué quedó de cada una.
Otoño 2023 · Primeros retos
Empezamos publicando un kata cada lunes con un enunciado corto y un plazo de siete días. Los primeros diez retos eran de estructuras básicas: arrays, mapas, recursión. La idea era que cualquiera pudiera resolverlos en una tarde y comparar su solución con la de otros.
Invierno 2023 · Revisión abierta
Al llegar a treinta soluciones publicadas vimos que hacía falta orden. Fijamos cuatro criterios de revisión: claridad del nombre, coste real medido, manejo de casos límite y comentarios útiles. Cada hilo queda abierto y cualquiera puede responder con una variante.
Primavera 2024 · Arte generativo
Añadimos una línea paralela de retos visuales: campos de flujo, ruido Perlin, paletas generadas por hash. Aquí el proceso se documenta distinto: capturas del shader en distintas resoluciones, tiempos de frame en móvil y notas sobre precisión de float en WebGL2.
Verano 2024 · Audio y CLI
Los retos de audio reactivo con Web Audio API y las utilidades de línea de comandos en Python llegaron juntos. Son formatos más largos, así que pasamos a publicar cada quince días en lugar de cada semana para no sacrificar la revisión.
Actualidad · Estado del método
Hoy los retos están clasificados en iniciación, intermedio y avanzado, con recursos de partida para quien llega desde JavaScript, Python o Processing. Todo el archivo de soluciones y revisiones sigue accesible sin registro, y cada nuevo reto se anuncia con su enunciado completo y sus restricciones antes de abrir el plazo.