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í.

Ideas para trabajos de fin de carrera

Quiero compartir algunas ideas para posibles trabajos de final de carrera, de haber algún interesado no dude en contactarme.

SmallChat

Es una aplicación de chat integrada en Pharo Smalltalk. Permite chatear y compartir código entre las imágenes. El escenario típico es un estudiante/aprendiz está trabajando en Pharo y se traba con un problema que no puede resolver, entonces inicia una sesión de chat, pide ayuda y puede compartir su código con otros participantes del chat.

Cloudeta

Es un gestor de publicaciones digitales basado en la nube. Básicamente permite tomar archivos de publicaciones (libros, artículos, etc) agregarles metadata y almacenarlas en la nube. Una vez almacenados permite buscar por diversos criterios y compartir los archivos.

AlfredSEAL

Estos dos sistemas ya existentes (y en uso) que permiten gestionar la publicación, entrega y corrección de trabajos prácticos de materias de programación. Ambos sistemas tienen un backlog de funcionalidades por implementar.

 

Un caso robusto de integración contínua en Java

En el proyecto en el que he estado trabajando los últimos meses tenemos montado un proceso de integración continua bastante completo en mi opinión, comparto aquí algunos detalles. Se trata de un proyecto Java, basado en Spring, Hibernate, Camel y algunos otros frameworks. A nivel de herramientas tenemos quality checks con PMD, pruebas unitarias y de aceptación con JUnit y pruebas de aceptación y carga con JMeter. Como herramienta de build usamos Maven, como servidor de integración continua usamos Jenkins y el código lo tenemos en Git (gitlab). Al mismo tiempo tenemos un ambiente de tests en la nube donde desplegamos nuestra aplicación periódicamente. También tenemos un ambiente de prueba en las oficinas del cliente, donde desplegamos nuestra aplicación al final de cada iteración. En el jenkins tenemos varios jobs:

  • integración continua: monitorea el branch develop y ante cada cambio compila, ejecuta las pruebas de JUnit (unitarias y de integración)
  • quality-check: se ejecuta a continuación del job de integración continua y caso_java_jenkins_2básicamente ejecuta análisis de código (pmd)
  • integración continua de branches: en algunos casos creamos feature-branches, para lo cual seguimos una convención de nombres y este job se encargar de ejecutar integración continua sobre estos branches. En general procuramos que estos branches no vivan más de 3 días.
  • inicialización: es el job que se dispara el build pipeline, y como tal comienza por inicializar el ambiente de test. Se ejecuta periódicamente (varias veces al dia siempre que haya cambios en el repositorio)
  • deploy: son dos jobs que se encargan de desplegar las dos aplicaciones que forman parte de nuestro sistema.
  • pruebas de aceptación: ejecuta las pruebas de aceptación (jmeter) luego de cada despliegue
  • pruebas de carga: ejecuta un conjunto de pruebas de carga. Este job lo ejecutamos manualmente al menos una vez por iteración para asegurarnos que los cambios realizados no haya impactado en la performance del sistema
  • generador de release: este job lo ejecutamos manualmente al final de cada iteración para generar un nuevo release lo cual implica: taggear el repo, generar y publicar los artefactos (wars y jars) y actualizar la versión en los archivos del proyecto (pom.xml)
  • generador de instalable: este job toma  los artefactos generados por el job de generación de release y los empaqueta junto con un grupo de scripts que luego se utilizarán para instalar  el sistema en los ambientes del cliente.

caso_java_jenkins

Planificando Febrero en Colombia

La segunda quincena de febrero estaré viajando a Colombia por cuestiones personales y se ocurrió que podria ser una buena oportunidad para hacer algunas actividades con mis colegas de Kleer Colombia. Por eso le escribí a amigo @luismulato contando la idea y ya estamos poniendo manos a la obra.

En principio estamos planificando dictar dos talleres abiertos en Bogotá:

  • Automatización de pruebas, el mismo es una variante del que hice hace un tiempo en Uruguay.
  • Devops y automatización de infraestructura, este es un taller que aún no he dictado nunca (en este formato), pero que a pesar de ello ya tengo casi todo el material listo, pues está basado en algunas de las actividades que he realizado en el contexto de otros talleres y capacitaciones que dicté en forma privada en empresas y en mi materia en UNQ.

Más allá de estos talleres, estoy abierto a realizar otras actividades (tanto de capacitación como de consultoría y también académicas) con lo cual, si hay algún interesado, no dude en contactarme.

