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.

 

 

Anuncios

Real-world TDD

El viernes pasado me tocó trabajar en una funcionalidad relativamente simple. Dada una aplicación de gestión de proyectos que tiene la capacidad de recibir mails (chiliproject) me pidieron que le agregue la capacidad de rutear los mails de entrada a uno u otro proyecto dependiendo de cierto algoritmo. Cuando estaba por empezar a desarrollarla pensé: “este es un excelente ejemplo para mostrar el uso de TDD en un contexto real”. Entonces abrí mi software de grabación y me puse trabajar. El resultado es este video que muestra cómo resolví parte del problema usando TDD. Espero lo disfruten.

Cierre de cuatrimestre en UNQ (2014-1)

Este cuatrimestre batimos algunos records. En primer lugar tuvimos record de alumnos: 14, al mismo tiempo tuvimos record de deserciones: 5, ¡ups! demasiado para mi gusto.

Hablo en plural pues ya desde el cuatrimestre pasado la materia la estoy dictando junto con @pablitosuarez

Como teníamos planeado, continuamos trabajando con el campus y más aún, potenciamos su utilización. Creamos varios cuestionarios como evaluaciones complementarias para algunos temas.

En lo que respecta a los TPs finales, hicimos algunas variantes. En primer lugar nos dividimos los grupos de manera que cada docente fuera product owner de dos grupos. Al mismo tiempo los grupos trabajaron sobre dos aplicacione distintas. Una de ellas era una aplicación creada de cero, mientras que la otra era una aplicación existente a la que debía agregarse funcionalidades. Quedamos muy conformes con la dinámica y los resultados, por lo cual estimo que repetiremos el cuatrimestre próximo.

Mantuvimos la dinámica de visitas de gente de la industria, en este caso tuvimos 3 visitas de excelente nivel de empresas radicalmente distintas:

Adicionalmente a la ya clásica retrospectiva de fin de curso, este cuatrimestre hicimos una encuesta anónima que nos permitió obtener una evaluación más cuantitativa. De esta encuesta sacamos que la evaluación general de la materia por parte de los alumnos fue: 8.4.

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

  • Comenzar con la kata de ruby en forma temprana para que los alumnos tenga más tiempo de familiarizarse con Ruby antes de comenzar con el trabajo final
  • Planificar con mayor anticipación las últimas semanas de clase de manera de poder hacerlas más interactivas
  • Alinear mejor entre los docentes los criterios de evaluación de los grupos

Aprovechando la moda, cierro el post con una selfie junto a los alumnos que estuvieron presentes la clase de cierre (solo falta uno que estuvo ausente por razones de salud).

unq-promocion-sexta
Sexta promoción de la materia desde que está a mi cargo

 

 

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

 

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.

Automatización de pruebas: principios, prácticas y herramientas

Finalmente, me hice un rato y mandé mi propuesta de sesión sobre este tema a Agiles 2014. Para quienes gusten darme feedback, pueden ver la propuesta completa en el sistema de call for papers de la conferencia.

Una cuestión que no está mencionada en la propuesta es qué fue lo que me llevó a proponer una sesión sobre este tema.

Como programador y sobre todo desde que me metí en el mundo Smalltalk, las pruebas unitarias automatizadas se volvieron un artefacto imprescindible en mi trabajo. Al ser Smalltalk un lenguaje de tipado dinámico no contaba con la (falsa) seguridad que proveen los compiladores en los lenguajes de tipado estático. Por esto me sentía obligado a escribir pruebas unitarias automatizadas para tener cierto nivel de seguridad de que no estaba rompiendo mi proyecto. Tiempo más tarde cuando comencé a trabajar en la implementación de la práctica de continuous delivery tomé conciencia de que con automatizar las pruebas unitarias y de componentes no era suficiente. Fue en ese momento que comencé a meterme gradualmente en las cuestiones de automatización de pruebas de aceptación de usuario. En ese sentido trabajé con Juan Gabardini en preparar un curso de automatización de pruebas y tiempo después comencé a trabajar con Pablo Tobia (alto tester) en el armado de una materia de testing que finalmente materializamos en el curso que dictamos en FIUBA. Al mismo tiempo para ganar más experiencia de campo logré meterme a trabajar como Software Engineer in Test en un proyecto de automatización de pruebas de un sistema de facturación. Todo esto me ayudó a ganar experiencia e incorporar muchísimo conocimiento sobre esta temática.

Como de costumbre, si la sesión es aceptada en Ágiles 2014, intentaré hacer una prueba previa en uno de los encuentros de la comunidad ágile@BsAs, mm, en realidad creo que la prueba lo voy a hacer igual más allá de que sesión sea aceptada en Agiles 2014 o no.

Nuevo proyecto, full Java

Esta semana comencé a trabajar en un nuevo proyecto que va a requerir que me meta con Java en profundidad. El proyecto consiste en el desarrollo de lo que podríamos denominar un Middleware, básicamente una aplicación que permite integrar aplicaciones.

Equipo de 3 personas, iteraciones de 2 semanas, Jira, Slack, Git, Jenkins, Maven, Spring, Camel, Eclipse, JUnit, Mockito y algunas otras cosillas.

Continuará…