Arquivo dos posts do autor 'Alecão'

Mega coleção de cartões para Desenvolvedores e Designers

Achei esta postagem interessante e resolvi colocar aqui no blog para compartilhar:
Mega Collection Of Cheatsheets for Designers & Developers

Glyphs para os botões da sua aplicação

Normalmente é difícil encontrar um grande número de glyphs que tenham o mesmo tema para usar em botões de tamanho 16×16.

Há alguns meses eu achei este conjunto de glyphs FAMFAMFAM Silk Icons. Eles são “sóbrios” e bonitos. Podendo ser usado em um grande número de aplicações. Infelizmente, como estão em formato PNG ao serem convertidos para BMP perdem as características. Mas mesmo assim fica bom em aplicativos feitos em Delphi.

Delphi - Verificando se o TDataset esta vazio

Jefferson que trabalha comigo, me questionou o que era mais rápido para verificar se havia dados em um TDataset, verificar a propriedade RecordCount ou a propriedade Eof?

var
  Q: TQuery;
begin
  …
  Q.Open;
  if not Q.Eof then
    …
  // ou
  if Q.RecordCount > 0 then
    …
 

Fiquei sem saber a resposta e falei para ele testar. Ele chegou a conclusão que o método Eof era instantâneo ao contrário do RecordCount.

Acredito que internamente a propriedade RecordCount deva “levantar” a quantidade de registros no momento em que ela é lida. Pelo menos no BDE que foi o tipo de comunicação que foi utilizado nos testes.

Independente disso, no TDataset existe uma propriedade que é mais legível, a IsEmpty:

var
  Q: TQuery;
begin
  …
  Q.Open;
  if not Q.IsEmpty then
    …
 

Pensando um pouco com relação as subestimativas

Recentemente, andei pensando na questão das subestimativas de esforço com relação aos desenvolvimentos de software. Mesmo sem nenhuma estatística é fácil dizer que a grande maioria das estimativas de esforço e tempo para desenvolvimento e implantação de softwares são menores que os reais.

Percebi nos meus tempos coordenando que os mais “novos” (de experiência) subestimam mais que os mais “velhos”.

Filosofando um pouco, acabei chegando a 2 conclusões.

Pessoas não “contam” a parte ruim

Não sou psicólogo, mas acredito que as pessoas no momento inicial da estimativa, apenas “lembram” das partes prazerosas do seu trabalho, as partes penosas são subtraídas deste pensamento, isso faz com que ele vê menos esforço com relação ao real. Acredito que os mais experientes acabam lembrando do não prazero por terem “apanhado” muito no passado.

Uma forma de evitar este equivoco seria criar um diário de bordo com anotações com todas as tarefas exercidas pelo profissional. Quando for estimar uma nova atividade, este ”olharia o passado” para verificar quais são as atividades (tanto as prazerosas, quanto as não prazerosas).

Estimativas de valor alto são penalizadas 

Pelo menos em empresas de desenvolvimento pequenas, sempre que alguém estima um prazo grande para uma atividade, levanta-se a discução, as vezes em vários níveis da empresa, se aquela informação esta correta. Já escutei um vendedor questionando que com aquele esforço ele não conseguiria vender (dado que o valor cobrado do cliente era proporcional ao esforço passado). Para o desenvolvedor, que só quer desenvolver, estes questionamentos funcionam como uma espécie de castigo e quando ele subestima, ninguém reclama.

É comum vermos reclamações quanto a não entrega em data pré combinada a reclamações quanto a subestimativa. Tem a ver com a memória curta das pessoas. Acredito que neste caso o desenvolvedor não sinta culpado pela subestimativa e portanto o fato de não ver problema nela. Os mais experientes acabam aprendendo a dura lição e acabam criando opniões fortes que combatam os questionamentos, o efeito colateral é que estes acabam tornando-se intransigentes.

Quanto esta segunda conclusão, acredito que para resolver deveriamos repensar as broncas, a estimativa deve ser comparada com o realizado, e apenas neste caso um desvio deve ser questionado (tanto para cima quanto para baixo). O questinamento prévio deveria ser evitado a todo custo.

E você o que pensa disso?

De sua opnião nos comentários, me diga porque acha que exista a subestimava e como devemos tratar para resolver.

Sistemas de controle de versão distruibuídos

Encontrei um artigo denominado Sistemas de Controle de Versão Distribuído: Um Guia não tão rápido. Este artigo explica as diferenças deste em relação aos sistemas de controle de versão não distruibuídos como Subversion e também compara os 3 sistemas de controle de versão distribuídos atuais que são o GIT, Mercurial e Bzr

Eu usei e me apaixonei pelo Subversion mais TortoiseSVN, mas em alguns projetos específicos em que precisava ter controle de vários branchs do mesmo projeto, vi que o Subversion não atende. O Subversion é muito bom ao atender projetos que tem releases únicos. 

Na última empresa que trabalhei, existia uma necessidade específica de versionar fontes específicos para cada cliente mas do mesmo software. Não sei se estas ferramentas distibuídas fazem isso, mas fiquei curioso para experimentar e descobrir se isso é possível.

Pretendo fazer experimentos com o Mercurial que possui um GUI chamado TortoiseHg, inclusive o TortoiseHg preve uma instalação completa incluindo os binários o Mercurial.

Conforme for minha experiência eu relato ela aqui.

Máquina de Estados - Provando a praticidade

Quando falei sobre máquina de estados nos artigos:

Falei que era muito útil no dia-a-dia para resolver problemas de lógica. Pois semana passada me deparei com um problema desses e pensei, isso é um caso de máquina de estados e saquei um papel e desenhei:

Continue lendo ‘Máquina de Estados - Provando a praticidade’

Blog sobre Engenharia de Software

Hoje, a Tamara que trabalha comigo me indicou um blog sobre Engenharia de Software do Professor José Augusto Fabri, pelo que entendi, ele dá aulas na Faculdade de Tecnologia de Ourinhos (São Paulo). Comecei lendo alguns artigos e gostei muito. Ele aborda assuntos como qualidade, métrica, normas, fábrica de software, entre outros assuntos. Muito boa a qualidade dos textos.

Ponteiros no Pascal / Delphi - Ponteiro de Ponteiro

Este é um recurso de programação interessante, podemos ter ponteiros apontando para ponteiros. Abaixo um pequeno exemplo em Pascal / Delphi de como é a declaração e o uso de um ponteiro que aponta para um ponteiro:

Continue lendo ‘Ponteiros no Pascal / Delphi - Ponteiro de Ponteiro’

Ponteiros no Pascal / Delphi - Ponteiros para matrizes / vetores

Assim como dissemos no post passado que podemos usar os ponteiros para apontar para estruturas, também podemos usar os ponteiros para apontar para matrizes ou vetores. Veja o exemplo abaixo:

Continue lendo ‘Ponteiros no Pascal / Delphi - Ponteiros para matrizes / vetores’

Ponteiros no Pascal / Delphi - Ponteiros para estruturas (Record)

Os ponteiros podem ser usados também para indicar o endereço de uma estrutura de dados (Record em Pascal / Delphi). Basta além de definir a estrutura, também definir um ponteiro para este tipo de estrutura como no exemplo abaixo:

Continue lendo ‘Ponteiros no Pascal / Delphi - Ponteiros para estruturas (Record)’