Mis estadísticas 2014

El fin de año es un período que comúnmente se utiliza para hacer un balance del año que se va. Yo mismo suelo hacerlo pero no pretendo aburrir a mis lectores con mi balance, sino que quiero compartir algo que me parece más interesante: estadísticas.

Para que se entiendan los números que quiero compartir es necesario que expliqué a grandes rasgos la forma en que suelo trabajar.

Mi trabajo se reparte entre actividades académicas (principalmente docencia) y ejercicio profesional. Este último lo hago en el contexto de proyectos, o sea, me involucro en el ecosistema del cliente, definimos objetivos de forma conjunta a cumplir en ciertos plazos. Luego trabajo de cerca con mi cliente de cara a lograr esos objetivos. Establecemos fecha de revisión en las cuales analizamos el trabajo realizado y el nivel de cumplimiento de los objetivos, en base a ello definimos la continuación o no de mi acuerdo de trabajo.

Yo suelo organizar mis jornadas de trabajo en base a pomodoros y mis acuerdos de trabajo suelen times & materials. Esto, sumado al hecho que me gusta ser muy transparente con mis clientes, me lleva a tener un registro detallado de las actividades realizadas y el tiempo insumido.

Si bien en los proyecto en que participo suelo hacer diversas actividades, siempre hay una que es la principal y que en cierto modo define mi rol en el proyecto. En este sentido mis proyectos se clasifican 4 grupos: desarrollo, testing (automatización de pruebas), operación (automatización de infraestructura) y capacitación (cursos informales y docencia universitaria).

Hecha la introducción quiero compartir en primer lugar cómo estuvo repartido mi tiempo en base al tipo principal de actividad que desarrollé en los proyectos que participé:

distribucion_actividad

Como muestra el gráfico precedente, mi principal actividad durante 2014 fue desarrollo, seguido en segundo lugar por capacitación la cual fue casi exclusivamente en contexto universitario. Hay algunas otras actividades que decidí omitir del gráfico por ser excepcionales (como la facilitación de eventos) o por no ser directamente facturables (como conferencias y el tiempo invertido en la escritura del blog y del libro).

Dado que mi principal actividad fue desarrollo, tiene entonces sentido analizar cuáles fueron las tecnologías con las que trabajé.

distribucion_tecnologia

 

La distribución de tecnologías está hecha en base a la tecnología principal del proyecto, por eso es que no figuran las tecnologías de presentación como HTML y CSS. Al mismo tiempo en lo que especifiqué como scripting estoy incluyendo cosas tales como shell script, powershell, puppet y chef.

Bueno, esto es todo por 2014, ¡nos leemos en 2015, felicidades!

Breve historia de las herramientas BDD

Uno de los mayores referentes en lo que a BDD respecta es Dan North. Hacia el año 2003 Dan se encontraba trabajando en ThoughtWorks cuando creo JBehave. Según el mismo cuenta, JBehave comenzó como un experimento para ver como podría haber sido JUnit si se hubiera concebido desde un principio como una herramienta para hacer TDD en lugar de un mero framework de pruebas automatizadas. Fue por aquel entonces que el dominio jbehave.org fue registrado. Con el correr del tiempo JBehave fue evolucionando con foco en la automatización de pruebas de aceptación.

Tiempo más tarde algunas ideas de JBehave fueron incorporadas por Dave Astels en RSpec.

Hacia 2007 Dan North inspirado por el la tracción generada por RSpec y con la intención de proveer una forma simple y elegante de describir comportamiento a nivel de aplicación publica RBehave, el cual trae como novedad la posibilidad de especificar comportamiento en texto plano, idea que luego daría origen a lo que en la actualidad se conoce como sintaxis Gherkin.

Al poco tiempo David Chelimsky incorpora en RSpec el soporte de especificaciones en texto plano.

En 2008 Liz Keogh and Mauro Taveli reescriben completamente desde cero JBehave haciendo uso de algunas característica recientemente incorporadas en Java 5 y utilizando JUnit 4 como runtime. Entre otras cosas incorporan soporte para especificaciones en texto plano e integración con Maven. El resultado es JBehave 2.

Por aquel entonces Aslak Hellesoy ya se encontraba trabajando en un reemplazo para el ejecutor de especificaciones en texto plano de RSpec, el cual sería bautizado como Cucumber. La primera versión de Cucumber fue liberada hacia fines del 2008.

