| Autor |
Mensagem |
|
|
|
bean será um bean. POJO. No JSF o ideal é tu ter o teu ManagedBean que é o controller. Se tu passa essa responsabilidade para o bean, infelizmente não tá fazendo no modelo ideal. evidente que vai funcionar, mas não é a melhor opção.
|
 |
|
|
|
isso é um pé no saco mesmo. Eu normalmente clico com o botão direito no tomcat ali no eclipse e escolho clean. E em seguida dou um refresh na página pra ver.
|
|
|
|
|
tem dia que recebo e outros não.
|
|
|
|
alias wrote:
Leozin wrote:Camilo é o nosso Paulo Coelho do GUJ!
Parabéns pelo livro!
Abração!
Hm, como nem o Paulo Coelho é unanimidade, vou destoar um pouco, com todo o respeito ao autor que é nosso colega de fórum. Adoro TDD e gostaria muito de comprar o livro, mas quando estava estudando pra certificação OCJP comprei o livro do Camilo e achei o livro muito ruim, mal escrito, mal revisado, e muito fraco tecnicamente. Novamente, com todo o respeito ao autor, sobre o qual não tenho nada a comentar, mas essa foi a minha opinião sobre a obra.
Como TDD é um assunto que me interessa bastante, o livro até me interessa, mas dado esse histórico...no blog será disponibilizado um "preview"?
alias obrigado por trazer esse comentário(nem eu gosto dos livros do Paulo Coelho  ). Gosto de ouvi-los. Apesar que tenho recebido quase 0, pois os emails dos leitores do meu primeiro livro, todos que recebi foram positivos, e há até posts aqui no no guj recomendando, mas isso é muito pessoal e vai de cada um. Há livros que eu tb já comprei que odiei, mas um colega do lado adorou. Eu tenho que concordar com você que a revisão poderia ter sido melhor, mas para aquele livro sair foi mais que um parto 2 anos trabalhando sozinho, a editora se envolveu apenas 6 meses perto da publicação.Enfim, foi muito estresse entre eu e a editora na época.E agora todo projeto eu imprimo ele antes e leio como se fosse o leitor (é dificil por estar envolvido há meses com o conteúdo), faço as revisões, contrato uma revisora à parte e depois mando para editora, para q eles façam a revisão deles. Há muitas coisas no mundo editorial aqui no Brasil que não posso comentar, mas é o que temos infelizmente. Já participei de revisão de uma editora fora do país, e lá as coisas são bem diferentes e bem melhor. E sobre a parte técnica do livro SCJP, eu sou suspeito, mas eu digo sempre que é importante alinhar o conteúdo técnico com o objetivo do livro. O mesmo para o livro de TDD, ele é para quem é iniciante ou nunca brincou com a técnica. Se o cara já "macaco velho". É como eu digo no livro "não compre". Assim que receber a versão final do livro por parte da editora, estarei disponibilizando alguns capítulos.
flw.
|
|
|
|
|
se vai ser NUll ou 0, é com base no tipo certo? Agora uma pergunta: Pq o hibernate teria que se preocupar com o valor armazenado ? qual a diferença entre NULL e qualquer outra coisa para o Hibernate?
|
|
|
|
|
use workbench.
|
|
|
|
matheuslmota wrote:
entanglement wrote:Você sabe o que é a variável de ambiente PATH no Windows?
Já mexeu com linha de comando (Command Prompt)?
Sabe o que ocorre quando você digita "dir" no DOS?
É a única coisa que você precisará saber (eu acrescentaria também, ao rodar o instalador, mudar o diretório padrão c:\Arquivos de Programas\Java\JDK1.7_03 para um outro mais simples e sem espaços no nome, como C:\JDK1.7.0 )
Engraçado entanglement, essa semana instalei o jdk e o eclipse em uma máquina Windows 7 de um amigo que começou à se aventurar no mundo Java. Estranhamente eu apenas instalei o JDK e não configurei variável de ambiente nenhuma, o Eclipse reconheceu o JDK automaticamente. Será que o Eclipse olha para o registro do Windows pra procurar alguma chave corresponedente ao diretório de instalação do Java? Pra tirar a prova dos nove, ao digitar javac no prompt do DOS, o programa não foi reconhecido (embora o comando java tenha sido reconhecido). Sabe dizer algo à respeito?
eu tenho instalado aqui sem configurar as variaveis de ambiente. Não é preciso para que funcione no Eclipse, mas se tu for rodar por fora e mandar compilar no prompt de comando do windows ai tu precisa.
|
|
|
|
a mesma coisa que nas versões anteriores.
http://camilolopes.wordpress.com/2008/03/27/instalando-java-em-ambiente-windows-5-minutes/
|
|
|
|
|
dar uma olhada: http://camilolopes.wordpress.com/2008/04/18/iniciandoqual-livro/
|
|
|
|
olá Jonas,
o livro da Caelum tem um objetivo X. O meu tem um objetivo Y. Então são completamente diferentes, não há relação entre eles.
O meu é focado mesmo, em quem nunca fez TDD na vida e quer pelo menos sair do 0x0 de forma prática. É tanto que a parte de teoria no livro, limitei ao que todo desenvolvedor deve saber no minimo. Se o cara que se aprofundar mais em teoria, entender bem detalhado, ai tem que ver outras referência no mercado que é focado nesse ponto. Eu fiz isso, pq não sou fã de teoria, gosto de ter uma boa base teórica, mas não ficar mergulhado nela. Senão eu fico louco . Necessito praticar e ver a coisa funcionando e alinhar com o que eu li.
|
|
|
|
pedrogf89 wrote:O livro parece bem interessante, já está definido o valor do livro?
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.
|
|
|
|
|
as classes estão mapeadas no arquivo do hibernate?
|
|
|
|
fabioEM wrote:
LPJava wrote: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 .
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.
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:
- não tinha o entendimento da técnica de TDD;
- que não era só criar unit test primeiro, TDD está envolvido com o Design tb e diretamente. Não se separa os dois. Na verdade o design da solução vinha do TDD;
- não sabia onde focar e gastava tempo demais com detalhes que não era importante, para meu ego como desenvolvedor era ideal eu ter mais tempo para poder testar, rodar todo ciclo TDD, mas para o ego do meu PM isso é custo;
- eu teria que ser persistente e não desistir;
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:
- nao conseguiam entregar dentro do prazo que estimou;
- e o velho ditado: "o código tá feito, só falta testar";
- unit test com baixa qualidade(isso quando eles conseguiam fazer);
- a quantidade de bugs que abriam para task/item era grande;
Com TDD eu aprendi:
- ser mais ágil no desenvolvimento;
- fazer entregar mais rápidas;
- melhorar minhas estimativas;
- buscar ter um código de qualidade;
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.
|
|
|
|
|
colocar o código que ajuda entender o que tu tá passando.
|
|
|
|
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 .
|
|
|
|
|
|