E os videos coloquei no Vimeo, o com exemplo Java aqui, e o com exemplo Rails aqui.

FISL 2010 – Rails Cucumber BDD Sample creation from Rodrigo Urubatan on Vimeo.

Rails + BDD sample created as a sample to my presentation at Forum Internacional de Software Livre 2010.

FISL 2010 – Java Cucumber BDD Sample creation from Rodrigo Urubatan on Vimeo.

Java + BDD sample created as a sample to my presentation at Forum Internacional de Software Livre 2010.

Bom, espero que seja útil, se tiverem dúvidas é só deixar um comentário …

PS.: não tenho o código comigo agora, assim que possível subo pro github e coloco o link para o código aqui

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Slides, videos e código da minha palestra no FISL 2010

Escreva em C um método que inverta uma lista encadeada.

Claro que algumas restrições eram aplicadas, a assinatura do método não deveria ser alterada e a estrutura que armazenaria a lista encadeada também não deveria ser alterada. Elas eram apresentadas como o código abaixo:

1
2
3
4
5
6

typedef struct nodetype {
  int value;
  struct nodetype *next;
} node;
 
node* reverselist(node*)

Tentando automatizar um pouco o processo, ele tentou apresentar o código pronto com um bug, para que o bug fosse encontrado, mas o candidato sempre poderia escolher reescrever o código do zero se seguisse as regras acima.
Bom, olhei o código e achei que a recursividade utilizada estava só piorando o algoritmo, ele precisa de duas iterações para inverter a lista, então eu pensei, por que não escrever uma versão sem recursividade e que faça o processo todo em apenas uma iteração?
Bom, a minha resposta para o problema foi esta que esta abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

	static class LinkedItem {
		int value;
		LinkedItem next;
 
		public LinkedItem(int value) {
			super();
			this.value = value;
		}
	}
 
	private static LinkedItem reverseLinkedList(LinkedItem currentHead) {
		LinkedItem nextHead = null, previousHead = null;
		while (currentHead != null) {
			nextHead = currentHead;
			currentHead = nextHead.next;
			nextHead.next = previousHead;
			previousHead = nextHead;
		}
		return nextHead;
	}

Eu escrevi em java, mas não faz diferença pois para o algoritmo que escrevi a unica diferença seria a sintaxe.
Para testar isto escrevi um programa simples que inicializa uma lista encadeada com números de 1 a 10 e imprime a lista antes e depois desta ser invertida. O código esta abaixo, se alguem quiser fazer uma versão melhor deste algoritmo por favor poste a sua resposta nos comentários.

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

package test;
 
public class Main {
	static class LinkedItem {
		int value;
		LinkedItem next;
 
		public LinkedItem(int value) {
			super();
			this.value = value;
		}
	}
 
	private static LinkedItem reverseLinkedList(LinkedItem currentHead) {
		LinkedItem nextHead = null, previousHead = null;
		while (currentHead != null) {
			nextHead = currentHead;
			currentHead = nextHead.next;
			nextHead.next = previousHead;
			previousHead = nextHead;
		}
		return nextHead;
	}
 
	public static void main(String[] args) {
		LinkedItem head = initializeSampleList();
		printLinkedList(head);
		head = reverseLinkedList(head);
		printLinkedList(head);
	}
 
	private static LinkedItem initializeSampleList() {
		LinkedItem it = new LinkedItem(1), head = it;
		for (int i = 2; i < 10; i++) {
			LinkedItem it2 = new LinkedItem(i);
			it.next = it2;
			it = it2;
		}
		return head;
	}
 
	private static void printLinkedList(LinkedItem it) {
		while (it != null) {
			System.out.printf("%d ", it.value);
			it = it.next;
		}
		System.out.println();
	}
}

Eu achei espetacular a idéia deles de criar um site para automatizar este tipo de smoke test para entrevista de emprego de programadores, se o cara não consegue resolver isto deveria estudar um pouco mais antes de querer trabalhar com programação mesmo.
Mas se a idéia for testar a habilidade com algoritmos acredito que o candidato deveria poder escolher em que linguagem implementar, caso contrario, em alguns casos a habilidade com a linguagem estaria sendo testada, e acho que estas duas coisas deveriam ser testadas em separado.

E vocês o que acham sobre isto? Sobre este tipo de testes?
Já fizeram algum teste parecido com este em alguma entrevista de emprego?
E se você é o entrevistador, gostou da idéia deste tipo de teste? Acha util ou desnecessário?
Utiliza alguma técnica alternativa?
Olha o código produzido pelo candidato em projetos open source?

Bom, acho que por enquanto é isto

PS.: me decepcionei com a minha demora para implementar este algoritmo simples, levei uns 10 minutos, quando comecei a escrever achei que seria algo natural e funcionaria de primeira. Isto deve ter sido causado pela facilidade que temos hoje, como um Collections.reverse do java ou um [].reverse do ruby por exemplo. Raramente temos que lidar diretamente com este tipo de algoritmo básico, mas saber implementa-los é extremamente importante, pelo menos na minha opinião

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Algoritmos básicos são importantes, você consegue melhorar este?

Os videos da execução do cucumber estão aqui para quem quiser pegar:
Aplicação ASP.NET MVC 2 e Aplicação Java

E para quem quiser pegar o código dos exemplos, os links estão aqui:
Aplicação ASP.NET, Aplicação Java e Aplicação Ruby on Rails

A idéia que eu queria passar era que o cucumber pode ser utilizado para testar diversos tipos de aplicação, e acho que isto ficou claro

Espero que este material seja útil, e quem quiser comentar, sugerir, criticar, xingar, …
Pode usar o campo de comentários aqui do blog para isto.

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Material da minha palestra do Agile Brazil 2010

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.2/jquery-ui.min.js"></script>
<script>
$(document).ready(function(){
    $("#backlog,#wip,#done").sortable({
        connectWith: '.connectedSortable',
        receive: function(event, ui) { 
            /*alert($(ui.item).attr('data-id') + ' -> ' + $(this).attr('id'));*/
            //Do something with the recently dropped item here
        }
    }).disableSelection();
 
});
</script>

Onde #backlog, #wip e #done são os IDs das divs principais …
Para posicionar estas divs coloquei elas dentro de um container de ID bublecontainers, e usei o seguinte CSS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

            #bublecontainers {
                background-color: gray;
                width: 600px;
                margin: 0 0 0 0;
                padding: 0 0 0 0;
            }
            #backlog, #wip, #done {
                width: 190px;
                margin-left: 5px;
                height: 340px;
                display: inline-block;
                float:left;
                border: solid 1px;
            }

E agora a parte importante, para fazer as tarefas parecerem bolhas, usei a seguinte estrutura HTML:

1
2
3
4
5
6

<div class="buble">
  <div class="buble-content">
Texto da task aqui
  </div>
  <div class="buble-arrow"></div>
</div>

E me aproveitei de como as bordas do HTML são montadas via CSS, para transformar isto em uma bolha, só precisei do CSS 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

