A week in the UK

Talking at SkillsMatter

Last week was very intense indeed. I gave my first talk at Skills Matter (video here).

I must say I am not content with my talk because my English was rubbish but on the other hand I am glad that it provided value to some attendees. That is why I did it. I am also glad because it gave me the opportunity to meet very nice people (we were having some chats before the talk, and afterwards in the pub). And I will do better the next time 🙂 I have learned several lessons.

First one, I will not give talks right after landing a plane. The fact that I could arrive late if the flight or the train was late, made me very nervous, I went running to the venue and it doesn't help to concentrate. I must fly the day before.

Second one, when I talk in English, I must have pretty much everything I want to say written in cards so that if I can't find the words, I can just read. My English is not too bad when I am relaxed but under pressure, it's much harder to find the words and pronounce. When giving a talk, I pay close attention to attendees, timing and the way I am expressing myself. All these concerns difficult my capacity to talk in English.
I'll be talking advanced English lessons with natives, aiming to get fluent some day. But in the meanwhile I must have the written speech as a backup.
When my friend Ivan Stepaniuk and I gave a talk in the Agile Testing Days last year, everything was written and it went better. Also the fact that we were two guys made it easier.

Third one, audience's feedback is different depending on the culture. When I talk in Spain I can clearly read faces and see if they follow me or not. But this time it was really hard for me to now if they were following me. I must not loose concentration regardless of my difficulties interpreting audience's feedback, but just keep going unless they actively ask.

Fourth, talking with braces is f***g annoying! 🙂

If I keep practicing and taking lessons, with the help of a trainer I'll become better.

Participating in the SocratesUK open space

The following days I participated in the #socratesuk open space, organized by the London Software Craftsmanship Community.
2013-09-21 18.31.10

A great event in the countryside, an incredible venue.

It started with lightning talks and a fish bowl. The next two days there were talks, discussions and time for pairing with people. Pairing was the part I enjoyed the most. After dinner people used to meet in the bar to talk, drink and pair.
The last day we spent the morning hiking together along the countryside in a beautiful sunny day.

2013-09-19 16.23.52

Rachel Davies did an excellent job facilitating the whole event. And people were friendly and willing to share and learn

Having everything in the same place was very handy to meet different people. And the food was good. I've learned, shared, and met very nice people. It's been totally worth participating.

Thank you very much to the organizers and all the participants.
2013-09-22 10.26.53

I'd like to participate in Socrates Germany next year as well as Socrates UK.

Several people said we must organize Socrates Canarias. What do you think? shall we? 🙂

See more pictures here





Push the query down: Tell, don’t ask

"Feature envy" is a typical code smell in Object Oriented Programming. It can be appreciated when code talking to an object accesses directly to that object's fields or properties, from the outside, breaking the encapsulation.

  1. // feature envy:
  2. fullName = person.name + " " + person.surname;
  4. // possible solution:
  5. fullName = person.fullName();

The "Tell, don't ask" principle helps to avoid feature envy when used properly, by using a declarative approach instead of a procedural one. This is, rather than asking a method for a value to make a decision based on the answer, we tell the method to perform an action. Any decisions based entirely upon the state of one object should be made "inside" the object itself. This principle promotes encapsulation, and low coupling. Query methods (method returning values) can't be totally avoided, in fact they shouldn't, but they can be pushed down to places where coupling is affordable, thus avoiding coupling high level classes, reducing the impact of changes.

"Tell, don't ask", and "Law of Demeter" were explained  by Andy Hunt and Dave Thomas in a IEEE Software column and on their site. Also recently by Martin Fowler.

