Veja também:

• Python : aumento e redução percentual
• Por tr?s das cenas : jogo : De volta para o futuro
• Veja o Sikorsky X2 quebrando o recorde mundial de velocidade de helicópteros
• [Curiosidade] Música Panamericano
• Porque os Hard Disks eram chamados de winchester?

Já está aberta a venda do livro jQuery Mobile na Prática. Por apenas R$ 10,00, você terá a chance de conhecer este framework do melhor jeito possível, através de exemplos práticos!

O lançamento ocorrerá no dia 27/02.

Muitas surpresas estão por vir, aguarde!

http://www.danielschmitz.com.br/jquery-mobile-na-pratica.html

Identifica??o por radiofrequ?ncia ou RFID (do ingl?s “Radio-Frequency IDentification” ) ? um m?todo de identifica??o autom?tica atrav?s de sinais de r?dio, recuperando e armazenando dados remotamente atrav?s de dispositivos denominados etiquetas RFID.

Uma etiqueta ou tag RFID ? um transpondedor, pequeno objeto que pode ser colocado em uma pessoa, animal, equipamento, embalagem ou produto, dentre outros. Cont?m chips de sil?cio e antenas que lhe permite responder aos sinais de r?dio enviados por uma base transmissora. Al?m das etiquetas passivas, que respondem ao sinal enviado pela base transmissora, existem ainda as etiquetas semi-passivas e as ativas, dotadas de bateria, que lhes permite enviar o pr?prio sinal. S?o bem mais caras que do que as etiquetas passivas. (Wikip?dia)

Agora imagine um RFID aplicado em um cart?o fidelidade de um Shopping ou uma Loja como a FNAC por exemplo, e atrav?s de um sistema o vendedor com um tablet consiga ter em as ?ltimas compras, o t?cket m?dio, prefer?ncias e outras informa??es adicionais dos consumidores portadores desses cart?es e consiga dar um tratamento totalmente personalizado e pr?-ativo para cada poss?vel comprador.

Com algoritmos de intelig?ncia artificial o sistema poderia identificar se o consumidor estaria disposto ou n?o a comprar naquele momento. Quando a pessoa estivesse marcada como verde no sistema, ela estaria disposta a comprar, e quando vermelho apenas estaria pesquisando. Isso sinalizaria qual a melhor abordagem do vendedor para casa ocasia??o.

Hoje j? temos tecnologia suficiente para aplicarmos esse modelo em nosso dia-a-dia.

Confira o v?deo abaixo que demonstra como seria a aplica??o real desse sistema.

Agora que voc? viu, fica a provoca??o para voc? desenvolver esse sistema.

Veja também:

• Oracle XE : Mudando a porta padrão HTTP
• Como jogar Call Of Dudy 4 MW em servidores do Brasil?
• WebLogic 10.x + Hibernate 3 (JPA) e base Oracle 9+
• [Adobe Flex] Definindo o foco na aplicação
• [Adobe Flex] comparando datas de maneira rápida e fácil

SharedObject é um recurso que dar ao Flash Player a capacidade de salvar dados localmente para poder ser usado posteriormente em sua aplicação, a grosso modo é como um cookie. Com o Flash Media Server, foi introduzido a possibilidade de usar o SharedObject Remote, no qual os dados são salvos no servidor Flash Media Server e compartilhados para todas as instâncias de uma conexão entre o Flash Player e o Flash Media Server. Isso possibilita a criação de aplicativos em real time como Dashboards, chats e o que mais a imaginação permitir.

O uso do SharedObject Remote pode ser usado de duas maneiras em conjunto com o Adobe Flash Media Server.

• Somente pelo lado cliente, através do Flash Player/AIR
• Em conjunto com ActionScript Communication, linguagem de servidor do Flash Media Server

Vejamos o primeiro caso:

Através do lado cliente, através do Flash Player/AIR

Caso você não tenha conhecimento para usar a linguagem Server-side do Flash Media Server, é possível utilizar o SharedObject Remote somente pelo ActionScript 3.0. Vamos a um exemplo clássico sharedBall, onde o objetivo é compartilhar as posições da bolinha a atualizar nos outros clientes conectados a mesma instância.

