BilboStack 2018 en mi mochila

La conferencia BilboStack, para aquellos “rookies” interesados en el artículo, aclarar que se trata de un evento donde profesionales nacionales e internacionales prestan su conocimiento al servicio de la comunidad tecnológica con discursos muy pintorescos consolidados a partir de las últimas tendencias.

BilboStack ha citado en la mañana del 27 de enero a cerca de 500 personas en el Palacio Euskalduna de Bilbao. Con una agenda compuesta de dos tracks, donde cada uno abarcaba cuatro presentaciones.

Como no podía ser de otra manera, el equipo de Irontec no podía faltar, dado que ponemos en gran estima todo aquello que sea enriquecedor profesional y personalmente. Os aseguro que el pin que me pusieron a la entrada y que me permitía gozar de un descuento en los bares de la Plaza Nueva, no tuvo nada que ver (guiño, guiño).

Ha sido una jornada intensa, divertida y apasionante. Tanto es así, que vengo con la intención de compartir impresiones y tips que he guardado en mi mochila y llevaré siempre conmigo.

“Lo que no se Vue” por Angélica Lozano

Angélica acudió a BilboStack para compartir su experiencia con una aplicación orientada a la automoción, donde al frontend nunca se le dio cariño, mientras que la satisfacción de los usuarios está en el punto de mira. Llegados a esta situación, el equipo toma la decisión de romper con la incongruencia gracias al desacoplamiento de frontend y backend, y vistas responsivas.

Entonces, llega el momento de mayor incertidumbre y que a todos nos produce gran expectación (redoble de tambores, por favor), ¡la elección del framework!

vue.js

Un poco a ciegas, optaron por Vue.js. Angélica afirma que en el equipo de desarrollo tienen un ninja de React que no se revolvió mucho ante la decisión, de forma que entendieron que iban por buen camino.

Vue es un framework progresivo que podemos usar tanto para cosas muy básicas (jQuery) como para algo más complejo como el desarrollo de una SPA (Single Page Application). Permite ir usando librerías a medida que se necesitan: vue-router (enrutador), directivas (manipulación HTML), vuex (patrón Flux), vuetify (Material Design).

Vue está orientado a componentes, paradigma muy extendido en el desarrollo web que permite un alto nivel de escalabilidad y desacoplamiento. Para facilitar la implementación basada en componentes, surgen los Vue templates. Nos permiten declarar nuestro HTML, CSS y código JavaScript en un mismo archivo orientado a un componente concreto, de manera similar a Polymer.

Gracias a Vue podemos estructurar nuestra aplicación al igual que en React, Angular o en Polymer, bajo demanda y siempre con un rendimiento y experiencia de desarrollo muy buena.

Según Angélica, Vue tiene una curva de aprendizaje muy alta, en poco tiempo se aprende mucho. Esto supone una ventaja competitiva, dado que permite incorporar rápidamente al equipo diferentes perfiles sin necesidad de que sean expertos.

Eskerrik asko Angélica, me has convencido para probarlo. Incluso, me has convencido para persuadir a los iron-mates más intrépidos de arrancar futuros proyectos. Dado que en Irontec nos hemos habituado a construir proyectos de front-end haciendo uso de Angular, pero en realidad somos unos culos inquietos.

Para aquellos que se identifiquen con nosotros, os dejo un par de enlaces a nuestro blog que describen primeras tomas de contacto con Angular y características más avanzadas .

Para vosotros jugadores.

“Refactoring Mount Doom” por Franziska Sauerwein

Puedo imaginar que a muchos de los presentes (y no presentes) en BilboStack os habrá tocado lidiar con código legacy o heredado. No es que me lo hayáis contado, es que la mayoría de los asistentes levantó la mano. Yo entre ellos.

No es una tarea fácil, pero me produce gran satisfacción cuando logro hacer magia a golpe de teclado.

Dado mi afán por la magia, me suscitaba especial interés asistir a la presentación y conocer cómo una verdadera experta es capaz de sacar conejos blancos de su chistera.

Entonces, me sorprendió gratamente descubrir que no era maga, sino una turista perdida de excursión por el monte. Pero no cualquier monte, sino el mismísimo Mount Doom. Muy buena metáfora Franzi.

Imaginémonos por un momento extraviados en Mount Doom. Nuestra primera premisa siempre se argumenta en el cómo y el por qué, y la reacción más obvia es la búsqueda de culpables.

No debemos caer en la trampa, los implicados seguramente hicieron todo aquello que estaba en sus manos, pero nadie es perfecto, ¿o sí?. Si retornamos al pasado, nosotros mismos habremos sido parte del problema, hemos estado sometidos a imposiciones de fechas irrealistas en deadlines, los requisitos no estaban claros y carecíamos de habilidades y conocimientos que ahora poseemos.

