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

Algunos cambios en Algo3 para el 2014

Un nuevo cuatrimestre está por comenzar y junto con el vienen algunos cambios.

En primer lugar tenemos algunos cambios de horario: la teórica será dictada los lunes por la tarde y al mismo tiempo la práctica de los miércoles también se dictará por la tarde (en ambos casos el horario es de 16 a 19 hs). Las otras dos prácticas siguen iguales.

También tenemos cambios en los equipos docentes de las prácticas: Gabi Falcone pasa a la práctica de los jueves a la noche, mientras que DiegoM y yo estaremos en la práctica de los miércoles.

Finalmente tenemos algunos cambios en lo que respecta a la dinámica de las clases: vamos a experimentar más fuertemente con algunas técnicas de lo que se denomina el paradigma de educación centrada en el alumno.

Recomendaciones idiomáticas para programadores

Las recomendaciones que comparto en esta sección han surgido principalmente de mi experiencia personal como programador y como docente de programación. Decidí ponerlas por escrito cuando me dí que cuenta que las repetía una y otra vez para los distintos alumnos que pasaban por mis clases.

Aprende inglés

Nos guste o no el inglés es la lenguaje universal es esta profesión, todos los lenguajes de programación de escala industrial parten de la lengua inglesa. (he sabido de lenguajes de programación basados en otros idiomas, pero todos ellos era experimentales o bien para uso educativo).

Si bien parte de la bibliografía es traducida al castellano, las traducciones siempre tienen un tiempo de defasaje respecto de la publicación original que la mayoría de los casos es en inglés. Incluso cuando la publicación original no sea en inglés, es casi seguro que será antes traducida al inglés que al castellano.

Al mismo tiempo la evolución de las herramientas es cada vez más rápida, haciendo que los tiempos entre las distintas versiones sea cada vez más corto. Esto hace que una traducción tardía pierda sentido pues queda rápidamente desactualizada.

Es cierto que también exiten publicaciones originales en castellano, pero sinceramente son sólo un pequeño porcentaje.

Adicionalmente existe un riesgo con las traducciones que es la potencial pérdida de cierto sentido del término original o peor aún, la ambiguedad.

Más allá de la necesidad del inglés para el acceso a los recursos, exite otra cuestión: los clientes. En este contexto cada vez más globalizado no es raro que termines trabajar con un cliente que no hable castellano. Aún cuando dicho cliente no sea un pais de habla inglesa ¿en qué lenguaje crees que pretenderá comunicarse contigo? Y podemos ir aún más allá, puede que incluso parte de tu equipo este distribuido y te tengas que trabajar con un compañero que no hable castellano.

Resumiendo: debes tener cierta soltura para comunicarte en inglés. ¿cuanta soltura? Mi heurística es: debes sentirte cómodo leyendo y escribiendo y debes ser capaz de entender los díalogos de la serie IT Crowd en idioma original sin necesidad de leer los subtitulos.

Elige un idioma

Un dilema común para muchos programadores de habla no inglesa es ¿en que idioma programar? O sea, más allá del lenguaje de programación que elijas utilizar, en un punto tendrás que crear tu clases/funciones/variables y deberás decidir cómo nombrarlas.

Podrias nombrarlas en inglés para así mantener uniforme el código fuente ya que las construcciones nativas del lenguaje de programación están en inglés.

Pero si tu cliente es de habla castellana, entonces podrías decidir nombras tus clases/funciones en castellano, para así tener un mapeo más directo entre los conceptos del dominio y tu código.

A mi parecer ambos criterios son válidos y creo que la decisión mas apropiada requiere de un análisis del contexto particular de cada caso.

Más allá del análisis y la decisión que uno tome, creo que lo importante es hacer el análisis, tomar decisión y respetarla. Obviamente esta no es un decisión individual, sino que es que debe decidirse a nivel de equipo.

Utiliza el alfabeto inglés

Es común en la actualidad encontrarse con lenguajes de programación que permiten el uso de caracteres no pertenecientes al alfabeto inglés. Por ejemplo en Java es posible definir una variable “año”, una clase “Interés”. En mi experiencia esto tarde o temprano suele traer algún tipo de problema, sobre todo si los ambientes de desarrollo de cada miembro del equipo no estan totalmente estandarizado.

Utiliza software de base en inglés

Es común que cuando se produce un error en una aplicación, se muestre mensaje de error al usuario y al mismo tiempo se genere una nueva entrada en el log de la aplicación. En algunos casos esos errores se muestran en el idioma actual de la aplicación y/o del sistema operativo.

Dado que hay mucha más información en internet en inglés que en castellano, siempre recomiendo utilizar software de base en inglés, o sea, al instalar tu sistema operativo, elige inglés como idioma por defecto. Lo mismo recomiendo para los IDEs y los SDKs. De esta forma en caso de encontrarte con un error, el mismo estará en inglés y al ponerlo en el buscador encontrarás muchos más resultados que si el error estuviera en castellano.

Cierre de Algo3, primer cuatrimestre 2013

Si bien no hicimos cambios explícitos en la dinámica de la materia, incorporamos algunas cuestiones internas que generaron impacto muy positivo.

Una de estas cuestiones fue la incorporación del sistema de corrección de TPs. Esto nos ayudo a reducir muchísimo la carga de trabajo manual al mismo tiempo que le permitió a los alumnos tener un feedback inmediato de las entregas de sus trabajos.

Por otro lado, trabajamos con más foco en la coordinación interna de las clases de los distintos cursos de práctica, reutilizando materiales y ejemplos.

Finalmente, en lo que respecta al trabajo final, tuve dos grupos a mi cargo y ya desde la primer semanal tuvimos el soporte de un servidor de integración continua. Para esto, utilice el servicio que gentilmente nos brinda en forma gratuita CloudBees. Al mismo tiempo, fue muy positivo que ambos grupos tomaron en serio el build server, rompiendo el build muy pocas veces. Todo el proceso de build lo hicimos usando Ant y consistia en compilación, ejecución de pruebas (junit), medición de cobertura (cobertura) y verificación de código (checkstyle). Otro detalle que me pareció muy positivo es que gran parte del modelo de la aplicación lo hicieron usando TDD, lo cual derivó en un porcentaje de cobertura muy bueno (superior al 80%). Algunos otro docente, también usaron esta herramienta con muy buenos resultados y por ello en la retrospectiva decidimos extenderlo a toda la cátedra para el próximo cuatrimestre.