quando voce escreve: (eval (if 4 4 2)) no caso o eval esta evaluando apenas o resultado da operacao (if 4 4 2) e nao a lista que voce passou. no fim fica assim (eval 4) Se voce quiser usar evaluar a lista voce precisa usar o sintax sugar ' (eval '(if 4 4 2)) ou a funcao list como fez nos outros examplos sobre a utilidade do code-as-data no meu ponto de vista: torna bem facil voce "extender" a linguagem criando novas macros. um exemplo bem comum de macros de usuarios 'e essa when-let* (defmacro when-let* [bindings & body] `(let ~bindings (if (and ~@(take-nth 2 bindings)) (do ~@body) ))) que eh basicamente um when-let que permite mutiplos bindings... ter code as data facilita e muito criar esse tipo de extensao. Desculpa os milhoes de erros de acentuacao e portugues meu SO ta em outro idioma

Bons estudos por aí... Mas admito que sem pesquisar, mas te acompanhando, ainda não sei qual problema o Cloujure resolve. Por que devo adotar Cloujure? Quando devo considerar o uso?

Parabens pelo conteudo

(pra cimaaaaaaaa 🚀)

seria o chatgpt o novo pato de borracha dos programadores? série muito boa! abraço!

Maravilha @! Sucesso !@

Salve, Alberto! Futuro colega de trabalho! Trabalho em outra área e estou estudando mais a stack pra voltar a ser Tech Manager, essa série será ótima pra mim! Valeu!

Meu amigo, muito obrigado por compartilhar sua jornada de aprendizado. Vou aproveitar bastante dos seus métodos nas minhas trilhas de aprendizagem também. Eapero muito pelo dia em que trará aqui a implementação de clean arch usando o Clojure! Sou fascinado por lisp e sua maneira diferente de se resolver problemas. Quero demais ver clean arch nele! Obrigado camarada! Tmj! Bons eatudos e parabéns na nova jornada no NuBank!

Ouvindo sua explicação Alberto, fiquei pensando a respeito de duas situações que vejo muito acontecer, uma delas é justamente o ponto que você colocou de postergar determinadas decisões, nesse ponto, quase todo tutorial ou curso que já vi, começa com a instalação do conjunto de ferramentas, bibliotecas, frameworks e tudo mais, as vezes naquele momento você nem precisa daquilo instalado. Outro ponto que vejo, é que sua explicação me fez lembrar muito de um dos propósitos de arquiteturas como a clean arch e hexagonal, quando coloca na camada de Infraestrutura tudo que diz respeito a tecnologias e quando você decide, por exemplo, mudar o broker que está utilizando para mensageria, a arquitetura do seu software torna mas fácial a inclusão/adaptação do novo broker que será adotado. No primeiro ponto, a gente evita se preocupar com aquilo que ainda não precisamos e no segundo facilita a adoção de novas tecnologias que decidimos utilizar depois de implementado o software.

Muito obrigado por compartilhar tua maneira de estudar com a gente, Alberto. De fato, é realmente muito interessante e estou aprendendo muito contigo sobre **como aprender**. Gratidão e boa sorte nessa nova jornada!

Depois do seu primeiro vídeo, comecei a questionar meus métodos de estudos 🤣

Parabéns mestre. Sempre fera nos ensinamentos

Caraca o BABA é uma lenda viva fora o conhecimento que extremo a humildade do cara é foda de mais. Vou tentar seguir o mestrado!!@

Clojure é uma linguagem incrível e extremamente apaixonante! sucesso Alberto!!!! 💪

cara gostei do vídeo .. e me animou a aprender clojure ... vamos juntos !

massa

cara .. como alguém consegue saber que vai trabalhar em algum lugar com 2 meses de antecedência ... e ainda tem a oortunidade de se preparar ... quando eu crescer queroi ser como vc Alberto.. .:) forte abs do RS

já fiquei ansioso pra ver mais dessa jornada! confesso que esse video me fez repensar alguns pontos dos meus estudos. boa sorte desde já na empreitada e não deixe de compartilhar com a gente!

Que demais! Achei muito interessante seu método de estudo. Com tanta distração, perco o foco e me perco no objetivo com facilidade e essa fase de consciência fez muito sentido pra mim, vou tentar aplicar 😊

👀👀🎯🎯🚀🚀🚀