Entonces, comprendemos que debemos dejar de pensar en la causa y centrarnos en los instrumentos que nos permiten alcanzar nuestro objetivo, modificar sin cambiar el comportamiento observado: mapas (documentación), seguridad (teses, buen ambiente de trabajo), herramientas y provisiones (IDE, habilidades) y un guía (product manager).

Refactoring Mount Doom

Franzi nos revela buenas prácticas de las cuales no debemos perder el foco:

  • Mikado method: establecer un objetivo, experimentar, visualizar y deshacer. Keep calm and Ctrl-F.
  • Exploratory testing: el aprendizaje, diseño y ejecución de las pruebas se ejecutan de forma simultánea.

Llegados a este punto, somos capaces de sacar conejos blancos de nuestra chistera. Pero queremos más, queremos tomar el té con la Liebre de Marzo en el país de las maravillas. ¿Cómo mejoramos? Es preciso someternos a una mejora continua a través del aprendizaje, enseñanza, exploración y comprensión. Ahora sí, bienvenidos al feliz no cumpleaños.

Recordad que tenéis la presentación pública a vuestra disposición, no os quedéis con las ganas de degustarla.

“Machine Learning, camino a Skynet” por Beatriz Martín

Sé que todos me odiaréis cuando admita que no reconocí a Skynet hasta la diapositiva en la cual aparecía, pero que no os impida continuar leyendo, porque se pone realmente interesante.

Beatriz se presentó en BilboStack como una forofa de la Inteligencia Artificial (IA) dispuesta a transmitirnos lo que para ella representa. Nos aclara uno de los grandes errores que todos cometemos, Machine Learning (ML) no es lo mismo que IA, sino que pertenece a la misma. ML es una disciplina que crea sistemas que aprenden automáticamente. Lo cual implica, que automáticamente, estos sistemas se mejoran de forma autónoma con el tiempo, sin intervención humana.

En primera instancia, la IA se relacionaba a las películas de ciencia ficción. Pero en la actualidad constituye una realidad. La IA está transformando nuestra manera de interactuar con el mundo. Sin ir más lejos, las lavadoras aplican lógica difusa para controlar el nivel de agua en relación a la cantidad de ropa. Una locura, ¿no os parece?

Del mismo modo, está revolucionando la forma de trabajar de las empresas, considerando la IA como una ventaja competitiva. Incluso Google, ha cambiado su discurso de ‘mobile first’ a ‘AI first‘. Y por supuesto, el grupo Gartner, no podía quedarse rezagado, y presenta la IA en las cinco fases de su ciclo de sobreexpectación. De hecho, Gartner predice que en 2020, la IA será tan buena creando realidad falsa que ni la IA sabrá detectarla. Un apunte que a mi me deja los pelos de punta.

Existen tres niveles de IA:

  •  ANI: Artificial Narrow Intelligence (débil)
  • AGI: Artificial General Intelligence (general)
  • ASI: Artificial Super Intelligence (singularidad)

Llegados a este punto, os lanzo dos preguntas: ¿en qué nivel nos encontramos actualmente? No contestes aún, tómate tu tiempo y piensa … ¿a qué nivel se encuentra Siri? Aunque sofisticado, Siri es un ejemplo del primer nivel, el asistente por excelencia desde mi humilde opinión (no me odiéis más), opera dentro de un rango limitado previamente definido, no hay ninguna inteligencia genuina, sin conciencia, sin vida.

Para llegar al segundo nivel, necesitamos lograr más inteligencia. Existen tres vertientes para alcanzar el objetivo:

  • Estimular evolución: algoritmos genéticos simulando la evolución
  • Inteligencia inversa: Replicar el cerebro humano de forma digital
  • La IA creará la IA: El aprendizaje como lanzadera de la AGI.

Beatriz apuesta por la última vertiente y yo me subo al carro. Me puedo justificar, porque así lo declara Google (señores superlistos con toboganes y mini-golf en sus oficinas). Google dice haber creado una IA capaz de diseñar otros modelos de IA superiores a los modelos creados por los humanos: NASNet.

skynet

¿No he conseguido impresionaros todavía? Los expertos declaran que una vez alcanzado el segundo nivel, la progresión en el campo de la IA es exponencial, de forma que antes de lo que imaginamos (2040-2060), habremos llegado a la singularidad: Skynet.

Resulta emocionante y me genera grandes expectativas creer que seremos testigos de la llegada de Skynet a nuestras vidas, pero, ¿estamos realmente preparados para afrontar un avance de tal envergadura? Abierto queda uno de los debates más interesantes surgidos durante el evento.

No olvidéis echar un ojo a la presentación publicada, merece la pena.

“Evitando el efecto dominó en nuestros (micro)servicios” por Javi Ferrer y Rafa Gómez

¿Es posible que la adición de un parámetro al JSON de respuesta de una petición HTTP produzca un auténtico apocalipsis zombie? Así nos lo demuestraron Javi y Rafa en esta edición de BilboStack.

