Programemos “la máquina de asombrar”

Baile de las copas en Cancún

Este año me ha vuelto a tocar hablar en un instituto sobre las salidas profesionales de la carrera de informática. Se puede hacer una presentación tal como esta, y no está mal. Pero este año me han dejado un poco de más tiempo, unos 40 minutos, así que antes de la presentación vamos a programar la máquina de asombrar. La actividad está inspirada por ésta llamada Getting Loopy, que consiste en usar el baile para enseñar el concepto de bucle. Yo voy a ir más allá, voy a tratar de resumir la profesión de informática en una actividad de unos 20 minutos.

Los experimentos en casa con gaseosa, y esto todavía no lo he hecho. Cuando vuelva actualizaré con el resultado del mismo y cómo ha influido en la decisión de estudiar o no informática. Con esto quiero decir que si se quiere probar, hazlo bajo tu propia responsabilidad bailonga.

A quién va dirigido

En principio a alumnos de Bachillerato de la opción científico-técnica, que es de donde sale la mayoría de los alumnos de Informática. Quizás alguno de otras ramas, pero en minoría. Por lo tanto, tiene unos 17–18 años.

Como actividad no enfocada a desarrollo vocacional, se puede hacer, creo yo, con niños de casi cualquier edad, aunque quizás convendría no usar ningún tipo de terminología técnica y centrarnos sólo en el concepto de “programa” y “programar”, añadiendo posiblemente algún otro concepto como “bucle”. Si más adelante hay un aula con ordenadores, se puede pedir que se haga la misma rutina de baile usando personajes diseñados en Scratch, o al revés.

Material y espacio.

  • PostIt o fichas, preferiblemente poco “informáticas”: corazones, de color rosa, de colores. Los postit son el “entorno de desarrollo” en el que van a tener que escribir el programa de “la máquina de asombrar”. Es importante que sean postit con la implicación de que los programas tienen normalmente una serie de restricciones, en este caso el espacio.
  • Un espacio donde desarrollar los pasos de baile y donde se puedan ver. También, si alguno de los grupos decide ensayar los pasos de baile antes de “desplegarlos a producción”, espacios donde los grupos puedan estar separados. Si no lo hay, simplemente que no se hagan “pruebas de staging”. Como sucede en la misma realidad.
  • En principio, vamos a intentar que ocupe unos 20–25 minutos.

Desarrollo

Dividimos a los alumnos que vayan a participar en dos grupos, para unos 20 minutos de actividad o así. Un grupo no deberá de tener más de 4–5 personas. Si hubiera más, pues más grupos. Cada grupo va a ser un “equipo de desarrollo”, trabajando sobre un “entorno de desarrollo”.

Cada equipo tendrá que escribir en el PostIt un programa para asombrar con las siguientes condiciones

  • Un lenguaje consistente en la descripción de los pasos de la rutina de baile. Un paso será siempre un paso, o una →, o 1 paso, no “tira pallá” o “1 step”.
  • El programa tiene que caber en un solo PostIt. Si se tienen que repetir cosas, tendrá que usarse un lenguaje tipo “repetir esto” o {} dos veces.
  • Finalmente, se le pone un nombre al “programa” y también al lenguaje que hemos usado para describirlo.
5 equipos de desarrollo preparando aplicaciones para “La máquina de asombrar”

Este equipo de desarrollo, si tiene tiempo y espacio, puede usar una “máquina de desarrollo” para probar los pasos (si es que los otros grupos no lo ven). Si no, tendrá que desplegar a producción el programa entregándole el programa usando algún ritual, el que sea. También se lo pueden inventar.

A continuación, la máquina de producción interpreta y ejecuta el programa, es decir, los pasos de baile. Es decir, que bailan, vamos. El equipo de desarrollo tienen que mirarlo y, si acaso, tomar notas de los errores o bugs que se hayan podido producir. Con esto se quiere representar un entorno en el que se monitoriza las máquinas de producción y también el hecho de que lo que se suelen llamar bugs o errores no son más que problemas de comprensión.

Chocobongo desplegado a producción en una máquina de asombrar con cinco cores.

El resto de los grupos hace lo mismo. Si hay muchos grupos lo pueden hacer a la vez. Incluso se puede dar el mismo programa a dos grupos para ver cómo se hacen despliegues A/B en diferentes entornos de producción para ver su eficiencia.

Finalmente, el programa se devuelve al equipo de desarrollo. Si hay tiempo, se depura o incluso refactoriza creando un nuevo PostIt y volviéndolo a entregar. Si no hay, bueno, pues no.

Concluyendo

Cualquier experiencia de este tipo conviene evaluarla. A continuación de la experiencia se puede hacer la presentación tradicional sobre la carrera de informática y lo que implica y lo que mola. Conviene también preguntar al principio y al final cuanta gente quería estudiar informática. Si se ha conseguido a alguna persona más para la causa, un tiempo por bien empleado.

Ya tengo los PostIts rosas preparados para trabajar y la presentación en aproximadamente dos horas. Actualizaré el post con el resultado o escribiré un nuevo post, dependiendo de lo bien (o mal) que salga.

Segmentation fault, core dumped.

Bueno, no ha ido tan mal, en realidad. Como todos los despliegues a producción, ha tenido el problema de que todas las instancias no se han levantado a la vez. Vamos, que había gente llegando un rato después del comienzo y ha habido 5 grupos con casi 30 personas, más otros 3 o 4 fuera de grupo. También ha habido un problema de escala. Como los despliegues a producción han sido secuenciales, se ha tardado un poco en presentarlos, y no hemos podido hacer una segunda fase de depuración y puesta en producción de nuevo.

También, como en todo despliegue en la nube, los clásicos problemas de aprovisionamiento: gente sin boli, básicamente. Como no era la clase de todos los que han venido, algunos se lo han dejado en su clase.

Finalmente, problema de no usar un sistema de control de fuentes. No he visto físicamente ninguno de los programas escritos en PostIt. A ver si puedo recuperar alguno y lo pongo por aquí.