Conferencia BilboStack 2019

La octava edición de la BilboStack sigue fiel a su cita en el calendario a finales de enero como en anteriores ocasiones. Tampoco cambia el formato de cuatro presentaciones en dos tracks simultáneos y de ser únicamente de media jornada a la mañana par disfrutar a la tarde del networking, comida y de Bilbao para aquellos que así quieran y aprovechar el viaje si se viene de fuera. Tampoco cambia el recinto como en la edición anterior de el Palacio Euskalduna, con un aforo bastante amplio aún así las entradas han llegado a agotarse y no han quedado prácticamente sitios libres en la sala A3.

La novedad más relevante de este año es que por primera vez las entradas han tenido un precio muy módico que no llega a los 15 € por asistente que junto a los patrocinadores permitirá a la organización cubrir en parte algunos costes como viajes de los ponentes, alojamiento, comida, recinto, etc. Otra novedad es que en el descanso después de las dos primeras presentaciones ha habido café y de comer para acompañarlo junto a los stands de varios de los patrocinadores para hacer contactos en el networking.

La conferencia comienza con la presentación y la bienvenida de los organizadores junto con unas palabras de Xabier Otxandiano concejal de desarrollo económico del ayuntamiento de Bilbao comentando la transformación que ha realizado la ciudad en las últimas décadas, urbanística siendo representante el propio palacio Euskalduna de un entorno más industrial a otro más de servicios y la importancia de la tecnología con el potencial para convertirse en la nueva industria de la ciudad. Por este motivo la conferencia BilboStack es importante y lo apoyan de forma institucional haciendo hincapié que no es fácil organizar una conferencia con el poder de convocatoria de casi 700 personas un sábado a la mañana y a la que muchos acuden haciendo muchos kilómetros de viaje.

La agenda comienza a las 9:00 de la mañana del sábado con una presentación y terminaba a las 14:00 aunque por el control de acceso de este año ha sido recomendable llegar un poco antes para evitar alguna pequeña aglomeración en los últimos minutos y encontrar y entrar en las salas con suficiente antelación. Llega el momento de decidir a qué presentación de los dos tracks asistir, dependiendo de los intereses de cada uno a veces no es fácil y uno quisiera haber asistido a las dos.

Hora	Sala Barria
09:00-09:20	Presentación
09:30-10:20	Kubernetes is not a deployment tool: it's a platform por Jose Armesto
10:30-11:20	Come reza data por Inés Huertas
11:30-12:00	Networking + Café
12:00-12:50	Devops is not what you think por Eduardo Ferro
13:00-13:50	10 retos de la creación de chatbots y asistentes con NLP por Cristina Santamarina
> 14:00	Networking + pintxos y poteo

Hora	Sala A3
09:00-09:20	Presentación
09:30-10:20	Web Components API: esto va en serio por Belén Albeza
10:30-11:20	Agile JavaScript por Ricardo Borillo
11:30-12:00	Networking + Café
12:00-12:50	UX para desarrolladores front y back por Virginia Aguirre
13:00-13:50	Viaje desde Arquitectura Hexagonal al Event Sourcing por Carlos Buenosvinos
> 14:00	Networking + pintxos y poteo

Cómo ocasiones anteriores hago un compendio de las ideas con las que me quedé de las presentaciones a las que asistí, seguro que me dejo cosas de las comentadas.

Web Components API: esto va en serio por Belén Albeza

Desde los inicios la web está formada por dos elementos el protocolo HTTP y los documentos HTML con el contenido. Con el paso del tiempo las páginas añadieron CSS y comportamiento con el lenguaje JavaScript. En gran medida las bases iniciales no han cambiado y una página de hace 20 años se verán igualmente en un navegador actual, al contrario que las aplicaciones nativas que pueden dejar de funcionar con actualizaciones de dispositivos móviles en un lustro.

Los Web Components son una especificación que están implementando la navegadores y es la alternativa estándar que cubre algunos aspectos de las populares librerías JavaScript como React y Vue. Estas aportan estructura al JavaScript y permiten crear componentes que por defecto loa navegadores no ofrecen como un calendario o menús.

Web Components permite crear etiquetas propias y ser usadas en los documentos HTML como si de cualquier otra etiqueta estándar se tratase. Los web componentes se componen de un nombre, atributos y los eventos que lanza. Con la API de los Web componentes se proporciona el HTML que genera un componente, el comportamiento con JavaScript y las clases CSS que le aplican.

Las especificación es de los Web Components son varias. Una de las cosas que aportan los web components es que el CSS de estos no entren en colisión con cualquier otro CSS de la página o de otros web componentes.

En las DevTools de Firefox se puede inspeccionar el shadow DOM del web componentes. En la documentación de MDN hay varias páginas que detallan los Web Components con ejemplos.

