Cierre de Algo3, primer cuatrimestre 2013

Si bien no hicimos cambios explícitos en la dinámica de la materia, incorporamos algunas cuestiones internas que generaron impacto muy positivo.

Una de estas cuestiones fue la incorporación del sistema de corrección de TPs. Esto nos ayudo a reducir muchísimo la carga de trabajo manual al mismo tiempo que le permitió a los alumnos tener un feedback inmediato de las entregas de sus trabajos.

Por otro lado, trabajamos con más foco en la coordinación interna de las clases de los distintos cursos de práctica, reutilizando materiales y ejemplos.

Finalmente, en lo que respecta al trabajo final, tuve dos grupos a mi cargo y ya desde la primer semanal tuvimos el soporte de un servidor de integración continua. Para esto, utilice el servicio que gentilmente nos brinda en forma gratuita CloudBees. Al mismo tiempo, fue muy positivo que ambos grupos tomaron en serio el build server, rompiendo el build muy pocas veces. Todo el proceso de build lo hicimos usando Ant y consistia en compilación, ejecución de pruebas (junit), medición de cobertura (cobertura) y verificación de código (checkstyle). Otro detalle que me pareció muy positivo es que gran parte del modelo de la aplicación lo hicieron usando TDD, lo cual derivó en un porcentaje de cobertura muy bueno (superior al 80%). Algunos otro docente, también usaron esta herramienta con muy buenos resultados y por ello en la retrospectiva decidimos extenderlo a toda la cátedra para el próximo cuatrimestre.

Travis y Jenkins al mismo tiempo

S bien ambas herramientas son build servers y en general uno utilizará alguno de los dos, en ciertos casos puede resultar muy útil utilizar ambos al mismo tiempo. Esto es hago que he hecho en mis últimos 3 proyectos.

Si bien, en varios sentidos Jenkins puede resultar mucho más «potente/flexible» que Travis, resulta que este último tiene una funcionalidad «matadora»: buildea todos lo branches existentes en el repositorio, sin requerir ninguna configuración adicional. Esto resulta especialmente útil cuando uno utiliza feature branches. Por su parte, Jenkins no tiene soporte actualmente para buildear varios branches en un mismo job. Claro que es posible jugar un poco con algunos plugins y lograr un workaround para lograrlo, pero no es algo out-of-the-box ni tampoco trivial.

Entonces, si para integración continua utilizo Travis, ¿para qué utilizo Jenkins? Simple, para automatizar mi proceso de despliegue y ejecutar algunas otras tareas que no puedo ejecutar con Travis como ser: enviar notificaciones via chat/sms, generar reportes, ejecutar tests de larga duración, etc.

Webinar: Técnicas de versionado para Entrega Contínua

El próximo miércoles (mañana), voy a estar dando un webinar sobre este tema. La idea es ver los conceptos básicos de la práctica Continuous Delivery y enfocarnos en cómo manejar nuestro repositorio de código para facilitar la entrega continua. Presentaremos algunos conceptos y estrategias, y veremos como llevarlos a la práctica utilizando la herramienta Git.

En página de registración encontrarás más detalles sobre este webinar.

