Ruby é uma linguagem de script criada em 1994 por Yukihiro Matsumoto (Matz). Ela foi grandemente inspirada em Python e Perl (daí o nome “Ruby”, outra pedra preciosa). Matz queria uma linguagem mais poderosa que Perl e mais orientada a objeto que Python.
Ruby foi desenvolvida com o “princípio da menor surpresa” em mente. O objetivo era fazer uma linguagem expressiva que ajudasse o programador a fazer o que pensa ao invés de “entrar no caminho”.
A linguagem é 100% orientado a objeto e dinamicamente tipada. Isto é, diferente de Java e C++, o tipo do objeto só é conhecido em runtime.
Como linguagem orientada a objetos, ela implementa algumas funcionalidades muito interessantes, como:
* Mixins, para lidar com o problema de herança múltipla.
* Closures ou Blocos de Código, que permitem que código seja passado como parâmetro. Muito útil ao se lidar com coleções.
* Continuations, uma espécie de “save game” para código. Permite que vc interrompa o código em um ponto e continue sua execução em outro lugar.
* Bindings, que permite que o contexto (variáveis, objetos) seja passado para outro ponto do código. É utilizado no “eval” e no mecanismo de template do Ruby, o ERB.
História do Ruby em dois parágrafos
Matz começou a trabalhar no Ruby em 24 de fevereiro de 1993, a primeira versão alpha ficou pronta em dezembro de 1994. Até 1996, ele trabalhou sozinho, quando começou a se formar uma comunidade ao redor da linguagem. A partir daí, apesar de ainda fazer a maior parte do desenvolvimento sozinho, Matz passou a receber fixes e patches da comunidade.
Em 2004, David Heinemeier Hansson e colaboradores criaram a “killer application” que está alavancando a linguagem para uma linguagem de primeiro nível: o RubyOnRails.
quarta-feira, 10 de março de 2010
Models
Models correspondem à camada de acesso ao banco de dados, implementada no
Rails por um componente denominado ActiveRecord.
O Rails automaticamente entende que todas as tabelas criadas no banco para uso
em models satisfarão a duas condições: terão um nome plural em inglês e terão
uma chave primária auto-incrementada chamada id. É possível mudar ambas as
condições, mas inicialmente ficaremos com elas para não ter que modificar o que o
Rails gera e usa automaticamente.
Para gerar um modelo, utilizamos o seguinte comando:
script/generate model categoria
exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/categoria.rb
create test/unit/categoria_test.rb
create test/fixtures/categorias.yml
create db/migrate
create db/migrate/20081011091001_create_categorias.rb
O comando acima gera toda estrutura de suporte ao modelo, incluindo testes e
migrações para o mesmo (abordaremos estes assuntos adiante neste livro).
O arquivo responsável pela implementação do modelo está em app/model/
categoria.rb e contém apenas o seguinte:
class Categoria < ActiveRecord::Base
end
Essas duas linhas, apoiadas pelo Rails, já providenciam uma riqueza de
implementação que nos permite recuperar, inserir e atualizar dados no banco, e
executar uma série de outras operações complexas sem a necessidade de qualquer
comando SQL direto.
Rails por um componente denominado ActiveRecord.
O Rails automaticamente entende que todas as tabelas criadas no banco para uso
em models satisfarão a duas condições: terão um nome plural em inglês e terão
uma chave primária auto-incrementada chamada id. É possível mudar ambas as
condições, mas inicialmente ficaremos com elas para não ter que modificar o que o
Rails gera e usa automaticamente.
Para gerar um modelo, utilizamos o seguinte comando:
script/generate model categoria
exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/categoria.rb
create test/unit/categoria_test.rb
create test/fixtures/categorias.yml
create db/migrate
create db/migrate/20081011091001_create_categorias.rb
O comando acima gera toda estrutura de suporte ao modelo, incluindo testes e
migrações para o mesmo (abordaremos estes assuntos adiante neste livro).
O arquivo responsável pela implementação do modelo está em app/model/
categoria.rb e contém apenas o seguinte:
class Categoria < ActiveRecord::Base
end
Essas duas linhas, apoiadas pelo Rails, já providenciam uma riqueza de
implementação que nos permite recuperar, inserir e atualizar dados no banco, e
executar uma série de outras operações complexas sem a necessidade de qualquer
comando SQL direto.
INCREMENTANDO AS VIEWS COM USO DE LAYOUTS
Para facilitar o desenvolvimento da parte visual de uma aplicação, o Rails possui um
conceito denominado layouts.
Na maioria das aplicações Web, as páginas variam somente no seu conteúdo
principal, possuindo cabeçalhos, rodapés e barras de navegação em comum.
Obviamente, um framework cujo maior objetivo é aumentar a produtividade do
desenvolvedor não exigiria que o código para esses elementos tivesse que ser
repetido em cada view. Um layout funciona como um arquivo raiz, dentro do qual o
resultado de uma view é inserido automaticamente.
Mais uma vez favorecendo convenção ao invés de configuração, o Rails define um
arquivo padrão de layout que é usado automaticamente por qualquer view a não ser
que haja especificação em contrário. O Rails também é inteligente o bastante para
somente usar um layout em views com a mesma extensão.
O layout padrão para a aplicação fica em um arquivo chamado application.html.erb,
dentro do diretório app/views/layouts.
Se olharmos agora o código gerado pela página que criamos no nosso primeiro
exemplo de Controller e View, teremos o seguinte:
Como você pode notar, não estamos gerando nenhum dos elementos HTML
geralmente vistos em uma página comum.
Vamos criar o arquivo application.html.erb no diretório especificado, com o
seguinte conteúdo:
Central Eventos
<%= yield %>
Temos no arquivo acima, o primeiro exemplo de uso de código Ruby dentro de
uma view, delimitado pelos marcadores <% e %>. Aqueles familiarizados com PHP e
ASP reconhecerão o estilo de marcadores, com o uso de <%= objeto %> para
retornar conteúdo.
No caso acima, o método especial yield retorna o conteúdo atual gerado pela ação,
seja por meio de uma view ou usando render diretamente. O método yield tem
uma conotação especial no Ruby, servindo para invocar o bloco associado ao
contexto. Inserido em um layout do Rails, o bloco define a execução da ação, com
seu conseqüente retorno de conteúdo.
A nossa página recarregada agora fica como mostrado abaixo:
Não parece muita coisa, mas, olhando o código, você verá o seguinte:
O que precisamos fazer agora é extender o nosso layout. O nosso arquivo
application.html.erb poderia ser mudado para o seguinte:
Central de Eventos
<%= stylesheet_link_tag "default" %>
<%= yield %>
O método stylesheet_link_tag recebe o nome de uma stylesheet como parâmetro e
gera um link para a mesma. O nosso código gerado agora ficou assim:
Note que mais uma vez o Rails assumiu um caminho padrão. Nesse caso, o arquivo
é servido diretamente da raiz da aplicação, que é o diretório public. Você pode criar
um arquivo chamado default.css no diretório public/stylesheets para adicioná-lo à
aplicação.
Um exemplo disso seria:
body{
background-color:#763A3A;
}
h1{
font-family:Verdana, Arial, Helvetica, sans-serif;
font-variant:small-caps;
font-size:30px;
margin:0px;
color:#572B2B;
}
h2{
font-family:Arial, Helvetica, sans-serif;
font-size:25px;
margin:0px;
}
p{
font-family:Arial, Helvetica, sans-serif;
font-size:12px;
color:#333333;
}
#principal{
width:760px;
height:600px;
border:solid 2px #000000;
background-color:#FFFFFF;
margin:20px auto 0px auto;
padding:15px;
}
Uma coisa a manter em mente é que o layout padrão da aplicação não é, de forma
alguma, o único que pode ser gerado. Você pode criar tantos layouts quanto
precisar, colocando-os no mesmo diretório, de onde estarão acessíveis a toda
aplicação.
Para usar um layout diferente em um controler você poderia fazer algo assim:
class EventosController < ApplicationController
layout "home"
def index
end
end
O layout cujo nome é home seria especificado no arquivo app/views/layouts/
home.html.erb, com a mesma funcionalidade do arquivo application.html.erb.
conceito denominado layouts.
Na maioria das aplicações Web, as páginas variam somente no seu conteúdo
principal, possuindo cabeçalhos, rodapés e barras de navegação em comum.
Obviamente, um framework cujo maior objetivo é aumentar a produtividade do
desenvolvedor não exigiria que o código para esses elementos tivesse que ser
repetido em cada view. Um layout funciona como um arquivo raiz, dentro do qual o
resultado de uma view é inserido automaticamente.
Mais uma vez favorecendo convenção ao invés de configuração, o Rails define um
arquivo padrão de layout que é usado automaticamente por qualquer view a não ser
que haja especificação em contrário. O Rails também é inteligente o bastante para
somente usar um layout em views com a mesma extensão.
O layout padrão para a aplicação fica em um arquivo chamado application.html.erb,
dentro do diretório app/views/layouts.
Se olharmos agora o código gerado pela página que criamos no nosso primeiro
exemplo de Controller e View, teremos o seguinte:
Como você pode notar, não estamos gerando nenhum dos elementos HTML
geralmente vistos em uma página comum.
Vamos criar o arquivo application.html.erb no diretório especificado, com o
seguinte conteúdo:
<%= yield %>
Temos no arquivo acima, o primeiro exemplo de uso de código Ruby dentro de
uma view, delimitado pelos marcadores <% e %>. Aqueles familiarizados com PHP e
ASP reconhecerão o estilo de marcadores, com o uso de <%= objeto %> para
retornar conteúdo.
No caso acima, o método especial yield retorna o conteúdo atual gerado pela ação,
seja por meio de uma view ou usando render diretamente. O método yield tem
uma conotação especial no Ruby, servindo para invocar o bloco associado ao
contexto. Inserido em um layout do Rails, o bloco define a execução da ação, com
seu conseqüente retorno de conteúdo.
A nossa página recarregada agora fica como mostrado abaixo:
Não parece muita coisa, mas, olhando o código, você verá o seguinte:
O que precisamos fazer agora é extender o nosso layout. O nosso arquivo
application.html.erb poderia ser mudado para o seguinte:
<%= stylesheet_link_tag "default" %>
<%= yield %>
O método stylesheet_link_tag recebe o nome de uma stylesheet como parâmetro e
gera um link para a mesma. O nosso código gerado agora ficou assim:
Note que mais uma vez o Rails assumiu um caminho padrão. Nesse caso, o arquivo
é servido diretamente da raiz da aplicação, que é o diretório public. Você pode criar
um arquivo chamado default.css no diretório public/stylesheets para adicioná-lo à
aplicação.
Um exemplo disso seria:
body{
background-color:#763A3A;
}
h1{
font-family:Verdana, Arial, Helvetica, sans-serif;
font-variant:small-caps;
font-size:30px;
margin:0px;
color:#572B2B;
}
h2{
font-family:Arial, Helvetica, sans-serif;
font-size:25px;
margin:0px;
}
p{
font-family:Arial, Helvetica, sans-serif;
font-size:12px;
color:#333333;
}
#principal{
width:760px;
height:600px;
border:solid 2px #000000;
background-color:#FFFFFF;
margin:20px auto 0px auto;
padding:15px;
}
Uma coisa a manter em mente é que o layout padrão da aplicação não é, de forma
alguma, o único que pode ser gerado. Você pode criar tantos layouts quanto
precisar, colocando-os no mesmo diretório, de onde estarão acessíveis a toda
aplicação.
Para usar um layout diferente em um controler você poderia fazer algo assim:
class EventosController < ApplicationController
layout "home"
def index
end
end
O layout cujo nome é home seria especificado no arquivo app/views/layouts/
home.html.erb, com a mesma funcionalidade do arquivo application.html.erb.
A PRIMEIRA VIEW
Vamos criar a nossa primeira view. O rails é automaticamente configurado para
procurar pela view com o mesmo nome da ação. Nossa ação se chama index,
portanto precisamos criar uma view com o mesmo nome “index”. As views são
salvas numa pasta com o mesmo nome do controller, portanto no nosso caso
criamos o arquivo app/views/eventos/index.html.erb
As extensões colocadas em sequencia .html.erb indicam que esse é um arquivo
HTML com código Ruby embutido (Embed RuBy - .erb).
Vamos criar o seguinte arquivo, então:
Agora, recarregando a página, temos:
Sem que haja necessidade de especificar qualquer coisa, o Rails está usando o
arquivo adequado. Veja que não configuramos qualquer coisa. Criamos um controller,
definimos um método no mesmo, e criamos um arquivo que contém o que
queremos que seja retornado por aquele método. A simples existência desses
arquivos representa uma cadeia de execução sem que precisamos nos preocupar
com que parte da aplicação faz isso ou aquilo.
Qualquer outra ação que fosse criada dentro desse controller seguiria o mesmo
padrão. O nome da ação seria associado a um nome de arquivo dentro de um
diretório em app/views cujo nome seria o do próprio controller. O Rails também é
inteligente ao ponto de responder a uma ação mesmo que o método não exista,
desde que a view esteja presente no diretório correto.
procurar pela view com o mesmo nome da ação. Nossa ação se chama index,
portanto precisamos criar uma view com o mesmo nome “index”. As views são
salvas numa pasta com o mesmo nome do controller, portanto no nosso caso
criamos o arquivo app/views/eventos/index.html.erb
As extensões colocadas em sequencia .html.erb indicam que esse é um arquivo
HTML com código Ruby embutido (Embed RuBy - .erb).
Vamos criar o seguinte arquivo, então:
Olá, mundo!
Agora, recarregando a página, temos:
Sem que haja necessidade de especificar qualquer coisa, o Rails está usando o
arquivo adequado. Veja que não configuramos qualquer coisa. Criamos um controller,
definimos um método no mesmo, e criamos um arquivo que contém o que
queremos que seja retornado por aquele método. A simples existência desses
arquivos representa uma cadeia de execução sem que precisamos nos preocupar
com que parte da aplicação faz isso ou aquilo.
Qualquer outra ação que fosse criada dentro desse controller seguiria o mesmo
padrão. O nome da ação seria associado a um nome de arquivo dentro de um
diretório em app/views cujo nome seria o do próprio controller. O Rails também é
inteligente ao ponto de responder a uma ação mesmo que o método não exista,
desde que a view esteja presente no diretório correto.
O Primeiro Controller
Vamos começar criando um controller para lidar com a página inicial de nossa
aplicação. Para gerar um controller, usamos o comando abaixo:
script/generate controller eventos
exists app/controllers/
exists app/helpers/
create app/views/eventos
exists test/functional/
create app/controllers/eventos_controller.rb
create test/functional/eventos_controller_test.rb
create app/helpers/eventos_helper.rb
Utilizaremos muito o comando generate, que gera documentos automaticamente.
O nome passado para o comando é eventos, que será usado para compor todos os
arquivos gerados pelo mesmo.
Se você acessar a URL desse controller agora, você vai receber a seguinte tela:
Repare que, nesse caso, eu informei somente /controller/ como a URL, sem passar
nem a parte correspondente a uma ação ou a um id. Nesse caso, o Rails assume que
estamos invocando a ação index sem id. Esse é um mais exemplo de convenção ao
invés de configuração. Ao invés de ter sempre que especificar uma ação padrão em
algum lugar, o Rails convenciona que a ação padrão é index, poupando o
desenvolvedor sem afetar a aplicação.
Vamos olhar o arquivo app/controllers/eventos_controller.rb gerado por nosso
comando. Como já mencionamos, o Rails segue uma estrutura fixa de diretórios,
poupando mais uma vez o desenvolvedor. Arquivos relacionados ao banco vão em
no diretório db, arquivos de configuração em config e tudo relacionado a MVC vai
em app. Dentro de app temos vários outros diretórios que contém mais partes
específicas da aplicação. Em alguns casos, o Rails também adiciona um sufixo ao
arquivo, evitando colisões de nomes e problemas estranhos na aplicação, como é o
caso aqui. O arquivo do controller criado contém o seguinte:
class EventosController < ApplicationController
end
A classe EventosController define quem que irá responder a requisições padrão
em /home. Ela herda da classe ApplicationController, que está definida no arquivo
application.rb, no mesmo diretório. Sendo assim, qualquer método criado na classe
ApplicationController estará automaticamente disponível nos controllers gerados
para a aplicação.
Para criarmos a ação index, basta adicionarmos um método à classe:
class EventosController < ApplicationController
def index
end
end
O princípio que usamos acima é comum a tudo em Rails. Basicamente tudo o que
fazemos em uma aplicação usando o mesmo consiste em extender alguma classe
por meio da adição de métodos customizados.
Recarregando a página no navegador, ficamos com o seguinte:
Vamos que, dessa vez, o Rails identificou a ação a ser executada, mas, como a
aplicação não especificou nenhum retorno, houve um erro. Isso aconteceu porque o
Rails tentou aplicar automaticamente uma view para aquela ação do controller. Como
a view ainda não existe, temos o erro.
aplicação. Para gerar um controller, usamos o comando abaixo:
script/generate controller eventos
exists app/controllers/
exists app/helpers/
create app/views/eventos
exists test/functional/
create app/controllers/eventos_controller.rb
create test/functional/eventos_controller_test.rb
create app/helpers/eventos_helper.rb
Utilizaremos muito o comando generate, que gera documentos automaticamente.
O nome passado para o comando é eventos, que será usado para compor todos os
arquivos gerados pelo mesmo.
Se você acessar a URL desse controller agora, você vai receber a seguinte tela:
Repare que, nesse caso, eu informei somente /controller/ como a URL, sem passar
nem a parte correspondente a uma ação ou a um id. Nesse caso, o Rails assume que
estamos invocando a ação index sem id. Esse é um mais exemplo de convenção ao
invés de configuração. Ao invés de ter sempre que especificar uma ação padrão em
algum lugar, o Rails convenciona que a ação padrão é index, poupando o
desenvolvedor sem afetar a aplicação.
Vamos olhar o arquivo app/controllers/eventos_controller.rb gerado por nosso
comando. Como já mencionamos, o Rails segue uma estrutura fixa de diretórios,
poupando mais uma vez o desenvolvedor. Arquivos relacionados ao banco vão em
no diretório db, arquivos de configuração em config e tudo relacionado a MVC vai
em app. Dentro de app temos vários outros diretórios que contém mais partes
específicas da aplicação. Em alguns casos, o Rails também adiciona um sufixo ao
arquivo, evitando colisões de nomes e problemas estranhos na aplicação, como é o
caso aqui. O arquivo do controller criado contém o seguinte:
class EventosController < ApplicationController
end
A classe EventosController define quem que irá responder a requisições padrão
em /home. Ela herda da classe ApplicationController, que está definida no arquivo
application.rb, no mesmo diretório. Sendo assim, qualquer método criado na classe
ApplicationController estará automaticamente disponível nos controllers gerados
para a aplicação.
Para criarmos a ação index, basta adicionarmos um método à classe:
class EventosController < ApplicationController
def index
end
end
O princípio que usamos acima é comum a tudo em Rails. Basicamente tudo o que
fazemos em uma aplicação usando o mesmo consiste em extender alguma classe
por meio da adição de métodos customizados.
Recarregando a página no navegador, ficamos com o seguinte:
Vamos que, dessa vez, o Rails identificou a ação a ser executada, mas, como a
aplicação não especificou nenhum retorno, houve um erro. Isso aconteceu porque o
Rails tentou aplicar automaticamente uma view para aquela ação do controller. Como
a view ainda não existe, temos o erro.
MVC – Models, Views e Controllers
O Rails utiliza uma estratégia de desenvolvimento chamada de MVC (Model-View-
Controller). Essa estratégia separa os componentes da aplicação em 3 partes
distintas:
Model
O Model é a parte da aplicação que faz ligação como o banco de dados.
Tecnicamente, o model é implementado pela classe ActiveRecord.
View
O View é a interface com o usuário – um sistema de template que gera
documentos HTML (entre outros) que são enviados para o usuário. As classes
conhecidas como ActionPack, implementam o View e também o Controller.
Controller
Um controller é uma classe responsável por receber as requisições feitas pela
aplicação e executar as ações necessárias para atender essas requisições. É no
controller que definimos a lógica do funcionamento da nossa aplicação.
O controller é quem será efetivamente solicitado pelo navegador. Quando
necessário, o controller utiliza um Model previamente definido para acessar o
banco de dados e, finalmente, encaminha um arquivo de visualização (uma View)
para o usuário.
Apesar de parecer complicado e trabalhoso demais à primeira vista, este modo de
trabalhar traz uma série de vantagens em relação ao modelo tradicional de
desenvolvimento em que uma única página mistura códigos responsáveis pelo seu
funcionamento, pelo acesso ao banco de dados e por exibir dados ao usuário.
Algumas vantagens são:
• A manutenção fica mais fácil por haver uma clara distinção entre as partes da
aplicação
• É possível manter um controle centralizado de todo o site num único (ou em
poucos) arquivo, ao invés de espalhado em dezenas deles.
Controller). Essa estratégia separa os componentes da aplicação em 3 partes
distintas:
Model
O Model é a parte da aplicação que faz ligação como o banco de dados.
Tecnicamente, o model é implementado pela classe ActiveRecord.
View
O View é a interface com o usuário – um sistema de template que gera
documentos HTML (entre outros) que são enviados para o usuário. As classes
conhecidas como ActionPack, implementam o View e também o Controller.
Controller
Um controller é uma classe responsável por receber as requisições feitas pela
aplicação e executar as ações necessárias para atender essas requisições. É no
controller que definimos a lógica do funcionamento da nossa aplicação.
O controller é quem será efetivamente solicitado pelo navegador. Quando
necessário, o controller utiliza um Model previamente definido para acessar o
banco de dados e, finalmente, encaminha um arquivo de visualização (uma View)
para o usuário.
Apesar de parecer complicado e trabalhoso demais à primeira vista, este modo de
trabalhar traz uma série de vantagens em relação ao modelo tradicional de
desenvolvimento em que uma única página mistura códigos responsáveis pelo seu
funcionamento, pelo acesso ao banco de dados e por exibir dados ao usuário.
Algumas vantagens são:
• A manutenção fica mais fácil por haver uma clara distinção entre as partes da
aplicação
• É possível manter um controle centralizado de todo o site num único (ou em
poucos) arquivo, ao invés de espalhado em dezenas deles.
Condigurando o Banco de Dados
Vamos agora configurar o banco de dados da aplicação. Esse primeiro passo é muito
importante porque o Rails usa as informações proveniente do schema do banco de
dados para gerar automaticamente arquivos e configurações adicionais. Esse é mais
um exemplo de convenção ao invés de configuração. Dessa forma, garantir que o
banco está funcionando corretamente, configurado para uso da aplicação, é o passo
inicial de qualquer desenvolvimento em Rails.
O arquivo de configuração de banco de dados se chamada database.yml e está
localizado no diretório config, junto com os demais arquivos de configuração da
aplicação.
Abrindo o arquivo database.yml, repare que uma aplicação Rails geralmente utiliza
três bancos de dados, um para cada ambiente de desenvolvimento padrão. Repare
também que por padrão o arquivo já vem previamente configurado para o banco de
dados SQLite. Na nossa aplicação utilizaremos o banco MySQL, portanto nossa
configuração ficará assim:
Dica de Ruby - Arquivos YAML (*.yml)
Um arquivo do tipo YAML é um arquivo de dados como o XML, por
exemplo, mas com uma sintaxe mais limpa e enxuta. Um documento
YAML é bastante útil para guardar arquivos de configuração.
development:
adapter: mysql
encoding: utf8
database: eventos_development
pool: 5
username: root
password:
host: localhost
test:
adapter: mysql
encoding: utf8
database: eventos_test
pool: 5
username: root
password:
host: localhost
production:
adapter: mysql
encoding: utf8
database: eventos_production
pool: 5
username: root
password:
host: localhost
Um banco de dados é utilizado para o desenvolvimento, onde todas as mudanças
são aplicadas. Esse banco tem seu correspondente em um banco de produção, onde
modificações somente são aplicadas uma vez que estejam completas. O arquivo
permite configurar, inclusive, um banco remoto para onde suas modificações finais
serão redirecionadas—embora geralmente seja melhor utilizar um outro método
de implantação, como veremos mais adiante.
O terceiro banco mostrado acima é um banco de testes, utilizado pelo Rails para a
execução de unit testing. Esse banco deve ser mantido necessariamente à parte já
que todos os dados e tabelas presentes no mesmo são excluídos e recriados a cada
teste completo efetuado na aplicação.
Voltando à nossa aplicação, como um arquivo de configuração importante foi
mudado, o servidor Web precisa ser reiniciado. Isso acontece porque ele somente
lê essas configurações no início de execução. Esse é um dos raros casos em que um
servidor de desenvolvimento precisa ser reiniciado já que o Rails recarrega
praticamente qualquer modificação feita na aplicação quando está no modo de
desenvolvimento.
Agora temos uma aplicação e um banco de dados configurado. Com isso já
podemos iniciar o processo de desenvolvimento propriamente dito.
importante porque o Rails usa as informações proveniente do schema do banco de
dados para gerar automaticamente arquivos e configurações adicionais. Esse é mais
um exemplo de convenção ao invés de configuração. Dessa forma, garantir que o
banco está funcionando corretamente, configurado para uso da aplicação, é o passo
inicial de qualquer desenvolvimento em Rails.
O arquivo de configuração de banco de dados se chamada database.yml e está
localizado no diretório config, junto com os demais arquivos de configuração da
aplicação.
Abrindo o arquivo database.yml, repare que uma aplicação Rails geralmente utiliza
três bancos de dados, um para cada ambiente de desenvolvimento padrão. Repare
também que por padrão o arquivo já vem previamente configurado para o banco de
dados SQLite. Na nossa aplicação utilizaremos o banco MySQL, portanto nossa
configuração ficará assim:
Dica de Ruby - Arquivos YAML (*.yml)
Um arquivo do tipo YAML é um arquivo de dados como o XML, por
exemplo, mas com uma sintaxe mais limpa e enxuta. Um documento
YAML é bastante útil para guardar arquivos de configuração.
development:
adapter: mysql
encoding: utf8
database: eventos_development
pool: 5
username: root
password:
host: localhost
test:
adapter: mysql
encoding: utf8
database: eventos_test
pool: 5
username: root
password:
host: localhost
production:
adapter: mysql
encoding: utf8
database: eventos_production
pool: 5
username: root
password:
host: localhost
Um banco de dados é utilizado para o desenvolvimento, onde todas as mudanças
são aplicadas. Esse banco tem seu correspondente em um banco de produção, onde
modificações somente são aplicadas uma vez que estejam completas. O arquivo
permite configurar, inclusive, um banco remoto para onde suas modificações finais
serão redirecionadas—embora geralmente seja melhor utilizar um outro método
de implantação, como veremos mais adiante.
O terceiro banco mostrado acima é um banco de testes, utilizado pelo Rails para a
execução de unit testing. Esse banco deve ser mantido necessariamente à parte já
que todos os dados e tabelas presentes no mesmo são excluídos e recriados a cada
teste completo efetuado na aplicação.
Voltando à nossa aplicação, como um arquivo de configuração importante foi
mudado, o servidor Web precisa ser reiniciado. Isso acontece porque ele somente
lê essas configurações no início de execução. Esse é um dos raros casos em que um
servidor de desenvolvimento precisa ser reiniciado já que o Rails recarrega
praticamente qualquer modificação feita na aplicação quando está no modo de
desenvolvimento.
Agora temos uma aplicação e um banco de dados configurado. Com isso já
podemos iniciar o processo de desenvolvimento propriamente dito.
Iniciando em Rails
DESENVOLVENDO UMA APLICAÇÃO COMPLETA
Para exemplificar os conceitos abordados neste material, vamos desenvolver uma
aplicação completa de agendamento de eventos. Esta aplicação listará uma série de
eventos como cursos, encontros e seminários com suas respectivas descrições e
datas, e permitirá que se faça a gestão destas informações com o cadastramento,
edição e exclusão de eventos.
A primeira coisa a fazer, então, é criar o diretório de trabalho da aplicação. Isso é
feito digitando o comando abaixo no console (ou no prompt de comando, no
windows):
rails eventos
O comando rails gera o esqueleto completo de uma aplicação, pronta para rodar.
Esse comando foi criado em seu sistema quando você instalou as bibliotecas
necessárias.
Após a digitação você verá o resultado do processo de criação, conforme
demonstrado abaixo:
create
create app/controllers
create app/helpers
create app/models
create app/views/layouts
create config/environments
create components
create db
create doc
create lib
create lib/tasks
No esqueleto gerado, cada parte da aplicação tem um local específico para ser
colocado. Isso deriva de uma das filosofias por trás do Rails que pode ser descrita
pela frase “convenção ao invés de configuração”. Convenção, nesse caso, significa
que há um acordo entre o framework e você, o desenvolvedor, de modo que você
não precisa de preocupar com certos detalhes que, de outra forma, teriam que se
descritos em um arquivo de configuração.
Não vamos entrar em detalhes sobre a estrutura de diretórios agora porque ela
ficará evidente à medida que avançarmos no livro. Não se preocupe: ela é bem
lógica e, na maior parte do tempo, automaticamente gerenciada pelo Rails.
Agora que temos uma aplicação básica, vamos rodá-la e ver o resultado.
Para facilitar a vida, o Rails vem com seu próprio servidor Web, utilizando as
bibliotecas do próprio Ruby. Para rodar o servidor, basta usar um dos scripts
utilitários presentes em cada aplicação gerada pelo Rails (veja o diretório script sob
o esqueleto da aplicação).
Entre no diretório recém-criado e digite:
script/server start
=> Booting Mongrel (use 'script/server webrick' to force
WEBrick)
=> Rails application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at :3000
** Starting Rails with development environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready. TERM => stop. USR2 => restart. INT => stop
** Rails signals registered. HUP => reload (without restart).
** Mongrel available at 0.0.0.0:3000
** Use CTRL-C to stop.
Como você poder ver, o comando inicia uma instância do servidor Mongrel, capaz
de servir aplicações Rails sem necessidade de qualquer configuração adicional. O
servidor roda localmente e recebe requisições na porta 3000.
Lembre-se que em ambiente Windows, você deve digitar
“ruby script/server start”.
Como mostrado acima, temos uma aplicação inicial rodando que, inclusive, mostra
quais são os próximos passos para continuar o desenvolvimento da mesma.
Para exemplificar os conceitos abordados neste material, vamos desenvolver uma
aplicação completa de agendamento de eventos. Esta aplicação listará uma série de
eventos como cursos, encontros e seminários com suas respectivas descrições e
datas, e permitirá que se faça a gestão destas informações com o cadastramento,
edição e exclusão de eventos.
A primeira coisa a fazer, então, é criar o diretório de trabalho da aplicação. Isso é
feito digitando o comando abaixo no console (ou no prompt de comando, no
windows):
rails eventos
O comando rails gera o esqueleto completo de uma aplicação, pronta para rodar.
Esse comando foi criado em seu sistema quando você instalou as bibliotecas
necessárias.
Após a digitação você verá o resultado do processo de criação, conforme
demonstrado abaixo:
create
create app/controllers
create app/helpers
create app/models
create app/views/layouts
create config/environments
create components
create db
create doc
create lib
create lib/tasks
No esqueleto gerado, cada parte da aplicação tem um local específico para ser
colocado. Isso deriva de uma das filosofias por trás do Rails que pode ser descrita
pela frase “convenção ao invés de configuração”. Convenção, nesse caso, significa
que há um acordo entre o framework e você, o desenvolvedor, de modo que você
não precisa de preocupar com certos detalhes que, de outra forma, teriam que se
descritos em um arquivo de configuração.
Não vamos entrar em detalhes sobre a estrutura de diretórios agora porque ela
ficará evidente à medida que avançarmos no livro. Não se preocupe: ela é bem
lógica e, na maior parte do tempo, automaticamente gerenciada pelo Rails.
Agora que temos uma aplicação básica, vamos rodá-la e ver o resultado.
Para facilitar a vida, o Rails vem com seu próprio servidor Web, utilizando as
bibliotecas do próprio Ruby. Para rodar o servidor, basta usar um dos scripts
utilitários presentes em cada aplicação gerada pelo Rails (veja o diretório script sob
o esqueleto da aplicação).
Entre no diretório recém-criado e digite:
script/server start
=> Booting Mongrel (use 'script/server webrick' to force
WEBrick)
=> Rails application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at :3000
** Starting Rails with development environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready. TERM => stop. USR2 => restart. INT => stop
** Rails signals registered. HUP => reload (without restart).
** Mongrel available at 0.0.0.0:3000
** Use CTRL-C to stop.
Como você poder ver, o comando inicia uma instância do servidor Mongrel, capaz
de servir aplicações Rails sem necessidade de qualquer configuração adicional. O
servidor roda localmente e recebe requisições na porta 3000.
Lembre-se que em ambiente Windows, você deve digitar
“ruby script/server start”.
Como mostrado acima, temos uma aplicação inicial rodando que, inclusive, mostra
quais são os próximos passos para continuar o desenvolvimento da mesma.
Instalação em Linux
Em distribuições do Linux como o Ubuntu ou Debian, com facilidades para a
instalação de aplicativos, uma maneira rápida é usar as ferramentas da própria
distribuições para baixar os pacotes e dependências necessárias.
Assim, se você está utilizando o Linux, eu recomendo que você compile a sua
própria versão do Ruby. A versão 1.8.6 é a estável atualmente. Para compilá-la,
utilize o procedimento abaixo:
wget ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.8.6.tar.gz
tar xvfz ruby-1.8.6.tar.gz
cd ruby-1.8.6
./configure --prefix=/usr
make
make install
Para verificar a versão instalada do Ruby, use o seguinte comando:
ruby -v
ruby 1.8.6 (2007-09-24) [i486-linux]
Uma vez que o Ruby esteja instalado, é hora de fazer o mesmo com o Rails. O
procedimento é bem simples: basta executar o comando abaixo1:
gem install rails --include-dependencies
Com os passos acima finalizados, você está pronto para começar o
desenvolvimento em Rails.
instalação de aplicativos, uma maneira rápida é usar as ferramentas da própria
distribuições para baixar os pacotes e dependências necessárias.
Assim, se você está utilizando o Linux, eu recomendo que você compile a sua
própria versão do Ruby. A versão 1.8.6 é a estável atualmente. Para compilá-la,
utilize o procedimento abaixo:
wget ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.8.6.tar.gz
tar xvfz ruby-1.8.6.tar.gz
cd ruby-1.8.6
./configure --prefix=/usr
make
make install
Para verificar a versão instalada do Ruby, use o seguinte comando:
ruby -v
ruby 1.8.6 (2007-09-24) [i486-linux]
Uma vez que o Ruby esteja instalado, é hora de fazer o mesmo com o Rails. O
procedimento é bem simples: basta executar o comando abaixo1:
gem install rails --include-dependencies
Com os passos acima finalizados, você está pronto para começar o
desenvolvimento em Rails.
Instalação em Mac OS
No Mac OS 10.5 em diante, o ruby e o rails já vêm pré-instalados por padrão. O
único problema é que a versão do Rails que já vêm instalada não é a versão mais
recente. Para atualizar o seu sistema siga os seguintes procedimentos:
1-Instale o XCode Tools, presente no CD de instalação do MAC OS, na categoria
“Optional Installs” (arquivoXcodeTools.mpkg)
2-Abra o terminal e digite:
sudo gem update --include-dependencies
3 - Selecione as opções padrões de intalação e alpós alguns instantes seu sistema
estará atualizado.
único problema é que a versão do Rails que já vêm instalada não é a versão mais
recente. Para atualizar o seu sistema siga os seguintes procedimentos:
1-Instale o XCode Tools, presente no CD de instalação do MAC OS, na categoria
“Optional Installs” (arquivoXcodeTools.mpkg)
2-Abra o terminal e digite:
sudo gem update --include-dependencies
3 - Selecione as opções padrões de intalação e alpós alguns instantes seu sistema
estará atualizado.
Instalação em Windows
No Windows existe o Ruby One-Click Installer. Esse instalador pode ser baixado de
http://rubyforge.org/projects/rubyinstaller/ e basta rodá-lo para ter um ambiente
Ruby para Windows (apenas Ruby, sem Rails por enquanto).
Vamos agora utilizar o gerenciador de pacotes GEM para instalar o próprio Rails e
mais algumas outras GEMS que serão necessárias durante o desenvolvimento. Abra
a linha de comando do seu Windows e digite.
gem install sqlite3-ruby
gem install mysql
gem install rails
Pronto, agora você tem um ambiente completo Ruby on Rails em Windows.
Alternativamente, ao invés de realizar manualmente a instalação você pode baixar o
InstantRails, uma aplicação que contém tudo o que é necessário para começar o
desenvolvimento: Ruby, Rails, servidores Apache e Mongrel além do mySQL. O
InstantRails é tão simples que nem é necessário instalá-lo – basta descompactá-lo
na pasta desejada e rodar a aplicação.
O InstantRails pode ser baixado em http://instantrails.rubyforge.org
http://rubyforge.org/projects/rubyinstaller/ e basta rodá-lo para ter um ambiente
Ruby para Windows (apenas Ruby, sem Rails por enquanto).
Vamos agora utilizar o gerenciador de pacotes GEM para instalar o próprio Rails e
mais algumas outras GEMS que serão necessárias durante o desenvolvimento. Abra
a linha de comando do seu Windows e digite.
gem install sqlite3-ruby
gem install mysql
gem install rails
Pronto, agora você tem um ambiente completo Ruby on Rails em Windows.
Alternativamente, ao invés de realizar manualmente a instalação você pode baixar o
InstantRails, uma aplicação que contém tudo o que é necessário para começar o
desenvolvimento: Ruby, Rails, servidores Apache e Mongrel além do mySQL. O
InstantRails é tão simples que nem é necessário instalá-lo – basta descompactá-lo
na pasta desejada e rodar a aplicação.
O InstantRails pode ser baixado em http://instantrails.rubyforge.org
Configuração e instalação
Este material assume que você tenha familiaridade com programação Web em
geral, e com pelo menos um banco de dados relacional. Na elaboração deste
material foi utilizado o MySQL, por ele ser um banco de fácil instalação e por estar
amplamente difundido na web, mas você pode usar o que mais se adaptar ao seu
ambiente, principalmente considerando que o Rails esconde a maior parte da
complexidade nesssa área e que ele suporta os principais bancos de dados
existentes no mercado.
Para começar, vamos assumir que você tenha um banco de dados instalado e que
esteja pronto para instalar a linguagem Ruby e o Rails.
Dica de Ruby - GEM
Nas instalações para Windows, Mac e Linux será utilizado o GEM.
Gem é o gerenciador de pacotes do Ruby, capaz de baixar os
arquivos necessários da Web e instalá-los no local apropriado dentro
das bibliotecas do Ruby sem que o desenvolvedor tenha que se
preocupar com os detalhes do processo
geral, e com pelo menos um banco de dados relacional. Na elaboração deste
material foi utilizado o MySQL, por ele ser um banco de fácil instalação e por estar
amplamente difundido na web, mas você pode usar o que mais se adaptar ao seu
ambiente, principalmente considerando que o Rails esconde a maior parte da
complexidade nesssa área e que ele suporta os principais bancos de dados
existentes no mercado.
Para começar, vamos assumir que você tenha um banco de dados instalado e que
esteja pronto para instalar a linguagem Ruby e o Rails.
Dica de Ruby - GEM
Nas instalações para Windows, Mac e Linux será utilizado o GEM.
Gem é o gerenciador de pacotes do Ruby, capaz de baixar os
arquivos necessários da Web e instalá-los no local apropriado dentro
das bibliotecas do Ruby sem que o desenvolvedor tenha que se
preocupar com os detalhes do processo
A LINGUAGEM RUBY
Ruby é uma linguagem de script interpretada para programação orientada a objetos
com uma filosofia e sintaxe muito limpa que fazem com que programar seja
elegante e divertido.
A linguagem foi criada no início da década de 90 no Japão e rapidamente ganhou
popularidade no mundo inteiro por sua filosofia de ter foco nas pessoas.
Para se tornar um desenvolvedor Ruby on Rails pleno é importante conhecer à
fundo a linguagem Ruby. Existem dezenas de livros, tutoriais e sites que podem lhe
4
ajudar, com grande destaque para o próprio site da linguagem Ruby (http://
www.ruby-lang.org), e o livro virtual “Why's (Poignant) Guide to Ruby” (http://
poignantguide.net/ruby/ - com versão em português em http://github.com/
carlosbrando/poignant-br/).
A quem se destina este livro
com uma filosofia e sintaxe muito limpa que fazem com que programar seja
elegante e divertido.
A linguagem foi criada no início da década de 90 no Japão e rapidamente ganhou
popularidade no mundo inteiro por sua filosofia de ter foco nas pessoas.
Para se tornar um desenvolvedor Ruby on Rails pleno é importante conhecer à
fundo a linguagem Ruby. Existem dezenas de livros, tutoriais e sites que podem lhe
4
ajudar, com grande destaque para o próprio site da linguagem Ruby (http://
www.ruby-lang.org), e o livro virtual “Why's (Poignant) Guide to Ruby” (http://
poignantguide.net/ruby/ - com versão em português em http://github.com/
carlosbrando/poignant-br/).
A quem se destina este livro
O que é Ruby on Rails
Ruby on Rails é uma tecnologia que permite desenvolver sites dinâmicos orientados
a banco de dados e aplicações para a web - de forma semelhante a tantas outras
linguagens de programação como PHP ou ASP.
Porém, apesar de ser mais novo que estas duas linguagens, o Ruby on Rails vêm
crescendo de forma espantosa e têm chamado a atenção de desenvolvedores de
todo o mundo, isso porque ele permite aumentar a velocidade e facilidade no
desenvolvimento de projetos.
Tecnicamente falando, Rails é um framework criado na linguagem de programação
Ruby (daí o nome Ruby on Rails),
Um framework é como um esqueleto em cima do qual se desenvolve uma aplicação
completa. Existem dezenas de frameworks disponíveis e muitos deles existem a
mais tempo que o Rails, então o que faz do Rails algo tão importante? A resposta é
simples: O Rails foi criado com o intuito de permitir o desenvolvimento ágil, com
alta produtividade, escrevendo poucas linhas de código e tendo muito resultado
como consequência. Aplicações que levam semanas ou meses para desenvolver em
linguagens tradicionais podem ser feitas em horas ou dias com Ruby on Rails.
a banco de dados e aplicações para a web - de forma semelhante a tantas outras
linguagens de programação como PHP ou ASP.
Porém, apesar de ser mais novo que estas duas linguagens, o Ruby on Rails vêm
crescendo de forma espantosa e têm chamado a atenção de desenvolvedores de
todo o mundo, isso porque ele permite aumentar a velocidade e facilidade no
desenvolvimento de projetos.
Tecnicamente falando, Rails é um framework criado na linguagem de programação
Ruby (daí o nome Ruby on Rails),
Um framework é como um esqueleto em cima do qual se desenvolve uma aplicação
completa. Existem dezenas de frameworks disponíveis e muitos deles existem a
mais tempo que o Rails, então o que faz do Rails algo tão importante? A resposta é
simples: O Rails foi criado com o intuito de permitir o desenvolvimento ágil, com
alta produtividade, escrevendo poucas linhas de código e tendo muito resultado
como consequência. Aplicações que levam semanas ou meses para desenvolver em
linguagens tradicionais podem ser feitas em horas ou dias com Ruby on Rails.
Ruby On Rails
Olá!
Outro dia eu estava navegando na Web procurando mais textos sobre acessibilidade e Ajax, e acabei indo parar no site do Ronaldo Ferraz. Ali encontrei um tutorial sobre Ruby on Rails. Como já havia ouvido falar sobre esse framework no site da Collaboraid, acabei dando uma fuçada e acho que já posso me considerar fã de Ruby e um possível usuário o Rails.
Ruby on Rails é um framework para desenvolvimento de aplicações baseado na Web que usa a linguagem de programação orientada a objetos Ruby. O Rails vem sendo desenvolvido pela comunidade há mais de dois anos com várias aplicações comerciais.
Fiz alguns testes portando alguns módulos de um sistema que estou desenvolvendo em PHP e pude constatar que a velocidade de desenvolvimento com o Rails é consideravelmente maior que com PHP. Para se ter uma ideia, eu gastei 15 minutos para fazer um módulo que eu havia gasto quase um dia para fazer em PHP. Obviamente o módulo que portei estava em PHP puro(já peguei o projeto no meio, e ainda não pude mudar a metodologia), sem nenhum framework, pois com o Seagull eu já havia experimentado algo parecido em termos de velocidade.
A despeito das diferenças das linguagens(PHP e Ruby), uma coisa que me deixou bastante impressionado com o Rails é a forma como ele implementa o MVC, e como o sistema de template dele é simples tanto para o desenvolvedor quanto para um possível designer.
Ainda quero gastar mais tempo estudando, mas quis comentar o quanto achei interessante o framework.
Abraços!
Outro dia eu estava navegando na Web procurando mais textos sobre acessibilidade e Ajax, e acabei indo parar no site do Ronaldo Ferraz. Ali encontrei um tutorial sobre Ruby on Rails. Como já havia ouvido falar sobre esse framework no site da Collaboraid, acabei dando uma fuçada e acho que já posso me considerar fã de Ruby e um possível usuário o Rails.
Ruby on Rails é um framework para desenvolvimento de aplicações baseado na Web que usa a linguagem de programação orientada a objetos Ruby. O Rails vem sendo desenvolvido pela comunidade há mais de dois anos com várias aplicações comerciais.
Fiz alguns testes portando alguns módulos de um sistema que estou desenvolvendo em PHP e pude constatar que a velocidade de desenvolvimento com o Rails é consideravelmente maior que com PHP. Para se ter uma ideia, eu gastei 15 minutos para fazer um módulo que eu havia gasto quase um dia para fazer em PHP. Obviamente o módulo que portei estava em PHP puro(já peguei o projeto no meio, e ainda não pude mudar a metodologia), sem nenhum framework, pois com o Seagull eu já havia experimentado algo parecido em termos de velocidade.
A despeito das diferenças das linguagens(PHP e Ruby), uma coisa que me deixou bastante impressionado com o Rails é a forma como ele implementa o MVC, e como o sistema de template dele é simples tanto para o desenvolvedor quanto para um possível designer.
Ainda quero gastar mais tempo estudando, mas quis comentar o quanto achei interessante o framework.
Abraços!
Try Ruby – Aprenda Ruby sem precisar de qualquer programa
O Try Ruby é uma interface web que possibilita que os novos desenvolvedores de Ruby on Rails possam criar e testar suas aplicações sem precisar de nenhuma infra-estrutura ou programa instalado em sua máquina. Para quem não conhece, o Ruby é uma linguagem para o desenvolvimento rápido de aplicações para web. Grandes sites como Twitter o usam em seus sistemas.
LOGO MAIS O CURSO RUBY
Up Source
Boa tarde, minha galera esse site está sendo criado para postar noticias sobre tecnologia, cursos e muito mais para vocês. Todo o dia estará sendo postados vídeos para vocês aqui no Blogger Up Source - Por que tecnologia e conhecimento e só no bogger - Up Source -
Assinar:
Postagens (Atom)
