DEV Community: Felippe Regazio

A NodeJS Package that verifies if a string contains a potential SSRF attack: ssrfcheck

Felippe Regazio — Wed, 17 Jan 2024 03:33:32 +0000

TL;DR;

Check if a given URI-String contains a possible SSRF (Server-Side Request Forgery) attack. Zero dependencies!

https://www.npmjs.com/package/ssrfcheck

The project

I created this NodeJS Package that helps to verify if a string contains a potential SSRF Attack, it can be used programmatically or as a CLI tool.

What is a SSRF Attack?

"In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like http enabled databases or perform post requests towards internal services which are not intended to be exposed."

source and more information: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery

How SSRF attacks may occur?

An SSRF attack may occur mainly if you have some kind of thirdy party configured information that provides URLs, domains or maybe URL parts for any kind of backend service of your application. As said before, this URL can be manipulated in many ways to force your service to sniff, retrieve private and sensitive information or scale access. For example: you provide an input to a common user to configure a postback URL on your service, well... you may be vulnerable.

Here are some SSRF payload examples:
https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server%20Side%20Request%20Forgery/README.md

The library

So, this library checks for potential SSRF attacks on a URL String. Zero dependencies.

You just import or require it and call a simple function:

const { isSSRFSafeURL } = require('ssrfcheck');

const url = 'https://localhost:8080/whatever';
const result = isSSRFSafeURL(url); // false

If you prefer, you can use it as a CLI by installing as a global dependency or just testing using NPX:

npx ssrfcheck <uri> <options>

E.g.:

npx ssrfcheck https://localhost:8080/whatever

What does this Lib check?

The library checks for complete URLs focusing on the protocol and domain structure and tells whether is a possible SSRF attack or not. This library does NOT checks for path traversal attacks or redirection attacks (server configuration). The checks are made in the following order:

must contain a hostname
must not be a login-url (e.g: https://user:pass@domain.com) (optionated)
cannot contain RFC forbidden chars: "<>\^`{|} (optionated)
cannot be a dot domain (e.g: https://./../.com) - commonly result of some trick
cannot be localhost or loopback domain
cannot be a private/reserved IP of any range
IPs are allowed but can be optionally blocked
checks for tricks: oct domain, decimal domains, special chars, schema tricks, etc..

If you wanna know more about test payloads and coverage, check the tests directory of the project. Test data lives in /tests/data folder.

Its Open Source

The project is open source, and PRs/Issues are welcome:
https://github.com/felippe-regazio/ssrfcheck

I Created a pure Unicode Code Highlighter :P

Felippe Regazio — Mon, 07 Nov 2022 18:09:24 +0000

The tool is called "Unilight". It is a simple parser and module that modifies unicode variation of string parts.

So you can highlight anywhere that doesn't accept rich editing, just have a pure string that accepts unicode variations. Works for almost any lang, take a look, this is a simple and pure STRING haha:

.......
// 𝕋𝕙𝕚𝕤 𝕚𝕤 𝕒𝕟 𝕖𝕩𝕒𝕞𝕡𝕝𝕖

𝗳𝘂𝗻𝗰𝘁𝗶𝗼𝗻 example() {
𝗰𝗼𝗻𝘀𝘁 a = "fizz";
𝗰𝗼𝗻𝘀𝘁 b = "buzz";
𝗿𝗲𝘁𝘂𝗿𝗻 a+b;
}
.......

You can highlight your code here:
https://felippe-regazio.github.io/unilight/

Source code and documentation here:
https://github.com/felippe-regazio/unilight

Warning:

This is a toy project made for aesthetic reasons only (just wanted to code). I made it because I wanted to study a few things about parsers and do something with it. However, there are important weaknesses of this technique:

Systems that do not support unicode will not display the text
Since unicode variations are hidden characters, the string will always be longer than it looks
Interpreters will not run the code because they don't know these chars, it will have to be sanitized

The tool is more useful for aesthetic reasons in fact, you can highlight simple snippets on a tweet, for example. I think the most interesting thing here is: The source code and the relationships between it (if you're a beginner/intermediate it might be a good thing to see given its simplicity), and the parser (if you're more advanced in js, good luck with that).

10 Dicas de Segurança para Projetos Front End

Felippe Regazio — Wed, 23 Mar 2022 22:42:53 +0000

1. Evite guardar tokens JWT (ou tokens importantes) na local storage

A LS é vulneravel a ataques XSS. O ideal é setar tokens num Http Only Signed Cookie, ou procurar outros meios de sessão afim de evitar a local storage pra guardar informações sensiveis.

Referencia de leitura para o item 1:

Here's why storing JWT in local host storage is a great mistake:
https://medium.com/kanlanc/heres-why-storing-jwt-in-local-storage-is-a-great-mistake-df01dad90f9e

2. Dados que serao interpretados como objetos ou HTML devem ser sanitizados e/ou escapados

Qualquer input/output vindo de wysiwyg, rich editor, markdown editor por exemplo. Isso evita ataque XSS (e roubo de tokens da storage rs)

Referencia de leitura para o item 2:

Dont sanitize, do escape!
https://benhoyt.com/writings/dont-sanitize-do-escape/

3. Validações de input devem ocorrer no front e no backend

Jamais uma validação critica ou de regra de negocio deve ser front only. Ex: input de email valida se a str é email? Valide no front e no back. No front pra evitar request desnecessária, no back pra evitar ataques ao DB.

Referencia de leitura sobre o item 3:

What is No-SQL Injection
https://www.invicti.com/blog/web-security/what-is-nosql-injection/

4. Não trafegue informações sensiveis via query param na URL

Exemplo: https://yoursite.com?token={important_token} - Se um atacante estiver assistindo o trafego da vitima ou fazendo sniffing, esse token nao sera criptografado e sera exposto numa conexão http-only. Caso vc esteja em uma conexao SSL, a query string estará resguardada na body, porem ainda sim estará exposta em server logs, historico do browser e JS history object num possivel XSS.

Referencia de leitura sobre o item 4:

Session token in URL - Vulnerability
https://www.acunetix.com/blog/web-security-zone/session-token-in-url-vulnerability/

5. Evite retornar/consumir um Array JSON diretamente via API

Tipo:

RESPONSE: "[{ ... }]"

Juro, isso expoe uma vulnerabilidade chamada "Primitive Object Override Attack" em que um atacante faz override de metodos de arrays. Pra saber mais, leia o link abaixo

Referencia de leitura sobre o item 5

Why Facebook's API starts with a for loop?
https://dev.to/antogarand/why-facebooks-api-starts-with-a-for-loop-1eob

Essa issue ja foi completamente corrigida em todos os browsers modernos há alguns anos. Vc nao precisa se preocupar com isso a menos que ofereça suporte para "old browsers"

6. Evite setar innerHTML diretamente em elementos no DOM

Evite muito setar innerHTML no codigo principalmente se o valor passou por algum input de usuario. Se precisar, procure sanitizar ou escapar o conteudo. Sempre que possivel, prefira utilizar innerText/textContent.

Referencia de leitura sobre o item 6:

DOM Manipulation and the dangers of innerHTML
https://betterprogramming.pub/dom-manipulation-the-dangers-of-innerhtml-602f4119d905

7. Evite permitir ao usuario fazer o input de URL ou load de SVG

Por ex: usuario inputar url a ser usado numa tag IMG. Diversos ataques podem acontecer, desde XSS via SVG ou PDF, ou Sniffing ao apontar o GET pra uma URL maliciosa
Referencia de leitura sobre o item 7 (embora fale sobre svg, a dinamica pra outros artefatos eh parecida: algo vem junto seja via request ou binary).

Do you allow user to load SVG? You have XSS
https://research.securitum.com/do-you-allow-to-load-svg-files-you-have-xss/

8. Utilize noreferrer e noopener para links cross-origin (de outro dominio)

Quando vc abre uma nova aba, a depender do contexto o browser pode enviar o objeto window da anterior para o novo endereço, permitindo assim umas bizarrices, vide link abaixo.
Referencia de leitura sobre o item 8:

External anchors and the rel noopener
https://web.dev/external-anchors-use-rel-noopener/

9. Adicione a Header "X-Frame-Options: DENY" ao seu front se possivel

Isso evita que pessoas embedem seu serviço num iframe e pratiquem ataques como "click highjack" em que um site é posto num iframe, e uma div eh inserida por cima pra interceptar o comportamento.

Referencia de leitura sobre o item 9:

Application Security: Clickjacking Attack
https://www.imperva.com/learn/application-security/clickjacking/

10. Essa é a mais simples de todas

Procure manter as dependencias atualizadas e ficar esperto com as vulnerabilidades que sao reportadas em pacotes NPM.

Então você quer ser Dev?

Felippe Regazio — Mon, 03 Jan 2022 14:29:47 +0000

Costumo receber muitas dúvidas de desenvolvedores iniciantes através das redes sociais. Tenho considerável audiencia tanto no twitter quanto aqui na DEV, e muitos deles pedem dicas e tiram dúvidas via inbox. Com o tempo notei que boa parte dessas dúvidas se repetem - salvo pequenas alterações - a maior parte são dúvidas naturais de inicio ou mudança de carreira.

Separei as 15 dúvidas que mais se repetiram ao longo de todo o ano passado neste post. Não sou nenhum coach, não sou jedi nem guru de nada. Sou simplesmente um programador com alguns anos de bagagem e paixão por programação, e resolvi utilizar essa condição para clarificar e/ou nortear alguns entrantes na área de tecnologia.

Sendo assim, esse post destina-se a pessoas que estejam pensando em entrar na área de programação e seguir carreira nela, e que estejam focando em aprendizado rápido, mercado de trabalho e em sua grande maioria em desenvolvimento web (que é também minha área). De qualquer forma, é possível que as dúvidas aqui sirvam para muitas outras áreas da programação também.

Precisa de Faculdade?

Não. Você não precisa de formação academica em tecnologia para entrar para o mercado de trabalho como desenvolvedor. Para outros fins em programação uma formação academica pode ser decisiva, ou/e até mesmo necessária, mas não para este.

Cabe dizer aqui que: assumir que a faculdade não é necessária não é o mesmo que dizer que não há benefícios em cursar uma universidade. Os benefícios podem ser incontáveis a depender do seu perfil e da sua condição de se manter-se em um curso superior de maneira proveitosa.

Cabe dizer ainda que: Em tecnologia, a universidade não é o conhecimento per si, mas um dos caminhos para ele. Isso pode aparecer como um alívio para muitos mas é na verdade uma grande responsabilidade: a não necessidade de uma universidade não quer dizer que vc pode negligenciar teoria e conhecimento academico, significa que vc deverá organizar-se e buscar sozinho por este conhecimento.

Se vc está iniciando e deseja ser auto-didata, aconselho a organizar um roteiro de estudos focados no que vc deseja aprender (seja conteudo academico ou nao), ou mesmo a pedir mentoria. Seja qual for o seu caminho, não deixe de dedicar algum tempo para estudar teoria de base como Algoritmos e Estrutura de Dados, Conceito temporal e espacial de código, Notação BigO etc.

Se vc crê que universidade é o melhor caminho de aprendizado para vc mas fica triste pois - por qualquer motivo - não possui condições cursa-la, acesse o repositório abaixo. Trata-se de um projeto de Conteúdo Academico Online, Livre, Gratuito e em PT-BR encabeçado por Camilo Cunha

Universidade Livre:
https://github.com/Universidade-Livre/ciencia-da-computacao

Preciso saber inglês?

Não, você não precisa saber inglês para iniciar em programação. Porém (há porem) vale ressaltar:

Busque aprender ingles. Você não precisa buscar fluencia, nem precisa aprender de hoje para amanhã caso não seja mandatório para seus planos de vida. Mas é bom aprender a compreender e se fazer compreender minimamente em inglês. Darei três motivos pra fazer isso:

Atualização: Boa parte dos estudos, pesquisas e tecnologias do mundo são documentadas primeiro em inglês, e apenas muito tempo depois saem traduções de documentação. Como você está iniciando não precisa se preocupar com isso agora, mas se visa atingir um alto desempenho como Dev, manter-se atualizado em primeira mão será importante, daí a importancia do ingles.
Autonomia: Ter um nível de ingles que te permita se virar pela internet te abrirá todo um novo universo online. Hoje tradutores automáticos já ajudam muito nessa questão, porém novas mídias poderão ser acessadas e melhor compreendidas por vc, como: vídeos de diferentes fontes, eventos online, pdfs, whitepapers, pesquisas, etc.
Contratação internacional: Mercados internacionais estão contratando cada vez mais de forma global. Boa parte das empresas também estão se globalizando através do trabalho remoto. Saber ingles te abrirá a possibilidade de trabalhar em muitos lugares do mundo (remoto ou não), aumentando seus ganhos e trazendo a ótima experiencia cultural.

Quais cursos devo fazer? Dicas?

Não sei te dizer. Muitos iniciantes perguntam para desenvolvedores mais experientes quais cursos fazer, onde aprender a programar, de que forma aprender... Acontece que esses desenvolvedores já são experientes, eles já se distanciaram desse início. As referencias podem ser outras, links podem nem mais existir, algumas tecnologias morreram, outras nasceram, assim é complicado dizer onde aprender o comecinho.

O processo de aprendizado de um desenvolvedor experiente pode ser diferente de um em inicio de carreira também, sendo que para o primeiro muitas vezes ler a documentação basta, enquanto que para o segundo é necessário maior fundamento antes.

Claro que isso não é verdade para todo e qualquer Dev Experiente, existem alguns engajados na comunidade e que possuem muitos recursos para ajudar iniciantes nesse quesito, mas no geral o melhor a fazer é envolver-se nas comunidades, conversar com outros desenvolvedores em inicio de carreira que já estão se evoluindo bem e/ou que tiveram inicios recentes, eles poderão dar um melhor mapa do tesouro.

Qual a primeira linguagem devo aprender?

A que você mais gostar. No ínicio, motivação e diversão são mais importantes do que qualquer outra coisa, pois é isso que te fará aprender e continuar querendo aprender. Então escolha a linguagem que mais te motiva, que mais te instiga a querer aprender.

Muitas pessoas argumentam que linguagem X ou Y são melhores porque são mais rígidas e isso gera um melhor aprendizado, ou facilita mais o aprendizado através de paradigma X ou sintaxe Y.

No inicio, quando vc ainda não sabe nada, toda linguagem servirá pra aprender as mesmas coisas, os mesmos fundamentos. Todas terão IF, todas terão WHILE, em todas vc escreverá funções que retornarão coisas, etc. Claro que há outros paradigmas, linguagens para outros fins, mas não é o seu momento.

Não adianta querer aprender a fundo Orientação a Objetos agora sem saber fundamentos, não adianta querer aprender paradigmas funcionais ou declarativos se vc ainda não aprendeu nem o que é um IF, um WHILE e uma Função e como essas coisas se relacionam num código. Sendo assim, o foco é mais importante que a linguagem. Escolha uma que te diverte e te instiga a aprender.

Algumas variaveis que ainda podem ser importantes na hora de decidir:

Fit com o que vc quer fazer: Se vc quer ser Dev web, veja o que os Devs web estão estudando. Se quer ser cientista de dados, veja o que cientistas de dados estão estudando e já comece por essas linguagens, assim vc corta caminho.
Comunidade: Dê uma fuçada nas redes sociais, foruns e na internet em geral pra ver se há ampla documentação e uma comunidade amigável em torno da linguagem que vc tá usando.

Na dúvida, escolha alguma super famosa que vc goste mais, não vai ter erro. Essa não é uma escolha definitiva, essa pode nem ser a linguagem que vc vai mais gostar (ou pode), e às vezes vc pode nunca nem chegar a trabalhar com ela (ou pode). Eu mesmo aprendi com Pascal (nunca trabalhei com isso), depois fui pro Python por conta propria, depois JS, etc, etc.

O que quero dizer aqui é que isso geralmente é super valorizado. Na real não é uma escolha de vida ou morte e nem de longe é definitiva. Sendo assim não precisa toda essa preocupação em torno disso. Pesquise, experimente e escolha a que mais gostar.

Quero ser Dev Web, o que tenho que aprender?

Existe um mar de conteúdo tecnico pra aprender, e isso por si já seria outro post a parte. É difícil entregar um RoadMap pra algum iniciante, mas por sorte existem alguns prontos. Sendo assim, comece pelo começo:

O que é a internet?
Como a internet funciona?
Como é a relação cliente vs servidor?
O que é, o que faz e pra que serve um navegador?
O que é exatamente backend e front end
Como rodo um codigo no front?
Como rodo um codigo no back end?

Isso já é MUITA coisa, e é o grande início. Me desculpem por não trazer links ou muitas referencias, mas como disse mais acima talvez eu não seja a melhor pessoa pra isso no momento. Espero que os comments fervam de boas referencias. No mais acredito que uma pesquisa na google ou Youtube sobre conteúdos de inicio básico em dev web devam trazer bons resultados, meu ponto aqui é mais: Não é simplesmente abrir uma IDE e sair tentando escrever código, tente imergir-se um pouco no contexto onde tudo vai acontecer primeiro.

Assim, antes de começar a escrever códigos, tente entender como tudo ao redor funciona. Não precisa virar expert no assunto, apenas as relações e caminhos entre as diferentes camadas pela qual os dados percorrem, e a história por trás do que vc está utilizando. Basicamente contextualizar-se.

Devo aprender frameworks primeiro?

Sim e não. Se o que vc busca é entrada rápida no mercado: Sim. Se o que vc busca é valorização e destaque a médio prazo: Não.

Se vc aprender um framework antes de tudo vc terá valor para o mercado e conseguirá trabalho rápido, porem será um profissional frágil em início de carreira. Vc sentirá de cara a porrada de ter pulado a base e o conceito ao precisar otimizar código, tomar avalanche de comments em code review e passar dias brigando com tasks ou tentando entender o código de outros desenvolvedores (normal).

Sendo assim, se você precisa muito de trabalho para agora, estude os frameworks e paralelamente a eles estude a linguagem a qual está trabalhando de forma pura. Entenda as particularidades, tecnicas, limites por detrás da tecnologia que vc está trabalhando. E quando conseguir seu desejado emprego, ou quando atingir bom grau de compreensão no que deseja aprender, volte sempre os estudos para a linguagem de forma pura. Pense que se vc sabe apenas um framework, toda vez que o mercado mudar é como se vc tivesse que recomeçar do zero, enquanto que saber as bases e fundamentos da linguagem a qual vc trabalha te ajuda a cortar enorme caminho e torna-se trivial aprender novos frameworks a partir daí.

Obs: Vanilla é o nome que damos ao uso de uma tecnologia em sua forma mais pura, sem frameworks ou boilerplates.

Caso vc já saiba a base, esse post que pode elucidar mais sobre esse assunto em se tratando de desenvolvimento web, especialmente front end:

https://dev.to/felipperegazio/o-minimo-que-vc-precisa-saber-de-javascript-pra-que-seja-confortavel-codar-e-aprender-qualquer-framework-front-end-4427

Qual área paga melhor?

Vc pode buscar isso na GlassDoor, LinkedIn, conversando com recruiters ou pesquisando em outras fontes. As areas oscilam, as experiencias podem ser muito diferentes de Dev pra Dev, de empresa pra empresa.

O mais importante é: Não baseie sua carreira em "ganhar o maior salario", ou ganhar igual o fulano do twitter ou do LinkedIn. Isso só vai te desmotivar. Defina a SUA meta e corra atrás, e mude quantas vezes for necessário conforme aprende coisas novas no caminho. Não é só porque vc não atingiu o topo que a vista já não esteja bonita de onde vc está. Se vc focar apenas no que paga mais poderá se perder no caminho toda vez que isso oscilar.

Vou começar ganhando 5 mil?

Não. Se vc está começando a aprender agora e deseja engressar no mercado o quanto antes, as chances são mínimas de começar ganhando 5 mil. Existem alguns caminhos, empresas que podem pagar esse valor para iniciantes, ou tendo ingles vc pode partir como junior para o mercado internacional, etc, etc. Mas via de regra, não é o que acontecerá. Como programador vc terá bons salários, boa perspectiva e rápida evolução salarial, isso de fato é verdade, mas não existe milagre de estudar 3 meses e ganhar 5 mil, isso é lorota.

Dá pra ser senior em dois anos? Vou demorar pra conseguir emprego?

Não. Você pode focar em UMA empresa e tornar-se senior para ela dois anos após ter entrado nela. Embora o que seja um senior é algo discutível, pensar em um profissional maduro com boa capacidade de entendimento de mercado, linguagens, soft skills, experiencia e agilidade, não é algo fácil de se atingir. Existe uma hype grande em torno da palavra senior e todo mundo fica correndo atrás disso e tentando cortar caminhos das mais variadas maneiras, e isso só significa uma coisa: definir o que vc pode deixar de aprender agora em prol de um "título".

No geral, preocupe-se em aprender e deixe essa preocupação em ser senior para os plenos. Uma pergunta que vc pode fazer é: dá pra ser pleno em transição pra senior em 1 ano? Dá pra virar pleno em 3 meses sem bagagem prévia, começando agora? Então, pois é: em geral não, e pra ser senior em 2 anos deveria. Então desencana.

Para você que está começando a buscar emprego agora, esse pode ser um post util:

12 Dicas NÃO TECNICAS para você que está buscando seu Primeiro Emprego na área de Desenvolvimento de Software

https://dev.to/felipperegazio/12-dicas-nao-tecnicas-para-voce-que-esta-buscando-seu-primeiro-emprego-na-area-de-desenvolvimento-de-software-3lfo

Vou ter que estudar durante toda a vida?

Sim, você vai. Seja através de curso, ou lendo docs toda semana, vendo videos, aprendendo coisas novas enquanto resolve problemas. Acostume-se a aprender. Aprenda as melhores maneiras de aprender, as que mais funcionam para você.

É importante entender que isso não é ruim. As pessoas costumam torcer o nariz quando digo isso, muito porque temos uma bagagem emocional advinda do método escolar de aprendizado, que é maçante e entediante e desprendido de motivo aparente ou significado prático. Mas isso não acontece em programação.

Quando vc começar a ser bom/boa no que está fazendo, quando começar a fazer seus primeiros códigos, ganhar fluencia como dev, quando ver seus primeiros salarios rendendo coisas legais vc será absorvido por um senso de valor e de evolução, e aí: Bem vindo/a ao estudo pelo prazer de evoluir! Aqui aprender novas coisas será motivo de alegria, e pode ser que vc entre numa dinamica parecida com ir à academia malhar: dói enquanto vc tá no processo mas te deixa muito feliz em ver os resultados todo dia, e quando vc não vai, vc sente falta até da dor.

Esse post pode dar dicas importantes para seu processo de aprendizado no que tange a aprender a perguntar e lidar com respostas a respeito de código:

https://dev.to/felipperegazio/como-fazer-perguntas-sobre-codigos-e-lidar-com-as-respostas-um-guia-pratico-1cf7

Não preencho todos os requisitos nunca, sou um iniciante ruim?

Não, vc é um iniciante. Hoje requisitos estão cada vez mais inflados. Será difícil ver uma vaga de emprego a qual vc preencherá TODOS os requisitos. Minha dica é: Se vc preenche a maioria, ou ao menos requisitos chave para a vaga, seja cara de pau e candidate-se. Seja honesto/a na entrevista, e bola pra frente.

Preciso de um super computador pra começar?

Na maior parte das vezes não. Mas vai precisar de algum computador. Sei que é difícil pra alguns, mas se vc puder ter um computador só seu é o ideal pois pode ser que vc troque ou quebre o seu sistema algumas vezes (é normal). Não precisa ser o mais rápido do mundo, e hoje existem muitos recursos gratuitos online caso vc precise de processamento pesado, é bom que já te força a aprender outras coisas rs. Se seu computador é compartilhado, estude mesmo assim e espero que vc consiga seu trampo e compre um só pra vc o quanto antes.

Preciso ser bom em matemática?

Sim e Não. Muita gente pode ficar brava comigo ao dizer isso, mas a verdade é que pra esse inicio - no contexto de hoje - não. Claro que isso pensando em entrada para o mercado de trabalho HOJE. Vc provavelmente vai buscar o ponto mais aquecido que é como dev web.

No geral vc não precisa ser foda em matemática pra começar a programar, mas saber matemática sem dúvidas te fará um/a Dev melhor. De qualquer forma, para algumas áreas pode ser que haja uma carga maior como IA, Data Analysis, NLP, etc. Porém esse é um requisito que pode andar JUNTO com seu aprendizado de programação, não precisa entender isso como requisito de entrada.

Preciso entender de hardware e redes?

Geralmente não. Vc pode começar a programar sem entender dessas coisas. Porem é bom saber o básico e dar alguma atenção, isso vai te ajudar a entender o contexto completo do que vc está fazendo, te dará noção de segurança, deployment, fluxo de dados e mais uma cacetada de coisas. Se não é muito sua praia, aprenda o necessário pra saber o que aconteceu com os dados que vc ta mexendo e bola pra frente. De qualquer forma, mantenha o foco: se vc é iniciante seu foco é iniciar, é aprender a programar, coloque o resto na pilha de pendencias e volte depois que: aprender a programar.

Tenho mais que 30 anos, estou velho pra começar agora?

Não. A área ainda é tomada de gente nova, mas isso por várias razões além das óbvias. Pense que ainda não somos uma geração tecnologica, existem pessoas vivas em nossa geração que nasceram antes da internet, e que não cresceram nela. Assim, novas geração virão e com ela outras gerações de programadores. Se vc tem 30 ou 40 anos, talvez sua rotina e responsabilidades sejam um desafio maior do que a sua idade, mas se ainda assim vc deseja encarar esse desafio, go ahead!

Conclusão

A motivação para eu ter escrito esse post foi não repetir as mesmas respostas de sempre. É cansativo para mim digitar as memas coisas para todo mundo, e também não é legal dar CTRL+C/V em algo que pode ser tão importante pra alguem, daí esse pequeno index.

Espero que essas respostas possam servir de norte para alguém uma vez que me pareceram tão recorrentes em minha experiencia como um velho intenauta, rs. Boa sorte em seus estudos, seja vc quem for.

I just launched a Free and Open Source Platform: CV Keep, a SAAS to keep an Online Resumé

Felippe Regazio — Wed, 27 Oct 2021 16:00:18 +0000

CV Keep - An Free and Open Source Platform

Im very proud and excited to have launched one of the biggest Free and Open Source projects I've ever done.

CV Keep is a complete platform to keep an Online Resume, and in this post I will talk about some features and highlights of this project.

Here is the live platform:
https://cvkeep.com

Presentation

The idea of the project is that anyone can keep an online resume quickly, beautifully, easy to manage and without the hassles of having to dive into a social network (trap) just to do this. And the platform is already internationalized. My CV for ex: https://www.cvkeep.com/cv/felipperegazio

The project was completely done by me, end to end. At the time I wanted to study some technologies and create a SAAS from scratch.

Also worth to mention: This project is a FOSS - Free and Open Source Software. You can use for anything your want, download the sources, put your own service up (even for commercial use) - since you don't use the same brand, you do not owe me anything.

In the next lines i will talk about technical aspects of the platform. That said, here are some useful links:

Official documentation:
https://cv-keep.github.io/cvkeep-docs/

GitHub with all sources + docs:
https://github.com/Cv-Keep

Stack

The project was done using a MEVN Stack: Mongo, Express, Vue and Node. It uses Vue-CLI 3 for Front End and no framework for styling.

Actually, the styling framework for this project was handcrafted and gave birth to a CSS Microframework made by me, and a Dev post here on DEV about SCSS architecture:

CSS custom properties with SASS/SCSS: A practical architecture strategy:
https://dev.to/felipperegazio/css-custom-properties-vars-with-sass-scss-a-practical-architecture-strategy-1m88

Plume CSS Microframework:
https://felippe-regazio.github.io/plume-css/

Architecture

The front talks to an independent RESTFul API, and both the Front and the API are modularized.

Still on the front, the project is a SPA/PWA with a service worker that delivers the app in a SUPER functional and light way, easy to convert to a mobile app.

i18n

The project is already internationalized between pt-br and en. It is very simple to translate, there is a section in the documentation dedicated to explaining how to add new languages.

The internationalization is independent between the Back End and Front End. In the Front I used Vue-i18n. In the Back I built an i18n lib dedicated to the project, called Express-REST-i18n, so that the API already delivers the content in the language that the front asks for based on Language headers, avoiding saving Back End matter in the front.

Here is the Express Rest i18n Middleware:
https://github.com/felippe-regazio/express-rest-i18n

Host

This project was optimized to the maximum i could do, so the cost is ridiculous. Today I run my instance with this infra:

A 7 dollars Heroku App
A Mongo Atlas (Free Tier)
A CloudFlare Free Tier

Other than that, I pay the annual domain. That's all the cost I have, and it's ready to scale if i need.

Thats all

Thats all folks. Just to say that I was happy to finish the project, and I hope it can be useful to someone.

12 Dicas NÃO TECNICAS para você que está buscando seu Primeiro Emprego na área de Desenvolvimento de Software

Felippe Regazio — Thu, 09 Sep 2021 03:30:47 +0000

Conseguir uma primeira vaga pode ser difícil. Embora a minha tenha sido há uns bons anos atrás, acho que tenho alguns centavos de conhecimento pra compartilhar sobre o assunto.

1. Estágio ou Self-Taught?

Muitas empresas contratam apenas estagiários no começo por motivos burocraticos, se vc (assim como eu) é auto didata, pode demorar mais ou ter que se provar mais no comecinho. Minha dica: Envie currículo mesmo assim. Tenha um projetinho pra mostrar.

2. Disposição é mais importante que conhecimento

NESSE MOMENTO INICIAL, uma empresa sensata não vai te cobrar uma toneladas de coisas. Espera-se que vc demonstre familiariedade (não esteja perdido na maionese) e demonstre curiosidade, vontade e disposição pra aprender e evoluir. Ninguém espera que vc esteja 100% habituado a conceitos sólidos de desenvolvimento, senão vc não seria um/a iniciante.

3. Faça parte de uma comunidade

Fazer parte de uma comunidade (mesmo que como expectador/a). vai te manter atualizado/a, vai moldar seu olhar e sua linguagem e te dará uma pequena imersão no mundo tech que, mais tarde, se converterá em senso de direção.

4. Se preocupe em aprender, não em aparecer

Vc não precisa chegar produzindo conteudo, enviando PR pra FOSS (Free and Open Source Software), questionando velhas práticas. Na verdade se vc tá fazendo isso, provavelmente
vc já teve seu primeiro emprego (?). Caso vc seja um beginner mesmo: Vc está aprendendo, então se preocupe em aprender.

5. Não finja ser o que vc AINDA não é

Um/a Dev experiente consegue sacar numa conversa se vc sabe mesmo do que está falando. Lembre-se, todo mundo já foi iniciante um dia, vc não é menos que ninguém por isso. Não precisa citar livro avançado fodão se ainda não é o seu tempo. Na verdade vc não deveria nem estar lendo livro avançado fodão, já que provavelmente não irá entender nada e ainda vai perder tempo. Digo novamente: se vc está aprendendo, se preocupe em aprender.

6. Não atire pra todo lado

Procure ser conciso/a. Aprenda o basico e siga estudando assuntos relevantes pro seu momento e meta de aprender o básico. Não pare do nada pra aprender Assembly Avançado (?) só porque você conseguiu fazer uma função recursiva por ex. É muito comum nos empolgarmos no meio do caminho e nos perdermos. Aprenda o que tem que aprender primeiro: foundations!

7. Aceite os ciclos do seu aprendizado

Cada um aprende de um jeito diferente, num tempo diferente. O que vai ditar a sua pressa será sua ansiedade e sua necessidade. Sabendo disso, corra atras das SUAS informações, baseando-se NA SUA necessidade e NOS SEUS planos. Não caia nesses papos milagrosos de cursos que te tornarão Dev foda em 6 meses. Isso não existe. Não queira burlar ou se entupir de coisas porque vc vai terminar cansado e achando que tudo é uma farsa. Procure se divertir nesse processo, aceite que vc "está começando", e realmente comece pelo começo.

8. Analise o mercado, trace SUAS metas

Busque vagas que vc gostaria de concorrer, ou que acha que é capaz de passar e analise os requisitos pra essas vagas. Agora ecolha 2 ou 3 tópicos e os estude afim de se aperfeiçoar pra enquanto vai se aplicando pra elas.

Enquanto corre atrás da meta sempre reavalie sua estrategia e suas escolhas enquanto as executa. Pesquise sobre suas decisões e se observe: eu to gostando disso? isso faz sentido pra mim? é mesmo como me fizeram acreditar que seria? Mantenha-se nesse loop de: executar e analisar. Para cada analise vc ajusta sua direção.

9. Mantenha o foco

Se vc resolver estudar tudo o que chamou a sua atenção ou tudo que estão dizendo que é legal, vc pode se perder num mar de tecnologias novas e chegar ao fim de 1 ano sabendo nada sobre nada, ou nada útil pra uma vaga factível. Escolha 2 ou 3 tópicos por vez e aprenda-os.

10. Cuidado com os cagadores de regras

Vc vai ver muita gente cagando regra por aí. Não se importe. Vc gosta de PHP? Estude com ele. Gosta de JS, daora. Sua praia é Python? Legal pra caralho. O importante é: encontre o que te estimula e estude essa porra, fodam-se os outros.

11. Estude os fundamentos, e estude uma tecnologia de necessidade

Mantenha-se sempre estudando os fundamentos, e em paralelo busque saber o básico sobre uma tecnologia de necessidade (react, no-sql, vue, sei lá). Não precisa mestrar no assunto, mas saber vai acelerar o processo. Pra descobrir a tecnologia de necessidade vc precisa unir duas coisas: o tópico 8 e o 11 desse post: Descuba o que te instiga, depois analise o mercado para descobrir se isso é uma necessidade mínima pra te colocar em um emprego em breve, se a resposta for sim: go ahead!

12. As coisas travam mesmo

De vez em quando vc vai demorar meses tentando entender algo de verdade. Diversifique a forma com que aprender: texto, video, exercicio, video, texto. É normal, uma hora vai. Fale sobre como venceu essas dificuldades na sua entrevista :D

Conclusão

O começo é foda. É normal, não desanime, continue a nadar, mova seu network, esteja presente na comunidade e aprendendo todo dia, sua hora vai chegar. Boa sorte!

O mínimo que vc precisa saber de JavaScript pra que seja confortável codar e aprender qualquer Framework Front End

Felippe Regazio — Tue, 07 Sep 2021 04:51:55 +0000

Pois é, vamos falar sobre o mínimo que vc precisa saber de JavaScript pra que seja confortável codar e aprender qualquer Framework Front End (React, Vue, Svelte, Angular, Ember, etc). Recentemente compartilhei isso no twitter e foi uma thread de muito sucesso, então vou deixar aqui também:

Eu vou partir do princípio que vc já sabe os fundamentos - HTML, CSS, JS Básico - e consegue criar páginas simples (como landings). O ideal é que vc seja capaz de fazer alguns CRUDS simples, mas senão tudo bem também, segue o fio e foco no estudo.

1. Fundamentos de JS

PRECISA saber coisas fundamentais como functions, tipos primitivos, operações básicas, loops e condicionais. Vc precisa ter passado pelo ensino fundamental do JS e isso tem que está claro na sua cabeça, não tem conversa.

2. Terminal Básico + Git

Seja qual for o S.O da sua escolha vc precisa saber se virar num Terminal (ou prompt), e precisa estar Ok com o básico de Git (push, pull, merge, rebase). Eu sei, isso não é JS, mas vale a menção né, rs.

3. Imports, Exports e NPM

Aprenda o que é e pra que servem Imports e Exports. Aprenda o que é, pra que serve, a instalar e a manter o Node e o NPM, bem como instalar, importar e desinstalar pacotes através dele. Isso é básico.

4. SASS - (Opcional)

"Ah mas isso não é JS". Pois é, o problema é que em frameworks vc pode lidar bastante com CSS in JS ou com coisas como "Styled Components", e geralmente a notação pra esses estilos é SASS. É fácil de aprender o básico e vai agregar muito, believe me.

5. Loops e Array Iterators

Entenda Loops e iteradores de Arrays, Objetos e outras estruturas. Busque entender iteradores mais profundamente e pra além básico, busque treinar coisas com: map, every, forEach, some, reduce, filter, for of, keys, entries, etc.

6. HttpRequests/Fetch

Entenda o conceito de fetch, ajax e requisições web. Se a coisa ficar muito esquisita nesse passo pode ser o momento de pausar e estudar o básico de arquitetura web: Protocolos, Client Side X Server Side, Requests e XhrRequests.

7. ES6 Basics

Const, Destructuring, Arrow Functions e Contexts. Claro que ES6 vai além desses pontos, mas esses são os que vc DEVE saber para tirar um bom proveito de um Framework JS.

We're good

Com um bom entendimento desses 7 pontos vc deve estar confortável pra aprender qualquer framework Front End sem grandes problemas. E sim, isso é BASTANTE coisa, e nem todo mundo pode parar completamente pra estudar isso, mas não perca esses pontos do seu horizonte.

Se vc é um Heavy Learner e curte/pode/consegue levar um ritmo de estudo mais intenso, vc pode ainda querer ver os pontos abaixo:

Extras

Hoisting e Conceitos de Runtime no JS - Sim, entender como o JS funciona por baixo dos panos e a lógica de máquina aplicada na hora de rodar seu código é mara. Sugiro ler o "You dont know JS" e começar do básico. Fist things first :D
Promises - Pois é Promises. Não tem muito o que falar, estude Promises e sua vida será mais fácil.
Design Patterns, Estrutura de Dados e Algoritmos - por fim, se vc não vem de um background fortemente academico, não deixe de ver esses pontos, vai ajudar muito na sua jornada com qualquer linguagem.

Conclusão

Eu sei que parece bastante coisa e que muitas vezes não dá pra estudar isso tudo antes de começar a codar num framework. O que sugiro aqui é vc não perder esses pontos de vista e ir complementando sua batalha prática com eles sempre que possível.

Após dominar estes pontos tenho certeza que vc estará confortável pra aprender qualquer framework JS sem nenhum percalço, e até iniciar em drogas mais pesadas como SSR, Tree Shaking, Code Spliting, Hybrid Apps, PWAs, Web Workers, etc

Cover Image by Stanley Dai @ Unsplash
Thats all folks.

Requests: A Diferença entre Ready State e Status Code

Felippe Regazio — Fri, 03 Sep 2021 17:34:49 +0000

Em se tratando de APIs algumas pessoas ainda podem confundir "Status Code" com "Ready State". Então vamo lá desembaraçar esse fio:

Toda request que retorna uma resposta (seja 200x, 300x, 500x, ...) é uma request bem sucedida do ponto de vista do browser. A request PER SI foi feita: ela saiu do seu browser, bateu no server e te devolveu algo, ainda que a resposta não seja a que vc esperava.

Essa verificação de "estado de requisição" é a Ready State. Isso não tem a ver se foi 200, 400, 500. Quando falamos de estados, estamos dizendo que a comunicação entre o browser e o server seguiu todos os seus estágios perfeitamente: algo foi enviado, e uma uma resposta foi dada.

Aqui vc pode ler um pouco sobre Ready States. Embora ela esteja atrelada a doc do XMLHttpRequest, a anatomia das Requests States são basicamente a mesma pra fetch e derivados (vc pode querer ver sobre preflight tbm): https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/readyState

Esse é o motivo de não devermos mandar Status Code 200 com { error: true } na body da resposta. Mas então se a Ready State define o estado de tráfego da requisição, pra que o Status Code?

O Status Code informa o posicionamento do Server referente a sua request. Ou seja: vc pediu algo, o server te entregou junto com um bilhete dizendo o que aconteceu lá.

Assim, se vc retorna um 200, vc não está dizendo que a REQUEST EM SI foi bem sucedida. O browser já sabe disso através do Ready State. Um 200 está dizendo que o server vai entregar o que ele deveria entregar.

Ou seja, o Status Code determina o STATUS da sua resposta, e não o ESTADO da requisição. Por isso vc deve retornar os status corretos para cada resposta.
Retornar 200 com { error: true } seria o mesmo que dizer: ta tudo bem, só que não.

Concluindo

Ready State: Determina se tudo correu bem na request referente a comunicação do browser com o server e o recebimento da resposta.

Status Code: Determina a natureza da resposta dada pelo server. É o motivo abreviado da resposta dada e deve ter peso semantico.

How to ask for help about code, and how to deal with the answers. A practical guide

Felippe Regazio — Wed, 18 Aug 2021 22:35:34 +0000

How to ask for help about code and deal with the answers

For the rest of your life as a developer you will bump into problems that you simply DONT KNOW how to start, how to solve, and you will need to discover by yourself. Its part of the game. How you handle this situation will define part of the type of professional you are and will be. the way that you will organize the problems, thing, present and attack them matters. So let's go to some important points about it:

1. Find the root of your doubt

Did you get the task but didn't understood the description? So it's useless to ask the Dev next to you "hey, I don't know how to do handle this, can you help me?". Even if he/she explains, you won't understand because you didn't even understood what to do, or what kind of problem is happening.

It's okay not to understand the briefing, it means you have a clear reason to ask for help. But its a problem pretending to understand, trying to get things done without clear information and end up stucked.

The task description said to do something in the login but you don't know "what login?", ok: ask. Missing info in description? Notify someone. You really don't understood, ask Lead, PM, PO... Trying to coding something without a clear understanding of what to do is by itself a problem.

2. Try not to pass the ball

Let's imagine that you got a task: show a new message after login. You read the task, understood the briefing, started to code, but suddenly nothing makes sense. Nothing works. This is where most beginners ask someone WHAT to do, and not HOW to do (because you even know what you dont know).

Often the Dev's first move is to call a colleague and say, "I need to show a message after login but I'm not getting it, how could I do it?"

This is not exactly a question, you are passing the ball. The person will basically tell you how to work. And thats ok sometimes, you can learn with it too. But if this starts to get recurrent, then it's better to follow the next steps:

First identify your difficulty

You can't start because you don't know which file to move? Not sure which function to use? Do you know the files but at the time of displaying the message you don't know how to do the modal? Or do you have a lib to show the message and you don't know where is the docs?

These are real doubts. See that then the way to build your questions would change:

Hey, I need to show a message after Login but I don't know what file or function it is in, can you show me?

I'm giving a console log here because I don't know how to do the modal, or if I should use lib, could you help me?

In other words, before declaring to someone that you have NO IDEA WHAT TO DO and need help to give baby steps, it's better to try, look at yourself and think: which part exactly am I not understanding?. Ask a question after question after another if you need to, no prob.

See that I'm not saying that you can't ask someone to show you how to do something entirely. I'm telling that this shouldn't become a modus operandi because will harm your learning and the team dynamics. Try to do it first, understand your own difficulties, list them and ask for help objectively. That way you help yourself to learn, and help the team to help you.

3. Have the ownership of your task

Let's say then that you understood the briefing, did the task, asked for help, pushed the code and tadááááá: A WILD BUG APPEARED.

The worst thing you can do when informed of the bug is to say, "But I did it the way Juliana (or anyone else on the team) told me to do it".

Bug report is not blaming. If someone informs you of a bug, you listen and solve it. Then starts all again.

Sometimes you can say this unintentionally, but it's like trying to blame the other for a non-existent consequence of your own task.

If you do a task, ask for help and then say "but I did it the way X-Person told me to do it", the person who helped you will probably think 10 times before helping you again. Even if nothing comes out of it. Remember: you can ask for help but the task is yours.

The responsibility for bugs should be with the whole team. This is one of the effects of doing code review: other people saw the code, other people approved it. Other people are naturally involved, you don't need to be afraid of being wronged (at least in a healthy team).

4. Ask for Pair Programming

Let's say that you really can't organize your head, you got the task, you have the ownership, you are motivated, but you you have no idea about how to solve it, you need to ask someone to untangle: Ask a colleague for a pair programming :)

If you're totally lost, instead of sending a message or poking the other dev and asking implicitly to "explain how to do your task", ask for a pair: among other things, that's what a pair its for.

5. BE HONEST when in doubt

Don't ask questions pretending to know more than you really do, or embarrassed. Okay to ask (if not, you are on the wrong place). You need a pair prgramming and it's lost? Ok, ask for help: "Hey, can we pair? I have no idea about how to attack this problem". Thats totally ok.

If what you have is a specific doubt, be frank: Hey, I read React's useState documentation, I did what was there, I tried a few things but nothing worked, it's buggy, I don't think I understood, could you help me? Sometimes, the way you ask can make the problem easy to solve.

Conclusion

If you have a cool team, the team will welcome you and you will all grow together, and knowing how to organize and present problems for the team is a skill that you should try to improve as much as possible.

Cover image by NeONBRAND on Unsplash.

Como fazer perguntas sobre códigos e lidar com as respostas, um guia prático

Felippe Regazio — Tue, 17 Aug 2021 14:56:11 +0000

Como fazer perguntas sobre códigos e lidar com as respostas

Pro resto da sua vida vc como dev vc esbarrará em coisas que vc não faz A MENOR ideia nem de por onde começar. Como vc conduzirá essa situação definirá muito o tipo de profissional que vc é e será. A maneira que vc colocará os problemas, os organizará e os apresentará aos outros deve ser vista como parte da solução de um problema. Então vamos a alguns pontos importantes:

1. Identifique a raiz da dúvida

Vc pegou a task mas não entendeu a descrição? Então não adianta perguntar pro Dev ao lado "hey, não sei como fazer isso, pode me ajudar?". Mesmo que ele te explique vc não entenderá, pq vc não compreendeu nem o que é pra fazer, que dirá como fazer.

Não tem problema em não compreender briefing. Tem problema em fingir que compreendeu, tentar se virar e ficar travado/a. Vc leu que é pra fazer algo no login mas não sabe "que login?", pergunte. Falta info na descrição? Avise. Realmente não entendeu, pergunte pro Lead, PM, PO...

2. Cuidado com a "Batata quente"

Imaginemos então que vc pegou uma task: mostrar uma mensagem nova após o login. Vc puxou a task, entendeu o briefing, começou a codar, mas de repente nada faz sentido. Nada funciona. Aqui é onde muito iniciante comete o primeiro erro: Repassar a task inconscientemente.

Muitas vezes o reflexo do Dev é chamar um colega e dizer: "Preciso mostrar uma mensagem após o login mas não to conseguindo, como eu poderia fazer?".

Isso não é uma dúvida, isso é repassar a task. A pessoa basicamente te dirá como trabalhar.

Repassar inconscientemente a task no começo é SUPER OK. Beleza vc estar perdido e pedir ajuda. Mas se isso começa a ficar recorrente, daí é melhor seguir os proximos passos:

Primeiro identifique seu problema

Vc não consegue começar pq não sabe em que arquivo mexer? Não sabe que função utilizar? Sabe os arquivos mas na hora de mostrar a mensagem não sabe fazer o modal? Ou tem alguma lib pra mostrar a mensagem e vc não sabe?

Essas são duvidas reais. Veja que aí a forma de construir sua duvida mudaria:

Hey, preciso mostar uma mensagem após o login mas nao sei em que arquivo ou função ele está, pode me mostrar?

To dando um console log pq não sei fazer o modal, ou se devo usar lib, poderia me dar uma luz?

Ou seja, antes de declarar pra alguem que vc nao faz IDEIA NENHUMA DO QUE FAZER e precisa de ajuda pra dar baby steps, vale mais a pena tentar, olhar pra si mesmo e pensar: o que exatamente não to conseguindo fazer. Faça uma pergunta depois da outra se precisar, no prob.

Veja ainda que nao to falando que vc não pode pedir pra alguem te mostrar algo por inteiro. To falando pra isso não virar modus operandi pq a equipe vai sacar. Tente fazer primeiro, entenda suas proprias dificuldades, liste-as e peça ajuda de forma objetiva, e não "socorro". Dessa forma vc ajuda a si mesmo a aprender, e ajuda a equipe a te ajudar.

3. Tenha ownership da sua tarefa

Digamos então que vc entendeu o briefing, fez a tarefa, pediu ajuda, subiu a task e DEU UM BUG.

A pior coisa que vc pode fazer ao ser informado do bug é dizer: "Mas eu fiz do jeito que fulano me falou pra fazer".

Informe de bug não é culpabilização. Se alguem te informa um bug, vc escuta e resolve. Fim.

Às vezes vc pode dizer isso sem ser por mal, mas é como tentar responsabilizar o outro por uma consequencia inexistente ainda por cima.

Se vc faz uma task, pede ajuda e depois diz "mas fiz do jeito que fulano falou pra fazer" se algo errado ocorre, provavelmente a pessoa que te ajudou vai pensar 10x antes de te ajudar de novo. Mesmo que não dê em nada. Lembre-se: vc pode pedir ajuda mas a task é sua.

4. Peça por um Pair Programming

Digamos que realmente vc não consegue organizar a sua cabeça, vc tem ownership da task, não quer responsabilizar ngm, mas simplesmente não vai, vc não faz ideia, precisa pedir pra alguem desensroscar: PEÇA UM PAIR.

Se realmente a coisa não desenrosca e vc ta mais perdido que cego em tiroteio, ao inves de mandar uma mensagem ou cutucar o outro e pedir implicitamente pra "te explicar como fazer sua task", peça um pair: dentre outras coisas é pra isso que serve pair.

5. SEJA FRANCO/A na duvida

Não faça perguntas fingindo saber mais do que vc realmente sabe, ou com vergonha. Ta tudo bem perguntar. Precisa de um pair e ta perdido/a, pode falar: Hey, pareia comigo pq to enroscado/a aqui e realmente não sei o que fazer. A pessoa ja vai preparada.

Se o que vc tem é uma duvida pontual, seja franco/a: Hey, li a documentação do useState do React, fiz o que tava lá, experimentei umas coisas mas a task nãos ai, ta bugando, acho que nao entendi, me ajuda?

Conclusão

Se vc tiver um time legal, o time vai te acolher e vcs todos vão crescer juntos com as duvidas e dando apoio um para o outro, sem deformações de ownership, sem sentimento de culpa, simplesmente por: saber como perguntar. Thats all folks.

Cover image by NeONBRAND on Unsplash.

Logflake, a NodeJS Console Logger with superpowers

Felippe Regazio — Wed, 04 Aug 2021 15:38:54 +0000

I just finished this lib that i've been working on for the few past weeks. LogFlake is a NodeJS console logger with superpowers. It has the same API as the usual Console but with beautified output, a message header with timestamp and useful information, trackability and a toolset for a better control of your log messages. You can check out the lib and the docs on this link: https://www.npmjs.com/package/logflake.

I decided to write this lib because i like the Console simplicity, but i miss some features. I was searching for a very simple, out of the box tool just to have better output and control of the console message logging. Then i wrote "logflake", which is pretty neat and, despite lots of options, requires zero configuration to use its basic features.

The lib was written with TypeScript, and tested with Jest. It has a test coverage (unity and integration) near 90%, and its available on NPMJS. You can download, or install it using npm/yarn.

Getting started

I'll show some of the basic features. If you like it, please consider to leave a star on GitHub. PR's are very welcome!

Hands on, you can install it using NPM or Yarn:

npm install logflake

Then you must create your log function (you can give the name you prefer). In CJS

const logger = require('logflake');
const log = logger();

or EJS

import logger from 'logflake';
const log = logger();

Now you can log things. As said, it has the same API as Console, with some advantages.

log('Hello world');

Will output:

The console header shows a namespace CONSOLE LOG , followed by the O.S indentifier, O.S username, current mainfile, date and time. You can configure the header and decide which information you want to show.

You can log anything you want, or how many things you want. For example, this is the log function logged by itself:

log('Hello %s', 'world', log);

Will output:

Log levels

The first log function argument can be used to change the log level. You can use the following log levels:

log (blue)
info (cyan)
warn (yellow)
error (red)
trace (magenta)
quiet (no console output)

An error, for example, would be:

log('error', 'Unexpected error', 500);

And would produce:

Namespaces

Now lets imagine that you have lots of logs in a huge and distributed application. You can add a namespace for each log function to make them easier to find:

const logger = require('logflake');
const log = logger('Example'); // Example is the namespace

log('error', 'Unexpected error', 500);

Note the [ EXAMPLE ERROR ] prefix on the log header:

Options

Logflake accepts lots of options passed directly to the "logger". To illustrate some of them, lets say you want to count how many times a log was triggered, and save its output on a local file. You could do:

const logger = require('logflake');

const log = logger({
  prefix: 'Example', // Now we pass Namespace as an option
  logDir: './',      // Directory to save the logs
  callCount: true    // Count how many times a log happened
});

/**
 * Now lets pretend this error happened 1000 times
 */
for (let i = 0; i < 1000; i++) {
  log('error', 'Unexpected error', 500).save();
}

This will output:

(...)

Note that the function now has a count (x1000, for example). Since we passed the option "callCount", it indicates how many times the log has been triggered on the current runtime. The save() method tells the logger to save each log output (of this specific call) to a file on the directory passed on the logDir option. The logger will automatically organize the different log files by date.

Methods

Now lets say you dont want to pass the save() method to specific log calls, instead you want to save all of them. Also you dont want to polute your log file with 1000 duplicated log registers, just one is enough to alarm the team.

You can ask LogFlake to save all logs for you, and to save some of them only once, like that:

const logger = require('logflake');

const log = logger({
  prefix: 'Example', // Now we pass Namespace as an option
  logDir: './',      // Directory to save the logs
  alwaysSave: true,  // Save all log outputs to a log file
  callCount: true    // Count how many times a log happened
});

log('I'll be saved also :3');

for (let i = 0; i < 1000; i++) {
  log('error', 'Unexpected error', 500).once();
}

The code above will save the first log, then will trigger and save the error log only once, despite being inside a 1000x for loop, because of the .once() method. All logs will be automatically saved due the alwaysSave option. Since the once has been used on the error, it will be saved only once.

We can also imagine that this is a very important log for you, and you want to send an alarm with its content to slack when and if it fires. LogFlake STILL dont do that (the slack thing), but you can get the log output + information and sent to whatever you want:

log('error', 'Unexpected error', 500)
  .once();
  .get((output, info) => {
     /* do whatever you want with output and info */
   });

As showed above, we are getting the log output using the get method. The output param will contain the string representing the log exactly as showed on the console. The info` param is a useful object containing information about the log as level, call count, trace, etc. You can also automatically trap all log outputs, allowing you to send them to slack, a database or whatever you want.

Conclusion

There are lots of options and usages to LogFlake and would be a huge post to show all of them, those were only some cool examples. If you liked, you can checkout the complete documentation and sources at GitHub: https://github.com/felippe-regazio/logflake.

As already mentioned, this lib is intended to be VERY simple and useful. Its a very handy way to track and save some runtime information while running your code.

Cover image by Jason Richard at Unsplash

JavaScript and the object keys automatic deduplication

Felippe Regazio — Tue, 22 Jun 2021 23:05:08 +0000

Imagine that you have a hard coded JS config file somewhere on your project (or any kind of object). Something like that:

const whatever = {
  base: 'anything',
  port: 123456,
  secret: 'just-to-illustrate-asdjf23u',
  port: 123568,
};

Probably you saw the error. The "port" key is duplicated. This is a very specific situation, when a key is duplicated at declaration level. Although it is very rare to pass to the production because will probably be spotted on lint, code review or test phase, i would like to talk about it a little bit.

JavaScript will silently normalize this object with no error or warning. This is understandable: if the object was created with a duplicated keys it would be an invalid object by definition. So there were 2 choices:

Deduplicate keys before create the object
Raise an error

JS will deduplicate the object keys (remove duplicated keys) for you at runtime, resulting in:

{
  base: 'anything',
  secret: 'just-to-illustrate-asdjf23u',
  port: 123568,
}

Buuut, the object is still misspelled. Of course, as already said and for the sake of your project, you are probably using a linter, a superset like TS and have a good code review and test process and this error wont pass. This also reinforce the good practices and automation tools on your code.

Even if you are in 'use strict', no error, no warning, no information will be thrown. Try to execute the following code:

'use strict'

const test = {
  fizz: 'fizz',
  fizz: 'buzz'
};

console.log(test); // { fizz: 'buzz' }

This is acceptable when you think that an object with duplicated keys would be an structure violation, so the object is normalized even in "strict mode" as a design decision, i guess. Again no error is thrown. Here is what the RFC says about it:

Each own property of an object must each have a key value that is distinct from the key values of the other own properties of that object - https://262.ecma-international.org/11.0/#sec-object-type

As you saw, there is nothing about how this kind of violation must be treated (or i didnt found it till now). This is also a kind of thing you cant validate at runtime. You can think in stringify and validate, check the structure on a for loop, but everything will fail because the object is normalized before anything. Do the test:

const test = Object.freeze({
  fizz: 'fizz',
  fizz: 'buzz'
});

console.log(test); // { fizz: 'buzz' }

As you can see, the object was normalized and then freezed. Anything you run against the object will run on a ready-normalized object. But as said, the "typo" on the object declaration remains there.

This is of course a very very specific discussion, but shows us the importance of process and tools not only at runtime, but also at lexical level, since some errors are very tricky and tiny and can be spotted only that way.

Some people argue that this behavior is due to features like spread operator. As I have no evidence of yes or no, I would prefer to hear the comments.

Anyway, a duplicated key on a config object can be confusing and lead to misinformation. You read a value but the server is running against another because you didn't notice the same duplicated key/value below, or at best, its just an annoying lexical error. Its very easy to avoid, unlikely to happen,
but I thought it would be nice to talk about it.