Blog do Urubatan
msgbartop
Desenvolvedor, Palestrante, Escritor, Nerd Assumido e Pai do Marcus :D
msgbarbottom

22 Jan 10 As 8 Falácias da programação distribuida


Encontrei esta lista no blog do James Gosling.

Essencialmente todos, ao desenvolver a primeira aplicação distribuída, assumem os 8 itens seguintes como verdade. Todos se provam falsos ao longo do tempo, e estes erros causam problemas graves e aprendizados dolorosos.

  1. A rede é confiável
  2. A latência é zero
  3. A banda é infinita
  4. A rede é segura
  5. A topologia não muda
  6. Existe um administrador de rede
  7. O custo de transporte é zero
  8. A rede é homogênea

Para mais detalhes, leiam o artigo escrito por Arnon Rotem-Gal-Oz.

James Gosling em um link fala o seguinte sobre a origem desta lista:

A verdadeira origem desta lista é um pouco mítica, sendo amplamente baseada na experiência coletiva de muitos hackers nos primórdios da construção de sistemas distribuídos. Peter Deutch foi o primeiro agrupar os itens em uma lista. Ele diz o seguinte em sua página:

Eu publiquei as “8 falácias da programação em rede” internamente enquanto trabalhava para “Sun Microsystem Labs” em 1991-92. (As primeiras 4 foram originalmente listadas por Bill ou Dick Lyon; Eu adicionei as outras 4.)

Achei que vali a tradução já que muita gente comete os mesmos erros até hoje :D

Tags: , , ,

11 Jan 10 Ruby on Rails 101 – Encurtador de URLs = Novo Blog

Ok, o titulo do post não ficou legal, mas a idéia é que tem tanto encurtador de URLs por ai que eu resolvi fazer um em rails também para brincar um pouco, e como a implementação ficou muito simples, vou tentar transformar isto em um tutorial bem básico de Rails.
Mas vejam bem, a idéia é só mostrar o básico, não vou colocar mais um no ar, já tem um excelente feito pelo nosso amigo Manoel Lemos, o zapt.in onde ele esta adicionando recursos muito legais. Só peguei a idéia por que achei que se tornaria um tutorial mais divertido do que o famoso blog em rails :D

Primeiro, você vai precisar do Rails[bb] instalado, e para ter o Rails instalado você vai precisar do interpretador Ruby instalado, tem diversos posts sobre isto por ai, mas basicamente numa maquina windows, sugiro instalar o “Instant Rails”, num linux instale o Ruby e depois o Ruby Gems e logo depois execute o comando “gem install rails”.

Deste ponto em diante vou considerar que você já tem o rails instalado e funcionando.

Agora com o Rails instalado, vamos começar a desenvolver a aplicação, vou chamar de “us” para “URL Shortener”, como qualquer projeto rails, vamos começar digitando:

1
2
rails us
cd us

Uma aplicação rails tem inicialmente a seguinte estrutura de diretórios:

  • app
    • controllers
    • helpers
    • models
    • views
      • layouts
  • config
    • environments
    • initializers
    • locales
  • db
  • doc
  • lib
    • tasks
  • log
  • public
    • images
    • javascripts
    • stylesheets
  • script
    • performance
  • test
    • fixtures
    • functional
    • integration
    • performance
    • unit
  • tmp
    • cache
    • pids
    • sessions
    • sockets
  • vendor
    • plugins

Não vou explicar para que serve cada um deles, mas os mais importantes para este mini tutorial são:

  • app/controllers – onde vão ficar os controladores, o código que faz o meio de campo entre a lógica e a view.
  • app/models – onde vão ficar os models, a interface da aplicação com o banco de dados e toda a lógica
  • app/views – onde vamos renderizar os dados para os usuários
  • public/* – onde ficam os recursos estáticos, como imagens, estilos, javascripts
  • config – onde ficam as configurações da aplicação
  • scripts – scripts para poupar trabalho, gerar código, rodar servidores, …

A nossa aplicação vai ser composta de dois controladores, um model e algumas views.

O ideal seria começar escrevendo testes, mas como este é um post estilo “introdução ao rails” vou deixar os testes de lado.

A primeira coisa que vamos fazer é criar um cadastro básico de URLs, para isto vamos utilizar o gerador do rails, com o seguinte comando:

1
ruby script/generate scaffold url_info href:string clicks:integer

Este comando vai gerar uma série de arquivos, vamso dar uma olhada em alguns deles:

1
2
class UrlInfo < ActiveRecord::Base
end

Este é o conteúdo do arquivo app/models/url_info.rb, toda a implementação do nosso model para um cadastro simples e, por enquanto, sem validações.

E já podemos inclusive criar o banco de dados padrão da aplicação, o rails veio configurado por padrão para utilizar o banco de dados sqlite3, mas isto pode ser facilmente alterado, mas por enquanto vamos aceitar esta configuração e executar o comando:

1
rake db:migrate

Isto vai executar as migrations da aplicação, uma migration foi criada no último comando, vamos dar uma olhada rápida nela:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class CreateUrlInfos < ActiveRecord::Migration
  def self.up
    create_table :url_infos do |t|
      t.string :href
      t.integer :clicks
 
      t.timestamps
    end
  end
 
  def self.down
    drop_table :url_infos
  end
end

Esta migration possui o código para criar uma tabela de nome “url_infos”, com um campo de nome “href” de tipo “string” e um campo “clicks” de tipo “integer”, o mapeamento do tipo ruby para o tipo SQL vai depender do banco de dados, do driver que o rails utilizar para acessar o banco.

Em uma migration é importatne sempre implementar os dois métodos, o self.up cria coisas no banco de dados, e o self.down apaga coisas do banco de dados, tudo o que for criado no self.up tem que ser apagado no self.down, desta forma permitindo que voltemos a qualquer versão da aplicação para corrigir algum bug se necessário.

No exemplo estamos utilizando os métodos create_table e drop_table da migration, mais informações sobre estes métodos podem ser obtidas nesta página da documentação do Rails.

A configuração de qual banco a aplicação esta acessando fica no arquivo config/database.yml que podemos ver abaixo com o conteúdo padrão:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# SQLite version 3.x
#   gem install sqlite3-ruby (not necessary on OS X Leopard)
development:
  adapter: sqlite3
  database: db/development.sqlite3
  pool: 5
  timeout: 5000
 
# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  adapter: sqlite3
  database: db/test.sqlite3
  pool: 5
  timeout: 5000
 
production:
  adapter: sqlite3
  database: db/production.sqlite3
  pool: 5
  timeout: 5000

Este arquivo tem 3 sessões, correspondentes aos ambientes de desenvolvimento, testes e produção, ou seja, já podemos deixar estes 3 bancos de dados[bb] configurados, o que pode facilitar bastante a vida, ou complicar as vezes :D

Mas a idéia básica é que em cada ambiente é possível configurar qual o driver do banco de dados “adapter”, e os parâmetros deste driver, neste caso apenas o nome do banco é o suficiente, não vou entrar em maiores detalhes aqui por que não é a idéia deste post, quero fazer o encurtador de URLs funcionar antes de você dormir ou cansar de ler …

Então vamos lá, o rails criou um cadastro completo, que se você digitar o seguinte comando para inicializar o servidor, já pode acessar:

1
ruby script/server

Agora abra o seu browser preferido e acesse o endereço: http://localhost:3000/url_infos

Você vai ver uma listagem de informações de URLs, e quantos clicks cada URL já recebeu, você já pode até cadastrar algumas URLs ai, não vamos mexer muito neste controlador que foi criado, vamos alterar só um pouquinho, não faz sentido na hora do cadastro de uma URL ser necessário informar o número de clicks, então vamos abrir o arquivo app/views/url_infos/edit.html.erb e deixe ele como o que esta abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<h1>Editing url_info</h1>
<% form_for(@url_info) do |f| %>
  <%= f.error_messages %>
  <p>
    <%= f.label :href %><br />
    <%= f.text_field :href %>
  </p>
  <p>
    <%= f.submit 'Update' %>
  </p>
<% end %>
 
<%= link_to 'Show', @url_info %> |
<%= link_to 'Back', url_infos_path %>

(Dica, eu removi o parágrafo que continha o campo “clicks”)

Nesta página podemos ver alguns dos helpers do rails para a geração de formulários HTML, e para tratamento de mensagens, a idéia do helper “form_for” é que a variável passada como argumento para o bloco representa um formulário para “aquele elemento”, isto torna possível utilizar os outros helpers “formulário.text_field”.
O Rails tem diversos helpers, tanto para formulários, para options, para AJAX e diversos outros.

Agora vamos duplicar a mudança no outro formulário no arquivo app/views/url_infos/new.html.erb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<h1>New url_info</h1>
 
<% form_for(@url_info) do |f| %>
  <%= f.error_messages %>
 
  <p>
    <%= f.label :href %><br />
    <%= f.text_field :href %>
  </p>
  <p>
    <%= f.submit 'Create' %>
  </p>
<% end %>
 
<%= link_to 'Back', url_infos_path %>

Claro que estes dois arquivos são bem parecidos, e que poderíamos juntar todo o código repetido dos dois, mas vamos deixar isto para depois, por enquanto isto não nos interessa muito.

Agora vamos editar o controlador no arquivo app/controllers/url_infos_controller.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
class UrlInfosController < ApplicationController
  # GET /url_infos
  # GET /url_infos.xml
  def index
    @url_infos = UrlInfo.all
 
    respond_to do |format|
      format.html # index.html.erb
      format.xml  { render :xml => @url_infos }
    end
  end
 
  # GET /url_infos/1
  # GET /url_infos/1.xml
  def show
    @url_info = UrlInfo.find(params[:id])
 
    respond_to do |format|
      format.html # show.html.erb
      format.xml  { render :xml => @url_info }
    end
  end
 
  # GET /url_infos/new
  # GET /url_infos/new.xml
  def new
    @url_info = UrlInfo.new
 
    respond_to do |format|
      format.html # new.html.erb
      format.xml  { render :xml => @url_info }
    end
  end
 
  # GET /url_infos/1/edit
  def edit
    @url_info = UrlInfo.find(params[:id])
  end
 
  # POST /url_infos
  # POST /url_infos.xml
  def create
    @url_info = UrlInfo.new(params[:url_info])
    @url_info.clicks = 0
    respond_to do |format|
      if @url_info.save
        flash[:notice] = 'UrlInfo was successfully created.'
        format.html { redirect_to(@url_info) }
        format.xml  { render :xml => @url_info, :status => :created, :location => @url_info }
      else
        format.html { render :action => "new" }
        format.xml  { render :xml => @url_info.errors, :status => :unprocessable_entity }
      end
    end
  end
 
  # PUT /url_infos/1
  # PUT /url_infos/1.xml
  def update
    @url_info = UrlInfo.find(params[:id])
 
    respond_to do |format|
      if @url_info.update_attributes(params[:url_info])
        flash[:notice] = 'UrlInfo was successfully updated.'
        format.html { redirect_to(@url_info) }
        format.xml  { head :ok }
      else
        format.html { render :action => "edit" }
        format.xml  { render :xml => @url_info.errors, :status => :unprocessable_entity }
      end
    end
  end
 
  # DELETE /url_infos/1
  # DELETE /url_infos/1.xml
  def destroy
    @url_info = UrlInfo.find(params[:id])
    @url_info.destroy
 
    respond_to do |format|
      format.html { redirect_to(url_infos_url) }
      format.xml  { head :ok }
    end
  end
end

A única alteração do código gerado foi a adição da linha “@url_info.clicks = 0″ no método create, que informa aquele parâmetro que removemos do formulário.

Neste arquivo podemos também ver alguns métodos interessantes do rails, veja na lista abaixo a explicação de alguns deles:

  • UrlInfo.all – A classe ActiveRecord::Base do rails tem diversos métodos para pesquisa, o all é um alias para find(:all) e aceita os mesmos parâmetros
  • respond_to – O bloco respond_to informa ao rails como responder para diferentes tipos mime
  • render – Este é o método que realmente envia a resposta para o cliente, ele possui diversos parâmetros que permitem o envio de respostas AJAX, XML, HTML e diversas outras de forma normalmente transparante, a documentação pode ser encontrada aqui.
  • @url_inf.save – save é o método da classe ActiveRecord::Base que insere ou altera o conteúdo de um registro de uma tabela.
  • @url_info.update_attributes – este é o método da classe ActiveRecord::Base que atualiza os atributos de um registro alterados e salva as alterações no banco de dados
  • params[...] – params é um hash que permite acesso aos parâmetros enviados pelo usuário
  • @url_info.destroy – este é o método utilizado para apagar um registro do banco de dados
  • format. – format. dentro de um bloco “respond_to” informa ao rails quais tipos mime este método sabe retornar, assim o rails decide qual o mais adequado a solicitação do usuário
  • UrlInfo.find – A classe ActiveRecord::Base do rails tem diversos métodos para pesquisa, o método find é a base para a maioria deles
  • redirect_to – este método permite enviar ao browser um código de redirecionamento HTTP

Acho que por enquanto já esta bom de alterações no cadastro, vamos fazer o encurtador de URLs funcionar.

Para isto vamos criar mais um controlador, execute no console o seguinte comando:

1
ruby script/generate controller redirector index

Como o nome diz, este é o controlador que vai fazer os redirecionamentos, depois deste comando executado, o arquivo app/controllers/redirector_controller.rb foi criado, vamos editar este arquivo para que ele fique mais ou menos assim:

1
2
3
4
5
6
7
class RedirectorController < ApplicationController
  def index
	  ui = UrlInfo.find params[:id]
	  redirect_to ui.href if ui
  end
 
end

Isto já faz o redirecionador funcionar, mas não exatamente da maneira que gostaríamos :D

Por enquanto para ele funcionar precisamos acessar http://localhost:3000/redirector?id=… a idéia é que funcione acessando http://localhost:3000/[id]

Quando o id for passado o redirecionamento deve ocorrer automagicamente, quando não for passado devemos ver a lista de links conhecidos com quantos clicks cada um já teve.

Para que isto funcione vamos editar o arquivo config/routes.rb como no exemplo abaixo (vou apagar todos os comentários para facilitar a leitura do arquivo, comentários em Ruby são as linhas começadas por “#”).

1
2
3
4
5
ActionController::Routing::Routes.draw do |map|
  map.resources :url_infos
 
  map.connect ':id', :controller => 'redirector', :action => 'index'
end

A linha map.resources :url_infos foi gerada automaticamente com o scaffold, ela configura todas as rotas para o cadastro de URLs.
Esta linha configura as seguitnes rotas na aplicação:

Nome Método HTTP Caminho Mapeamento
url_infos GET /url_infos(.:format) {:action=>”index”, :controller=>”url_infos”}
  POST /url_infos(.:format) {:action=>”create”, :controller=>”url_infos”}
new_url_info GET /url_infos/new(.:format) {:action=>”new”, :controller=>”url_infos”}
edit_url_info GET /url_infos/:id/edit(.:format) {:action=>”edit”, :controller=>”url_infos”}
url_info GET /url_infos/:id(.:format) {:action=>”show”, :controller=>”url_infos”}
  PUT /url_infos/:id(.:format) {:action=>”update”, :controller=>”url_infos”}
  DELETE /url_infos/:id(.:format) {:action=>”destroy”, :controller=>”url_infos”}

A segunda linha configura a aplicação para quando receber apenas um parâmetro passar isto para o controlador de nome “redirector” para a action “index”, agora se acessarmos o endereço http://localhost:3000/1 a aplicação vai nos redirecionar para a primeira URL cadastrada, mas ainda não esta legal, precisamos contar os clicks tabém.

Para contar o clicks vamos alterar o redirector controller que editamos antes, o código dele vai ficar assim:

1
2
3
4
5
6
7
8
9
10
class RedirectorController < ApplicationController
  def index
        ui = UrlInfo.find params[:id]
        if ui
                ui.clicks += 1
                ui.save
                redirect_to ui.href
        end
  end
end

Agora antes de redirecionar a quantidade de clicks é incrementada e a informação é salva no banco de dados.

Agora vamos mudar a página inicial para a listagem de URLs, temos duas formas de fazer isto, forma chinelona:
Editar o arquivo public/index.html e configurar um meta refresh, o conteúdo fica como abaixo (HTML padrão).

1
2
3
4
5
6
7
8
9
10
11
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
  <head>
    <meta http-equiv="refresh" content="0;url=url_infos" />
    <title>Mega URL Shortener Sample</title>
  </head>
  <body>
  <a href="url_infos">Link List</a>
  </body>
</html>

Ou apagar o arquivo public/index.html, e editar novamente o arquivo config/routes.rb, verifique abaixo o conteúdo alterado.

1
2
3
4
5
ActionController::Routing::Routes.draw do |map|
  map.resources :url_infos
  map.root :controller => 'url_infos'
  map.connect ':id', :controller => 'redirector', :action => 'index'
end

Foi adicionada a linha “map.root :controller => ‘url_infos’” que informa qual a ação padrão da aplicação.

E com isto já temos o encurtador de URLs quase pronto, faltam alguns detalhes, primeiro no arquivo app/views/redirector/index.html.erb vamos adicionar uma mensagem dizendo que a URL não esta cadastrada.

1
<b>A URL informada não esta cadastrada no sistema</b>

Isto vai funcionar por que o controlador “redirector” só chama o redirect se a “UrlInfo” for encontrada, caso contrário ele executa a ação default, que é renderizar a “view” correspondente ao método.

Agora vamos apagar alguns arquivos no diretório app/views/url_infos/, siga a lista:

  • edit.html.erb
  • new.html.erb
  • show.html.erb

Vamos editar o arquivo index.html.erb no mesmo diretório:

1
2
3
4
5
6
7
<h1>Shortened URLs</h1>
<div id="form">
<%= render :partial => 'editor_form' %>
</div>
<div id="table">
<%= render :partial => 'urls_table' %>
</div>

Todo o conteúdo deste arquivo foi movido para dois partials, partials são uma forma de reutilizar código de views no rails, mas neste caso estaremos utilizando partials para implementar um pouco de AJAX.

A idéia é que o formulário do topo da página seja submetido via ajax e que atualize apenas o pedaço da página que for necessário, veja abaixo como ficaram os dois partials:
_editor_form.html.erb

1
2
3
4
5
6
7
8
<% form_remote_for(@url_info) do |f| %>
  <%= f.error_messages %>
  <p>
    <%= f.label :href, 'URL:' %>
    <%= f.text_field :href %>
    <%= f.submit 'Create' %>
  </p>
<% end %>

Neste formulário estamos utilizando o helper “form_for_remote” que cria um formulário que sera submetido via AJAX, não fazendo refresh da página toda de uma só vez.
_urls_table.html.erb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<table width="100%">
  <tr>
    <th>Original URL</th>
    <th>Shortened URL</th>
    <th>Clicks</th>
  </tr>
<% @url_infos.each do |url_info| %>
  <tr>
    <td><%=h url_info.href %></td>
    <td><%=h url_for(:controller => 'redirector', :id => url_info.id, :only_path => false) %></td>
    <td><%=h url_info.clicks %></td>
    <td><%= link_to 'Go To', :controller => 'redirector', :id => url_info.id %></td>
    <td><%= link_to 'Destroy', url_info, :confirm => 'Are you sure?', :method => :delete %></td>
  </tr>
<% end %>
</table>

A tabela não sofreu alterações grandes, apenas foi colocado mais um campo para mostrar qual a URL no sistema correspondente a uma URL cadastrada, e para que isto ficasse dinâmico, o helper “url_for” for utilizado, com o parâmetro “:only_path” setado para false, desta forma a URL completa seria impressa.

Para que este formulário via AJAX[bb] funcione, algumas alterações precisaram ser feitas no controlados “url_infos”, como pode ser visto abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
class UrlInfosController < ApplicationController
  # GET /url_infos
  # GET /url_infos.xml
  def index
    @url_infos = UrlInfo.all
    @url_info = UrlInfo.new
 
    respond_to do |format|
      format.html # index.html.erb
      format.xml  { render :xml => @url_infos }
    end
  end
 
  # POST /url_infos
  # POST /url_infos.xml
  def create
    @url_info = UrlInfo.new(params[:url_info])
    @url_info.href = params[:href] if params[:href]
    @url_info.clicks = 0
    respond_to do |format|
      if @url_info.save
        format.html  do
          flash[:notice] = 'UrlInfo was successfully created.'
          redirect_to root_url
        end
        format.xml  { render :xml => @url_info, :status => :created, :location => @url_info }
	format.js  do
          @url_infos = UrlInfo.all
          @url_info = UrlInfo.new
          render :update do |page|
            page.replace_html 'form', :partial => 'editor_form'
            page.replace_html 'table', :partial => 'urls_table'
            page.alert 'UrlInfo was successfully created.'
          end 
        end
      else
        format.html { render :action => "index" }
        format.xml  { render :xml => @url_info.errors, :status => :unprocessable_entity }
        format.js do
          render :update do |page|
            page.alert @url_info.errors.full_messages.join '\n'
          end
        end
      end
    end
  end
 
  # DELETE /url_infos/1
  # DELETE /url_infos/1.xml
  def destroy
    @url_info = UrlInfo.find(params[:id])
    @url_info.destroy
 
    respond_to do |format|
      format.html { redirect_to(url_infos_url) }
      format.xml  { head :ok }
    end
  end
end

Alguns métodos foram removidos, e o metodo create sofreu algumas alterações dentro do bloco “respond_to” adicionando suporte a respostas tipo “javascript”. E tem mais um detalhe no mesmo método, a segunda linha foi adicionada para quebrar todo o suporte “REST” do rails, como este é um encurtador de URLs eu quero que seja possível adicionar uma URL via uma chamada a uma URL do sistema, neste caso vai ser “/add/” e para isto na segunda linha do método “create” se o parâmetro “href” existir este é utilizado como valor da URL sendo criada no sistema, mas para isto funcionar a alteração abaixo é necessária no arquivo config/routes.rb:

1
2
3
4
5
6
7
ActionController::Routing::Routes.draw do |map|
  map.resources :url_infos
 
  map.root :controller => 'url_infos'
  map.connect '/add/:href', :controller => 'url_infos', :action => 'create', :href => /http[s]{0,1}:\/\/.*/
  map.connect ':id', :controller => 'redirector', :action => 'index'
