Etiquetado: fiuba

Curso: Aprendiendo a programar con Python

Durante el segundo cuatrimestre de este año voy estar dictando este curso de introducción a la programación. El mismo surge de una iniciativa conjunta del FIUBA y el programa EmplearTec.

Tanto la currícula como en enfoque de enseñanza del curso están basados en el curso de Algoritmos y Programación 1 (FIUBA) de Rosita Wachenchauzer, del cual fui parte hace algunos años. Esto implica que quienes tomen el curso deberán asistir a dos clases semanales de 3 horas cada una y deberán dedicar otras tantas horas para estudio extra clase.

Los interesados pueden encontrar más información y detalles de la inscripción en la página de FIUBA.

Reflexiones sobre docencia universitaria

En 2009 participé como docente del curso experimental de Algoritmos y Programación 1 a cargo de Rosita Wachenchauzer en FIUBA. Esa experiencia me hizo un click y me llevó a replantearme varias cuestiones respecto de la forma de organizar las clases. Quiero en este artículo enfocarme en una de las cuestiones que generó ese click.

Tradicionalmente las clases de Algoritmos y Programación en FIUBA se dividen en dos clases semanales: una clase teórica dictada generalmente por el profesor a cargo de la materia y una clase práctica a cargo de los docente auxiliares. En algo3 lo hacemos así. Una de las particularidades del curso de Algoritmos y Programación 1 de Rosita era (y aún hoy lo es pues el curso sigue dictandose) la organización de las clases. La materia se dicta 2 días por semana y cada día se dicta teoría y práctica. Esto permite que el alumno vea un tema en la clase teórica y a continuación lo lleve a la práctica justamente en la clase práctica. Personalmente creo que este enfoque es mejor para facilitar el aprendizaje que el enfoque tradicional.

Para los docentes esta diferencia en la organización de las clases puede tener un impacto operativo importante, sobre todo para los docentes de dedicación simple que no asisten a la universidad todos los días. Con el enfoque tradicional cada docente asiste a la universidad una sola vez por semana: el profesor asiste un día a dictar la clase teórica y los auxiliares asisten otro dia a dictar la clase práctica. El enfoque alternativo implica que todos los docentes asistan dos veces por semana a la universidad ya que cada dia se dicta teoría y práctica.

Si tomamos como verdadera la hipótesis que de que este segundo enfoque es mejor para facilitar el aprendizaje de los alumnos, nos surge entonces un dilema como docentes: ¿qué priorizar a la hora de organizar las clases: la comodidad del docente o el mejor aprendizaje del alumno?

Continuará…

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.

Apostando a la ingeniería con estímulos de $ 25.000

La Facultad de Ingeniería de la UBA, tiene en curso un programa de estímulo a la graduación de estudiantes. Dicho programa está apuntado a aquellos estudiantes que se encuentren próximos al final de su carrera y que por una u otra razón hayan interrumpido sus estudios. El estímulo consiste en el pago de un monto de $25.000 para aquellos que efectivamente se gradúen.

Pueden encontrar más información en la página de la facultad.

Cierre de cuatrimestre en Algo3 (2013-2)

Comienzo compartiendo algunos hechos generales que personalmente me resultan de interés:

  • Consolidamos el uso de campus virtual
  • Consolidamos el uso del sistema de corrección de TPs
  • Gran parte de los grupos pudo trabajar exitosamente con servidor de integración continua
  • Curiosamente el  curso de los jueves por la tarde tuvo record de alumnos

Ya hablando en particular del curso de los jueves por la tarde, surgieron los siguientes temas en la retrospectiva:

  • (+) Los videos explicativos
  • (+) El uso de dos lenguajes
  • (+) El uso del sistema de corrección/gestión de TPs
  • (+) El TP final
  • (-) Poco tiempo para resolver los parciales => cuestión recurrente a pesar que Carlos a intentado mejoras ya lo hablaremos en equipo
  • (-) Poca explicación sobre cómo crear elementos visuales con Java => Vamos a proveer una guía/ejemplo/video para facilitar este tema
  • (-) Que el corrector automático no corra todo el tiempo => Este un tema de infraestructura que esperamos tener resulto para el cuatrimestre próximo.

