MundoJava 38 - Boas Práticas Java EE - Acerte na sua escolha!

Leonardo3001 wrote:Vai ter "jotassefista" botando meu nome na boca do sapo, mas achei muito estranho os 10 maus hábitos. A impressão que tenho é que os 10 maus hábitos está para o JSF assim como o Core J2EE Patterns está para o EJB: Joga a culpa dum framework problemático nas costas dos desenvolvedores (que, supostamente, não sabe usar os padrões estabelecidos), ao invés de admitir que o problema está no próprio design.

Veja, fui um desenvolvedor JSF por muito tempo, e hoje desenvolvo um site em VRaptor. E não penso nem meia vez ao recomendar este ao invés daquele. E porque? Porque nunca ouvi falar em maus hábitos dos desenvolvedores VRaptor. Porque não há reinvenção da roda. E todos aqueles padrões comumente encontrados no desenvolvimento web são benvindos no VRaptor, não apenas "maus hábitos".

E não me venha dizer que JSF é melhor para aplicações em workflow ou com estado persistente na página, isso é melhor resolvido com JQuery e afins (aliás, os melhores sites "stateful" são feitos em Javascript, não JSF). "Ah não! Javascript é complicado e não funciona no IE!" Paciência, aprenda!

"Jotassefistas" de carteirinha, agora podem jogar tomates. Não vou treplicar o meu comentário.

Entao la vai o primeiro tomate podre!! hehe brincadeiras a parte, não ha o que argumentar, ja é sabida de todos no forum a sua paixao por action based, e a sua birra por component based, entao: Contra gosto não ha argumentos!

This message was edited 1 time. Last update was at 20/11/2009 00:49:59

sergiotaborda wrote:O artigo explica rápidamente pontos de funçao e pontos de caso de uso

a respeito deste artigo, visto que ainda não o li, mas sobre métricas, fico imaginando até quando iremos precisar de tantas especificações funcionais/não-funcionais, casos de usos, diagramas UML, ou seja, até quando precisaremos de analistas ?

acho que se cortarem os analistas e/ou transformarem em desenvolvedores, de forma a ter uma equipe uniforme e que todos tivessem quase o mesmo nível de conhecimento, não nos preocuparíamos tanto assim com métricas, seja no setor público ou privado.

(bem foi um pequeno desabafo)

faelcavalcanti wrote:

sergiotaborda wrote:O artigo explica rápidamente pontos de funçao e pontos de caso de uso

a respeito deste artigo, visto que ainda não o li, mas sobre métricas, fico imaginando até quando iremos precisar de tantas especificações funcionais/não-funcionais, casos de usos, diagramas UML, ou seja, até quando precisaremos de analistas ?

acho que se cortarem os analistas e/ou transformarem em desenvolvedores, de forma a ter uma equipe uniforme e que todos tivessem quase o mesmo nível de conhecimento, não nos preocuparíamos tanto assim com métricas, seja no setor público ou privado.

(bem foi um pequeno desabafo)

Entao, supondo empresa privada, o que vai dizer ao seu cliente quando ele perguntar "em quanto tempo fica pronto?"??? E logo em seguida quando ele tambem perguntar "quanto vai custar? baseado em que?"??

Ta certo que algumas coisas enchem, mas as coisas estao ali por algum motivo.

fredferrao wrote:Entao, supondo empresa privada, o que vai dizer ao seu cliente quando ele perguntar "em quanto tempo fica pronto?"??? E logo em seguida quando ele tambem perguntar "quanto vai custar? baseado em que?"??

Ta certo que algumas coisas enchem, mas as coisas estao ali por algum motivo.

este tipo de metrica, em ponto de funcao e caso de uso, me incomoda faz bom tempo, não vejo muito valor, a não ser que me digam o contrário, então não vejo também motivação, a não ser um motivo para se por um fim nisto.

como falei, não li o artigo sobre métricas, mas agora vou antecipar esta leitura.

Ok. Ainda referente a materia dos 10 maus habitos o mau habito 3 referente ao acesso a metodos expostos. O exemplo utilizado pelo dataTable. Vi que esse mal hábito se enquadrou da forma que utilizo para paginar tabelas. Sempre que pagino uma tabela tenho q acessar o metodo getDadosDaTabela que faz uma consulta ao banco de dados. Nesse caso achei a solução valida. Porem nao achei ela adequada para resolver a paginação de tabelas ou pelo menos não ficou de forma implícita.

