Veja também:

• [ Adobe AIR ] Color Browser
• [ Adobe AIR ] Package Assistant Pro
• GVT – Power Music Club
• Adobe AIR – FileSearch
• [Adobe AIR 2 : NativeProcess] projeto de exemplo : Windows Console

Twitter!

Introdução

Um desafio de todo desenvolvedor html é manter o seu site compatível com todos os browsers ( em especial o Internet Explorer ), devido as limitações e detalhes na implementação de cada um, isso é um fato inegável, e qualquer um que ja tentou um dia desenvolver alguma coisa em html sabe disso.

Em projetos pequenos podemos tomar conta disso sem a necessidade de nenhuma ferramenta extra, entretanto com o? crescimento? do projeto? a tendência ? é que estes trechos de códigos para manter a compatibilidade fiquem tão grande quanto o código do próprio site em si, tornando difícil de manter e etc.

jQuery

Nesta hora é importante conhecer as ferramentas que existem para ajudar o desenvolvimento, e utiliza-las de maneira correta. Uma ferramenta importante no desenvolvimento html é o jQuery.

Para quem não sabe o que é, o jQuery é uma biblioteca javascript que facilita a manipulação do DOM ( Document Object Model ) html, ou seja, facilita a manipulação da sua página html.

Para entender melhor do que este post se trata é necessário ter um conhecimento básico da biblioteca jQuery

Hooks

Muitos dos métodos get e set do jQuery podem ser extendidos para casos especiais, estas extensões são conhecidas como hooks. O namespace $.cssHooks permite extender o método .css(), permitindo criar novas propriedades de CSS.

Os hooks podem ser utilizados como uma solução elegante para a compatibilidade de CSS em diferentes browsers, por exemplo, a propriedade text-shadow do CSS3 não é suportada pelo Internet Explorer, portanto o código abaixo não funcionará no IE:

Este código aplica um glow verde em todos os elementos H3 do documento HTML, porém não funciona no IE.

CSS Hooks

Mas nós podemos criar uma nova propriedade css, e internamente tratar o caso do IE. Vamos chamar a nova propriedade de glowColor:

Este código cria uma propriedade dentro do namespace .cssHooks chamada glowColor, esta propriedade possui uma função set específica para o caso do IE e outra para o caso dos outros browsers. A lógica deste código é basicamente, verificar se possui suporte ao textShadow, caso sim,? define? uma função set que altera o atributo elem.style.textShadow com a cor do parâmetro, caso não, define uma função que altera a propriedade elem.style.filter com um filtro especifico utilizando a cor do? parâmetro.

Agora podemos aplicar o efeito através do código

Conclusão

O lado bom de criar um cssHook no jQuery para o problema de descrito é que o código que trata a compatibilidade fica oculto do desenvolvedor, ele não precisa se? preocupar? com isso, o foco é no código que? constrói? a pagina unicamente. Esta? estratégia pode ser aplicada para outros diversos efeitos e manipulações, criar uma serie de hooks para tratar este tipo de coisa e etc. O lado ruim no meu ponto de vista é que estamos criando propriedades novas, que são desconhecidas pelos outros desenvolvedores e etc, portanto um novo desenvolvedor iria demorar para aprender todas customizações e suas funções, uma dica é tentar manter os nomes semelhantes ao padrão.

Por @thiagoofelix

Referências

• Learning jQuery, Third Edition
• jQuery API

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

Twitter!

Profiles e Environments no novo Spring 3.1

A SrpingSource adotou a estratégia de soltar mais versões do Spring com mais velocidade e escopos de funcionalidades menores.
Seguindo tal estratégia acabou de sair do forno o primeiro release candidate da versão 3.1 do framework.
Para uma estratégia de escopos menores, até que tiveram bastante trabalho e adicionaram várias novidades. Vamos cobrir as novidades aos poucos, começando com uma muito interessante: Profiles e Environments.

Especificando Profiles nos Beans

A idéia de um profile é simples. Um profile define um escopo, envirnmente como é chamado no framework, em que certos beans estarão disponíveis e outros não.
Imagine que você precisa de uma conexão com o banco de dados de testes, que é diferente do banco de dados de desenvolvimento. Com profiles podemos definir um data source do profile de desenvolvimento, e outro do profile de testes, instanciando o correto de acordo com o ambiente que a aplicação irá rodar.

