Conferencia BilboStack 2018

A diferencia de los seis años anteriores este la BilboStack ha tenido lugar en el Palacio Euskalduna en vez de la Universidad de Deusto permitiendo un aforo aún mayor que el de la universidad y con unas salas más grandes y butacas más cómodas que las espartanas sillas de la uni en las que igualmente si se ponía atención y luego esfuerzo se aprendían cosas interesantes, muchos hemos pasado varios años en ellas.

En la presentación inicial se ha comentado como se gestó la primera BilboStack. A la vuelta de otra conferencia los organizadores se preguntaron por que no organizar una ellos en Bilbao para no siempre ir a otras ciudades como Madrid o Barcelona.

Hasta el momento siempre se ha mantenido gratuita la entrada previa reserva pero este año con la ayuda de los patrocinadores han podido acceder a este gran recinto y costear el viaje a los ponentes, esto demuestra lo agradecidos que debemos estar a los de los años anteriores ya que además de hacer la presentación compartiendo su conocimiento se pagaban ellos mismos el viaje.

700 y pico entradas eran las que se han ofrecido, ni los organizadores creían que se iban a agotar y se jactaban de que habría entradas para todos en los primeros días de poner la primera oleada para la reserva, pues al final ni esas 700 parece que han estado sobradas. Sorprendente ya que en el 2016 los asistentes fueron 332, algo menos de la mitad del aforo de este año. 6 de las 8 presentaciones han sido dadas por mujeres y en años anteriores también ha habido presencia femenina tanto ponentes como asistentes.

Número de asistentes por año:

• 2012: 252
• 2013: 261
• 2014: 304
• 2015: 340
• 2016: 332
• 2017: ¿?
• 2018: 500

Por supuesto tener a disposición para la conferencia este recinto y los ponente sin que estos se paguen el viaje ha sido más fácil y posible gracias a los patrocinadores que además han ofrecido algunas pegatinas, cuadernillos, folletos a los asistentes e incluso ofertas laborales.

La agenda del evento en esta edición ha sido la siguiente, dos tracks con cuatro presentaciones en cada una de ellas, en formato de una mañana y el posterior postevento para el que desee.

Lo que no se Vue por Angélica Lozano

En una aplicación con algunos indicadores para el sector de la automoción en la que el front era «una puta chapuza» la replantean para permitir diferentes dispositivos y desacoplar el frontend y backend. Usando Vue las cosas se simplifican al usar sus componentes (componentes… de que me suena…) encapsulando la funcionalidad y utilizando un solo fichero en el que se incluye la plantilla para el HTML, el código JavaScript asociado y los estilos CSS.

Algunas de sus manías o recomendaciones son programar y dar nombres a las cosas en inglés (¿evitar el spanglish, más compacto que el español?, caracter ñ, …), conocer las herramientas que hace más simple el trabajo, usar poka-jokes al diseñar el código para no poder usarlo mal ni aposta, evitar sentencias if anidadas utilizando guard-clauses, utilizar una buena semántica según el área de dominio junto con una buena nomenclatura al asignar nombres o usar alguna herramienta para analizar que el código sigue las buenas prácticas adoptadas.

En las plantillas de Vue se usan algunas directivas como v-if, v-for o v-model para añadirles lógica o para pasar propiedades del componente padre al hijo, con eventos se puede pasar información del hijo al componente padre. Es un framework progresivo en el que se pueden ir usando cosas según se necesitan (vuex, vue-router, vuetify, vue-i18n).

Llevar el código a las fábricas de automoción es parte del desarrollo y para ello utilizan herramientas como Jenkins, Ansible y Docker.

Referencia:

• La Pull Request Perfecta
• Meetup Vuex, ¿para qué sirve? ¿lo necesito?
• Libro Desarrolla aplicaciones con Vue
• Curso Testing con Vuejs, CodelyTv Pro

CSS Grid Layout en acción por Diana Aceves

Mas que una charla ha sido una demostración de como implementar con CSS Grid una plantilla existente para Wordpress con once variaciones de layout, una columna y fila con un texto alineado horizontalmente y verticalmente, dos columnas, tres columnas, dos filas, dos filas dos columnas y así hasta once.

La especificación de CSS Grid es grande y parece complicada pero no hace falta conocerla entera ya que utilizando una pequeña parte y unas pocas propiedades ya es posible hacer cosas interesantes. En las herramientas para desarrolladores de Firefox hay un inspector especifico para los grids útil para depurar e inspeccionar los elementos.

Algunas de las propiedades de CSS Grid son:

• display: grid;
• grid-template-columns: 4em 4em 4em;
• grid-template-columns: 1fr 1fr 1fr;
• grid-template-rows: repeat(5, 4em);
• grid-gap: 4em;
• grid-row-gap: 4em;
• grid-column: 3;
• grid-row: 2;
• grid-row: span 2;
• grid-row: 1/span 2;
• grid-auto-flow: dense;

