Forem: Andres dos Santos

The Importance of Maintaining Standards

Andres dos Santos — Mon, 26 Jan 2026 14:11:13 +0000

In this post, I want to talk a bit about productivity, safety, and scalability, and also about structure. A good folder structure helps guarantee all of that in your code.

My goal is to make you leave here thinking:

“From today on, I will help my team standardize a good folder and file structure.”

Code is read far more than it is written

A good standard makes this possible: someone looks at the project and immediately understands where everything is, without asking anyone.

The structure becomes a mental map, where following that path guarantees you’ll find the information you need.

Navigation becomes automatic:

“Okay, I need to go here, access this, enter that folder, click here — done.”

Without a standard, you waste time looking for files:

“Hmm, I need to go here… but now what? Maybe I should ask someone… oh, they’re in a meeting. I’ll have to wait.”

And many times, the company itself becomes hostage to the people who know where everything is.

Reduces errors (especially in large projects)

Without standards, things like this start to appear:

userService, User_service, serviceUser, or even utils, helpers, common, misc — all meaning roughly the same thing.

The result:

duplicated logic
wrong files being imported
“mysterious” bugs that exist only because someone got lost

A standard prevents errors before they even exist.

Makes maintenance and refactoring easier

When folders follow a clear rule (by layer, by domain, or by feature):

you know where to make changes
you know what might break
refactoring stops being a risk and becomes a task

Without a standard, changing code feels like this:

“I’ll touch this and hope nothing breaks.”

Helps the team (and your reputation)

This is important for your career.

A well-structured project sends a clear message:

“This person thinks before writing code”
“This code is maintainable”
“This isn’t hidden chaos that only the author understands”

Leaders trust people who deliver organized code.

Even if no one praises it, everyone notices.

Scales the project — and scales you

Small projects can “tolerate” mess.

Real projects can’t.

If you’re just starting an app, you don’t need to obsess over patterns — just write code.

But once your app has a solid user base, you must start standardizing things.

Here’s a tip:

If your company struggles with this and you want to grow there — or move to a bigger company — standards stop being optional.

A standard is not rigidity, it’s an agreement

This isn’t about the perfect standard.

It’s about having a standard and following it.

It can vary from company to company — and still work very well.

An average standard + consistency

is infinitely better than a brilliant standard that no one follows.

That’s it, folks. It’s not much, but it’s honest 😂

Standardizing names and folders reduces time, errors, and maintenance costs, while allowing the project to grow without becoming technical debt.

And remember:

it doesn’t matter which standard you use — what matters is following one.

What To Expect For My 2026

Andres dos Santos — Wed, 21 Jan 2026 01:26:51 +0000

Let’s go. This is me being as honest as I can with myself.

2026 is just another year. Time will pass, and before I realize it, it’ll already be 2027. That doesn’t mean I shouldn’t plan — quite the opposite. A lot can be done in 8,760 hours.

So here are my plans.

Build a solid technical foundation (without trying to know everything)

This matters to me. I want to master a main stack — in my mind, Spring with React. I want clarity around code organization, to truly understand the decisions I make, and to be able to explain the trade-offs behind them.

Work-oriented, functional English

Maybe the most life-changing goal. I want to clearly explain problems, risks, and decisions. To be able to say “no” from a technical standpoint. To speak correctly, calmly, without rushing.

A professional profile that actually represents me

I want a resume focused on impact, not task lists. I want my LinkedIn in English and a clean, well-organized GitHub with projects that make sense and tell a story.

That’s it.

No overexplaining. Broad, but intentional.

Now it’s time to work, day after day, to make this real.

What To Expect For My 2026

Andres dos Santos — Wed, 21 Jan 2026 01:20:01 +0000

Let’s go.

This is me being as honest as I can with myself.

2026 is just another year. Time will pass, and before I realize it, it’ll already be 2027.

That doesn’t mean I shouldn’t plan — quite the opposite. A lot can be done in 8,760 hours.

So here are my plans.

Build a solid technical foundation (without trying to know everything)

Work-oriented, functional English

Maybe the most life-changing goal. I want to clearly explain problems, risks, and decisions. To be able to say “no” from a technical standpoint. To speak correctly, calmly, without rushing.

A professional profile that actually represents me

I want a resume focused on impact, not task lists. I want my LinkedIn in English and a clean, well-organized GitHub with projects that make sense and tell a story.

That’s it.

No overexplaining. Broad, but intentional.

Now it’s time to work, day after day, to make this real.

What To Expect For My 2026

Andres dos Santos — Sun, 18 Jan 2026 18:45:12 +0000

Well, here goes a bit of what I expect for my 2026.

By the end of the year, I hope to come back here and see that I’ve accomplished everything I promised, so let’s go.

At work

I work at a bank, so what I expect is to learn a lot about the financial market — about PIX, P2P transactions, cards, boletos, and more.

One concern of mine is code organization. Well-structured code makes sense and helps with testing and maintainability.

I don’t need to push this too far — that’s it.

In my studies

My plan here is to improve in algorithms and data structures. It’s an interesting topic and has real value in the programming field.

In addition, I’ve been learning more about PHP syntax and English. This year, I intend to reach the end of the year speaking well enough to confidently take interviews abroad.

That’s it.

Let’s go, 2026.

What to expect for my 2026

Andres dos Santos — Sun, 18 Jan 2026 18:41:23 +0000

Well, here goes a bit of what I expect for my 2026.

