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

2012 será mais um ano de ascensão dos dispositivos mobile em todo o mundo. Mesmo que aqui no Brasil tudo seja mais lento, com preços mais altos, estamos seguindo em frente. Já temos frameworks javascript adaptados ? s telinhas, como o Sencha, ? e o jQueryMobile, além do Flex Mobile, claro. Outras tecnologias estão crescendo a cada dia, e a quantidade de informação que é “jogada” para nós programadores aumenta em um ritmo alucinante. Seguindo esta tendência, estamos também nos adaptando, e para que tudo fique bem claro ao leitor, decidi comentar as principais mudanças do site neste post.

Neste novo ano estaremos adotando algumas mudanças que visam melhorar a qualidade de nossas obras. As principais mudanças que estão por vir são:

1)? Fim do suporte por email: Nestes quatro anos de suporte por email, pude observar diversos prós e contras, e sempre tentei agradar a “gregos e troianos”. Nunca fiz nenhuma distinção de quem comprou ou quem não comprou meus livros, sempre respondendo as dúvidas em menos de 48 horas. Todo esse tempo foi um aprendizado enorme, e agora tenho a necessidade de “lapidar” este processo de suporte. Observei que muito das dúvidas dos leitores eram repetidas e que sempre respondia ? s mesmas questões. Observei também que, ? s vezes, dava prioridade a alguém que não tinha comprado um livro, e deixava “na fila” uma outra pessoa que tinha dúvidas relativas aos livros. Também cheguei ao ponto de responder 10, 15 e-mails por dia, tornando uma tarefa bastante trabalhosa. Neste contexto, estarei “movendo” o suporte para um fórum especial, aberto a qualquer pessoa e destinado a sanar dúvidas dos livros. Falarei mais deste fórum em um outro post, mas deixo claro que, para quem é leitor, terá como sempre o suporte 100% garantido.

2)? eBOOKs serão predominantes: Todo o processo de criação/distribuição de um ebook é perfeito aos olhos do autor se não fosse a pirataria. Realmente encontrar meus livros que consumiram várias horas de preparo e trabalho nos torrents por aí não é uma sensação boa. Mas eu quero acreditar que isso é possível! Eu quero acreditar que o brasileiro é gente honesta, que deseja pagar por um conteúdo útil sem ser “assaltado”. Por isso, em 2012, eu vou priorizar o desenvolvimento de eBooks, cobrando um preço justo, e com a meta de criar muito mais ebooks do que já foi criado atualmente.

3)? Flex não será prioridade: Nestes últimos quatro anos tenho me dedicado muito ao Flex. Fui o primeiro a escrever um livro sobre Adobe Flex no Brasil e desde então foram quase 10 livros abordando o tema. Sei que está chegando o momento em que eu terei que “dissipar” o meu conhecimento para outras áreas, pois o tema Flex já está bastante difundido, felizmente hoje em dia existe bastante conteúdo dedicado a cultura Flex e só não aprende quem não quer. Veja que, para quem escreve livros, as tecnologias saturam, mas não morrem. Este é o caso do Flex, o conteúdo está saturado, eu não tenho muito mais a escrever, por isso o foco será distribuído para outras áreas. O livro “Adobe Air em Ação” será o último livro a ser escrito para a tecnologia Flex, e não haverá mais edições previstas. O suporte continuará normalmente para quem comprou qualquer livro sobre Flex.

4)? Mobile será prioridade: Daremos certa prioridade ao desenvolvimento mobile, e dependendo de novas tecnologias que deverão surgir, estaremos pesquisando e publicando material sobre elas. Isso significa que determinados livros poderão conter menos páginas, por exemplo, 100, mas que expliquem um conceito ou tecnologia emergente.

5)? Tendências serão prioridade:? A rapidez com que uma tecnologia emerge abre uma lacuna de desinformação para nós tupiniquins. E a? idéia? é preencher esta lacuna com um livro. Por exemplo, ainda não temos um livro sobre SENSHA, muito menos EXTJS. Um livro sobre HTML 5, custa nada mais, nada menos que 73 reais. Nem temos um livro sobre a linguagem SCALA ou sobre DJANGO. Enfim, existe muito assunto para se escrever.

6)? Site flex.etc.br deixa de conter informações sobre os livros:? Todas as informações estarão no site danielschmitz.com.br. O blog flex continua, mas aos poucos deixará de ser atualizado.

Resumindo:

- Vamos publicar ebooks com qualidade e a preços atraentes, sobre diversos temas. Contamos com a aprovação de vocês, enviando críticas e sugestões, .

- Haverá um fórum dedicado ao suporte dos livros.

- Estaremos em breve publicando quais serão os primeiros eBooks a serem lançados e contamos com a sua opinião. Mande ideias !

Twitter!

JodaTime

Não existe segredo quando se fala da implementação de datas no Java: é ruim de usar. Alguns chegam a dizer que é errado usar inclusive, mas não serei tão extremo.
A API de datas do Java é ruim por vários motivos, como por exemplo, é mal documentada, não é Thread Safe, é difícil de manipular datas, e o comportamento nem sempre é o esperado.
Vamos ver como susbtituir a API de datas que vem Out of the Box no Java, por uma mais efetiva, amigável e confiável: JodaTime.

