Categoría: opinion

Los dilemas del uso de Gherkin/Cucumber

Como mencioné anteriormente, estoy trabajando un proyecto ocupando el rol de Software Engineer in Test (SET). Una de las primeras cuestiones que debí resolver en el proyecto fue acordar con los analistas/testers la convenciones para escribir los tests con Gherkin. Todo aquel que haya trabajado con Gherkin en algún momento seguramente se ha enfrentado a los diversos dilemas que plantea el uso de la herramienta.

Dilema 1

  • Escribir steps con parámetros, que permiten un alto reuso de steps definitions disminuyendo la cantidad necesaria de glue-code
  • Escribir steps sin parámetros, que permiten un mayor nivel de abstracción y expresividad, pero que al mismo tiempo requieren de más glue-code

Dilema 2

  • Agrupar los steps definitions por feature, lo cual posiblemente genere muchos archivos de steps definitions y también repetición de glue-code, pero que facilita la trazabilidad entre los archivos de features y los archivos de steps definitions
  • Agrupar los steps definitions por concepto de negocio, lo cual ayuda a reducir la cantidad de archivos y la posible repetición de código, pero que puede dificultar la trazabilidad entre archivos de features y archivos de steps definitions

Dilema 3

  • Hacer steps “stateless” (que no dependen de datos de contexto) lo cual permite mayor reuso, pero que obliga a pasar la información de contexto como parámetro de los steps
  • Hacer steps “stateful” (que sí dependen de datos del contexto) lo cual permite reducir/omitir los parámetros en los steps, pero que disminuye el reuso de steps y obliga a generar código adicional para el manejo del contexto

En todos los dilemas planteados existen más alternativas que las mencionadas, de hecho las alternativas aquí planteadas son en cierto modo extremas pero sirven para ejemplificar algunas de las cuestiones que debemos definir al trabajar con esta herramienta.

Al mismo tiempo hay algunas cuestiones adicionales a considerar dependiendo de la implementación de cucumber que utilicemos. Por ejemplo: la implementación Ruby es un DSL que permite fácilmente compartir estado entre los steps definitions independientemente de la forma en que los agrupemos, mientras que en la implementación Java (Cucumber-JVM) sólo es posible (en principio) compartir estado entre los steps definitions que esten agrupados en la misma clase.

Todas estas cosas son las que estuve definiendo la primer semana de proyecto. Ahora estoy trabajando en generar un “micro framework” (básicamente algunas clases helpers) que me faciliten la implementación de los steps definitions.

Continuará…

 

 

 

Las Heras Basket, historia de un logro merecido

Una vez más voy a tomarme una breve licencia para desviarme de la temática habitual de este espacio y dedicar algunas líneas a una iniciativa deportiva de la que soy parte.

La iniciativa de la que quiero hablar no tiene un nombre oficial, pero si lo tuviera sería algo del tipo “Las Heras Basket”.

Me gustaría empezar por el principio, pero sinceramente no tengo en claro cuando comenzó todo esto. Podría situar el inicio a mediados de los 90′ cuando conocí a varios de mi compañeros actuales en esta iniciativa. O tal vez podría situarlo hacia 2006, cuando luego de varios intentos fallidos finalmente logramos, gracias a la buena predisposición de las autoridades del Instituto San Luis Gonzaga, contar con un espacio para la práctica de este deporte que amamos.

Ese primer espacio fue justamente el gimnasio del Instituto San Luis Gonzaga, donde nos reuníamos todos los sábados de 15 a 18 hs a entrenar basket. Dedicabamos aproximadamente 2 horas para hacer diversos movimientos y luego cerrábamos con un picadito. No recuerdo exactamente quienes participábamos de ese espacio, pero recuerdo claramente que estaban Alban, NicoG, Laza, Beron y Bil. Tiempo más tarde se sumaron Santi, Hety, Ema, los Recaite, Chapita y otros más. El número de asistentes variaba, pero en general éramos alrededor de 10. En ocasiones superamos los 15 y en total por ese espacio deben haber pasado unas 30 personas.

De vez en cuando organizábamos algún partido amistoso con la gente de Navarro y Marcos Paz. Y una vez al año participábamos en los Juegos de la Cuenca del Salado (una competencia regional con formato de eliminación directa).juegos_2009

A fines de 2008 compramos nuestro primer  (y único hasta el momento) juego de camisetas. Para esto tuvimos que elegir un color.

 

 

Dado que nuestros contrincantes más frecuentes vestían de azul, celeste, blanco o rojo, decidimos inclinarnos por el negro.

amitoso2009

