Books I read 2016

January
- El Eternauta, Héctor Germán Oesterheld and Francisco Solano López
- Barcelona. Los vagabundos de la chatarra, Jorge Carrión and Sagar Fornies
- Rip Van Winkle, Washington Irving
- La guerra interminable (The Forever War), Joe Haldeman
- Maintanable JavaScript, Nicholas C. Zakas
- Ve y pon un centinela (Go Set a Watchman), Harper Lee
- El nombre del viento (The Name of the Wind), Patrick Rothfuss
- You Don't Know JS: Async & Performance, Kyle Simpson
- Sapiens: A Brief History of Humankind, Yuval Noah Harari
- The Principles of Object Oriented JavaScript, Nicholas C. Zakas

February
- The Leprechauns of Software Engineering, Laurent Bossavit
- The Wise Man's Fear, Patrick Rothfuss
- Fundamentals of Object-Oriented Design in UML, Meilir Page-Jones
- Old Man's War, John Scalzi
- Cevdet Bey e hijos (Cevdet Bey ve Oğulları), Orhan Pamuk
- Ringworld, Larry Niven
- Why Nations Fail: The Origins of Power, Prosperity, and Poverty, Daron Acemoglu and James A. Robinson

March
- The Grumpy Programmer's Guide To Building Testable PHP Applications, Chris Hartjes
- The Grapes of Wrath, John Steinbeck
- The Coding Dojo Handbook, Emily Bache
- Fahrenheit 451, Ray Bradbury

April
- Implementation Patterns, Kent Beck (3rd time)
- The Power of Habit: Why We Do What We Do in Life and Business, Charles Duhigg
- How to Win Friends and Influence People, Dale Carnegie
- Understanding the Four Rules of Simple Design, Corey Haines (2nd time)
- La llamada de Cthulhu (The Call of Cthulhu), El horror de Dunwich (The Dunwich Horror) and Las ratas en las paredes (The Rats in the Walls), H. P. Lovecraft
- The Tales of Beedle the Bard, J. K. Rowling

May
- The Slow Regard of Silent Things, Patrick Rothfuss
- Building Microservices, Designing Fine-Grained Systems, Sam Newman
- Man's Search for Meaning, Viktor Frankl
- Manifiesto del Partido Comunista (Das Kommunistiche Manifest), K. Marx and F. Engels
- Web Development with Clojure, Build Bulletproof Web Apps with Less Code, Dimitri Sotnikov
- Patterns of Enterprise Application Architecture, Martin Fowler
- The Checklist Manifesto: How to Get Things Right, Atul Gawande
- How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life, Scott Adams

June
- Pragmatic Thinking and Learning, Refactor Your Wetware, Andy Hunt
- Testable JavaScript, Mark Ethan Trostler
- The Secrets of Consulting: A Guide to Giving & Getting Advice Successfully, Gerald M. Weinberg
- La desfachatez intelectual. Escritores e intelectuales ante la política, Ignacio Sánchez-Cuenca
- REST in Practice, Jim Webber, Savas Parastatidis and Ian Robinson
- Mindset, Carol Dweck

July
- The Call of the Wild, Jack London
- Weinberg on Writing: The Fieldstone Method, Gerald M. Weinberg
- Dinner at the Homesick Restaurant, Anne Tyler
- How to Solve It: A New Aspect of Mathematical Method, G. Polya
- Object Oriented Software Engineering: A Use Case Driven Approach, Ivar Jacobson
- A Far Cry from Kensington, Muriel Spark

August
- The Difference Engine, William Gibson and Bruce Sterling
- Clojure Applied, From Practice to Practitioner, Ben Vandgrift and Alex Miller
- Vampir, Joann Sfar
- Los mares del Sur, Manuel Vázquez Montalbán
- El océano al final del camino (The Ocean at the End of the Lane), Neil Gaiman
- La Guerra Civil Española, Paul Preston and José Pablo García
- Wiser: Getting Beyond Groupthink to Make Groups Smarter, Cass R. Sunstein and Reid Hastie