By the end of the year, I hope to come back here and see that I’ve done everything I promised, so let’s go.

At work

I work at CDC Bank, so what I expect is to learn a lot about the financial market — about PIX, P2P transactions, cards, boletos, and so on.

One concern of mine is code organization; well-structured code makes sense and helps with testing and maintainability.

I don’t need to push this too far — that’s it.

In my studies

My plan here is to improve in algorithms and data structures. It’s an interesting topic and has real value in the programming field.

Besides that, I’ve been learning more about PHP syntax, and of course there’s always a good course to take.

That’s it.

Let’s go, 2026.

Cliente x servidor, entendendo tudo

Andres dos Santos — Sun, 11 Jan 2026 17:02:18 +0000

Fala dev, nesse post nós vamos aprender tudo sobre o modelo cliente e servidor, desde como ele funciona até tecnologias usadas tanto no cliente quanto no servidor.

No modelo cliente x servidor, o cliente (como um PC ou celular) faz uma requisição solicitando um serviço, e o servidor, que permanece ativo continuamente, recebe essa requisição, processa e devolve uma resposta.

Esse fluxo caracteriza o ciclo de requisição e resposta, permitindo que o usuário acesse funcionalidades e dados de forma remota.

Para organizar melhor o sistema, essa arquitetura evoluiu para o modelo em camadas, no qual cada parte tem uma responsabilidade bem definida.

Inicialmente existia o modelo de duas camadas, onde o cliente cuidava da interface e da lógica de negócio, enquanto o servidor era responsável pelos dados.

Com o crescimento das aplicações, surgiu o modelo de três ou quatro camadas, separando apresentação, lógica de negócio e dados.

Nesse modelo mais moderno, o cliente precisa apenas de um navegador, o servidor web cuida da interface e da comunicação, o servidor de aplicação centraliza as regras de negócio e o servidor de dados armazena as informações.

Essa separação facilita manutenção, escalabilidade e atualização do sistema.

O ambiente web

No ambiente web, baseado no modelo de quatro camadas, o cliente não precisa instalar softwares adicionais: a interface da aplicação é fornecida pelo servidor web e executada diretamente no navegador ou em aplicativos mobile.

Além dele, existem servidores específicos para lógica de aplicação e dados, que podem estar juntos ou distribuídos, sem que o cliente perceba essa separação.

Com a evolução das redes internas para a internet, as aplicações passaram a ser acessadas por diversos dispositivos, permitindo que usuários consumam serviços a partir de navegadores e apps.

A comunicação entre cliente e servidor acontece principalmente por meio do protocolo HTTP, seguindo o modelo de requisição (request) e resposta (response), podendo também incluir comunicações iniciadas pelo servidor, como notificações push.

Nesse contexto, falamos em client side para tudo que é processado no dispositivo do usuário e em server side para o que é executado no servidor, mantendo responsabilidades bem definidas e facilitando a escalabilidade das aplicações.

Demonstração prática da arquitetura cliente x servidor

Segue um exemplo passo a passo, do momento em que você acessa um site até receber a resposta, no modelo cliente x servidor.

Você digita o endereço do site (URL) no navegador e pressiona Enter
O navegador (cliente) consulta o DNS para descobrir qual é o endereço IP do servidor daquele site
Com o IP em mãos, o navegador abre uma conexão com o servidor web pela internet
O navegador envia uma requisição HTTP (request) solicitando a página
O servidor web recebe a requisição
Se necessário, o servidor web encaminha a requisição para o servidor de aplicação
O servidor de aplicação executa a lógica de negócio (valida dados, regras, permissões, etc.)
Caso precise de informações, o servidor de aplicação consulta o servidor de dados (banco de dados)
O servidor de dados retorna as informações solicitadas
O servidor de aplicação processa os dados e monta a resposta
O servidor web recebe essa resposta e gera o conteúdo final (HTML, CSS, JS ou JSON)
O servidor envia a resposta HTTP (response) de volta ao navegador
O navegador interpreta a resposta e renderiza a página para o usuário

Esse fluxo acontece em milissegundos e se repete várias vezes enquanto você navega pelo site.

Visão geral de interface de usuários

Interfaces de usuário são a ponte entre pessoas e aplicações.

Uma boa interface precisa ser clara, intuitiva e oferecer boa usabilidade, garantindo uma experiência positiva para o usuário.

Esse conceito está diretamente ligado à Interação Humano-Computador (IHC), área que estuda como pessoas interagem com sistemas computacionais.

No início, o foco era o hardware e o software, exigindo que o usuário se adaptasse ao sistema.

Com a popularização dos computadores e, principalmente, dos smartphones, o foco passou a ser o inverso: adaptar o sistema ao usuário.

A interface do lado do cliente

Do ponto de vista da usabilidade, a interface do cliente deve seguir os princípios de design responsivo, permitindo que aplicações web se adaptem a diferentes dispositivos e tamanhos de tela sem perda de informação.

Dados de utilização de tamanhos de tela (abril/2019 a abril/2020) mostram a diversidade de dispositivos que precisam ser considerados:

Tamanho da tela (px)	Uso
360 x 640	10,11%
1366 x 768	9,69%
1920 x 1080	8,4%
375 x 667	4,24%
414 x 896	3,62%
1536 x 864	3,57%

Esses números reforçam a importância de interfaces flexíveis, pensadas desde o início para múltiplos contextos de uso.

Design responsivo

