Mes: marzo 2013

Caso de éxito: sistema de gestión de trabajos prácticos

Hace un tiempo comenté sobre el sistema de gestión que estábamos por estrenar en Algo3. Bueno, lo estrenamos y fue un éxito rotundo. El sistema nos permitió corregir en forma automática más de 150 entregas.

Básicamente el trabajo práctico tenia como objetivo que los alumnos se familiazaran con el entorno de Pharo y la sintáxis de Smalltalk. Para ello les dimos un script con un conjunto de pruebas unitarias y los alumnos debían escribir todo el código necesario para que dichas pruebas se ejecuten exitosamente. Una vez escrito el código, los alumnos tenian que registrase en el sistema y subir el código escrito. Entonces el servidor se encargaba de correr el script de prueba e informar el resultado de la entrega via mail. Luego, una vez completada exitosamente la corrección automática, los docentes teniamos la posibilidad de navegar el código de los alumnos y realizar una corrección manual enfocada en cuestiones de diseño.

Con este hito, los alumnos que desarrollaron el sistema de corrección, obtuvieron la aprobación de su trabajo profesional de ingenieros en informática (aún restan ajustar algunas cosillas menores y algunos trámites administrativos, pero la parte «dura» ya está).

En las próxima semanas estaremos trabajando en ajustar algunos detalles del producto de cara a liberarlo formalmente como herramienta open source. Al mismo tiempo, ya estoy trabajando en armar un nuevo backlog para continuar trabajando con otros alumnos que quieran recibirse haciendo un aporte a esta herramienta.

Inclusión de métodos ágiles en las carreras de informática

En este post quiero tratar un tema que estuve trabajando la semana pasada en los talleres que participé en Medellín.
Según mi visión, a la hora de diseñar una carrera de informática existen distintas alternativas para incluir los métodos ágiles. En una simplificación extrema podriamos hablar de un enfoque conservador y otro innovador.

El enfoque conservador podria consistir simplemente en agregar una materia sobre métodos ágiles (posiblemente hacia el final de la carrera) y mantener el resto del plan sin mayores modificaciones.

Por otro lado, el enfoque innovador sería repensar la carrera completa incluyendo temas de agilismo en diversas materias. De esta forma se podría incluir Scrum en la materia de gestión de proyectos, TDD en las materias de diseño/programación, BDD y User Stories en las materias de análisis/requerimientos y así sucesivamente.

Si bien el enfoque innovador puede parecer más difícil de implementar, la realidad es que no siempre es así. Un claro ejemplo es lo que ocurre en FIUBA. Si bien los planes de estudio actuales no hacen referencia explícita a métodos ágiles, varios profesores han incluido temas de métodos ágiles en sus respectivas materias por iniciativa propia. Claro está, que esto es pura informalidad ya que la inclusión de los temas está sujeta por completo a la iniciativa de cada docente. Pero también es cierto que es una implementación «rápida», ya que no require de todo el trámite burocrático que puede implicar el modificar un plan de estudios. En FIUBA los temas de agilismo se empezaron a dictar hace ya más de 6 años por iniciativa de algunos docentes. Hoy por hoy, más docentes se han sumado a esta iniciativa y los nuevos planes de estudio (que están en proceso de aprobación) ya incluyen formalmente estos temas que en la realidad se vienen dictando hace varios años.

Cómo hacer pruebas automáticas sin xUnit

Hace un tiempo en un webcast de la comunidad ágil de Venezuela mencioné la importancia de que todo programador sea responsable de escribir las pruebas unitarias de su código, lo cual es absolutamente independiente del lenguaje de programación utilizado ya que para hacer pruebas no es necesario contar con ninguna herramienta particular. Ante esta afirmación una persona de la audiencia consulto ¿afirmas que es posible escribir pruebas unitarias sin usar un framework de pruebas unitarias? La respuesta es si. Veamos un ejemplo.

Básicamente una prueba unitaria consta de 3 pasos conocidos como las 3A.

  • Arrange: es la preparación de todo lo necesario para realizar la prueba
  • Act: es la ejecutación de la prueba
  • Assert: es verificación de que el resultado obtenido es acorde a lo esperado

De estos tres pasos el único que depende del framework de pruebas unitarias es el assert. Generalmente el framework de pruebas unitarias provee uno o varios métodos del tipo assertXXXX que verifican el valor de verdad de una expresión y en base a ello arrojan un resultado.
Esta funcionalidad del assert de framework de pruebas unitarias bien podría ser reemplazada por una función similar a la siguiente

