Cambios en MeMo2 @ FIUBA

Para este segundo cuatrimestre de 2022 estamos considerando realizar varios cambios en la dinámica de la materia.

En primer lugar tenemos un cambio importante en el equipo docente. Emilio Gutter quien venía desempeñando funciones de JTP ya no estará en la materia. Su lugar lo tomará, al menos parcialmente, Hernán de la Fuente, ex-alumno de la materia, miembro del equipo hace ya varios años y muy próximo a graduarse. También tenemos algunos otras bajas, no todas ellas cubiertas, con lo cual el tamaño del equipo se verá disminuído.

Por otro lado vamos a cambiar el orden de algunos temas y la forma en que los damos. Vamos a mantener una modalidad híbrida en la apuntamos a realizar cambios significativos en la dinámica de las clases presenciales.

También tenemos la intención de «reenfocar» algunas cuestiones, concretamente vamos a quitar un poco de relevancia al modelado de objetos/clases para poner más foco en el proceso de construcción (BDD/TDD) y el trabajo en equipo. Esto implica que algunos de los ejercicio individuales de programación pasarán a ser ejercicios en grupales.

Finalmente el último cambio es tal vez el de mayor impacto, vamos a cambiar el mecanismo de evaluación. Hasta el momento no tomábamos parciales ni final. La evaluación de los alumnos era constante a partir de las distintas tareas semanales y proyecto de TP. La idea es mantener eso pero adicionalmente agregar una instancia de evaluación al final de la materia donde cada alumno individualmente tenga que desarrollar «en vivo» una funcionalidad sobre su proyecto. Cuando digo en vivo me refiero a una sesión tipo pairing, donde el alumno acompañado por un docente desarrolla una funcionalidad de acuerdo al proceso y técnicas estudiadas en la materia. Esto no debería representar ningún desafío para los alumnos ya que es lo que hacemos durante la materia. ¿Entonces por qué lo vamos a hacer? Porque tenemos la sospecha de que al trabajar en equipo no todos los miembros asimilan los conceptos, como que algunos «delegan» en sus compañeros.

Se viene Nerdearla 2022

Este año Nerdearla tiene dos ediciones. Nerdearla 101, enfocada en aquellos que están comenzando en el mundo IT, que tendrá lugar esta semana: 5 y 6 de Agosto, gratis y en modalidad híbrida. Registración aquí. Estuve viendo la agenda y hay algunas sesiones muy interesantes incluso para gente ya experimentada. Aquí está publicada la agenda completa.

Por otro el Nerdearla «clásico» (novena edición) se realizará del 19 al 22 de Octubre también en modalidad híbrida. En este momento no hay mucha información al respecto pues el foco está en el evento 101 que es esta semana. Se sabe que la parte presencial será en el Konex (en Ciudad de Buenos Aires). Si están interesados en enviar una propuesta, pueden hacerlo aquí. El llamado está abierto hasta el 8 de agosto. Yo ya mandé mi propuesta, no se duerman.

Preparando Ingeniería de Software 2022 @ UNTreF

Luego de dos ediciones 100% virtuales volvemos a la presencialidad. Si bien la universidad habilitó la presencialidad plena, nuestra idea es tener un esquema híbrido. En principio estamos planificando al menos 4 clases presenciales y las restantes online.

En términos de contenido, no planeamos novedades.

En términos de la dinámica de las clases esperamos hacer un mix de lo que eran nuestras clases presenciales pre-pandemia y nuestras clases online de la pandemia.

Un cambio que estamos evaluando es respecto del trabajo grupal de la materia. Personalmente tengo la idea de que el trabajo tenga un complejidad funcional y técnica un poco mayor que lo que veníamos haciendo, de forma tal que nos habilite a poner en práctica algunas cuestiones que hasta el momento solo estudiábamos de forma más superficial.

Finalmente cierro con algunos datos relevantes para quienes tengan pensado cursar la materia este 2022:

  • La materia se dictará en modalidad híbrida y que la asistencia es obligatoria.
  • Semanalmente son 4 horas de clase y adicionalmente hay que dedicar como mínimo otras 4 horas de estudio (según reportan los alumnos suelen dedicar unas ~7 horas extra clase)
  • Utilizamos Git pero no enseñamos Git
  • Programamos con Ruby pero que no enseñamos Ruby
  • Damos por sabido todo lo visto en la materias anteriores, pero definitivamente lo más relevante es lo visto en las materias «Algoritmos y Programación (1,2 y 3)» y «Diseño y Arquitectura de Sistemas«

