Recently I changed to Ruby 2.0.0 in a project I am working on. I think I am going to share some things that I found specially attractive when I find them in a series of small posts (this might be the only one though)

In the few weeks I have been playing around with Ruby 2.0.0 I really have come to love named parameters. You know them already from other languages (in Smalltalk and Objective-C, for example, you find this type of function calls) and I always have loved them for the clarity in the language they give. It is much easier to compose a meaningful sentence and make the messages you send across much more explicit.

There is one thing about the Ruby’s implementation of the named parameters that I am really fond of though. Let me show you first how the method definition looks now:

What does all this mean in practical terms?

Imagine you have a Use Case you are working on, it shows a project for a user in a project management tool. This method could look like this:

As you can see we are looking up the user and the project by their names and then passing them to a presenter wich will render the project board; a simple task.

We can argue that the user and the project should not really be looked up in the method body (they are needed for the presenter to render the page, but are a possible violation of the Single Responsibility Principle, if we are being purists about it) as the method is only in charge of showing the project (as it’s name indicates).

The beauty comes from what we can do now with it due the new flexibility Ruby 2.0.0 gives us.

And suddenly our method follows the Single Responsibility Principle again!

Obviously all this can be overdone and I would recommend you to explore the possibilities before you start messing up your production codebase.

Remember it is all about making your code clearer and cleaner!

Update!

As Chad mentioned in the gist, something similar as I show above can be done in Ruby 1.8.x already. I was to eager to get the blogpost out and I forgot to add a little spice to the method so that it would become cleaner and more readable:

If you look at this now from the clients point of view it actually becomes a nifty method call:

Thank you for pointing it out Chad!

Humans love stories; in the past stories were used to transmit important cultural events from generation to generation, we read novels that transport us to a different reality, we watch movies… the list goes on and on.

As developers we deal with language every day; be it a programming language or the natural language we are speaking with our team.

Why does our code not tell a story?

It starts with the obvious; when you are working on an acceptance testing tool (like cucumber) you are afraid not to capture every nuance of the system; you end up writing imperative scenarios.

If I read a list of things your system can do, like the back of a productbox, I will get bored.

Boredom is a dangerous thing!

I will disengage from your description, not really care about the application you are describing; over time I will let it wither and die.

If on the other hand you tell me a story, I will devour it, you will make me dream, seeing the users interact with the system in my head imagining their faces and reactions; You will catch my attention!

Reading a compelling story is always beautiful and engaging, if you become part of the story magic will happen!

Next time you write acceptance tests, unit tests or code think about me, the reader, your fellow co-worker and make me want to be part of that story…

This weekend I was working on a product idea we have been toying around (I wanted to have a little break from writing) and a thought occurred to me…

Suppose you are like me sitting in your home office some weekend (or late night) and you are coding on some project you want your colleagues/friends to see when they come back from the weekend or the next day. “Well”, you say, “you push it on github and they will get it…”

Right, all true, but What if I want them to see my thought process?

So here is the idea:

• You write a test
• You write sufficient code to make it pass the simplest way you can imagine
• You commit that code
• You refactor that code (micro refactoring)
• You commit that code
• You look if there is some other code that can be refactored that’s related (macro refactoring)
• You commit that code
• You push to github

I am going to experiment with this a little and see if there is any benefit at all in this approach and if people actually like reading the commits in chronological order to understand the thought process of a person.

Note: I usually commit many times (almost every 5 minutes), but not following a particular criteria (as long as the tests pass that is), that’s why I thought that this would be a good approach to keep my commits at bay and to have an order of commits.

Yesterday I announced my book on Inceptions, Inceptions - Starting a Software Project on twitter and I was totally flabbergasted about the positive feedback and retweets I got.

THANK YOU!

When you know the theme you are writing about by heard it becomes relatively easy; it’s like the text keeps flowing out of my brain through my fingers onto the paper (or rather keyboard in my case). It’s a good feeling.

There are some parts of the book which are more difficult to formulate and get across; mainly the introductory chapters and sections.

Anyhow, I am looking for someone that can help out reviewing what I write (as I write it) and giving me advice on how to write more clearly.

Who am I looking for?

You should be an excellent english speaker, ideally you have reviewed a technical book in the past (or even written one). You want to commit to spending time reading and rereading the book as I write giving me advice on how to improve the way I get the idea across to the reader.

