opa! Pessoal,
Queria compartilhar com vocês o pré-lançamento do meu livro. A previsão é que seja publicado até final de junho/2012 pela editora Ciência Moderna. Ainda não recebi a versão final do livro pela editora, mas assim que receber estarei disponibilizando alguns capítulos :). Fiz um post no blog sobre o livro:
http://blog.camilolopes.com.br/prelancamentotddnapratica
abracos!! flw.
Opa, parabéns, mais um pra lista de cabeceira…
Parabéns Camilo por mais um livro seu que será lançado, quando sair comprarei
Camilo é o nosso Paulo Coelho do GUJ!
Parabéns pelo livro!
Abração!
[quote=Leozin]Camilo é o nosso Paulo Coelho do GUJ!
Parabéns pelo livro!
Abração![/quote]
ótimo comentário.
Parabéns certamente comprarei 
Parabéns cara!
Tomara que seu livro ajude os desenvolvedores a tirarem um pouco o foco de tantos frameworks e tecnologias e se concentrarem mais em TDD.
Sério, vejo tanta gente empregando tanto esforço em estudar as entranhas de frameworks como JSF, Hibernate, Spring e outros, e esse pessoal às vezes foca tanto nessas coisas que esquecem de estudar assuntos realmente relevantes, como TDD, cujo domínio provoca intenso impacto na capacidade profissional - e na qualidade do código que você escreve.
Camilo, você tem intenção de vender o livro em formato de e-book também? Seria bem interessante poder ler o livro no iPad ou no Kindle, em vez de carregar um monte de livros pra cima e pra baixo.
E parabéns pelo livro!
[quote=vitorh.campos]Camilo, você tem intenção de vender o livro em formato de e-book também? Seria bem interessante poder ler o livro no iPad ou no Kindle, em vez de carregar um monte de livros pra cima e pra baixo.
E parabéns pelo livro![/quote]
Isso que dá fazer a pergunta sem ler o artigo no blog primeiro: agora que eu vi que também vai ser vendido como e-book!
Parabéns por mais essa iniciativa!!
Usei o guia SCJP para a certificação e gostei muito , até comprei o curso online de presente para um amigo que também estava estudando.
Meu aniversario esta chegando , vou ganhar o de Engenharia e Arquitetura da CAELUM e com ctz, vou dar um jeito de pedir esse pra alguém xD
Sera que rola um desconto Camilo LP?
opa! pessoal,
obrigado pelo comentários e feedback. uhauhhua gostei da associação com Paulo Coelho, porém a diferença é que o Paulo é escritor, nasceu para escrever livros. Já eu, escrevo por hobby, esse ai tá na gaveta desde de 2010 e só em fev para inicio de março que conseguir fechar o último capítulo.
mausexdd: posso conseguir 30% de desconto :). Ainda não temos o valor, pois quem faz esse é a editora. Como sempre vou brigar por um preço acessível.
tnaires: esse é o objetivo, o livro é puramente “seco” em termo de Java, longe dos frameworks que vc citou. A idéia é praticar TDD e exercitar o ciclo e buscar resolver problemas. Dividir o livro em duas partes: Na primeira eu até ajudo os primeiros passos, mas na parte 2, ele vai se virando.
eu aprendi bastante durante esses 2 anos escrevendo, achei que pelo fato de usar no dia-dia seria moleza escrever o livro, mas não foi. Pois, escrever sobre refactoring, TDD etc. Esses assuntos que são abstratos e não tem receita de bolo, não é fácil. Tentar deixar claro para o leitor que nunca é a mesma solução para tudo, que saber dar os passos certos e como dar, é um tremendo desafio. E o melhor, não fazer o cara se sentir um TDD expert só pq leu o meu livro, ou do Kent Beck, que ai é apenas a porta de entrada e uma motivação para quem tá no 0x0.
valeu pessoal,pelo apoio. Assim q for lançado e receber os exemplares, vou sortear um :).
[quote=LPJava]opa! pessoal,
obrigado pelo comentários e feedback. uhauhhua gostei da associação com Paulo Coelho, porém a diferença é que o Paulo é escritor, nasceu para escrever livros. Já eu, escrevo por hobby, esse ai tá na gaveta desde de 2010 e só em fev para inicio de março que conseguir fechar o último capítulo.
mausexdd: posso conseguir 30% de desconto :). Ainda não temos o valor, pois quem faz esse é a editora. Como sempre vou brigar por um preço acessível.
tnaires: esse é o objetivo, o livro é puramente “seco” em termo de Java, longe dos frameworks que vc citou. A idéia é praticar TDD e exercitar o ciclo e buscar resolver problemas. Dividir o livro em duas partes: Na primeira eu até ajudo os primeiros passos, mas na parte 2, ele vai se virando.
eu aprendi bastante durante esses 2 anos escrevendo, achei que pelo fato de usar no dia-dia seria moleza escrever o livro, mas não foi. Pois, escrever sobre refactoring, TDD etc. Esses assuntos que são abstratos e não tem receita de bolo, não é fácil. Tentar deixar claro para o leitor que nunca é a mesma solução para tudo, que saber dar os passos certos e como dar, é um tremendo desafio. E o melhor, não fazer o cara se sentir um TDD expert só pq leu o meu livro, ou do Kent Beck, que ai é apenas a porta de entrada e uma motivação para quem tá no 0x0.
valeu pessoal,pelo apoio. Assim q for lançado e receber os exemplares, vou sortear um :).[/quote]
Parabéns! Muito Show!
Porém conheço desenvolvedores que sofreram,sofrem e sofrerão bastantes com essa abordagem. Quando trabalhava na BRQ lembro que a especificação chegava sempre com prazo muito curto e bem simplista, na real, o desenvolvimento era realizado por etapas e conversando de forma continua com clientes e analistas. Por vez isso acarretava muitas mudanças e até um vamos tudo de novo!! Portanto, em 99% dos casos, usando essa metodologia, será mais oneroso. Acredito que o TDD é uma boa pratica quando se tens prazos mais confortáveis e boa visão dos requisitos que na prática tá difícil. Porém é uma opinião de quem realmente nunca trabalhou com TDD mas já vi. Logo posso estar errado, ou quem reclamava o fazia porque não sabia bem como funcionava a metodologia.
[quote=fabioEM]Parabéns! Muito Show!
Porém conheço desenvolvedores que sofreram,sofrem e sofrerão bastantes com essa abordagem. Quando trabalhava na BRQ lembro que a especificação chegava sempre com prazo muito curto e bem simplista, na real, o desenvolvimento era realizado por etapas e conversando de forma continua com clientes e analistas. Por vez isso acarretava muitas mudanças e até um vamos tudo de novo!! Portanto, em 99% dos casos, usando essa metodologia, será mais oneroso. Acredito que o TDD é uma boa pratica quando se tens prazos mais confortáveis e boa visão dos requisitos que na prática tá difícil. Porém é uma opinião de quem realmente nunca trabalhou com TDD mas já vi. Logo posso estar errado, ou quem reclamava o fazia porque não sabia bem como funcionava a metodologia.[/quote]
Pensar assim e comum. Afinal de contas, voce escreve mais codigo, e isso requer mais esforco. Porem o uso de TDD faz com que voce diminua o esforco de correcao de bugs a longo prazo, permitindo que voce trabalhe em mais coisas que agreguem valor ao cliente. Quando voce tem esse ganho, amigo, a coisa muda MUITO de figura.
Voce pode ainda aumentar o ganho aliando TDD com outras praticas, como integracao continua, programacao em par e por ai vai.
[quote=fabioEM][quote=LPJava]opa! pessoal,
obrigado pelo comentários e feedback. uhauhhua gostei da associação com Paulo Coelho, porém a diferença é que o Paulo é escritor, nasceu para escrever livros. Já eu, escrevo por hobby, esse ai tá na gaveta desde de 2010 e só em fev para inicio de março que conseguir fechar o último capítulo.
mausexdd: posso conseguir 30% de desconto :). Ainda não temos o valor, pois quem faz esse é a editora. Como sempre vou brigar por um preço acessível.
tnaires: esse é o objetivo, o livro é puramente “seco” em termo de Java, longe dos frameworks que vc citou. A idéia é praticar TDD e exercitar o ciclo e buscar resolver problemas. Dividir o livro em duas partes: Na primeira eu até ajudo os primeiros passos, mas na parte 2, ele vai se virando.
eu aprendi bastante durante esses 2 anos escrevendo, achei que pelo fato de usar no dia-dia seria moleza escrever o livro, mas não foi. Pois, escrever sobre refactoring, TDD etc. Esses assuntos que são abstratos e não tem receita de bolo, não é fácil. Tentar deixar claro para o leitor que nunca é a mesma solução para tudo, que saber dar os passos certos e como dar, é um tremendo desafio. E o melhor, não fazer o cara se sentir um TDD expert só pq leu o meu livro, ou do Kent Beck, que ai é apenas a porta de entrada e uma motivação para quem tá no 0x0.
valeu pessoal,pelo apoio. Assim q for lançado e receber os exemplares, vou sortear um :).[/quote]
Parabéns! Muito Show!
Porém conheço desenvolvedores que sofreram,sofrem e sofrerão bastantes com essa abordagem. Quando trabalhava na BRQ lembro que a especificação chegava sempre com prazo muito curto e bem simplista, na real, o desenvolvimento era realizado por etapas e conversando de forma continua com clientes e analistas. Por vez isso acarretava muitas mudanças e até um vamos tudo de novo!! Portanto, em 99% dos casos, usando essa metodologia, será mais oneroso. Acredito que o TDD é uma boa pratica quando se tens prazos mais confortáveis e boa visão dos requisitos que na prática tá difícil. Porém é uma opinião de quem realmente nunca trabalhou com TDD mas já vi. Logo posso estar errado, ou quem reclamava o fazia porque não sabia bem como funcionava a metodologia.[/quote]
opa! Fábio legal sua opinião. Eu passei por algo parecido. Na verdade o que coloquei no livro nada mais é o que aprendi nos ultimos dois anos com TDD. O ultimo projeto, tinhamos prazos curtos e uma demanda alta e poucos devs, trabalhei sabado, domigo, feriado, dia santo. Bem no inicio deu a ideia que TDD estava sendo oneroso, mas eu achei que tinha algo de errado. E falava: “nao pode ser oneroso, n faz sentindo”. Fui estudar mais, li o livro do Kent Beck umas 3x, motivo? Na minha opinião há muita coisa naquele livro que o Beck não é direto e que só percebemos quando temos um problema e conseguimos entender o que ele quer dizer. Li outros livros, e fui buscando entender meu ambiente com TDD.Dai percebi que no inicio eu:
No inicio fui criticado por outros desenvolvedores do projeto. Dizendo: “Isso é coisa do mundo do Kent Beck e Martin Fowler, só funciona na empresa dele”. fora as piadas. Porém, não respondi as críticas, mas eu pensei comigo: “vou provar que não é”. Moral da história, sofrir bastante no inicio, mas nas entregas eu me sair muito bem. Cada task/item/card que era entregue não tinha bugs de desenvolvimento, quando tinha era falha no analista de requisito, que passou a informação errada e dai tinha que mudar, mas isso ficava claro. Não estou dizendo que TDD não é produzir código sem bugs(ou a bala de prata), não tem relação, na minha opinião. E sim tudo é consequência. Agora os outros colegas que criticaram:
Com TDD eu aprendi:
juntar tudo isso no dia-a-dia com qualidade e baixo número de erros, confesso que não é fácil. Nos próximos 1-2 meses fui convidado para um novo projeto, que tem interesse em usar TDD e outras práticas de desenvolvimento com o objetivo de melhorar a qualidade interna deles. Já estou até ansioso para descobrir o que vou aprender com TDD dessa vez.
[quote=LPJava][quote=fabioEM][quote=LPJava]opa! pessoal,
obrigado pelo comentários e feedback. uhauhhua gostei da associação com Paulo Coelho, porém a diferença é que o Paulo é escritor, nasceu para escrever livros. Já eu, escrevo por hobby, esse ai tá na gaveta desde de 2010 e só em fev para inicio de março que conseguir fechar o último capítulo.
mausexdd: posso conseguir 30% de desconto :). Ainda não temos o valor, pois quem faz esse é a editora. Como sempre vou brigar por um preço acessível.
tnaires: esse é o objetivo, o livro é puramente “seco” em termo de Java, longe dos frameworks que vc citou. A idéia é praticar TDD e exercitar o ciclo e buscar resolver problemas. Dividir o livro em duas partes: Na primeira eu até ajudo os primeiros passos, mas na parte 2, ele vai se virando.
eu aprendi bastante durante esses 2 anos escrevendo, achei que pelo fato de usar no dia-dia seria moleza escrever o livro, mas não foi. Pois, escrever sobre refactoring, TDD etc. Esses assuntos que são abstratos e não tem receita de bolo, não é fácil. Tentar deixar claro para o leitor que nunca é a mesma solução para tudo, que saber dar os passos certos e como dar, é um tremendo desafio. E o melhor, não fazer o cara se sentir um TDD expert só pq leu o meu livro, ou do Kent Beck, que ai é apenas a porta de entrada e uma motivação para quem tá no 0x0.
valeu pessoal,pelo apoio. Assim q for lançado e receber os exemplares, vou sortear um :).[/quote]
Parabéns! Muito Show!
Porém conheço desenvolvedores que sofreram,sofrem e sofrerão bastantes com essa abordagem. Quando trabalhava na BRQ lembro que a especificação chegava sempre com prazo muito curto e bem simplista, na real, o desenvolvimento era realizado por etapas e conversando de forma continua com clientes e analistas. Por vez isso acarretava muitas mudanças e até um vamos tudo de novo!! Portanto, em 99% dos casos, usando essa metodologia, será mais oneroso. Acredito que o TDD é uma boa pratica quando se tens prazos mais confortáveis e boa visão dos requisitos que na prática tá difícil. Porém é uma opinião de quem realmente nunca trabalhou com TDD mas já vi. Logo posso estar errado, ou quem reclamava o fazia porque não sabia bem como funcionava a metodologia.[/quote]
opa! Fábio legal sua opinião. Eu passei por algo parecido. Na verdade o que coloquei no livro nada mais é o que aprendi nos ultimos dois anos com TDD. O ultimo projeto, tinhamos prazos curtos e uma demanda alta e poucos devs, trabalhei sabado, domigo, feriado, dia santo. Bem no inicio deu a ideia que TDD estava sendo oneroso, mas eu achei que tinha algo de errado. E falava: “nao pode ser oneroso, n faz sentindo”. Fui estudar mais, li o livro do Kent Beck umas 3x, motivo? Na minha opinião há muita coisa naquele livro que o Beck não é direto e que só percebemos quando temos um problema e conseguimos entender o que ele quer dizer. Li outros livros, e fui buscando entender meu ambiente com TDD.Dai percebi que no inicio eu:
No inicio fui criticado por outros desenvolvedores do projeto. Dizendo: “Isso é coisa do mundo do Kent Beck e Martin Fowler, só funciona na empresa dele”. fora as piadas. Porém, não respondi as críticas, mas eu pensei comigo: “vou provar que não é”. Moral da história, sofrir bastante no inicio, mas nas entregas eu me sair muito bem. Cada task/item/card que era entregue não tinha bugs de desenvolvimento, quando tinha era falha no analista de requisito, que passou a informação errada e dai tinha que mudar, mas isso ficava claro. Não estou dizendo que TDD não é produzir código sem bugs(ou a bala de prata), não tem relação, na minha opinião. E sim tudo é consequência. Agora os outros colegas que criticaram:
Com TDD eu aprendi:
juntar tudo isso no dia-a-dia com qualidade e baixo número de erros, confesso que não é fácil. Nos próximos 1-2 meses fui convidado para um novo projeto, que tem interesse em usar TDD e outras práticas de desenvolvimento com o objetivo de melhorar a qualidade interna deles. Já estou até ansioso para descobrir o que vou aprender com TDD dessa vez. :)[/quote]
Legal e bem argumentado! Se tivesse um curtir, teria curtido :lol:
O que me mataz o TDD eh q uso ejb 3.1 
, todas solucoes para teste usando este framework sao pela metade Alguem ai tem alguma sugestao que tenha usado ?
O livro parece bem interessante, já está definido o valor do livro?
Muito bom, excelente idéia. Aguardo ansioso o lançamento para poder me aprofundar em TDD.
ainda não foi definido o valor do livro. O preço é formado apenas quando o livro vai para gráfica, algo que deve acontecer até o final do mês de maio.
ainda não foi definido o valor do livro. O preço é formado apenas quando o livro vai para gráfica, algo que deve acontecer até o final do mês de maio. [/quote]
[size=24]; -)[/size] , comprei o livro da Caelum é não gostei, espero que esse faça melhor sucesso …