Minha opnião.

Java Ninja Membro desde: 04/04/2007 19:21:36 Mensagens: 268 Offline

A questão é que não se trada de 10 maus hábitos e sim de uma deficiência do JSF. É querer colocar uma cereja num bolo queimado, entende?

JavaEvangelist Membro desde: 21/11/2004 16:40:00 Mensagens: 424 Offline

Quais seriam essas deficiências?
Acho que seria saudável a todos se vc comentasse algumas. Seria bom para o fórum, para os desenvolvedores Web e até para a revista mundo Java, que poderia ter conteúdo para uma futura matéria justamente sobre as deficiência do JSF.

Na minha opinião, o que falta no JSF é flexibilidade. Quando vc não tem o que vc quer nas bibliotecas prontas, é bem custoso implementar.
Pelo que eu vi JSF 2.0 isso melhora um pouco, mas não faz milagres.

Thread.start() Membro desde: 09/11/2009 13:46:06 Mensagens: 44 Offline

fredferrao wrote:
Só nao podemos esquecer o nome da revista: Mundo JAVA

Uma coisa é falar de linguagens que rodam nao VM como scala, groovy, agora sair totalmente do contexto ja não da.

Nao se chama Mundo TI.

Uma coisa é falar sobre Java, outra coisa é transformar uma revista em especificação que cerca a tecnologia, existem outras informações tão úteis no mundo Open Source e simplesmente não são trazidas aqui para uma nova descoberta ou horizonte, java é a herança para todas as novas tendencias desse mundo novo e que se extendeu para a WEB 2.0.

Comprei agora pouco minha revista e achei muito boa.

Primeiro pela aparência, pois o código não pode apenas funcionar, tem que ser bonito. E a revista está muito bonita, bem editada, sem erros de ortografia e muito bem organizada. Parabéns.

O primeiro artigo que lí foi do vraptor3. Parabéns ao Lucas e Adriano, o artigo está excelente. O texto foi na medida certa, e vale a pena a leitura de cada linha, mesmo para os que conhecem o framework, como no meu caso. Temos muitos frameworks e utilitários brasileiros, seria mesmo interessante ter seguidamente alguns artigos sobre algum, mesmo que pequeno. Ajuda não apenas incentivar o uso, mas também para apresentar para quem não conhece.

O Artigo sobre eventos JPA, embora eu lí por cima, está muito bom também. Mesmo trabalhando há muitos anos com JPA agregou muita informação.

Gostei também sobre o AdWords, mesmo que eu não use e nem tenha interesse em usar em minhas apps. Será que rola novos artigos sobre as APIs do Google em próximas edições?

Enfim, a revista desse mês, na minha opinião, foi um bom investimento. Valeu Guerra :thumbup:

Onde encontrar a revista?

No site diz as cidades que tem revista, porem passei em algumas bancas e nao encontrei, teria uma lista de bancas?

fredferrao wrote:Entao, supondo empresa privada, o que vai dizer ao seu cliente quando ele perguntar "em quanto tempo fica pronto?"??? E logo em seguida quando ele tambem perguntar "quanto vai custar? baseado em que?"??

Legal dar uma olhada neste livro.

fredferrao wrote:Ta certo que algumas coisas enchem, mas as coisas estao ali por algum motivo.

Algumas destas coisas (pontos por função, analistas de sistemas e outros cacarecos) TIVERAM um motivo, outras nem isso.

Rodrigo Manhães wrote:

fredferrao wrote:Entao, supondo empresa privada, o que vai dizer ao seu cliente quando ele perguntar "em quanto tempo fica pronto?"??? E logo em seguida quando ele tambem perguntar "quanto vai custar? baseado em que?"??

Legal dar uma olhada neste livro.

fredferrao wrote:Ta certo que algumas coisas enchem, mas as coisas estao ali por algum motivo.

Algumas destas coisas (pontos por função, analistas de sistemas e outros cacarecos) TIVERAM um motivo, outras nem isso.

Certo e isso nao se encaixa em METRICAS??? Veja bem que nao citei qualquer ferramenta ou metodo especifico em si! E repliquei o faelcavalcanti que disse estar cansado de metricas, AGIL ou nao, ainda são metricas, sao maneiras de medir coisas, neste caso devenvolvimento de software.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

fredferrao wrote:

faelcavalcanti wrote:

sergiotaborda wrote:O artigo explica rápidamente pontos de funçao e pontos de caso de uso