What’s in there for you?

You will obviously receive a free copy of my book, a 30% discount on any new book I write and a special mention in the Acknowledgements section :)

Will you help me?

I remember a conversation I had with Dave Hoover a few years ago. We were talking about his recently published book Apprenticeship Patterns. I was telling him that I wanted to write something about the craft of writing software myself, but that I wanted to write a book aimed more to the Journeymen out there.

This holiday season I was struggling with my writing. I somehow could not get myself into writing more in my blog; I was suffering the known writers block. Something changed though and I decided to give Leanpub a try and get myself to write a book.

Well, actually I thought about a series of books which I will publish under the series Software Craftsmanship - The Hidden Toolbox.

The first one in the series (and hopefully not the last one) will be Inceptions - Starting a Software Project. In this book I give a recipe book as how you can run an Inception Workshop successfully and the tools you need.

Currently I am writing the activities chapter in which I describe how to run each activity you can do during an Inception Workshop.

If you are interested in the book please go to the leanpub page of the book and register your interest! It will be interesting to know for how much you’d buy it for (I have a price range in mind, but I will adapt it if there is sufficient feedback).

CodeRetreat events are awesome! I have attended and facilitated quite a few over the past years and it is always great fun.

I would love to see some other kind of retreat coming up though. A retreat were very experienced software craftsmen share their techniques with other crafters.

In this retreat each attending crafter would present her technique to the group in about 25 minutes and then the rest of the group would practice that technique for another 25 minutes. Each attending crafter would have to present a technique and also learn from the other crafters attending their techniques.

As a bonus (because I am a castle lover) the setting of this retreat would be an old European castle.

The Software Craftsmanship movement is sometimes seen as an elitist (in the bad way of the word) buch of people that are separating themselves from the rest of the software development community. Others say that we are very serious and not close to the people.

This is simply not true.

Most people saying these things have actually never really tried to talk to anyone (this I don’t know as a fact, but knowing how the people that I admire are) and just assume, from within their own positions how some people are.

Today’s idea is to create Software Craftsmanship apparel that is funny and sends some message. Like t-shirts similar to the ones in ThinkGeek with funny quotes or imagery on them.

I actually have a few great t-shirt ideas, so maybe, we at path11, will actually do something like this :)

Happy Sunday everyone!

The software development community, specially the one we belong to (the software craftsmanship community) is a very small community of professionals.

We embrace perpetual learning and a community of professionals that pushes each other to the limits; where we learn from each other.

Sometimes we don’t exactly remember from whom we learned which technique or way of working and the roots of that knowledge, of that discovery, get lost in time.

I would love to have a place where, like in a family tree I could see who has learned what from whom. This way, for instance if I pair with Corey Haines and I realize that J.B. Rainsberger has had a great influence in his style for naming and refactoring I can try and contact Joe to see if there is a chance that I can learn that skill from him.

This place (or app) would not give any clue on how good you learned what you did, but only a way to see from whom you learned.

It should also offer the possibility of (at least) two ways of relations; direct (you actually paired with that person and she agrees that that is true) or indirect (you have read a book, article, etc that influenced your style).

I love watching documentaries. They give you a glimpse of a particular theme and in some cases they wake your curiosity to dwell deeper into a theme.

Prof. Brian Cox did something remarkable with his two TV series (The wonders of the Solar System and The wonders of the Universe). If you are a hardcore physicist or astrologist you will not agree that these TV series where any good, and argue that they are only divulgation.

But there was something fascinating about them…

They got people hooked to watch Prof. Brian Cox telling how wonderful the world around us is. His young looks and passion helped a lot in the success of the series (specially amongst the younger audience).

So I thought about this and thought “wouldn’t it be awesome to find some good looking presenter (male or female) that would tell the story of software craftsmanship?”.

When I say software craftsmanship I don’t mean necessarily the Software Craftsmanship Movement, but the craft of writing software.

The presenter would travel around the world telling the story of the craft of writing software, interviewing people that where key to the practices, values and principles great craftsmen share (i.e. I could imagine interviews to Ward, Kent, Unclebob and many other people that have influenced us).

As a bonus it would show on the TV Sunday evenings ;)