end

A alteração feita foi a adição da linha “map.connect ‘/add/…”, preste atenção na utilização de uma expressão regular na especificação do parâmetro “href” no final da linha, isto permite que a URL completa seja utilizada como parâmetro, se isto não for utilizado o parâmetro vai terminar na primeira “/” da URL e o roteamento não vai funcionar corretamente.

Agora para que o AJAX funcione vamos alterar o layout gerado quando executamos o primeiro comando “script/generate scaffold …”, naquele momento foi gerado também o arquivo app/views/layouts/url_infos.html.erb.

Como este arquivo de layout[bb] tem o nome de um controlador, ele é utilizado apenas por este controlador, se o nome do arquivo fosse “application.html.erb” ele seria utilizado por todos os controladores da aplicação que não tivesse um layout próprio.

O conteúdo do arquivo é semelhante a qualquer outra view, uma coisa interessante de se reparar no nome do arquivo é que ele contem o “mime type” no nome, então se quisermos criar um “layout” para respostas XML vale a mesma lógica (application.xml.erb).

Vamos ver o conteúdo deste layout:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="content-type" content="text/html;charset=UTF-8" />
  <title>UrlInfos: <%= controller.action_name %></title>
  <%= stylesheet_link_tag 'scaffold' %>
  <%= javascript_include_tag :defaults %>
</head>
<body>
 
<p style="color: green"><%= flash[:notice] %></p>
 
<%= yield %>
 
</body>
</html>

Foi adicionada a linha “<%= javascript_include_tag :defaults %>” que adiciona na página gerada a chamada para o javascript padrão do rails (que utiliza por padrão a biblioteca prototype).

O conteúdo das views é renderizado no lugar em que se encontra “<%= yield %>” neste arquivo de layout.

A última alteração que falta é impedir que sejam cadastradas URLs duplicadas ou em branco, para isto vamos voltar ao arquivo do model app/models/utl_info.rb

1
2
3
4
class UrlInfo < ActiveRecord::Base
	validates_uniqueness_of :href
	validates_presence_of :href
end

O suporte a validações do rails é bem flexível, e possui helpers para diversas validações, neste caso estamos garantindo que a URL seja única e esteja preenchida.

Bom, acho que era isto, temos um encurtador de URLs bem simples pronto. Esepro que o exemplo tenha sido útil para mostrar alguns dos recursos do Rails fugindo um pouco do exemplo padrão do blog.

Siga os links para a documentação do Rails, e lembre-se de programar sempre com o site da API do rails aberto em um browser.

PS.: o código completo para este exemplo esta disponível no github.

Tags: , , , ,

25 Jun 09 Um especialista precisa saber um pouco de cada coisa

Para quem acha que o título deste post esta contraditório, lamento informar, mas você esta completamente equivocado.
Você conhece algum especialista? De preferência algum que esteja ai pertinho de você.
Se conhece por exemplo um especialista em Java ou .NET, chega pra ele e pergunta se ele conhece algum dos seguintes assuntos:

  • XML
  • Expressões Regulares
  • HTML
  • XHTML
  • Javascript
  • Modelos de Threading
  • Como funciona uma CPU
  • Para que serve um sistema operacional
  • O que é e para que serve uma “Maquina Virtual”
  • Flash
  • XSD
  • XPath
  • SQL
  • Estrutura de bancos de dados
  • TCP/IP
  • Sockets

