Pessoal,
Está sendo organizado, através do twitter, um Happy Hour Ágil que acontecerá em Campinas/SP. Será no dia 19/08 às 19:30 no Giovannetti da Rua Padre Vieira, 1277 - Cambuí - Campinas, ao lado da Prefeitura.
Para acompanhar o que estamos falando sobre este Happy Hour lá no twitter, procure pela tag #HHA
Nos encontramos lá =D
Hoje eu tive um problema pra lá de bizarro:
Eu estava trabalhando normalmente no Ubuntu, quando precisei reiniciar e abrir uma aplicação à partir do Windows. Quando eu voltei para o Ubuntu, o som parou de funcionar. Tudo estava instalado, o único problema era que o som não saia na caixa de som.
Eis a solução:
“2.1 If you are in Windows unplug the AC cable and plug it back after you logged into Ubuntu.
2.2 If you are already on Linux after a Windows session and you didn’t follow point 1.1estat, Unplug the AC cable, then SHUTDOWN , not restart the computer. Start it again manually and plug the cable back after you logged into Ubuntu ”
http://ubuntuforums.org/showthread.php?t=455147
Achei legal compartilhar isso aqui antes que alguém se mate re-compilando os drivers do alsa e assim por diante =D
Olá Pessoal,
Neste último final de semana eu gravei um screencast de como criar um branch vazio no Git.
Espero que vocês gostem:
Creating an empty branch on Git from Alberto Leal on Vimeo.
Abraços.
No artigo de hoje, vamos abordar uma funcionalidade muito interessante do Git, a qual nos permite fazer uma busca binária no projeto procurando o commit exato onde o bug foi introduzido no projeto.
Cenário: Você não é o único desenvolvedor que trabalha no projeto. Enquanto você trabalha em um branch, outras pessoas trabalham em outros branches, e no final todos fazem o merge no branch master. O merge é feito várias vezes por semana. Em um belo dia, uma funcionalidade que antes funcionava perfeitamente para de funcionar, mas ninguém sabe dizer quem foi o responsável por quebrar aquela parte da aplicação, e como não existia uma suíte de testes cobrindo tal funcionalidade, o bug foi commitado.
Problema: Onde o erro foi commitado?
Solução: Utilizar o comando git bisect.
O projeto possui os seguintes commits:
commit 5c370fe0c059566a88e41699bfb7fea0abf4da0c Author: Alberto Leal <albertonb@gmail.com> Date: Sat Dec 12 11:05:04 2009 -0200 CBR 98575 - Cert verification commit bd9e83fe1def11a38436d159b1ce721920fb9565 Author: Alberto Leal <albertonb@gmail.com> Date: Sat Dec 12 11:04:25 2009 -0200 CBR 26345 - Regression commit 61de4d21518855196426986ee0798c1e69f05ae0 Author: Alberto Leal <albertonb@gmail.com> Date: Sat Dec 12 11:03:37 2009 -0200 bug 123 fixed commit 32c8ce277a7db30aea67f7397a06596b1fc8bfdf Author: Alberto Leal <albertonb@gmail.com> Date: Sat Dec 12 11:02:58 2009 -0200 sessionTimeout features added commit 1973d569ac052697c6e35e7e26b4e7b03ba09616 Author: Alberto Leal <albertonb@gmail.com> Date: Sat Dec 12 11:01:58 2009 -0200 slogan on the header commit 294d5cac2d9b400b7d244d71c6db5849f61fad6a Author: Alberto Leal <albertonb@gmail.com> Date: Sat Dec 12 11:01:01 2009 -0200 initial commit
**Para efeito de didática, já sabemos que o bug está no commit:
bd9e83fe1def11a38436d159b1ce721920fb9565
Antes de iniciar a busca binária, deve-se saber pelo menos um commit onde não existia o bug. Neste caso, sabemos que até o segundo commit tudo funcionava perfeitamente. Mas, para ter certeza disso, execute o comando abaixo, rode a aplicação e teste:
git checkout 1973d569ac052697c6e35e7e26b4e7b03ba09616
Observação: Estamos utilizando poucos commits, mas no “mundo real” os commits são muitos.
Após constatar que não existe o bug no segundo commit, volte para o último commit da mesma maneira:
git checkout 5c370fe0c059566a88e41699bfb7fea0abf4da0c
Agora chegou a vez de utilizar o comando git bisect. A idéia é marcar os commits como bad(ruim) e good(bom), e deixar que o Git faça uma busca binária entre os commits.
Alberto:repo Alberto$ git bisect start Alberto:repo Alberto$ git bisect bad Alberto:repo Alberto$ git bisect good 1973d569ac052697c6e35e7e26b4e7b03ba09616 Bisecting: 1 revisions left to test after this (roughly 1 steps) [61de4d21518855196426986ee0798c1e69f05ae0] bug 123 fixed
Antes de mais nada, é necessário informar ao Git que vamos iniciar uma busca binária, para isso execute git bisect start. Repare que após iniciar o bisect, marcamos o último commit como bad e o segundo commit como good.
Em seguida o Git fez uma busca binária e encontrou o commit “bug 123 fixed”. Neste momento você deve executar a sua aplicação para ver se o bug está lá.
Não, o bug não está lá, portanto, marcamos o commit como good:
Alberto:repo Alberto$ git bisect good Bisecting: 0 revisions left to test after this (roughly 0 steps) [bd9e83fe1def11a38436d159b1ce721920fb9565] CBR 26345 - Regression
Novamente, o Git faz uma busca binária e encontra mais um commit para ser analisado. Após rodar a aplicação, constata-se que o erro está no commit atual que o bisect encontrou “CBR 26345 - Regression”:
Alberto:repo Alberto$ git bisect bad bd9e83fe1def11a38436d159b1ce721920fb9565 is first bad commit commit bd9e83fe1def11a38436d159b1ce721920fb9565 Author: Alberto Leal <albertonb@gmail.com> Date: Sat Dec 12 11:04:25 2009 -0200 CBR 26345 - Regression :100644 100644 9309150acfad8f21cb460ee17663fcbeaf212aa0 172b5ae1734b7bd1e1ac46b5cade3e61cbfddff1 M imasters.txt
Pronto! Agora já sabemos em qual commit o bug foi introduzido. E, para finalizar, da mesma forma que informamos ao Git que desejávamos fazer uma busca binária, devemos informá-lo que já terminamos, executando o comando abaixo:
Alberto:repo Alberto$ git bisect reset Previous HEAD position was bd9e83f... CBR 26345 - Regression Switched to branch 'master'
Muita gente acha que quando se está trabalhando sozinho em um projeto de software não é necessário utilizar um sistema de controle de versões. O que é um falácia. Utilizar um SCM é indispensável e indiferente à quantidade de desenvolvedores que está trabalhando no projeto.
Caramba, quanto tempo que eu não posto nada =(
Mas hoje eu não vim aqui para publicar algo técnico. Dei uma passada rápida para dar um recado aos leitores do blog.
Aconteceu algo nesta semana que gostaria de compartilhar com vocês.
Leiam o email abaixo:
Ei Alberto, boa tarde.
Obrigada pelo retorno.
Sou editora do iMasters e cheguei até você através de um de nossos desenvolvedores. Ele viu seu artigo [http://albertoleal.eti.br/2009/06/git-o-rebase-pode-te-assustar/] e me repassou, com ótimos comentários.
Gostaria de saber se você tem interesse de publicar o artigo no iMasters. E não só ele, como outros também, sendo nosso articulista.
Se você topar, preciso apenas que faça cadastro no site, como usuário, e me envie uma foto (rosto) e um texto curto para o seu perfil. Com isso em mãos, farei o agendamento desse artigo e, então, você poderá publicar semanalmente - intervalo mínimo.
O que me diz?
Aguardo sua resposta.
Atenciosamente,
Rina Noronha
Editora - Redação iMasters
Fiquei muito contente com o convite feito pela Rina, editora do iMasters. Pois, meu primeiro contato com o iMasters foi há muitos anos atrás, logo no início da carreira hobby. E, nunca imaginei que um dia eu pudesse vir a me tornar um colunista do site.
Inicialmente, os artigos publicados por lá serão sobre Git.
Por que? Quando eu iniciei minha série de posts sobre este assunto, eu recebi um ótimo feedback através de emails e twitter, com isso, espero poder ajudar ainda mais pessoas, já que o público do iMasters é N vezes maior do que o meu humilde blog =)
Eu pretendo escrever artigos exclusivos para serem publicados no iMasters, mas isso somente acontecerá no próximo ano.
O primeiro artigo já foi publicado: “Git: o rebase pode te assustar”
Boa leitura!
Recent Comments