Running background jobs on Ubuntu

Some time ago I mentioned a project I was working on to move an application from Heroku to a virtual server running on Rackspace. One of the challenges I faced in that project was setting up some background jobs.

Given that we were using Ubuntu we decided to use Upstart to manage the jobs.

Here is a summary of the procedure I followed:

  1. Create an specific user for the jobs to run (useradd worker)
  2. Create a config file to make upstart manage each job. These files should be placed under /etc/init/. These files should include some generic information for upstart (like the user that will run the service) and also some specific information related to job (like how to start it). Here you can find and example to configure Clockwork (a cron replacement app built on Ruby).
  3. Now to manage the job you can use this command
    sudo service clockwork {start|status|stop|restart}
  4. The log file of the job will be placed under /var/log/upstart and the file name will be <job_name>.log

Hope you find it useful.

Primeros pasos con Scala: FooTest

En último lenguaje que decidí aprender fue Scala y siguiendo la política que mencioné en un post anterior, comencé programado un FooTest.

Al intentar hacer esto me encontré que Scala, a diferencia de Ruby, no viene con ningún framework de test incluido. Luego de investigar un poco encontré que hay más de una herramienta de test disponibles en la web. Finalmente decidí utilizar ScalaTest. En cuanto a herramienta de build ya sabía de la existencia de SBT, así que simplemente investigué cómo hacer que SBT ejecutara los tests escritos con ScalaTest. El resultado fue este proyectito.

footest_scala

 

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.

 

FooTest el nuevo “Hola Mundo”

Tradicionalmente a la hora de aprender un nuevo lenguaje de programación uno comenzaba por programar una aplicación que imprimiera “¡Hola Mundo!” en la salida estándar. Creo que eso puedo estar bien en una época, pero en la actualidad escribir mensajes en la salida estándar no suele ser de gran utilidad.

Personalmente dejé de programar “Hola mundos” hace varios años y lo reemplacé por programar una prueba unitaria. Y en general suelo ir un poco más allá y hacer que la prueba unitaria se ejecute con la herramienta de build correspondiente con total independencia del IDE utilizado.

La prueba unitaria que suelo programar es siempre la misma, verifico que el método sayFoo de la clase Foo devuelva el string “foo!”. Esto me lleva a escribir la clase FooTest, la clase Foo y un script de build para correr el test.

Experiencias de Enseñanza de POO en WISIT 2014

El sábado pasado estuve participando del WISIT 2014. Junto con Pablo Suárez presentamos el enfoque estamos utilizando en FIUBA para enseñar Programación Orientada a Objetos.

En nuestra sesión destacamos 4 puntos que consideramos centrales en nuestro enfoque:

  • Uso de técnicas de educación centrada en el alumno (Learner Centered Teaching)
  • Uso de herramientas informáticas: Campus Virtual de la universidad, Foros, Sistema de gestión de TPs (alfred) y videos explicativos.
  • Uso de dos lenguajes: Smalltalk y Java
  • Test-Driven: no solo enseñamos y usamos TDD, sino que también el desarrollo de los trabajos tiene algo de TDD pues las especificaciones de los que los alumnos deben resolver, la entregamos siempre en forma de pruebas.

Creemos que la presentación salió muy bien y notamos a la audiencia muy interesada. De hecho al finalizar nuestra exposición recibimos varias consultas y más de una persona manifestó intenciones de probar Alfred.

Para facilitar la sesión sesión utilizamos un Prezi que armó Pablo y que está disponible aquí. También armamos este póster que enviamos en su momento a los organizadores del evento como parte de nuestra propuesta de sesión.

Curiosamente hubo otras dos sesiones en las que también se presentaron enfoques de enseñanza de POO. Una de esas sesiones estuvo a cargo de Alfredo Sanzo y Lucas Spigariol quienes contaron su enfoque fuertemente basado en actividades de representación/actuación y en el uso de objetos físicos.

La otra sesión sobre POO estuvo presentada por Nico Passerini, Javi Fernández y Pablo Tesone, quienes mostraron Wollok, una herramienta basada en Eclipse y un lenguaje desarrollado por ellos mismo con el fin específico de enseñanza de POO.

Ambos enfoques me parecieron muy interesantes.

Celebro la iniciativa Uqbar Project de llevar adelante este evento. ¡Que se repita!