Acredito que a resposta vai ser sim para todos, ou pelo menos a grande maior parte destes itens. E isto são só coisas genéricas, imagina se começarmos a detalhar a sopa de letrinhas existente no mundo Java EE ou no .NET.
Pois é mais ou menos isto que estou querendo dizer, um especialista precisa saber um monte de coisas para se tornar um especialista em uma delas.
A forma mais fácil que eu conheço para melhorar muito e muito rápido a qualidade do código que você escreve em uma linguagem é aprendendo outra linguagem de programação.
Tem gente que diz que o ideal é aprender uma linguagem nova por ano, e com certeza, o período da minha vida profissional que eu mais melhorei foi quando aprendi várias linguagens em um período curto de tempo.
Quando eu era mais novo (coisa de velho escrever isto :D ) o meu chefe na época disse que um especialista é alguem que sabe cada vez mais sobre cada vez menos, e que um super especialista é alguem que sabe absolutamente tudo sobre absolutamente nada …
Ach oque este conceito esta um pouco desatualizado, até por que por este conceito, um super especialista é o cara que sabe absolutamente tudo sobre absolutamente nada.

Pelo menos na minha opinião, eu espero que um especialista em Java por exemplo, consiga criar um pacote EAR padrão Java EE para uma aplicação composta por dois módulos web e três módulos EJB além de algumas bibliotecas utilizadas por todos os módulos.
Para fazer isto, o cara vai ter que conhecer no mínimo muito XML, vai ter que saber o que são meta dados, vai ter que saber quais meta dados foram definidos via anotações no código e quais ele vai querer sobre escrever com XML. Vai ter que conhecer a estrutura de um arquivo EAR, a estrutura de um arquivo WAR e qual a diferença entre um arquivo jar de uma biblioteca e de um módulo EJB.
Para entender direito o que ele ta fazendo, ele vai ter que conhecer o protocolo HTTP, por conseqüência o protocolo TCP e o IP. Além de precisar entender de RMI que é utilizado para chamada dos EJBs, RMI também funciona sobre TCP.
Se o servidor for rodar em cluster, é necessário saber como este cluster esta configurado, a maior parte dos servidores Java EE utiliza o protocolo IIOP/IP, o mesmo do corba, já que pela especificação Java EE todo EJB pode ser chamado utilizando CORBA também, e que o IIOP/IP permite roteamento muito mais fácil do que o RMI direto.
E isto tudo só para começar.
Se o especialista em java precisar também configurar o servidor de aplicações também ai aumenta bastante a quantidade de coisas que ele vai ter que saber só para poder ser chamado de especialista em Java e nem chegamos na parte de desenvolvimento ainda …
Claro que isto ainda é só a minha opinião, mas para ser um especialista em java, o cara tem que saber muito bem Orientação a Objetos, Reflexão, Refactoring e mais Refactoring, AOP, a diferença entre excessões checadas e não checadas, para que serve cada tipo de collection, todas as classes no mínimo dos pacotes java.lang e java.util e mais um monte de outras coisas.

Só para finalizar.
Vocês não vão conseguir se tornar especialistas em nada da noite para o dia. Isto vai demorar bastante, e mesmo que você queira ser especialista em .NET por exemplo, você vai ter que estudar muitas outras coisas.
A pior coisa que tem é programador bitolado que acha que a única linguagem/ferramenta/time/religião que presta é a que ele conhece agora …
(isto foi um misto de dicas com desabafo :D )

Tags: , ,

19 Jan 09 Profiglacy – Nunca foi tão fácil escrever uma UI com Swing (Graças ao JRuby)

O nome é complicado mesmo, o nome da biblioteca é “Profiglacy“. O nome da biblioteca veio de um SPAM recebido pelo Zed Shaw e ele utiliza esta biblioteca para escrever um programa de nome iHate, que é um cliente para um protocolo parecido com IRC, mas com algumas coisas mais divertidas.

O JRuby é uma implementação da linguagem Ruby para rodar na JVM. Uma das vantagens de uma implementação de Ruby rodando em uma JVM é a possibilidade de tirar proveito de todas as outras coisas que também rodam na JVM.
Exemplos disto são o acesso a EJBs a partir de aplicações Ruby, utilização de código Legado Java, acesso a diversas bibliotecas que já existem para Java e ainda não existem para Ruby.
Outra grande vantagem é a possibilidade de escrever UIs utilizando SWING que é um dos frameworks para UI mais completos disponíveis hoje em dia, mas que quando utilizado com java, tem uma possibilidade muito grande de criar um código horrível.
E para solucionar este problema existe o Profiglacy, que é uma biblioteca Ruby para facilitar a utilização de SWING quando se esta trabalhando com o JRuby.

E neste pequeno tutorial vou criar uma aplicação simples utilizando esta biblioteca. A proposta é um Gerenciador de Tarefas bem simples, mas antes vamos ver do que estamos fugindo …

Criar UI em Java é muito flexível mas muito trabalhoso, o SWING é poderoso mas muito verboso, e a própria natureza do Ruby ja melhora um pouco isto, veja o código abaixo:

1
2
3
4
5
6
require 'java'
 
@frame = javax.swing.JFrame.new "Old Way, using only SWING from Ruby"
@frame.add(@lbl1 = javax.swing.JLabel.new("Master Title"))
@frame.pack
@frame.visible = true

Isto vai criar um jframe com um label, mas ainda assim iriamos precisar de todos aqueles gerenciadores de layout, além de ser necessário também atrelar a ordem de criação dos objetos a posição deles no layout, mas para tudo há uma solução.
O modo padrão de trabalho do Profiglacy melhora isto apenas um pouco, então vamos começar direto com a utilização da Layout Expression Language criada para utilização na biblioteca. É basicamente uma forma fácil de se utilizar um GridLayout …
O layout vai ser definido como uma String, o formato desta string é bastante simples:

  • [ .. ] – delimita o inicio e fim de uma linha
  • | – delimita uma celula da linha
  • label – qualquer nome utilizado dentro de uma celula se torna o nome da celula para referência posterior
  • _ – identifica uma celula em branco
  • (width) ou (width,height) – define a largura e/ou altura de um componente dentro da celula
  • * – Expande a celula
  • ^ ou . – Alinham o componente no topo ou na parte de baixo da celula respectivamente
  • < ou > – Alinham o componente a esquerda ou direita respectivamente

E é isto, simples assim …
Segue um exemplo para facilitar o entendimento:

1
2
3
4
5
[ <lbl_proj | cmb_project  ]
[ <lbl_activ | cmb_activ  ]
[ <lbl_date | inpt_date ]
[ <lbl_hour | inpt_hour ]
[ <lbl_description | (300,200)txt_description  ]

Este código define um Grid Layout de 5 linhas por duas colunas, todos os componentes da esquerda estão também alinhados a esquerda e o último componente da direita tem 300 pixels de largura por 200 de altura.

Agora algum de vocês se anima a escrever o código em java para montar isto? Não precisa nem usar o Grid Layout, garanto que vai ficar bem maior.

Claro que as vezes o LEL (Layout Expression Language) não é suficiente, mas para mim parece que isto torna 80% dos casos bastante simples, e quando for necessário isto sempre pode ser combinado com código padrão …

Deem uma olhada no código abaixo, é criada uma UI simples, combinando paineis.
O primeiro painel definido por “main_layout” organiza os grupos de componentes, o primeiro componente recebe um label e os outros dois recebem paineis, criados com LEL mas poderiam ser criados utilizando JPanel.new sem maiores problemas.
TaskManager.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
require 'java'
require 'rubygems'
require 'profligacy/swing'
require 'profligacy/lel'
 
module TaskManager
    class UI
      include_package 'javax.swing'
      include_package 'java.awt'
      include_package 'javax.swing.border'
      include Profligacy
 
      def initialize(title)
        main_layout = "[main_label][inputs][buttons]"
        layout = %Q{
        [ <lbl_proj | cmb_project  ]
        [ <lbl_activ | cmb_activ  ]
        [ <lbl_date | inpt_date ]
        [ <lbl_hour | inpt_hour ]
        [ <lbl_description | (300,200)txt_description  ]
        }
        @ui = Swing::LEL.new JFrame, main_layout do |c,i|
          c.main_label = JLabel.new "Information About  New Entry"
          c.inputs = Swing::LEL.new JPanel, layout do |d,i| 
            d.lbl_proj = JLabel.new "Project"
            d.cmb_project = JTextField.new
            d.lbl_activ = JLabel.new "Activity" 
            d.cmb_activ = JTextField.new 
            d.lbl_date = JLabel.new "Date"
            d.inpt_date = JTextField.new 
            d.lbl_hour = JLabel.new "Hour"
            d.inpt_hour = JTextField.new 
            d.lbl_description = JLabel.new "Description"
            d.txt_description = JTextArea.new
          end.build :auto_create_container_gaps => false
          c.buttons = Swing::LEL.new JPanel, "[button_save|button_cancel ]" do |e,i|
            e.button_save = JButton.new "Save"
            i.button_save = { :action => method(:save_clicked) }
            e.button_cancel = JButton.new "Cancel"
          end.build :auto_create_container_gaps => false
        end
        @ui.build(:args => "Simple LEL Example").default_close_operation = JFrame::EXIT_ON_CLOSE
      end
 
      def save_clicked(evt_type,event)
        puts "Test OK 2"
      end
 
      def self.start
        SwingUtilities.invoke_later proc { UI.new('My Test Frame with long title') }.to_runnable
      end
 
    end
end

Para executar o código precisamos apenas de um arquivo Ruby para chamar o método “start” definido na classe UI, claro que poderiamos ter utilizado o mesmo arquivo .rb, mas isto iria diminuir a possibilidadede reutilização daquele código, então criei o arquivo abaixo:
starter.rb

1
2
3
require 'TaskManager'
 
TaskManager::UI.start

Pronto, com este super mini tutorial, você ja pode escrever muito menos código para definir as suas interfaces Java de hoje em diante, para isto só precisa programar em Ruby :D

Cada vez mais me convenço que o melhor cenário é utilizar java como Plataforma em vez de como Linguagem :D

PS.: Eu sei que faltou explicar toda a parte de eventos, mas se não for possível inferir isto do exemplo apresentado, postem perguntas nos comentários que escrevo mais algo detalhado sobre isto (isto vai servir também pra ver se alguem lê o que eu escrevo aqui :D )

Tags: , , , , , , , ,

13 Nov 08 Comentário no código é para os fracos

Provavelmente serei crucificado por causa deste post, mas se você se der ao trabalho de ler até o final, provavelmente vai concordar comigo que comentários no código são para os fracos, programador hardcore de verdade escreve código legível!
É exatamente isto que eu estou dizendo, por exemplo, o que faz o código abaixo?

1
2
3
4
5
6
7
8
9
10
public String write(StringBuilder fle, StringBuffer con) {
  File f = new File(fle.toString());
  FileReader fr = new FileReader(f);
  BufferedReader br = new BufferedReader(fr);
  String lin;
  while((lin=br.readLine())!=null){
    con.append(lin).append("\n");
  }
  return con.toString();
}

Difícil? E este ainda é um código simples, mas vamos dar uma melhorada nele …

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public String read(StringBuilder fle, StringBuffer con) {
  //Opens the file with the name container in the fle parameter
  File f = new File(fle.toString());
  //Create a file reader, then a buffered reader to make our work easier
  FileReader fr = new FileReader(f);
  BufferedReader br = new BufferedReader(fr);
  String lin;
  //Read each line of the file until it is null
  while((lin=br.readLine())!=null){
    //Put the content read into the buffer pointed by the parameter "con"
    con.append(lin).append("\n");
  }
  //The caller already have the content, because he created the buffer, but I'll return the string anyway
  return con.toString();
}

Mais fácil certo? Bastou ler os comentários, mas o código continua um lixo.
Ou seja, esta é uma gambiarra utilizada por péssimos programadores para contornar a própria limitação de não conseguir escrever um código decente.

Então qual a solução que eu recomendo?
Vamos tentar reescrever este método então:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public String readFileContents(File fileToRead) {
  boolean canReadFile = fileToRead.exists();
  if(!canReadFile)
    return "";
  StringBuilder buffer = new StringBuilder();
  BufferedReader readerForFile = openBufferedReaderForFile(fileToRead);
  readFileContetIntoBuffer(buffer,readerForFile);
  closeFileReader(readerForFile);
  return buffer.toString();
}
private  BufferedReader openBufferedReaderForFile(File fileToRead){
  return new BufferedReader(new FileReader(fileToRead));
}
private void readFileContetIntoBuffer(buffer,readerForFile){
  String line;
  while((line=readerForFile.readLine())!=null){
    buffer.append(line).append("\n");
  }
}
private void closeFileReader(readerForFile){
  readerForFile.close();
}

Agora se você prestar atenção no nome do método “readFileContents” já vai saber o que o método faz, Além disto, o código do método é quase legível em inglês. A leitura dele ficaria mais ou menos assim:

if not can read file, return null
open Buffered Reader For File: fileToRead
read File Contet Into Buffer: buffer, readerForFile
close File Reader: readerForFile
return buffer.toString();

Ou seja, qualquer um que entenda inglês, como qualquer desenvolvedor tem a obrigação de entender, vai ler o método como se fosse um comentário.

E eu já vi gente fazendo pior do que isto, o código tinha comentários, mas parecia com esta coisa ai em baixo:

1
2
3
4
5
public String write(StringBuilder fle, StringBuffer con) {
  File f = new File(fle.toString()); FileReader fr = new FileReader(f);  BufferedReader br = new BufferedReader(fr);
String lin; while((lin=br.readLine())!=null){  con.append(lin).append("\n");  }
  return con.toString();
}

Com certeza tinha muito menos linhas de código do que a minha versão :D
Mas não é uma tarefa fácil entender o código que uma criatura destas escreve :D

Claro que o exemplo que eu apresentei foi um exemplo bem simples, e que escrever código legível requer uma certa prática …
Então, vou fazer uma proposta:
Vou deixar um exemplo de código abaixo, e vocês tentam torna-lo mais legível. Em um ou dois dias eu posto a minha resposta aqui.
Quem quiser pode postar nos comentários o código que escreveu.
Para que o código fique colorido no blog, basta colocar dentro de uma tag <pre lang=”java” line=”1″> … </pre>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
package blog;
 
import java.io.BufferedReader;
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.FileWriter;
import java.io.IOException;
 
public class VeryBadlyNamedFile {
	private static final char[] asdfg = new char[] {'I', ' ', 'c', 'a', 'n', ' ', 'd', 'o', ' ', 'v', 'e', 'r', 'y', ' ', 'u', 'g', 'l', 'y', ' ', 'c', 'o', 'd', 'e'};
	private String an;
	private BufferedReader rfsdw;
	private FileReader temp;
 
	public VeryBadlyNamedFile(String an, BufferedReader rfsdw, FileReader temp) {
		super();
		this.an = an;
		this.rfsdw = rfsdw;
		this.temp = temp;
	}
 
	public void doIt() throws IOException {
		ctfiidne();
		startDoing();
		try {
			canIDoAnyThing();
		} catch (RuntimeException yicdet) {
			nowReallyDoIt();
		}
	}
 
	private void nowReallyDoIt() {
		firstDoTheOtherThing();
		reallyDoItInternal();
	}
 
	private void firstDoTheOtherThing() {
		rfsdw = new BufferedReader(temp);
	}
 
	private void reallyDoItInternal() {
		while (true) {
			try {
				imDoingIt();
			} catch (Exception e) {
				break;
			}
		}
	}
 
	private void imDoingIt() throws Exception {
		String s = rfsdw.readLine();
		if (s == null)
			throw new Exception("hahaha, I bet you did not understood the code");
		System.out.println(s);
	}
 
	private void ctfiidne() throws IOException {
		File a = new File(an);
		if (!a.exists()) {
			FileWriter wrfedsd = new FileWriter(a);
			wrfedsd.write(asdfg);
			wrfedsd.close();
		}
	}
 
	private void canIDoAnyThing() {
		if (new File(an).exists() && new File(an).canRead() && new File(an).canWrite())
			throw new RuntimeException();
	}
 
	private void startDoing() throws FileNotFoundException {
		File f = new File(an);
		temp = new FileReader(f);
	}
}

E agora um “main” só para executar o lixão acima.

1
2
3
4
5
6
7
8
9
package blog;
 
import java.io.IOException;
 
public class Main {
	public static void main(String[] args) throws IOException {
		new VeryBadlyNamedFile("c:\\anyFile.any",null,null).doIt();
	}
}

Os exemplos estão em java, mas em qualquer linguagem os comentários para explicar o código servem para mascarar a incapacidade dos programadores escreverem código decente.

PS.: Só para constar, eu não acho de verdade que vocês não devem comentar o código, mas se vocês não escrevem código legível, ou escrevem código que realmente precisa de um comentário para outro programador entender, então vocês não aprenderam a programar ainda!

PS2.: só para constar, o código deste post foi inventado na hora, inspirado em coisas que ja vi em diversos lugares por ai, masescrevi ele direto no blog, então existe uma grande possibilidade de não compilar.

PS3.: acho que preciso de exemplos melhores, mas vocês devem ter entendido a idéia deste post

Tags: , , ,

15 Jul 08 Testes unitários em C++ para um programador Java!

English version here
Eu trabalhei com C++ quando iniciei no mundo da programação (entre 1997 e 2000), mas na época eu trabalhava com o Borland C++ Builder e o Microsoft Visual C++, naquela época eu ainda não tinha ouvido falar em testes unitários, depois disto eu trabalhei com Delphi, PHO, ASP, ColdFusion, …
Desde 2002 eu trabalhei a maior parte do tempo com Java, e aprendi muito neste período, muitas boas práticas, muito sobre orientação a objetos e principalmente, aprendi a amar os testes unitários.
Pouco tempo atrás eu voltei a trabalhar com C++, mas já viciado em testes unitários, e querendo aplica-los ao meu código C++ também, e este post é um exemplo bem curto de como um programador Java pode trabalhar com C++ utilizando testes unitários.

