Clases virtuales condicionadas

Luego de 2 años de clases obligadas en modalidad virtual, la mayoría de los alumnos siguen prefiriendo esa modalidad. De mi lado docente, si bien la virtualidad me resulta en cierto modo más cómoda (no tengo que trasladarme hasta la universidad) hay ciertas cuestiones que me resultan mucho más incómodas y que en el balance me llevan a elegir la presencialidad en varias casos.

Concretamente me genera una gran incomodidad dar clases virtuales para una audiencia «ausente»: gente con cámara apagada (o sin cámara) y con nula participación durante la clase. La participación «verbal» puede que no cambie en un esquema virtual o presencial (hay gente que incluso estando en el aula física, no aporta ni una palabra durante toda la clase), pero a pesar de eso, el poder ver las caras ofrece al menos cierto grado de feedback infinitamente más rico que una foto de perfil.

Es por eso que para este segundo cuatrimestre 2022 de MeMo2 vamos a regular la virtualidad acorde a la participación de los alumnos. Si los alumnos quieren clases virtuales entonces deben tener sus cámaras encendidas. En la medida que la mayoría de las cámaras permanezcan apagadas vamos a optar por más clases presenciales. Según la planificación que hicimos tenemos 6 clases que si o si serán presenciales y otras 2 que si o si serán virtuales. El resto de las clases, tenemos la flexibilidad de poder darlas en cualquiera de las dos modalidades.

Kit docente 2022 para clases presenciales

Hubo una época en que ir a dar clases implicaba llevar solamente la notas de la clase. El docente tomaba el centro de la escena, hablaba y posiblemente escribía algo en el pizarrón. En el aula siempre había borrador y algunas tizas.

Luego llegaron las notebooks y los proyectores, entonces en pizarrón dejó de estar solo y empezamos a llevar las notebooks y a usar los proyectores provistos por la universidad.

Gradualmente los pizarrones «de madera para tiza» fueron reemplazados (o complementados) por pizarras «de plástico para fibra» y obviamente empezamos a llevar fibras y borradores para estos nuevos pizarrones. Creo que en la actualidad esta es la situación para muchos docentes universitarios en el área de tecnología/ingeniería (posiblemente en otras áreas ocurra lo mismo).

Pero quienes optamos por una modalidad distinta a la clase magistral, solemos necesitar algunos elementos adicionales. A esto debemos sumarle cierta escasez de recursos en la universidad pública y mi intención de mitigar riesgos. Es por estas cuestiones que suelo asistir a mis clases presenciales con conjunto extra de elementos.

En la foto precedente se pueden observar los siguientes elementos:

  • Parlante: lo utilizo para poner música al llegar al aula (suelo llegar unos 10 minutos antes del comienzo de clase y entonces pongo música mientras van llegando los alumnos). También suelo poner música mientras los alumnos trabajan en las consignas de la clase.
  • Post-it: las suelo utilizar para distintas cuestiones, por ejemplo para pegar en el pizarrón el plan de clase o para hacer un «parking lot» de la dudas que van surgieron durante la clase.
  • Control remoto y puntero láser: en ocasiones me gusta sentarme junto a los alumnos y este dispositivo me permite pasar las diapositivas a distancia y apuntar a los elementos que quiero destacar.
  • Papeles de colores: son como los post-it pero sin el pegamento.
  • Cable HDMI: para conectar la notebook al proyector. Me ha pasado que el que me provee la universidad no funciona óptimamente.
  • Hojas de papel A4: más papel para actividades
  • Borrador y varios marcadores para pizarra: si bien la universidad provee estos materiales prefiero utilizar los míos.
  • Zapatilla: en ocasiones me toca dar clases en aulas donde los toma corriente se encuentran demasiado lejos o incluso tal vez hay un único toma.

Y para llevar todo esto, utilizo mi «maletin» de la Smalltalks 2009.

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 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)

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.