Lamentablemente hacia comienzos del 2010 nos quedamos sin espacio físico donde entrenar. Debido a un incidente totalmente ajenos a nosotros el Instituto San Luis Gonzaga decidió remover los aros de basket del gimnasio. Si bien en el pueblo había otras canchas de basket ninguna de ellas era de acceso público y al mismo tiempo no logramos establecer ningún acuerdo con las instituciones que las poseían. A pesar de esto seguimos jugando algunos amistosos y participando en los Juegos de la Cuenca.

Tiempo más tarde el gobierno local colocó un aro en el playón del campo de deportes municipal y ello nos permitió volver a reunirnos para entrenar. Si bien el espacio era bastante precario, al menos representaba un punto de encuentro y nos permitia hacer un poco de basket. Estando en ese espacio fue que se sumaron nuevas caras a la iniciativa. navarro_2010

El siguiente hito importante fue la organización de la Liga Navarrense de Basket Amateur, de la cual fuimos invitados a participar. En la primera edición fuimos 4 equipos y nuestros resultados fueron bastante pobres (de hecho me parece que no ganamos ningún partido), pero a pesar de eso la experiencia fue muy positiva ya que nos permitió consolidar el grupo y lograr más difusión de nuestra iniciativa.

Fue así que para la segunda edición de esta liga que contó ya con 6 equipos, sumamos nuevas caras al plantel estable, quedando conformado de la siguiente manera:

  • Alban, Santi, Gus y Coto (internos)
  • Elias, Hety, Franco, Bill, Dami (aleros)
  • Pipa, NicoG, NicoPaez (bases)

Y contábamos adicionalmente con la participación esporádica de Laza y Berón.Juegos de la Cuenca 2013

El contar con un plantel largo y estable de jugadores no permitió crecer en juego e ir afianzándonos como equipo. Lo cual con el correr de los partidos dió sus frutos en los resultados.

Durante esta segunda participación en la Liga de Navarro fueron ocurriendo algunas cuestiones interesantes en el ámbito local. Por un lado captamos cierta atención de la prensa local que comenzó a informar sobre nuestro desempeño en la Liga. Al mismo tiempo el Club San Miguel decidió comenzar a trabajar en un proyecto para ampliar sus instalaciones y poder sumar basket a sus actividades y como consecuencia de ello nos invitó a formar parte de una subcomisión de basket.

Finalmente nos consagramos campeones de la segunda edición de la Liga Navarrense de Basket Amateur y personalmente estoy muy contento por ello. No tanto por el título en si mismo, sino porque creo que el campeonato es consecuencia de un montón de cosas mucho más relevantes. Soy consciente de que aún nos queda mucho por mejorar como grupo y a nivel organización, pero creo que es muchísimo lo que hemos logrado de forma totalmente autorganizada y sin ningún tipo de apoyo institucional. Este campeonato marca un hito en la historia de esta iniciativa y nos deja muy bien parados anímicamente para iniciar una nueva etapa que incluirá la institucionalización de la iniciativa en el contexto del club San Miguel.

Me parece que es un buen momento para agradecer a todos aquellos que de forma directa o indirecta han colaborado con esta iniciativa y entre ellos quiero destacar a:

  • Susana Aón, quien nos abrió las puerta del Instituto San Luis Gonzaga
  • Alejandro Palomero, quien fue el mentor basquetbolistico de varios de los participantes de esta iniciativa
  • Juan Denegri y sus colegas de Navarro, por el armado de la Liga

A mi entender hemos construido un espacio abierto para la práctica del basket en Las Heras, con un grupo humano excepcional, donde predominan las relaciones por sobre los resultados, donde el todo es mucho más que la suma de las partes, donde cada uno aporta lo que puede desde donde puede, donde tenemos aciertos y equivocaciones pero siempre en pos de intentar crecer como grupo y fomentar la práctica del basket.

equipo_campeon

Coursera: curso de Android, cierre y reflexiones

El domingo terminé finalmente el curso de Android. Se estiró bastante más de las 8 semanas inicialmente anunciadas, pues 8 semanas era sólamente el tiempo de clase y más allá de eso había un trabajo final que consistía en 3 actividades: resolver dos ejercicios de programación, hacer tres evaluaciones de pares y hacer una autoevaluación.

El curso me resultó muy interesante y creo que fue muy útil como una primera aproximación a la plataforma Android. Un detalle que quiero destacar es la importancia del foros del curso, pues fueron una gran fuente de información y si bien escribí poco, leí mucho.

Ahora es momento de intentar poner en práctica lo aprendido, coding time!

Coursera: Curso de Android, Semanas #4 & #5

La cosa se puso más dura, muchos más videos y al mismo tiempo mucho más contenido, lo cual hace que sea más difícil afianzar los conocimientos. Estoy descubriendo que realmente no es una cuestión tan simple hacer aplicaciones para dispositivos móviles en la actualidad. Si bien sólo tengo una idea aproximada de lo que es desarrollar para Android, estimo que la complejidad de desarrollo en Windows Phone y iPhone ha de ser similar.

