Bitácora de Vuelo

Se fue otro PyCamp. Como siempre, genial. Lo charlaba con Moni, es notable como el formato del evento no decae año a año, ¡siguen siendo bárbaros!

Eso sí, voy a tratar de innovar en lo que es la descripción del mismo, escaparme de hacer una cronología, y orientar más el relato a las situaciones.

Llegando y saliendo

Los viajes bien. Como el año pasado, me quedé hasta "cerrar el evento", y también como el año pasado, luego de vaciar el lugar, entregar la llave y eso, nos quedamos algunos tomando unas cervezas en el bar del lugar, hasta que íbamos partiendo en función del horario de bondi de cada uno.

La diferencia estuvo en la llegada, ya que este año no tuvimos al Joven Ocupado en la Accesibilidad y Conectividad (JOAC), así que tuvimos que armar toda la infraestructura de red sin saber demasiado. Viajé con Nico Demarchi, así que al llegar nos pusimos con eso... y aunque no es rocket science, tampoco es trivial, y estuvimos como tres horas para dejar todo lindo!

Proyectos

El proyecto mío en el que más trabajé fue Encuentro, en parte en esta biblioteca para parsear SWFs que vengo necesitando, pero también porque para este proyecto se anotaron varias personas... ¡y metieron un montón de laburo! Tres branches de Mica Bressan, dos de Nico y uno de Emiliano Dalla Verde Marcozzi, y creo que hay otro más dando vuelta por ahí.

También trabajé en un proyecto nuevo, que arrancó en este PyCamp. Es WeFree (EDITADO: la url no existe más), un proyecto para almacenar colaborativamente claves de redes, de manera de hacer que tu computadora o teléfono se conecte automáticamente en todos los lados posibles. Participé todo el primer día, en el diseño general y luego armé la interfaz gráfica para la compu (no toda, pero sí la base, dejando algo usable).

Algo en lo que también trabajé desde cero, pero que no sé si se puede calificar como proyecto, fue algo así como la "búsqueda del testrunner perfecto", que describí en este post. Con la ayuda de Martín Gaitán atacamos como base a nose, y le fuimos agregando plugins y probándolos. El experimento fue un éxito, logramos todo lo que queríamos, ya voy a poner un post acá explicando bien el detalle.

Hubo un proyecto que llevé pero en el que yo no trabajé, que fue Linkode, pero Seba Alvarez estuvo haciendo cosas copadas con la interfaz, me tiene que mandar el código.

Finalmente, arranqué ayudando a un par de chicos a migrar código a Python 3, pero no hicimos mucho de eso (aunque aprendimos algunos detalles interesantes).

Las noches

Sólo tres, porque el último día uno viaja, pero las aprovechamos a full :)... la gente se va a dormir sorprendentemente tarde luego de lo arduo que son los días. Bah, más sorprendente es que muchos al otro día nos levantamos temprano :p

La primer noche jugué a un juego que no conocía, el Munchkin, ¡y gané!. Está bueno el juego, pero es uno de esos que tenés que leer mil cartitas, entonces las primeras diez veces que jugás se hace un poco lento.

El sábado fue la reunión de PyAr, y después charlé con gente y programé algo, no jugué a nada.

La tercer noche fue doble... Munchkin primero (ganó Matías), y luego jugamos al Carrera de Mente. Hacía como 15 años que no jugaba un Carrera de Mente, no me acordaba que fuese tan divertido! Nos reimos mucho.

Notas de color

Este año Alecu no pudo venir... y Diego Sarmentero se le ocurrió la idea de nombrarlo Lider Inspiracional, y mandó a imprimir dos cuadros, uno para tenerlo durante el día, y otro para tenerlo luego de las cenas.

A nivel de "actividades al aire libre", este año volvimos a repetir la caminata del año pasado hasta el río (fuimos un grupito de unos 10), y también hice paddle con Hugo Ruscitti, Emilio Ramirez y Hernán Lozano. ¡Jugamos un montón! Bah, menos de dos horas, pero nos arreglamos para meter dos partidos (cinco sets rápidos).