👏🏾 🚀 👏🏾 🚀 👏🏾 🚀 👏🏾 🚀 👏🏾 🚀

Além da jornada de estudo aproveita que vc está no Nubank e aprende com os repositórios, melhor lugar pra aprender com a mão na massa. Bem vindo :)

Excelente vídeo Alberto, muito legal acompanhar teu aprendizado na prática. Sucesso na nova caminhada!

Pra pensar em code-as-data acho que vale refletir sobre o que diferencia um "pedaço" de código e um "pedaço" de dados? Como isso funciona em uma linguagem tipo JavaScript vs em Clojure? Tem alguma diferença?

Desejo muito sucesso no novo desafio. Os livros de Clojure que eu mais gostei de ler: Clojure Applied [Ben Vandgrift, Alex Miller], Functional Thinking [Neal Ford] (não tem só Clojure, mas tem bastante), Functional Programming Patterns in Scala and Clojure [Michael Bevilacqua-Linn].

2:14 Acho que "a mais conhecida" derivada do Lisp fora o Clojure seria a linguagem Scheme. Ela ganhou alguma atenção por ser adotada no, aí sim muito famoso, MIT.

Bem legal, hj uso o codeium e o github actions pra gerar revisão do meu código dessa forma mas.... dessa forma economiza um tempo absurdo, vou mandar essa live aqui no time imagino que rodar com o phi3:mini localmente com o ollama seria bem legal tb

Achei muito interessante e fez sentido. Valeu

Primeiramente excelente video, me fez pensar em todos os testes unitários que eu fiz utilizando any. Faz sentido colocar um valor verdadeiro para um método que estou mockando o retorno? Pelo que entendo da utilização de any no lugar de valores verdadeiros seria porque mesmo que eu coloque um valor verdadeiro, eu estou definindo qual será o retorno do método A lógica de testar uma classe que utiliza um método de outra classe seria para testar todas as condições dentro da classe Dessa forma, mesmo que eu utilize o any, eu posso definir o valor que eu quero retornar e testar todas as condições de acordo com o retorno do método que está fora da classe Faria sentido eu colocar um valor especifico no lugar do any caso o retorno do método que eu estou mockando seja influenciado por esse valor Isso ajudaria na legibilidade no teste unitário e facilitaria o programador que não fez o teste a entender o fluxo que está sendo testado. Caso o valor que está sendo passado não influenciar no retorno do método que está sendo mockado, não vejo problema em passar um any

Showw 👏👏👏

Fala meu bom, legal esse vídeo aí, sempre legal se aproximar da realidade da aplicação o máximo possível, me tira uma dúvida, vc sabe como se usa attachaprovider com o mockito?

Muito boa essa reflexão! As vezes temos o ímpeto de escrever o teste muito genérico e aí ele deixa de ser assertivo.

Excelente informação sobre mocks nos testes unitários. A não utilização de matchers não só aumenta a confiabilidade dos testes, como facilita o mock específico de multiplas chamadas do mesmo método mockado com valores de parâmetros diferentes.

esse casaco do milan eh mto bonito

Olá Alberto, boa noite! Você acredita que o uso excessivo de Mocks acontece porque as pessoas têm na cabeça que testes unitários significam testar sempre a menor unidade possível (solitários), em vez de testar unidades sociáveis? Na minha experiência, escrever testes um pouco mais sociáveis aumenta a confiabilidade do teste e diminuem o uso de mocks. Confesso que eu utilizo Matchers em situações específicas: por exemplo, quando tenho uma classe que posta uma mensagem num tópico Kafka. Nesses casos de uso, eu acho que os Matchers especificos - sem nenhum tipo de Any(), cumprem bem a função. O que acha? Obrigado pelo vídeo.

Não seria o caso de mudar o nome de servicosAI pra servicosAIClient ou servicosAIFeignClient? Acho que ai pelo nome já ficaria evidente que estamos invocando um client externo

Confesso que para mim ficou mais complicado ler o fluxo do negócio quando tudo esta misturado. A leitura mais simples é aquela que tudo aconteceu com sucesso e este é realmente meu fluxo de negócio. Os fluxos "alternativos" de resiliência e idempotência, são "apenas" técnicas para executar este fluxo principal, e ficar filtrando o que é fluxo de negócio do restante na hora de fazer a leitura do código me dá bem mais trabalhos cognitivo. Prefiro deixar menos "poluído" esta leitura e delegar para outras ferramentas.

