blog.2solutions.com.br

Abaixo estou listando um passo-a-passo para a implementação de requisitos de um sistema, utilizando a arquitetura Java da 2Solutions.

Em primeiro lugar, os frameworks que adotamos para o desenvolvimento são :

Struts2 : View e Controller
JPA (Hibernate) : Persistência
Spring : IoC e DI

Os frameworks se relacionam, facilitando o nosso trabalho assim, os trabalhos iniciam assim:

Resumo de Levantamento de requerimentos

A primeira coisa a fazer no desenvolvimento de software é o levantamento/descobrimente de requerimentos. Essas informações são bem armazenadas na forma de diagramas de caso de uso.

A ideia dos casos de uso é ser o mais simples possivel, apenas documentando as funcionalidades, deixando de descreve-las a fundo. O caso de uso deve ser documentado com um usuario e quais funcionalidades do sistema ele ira interagir, por exemplo :

Ator : Gerente de contas
Caso de Uso : Cadastrar novo cliente

Se o caso de uso ‘cadastrar novo cliente’ for um pouco complexo, repare bem, SE for complexo, dai sua lógica deve ser armazenada em um diagrama de atividades. Ou podemos utilizar cenários para armazenar as situações.

Junto a isso pode ser feito protótipos para ser apresentado ao cliente e este levantar mais informações pertinentes. Nesta fase não temos codigo compilado, apenas telas e informações sobre a funcionalidade. Podemos agilizar isso com reunioes, ou com viagens ao codigo e planos de teste.

Modelagem

A medida que as funcionalidades vão sendo descobertas o próximo passo é ir descrevendo as entidades encontradas. Essa descrição pode ser feita direto no banco de dados, ou pode ser feita associando classes.

Na 2Solutions nós fazemos as classes e anotamos seu nome e seus atributos para que as tabelas sejam geradas.

Por tanto o primeiro passo é fazer a modelagem das classes.

Uma forma de verificar se o modelo esta bem feito é criando testes unitários. Teste unitário é apenas garantir que aquela funcionalidade especifica da sua entidade como ‘inserir no banco’ esta funcionando. O ideal é criar para cada entidade testes unitarios de insert, select, update e delete.

Action/Jsp

Depois que suas classes estiverem corretamente modeladas e testadas, dai partimos para as interfaces. Por padrão toda entidade criada pode ser manipulada utilizando interfaces genéricas. Para que isso funcione voce precisa.

1 - Criar o arquivo EntidadeAction no pacote actions, seguindo o modelo de uma action padrão :

public class ClienteAction extends GenericAction {
public ClienteAction(GenericService service){
super(service);
}
}

2 - Com a entidade criada, o próximo passo é fazer as associações no Spring. O Spring é o responsável por cuidar da parte de instanciar objetos e seta-los nas entidades. Com o Spring temos benefícios imediatos como a IoC (Inversion Of Control) e a DI (Dependency Injection)

<!--
Entitys
-->
<bean id="clienteEntity" class="br.gov.sp.sucen.controledengue.entity.Cliente" scope="session"/>

<!--
Services
-->
<bean id="clienteService" class="br.gov.sp.sucen.controledengue.service.GenericServiceImpl">
<constructor-arg>
<value>br.gov.sp.sucen.controledengue.entity.Cliente </constructor-arg>
</bean>

<!--
Actions
-->
<bean id="clienteAction" scope="prototype" class="br.gov.sp.sucen.controledengue.action.ClienteAction">
<constructor-arg ref="clienteService" />
<property name="entity" ref="clienteEntity" />
</bean>

3 - Com tudo configurado a sua entidade ja esta com as operações basicas de manipulação prontas.

http://localhost:8080/MeuProjeto/cliente!novo.action
http://localhost:8080/MeuProjeto/cliente!pesquisar.action
http://localhost:8080/MeuProjeto/cliente!salvar.action
http://localhost:8080/MeuProjeto/cliente!remover.action
http://localhost:8080/MeuProjeto/cliente!editar.action
http://localhost:8080/MeuProjeto/cliente!visualizar.action