También hicimos una *key signing party*, y Juanjo Ciarlante nos charló un poco de seguridad y buenas costumbres.

Hace rato que vengo con ganas de hablar acerca de una serie de herramientas interesantes que he encontrado.

Son de lo más variadas. Lo único que tienen en común es que solucionan un problema específico que tuve o tengo. Y que me parece que son piolas :)

Limitando el ancho de banda: ¿Tienen una aplicación que les usa mucho la red? Aunque la misma no esté preparada para autolimitarse, siempre se puede hacer desde afuera, y para ello nos viene a ayudar trickle, un utilitario que hace justamente lo que queremos: ejecutar otro programa limitándo su ancho de banda usable para download, para upload, o ambos.

Midiendo uso de recursos: Muy relacionado con lo anterior, a veces vemos que la red se está usando, pero no sabemos por qué proceso. Para contestarnos esto tenemos dos herramientas, IPTraf y NetHogs, que nos muestran la info pertinente de forma bastante distinta, por lo cual está bueno tener ambas a mano, para probar cual nos va mejor en cada momento. También nos pasa parecido con el uso del disco. en este caso nos salva las papas el iotop. Para recursos como memoria y CPU tenemos el clásico top, obviamente, pero muchas veces uso htop que es más interactivo y me facilita la exploración.

Fijate si cambió: ¿Alguna vez les pasó que tiran un comando en la terminal cada algunos segundos para monitorear algo, tratando de ver si algún dato cambia o viendo cómo cambia? En estos casos lo mejor es usar watch, que nos ejecuta el programa que queremos, cada los segundos que le especificamos, y encima nos resalta los lugares donde hubo cambios con respecto a la ejecución anterior. Más útil de lo que parece.

Mandando muchos mails: Me pasa seguido, para organizar jodas en casa, o eventos en PyAr, o cursos, etc, que tengo que mandar el mismo mail a mucha gente. Mandar uno por uno es mucho trabajo; mandar todos en "copia oculta" es muy impersonal; y ponerlos a todos en "copia visible" es una mala práctica. Por suerte está Mail Merge, un plug-in para Thunderbird que hace todo sencillo: uno pone todos los destinatarios en el campo de "Para:", pero luego en lugar de hacer click en "Enviar", se elige la opción de MailMerge, y en vez de salir uno para todos, el plug-in manda un mail a cada uno. Limpio, y útil. Y tiene opciones para lograr cosas más complejas, pero no lo exploré demasiado, con esta funcionalidad básica por ahora me alcanza.

Seguridad, seguridad: Por último, la herramienta que más me tiene fascinado estos últimos tiempos. Se llama KeePassX, y marcó un antes y un después en mi administración de contraseñas. En el pasado, yo tenía tres o cuatro claves... una genérica, una para lugares de "alta seguridad" como el banco, etc, y las repetía en varios sitios. Así y todo, las claves no eran demasiado complejas (usaba mayúsculas, minúsculas y números, pero no caracteres extraños, y nunca superaba los 10-12 caracteres). ¿Por qué? ¡Por que me las tenía que acordar! Con KeePassX, sin embargo, ya no me las tengo que acordar: se guardan en un archivo (cifrado con una clave que sí tengo que acordarme, y la hice complicada y larga, pero es una sola). El programa no es mucho más que eso, pero también te permite relacionar campos con la clave (en qué sitio va, el nombre de usuario,etc), y también tiene campos genéricos donde uno puede escribir cualquier cosa. Ah, y también te autogenera claves... entonces, la realidad es que ni siquiera veo las alguna vez! Todo esto, sumado a la facilidad de uso (por ejemplo, ctrl-B sobre una entrada te copia el nombre del usuario, y ctrl-C te copia la clave) y que tiene clientes para muchas plataformas (incluida Android), hace que sea una herramienta maravillosa.

