Map and reduce methods in Ruby

There are two methods in Ruby's Enumerable module that often people coming
from an object oriented background find confusing but are indeed very
useful: .map and .reduce.

They both are constructions taken from functional programming so they
both take a block as a parameter.

There are also .collect and .inject aliases for them. They are there
only to use whatever one the domain you are working thinks is best.

.map / .collect

Map takes a function and returns the array that has in each position
the result of applying that function to the corresponding element of the
original array.

map.png

This is a highly practical method. Imagine that, for example, you have
an array of people and you want to get an array of the names. It is
as easy as:

.reduce / .inject

Reduce is similar to map but instead of receiving a function that takes
only one parameter it receives a function that receives an accumulator and
the value. Instead of returning an array it just returns the accumulator.
We can say that this method reduces the array to a single value.

reduce.png

Imagine now that with our array of people we want to get the total number
of letters that all the names have. We can do:

Software craftsmanship Madrid

For some time since my two kids were born I stopped attending to user groups, conferences and events in general. These days I decided to make a small effort and return again to those activities. To be completely hones, I must say I missed it a lot. Maybe there is nothing you can learn there that you can do by yourself diving through the internet or reading some books but, in my humble opinion, it is not the same thing.

So I'm spending some effort in a small meetup group in Madrid. We prepare some small workshops from time to time and it really feels good to connect to other professionals.

There is always a time in all software developer's life when you see going to this kind of events as a waste of time since you do a lot of socialization and not that much learning. Anyway I'm starting to think that this is not that bad. Developing software is an activity that has an important social component. Cultivating this part is also important. We build sofware for humans so we need to communicate and interact with people constantly, not only with machines.

Go outside your cubicle. Speak with people. Enjoy having discussions.

Lessons learnt from my first workshop

The workshop

I drove a small workshop about BDD for the Madrid Software Craftsmanship meetup. It was a great experience. I learned a lot in the process so I wanted to recap my experiences.

The outcome

Basically it was horrible. I prepared a huge range of exercises and due to many reasons we could only do one that was not the most important one.

Lessons learnt

  • Exercises in a workshop must be self-contained. You should not rely on what you speak but what people sees in their screens. There were more people than expected in the workshop and I could not spend almost no time with each of them.
  • Let everybody go their own pace. Everyone deserves to have fun. A nice way of having all the people 100% involved is proposing a challenge of their level. If somebody needs less time to go through the simplest examples he should be able to do so to get to the more challenging ones.
  • Prepare less but prepare right. Conversation will arise.
  • A coding workshop has no need for a presentation excepting maybe for some small introduction. You will spend a lot of time speaking to people and trying to solve problems they may have. Also, you can find time to ask questions to some of the groups in the workshop.

Was everything horrible?

I suppose not. Some people approached me after the workshop and said that they learnt a lot.

Also, the discussion after the workshop was pretty interesting. The practical exercise was a cool excuse to start working about scenarios where all what we did before could be applied.

Do I want to repeat?

After the traumatic experience... of course I do! Indeed it was a good experience. Also I see that I have a lot of room for improvement here and I want to walk that road.

Methodologies, use them wisely

The methodology trap

Maybe it is because we are entering the post agile era but I can't stop seeing people complaining about Scrum being slow, waterfallish... The last one I saw really caught my eye. It even hit front page of HN. It was called standups are poisonous. I read the title and couldn't avoid WTFing. Of course I don't really enter this kind of discussions. I don't see myself as an authority to question somebody's opinion. Luckly Darian Shimy wrote something far wiser than whatever I could try to explain.

Anyhow I think we are missing the big picture. Following blindly whatever methodology or principle is too stupid.

What are methodologies for?

A methodology is only a set of guidelines that helps us reaching some purpose. It's like the shopping list: it's a reminder of some steps you need to do in order to reach some goal. The stress in in the purpose, not in the means. Back in the stand up example, of course a 30 minute daily stand up is evil! And of course changing it to something that reaches the same goal and takes less time is a good idea. The idea behind the daily stand up is making all the team aware of the current situation and remove any obstacle that may arise. That's it. If your team thinks it is better to send a plain email: let be it! If your team prefers using a bunch of homing pigeons: have fun and remember to feed them properly!

