Ivan Sanchez

In our last coding dojo, instead of a randori we had a kata prepared by Danilo Sato. He solved the Minesweeper problem in ruby in about one hour using proper TDD and stopping for questions/suggestions from the audience. Here are some of the tricks people could learn from that session:

• When working with ruby on a Mac, the RSpec bundle for TextMate is great. It has really helpful shortcuts and can easily run your specs and see your reports inside the editor.
• Rspec can be used as a TO-DO list during the development of a class. This can be done by creating pending tests as reminders of test cases to be covered. These are tests appear “yellow” state, waiting for a proper implementation.
• Autospec is also a great tool for TDD. Seeing a test becoming green is fun, but doing so without running it manually is way better. Specially using Growl.
• When doing a presentation using the command line, it’s easy to be tricked by font colors. They may look great on screen, but a projector may not like them.
• During TDD, it’s really important to know how to fake it. But knowing when to refactor the fake code is even more.
• Being able to create methods like “[]” in ruby can be really helpful.
• TextMate allows you to run any text file or even just a few lines of it as a ruby script . This can a good alternative to play with the language instead of using irb.
• A piece of code can sometimes be used as a good visualization tool for a problem. Here’s an example:

    it "should find neighbours around cell" do
      @field.neighbours_at(1, 1).should have(8).neighbours
      @field.neighbours_at(1, 1).should include([0, 0], [0, 1], [0, 2],
                                                [1, 0],         [1, 2],
                                                [2, 0], [2, 1], [2, 2])
    end

• It’s easy to create bugs by using “…” instead of “..” in ruby ranges.
• Multiple assignments FTW.
• jUnit should have something like nested describes in RSpec. It’s a great way to group related tests for a single class.
• Nice RSpec reports can be generated even outside TextMate by using “rspec –format html”
• In BDD sometimes makes more sense having multiple assertions inside the same test. The condition in this case is that they should all help to verify a single behavior of the class being tested.
• Being able to refactor a field into a method without having to care about the references to that field is really cool.
• Assertions for boolean values in rspec are very elegant.
• The pending feature in rspec can really good for big refactorings. It helps to be sure a test or more should be failing during the process.
• Creating your own matchers can make a rspec test more readable. And people should use this feature from jUnit more too.
• It’s easy to get confused by the use of &block and yeld in ruby. In any case, it’s better to learn both and stick to only one of them whenever possible.
• Some ruby conventions are really smart. Append “?” to describe a boolean method, or “!” to do the same for a method which changes the internal state of the class.

If you want to check the source code it’s available on github. To know more about the dojo and or attend our next session check our mailing list for the discussions going on.

Work Coding Dojo, Kata, Programming, Ruby, TDD

Yesterday we had our first dojo in 2009 and once more people asked me when are the next sessions. So here they are:

• Wednesday, January 28th
• Thursday, February 12th
• Wednesday, February 25th
• Monday, March 9th
• Wednesday, March 25th

The dates may change (they already did), so that’s one more reason to join our group or subscribe to this blog to be informed if that happens.

Work Coding Dojo

Last Monday we had our first open coding dojo at Skillsmatter. Although we didn’t manage to decide all the details beforehand on the mailing list, I believe it worked pretty well for a first session.

With 11 people attending, this dojo was challenging in different ways. The problem we tried to solve was the BankOCR, which only two or three people had tried to solve beforehand. The language was Ruby, which most people didn’t have tried before. And the environment was MacBook+TextMate, which was also something new for almost everyone there.

The randori started right after we had some time to read the problem description and had a minimal discussion on how to approach it. The pairs were rotating every 5 minutes and we manage to code for almost 1 and a half hour before running a quick retrospective at the end.

Most of the attendees had been in dojos before, which made things run smoothly most of the time. On the other hand some people felt a bit lost during the session, and that was one of the first things brought up during the retrospective. To avoid that in the the next sessions I’ll be in charge of doing a better introduction to the newcomers about the dojo and its rules.

At some points people also had problems with the keyboard from the Mac, which is something that could be easily avoided and hopefully won’t be a problem next time.

From my point of view, one of the highest points during the retrospective was when someone brought to attention the fact that people tend to radically change the approach of the implementation once is their time to actually code. Ryan’s insight was that from many perspectives the dojo is very similar to improvisational comedy: the current state of the code has be used as a source of inspiration and giving it continuation will definitely keep the audience involved. In simple terms: go with the flow!

In general I was very pleased by the reactions at the end of the session and specially the discussions we had in the pub afterwards.

The generated source from this session is available on the dojo’s repository on github. There is not a lot there, but it may be interesting for people to continue that implementation and keep discussing it on the mailing list.

Although I didn’t manage to do it this time, the idea is to discuss the problem and the session style in the list and then publish on the Skillsmatter website before the event, so people who are not in the list yet can have more details about what we’re planning to do. If you decide to join now make sure you check the previous topics to know what’s going on.

If you are interested to watch the whole session, here’s the video:

The next session will be on 14 January and the registration is already open. See you guys next time!

Work Coding Dojo, Programming