Lembrando do Calendar

Todo programador Java conhece o Calendar, e sabe que para usá-lo, basta seguir o Design Pattern singleton, ou seja, basta chamar o método de classe em Calendar que devolve a instância única do sistema para o Calendar.


Problema: não funciona.


Não funciona porque se a instância é singleton, e não utiliza threadlocking no código, então não é uma instância ThreadSafe. Logo toda vez que chamamos o getInstance() do Calendar, obtemos uma nova instância. Para ilustrar, crie um teste em JUnit 4 com o seguinte código:

Rode o teste e veja a barra do JUnit ficar vermelha. O comparador ‘==’ usado em objetos, compara pelo endereço de memória, o que deveria ser o mesmo se fosse seguido o padrão singleton de verdade.
Pra piorar, todos os métodos que alteram as intâncias do Date estão expostos (por mais que estejam depreciados) para mantêr compatibilidade com versões anteriores da VM. Portanto o Date também não é ThreadSafe, pois não existe controle de concorrência em sua implementação.
Agora vamos deixar o Date e o Calendar de lado, e vamos ao JodaTime.

DateTime

O JodaTime diferencia muito bem os conceitos de data, instante de tempo, período, etc. A classe mais básica (interface no caso) é a ReadableInstant. Não precisa dizer que todas as modelagens de data implementam essa interface, permitindo comparar todos os tipos de modelagem de tempo pontuais. Um período não descreve um único instante ou ponto no tempo, por exemplo.
DateTime é talvez o ReadableInstant mais conhecido, e funciona muito parecido com o Date do Java.
Fatores que tornam o DateTime mais amigável são: é ThreadSafe pois é imutável, é muito bem documentado, e é muto fácil realizar operações com data. Vamos escrever um pouco de código para entender o que se passa.
Comece criando um DateTime. Como no Java, este DateTime criado possui o instante atual do sistema. Em seguida para efeito de teste (o teste pode falhar dependendo de quando for executado), adicione um dia na data criada, e verifique que o novo date aponta para amanhã:

Repare que tive que reassociar o date para que ele pudesse ser alterado, afinal DateTime é imutável, o mesmo comportamento que o BinInteger possui. Repare também que pra adicionar um dia, basta chamar plusDays. Este método já se encarrega de fazer toda a lógica de adicionar um dia na data, como por exemplo mudar o mês ou ano se for preciso, por isso se esse teste for rodado no dia 31 de dezembro, ele irá falhar pois o DateTime irá adicionar mais um dia a data, e perceberá que se trata do ano seguinte, e portanto getDayOfYear irá devolver ’1′, e não ’366′ ou ’365′ como esperado.
O JodaTime também trata anos bissestos e horário de verão se for selecionado o fuzo correto.
Existe uma API bem completa em DateTime para manipular todos os campos possíveis da data, sendo assim fica muito mais fácil iterar ao longo dos dias, sem precisar delegar pro Calendar a tarefa, e depois recuperar o resultado.
Não vou abordar muito da API do JodaTime, pois está muito bem documentada e existem muitos exemplos nas internet. O objetivo desse post é tratar do assunto do próximo tópico.

JodaTime e Hibernate

Pior que manipular datas, é persistir datas. Cada banco persiste data do seu próprio jeito, e cada implementação de ORM trata o Date do seu próprio jeito. Mas se você está utilizando o Hibernate, o JodaTime tem uma solução de padronização pra você: JodaTime Hibernate.
Com o JodaTime Hibernate é possível mapear diversos tipos de representação de data em suas classes Java, com ou sem TimeZone, como String ou bigint, como período ou duração, etc.
Para se ter uma idéia do que é possível, basta verificar a documentação online.
E para utiliza é muito fácil. Imagine que você tenha uma entidade com um campo DateTime, que se chama entryDate, portanto temos o getter:

Para tornar este DateTime uma data que é padrão do banco que será utilizado, por exemplo, basta adicionar a seguinte anotação:

Estamos falando para o hibernate utilzar o tipo de coluna descrito pelo PersistentDateTime, e utilizar o mesmo para converter a data novamente para DateTime quando for recuperado.
Caso você esteja fazendo engenharia reversa de algum banco, recomendo ler a descrição de todos os tipo disponíveis pra fazer a melhor escolha.
Com isso conseguimos obter todos os benefícios do JodaTime em nossas entidades, facilitando controlar as datas no domínio de nossas aplicações.


Espero ter despertado sua curiosidade com o JodaTime. Na minha opinião é uma das melhores bibliotecas Java disponíveis, mas não quero falar muito sobre suas funcionalidades, pois um dos pontos mais fortes da biblioteca é a facilidade de se acostumar com ela, e principalmente utilizar todos seus recursos. Quero que vocês tenham um pouco desse gostinho .

Por @Gust4v0_H4xx0r

Twitter!

