quinta-feira, 27 de maio de 2010

Firebird - Comandos SQL úteis - Substring, Cast, Case, Like




Olá amigos esse post abaixo é um copy / paste que fiz do endereço no final do post .... quero agradecer ao Thunder Boy pelas dicas ... não deixem de dar uma passada lá no blog dele e conferir. 


Problema: Como mostrar apenas parte dos dados de um coluna em um relatório?

=============================
SUBSTRING
=============================

Conheça o  “substring”, mas como ele funciona? 
A sintaxie é a seguinte: select substring (”nome do campo” from “coluna_inicial” for “caracteres”) from “nome da tabela”
Exemplo: A máscara de estoque é de 8 digitos, porém quero que na SQL mostre apenas os 3 últimos dígitos
select substring (codpa from 6 for 3) as Referencia from etprocab where codemp=1
Nota: Este comando é muito útil e pode ser usado inclusive para acerto de base, quando é necessário diminuir o tamanho de alguma configuração, para isto basta combiná-lo com update
=============================
CAST
=============================
Porém a coluna irá ser mostrada grande, devido ao tamanho que foi criada, ai neste caso basta usar o “cast” para reduzir o tamanho da coluna na consulta
Exemplo:
select cast(substring (codpa from 6 for 3) as varchar (3)) as Ref from etprocab
where codemp=1
Nota: Este comando é útil, para ser usado no gerrel, pois neste caso iria mostrar a coluna grande no excel e após usar o “cast” o tamanho da coluna fica limitada ao tamanho informado no comando
=============================
LIKE
=============================
Outro comando bacana é o like, que acredito que não seja novidade pra ninguém, porém mesmo assim vai a dica:
select * from dtclifor
where insestrg like ‘%NTO’ /* Neste caso o percentual antes da palavra substitui as letras que o antecede */
and insestrg like ‘ISE%’ /* Neste caso o percentual depois da palavra substitui as letras da sequencia */
and insestrg like ‘%EN%’ /* E entre percentuais ira retornar todos valores que contenham a consulta em qualquer parte do campo */
Mais se quiser consultar todos os registros que variam apenas um caracter, como faço?
Basta utilizar o “_” (underline) no lugar do percentual, pois neste caso ele irá considerar a variação de apenas uma casa decimal na consulta.
Exemplo:
select * from dtclifor
where codclifor like ‘10000_1′
=============================
CASE
=============================
E vai a dica do comando case, onde com ele é possivel mostrar dados que seriam mostrados por linha, nas colunas
Exemplo:
select
sum ( case when vendedor = 1 then pretot else 0 end ) as Vendedor_1,
sum ( case when vendedor = 2 then pretot else 0 end ) as Vendedor_2,
sum ( case when vendedor = 3 then pretot else 0 end ) as Vendedor_3,
sum ( case when vendedor = 4 then pretot else 0 end ) as Vendedor_4
from vtvencor
where tipo in (’VBA’, ‘VBT’, ‘VCO’)
and situacao=1
and codemp=1
Nota: Este é um exemplo simples de como usar o comando case, onde mostra o valor vendido com base na tabela vtvencor, porém não é considerado os descontos e acréscimos do cadastro da venda e mostra os valores independente da venda cadastrada ou não. É apenas para demonstrar o uso do case.
=============================
COMENTÁRIO EM COMANDOS
=============================
Outra dica útil é poder colocar comentários em comandos para isso basta entre os comentários colocar as tags “/*” para iniciar e “*/” para finalizar, com isso ao executar o comando, não será considerado o que estiver entre as tags
Exemplo:
select * from dtclifor
where codemp=1 /* Comentário qualquer de sua preferencia… */


sexta-feira, 14 de maio de 2010

Compilar em apenas um passo




Na serie de arigos sobre o teste do Joel estou escrevendo sobre os pontos que devem ser levados em consideração para a melhor o processo de produção de software.

A segunda  pergunta do 
teste do Joel é saber se você pode compilar todo o projeto em apenas um passo. Essa é uma questão essencial e um desafio para muitas equipes. Em muitos casos perdem-se horas sagradas para gerar um novo Release.

Boas equipes possuem um único script que faz um checkout completo do zero, reconstrói cada linha de código, faz os EXE's, em todas as suas várias versões, linguagens e combinações de #ifdef, cria o pacote de instalação e cria a mídia final -- layout do CDROM, download do website, o que seja.

Se este processo possui mais de uma etapa, ele tende a ter erros. E quanto mais perto você chega da data de entrega, mais você quer ter um ciclo realmente rápido para corrigir o "último" bug, fazer os EXE's finais, etc. Se você leva 20 etapas para compilar o código, executar o construtor de instalação, etc, você vai enlouquecer e cometerá erros bobos.

Para automatizar o processo de compilação existem diversas ferramentas mas duas premissas sempre se mantêm independente da ferramenta escolhida :
  • Deve ser possível compilar o projeto inteiro em um passo
  • Deve ser possível usar qualquer máquina de desenvolvimento para isso

