Nov 4

Spring 3.1 RC1 – Profiles

Escrito por DClick Team em 1, 2.0, 4, 6, Air, app, AR, Banco de Dados, bar, BI, C#, carregar, class, código, dados, demo, Desenvolvimento, Dica, dispatch, Download, err, exemplo, for, framework, Google, ide, IE, if, int, interface, Java, LOB, lógica, novidade, Novidades, O, on, Outros, override, refresh, Release Candidate, RIA, Ria’s Geral, S+S, Sem categoria, site, Spring, SpringFramework, string, Sun, TAT, Teste, Twitter, UI, uint, web, XML, zend @ 11 4th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

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:

1
2
3
4
5

public interface ProfileEspecificBean

String recoverActiveProfile();

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

1
2
3
4
5
6
7
8
9
10

public final class Profiles

private Profiles()

public static final String DEV_PROFILE = “dev”;

public static final String QA_PROFILE = “qa”;

}

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

package br.com.dclick.tentativas.beans;

@Component(“profileBean”)
@Profile(DEV_PROFILE)
public class DevEspecificBean implements ProfileEspecificBean

@Override
public String recoverActiveProfile()
return DEV_PROFILE;

}

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

package br.com.dclick.tentativas.beans;

@Component(“profileBean”)
@Profile(QA_PROFILE)
public class QAEspecificBean implements ProfileEspecificBean

@Override
public String recoverActiveProfile()
return QA_PROFILE;

}

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:

1
2
3
4
5
6
7
8
9
10
11

<?xml version=“1.0″ encoding=“UTF-8″?>
xmlns=“http://www.springframework.org/schema/beans”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xmlns:context=“http://www.springframework.org/schema/context”
xsi:schemaLocation=“http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.1.xsd”>

:component-scan base-package=“br.com.dclick.tentativas.beans” />

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

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

public class ProfileBeansTest

@Test
public void testProfileDev()

GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.getEnvironment().setActiveProfiles(DEV_PROFILE);
ctx.load(“classpath:spring31-test-beans.xml”);
ctx.refresh();

// Profile de DEV
ProfileEspecificBean profileBean = ctx.getBean(“profileBean”,
ProfileEspecificBean.class);

Assert.assertEquals(DEV_PROFILE, profileBean.recoverActiveProfile());

@Test
public void testProfileQA()

GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.getEnvironment().setActiveProfiles(QA_PROFILE);
ctx.load(“classpath:spring31-test-beans.xml”);
ctx.refresh();

// Profile de QA
ProfileEspecificBean profileBean = ctx.getBean(“profileBean”,
ProfileEspecificBean.class);

Assert.assertEquals(QA_PROFILE, profileBean.recoverActiveProfile());

}

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:

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

profile=“dev”>
class=“br.com.dclick.tentativas.beans.DevEspecificBean” id=“profileBean” />
>

profile=“qa”>
class=“br.com.dclick.tentativas.beans.QAEspecificBean” id=“profileBean” />
>

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:

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

@Test
public void testProfileDevXml()

GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.getEnvironment().setActiveProfiles(DEV_PROFILE);
ctx.load(“classpath:spring31-test-nested-beans.xml”);
ctx.refresh();

// Profile de DEV
ProfileEspecificBean profileBean = ctx.getBean(“profileBean”,
ProfileEspecificBean.class);

Assert.assertEquals(DEV_PROFILE, profileBean.recoverActiveProfile());

@Test
public void testProfileQAXml()

GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.getEnvironment().setActiveProfiles(QA_PROFILE);
ctx.load(“classpath:spring31-test-nested-beans.xml”);
ctx.refresh();

// Profile de QA
ProfileEspecificBean profileBean = ctx.getBean(“profileBean”,
ProfileEspecificBean.class);

Assert.assertEquals(QA_PROFILE, profileBean.recoverActiveProfile());

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:

1
2
3
4
5
6
7
8

>
-name>dispatcher-name>
-class>org.springframework.web.servlet.DispatcherServlet-class>
-param>
-name>spring.profiles.active-name>
-value>qa-value>
-param>
>

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:

