Danilo Sato

I’ve finally settled down in London and took some time to start the conference reports from the last couple of weeks. The first one I attended in São Paulo was Rails Summit Latin America. It was very well attended (500+ participants) and organized. I should give a special thanks to Fabio Akita and Locaweb for putting such a great conference together!

The conference started a bit earlier to me, when we went out with the other “foreigner speakers” (that’s how non-Brazilians are called in the airport…) to eat Feijoada and drink Caipirinha! Lots of fun! It was really cool to hang out with George, Jay, Obie, Desi, Dr. Nic, Chris, David Chelimsky, Luis Lavena, Akita, and Tim.

The first day of the conference started with DHH’s remote Q&A session, which was OK but nothing new or exciting. The following talk was really good: Chad Fowler gave an inspiring keynote about “Being Remarkable” which was a good summary of his book, plus his skills as a presenter and a good deck of slides (and videos). Very good!

Me and George skiped lunch to rehearse and give some final touches on our presentation about REST. I thought the presentation flowed very well, and it ended up being the only technical session on the main stage during the first day, even though we didn’t show any code: our goal was to talk about REST as an architectural style, basically summing up the great work of Fielding and the good practices that people on the REST community have been talking about. We also wanted to talk about other alternatives to building services on the internet. The slides are available here (we added some notes to make it easier to follow our train of thought).

Dr. Nic gave a funny and entertaining presentation about contributing to Open Source projects and the “Path to Awesomeness”. The first day finished with Chris’ keynote, which was very similar to the one he presented at Ruby Hoedown. If you’re interested, watch it on Confreaks. After his talk, Fabio moderated the Birds of a Feather session (which was more like Lightning Talks), and I was very surprised to see a lot of people stepping up to talk in their 5 minutes slot. The topics ranged from politics to organizing a study group, with special kudos to the Phusion guys who showed a Brainf*ck interpreter in Ruby. Of course, the day couldn’t finish without a rodízio of Brazilian steak at the churrascaria.

On the second day, I experienced the great joy of São Paulo traffic and didn’t made it to watch the Phusion guys’ presentation. I’ve heard from a lot of people it was great and that they gave a great talk about scalability (as well as a lesson on how to use Keynote properly). I arrived during Charles Nutter and Thomas Enebo’s talk about JRuby. It was held remotely and I know Akita had a lot of work to get the environment working. In the end, we still experienced some latency issues but the demos worked out quite OK. After that, Jay gave an interesting talk about the “Immaturity of Testing”, which was rooted in a last-minute presentation we put together for the UK ThoughtWorks Away Day back in June with George. It was great to see how much the discussions from our internal session enhanced the overall message and how Jay managed to put it all together in a nice format. I think a lot of people learned from the pros and cons that he discussed.

After lunch, the ‘testing’ theme continued with David Chelimsky presenting a double talk on RSpec and Cucumber, the gem that’s being developed by Aslak right now and will eventually replace RSpec’s current Story Runner. I wasn’t present during the second half, because I was preparing to present next about my lessons learned about testing. The slides (in Portuguese) are also available and I received some good feedback about it from the brazilians who prefered to watch me instead of David :-)

I stayed around the Brazilian track to watch my friend Fabio Kung present on JRuby and give a real-life demo of his experiments with JMagLev. After that, we all went to watch the closing keynote, by Obie Fernandez. It was a great talk about the Hashrocket way, which was heavily based on their way of applying Agile. In the end, he managed to get standing ovation from some folks in the audience. The last day finished with a lot of champagne and free beer, closing two days of networking, fun, Ruby, and Rails.

My overall impressions from the conference were very positive. It was great to see how much the Brazilian Rails community has grown over the past year. When Fabio and I organized the first RejectConf, back in 2007, we managed to get 100 people to show up in a Saturday and that triggered a lot of other small local conferences throughout Brazil. Seing everyone together for the first time, was a great chance to do the usual networking, and to share our experiences working with Ruby and Rails. I suspect next year’s conference will be even better. See you there!

I’m back from a 2 week “conference season” in Brazil and Argentina, but before I share my experiences on those conferences, I want to talk about my first session at the São Paulo Coding Dojo since I left in February. It was very unusual and pleasant for different reasons: first of all, George had arrived in Brazil for Rails Summit Latin America and I took him to the session; second, it was held at one of the participant’s house, instead of the usual venue at the University of São Paulo (which made it possible to add a taste of fresh baked pizzas to the retrospective); third, we decided to try out a different session format called, in lack of a better name, ÃœberDojo which I will try to describe in this post. Hugo has already explained how they came up with the new format in his blog.

In an ÃœberDojo, the setup is different than a regular session: there are more than one laptop and no projector. The number of laptops may vary depending on the number of participants, but we were 14 and decided to have 4 pairs, so 4 laptops were available. We laid out the laptops in 2 tables and chose 2 different problems to be solved in 2 different languages. We would go with Python and Ruby, but George argued in favour of having different programming paradigms to enrich the discussions, so we ended up coding in Ruby and Haskell. The problems we chose were already familiar to most of the participants since the goal of the session was to try out the new format rather than solving a difficult problem or learning a new language: Minesweeper and Bank OCR were the chosen problems.

The dynamics of the session are similar to a Randori session, but with multiple pairs coding at the same time. We used a fixed timebox of 7 minutes to switch the pairs (when the round is over, the driver leaves the pair, the observer becomes pilot, and a new observer joins from the audience). The big difference in this format is that it’s impossible for everyone to follow the same train of thought, and there’s always more people than seats available so there’s a lot more chatting happening. When a new member joins the pair, it’s very likely that he will have almost no previous experience with the code being developed (similar to a real-life environment?), so everyone can exercise their ability to read and write readable code. In the original idea, people who were not coding were not supposed to follow what the other pairs were doing, but we ended up helping other pairs with less knowledge on the languages and/or environment. I have to admit I sometimes tried to stick around one of the pair stations because the approach to the solution and the discussions were getting interesting :-)

At the end we held our usual retrospective with food (a lot of pizza) and everyone seemed to have enjoyed the session. I particularly felt the energy and the innovation happening and was very excited with the results. We coded for more than 1:30 hours and it was very hard for me to leave the code unfinished. Although it was a lot of fun, I think for this kind of session to be successful, the participants need to be familiar with a Dojo session and its dynamics (TDD and Pair Programming in particular). Hugo was also a very good moderator, using a pairing matrix to keep track of who was pairing with who, to keep at least one experienced member on each pair, and to put different people in different pairs at each round. The code from that session is available at GitHub.

I see some benefits to trying out this type of session. Solving the same problems in different languages (and paradigms) made it possible to have a rich discussion at the end. For example: when solving the Bank OCR problem in Haskell, pattern matching made it easy to make progress on the first steps, while the Ruby version was getting stuck with a lot of nested if/else statements. Another benefit of this type of session is that you can cope with programmers in different levels of experience. In a traditional Dojo session, you always go as fast as your least experienced participant. In this session, you have different streams of development happening at the same time, so a faster pair can make more progress on their turn. Finally, I think this environment is much more similar to what you might encounter in “real-life”: you develop code for others to read and you have to understand what others were doing while you were absent.

I hope you try out this format in your Dojo and share your experiences. What other types of session are you trying out in your local Dojos? Would you have a better name for this new session format? Leave your comments!