Taller de TDD, CI & Pair-Programming

En el contexto de las Jornadas de Ingeniería de Software del Uruguay, estuve haciendo un Taller sobre Test-Driven Development, Continuous Integration & Pair-Programming.

Participaron del taller unas 19 personas y a pesar de algunos imprevistos (como que la gente no hubiera leído los materiales de preparación), el taller salió muy bien. La evaluación general del taller fue 4.4 / 5.

Dejo aquí los recursos que compartí con los asistentes del taller:

Primeras Jornadas de Ingeniería de Software del Uruguay (notas personales)

Los pasados martes y miércoles estuve participando de este evento. Tuve el honor de dar el keynote del martes. Hablé sobre un tema de moda que conozco con bastante profundidad: DevOps. Las diapositivas de mi exposición están disponibles aquí.

Entre las exposiciones que me resultaron más interesantes estuvieron:

  • La de Federico Toledo quien contó experiencias en pruebas de performance.
  • La de Guilherme Travassos, un reconocido académico brasilero, quien expuso sobre “Using validation sessions based on technology probe in software development to innovation
  • La de Jorge Corral que habló sobre la exportación de servicio de IT a USA
  • La de Nicolás Jodal,  quien habló sobre los desafíos de 30 años de evolución de Genexus (producto desarrollado por su empresa).

Más allá de las exposiciones hubo una mesa redonda de la que participaron varios referentes de la industria uruguaya del Software en la que se destacó la presencia de la Ministra de Industria Carolina Cosse.

Agradezco a Diego Valespir, Cecilia Apa y al resto del equipo organizador por la haberme invitado y los felicito por el gran evento realizado.

Libro recomendado: XP installed

Es domingo por la tarde, está anocheciendo. Estoy sentado en un sillón releyendo un libro para mi taller de TDD. El libro lleva
en mi biblioteca un buen tiempo pero no el suficiente, debería haberlo comprado antes.

Leo un par capítulos seguidos y me resuena lo que dice, pero al mismo tiempo me llama la atención. Lo que estoy leyendo me parece muy actual pero sospecho que el libro fue publicado hace unos 15 años. Entonces detengo mi lectura y reviso las primera páginas donde figura la información editorial. Efectivamente, el libro fue publicado en Diciembre del año 2000.


Se trata de “Extreme Programming Installed”, el libro de tapa rosa de la colección XP Series. Un libro escrito por Ron Jeffries, Ann Anderson y Chet Hendrickson. El libro es como un reporte de experiencia, los autores cuentan a lo largo del libro como aplican XP. Curiosamente los ejemplos de código están en Smalltalk, lo cual me resulta muy agradable :-).

ArqConf: Infrastructure as Code

El próximo 11 de Octubre se realizará una edición especial de la ArqConf sobre la temática particular de Infrastructure as Code.  En ese contexto estaré dando una charla titulada “Consideraciones de Diseño para un modelo de Infraestructura”. Lo sé, el nombre no resulta muy atractivo pero confío en que contenido resultará valioso:

De la mano de DevOps, SREs y un conjunto de herramientas, la práctica de Infraestructura como Código ha adquirido una gran popularidad en los últimos años. La adopción de esta práctica implica una toma de decisiones que entre otras cosas incluye el diseño de un modelo de infraestructura y la selección de herramientas asociadas. En esta sesión veremos un conjunto de conceptos y recomendaciones para tomar estas decisiones de cara a una efectiva implementación de la práctica de Infraestructura como Código.

La cita es el 11 de Octubre a partir de las 14.30 en las instalaciones de Universidad Tecnológica Nacional, FRBA en Medrano 951, más info y registración en meetup.

De la máquina del developer directo a Producción, sin escalas

Ayer estuve participando de un meetup donde Marcos Nils estuvo contando sobre su implementación de GitOps. Su presentación me pareció muy interesante pero lo que más me llamó la atención fue cuando comentó que en su organización no tienen ambiente de testing, ni staging, ni nada parecido, o sea: cada developer trabaja en su máquina, sube su código a Git y eso dispara una serie de pasos que terminan instalando una nueva versión en el ambiente productivo. No todos los pasos  son necesariamente automáticos, puede que haya algún trigger manual, pero el punto central es que la aplicación no es instalada en ningún otro ambiente más que el productivo.

