furniture
Inflatable Water Slide

A week to remember in Barcelona

March 27th, 2014

Last week was awesome, I went to Barcelona to run two training courses. Well, one of them was my yearly session at the Postgraduate on Agile Methods at La Salle (Universitat Ramon Llull). The first postgraduate in the world on Agile Methods. I explain eXtreme Programming, together with my good friend Rubern Bernardez,  during 6 days (3 weekends).

PMA 2013/2014

PMA 2013/2014

 

This has been my third year at the PMA and it's been really nice. The selection process for participants went very well thanks to Xavier Albaladejo and so the group was excellent. People have made an endeavor to understand the XP practices and the values behind. Even project managers, people that have been away from code for years, were test-driving the exercises in pairs.  The fact that decision makers come to the class and get to appreciate the benefits of clean code and XP is very important in my opinion.  Because they can encourage and tell developers later. In the group there were testers and developers too. The different mindsets together were very interesting when facing code. Enriching experience for everybody. Thank you all for this great PMA edition. Special thanks to Xavi and to Quim Ibañez for his kindness and support.

 

During the week, I gave one of my TDD training courses, this time open to the public. In general, public courses are more energizing than in-house, because people are willing to learn and participate. They have to pay for their ticket or ask their companies and that makes a difference. This time I got to know several members from the Barcelona Software Craftsmanship Community. The level in the training was very high, in fact, it was more an exchange than a teaching session. There were many interesting discussions and retrospectives whilst looking at the code in the projector.  It's been also very nice to meet old friends and observe how they have progressed over the last couple of years. Specially Manuel Rivero who has made an outstanding progress in his career and now let me learn from him.

 

TDD Training in Barcelona

TDD Training in Barcelona (open to the public)

This experience reminds me my first open course in Madrid in 2010, when I got to know people that are now good friends and that today, run their own training courses on TDD and clean code or lead teams. So I believe that we have started here a wonderful relationship and that we will cross roads soon again. There was magic in the air.

I have to say thank you to my good friend Javier Gomez for all the support and the hosting,  as the event happened in Ricoh Spain. In this kind of courses I get to know great programmers that usually end up being colleagues or collaborators at some point ;-)

Coding dojo - Barcelona Software Craftsmanship

Coding dojo - Barcelona Software Craftsmanship

 

Thank you very much also to all the folks that came to the coding dojo that we had on Monday evening, hosted by Barcelona Software Craftsmanship, thanks to Manuel Rivero, Beatriz Martin and Jaume Jornet. In my opinion the community is very healthy in Barcelona, congratulations.

I was an IronHacker at the 2nd edition

February 24th, 2014
Teaching TDD

TDD class at the IronHack 2nd edition (picture by @JackLondon84)

Last week I was the teacher in the second edition of the IronHack, well for the last two days of the week. This time I've joined the group on their second week rather than the fifth. So I've been the one introducing unit tests. It's been quite challenging as it had to be using JavaScript. Many new concepts at the same time. Really hard for the participants but eventually absolutely all of them understood the benefits of unit tests and even the TDD cycle. They got the point with TDD. Fortunately,  my friend Fernando Moreno (who was a participant in the previous edition), was helping me out with the class. He was solving doubts and helping with technical problems and that made a huge difference. Being two people answering questions, was the key for the group to progress with steady pace. I am so grateful to Fernando, a great teacher assistant.

The group has a great potential, this training course is going to be a remarkable milestone in the life of many participants. It's been a pleasure meeting the folks.

And... you know what? pretty much all the participants from the first edition have a job already. And I know that some of them are really interesting positions. This is great news, I had the chance to talk with four of them and they are very enthusiastic about their new careers. This fact says a lot about the IronHack project and I am glad for being part of it. The more I know the project and the people behind it, the more I like it.

On Thursday evening Marta Fonda (from edition one) came up to give a talk on personal branding after my class, it was a nice surprise and we had a great time with beers afterwards.

