Fev 1

Curiosidades sobre loops no Python

Escrito por Erko Bridee em 1, 2.0, 4, 6, action, Algoritmos, api, AR, BI, blog, C#, control, exemplo, Exemplos, for, futuro, html, ide, IE, if, int, Java, jogo, loop, mg, musica, O, on, oop, pt, RIA, Ria’s Geral, S+S, Teste, Tutorial, UI @ 02 1st, 2012 | via http://blog.erkobridee.com | Sem comentários

Atualmente tenho estudando Python devido a sua facilidade de implementa??o e me possibilitar codificar alguns algoritmos r?pidos, nessas brincadeiras me deparei com uma situa??o interessante, observei que a forma de trabalhar com loops no python, principalmente o for ? diferente do que estava acostumado no C e no Java…

1	for( int i = 0; i < length; i++ ) ...

segue o teste abaixo que fiz umas brincadeiras que me ajudaram a compreender como conseguir fazer algo como este for antigo, para os casos em que eu queira, por algum motivo, o ?ndice da intera??o…

Na documenta??o do Python, tem muito mais coisas legais, al?m de ser bem f?cil de compreender, com bastante exemplos de c?digo : Control Flow

Veja também:

Dez 18

Recomendação de Produtos em eCommerce

Escrito por Igor Musardo em .NET, 1, 2.0, 4, 6, action, analytics, AR, arte, Behavior, BI, blog, C#, carregar, class, cliente, consultoria, Destaque, Dica, Dicas, DRE, e-commerce, filter, filtra, fonte, for, Google, ide, IE, if, image, int, internet, layout, lista, Livro, Livros, Mercado, mg, NaN, O, on, procura, produto, pt, RIA, Ria’s Geral, S+S, site, Software, tag, TAT, Tema, Teste, UI, Vídeo, Vídeos, web, XP, zend @ 12 18th, 2011 | via http://www.igormusardo.com.br | Sem comentários

Sistemas de Recomenda??o procuram recomendar informa??o e produtos (como computadores, m?quinas fotogr?ficas, filmes, videos, m?sicas, livros, p?ginas de internet, etc.) que possam ser de interesse do usu?rio, esses sistemas procuram e identificam padr?es de interesse, perfil e consumo. A partir desses padr?es os sistemas de intelig?ncia artificial geram associa??es entre produtos e consumidores aplicando t?cnicas de filtragem colaborativa.

Com a ajuda dos sistemas de recomenda??o as vendas pela internet podem se aproximar do conceito criado por Jeff Bezos, presidente da Amazon, de “uma loja por cliente”. Pensar no usu?rio ? fundamental para manter-se num mercado t?o competitivo como a internet. N?o ? ? toa que a Amazon ? um dos e-commerce mais bem sucedidas da hist?ria.

Sistemas de Recomenda??o processam as informa??es que o usu?rio d? ao site durante a navega??o e entregam dicas de produtos relacionados aos gostos e interesses do consumidor, fazendo parte dos sistemas de Behavioral Targeting, ou Marketing Comportamental.

Por?m s? a utiliza??o de Intelig?ncia Artificial, Filtragem Colaborativa e outras t?cnicas computacionais n?o garantem o aumento de convers?o, pois o consumidor precisa impactado de maneira positiva pelas recomenda??es, a seguir voc? encontrar? dicas e melhores pr?ticas de como direcionar o usu?rio-consumidor para uma melhor compra.

Elementos de uma vitrine

T?tulo

Utilize cores diferenciadas do layout do site;
Utilize n?meros: “60% das pessoas” constroi um fator de confian?a na cabe?a do consumidor.

Cores

Utilize cores contrastantes que d?em destaque para a se??o de recomenda??o. Cuidado para n?o sobrecarregar, a se??o deve parecer como um an?ncio.

Produtos

Oferece sempre poucas op??es. Apenas 3 ou 4 recomenda??es s?o suficientes.

Chamada para a??o (Call-to-action)

Se voc? utilizar mais de uma chamada pra a??o, tenha uma como principal com maior destaque dentro da se??o de recomenda??o.

Melhores pr?ticas

Confira as melhores pr?ticas para conseguir um maior ?ndice de convers?o de suas vitrines de recomenda??o.

Menos sempre ? mais

Mostrando poucas recomenda??es, torna a decis?o do consumidor mais f?cil. Um bom n?mero de produtos na lista ? 3 ou 4, n?o fa?a uma lista grande. Tornar? a escolha muito mais dif?cil pelo internauta.

Tente o UpSell, pelo menos o Cross Sell

O prop?sito de fazer recomenda??es ? para aumentar o valor do pedido e/ou fazer a venda mostrando melhores op??es por um pre?o pr?ximo do produto visualizado.

Exclua Recomenda??es

Voc? n?o deve recomendar produtos antigos quando algu?m est? tentando comprar a ?ltima vers?o do mesmo produto. Seja mais criativo e venda mais.

Descontos funcionam

Ofere?a pacotes de produtos com descontes. Seus consumidores prezam pelo dinheiro. Com um lucro menor em alguns produtos, mas o valor de pedido maior garante uma boa margem.

Senso de urg?ncia

Quando oferecer um desconto ou valor especial, tire vantagem disso criando urg?ncia, dando um prazo curto para o consumidor efetuar a compra. Isso ir? aumentar os cliques e as convers?es.

Continue testando

Como garantir que essas pr?ticas funcionar?o e continuar?o funcionando em seu neg?cio? Continue testando permanentemente. Teste Chamadas para a??o, T?tulos, Cores, etc. Utilize softwares de testes gratu?tos como o Google Website Optimizer.

Sua loja utiliza sistemas de recomenda??es de produtos?

Sim? Compartilhe nos coment?rios quais as experi?ncias e resultados obtidos com suas vitrines.

Caso seu eCommerce n?o utilize, entre em contato comigo.

Fontes

Webinsider

Wikipedia

LiftSuggest

Dez 15

Injeção de Dependências nos DAOs de Entidades do Framework

Escrito por DClick Team em 1, 2.0, 4, 6, AR, arte, auto, BI, C#, class, err, exemplo, for, framework, git, Google, Hibernate, ide, IE, if, Java, Number, O, on, override, padrão, procura, Ria’s Geral, S+S, Sem categoria, Spring, string, Sun, super(), TAT, Teste, Twitter, UI @ 12 15th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Twitter!

