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«
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.
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.
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):
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.
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 aprobació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)
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.
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.
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.
Blog de NicoPaez 