.buble-content {
                width: 100%;
                top: 0;
                margin: 0 0 0 0;
                padding: 8px 8px 8px 8px;
                text-align:justify;
                overflow: hidden;
                border-radius:10px;
                -moz-border-radius:10px;
                -webkit-border-radius:10px;
                background-color:#FFF;
                border-style: outset;
                text-indent: 10px;
 
 
            }
            .buble
            {
                display:inline-block;
                width:90%;
            }
 
            .buble-arrow
            {
                border-color:#FFF transparent transparent transparent;
                border-style:solid;
                border-width:17px;
                margin: -4 0 0 0;
                height:0;
                width:0;
                position: relative;
                left: 30%;
            }

As bordas arredondadas só vão aparecer em browsers mais modernos que tenham algum suporte a CSS3 rounded corners.

O experimento até que foi divertido, mas o código tem diversas falhas ainda, serviu para brincar um pouco

E o resultado vocês podem ver nesta coisa horrenda aqui de baixo (deem uma folga, fiz isto em 20 minutos ais ou menos só pra brincar e ver se a minha idéia era viável )

Se quiserem o código completo, segue 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
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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113

<html>
    <head>
        <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
        <script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.2/jquery-ui.min.js"></script>
        <style>
            #bublecontainers {
                background-color: gray;
                width: 600px;
                margin: 0 0 0 0;
                padding: 0 0 0 0;
            }
            .buble-content {
                width: 100%;
                top: 0;
                margin: 0 0 0 0;
                padding: 8px 8px 8px 8px;
                text-align:justify;
                overflow: hidden;
                border-radius:10px;
                -moz-border-radius:10px;
                -webkit-border-radius:10px;
                background-color:#FFF;
                border-style: outset;
                text-indent: 10px;
 
 
            }
            .buble
            {
                display:inline-block;
                width:90%;
            }
 
            .buble-arrow
            {
                border-color:#FFF transparent transparent transparent;
                border-style:solid;
                border-width:17px;
                margin: -4 0 0 0;
                height:0;
                width:0;
                position: relative;
                left: 30%;
            }
            #backlog, #wip, #done {
                width: 190px;
                margin-left: 5px;
                height: 340px;
                display: inline-block;
                float:left;
                border: solid 1px;
            }
            #bltitle, #wiptitle, #donetitle {
                height: 15px;
                text-align: center;
                width: 190px;
                display: inline-block;
                font-size: 20;
                font-height: bold;
            }
        </style>
        <script>
            $(document).ready(function(){
                $("#backlog,#wip,#done").sortable({
                    connectWith: '.connectedSortable',
                    receive: function(event, ui) { 
                        /*alert($(ui.item).attr('data-id') + ' -> ' + $(this).attr('id'));*/
                        //Do something with the recently dropped item here
                    }
                }).disableSelection();
 
            });
        </script>
    </head>
    <body>
        <div id="bublecontainers">
            <div id="bltitle">Back Log</div>
            <div id="wiptitle">Work In Progress</div>
            <div id="donetitle">Done</div>
            <div id="backlog" class="connectedSortable">
                <div class="buble" data-id="buble1">
                    <div class="buble-content">
                        Create a virtual Kanban Board
                    </div>
                    <div class="buble-arrow"></div>
                </div>
                <div class="buble" data-id="buble2">
                    <div class="buble-content">
                        Make this VKB usable
                    </div>
                    <div class="buble-arrow"></div>
                </div>
                <div class="buble" data-id="buble2">
                    <div class="buble-content">
                        write a blog post about it
                    </div>
                    <div class="buble-arrow"></div>
                </div>
                <div class="buble" data-id="buble2">
                    <div class="buble-content">
                        make it using no images, just CSS
                    </div>
                    <div class="buble-arrow"></div>
                </div>
            </div>
            <div id="wip" class="connectedSortable">
            </div>
            <div id="done" class="connectedSortable">
            </div>
            <div style="clear:both"></div>
        </div>
    </body>
</html>

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Brincadeirinha com Kanban Board Online

Eu também não queria ter que iniciar um processo separado da aplicação para cuidar disto pois eram tarefas simples, e depois de algumas pesquisas, encontrei o Rufus-Scheduler que resolve o problema que eu tinha, então resolvi escrever este post para que eu lembre dele caso precise novamente.

Sempre lembrando que aqui não serão mostrados todos do Rufus-Scheduler, apenas uma forma simples de usa-lo, se tiver dúvidas deixe um comentário que farei o melhor para esclarece-las.

Este exemplo vai começar com uma aplicação simples, um scaffold de uma entidade de nome SimpleTask com os seguintes parâmetros:

rails generate scaffold SampleTask name:string cron:string times:integer done:boolean job_id:string
rake db:migrate

A premissa para este exemplo é a seguinte:
Quando o sistema for iniciado as tarefas ainda não completas tem que ser agendadas novamente, e toda vez que eu criar uma tarefa nova esta tem que ser agendada automaticamente.

Então vamos a implementação com o Rufus-Scheduler.

• Apagar o arquivo public/index.html
• No arquivo routes.rb adicionar a linha ‘root :to => “sample_tasks#index”‘
• No Gemfile adicionar a linha ‘gem “rufus-scheduler”‘
• Criar um arquivo config/initializers/scheduler_initialization.rb com a seguinte linha: MySampleScheduler.update_schedules

No model criado adicionar o seguinte código:

class SampleTask < ActiveRecord::Base
	after_create :schedule_me
	after_destroy :unschedule_me
 
	def schedule_me
		MySampleScheduler.schedule read_attribute(:id)
	end
	def unschedule_me
		MySampleScheduler.unschedule read_attribute(:job_id)
	end
end

Criar o arquivo lib/my_sample_scheduler.rb com o seguinte conteúdo:

class MySampleScheduler
	@@scheduler = Rufus::Scheduler::PlainScheduler.start_new
	def self.update_schedules
		@@scheduler.in '1m' do #delay initialization because of problems acessing rails models during rails initialization
			jobs = @@scheduler.cron_jobs
			tasks = SampleTask.all
			tasks.each do |task|
				job = jobs[task.job_id] if task.job_id
				job.unschedule if job && (task.done || job.cron_line!=task.cron)
				if !task.done
					schedule(task)
				end
			end
		end
	end
	def self.unschedule(job_id)
		@@scheduler.unschedule(job_id)
	end
	def self.schedule(task_id)
		task = SampleTask.find task_id
		job = @@scheduler.cron task.cron do |j|
			task = SampleTask.find task_id
			if task
				puts "#{task.name} executing at #{Time.now} ---- #{task.times}"
				task.times = task.times - 1
				task.done = task.times==0
				task.save
				unschedule task.job_id if task.done
			else
				puts "Task deleted #{task_id}"
				unschedule j.job_id
			end
		end
		task.job_id = job.job_id
		task.save
	end
end

Rodar a aplicação e já deve ser possível cadastrar tarefas.
Quando a aplicação for finalizada e novamente inicializada, as tarefas pendentes terão um delay de 1 minuto para re-iniciarem, isto foi necessário porque se acessarmos os models diretamente durante a inicialização do rails, muitas coisas ruins podem acontecer.

Não se esqueça que para este exemplo funcionar você precisa ter o Rufus-Scheduler instalado. Se você seguiu todos os passos, um “bundle install” do diretório do projeto deve resolver o problema.

Se quiser o código da aplicação que eu escrevi, ele esta disponível neste endereço:http://github.com/urubatan/rails_schedule_samples

