Archivo de la categoría: Historias

Testing with Hamcrest

When I build software one of the things that I need to consider is how to test what I’ve built. Testing gives me a safety net to add new features and to refactor existing code without breaking functionality. For having the basics covered, I use unit tests, and with frameworks such as JUnit we can get easily used to code like this:

assertEquals(expected, actual, message)

When using this code, semantics don’t help, and the question is always the same: what is the expectation, and what is the actual? I tend to swap them, and sometimes I see the test fail with wrong messages. These messages can misguide us or the developer who needs to do some maintenance work.

One of the approaches that we can use for fixing this issue is by using Hamcrest, a JUnit extension that provides a different way of reading our tests. Let’s replace the previous code with:

assertThat(actual, is(expected)) 

With this way of writing, we are stating the assertion, asssertThat whatever object or property we want to validate has an expected value.

The method is, is named a “matcher”, a specific snippet that allow us to build a readable assertion, such as the following ones.

assertThat(result.message, is(equalToIgnoringCase("EXPECTED")));
assertThat(result.message, allOf(containsString("aa"), containsString("bb")));
assertThat(result, hasItem(expected));

As we can see in the previous examples, we have equality modifers, we are able to group different assertions into one and we even have support for Collections.

With this way, we can have more expressive tests and less error prone. This is not something “new”, in fact, it was added to JUnit 4.4 (check out the original release notes) but it’s a different way of writing our tests in Java.

Which syntax do you use for your tests?

Libro: The Clean Coder

downloadEsta semana he terminado de leer “The Clean Coder”, de Robert (Uncle Bob) Martin, un libro que la crítica considera la la continuación del célebre “Clean Code” del mismo autor, pese a que está más enfocado a corregir ciertas actitudes a la hora de programar, de relacionarnos con compañeros, aceptar responsabilidades, etc, dentro de la imagen del programador profesional.

A lo largo de poco más de 200 páginas el libro nos explica detalladamente conceptos técnicos como TDD, que nos ayuda a generar un conjunto de pruebas antes de comenzar a escribir una línea de código, la importancia de Pair Programming como medio de estar centrados en la solución del problema y de transmitir conocimientos, la necesidad de tener un sistema de integración continua que haga que los test se ejecuten de manera regular y la necesidad de que estos tests sean rápidos para poder ejecutarlos una y mil veces, entre otras cosas.

Por otra parte, y más relacionado con habilidades interpersonales, nos cuenta la importancia de saber decir NO a cualquier petición por urgente que parezca, y valorar si realmente podemos hacerlo, lo que nos lleva a saber decir , y hacernos responsables de las promesas que hacemos a nuestros clientes, managers y compañeros.

Siguiendo esta línea, el libro nos explica cómo los programadores solemos interpretar las estimaciones que hacemos como meras aproximaciones, y nuestros clientes o managers las suelen interpretar como deadlines, y explica varias técnicas para poder dar estimaciones más fiables como puede ser el análisis PERT, en el cual asignas caso mejor, caso más probable y caso peor a cualquier tarea.

Relacionado con la estimación, nos habla de la necesidad de conocer el negocio en el que nos encontramos para poder dar una mejor valoración a las prioridades que vienen “de arriba” usando algunas anécdotas.

Finalmente nos habla de la importancia de practicar, de aprender, de mantener nuestras herramientas al día, de buscar mentores, ya sea de la manera clásica (alguien que dedique activamente su tiempo a ayudarnos) o de maneras menos convencionales (un libro, una conferencia, algo que nos motive a seguir adelante aunque los autores no lo sepan).

En definitiva, una lectura recomendable, sobre todo al empezar un nuevo proyecto profesional, nos ayudarán a identificar puntos a mejorar de nuestros equipos, y nos ayudaran a ser mejores profesionales.

En Amazon: The Clean Coder: A Code of Conduct for Professional Programmers

Manteniendo nuestros eBooks sincronizados entre diferentes dispositivos.

Cuando nos movemos del modelo de libros físicos al modelo de libros digitales, ganamos una enorme conveniencia, y es que nuestros libros de repente se vuelven accesibles allá donde vayamos, en nuestro lector de eBooks, en nuestro móvil, en nuestra tablet, e incluso en cualquier ordenador vía el navegador, guardando el estado de la lectura.

