Mes: diciembre 2023

[off-topic] Las Heras Basket 2023

Una vez más hago una excepción en la temática habitual de este espacio para compartir algunos datos y sensaciones de mi otra pasión: el basket.

Este año volvimos a juntar a la banda para darle más constancia a la práctica del deporte. Ese mismo grupo de Las Heras Basket del que ya escribí en alguna otra ocasión en este espacio. 

Lo primero que hicimos fue tramitar un espacio para practicar, hablamos con el secretario municipal de deportes, Pablo Dotti, para poder utilizar el gimnasio municipal.

Luego contactamos a Ale Palomero, quien nos formó basketbolísticamente a varios de nosotros, para que nos entrene.

Y así, en marzo, empezamos a entrenar y a jugar algunos partidos amistosos contra otros equipos de la zona.

En mayo/junio llegó la invitación de la gente de Lobos Athletic Club para armar una liga de Maxi Basquet (maxi es el nombre que se le suele dar a la categoría de mayores de 35 años). Se armó un grupo de coordinación, en el cual estuve participando como representante de nuestro equipo, y empezamos a darle forma a la liga. Se empezaron a sumar equipos: Dorrego (Navarro), Roque Perez Basket y Unitarios (Marcos Paz). Luego de un par de reuniones por Zoom y algunos encuentros de partidos amistosos para conocernos largamos la Liga Lobense de Maxi Basket. Acordamos jugar una fecha cada 2 semanas en una única sede rotativa. Luego de la primera fecha se sumó un sexto equipo: Sportivo (25 de Mayo).

El pasado 16 de diciembre se jugó la última fecha de liga donde Unitarios se consagró como campeón de esta primera edición de la liga. Nosotros quedamos en el sexto lugar, últimos pero contentos con haber completado el campeonato. Por momentos pensé que no lo lograríamos por estar muy cortos de jugadores. Yo en lo personal apenas pude participar en dos fechas debido a una lesión de tobillo que me paró 3 meses y a algunos compromisos personales. Logramos completar la participación en la liga pero me temo que no logramos consolidar un equipo para la competencia. Una muestra de esto es que solo tuvimos un jugador que pudo estar presente en todos los partidos.

Más allá de nuestra participación en la liga, completamos el 2023 con un total de 24 partidos (9 victorias y 15 derrotas).

En lo personal estoy muy contento con lo logrado. Creo que de cara al año próximo tenemos el desafío de volver a participar de la liga y adicionalmente intentar consolidarnos como equipo afianzando una identidad de juego.

Para cerrar quiero agradecer:

  • A Pablo Dotti y al gobierno municipal por habernos prestado el gimnasio.
  • A Ale Palomero que no dudó ni un minuto cuando lo fuimos a buscar para sumarse a esta iniciativa
  • A la gente de Lobos por haber tenido la iniciativa de comenzar con la liga y habernos invitado a participar.

Sobre el uso y la enseñanza de Mob/Pair Programming

La práctica de Pair-Programming es un caso que me llama poderosamente la atención:

  1. Es una práctica que formalmente tiene ~25 años (o tal vez incluso más) [1].
  2. Hay numerosos estudios que respaldan sus beneficios [2,3] y por ello es que la utilizo en mis proyectos y también la enseño en mis cursos.
  3. Pero curiosamente es una práctica muy poco utilizada [4].
  4. Finalmente es una práctica mal interpretada, o sea: hay gente que cree que Pair-Programming es simplemente sentar dos programadores a trabajar en una máquina cuando en realidad hay mucho más que eso. (de esto no tengo pruebas pero tampoco dudas).

Este es un tema que en MeMo2 le damos bastante importancia por varias cuestiones:

1. Los beneficios que trae la convierten en una práctica importante.

2. «El ruido» y malas interpretaciones que hay sobre esta práctica.

3. Creemos fundamental que los alumnos prueben usar la práctica: si no la prueban en nuestra materia creemos muy poco probable que tengan chance y ganas de probarla en otros contextos.

Este cuatrimestre en MeMo2 pedimos a los alumnos que en el primer trabajo grupal nadie escriba código en solitario, o sea: estaban obligados a trabajar todo tiempo haciendo mob/pair programming. Obviamente antes de esto explicamos la dinámica de esta práctica.

En el segundo trabajo grupal cambiamos la consigna, les sugerimos que hagan mob-programming durante toda la primera iteración y que luego de eso trabajen de la forma que consideren más apropiada en las dos iteraciones siguientes. Pero fue solo una sugerencia y como tal no había obligación que la siguieran.

Una vez finalizado el segundo trabajo hicimos una actividad donde les pedimos a los alumnos que individualmente evaluaran la experiencia con cada una de las técnicas, solo-pair-mob, considerando: 1) cuánto utilizaron cada técnica y 2) cúan útil/cómodo que les resultó.

