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

 

Sobre el TP final de algo3 (2015-1)

A fines de mayo lanzamos el TP final de Algo3. En el curso de los miércoles tenemos poco más de 30 alumnos repartidos en equipos de 3 integrantes, cada equipo con un docente tutor. En mi caso soy tutor de 4 equipos.

Este cuatrimestre el trabajo prácticos se llama AlgoCraft y como su nombre lo sugiere es una variante del clásico juego StarCraft.

Como de costumbre desde el comienzo del trabajo práctico configuré un Jenkins para que los alumnos pudieran hacer integración continua. Esto también me permite tener métricas de su trabajo. Este cuatrimestre incorporé PMD al conjunto de tareas ejecutadas en el proceso de integración continua. PMD es un herramienta que entra en la categoría de “Linter” y como tal, lo que hace es analizar el código fuente realizando un conjunto de verificaciones relacionadas al cumplimiento de estándares y buenas prácticas de programación del lenguaje en cuestión.

algo3_20151

Expectativas para el nuevo cuatrimestre en FIUBA

Esta semana comenzó el cuatrimestre en FIUBA. En el curso 3 (miércoles) tenemos poco más de 40 alumnos 2 de los cuales son de intercambio (uno de Colombia y otro de Francia). Respecto del equipo docente, quedó conformado por DiegoM, PabloRM y yo, lo cual no dá prácticamente unos 15 alumnos por docente, un número no tan malo tratándose de UBA, sobre todo si tenemos en cuenta que según la política de la facultad la relación debería ser de 1 docente cada 20 alumnos.

Como de costumbre, la gran mayoría de los alumnos (~85%) son de la carrera de ingeniería informática.

En términos generales no tenemos planificadas grandes innovaciones para este cuatrimestre, pero en particular en el curso de los miércoles intentaremos realizar más actividades de programación en clase, ya que según pudimos relevar en la primera clase, muchos alumnos podrían asistir a clase con sus computadoras personales.

fiuba_2015