Como ser um maluco da contra-cultura

[quote=asaudate][quote=saoj][quote=Rubem Azenha]
Parabéns Sérgio! Você elevou o desenvolvimento Java a um outro patamar :slight_smile:
[/quote]

Obrigado, Rubem! Sei que vc tb gosta do Maker, pois vc não precisa fazer quase nada para colocar uma aplicação web rodando. Bem menos código para vc cansar os seus dedos digitando.[/quote]

Também não precisa chutar o balde. O caso é que, de fato, se você aprende a usar a ferramenta corretamente (e tenho certeza que esse é o ponto onde o Rubem quer chegar) é muito mais produtivo do que ter que reinventar a roda a cada programa feito.

[]´s[/quote]

Recomendo aprender o Maker. Ou VisualBasic. Não precisa reinventar a roda. Digita muito pouco também. ColdFusion tb é uma boa.

[quote=saoj][quote=asaudate][quote=saoj][quote=Rubem Azenha]
Parabéns Sérgio! Você elevou o desenvolvimento Java a um outro patamar :slight_smile:
[/quote]

Obrigado, Rubem! Sei que vc tb gosta do Maker, pois vc não precisa fazer quase nada para colocar uma aplicação web rodando. Bem menos código para vc cansar os seus dedos digitando.[/quote]

Também não precisa chutar o balde. O caso é que, de fato, se você aprende a usar a ferramenta corretamente (e tenho certeza que esse é o ponto onde o Rubem quer chegar) é muito mais produtivo do que ter que reinventar a roda a cada programa feito.

[]´s[/quote]

Recomendo aprender o Maker. Ou VisualBasic. Não precisa reinventar a roda. Digita muito pouco também. ColdFusion tb é uma boa.[/quote]

Eu já fui programador VB =P

Ah, e por falar nisso… você reparou que nenhum dos três que você citou têm o mesmo propósito?? Por isso que eu digo: saber o propósito também é importante!!

Bom, já que a conversa afunilou para frameworks…

Sempre pensei que a utilização de frameworks era para facilitar a vida do programador e não uma questão de estética ou melhor maneira de programar. É claro que há perdas em se utilizar frameworks, mas há ganhos também, sendo que, em tese, o principal deles é de ser ter um menor tempo de desenvolvimento de sistemas (você não precisa implementar tudo, porque já fizeram isso pra você, consequentemente escreverá menos código).

Saber SQL é legal e essencial, mas ficar fazendo CRUD o dia todo escrevendo um monte disso o dia inteiro enche o saco.

E aos que gostam de escrever o sql na unha, não se esqueçam de usar SQL/ANSI PURINHO, porque se começarem a usar features especificas do BD, rezem para um dia nao precisarem mudar de SGBD :shock: Imaginem o tamanho do refactory de um sistema grandinho, sair pescando as querys e mudando as coisas especificas de BD.

Bom, cada um na sua. A partir do momento em que uma das pessoas que estão participando da discussão diz “esta é minha opinião”, não há mais o que discutir.

O que eu acho interessante é que as críticas se referem ao esforço que é necessário empregar para aprender a usar o Hibernate, como se não fosse necessário empregar qualquer esforço para aprender JDBC ou qualquer dos correlatos substitutos.

nesta query ai é simples usar criteria mas em querys complexas e grandes não é muito bom… pois no final das contas o que o hibernate vai fazer e transformar o criteria em query… e se vc quer velocidade e performance e souber trabalhar bem com sql nativo não é bom usar critéria para consultas complexas…
já reftorei querys que usavam criteria e levavam até 15 min pra sql nativo onde rodavam em cerca de 1,5 min… usando algumas técnicas de otimização as quais o hibernate não usa pois para isto ele iria requerer uma heuristica um pouco mais avançada a qual não faz parte do escopo do framework…

Todo bom query helper vai te dar isso de bandeja.

Isso quase NUNCA acontece. O máximo que acontece é usar um outro DB para unit tests em memória. Eu uso H2 que suporta mode=MYSQL por exemplo.

Sim. Se vc não sabe nada, então é melhor partir para o Hibernate mesmo. O mercado aceita, etc. O problema é quem já sabia SQL, banco-de-dados, cache, blah, blah, e agora tem que esquecer isso e aprender um novo paradigma. O cara tem que se convencer que os benefícios superam os custos. Posso estar errado, mas não estou convencido disso. Pelo menos em todas as vezes que usei Hibernate.

[quote=saoj]

Sim. Se vc não sabe nada, então é melhor partir para o Hibernate mesmo. O mercado aceita, etc. O problema é quem já sabia SQL, banco-de-dados, cache, blah, blah, e agora tem que esquecer isso e aprender um novo paradigma. O cara tem que se convencer que os benefícios superam os custos. Posso estar errado, mas não estou convencido disso. Pelo menos em todas as vezes que usei Hibernate.[/quote]

Exatamente o que penso.Tirando a parte,sobre já ter usado Hibernate. :wink:

[quote=saoj]
Sim. Se vc não sabe nada, então é melhor partir para o Hibernate mesmo. O mercado aceita, etc. O problema é quem já sabia SQL, banco-de-dados, cache, blah, blah, e agora tem que esquecer isso e aprender um novo paradigma. O cara tem que se convencer que os benefícios superam os custos. Posso estar errado, mas não estou convencido disso. Pelo menos em todas as vezes que usei Hibernate.[/quote]

Errado, na minha opinião. O hibernate não tem nenhum paradigma novo. Ele é um framework de persistencia/ORM. Se você programa decentemente a tua persistencia, você vai implementar na mão várias coisas que o Hibernate já tem implementado out-of-the-box.
Quem conhece bem Hibernate e depois le o PoEAA percebe que ele implementa vários patterns complexos, alguns inclusive que você dificilmente se daria o trabalho de implementar na mão (principalmente o Unit of Work). Cache da forma como ele faz nem se fala. Lazy loading, carregar automaticamente relacionamentos, etc, são outras coisas bem legais dele. Sem falar nos projetos Hibernate Search, Hibernate Validator, etc.

Tudo isso tem um custo, ele tem uma forma de se trabalhar e você precisa configurar ele. Mas hoje em dia a configuração dele é ridiculamente simples. O Hibernate em si é um projeto grande, tem uma complexidade, devido ao conjunto de conceitos e funcionalidades que ele implementa. Por isso é preciso ler a documentação e consultar a documentação constantemente.

Eu vejo muito desenvolvedor que não tem muita paciência e vai reinventando a roda, codificando tudo do zero. Eu acho que quem faz isso não é por que já sabe SQL e JDBC, e sim por que não tem conhecimento das ferramentas disponíveis. Por preguiça, má vontade, gosto pessoal e outros motivos, prefere não gastar tempo aprendendo bem uma ferramenta bem estabelecida que já faz muito bem o que ele precisa.

E não da pra comparar Hibernate com VB e Maker. Abstrair e implementar conceitos encapsulando suas complexidades é uma coisa, ferramenta visual para gerar código é outra.

Não vejo problema nenhum em não gostar de ferramentas/conceitos bem estabelecidos. Mas quando falamos de tecnologia e desenvolvimento, temos que que ter um olhar mais técnico e menos emocional. Se não gostamos de uma ferramenta que todo mundo gosta, nós podemos estar certos, mas seria bom entendermos o que realmente não gostamos na ferramenta e ter a mente aberta, pode ser que nós simplesmente não conhecemos a ferramenta o suficiente ou nunca trabalhamos num ambiente em que ela é usada de forma correta.

[quote=Rubem Azenha]

Errado, na minha opinião. O hibernate não tem nenhum paradigma novo. Ele é um framework de persistencia/ORM. Se você programa decentemente a tua persistencia, você vai implementar na mão várias coisas que o Hibernate já tem implementado out-of-the-box. [/quote]

Se vc não esta trabalhando em um novo paradigma usando hibernate então está fazendo algo errado. Afinal, é pra isso que ele implementa os padrões pra vc, para que possa trabalhar em um outro nivel de abstração.

Disse tudo!!

[quote=asaudate][quote=Felagund][quote=asaudate]Parando de trollar um pouco (ou não):

Acho que só não gosta de um framework quem não sabe usar e/ou não sabe pra que serve. Ex.: quem foi aí que comentou que o Hibernate é pouco flexível pq não suporta NoSQL, mesmo??

