El evento del Año: AOC 2015

aoc2015

Definitivamente este evento está en el top 3 de los eventos que más expectativas me han generado.

Mi gran expectativa no es por el contenido, pues dada la propia dinámica del evento el contenido surgirá de los asistentes y será sin duda excelente. Lo que realmente me genera gran expectativa es el «formato inmersivo»: hay una invitación explícita a compartir plenamente 3 días realizando diversos tipos de actividades, sesiones de debate, caminatas, almuerzos, meriendas, cenas, visitas turísticas, actividades deportivas, etc, etc.

Y como si con una experiencia así no fuera ya suficiente, debemos sumarle el hecho de que el evento se llevará a cabo es uno de los paisajes naturales más hermosos de Argentina.

Me imagino…

….charlas después de la cena alrededor de una fogata.

…rondas de mate al aire libre con un cerro nevado de fondo.

… actividades recreativas a la orilla del lago.

…asado, chocolates y cerveza!!!!

La cita es 17, 18 y 19 de Abril en San Carlos de Bariloche, info completa en http://www.agileopencamp.com.ar/ ¿Te lo vas a perder?

 

 

 

Elegir un sistema de control de versiones

En más de una ocasión he sido consultado por organizaciones sobre la elección de sistemas de control de versión. Actualmente estoy trabajando con una organización que usa CVS y que está evaluando distintas herramientas para reemplazarlo.

Si bien basta con googlear un poco para encontrar miles de post sobre las diferencias, beneficios y problemas de los distintos sistemas de control de versiones, cambiar el sistema de control de versiones implica varias cuestiones no triviales.

Desde mi perspectiva estamos hablando de una herramienta que nos ayudará a resolver ciertas cuestiones de trabajo colaborativo y recalco esto: nos ayudará, la herramienta por sí sola no resolverá nada. Más aún, una herramienta mal utilizada puede traer más problemas que soluciones. Para que la herramienta nos permita resolver algún problema, debemos establecer ciertas reglas/convenciones para su uso (y luego respetarlas).

Dicho esto, deberíamos comenzar por identificar el/los problemas a resolver y luego analizar cómo es que cada alternativa de herramienta nos permitiría resolver esas cuestiones.

Desde mi óptica, hay 3 dimensiones de considerar en la evaluación.

Sistema de control de versiones: Git, Subversion, CVS, Mercurial, Darcs, son algunos sistemas de control de versiones. Para elegir uno posiblemente debamos comenzar por preguntarnos si queremos un sistema distribuido o centralizado y con ese punto de partida podremos ir acotando nuestras opciones. No voy a profundizar sobre este punto pues considero que es el que más desarrollado está y basta googlear un poco para encontrar pros y contras de cada uno.

Producto/Servicio: una vez elegido el sistema debemos elegir un producto o servicio que lo implemente. En este caso la discusión podría comenzar por: ¿queremos tener el sistema en nuestra infraestructura o preferimos contratarlo como servicio?. Una vez definido esto deberemos elegir un opción concreta. Ejemplo: supongamos que decidimos ir un sistema distribuido y concreto nos inclinamos por Git, entonces podríamos utilizar un servicio en la nube como el ofrecido por GitHub o Bitbucket o bien podríamos decidir adquirir un producto e instalarlo en nuestro entorno como podria ser GitLab o Stash.

Forma de uso: por más que hayamos elegido una producto/servicio concreto (supongamos GitLab), aún no basta para resolver nuestro problema, deberíamos definir ciertas cuestiones respecto de cómo usarlo. Esto implica responder preguntas tales como: ¿Cuál es el criterio para la creación de repositorios: creamos un único repo por equipo o creamos un repo por componente de nuestra solución? ¿usamos branches o forks? ¿cómo debería ser la estructura de cada repositorio?¿trabajamos todos sobre master o usamos feature branches?. Sin duda varias de estas cuestiones estarán influenciadas por la herramienta elegida pero más allá de eso, hay otra cuestiones que dependerán de problemática concreta de cada organización/proyecto.