• Vá até o diretório de instalação do Flash Media Server e procure pela pasta “applications”, lá crie um diretório chamado “sharedBall”, dentro dele um arquivo chamado “main.asc”
• Abra o main.asc no seu editor de textos de preferencia ou pelo próprio Flash e digite: trace(“sharedBall…”);
• Vamos testar esse arquivo, abra o console do Flash Media Server, geralmente fica localizado no diretorio de instalação/webrrot/swfs. Você pode abrir pelo browser ou o swf diretamente.
• Clique no botão “View Applications” e em seguida procure o nome “sharedBall” no combobox logo no canto inferior esquerdo onde está escrito “New Instance…”
• Selecione “sharedBall” e deveremos ter na aba Live Log algo como na imagem abaixo:

• No Flash, criei uma bola com as ferramentas de desenho e converti para MovieClip dando o nome de “mc_ball”.
• Estamos prontos para começar a integração entre o Flash e o Flash Media Server. Crie um layer para o ActionScript e abra o editor apertando F9 ou “Window->Actions”
• Nosso código começa com a conexão com o servidor Flash Media Server

Feito isso, podemos testar o swf apertando Ctrl+Enter, se tudo correr bem, deveremos ter a seguinte mensagem no output do Flash:

NetConnection.Connect.Success

Com a conexão feita, podemos instanciar o nosso SharedObject Remote para compartilhar as posições de x e y da bolinha.

O handlerSync é responsável por atualizar os dados de x e y pegaremos do SharedObject Remote:

Daremos a opção de ao clicar na bolinha, que ela possa ser arrastável, em seguida atualizaremos as posições de x e y no SharedObject Remote:

Segue o código completo:

Veja uma demostração em funcionamento:

Download sharedBall

O Visual Studio 2010 tem diversos recursos que estão muito bem escondidos nos seus vários menus e telas de configuração, mas são acessíveis por teclas de atalho. Isso é vantajoso em diversas situações pois pode agilizar a utilização desses recursos mas também pode se tornar uma irritação ou mesmo um problema se você por acaso acionar uma dessas teclas de atalho por acidente e não souber como voltar atrás. Foi o que aconteceu com um colega no trabalho recentemente.

Por acidente esse colega acionou uma tecla de atalho do Visual Studio 2010 que ativa a exibição de caracteres ocultos (white space). Em outras palavras, o Visual studio passou a exibir todos os espaços e marcação de final de arquivo na tela. O resultado foi algo semelhante ? imagem abaixo:

Não parece ser algo muito irritante neste exemplo pois há pouco código, mas em arquivos com centenas de linhas de código e em arquivo com html esse modo de visualização é bastante irritante e chega a atrapalhar a produtividade pois polue visualmente a tela. Esse colega passou quase 2 meses trabalhando com essa configuração pois não conseguia encontrar um meio de desfazer e voltar ao modo normal de visualização. Ele chegou inclusive a reinstalar o Visual Studio mas não adiantou pois o instalador não removeu as configurações problematicas.

Hoje eu dei uma pesquisada um pouco mais a fundo e acabei encontrando a solução. A opção do menu para essa configuração se encontra em Edit > Advanced > View White Space e pode ser acionada pela tecla de atalho Ctrl+E, S (que foi o que aconteceu com meu colega).

O artigo Adobe Flex com PHP usando ZendAMF – primeiros passos teve como objetivo exemplificar a integração do Flex com PHP para quem já tinha sistemas desenvolvidos usando o AMFPHP, por isso não usei as classes para acesso a banco de dados do ZendFramework. Neste artigo mostrarei o mesmo exemplo mas usando exclusivamente ZendFramework.

Pegarei o mesmo exemplo utilizado no artigo anterior, só modificando a classe PHP para usar as classes de abstração de banco de dados do ZendFramework. Começaremos com nosso gateway.php

Executando o link no seu navegador, deve aparecer a seguinte mensagem:

Zend Amf Endpoint

Em seguida, modificaremos em nossa classe principal, que efetuará as operações de listar, inserir, apagar e atualizar os dados do nosso banco:

No ActionScript só precisaremos mudar o que será passado para o PHP, ao inves de VOs, mandaremos Arrays:

Referências:
http://framework.zend.com/manual/en/zend.db.adapter.html

Twitter!

A última implementação da HibernateDAOFactory do módulo persist do DCF, agora permite que seus DAOs de entidade possuam propriedades injetadas diretamente do container de beans do Spring.