September
- And The Weak Suffer What They Must?: Europe, Austerity and the Threat to Global Stability, Yanis Varoufakis
- Clojure Reactive Programming, Leonardo Borges
- Designing Object-Oriented Software 1st ed., Rebecca Wirfs-Brock, Brian Wilkerson and Lauren Wiener
- Divina Comedia (Divina Commedia), Dante Alighieri

October
- David Copperfield, Charles Dickens
- Utopía (Utopia), Thomas More
- La pulga de acero (Сказ о тульском косом Левше и о стальной блохе), Nikolái Leskov
- Living Clojure, An Introduction and Training Plan for Developers, Carin Meier
- Buddha in Blue Jeans: An Extremely Short Zen Guide to Sitting Quietly and Being Buddha, Tai Sheridan

November
- De tu tierra (Paesi tuoi), El Camarada (Il Compagno), Cesare Pavese
- A Passage to India, E. M. Forster
- React: Up & Running. Building Web Applications, Stoyan Stefanov
- El relato de Arthur Gordon Pym (The Narrative of Arthur Gordon Pym of Nantucket),Edgar Allan Poe.

December
- The Remains of the Day, Kazuo Ishiguro
- Quiet: The Power of Introverts in a World That Can't Stop Talking, Susan Cain
- Robinson Crusoe, Daniel Defoe
- All you Zombies, Robert A. Heinlein

TDD Training at Gradiant (in spanish)

La semana pasada Luis Rovirosa y yo impartimos una formación de TDD en las oficinas de Gradiant en Vigo.

Gradiant es el acrónimo en inglés del Centro Tecnolóxico de Telecomunicacións de Galicia (Galician Research and Development Center in Advanced Telecomunications) y utilizan los conocimientos y experiencia de sus profesionales de investigación para aportar valor a empresas y organizaciones mediante la transferencia de conocimiento y el diseño de productos especializados.

La naturaleza del centro y su ubicación en el campus de la Universidad de Vigo me recordó bastante a la época en que trabajé en el BSC.

Este fue el segundo curso de TDD de Codesai que imparto con Luis, y era todo un reto, debido al número de asistentes, 18 personas, y, sobretodo, a la gran variedad de tecnologías y tipos de sistemas que desarrollan, que iban desde C empotrado para procesado de señales o IOT, hasta APIs REST con node.js, pasando por diversas aplicaciones en Java, C++ o Scala.

Creo que hacer los cursos en pareja es una gran ventaja. Por un lado, porque podemos atender mucho mejor, sobre todo si el grupo es numeroso, a las parejas durante las sesiones prácticas dándoles feedback y contestando sus dudas, para ayudar a que asimilen mejor los conceptos que persigue trabajar cada kata. Por otro lado, porque nos permite asumir roles diferentes, parecidos a los de conductor y navegador en pair-programming, para percibir mejor el pulso de nuestra audiencia y modular mejor nuestro mensaje. En este sentido, Luis y yo, nos complementamos bastante bien porque, al tener backgrounds bastante distintos y personalidades diferentes, podemos enriquecer tanto las explicaciones teóricas como las prácticas, con un rango de experiencias y perpectivas más amplio, lo que considero que fue muy útil, dada la diversidad del grupo.

Algunos de los desarrolladores que asistieron al curso trabajaban en sistemas empotrados haciendo IOT o procesado de señales en los que cuentan con recursos muy limitados y en entornos en los que testear es bastante complicado. Para tratar de ayudarlos, aparte de responder dudas concretas y de las conversaciones de pasillo, reunimos una compilación de recursos interesantes para hacer testing y TDD con C empotrado.

Nos gustó muchísimo la experiencia de trabajar con las personas que asistieron al curso. Era un grupo muy agradable y con muchísimas ganas de aprender. Además, durante el curso, surgieron preguntas y debates muy interesantes debido a la gran diversidad de tipos de proyecto desarrollados por los asistentes.

Hemos acabado reventados después de dos días intensos... Pero también motivadísimos #tdd #craftmanship https://t.co/eXtEBVssmZ

— Javi (@jsrois) December 20, 2016

