Friday, December 30, 2016

Books I read 2016

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

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

- 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

Saturday, December 24, 2016

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.

Sunday, December 18, 2016

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.

Thursday, December 1, 2016

Interesting Talk: "Code Symbiosis, a technical keynote"

I've just watched this wonderful talk by Michael Feathers

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.