Native/Browser SPA versions using ClojureScript and re-frame talk at SCBCN17

Last month I had the pleasure of giving a talk at the Software Craftsmanship Barcelona 2017 conference about what my colleague Francesc and I have been learning lately while working on the mobile and browser versions of a SPA using ClojureScript and re-frame.

I talked mainly about how re-frame's effects and coeffects, re-frame's subscriptions and modelling a UI as FSMs place you in a pit of success, i. e., a design that, according to Jeff Atwood, "makes it easy to do the right things and annoying (but not impossible) to do the wrong things".

It was my first talk in a big conference and I had some technical problems, so I was very nervous at the beginning. After a while I relaxed and felt better. In the end I received more questions than I expected and very nice feedback.

I'd like to thank Modesto for lending me his computer when mine crashed just before the talk and helping me relax.

This is the video of the talk, (thanks Autentia for recording all the talks and for being so kind to me when I was having technical difficulties). I hope you'll find it interesting:



and these are the slides that I've improved after the talk using Modesto's feedback (thanks!!): .

Thanks to Francesc and all the people in Clojure Developers Barcelona Group, Green Power Monitor and Codesai that contributed to improve the talk with their feedback. Also thanks to my colleague Antonio for "persuading" me to give a talk in a conference.

Finally, I'd also like to thank Software Craftsmanship Barcelona 2017 conference organizers for giving me the opportunity to talk at such a great conference and for all the effort they put to make this conference better, edition after edition.

Software Craftsmanship Barcelona 2015

Last weekend I attended the Software Craftsmanship Barcelona 2015. This was the first time I participate as an attendee (I had worked in the organization of the first two editions).

It was a great event. I attended very interesting talks and had amazing conversations with many people. Some of them I already knew from the Barcelona, Zaragoza, Bilbao, Canarias and Valencia community or from abroad but many of them I just met there.

If I had to highlight my favorite talk, I'd choose Accesibilidad en el software. ¿Qué es? ¿Por qué es importante? (Software Accessibility. What is it? Why is it important?) by Juanjo

Juanjo is a great developer and an accessibility specialist. He also happens to be blind.

He showed us how he programs with Visual Studio using a screen reader and knowing nearly every keyword shortcut. It was very impressive.

Personally, I found it amazing how the human brain adapts to different situations. He has developed a great memory and is able to mentally "visualize" the code with just hearing it once (at a really fast speed).

He also told us about several applications he'd made in his spare time to improve his and another blind people's daily life.

I also enjoyed very much Vicenç García-Altés' talk about Mutation Testing, Álvaro García's talk Tu carrera como una marathon (Your career as a marathon) and the Yatzy refactoring kata also facilitated by Álvaro.
 
We (the No Flop Squad) also participated in the SCBCN15.

The afternoon before the SCBCN15 we facilitated a Pre-SCBCN15 coding dojo.

We practiced doing the Business Rules kata but with the constraint of having to develop an internal DSL that make the tests read nearly as the business rules it was testing. The constraint was based on an exercise Xavi Gost and I did to practice together in one of my last visits to Valencia. This constraint forces you to stay more time on the problem space before passing to the solution space.
We received a lot of positive feedback.

On Saturday morning we gave a talk in which we spoke about an ongoing experiment that we've been developing during the last month: Hybrid Persistence.

In this experiment, we are exploring the idea of persisting different parts of the state of an aggregate on different data storage technologies depending on the kind of state. The idea is similar to Polyglot Persistence but it works at a finer grain persisting separately the identity and mutable state of each member of the aggregate. The relationships among members of the aggregate can also be persisted independently.

The experiment is still in an initial phase, so we haven't yet reached to any sound conclusions. In the talk, we explained the ideas behind this exploration, what we have seen so far (including dead-ends, mistakes and successes) and the things we'd like to try next.

On Sunday afternoon there was an Open Space .

A session that I really enjoyed and took a lot of ideas from, was Dinamizando las comunidades locales (Energizing local communities)

in which organizers and members of several communities across Spain, shared our experiments, successes and failures in trying to improve and sustain our communities.