Testing automatizado en React-Native

Luego de 6 meses trabajando a diario con React-Native he logrado hacerme una idea bastante clara sobre esta temática que me parece no está suficientemente bien documentada.

En primer lugar tengamos presente que con React-Native vamos a generar aplicaciones móviles para Android y/o iPhone con lo cual un tipo de prueba automatizada que podremos realizar es directamente sobre el binario nativo que se instala en el dispositivo, serían las denominadas pruebas end-to-end que muchas veces se hacen en forma manual. Su ejecución requiere por un lado del uso de un emulador (o incluso se puede usar un dispositivo físico) y por otro, el uso de algún driver/conector que nos permita interactuar con la aplicación desde la perspectiva del usuario. Como estas pruebas van directamente contra el binario/ejecutable, tenemos independencia para codearlas en un lenguaje distinto al que utilizamos para codear la aplicación. La pieza central en este tipo de pruebas es el driver/componente que nos va a permitir manipular la aplicación emulando la interacción del usuario. En este sentido una de las herramientas más populares es Appium y otra es Detox.

Sacando las pruebas end2end, tenemos distintos tipos de pruebas de índole más técnico, de componentes/unitarios. Estas pruebas sí las estaremos codeando con la misma tecnología que codeamos la aplicación. En el caso de estar trabajando con React Native estas pruebas las vamos a codear con JavaScript. Aquí también entran en juego distintas herramientas. La primera de ellas es el framework de testing que utilizaremos para escribir los casos de prueba y agruparlos en suites. Aquí tenemos varias alternativas (como suele ocurrir habitualmente en JavaScript) pero al trabajar con React se suele utilizar Jest que es la herramienta recomendada en la documentación oficial de React. Jest nos va a permitir escribir casos de prueba sobre objetos/funciones JavaScript, sean estos componentes React o simples objetos planos «vanilla JavaScript». Una «bondad» que tiene Jest es que trae nativamente funcionalidades de mocking/stubbing con lo cual nos ahorramos de tener que incluir en nuestro proyecto otro framework/herramienta para mocking.

Si en nuestras pruebas queremos testear componentes React-Native, en particular el rendering, en primera instancia podemos utilizar el Test Renderer que es parte del core de React. También como parte del core de React tenemos las Test Utils que ofrecen un conjunto muy útil de funciones utilitarias.

También tenemos la posibilidad de utilizar React-Native Testing Library que debemos instalar por separado (yarn add –dev @testing-library/react-native). Esta librería construída sobre la base del Test Renderer y agrega un conjunto de funciones utilitarias de gran utilidad.

Docker: experiencia clone & run

Durante mucho tiempo al comienzo de mi carrera profesional como desarrollador (hace +20 años) era habitual que cuando uno comenzaba en un nuevo proyecto/trabajo, tenía que invertir varias horas instalando herramientas y ajustando configuración antes de poder tirar una línea de código. Esta situación sigue ocurriendo en muchas organizaciones/contextos. Sin embargo existe en la actualidad un conjunto de herramientas que pueden ayudarnos a tener experiencia mucho más fluida. Una de esas herramientas es Docker. Personalmente suelo hablar de una experiencia Clone & Run. Llegas a un proyecto, tomas tu host, instalas Git y Docker, ejecutas git clone y docker-compose up, buscas un café y al rato ya estas listo para empezar a codear. Explicar como lograr esto con texto puede resultar muy largo e inconveniente, por ello hice un video explicando y mostrando esta experiencia. Espero les resulte util.

Cierre de cuatrimestre en UBA: ¡volvimos!

Luego de dos años de completa virtualidad, en marzo de 2022 volvimos a las aulas. Pero dado que descubrimos que algunas cuestiones funcionaban mejor en modo virtual, la vuelta fue mixta. La facultad habilitó un esquema híbrido con un cierto porcentaje obligatorio de clases presenciales y el resto a criterio de cada docente. En el caso de MeMo2, hicimos principalmente presencial la primera parte de la materia y principalmente virtual la segunda parte.