A última implementação da HibernateDAOFactory do módulo persist do DCF, agora permite que seus DAOs de entidade possuam propriedades injetadas diretamente do container de beans do Spring.

No exemplo que temos nos testes de projeto, temos o MockDAO, que possui uma propriedade String com nome ‘testeString’:

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

public class MockDAO extends HibernateEntityDAO

private String testeString;

public MockDAO(SessionFactory sessionFactory)
super(MockEntity.class, sessionFactory);

@Override
protected Order getOrderForList()
return Order.asc(“number”);

public String getTesteString()
return testeString;

@Autowired
@Qualifier(“testeString”)
public void setTesteString(String testeString)
this.testeString = testeString;

}

Note que no setter da propriedade, colocamos a anotação @Autowired, para recuperar esta String do container, e também associamos o Qualifier ‘testeString’.

No arquivo de beans do spring, basta adicionarmos um bean String com o id igual ao do qualifier:

1
2
3

class=“java.lang.String” id=“testeString”>
-arg value=“stringTeste” />
>

Repare que o valor da String é ‘stringTeste’. Vamos ver em nosso teste agora se tal valor chega corretamente no DAO:

1
2
3
4
5
6
7
8
9
10

@Test
public void testRightFactory()
MockDAO dao = this.getDaoFactory().getDAO(MockEntity.class);
Assert.assertNotNull(dao);

Assert.assertEquals(this.getDaoFactory(), dao.getDaoFactory());

Assert.assertNotNull(dao.getTesteString());
Assert.assertEquals(“stringTeste”, dao.getTesteString());

Uma coisa importante a se perceber, é que a chamada da DAOFactory permanece exatamente a mesma, mantendo assim a retro-compatibilidade com as outras versões, e apenas as injeções baseadas em anotações do Spring vão ser consideradas.
NÃO é necessário apontar o component-scan do Spring para o pacote de DAOs de sua aplicação. A injeção de beans adicionais é feita completamente a parte, seguindo o mesmo padrão de nome e de instanciação dos DAOs.

Qualquer dúvida, basta me procurar.

O projeto está no github, dentro do módulo persist do dclick-framework, ou diretamente no nexus da DClick.

Dez 14

Testes Unitários com JUnit – De volta ao básico

Escrito por DClick Team em 1, 2.0, 4, 6, Air, AR, arte, C#, case, class, classe, classes, cliente, código, comparação, demo, Desenvolvimento, Design, Download, Eclipse, err, erro, exemplo, falha, Ferramenta, Flex, for, framework, Google, ide, IE, if, int, Introdução, Java, NaN, O, on, Opinião, Outros, padrão, Plugin, print, rest, RIA, Ria’s Geral, S+S, Sem categoria, site, string, Sun, super(), TAT, Tema, Teste, Twitter, UI, uint @ 12 14th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Twitter!

Já que ultimamente estamos falando bastante de testes unitários, principalmente aqui na DClick, vamos revisar uma das ferramentas essenciais para executar essa tarefa: JUnit. Mais especificamente, vamos fazer alguns testes com o JUnit 4.8.1, que pode ser encontrado para download no site do projeto, ou até mesmo no repositório do maven.
A proposta desse post é apresentar a ferramenta para quem ainda não conhece, e relembrar ou até mesmo mostrar algumas funcionalidades muito úteis para nosso dia a dia de desenvolvimento.

Um pouco sobre a nova versão

Nas versões anteriores do JUnit, da 3.* pra baixo para ser mais exato, era necessário criar as classes de testes seguindo uma hierarquia pré-definida do JUnit para que os testes fossem executados. Era necessário extender uma das classes de Test Case do JUnit, e seus métodos precisavam seguir um padrão de nome específico definido pelo framework.
Com a versão 4.* e a introdução ao suporte a Java 5, agora todas as configurações de testes unitários em JUnit são feitas via anotações, o que na minha opinião é muito mais rápido e fácil, tornando muito mais agradável e flexível escrever testes unitários. Agora é possível definir umahierarquia específica para os testes do projeto, podendo abstrair muitas inicializações e padrões do sistema, facilitando o reaproveitamento e aumentando a velocidade de desenvolvimento. Afinal a maior parte do tempo gasto em desenvolvimento é com os testes.
Porém, com anotações, perdemos o acesso direto aos métodos de asserção de valores que as super classes definiam. A solução adotada foi tornar todos esses métodos estáticos e públicos, em uma classe específica para guardá-los: org.junit.Assert.
Pode parecer uma solução não muito elegante do ponto de vista de código, e de fato não é quando consideramos código que será distribuído e deploiado, porém é uma solução que faz total sentido no escopo dos testes unitários, tornando fácil o uso e acesso a tais funcionalidades.

Asserções

Para testar nosso código, o JUnit fornece os métodos de assert. O conceito é muito simples, todo método de asserção recebe um valor que é o correto esperado pelo teste, e o outro valor que é o devolvido pelo seu código. A comparação é executada, e o teste falha caso sejam diferentes e passa caso sejam iguais. Apenas com esse conceito é possível testar todo o código, basta saber quais são os valores que devem ser testados para garantir o funcionamento do código.
A chave para escrever um teste unitário que cobre muito bem o seu código, é colocar as asserções nos valores realmente relevantes ao funcionamento do sistema. Algumas vezes por exemplo, não é preciso testar um valor intermediário gerado pelo código, apenas o resultado final, outras vezes esse valor intermediário gerado é crucial para o resultado final, e portanto deve ser verificado também.
Quando eu menciono ‘valores’, entenda que um valor pode ser qualquer objeto Java, portanto é muito importante implementar o equals e hashcode de seus objetos de resposta que serão testados pelo JUnit.

Exemplo Prático

Vamos criar um exemplo de classe de testes com o JUnit 4 para vermos como funciona na prática a execução de testes unitários.
Se você utiliza o Eclipse, você já possui instalado o plugin de execução de testes do JUnit, caso você não tenha tal plugin, recomendo que instale posi facilita muito a execução e depuração dos testes.
Vamos criar uma classe de testes:

1
2
3

public class JUnitTestCase

Repare que apesar do nome parecer que segue algum padrão, não é necessário que a classe tenha nenhuma dessas palavras em seu nome. Porém esta classe ainda não é uma classe de testes do JUnit. Para torná-la um teste, crie um método da seguinte forma:

1
2
3
4

@Test
public void metodoQualquer()

