Cadenas y Tuplas

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

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

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?

Sun/Oracle Java y OpenJDK con apache y mod_jk

Esta semana he estado trabajando en la configuración de dos servidores iguales. En ambos casos los servidores tendrán un Apache que pasarás las peticiones a un Tomcat 6. Siendo los servidores (casi) idénticos con las mismas configuraciones en Apache y Tomcat me encontré con que uno de ellos, después de diez minutos de haber arrancado el servicio tomcat comenzaba a consumir el 100% de la CPU y se quedaba en un estado en el que no devolvía ninguna petición. Pensé que se debía a las tareas de arranque, pero el comportamiento no cambiaba en el tiempo. Por contra el otro no presentaba este comportamiento.

Tras dar muchas vueltas, mirar en muchos sitios de Internet, vi que las versiones de Java eran distintas. Uno de los servidores usaba la versión oficial de Sun/Oracle mientras que el otro estaba usando la versión abierta OpenJDK. Lo curioso del caso es que el que funciona como se esperaba es el que utiliza OpenJDK. El servicio en producción utilizará OpenJDK y esto es algo que nunca antes había hecho. Esperemos que salga bien.

Ciclo de vida de los proyectos

Una de las cosas que más he echado de menos de mi formación en mi vida profesional es la importancia del ciclo de vida de los proyectos. Durante la carrera, al menos en la ULL, todo se centraba en conseguir desarrollar un (pequeño) proyecto. Durante los primeros años se centraban en enseñarnos a programar, después nos enseñaron algunas metodologías de programación clásicas, como Métrica 3 o el modulo en cascada, y en algunas asignaturas nombraron de pasada las metodologías ágiles. Sólo en unas pocas asignaturas se desarrollaban proyectos algo mayores, y en estos casos el objetivo se centraba más en enseñarnos algún área de conocimiento como procesamiento de lenguajes.

Sin embargo al llegar al mundo laboral, con esa idea interiorizada de conseguir sacar el proyecto adelante sin importar la calidad y mantenibilidad del código escrito, me topé con que, en la vida real, un proyecto siempre había que modificarlo a posteriori. Cuando tienes interiorizada dicha idea y tienes que modificar un proyecto sigues haciendo lo mismo, con lo que pones un parche. Después de un número de parches el código es una superbazofia que no hay Dios que mantenga. Es lo que se conoce como Legacy Code (código que cumple las expectativas del cliente, pero es caro de mantener). Si se prestase más atención a la calidad de código, en lugar de ir poniendo parches sin ton ni son, se refactorizaría, haciendo que las modificaciones se integrasen dentro del proyecto de un modo más natural y por tanto permitiendo una mejor mantenibilidad. Esto es Beautiful Code. Es muy difícil enseñar esto en una facultad, pero no por ello debería dejar de intentarse.

Estudié cuatro asignaturas relacionadas con la ingeniería del software (es posible que me equivoque en algún nombre):

• Ingeniería del software de gestión I (donde nos enseñaron métrica, el modelo en cascada y otras metodologías clásicas)
• Ingeniería del software (aquí no tengo claro lo que aprendí)
• Gestión de sistemas de información (utilizando el PMBOK como base nos enseñaron cómo se debían gestionar los proyectos de los sistemas de información)
• Laboratorio de ingeniería del software (desarrollamos un pequeño proyecto en equipos para una empresa)

De todas estas Ingeniería del software es probablemente una de las asignaturas menos útiles que he cursado nunca, el resto en general son bastante útiles, pero, al ser asignaturas cuatrimestrales, no se llega a comprender cómo de importante es el ciclo de vida.

Ahora mismo estoy siguiendo un curso llamado Software Engineering for Sofware as a Service. En él se enseñan metodologías ágiles, para comprender el ciclo de vida, es mejor tener un ciclo corto. Creo que este curso podría ser un ejemplo a seguir para alguna de las asignaturas que he mencionado con anterioridad. Por un lado se desarrolla un proyecto de manera iterativa, por otro lado un cuatrimestre permite ocho iteraciones de dos semanas o dieciseis iteraciones de una semana. Además las metodologías ágiles se están consolidando cada vez más en proyectos con clientes, puesto que se adaptan mucho mejor al cambio y los clientes nunca saben lo que quieren. Si lograsen que los alumnos de las distintas asignaturas relacionadas con ingeniería del software pudieran trabajar juntos asumiendo en cada caso el rol que corresponda en el equipo a la asignatura que estén cursando estoy seguro de que sería tremendamente positivo.