Criando um CustomAppender para JTextArea com Log4j

Recentemente estavámos trabalhando em um projeto de migração de dados em Java, e foi criada uma pequena interface para interagir com o usuário utilizando Swing. Em dado momento, decidimos incluir um JTextArea para mostrar ao usuário as informações emitidas pelo log do programa, no caso, utilizando Log4j, para que o mesmo pudesse acompanhar com mais detalhes o que o conversor estava fazendo no momento.

Foi então que pesquisando um pouco no google vimos que há como criar nossos próprios Appender's do Log4j, e é sobre isso que eu vou falar hoje.

Serviços da Google Maps API de Geocodificação

Olá, hoje vou mostrar um exemplo de como consumir o serviço do Google Maps API de geocodificação. A definição de geocodificação eu extraí do próprio site do google:

"Geocodificação é o processo de conversão de endereços (como "1600 Amphitheatre Parkway, Mountain View, CA") em coordenadas geográficas (como latitude 37.423021 e longitude -122.083739), que você pode usar para colocar marcadores ou posicionar o mapa. A Google Geocoding API fornece uma maneira direta de acessar um geocodificador por meio de uma solicitação HTTP. Além disso, o serviço permite que você realize a operação inversa (transformar coordenadas em endereços); esse processo é conhecido como "geocodificação reversa"."

Simplificando o merge no TortoiseSVN com DiffMerge

Muitos de vocês já devem ter se aborrecido com a ferramenta de diff(comparação entre arquivos) que vem junto com o TortoiseSVN. Ela não consegue resolver sozinha vários tipos de conflitos e a resolução manual é complicada.

Procurando uma ferramenta melhor tempos atrás, encontrei esse post do Erick Sasse onde ele recomendava a ferramenta DiffMerge que é gratuita e funciona no Windows, Mac OS X e Linux.

Integração Contínua - Instalando as ferramentas(Java JRE, TomCat e Hudson)

Já faz algum tempo desde o último post, o tempo está curto, mais dando continuidade a série sobre Integração Contínua, hoje vou mostrar como instalar e configurar as ferramentas que iremos utilizar: Java JRE, Tomcat, Hudson e VisualSVN Server.

Java
Como servidor de aplicação utilizarei o Tomcat e para isso, precisamos do Java Runtime Edition (JRE) (ou Java Development Kit(JDK) caso já tenha instalado). Você pode obter o instalador nesse link Java SE Downloads. Escolha a opção JRE. A instalação é no estilo next, next, finish.

Integração contínua - Compilar projeto delphi por linha de comando (dcc32) - Recursos Avançados

Olá pessoal. No último post falamos sobre compilar projeto delphi por linha de comando, continuando o assunto, hoje vamos ver como compilar o projeto habilitando opções mais específica de compilação para rodar o projeto em modo de depuração. Nosso projeto de teste utiliza duas bibliotecas externas: FastMM e DUnit, para que o FastMM(em FullDebugMode) consiga captar corretamente o nome das units e métodos onde ocorreram os leaks de memória, é necessário modificar algumas configurações no projeto. Outras ferramentas como o Delphi Code Coverage, utilizam o Map File do executável para analizar a cobertura de código, então também habilitamos a geração do mesmo.

A configuração do projeto nessa caso deveria ficar assim:

Integração contínua - Compilar projeto delphi por linha de comando (dcc32)

Olá pessoal, tudo bem? Nessa série de posts sobre Integração Contínua, precisamos compilar nosso projeto de forma automatizada, para conseguir rodas os testes sempre com a última versão disponível do código fonte, e é sobre isso que vou falar hoje.

A partir do delphi 2007 há integração com msbuild, o que facilita muito a nossa vida, sem falar que no Delphi XE uma das ferramentas incluídas no pacote é o Final Builder, excelente ferramente de build automatizado. Infelizmente, muita gente ainda utiliza o delphi 7 (eu sou um deles) e nesse caso o trabalho é mais braçal. Esse post tem como foco aqueles que por algum motivo ainda utilizam - principalmente - o delphi 7.

Integração contínua com Hudon, subversion e Delphi

Cada vez mais estamos buscando maneiras de melhorar a qualidade do software que produzimos, gerando um código com menos bugs e um produto final que gere valor para o cliente. Uma das melhores maneiras para se desenvolver software é praticar TDD, não só por escrever o teste primeiro, mais por contribuir significativamente para a melhoria do design do código, com classes mais coesas e com poucas responsabilidades, consequentemente, temos classes mais fáceis de testar e menos suscetíveis a falhas, e ainda por cima ganhamos uma especificação testável de brinde. :P

Estes testes tem também um papel fundamental garantindo que não haja regressão do software, ou seja, quando alguém altera o código, os testes devem continuar passando, garantindo que tudo continua funcionando adequadamente. Então antes de cada commit, precisamos fazer update no svn para atualizar nossa working copy, rodar os testes e deixar tudo verdinho e só depois integrar nossas alterações. Mais há algo errado com essa sequência de passos. É muito manual. Depende do desenvolvedor. Há muitos pontos de falha, ele pode esquecer de sincronizar seu repositório local, pode esquecer de rodar os testes, pode estar trabalhando até tarde e estar cansado demais pra rodar os teste, etc, etc. E o que devemos fazer então? Automatizar, é claro.