On Friday I organized a small coding dojo in the same venue and I had the chance to pair with Sergio Revilla and Vishal  Shahdadpuri, from the first and second editions. We had a great time, I could appreciate Sergio's evolution which is impressive and we learned from each other. Pasku came out with a nice solution in Ruby. We ended up with a nice solution in JavaScript, also using a functional style.

I will back in the IronHack this summer in Barcelona. Check out their new courses on iOS development, in Madrid & Barcelona (summer and autumn).

Test Driven Development with iSQI

December 4th, 2013

iSQI logo

I am happy to announce that the work  I've been doing in the last quarter in collaboration with iSQI is now official. We have prepared a new TDD training based on the successful course that I've been running in Spain for about 3 years. The new training is now part of iSQI's Certified Agile program, so those who want to take the exam after the course will become certified (if they pass it).

iSQI is a well-known organization in Europe specially among testers. Their CAT (Certified Agile Tester) is quite popular and I can tell is a good training because I participated in one edition just to see how they work. Now iSQI also wants to provide more training options for developers.

I've created a hand book for the participants and a guide for trainers, updating my original course with an additional day and new exercises.  In January I'll be in Berlin running the first Train the Trainers (TTT) where developers passing the exam will become trainers entitled to run official courses and certify other developers.

I do know this training provides great value to developers. I encourage people new to TDD to participate in the training because I know they will learn. I would discourage those who want just the certification because this one is not easy to get.  The exam is mostly coding to demonstrate that candidates really understand TDD. Last month we had the first pilot training in Potsdam (Berlin) and only half the participants passed the exam.  Fortunately all of them learned something new and I can tell that if they keep practicing, they will pass the exam in a few months. But at the same time I am satisfied that not everybody passed the exam because we had some people that haven't been coding in the recent years and I felt they were not ready yet.

I don't know about other certifications because I don't have any, and the value of this training is not in the certification either but in the important lessons participants learn. However I can confirm that the people passing this exam will know what TDD is, and what it's not and that provides value too. We are doing a good job there.

My challenge now is to train other trainers so that we preserve the essence of the course adding even more value and quality.  If you are a seasoned test-driven developer please join us as a trainer :-)

We know TDD is not mainstream and will probably never be, but I see in this a great opportunity for TDD to reach more developers. An opportunity for developers to feel comfortable asking their managers for three days to come and practice and then keep on practicing on a regular basis.

Even though the title of the training is TDD, we cover some basics on clean code and SOLID design principles to make sure we triangulate towards well-designed code. The emphasis is on good naming and removing duplication. The first day is all about refactoring, unit tests, and design principles.

For my friends in Spain I have to say that we would like to translate the materials to Spanish and run a TTT somewhere in Spain and also in Latinamerica. Probably in Mexico and Colombia. But we don't know when is this going to happen or whether it will happen eventually. For now, all is in English and the first editions will happen in Berlin. But if I can give the course with my bad English, you can for sure participate ;-)

All the information and contents about this training is here.

 

 

Mock objects on JavaScript

November 24th, 2013

Many frameworks use the word "mock" for what in reality are "spies". But that's OK, the work "mock" in English covers actually all the possible test double types...

However according to G. Meszaros, a mock object is a specific type of test double that is configured with expectations before exercising the system under test. During the execution the mock compares the calls being made, to its expectations failing if they don't match.

The two frameworks I use for test doubles in JavaScript are Jasmine and Sinon.js. And I also use some helpers of my own. None of these two frameworks provide actual mock objects. Sinon has a "mock" function that let us configure expectations before exercising the system under test. It behaves like a mock if we are working with functions only. Nonetheless if we are working with objects (OOP), then what Sinon provides is not a mock object because a call to any other method in the object other than the expected, will not fail the test. And it should as unexpected calls should make the test fail.

