Autor: NicoPaez

To Heroku or not to Heroku

Hace un tiempo estuve escribiendo sobre el Proyecto CMS. Actualmente continuo trabajando en dicho proyecto y en estos dias estamos analizando en que plataforma hostear la aplicación. En este momento la aplicación está corriendo en Heroku, pero hay ciertas cuestiones que están ocasionando issues de performance. Ello llevó a que hicieramos una prueba de concepto levantando la aplicación en Linode.

Personalmente creo que las cuestiones de performance de la aplicación no tienen que ver con donde está hosteada sino con ciertas cuestiones de diseño y configuración. Al mismo tiempo, el pasaje de una plataforma como Heroku a otra plataforma del estilo Linode o Amazon EC2 implica un incremento importante en el costo de operación (al menos en un principio hasta que uno logra automatizar parte del trabajo).

Estimo que en las próximas dos semanas estaremos tomando una decisión respecto a esto (en realidad yo no tomo ninguna decisión, simplemente doy mi opinión).

Continuará…

¿Cómo enseñamos a programar?

Cada vez estoy más convencido que la programación es un oficio y como todos los oficios se aprende haciendo. Pero no haciendo en soledad sino con un maestro. Pensemos en un carpintero ¿cómo se forma? ¿leyendo libros? Tal vez, si, es posible que lea algún libro, pero no es su principal formación. Su principal formación es trabajando la madera junto a un carpintero ya experimentado, quien le va enseñando los gajes del oficio. Pero si miramos la forma en que suele enseñarse a programar lejos está de esto.

No hay diferencia entre universidades, institutos terciarios o centros de capacitación privados, en general todos siguen el mismo esquema. El alumno asiste a un curso donde el docente ofrece algún tipo de explicación inicial y luego le dá a los alumnos ejercicios para que resuelvan. Luego se hace una resolución general en el pizarrón o usando un proyector. Puede que también se entregue algún material de lectura. Pero sentarse a programar con el alumno, no, nunca. En el mejor de los casos, mientras los alumnos trabajan en la resolución de los ejercicios, puede que un docente se acerque para responder alguna consulta o para destrabar a un alumno que no logra avanzar en la resolución.

¿Por qué es esto así? no lo sé a ciencia cierta. Creo que puede haber diversos motivos.

En sus comienzos la programación surgió vinculada a la matemática y por ello puede que haya heredado su didáctica. También puede ser que los docentes no vean la programación como un oficio. En algunos casos podría argumentarse que la masividad de algunos cursos hace imposible que el docente se siente a programar con los alumnos. En fin, cada cual tendrá sus argumentos. En lo que a mi respecta, estoy convencido que la programación es un oficio y si bien en Algo3 tenemos cursos masivos y recursos acotados, intentamos programar con los alumnos haciendo dojos en clase o incluso algo de «community-programming» al desarrollar el trabajo final, donde cada docente puede sentarse con grupos de 3 o 4 alumnos a programar conjuntamente.

Agile no funciona con equipos grandes

Simplemente porque no existen equipos grandes. Seamos realista, 50 personas trabajando en un en una sala no son un equipo, son simplemente un amontonamiento de gente. Un equipo es mucho más que un amontonamiento de gente, basta con mirar los equipos deportivos, donde la mayoría no supera los 10 integrantes.

¿Esto implica que no pueden hacerse proyectos grandes? De ninguna manera, si un proyecto por la cuestión que sea require de 50 programadores, entonces simplemente habrá que particionar el proyecto de manera que puede ser desarrollado por 10 equipo de 5 integrantes cada uno.

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.