Ya en el plano personal, la experiencia con mis grupos me resulto excelente. Tuve 3 grupos que trabajaron acorde a mis expectativas, haciendo test-driven development e integración continua y cumpliendo con las fechas estipuladas. Creo que por primera vez todos los grupos a mi cargo cumplieron con la fechas estipuladas.

algo3-2013-2

La satisfacción de la inquietud

La semana pasada en el contexto del trabajo final de Algo3 dimos la clase de MVC de cara a que los alumnos puedan empezar a trabajar en la parte de vista y controlador.  A los poco días recibí un mail de un alumno de uno de mis grupos con la siguiente consulta:

Queríamos consultarle si hay alguna forma apropiada de hacer testing para la parte de vista del proyecto, ya que desde que nos pusimos a trabajar con la misma la cobertura de código del proyecto bajó notablemente.

Sinceramente la consulta me sorprendió para bien y me causó una gran satisfacción ver que un alumno tenga este tipo de inquietudes ya desde los primeros años de la carrera.

Largamos el TP Final de Algo3

Este cuatrimestre el TP fue ideado por GabiD con aportes de DiegoM y PabloM. Consiste en un juego por turnos en el que el usuario debe mover su vehículo por una ciudad llena de obstáculos de distinto tipo, intentando minimizar la cantidad de turnos utilizados y maximizando el puntaje acumulado.

Yo tengo a mi cargo 3 grupos los cuales vienen trabajando muy bien. Para facilitar las cuestiones tecnológicas y permitir que los alumnos se concentren en OO, les dimos un proyecto base de ant y un par de videos que explican cómo dar los primeros pasos con Java, Ant y Subversión. Adicionalmente me encargué de configurar un servidor de integración continua. Para esto último estamos usando el servicio gratuito que muy gentilmente nos brinda la CloudBees. Como de costumbre hemos hecho mucho énfasis en que desarrollen sus trabajos haciendo TDD y según muestran los reportes de cobertura parece que lo estan haciendo.

algo3-g1-2013-2

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.

La clave es educarlos de chiquitos

Hoy compartí el almuerzo con mi colega JuanG y algunos otros profesionales de la informática. En un momento comenzamos a hablar sobre TDD y algunas otras prácticas ágiles. Durante la charla uno de los comensales comentó que le parecía muy difícil pretender que los programadores “junior” utilicen dichas técnicas cuando las mismas ni se mencionan en las universidades. Estuve de acuerdo con el comentario respecto de la complejidad, pero al mismo tiempo agregué que en algunas universidades, estos temas son materia corriente. Para mi : “La clave es educarlos de chiquitos”.

Como ocurre en todos los ámbitos de la vida, una vez que algo se hace hábito, cuesta mucho cambiarlo. Es por esto que en las materias que dicto hago mucho énfasis en cuestiones tales TDD y prueba unitaria. Un caso testigo es lo que hacemos en Algo3. En las clases prácticas resolvemos ejercicios y en todos los casos lo hacemos usando TDD. Luego, en los dos trabajos prácticos individuales que los almnos deben resolver, les recomendamos una y otra vez que los resuelvan utilizando TDD. Finalmente cuando llegan al último trabajo práctico que implica trabajar el grupo, los alumnos tienen la técnica incorporada. Un detalle importante es que si bien la técnica de TDD la aprenden en nuestra material, ya en la materia anterior los alumnos comienzan a hacer pruebas unitarias automatizadas.

Cierro este post con algunos gráficos de métricas de tests de los grupos que estoy dirigiendo en Algo3 este cuatrimestre. ¡Hermoso!

covertura

Batalla Naval en Algo3

La semana pasada publicamos el trabajo práctico final de Algo3 de este cuatrimestre. El trabajo consiste en la construcción de una aplicación que es una variante del clásico Batalla Naval.

Yo tengo a mi cargo dos grupos, de 3 alumnos cada uno. Ambos equipos estan trabajando en Java.  En la primera charla que tuve con los grupos fui bien claro respecto de la expectativas en la forma de trabajo. Hablé con ambos grupos juntos e hicimos un poco de “community programming” (una especie de pair programming pero de a muchos más) para hacer el setup del proyecto: crear estructura de carpetas, ant, etc, y codeamos la clase casillero haciendo TDD.

Luego les comparti un .zip de lo que hicimos para que lo tomaran como base. Eso les permitió no tener que andar “peleando” con Java y Ant y concentrase en lo importante para nuestra materia: la programación orientada a objetos.