Apenas escuché esto me resultó muy disruptivo, luego, en el intervalo hablé personalmente con Marcos y me siguió pareciendo disruptivo, ¡ja! Una estrategia de GitOps implica una alto de grado de automatización y el manejo de infraestructura como código, lo cual facilitaría mucho el armado de nuevos ambientes. Sin embargo, lo que me comentaba Marcos es que ellos hicieron un análisis y no encontraron la necesidad de un ambiente de prueba: tienen tests automatizados y algunas cosas las prueban directamente en producción utilizando usuarios particulares de forma de no interferir con los usuarios reales. La respuesta de Marcos me pareció razonable, pues tomaron las decisión con cierto fundamento y contando con toda una serie de medidas (automatización, monitoreo, alertas, etc) que les ayudan a mitigar algunos de los riesgos de no tener un ambiente de prueba.

Personalmente las veces en que me encontré con equipos/organizaciones sin ambiente de prueba, ha sido por la imposibilidad de armar dicho ambiente en lugar de ser consecuencia de una decisión analizada. Al mismo tiempo, en varios de los proyectos que he participado había un contexto de regulaciones que obligaban a contar con un ambiente de prueba/homologación, previo al ambiente productivo.

Pero quien sabe, tal vez algún día tenga la oportunidad de experimentar con una estrategia de este tipo.

El desafió de Enseñar a Diseñar

El desafió de Enseñar a Diseñar

Desde mi comienzo en la carrera docente siempre he estado en materias que en mayor o menor medida han incluido la temática de diseño de software. Cuando estaba en Algo3 y AyDOO era diseño a nivel de clases, ahora en MeMo2 cubrimos un poco de diseño a nivel de clases y también diseño de más alto nivel (arquitectura e infraestructura). Enseñar a diseñar es una tarea que me parece muy difícil. De entrada debemos decir que no hay diseños “malos” o “buenos”, sino que un diseño podrá ser más o menos conveniente dependiente del contexto. Un diseño es consecuencia de un conjunto de decisiones, diseñar es decidir, elegir. Pensando en el proceso de diseño veo al menos 3 pasos:
  1. Entender el contexto, el problema a resolver, las restricciones y necesidades. Esto es lo que Kazman denomina Architectural Drivers.
  2. Entendido el contexto hay que identificar las decisiones relevantes que deben tomarse.
  3. Finalmente para cada decisión relevante hay que analizar las posibles alternativas y elegir una. Esto puede implicar hacer algunas pruebas de concepto para poder tomar decisiones con evidencia que las respalde.
El punto 1 cae dentro del área denominada ingeniería de requerimientos y cuenta con un amplio cuerpo de conocimiento. El punto 2, ya es más complejo y más allá del cuerpo de conocimiento requiere de experiencia, lo cual es bastante difícil de transmitir. El punto 3 también reviste de complejidad pero creo que en general es más fácil que el punto 2. A mi parecer identificar opciones y evaluarlas para decidir es una trabajo en esencia muy ingenieril. A comienzo de año estábamos hablando con mi colega docente Diego Marcet sobre los criterios de corrección de un ejercicio de AyDOO y lo vimos:
Pretender que en un cuatrimestre académico alguien aprenda a diseñar es demasiado ambicioso, o sea, se puede enseñar algún método/heurística pero pretender dominarlo y generar buenos resultados puede ser difícil. Por ello ajustamos nuestro objetivo para centrarnos en dar a los alumnos herramientas para ser capaces de detectar las decisiones importantes y al mismo tiempo que sean capaces de detectar decisiones inapropiadas para un contexto dado.
De cara a este objetivo trabajamos bastante sobre código ajeno, o sea, analizando y extendiendo código existente. Continuará….

Mis notas de la 10Pines Conf 2018

Una casa con 10 pinos hacia el sur hay un lugar….

Así comienza la canción que da nombre a 10 Pines, esa empresa de la que son parte varios amigos y que ayer realizó su primer conferencia. La idea inicial de la conferencia fue de Ale Alfonso y luego hubo un grupo de varios pinos que se entusiasmaron y le dieron forma.

La conferencia fue interna pero con la participación de algunos amigos de la casa (como yo). La fecha elegida no fue casual, fue el día 256, el día del programador.

La jornada comenzó minutos antes de las 10 con la apertura de @lucas_giudice y cerró alrededor de las 18 con la certeza de una edición 2019. A lo largo del día participé de 5 sesiones cada una más interesante que la otra:

  • La de Nico PaPagna en la que compartió varias recomendaciones para hacer TDD
  • La de Fede Zuppa sobre Performance de Equipos
  • La de Nico Derecho sobre React Native
  • La de AgusGS sobre arquitectura Serverless
  • La de DarioG sobre Java-Spec

Adicionalmente a esto, también di una sesión sobre construcción de aplicaciones escalables (aquí están las diapositivas). Más allá de las sesiones en las que participé, creo que el programa ha sido de lo mejor que he visto en el último tiempo en Argentina (y tal vez incluso en la región).

Le agradezco a los pinos por haberme invitado a participar y al mismo tiempo los felicito por la movida.