We need this kind of methodologies because our imperfections. A groceries list is very useful because it helps you to remember what you have to buy but it also saves you from buying more than you need because you write the list at home and you can check your fridge at the moment you are deciding what to buy. Maybe your memory is superb and you don't need to write the list on paper and prefer making a mental note. Are you using a grocery list then? Maybe or maybe not but you are following its spirit and reaching the goals it helps you to reach.

Standing on the shoulders of giants

Anyway we have lots of literature about all the methodologies you can think of. A lot of book have been written about Scrum. All of them are written based on the author experiences and working with the human beings the author has worked with. This may or may not work 100% with all the people in this world. Anyway, since it worked for somebody they make an awesome starting point for you and your team to iterate and build your own way. Build your experience on top of other people's.

Your books are your story

I had a conversation with @jacegu in Baruco about putting stickers in your laptop. As I always did he keeps his machines bright and shiny with no extra glue and plastic over it.

Once, the laptop I'm currently using fell to the ground and a dent appeared behind the screen. To hide it I bought a vinyl sticker from Etsy and sticked it over the dent.

Some time after I went to a code retreat and I ended up with two stickers: one from coderetreat.org and another one from dnssimple.com. Since there was already one sticker, why not pasting another one? Both of them got there. Now, I've added some more and probably more are yet to come.

Why the change? I think that it is probably uglier for an external viewer but I started to notice that the machine I use everyday for work is my machine and is a little bit of me. It's my story and all of its dents and scratches are moments I've spent in my life. They are imperfections but they are my imperfections. They tell a story. The story of the places or the people that computer has been with.

I also kept my personal library bright and shiny in the past. Taking notes on books was strictly forbidden. This is starting also to change. I'm going the other way round. I'm taking notes, writing comments, pointing other examples or related concepts in the margins, underlining things I think that are key concepts... If you do it once, you'll start seeing this as marking the path you followed, as leaving marks for a future visitor to see some hidden treasure that otherwise may go unnoticed. If some friend borrows the book from you he will have not only the standard path for tourists but also your story. For sure when a friend from another city visits your you take him not only to the most representative places but to the places you like the most. Why are we taught that we should not do the same with books? Are they somehow sacred?

It's a bit of Wabi Sabi. You celebrate some imperfections caused by the limitations of the moment. Your communication with the author is limited so you can only write annotations to the book. Also you must know that the purpose of the book is not lasting indefinitely so, why not marking it?

We should also have a little bit of this philosophy in our software projects. We tend to design software thinking that it needs to be perfect and it needs to last forever. We must learn to value the compromises we make in design due to limitations in the moment: time contraints, budget constraints... and appreciate the solutions that were took at a given moment. We must embrace change. And most of all. We must see the beauty on that.

Study joseki

There is something I like a lot about Go and is that all the things I learnt about the game can be applied to everyday things in this life.

The Joseki in go is a sequence of moves at the corner that are supposed to be "correct" and balanced for both players. While listening to the last Ruby Rogues podcast I couldn't get out of my mind a proverb applied to go.

Learning Joseki loses two stones strength -- Studying Joseki gains four stones strength

This can be also applied to design patterns in code. Learning them is useful but applying them blindly is just bloat and nonsense. Design patterns are patterns that arise in a lot of codebases and are a good tool to help us to communicate with other programmers. They are not "the correct solution".

I liked something David Heinemeier Hansson said. It was that using a pattern is only useful if the outcome is better that without using it. After seeing this written it looks maybe stupid but there are a lot of times that we try to organize, patternize, and write are code in an unnatural way just because is the "correct solution".

There are no correct solutions in software. We often lose focus with that and forget to get to the solution that just looks better no matter how academically correct is.

Mendicant Reading club: Beautiful Visualization

I'll be driving a book club session at mendicant university.
We'll be reading (if there is somebody interested in joining in)
Beautiful Visualization. I've recently became interested in UX and visualization of large amounts of data is, at this moment, for me an art more than a science. I hope we are able to throw some light over this topic.

I'll try to keep the discussion running by asking questions and organizing small debates.

This is the first time I do something like this but I hope this is a good
experience for everybody.