Cierre de cuatrimestre en UNQ (2014-2)

Un nuevo cuatrimestre ha pasado y seguimos batiendo records, este cuatrimestre tuvimos 15 alumnos. Lamentablemente no todos aprobaron, en concreto tuvimos:

  • 11 aprobados
  • 2 abandonos
  • 1 desaprobado
  • 1 pendiente de aprobación

Otra novedad de este cuatrimestre fue la incorporación como colaboradora de Ingrid Calderón, una ex-alumna de la materia.

Básicamente mantuvimos la misma estructura y dinámicas que el cuatrimestre anterior con la incorporación de algunas innovaciones y mejoras surgidas de la retrospectiva del primer cuatrimestre. Entre las innovaciones, incorporamos en forma temprana mini TPs que denominamos Katas y que tenían como objetivo:

  • que los alumnos se familiarizaran con ciertas herramientas (ruby, rspec, cucumber, etc) y técnicas (tdd y bdd)
  • que se habituaran a estimar y planificar tareas
  • que se acostumbren a dar visibilidad sobre todo en caso de no poder cumplir con fechas comprometidas

En cuanto a los TPs, mantuvimos la misma estrategia (equipos de 3 personas trabajando sobre aplicaciones Ruby/Padrino) pero con una pequeña innovación: la formación de los equipos estuvo condicionada por el desempeño de los alumnos al momento de inicio del TP. O sea, si un alumno no habia completado todas las tareas anteriores al momento de inicio del TP, entonces no podía conformar equipo con alguien que sí las había completado. La motivación detrás de esto es: dado que las tareas son relativamente simples, quien no las completa es en general por falta de compromiso/interés en la materia, entonces procuramos que todos los equipos cuenten con gente con el mismo nivel de compromiso/interés.

En cuanto a visitas de la industria, este cuatrimestre tuvimos a:

Al igual que el cuatrimestre pasado hicimos una encuesta complementaria a la retrospectiva y según la misma, la evaluación general de la materia por parte de los alumnos fue de 8,8.

De la retrospectiva y la encuesta destacamos algunos puntos en los que trabajaremos el cuatrimestre próximo:

  • Explicar desde el comienzo los criterios de evaluación de la materia y del TP final
  • Reorganizar las katas de forma de incluir alguna con Padrino y Travis
  • Hacer más prácticas de programación en clase (dojos)
  • Publicar todos los recursos técnicos de forma temprana para que cada uno pueda organizarse mejor (en general los punblicamos a medida que vamos avanzando en la materia).
  • Reevaluar la estrategia para la formación de equipo para el TP final

unq_2014_2

Finalmente, este cuatrimestre les pedimos a los alumnos que graben una breve demo de las aplicaciones desarrolladas:

Tenemos un video más pero al no estar publicado en YouTuve no he logrado embeberlo aquí.

Agiles 2014, #NoSeréFeliz pero tengo trabajo

#NoSeréFeliz pero tengo trabajo, fue el título del keynote de Martín Alaimo el tercer día de Agiles2014. Posiblemente haya sido el mejor keynote que vi en las 6 ediciones de ÁgilesXX que participé (no estuve en 2010). Ya de entrada el título resultaba interesante. Más allá del contenido del keynote, destaco algunos elementos que a mi entender fueron claves para que el keynote sea realmente excelente:

  • Manejo de recursos: en primer lugar Martín manejó muy bien los tiempos y respetó lo que estaba agendado. También hizo un uso discreto pero muy apropiado de las diapositivas: diseño minimalista, pocos colores, poco texto, algunas imágenes, nada de transiciones. Esto hacía que audiencia no se distraiga con las diapositivas en cambio prestara atención a lo que Martín decía. También hizo uso de las luces, en un momento se apagaron todas las luces del auditorio lo cual sirvió para generar una atmósfera muy especial y en sintonía con lo .que se estaba hablando.
  • Vivencia: Martín comenzó contando una vivencia personal, lo cual generó una conexión con la audiencia.
  • Participación: a pesar de ser un keynote, Martín hizo participar a la audiencia en varias ocasiones. En un momento nos dió algunas consignas a realizar desde nuestro lugar y luego invitó a algunos voluntarios a subir al escenario.
  • Llamado a la acción: finalmente el keynote cerró con un llamado a la acción, una estupenda idea para el cierre pero que curiosamente pocas veces he visto.

Mientras escribo estas líneas, reflexiono, recorro mi memoria y llego a la conclusión de que este keynote está en el top 3 de las mejores sesión que presencie en mi vida.

¡Gracias Martín!

martin_at_agiles2014

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.

ASSE 2014, ya casi estamos

El programa del simposio ya está listo. Por un lado tendremos las actividades tradicionales del simposio: presentación de trabajos y conferencistas y por otro lado tendremos algunas actividades nuevas.