Recently, I came across an "extract method" refactoring promoting this principle that makes the code easier to read and maintain:


  2. // Service class:
  3. ...
  4. public virtual void RequestPin(User user) {
  5. var newPin = PinBuilder.CreateNewPin();
  6. PinRepository.SaveNewPinFor(newPin, user.UniqueIdentifier);
  7. SmsProxy.SendSms(user.Phone, CreateSMSMessage(newPin));
  8. }
  9. ...


  2. // Service class:
  3. ...
  4. public virtual void RequestPin(User user) {
  5. var newPin = PinBuilder.CreateNewPin();
  6. user.ResetPIN(newPin, PinRepository);
  7. user.RequestSMS(CreateSMSMessage(newPin), SmsProxy);
  8. }
  9. ...
  11. // User class:
  12. ...
  13. public void ResetPIN(string newPin, PinRepository pinRepository) {
  14. pinRepository.SaveNewPinFor(UniqueIdentifier, newPin);
  15. }
  17. public void ReceiveSMS(string message, SmsProxy smsProxy) {
  18. smsProxy.SendSms(Phone, message);
  19. }
  20. ...

This refactoring brings several advantages. First, we remove feature envy, because properties "UniqueIdentifier" and "Phone" are used inside the User object. So the data and the behavior are in the same place. If I have to change the field in the future, it will be clear what is it affecting to. Second, the service code is easier to read and encapsulates details that should not be visible there.

It looks weird at first, sending a repository or a service instance as a parameter to an entity's method. I usually do it as I refactor, not upfront. The tests don't need to be changed if they are well-written.

Getting started with Mercurial and TortoiseHG Workbench

A version control system should be easy to use, at least when you just need to perform basic tasks.

This is why I like Mercurial. It's powerful yet easy. And TortoiseHG is an excellent client app. It's got the same GUI in Linux, MacOS and Windows. This is a brief tutorial:


We are going to use the TortoiseHG Workbench. So let’s open up the workbench now. If it’s the first time we open the workbench we must tell  TortoiseHG what is our username. Open the settings window through the “File” menu. Select “Commit” on the left hand side and introduce some username on the right.

Now we need to create a repository. That can be done through the “New Repository” in the “File” menu. We just need to indicate the folder. It can contain source code already.

tortoise_ready_to_commitThe “commit view”, is where pending changes (uncommitted) can be seen. To display this view click on the green tick button on the top. From this view we can see changed files and their contents.
If there has been changes while this view was displayed, we need to refresh (blue circle button in the middle of the screen) in order to
see them.
Finally, the commit needs a comment that goes into the comment area. Text from previous comments can be retrieved in case we want to reuse the same comment. See the “Copy message” dropdown right on top of the comment area. Once the commit comment is introduced we just need to click on the “Commit” button on the right hand side.
If we need to commit the change into a new branch, we can do that clicking on the label “Branch: default” right on top of the comment area.


From the "commit view" it's also possible to track new files. This is one way we can add existing source files into the repository or files that we create later. Using the right mouse button over the pink file

(unversioned file) pops over the menu with the option to add. The same menu also gives the choice to discard changes made on the selected file (the “Revert” menu item). Another useful item in the menu is the “File History” of each file, which opens up in a new window. That window shows only commits where the selected file was changed.

tortoise_enabling_filter_barThe second most common operation we do with TortoiseHG is searching for commits. The “filter bar” must be enabled for that. Then we can write any word that we want to search for in the commits comments. The filter bar also admits filter commands. For example to search for commits made by user with name John write “user(‘john’)” on the filter bar.

Version control and TDD

I use the VCS to keep track of my TDD flow. It serves as documentation for others and saves me time when I want to jump back to a previous state. I usually commit on red (test failing), on green (test passing) and eventually on refactor. To be efficient with that, I don’t worry much about the commit comment. I prefix the comment with “red:”, “green” or “refactor:”. In red, I copy the name of the test as part of the commit comment. On green I don’t need to add anything. On refactor, sometimes I add the name of refactor used (i.e “refactor: extract method”).

tortoise_filtering_commitsPeople coming from CVS or Mercurial are used to commit only when the code compiles and tests pass, because a  commit affects the  other teammates. The biggest advantage of DVCS over centralized systems is that our commits don’t affect others. So now a commit is just a snapshot of the code. And we should take as many snapshots as needed. Doing this properly we will never find ourselves struggling to come back to a previous state where everything was working. We can just discard the changes (revert) and continue from the last safe point. This technique is explained in detail in the Agile Record Magazine, issue 9, page18