Como todos devem ter percebido, nos últimos meses o CSS3 e o HTML5 tem ganho um grande destaque no desenvolvimento web. Grandes empresas como o Google, Microsoft, Adobe e Apple estão apoiando fortemente o desenvolvimento web utilizando WebStandards. Caso você já conheça algo sobre CSS, provavelmente deve saber como é complicado a organização desses documentos em um projeto de médio ou grande porte. Dado esses problemas conhecidos, foram surgindo os chamados pré-processadores de CSS, que viabilizam a criação de documentos de estilo, adicionando novas funcionalidades.

Hoje vamos conhecer o LESS, The Dynamic Stylesheet Language. O objetivo dessa biblioteca em javascript é prover uma série de funcionalidades para as, usualmente criadas a mão, folhas de estilos. Recursos tais como, variáveis, mixins (Multiple Inheritance, Traits), mixins parametrizáveis, funções, namespaces, importação, etc. Vamos aprender como utilizar os principais recursos dessa biblioteca em um projeto e como aproveitar o melhor dessa biblioteca para organizar corretamente nossas folhas de estilo.

Variables

As variáveis ajudam-nos a definir valores que podem ser utilizados em diversas regras do nosso CSS. Elas possuem escopo assim como em uma linguagem de programação orientada a objetos, trocando em miúdos:

O que é interessante no uso de variáveis é a reutilização e organização. Imagine uma design guideline onde existem RGBs específicos a serem seguidos, essas cores poderiam ser definidas em um documento chamado color_variables.less e adicionados ao nosso arquivo principal utilizando a clausula @import.

@Import – Importando outros arquivos

Quando um arquivo LESS é importado, todas as suas variáveis e mixins são adicionados ao arquivo principal. Os escopos serão mantidos e a extensão .less é opcional.

@import “lib.less”
@import “lib”

É possível utilizar pastas nas clausulas de @import:

@import “where/is/my/stylesheet.less”
@import “where/is/my/stylesheet”

Mixins

No LESS, mixis são como uma espécie de classe CSS que pode ser reutilizada em diversas outras regras. Quando utilizadas, todas as propriedades definidas no mixin são adicionadas a regra onde a mesma foi adicionada, caso um mixin mude, todas as regras que o referenciam serão também modificadas.

Imagine o conceito de mixin como classes CSS orientadas a objeto, o que é interessante do mixin é que temos aqui algo como uma herança múltipla, caso uma mesma instrução seja declarada em mixins diferentes, e esses mixins adicionados a uma regra, o mixin declarado por último terá vantagem na construção final do CSS da regra onde foi adicionado.

Quando modificarmos o mixin .bordered, todos os elementos que o estão utilizando serão modificados. Reutilização!
Vamos para um exemplo mais usável para exemplificar como é um mixin parametrizável.

É importante destacar que um mixin pode conter diversos parâmetros. Isso pode ser feito da seguinte forma:

Nested Rules

Com o LESS você pode criar suas regras de CSS utilizando uma espécie de hierarquia. Vamos ver como isso funciona na prática.

Com o LESS, o mesmo CSS acima poderia ser escrito da seguinte forma:

Depois de processado, o CSS será exatamente igual. Você não precisa utilizar esse esquema de hierarquia caso não queira, é importante lembrar que o LESS é apenas uma extensão do CSS, se for de desejo do desenvolvedor, podemos escrever um código LESS sem usar nenhum recurso especial, como se fosse um CSS tradicional.

Operations

Com o LESS o seu CSS sabe fazer contas. Qualquer número, cor ou variável pode ser utilizada em uma operação aritmética.
Ele sabe identificar quando estamos utilizando uma cor ou um número, por exemplo:

Assim como no javascript, é possível também utilizar parênteses nas suas operações:

Color Functions

Na minha opinião um dos recursos mais úteis durante o desenvolvimento de uma aplicação. Podemos efetuar operações em cima de RGBs, por exemplo, imagine que o layout do seu website foi criado baseado-se em apenas uma cor, utilizando diversos tons dessa cor. Com o LESS é possível utilizar métodos pré-definidos como lighten, saturate, darken, fadein, fadeout e spin. Esses métodos retornam sempre um RGB que pode ser utilizado em seu LESS. Vejamos alguns exemplos:

É possível também extrair informações de uma determinada cor para ser utilizada em outra.
Isso é feito a partir dos métodos hue, saturation e lightness.

Namespaces

Em dado momento necessitamos organizar uma série de mixins e variáveis. Para isto podemos utilizar um conceito presente no LESS chamado Namespaces. Assim como em linguagens de programação orientadas a objetos, que possuem o conceito de pacotes, os namespaces fornecem encapsulação para nossas folhas de estilo. Isso pode ser implementado facilmente utilizando a mesma notação de ID do CSS tradicional. Vejamos.

Verifique que acima, criamos um mixin chamado button dentro do namespace bundle. Para o utilizarmos devemos fazer da seguinte forma:

Uma utilização muito comum dos namespaces é na criação de pequenas bibliotecas de utilidades. Imagine que sua empresa pode possuir uma série de arquivos LESS, e em um determinado projeto você necessita de acesso a esses mixins, variáveis, etc. Organizar seus documentos com namespaces fácilita a visualização e localização de uma determinada instrução no seu documento LESS, como por exemplo, um mixin customizado que pode ser facilmente encontrado a partir da sua indicação de namespace.

Conclusão

Como podemos ver, o LESS facilita uma série de tarefas que são praticamente impossíveis de serem efetuadas pelo CSS tradicional.
Aconselho a todos que tenham interesse em se aprofundar mais na biblioteca a conhecer o website (http://lesscss.org/). Lá você poderá encontrar a documentação com maior riqueza de informações também poderá ver alguns exemplos de código que não foram abordados nesse post.

Qualquer dúvida, sinta-se a vontade e envie-nos um comentário!
Abraço!

Twitter!

Antes de mais nada, meu enorme agradecimento a diretoria da DClick, Rafael Martinelli, Rogério Martinelli, e Eduardo Melendez, os quais estavam comigo nesse evento da MAX de 2011.

Como alguns aqui já sabem, fui para a MAX porque ganhei a primeira Season do Agon, nossa rede social interna na DClick.

E claro, estou aqui para trazer as minhas primeiras impressões sobre o evento.
Começo dizendo que de infraestrutura não deixa nada a desejar, é um evento de grande porte, muito bacana, e com uma produção de dar inveja. A abertura do evento possui toda a pirotecnia possível, mas vamos deixar essa parte de lado (que você pode conferir facilmente no youtube) para comentar sobre o conteúdo do evento, que é o mais importante.

Sempre reforço que Design é uma matéria que pertence a UX, e não o inverso, tal como outras demais matérias fazem parte do resultado final que é a Experiência do Usuário, e reforçando o que Rafael Martinelli comentou no seu post, a tecnologia é o meio, e ? no Design não é diferente… ? você pode desenvolver uma User Interface com qualquer ferramenta, e para qualquer estrutura, ou seja, qualquer linguagem, Flex, HMTL5, Android, iOS, etc etc… e claro, a ferramenta gráfica mais poderosa do mercado continua sendo o imbatível Photoshop, na minha humilde opinião… Eu sinceramente estava bastante curioso para ver o que a MAX iria trazer nesse sentido, na área de Interfaces, portanto me escrevi nas diversas Sessions de Photoshop, também na de ROX (Return of Experience, ROI pensando no Usuário) e claro, em uma palestra de Flash Catalyst….

Vou começar falando minha impressão sobre as palestras sobre Photoshop, o que vi foi que não se falou muito, ou quase nada de User Interface, e sim foi mostrado técnicas para fotógrafos e outros designers que visam o tratamento de imagem, ou ainda, a produção de imagens detalhadas com 3D e outros efeitos. Confesso que como AppDesigner que sou, me senti meio orfão, mas não é de se admirar, não há profissionais muito empenhados nesse segmento, nem mesmo lá fora, certamente a Adobe fez uma pesquisa do que seria mais atrativo aos participantes da MAX, e acertou em cheio nas palestras voltadas a tratamento de imagens, pois acaba agradando a todos, mesmo AppDesigners como eu se interessam também pelo assunto, pois também utilizamos tais recursos.

Sobre UI não vi nada de novo, nada que eu já não conheça, mas sobre tratamento de imagens, não exatamente no Photoshop, mas por exemplo no Camera Raw e Adobe Bridge, vi recursos que podem ajudar-nos no dia a dia a sermos mais produtivos, sim, muito mais produtivos.. ? e vou abordar as técnicas que vi em posts futuros. Resta dizer ainda, meio que reforçando os comentários do Rafael, que me surpreendi um tempo e vi um pouco de descaso ao Flash, ao Flex nem se fala, praticamente só ouvi falar do mesmo na Session de Catalyst, mas sobre o Flash, depois seu logo apareceu estampado no telão da general session… ? mas o foco era outro, percebi o que não é novidade para ninguém o quanto a plataforma está voltada para games. E claro, o quanto os games estão voltados para o social.

Mas se teve algo que foi comentado em grande escala em todos os eventos, quer seja a general session ou os eventos segmentados, foi sem dúvida o tão badalado nome do momento: HTML5. Acho que você tanto quanto eu sabe as implicações dessa tecnologia, do que ela depende, etc… mas não cabe aqui discutir isso, e sim que o mercado está aceitando o nome, como uma grife, como algo que as pessoas querem estampar. Eu me lembro do termo Web2.0, baladíssimo, as pessoas citam os termos mas não sabem do que se trata realmente.

Agora chega de blá blá blá e vamos a um resumo da situação.

Photoshop:

A MAX trouxe profissionais que falaram de muitas novidades, não dentro do software, mas extensões, aquele tipo de ferramenta que te ajuda no dia a dia. Se teve algo de novo para mim no Photoshop foi sobre uma palestra de compactação de arquivo JPG, confesso que ouvi coisas que me surpreenderam, e é de uma utilidade absurda. Futuro Post

UX:

Nada de novo, mas o óbvio, que avaliar as possibilidades do estudo centrado no usuário pode trazer um retorno muito maior ao investimento feito nos projetos. Não é novo, mas a maioria das empresas não aplica essa estratégia… ? UX também é um termo que está já meio que saturado, todo mundo fala, ninguém sabe o que é, mas é bonito de se citar… ? Não é bem assim que deveria ser, mas ao que parece, a Adobe também está fazendo o seu papel em educar os seus profissionais e evangelistas sobre esse termo, o que é, e o quanto é importante nos projetos. Logo, foi positivo ver esse posicionamento da empresa sobre o assunto. ROX, Futuro post

Design:

A MAX não é o que podemos dizer de um evento propriamente voltado a esse segmento, para isso existe um evento só sobre Photoshop, onde além de se tratar do software em si, se fala sobre os diversos aspectos do Design. Mas resta dizer que estava impecável o tratamento e cuidado com a matéria, quer seja nos games que vi, aplicações, ou citações nas palestras.

Novidade:

A Adobe trouxe alguns tipos de apps para mobile (Tablet mesmo), que pasmem (até parece.. rs) são para Androids primeiramente, e em breve vão sair para iOS.
Você pode encontrá-las aqui: http://www.adobe.com/products/touchapps.html

Aos poucos estarei trazendo as novidades referente aos temas que abordei em posts ou screencasts. Acompanhem o Blog!!!

Por muito tempo o teste de software foi visto como uma atividade do processo de desenvolvimento de software que no papel era extremamente importante e necess?ria para atingir a qualidade do produto de software, mas na pr?tica, por muitas empresas, tornou-se uma das atividades mais negligenciada. Por esse motivo enraizou-se uma p?ssima cultura em rela??o ? atividades de testes, que, quanto a import?ncia, ficou ? margem da constru??es do software e que, se desse tempo, era executada. A neglig?ncia, por muito tempo da referida atividade gerou algumas “afirma??es” que hoje soam como piadas:

• “…Implemente, se der tempo agente testa.”
  
• “o importante ? entregar… os testes, deixa que o cliente faz pra gente…”
  
• “o prazo vai estourar…Ent?o sacrifique os testes…”
  
• “entregue com bugs, mas entregue em dia, depois agente arruma…”
  
• “sabemos que nosso software est? cheio de bugs, ent?o vamos cobrar uma manuten??o mensal do nosso cliente para consert?-los…”
  
• “testar n?o ? uma atividade importante…”
  
• ”…como vamos testar se n?o temos tempo?”
  
• “…testar pra que? perda de tempo.”
  
• “pra desenvolver sem teste ? X, com teste ? X²…'“

Fico impressionado! D? at? medo! Imagine se a ind?stria de avia??o fosse igual a de software. Quantos avi?es cairiam por dia? Imagine se a ind?stria farmac?utica fosse igual a de software. Voc? confiaria nos rem?dios? Imagine se o projeto do modelo do seu carro fosse constru?do como esses softwares? Voc? andaria em um elevador que foi constru?do com essa mesma metodologia? “Instale o elevador a?… depois o cliente testa pra gente…”

Quando fala de teste, estou me referindo tamb?m a qualidade do software. Apesar de n?o serem sin?nimos, mas com certeza o n?vel de qualidade dos teste de software ? um fator, entre v?rios outros que definem a qualidade do produto final.

Por outro lado, do ponto de vista do profissional, o teste de software possuia alguns PRE-conceitos:

• “testar ? uma atividade chata e cansativa…”
• “testar paga mal…”
  
• “n?o gosto e n?o sei programar… logo vou trabalhar na ?rea de teste…”
  
• “minha empresa n?o valoriza a ?rea de testes…”
  
• “testar ? ficar encontrando erros dos outros…”
  
• “maus programadores viram testadores…”
• “…subatividade?”
  
• “qualquer um pode testar…”
  

Hoje, no entanto, o teste “virou o jogo” com a populariza??o de processos emergentes de desenvolvimento de software como eXtreme Programming. Pr?ticas como TDD e BDD fornecem uma novo paradigma no desenvolvimento. Hoje, com a ascens?o do teste de software, novas “afirma??es” foram geradas:

• “a qualidade do produto ? inegoci?vel…”
• “primeiro escrevemos nossos testes unit?rios, depois implementamos…”
  
• “entregar software sem um boa cobertura de teste unit?rio tornou-se amadorismo…”
  
• “aus?ncia de teste unit?rio ? anti?tico… “
  
• “n?o consegue executar teste de carga, performance e seguran?a no seu sistema? Sua equipe est? com d?bito t?cnico…”
  
• “nossa integra??o ? cont?nua e automatizada…”
  
• “nossos testes s?o automatizados…”
  
• “temos cada linha de c?digo da aplica??o, temos tr?s linhas de teste…”
  
• “nos preocupamos com a cobertura dos testes, com casos de teste que refletem os requisitos de neg?cio…”
  
• “enquanto os testes n?o passarem 100% o produto n?o ? entregue…”
  
• “entregue menos, mas entregue funcionando…”
  
• “quem quebrar o deploy paga dez flex?es…”
  

Olá.

A alguns dias escrevi um post sobre PHP + MongoDB e recebi um feedback muito positivo
então resolvi repetir a dose e mostrar um pouco da integração entre Java e MongoDB.

Na minha opinião essa é uma das principais vantagens do MongoDB em relação a outros bancos de dados NoSQL,
O MongoDB e extremamente fácil de se integrar com a maioria das linguagens.

Neste Post vou falar um pouco sobre o MongoDB e a integração com o java utilizando o Spring Data.
O MongoDB fornece o mongo-java-driver que atualmente esta na versão 2.6.X é uma API completa para acessar o MongoDB.
O Spring Data é um projeto recente, lançado em 2010, ele oferecer suporte a novas tecnologias não relacionais, suporte a extensões específicas a bancos de dados relacionais. Spring Data trabalha como uma camada intermediária entre seus POJOs e o MongoDB.

Nesse exemplo estou usando o maven para gerencias as dependências do projeto
Então alem das dependências habituais do projeto: Spring, JUnit e etc.. vamos precisar adiciona ao pow.xml as dependências do MongoDB e Spring Data

pow.xml

Feito isso as dependências do projeto estão configuradas e podemos partir para a configuração do spring.
A configuração é bem simples, nesse exemplo existem apenas 2 beans que configuram o MongoDB e Spring Data mongoTemplate e mongo

applicationContext.xml

O Spring Data oferece uma serie de anotações que permitem mapear o POJO de forma bem similar ao Hibernate/JPA
Contact.java

@Document(collection="contacts")
public class Contact 
    @Id
    private ObjectId id;
    private String name;
    private String email;

  //getter and setter methods 
  ...

E é através do mongoTemplate que vamos interagir com o MongoDB por exemplo :

@Autowired
MongoTemplate template;

// insere um novo registro		
template.insert("contacts", contact);

// insere/altera um registro
template.save("contacts", contact);

// remove um registro
template.remove(contact);

// lista todos os registros
List list = template.getCollection(collectionName, Contact.class);

Apesar do Spring Data suportar o JPA repository fiz uma implementação genérica para um repositório usando o Spring Data.

GenericRepositoryWithMongo.java – Repositório genérico

public abstract class GenericRepositoryWithMongo 

  @Autowired
  protected MongoTemplate template;
  protected Class targetClass;
  protected String collectionName;

  @SuppressWarnings("unchecked")
  public GenericRepositoryWithMongo() 
     this.targetClass = (Class) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];
  

  @PostConstruct
  public void initCollection() 
    if(this.targetClass.isAnnotationPresent(Document.class))
      Document document   = this.targetClass.getAnnotation(Document.class);
      this.collectionName = document.collection();
    
    else
      this.collectionName = this.targetClass.getSimpleName().toLowerCase();
    
  }

  public List getCollection() 
    return template.getCollection(collectionName, targetClass);
  

  public void persist(T entity) 
    template.insert(collectionName, entity);
  

  public void merge(T entity) 
    template.save(collectionName, entity);
  

  public void remove(T entity) 
    template.remove(entity);
  

  public List findAll() 
    return getCollection();
  

  public long count() 
    return getCollection().size();
  
}

