Generando “fixtures” con sentido

April 25, 2012

Una de las cosas que menos me gusta de trabajar con Django es la generación de datos de prueba. Habitualmente cuando desarrollamos aplicaciones más o menos sencillas tenemos un servidor de explotación o producción, un servidor de pre-explotación o pre-producción y máquinas de desarrollo. Cuando la aplicación ya tiene cierta entidad, se hace necesario disponer de un conjunto de datos que podamos usar para comprobar el correcto funcionamiento de las distintas características ya sean nuevas o no. Además estos datos son también necesario para poder ejecutar los tests. Nunca he encontrado un mecanismo suficientemente bueno para, coger datos de producción, y pasarlos a los entornos de pre-producción o desarrollo.

He inspeccionado un poco por encima las alternativas que se muestran en Django Packages, pero ninguna me termina de parecer del todo buena. Muchas están centradas en la generación de datos para tests, que es tremendamente interesante, pero no es exactamente lo que estoy buscando.

A mi me gustaría tener un mecanismo mediante el que pudiera elegir unos cuantos objetos, y simplemente que todos los related a dichos objetos “vinieran” con ellos. De este modo si estuviera trabajando en un sitio en el que existiesen distintos tipos de roles, podría elegir un usuario de cada rol, y generar un conjunto de datos que me permita comprobar que cada uno puede hacer lo que se supone que puede hacer.

Alguien había publicado este snippet, pero no funciona debido a que utiliza partes internas de la api de django y cambiaron en la versión 1.3, así que me puse manos a la obra e hice lo mismo utilizando los mecanismos que existen ahora para hacer eso.

Este código es una acción para la interfaz administrativa, que se puede hacer disponible “site-wide”. Lo que hace es, dada una lista de objetos (qs), calcular la lista de objetos que se borrarían a través de “on cascade”, etc. Utiliza ese mecanismo, así que si se modifica el comportamiento ante borrado de un modelo probablemente no funcione adecuadamente.


Cadenas y Tuplas

April 24, 2012

Esta tarde he estado trabajando en una aplicación y me ha ocurrido una cosa curiosa, no es que no me hubiera ocurrido antes, pero no me había llevado tanto tiempo darme cuenta.

>>> a = "NIF"
>>> type(a)
<type 'str'>
>>> a = "NIF",
>>> type(a)
<type 'tuple'>

La moraleja de la historia es que una coma, puede tener entretenido veinte minutos.

No obstante, estoy seguro de que volveré a tropezar en la misma piedra.


La historia se hace como se puede

April 20, 2012

Decía hace unos días la presidenta argentina Cristina Fernández de Kirchner que la “Historia se hace como se puede”. Esto unido a que los últimos días he podido rescatar mi faceta como desarrollador me ha hecho darme cuenta de que tiene razón. Siempre pensé que soy más un desarrollador que un administrador de sistemas o de servicios, pero en mi vida profesional esta última faceta siempre ha sido más importante que la primera.

Desde hace unos meses cuando dejé Galotecnia, no he podido dedicarme en profundidad a desarrollar, que es lo que realmente me apasiona, pero esto ha cambiado en las últimas semanas. Ayer fue uno de los días en los que más he disfrutado de mi trabajo en los últimos meses.

Como siempre sigo “picando” Django, y la aplicación que me ocupa está muy dirigida por los datos (data-driven) esto hace que haya que buscar un mecanismo para poder pasar de pre-explotación a explotación con nuevos datos. Básicamente se me ocurren tres aproximaciones:

  • Utilizar initial_data
  • Utilizar south
  • Utilizar scripts fabric

En condiciones normales me decantaría probablemente por las “data-migration” de south, pero la aplicación utiliza una base de datos no soportada (no preguntes), así que esto representaba una gran oportunidad para trabajar con fabric. Aunque fabric no está diseñado exclusivamente para esto su integración don Django permite importar los modelos y crear las entradas que sean necesarias. Anteriormente teníamos unos scripts hechos en una mezcla entre python y bash para cargar algunos datos, pero estos no estaban actualizados, así que ahora ya podemos usar fabric para eso.

Por otro lado he podido probar bootstrap que es algo que llevaba algún tiempo queriendo hacer. Yo no soy un diseñador y contar con una herramienta como esta me parece muy positivo. Sin embargo creo que no voy a poder profundizar mucho en esta herramienta con este proyecto. Ya habrá más proyectos!.

Hoy me toca seguir trabajando en este proyecto. En principio tendré que llamar a un procedimiento almacenado en una base de datos Oracle que es algo que tampoco he hecho nunca, aunque he leído que es relativamente sencillo

Una cosa “chula” que hice ayer fue implemenar un Mixin que permite validar un NIF, NIE o CIF español. En “django.contrib.localflavor.es” hay un tipo de form field que permite hacer esto (aunque creo que la validación del NIE es incorrecta), pero en mi formulario se almacena por separado el tipo de documento identificativo y el propio documento. Hice un pequeño mixin que contiene un método clean que tiene en cuenta todas las posibilidades, las clases que hereden de forms.ModelForm o forms.Form y este mixin pueden aprovechar esta validación lo cual, teniendo en cuenta que se usa en varios formularios por toda la aplicación, es muy deseable.


Documentación de proyectos

April 12, 2012

Llevo un tiempo trabajando en el despliegue de JASIG CAS. Como neófito en aplicaciones web desarrolladas en Java me ha costado bastante comprender cómo se hacen algunas cosas en este entorno. Sin embargo una vez que hemos concluido con éxito el proyecto, debo decir que echo de menos una documentación del proyecto adecuada. La documentación se gestiona mediante un wiki, el problema es que se mezcla información para diferentes versiones del proyecto sin ningún tipo de control. Varios de los errores que he tenido que enfrentar se han producido porque la documentación del wiki hacía referencia a una versión obsoleta.

Anteriormente he trabajado con otros productos de software libre donde la documentación está a un nivel altísimo. Por nombrar dos pondré Django y QT. La documentación del proyecto es muy importante para su éxito en un entorno de software libre evolutivo. Creo que el éxito de las buenas documentaciones viene por evolucionar con el proyecto. ¿Qué buenos mecanismos de gestión de la documentación conoces?