Estoy usando el emulador de  Genymotion, que supera con creces al emulador por defecto que viene con el SDK.

Estoy por comenzar con el contenido de la semana 6, que está centrado en gráficos y animaciones, temas que no me interesan demasiado pero que sin duda son relevantes sobre todo para el desarrollo de juegos.

Continuará…

Recomendaciones idiomáticas para programadores

Las recomendaciones que comparto en esta sección han surgido principalmente de mi experiencia personal como programador y como docente de programación. Decidí ponerlas por escrito cuando me dí que cuenta que las repetía una y otra vez para los distintos alumnos que pasaban por mis clases.

Aprende inglés

Nos guste o no el inglés es la lenguaje universal es esta profesión, todos los lenguajes de programación de escala industrial parten de la lengua inglesa. (he sabido de lenguajes de programación basados en otros idiomas, pero todos ellos era experimentales o bien para uso educativo).

Si bien parte de la bibliografía es traducida al castellano, las traducciones siempre tienen un tiempo de defasaje respecto de la publicación original que la mayoría de los casos es en inglés. Incluso cuando la publicación original no sea en inglés, es casi seguro que será antes traducida al inglés que al castellano.

Al mismo tiempo la evolución de las herramientas es cada vez más rápida, haciendo que los tiempos entre las distintas versiones sea cada vez más corto. Esto hace que una traducción tardía pierda sentido pues queda rápidamente desactualizada.

Es cierto que también exiten publicaciones originales en castellano, pero sinceramente son sólo un pequeño porcentaje.

Adicionalmente existe un riesgo con las traducciones que es la potencial pérdida de cierto sentido del término original o peor aún, la ambiguedad.

Más allá de la necesidad del inglés para el acceso a los recursos, exite otra cuestión: los clientes. En este contexto cada vez más globalizado no es raro que termines trabajar con un cliente que no hable castellano. Aún cuando dicho cliente no sea un pais de habla inglesa ¿en qué lenguaje crees que pretenderá comunicarse contigo? Y podemos ir aún más allá, puede que incluso parte de tu equipo este distribuido y te tengas que trabajar con un compañero que no hable castellano.

Resumiendo: debes tener cierta soltura para comunicarte en inglés. ¿cuanta soltura? Mi heurística es: debes sentirte cómodo leyendo y escribiendo y debes ser capaz de entender los díalogos de la serie IT Crowd en idioma original sin necesidad de leer los subtitulos.

Elige un idioma

Un dilema común para muchos programadores de habla no inglesa es ¿en que idioma programar? O sea, más allá del lenguaje de programación que elijas utilizar, en un punto tendrás que crear tu clases/funciones/variables y deberás decidir cómo nombrarlas.

Podrias nombrarlas en inglés para así mantener uniforme el código fuente ya que las construcciones nativas del lenguaje de programación están en inglés.

Pero si tu cliente es de habla castellana, entonces podrías decidir nombras tus clases/funciones en castellano, para así tener un mapeo más directo entre los conceptos del dominio y tu código.

A mi parecer ambos criterios son válidos y creo que la decisión mas apropiada requiere de un análisis del contexto particular de cada caso.

Más allá del análisis y la decisión que uno tome, creo que lo importante es hacer el análisis, tomar decisión y respetarla. Obviamente esta no es un decisión individual, sino que es que debe decidirse a nivel de equipo.

Utiliza el alfabeto inglés

Es común en la actualidad encontrarse con lenguajes de programación que permiten el uso de caracteres no pertenecientes al alfabeto inglés. Por ejemplo en Java es posible definir una variable “año”, una clase “Interés”. En mi experiencia esto tarde o temprano suele traer algún tipo de problema, sobre todo si los ambientes de desarrollo de cada miembro del equipo no estan totalmente estandarizado.

Utiliza software de base en inglés

Es común que cuando se produce un error en una aplicación, se muestre mensaje de error al usuario y al mismo tiempo se genere una nueva entrada en el log de la aplicación. En algunos casos esos errores se muestran en el idioma actual de la aplicación y/o del sistema operativo.

Dado que hay mucha más información en internet en inglés que en castellano, siempre recomiendo utilizar software de base en inglés, o sea, al instalar tu sistema operativo, elige inglés como idioma por defecto. Lo mismo recomiendo para los IDEs y los SDKs. De esta forma en caso de encontrarte con un error, el mismo estará en inglés y al ponerlo en el buscador encontrarás muchos más resultados que si el error estuviera en castellano.

JavaScript en OLX

Este semana estuve participando de un entrenamiento en JavaScript organizado por la gente de OLX con quien vengo trabajando desde hace casi un año.

