O que aconteceu com os sites do Uai Hebert?

Faz muito tempo que está fora do ar, porém até hoje não encontrei nenhum parecer sobre o porque está fora do ar e se vai voltar algum dia.

Sim, já faz um tempo que está offline, procurei algumas vezes o motivo e nada, resolvi perguntar aqui.

Talvez a publicidade não ta pagando nem a hospedagem?

Fazer site pra programador é uma péssima idéia já que é um publico que sabe instalar adblock.

Só pra constar, hoje em dia tem o “adblocker blocker” que alguns sites de notícias estão usando pra ocultar o conteúdo quando o visitante está com o adblocker habilitado…
Não conheci o site, mas pelo que estão dizendo parece que era interessante…

Para quem quiser matar a saudade ou a curiosidade:

Adblocker apenas bloqueia anúncios de terceiros. Não impede que o site monetize anúncios nativos, nem informações coletadas sobre o usuário.

Bom, esse último vai ficar dificil tb , porque todos os Macs começam a bloquear tracking no final do ano!

Então acho que só vai sobrar anúncios nativos ou abrir mão do segmento da web que usa Safari.

ps: anuncios nativos seriam aqueles servidos do mesmo IP do site.

É pelo visto ninguém sabe, será que ele deixou de ser desenvolvedor?

Ou um teste pra ver quem ia sentir falta…

É uma pena e uma grande perda de material. Ele me inspirou a criar meu próprio site, sem contar os ótimos guias de JPA. Espero que volte logo.

Não acho que o caso era ad ou custo com hospedagem porque isso é barato, talvez seja alguma treta técnica mesmo.

eu encontrei algumas das paginas dele, porem somente em ingles.

Este artigo é de 2012

Senti falta também, ainda bem que tinha algumas coisas salvas aqui… hehe

Pelo twitter dele… ele tá fora do país, talvez parou por falta de tempo… mas gostaria de saber também, porque o conteúdo sempre foi de qualidade.

https://twitter.com/uaihebert

Alguém ainda usa JPA?

Conheço muitas empresas que usam sim, JPA e seus derivados como Spring Data, qual vc usa? JDBC puro?

JPA e a promessa de gerar o schema do banco depois, a partir do código, nunca foi popular nas empresas de desenvolvimento tradicionais. Elas sempre preferiram começar pela modelagem de dados e usar JDBC para conectar.
Nas empresas de desenvolvimento moderninhas, orientação a objetos está em desuso no backend.
Por isso a pergunta, quem ainda usa JPA?

Excesso de engenharia infelizmente faz parte da cultura da comunidade Java. Nunca entendi essa fuga toda das naturezas da fonte de dados utilizada. Fora que tem soluções meio termo como Jdbc Template da Spring.

Opa pessoas, tudo bem?