A continuación comparto los resultados para que el lector saque sus propias conclusiones. Yo hace mucho que me convencí que el camino no es solo, parece que no soy el único.

Referencias

[1] Beck, K. (1999). Extreme Programming Explained: Embrace Change. United Kingdom: Pearson Education.

[2] L. Williams, R. R. Kessler, W. Cunningham and R. Jeffries, «Strengthening the case for pair programming,» in IEEE Software, vol. 17, no. 4, pp. 19-25, July-Aug. 2000, doi: 10.1109/52.854064.

[3] Chong, Jan & Plummer, Robert & Leifer, Larry & Klemmer, Scott & Eris, Ozgur & Toye, George. (2005). Pair programming: When and why it works.

[4] Paez, N., Fontdevila, D., Gainey, F., Oliveros, A. (2018). Technical and Organizational Agile Practices: A Latin-American Survey. In: Garbajosa, J., Wang, X., Aguiar, A. (eds) Agile Processes in Software Engineering and Extreme Programming. XP 2018. Lecture Notes in Business Information Processing, vol 314. Springer, Cham. https://doi.org/10.1007/978-3-319-91602-6_10

Cierre de cuatrimestre 2023-2 en MeMo2 @ FIUBA

Terminamos el cuatrimestre y me alegra tener la sensación de que seguimos mejorando. Continuamos con el horario matutino de 8 a 11, excelente. Y mantuvimos el mismo porcentaje de clases presenciales/virtuales.

Como siempre hicimos un par de ajustes respecto del cuatrimestre anterior, algunos de ellos basados en el feedback de los alumnos y otros surgidos del equipo docente.

  • Uno de los ajustes más importantes fue ser más explícitos sobre la «programación colaborativa» (mob y pair programming), por momentos pedimos explícitamente que no programen en solitario. Esto generó cierta «incomodidad» entre algunos alumnos por verse obligados a coordinar horarios con sus compañeros para hacer algunas tareas. Pero creemos que el resultado fue muy positivo ya que percibimos que se trabaron menos con cuestiones técnicas lo que les permitió terminar las tareas en menos tiempo y con menos grado de «frustración».
  • Una novedad fue que para los trabajos grupales, agregamos un facilitador «externo» para las retrospectivas al final de cada iteración iteración. O sea: cada grupo ya tenia un docente en el rol de Product Owner y a eso agregamos un segundo docente que solo se sumaba para facilitar las retrospectivas.
  • Otro de los ajustes, no tan visible para los alumnos, tuvo que ver con la infraestructura que utilizamos para el trabajo final debido a algunos cambios en Okteto. Básicamente dejamos de utilizar Okteto y directamente pusimos (casi) todo a correr en nuestro propio cluster Kubernetes en Digital Ocean.
  • También pusimos un poco más de foco en las cuestiones relacionadas a la operación o mejor dicho lo que suele llamarse «build for operations»
  • Finalmente, estrenamos un nuevo trabajo final que nos trajo renovados desafíos para el equipo docente.

Tanto en la retrospectiva final como en la encuesta de cierre, tuvimos feedback muy positivo de los alumnos. Comparto algunos números de la encuesta:

  • La encuesta fue contestada por la totalidad de los alumnos que completaron el curso (11)
  • La evaluación general de la materia (en promedio) dio 9.0, lo cual es mayor que el cuatrimestre anterior (8,8).
  • Respecto del porcentaje de clases presenciales/virtuales, 10 alumnos lo consideraron apropiado mientras que solo 1 hubiera preferido más virtualidad.
  • Las otras dimensiones de evaluación de la materia también resultaron muy positivas: claridad de los docentes: 4,7/5; Conocimientos de los docentes: 5 /5; Dinámica de las clase: 4,6/5; Materiales de estudio: 4/5.
  • La dedicación semanal a la materia extra clase dio un promedio de 8,7 lo cual me parece puede estar un poco distorsionado por la últimas semanas en las que los alumnos trabajaron en el trabajo final.
  • El NPS nos dio 63 (esta es una métrica que puede tomar valores en el rango -100 +100)

Algunos otros números del cuatrimestre:

  • Comenzamos la materia con 13 alumnos dos de los cuales abandonaron aproximadamente a mitad de cuatrimestre. Finalmente completaron la cursada 11 alumnos. Luego todos aprobaron el final.
  • Tuvimos 40 tareas individuales que incluyeron: lecturas, videos, cuestionarios y ejercicios de programación
  • Tuvimos 1 tarea para trabajar en parejas y dos trabajos grupales con grupos 3 o 4 alumnos
  • La calificación promedio de aprobación fue 7,1

Resulta curioso que si bien los números de la encuesta dieron mejor que el cuatrimestre anterior, la calificaciones fueron más bajas, un fenómeno para analizar.