Personalizando

Procure sempre criar interfaces baseadas nas entidades. Com recursos como AJAX, nós podemos ter uma tela desempenhando varias funções no mesmo ambiente. Por exemplo, se na interface de cadastro de cliente você precisar mostrar uma lista com os vendedores, para selecionar qual o vendedor desse cliente, o processe ficaria assim.

Combo (<select>)

<%
ObjectFactory factory = StrutsSpringObjectFactory.getObjectFactory();
GenericService service = (GenericService)factory.buildBean("vendedorService",null);
pageContext.setAttribute("propertyListName",service.buscarTodos());
%>
<s:select name="entity.vendedor.id" label="Selecione Vendedor" list="%{#attr.propertyListName}" listKey="id" headerKey="" headerValue=""/>

Eu particularmente não gosto muito de Scriptlets no JSP, porém não gosto de ter que ficar criando uma colecao de retorno em toda Action

Radiobuttons (Sim/Nao)

<s:radio label="Ativo" list="#{'true':'Sim','false':'Nao'}" name="entity.ativo"/>

Checkbox (Lista de Elementos)

<%
GenericService service = (GenericService)factory.buildBean("vendedorService",null);
List all = service.buscarTodos();
pageContext.setAttribute("propertyListName",all);
%>
<s:checkboxlist name="entity.vendedores" label="Selecione vendedores" list="%{#attr.propertyListName}"/>

Durante o treinamento, utilizamos uma liguagem nova (Ruby) e um framework (Rails) revolucionário. Não há duvidas da produtividade de Rails, e mesmo que consigamos atingir algo semelhante com outras lingguagens/plataformas, o mais importante são os conceitos aprendidos. Para esse ultimo dia, veremos dois assuntos.

JRuby

Para quem ja brincou com recursos avançados de Java, sabe os SDKs mais atuais têm suporte a scripting, ou seja, é possível definir trechos de codigo em outra linguagem e o Java consegue interpreta-los. Esse é um grande avanço para a plataforma Java pois ela agora não fica mais depedente diretamente da linguagem Java, abrindo seus mercado para qualquer linguagem que implemente scripting.

Com o JRuby temos uma outra vantagem que é nosso codigo Ruby (rodando com Rails inclusive) acessar recursos Java (todo o nosso legado de bibliotecas Java que não queremos reescrever). Segue abaixo alguns caminhos para quem quer se aprofundar no assunto.

Pagina Oficial
http://jruby.codehaus.org/

Download
http://dist.codehaus.org/jruby/jruby-bin-1.1.4.zip

Iniciar (conhecendo bem ruby não tem segredo)
http://wiki.jruby.org/wiki/Getting_Started

Deploy no Tomcat(*)
http://wiki.jruby.org/wiki/Jruby_on_Rails_on_Tomcat