Repare na anotação org.junit.Test. Essa anotação diz que nosso método ‘metodoQualquer’ é um teste do JUnit. Perceba também que seu retorno é ‘void’ e ele não recebe nenhum argumento. Agora nossa classe é um teste propriamente dito. Simples assim. Vamos adicionar uma asserção agora para ver o funcionamento da mesma. Dentro do método que acabamos de criar, adicione a seguinte chamada:

1	Assert.assertEquals(“2 dividido por 2 deveria ser 1.”, 1, 2 / 2);

Repare que o primeiro argumento do método, é a mensagem que vai aparecer caso o método falhe. Mude o valor obtido (último argumento) para ver a mensagem de erro.
Esse é o básico de execução de testes. Por mais simples que possa parecer, esse é o ponto de partida. Agora existem outras funcionalidades qua ajudam a escrever testes mais complexos, por exemplo, se precisarmos criar um objeto mais complexo para nossos testes, fazemos o seguinte, adicione o seguinte código em nossa classe de testes:

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

private String stringLocal;

@Before
public void inicializaLocal()
System.out.println(“Inicializou.”);
this.stringLocal = “inicializada”;

@Test
public void testInicializadaLocal1()
Assert.assertEquals(“A String deveria estar inicializada.”, “inicializada”,
this.stringLocal);

@Test
public void testInicializadaLocal2()
Assert.assertEquals(“A String deveria estar inicializada.”, “inicializada”,
this.stringLocal);

@After
public void setaNull()
System.out.println(“Setou nulo.”);
this.stringLocal = null;

Rode o teste e veja o que aparece no console.
Repare que a String é inicializada e setada novamente pra ‘null’ 3 vezes. Isso porque nossa classe possui 3 métodos de testes, e os métodosanotados com @Before rodam sempre antes de todos os métodos de teste. O mesmo vale para os métodos anotados com @After, só que estes rodam depois de executar os métodos de teste.
Só com essas duas anotações é possível criar cenários que estão sempre ‘zerados’ e corretamente incializados para cada teste que será executado em sua classe. Perceba que com isso é possível separa melhor as asserções em suas classes em mais métodos, deixando mais específico e focado cada método de teste.
Porém algumas vezes queremos inicializar algum objeto para o teste todo, sem precisar de algo específico para cada execução. Nesse caso existem duas outras anotações que podem ser úteis. Adicione o seguinte trecho em nossa classe de testes:

1
2
3
4
5
6
7
8
9

@BeforeClass
public static void antesDeTudo()
System.out.println(“Executado Antes.”);

@AfterClass
public static void depoisDeTudo()
System.out.println(“Executado Depois.”);

Só existe um restrição com essa abordagem, e acho que está claro no código qual que é: o escopo dessas chamadas é estático. Repare que os métodos precisam ser estáticos, e portanto as incializações só servirão para propriedades que são estáticas em sua classe de testes.
Essa funcionalidade possui esse comportamento porque o JUnit instancia um novo objeto da sua classe de testes para cada método que será rodado, dessa forma ele garante um melhor isolamento dos testes, tornando-os mais unitários por assim dizer. Dessa forma somente métodos estáticos são garantia de execução antes de todos os outros métodos.
Rode o teste e veja a ordem das mensagens em seu console.

Próximos passos

Essa foi uma introdução muito simples do JUnit e testes unitários. Acho que já passou pela sua cabeça muitas formas de inicializar, integrar e rodar testes em sua aplicação usando JUnit, o que é ótimo, mas ainda existem boas práticas para criar testes assim como existem boas práticas para escrever código, afinal testes são linhas de código também.
O segredo de um bom teste unitário é o quanto ele consegue cobrir do funcionamento do código, sem que seja necessário escrever um teste extremamente detalhado que deixe o código acoplado demais, e não permita muita mudança no código original. Se você investir tempo demais testando TODOS os valores possíveis de suas classes de maneira extremamente detalhada, quando o cliente pedir que um requisito mude, você com certeza vai ter a sensação de trabalho jogado fora, e desânimo por ter que escrever tudo novamente. A idéia é utilizar padrões de design para testes unitários, de forma que se mantenha a cobertura de código no 85%+ e ainda deixe os testes bem flexíveis a mudança. Difícil mas não impossível, e sim, é muito mais difícil e trabalhosos escrever testes realmente bons, do que escrever o código que será testado.

Por @Gust4v0_H4xx0r

Dez 6

JodaTime – Java Date que funciona!

Escrito por DClick Team em .NET, 1, 2.0, 4, 6, api, AR, bar, BI, blog, C#, camp, class, classe, classes, código, control, Curso, Cursos, Design, Design Pattern, Diversos, Documentação, efeito, err, exemplo, Exemplos, falha, for, Google, Hibernate, html, ide, IE, if, image, int, interface, internet, Java, lógica, map, mg, O, on, online, Opinião, padrão, pattern, print, problema, RIA, Ria’s Geral, S+S, Sem categoria, singleton, string, Sun, TAT, Tema, Teste, try, Twitter, UI, uint, Vários, XP, zend @ 12 6th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Twitter!

JodaTime

Não existe segredo quando se fala da implementação de datas no Java: é ruim de usar. Alguns chegam a dizer que é errado usar inclusive, mas não serei tão extremo.
A API de datas do Java é ruim por vários motivos, como por exemplo, é mal documentada, não é Thread Safe, é difícil de manipular datas, e o comportamento nem sempre é o esperado.
Vamos ver como susbtituir a API de datas que vem Out of the Box no Java, por uma mais efetiva, amigável e confiável: JodaTime.

Lembrando do Calendar

Todo programador Java conhece o Calendar, e sabe que para usá-lo, basta seguir o Design Pattern singleton, ou seja, basta chamar o método de classe em Calendar que devolve a instância única do sistema para o Calendar.

Problema: não funciona.

Não funciona porque se a instância é singleton, e não utiliza threadlocking no código, então não é uma instância ThreadSafe. Logo toda vez que chamamos o getInstance() do Calendar, obtemos uma nova instância. Para ilustrar, crie um teste em JUnit 4 com o seguinte código:

1
2
3
4
5
6
7

Calendar calendar = Calendar.getInstance();

System.out.println(calendar.getTime());

Calendar calendar2 = Calendar.getInstance();

Assert.assertTrue(calendar == calendar2);