Se você já usa o GIT pode baixar o código com o comando: git clone git://github.com/urubatan/rails_schedule_samples.git

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Agendamento de tarefas muito fácil com com Ruby on Rails

PROTOCOLO://[USUARIO[:SENHA]@]ENDERECO_SERVIDOR/CAMINHO_NO_SERVIDOR?parametro=valor&outro_parametro=outro_valor#ancoraNaPagina

Por exemplo:

http://www.google.com/search?q=ruby+on+rails

onde:

• http é o protocolo
• www.google.com é o endereço do host
• /search é o caminho dentro do servidor
• q=ruby+on+rails é o parâmetro de nome “q” com o valor “ruby on rails”

Como uma URL não pode conter espaços os espaços são substituídos pelo sinal “+”, isto se chama codificar o parâmetro.

Como uma URL não aceita nenhum caractere com código ASCII maior que 127, qualquer caractere nesta categoria precisa ser codificado. Esta codificação consiste em substituir os caracteres por um “%” mais 2 dígitos numéricos representando o código ASCII em hexadecimal do caractere desejado, como na tabela a baixo:

Alguns destes caracteres são aceitáveis em uma URL, mas em algumas situações precisam ser codificados, como por exemplo o # que pode ser utilizado no final de uma URL para indicar ao browser qual parte da página mostrar, quando não for utilizado para este fim, deve ser codificado para evitar confusões.

Cabeçalhos HTTP

Cabeçalhos HTTP são uma forma de passar parâmetros extras, além da URL do browser para o servidor. Normalmente, estes parâmetros são utilizados para informar ao servidor as capacidades do browser e preferências do usuário, mas podem também ser utilizados para trocar dados adicionais além dos informados pelo usuário (que podem ser passados pela URL).

Os cabeçalhos HTTP são enviados com o seguinte formato, logo depois da URL e antes da primeira linha em branco na requisição:

nome: valor

O valor dos cabeçalhos deve ser codificados utilizando a mesma tabela de conversão das URLs.

Exemplo de Requisião HTTP

O usuário digita no browser a URL: http://www.google.com/search?q=ruby+on+rails

O browser abre uma conexão TCP/IP na porta 80 (padrão) do servidor www.google.com e envia o seguinte texto:

GET http://www.google.com/search?q=ruby+rails HTTP/1.0
User-Agent: Mozilla/4.73 [en] (X11; U; Linux 2.0.35  i686)
<Linha em branco no final>

O Servidor Responde:

HTTP/1.0 200 OK
Cache-Control: private
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=059bd3c506c56f82:TM=1189888548:LM=1189888548:S=hV0hCZi26b1SuRY7; expires=Mon, 14-Sep-2009 20:35:48 GMT; path=/; domain=.google.com
Server: gws
Date: Sat, 15 Sep 2007 20:35:48 GMT
Connection: Close

<html><head>
<Resto do HTML da página>

Explicando o que foi enviado:

• GET http://www.google.com/search?q=ruby+rails HTTP/1.0
  • GET é o método sendo utilizado
  • http://www.google.com/search?q=ruby+rails é a URL solicitada no servidor
  • HTTP/1.0 é a versão do protocolo sendo utilizada
• User-Agent: Mozilla/4.73 [en] (X11; U; Linux 2.0.35  i686)
  • User-Agent é um cabeçalho enviado que informa ao servidor qual browser esta fazendo a requisição
• Linha em branco marcando o final da transmissão.

Explicando a resposta:

• HTTP/1.0 200 OK
  • HTTP/1.0 é a versão do protocolo
  • 200 é o código da resposta que informa que o processamento esta OK
  • OK é um texto livre escrevendo o status, cada servidor pode responder com uma descrição diferente relativa ao código
• Nas linhas seguintes, antes do espaço, tem diversos HEADERS que podem ser utilizados pelo browser
• Após a linha em branco, há o conteúdo da URL solicitada

Métodos HTTP

GET

O método GET é utilizado para buscar o conteúdo de uma URL e o conteúdo retornado para a mesma URL deve ser sempre o mesmo. Isso facilita que o browser possa guardar páginas em cache por algum tempo para melhorar a experiência do usuário.

POST

O método POST é utilizado para enviar dados para o servidor. Esse método não possui a obrigatoriedade de ter sempre o mesmo resultado para os mesmos dados enviados.

PUT

O método PUT é utilizado para criar recursos no servidor. Ele possui a característica do método GET, de ter a mesma resposta para o mesmo conteúdo enviado.

DELETE

Este método é utilizado para remover recursos do servidor.

HEAD

O método HEAD serve para solicitar ao servidor apenas o cabeçalho do conteúdo com os headers, para que o cliente decida se precisa requisitar o conteúdo completo ou não.

Os métodos mais utilizados pela maioria das aplicações são o GET para buscar dados e o POST para enviar dados. Os métodos PUT e DELETE raramente são suportados por uma aplicação, mas são bastante úteis quando se deseja implementar Web Services seguindo o padrão REST. Alguns outros protocolos utilizam métodos adicionais e até definem alguns novos, como por exemplo o protocolo WebDav.

Códigos de resposta HTTP

Os códigos de resposta HTTP possuem 4 famílias básicas que serão apresentadas abaixo. Mais informações sobre estes códigos de resposta podem ser encontradas nesta URL: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

• 1XX – Códigos de informação, muito pouco utilizados
• 2XX – Sucesso: o código mais utilizado desta família é o 200 que significa OK
• 3XX – Redirecionamento: os códigos mais utilizados desta família são: 301 redirecionamento permanente e 307 redirecionamento temporário
• 4XX – Erro do cliente: o código mais conhecido desta família é o 404 que significa recurso não encontrado
• 5XX – Erro do servidor: o código mais conhecido desta família é o 500 que significa erro interno do servidor.

Cabeçalhos comuns

Como o protocolo HTTP não mantém estado portanto, cada request é independente. Para solucionar este problema os cookies podem informar ao servidor quem é o cliente que está acessando o recurso.

Segue uma lista de alguns cabeçalhos bastante utilizados.

• Location: utilizado junto com os códigos 301 e 307 informando o novo endereço do recurso
• Content-Type: informa o tipo MIME do recurso retornado ou enviado ao servidor
• Set-Cookie: grava um cookie no browser
• Cookie: envia os cookies armazenados no servidor
• Cache-Control: informa se o browser pode ou não armazenar o recurso em cache
• Content-Length: informa o tamanho do conteúdo enviado ou da resposta
• Last-Modified: informa ao cliente quando foi a ultima alteração do recurso solicitado
• Accept: informa ao servidor quais são os tipos de recursos que o cliente sabe processar
• Allow: informa ao cliente quais as ações disponíveis para um recurso especifico
• Content-Encoding: informa ao cliente ou ao servidor qual a codificação que está sendo utilizada para o conteúdo enviado ou recebido
• Host: informa ao servidor qual o nome do host utilizado no request. Bastante útil para possibilitar a configuração de hosts virtuais no mesmo endereço IP

Bom, acho que era isto, claro que isto não é tudo sobre formação de URLs e sobre o protocolo HTTP, mas já é um bom começo.

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

HTTP e URL – Dois ilustres pouco conhecidos