* Ao baixar a nova versao do Rails (2.1.1) é preciso comentar a versao do Rails do seu projeto (2.1.0), localizado em
SEU_PROJETO\config\environment.rb (comentar a linha

IDE

Durante o treinamento trabalhamos apenas com editores de texto e o console (prompt). Esse modelo funciona, porém o auxílio de uma ferramenta pode trazer vantagens, como agilidade no acesso a códigos, acompanhar o log, assistencia de codigo, facilidade na exução de scripts e etc.

Aptana - RadRails

Uma IDE bem interessante para trabalhar com Rails é o RadRails (Aptana). Desenvolvida sobre plataforma Eclipse, é possível instalá-la como se fosse um plugin. Para trabalhar com Rails apenas alguns ajustes são necessários.

Comece fazendo o download em http://www.aptana.com/studio/download/

Apos a instalação baixar o plugin do Rails. Isso pode ser feito clicando na pagina inicial da IDE.

Feito a instalação agora podemos começar com a criação de um novo projeto Rails.

Clicando em File >> New >> Other >> Project

Selecionado um projeto Rails

Após ter configurado seu projeto, a interface principal é atualizada com o diretorio do seu projeto criado ja com a estrutura dos diretorios. Na aba de log aparece todos os diretorios/arquivos criados.

Na aba console, é possível executar os comandos que seriam executados no prompt, apesar de existir uma forma mais user-friendly de executar essas operações.

No exemplo de execução de script, foi executado o script de scaffolding em uma entidade Company. O resultado dos arquivos (não precisa dar refresh) esta abaixo.

Com os arquivos criados, podemo agora editar os códigos. Começando pelas classes, o editor coloca em destaque as palavras reservadas, faz alinhamento automatico (identação) e também tem suporte ao Ctrl+’espaço’ para apresentar métodos que você tem acesso. Recurso bem interessante visto que as classes Ruby tem um numero maior de métodos (interface humana).

Também temos esses recursos na edição de paginas view (html).

Arquivos atualizados, é hora de colocarmos o servidor para funcionar. Na aba Servers execute o servidor

O servidor é iniciado na porta 3002, podendo ser acesso com http://localhost:3002

A perspectiva ideial para trabalhar com projeto Rails é a ‘RadRails’. Para acessá-la va em Window >> Open Perspective >> Other

Nesta nova perspectiva os comandos via script que voce executaria no console, agora voce pode executar pelas abas, inclindo comandos rake.

Executando instruções direto no console

Executando os scripts de geração de código (generator)

Outra funcionalidade util é o gerenciamento de gems que pode ser feito direto na ferramenta.

Para adicionar uma gem basta clicar no ícone “+” e uma interface para atualização de gems vai aparecer, com um espaço para indicar qual o endereço do src do gem.

As funcionalidades acima servem para você começar a desenvolver com o RadRails, porém ele possui outras funcionalidades interessantes como a parte de integração com banco de dados e a edição dos arquivos de propriedade. Vale a pena dar uma conferida.

Até a próxima

No quarto dia de treinamento o assunto que iremos abordar são as interfaces (ActionView).

Assim como todo framework para interfaces web, o principal é minimizar a utilização de lógicas de controle (if/else) na construção de formulários. Essa diminuição aparece principalmente quando utilizamos os formulários.

Um formulario contem informações que irão ser enviadas, porém que podem ser carregadas. Dai a praticidade de se criar um formulario que ja esteja preparado para trabalhar com dados integradas a outras camadas.

No Ruby On Rails a estratégia não é nunhuma novidade.

Temos diversas instruções para representar um campo associado a um atributo de um registro. Por exemplo :

<% form_for(@fabricante) do |f| %>
<%= f.error_messages %>
<p>
<%= f.label :descricao %><br />
<%= f.text_field :descricao %>
</p>
<p>
<%= f.submit "Update" %>
</p>
<% end %>

<%= link_to 'Show', @fabricante %> |
<%= link_to 'Back', fabricantes_path %>

No exemplo acima (gerado pelo scaffold) temos um formulario, seus campos e um botão de submissão. Todo são construidos utilizando instruções do framework, dessa forma não precisamos nos preocupar se estamos preenchendo um formulario, validando se houve erro para retornar os campos preenchidos, etc. O mais importante é que o objeto que vai ter os seus atributos mapeados para os campos do formulario deve ser declarado como um atributo (@) no controller. No nosso exemplo deve existir um atributo @fabricante.

Discutimos muito sobre a utilização de campos <select>, por exemplo. Estes campos são mais complexos pois é necessário uma segunda consulta para mostrar os dados no combo, algo como :

<p><label for="carro_fabricante">Carro</label><br/>
<%= collection_select(:carro, :fabricante_id, Fabricante.find(:all), :descricao, {:prompt => true}) %>

JavascriptGeneratorTemplate

Para que voce possivel utilizar o mínimo de javascript para interações Javascript, foi desenvolvido uma forma de estruturar os arquivos em que a unica linguagem envolvida é o Ruby.

Um exemplo clássico é a pagina de listagem, aonde ao clicar em inserir um novo registro, este aparece na listagem sem que haja refresh na tela. Na prática é incluir uma nova linha na tabela através de operações DOM.

Para quem ja trabalhou com manipulação de objetos DOM em algum elemento HTML (tabela por exemplo) sabe que é preciso um pouco de conhecimento (e código) para que fique do jeito que esperamos. Ja com Rails, o templa RJS faz isso de forma que ele é o arquivo que encapsula a lógica de atualização da interface.

O processo fica assim

Arquivo principal : É a pagina contendo a tabela renderizada.
Arquivo include de linha: O trecho que representa cada linha da tabela é um arquivo de inclusão, que sera utilizado pela pagina principal e pelo script RJS
Arquivo script RJS: O método da controller, ao retornar uma pagina, retorna esse arquivo. Por ser uma chamada assincrona, o resultado do processamento desse arquivo é um codigo Javascript gerado pelo RJS.

Na aula anterior finalizamos a aplicação CRUD. Tomou um certo tempo devido a alguns ajustes de configuração e também porque a cada camada alguns conceitos iam sendo discutidos. Hoje o objetivo foi o estudo aprofundado de ActionRecord e ActionController.

ActionRecord

Existem algumas estratégias para fazer o mapeamento objeto-tabela (ORM), no caso do ActiveRecord uma funcionalidade que o difere de outras implementações (como DAO por exemplo) é o fato de a própria entidade possuir métodos de interação com o banco. Isso faz com que se diminua o numero de classes e se reaproveite os atributos do objeto.

Mas isso é so uma parte. Como a estrutura da linguagem Ruby é tão flexível, é possível ter definições de método de consulta no próprio objeto como por exemplo :

User.find_by_username("login")

Inclusive, dizer que o Rails é um framework ORM eu considero meio equivocado, na verdade o Rails não mapeia as colunas para os atributos, ele adiciona nos objetos as colunas. Toda vez que se pede algo para uma classe, o Rails faz um metadados na tabela associada a insere esses atributos dinamicamente no objeto. Assim, se alguem inserir uma nova coluna na tabela, ela automaticamente sera carregada nos objetos.

Isso remete a um outro assunto discutido em sala, Migration.

Migration

Atualizações em tabelas de banco são muitas. Por mais que se faça um trabalho legal de modelagem, invariávelmente temos que criar colunas, refatorar nomes, ajustas associações e por ai vai. Manter essa documentação de atualizações organizada de forma coerente e prática pode demandar uma intereção custoza na equipe de desenvolvimento/banco. Nisso entra o Migration. Com um padrão de nomenclaturas de arquivo e uma facilidade de comandos, é possível versionar os estados das estruturas e trocar facilmente de uma versão para outra. Bem interessante.

Mas isso não tem a ver só com Rails. Isso tem a ver com a organização da manutenção dos dados da empresa. O legal é que como a linguagem utilizada é Ruby e o framework é o Rails, fica muito mais prático, porém poderia ser utilizado para qualquer equipe em qualquer linguagem/plataforma.

Operações Bulk

Operaçoes em massa são aquelas que alteram varios registros ao mesmo tempo, por exemplo :

update users set ativo = 1

Acessível pelos métodos

User.update_all("ativo = 1")
User.destroy_all("ativo = 1")

Eventos - Callbacks

Métodos de callbacks são aqueles invocados quando ocorre determinada situação. No rails eles aparecem nos eventos de interação com o banco. São bem simples de criar e utilizar.

Exemplos :

class User < ActiveRecord::Base
before_destroy :manda_email

def manda_email
#Manda email para alguém
end
end


Outros recursos

Para validações ja tem um monte de funções prontas para serem utilizadas, é possível especializar algumas e criar as suas. Muito útil e fácil.

validates_inclusion_of :age , :in => 15..99

Para os acumuladores (count, sum, minimum, etc) também é bem prático e útil.

User.count(:condition => "age > 18")

Um assunto que discutimos muito (e eu sempre me emociono) é da parte de transações. Como eles conseguiram deixar tão simples.

User.transaction do
a1.deposit(100)
a2.withdraw(100)
end

Se der exceção é feito rollback senão commit. E a funcionalidade não para ai, se você quiser que os objetos retornem ao estado anterior do bloco de transação é so :

User.transaction(a1,a2) do
a1.deposit(100)
a2.withdraw(100)
end

Mais um recurso, facil de implementar, porém muito inteligente são as colunas timestamps, que se seguirem a convenção de nomes funcionam assim :

created_on grava a data/hora ao inserir um novo registro
created_at grava a data ao inserir um novo registro
updated_on grava a data/hora ao atualizar o registro
updated_at grava a data ao atualizar o registro

E por ultimo, um recurso que muita gente nem conhece, Lock otimista (Optimistic Lock). Funciona assim, quando consultamos um registro no banco e abrimos seus dados para edição o registro não fica “lockado” para nosso acesso, ele fica disponível para outros fazerem a mesma operação no mesmo registro. Isso ocorre porque em aplicações com muitos usuarios, se houvesse esse lock todos os outros usuarios ficariam esperando o primeiro finalizar, seria a estratégia pessimista, pois ja pensa que se não segurar o registro outro vai na frente e salva antes. Isso pode acontecer, lógico, mas a estratégia implementada é criar uma coluna de versão.
Quando eu consulto um registro, fica a informação da versão que estou editando, se alguem salvar na minha frente vai atualizar a versão, e quando eu for salvar o ambiente de avisa “Olha, alguem ja salvou antes”.
Implementar isso leva um certo tempo de desenvolvimento, porém em rails é so voce criar uma coluna com o nome lock_version.

Da parte do ActionRecord foi isso vamos ao ActionController

ActionController

Para quem esta acostumado com frameworks web, esse é o controlador de fluxo. Vantagens do framework Rails é a facilidade de criação (não tem XMLs nem anotações, somente convenções) e inclusão de actions (métodos que recebem requisições).

Todo método criado na classe Controller pode receber requisição, e o legal é que existe um diretorio específico para cada pagina de cada controlador. É mais ou menos o que acontece na realidade, um controlador acaba “gerenciando” um grupo de paginas específicas do seu contexto.

O interessante é que acessar a pagina de outro controlador, mudar de pagina para retorno em conteudo texto ou verificar se é uma requisição ajax é facil. É abstraido muitos conceitos da parte de troca de mensagens HTTP.

Exemplos:

Para retornar texto

def teste_texto
s = "Esse é o texto que sera retornado"
render :text => s
end

Para retornar uma pagina do mesmo controller

def teste_uma_pagina
#Faz algumas operacoes
render :action => 'uma_pagina'
end

Para retornar uma pagina com mesmo nome do método

def uma_pagina
#Faz algumas operacoes
end

Para retornar uma página de um outro Controller (adivinham ?)

def teste_mais_complexo
#Faz algumas operacoes
render :controller => 'loja_virtual' , :action => 'outra_pagina'
end

Também existem recursos de verificação, como so deixar executar os métodos que forem por post.

verify :method => :post, nly => [ :destroy , :create , :update],
:redirect_to => { :action => :list }

Para configurar os layouts utilizados por esse controler, é so adicionar no inicio do corpo da classe :

layout :loja_virtual_usuario

Para configurar filtros de requisição :

before_filter :valida_usuario
def valida_usuario
#faz a validacao
end


Existem outros recursos como flash[:notice] para o envio de mensagens com tempo de vida da requisiçao, outra funcionalidade é o render para montar as paginas de resposta, tem tambem o rescue para lançar excessão e depois trata-la.

Tanto o assunto de ActionRecord quanto de ActionController foram muito bem trabalhados no livro. Vale a pena dar uma conferida.

Amanhã tem mais.

Uma palavra que resume bem o dia 2 é a seguinte “atualização”. Eu não estava trabalhando com Ruby +2.0 e infelizmente, o livro também segue a versão mais antiga. O problema é que houveram algumas atualizações que tomaram um pouco do tempo do treinamento, no entanto, não impactaram no resultado final. Finalizar o aplicativo CRUD.

Bem, vamos detalhar algumas dificuldades encontradas. O inicio do desenvolvimento foi focado na modelagem das entidades (Model). Hoje adicionamos métodos de negocio, como um metodo para criptografar senha. Tudo ia muto bem até a hora de gerar os controllers e views.

O comando utilizado para isso é o scaffolding

ruby script/generate scaffolding Car

A listagem resultado do comando mostra que tudo foi gerado, no entanto o conteudo das paginas de listagem (index), edicao, novo e visualização não estão com os campos da entidade. Assim tivemos que fazer tudo na mão. Pelo menos serviu para o pessoal dar uma praticada e ir entendendo uma parte da sintaxe dos controllers e views.

Se você não implementou a entidade model, a sintaxe do scaffolding deve ser

ruby script/generate scaffold Car model:string year:integer preco:float data_compra:datetime

Interessante que agora não é mais gerado as telas com um for pesquisando as colunas e sim, é adicionado os campos diretamente. Isso ajuda pois na realidade ao ajustar as telas o mais comum é retirarmos colunas.

Com o scaffolding executado, a estrutura principal das nossas entidades esta pronto. O que nos resta fazer é irmos as especializando e adicionando outras com funcionalidades não ligadas a uma entidade específica.

Para simularmos essa situação implementamos um requisito de autenticação. Dificilmente você ira participar do desenvolvimento de uma aplicação que não utilize recursos de autenticação (e a maioria ainda precisa de autorização também), e para o treinamento essa funcionalidade tem alguns objetivos didáticos :

1) A interface de login não esta associada a nenhuma entidade e portanto deve ser criada a parte
2) O controlador precisa de método fora do padrão CRUD, como login e logout
3) Na logica de autenticação é preciso criar um metodo que saiba o que fazer com o login/senha, e assim trabalhamos com esses métodos de negócio nas entidades (User). Esse método além de realizar manipulação de banco de dados, tambem trabalha um pouco com a sintaxe da linguagem.
4) No controlador (LoginController) manipulamos dados da sessão
5) No controlador manipulamos dados no flash[:notice], especifico para armazenar dados durante uma requisição
6) O redirecionamento das paginas (login com sucesso ou nao)

