edit

Seminário Ruby on Rails Reloaded

Publicado por Vinicius Manhães Teles há mais de 2 anos.

O que acontece quando você está diante de ótimos palestrantes, na companhia de bons amigos, tem a chance de fazer novas amizades e aprende um monte de coisas interessantes? Será que não podia ser todo dia assim? :-)

O Seminário de Ruby on Rails produzido pela Livraria Tempo Real foi ótimo, a começar pelo Sol, que os visitantes cariocas levaram na bagagem. ;-)

Sobre as apresentações...

Ruby - Conhecendo a Linguagem (Eustáquio Rangel)

Pontos fortes

O Eustáquio começou muito bem citando que "uma linguagem é boa quando muda seu jeito de pensar." É verdade, Ruby definitivamente vem mudando meu jeito de pensar. Ele mostrou aspectos interessantes da linguagem. Meus preferidos:

• Redefinição de operadores.
• Facilidade para adicionar métodos em uma classe, ou instância, em runtime.
• Herança única, mas módulos que permitem fazer mixins.
• Blocos.
• Sintaxe limpa.
• Código menor e mais eficiente.
• Duck typing.
• Instance_eval.

Poderia melhorar

O aspecto didático ficou um tanto comprometido à medida que a apresentação se aproximava do final, já que recursos avançados da linguagem começaram a ser mostrados, sem que houvesse tempo para aprofundar a explicação dos mesmos. Para alguns, o efeito pode ter sido o contrário do desejado. Ao invés de perceberem a simplicidade e a beleza da linguagem, talvez tenham sido intimidados pela complexidade aparente dos exemplos. Ainda no aspecto didático, um pequeno detalhe que me incomoda muito é mostrar exemplos em que nomes de variáveis têm apenas uma letra, especialmente quando envolvem blocos:

[1, 3, 5, 7, 9].find {|v| v*v > 30 }

versus

[1,3,5,7].inject(0) {|sum, element| sum + element}

Esses trechos de código foram extraídos do livro Programming Ruby (2nd. Edition). É um livro magnífico, mas também cai no mesmo erro que observei algumas vezes na apresentação. Talvez você não saiba o que esses códigos fazem. Não tem problema. A questão é que no primeiro, |v| v*v > 30 é muito obscuro. O que é esse v quando você ainda nem sabe o que é um bloco? No segundo trecho, |sum, element| sum + element é mais expressivo porque os nomes das variáveis transmitem informação. Isso ajuda a tornar o segundo código menos obscuro, embora o que ele faz seja, na prática, mais esquisito do que a tarefa realizada pelo código anterior.

Na minha opinião, usar uma variável chamada v deveria ser evitado em qualquer código, porque dificulta a compreensão. Confesso que demorei para entender blocos (se é que já entendi) em parte devido a inúmeros exemplos que cometiam essa falha. Infelizmente elas estiveram presentes em alguns exemplos da apresentação.

Sugestões

Para um próximo evento, sugiro evitar slides em Power Point. Seria mais interessante mostrar o código, executá-lo e apresentar os resultados. Power Point é chato! Código é divertido e ver o resultado de sua execução é motivante. :-) O problema é que dá muito mais trabalho preparar uma apresentação nesse formato. Seja como for, eu aprendi bastante na apresentação do Eustáquio e acredito que aprenderei ainda mais se, em outra oportunidade, o formato envolver mais código, mais resultados de sua execução e, se possível, pouco ou nenhum slide.

Começando com Ruby on Rails: instalação, configuração e anatomia (Adriano Dadario)

Pontos fortes

O conteúdo da apresentação era muito bom, pois dava uma visão geral de vários aspectos do Rails. Além disso, o aplicativo que o Dadario levou para mostrar era muito bacana.

Poderia melhorar

Senti que se perdeu uma oportunidade fantástica nessa apresentação porque ela também se baseou demais em slides. Isso fez com que um conteúdo excepcional, acabasse embrulhado em um formato que não empolgava. Quem está na platéia quer ver a coisa acontecer! Fica ansioso para ver o software rodando. E com o Rails, consegue-se mostrar muito software interessante, em pouco tempo. Portanto, o formato acabou sendo o grande vilão e, para piorar, acabou sobrando pouco tempo para mostrar o aplicativo que o Dadario desenvolveu, que claramente era o ponto alto da apresentação.

Sugestões