Ah! Que recuerdos de aquella época cuando se maquetaban con tablas e incluso tablas dentro de tablas y gifs de un pixel transparentes…, luego vinieron los divs y algunos floats, … las cosas han cambiado con CSS Grid y CSS Flexbox aunque los que no nos dedicamos específicamente al diseño o maquetación sobrevivimos con Bootstrap.

Referencia:

• CSS Grid Layout
• CSS Flexbox Layout
• Grid Auto-Placement Is Ready

Camino a producción por Mario Marin

Había oído algo de la tienda de componentes electrónicos para ordenadores PC Componentes que ahí está luchando con Amazon, nada más y nada menos, en este nicho de mercado. Es un ejemplo de éxito por como ha pasado de ser una tienda de barrio a convertirse en una de las web de referencia en internet del comercio electrónico. Algunos de sus números en el 2017 son:

• 314 millones de facturación
• 88 millones de sesiones
• 1,5 millones de pedidos
• 30 mil pedidos semanales

Evolucionan en la misma medida que crece el negocio por internet. Surgen necesidades y departamentos (atención al cliente, compras, devoluciones, …). El desarrollo y el mantenimiento se complica que acaba afectando a la rapidez del desarrollo. También se va acumulando la deuda técnica pero el negocio tiene que seguir funcionando, no se puede parar a resolverla o parar de crearla para llegar antes al mercado o no llegar más tarde que la competencia. El resultado es algo que no funciona bien con errores y que los sistemas a duras penas soportan.

En este punto es cuando empiezan a mejorar, aprendiendo cosas que antes no conocían a partir de como los demás con problemas similares los resuelven y que aplicándolas van solucionando algunos problemas. También contratando gente específica para desarrollo o sistemas y utilizando herramientas que faciliten el desarrollo como Bitbucket, JIRA, Git, Jenkins, Docker, PHPUnit, SonarQube, Selenium y New Relic.

Echando la vista atrás se ve lo que has mejorado y es satisfactorio, a pesar de que quedan muchas cosas por hacer.

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

Muchas aplicaciones empiezan siendo un monolito, sin embargo aún siendo más fáciles de saber como funcionan y de desarrollar nuevas características no están exentas de problemas como el escalado ante picos de tráfico o que cuando se cae deja de funcionar todo. Los microservicios tratan de solventar algunos de las deficiencias de los monolitos y permiten cosas como múltiples equipos para diferentes funcionalidades, trocear el monolito en partes más pequeñas, usar diferentes lenguajes de programación según se considere el más adecuado para cada parte y escalarlas individualmente.

Sin embargo, dividir la aplicación en dos no es suficiente ya que puede seguir estando acopladas en la base de datos si la comparten de modo que si una parte sufre un tráfico importante este puede afectar a la otra aplicación por competir con ella en el acceso a la base de datos. Crear dos bases de datos y que las aplicaciones se comuniquen mediante llamadas a una API, por ejemplo con un servicio REST, para acceder una a los datos de la otra sigue habiendo acoplamiento, si una parte falla afecta a la otra. Estas opciones siguen siendo un monolito, distribuido pero monolito.

Para eliminar este acoplamiento en la infraestructura de las aplicaciones se pueden aplicar los principios SOLID e inversión de dependencias que ya aplicamos en el código para no depender de una implementación concreta, creando una interfaz de repositorio y luego implementaciones de esta según se necesiten, una implementación del repositorio para guardar en base de datos u otra para enviar un correo electrónico. De esta forma se pueden añadir nuevas implementaciones con nuevas funcionalidades, el sistema está abierto a extensión sin necesidad de modificar el código existente.

A nivel de la infraestructura una forma de interfaz son los eventos, un sistema los publica y otro u otros suscritos a ellos los consumen. Utilizar un sistema de mensajes y colas como RabbitMQ permite desacoplar los servicios, si el consumidor de eventos cae los mensajes se siguen encolando y se volverán a procesar cuando el consumidor esté de nuevo en funcionamiento. Si se quiere desarrollar una nueva funcionalidad asociada a un evento solo hay que crear una nueva cola y el nuevo consumidor con su funcionalidad.

Aunque los microservicios solucionan algunos problemas de los monolitos traen consigo nuevo problemas como una consistencia eventual en las diferentes bases de datos que posee cada microservicio, también puede haber duplicados y no se garantiza el orden de los mensajes.

Cuando en diciembre se pusieron las entradas para reserva a no mucho tardar y con las ganas de ir a la conferencia estaba motivado para ir, en los días anteriores siempre da algo de pereza la asistencia ya que después de una semana de trabajo las ganas no son tantas de pasar la mañana o el día también con el mismo tema sin desconectar ni descansar, pero luego después de haber madrugado y las presentaciones queda una buena sensación y de haber merecido la pena el esfuerzo.