Tenía claro que quería acudir a esta presentación, era una en la que no tenía muchas dudas al elegir por quien la daba @ladybenko, desarrolladora de Firefox, es el nivel que hay en los ponentes de la BilboStack. Comenzaba la mañana posponiendo la alarma del despertador varias veces pero solo por esta presentación ya ha merecido el levantarme para acudir a la BilboStack.

Agile JavaScript por Ricardo Borillo

En el State of JavaScript del 2018 se mencionan numerosas herramientas de JavaScript más populares del momento y otras nuevas que están surgiendo como alternativa.

Entre las que se mencionan, no son pocas, están npm, nvm, Node.js, Webpack, Babel, Parcel, Rollup, Eslint, Prettier, Flow, TypeScript, Reason.

Esta presentación junto con la anterior forman la representación de JavaScript que siempre tiene la BilboStack y es que muchos lo utilizamos en mayor o menor medida.

Descanso

No saque fotos pero algunos patrocinadores dispusieron stands en los que hacerse con algunas pegatinas y bagatelas, de las empresas una oportunidad de conocerlas e iniciar algún contacto.

UX para desarrolladores front y back por Virginia Aguirre

A veces hay más atención puesta en la tecnología que en la experiencia de usuario y en estos casos ocurren ejemplos como el Nokia Ngage con su peculiar forma para hacer llamadas, aplicaciones con gran cantidad de barras de herramientas que ocupan gran parte del espacio vertical de la pantalla o el incómodo menú inicio de Windows 8 más adaptado a interfaces táctiles que a escritorio. La UX hace hincapié en las necesidades del usuario primero, las necesidades del negocio y finalmente las posibilidades técnicas, el orden es importante.

UX aplicado es que el usuario pueda ver como quedan los muebles antes de comprarlos, ante esta necesidad del usuario Ikea desarrolla una aplicación de realidad aumentada que permite ver con la cámara del móvil una representación del mueble en la pantalla con la imagen del salón captada por la cámara. Otro ejemplo de uso es encontrar la gasolinera más cercana aprovechando la geolocalización de los móviles, dado que el contexto es uno de estar conduciendo la aplicación no ha de ser interactiva como es el caso de mostrar un mapa del país en el que ver las gasolineras y buscar entre ellas la más cercana. Con la geolocalización la aplicación ya puede conocer la ubicación del usuario y mostrar la más cercana que será el caso de uso más habitual.

En UX hay múltiples factores usuario, sociales, culturales, contexto de uso (casa, coche, móvil, escritorio) y el producto. Hay que entender el problema para proporcionar una solución efectiva, la solución puede desarrollarse de forma iterativa. Obtener información de los usuarios puede hacerse con analítica web, del departamento de atención al cliente, de formularios de encuestas, de noticias, informes sectoriales o analizando que hace la competencia.

De las que he asistido esta y la del otro track era la presentación que podría haber asistido a cualquiera, en cualquier caso siempre se descubre algún detalle interesante, como programador en mi caso varios puntos interesantes.

Viaje desde Arquitectura Hexagonal al Event Sourcing por Carlos Buenosvinos

Las arquitecturas pueden evolucionar en seis niveles.

1. Spaghetti
2. Framework
3. Hexagonal
4. Hexagonal + Domain Event
5. CQRS
6. Event Sourcing

Estar en el nivel 3 y 4 probablemente para muchas aplicaciones ya sea suficiente. En las 1 no hay estructura y con el paso del tiempo añadir nuevas características se hace más difícil y el código más difícil de mantener. La 2 añade estructura al código pero lo hace dependiente del framework en forma de acoplamiento. Con hexagonal se trata de independizar la lógica de negocio del código de infraestructura entendiendo por infraestructura la parte ajena al modelo como es el caso del sistema de persistencia en concreto que se utilice, para el negocio que sea una base de datos relacional o NoSQL es indiferente. Con una arquitectura hexagonal se separan aspectos, se independiza del framework y retrasan las decisiones de infraestructura.

Hay funcionalidades que no forman parte del núcleo del negocio. Estas funcionalidades se pueden realizar al reaccionar a esos eventos, registrados en elastic search o rabbit se obtienen métricas en tiempo real de lo que sucede en la aplicación. Al mostrar una página la cantidad de información puede generar unas decenas o cientos de consultas a la base de datos y a medida que se añaden funcionalidades e información la página irá más lenta. Cuando se modifica una entidad se dispara un evento que un listener escucha y se encarga de recuperar la información actualizada y guardarla transformada según las necesidades de lectura para que con una consulta se obtenga toda toda la información de la entidad, en este momento el rendimiento de la aplicación no se degrada al añadir nuevas características. En este sistema donde las consultas y modificaciones están separadas, con la serie de eventos que provocan cambios se puede reconstruir el estado final de una entidad aplicando la serie de eventos que sucedieron secuencialmente.