Com o surgimento de dispositivos com diferentes tamanhos de tela, surgiu o design responsivo, cujo objetivo é adaptar páginas e aplicações web ao dispositivo do usuário, oferecendo melhor experiência.

Segundo Knight (2011), design responsivo é a abordagem em que design e desenvolvimento respondem ao comportamento e ao ambiente do usuário, considerando tamanho de tela, plataforma e orientação.

Na prática, isso evita a criação de múltiplas versões de uma mesma aplicação para dispositivos diferentes.

Layout fixo x layout fluido

Para entender o design responsivo, é importante conhecer seu oposto: o layout fixo.

Layout fixo - Utiliza unidades fixas (como pixels) para definir dimensões. Os elementos não se adaptam a diferentes tamanhos de tela.
Layout fluido (responsivo) - Utiliza unidades flexíveis, permitindo adaptação ao tamanho da tela.

As unidades mais comuns são:

%(percentual)
EM: relativo ao tamanho da fonte do elemento pai
REM: relativo ao tamanho da fonte do elemento raiz (html)

Media queries

As media queries permitem aplicar estilos condicionais conforme características do dispositivo.

No exemplo abaixo, um menu lateral é ocultado em telas menores que 360px:

@media (max-width:360px) {
.menu_lateral {
display: none;
  }
}

A condição será verdadeira quando a largura da tela for inferior a 360px. Caso contrário, o CSS será ignorado.

Scripts

No lado cliente, scripts são linguagens executadas no navegador, sendo o JavaScript o principal exemplo.

Ele permite adicionar interatividade à página, como:

Atualização dinâmica de conteúdo
Controle de multimídia
Animações
Manipulação de eventos e dados

Design responsivo x design adaptativo

Design responsivo - ****Utiliza media queries e scripts para criar layouts fluidos que se adaptam dinamicamente.
Design adaptativo - ****Trabalha com layouts estáticos baseados em pontos de quebra, carregando versões específicas conforme o tamanho da tela.

De forma geral, o design responsivo é mais flexível, enquanto o adaptativo tende a ser mais trabalhoso e menos dinâmico.

Mobile first

O mobile first é uma abordagem muito utilizada no design responsivo atual.

Ela propõe que o design seja pensado primeiro para dispositivos móveis e, depois, expandido para telas maiores.

Esse modelo segue o conceito de progressive enhancement, adicionando recursos conforme o tamanho e a capacidade do dispositivo aumentam.

Em contraste, o modelo tradicional segue a graceful degradation, onde o site é pensado para telas grandes e depois adaptado para dispositivos menores.

Na prática, mobile first significa priorizar limitações e recursos dos dispositivos móveis, como tamanho de tela, largura de banda e funcionalidades específicas (ex: localização).

As tecnologias HTML

HTML (HyperText Markup Language) é a linguagem usada para estruturar páginas web.

Trata-se de uma linguagem de marcação simples, composta por tags que dão significado a textos e outros conteúdos.

Além de marcar conteúdo, o HTML define a estrutura lógica do documento, como cabeçalho, menu de navegação, seções e rodapé.

As tags podem ser classificadas em:

Estruturais – Em conjunto com o DocType, formam a estrutura básica e obrigatória da página.
De conteúdo – Marcam o conteúdo de acordo com seu tipo (texto, imagem, links, etc.).
Semânticas – Organizam o conteúdo em seções com significado, de acordo com sua função no documento.

Apesar do HTML5 permitir alguns ajustes visuais, o CSS é a ferramenta mais adequada para controlar estilo e identidade visual, especialmente em aplicações com múltiplas páginas.

CSS

CSS (Cascading Style Sheets) é uma linguagem declarativa responsável pela apresentação visual das páginas web.

Enquanto o HTML cuida da estrutura e do conteúdo, o CSS define cores, layout, tipografia e responsividade.

Dominar sua sintaxe e aplicação é essencial para criar interfaces consistentes e reutilizáveis.

JS

JavaScript é uma linguagem de programação interpretada pelo navegador e amplamente utilizada no desenvolvimento web.

Ela é multiparadigma (orientada a objetos, funcional, baseada em protótipos) e tem como principal objetivo adicionar interatividade às páginas.

O JavaScript permite comunicação assíncrona com o servidor e atualização dinâmica de conteúdo, evitando recarregamentos completos da página.

Nesse ponto, vale estudar sua sintaxe, manipulação do DOM e até bibliotecas como jQuery, dependendo do contexto do projeto.

Tecnologias no lado do servidor: o PHP

PHP é uma linguagem de programação utilizada no lado do servidor, assim como Java ou Python, e muito aplicada no desenvolvimento web.

Com PHP é possível processar requisições de clientes, integrar aplicações a bancos de dados e trabalhar com diferentes paradigmas, incluindo orientação a objetos.

Por ser uma linguagem interpretada, o PHP precisa de um servidor web para ser executado.

Um ponto fundamental é que o código PHP é processado no servidor e convertido em HTML, de forma que o usuário final visualiza apenas o resultado gerado, nunca o código fonte original.

PHP (Hypertext Preprocessor) é open source e focada principalmente na criação de aplicações web dinâmicas.

Como o PHP funciona

O funcionamento do PHP ocorre inteiramente no servidor:

O código PHP é interpretado pelo servidor web.
O resultado é convertido em HTML.
O HTML gerado é enviado e exibido no navegador.

Isso garante que o código fonte PHP permaneça oculto no lado cliente.

Além disso, o PHP é multiplataforma e compatível com diversos servidores web, como Apache, Nginx e IIS.

