Autor: NicoPaez

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!

Selección de herramientas de prueba (parte 1)

Una de las decisiones a tomar al querer hacer pruebas automatizadas es qué herramientas utilizar. Para poder tomar esta decisión resulta importante entender mínimamente la arquitectura de una infraestructura de pruebas automatizadas. El siguiente gráfico resumen de forma muy general una arquitectura de modelo para esta problemática.

arq_pruebasSi bien el gráfico puede sugerir una arquitectura de capas, la misma rara vez se cumple a nivel de implementación pero si es cierto que para elemento representa un nivel de abstracción distinto en la estructura de la solución.

En el nivel de abstracción de más alto tenemos un lenguaje de especificación que nos permite expresar la prueba.
Un ejemplo de un lenguaje posible de especificación podría ser Gherkin.

En un segundo nivel tenemos un intérprete de ese lenguaje
que nos permitirá relacionar la especificación abstracta con fragmentos de código que escribiremos nosotros y que comúnmente se denominan «glue code».
Para el caso Gherkin tenemos como intérpretes las familia de herramientas Cucumber, en particular si quisieras escribir nuestro código en Java podríamos utilizar Cucumber-JVM.

En el tercer nivel tendremos un componente que denominamos **driver** que nos permitirá interactuar con nuestra aplicación. Lo que hace el driver en concreto es implementar el protocolo de comunicación necesario para interactuar con el sistema bajo prueba.
Siguiendo con el ejemplo anterior y asumiendo que el sistema bajo prueba es de tipo web, podríamos entonces utilizar Selenium Web Driver el ofrece una implementación en Java.

El siguiente elemento de nuestra arquitectura es la librería de aserciones, la cual nos permitirá precisamente hacer aserciones sobre el resultado de las operaciones realizadas sobre el sistema bajo prueba.
En este caso es común utilizar alguna librería de la familia xUnit. En el caso de Java utilizaríamos JUnit.

Finalmente, como último ítem de esta enumeración tenemos un motor de ejecución que se encarga de instanciar y ejecutar los elementos previamente mencionados.
En este caso una alternativa muy común en el mundo Java en particular es utilizar el mismísimo JUnit.

En la segunda parte de este artículo ofreceré algunos ejemplos concretos de implementación de esta arquitectura.

¿Realmente necesitas una nueva herramienta para hacer ATDD?

Recientemente recibí una consulta por Twitter sobre este tema y dado que la respuesta no entraba en 140 caracteres decidí escribir este post.

Acceptance Test-Driven Development (ATDD) es una práctica de desarrollo ágil cuya popularidad está en franco ascenso. La idea es simple: guiar el desarrollo de funcionalidades a partir de sus correspondiente pruebas de aceptación. ¿Pero eso no es TDD? Si y no. Conceptualmente ATDD es como TDD en el sentido que es la prueba la guía el desarrollo, pero en general cuando hablamos de TDD estamos hablando del desarrollo de clases, una actividad que realiza el programador. Cuando hablamos de ATDD (o BDD o SBE) hablamos del desarrollo de funcionalidades desde la perspectiva del usuario lo cual requiere del trabajo conjunto del usuario y el programador. Resumiendo:

La principal diferencia entre ATDD y TDD pasa por el involucramiento del usuario en la definición de las pruebas que guiarán el desarrollo y la granularidad de las mismas.

Incluso, hay quienes afirman que el mayor beneficio de ATDD no pasa por la automatización de las pruebas sino por el involucramiento temprano del usuario en la definición de las pruebas de aceptación.

Habiendo dejado en claro los conceptos, vamos a las herramientas. Cuando hacemos TDD escribimos las pruebas en el mismo lenguaje que estamos programando nuestras clases y utilizamos para ello alguna herramienta de la familia xUnit.

Cuando hacemos ATDD escribimos pruebas de funcionalidades desde la perspectiva del usuario e idealmente lo hacemos trabajando en conjunto con él. Esto nos obliga utilizar alguna herramienta de especificación que resulte amena para el usuario quien generalmente no es alguien técnico. Dos herramientas muy difundidas en este terreno son Cucumber y Fitnesse, las cuales ofrecen un lenguaje de especificación muy amistoso y poco técnico. Luego tendremos que escribir lo que se denomina «glue code» para traducir las especificaciones escritas por el usuario a instrucciones ejecutables que se traduzcan en mensaje concretos a nuestro sistema bajo prueba. Este este sentido, puede que esa traducción ocurra a distintos niveles. O sea, una especificación del usuario podria terminar siendo una prueba a nivel de UI o bien una prueba a nivel de servicio o incluso una prueba a nivel de componente o clase. Esto no es un tema menor, ya que tiene un importante impacto en la elección de la herramienta a utilizar.