The solution to have real mock objects with Sinon is just a little helper:

  1.  
  2. //------ HELPER FUNCTIONS
  3. function unexpectedCall(functName)
  4. {
  5. return function(){
  6. throw new Error('Function ' + functName + ' was not expected but invoked');
  7. };
  8. }
  9. function inocuousCall(){
  10. return function(){};
  11. }
  12. function replaceAll(obj){
  13. return {
  14. methodsWith: function(fn){
  15. for (var propName in obj)
  16. if (typeof(obj[propName]) == 'function')
  17. obj[propName] = fn(propName);
  18. }
  19. }
  20. }
  21. function stubThe(obj){
  22. replaceAll(obj).methodsWith(inocuousCall);
  23. }
  24. function mockThe(obj){
  25. replaceAll(obj).methodsWith(unexpectedCall);
  26. }
  27.  
  28. //------ THE TEST
  29.  
  30. it("stores the user when adding a new one", function(){
  31. // the DOC (depended-on component)
  32. var repo = userRepository();
  33. // the SUT (system under test) and dependency injection
  34. var service = userService(repo);
  35. // patching the DOC, making it a mock
  36. mockThe(repo);
  37. var mock = sinon.mock(repo);
  38. // configuring expectation:
  39. mock.expects("store").once();
  40.  
  41. // exercising the SUT
  42. service.add(new User({email: 'test@test.com'}));
  43.  
  44. // verifying configured expectations
  45. mock.verify();
  46. });
  47.  

In languages like Java or C#, test doubles frameworks create a replacement for all the methods in the target class/interface. In JavaScript however, frameworks replace single functions. For this reason it's possible to have the same object acting as the SUT and the double in a single test. But the fact it's possible doesn't mean it's right. Whenever you find yourself in a test using a double for some method and then invoking another method in the same object, think carefully whether the design is appropriate. That smell is usually pointing out that you should extract a new class and create a dependency between the old and the new, so that one acts as the double and the other as the SUT.

Case study: Audience Response

October 30th, 2013

Wow, AgileTestingDays 2013 it's being awesome! I gave my talk today, a practical "live coding" session. Last week I created a real-time application to communicate with the audience so that when I am speaking they can tell me if they are understanding or if they want me to repeat ...
So we started off using this app on my session. Interestingly enough the session was about building the tool again. From Cucumber specifications, all the way down to the GUI and the hub (server).

You can find the actual code of the application here and more importantly, the process I followed to write it, because I checked-in the code on every green test so by looking at the diffs, you'll figure out how code evolved.
Unfortunately the wifi didn't work well so I couldn't really take advantage of the app. Next time I'll bring my own wireless router to create our private LAN.

In order to prepare the session, I rewrote part of the app again myself. In here you can find this second iteration, again with a test committed at a time. By looking at the commits you can follow part of what I did during my session. You can take the code and practice yourself from this particular commit, comparing your moves with mine ones to see what we can learn.

Find the business specifications of the app here and the step definitions (glue) in here.

Now, the session didn't go bad, but it didn't go as well as I'd like. I did quite bad with the timing.I would have needed 90 minutes rather than 45 to illustrate the process properly. When I was preparing the talk, I wrote the code on my own and it didn't take much time, but presenting it's a different story, I've learned that I need about twice as much time.

2013-10-31 01.24.06But I am satisfied because several people understood the process and got value from it. Next time I run this session, it will go much better. And you know what? I've been approved by The Code Cop! Look at this picture.

 

I'll be happy if you were attending the talk and can give me some feedback in the form of a comment in this blog. As a reward, one person out of the people commenting will be randomly selected and I will run a free 90 minutes session for her/his company (remotely, videoconferencing), doing this same exercise properly with Q&A session.

James Lyndsay and Bart Knaack from The Test Lab have used an instance of the app for testing purposes and people have found several defects. I am happy for that because I didn't do any exploratory testing or even took care of network failures or latency problems. Thanks for that guys!

