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.

We'll talk about our experience developing an SPA' browser and native versions that share 90 sth % of their code using React and ReactNative and about the advantages of using a functional language like ClojureScript combined with the re-frame framework which has an architecture similar to Redux but with great conceptual improvements such as effects and coeffects that improve testability by eliminating the need of mocking inside the SPA business logic, or reactive subscriptions which make views dumber and can also reduce the number of renderings.

¿Qué ventajas tiene la separación entre el modelo de escritura y lectura que propone CQRS? ¿Realmente tiene sentido? ¿Cómo realizamos una integración con un sistema externo sin depender de él y desacoplado? ¿Cómo podemos aprovecharnos de la consistencia eventual? ¿Cómo se aplica todo esto en un proyecto real?

Vivimos en una sociedad acelerada, donde las rutinas y la inercia del día a día hacen que no seamos dueños de nuestras vidas. Aunque no acabemos de estar satisfechos con nuestro trabajo, el miedo al cambio, al rechazo y al fracaso hacen que no tomemos ninguna acción para mejorar nuestra situación. Ir más lentos, aprender a decir a ‘no’ y deshacernos de lo que no nos aporta nos ha permitido disfrutar con nuestra profesión, tener claro nuestras prioridades, compaginar la vida profesional con la personal, conseguir mejores clientes y desarrollar proyectos de forma sostenible.

"Let's learn about useful Machine Learning algorithms, invoking them from common libraries (pandas & scikit-learn). The session starts with a brief introduction to ML and the different approaches we can apply. After that we will practice exploring real datasets, cleaning and optimizing the data, and using ML algorithms to find hidden insights. NO need to know about maths, machine learning, nor python; this is an introductory but profitable workshop!"

"In this talk I'd like to share some thoughts on how we learn best practices, and, specifically, how different learning mechanisms are better for different moments along the way."

Se trata de explicar, desde un punto de vista de arquitectura, infraestructuras, y prácticas de desarrollo, cómo descomponer un monolito basado en Drupal y convertirlo en una colección de servicios autónomos, cada uno con su propio stack de tecnologías, y sin que los usuarios perciban ni un segundo de caída en el servicio.

CSS no es un lenguaje de programación, pero no por eso tenemos que hacer las cosas mal. El término Software Craftsmanship ha sigo acogido por la comunidad como definición de una metodología de desarrollo acorde a: un software bien diseñado, agregar valor constante, comunidad de profesionales y asociaciones productivas.

"A todos nos ha pasado que hemos leído un tutorial de programación declarativa (aka funcional), pero después llegamos a un código real y no sabemos ni como empezar a usar esos conceptos. A nosotros nos pasaba lo mismo. Después de mucho luchar, muchas iteraciones y pedir mucha ayuda a gente más buena que nosotros, hemos aprendido a allanar el camino hacia la programación declarativa de manera pragmática, poco a poco y sin irnos por las ramas. Llegados a este punto, creemos que otra gente se beneficiaría de este conocimiento. En esta charla vamos a refactorizar una aplicación con casos de uso reales partiendo de una base imperativa. Nuestro objetivo será ir puliendo la lógica de éstos hasta llegar a una implementación declarativa fácilmente entendible, y, a la vez, más robusta ante los dichosos 'side-effects'."

Kubernetes is an orchestration tool created by Google aiming to control containerized applications at the cluster level. People used to say the entry level is hard but I hope to demonstrate how you can build an application from scratch using good practices.

When embracing Java 8 we walk down the yellow brick road to the wizard of lambdas. That road usually starts from the fear and terror of learning their syntax until finally getting to understand them and opening our minds to the fruitful fields of functional programming. But this road eventually reaches a final stage: the lambda abuse. To master the lambdas art means to know when to use them and when not to not damage your brain and, most importantly, other Java developers’. Keep your code readable and maintainable, avoid becoming a lambda addict!