Em uma outra quest?o do site rankk.org foi apresentado a sequinte quest?o, solicitando para encontrar um respectivo valor em uma posi??o dada uma sequ?ncia:
1,1,2,3,5,8,13,21,34,55,89 …Qual ? o 119 termo?
Observando a sequ?ncia, temos uma sequ?ncia de fibonacci (wikipedia), ent?o sabendo isso, partindo do algoritmo de c?lculo de fibonacci, bastou alterar o algoritmo para realizar o c?lculo at? a respectiva posi??o.
Uma outra quest?o inicial do site rankk.org para possibilitar o cadastro no site, foi apresentada a seguinte situa??o:
Uma caixa cont?m alguns bot?es. 1/4 desses s?o pretos, 1/8 s?o vermelhos e os demais s?o brancos. Sabendo que nesta caixa temos 636 bot?es brancos a mais que os vermelhos. Quantos bot?es tem nesta caixa?
A primeira coisa a se fazer ao ver a quest?o foi identificar, do que se trata esse c?lculo, e eu com meu c?rebro enferrujado sem utilizar para c?lculos matem?ticos durante muito tempo, patinei legal, nessa mesma ?poca o @jandersonfc tamb?m estava resolvendo essa mesma situa??o, no caso ele identificou antes do que eu, que este problema se tratava de uma equa??o de primeiro grau, depois disso para resolver o problema foi tranquilo.
O que resultou na brincadeira abaixo:
Ontem resolvendo um dos desafios do site http://www.rankk.org/ me deparei com a seguinte quest?o:
Sabendo que para passar da primeira fase ? necess?rio resolver 9 desafios de um total de 60, quantas combina??es de resolu??o de 9 quest?es s?o poss?veis, n?o considerando a ordem na qual ser?o resolvidas?
Observei que se tratava de uma quest?o matem?tica de combina??o, com isso, inicialmente resolvi o c?lculo de maneira tradicional, depois resolvi criar o respectivo algoritmo abaixo, onde defini uma fun??o em python para realizar o c?lculo fatorial, com a possibilidade de definir um limite, o que me era necess?rio para codificar o algoritmo do c?lculo de combina??o.
Segue links sobre Fatorial e Combina??o.
SharedObject é um recurso que dar ao Flash Player a capacidade de salvar dados localmente para poder ser usado posteriormente em sua aplicação, a grosso modo é como um cookie. Com o Flash Media Server, foi introduzido a possibilidade de usar o SharedObject Remote, no qual os dados são salvos no servidor Flash Media Server e compartilhados para todas as instâncias de uma conexão entre o Flash Player e o Flash Media Server. Isso possibilita a criação de aplicativos em real time como Dashboards, chats e o que mais a imaginação permitir.
O uso do SharedObject Remote pode ser usado de duas maneiras em conjunto com o Adobe Flash Media Server.
Vejamos o primeiro caso:
Caso você não tenha conhecimento para usar a linguagem Server-side do Flash Media Server, é possÃvel utilizar o SharedObject Remote somente pelo ActionScript 3.0. Vamos a um exemplo clássico sharedBall, onde o objetivo é compartilhar as posições da bolinha a atualizar nos outros clientes conectados a mesma instância.
Feito isso, podemos testar o swf apertando Ctrl+Enter, se tudo correr bem, deveremos ter a seguinte mensagem no output do Flash:
NetConnection.Connect.Success
Com a conexão feita, podemos instanciar o nosso SharedObject Remote para compartilhar as posições de x e y da bolinha.
O handlerSync é responsável por atualizar os dados de x e y pegaremos do SharedObject Remote:
Daremos a opção de ao clicar na bolinha, que ela possa ser arrastável, em seguida atualizaremos as posições de x e y no SharedObject Remote:
Segue o código completo:
Veja uma demostração em funcionamento:
O artigo Adobe Flex com PHP usando ZendAMF – primeiros passos teve como objetivo exemplificar a integração do Flex com PHP para quem já tinha sistemas desenvolvidos usando o AMFPHP, por isso não usei as classes para acesso a banco de dados do ZendFramework. Neste artigo mostrarei o mesmo exemplo mas usando exclusivamente ZendFramework.
Pegarei o mesmo exemplo utilizado no artigo anterior, só modificando a classe PHP para usar as classes de abstração de banco de dados do ZendFramework. Começaremos com nosso gateway.php
Executando o link no seu navegador, deve aparecer a seguinte mensagem:
Zend Amf Endpoint
Em seguida, modificaremos em nossa classe principal, que efetuará as operações de listar, inserir, apagar e atualizar os dados do nosso banco:
No ActionScript só precisaremos mudar o que será passado para o PHP, ao inves de VOs, mandaremos Arrays:
Referências:
http://framework.zend.com/manual/en/zend.db.adapter.html
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.
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.
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.
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 @Test @Test @After |
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 |
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.
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
Uma das vantagens de utilizar a arquitetura do Spring para implementar projetos Web, é fazer uso do Sprin-WEB-MVC. Quem já usou sabe que isso é uma vantagem a se considerar quando for feita a escolha das tecnologias e frameworks que serão utilizados no projeto.
Spring WEB-MVC é uma abstração poderosa para a camada de apresentação, tornando muito flexÃvel o uso de diferentes tipos de tecnologias no frnt-end da aplicação.
Veremos uma dessas abstrações que ajudam a modularizar e simplificar nosso trabalho do lado do servidor: Views.
Toda requisição que segue para o WEB-MVC passa pelo DispatcherServlet do spring. A partir daÃ, o container se responsabiliza por delegar a chamada para o controller correto, baseando-se nas configurações de sua aplicação.
Depois que a chamada é tratada pelo controller, o spring manda a resposta correspondente atrelada a uma View. Uma View é um descritor da forma com que os dados vão ser apresentados na interface, podendo ser JSP, JSF, JSon, XML, etc., ou até mesmo uma forma de encapsular os dados especÃfica da sua aplicação.
O poder das Views está justamente no fato de ser apenas uma descrição de como os dados serão apresentados, portanto desconecta-se completamente da aplicação, e pode ser aproveitada em outras ocasiões por outros sistemas.
Uma View no Spring nada mais é do que uma interface Java que descreve o tipo do conteúdo, e é responsável por renderizar a requisição:
|
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 |
/*
* Copyright 2002-2008 the original author or authors. * * Licensed under the Apache License, Version 2.0 (the “License”); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an “AS IS” BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package org.springframework.web.servlet; import java.util.Map; import javax.servlet.http.HttpServletRequest; /** This class and the MVC approach associated with it is discussed in Chapter 12 of View implementations may differ widely. An obvious implementation would be Views should be beans. They are likely to be instantiated as beans by a ViewResolver. /** Note: This attribute is not required to be supported by all
/** Can be used to check the content type upfront, if not predetermined. /** The first step will be preparing the request: In the JSP case, in case of empty model) } |
Todo o código e JavaDoc está no projeto do Spring.
Vamos criar um exemplo de controller com duas views diferentes: JSon e XML. JSon e Xml são os formatos mais comuns na Web, por isso vamos ver uma das maneiras de devolvê-las em nossos contrllers.
Não vou entrar no detalhe de como configurar os controllers da sua aplicação para funcionar com o Spring-WEB-MVC, pois não é o intuito deste post, e existe bastante documentação disponÃvel na internet sobre o assunto.
A maneira que escolhi para o exemplo, foi deixar a resposta padrão da servlet como XML, e criar uma alternativa de view em JSon. Você pode configurar como quiser a ordem e o padrão de view da sua aplicação, essa escolha serve apenas para ilustar como lidar com os dois casos.
Comece criando alguma classe de domÃnio para servir de resposta do nosso controller:
|
1
2 3 4 5 6 7 8 9 10 |
Agora vamos criar um Controller para devolver nosso objeto de domÃnio:
|
1
2 3 4 5 6 7 8 9 10 11 12 |
@Controller
public class ExemploController @RequestMapping(“/exemplo/xml”) } |
Agora temos uma servlet que responderá por “
Vamos configurar agora nosso ‘empacotador’ de XML para torná-lo formato padrão da aplicação. No arquivo de beans do Spring crie os seguintes beans:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
class=“org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter”> > > > |
O que fizemos foi criar um “marshaller” de XML que usa o XStream para converter ‘de’ e ‘para’ XML. Também mapeamos nossa classe de domÃnio para o alias “exemplo”. Feito isso basta criar um bean que representa os conversores de mensagens do Spring, nesse caso ‘messageConverters’, e associar o conversor de XML nele.
Pronto! Agora que temos as configurações necessárias para criar XML, e anotamos nosso método do controller com ‘@ResponseBody’, o padrão do Spring será devolver o XML que representa a entidade de domÃnio criada:
|
1
2 3 |
> |
Para criar a view de JSon agora, vamos fazer de maneira diferente. Comece criando um bean em seu arquivo do Spring que representa a View de JSon:
|
1
2 3 |
class=“org.springframework.web.servlet.view.json.MappingJacksonJsonView”> > |
Note que precisamos da dependência do ‘Jackson’ no classpath do nosso projeto, que está disponÃvel no site do projeto ou até mesmo no repositório do maven.
Agora em nosso controler, vamos adicionar a dependência da view que acabamos de criar, e adicionar o método que tratará a requisição em JSon:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 |
Repare que não precisamos da anotação ‘@ResponseBody’, e que ao invés de devolver um ‘Exemplo’ estamos devolvendo o ModelAndView do SpringWEBMVC.
Para que a resposta chegue no formato correto, basta mandar a view de JSon que criamos junto com o ModelAndView, e o objeto de domÃnio. Dessa forma temos a resposta que esperamos:
|
1
2 3 4 |
“response”:
“nome”:”json” } |
Para a moda REST que está tomando força nos últimos tempos, as múltiplas views do Spring é uma ótima ferramenta para fazer parte dessa onda, e ainda prover diferentes maneiras de seu servidor se comunicar com diversos tipos de dispositivos e aplicações clientes, sem comprometer código com regras de negócio.
Espero ter sido útil, e qualquer dúvida, crÃtica ou comentário são sempre bem vindos.
Por @Gust4v0_H4xx0r
Voc? sabia que em m?dia 9 entre cada 10 novas lojas virtuais deixam de existir no primeiro ano de vida? E que em sua grande maioria devido as fraudes on-line.
As grandes causas de fraudes sofridas pelo comercio eletr?nico est?o, de um lado a escassa seguran?a e as limita??es dos meios de pagamento e de outro a grande dificuldade pr?tica em verificar e garantir a identidade do cliente/comprador.
Neste caso o comprador golpistas aproveita os dados de um cart?o de cr?dito que foi clonado ou roubado ou cujos dados estejam dispon?veis por alguma raz?o (muitas vezes basta um xerox frente e verso), se passando pelo titular do mesmo e realizando a compra em nome dele. Alguns golpistas mais sofisticados procuram ter um cadastro completo do verdadeiro titular do cart?o de forma a estar pronto em caso de liga??o.
Existem basicamente duas alternativas para enfrentar o problema das fraudes no com?rcio eletr?nico.
Terceirizar para empresas de meios de pagamento pois est?o estruturadas para garantir a seguran?a nas transa??es.
Alguns exemplos de empresas deste tipo (para o Brasil) s?o os seguintes:
• http://www.pagseguro.com.br
• http://www.moip.com.br
• http://www.braspag.com.br
• http://www.ipagare.com.br
Caso escolha criar uma estrutura de verifica??o interna, vale levar em conta os seguintes fatores e dicas.
O ponto principal ? a valida??o da identidade do cliente, e conseq?entemente de seus meios de pagamento. Para isso voc? pode utilizar usadas ferramentas e fontes de valida??o de cadastro, tal qual Zip Code. Os dados solicitados no cadastro devem ser escolhidos com base nas necessidades do neg?cio. O uso de ferramentas autom?ticas de scoring ou de detec??o de ind?cios de fraudes ? muito recomend?vel.
? ?til, quando poss?vel, utilizar ferramentas de an?lise de risco e preven??o de fraudes ou ainda sistemas de scoring automaticos ou n?o.
Solicitar c?pias de determinados documentos ou comprovantes por fax ou email pode ser uma ?tima alternativa para alguns tipos de neg?cios. Uma longa demora no envio dos documentos ? sinal de suspeita.
Em caso de suspeita de fraude poder?o ser realizadas entre outras, as seguintes verifica??es:
Automatize o processo de verifica??o e preven??o de fraudes em seu ecommerce atrav?s dessas ferramentas:
L?gico que o melhor caminho sem d?vida ? quando sua empresa mescla a utiliza??o de v?rias formas e t?cnicas de verifica??es e valida??es dos compradores e suas compras em tempo real para identificar e previnir o preju?zo com fraudes no ecommerce.
E a sua empresa como trabalha para previnir as fraudes? Comente logo abaixo.
Sua empresa n?o utiliza nenhuma forma de preven??o contra fraudes? Entre em contato comigo.
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.
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 |
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.
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.
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
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.
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 AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(); |
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 |
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”) |
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); GenericBean otherBean = ctx.getBean(“otherBean”, GenericBean.class); Assert.assertNotNull(otherBean); |
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>
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 |
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); |
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.
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