Uma excessão a isto, na minha opinião pelo menos, é o código gerado pelo “scaffold” do Grails, pelo simples fato que ele sempre permitiu que a aplicação alterasse os templates que seriam utilizados para gerar o código. No rails isto sempre foi mais complicado, era preciso criar um generator e duplicar todo o generator que você queria personalizar para algumas vezes mudar quase nada no código gerado, ou seja, na maior parte das vezes isto não valeria a pena mesmo …

Mas com o Rails 3 seus problemas acabaramse! _{(alusão sem graça nenhuma ao seu Creiçom do Casseta e Planeta)}

O Rails 3 permite que você personalize de forma bastante fácil os templates utilizados pelos generators do rails, basta criar uma pasta templates dentro do diretório lib do projeto, e neste diretório copiar para lá o template original do rails e fazer as alterações que você achar interessante para o seu projeto.

Os templates do rails ficam dentro da Ruby Gem “railties”, dentro de lib/generators.

Neste diretório existem os grupos de generators (erb, rails e test_unit) e dentro destes, um diretório para cada generator e dentro deste um diretório templates. O conteúdo deste diretório templates deve ser copiado para RAILS_ROOT/lib/templates/<grupo>/<nome do generator>.

E pronto, as alterações que você fizer na copia do seu projeto vão refletir no resultado da próxima vez que você executar o generator …

Acho que isto ficou meio confuso certo?

Então é o seguinte, vamos supor que queiramos alterar o código das views geradas pelo generator “scaffold”. O código original vai estar no diretório
RAILTIES_GEM/lib/rails/generators/erb/scaffold/templates
Este diretório contem os templates que vão gerar os arquivos .html.erb, para personalizar o código gerado para o seu projeto, basta copiar o conteúdo deste diretório para
RAILS_ROOT/lib/templates/erb/scaffold (isto mesmo, sem o diretório templates)
Alterar o que você quiser, e pronto, tudo vai funcionar …

Mas vamos combinar que ficar copiando estes arquivos da trabalho né? Isto me faz sentir falta de uma task de nome “install-templates” do grails, que copiava todos os templates de geração de código para o diretório da aplicação para que fossem personalizados. E como sou preguiçoso demais para ficar copiando arquivos a mão, criei uma task rake que faz isto. Não empacotei em um plugin por que achei muito simples, mas se alguem achar interessante posso fazer isto
Enquanto isto, quem quiser copiar o código desta task, esta disponível no gist, é só copiar o código e colocar em um arquivo .rake no diretório lib/tasks da aplicação.

E para usar a task é só rodar: rake templates:copy

Ahh, mas pra que serve isto?
Bom, para diversas coisas, como por exemplo fazer com que o código gerado pelo scaffold chegue mais próximo de um cadastro real da sua aplicação, ou para fazer um exemplo simples, eu personalizei o controller.rb do scaffold_generator para utilizar o novo Responder do Rails 3, o template ficou assim:

E o controlador gerado, mantem exatamente a mesma funcionalidade, mas em vez das 84 linhas padrão de um controlador gerado pelo scaffold do rails, ele tem apelas 51 linhas. O código gerado ficou assim:

Se você quiser saber mais sobre o Responder, o Akita publicou um post sobre isto hoje no blog dele.

Espero que este post ajude vocês a trabalhar menos daqui pra frente.

PS.: Achei legal testar o Gist, mas se vocês não gostaram e preferirem o código embedded nos posts do blog como eu sempre faço, é só avisar que volto a colar o código por aqui mesmo

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Personalizando o código gerado pelo Rails 3

SOA

Sim, eu sei que estou sendo um pouco categórico demais, e que nenhuma regra se aplica a tudo e que existem excessões para o que estou escrevendo.

Stateless

Se você quer um sistema ou um serviço escalável, com certeza você quer que todas as requisições para este serviço sejam stateless.
Mas por que?
Simplesmente por que caso em um futuro próximo você precise rodar a sua aplicação em um cluster, você não prende um cliente a um nó do cluster, cada requisição pode ir para o nó do cluster que estiver com a menór carga naquele momento, fazendo com que o tempo de resposta aquela requisição seja o menor possível, mantendo o nó do cluster que vai atender a esta requisição ocupado o menor tempo possível.

Request Response Time

Acho que já falei um pouco sobre isto, mas imagine a seguinte situação, o sistema que você acabou de publicar bombou e agora em vez de ter que atender a 5 clientes (Você, seu melhor amigo, sua mãe, seu pai, sua namorada), agora o sistema tem que atender a 1k clientes simultâneos, e você pensa: Beleza, só preciso fazer um clusterzinho aqui, coloco mais duas maquinas e tudo beleza.
O problema é que o seu sistema antes estava com um “RRT” médio de 30s ou seja, com uma maquina só, você conseguia responder a duas requisições por minuto (considerando apenas um thread por máquina para facilitar o exemplo), agora com as duas maquinas novas você consegue atender a maravilhosos 6 requests por minuto. Ou seja, você tem um baita fiasco nas mãos.
Por isto o Request Response Time, ou seja, o tempo que a sua aplicação leva para atender a cada requisição tem que ser o mais baixo possível.
Por exemplo, enquanto escrevia este post criei uma aplicação rails com um cadastro de usuários de brinquedo, gerado pelo scaffold e o RRT é de 15.6ms (alto mas a maquina esta bastante carregada agora) o que permite que com uma thread seja possível atender a 64 requisições por segundo. Em um outro sistema que trabalhei, algumas requisições por diversos motivos chegaram a demorar 20s para retornar, mas isto foi resolvido claro
Bom, acho que deu para entender o por que o RRT é tão importante. Para clarear mais a idéia, imagine a seguinte situação que você já deve ter visto diversas vezes: Uma loja grande, com fila unica e 4 caixas atendendo. Se cada um dos caixas for muito demorado, você vai passar horas na fila, e não é economicamente viável ter um caixa por usuário. então a solução viável para este problema é otimizar o trabalho dos caixas para que cada caixa seja mais rápido e consiga atender a um maior número de clientes por minuto.

Cache

Cache é uma forma de melhorar muito o RRT, imagine que a sua mega aplicação seja uma página de classificados, em que a página inicial, que todos os clientes acessam ao chegar no site. Tenha uma lista com os produtos mais baratos anunciados.
Esta página precisa de uma consulta no banco de dados para ser renderizada, mas se você pensar bem os dados serão sempre os mesmos até que alguem delete um dos produtos listados ali ou cadastre outro mais barato.
Então faz todo o sentido “guardar uma copia” da página prontinha, e só mostrar aquela cópia para o próximo que acessar a página, e simplesmente deletar esta cópia quando uma das duas situações que pode alterar a página acontecer, ai no próximo acesso a página é renderizada novamente e a copia atualizada é guardada, e novamente ficamos utilizando apenas aquela cópia até que algo aconteça que possa fazer os dados ficarem desatualizados.
Isto é chamado de “cache”, na verdade esta é uma forma bem simples de cache. Estude aos recursos de caching do framework que você esta utilizando, do servidor de aplicações, do sistema operacional, do banco de dados.
Mas não ative tudo ao mesmo tempo, o correto uso de cache vai melhorar muito a performance da sua aplicação, mas o uso incorreto pode causar muitos problemas.

