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:

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ã:

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:

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

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

Princ?pio da ?nica Responsabilidade:

“Nunca deve haver mais de um motivo para uma classe ser alterada”

Cada responsabilidade constitui-se uma dimens?o de mudan?as. Se uma classe tem mais de uma responsabilidade, ent?o haver? mais de uma raz?o para alter?-la. Quanto mais responsabilidades h? numa classe, mais fr?gil (maior risco de para de funcionar) torna-se o projeto.

Viola??o do princ?pio:

Considere a Classe TAD:

import java.util.Vector;

/**
 *
 * @author Edgard Davidson
 */
public class TAD 

    private Vector vector;

    public TAD()
        vector = new Vector();

    public void empilhar(Object element)
        vector.insertElementAt(element, 0);

    public Object desempilhar()
        if (!this.eVazia())
            Object result = vector.firstElement();
            vector.removeElementAt(0);
            return result;
         else
            return null;

    }

    public void enfileirar(Object element)
        vector.add(element);

    public Object desenfileirar()
        if (!this.eVazia())
            Object result = vector.firstElement();
            vector.removeElementAt(0);
            return result;
         else
            return null;

    }

    public int obtemTamanho()
        return vector.size();

    public boolean eVazia()
        return vector.isEmpty();

}

Como pode ser visto, a classe TAD (Tipo Abstrato de Dados) ? uma classe que possui mais de uma responsabilidade. Ela implementa o contrato de um Pilha com os m?todos (empilha e desempilha) e o contrato de uma Fila com os m?todos (enfileira e desenfileira). A classe TAD viola o princ?pio da ?nica responsabilidade. Para se adequar ao princ?pio, ? necess?rio aplicar a refatora??o Extrair Classe. Essa t?cnica de refatora??o ? a mais indicada para o caso da viola??o do SRP. Sempre que houver uma classe fazendo o trabalho que deveria ser feito por duas classes, aplique a referida refatora??o para criar uma nova classe movendo os campos e m?todos pertinentes da classe antiga para a classe nova.

Al?m de aplicar a refatora??o Extrair Classe, na adequa??o ? viola??o do princ?pio, foi renomeado tamb?m a classe TAD, que n?o possuia um nome significativo ao seu contrato. Ap?s aplica??o de Refatora??o temos:

Adequa??o ao princ?pio:

Antes de mostrar a solu??o, a figura abaixo ilustra o contrato de uma Pilha e o contrato de uma Fila. Ambas s?o estruturas de dados com comportamentos diferenciados. A pilha implementa um algoritmo de LIFO (Last In, First Out), o ?ltimo a entrar ? o primeiro a sair. J? a fila implementa um algoritmo de FIFO (First In, First Out), o primeiro a entrar ? o primeiro a sair.

O diagrama de classe original foi refatorado e a classe TAD foi renomeada para Pilha e todos os m?todos referentes ao contrato de uma fila, ap?s aplicado o Extrair Classe e foram movidos para a classe Fila

Implementa??o da classe Pilha

import java.util.Vector;

/**
 *
 * @author Edgard Davidson
 */
public class Pilha 

    private Vector vector;

    public Pilha()
        vector = new Vector();

    public void empilhar(Object element)
        vector.insertElementAt(element, 0);

    public Object desempilhar()
        if (!this.eVazia())
            Object result = vector.firstElement();
            vector.removeElementAt(0);
            return result;
         else
            return null;

    }

    public int obtemTamanho()
        return vector.size();

    public boolean eVazia()
        return vector.isEmpty();

}

Implementa??o da classe Fila

import java.util.Vector;

/**
 *
 * @author Edgard Davidson
 */
public class Fila 

    private Vector vector;

    public Fila()
        vector = new Vector();

    public void enfileirar(Object element)
        vector.add(element);

    public Object desenfileirar()
        if (!this.eVazia())
            Object result = vector.firstElement();
            vector.removeElementAt(0);
            return result;
         else
            return null;

    }

    public int obtemTamanho()
        return vector.size();

    public boolean eVazia()
        return vector.isEmpty();

}