E então a interface do repositório e sua implementação

ContactRepository.java – Repositório de contatos

public interface ContactRepository 

    public Contact findByEmail(String email);

    public void persist(Contact entity);

    public void merge(Contact entity);

    public void remove(Contact entity);

    public List findAll();

ContactRepositoryImpl.java – Implementação do repositório de contatos

@Service("contactRepository")
@Repository
public class ContactRepositoryImpl extends GenericRepositoryWithMongo implements ContactRepository

	public Contact findByEmail(String email) 
	   Criteria criteria	 = Criteria.where("email").is(email);
	   Query query 	         = new Query(criteria);
	   return template.findOne(query, targetClass);
	
}

Realmente me surpreendi com a facilidade da integração usando o Spring Data
é um exemplo bem simples da integração porem mais da o caminho das pedras para quem esta se aventurando no mundo NoSQL.
Espero que seja util..

Para quem tiver o interesse deixei app no git
https://github.com/FabioBatSilva/spring-mongodb

Abraço e até a próxima….

Click aqui para ver o post Original

Fabio B. Silva
http://www.flexria.com.br

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 [...]

Olá pessoal,

Depois de quase um ano afastado do blog estou voltando as suas atividades, e para recomeçar com o pé direito, resolvi dar uma cara nova ao espaço, espero que gostem deste novo theme. Meu último post foi referente ao FlexMania 2010, e volto agora postando sobre um novo evento, o Flash Camp Brasil 2011.

