Danilo Sato

Next 15th and 16th of October I will be in São Paulo speaking at Rails Summit Latin America. I will be presenting a session about Developer Testing, showing some interesting tools in the Ruby world such as: RSpec, Mocha, Synthesis, RCov, and Autotest. I will also be co-presenting a session with George about Application Design for REST (or something along those lines).

In the meantime, for the Portuguese speaking audience, I have uploaded the slides and Carlos Eduardo made the recorded video available of my Merb webinar that I presented last month at ”Café com Tom”. I will be back to present another webinar about BDD and RSpec in September.

Hope to see you all there!

The main reason I went to the conference was to present my experience report on Wednesday about running a Coding Dojo in São Paulo since last year with my friends: Hugo and Mariana. I just made the slides available for download, as well as the published paper. Feel free to comment and send questions and comments about our unanswered questions.

The overall feedback we got from the 30 minutes presentation was very good and we decided to do a Live Dojo at the Open Jam in the next available slot. Besides me, Hugo, and Mariana, Emmanuel and Arnaud from the Paris Dojo showed up, Ivan Sanchez from the Floripa Dojo as well, and other people joined us during the session.

We did a Randori session solving the Blocks Problem in Ruby/RSpec, switching pairs every 7 minutes. Although we didn’t finish the problem, it generated some interesting discussions about exposing the internal state vs. a representation of the state to the tests, and how valuable it is to introduce a data structure that you don’t need now but will soon need.

The problem generated some interest and, on the following day, Arnaud had scheduled a slot on the Opem Jam, and we decided to tackle the problem again, but this time in Haskell. Dan and Liz were also there and it was really cool to see the same problem from a different perspective. We discussed how some features of a functional language forces you to think in a different way (I still don’t quite understand Monads, by the way) :-)

Another interesting learning point was: In our paper, we discussed a whole topic about issues with people pairing in different environments (operating system, keyboard layout, shortcut keys, IDEs, …) at every meeting. At the Open Jam, Dan proposed that we used a local Mercurial repository to share the progress on development (pushing at each TDD step for the next pair to continue working on the problem). This allowed him to work on his Mac with a Dvorak layout, while we were using Emacs on a Linux laptop. The other benefit of this approach is that it allows people to experience how Continuous Integration works in practice, committing as often as possible, whenever it makes sense to do so. Good stuff!

I was kindly invited by my friend Carlos Eduardo (e-Genial) to give 2 webinars to the brazilian Ruby/Rails community in the next months (in Portuguese). So, add to your calendar:

• 19/Jul/2008: “Merb: web development with Ruby without Rails“
• 13/Sep/2008: “BDD with RSpec“

Both webinars will be held at 3:00PM (brazilian time) via Treina Tom, a great e-learning/e-conference tool developed by Carlos. More details can be found at the event website. Hope to see you there!

A recent post on InfoQ made me think about how I use mocks during development. I used to be a classicist tester and thought mocks were only useful to fake external services (usually slow or hard to setup). After learning more about interaction-based testing and BDD, I now see some good advantages of using mocks during development:

Outside-In Development

Behaviour-Driven Development is more than a variation of TDD. I like Dan North’s explanation of BDD as an “outside-in” approach to development. We start at the Story level, defining the acceptance criteria as scenarios which create an agreement between the team and the customer on the meaning of DONE. From the outside view, we start digging into the domain model, designing the objects and services needed to implement the story. I find mocks really useful in such scenario, because I can define the interface of the objects that still doesn’t exist, while focusing on the current layer of functionality. As a side effect, my tests become more isolated and when they fail I usually have a good indication of where the problem is located, requiring less debugging.

In this sense, I think the really important scenario for using mocks from Colin Mackay’s article is the last one: “when the real object does not yet exist”. I still mock someone else’s objects in the boundaries of the system, to assert that my code interacts properly with external libraries. But I see much more value in mocking my own objects, designing interactions and isolating behaviour. Which leads to my next point…

CRC with tests

