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.

LiveBindings no delphi XE2

Hoje vamos falar sobre LiveBindings, um dos novos recursos do Delphi XE2.

LiveBindings é um mecanismo de data-binding suportados pela VCL e FireMonkey. Ele é baseado em expressões (binding expressions), o que significa que usa expressões para ligar objetos uns aos outros, por meio de suas propriedades.

É importante salientar que o LiveBinding foi criado devido a inclusão do FireMonkey, uma vez que o mesmo não possui componentes DB-Aware. Ao invés da criação desses componentes optou-se por criar um mecanismo de data-binding, e foi uma decisão muito feliz. No caso do FireMonkey os componentes podem ser ligados ao DataSource de maneira relativamente simples e de forma visual.

PodCasts

Olá pessoal. Gostaria de compartilhar com vocês os podcasts que acompanho e que ajudam muito a me manter atualizado sobre vários assuntos.

• Grok podcast é o que tem assuntos mais variados, já "grokamos" sobre Ruby, Python, Arduíno, Node-JS e mais recentemente Erlang, e outros assuntos como Sistemas de controle de versão, carreira, desenvolvimento de games, e muito mais. Visite o site para saber o que significa o termo grok.
  

Google Developer Day Brasil 2011 - Prova de Programação

Olá pessoal. Após ler o post do Erick Sasse entitulado Prova do Google Developer Day em Delphi decidi aceitar o desafio e resolver a prova (também em delphi) mesmo que eu não vá ao Google Developer Day 2011 Brasil.

A prova é bem interessante, é dado um texto em um alfabeto diferente do nosso e algumas regras para extrair do texto as quantidades de preposições e verbos, ordenar o texto e transformar as palavras em números base 20.

Strategy - Separando os comportamentos - Parte Final

No último artigo falei sobre o padrão de projeto Strategy e expus um diagrama de como utilizar o strategy para exportação de dados. Hoje vou mostrar como podemos implementar o padrão seguindo a modelagem do diagrama.

Primeiro, vamos a declaração da interface que define a API de exportação e o enumerator com os formatos de saída suportados.

type
  TExporterType = (etText, etCSV, etXML);

  IExporterStrategy = interface
  ['{AA69E6F1-389F-4DC3-AC14-7FA7A749B183}']
    function GetFileName: String;
    procedure SetFileName(const Value: String);

    property FileName: String read GetFileName write SetFileName;

    procedure ExportToFile(const Value: String);
  end;

Strategy - Separando os comportamentos - Parte 1

O padrão de projeto Strategy define uma família de algoritmos, encapsula cada um e os torna intercambiáveis, traduzindo, definimos uma interface, criamos várias implementações para essa interface, e podemos mudar o comportamento do objeto trocando a implementação utilizada. Podemos inclusive fazer isso em runtime.

Vamos observar o diagrama abaixo.

Singleton em Delphi utilzando interfaces

Olá, dando sequencia ao post anterior sobre Singleton, hoje irei mostrar uma implementação alternativa, e ao meu ver, mais elegante.

Nessa abordagem, o estado e/ou comportamento exposto pelo singleton deve ser declarado em uma interface.

type
  ISingleton = interface
  ['{F5B00272-536A-4C30-AB19-54496B106C7C}']
    procedure FacaAlgo;
  end;

Após a interface, vamos criar uma classe que seja responsável por implementá-la. O detalhe importante é que a classe fique abaixo da seção implementation, isso garante que ninguém fora dessa unit terá acesso a classe, tornado impossível criar uma nova instância da mesma.

Singleton em Delphi

O Singleton é um padrão de projeto utilizado para garantir que apenas uma única instância de determinada classe esteja disponível em todo o projeto, ou seja, ele garante que o objeto será instanciado apenas uma vez e será acessivel de forma global.

Isso é muito útil, por exemplo, quando lidamos com factory, pois a factory não precisa ser instanciada a todo momento. Outros exemplos são Pool de Conexões, Registry, Logs, ou recursos que sejam caros de instanciar a cada uso.

Usando DUnit para implementar testes unitários - Parte 2

No último post fiz uma introdução sobre a criação de testes unitários com o DUnit. Hoje, vou explorar mais alguns recursos desta poderosa ferramenta, continuando com o exemplo da Calculadora, para isso, a calculadora vai ganhar um método para fazer divisão. Lembram do ritual? Red - Green - Refactor! Vejam a classe de teste, garanta que o teste falhe e então faça-o passar.

procedure TTestCalculadora.DivisaoDe6Por2DeveSer3;
var
 vCalculadora: TCalculadora;
begin
 vCalculadora := TCalculadora.Create;
 try
   CheckEquals(3, vCalculadora.Soma(6).DividePor(2).GetTotal, 'Divisão inválida');
 finally
   vCalculadora.Free;
 end;
end;

Fail!

function TCalculadora.DividePor(const AValor: Double): TCalculadora;
begin
  FValor := FValor / AValor;
  Result := Self;
end;

Success!

Usando DUnit para implementar testes unitários

Esse é meu primeiro post, e vou começar abordando um assunto que ao meu ver é pouco difundido na comunidade Delphi, Testes Unitários, e para isso vou demonstrar como utilizar a ferramenta DUnit para construção dos testes.

Cada vez mais é primordial que o desenvolvedor invista parte de seu tempo na construção de testes, se for utilizando TDD, melhor ainda. Uma boa suíte de teste nos dá segurança e confiança no momento de fazer um refactoring ou a correção de um bug. Também melhora significativamente o design do nosso código, pois, para pode testar de forma realmente unitária, nossas classes precisam ter baixo acoplamento, boa coesão, serem realmente testáveis.