Also while we were selecting the open space grid, someone nominated a session asking me to give a short introduction to Clojure. Surprisingly it received enough votes to be selected so I had to improvise it.

I showed some code examples and used LightTable to write and evaluate expressions on the fly while I was explaining some language features. Álvaro helped me (thanks!) writing on Juanjo's laptop the code I was writing on my laptop and showing on the screen so that he could also follow the talk using his screen reader.

I tried to demystify parentheses and prefix notation, and explain some of the simplest goodies of the language. Even though it wasn't a good talk, I think I managed to at least arise the curiosity of some of the attendees. I also invited all to come to the Clojure Developers Barcelona's Introduction to Clojure event on next October 27th.

There were so many other interesting talks I couldn't see. I can't wait for the videos to be published.

All in all, it was a wonderful event.

I'd like to thank from here all the attendees and the organization for making it possible. I'd also like to thank Netmind for letting us use their facilities for free one more time.

Kata: "Sieve of Eratosthenes" test-driven and explained step by step

Yesterday we practiced doing the Sieve of Eratosthenes kata at a Barcelona Software Craftsmanship event.

My partner Fernando Mora and I used TDD in Scala to write the code.

Today I did it once again in Clojure.

I'd like to explain here how I did it step by step in order to share it with the Barcelona Software Craftsmanship members.

I started by writing this test:

which I quickly got to green by just hard-coding the response:

In this first test I used wishful thinking to get the function and signature I wished.

Then I wrote the following test:

which drove me to generalize the code substituting the hard-coded list by a code that generated a list that was valid for both the first and the second test:

The next test was the first one that drove me to start eliminating multiples of a number, in this case the multiples of 2:

I made it quickly pass by using filter to only keep those that are not multiples of 2 and 2 itself:

Alternatively, I could have taken a smaller step by just eliminating 4, then go on triangulating to also eliminate 6 and finally refactor out the duplication by eliminating all the multiples of 2 that are different from 2.

Since the implementation was obvious and I could rely on filter, I decided not to follow that path and took a larger step.

I've noticed that my TDD baby steps tend to be larger in functional languages. I think the reason is, on one hand, the REPL which complements TDD by providing a faster feedback loop for triangulation and trying things out and, on the other hand, the power of sequence functions in those languages (in the case of this kata the Scala and Clojure ones).

Once the test was passing I started to refactor that ugly one-liner and got to this more readable version:

in which I extracted two helpers and used remove instead of filter to better express the idea of sieving.

My next goal was to write a test to drive me to generalize the code a bit more by eliminating the hard-coded number 2 in line 10 of the code.

To do it I just needed a test that forced the code to also eliminate just the multiples of 3:

Again I could have triangulated to first eliminate 9 and then 12 before refactoring but there was an easier way at this point: to introduce recursion.

But before doing that, I quickly went to green by calling the sieve function twice to eliminate the multiples of 2 and 3:

With this tiny step I both highlighted the recursive pattern and provided a safe place from which to start using refactoring to introduce recursion.

In this case I think that having tried to directly introduce recursion to make the test pass would have been too large a step to take, so I played safe.

Once in green again I safely refactored the code to introduce recursion:

Notice that this version of the code is the first one that solves the kata.

From this point on I just refactored the code trying to make it a bit more readable until I got to this version:

Finally, I wrote a more thorough test that made the stepping-stone tests that helped me drive the solution redundant, so I deleted them:

If you want to have a closer look at the process I followed, please check the commits list where I've also included the REPL history. You can also see all the code in this GitHub repository.

That's all.

I'd like to thank Barcelona Software Craftsmanship members for practicing together every two weeks, especially Álvaro García for facilitating this last kata, and eBay España for kindly having us yesterday (and on many previous events) in their Barcelona office.

Solving the Tire Pressure Monitoring System exercise (IV)

8. Achieving Dependency Inversion by extracting an interface.

Even though we are already injecting into Alarm the dependency on Sensor, we haven't inverted the dependency yet. Alarm still depends on a concrete implementation.

