Forem: Manu Coutinho

Funções Lambda em Java

Manu Coutinho — Mon, 03 Feb 2025 22:09:28 +0000

Você sabia que as funções lambda foram introduzidas na linguagem Java na versão 8 ? Pois é! Faz tempo, pois atualmente estamos na versão 23 da linguagem.

A introdução das funções lambdas representou um marco significativo na evolução do ecossistema Java.

Introdução

Neste artigo vamos explorar a evolução cronológica desta feature, suas aplicações, vantagens, limitações e os cenários ideais para o seu uso.

A análise visa oferecer uma compreensão base sobre como essas construções impactam a produtividade e a manutenção do código. E sem dúvida, ao fim, você vai estar prontinha(o) para sair aplicando no seu projeto Java.

Historicamente, Java se destacou como uma linguagem orientada a objetos (OO) com sintaxe verbosa. No entanto, com a crescente popularidade de paradigmas funcionais, tornou-se evidente a necessidade de recursos que permitissem expressar operações em um estilo mais conciso e declarativo, ou se preferir, de um modo direto.

Desta forma as funções lambda ganharam popularidade como uma solução capaz de simplificar códigos que manipulam coleções e fluxos de dados.

Antes do Java 8

Antes da introdução das funções lambda, Java dependia fortemente de classes anônimas para implementar interfaces funcionais. Esse método era prolixo e tornava o código menos legível:

List<String> nomes = Arrays.asList("Ana", "Bruno", "Carlos");
Collections.sort(nomes, new Comparator<String>() {
    @Override
    public int compare(String s1, String s2) {
        return s1.compareTo(s2);
    }
});

Chegada do Java 8 e a introdução das funções Lambda

A partir do Java 8, o suporte para funções lambda e a inclusão da API de Streams transformaram o paradigma de desenvolvimento, permitindo uma abordagem mais concisa e legível:

List<String> nomes = Arrays.asList("Ana", "Bruno", "Carlos");
nomes.sort((s1, s2) -> s1.compareTo(s2));

Versões subsequentes de Java continuaram aprimorando a integração funcional, incluindo melhorias nas APIs de coleções e suporte à inferência de tipos, tornando a sintaxe ainda mais limpa e eficiente.

Usabilidade

Funções lambda são amplamente utilizadas em:

Manipulação de coleções com Streams.
Implementação de eventos e callbacks.
Expressões em APIs funcionais personalizadas.

A API java.util.function fornece interfaces funcionais como Function, Predicate, Supplier, entre outras, que facilitam a criação e manipulação de funções lambda.

Motivos para usar funções Lambda

Redução da verbosidade

As funções lambda reduzem a necessidade de boilerplate code, tornando o código mais claro e direto.

Melhor leitura e manutenção

A sintaxe concisa das lambdas facilita a compreensão rápida das lógicas implementadas, melhorando a manutenção.

Paradigma funcional

Permitem a adoção de práticas funcionais, como imutabilidade e composição de funções.

Motivos para não usar funções Lambda

Complexidade desnecessária

Em cenários onde a simplicidade é crucial, como pequenos projetos ou códigos com baixa necessidade de manutenção, a introdução de lambdas pode ser excessiva.

Debug mais complexo

O uso extensivo de funções lambda pode dificultar o debug, pois os pontos de entrada podem se tornar menos evidentes.

Difícil compreensão para os “juninhos”

Desenvolvedores iniciantes podem encontrar dificuldades para entender códigos fortemente baseados em lambdas.

Casos de uso

Processamento de Coleções

Funções lambda simplificam operações complexas em listas, como filtragem, mapeamento e redução:

List<String> nomes = Arrays.asList("Ana", "Bruno", "Carlos");
List<String> filtrados = nomes.stream()
                              .filter(nome -> nome.startsWith("A"))
                              .collect(Collectors.toList());

Eventos e Callbacks

O uso de lambdas em interfaces gráficas permite a implementação direta de eventos:

button.setOnAction(event -> System.out.println("Botão clicado!"));

APIs funcionais personalizadas