En los últimos 2 años, he trabajado con al menos 5 organizaciones y en todos los casos la herramienta elegida ha sido Git. Si bien no siempre participé directamente en la elección de la herramienta, en varios casos estuve fuertemente involucrado en la definición de la forma de uso y la capacitación de los equipos.

Continuous: Integration vs Delivery vs Deployment

En los últimos dos años he repetido incontables veces la diferencia entre estas tres prácticas y dado que no encontré ninguna explicación online que me satisfaciera, he decidido escribir mi propia explicación.

Continuous Integration: el software suele desarrollarse en equipo, donde cada miembro trabaja en su máquina en una porción del software. En ese contexto, la práctica de Continuous Integration propone integrar de forma continua el trabajo realizado por cada miembro del equipo. Esto implica una serie de cuestiones como ser el uso de controlador de versiones y contar con un ambiente de integración donde puedan ejecutarse verificaciones sobre software integrado.

Continuous Delivery: en términos organizacionales esta práctica es poner en manos del negocio la decisión de cuándo ir a producción. Más concretamente eso implica que cada build exitoso pueda (si el negocio así lo decide) ir a producción. entiéndasee build como el artefacto resultante del proceso de integración)

Continuous Deployment: está práctica va más allá de Continuous Delivery e implica que cada build exitoso va automáticamente a producción. Tal como propone Jez Humble, un mejor nombre para esta práctica sería Continuous Release. Continuous Deployment implica Continuous Delivery pero no al reves.

Estas tres prácticas tienen un aspecto técnico relacionado a herramientas y aspecto humano relacionado a hábitos y reglas que las personas deben incorporar y que personalmente considero que es el mayor desafío a la hora de intentar implementar estas prácticas. Ejemplo: de nada sirve tener un controlador de versiones si los miembros del equipo hacen commit una vez por día.

El orden en que describí cada práctica tiene que ver con el orden natural de adopción de las misma. Cabe aclarar cada práctica puede implementarse con distintos «niveles de profundidad» los cuales dependerán del contexto de cada proyecto/organización.

Muchas veces al explicar estas prácticas la audiencia tiende a decir que quiere implementar Continuous Delivery ante lo cual suelo aclarar: «No todas las prácticas son necesarias para todo contexto» y a continuación pregunto: «¿Su negocio realmente necesita continuous delivery?» En determinados contextos tener Continuous Delivery puede ser imprescindible para que el negocio sea competitivo, mientras en otros contextos (posiblemente más estables a nivel de negocio), sea simplemente un nice-to-have.

Como comentaba un amigo que trabaja en la industria petrolera: «Nosotros tenemos 3 releases anuales planificados e inamovibles», en un contexto así posiblemente no se justifique el esfuerzo que implica adoptar continuous delivery. Distinto es el caso de un negocio muy variable que requiere de cambios constantes en sus aplicaciones donde no tener Continuous Delivery podría implicar perder el negocio.

Por su parte la práctica de Continuous Integration tiene algunas particularidades respecto de las otras dos prácticas. En primer lugar, es una práctica higiénica, lo cual implica que en términos generales siempre debe utilizarse. En segundo lugar es una práctica «a puertas cerradas» en el sentido que su uso está complementamente en manos del equipo de desarrollo. No es necesario aprobación y/o interacción con personas de otras áreas de las organización ni con el usuario. Si bien puede ser útil tener ayuda del grupo de infraestructura para montar un servidor de integración continua, la realidad es que no es algo imprescindible, el propio equipo puede montar un servidor de integración continua en la máquina de alguno de los miembros del equipo o bien podría utilizar algún servicio online (como Travis o CloudBees).

Para quienes quieran profundizar les recomiendo es artículo de Jez Humble: Continuous Delivery vs. Continuous Deployment.

Para cerrar les comparto un par de imagenes (de mi autoría) que esquematiza la diferencia/relación entre estas prácticas.

ci_y_cd

 

cd_y_cd

