Categoría: Uncategorized

Caminando las herramientas de automatización de infraestructura

En mi opinión hay 3 herramientas que han picado en punta en esta temática: Chef, Puppet y Ansible. Hay algunas otras (como por ejemplo CFEngine) pero toda la gente y casos que conozco utilizan alguna de las 3 mencionadas. En mi caso cuando comencé a meterme en este campo di una primera mirada a Chef, tenía por aquella época un cliente a quien yo estaba ayudando con otras cuestiones y que usaba Chef para administrar su infraestructura. A partir de ello hice algunas pruebas con Chef, pero nunca lo use en un «proyecto real».

Poco tiempo después me salió un proyecto para automatizar todo el pipeline de deployment de un aplicación incluyendo el proceso de provisioning de ambientes. Las pruebas que había hecho con Chef no me habían convencido, asi que decidí probar con Puppet. Usé Puppet durante un buen tiempo en diversos proyectos hasta que este año trabajé en un proyecto con Ale Ferrari quien venía utilizando Ansible y en mi siguiente proyecto decidí probarlo.

Hoy en día mi elección es Ansible, pero las razones las compartiré en otro post.

Versionado de base de datos

Este es un tema que curiosamente para mi muchos equipos no tienen incorporado como práctica. A mi parecer en la actualidad la estrategia más común para esto es lo que desde hace años comenzó a hacer Ruby on Rails:

  • escribir los scripts incrementales de actualización de la base siguiendo una convención de naming incremental (números secuenciales o timestamp invertidos). Estos scripts al ser texto plano se pueden almacenar naturalmente en el repositorio de código junto al código de la aplicación
  • por otro lado se agrega una tabla en la propia base de datos para llevar registro de los scripts aplicados lo cual determina la versión de la base de datos.

