Archivo de la categoría: Historias

En Pamplona Software Craftsmanship 2017

Este fin de semana he tenido la oportunidad de participar en un evento diferente orientado a profesionales de la industria del software en la ciudad de Pamplona, en Navarra, en el que se combinaban dos aproximaciones:

  • Por una parte, una conferencia tradicional, en la que los ponentes y las sesiones se conocen de antemano.
  • Por otra, un open space, en el que las sesiones se proponen, presentan y votan por parte de los asistentes.

Durante dos días, más de una centena de desarrolladores, ingenieros de software, programadores, agilitas, craftsmen, o profesionales de la industria, independientemente de la etiqueta que tengamos en nuestro lugar de trabajo o en nuestro CV, hemos debatido sobre la profesión, lo que nos motiva a hacer lo que hacemos, los problemas a los que nos enfrentamos y las soluciones a las que hemos llegado.

Con unas 40 sesiones entre open space y ponencias, la temática era muy variada, y pude tomar bastantes notas, entre otras cosas, sobre:

  • Cómo con TDD podemos aprender a trabajar con un lenguaje como Elixir.
  • Cuales son las responsabilidades del arquitecto del software, como todos somos arquitectos en cierta manera y cómo conectar con los responsables de negocio en nuestra empresa o nuestros clientes.
  • Cómo algunos han conseguido llevar soluciones de entrega continua a sectores como la fabricación de vehículos.
  • En qué aspectos de la experiencia de usuario deberíamos fijarnos, como mínimo, a la hora de desarrollar sistemas de información en general e interfaces de usuario en particular.
  • Cómo aprender a enseñar, de qué maneras podemos ayudar, especialmente a los que están empezando, a que entiendan y usen buenas prácticas desde el principio.
  • Por qué perdemos la motivación por la comunidad o por mejorar como profesionales, y cómo podemos recuperarla.
  • Cómo nos organizamos, tanto profesionalmente en el caso de ser freelance como personalmente.
  • Qué libros, charlas o eventos, han influido en nuestra manera de trabajar, nos han enseñado nuevas maneras de ver problemas o nos han inspirado.

Tuve además, la oportunidad de facilitar dos debates, algo que supuso otra experiencia nueva para mí por la cantidad de conversaciones que surgen, cómo se ramifican los temas y la necesidad de ser capaces de reconducir la conversación cuando se aleja demasiado del objetivo del debate.

El formato del evento y los tiempos, con descansos entre todas las sesiones, permitían un amplio margen para conversaciones informales, y eso invitaba a acercarte e iniciar una conversación con gente con quien tal vez no habrías interactuado en una conferencia “tradicional”, ya sea por la cantidad de asistentes como por esa separación entre “ponente” y “asistente”.

De manera paralela, como no solamente de software vive el craftsman, el segundo día por la mañana el tiempo me dio un respiro, me puse mis zapatillas y salí a correr un par de millas alrededor de la ciudad, algo que estoy intentando convertir en una tradición cuando voy a un evento.

Para mí fue toda una experiencia, el viernes comenzó en una sala donde, salvo excepciones, estaba rodeado de desconocidos, y vuelvo el domingo sintiéndome parte de otra comunidad, con muchísima gente que se enfrenta a un montón de problemas interesantes y con quien he compartido experiencias con una cerveza, un café, una copa de vino y algo de comer.

Desde mi humilde blog, no quería perder la oportunidad de agradecer:

  • A la organización por el impagable trabajo que han hecho a lo largo de todos estos meses desde que se convoca hasta que sucede.
  • A todos con los que compartí experiencias, de los que aprendí trucos, y que escucharon mis batallitas,
  • Finalmente a mi familia, por entender la importancia de participar en estos eventos.

Nos vemos en la siguiente!

Tareas, Kanban, GTD y otras hierbas

Cada día, una, dos, diez, o centenares de tareas esperan acción por nuestra parte, tanto en nuestra vida personal como en la profesional.  Mantenerlas al día o completamente fuera de control nos puede alegrar o estropear el día.

En este artículo veremos algunas maneras de organizar las diferentes tareas que surgen a lo largo de nuestra jornada, así como aquellas que planificamos para corto, medio y largo plazo.

Listas de tareas

