-->

On duplicate key update

1

Category : Banco de Dados

Tá ai um recurso que achei magnifico no MySQL 5, talvez não seja mais novidade para niguém, mas para mim foi bem interessante descobrir que não preciso mais fazer um update na minha abstração de dados, posso fazer tudo com insert e caso uma das chaves já esteja cadastrada o MySQL dispara um update.

O procedimento é muito simples, basta que você tenha uma primary key ou um index único e você poderá utilizar esta técnica.

Exemplo:

INSERT INTO table (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=c+1;

O comando acima irá atualizar a coluna c com o valor de c+1 quando a primary ou o index for duplicado.

Você pode indicar outros campos para serem atualizados também.

Exemplo:

INSERT INTO table (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=c+1, b=now();

É uma técnica simples, mas que pode ganhar muito tempo de projeto dependendo da sua aplicação.

Para saber mais:
 


Tags BlogBlogs: mysq, banco de dados, duplicate key

SCRUM – Primeiros passos

2

Category : Engenharia de Software

Mudei de emprego recentemente, e tive a oportunidade de ter contato com o SCRUM, que curiosamente segue a fio a teoria que eu vinha acompanhando.

Em resumo, o cliente ou o gerente (que é chamado de PO – Project Owner) quer fazer algo, então ele separa isso em partes, algo como: criar base de dados, modelar classes, criar interface, desenvolver, etc (essas partes são chamadas histórias), então em uma reunião com a equipe o PO diz o que precisa ser feito.

A equipe analisa cada história e o coordenador ou líder de projeto (chamado de Scrum Master) solicita que cada membro da equipe diga o quão dificil isso é de fazer, cada equipe adota uma escala, no meu caso a escala foi a seguinte 0,1/2,2 e 3 para facil, 5 e 8 para dificuldade média e acima disso dificil. Quando todos apontam a dificuldade que acham ser a da história, temos uma discussão entre os extremos, por exemplo, alguém sozinho colocou 1/2 e outra pessoa sozinha colocou 3, temos dois pontos de vista extremos e precisamo entender o que levou a essa visão, após uma rápida argumentação das partes, todos os membro apontam a dificuldade novamente, e esse processo se repete até chegarmos em valores coerentes.

Se analisarem, dessa forma, você consegue segmentar as equipes para trabalharem com níveis de dificuldades diferentes, tendo assim equipes que solucionam dificuldades de até 3 pontos para tarefas fáceis, equipes que trabalham com dificuldades acima de 5 pontos e assim por diante.

Após a distribuição de dificuldades entre as histórias, selecionamos as histórias que serão executadas até a próxima reunião (isso é chamado de sprint), as reuniões podem ter intervalos diferentes dependendo da equipe, no meu caso temos sprints de 15 dias, então escolhes as histórias que iremos trabalhar pelos próximos 15 dias. Podemos saber quantos pontos uma equipe é capaz de trabalhar por sprint, assim conseguimos medir a produtividade em relação a dificuldade da equipe.

Finalizada a etapa de separação das histórias por dificuldade, reunimos a equipe sem o PO e dividimos as histórias em tarefas. E realizamos um processo semelhante, porém indicando quanto tempo leva para realizar cada tarefa e não a dificuldade, assim, cada historia pode ter n tarefas, no entanto, podemos identificar se houve alguma falha no planejamento, caso histórias com dificuldades semelhantes tenham tempos de execução muito diferentes.

É um resumo do que vi até agora, quando tiver mais experiência com isso eu passo mais detalhes.

Para saber mais:

 

Tags BlogBlogs: scrum, desenvolvimento ágil