Cada taller parte de un problema concreto y se resuelve en directo: un campo de flujo en GLSL, un kata de vecinos más cercanos, una demo de audio reactivo con AnalyserNode. Se revisan los fragmentos comentados, los errores que aparecen al portar el código y las decisiones de arquitectura que marcan el resultado.
Cada taller sigue la misma ruta, aunque el tema cambie: shaders, canvas, audio reactivo o katas de algoritmos. No hay clases grabadas ni teoría previa. Se parte de un problema concreto y se llega a una solución que puedes ejecutar en tu máquina el mismo día.
Se publica el problema con restricciones claras: lenguaje permitido, límite de líneas, si se puede usar librería externa o no. Los enunciados de shaders suelen pedir GLSL puro; los de canvas, JavaScript sin frameworks.
Antes de escribir la versión final se prueba en pequeño: un canvas de 200x200, un shader que solo dibuja un gradiente, una kata con 20 elementos en lugar de 10.000. Aquí se descartan enfoques que no aguantan.
El código se entrega con comentarios sobre las decisiones reales: por qué se usa una función hash de tres pasos, por qué el orden de los ejes afecta al rendimiento, por qué se cambia de quickselect a heap parcial según el valor de k.
Se documentan tiempos de ejecución, problemas de precisión de float en móviles, latencia de audio en Firefox. Los errores frecuentes se listan tal como aparecen, no como deberían aparecer.
Cada solución se abre a comentarios en el hilo del reto. Se comparan enfoques, no se puntúa el resultado. Una variante con value noise puede ser más útil que la versión con Perlin según el caso.
El fragmento final, el perfilado y las notas se publican en la galería de la comunidad. Si quieres ver cómo se documenta un taller completo, revisa el proceso editorial o pásate por quiénes mantenemos esto.
Cada ejercicio del taller está pensado para que salgas con algo que puedas reutilizar: un patrón, una medición o una decisión de arquitectura que ya hayas probado en tu propio código.
Cada reto se entrega con el código anotado línea a línea: por qué se elige un hash de tres pasos en un shader, por qué el orden de los ejes cambia el rendimiento en un array de coordenadas. Copias, pegas y entiendes qué estás tocando.
La precisión de float en móviles al portar GLSL a WebGL2, la latencia de AnalyserNode en Firefox, el punto de cruce entre quickselect y heap parcial. Los fallos que aparecen una y otra vez quedan escritos para que no los repitas a ciegas.
Perfilado en Chrome, comparativas en Node 20, variaciones según el tamaño de k. No se trata de decir qué algoritmo es mejor en abstracto, sino de enseñarte dónde está el punto de cruce en tu caso concreto.
Publicas tu solución y otros desarrolladores comentan el enfoque, no solo el estilo. Se discuten decisiones de arquitectura, alternativas al stack elegido y qué partes del código se pueden simplificar sin perder claridad.
Los retos están agrupados por nivel y por stack: JavaScript, Python o Processing. Si empiezas, hay katas de algoritmos con enunciado cerrado; si ya llevas tiempo, hay experimentos de arte generativo con canvas y shaders abiertos a interpretación.
Demos de audio reactivo, utilidades de línea de comandos, generadores de ruido. Piezas cortas que puedes insertar en tus propios proyectos sin arrastrar dependencias ni frameworks de visualización.
Si quieres ver cómo encajan estos retos dentro del taller completo, revisa el proceso de trabajo o pásate por la página del colectivo.