uaiHebert aqui ( :

O site morreu, realmente. Não tenho idéia se vou voltar com ele. Eu nunca ganhei um tostão com ele e isso não foi o motivo de parado com o blog.

Eu parei de publicar nele justamente quando minha vida virou uma avalanche de coisas:

1. Migrei de Java para Ruby
2. Virei lider de TI
3. Mudei para Alemanha
4. Migrei de Ruby para Groovy/Servless/JS.

foram 3 anos bem puxados. O problema maior foi que ao vir para Alemanha fiquei bem curto de grana. E foi justamente quando chegou a conta do blog, que era anual. Aí o bolso doeu muito e eu resolvi encostar o blog, se não me engano a conta era de 150 obamas na época.

Um parça gente boa (Bruno Gasparotto) me indicou o webarchive. https://web.archive.org/web/20161228051356/https://uaihebert.com/

Lá tem meu blog todo.

Eu não vinha a anos no GUJ, então desculpe por não ter respondido aqui antes.

Pelo visto voce conheçe uma parte do JPA e o julga por completo. ( :

Voce pode ter ambas abordagens. DB first ou Model First.

OO em desuso no backend? Essa é nova para mim.

A especificação JPA define apenas a abordagem Model First.

Pelo visto você conhece ferramentas proprietárias de engenharia reversa e pensa que elas fazem parte do JPA. Na verdade, elas fazem parte da cultura de excesso de engenharia da comunidade Java.

Mas as empresas tradicionais, elas não mudaram, e nem irão mudar sua abordagem, mais fácil não usar JPA.

Voce poderia me mostrar isso na Spec?

Eu já li e não me lembro dela falar que esse é o único modo de usar.

Eu vejo que é flexível o bastante para deixar voce escolher sua abordagem. Por isso JPA suporta tantos tipos de herança, override de nome de colunas, indexes, etc…

Poderia tb me mostrar em que caso OO está em desuso? Nunca vi uma referencia a isso.

Quem esta dizendo que a abordagem DB first faz parte do JPA é você, então é mais lógico você mostrar onde isso é definido na especificação.

Eu estou dizendo que não existe isso na especificação, logo não faz sentido você pedir pra eu “mostrar isso na spec”. Você quer que mostre o que?

Não entendi qual a relação. A especificação JPA fala claramente sobre tipos de herança, mapeamento de colunas, indexes. Até onde sei, a especificação não fala de abordagem DB first.

Por isso seria bom citar onde você vê ela falar sobre DB first.

No backend. Mas é apenas uma impressão dado a quantidade de vagas pedindo conhecimento em linguagens funcionais que tenho visto ultimamente.

1. A primeira pessoa a falar de Spec foi voce. Por isso te pergunto novamente, voce poderia mostrar onde ela fala para usar Model First? Ou melhor, voce já leu a Spec alguma vez? Me parece que voce está afirmando algo em uma documentação que você, pelo visto, nunca leu.

2. A spec determina que o modelo deve refletir o banco de dados. Qual a diferença entre começar com o DB ou com o modelo? Se o DBA fez o modelo, crie seu código. Se o Dev fez o modelo, crie seu banco. Ou seja, vc pode optar qual a abordagem que voce quer e seguir. Se voce tem essas duas opções, onde está a limtação em fazer DB First ou Model First?

3. Quanto ao ‘desuso’ de OO como foi baseado em impressão, isso é mais opnião para mim. Como cada um tem a sua isso não adianta discutir se não á dados. ( :

Na introdução, uma vez que toda a especificação é sobre model first:

This document is the specification of the Java API for the management of persistence and object/rela- tional mapping with Java EE and Java SE. The technical objective of this work is to provide an object/relational mapping facility for the Java application developer using a Java domain model to manage a relational database.

Agora podemos saber onde a especificação fala sobre DB ser modelado primeiro ou você vai continuar inventando desculpa e tentando desqualificar o debatedor?

zzzzZZZZZZzzzzZZZZZZZzzzzz

A diferença é que uma é abordada na especificação JPA, a outra não.

Citando o pedaço da Spec que pelo visto foi rapidamente (ou incorretamente) lido:
to provide an object/relational mapping facility
Facilitar o mapeamento. Engraçado… não vi nada falando sobre model first ou mesmo DB first. O que eu to tentando falar é: JPA é agnóstico a quem é criado primeiro. O JPA funciona independente de quem veio antes. A Spec é adaptável a qualquer situação. JPA serve para facilitar o uso de OO com o DB.

using a Java domain model to manage a relational database.
O que voce entende por manage? Criar modelo primeiro para acessar o banco?

Honestamente acho que estou desqualificando a leitura em ingles do debatedor. Pq o texto que voce colocou mostra apensa que o JPA facilita a manutenção/utilização do DB, e em nenhum momento fala que o modelo tem que ser feito primeiro.

Novamente, me mostre que não. Bem, acho que vou parar de discutir Spec com quem está lendo a introdução as pressas e querendo argumentar.

Nas empresas de desenvolvimento moderninhas, orientação a objetos está em desuso no backend.

Eu parei de ler nessa parte, sinceramente.
Acho que desenvolvedores experientes precisam ter responsabilidade com as informações que são colocadas na internet, pois isso aqui será utilizado muitas vezes como referência dos recém-chegados no futuro. Estamos numa área de EXATAS onde uma opinião sem dados vale pouco, muito pouco.

De qualquer forma, quanto ao JPA eu particularmente utilizo com schema validation, pois sempre desenhei meus databases a parte (seguindo as 3 primeiras das 5 formas normais) e peço pro JPA validar, pois acho que consigo tirar o melhor dos dois mundos. JPA até agora me serviu bem tanto pra spec Java EE tanto pro ecossistema Spring. Por sinal, Spring Boot com JPA, REST, MVC eu atualmente considero a stack mais produtiva para programadores Java experientes (já brinquei com a stack MEAN e Ruby para efeito de comparação).

Um parça gente boa (Bruno Gasparotto) me indicou o webarchive. https://web.archive.org/web/20161228051356/https://uaihebert.com/

Já tinha sido indicado aqui mesmo no tópico! E como te falei, se um dia tiver tempo pra administrar seu blog de novo, te ajudo a subir tudo de novo =]

Não tem nada de agnóstico ou adaptável. A especificação é sobre usar o domain model para gerenciar o banco. Isso inclui gerar o schema a partir do código Java.

É uma coisa óbvia pra quem leu a especificação ou quem trabalhou com JPA.

Quando tiver um tempo, sugiro que leia o pacote javax.persistence.schema-generation e o pacote javax.persistence.code-generation… ops, brincadeira esse último não existe.

Sim, é o melhor que vc faz visto que não tem nada pra citar e sua tentativa de desqualificar o debatedor não parece estar dando certo.

O JPA na sua stack apenas significa que sua experiência é baseada em aplicações CRUD simples.

Não que tenha algo de errado nisso, tem muita demanda por esse tipo de sistema no mercado. Mas JPA jamais estará presente em sistemas que precisam escalar.

E REST com MVC… como isso é possível?

rapaz do céu que treta mininu, eu aposto no UAI Hebert saindo vitorioso! rsrs

Olá @Hebert_Coelho,

Uma pena seu site ter saído do ar, pois era uma referência pra mim e pra muitos outros colegas. Faço votos que você volte em breve, pois faz muita falta.

Muito legal você esta tendo essa experiência internacional, se fosse possível você fazer um vídeo falando do mercado de trabalho ai na Alemanha, seria bacana.

Como em qualquer parte na internet existe troll, o GUJ não é diferente. Por fim como diria um amigo meu “não alimente os Trolls”, apenas ignore.

Boa, kkkkkkkk isso mesmo não dê cachaça para os Trolls, quer dizer os Troços do Sub Treco.

Independente de DB First, é da cultura da comunidade Java (principalmente) querer abstrair ou desacoplar tudo mesmo sem necessidade. Como por exemplo, abstrair SQL mesmo com a empresa usando somente bancos de dados relacionais, criar Interfaces sempre, mesmo para uma única implementação contratada, etc.

Acho que empresa moderninha nem deveria usar Java, deveria usar Go, assim fica livre dessas pregações que tudo deve ser OO, MVC, etc. Fora isso, pelo que vejo infelizmente ainda continuam sim usando muito JPA/Hibernate, mesmo já tendo opções intermediárias mais leves. Sobre excesso de engenharia é verdade, é uma ferramenta pesada, e deveria ser usada quando existisse necessidade para o resultado, não só para consumir mais recursos.

Opa Namor, tudo bem? Cara Herbert eh amigo meu, ele começou a ficar muito sem tempo e nós dois nos mudamos do Brasil quase na mesma época, ele ta morando na Alemanha e tem tido algumas outras prioridades, mas pra frente ele deve voltar com o site. Viver fora é meio pancada principalmente no começo, mas uma hora as coisas começam a ficar mais folgadas.