Rode o teste e veja a barra do JUnit ficar vermelha. O comparador ‘==’ usado em objetos, compara pelo endereço de memória, o que deveria ser o mesmo se fosse seguido o padrão singleton de verdade.
Pra piorar, todos os métodos que alteram as intâncias do Date estão expostos (por mais que estejam depreciados) para mantêr compatibilidade com versões anteriores da VM. Portanto o Date também não é ThreadSafe, pois não existe controle de concorrência em sua implementação.
Agora vamos deixar o Date e o Calendar de lado, e vamos ao JodaTime.

DateTime

O JodaTime diferencia muito bem os conceitos de data, instante de tempo, período, etc. A classe mais básica (interface no caso) é a ReadableInstant. Não precisa dizer que todas as modelagens de data implementam essa interface, permitindo comparar todos os tipos de modelagem de tempo pontuais. Um período não descreve um único instante ou ponto no tempo, por exemplo.
DateTime é talvez o ReadableInstant mais conhecido, e funciona muito parecido com o Date do Java.
Fatores que tornam o DateTime mais amigável são: é ThreadSafe pois é imutável, é muito bem documentado, e é muto fácil realizar operações com data. Vamos escrever um pouco de código para entender o que se passa.
Comece criando um DateTime. Como no Java, este DateTime criado possui o instante atual do sistema. Em seguida para efeito de teste (o teste pode falhar dependendo de quando for executado), adicione um dia na data criada, e verifique que o novo date aponta para amanhã:

1
2
3
4
5

DateTime date = new DateTime();

date = date.plusDays(1);

Assert.assertEquals(new DateTime().getDayOfYear() + 1, date.getDayOfYear());

Repare que tive que reassociar o date para que ele pudesse ser alterado, afinal DateTime é imutável, o mesmo comportamento que o BinInteger possui. Repare também que pra adicionar um dia, basta chamar plusDays. Este método já se encarrega de fazer toda a lógica de adicionar um dia na data, como por exemplo mudar o mês ou ano se for preciso, por isso se esse teste for rodado no dia 31 de dezembro, ele irá falhar pois o DateTime irá adicionar mais um dia a data, e perceberá que se trata do ano seguinte, e portanto getDayOfYear irá devolver ’1′, e não ’366′ ou ’365′ como esperado.
O JodaTime também trata anos bissestos e horário de verão se for selecionado o fuzo correto.
Existe uma API bem completa em DateTime para manipular todos os campos possíveis da data, sendo assim fica muito mais fácil iterar ao longo dos dias, sem precisar delegar pro Calendar a tarefa, e depois recuperar o resultado.
Não vou abordar muito da API do JodaTime, pois está muito bem documentada e existem muitos exemplos nas internet. O objetivo desse post é tratar do assunto do próximo tópico.

JodaTime e Hibernate

Pior que manipular datas, é persistir datas. Cada banco persiste data do seu próprio jeito, e cada implementação de ORM trata o Date do seu próprio jeito. Mas se você está utilizando o Hibernate, o JodaTime tem uma solução de padronização pra você: JodaTime Hibernate.
Com o JodaTime Hibernate é possível mapear diversos tipos de representação de data em suas classes Java, com ou sem TimeZone, como String ou bigint, como período ou duração, etc.
Para se ter uma idéia do que é possível, basta verificar a documentação online.
E para utiliza é muito fácil. Imagine que você tenha uma entidade com um campo DateTime, que se chama entryDate, portanto temos o getter:

1
2
3
4

@Column(nullable = false)
public DateTime getEntryDate()
return entryDate;

Para tornar este DateTime uma data que é padrão do banco que será utilizado, por exemplo, basta adicionar a seguinte anotação:

1
2
3
4
5

@Column(nullable = false)
@Type(type = “org.joda.time.contrib.hibernate.PersistentDateTime”)
public DateTime getEntryDate()
return entryDate;

Estamos falando para o hibernate utilzar o tipo de coluna descrito pelo PersistentDateTime, e utilizar o mesmo para converter a data novamente para DateTime quando for recuperado.
Caso você esteja fazendo engenharia reversa de algum banco, recomendo ler a descrição de todos os tipo disponíveis pra fazer a melhor escolha.
Com isso conseguimos obter todos os benefícios do JodaTime em nossas entidades, facilitando controlar as datas no domínio de nossas aplicações.

Espero ter despertado sua curiosidade com o JodaTime. Na minha opinião é uma das melhores bibliotecas Java disponíveis, mas não quero falar muito sobre suas funcionalidades, pois um dos pontos mais fortes da biblioteca é a facilidade de se acostumar com ela, e principalmente utilizar todos seus recursos. Quero que vocês tenham um pouco desse gostinho .

Por @Gust4v0_H4xx0r

Dez 5

Play Framework – alta produtividade em Java

Escrito por Erko Bridee em .NET, 1, 2.0, 4, 6, action, Adobe, Adobe Flex, apache, api, AR, Arquitetura, BI, blog, browser, C#, case, class, cliente, Componente, Componentes, control, Controles, CRUD, css, Curso, Cursos, dados, Desenvolvedor, desenvolvedores, Desenvolvimento, Desktop, Dica, Download, Eclipse, email, engine, err, erro, exemplo, Exemplos, Flex, Flexmania, for, framework, Frameworks, gae, Geral, git, Google, Hibernate, html, ide, IE, if, image, imagens, int, internet, Java, JPA, Links, mg, mvc, novidade, Novidades, O, on, Outros, produtividade, rails, rest, RIA, Ria’s Geral, ruby, ruby on rails, S+S, server, servidor, site, state, tag, TAT, Tema, template, Teste, Tree, Tutorial, UI, UX, Ved, web, Web Service, XML, XP @ 12 5th, 2011 | via http://blog.erkobridee.com | Sem comentários

O Play ? um framework open source para aplica??es web, escrito em Java, que possibilita o desenvolvimento de aplica??es web que seguem o padr?o MVC. Tem por objetivo otimizar a produtividade do desenvolvedor atrav?s do uso de configura??o sobre conven??o (CoC). Com recompila??o feita durante a execu??o da aplica??o, e caso ocorra algum erro, o respectivo ? exibido no browser, indicando a linha do erro.

Aten??o: o objetivo desse post ? realizar uma vis?o geral do que se trat? o Play Framework que temos ouvidos os coment?rios na internet.

O Play Framework torna o desenvolvimento de aplica??es Java e Scala uma tarefa f?cil para o desenvolvedor.

Site: Play Framework

Descubra uma alternativa limpa e leve para as atuais aplica??es Java Enterprise. O Play ? focado na produtividade do desenvolvedor e tem por alvo a arquitetura RESTFul.