Páginas dinâmicas e acesso a dados

Com a evolução da web, surgiu a necessidade de gerar conteúdo de forma dinâmica, como acontece em redes sociais, e-commerces, sistemas bancários e plataformas de streaming.

Páginas dinâmicas permitem que usuários interajam com a aplicação, enviando e recebendo dados em tempo real.

Em um blog, por exemplo, comentários, curtidas e conteúdos podem ser processados e armazenados dinamicamente.

A combinação de tecnologias do lado cliente com tecnologias do lado servidor é o que torna possíveis as páginas dinâmicas.

Nesse modelo, os dados podem ser recebidos, processados, armazenados e reutilizados sempre que necessário.

Acesso a dados

Além do cliente e do servidor, o ambiente web inclui o banco de dados, responsável por armazenar informações de forma estruturada.

No lado servidor, o PHP atua como intermediário entre a aplicação e o banco de dados, permitindo salvar, recuperar e manipular informações que sustentam o funcionamento de aplicações web modernas.

Entendendo o event loop do NodeJS

Andres dos Santos — Tue, 14 Oct 2025 14:48:59 +0000

Fala!

Hoje eu quero que você entenda o event loop, vou te explicar o que você precisa saber para mandar bem nas entrevistas e entender o coração do Node.

Como o nome diz o event loop é um laço de eventos responsável por gerenciar quando e como seu código é executado — especialmente quando tem tarefas assíncronas.

Tá, mas o que é uma tarefa assíncrona?

Ler um arquivo do disco
Esperar uma resposta HTTP
Esperar um setTimeout
Consultar banco de dados

Importante, isso quer dizer que ele pode executar outros processos enquanto consulta dados no banco ou espera uma resposta HTTP.

O Node, por exemplo, é single-threaded (roda em uma thread principal), mas ele usa o event loop para parecer que faz várias coisas ao mesmo tempo.

A ideia principal

Agora vou te mostrar a ideia principal do Node e é onde fica a escalabilidade dele e de outras linguagens como o Python e Java.

O Node recebe um evento, como uma requisição HTTP — event queue
O _callback_associado a esse evento é enviado para execução
- Se for algo demorado do tipo acessar banco ele é delegada para as threads do libuv.
Enquanto isso, o event loop continua livre para processar outros eventos.
Quando a operação assíncrona termina, o resultado é colocado de volta na fila de callbacks, e o event loop chama o callback correspondente.
O ciclo se repete indefinidamente — o loop nunca para, a menos que não haja mais nada para processar.

Node manda o evento assíncrono para uma thread secundária sem travar a fila. Quando a thread termina, o resultado do evento é enviado de volta para o loop principal e o callback é executado.

Fases do event loop

O Node executa todas essas fases, mas se não tiver processo nenhum ele pula ela, por exemplo, a fase 1 que é o timer, se não tiver um setTimeout ou setInterval no seu código ele pula essa fase.

Ele divide a execução de callbacks nessas fases e o loop vai passando por elas de forma cíclica enquanto houver tarefas para executar.

Timers

(

setTimeout

e

setInterval

) — só executa se estiver no código.
1. Execulta callbacks de temporizadores cujo tempo já expirou.
2. Callback de 0ms não é instantâneo: ele entra na fila de timers e só é executado quando o loop chegar nessa fase.
Pending callbacks
1. Trata callbacks de operações assíncronas do sistema, como erros TCP ou algumas operações de I/O.
Idle, Prepare
1. Fase interna do Node, não interagimos com ela diretamente
Poll

(a mais importante)
1. Fica esperando eventos de I/O (rede, arquivos, timers expirados, etc).
2. Se houver callbacks prontos, ele os executa aqui
3. Se não hover nada, ele espera ou vai para a fase de check (setImmediate) dependendo do estado do loop.
4. A leitura é feita no poll.
5. Quando termina o callback é chamado.
Check

(

setImmediate

)
1. Sempre executa após o poll, mesmo que esteja vazio
2. Útil quando você quer rodar algo assim que o I/O atual terminar.
Close callbacks
1. Chamado quando algo é fechado, como sockets.
2. Sempre executa após o fechamento da conexão.

Algo importante de entender é isso…

O event loop do Node passa por todas as fases em ciclo contínuo, mas cada fase só faz algo se houver callbacks na fila correspondente.

Caso contrário, o Node simplesmente pula para a próxima fase.

Loop Infinito:

  1️⃣ Timers -> executa setTimeout/setInterval vencidos, senão pula
  2️⃣ I/O callbacks -> executa callbacks de operações I/O concluídas, senão pula
  3️⃣ Idle, prepare -> interno do Node, pouca coisa pra dev ver
  4️⃣ Poll -> verifica se há novas operações de I/O, senão aguarda
  5️⃣ Check -> executa setImmediate, senão pula
  6️⃣ Close callbacks -> executa callbacks de fechamento de sockets, senão pula

Então sim, todas as fases são "visitadas" em cada loop, mas só executam algo se tiver trabalho correspondente.

Bom pessoal é isso, espero que isso tenha te ajudado a entender.

Camadas de aplicação e transporte

Andres dos Santos — Tue, 07 Oct 2025 02:25:54 +0000

Quando realizamos uma compra com cartão de crédito ou débito em um estabelecimento comercial, é fundamental a existência de uma rede de comunicação, já que ela será o alicerce para execução da operação.