Now we'll show how to invert the dependency by extracting an interface.

Normally, it's better to defer this refactoring until you have more information, i.e., until the need for another sensor types arises, to avoid falling in the Speculative Generality code smell.

However, despite having only one type of sensor, we extract the interface anyway, as a demonstration of the refactoring technique.

So first, we rename the method that is being called on Sensor from Alarm, to make it less related with the concrete implementation of Sensor.

Then, following Kent Beck's guidelines in his Implementation Patterns book to name interface and classes, we renamed the Sensor class to TelemetryPressureSensor.

This renaming, on one hand, frees "Sensor" name so that we can use it to name the interface and, on the other hand, gives a more accurate name to the concrete implementation.

Then we extract the interface which is very easy relying on an IDE such as Eclipse or IntelliJ IDEA.

This is the generated interface:

This is Alarm's code and tests after removing any references to the pressure sensor from the naming:

Now we have a version of Alarm that is truly context independent.

We achieved context independence by inverting the dependency which makes Alarm depend on an abstraction (Sensor) instead of a concrete type (TelemetryPressureSensor) and also by moving the specificity of the SafetyRange configuration details towards its clients.

By programming to an interface we got to a loosely coupled design which now respects both DIP and OCP from SOLID.

In a dynamic language, we wouldn't have needed to extract an interface, thanks to duck typing. In that case Sensor would be a duck type and any object responding to the probe method would behave like a sensor. What we would have needed to do anyway, is the process of renaming the method called on sensor and eliminating any references to pressure from the names used inside Alarm, so that, in the end we have names that make sense for any type of sensor.

9. Using a builder for the Alarm.

Finally to make the Alarm tests a bit more readable we create a builder for the Alarm class.

That's all.

If you want to follow the whole refactoring process in more detail, I committed the code after every passing test and every refactoring. You can find the step by step commits here. The current version of the code is in this GitHub repo.

I hope this would be useful for the people who couldn't attend to the events (the SCBCN one or the Gran Canaria Ágil one)and also as a remainder for the people who could.

I'd also like to thank Luca Minudel for creating and sharing these great exercises and Álvaro García for pairing regularly with me and solved this exercise together.

This is the last post in a series of posts about solving the Tire Pressure Monitoring System exercise in Java:

1. Solving the Tire Pressure Monitoring System exercise (I)
2. Solving the Tire Pressure Monitoring System exercise (II)
3. Solving the Tire Pressure Monitoring System exercise (III)
4. Solving the Tire Pressure Monitoring System exercise (IV)

Solving the Tire Pressure Monitoring System exercise (III)

6. Improving the semantics inside Alarm and adding a new concept to enrich the domain.

Now we turn our attention to the code inside the Alarm class.

We first rename a local variable inside the check method and the method we are calling on Sensor so that we have new names that have less to do with the implementation of Sensor.

Next, we extract the condition inside the check method to an explanatory helper: isNotWithinSafetyRange.

This is the resulting code:

Notice that the Alarm class contains a data clump.

The constants LowPressureThreshold and HighPressureThreshold don't make any sense the one without the other. They together define a range, to which we have already referred both in production and test code as a safety range.

We remove the data clump by creating a new concept, the SafetyRange value object:

7. Moving Specificity Towards the Tests.

If you check the tests in AlarmShould class, you'll see that it's difficult to understand the tests at a glance.
Why is the alarm on in some cases and off in some other cases?

To understand why, we have to check Alarm's constructor in which a SafetyRange object is created. This SafetyRange is an implicit configuration of Alarm.

We can make the code clearer and more reusable by moving this configuration details towards the tests.

J. B. Rainsberger explains this concept of moving specificity towards the tests in this video which is embedded in his Demystifying the Dependency Inversion Principle post.

So we change the signature of the Alarm constructor so that the SafetyRange is injected through it.

Now the configuration detail is explicit and it's easier to understand at a glance why any test pass or not.

Moreover this change makes Alarm more reusable.

This is the third post in a series of posts about solving the Tire Pressure Monitoring System exercise in Java:

1. Solving the Tire Pressure Monitoring System exercise (I)
2. Solving the Tire Pressure Monitoring System exercise (II)
3. Solving the Tire Pressure Monitoring System exercise (III)
4. Solving the Tire Pressure Monitoring System exercise (IV)

Solving the Tire Pressure Monitoring System exercise (II)

4. Introducing a test harness.

To be able to refactor Alarm, we first need to protect its current behavior (its check method) from regressions by writing tests for it.

The implicit dependency of Alarm on Sensor makes Alarm difficult to test. However, it's the fact that Sensor returns random values that makes Alarm impossible to test because the measured pressure values it gets are not deterministic.

It seems we're trapped in a vicious circle: in order to refactor the code (improving its design without altering its behavior) we must test it first, but in order to test it, we must change it first.

We can get out of this problem by applying a dependency-breaking technique called Extract and Override call.

4.1. Extract and Override call.

This is a dependency-breaking technique from Michael Feather's Working Effectively with Legacy code book. These techniques consist of carefully making a very small modification in the production code in order to create a seam:

A seam is a place where you can alter behavior in your program without editing in that place.

The behavior we want to test is the logic in Alarm's check method. This logic is very simple, just an if condition and a mutation of a property, but as we saw its dependence on Sensor makes it untestable.

To test it, we need to alter the collaboration between Alarm and Sensor so that it becomes deterministic. That would make Alarm testable. For that we have to create a seam first.

4.1.1. Extract call to create a seam.
First, we create a seam by extracting the collaboration with Sensor to a protected method, probeValue. This step must be made with a lot of caution because we have no tests yet.

Thankfully in Java, we can rely on the IDE to do it automatically.
4.1.2. Override the call in order to isolate the logic we want to test.
Next, we take advantage of the new seam, to alter the behavior of Alarm without affecting the logic we want to test.

To do it, we create a FakeAlarm class inside the AlarmShould tests that inherits from Alarm and overrides the call to the protected probeValue method: Now using FakeAlarm we are able to write all the necessary tests for Alarm's logic (its check method):

Now that we have a test harness for Alarm in place, we'll focus on making its dependency on Sensor explicit.

5. Making the dependency on Sensor explicit.

Now our goal is to inject the dependency on Sensor into Alarm through its constructor.

To remain in the green all the time, we use the Parallel Change technique.

With TDD we drive a new constructor without touching the one already in place by writing a new behavior test with the help of a mocking library (mockito):

And we make the new test pass.

In the version of Alarm above, we also used the Parameterize Constructor technique to make the default constructor (used by FakeAlarm) depend on the new one.

Then we use the new constructor in the rest of the tests one by one in order to stop using FakeAlarm.

Once there are no test using FakeAlarm, we can delete it. This makes the default constructor become obsolete, so we delete it too.

Finally, we also inline the previously extracted probeValue method.

This is the resulting test code after introducing dependency injection in which we have also deleted the test used to drive the new constructor because we think it was redundant:

and this is the production code:

By making the dependency on Sensor explicit with dependency injection and using a mocking library we have simplified Alarm tests.

This is the second post in a series of posts about solving the Tire Pressure Monitoring System exercise in Java:

1. Solving the Tire Pressure Monitoring System exercise (I)
2. Solving the Tire Pressure Monitoring System exercise (II)
3. Solving the Tire Pressure Monitoring System exercise (III)
4. Solving the Tire Pressure Monitoring System exercise (IV)

Solving the Tire Pressure Monitoring System exercise (I)

1. Introduction.

Last week I facilitated a guided kata for a Gran Canaria Ágil event in Aplicaciones Informáticas Domingo Alonso (thanks to both for inviting me) in which I explained a possible way to solve Luca Minudel's Tire Pressure Monitoring System exercise.

This exercise is part of his TDD with Mock Objects: Design Principles and Emergent Properties exercises.

I like these exercises very much because they contain clear violations of the SOLID principles but they are sill small enough to be able to finish the refactoring in a short session at a slow pace. This makes possible to explain, answer questions and debate about design principles, dependency-breaking techniques and refactoring techniques as you apply them.

