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.

 

Charla orientativa para estudiantes de secundaria

El pasado viernes estuve participando de un encuentro de orientación vocacional en la sede del CBC de Ciudad universitaria. Casualmente yo había participado de un encuentro similar en el mismo lugar en el año 1997, cuando estaba terminando la secundaria. A diferencia de aquella vez, en esta ocasión fui orador y no oyente.

El encuentro estuvo organizado por el área de orientación vocacional del CBC y pretendia reunir a representantes de las distintas carreras de informática dictadas en la UBA. En este sentido habia una persona de la Facultad de Ciencias Económicas, donde se dicta la carrera de Licenciatura en Sistemas de información de las Organizaciones y una alumna avanzada de la Facultad de Ciencias Exactas y Naturales, donde se dicta la carrera de Licenciatura en Ciencias de la Computación. Y finalmente estaba yo, en representación de la Facultad de Ingeniería, donde se dictan las carreras de Ingeniería en Informática y Licenciatura en Análisis de Sistemas.

El encuentro duró unas dos horas y comenzó con una breve charla de un representante de la CESSI, quien habló sobre las oportunidades laborales en Argentina en la industria del software.

Aquí estan las diapositivas que utilicé durante en encuentro.

Fin del taller de prueba automatizada

El jueves pasado tuvimos el quinto y último encuentro del taller de prueba automatizada que dictamos junto con Pablo Tobia en FIUBA. El taller era abierto y gratuito pero con inscripción previa. Justamente al ser totalmente gratuito implicaba cierto riesgo en lo que hace a la planificación, pues es común que mucha gente se inscriba y luego no asista. Para mitigar esto, pedimos a todos los interesados que para confirmar su vacante resolvieran un pequeño ejercicio de programación.

Inicialmente tuvimos unas 40 personas que manifestaron interés en participar del taller cuando aún no estaba definido el horario. Una vez que definimos el horario le informamos a estas ~40 personas y les pedimos que resolvieran el ejercicio para completar su inscripción. Sólo 12 de los 40 lo hicieron. Y aún así, de esos 12 solo 10 participaron del taller.

El taller consistió en 5 encuentros de  ~3 horas. Como guía del taller utilizamos los cuadrantes de testing de Marrick con lo cual el contenido quedó organizado de la siguiente forma:

  • Encuentro #1: conceptos básicos de testing y presentación del enfoque de los cuadrantes
  • Encuentro #2:
    • foco en el cuadrante #1 (support programming & technology facing),
    • test automation manifest
    • xUnit test patterns
    • Test doubles
    • Coverage
  • Encuentro #3 y #4:
    • foco en el cuadrante #2 (support programming & business facing)
    • tipos de herramientas para automatización de pruebas
    • arquitectura de las herramientas de automatización de pruebas
    • testing de aplicaciones tipo enterprise
    • SeleniumIDE, Cucumber, Fitnesse
    • Phantom, Slimer and CasperJS
    • Watir & PageObjects
  • Encuentro #5:
    • foco en los cuadrantes #3 y #4 (test que critican el producto)
    • Stress testing, JMeter
    • AB testing
    • Calidad del software más allá del testing
    • Testing en distintos tipos de proceso de desarrollo
    • El rol de tester

Tanto docentes como alumnos quedamos muy contentos con el taller y concluimos que perfectamente podria ser una materia de las carreras de informática de FIUBA (en realidad es posible que también aplique a otras carreras pero sabemos que en FIUBA estos temas no estan cubiertos por ninguna materia en la actualidad). En caso querer convertir este taller en un materia (o en un curso más amplio) deberíamos agregar temas talles como: planificación de la prueba, definición y administración de casos de prueba, herramientas de soporte, Testlink, modelos de calidad, etc.

Finalmente quiero agradecer a todos los que participaron este experimento para mi ha sido un gran placer el tiempo compartido.

Sobre las carreras de informática en FIUBA

La Facultad de Ingeniería de la Universidad de Buenos ofrece dos carreras en el área de informática: Ingeniería en Informática y Licenciatura en sistemas. Como docente de dicha casa de estudio suelo recibir consultas del tipo:

“Me gustaría trabajar en XYZ, ¿me conviene hacer la licenciatura o la ingeniería?”

Luego de haber respondido esta pregunta N veces, decidí tomarme unos minutos para grabar los siguientes dos videos. Espero les resulten útiles.

 

 

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.