Anotações

Para especificar um profile no seu bean, basta adicionar a anotação @Profile com o nome do profile correspondente. Lembrando que este é o caso em que seus Beans estão sendo criados pelo component-scan usando package scan. Vamos criar um exemplo pra ficar mais claro o que acontece.
Vamos criar uma interface comum para nossos beans:

Agora vamos criar dois profiles e dois beans diferentes para a mesma interface. Um é o bean de desenvolvimento (dev) e o outro de testes (qa).

Repare que já anotei os beans com @Profile respeitando os profiles específicos de cada bean.
Agora criamos o arquivo de beans do spring, dei o nome de spring31-test-beans.xml:

Feito isso, vamos criar um teste para verificar a lógica de criação dos beans. estou usando JUnit 4.8.1.

Algumas coisas diferentes estão acontecendo nesse teste.
Estou instanciando um GenericXmlApplicationContext para carregar meus arquivos de beans, isso porque esse application context me disponibiliza um método que é importante para nosso teste: getEnvironment(). Com isso conseguimos acessar o environment do application context, e mais do que isso, conseguimos setar os profiles que estão ativos usando setActiveProfiles. Repare que é possível de setar mais de um profile como ativo, e que os beans podem precisar de mais de um profile para serem instanciados.
Outro fato importante, é que este environment que está disponível, é uma instância de ConfigurableEnvironment. Se você tentar acessar o profile diretamtente em ApplicationContext, você estará acessando um Environment o qual não permite ativar e desativar profiles. Fica a dica.


Após ativar o profile que queremos, basta chamar o load no contexto seguido do refresh para que os beans sejam criados.
Uma vez que o bean foi criado, basta recuperá-lo e executar o teste para se certificaro que se trata do bean que estamos esperando. Note que o nome dos dois beans é o mesmo, e que apenas um deles existe no application context, pois o outro profile não está ativo.

Nested Beans

Outra maneira de definir profiles nos beans é diretamente no XML do spring. Para que isso seja possível foi necessário permitir nested beans nos arquivos de beans, ou seja, definições de beans dentro de outra definição.
Além de possibilitar a definição de diferentes profiles, essa nova funcionalidade permite que sejam definidos alguns padrões de comportamento para os beans que só se apliquem no conjunto de beans que está nested. Mas isto veremos em um próximo post.
Para testar a definição de profiles direto no XML, vamos criar um outro XML chamado spring31-test-nested-beans.xml:

Feito isso, vamos criar um novo teste que é idêntico ao primeiro, com exceção do arquivo de beans especificado, afinal o comportamento deve ser o mesmo em ambos os casos:

Sua barra do JUnit vai ficar verde e você vai ficar feliz com essa brincadeira rápida com profiles.

Ativando Profiles de outras maneiras

Ativa os profiles no código funciona muito bem no caso dos testes, mas o que realmente se aplica a vida real é poder ativar tais profiles de maneira independente da aplicação e do código propriamente dito. Por isso podemos ativar os profiles setando uma variável global chamada spring.profiles.active.
Podemos ativar tal variável de diversas maneiras, dentre elas no próprio web.xml como um parâmetro da sua Servlet do Spring:

Podemos usar também JNDI, ou até mesmo uma variável de ambiente da VM Java. Se você preferir também pode ativar profiles diretamente no maven:

Fazendo Download

Se você usa o maven, basta adicionar o seguinte no seu pom:

Caso você queira baixar diretamente do site, acesse o site do spring.

Espero ter sido útil, qualquer pergunta basta enviar nos comentários.

Por @Gust4v0_H4xx0r

Twitter!

No escritório da DClick em SP:

“Na DClick nós queremos inovar, mas vale a ressalva: ser o primeiro não é inovar. Pioneiro é diferente de inovador. O pioneiro pode ter alguma vantagem competitiva, mas nada impede que os concorrentes o alcancem logo. Por isso, de nada adianta apenas sair correndo para ser o primeiro a instalar a versão mais recente da tecnologia X. É preciso sim encontrar uma maneira nunca vista antes de tirar proveito da tecnologia X para resolver um problema relevante. É preciso pensar diferente. É preciso trazer novas soluções para velhos problemas. Não é ser o primeiro, mas ser o único. Para inovar é preciso ser Singular.