Remote Data

Muito pouca coisa é pior para um cluster do que uma aplicação que guarda dados localmente.
Imagine só o seguinte, naquela aplicação de classificados, você resolveu que as imagens correspondentes a cada anuncio ficariam gravadas na própria maquina do servidor, barbadinha, facilita o upload.
Ai é que mora o perigo.
Quando você precisar colocar isto pra rodar em um cluster, o segundo nó do cluster quando atendendo uma requisição, vai acreditar que as imagens estão naquele nó também, mas ele nem existia quando o anuncio foi criado, o upload foi feito pra outra maquina. Isto vai fazer com que o usuário veja uma página com a imagem quebrada.
Ahh, e como resolver isto?
Bom, existem diversas formas, uma bem simples é criar um servidor de “recursos estáticos”, ou seja, tudo o que é estático no site é servido por um endereço diferente, e quando for feito o upload de uma imagem, ela deve ser salva neste outro servidor. Também é possível utilizar um serviço como o Amazon S3 que vai fazer exatamente a mesma coisa que o seu servidor de recursos estáticos, mas de fora
Outra coisa a lembrar é do banco de dados, ele também não deve ficar na mesma maquina que o servidor da aplicação, ou o endereço do banco (seja ele SQL, document driven, …) deve ser configurável. Isto por que em um cluster, o ideal é que todos os nós acessem o mesmo banco de dados, ou no mínimo que todos os bancos do cluster estejam sincronizados.

Proxy Reverso

Um próxi reverso no contexto deste post vai ser utilizado para mascarar algumas das técnicas de caching, para implementar algumas técnicas de caching e principalmente para esconder do usuário que você tem diversos servidores, ele vai ser o “front-end” da sua aplicação, a mágica do cloud só pode acontecer atrás do proxy, e ele também pode esconder do usuário o fato de você usar um “servidor de recursos estáticos” sendo ele interno criado por você mesmo ou você usando um S3 da vida, o proxy reverso pode mascarar o endereço real da aplicação.
Mas nunca esqueça de um detalhe importante. Este proxy mesmo sendo vital para uma arquitetura cloud, ou um cluster menorzinho, ele acaba de adicionar um SPoF (Single Point Of Failure) se o proxy morrer, a sua mega aplicação esta fora do ar.

Bom, acho que era isto, sempre tem alguem perguntando como fazer um sistema escalável, como fazer um sistema robusto, como fazer um sistema para rodar em cluster ou na nuvem.
Este post não é a resposta final para todos os problemas, este post não responde estas perguntas para todos os casos, mas para a maior parte dos casos que me lembro agora, as dicas deste post são pontos imprescindíveis para qualquer aplicação ou arquitetura que pretenda ter um mínimo de escalabilidade.
Espero que este post seja útil para alguem, e se não concordarem com alguma coisa é só deixar um comentário.

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Os 5 segredos para um sistema altamente escalável

A Agile Brazil 2010 é um evento nacional organizado por representantes das principais comunidades ágeis brasileiras. Junte-se a nós submetendo trabalhos, participando do concurso do logo e divulgando o evento.

Acompanhe as novidades do @agilebrazil pelo Twitter.

O evento vai acontecer em Porto Alegre de 22 a 25 de Junho 2010.

Espero ver alguns de vocês por lá!

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Agile Brazil 2010 – A chamada para trabalhos está aberta!

1. Ajudar a quem precisa, neste caso a Cotolengo
2. Compartilhar conhecimento sobre Adobe Flex, e o pessoal que vai estar compartilhando conhecimento é muito fera!!

Quem organiza o evento é a e-Genial, que também organiza o Rails for Kids.
No Flex For Kids as doações recebidas vão direto para a Cotolengo, o que é bem legal, na prática você estara assistindo a excelentes palestras de grátis, a única coisa que é cobrada é que você faça um pouquinho de caridade
Bom, veja o que você vai poder aproveitar neste evento, e tudo isto sem sair de casa (ou do trabalho) já que o evento utiliza a excelente plataforma Treina Tom (Também da e-Genial)

• Vicente Maciel Junior

  Palestra: Desenvolvimento Multi-touch com AIR 2.0
  Nesta palestra o participante irá conhecer a API Multi-touch introduzida na versão 2.0 do Adobe Integrated Runtime, que traz grande facilidade para o desenvolvimento de aplicações explorando este recurso.
  Público Alvo: Desenvolvedores, gerentes de projeto e entusiastas no desenvolvimento de soluções utilizando o AIR 2.0

• Igor Musardo

  Palestra: Construa painéis administrativos em Flex integrados com ASP.NET MVC.
  Você verá na prática como integrar o Flex com a nova abordagem MVC do ASP.NET, indo além do CRUD.
  Público Alvo: Desenvolvedores Flex que utilizem ou querem utilizar o ASP.NET MVC como Back-End.

• Mário Júnior

  Palestra: Swiz Framework: MVC Simples e Poderoso para projetos Flex/AIR
  Essa palestra visa mostrar a brutal diferença entre seus “concorrentes” e entender melhor a “conceptual constraint” que levou os autores do Swiz Framework a desenvolverem uma solução simples e flexível para projetos Flex/AIR, em relação aos demais frameworks conhecidos. (Cainrgorm, PureMVC, Mate, etc). Pré requisito: Conhecer “Dependency Injection” (DI) e “Inverse of Control” (IoC).
  Público Alvo: Desenvolvedores Flex.

• Eberton Consolim

  Palestra: Flex e VOIP: Adicione essa tecnologia em suas aplicações
  Essa palestra tem por objetivo demonstrar a desenvolvedores Flex como implementar em suas aplicações funcionalidades de um discador VOIP, usando soluções open source.
  Público Alvo: Desenvolvedores Flex.

• Daniel Lopes

  Palestra: Desktop com HTML, Javascript e Adobe AIR
  Conheça um novo mundo de possibilidades e tecnologias com Javascript e HTML para desktop e descubra como Adobe Air se integra a este ambiente, utilizando como case o PomoDo.
  Público Alvo: Desenvolvedores de qualquer linguagem.

• Gabriela Trindade Perry

  Palestra: Estudo de caso: User Experience em um RIA
  Será debatido um estudo de caso onde implementamos um mecanismo de busca semântica através do design (!) A interface apenas pode ser viabilizada pela alta capacidade de componentização do Flex e porque entendemos o que o usuário precisava fazer com a interface.
  Público Alvo: Desenvolvedores Flex e designers de todos os credos e cores.

• Eric Cavalcanti

  Palestra: Desmistificando o Cairngorm
  O Cairngorm é considerado por muitos como um framework com uma curva de aprendizado elevada. A finalidade desta palestra é desvendar o Cairngorm utilizando uma abordagem diferenciada, com o objetivo de facilitar o aprendizado do mesmo.
  Público Alvo: Desenvolvedores Flex.

• Fábio Vedovelli

  Palestra: Introdução ao Mate: a importância de um framework MVC para Flex
  Muitos ainda não se convenceram da necessidade da utilização de um dos frameworks MVC (Model – View – Controller) presentes no mercado e esta palestra tem como objetivo mostrar a sua importância e indicar o framework escolhido pela RIA Labs.
  Público Alvo: Desenvolvedores Flex.

