kent beck | André Faria Gomes

Os Melhores Podcasts de Tecnologia para Desenvolvedores

Posted by andrefaria on Nov 20, 2009 in Agile, Featured | 5 comments

Um dos maiores problemas da sociedade moderna é a dificuldade de locomoção diária, a maioria das pessoas passa horas em seus carros, ou em meios de transporte públicos para irem de lugar a outro. Há alguns anos atrás quando morava na zona norte de São Paulo e trabalha na zona sul, essa era minha realidade. Uma vez que naquela época passar por isso era inevitável procurei formas de fazer com esse tempo pudesse de alguma forma torna-se produtivo, foi então que comecei a ouvir à podcasts.

iPod por Dan Taylor

De acordo com a Wikipedia, Podcasting é uma forma de publicação de arquivos de mídia digital (áudio, vídeo, foto, etc.) pela Internet, através de um feed RSS, que permite aos utilizadores acompanhar a sua atualização. Assim, é possível o acompanhamento e/ou download automático do conteúdo de um podcast.

Neste post apresentarei os podcasts aos quais escuto e os episódios principais para que você ouça. Sugiro que você utilize o iTunes para inscrever-se nos podcasts e sincronizar com seu iPod.

Desenvolvimento Ágil

por pcalcado

Podcast da ImproveIt

por Vinícius Teles
http://improveit.com.br/podcast
Português

AgilCast

Por AgilCoop
http://agilcoop.incubadora.fapesp.br/portal/agilcast
Português

Bluesoft Podcast

Por André Faria e Luiz Faias Jr.
http://podcast.bluesoft.com.br
Português em Áudio e Vídeo

Open Source

FLOSS Weekly

por Leo Laport, Jono Bacon e Randal Schwartz
Inglês

Java

HorecaExpo - Java por bramloquet

JBoss Community Asylum

Podcast da Comunidade JBoss
Inglês
http://asylum.libsyn.com

JavaPosse

Por Tor Norbye, Carl Quinn, Dick Wall e Joe Nuxoll
Inglês
http://www.javaposse.com

Java Technology Insider

Inglês
http://www.javaworld.com/podcasts/jtech

Rod Johnson: SpringSource and the future of Spring (2008)

Grails Podcast

Por Glen Smith e Sven Haiges
http://grailspodcast.com

Ruby

Ruby on Rails por Andrew*

Rails Envy

Por Jason Seifer e Gregg Pollack
Inglês
http://railsenvy.com

Rails Podcast

por Geoffrey Grosenbach
Inglês
http://podcast.rubyonrails.com/

Rubiverse Podcast

Por Mike Moore
Ingles
http://rubiverse.com

JavaScript

jQuery Podcast

Inglês
http://blog.jquery.com/2009/11/13/announcing-the-official-jquery-podcast/

yayQuery Podcast (jQuery)

Inglês
http://yayquery.com/

Audible Ajax

Inglês
http://ajaxian.com/by/category/podcasts

Gadgets

GeekBrief TV

por Cali Lewis
Inglês
http://www.geekbrief.tv

Software

Desk por Guillermo Esteves

Pragmatic Podcasts

por Pragmatic Bookshelf
Inglês
http://www.pragprog.com/podcasts

Software Engineering Radio

por Software Engineering Radio
http://www.se-radio.net
Inglês

Elegant Code

por Elegant Code Community
http://elegantcode.com
Inglês

Google Developer Podcast

http://code.google.com/p/google-developer-podcast/downloads/list
Inglês

Hearding Code

http://herdingcode.com
Inglês

The Dev Show

Inglês
http://5by5.tv/devshow

The Changelog

Inglês
http://thechangelog.com/

Tecnologia

IT Conversations

http://itc.conversationsnetwork.org
Inglês

net@Night

por Amber MacArthur e Leo Laport
http://www.twit.tv/natn

Twit – This Week in Tech

por Leo Laporte, Jeff Jarvis, Baratunde Thurston, e John C. Dvorak
http://www.twit.tv/twit