Na DClick nós acreditamos que o entendimento do problema é a peça chave no quebra cabeça de uma solução singular. Acreditamos que a solução não surge pronta, mas precisa ser trabalhada passo-a-passo até que sejamos premiados por insights que nos levarão a Conquista destas soluções.

Também acreditamos que a tecnologia é o meio pelo qual viabilizamos esta conquista. Acreditamos que é preciso ter um vasto leque de opções para não sermos limitados na busca das soluções. Acreditamos que nada é impossível até que se prove o contrário e que a Exploração tecnológica é capaz de viabilizar nossas soluções singulares.

Explore tecnologias e Conquiste soluções Singulares. É nisso que acreditamos. Esta é a nossa filosofia. Este é o nosso mantra.”

Na defini??o da teoria da cria??o do conhecimento organizacional [Nonaka e Takeuchi, 1995] definiram duas dimens?es para a cria??o do conhecimento:

i) a dimens?o epistemologica: onde ? feita uma distin??o entre o conhecimento t?cito e o expl?cito para a cria??o do conhecimento. Essa distin??o corrobora com a estabelecida por [Polanyi, 1967]. O conhecimento t?cito ? individual, pertence a pessoa ? espec?fico ao contexto e ? dif?cil de ser registrado e compartilhado. J? o conhecimento expl?cito pode ser registrado em meios f?sicos ou digitais em linguagem natural, formal, ou sist?mica;

ii) a dimens?o ontol?gica: onde enfatiza a cria??o do conhecimento organizacional em oposi??o ? cria??o do conhecimento individual, passando por v?rios n?veis de cria??o do conhecimento (individual, grupal, organizacional e inter-organizacional). Segundo [Nonaka e Takeuchi, 1995] o conhecimento s? pode ser criado pelos indiv?duos. O papel da organiza??o ? apoiar e motivar os indiv?duos criativos e lhe proporcionar um ambiente adequado para a cria??o do conhecimento. Neste contexto, o conhecimento organizacional ? o resultado do conhecimento individual amplificado, registrado e mantido pela organiza??o.

