Organizando conceptos con mapas mentales

Un mapa mental es un esquema sin una estructura fija que nos permite ayudar a fijar conceptos, hallar relaciones entre ellos y formar una representación gráfica de los mismos. En este artículo veremos para qué podemos usar esta herramienta, cómo empezar desde cero y qué opciones, tanto analógicas como digitales tenemos a nuestra disposición.

Para qué usar mapas mentales

Se pueden usar para prácticamente cualquier cosa que implique relaciones entre conceptos, en mi caso, los he usado para:

  • Analizar información y conceptos nuevos, ya sea de temas que esté leyendo, cursos, presentaciones, etc.
  • Dar forma a cualquier tipo de presentación, documento, artículo o libro, para poder ver todos los puntos a tratar antes de ir más a fondo.
  • Organizar ideas aleatorias que no tienen forma ni sentido en un principio.
  • Analizar problemas. Esta última me ha sido de gran utilidad en el trabajo, te permite poder ver posibles orígenes de problemas y tener una idea un poco más amplia de lo que está pasando.

Cómo empezamos?

La manera más sencilla de comenzar a hacer mapas mentales es usando papel y lápiz, aunque el mundo nos mueva en la dirección de tomar notas con nuestros iPhones, iPads, tablets y ordenadores. Un estudio afirma que tomar notas de nuestro puño y letra es más provechoso cognitivamente, además de que al escribir “en sucio” podemos ser más creativos.

Con nuestro papel y lapiz en la mano, fijamos la idea principal en el centro de la hoja, y empezamos a escribir/dibujar conceptos e ideas alrededor:

unspecified
El mapa mental de este artículo sobre mapas mentales

Para ello podemos utilizar cualquier cuaderno o libreta (como se ve anteriormente), aunque personalmente recomiendo un modelo fabricado por la empresa portuguesa InfiniteBook, que nos permite borrar y reescribir utilizando bolígrafos de pizarra. Está disponible en tamaños (A4 y A5) y se puede adquirir a través de Amazon o bien desde su web oficial infinitebook.pt

51X5jrqZKkL._SL1024_
Cuaderno InfiniteBook

Si tenemos además la suerte de tener acceso a una pizarra también podemos hacer uso de ella, especialmente si estamos haciendo una sesión de trabajo en equipo.

Pasando nuestros apuntes “a limpio”

Una vez tenemos nuestro mapa mental el papel, con algún que otro tachón de por medio, posiblemente queremos tener una versión en limpio de los mismos, y conservarlo en nuestro mundo digital.

Aunque siempre tenemos la opción de hacer una foto al papel o a la pizarra con nuestro móvil, existen herramientas específicas que nos permiten crear una versión digital de los mapas y poder editarlos, compartirlos o conservarlos indefinidamente.

Una de estas herramientas es XMind, cuya versión gratuita nos permite crear un mapa mental digital. Posee algunos atajos de teclado muy básicos como usar Tab para crear un nuevo elemento “hijo” o Enter para crear un nuevo elemento al mismo nivel, y esto nos permite replicar lo que hemos hecho en papel de una manera rápida y efectiva:

Captura de pantalla 2016-08-18 a las 8.06.07.png
La misma versión del Mapa mental anterior, en digital

Una alternativa que también usé en mis años de carrera, especialmente para Windows y Linux, es FreeMind, que posee una interfaz y funcionamiento similar, con la principal diferencia de ser Software Libre (GPL v2).

El mundo de las herramientas de mapas mentales es aún mayor, si usas otra herramienta diferente de las mencionadas, puedes comentar tu experiencia en los comentarios.

Como nota importante, todas las herramientas de mind mapping que he visto permiten la opción de exportar e imprimir nuestro mapa, con lo cual si queremos, podemos cerrar el ciclo del mundo “analógico” teniendo una copia impresa de nuestro mapa mental sobre la que tomar aún más notas.

Mind mapping en dispositivos móviles

Pese a que existen herramientas para crear y gestionar los mapas mentales desde el móvil, personalmente prefiero usar mi dispositivo de bolsillo para capturar ideas y no tanto para crear los mapas. Si usas alguna herramienta en tu móvil o tablet, comenta tu experiencia en los comentarios.

Sketchnoting

Sketchnoting es otra técnica relacionada para la captura de información, con la que utilizamos iconos y dibujos para reducir los conceptos que estamos aprendiendo a su mínima expresión. Aunque no es necesario ser un artista para utilizar sketchnoting, dibujar nos puede ayudar a fijar ideas, aunque luego pasar esos dibujos a formato digital puede resultar un poco más trabajoso.

En cualquier caso, un buen manual al que acudir es “The SketchNote Handbook” (en Amazon) que, mediante esa misma técnica nos explica algunos conceptos y nos ayuda a crear nuestras propias notas.

#En resumen

Los mapas mentales nos ayudan a organizar nuestras ideas alrededor de conceptos nuevos o conocidos. Podemos usar papel, pizarra u ordenador para crearlos y mantenerlos, podemos imprimirlos, compartirlos y llevarlos encima en todo momento, y podemos utilizar técnicas como Sketchnoting para capturar la información de manera gráfica.

Descubriendo CloudFormation

Desde hace algunas semanas he estado usando, como parte de mi trabajo diario, una de las opciones de Amazon Web Services que nos permite crear plantillas para automatizar la creación de recursos llamada CloudFormation.

En este artículo, tras revisar las las diferentes opciones que tenemos para crear recursos, describiremos algunas características de CloudFormation, y finalmente veremos mi propia experiencia al usar esta herramienta.

Creando recursos en AWS

Crear recursos en la nube, tales como máquinas, blobs para almacenamiento, colas para intercambio de mensajes, bases de datos, o incluso alarmas para medir el rendimiento, es algo que podemos hacer mediante tres maneras:

Mediante la interfaz de usuario

La interfaz nos ayuda a explorar la plataforma, conocer lo que nos ofrece, y suele tener además guías, recomendaciones y enlaces a documentación. Es un buen punto de entrada, pero propenso a error ya que no es sencillo de automatizar.

Usando las herramientas de línea de comandos

Prácticamente todas las acciones que se pueden hacer por la interfaz, se pueden hacer por la línea de comandos (Por ejemplo, aún no podemos crear dashboards de CloudWatch). Por una parte, tendremos que aprender la sintaxis, y el funcionamiento será menos intuitivo que usar el portal, pero por otra parte trabajar con la línea de comandos nos permite cierto grado de automatización.

A través del SDK

Esta opción viene a ser un complemento de la segunda, pero en vez de utilizar un lenguaje de consola de comandos como Bash para nuestra automatización, podemos usar lenguajes como C#, Python o Java para crear nuestros scripts.

Usando plantillas

Esta opción nos permite, mediante un fichero JSON, definir nuestros recursos, valores por defecto, relaciones entre ellos y parámetros que podremos rellenar cuando estemos aplicando la plantilla. Veamos un ejemplo:

{
  "AWSTemplateFormatVersion" : "2010-09-09",
  "Resources" : {
    "myDynamoDBTable" : {
      "Type" : "AWS::DynamoDB::Table",
      "Properties" : {
        "AttributeDefinitions" : [
          {
            "AttributeName" : "Album",
            "AttributeType" : "S"
          },
          {
            "AttributeName" : "Artist",
            "AttributeType" : "S"
          }
        ],
        "KeySchema" : [
          {
            "AttributeName" : "Album",
            "KeyType" : "HASH"
          },
          {
            "AttributeName" : "Artist",
            "KeyType" : "RANGE"
          }
        ],
        "ProvisionedThroughput" : {
          "ReadCapacityUnits" : "5",
          "WriteCapacityUnits" : "5"
        },
        "TableName" : "myTableName"
      }
    }
  }
}

CloudFormation es el sistema que nos permite crear y utilizar estas plantillas, y es el que establece la sintaxis que acabamos de ver para definir nuestros recursos y los diferentes atributos, veamos algunas de sus características y ventajas.

Características

Parámetros

Los parámetros nos permiten personalizar nuestra plantilla en tiempo de creación y pueden ser muy útiles para aplica el mismo recurso en diferentes regiones, o tener la misma plantilla para varios grupos de recursos, utilizando los siguientes tipos de datos:

  • Texto
  • Número
  • Números separados por comas
  • Textos separados por comas