Com essa nova implementa??o, a classe Pilha e a classe Fila s?o extremamente coesas, possuem apenas um prop?sito, uma ?nica responsabilidade e apenas um contrato

Outras refer?ncias

• http://engenhariadesoftwareagil.com/?p=236
  
• http://www.objectmentor.com/resources/articles/srp.pdf
• http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx
• http://c2.com/cgi/wiki?SingleResponsibilityPrinciple
• http://msdn.microsoft.com/en-us/magazine/cc546578.aspx
• http://codebetter.com/blogs/david_laribee/archive/2008/09/09/why-solid-gimme-an-s.aspx
• Head First Design patterns. pags 185, 336, 339, 367
• Agile Principles, Patterns, and Practices in C#.
• UML for Java Programmers

Faz algum tempo que não escrevo aqui no blog, estou em vários projetos simultâneos e acabei ficando sem gás para escrever no mesmo ritmo que antes. Para compensar, hoje vou disponibilizar um componente de notificação bem bacana que criei para um treinamento in company de Flex. O código aborda diversos conceitos interessantes do Flex 4 como states, FXG e Spark Skinning. Além disso, o componente é um excelente exemplo de onde utilizar o design pattern Singleton.

O componente possui 3 classes:

NotificatorMode.as
Utilizado como um “Enum”, define as constantes que representam os estados do componente: Warning, Success e Failure.

NotificatorManager.as
Implementação do padrão de projeto Singleton, responsável por manipular as mensagens de notificação.

Notificator.mxml
Classe que define a aparência, comportamento e estados do componente de notificação.

A pasta /assets contêm os arquivos que foram gerados no Fireworks e exportados como FXG para o Flash Builder.

Your browser does not support iframes.

Quer o código fonte? Baixe aqui..

Espero que tenham gostado. Até a próxima!

Dae Pessoal.

Hoje vamos falar sobre Singleton em Action Script.
Singleton é um modelo de Design Pattern que simplifica o acesso ao objeto, apenas instanciando a mesma. Veja no exemplo a Classe que eu fiz e o seu uso.

package br.com.fborella
{
	public class Singleton
	{
		private static var instance:Singleton;
		public var auxiliar:String;
?
		public function Singleton(enforcer:SingletonEnforcer)
		{
			if (enforcer == null)
				throw new Error("é possivel apenas uma instância");
		}
?
		public static function getInstance():Singleton
		{
			if (instance == null)
				instance=new Singleton(new SingletonEnforcer);
			return instance;
		}
	}
}
//Esse class abaixo e para bloquear qualquer acesso ao construtor.  
class SingletonEnforcer {
?
}

Usando a mesma:

xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
	<fx:Script>
		[CDATA[
			import mx.controls.Alert;
			import br.com.fborella.Singleton;
?
			public var instancia:Singleton = Singleton.getInstance();
?
            public function clique():void{
            	instancia.auxiliar = 'Teste Singleton';
            	Alert.show(instancia.auxiliar);
            }
		]]>
	fx:Script>
	<s:Button label="Clique aqui" click="clique()"/>
s:Application>

Valeu ai pessoal..

Felipe

Criando a camada WEB com Spring-WEBMVC – @Annotation

Spring WebMVC é uma ferramenta poderosa para criação de aplicação com uma camada web muito utilizada no mercado.
Algumas de suas características incluem uma separação clara entre camada de apresentação, negócios e modelo, e também uma distinção clara de papéis de controllers, validators, commands, forms, models, views etc. Também é um framework altamente customisável e adaptável, disponibilizando ferramentas para controle de todo o fluxo entre as páginas e se adaptando bem a maioria dos modelos de negócio. Outra característica que é quase obrigatória em todos os módulos do Spring, é o padrão Spring de se organizar e configurar as classes de negócio como beans gerenciados pelo container.
Além das características básicas, ainda estão disponíveis bibliotecas de JSP muito úteis no dia-a-dia de desenvolvimento que facilitam a contrução de interfaces. E ainda existe a possibilidade de configurar os escopos dos beans da aplicação de acordo com o lifecycle do HTTP request que está sendo feito para a aplicação.

