Hace un par de semanas me sumé a un nuevo proyecto para colaborar en cuestiones de operaciones/arquitectura. Cuando me hicieron la propuesta para sumarme no lo dudé ni un momento pues el contexto me resultó super interesante:
Plataforma multi-tenant de administración de contenido + aplicación móvil para consumo del contenido
Integración con redes sociales
Características de red social (contenido social compartido, picos de carga, potencial de cientos de miles de usuarios, etc)
Frontends Angular y iPhone
Backend Python
Infraestructura Cloud en Amazon
Equipo de 12 personas incluyendo devs, un especialista en ux, un tester y un coach (y ahora yo en rol de devop)
Cliente remoto (en US) y equipo de ingeniería distribuido en 3 cuidades.
La dinámica que voy a describir aquí fue diseñada por Gabi Falcone para una clase de Algo3@Fiuba. El objetivo de la misma es presentar las pruebas automatizadas y su uso como herramienta de especificación.
Contexto: en el curso tenemos alrededor de 50 alumnos. El aula de clase no tiene computadoras, pero algunos alumnos traen sus portátiles.
Preparación
Previo a la clase se le pide a alumnos resolver un problema de programación que implica crear algunas clases. En necesario contar con al menos dos problemas de complejidad similar. Dependiendo de la cantidad de alumnos puede resultar conveniente contar con más problemas. En nuestro caso trabajamos con 3. Se le pide a cada alumno resolver solo uno de los problemas. Para esto nosotros solemos utilizar una heurística basada en el número de padrón:
padrones terminados en 0,1,2,3 => problema 1
padrones terminados en 4,5,6 => problema 2
padrones terminados en 7,8,9 => problema 3
La clase comienza con una explicación conceptual de pruebas unitarias automatizadas y del framework xUnit. En nuestro caso explicamos SUnit pues trabajamos con Smalltalk. Luego de la explicación se pone manos a la obra con la dinámica de trabajo interactiva.
La dinámica se hace en grupos donde cada grupo tiene una computadora. El primer paso entonces es armar los grupos. Se le pide a todos que salgan del aula, armamos tres filas con la gente que había resuelto cada variante del problema pedido inicialmente. A continuación en cada fila se le pide a los que tengan computadora que pasen al frente y elijan 2 o 3 compañeros de la fila que no tengan computadora. Así quedan armados los grupos. A continuación se les pide volver a entrar al aula y que se ubiquen en las mesas según los grupos armados.
Primera etapa
A cada grupo se le pide que escriba un conjunto de pruebas unitarias para el problema que les tocó resolver. Como todos los alumnos de un mismo grupo ya han resulto el mismo problema, la escritura de las pruebas resulta bastante directa. Al mismo tiempo como ya tiene el código que resuelve el problema, los alumnos pueden ir corriendo los tests a medida que los van escribiendo. Explícitamente se les indica que roten el conductor (la persona que está al teclado) con el fin de que todos tengan el teclado un rato. En concreto cada prueba debe ser codeada por una persona distinta.
Al cabo de 30 minutos deberían tener una cantidad relevante de pruebas.
Segunda etapa
Cada grupo entrega el conjunto de pruebas creadas (sólo el código de las pruebas, no el código que hace pasar las pruebas) a otro grupo que haya estado trabajando sobre un problema distinto. Ahora cada grupo debe resolver un problema nuevo pero en este caso tiene un conjunto de pruebas como especificación de lo que debe resolver y al mismo tiempo puede ir corriendo esas pruebas para verificar la solución que va generando. Una vez más se pide explícitamente que vayan rotando el conductor.
Al cabo de unos 30 minutos, deben tener la mayoría de las pruebas pasando.
Cierre
Aquí se pide a los alumnos dejar a un lado las computadoras para hacer una puesta en común de la actividad. Se plantean algunas preguntas para disparar la discusión:
¿Cómo les resultó la experiencia en general?
¿Cómo les resultó el resolver un problema a partir de una especificación en forma de pruebas?
¿Cómo les resultó escribir pruebas para un problema ya resuelto? ¿Qué utilidad le ven a esto?
Nota: tener presente que durante esta actividad no se hace TDD sino que simplemente se utilizan pruebas como especificación lo cual es solo una parte de TDD. Notar que aquí el trabajo comienza con todo un conjunto de pruebas ya escrito, mientras que en TDD las pruebas se van escribiendo de a una por vez.
My session proposal for the Extreme Programming Conference was accepted so now I must practice to ensure a clean delivery.
The session is based on my Software Engineering course at UNTreF but I need to perform some modifications in order to delivery it in 6 hours.
The session is called «Modern Extreme Programming Workshop» and it is focused on how Extreme Programming practices have evolved and how they are being used by (some) development teams nowadays. The session is hands-on so the participant we will have the chance to apply XP practices while working in a «real world» Java application. Among the practices we will cover Behaviour-Driven Development, Mob Programming, and Continuous Delivery. Regarding tools and technologies, we will work with Java, Gradle, Cucumber, Jenkins and Ansible.
To practice before the conference I will run this workshop in Buenos Aires (but in English). If you are interested in participating just fill this form (programming experience required).
Maven es una herramienta de build, posiblemente la más utilizada en la actualidad en el mundo Java.
Una herramienta de build es un herramienta que permite «buildear» un proyecto. «Buildear» (ejecutar un proceso de build) implica ejecutar un conjunto de tareas las cuales pueden variar dependiendo de cada proyecto. En el caso más básico el proceso de build implica tan solo compilar. En casos más avanzados el build implica ejecucar algunas otras tareas como ser: resolución de dependencias (previo a la compilación), verificación de estándares de codificación, ejecución de pruebas automatizadas, generación de paquetes binarios, etc.
En algunos casos las herramientas de build pueden utilizarse con distintos lenguajes de programación, pero en general cada lenguaje de programación tiene alguna herramienta de build «preferida». Entre las herramientas de build más populares en la actualidad se encuentran:
Maven, Ant y Gradle (Java y derivados)
MSBuild y NAnt (C#)
Grunt y Gulp (JavaScript)
Rake (Ruby)
Algunas herramientas de Build funcionan con un conjunto de tareas predefinidas (que pueden extenderse), mientras que otras dependen completamente de la definición que haga el usuario.
Todas estas herramientas de build toman como entrada un archivo que describe generalidades del proyecto a buildear (cosas como nombre del proyecto, autor, versión, etc) y la lista de tareas a ejecutar.
Maven es una de las herramientas de build que ya trae un conjunto de tareas predeterminadas. Más concretamente Maven define lo que llama un ciclo de vida, el cual incluye diversas fases y tareas asociadas a cada una. Al mismo tiempo Maven define un serie de convenciones respecto de la estructura de carpetas del proyecto. Entonces para usar Maven deberemos:
Crear una estructura de directorios acorde a lo definido por Maven (en realidad la estructura exacta depende del tipo de arquetipo utilizado, pero ello es un tema avanzado)
Incluir en la raíz del directorio un archivo llamado pom.xml que describa nuestro proyecto
Ejecutar Maven indicando la fase deseada. Aquí debemos tener presente que cuando indicamos una fase, Maven ejecutará la fase indicada pero previamente ejecutará todas las fases anteriores. O sea, cuando uno le indica a Maven una fase X, lo que le está diciendo es: quiero ejecutar el ciclo de vida completo hasta la fase X
Una problemática común para aquellos que trabajamos en el mundo del software es la disponibilidad de nuestras aplicaciones. En primera instancia es imprescindible entender las necesidades de disponibilidad que debe cumplir nuestra aplicación. Esto es una definición que viene dada por una restricción del negocio. En ese sentido hay aplicaciones que solo deben están disponibles en horario de oficina (de lunes a viernes a 9 a 18), mientras que hay otras que puede que solo requieran estar disponibles ciertos días por mes. Y obviamente también están aquellas aplicaciones que tienen que estar disponibles 7 x 24. Esta es una cuestión de negocio que tiene un impacto enorme en las cuestiones técnicas. Desde el punto de vista de desarrollo tenemos que tomar cierta precauciones en el diseño y codificación de nuestra solución. Al mismo tiempo también debemos observar ciertas cuestiones en lo que respecta a la arquitectura física de la solución. Finalmente debemos tener presente una serie de cuestiones operacionales como ser backups, failover, escalamiento, etc. Como consecuencia de varias de estas cuestiones surge la necesidad de ser capaces de detectar una interrupción del servicio ANTES que se entere el usuario final. Más aún, lo ideal es detectar en forma anticipada una posible interrupción para intentar evitarla. Esto implica implementar una estrategia de monitoreo.
Cuando hablamos de monitoreo tenemos distintos niveles:
Capa 1: hardware / sistema operativo, aquí miramos cpu, memoria, disco, red, etc.
Capa 2: middleware, aqui miramos métricas particulares del midddleware como ser métricas de la JVM, del web server, la DB, etc
Capa 3: aplicación, aquí miramos cuestiones más concretas cercanas al dominio de nuestra app. Incluyo aquí tiempo de respuesta, tiempo de carga de las páginas, y también cuestiones como cantidad de usuarios con sesión activa, etc.
Para monitorear cada una de estas capas hay distintas alternativas. Cuando uno corre con una infraestructura de cloud, el proveedor de cloud típicamente provee monitoreo de capa 1. El monitoreo a este nivel es transparente para la aplicación.
Para capa 2 el monitoreo también puede hacerse de forma transparente, y las herramientas para hacerlo dependen en gran medida de cual sea nuestro middleware, o sea, no es lo mismo monitorear tomcat que nginx. Una herramienta de uso común aquí es Nagios (aunque Nagios también puedeusarse en capa 1).
Para capa 3 implementar monitoreo requiere algunos ajustes a nivel de aplicación, o sea, las soluciones tienen cierto grado de intrusión en nuestra aplicación y suelen requerir algunos cambios en nuestro código. Las soluciones son diversas y pueden mezclase. Un caso típico es utilizar Google Analytics para medir tiempos de respuesta y permanencia de los usuarios en ciertas páginas.
Obviamente existen algunas soluciones que proveen la posibilidad de monitorear las 3 capas de manera unificada. A mi parecer la solución más popular a en este segmento es New Relic.
Por otro lado el monitoreo implica 2 cuestiones centrales:
Recolección de datos
Ejecución de acciones ante determinadas situaciones. De mínima tenemos el envió de alertas, pero también podríamos activar acciones de escalamiento.
Lo mencionado anteriormente sobre los niveles de monitoreo aplica a la recolección. Respecto de la acciones a ejecutar, ahí también tenemos diferencia en la solución de monitoreo elegida. En este sentido, si la aplicación va a estar disponible 7×24, es posible que el envío de mails no sea suficiente y tengamos que echar mano de mensajes a directos a un teléfono de guardia.
Intenso. Había tanta gente con tanta energía que simplemente las charlas se extendían horas y horas. En general la actividad «oficial» arrancaba alrededor de las 9 am, pero ya desde las 7 am había gente activa: algunos haciendo meditación, otros ejercicio físico, otros simplemente tomando mate y disfrutando del paisaje. Por la noche la actividad se estiraba más allá de media noche. Personalmente nunca me acosté antes de las 2.30.
Al igual que el año pasado, el evento fue en formato open space con el agregado de algunos keynotes. Me resultó muy interesante la variedad de los keynotes. El primer keynote fue de @FerClaverino quien nos deleitó con historias y magia (literalmente hizo varios trucos/ilusiones). El segundo fue de Hiro quien usando un formato más tradicional nos habló sobre estrategias para mejora. El tercero fue el de Tulio Calderón quien nos habló sobre los desafíos para el desarrollo de alta tecnología en Argentina. Finalmente el cuarto keynote fue el de Juan Daza, quien parado a la orilla de rió con la montaña de fondo nos hizo reflexionar sobre redes, transversalidad y evolución. Todos los keynotes me parecieron excelentes: expositores claros, presentaciones bien preparadas y temáticas interesantes.
Keynote de Juan Daza
En este AOC Hubo más participantes que el año anterior y con perfil más diverso lo cual tuvo un impacto directo en las temáticas de las sesiones. El grueso de las sesiones estuvo alrededor de cuestiones de gestión, hubo muy pocas sesiones técnicas y una cantidad interesante de sesiones de temáticas «desconectadas» ( katas de guitarra, un taller de fotografía, bitcoins, artes marciales, etc).
También hubo diversos grupos autoorganizados que llevaron adelante diversas iniciativas «artísticas». Juan Zapico coordinó un grupo que participantes que filmaban escenas espontáneas del evento y las editaban para compartirlas en un único video de unos 10/15 minutos al final de cada día. Pablitux coordinó un conjuntos de participantes con habilidades musicales para componer una canción para del evento, una especie de «Himno del Agile Open Camp». Finalmente yo repetí la experiencia del año anterior y coordiné la escritura de un libro sobre herramientas ágiles (más detalle de esto último en un futuro post).
Otra particularidad de este año fue la gran cantidad de participantes extranjeros. Más allá de argentinos, hubo gente de Chile, Uruguay, Perú, Colombia, Ecuador, Venezuela y Costa Rica
Me cuesta decir si esta edición 2016 estuvo mejor que la 2015, creo que fue distinta, no solo por el lugar sino principalmente porque los participantes fueron distintos y es justamente la gente el factor determinante en eventos tan «inmersivos».
Para cerrar doy las gracias al grupo organizador, disfruté muchísimo y espero que se repita.
El último fin de semana estuve participando del Agile Open Camp. En un momento dado me encontré compartiendo una mesa con otros cuatros egresados de FIUBA y curiosamente todos ex-alumnos de Carlos Fontela en Algo3. Pero como si fuera poco, había en la conferencia algunos otros ex-alumnos que no estaban en la mesa en ese momento.
La coincidencia nos pareció divertida así que al día siguiente nos sacamos una foto todos juntos.
Arriba: Marcos Pozzo, Fer Claverino, Ricardo Markiewicz, Vanesa Savino, Pablo Suarez, Elias Molini. Abajo: Pablo Tortorela, NicoPaez, Sole Pinter.
Una simple búsqueda en Google del término «microservices» nos arroja unos 710.000 resultados. Entre los tres primeros están: un artículo de Martin Fowler, la correspondiente página de wikipedia y el sitio microservices.io.
El lunes pasado tuvimos mesa de examen en Algo3 y el examen que tomamos fue el mejor que vi en mi vida entera. El examen consistió en un ejercicio práctico, cada alumno estaba con su computadora y le entregamos un conjunto de clases que resolvían un problema dado. La consigna era simple: analice el código y mejorelo. Luego de cierto tiempo (unos 30 minutos) un docente se sentaba con cada alumno para hablar con él sobre las mejoras realizadas.
Obviamente el código entregado tenía una serie de «cochinadas» algunas muy groseras y otras menores. La expectativa era que los alumnos fueran capaces:
Identificar las «cochinadas»
Explicar los problemas que las mismas podrían acarrear
Proponer modificaciones a la solución para remover «las cochinadas»
Implementar esas propuestas en código
A mi me tocó evaluar a dos alumnos y el método me pareció simplemente genial, pues con preguntas muy concretas uno podía determinar si el alumno había incorporado, o no,los conceptos centrales de la materia.
Debo felicitar a Pablo Massuh y Gabi Devoto que fueron los ideólogos de este examen.
Pasado mañana larga el AOC 2016 y personalmente creo que hay una gran expectativa. En los últimos días he hablado con varias personas que asistirán a la conferencia y he notado un entusiasmo similar al mío. Estas sensaciones están justificadas por diversas cuestiones:
El escenario es simplemente in-cre-i-ble, el evento se llevará a cabo en un complejo a en las cercanias del Lago Escondido.
La experiencia de vivir tres días completamente inmersivos con 100 personas ávidas de compartir, aprender y pasarla bien no es algo que se pueda hacer muy frecuentemente.
Blog de NicoPaez 