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

 

Retrospectiva Algo3 Segundo Cuatrimestre 2014

En particular voy a referirme al curso de práctica de los miércoles a la tarde y antes de entrar en los hallazgos de la retrospectiva quiero compartir algunas particularidades de este cuatrimestre.

Este cuatrimestre en el curso de los miércoles por la tarde tuvimos tan sólo 9 alumnos, lo cual es muy raro, ya que el cuatrimestre anterior tuvimos más de 50 y en los cursos de la tarde nunca hemos tenido menos de 20 alumnos. Creemos que esta situación se debió a un error que hubo en la publicación de horarios: inicialmente se publicó que el curso se dictaba en el horario de 19 a 22 cuando en realidad se dictaba en el horario de 16 a 19. Esta inusualmente pequeña cantidad de alumnos nos permitió utilizar el laboratorio de computadoras en lugar de un aula tradicional lo cual cambió bastante la dinámica de las clases. Más aún, generó una situación rara para FIUBA: una materia de comienzo de carrera, con 9 alumnos, dos docentes y una computadora por alumno, ¡INCREIBLE!
Es la primera vez que como docente de FIUBA me encuentro en una situación así. Al mismo tiempo creo que es la primera vez que TODOS los alumnos que comenzaron a cursar aprobaron la cursada (digo los que comenzaron a cursar pues por el problema de la publicación de horarios hubo que gente no pudo cursar o lo hizo en otro curso).

Ahora sí, los hallazgos de la retrospectiva:

  • Mantener
    • Uso de dos lenguajes
    • Videos explicativos
    • TPs de Juegos
    • Clases prácticas en laboratorio
    • Acompañamiento docente
    • Uso de Jenkins en el TP final
  • Cambiar/Mejorar
    • Publicar el material de la clase teórica antes de clase
    • Más detalle en la clase de MVC (agregar un video podria ayudar)
    • La relación tiempo/longitud de los parciales
  • Probar
    • Agregar más ejercicios a la guia
    • Más ejercicios para entregar via Alfred

Al ver las notas de la retrospectiva compartidas por los docentes de los cursos de los jueves veo varios puntos comunes en que me parece deberemos trabajar.

Personalmente estoy muy conforme el resultado del cuatrimestre y debo admitir que disfruté mucho la dinámica que logramos teniendo un curso tan chico.

 

Cierre de cuatrimestre en Algo3

Este cuatrimestre afrontamos algunos nuevos desafíos, a partir de ciertos cambios en el equipo docente.

Uno de los cambios fue el horario de dictado de la materia. Las clases  teóricas pasaron a la tarde (16 hs) y lo mismo hicimos con el curso de los miércoles. Posiblemente por influencia de este cambio tuvimos una interesante variación en la cantidad de alumnos de los diferentes cursos de práctica. Generalmente el curso de los miércoles (que solía dictarse a las 19 hs) era el que menos alumnos tenía (~20), sin embargo este cuatrimestre movimos el curso a las 16 hs y tuvimos ~ 55 alumnos.

Otro de los cambios que hicimos fue en las clases teóricas, donde Carlos decidió experimentar un poco más en profundidad con algunas técnicas de educación centrada en el alumno. Creemos que eso ayudó a mejorar las clases pues recibimos comentarios positivos de los alumnos al respecto.

En las prácticas de los miércoles generalizamos una estrategia que yo venía utilizando desde hace un tiempo: guiar el desarrollo del trabajo práctico final con escenarios de prueba. El trabajo práctico final se hace con lenguaje Java, trabajando en grupo junto a un docente tutor y dura unas 5 semanas en las que se espera que los alumnos trabajen de forma continua demostrando avance semanal.

leyen
El TP final de este cuatrimestre fue un juego del tipo Carmen San Diego

En una época solíamos pedirle a los alumnos que las primeras semanas se concentrarán en el diseño haciendo diagramas UML y luego de tener un modelo del dominio base, recién entonces pasaran al código. Con el correr del tiempo eso ha ido cambiando. Ya desde el año pasado comencé a guiar a mis grupos especificando semana a semana un conjunto de casos de prueba a resolver de manera que funcionaran como “pruebas de aceptación” y que los guiaran en la implementación incremental de la aplicación.