I'd like to thank Luca Minudel for creating and sharing these great exercises.

I co-facilitated this exercise with Álvaro García several month ago in a Software Craftsmanship Barcelona event and we received a lot of positive feedback.

That time, many people couldn't attend due to space limits, so I'd like to make a summary of the exercise here for them.

2. The initial code.

The initial code has two classes: Alarm and Sensor.
The exercise focuses on refactoring the Alarm class.

3. SOLID violations, hidden dependencies.

All the logic of the Alarm class is in the check method.

Alarm's main problem is that it depends on a concrete class, the sensor that measures pressure values.

This is a clear violation of the Dependency Inversion principle (DIP) which states that:

Abstractions should not depend on details.

Details should depend on abstractions.

To make things worse this dependency is hidden inside Alarm's check method (see J. B. Rainsberger's The Pain of Implicit Dependencies post).

The violation of the DIP and the implicit dependency makes also impossible to fulfill the Open Closed Principle (OCP).

Fulfilling those two principles will be one of the main goals of this refactoring.

This is the first post in a series of posts about solving the Tire Pressure Monitoring System exercise in Java:

1. Solving the Tire Pressure Monitoring System exercise (I)
2. Solving the Tire Pressure Monitoring System exercise (II)
3. Solving the Tire Pressure Monitoring System exercise (III)
4. Solving the Tire Pressure Monitoring System exercise (IV)

Updated my A bit about JavaScript functions talk (with videos in Spanish)

Before the summer, I updated the contents of my talk about JavaScript functions to prepare a master class (that finally became two) for the wonderful Devscola project.

These are the updated slides and these are the two recorded master classes (in Spanish):

• Master class 1
• Master class 2

I hope you'll find them useful.

Kata: Mars Rover in Clojure using multimethods

Yesterday we had a coding dojo in Clojure Developers Barcelona meetup.

We practiced together doing the Mars Rover kata.

I had already done this kata in Java and C++ before (several times) using the state pattern to eliminate all the conditionals on the rover direction and the command pattern to decouple the translation from the messages sent to the rover into commands acting on it.

As usual I used a mix of TDD and work on the REPL to code this Clojure version.

To document the process I committed the code after every passing test and every refactoring and also committed the REPL history. You can find the commits step by step here.

After making the rover rotations work I had a huge cond on the rover direction with an if branching on the command value inside each case.

It was time to refactor.

The suggestion in the kata was to try to eliminate conditionals using maps, multimethods and/or protocols.

First, I used multimethods, dispatching on the rover direction and the message it was receiving just to see how multimethods work.

It took me a while to make it work because I had a error in the arity of a defmethod and the stack trace was difficult for me to understand.

Then I realized that it was much better to separate the translation of messages into commands from the commands themselves. To do it I used a map that associate each message to the command multimethod:

Here you can see one of the multimethods:

From here on, coding the remaining commands using TDD was very easy. I just had to write a failing test and then make it pass by implementing its corresponding defmethod.

Once all the possible commands were working, I started with the functionality of wrapping the rover in a world.

If you check the commits, you'll see that I tried several approaches here because I wasn't sure how to model the world.

In the end, I decided to model the world as a map with a :wrap-fn key associated to the wrap function for a given kind of world. I passed the world map as a keyword parameter to the receive function which had a default value equal to infinite-world whose :wrap-fn was the identity function. That way all my previous tests continue to work without having to change them.

Then I started doing TDD to code the wrap function for a kind of world called squared-world which was created by a factory function by the same name.

Finally, I started with the obstacles which were modeled as a list of positions (which were represented by maps like {:x 1 :y 2}) associated to the :obstacles key in the world map.

To code the hit-obstacle? function I used the REPL for the first time (you can check all my tests on the REPL history which I also committed) to try to make it work using the some function.

After that I just added a validation to check if the initial position of the rover was on an obstacle.

These are the resulting tests using Midje:

and this is the resulting code:

I'm not sure if this is a good factorization for this problem in Clojure, (I feel that what I did for having different implementations of the wrap function is still a bit OO-ish), but it was a good exercise to practice with multimethods and start exploring their possibilities.