A mí personalmente me encanta cómo funciona el ecosistema de Kindle, ya que tienes por una parte el dispositivo y por otra parte una suite de aplicaciones para iOS, Android, Windows y un lector web que mantienen todo conectado.

Sin embargo, a pesar de que el catálogo de Amazon es bastante grande, no es la única fuente para comprar ebooks, y a veces nos encontramos con otras fuentes, que incluso a veces ofrecen libros de manera gratuita, como por ejemplo:

  • O’Reilly y sus ofertas diarias
  • Manning, que nos regala el ebook cuando compramos el libro en papel.
  • Pragmatic Programmers, con ofertas recurrentes.
  • Microsoft Press, con libros gratuitos.

Amazon no ofrece ninguna manera de poder ampliar nuestra biblioteca, aunque sí que nos permite enviar libros a dispositivos y aplicaciones concretas, pero sin la capacidad de sincronización entre ellos.

Buscando una solución a esto me topé con Google Play Books, que para aquellos que tengan Android es la aplicación por defecto para abrir libros en formato ePub, también tiene aplicaciones para iPhone, y además es una web donde podemos continuar leyendo nuestros libros.

Una de las ventajas que descubrí de Google Play Books es la posibilidad de subir nuestros propios libros, hasta 1000, con lo cual (siempre que no estén protegidos por DRM) podemos tenerlos accesibles desde cualquier parte manteniendo nuestro estado guardado.

Como decía en mi artículo al principio del año, uno de mis objetivos es leer más, y de momento este pequeño descubrimiento me está ayudando bastante.

Enlace: Google Play Books

Y llegó 2016

Ya con esta son seis ediciones del resumen anual de mi blog, o lo que es lo mismo, más de 2000 días desde mi primer artículo, y es que 2015 ha sido un año muy interesante para mí, aunque he de reconocer que he escrito menos, mucho menos, de lo que pensaba en un primer momento.

Comencé el año volviendo a mi universidad a hablar de tres Tecnologías Microsoft que no se dan en la carrera, comprobando cómo, años después de mi paso por las aulas, el DotNetClub sigue vivo y dando caña. Enhorabuena a Arcadio (actual Presidente de la asociación) por ese trabajo.

En febrero publiqué The Time Box, mi primera aplicación para Android, y pude dar un vistazo a esa plataforma, tener mi primera aplicación en Google Play y ver todo el ciclo de desarrollo de una aplicación móvil.

En marzo tuve la oportunidad de formar parte de la primera gran conferencia de .NET a nivel nacional, en la que tuve el honor de presentar dos sesiones, una de ellas acompañado por el ilustre Eduard Tomás en la que hablamos de ASP.net vNext, y las novedades que traía.

Entre febrero y abril, Juan Quijano y yo un par de hangouts en los que tratamos temas como Xamarin o programación funcional desde la perspectiva del mundo real, y de cómo profesionales usan estas herramientas y lenguajes en su día a día.

Mayo fue mes de cambios, y de despedidas, ya que cerré un ciclo profesional en Frontiers, una empresa de publicaciones suiza en la que participé en la creación de Loop, su red social.

Alrededor de la misma fecha, y a pesar de que no le hice la publicidad que se merecía en el blog, publiqué mi primer curso de CampusMVP, que ahora forma parte de la oferta del Master Online de desarrollo de Aplicaciones Front-End.

Durante el resto del año estuve un poco alejado del blog, ya que apenas tuve tiempo, pero eso no me impidió publicar un monográfico de Scala, que me gustaría retomar este año, o publicar mi experiencia en el lambda world de Cádiz.

Como último artículo del año, me calcé las zapatillas otra vez y comenté mi experiencia corriendo la carrera “Ponle Freno” un año después de mi primera incursión en el mundo del “Running”

El año pasado además, dejé lista una lista de objetivos que quería cumplir este año:

  • Aprender un nuevo lenguaje de programación o framework, y hacer un proyecto en él: En este caso he aprendido algo de programación para Android y Scala, así que lo podemos dar por conseguido.

  • Hacer más vídeos en inglés y en castellano: La parte de castellano está conseguida con el curso de CampusMVP, la parte en inglés no tanto. digamos que cumplido al 50%

  • Montar más hangouts: 3 en 2014 contra 2 en 2015, está claro que este año no ha podido ser.

  • Hacer más proyectos personales: 2015 terminó con un par de ideas, mi primera aplicación Android y un pequeño clon de Trello, creo que lo podemos dar por conseguido.

  • Cerrar un ciclo de certificaciones Microsoft: Este año no ha podido ser.

  • Cursar y aprobar otro MOOC: Muy en la línea de las certificaciones Microsoft, tampoco ha podido ser.

  • Trabajar más en mi segundo o tercer idioma: A fecha de hoy trabajo en inglés al 100%, así que mi nivel de inglés y mi vocabulario han mejorado, pero el tercer idioma sigue siendo una incógnita.

  • Seguir escribiendo: Pese a que he escrito menos, he escrito, y espero seguir el año que viene.