E tivemos tempo de trabalhar um pouco com filtros. É um assunto com uma leve carga conceitual, porém com uma implementação muito simples.

Resumindo nossos trabalhos, podemos destacar uma revisão em conceitos de OO, pratica na linguagem Ruby, os geradores de codigo script/generate e algumas funcionalidades interessantes como sessao, flash e filtros.

Um outro recurso interessante é para quem não gosta de geradores de código (eu). Ao invés de deixar os controladores gerados pelo scaffolding com todas as assinaturas de métodos, adicione a linha no corpo da sua classe :

scaffold :car

Assim seu controller “ganha” as funcionalidades CRUD padrão, e o numero de linhas de código cai mais ainda.

Observação : Em alguns projetos Java que eu trabalho nós criamos Actions (strus2) genéricas com Jsp genéricos também, assim, para situações em que o CRUD nao precisa de nenhuma especialização não é preciso codificar as telas.

Nos próximos dias vamos aprofundar o assunto em cada tópico.

Até amanhã

Para servir de repositorio de dados do conteudo passado no treinamento Ruby On Rails em Sao Luiz - MA eu resolvi criar um post especifico de cada dia de treinamento. O treinamento é baseado no livro do Fabio Akita, que além de ter uma ordem cronológica didática, também tem exemplos práticos. Cada aluno tem seu exemplar do livro para acopanhamento. Vou aproveitar para detalhar o que levantamentos de util nas aulas pois pode ser útil para mais alguém.