O Flash Camp Brasil aconteceu em Maceió durante os dias 8 e 9 de abril. Tive a oportunidade de participar de um workshop privado oferecido pela RIM sobre o Playbook na sexta-feira. O workshop durou o dia todo, e nele pudemos conhecer todo o ambiente de desenvolvimento para o PlayBook. O Workshop na parte Flex foi ministrado pelo Julian Dolce, Platform Lead na QNX Software Systems. Uma coisa que ficou muito clara durante o Workshop é que o PlayBook veio para ficar, com certeza o melhor tablet que já tive acesso.

Sobre as palestras não vou comentar uma a uma porque todas foram ótimas, mas fica a dica para quem vai assistir as gravações no youtube, na minha opinião não deixe de assistir as seguintes palestras:

• Status na Década de 10 – André Matarazzo;
• O futuro do Flash Runtime – Arno Gourdol
• Se aprofundando no Molehill, o futuro do Flash Player – Alex Karpovich
• Criando AIR Applications para TVs – Elad Elrom
• Flex em dispositivos móveis – Igor Costa
• ADHD FTW, Gargalhadas! – Grant Skinner

A organização foi perfeita, não vi nenhum problema durante o evento, algumas pessoas relataram alguma dificuldade com a tradução simultânea, mas na velocidade que os palestrantes falavam realmente era impossível uma tradução perfeita.