Podemos ver un ejemplo del uso de parámetros en el siguiente bloque, donde, además, podemos utilizar la propiedad AllowedValues para mostrar un desplegable con las diferentes opciones disponibles, o bien dejar un campo de texto libre:

"Parameters" : {
  "InstanceTypeParameter" : {
    "Type" : "String",
    "Default" : "t1.micro",
    "AllowedValues" : ["t1.micro", "m1.small", "m1.large"],
    "Description" : "Enter t1.micro, m1.small, or m1.large. Default is t1.micro."
  }
}

Salida

Otra de las características que podemos utilizar de CloudFormation, es la definición de la salida, que nos permite obtener cualquier valor de los recursos que acabamos de crear, ya sean IDs de instancias de EC2, nombres DNS de recrusos, URLs de tablas en DynamoDB o ARN de colas SQS. Esto es especialmente útil si estamos aplicando nuestro script utilizando la línea de comandos de AWS.

"Outputs" : {
  "BackupLoadBalancerDNSName" : {
    "Description": "The DNSName of the backup load balancer",
    "Value" : { "Fn::GetAtt" : [ "BackupLoadBalancer", "DNSName" ]},
    "Condition" : "CreateProdResources"
  },
  "InstanceID" : {
    "Description": "The Instance ID",
    "Value" : { "Ref" : "EC2Instance" }
  }
}

Referencias

Podemos enlazar recursos en tiempo de creación, es decir, podemos crear una cola SQS, y a su vez una segunda cola para que guarde los mensajes tras varios intentos (lo que se denomina Dead Letter Queue), o podemos crear una tabla y una alarma de CloudWatch asociada a la misma, utilizando referencias internas.

En este ejemplo podemos ver una dirección IP que asociamos a una instancia que hemos definido anteriormente:

"MyEIP" : {
   "Type" : "AWS::EC2::EIP",
   "Properties" : {
      "InstanceId" : { "Ref" : "MyEC2Instance" }
   }
}

Ventajas

La primera ventaja es que es una manera limpia de crear y administrar recursos en AWS, los recursos creados como parte de una plantilla se pueden modificar directamente subiendo una nueva versión de la misma, o bien se pueden borrar, evitando tener que hacer estas acciones por separado.

En segundo lugar, nos facilita replicar nuestra infraestructura en diferentes regiones, ya que AWS mantiene una separación muy estricta entre las regiones (de hecho, no todas las regiones cuentan con todos los recursos, y los precios varían por región).

En tercer lugar, nos aporta control de cambios, ya que por una parte tenemos un fichero de texto que podemos agregar a nuestro sistema de control de versiones, y por otra parte, al aplicar las plantillas, mantenemos un histórico de cambios, donde se aprecian qué recursos se han creado, modificado y eliminado cuando actualizamos nuestras plantillas.

Finalmente, es gratis! AWS no hace ningún cargo por el uso de CloudFormation, solamente pagaremos por los recursos que creamos con el mismo, que sería lo mismo que si los creáramos por separado.

Mi experiencia personal

Personalmente he utilizado CloudFormation para crear plantillas a partir de recursos ya existentes entre diferentes zonas de AWS, creando ficheros (denominados “Stacks”) para tablas DynamoDB, colas SQS y sistemas de notificaciones SNS, así como alarmas de CloudWatch.

Además de los parámetros que hemos visto antes, he necesitado personalizar los stacks que he creado, y para ello, utilizando la función Join para combinar valores por defecto y parámetros:

"Fn::Join" : [ ":", [ "a", "b", "c" ] ] //a:b:c

He experimentado bastante libertad a la hora de enlazar recursos y personalizar los valores, y el hecho de que muchos de los valores sean opcionales me ha permitido centrarme en las características específicas de mi Stack, y no tener que aprender todas las opciones antes de empezar a trabajar, lo cual es de agradecer.

Una cosa que sí hecho en falta de CloudFormation es la posibilidad de crear plantillas automáticamente especificando un recurso, esto nos permitiría convertir tablas, colas, o instancias EC2 en plantillas que podríamos luego replicar en otras zonas.

Resumen

