DEV Community: Eduardo Cerioni Cappellotto

Onde aprender (ou revisar) conceitos importantes de Next.js?

Eduardo Cerioni Cappellotto — Wed, 10 Jan 2024 21:15:34 +0000

O texto de hoje é uma dica para você, desenvolvedor web que sempre teve interesse no Next.js ou que já trabalhou com ele no passado e deseja reacender sua relação com essa ferramenta queridinha da Vercel. 😊

Meu Contexto

Minha primeira experiência com o Next.js aconteceu por volta de 2020, quando essa "nave espacial" 🚀 criada pela Vercel começou a decolar. Desde então, o cenário web adotou amplamente o TypeScript e abraçou de vez o server-side rendering. Profissionalmente, acabei me envolvendo mais com o lado "verde" da força (Vue + Nuxt) e foi lá onde passei os últimos 3 anos.

Agora, em um novo momento da minha carreira, decidi revisitar o que o Next.js oferece e como ele funciona.

Minha Escolha

Eu poderia ter optado por fazer um curso. 📚
Eu poderia simplesmente ler a documentação. 📖
Eu poderia até mesmo apenas construir algo do zero. 🏗️

Bem, fiz a minha escolha:

Reescrevi meu site pessoal, https://eduardocappellotto.com/, usando o Next.js (o código está disponível aqui: https://github.com/eduardocappellotto/cappellotto-portfolio).

Explorando os Tutoriais da Vercel

No entanto, também me veio um pensamento: os tutoriais do Nuxt feitos pela equipe central são tão úteis... E quanto aos tutoriais da Vercel?

Acontece que os tutoriais de Next.js (e também de React.js) da Vercel são excelentes e merecem mais reconhecimento! Eles te guiam na criação de pequenos projetos, ajudando a entender pontos essenciais do framework.

A Dica de Hoje: Tutoriais da Vercel

E essa é a dica de hoje: A Vercel disponibiliza ótimos tutoriais de Next.js e React.js diretamente em seu site: https://nextjs.org/learn

Peço desculpas pela falta de padronização. Aqui estão as duas partes padronizadas com listas de itens em ambas:

Trilha de React.js - Pré-requisito para a Trilha de Next.js!

Antes de mergulharmos na trilha de Next.js, é crucial adquirir uma base sólida em React. A trilha de React.js oferece uma introdução a conceitos fundamentais que você deve dominar, incluindo:

O que é o DOM?
Como alterar a interface do usuário com JavaScript.
Como o React funciona.
Trabalho com props.
Uso de componentes.
Gerenciamento de estado.
Diferenças em relação ao Next.js.

Aqui está o link para a trilha de React: Trilha de React

Trilha de Next.js

Agora que você possui uma compreensão sólida de React, pode avançar para a trilha de Next.js, que aborda os seguintes tópicos:

Estilização: Explore diferentes abordagens para estilizar sua aplicação no Next.js. 🎨
Otimizações: Saiba como otimizar imagens, links e fontes para melhor desempenho. 🚀
Roteamento: Crie layouts e páginas aninhadas usando o sistema de roteamento baseado em arquivos. 🌐
Recuperação de Dados: Configure um banco de dados na Vercel e siga as melhores práticas para buscar e transmitir dados. 💼
Pesquisa e Paginação: Implemente pesquisa e paginação utilizando Parâmetros de Pesquisa na URL. 🔍
Mutação de Dados: Aprenda como modificar dados com as Ações de Servidor do React e revalide o cache do Next.js. ✏️
Tratamento de Erros: Saiba como lidar com erros gerais e erros 404 não encontrados. 🚧
Validação de Formulários e Acessibilidade: Realize a validação de formulários no servidor e aplique dicas para melhorar a acessibilidade. ♿
Autenticação: Adicione autenticação à sua aplicação utilizando o NextAuth.js e Middlewares. 🔐
Metadados: Acrescente metadados e prepare sua aplicação para compartilhamento nas redes sociais. 📊

Agora, você está pronto para explorar ou aprofundar seu conhecimento em Next.js e React.js, começando pela trilha de React.js como um sólido pré-requisito antes de avançar para a trilha de Next.js. 👨‍💻👩‍💻

Portanto, se você está pronto para explorar ou aprofundar seu conhecimento em Next.js e React.js, esses tutoriais da Vercel são um recurso valioso que merece sua atenção. 👨‍💻👩‍💻

Progredindo em ambientes caóticos - a visão de um dev

Eduardo Cerioni Cappellotto — Fri, 21 Oct 2022 04:59:59 +0000

Em minha jornada de desenvolvimento, atuei por ambientes caóticos onde o tal caos estava presente em diferentes sabores. Nesse artigo, busco discutir sobre como você desenvolvedor pode sobreviver (e progredir) nesses ambientes e também conto um pouco de minha experiência pessoal.

O caos pode se manifestar de diversas formas e durante diferentes períodos. Não acho que enfrentei todos (possuo uma carreira relativamente nova), mas já provei de alguns sabores de caos e com eles aprendi uma coisinha ou outra.

O caos nosso de sexta-feira

Todo desenvolvedor já passou por um momento de caos nosso de sexta feira: aquele famoso deploy de sexta-feira que dá errado e torna o ambiente caótico por um tempinho.

Costuma ser um caos passageiro e que nos ensina lições quase que instantâneas. É durante esse momento em que nos são apresentadas as deficiências em nossos processos e a observabilidade de nosso código.~

Meu(s) aprendizado(s) para sobreviver ao caos nosso de sexta-feira: foi:

Don't panic!... ou pelo menos não em público. Pânico, acusações de culpa e afins não vão resolver o problema. Xingue no twitter (fechado), xingue no grupo de whatsapp de seus amigos, xingue pra namoradx. No chat corporativo seja prestativo e busque informar TUDO o que está acontecendo.
Anote os valiosos insumos do problema que rolou. Com isso em mãos, você consegue não só estudar e propor resoluções posteriormente (caso o problema esteja em sua responsabilidade) como estudar e apoiar a criação de resoluções mais eficientes no caso de problemas em terceiros.
(*) Esse é um extra: deploys em sextas-feiras podem realmente não ser uma boa ideia. O argumento é muito mais psicológico do que prático, mas, software é construído e utilizado por pessoas.

O caos C4

Existem ambientes onde o caos está presente no cotidiano: sistemas legado mal construídos e com pouquíssima documentação, tecnologias com baixa adesão no mercado... a tal "bomba relógio" que todo dev já ouviu falar dentro de uma empresa.

Você possui duas formas de sobreviver á projetos legado ruins:

Propõe com muito estudo e munido "habilidades de venda" a criação de um novo projeto á fim de substituir o legado

OU

Aprende á lidar com as partes as quais você interage desse código legado. Eu mesmo já aprendi coisas incríveis lendo códigos legado.

O caos darwinista

Quando uma empresa (ou o país/mundo) passam por momentos de crise econômica por exemplo, o caos é generalizado: o CEO da empresa cobra os vices...

...que cobram os diretores
...que cobram os superintendentes
...que cobram os gerentes
...que cobram os gestores
...que cobram ..

Bom, você entendeu: a cobrança torna-se generalizada. . E nesse caso, você acaba sendo muito levado pela maré: Muitos sofrerão layoffs e quem sobrar fatalmente trabalhará sobrecarregado.

Sinceramente, como dito no parágrafo anterior, esse caos pode te afetar muito e você possui pouca ou nenhum controle desses fatores. Mas, você consegue ao longo de sua trajetória dentro da empresa tentar se tornar insubstituível.

No fim, ninguém é insubstituível. Mas se você se envolver com os projetos da empresa e for engajado dentro de um ambiente corporativo, você se torna um alvo mais dificil de se mandar embora.

Sobre os erros na construção de um software - a visão de um desenvolvedor Júnior

Eduardo Cerioni Cappellotto — Mon, 07 Mar 2022 19:54:04 +0000

Após quase um ano atuando em um projeto desde sua concepção até sua primeira entrega, decidi "olhar pra trás" não somente para me questionar sobre tudo o que foi construído mas para também me questionar sobre onde eu e o time erramos.

A importância de uma arquitetura pré-estabelecida

Nesse projeto, seguimos uma especificação funcional. Uma especificação funcional contempla as funções básicas de uma aplicação.. opa, deixe-me repetir essa palavra: básicas.

Talvez seja muita presunção minha, mas, acredito que além de uma especificação funcional, um esboço de uma especificação arquitetural também fosse necessária. Como desenvolvedor que sempre trabalhou em startups pequenas e era recém-chegado na empresa, em muitos momentos a escala de centenas, milhares e até milhões de dados me fez cogitar saídas que, devido á escala, não eram viáveis. Não sei também em totalidade quais bancos e search engines temos á disposição ( e áo descobrirmos, muitas vezes é nosso primeiro contato com essas ferramentas ).

Com uma arquitetura mais pré-estabelecida conseguimos nos preparar melhor também no que viriam á ser débitos técnicos no conhecimento de ferramentas.

Por exemplo: nenhum dos desenvolvedores que atuou no projeto possuía efetivamente experiências anteriores com o banco de dados utilizado, e, o foco foi em "aprender fazendo" e não "aprender e fazer". E nisso nascem más-práticas que se proliferam pelas raízes projeto.
Dominar a linguagem e exercitar a modelagem de um banco é essencial para manter uma escala saudável no projeto.

Não tornar boas práticas desde o início

Julgo que temos uma qualidade de software mediana. Faltam muitas coisas, mas já seguimos bons padrões. Principalmente a falta de testes de integração no back-end é algo que efetivamente me preocupa á longo prazo.

Sempre fui entusiasta de testes e vejo a entrega de valor ( e a prevenção á incêndios ) que testes básicos porém bem estruturados entregam.

Há também alguns débitos técnicos no front-end: componentes grandes que poderiam ser menores, lógicas pouco e/ou nada comentadas e inconsistências em seguir alguns padrões dentro do sistema.

A falta de documentação estruturada

Esse aqui eu julgo ser um problema de muitas companhias: gerar documentação não gera valor efetivo pra stakeholders, mas, gera velocidade na criação de software. Até por isso, ferramentas como GraphQL que geram docs automaticamente têm seu valor intríseco.
Mas um swaggerzinho organizado não faz mal á ninguém 😂

Code review "camarada"

Julgo que aqui jaz o nosso maior erro: realizar pouquíssimos code reviews propondo efetivamente mudanças e/ou melhorias.

Quem melhor poderia nos policiar de subirmos inconsistências e códigos de qualidade duvidosa somos nós mesmos, e, por opção escolhemos deixar muita coisa passar.

Seja por pressa em "subir aquelas mudanças" ou em simplesmente acreditar que "isso é o jeito que ele(a) coda, não é melhor ou pior: é apenas diferente".

Mas.. tudo foi ruim e/ou mediano?

Não!

Na realidade, o projeto andou muito bem mesmo com as várias interpéries de um projeto realizado no mundo real. Construímos um sistema extremamente robusto e que resolve muitos problemas atuais e futuros da empresa, e sou extremamente grato por tudo que aprendi e aprendo diariamente participando da criação de um sistema do zero.