Em sistemas orientados a microserviços, lambdas ajudam a criar interfaces flexíveis e expressivas.

Conclusão

Diante de toda essa informação, fica claro que as funções lambda trouxeram um paradigma poderoso ao ecossistema Java, permitindo soluções mais concisas, funcionais e ao meu ver, leve.

Mesmo apresentando limitações em alguns contextos, seu uso pode transformar significativamente a manutenção e a legibilidade do código.

Mas claro, como em qualquer outro caso em desenvolvimento, o equilíbrio na hora de aplicar dentro do seu código fica na mão do desenvolvedor.

Espero ter ajudado 👋🏽

Normalização dos Bancos de Dados Relacionais (Handbook)

Manu Coutinho — Mon, 06 Jan 2025 18:51:58 +0000

Você já ouviu falar nas 5 Regras de Normalização dos Bancos de Dados Relacionais?

A normalização de bancos de dados é um processo sistemático que organiza os dados de forma a minimizar redundâncias e melhorar a integridade dos dados. Esse processo segue um conjunto de regras conhecidas como formas normais, desenvolvidas por Edgar F. Codd, o criador do modelo relacional.

Mas você deve estar se perguntando o por quê devemos utilizar tais regras em nos banco de dados.

Então te dou 5 bons motivos:

Redução de Redundâncias: Evita a repetição desnecessária de dados e consequentemente otimiza o espaço de armazenamento.
Eliminação de Anomalias: Minimiza inconsistências em inserções, atualizações e deleções.
Melhor Manutenção: Torna o banco de dados mais fácil de atualizar e escalar.
Eficiência de Armazenamento: Reduz o uso de espaço, armazenando dados de forma mais compacta.
Integridade dos Dados: Garante a consistência e precisão das informações.

A normalização é um processo essencial, especialmente em projetos onde a integridade e o desempenho do banco de dados são fundamentais. Cá entre nós, esses atributos são fundamentais em qualquer projeto.

Neste artigo, explicaremos as cinco primeiras formas normais, acompanhadas de exemplos práticos.

1ª Forma Normal (1FN)

A primeira forma normal exige que uma tabela:

Tenha colunas atômicas (ou indivisíveis).
Não contenha grupos repetidos ou colunas que armazenem listas de valores.

Exemplo: Considere a tabela abaixo:

id_cliente	nome	telefones
1	João Silva	1234, 5678
2	Maria Santos	9876

A coluna "telefones" viola a 1FN porque armazena múltiplos valores em uma única célula. Para corrigir, dividimos os dados:

id_cliente	nome	telefone
1	João Silva	1234
1	João Silva	5678
2	Maria Santos	9876

Em suma, a primeira forma visa eliminar dados repetidos, garantindo que cada coluna contenha apenas valores indivisíveis e que cada linha seja única.

2ª Forma Normal (2FN)

A segunda forma normal requer que a tabela:

Esteja na 1FN.
Não contenha dependências parciais, ou seja, cada atributo não-chave deve depender da chave primária inteira.

Exemplo: Considere uma tabela que armazena informações de pedidos:

id_pedido	id_produto	nome_produto	quantidade	preco_unitario
1	A1	Caneta	10	1.50
1	A2	Caderno	5	10.00

Aqui, "nome_produto" e "preco_unitario" dependem apenas de "id_produto", não de "id_pedido". Para corrigir, dividimos a tabela em duas:

Tabela Pedidos:

id_pedido	id_produto	quantidade
1	A1	10
1	A2	5

Tabela Produtos:

id_produto	nome_produto	preco_unitario
A1	Caneta	1.50
A2	Caderno	10.00

Com a remoção das dependências parciais, garantimos que todos os atributos não-chave (secundários), dependam apenas da key ou chave, evitando redundância associadas às dependências parciais.

3ª Forma Normal (3FN)

A terceira forma normal requer que a tabela:

Esteja na 2FN.
Não contenha dependências transitivas, ou seja, nenhum atributo não-chave deve depender de outro atributo não-chave.