CloudFormation nos permite, utilizando parámetros, crear una serie de ficheros JSON llamados templates, que podemos aplicar desde la UI o la línea de comandos para crear, modificar o eliminar recursos como colas SNS, tablas, máquinas EC2 o alarmas CloudWatch, sin tener que pagar un sobrecoste por esta característica.

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

DotNetSpain Conference 2015, yo estuve allí!

El pasado viernes y sábado 27 y 28 de febrero tuve la suerte de asistir, de ponente y de espectador, al evento DotNetSpain Conference 2015, un evento centrado fundamentalmente en .NET, sus lenguajes (en especial C# y F#), sus herramientas, y sobre todo su ecosistema, que cubre desde aplicaciones para dispositivos IoT hasta aplicaciones en la nube, tanto en hosts Linux como Windows, pasando por Windows Phone, iPhone y Android a través de Xamarin.

Como asistente, he disfrutado muchísimo de todas las sesiones a las que he asistido. En algunas he descubierto muchas malas prácticas que, para mi sorpresa, empleo diariamente, en esta sesión titulada Code Smells de Ferando Escolar (@fernandoescolar). Una sesión muy extensa de la cual pude sacar algunas notas:

image

image

Fernando ha publicado las slides en slideshare, así que las enlazo desde aquí también: Slides

Además, de la mano de Alex Casquete (@acasquete) pude comprobar cómo la programación funcional te permite hacer código más simple, más legible y con menor posibilidad de fallos. Además tuve la ocasión de tomar algunas notas:
image

image

Escoger entre las más de 45 sesiones y otros tantos talleres prácticos en solo dos días era difícil. Así, pude ver además temas relacionados con escalabilidad en la nube, gadgets variados en sesiones relacionadas con IoT, o algunos tips & tricks sobre C# que ignoramos. Ha sido muy interesante y traigo mucho que estudiar de vuelta.

Además de las charlas hubo tiempo para networking, ya que pude ver representación de las comunidades técnicas de toda España, así como muchos estudiantes llenos de inquietudes y de ganas de aprender miembros del programa Microsoft Student Partners, al que tuve el orgullo de pertenecer mientras fui estudiante. Algunos de estos estudiantes participaron, además, como ponentes en sesiones y talleres.

Este evento ha sido muy especial para mí, ya que he tenido la enorme oportunidad de participar como ponente en dos charlas bastante diferenciadas:

Una visión multiplataforma con ASP.net vNext

B-3c5x0W8AEoSu4

Por una parte pude compartir escenario con el gran Eduard Tomás (@eiximenis) en una sesión en la que estuvimos hablando de cervezas y de las novedades de ASP.net vNext para entornos multiplataforma. Vimos, además de las novedades que trae Visual Studio para el soporte de Grunt y Bower, que desplegar una aplicación compilada en Mac OSX, utilizando Sublime como editor y el proyecto Omnisharp para aportar Intellisense, en un contenedor Docker (en linux) ya es posible con unas pocas líneas.

Slides y ejemplos

Los ejemplos del apartado de MacOSX, que incluyen además los ficheros de configuración de Docker para desplegar, están disponible en GitHub

Vídeo

Esta sesión fue grabada por GlobbTV, y está disponible en su web: http://www.globbtv.com/12/microsite/4762/dotnetspain2015–una-vision-multiplataforma-con-aspnet-vnext

Extendiendo Visual Studio Online a través de su API

B-3lOhkW0AACJsQ

En mi segunda sesión, justo después, estuve mostrando utilizando algunos ejemplos, cómo mediante las APIs de Visual Studio Online podemos leer de nuestro proyecto, escribir y actualizar información, ejecutar operaciones como la solicitud de builds, y además, interactuar de manera pasiva mediante el uso de service hooks, para responder a eventos ya creados.

Slides y ejemplos

Los ejemplos utilizados se encuentran disponibles en GitHub

Conclusiones

Este evento ha sido una gran oportunidad para reconectar con muchos compañeros de profesión, para ponerme al día con diversos temas y además para poder compartir algo de lo aprendido en mis sesiones. Desde aquí muchas gracias a todos los asistentes, a la organización por hacer posible el evento y al resto de los ponentes por compartir con nosotros su experiencia.