Conferencia BilboStack 2017

Cuando me inscribí en la BilboStack para reservar entrada no me llamaron mucho la atención las presentaciones del programa pero ya a una semana de decidir a cuales iba a ir definitivamente he tenido dificultades para elegir y en varios casos me hubiese gustado ir a las de los dos tracks. Como años anteriores la BilboStack se ha celebrado en Bilbao en el mismo emplazamiento de la Universidad de Deusto pero volviendo como en años precedentes al edificio de las ingenierías. Otro cambio ha sido que este año fueron cuatro presentaciones por track cuando en años anteriores fueron cinco.

El número de asistentes ha sido numeroso quedando algo de sitio libre en el track 2 que era un aula pero en la sala de conferencias del track 1 aunque tiene cómodas butacas salvo por su estrechez el sitio libre era inexistente de modo que en algunas presentaciones ha habido algunos asistentes que han debido estar de pie.

Este era el programa completo con su horario, temas muy distintos y variados como Xamarin, internet of things, el siempre presente JavaScript con Angular y Node, Lean Analytics y DDD entre algunos otros de la siguiente agenda:

Al igual que en ediciones previas hago un pequeño resumen de las presentaciones a las que asistí. Los resúmenes no le hace justicia a las grandes ponencias que fueron en realidad pero espero haber captado y transmitir aquí escuetamente las ideas básicas que se expusieron. Y con este es el tercer resumen consecutivo que escribo de la BilboStack, los anteriores (y posteriores que si tengo oportunidad espero escribir) de esta serie de artículos están al final de este artículo.

Invisible o desaparece… por Isabel Cabezas y Juliet Moreiro

El IoT o esos pequeños dispositivos que tienen conexión a internet están surgiendo como una forma de ayudarnos en algunas situaciones cotidianas como cambiar la ruta cuando hay un accidente para no llegar a un atasco o encender la calefacción antes de llegar a casa o antes de levantarnos, espejos que proporcionan información como notificaciones o el tiempo o un centro comercial que te posiciona y ofrece ofertas según la localización en la que estas y tus hábitos de consumo. Aparatos como Amazon Echo son asistentes a través de los cuales mediante comandos de voz podemos realizar acciones como pedir comida a domicilio.

Estos aparatos conectados a internet nos ofrecen una nuevo área posibilidades. Muestra de ellos es la demostración presentada que consistía en base a los mensajes escritos en Twitter iluminar una lámpara PLAYBULB con color verde si eran positivos, rojo si eran negativos y azul si eran neutros haciendo uso de Microsoft Cognitive Services y de algunas de sus APIs para evaluar el sentido de los mensajes. Por ejemplo el mensaje BilboStak is an awesome event! se evaluará como positivo y sumará a la media para que la lampara cambie a color verde.

El hardware era la propia lámpara y una placa de computación Intel Edison junto con un servicio en la nube de Azure pero perfectamente podría ser una Raspberry Pi u otra de las numerosas pequeñas placas que están surgiendo en este nuevo mercado. El código fuente del ejemplo está compartido en un repositorio de GitHub.

Érase una vez… el Design System por Naiara Abaroa

El diseño de una página es una parte importante de la misma, no considerarlo así seguramente nos encontremos con problemas.

1. Requiere de un conocimiento específico para hacerlo bien y esta es la habilidad que posee un front-designer.
2. Falta de arquitectura de CSS a pesar de que existen herramientas como Sass o less se sigue produciendo código espagueti.
3. Hay duplicidades y está poco estructurado.
4. Falta de coherencia en la tipografía, color, …
5. Problemas de especifidad al no considerar la evaluación en cascada y el orden de precedencia de inline, id, clases y elementos con lo que se ha de usar el denostado !important como último recurso.
6. Mezcla de varias convenciones, en el nombrado de elementos.

La solución es el Design System consiguiendo primero claridad, segundo eficiencia y finalmente «belleza». Siguiendo el Atomic Design se consigue una mayor reutilización y facilidad de mantenimiento combinándolo con herramientas como Sketch para el desarrollo de mockups.

Algunos recursos de diseño e implementaciones conocidas de Design Systems son:

• Material Design y su guía
• Lightning Design System
• Bootstrap
• Foundation
• Y el propio que ha comenzado a desarrollar Naiara, nakDS que ha compartido en su GitHub

Agile for scrummies por Jorge Uriarte

La situación respecto a las metodologías de desarrollo ha cambiado, hace 10 años había resistencia al cambio ahora se aplica pero tampoco resuelve mágicamente los problemas del desarrollo de todos los casos donde se usa.

Algunas esencias de scrum que permanecerán son:

• En el producto: no detallar en exceso el backlog ya que cambiará.
• En las historias: siendo completas, entregables individualmente y según el valor que aportan.
• En los equipos: siendo estos autoorganizados, multidisciplinares, alineados, dueños del proceso y autónomos.
• En las entregas: serán incrementales y continuas.
• En el proceso: no estará sacralizado y cambiará con el fin de mejorar al igual que tratan de conseguir las retrospectivas.

Un sistema ágil es una aproximación a la incertidumbre. Incertidumbre que siempre está presente en los desarrollos de software al tratar de responder preguntas como ¿que hay que hacer? ¿cuanto tiempo se tardará? ¿que tecnología se usará?. Para evitar los problemas que genera la incertidumbre un work in progress o WIP pequeño es un buen arma. Lo terminado elimina incertidumbres, se considera que es lo menos que se puede hacer ahora que de el máximo valor. Una consecuencia es que en el flujo de desarrollo habrá menos cosas pero pasando más rápido. Esto se resume en título del libro Stop Starting, Start Finishing! y que tiene la siguiente reseña.

This booklet tells the story of Justin - a project manager who achieved remarkable results with his team by doing very simple things! This guide covers the core concepts of Kanban for knowledge work, and shows how limiting your amount of work-in-progress can lead to getting things done better and faster.

La combinación de un WIP pequeño junto con un sistema pull en el que no se construye lo no necesario, no se prueba lo que no se puede entregar, no se desarrolla lo que no se puede probar y no se especifica lo no se puede desarrollar produce una reducción de tiempos de entrega, hay mayor predictibilidad y elimina rehacer trabajo.

Domain-Driven Design, uniendo negocio con el software por Gorka Laucirica y Beñat Espiña

El Domain-Driven Design o DDD se centra en el dominio de la aplicación, la lógica de negocio y lo que quiere el negocio de la aplicación.

Los modelos anémicos con getters y setters se consideran un antipatrón y hace que la lógica esté dispersa. En el patrón MVC los controladores pueden contener múltiples responsabilidades generando duplicidad de código. Aplicar los principios SOLID generan código limpio y una arquitectura hexagonal ayuda a no crear en la aplicación una dependencia con el framework posibilitando usar por ejemplo Symfony como herramienta y no como base.

DDD se divide en patrones estratégicos (bounded context) que no tienen código y tácticos (entities, agregados, eventos de dominio, factorías, repositorios) que si tienen código. Hay un servicio para cada caso de uso de la aplicación. Para cosas simples junto con su curva de aprendizaje esto seguramente será demasiado complejo pero en los casos en los que haya lógica de negocio, equipos medianos/grandes si será útil.

Un ejemplo de aplicación donde han aplicado DDD es Kreta.

Nuevamente gracias la dedicación de los organizadores por crear otra edición de este gran pequeño evento anual, los ponentes que altruistamente colaboran compartiendo su conocimiento y a la Universidad de Deusto por acoger un año más uno de los mejores eventos para desarrolladores de Bilbao y alrededores.