Para ser «el primer cuatrimestre del regreso» creo que estuvo bien y confío en que aún podemos mejorar algunos aspectos. De todas formas tengo la sensación de que gran parte de los alumnos (¿casi todos?) prefiere quedarse en la virtualidad total. Al margen de la vuelta parcial a la presencialidad, este cuatrimestre tuvimos 2 cambios relevantes respecto de cuatrimestres anteriores: 1) dedicamos una clase a hacer el setup de la infraestructura del TP2 (creación del clúster de kubernetes, configuración del pipeline, etc), cosa que previamente lo veníamos haciendo los docentes «tras bambalinas» y 2) Reciclamos un TP2 existente (hasta el momento, cada cuatrimestre «inventábamos» un nuevo TP). Creo que ambos cambios fueron positivos.

En lo referente al desempeño de los alumnos notamos una disparidad importante en la dedicación del TP2. Contexto: el TP2 tiene un alcance fijo (negociable) y dadas las capacidades de cada equipo puede que el tiempo requerido para completarlo sea distinto para cada uno. Lo que vimos es que en términos de calificación todos los equipos tuvieron notas muy similares (menor dispersión de notas que cuatrimestres anteriores), pero al ver la dedicación tenemos en un extremo equipos que completaron el TP2 en ~80 horas mientras que otros dedicaron ~170 horas. Mi explicación de esto tiene que ver con 2 cuestiones: 1) afinidad de los miembros de equipo y 2) experiencia / «habilidad» técnica (no necesariamente en este orden):

  1. No es lo mismo un equipo cuyo miembros son amigos y vienen trabajando juntos en varias materias que un equipo cuyos miembros recién se conocen y que tal vez no se llevan muy bien.
  2. No es lo mismo un equipo cuyos miembros ya tienen experiencia profesional programando y están familiarizados con el stack de herramientas que un equipo donde no todos sus miembros tienen experiencia profesional programando y que desconocen completamente el stack de herramientas. Aquí también entra en juego «la maña» que cada uno se puede dar para resolver dificultades técnicas.

Respecto de 1) no veo que como docentes podamos hacer mucho más allá de permitir que los alumnos armen los equipos a su parecer y de forma temprana en la materia como para que se vayan conociendo. Respeto de 2) lo que intentamos hacer es contestar muy rápidamente las consultas de indole técnicas y proveer a los alumnos con guías/videos para facilitar las cuestiones técnicas/tooling.

Las encuesta interna del curso nos arrojó los siguientes números:

  • Evaluación general de la materia: 8.1 / 10
  • Conformidad con la nota de aprobación: 4.8 / 5
  • Dedicación semanal extra-clase: 8.6 horas
  • Materiales de estudio: 4.0 / 5
  • Claridad de los docentes: 4.3 / 5
  • Conocimientos de los docentes: 4.9 / 5
  • Dinámica de las clases: 4.1 / 5
  • Net Promoter Score: 37.5 (métrica que puede oscilar entre -100 y +100)

Comenzamos el cuatrimestre con 22 alumnos, 2 abandonaron en las primeras semanas y los restantes 20 aprobaron la materia. Lo nota promedio de evaluación fue 8 lo cual es lo mismo que el cuatrimestre anterior pero en este caso la dispersión fue menor.

Como de costumbre cerramos el cuatrimestre con una retrospectiva pero esta vez entre barbijos (que solo algunos nos los sacamos para la foto final)

Libro: Discovery (The BDD Books)

Ayer terminé de leer este libro cuyo nombre completo es «Discovery: Explore behaviour using examples«. Es el primer libro de la serie «The BDD Books» de Seb Rose y Gaspar Nagy. El foco del libro está en la utilización de ejemplos como «técnica de especificación funcional». En este sentido el libro provee una guía respecto de cómo, quien y cuando utilizar la técnica, dando respuesta no solo a las particularidades de la técnica sino también a cómo usar la técnica en el contexto de un proceso de desarrollo de una equipo/organización.

Debo decir que el libro me gustó mucho, es cortito y muy concreto. Provee ejemplos muy claros y fáciles de entender. Al mismo tiempo atiende dudas/situaciones que habitualmente surgen al intentar aplicar BDD en distintos contextos de proyecto.