You can find the code in this GitHub repository.

Next time I'll try doing the same exercise using protocols instead.

I enjoyed a lot this coding dojo.

Thanks everyone for coming and Akamon for letting us use its facilities.

-----------

Update: I continued working in this code on Separating Mars Rover code into different name spaces, Mars Rover code version using protocols instead of multimethods and Mars Rover using a finite state machine implemented with mutually recursive functions and trampoline

Scala Developers Barcelona TDD introduction session

Two weeks ago I facilitated an introduction to TDD in a Scala Developers Barcelona event.

First, I gave a very short introductory talk about TDD, (these are the slides).

After the talk, I coded a simple exercise to help the attendants get a feeling of the TDD flow.
I tried to stress the importance of creating a list of examples first and choosing the next test so that the code could grow in small steps. I also talked about wishful programming, going from red to green quickly and the importance of refactoring to sustainable TDD.

I used Clojure to code the exercise.

I feel that, somehow, using Clojure got in the way of the message I wanted to transmit. Next time I'll use a language which is more familiar to all the attendants.

This is my solution to the exercise in Clojure where you'll find commits after each passing test and each refactoring, so you can follow the process.

Finally, we started doing TDD with a simple kata.

Ignasi, Jordi and I were all the time visiting the different pairs, helping with doubts about TDD or Scala and commenting with them how their solutions were growing test after test.

I think that during this time I had the chance to clarify some things that hadn't come across before because of the lack of familiarity with Clojure.

At the end, we had a short debate about TDD.

I'd like to thank the Scala Developers Barcelona organizers for inviting me to facilitate this dojo. I had a great time and I hope that, the attendants could get something useful from it in spite of my using Clojure for the first example.

I'd like to also thank all the attendants for coming and Álvaro for telling the Scala Developers Barcelona organizers about me.

Clojure Developers Barcelona: Introductory talk about Clojure functions

Last week I gave a talk about Clojure functions for some of the Clojure Developers Barcelona study group members.

This is the the code I showed on Lightable to explain a bit about Clojure functions:

I had a great time and learned a lot preparing this talk.

During the talk I mentioned some destructuring techniques I had explained more deeply in a previous talk.

This time there were many more attendants than in previous events of the group which is really great.

Thanks all for coming!

I hope we'll go on learning together in next events.

Clojure Developers Barcelona: Reverse Polish Notation Calculator kata

Last Tuesday I facilitated a kata for the Clojure Developers Barcelona Group hosted by Akamon.

We've been doing several Clojure katas and talks during the last two months within a small study group (mainly composed of people who work in Akamon) as a preparation to bring back to life the Clojure Developers Barcelona Group.

This kata was the first one we did as Clojure Developers Barcelona Group.

We did the Reverse Polish Notation Calculator kata which is a very nice kata to practice.

Although 10 people had RSVPed that they were coming, in the end we were seven people: 4 Akamon workers, 2 people non-related to Akamon (a second-timer and a newcomer) and me. We formed 3 pairs and worked in the kata from 18:30 to 21:00.

I had a great time facilitating the kata, solving doubts and talking about Clojure.

If you like you can share your solution in the Clojure-Barcelona Google+ community. At the moment of writing this post, you'd find there two solutions: Rafa's and mine.

To finish I'd like to thank Akamon for hosting our events and all the attendants (Jorge, Jordi, Sergi, Álvaro, Rafa and Eloi) for their enthusiasm to learn and share in an afternoon of Clojure.

Conferences in 2014

These are the conferences I attended last year:

• Craft, Software Craftsmanship Matters
• Barcelona Ruby Conference
• Software Craftsmanship Barcelona 2014* 
• PyConEs 2014
• Conferencia Agile Spain 2014**

* I was part of the team that organized it.
** I co-chaired the Dev Practices & Craftsmanship track.

Clojure Developers Barcelona: Talk about Clojure destructuring

Today I gave a talk about destructuring in Clojure for some of the Clojure study group members.