a respeito deste artigo, visto que ainda não o li, mas sobre métricas, fico imaginando até quando iremos precisar de tantas especificações funcionais/não-funcionais, casos de usos, diagramas UML, ou seja, até quando precisaremos de analistas ?

acho que se cortarem os analistas e/ou transformarem em desenvolvedores, de forma a ter uma equipe uniforme e que todos tivessem quase o mesmo nível de conhecimento, não nos preocuparíamos tanto assim com métricas, seja no setor público ou privado.

(bem foi um pequeno desabafo)

Entao, supondo empresa privada, o que vai dizer ao seu cliente quando ele perguntar "em quanto tempo fica pronto?"??? E logo em seguida quando ele tambem perguntar "quanto vai custar? baseado em que?"??

Este é um erro comum. A primeira coisa a fazer quando se é perguntado por "em quanto tempo fica pronto" é :"para quando precisa?" Se o cara dá uma data vc tem um projeto de prazo fixo. Se ele não dá uma data, vc pergunta "Quanto quer gastar ?" e tem um projeto de preço fixo. Veja que preço e custo são coisas diferentes. Se o cara responde que não tem prazo nem orçamento então ele está interessando em ter o máximo de funcionalidades. então ai vc pergunta : "quais funcionalidades têm maior prioridade?"

Repare que as métricas não servem para responder aos clientes e sim para que a "gerencia" e o comercial tenha uma ideia de quanto pedir pelo software quando o cara perguntar :"quanto custa". Veja que é comum o comercial negociar o preço, mas isso é normalmente feito da forma errada porque o custo é chutado pelas métricas e não avalidado concretamente pelas equipas. O comercial vende o software com base no que o cliente pode/está disposto a pagar e não pelas features. O input dos desenvolvedores não existe, e acaba que o projeto estoura prazos e custos. O triangulo de projeto não mente, mas muitas software houses não cansam de tentar driblá-lo.

Métricas são uma forma pobre e preguiçosa e até timida (porque a empresa tem medo de falar com o cliente) de tentar resolver um problema que é estimar. Agil em geral e Scrum em particular tem outra prespetiva. Tanto o cliente como os desenvolvedores devem ser consultados. Riscos devem ser avaliados. O tempo de alocação deve ser considerado, assim como o prazo esperado pelo cliente.

O ideal é que , quando o cliente não estabelece um prazo ou um custo, o projeto seja dividido em releases. Isto força um prazo e isso ajuda no planejamento e permite ao cliente decidir o rumo do software. Em vez de um prototipo, faz uma versão funcional com o mínimo de features e usa reuniões de fim de sprint para direcionar os requisitos. é muito comum que o cliente tenha a capacidade de abstração de uma ameba e que depois de ver a coisa funcionando na frente dele mude de opinião.

Pontos de função ou pontos de caso de uso são falhos. E a razão é simples : se baseiam numa pseudo teoria que nunca foi confirmada. enquanto que planning poker e outras metodologia ageis se baseiam na opinião real de quem vai fazer a coisa existir, se baseiam em consenso e não em autoridade e por conseguinte isso significa que faz nascer uma responsabilidade dos desenvovedore so que os levará a falar numeros honestos.

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 521 Offline

Não sei se vocês perceberam mas o nome dessa nova coluna é "Provocação Digital", ou seja, o objetivo é levantar discussões a respeito de temas gerando uma reflexão a respeito deles por parte do leitor. Pelos posts que foram gerados acho que o objetivo está sendo atingido!

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Guerr@ wrote:Não sei se vocês perceberam mas o nome dessa nova coluna é "Provocação Digital", ou seja, o objetivo é levantar discussões a respeito de temas gerando uma reflexão a respeito deles por parte do leitor. Pelos posts que foram gerados acho que o objetivo está sendo atingido!

O objetivo é muito ruim sendo que a revista é one-way-only.
Mas o principal problema é que o artigo é baseado em mentiras. Isso me faz pensar se os PF e os PCU realmente se calculam daquela forma. Ou seja, a credebilidade foi pro saco. Além disso se é provocação, o titulo deve ser uma pergunta e o texto deve ser uma suposta resposta. algo do tipo "Você usaria métricas ?" e depois responder. O texto que explica as métricas poderia ser todo um side-box.
O problema é este. todo o texto é o side-box e o core não está lá.

Notícias, artigos e o maior fórum brasileiro sobre Java