Exemplo: Considere uma tabela de vendas:

id_venda	id_cliente	nome_cliente	cidade
1	101	João Silva	São Paulo
2	102	Maria Santos	Rio de Janeiro

Aqui, "nome_cliente" e "cidade" dependem de "id_cliente", não de "id_venda". Para corrigir, dividimos em duas tabelas:

Tabela Vendas:

id_venda	id_cliente
1	101
2	102

Tabela Clientes:

id_cliente	nome_cliente	cidade
101	João Silva	São Paulo
102	Maria Santos	Rio de Janeiro

A remoção das dependências transitivas visa minimizar ainda mais as redundâncias, tornando as tabelas mais simples de compreender e manter.

4ª Forma Normal (4FN)

A quarta forma normal trata das dependências multivaloradas. Ela exige que:

Esteja na 3FN.
Não existam dependências multivaloradas, ou seja, cada fato independente deve estar representado em sua própria tabela.

Exemplo: Considere uma tabela que armazena habilidades de empregados e idiomas falados:

id_empregado	habilidade	idioma
1	Programar	Inglês
1	Programar	Espanhol
1	Design	Inglês
1	Design	Espanhol

Aqui, habilidades e idiomas são informações independentes. Para corrigir, dividimos em duas tabelas:

Tabela Habilidades:

id_empregado	habilidade
1	Programar
1	Design

Tabela Idiomas:

id_empregado	idioma
1	Inglês
1	Espanhol

Implementando a quarta forma, evitamos combinações redundantes de dados e organizamos as tabelas com relacionamentos complexos de forma objetiva.

5ª Forma Normal (5FN)

A quinta forma normal, também conhecida como forma normal de projeção e junção, exige que:

Esteja na 4FN.
Nenhum dado possa ser reconstruído a partir de tabelas menores de forma que a divisão cause perda de informação.

Exemplo: Considere uma tabela de fornecedores, produtos e clientes:

id_fornecedor	id_produto	id_cliente
F1	P1	C1
F1	P1	C2
F2	P1	C1

Se houver uma relação direta entre fornecedores, produtos e clientes, dividir essas informações em tabelas menores pode gerar perda de dados. A 5FN assegura que todos os dados só sejam separados se cada fato puder ser representado independentemente sem ambiguidade. A quinta forma assegura que os dados sejam armazenados de forma modular e que todas as suas dependências sejam explícitas.

Conclusão

A normalização melhora a organização dos dados e a integridade do banco, embora possa aumentar a complexidade das consultas. O uso adequado depende do contexto e do equilíbrio entre desempenho e consistência.

Agora que você já conhece as 5FN e seus benefícios, que tal implementá-las?

Referências:

Codd, E. F. "A Relational Model of Data for Large Shared Data Banks" (1970).
Silberschatz, A., Korth, H., & Sudarshan, S. "Database System Concepts".
Date, C. J. "An Introduction to Database Systems".

Tipos de arquitetura de API

Manu Coutinho — Fri, 21 Apr 2023 16:29:43 +0000

Introdução

API é um acrônimo para Application Programming Interfaces, que em tradução livre quer dizer: “Interface de Programação de Aplicações/Aplicativos”.

Na prática, são construções de programação que permitem a desenvolvedores criar funcionalidades mais complexas contendo abstração de código, de forma que seja simples sua utilização.

No dia a dia do desenvolvimento de software as APIs entram em cena quando um aplicativo precisa se conectar a outro aplicativo. Mas como?

Tudo começa quando uma aplicação, seja ela front-end ou back-end, inicia uma interação com outra aplicação por meio de uma requisição. Após a recepção dessa requisição, dentro dos parâmetros pré-estabelecidos, a aplicação receptora, realiza a rotina prevista e entrega o dado solicitado por meio de uma resposta.

A MDN¹ em sua documentação traz uma analogia que nos ajuda a desmistificar esse processo:

”Pense no seguinte exemplo: o uso de energia elétrica em sua casa ou apartamento. Quando você deseja utilizar um eletrodoméstico, você precisa somente ligar o aparelho na tomada. Não é preciso conectar diretamente o fio do aparelho diretamente na caixa de luz. Isso seria, além de muito ineficiente, difícil e perigoso de ser feito (caso você não seja eletricista).”

Nesta analogia a tomada e o plug seriam as APIs que se conectam e, transmitem o dado solicitado: a energia elétrica.

Todo esse processo é chamado de transação de API, que pode ocorrer com ou sem acesso a Web. Pois nem todas as APIs são Web APIs.

Tanto as requisições como as respostas podem assumir diversos formatos, à depender da arquitetura e tipo de API, conforme veremos a seguir.

Tipos de API

Existem várias formas de categorizar as APIs, a maneira geralmente utilizada é baseada no escopo de uso pretentido. Em se tratando de escopo, podemos dividir em quatro principais tipos de APIs, que são:

API Aberta/pública (Open/public)

Como o nome bem sugere uma API Pública está publicada e documentada publicamente, podendo ser acessada por quem tiver o interesse de fazê-lo. Em alguns casos é necessário o uso de alguma chave de autenticação e ou cabeçalho específico, quais estarão na documentação da mesma. Exigindo assim, pouco ou nenhum gerenciamento de identidade. São exemplos:
- Nasa - https://api.nasa.gov/
- AccuWeather - https://developer.accuweather.com/
- Correios - https://cws.correios.com.br/ajuda
API de Parceiro (Partner)

Este tipo de API é baseado em licença usada para facilitar a comunicação entre aplicativos em nível B2B (business to business). API de parceiro destina-se ao uso por parceiros de negócios pagantes para facilitar a comunicação entre vários aplicativos corporativos. Como as APIs de parceiros exigem mecanismos de autorização, mecanismos de autenticação e medidas gerais de segurança mais fortes, elas são muito mais seguras do que as APIs públicas.
API Privada (Private)

Este tipo também pode ser chamado de API interna, pois é hospedada na infraestrutura interna de um negócio/empresa, estando disponível apenas aos desenvolvedores envolvidos na aplicação e uso da mesma, mediante as regras de acesso existentes. O nível de segurança e arquitetura adotada dependerão da postura do negócio.
API Composta (Composite)

Uma API composta combina sequencialmente solicitações de API em uma única chamada de API. As APIs compostas permitem que os clientes usem o encadeamento de chamadas para fazer várias chamadas de API e receber uma resposta em vez de várias respostas. Geralmente útil para velocidade e eficiência ao fazer chamadas de API complexas entre cliente e servidor.

Tipos/Padrões de Arquitetura

Além de se categorizar por tipos, as APIs distinguem-se quanto ao estilo/arquitetura adotado na sua construção. Tal taxonomia geralmente se baseia no protocolo de comunicação adotado. A seguir falarei dos tipos mais populares, quando se trata de web API (API criada para comunicação web)

REST
1. Segue 6 restrições de arquitetura
2. Pode usar JSON, XML, HTML ou Plain Text
3. Flexível, leve e escalável
4. Formato mais utilizado na web
5. Utiliza HTTP como protocolo

REST é sem dúvida um dos padrões mais populares no desenvolvimento voltado para web. REST significa Representational State Transfer (Transferência de Estado Representacional). As Aplicações que utilizam esse padrão de arquitetura são comumente denominadas RESTful. REST é um conjunto de definições arquitetônicas e, não um protocolo ou padrão, podendo ser implementadas de várias maneiras.
Quando uma solicitação do cliente é feita por meio de uma API RESTful, ela transfere uma representação do estado do recurso para o solicitante ou terminal. Essas informações ou representações são entregues em um dos vários formatos via HTTP: JSON (notação de objeto Javascript), HTML, XLT, Python, PHP ou texto sem formatação. O JSON é o formato de arquivo mais popular para usar, porque, apesar do nome, é um diagnóstico de linguagem e legível por humanos e máquinas.