Também tive a oportunidade de conhecer pessoalmente o John Koch e o Leandro Reis da Adobe USA. Tivemos um bate-papo aonde eles puderam conhecer mais sobre o AUG FlexDuck, nosso trabalho junto a comunidade e nos orientar sobre nossas atividades, realmente foi excelente essa conversa.

E para finalizar, foi excepcional conhecer pessoalmente toda essa galera que faz parte da comunidade Flex no Brasil.

Parabéns Demian pelo esforço na organização!

Abaixo algumas fotos no evento

Flash Camp Brasil – Radisson Hotel

PlayBook Workshop

Stefan Horochovec, Igor Costa, Janderson, Jotaefe, Bruno Sales, Thalison, Thiago Felix, Mario Junior

Janderson, Jotaefe, Thalison, Igor Costa, Marcus Pinto, Stefan Horochovec, Mario Junior

John Koch, Stefan Horochovec, Leandro Reis

Stefan Horochovec, Arno Gourdol

Stefan Horochovec, Julian Dolce

Demian Borba, Stefan Horochovec

Sorteio

Leandro Reis, Stefan Horochovec, Fabiana GO, Jotaefe, Mauri Dengo, Leon, Lauro Santos

Um até breve a Maceió, no mais tardar, nos encontraremos em 2012 no próximo Flash Camp Brasil!

Salve pessoal!

Essa semana eu inicie a fase de contratações da equipe que vai trabalhar comigo em um projeto nos próximos meses, entre horas de pesquisa e análise de possibilidades eu me deparei com uma situação engraçada e atípica, pesquisando sobre média salarial de profissionais de agências de publicidade encontrei um estudo feito pela ABRADI (Associação Brasileira de agências digitais), esse estudo mostra o salário dos profissionais de agências digitais descriminado por áreas e níveis de conhecimento.

Para minha surpresa percebi que nesse estudo Flash Developers estão na lista dos mais bem pagos do mercado, ficando atrás apenas de profissionais de atendimento, planejamento e diretores.

Essa grata surpresa me incitou a escrever uma matéria sobre quais são as principais características e os principais conhecimentos de um Flash Developer Sênior, basicamente nessa matéria vou descrever sob o meu ponto de vista os conhecimentos que um “Flash Developer” tem que ter para alcançar o topo da agência onde trabalha ou vai trabalhar.

Fuja das brigas sobre qual tecnologia é a melhor

O Flash há muito tempo desperta amor e ódio nas pessoas, varias vezes eu me vi incluso em “brigas” sobre qual é a melhor tecnologia e qual é o lugar do Flash na escala de desenvolvimento.

Minha opinião sobre o assunto sempre foi clara, caso alguém me mostre uma tecnologia que seja tão hibrida quanto o Flash no quesito integração com outras tecnologias, ferramentas de desenvolvimento, documentação oficial útil e descomplicada, cursos, metodologia, comunidade de desenvolvimento ativa, padronização de desenvolvimento e possibilidade de desenvolvimento para várias plataformas, nesse dia eu com certeza vou parar de trabalhar com Flash/Actionscript e aprender essa incrível tecnologia que terá batido o Flash, até esse dia, eu prefiro continuar no mundo da plataforma flash. Então fica a dica, não perca seu tempo nesse tipo de discussão, deixe que cada um escolha seu caminho, acredite, isso vai ser melhor para você!

Aprenda a desenvolver usando OOP

Se você é um verdadeiro “Flash Developer” com certeza já fez alguma coisa em OOP, esse padrão de programação pode salvar a sua vida quando o tempo for curto e o projeto desafiador. Para saber mais acesse esse link

Use um Framework para facilitar o desenvolvimento

Frameworks ajudam você a manter um padrão de desenvolvimento e diminuem o tempo de tarefas simples, existem ótimos frameworks de desenvolvimento, entre eles eu destaco o Gaia Framework e o ASF-AS3(Neto Leal). Use sem moderação!

Aprenda integrar redes sociais