[]´s[/quote]

Eu disse :D[/quote]

Então, cara… o caso é que o Hibernate, como ferramenta ORM é feito para trabalhar somente com bancos de dados relacionais. Na verdade, existem tentativas de usar o Hibernate com bancos como o BigTable, do Google App Engine, mas o pessoal que já fez isso admite que fica muito ruim de trabalhar e admite, também, que é melhor usar outras estratégias.

Então, recapitulando… JPA (Hibernate) != Bancos NoSQL, OK ?

[]´s!!![/quote]

Compreendo que o propósito do Hibernate não é remover o R da sua sigla existencial, mas acredito que ele poderia ser algumas vezes mais flexivel, eu tentei estudar um pouco da API do Hibernate pra implementar um dialeto pro CouchDB, e abandonei, não era vantagem.

Mas em se falando de representar estruturas com objetos, você pode perfeitamente usar a mesma abordagem do Hibernate, pois o NoSQL também possui relacionamentos, tanto quanto ou até mais que o relacional, só não é tão forçado.

Enfim, chegamos a uma conclusão de que Hibernate é uma melhor opção pra Relacional, mas não serve pra outros tipos de bancos não relacionais, e escrever um amontoado de SQL pra mim ta fora, prefiro muito mais usar o Hibernate e deixar esse retrabalho pra ele.

[quote=Rubem Azenha][quote=saoj]
Sim. Se vc não sabe nada, então é melhor partir para o Hibernate mesmo. O mercado aceita, etc. O problema é quem já sabia SQL, banco-de-dados, cache, blah, blah, e agora tem que esquecer isso e aprender um novo paradigma. O cara tem que se convencer que os benefícios superam os custos. Posso estar errado, mas não estou convencido disso. Pelo menos em todas as vezes que usei Hibernate.[/quote]

Errado, na minha opinião. O hibernate não tem nenhum paradigma novo. Ele é um framework de persistencia/ORM. Se você programa decentemente a tua persistencia, você vai implementar na mão várias coisas que o Hibernate já tem implementado out-of-the-box.
Quem conhece bem Hibernate e depois le o PoEAA percebe que ele implementa vários patterns complexos, alguns inclusive que você dificilmente se daria o trabalho de implementar na mão (principalmente o Unit of Work). Cache da forma como ele faz nem se fala. Lazy loading, carregar automaticamente relacionamentos, etc, são outras coisas bem legais dele. Sem falar nos projetos Hibernate Search, Hibernate Validator, etc.

Tudo isso tem um custo, ele tem uma forma de se trabalhar e você precisa configurar ele. Mas hoje em dia a configuração dele é ridiculamente simples. O Hibernate em si é um projeto grande, tem uma complexidade, devido ao conjunto de conceitos e funcionalidades que ele implementa. Por isso é preciso ler a documentação e consultar a documentação constantemente.

Eu vejo muito desenvolvedor que não tem muita paciência e vai reinventando a roda, codificando tudo do zero. Eu acho que quem faz isso não é por que já sabe SQL e JDBC, e sim por que não tem conhecimento das ferramentas disponíveis. Por preguiça, má vontade, gosto pessoal e outros motivos, prefere não gastar tempo aprendendo bem uma ferramenta bem estabelecida que já faz muito bem o que ele precisa.

E não da pra comparar Hibernate com VB e Maker. Abstrair e implementar conceitos encapsulando suas complexidades é uma coisa, ferramenta visual para gerar código é outra.

Não vejo problema nenhum em não gostar de ferramentas/conceitos bem estabelecidos. Mas quando falamos de tecnologia e desenvolvimento, temos que que ter um olhar mais técnico e menos emocional. Se não gostamos de uma ferramenta que todo mundo gosta, nós podemos estar certos, mas seria bom entendermos o que realmente não gostamos na ferramenta e ter a mente aberta, pode ser que nós simplesmente não conhecemos a ferramenta o suficiente ou nunca trabalhamos num ambiente em que ela é usada de forma correta.[/quote]

Falou tudo!

[]´s

Que polemica… :shock:

Já que é para abandonar o velho e usar o novo,só por que a maioria está usando :roll: ,então quem usa eclipse está ultrapassado,abandonem isso e comecem a utilizar Netbeans.