Apesar do Play ter sido escrito em Java, ele suporta a linguagem Scala desde a vers?o 1.1 (hoje[Dezembro/2011] est? na vers?o 1.2.4). Este ano a empresa Typesafe (respons?vel pela linguagem Scala), anunciou a aquisi??o do Play Framework e este ser? mantido pela empresa. Uma das novidades relacionado a este anuncio ? que a vers?o 2.0 o n?cleo do Play Framework est? sendo totalmente reescrito em Scala.

Um v?deo para uma breve apresenta??o do Play Framework: Desenvolcendo uma aplica??o web em 10 minutos

Motiva??o

O Play foi muito inspirado no Ruby on Rails e Django. Um desenvolvedor familiarizado com qualquer um desses 2, ir? se sentir em casa.

Algo que ? fato, Ruby on Rails e Django s?o produtivos, ent?o por que n?o ter o mesmo n?vel de produtividade com java?

O Play utiliza do poder das aplica??es Java, por?m sem o “sofrimento” necess?rio para o desenvolvimento de aplica??es centradas no modelo Java Enterprise. Libertando das metodologias e ideologias relacionadas ao desenvolvimento de aplica??es Java EE, o Play prove para os desenvolvedores uma maneira f?cil e elegante de trabalhar, visando o aumento da produtividade.

Caso voc? queria, basta um editor de c?digo e ser? mais que o suficiente para o desenvolvimento de aplica??es, chega a ser incr?vel pensar que conseguiremos desenvolver aplica??es Java Web sem a necessidade de um IDE (Eclipse, Netbeans, …), mas vale lembrar, que estas IDE's ainda possuem seus atrat?vos e auxiliam em nossa produtividade.

Apesar de que as aplica??es desenvolvidas com o Play, foram projetadas para executar dentro do JBoss Netty Web Server, as aplica??es podem ser empacotadas em arquivos WAR e distribu?das para outros servidores de aplica??es Java EE (ex.: Apache Tomcat).

Maiores diferen?as com os demais frameworks

Stateless: o Play ? totalmente RESTful – n?o existe conex?o por sess?o Java EE. Isto torna o Play muito mais escal?vel que os demais frameworks.

Sem configura??o: realizar o download, descompactar e desenvolver.

F?cil ida e volta: sem necessidade de deploy no servidor de aplica??o, apenas edite o c?digo e atualize o browser.

Teste unit?rio integrado: suportes nativos para JUnit e Selenium.

API elegante: raramente um desenvolvedor ter? a necessidade de importar alguma lib. O Play j? disponibiliza a maioria dos recursos necess?rios para o desenvolvimento de uma aplica??o.

M?todos est?ticos: todos os controles de entrada e m?todos de neg?cio s?o declarados como est?ticos. E isto ? de fato bem diferente o que vemos nos demais frameworks Java.

I/O Ass?ncrona: atrav?s do uso do servidor web JBoss Netty, o Play consegue disponibilizar e tratar uma enorme quantidade de requisi??es ass?ncronas.

Arquitetura Modular: assim como Rail e Django, o Play utiliza o conceito de m?dulos. O que possibilida um meio elegante e simples de expandir o core do Play.

M?dulo CRUD: f?cil constru??o de UI administrativas com pouco c?digo.

M?dulo Scala: disponibiliza um suporte completo para Scala.

Componentes

O Play utiliza massivamente algumas bibliotecas populares:

JBoss Netty para o servidor web.
Hibernate para a camada de dados.
Groovy para a os templates.
O compilador do Eclipse para atualiza??o da aplica??o sem necessidade de realizar um deploy da aplica??o para testar as altera??es (hot-reloading).
Apache Ivy para gerencimanto de dependencias.

Funcionalidades presentes no n?cleo do Play:

Um framework RESTful limpo e leve.
CRUD: um m?dulo para simplicifar a edi??o de modelos de objetos.
Secure: um m?dulo para habilitar um sistema de autentifica??o de usu?rios.
Um framework de valida??o baseado em anota??es.
Um Job Scheduler (agendamento de tarefas).
Suporte para emails SMTP de maneira simples.
Suporte para JSON e XML.
Uma camada de persist?ncia baseada em JPA.
Uma base de dados embutida para r?pido deploy e testes da aplica??o.
Um framework completo para realiza??o de testes.
Funcionalidade para upload de arquivos.
Suporte para m?ltiplos ambientes de desenvolvimento.
Uma poderosa engine de templates baseadas em Groovy com templates, hierarquias e tags.
Arquitetura modular, que possibilita criar novas funcionalidades para o n?cleo facilmente.
Suporte para OpenID e clientes de Web Service.

Links ?teis

Informa??es a mais da Wikipedia

Overview do Play Framework 1.2.4

Documenta??o Play Framework 1.2.4

A documenta??o foi algo que achei interessante, me parece bem completa com bastante exemplos e informa??es de como utilizar as funcionalidades presentes no Play Framework.

Suporte para a linguagem Scala

Utilize a IDE de sua prefer?ncia (Eclipse, Netbeans, …)

Se por um acaso voc? utilize o Sublime Text 2, veja esse suporte para este editor de c?digo [github]

Reposit?rio de M?dulos

Dentre eles temos: MongoDB, GAE, Gera??o de PDF, GWT, SASS e SCSS, entre outros.

E agora?

Bom agora que j? temos uma boa id?ia do que se trata o Play Framework ? baixar e come?ar a testar e ver se na pr?tica ele ? bom mesmo.

Hora de fazer o download, instalar e colocar a m?o no c?digo: Tutorial para seguir e ver uma aplica??o do in?cio at? o “fim”

Eu particularmente ainda possuo algumas quest?es em aberto para descobrir as respostas, dentre elas est? uma: - Como ? que eu utilizo o Play Framework em um projeto com uma equipe? At? o momento s? tenho visto casos onde s?o apresentados desenvolvimetno de aplica??es r?pidas, por?m com um ?nico desenvolvedor…

No meu caso eu vou atr?s dessa reposta.

Veja também:

Nov 16

LCCS e PHP com ZendAMF

Escrito por Leonardo França em .NET, 1, 2.0, 4, Adobe, AMF, amfphp, AR, Artigo, Artigos, C#, catch, class, classe, classes, developer, Documentação, exemplo, Exemplos, flash, Flex, Flex 4, for, framework, function, handle, image, int, Java, Javascript, live, LiveCycle, Mercado, mg, O, on, Password, PHP, player, portal, programação, pt, rest, RIA, Ria’s Geral, S+S, SDK, server, swf, Teste, try, UI, web, zend, zendAMF, zendFramework @ 11 16th, 2011 | via http://www.leonardofranca.com.br | Sem comentários