En este apartado cubrimos desde la lista de la compra hasta un plan de carrera. Es la variante más versátil, y podemos utilizar papel y bolígrafo en su versión más simple. Si compartimos tareas con más personas puede ser más útil recurrir a una pizarra. Por otro lado, si nuestras tareas nos llegan vía e-mail, podemos emplear nuestro cliente de correo favorito para gestionarlas, siempre que no olvidemos dar alguna respuesta al emisor.

En el terreno de las apps, tenemos Apple tasks y Gmail tasks, para iOS y Android, servicios como Remember The Milk, Wunderlist o Todoist, así como alternativas más “frikis” como Todo.txt, basado en ficheros de texto.

Sin embargo, siempre se nos acumulan demasiadas tareas, y alrededor del 60% de lo que escribimos en esas listas nunca se completa, por no decir aquello que no llegamos ni a empezar.

Como alternativa, podemos emplear una “lista de hechos”, donde escribimos aquello que hemos completado en vez de lo que pensamos hacer. iDoneThis es un servicio muy interesante para este escenario.

Agregando prioridades

Una vez que tenemos nuestra lista, el siguiente paso es decidir qué hacer primero. Una de las maneras en las que podemos priorizar nuestras tareas es mediante la matriz de Eisenhower, que divide las tareas en cuatro cuadrantes:

  • Urgente e importante: caída del servidor de producción…
  • Urgente y no importante: pasar la ITV del coche, renovar DNI…
  • No urgente pero importante: una certificación, un viaje, cambiar de trabajo…
  • Ni urgente ni importante: terminar el Halo 4…

Imagen 1.png

Al usar esta matriz, podemos priorizar aquello urgente e importante; dedicar todo el tiempo planificado a aquello que es importante, aunque no urgente; y en la medida de lo posible, delegar o retrasar aquello que, pese a ser urgente, no es importante.

imagen-2

Fuente de la imagen: http://mathewreuther.com/blog/2013/12/30/looking-ahead-to-2014/the-oatmeal-running-agony-nope/

Por último, lo que no encaja en ninguno de los tres cuadrantes debería ser descartado, siempre que haya trabajo pendiente en los otros cuadrantes.

Otra manera de priorizar es la propuesta por el método GTD®, de acuerdo con los siguientes valores:

  1. Contexto: esperando en el metro o sentado en nuestro escritorio, por ejemplo.
  2. Tiempo disponible: cinco minutos antes de una reunión o toda la mañana por delante, por ejemplo.
  3. Energía disponible: ¿Hemos dormido mal? ¿Venimos de salir a correr? No siempre tenemos la misma energía.
  4. Prioridad: finalmente, vemos qué es más importante para nosotros de acuerdo con nuestra preferencia.

Kanban

El contexto que acabamos de ver nos ayuda, pero ¿qué pasa con tareas que tienen más de un estado, o tareas que están en proceso o bloqueadas?

Para mantener estas tareas bajo control podemos recurrir a sistemas como Kanban, que se basa en agruparlas por estados, consiguiendo con ello visualizar todo el trabajo disponible y minimizar aquello que está en progreso, así como poder revisar aquello que hemos terminado.

La principal razón para limitar el trabajo en progreso la podemos ver en el contexto de una carretera: cuando está al límite de su capacidad es inútil, porque es un colapso de coches, mientras que si está vacía también lo es. En este escenario lo que se usa es un punto medio de capacidad que maximice el número de coches que entran y salen de la carretera. Al 100% de su capacidad es un parking, al 0% de su capacidad es un desierto, pero al 60% de su capacidad el tráfico fluye con normalidad.

Cuando trabajamos con tareas, es más importante el tráfico de las mismas que estar operando al máximo de nuestra capacidad; siendo el tráfico lo rápido que una tarea pasa por todos los pasos.

Además, tener muchas tareas “en progreso” puede provocar que haya algunas que no terminemos nunca y se mantengan en ese estado intermedio, volviendo al primer plano de nuestra mente cuando menos lo imaginamos.

Un tablero de Kanban se divide, en su forma más simple, en tres partes:

  • TODO
  • WIP
  • DONE

La sencillez del sistema hace que podamos agregar estados adicionales con total facilidad.

Como herramientas, podemos recurrir a la clásica pizarra blanca + Post-it, o usar aplicaciones como Excel (son filas y columnas, al fin y al cabo) o podemos usar tableros de Kanban de Github, GitLab, TeamServices y Jira, o aplicaciones específicas como Leankit y Kanbanflow, aunque personalmente me decanto por Trello.

