Bitácora de Vuelo

Venimos atrasados con el procesamiento de fotos, pero acá ya tenemos los videos del cuarto y quinto mes de Felipe (click en la foto para verlos en YouTube).

Si quieren, pueden bajarlos de acá y acá con más resolución.

(Note: There's an English version of this report `here <http://www.taniquetil.com.ar/bdvfiles/testing.txt>`_)

Mandé este mail originalmente a la lista interna de Canonical donde discutimos temas técnicos:

"Testing" (o testeo, o realizar pruebas) es un terreno resbaladizo en el desarrollo de software. Es como dejar de fumar: todo el mundo sabe que es algo bueno, pero pocos tienden naturalmente a hacerlo.

Además tiene facetas muy diferentes: pruebas de unidad, pruebas de integración, interfaces gráficas. Incluso en las interfaces gráficas, no es lo mismo hacer pruebas en PyGTK, o en interfaces web.

Por ejemplo, yo estoy convencido de que debemos hacer pruebas cuando desarrollamos software, que es una buena manera de evitar (o minimizar) deuda técnica, y que no sólo te mejora la calidad del producto, sino que tiene características más difíciles de medir (como innovación: nadie va a tocar un proyecto grande que no tiene pruebas sólo para probar algo nuevo).

Pero, todavía tengo algunas dudas, y mucho que aprender en este campo. ¿Es valioso en todos los casos? ¿Cual es el balance correcto entre pruebas de unidad y pruebas de integración? ¿Y qué hacemos con las interfaces gráficas?

Y un tópico probablemente controversial: yo sé que tenemos que hacer pruebas, pero gente en mi equipo no, ¡ayúdenme a convencerlos!

En cualquier caso, es algo para hablar. Podemos arrancar una charla acá, y luego agendar un par de reuniones para cubrir algunos temas particulares, una vez que sepamos cuales, o quizás encontrarnos en el UDS para discutirlo personalmente.

Estoy seguro que dentro de Canonical "Testing" se usa en todos lados, y podemos aprender unos de otros.

Ideas? Preocupaciones? Experiencias?

Esto generó un gran árbol de discusiones, con un montón de puntos en los que todos estaban de acuerdo, y un montón que fueron un poco controvertidos.

Entonces, luego de que el polvo se asentó, escribí un resumen de toda la conversación:

Esto es una especie de resumen con conclusiones y comentarios del hilo sobre Testing de los últimos días.

Es mejor mostrar ventajas sobre algo a la gente que forzarlos a usarlo. Hay un par de situaciones "fáciles de ver" donde las pruebas de unidad son claramente algo bueno. Jamu K. agregó algunos puntos a lo que yo mencioné en el correo original:

• Te dicen cuando cometiste un error y rompiste algo. Cuanto antes detectes el error será más barato arreglarlo. Si un problema entra a un sistema en producción y afecta a los clientes, costará mucho en términos de satisfacción del usuario y tiempo para arreglarlo.

• Son material educativo que ayuda un principiante (o alguien experimentado) a entender la lógica en una manera que no es posible simplemente al leer el código mismo. Esto es especialmente verdad cuando las pruebas ejercitan condiciones de error que no se desprenden de forma obvia del código.

• Te ayudan a mantener una velocidad consistente. Es mucho menos probable que encuentres un problema que te haga perder dos días revisando y corrigiendo cuanto tenés buenas pruebas.

• Te permiten optimizar la implementación con la confianza de que no rompiste ninguna API. "Primero hacelo bien, luego hacelo rápido" es bastante duro, y lo es aún más sin buenas pruebas.

• Por definición, hacen que tu implementación se pueda probar. Te ayudan a entender cuando amontonaste demasiados detalles y te llevan a un mejor diseño.

Algunas ventajas son más conceptuales: muy claras a la gente que ya probó pruebas de unidad, pero no tan fáciles de ver para gente que realmente nunca lo hizo. Un ejemplo de esto es que diseñar para ser probado frecuentemente lleva a una mejor API (sin embargo, algunas veces lleva a una API más fea, porque estás forzado a agregar parámetros que sólo son útiles en un entorno de pruebas; como en todo, el equilibrio es el mejor de los consejos).

Una buena frase del hilo que me gustó como razón para hacer pruebas:

El código que estás escribiendo será usado por años. Será actualizado al cambiar los requerimientos. Y de vez en cuando, alguien que no es familiar al código como lo estás vos ahora estará en apuros para corregir un problema en él. ¿Qué previsión razonable podés hacer para ayudar a esa persona? Pensalo un minuto. Acordate, esa persona podrías ser vos.

¿Y qué desventajas hay? La gente a veces se queja de que si hacen pruebas, tardan más en escribir código. Sin embargo, lo que sucede es que las pruebas no cambian realmente el total de tiempo que toma desarrollar software, sólo cambia el cuando se paga ese costo. Sí, para software con pruebas, el beta inicial es mucho más completo y mejor probado, pero aparece más tarde en el ciclo, lo que puede ser un problema si no podés entregar ese código al usuario.

En todo el hilo, sólo se mencionó una desventaja real de TDD: puede pasar a veces que en lugar de realmente pensar profundamente un detalle del código, sólo lo vas toqueteando hasta que pasás las pruebas: esto puede llevar a código que esté menos pensado que lo que debería, ya que programás contra una luz verde, no contra un modelo mental limpio.

Hay que aclarar que no hay nada malo en no hacer TDD, pero que entrega resultados muy distintos con respecto a hacer las pruebas como corresponde, y se podría decir que al no hacer TDD los resultados son peores. ¿Está bien tener malos resultados? En algunos entornos, apuesto a que sí; sin embargo en Canonical queremos entregar lo mejor. Jamu lo dijo bien claro: si estás escribiendo código de producción sin hacer pruebas, entonces no estás haciendo tu trabajo correctamente. Mark S. lo reforzó con:

Deberíamos requerir pruebas para el código que somos responsables, y las excepciones que haya (seguro las habrán) necesitan justificarse y documentarse, no al revés.

Hacer pruebas es algo cultural, necesitamos encontrar cómo hacerlo crecer culturalmente: contratar gente que ya entienda y actúe con ese conocimiento, y entrenar a aquellos que todavía no tienen confianza en esto.

Hubo un montón de charla alrededor de hacer pruebas, pero nadie hizo distinción sobre que tipos de pruebas eran. Parece que las pruebas de unidad y de integración, o probar bibliotecas o interfaces gráficas, es todo lo mismo al discutir el tema.

Sin embargo, alguien preguntó específicamente sobre pruebas en interfaces gráficas. Realmente no sé sobre eso (¡quiero aprender!), pero creo que es un área menos conocida que las "pruebas sobre bibliotecas".

También se mencionó un tipo de pruebas que es raramente comentado fuera de los círculos de administradores de sistemas: cuando se maneja un servicio que se tienen que monitorear, es vital disponer de una manera de poder probar al servicio de manera frecuente y repetida tal que se pueda asegurar que sigue funcionando. Entonces, también se necesitan pruebas de reglas y procesos de negocios para los sistemas funcionado.

Hubo un poco de discusión acerca de las pruebas de documentación. "Doctests" son un buen material de aprendizaje para las bibliotecas, y pueden escribirse para mostrar funcionalidad y guiar por arriba a los usuarios. Pueden ser muy buenas para dar impresiones generales sobre el módulo.

Pruebas de documentación bien escritas son excelentes para documentar APIs, porque podés hacer que el conjunto de pruebas ejecute también aquellas, de manera de asegurarte que la documentación siempre permanece actualizada. Estás haciendo pruebas sobre la documentación, no usando la documentación para probar nada.

Quedó claro que las pruebas de documentación no reemplazan las pruebas de unidad, las complementan.

La discusión más grande del hilo fue sobre si TDD era útil en código experimental, o en etapas muy tempranas del desarrollo. Se aseguró que TDD funciona mucho mejor con códigos maduros que con código experimental. Esto se aplica también a características experimentales dentro de proyectos maduros. Básicamente se reduce a esto: si tenés una buena visión de lo que necesitás, escribir las pruebas primero te ayudan a señalizar el camino que vas a tomar. Si no tenés ni siquiera una buena idea de para qué dirección vas, TDD es un esfuerzo desperdiciado.

Esto generó algo de controversia, hasta que se explicó que "experimental" no es la mejor palabra para explicar que: estás en una fase de aprendizaje porque realmente estás tratando de entender mejor el problema. Una vez que entendiste el problema lo suficientemente bien como para tener una visión de la solución, volvés a TDD. Son realmente dos actividades distintas.

Esto normalmente sucede cuando la gente que escribe el código en modo "experimentación" sólo quiere ver si una idea loca va a funcionar o no, lo que muchas veces resulta en descubrir que todavía no se entiende el problema completamente.

Por otro lado, está la situación donde se necesita código en producción, y realmente no hay tiempo de hacer pruebas. Sí, ya sabemos, tendrá defectos, y a largo plazo es más caro, pero "lo necesitamos ya". Esto pasa en la vida real más veces que con las que estaría cómodo... Gustavo N. dijo algo que comparto completamente:

Si estás en una startup en una situación de vida o muerte (para la compañía), seguro... podés optar por ir realmente rápido, obtener un montón de mercado, y luego estabilizarte si resultó bien (mirá Twitter :-). Si sos parte de un contexto más grande (como nosotros), y tu producto no va a desaparecer pronto (ni la compañía que tiene una marca asociada con el producto), entonces estas rupturas pueden dañar realmente al producto y a la marca.

Entonces, como conclusión, por favor compartí sobre hacer pruebas en esta lista. Preocupaciones, ideas, tecnologías, si deberías o no hacer algo, etc.; este no es un tema donde todo es blanco o negro, o donde está todo dicho.

Si con el tiempo encontramos que es necesario una reunión para discutir algo (o incluso un grupo que se reúna regularmente), podemos ir a por ello. Mientras tanto, charlemos por acá.

Es que estuvimos programando...

... y luego me plantearon un desafío:

Más tarde nos relajamos leyendo...

... hasta que caímos exhaustos!

El jueves había una sensación general de cansancio y de que ya faltaba poco para que termine la semana.

Yo estaba igual. El día no ayudaba, frío, casi lluvioso. Luego de las sesiones me quedé un rato en la habitación, sin decidirme qué hacer... finalmente agarré la campera y bajé rápido para tomarme el bus hacia la ciudad, a ver si agarraba el último.

Por suerte sí, y encima me encontré con Nicolás Valcárcel, así que paseamos juntos. El bondi nos dejó en el medio de nada, pero al lado de una estación de subte. Ocho estaciones y estábamos en el centro de la ciudad.

Paseamos un rato para ver al famoso niño que hace pis (Manneken Pis), y de paso compramos cosas para llevar a nuestras familias, ya que entre esa estatua y la plaza central están todos los puestos para turistas. Comimos rápido por ahí (si no perdíamos el micro de regreso), y no tan tarde estábamos en el hotel nuevamente.

Ya en la habitación, me abrí una cerveza y me puse a trabajar en distintas cosas. Estaba cansado, y mi idea era irme a dormir temprano, pero al final me enganché con no se qué y me terminé acostando a las dos de la mañana.

El viernes no tenía nada en la primer franja, así que me levanté una hora más tarde (a las nueve y diez, así entre vestirme y desayunar llegaba bien a la sesión de las 10). La tarde la tenía casi libre, así que estuve laburando en mi habitación hasta que se hicieron las cinco, que arrancaba la ceremonia de cierre.

En la misma hicieron un anuncio que ya se había sugerido en otro momento, y que es una idea genial. ¿Saben cómo es 42 en binario? 101010. Bueno, Ubuntu Maverick Meerkat será liberado el 10/10/10, :D. Para los que 42 no les dice nada, les dejo este enlace.

Cuando terminó la ceremonia pasé por mi habitación a agarrar la raqueta, y me fuí a jugar al tenis con Guilherme Salgado. Fue un partido interesante, no sólo porque nuestro nivel era parejo (gané 6-3 6-1), sino porque jugamos sobre pasto sintético (nunca había jugado sobre pasto, y la verdad es que se nota la diferencia... la pelotita pica un poco menos, y sale disparada luego de hacerlo).

Luego del partido, me pegué un baño y me fui a la fiesta, donde entre cena, vino y cerveza, se desenvolvió el clásico All Stars, donde la gente se va turnando en los instrumentos para hacer música (generalmente rocanrol). Me terminé yendo temprano a dormir, porque entre el cansancio y la cerveza, no daba para trasnochar.

El sábado me levanté temprano, y aprovechando el micro que iba y venía a la estación de tren de La Hulpe, me fui para allá para pasear un rato. Caminé por la ciudad casi una hora, yendo y viniendo de la estación de tren a un pequeño centro comercial que habíamos visto con John cuando fuimos en bici al Carrefour. Ahí compré un par de libritos en francés para Felipe y Moni.

Volví al hotel con otro micro, y empecé la ceremonia de partida: revisé toda la habitación y dejé arriba de la cama todo lo que era mío, me bañé, armé la valija y la mochila, y bajé. Hice el checkout, esperé un par de horas en el lobby del hotel a mi micro para el aeropuerto, y luego partí de regreso a casa.

Sinceramente, el evento estuvo muy bueno. Más allá de encontrarme con mucha gente que conozco, es maravilloso ver como la comunidad de Ubuntu trabaja y trabaja para que todos tengamos un sistema operativo mejor, para cambiar el mundo un bit a la vez, algo que ya se está logrando, y lo mejor es que es de forma coordinada con otras comunidades.

Relacionado con eso les dejo un enlace a este video que fue presentado por Jono Bacon en la apertura del UDS (yo lo había subtitulado, pero eso lo perdí, una lástima porque la letra cierra mucho con las imágenes que muestran). No dejen de verlo.

Para cerrar, pueden ver todas las fotos del UDS acá.

El lunes nos levantamos tempranito con John, bajamos a desayunar tipo ocho y veinte, y estábamos a las nueve listos para la apertura del evento a cargo de Jono Bacon, y luego una keynote de Mark Shuttleworth.

Durante el día estuve en varias sesiones, algunas me gustaron más, otras menos, en algunas aprendí, en otras participé, etc. Nada realmente maravilloso.

La parte de sesiones de UDS terminó a las seis de la tarde, y seis y media ya estábamos con John alquilando unas bicis: fuimos hasta el pueblo cercano, al supermercado. El paseo estuvo fantástico, pero la verdad es que las subidas y bajadas del terreno nos mataron... pasábamos de una punta a la otra de los cambios de la bici, en la bajada alcanzábamos casi la velocidad de la luz (?), pero en la subida sufríamos.

Llegamos, acomodamos las cosas en la heladera, y bajamos a tomar una cerveza y charlar con la gente. Más tarde ya volvimos a la habitación, cenamos, laburamos un rato, llamé a casa y a mi hermana que cumplió años, y luego a dormir.

Ya que menciono lo de llamar a casa... hablé más de 10 minutos por Skype, de Bélgica a Argentina, y gasté 30 centavos de dólar. En comparación, Movistar me cobra 29 centavos de dólar + IVA por mandar un sólo SMS! Si alguna vez tienen que viajar, la opción de usar Skype para comunicarse hace todo mucho más barato.

El martes costó más levantarse, pero arranqué temprano igual. La mañana la pasé en distintas sesiones, normal.

La tarde fue distinta: nos juntamos todos los de Ubuntu One en una habitación grande, y todos los que tenían algún problema venían y se lo solucionábamos. Yo manejé tres casos... el primero, tenía la metadata corrupta (el usuario mismo protestaba que esa computadorita que tenía se le colgaba siempre y se le jodían los archivos, más allá de los nuestros); el segundo, cuando me fue a mostrar el problema, funcionaba todo perfectamente, :); y el tercero, al que realmente no le funcionaba todo perfectamente, era porque el servicio todavía es lento en algunos casos (y él había tirado miles de archivos y nunca terminaba), así que tocamos algunas cosas para sacarlos, y dejarlo "sano", para que vaya agregando otra info que le interesaba más.