Um projeto C++ começa por um Makefile, eu estou acostumado com o ANT e não gosto da idéia de listar todos os meus arquivos fonte na configuração de build como a maior parte dos exemplos de Makefiles fazem, então eu criei um Makefile simples, mas bastante flexível para o meu projeto.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
TESTDIRECTORIES := test
DIRECTORIES := src
SOURCES := $(foreach dir,$(DIRECTORIES),$(wildcard $(dir)/*.cpp))
TESTSOURCES := $(foreach dir,$(TESTDIRECTORIES),$(wildcard $(dir)/*.cpp))
OBJECTS := $(patsubst %.cpp,%.obj,$(SOURCES))
TESTOBJECTS := $(patsubst %.cpp,%.obj,$(TESTSOURCES))
TESTOBJECTS += $(filter-out src/main.obj,$(OBJECTS))
TARGET := example
LINK := g++
CC := g++
CFLAGS := -c
LFLAGS :=
 
all: $(OBJECTS)
	$(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS)
 
test: $(TESTOBJECTS)
	$(LINK) $(LFLAGS) -lcppunit -o $(TARGET)_unit $(TESTOBJECTS) 
	./$(TARGET)_unit
 
%.obj:%.cpp
	$(CC) $(CFLAGS) -o $*.obj $*.cpp

Com este Makefile, todos os arquivos .cpp que estiverem no diretório src farão parte do executável gerado, mais diretórios podem ser adicionados simplesmente atualizando a variável DIRECTORIES, a mesma coisa acontece com o diretório test e a variável TESTDIRECTORIES para os testes unitários.
O truque aqui é a combinação das funções foreach e wildcard, a função pathsubst é usada para alterar as extensões de .cpp para .obj e a função filter-out é usada para remover o main.cpp dos testes unitários pois este arquivo é apenas o ponto de entrada para o executável principal.
Este Makefile é o mais próximo que eu consegui chegar da funcionalidade do ANT para programação C++, claro que ela pode ser melhorada, considerando que eu não sou um especialista em Makefiles.
Mas o Makefile não é o motivo deste post, estou escrevendo para contar para vocês sobre o CppUnit, uma ótima implementação xUnit para C++.
Eu comecei o projeto escrevendo o “executador de testes” do CppUnit:
testRunner.hpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#include <cppunit/CompilerOutputter.h>
#include <cppunit/extensions/TestFactoryRegistry.h>
#include <cppunit/TestResult.h>
#include <cppunit/TestResultCollector.h>
#include <cppunit/TestRunner.h>
#include <cppunit/BriefTestProgressListener.h>
 
int main (int argc, char* argv[])
{
    // informs test-listener about testresults
    CPPUNIT_NS :: TestResult testresult;
 
    // register listener for collecting the test-results
    CPPUNIT_NS :: TestResultCollector collectedresults;
    testresult.addListener (&collectedresults);
 
    // register listener for per-test progress output
    CPPUNIT_NS :: BriefTestProgressListener progress;
    testresult.addListener (&progress);
 
    // insert test-suite at test-runner by registry
    CPPUNIT_NS :: TestRunner testrunner;
    testrunner.addTest (CPPUNIT_NS :: TestFactoryRegistry :: getRegistry ().makeTest ());
    testrunner.run (testresult);
 
    // output results in compiler-format
    CPPUNIT_NS :: CompilerOutputter compileroutputter (&collectedresults, std::cerr);
    compileroutputter.write ();
 
    // return 0 if tests were successful
    return collectedresults.wasSuccessful () ? 0 : 1;
}

CppUnit é mito flexível, permitindo diversos tipos de saída para os resultados dos testes, mas escreverei sobre isto em outro post, a idéia atrás deste “executador” é a utilização do registro de testes do CppUnit, o que torna a vida muito mais fácil.
O registro de testes é bem próximo ao fileset passado a task junit do ant, mas os testes se registram sozinhos.
Depois do “executador de testes” pronto, podemos começar a escrever os testes unitários.
Em C++ diferente do Java, são necessários dois arquivos para cada classe, um cabeçalho e uma implementação.
Então, vamos começar com o cabeçalho.
mainTest.hpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#ifndef MAINTEST_H
#define MAINTEST_H
 
#include <cppunit/TestFixture.h>
#include <cppunit/extensions/HelperMacros.h>
#include "../src/HelloWorld.hpp"
 
using namespace std;
 
class MainTest : public CPPUNIT_NS :: TestFixture
{
    CPPUNIT_TEST_SUITE (MainTest);
    CPPUNIT_TEST (testHello);
    CPPUNIT_TEST_SUITE_END ();
 
    public:
        void setUp (void);
        void tearDown (void);
        void testHello (void);
    private:
        HelloWorld *hello;
};
CPPUNIT_TEST_SUITE_REGISTRATION (MainTest);
#endif

Neste cabeçalho temos uma declaração de classe simples, extendendo TestFixture do namespace do CppUnit.
C++ não possui reflexão, por isto o CppUnit possui algumas macros para definir o teste, que podem ser vistas no início da declaração da classe, será necessária uma linha com CPPUNIT_TEST para cada método de teste que você declarar.
A linha: CPPUNIT_TEST_SUITE_REGISTRATION (MainTest);
Faz a mágica do auto registro dos testes.
Com isto pronto, você pode começar a implementar a classe de testes como faria em java:
mainTest.cpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include "mainTest.hpp"
 
void MainTest::setUp(){ 
	hello = new HelloWorld("Test");
}
 
void MainTest::tearDown(){
	delete hello;
}
 
void MainTest::testHello(){
	string expected("Hello Test\n");
	CPPUNIT_ASSERT_EQUAL(expected,hello->sayHello());
}

Como no JUnit existem os métodos setUp e tearDown que são executados antes e depois de cada um dos testes, e o método testHello possui o código do teste (ja que só foi implementado um para este exemplo).
As asserções no CppUnit são feitas utilizando macros.
O CppUnit disponibiliza as seguintes asserções:

  • CPPUNIT_ASSERT(condition)
  • CPPUNIT_ASSERT_MESSAGE(message,condition)
  • CPPUNIT_FAIL( message )
  • CPPUNIT_ASSERT_EQUAL(expected,actual)
  • CPPUNIT_ASSERT_EQUAL_MESSAGE(message,expected,actual)
  • CPPUNIT_ASSERT_DOUBLES_EQUAL(expected,actual,delta)
  • CPPUNIT_ASSERT_THROW( expression, ExceptionType )

Muito menos do que no JUnit, mas o suficiente para a grande maioria dos casos.
Depois do teste pronto, agora precisamos escrever o código para que os testes passem.
HelloWord.hpp

1
2
3
4
5
6
7
8
9
10
11
12
13
#include <stdio.h>
#include <iostream>
 
#ifndef MAIN_HPP
#define MAINHPP
class HelloWorld{
private:
	std::string name;
public:
	HelloWorld(char* name);
	std::string sayHello();
};
#endif

E a implementação:
HelloWord.cpp

1
2
3
4
5
6
7
8
9
10
11
#include "HelloWorld.hpp"
 
HelloWorld::HelloWorld(char* name){
	this->name = name;
}
 
std::string HelloWorld::sayHello(){
	std::string result("Hello ");
	result = result + name + "\n";
	return result;
}

Para executar os testes, basta você executar no console:
make test
Agora que todos os testes foram escritos e estão passando, o último passo é escrever o código para inicializar a aplicação:
main.cpp

1
2
3
4
5
6
7
8
#include "HelloWorld.hpp"
int main(int argc, char** argv){
	if (argc >= 2) {
		HelloWorld* hello = new HelloWorld(argv[1]);
		std::cout << hello->sayHello();
		delete hello;
	}
}

E você tem a sua primeira aplicação test driven escrita em C++!
PS.: se você esta utilizando o Makefile que escrevi, lembre que o código da aplicação deve ficar no diretório src e o código de testes no diretório test.
PS2.: O exemplo foi testado em um linux com o CppUnit instalado pelo gerenciador de pacotes, se você quiser instalar o cppunit usando o código fonte ou for executar em outra plataforma lembre-se de atualizar o CFLAGS com os caminhos de influde corretos e o LFLAGS com o caminho da biblioteca do cppunit, se você não esta utilizando o g++ como compilador e linker, lembre-se de atualizar as variáveis CC e LINK.

Tags: , , , ,

08 Jun 08 Orientação a objetos é fácil, as pessoas é que complicam

A idéia de escrever este post veio desta discussão no GUJ, que começou falando de testes unitários e terminou sobre orientação a objetos.
Então seguem as minhas opiniões.


As linguagens de programação mais modernas, ou pelo menos as mais utilizadas de hoje em dia são Orientadas a Objeto, as famosas linguagens OO, mas mesmo assim, a grande maior parte dos desenvolvedores parece não conseguir entender direito a tal da Orientação a Objeto.
Resolvi escrever este este post porque do alto do meu ego inflado, acredito conseguir entender corretamente OO e poder ajudar um pouco.
Então, leiam o post até o final, e depois se quiserem tirar dúvidas ou me xingar, é só deixar um comentário …

O primeiro erro que todos cometem ao iniciar em OO é achar que Orientação a Objetos é sobre classes, isto não faz nenhum sentido, Orientação a Objetos como o próprio nome diz, é sobre Objetos, então, qualquer coisa que não seja um objeto não é realmente importante quando se fala em Orientação a Objetos.
OK, mas por que todos caem no mesmo engano então? porque a grande maior parte das linguagens de programação orientadas a objeto, utilizam classes como moldes para objetos, e durante o desenvolvimento se cria os moldes, ja que os objetos só existem em tempo de execução nestas linguagens.
Quais linguagens não funcionam assim? Bom, agora me vem a cabeça SmallTalk, IO e Ruby, mas devem ter outras.
SmallTalk porque não existe realmente distinção entre “tempo de desenvolvimento” e “tempo de execução” em SmallTalk, tudo esta sempre executando.
IO porque não utiliza o conceiro de classes (a não ser que eu tenha entendido a linguagem errado) e sim objetos template.
E Ruby porque as classes em Ruby são objetos também, mas das três é a que mais se aproxima do “padrão” que citei antes.

Outro erro bastante comum, desta vez quando se utiliza alguma tecnologia de mapeamento Objeto/Relacional, é achar que objetos são tabelas, mapeamento Objeto/Relacional serve para salvar o estado de um objeto em um banco de dados relacional, apenas isto, um objeto do tipo Usuario por exemplo, não possui um atributo “grupo_id”, mas pode possuir um relacionamento com um objeto do tipo Grupo. Percebam que eu escrevi atributo e não campo, pois tabelas tem campos e linhas, objetos possuem atributos e métodos.

Uma coisa bastante comum, ainda utilizando mapeamento O/R é achar que um objeto possui os mesmos atributos que a tabela correspondente, mas neste caso até os nomes são diferentes, infelizmente nestes casos, um objeto precisa ter um atributo “id” que mapeia para a chave primária da tabela, mas um objeto não tem uma chave primária, ele tem apenas atributos.

Então, como solucionar estes problemas?
Bom, no geral, um objeto tem comportamento, e alguns atributos também, mas o importante em um objeto é o que ele faz e como ele faz.
Claro que existem objetos que não tem comportamento, objetos em um sistema são a representação binária de alguma coisa do mundo real, e existem coisas no mundo real que não tem comportamento, tem apenas atributos, como por exemplo mesas e cadeiras, mas exceto se você estiver mapeando um destes objetos no seu sistema, todos os objetos tem um comportamento.
Por exemplo, se você criar um objeto do tipo Usuário, se ele não possuir nenhum comportamento, com certeza o seu sistema esta construído de forma errada, pois pelo menos eu, não conheço nenhum usuário que fique parado como uma estátua o tempo todo, e se este for o caso, com certeza ele não é usuário de sistema nenhum, portanto ele não deveria existir no seu sistema.
A mesma coisa se aplica a um carro, você conhece algum carro que não se move? Que não tenha comportamento algum? A única desculpa para um carro que não tem comportamento algum é um sistema para um museu de carros, onde só importa a carcaça do carro e os atributos dele, principalmente o ano de fabricação.

Outra coisa que todos entendem errado é o padrão MVC (Model, View, Controller).
Na definição do padrão, o controlador esta la apenas como ponto de entrada, ele passa parâmetros para um método de um Model, pega o resultado disto e passa para uma View, se ele estiver fazendo mais do que isto, ele possui parte do código que deveria estar dentro do Model, por tanto, o seu Controller esta errado!

Beleza, mas se eu estou dizendo que todos cometem os mesmos erros, como eu posso dizer que OO é fácil então?
Porque a maioria aprende primeiro a programar de forma estrutural, e depois passa para orientação a objetos, e como as pessoas aprendem coisas novas utilizando como base suas experiências anteriores, utilizam os paradigmas procedurais para tentar programar orientado a objetos, esta é basicamente a raiz do problema.
Para tornar a vida de todos mais fácil, o primeiro contato com programação nos cursos e faculdades deveria ser com SmallTalk e não com portugol ou pascal.
Se você aprender primeiro orientação a objetos, conseguira passar para programação procedural com uma facilidade muito maior do que alguem que aprende primeiro programação procedural tentando aprender orientação a objetos.

O pior é que as linguagens de programação que não são 100% OO contribuem ainda mais para aumentar este problema, vamos pegar o Java como exemplo de uma linguagem não 100% OO.
“Mas me disseram que java era uma linguagem de programação OO”
Bom isto também é verdade, eu disse não 100% OO, não disse que não era OO.
Exemplos de coisas que não são OO em Java: tipos primitivos e métodos estáticos
Basicamente eu acho que na linguagem é só isto que não é OO, mas isto ja causa problemas o suficiente confundindo a cabeça de muita gente.
“Perai, métodos estáticos ficam dentro de classes, como podem não ser OO?”
Mérodos estáticos são uma forma porca de programação procedural dentro de uma linguagem OO que teve uma linguagem procedural como origem, como por exemplo o Java e o C++.
Métodos estáticos não fazem parte de uma classe, utilizam a classe apenas como namespace, o que é diferente de fazer parte.
Em um método estático, não é possível nem saber a qual classe ele pertence, como é possível tanto em object pascal quanto em Ruby, ja que estas não possuem métodos estáticos e sim métodos de classe.
E os tipos primitivos estes sim, não tem relação nenhuma com orientação a objetos, só estão la porque quando a linguagem foi criada não era possível fazer uma classe ter a mesma performance do que um tipo mapeado diretamente do processador da máquina, eles existem em Java por problemas de performance e não por serem Orientados a Objeto.

Alguns design patterns foram criados apenas para contornar limitações da pataforma (Exemplo prático, com um banco de dados OO decente não seria necessário criar o pattern DTO), da mesma forma algumas das regras sobre a utilização de OO foram criadas apenas porque a maioria das pessoas não entende OO, como a regra que diz favoreça composição em vez de herança.
Este é um engano terrível cometido por muitas pessoas que eu não consigo entender.
Muita gente acha que estender uma classe é uma forma de compartilhar código, por exemplo:
Existe uma entidade no sistema de nome Cliente, e em algum momento é necessário criar um ClienteDependente que vai possuir todos os mesmos atributos de cliente mais um que aponta para o responsável, não faz sentido algum fazer ClienteDependente estender Cliente para compartilhar este código, porque o comportamento deles não é o mesmo, por exemplo, ClienteDependente não paga a conta, mas Cliente sim, neste caso seria melhor refatorar o sistema e criar uma entidade que pudesse realizar compras (Ou criar objetos do tipo Compra se o sistema foi bem modelado), e fazer com que Cliente e ClienteDependente estendessem desta, pois neste caso elas estariam realmente compartilhando o comportamento e não apenas evitando algum código aparentemente repetido.
Estender uma classe é estender o comportamento, ou seja, só faz sentido estender o comportamento se a classe “filha” tiver todo o comportamento da classe “pai”, ou seja, é um relacionamento o tipo “é um”. Mas como quase ninguém consegue entender que estender uma classe estende o comportamento (não me parece uma coisa tão complexa assim para se entender), foi criada esta regra que diz: Não use herança, use composição. Simplesmente para evitar que pessoas façam porcaria por não entender conceitos que são estupidamente simples, mas que todos tem mania de complicar.

Outro erro bastante comum é tentar colocar em uma classe apenas o comportamento de todo o sistema, se for para fazer isto, utilize programação procedural, pois você vai estar utilizando a classe apenas como namespace mesmo, não vai nem lembrar que em tempo de execução estara trabalhando com diversos objetos criados a partir daquela forma.

Orientação a objetos é simples, é um paradigma de desenvolvimento que modela um sistema transformando conceitos do mundo real como objetos que colaboram entre si para atingir um objetivo.
Acho que o nome Objeto pode ajudar a confundir boa parte das pessoas, pois em um sistema OO, Compra pode ser um tipo de Objetos, mas no mundo real, compra não é um objeto. Mas para resolver isto eu simplesmente assumo que qualquer um que queira ser um programador precisa ter capacidade para trabalhar com abstrações, não tenho uma explicação melhor para alguem que não consegue entender que Compra pode ser um tipo de Objeto em um sistema OO, assim como Viajem também pode ser um tipo de Objeto (estou utilizando “Tipo de Objeto” em vez de classe porque o que importa em um sistema OO são as instâncias e não as classes) dependendo do problema a ser resolvido.

Acho que são estes os erros mais comuns na orientação a objetos, lendo isto você não concorda comigo? OO é simples, as pessoas é que complicam!
Você lembra de algum outro erro muito comum em OO? deixe um comentário.
Se eu lembrar de mais coisas simples que as pessoas tem mania de complicar eu escrevo outro post.

Tags: ,

24 Mar 08 Pare de perder tempo escrevendo documentação do código que você escreveu (parte 1)

time_graphic.jpg

Não, eu não estou completamente louco, e não acho que documentação para o código escrito seja uma coisa completamente inútil.
Mas eu acredito que documentação desatualizada é pior do que nenhuma documentação …
E não estou incentivando a escrita de código completamente sem documentação …
E por último, só para constar, eu estou falando de documentação da regra de negócio implementada e não o manual do usuário …

Ok, mas como deixar de perder tempo escrevendo a tal da documentação?
A solução que me vem a cabeça é BDD, ou seja, Behavior Driven Development, junto com a tão falada, documentação executável …

Mas isto existe?
Sim existe, e o pessoal doRuby On Rails já esta bastante acostumado com isto, utilizando o RSpec.
Mas este post não é sobre Ruby On Rails e nem sobre RSpec, e sim sobre o Easyb, que é uma biblioteca para escrita de “Documentação Executável” utilizando Groovy, muito fácil de utilizar para testar código Java …

Para começar com a brincadeira, vou ir ao site do projeto e fazer o download do último release (atualmente 0.7)
criar um projeto java novo no eclipse.
criar uma pasta de nome lib e copiar os seguintes jars para a pasta:commons-cli-1.1.jar easyb-0.7.3.jar groovy-all-1.5.0.jar (todos vem no zip do easyb)
criar mais uma source folder de nome behavior
(O meu eclipse esta com o plugin para edição de código groovy instalado)

Crio um build.xml para executar os testes (ainda não existe um plugin para o eclipse, mas sinceramente, não achei necessário)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<?xml version="1.0" encoding="UTF-8"?>
<project name="project" default="run_tests">
	<path id="all.path">
		<pathelement location="${basedir}/bin" />
		<pathelement location="${basedir}/bin-groovy" />
		<fileset dir="${basedir}/lib" includes="**/*.jar" />
	</path>
	<taskdef name="easyb" classname="org.disco.easyb.ant.BehaviorRunnerTask" classpathref="all.path" />
	<!-- ================================= 
          target: default              
         ================================= -->
	<target name="run_tests" description="--> description">
		<easyb failureProperty="easyb.failed">
			<classpath>
				<path refid="all.path" />
			</classpath>
			<behaviors dir="${basedir}/behavior">
				<include name="**/*Story.groovy" />
				<include name="**/*Specification.groovy" />
			</behaviors>
			<report location="story.txt" format="txtstory" />
			<report location="behavior.txt" format="txtbehavior" />
			<report location="easyb.xml" format="xmleasyb" />
		</easyb>
	</target>
</project>

Este build.xml declara a tag do easyb e executa todos os testes, alem de gerar os relatórios, que vocês vão gostar bastante …
Os tipos de relatórios variam bastante de acordo com a versão do easyb, a equipe de desenvolvimento esta melhorando bastante isto, eu estou utilizando aqui a versão do trunk do subversion, se quiserem baixar a mesma versão que uso aqui, podem baixar via git deste repositório : git clone git://github.com/urubatan/easyb.git
(Eu fiz um fork do projeto para adicioar algumas features, e ja estou enviando os patches para os desenvolvedores)

Agora vamos começar a brincadeira :D
Dentro do diretório behavior vou criar um diretório de nome users e um arquivo de nome PermitirRegistroDeUsuariosStory.groovy dentro deste último.
Ou seja, este arquivo vai conter os testes, e a documentação das regras de negócio sobre a criação de novos usuários no sistema …

Quero ter uma breve descrição da história nos meus relatórios, então adiciono uma tag description no inicio do arquivo (esta tag por enquanto só existe no meu fork).

1
2
3
description """Qualquer novo visitante do site deve poder se registrar no sistema, 
desde que as regras de validação definidas sejam atendidas.
Um usuário registrado podera alterar a sua senha sempre que desejar, mas a senha devera atender aos padrões minimos de segurança"""

As histórias são compostas basicamente de 4 comandos:
scenario – define um cenário da história, ou seja, um bloco contendo os outros 3 comandos
given – define a situação inicial
when – define um gatilho, uma ação do usuário que ira disparar alguma ação do sistema, este comando é opcional
then – define o que o sistema deve fazer, e o que vai ser testado

alem destes existe o “and” que atualmente é um comando que não executa nada, serve apenas para deixar o código mais legivel, mas isto vai mudar na próxima versão, o and vai repetir o comando anterior, semelhante ao que acontece no RSpec.

Conhecendo estes comandos podemos começar a escrever a nossa documentação :D
Vou adicionar alguns cenários a minha história e alguns detalhes.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
scenario "Um novo usuário precisa confirmar a senha", {
	given "Um novo usuário", {
	}
	when "O usuário preenche o nome de usuário e a senha, mas sem confirmar a mesma", {
	}
	then "A validação do usuário deve falhar", {
	}
	when "O usuário preenche o nome de usuário e confirma a senha corretamente", {
	}
	then "A validação do usuário deve passar",{
	}
}
scenario "Um nome de usuário deve ser único no sistema", {
	given "Um usuário com o formulário preenchido corretamente", {
	}
	then "O registro deve criar o usuário no sistema", {
	}
	when "O nome de usuário ja existe no sistema", {
	}
	then "O registro do usuário deve falhar",{
	}
}
}

Com isto, podemos ver no diretório do projeto os seguintes arquivos criados:
behavior.txt que até o momento esta em branco

story.txt que contem o seguinte texto:

  Story: permitir registro de usuarios
    Qualquer novo visitante do site deve poder se registrar no sistema,
desde que as regras de validação definidas sejam atendidas.
Um usuário registrado podera alterar a sua senha sempre que desejar, mas a senha devera atender aos padrões minimos de segurança

    scenario Um novo usuário precisa confirmar a senha
      given Um novo usuário
      when O usuário preenche o nome de usuário e a senha, mas sem confirmar a mesma
      then A validação do usuário deve falhar
      when O usuário preenche o nome de usuário e confirma a senha corretamente
      then A validação do usuário deve passar

    scenario Um nome de usuário deve ser único no sistema
      given Um usuário com o formulário preenchido corretamente
      then O registro deve criar o usuário no sistema
      when O nome de usuário ja existe no sistema
      then O registro do usuário deve falhar

e easyb.xml que contem uma versão XML dos dois relatórios combinados …
Se você prestar atenção no story.txt, substituindo as palavras em ingles que fazem parte da DSL do easyb, por palavras em portugues, esta é uma ótima documentação para ser validada com o cliente, e com a garantia de que não vai ficar desatualizada por que este é o código fonte dos testes, por tanto sera alterado sempre que a regra de negócio for alterada …

Como assim?
Vamos seguir trabalhando no sistema, agora que ja temos o “behavior”, ou seja, o comportamento definido, vou adicionar algum código a esta história que devera ser testada sempre junto com o build automatizado do sistema:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
package users;
 
description """Qualquer novo visitante do site deve poder se registrar no sistema, 
desde que as regras de validação definidas sejam atendidas.
Um usuário registrado podera alterar a sua senha sempre que desejar, mas a senha devera atender aos padrões minimos de segurança"""
 
scenario "Um novo usuário precisa confirmar a senha", {
	given "Um novo usuário", {
		user = new User()
	}
	when "O usuário preenche o nome de usuário e a senha, mas sem confirmar a mesma", {
		user.setName "validName"
		user.setPassword "aPassword"
	}
	then "A validação do usuário deve falhar", {
		ensureThrows(PasswordValidationException){
			user.validate()
		}
	}
	when "O usuário preenche o nome de usuário e confirma a senha corretamente", {
		user.setName "validName"
		user.setPassword "aPassword"
		user.setPasswordConfirmation "aPassword"
	}
	then "A validação do usuário deve passar",{
		user.validate()
	}
}
scenario "Um nome de usuário deve ser único no sistema", {
	given "Um usuário com o formulário preenchido corretamente", {
		user = new User('userName','password','password')
		userManager = UserManager.getInstance()
	}
	then "O registro deve criar o usuário no sistema", {
		userManager.create(user)
	}
	when "O nome de usuário ja existe no sistema", {
		user = new User('userName','otherPassword','otherPassword')
	}
	then "O registro do usuário deve falhar",{
		ensureThrows(UserAlreadyExistsException){
			userManager.create(user)
		}
	}
}

Pronto, este é todo o código desta história, e foi apenas o que eu escrevi até agora.
Agora preciso criar as classes User, UserManager e implementar os métodos corretamente, para que os testes passem., por que no momento os testes não estão nem rodando, ja que estas classes não existem ainda …

Criada a classe User:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
package users;
 
public class User {
	private String name;
	private String password;
	private String passwordConfirmation;
 
	public User() {
		super();
	}
 
	public User(String name, String password, String passwordConfirmation) {
		super();
		this.name = name;
		this.password = password;
		this.passwordConfirmation = passwordConfirmation;
	}
 
	public String getName() {
		return name;
	}
 
	public void setName(String userName) {
		this.name = userName;
	}
 
	public String getPassword() {
		return password;
	}
 
	public void setPassword(String password) {
		this.password = password;
	}
 
	public String getPasswordConfirmation() {
		return passwordConfirmation;
	}
 
	public void setPasswordConfirmation(String passwordConfirmation) {
		this.passwordConfirmation = passwordConfirmation;
	}
 
	public void validate() {
		throw new RuntimeException();
	}
}

E a classe UserManager:

1
2
3
4
5
6
7
8
9
10
11
package users;
 
public class UserManager {
	private static UserManager instance = new UserManager();
	public static UserManager getInstance(){
		return instance;
	}
	public void create(User user){
		throw new RuntimeException();
	}
}

Os testes agora executam mas falham.

Implementando corretamente o método “validate” da classe User, ja temos 2 testes passando:

1
2
3
4
	public void validate() throws PasswordValidationException {
		if(password==null || passwordConfirmation==null || !password.equals(passwordConfirmation))
			throw new PasswordValidationException();
	}

E agora, finalizando a implementação do método create da classe UserManager.

1
2
3
4
5
6
7
8
	public void create(User user) throws InvalidUserException, PasswordValidationException, UserAlreadyExistsException{
		if(user==null)
			throw new InvalidUserException();
		user.validate();
		if(users.containsKey(user.getName()))
			throw new UserAlreadyExistsException();
		users.put(user.getName(), user);
	}

Todos os testes passam, e o nosso código funciona perfeitamente.

Claro que a DSL do easyb é bem mais completa que isto, é possível testar apenas a especificação de uma classe em vez de uma história completa (eu uso histórias para as regras de negócio importantes para o cliente, e especificações para classes internas do sistema), existem diversos “ensure” para validar o estado desejado, tudo isto vocês podem ver na página do projeto: http://www.easyb.org

E como eu falei antes, este é o código dos testes do sistema, desta forma, quando o usuário solicitar uma alteração, se altera o teste, depois se altera o código.
Quando o seu chefe pedir para você documentar o código escrito até agora, você executa os testes, e copia os txts gerados e envia para ele por e-mail.
Os testes você seria obrigado a escrever de qualquer forma, ja que acredito eu que se você leu até aqui, você acredita que testes de código são importantes.
Como você iria escrever os testes de qualquer forma, agora você precisa fazer uma coisa a menos, que é documentar aquilo que escreveu, por que algum dia você vai querer tirar férias, e outro desenvolvedor vai precisar alterar o código que você escreveu :D

Depois de ler até aqui, o que você acha do easyb?
O que você acha de Behavior Driven Development?
Você concorda comigo, quando digo que o easyb tornou possível BDD em Java? (Sim eu sei que existe o JBehave, mas eu acho o trabalhoso demais, e sei que é possível trabalhar com BDD utilizando qualquer xUnit, mas ai eu perco muito da vantagem da documentação executável)
Você vai pelo menos testar isto no seu próximo projeto?

Eu estou escrevendo alguns pequenos patches e enviando para eles sempre que sinto falta de alguma coisa, e fora isto o projeto vai ter diversas melhorias bastante significativas em pouco tempo!
Parabens aos desenvolvedores, e viva o Groovy, tornando o desenvolvimento Java mais divertido e menos trabalhoso!

Tags: , ,

04 Sep 07 Gravando ScreenCasts no Linux(Ubuntu/Kubuntu)! E rodando em qualquer PC ou disponibilizando via WEB.

Bom, tem bastante gente que quer criar ScreenCasts no linux mas tem não faz a menor idéia de como fazer isto, segue um passo a passo para fazer isto no Ubuntu/Kubuntu!
E vocês vão ver que nem são tantos passos assim :D

ffmpeg-logo.png flv-75.jpg
logo-name.png tux-director-t2.gif
  1. para instalar os comandos que utilizaremos utilize o seguinte comando
  2. $sudo apt-get install gtk-recordmydesktop mplayer mencoder ffmpeg
  3. para gravar o screencast, basta abrir o gtk-recordmydesktop e seguir as informações na tela
  4. O video gravado se estiver muito grande (resolução alta da tela, como no meu caso 1280×800), apenas o mplayer vai conseguir reproduzir, parece que o theora tem problemas para gerenciar memória
  5. O video gerado estara no formato Ogg Theora, que apenas funciona em linux, e tem 1 encoder para windows, então vamos transformalo em algo utilizável
  6. $mencoder [arquivo].ogg -o [arquivo].avi -ovc lavc -oac lavc
  7. Pronto, agora possuímos um video que poe ser visualizado em qualquer plataforma :D
  8. Quer ainda colocar ele na web como um screencast? como o deste post?
  9. $ffmpeg -i [arquivo].avi [arquivo].flv
  10. pronto, agora possuímos um video em flash, falta só o player

Se você trabalha com flash pode fazer um quando quiser, acredito que não seja complexo, como este não é o meu caso, este player open source faz o trabalho muito bem! JW FLV Player

Prontinho, ja pode encher o seu site de screencasts :D

Acho que este foi o passo a masso mais simples e direto para criaçao de screencasts no linux que eu ja vi até gora :D

Tags: , ,

16 Aug 07 Implementando Login com Ruby on Rails (exemplo simples)

Bom, ja que fui criticado por “incentivar a utilização de JSF”, vou fazer mais alguns pequenos tutoriais de como implementar um login com outros frameworks, e este sim é para incentivar a utilização, ja que estou gostando bastante do Ruby On Rails :D

Antes de comparar os dois exemplos, lembre-se de que o Ruby On Rails te da uma estrutura pronta de aplicação, por tanto não vou precisar mostrar como configurar a base de uma aplicação como foi feito no outro exemplo

Comecemos criando uma aplicação Ruby On Rails:

$rails nomeDaAplicação

Depois, vamos criar um controller para a autenticação:

$script/generate controller login login

Isto vai criar um controller de nome login, e uma view de nome login também.

O código do login_controller.rb vai ficar mais ou menos assim:

class LoginController < ApplicationController
def index
render :action => 'login'
end
def login
end
def do_login
username = params[:username]
password = params[:password]
if username.nil? || password.nil? || username==password
redirect_to :action => "login"
flash[:notice] = 'Usuário ou senha incorretos'
else
session["user_id"] = username
redirect_to :controller => "secure", :action => "index"
end
end
end

Basicamente o controller tem implementado apenas o método do_login, que vai fazer uma validação bem complexa, de o usuário e a senha terem sido fornecidos e não serem iguais, você pode adaptar isto a sua aplicação mais tarde …

A view de login, vai ficar assim:

<% form_tag :action => 'do_login' do %>
<table align="center" class="loginForm">
<tr>
<td>
<%= image_tag "botao_login.png" %>
</td>
<td>
<input type="text" name="username"/>
</td>
</tr>
<tr>
<td>
<%= image_tag "botao_senha.png" %>
</td>
<td>
<input type="password" name="password" />
</td>
</tr>
<tr>
<td colspan="2">
<%= image_submit_tag "box_avancar.png", :style => 'width:75px;height:25px;' %>
</td>
</tr>
<table>
<% end %>

É uma view simples, apenas com um formulário e dois campos …

Ok, beleza, e como é que eu uso isto?

Vamos começar alterando application.rb, o código vai ficar assim:

class ApplicationController < ActionController::Base
# Pick a unique cookie name to distinguish our session data from others'
session :session_key => '_untitled6_session_id'
before_filter :authorize
protected
# Override in controller classes that should require authentication
def secure?
false
end
private
def authorize
if secure? && session["user_id"].nil?
session["return_to"] = request.request_uri
redirect_to :controller => "login", :action => "login"
return false
end
end
end

O que fizemos foi adicionar um filter a todos os métodos de todos os controllers, que vai interceptar a chamada a todos os métodos, e por padrão não vai fazer nada (o método secure? retorna false por padrão), caso o controller sobreescreva este método e faça-o retornar true, o filtro vai verificar se existe um user_id na sessão, se existir segue o processamento normal, caso contrário redireciona para o login.

E como utilizamos isto? vamos fazer um exemplo de um controller que vai precisar de segurança …

$script/generate controller seguro index

Para gerar um controller de nome seguro, e com uma ação de nome index.

Agora vamos alterar o código do securo_controller.rb

class SeguroController < ApplicationController
def index
end
protected
def secure?
true
end
end

Sobre escrevendo o método secure? para retornar true, fizemos com que todos os métodos deste controller precisem de autenticação para permitir o acesso.

E se quisermos que apenas alguns métodos precisem de autenticação?

Podemos utilizar algo parecido com este código:

protected
def secure?
["metodoSegro","outroMetodoSeguro"].include?(action_name)
end

Tudo pronto, login implementado …

Mas como no exemplo com JSF, ainda podemos melhorar esta implementação, por exemplo, armazenando na sessão os grupos do usuário para poder fazer uma melhor verificação dentro dos métodos …

Outra possível melhoria, seria aproveitar o atributo: session["return_to"] dentro do método do_login para redirecionar o usuário para a URL que ele tentou acessar originalmente ...

E como no último post, deixo algumas perguntas para vocês:

  1. Quais outras possíveis melhorias vocês vêem neste exemplo?
  2. Quais problemas vocês vêem nesta implementação?

Para quem estiver interessado em mais detalhes sobre Ruby On Rails, podem dar uma olhada no tutorial que eu traduzi:

Quatro dias de Ruby On Rails – Primeiro dia, Quatro dias de Ruby On Rails – Segundo dia,

Quatro dias de Ruby On Rails – Terceiro Dia, Quatro dias de Ruby On Rails – Quarto Dia

A próxima implementação de login, acho que vai ser com o Wicket, até para eu aprender um pouco sobre ele :D (seufagner, não se anima a escrever este para postar aqui?)

Tags: ,

14 Aug 07 Implementando Login com JSF (exemplo simples)

English Version Here

Bom, uma das perguntas mais frequentes de quem esta começando a estudar JSF é como implementar um Login, e esta foi uma das perguntas mais frequentes que vi no GUJ e em comentários aqui no blog também …

Antes de começar, quem quiser usar JSF com JPA é só dar uma olhada neste post que escrevi a algum tempo.

Agora vamos dar uma olhada rápida em algumas formas de implementar login com JSF.

A primeira abordagem é uma implementação manual, que nesta versão só verifica se o usuário ja esta logado, mas é possível estende-la facilmente para utilizar grupos.

Primeiro vamos começar com a configuração do web.xml …

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5">
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<error-page>
<exception-type>java.lang.SecurityException</exception-type>
<location>/login.jsf</location>
</error-page>
</web-app>

Como podem ver, eu criei uma aplicação WEB com servlets 2.5, estou utilizando JSF 1.2, mas para este exemplo a versão não faz muita diferença, e configurei o servlet container para que no caso de uma java.lang.SecurityException ele redireccione para a página de login da aplicação.

Depois disto, vamos começar a escrever alguns beans, vou utilizar dois beans simples, um para gerenciar o login:

package br.com.urubatan.jsfjpasec;
public class Login {
private boolean loginOk;
private String userName;
private String password;
public boolean isLoginOk() {
return loginOk;
}
public String getUserName() {
return userName;
}
public void setUserName(String userName) {
this.userName = userName;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
public String validateLogin(){
if(userName!=null && password!=null && !userName.equalsIgnoreCase(password)){
loginOk = true;
return "secpage";
}else return "login";
}
}

É uma classe bastante simples, ele tem 3 propriedades, o nome e senha do usuário, e uma propriedade dizendo que o login esta OK, este é o ponto de extensão para adicionar suporte a grupos mais tarde se quiserem.

E este bean que vai conter todos os dados da aplicação (neste exemplo, dados estáticos), ele tem duas propriedades que possuem dados estáticos apenas para este exemplo, se quiserem utilizar JPA basta misturar com este exemplo ou com um destes.

package br.com.urubatan.jsfjpasec;
import java.util.List;
import java.util.ArrayList;
public class SomeData {
private List<String> data = new ArrayList<String>();
private List<String> securedData = new ArrayList<String>();
private boolean loginOk;
public SomeData() {
for(int i=0;i<10;i++){
data.add("Dados Simples " + i);
securedData.add("Dados Seguros " + i);
}
}
public void setLoginOk(boolean loginOk) {
this.loginOk = loginOk;
}
public List<String> getSecuredData() {
if(!loginOk)
throw new SecurityException();
return securedData;
}
public List<String> getData() {
return data;
}
}

Como podemos ver, ele possui apenas os getters dos dados, e o método de leitura dos dados seguros, verifica a propriedade loginOk que deve ter sido fornecida pelo bean de login, vamos configurar isto no faces-config.xml a seguir.

Caso o usuário não tenha se identificado ainda, apenas geramos uma SecurityException e o container cuida de mandar isto para a página de login, como foi configurado no web.xml.

Agora um pouco mais de XML, vamos configurar os navigation cases necessários para a aplicação e os relacionamentos entre os beans ja criados, no caso, configurar a propriedade loginOk do bean de dados com a mesma propriedade do bean de login.

<?xml version='1.0' encoding='UTF-8'?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"
version="1.2">
<managed-bean>
<managed-bean-name>login</managed-bean-name>
<managed-bean-class>br.com.urubatan.jsfjpasec.Login</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
<managed-bean>
<managed-bean-name>mdata</managed-bean-name>
<managed-bean-class>br.com.urubatan.jsfjpasec.SomeData</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>loginOk</property-name>
<property-class>java.lang.Boolean</property-class>
<value>#{login.loginOk}</value>
</managed-property>
</managed-bean>
<navigation-rule>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>
login
</from-outcome>
<to-view-id>
/login.jsp
</to-view-id>
<redirect/>
</navigation-case>
<navigation-case>
<from-outcome>
secpage
</from-outcome>
<to-view-id>
/secureView.jsp
</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>
</faces-config>

Os casos de navegação nesta aplicação bastante complexa são utilizados apenas pelo bean de login, no método que valida o login (baita validação, apenas verifica se foram informados um nome e uma senha e se os dois não são iguais, mas este é outro problema :D )

Com isto toda a lógica necessária para a aplicação esta pronta, falta apenas criarmos as páginas utilizadas, então segue o código delas:

login.jsp:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %>
<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core" %>
<html>
<head><title>System Login</title></head>
<body>
<f:view> <h:form>
<h:panelGrid columns="2">
<h:outputLabel value="User Name" for="un"/>
<h:inputText id="un" value="#{login.userName}"/>
<h:outputLabel value="Password" for="pw"/>
<h:inputText id="pw" value="#{login.password}"/>
</h:panelGrid>
<h:commandButton value="Login" action="#{login.validateLogin}"/>
</h:form>
</f:view>
</body>
</html>

Como podemos ver é apenas uma página JSF simples com um formulário e dois campos, chamando o método vaidateLogin de um bean de nome login.

dataView.jsp:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %>
<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core" %>
<html>
<head><title>Unsecured Data Page</title></head>
<body>
<f:view>
<h:dataTable value="#{mdata.data}" var="v">
<h:column>
<f:facet name="header">
<h:outputText value="Data List"/>
</f:facet>
<h:outputText value="#{v}"/>
</h:column>
</h:dataTable>
<h:panelGrid columns="3">
<h:outputLink value="dataView.jsf">
<h:outputText value="Data that every one can access"/>
</h:outputLink>
<h:outputLink value="secureView.jsf">
<h:outputText value="Data that you can view after login"/>
</h:outputLink>
<h:outputLink value="login.jsf">
<h:outputText value="Login"/>
</h:outputLink>
</h:panelGrid>
</f:view>
</body>
</html>

Como podemos ver também é uma página bem simples, com apenas uma dataTable listando os dados da propriedade data de um bean de nome mdata.

secureView.jsp:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %>
<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core" %>
<html>
<head><title>Secured Data Page</title></head>
<body>
<f:view>
<h:dataTable value="#{mdata.securedData}" var="v">
<h:column>
<f:facet name="header">
<h:outputText value="Data List"/>
</f:facet>
<h:outputText value="#{v}"/>
</h:column>
</h:dataTable>
<h:panelGrid columns="3">
<h:outputLink value="dataView.jsf">
<h:outputText value="Data that every one can access"/>
</h:outputLink>
<h:outputLink value="secureView.jsf">
<h:outputText value="Data that you can view after login"/>
</h:outputLink>
<h:outputLink value="login.jsf">
<h:outputText value="Login"/>
</h:outputLink>
</h:panelGrid>
</f:view>
</body>
</html>

Esta também é uma página simples, praticamente igual a anterior, mas desta vez, lendo a propriedade securedData do bean mdata, nesta propriedade o bean verifica se o usuário tem acesso, caso contrário gera uma excessão.

por último temos a página index.jsp que apenas possui um link para a página dataView.jsp:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head><title>Entry Page</title></head>
<body>Entry Page, this could redirect to the JSF Index, but for now, click here: <a href="dataView.jsf">JSF Index</a>
</body>
</html>

com isto temos uma implementação bem simples de um login em uma aplicação JSF, bom para quem esta começando a estudar a tecnologia.

Como melhorias poderíamos mudar a propriedade loginOk para um Map<String,Boolean> tendo como chave os nomes dos possíveis grupos e como valores veradeiro se o usuário pertence aquele grupo.

Outra melhoria interessante seria utilizar um h:inputSecret para a senha em vez de um inputText como estou utilizando no exemplo.

Outra possível melhoria seria utilizar uma combinação de anotações e AOP como esta implementado no Spring-Annotations. (se quiserem posso postar outro dia um exemplo de implementação de segurança com o SA).

Uma outra possível alteração seria utilizar JAAS para a segurança declarativa e deixar isto por conta do container.

Agora algumas perguntas para vocês:

  1. Quais outras possíveis melhorias vocês vêem neste exemplo?
  2. Quais problemas vocês vêem nesta implementação?
  3. Vocês gostariam de outros exemplos deste estilo aqui no blog?
  4. Vocês já estão utilizando JSF?

Acho que era isto, espero que o exemplo seja útil para alguém :D

PS.: para os que forem rodar a aplicação, são necessários apenas os jars: jstl.jar, jsf-api.jar e jsf-impl.jar (se forem utilizar a JSF-RI como eu).

Tags: , ,

11 Aug 07 O filtro do tato (por que nerds/geeks tem problemas de relacionamento com outras pessoas)

Bom, eu sou um exemplo vivo, pelo menos eu acho que sim, de que nerds, geeks ou como preferirem ser chamados, tem problemas no trato com outras pessoas.
Sempre acham que eu sou direto demais, ou que sou grosso, ou qualquer coisa do gênero.
Na verdade, eu concordo que sou direto demais, não com a parte de ser grosso.
Eu acredito que se eu penso alguma coisa, eu posso dizer aquilo, e azar é de quem estiver ouvindo, mas isto ja me trouxe muitos problemas.
Mesmo, pelo menos na minha opinião, eu sendo um dos melhores na parte técnica do que eu faço, eu acabo sempre me prejudicando por falar o que eu penso e outras pessoas não gostarem de ouvir isto, o que prejudica inclusive o crescimento profissional …
Eu ja tentei ser gerente de projetos, e tenho a consciência de que pelo menos por enquanto não seria um bom gerente …
Em empresas que eu trabalhei, ja houveram casos em que mesmo sabendo que eu tinha a resposta, colegas de trabalho evitavam perguntar alguma coisa para mim.

Bom, eu ja melhorei muito neste ponto, acho que hoje sou razoavelmente conhecido na “comunidade java” aqui no Brasil, e cheguei a ouvir de um gerente: Bahh, legal, não sabia que tu era “O Urubatan”.
Mas melhorei isto com muito custo, e não foi muito fácil …

Mas voltando ao assunto deste post, eu encontrei um texto excelente que explica muito bem, na minha opinião, por que a maioria dos Nerds tem problemas no relacionamento com outras pessoas “Não Nerd”.
O texto original é este: “Tact Filters“.

A baixo segue uma tradução livre deste excelente texto.


Filtros de tato

Todas as pessoas possuem um “filtro de tato”, que aplica um filtro de “trato social” em uma direção há tudo que passa por ele. A maioria das “pessoas normais” tem este filtro posicionado para filtrar tudo o que elas falam ou fazem. Então toda e qualquer coisa que as “pessoas normais” dizem, tem a quantidade ideal de “filtro para trato social” aplicado, antes de elas realmente falarem. Isto normalmte acontece por que quando eles estavam crescendo, os seus pais continuamente diziam para eles coisas como: “Se você não pode dizer algo de bom, não diga nada!”, ou então “Não diga este tipo de coisa, vai fazer com que eles se sintam mal!”.

“Nerds”, por outro lado, tem este filtro, aplicado na posição contrária, ou seja, tudo o que eles ouvem é filtrado. Então, qualquer coisa que qualquer um diz para eles, tem a quantidade adequada de “filtro social” aplicado quando eles ouvem. Isto normalmente é por que quando eles estavam crescendo, as outras crianças ficavam incomodando e dizendo coisas desagradáveis, e os seus pais diziam o tempo todo: “Eles estão dizendo estas coisas só por que eles estão com ciúmes”.

Quando “pessoas normais” conversam entre si, elas normalmente aplicam a quantidade apropriada de “tato social” para tudo o que eles dizem, e ninguém sai com os sentimentos feridos. Quando “Nerds” conversam entre si, eles normalmente aplicam a quantidade adequada de “tato social” a tudo o que eles ouvem, e ninguém sai com os sentimentos feridos. Entretanto, quando pessoas normais, falam com “Nerds”, os “Nerds” ficam frustrados com freqüência, por que as “pessoas normais” parecem estar sempre evitando de dizer o que eles realmente querem. E pior ainda, quando “Nerds” falam com “pessoas normais”, estas com freqüência saem com os sentimentos feridos, por que os nerds não aplicam o filtro ao que eles estão falando, esperando que o ouvinte o faça.

Então, os “nerds” precisam entender que as “pessoas normais”, precisam aplicar este filtro para tudo o que eles dizem, eles ficam desconfortáveis se eles não puderem fazer isto. “Pessoas normais” precisam entender que fora o fato de os nerds normalmente não possuirem “tato”, as coisas que eles dizem quase nunca devem ser tomadas como pessoais. Ambos os tipos de pessoas precisam ter uma quantidade extra de paciência quando estiverem lidando com alguém que possua o “filtro de tato” na direção oposta a sua.



Acho que este texto explica mais ou menos bem, os motivos destes “conflitos” entre os “nerds” e as outras pessoas.
É possível para um nerd amenizar bastante este problema, acho que na maior parte das situações eu ja melhorei muito, mas eu continuo achando irritante quando as pessoas ficam cuidando o que vão falar, ou até mesmo falando claramente algo diferente do que estão pensando apenas para não “ferir os sentimentos” de quem esta ouvindo.
As vezes eu até encaro isto como um pouco de hipocrisia.
Mas quem sou eu para querer mudar o mundo …Então, o que vocês acham deste texto, não é mais ou menos isto o que acontece? mesmo os motivos originais mudando bastante de uma pessoa para outra …
Eu acho que entender esta “teoria” tem me ajudado bastante, e um exercício de paciência de vez em quando ajuda muito também :D

O texto original é de autoria de: Jeff Bigler.
Todos os outros comentários e tradução são de minha autoria :D

Tags: , , ,

16 Jul 07 Quatro dias de Ruby On Rails – Quarto e último dia

Quatro dias de Ruby On Rails – Primeiro dia, Quatro dias de Ruby On Rails – Segundo dia,

Quatro dias de Ruby On Rails – Terceiro Dia

Vamos começar agora o quarto e último dia de nosso tutorial …

A tela de Notas

Claro que o Scaffold daentidade Notes, ja cria uma estrutura completa CRUD para as notas, mas não queremos que o usuário acesse isto diretamente.

Queremos poder linkar uma nota a uma tarefa ja existente.

E caso ja exista uma nota para esta tarefa, precisamos poder editar ou remove-la.

Primeiro, vamos dar uma olhada novamente na tela de edição de tarefas. Atualmente ela ja ajusta os botões caso exista ou não uma nota para esta tarefa.

<% @heading = "Edit To Do" %>
<%= error_messages_for 'item' %>
<%= start_form_tag :action => 'update', :id => @item %>
<table>
<%= render_partial "form" %>
<tr>
<td><b>Notes: </b></td>
<% if @item.note_id.nil? %>
<td>None</td>
<td><%= link_to_image "note", :controller => "notes", :action => "new", :id => @item.id %></td>
<% else %>
<td><%=h @item.note.more_notes %></td>
<td><%= link_to_image "edit_button", :controller => "notes", :action => "edit", :id => @item.note_id %></td>
<td><%= link_to_image "delete_button", {:controller => "notes", :action => "destroy", :id => @item.note_id }, :confirm => "Are you sure you want to delete this note?" %></td>
<% end %>
</tr>
</table>
<hr />
<%= submit_tag "Save" %>
<%= submit_tag "Cancel", {:type => 'button', :o nClick=>"parent.location='" + url_for( :action => 'list' ) + "'" } %>
<%= end_form_tag %>

A tela de edição de notas.

Editar uma nota é bastante fácil, segue o template:

<% @heading = "Edit Note" %>
<%= start_form_tag :action => 'update', :id => @note %>
<%= render_partial "form" %>
<%= submit_tag "Save" %>
<%= submit_tag "Cancel", {:type => 'button', :o nClick=>"parent.location='" + url_for( :controller => 'items', :action => 'list' ) + "'" } %>
<%= end_form_tag %>

E o Partial Correspondente:

<table>
<tr>
<td><label for="note_more_notes">More notes</label></td>
<td><%= text_area 'note', 'more_notes' %></td>
</tr>
</table>

Assim que o update ou destroy de uma nota é completado, precisamos voltar a tela de listagem de tarefas.

def update
@note = Note.find(params[:id])
if @note.update_attributes(params[:note])
flash[:notice] = 'Note was successfully updated.'
redirect_to :controller => 'items', :action => 'list'
else
render :action => 'edit'
end
end
def destroy
Note.find(params[:id]).destroy
redirect_to :controller => 'items', :action => 'list'
end

Lembrem-se que as regras de integridade referencial, ja definidas no model e estas vão garantir que caso removamos uma nota, as referencias para a mesma serão removidas automaticamente.

A tela de criação de Notas.

Criar uma nova nota é um pouco mais complicado. O que queremos fazer é:

  • Armazenar a nota na tabela notes.
  • Localizar o ID da nota recem criada.
  • Armazenar o ID da nota recem criada no campo note_id da tarefa associada.

Variáveis de sessão são uma ótima forma de armazenar valores entre telas, vamos utilizar esta abordagem para armazenar o ID da tarefa associada a nova nota.

Documentação: ActionController::Base

Primeiro, quando clicamos no link para criar uma nova nota, nos passamos o ID da tarefa associada:

app\views\items\edit.rhtml (excerpt)

<td><%= link_to_image "note", :controller => "notes", :action => "new", :id => @item.id %></td>

O método “new” no controller de notas armazena este ID na sessão:

app\controllers\notes_controller.rb (excerpt)

def new
@session[:item_id] = @params[:id]
@note = Note.new
end

O template de “New Notes” não tem nenhuma novidade:

<% @heading = "New Note" %>
<%= start_form_tag :action => 'create' %>
<%= render_partial "form" %>
<%= submit_tag "Save" %>
<%= submit_tag "Cancel", {:type => 'button', :o nClick=>"parent.location='" + url_for(:controller => 'items', :action => 'list' ) + "'" } %>
<%= end_form_tag %>

O método “create” pega o ID novamente da sessão, utiliza o mesmo para buscar a tarefa do banco e atualizar o campo “note_id” na tabela items, e novamente redireciona a tela para a listagem de tarefas.

app\controllers\notes_controller.rb (excerpt)

def create
@note = Note.new(@params[:note])
if @note.save
flash['notice'] = 'Note was successfully created.'
@item = Item.find(@session[:item_id])
@item.update_attribute(:note_id, @note.id)
redirect_to :controller => 'items', :action => 'list'
else
render_action 'new'
end
end

Algumas alterações na tela de categorias.

Não sobrou muita coisa para fazer no sistema agora, alem de pequenos ajustes nas telas criadas no primeiro dia para que tenham o mesmo esquema de navegação por botões.

app\views\categories\list.rhtml

<% @heading = "Categories" %>
<form action="/categories/new" method="post">
<table>
<tr>
<th>Category</th>
<th>Created</th>
<th>Updated</th>
</tr>
<% for category in @categories %>
<tr>
<td><%=h category["category"] %></td>
<td><%= category["created_on"].strftime("%I:%M %p %d-%b-%y") %></td>
<td><%= category["updated_on"].strftime("%I:%M %p %d-%b-%y") %></td>
<td><%= link_to_image 'edit', { :action => 'edit', :id => category.id } %></td>
<td><%= link_to_image 'delete', { :action => 'destroy', :id => category.id },:confirm => 'Are you sure you want to delete this category?' %></td>
</tr>
<% end %>
</table>
<hr />
<input type="submit" value="New Category..." />
<input type="button" value="To Dos" onClick="parent.location='<%= url_for(:controller => 'items', :action => 'list' ) %>'">
</form>

app\views\categories\new.rhtml

<% @heading = "Add new Category" %>
<%= error_messages_for 'category' %>
<%= start_form_tag :action => 'create' %>
<%= render_partial "form" %>
<hr />
<input type="submit" value="Save" />
<input type="button" value="Cancel" onClick="parent.location='<%= url_for( :action=> 'list' ) %>'">
<%= end_form_tag %>

app\views\categories\edit.rhtml

<% @heading = "Rename Category" %>
<%= error_messages_for 'category' %>
<%= start_form_tag :action => 'update', :id => @category %>
<%= render_partial "form" %>
<hr />
<input type="submit" value="Update" />
<input type="button" value="Cancel" onClick="parent.location='<%= url_for( :action=> 'list' ) %>'">
<%= end_form_tag %>

Navegação pelo sistema

O grafo final de navegação pelo sistema é mostrado na imagem a baixo. Qualquer código redundante gerado pelo scaffold pode ser removido sem problemas (por exemplo show.rhtml). Esta é a beleza do scaffold, ele não te custa nada, então pode ser simplesmente excluido quando não for necessário.

Configurando a página inicial da aplicação.

Primeiro renomeie o arquivo pub.ic/index.html para public/index.html.orig

E edite o arquivo:

config\routes.rb (excerpt)

map.connect '', :controller => 'items'

Pronto, agora a tela inicial da aplicação é a listagem de tarefas.


Então era isto, fica faltando apenas o último post com os apendices.
Se tiverem duvidas é só entrar em contato :D

PS.: agradeço se os leitores que estão gostando do tutorial colocarem links em seus blogs para o tutorial, indicando para seus amigos.

Tags: ,

07 Jul 07 Quatro dias de Ruby On Rails – Terceiro Dia

Quatro dias de Ruby On Rails – Primeiro dia, Quatro dias de Ruby On Rails – Segundo dia

Seguindo com a tradução do tutorial, vamos ao terceiro dia (desculpem pela demora, mas não andava com muita vontade de escrever :D )

Agora é hora de começar o “coração” da nossa aplicação. A tabela Itens contem a lista de “Tarefas”. Cada item pertence a uma categoria das que criamos no Segundo Dia, cada Item pode opcionalmente possuir uma nota, criada em uma tabela separada, mas esta vamos deixar para o próximo dia de Rails. Cada tabela possui uma chave primária chamada “id” que é utilizada também para fazer o link entre as tabelas. (more…)

Tags: , ,

02 Jun 07 Java on Rails – Produtividade em Java (Parte 3 – Grails)

Eu fiquei em duvida sobre o titulo deste artigo, achei que deveria ser Groovy On Rails, mas eu resolvi seguir a linha “Java On Rails” que eu vinha escrevendo a algum tempo atras (aqui, aqui) e quando eu mencionei o Grails no ano passado.

O Grails é a coisa mais parecida com o Java On Rails que eu encontrei até agora, Grails é um Groovy On Rails que foi escrito em Groovy, uma linguagem dinamica derivada do Java, e que roda na JVM.

Ele foi bastante inspirado no Rails mesmo, e tem inclusive algumas coisas que eu achei mais inteligentes que o proprio Rails (eles poderiam copiar de volta :D ). (more…)

Tags: , , ,