MacBreak Weekly

por Leo Laporte, Don McAllister, Paul Kent, and Andy Ihnatko
http://www.twit.tv/mbw

This Week in Google

por Leo Laporte, Gina Trapani, Jeff Jarvis e Mary Hodder
http://www.twit.tv/twig

SitePoint Podcast

inglês
http://www.sitepoint.com/podcast

Empreendedorismo e Negócios

37 Signals Podcast

por 37 Signals
Inglês
http://37signals.com/podcast

Max Gehringer (CBN)

por Max Gehringer
Português
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

Mundo Corporativo (CBN)

por Heródoto Barbeiro
Português em Áudio
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

The Startup Success Podcast

http://startuppodcast.wordpress.com
Inglês

TED Talks

por TED Talks
Inglês
http://www.ted.com

Stanford Technology Ventures

por Stanford

Inglês em Áudio e Vídeo

http://stvp.stanford.edu

Entrepreneurial Thought Leaders

por Stanford

http://ecorner.stanford.edu/podcasts.html

Se você quiser incluir algum outro podcast nesta lista, deixe um comentário. Espero que seja Útil!

Programação em Par

Posted by andrefaria on Dec 20, 2008 in Agile, Featured | 20 comments

Já faz algum tempo que a programação em par se tornou uma realidade do meu dia-a-dia, confesso que nos meus primeiros contatos com Extreme Programming (XP) essa era a prática que eu menos gostava, mas depois, ao me envolver mais com práticas ágeis comecei a perceber seus benefícios e inclusive passei a propagar a idéia, porém agora, senti um mais de perto como realmente funciona e gostaria de compartilhar um pouco do que venho aprendendo.

O que é programação e par?

Bernardo e Elmar por ImproveIt

A programação em par é uma técnica que sugere que todo e qualquer código produzido em um projeto de desenolvimento de software seja implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado [1]. A Pessoa quem está com teclado em mãos é chamada de condutor e a outra de navegador.

Por que programar em par?

“Unir-se é um bom começo, manter a união é um progresso, e trabalhar em conjunto é a vitória.”
(Henry Ford)

Foco no trabalho

Focus por Dani Ihtatho

Temos o mundo inteiro de informação e recursos ao alcance de alguns cliques. A internet, o correio eletrônico, o feed reader, somos tentados o tempo todo a nos distrair, e perder o foco do nosso objetivo principal: escrever código. A programação em par nos ajuda a manter o foco, afinal de contas, temos alguém sentado ao lado interessando em ver o problema resolvido, assim, com certeza, mesmo que tentados iremos evitar fazer outra coisa senão concentrar nossas energias em resolver o problema em questão. Isso não quer dizer que seja proibido consultar algo na internet, ou ler e-mails, na Bluesoft, por exemplo, sempre temos algumas máquinas disponíveis para esse tipo de coisa, porém, garanto que a freqüência desse tipo de atividade é bem menor quando se trabalha em par, e não são somente as distrações que são reduzidas, segundo Laurie Williams [3], as pessoas são menos interrompidas por outras quando trabalhando em par do que quando trabalhando sozinhas.

Ensinar e Aprender

Owen teaching Dad how to use the computer pro Jordan Brock

Owen teaching Dad how to use the computer por Jordan Brock

“Aprender é a única coisa de que a mente nunca se cansa, nunca tem medo e nunca se arrepende.”
(Leonardo da Vinci)

Todos nós somos diferentes, pensamos de forma diferente e sabemos coisas diferentes, programando em par essas diferenças podem se complementar de forma positiva trazendo mais qualidade ao trabalho e muito aprendizado a ambos os envolvidos, não somente conhecimentos técnicos, mas também muito conhecimento sobre o domínio de negócio são trocados todo o tempo.

Exterminando ilhas de conhecimento

“uhmmm…, esse problema é só com fulano mesmo, ele quem desenvolveu e sempre deu manutenção nisso, nem adianta tentar porque ninguém mais vai conseguir resolver isso “.