Otra práctica que hemos establecido por completo en el curso de los miércoles es el uso de Jenkins como servidor de integración continua para el desarrollo de los trabajos finales. El uso de Jenkins en conjunto con Ant y algunas otras herramientas más, nos permitieron obtener ciertas métricas sobre el código de los alumnos al mismo tiempo que les facilitó la integración del trabajo a cada equipo.

Mé
Métricas de un trabajo final

Al terminar el cuatrimestre, además de la clásica retrospectiva hicimos una encuesta online anónima para obtener algunos números concretos de manera de poder medir la mejora de un cuatrimes a otro. Entre el feedback que recogimos destaco los siguientes puntos:

  • (a mejorar) Que las correcciones del TP1 sean entregadas antes de rendir el primer parcial
  • (a mejorar) Actualizar el template del proyecto ant para incluir la ejecución de la aplicación
  • (mantener) Clases participativas y juegos de rol
  • (mantener) Videos complementarios de explicación sobre las herramientas
  • (mantener) Jenkins

 

retro-algo3
Post-its de la retro

 

Cómo enseñamos TDD

TDD es una práctica cuyo punto clave es la secuencia de pasos que se siguen para obtener la solución. En Algo3 explicamos la teoría y luego la ponemos en práctica haciendo dojos en las clases. También les damos ejercicios a los alumnos y les pedimos que los resuelven haciendo TDD, pero la realidad es no tenemos forma de asegurarnos que hayan arribado a la solución usando TDD. Hay algunas situaciones observables que pueden sugerir que la solución no fue generada utilizando TDD (por ejemplo si la solución tiene baja cobertura es muy posible que no se haya utilizado TDD o al menos no se lo haya utilizado correctamente o todo el tiempo). Al mismo tiempo todos los ejercicios de programación que resolvemos en clase procuramos hacerlo usando TDD. Finalmente evaluamos su conocimiento sobre TDD con alguna pregunta en el examen. Creo que es un enfoque bastante integral y razonable para el contexto de la materia, donde es común que tengamos más de 40 alumnos por curso. Pero es posible que haya mejores enfoque para otros contextos.

Sin ir más a lejos, yo mismo en UNQ estrené este cuatrimestre un enfoque distinto. Cabe aclarar que el contexto de UNQ es distinto, en primer lugar es una materia de ingeniería de software donde se supone que los alumnos ya vieron algo de TDD. Al mismo tiempo, la cantidad de alumnos es mucho menor, suelen ser alrededor de 10. Finalmente la dinámica de la materia es distinta: no tenemos separación explícita entre teoría y práctica y tampoco tenemos exámenes formales. Lo que hacemos (o mejor dicho lo que hemos hecho este cuatrimestre) es explicar TDD haciendo TDD, de una, explicando la teoría sobre la misma práctica. Luego les damos a los alumnos algunas katas para resolver y les pedimos que graben un screencast mientras van resolviendo la kata. Esto nos permite observar cómo los alumnos aplican la técnica paso a paso y detectar si algo no fue correctamente entendido.

Métodos de clase

Conceptualmente los métodos de clase son métodos que tienen la particularidad de pertenecer a la clase y no a las instancias de la clase. Por esto es que para invocar a un método de clase no es necesario crear una instancia de la clase que contiene el método.

En aquellos lenguajes cuya sintaxis deriva de C, los métodos de clase se identifican con la palabra clave static y de ahí que en ocasiones se los llame métodos estáticos. Conceptualmente desde la POO creo que este nombre no es correcto pues mezcla una cuestión conceptual con un detalle de implementación de algunos lenguajes particulares.

public static doFoo() {
..
}

En Ruby, los métodos de clase de clase, se los identifica en su definición con el prefijo self.

def self.doFoo
...
end

El Smalltalk (pharo) los métodos de clase son definidos en un compartimento particular.

class_methods