Próximos eventos en lo que resta del 2014

Como es costumbre, la primera mitad del año no pasa nada y la segunda está tan cargada de eventos que resulta difícil decidir a cuales asistir. Comparto aquí una lista de los evento que personalmente me resultan de interés:

Del 14 al 15 de agosto se llevará a cabo en Facultad de Ingeniería de la UBA, el Simposio Argentino de Sistemas Embebidos, SASE 2014. Un evento del que nunca participé pero del cual planeo participar este año.

Del 1 al 5 de Septiembre tendrá lugar en la Universidad de Palermo la edición número 43 de las Jornadas Argentinas de Informática. Estas jornadas incluyen una serie de Simposios entre los que se encuentra el Simposio Argentino de Ingeniería de Software del cual tengo el honor de ser co-chair.

También en Septiembre, más precisamente 26 y 27, tendremos las primeras Jornadas Nacionales de Métodos Ágiles que se realizarán en las instalaciones de la Universidad de Belgrano con formato completamente Open Space.

Octubre viene cargado con 3 eventos en la semana del 20 de Octubre.

Del 23 al 25 de Octubre tendremos la séptima edición de las Jornadas Latinoamericanas de Métodos ágiles, Agiles 2014 a desarrollarse este año en Medellín (Colombia).

Casi al mismo tiempo que Agiles 2014 tendremos la RubyConf Argentina, una vez más en las instalaciones del Konex.

El tercer evento en esos mismos días es el Congreso Argentino de Ciencias de la Computación, CACIC 2014, que se desarrollará en las Universidad Nacional de la Matanza.

Ya en noviembre (5,6 y 7), en la ciudad de Córdoba, tendremos la Smallktalks 2014. Esta vez en las instalaciones de la Universidad Tecnológica Nacional.

Más allá de los eventos aquí mencionados, me consta que hay programados algunos más, pero no menciono pues no estan entre los que suelo asistir.

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.

 

 

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

 

Taller (experimental) de Testing

Hace varios de meses comenzamos a trabajar con mi colega Pablo Tobia en el armado de la un materia de Testing. Leímos, experimentamos, debatimos, hablamos con otros colegas y finalmente decidimos pasar a la acción: vamos a dictar un Taller de testing. El objetivo central de este taller es obtener feedback de lo que hemos armado para poder refinarlo de cara a presentarlo formalmente como una materia. A continuación comparto un poco más de información en forma de “Preguntas frecuentes” para los posibles interesados.

¿Qué duración tiene? Son 4 clases de 3 horas cada una. Adicionalmente al tiempo de clase se espera que los alumnos dediquen cierto tiempo (entre 1 y 2 horas semanales) a la realización de algunas prácticas.

¿Qué costo tiene el curso? Ninguno, es gratuito aunque posiblemente le pidamos a los alumnos algún tipo de contraprestación como por ejemplo traer alimentos para donar a un comedor comunitario o algo por el estilo.

¿Cuando se dicta? Aún no lo tenemos del todo definido pero la idea es hacerlo durante Julio aprovechando que no hay clases. Seguramente sea un día por semana a partir de las 18 o 19 horas.

¿Da créditos para la carrera? No, el taller es absolutamente extra-curricular.

¿Qué conocimiento previo necesito? El taller es muy práctico y está orientado a la automatización, con lo cual se espera que todo alumno pueda programar. En principio trabajaremos con Java y Ruby. Si no sabes de ninguno de estos lenguajes y crees que puedes darte maña para aprenderlos, no hay problema, pero nosotros no vamos a explicar Java ni Ruby. Al mismo tiempo, son necesarios cierto conocimiento de aplicaciones web (http, html, etc) y de metodologías de desarrollo de software.

¿Cuál es el temario del curso? En forma resumida podemos decir que veremos algunas cuestiones conceptuales, varias cuestiones de índole práctica y diversas herramientas como ser Cucumber, Fit, Watir, RSpec, JUnit, CasperJS y Selenium.

¿Cómo me anoto? Si estas interesado participar, te pedimos que completes este formulario.

 

 

 

Libros de testing

Luego de la inquietud planteada sobre mi percepción del testing en la industria y la academia, me dediqué a profundizar en el tema. Por un lado conociendo herramientas y buscando oportunidades laborales relacionadas al tema y por otro lado leyendo al respecto. Comparto aquí la lista de los principales libros que he leído/consultado:

 

 

 

 

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.

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