En lo que respecta a presentación de trabajos, tendremos 19 presentaciones de trabajos originales y 8 comunicaciones orales de trabajos que han sido presentados en otros simposios internacionales.

En lo que respecta a las conferencias tendremos 2 de sponsors (Red Hat y Pragma) y 3 más de invitados especiales. En este sentido contaremos con Esteban Feuerstein (Fund. Sadosky) quien hablará sobre Big Data, Alvaro Ruiz de Mendarozqueta y Juan Gabardini quienes hablarán sobre Métodos ágiles. La descripción de estas conferencias está publicada en la página del simposio.

Adicionalmente a la clásicas actividades mencionadas, tendremos dos novedades.

La primer novedad es un taller de Arquitectura emergente dictado por Diego Fontdevila (requiere inscripción aparte pues tiene cupos limitados). Pueden encontrar más detalles de este taller aquí.

La segunda novedad es un espacio de debate sobre Enseñanza de la ingeniería de software. Este espacio tendrá lugar el Jueves 4 de Septiembre a partir de las 16.30 hs. La dinámica de este espacio estará dividida en dos actividades y Luciana y yo seremos los facilitadores. En primer lugar tendremos sesiones en formato Lightning talks, la idea es que cada participante que lo desee pueda presentar en 5 minutos su enfoque para la enseñanza de ingeniería de software y las dificultades que suele afrontar (puede que el tiempo de presentación varie un poquito dependendiendo de la cantidad de interesados en presentar). Luego de estas presentaciones, pasaremos a un debate con formato Fishbowl.

El detalle completo del programa está disponible en la página del evento.

Clasificación de herramientas para automatizar pruebas de funcionales

Las pruebas funcionales son las que típicamente hace un tester, que más le importa al usuario y sería ideal definir en conjunto con él, pues estas pruebas interactúan con el SUT desde la perspectiva del usuario. Son pruebas que Marrick clasifica como Business Facing.

Para este tipo de pruebas es muy relevante la forma en que las herramientas permiten expresar la prueba, ya que dado que son “pruebas de usuario”, dependiendo de la forma en este planteado el proyecto podríamos querer que estas pruebas sean escritas por el usuario.
En este sentido es que las herramientas para automatizar este tipo de pruebas han adoptado distintos enfoques:

  • Record and Play: permiten “grabar” la interacción del usuario con el SUT para luego reproducirlo. Con este tipo de herramienta, básicamente se ejecuta manualmente 1 una vez cada caso de prueba mientras la herramienta va grabando la interacción de manera que la misma y una completada la grabación las pruebas pueden repetirse tantas veces como se guste de forma automática. Un ejemplo de este tipo de herramientas es SeleniumIDE.
  • Keywork-Driven: este tipo de herramientas permiten definir las pruebas utilizando un conjunto de palabras claves par estructurar la prueba. Luego es necesario escribir cierto código (glue code) para vincular la prueba (expresada con palabras claves específicas) y el SUT. En esta categoría de herramientas entra toda la familia de Cucumber.
  • Data-Driven: este tipo de herramientas permiten especificar la prueba a partir de condiciones expresadas en tablas. Cada tabla es interpretada por por cierto código (glue code) que permite la interacción con el SUT. Las herramientas de la familia Fitnesse entran en este grupo.

Si bien muchas veces las herramientas pueden utilizarse de diversas formas, en general suelen ser concebidas para ser utilizadas de una forma particular (una silla es concebida para sentarse, sin embargo en ocasiones es posible utilizarla para elevar nuestra altura como si fuera una escalera). En este sentido cada herramienta puede verse más orientada con alguno de los grupos mencionados, pero ello no quita que la podamos usar de forma distinta.

Reportes en Jenkins

Si bien últimamente vengo trabajando muy felizmente con Travis, una de las funcionalidades que extraño mucho son los reportes. Cuando trabajo con Jenkins suelo hacer que mis jobs de CI muestren diversos reportes.

Hay dos estrategias para mostrar reportes en Jenkins:

  1. Utilizar las capacidades de reporting de Jenkins, ya sea nativas o con plugins, o bien
  2. Hacer que cada herramienta que forma parte del build genere sus propios reportes y luego simplemente hacer que Jenkins provea acceso a dichos reportes.

Un ejemplo del primer caso es el plugin de Cucumber-jvm que genera un reporte como el de la figura 1.

cucumber_jenkins
Figura 1

Un ejemplo similar pero usando la segunda estrategia sería ejecutar cucumber especificando que genere output HTML y luego usar el plugin Sidebar link de Jenkins para linkear el reporte generado por cucumber. En figura 2 se ve un caso de esta estrategia donde Jenkins provee links un reporte de features generado por cucumber y otro de coverage generado por SimpleCov. La figura 3 muestra cómo configurar los links a los reportes una vez instalado el plugin.

reportes_jenkins
Figura 2

 

sidebar_links
Figura 3