This exercise will be part of my upcoming book on Agile JavaScript for Rich Internet Applications. I expect to have the book done in 2014.

If you want to have a look at the sample deployed app on Heroku, use these urls:
Load a page in the browser with this url (as a speaker).
Then load the page as the audience in other window.
Then just interact.

Thank you very much for all your support, I really appreciated you invested your time on my talk. If are there questions please let me know of find me tomorrow in the conference to catch up or hang out :-)

Online training course/class: Test doubles

October 21st, 2013

No long ago in the Spanish TDD mailing list, some friends said they were struggling with test doubles. A typical question is how to use them to design collaboration a la test-first. Test doubles are something people find hard to understand in my TDD training courses.
This is why I've decided to run an online training class on Test Doubles. Mostly those used in unit tests: mocks, stubs and spies.

I'll run two editions of the training, one English spoken and the other Spanish spoken. People can decide which one they want to participate in after they subscribe the online form.

We'll use mostly Java to practice as it's a language most people know. But the same concepts are valid for other languages. We'll also view examples on JavaScript and C#. Like all my training courses, this will be hands-on with very little talk from my side.

The number of participants per course is limited to 25 so that I will have time to review all the exercises during the course and make suggestions. I enjoy having time to share it with participants one by one. Don't wait too much, 25 spots will be gone soon :-)

As this is the first edition it comes with a special price, only 49 bucks!

If you are familiar with the idea of writing a test first, you can join this class. We'll use Webex for videoconferencing as well as sharing resources together with other tools.

Find the subscription form here.

Fluent API for test doubles

October 11th, 2013

There are several good frameworks out there to create test doubles with JavaScript. Jasmine  and Sinon provide test spies and stubs. JsMockito looks good too. However, creating your own API for test stubs is very easy. I've created mine as an exercise. It's a very naive implementation but it works. See the code:

  1.  
  2. describe("a fluent API to create a test stub", function(){
  3. it("stubs out a method", function(){
  4. // the fluent API:
  5. function when(stub){
  6. return {
  7. thenReturn:function(arg1){
  8. stub.configureOutput(arg1);
  9. }
  10. };
  11. }
  12. function stub(actual){
  13. var expectedArgs,
  14. configuredOutput,
  15. isConfigured = false;
  16. actual.configureOutput = function(output){
  17. configuredOutput = output;
  18. isConfigured = true;
  19. }
  20. actual.someMethod = function(){
  21. if (isConfigured){
  22. if (expectedArgs[0] == arguments[0])
  23. return configuredOutput;
  24. return;
  25. }
  26. else
  27. expectedArgs = arguments;
  28. return actual;
  29. };
  30. return actual;
  31. }
  32.  
  33. // the test confirming it works:
  34. var actualObject = {someMethod: function(a){return 1+a;}};
  35. var theStub = stub(actualObject);
  36.  
  37. when(theStub.someMethod(2)).thenReturn(5);
  38. expect(theStub.someMethod(2)).toBe(5);
  39. });
  40. });
  41.  

The implementation is not generalized to support any method or any number of parameters. I just wanted to play with the idea that I can invoke the stubbed method in the "when" statement and it doesn't execute anything apparently. It only executes the stubbed behavior once it's been configured.

It's very simple but it didn't come up to my mind when I implemented pyDoubles (now Doublex), which might have made the API even better.

A week in the UK

September 24th, 2013

Talking at SkillsMatter

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

BDD for RIAs with JavaScript - Skills Matter from Carlos Ble

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

 

 

 

 

RIAs: the domain is not in the server side

August 11th, 2013

Rich internet applications bring a powerful user experience. But in order to achieve that, they must be written totally different from traditional webs. The paradigm is totally different and so the architecture.  There is no "server side" as such. In some cases it's just a deployment site, where you have to browse in order to load the app. In some other cases you also need a centralized site to:

  • Initializing the application (deployment).
  • Storing data to be shared among instances/users (persistence).  
  • Connecting instances/users to each other (communication). 