Así, pongo la vista en 2016 con la siguiente lista de tareas, que seguramente sufrirá modificaciones a lo largo del año, pero esto es lo que quiero hacer a fecha de hoy:

  • Enviar al menos 3 papers a conferencias técnicas.

  • Leer más literatura técnica, mínimo 10 libros.

  • Hacer más proyectos personales, mínimo 3.

  • Escribir más artículos técnicos, mínimo 20.

  • Hacer un nuevo MOOC de Coursera/edX, etc.

  • Conseguir al menos una certificación de tecnología, ya sea Microsoft, Java, etc.

  • Aprender al menos un lenguaje, tecnología, plataforma o paradigma que me saque de mi zona de comfort.

Y a todo eso, sumar conseguir correr la San Silvestre Vallecana en menos de 1h.

Gracias por leer este blog. Espero que tengas un próspero y 2016 cargado de cosas interesantes.

OT: Corriendo voy… un año después

El año pasado por estas fechas comentaba mi primera experiencia en una carrera popular, y toda la tecnología que había visto en su momento.

He de reconocer que fue agónico, tuve que parar varias veces y el resultado implicó una semana de agujetas, aunque fue suficiente para que me picara la curiosidad, empezara a correr de manera más regular y a participar en alguna que otra carrera más:

  • Rexona Street Run (5K) en la que descubrí lo divertido que es participar en una carrera resfriado, altamente recomendable. Me paré un par de veces pero logré terminarla corriendo.

  • Rock n’Roll (10K), que llegué justo y no pude dejar la mochila en el guardarropa, con lo cual me tocó correr con la bolsa, una faena, pero logré terminarla sin parar.

  • Carrera Popular Alcobendas (10K) ya en primavera, pude comprobar que el calor no perdona, y los desniveles de Alcobendas son algo intimidantes. Me tocó pararme varias veces y casi no lo consigo.

  • Proniño (10K) la última carrera que corrí en verano, todo fue perfecto, un tiempo maravilloso, un terreno plano prácticamente sin cambios de nivel, logré terminarla sin parar logrando mi mejor tiempo en 10K hasta ahora.

  • Ponle Freno (5K) he repetido este año aunque en la modalidad 5K, con la suerte de que todo ha salido bien, desde el transporte hasta el guardarropa, y he conseguido mi mejor tiempo.

Con cada carrera, he ido aprendiendo muchísimo sobre ritmos, tiempos, estiramientos, qué llevar, qué no llevar, etc, y de momento mi stack tecnológico de runner consiste en lo siguiente:

  • Fitbit Charge HR: Además de contar pasos, Detecta cuando empiezo (y termino) una actividad como correr, registrando distancia y ritmo cardiaco, lo que me permite analizar mejor los resultados tras la carrera.

  • Pebble Time: Además de poder personalizar la hora y poder leer los mensajes de Whatsapp mientras corres, permite la conexión con Endomondo, resultando muy útil para tener datos como el ritmo actual directamente en la muñeca.

  • Auriculares Bluetooth MPow Cheetah: En su momento me costaron poco más de 20€, y son extremadamente buenos para el precio que tienen, se oyen bien, resultan cómodos, aíslan del ruido y evitan los molestos cables, sin sacrificar batería. disponible en Amazon

  • iPhone 6: Hace un año tenía un iPhone 5 que luego descubrí que formaba parte de la partida con problemas de batería, tras una temporada en el mundo Android he vuelto a iOS, y la batería del 6 me permite correr sin tener que depender de baterías extra.

  • Endomondo: Mi app de referencia para todo lo relacionado con deporte, me ayuda a correr, mide las distancias y me va indicando ritmo y kilómetros por los auriculares mientras corro.

  • Spotify He de reconocer que envidio a aquellos que son capaces de correr sin música, pero yo aún no he llegado a ese nivel, ni sé si seré capaz, de momento spotify (y su opción running) me ayudan a concentrarme, aunque para la carrera opté por una lista de reproducción, ya que spotify running requiere internet y no quería depender del estado de la red mientras corría.