Luego de las sesiones de UDS misma, la idea era irme a jugar al tenis con Rodrigo, pero lloviznaba, así que me puse el short y me fui a la pileta del hotel, hice algunos largos, me metí cinco minutos en el sauna, y volví a la habitación como nuevo. Me pegué un baño y bajamos a tomar una cerveza con John y Achuni.

Luego los chicos y un par más arrancaron un juego de Illuminati, yo me quedé un rato viéndolos y aprendiendo las reglas y dinámica del juego, y luego volví a la habitación y me fui a dormir.

El miércoles también fue un día de sesiones y sesiones, pero aproveché para salir a caminar. Como el último turno de la mañana terminó temprano, aproveché para comer rapidito y salí a recorrer un poco el bosque de alrededor del hotel.

Comentario del hotel: está muy bien, moderno, elegante, muy luminoso, rodeado de unos bosques maravillosos. Lo mejor: el servicio de wifi; andaba en todos lados, con una velocidad maravillosa, podías pasearte por todo el hotel y que no se desconectara, no tuvo problemas. Lo peor: el diseño del baño; estaba como separado en tres partes... un inodoro (sin bidet!), el cual tenía puerta, la pileta que daba directamente al pasillo, y la bañadera/ducha que tenía una especie de mampara que cubría la mitad de la misma... pero dejaba entrar todo el frío que venía desde la parte de la pileta, que no tenía puerta que la separe del resto de la habitación.

A la noche también salí a caminar, pero esta vez por la ciudad. Aproveché los micros hotel-ciudad, y pegué una vuelta de hora y media antes de que se terminara la luz. La ciudad me pareció aburrida... quizás porque es bastante gris y estaba muy nublado, pero lo más probable es que fuese porque estaba todo cerrado.

Bueno, no todo. Había varios restaurants y muchos pubs que todavía estaban abiertos, pero todo el resto de negocios (cafés, librerías, negocios de ropa, negocios de regalos, casas de discos, etc, etc, etc.) esta cerrado. Parece que si trabajás, no podés comprar nada en esta ciudad, porque el horario de todos los negocios es (más o menos) de 10 a 18:30, algunos cerrando un rato al mediodía también. Incluso pasé por un teatro que decía que el día que tenían función "nocturna" el horario era extendido: hasta las 20:30!

Anyway.... volví medio decepcionado al hotel, fuimos al gym con John (hice cinta y algo de bici), luego cenamos, laburamos un rato y terminó el día. |