| Autor |
Mensagem |
|
|
Pelo que eu entendi, não é essa a dúvida do colega. Ele quer saber se é melhor incrementar algum campo no banco toda vez que tiver um acesso ou fazer "select count(*) from acessos" sempre que quiser saber a quantidade de acessos.
Se você for precisar desse dado muitas vezes, é melhor tê-la guardada em algum campo e só consultar essa informação. Mas se for uma vez perdida, faz o count(*) mesmo.
|
 |
|
|
jack_-_ganzha wrote:Usei pair programming para testar as ultimas pessoas que entrevistei, mas com problemas mais proximos do dia-a-dia. O que vcs acham desse tipo de avaliação?
A menos que o candidato tenha aquele bafinho de onça, é uma boa. 
|
|
|
|
|
Verifique se no console da aplicação está sendo exibido a stacktrace de alguma exceção que pode ter sido lançada. Você já verificou se o jasper está realmente pegando o conteúdo da lista (ou seja, chamando o método getListAssunto())? E se essa lista não está vazia?
|
|
|
|
O ideal é usar qualquer framework que não seja o Struts.
VRaptor, Mentawai, WebWork, Seam, etc...
|
|
|
|
Não é necessário usar a API inteira da Java SE para poder dizer que programa em Java. Portanto, eu não acho que precise usar todas as funcionalidades de Java EE para que você se considere programando em Java EE. Pra mim, usar Servlets e JSP é Java EE sim. Assim como um código com alguns IFs, System.outs, etc continua sendo Java. Até por que se fosse necessário conhecer tudo da especificação, o GUJ teria no máximo 10 pessoas que conhecem Java EE...
immortalSoul wrote:nao entendo porque jogam tanta pedra nos sigletons 
Uma busca aqui no fórum e você vai entender! Tem um monte de tópico sobre isso. 
|
|
|
|
|
A exceção é lançada quando se tenta usar a classe que está faltando. Uma solução é capturar a NoClassDefFoundException, que é a exceção lançada quando não se acha determinada classe (típico erro de jar não encontrado).
|
|
|
|
Que maldade. 
|
|
|
|
Rezo todos os dias para que papai do céu olhe com bastante carinho para aqueles que usam SQL em Java e não usam Prepared Statement. 
|
|
|
|
saoj wrote:...
Isso é gambiarra, na minha opinião. Depois de um tempo, o código estaria cheio de IFs que ninguém sabe ao certo pra que serve, colocados lá só para ser uma garantia mandrake de backward compatibility. Parece mais medo de mexer no códigos dos outros.
Interessante, se você procurar sobre programação orientada a gambiarras em sites do Wikipedia ou Desciclopedia, eles falam que isso é técnica de POG. Se você não sabe o porquê daquele código existir, coloca um IF e deixa ele lá. Se funciona, tá ótimo.
|
|
|
|
saoj wrote:O cara tem a experiencia prática, e isso ao meu ver vale muito mais do que qualque experiencia teórica.
E quem perguntou sobre prática ou teórica? Eu perguntei se ele conhecia testes unitários, minha pergunta não foi se ele já havia lido determinado livro. Pode se conhecer determinado assunto de vários modos e a minha impressão é que ele não conhecia muito bem em nenhum deles (algo que, aliás, ele até admitiu).
Eu só acho que é bastante chato discutir com quem nem sequer procurou estudar o tema que está argumentando (assim como foi discutir com você sobre Hibernate, quando você nunca tinha usado o framework).
Por isso que estou aconselhando que procurem a ler, testar do modo certo (e não do modo que acham que é) e usar, pra depois argumentar.
Do mesmo jeito que você não gosta quando alguém fala do Mentawai sem ter testado, é igualmente irritante quando vemos vocês falando de T.U. e TDD sem nunca ter usado (nem estudado).
|
|
|
|
eduveks, você realmente conhece testes unitários, tdd, etc.? Ou está falando isso baseado apenas em um tutorial de JUnit que leu? Sinceramente, parece muito que você tá falando de algo que não conhece!
Dá pra argumentar a favor de testes unitários usando exatamente as mesmas palavras que você tá usando. Isso é sinal de que você tá argumentando sem conhecer...
|
|
|
|
|
Eu uso o tópicos recentes: http://www.guj.com.br/recentTopics/list.java
|
|
|
|
eduveks wrote:Exatamente, citei este exemplo para depois combater, a resposta que dariam e ir mais pra prática em vez da teoria...
...?
eduveks wrote:Então vamos lá, seguindo a tua ideia, o teste vai ter q ser ajustado a mão para fazer o teste deste método certo? E vc vai lembrar de fazer este ajuste? E vai ter certeza que o teste esta bem configurado? Em uma aplicação peguena, isto é simples, mas numa aplicação de grande porte, seria um tempo muito precioso, perdido nisto, aumento o custo do projeto.
Então você está dizendo que testes são perda de tempo? Hum.
A qualidade de um bom programador pode ser medida pela sua capacidade de escrever testes que avaliem o código de modo satisfatórios.
E acredite, escrever testes não gasta tanto tempo assim.
eduveks wrote:Vc não acha que a melhor forma de testar isto, é no formulário colocar um número negativo e clicar em gravar, e ai se aceitar, aproveita para reportar um bug, e diz para corrigir no método e também colocar uma validação no formulário, não é muito mais simples?
Agora você está falando de projeto de que porte? Pq no parágrafo anterior você estava preocupado com projetos de grande porte e agora vem com essa, de que o melhor modo de testar é na mãozona ou no velho PSVM.
Isso pode funcionar pra crud de 10 campos... mas, como já disse, precisamos de um pouco mais de garantias do que isso. 
eduveks wrote:E não iriamos ter que fazer isto? Ou vc confia tanto assim em testes unitários?
Confio. Bem mais do que o programador ter que ficar testando formulário. Além do fato de que eu não só macaco que escreve código e que passa o dia só escrevendo formulário, graças a deus.
Continuo achando que você conhece muito pouco do assunto. Dá uma lida, na boa...
|
|
|
|
eduveks wrote:Imagina vc tem um método para fazer adição monetária, onde é proibido números negativos, e recebe um valor negativo e funciona, os testes unitários não vao detectar este bug, e o novo programador q ta fazendo merda, não vai ser testes unitários que vai te ajudar a descobrir este bug.
Esse é o típico caso de utilidade para testes unitários (verificar se o método está checando a validade de parâmetros) e eles funcionam muito bem, obrigado, nessas situações.
Com um teste de unidade razoável implementado para esse método, você tem certeza que ele nunca vai aceitar números negativos, mesmo depois de mexer no código da classe. Quer garantia melhor que essa? Ou você prefere ter que ir na "mãozona" e testar todo o tipo de combinação da parâmetros e ver se o método continua funcionando? Acho que a maioria de nós precisa de mais garantias que não quebrou nada no código, ao fazer uma alteração.
Definitivamente, você deveria conhecer melhor testes untiários antes de tentar argumentar alguma coisa contra eles por aqui. Ou, pelo menos, melhorar os exemplos.
|
|
|
|
cv wrote:Nao disse que futebol eh coisa so de brasileiro. Mas que o Brasil eh provavelmente o unico pais onde instituicoes como a CBF mandam mais que o Ministerio da Cultura, eh
Até o Ministério da Magia manda mais do que o Ministério da Cultura aqui no Brasil.
|
|
|
|