O Adobe LiveCycle Collaboration Service possui em seu SDK, exemplos de integração com as principais linguagens de programação web do mercado como PHP, Java, Python, etc.
Na documentação da Adobe, é recomendado o uso do AMFPHP ou o PHP puro mesmo, mas nada impede de usar tranquilamente em conjunto com o ZendFramework (usando ZendAMF)
Ryan Stewart escreveu dois artigos mostrando a implementação com PHP e REST.

Uma observação sobre o artigo de Ryan, no Flex 4, Adobe passou a usar o swfobject, então o modo de pegar os parâmetros via URL e passar para o SWF fica desse modo:

PLAIN TEXT

JAVASCRIPT:

var xiSwfUrlStr = “playerProductInstall.swf”;
var flashvars = ;
flashvars.roomURL = swfobject.getQueryParamValue(“roomURL”);
flashvars.authToken = swfobject.getQueryParamValue(“authToken”);
var params = ;

No SDK do LCCS, existe um arquivo chamado lccs.php, basta copiar para o mesmo diretório em que você já usa suas classes. Em seguida, adicionar o include no arquivo gateway.php

PLAIN TEXT

PHP:

require_once ‘Zend/Amf/Server.php’;
require_once ‘lccs.php’;
require_once ‘Test.php’;
/** Bootstrap */
// Instantiate server
$server = new Zend_Amf_Server();
$server->setProduction(false);
$server->setClass(‘Test’);
// Handle request
echo($server->handle());
?>

E está é uma simples classe para teste chamando o método que retorna o token para autenticação.

PLAIN TEXT

PHP:

class Test
private $account;
private $room;
private $devUsername;
private $devPassword;
private $secret;
//$accountURL = “https://collaboration.adobelivecycle.com/$account”;
private $accountURL;
private $roomURL;
function __construct()
//for LCCS
$this->account = “Your SDK account username from LCCS developer portal”;
$this->room = “The room you want to connect to”;
$this->devUsername = “Your LCCS developer account username”;
$this->devPassword = “Your LCCS developer account password”;
$this->secret = “The shared secret from the LCCS developer portal”;
//$accountURL = “https://collaboration.adobelivecycle.com/$account”;
$this->accountURL = “http://connectnow.acrobat.com/$this->account“;
$this->roomURL = “$this->accountURL/$this->room“;
public function getToken($data=array())
try
$this->account = new RTCAccount($this->accountURL);
$this->account->login($this->devUsername,$this->devPassword);
$session = $this->account->getSession($data['room']);
$displayName = $data['displayName'];
$username = $data['username'];
$role = $data['role'];
$token = $session->getAuthenticationToken($this->secret, $displayName, $username, $role);
return $token;
catch (Exception $e)
throw new Exception($e->getMessage());
}
}
?>

Nov 16

Spring 3.1 RC1 – @Configuration

Escrito por DClick Team em 1, 2.0, 4, 6, action, app, AR, auto, bar, BI, blog, busca, C#, case, class, classe, classes, código, components, configuração, err, erro, error, exemplo, for, framework, Google, IE, if, int, Java, lite, map, mudanças, mvc, NaN, O, on, Plugin, refresh, rest, RIA, Ria’s Geral, RoR, S+S, Sem categoria, Spring, SpringFramework, string, Sun, super(), tag, TAT, Teste, Twitter, UI, uint, web, XML @ 11 16th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Twitter!

Spring @Configuration

O que há de novo

Para habilitar certas funcionalidades do Spring que envolvem AOP, era preciso escrever tags XML como por exemplo context:component-scan para especificar os pacotes em que o Spring pode buscar por beans anotados com @Component, @Repository ou @Service.
Na versão 3.1 foram disponibilizadas as mesmas funcionalidades via anotação. São elas:

1
2
3
4
5
6
7
8

org.springframework.context.annotation.Configuration
org.springframework.context.annotation.ComponentScan
org.springframework.context.annotation.EnableLoadTimeWeaving
org.springframework.context.annotation.EnableAspectJAutoProxy
org.springframework.scheduling.annotation.EnableScheduling
org.springframework.scheduling.annotation.EnableAsync
org.springframework.transaction.annotation.EnableTransactionManagement
org.springframework.web.servlet.config.annotation.EnableWebMvc

Vamos abordar o caso básico, pois o resto é bem similar.

@ComponentScan

Caso você ainda não esteja familiarizado com as configurações por anotaçãoo, vamos ao básico.
Comece criando uma classe que representará seu container de beans, e a anote com @configuration:

1
2
3
4

@Configuration
public class TestConfiguration

Nesta classe estarão os beans que o container irá instanciar e deixar a nossa disposição.
Para iniciar o container vamos criar um test (JUnit 4) que instancia o contexto:

1
2
3
4
5
6
7
8
9
10
11

public class ConfigurationTestCase

@Test
public void testConfigurationBeans()

AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
ctx.register(TestConfiguration.class);
ctx.refresh();

}

Aqui criamos um container do tipo AnnotationConfigApplicationContext e registramos nossa classe de configuração nele. Repare que é possível registrar mais classes, e portanto disponibilizar mais beans no container.
Agora vamos criar nosso bean de teste:

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

public class GenericBean

private String testProperty;

public GenericBean(String testProperty)
super();
this.testProperty = testProperty;

public String getTestProperty()
return testProperty;

}

Vamos criar os métodos em nossa classe de configuração que instanciam nosso bean de duas maneiras diferentes:

1
2
3
4
5
6
7
8
9

@Bean(name = “testBean”)
public GenericBean genericTestBean()
return new GenericBean(“test”);

@Bean(name = “otherBean”)
public GenericBean genericOtherBean()
return new GenericBean(“other”);

Repare que a única diferença entre os dois é a String que passamos como parâmetro.
Agora que temos 2 beans diferentes em nosso container, vamos criar os testes para verificar o comportamento do Spring. Abaixo da inicialização do contexto, vamos adicionar as seguintes linhas:

1
2
3
4
5
6
7
8
9

GenericBean testBean = ctx.getBean(“testBean”, GenericBean.class);

Assert.assertNotNull(testBean);
Assert.assertEquals(“test”, testBean.getTestProperty());

GenericBean otherBean = ctx.getBean(“otherBean”, GenericBean.class);