Quem nunca ouviu algo assim? Eu já, e muitas vezes. É comum, especialmente em contextos em que não são aplicadas metodologias ágeis, existirem ilhas de conhecimento, essas ilhas são representam o conhecimento retido por pessoas que não o com outras, muitas vezes por falta de oportunidade, outras por pensar que dessa forma se tornaram insubistituiveis, bobagem.

Ilhas de conhecimento podem se tornar um grande problema, porque a manutenção do software fica extremamente dependente da pessoa que retêm o conhecimento, e essa pessoa pode a qualquer momento sair da empresa, ficar de férias, estar viajando, etc… Mas e quando ocorrer um problema crítico e a pessoa não estiver presente? O grande problema é que tudo fica dependendo da ilha.

A programação em par estimula a troca de conhecimento, faz com que todo a equipe compartilhe o código e saiba um pouco de tudo o que foi desenvolvido, tornando assim, a toda a equipe capacitada a resolver qualquer problema a qualquer momento, se um membro da equipe estiver ausente, provavelmente não haverá poblemas por isso.

Mais disciplina = Mais qualidade = Menos bugs

asians with swords! por miss karen

A programação em par aumenta a qualidade do software sem impactar de forma significativa no prazo [2]. Apesar de ser contra senso que duas pessoas trabalhando em um único computador podem produzir mais valor do que trabalhando separadamente, sem dúvida é fácil de acreditar que irão entregar um trabalho de muito mais qualidade, e essa qualidade adicional, por si só, trará grandes ganhos mais tarde.

Laurie Williams da universidade de Utah em Salt Lake City comprovou que a programação é em média apenas 15% mais lenta do que a programação individual, porém, produz 15% menos bugs [5]. Considerando que testar e debugar é na maioria da vezes muito mais custoso do que a programação inicial, esse é um resultado no mínimo significativo.

Segundo Vinícus Teles, “a pessoa que está conduzindo o teclado (condutor) tem um campo de observação diferente do seu parceiro. Quem digita normalmente está olhando sobretudo para a linha que está editando e adjacências. O navegador, por sua vez, tem uma visão mais ampla e olha não apenas a linha que está sendo editada, mas também o restante do código que aparece na tela. Ao fazer isso, ele acaba tendo uma visão complementar que freqüentemente revela problemas que o condutor não percebe com a mesma rapidez” [1], dessa forma, o código está sendo revisado o todo o tempo, sem contar que programar em par evita que caiamos na tentação de não escrever testes unitários ou deixar refactorings de lado [4].

Dicas

Ping-pong programming (P3)

"Ping (Pong)" por Dustin Baxter

Ping-pong Programming [12] é um técnica que une programação em par e test driven development tornando o a programação em par mais divertida [13], dinâmica e interativa, consiste nos seguintes passos:

O Programador A escreve um novo teste e o deixa falhando.
O Programador B implementa o código necessário para fazer o teste passar.
O Programador B escreve o próximo teste.
O Programador A implementa o código necessário para fazer o teste passar.
O processo se repete.

Pausas

"Pause" por Vanderlin

Pare! Tome um café. Coma alguma coisa. Converse com outras pessoas além do seu par [7]. Tudo isso será bom para que descanse um pouco, se distraia e se prepare para voltar mais disposto e dar continuidade na tarefa.

Cuidado com discussões longas

Estabeleça um time-box para discussões. É comum que dois programadores discordem ao tentar decidir as melhores formas de implementar algo, quando isso acontecer, procure ouvir as razões da outra pessoa e apresentar suas argumentações, tentem chegar a um meio termo, se isso não for possível chame uma terceira pessoa para dar uma opnião. Não resista em ceder quando perceber que outro pode estar certo, lembre-se você está aprendendo e ensinando o tempo todo, não há problema algum em estar errado de vez em quando.

Não se engane!

Wrong Way por Emilie Eagan

