Olá, pessoal!
O post de hoje é uma dica pra quem busca uma solução open-source alternativa ao Google Analytics para agregar ao seu negócio. Capaz de apresentar os dados em tempo real, o software fornece relatórios detalhados sobre cada visita: motores de busca e palavras-chave utilizadas, localizações geográficas, navegadores, plugins, páginas populares, entre outros.
Para maiores informações: http://piwik.org/
Sucesso!
Abraço
Se você ainda está em dúvida se deve ou não abrir sua Loja Virtual, abaixo seguem dez ótimos motivos para convencê-lo(a) de que está no caminho certo.
Conheça CogStores: E-commerce / Lojas Virtuais aqui.
1. Funcionamento 24 horas – Com um endereço na web, a sua empresa pode montar uma loja virtual e vender a qualquer hora. O horário comercial da sua empresa passa ser 24×7 (7 dias por semana e 24 horas por dia). A loja na rede abre canal de comercialização com 50 milhões de internautas somente no Brasil. Os números do e-commerce no Brasil são impressionantes.
Conheça CogStores: E-commerce / Lojas Virtuais aqui.
Link: http://www.blogdoecommerce.com.br/porque_criar_loja_virtual/
Este post era para ter sido publicado quarta feira passada, mas não foi. Faltou acertar alguns detalhes pendentes e a partir de agora podemos compartilhá-lo.
Primeiramente, gostaria de agradecer a todos que estão participando da pré-venda! Eu tenho certeza que vocês não irão se arrepender. Nesta semana o livro será enviado para a gráfica, com retorno aproximadamente no final do mês. Está tudo certo para que o envio do livro seja realizado na data combinada, ou seja, a partir do início do mês que vem.
Vocês conhecem o suporte que eu faço após a venda de qualquer livro. Sempre me esforço para responder os emails de suporte e tento fazer isso bem rápido e, sempre que possível, conseguir resolver os problemas apresentados. Vocês que já me escreveram sabem disso.
Agora vamos a novidade principal do nosso livro. Ele será muito mais que um livro físico, também haverá uma versão e-book estendida, e um site exclusivo. Tive esta ideia a partir do momento em que decidi criar um sistema complexo, pois saberia que somente um livro impresso não “daria conta” do recado. Veja, um sistema complexo possui centenas de milhares de linhas de código, e colocar tudo isso em papel resultaria em um livro de 500 páginas, onde a metade é código. E um livro de 500 páginas iria sair muito caro tanto para mim quanto para você. Então, para que possamos dar qualidade a nossa obra com preço justo, você receberá um livro impresso de 180 páginas, e terá acesso a um ebook contendo o sistema complexo, totalmente comentado. Além disso, haverá um site especial, acessado através de login/senha, no qual poderemos fornecer informações extras e trocar idéias.
Neste site, iremos discutir novas funcionalidades para o sistema, como forma de estarmos sempre ampliando o mesmo. A idéia é fazer isso até 31/Dez/2011. Assim como um sistema não termina, um livro sobre um sistema real teoricamente não deveria terminar também, e é isso que vamos fazer. Após completar o sistema, e deixá-lo pronto, iremos abrir uma série de discussões para estendê-lo. Funcionalidades novas como acesso ACL, relatórios, e outros assuntos, serão votados e implementados.
Resumindo, você irá comprar um livro Flex+PHP por 56 reais e terá retorno de conhecimento até o final do ano. Não existe custo/benefício melhor que este. Em um próximo post, vou comentar mais como será este acesso e este ebook complementar. Até lá!
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.
Vimos alguns tutoriais e posts que descreviam o funcionamento do maven, e tabmbém criamos alguns projetos com seus respectivos relatórios. Porém sempre utilizamos uma versão do Maven 2. Atualmente está disponível (não mais como beta) a versão 3 da ferramenta. Mas afinal, o que muda e como que sua aplicação construída utilizando Maven 2 irá se comportar com o Maven 3? Veremos!
A primeira coisa a se notar de diferente é a saída no terminal de comando gerada pelo Maven 3. Veja a saída em um projeto padrão maven criado para o exemplo:
Note que a divisão entre projetos está mais clara e que cada goal está explicitamente descrito com seus respectivos plugins, tornando mais fácil identificar possíveis problemas. Por exemplo vejamos o que forçarmos um erro no build:
Repare que ao executar o plugin maven-compiler-plugin do Maven na fase de compile ocorreu um erro que está descrito logo abaixo. Note também que agora o Maven sugere uma URL da documentação onde você pode encontar ajuda sobre a falha.
Caso mais de um erro tivesse ocorrido, seria descrito em ordem de ocorrência e se fosse possível sugerir ajuda, estariam descritas as URLs de ajuda.
Essa é a primeira mudança mais notável. Uma segunda mudança pode ser percebida também, mas é mais sutil: performance. A Apache diz que o Maven é muito mais performático que suas versões anteriores em muitos aspectos.
Eu trabalho com Maven a um bom tempo já e posso dizer por experência que sim, o Maven 3 é de fato mais rápido mas não o suficiente para impressionar e de fato afetar o dia-a-dia. Está mais rápido identificar alguns problemas que podem acontecer durante o build, isso sim eu acho que afeta mais no dia-a-dia.
Quanto aos downloads de artefatos, está melhor que nas versão anteriores, pois o download em paralelo está melhor implementado e portanto a banda é melhor gerenciado. Essa mudança também afeta no dia-a-dia de uma maneira positiva.
Outra melhoria de performance é com relação aos plugins externos. A Apache diz que a API de uso do Maven para plugins externos está muito melhorada, e que a integração está bem mais otimizada. Aqui na empresa utilizo bastante a integração com o plugin do Flex para o Maven (FlexMojos), e posso dizer que nesse ponto a mudança foi drástica. O build está de fato muito mais rápido que nas versão anteriores do maven e melhorou bastante no dia-a-dia do desenvolvimento.
A validação dos poms do projeto está mais bem estruturada e descrita pela ferramenta. Por exemplo, caso você repita uma dependência em um de seus poms, o build não será afetado, mas o Maven irá lhe alertar dos possíveis problemas:
Repare que é informada exatamente a posição do erro no pom do projeto e o que pode acontecer caso a inconsistência permaneça. Outro ponto para a versão nova da ferramenta. Muitos dos projetos que rodei o Maven 3 e estavam sobre o controle do Maven 2 apresentaram algum tipo de inconsistência que poderia interferir no controle de versões dos artefatos e até mesmo no funcionamento da aplicação.
Outra mudança na organização, é o controle do parent pom. Era comum criar projetos auxiliares aos projetos principais para guardar o pom que serviria de parent para os demais poms da aplicação. Era criado tal projeto para poder importá-lo no Eclipse como se fosse um projeto como qualquer outro. Dessa forma, o pom do projeto que agregava todos os sub-projetos servia apenas como descritor dos módulos presentes sendo que este também herdava do pom parent em um de seus sub-projetos. Temos um erro de consistência nesse caso, pois era necessário realizar o install deste sub-projeto antes de todos os outros, e no build com todos os projetos portanto, a versão do parent pom era sempre uma anterior a que está sendo instalada.
Na versão nova da ferramenta tal organização é ainda tolerada, mas é lançado um aviso de que existe tal inconsistência, e de que possivelmente as próximas versões do Maven não irão mais suportá-la. O único problema com essa organização é não poder importar o projeto no Eclipse de maneira simples, pois o projeto pai trará todos os filhos como sub-pastas do mesmo, mas é de fato melhor em termos de organização e facilita na manutenção do parent pom.
Muitas outras validações são feitas nos poms do projeto que são muito úteis para manutenção e controle das versões das bibliotecas da aplicação.
Reporting no Maven 2 possui sua própria tag no xml do pom do projeto. No Maven 3 tal tag é ignorada e portanto seus projetos devem ser refatorados para que os relatórios ainda funcionem. Isso acontece porque agora o módulo de relatórios do maven está completamente independente da ferramenta, e portanto deve ser executado por um plugin. Portanto a descrição dos relatórios deve ser feita na tag de build do pom na parte de plugins.
A configuração mudou um pouco, pois agora os tipos de relatórios são descritos como configuração do plugin de geração de relatórios do maven, por exemplo um pom compatível com a versão 3 do Maven:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 |
? ? … ? ? ? ? ? ? … ? ? ? ? ? ? ? ? ? ? … ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? ? ? > ? ? ? ? > ? ? > ? ? … > |
Nesta configuração estou gerando uma série de relatórios de cobertura e análise de código, assim como alguns de documentação também. Repare que é necessário utilizar o maven-project-info-reports-plugin, isso porque o site gerado pelo maven por padrão não gera um index.html que serve de agregador dos demais relatórios, por isso este plugin está presente na configuração.
Em conclusão o Maven 3 é mais um passo bem grande na evolução da ferramente que tem como objetivo tornar mais intuitivo o uso e menos intrusivo no dia-a-dia do desenvolvedor.
A integração com plugins externos está muito melhorada, o que acredit que possibilitará muitas outras integrações com diversas outras tecnologias em um mesmo projeto, facilitando muito o controle de versões e a manutenção dos projetos.
A parte de relatórios fiquei um pouco decepcionado com a mudança, pois a documentação ainda não deixa claro exatamente o que foi alterado e o que deixou de fazer parte da execução padrão, tive que chegar nessa configuração por tentativa e erro e buscando na internet por pessoas que passaram pelos mesmo problemas. O resultado obtido é exatamente o mesmo, exceto por um bug que não gera o site do pom parent linkando todos os seus filhos em uma mesma página. Este sim é um problema que afeta no dia-a-dia, principalmente se você executa o build de maneira contínua, gerando os relatórios para deixá-los disponíveis na empresa.
De resto acredito que o Maven ainda tem muito a oferecer, e existem outras melhorias as quais não abordei aqui no post, mas que assim que passar por elas irei postando aqui no blog.
Por @Gust4v0_H4xx0r
Fazer parsing de uma estrutura de dados como o XML é muito comum no desenvolvimento de aplicativos web, a maior parte dos sistemas desenvolvidos com o conceito de Web 2.0 implementam uma api de serviços para que o desenvolvedor possa utilizar e criar novos aplicativos, sub programas, relatórios e etc.
Estas API’s de serviços trabalham na maioria das vezes com formato de dados universais, como por ex, o JSON e XML. Portanto uma terefa comum quando estamos desenvolvendo um aplicativo “client” para estes serviços é interpretar estes dados para utilizar do modo desejado no software.
Existem diferentes modos de trabalhar com documentos XML’s e diferentes ferramentas para isso. Neste post vamos ver como isso funciona no desenvolvimento para IPhone.
Como funciona o parsing de XML?
Existem dois modos para fazer parsing de um documento XML, e muita diferença entre eles. Entender como cada modo funciona é fundamental para que esta tarefa não se torne um problema no seu projeto.
SAX ( Sequencial Access Parser )
Como o nome sugere, o parser que implementa o SAX irá fazer uma analise sequencial na estrutura do xml, o que isso quer dizer? Cada elemento do XML será analisado individualmente e em sequencia. Ele é baseado em um fluxo de eventos que são disparados para cada elemento do XML.
Exemplo
Dado o XML abaixo:
A sequência que o parser irá fazer é a seguinte:
Quando utilizar?
Este tipo de parser é recomendado quando o tamanho do documento é muito grande ( algo em torno de 10MB ) e você pretende utilizar somente uma pequena parte do XML, pois ele não carrega o conteúdo do documento em memória ( isso acontece com os parser que implementam DOM ), porém o trabalho de desenvolvimento é maior.
DOM ( Document Object Model )
O parser que implementa o XML DOM, possibilita você acesse qualquer elemento diretamente sem a restrição de seguir uma seqüência baseado na hierarquia do XML.
Normalmente os parsers que implementam o modelo DOM também permitem que você defina a consulta no xml através de XPath. Isso torna muito mais fácil a maneira de filtrar ou agrupar os elementos do XML.
Para aqueles que estão acostumados a trabalhar com o flex, a maneira como o sdk lida com XML é através da implementação DOM, e a linguagem de busca dentro do XML é o E4X, portanto a curva de aprendizagem para aprender XPath será menor.
Para que o parser possa interpretar as consultas XPath e navegar de modo trasnversal entre os elementos para encontrar o critério de busca, o XML é carregado em memoria e transformado em uma estrutura de dados que facilita este tipo de tarefa. O ponto ruim disso é que em documentos grandes esta abordagem pode ocasionar problemas.
Exemplo
Dado o xml abaixo:
E o seguinte trecho de código:
O exemplo de código abaixo utiliza a biblioteca GDataXML para manipulação DOM do XML, está biblioteca é distribuida pela Google.
O método [doc nodesForXPath:@"//item":nil] irá percorrer todos os elementos do XML procurando pelos nós do tipo
Quando utilizar?
O parser que implementa o XML DOM deve ser utilizado em documentos que não irão comprometer a memória ( algo menor que 10MB ), já que o gerenciamento de memoria no desenvolvimento de IPhone é um ponto que deve ser considerado. A manipulação de XML com DOM é muito mais fácil do que com SAX, uma vez que o acesso é direto.
Quais bibliotecas utilizar?
Existem várias bibliotecas que fazem parsing de XML, as mais conhecidas são:
Conclusão
O importante é ter em mente quais são as opções e modos de fazer o parcing do XML na sua aplicação, entender quais são as métricas que o ambiente da aplicação possui e leva-las em conta na decisão de como fazer o parsing. Estas métricas irão te encaminhar a uma das opções.
O link a seguir possui um conteudo complementar ao tema, e também apresenta uma comparação entre todas as ferramentas analisando performace e utilização de memória, vale a pena dar uma olhada: link
Referencias:
http://www.raywenderlich.com/553/how-to-chose-the-best-xml-parser-for-your-iphone-project
http://stackoverflow.com/questions/406811/iphone-development-xmlparser-vs-libxml2-vs-touchxml
http://www.saxproject.org/
http://en.wikipedia.org/wiki/Simple_API_for_XML
http://www.w3schools.com/Dom/dom_parser.asp
http://www.w3schools.com/XPath/default.asp
O livro Dominando Flex e Java está muito perto de ser lançado! Você tem interesse na sua compra?? Preencha este pequeno formulário para receber em seu email uma oferta exclusiva, no dia de lançamento da obra:
http://bit.ly/CadastroFlexJava
RelatóriosSumário completo: http://dl.dropbox.com/u/6740457/flex-java/Sumario-Livro-Dominando-Flex-Java.pdf
Vimos que o maven é uma ferramenta poderosa para gerenciar projetos e dependências em posts passados. Vamos ter uma idéia agora de como o maven nos ajuda com o cotidiano de desenvolvimento gerando relatórios para documentação, boas práticas e possíveis bugs no sistema.
Testes unitários já foram vistos com maus olhos pela comunidade de desenvolvimento de software quando surgiram, e hoje em dia é uma das práticas obrigatórias no desenvolvimento da maioria dos sistemas. Mas afinal o que fez todo mundo mudar a maneira de pensar e trabalhar? O que motiva um desenvolvedor a “perder tempo” escrevendo testes unitários?
As respostas hoje em dia são bem claras na cabeça de muitos desenvolvedores, por isso vamos passar por temas que vão além dos testes unitários e abordar como nos beneficiamos a longo prazo com uma política de testes e boas práticas bem definida.
Já que todos concordam (a grande maioria pelo menos) que testes nos beneficiam, porque não testar em todo o processo de desenvolvimento? Uma dúvida que surge assim que a equipe resolve testar suas classes: devemos estimar também o tempo que levaremos para escrever os testes? A resposta é simples, sim e não. Sim porque com certeza o tempo para executar a tarefa será diferente quando resolvemos escrever testes para nossas classes, e não porque não devemos separar a estimativa, como se escrever testes fossem uma tarefa diferente. Inclusive deveríamos considerar que uma tarefa só é concluída se existem testes unitários que garantem o funcionamento da mesma, e que tais testes estejam passando.
Podemos pensar que se para cada funcionalidade que implementamos garantimos o funcionamento da mesma, estamos seguros para implementar uma nova funcionalidade sem interferir no progresso do sistema até então. A única maneira de garantirmos que toda funcionalidade nova estará de acordo com as já existentes é testando ao longo de todo o projeto. O mesmo vale para testes de uso, feitos por uma equipe de testes, pois se pensarmos que os testes unitários nos protegem de nossos próprios erros, ainda assim não estamos protegidos de erros de sistemas externos que serão usados par integração com o nosso projeto.
O fator mais crítico em se testar sempre, é que quando nos deparamos com um determinado erro, nossa cabeça ainda está no contexto da tarefa ao qual o teste falhou, e portanto está mais claro em nossas mentes como corrigi-la, acelerando a correção de erros e o desenvolvimento de novas tarefas mais futuramente.
Os relatórios de cobertura de testes a primeira vista parecem um ferramenta de controle sobre como estamos desenvolvendo. Muito pelo contrário, porque os relatórios de cobertura apenas expoem as linhas e blocos do código que são executados durante os testes, escondendo muitos outros fatores relevantes no desenvolvimento, além do que é bem fácil “roubar” no teste para obter uma cobertura alta.
O relatório de cobertura serve como ferramenta de alerta para a equipe como um todo, para que a qualquer momento, qualquer membro da equipe possa consultar o relatório e se certificar que dado a cobertura de testes, ele pode continuar o desenvolvimento de suas tarefas ou então, notificar toda a equipe que existem partes do código não testadas e que devem receber mais atenção para garantir uma evolução contínua do sistema.
O FindBugs é uma ferramenta que nos auxilia no desenvolvimento prevendo possíveis pontos problemáticos do sistema. O FindBugs funciona com o Java mas existem versões para diversas plataformas.
No mesmo espírito do relatório de cobertura, os possíveis bugs apontados pelo FindBugs servem como alerta para a equipe para pontos do sistema que talvez mereçam mais atenção, e da mesma forma é possível “roubar” e sempre deixar o FindBugs “contente”, por isso é essencial a consciência da equipe para manter o FindBugs dentro da linha.
O relatório gerado pelo PMD é mais um guia de boas práticas que deveriam ser seguidas durante a implementação do código. O PMD é bem menos intrusivo que o FindBugs no sentido de que a análise feita por ele é mais voltada a estilo de programação, e pode ser configurada e ajustada de acordo com o projeto e a equipe. O ideal seria que conseguíssemos estabelecer uma configuração do PMD e do FindBugs para a DClick, garantindo que se mudarmos algum desenvolvedor de equipe, o desenvolvedor iria estar familiarizado com as práticas e padrões do novo projeto, afinal seriam os mesmos padrões exigidos no projeto em que o desenvolvedor estava.
Um dos principais objetivos de se empregar boas práticas de programação, é garantir uma linguagem comum entre equipes de desenvolvimento. Para facilitar tal compreensão, seria interessante que o código implementado independente da equipe, seguisse uma mesma identação e organização. Dessa forma um desenvolvedor novo no projeto consegueria “se encontrar” no código de maneira mais rápida, porque a estrutura adotada seria a mesma em todos os projetos.
Para facilitar e garantir que o padrão está sendo seguido, existe por exemplo, o plugin de ‘checkstyle’ do eclipse. O plugin nada mais faz do que colocar warnings no código, nos trechos em que o padrão de identação e organização definido não está sendo seguido. O plugin consegue ir um pouco mais longe do que meramente validar formatação de código, e consegue “cobrar” o emprego de algumas boas práticas mais básicas, como por exemplo encapsulamento e gerenciamento de variáveis.
Se escrever código de maneira padronizada, organizada e compreensível é essencial para comunicação, o mesmo se aplica para a documentação das classes.
Por isso que existem ferramentas como o javadoc, que é uma das ferramentas mais difundidas na comunidade. Isso porque garante a geração de uma documentação livre de código de maneira automática e simples. O que deveríamos ter em nossas classes, é uma documentação na qual não seja necessário ler o código para entender o funcionamento da classe. A única maneira de garantir um nível de documentação desses, é sempre manter a documentação atualizada e constantemente mudá-la conforme desenvolvemos o sistema.
No Java existe o Javadoc que é tão difundido que já vem integrado com o Eclipse IDE, e existem versões disponíveis para todas as grandes plataformas, inclusive Flex.
Apesar de citar algumas tecnologias usadas no Java, o objetivo principal do post é mostrar que o emprego de tais ferramentas nos ajuda no dia-a-dia de desenvolvimento em geral, não importando a tecnologia utilizada. A idéia é atingir um nível de qualidade geral, independente de plataforma. Se atingirmos um nível aceitável e conseguirmos seguir um padrão, conseguiremos migrar entre projetos tendo que apenas entender a regra de negócio do projeto, já estando familiarizado com as práticas de desenvolvimento.
Olá Pessoal, vou mostrar a vocês como criar relatório com o IReport. Mas antes de mais nada o que é a IReport.
IReport
IReport é uma ferramenta de designer para relatórios, que utiliza a biblioteca Java para relatórios a JasperReports. Com ele é possível fazer layots sofisticados, contendo gráficos, imagens, sub-relatórios, tabelas de referência cruzada e muito mais. Os dados podem ser acessado via JDBC, TableModels, JavaBeans, XML, Hibernate e CSV. Depois podendo fazer relatórios em PDF, RTF, XML, XLS, CSV, HTML, XHTML, textos, DOCX ou OpenOffice.
É um projeto open-source da equipe JasperForge que possui ferramentas para produção de relatórios, elaboração de relatórios operacionais etc. Mais informações estão disponíveis no www.jasperforge.org.
Ciclo de Vida do Relatório
O arquivo criado pelo IReport é um jrxml, arquivo XML que contém a definição do relatório, como o relatório é desenhado completamente de uma forma visual não é necessário saber a estrutura desse arquivo XML. Depois o jrxml deve ser compilado em um objeto binário chamado Jasper, e é o que você precisa enviar para sua aplicação para executar os relatórios.
Na execução do relatório você precisará do arquivo Jasper e uma fonte de dados para o JasperReports. Há muitos tipos de fontes de dados como: arquivo XML, consulta SQL, arquivo CSV, uma HQL (Hibernate Query Language), uma consulta com JavaBeans, etc. O JasperReports é bem flexível proporcionando a você criar sua propria fonte de dados. Com o arquivo Jasper e a fonte dados o JasperReports é capaz de gerar o documento final em vários formatos.
Atualmente se encontra na versão 3.7.5 e pode ser baixado no site:
http://jasperforge.org//website/ireportwebsite/IR%20Website/ir_download.html?header=project&target=ireport
Fonte
http://jasperforge.org/projects/ireport
Exemplo
No screencast abaixo é explificado o uso do IReport, para fonte de dados utilizei um arquivo xml.
Arquivos Fontes
http://office-sp.dclick.com.br/devblog/wp-content/uploads/2010/arquivos-fontes-relatorio.zip
http://office-sp.dclick.com.br/devblog/wp-content/uploads/2010/lib-relatorio.zip
Templantes de relatórios
http://office-sp.dclick.com.br/devblog/wp-content/uploads/2010/templates-relatorios.zip