No exemplo que temos nos testes de projeto, temos o MockDAO, que possui uma propriedade String com nome ‘testeString’:

Note que no setter da propriedade, colocamos a anotação @Autowired, para recuperar esta String do container, e também associamos o Qualifier ‘testeString’.

No arquivo de beans do spring, basta adicionarmos um bean String com o id igual ao do qualifier:

Repare que o valor da String é ‘stringTeste’. Vamos ver em nosso teste agora se tal valor chega corretamente no DAO:

Uma coisa importante a se perceber, é que a chamada da DAOFactory permanece exatamente a mesma, mantendo assim a retro-compatibilidade com as outras versões, e apenas as injeções baseadas em anotações do Spring vão ser consideradas.
NÃO é necessário apontar o component-scan do Spring para o pacote de DAOs de sua aplicação. A injeção de beans adicionais é feita completamente a parte, seguindo o mesmo padrão de nome e de instanciação dos DAOs.

Qualquer dúvida, basta me procurar.

O projeto está no github, dentro do módulo persist do dclick-framework, ou diretamente no nexus da DClick.

O portal E-commerce Brasil realizou recentemente uma pesquisa com as principais lojas virtuais do pa?s com o objetivo de saber mais sobre as plataformas utilizadas.

Plataforma Pr?pria x Tercerizada

ERP?

Atendimento Online

Selos de Seguran?a

Como expor os produtos no e-commerce

Categorias

Fotos

Uma vis?o geral sobre os e-commerces analisados

Twitter!

Já que ultimamente estamos falando bastante de testes unitários, principalmente aqui na DClick, vamos revisar uma das ferramentas essenciais para executar essa tarefa: JUnit. Mais especificamente, vamos fazer alguns testes com o JUnit 4.8.1, que pode ser encontrado para download no site do projeto, ou até mesmo no repositório do maven.
A proposta desse post é apresentar a ferramenta para quem ainda não conhece, e relembrar ou até mesmo mostrar algumas funcionalidades muito úteis para nosso dia a dia de desenvolvimento.

Um pouco sobre a nova versão

Nas versões anteriores do JUnit, da 3.* pra baixo para ser mais exato, era necessário criar as classes de testes seguindo uma hierarquia pré-definida do JUnit para que os testes fossem executados. Era necessário extender uma das classes de Test Case do JUnit, e seus métodos precisavam seguir um padrão de nome específico definido pelo framework.
Com a versão 4.* e a introdução ao suporte a Java 5, agora todas as configurações de testes unitários em JUnit são feitas via anotações, o que na minha opinião é muito mais rápido e fácil, tornando muito mais agradável e flexível escrever testes unitários. Agora é possível definir umahierarquia específica para os testes do projeto, podendo abstrair muitas inicializações e padrões do sistema, facilitando o reaproveitamento e aumentando a velocidade de desenvolvimento. Afinal a maior parte do tempo gasto em desenvolvimento é com os testes.
Porém, com anotações, perdemos o acesso direto aos métodos de asserção de valores que as super classes definiam. A solução adotada foi tornar todos esses métodos estáticos e públicos, em uma classe específica para guardá-los: org.junit.Assert.
Pode parecer uma solução não muito elegante do ponto de vista de código, e de fato não é quando consideramos código que será distribuído e deploiado, porém é uma solução que faz total sentido no escopo dos testes unitários, tornando fácil o uso e acesso a tais funcionalidades.

Asserções

Para testar nosso código, o JUnit fornece os métodos de assert. O conceito é muito simples, todo método de asserção recebe um valor que é o correto esperado pelo teste, e o outro valor que é o devolvido pelo seu código. A comparação é executada, e o teste falha caso sejam diferentes e passa caso sejam iguais. Apenas com esse conceito é possível testar todo o código, basta saber quais são os valores que devem ser testados para garantir o funcionamento do código.
A chave para escrever um teste unitário que cobre muito bem o seu código, é colocar as asserções nos valores realmente relevantes ao funcionamento do sistema. Algumas vezes por exemplo, não é preciso testar um valor intermediário gerado pelo código, apenas o resultado final, outras vezes esse valor intermediário gerado é crucial para o resultado final, e portanto deve ser verificado também.
Quando eu menciono ‘valores’, entenda que um valor pode ser qualquer objeto Java, portanto é muito importante implementar o equals e hashcode de seus objetos de resposta que serão testados pelo JUnit.

