Siempre que se nos habla de calidad de código y de Buenas Prácticas de programación se presentan una serie de recomendaciones que, muchas veces acabamos olvidando cuando las prisas o el desconocimiento de una tecnología aprieta.
En esta charla, utilizaremos la aproximación contraria: Partiremos de pequeños fragmentos de código extraídos de proyectos reales e indicaremos porqué son malas prácticas. Algunos de estos ejemplos de código procede de proyectos grandes opensource (todo el mundo echa un borrón de cuando en cuando). También mostraremos cuales son los conceptos de diseño y daremos las recomendaciones para evitar caer en estos problemas.
La charla será amena y divertida, basada principalmente en Java (aunque habrá algo de otros lenguajes), en la que procuraré que, a través de las anécdotas y estos casos extremos, podamos recordar las buenas prácticas de desarrollo que deberíamos tener siempre presentes.

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'.

Al terminar, queremos que los asistentes:

• - Sepan las ventajas y desventajas de usar este estilo de programación.
• - Entiendan que la curva de aprendizaje a nivel de lógica es menor, a cambio de una mayor complejidad de implementación.
• - Pierdan el miedo a conceptos matemáticos como Monad Transformers, explicándolos con pragmatismo.
• - Vean que se puede usar la programación declarativa en cualquier caso de uso real, no solo en proyectos de juguete.

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!

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.

¿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.

En esta charla compartiremos cómo hemos ralentizado nuestro ritmo para ser más conscientes de nuestras necesidades, tomar mejores decisiones y ser felices.

Architectural Katas is an exercise created by Ted Neward. Similarly to code katas, the role of this session is to practice and became better at software architecture. The exercise normally consists on groups of 3 to 5 people, each one of them doing a different kata. The group will discuss options and sketch what a possible solution may look like. The moderator assigns the katas and acts as a "customer" answering questions from the teams. At the end, the teams present their solution to the other teams in the room, and answer challenges (in the form of hard-but-fair questions). This session is open to everyone, from seasoned architect to junior developers. The main goal is to practice our architectural skills by learning from each other. The original Kata is described here (https://archkatas.herokuapp.com/about.html).

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!

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.

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.

A core mission of the software craftsmanship movement is to promote modern practices within the tech industry, like TDD and pair programming. Software, however, is only one part of the craftsmanship puzzle: our manifesto also speaks of professionalism and partnership.
When it comes to diversity and inclusion, our industry has an abysmal track record. Some of us in the craftsmanship community are actively working to make a difference. We believe that if craftsmanship is to remain relevant into the 2020s and beyond, we must tackle this issue head-on.
In this talk I’ll look at what key players in the software craftsmanship community have been doing to improve diversity, why it’s important we all participate, and what you can do to help.

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.

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.

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.

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.