Neste post veremos o básico de spring-webmvc e sua configuração feita por anotações, aprendendo os conceitos base do módulo e entendendo melhor como configurar e organizar seus beans de acordo com suas necessidades. Por fim veremos um screencast com um exemplo de aplicação web feita do zero e seguindo todo o caminho desde o modelo, passando pelo controller e terminando na view.

Entendendo o DispatcherServlet

O DispatcherServlet é de fato um servlet Java que é o ponto de entrada para as aplicações Web.

É encarregado de encaminhar as chamadas feitas a aplicação para seu respectivo controller, e uma vez que a resposta do controller foi recebida, encaminhas a resposta para a view correta. Mas como DispatcherServlet faz parte do Spring, para ele e seus beans, nesse caso controllers e suas dependências, estão disponíveis todas as outras features que o container disponibiliza, como gerenciamento de beans e injeção de dependências.

O DispatcherServlet seguem um Design Pattern conhecido como Front Controller. No site do spring está disponível o seguinte diagrama exemplificando o pattern:





No diagrama fica claro o papel do DispatcherServlet.
Uma chamada que acabou de chegar na aplicação, passa pelo DispatcherServlet, que por sua vez escolhe o controller correto para tratar a chamada e delega a mesma. Feito isso o controller devolve o resultado da operação para o DispatcherServlet que dessa vez se encarrega de encontrar a view correta para tratar a resposta. Após a view ter renderizado a página de resposta, o DispatcherServlet devolve para o dono da requisição a resposta.

Configurando o DispatcherServlet

Agora que entendemos que o DispatcherServlet é peça fundamental para nossa aplicação, precisamo configurá-lo. Para isso basta adicioná-lo ao seu arquivo web.xml da seguinte forma:

O que fizemos foi dizer ao server, que ele deve instanciar um novo servlet, que nesse caso é o DispatcherServlet, assim que a aplicação subir no servidor. Também estamos dizendo que todas as chamadas para a aplicação, que forem feitas em / devem ser delegadas para o nosso servlet com o nome servletName. Nesse campo você pode escolher o nome que mais fizer sentido para sua aplicação, e perceba que você pode criar mais de um servlet para tratar suas chamadas.

Agora vamos à integração com o IoC do Spring.

Como eu havia dito, esse é um dos benefícios do Spring-WebMVC, e portanto vamos ver como usá-lo corretamente para tirar maior proveito do mesmo.

Todo DispatcherServlet está associado a um contexto de beans do Spring. Tal associação é feita através do nome do servlet e um arquivo de beans padrão do spring. No momento em que o DispatcherServlet for criado, o classpath será percorrido em procura de uma arquivo que, neste caso, deve se chamar /WEB-INF/servletName-servlet.xml. Neste arquivo devem estar definidos os beans específicos para que os seus controllers referentes a este servlet funcionem corretamente. Note que se estiver definido mais de um DispatcherServlet, será necessário definir um arquivo com tais beans para cada um deles.

Controllers

Controllers são parte fundamental da arquitetura MVC (se referem so ‘C’ da sigla), e no Spring-webmcv não é diferente. Saber configurá-los e atribuí-los a suas chamadas específicas é muito importante no desenvolvimento da aplicação. Pensando nisso o Spring disponibiliza várias implementações de controllers que pode ajudar no dia-a-dia e várias ferramentas para associar as chamadas a tais controllers. Como o objetivo do post é tratar da configuração por anotações, não entrarei no detalhe de tais implementações e de tais associações. Iremos utilizar um serviço qualquer da aplicação para servir de controller, e a associação será feita através das anotações.