Respecto de la dedicación, el análisis de la información reportada por los alumnos nos indica que:

  • La dedicación promedio extra-clase por persona sin considerar los trabajos grupales fue de 65 horas
  • La dedicación promedio extra-clase por persona para los trabajos grupales fue tp1: 6 horas y tp2: 14 horas
  • En términos generales la dedicación extra-clase promedio por persona a lo largo de toda la materia fue de 7,7 horas semanales.

Ingeniería de Software Continua: Fin de primer cuatrimeste & Inscripción 2024

La semana pasada completamos el primer cuatrimestre de la Diplomatura en Ingeniería de Software Continua. Dictamos dos materias: «Diseño y Evolución de Arquitecturas de Software» e «Ingeniería de Software Moderna» las cuales tuvieron 12 alumnos, un muy buen número para la dinámica de clases que diseñamos. El feedback de los participantes fue muy positivo y desde el equipo docente también quedamos muy contentos.

Para ser preciso debo decir que no yo dicté ninguna materia, sino que cuando digo dictamos lo hago desde mi rol de coordinador de la carrera.

El dictado del segundo cuatrimestre comenzará en Abril 2024 con otras dos materias: «Operación y Gestión de Servicios de Software con DevOps» y «Continuous Delivery«, esta última está a mi cargo. Dada la flexibilidad con la armamos el plan de estudio, los interesados en hacer la carrera pueden sumarse en este segundo cuatrimestre y luego completar el diploma en la segunda mitad de 2024. Más aún, si alguien no quiere hacer la carrera completa sino alguna materia puntual, también es posible. Para despejar estas dudas y cualquier otra que los potenciales interesados puedan tener, este miércoles 13 a las 12:00 horas (hora Argentina, gmt-3) estaremos dando una charla informativa (online). Los interesados en participar pueden completar este formulario para que les pasemos los datos de conexión.

Sobre las poco conocidas Pruebas end-to-EDGE

Tengo la sensación que este tipo de pruebas no es muy conocido y al mismo tiempo es un tipo de prueba que me parece fundamental para poder trabajar en un esquema de entrega continua. Paso a explicar.

En la actualidad es muy común que una aplicación tenga dependencias que no están bajo nuestro control, típicamente alguna API de un servicio externo. Ejemplos típicos podrían incluir un servicio de pagos o un proveedor de información climática. Esos servicios externos pueden ser parte de nuestra misma organización o no, pero en ambos casos el punto en común es que no tenemos control sobre ellos.

Muchas veces esta dependencia resulta un impedimento para poder testear nuestra aplicación y aquí está el punto clave a la hora de querer implementar una estrategia de entrega continua. Si queremos trabajar en un esquema de entrega continua tenemos que poder testear (casi) todo nuestro código sin depender de la disponibilidad del servicio externo.

En una prueba end-to-end testeamos todo nuestro código incluida la interacción con las dependencias externas.

En una prueba end-to-EDGE testeamos todo nuestro código sin «tocar» las dependencias externas. Esto lo hacemos utilizando «un doble de prueba» de la dependencia. Una forma de implementar esto es usando una herramienta tipo Wiremock.

Cabe destacar aquí, que en estos tests end-to-edge, nuestra aplicación «no sabe» que está interactuando con un doble de prueba, pues lo único que hace es tirar un request sin saber quién está del otro lado. Al mismo tiempo como ese doble de prueba está bajo nuestro control, tenemos la posibilidad de generar respuestas que nos permitan ejercitar distintos escenarios, algo que muchas veces no es posible con las pruebas end-to-end, pues en la prueba end-to-end no tenemos control sobre esa api/depedencia externa. ¿Cómo haríamos para probar el comportamiento de nuestra aplicación cuando esa api/dependencia externa falla? ¿Llamamos al dueño de la api/dependencia externa y le decimos que la apague un rato para poder probar el escenario de error? No parece factible, lo que debemos hacer no es una prueba end-to-end, sino una prueba end-to-edge que utilice nuestro doble de prueba en lugar de la api/dependencia externa real.

Una última consideración, si vamos a hacer pruebas end-to-edge utilizando un doble de prueba de la api/dependencia externa, debemos entonces también tener alguna prueba de integración que verifique la correcta interacción con la api/dependencia externa, pues sin eso corremos el riesgo de que la api/dependencia externa cambie y nosotros no nos enteremos pues confiamos en la corrección de nuestro doble de prueba que podría quedar desactualizado. Esas pruebas de integración con la api/dependencia externa no es necesario que sean pruebas end-to-end, sino que basta con que sean pruebas puntuales del componente/conector que encapsula la interacción con esa api/dependencia externa. Finalmente es importante que esas pruebas de integración se ejecuten periódicamente aún cuando no haya cambios en nuestro código, pues puede que se produzcan cambios en el api/dependencia externa y no nos avisen.

Para intentar clarificar varias de estas ideas he grabado una par de videos explicando esto con gráficos y código.