Outra coisa a ter em mente: os cabeçalhos e parâmetros também são importantes nos métodos HTTP de uma solicitação HTTP da API RESTful, pois contêm informações importantes sobre o identificador dos metadados da solicitação, autorização, identificador uniforme de recursos (URI), cache, cookies e mais. Existem cabeçalhos de solicitação e cabeçalhos de resposta, cada um com suas próprias informações de conexão HTTP e códigos de status.²
Para que uma API possa ser considerada RESTful, deve seguir os seguintes critérios:

Uma arquitetura cliente-servidor composta por clientes, servidores e recursos, com solicitações gerenciadas por HTTP;
Comunicação apátrida cliente-servidor, o que significa que nenhuma informação do cliente é armazenada entre as solicitações de obtenção e cada solicitação é separada e desconectada;
Dados cacheados, que simplificam as interações cliente-servidor;
Uma interface uniforme entre componentes para que as informações sejam transferidas de forma padrão. Isso requer que:
- os recursos solicitados são identificáveis e separados das representações enviadas ao cliente.
- os recursos podem ser manipulados pelo cliente através da representação que recebem, porque a representação contém informações suficientes para fazê-lo.
- as mensagens auto-descritivas retornadas ao cliente têm informações suficientes para descrever como o cliente deve processá-lo.
- hipertexto / hipermídia está disponível, o que significa que, após acessar um recurso, o cliente deve poder usar hiperlinks para encontrar todas as outras ações disponíveis no momento que possam executar.
Um sistema em camadas que organiza cada tipo de servidor (responsável pela segurança, balanceamento de carga etc.).) envolveu a recuperação das informações solicitadas em hierarquias, invisíveis para o cliente.
Código sob demanda (opcional): a capacidade de enviar código executável do servidor para o cliente quando solicitado, estendendo a funcionalidade do cliente.
Apesar dos diversos critérios uma API RESTful é simples de ser criada, razão pela qual é o modelo arquitetônico mais popular na web, podendo ser adotado nas mais diversas situações existentes no dia a dia.

SOAP
1. Estrutura de mensagem estritamente definida que depende de XML
2. Protocolo independente
3. Seguro e extensível
4. Utilizado em ambiente empresarial seguro

SOAP é um acrônimo para Simple Object Access Protocol (Protocolo de Acesso a Objeto Simples), sendo um protocolo padrão que foi projetado pela primeira vez para que aplicativos criados com diferentes idiomas e em diferentes plataformas pudessem se comunicar, fazendo com que seja conhecido por sua extensibilidade e independência de estilos de programação. Além disso, este é um protocolo dito neutro. Isto é, pode operar sob diferentes tipos de protocolos, como HTTP, SMTP, TCP e outros.
Por ser um protocolo, impõe regras internas que aumentam sua complexidade e sobrecarga, o que pode levar a tempos de carregamento mais longos da página. No entanto, esses padrões também oferecem conformidade interna (compliance) que podem torná-lo preferível para cenários corporativos. Os padrões de conformidade internos incluem segurança, atomicidade, consistência, isolamento e durabilidade (ACID), que é um conjunto de propriedades para garantir transações confiáveis no banco de dados.
A especificações mais comuns desse protocolo são:

Segurança de serviços da Web (segurança WS): padroniza como as mensagens são protegidas e transferidas por meio de identificadores exclusivos chamados tokens.
Serviço web de mensagens confiáveis: padroniza o tratamento de erros entre as mensagens transferidas pela infraestrutura de TI não confiável.
Endereçamento de serviços da Web (endereço WS): empacotar informações de roteamento como metadados nos cabeçalhos SOAP, em vez de manter essas informações mais profundas na rede.
Linguagem de descrição de serviços da Web (WSDL): descreve o que um serviço da Web faz e onde esse serviço começa e termina. Quando uma solicitação de dados é enviada para uma API SOAP, ela pode ser tratada através de qualquer um dos protocolos da camada do aplicativo: HTTP (para navegadores da web), SMTP (para email), TCP e outros. No entanto, uma vez recebida uma solicitação, as mensagens SOAP de retorno devem ser retornadas como documentos XML - uma linguagem de marcação legível por humanos e máquinas. Uma solicitação concluída para uma API SOAP não pode ser armazenada em cache por um navegador, portanto não pode ser acessada posteriormente sem reenviar para a API³.

RPC

Procedimento baseado em ação, ótimo para sistemas baseados em comando
Usa apenas HTTP GET e POST
Tem payloads leves que permitem maior performance
usados em sistemas distribuídos

RPC significa Remote Procedural Call, em português, Chamada Procedural Remota. Este protcolo permite que uma aplicação chame, remotamente, um procedimento de outra (via internet ou intranet).

Este tipo de API é o mais antigo e básico, sendo uma arquitetura cliente-servidor para construir aplicações distribuídas, que normalmente exigem que os desenvolvedores executem blocos específicos de código em outro sistema.

O RPC é agnóstico em termos de protocolo, o que significa que tem o potencial de ser compatível com muitos protocolos, mas também perde os benefícios de usar recursos nativos de alguns protocolos como armazenamento em cache.

Para oferecer suporte a chamadas de API para serviços em redes externas, o RPC depende de uma linguagem de definição de interface (IDL) que atua como um link de comunicação entre servidores localizados em diferentes redes externas criadas usando diferentes linguagens de programação.

As APIs do tipo RPC podem se comunicar por meio de chamadas com multi parâmetros, que retornam um único resultado nos formatos JSON (JSON-RPC) ou XML (XML*-RPC*)

Há ainda as APIs baseadas em eventos/streamings, que também são chamadas de arquiteturas orientadas à eventos, em tempo real (real time), de streaming, assíncronas ou push. Esse tipo de API não espera que o consumidor chame-a para que possa enviar uma resposta. Em vez disso, uma resposta é disparada pela ocorrência de um evento. Como exemplo, esses serviços expõem eventos nos quais os clientes podem se inscrever para receber atualizações quando os valores no serviço mudam. Há muitas variações para esse estilo, incluindo (entre outros) reativo, publicação e assinatura, notificação de eventos e CQRS.

Numa próxima oportunidade, trataremos de GraphQL que não é um padrão de arquitetura de API, mais sim um tipo de linguagem de consulta que pode ser adotado. Um outro tema muito empolgante, são os formatos de dados que podem trafegar entre APIs.

Spoiler: Não! Não é apenas JSON 🤭

Conclusão

O tipo e arquitetura de uma API pode variar muito, dependendo do tipo de informação que irá entregar, quantidade de consultas simultâneas, velocidade, acesso, etc. E o time de desenvolvimento que deverá levantar os requisitos para eleger o melhor formato/arquitetura para a aplicação em questão.

Aqui quis trazer luz sobre os formatos mais comuns no dia a dia do desenvolvimento. Você já os conhecia? Utiliza outro?

Até a próxima 👋🏾

Fontes:

¹ https://developer.mozilla.org/pt-BR/docs/Learn/JavaScript/Client-side_web_APIs/Introduction

² https://www.redhat.com/en/topics/api/what-is-a-rest-api

³ https://www.redhat.com/en/topics/integration/whats-the-difference-between-soap-rest#soap

Como você estuda?

Manu Coutinho — Mon, 18 Apr 2022 14:47:36 +0000

Olá Devs!

O episódio de hoje na minha (nada mole) vida de Dev Sandy é sobre Estudar!

Sim, sou uma pessoa ávida por estudar e, quando falo estudar, me refiro a qualquer coisa: desde um novo idioma, passando por matérias tradicionais, culturas diferentes, games, enfim, qualquer coisa mesmo.

Mas, desde que me decidi pela migração de carreira para área Tech, mudei a didática e a intensidade dos estudos ao longo da jornada.

De início, acompanhava cursos ou tutores do começo ao fim e, a partir das dúvidas que surgiam no percurso, pesquisava tais assuntos.
Ao passar do tempo, quando comecei a implementar meus próprios projetos, percebi que passava bastante tempo pesquisando e estudando para implementar boa parte deles. Logo, aquela fórmula inicial de estudo, não me servia mais.