Finalmente, el mayor valor de Kanban es su capacidad para trabajar con volúmenes pequeños de información. Demasiadas notas en el tablero pueden provocar que el bosque no nos deje ver los árboles.

GTD

El método GTD, popularizado por David Allen a principios de la pasada década, es uno de los más complejos e interesantes sistemas de almacenamiento y gestión de información.

Se han escrito innumerables libros y artículos sobre GTD, pero las bases son relativamente simples:

  • Capturamos la información en un buzón de entrada.
  • En otro momento clarificamos esta información y decidimos si es accionable o no, asignándola a su lista o archivo correspondiente.
  • Organizamos las listas en tareas, proyectos y contextos en función de la complejidad y los requisitos.
  • Reflexionamos sobre las tareas pendientes, re-priorizando o descartando aquellas que hayan cambiado de estado.

Este sistema se aplica de manera bastante eficiente también a elementos físicos, pudiendo utilizar papel y lápiz, notas de papel almacenadas en carpetas, o herramientas de software entre las que figuran Omnifocus, Things o, como he mencionado antes, Trello.

El principal valor de GTD es la esencia de “mente como el agua”, es decir, vaciar nuestra mente en el sistema y tenerlo todo organizado fuera de nuestro cerebro, para podernos dedicar a crear, en vez de a recordar. Un pasaje de su libro comentaba que era habitual para muchos tener listas con cientos de elementos, algo impensable en un modelo Kanban.

Midiendo resultados

Una parte importante de nuestras tareas es hacer retrospectiva, ver si hemos podido completar lo que nos hemos propuesto o saber qué nos lo ha impedido.

Una manera es utilizar programas que nos ayuden a ver a qué dedicamos nuestro tiempo, como son RescueTime y Qbserve, que vigilan nuestro ordenador para darnos informes detallados de uso y ver cuánto tiempo realmente pasamos trabajando y cuanto se nos va contestando e-mails.

Por otra parte, para tener un control más estricto sobre cuánto tiempo tardamos en completar una tarea, podemos utilizar contadores como Toggl, que está disponible para web, escritorio y móviles.

Además, podemos utilizar técnicas como Pomodoro, en el que dedicamos intervalos de 25 minutos de trabajo y 5 de descanso. Es particularmente útil si no estamos demasiado interesados en la tarea en cuestión: “al menos le dedico 25 minutos y me la quito de encima”.

Finalmente, métodos como Bullet journal defienden volver al papel para realizar esta retrospectiva, tomar nota de lo que ha pasado, incluso de aquello no planificado o de aquello que se nos ha quedado pendiente, ya que estudios han demostrado que recordamos mejor aquello que escribimos a mano.

Conclusiones

Las listas nos acompañan, las usemos conscientemente o no. Podemos crearlas, priorizarlas, agregar contexto, ampliarlas o reducirlas, podarlas y curar el contenido de las mismas, tachar elementos, medir el tiempo y el esfuerzo y, finalmente, reflexionar sobre ellas. Hay muchísimos más métodos, reglas y teorías para gestionar listas. Este artículo es solamente un resumen de lo que he ido probando con el tiempo.

Y tú, querido lector, ¿qué sistema usas o has usado?

Se acaba 2016, nuevos hábitos, retos y aprendizaje

Diciembre es momento de reflexión, de echar la vista atrás, de tomar esas listas de objetivos que fijamos a principios de año y ver qué tal nos ha ido, las cosas que hemos conseguido y las que por otra parte se han quedado en el tintero.

Este año, mis objetivos personales han ido cambiando, con lo cual la lista original se ha quedado un poco obsoleta, así que en esta edición de mi resumen anual quiero compartir contigo, querido lector, algunas cosas que he aprendido, estuvieran en el plan inicial, o no.

Encontrar tiempo para leer y escuchar

Este año me he leído, entre ebooks, papel y audiolibros con Audible, un total de veintisiete libros entre literatura técnica, biografías, ciencia ficción, acción y otros tantos englobados en la categoría de no-ficción, utilizando los viajes diarios a la oficina y también como banda sonora al salir a correr.

