Hace unos meses decidimos juntarnos y hacer un equipo de desarrollo a la XP, y así nacimos como Coding Stones.
En nuestro último proyecto, pudímos aplicar todo nuestro kung-fu sobre DDD y vimos que nos encajaba muy bien la separación de Actions como Application Services que propone Sandro Mancuso en sus charlas sobre IDD o Crafted Design. Y nos gustaría compartir las experiencias sobre lo que hemos aprendido con el resto de la comunidad.

Después de la charla que ya di el año pasado sobre la intención de Schibsted de implantar ReactJS en todos sus productos y como pensábamos. Voy a tratar de explicar todas las cosas buenas y malas que hemos hecho en la transición. Creo que es una experiencia muy valiosa para otras plataformas que tengan en mente un cambio similar.

Nuestro software debería tener la capacidad de poder ser modificado con un coste bajo. Para ello utilizamos algunas buenas prácticas de diseño o code smells que nos guíen (SOLID, Yagni, Demeter Law, etc). Pero a veces, estos elementos suelen ser algo subjetivos que a veces derivan en discusiones poco productivas para el fin. Los tipos de Connascence nos ofrece otra herramienta para evaluar nuestro diseño en otros términos, basado en 2 conceptos clave "Coupling & Cohesion" de los que Yourdon y Constantine ya nos hablaban en el año 79 en su famoso libro Structured Design.
La charla hablará de los tipos de connascence (o grado de acoplamiento), como podemos ver el impacto que tiene en nuestro diseño y algunas maneras de resolverlo. El paradigma es OOP por lo que se hará una muy breve introducción sólo a Encapsulation, Informations Hiding y Messaging.
Aunque he indicado que la charla será en español porque es mi lenguaje nativo, intentaré prepararla en inglés bajo la recomendación del documento para el call for papers.

The talk would describe the relationship between software architecture, qualitty attributes, talk some about architectural patterns and tactics. It is basically an introduction to some sw architecture topics (and up-front-design standpoint rather than emergent design) and while doing so focus on the fact that as engineers we have a responsibility to understand the pros but also the cons of our decisions.

Brief Description of Machine Learning and Deep Learning. Furthermore, I will show a few examples and how ML can be useful for us.

La inteligencia artificial está por todas partes a nuestro alrededor. Hasta los ascensores tienen capacidad de decisión, eso sin pararnos a pensar en nuestro móvil o nuestro GPS. Pero el sistema que mejor expone lo que es la IA son los videojuegos, en los que los NPCs muestran comportamientos inquietantemente humanos.
Pero no os dejéis engañar, ¡todo es una ilusión! Diseccionemos juntos el cerebro positrónico, conozcamos los secretos ocultos en su núcleo, y acabemos con ese turbio misticismo que rodea a las "máquinas inteligentes".

We make decisions every time we write a line of code. Often those decisions are not even conscious although they shape the code we have to maintain in the future. In this session we'll talk about the Less Surprise Principle among other principles, techniques and trade-offs we should consider when writing code. Not only for maintainability reasons but also as a mean to support our ideas when pairing or mobing with the team. This is a collaborative session where participants we'll discuss and propose more principles and techniques to enrich the group.

Es muy fácil comenzar a crear nuestros primeros containers de Docker en local, y facilitarnos la vida durante el desarrollo. Pero, ¿y si queremos compartir nuestros containers con nuestros compañeros de equipo o con otros equipos? ¿E introducirlos dentro del flujo de integración continua? ¿Cómo escalamos Docker dentro de nuestra organización?
En esta charla explicaremos las lecciones aprendidas durante nuestra aventura intentando conseguir utilizar containers en todas las fases del desarrollo del producto: desde la máquina del programador hasta producción. Y veremos qué buenas prácticas podemos adoptar para que la creación, distribución, y el despliegue de containers de Docker no sea una utopía.

Flow is what we experience when we are in an all-night coding session: we make so much progress and we have so much fun coding that we don't want to stop. It is the feeling we get when we are at our maximum engagement with the task we're doing. When we are in a flow state, we don't feel time passing by, we don't get stuck because we're able to solve all the problems that we encounter by effortlessly applying our skills, and we enjoy what we're doing.
Luckily, the job of a programmer is full of oportunities for experiencing flow everyday. In this talk we'll see how flow works and what we can do in order to get to that state easily. The purpose: being more productive and having fun at work.

Estos últimos meses hemos desarrollado un nuevo sistema de chat para la aplicación de Letgo. En esta charla os contaremos toda la experiencia vivida al respecto, tanto a nivel del proceso seguido, como de nuestro proceso de aprendizaje sobre las tecnologías usadas y los errores que hemos cometido. Por lo tanto no es una charla puramente técnica (hay material mucho mejor para aprender Akka y Scala) pero sí que haremos una breve introducción al paradigma de actores.

Viniendo de desarrollar webs en PHP, muy concienciados por temas como SOLID, Arquitectura Hexagonal, DDD, y CQRS; nos encontramos con un paradigma donde nos ha costado encajar según qué planteamientos. Con lo cuál, os contaremos justamente eso:
* Estrategia seguida para salir del monolito e ir al microservicio rico
* Evolución del proyecto a lo largo de estos meses
* Por qué decidimos apostar por el stack tecnológico escogido a pesar del cambio que implica
* Paradigma de actores de Akka en el chat de Letgo.
* Cómo hemos intentado llevar el CQRS a un protocolo de comunicación por WebSockets
* Cómo hemos usado Akka Streams para el proceso de migración inicial de datos
* Qué cosas nos han sorprendido del cambio de ecosistema (tanto para bien como para mal)
* Cómo hemos conseguido mantener retrocompatibilidad con las versiones anteriores de la app que apuntan al sistema de chat anterior
* …

Esta charla proveerá de una visión más amplia de lo que se expuso en la Software Craftsmanship de Pamplona ( http://www.slideshare.net/JavierCane/leaving-the-monolith-thanks-to-eventsourcing-scpna-63267815 ). Donde nos centramos únicamente a analizamor cómo conseguimos mantener la retrocompatibilidad entre los dos sistemas de chat gracias a eventos de dominio, SNS, y SQS.

La charla la daríamos a medias entre los dos, @SergiGP y @JavierCane :)

Dejémonos de liderazgos técnicos, de primeros de la clase, de meritocracias y de equipos de dos velocidades.

Most organisational models are broken and very few employees can say they are empowered and trusted to do their jobs. Most professionals today want far more than a job—they want to develop their careers, be part of the decision making, and have the power to reshape the organisation they work for, and most importantly, enjoy their work. In this talk Sandro will explain what Teal Organisations are and will describe some of the advantages and challenges of being part of a self-organised and self-managed company. He will be covering topics that include: complete flat structure, decentralised decision making, open financials, open salaries, recruitment, initiative circles, and cultural fit.