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.
Cada semana publicamos un enunciado con su contexto técnico, los recursos mínimos para abordarlo y un plazo de entrega. Antes de escribir código, explicamos qué se espera del resultado, qué no, y en qué se fijan quienes revisan las soluciones.
La página de inicio no es una promesa: es un calendario. Aquí queda registrado qué ocurre desde que se publica un enunciado hasta que las soluciones se archivan en el repositorio común. Fechas, entregas y lo que se espera de ti en cada tramo.
Publicación del enunciado
Se publica el brief con restricciones claras: lenguaje permitido, límite de líneas, si se admite o no una librería concreta. Los retos de nivel inicial suelen pedir solo canvas 2D; los avanzados entran en shaders y buffers.
Trabajo y dudas
Durante estos días se puede preguntar en el hilo del reto. No se resuelve el ejercicio por nadie, pero sí se orienta sobre errores de precisión, orden de interpolaciones o por qué un bucle se come el frame rate. Los fragmentos de código se comparten comentados.
Cierre de entregas
Se entrega un enlace al repositorio o un archivo con el código y una nota breve sobre las decisiones tomadas. No se valora la estética final: se valora que el proceso esté explicado y que el código se pueda leer sin contexto adicional.
Comparativa pública
Se publican las soluciones junto a un comentario sobre qué enfoque eligió cada persona y por qué. Aquí aparecen las diferencias reales: quien optimizó memoria, quien priorizó legibilidad, quien se quedó a medio camino y lo cuenta igual.
Archivo y siguiente reto
Todo queda archivado con su fecha y su nivel de dificultad. El lunes siguiente empieza otro reto, a veces relacionado con el anterior y a veces no. Si te incorporas a mitad de semana, puedes resolver el reto vigente o recuperar uno antiguo del archivo.
Antes de publicar nada, cada reto pasa por el mismo recorrido. No hay atajos ni entregas sorpresa: quien participa sabe en qué punto está y qué se espera de su solución. Esto es lo que ocurre desde que se lanza la propuesta hasta que aparece en la galería.
Cada lunes aparece un reto con un objetivo concreto: un campo de flujo en canvas, una kata de grafos, un shader con ruido animado. Se indica el lenguaje sugerido (JavaScript, Python o Processing) y las restricciones reales: sin librerías externas, tiempo de ejecución máximo, tamaño del conjunto de datos.
No hay plantilla obligatoria. Algunos abren un archivo HTML con un canvas y listo, otros levantan un proyecto con bundler. En los hilos de la comunidad se comparten configuraciones mínimas y se avisa de los problemas típicos: precisión de float en móviles, orden de interpolaciones en GLSL, latencia de audio en Firefox.
Lo que se envía no es solo el resultado. Se pide el código comentado, los errores que aparecieron por el camino y una nota breve sobre las decisiones de arquitectura. Un fragmento de veinte líneas bien explicado vale más que una demo pulida sin contexto.
Durante la semana siguiente, las soluciones se abren a comentarios. Se discuten enfoques alternativos, se comparan tiempos de ejecución medidos y se señalan los puntos donde el código se puede simplificar. La crítica va al código, nunca a quien lo escribió.
Las soluciones que aportan algo al conjunto (una técnica nueva, una comparativa útil, un error bien documentado) pasan a la galería pública. Ahí quedan como referencia para quien llegue después y quiera ver cómo se resolvió un problema parecido.
El ciclo vuelve a empezar sin pausa. Los temas se encadenan: un shader de ruido puede derivar en una kata de vecinos más cercanos o en una demo de audio reactivo. Si quieres ver cómo se conectan las piezas, en la página de proceso está el mapa completo.
Si es tu primera vez, lo más útil es empezar por un reto de dificultad baja y leer las revisiones de otros antes de publicar. En quiénes somos contamos por qué mantenemos este formato abierto y sin plazos rígidos.