El entrenamiento fue dictado por Kyle Simpson (@getify) y estaba titulado “Advanced JavaScript”. Cómo dijo el propio Kyle durante la apertura, un nombre mejor podría haber sido “JavaScript Foundations”, pues justamente el foco estuvo en cuestiones básicas, de “bajo nivel” en cierto punto, que en mi opinión la gran mayoría de la gente que escribe JavaScript desconoce.

El entrenamiento me pareció muy interesante, me enteré de cosas de las que no tenia ni idea. Ojo, también debo admitir que nunca le puse muchas pilas a aprender JavaScript. He escrito código y aprendido lo poco que sé a base de “prueba y error”. A pesar de esto soy consciente que cada vez es más necesario para todo programador, manejar cierto nivel de JavaScript.js_at_olx

Una cosa que confirmé en el entrenamiento es que nunca voy a llegar a un nivel avanzado en el uso de JavaScript, pues resulta que el lenguaje tiene tantas particularidades/características que llegar a dominarlas me llevaría un tiempo tal que no estoy dispuesto a invertir.

Le agradezco a David Grandes y Santiago Villa del equipo Mobile de OLX por haberme invitado.

Coursera: Curso de Android, Semana #3

Ayer completé la tercer semana, durísimo. Tuve que ver 4 videos y hacer 5 ejercicios de programación, uno de los cuales me llevó varias horas debido a que la configuración provista en el código base del ejercicio no permitía ejecutar la aplicación en un emulador.

Hasta el momento el curso ha estado enfocado en cuestiones relacionadas a la arquitectura de las aplicaciones Android. Por lo poco que ví de la semana 4, parecer tratar sobre construcción de interfaces de usuario.

Continuará…

Un defecto en producción, ¿que harías tu?

A partir de ciertos problemas de calidad en sus aplicaciones, al área de sistemas de una organización decide invertir en la adopción de ciertas prácticas. Trabaja durante un año adoptando prácticas y principios tales como integración continua, control de configuración, mejora continua, planificación adaptativa, automatización de pruebas, etc. Todo esto a la par de un cambio en el proceso de desarrollo y despliegue de las aplicaciones.

Luego de un arduo trabajo de un año todos los equipos de desarrollo de la organización han adoptado (en mayor o menor medida) la nueva forma de trabajo y las prácticas asociadas.

Un día llega un defecto crítico a producción: ¿qué es lo que debería hacerse?

  • Opción A: arreglar el defecto y ya, no importa el proceso ni las prácticas
  • Opción B: seguir el procedimiento correspondiente para este tipo de situaciones.
  • Opción C:  intentar seguir el correspondiente procedimiento pero si este retrasa/dificulta la solución del problema, intentar una solución sin apartarse de los principios que se han venido trabajando y revisando/ajustando el procedimiento una vez resuelto el problema.

¿que opinas tu?

Coursera: Curso de Android, Semana #2

Completé la segunda semana del curso: 4 videos, un par de ejercicios de programación y un cuestionario. Tuve que invertir casi 3 horas.

Me pasa que cuanto más avanzo más dudas me van surgiendo, lo cual en un contexto así lo interpreto como un buen síntoma.

Por lo que visto hasta el momento me va gustando mucho la arquitectura de Android. Aún no me cierra el emulador, tarda demasiado en levantar. Voy a investigar un poco más pues tiene que existir alguna alternativa mejor, me recomendaron usar el emulador de Genymotion, lo voy a probar y les cuento.

Continuará….

 

Javascript tests running on Jenkins

Nowadays, no matter what technology you use to build your web application, it is almost sure you will need to write some JavaScript code. At the same Javascript script code is not only used to animate the web pages, it is also used to handle validations and application flow. Because of this, everyday is more needed to write unit tests for the Javascript code.

There are several unit testing frameworks for Javascript. In my case I choose Qunit, that is testing framework developed by the jQuery guys.

Of course that in order to be able to write unit tests for your code, you will need to follow some design guidelines, but that is part of another post. Let’s suppose you followed that guidelines and now you want to write some test, these are the steps you should follow to run your tests:

  1. Download qunit.js
  2. Download qunit.css
  3. Write your tests in a javascript file
  4. Create a html page referencing the 3 previous files

With these 4 steps you are almost done, open the html file and you will have your tests executed.

What is missing, is how to run these tests in the build server. The interesting point here is that to run Javascript t tests we need a Javascript engine. In a develop machine, it is not a problem, you can use your browser, but in the build server is not so easy. The approach I took was to use PhantomJS, a tool that among other things, can run Javascript without needing a browser.

So using PhantomJS and MSbuild I was able to have my Jenkins running my Javascript tests.

Here you can download a running example.