Não é novidade alguma que as redes sociais revolucionaram a forma como as coisas acontecem na web, então é muito importante que você saiba integrar diversos serviços ao seus sites/aplicativos em Flash, serviços como Youtube, Facebook, Twitter e Flickr tem áreas específicas para desenvolvedores de várias tecnologias e em todas elas você pode encontrar APIs para auxiliar no desenvolvimento de seus sites/aplicativos.

Aprenda uma linguagem de programação Server-Side

Não que você tenha que ser um expert nessa linguagem, mas é muito bom você ter a visão do “outro lado”, não serão poucas as vezes que vão querer que aquele “hotsitezinho” que você fez tenha uma área administrativa e grave/leia dados de um banco de dados, ou que aquele outro programador “mala” vai dizer que isso ou aquilo não é possível com flash, nesse caso eu indico duas tecnologias exatamente nessa ordem, Coldfusion e PHP. Não se esqueça de aprender a trabalhar bem com Mysql, mas atenção, você não vai se tornar o melhor programador Serve-Side do mundo então tente não perder sua “veia” de design com essas tecnologias o interessante é você ainda continuar “mandando bem” em áreas fundamentais como Motion e Design.

Todo Flash Developer TEM que saber trabalhar com Photoshop

Isso pode levantar certa polêmica, mas a grande verdade é que se você pretende ser um Flash Developer e gerenciar um projeto é fundamental que você conheça profundamente o Photoshop, que tenha uma boa noção de design, tipografia e afins e conheça muito de motion design, por mais que digam o contrário 80% do trabalho de um Flash Developer é dar vida a interfaces malucas criadas por Diretores de Arte ainda mais malucos!

Animação via código é muito melhor que Timeline

Falar isso para os desavisados pode parecer uma heresia, mas a verdade é que, seja um banner, um hotsite ou um grande site é muito melhor você fazer todas as transições e motions via código, nesse caso eu indico que você use a Greensock. Trabalhando dessa forma você terá uma facilidade maior na hora de fazer aquele ajuste fino ou implementar aquela alteração de última hora.

Tenha boas referências

A comunidade de desenvolvimento Flash é muito unida, existem vários blogs como o meu que visam o crescimento profissional das pessoas sem nada em troca, é fundamental que você tenha boas referencias, que fique ligado nas constantes novidades que circulam no mundo da plataforma flash(sabe o que é molehill?), quer saber quem são as minhas referencias? Segue o link. Outra dica, tenha uma pagina de Labs sempre atualizada ou então crie um blog para compartilhar seus conhecimentos e experiências, isso coloca você em destaque na comunidade e pode abrir portas para bons trabalhos =)

Editor de código

A IDE do flash é muito boa, na versão CS5 o pessoal da Adobe melhorou bastante o editor de código, porém, ele está longe de ser a melhor opção do mercado, eu particularmente uso o FlashDevelop para fazer isso, mas o Flash Builder 4 também é uma boa opção, escolha a sua!

Pense fora da caixa

Há muito tempo o flash player domina as estatísticas de software mais instalado do mundo, mas é importante saber que o Flash não serve apenas para desenvolver sites, hoje em dia existe uma infinidade de dispositivos que utilizam o flash player, hoje você pode criar conteúdo para Iphone, Ipad, Smartphones com Android e tablets como o Motorola Xoom. Eu acho muito importante estar sempre ligado nessas novas possibilidades e de preferência ter um (ou todos) para estudos, pense fora da caixa, quem sabe isso não vai te render uma grana extra!

Em casa de ferreiro o espeto é de pau, mas não deveria ser!

Tenha sempre um portfólio bem atualizado, eu não posso falar disso com muita autoridade, pois há três anos venho tentando ter tempo para atualizar meu site, kaekae, mas é fundamental que você tenha um portfólio online que mostre exatamente o que você é capaz de fazer, ele com certeza vai ser decisivo na hora da contratação para uma empresa ou freela.

Curso, congressos, atualize-se!

É importante que você faça pelo menos uma vez ao ano uma reciclagem de seus conhecimentos, eu particularmente guardo 5% do que ganho ao ano para fazer isso, esse ano vou estar no FlashCampBrasil, uma dica que deixo são os cursos do Luciano Augusto o cara manda super bem em cursos a distância.

Saiba cobrar por seus projetos e não vacile nos prazos.

O maior erros do Flash Developer está na hora de passar o orçamento, acredite, nós estamos no topo da cadeia alimentar dos desenvolvedores, quando aparecer aquele freela não fique com medo de cobrar o valor real, você é um Flash Developer e sua hora é uma das mais caras do mercado.
Outra coisa importante são os prazos, saiba quanto tempo você leva para fazer determinadas atividades comuns a um Flash Developer, não cumprir prazos está fora de questão e lembre-se sempre existe alguém que conhece outro alguém e uma vez queimado no mercado você estará fadado ao limbo!

Não existe limite para a criatividade dentro do flash, não desanime o caminho é longo mais as recompensas em R$ são grandes depois de um tempo!

Deixe um comentário sobre esse artigo e não se faça de difícil se precisar de ajuda!
Um abraço

Meu perfil no Facebook
Meu Twitter