No título da palestra tem a palavra anatomia. Para mim, ela é a chave para se apresentar o mesmo conteúdo, de forma bem mais empolgante. A idéia seria começar mostrando o aplicativo que ele fez, abrir o código e mostrar como as coisas foram feitas, como os elementos são estruturados em um projeto Rails, como é a conexão com o banco de dados, como funciona o MVC, como funciona a idéia de convenção, ao invés de configuração etc.
É melhor começar pelo aplicativo porque motiva as pessoas a compreenderem o que está por trás, o que permitiu fazer algo tão bacana em tão pouco tempo, como foi o caso. Resumindo: minha sugestão é começar de traz para a frente. Mostre o software e convide as pessoas a entender como foi desenvolvido. E, definitivamente, abandone esses slides. São mais fáceis de preparar, mas dão um trabalhão para acompanhar. Em se tratando de apresentações, o inverso normalmente é melhor.

Ruby on Rails: criação de uma aplicação simples (Bill Coutinho)

Pontos fortes

Finalmente o modelo "show me the code" começou a emergir. A maior parte da apresentação foi puro desenvolvimento de código. O Bill mostrou características interessantes, como o uso de migrations. Aprendi, por exemplo, sobre o scaffold em Ajax. Muito útil.

Poderia melhorar

O início da apresentação repetiu um problema que aconteceu nas duas anteriores: contexto demais. Todos os apresentadores até esse ponto gastaram boa parte do tempo inicial da apresentação descrevendo Ruby, Rails e suas respectivas histórias. No caso do Bill, o problema foi ainda mais grave, pois ele acabou repetindo grande parte do que já havia sido dito na parte da manhã, no que se refere ao contexto. Foi uma pena, pois isso reduziu o tempo da parte mais interessante: a codificação do aplicativo de exemplo.
Esse problema do histórico e do excesso de contexto no início de apresentações, livros etc parece ser endêmico e também não estou livre dele. Recentemente Kathy Sierra, uma das criadoras da série de livros Head First, escreveu um artigo magnífico sobre essa questão. Vale a pena ler esse texto. Algumas sugestões que ela dá:

• Não comece pelo começo
• Mostre, ao invés de falar a respeito
• Pelo amor de Deus, não comece pela história
• Não comece pelos pré-requisitos

Nessa apresentação, tive a sensação de que mais uma vez se perdeu uma grande oportunidade de levar a platéia ao delírio. O Bill acertou com o esquema "show me the code", mas percebi que isso não basta, é preciso que haja "show me the code and the screen!" Havia código, mas durante boa parte da apresentação ele esqueceu de mostrar o resultado da execução. Ou seja, não víamos as telas que eram produzidas. Elas só começaram a ser mostradas no finalzinho da apresentação.

Sugestões

Deixar o contexto de lado, esquecer a história, não falar nada sobre Ruby. Ao invés disso, começar codificando e mostrando uma tela de impacto rapidamente, o que é fácil de fazer, sobretudo com o uso do scaffold em Ajax. Ao longo da apresentação, pode-se mencionar aspectos interessantes do Ruby, do Rails e, ao final, pode-se até mencionar um pouco da história. Mas, o filé mignon precisa ser lançado aos leões o mais rapidamente possível, logo no início da apresentação.

Rails tricks: alta produtividade com Rails (Ronie Uliana)

Pontos fortes

O primeiro, naturalmente, é o próprio Ronie. Seu jeito de apresentar e engajar o público é divertido. Também gostei muito dos assuntos que ele mostrou e aprendi bastante com coisas tais como:

• Plugins
• Produtização
• Efeitos especiais com Ajax
• Filosofia de deploy e facilidade de rollback
• O poder dos logs no Rails
• Escalabilidade com o modelo "share nothing"

Também gostei do fato de o Ronie ter demonstrado que se esforçou para preparar a apresentação da melhor forma possível. Ele começou mencionando que a apostila tinha mais conteúdo do que ele iria mostrar, porque percebeu que não daria tempo para falar tudo o que havia planejado. Ele ensaiou a apresentação, percebeu que o tempo ficaria curto para tanta coisa, priorizou o conteúdo e todos nós ganhamos com isso. Parabéns pela iniciativa!

Poderia melhorar

Apesar da preparação, o Ronie acabou tendo algumas dificuldades para mostrar a parte prática. Mas, ele tentou bravamente e conseguiu mostrar várias coisas interessantes. Seja como for, dá um trabalhão montar uma apresentação na qual fazemos algo ao vivo. Um pequeno detalhe que também me pareceu uma falta grave foi não mencionar o Capistrano. A filosofia do Capistrano foi bem exposta, mas a ferramenta em si não foi citada.