Si bien mi referencia preferida en este tema son los libros de Gojko (Specification by Example y Bridging the Communication Gap), creo que este libro es más directo y por ello que puede resultar un muy buen punto de entrada para quienes no están familiarizados con la técnica. Claro que los libros de Gojko son mucho más amplios y profundos pero justamente por eso me parece que es mejor arrancar por aquí y eventualmente continuar con los otros.

El libro está disponible en LeanPub.

Plan de Virtualización de la Educación Superior @ UNTreF

Este plan es una iniciativa del Ministerio de Educación disparada a partir de la pandemia y de la cual han participado distintas instituciones. UNTreF es una de ellas. En el contexto de este plan UNTreF llevó a cabo distintas acciones de capacitación (en algunas de las cuales he participado). Precisamente ayer se realizó una jornada en UNTReF donde se expusieron cinco casos de «adaptación» de materias/carreras a los contextos de virtualidad. Mi caso fue uno de esos cinco.

Estuve presentando la dinámica de trabajo de la materia Ingeniería de Software que dicto con Diego Marcet.

La jornada fue en formato mixto, había unas ~50 personas en el auditorio y otras ~80 vía Zoom. Para mi sorpresa la jornada fluyó muy bien (digo para mi sorpresa porque mi experiencia con reuniones mixtas ha sido bastante mala).

La presentación de cada caso se hacía en 25 minutos y luego había 3 especialistas en el rol de comentaristas que justamente realizaban comentarios/observaciones luego de cada presentación de caso. Me alegra que la universidad tenga este tipo de iniciativas y felicito al equipo de organización.

Para los interesados aquí están las diapositivas que utilicé durante mi exposición.

Notas de Seminario de Software Delivery 2022

La semana pasada completamos la tercera edición de este seminario. Quedé muy conforme con el resultado. Creo que hemos consolidado tanto el contenido como la dinámica. Es esta edición tuvimos un cambio de equipo, cambiamos de Diego, estuve acompañado por Diego Marcet en lugar de Diego Fontdevila. Este cambio estuvo motivado en parte porque tenemos la intención de que DiegoF dicte otro seminario de postgrado en la segunda mitad de año enfocado en cuestiones de arquitectura (más información sobre este en un futuro post).

El seminario estuvo estructurado en 6 encuentros de 2,5 horas, uno cada dos semanas. Adicionalmente tuvimos algunas sesiones de consulta agendadas específicamente para ver cuestiones referentes a los trabajos finales.

Tuvimos 10 participantes de perfil variado, gente industria, gente de academia y tuvimos hasta un extranjero. De estos 10 participantes, 8 completaron el curso y 3 llegaron incluso a completar el trabajo final de aplicación en campo.

La evaluación de los participantes fue muy positiva. Ante la pregunta ¿Cómo evalúas este seminario respecto de tus expectativas iniciales? Todas las respuestas indicaron que por encima de sus expectativas.

En términos históricos el Seminario tiene un Net Promoter Score de 84.

En principio si no hay cambios a nivel institucional, la siguiente edición del seminario será el primer cuatrimestre de 2023.

Ingeniería de Software en la Era DevOps

Este el título de la charla/tutorial que dí la semana pasada en el contexto de CIbSE. En Zoom hubo unas 80 personas conectadas pero de las actividades interactivas que propuse, participaron alrededor de 30, un buen número de todas formas.

El punto central de mi de charla fue el hecho de que los escenarios que enfrentamos actualmente en la entrega de software nos llevan a tener que lidiar con ciertas cuestiones que tradicionalmente la ingeniería de software no ha atendido presentes. Al mismo tiempo, dichas cuestiones son centrales dentro del movimiento DevOps. Esto plantea un dilema: ¿es DevOps una disciplina distinta a la Ingeniería de Software? Pues yo creo que no. A mi parecer la Ingeniería de Software debe incluir DevOps. De hecho algunas de prácticas DevOps no son nuevas, sino que han sido parte de la Ingeniería de Software desde hace mucho tiempo. Ejemplo: Integración Continua.

En línea con esta idea, durante mi disertación mencioné varios libros que deberíamos tener presentes a la hora de plantear una Ingeniería de Software que incluya la temática DevOps:

Actualización: ya está disponible el video de la sesión, aquí.