Mega cursazo! Gracias @trikitrok @luisrovirosa y gracias @Gradiant por traerlos! A ver si vuelven 😉https://t.co/pMuI7aZl2E

— Fernando Vilas (@fer_vilas) December 20, 2016

Como siempre acabamos cansadísimos pero muy contentos porque creo que conseguimos nuestro objetivo de iniciar al grupo en testing y TDD, y de ilusionarlos para empezar a aventurarse en una forma de trabajo diferente.

Antes de terminar quería darle las gracias especialmente a Javi Sánchez Rois y a Fernando Vilas por acogernos, llevarnos a sitios ricos para comer y presentarnos al Dinoseto 😉.

Publicado originalmente en el blog de Codesai.

An example of introducing symmetry to enable duplication removal

Symmetry is a subtle concept that may seem only related to code aesthetics. However, as Kent Beck states in Implementation Patterns,

"...finding and expressing symmetry is a preliminary step to removing duplication. If a similar thought exists in several places in the code, making them symmetrical to each other is a first good step towards unifying them"

In this post we'll look at an example of expressing symmetry as a way to make duplication more visible. This is the initial code of a version of a subset of the Mars Rover kata that Álvaro García and I used in a refactoring workshop some time ago:

This code is using conditionals to express two consecutive decisions:

1. Which command to execute depending on a command code.
2. How to execute the command depending on the direction the rover faces.

These decisions are repeated for different responsibilities, displacing the rover and rotating the rover, so the code presents a Case Statements smell. Since those decisions are completely independent, we could mechanically refactor the code to start using polymorphism instead of conditionals. This way we'll end having two consecutive single dispatches, one for each decision.

If we start applying Replace Type Code with State/Strategy refactoring to the code as it is now, there is a subtle problem, though.

Looking carefully more carefully, we can observe that in the case of the rover's displacement, the sequence of two decisions is clearly there:

However, that sequence is not there in the case of the rover's rotations. In this case there's a third decision (conditional) based on the command type which as, we'll see, is not necessary:

This difference between the two sequences of decisions reveals a lack of symmetry in the code. It's important to remove it before starting to refactor the code to substitute the conditionals with polymorphism.

I've seen many cases in which developers naively start extracting methods and substituting the conditionals with polymorphism starting from asymmetrical code like this one. This often leads them to create entangled and leaking abstractions.

Particularly, in this case, blindly applying Replace Type Code with State/Strategy refactoring to the left and right rotations can very likely lead to a solution containing code like the following:

Notice how the Direction class contains a decision based on the encoding of the command. To be able to take that decision, Direction needs to know about the encoding, which is why it's been made public in the Command class.

This is bad... Some knowledge about the commands encoding has leaked from the Command class into the Direction class. Direction shouldn't be taking that decision in the first place. Neither should it know how commands are encoded. Moreover, this is a decision that was already taken and doesn't need to be taken again.

How can we avoid this trap?

We should go back to the initial code and instead of mechanically applying refactoring, we should start by removing the asymmetry from the initial code.

You can see one way of doing it in this video:



After this refactoring all cases are symmetrical (they present the same sequence of decisions)

We've not only removed the asymmetry but we've also made more explicit the case statements (Case Statements smell) on the command encoding and the duplicated switches on the direction the rover is facing:

Now it's clear that the third decision (third nested conditional) in the original rover's rotations code was unnecessary.

If we start the Replace Type Code with State/Strategy refactoring now, it's more likely that we'll end with a code in which Direction knows nothing about how the commands are encoded:

and the encoding of each command is known in only one place:

As we said at the beginning, symmetry is a very useful concept that can help you guide refactoring. Detecting asymmetries and thinking why they happen, can help you to detect hidden duplication and, as in this case, sometimes entangled dimensions of complexity ^[1].

Then, by removing those asymmetries, you can make the duplication more visible and disentangle the entangled dimensions of complexity. The only thing you need is to be patient and don't start "obvious" refactorings before thinking a bit about symmetry.