1	-Dspring.profiles.active=”profile1,profile2″

Fazendo Download

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

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

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

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

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

Out 21

DClick Mantra

Escrito por DClick Team em 1, 2.0, 3.5, 4, 6, Air, AR, BI, blog, busca, C#, class, escritório, if, image, lógica, mg, Notícias, O, on, problema, problemas, Ria’s Geral, S+S, tag, TAT, Tecnologia, Twitter, UI, XP @ 10 21st, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

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

Set 11

Teoria da criação do conhecimento

Escrito por Edgard Davidson em 1, 2.0, 4, 6, AR, BI, C#, dynamic, for, git, IE, if, int, lógica, map, mapa, Mestrado, mg, O, on, Outros, Partilha, processo, RIA, Ria’s Geral, RoR, S+S, social, XP, zend @ 09 11th, 2011 | via http://edgarddavidson.com | Sem comentários

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.

Seci

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.

Ago 26

Workshop na FNAC de Santa Catarina, Porto

Escrito por Mauro Martins em .NET, 1, 2.0, 4, 6, Adobe, Adobe User Group, app, app store, AR, AUG, BI, blog, C#, class, dados, Desenvolvimento, Design, Desktop, Diversos, event, Evento, Eventos, Experiências, for, ide, IE, if, image, int, Introdução, Links e sugestões, lógica, map, mg, mobile, O, on, Partilha, pt, Random, RIA, Ria’s Geral, S+S, UI, User Group, Vários, Workshop, XP @ 08 26th, 2011 | via http://imauro.com/blog/ | Sem comentários

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.

Jul 28

Estratégia para lidar com callbacks assíncronos em Silverlight

Escrito por Kelps Sousa em .NET, 1, 4, 6, action, AR, back, BI, blog, C#, class, classe, código, dados, demo, Desenvolvedor, desenvolvedores, Desenvolvimento, Download, err, erro, error, event, Evento, Eventos, exemplo, for, framework, gc, Google, html, IE, if, int, LOB, lógica, map, mg, MSDN, NaN, News, O, on, problema, Projetos, pt, RIA, Ria’s Geral, RoR, S+S, silverlight, Silverlight 4, string, tag, TAT, Tutorial, Twitter, UI, Ved, web, Web Service, web services, WebClient, XP @ 07 28th, 2011 | via http://kelps-sousa.blogspot.com/ | Sem comentários

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.

Mai 19

10 coisas que um bom programador flex deve saber

Escrito por Daniel Schmitz em .NET, 1, 2.0, 2009, 3.5, 4, 6, action, Action Script, Actionscript, ActionScript 3, Actionscript 3.0, Actionscript3, Adobe, Air, api, Aplicativos, Apresentação, AR, Arquitetura, arte, Artigo, as3, BI, Bindable, blog, bug, builder 4, C#, Cairngorm, class, classe, classes, código, código fonte, Componente, Componentes, components, control, Controles, css, Curso, Cursos, custom, dados, Data Binding, DataGrid, Debug, demo, desempenho, Desenvolvedor, desenvolvedores, Design, developer, development, dispatch, dispatchEvent, DRE, empresas, err, Estilo, event, EventListener, Evento, Eventos, eventos customizados, events, Excel, explorer, Ferramenta, flash, flash builder, Flash Builder 4, Flash Player, Flex, Flex 3, Flex 4, Flex Examples, fonte, for, framework, Frameworks, Google, Gráfico, handle, html, HTTPService, ide, IE, if, int, interface, Java, layout, lista, live, Livro, lógica, map, Mate, MAX 2009, mvc, MXML, O, on, oop, opensource, Outros, player, polimorfismo, problema, problemas, programação, Projetos, pt, RIA, Ria’s Geral, ruby, S+S, site, skins, Sun, tag, TAT, Tech, Tecnologia, tv, UI, uint, utf8, Ved, Vídeo, vs, web, Webservice, XML, XP @ 05 19th, 2011 | via http://flex.etc.br | Sem comentários

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

