Em 99% das empresas que trabalhei, a preocupação sempre era "faz funcionar agora e depois melhoramos"
/2
E a real é que isso NUNCA aconteceu e todos os problemas que o time previa que ia acontecer, aconteciam e os projetos se tornavam um caos
/3
Na maioria dessas empresas, os softwares ficavam insustentáveis e viravam "legado" em pouco menos de dois anos, o que gerava muito retrabalho e insatisfação de usuários
/4
Quando entrei para o time do @Nodejs, me veio uma série de reflexões: como um projeto de mais de dez anos, consegue ficar melhor a cada nova versão?
Isso falando do ponto de vista de performance da aplicação, de ferramental e principalmente de funcionalidades
/5
São raros (ou quase nulos) casos em que o Node.js quebrou em produção ou ficou mais lento em uma nova versão
Já nas empresas que passei, toda semana era um problema diferente, clientes reclamando e caos 😂
/6
O conceito de "pronto" não é bem definido, então sempre levam tempo e o minimamente entregue como o fator de sucesso da entrega
No projeto Node.js, nada é mergeado se não estiver bem testado, afinal essa é a unica forma de validar se o que você fez realmente funciona
/7
Existem fluxos de CI que fazem benchmarking do antes e depois para validar o que deixou a plataforma menos performática e geram alertas
Além disso, existem pessoas toda semana, trabalhando para melhorar o que já funciona
/8
É algo que senti falta nas empresas que passei, definirem um dia da semana ou um tempo da sprint, para refatorar e melhorar o que já funciona
Ao invés de focar em implementar novas funcionalidades, gastar um tempo para garantir que o que existe, continue funcionando
/9
O minimo de qualidade de software, né?
E as vezes, jogamos a culpa na gerência, mas a real é que nós devs é que deixamos isso acontecer
Não deveria ser uma opção entregar software sem que cada funcionalidade seja completamente testada de forma automatizada
/10
Sinto que fazemos isso por aquela sensação de "preciso entregar rápido" e eu pessoalmente já cai nessa armadilha por tempo demais 😂
/11
A "pastelaria" só vai acabar, quando tomarmos vergonha na cara e definirmos nossos padrões de qualidade de entrega e provar que isso é valioso para o negócio
I've been creating videos on my youtube channel that you rarely will see in another place on the internet 🤩
You'll find there subjects like Recreating @nodejs from scratch, Web APIs and recreating web protocols such as the Web Socket using JS with no frameworks, etc
/2
And others, which are amazing experiments, such as recreating a code coverage tool from scratch and how to process terabytes of data using JavaScript
If you search about those subjects you'd reach out to my videos but why not have them as blog posts as well?
/3
Estava produzindo uma super aula do meu curso de Node.js Streams (em inglês), ensinando sobre como paralelizar o processamento de arquivos usando Node.js
A ideia é subir um processo para cada arquivo, e cada processo filtra os usuários que possuem o email em dominio gmail
/2
Só que eu automatizei a validação para verificar que todos os itens foram processados e enviados para um arquivo de saida
Então primeiro fui lá e usei o `grep` para filtrar o texto do arquivo e o `wc -l`, para obter a quantidade de linhas.
/3
The secret for processing anything using JavaScript is to handle data on demand.
Imagine data you wanna migrate data from a SQL database to a NoSQL DB. You would need to apply some business rules, clean up fields, filter data and then output them to the final output.
/2
You might know that you can block the Node.js (and the data source you're consuming) if you handle too much data at once in memory
The best practice then is to limit results, send individual data to a stream pipeline, and then ask for more data until you've consumed it all.
/3