Assert.assertNotNull(otherBean);
Assert.assertEquals(“other”, otherBean.getTestProperty());

Aqui estamos garantindo que nossos dois beans diferentes estarão no contexto como esperado.
Antes de rodar o teste, será necessário adicionar a dependência do CGLib ao seu projeto. Caso você esteja usando o maven, basta adicionar a seguinte dependência>

GeSHi Error: GeSHi could not find the language text (using path C:Program Fileswampwwwblogwp-contentpluginsig_syntax_hilitegeshi) (code 2)

Pronto, com isso temos o suficiente pra deixar a barra do JUnit verde. Vamos agora adicionar o @ComponentScan.
Em nossa classe de configuração (poderia ser qualquer outra registrada no contexto) adiciona a seguinte anotação:

1
2
3

@Configuration
@ComponentScan(“br.com.dclick.tentativas.configuration.beans”)
public class TestConfiguration

No meu caso meu bean está dentro do pacote br.com.dclick.tentativas.configuration.beans e portanto basta eu alterá-lo adicionando o seguinte código:

1
2
3
4
5
6
7
8

@Component(“componentBean”)
public class GenericBean

private String testProperty;

public GenericBean()
this.testProperty = “component”;

Dessa forma posso criar mais um teste e verificar que o bean está vindo corretamente:

1
2
3
4

GenericBean componentBean = ctx.getBean(“componentBean”, GenericBean.class);

Assert.assertNotNull(componentBean);
Assert.assertEquals(“component”, componentBean.getTestProperty());

Rode o teste e deixa o JUnit feliz.
A única coisa a se ter cuidado aqui, é que com @ComponentScan, você não pode mapear o diretório da própria classe de configuração.

Demais Configurações

Daqui em diante basta anotar suas classes de configuração com as configurações que você deseja ativar, como por exemplo @EnableAsync que permite que os beans rodem de maneira assíncrona com a anotação @Async.

Brinque um pouco com as outras anotações. Acredito que vale o esforço, pois esse tipo de configuração permite abandonar um pouco os arquivos XML e tornam mais fácil o refactor dos beans, afinal teremos erros de compilação com as mudanças de código.

Por enquanto é isso, qualquer dúvida mande nos comentários que responderei assim que possível.

Por @Gust4v0_H4xx0r

Nov 11

Minha opinião atual sobre a “Morte do Flash”

Escrito por Erko Bridee em .NET, 1, 2.0, 2009, 3d, 4, 6, action, Adobe, Adobe Air, Air, Ajax, Android, api, AR, Arquitetura, back, BI, blog, Blogs, browser, C#, class, cliente, css, css3, demo, Desenvolvimento, entrevista, err, facebook, Ferramenta, flash, Flash Player, for, game, git, html, html5, ide, IE, image, int, internet, jandersonfc, jandersonfc.com, Java, Javascript, jogo, Jogos, Mercado, mg, mobile, O, on, player, Projetos, prova, pt, Redes Sociais, Revistas, Ria’s Geral, S+S, site, SmartPhone, Sun, Tecnologia, Tema, tendencia, Teste, Twitter, UI, vs, web, zend @ 11 11th, 2011 | via http://blog.erkobridee.com | Sem comentários

Nesses ?ltimos dias a internet est? virada em um caos depois dos boatos e anuncio da “Morte do Flash” (descont?nuo do Flash Player para disposit?vos m?veis, leia-se smartphones e tables Android/RIM), todo um medo gerado pelo combo da not?cia com a demiss?o de 750 funcion?rios da Adobe (EUA e Europa)

Minha real opini?o ? a seguir:

No mais, os projetos continuam, novos desafios est?o surgindo, novas oportunidades de ganhar dinheiro continuam aparecendo constantemente, nada de mimimi, bora usar HTML5, e que tecnologia for…

Roubando a frase do @jandersonfc disse no final desse post: As tend?ncias s?o suas aliadas

“Tecnologia, Ferramentas e metodologia s?o o meio, dinheiro no bolso ? o fim”

Se voc? ainda est? preocupado sobre a tal morte do Flash no mobile, recomendo ler o post: Adobe desiste do Flash Player plug-in para dispositivos m?veis do @igorcosta e reflita no seu texto.

Agora se voc? j? estava jogando a toalha achando que o Flash j? era, se voc? estava fechando o “caix?o”, pode executar um rollback ai, pois ontem (10/11/2011) foi disponibilizado o novo Flash Player 11.1 e AIR 3.1. Tenha em mente que a plataforma Flash ainda ter? um bom tempo de vida. Motivo banal pelo qual n?o ir?o conseguir matar o Flash, digo que talvez esse mundo mobile tenha at? que readerir ao Flash : games, ainda mais agora com o novo suporte a acelera??o gr?fica e a 3D. Outro grande motivo, se “matarem” o Flash Player hoje haver? uma revolta mundial dos jogadores do jogos do Facebook e demais redes sociais, tamb?m sabemos que o HTML5 est? a anos luz de dist?ncia da maturidade e capacidade do Flash Player atual, ent?o o Flash Player n?o morrera.

Algo que eu tenho em mente, quando penso no assunto, eu lembro da mesma agita??o que foi na ?poca do Ajax, no final aqui estamos n?s usando o Flash ao invez do Ajax para desenvolver sistemas robustos. O HTML5 para sites e algumas outras coisas at? que j? tem como utilizar, mas creio que vamos chegar na mesma situa??o que nos deparamos a alguns anos atr?s e recorreremos a algo como o Flash que ? mais robusto para desenvolvimento de sistemas.

Algu?m me diz como ? que eu fa?o uma arquitetura organizada, com pacotes no JavaScript?

Algu?m sabe se existe alguma maneira de trabalhar com IoC no JavaScript?

Fora outras quest?es para as quais n?o tenho resposta de como fazer usando HTML5 + JS + CSS3

Lembrando que a compatibilidade crossbrowser do HTML5 ? um pesadelo [mobile] [web browsers teste] [demos teste]

N?o estou dizendo que sou contra o HTML5, mas hoje ele ainda ? muito imaturo para desenvolver, leia bem: sistemas

E como n?o devemos nos apegar a tecnologia alguma, muito menos rejeitar qualquer outra que o mercado est? aderindo, recomendo o HTML5 Rocks para quem quizer estudar o HTML5.