Thanks to Gojko and the guys from Skillsmatter I’ll be running a regular coding dojo in London. The challenges, languages, session formats and any other related topic will be discussed in the new coding-dojo-london group, so if you’re interested in attending any session or learning more about how the dojo works, it’s a good idea to subscribe.

My idea with this group is also help people interested in running other dojos in the city. So far I know Danilo from ThoughtWorks and the guys from YouDevise who are doing that, and I hope to see more next year.

The first session will be on 1st of December and the idea is to have one session every 2 weeks starting in January. All the sessions are free but be aware that some sessions may have limited number of people.

Work Coding Dojo, Programming

Then is time to visit TDD Problems:

The aim of this site is to contain a growing collection of software problems well-suited for the TDD-beginner to learn Test-Driven Development through problem solving.

Today the site contains 20 different “real-life” problems, which is probably enough to keep anyone busy for a long time. And since it was announced in the testdrivendevelopment list only a few days ago, it’s very likely the list will keep growing.

Enjoy!

Work Coding Dojo, Programming, TDD

In the last months I’ve been in touch with a lot of people trying to start their own coding dojos. Here’s some tips for those who already started or are considering it:

Setting up

You don’t need much more than a place with one computer connected to a projector and enough sits for people attending. A timer to keep track of the pair rotation and a white board or flip chart to discuss the problem are also very useful.

If providing foods and drinks is not in the plan, at least don’t forget to have enough water for people in the room. Breaks are acceptable, but the idea is to get people focused most of the time.

Introducing the dojo to new people

In my experience, the dojo is not suitable for everyone. Not that you have to be special to be part of it. Not at all.

The problem is that people are used to learn in different ways. Some don’t like to slow down and see things they already know being done step by step. Those will become inpatient and probably get in the way of those seeing things for the first time. In other cases, people are so used to learn by themselves that is hard to share this process with other people. There’s also people who will simply find the problem too easy/hard to solve and therefore useless for them.

My suggestion in this case is start with people who already know how the dojo works. Even if it takes doing a small presentation to explain it. Show that the point is not the problem itself. The point is deliberate practice. If people accept that before the meeting starts it should flow way easier.

The right style and size

The number of people is also important. Is very hard to run a randori with more then 10 people. Specially if they are new to the dojo. People approach a problem in different ways and it may become hard to listen to everyone’s opinion in this case.

In the other hand a kata can be done with more people at the same time. This approach requires some effort to prepare and practice the solution for a challenge, but may help to introduce the idea of the dojo before getting everyone involved in the coding.

Choosing the coding challenge

There are load of sources for problems out there. The guys from Dojo São Paulo have a list in their wiki, but in principle any well known problem is okay. I really like something like Mine Sweeper to get people started, and then let them help to choose new problems based on that first experience.

Remember that starting with a completely new language is a good idea only if people do their homework and try to learn the basics before the meeting. Otherwise the meeting will be only for reading documentation instead of coding.

Don’t forget the retrospective!

The dojo is a place for continuous improvement, and the retrospectives are essential to achieve that. It’s normal to have some problems during the meetings, but there’s no excuse to discuss them and do things better next time. For the good things is also interesting to discuss to acknowledge what’s working and try to keep them.

Try to get everyone’s feedback. If people are not motivated to talk, well, that’s the first problem to be solved.

Now that you’ve started…

… It’s time to merge with the software community around you. It’s easy to find more people to attend to the meetings. Simply invite and they will come. I try to attend all the dojos I’m invited because I know how much I learn every time I see other people programming in front of me. For the same reason I’d like to always have new people in my dojos.

I hope to be inviting people through here my dojos soon. At the meantime, I’d be happy to help anyone interested in starting a dojo. In this case, just let me know.

Work Coding Dojo, Programming

1. Is the easiest and cheapest way to invest in training

To run a coding dojo people don’t need much more than a computer and a projector. Paying for the pizza and some beers for the end of the meetings is not expensive either, and is surely welcome. But if the company is really cool, some dojos can take place during work time to get more developers involved. Note that none of those items take lots of money nor is too complicated. The only things needed are some engaged developers and good sense of the company to invest in their professionals.

2. Stimulates social and self-organization skills

Many developers have some hard time when talking in public, exposing their ideas or collaborate with other people. Others have problems to self-organize, work in a team or even lead. When does a company invest on those kind of skills of a developer? Rarely. The dojo is a great start for those people, and even who doesn’t have any of these difficulties will have a chance to exercise their skills and explore points which may need some improvement.

3. Is good publicity for the company

If the company took the first step and the developers are already comfortable running a dojo, why not open the doors for the public? The company name will become associated with the agile principles behind the the coding dojo and developers won’t have to leave the company to network. Better, if everything goes well the company won’t have to publish ads to get new developers since the potential candidates will be part of the company’s routine.

4. Helps developers to be active in the community

Discussing the techniques applied in the dojos can be a good incentive for some developers to participate more in the software development community. It can also be a first step help some open source projects, publish articles or participate in conferences.

5. Breaks the routine

Code something different from the daily projects, using other languages, tools and techniques, with other people and in a more relaxed environment may be very stimulating.

So, do you need more reasons?

Work Coding Dojo