^[1] Dimension of Complexity is a term used by Mateu Adsuara in a talk at SocraCan16 to name an orthogonal functionality. In that talk he used dimensions of complexity to group the examples in his test list and help him choose the next test when doing TDD. He talked about it in this three posts: Complexity dimensions - FizzBuzz part I, Complexity dimensions - FizzBuzz part II and Complexity dimensions - FizzBuzz part III. Other names for the same concept that I've heard are axes of change, directions of change or vectors of change.

Recorded talk about functions in Clojure (in Spanish)

Last Wednesday we did our third remote talk about Clojure as part of our small Clojure/ClojureScript study group.

This time we talked a bit about functions and we recorded it as well.

This is the resulting video:

You'll find the examples we used here.

Again I'd like to especially thank Ángel and Magento Barcelona for letting me do the talk from their office.

I hope you find it useful.

Interesting Talk: "GOOS style TDD by Example"

I've just watched this interesting talk by Sagy Rozman

• GOOS style TDD by Example

Interesting Talk: "Neurobollocks: el nuevo aceite de serpiente"

I've just watched this interesting talk by Marta Ferrero and Pablo Garaizar

• Neurobollocks: el nuevo aceite de serpiente

TDD Training at Ve Interactive (in spanish)

Hace unas semanas Luis Rovirosa y yo impartimos una formación de TDD en las oficinas de Ve Interactive en Bilbao.

Luis lleva bastante tiempo impartiendo el curso de TDD de Codesai, tanto en solitario como junto con Carlos Blé, pero para mi era la privera vez. Me gustó mucho la estructura y el ritmo que le da Luis al curso.

Se trata un curso muy intenso y eminentemente práctico que dura dos días, cada uno de los cuales se divide en cuatro bloques de dos horas. Al comienzo de cada bloque presentamos una serie de conceptos teóricos, que comentamos y debatimos con el grupo, y rápidamente pasamos a ponerlos en práctica mediante una serie de katas de complejidad y dificultad creciente, en las que acompañamos continuamente a las parejas dándoles feedback y contestando sus dudas, para que los conceptos acaben de ser asimilados.

Fue todo un placer trabajar con los 14 desarrolladores que asistieron al curso. Era un grupo con una actitud genial y con un nivel muy bueno. A pesar de lo intenso del curso, trabajaron con mucho entusiasmo cada uno de los ejercicios y se produjeron debates muy interesantes y constructivos.

Nos fuimos de Bilbao exhaustos, pero muy contentos, tanto por las personas que conocimos como por el feedback que recibimos. Personalmente, me encanto trabajar con Luis y aprendí muchísimo de él.

Publicado originalmente en el blog de Codesai.

Interesting Talk: "Overcoming the Challenges of Mentoring"

I've just watched this great talk by Kim Crayton

• Overcoming the Challenges of Mentoring

Interesting Talk: "Code Symbiosis, a technical keynote"

I've just watched this wonderful talk by Michael Feathers

• Code Symbiosis, a technical keynote

Recorded talk about destructuring in Clojure (in Spanish)

I recently started to work at Codesai.

Some members of the team wanted to learn Clojure, so we started a small Clojure/ClojureScript study group.

We created a slack called clojuresai where I'm posting some readings (we're reading Clojure for the Brave and True) and exercises (we're working through a selection of exercises from 4Clojure) each week and where they can ask doubts about the exercises and readings, and comment things they find interesting.

Some colleagues from the Clojure Developers Barcelona meetup that are beginning to learn clojure have also joined the study group.

Now and then, we do introductory talks using Google Hangouts (Codesai's team is distributed) to go deeper in some of the topics they've just read in the book.

So far we've done two talks. The first one was about Clojure collections. Unfortunately, we didn't record it, but you can find the examples we used here.

Today we did a second remote talk. This time it was about destructuring in Clojure, and since some of the members of the study group members weren't able to make it, we decided to record it.

This is the resulting video:

You'll find the examples we used in this previous post.

I'd like to especially thank Ángel and Magento Barcelona for letting me do the talk today from their office (their internet connection is much better than mine).

Recently, Miguel de la Cruz (thanks a million Miguel!!) has joined our study group as a tutor. He knows a lot of Clojure so he will help answering doubts and giving some talks that we'll hopefully share with you soon, as well.