public void verificar(boolean expresion){
  if(!expresion)
    throw new RuntimeException();
}

Vemos cómo podríamos utilizar esta función para hacer un prueba de la clase ArrayList.

public void deberiaCrearseVacio(){
  // arrange & act
  ArrayList array = new ArrayList();
  // assert
  verificar(array.size()==0);
}

Para aquellos interesados en profundizar, aquí les dejo un ejemplo completo en Java que muestra como codificar y ejecutar las pruebas.

Agilizando Medellín

Por estos dias me encuentro en Medellín dictando un par de talleres sobre adopción de métodos ágiles en la academia. Esta actividad es una iniciativa de Ruta N, un organismo creado conjuntamente por la alcaldía de Medellín y otras organizaciones (tanto del sector público como privado) para promover el desarrollo de negocios innovadores basados en tecnología.

Esta iniciativa tiene como objetivo promover/facilitar la inclusión de los métodos ágiles en los planes de estudio de las carreras de informática. De la iniciativa estan participando 6 universidades entre las que se encuentran la Universidad Nacional de Colombia, la Universidad de Medellín y el Politécnico Colombiano.

Continuará…

Sistema de gestión de trabajos prácticos

A mediados del año pasado se me acercaron dos alumnos de FIUBA, con la intención de que los dirigieran en el desarrrollo de su trabajo profesional de fin de carrera. La propuesta que traían no me convenció, pero en lugar de decirles que no, les hice una contra oferta y trabajar en una idea que tenia en mente desde hace un tiempo: una herramienta de gestión para de trabajos prácticos de programación. La idea no era del todo novedosa, pues ya había en nuestra misma facultad dos materias que ya tenian un sistema similar. Al mismo tiempo, puse una seria de condiciones respecto del producto final y de la forma de trabajo:

En cuanto al producto, pedí las siguientes cuestiones

  • Pruebas unitarias y de aceptación automatizadas
  • Alto porcentaje de cobertura
  • Cumplimiento de las convenciones de código del lenguaje utilizado
  • Implementación con tecnologias abiertas

Respecto de la forma de trabajo les pedí:

  • Enfoque iterativo incremental con iteraciones semanales
  • Proceso de trabajo tipo Scrum
  • Visibilidad contínua

Con buen criterio los muchachos se tomaron un par de dias para pensarlo y finalmente aceptaron.

Hoy al cabo de 21 iteraciones, estamos a punto de salir en producción. Estamos arrancando el cuatrimestre y vamos a utilizar el sistema para gestionar los dos primeros trabajos prácticos de este cuatrimestre.

En próximos post compartiré más detalles del proyecto.

Continuous Delivery, una visión de alto nivel

No quiero entrar en detalle sobre definiciones, beneficios e impedimentos relacionados a esta práctica. Creo que hay suficientes fuentes de información en la web al respecto (con solo googlear el término continuous delivery encontraremos alrededor de 18.000.000 resultados).

Asumiendo que el lector ya está familiarizado con las definiciones básicas, quiero compartir mi visión de esta práctica.

Un concepto central en la práctica de continuous delivery es el denominado Deployment Pipeline. El mismo modela el proceso de la organización para materializar la implementación de una idea/necesidad del negocio. Dos puntos a destacar:

  • Hablamos de organización y no de equipo, porque este proceso involucra varios sectores de la organización más allá del equipo de desarrollo.
  • Hablamos de materializar una idea/necesidad de negocio. No basta con que el software esté desarrollado, la necesidad no se resuelve con el código dentro de un repositorio o en un paquete .zip, sino con el software corriendo en un ambiente donde pueda ser utilizado por el cliente.

La primera parte de este este Deployment Pipeline debe darlo el equipo de desarrollo con la implementación de la práctica de integración continua, lo cual puede llegar a ser un interesante desafío si el equipo trabaja sobre código legacy (entiéndase legacy=sin pruebas). Aquí es importante destacar que incorporar la práctica de integración continua va mucho más allá de poner un Build Server a monitorear el repositorio, compilar el código y ejecutar los tests.

La segunda parte del Deployment Pipeline es la que involucra a otros sectores de la organización, pues es la parte que recorre los distintos ambientes hasta llegar a producción.

Agile en la academia, mi experiencia

