Neste dia 29 de agosto tivemos o primeiro evento especificamente de Rails aqui no Rio Grande do Sul, que foi muito bom por sinal! Parabenizo o pessoal da Softa por tomar frente na organização e promover o evento.
Disponibilizo abaixo os slides da minha palestra de Behaviour-Driven Development e os projetos no github, como havia prometido.
Espero que tenham gostado!
Tenho visto diversas pessoas falando do Shoulda, e algumas que já sentiram o gosto do RSpec e depois também gostaram do Shoulda. Até aí sem problemas. Agora, ao passo que surgem comparações entre RSpec e Shoulda, um sinal amarelo deveria aparecer por aí e deixar algumas coisas bem claras. E este é o objetivo do post.
Em primeiro lugar, a diferença fundamental é: RSpec é totalmente focado no teste de comportamento (Behaviour). Esse é o seu objetivo e a orientação de sua sintaxe. Ok, é possível sim fazer testes no estilo unit/test com RSpec, mas obviamente, não é a intenção ao usá-lo. É como uma implicação na lógica clássica: vou usar RSpec, logo (deveria) me focar em testar comportamento. E, numa implicação, o inverso não é necessariamente verdadeiro.
Resumindo: RSpec é focado em testar comportamento (Behaviour Driven Development). Shoulda não é focado em testar comportamento (Test Driven Development sem o “behaviour” na história), mas tem a intenção de melhorar o test/unit com helpers, macros e contextos. É um açucar sintático que torna os test/unit mais, digamos, pragmáticos e também documentados.
Dito isso, deve-se ter muito cuidado ao compará-los porque são ABORDAGENS e VISÕES diferentes, embora o objetivo de testar seja o mesmo.
Podemos comparar apenas da seguinte forma: Eu gosto mais de RSpec, ou eu gosto mais de Shoulda. Ponto. Qualquer comparação dizendo “este é melhor”, ou “este é pior” deve ser evitada e levar essa diferença fundamental em consideração: “Eu gosto de testar comportamento com o RSpec” ou “Eu prefiro testar no modelo test/unit com Shoulda” são argumentos válidos e não depreciativos entre ambos.
Agora, quando eu vejo alguém falando que faz “BDD com Shoulda”, isso me preocupa um pouco. Eu me pergunto: “Será mesmo?”. Confesso, sou um pouco purista no que tange a testar comportamento e estou sempre procurando uma melhor forma de fazê-lo. E já vi opiniões semelhantes por aí.
É possível fazer BDD com Shoulda? Sim, mas de fato não é a tendência ao usar o Shoulda. Vejamos porque.
Suponhamos a seguinte linha, retirada da documentacao do Shoulda:
class Article < ActiveRecord::Base { named_scope :visible, :conditions => {:visible => true} }
E o teste para ela com Shoulda:
should_have_named_scope :visible, :conditions => {:visible => true}
Então eu pergunto: testei comportamento ou garanti que existe aquela linha de código no meu Model? Naturalmente, a segunda opção. Não que isso esteja errado, pelo contrário, seu teste tem 100% de cobertura.
Mas, e se minha lógica estiver errada? Digamos que você esqueceu que ao chamar Article.visible não deveria incluir os itens que não foram publicados ainda. Ou seja, você esqueceu uma condição que deveria fazer parte da regra. Mas você tem o teste, então (teoricamente) sua mente está livre do medo de ter errado.
É nesse ponto que entra a idéia de testar comportamento. É mais provável que você descubra esse problema se pensou anteriormente no comportamento que sua busca deveria ter. Note, eu disse que é mais provável, não é garantido que você perceberia isso imediatamente.
Estamos lidando com uma busca. Logo, vamos testar o comportamento desta busca simulando-a com exemplos (sintaxe abaixo é RSpec):
describe Article, "being displayed on the website" do it "should display only visible entries" do visible = Article.create(:name => "Art1", :visible => true, :published_at => Time.now) hidden = Article.create(:name => "Art2", :visible => false, :published_at => Time.now) visible_not_published = Article.create(:name => "Art3", :visible => true, :published_at => nil) Article.visible.should be_eql([visible]) end end
Nota: Num contexto real, estou usando o plugin factory_girl, da própria empresa que criou o Shoulda. É ótimo, sugiro o uso.
Simulei alguns cenários e acredito que é mais provável que eu encontre um erro no comportamento dessa forma, pois fui obrigado a formular um exemplo. Quem é acostumado a unit/test geralmente olha essa situação como um pouco de overkill: o que faria em uma linha, demorou bem mais tendo que pensar nos exemplos e na construção do teste em si.
Mas, o foco de BDD é CLAREZA nos testes e não DRY. Nem sempre um teste deve ser DRY.
É claro que é perfeitamente possível fazer isso com Shoulda e outras libs. A questão é: macros como should_have_named_scope induzem a esquecer o comportamento em benefício da simplicidade e rapidez em escrever o teste.
Escolher entre Shoulda e RSpec é uma questão de gosto, como eu falei no começo. Ou você gosta de focar seus testes no comportamento de um objeto, ou você prefere utilizar asserções do test/unit.
Para finalizar, volto a dizer que estamos falando aqui de BDD e TDD, e o objetivo aqui não é comparar frameworks nem gerar flames. “Shouldeiros”, não me crucifiquem por favor 
E opiniões são bem vindas sobre isso tudo.
Obrigado!
Estamos buscando mais brasileiros para o time, abaixo alguns detalhes sobre a oportunidade.
Pixily, a well-funded start-up is looking for experienced Rails programmers. We provide you with excellent opportunities to learn and work with the best in the industry and build amazing products.
Pixily helps professionals, home offices and small businesses aggregate, organize and find paper and digital documents. You mail-in your paper documents periodically to us in prepaid envelopes or boxes, we scan them into your online accounts and make the content searchable. You can then search, organize, share, and download documents. You can also upload documents or scan them into your account directly.
With Pixily, you save money, time, space and trees.
Get a taste for the beta by viewing this video
• A great working environment
• An opportunity to work with the best
• An opportunity to learn and apply cool scalable technologies in cloud computing, Rails, Ajax, RSpec and Java
• An opportunity to be creative and make large contributions
• An opportunity to grow with the company
• Strong fundamentals (MVC, data structures, etc.,)
• Experience in at least one production Rails application
• A working knowledge of Javascript, CSS and SQL. (Expertise in Javascript and CSS would be a big plus)
• Good spoken and written communication skills in English
• Ability to work in geographically distributed teams over IM and phone
• A Smart Generalist. (Competent in both depth and breadth of technologies)
Please send your resume to careers@pixily.com, if you are interested.
Pixily is an Equal Opportunity Employer.
UPDATE: Agradeço a presença de todos que participaram, o encontro foi ótimo. Os slides estão disponíveis na seção de Palestras. Qualquer dúvida, entre em contato direto comigo por e-mail ou deixe um comentário
O Instituto de Informática Unisinos convida para o evento gratuito “Conhecendo Ruby on Rails”, onde serão abordados os seguintes tópicos:
O evento é gratuito e acontecerá no dia 13/6 (sexta-feira) no Auditório do Centro Empresarial Presidente Kennedy, em Porto Alegre.
Inscrições até dia 11 de junho.
==> As vagas são limitadas!
Realização: 13/06/2008
Horário: às 18h30min
Local: Auditório do Centro Empresarial Presidente Kennedy
Avenida Carlos Gomes, 111 – Bairro Auxiliadora – Porto Alegre
Acesse o link: http://www.ccti.unisinos.br/ccti_interna.php?corpo=acontece&codigo=253
Para os residentes da região metropolitana de Porto Alegre – RS, estão abertas vagas para a Formação Desenvolvedor Web com Ruby on Rails, a ser realizada no Instituto de Informática Unisinos.
A carga horária é de 80 horas, dividia em 3 módulos. A estrutura está adequada tanto para profissionais que já programam em outras linguagens como iniciantes. Na página acima têm todos os detalhes 
Não sei se é oficial (nem mesmo se estou atrasado comentando isso), mas vi agora que passaram a constar alguns tickets no Lighthouse: http://rails.lighthouseapp.com/
Agora a logística parece ser Github + Lighthouse. O Github é muito bacana, já tem vários forks do Rails, o último que vi é um esforço para implementar características thread-safe.
Legal, vamos acompanhar o progresso da migração
UPDATE: Pois é, passei batido no feed do weblog.rubyonrails.com e não vi o anúncio oficial hehe. Não só o Rails foi para o Lighthouse, mas também o Capistrano e Prototype. Acontece
Acabaram ontem os 3 ótimos dias de FISL (com uma baita churrascada), que a cada ano fica mais interessante. Neste ano poucas palestras me atraíram, mas o que realmente valeu à pena foi conhecer grandes pessoas, tanto da comunidade Rails, como de outros lugares.
O Lucas Húngaro e o Tiago (Lecom), Ronaldo Ferraz e a Taís (Brasigo/BlogBlogs), Fábio Akita e Rodrigo (Sugerworks), Carlos Eduardo (e-Genial), Everton Carpes, Weldyss Santos, Vinícius Teles (ImproveIT), o pessoal da UDESC (Grupo Colméia), Sylvestre Mergulhão, entre outros que me fogem da memória neste instante.
Revi também os amigos, Júlio Santos Monteiro, Evandro Dutra, Pablo Targa e outros que convivem comigo na universidade, como o Joni Canal e o Eduardo Pittol.
Conheci também o Evan “Rabble” Henshaw-Plath, profissional que trabalha no Yahoo! e é responsável pelo recente Fireeagle.com, e outros sites como Odeo.com. Ele foi palestrante na RailsConf 2007 também. Chegou com irreverência no stand do Rails Brasil, questionando-nos “Onde estão os Macs?”. Extremamente gentil e simpático.
Assisti à palestra de Seaside com Randal Schwartz. Foi uma pena que ficou muito focada na linguagem, e o framework sobrou pouco tempo. Um detalhe interessante é que já nos primeiros slides ele disse acreditar que o Seaside será o próximo Rails. Ávidos e curiosos (rsrs), eu e o Júlio (que o abordou) conversamos rapidamente com ele, e resolvi perguntar o por quê desta opinião. Segundo ele, dois fatores: velocidade e debugging. A propósito, o debugging é fora do comum mesmo, pretendo olhar (novamente, mas com calma) o Seaside.
Algumas descobertas:
O encerramento foi magnífico, com o onipresente Jon “maddog” Hall que, com muita sabedoria e irreverência (assim como em TODOS os FISL que ele fala), levantou o público através de aplausos.
Resumindo: foi ótimo! Infelizmente minha câmera estava há alguns kilômetros daqui, mas aguardo as fotos do pessoal que estiver lendo e que, por gentileza, puder mandar para jonysk AT gmail DOT com.
Este cenário surgiu da necessidade de sincronizar o desenvolvimento de mais pessoas num projeto Rails (usando GIT), no que diz respeito a vendor branches externos (plugins). Quando se usa SVN, instalar plugins no Rails com ./script/plugin install -x parece uma maravilha até o momento que você começa a alterar seus plugins.. Quando faz isso, não pode comitá-los, e fica no impasse sobre o que fazer. Nem preciso comentar o quão estranho seria mandar patchs para equipe…
As premissas, antes de tudo, eram:
Deixe-me explicar a primeira premissa: Usar Subversion implicaria em merges a cada atualização dos plugins. Independente da solução que fosse usada para o merge de um plugin (piston, svnmerge, svn_load_dirs), o Subversion não trabalha bem com arquivos removidos/renomeados/movidos. Seja qual for a estratégia, o fato de fazer merge em repositórios diferentes no Subversion é um “tiro no escuro”: você nunca sabe está realmente idêntico ao repositório que você sincronizou, principalmente quando há mudanças drásticas neles (arquivos removidos/renomeados/movidos), e vai deixando seu rastro de desorganização com o tempo. No site do Piston eles também comentam sobre isso.
Uma dica rápida para fazer o deploy usando remote_cache e mongrel_cluster. Antes da dica, uma introdução nos temas abordados:
Capistrano é uma ferramenta que, a grosso modo, permite realizar tarefas remotas de todos os tipos. Uma das aplicações comuns é no processo de deployment do Rails que é, de longe, facilitado pelo Capistrano
mongrel_cluster é, em suma, um Gem que agrupa um cluster de servidores de aplicação Mongrel, simplificando a tarefa de gerenciá-los.
Remote cache é uma estratégia de deployment do Capistrano que executa uma tarefa interessante: ela faz um clone do repositório GIT (ou um checkout, se for Subversion) e atualiza a aplicação apenas com um rsync, ou seja, copia apenas os arquivos modificados para a release atual.
É com muita satistafação que anuncio a nova formação “Desenvolvedor Web com Ruby on Rails”, a ser realizada aos sábados no Instituto de Informática – UNISINOS em São Leopoldo, Rio Grande do Sul (região metropolitana de Porto Alegre).
Como o nome sugere, é uma formação bastante abrangente que envolve não apenas o desenvolvimento de aplicações com Ruby on Rails, mas também módulos de HTML/Webstandards e SQL, provendo uma base necessária para construir aplicações web completas.
A carga horária em Ruby e Rails é forte. Serão 60 horas no total (20-Ruby, 40-Rails) onde propõe-se uma formação consistente em tópicos não só básicos, mas também deployment, RESTful, etc, assim como o desenvolvimento de uma aplicação com contexto real e útil.
Cabe um comentário pessoal aqui: Estou bastante satisfeito em pensar que esta é mais uma iniciativa visando a divulgação do Ruby on Rails no Brasil. Espero contribuir ampliando a rede de desenvolvedores e boas aplicações saindo do Brasil. Ah, e nos veremos também no FISL, nos stand do Rails Brasil!
Telefone e fax: (51) 3328-2221
Proposta on-line: http://www.ccti.unisinos.br/ccti_interna.php?corpo=faleconosco
Objetivo:
Capacitar os profissionais a desenvolver aplicações Web utilizando os recursos do framework Rails e da linguagem Ruby, seguindo os princípios e práticas que norteiam o modelo de desenvolvimento ágil.
Público-Alvo:
Desenvolvedores PHP, Java, .NET e/ou outras linguagens; Programadores com pouca ou bastante experiência.
Pré-requisitos:
Conhecimentos em ambiente Windows ou Linux; Noções básicas de programação; Desejável conhecimento em Orientação a Objetos.
Realização da formação: De 29/03 à 05/07
Local: Câmpus Unisinos – São Leopoldo
Horário > Sábado 08:30 até 12:30 e das 13:30 até 16:00
HTML e WebStandards – 20 horas -> apresenta a linguagem HTML e os últimos padrões de desenvolvimento de páginas para Web, incluindo os Web Standards, a linguagem XHTML, e o desenvolvimento de páginas utilizando CSS e Tableless Design.
Realização: 29/03/2008 – 12/04/2008 – São Leopoldo
Linguagem SQL Padrão ANSI – 20 horas
Realização: 19/04/2008 – 03/05/2008 – São Leopoldo
Introdução à linguagem Ruby – 20 horas -> Compreender a linguagem Ruby e a aplicabilidade de suas principais funcionalidades para otimizar a construção de algorítimos.
Realização: 10/05/2008 – 24/05/2008 – São Leopoldo
Ruby on Rails prático – 40 horas -> Capacitar o aluno a desenvolver aplicações web com o framework Rails utilizando seus principais recursos, melhores práticas e técnicas de desenvolvimento, voltadas a projetos e cenários reais.
Realização: 31/05/2008 – 05/07/2008 – São Leopoldo
Wordpress Themes sponsored by BlogPerfume
Jony dos Santos Kostetzer is powered by WordPress and FREEmium Theme.
developed by Dariusz Siedlecki and brought to you by FreebiesDock.com