Dar con el equipamiento definitivo es una cuestión de prueba y error, aunque de momento creo que el que tengo me vale, lo siguiente es encontrar unas buenas zapatillas, y creo que para eso le preguntaré a los chicos de runnics.

Nos vemos en la línea de meta!

Mi paso por Frontiers, retrospectiva

Después de casi 10 meses de trabajo y con la vista puesta en un nuevo reto profesional, me despedí de la familia Frontiers como SCRUM recomienda, en una sesión de retrospectiva el pasado 7 de mayo. En este artículo me gustaría comentarte, a modo de resumen, mi experiencia como miembro de este equipo.

¿Qué es Frontiers?

Cuando ví la oferta empecé a investigar, y pude ver que era una empresa suiza, con sede en Laussane, que llevaba desde 2007 y que se dedicaba a la publicación de artículos científicos. La idea de trabajar “para la ciencia” me llamó la atención y decidí intentarlo.

Luego descubriría que la idea no era solamente publicar artículos, sino crear una red social alrededor de los mismos para poner en contacto a investigadores y científicos, en lo que se llamó Loop, y que fue el proyecto en el que estuve involucrado desde que pisé las oficinas.

¿En qué se desarrolla?

Para la red social nos apoyamos en tecnologías Microsoft, contando con un stack que iba desde SQL Server para la base de datos hasta ASP.net MVC y Web API para el frontal, utilizando C# como lenguaje de desarrollo.

Teníamos además cosas chulas como Rabbit MQ para comunicar diferentes sistemas y de lado del navegador, Knockout como framework JavaScript, y QUnit para pruebas unitarias.

Todo esto se coordinaba con diferentes sistemas de integración contínua en los que automatizabamos el despliegue en diferentes entornos de integración y las pruebas. Todo esto, a su tiempo, se iba integrando hasta llegar al ansiado entorno de producción. Esta parte, he de reconocer, que me resultaba particularmente interesante :)

¿Cómo funciona?

Utilizábamos SCRUM como metodología de desarrollo, y sus diferentes “ceremonias”, una reunión de planificación antes de cada iteración, demo para mostrar los avances realizados, retrospectivas, y la sesión diaria donde veíamos los avances, y qué nos impedía seguir adelante.

Los equipos estaban formados, además de por los desarrolladores, por una persona de negocio, un QA y un SCRUM master que velaba porque todo estubiera bajo control.

Sin embargo en Frontiers había algo que no contemplaba SCRUM, y eran las comunidades. Una comunidad era un grupo formado por miembros de cada equipo, en los que se tomaban decisiones técnicas que afectaran a todos, para lograr también una sincronización a nivel técnico.

¿Cómo es el día a día?

A excepción de los días en los que teníamos planificación o demo, en los que una buena parte del día se nos iba en reuniones, nos dedicábamos diariamente a escribir código para arreglar bugs o crear características nuevas, mover postits (tareas) a diferentes estados en un panel que teníamos en la oficina o diseñar arquitecturas escribiendo en las paredes, ya que estaban recubiertas por una pintura especial que lo hacía posible.

Todo esto en jornadas que transcurrían entre las 8 de la mañana y las 5 de la tarde, donde la energía la proporcionaba el café proveniente de una máquina Nespresso que nos daba el oscuro brebaje sin coste.

Tras de la jornada laboral, los había que se quedaban para jugar al fútbol en unos campos que había cerca de la zona, otros coordinaban el huerto que teníamos, otros participábamos en carreras populares, los había que esquiaban, en general se promovía un estilo de vida bastante saludable, cervezas mediante una vez al mes :)

Agradecimientos

Mi experiencia en Frontiers no habría sido la misma sin mis compañeros del equipo MadOne, Ángel, nuestro Scrum Master, Iván, Carlos, María, Quique, Axel, que nos dejó para ver mundo, Cristina, nuestra QA, Charlie, Ramón, nuestro Product Owner y Adrián, nuestro Lead Designer, con los que, codo con codo, nos enfrentábamos a bugs, tareas nuevas y adversidades varias.

