Después de varios años de escritura, he decidido experimentar con otro formato para difundir ideas/conocimiento/opiniones. El formato en cuestión es podcast. Para grabarlo utilicé Garage Band y luego lo subí en SoundCloud. Respecto de la temática de este primer experimento, decidí tratar una cuestión que escribí en el libro de ensayos del AOC: La popularidad de agile.
Categoría: curiosidades
[OT] El día que metí un triple
Una vez más me tomo una licencia para salir de la temática usual de este blog para compartir un tema personal. Espero los habituales lectores sepan disculpar.
Por esas cosas que tiene la mente que uno no termina de entender, ayer espontáneamente recordé el primer triple que convertí en mi carrera de basquetbolista en un partido oficial. Como es un recuerdo muy grato para mi y no quisiera olvidarlo he decidido escribirlo.
Antes de ir al hecho concreto, comparto un poco de contexto. Comencé a practicar basquet cuando tenía unos 8 o 9 años pero no fue hasta los 12, cuando me sumé al CEF 31 de Marcos Paz, que comencé a competir regularmente. Si bien nunca fui alto, en aquella época era de los más altos de mi equipo. Ello sumado al hecho de que me daba mañana forcejeando cerca del aro determinó que me tocara jugar de interno. Al mismo tiempo nunca fui un gran encestador, mi promedio de puntos por partido rondaba los 10 (aunque en una tarde muy poco usual fui el goleador de mi equipo con ¡34 puntos!).
Ahora si, el hecho en cuestión. Era el año 1996 y estábamos jugando en un triangular organizado en el club González Catán en el cual participábamos: los locales (González Catán), nosotros (CEF 31) y nuestro clásico rival: Central Norte de Laferrere. Estábamos jugando contra Central Norte, se aproximaba el final del primer tiempo e íbamos ganado. Nos tocaba atacar, quedaban unos pocos segundos en el reloj, un par de pases y la pelota llegó a mis manos cuando tan solo quedaban 2 segundos. Estaba en zona de triple y si bien la estadística no me acompañaba (nunca había metido un triple en un partido oficial) no había opción pues se acababa el tiempo, así que simplemente lancé.
La pelota entró junto con el sonido de la chicharra que anunciaba el fin del primer tiempo.
Estadísticas personales 2016
Desde que comencé a trabajar en forma independiente registro con bastante detalle el tiempo que dedico a mi actividad profesional y dado que me gustan las estadísticas y el cierre de año parece un momento propicio para actualizarlas.
Durante 2016 hice un cambio relevante en la utilización de mi tiempo motivado principalmente por tomar un cargo de mayor dedicación en la Universidad. Analizando mi registro de horas los números indican que mi dedicación industria/academia fue 60/40.
Del análisis se desprende también que el promedio de horas trabajadas semanalmente (industria + academia) suma 32 horas semanales. Aquí hay algunos puntos a tener presentes:
- El trabajo en la academia tiene «pozos y picos», por ejemplo durante enero/febrero la actividad es muy baja debido a que no hay clases, mientras que durante diciembre y julio/agosto suele haber picos debido al cierre de cuatrimestre.
- Las horas aquí contabilizadas del trabajo en la industria son solamente las horas facturables. Cuando uno trabaja en proyectos de desarrollo el total de las horas dedicadas son facturables, pero cuando los proyectos son de consultoría/capacitación hay algunas horas que no se facturan (típicamente las dedicadas a la pre-venta)
- No están reflejados en el registro de horas las cuestiones de «formación, marketing y similares», o sea: los cursos, conferencias y charlas a los que asistí, ni tampoco las lecturas ni las katas que realicé, ni mucho menos el tiempo dedicado a pre-venta, ni a escribir en este blog, ni tampoco los cursos que armé y dicte en empresas. Al mismo tiempo cabe destacar que muchas de estas actividades no son exclusivamente académicas ni industriales pero sin embargo aportan a ambas dimensiones ya que en mi caso particular ambas dimensiones están enfocadas en la misma área de conocimiento: ingeniería de software.
En base a lo puntos anteriores se desprende que en realidad dedico más de 32 horas promedio por semana a mi actividad profesional, la pregunta que surge entonces es: ¿cuantas horas trabajo por semana? La respuesta no es trivial, como indica un viejo dicho «búscate un trabajo que te apasione y no trabajarás nunca más«, puede sonar a chiste pero es mi realidad. De todas formas quiero intentar dar una respuesta a esta pregunta. En términos generales dedico a mi actividad profesional el horario típico de oficina o sea de lunes a viernes de 9 a 18, a excepción de los martes por la mañana y viernes por la tarde que intento dejarlos libre. Pero al mismo tiempo dos veces por semana dicto clases en la universidad después de las 18. Finalmente los sábados por la mañana por la mañana también los dedico a cuestiones profesionales, generalmente lecturas relacionadas a mi proyecto de investigación. Con lo cual en términos generales dedico unas ~44 horas a cuestiones profesionales, lo cual implica unas ~12 horas típicamente no facturables directamente que suman tanto a mi actividad profesional como académica.
Al analizar las tecnologías con las que he trabajado en este 2016 se destaca .Net, cosa que no ocurría desde 2013.
Finalmente en lo que respecta conferencias/eventos/cursos:
- Participé en 5 conferencias grandes, cuatro de ellas internacionales
- Participé de 6 cursos (sin contar las sesiones de las conferencias)
- Dicté/facilité 12 cursos/charlas
Finalmente en lo que respecta a este blog, escribí 101 artículos, prácticamente 1 cada 3 días.
Mirando en retrospectiva y comparando con años anteriores este 2016 fue un año muy intenso y el pronóstico para 2017 (al menos en los primeros meses) pinta muy parecido.
Fontela los cría y el AOC los junta
El último fin de semana estuve participando del Agile Open Camp. En un momento dado me encontré compartiendo una mesa con otros cuatros egresados de FIUBA y curiosamente todos ex-alumnos de Carlos Fontela en Algo3. Pero como si fuera poco, había en la conferencia algunos otros ex-alumnos que no estaban en la mesa en ese momento.
La coincidencia nos pareció divertida así que al día siguiente nos sacamos una foto todos juntos.
Arriba: Marcos Pozzo, Fer Claverino, Ricardo Markiewicz, Vanesa Savino, Pablo Suarez, Elias Molini. Abajo: Pablo Tortorela, NicoPaez, Sole Pinter.
Agiles 2015: octava edición, ¿alguien lo imaginaba?
Hace un tiempo haciendo limpieza de mi casilla de correo encontré un mail de @jgabardini invitandome a participar de la organización de lo que fue Agiles 2008.
Con gran gusto acepté la invitación, un par de meses después la iniciativa se materializó y tuvimos la primera edición de la Conferencia Latinoamericana de Método Ágiles: Ágiles 2008.
Desde entonces la conferencia se ha realizado todos los años de forma ininterrumpida en distintos países de la región: Argentina, Brasil, Perú, y Colombia. Este año le toca a Uruguay y por eso estoy escribiendo este artículo sentado en un bar de Montevideo ubicado en el barrio «Ciudad Vieja».
Ya desde la previa, esta edición se destaca por dos hecho inéditos:
- la mitad de los participantes de la conferencia son extranjeros (históricamente la cantidad de extranjeros no ha superado el 40%)
- las entradas se agotaron semanas antes de la conferencia (de hecho estoy casi seguro que nunca antes se habían agotado).
El evento comienza en un par de horas, gran parte de los participantes ya están en la ciudad y la ansiedad va en ascenso.
Me pregunto: ¿alguno de los miembros del equipo organizador de Ágiles 2008 se imaginaba que llegaríamos hasta aquí? Yo sinceramente no.
Breve historia de las herramientas BDD – parte 2
En un artículo anterior conté una parte historia, he aquí la otra.
Mientras que Dan North y los suyos trabajaban sobre JBehave y afines que luego llevarían al surgimiento de Cucumber, Ward Cunningham trabajaba en cuestiones relacionadas a pruebas de aceptación.
El trabajo de Cunningham se tradujo concretamente en una herramienta llamada FIT: Framework for Integration Testing, cuyos objetivos pueden resumirse como:
- Ayudar a pensar y comunicar las necesidades que debe cubrir una aplicación de software en base a ejemplos concretos de uso
- Probar automáticamente desde una perspectiva de negocio que una aplicación de software hace lo que efectivamente se espera de ella y que continúa haciéndolo a medida que crece en funcionalidad
Para lograr esto, FIT propone escribir los ejemplos con herramientas capaces de generar HTML (Word, Excel, etc) utilizando distintos tipos de tablas para dar cierta estructura unificada a los ejemplos y facilitar así su interpretación. Una vez escritos los ejemplos trabajando en conjunto con gente de negocio y técnicos, se escribe código Java que interpreta la tablas e interactúa con la aplicación en cuestión.
El propio Ward Cunningham escribió la primera implementación FIT en Java, mientras que tiempo después James Shore tomó la coordinación general del proyecto y colaboró en la implementación en C#.
En 2005 Ward Cunningham junto con Rick Mugridge publicaron el libro Fit for Developing Software: Framework for Integrated Tests, el cual explica de forma bastante detallada el uso de FIT.
A lo largo del tiempo han ido surgiendo diversas herramientas en el ecosistema FIT, algunas de las cuales se integran con FIT mientras que otras lo extienden. Una de las más destacadas es FitNesse, desarrollada por inicialmente por Robert Martin y que en cierto modo agrega una interface de usuario por encima de FIT permitiendo que los ejemplos sean escritos en una Wiki. De esta forma FitNesse oficia de interface de usuario y FIT de motor de ejecución. Esta combinación tuvo buena recepción en la comunidad y para 2006 David Chelimsky y Mike Stockdale ya habían publicado una implementación de FIT en C#.
Fue a partir de esa implementación en C# que en 2008 Gojko Adzic publicó el excelente libro Test Drive .NET Development with FitNesse. Si bien este libro tiene un foco técnico, el autor resalta la importancia del trabajo colaborativo en entre gente de negocio y técnicos para la identificación y especificación de ejemplos. Los siguientes libros de Gojko se centraron precisamente en estas cuestiones de colaboración dejando de lado las cuestiones técnicas.
Fuentes:
- Sitio oficial de FIT
- Sitio oficial FitNesse
- Libro Fit for Developing Software: Framework for Integrated Tests de R.Mugridge y W. Cunningham
- Libro Test Drive .NET Development with FitNesse de Gojko Adzic
- Libro Specificacion by Example de Gojko Adzic
El placer de trabajar con quien uno gusta
Varios son los beneficios de trabajar de manera independiente, pero dudo que alguno sea más gratificante que el hecho de poder elegir con quien trabajar.
En este sentido ayer tuve el gusto de compartir una mañana de trabajo con Pablito Tortorella (@pablitux). Pablo y yo estamos trabajando en un cliente, Pablo enfocado en cuestiones de adopción de Scrum y mejora organizacional y yo en cuestiones de integración continua y pruebas automatizadas. Si bien son temas distintos, tienen puntos de contacto y complementación. Ayer en particular estuvimos trabajando armando la infraestructura de prueba con un equipo que está físicamente distribuído.
Fue una mañana intensa, trabajamos todos juntos sentados frente a dos pantallas: una con el Hangout (teníamos miembros del equipo conectados en forma remota) y otra con el código del proyecto.
Logramos el objetivo que nos habíamos propuesto (tener una prueba corriendo sobre la nueva arquitectura), aprendimos, la pasamos bien y acordamos repetirlo la semana próxima.
¡Gracias Pablitux!
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é:
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é.
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:
- Artículo Story Runner in Plain English de David Chelimsky
- Artículo Introducing RBehave de Dan North
- Artículo JBehave 2.0 is Live! de Dan North
- Artículo JBehave and RSpec History de Ed Gibbs
- Artículo Behaviour-drive development de Wikipedia
- Libro The Cucumber Book de Wynne y Hellesoy
- Libro The RSpec Book de Chelimsky y otros
- Sitio de oficial JBehave
- Sitio oficial de Cucumber
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.
Blog de NicoPaez 