CRC cards was one of the techniques that thought me what good Object-Oriented design looks like. It focus on designing behaviour-rich objects, defining its Responsibilities and Collaborators. In general, while state-based testing is great for defining Responsibilities, mocks give me the ability to precisely describe the Collaborators in my tests. Since I’m all in for using tests as executable documentation, mocks turned out to be a great technique to express my intent. Leading to my last point…

Mocking methods vs. mocking objects

My last point is not exactly an advantage of using mocks, but an example of how a framework can influence how you approach development. Coming from the Java world, I was used to encapsulate behaviour behind well defined interfaces. Now that I spend most of my time developing in Ruby, I not only have the ability of creating a mock/stub object, but also of mocking just one or two methods in a real object. These are usually called Partial Mocks.

Partial mocks allow me to express intent more precisely: instead of having to create a mock from an interface/class and record expectations in a proxy, I can specify the interactions in the real collaborators. It also makes the separation between state-based and interaction-based tests more loose, because I can selectively choose which methods will be mocked and which will be real. Finally, I can use tools such as Synthesis to verify that the interactions I’m mocking in one test are actually being verified in the collaborator’s test.

I know some people don’t feel comfortable using mocks and some even find it complex, but I think there’s great value on using it in the appropriate context. Instead of complaining about different framework’s idiosyncrasies and complexities, I think people should focus on its benefits as a design technique.

Esse fim de semana tive a oportunidade de conhecer o Rio de Janeiro e participar do Rio on Rails, organizado pelo pessoal da ImproveIt. O sábado foi repleto de Ruby e Rails e no domingo tive um tempinho para passear e conhecer um pouco da cidade maravilhosa.

Os organizadores estão de parabéns. As palestras foram muito bem escolhidas e acho que deram um bom gostinho de como é divertido programar em Ruby e Rails para quem nunca tinha experimentado. Como sempre, eventos são uma excelente oportunidade de conhecer gente nova e trocar experiências e o Rio on Rails não deixou a desejar. Conheci o Ronaldo Ferraz, que falou um pouco sobre DSLs, o Demetrius Nunes, um dos pioneiros na adoção de Rails no Brasil, o Eduardo do site o Curioso, todo o pessoal da Improveit e do projeto Lucidus e mais um monte de gente que não vou lembrar do nome, mas que estavam presentes para fazer mais um grande evento da comunidade Rails no Brasil.

Minha palestra sobre BDD e RSpec foi uma evolução da palestra no RejectConf’SP. Com mais tempo para explicar os conceitos e fazer uma demonstração mais calma, acho que consegui passar uma idéia melhor da experiência de programar com BDD em Ruby e Rails. Os slides já estão disponíveis aqui, assim como o esqueleto da aplicação demo que desenvolvi, com o passo-a-passo da demonstração. Quem quiser também consegue pegar a versão final do código apresentado.

Uma coisa legal que eu consegui terminar de preparar para a apresentação foram algumas das novidades do RSpec 1.1.0, como o Story Runner (integração com o RBehave, que eu apresentei no screencast do Dojo@SP), os plain text story tests e o protótipo do editor de story tests no browser.

Para rodar os exemplos, você precisará do Rails 1.2.6 (não fiz update pro 2.0 na palestra pois o patch da integração do RSpec com o Rails novo saiu na sexta a noite e não quis arriscar a demonstração ao vivo), do RSpec e do Rcov, caso queira verificar a cobertura (gem install rcov). Quem gostou da integração do Autotest com o Growl que eu usei na demonstração, pode pegar meus arquivos de configuração no Google Groups do Dojo@SP (não esqueça de instalar o Autotest com ‘gem install ZenTest’).

Continuando com a maratona, participei de mais um evento excelente. Sou um pouco suspeito para falar pois dessa vez tive a oportunidade de ajudar na organização do primeiro RejectConf para a comunidade Ruby e Rails brasileira. Não posso deixar de agradecer ao Akita, à Caelum e ao Prof. João Eduardo Ferreira do CCSL/IME-USP pelo apoio e ajuda na organização do evento.

