Pase: de Algo3 a MeMo2

Pase: de Algo3 a MeMo2

Después de más 15 años como parte del equipo docente liderado por Carlos Fontela y a cargo de la materia Algoritmos y Programación 3, este año emprenderé un nuevo camino.

Resulta que a partir de la implementación del nuevo plan de estudios de la Licenciatura hay que empezar dictar nuevas materias y eso requiere del nombramiento de nuevos docentes o de la reubicación de los docentes existentes. Este segundo caso es el mío.

En particular en el segundo cuatrimestre de este año debe comenzar a dictarse la materia Métodos y Modelos en la Ingeniería de Software 2 (a.k.a. MeMo2). Como su nombre lo sugiere, esta nueva materia es la continuación de Métodos y Modelos en la Ingeniería de Software 1 (a.k.a. MeMo1) que es una materia (hoy en día) equivalente a la materia Análisis de la Información del plan anterior. MeMo1 empezó a dictarse hace un par de cuatrimestres y su equipo docente está liderado por Sergio Villagra. Para asegurar cierta consistencia entre MeMo1 y MeMo2, Sergio también estará involucrado en MeMo2. Por mi parte, durante este primer cuatrimestre estaré participando de MeMo1 y trabajando en el armado de MeMo2.

Debo admitir que dejar Algo3 no fue una cuestión fácil. Si bien el equipo docente de Algo3 ha ido variando a lo largo de todos estos años, somos varios los que llevamos más de 10 años trabajando juntos. Creo que justamente es esa combinación del “núcleo de veteranos” con “la sangre de los nuevos colaboradores” y el compromiso de mejora continua de todo el equipo, lo que ha motivado a que la materia este en una constante evolución. Al mismo tiempo armar y dictar MeMo2 representa un gran desafío y una importante oportunidad de crecimiento en mi carrera docente y es por ello que acepté el pase.

Me voy de Algo3 muy contento de haber trabajado con ese gran equipo docente e infinitamente agradecido a Carlos Fontela por haberme invitado a sumarme al equipo allá por el año 2000.

Cierre de algo3 (2016)

Terminamos un año de cambios:

  • Eliminamos la distinción clase teórica / clase práctica y pasamos a tener dos clases, ambas de índole teórico/prácticas
  • Cambiamos la dinámica de las clases a hacia un enfoque más “from the back”, algo que ya veníamos haciendo en forma más leve y este años aumentamos la apuesta
  • Como parte del punto anterior fomentamos el trabajo en clase con las computadoras, intentando programar durante la clase

Si bien conceptualmente estoy completamente convencido de que este enfoque es el más apropiado para esta materia, creo que la puesta en práctica no fue lo suficientemente buena, creo que tuvimos varias falencias de coordinación interna entre los docentes. La parte positiva es que esto nos deja un buen espacio mejorar 😉

Tipado estático vs. Tipado dinámico

Como de costumbre luego del almuerzo dominical, me senté con un café a leer mi lista de blogs. Fue en ese momento cuando me encontré con este artículo que había publicado Uncle Bob ese mismo día. El artículo está titulado “Type Wars” y en forma muy resumida es una recorrida histórica de esta interminable contienda, con opiniones intercaladas del autor y un cierre interesante.

Este tema del tipado es una cuestión que me encuentro recurrentemente en mis clases todos los cuatrimestres. En FIUBA la mayoría de los alumnos viene de programar Pascal, C y C++, mientras que en UNTREF todos vienen de programar Java. Cada vez que en las materias empezamos a trabajar con lenguajes de tipado dinámico (Smalltalk o Ruby) algunos alumnos se sienten desconcertados y en más de una ocasión surge el debate en clase. De ahora en más voy a referenciarlos directamente al artículo de Uncle Bob, más aún, voy a incluir el artículo como lectura obligatoria.

Para cerrar les recomiendo dedicar un rato para leer el artículo completo y les dejo aquí una frase excelente incluida en el mismo:

…when a Java programmer gets used to TDD, they start asking themselves a very important question: “Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?” Those programmers begin to realize that they could become much more productive by switching to a dynamically typed language like Ruby or Python.

Extracto del artículo “Type Wars, de Uncle Bob“, artículo completo disponible en: http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html

Dinámica para enseñanza de pruebas automatizadas y especificación con pruebas

La dinámica que voy a describir aquí fue diseñada por Gabi Falcone para una clase de Algo3@Fiuba. El objetivo de la misma es presentar las pruebas automatizadas y su uso como herramienta de especificación.

Contexto: en el curso tenemos alrededor de 50 alumnos. El aula de clase no tiene computadoras, pero algunos alumnos traen sus portátiles.

Preparación

Previo a la clase se le pide a alumnos resolver un problema de programación que implica crear algunas clases. En necesario contar con al menos dos problemas de complejidad similar. Dependiendo de la cantidad de alumnos puede resultar conveniente contar con más problemas. En nuestro caso trabajamos con 3. Se le pide a cada alumno resolver solo uno de los problemas. Para esto nosotros solemos utilizar una heurística basada en el número de padrón:

  • padrones terminados en 0,1,2,3 => problema 1
  • padrones terminados en  4,5,6 => problema 2
  • padrones terminados en  7,8,9 => problema 3

La clase comienza con una explicación conceptual de pruebas unitarias automatizadas y del framework xUnit. En nuestro caso explicamos SUnit pues trabajamos con Smalltalk. Luego de la explicación se pone manos a la obra con la dinámica de trabajo interactiva.