Ao inseri-lo na máquina de cartão, precisamos colocar uma senha para confirmar a operação.

Tal dado é inserido no sistema por meio de um software executado nessa máquina. Nesse caso, o software é executado na camada de aplicação.

Portanto, sempre que houver um serviço na rede, virá à mente a interface com ele.

Ressaltamos que a camada de aplicação é aquela de mais alto nível do modelo OSI, fazendo a interface com os usuários do sistema e realizando as tarefas que eles desejam.

Arquitetura cliente-servidor

Nesta arquitetura, há pelo menos duas entidades: um cliente e um servidor.

O servidor executa operações continuamente aguardando por requisições do(s) cliente(s). O mais comum, é que hajam diversos clientes e um único servidor.

Quando um dos clientes precisa que o trabalho seja realizado pelo servidor, ele monta uma mensagem, especificando o que deve ser realizado.

Quando a mensagem está montada, é enviada ao servidor por intermédio de algum sistema de comunicação (internet).

Este recebe a mensagem, processa seu conteúdo e envia a resposta ao cliente.

O servidor comporta-se passivamente, normalmente limita-se a aguardar solicitações, e quando estas chegam, processa as mensagens com os dados necessários e enviar o resultado do processamento de volta a seus clientes.

Servidor

Quando chega uma solicitação, o servidor pode:

Atender imediatamente caso esteja ocioso
Gerar um processo-filho para o atendimento da solicitação
Enfileirar a solicitação para ser atendida mais tarde
Criar uma thread para esse atendimento.

Independentemente do momento em que uma solicitação é processada, o servidor, no final, envia ao cliente uma mensagem contendo o resultado do processamento.

O que determina se uma entidade é cliente ou servidor é a função desempenhada pelo software, e não o tipo de equipamento.

Além disso, um processo pode atuar simultaneamente como cliente e servidor.

Arquitetura peer-to-peer

Enquanto existe uma distinção bem clara entre os processos que trocam informações na arquitetura cliente-servidor, na peer-to-peer – também conhecida como arquitetura P2P –, todos os processos envolvidos desempenham funções similares.

Em geral, nesses sistemas, os processos não são uma propriedade de corporações.

Quase todos os participantes (senão todos) são provenientes de usuários comuns executando seus programas em desktops e notebooks.

Tanto o processamento quanto o armazenamento das informações são distribuídos entre os hospedeiros. Isso lhes confere maior escalabilidade em comparação à arquitetura cliente-servidor.

Protocolos da camada de aplicação

Enquanto o algoritmo da camada de aplicação determina seu funcionamento no ambiente local, o protocolo dela estipula tudo que é necessário para que aplicações em diferentes hospedeiros possam trocar mensagens de maneira estruturada.

Serviços da camada de aplicação

Descreveremos a seguir o funcionamento de três importantes aplicações das camadas de aplicação na internet.

Serviço web / protocolo HTTP — Implementado pelo protocolo HTTP, que muita gente confunde com a própria internet.
Serviço de Correio / protocolos SMTP, IMAP e POP — Serviço do correio eletrônico.
Serviço de nomes / DNS — Sistema de resolução de nomes DNS.

HTTP / Serviço web / Protocolo HTTP

Esse protocolo é constituído de duas etapas:

Uma página web típica é um documento em formato HTML que pode conter imagens e outros tipos de objetos, como vídeos, texto, som, etc.

Para exibir determinada página web, o usuário digita no browser o endereço no qual ela se encontra, indicando o local em que deve ser buscada.

Para que uma página seja transferida do servidor até o browser, um padrão deve ser seguido pelos softwares.

Ele especifica como o cliente solicita a página, e o servidor a transfere para o cliente.
Esse padrão é o protocolo HTTP. A mensagem HTTP, por sua vez, é carregada pelo outro protocolo: TCP.

Uma interação entre cliente e servidor se inicia quando o cliente envia uma requisição a um servidor. A solicitação mais comum consiste em:

-   Enviar um texto em formato ASCII.


  Iniciar com a palavra GET.
  Inserir página solicitada, protocolo utilizado na transferência e servidor a ser contatado.

Correio eletrônico (email)

A arquitetura do sistema de correio eletrônico é construída com base em dois agentes:

Do usuário
De transferência de mensagens

O agente do usuário é o programa que faz a interface do usuário com o sistema de correio eletrônico.É por meio dele que o usuário:

Faz o envio e o download de mensagens e anexos.
Lê as mensagens.
Realiza a pesquisa, o arquivamento e o descarte de mensagens.
Escreve suas mensagens.
Anexa arquivos.

Já os agentes de transferência de mensagens são os responsáveis por fazer com que elas cheguem até o destino.

Eles são mais conhecidos como servidores de correio eletrônico.

Funcionamento do correio eletrônico

Para concluirmos esse estudo, analisaremos importantes características dos protocolos apresentados:

SMTP

O protocolo responsável pela transferência da mensagem até seu destino é o SMTP. O servidor SMTP aguarda por conexões de seus clientes.

Quando uma conexão é estabelecida, o servidor inicia a conversação enviando uma linha de texto na qual se identifica e informa se está pronto (ou não) para receber mensagens.

Se ele não estiver, o cliente deverá encerrar a conexão e tentar novamente mais tarde.

Caso o servidor esteja acessível, o cliente precisa informar aos usuários a origem e o destino da mensagem.

Se o servidor considerar que se trata de uma transferência válida, sinalizará para que ele a envie.

Após o envio, o servidor confirma sua recepção e a conexão é encerrada.

POP3

A RFC 1939 estipula que o POP3 tem a finalidade de fazer o download das mensagens que se encontram no mailbox do usuário para o sistema local.

Caso estejam neste sistema, ele pode utilizá-las em qualquer momento, mesmo sem ter conexão com a internet.

O POP3 é implementado na maioria dos agentes de usuário.

IMAP

Assim como o POP3, o IMAP permite que um usuário tenha acesso às mensagens armazenadas em sua caixa.

Porém, enquanto o POP3 é baseado na transferência delas para o sistema local a fim de serem lidas, o IMAP consegue permitir sua leitura diretamente no servidor, dispensando, portanto, a transferência para o sistema local.

Isso será particularmente útil para usuários que não utilizarem sempre o mesmo computador, pois permite que suas mensagens sejam acessadas a partir de qualquer sistema.

DNS

A comunicação entre hospedeiros na internet ocorre por meio de endereços binários de rede.

Entretanto, é bem mais fácil trabalhar com nomes de hospedeiros do que com seus endereços de rede.

Além de ser muito difícil conhecer todos os endereços dos hospedeiros com os quais precisamos trabalhar, precisaríamos ser notificados toda vez que algum deles mudasse de endereço.

Para resolver esse problema, foi desenvolvido o Domain Name System (DNS).

Sua finalidade é a criação de um sistema de nomes de forma hierárquica e baseada em domínios.

Para acessar um hospedeiro, portanto, basta conhecer seu nome de domínio e fazer uma consulta ao servidor DNS, que é responsável por descobrir seu endereço.

Espaços de nomes

O espaço de nomes do DNS é dividido em domínios estruturados em níveis. Confira a organização do primeiro nível:

Domínios genéricos

Informam o tipo de organização ao qual o domínio está vinculado. Alguns exemplos são:

.com — comercial
.edu — instituições educacionais
.int — algumas organizações internacionais
.org — organizações sem fins lucrativos

Domínios de países

Cada domínio controla como são criados seus subdomínios. Para a criação de um novo domínio, é necessária apenas a permissão daquele no qual será incluído.

Não há qualquer restrição sobre a quantidade de subdomínios que podem ser criados dentro de um domínio.

Os nomes de domínio não fazem distinção entre letras maiúsculas e minúsculas. EDU e edu, por exemplo, são o mesmo.

O DNS é implementado sobre o protocolo UDP. Trata-se de um protocolo do nível de transporte que não garante a entrega dos dados no destino.

Dessa forma, cabe ao software DNS garantir uma comunicação confiável.

Resolução de nomes

O espaço de nomes do DNS é dividido em zonas. Independentes, elas possuem um servidor de nomes principal e pelo menos um de nomes secundário:

Servidor de nomes principal — Configurado com as informações das zonas sob sua responsabilidade, ele faz o repasse delas para os servidores de nomes secundários.
Servidor de nomes secundário — Responde pelas zonas caso haja uma falha do servidor de nomes principal.

As zonas do DNS definem o que um servidor deve resolver. Se ele for o responsável pela zona pesquisada (servidor autoritativo), deverá fazer a resolução solicitada.

Três principais componentes do DNS

Registros de recursos armazenados em um banco de dados distribuído.
Servidores de nomes DNS responsáveis pela manutenção de zonas específicas.
Solucionadores DNS em execução nos clientes.

Solucionador x servidor DNS

Quando um solucionador solicita a resolução de um nome para o servidor DNS, pode acontecer o seguinte:

O servidor DNS é o responsável pela zona: O servidor resolve o nome solicitado e o devolve ao solucionador.
O servidor DNS não é o responsável pela zona, mas possui a resolução em cache: O servidor envia a resolução ao solucionador.
O servidor DNS não é o responsável pela zona nem possui a resolução em cache: O servidor precisa realizar uma busca para resolver o nome.

Ok, falamos bastante da camada de aplicação, agora é hora de falar sobre a camada de transporte.

Mas para que serve a camada de transporte?

Executadas na camada de aplicação, as aplicações precisam de um modelo de rede no qual haja a entrega de uma mensagem tanto em um ponto de rede quanto em sua aplicação par no hospedeiro destino.

O objetivo da camada de transporte é, independentemente das redes físicas em uso, promover a confiabilidade na transferência de dados entre os hospedeiros origem e destino.

Aspectos fundamentais da camada de transporte

Em uma arquitetura de camadas, podemos afirmar que o objetivo geral de uma camada é oferecer serviços àquela imediatamente superior.

No caso da camada de transporte, sua pretensão é oferecê-los à de aplicação.

Como um dos principais objetivos da camada de transporte é ofertar um serviço confiável e eficiente a seus usuários, ela precisa oferecer, no mínimo, um serviço orientado à conexão e outro sem conexão.

Para atingir esse objetivo, a camada de transporte utiliza os serviços oferecidos pela de rede.

No serviço de transporte orientado à conexão, existem três fases:

Estabelecimento da conexão
Transferência de dados
Encerramento da conexão

Por meio de um controle apurado da conexão, esse serviço de transporte consegue verificar quais pacotes chegaram com erro ao destino e até mesmo aqueles que não foram enviados, sendo capaz de retransmiti-los até que os dados estejam corretos.

Já no serviço de transporte sem conexão, não existe nenhum controle sobre os pacotes enviados.

Se um deles se perder ou chegar ao destino com erro, nada será feito para obter a sua recuperação.

Se a rede oferece um serviço com que garanta uma entrega sem erros, por que uma aplicação optaria por um serviço sem essa garantia?

A resposta é simples: por questões de desempenho.

Pelo fato de ser preciso cuidar de cada pacote no serviço orientado à conexão, verificando-os e retransmitindo-os em caso de necessidade, esse controle gera um overhead.

Aplicações como transferência de arquivos e e-mail exigem que seus dados cheguem ao destino livres de erros. Dessa forma, elas utilizam um serviço orientado à conexão.

Ainda assim, em certas aplicações, o mais importante é a chegada a tempo de uma informação, mesmo que ela contenha erros ou que a mensagem anterior tenha se perdido.

Endereçamento (camada de transporte)

Quando seu programa solicita algo a um servidor, o sistema envia uma mensagem para ser entregue à aplicação que executa em um hospedeiro remoto.

Mas podem existir várias aplicações nele.

Como identificamos uma aplicação específica?

Surge neste momento o endereçamento no nível de transporte. Sua função é identificar em qual aplicação determinada mensagem deve ser entregue.

Afinal, toda mensagem do protocolo de transporte carrega o endereço da aplicação.

Verificaremos agora a importância do endereçamento no nível de transporte.

Afinal, é necessário indicar em qual aplicação os dados devem ser entregues por meio de seu endereço (de transporte).

Assim, o hospedeiro destino consegue saber o destino deles.

Estudaremos mais adiante TCP e UDP, dois protocolos da camada de transporte da arquitetura TCP/IP.

Neles, o endereço de transporte é conhecido como porta.

Multiplexação e demultiplexação

A multiplexação e a demultiplexação fornecem um serviço de entrega, processo a processo para aplicações executadas nos hospedeiros.

No hospedeiro destino, a camada de transporte recebe segmentos de dados da camada de rede, tendo a responsabilidade de entregá-los ao processo de aplicação correto.

Um processo pode ter um ou mais endereços de transporte (conhecidos como portas na arquitetura TCP/IP) pelos quais dados passam da rede para o processo – e vice-versa.

Como o hospedeiro destino direciona à porta correta um segmento que chega?

Para essa finalidade, cada segmento da camada de transporte tem um conjunto de campos de endereçamento no cabeçalho.

No receptor, a camada de transporte examina esses campos para identificar a porta receptora e direcionar o segmento a ela.

A tarefa de entregar os dados contidos em um segmento para a porta correta é denominada demultiplexação.

Já a multiplexação consiste no trabalho de, no hospedeiro origem:

Reunir porções de dados provenientes de diferentes portas.
Encapsular cada porção de dados com as informações de cabeçalho (as quais, mais tarde, serão usadas na demultiplexação) para criar segmentos.
Passar os segmentos para a camada de rede.

Vejamos um exemplo, vamos pensar no computador que Eduardo utiliza em suas atividades.

Navegando na web, ele acessa seu e-mail e faz o download de arquivos usando um programa específico para isso. De fato, o objetivo da multiplexação é possibilitar ****uma melhor utilização ****do meio de comunicação ****ao permitir que ele seja compartilhado pelos diversos programas utilizados.
Eduardo utiliza a Internet, cujo protocolo de transporte é o TCP.
Todos os programas operados por ele (browser web, cliente de e-mail e programa de transferência de arquivos) utilizam o TCP, que fará a transferência da informação até o destino.

A multiplexação, portanto, permite que vários programas possam utilizar o TCP ao mesmo tempo, fazendo, assim, com que Eduardo possa ter tantos programas quanto queira ao acessar a rede.

Como o TCP sabe quem é quem?

Para fazer uso dele, um processo deve se registrar em uma porta (endereço de transporte) do protocolo TCP.

Servidores possuem portas conhecidas, mas programas clientes se registram nas aleatórias.

Vamos supor que os programas de Eduardo se registraram nas seguintes portas:

Browser web — 11278
Cliente de email — 25786
Transferência de arquivos — 3709

Dessa maneira, o TCP pode identificar cada uma.

Quando o browser envia uma solicitação a um servidor web, o TCP coloca na informação enviada o número de porta 11278.

O servidor, portanto, já sabe que deve responder-lhe enviando a resposta para essa porta.

Loops avançados e recursividade

Andres dos Santos — Tue, 16 Sep 2025 21:00:49 +0000

Nesse post vamos ver técnicas avançadas de declarar loops, vou te passar exemplos explicativos de como eles são escritos e usados.

Loops com múltiplas variáveis

É uma técnica em que muitas variáveis são inicializadas, testadas e atualizadas simultaneamente dentro de um único loop.

Esse método é útil quando precisamos controlar ou monitorar mais de um valor ao mesmo tempo.

Quando falamos de um loop for, podemos inicializar diversas variáveis, definir condições de continuidade para todas elas e atualizá-las a cada iteração do loop.

Isso é útil para problemas que envolvem iterações dependentes de múltiplas variáveis ou para manipulações complexas de dados.

#include <stdio.h>

int main() {
    for (int i = 0, j = 10; i < j; i++, j--) {
        printf("i = %d, j = %d\\n", i, j);
    }
    return 0;
}

Nesse exemplo, i é incrementado e j é decrementado em cada iteração, permitindo um controle simultâneo de duas variáveis dentro do mesmo loop.

Loops com condições múltiplas

Utilizam mais de uma condição para determinar quando devem continuar ou parar.