• Igor Costa

  Palestra: Coloque uma interface Flex em seus projetos JEE
  Entenda como funciona a integração Adobe Flex com todos os serializadores disponíveis no mercado (BlazeDs, LivecycleDs,WebOrb for java,Pimento,Red5) para integração com seu back-end Java e crie novas ferramentas com recursos ímpar para seu negócio.
  Público Alvo: Desenvolvedores Java.

• Beck Novaes

  Palestra: O Quarteto Fantástico: Flash 10.1, Flex 4, Flash Catalyst e Flash Builder
  Como as principais novidades da Plataforma Flash poderão impactar o desenvolvimento de Rich Internet Applications.
  Público Alvo: Pessoas interessadas no desenvolvimento de Rich Internet Applications.

Para se inscrever, ou só para ver mais alguns detalhes antes de se inscrever, é só acessar o site do evento.

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Flex For Kids – Aprendendo o que precisa e ajudando a quem precisa :D

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

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

As 8 Falácias da programação distribuida

P3301

Procurei um pouco no forum.xda-developers.com e encontrei uma ROM com windows mobile 6.5 para o meu HTC Artemis, instalei a Original Microsoft Edition (sim, eu sei que não foi uma atualização oficial feita pela MS, até por que eles não liberam atualizações, apenas o fabricante do celular pode fazer isto).

Bom, o que eu tenho a dizer é que o WM 6.5 esta realmente muito melhor que o 6.0 (que eu tinha antes no celular).

A tela inicial (Chamada de Titanium se não me engano) ficou bem legal. Poderia ser mais costumizável, mas ficou legal, e com certeza é criativa e foge bastante dos dois padrões existentes atualmente (estilo iPhone com botões e estilo Android/HTC com muitas informações, widgets e páginas).

O menu “Honey Comb” ficou espetacular, é impossível abrir a aplicação errada com este formato de menu, só não gostei do tempo que se leva para organizar manualmente as aplicações, mas pelo menos agora é possível, o que antes não era …

O Windows Marketplace é um completo fiasco, não tem nada la, deve ter no máximo umas 40 aplicações …

O Internet Explorer parece bem mais rápido, e o esquema de zoom e navegação em tela cheia desta nova versão ficou beem legal …

O Media Player Mobile também melhorou, mas não foi nada que realmente chame atenção.

O PIM melhorou bastante, mas não tem nenhum recurso novo excepcional, ja que na minha opinião o anterior não tinha nada faltando (Isto inclui os aplicativos de contatos e calendário).

Não sei se é um problema com a ROM que instalei ou com o WM 6.5, mas na configuração de o que cada botão vai fazer eu posso configurar ações para os botões 1, 2, 3, 5, 6, 6(Hold), é isto ai, ta faltando o botão 4 na lista. Mas isto não chega a ser grave.

Uma das coisas que mais gostei, é que agora o SO todo é “finger friendly”, provavelmente por causa da onda de iPhones e Androids e de todo o esforço dos fabricantes para melhorar a interface do WM. Se bem que não tem disculpa para o 6.0 não ser assim, já que já existia o iPhone quando lançaram o WM 6.0 …

No geral, a performance do PDA/celular melhorou muito com esta nova ROM, não sei o que exatamente causou isto, se foi a versão nova do windows mobile, se é a quantidade de memória livre, mas agora estou bem mais feliz com o meu smartphone

PS.: se algum usuário de windows mobile estiver com medo de atualizar a ROM, é só seguir os passo a passo encontrados no forum.xda-developers.com que fica tudo tranqüilo, tem até instruções de como fazer backup da ROM original para uma possível restauração em caso de problemas
Se quiserem um passo a passo em português aqui no blog é só pedir nos comentários …

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Quick Review – Windows Mobile 6.5

Primeiro, você vai precisar do Rails 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 configurados, o que pode facilitar bastante a vida, ou complicar as vezes

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

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:

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

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Ruby on Rails 101 – Encurtador de URLs = Novo Blog

Não me levem a mal, eu já tentei utilizar ele algumas vezes, mas eu não consigo gostar de uma ferramenta que acha que sabe mais do meu projeto do que eu mesmo (ou o cliente, ou os desenvolvedores, …).
Ou pior que isto, uma ferramenta que tem a infeliz mania de tentar fazer um backup da internet antes de cada build só para verificar se tem a última versão das dependências disponível …

Como é citado no post, não acho que alguma ferramenta vá saber exatamente o que é necessário para qualquer projeto, até por que cada projeto é um projeto, e cada projeto tem suas peculiaridades, e eu simplesmente desisti todas as vezes que precisei configurar alguma destas peculiaridades no maven e voltei para o ANT.

O ANT é uma ferramenta bastante flexível, e pelo que eu tenho visto no mercado, fora alguns teimosos que preferem usar o maven mesmo passando muito mais trabalho do que o necessário, o ANT é o “defacto standard” para builds em Java, mas algumas vezes a “linguagem de script” do ANT dificulta as coisas quando se precisa realmente de um script para fazer alguma coisa durante o build, então resolvi usar Ruby para escrever os builds, ou seja, utilizar uma linguagem de scripts de verdade.

Ai pensei, como é que vou fazer para compilar meu projeto java utilizando o Rake? A linguagem de script é muito fodastica, é Ruby, eu me sinto bem programando em Ruby, mas e como compilar?

Fui perguntar ao oraculo e descobri o BuildR e o Raven que fora o fato de não utilizarem XML e sim Ruby, conseguem repetir todos os erros do Maven, eles parecem “ports do Maven para o Rake” e eu não sei por que alguem iria fazer isto, se você gosta tanto assim do Maven, use ele mesmo …

Mas do Rake eu gosto, me acostumei com ele trabalhando com o Rails, é muito fácil de automatizar tarefas relacionadas a um projeto utilizando o Rake, e não apenas o “build”, mas algumas tarefas que as vezes precisam ser automatizadas, como um merge freqüente com algum sub projeto desenvolvido em outra parte do mundo …

Isto me criou apenas um problema, como compilar, empacotar, …

Ou seja, me faziam falta as tasks básicas do ANT que eu utilizo sempre. As outras tarefas são melhor executadas na minha opinião pelo próprio Rake ou até mesmo por um script em Ruby, mas estas tarefas básicas iriam fazer falta, e para resolver isto eu criei uma classe wrapper para os comandos do JDK, que pode ser estendida depois, não é algo 100% rake, mas eu achei que ficou legal assim, se alguem não concordar e tiver idéias para melhorar estou aceitando sugestões

O wraper para os comandos do JDK ficou assim:

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