Na teoria da cria??o do conhecimento organizacional, conforme ilustrado na figura do espiral do conhecimento, as dimens?es epistemol?gica e ontol?gica suportam o “`espiral”' da cria??o do conhecimento [Nonaka e Takeuchi, 1995]. A referida espiral surge quando, por meio de intera??es entre o conhecimento t?cito e o conhecimento expl?cito, existe uma amplifica??o do conhecimento come?ando pelo conhecimento do indiv?duo, passando pela forma??o do conhecimento do grupo, estabelecendo o conhecimento da organiza??o e por fim convergindo no conhecimento da interorganiza??o.

No centro dessa teoria, conforme ilustrado na figura no modelo SECI abaixo, est? os quatro modos de convers?o do conhecimento criados a partir da intera??o entre t?cito e expl?cito. Esses modos de convers?o foram um modelo que descreve como o conhecimento t?cito ? criado atrav?s da socializa??o, convertido de t?cito para expl?cito atrav?s da externaliza??o, recombinado com outras formas de conhecimento expl?cito atrav?s da combina??o e convertido, novamente, em conhecimento t?cito atrav?s da internaliza??o.

i) socializa??o: quando o conhecimento t?cito se amplifica e ? formado um novo conhecimento t?cito. A socializa??o acontece quando h? compartilhamento de experi?ncias por meio observa??es, de forma emp?rica, diretamente de um indiv?duo para outro, com utiliza??o de linguagem ou apenas atrav?s de observa??es.

ii) externaliza??o: quanto o conhecimento t?cito se amplifica e ? formado um novo conhecimento expl?cito. A externaliza??o acontece quando o conhecimento t?cito ? registrado e pode ser compartilhado em um formato documental, met?fora, mapa mental, modelos, conceitos, hip?teses, etc.

iii) combina??o: quanto o conhecimento expl?cito se amplifica e ? formado um novo conhecimento expl?cito. A combina??o acontece quando um conhecimento j? externalizado ? compilado com outros conhecimento tamb?m j? extenalizados a fim de gerais um novo conhecimento externalizado. Normalmente a combina??o ocorre atrav?s de documentos, reuni?es, conversas ao telefone ou em comunica??o computadorizada.

iv) internaliza??o: quando o conhecimento expl?cito se amplifica e ? formado um novo conhecimento t?cito. A internaliza??o acontece quando o indiv?duo sintetiza e incorpora??o um conhecimento explicito para seu conhecimento t?cito. A internaliza??o ? concebido com o “aprender fazendo”, e incorpora no indiv?duo o “knowhow” t?cnico.

O paradigma de [Nonaka e Takeuchi, 1995] sobre a cria??o do conhecimento destaca tanto o processo de cria??o do conhecimento quanto as condi??es sob as quais o conhecimento ? criado. Essencial para esse paradigma ? a intera??o entre o conhecimento t?cito e expl?cito. A cria??o do conhecimento ? uma espiral, conforme ilustrado na figura do espiral do conhecimento e descrita pelo modelo SECI.

Refer?ncia:

[Nonaka e Takeuchi, 1995] Ikujiro Nonaka and Hirotaka Takeuchi. The knowledge-creating company: how Japanese companies create the dynamics of innovation. Oxford University Press, New York, 1995.

[Polanyi, 1967] Michael Polanyi. The tacit dimension. An anchor book: philosophy. Doubleday, Garden City, NY, 1967.

Olá a todos!

No próximo dia 3 de Setembro, ? s 17 horas, na FNAC de Santa Catarina, vou dar um workshop com o título “Desenho de soluções interactivas para diversas plataformas”.

O workshop vai-se centrar na forma como devemos pensar / desenhar e desenvolver aplicações para vários dispositivos ao mesmo tempo.

Aqui ficam alguns dos tópicos que vão ser abordados:

• A mudança de paradigma com a introdução do mobile (telefones e tablets);
• Tipos de ecrãs e resoluções diferentes – ter atenção ao detalhe!;
• Do rato de computador para o corpo do utilizador;
• A harmonia entre as diferentes experiências e os diferentes dispositivos;
• Tipos de utilizadores nos vários dispositivos;
• As diferentes “App stores”;
• Uma linguagem, várias aplicações / Uma aplicação, várias linguagens;

Este workshop insere-se em uma séries de eventos que o Adobe User Group Porto vai fazer, em conjunto com a FLAG.

A saber:

8 de Setembro, ? s 22 no NorteShopping

Rui Silva : “Importância da arquitectura em design e desenvolvimento de soluções interactivas”.

Este workshop vai falar da integração de diversos dispositivos numa única experiência de utilização e como isto é vital nos dias de hoje com os smartsphones, tablets, e desktops.

11 de Setembro, ? s 17 no Marshopping

Rui Silva: “Aura tecnológica: Interacção distribuída”

Este workshop vai falar sobre a definição e reutilização de elementos arquitecturais para o desenho e desenvolvimento de soluções interactivas.

Apareçam e vamos partilhar ideias, experiências, e tomar um café

Um abraço, Mauro.

Recentemente, conversando com alguns desenvolvedores no trabalho e verificando algumas perguntas publicadas nos fóruns do MSDN, eu notei que ainda há uma dificuldade muito grande tanto de compreensão quanto de implementação para trabalhar com métodos assincronos. Isso se torna um problema particularmente importante em aplicações Silverlight pois todas as chamadas a web services, RIA services, web requests, etc são obrigatoriamente feitos de forma assincrona, não havendo opções para executar essas mesmas operações da forma sincrona e linear ? qual a maioria dos desenvolvedores está acostumada.

Acontece que desenvolvimento assincrono não é difícil e, depois que você aprende e se acostuma, você acaba percebendo que suas aplicações passam a funcionar muito melhor. Sim, não vou argumentar aqui contra o fato de que é necessário se acostumar e que começo seja realmente algo estranho, mas posso garantir que demora pouco tempo para se acostumar e os benefícios são muitos.

Há muitas abordagens e estratégias possíveis para desenvolvimento assíncrono e eu vou apresentar aqui uma delas que é bem simples e que eu usei em praticamente todos os projetos Silverlight em dos quais participei. Essa abordagem não envolve o uso de nenhum framework ou biblioteca externa e pode ser utilizada tranquilamente também em projetos que não sejam Silverlight.

Digamos que você precisa obter o html de uma página web por algum motivo. Uma forma de fazer isso seria criando uma nova instância de WebClient, assinando o evento DownloadStringCompleted e depois chamando o método DownloadString passando a url. Ok, não é difícil, mas é um código repetitivo que poderia facilmente ser reaproveitado ao invés de ser copiado por toda sua aplicação em todo lugar onde você precisar fazer download de uma página. O que eu costumo fazer para esse tipo de chamada é criar um método estático em uma classe utilitária e simplesmente chamar esse método passando, nesse caso, minha url e um ponteiro de callback. É mais fácil mostrar:

public static void HttpGet(string url, Action<string, Exception> callback)     if (!string.IsNullOrWhiteSpace(url))         var client = new WebClient();        client.DownloadStringCompleted += (sender, e) =>             if (callback != null)                 callback(e.Result, e.Error);

        };        client.DownloadStringAsync(new Uri(url));    }}

Quais são as vantagens desse método:

• para executá-lo não é necessário instanciar nenhuma classe
• é facil de reutilizar
• permite que a lógica da minha aplicação fique um pouco mais simples, já que não me obriga a assinar nenhum evento no meu código

Para executar esse método, eu posso usar 2 abordagens.

Abordagem 1 – Delegar o retorno para outro método. Nessa abordagem eu chamo o método HttpGet passando a url desejada e o ponteiro de um método que será executado quando o request for concluído.

private void LoadData()     HttpGet("http://kelps.net", DataLoaded);

private void DataLoaded(string data, Exception error)     if (error == null)         //utiliza os dados retornados na variável "data"

}

Abordagem 2 – Utilizar uma expressão lambda para criar um método anônimo inline no meu código, ao invés de criar uma função separada apenas para processar os dados retornados.

HttpGet("http://twitter.com/kelps", (data, error) =>     if (error == null)         //utiliza os dados retornados na variável "data"

});

A única diferença de funcionamento entre as 2 abordagens acima é que na segunda seria possível utilizar variáveis que estiverem no mesmo escopo da chamada que está sendo feita, ao passo que na primeira seria necessário que essas variáveis fossem globais da classe para que isso funcione. Nos projetos em que trabalho eu costumo utilizar ambas as abordagens, de acordo com o que faz mais sentido em cada situação. Expressões lambda são bem concisas e compactas, mas são claras para qualquer desenvolvedor.

Este foi apenas um pequeno exemplo de como trabalhar com chamadas assincronas sem ficar se perdendo com assinaturas e liberação de eventos. Há outras formas mais complexas e robustas de lidar com isso mas a minha intenção hoje era simplesmente mostrar como dá pra trabalhar de forma simples com código assíncrono, mesmo sem utilizar nenhuma biblioteca externa.

Esta é uma tradução do seguinte artigo: 10 Things A Good Flex Developer Should Know

Para ser um bom programador Flex é preciso mais que simplesmente saber como usar alguns componentes nativos do Flex. É preciso muito mais.

Aqui está minha contribuição sobre o assunto… juntamente com alguns recursos ou algumas palavras-chave que você poderá pesquisar facilmente através do Google.

Por favor, comente no blog se você achar que esqueci algo (o que é inevitável) ou se quiser sugerir alguns recursos interessantes que devo acrescentar.

1- Programação orientada a Objetos (OO)

O Flex se baseia na linguagem ActionScript3, que é totalmente orientada a objetos. Embora não seja um conceito fácil de aprender, programação orientada a objeto é um pré-requisito para aprender Flex. Se já possui experiência com OO (Java, C#, Ruby, etc), então você está pronto. Se não, você precisará pegar um livro sobre OO e começar a aprender o mais rápido possível.

· Head First Java (Java? Sim, Eu sei. Mas confie em mim.)

· Object-oriented programming with ActionScript 3.0

Nota: Alguns de vocês poderão perguntar – “O que são padrões de projetos?”. Vamos dar um passo de cada vez? Preocupe-se em entender classes e objetos, interfaces, herança, composição, polimorfismo, encapsulamento, etc. Só então considere estudar padrões de projetos. De fato, se eu escrever um post intitulado “10 coisas que um GRANDE programador Flex deve saber”, padrões de projeto estará nessa lista.

2- ActionScript/MXML

ActionScript é a linguagem de programação usada juntamente com MXML para criar aplicações Flex. MXML é uma linguagem de marcação baseada em XML. Cada tag MXML é mapeada diretamente para uma classe ActionScript correspondente. MXML é usado pelos desenvolvedores Flex principalmente para apresentar a interface do usuário, enquanto que, o ActionScript é usado para a lógica de negócio. Com exceções, é claro.

O Framework Flex inclui centenas de classes ActionScript e interfaces usadas para desenvolver aplicações Flex. Seu nível de habilidade como um desenvolvedor Flex está diretamente ligado ao seu conhecimento em relação ao ActionScript e MXML.

· Flex in a Week

· Tour De Flex

· Essential ActionScript 3.0

Nota: Fique ? vontade com a API do Flex. Como um desenvolvedor Flex, você vai usá-la diariamente.

3- Debugging

Boa parte do tempo de qualquer programador é gasto no debugging. Obviamente, é necessário debugar para rastrear a causa de bugs. No entanto, também é uma ótima maneira de conhecer o código fonte.

Felizmente, existem muitas ferramentas disponíveis para ajudá-lo com o trabalho de debugging. Invista algum tempo para aprender essas ferramentas. Seu investimento irá proporcionar retorno imediato.

· Flash Builder 4.5 Debugger

· De MonsterDebugger

· Kap Inspect

4- Programação orientada a eventos

Aplicações Flex são orientadas a eventos. Toda ação é o resultado de um evento assíncrono.

Como um desenvolvedor Flex, você deve saber como responder a eventos e como criar e disparar eventos. Para isso, é necessária uma sólida compreensão da arquitetura de eventos do Flex, incluindo familiaridade com os seguintes conceitos:

· Eventos nativos (Flash Player ou Framework de eventos Flex)

· Eventos customizados (Eventos criados pelo desenvolvedor, que estende a classe Event ou uma de suas subclasses)

· Disparar eventos, propagação de eventos (ver classe EventDispatcher e seu método dispatchEvent)

· Event listeners, event handlers (ver classe EventDispatcher e seus métodos addEventListener e removeEventListener)

· Fases do evento (capture, target & bubbling phases; target vs. currentTarget)

· Objetos do evento, tipos de eventos (ver classe Event e subclasses)

· Comportamento do evento default (ver classe Event e subclasses e seu método preventDefault)

5- Data binding

Aparentemente, data binding é um “no brainer”[1]. É só vincular o valor de uma propriedade ao valor de outra propriedade usando chaves. Quando o valor da propriedade de origem for alterado, o valor da propriedade de destino também é alterado.

No entanto, existe uma sobrecarga associada ao uso indiscriminado de data binding, podendo haver implicações no desempenho. Uma sólida compreensão de data binding ajudará a determinar quando é apropriado o seu uso e quando não é.

· Flex Tips – Using Bindable Metadata Events

· Michael Labriola’s presentation entitled Diving in the Data Binding Waters

6- Item renderers

Uma característica de uma aplicação Flex bem projetada é a apresentação dos dados de uma forma visualmente atraente. O Flex oferece uma série de controles baseados em listas (DataGrid, List, TileList, HorizontalList, etc) responsável pela apresentação dos dados. Portanto, pode-se personalizar a exibição dos dados com a ajuda de item renderers.

Você irá consumir muito tempo trabalhando com item renderers. Então é melhor saber bem como ele funciona.

· Flex Examples – Item Renderers in Practice

· A Deep Dive into Flex 4 Lists and Layouts

7- Acesso remoto a dados

Você conhece muitas aplicações que não interagem com os dados? Eu também não. Saiba como recuperar dados através de HTTPServive, WebService e RemoteObject. A arquitetura do framework Flex também poderá ajudá-lo com isso (ver #9).

· Retrieving and handling data with HTTPService

· Retrieving and handling data with WebService

· Retrieving and handling data with RemoteObject

8- Styling / Skinning

Não vamos nos esquecer que o Flex é uma tecnologia de interface e, como tal, certamente há expectativas em relação ao design. Como um desenvolvedor Flex, você deve ser capaz de personalizar a aparência de seus aplicativos usando estilos CSS, gráficos e/ou skins.

Com o Flex 4, não há mais desculpas. Use um pouco do seu tempo para conhecer de uma vez o lado direito do seu cérebro. É uma excelente mudança de paradigma, e vai ajudá-lo a diferenciar-se dos outros desenvolvedores Flex.

· Flex Style Explorer

· ScaleNine

· Introduction to Flex: Part 3 – Styles & Skins

9- Pelo menos um framework de arquitetura Flex

A maioria dos frameworks de arquitetura Flex impõe uma separação de camadas através da implementação do MVC (model-view-controller). Além disso, esses mesmos frameworks especificam como seu código deve ser organizado dentro do projeto Flex.

Embora muitos argumentariam que os frameworks são desnecessários, acredito que os desenvolvedores Flex se beneficiam em muitos aspectos da experiência de usá-los. Basta assistir ? s técnicas (boas ou más) empregadas por um framework para resolver problemas complexos de arquitetura. Isso contribuirá para seu crescimento como um desenvolvedor Flex.

Além disso, é difícil negar o fato de que a experiência com framework aumentará substancialmente o seu valor comercial como um desenvolvedor Flex. Jesse Warden me disse recentemente “Existem poucas empresas que não usam frameworks, mas isso é raro. Queiramos ou não, está na ‘moda’”. Eu concordo com Jesse.

· Cairngorm

· Parsley

· PureMVC

· Mate

· Swiz

· Robotlegs

10- Ciclo de vida de componentes e display list

Eu não estava convencido da necessidade de aprender o ciclo de vida de componentes Flex ou da display list até que escrevi o meu primeiro componente customizado (na verdade foi um componente semi-customizado que se estendia do componente Canvas). Até essa época eu usava componentes nativos do Flex, usando apenas o MXML enquanto que a display list era renderizada para mim. Em nenhuma vez tive que usar os métodos addChild, createChildren ou commitProperties, e usava o evento creatiomComplete para tudo.

Meu primeiro componente customizado usava uma quantidade enorme de eventos assíncronos, e eu não poderia prever a ordem em que cada evento seria disparado. Só depois que eu aprendi os métodos e variáveis do ciclo de vida dos componentes do Flex que eu pude ter um certo controle.

Estes métodos do ciclo de vida estão lá para serem usados. Saiba como funcionam e use-os para o seu benefício. Sua vida será mais fácil e você perderá menos cabelos.

· Colin Moock’s Lost ActionScript Weekend – The Display List

· Creating New Components in Flex 3

· Diving Deep with the Flex Component Lifecycle

· Understanding the Flex 3 Component and Framework Lifecycle

[1] Expressão americana usada para algo que requer pouco esforço mental ou inteligência para realizar ou compreender

Twitter!

Domain Driven Design

Também conhecido como DDD, Domain Driven Design está bem alta nos tempos mais recentes pelo apelo a maior aderência do sistema a lógica de negócio. Mas mais do que uma receita, ou técnica, DDD é um conceito. Aplicar DDD é mudar a maneira de pensar em relação a modelagem (Design) do modelo de domínio. Trata-se de um maior foco no problema que o cliente quer resolver, e basear os resultados atingidos e caractrísticas do sistema com base em feedback do cliente.
A idéia não é nova, e a semelhança com as práticas ágeis é muito clara, por isso DDD veio a tona nos últimos tempos, embalado com a onda das metodologias ágeis.

Conceitos

Como foi dito anteriormente, e como é pregado no livro do Eric Evans, dito pai do DDD, se trata de uma maneira de pensar mais do que uma receita ou metodologia. Os primeiros capítulos do livro citam casos em que a modelagem da aplicação pode levar em conta um melhor entendimento do negócio, e como um modelagem muitas vezes natural e intuitiva do ponto de vista técnico pode trazer problemas futuros para a aplicação.
Um exemplo interessante presente no livro, é o exemplo de um programa para modelar um circuito eletrônico. Em tal exemplo é primeiro abordado o modelo convencional de modelagem e organização, assim como alguns padrões de projeto pensando mais do ponto de vista técnico da aplicação. Porém componenentes eletrônicos, portas lógicas por exemplo, possuem uma certa intelgência imbutida. No modelo convencional o modelo de negócio é uma camada burra da aplicação, onde somente são armazenados os dados referente ao domínio. Tal abordagem traz problemas quando é necessário simular uma execução do circito eletrônico, pois seria necessário guardar tal inteligência na camada responsável por gerenciar os componentes, tornando a aplicação mais complexa, e concentrando o conhecimento de negócio em um único lugar.
A idéia nesse caso, é tornar o modelo do domínio mais inteligente, e passar a responsabilidade de entender seu funcionamento para as entidades, espalhando mais o conhecimento do negócio, e possibilitando outras partes da aplicação de terem acesso a este mesmo conhecimento somente através do domínio.
Não focarei nesses exemplos nesse post, pois o intuito aqui é mais uma introdução aos conceitos básicos e a nomenclatura muitas vezes empregada em DDD. Vamos ver algumas definições.

Domain

Um Domain (domínio) nada mais é do que uma descrição de um conceito de negócio, contendo as informações que o modelo necessita e o comportamento do modelo. Um exemplo clássico é uma aplicação que precisa gerenciar usuários. Em uma aplicação como esta, usuários carregam informações, podem ser listados, criados, deletados, editados, associados com outras entidades, etc. Toda essa lógica determina um domínio. Então diferente de uma arquitetura convencional MVC por exemplo, onde o modelo seria os dados do usuário, o controller seria responsável por associar e e gerenciar os usuários e a view se encarregaria de mostrar o usuário, em DDD essa lógica faz parte do domínio de usuário.
Parece um pouco overkill concentrar tantas responsabilidades em um único ponto, mas mais forte do que lógica da aplicação, modelar o sistema dessa forma concentra a lógica de negócio em um único lugar também. Com isso podemos acessar o domínio de usuário em qualquer lugar do sistema, e o comportamento será o mesmo em todos os lugares, facilitanto assim quando o modelo de negócio exigir que seja feita alguma alteração no comportamento do domínio de usuário.
Domínio é o centro das atenções em DDD (óbvio), mas já é possível perceber que tanta responsabilidade em um único lugar pode dificultar criação e manutenção de tais domínios. Por isso que existem as outras definições em DDD, para facilitar a manutenção e a modelagem do domínio.

Factory

Factories são responsáveis por criar novos Domains.
Muitas vezes os domínios são complexos, e precisam do auxílio de outras classes de negócio para poder se comportar da maneira esperada. Pensando nesse ponto, os domínios podem ser criados através das Factories, delegando a responsabilidade de preencher e configurar o domínio, deixando para o domínio focar mais na parte de lógica de negócio.
Essas factories podem ser modeladas de acordo com as necessidades da aplicação. O que DDD prega é que se mantenha o conceito, para que caso os domínios precisem ser alterados, de maneira que alguma pré-configuração, ou uma nova entidade de negócio comece a fazer parte do domínio seja incorporada, fique fácil dar manutenção e testar esse novo comportamento.
Porém Factories ainda assim podem acabar tendo muitas responsabilidades no que diz respeito a organização do domínio, em termos de armazenamento de dados mesmo, ou seja, muitas vezes uma representação do domínio como entidade pode ser bem complexa, pois a representação pode ter uma série de dependências para outras entidades e assim por diante, todas dentro do mesmo conceito de domínio.
Pensando nesse possível problema, existe uma outra definição em DDD.

Aggregate

Um Aggregate, como o próprio nome traduzido diz, é um agregado de entidades do domínio.
Sua responsabilidade é respresentar um conjunto de outras entidades que identificam a entidade do domínio. Uma maneira mais prática de se pensar, é que um domínio utiliza um Aggregate para criar a entidade que representa o domínio. A idéia é concentrar a responsabilidade pela entidade do domínio no aggregate, tornando mais fácil a manutenção e alteraçao do modelo de negócio.
Tanto a factory, quanto o aggregate pertencem ao domínio, portanto são características tranparentes ao usuário do domínio, ou seja, os domínios interagem entre si apenas pelas caracterísiticas expostas pelos próprios domínio.

Conclusão

DDD não é a solução para todos os problemas de modelagem de regra de negócio, afinal a modelagem depdende muito mais das pessoas do que do conceito em si, mas é uma maneira mais concisa de pelo menos dar ao sistema uma cara mais parecida com o modelo de negócio, e criar a famosa Ubiquitous Language, onde programadores e pessoas de negócio conseguem se entender melhor.

Por @Gust4v0_H4xx0r