Exemplo Prático

Vamos criar um exemplo de classe de testes com o JUnit 4 para vermos como funciona na prática a execução de testes unitários.
Se você utiliza o Eclipse, você já possui instalado o plugin de execução de testes do JUnit, caso você não tenha tal plugin, recomendo que instale posi facilita muito a execução e depuração dos testes.
Vamos criar uma classe de testes:

Repare que apesar do nome parecer que segue algum padrão, não é necessário que a classe tenha nenhuma dessas palavras em seu nome. Porém esta classe ainda não é uma classe de testes do JUnit. Para torná-la um teste, crie um método da seguinte forma:

Repare na anotação org.junit.Test. Essa anotação diz que nosso método ‘metodoQualquer’ é um teste do JUnit. Perceba também que seu retorno é ‘void’ e ele não recebe nenhum argumento. Agora nossa classe é um teste propriamente dito. Simples assim. Vamos adicionar uma asserção agora para ver o funcionamento da mesma. Dentro do método que acabamos de criar, adicione a seguinte chamada:

Repare que o primeiro argumento do método, é a mensagem que vai aparecer caso o método falhe. Mude o valor obtido (último argumento) para ver a mensagem de erro.
Esse é o básico de execução de testes. Por mais simples que possa parecer, esse é o ponto de partida. Agora existem outras funcionalidades qua ajudam a escrever testes mais complexos, por exemplo, se precisarmos criar um objeto mais complexo para nossos testes, fazemos o seguinte, adicione o seguinte código em nossa classe de testes:

Rode o teste e veja o que aparece no console.
Repare que a String é inicializada e setada novamente pra ‘null’ 3 vezes. Isso porque nossa classe possui 3 métodos de testes, e os métodosanotados com @Before rodam sempre antes de todos os métodos de teste. O mesmo vale para os métodos anotados com @After, só que estes rodam depois de executar os métodos de teste.
Só com essas duas anotações é possível criar cenários que estão sempre ‘zerados’ e corretamente incializados para cada teste que será executado em sua classe. Perceba que com isso é possível separa melhor as asserções em suas classes em mais métodos, deixando mais específico e focado cada método de teste.
Porém algumas vezes queremos inicializar algum objeto para o teste todo, sem precisar de algo específico para cada execução. Nesse caso existem duas outras anotações que podem ser úteis. Adicione o seguinte trecho em nossa classe de testes:

Só existe um restrição com essa abordagem, e acho que está claro no código qual que é: o escopo dessas chamadas é estático. Repare que os métodos precisam ser estáticos, e portanto as incializações só servirão para propriedades que são estáticas em sua classe de testes.
Essa funcionalidade possui esse comportamento porque o JUnit instancia um novo objeto da sua classe de testes para cada método que será rodado, dessa forma ele garante um melhor isolamento dos testes, tornando-os mais unitários por assim dizer. Dessa forma somente métodos estáticos são garantia de execução antes de todos os outros métodos.
Rode o teste e veja a ordem das mensagens em seu console.

Próximos passos

Essa foi uma introdução muito simples do JUnit e testes unitários. Acho que já passou pela sua cabeça muitas formas de inicializar, integrar e rodar testes em sua aplicação usando JUnit, o que é ótimo, mas ainda existem boas práticas para criar testes assim como existem boas práticas para escrever código, afinal testes são linhas de código também.
O segredo de um bom teste unitário é o quanto ele consegue cobrir do funcionamento do código, sem que seja necessário escrever um teste extremamente detalhado que deixe o código acoplado demais, e não permita muita mudança no código original. Se você investir tempo demais testando TODOS os valores possíveis de suas classes de maneira extremamente detalhada, quando o cliente pedir que um requisito mude, você com certeza vai ter a sensação de trabalho jogado fora, e desânimo por ter que escrever tudo novamente. A idéia é utilizar padrões de design para testes unitários, de forma que se mantenha a cobertura de código no 85%+ e ainda deixe os testes bem flexíveis a mudança. Difícil mas não impossível, e sim, é muito mais difícil e trabalhosos escrever testes realmente bons, do que escrever o código que será testado.

Por @Gust4v0_H4xx0r