Muito bom o vídeo, so quero deixar apenas uma sugestão, em uma API REST o método DELETE deve ser usado para remoção de um recurso. No seu caso, como está alterando um recurso (Status), deveria usar PUT
lembrando que, tem um video que o Brunão fez sobre o design pattern strategy, da pra implementar o envio para cada channel, da pra dar uma incrementada no código e mostrar que tem conhecimento tambem sobre design pattern 😄
Espero que seu canal cresça bastante, pois seu trabalho é muito bom! Trabalho com java a 7 anos e vi poucos canais no yt que tem esse grau de cuidado com a apresentação que você tem!!!
Muito bom. Parabéns pelo canal. Aproveitando os vídeos pra dar uma atualizada. Vou ver todos e já estou compartilhando seus vídeos com o clã dos devs por aqui. kkkkkk. Valeu.
@@ricardoaugusto6985 obrigado Ricardo! É intencional mesmo, por algumas razões eu não curto muito o uso do Lombok. Mas ao utilizar, nao teria nenhum problema, funcionaria da mesma forma.
Qual sua opiniao de status e channel serem apenas enums? Penso isso pois são registros que não mudarão com frequência e eles são muito acoplados a implementação, você teoricamente não poderia ter um channel sem implementar a forma de envio dele (pensando em algo mais futuro)
@@programadordebug Pensando em otimização, nós precisamos normalizar as colunas da base de dados ( 1 Forma Normal ). Se for um campo de texto somente, não temos tantos benefícios com indexação. :)
Poderia ser dessa forma tambem, nao vejo problema na questao do status ser um ENUM dentro da propria entidade. Quanto ao Chaneel nesse caso e melhor ser uma tabela separada pois o channel pode ter outros atributos. Suponha que a empresa deseje desabilitar o envio de notificacao de SMS, por questao de custo, por exemplo. A tabela channel poderia ter um campo Ativo (true/false) para cada tipo de notificação. Dessa forma, voce consegue ter controle maior sobre cada channel
Camarada, algum motivo especial em ter optado por utilizar o CommandLineRunner ao invés dos arquivos schema.sql e data.sql? Parabéns pelo vídeo, muito bacana.
@@murilokratos3388 obrigado Murilo! Rapaz, eu prefiro ter a visão real do código que está rodando, além de outros aspectos (encapsulamento, etc). Não tem certo ou errado, é mais a minha preferencia mesmo :)
Utilizar a identificação como notificationId não seria algo redundante dentro do contexto da entidade Notification? Porque você prefiriu utilizar um relacionamento 1 para N entre Channel e Notification ao invés de criar um enumerado, no caso não seria mais interessante ser um relacionamento N x N ou talvez utilizar @ElementCollection com uma listagem de enums representando os canais, tendo em vista que a notificação poderia ser enviada para vários canais ao mesmo tempo. Achei muito inteligente sua ideia de criar um Enum para o Channel contento o Id e a descrição dele pra representar os canais padrões pré cadastrados no banco, eu provavelmente teria feito um enum somente com a descrição dos channels e buscaria eles através da descrição pra pode setar ele como um relacionamento da notificação, mas usando essa abordagem que você fez fica muito mais claro e simples. Muito bom o vídeo, aprendi coisas novas ✌
Muito bom o video parabéns super didático. Espero que mais brasileiro possa criar conteudo desse seu nível. Eu só fique com uma duvida, por que você extraiu tudo para uma entidade channel e status, pq não optou por só usar uma enum? No final você colocou um TODO dizendo que não irá realizar essa implementação. Daria para ter criado uma interface, envioGateway com 1 metodo send por exemplo, injetar na sua service e chamar o metodo send no lugar do TODO. Ai quem for mexer com o envio teria que implementar essa interface. Acredito que desacoplaria bem mais.
@@eduardoroosevelt3261 Fala Edu! Optei por normalizar a base de dados, com isso ela fica melhor indexada e otimizada. É uma ótima sugestão essa criação da interface, boa!
Obrigado pelo conteudo!! Dúvida: qual seria o motivo de criar as tabelas channel e status ao inves de apenas adiciola-las como coluna de notifications e deixar o proprio backend tratar isso?
Naoo vejo problema na questao do status ser um ENUM dentro da propria entidade. Quanto ao Chaneel nesse caso e melhor ser uma tabela separada pois o channel pode ter outros atributos. Suponha que a empresa deseje desabilitar o envio de notificacao de SMS, por questao de custo, por exemplo. A tabela channel poderia ter um campo Ativo (true/false) para cada tipo de notificação. Dessa forma, voce consegue ter controle maior sobre cada channel
Muito bom mesmo. Agora me tira uma dúvida. Porque você optou por fazer duas entidades channel e status e não colocou apenas como 2 atributos da notificação já que no cadastro é uma notificação por channel? Eu só faria assim se no cadastro eu enviasse uma mensagem e uma lista de chanels para essa mesma notificação. Muito obrigado pelo conteúdo.
@@daniel_goncalves opa, obrigado! Optei por normalizar a base, para poder ensinar os relacionamentos tbem. Com a base normalizada, as buscas ficam mais eficientes
Nao vejo problema na questao do status ser um ENUM dentro da propria entidade. Quanto ao Chaneel nesse caso e melhor ser uma tabela separada pois o channel pode ter outros atributos. Suponha que a empresa deseje desabilitar o envio de notificacao de SMS, por questao de custo, por exemplo. A tabela channel poderia ter um campo Ativo (true/false) para cada tipo de notificação. Dessa forma, voce consegue ter controle maior sobre cada channel
@@dldmdani O desafio foi passado via PDF para um inscrito do canal. Ele passou para a gente e eu converti para MD. Está no link da descrição o repositorio, o arquivo é o problem.md
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
![[ADI #2] - Testes Unitários em Java com JUnit e Mockito](/img/1.gif)
🎉 Conheça a FBR:
hotm.art/fbryc
Você gostou do vídeo de hoje? Qual poderia ser o próximo desafio?
Demorou pra criar a assinatura pra membros, macho. Ja garanti a minha. Sucesso, seu trampo e massa, melhor do YT
@@avnercaleb8867 kkkkk, obrigado Avner 🫡
Muito bom o vídeo, so quero deixar apenas uma sugestão, em uma API REST o método DELETE deve ser usado para remoção de um recurso. No seu caso, como está alterando um recurso (Status), deveria usar PUT
lembrando que, tem um video que o Brunão fez sobre o design pattern strategy, da pra implementar o envio para cada channel, da pra dar uma incrementada no código e mostrar que tem conhecimento tambem sobre design pattern 😄
É verdadee! Bem lembrado Cesar! Dica boa!!
Essa playlist de desafio tecnico é show demais
Espero que seu canal cresça bastante, pois seu trabalho é muito bom! Trabalho com java a 7 anos e vi poucos canais no yt que tem esse grau de cuidado com a apresentação que você tem!!!
@@leandropqd obrigado Leandro! 🤘🫡
Iradissimo padrinho, estou estudando spring (migrando de node com nest) esses vídeos vão me salvar!!!
fiz um strategy pra os Channel, ficou maneiro, se quizer, posso subir numa branch
Muito bom. Parabéns pelo canal. Aproveitando os vídeos pra dar uma atualizada. Vou ver todos e já estou compartilhando seus vídeos com o clã dos devs por aqui. kkkkkk. Valeu.
@@victorabreu4463 Obrigadoo! 🤘
Seus vídeos são uma mina de ouro , muito bom
Massa demais! Cheguei agora por aqui!
Aeeee! Mais um desafio, sua didática é incrível 🙌🏽
Obrigado mano!
Admiro demais sua linha de raciocínio, parabéns! uma dúvida, a escolha de não utilizar o Lombok é para evitar algum possível conflito ?
@@ricardoaugusto6985 obrigado Ricardo! É intencional mesmo, por algumas razões eu não curto muito o uso do Lombok. Mas ao utilizar, nao teria nenhum problema, funcionaria da mesma forma.
que video top ! Parabéns pela didatica e conteúdo
Qual sua opiniao de status e channel serem apenas enums?
Penso isso pois são registros que não mudarão com frequência e eles são muito acoplados a implementação, você teoricamente não poderia ter um channel sem implementar a forma de envio dele (pensando em algo mais futuro)
@@programadordebug Pensando em otimização, nós precisamos normalizar as colunas da base de dados ( 1 Forma Normal ). Se for um campo de texto somente, não temos tantos benefícios com indexação. :)
Poderia ser dessa forma tambem, nao vejo problema na questao do status ser um ENUM dentro da propria entidade.
Quanto ao Chaneel nesse caso e melhor ser uma tabela separada pois o channel pode ter outros atributos. Suponha que a empresa deseje desabilitar o envio de notificacao de SMS, por questao de custo, por exemplo. A tabela channel poderia ter um campo Ativo (true/false) para cada tipo de notificação.
Dessa forma, voce consegue ter controle maior sobre cada channel
Camarada, algum motivo especial em ter optado por utilizar o CommandLineRunner ao invés dos arquivos schema.sql e data.sql? Parabéns pelo vídeo, muito bacana.
Tem que tomar cuidado com o @scheduled pq se subir mais de uma instância o scheduled vai rodar ao mesmo tempo nas duas instâncias.
Por ser um teste pra recrutadores não seria legal colocar também tratamento de exceções?
Otimo video. Descobri teu canal ao puro acaso e to curtindo muito. Uma duvida, pq vc não utiliza o Lombok?.
@@murilokratos3388 obrigado Murilo! Rapaz, eu prefiro ter a visão real do código que está rodando, além de outros aspectos (encapsulamento, etc). Não tem certo ou errado, é mais a minha preferencia mesmo :)
Gostei dessa maratona (resolvendo desafios)
Show demais esses desafios
Utilizar a identificação como notificationId não seria algo redundante dentro do contexto da entidade Notification? Porque você prefiriu utilizar um relacionamento 1 para N entre Channel e Notification ao invés de criar um enumerado, no caso não seria mais interessante ser um relacionamento N x N ou talvez utilizar @ElementCollection com uma listagem de enums representando os canais, tendo em vista que a notificação poderia ser enviada para vários canais ao mesmo tempo. Achei muito inteligente sua ideia de criar um Enum para o Channel contento o Id e a descrição dele pra representar os canais padrões pré cadastrados no banco, eu provavelmente teria feito um enum somente com a descrição dos channels e buscaria eles através da descrição pra pode setar ele como um relacionamento da notificação, mas usando essa abordagem que você fez fica muito mais claro e simples. Muito bom o vídeo, aprendi coisas novas ✌
@@gabrielcardosogirarde7515 São boas ideias tbem Gabriel! Neste caso optei por normalizar a base, para ficar mais otimizada e melhor indexada.
Muito bom! Só uma dúvida: como tu grava o conteudo assim deixando você e a tela desse jeito? Com qual app?
@@pedroarthuralves obrigado! É o OBS mesmo :)
Muito bom o video parabéns super didático. Espero que mais brasileiro possa criar conteudo desse seu nível.
Eu só fique com uma duvida, por que você extraiu tudo para uma entidade channel e status, pq não optou por só usar uma enum?
No final você colocou um TODO dizendo que não irá realizar essa implementação. Daria para ter criado uma interface, envioGateway com 1 metodo send por exemplo, injetar na sua service e chamar o metodo send no lugar do TODO. Ai quem for mexer com o envio teria que implementar essa interface. Acredito que desacoplaria bem mais.
@@eduardoroosevelt3261 Fala Edu! Optei por normalizar a base de dados, com isso ela fica melhor indexada e otimizada.
É uma ótima sugestão essa criação da interface, boa!
Obrigado pelo conteudo!!
Dúvida: qual seria o motivo de criar as tabelas channel e status ao inves de apenas adiciola-las como coluna de notifications e deixar o proprio backend tratar isso?
normalização é uma boa prática dentro da base de dados (quando não é levada ao extremo)
@@estevaois Exato, é para isso msm!
Naoo vejo problema na questao do status ser um ENUM dentro da propria entidade.
Quanto ao Chaneel nesse caso e melhor ser uma tabela separada pois o channel pode ter outros atributos. Suponha que a empresa deseje desabilitar o envio de notificacao de SMS, por questao de custo, por exemplo. A tabela channel poderia ter um campo Ativo (true/false) para cada tipo de notificação.
Dessa forma, voce consegue ter controle maior sobre cada channel
Muito bom mesmo. Agora me tira uma dúvida. Porque você optou por fazer duas entidades channel e status e não colocou apenas como 2 atributos da notificação já que no cadastro é uma notificação por channel? Eu só faria assim se no cadastro eu enviasse uma mensagem e uma lista de chanels para essa mesma notificação.
Muito obrigado pelo conteúdo.
@@daniel_goncalves opa, obrigado! Optei por normalizar a base, para poder ensinar os relacionamentos tbem. Com a base normalizada, as buscas ficam mais eficientes
@@buildrun-tech fiz um fork pra fazer umas mudanças. Depois compartilho pra vc ver se é legal
@@daniel_goncalves boaa! Compartilha sim
Nao vejo problema na questao do status ser um ENUM dentro da propria entidade.
Quanto ao Chaneel nesse caso e melhor ser uma tabela separada pois o channel pode ter outros atributos. Suponha que a empresa deseje desabilitar o envio de notificacao de SMS, por questao de custo, por exemplo. A tabela channel poderia ter um campo Ativo (true/false) para cada tipo de notificação.
Dessa forma, voce consegue ter controle maior sobre cada channel
Show demais!
onde posso ver o repositório do desafio original?
@@dldmdani O desafio foi passado via PDF para um inscrito do canal. Ele passou para a gente e eu converti para MD. Está no link da descrição o repositorio, o arquivo é o problem.md
Muito bom!!!👏👏👏
Aonde eu encontro esses desafios?
@@JCode_Development existe o repositório do backend brasil. Mas esses eu recebi dos inscritos :)
Top
Por que preciso criar um construtor vazio?
@@Anacletodev Opa, seria pro SpringData/Hibernate conseguir instanciar e gerenciar a inserção dos atributos da sua entity
Qual o nivel ? Junior ?
@@lealsantanati Junior/Pleno