Sugestões

Como eu gostei de quase tudo, é difícil achar algo para melhorar na apresentação dele. A única coisa que me vem à mente é que, da próxima vez, talvez fosse interessante ter tudo instalado em um notebook, para não depender do computador do auditório. Isso provavelmente evitaria os problemas que ele enfretou durante as demonstrações.

Rails 1.1 com RadRails 0.7: o que era bom ficou ainda melhor (Fernando Gomes)

Pontos Positivos

• Excelente conteúdo
• "Show me the code and the screen" desde o início

Foi uma apresentação excelente, que se concentrou no que interessava desde o início. O Fernando estava bem preparado e o conteúdo envolveu muito mais do que o título da apresentação sugere:

• Características do RadRails
• Relacionamentos many to many com dados extras
• Calculations
• Associações polimórficas
• RJS e efeitos especiais com Ajax

Outro aspecto interessante foi o comentário sobre a forma não muito convencional pela qual ele ingressou no mundo Rails. Começou apredendo sobre Rails, depois sobre Ruby, depois sobre orientação ao objetos e, finalmente, HTML. O interessante é que isso revela um padrão que me parece muito produtivo: começar com um problema e deixar que a necessidade nos leve a aprender inúmeras outras coisas. No caso, ele aprendeu sobre Rails, que levou à necessidade de entender Ruby, que levou à necessidade de compreender mais sobre OO. O Rails também deve tê-lo levado à necessidade de aprender sobre HTML. O meu caso é parecido em um aspecto. Primeiro aprendi sobre Rails e depois comecei a aprender sobre Ruby.

O Fernando também ganhou pontos extras por usar um Mac, o que revela uma pessoa de extremo bom gosto e inteligência apurada! O que? Você acha que eu só fiz esse comentário porque também uso um Mac? Que isso! Uma coisa não tem nada a ver com a outra... ;-)

Considerações finais

Antes de encerrar, dizendo que eu adorei o evento, faço uma última reclamação: onde estavam os testes? Automação de testes é algo essencial em desenvolvimento de software e o Rails foi todo projetado para facilitar nossa vida ao máximo no que se refere a essa questão. Apesar disso, se falou muito pouco sobre essa parte durante o evento. Espero que no próximo, tenhamos maior ênfase em desenvolvimento orientado a testes no Rails.

O André, da Tempo Real, e todas as demais pessoas que ajudaram a organizar o evento estão de parabéns! Foi muito proveitoso, divertido e gratificante. Espero que muitos outros eventos parecidos comecem a pipocar em todos os lugares do Brasil e torço para que o Rails seja adotado rapidamente por muitos desenvolvedores. Nós todos da Improve It ficamos felizes de ter ido e aprendemos muito. Falando na gente, meu grande amigo Fábio Pereira, da Hayper, providenciou as fotos abaixo:

Equipe da Improve It. Da esquerda para a direita: Marcelo Alvim, Marcos Tapajós e eu.

Não é o máximo poder rever os amigos? Nessa foto, além do Tapajós e eu, está também o casal de amigos Fábio e Camila. Grandes amigos com quem tive a satisfação de trabalhar junto no ano passado.

Ooops. Lá fui eu atrapalhar a apresentação do Ronie. O André me pediu para falar rapidamente sobre nossa experiência ensinando XP e Rails na UFRJ, nesse segundo semestre. Eu juro que tentei ser breve. Tomara que não tenha tomado tempo demais do Ronie.

E quem diria que até o Bob Esponja apareceu por lá. Será que alguém pagou a inscrição dele? :-)

Enquanto aguardamos ansiosamente pelo próximo seminário de Rails, resolvemos criar uma comunidade de Rails no Rio de Janeiro para troca de idéias e para promover reuniões como as que temos feito nos últimos quatro anos no XP Rio. Ou seja, queremos nos reunir mensalmente para trocar experiências, codificar, bater papo e aprender mais. Assim nasce a comunidade Rio on Rails, que pode ser acessada aqui.

Aqui no Brasil já temos uma boa lista sobre Rails, que é a rails-br. Incentivo todos aqueles interessados em Rails a participar dela. O objetivo da Rio on Rails é complementá-la, sobretudo através dos encontros mensais que passarão a ser promovidos aqui no Rio.

Tags conferência, rails, ruby | 8 comentários