class JavaUtil
  RAW_COMMANDS = %w{appletviewer apt extcheck idlj jar jarsigner java javac javadoc javah javap javaw javaws jconsole jdb jhat jinfo jmap jps jrunscript jstack jstat jstatd jvisualvm keytool kinit klist ktab native2ascii orbd pack200 packager policytool rmic rmid rmiregistry schemagen serialver servertool tnameserv unpack200 wsgen wsimport xjc}
 
  def initialize(jdk_home=nil)
    @commands = {}
    @jdk_home = jdk_home || ENV['java_home']
    @default_for_command = {}
    @global_default = {}
    init_commands
  end
 
  def method_missing(met,*args)
    if RAW_COMMANDS.include? met.to_s
      execute_command met, *args
    else
      super.method_missing met, *args
    end
  end
 
  def respond_to?(met)
    RAW_COMMANDS.include?(met.to_s) || super.respond_to?(met)
  end
 
  def default_parameter(param,value)
    @global_default[param] = value
  end
 
  def default_parameter_for(met,param,value)
    params = @default_for_command[met] || {}
    params[param] = value
    @default_for_command[met] = params
  end
 
  private
    def init_commands
      @jdk_bin = File.join @jdk_home , "bin"
      RAW_COMMANDS.each do |cmd|
        @commands[cmd.to_sym] = File.join @jdk_bin, cmd
      end
    end
 
    def update_or_concat_with_defaults(opts,defaults)
      defaults.each do |key,value|
        param = opts[key]
        if !param
          param = value
        else
          if param.is_a? Array
            param << value
            param.flatten!
          end
        end
        opts[key] = param
      end
    end
 
    def execute_command(cmd, *args)
      actual_command = @commands[cmd.to_sym]
      if args
        opts = {}
        opts.update args.pop if args.last.is_a? Hash
        update_or_concat_with_defaults opts, @global_default
        update_or_concat_with_defaults opts, @default_for_command[cmd.to_sym] if @default_for_command[cmd.to_sym]        
        opts.each do |key, value|
          param = value
          param = param.join File::PATH_SEPARATOR if param.is_a? Array
          actual_command << " -" << key.to_s << " "  << param
        end
        actual_command = "#{actual_command} #{args.join ' '} "
      end
      puts actual_command
      res = %x{#{actual_command}}
      puts res
      [$?,res]
    end
end

A minha idéia dos parâmetros default globais tem um pequeno problema, alguns comandos não recebem os mesmos parâmetros, mas é possível setar parâmetros padrão por comando, o que ficou legal, e deixou a compilação mais limpa …

A classe pode ser utilizada com qualquer JDK, inclusive instâncias diferentes podem utilizar JDKs diferentes para o mesmo build, basta passar o “JAVA_HOME” no construtor, por padrão a variável de ambiente é utilizada …

Mas beleza, como é que eu utilizo esta tranqueira em um Rakefile agora? bom, o meu Rakefile para o projeto de exemplo ficou assim:

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

require 'lib/java_util'
@java_util = JavaUtil.new
 
task :default => :test
 
SRC_FILES = FileList.new 'src/**/*.java'
TST_FILES = FileList.new 'test/**/*.java'
CLASSPATH = FileList.new "#{File.join(ENV['TOMCAT_DIR'], 'lib').gsub /\\/,'/'}/*.jar"
 
@java_util.default_parameter_for :java, :classpath, CLASSPATH.to_a
@java_util.default_parameter_for :javac, :classpath, CLASSPATH.to_a
 
directory 'output/classes'
directory 'output/tests'
 
desc "Compile all the java files"
task :compile => ['output/classes','output/tests']  do
  @java_util.javac SRC_FILES, :d => 'output/classes'
  @java_util.javac TST_FILES, :d => 'output/tests', :classpath => ['output/classes',"#{ENV['JUNIT_DIR']}\\junit-4.4.jar"]
end
 
desc "Creates the package after compilation"
task :package => :compile do
  @java_util.jar '-cf output/target.jar -C output/classes .'
  cp 'output/target.jar', 'WebContent/WEB-INF/lib'
  @java_util.jar '-cf output/target.war -C WebContent .'
end
 
desc "Runs the tests after packaging"
task :test => :package do
  test_classes = FileList.new 'output/tests/**/*.class'
  test_classes.gsub! /output\/tests\/(.*)\.class/,'\1'
  test_classes.gsub! /\//, '.'
  @java_util.java "org.junit.runner.JUnitCore #{test_classes.join ' '}", :classpath => ['output/tests','output/target.jar',"#{ENV['JUNIT_DIR']}\\junit-4.4.jar"]
end
 
desc "Clean up all the mess we created"
task :clean do
  rm_f 'output'
  rm_t 'WebContent/WEB-INF/lib/target.jar'
end

O código dos testes não precisava ser tão complexo, eu poderia ter criado um wrapper para ele, a mesma coisa para a criação do jar, poderia até mesmo ter utilizado o “rubyzip” para deixar mais bonitinho, mas a idéia por enquanto é ser bem simples.

Estou utilizando este build em um projeto, se engrenar provavelmente a biblioteca vá crescendo, mas acho que por agora já serve para começar a brincar e ver o que vocês acham da idéia.
A classe “JavaUtil” precisa ser mais testável, mas isto tornou ela complexa demais para o exemplo deste post, se eu convencer o resto da equipe a continuar usando esta solução vou melhorando ela aos poucos

Acho que vou separar a montagem do comando e a execução do mesmo, ou transformar cada comando em uma classe para facilitar a expansão da biblioteca e tornar mais testável, ou até mesmo as duas coisas.
No momento a classe não é nada testável, mas já esta divertida e o meu bluid diminuiu muitas linhas depois que eu converti ele de ANT para Rake utilizando esta lib

PS.: quem quiser pegar o projeto de testes para brincar, só para olhar ou até mesmo para implementar algumas melhorias, ele esta publicado no github. Se implementarem alguma melhoria, não esqueçam de enviar um pull request para que eu possa fazer o merge das alterações

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Utilizando Rake para o Build de projetos Java!

Desenvolvimento Guiado pelo Comportamento (BDD – Behaviour Driven Development)

Desenvolvimento guiado pelo comportamento da aplicação é o que todos deveriam fazer sempre, de forma bastante resumida é definir com o cliente como a aplicação deve se comportar, escrever um teste automatizado para verificar este comportamento e depois escrever código suficiente para fazer o comportamento da aplicação ficar de acordo com o que o cliente deseja.

A diferença básica do Behaviour Driven Development (de agora em diante simplesmente BDD) para o desenvolvimento orientado por testes, é que o BDD coloca em foco o valor para o negócio que o software vai adicionar. Parece ser uma diferença puramente conceitual mas não é, por exemplo:
A tela inicial deve listar todos os clientes
Não é a mesma coisa que
O método HomeController.index precisa popular a variável @clientes

1. O primeiro é inteligivel para um leigo, o segundo é especifico para um sistema e apenas um programador entende
2. O primeiro é um exemplo de uma definição de comportamento de uma tela, uma coisa que um cliente poderia dizer.
3. O segundo é um exemplo de como um programador poderia ler uma linha de código fonte.

Claro que não são só estas diferenças, trabalhando mais com BDD percebe-se que ele poupa muito mais trabalho do que o TDD simples (Não que TDD seja simples de se adotar). BDD tem todas as vantagens de TDD e mais algumas, veja as duas listas abaixo:

Test Driven Development:

1. O código gerado tem menor acomplamento e maior coesão.
2. O código gerado tem uma maior qualidade por ser quase 100% testado.
3. Refatoramentos podem ser feitos sem medo pois qualquer problema sera detectado pelos testes.
4. É possível saber claramente quando uma tarefa foi concluida, pois o teste correspondente esta passando.
5. Testes de regressão automatizados existem sem nenhum esforço adicional.
6. A maior parte dos bugs é encontrada mais cedo o que torna mais barato corrigi-los.

Behavior Driven Development:

1. Todos os anteriores
2. Aumenta a integração entre o cliente, os testadores e os desenvolvedores pois todos falam a mesma lingua.
3. Mesmo quando testadores e desenvolvedores são equipes diferentes eles podem trabalhar juntos para definir o design do que vai ser feito, escrever User Stories é uma ótima forma de fazer isto, pode ser feito com a ajuda do usuário ou pelo menos validada com o usuário que vai entender o que esta escrito.
4. User Stories servem como Test Case, Código do teste automatizado, e Design tudo junto.
5. As User Stories se tornam testes executáveis, o que quer dizer que o usuário pode escrever o código dos testes de aceitação (OK, isto é bem pouco provável, mas ele pode pelo menos ler)

Ou seja, alem de gerar um código com mais qualidade, o BDD poupa trabalho de toda a equipe e o principal, melhora a comunicação, que tanto para quem trabalha com metodologias ágeis quanto para quem não trabalha é extremamente importante e a falta dela é um problema gravíssimo que leva diversos projetos ao fracasso. Na minha opinião, só o fato de melhorar a comunicação já é motivo o suficiente para testar BDD.

Claro que alguns dos benefícios que eu citei dependem do suporte de ferramentas, para ser mais preciso, as User Stories serem o código executável dos testes de aceitação depende de uma ferramenta para ser verdade, e a ferramenta que eu escolhi para isto é o Cucumber, do qual eu vou começar a falar com mais freqüência aqui no blog.

Eu pessoalmente encaro o BDD como uma evolução do TDD, eu sempre tive dificuldades em escrever testes unitários antes do código da aplicação, claro que para bibliotecas é fácil, mas para a interface com o usuário que consome boa parte do código da aplicação é bem complicado escrever testes estilo XUnit, mas quando as user stories se tornaram o código executável dos testes de aceitação da UI (pelo menos os básicos desconsiderando o layout) um novo mundo se abriu para mim e tudo passou a fazer sentido.

Cucumber – Quem disse que pepinos seriam um problema?

_{para quem não percebeu este sub-titulo é uma brincadeira com a tradução da palavra cucumber que quer dizer pepino}

Cucumber é uma ferramenta que torna possível executar histórias em texto puro, ele é uma ferramenta escrita em Ruby que veio para substituir o RSpec Story Runner, e tem diversas vantagens sobre este.

O Cucumber, utiliza Ruby e expressões regulares para definir o que qualquer expressão quer dizer, mas antes de entrar nestes pormenores vamos entender um pouquinho da estrutura básica que o Cucumber define para as User Stories.

Para que seja possível executar uma User Storie utilizando o Cucumber, ela precisa ter uma estrutura básica.

1. Para o cucumber, todas as User Stories referentes a uma funcionalidade do sistema estarão agrupadas em um arquivo com a extensão .feature
2. No início de cada arquivo existe um resumo da funcionalidade com um formato bem simples: um título, qual o problema a ser resolvido, qual ator trabalha nesta história e qual o resultado desejado.
3. Logo depois são definidos os cenários, que são as histórias em si, cada arquivo tem pelo menos um cenário.
4. Cada história, ou cenário é composto por uma descrição ou título, uma ou mais pré condições, uma ou mais ações e uma ou mais verificações.

Esta é uma forma de definir a estrutura básica de um arquivo .feature do Cucumber, claro que explicando desta forma estas definições se encaixam em muita coisa, então vamos ser um pouco mais especificos.

O Cucumber define algumas palavras chave para cada uma destas sessões, estas palavras chave podem ser traduzidas para diversas linguas, o primeiro exemplo eu vou colocar em ingês, depois vou mostrar o equivalente em portugues, mais adiante quando entrarmos na parte de configurações do cucumber vamos ver melhor como selecionar a lingua utilizada, e como customizar isto, mas por enquanto fiquemos com as configurações padrão.

	Feature: Simple math
		In order to avoid silly mistakes
		As a math idiot
		I want to be told the result of simple math operations

		Scenario: adition
			Given I have entered 50 into the calculator
			And I have entered 70 into the calculator
			When I press add
			Then I should see 120 on the screen

		Scenario: subtraction
			Given I have entered 60 into the calculator
			And I have entered 30 into the calculator
			When I press sub
			Then I should see 30 on the screen

Este é o exemplo de uma história bem simples que o cucumber pode interpretar, as palavras chave apresentadas são:

• Feature
• Scenario
• Given
• And
• When
• Then

Estas mesmas palavras podem ser traduzidas para o portugues como:

• Funcionalidade
• Cenário
• Dado
• E
• Quando
• Então

Utilizando estas palavras chave, seria possível escrever esta história assim em portugues:

	Funcionalidade: Matemática Simples
		Para evitar erros idiotas
		Como um completo ignorante em matemática
		Eu quero que operações simples de matemática sejam resolvidas para mim

		Cenário: adição
			Dado que eu digite 50 na calculadora
			E que eu digite 70 na calculadora
			Quando eu precionar "Adicione"
			Então eu devo ver 120 na tela

		Cenário: subtração
			Dado que eu digite 60 na calculadora
			E que eu digite 30 na calculadora
			Quando eu precionar "Subtraia"
			Então eu devo ver 30 na tela

O legal é que esta histórinha poderia ser escrita por um usuário, as únicas regras reais são:

1. Começar as frases com as palavras chave definidas
2. Tentar utilizar as mesmas frases sempre que possível, isto vai facilitar na tradução do dialeto utilizado para Ruby

A estrutura que utilizei na descrição da funcionalidade não esta descrita em palavras chave por que ela não é interpretada pelo cucumber, é apenas uma descrição e o formato pode variar um pouco.

Mas por que utilizar esta ferramenta para testes em vez de qualquer outra?
Por que utilizar o cucumber como ferramenta de testes vai viabilizar uma abordagem BDD no desenvolvimento do seu sistema, e que isto vai te poupar muito dinheiro.

Seguem agora alguns argumentos (fora os que você pode retirar do texto)

• Presidente da empresa
  • Esta metodologia de desenvolvimento em conjunto com as ferramentas corretas vão poupar bastante dinheiro no desenvolvimento de sistemas
• Gerente
  • A integração entre as equipes de desenvolvimento e os clientes vai melhorar muito, isto vai fazer com que os clientes fiquem mais felizes com as entregas, possam acompanhar o progresso do desenvolvimento e entendam se o que esta sendo testado é o que realmente importa para eles melhorando a qualidade do que é entregue
• Arquiteto
  • Esta metodologia vai melhorar o entendimento da equipe sobre o que deve ser desenvolvido
• Desenvolvedores e Testadores
  • É legal trabalhar desta forma, e você vai trabalhar menos no final das contas o que é bom e ermite que você exercite a sua preguiça

Acho que era isto, falei um pouco de BDD, um monte de Cucumber e acho que consegui mostrar a idéia geral, mas isto vai ficar um pouco mais claro nos próximos posts sobre o Cucumber.
PS.: parabéns pela paciência se você leu até aqui

Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D

Cucumber e BDD – Vantagens para a empresa (Argumentos para o gerente, para o arquiteto, para o presidente da empresa, …)