Um problema comum é quando sua aplicação Flex tentar acessar uma url de um domínio diferente da que esta no browser.
Para esse tipo de problema você pode hospedar no seu Server o arquivo crossdomain.xml.
Segue um exemplo de crossdomain.xml:
Após ter esse arquivo hospedado vamos ao Flex:
protected function application1_creationCompleteHandler(event:FlexEvent):void{
Security.allowDomain("http://dominio.com");
Security.loadPolicyFile("http://dominio.com/crossdomain.xml");
}
Caso sua aplicação esteja apresentando datas com um dia a menos ou erradas essa pode ser a solução.
Crie a classe?ServletContextListenerTimefix.java :
package com.xxx.business.listeners;
import java.util.TimeZone;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
public class ServletContextListenerTimefix implements ServletContextListener {
@Override
public void contextDestroyed(final ServletContextEvent $event) {
}
@Override
public void contextInitialized(final ServletContextEvent $event) {
TimeZone.setDefault(TimeZone.getTimeZone("GMT-3"));
}
}
Depois set ela no web.xml:
com.xxx.business.listeners.ServletContextListenerTimefix
Na programação orientada a objetos um iterador é um objeto que possibilita o programador a examinar um objeto que contem outros objetos (container).
As semânticas de acesso dos iteradores são fixas e você pode implementar diversos tipos de iteradores de forma desacoplada a partir de uma interface.
Imagine um iterador como um cursor de uma base de dados onde os elementos são acessados sequencialmente (cursor).
Os arquivos utilizados podem ser encontrados em:
https://github.com/wlepinski/as3-patterns/tree/master/Iterator
Basicamente a interface de um iterador pode ser definida como:
|
1
2 3 4 5 6 7 8 |
public interface IIterator
? ? function first ():void; ? ? function next ():void; ? ? function isDone ():Boolean; ? ? function currentItem ():*; ? ? function hasNext():Boolean; |
Com essa interface podemos prover algumas implementações de iteradores para qualquer tipo de objeto que descreva qual o seu iterador, a interface abaixo será utilizada pelos nosso objetos que podem ser iterados.
|
1
2 3 4 5 6 7 |
public interface IAbstractList
? ? function createIterator ():IIterator; ? ? function count ():int; ? ? function append ( item:Object ):void; ? ? function remove ( item:Object ):void; |
Vamos criar um iterador (ArrayIterator) que implementa a interface IIterator e recebe como parâmetro no construtor um ArrayList que também vamos implementar a seguir:
Implementação do ArrayIterator:
|
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 |
public class ArrayIterator implements IIterator
? ? public var index:int = 0; ? ? public var list:ArrayList; ? ? public function ArrayIterator ( list:ArrayList ) |
Implementação do ArrayList:
|
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 |
public class ArrayList implements IAbstractList
? ? public var array:ArrayCollection = new ArrayCollection(); ? ? ? ? public function ArrayList () ? ? ? ? ? ? ? ? public function createIterator ():IIterator ? ? ? ? ? ? return new ArrayIterator( this ); ? ? ? ? ? ? public function count ():int ? ? ? ? ? ? return array.length; ? ? ? ? ? ? public function append ( item:Object ):void ? ? ? ? ? ? array.addItem( item ); ? ? ? ? ? ? public function remove ( item:Object ):void ? ? ? ? ? ? array.removeItemAt( array.getItemIndex( item ) ); ? ? } |
Podemos utilizar o iterador de duas formas, em um “for” ou em um “while”:
|
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 |
var list:IAbstractList;
var iterator:IIterator; // Utilizando o for???? iterator = list.createIterator(); // Usando while iterator = list.createIterator(); while ( iterator.hasNext() ) |
Apesar de detestar telefones, coisa que sempre achei por demais invasiva, tenho um celular, que uso basicamente por causa do GPS (para treinamentos de bike) e o Facebook (culto ao ego). Ligações são raras, tanto in quanto out. Não faz muito tempo que tenho um smartphone pois relutei o quanto pude a mudar meu confortável [...]
A minha esposa Fernanda Musardo e a Camila Porto preparam um curso sensacional sobre como utilizar o poder das Mídias Sociais em favor da sua empresa.
Por isso meu amigo desenvolvedor, se a sua empresa ainda ignora as redes sociais, mande o link do curso para a turma da marketing da sua empresa e recomende que alguém do departamento faça o curso.
Tenho certeza que a sua empresa conseguirá aumentar o engajamento da sua marca e produtos nas redes e conseqüentemente, aumentar o faturamento da sua empresa, e quem sabe de lambuja você não ganha um aumento salarial pela indicação?
O Membase é um sistema de gerenciamento de banco de dados chave-valor distribuído, otimizado para aplicações web interativas.
O Membase é utilizado em produção em milhares de aplicativos no mundo, entre as grandes empresas que utilizam temos Zynga e NHN. E já também disponível no host compartilhado Heroku.
Infelizmente hoje os hosts brasileiros nos planos compartilhados é dificil encontrar suporte à tecnologias noSQL como o Membase, CouchDb, MongoDb, etc, e com isso forçam os desenvolvedores fazerem software utilizando bancos de dados relacionais que não são aderentes à programação orientada a objetos.
Banco de dados relacional é muito recomendado para persistência de dados que não são utilizados com muita frequência e também para aplicações cujo objetivo é gerar relatórios. Então uma ótima sacada é utilizar as duas tecnologia juntas. Para os dados que são constantemente utilizados por sua aplicação utilize o Membase, para os dados utilizados com menos frequencia use banco de dados relacional.
Porém adotar o modelo chave-valor traz consigo uma pequena “dor”, pois você será forçado a mudar a forma como os dados serão gravados e buscados em sua aplicação, pois o Membase é uma estrutura de dicionário, ou seja, as operações de busca e remoção dependem diretamente de você saber de ante-mão a chave de onde está o registro.
Escolha a versão que mais se adequa a sua necessidade: Enterprise Edition ou Community Edition, eu recomendo a versão Enterprise.
Disponível para Windows, Red Hat e Ubuntu.
O arquivo de instalação tem em média 80MB.
http://www.couchbase.com/downloads
A instalação é bem simples seguindo o modelo AVANÇAR, AVANÇAR, …, CONCLUIR.
Após a conclusão da instalação o browser é aberto com a página de SETUP do Servidor Membase.
A primeira etapa da configuração do servidor é definir o local onde serão persistidos os dados, escolher se essa instância será um novo cluster ou se juntará a um cluster existente.
Caso for criar um novo cluster, defina a quantidade máxima de memória você deixará disponível para o Membase utilizar. Ele só alocará a memória quando necessário.
Agora é hora de criar o Bucket Default, container isolado de dados, a área onde ficarão os dados.
Você pode escolher entre os tipos Memcached e Membase as diferenças entre os dois são muitas, mas as mais importantes são: Membase persiste no disco e Memcached não, o Memcached possui o limite de 1MB por valor em cada registro, no Membase o limite são 20MB.
Uma dica, como você pode criar vários Buckets, sugiro você separar os assuntos de dados do seu sistema em Buckets distintos, isso facilitará sua vida quando precisar definir qual o modelo de chave utilizar para guardar os dados, acredite em mim.
Defina um usuário e senha para acessar o serviço, esses dados também serão utilizados para acessar o painel administrativo do Membase.
Esse é o painel administrativo do Membase.
Assim concluimos a etapa de instalação e configuração do Membase. Simples né?!
Agora vamos trabalhar com a integração entre o .NET e o Membase, para isso antes de mais nada é necessário utilizar um client para a linguagem que a sua aplicação foi ou será escrita, no nosso caso .NET.
Hoje as linguagens que já possuem cliente são:
Para fazer o download do cliente acesse: http://techzone.couchbase.com/downloads
Primeiro copie as DLL’s Enyim.Caching.dll e Membase.dll para a pasta BIN do seu projeto e adicione a referência dessas DLL’s no projeto.
No web.config ou app.config da sua aplicação acrescente as seguintes configurações:
Para utilizar o Membase você precisa criar uma instância do MembaseClient passando como prâmetros o nome e senha do bucket:
var membaseClient = new MembaseClient("default", "senha_bucket");
Para armazenar os dados no Membase utilize o método SET:
membaseClient.Set(StoreMode.Set, “key01”, “value01”);
Para o valor o membase aceita qualquer tipo de objeto. O método SET adiciona uma chave inexistente ou substitui uma chave existente.
Para resgatar um valor amazenado utilize o método GET:
var valor = membaseClient.Get(“key01”); // Retorna “value01”
Agora que você foi apresentado ao Membase pode já começar a brincar a fazer testes para aumentar o throughput e a escalabilidade da sua aplicação.
Até o próximo post.
Divita-se.
A data do evento mudou do dia 30 de abril para 14 de maio.
O IT Care Paraná é uma iniciativa da comunidade de TI (Java, .NET, Android, Apple, Linux, etc) para auxiliar, através de palestras técnicas, as vítimas do litoral paranaense afetadas pelas chuvas.
Notícias sobre as chuvas no litoral do Paraná:
Chuvas isolam litoral do Paraná e 8 mil pessoas deixaram as casas
Chuvas no Paraná deixam prejuízos estimados em mais de R$ 87 milhões
Chuvas no Paraná voltam a interditar duas rodovias; Morretes decreta calamidade pública
Chuvas no litoral paranaense tiram 16 mil de suas casas
O evento não tem intenção de levantar bandeira de tecnologia específica, afinal, quanto maior o público maior será a arrecadação para as vítimas: o mais importante no momento.
A idéia principal é arrecadar alimentos não-perecíveis, material de limpeza e água mineral, haja vista que são os essenciais.
Com o IT Care você não estará apenas se atualizando, incrementando o conhecimento, aumentando redes de contatos e conhecendo outras tecnologias, estará também ajudando diretamente os mais necessitados.
O IT Care Paraná é uma iniciativa da comunidade de TI (Java, .NET, Android, Apple, Linux, etc) para auxiliar, através de palestras técnicas, as vítimas do litoral paranaense afetadas pelas chuvas.
Notícias sobre as chuvas no litoral do Paraná:
Chuvas isolam litoral do Paraná e 8 mil pessoas deixaram as casas
Chuvas no Paraná deixam prejuízos estimados em mais de R$ 87 milhões
Chuvas no Paraná voltam a interditar duas rodovias; Morretes decreta calamidade pública
Chuvas no litoral paranaense tiram 16 mil de suas casas
O evento não tem intenção de levantar bandeira de tecnologia específica, afinal, quanto maior o público maior será a arrecadação para as vítimas: o mais importante no momento.
A idéia principal é arrecadar alimentos não-perecíveis, material de limpeza e água mineral, haja vista que são os essenciais.
Com o IT Care você não estará apenas se atualizando, incrementando o conhecimento, aumentando redes de contatos e conhecendo outras tecnologias, estará também ajudando diretamente os mais necessitados.
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.
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.
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.
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.
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.
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
Como nós já vimos em posts anteriores, é muito simples alterar o skin de um componente Spark. Com o exemplo abaixo, você aprenderá a customizar a aparência do componente Spark ButtonBar e também a inserir ícones em seus botões.
Your browser does not support iframes.
Download do código fonte do projeto:
CustomButtonBar – 573kb
Espero que tenham gostado e até a próxima!