No inicio do treinamento ja discutimos sobre a necessidade de alguns conceitos fundamentais para um melhor aproveitamento do treinamento.

Em primeiro lugar, para mergulhar de cabeça em Ruby On Rails, você TEM que ter alguns pré-requisitos :

1) conceitos de modelagem de dados : Não precisa ser expert em nenhum banco, no entanto, saber criar tabelas e relacionamentos é fundamental.
2) conceito de orientação a objetos : Muitos recursos do Ruby e do Rails exigem que o desenvolvedor entenda bem de classes e objetos. Se você enxerga classes apenas como o mal necessário para criar objetos, acho melhor voce dar uma estuda nestes conceitos. De uma revisada em polimorfismo, herança e encapsulamento (pilares da OO).
3) Familiaridade com ambiente web : O foco do treinamento é em um framework web, e por tanto, você deve ter noção de como funciona aplicações web. Servidor web, provendo paginas estáticas ou dinâmicas, processando requisições de clientes, request, response, sessão e conceitos de segurança ajudam.
Atende os requisitos ? Então vamos la.

Ambiente

Ruby é uma linguagem interpretada, e por tanto você precisa do interpretador. Acessa o site http://www.ruby-lang.org e baixa o binario para o seu sistema operacional. Vai vir muito mais coisa que o interpretador, com destaque para o “ri” (consultar a documentação das classes) e “rdoc” para gerar documentação