Abr 15

DDD

Escrito por DClick Team em 1, 4, AR, Arquitetura, arte, back, bar, BI, carregar, class, classe, classes, cliente, Componente, Componentes, configuração, control, dados, demo, Design, exemplo, Exemplos, for, futuro, ide, IE, if, int, Introdução, lista, Livro, lógica, mvc, NaN, O, on, problema, problemas, RIA, Ria’s Geral, Sem categoria, TAT, Tema, Twitter, UI, UX, XP @ 04 15th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

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

Mar 10

Adobe Photoshop CS5 – Criação de Interface para Flex 4

Escrito por DClick Team em 1, 4, 6, Adobe, app, AR, arte, bar, BI, blog, Botões, busca, Catalyst, class, cliente, Curso, demo, Design, designer, Destaque, Flex, Flex 4, Flex4, for, Formação, git, ide, IE, image, imagens, int, interface, lógica, menu, mg, O, on, padrão, photoshop, processo, produto, pt, RIA, Ria’s Geral, screen, Screencast, screencasts, site, TAT, Tecnologia, Tutorial, Twitter, UI, user experience, UX, Vídeo, web, XP @ 03 10th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Essa é uma aula a tempos pedida pela galera que assiste as aulas de Catalyst. Acontece que não dá para dar aula sobre tudo, vamos aos poucos dando ênfase naquilo que é mais pertinente a essa atividade que se chama Design de Interface, que é o que faço na DClick, juntamente com a parte de User Experience.

Com base nisso, pedi ao nosso Arquiteto de Informação que criasse alguns wireframes de algo bem genérico, optamos por um ShowRoom Virtual feito em Flex, desses que não podemos chamar de mero website, e sim uma aplicação inteligente para mostrar aos clientes alguns produtos, apesar de web, eu não considero como site e sim como uma webapp.

Enviei algumas premissas ao nosso Arquiteto que foram:

Criar um showroom virtual que pode na verdade ser qualquer coisa.

Ele será feito em flex4.

Não quero utilizar combo, quero uma navegação tranquila e mais fácil, porém tudo será dinâmico, ou seja, por um admin poderá ser alterado o menu, o que terá na vitrine etc. Isso na nossa lógica. Nós mesmos iremos até a parte da Skin.

1. Terá uma vitrine com uns 6 produtos em destaque.

2. Cada produto tem suas 3 ou mais fotos, e poderá ter até 1 vídeo.

3. A visualização desses produtos em destaque se dará por pageflip.

4. O menu será horizontal

5. Terá busca.

6. Menu por categoria e subcategoria.

7. Utilizará o tamanho padrão, não pode ter barra de rolagem.

8. Deverá ter o mínimo de coisa no menor espaço possível.

9. Vamos explorar mesmo a navegação do flex como se fosse um iOS (um iPad) etc..

Baseada nessas premissas nosso Arquiteto criou os wireframes, o mesmo ficou de criar alguns screencasts mostrando como funciona esse processo.

AULA 1

Vamos aprender como criar uma interface completa no Adobe Photoshop CS5, nosso foco é criar uma interface para Flex 4.

AULA 2

Criando o menu Bar com buttons e técnica para visualização do Wireframe diretamente na interface.

AULA 3

Trabalhando com os estados dos botões, up, over, down, técnicas para criar facilmente essa skin.

AULA 4

Aprendendendo a tabalhar com Layer Comps

AULA 5

Finalização da parte mais básica da interface, aplicação das imagens no ambiente com a mask.

AULA 6

Trabalhando bastante com SmartObject

_________________________________________

Eduardo Horvath é UX Specialist e Designer na DClick.
Formado pela Faculdade Impacta de Tecnologia no curso Design de Mídia Digital ele atua na área de Design a mais de 15 anos.
@eduardohorvath

Mar 3

Spring WEBMVC – Annotations