Habían construido de una aplicación de compartición de vídeos orientada al campo de la informática y querían introducir un nuevo caso de uso: visualizar el número de vídeos creados por un usuario en su perfil.
Parece tan fácil como robarle un caramelo a un niño, pues, nada más lejos de la realidad, se toparon con Maggie Simpson.

Satisfechos con su nueva funcionalidad, se quedaron sin blanca añadiendo un anuncio en Netflix que supondría su estrategia de ‘EXIT’. Pero la aplicación monolítica no era capaz de responder a los 1000 usuarios simultáneos generando nuevos vídeos y en consecuencia, tampoco a las peticiones de visualización de perfiles que mostraban el número de los mismos.
Ciertamente la arquitectura monolitica tiene sus ventajas, el código centralizado es más fácil de testear, pero no es escalable a ningún nivel (desarrollo, aplicación e infraestructura).

¿Y ahora qué? Arquitectura de microlito, separar el servicio orientado a usuarios y a vídeos en dos máquinas apuntando a la misma BD. Aunque se solventan los problemas de escalabilidad a nivel de desarrollo y aplicación, se mantiene el problema de escalabilidad de infraestructura, dado que la BD establece el cuello de botella.

¿Y ahora qué? Arquitectura de microlitos acoplados, basándonos en la arquitectura anterior, añadimos una nueva BD y conectamos los microlitos a nivel de aplicación, realizando peticiones HTTP para actualizar los datos. Aunque el sistema está totalmente desacoplado, seguimos sobrecargando la BD orientada a los vídeos y añadimos latencia entre servidores.

¿Qué hay de nuevo, viejo? DIP (Principio de Inversión de Dependencias) de SOLID para la interacción del dominio con el resto de elementos.
¿Cómo te quedas? Yo como desarrolladora front-end, como un pulpo en un garaje.
Aunque no es la primera vez que escucho el concepto, sí es la primera vez que lo entiendo.
Javi y Rafa hacen una analogía de DIP con las interfaces que utilizamos para abstraer a nuestro dominio de las implementaciones de elementos externos, como pueden ser las BD.

Aplicado a la arquitectura, una de las formas que pueden tomar las interfaces son los eventos de dominio. Los eventos se gestionan a través de un sistema de colas para conectarse a la aplicación, donde un sistema se encarga de publicar los eventos en la cola y el resto de sistemas se suscriben a dicha cola para consumir la información.

BilboStack 2018: Evitando el efecto dominó en nuestros (micro)servicios

Evitando el efecto dominó en nuestros (micro)servicios

A la hora de poner en práctica la teoría, utilizan RabbitMQ como sistema de mensajes y colas. Estos sistemas permiten:

  • Elasticidad: cuando el sistema llega a su capacidad de recepción de peticiones y se vuelve incapaz de responder, la cola de peticiones permite balancear, filtrar y normalizar el flujo, evitando la pérdida de mensajes o el colapso del sistema.
  • Tolerancia a fallos: si parte de tu arquitectura falla, los mensajes no se pierden, siguen en la cola. Asimismo, la cola sigue recibiendo mensajes para el procesamiento posterior a la recuperación del sistema.
  • Arquitectura abierta a extensión: si se quiere desarrollar una nueva funcionalidad asociada a un evento solo hay que crear una nueva cola y la nueva funcionalidad en el consumidor.

Aún así, no es oro todo lo que reluce, y nos advierten sobre la posibilidad de duplicidades y que no se garantiza el orden en la recepción de los mensajes.

De todos modos, a mí me han conquistado y creo que estoy tardando en crearme una cuenta en CodelyTV.

No dejéis de curiosear la presentación que Javi Ferrer y Rafa Gómez expusieron en Bilbostack, merece invertir unos minutos en ella.

Conclusiones de nuestro paso por BilboStack 2018

Mi percepción de BilboStack 2018: un sábado muy bien invertido. No por los vinos y cervecitas de después, sino por la gran diversidad en las temáticas de las charlas, cargadas de contenidos enriquecedores y merecedoras de la atención prestada. Donde los ponentes muy cercanos a los espectadores, manejaron un lenguaje asequible para todos los públicos, a pesar de su gran trayectoria y experiencia en los temas que exponían.

En definitiva, un lujo poder guardar en mi mochila todo lo que he compartido con vosotros, y ases que me guardo bajo la manga. Ya os dije que era maga.

Y como no puede ser de otra manera, el equipo de Irontec no puede faltar a la próxima jornada de BilboStack 2019. Os esperamos con los brazos abiertos. ¡Que no os lo cuenten!



¿Te gusta este post? Es solo un ejemplo de cómo podemos ayudar a tu empresa...
Sobre

Desarrolladora front-end seducida por el diseño, apasionada por las buenas prácticas y como no, con Octocat de mascota.

Queremos tu opinión :)