Mito: Sem Programação em Par, não há Agilidade

Martin Fowler uma das personalidades mais respeitadas no mundo do desenvolvimento de software escreveu um artigo em 2006 levantando alguns dos principais enganos sobre programação em par. Fowler esclarece em seu artigo que “não é necessário programar em par para estar praticando um processo ágil” [11], nem mesmo para se pode dizer que para aplicar Extreme Programming você é obrigado a programar em par, o máximo que se pode dizer é que alguém aprender XP, deve tentar programar em par e ver se funciona em seu caso em particular [11]. A programação em par não é nem mesmo citada no manifesto ágil, porém, é uma prática altamente recomendada para que se alcance os principios ágeis.

Mito: A Produtividade cairá pela metade

Um outro engano muito comum é pensar que a produtividade dos desenvolvedores cairá pela metade, como discutimos anteriormente, na maioria dos casos essa afirmação será falsa.

Mito: Tenho certeza de que não vou gostar de programar em par

Segundo Fowler, muitas pessoas surpreendem-se e começam a gostar de programar em par depois de tentar, por isso, experimente antes de dizer de não gosta!

Conclusão

Concluo com a citação de Mary e Tom Poppendieck no livro “Implementing Lean Software Development”:

Programação em Par não é para todos, nem para todas as situações, porém, a programação em par cria sinergia: Duas pessoas vão frequentement entregar um código mais integrado, testado e sem defeitos, trabalhando juntas [...]. A Programação em par é uma das melhores formas de se atigir os beneficíos de revisões de código [...] .

Referências

[1] Improvit – Programação em Par
[2] Extreme Programming Rules – Pair Programming
[3] Williams, Laurie (2003). Pair Programming Illuminated, Addison-Wesley
[4] Beck, Kent (2000). Extreme Programming Explained, Addison-Wesley
[5] Cunningham & Cunningham – PairProgramming
[6] Mark Needham – Pair Programming: What works for me
[7] Brian Guthrie – The Way I Pair
[8] thekua.com@work – How I like to pair
[9] InfoQ – Pair Programming Debate
[10] InfoQ – Common misconceptions about paired programming
[11] Martin Fowler – Pair Programming Misconceptions
[12] Pair Programming Ping Pong Pattern
[13] Ping Pong Pairing: Even More Fun!
[14] Poppendieck, Tom and Mary (2007). Implementing Lean Software Development, Addison-Wesley

Test Driven Development

Posted by andrefaria on Jul 12, 2008 in Agile, Software | 3 comments

O contato com Scrum, XP e Agile em geral, me levaram à diversos conceitos que até então desconhecia, um dos quais resolvi me aprofundar foi TDD (Test Driven Devolpment), para isso li o livro ”Test-Driven Development by Example” escrito por Kent Beck. O Livro é muito esclarecedor e divertido de ler, apresenta diversos conceitos e técnicas através de exemplos de implementações de pequenas soluções.
TDD ou Desenvolvimento Dirigido por Testes, é uma técnica de desenvolvimento de software que consiste em pequenas iterações onde testes são escritos primeiro e o código produzido é somente o necessário para fazer o teste passar, e finalmente o código é refatorado para acomodar as mudanças. TDD proporciona feedback rápido depois de cada mudança. Não é considerado somente uma ténica de escrita de testes, mas uma técnica para design de software.

chemistry por tschoppi

TDD pode ser facilmente explicado em cinco simples passos:

Adicione um teste rapidamente.
Execute todos os testes e observe o novo teste falhar.
Faça uma pequena mudança para fazer o teste passar .
Execute todos os teste e observe que foram bem sucedidos.
Refatore e remova o código duplicado.

Para melhor entender este ciclo de cinco fases, vamos constuir um pequeno programa Java para realizar um simples cálculo de potência. Para executar os testes precisamos de uma ferramenta de testes unitários, utilizaremos o JUnit.