Citando algumas ferramentas:

Cruise Control
 - ferramenta que automatiza o processo de build, provendo várias tarefas que facilitam o controle sobre o código, incluindo uma interface para visualizar os detalhes sobre cada build

Visual Build Professional
-   ferramenta que possui suporte para o Microsoft Visual Studio .NET/2005, Visual Studio Team System, Visual Basic, Visual C++, SourceSafe, eMbedded Tools, Borland Developer Studio, Delphi, JBuilder, C++Builder, ClearCase.  Para sistemas de builds pequenos/medios ele é excelente. Já para builds de grande porte, pode não ser uma boa já que ele não permite o que, em alguns casos, dificulta o reaproveitamento dos scripts.

Além das ferramentas acima ainda merecem ser lembradas o Quick Build e o Luntbuild


Finalizando ...

Seja qual for a sua ferramenta preferida, o que realmente importa é que o processo seja o mais automatizado possivel, para assim diminuir as possibilidades de erros, como também agilizar o processo de deploy de novas versões do sistema.

Para quem desejar saber mais sobre o assunto seguem alguns links que entre outros serviram de base para este post

terça-feira, 11 de maio de 2010

O Planning Poker





Antes de mais nada o conceito

O Planning Poker é uma técnica de estimativa baseada no consenso de toda a equipe, onde é utilizado um conjunto de cartas com valores específicos que podem representar pontos relativos ou até mesmo horas (esses valores podem seguir a seqüência de fibonacci) e é praticado como se fosse um jogo. Uma pessoa apresenta a tarefa ou estória para o time, e, após uma breve discussão, cada um escolhe uma carta e coloca virada para baixo sobre uma mesa. Quando todas as cartas estiverem lançadas, elas são viradas e caso não haja consenso nos valores escolhidos, as diferenças são discutidas de forma breve, e uma nova rodada acontece até que haja a convergência.


Porque usar o Planning Poker?
Quem trabalha com desenvolvimento de software sabe que um dos nossos maiores desafios é conseguir mensurar o tamanho de cada tarefa com uma boa precisão, e, conseqüentemente, conseguir prever quando determinado recurso deverá ser concluído. A forma como fazemos nossas estimativas tem um grande impacto na confiabilidade de nossos prazos, porém, nem sempre as equipes tomam consciência desse fato, e continuam dando pouco valor ou dedicando menos esforço do que deveriam a essa atividade.
Seja qual for a metodologia de trabalho que sua equipe utiliza (scrum + XP ou outra mais tradicional) você pode utilizar diversas técnicas de estimativas. 
Algumas vantagens do Planning Poker:
· Equipe mais comprometida, pois todos participam;
· Força a equipe a ter um conhecimento de negócio mais homogêneo;
· Aumenta bastante a precisão das estimativas, pois considera a experiência de todos;
· Mais atraente (divertida) que as demais técnicas.
Se seu time está tentando implementar o scrum, algumas considerações:
· Estórias são funcionalidades, na forma como tem valor para o cliente (no scrum, o PO ou Product Owner). Exemplo: Eu como usuário quero poder cadastrar um produto;
· Tarefas são as implementações que devem ser feitas para que a funcionalidade seja entregue. Uma estória pode possuir uma ou mais tarefas;
· Nós só conseguimos estimar com precisão as tarefas pequenas. Se estiver estimando em horas, um valor maior que oito já é considerado um ‘chute’, e geralmente significa que aquela tarefa deve ser particionada em pelo menos duas partes, e reestimada, portanto, é recomendável assumir que cada tarefa deve ser pequena o suficiente para poder ser executada em um dia;
· Nem todas as estórias precisam ser detalhadas durante as estimativas. Se você trabalha com scrum, durante o backlog estimate (reunião, geralmente semanal, onde estimamos apenas as estórias de usuário) todas as estórias são reestimadas, e as estórias grandes são quebradas de acordo com a priorização do Product Owner. Dessa forma, as estórias com prioridade mais baixas podem ser estimadas com valores mais altos, e seu detalhamento pode ser postergado para quando se tornarem mais próximas de serem selecionadas para o sprint;
· Estimativas por horas devem ser feitas sem considerar as interrupções, ou seja, o tempo que efetivamente levaríamos para concluir a tarefa em um dia ideal;
· Estimativas por pontos é uma técnica muito boa para se estimar as estórias de usuário e não as tarefas, que usamos estimativas por horas em dias ideais (veja mais sobre estimativas por pontos aqui).
Existe um site bem interessante onde é possível jogar online o Planning Poker com sua equipe: planningpoker.com. Mas note que o poker real, com cartas de papel, é mais recomendável e geralmente mais ágil. Existem vários sites que fornecem as cartas para impressão, como: sprintplanning.com (para mais, deem uma olhada nas referências da Wikipedia).
Aqui tem uma explicação bem legal sobre como funciona a dinâmica do jogo:www.crisp.se/planningpoker

Links que serviram de base para este post