Además, Paola y Giovanni de Recursos Humanos, siempre estuvieron pendientes del equipo durante mi estancia y de que estuviera cómodo desde la fase de entrevistas hasta el momento de mi salida de la empresa.

Otra mención a los runners, en especial a Felipe, por algunos tips & tricks para poder lograr correr mi primera 10k (por cortesía de la empresa, por cierto!).

Finalmente un agradecimiento a Victor Mendez y Tobías Abarbanel, los responsables técnicos de la compañía y de los cuales he aprendido muchísimo estos meses. Gracias por la oportunidad de haber formado parte de esta familia, me lo pasé en grande.

Por cierto, Frontiers sigue buscando gente.

Friday fun: A++, ++A o A+=1? Esa es la cuestión…

Cuando empezamos a programar, una de las cosas que suelen quedar bastante claras (o no) es la diferencia entre i++, ++i e i+=1, mientras que la primera lee y luego asigna, la segunda asigna y luego lee, y la tercera lee y asigna. Personalmente no estaba del todo convencido, así que decidí verlo por mí mismo utilizando el compilador de C#, y comprobar cual era el código IL generado. Las funciones utilizadas son muy simples, y el código se ha compilado en modo debug.

¿Por qué el modo debug? Porque el modo release hace una serie de optimizaciones que dan como resultado exactamente el mismo código IL para un comportamiento sencillo. Veamos la primera función, con su respectivo código IL:

void APlusPlus(int A) 
{
    int B = A++;
}

El código IL es el siguiente:

.method private hidebysig instance void  APlusPlus(int32 A) cil managed
{
  // Code size       9 (0x9)
  .maxstack  3
  .locals init ([0] int32 B)
  IL_0000:  nop
  IL_0001:  ldarg.1
  IL_0002:  dup
  IL_0003:  ldc.i4.1
  IL_0004:  add
  IL_0005:  starg.s    A
  IL_0007:  stloc.0
  IL_0008:  ret
} // end of method Sample::APlusPlus

En este caso el funcionamiento es el siguiente:

  • Se carga el valor de A en la pila
  • Se duplica el valor de A.
  • Se suma 1 al valor de A
  • Se almacena el nuevo valor de A.
  • Se almacena el antiguo valor de A en B (A = B + 1).

Veamos el segundo candidato, en este caso la suma se realiza antes de la lectura.

void PlusPlusA(int A) 
{
    int B = ++A;
}

El código IL se muestra a continuación:

.method private hidebysig instance void  PlusPlusA(int32 A) cil managed
{
  // Code size       9 (0x9)
  .maxstack  2
  .locals init ([0] int32 B)
  IL_0000:  nop
  IL_0001:  ldarg.1
  IL_0002:  ldc.i4.1
  IL_0003:  add
  IL_0004:  dup
  IL_0005:  starg.s    A
  IL_0007:  stloc.0
  IL_0008:  ret
} // end of method Sample::PlusPlusA

En este caso el funcionamiento es el siguiente:

  • Se carga el valor de A en la pila
  • Se suma 1 al valor de A
  • Se duplica el valor del elemento almacenado en la pila.
  • Se almacena el nuevo valor en A.
  • Se almacena el nuevo valor en B (A = B).

Finalmente, veremos qué pasa con la construcción A+=1;

void APlusOne(int A)
{
    int B = A += 1;
}

El código IL es el siguiente:

.method private hidebysig instance void  APlusOne(int32 A) cil managed
{
  // Code size       9 (0x9)
  .maxstack  2
  .locals init ([0] int32 B)
  IL_0000:  nop
  IL_0001:  ldarg.1
  IL_0002:  ldc.i4.1
  IL_0003:  add
  IL_0004:  dup
  IL_0005:  starg.s    A
  IL_0007:  stloc.0
  IL_0008:  ret
} // end of method Sample::APlusOne

Si comparamos con el código anterior veremos que el resultado es exactamente igual, sin ningún cambio.

Conclusiones

Estas pequeñas pruebas nos permiten ver cómo funciona internamente el código IL, así como comprobar cómo se manipulan los objetos en operaciones sencillas. Si ejecutamos estas mismas operaciones en modo release cambia por completo, ya que el compilador elimina código no utilizado, así como valores nop que se insertan para facilitar la depuración.

Más info de ildasm en MSDN