| Autor |
Mensagem |
|
|
TDD para praticantes de XP não é opcional.
http://www.extremeprogramming.org/rules/testfirst.html
Eu faço TDD e digo que pode sim ser aplicado com qualquer metodologia.
|
 |
|
|
Posso não ter entendido muito bem, mas será que vc nesse caso não poderia mockear toda a sua camada DAO?
Se o que vc precisa é testar a sua regra de negócio, isso deve estar acima do acesso ao banco, logo, acima da sua camada DAO.
Eu trabalho bastante com o mockito(.org) nesses casos.
Só quando eu tenho que testar queries* e acesso a banco, eu uso dbunit pra colocar os dados que eu preciso na base.
* Sim, por incrível que pareça, em 2009 ainda tem empresa que insiste em começar projetos novos com acesso a banco de dados e SQL na unha.
|
|
|
|
Documentação nenhuma garante que o sistema funcione, testes sim.
SCRUM não é só para projetos pequenos.
|
|
|
|
Só para acrescentar informações a respeito do problema, existe um bug aberto:
http://jasperforge.org/sf/go/artf2423?nav=1
|
|
|
|
Ah, vc tá usando swing application framework.
Estranho, eu estou só começando nele, mas vc não precisaria centralizar os Frames, ele já faz isso.
Se vc olhar no fonte da classe SingleFrameApplication vc vai ver ele centralizar o Frame no método initRootPaneContainer.
|
|
|
|
É importante dar uma procurada no forum antes de postar uma dúvida, pode ser que já tenham perguntado por isso.
http://www.guj.com.br/posts/list/80297.java#426519
abraço
|
|
|
|
Pra exemplificar melhor, se vcs estão usando o netbeans eu imagino que as telas às quais vcs se referem são JFrames.
Nesse caso bastaria colocar no construtor desses JFrames, após a linha initComponents(), setLocationRelativeTo(null);
abraço.
|
|
|
|
Saudações Victor,
Faz tempo que eu tenho esse problema, dá uma olhada nesse bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6181488
Tem a ver com a forma que o java lista as impressoras no linux usando o comando lpc e outros.
Em umas versões anteriores do cups, instalando o pacote cupsys-bsd no linux eu consegui fazer funcionar o lpc da forma que o java conseguisse pegar a lista das impressoras configuradas no cups.
Mas na versão do cups que eu uso atualmente 1.3.5-1 esse problema voltou a acontecer. O java não consegue listar as impressoras instaladas e configuradas no cups.
Faz tempo que eu não procuro nada sobre esse problema, pode ser que já exista alguma solução por aí na net.
Com essas informações vc já deve saber ± o que procurar, se achar alguma solução posta pra gente pq eu também preciso 
abraço
|
|
|
|
setLocationRelativeTo(null);
Serve para qualquer um que "extends" de Window.
|
|
|
|
Já usei speedy por muitos anos, o problema dele é o upload, antigamente era só 128, isso me matava, agora melhorou, tá com 256... hahahahha
To com o virtua 2mb há alguns meses, eu acho bom o serviço, pra não dizer que nunca ficou fora do ar, ficou ontem durante 2 horas, mas no geral é bom.
|
|
|
|
Parabéns cara, muito bom.
Agora que vc já tem essa pensa nas próximas, vão te dar um bom diferencial.
|
|
|
|
Valeu, mas não rolou não.
Nem trocando o keymap para Eclipse. Também não funcionou com keymap Netbeans.
|
|
|
|
Alguém sabe como ficou no netbeans 6 para gerar automaticamente o javadoc de um método?
No netbeans 5.5 tinha um editor de javadoc que até adicionava as tags que estavam faltando. Agora no 6 não achei mais essa opção.
Procurei no wiki do netbeans, o mais próximo que eu cheguei foram esses dois links
http://wiki.netbeans.org/wiki/view/EclipseMapping
http://wiki.netbeans.org/wiki/view/CorrectJavadoc
mas esse Alt+Shift+J não funcionou nem trocando o key mapping para o do eclipse.
eu só queria que num método
ele me gerasse o esqueleto do javadoc
|
|
|
|
Saudações saoj,
No começo também usávamos aqui alguma coisa bem parecida com a forma que o MentaBeans para facilitar na persistência. Classe para gerar slq automático pegando os atributos e os valores do objeto por reflection, executando bem fácil um update com uma simples chamada de método .atualizar(). Foi bem produtivo no começo do projeto, pois era rápido pra desenvolver o código.
Mas depois de cair em um problema, o de busca de coleções, desistimos desse nosso framework e passamos a usar hibernate, pois tinha inúmeras vantagens, transações e busca ávida de coleções eram algumas dessas vantagens.
Eu acho que o hibernate se propoe a fazer o que vc pretende com o MentaBeans de uma maneira mais simples, (estou deixando de lado o fato do MentaBenas ter acabado de nascer), mas que a sua idéia não é ruim, só acho que o seu esforço poderia ser aplicado a uma necessidade específica que o hibernate não venha a cobrir.
Por exemplo, buscar avidamente mais de uma coleção do mesmo objeto. O hibernate não monta um grafo de um objeto que tenha duas coleções. O hibernate usa um outer join para preencher apenas uma das coleções as outras precisam ser inicializadas um um select extra ou busca preguiçosa. (pelo menos era assim na época que eu li o livro hibernate em ação).
Se vc implementasse uma busca que ele fosse capaz de trazer um objeto e todas as suas coleções, vc ainda poderia utilizar uma sessão de hibernate e persistir as alterações desse objeto e suas coleções automaticamente.
É apenas um exemplo, não sei se existiria uma necessidade real para isso.
Acho que vc poderia concentrar seus esforços pra tentar preencher as lacunas do hibernate e outros frameworks de persistência, assim o MentaBeans associado à outros frameworks de persistência cobriria praticamente todas as necessidades de persistência.
IMHO
|
|
|
|
Vou acompanhar seu tópico, pois tenho a mesma dificuldade.
Quando ao jformattedfield, use o método setValue().
Abraço
|
|
|
|