Mis estadísticas 2014

El fin de año es un período que comúnmente se utiliza para hacer un balance del año que se va. Yo mismo suelo hacerlo pero no pretendo aburrir a mis lectores con mi balance, sino que quiero compartir algo que me parece más interesante: estadísticas.

Para que se entiendan los números que quiero compartir es necesario que expliqué a grandes rasgos la forma en que suelo trabajar.

Mi trabajo se reparte entre actividades académicas (principalmente docencia) y ejercicio profesional. Este último lo hago en el contexto de proyectos, o sea, me involucro en el ecosistema del cliente, definimos objetivos de forma conjunta a cumplir en ciertos plazos. Luego trabajo de cerca con mi cliente de cara a lograr esos objetivos. Establecemos fecha de revisión en las cuales analizamos el trabajo realizado y el nivel de cumplimiento de los objetivos, en base a ello definimos la continuación o no de mi acuerdo de trabajo.

Yo suelo organizar mis jornadas de trabajo en base a pomodoros y mis acuerdos de trabajo suelen times & materials. Esto, sumado al hecho que me gusta ser muy transparente con mis clientes, me lleva a tener un registro detallado de las actividades realizadas y el tiempo insumido.

Si bien en los proyecto en que participo suelo hacer diversas actividades, siempre hay una que es la principal y que en cierto modo define mi rol en el proyecto. En este sentido mis proyectos se clasifican 4 grupos: desarrollo, testing (automatización de pruebas), operación (automatización de infraestructura) y capacitación (cursos informales y docencia universitaria).

Hecha la introducción quiero compartir en primer lugar cómo estuvo repartido mi tiempo en base al tipo principal de actividad que desarrollé en los proyectos que participé:

distribucion_actividad

Como muestra el gráfico precedente, mi principal actividad durante 2014 fue desarrollo, seguido en segundo lugar por capacitación la cual fue casi exclusivamente en contexto universitario. Hay algunas otras actividades que decidí omitir del gráfico por ser excepcionales (como la facilitación de eventos) o por no ser directamente facturables (como conferencias y el tiempo invertido en la escritura del blog y del libro).

Dado que mi principal actividad fue desarrollo, tiene entonces sentido analizar cuáles fueron las tecnologías con las que trabajé.

distribucion_tecnologia

 

La distribución de tecnologías está hecha en base a la tecnología principal del proyecto, por eso es que no figuran las tecnologías de presentación como HTML y CSS. Al mismo tiempo en lo que especifiqué como scripting estoy incluyendo cosas tales como shell script, powershell, puppet y chef.

Bueno, esto es todo por 2014, ¡nos leemos en 2015, felicidades!

Breve historia de las herramientas BDD

Uno de los mayores referentes en lo que a BDD respecta es Dan North. Hacia el año 2003 Dan se encontraba trabajando en ThoughtWorks cuando creo JBehave. Según el mismo cuenta, JBehave comenzó como un experimento para ver como podría haber sido JUnit si se hubiera concebido desde un principio como una herramienta para hacer TDD en lugar de un mero framework de pruebas automatizadas. Fue por aquel entonces que el dominio jbehave.org fue registrado. Con el correr del tiempo JBehave fue evolucionando con foco en la automatización de pruebas de aceptación.

Tiempo más tarde algunas ideas de JBehave fueron incorporadas por Dave Astels en RSpec.

Hacia 2007 Dan North inspirado por el la tracción generada por RSpec y con la intención de proveer una forma simple y elegante de describir comportamiento a nivel de aplicación publica RBehave, el cual trae como novedad la posibilidad de especificar comportamiento en texto plano, idea que luego daría origen a lo que en la actualidad se conoce como sintaxis Gherkin.

Al poco tiempo David Chelimsky incorpora en RSpec el soporte de especificaciones en texto plano.

En 2008 Liz Keogh and Mauro Taveli reescriben completamente desde cero JBehave haciendo uso de algunas característica recientemente incorporadas en Java 5 y utilizando JUnit 4 como runtime. Entre otras cosas incorporan soporte para especificaciones en texto plano e integración con Maven. El resultado es JBehave 2.