Escrito por DClick Team em 1, 2.0, 4, 6, app, Apresentação, AR, Arquitetura, arte, BI, blog, busca, camp, class, classe, classes, configuração, control, custom, dados, demo, Desenvolvimento, Design, Design Pattern, dispatch, err, exemplo, Ferramenta, for, framework, Google, IE, if, image, int, interface, j2ee, Java, lógica, map, Mercado, mg, mvc, NaN, Negócios, O, on, Outros, padrão, pattern, procura, programação, pt, reference, rest, RIA, Ria’s Geral, screen, Screencast, server, serviço, servidor, site, Spring, SpringFramework, string, Sun, tag, TAT, Tema, Teste, Twitter, UI, uint, UX, validação, web, XML, XP, zend @ 03 3rd, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

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:

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

-app xmlns=“http://java.sun.com/xml/ns/j2ee” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
? ? version=“2.4″ xsi:schemaLocation=“http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd”>
? ?
? ? >
? ? ? ? -name>servletName-name>
? ? ? ? -class>org.springframework.web.servlet.DispatcherServlet-class>
? ? ? ? -on-startup>1-on-startup>
? ? >

? ? -mapping>
? ? ? ? -name>servletName-name>
? ? ? ? -pattern>/*-pattern>
? ? -mapping>

-app>

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:

1
2
3
4

? ? package br.com.dclick;

? ? @Controller
? ? public class ServicoComum {

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:

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

<?xml version=“1.0″ encoding=“UTF-8″?>
xmlns=“http://www.springframework.org/schema/beans”
? ? xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xmlns:context=“http://www.springframework.org/schema/context”
? ? xsi:schemaLocation=“http://www.springframework.org/schema/beans
? ? ? ? http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
? ? ? ? http://www.springframework.org/schema/context
? ? ? ? http://www.springframework.org/schema/context/spring-context-3.0.xsd”>

? ? :annotation-config />

? ? :component-scan?base-package=“br.com.dclick” />

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:

1 2	? ? @RequestMapping(value = “/chamada”, method = RequestMethod.GET) ? ? public ModelAndView trataChamada(@PathVariable(“var”) String var) {

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:

1 2	? ? @Controller(“/base”) ? ? public class ServicoComum {

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:

1
2
3
4
5

? ? id=“viewResolver”
? ? ? ?? ?class=“org.springframework.web.servlet.view.UrlBasedViewResolver”>
? ? ? ? name=“prefix” value=“/WEB-INF/jsp/”/>
? ? ? ? name=“suffix” value=“.jsp”/>
? ? >

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

Fev 16

BDD – Do que se trata?

Escrito por DClick Team em 1, 4, 6, análise, AR, arte, auto, bar, Behavior, bug, class, classe, classes, cliente, código, comunicação, cultura, demo, Desenvolvedor, Desenvolvimento, Desenvolvimento de Software, development, err, erro, exemplo, Ferramenta, for, Formação, framework, Frameworks, IE, if, int, Java, lógica, NaN, O, on, Opinião, problema, problemas, programação, Projetos, relatório, RIA, Ria’s Geral, Sem categoria, serviço, Software, Sun, TAT, Tema, Teste, Twitter, UI, Ved @ 02 16th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

BDD – Behavior Driven Development

BDD está ficando mais conhecido ultimamente e muitas pessoas estão adotando a prática no dia a dia de desenvolvimento. Mesmo assim BDD é tão antigo quanto o próprio TDD (Test Driven Development).
BDD nada mais é do que trazer ao código, e principalmente ao código que testa os casos de uso da aplicação, um pouco mais da lógica de negócio e do problema que está sendo resolvido no nível do usuário.

Melhorando a comunicação

Quando escrevemos algum teste unitário, normalmente damos um nome ao teste para que possamos entender os resultados quando gerarmos um relatório após a execução dos mesmos. Também damos nomes que façam sentido, para facilitar a comunicação da equipe de desenvolvimento, pois se outra pessoa da equipe precisar dar manutenção no teste, torna mais fácil a compreensão do que o teste está encarregado de testar sem que seja necessário ler muitas linhas de código.

Nos tempos atuais falamos bastante de aumentar a integração da equipe com o cliente ou a área que entende do negócio da aplicação. Também falamos em uma maior colaboração de ambas as partes no desenvolvimento de software. Para quebrar essa barreira que existe entre desenvolvimento e análise, algumas equipes empregam uma programação mais voltada a resolver os casos de uso propostos, ao invés de resolver problemas de baixo nível e compor uma aplicação final.

BDD prega que o problema que será resolvido deve estar bem claro para a parte quem entende do negócio (chamarei de cliente, mesmo que algumas vezes não seja necessariamente um cliente), e quem desenvolve a aplicação em si. Para isso são escritos casos de testes baseados nos casos de uso do sistema, e tais casos de teste usam uma linguagem comum para ambas as partes.

Como normalmente o cliente não é técnico, fica muito difícil se comunicar com ele via testes unitários em código, e fica mais difícil ainda que o cliente colabore com a melhoria e a escrita de tais testes. Porém, os testes unitários e automatizados são a melhor ferramenta do desenvolvedor para testar a aplicação e garantir que a equipe mantenha o código funcionando.

Para suportar ambas as necessidades, e implantar o BDD de fato, uma das soluções é associar o problema de cada caso de uso, a um teste unitário que irá se certificar que aquele caso de uso está sendo corretamente executado.

Por exemplo, em java podemos dar nomes a nossas classes de teste de acordo com o caso de uso que aquele teste se refere. E podemos também nomear os métodos como a execução específica daquele caso de uso:

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

public class TesteDeCadastroDeUsuario {
? ?
? ? @Test
? ? public void testeDeCadastrarNovoUsuario() {
? ?
? ? ? ? // … cadastra o usuário
? ?
? ? ? ? Assert.assertTrue(“Usuário novo não foi cadastrado corretamente, “
? ? ? ? ? ? ? ? ? ? ? ? + “pois o nome está inválido.”,
? ? ? ? ? ? ? ? ? ? ? ? nomeUsuarioValido());
? ?
? ? }
? ?
}

Dessa forma quando o cliente ver o resultado dos testes e perceber que este teste falhou, ao invés de ler algo como “O serviço de usuário voltou null.”, ele conseguirá ler “No teste de cadastro de usuário, ao testar que um usuário novo está sendo cadastrado, o teste falhou pois o usuário não possui um nome válido, logo não foi cadastrado.”

Parece pouca coisa, mas para o cliente é um informação muito importante nas discussões sobre prioridade de correção de bugs e melhorias do sistema. Isso porque fica claro para o cliente quando o desenvolvedor descreve o teste exato que falhou e o cliente sabe exatamente a qual caso de teste se refere e qual o problema que está sendo resolvido. Não é informação pertinente ao cliente como que tecnicamente se corrige o problema e como que o sistema está implementado para que o erro ocorre-se, esse é o papel do desenvolvedor.

Simples e Efetivo, mas não é a Silver Bullet

Existem muitos frameworks para facilitar a empregação do BDD. Vimos aqui que mais do que um framework, BDD é uma cultura e pode ser empregado sem o uso de qualquer ferramenta, pois o importante é manter a comunicação entre os níveis técnicos diferente na mesma equipe.

Muitos correm atrás da implantação do BDD nos projetos com a esperança de que os problemas na resolução de bugs e na comunicação da equipe serão resolvidos. Isso não é verdade e seu projeto irá dar tão certo quanto ele daria antes da adoção de BDD. BDD é um mudança de comportamento na equipe onde todos devem estar empenhados na causa de melhorar a comunicação, e tentar entender os problemas de verdade que o sistema se propõe a resolver.

A mudança de comportamento tem que partir do lado do cliente também, pois é necessário a compreensão de que os erros que estão claros para ele agora, não surgiram do nada. Na verdade eles sempre estiveram presentes no sistema, só que protegidos pela barreira que impedia a comunicação entre de desenvolvimento e análise.

Espero ter sido claro, qualquer opinião sobre o assunto será bem vinda.

Por @Gust4v0_H4xx0r

« Entradas anteriores | Entradas recentes »