En el caso de Ruby on Rails, uno debe encargarse de escribir los scripts (para escribir los puede usar un DSL en lugar de sql) y luego el propio framework brinda funcionalidades para crear la tabla de versión, ejecutar los scripts y llevar control de su ejecución. No estoy seguro si Rails fue el primer framework en implementar esta estrategia pero en la actualidad existen diversas herramientas en distintos lenguajes que la implementan como ser: FluentMigrator (con foco en C#), LiquidBase (con foco en Java/Grails).

Una herramienta que implementa esta estrategia y con la que he estado trabajando este último tiempo es Flyway, les comparto un video que muestra su uso y explica algunos detalles.

La reunión olvidada: Iteration Review

En el desarrollo (ágil) de software actual hay 3 reuniones bien establecidas: iteration planning, iteration review y retrospectiva. (nota: si bien esta es la terminología propuesta por Scrum no estoy hablando particularmente de Scrum sino de desarrollo ágil en general)

Hay libros enteros dedicados a planning y también los hay dedicados a retrospectivas, pero no ocurre lo mismo con reviews. Al mismo tiempo he visto consultores/facilitadores colaborando en reuniones de planning y retrospectiva (retrospectivas sobre todo) pero no ocurre lo mismo con las reviews.

Curioso ¿no?. ¿Simple casualidad? Mmm, no creo.¿Será que la review es menos importante? No ¿será que la review es más fácil? Mmmmm, no creo. @egutter me dice que es porque la review es anterior al desarrollo ágil y al mismo tiempo la agilidad no ha introducido grandes cambios en esta reunión, como si lo ha hecho en la planning. Esta justificación me resulta bastante convincente.

Mientras escribo estas líneas caigo en la cuenta que en mi propio libro hay capítulos dedicados a planning y retrospectivas pero no dedicado a reviews, ¡Ja!

Personalmente la mayoría de las veces que he asistido a reviews ajenas (o sea de proyectos/equipos en los que no estaba involucrado) me fui decepcionado. Reuniones empezando tarde, demostraciones inentendibles (o directamente fallidas), usuarios/stakeholders ausentes, incluso miembros del equipo ausentes, pérdida del foco de la reunión, horario de finalización incierto, entre otras cuestiones.

Para mi la review es una reunión clave. O tal vez LA REUNION CLAVE. En la planning el equipo asume un compromiso pero es en la review donde se ve el resultado de ese compromiso. Es en la review donde tenemos la posibilidad de deleitar a nuestros stakeholders. Es en la review donde se juega la continuidad del proyecto.

Es por esto que en mi materia de ingeniería de software dedico una clase para que mis alumnos entiendan la importancia de esta reunión y sepan como prepararla y guiarla apropiadamente. Al mismo tiempo como parte de la materia los alumnos tienen que realizar al menos 4 reviews y su desempeño en esas reviews tiene impacto directo en la aprobación de la materia.

Continuará…

Sobre el TP final de algo3 (2015-1)

A fines de mayo lanzamos el TP final de Algo3. En el curso de los miércoles tenemos poco más de 30 alumnos repartidos en equipos de 3 integrantes, cada equipo con un docente tutor. En mi caso soy tutor de 4 equipos.

Este cuatrimestre el trabajo prácticos se llama AlgoCraft y como su nombre lo sugiere es una variante del clásico juego StarCraft.

Como de costumbre desde el comienzo del trabajo práctico configuré un Jenkins para que los alumnos pudieran hacer integración continua. Esto también me permite tener métricas de su trabajo. Este cuatrimestre incorporé PMD al conjunto de tareas ejecutadas en el proceso de integración continua. PMD es un herramienta que entra en la categoría de «Linter» y como tal, lo que hace es analizar el código fuente realizando un conjunto de verificaciones relacionadas al cumplimiento de estándares y buenas prácticas de programación del lenguaje en cuestión.

algo3_20151

XP2015: Day 3 Summary

The journey started with the keynote by Harri Oikarinen from Ericsson. His talk focused on the leadership model and learning lifestyle strategy that Ericsson is using to face what he described as the Network Society. It was very interesting and the slides were really cool!

After the keynote we had pitches of the sessions on the day.

During the whole day there were open space sessions in parallel with the predefined sessions.

I spent the rest of the morning in the lightning talks session where I found some interesting stuff and I also shared the Test-Driven approach we are using at FIUBA.

After the lunch I joined the session Create the Conditions for Team Learning and Coordination: Five Simple Rules hosted by Diana Larsen. Very very useful (I will share some notes about this in another post).

Finally I joined an open session session proposed by Alex Wilson which was about Modern XP. In this session we went over the original XP practices and analyzed the evolution of each of them. Very interesting and possible one of the best sessions of the day.

Late in the evening we had the conference social dinner at the Helsinki Stock Exchange Building, a really nice place. The dinner was great: excellent food and some fun entertainment including PowerPoint-Karaoke (organized by Diana Larsen), a singer, a pianist and magician. I was in a table with some guys some India and Italy and another guy born in Tunisia but currently living now in Sweden.

xp_day3_1 xp_day3_2

Preparation for BDD Tutorial

Next Friday I will be hosting a BDD Tutorial (fr2.1) in the context of XP Conference. For those planning to attend to this workshop consider that it is a hands-on session, so bring your machines. I have a preconfigured vm image with all the required tools in it, so please ensure to have Virtual Box installed in your machine.

If you prefer to not use the VM, then you should ensure to install:

  • Java 7 JDK
  • Maven
  • Git

Finally, please complete this form, so I can have a idea of how many people will attend to the workshop. This will allow me to adjust the activities of the workshop.

Nuevo proyecto de CI / CD

Hacía fines de diciembre del año pasado me contactaron de una empresa para que los ayudara con una iniciativa de Integración Continua. Intercambiamos un par de mails, tuvimos una llamada telefónica de 20 minutos y acordamos una primera reunión.

Desde mi punto de vista la práctica de integración continua no es un fin en sí mismo sino que es una herramienta. Por ello, una de las primeras cosas que pregunté fue: ¿Cuál es su problema? ¿Qué esperan solucionar con esta práctica? La respuesta fue clara, había dos problemas principales: por un lado la calidad del producto y por otro el desperdicio de tiempo invertido en el despliegue de la aplicación a los distintos ambientes. Esto me permitió entender que la cuestión iba bastante más allá de la integración continua.

El desafió me pareció muy interesante, pues se trataba de una empresa grande, con equipos distribuidos geográficamente en distintos lugares de latinoamérica y cuyo negocio estaba centrado en la venta de soluciones de banca. La empresa contaba con un plataforma de productos que vendía a distintos clientes y cada venta implicaba una implementación/customización de los productos. De esta forma había equipos trabajando sobre los productos y en paralelo un equipo de implementación para cada cliente que compraba el producto.

En términos de administración de la configuración a primera vista la naturaleza del negocio llevaba a tener un trunk de producto con un branch por cada cliente. Fácil decirlo, no tan fácil de implementarlo sobre todo teniendo el código de todos los productos en un único repositorio CVS.

La plataforma tecnológica era Java, un clásico en sistemas de banca. Pero dado que la solución se vendía a distintos clientes la aplicación debía funcionar sobre distintos ecosistemas tanto a nivel base de datos, application server y service bus.

Un último condimento no menor es que gran parte del código venía arrastrándose desde hacía varios años y tenía dependencia con componentes open source ya sin soporte (por ejemplo Apache Hivemind). Adicionalmente también se estaban usando versiones viejas de algunas herramientas (por ejemplo java6  y maven2).

Cabe destacar que varias de este cuestiones no las sabia inicialmente, sino que las fui descubriendo una vez empecé a trabajar.

La situación era compleja y las expectativas del cliente eran muy grandes. Mi propuesta fue simple y concreta:

Busca un equipo que esté interesado en trabajar en esta iniciativa. Yo me siento y trabajo con el equipo codo a codo 1 mes para resolver los impedimentos que el equipo considere le impiden construir software de calidad.

Al cliente, le gustó la propuesta y la bola empezó a rodar.

Continuará…

Cierre de cuatrimestre en UNQ (2014-2)

Un nuevo cuatrimestre ha pasado y seguimos batiendo records, este cuatrimestre tuvimos 15 alumnos. Lamentablemente no todos aprobaron, en concreto tuvimos:

  • 11 aprobados
  • 2 abandonos
  • 1 desaprobado
  • 1 pendiente de aprobación

Otra novedad de este cuatrimestre fue la incorporación como colaboradora de Ingrid Calderón, una ex-alumna de la materia.

Básicamente mantuvimos la misma estructura y dinámicas que el cuatrimestre anterior con la incorporación de algunas innovaciones y mejoras surgidas de la retrospectiva del primer cuatrimestre. Entre las innovaciones, incorporamos en forma temprana mini TPs que denominamos Katas y que tenían como objetivo:

  • que los alumnos se familiarizaran con ciertas herramientas (ruby, rspec, cucumber, etc) y técnicas (tdd y bdd)
  • que se habituaran a estimar y planificar tareas
  • que se acostumbren a dar visibilidad sobre todo en caso de no poder cumplir con fechas comprometidas

En cuanto a los TPs, mantuvimos la misma estrategia (equipos de 3 personas trabajando sobre aplicaciones Ruby/Padrino) pero con una pequeña innovación: la formación de los equipos estuvo condicionada por el desempeño de los alumnos al momento de inicio del TP. O sea, si un alumno no habia completado todas las tareas anteriores al momento de inicio del TP, entonces no podía conformar equipo con alguien que sí las había completado. La motivación detrás de esto es: dado que las tareas son relativamente simples, quien no las completa es en general por falta de compromiso/interés en la materia, entonces procuramos que todos los equipos cuenten con gente con el mismo nivel de compromiso/interés.

En cuanto a visitas de la industria, este cuatrimestre tuvimos a:

Al igual que el cuatrimestre pasado hicimos una encuesta complementaria a la retrospectiva y según la misma, la evaluación general de la materia por parte de los alumnos fue de 8,8.

De la retrospectiva y la encuesta destacamos algunos puntos en los que trabajaremos el cuatrimestre próximo:

  • Explicar desde el comienzo los criterios de evaluación de la materia y del TP final
  • Reorganizar las katas de forma de incluir alguna con Padrino y Travis
  • Hacer más prácticas de programación en clase (dojos)
  • Publicar todos los recursos técnicos de forma temprana para que cada uno pueda organizarse mejor (en general los punblicamos a medida que vamos avanzando en la materia).
  • Reevaluar la estrategia para la formación de equipo para el TP final

unq_2014_2

Finalmente, este cuatrimestre les pedimos a los alumnos que graben una breve demo de las aplicaciones desarrolladas:

Tenemos un video más pero al no estar publicado en YouTuve no he logrado embeberlo aquí.

Agiles 2014, #NoSeréFeliz pero tengo trabajo

#NoSeréFeliz pero tengo trabajo, fue el título del keynote de Martín Alaimo el tercer día de Agiles2014. Posiblemente haya sido el mejor keynote que vi en las 6 ediciones de ÁgilesXX que participé (no estuve en 2010). Ya de entrada el título resultaba interesante. Más allá del contenido del keynote, destaco algunos elementos que a mi entender fueron claves para que el keynote sea realmente excelente:

  • Manejo de recursos: en primer lugar Martín manejó muy bien los tiempos y respetó lo que estaba agendado. También hizo un uso discreto pero muy apropiado de las diapositivas: diseño minimalista, pocos colores, poco texto, algunas imágenes, nada de transiciones. Esto hacía que audiencia no se distraiga con las diapositivas en cambio prestara atención a lo que Martín decía. También hizo uso de las luces, en un momento se apagaron todas las luces del auditorio lo cual sirvió para generar una atmósfera muy especial y en sintonía con lo .que se estaba hablando.
  • Vivencia: Martín comenzó contando una vivencia personal, lo cual generó una conexión con la audiencia.
  • Participación: a pesar de ser un keynote, Martín hizo participar a la audiencia en varias ocasiones. En un momento nos dió algunas consignas a realizar desde nuestro lugar y luego invitó a algunos voluntarios a subir al escenario.
  • Llamado a la acción: finalmente el keynote cerró con un llamado a la acción, una estupenda idea para el cierre pero que curiosamente pocas veces he visto.

Mientras escribo estas líneas, reflexiono, recorro mi memoria y llego a la conclusión de que este keynote está en el top 3 de las mejores sesión que presencie en mi vida.

¡Gracias Martín!

martin_at_agiles2014