Por aquel entonces Aslak Hellesoy ya se encontraba trabajando en un reemplazo para el ejecutor de especificaciones en texto plano de RSpec, el cual sería bautizado como Cucumber. La primera versión de Cucumber fue liberada hacia fines del 2008.

Mi percepción es que Cucumber marcó un punto de inflexión en la difusión de BDD. Fue precisamente en el contexto de Cucumber que se estandarizó la sintaxis de especificación en texto plano y se la bautizó como Gherkin.

Fue tal el impacto de Cucumber, que en la actualidad existen herramientas de BDD con soporte para Gherkin implementadas en diversos lenguajes, algunas de ellas son directamente reimplementaciones de Cucumber sobre otras plataformas (tal es el caso de Cucumber-JVM).

Fuentes:

 

Una empresa interesante: Poincenot Technology Studio

La segunda mitad de este año estuve trabajando con la gente de Poincenot. La experiencia me resultó muy interesante por una serie de cuestiones que van allá de la temática del proyecto en que participé.

En primer lugar me reencontré con algunos estudiantes/graduados de FIUBA, lo cual nos dio tema de conversación para más de un almuerzo.

Tuve la oportunidad de compartir algunas conversaciones con los fundadores de la empresa y me llamó poderosamente su visión, la cual yo interpreté como: «Somos un estudio de tecnología enfocados en habilitar negocios, no desarrollamos software porque sí, sino que lo hacemos para apalancar negocios. La tecnología no es un fin en sí mismo, sino un medio«. A mi entender esto representa un foco claro en la entrega de valor lo cual en gran medida explica el hecho de que muchas cosas en Poincenot se hagan con mindset ágil.

Poincenot es un empresa con menos de un año de vida, pero con un equipo de profesionales excepcionales tanto a nivel management como técnico. En el equipo de management están Mario López, un técnico convertido en hombre de negocios, Facundo Vazquez y Augusto Fernández Villa, ambos ex-Tecso. Dentro del equipo de técnicos destaco a Maia, egresada de FIUBA con quien tuve el gusto de trabajar años atrás. Maia tiene un master en Human-Computer Interaction y a penas regresó se sumó  a Poincenot donde está liderando las cuestiones de UX. También entre los técnicos hay un par de expertos Java con los que estuve trabajando de cerca y de quienes aprendí muchísimo (gracias Lio y Dani).

Y como si con todos esos profesionales fuera poco, han sumado algunos profesionales externos para colaborar con algunas cuestiones específicas. Fue así que durante mi participación en Poincenot me encontré trabajando con Alan Cyment, Sole Pinter y Diego Fontdevila.

Para cerrar te digo: si estas evaluando un cambio de trabajo, te interesa ser parte de un proyecto prometedor y trabajar en un ambiente profesional y ameno, no dudes en contactarte con Poincenot.

poincenot

Nuevos Técnicos en Programación graduados de UNQ

El viernes pasado fue la presentación del trabajo de final de carrera de Marcia Tejeda y Néstor Muñoz. Con la presentación y aprobación de trabajo, Marcia y Néstor completaron la Tecnicatura Universitaria en Programación Informática y se convirtieron en los egresados 13 y 14 de esta jóven carrera.

Yo tuve el gusto de dirigir el trabajo junto a Fidel. El mismo consistió en el desarrollo y puesta en marcha de una aplicación para el proceso de Triage del servicio de guardia del Hospital Arturo Oñativa de Rafael Calzada.

Este fue el primer trabajo que dirigí en UNQ y estoy verdaderamente muy contento con el resultado por diversos motivos:

  • La pieza de software creada (producto)
  • La forma en que se trabajó (proceso)
  • El hecho de que el software quedó funcionando en manos del usuario (valor)
  • El hecho de que el software optimiza un proceso negocio con impacto en la sociedad (valor)

