Acaba de empezar diciembre, este mes cerramos año y década, y me ha parecido una buena ocasión para compartir con vosotros una breve reflexión.
En los más de 10 años que llevo escribiendo este blog, he visto empresas y productos desaparecer, paradigmas tecnológicos que iban a revolucionar las cosas que luego no han revolucionado tanto, lenguajes, herramientas, métodos, y utilidades para aburrir, todo esto son, dicho de una manera simple, cosas, en las que personalmente he invertido mucho tiempo, y aunque he aprendido mucho por el camino, no dejan de ser cosas.
Por otra parte, he podido podido compartir experiencias por videoconferencia y escenarios con grandes profesionales a los que admiro mucho, he descubierto el formato open space y superar el miedo a salir a proponer temas para discutir, que a veces saliera, y a veces no, aprender de la experiencia de los demás, aportar un poco siempre que se pudiera y escuchar mucho rodeado de gente. Personas que van un paso más allá para compartir lo que saben, muchas veces de manera altruista y de su propio bolsillo. Estas experiencias me han enseñado mucho, pero más importante, he podido conocer a gente excepcional.
Estas situaciones en cierta manera contrastan con el día a día de nuestra profesión, que en ocasiones requiere y exige que nos pasemos largas horas en la soledad de nuestra pantalla, nuestro IDE, y aunque tenemos cientos de maneras de distraernos y perder el foco, no deja de ser un momento de soledad. El estrés y la ansiedad causados por el día a día del trabajo no hacen más que incrementar esta soledad, ya que nos vemos pasando más tiempo en la pantalla, más tiempo alejados de la gente y para colmo, expuestos a las redes sociales que nos recuerdan de manera constante todo lo que nos estamos perdiendo.
Esa gente, que es nuestra familia, nuestros amigos, nuestros compañeros del trabajo, los miembros de la comunidad a la que pertenecemos, los colegas de la facultad, la gente con la que entrenamos, etc., es importante. Son ellos los que nos sacan del pozo cuando el trabajo se complica, y los proyectos se atragantan, y son ellos los que están allí si las cosas van mal en el terreno personal.
Siempre tendremos trabajo, siempre será urgente, y siempre será lo más importante, y muchas veces será diferente, sin embargo, y es algo que todos experimentaremos según pasa la vida, esa gente a la que importamos, nos importa y nos apoya no va a estar para siempre, y de hecho nos queda mucho menos tiempo con ellos del que creemos.
Por ello, en estos últimos días de la década de los 2010, me gustaría que todos nos alejáramos un poco de las pantallas, de la soledad de nuestros proyectos, pongamos el móvil en no molestar y les dediquemos un poco más de tiempo a esas personas que nos soportan, que nos apoyan y que nos ayudan a avanzar, y estemos allí para ellos con una sonrisa, los brazos abiertos y voluntad de escuchar.
Espero volver a veros por aquí después del 25 de diciembre para compartir con vosotros mi resumen anual, y tal vez algo con más contenido técnico :)
La terminal de unix lleva décadas ofreciendo utilidades no solamente a desarrolladores y administradores de sistemas a nivel de servidor, sino también a entusiastas en entornos de escritorio.
El uso de herramientas como git, o nodejs, ha traído un uso mayor de la consola a los entornos locales, y también la necesidad, a veces, de estar conectados a terminales remotos vía SSH.
El problema de una conexión por SSH es que si tenemos un fallo de red o suspendemos nuestro ordenador, nuestra conexión se puede ver afectada, lo que causará que nuestra sesión termine, y con ella los comandos que estemos ejecutando.
Existen utilidades que no solamente nos permiten prevenir esta circunstancia sino que nos permiten tener una configuración en nuestra terminal remota que haga más sencilla la conexión. En el artículo de hoy hablaremos de tmux, una solución que nos permite controlar múltiples ventanas y mantener la configuración de las mismas.
Instalando tmux
La fuerza de tmux radica cuando lo instalamos de manera remota en un servidor al que accedamos con frecuencia. En mi caso particular, me suelo conectar vía SSH a hosts que emplean Amazon Linux en la nube de AWS y usamos yum como gestor de paquetes, con lo cual el comando es:
yum install tmux
Podemos también instalar tmux en local y tener una configuración de consolas personalizada. En el caso de Mac podemos instalar tmux vía homebrew:
brew install tmux
Si tenemos Windows y WSL tendremos acceso a una shell de bash, en la que podemos instalar tmux utilizando:
apt-get install tmux
Utilizando tmux
La manera más sencilla de utilizar tmux es como una capa por encima de la terminal.
tmux
Este comando inicia una sesión de tmux que permanecerá activa incluso si nuestra conexión se cierra o en el caso de que estemos ejecutando de manera local, si cerramos la ventana. Este comportamiento se mantiene tanto en local (Mac) como en una sesión SSH, no sé que pasaría en Windows
Si cerramos la ventana nuestra sesión de tmux seguirá funcionando, así que para salir de la misma podemos utilizar o bien Ctrl + d o bien escribir logouto exiten la consola de comandos.
Por defecto. las sesiones en tmux están numeradas, para volver a una sesión solamente necesitamos escribir tmux lsy a continuación tmux attach -t Ndonde N es el número de sesión. Por otra parte podemos darle nombre a nuestras sesiones, lo que hará que volver a ellas sea mucho más sencillo.
Creamos nuestra sesión contmux new -s desarrollo
Volvemos a la misma con tmux attach -t desarrollo
Múltiples pestañas, pantalla dividida y más
Una vez tengamos nuestra sesión abierta, podemos personalizarlo utilizando Ctrl + bque es el prefijo por defecto en tmux, una vez pulsado, los siguientes comandos nos pueden ayudar:
“Dividir el panel de manera horizontal
%Dividir el panel de manera vertical
derecha/izquierda/arriba/abajoDesplazarse por los paneles
cCrear una nueva ventana
nCambiar a la ventana siguiente
pCambiar a la ventana anterior
En el siguiente ejemplo (ejecutado de manera local) se puede ver una sesión con dos ventanas y tres paneles.
Si cerramos la ventana y volvemos a la sesión se mantendrá abierta.
Tmux con iTerm (Mac)
Si utilizamos Mac con iTerm, este último tiene integración con Tmux, con lo cual podemos crear los paneles utilizando la manera nativa que estamos acostumbrados en iTerm, y podremos intercambiarlos con los controles nativos.
Para ello abriremos nuestra sesión con tmux -CC newo tmux -CC attach
Iterm, por defecto, abre nuevas pestañas de Tmux en ventanas, con lo cual para cambiar esa configuración podemos ir a Preferences > general > tmux > Open tmux windows as “Tabs in attaching window” como se ve en la imagen
Personalizando nuestra configuración
El último paso es tener nuestra configuración guardada de manera persistente de tal manera que “sobreviva” un reinicio del sistema o si queremos simplemente poder volver a una configuración estable.
Para ello, usemos el ejemplo que he descrito anteriormente en un script de bash:
Este script lo podemos guardar como reset-session.sh y podemos llamarlo siempre que queramos restaurar la configuración de la sesión que teníamos anteriormente.
En resumen
Tmux es una herramienta muy poderosa que nos permite personalizar la configuración de nuestras ventanas, mantener procesos en ejecución dentro de una consola remota y guardar esta personalización para poder restaurar un espacio de trabajo a nuestro gusto.
Hace casi casi 4 años, el 25 de octubre de 2015, David nos hacía saber en su newsletter y en su blog que estaba montando una conferencia dedicada a la gente que, como yo, leía sus columnas semanales. Nacía entonces la #TarugoConf.
Cada año a partir de entonces veíamos como las redes se llenaban de comentarios en dos fechas clave, cuando salían las entradas a la venta (que eran reducidas por temas de aforo y mucha gente, incluido un servidor, se quedaba sin poder asistir) y en la fecha del evento, en el que los asistentes salían contentos e inspirados.
Tres ediciones después, la providencia me ha permitido asistir a mi primera Tarugo, y puedo aseguraros que Bonilla no defrauda.
La TarugoConf es un evento que combina tecnología, negocios y un montón de cosas más, con un track de charlas, comida “como para una boda” y muchos espacios y oportunidades para conocer a gente, para desvirtualizar aquellos a los que solamente has visto en redes o para recuperar el contacto con compañeros a los que le has perdido la pista.
En el track de charlas los temas en esta edición han sido:
Cómo potenciar la innovación en los equipos utilizando un montón de anécdotas de la industria de los helados.
Qué mecanismos podemos implementar desde un punto de vista técnico para mejorar la privacidad de nuestros usuarios en nuestros sistemas.
Cómo convertirnos en podcasters, qué técnicas utilizar, qué medios comprar, cómo conseguir audiencia y cómo incluso podríamos ganar dinero con ello.
Cómo montar un flujo de trabajo para científicos de datos, cómo integrarlos con el desarrollo de producto y sobre todo, pensar si necesitamos ese rol en nuestros equipos.
Cómo hacer productos que vendes a otras empresas, con especial hincapié en cómo incrementar la conversión entre un primer contacto y un contrato firmado.
Cómo crear mecanismos de entrega de valor, desde control de versiones a gestión de artefactos a entrega continua utilizando anécdotas de consultoría, administración pública y desarrollo de producto.
Cómo crear y mantener un estudio de videojuegos, utilizando anécdotas en el rol de estudio, publicador, editor, y todas las anteriores, y con especial interés en tener ambos lados del cerebro en un estudio, creativo y gestión.
Cómo hacer negocios en latinoamérica, qué tener en cuenta, qué mercados están creciendo, cómo conseguir presencia y cómo lograr que te paguen, entre otras.
Cada ponencia, de aproximadamente 45min + preguntas, ha sido tan interesante o más que la anterior, y pese a que hemos estado más de 8h en una sala de cine a nivel personal no se ha hecho largo. Los ponentes han hecho un excelente trabajo condensando estos temas, y todas y cada una de las charlas han tenido un componente práctico, y ha sido sencillo traernos deberes “a casa”.
Los voluntarios y la organización han estado todo el tiempo pendientes de los asistentes, poniendo todo el amor, las ganas y los focos de las cámaras en que todos estuviéramos pasando un buen rato, sintiéndonos como en casa.
Finalmente los patrocinadores han estado especialmente involucrados, con un nivel de interacción con los asistentes diferente, y más allá del típico stand. Un ejemplo de ello han sido los chicos de Libros.com una editorial que publica novelas, ensayo, manuales, y artes gráficas utilizando crowdfunding, y que estaban allí por una parte mostrando el resultado de sus campañas, y por otra parte (más interesante aún) buscando historias que publicar. Un equipo muy cercano del que espero hablar más en el futuro, mientras tanto, si tienes una historia que quieres compartir con ellos aquí te dejo el enlace
Como anécdota personal, he conocido en persona a la gran Nerea Luis, Doctora en IA, y cofundadora de T3chfest, con la que comparto, por casualidades de la vida, apellido, y nos hemos contado batallitas sobre el caos administrativo de un apellido que suena tanto, tanto, a nombre.
Enhorabuena a todo el Equipo Tarugo por un gran evento, por hacernos sentir en familia, por enseñarnos tanto y por inspirarnos.
Hoy hablamos de un libro que me ha tenido enganchado durante varios días y varias horas de vuelo, un ensayo lleno de historias médicas, de aviación, construcción y cocina, sobre un mecanismo que comparte que mejora la seguridad, la eficiencia y, sobre todo, protege y salva vidas. una lista.
Hoy te cuento, querido lector, acerca de The Checklist Manifesto, de Atul Gawande.
Nuestra memoria falla, y no hay nada que podamos hacer al respecto
En nuestro día a día, la complejidad de nuestras obligaciones profesionales ha aumentado exponencialmente, y se espera que podamos mantener bajo control situaciones variables, variaciones, opciones e incertidumbre, y en medio del caos es normal, y común, olvidar cosas o pasarlas por alto.
La memoria tanto a corto como a largo plazo puede fallar, y falla. En una mesa de operaciones o en una cabina de un 747, esto tiene trágicas consecuencias.
La lista: alternativa simple y sofisticada
La manera de mitigar el error, comenta el autor, no es prestar más atención, más medios, más maquinaria o más tecnología, sino un enfoque más simple, tener una lista con puntos críticos, y utilizarla y revisarla de manera continua.
Una lista, en este contexto no es algo que se escribe en 5 minutos, no es un manual de instrucciones, no tiene como objetivo enseñar ni educar, y se basa en la suposición de que será utilizada por profesionales que conocen perfectamente su dominio.
El uso de esta lista puede ser, por una parte en un caso normal (despegar un avión) así como en situaciones excepcionales (motor en llamas). En ambos escenarios, tener una lista de acciones a realizar permite libertad a la persona para poder centrarse en la tarea a mano sin olvidar elementos críticos.
Es importante entonces definir qué es una mala lista. De acuerdo con el autor, una mala lista es poco precisa, demasiado larga y difícil de utilizar.
Por otra parte, una buena lista es práctica, precisa, eficiente, fácil de utilizar en situaciones complejas, y sobre todo, un recordatorio de los pasos críticos e importantes que se pueden pasar por alto independientemente de cuan experimentada sea la persona que las va a utilizar.
Creando nuestras listas
A lo largo del libro, el autor nos da algunas pistas para crear listas efectivas tras aprender de la mano de pilotos de Boeing, y de cómo lo puso en práctica en una mesa de operaciones.
Por una parte, queremos entender especificar qué tipo de lista necesitamos:
DO-CONFIRM: En este caso la lista se utiliza como punto de sincronización, las tareas se hacen «de memoria» y llegados a un punto específico (antes de comenzar la operación, antes de entrar en una pista de aterrizaje) se comprueban todos los puntos de manera rápida.
READ-DO: En este caso la lista se utiliza como una receta, una serie de pasos que hay que seguir en un orden específico. Un ejemplo de uso de esta lista sería el caso del motor en llamas.
El objetivo de limitar los puntos es que podamos revisar la lista en cuestión de segundos, de tal manera que no se interponga en nuestro trabajo, no olvidemos que una lista muy larga puede provocar que empecemos a «saltarnos» puntos de la misma.
Dichos puntos han de ser claros, específicos, solamente aquellos que consideremos críticos, con un lenguaje simple, y específico del contexto, como hemos mencionado antes, no estamos ante una herramienta de aprendizaje.
El documento ha de ser puesto en práctica para verificar que funciona en el mundo real. Los pilotos utilizan los simuladores de vuelo para ello.
Es necesario asegurarse que la lista funciona tanto en situaciones normales y en caso de una emergencia. En caso de que las listas no funcionen en un entorno de pruebas, se toman notas, se vuelve atrás, se mejoran, y se intenta una y otra vez.
Resumen
A lo largo de unas 200 páginas, el autor cuenta ejemplos de cómo las listas nos permiten no perder de vista puntos críticos del trabajo que hacemos sin limitar nuestra creatividad ni capacidad de reacción, más bien al contrario, establece un balance de libertad y disciplina que nos permite mejorar, ser predecibles y efectivos, especialmente en situaciones extremas.
De momento he empezado a experimentar creando y puliendo listas, cosas que revisar antes de dar por bueno un documento, diseño, análisis, o incluso antes de tener reuniones o de entrevistar a un candidato.
El pasado 1 de Julio, tras pasar cuatro años como parte de la familia Amazon Business, cambié de organización para empezar una nueva aventura como miembro del equipo de ingeniería de Kindle.
Cambiar de organización a nivel corporativo es algo suficientemente complejo que “casi” equivale a cambiar de empresa, con lo cual había expectativas que fijar, información que transferir, tareas que cerrar y procesos que documentar.
En este artículo veremos algunos elementos a tener en cuenta cuando cambiamos de equipos desde el punto de vista del técnico individual, algunos estos elementos serán aplicables también a cuando cambiamos de empresa.
Expectativas
Lo primero, una vez aclaramos con nuestro jefe de nuestra intención para cambiar de destino, es necesario fijar plazos para cerrar frentes abiertos y proyectos en curso.
Si estamos cambiando de empresa, lo habitual es que tengamos un plazo mínimo de notificación estipulado en el contrato, mientras que si estamos cambiando de equipo podemos ser más flexibles.
En general, basándome en mi experiencia, entre tres semanas y un mes debería ser tiempo suficiente para cerrar frentes abiertos y hacer transferencia de conocimientos, lo que nos lleva a…
Listar frentes abiertos
El siguiente paso es abrir una hoja de Excel, Google Spreadsheets, o un fichero de texto y comenzar a escribir una tabla con la información siguiente para todo lo que tengamos en la cabeza:
Área (o proyecto)
Tarea
Estado a fecha de hoy
Personas involucradas (aparte de nosotros)
Fecha tope
Estará completo antes de que dejemos el equipo?
Quién se puede hacer cargo cuando no estemos?
Qué necesitamos para que esté completo?
Aunque tengamos un equipo perfectamente conexionado con todas las tareas en Jira, TFS, GitLab, Github, Trello, etc. siempre habrá tareas que tenemos en la cabeza, ideas y frentes abiertos que no viven en el sistema de gestión de tareas.
Para aquellas tareas que estén asignadas a nosotros en el sistema, podemos repetir el ejercicio documentando el estado actual y el estado esperado cuando ya no estemos.
Es importante dejar a una persona o punto de contacto a cargo de estas tareas, para ello podemos sugerir alguien en nuestro equipo que tenga especial contexto sobre las mismas, de manera que el seguimiento no se interrumpa.
Notificar a personas involucradas
Tras listar los frentes abiertos y detectar las personas involucradas, es importante notificar a otras personas que trabajan con nosotros que no seguiremos en el equipo, especialmente si somos la persona de contacto de una o más iniciativas, y hacer las conexiones necesarias entre otros equipos y los nuevos interlocutores.
De esta manera nos aseguraremos que los proyectos sigan adelante y estableceremos expectativas claras para las personas que están fuera de nuestro equipo aunque colaboren con nosotros.
Documentar progreso
El siguiente paso, una vez aclarado qué vamos a poder poder terminar y qué no, es dedicar tiempo a documentar, especialmente los proyectos que hemos entregado más recientemente y aquellos que se van a mantener en curso cuando no estemos.
Como ejemplo de elementos que podemos documentar, tenemos:
Decisiones técnicas tomadas y por qué las hemos tomado.
Puesta en marcha en pruebas y producción de nuestros servicios.
Detalles sobre scripts y pequeñas automatizaciones que hayamos hecho.
Transferir conocimiento
Además de la documentación, es muy útil tener una o varias sesiones de transferencia de conocimiento con otros miembros del equipo que vayan a heredar nuestras responsabilidades.
Estas sesiones pueden cubrir, entre otros aspectos:
Visión general de los diferentes servicios que componen nuestro sistema
Ciclo de vida de peticiones (especialmente útil en una arquitectura de microservicios)
Tickets cerrados recientemente, especialmente aquellos de alta prioridad, y causas más comunes.
Estas sesiones, además, podemos grabarlas en vídeo de manera que queden como “documentación” para que otros miembros del equipo puedan recurrir a ellas en caso necesario.
Limpiar
Cambiar de equipo suele ser una buena oportunidad para hacer “borrón y cuenta nueva”, así que podemos aprovechar para renovar equipamiento si es posible.
En cualquier caso es una buena oportunidad para hacer copia de seguridad, y borrar repositorios locales de proyectos antiguos, siempre y cuando dejemos copias de nuestras ramas en repositorios remotos.
Re-asignar cuentas, permisos, credenciales, listas de correos…
Dependiendo del grado de automatización que tengamos, nuestro usuario puede ser administrador o dueño de ciertos recursos, por tanto será necesario re-asignar dichos recursos así como rotar claves en caso de que no tengamos un sistema automatizado. En caso contrario se podría perder información cuando nuestra salida se haga efectiva.
Es posible que tengamos acceso a sistemas específicos única y exclusivamente por pertenecer a ciertos equipos, y es importante asegurarnos que este acceso será revocado, ya que puede ser un vector de ataque desde nuestra cuenta del que nos olvidemos en el futuro.
De manera adicional, es importante dejar listas de distribución o canales de slack que dejen de ser relevantes para nosotros, ya que solamente agregaremos ruido y podemos dar la falsa impresión de que seguimos en el equipo.
Seamos accesibles
Incluso tras meses de trasferencia de conocimientos habrá cosas que no seamos capaz de transmitir, o problemas que surjan cuando no estemos, y para ello es importante mantenernos accesibles.
Si seguimos dentro de la empresa, habrá ocasiones en que alguien de nuestro antiguo equipo contactará con nosotros con dudas o preguntas, especialmente en las primeras semanas o meses, y es una oportunidad para seguir ayudando y apoyando al equipo.
Conclusiones
Los cambios siempre traen incertidumbre, cuando nosotros propiciamos un cambio generamos incertidumbre en la gente a nuestro alrededor pero también en nosotros mismos.
Construir un plan de transición nos ayudará a reducir y limitar esta incertidumbre tanto para nosotros como para nuestros compañeros.
Dejando claras las expectativas, los frentes abiertos, habiendo transferido el conocimiento, documentando proyectos, dejando los recursos con sus nuevos dueños y manteniéndonos accesibles, podremos enfrentar los nuevos retos que nos esperan tras cerrar una etapa profesional, hagámoslo bien.
Esta semana he estado leyendo sobre Backend For Frontend o BFF, un patrón de arquitectura de microservicios dio a conocer al mundo uno de los ingenieros de SoundCloud en el año 2015, aunque sigue aplicándose a día de hoy.
En este artículo veremos el problema que tenemos en un entorno de microservicios y cómo el patrón BFF es una de las soluciones posibles.
El problema
Una aplicación web presenta diferentes niveles de complejidad en función de la necesidad. El ejemplo más básico es el de un único sistema que genera el contenido de lado del servidor, donde tanto el frontend como el backend forman parte del mismo, lo que se considera un monolito (por ejemplo, este blog).
Este sistema se puede hacer más complicado si convertimos este monolito en un conjunto de APIs REST unido a un código más complicado del lado del cliente (una Single Page Application o SPA) (o un estéreo-liso). Hasta este momento tenemos una única conexión entre cliente y servidor.
La complejidad puede aumentar mucho más por dos lugares diferentes. Por una parte, podemos necesitar soportar otros canales, como una aplicación móvil, una skill de Alexa, o una API para terceros. Por otra, el backend se puede dividir en diferentes servicios, cada uno con una API específica, a la que nos tendremos que adaptar.
Llegados a este punto, nos encontramos en una posición en el que los clientes (la aplicación móvil, la aplicación principal, la skill de alexa y un desarrollador independiente) dependen de una API común o de una serie de APIs independientes, con lo cual se genera un acoplamiento fuerte entre dos o más sistemas.
El resultado es que todos los clientes acceden a APIs que dan mucha más información de la que ellos necesitan, y no tienen una manera específica de controlar qué información utilizar y cómo leerla. Además, esto limita la capacidad de los desarrolladores de la API, ya que de repente cualquier cambio tiene que ser consensuado con todos los clientes, aumentando la probabilidad de generar regresiones.
La filosofía
La filosofía propuesta por BFF intenta simplificar la relación entre un cliente y su servidor, generando un punto de entrada para cada cliente. Esto significa que un cliente accede a una API exclusiva que soporta casos de uso específicos de cada cliente y que el cliente tiene total libertad para adecuar su API a sus propias necesidades.
En un patrón de microservicios, esto significa generar un servicio intermedio que de soporte única y exclusivamente a este tipo de cliente. Este servicio, desde el punto de vista de pertenencia, le pertenece al equipo del cliente. Volviendo a nuestro ejemplo, el equipo de la Skill de Alexa tendrá una API diferente al equipo de la app móvil, que el de la aplicación de escritorio.
La ventaja principal, que he comentado anteriormente, es que se simplifica el acoplamiento entre una aplicación y sus servicios de backend. Además, es más fácil que un servicio de backend evolucione, ya que las adaptaciones no necesitarán desplegar nuevos cambios en cliente, sino solamente en los adaptadores.
El ejemplo
Supongamos que queremos diseñar la siguiente iteración de Pokemon Go, tenemos una aplicación móvil en la que capturaremos los Pokemon, una web donde podemos ver detalles de nuestras capturas y una Skill de Alexa en la cual podemos saber en qué posición estamos del ranking.
En un desarrollo tradicional con un único endpoint, tendríamos una API REST en el cual todos los clientes efectuarán las llamadas necesarias, todos los clientes utilizarán el mismo protocolo y tipo de datos.
Este sistema convierte nuestra API rest en un punto de fallo para tres sistemas diferentes, con el añadido de que, salvo el sistema web, un fallo que rompa los clientes de iOS y los de la Skill de Alexa pueden tardar en corregirse, ya que depende de las reglas de cada marketplace.
Por otro lado, ¿que pasaría si cada cliente tuviera un servicio asociado? Esto provocaría un aumento considerable en la libertad de los diferentes equipos en desarrollar soluciones en el servidor para sus problemas específicos.
El equipo que gestiona la web podría decidir en utilizar GraphQL para generar solamente una petición, y utilizar código isomórfico para tener JavaScript en cliente y servidor.
El equipo que gestiona la Skill de Alexa podría utilizar una opción servirles en Lambda utilizando Python.
El equipo que utiliza la aplicación iOS, con el objetivo de ahorrar ancho de banda a los clientes, puede decidir montar un servicio a bajo nivel con un socket TCP.
Este cambio no afecta a la lógica de negocio, ya que estos servidores seguirán llamando a nuestro servicio común, que a su vez puede evolucionar de manera separada dividiéndolo en otros tantos servicios.
Esto permite además una evolución mucho más rápida de los sistemas, ya que en caso de un cambio importante, solamente será necesario actualizar los servicios intermedios, y las aplicaciones cliente pueden continuar funcionando.
Los inconvenientes
El principal problema de utilizar una API para cada tipo de cliente es la complejidad, de repente tener un servicio y tres aplicaciones cliente se convierte en tener tres servicios, tres aplicaciones cliente y un cuarto servicio por encima de todas ellas. Esta complejidad no está exenta de coste, lo cual puede repercutir en más hardware, más configuración y encarece el desarrollo.
Otro problema de esta aproximación es que requiere que los equipos de cliente tengan capacidad para generar su propio servicio de backend, lo que implica tener conocimientos de backend en un equipo frontend o un equipo mobile, lo cual no siempre es el caso.
El dilema de dogfooding
Dogfooding (o “eat your own dog food”) es el término que en ocasiones empleamos para utilizar las mismas herramientas y APIs a las que pueden acceder nuestros clientes externos, idealmente con el objetivo de no crear ciudadanos de primera y de segunda.
Sin embargo el peligro que tiene una API pública es el riesgo de romper a clientes externos con cambios que tengan sentido de manera interna pero no de manera externa, así que podríamos considerar la API pública como una API más, con una evolución diferente.
La decisión, to bff or not to bff?
La respuesta es, como siempre, depende. Si tenemos un sistema en el cual un tipo de cliente solamente va a utilizar un subconjunto de la API principal, puede ser buena idea crear un acceso solamente para este tipo de clientes. Ejemplo: Una skill de Alexa para agregar elementos a una lista de tareas, y un portal web para administrarlas.
Si, por el contrario, todos nuestros clientes van a utilizar los mismos métodos de nuestra API, y todos los clientes van a ser exactamente iguales en cuanto a funcionalidad, es posible que no necesitemos más que una API para gobernarlas a todas.
Echando la vista atrás recuerdo un ejemplo muy claro en el que tener un servicio genérico con el objetivo de soportar varios tipos de cliente condicionó muchísimo el diseño del primer y único cliente que se terminó desarrollando, agregando un montón de lógica al cliente de manera innecesaria para adaptar los datos que venían del servicio. Esto se podría haber evitado considerando que el servicio iba a tener un único cliente.
Resumen
BFF es un patrón de diseño de microservicios que nos permite considerar que el acceso a nuestro servicio se realiza desde clientes específicos con necesidades específicas, permite evolucionar las diferentes capas de la aplicación de manera paralela y elimina acoplamiento entre clientes diferentes con casos de uso específicos, siempre y cuando podamos asumir los costes de tener diferentes puntos de entrada a nuestra aplicación mantenidos por diferentes equipos.
Si quieres leer más del tema te recomiendo que eches un vistazo a los siguientes artículos:
El pasado jueves estuve en la primera sesión del grupo MADnagers in tech y el tema de conversación era “Gestionando equipos en remoto”, presentado por Pablo Carranza, Head of Engineering en Cabify.
Aunque tuve la mala suerte de llegar un poco tarde y perderme los primeros minutos de presentación, lo que pude ver me resultó realmente interesante, así que no quería perder la ocasión de compartir mis notas y aprendizajes de esta sesión.
Dos ritmos de trabajo en paralelo
Una de las ideas más interesantes que se comentó fue la de los dos ritmos de trabajo a los que nos enfrentamos en una organización, y que funcionan a la par:
El primero se refiere al aquí y ahora, las características, bugs, y problemas a los que se está enfrentando el equipo a fecha de hoy. Este ritmo es el que se suele ver diariamente en las standups, en los correos “urgentes” y en la cola de tickets que nos vienen de atención al cliente. El responsable de llevar este ritmo es el propio equipo, que tiene todo el contexto sobre el aquí y ahora, siendo la labor del líder del equipo la de desbloquear situaciones, pero no la de controlar cada tarea.
El segundo se refiere al futuro, aquí es donde están las nuevas peticiones, el estado de los proyectos que se ejecutarán más adelante, las nuevas iniciativas, las migraciones, y todo lo que no tenga el carácter de “Urgente”. En este caso el responsable de llevar este ritmo es el líder del equipo, de fijar el contexto y mantener la conversación sobre el futuro, especialmente a la hora de encontrar bloqueos que afecten al equipo
Uno de los puntos en los que más incidió Pablo fue en la necesidad de que tanto el presente como el futuro convivieran, idealmente, en el sistema de control de tareas, ya sea Jira, Github, Gitlab u otros.
Esto es debido a que el sistema de control de tareas permite mantener una conversación de manera asíncrona y pública y en diferentes hilos. Esto es especialmente importante en el caso de equipos remotos, ya que por una parte, no todos los miembros del equipo tienen que estar disponibles a la misma hora, y por otra, garantiza que en el futuro cualquier miembro del equipo pueda acceder a este historial, especialmente nuevos miembros.
Roadmaps permanentes y controlados
Otro punto destacado fue la gestión del Roadmap, en la que pasamos de un documento de Word compartido por email a un sistema controlado y versionado.
Un roadmap es importante en cuanto a que define la dirección a la que vamos, y por tanto es un documento que debería cambiar lentamente y de manera controlada. Si un roadmap está cambiando constantemente se convierte en un documento que no es fiable, y por tanto se le deja de presentar atención.
Es por ello que una idea que plantea Pablo es la de mantener el roadmap de manera controlada y controlar qué cambios se hacen al mismo. La manera más fácil de hacer esto es mantener el roadmap en un fichero markdown dentro de nuestro control de versiones, que las actualizaciones del mismo se realicen vía pull request, y que se pueda tener una conversación sobre la misma de manera pública y asíncrona.
Esto además nos permitiría mantener el histórico de donde estábamos hace 1 año, 6 meses, y ver si lo que queríamos hacer entonces lo queremos hacer ahora.
Si no está escrito, no pasó
En este punto, mencionaba dos ceremonias que suelen ocurrir cuando tenemos un equipo parcialmente remoto, las reuniones formales, como por ejemplo la standup, y las reuniones informales, como las conversaciones de pasillo.
Por lo general, salvo que exista una agenda definida y unos minutos tras la reunión, no se suele dejar constancia de que lo que se ha contado en una reunión, especialmente si la información solamente se comparte en ese momento y no queda en una tarea.
Esto es especialmente delicado en lo que respecta a las conversaciones de pasillo, ya que suelen ir acompañadas por una toma de decisiones que no suele quedar documentada, ni la decisión, ni las razones de la misma.
Pensando en este tema me ha venido a la memoria el año 2012, cuando formaba parte del equipo de Códice Software haciendo PlasticSCM, que durante las standups un miembro del equipo tomaba nota del estado que compartía cada miembro del equipo, y luego ese estado se actualizaba en una wiki de manera pública.
De esta manera, al final del sprint se podría comprobar cómo había sido el progreso del mismo, y habría un registro. Por otra parte, si alguien se incorporaba después de unos días de vacaciones, era tan sencillo como ir al registro del sprint, leer el estado y ponerse al día de manera asíncrona,
Cuidado con los Silos
Otro de los puntos comentados se refería a cómo el no compartir la información de manera pública puede acabar provocando silos de información, cuando solamente ciertas personas conocen el estado de un sistema porque lo diseñaron ellos, o peculiaridades de una integración que no están documentadas porque es conocimiento tribal.
Para ello es muy importante tomarle el pulso al equipo, ver cómo están hablando, cómo se están comunicando y encontrar los mejores canales para ello, wikis, sistemas de tareas, repositorios y otros mecanismos más allá de reuniones, chats o email.
Equipos remotos y la ley de Conway
La importancia de mantener unos niveles de comunicación adecuados en un equipo va más allá de que sea más sencillo seguir el rastro a tareas, de que el equipo no tenga que estar preocupado de lo que va a decir en la standup, o que las reuniones de sincronización se extiendan durante varias horas hasta que el estado quede claro.
De acuerdo con la ley de Conway, esto afecta directamente a cómo producimos el software en nuestras organizaciones:
Las organizaciones dedicadas al diseño de sistemas […] están abocadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones
Melvin Conway
Por tanto, si formamos parte de equipos remotos y nuestra estructura de comunicación es pública y asíncrona acabaremos haciendo mejor software.
Conclusiones
Tenemos muchos sistemas a nuestra disposición para compartir el estado de nuestras tareas más allá de una reunión de 15 minutos en la que cada miembro del equipo tiene 30 segundos para hablar.
Compartir información de tal manera que no necesitemos a todos los miembros del equipo presentes a la misma vez nos permite ganar tiempo, ya que la información se mantiene en un punto común y de manera estable, especialmente a la hora de tomar decisiones, documentando las decisiones tomadas y las razones para las mismas.
Mantener la información públicamente accesible y simplificar canales de comunicación sencillos permite mitigar la aparición de silos de información, en las que solamente un subconjunto del equipo conozcan cierta información que todos deberían conocer.
Conseguir un sistema que permita que el estado esté fácilmente disponible, y que los canales de comunicación estén claros, no solamente afecta a la actitud del equipo, sino que tiene un impacto directo sobre el software que producimos.
Lecturas adicionales
Pablo escribió un artículo en su blog en el que habla de estos temas y los desarrolla con un gran nivel de detalle, además durante el evento mencionó el Remote Manifesto de Gitlab, y la teoría de las limitaciones (theory of constraints) que se hizo conocida en el ibro The Goal y que se ha llevado al campo de IT en el libro The Phoenix Project, que comenté el pasado año.
En nuestro día a día empleamos múltiples niveles de abstracción para referirnos a los sistemas de información que construimos, manipulamos o mantenemos, nos referimos a sistemas, aplicaciones, servicios, APIs, llamadas, funciones, almacenamiento, memoria, ficheros, eventos, etc.
Muchas de estas abstracciones las comentamos de manera informal, las describimos a través del código que escribimos y que ejecutamos, las describimos en prosa, o empleamos la herramienta favorita de los arquitectos y la más temida por los desarrolladores, los diagramas.
Un diagrama, ya sea de componentes, de secuencia, de interacción o de clases, no es más que otra abstracción en la que describimos como es o cómo pretendemos que sea nuestro sistema. El diagrama nos puede permitir pasar por ciertas capas de descubrimiento, descubrir o fijar los límites de nuestro servicio en comparación con otros, y es una herramienta que nos permite mantener una conversación.
Esta herramienta es crítica cuando tenemos que interactuar con otros equipos, o compañeros que pueden no tener todo el contexto. Es por ello que es importante tener en cuenta el público, el objetivo, y el nivel de abstracción que queremos mantener. al crear dichos diagramas y representar contextos
Una metodología para la representación de diagramas que he estado poniendo en práctica recientemente es el modelo C4 por Simon Brown, en el cual, siguiendo ciertas prácticas e iterando sobre nuestros diagramas, podemos diseñar nuestro sistema utilizando varios niveles de abstracción:
Contexto
Contenedor
Componente
Código
Pese a que el modelo define 4 capas, en este artículo hablaremos de las tres capas superiores, ya que la cuarta se asemeja bastante a diagramas a los que podamos estar más familiarizados, y en ocasiones no es necesario ni siquiera llegar a ellas.
El ejemplo
A la hora de escribir el artículo pensé en algo del estilo “lista de tareas” dada mi obsesión por las aplicaciones, metodologías y otros, pero al final me decanté por un sistema que me permitiera escribir artículos en un blog.
Los requisitos son los siguientes:
Un lector puede ver artículos publicados y escribir comentarios.
Un autor puede escribir artículos, editarlos y borrarlos
Un autor, además, recibirá una notificación cuando se cree un nuevo comentario.
Vayamos manos a la obra:
Nivel 0: Contexto
A este nivel queremos definir de manera clara quienes son los actores que interactúan con nuestro sistema, qué sistemas tenemos, y una primera idea de cómo se relacionan entre ellos.
A este nivel podemos tener una conversación con un potencial usuario del sistema, o con nuestros compañeros de negocio, ya que los casos de uso generales se definen aquí.
Es también una oportunidad para destacar qué queda fuera del sistema, y hasta qué punto se pueden modificar esos sistemas. Podemos utilizar esquemas de colores para destacar qué sistemas podemos y cuales no podemos modificar.
Nivel 1: Contenedores
En este caso hacemos zoom en cada uno de los sistemas, y lo separamos en contenedores que tienen una función lógica. En el caso de nuestro blog tenemos dos subsistemas diferentes, uno encargado de la edición de artículos y otro de la visualización, así como una API entre la que interactúan ambos sistemas.
A este nivel podemos tener conversaciones a nivel técnico con diferentes equipos involucrados en el proyecto, el nivel de abstracción es menor, y podemos tomar decisiones como cuantos subsistemas construimos y cómo se reparte el trabajo de los mismos.
Nivel 2: Componentes
Este nivel es el más profundo al que llegaremos en este artículo, aquí podemos establecer una separación más clara, en el caso de la UI podemos separar las diferentes páginas que existirán, y en el caso de la API backend los diferentes componentes que podemos emplear, en el que cada componente puede ser una librería, un paquete, un proyecto o una unidad semántica de código.
En este nivel podemos tomar decisiones de arquitectura directamente a nivel de equipo, entender las diferentes relaciones entre los diferentes componentes y modularizar más, si fuese necesario.
Evolución
Una de las características más interesantes de este estilo de modelado es que es iterativo, una vez que empiezas y vas pasando por las diferentes capas descubres que estabas empleando el modelo erróneo de abstracción, y mueves “cajitas” entre las diferentes capas.
El primer diagrama que hagamos nunca será perfecto, pero el hecho de tener tres diagramas diferentes e iterar entre ellos nos permitirá descubrir nuestra arquitectura, encontrar límites y tener una mejor idea del alcance de los productos que vamos a construir.
Desde el punto de vista práctico, recomiendo utilizar una herramienta que nos permita tener los tres tipos de diagramas visibles a la vez, ya que nos veremos en la situación de estar cambiando componentes entre los diferentes niveles de abstracción.
Retrospección
Podemos utilizar estos diagramas no solamente como una manera de crear software, sino también de familiarizarnos con software existente. A la hora de enfrentarnos a un nuevo proyecto, entender el sistema en el que nos encontramos nos permite mitigar el factor ”Pulpo en garaje” y ser más productivos desde el principio.
Conclusiones
En general los diagramas son otra herramienta que podemos utilizar tanto para descubrir, explorar o enterarnos de donde nos hemos metido, no son el fin, ni mucho menos, sino un medio para construir mejores sistemas. Metodologías como C4 nos permiten crear mejores diagramas y con ello, mejores sistemas.
Soy de esas personas que, además de tener libros en casa que no han empezado, tengo muchos que empiezo y dejo por la mitad. En este mes de marzo he intentado ponerme al día en los libros que tengo empezados, algunos de ellos he tenido que volver a empezar desde el principio pero otros los he retomado por donde estaba.
Uno de los libros que he retomado es ¿Cuando?, de Daniel H. Pink (When: The Scientific Secrets of Perfect Timing en su versión en inglés).
Es un libro que habla de muchas cosas, pero sobre todo es un libro que habla del tiempo, desde la manera en la que somos productivos a lo largo del día, la diferencia entre búhos y alondras, pasando por los principios, los intermedios y los finales, hasta temas como el concepto del tiempo y del futuro, que no está presente de manera tan fuerte en todos los lenguajes y modifica no solamente la manera de interactuar, sino la manera de ver el mundo.
El libro se divide en tres bloques. Cada bloque, además, consta de una parte que podríamos denominar teórica o divulgativa, y una parte más práctica que Daniel denomina “Manual del Hacker del Tiempo” con consejos prácticos para poner en uso lo enseñado en el apartado anterior.
El día: En ella habla de cómo definimos nuestro día, cómo y cuando dormimos, cómo algunos somos de levantarnos pronto y otros de quedarnos hasta tarde, cómo afecta eso a nuestras decisiones, y cuando tomar decisiones importantes.
Comienzos, finales y mitades: En este bloque habla de diferentes tipos de comienzo, la importante de volver a empezar en algunos momentos de nuestra vida, la importancia de los finales, de por qué hacemos locuras o cosas intensas en el último año de cada década o cómo varían las relaciones entre la edad adulta y la vejez.
Sincronizar y pensar: Finalmente, usando como ejemplos a los dabbawalas, los miembros de un coro, y de un equipo de remo, habla de la importancia y la necesidad de mantener sincronía con aquello que marca el tiempo (que puede ser una persona, un reloj, una situación), sincronía con el grupo y finalmente, lo que denomina sincronía del corazón, es decir, la razón última de por qué hacemos las cosas, en el coro puede ser por motivos religiosos, en el remo por el esfuerzo conjunto, y en el caso de los dabbawalas, por la importancia de lo que están transportando, comida hecha en casa.
Un libro interesante, que te puede hacer pensar y reflexionar, siendo mi parte favorita la de los comienzos, finales y mitades. Todo lo que hacemos, inexorablemente tiene un principio, una mitad, y un final, como también lo tiene este artículo que comparto contigo, querido lector.
Procrastinar Del lat.procrastināre. 1. tr. Diferir, aplazar.
RAE
Una de las cosas que intento hacer siempre que estoy en un aeropuerto es pasar por la sección de libros de las tiendas de Duty Free, si veo algo interesante en un idioma que entiendo y me puedo beneficiar de algún cambio de moneda, no lo dudo y compro un ejemplar, aunque tenga una pila infinita de libros por leer, con la errónea suposición de que leeré el libro mientras vuelo.
Así, casi dos meses después de su compra, te traigo “The End of Procrastination”, un libro corto (apenas 240 páginas de contenido) y pequeño que nos trae algunos trucos sobre cómo combatir la tendencia que tenemos algunos de postergar cosas, especialmente si son importantes o aburridas.
En un formato diferente a otros libros (cuadrado para ser exactos) y lleno de ayudas visuales, el libro nos provee con varias herramientas para intentar superarnos poco a poco.
Partiendo de un análisis personal, utilizando métodos como SWOT o DAFO para ver cuales son nuestras fortalezas y debilidades, una lista de lo que creemos que puedan ser nuestros mayores logros, así como una visión personal, podemos tener una idea más realista de donde estamos y a donde queremos llegar, siendo el principal objetivo limitar el espectro de opciones a nuestro alcance a aquellas que nos ayuden a lograr esa visión, ya que está demostrado que tener demasiadas opciones bloquea nuestra capacidad de elegir, y ante la frustración de no poder elegir, elegimos no hacer nada.
A partir de ahí, el libro pasa a temas más de nuestro día a día, como mantener actualizada una lista de hábitos, planificar las tareas diarias de manera visual, encadenando unas con otras y agregando marcadores de importancia, maneras de organizar aquellas tareas que no requieren acción inmediata, cómo tener listas de ideas en las cuales actuar a futuro, y cómo salir de nuestra zona de confort para poder hacer más.
Finalmente, el libro pasa a temas más complejos, como qué pasa cuando nos vemos en una situación de bloqueo, en el cual nos vemos atados a un presente o a una situación pasada negativa y no podemos salir de ahí, mencionando cómo tenemos el control sobre la manera en la que respondemos a estímulos, por mucho que puedan ser negativos, o cómo mantener una lista de cosas positivas que han pasado durante el día (otros autores lo mencionan como las tres gratitudes)
Personalmente me ha gustado el formato, aunque, tras haberlo intentado, no esté del todo convencido del formato de organización de tareas diarias, para ello me quedo con el método de Cal Newport que recomienda tanto en su blog Deep Habits: The Importance of Planning Every Minute of Your Work Day como en su libro Deep work, que ya comenté en este blog en 2016.
rlbisbe @ dev 