This is the "clean version" of the code I wrote on the fly on Lightable to explain destructuring:

I had a great time and learned a lot preparing the talk.

I hope this small study group will be help to get the Clojure Developers Barcelona Group up and running again soon.

Thanks all for coming.

Update

I repeated this talk yesterday.

I updated the code in the gist shown above.

Kata: Studious Student in Clojure

Last week Leo Antoli facilitated a kata for Software Craftsmanship Barcelona.

We had to solve the Studious Student exercise.

Leo wanted us to experiment how useful testing is in an exercise like this one, so we divided the group in some pairs using TDD, some pairs testing after writing the code and some pairs not testing at all.

The exercise is a bit tricky as pairs that were not testing discovered at the end, whereas the ones doing TDD or testing after coding discovered early during the process.

After an iteration of one hour, we had a very interesting debate about automatic testing.

This is my solution of the exercise in Clojure:

and these are the tests using Midje:


You can see all the code in this GitHub repository.

I'd like to thank Leo for being so kind and sharing his knowledge with us.

Introduction to TDD with Barcelona JUG and SCBCN

Yesterday Álvaro (@alvarobiz) and I facilitated the Fractions Arithmetic kata. It was an activity organized by the Barcelona Java Users Group and the Barcelona Software Craftsmanship Community. Thanks to Ignacio Cougil and Jonathan Vila for having the idea and making this event possible.

Since the kata was meant to be an introducction to TDD, we had first a short talk explaining a bit what TDD is about.

The talk took longer than I expected because we discussed about topics, such as, TDD, object-oriented design or refactoring. Thanks for the questions and comments, I think they lead to interesting discussions.

Then we started the kata working in pairs.

In the Fractions Arithmetic kata you have to develop the arithmetic of rational numbers but, in this occasion, we limited ourselves to just developing the addition of rational numbers. We modeled the rational numbers as value objects and the fractions had to be reduced.

Álvaro and I went from pair to pair commenting with them their approaches, helping when some pair was stuck, talking about some possible refactorings, etc.

I enjoyed the experience a lot and I hope all participants took something useful home.

We talked about some books and talks that might be interesting to learn more about TDD.

These are the links:

• TDD books.
  • Test Driven Development: By Example by Kent Beck. Read it to know first-hand the original TDD source
  • Diseño Ágil con TDD by Carlos Blé. A very interesting explanation of TDD in Spanish which has a Creative Commons license
  • Growing Object-Oriented Software Guided by Tests by Steve Freeman and Nat Pryce. A wonderful advanced TDD and OO book which illustrates the london School of TDD.
  • Test Driven, Practical TDD and Acceptance TDD for Java Developers by Lasse Koskela. A really great TDD book. Its second part is specially dedicated to apply TDD to specific Java technologies
  • Modern C++ Programming with Test-Driven Development by Jeff Langr. Another great book on TDD which, due to its more recent publication, also contains explanations and worked examples on the Transformation Priority Premise and the Mikado method.
• Refactoring books.
  • Refactoring, Improving the Design of Existing Code by Martin Fowler. A must-read.
  • Refactoring to Patterns by Joshua Kerievsky. Another great book which reconciled two worlds.
• Some more advanced talks we mentioned (and an extra one I forgot to mention):
  • Listening to Test Smells by Steve Freeman
  • Design How Your Objects Talk Through Mocking by Konstantin Kudryashov
  • Fractal TDD: Using tests to drive system design by Steve Freeman

Thanks to all for coming. We'll see each other in the next one.

A bit about JavaScript functions

Yesterday, I gave a talk about JavaScript functions in Vilanova i la Geltrú.

These are the talk slides.

The talk focused in introducing the following concepts:

• Functions as first class entities
• Closures
• Higher-order functions

It was based on the readings I've done lately to learn JavaScript:

• JavaScript Enlightenment, Cody Lindley
• JavaScript: The Good Parts, Douglas Crockford
• JavaScript Allongé, Reginald Braithwaite

Here is the code of the examples used in the talk. Most of them were taken from Reginald Braithwaite's wonderful book. I also used an example from this other post of this blog: Strategy pattern and higher-order functions?.