Libros como “Getting Things Done” de David Allen, “Deep Work” de Cal Newport, o “The Power of Habit” de Charles Duhigg, a pesar de no ser libros “técnicos”, me han aportado ideas muy interesantes durante el año, coplementando thrillers como “The Gray Man” o “The Janson Directive”.

De manera adicional he estado escuchando algunos podcasts, como “The Tim Ferris Show” y “Fortune Unfiltered”, así como técnicos como “No tiene nombre” de El Bruno o “Hanselminutes”.

Buscar un computer-life balance

He mencionado computer-life y no work-life, ya que en más de una ocasión las ganas de aprender, la colaboración con la comunidad o simplemente reddit y hackernews, logran mantenernos pegados a la pantalla demasiado tiempo, lo cual nos aleja de la productividad y del descanso que nuestro cerebro necesita.

El mi caso el balance lo han aportado un par de zapatillas, un reloj con pulsómetro, unos auriculares bluetooth, y buscar cierta constancia a la hora de salir a correr, tanto por la hora como por el circuito, que aunque parezca monótono te permite “competir” contra tí mismo cada vez que sales, algo que no consigues cuando vas cada día por un circuito diferente.

Como “compañía” para salir a correr, donde antes llevaba música, ahora llevo audiolibros o podcasts, lo que me ayuda a adaptar el ritmo a cómo me sienta en ese momento, sin tener una canción que, en cierta manera, te lo imponga. Como ventaja adicional, cada libro o podcast es completamente distinto del anterior, lo que aporta un extra de motivación para salir.

Conocer la caja de herramientas

Atajos de teclado, comandos de UNIX, o incluso aprender algo de python, me han permitido trabajar mejor y algo más rápido este año.

Un ejemplo: Los chicos de IntelliJ han creado una “chuleta” con algunos de los atajos más usados. Estuvo impresa en mi escritorio durante un par de meses, y gracias a ella útiles. Empecé imprimiendola, pegándola a mi escritorio y subrayando un par de comandos, un año después ya uso unos cuantos más. También existen alternativas para Visual Studio y otros IDEs.

Es cierto que las herramientas por sí mismas no nos hacen mejores técnicos, pero tener soltura con ellas y conocer las diferentes opciones nos puede ayudar a centrarnos más en el problema y menos todo lo demás.

Es dificil, por otra parte, llegar a conocer perfectamente todas las características, funcionalidades, comandos, que necesitamos en nuestro día a día, y esto lo convierte en una oportunidad de no dejar de aprender nunca.

Mejorar la práctica

Una idea que planteaba Jorge Barroso en su charla “Time to grow up” es la idea del desarrollo de software como algo similar a la cocina, en función del momento y la necesidad hacemos un apaño rápido, o hacemos algo digno de estrellas michelín, para lo cual tenemos que aprender mucho, y luego usar lo que podamos en cada momento.

Para mí, “aprender mucho” era algo asociado a un lenguaje, tecnología, plataforma, etc, sin embargo este año he tenido la oportunidad de trabajar y de experimentar con más abstracciones independientes de lenguaje y de arquitecturas independientes de la plataforma, y esas abstracciones (teoría de colas, fundamentos de sistemas distribuidos, patrones de diseño) luego me han permitido entender mejor los problemas, las soluciones o incluso cómo funcionan algunas plataformas.

Aprender es un proceso continuo, pero también tenemos un tiempo limitado para dedicarlo a formarnos y a apender lo que me lleva también a los artículos de Robert “Uncle Bob” Martin titulados “The Churn” y “The Lurn” en los que insiste en la necesidad de aprender conceptos más profundos como concurrencia, o protocolos de comunicación, en vez de dedicar tiempo a aprender otros lenguajes (especialmente si siguen relativamente el mismo paradigma que los que ya sabemos).

Para 2017

En general la idea es seguir usando los mismos hábitos que he ido cultivando estos años, ir mejorando cuando se pueda, y contribuir de vuelta a la comunidad, de la cual aprendo cada día.

  • Seguir leyendo, estudiando y compartir las notas de lo leído.
  • Seguir corriendo y moviéndome, este trabajo nos hace sedentarios.
  • Seguir aprendiendo abstracciones, y hablar de ellas en el blog.
  • Mejorar la fluidez con herramientas de UNIX, comandos, pipes, python para scripts, etc.
  • Contribuir de vuelta a la comunidad vía charlas o artículos.