En este tema tenemos dos cuestiones:

  1. La aplicación de técnicas agile en la enseñanza (más allá de cual sea la materia de estudio)
  2. La enseñanza de agile como un enfoque de la ingeniería de software.

En mi caso tengo experiencia en ambas cuestiones.

En Algoritmos y Programación 3 (Universidad de Buenos Aires) nuestro foco de estudio es la programación orientada a objetos pero incluimos en el programa de la materia algunas prácticas comunes en el movimiento agile como ser TDD e integración contínua. Esto se debe a que en la actualidad no concebimos la construcción de software orientado a objetos sin el uso de estas prácticas.

Por otro lado, en Elementos de Ingeniería de Software (Universidad Nacional de Quilmes) el enfoque de ingeniería que enseñamos es el enfoque Agile. Es necesario mencionar que el objetivo de esta materia es proveer, a un técnico en programación, herramientas suficientes para llevar adelante el desarrollo de un sistema de software. La discusión de porqué el enfoque Agile y no otros, es tema de otro post. Al mismo tiempo la forma en que se dicta la materia tiene varias técnicas de agiles como ser:

  • La materia se encuentra dividida en iteraciones, al final de cada una los alumnos presentan un entregable y se realiza un retrospectiva sobre la forma en que se ha dictado la materia
  • El entregable puede ser un informe, software, un documento de diseño o una evaluación
  • Los alumnos se auto organizan para llevar adelante las distintas asignaciones
  • Cada alumno lleva un backlog de sus tareas, que es priorizado por el docente y estimado por cada alumno
  • Si al final de la iteración el entregable de un alumno no cumple con el criterio de done previamente acordado, entonces el docente puede decidir:
    • «cancelar el proyecto», lo que básicamente significa que el alumno ha pedido la materia)
    • agregar al backlog items distintos o adicionales para compensar/suplir el entregable incompleto

Asimismo hay dos cuestiones que nos parecen centrales más allá del enfoque agile:

  • Los proyectos de software se desarrollan dia a dia y eso mismo hacemos en la materia. Hay que trabajar todas las semanas. Esto resulta en ocasiones «chocante» para los alumnos que muchas veces están acostumbrados a simplemente asistir a clase y sólo trabajar/estudiar la semana previa a un exámen. 
  • Un factor importante para el éxito de cualquier proyecto es la comunicación y el manejo de expectativas. Durante toda la materia hacemos mucho incapié en esto. Por eso, si un alumno piensa no asistir a una clase, tiene la obligación de avisar previamente al resto de la clase. No hace falta que dé explicaciones, simplemente decir «No asistiré a clase». Esto permite que el docente puede planificar mejor las actividades de la clase sabiendo con cuantos alumnos contará.

Aqui dejo algunos links a posts anteriores que agregan más información sobre lo mencionado aquí:

Nota: este post surgió a partir de una consulta de mi colega Juan Gabardini quien me mencionó una iniciativa de gobierno de Medellín para la enseñanza de método ágiles en las universidades. Gracias Juan.

Estudio de radio casero al alcance de tu mano

La tecnologia ha evolucionado y los costos han bajado radicalmente, permitiendo que cualquier hijo del vecino pueda hacer su propia radio por internet. La infraestructura más básica consisten en:

  • Una computadora con placa de sonido con entrada para microfono
  • Una conexión de banda a ancha de internet
  • Un micrófono

A nivel de software necesitaremos:

  • Windows XP o superior
  • Zara Radio (programa gratuito para operación de radio)
  • Winamp con el plugin Shoutcast (también gratuito)

Finalmente, el último componente es el servicio de streaming, el cual se encarga de tomar nuestra transmisión y ponerla disponible en el ciberespacio. El costo de estos servicios varia según la capacidad de streamming deseada. En la actualidad uno puede comenzar con un servicio con capacidad para 100 oyentes simultáneos por alrededor de $ 100 (pesos argentinos).

La forma en que todos estos componentes interactuan es:

  1. El micrófono se conecta a la computadora que a su vez está conectada a internet
  2. Se ejecuta Zara Radio que permite elegir las canciones/audios a reproducir y también permite activar el micrónofo
  3. Se ejecuta Winamp con el mencionado plugin, que tomará la salida de audio generada por Zara Radio y la enviará al proveedor de steamming.
  4. El proveedor de streamming tomará nuestra señal y la pondrá disponible para los usuarios en una URL de su propiedad

Esto es todo, 1, 2, 3, ¡al aire!