Apesar de termos atrasado um pouco o cronograma, já sabíamos que isso podia acontecer (big design up-front não funciona :P). No entanto, a qualidade dos palestrantes e a participação do público em geral superou e muito minhas expectativas.

Foi muito bom conhecer algumas pessoas pessoalmente, como o Eduardo Fiorezi, o Vinicius, Tapajós e o pessoal da ImproveIt, além de reencontrar amigos e conhecidos, como o Carlos Villela, o Fernando Meyer, o Fabio Kung, Paulo e Jonas da Caelum, o Hugo e o George (ainda não o conhecia) do Pagestackr, meus amigos do IME (Pedro, Dairton, Giuliano, Fabricio, Jef) e muitos outros que com certeza estou esquecendo de listar.

Palestras e Palestrantes

Do ponto de vista técnico, todas as palestras foram excelentes. O conteúdo abrangia diferentes níveis de conhecimento, agradando aos iniciantes e aos desenvolvedores mais avançados. Todo o material vai ser disponibilizado, assim como os vídeos gravados no evento.

Os palestrantes estão de parabéns! Foi incrível como algumas palestras pareciam se “linkar” umas com as outras. Parecia até que havíamos combinado algo antes :-)

RSpec e RSpec on Rails

Minha palestra foi curta e, apesar de uns probleminhas técnicos (bugzinhos), correu tudo bem. Eu falei brevemente sobre o conceito de Behaviour-Driven Development e mostrei um pouco de código ao vivo. Desenvolvi uma aplicação demo para obter feedback (positivo ou negativo) das palestras e deixei meu notebook ligado para quem quisesse votar durante o evento. Apesar de alguns problemas com a rede wireless, algumas pessoas conseguiram acessar e votar. Tirei um screenshot do widget criado pelo Safari 3 mostrando o resultado final da votação. É claro que o placar é irrelevante a não ser pelo fato de que o coffee-break venceu disparado!! :-)

Os slides da minha palestra já estão disponíveis para download, assim com o código-fonte da aplicação demo e as notas que usei na implementação ao vivo.

Se você tem alguma sugestão para melhorar minha palestra, por favor deixe um comentário. Você gostou ou não gostou da minha palestra? Aprendeu alguma coisa? O bug na demonstração atrapalhou muito? Você prefere ver código ou slides? Essa palestra será a base do que vou apresentar no próximo evento de dezembro, o RioOnRails, por isso sua opinião é muito importante. Lá terei mais tempo para elaborar os conceitos e mostrar um demo mais completo e detalhado. Espero vocês lá!

Mais uma vez, todos os que participaram estão de parabéns. Tenho consciência que podemos melhorar muitas coisas para o ano que vem, mas o importante é que demos o primeiro passo. Acredito que daqui pra frente a comunidade Ruby e Rails brasileira só tende a crescer.

Se você é de São Paulo ou do Rio de Janeiro, nunca me (ou)viu falar ao vivo e estiver interessado em me conhecer para bater um papo, vai ter algumas chances nos próximos meses. Depois de participar de um evento de Software Livre, de XP e de Python nesse ano, vou apresentar algumas palestras para a comunidade Java, Ruby e Rails. Detalhes a seguir…

09/Nov e 10/Nov: Conexão Java '07 Hands On

No dia 10 de Novembro, das 11:30 - 13:00, vou apresentar uma palestra sobre Métodos Ágeis chamada “Agile Methods for the Traditional Guy”. Espero que o título não assuste as pessoas, pois o tema é legal e a idéia é dar uma introdução geral sobre os princípios do Manifesto Ágil, XP, Scrum, Lean, discutir problemas dos métodos tradicionais e desmistificar alguns mitos sobre Métodos Ágeis. As inscrições podem ser feitas pelo site do evento (com desconto até o dia 31/Out) e o evento acontecerá na Universidade Anhembi Morumbi da Vila Olímpia.

