Mi primera auditoría de código: revisando scikit-aero

Introducción

Como ya sabéis Javier Gutiérrez, profesor de la Universidad de Sevilla, está escribiendo una serie de entradas en Pybonacci sobre desarrollo dirigido por pruebas en Python, que os animo a leer si no lo habéis hecho todavía. Pues bien, después de conocernos en la PyConES rescatamos la idea de aplicar estos conceptos a problemas no tan genéricos y más cercanos al software científico que escribimos nosotros. Fruto de esta idea Javier se ha tomado la molestia de revisar nuestra biblioteca scikit-aero, y ha escrito una entrada en su blog sobre el proceso:

Como comenté en la entrada Auditorias de código o aprendamos juntos a ser mejores, una de las cosas que más me gusta hacer es analizar código de otras personas para aprender y también para aplicar la regla del buen boy scout e intentar contribuir a que ese código sea un poquito mejor.

El último proyecto que he analizado por el momento ha sido ha sido Scikit-Aero en Github del fenomenal Juan Luis Pibonacci que lleva el proyecto del blog Pybonacci (enlace) y en el que colaboro son una serie de entradas sobre TDD / Desarollo Dirigido por Pruebas.

En este artículo voy a contar brevemente cómo las cosas que he aprendido 🙂

Sobre scikit-aero

scikit-aero es una pequeña biblioteca Python que escribí mientras estudiaba flujos isentrópicos, ondas de choque, expansiones de Prandtl-Meyer y similares en una materia llamada «Aerothermodynamics». Es, por tanto, algo bastante específico. De ella me serví por ejemplo para producir este diagrama:

Diagrama de ondas de choque oblicuas
Diagrama de ondas de choque oblicuas

Podéis consultar el código en este notebook de ejemplo. Mi idea era además tratar de crear un código bien documentado, bien estructurado y bien probado.

Continue reading

Desarrollo Dirigido por Pruebas en Python (II). Un Caso Práctico (I)

A principios de año escribimos una entrada que puedes leer aquí. Después de un parón más largo de lo previsto, volvemos a la carga con el desarrollo dirigido por pruebas en Python.

Vamos a utilizar TDD y el módulo unittest para crear una aplicación que se conecte a twitter, recupere los mensajes de un hashtag y almacene parte de los mensajes en un fichero. El nombre del fichero será la fecha actual y el hashtag. El fichero contendrá la información de cada tweet separada por comas.

Dividiremos este ejemplo en varias entradas. En cada entrada, desarrollaremos una parte de la aplicación a medida que aprendemos distintas técnicas y buenas prácticas para aplicar TDD. En la primera entrada empezaremos con la aplicación y veremos algunos aspectos clave de la aplicación de TDD.

El diario de diseño

Vamos  comenzar creando el diario de diseño. Este diario es la lista de tareas que tenemos pendientes (una to-do list) de hacer cómo código a escribir o funcionalidad a implementar y nos va a servir para mantenernos en todo momento con el foco centrado. Utilizamos el diario cuando ya tengamos una funcionalidad implementada (y gracias a TDD probada) para decir la siguiente y cuando, durante un ciclo de TDD, se nos ocurra nueva funcionalidad o nuevas condiciones a implementar en nuestro código. Vamos a ver las tareas que tenemos que hacer en el cuadro 1.

Cuadro 1. Diario de diseño.
1) Conectarse a Internet y obtener los mensajes que contengan un tag concreto.
2) Procesar los tweets para obtener el nombre y dirección twitter del autor, la fecha y el contenido del tweet.
3) Guardar la información anterior en un nuevo fichero.
4) Crear una interfaz de usuario por línea de comandos.

Para empezar a escribir código elegimos una de las tareas anteriores, la que queramos. No tenemos que imponernos un orden ni pensar que tenemos dependencias. En su lugar elegimos la tarea que consideremos más importante, más arriesgada, más rápida de implementar, etc.

Continue reading

Desarrollo dirigido por pruebas en Python (I): Una historia que pasa todos los días

Vamos a iniciar una serie de artículos sobre desarrollo dirigido por pruebas en Python (TDD en inglés) con el objetivo de acercarlo a científicos e ingenieros. En el primero presentaremos la idea principal del desarrollo dirigido por pruebas, y para ello empezamos una pequeña historia:

Una empresa de desarrollo de productor de jardinería a medida, GardenTech, tiene un nuevo cliente, el señor Sellers. La reunión de requisitos podría ser algo así:

Ingeniero GardenTech: Buenos días señor Seller, díganos qué es lo que necesita.

Sellers: Necesito una manera de poder regar mis plantas.

GT: Podemos ayudarle, tenemos mucha experiencia en ese campo. ¿En qué ha pensado?

S: Tengo 5 macetas, así que me gustaría llevar el agua para allá y echársela.

GT: Perfecto, le pondremos a su aparato un agujero grande para que pueda llenarlo de agua y muchos pequeñitos para que no tronche las flores.

S: Pero ¿y si se me cae?

GT: Tranquilo, la usabilidad es nuestra especialidad, le añadiremos un asa para que pueda manejarlo y no será muy grande para que no pese.

S: ¿no será grande? Entonces igual lo pierdo.

GT: Todo está pensado, le daremos un color rojo brillante para que pueda encontrarlo a simple vista.

S: ¿Y si me mojo?

GT: Los agujeros pequeños estarán alejados del dispositivo mediante un tubo.

S: Perfecto, veo que piensan en todo.

GT: Somos buenos.

El señor Sellers y GardenTech están de acuerdo  en los requisitos que debe tener el artefacto, y GardenTech comienza a desarrollarlo. Un mes después la empresa llama al seños Sellers. En medio de la sala de reuniones hay una mesa con un bulto cubierto por una sábana.

Continue reading