No mais, n?o se desespere com as not?cias que voc? l? na internet, mas mantenha-se sempre atualizado, pois quem escolhe que tecnologia voc? ir? utilizar no pr?ximo projeto, provavelmente ser? o seu cliente, pedindo se roda no iPad…

Veja também:

Nov 8

Spring 3.1 RC1 – Cache Abstraction

Escrito por DClick Team em 1, 2.0, 4, 6, action, app, AR, Arquitetura, Banco de Dados, BI, blog, C#, cache, class, classe, configuração, dados, Documentação, Download, err, erro, exemplo, for, framework, Google, html, ide, IE, if, int, interface, Java, lite, map, mapa, O, on, Outros, padrão, pt, reference, RIA, Ria’s Geral, S+S, Sem categoria, site, Spring, Spring Framework, SpringFramework, string, Sun, tag, TAT, Teste, Twitter, UI, uint, XML, zend @ 11 8th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Twitter!

Spring Cache Abstraction

Abordamos um das novas funcionalidades do Spring 3.1 RC1, profiles e environments. Ainda existem outras funcionalidades, mas hoje iremos dar uma olhada em Cache Abstraction.

Cache Abstraction é literalmente uma abstração out of the box para adicionar uma camada de cache sobre seus beans, usando uma arquitetura AOP para gerenciar o que deve e o que não deve ser feito o cache.
Usar a nova camada de cache é muito fácil se você já está habituado com Spring, e veremos uma das diferentes maneiras de configurar seus beans.

Baixando a Denpendência

Para quem utiliza maven, basta adicionar a seguinte dependência no pom do seu projeto:

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

>
>
>org.springframework.maven.milestone>
>Spring Maven Milestone Repository>
>http://maven.springframework.org/milestone>
>
>

>
>
>org.springframework>
>spring-core>
>3.1.0.RC1>
>
>
>org.springframework>
>spring-context>
>3.1.0.RC1>
>
>

Se você perferir, pode baixar os jar direto do site do spring.
Sem segredos aqui, basta adicionar as dependências ao projeto e está pronto para usar.

Entendendo o funcionamento

A maneira com que o cache funciona é bem simples. Você pode enxergar o cache como um mapa chave-valor, onde a chave é o conjunto de argumentos do seu método, e o valor é o valor devolvido pelo seu método. Pensando assim fica fácil entender o funcionamento que irei mostrar no exemplo.
Referente a configuração do Spring, é necessário instanciar um gerenciador de cache, ou na linguagem spring, cacheManager. Existe algumas implementações de cache manager disponível no spring, portanto iremos utilizar uma delas em nosso exemplo.
Vamos escrever um teste unitário com JUnit 4.8.1 para ilustrar o comportamento do cache.
Comece criando um arquivo padrão de beans do spring, mas com um namespace a mais:

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

>
Repare que estamos utilizando o namespace de cache além dos usuais.
A única configuração que iremos fazer aqui, é a do cache manager. Crie um bean da classe >SimpleCacheManager> e adicione o seguinte bean como cache gerenciado:
>
cc lang=”XML”
public interface CacheableTest

@CacheEvict(value = “property”, allEntries = true)
void evictCache();

@Cacheable(“property”)
String getForCache(String s);

String getProperty();

void setProperty(String property);

Repare no getter e setter que usaremos no teste, e na anotação @Cacheable(“property”). Esta anotação está dizendo que o valor que este método devolver será armazenado no cache que configuramos previamente como property. Fato importante é que este valor é referente ao argumento passado como parâmetro no método.
A outra anotação @CacheEvict(value = “property”, allEntries = true) descreve o método que chamaremos para esvaziar o cache. Note que passamos o nome do cache, e que ele deve limpar todos os valores.
É importante notar também que pode ser passado mais de um nome de cache em ambas as anotações.
Uma implementação básica para nosso bean pode ser:

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

@Component(“cacheBean”)
public class CacheableBean implements CacheableTest

private String property;

public String getForCache(String s)
return this.property;

public String getProperty()
return property;

public void setProperty(String property)
this.property = property;

public void evictCache()
// Não faz nada

}

Estou usando o package scan para instanciar o bean. Agora nosso teste:

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

public class CacheTest

@Test
public void testCache()

ApplicationContext ctx = new ClassPathXmlApplicationContext(
“spring31-test-beans.xml”);

CacheableTest bean = ctx.getBean(“cacheBean”, CacheableTest.class);

bean.setProperty(“teste”);

Assert.assertEquals(“teste”, bean.getProperty());
Assert.assertEquals(“teste”, bean.getForCache(“a”));

bean.setProperty(“teste2″);
Assert.assertEquals(“teste2″, bean.getProperty());
Assert.assertEquals(“teste”, bean.getForCache(“a”));
Assert.assertEquals(“teste2″, bean.getForCache(“b”));

bean.setProperty(“teste3″);
Assert.assertEquals(“teste3″, bean.getProperty());
Assert.assertEquals(“teste”, bean.getForCache(“a”));
Assert.assertEquals(“teste2″, bean.getForCache(“b”));

bean.evictCache();
bean.setProperty(“teste4″);
Assert.assertEquals(“teste4″, bean.getProperty());
Assert.assertEquals(“teste4″, bean.getForCache(“a”));
Assert.assertEquals(“teste4″, bean.getForCache(“b”));

}

O arquivo de beans se chama spring31-test-beans.xml.
Repare que estamos invocando o método getForCache passando alguns valores diferentes, e o valor devolvido é sempre igual, mesmo que depois setamos um valor diferente ao bean. Para atualizar o valor e limpar o cache, basta invocar o método evictCache que havíamos anotado com @CacheEvict.
Vale a pena brincar um pouco com o funcionamento do cache, e até mesmo criar outros caches e ver o comportamento do evict em diferentes métodos.

Últimas Considerações

As mesmas configurações que fizemos com anotações, pode-se fazer direto no XML. Não entrarei no detalhe pois o funcionamento é exatamente o mesmo, mas se você preferir basta olhar a documentação que é bem straightforward.
Lembre-se que esta camada de cache não possui nenhuma relação com o banco de dados, e deve ser usada com muito cuidado em tais casos, pois alguns erros de concistência podem aparecer devido a um cache desatualizado.
Vale a pena brincar com o cache manager, pois o spring suporta o uso do EhCache, o que pode ser muito útil se você já possui alguma configuração pré-definida para sua aplicação.

Por enquanto é isso, qualquer dúvida mande nos comentários que responderei assim que possível.

Por @Gust4v0_H4xx0r

« Entradas anteriores |