Passei então a acompanhar as aulas e ao final de cada tema e/ou módulo, implementar um projeto original utilizando o conhecimento ali adquirido. Nesse momento, passei a mensurar o quanto estava absorvendo das aulas técnicas.

Fiquei bem frustrada ao perceber que era menos do que eu esperava.

Como define os dicionários, autodidata é a pessoa que aprende por meio do seu esforço particular em buscar o conhecimento.

E eu me defino com sendo uma pessoa autodidata, então passei a criar pequenas metas de aprendizado.

A partir destas pequenas metas, passei a mapear todos os subtemas relacionados que seriam necessários para que eu pudesse compreender aquela meta. *(como no diagrama da imagem)

Com esse simples passo, já tinha meu primeiro plano de estudos (passo essencial).

O que percebi? Quando eu crio um plano de estudos personalizado, com uma meta macro (meta de longo prazo), diversas submetas (metas de médio prazo), sendo essas submetas divididas em temas (metas de curto prazo), podendo esses temas compreender outros subtemas, meu plano de estudo passa a ser somente meu, estritamente personalizado e, a partir daí nem o céu é limite para onde posso chegar. Pois o destino quem define, é o autor do projeto, no meu caso, euzinha!

Hoje, tenho meu plano de estudos que compreende uma gama de assuntos ligados às minhas metas intermediárias. E a cada tema (parte micro do plano de estudo), início a busca por conteúdo escrito, frequentemente em inglês.

Início pela documentação oficial, caso precise de algum exemplo específico ou de informação adicional, passo a procurar artigos, salvo e categorizo os mais relevantes no meu Notion (meu caderninho).

Principais motivos pelos quais eu salvo:

Consultar em outro momento – muito comum você compreender a ideia inicial de um tema. Mas se você ler novamente após ter adquirido outros conhecimentos, irá visualizar camadas que não viu antes 😉.
Documentar – acredito que como eu, as pessoas que estão estudando assuntos ligados à área tech, têm um aprendizado acelerado, devido a quantidade de informação que consumimos x tempo. Então fica fácil você esquecer o motivo que levou a adotar determinado entendimento. Documentar resolve esse e outros problemas 📃

Ultrapassada esta fase de pesquisa, vou para prática, momento em que tento implementar aquele conhecimento num projeto. Nesse momento vejo os “gargalos”, ou seja, onde ainda não compreendi da forma esperada, volto e consulto o material que separei. Mas se realmente eu não conseguir avançar, vou procurar o conteúdo em vídeo.

Com relação aos tutoriais em vídeo, é bom ter em mente que nem sempre vamos encontrar algo que se encaixe 100% na sua dúvida.

Claro que estou falando aqui de temas mais específicos, com uma mensagem de erro ou implementação de determinada feature que está tendo incompatibilidade com outra parte do seu código ou, ainda, algo lançado recentemente. Além de outras coisas que me fazem deixar o vídeo como última opção, isso daria assunto para outro artigo.

Com isso em mente, vou realizando o ciclo: aulas – pesquisa – implementação. Claro que nenhuma dúvida deve permanecer ativa em nossa mente por muito tempo, portanto, sempre que necessário recorra aos nossos colegas da Bolha Dev, certamente alguém lhe auxiliará, isso incluí o queridinho Stack Overflow.

Por fim, ressalto dois pontos, que julgo essenciais para evolução nos estudos:

⏲️ Periodicamente revise suas metas, para incluir novos temas que encontrou no caminho e para excluir ou postergar o que descobriu não ser tão relevantes;
📚Vai chegar um momento na sua jornada em que verá a necessidade de imergir na literatura técnica, não evite! Mergulhe com tudo.

😊 Com essa reflexão, a única coisa que posso afirmar é que não existe receita infalível! O método que venho desenvolvendo, no momento, me serve. Mas, pode ser que daqui a algum tempo tenha que ser mudado.

Aprendizado é algo contínuo, um ciclo infinito ao longo da nossa vida. Aproveite a jornada!