Desculpe,mas tem gente viajando… :roll:

Considerando que qualquer faculdade de quinta hoje em dia tem a linguagem java na sua grade curricular e o fato de ser considerado a linguagem oficial das consultorias 3 letrinhas que assolam o mercado de TI, acho uma tremenda ironia alguém afirmar ser “maluco contra-cultura” e ao mesmo tempo usar Java.

Só porque prefere usar um framework desconhecido? Sério?

[quote=Anime]Que polemica… :shock:

Já que é para abandonar o velhor e usar o novo,só por que a maioria está usando :roll: ,então quem usa eclipse está ultrapassado,abandonem isso e comecem a utilizar Netbeans.

Desculpe,mas tem gente viajando… :roll: [/quote]

Por esse ponto, os dois IDEs são velhos. O próprio Hibernate é bem velho também, assim como todo o resto exposto no tópico.

E é claro que não funciona assim. O ponto do Rubem é exatamente que não devemos levar no emocional decisões tecnológicas justamente porque a tecnologia não é emocional.

Isto sim é uma decisão racional:

http://community.jboss.org/wiki/Gradlewhy

Pra quem não irá ver o link, ele conta os motivos que levaram o time do Hibernate a deixar de usar o Maven e passar a usar o Gradle. São motivos parecidos que estão me levando a usar o Gradle na empresa, mas em casa o Maven me atende. É uma questão racional e não emocional.

[quote=Ataxexe][quote=Anime]Que polemica… :shock:

Já que é para abandonar o velhor e usar o novo,só por que a maioria está usando :roll: ,então quem usa eclipse está ultrapassado,abandonem isso e comecem a utilizar Netbeans.

Desculpe,mas tem gente viajando… :roll: [/quote]

Por esse ponto, os dois IDEs são velhos. O próprio Hibernate é bem velho também, assim como todo o resto exposto no tópico.

E é claro que não funciona assim. O ponto do Rubem é exatamente que não devemos levar no emocional decisões tecnológicas justamente porque a tecnologia não é emocional.

Isto sim é uma decisão racional:

http://community.jboss.org/wiki/Gradlewhy

Pra quem não irá ver o link, ele conta os motivos que levaram o time do Hibernate a deixar de usar o Maven e passar a usar o Gradle. São motivos parecidos que estão me levando a usar o Gradle na empresa, mas em casa o Maven me atende. É uma questão racional e não emocional.[/quote]

Então não tinha entendido,mas cada caso é um caso e nem sempre “esse” será melhor que “aquele”,tecnologicamente falando… :wink:

aff acho que foi isso que ele quis dizer :oops:

Não, o saoj quis dizer que, se todo mundo usa, ele desconfia. O que não é de todo errado, a não ser que ele não use por não usar - ou seja, ele é um do contra, um “maluco da contra-cultura”.

[]´s

nussa… o Tópico ganhou proporções gigantescas…

Bom gente, acho que chegamos no meio termo onde todos tem um pouco de razão…

Lembro que quando lí sobre o Maven e tentei levar um Projeto com ele na mão, realmente deu vontade de chutar o balde e mandar pra PQP… Mas de fato consegui… O Maven nasceu como solução ao ANT, o Gradle (ao que parece, corrijam se eu estiver errado) como solução ao Maven… Daqui uns anos aparece um XBUILDULTRAMEGAPOWER como solução ao Gradle e etc…

Hibernate não resolve todos os Problemas da face da Terra, mas ajuda na manutenção, assim como o Spring (mas que é um parto é…)

Daqui um tempo estaremos falando de Rails, Groovy, Scala, etc…

O ponto é… meu Projeto precisa de Controle ou pode ter abstração ??

Isso só quem pode responder é cada um com seus Projetos… De repente o saoj nunca precisou de Abstração e sempre precisou de controle, alguns já se deram bem com os Frames porque seus projetos não precisavam de baixo tempo de resposta e nem de tanto controle manual, etc… E assim segue a vida e o mundo Tecnológico… Recentemente entrei em um Projeto onde toda a regra já estava implementada em Procedures… Mas já estava mesmo, sem acordo pra trocar… o bom e velho JDBC me ajudou pra KCTi…

Att.