Primeiro ponto

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.

Segundo ponto

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.

OK, e como eu testo o comportamento neste caso?

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.

After all, it’s a matter of taste..

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!

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.

About Pixily:

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

What you can expect:

• 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

What we are looking for:

• 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.

O Instituto de Informática Unisinos convida para o evento gratuito “Conhecendo Ruby on Rails”, onde serão abordados os seguintes tópicos:

• Conhecendo o Ruby on Rails: Princípios por trás do Rails. Por que Ruby on Rails?
• Mercado interno e externo: oportunidades
• Cases e Projetos
• Demonstração
• Entre outros 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

INSCRIÇÕES ON-LINE

Acesse o link: http://www.ccti.unisinos.br/ccti_interna.php?corpo=acontece&codigo=253

A Pixily é um startup focado estritamente nos EUA. É um serviço online que ajuda clientes a agregar, organizar, localizar e compartilhar papéis e documentos digitais. Dessa forma:

Você coleta seus papéis e os envia por correio, é feita a conversão em arquivos PDF e os conteúdos são indexados para que seja possível buscar, compartilhar, organizar, etc.

Quero agradecer a ajuda do Fábio Espindula, que colaborou nesse processo e tem se mostrado uma pessoa fantástica. Ao Fábio Akita também, pelo auxilio nas dúvidas em relação a exportação de serviços e pelas dicas valiosas.

É isso aí, que venha o desafio!

Mais detalhes da formação.

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

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

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:

• A Globo.com está utilizando Rails em alguns de seus projetos, como a intranet. Estão contratando profissionais também.
• A Propus também usa Rails em alguns de seus projetos.
• O Yahoo! parece estar gradativamente entrando no Rails, agora com o Fireeagle. O Rabble nos contou mais ou menos a arquitetura deles, que está otimizada principalmente para o PHP, mas aos poucos o Rails tem entrado na jogada.

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.

As premissas, antes de tudo, eram:

1. Não usar SVN.
2. Flexibilidade para SVN e GIT como repositórios remotos.
3. Possibilidade de trabalhar em ambiente multiusuário, ou seja, vários desenvolvedores.

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.

(more…)

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.

(more…)

Sem mais, acho que dessa vez achei um tema bem agradável. Nada mais de bordas quadradas!

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!

INFORMAÇÕES E INSCRIÇÕES:

Telefone e fax: (51) 3328-2221
Proposta on-line: http://www.ccti.unisinos.br/ccti_interna.php?corpo=faleconosco

DETALHES DA FORMAÇÃO:

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

CONTEÚDO PROGRAMÁTICO:

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

Veja a página da extensão.

Agora, PHP é oficialmente suportado pela Microsoft em seus servidores IIS. Em suma, PHP para Windows (2003) está finalmente com suporte estável. Mais uma justificativa para argumentar caso surja um “.NET” no meio da conversa com os clientes que utilizam Windows como servidor, ou aquele temeroso papo de performance do PHP no Windows

Mais detalhes no site do Andi Gutmans ou em vários outros no Planet PHP.

19/10 - 13h às 16h
Minicurso: Introdução ao Ruby on Rails
Ministrante: Jony dos Santos Kostetzer
Local: Sala 6L 118
Objetivo: Conhecer alguns conceitos, recursos e práticas no desenvolvimento de aplicações em ambiente web utilizando a linguagem Ruby e o framework Rails.
Conteúdo: Introdução à linguagem Ruby; Instalaçao em amb. Windows e Linux; IRB; Modelo MVC; Introdução ao Rails; Primeiros passos; Relacionamentos; Ajax; IDEs; Atualidade e futuro do RoR.

Quem é estudante da Unisinos ou reside na região e gostaria de conhecer um pouco a linguagem Ruby e o framewok Rails, fica o meu convite

Importante:

• É necessário fazer a inscrição no evento através do site
• É solicitado aos inscritos que informem ao coordenador do evento (pelo e-mail cazella@unisinos.br) se desejarem realizar o minicurso: NOME COMPLETO, E-MAIL e NOME DO MINICURSO (Introdução ao Ruby on Rails). Este controle torna-se necessário devido ao número de vagas disponíveis ser limitado para minicursos.

Conto com a presença de vocês!

UPDATE: Muito obrigado pela presença de todos! Foi um ótimo encontro

Aqui estão os slides conforme prometido: Introdução ao Ruby on Rails

Até a próxima!

CREATE TABLE "estado"
(
"id" NUMBER  NOT NULL,
"nome" VARCHAR2(50),
"sigla" VARCHAR2(2)
);

MySQL e PostgreSQL não apresentaram problemas. Porém, a inserção deste SQL no Oracle força que todas as tabelas e campos sejam criados na forma de caracteres minúsculos.

(more…)

Por exemplo:

project:
id:
title: varchar(255)
sf_guard_user_id:

O código acima resultará no seguinte erro:

“Unable to resolve foreign table for column “sf_guard_user_id”"

(more…)

(more…)

Ok, sem mais para o primeiro post, mesmo porque ninguém o lê por completo se for extenso.