Se for tudo no Next >> Next >> Finish sera criado um diretorio Ruby e o sub-diretorio Bin ja vai estar configurado no path.

Abra o console (prompt) e execute “ruby” de qualquer diretorio. Assim ja validamos se a instalação foi executada com sucesso.

Bem, o Ruby é muito legal e eu recomendo uma leitura mais avançada na linguagem, no entanto, para nosso treinamento as coisas vão sendo passadas sob demanda. Por tanto vamos ao Rails.


gem update --system
gem install rails --include-dependencies


A instalação de pacotes adicionais é feita utilizando esse gerenciador “gem”

Começando meu projeto

Depois de instalado é hora de criarmos o nosso projeto:

rails meuprojeto

Todos os diretorios do projeto são criados e cada um tem a sua função específica.

Vamos iniciar configurando o acesso ao banco de dados.

Seguimos o wiki do Rails para configurar o acesso ao SQL Server

http://wiki.rubyonrails.org/rails/pages/HowtoConnectToMicrosoftSQLServer

Essa atividade foi mais demorada, pois tivemos que pesquisar esse driver e seguir o tutorial. Fizemos o teste ja executando um comando do rake para fazer a carga no banco com as nossas tabelas.

rake db:schema:load

começamos a construção das nossas entidades (model)


ruby script/generate model User
ruby script/generate model Task


e interagimos com o banco de dados através do ambiente de execução do Rails

ruby script/console

Exemplos


u = User.new
u.username = "teste"
u.full_name = "Teste de usuario"
u.hashed_password = "12313"
u.save


Com a parte de integração com o SQL Server funcionando, fechamos a parte de preparação do ambiente. Uma duvida que surgiu foi referente a documentação.

Para visualizar a documentação de uma classe podemos utilizar o ri.

Exemplo :

ri String

ou, especificando o método

ri String#upcase

Mas quando existe mais de um metodo com essa assinatura significa que o Ri esta encontrando essa classe#metodo em mais de uma fonte de documentacao.
Nesses casos você precisa especificar qual documentação deve ser pesquisada.

Exemplo :

ri --system String#upcase

As opções disponíveis são :

By default ri searches for documentation in the following
directories:

c:/ruby/share/ri/1.8/system
c:/ruby/share/ri/1.8/site
C:\Users\hfurlan/.rdoc
c:/ruby/lib/ruby/gems/1.8/doc/*/ri

Specifying the –system, –site, –home, –gems or –doc-dir
options will limit ri to searching only the specified
directories.

Do primeiro dia foi (resumidamente) isso.

Amanhã tem mais.