Durante el webinar, recibiré consultas a través de Twitter (@kleer_la & #kleerScm).

 

Tools for Git

There is a simple but extremely useful tool to work with Git. It is not a graphic interface nor an IDE plugin. It is just an extension to the shell. It is called oh-my-zsh and, among other things, it provides a feature that shows the current git branch you are working on, when you are browsing a git directory.

To install this tool, you just have to follow these simple steps:

  1. The tool is an extension to zsh shell, so you have to start by installing zsh: apt-get install zsh
  2. Then you could want to set zsh as you default shell: chsh -s /bin/zsh <user_name>
  3. Install oh-my-zsh: curl -L https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh | sh
  4. Close the terminal and restart you OS session

That is all, you are done!.

git-tools

Tutorial de aplicaciones Padrino: parte 1

En esta primera parte veremos la configuración inicial de nuestra aplicación y algunas de las herramientas que utilizaremos a lo largo del tutorial. La idea trabajar con un entorno como el descripto en el post inicial de esta serie, partiendo de esta solución y siguiendo los videos explicativos.

  • Creación del repo git y primer commit, ver.
  • Creación de la aplicación base con Padrino, ver.
  • Configuración de Travis (build server), ver.
  • Ajustes de configuración en la aplicación base que genera Padrino, ver.
  • Generación de un objeto de negocio (model) con Padrino, ver.
Continuará…

Cierre de cuatrimestre en UNQ, cuarta promoción

Terminó el cuatrimestre y se fue la cuarta promoción de Elementos de Ingeniería de software desde que la materia está a mi cargo. Este cuatrimestre la materia tuvo un enfoque mucho más práctico. El primer mes de clase fue más o menos igual que siempre, pero luego nos fuimos enfocando mucho más en cuestiones cercanas al código. Para ello trabajamos con Ruby+Padrino, GitHub, Travis y Heroku. Lás últimas 5 semanas los alumnos trabajaron en grupo en el desarrollo de distintas aplicaciones. La aplicaciones en sí no fueron más que una excusa para poner en práctica los temas de ingeniería abordados durante la materia: estimación, planificación, comunicación, gestión de alcance y cambios, etc, etc.

Otro cambio que tuvimos este cuatrimestre fue que usamos un sitio basado en Jekill para llevar la bitácora de clase.

Para cerrar la materia cada grupo de alumnos grabó un screencast contando el trabajo realizado, les dejo los links a los videos:

Al igual que el cuatrimestre pasado, conté con la colaboración de Natalia, una ex-alumna de la materia (¡gracias Nati!)

Algunos números frios:

  • Alumnos anotados: 10
  • Alumnos aprobados: 8 (2 alumnos abandonaron la materia en el primer mes de clase)
  • Nota final promedio: 8,25
  • Fueron un total de 28 clases
  • Tuvimos otra vez la visita de un profesional de la industria (¡gracias Emilio!)

Estoy muy contento con como salió la materia y según lo hablado en la restrospectiva, los alumnos también quedaron contentos. Una cosa en particular que me puso muy contento, es que logré mejorar la forma en que doy feedback, algo que había salido de la restrospectiva anterior.

eis2013-1

Nota: el ícono representa un alumno que estuvo ausente el día de la retrospectiva.

eis-2013-1b

Curso de Extreme Programming y tutorial de desarrollo de aplicaciones con Padrino

Desde hace un tiempo vengo trabajando con mi colegas de Kleer en la preparación de un curso de desarrollo de aplicaciones con prácticas ágiles. En cierto modo es un curso intermedio/avanzado de Extreme Programming. Durante el curso se verán temas como SCM, BDD, TDD, Mocking, Continuous Delivery, Pair programming, Design Patterns, SOLID, etc.

La idea del curso es ver estos conceptos y poner manos a la obra programando una aplicación empresarial utilizando Github, Travis, Ruby, Padrino y Heroku, entre otros. Dado que la idea es trabajar sobre los conceptos previamente mencionados, nosotros proveeremos una aplicación base sobre la cual se desarrollará el curso y sobre la que los alumnos deberán implementar nuevas funcionalidades poniendo en práctica los conceptos/prácticas en estudio.

Aprovechando el desarrollo de esta aplicación, he decido ir generando una serie de artículos y videos a modo de tutorial, para mostrar cómo encarar el desarrollo de una aplicación utilizando las mencionadas prácticas y herramientas.

Para facilitar las cuestiones de setup, estoy utilizando una máquina virtual con Linux Mint 14. Pueden descargarse la imagen base en forma totalmente gratuita desde virtualboxes.org. Esta imagen se puede ejecutar en diversas plataformas utilizando Virtual Box.

Una vez que tengan la imagen funcionando, es necesario instalar algunas cosillas, cuyo detalle pueden ver aquí.

En los próximos días comenzaré a publicar videos de 5 minutos mostrando como desarrollar la solución utilizando las mencionadas herramientas.

Anécdotas sobre cobertura de la prueba

«No quieres 100% de cobertura, porque es realmente muy caro lograrlo. En cambio deberías enfocarte en asegurarte la cobertura en los lugares donde más frecuentemente tienes bugs«.

Este es un extracto de una charla que tuve con Stef mientras transitábamos por la ruta que lleva de Lens a Lille, en Octubre de 2010. Si bien puse el texto entre comillas, la cita no es textual, pues Stef hablaba en inglés, pero la idea central es la que reflejo aquí.

Para cerrar este post, les comparto una situación que viví hace un tiempo: resulta que una de las personas que estuve capacitando hizo una demo de la aplicación que desarrolló como parte de la capacitación. La demo venia bien y en un momento le pedimos que mostrara una funcionalidad particular que no habia sido mostrada. Resulta que cuando la va a mostrar, la aplicación ¡pincha!, ja!  a lo que le pregunto ¿y los tests? adivinen….no había tests para esa funcionalidad. El porcentaje de cobertura de la aplicación no superaba el 40%. ¡Que mejor forma de ilustrar la importancia de estas cuestiones! Espero que este colega haya aprendido la lección.

Por último quiero agradecer a David Frassoni quien la semana pasada me dio la idea de escribir este post.