Si yo pretendo hacer ATDD generando pruebas de aceptación a nivel de componente/clase, entonces deberé elegir una herramienta que esté construida en el mismo lenguaje que mi aplicación. Pero si yo prefiriera hacer pruebas a nivel de UI, entonces tendré más libertad y podré elegir utilizar un lenguaje distinto para programar las pruebas. En este sentido conozco de varios proyectos en Android, .NET y Java, con pruebas de aceptación realizadas con Ruby. Debo admitir que cuando vi esto por primera vez, me resultó chocante, pero luego estuve involucrado en un par de proyectos en que se utilizaba esta estrategia y resultó muy cómodo.

La consulta que disparó este post tenia que ver con herramientas para hacer ATDD cuando la aplicación está construida en .NET. Mi respuesta concreta es:

  • Si el usuario va estar involucrado activamente en la escritura/validación de las pruebas y esas pruebas serán a nivel UI
    => Tienes muchas alternativas pues no estas atado a .Net. Básicamente cualquier herramienta de la familia Cucumber o Fitnesse estará bien.
  • Si el usuario va estar involucrado activamente en la escritura/validación de las pruebas y esas pruebas serán a un nivel por debajo de la UI
    => Puedes usar Specflow o Fitnesse (con su conector para net)
  • Si el usuario no va estar involucrado, entonces tienes libertad total y puedes escribir tus pruebas incluso con algo de la familia xUnit, ya que los únicos que leerán esas pruebas serán los técnicos, pero claro, ya no estarias contando con todos los beneficios de ATDD.

Dicho todo esto: ¿Realmente necesitas una nueva herramienta para hacer ATDD?

Automatización de pruebas y entrega continua en Uruguay

En 25 de noviembre voy a dictar un taller sobre estas temáticas en Uruguay con la colaboración de @pablolis. La idea de hacer un taller que una estas dos temáticas surgió a partir de reiteradas consultas que he recibido y de encontrarme hablando de una de ellas a partir de una consulta que originalmente tenía que ver con la otra.

Ante todo me parece importante dejar bien en claro la relación entre estas dos cuestiones:

  • La automatización de pruebas puede hacerse independientemente de que se trabaje en un contexto de entrega continua. Más aún, ni siquiera es necesario que se trabaje con un proceso de desarrollo en particular. No importa si se trabaja con métodos ágiles, proceso unificado o algún proceso ad-hoc, siempre puede ser valioso automatizar las pruebas.
  • Trabajar en modo entrega continua requiere indefectiblemente contar con pruebas automatizadas, pues de lo contrario, habría que invertir mucho tiempo en pruebas manuales o bien ir a producción con un producto inestable o de calidad desconocida, lo cual podria traducirse en problemas continuos más que en entrega continua.

Con esta aclaración conceptual creo que queda clara la motivación para juntar ambas cuestiones en un mismo taller.

Hablando ahora de la estructura del taller, la idea es comenzar entiendo la práctica de entrega continua, sus beneficios, fundamentos y un conjunto de patrones para su implementación. Todo esto de la mano de un conjunto de herramientas para su implementación. En este sentido compartiremos con los participantes una máquina virtual con una aplicación de ejemplo y con un set de herramientas ya instalado, listo para que puedan poner manos a la obra a medida que vamos viendo las herramientas.

En varios puntos del flujo de entrega continua nos encontraremos con pruebas automatizadas. En cada uno de esos puntos nos detendremos a analizar el tipo de prueba y las distintas alternativas de herramientas para su automatización. Por más que las pruebas y herramientas las veamos en un contexto de entrega continua, como mencioné anteriormente, las mismas también pueden resultar útiles en cualquier otro contexto.

Entre las herramientas que veremos estan: Puppet, Chef, Docker, Jenkins, Go, Travis, Cucumber, Selenium, Fitnesse y JMeter.

Los interesados pueden consultar más detalles e información para inscripción en la página de Evolución Ágil.