Quem for participar terá a chance de assistir ótimas palestras de alguns amigos: o Carlos Villela vem apresentar o keynote e falar sobre o “Arquiteto de uma nota só”; o Phillip Calçado vem reapresentar a ótima palestra sobre arquitetura do JustJava (dessa vez sem o Paulo), além de coordenar uma atividade que promete ser divertida: a Oficina do Arquiteto; O Fernando Meyer vai falar sobre DSLs e ANTLR; o Alexandre Magno vai falar sobre Scrum, dentre outras palestras muito boas.

Além das palestras, estarão acontecendo também mini-cursos em paralelo. O pessoal da Caelum vai ensinar Hibernate, AJAX e JSF, Java ME e JPA. Pelo que conheço da qualidade dos cursos deles, são mini-cursos ótimos e imperdíveis se você estiver interessado em aprender um pouco sobre essas tecnologias.

17/Nov: RejectConfSP '07

No fim de semana seguinte (sim, no meio dos feriados) estou ajudando o Fabio Akita a organizar a primeira RejectConf em São Paulo. A idéia é juntar a comunidade Ruby e Rails para mini-apresentações (de 10 a 30 minutos) sobre diversos assuntos, além do networking, troca de conhecimentos e diversão :-)

O evento vai acontecer no IME-USP, no Auditório Jacy Monteiro, das 11:00 - 17:00. As inscrições são gratuitas estão atualmente com lista de espera, mas pode ser feitas neste formulário. Quem estiver interessado em apresentar algum tópico, basta preencher este outro formulário.

Minha mini-palestra será sobre RSpec e RSpec on Rails. Quem quiser um gostinho de como é programar com RSpec/RBehave pode assitir o screencast #01 do Dojo@SP.

08/Dez: Rio on Rails

Por fim, mais um evento da comunidade Rails, organizado pelo Vinicius e o pessoal da Improve It. O evento está confirmadíssimo e acontecerá no SENAC, das 9:00 - 18:00. As inscrições custarão R$50,00 e estarão disponíveis em breve no site do evento (disponibilizado pela Improve It nos próximos dias).

O assunto será RSpec e RSpec on Rails novamente, mas dessa vez terei mais tempo para me apresentar.

Nos vemos por lá!

Acredito que os eventos serão bastante divertidos e informativos e espero que ninguém durma de tédio nas minhas apresentações :-). Faça sua inscrição e deixe um alô nos comentários para saber se devo te encontrar por lá!

Na reunião do Dojo@SP do último dia 03/Out decidimos gravar um screencast do Kata que estávamos resolvendo: Splitting the Loot. Nessa reunião, eu apresentei um Kata Preparado, programando em Ruby e utilizando RSpec+RBehave como frameworks de BDD. O resultado está finalmente disponível no Google Video:

Depois da conversão, a qualidade do vídeo acabou sendo prejudicada. No tamanho original dá pra assistir, mas as letras ficam pequenas (principalmente quando mudo pro terminal). Os atalhos de teclado (gravados com o KeyCastr) também ficam ruim de ver.

Para assistir uma versão com resolução melhor, disponibilizei o arquivo original para download no site da AgilCoop:

• Dojo@SP Screencast #01 (1h33min / 266Mb)

O código final dessa e de todas as nossas reuniões pode ser obtido no nosso Google Groups.

Gostaria de agradecer a Mariana Bravo por ter criado nosso logotipo, o Paulo Sacramento, por ceder a música Batida Urbana sob a licença Creative Commons - Atribuição-Uso Não-Comercial 2.5 Brasil (utilizada na introdução e no final do vídeo) e aos participantes da reunião pelo feedback e ajuda na resolução do problema: Breno Franco, Daniel Cordeiro, RBP e Thiago Colucci.

Espero que esse vídeo ajude a mostrar como o Dojo funciona. O feedback de vocês é muito importante. Caso o retorno seja positivo, podemos produzir outros vídeos semelhantes. Se você se interessou pelo Dojo@SP, junte-se a nós!