En la vida del programador hay una tarea que lleva bastante tiempo, y es la de correr tests, ya sean "unit tests" (pruebas unitarias) o "integration tests" (pruebas donde se hacen interactuar subsistemas entre sí).

Es cierto, no todos los proyectos tienen tests, pero deberían. ¡Y son un vicio! Una vez que los probaste, querés pruebas en todos los proyectos. Pero claro, a los tests hay que correrlos, y hay muchas maneras de hacerlo.

La verdad es que la estructura de los tests es siempre la misma (o casi siempre), obviamente hablando de proyectos en Python, pero la forma de correrlos, y especialmente la forma de presentar los resultados, varía mucho de un corredor de tests a otros.

A lo largo de años he probado distintos, y debo decir que ninguno cumple 100% con lo que a mi me gustaría tener en el test runner ideal. Por otro lado, seguramente alguno (como nosetests, por ejemplo), cumpla gran porcentaje de lo que quiero, es cuestión de lograr lo que falta.

Acá está la listita de las cosas que cumpliría mi test runner soñado. Propuse un proyecto en el PyCamp de este mes para laburar en esto (obviamente no escribir algo desde cero, sino lograr el objetivo con el menor esfuerzo posible).

Le puse un número a cada ítem para que sea más fácil referenciar en cualquier discusión:

1. Debería soportar que le pase un directorio (default a '.') y que descubra todo ahí y para abajo:

   $ <testrunner> project/tests/
   $ <testrunner>

2. Debería soportar que le pase un archivo, y que corra sólo los tests de ese archivo:

   $ <testrunner> project/tests/test_stuff.py

3. Debería soportar que le pase "paths de import de Python", y que corra sólo tests de ese paquete, módulo, clase, o lo que corresponda:

   $ <testrunner> project.tests
   $ <testrunner> project.tests.test_stuff
   $ <testrunner> project.tests.test_stuff.StuffTestCase
   $ <testrunner> project.tests.test_stuff.StuffTestCase.test_feature

4. Debería poder pasarle una regex para que corra sólo lo que re.search() encuentra en el path completo del método:

   $ <testrunner> project/tests/ --search feature
       correría:
           test_feature
           test_feature_1
           test_feature_2
       no correría:
           test_crash
   
   $ <testrunner> project/tests/ --search feature$
       correría:
           test_feature
       no correría:
           test_feature_1
           test_feature_2
           test_crash

5. Debería poder decirle que pare de correr los tests al encontrar el primer error o falla.

6. Debería poder indicarle que mida los tiempos de cada test (y al final que presente un reporte con los N tests que más tardaron).

7. Debería mostrar los resultados usando los nombres de paquete/módulo/clase/método, en una jerarquía de árbol o en la misma linea:

   $ <testrunner> project/tests/test_stuff.py
   project.tests.test_stuff
     StuffTestCase
       test_feature_1                      OK
       test_feature_2                    FAIL
     OtherStuffTestCase
       test_feature_A                      OK
   
   $ <testrunner> project/tests/test_stuff.py
   OK  project.tests.test_stuff.StuffTestCase.test_feature_1
   FAIL project.tests.test_stuff.StuffTestCase.test_feature_2
   OK  project.tests.test_stuff.OtherStuffTestCase.test_feature_A

   De cualquier manera, esto no afecta el órden de ejecución de las pruebas (secuencial, aleatoria, etc), sólo es cómo mostrar los resultados.

8. Los OKs deberían ser verdes; ERRORs y FAILs deberían ser rojos.

9. Los OKs/FAILs/ERRORs para cada prueba, en el listado, deberían estar alineados verticalmente.

10. No debería capturar stdout/stderr.

11. En el reporte final (luego del listado que va mostrando al ejecutar todo), debería mostrar el path completo del test que falla (o de los tests que fallan), junto con el (los) errores, de manera que si uno copia y pega ese path, sirva para correr ese único test.