Los dos primeros ítems son bastante esperables por tratarse de un desarrollo realizado en un contexto académico, pero los últimos dos me parece que no son tan comunes y son de gran valor.

La aplicación fue construida con Grails + Angular, dos tecnologías que los alumnos tuvieron que aprender como parte del alcance del trabajo.

Mis felicitaciones para Marcia y Néstor por el trabajo realizado y también mi agradecimiento por haber confiado en mí para la dirección del trabajo.

fidel_marcia_nestor
Néstor, Marcia y Fidel

 

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í.

Ideas para trabajos de fin de carrera

Quiero compartir algunas ideas para posibles trabajos de final de carrera, de haber algún interesado no dude en contactarme.

SmallChat

Es una aplicación de chat integrada en Pharo Smalltalk. Permite chatear y compartir código entre las imágenes. El escenario típico es un estudiante/aprendiz está trabajando en Pharo y se traba con un problema que no puede resolver, entonces inicia una sesión de chat, pide ayuda y puede compartir su código con otros participantes del chat.

Cloudeta

Es un gestor de publicaciones digitales basado en la nube. Básicamente permite tomar archivos de publicaciones (libros, artículos, etc) agregarles metadata y almacenarlas en la nube. Una vez almacenados permite buscar por diversos criterios y compartir los archivos.

AlfredSEAL

Estos dos sistemas ya existentes (y en uso) que permiten gestionar la publicación, entrega y corrección de trabajos prácticos de materias de programación. Ambos sistemas tienen un backlog de funcionalidades por implementar.

 

Un caso robusto de integración contínua en Java

En el proyecto en el que he estado trabajando los últimos meses tenemos montado un proceso de integración continua bastante completo en mi opinión, comparto aquí algunos detalles. Se trata de un proyecto Java, basado en Spring, Hibernate, Camel y algunos otros frameworks. A nivel de herramientas tenemos quality checks con PMD, pruebas unitarias y de aceptación con JUnit y pruebas de aceptación y carga con JMeter. Como herramienta de build usamos Maven, como servidor de integración continua usamos Jenkins y el código lo tenemos en Git (gitlab). Al mismo tiempo tenemos un ambiente de tests en la nube donde desplegamos nuestra aplicación periódicamente. También tenemos un ambiente de prueba en las oficinas del cliente, donde desplegamos nuestra aplicación al final de cada iteración. En el jenkins tenemos varios jobs:

  • integración continua: monitorea el branch develop y ante cada cambio compila, ejecuta las pruebas de JUnit (unitarias y de integración)
  • quality-check: se ejecuta a continuación del job de integración continua y caso_java_jenkins_2básicamente ejecuta análisis de código (pmd)
  • integración continua de branches: en algunos casos creamos feature-branches, para lo cual seguimos una convención de nombres y este job se encarga de ejecutar integración continua sobre estos branches. En general procuramos que estos branches no vivan más de 3 días.
  • inicialización: es el job que dispara el build pipeline, y como tal comienza por inicializar el ambiente de test. Se ejecuta periódicamente (varias veces al dia siempre que haya cambios en el repositorio)
  • deploy: son dos jobs que se encargan de desplegar las dos aplicaciones que forman parte de nuestro sistema.
  • pruebas de aceptación: ejecuta las pruebas de aceptación (codeadas con jmeter) luego de cada despliegue
  • pruebas de carga: ejecuta un conjunto de pruebas de carga. Este job lo ejecutamos manualmente al menos una vez por iteración para asegurarnos que los cambios realizados no haya impactado en la performance del sistema
  • generador de release: este job lo ejecutamos manualmente al final de cada iteración para generar un nuevo release lo cual implica: taggear el repo, generar y publicar los artefactos (wars y jars) y actualizar la versión en los archivos del proyecto (pom.xml)
  • generador de instalable: este job toma  los artefactos generados por el job de generación de release y los empaqueta junto con un grupo de scripts que luego se utilizarán para instalar  el sistema en los ambientes del cliente.

caso_java_jenkins