Rather than calling it "server side", let's call it the hub. Its architecture must contemplate mainly:
  • Security
  • Concurrency
  • Scalability 
But everything else, lives in the application. The business domain, lives in the desktop application (which is inside the browser). There might be some security constraints related to the business that need to be tackled by the hub. In those cases, that particular bit of the business lives in the hub.


In order to be productive, the hub must understand JSON very well (assuming the data is sent/loaded via JSON) and serialize/deserialize it to objects automatically, without the need for hand-written mappings. This is one of the reasons why using Node.js in the backend makes sense, because you don't have to rewrite your objects in two different languages. Anyway, I am using C# and Python as the backend languages in two of my projects and the idea is the same.
If there are no particular security constraints, hub must accept data sent from the application and store it without objection.  The best way to avoid objections is using schemaless databases like Mongo.
Fortunately C# with ASP.Net is fantastic for JSON serialization/deserialization. For Python we've had to write code ourselves to get some automated conversion working.


As the hub is not the core, its functional requirements emerge from the incremental design. Such a design starts in the application side which eventually might need to send or retrieve some data to the hub. So my Cucumber scenarios, talk to JavaScript in the application side, specially if they are end to end.


Examples:
- Adding a "comment" to a "merchant" (where merchant is an entity, and comment is a value object): is done by the application. The hub just stores the entity as sent by the app. It  might have a security check to make sure the logged user can make changes in the merchant.  If there is any additional specific security constraint saying that comments can be made only by certain users, then we need to check that in the hub too, for the sake of data consistency. But that validation would go into the security rule's code. The hub's "merchant service/repository" won't know anything about comments.
- When listing merchants, show only those from  a particular country: is done in the hub. If the security constraint says that logged users from the UK can only work with merchants from the UK, we can't send all the merchants to the app for it to filter them out. Instead, the hub makes sure that only the information that can be seen in the app is sent.


So for rich internet applications, the hub is there just to support the architecture. Don't start the implementation of a feature in the hub, because you don't know if you are going to need it.  Keep your hub layer as thin as possible,  adding complexity only when proven necessary.
This will be probably a  chapter in my upcoming book where I will explain it in more detail.


The rationale behind:
The reason why desktop applications provide much better user experience than server-side web apps, is because they react immediately to user input. They interact in real time. When the user asks the application to save some data, the app should immediately tell the user data is saved, even if it hasn't got confirmation from the hub. If the hub doesn't respond or informs about a problem storing the data, then the application should inform the user, handling that somehow. But it should not make the user wait. So the application must have all the business knowledge to implement this solution.
Imagine a desktop application, a text editor for example. Now imagine it runs in the browser. All you need the hub for, is to load the application. If you want to access your text documents from different machines, then you need a hub to store and serve that information. Why do you need any business logic in the hub? What for?
In a later version, we decide to implement a new feature: collaboration with other users. There might be security restrictions. You might not want to have all the users opening your documents, but just some. Then you go and add a filter in the hub.
So it's not that you design some kind of service in the hub first and then call it from the application. It's the other way around, like in TDD, I might write a call to a centralized service that doesn't exist yet, once I know I need it in my application and once I know how I want it to behave. Then I add that behavior in the hub if necessary.
Eventually if the interaction among users is very complex, the hub will become complex and will contain important business logic, but its design will emerge according to the needs of the application and not the other way around.

The best coding dojo ever

May 18th, 2013

 


I've got goosebumps on my arms most of the day. And it doesn't happen very often. This is the most emotional coding dojo I've ever facilitated. It's been in Gran Canaria, at the Universidad de Las Palmas de Gran Canaria (EII ULPGC).

The last day in college for some students, where many of them were thinking of their uncertain near future. Asking for recommendations and expressing many doubts.