Isso é frequentemente realizado com o loop for, em que a expressão de condição pode incluir múltiplas condições combinadas usando operadores lógicos (“&&” para E lógico e “||” para OU lógico).

Loops com condições múltiplas são úteis para situações em que o controle do loop depende de várias variáveis ou condições que precisam ser verificadas simultaneamente.

#include <stdio.h>

int main() {
    for (int i = 0, j = 10; i < 5 && j > 5; i++, j--) {
        printf("i = %d, j = %d\\n", i, j);
    }
    return 0;
}

Nesse exemplo, o loop continua enquanto i for menor que 5 e j for maior que 5.

As duas condições são avaliadas simultaneamente e o loop só prossegue se ambas forem verdadeiras.

Loops com atualizações complexas

São loops em que a variável de controle é modificada de maneiras mais sofisticadas que simples incrementos ou decrementos.

Esses loops frequentemente utilizam expressões condicionais, cálculos matemáticos ou funções para alterar a variável de controle a cada iteração.

Isso permite uma maior flexibilidade e controle sobre o fluxo do loop, adaptando-se a requisitos específicos ou padrões de iteração não lineares.

#include <stdio.h>

int main() {
    for (int i = 0; i < 100; i += (i % 2 == 0) ? 1 : 2) {
        printf("%d ", i);
    }
    return 0;
}

Nesse exemplo, a variável i é atualizada de maneira diferente dependendo de sua paridade: se i for par, é incrementado por 1; se for ímpar, é incrementado por 2.

Essa lógica de atualização complexa permite que o loop siga um padrão de iteração não trivial.

Uso de continue e break

Nos loops for, continue e break são usados para controlar o fluxo de execução.

// Uso do continue

while (testExpression) {
  // code
  if (testExpression) {
    continue;
  }
  // code
}

Faz com que o loop pule a iteração atual e prossiga com a próxima iteração, verificando a condição do loop novamente.

// Uso do continue

while (testExpression) {
  // code
  if (testExpression) {
    break;
  }
  // code
}

Interrompe o loop imediatamente, saindo dele antes que todas as iterações sejam concluídas.

Os comandos continue e break são úteis para evitar certas condições ou para terminar o loop com base em critérios específicos.

Recursividade

Descubra o que é recursividade e aprenda como usá-la para simular loops simples, como while e for.

Antes disso você precisa saber o que é um procedimento, nada mais é do que um bloco de código que retorna um valor vazio (void).

Procedimentos são frequentemente usados para modularizar o código, dividindo-o em partes mais gerenciáveis e reutilizáveis.

#include <stdio.h>

// Definição de procedimento para imprimir uma mensagem
void imprimirMensagem() {
    printf("Olá, mundo!\\n");
}

int main() {
    // Chamada do procedimento
    imprimirMensagem();
    return 0;
}

Nesse exemplo, o procedimento imprimirMensagem é definido com o tipo de retorno void, o que significa que não retorna nenhum valor.

Agora sim, vamos a recursividade, é um conceito importante em programação, em que uma função chama a si mesma para resolver problemas de forma mais simples e eficiente.

Recursividade é uma técnica que pode ser usada para substituir loops, dividir problemas complexos em partes menores e simplificar a lógica de muitos algoritmos.

Para ilustrar o conceito de recursividade, veja um exemplo simples de uma função recursiva em C que simula o comportamento de um loop.

Considere o código a seguir, que usa recursividade para imprimir números de n até 1.

#include <stdio.h>

// Função recursiva para imprimir números de n até 1
void recursiveLoop(int n) {
    if (n > 0) {
        printf("%d ", n);  // Imprime o valor atual de n
        recursiveLoop(n - 1);  // Chama a si mesma com n - 1
    }
}

int main() {
    int numero = 5;
    printf("Contagem regressiva: ");
    recursiveLoop(numero);
    return 0;
}

Definição da função — a função recursiveLoop é definida para aceitar um único argumento. Essa função imprime o valor de n ****e depois chama a si mesma com n - 1.
Caso-base — a recursividade é controlada por uma condição base if (n > 0). Quando chega a 0, a função para de chamar a si mesma, evitando um loop infinito. Se n for maior que 0, a função imprime o valor atual e faz uma chamada recursiva com n - 1**.**
Chamada recursiva — cada chamada de recursiveLoop ****reduz o valor de em 1. Isso cria uma série de chamadas que eventualmente atingem o caso-base.

Recursividade é uma técnica essencial para resolver problemas que podem ser divididos em subproblemas menores.

Resumindo

A chave para entender a recursividade é identificar o caso-base e garantir que cada chamada recursiva se aproxime desse caso-base, prevenindo loops infinitos.

Embora simples, esse conceito é aplicável a uma gama de problemas, desde travessias de estruturas de dados complexas até algoritmos de ordenação e busca.

Com a prática, a recursividade se torna uma ferramenta valiosa no arsenal de qualquer programador.

devto api

Andres dos Santos — Mon, 08 Sep 2025 18:54:21 +0000

Agora sim, temos um post publicado no X.

devto api

Andres dos Santos — Mon, 08 Sep 2025 18:48:00 +0000

Agora sim, temos um post publicado no X.

devto api

Andres dos Santos — Mon, 08 Sep 2025 18:09:08 +0000

    Agora sim, temos um post publicado no DevTO.


    <p>Confira no meu site https://andresdosantos.com/posts/cmfbf3ohlst6n07lkn0cyx428.</p>