Nesse caso a documentação descritiva do proprio método não deveria conter uma direção do que ele faz e ter um contrato bem definido do que seria o retorno ? Pensando num cenário ideal onde manteriamos o encapsulamento o mais genérico possivel.

"Driva"... saquei. Ótimo vídeo. Trouxe a informação que eu queria. Obrigado

Ótimo, Professor Alberto. Você considera os indicadores de complexidade ciclomática/cognitiva do sonarQube melhores balizadores para segregação de responsabilidades e definição das camadas da aplicação além do pregado por _clean_ _architecture_ ou arquitetura hexagonal, por exemplo? Na falta de um modelo genérico a seguir, esses indicadores, ainda que insuficientes, funcionam para reduzir a complexidade de manutenção de classes mais "gordinhas".

A qualidade daquilo que você produz, está de acordo com aquilo que você conhece

Desconsiderando o rant do DHH, o problema da Amazon parece ter sido de complexidade. É muito comum que aplicações distribuídas se tornem mais complexas de manter por conta do overhead de problemas possíveis (latência, indisponibilidade, retentativas, tráfego). P.S: fecha um pouco dessas abas kkkkkk

Substitutos do "porquê": Como isso nos ajuda? Quando isso é eficiente? Como isso se compara com outras opções? Me ajude a entender o raciocínio que guiou essa decisão. Que fatores influenciaram essa escolha? Quais foram os fatores levados em conta nessa escolha? Qual foi o contexto dessa decisão?

Boa noite, muito obrigado pelo seu trabalho, estou amando os vídeos! Estou trabalhando num projeto Flutter e como tem muita composição quando tem muitas linhas (de código solto e sem componentização) acaba que não dá de ver nada nem de separar de uma forma visualmente boa. Enfim, você teria alguma dica nesse sentido? Desde já agradeço!

Aí está algo que corrobora com o que tenho visto: "o que mais muda num software corporativo não são as tecnologias, são as pessoas". Nos últimos 3 anos não vi ninguém trazendo uma demanda para trocar um banco de dados ou framework, mas foram inúmeras as vezes em que as pessoas trocaram de projeto.

O Call Of Duty tem um Match Making, que é responsável por criar os lobs, ou as salas de quem vai jogar. A galera reclama muito que algumas salas são muito difíceis, e sempre há 2 ou 3 equipes que massacram todas as outras. Isso ocorre, pq essas equipes são realmente pro-players, ou seja, profissionais do game. Quando estas equipes procuram por partidas, raramente existem pessoas com o nível delas para jogar, por isso o game as coloca em lobs mais fáceis. E quanto mais esses pro-players se especializam, mais isso ocorre. Tenho a sensação de que é o que ocorreu contigo aí, a IA trouxe o feedback inspirado em pessoas medium-profile, pois é a maior parte da massa de programadores existentes. Como os pró-players da programação são poucos, acabam não tendo tanta influência nesse feedback. Por isso o feedback é ruim. Isso me faz pensar em muitas coisas, como por exemplo: Normalmente quando alguém destoa do restante da equipe, dizendo que algo que está sendo efeito está estranho. É natural a equipe isolar essa pessoa pois "todo mundo está achando que está certo, só você que está achando que está errado. Se todo mundo pensa que está certo, então está certo." < -- Hoje em dia, em 2024, na época das IA's, mídias sociais, e etc, é provável que essa única pessoa que destoa esteja correta. As chances desta única pessoa estar correta, são maiores do que de ela estar incorreta.

Colocar todos os ovos numa única cesta de TI. Um ponto único de falha (SPOF) é uma parte de um sistema que, se falhar, impedirá o funcionamento de todo o sistema.

Parabéns pelo vídeo Alberto e pelos conselhos de checagem de fontes, isso é muito importante. Outro ponto importante a se acrescentar é que esse tipo de problema é do tipo "tudo ou nada" ou seja pela gravidade o processo de qualidade poderia ter captado em algum momento, é realmente de se estranhar o que houve.

x.com/perpetualmaniac/status/1815316367958290828?t=Yr7HzSwDnDqz1dDtVow1ww Acho o rapaz ficou pistola e soltou um novo capítulo dessa história

Muito bom, muito legal ver sua abordagem...