Participando en el CodeJam con ZinjaI

El fin de semana pasado comenzó el Google Code Jam, ese contest online de programación que organiza Google. Pero este año cambiaron un poco las reglas de la mano de un cambio grande en el entorno sobre el cual se desarrolla. Eso hizo que sea un poquito más incómodo desarrollar las soluciones desde mi IDE preferido. Acá les cuento cómo acomodar ZinjaI para que el "workflow" durante el contest sea algo más fluido, dado que a partir de la 1er ronda la cosa es por tiempo, se pone ajustada, y cada segundo cuenta.

Antes, uno descargaba un archivo de datos de entrada y corría en su máquina como quisiera y con el compilador o intérprete que quisiera su solución. Esta debía generar un archivo de salida y había que subir ese archivo. Esto era muy cómodo, porque entonces se podía tener abiertos en distintas pestañas los archivos de entrada, salida y fuente; y para probar un cambio en la solución, simplemente había que ejecutar e ir a la pestaña del archivo de salida, no se necesitaba reingresar nada.

Ahora, tenemos que enviarles el código para que ellos compilen y ejecuten. Cuando lo hagan, van a esperar que el programa lea desde la entrada estándar (cin), y escriba en la salida estándar (cout). Esto es molesto para probar cambios desde un IDE, pues no parece sensato tener que ingresar la entrada con cada prueba cuando uno está trabajando contrareloj. Para solucionar esto (sin #ifdefs, que es la solución más habitual) me hice un script que consiste en repetir tres pasos ad-infinitum: 1) esperar que se modifique el fuente, 2) compilar, 3) ejecutar, redireccionando un archivo de texto a la entrada. Así puedo fijar la entrada en un archivo de texto y dejar el script corriendo en un segundo monitor; entonces cada vez que guardo un cambio veo automáticamente el nuevo resultado.

A la izquierda el panel del explorador (Ctrl+E) con la carpeta del contest. A la derecha, el script corriendo.
En medio, la configuración de una herramienta personalizada para lanzar el script desde ZinjaI.

Pero hay más. El hecho de que ellos corran las soluciones en su servidor los habilita a hacer ejercicios con entrada interactiva. Es decir, donde la entrada no es fija, sino que depende de las salidas parciales que nuestro código vaya generando. Por ejemplo, en la sesión de práctica había uno donde nuestro código debía adivinar un número secreto; y por cada intento en la entrada nos respondían con "muy alto" o "muy bajo" para que ajustemos el siguiente intento. Obviamente, esto no se puede probar con entrada predefinda desde un archivo.

En estos casos, parece que nos van a ofrecer un script de python que más o menos emule la lógica de la entrada. La forma que tenemos de probar nuestra solución antes de enviarla es mediante ese script. Pues bien; mi script de bash detecta a ese script si lo descargamos en la carpeta de trabajo, y cambia el modo de ejecución, pasando a usar ese script a modo de wrapper. Entoces también sirve para este tipo nuevo de problemas, y se da cuenta solo.

Por último, un detalle no menor. Una vez listo el código, hay que copiarlo y pegarlo en el entorno web del contest para que google lo valide. En la sesión de práctica descubrí que la versión de wx con la que compilo ZinjaI tiene un bug (no es culpa de wx, es que uso una versión de hace 1000 años) que hace que con ciertos gestores de portapapeles, no podamos copiar código en ZinjaI y pegarlo en el navegador. Me funcionaba, por ej, pegarlo en Kate/KWrite, pero no en Firefox ¿?. Improvisé un parche medio feo que soluciona esto en la versión de prueba que publiqué el viernes antes del contest (y actualicé ayer), y por eso recomendé por twitter que la bajen antes de participar.

Con todo esto, lo que yo hago es preparar una carpeta para cada competencia, con tres o cuatro subcarpetas, una por problema. Para cada problema, dejo un cpp con una base que uso a modo de plantilla, un archivo de entrada en blanco para pegar ahí el ejemplo que me de el enunciado, y el script para lanzar todo. En ZinjaI, uso las herramientas personalizables para poder lanzar el script rápidamente, y el panel del explorador (Ctrl+E) para tener todas las subcarpetas y los archivos bien a mano. Ni hablar de que al momento de escribir código uso atajos de teclados, autocódigos, inserción automática de includes, ediciones múltiples, etc... todo lo que pueda para escribir mucho tipeando poco y ganar otros tantos segundos extra para pensar en las soluciones.