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 se abre un reto con un enunciado corto y un límite de tiempo razonable. Lo que se publica después no es la solución más elegante, sino el proceso: los archivos tal como quedaron, las decisiones que se tomaron a mitad de camino y los errores que costaron más de lo previsto.
Cada reto semanal sigue un recorrido bastante fijo. No es una metodología cerrada, pero sí un orden que nos ahorra repetir las mismas dudas cada vez que alguien se suma por primera vez. Aquí queda la cronología real, con lo que se publica, cuándo y qué se espera de quien participa.
Lunes
Se abre el reto con una restricción concreta: sin librerías externas, un solo archivo, o un límite de líneas. El enunciado incluye ejemplos de entrada y salida cuando aplica, y una nota sobre qué se considera una solución válida.
Martes a jueves
La gente publica fragmentos intermedios, no solo el resultado final. Es habitual ver capturas de errores, tiempos de ejecución medidos a mano y decisiones de arquitectura a medio justificar. Las preguntas se responden en el mismo hilo para que queden visibles.
Viernes
Se aceptan soluciones en JavaScript, Python o Processing. No se puntúa la elegancia del código, sino que el enfoque esté explicado. Las entregas que llegan tarde se incorporan igualmente a la galería, pero fuera del orden de revisión semanal.
Sábado
Se eligen dos o tres soluciones con enfoques distintos y se comentan lado a lado. Interesa más el contraste que la corrección: por qué alguien eligió un heap parcial frente a un ordenamiento completo, o por qué un shader se comporta distinto en móvil.
Domingo
Todo queda archivado por dificultad y por lenguaje en la galería de la comunidad. El lunes siguiente arranca un reto nuevo, a veces relacionado con el anterior y a veces no. Si quieres proponer un enunciado, se puede enviar antes del cierre.
Cada semana abrimos un enunciado, lo discutimos en el hilo público y publicamos las soluciones con sus tiempos, errores y decisiones. Estos son los pasos que seguimos, sin atajos ni resultados maquillados.
Publicamos el reto con un objetivo claro y límites concretos: lenguaje permitido, tamaño máximo del archivo, si se pueden usar librerías. Los enunciados suelen ser ambiguos a propósito para que cada uno decida su enfoque.
Antes de escribir la versión final, se prueban dos o tres caminos. Aquí es donde aparecen los callejones sin salida: shaders que no compilan, bucles que se comen la memoria, APIs que no hacen lo que prometían.
El código se publica con comentarios sobre las decisiones reales: por qué se eligió un heap parcial en lugar de ordenar, por qué se evita una textura precalculada. Nada de fragmentos limpios sin contexto.
Cada solución se mide en condiciones concretas: versión de Node, navegador, tamaño del conjunto de datos. Los tiempos se publican tal cual salen, incluso cuando contradicen la teoría de la complejidad.
Las soluciones se comentan en abierto. Se señalan errores frecuentes, alternativas más cortas y casos límite que el autor no había considerado. La crítica va al código, no a quien lo escribe.
Todo queda archivado por dificultad y lenguaje. El enunciado de la semana siguiente se abre al cerrar el anterior, para que quien quiera pueda comparar enfoques entre retos consecutivos.
Si quieres ver el detalle metodológico detrás de estos pasos, revisa nuestro método. Y si prefieres empezar por un caso concreto, el desglose del shader de ruido Perlin muestra el proceso completo aplicado a un reto real.