Mi percepción es que Cucumber marcó un punto de inflexión en la difusión de BDD. Fue precisamente en el contexto de Cucumber que se estandarizó la sintaxis de especificación en texto plano y se la bautizó como Gherkin.

Fue tal el impacto de Cucumber, que en la actualidad existen herramientas de BDD con soporte para Gherkin implementadas en diversos lenguajes, algunas de ellas son directamente reimplementaciones de Cucumber sobre otras plataformas (tal es el caso de Cucumber-JVM).

Fuentes:

 

Una empresa interesante: Poincenot Technology Studio

La segunda mitad de este año estuve trabajando con la gente de Poincenot. La experiencia me resultó muy interesante por una serie de cuestiones que van allá de la temática del proyecto en que participé.

En primer lugar me reencontré con algunos estudiantes/graduados de FIUBA, lo cual nos dio tema de conversación para más de un almuerzo.

Tuve la oportunidad de compartir algunas conversaciones con los fundadores de la empresa y me llamó poderosamente su visión, la cual yo interpreté como: «Somos un estudio de tecnología enfocados en habilitar negocios, no desarrollamos software porque sí, sino que lo hacemos para apalancar negocios. La tecnología no es un fin en sí mismo, sino un medio«. A mi entender esto representa un foco claro en la entrega de valor lo cual en gran medida explica el hecho de que muchas cosas en Poincenot se hagan con mindset ágil.

Poincenot es un empresa con menos de un año de vida, pero con un equipo de profesionales excepcionales tanto a nivel management como técnico. En el equipo de management están Mario López, un técnico convertido en hombre de negocios, Facundo Vazquez y Augusto Fernández Villa, ambos ex-Tecso. Dentro del equipo de técnicos destaco a Maia, egresada de FIUBA con quien tuve el gusto de trabajar años atrás. Maia tiene un master en Human-Computer Interaction y a penas regresó se sumó  a Poincenot donde está liderando las cuestiones de UX. También entre los técnicos hay un par de expertos Java con los que estuve trabajando de cerca y de quienes aprendí muchísimo (gracias Lio y Dani).

Y como si con todos esos profesionales fuera poco, han sumado algunos profesionales externos para colaborar con algunas cuestiones específicas. Fue así que durante mi participación en Poincenot me encontré trabajando con Alan Cyment, Sole Pinter y Diego Fontdevila.

Para cerrar te digo: si estas evaluando un cambio de trabajo, te interesa ser parte de un proyecto prometedor y trabajar en un ambiente profesional y ameno, no dudes en contactarte con Poincenot.

poincenot

Nuevos Técnicos en Programación graduados de UNQ

El viernes pasado fue la presentación del trabajo de final de carrera de Marcia Tejeda y Néstor Muñoz. Con la presentación y aprobación de trabajo, Marcia y Néstor completaron la Tecnicatura Universitaria en Programación Informática y se convirtieron en los egresados 13 y 14 de esta jóven carrera.

Yo tuve el gusto de dirigir el trabajo junto a Fidel. El mismo consistió en el desarrollo y puesta en marcha de una aplicación para el proceso de Triage del servicio de guardia del Hospital Arturo Oñativa de Rafael Calzada.

Este fue el primer trabajo que dirigí en UNQ y estoy verdaderamente muy contento con el resultado por diversos motivos:

  • La pieza de software creada (producto)
  • La forma en que se trabajó (proceso)
  • El hecho de que el software quedó funcionando en manos del usuario (valor)
  • El hecho de que el software optimiza un proceso negocio con impacto en la sociedad (valor)

Los dos primeros ítems son bastante esperables por tratarse de un desarrollo realizado en un contexto académico, pero los últimos dos me parece que no son tan comunes y son de gran valor.

La aplicación fue construida con Grails + Angular, dos tecnologías que los alumnos tuvieron que aprender como parte del alcance del trabajo.

Mis felicitaciones para Marcia y Néstor por el trabajo realizado y también mi agradecimiento por haber confiado en mí para la dirección del trabajo.

fidel_marcia_nestor
Néstor, Marcia y Fidel

 

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 encarga 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 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 (codeadas con 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