de recursos e entender o que cada parte do MVC faz devidamente. Isso significa
que, sempre que possível, devemos modelar nossas aplicações como recursos e que
nunca, jamais, devemos colocar regras importantes de negócio em Controles, por exemplo, pois não é o papel dele.
Entendido isso, vamos continuar. Agora é hora de voltar a programar!
80
Capítulo 4
Primeiros passos com Rails
Conhecer seus limites já é estar a frente deles.
Georg Wilhelm Friedrich Hegel
Para criar uma aplicação Rails, usaremos um script que a gem do Ruby on Rails
instala no sistema. Se você ainda não instalou Ruby e Rails, dê uma olhada na se-
ção 2.1, lá você encontrará instruções de como fazê-lo e em seguida volte aqui para
começarmos a construção do Colcho.net.
4.1
Gerar o alicerce da aplicação
Vamos ao terminal gerar o esqueleto para o Colcho.net. Para criarmos um novo pro-
jeto, precisamos executar no terminal o comando rails new, passando em seguida
o nome do projeto que será criado, no caso colchonet.
Ao começar a instalar, aproveite para pegar mais café ou sua bebida favorita, pois
pode demorar um pouco.
Casa do Código
Capítulo 4. Primeiros passos com Rails
Figura 4.2: Estrutura de pastas geradas - 2
Cada pasta possui um significado e já é um efeito do conceito que vimos no
capítulo 1, chamado Convenção sobre Configuração. Isso significa que não teremos
um XML que dirá em que pasta fica o quê, em contrapartida, significa também que
temos que seguir a estrutura proposta. Eu pessoalmente acho que é uma ótima troca!
Vamos entender o que é cada uma delas:
app - É onde fica o código principal da
sua aplicação. Controles ficam na pasta
controllers, apresentações em views, javascript e CSS em assets e modelos em
models. A pasta helpers guarda códigos auxiliares usados em apresentações e
mailers são classes para o envio de emails.
config - Configuração da aplicação, como informações sobre banco(s) de da-
dos, internacionalização de strings (I18n), time zone, e outras coisas.
db - Armazena migrações e o esquema do banco de dados usado na aplicação.
doc - Toda a documentação de sua aplicação deve estar aí.
lib - Armazena código externo à sua aplicação mas que não faz parte de gems.
83
4.2. Os ambientes de execução
Casa do Código
Aí também ficam tarefas rake, código que deve ser executado fora do ambiente
Web.
log - Onde ficarão seus logs e, se tudo der certo, uma pasta que você raramente
terá que acessar.
public - Arquivos estáticos como favicon.ico, robots.txt, 404.html e
500.html, que serão exibidos nos casos de página não encontrada e erro de
servidor, respectivamente.
script - Guarda o script rails, usado para gerar código (vamos ver mais de-
talhes sobre esse comando a seguir).
test - Testes unitários, integração, funcionais e performance ficam aqui. Este
é um tópico bastante complicado e merece seu próprio livro, então, ao invés
de vermos o assunto pela metade, indico a leitura do RSpec Book [5] ou o Guia
Rápido de RSpec [9].
tmp - Nesta pasta ficam arquivos temporários como PIDs, cache, entre outros.
vendor - É onde você deverá instalar plugins de terceiros que não são gems.
Também é uma boa ideia instalar eventuais plugins javascript e CSS aqui, para
separar o código da sua aplicação.
Dê uma olhada no conteúdo das pastas e abra alguns arquivos, apenas por curi-
osidade, para quebrar o gelo, já que você e o Rails ainda são estranhos entre si. Dê
uma atenção especial ao arquivo config/application.rb, o arquivo de configura-
ções gerais da sua aplicação.
4.2
Os ambientes de execução
O Rails possui o conceito de ambientes de execução do aplicativo e cada um deles
possui um conjunto próprio de configurações. Um exemplo de configuração que
varia por ambiente é o caching de classes, ou seja, todo o código Ruby presente na
pasta app será carregado apenas uma vez. Isso é bastante útil em produção devido a
maior performance, porém, em desenvolvimento, atrapalha bastante.
Por padrão, o Rails possui, mas não se limita a, três ambientes:
development: É o ambiente padrão, onde o Rails é totalmente configurado
para facilitar o desenvolvimento;
84
Casa do Código
Capítulo 4. Primeiros passos com Rails
test: Ambiente para se executar testes de todos os níveis (unitários, integra-
ção, etc.);
production: É o ambiente em que a aplicação deve executar quando rodando
no servidor, para os seus usuários. Por esse motivo, é otimizado para perfor-
mance.
Cada
ambiente
possui
seu
próprio
banco
de
dados.
O
arquivo
config/database.yml possui a definição da configuração de banco de dados
para cada ambiente. Veja o exemplo para o ambiente de desenvolvimento, usando o
adaptador para o PostgreSQL:
development:
adapter: postgresql
database: colchonet_dev
host: localhost
username: vinibaggio
password:
pool: 5
timeout: 5000
Outros
arquivos
relacionados
com
ambientes
ficam
na
pasta
config/environments, no qual cada arquivo é carregado automaticamente de
acordo com o ambiente em execução.