antiduhring.dev
Software Engineer.
Working from 🇧🇷 to 🇺🇸
321 posts
1,034 followers
505 following
Regular Contributor
Active Commenter
comment in response to
post
Ele vai se foder MUITO com essa que aprontou, mesmo que ganhe a eleição
comment in response to
post
Lili cantou demais!! Parabéns mano, muito merecido, vc já é senior no meu coração
comment in response to
post
o carnaval daqui é bom dimai, tava com saudade tbm, não vim pra cá ano passado
comment in response to
post
essa carência é muito coisa de adolescente kkkkkk tem gente que não entende que as vezes vc só quer sair com outros amigos e pronto. Ninguém precisa tá grudado o tempo todo
comment in response to
post
sim!! KSKSKSKS
comment in response to
post
- usem sempre feature flag
- chequem se a feature flag tá ativa/desativada antes de mandar pra prod
- chequem se oq vcs subiram quebrou algo depois de mandar pra prod
comment in response to
post
cc @samsantosb.bsky.social @sseraphini.bsky.social
comment in response to
post
a gente tem bancos separados pra cada microsserviço, então o sistema de email envolve várias filas pra fazer fetch desses dados e garantir que tem todas as informações antes de mandar o email. A única desvantagem é que os dados não são real time up to date, então pode rolar inconsistência
comment in response to
post
sim, é o que a gente usa no trampo. a conta mais barata permite até 10 usuários se não me engano, já quebra um galho
comment in response to
post
javascript é muito ame ou odeie, se tu não aprender a gostar acho difícil superar esse desgaste ksskkssksk
comment in response to
post
pra gerenciar senhas internamente eu prefiro uma conta business do 1Password (ou alguma solução parecida self-hosted pra ser mais seguro), porque ai é fácil de controlar acessos, fácil de consultar, adicionar/remover pessoas
comment in response to
post
no trampo a gente tem uma política de que só 2 pessoas tem acesso as senhas root, incluindo o lead da infra, e ele controla todos os outros acessos via roles e obriga a gente a usar MFA
comment in response to
post
Sim vei, os caras metem essas histórias e depois acusam os democratas de espalhar pânico kikkkk
comment in response to
post
foda!! por isso eu amo JS, tu pode mudar o comportamento dos prototypes como quiser e ninguém reclama
comment in response to
post
ai eu concordo sim, 100%, mas pra mim isso é mais questão da tecnologia e onde ela é aplicada do que sobre as pessoas em si. Hj em dia minha stack principal é Go e sinto que tive contato com problemas bem mais complexos do que quando era com JS
comment in response to
post
não acho, tu consegue encontrar bolhas dentro da comunidade de qualquer lang que vai ter gente muito foda, experiente e disposta a trocar ideia. o ecossistema do JS tem muito disso inclusive
comment in response to
post
é muito real isso que ele falou, o Node não inventou a roda rodando um event loop single threaded, isso é um padrão bem conhecido já chamado Reactor, o nginx também usa.
o non-blocking I/O "substitui" a necessidade de multi-thread
en.wikipedia.org/wiki/Reactor...
comment in response to
post
o terror dos CTO kkkkkk sou muito adepto do make it work, make it right, make it fast. O iniciante tá no make it work mas tem que se manter estudando pra chegar no make it right
comment in response to
post
o país tem jeito sim, mas acredito piamente que boa parte das pessoas - de todos os estratos sociais - tão num estado de descolamento da realidade irrecuperável
comment in response to
post
e é importante lembrar que isso de má-prática e anti-pattern depende 100% de onde tu ta codando. Se no teu trampo for é muito comum na codebase não tem pq ter medo de usar
comment in response to
post
acho que o ideal é o iniciante ter contato com isso mas saber como absorver. Se tu leva tudo oq falam na internet como regra vai ficar em pânico mesmo, então meu conselho é entender que essas discussões existe mas na hora de codar só fazer do jeito que consegue
comment in response to
post
tenho uma opinião bem parecida também, evito for na maioria dos casos - 100% gosto pessoal, não é meu paradigma preferido -, mas pra encadear promises que precisam ser executadas em ordem é o que mais faz sentido. Se desse p fazer um map com await eu abandonaria o for
comment in response to
post
evento canônico na vida de um dev
comment in response to
post
brabo!!