I'm a shy person and it's difficult for me to talk in public but in the end I enjoyed the experience. I feel that trying to share what I've learned has improved my understanding of the topic.

I hope that the talk has somehow awaken a bit of interest for functional techniques in JavaScript among the attendants.

I'd like to thank you José Carlos for talking me into giving this talk to share what I have been learning lately about JavaScript functions and functional programming.

I'd also like to thank Edgar Costilla for letting us use Espai Feedback great facilities.

Finally, I'd like to thank the attendants for their interest and questions.

Craft Conference 2014

Last month @pclavijo and I went to the Craft Conference in Budapest.

It was my first international conference and it was a great experience.

This were my favorite talks in no particular order:

• Conway's Law and you: How to organize your organization for optimal development, Michael Feathers
• Polyglot Data, Greg Young
• Responsibly maximizing craftsmanship in software engineering, Theo Schlossnagle
• Acknowledging CAP at the Root - in the Domain Model, Eric Evans
• Find the right abstraction level for your tests, Gerard Meszaros
• Going reactive: event driven, scalable, resilient and responsive systems, Jonas Bonér
• Coaching teams through change, Rachel Davies
• Building on SOLID Foundations, Nat Pryce and Steve Freeman
• Jackstones: the journey to mastery, Dan North

This other one I couldn't go but @pclavijo said it was great, so it's in my talks queue:

• How I learned to stop worrying and love flexible scope, Gojko Adzic

Birthday greetings refactoring kata at Barcelona Software Craftsmanship: step by step commits and screencasts

Last Monday I hosted an event for Barcelona Software Craftsmanship community.

We practiced refactoring and learned about ports and adapters using Matteo Vaccari's Birthday Greetings kata in refactoring mode. This is the initial code in Java that we tried to refactor.

I prepared several slides to introduce what we were going to do. I thought that we could just start refactoring for two hours right after this explanation, but, thanks to the suggestions of some attendees, we changed the plan and did two iterations (extracting the employees repository in the first one and extracting the greetings sender in the second one) with a retrospective in the middle.

This was a really good idea because it gave us the opportunity to debate about different approaches to this refactoring and about ports and adapters. Some very interesting points were raised during those conversations and we could exchange personal experiences and views about this architecture and refactoring. This kind of conversations are a very important part of practicing together and they enrich the kata experience.

I think I have a lot to improve as an event host. Next time I'll make explicit that attendees need to bring their laptop and I'll try to help more the beginners.

I had published a possible solution to the kata, but it was just the final solution not the intermediate steps. Some attendees said that they would like to see how this refactoring could be done in small steps. For that reason, I redid the kata again at home committing after every refactoring step and recording the process:

• Step by step kata commits
• Screencasts of most of the process: Extracting the employees repository and Extracting the greetings sender

Take this recordings with a grain of salt because I'm still working hard to improve my refactoring skills.

Well I hope this might be useful to someone.

Just to finish, I'd like to thank all the attendees for coming, I had a great time. I'll try to do it better the next time.

I'd also like to thank netmind for their support to our community giving us a place and the means to hold Barcelona Software Craftsmanship events. Having a regular place for our events makes everything much easier.

So far the events have had much more attendees than we had expected. In fact, this last Monday we nearly run out of space. If this trend continues, we'll probably need to ask for a bigger room to hold future events.

-----------------------------------------------------------------------------

PS: Christian Soronellas shared a version of the initial code in PHP.
Thank you very much Christian!

My path to Clojure: Clojure Developers Barcelona meetup

Last week I attended the first Clojure Developers Barcelona meetup.

There we could listen a very interesting talk by Jiří Knesl:

• Writing Readable Clojure* Code

It was a very interesting talk full of common sense.

I think we all were a bit surprised because none of us expected there were going to be so many people interested in or already working with Clojure

There were also many ideas about new activities.

I think this has just been the beginning of a very interesting community which will produce many interesting activities.

Thanks to Jiří Knesl for his great talk and to José Raya and Jordi Pradel for organizing the meetup.