Barcelona Software Craftmanship 2017

"Why should you invest in Continuous Delivery?

It's expensive, requires tecnical expertise, time and machines... The problem is that without CD you are walking around with a hole in your pocket and the hole is getting bigger...

This presentation focusses on the 3 main reasons why the hole is there... and growing. They are the ABC of Continuous Delivery:

- Amplification: Deploying takes more time the longer the time between deploys.

- Bugs: Bugs are more costly to fix the longer ago they were introduced.

- Cost of Delay (CoD): The longer you take between deploys, the longer your cost of delay

In the model we present, one can see the costs of integration and deploy are super linear to the number of changes to integrate. In Software Development, the commits that are not yet in production are inventory... and inventory is waste."

The talk focuses on architectural changes and new tools we should adopt to be able to tackle the problems presented by a demand for modern, responsive, fault tolerant and elastic systems. It is based on the material published in The DevOps 2.1 Toolkit: Building, testing, deploying, and monitoring services inside Docker Swarm clusters.

The talk will go through the whole microservices development lifecycle. We’ll start from the very beginning and define and design architecture. From there on we’ll move from requirements, technological choices and development environment setup, through coding and testing all the way until the final deployment to production. We won’t stop there. Once our new services are up and running we’ll see how to maintain them, scale them depending on resource utilization and response time, and recover them in case of failures. We’ll try to balance the need for creative manual work and the need to automate as much of the process as possible.

The goal is to design a fully automated continuous deployment (CDP) pipeline. We’ll see how microservices fit into CDP and immutable containers concepts and why the best results are obtained when those three are combined into one unique framework.

One day, you learn that you will be responsible for the company’s externally facing API.

It is a strategic product for the business and expected to have more and more users in the next few months. However, you also know that the existing API has various performance problems and multiple clients have been complaining. Where would you start?

The software craftsmanship movement started 8 years ago. What happened since? Has anything changed? Where is this movement? What is Software Craftsmanship anyway? In this session Sandro will be talking about the past, present and future of the Software Craftsmanship movement and how it is changing the way developers and companies think about software.

ACID transactions in a monolithic application are a great, powerful and simple tool, that helps us guaranteeing data consistency inside our application.

But... what happens when we move from monolithic applications to distributed systems? We don't have a single database or ACID transactions anymore, and there is also a choice to make regarding the CAP theorem. But... is all hope lost? Or can we still somehow have transactions across service boundaries?

In this talk we will try to understand that complexity, see some alternatives, and how the SAGA pattern comes to the rescue here.

Main goal of the talk is to expose, elaborate and show examples from my own experience on the Dungeon Master (DM)

"Estamos acostumbrados a hablar de la calidad del código "de producción", pero ¿qué hay de la calidad de los test? ¿Cómo medimos si son buenos o malos?

En esta sesión veremos problemas comunes que nos encontramos al empezar a testear, cómo evitar malas prácticas, y daremos nuestra opinión acerca de los tipos de test que más valor aportan.

Por último, también hablaremos del encaje del testing en una aplicaciones CQRS y DDD (Arquitectura Hexagonal).

Para demostrar que son principios agnósticos del lenguaje, los ejemplos de código serán tanto en Scala como en PHP"

Unit testing can sometimes be tedious to write, hard to maintain, difficult to get good coverage and in some cases its difficult to come up with random (edge cases) unbiased examples. Random testing based on properties can complement unit testing and in some cases even replace them completly.

This talk is a introduction to radom testing, how to define and use properties to test code.

TDD es una parte importantísima de mi flujo de trabajo cuando desarrollo software. Con el paso de los años he modificado la forma en la que lo aplico, he aplicado distintas técnicas y he experimentado distintas formas de escribir mis tests para tratar de sentirme lo más productivo posible. Dar con un flujo de trabajo que me resulte cómodo, trabajar en el nivel de abstracción y con la aproximación adecuada no ha sido fácil y aún así tengo claro que estoy lejos de haber encontrado una fórmula ideal.

Elegir entre una aproximación outside-in vs inside-out, qué tipos de dobles de prueba utilizar, escribir tests que no requieran más mantenimiento que el propio código de producción son algunos de los retos a los que podemos tener que enfrentarnos cuando aplicamos TDD en nuestro día a día.

En esta charla quiero hablar de cómo aproximo mi trabajo cuando desarrollo aplicando TDD. No se trata de una charla introductoria ni de evangelización sobre las virtudes de TDD.

When we think of a Linux distribution, most of the time we think of a graphical Interface. We can install the needed packages using some tool the distribution provides us. From time to time we get updates. Everything works (hopefully) out of the box.