La dinámica se hace en grupos donde cada grupo tiene una computadora. El primer paso entonces es armar los grupos. Se le pide a todos que salgan del aula, armamos tres filas con la gente que había resuelto cada variante del problema pedido inicialmente. A continuación en cada fila se le pide a los que tengan computadora que pasen al frente y elijan 2 o 3 compañeros de la fila que no tengan computadora. Así quedan armados los grupos. A continuación se les pide volver a entrar al aula y que se ubiquen en las mesas según los grupos armados.

Primera etapa

A cada grupo se le pide que escriba un conjunto de pruebas unitarias para el problema que les tocó resolver. Como todos los alumnos de un mismo grupo ya han resulto el mismo problema, la escritura de las pruebas resulta bastante directa.  Al mismo tiempo como ya tiene el código que resuelve el problema, los alumnos pueden ir corriendo los tests a medida que los van escribiendo. Explícitamente se les indica que roten el conductor (la persona que está al teclado) con el fin de que todos tengan el teclado un rato. En concreto cada prueba debe ser codeada por una persona distinta.
Al cabo de 30 minutos deberían tener una cantidad relevante de pruebas.

Segunda etapa

Cada grupo entrega el conjunto de pruebas creadas (sólo el código de las pruebas, no el código que hace pasar las pruebas) a otro grupo que haya estado trabajando sobre un problema distinto. Ahora cada grupo debe resolver un problema nuevo pero en este caso tiene un conjunto de pruebas como especificación de lo que debe resolver y al mismo tiempo puede ir corriendo esas pruebas para verificar la solución que va generando. Una vez más se pide explícitamente que vayan rotando el conductor.
Al cabo de unos 30 minutos, deben tener la mayoría de las pruebas pasando.

Cierre

Aquí se pide a los alumnos dejar a un lado las computadoras para hacer una puesta en común de la actividad. Se plantean algunas preguntas para disparar la discusión:

  • ¿Cómo les resultó la experiencia en general?
  • ¿Cómo les resultó el resolver un problema a partir de una especificación en forma de pruebas?
  • ¿Cómo les resultó escribir pruebas para un problema ya resuelto? ¿Qué utilidad le ven a esto?

Nota: tener presente que durante esta actividad no se hace TDD sino que simplemente se utilizan pruebas como especificación lo cual es solo una parte de TDD. Notar que aquí el trabajo comienza con todo un conjunto de pruebas ya escrito, mientras que en TDD las pruebas se van escribiendo de a una por vez.

Fontela los cría y el AOC los junta

El último fin de semana estuve participando del Agile Open Camp. En un momento dado me encontré compartiendo una mesa con otros cuatros egresados de FIUBA y curiosamente todos ex-alumnos de Carlos Fontela en Algo3. Pero como si fuera poco, había en la conferencia algunos otros ex-alumnos que no estaban en la mesa en ese momento.

La coincidencia nos pareció divertida así que al día siguiente nos sacamos una foto todos juntos.

20120101_023502

Arriba: Marcos Pozzo, Fer Claverino, Ricardo Markiewicz, Vanesa Savino, Pablo Suarez, Elias Molini. Abajo: Pablo Tortorela, NicoPaez, Sole Pinter.

The BEST exam EVER!!!!

El lunes pasado tuvimos mesa de examen en Algo3 y el examen que tomamos fue el mejor que vi en mi vida entera. El examen consistió en un ejercicio práctico, cada alumno estaba con su computadora y le entregamos un conjunto de clases que resolvían un problema dado. La consigna era simple: analice el código y mejorelo. Luego de cierto tiempo (unos 30 minutos) un docente se sentaba con cada alumno para hablar con él sobre las mejoras realizadas.

Obviamente el código entregado tenía una serie de “cochinadas” algunas muy groseras y otras menores. La expectativa era que los alumnos fueran capaces:

  1. Identificar las “cochinadas”
  2. Explicar los problemas que las mismas podrían acarrear
  3. Proponer modificaciones a la solución para remover “las cochinadas”
  4. Implementar esas propuestas en código

A mi me tocó evaluar a dos alumnos y el método me pareció simplemente genial, pues con preguntas muy concretas uno podía determinar si el alumno había incorporado, o no,los conceptos centrales de la materia.

Debo felicitar a Pablo Massuh y Gabi Devoto que fueron los ideólogos de este examen.

Cierre de cuatrimestre Algo3 (2015-1)

El pasado miércoles hicimos la retrospectiva de cierre del cuatrimestre en Algo3. Estos son los puntos destacados:

  • (+) Videos explicativos de las herramientas
  • (+) Uso del sistema de gestión de TPs (alfred)
  • (+) Clases entretenidas
  • (-) Falta de explicaciones/poco soporte para el desarrollo de las vistas en el TP final.
    En línea con la buena llegada de los videos, creemos que generar un video sobre este tema podría resultar positivo.
  • (-) Escritura de código en papel durante los parciales.
    Este un tema que venimos hablando internamente en la cátedra y si bien tenemos intenciones de cambiarlo, aún no encontramos un mecanismo que nos sirva para manejar la gran cantidad de alumnos que tenemos.
  • (-) Falta de publicación de materiales de clase.
    Mala nuestra, en muchas ocasiones utilizamos materiales en clase que luego no compartimos (por olvido) con los alumnos.

Además de los puntos positivos y negativos también surgieron algunas cosas para experimentar:

  • Incluir mocking y metaprogramación en el programa de la materia
  • Reemplazar el uso de Swing por JavaFX para la construcción de interfaces de usuario

cierre_algo3_2015-1