O JUnit possui uma classes chamada TestCase, a qual nossa classe de teste deverá extender. Essa classe possui uma série de métodos que nos auxiliarão no processo de testes unitários, tais métodos fazem o teste falhar caso determinadas condições não sejam satisfeitas.

Ex: O método “AssertEquals(x,y)“ faz o teste falhar caso x seja direferente de y.

  assertEquals(“TDD”,”DDD”); //Falha
  assertEquals(100, 100); //Passa

Começaremos então pelo teste:

  public class CalculadoraTest extends TestCase {
    public void testCalcularOitoAoQuadrado(){
      Calculadora calculadora = new Calculadora();
      assertEquals(calculadora.calcularPotencia(8, 2), new BigDecimal(“64”));
    }
  }

Se tentarmos executar nosso teste, o JUnit nos apresentará uma barra vemelha o que signfica que o teste falhou, e falhou porque a classe Calculadora e o método estático calcularPotencia ainda não existem. Vamos então criar a classe e o método para fazer o teste ao menos compilar.

  public class Calculadora {
    public void calcularPotencia(Integer a, Integer b){
      return null;
    }
  }

Nossa missão agora é fazer, rapidamente, o teste passar. Para isso vamos então retornar o valor que nosso primeiro teste espera, 64.

  public class Calculadora {
    public void calcularPotencia(Integer a, Integer b){
      return new BigDecimal(“64”);
    }
  }

Se executarmos o teste novamente o mesmo passará… Eu seu, eu sei, que isso pode parecer meio estranho no inicio, mas não se assuste, você se acostumará e entenderá melhor o que está por traz disso tudo com o tempo. Vamos adicionar mais um método de teste em nossas classe de testes

    public void testCalcularDoisAoCubo(){
      Calculadora calculadora = new Calculadora();
      assertEquals(calculadora.calcularPotencia(2, 3), new BigDecimal(“8”));
    }

E vamos fazer a alteração mais simples possível para fazer o teste passar:

  public class Calculadora {
    public void calcularPotencia(Integer a, Integer b){
      if (b == 2)
        return new BigDecimal(“64”);
      else
        return new BigDecimal("8");
    }
  }

Agora que os dois testes estam passando, realizaremos o processo de refatoração para remover as constantes e a redundancia do código, assegurando que o teste continue passando.

  public void calcularPotencia(Integer a, Integer b){
    BigDecimal result = new BigDecimal(a);
    for (int I = 0; I &lt; b; I++) {
      result = result.multipliedBy(BigDecimal.valueOf(a));
    }
    return result;
  }

Pronto! Refatoramos nosso código removendo as constantes e se executarmos nossos testes verificaremos que este será bem sucedido! Este é o processo básico de TDD.

Ops!!! O que acontecerá se tentarmos executar o método executar uma potencia de um número elevado a zero? Problemas!!! Todo o número elevado a Zero é igual a 1 (Um), dessa forma devemos adicionar um novo teste que verifique se um número elevado a zero retorna 1, fazer o teste passar, refatorar e assegurar de que os outros testes continuem passando.

  public void calcularPotencia(Integer a, Integer b){
    if (b.equals(0)){
      return BigDecimal.valueOf(1);
    }
    BigDecimal result = new BigDecimal(a);
    for (int I = 0; I &lt; b; I++) {
      result = result.multipliedBy(BigDecimal.valueOf(a));
    }
    return result;
  }

  public void testTodoNumeroElevadoAZeroDeveRetornarUm(){
    Calculadora calculadora = new Calculadora();
    assertEquals(calculadora.calcularPortencia(21, 0), new BigDecimal(“1”));
    assertEquals(calculadora.calcularPortencia(8, 0), new BigDecimal(“1”));
  }

É isso pessoal! Parece simples, mas não é fácil. Depois muito treinamento e prática em diferentes cenários isso começa a ficar mais natural e você passa a enxergar mais claramente os benefício desta poderosa técnica. Estou a disposição para esclarecimento de dúvidas. Comentários são sempre muito bem vindos.

Posts Tagged "kent beck"