Como se ve no son objetivos, con lo cual dentro de un año será dificil cuantificar si lo he conseguido o no, sin embargo, cada vez que lea un libro nuevo, corra un KM más o aprenda un nuevo comando, será una pequeña victoria, y no una derrota constante hasta no cumplir el objetivo.

Veremos dentro de un año si he mantenido estos hábitos, creado nuevos, o perdido alguno de los que está en la lista.

Feliz Año Nuevo

He leído: Deep work

En septiembre agregué un nuevo libro a mi colección llamado “Deep Work”, y el subtítulo se traduciría como reglas para mantener la concentración en un mundo distraído. El libro define “Deep Work” como todo aquello que nos exija cierto esfuerzo cognitivo, y la importancia de dedicar tiempo libre de distracciones para este tipo de trabajo.

A lo largo de 300 páginas (o casi 8 horas en su versión de audio) Cal Newport va mostrando ejemplos de cómo detectar este tipo de trabajo, diferenciándolo de “Shallow Work” o trabajo trivial, como podría ser gestionar el email, reuniones o tareas administrativas, entre otros.

Sigue leyendo

Conservando el estado en una SPA

En aplicaciones web como Gmail o Facebook, la mayor parte de la interacción se realiza una vez la página original se ha cargado, de manera que la URL a la que se accede originalmente no cambia. Esto provoca que al refrescar la página en el navegador, cualquier cambio efectuado en el estado se pierda.

Dos enfoques distintos

Estas aplicaciones sí que mantienen el estado del lado del cliente manipulando la URL original, como se puede ver en estos dos ejemplos:

  • Gmail basa su URL en carpetas y mensajes en ese contexto, con lo cual /mail/u/0/#starred carga la carpeta de favoritos y /mail/u/0/#starred/13da7c68fe1d0cc0 enlaza a un mensaje para un mensaje en el contexto de esa carpeta.

  • Trello por su parte es un gestor de tareas ordenadas por listas en tableros, la url puede representar un tablero /b/Pvr5jDBv/recetas o una tarea específica /c/e0y3broE/12-arroz. La URL se modifica para definir el tipo de recurso, un identificador y un nombre legible.

Ambas soluciones emplean una manera diferente de modificar la URL, Google agrega un hash (#) al final de la URL, mientras que Trello modifica completamente la misma mediante el uso de PushState, una manera de manipular el historial del navegador introducida en HTML5.

Utilizado Hash para agregar estado y leerlo

El hash (#), como se ha mencionado anteriormente, se sitúa al final de la URL, y no se envía al servidor, sino que se procesa en el propio navegador. Su uso está muy extendido ya que no requiere HTML5, cosa que sí pasa con PushState.

Para modificar la URL se puede acceder como se ve en el ejemplo, el acceso a la misma se realiza leyendo la misma variable:

function pushUrl(value) {
  document.location.hash = "key=" + value;
}

Al no enviar el contenido al servidor, no es necesario agregar soporte de backend de ningún tipo, y se puede emplear con páginas estáticas servidas con Github pages, por ejemplo. Esto también tiene una desventaja, que es que limita cualquier tipo de pre-procesamiento que se quiera realizar al recargar la página.

PushState por otra parte, al no utilizar Hash, genera URLs mucho más limpias, permite cierto procesado inicial del lado del servidor, y además permite modificar el historial, haciendo que la interacción sea más cercana a la de una aplicación web.

Un ejemplo práctico

En este ejemplo se ha creado una aplicación de búsqueda, al introducir un criterio, se agrega a la URL, de tal manera que al refrescar la página se lee el contenido y se aplican los cambios:

captura-de-pantalla-2016-09-16-a-las-1-17-58

La aplicación de ejemplo se encuentra disponible aqui y el código está disponible en Github.

Conclusiones

Al desarrollar una aplicación web es importante preguntarse si se quiere conservar el estado (guardado en favoritos, envío de enlace vía e-mail, mailing lists, etc) y qué opción usar. Hash es una manera cómoda de agregar estado como se puede ver, aunque existen maneras más sofisticadas como el uso de PushState, que permite de manera adicional modificar el historial de navegación.

Enlaces

  • Sobre el hash MDN
  • Sobre PushState MDN
  • Código de ejemplo Github

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.