? Android: ORMLite Feita a introdução básica sobre como o android manipula e gerencia bancos de dados, podemos avançar para um tópico, digamos, um pouco mais avançado e que tornará nossas iterações com os bancos de dados em Android muito mais fáceis. ORMLite, ou Object Relational Mapping Lite, é um framework que (como descrito em…
Quarto vídeo da série de screencasts sobre lógica de programação com Scratch.
Este vídeo mostra como salvar e abrir um projeto, como controlar o teclado e como trabalhar com blocos de comandos condicionais.
Veja mais informações sobre a série neste outro post.
© Elvis for Elvis Fernandes, 2012. |
Permalink |
Nenhum comentário |
Adicione ao
del.icio.us
Tags: aula, Desenvolvimento, lógica, programação, scratch
Introdução Provavelmente você já sofreu muito no JSF 1.2 ou versões anteriores devido a não existência de um conversor de entidades padrão, e assim éramos obrigados a procurar soluções para contornar isso. Encontrávamos na comunidade boas soluções como implementações próprias dos famosos “Entity Converters” ou se alguns programadores tinham a liberdade de inserir bibliotecas no…
Ursula Wolff curtiu este postÉ isso aí galera, estou de volta. Depois de uma certa experiência com usabilidade mobile, tanto Android quanto iOS (em breve vou abordar também sobre Windows Phone), resolvi criar alguns posts para tratar do tema. Nessa introdução vou comentar sobre o que é a Usabilidade Mobile ? e abordar um dos primeiros…
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.
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.
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.
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:
|
1
2 3 |
public class JUnitTestCase
|
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:
|
1
2 3 4 |
@Test
public void metodoQualquer()
|
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:
|
1
|
Assert.assertEquals(“2 dividido por 2 deveria ser 1.”, 1, 2 / 2);
|
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:
|
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 |
private String stringLocal;
@Before @Test @Test @After |
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:
|
1
2 3 4 5 6 7 8 9 |
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.
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
Um desafio de todo desenvolvedor html é manter o seu site compatível com todos os browsers ( em especial o Internet Explorer ), devido as limitações e detalhes na implementação de cada um, isso é um fato inegável, e qualquer um que ja tentou um dia desenvolver alguma coisa em html sabe disso.
Em projetos pequenos podemos tomar conta disso sem a necessidade de nenhuma ferramenta extra, entretanto com o? crescimento? do projeto? a tendência ? é que estes trechos de códigos para manter a compatibilidade fiquem tão grande quanto o código do próprio site em si, tornando difícil de manter e etc.
Nesta hora é importante conhecer as ferramentas que existem para ajudar o desenvolvimento, e utiliza-las de maneira correta. Uma ferramenta importante no desenvolvimento html é o jQuery.
Para quem não sabe o que é, o jQuery é uma biblioteca javascript que facilita a manipulação do DOM ( Document Object Model ) html, ou seja, facilita a manipulação da sua página html.
Para entender melhor do que este post se trata é necessário ter um conhecimento básico da biblioteca jQuery
Muitos dos métodos get e set do jQuery podem ser extendidos para casos especiais, estas extensões são conhecidas como hooks. O namespace $.cssHooks permite extender o método .css(), permitindo criar novas propriedades de CSS.
Os hooks podem ser utilizados como uma solução elegante para a compatibilidade de CSS em diferentes browsers, por exemplo, a propriedade text-shadow do CSS3 não é suportada pelo Internet Explorer, portanto o código abaixo não funcionará no IE:
Este código aplica um glow verde em todos os elementos H3 do documento HTML, porém não funciona no IE.
Mas nós podemos criar uma nova propriedade css, e internamente tratar o caso do IE. Vamos chamar a nova propriedade de glowColor:
Este código cria uma propriedade dentro do namespace .cssHooks chamada glowColor, esta propriedade possui uma função set específica para o caso do IE e outra para o caso dos outros browsers. A lógica deste código é basicamente, verificar se possui suporte ao textShadow, caso sim,? define? uma função set que altera o atributo elem.style.textShadow com a cor do parâmetro, caso não, define uma função que altera a propriedade elem.style.filter com um filtro especifico utilizando a cor do? parâmetro.
Agora podemos aplicar o efeito através do código
O lado bom de criar um cssHook no jQuery para o problema de descrito é que o código que trata a compatibilidade fica oculto do desenvolvedor, ele não precisa se? preocupar? com isso, o foco é no código que? constrói? a pagina unicamente. Esta? estratégia pode ser aplicada para outros diversos efeitos e manipulações, criar uma serie de hooks para tratar este tipo de coisa e etc. O lado ruim no meu ponto de vista é que estamos criando propriedades novas, que são desconhecidas pelos outros desenvolvedores e etc, portanto um novo desenvolvedor iria demorar para aprender todas customizações e suas funções, uma dica é tentar manter os nomes semelhantes ao padrão.
Por @thiagoofelix
Referências
O jQuery é uma biblioteca JavaScript poderosa que está quase se tornando quase “sinônimo” do próprio JavaScript.
A apresentação de slides a seguir é de uma palestra introdutória do jQuery, que destaca praticamente todos os seus recursos e que mostra algumas modificações na versão mais recente da biblioteca (1.7).
E para quem quiser se aprofundar no assunto, o último slide aponta para um livro gratuito de jQuery: jqfundamentals.com.
(Registro aqui o agradecimento ao Erko Bridee por compartilhar esse conteúdo)
© Elvis for Elvis Fernandes, 2011. |
Permalink |
Nenhum comentário |
Adicione ao
del.icio.us
Tags: AJAX, Desenvolvimento, JavaScript, jQuery, web
Caso voc? trabalha com desenvolvimento de software, ambiente web, provavelmente tem ouvido e lido sobre esse tal de NoSQL, mas o que ?, para que serve, quando usar, voc? sabe?
Aten??o a explica??o a seguir ? a minha com rela??o ao assunto:
Antes de mais nada, o NoSQL ? um novo modelo de base de dados, diferente do modelo relacional, que, creio eu ? muito conhecido de todos os desenvolvedores de software, o NoSQL surgiu para suprir a necessidade de lidar com um volume de informa??es que podem ir muito al?m da que voc? consiga imaginar. Este ? o cen?rio de redes sociais, exemplos cl?ssicos n?s temos o Twitter, Facebook e outras redes, onde a quantidade de informa??o gerada pelos usu?rios (essas redes que possuem milh?es de usu?rios ao redor do mundo) possui um crescimento que as bases de dados relacionais n?o conseguem comportar.
O NoSQL surgiu j? pensando em crescimento da informa??o armazenada e manipulada. As solu??es de NoSQL que temos dispon?veis hoje j? vem por padr?o com todo o conjunto de suporte para poder adicionar novos servidores (nodes) e comportar um crescimento dos dados a um custo muito menor do que a das bases relacionais. Esse crescimento ? chamado de crescimento horizontal, onde basta adicionar novas m?quinas e nessas bases NoSQL adicionadas como nodes da base e tudo pronto. Enquanto nas bases relacionais o crescimento ? vertical, ou seja, ? necess?rio aumentar o poder de hardware dos servidores (e este custo ? alto), al?m do fato que a implementa??o de servidores escravos e nodes n?o s?o simples de adicionar e gerenciar, pois essas bases n?o foram projetadas para atender a esse n?vel de demanda.
Sei que n?o sou o melhor para explicar o respectivo tema, ent?o vamos ao real objetivo do tema, segue alguns materiais interessantes para estudar quanto ao tema, segue estes excelentes postcats sobre o tema que apresenta uma boa vis?o e explica??o sobre o assunto, do pessoal do Grok Podcast:
Epis?dio 45 – Repensando os bancos de dados – NoSQL – Parte 1 de 3
Epis?dio 46 – Repensando os bancos de dados – NoSQL – Parte 2 de 3
Epis?dio 47 – Repensando os bancos de dados – NoSQL – Parte 3 de 3
Links para mais informa??es do assunto:
Comunidade Brasileira de NoSQL
Listagem das bases NoSQL existentes
Escalabilidade – Introdu??o ao NoSQL 1
Olá pessoal, venho através desse post fazer um convite ? todos vocês.
Recentemente nós aqui do maranhão fundamos um adobe user group o BumbAUG (Bumba meu boi + AUG) e gostaríamos de lhe convidar a fazer parte desse grupo.
Inicialmente nós iremos tratar principalmente o desenvolvimento de aplicações mobile sejam utilizando o flex, PhoneGap ou mesmo nativamente. Poderemos também fazer algo de introdução ao Flex Framework, mas isso é projeto futuro.
Apesar de ainda estar engatinhando nós do BumbAUG realizamos no dia 18/11 o Flash Mobile Day Edição São Luís, onde tivemos palestras das mais diversas áreas.
Acessem o grupo, participem, deixem suas idéias e contribuição. Como eu já falei é um GRUPO de estudos, então se você tiver um tema para palestrar, sinta-se ? vontade. O espaço é seu.
O Rafael Laranjeiras já marcou 2 palestras muito interessantes e em breve eu irei divulgar os temas para vocês.
Acessem: http://bumbaug.groups.adobe.com e vamos levar o desenvolvimento de aplicações ? um novo patamar.
Está quase tudo preparado para o lançamento do ebook Dominando Flex Mobile no dia 29 de novembro. Como prometido, o livro será lançado no mesmo dia que o Flash Builder 4.6 for lançado, que deve ser provavelmente agora no dia 29. Se houver atrasos perante a Adobe, nós atrasamos aqui também.
O ebook conterá 165 páginas. O preço será R$ 25,00. O formato será PDF, e vou testar o formato EPUB. Todos os exemplos do livro foram testados no Galaxy Tab com Android 2.2 e Adobe Air 3.0.
O que irei abordar:
