Diego Pacheco Tech blog

Eu fico muito triste em saber que em 2010 eu não sou capaz de fazer software bom de primeira. Eu até poderia me decepcionar mais ainda por estar adimitindo que com 10 anos de TI ainda não sou capaz de fazer software bom de primeira e não sei se algum dia eu irei ser capaz, será que alguém é ? Em contra partida existe uma pressão do mercaso e das pessoas que compram software, seja o setor de compras, setor financeiro, gerente, CIO, CEO, em resumo quem comprar quer comprar as coisas como um todo . Mas qual é o mal disso? Muitas vezes esta motivação vem da velha discussão do budget fechado que as vezes é definido de forma anual outras é definido por quarter e outras só Deus sabes. Logo quem compra quer saber o preço total e esta questão de saber o preço total pode ter vários motivos, como por exemplo: Saber se esta dentro do orçamento Justificar para algum superior na organização Poder cotar com outras empresas e ter desconto Pagar como um todo, para pedir algum desconto como...

Hoje em dia, cada vez mais e difícil fazer um sistema do zero, sempre é necessário realizar integrações com outros sistemas da empresa, sistemas de fornecedores, sistemas do governo e principalmente sistemas legados. Hoje em dia ainda que pareça absurdo a maioria dos projetos não trabalham com testes unitários, concordo que nem sempre será possível trabalhar com testes unitários por que as vezes você não tem o que testar, ou a lógica esta em outra aplicação/camada/tecnologia ou o tempo para realizar versus o beneficio não se paga. Qualquer linguagem OO moderna tem bons frameworks de testes unitários, falando de Java e .NET existem vários, mas mesmo assim existem muito e muitos sistemas feitos sem testes unitários, não usar este nível de testes além da perda da regressão(Falando de unidade) existem outros problemas. O Medo de mudar o código Medo de Mudar código? Acredito que o ponto seja este mesmo. No final das contas os desenvolvedores ficam com medo, literalmente, logo ac...

No post anterior comentei sobre a importância das práticas da engenharia como refactoring e versionamento aplicados ao Banco de Dados. Neste post vou mostrar como usar o Liquibase na prática com Apache Maven 2. A utilização em conjunto com Maven 2 é muito produtiva por dois fatores, o primeiro é que você pode criar um projeto Java no eclipse e utilizar o seu plugin de SCM sendo do CVS ou Subversion para versionar o projeto. O Segundo motivo é você pode colocar este projeto no seu servidor de build continuo e tendo assim as mudanças do desenvolvimento e banco acontecendo de forma igual e no mesmo momento. A Estrutura básica do Projeto Você poderia estruturar o projeto de várias formas, no site do liquibase existem algumas boas práticas de como estruturas os conjuntos de mudanças. Vamos a estrutura do projeto que criei: src/main/resources/ changelogs src/main/resources/ database-conf src/main/resources/ sql src/main/resources/ start-script pom.xml No arquivo pom.xml que f...

Faz tempo que o banco de dados deixou de ser um mero repositório. Hoje em dia os bancos de dados tem muito mais do que um mero repositório. Muitas aplicações tem diversos pontos em banco de dados, quando a maior parte de aplicação já não esta no banco. Quando olhamos para o desenvolvimento de software nos dias de hoje podemos perceber a utilização de diversas práticas e métodos da engenharia como Integração Continua, Sandboxes, Testes, Versionamento, Refactoring e muito mais. Mas e o banco de dados? Na maioria das vezes não utiliza estas práticas. A não utilização das práticas de desenvolvimento junto ao banco de dados tem motivos, dentre eles saliente a própria questão cultural. Em muitas empresas a equipe é dividia em desenvolvimento e banco de dados, logo que mexe com Java, .NET, Delphi ou qualquer linguagem por exemplo não é do mesmo grupo das pessoas que lidam com o banco. Outro fator é o paradigma, muitas vezes as equipes responsáveis pelo banco de dados estão atreladas a um pa...

Na parte 1 desta séria de postes comentei sobre a integração de soluções para testes como o TestNG e o Mockito mostrando um domínio básico de um aplicação para efetuarmos testes. Na parte 2 mostrei na prática como criar um teste com Spring, testNG e rodar tudo através do Maven 2. Neste post vou falar mais de alguns recursos do TestNG e mostrar como utilizar o Mockito e bem como as possibilidades e cenários de uso deste tipo de soluções para testes. Continuando o assunto com testNG vou falar de alguns recursos da solução utilizando anotações. Anotações de @Before... e @After... O TestNG tem algumas anotações muito úteis. Para setup de testes e grupos de testes, isso nos possibilita montar o ambiente necessário para execução dos testes. Também possibilita a limpeza do cenário dos testes entre uma execução e outra. Confira as anotações: @BeforeClass @AfterClass @BeforeMethod @AfterMethod As anotações de Before e After significam que o método anotado vai rodar antes ou depo...

No post anterior eu comecei a falar de testes com Spring, TestNG, Mockito e Maven. Neste post vou continuar com o assunto. Agora direto ao código e com exemplo práticos, usarei isto para discutir mais sobre o tema. Vamos ao código então, vou mostrar primeiro o código do domínio e depois os serviços para por fim chegar no nosso objetivo os testes. Produto package com.blogspost.diegopacheco.testng.spring.mockito.maven.core.domain; import java.io.Serializable; /** * Pojo que representa a entidade Produto. * O produto pode ser qualquer mercadoria que eh vendida pelo estabelecimento. * Você pode adicionar mapeamento ORM aqui com anotações por exemplo, isso foi * abstraido por conta do foco do post. * * @author Diego Pacheco * @version 1.0 * @since 28/07/2009 * */ public class Produto implements Serializable { private static final long serialVersionUID = 1L; private Long id; private String nome; private String desc; public Produto(){ } public Produto(Long id, String nome, Strin...