Para tornar uma classe um controller do spring, basta anotá-lo com @Controller da seguinte forma:

Repare que não é necessário extender nem implementar nenhuma classe ou interface específica, o que colabora bastante para desacoplar a lógica de view de nosso sistema.

Para habilitar esse nosso controller e associá-lo ao servlet, basta pedirmos ao Spring para scannear esse pacote e deixar o bean disponível no contexto do servlet. Para fazer isso adicione o seguinte no arquivo de beans do servlet:

Perceba que coloquei a tag do contexto do spring que habilita a configuração por anotações.

Agora precisamos definir um método para que o spring faça a chamada quando o request chegar na aplicação. Para isso vamos entender o papel do ModelAndView.

ModelAndView

O ModelAndView é responsável por descrever o modelo e a view (intuitivo? ) daquela chamada, portanto nele estão setados a view a qual a chamada está associada, e todos os atributos de modelo que devem chegar até a view. Tais atributos são guardados como em um Map associando chaves e valores. Veremos que esses valores ficam disponíveis em nossa view e podem ser usados nos JSPs da aplicação, mas agora vamos ao método do controller:

Muita coisa acontecendo aqui, mas vamos por partes. A primeira coisa a se notar é que o método irá tratar todas as chamadas feitas em nomeDaAplicação/chamada, isso porque nosso servlet está associado em / e nosso método está associado com chamada. Nós poderíamos também ter definido o caminha básico para o controller ainda na anotação do controller, por exemplo:

Assim nosso método trataria todas as chamadas feitas em nomeDaAplicação/base/chamada.

A segunda coisa a se notar é que nosso método só irá tratar requisições do tipo GET, podendo ser alterado para os outros tipos de requisição seguindo um modelo REST.

A terceira coisa a se notar é que nosso método devolve um ModelAndView, portanto saberemos a que view o DispatcherServlet irá direcionar, e também teremos alguns atributos do modelo disponíveis.

A última mas não menos importante, é que o método está esperando um parâmetro. Esse parâmetro foi anotado com @PathVariable, isso significa que a chamada ao controller deve esr da seguinte forma: nomeDaAplicação/chamada?var=teste e assim nosso método irá receber o valor teste. Faça alguns testes e repare que é possível configurar a obrigatoriedade do parâmetro, a validação do mesmo dentre outras coisas. Também poderíamos ter definido o parãmetro como @RequestParam, mas nesse caso a chamada deveria estar em um formato POST e o atributo deveria estar setado no request.

ViewResolver

A última configuração necessária para nossa aplicação funcionar é um ViewResolver. Vamos utilizar um bem simples para que possamos utilizar páginas em JSP em nossa aplicação. Para isso, basta adicionar o seguinte bean no contecto do servlet:

O que fizemos, foi dizer ao view resolver, que ele deve buscar na pasta WEB-INF/jsp por nossos arquivos JSPs antes de renderizar as páginas de resposta. Também estamos dizendo, que ele deve procurar através do nome da view que o controller devolver, por exemplo, se nosso ModelAndView possuir uma view com nome pagina, o view resolver irá buscar por um arquivo com nome pagina.jsp para renderizá-lo com os atributos setados no ModelAndView.

Existem muitos tipos de view resolvers, e muitas maneiras de configurá-los, mas para uma primeira experiência com o framework essa configuração já é suficiente.

Por @Gust4v0_H4xx0r

Olá a todos!

Para os mais distraídos, há cerca de uma semana coloquei, do lado direito do blog, um logótipo do qual me orgulho muito. É o logótipo que é atribuído a todos os profissionais que possuem o título de Adobe Certified Expert.

Esta certificação deu-se, depois de ter completado, com sucesso, o exame da Pearson Vue sobre Flex 4.

Em termos de partilha de experiência, posso-vos dizer que o exame é difícil e que toca em bastantes pontos do desenvolvimento nesta plataforma.