More than 50 people coding together for more than 8 hours, in an incredible atmosphere.

 

 

How did we get here?

There is only one book on TDD in Spanish so far. Published by my friends and me back in 2010, under the creative commons license. Creative commons is like a virus for this. One year ago a real master, Jose Juan Hernandez (@jjhernandez) decided the book was nice to teach his students how to write clean code. We didn't know each other. In fact I didn't know the book was being used at the University. Jose Juan has been coding since 1985 and I do believe he is a software craftsman, now that I've seen him coding and teaching.
A couple of months ago he contacted me  see if I could give a talk to his students, about TDD in the real world™ and the encounter was excellent. The coding dojo proposal came along right after that.

Why has it been so good?

Guillermo and I

Several factors in here. Jose Juan has been teaching TDD, Refactoring, Patterns and Clean Code to his students the whole year. No only the practices but the values. This is the reason we believe he is a master, because his students have embraced and internalized his values and principles.

  1. So about 30% of the students were familiar with the techniques, and we asked them to pair up with those not exposed to automated tests and example driven design before. And they explained everything to others with passion. 
  2. In a regular coding dojo the facilitator does not necessarily teach. Her goal is facilitating. In this case though, we've been teaching people, so it's been half of a training session. With direct feedback on their work, based on our experience.
  3. We were 3 guys facilitating: Guillermo Pascual (@pasku1), Jose Juan and me. And the sinergy it's been huge.
  4. Everyone was absolutely willing to learn and share. Passionate people, warm and friendly.
  5. It's been a total win-win event. We (facilitators) have felt very useful and appreciated, it's been fulfilling. Some people have discovered a new way of understanding their careers, and what "caring about code" means.
  6. The retrospectives following every iteration were very participative, people were able to discuss among them.
 

Jose Juan

What's next?

  • This is a milestone in the Canary Islands software development community, I can feel it. Something is changing...
  • Let's keep on practising together. The AgileCanarias community is growing and it's a good starting point  o meet new people and learn new stuff. The Tenerife group is kind of mature and stable now, let's do the same in Gran Canaria. And let's join the two groups for dojos and local conferences.
  • We have the Agile Open Space this year in Tenerife. Join us, it's a great opportunity to discover more.
  • Now you know there are different ways of writing software. Keep on learning, it's a never ending path.
  • When is the next coding dojo, who will organize and facilitate it? :-)

I want to facilitate a dojo, what should I know?

  • Manage people's expectations. In general a coding dojo is not a training session. Be honest with participants and help beginners as much as you can. Otherwise they'll be scared, run away and take a wrong idea about what it is.
  • A dojo is a space for innovation, try different things all the time, you don't have to follow the manual on the go. Just use your imagination and empathy.
  • Ask someone experienced to facilitate it before doing it yourself, if possible.
  • There is an interesting new book on this by Emily Bachehttps://leanpub.com/codingdojohandbook (haven't read it yet), foreword by Uncle Bob Martin.
  • Check out this video by Emily Bache: http://www.youtube.com/watch?v=yao5XLJqogQ

Acknowledgments

  • Jose Juan and Guillermo Pascual.
  • All the participants, of course. Without them, there is nothing to do.
  • Jorge Castellano for his pictures and video. Pictures will be uploaded soon here. Jorge already uploaded some pictures to twitter. Just search for the hashtag #dojoULPGC
  • Fran Santanta for his support and organization. Fran brought journalists from local newspapers and TV, apart from the food and everything else.
  • Mario Hernandez Tejera for his company, hospitality and sharing his interesting/wise thoughts.
  • All the colleagues who work with Jose Juan for his support and energy.
  • JM Beas, Xavi Gost and other folks from Agile Spain, as they introduced me to coding dojos.

This is the related thread in the AgileCanarias mailing list.

fotos de Jorge Castellano
Guillermo Pascual y Carlos Ble