As questões que nos são colocadas no exame vão desde o simples nome de uma propriedade de um componente, passando por casos de utilização ou não de certos tipos de design patterns, até a questões sobre BlazeDS, Adobe Live Cycle e consequentemente questões sobre model-driven development.

No meu caso, quando achei que estava na hora de obter a certificação, marquei logo o exame e dediquei cerca de dois meses a estudar a plataforma / framework e todos os seus pequenos detalhes. De forma a estar mais confortável no exame, comprei o software Attest 3 que tenta simular o ambiente de exame real e que se revelou essencial para o resultado final.

Esta foi, sem dúvida, a forma ideal de acabar 2010

Qualquer dúvida que tenham e esclarecimento que precisem sobre as certificações de Adobe Certified Expert, coloquem-nas aqui que tentarei responder o melhor que sei!

Bom 2011, Mauro.

Boa noite pessoal!

Mais uma excelente noticia!
Foi lançado a edição número 76 da revista .NET Magazine, no qual tive o grande prazer de colaborar com o Alexandre Tadashi Sato (Silverlight Experience), na escrita de mais um artigo, sendo que o tema proposto foi sobre Silverlight Toolkit!

O Silverlight Toolkit proporciona aos desenvolvedores uma gama de controles extras ao Microsoft Silverlight, que vão desde componentes para dashboards, skins, controles de navegação, visualização de dados e muito mais. Você encontrará vários exemplos práticos de alguns dos principais componentes, e muito mais!

Lista de artigos desta edição:

• Silverlight Toolkit
• Design Patterns na prática – Parte 1
• Design Patterns
• Code Contracts
• Estimando seus Requisitos
• Pesquisa de objetos na memória
• É possível ganhar dinheiro com licença GPL?(Artigo Exclusivo Digital)

Grande Abs.

Robson Fernandes

Acaba de ser lançada a nova edição da revista .net Magazine, a edição de número 76, o destaque é a programação com Design Patterns.

Segue a lista de artigos:

• Silverlight Toolkit
• Design Patterns na prática – Parte 1
• Design Patterns
• Code Contracts
• Estimando seus Requisitos
• Pesquisa de objetos na memória
• É possível ganhar dinheiro com licença GPL?(Artigo Exclusivo Digital)

O Robson Fernandes (RIA Software) escreveu junto comigo um artigo sobre o Silverlight Toolkit que está nesta edição da .net Magazine, o Silverlight Toolkit é um conjunto de componentes que enriquece os aplicativos desenvolvidos com a tecnologia Silverlight. Além de conhecer a ferramenta, durante o artigo criamos exemplos práticos de alguns dos principais componentes.

Boa noite Pessoal!

Galera, vejam que massa! Eu estava a pesquisar na internet sobre UX (User eXperience), e me deparo com esta aplicação desenvolvida em Microsoft Silverlight, o Quince.

O Quince, é um diretório on-line de UX – design patterns, criado pela Infragistics. Nele você encontrará mais de 100 exemplos de padrões de UX, utilizados em aplicações Web, Desktop e outras. O mais interessante, até mesmo para fins didáticos, é que este aplicativo aborda cada padrão, informando ao desenvolvedor qual a melhor situação em usá-lo, narrando de forma a exemplificar um “Problema encontrado”, a “Solução, através do padrão”, “Contexto de aplicação.”

Fantástico!

Segue o link Quince : http://quince.infragistics.com

Este artigo não é meu. É a tradução do artigo de Joel Hooks, cujo original encontra-se aqui: http://joelhooks.com/2009/07/12/inversion-of-control-and-dependency-injection-in-flex-using-the-parsley-application-framework-part-1/
O princípio de projeto Inversão de Controle (IoC) e o design pattern Injeção de Dependência (DI) estão no mercado já há vários anos. No mundo Java, frameworks populares como o Spring fazem grande uso destes conceitos. Com a [...]