Forem: Luiz Eduardo Prado Veltroni

O que é nome de domínio - Internet

Luiz Eduardo Prado Veltroni — Thu, 26 Oct 2023 16:23:18 +0000

Nomes de Domínio são uma parte fundamental da infraestrutura da Internet. Eles são essenciais para nossa navegação na web, permitindo que identifiquemos e acessemos facilmente os sites. Os nomes de domínio fornecem endereços legíveis para servidores web disponíveis na Internet.

Qualquer computador conectado na Internet pode ser alcançado através de um endereço IP público, consistido de 32 bits para IPv4 e 128 bits para IPv6 como vimos no artigo falando sobre DNS. Computadores podem manipular esses endereços facilmente, mas as pessoas tem dificuldade em descobrir quem está executando o servidor ou que serviço o site oferece. Endereços de IP são difíceis de lembrar e podem mudar com o tempo. Para resolver todos esses problemas nós usamos endereços legíveis chamados domain names (nomes de domínio).

Estrutura dos domínios

Um "nome de domínio" tem uma estrutura simples construída por algumas partes, que são separadas por pontos e lidos da direita para a esquerda. Cada uma dessas partes nos fornecem informações importantes sobre o domínio, exemplo:

O que é TLD (Top-Level Domain):

O TLD nos trazem informações mais genéricas, como informar aos usuários o propósito geral do serviço por trás do nome de domínio.

Existem os TLDs mais genéricos como: .com, .org, .net.

Alguns TLDs como: .us, .fr, or .sh podem exigir que o serviço seja fornecido em um determinado idioma ou hospedado em um determinado país.

O que é Label (ou componente):

Os labels são os que seguem o TLD. Não existe uma forma correta de escrever um label, pode ser qualquer coisa, de uma letra a uma frase completa, geralmente no label vai o nome da empresa ou produto que irá conter no site.

Também podemos chamar eles de Domínio de Nível Secundário (SLD) ou ******Subdomínio*****. Um *nome de domínio pode ter muitos labels, não é obrigatório ter 3 labels para formar um nome de domínio.

Como ter um nome de domínio

Diferente do que dizem por ai, não é possível você "comprar um nome de domínio". O que nós fazemos é pagar pelo direito de usar um nome de domínio por um ano ou mais (depende do que está no plano contratado).

Você pode renovar seu direito quantas vezes/anos quiser, e sua renovação tem prioridade sobre as aplicações de outras pessoas (sim, da para outra pessoa comprar o seu nome de domínio caso você não renove, então fique de olho).

As empresas famosas que vendem esse tipo de serviço são chamadas registradoras, que utilizam registros de nome de domínio para acompanhar as informações técnicas e administrativas que conectam você a seu nome de domínio.

CUIDADO: Em alguns casos, os registradores se aproveitam dos nomes de domínio expirados, comprando esses domínios no momento em que expiram e, vendendo de volta ao registrante original por um preço elevado.

Diferença entre nome de domínio e URL

Um localizador uniforme de recursos (URL) que muitas é vezes chamado de endereço, caminho, site, entre outros, contém o nome de domínio e também trás outras informações importantes, como, o protocolo usado no site e o caminho que você se encontra.

Os nomes de domínio desempenham um papel fundamental na nossa experiência na web, fornecendo endereços legíveis que simplificam a navegação e o acesso a sites. Eles são uma parte vital da infraestrutura da Internet, conectando-nos a servidores web em todo o mundo.

Lembre-se de que a renovação do seu nome de domínio é crucial para mantê-lo sob seu controle.

DNS e como funciona - Internet

Luiz Eduardo Prado Veltroni — Wed, 04 Oct 2023 13:53:26 +0000

O que é DNS?

O Domain Name System (DNS) é como um "tradutor" da internet que ajuda a encontrar sites. Imagine que a internet é como um mundo com milhões de endereços secretos. Nós, seres humanos, lembramos melhor de nomes amigáveis, como "www.exemplo.com", em vez de números complicados, como "192.168.1.1".

Aqui está uma comparação simples: pense no DNS como uma lista telefônica enorme, mas em vez de números de telefone, ela tem nomes de sites. Quando você digita um nome de site, o DNS pega esse nome e o transforma em um número especial que os computadores usam para encontrar o site na internet. É como se o DNS dissesse ao seu computador: "Ei, o site que você está procurando fica no número 192.168.1.1".

Atualmente, existem dois tipos de números que o DNS usa:

IPv4: São números como "192.168.1.1".
IPv6: São números ainda mais longos, como "2400:cb00:2048:1::c629:d7a2". Mas você não precisa se preocupar muito com eles.

Se quiser saber mais sobre as diferenças entre IPv4 e IPv6, você pode ler este artigo.

Como funciona o DNS?

O DNS se preocupa em transformar nomes de sites em números de internet (endereços IP). Vamos ver como isso acontece em algumas etapas simples:

Muitas vezes, as informações de pesquisa de DNS serão armazenadas em cache ignorando algumas etapas que iremos mostrar abaixo.

Etapas de uma pesquisa de DNS:

Você abre seu navegador e digita um nome de site, como "exemplo.com". Essa solicitação é enviada para um tipo especial de computador chamado "resolvedor DNS".
O resolvedor pega esse endereço e então consulta em um servidor de nomes raiz DNS.
O servidor raiz então responde ao resolvedor com o endereço de um servidor DNS de nível superior (TLD) (como .com ou .net), que armazena as informações de seus domínios. Ao pesquisar por example.com, nossa solicitação é direcionada para o TLD .com.
O resolvedor então realiza uma solicitação para o Servidor DNS de nível superior (TLD) .com.
Servidor DNS de nível superior (TLD) então responde com o endereço IP do servidor de nomes do domínio, exemplo.com.
Por fim, o resolvedor recursivo envia uma consulta ao servidor de nomes do domínio.
O endereço IP de example.com é retornado ao resolvedor do servidor de nomes (192.168.1.1).
O resolvedor de DNS responde ao navegador da Web com o endereço IP do domínio solicitado inicialmente.

Depois que as 8 etapas da pesquisa de DNS retornarem o endereço IP de example.com, o navegador poderá fazer a solicitação para a página da web:

O navegador faz uma solicitação HTTP para o endereço IP.
O servidor naquele IP retorna a página da web para ser renderizada no navegador.

O que é um resolvedor de DNS?

Pense no resolvedor de DNS como um detetive da internet que ajuda seu computador a encontrar os sites que você deseja visitar. Ele é o primeiro passo em uma busca na internet e lida com a solicitação inicial do cliente.

Servidor Raiz

Imagine o Servidor Raiz como o "diretório principal" da internet. É o ponto de partida na pesquisa de DNS. Ele não possui informações específicas sobre domínios individuais, como "example.com", mas ele saberá guiar até os domínios de topo, como ".com", ".org", ".net" e assim por diante.

Servidor TLD (Top-Level Domain)

Ele está um passo mais próximo dos domínios específicos. Quando você digita um domínio, como "example.com", o Servidor Raiz encaminha sua solicitação para o servidor TLD correspondente ao domínio de topo, que no caso de "example.com" seria o servidor TLD ".com".

Servidor Autoritativo

Um servidor autoritativo é um servidor que é a "fonte definitiva" de informações sobre um domínio específico. Isso significa que ele possui registros detalhados e precisos para um domínio específico.

O que é cache de DNS? Onde ocorre o cache de DNS?

O cache de DNS é como a memória temporária do seu computador. Ele armazena informações sobre sites que você visitou recentemente para tornar a navegação mais rápida e eficiente.

O cache de DNS é armazenado em diferentes lugares e cada um deles mantém as informações por um período específico, chamado "tempo de vida" (TTL).

Cache de DNS do navegador

Quando você usa um navegador da web moderno, ele armazena temporariamente informações de DNS dos sites que você visita. Isso significa que, se você retornar a um site recentemente visitado, o navegador verificará primeiro no cache de DNS para encontrar o endereço, tornando a navegação mais rápida.

Por exemplo, o Google Chrome permite verificar o status do seu cache DNS através do link chrome://net-internals/#dns.

Cache de DNS no nível do sistema operacional (SO)

O sistema operacional do seu computador também possui seu próprio cache de DNS. Quando um aplicativo, como um navegador, precisa encontrar o endereço IP de um site, ele verifica primeiro o cache do sistema operacional.

Com isso nós vimos o básico de DNS, o que é, qual o caminho que ele faz até nos retornar o arquivo da página e seus possíveis cache, lembrando que o conteúdo é bem mais complexo do que foi apresentado aqui, a ideia é dar apenas uma pincelada no assunto.

O que é HTTP - Internet

Luiz Eduardo Prado Veltroni — Thu, 13 Jul 2023 22:03:58 +0000

Dando continuidade à nossa série de introdução à internet, no post anterior Como funciona a internet? - Internet 1/5, introduzimos algumas siglas como HTTP e HTTPS. Desta vez, iremos nos aprofundar mais no conceito do HTTP e entender por que ele foi criado, além de explorar sua linha do tempo ao longo do desenvolvimento da web.

Falaremos sobre "What is HTTP? / O que é HTTP?".

Motivação e criação do HTTP

O HTTP (Hypertext Transfer Protocol) foi desenvolvido por Tim Berners-Lee, conhecido como o pai da internet, juntamente com sua equipe no CERN (Organização Europeia para a Pesquisa Nuclear), no início dos anos 1990. A criação do HTTP surgiu da necessidade de compartilhar informações e recursos de forma eficiente na World Wide Web, que já tinha 30 anos na época.

Berners-Lee estava trabalhando no desenvolvimento da Web, que envolvia a criação de um sistema para interligar documentos por meio de links. No entanto, foi necessário criar um protocolo que permitisse a transferência de dados de maneira padronizada e confiável entre os servidores web e os clientes, como navegadores.

Para isso, Berners-Lee e sua equipe se basearam em várias tecnologias e conceitos que já existiam na época:

Hipertexto: conceito que permite a criação de links entre diferentes documentos.
Modelo cliente-servidor: no qual um cliente solicita informações a um servidor que responde com os dados solicitados.
FTP (File Transfer Protocol): ideia de comandos e respostas para estabelecer uma comunicação entre o cliente e o servidor.

É importante destacar que o HTTP foi projetado para ser um protocolo simples e extensível, permitindo a adição de novos recursos e funcionalidades no futuro. Essa visão de futuro foi uma das razões pelas quais o HTTP se tornou amplamente adotado e evoluiu ao longo dos anos.

Vale ressaltar que houve várias atualizações menores e extensões ao longo dos anos para melhorar o protocolo e adicionar recursos adicionais. Apresentarei apenas algumas atualizações grandes e relevantes para o entendimento.

HTTP/0.9 - 1991

A primeira versão documentada do HTTP foi a HTTP/0.9, lançada em 1991. Foi o protocolo mais simples de todos os tempos, com apenas um método chamado GET para que um cliente pudesse solicitar uma página da web ao servidor.

Aqui está um exemplo de como uma requisição HTTP/0.9 poderia ser:

GET /index.html

Exemplo de resposta:

<html>
  ...
</html>

(connection closed)

HTTP/1.0 - 1996

Ao contrário de seu antecessor, o HTTP/1.0 era capaz de lidar com outros tipos de resposta, como imagens, arquivos de vídeo, texto simples ou qualquer outro tipo de conteúdo. Algumas das principais atualizações lançadas foram:

Adição de novos métodos, incluindo GET, POST e HEAD.
Adição de cabeçalhos HTTP tanto nas solicitações quanto nas respostas.
Adição de códigos de status para identificar a resposta.
Introdução de suporte a conjuntos de caracteres.
Adição de recursos como autorização e codificação de conteúdo.
Entre outros.

Aqui está um exemplo de como uma requisição HTTP/1.0 poderia ser:

GET /api/users/123 HTTP/1.0
Host: example.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Accept: application/json
Referer: <https://www.google.com/>
If-Modified-Since: Sat, 1 Jul 2023 12:00:00 GMT

Exemplo de resposta:

HTTP/1.0 200 OK
Date: Tue, 3 Jul 2023 15:30:00 GMT
Server: Apache/1.3.29 (Unix) PHP/4.4.2
Content-Type: text/html; charset=UTF-8
Content-Length: 1024
Expires: Tue, 3 Jul 2023 16:30:00 GMT
Last-Modified: Mon, 2 Jul 2023 14:30:00 GMT

(response body)
(connection closed)

No início da resposta, há o HTTP/1.0 (HTTP seguido pelo número da versão), seguido pelo código de status 200 e a descrição do código de status.

Nesta versão mais recente, os cabeçalhos de solicitação e resposta eram mantidos em formato ASCII, mas o corpo da resposta poderia ser de qualquer tipo, como imagem, vídeo, HTML, texto simples ou qualquer outro tipo de conteúdo.

Uma das principais desvantagens do HTTP/1.0 era que não era possível ter várias solicitações em uma única conexão. Isso significa que, sempre que um cliente precisava de algo do servidor, ele precisava abrir uma nova conexão TCP e, após o atendimento dessa única requisição, a conexão era encerrada.

HTTP/1.1 - 1999

Após três anos do HTTP 1.0, foi lançada a nova versão HTTP/1.1 em 1999. Ela trouxe diversas melhorias em comparação ao seu antecessor (HTTP/1.0). Algumas das principais melhorias incluídas foram:

Adição de novos métodos HTTP, incluindo PUT, PATCH, OPTIONS e DELETE.
Obrigação de identificação do nome do host no cabeçalho.
Conexões persistentes, ou seja, as conexões não eram fechadas por padrão e eram mantidas abertas, permitindo várias solicitações. Para fechar as conexões, era necessário enviar o cabeçalho "Connection: close" na requisição.
Pipelining, onde o cliente podia enviar múltiplas requisições ao servidor sem esperar a resposta do servidor. O servidor era responsável por retornar as respostas na ordem em que foram solicitadas. Para lidar com essas diversas requisições, era necessário enviar o cabeçalho "Content-Length".
Transferência em chunks, para conteúdo dinâmico em que não é possível identificar o "Content-Length". O servidor enviava o conteúdo em pedaços (chunks), adicionando o "Content-Length" para cada chunk. Após enviar todos os chunks, o servidor enviava um bloco vazio, com "Content-Length" igual a zero, indicando que a transferência foi concluída. Para isso, era necessário enviar o cabeçalho "Transfer-Encoding: chunked".
Cache.
Suporte a conjuntos de caracteres.
Negociação de idiomas.
Cookies de cliente.
Melhor suporte de compressão.
Entre outros.

Aqui está um exemplo de como uma requisição HTTP/1.1 poderia ser:

GET /api/users/123 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: application/json
Accept-Language: en-US,en;q=0.9
Referer: <https://www.google.com/>
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNjI1NDU2NTY4LCJleHAiOjE2MjU0NTY3NjgsImlzcyI6ImV4YW1wbGUuY29tIiwic3ViIjoiYXV0aDB8NTg4ZjFmZGE0NzM0MDMwMDZkM2Y2Y2JhIiwiYXVkIjoiaHR0cHM6Ly9leGFtcGxlLmNvbSJ9.TMszXmUKITDFPf4AiwQ6MCdMbMw8uZlFWmBkOe4CEsA
If-None-Match: "abcdef123456"
If-Modified-Since: Sat, 1 Jul 2023 12:00:00 GMT
Cache-Control: no-cache
Cookie: sessionid=abcde12345; lang=en-US

Exemplo de resposta:

HTTP/1.1 200 OK
Date: Tue, 3 Jul 2023 15:30:00 GMT
Server: Apache/2.4.7 (Ubuntu)
Content-Type: application/json
Content-Length: 256
Cache-Control: public, max-age=3600
Expires: Tue, 3 Jul 2023 16:30:00 GMT
Last-Modified: Mon, 2 Jul 2023 14:30:00 GMT
ETag: "abcdef123456"
X-Powered-By: PHP/7.3.9
Set-Cookie: sessionid=abcde12345; path=/; HttpOnly; Secure
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Frame-Options: DENY
X-Content-Type-Options: nosniff

(response body)
(connection closed)

SPDY - 2009

O Google começou a experimentar protocolos alternativos para tornar a web mais rápida e melhorar a segurança nas trocas de requisições. O principal objetivo era reduzir a latência das páginas. Com isso, em 2009, o projeto SPDY foi anunciado.

Foram realizados diversos testes para otimizar a velocidade e o desempenho, e percebeu-se que, ao focar na latência, haveria um ganho de desempenho constante. Isso levou ao desenvolvimento do SPDY.

Os principais recursos introduzidos pelo SPDY foram:

Compressão de cabeçalhos.
Multiplexação.
Priorização de requisições.
Push de recursos.
Stream ID e Stream Dependency.
Melhorias na segurança.
Entre outros.

Aqui está um exemplo de como uma solicitação e resposta no SPDY poderiam ser:

GET /pagina HTTP/1.1
Host: www.exemplo.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: <https://www.exemplo.com/pagina-anterior>
Cookie: nome=valor; outro_nome=outro_valor
X-SPDY-Stream-ID: 1
X-SPDY-Priority: 3
X-SPDY-Session-ID: abcd1234
X-SPDY-Referrer: <https://www.exemplo.com/referencia>
X-SPDY-URL: /pagina
X-SPDY-Scheme: https
X-SPDY-Host: www.exemplo.com
X-SPDY-Protocol: http/1.1
X-SPDY-Version: 3.1
X-SPDY-Capabilities: spdy/3, http/1.1
X-SPDY-Headers: name,value
X-SPDY-SSL: true
X-SPDY-Status: active
X-SPDY-Compression: gzip
X-SPDY-Method: GET
X-SPDY-Content-Length: 0
X-SPDY-Content-Type: text/html
X-SPDY-Content-Encoding: deflate
X-SPDY-Upgrade: HTTP/1.1, HTTPS/1.3, IRC/6.9, RTA/x11, websocket
X-SPDY-Connection: keep-alive

Exemplo de resposta:

HTTP/1.1 200 OK
Date: Wed, 07 Jul 2023 15:30:00 GMT
Server: Apache/2.4.39 (Unix)
Content-Length: 245
Content-Type: text/html; charset=UTF-8
Expires: Wed, 07 Jul 2023 15:45:00 GMT
Cache-Control: max-age=900
X-SPDY-Stream-ID: 1
X-SPDY-Version: 3.1
X-SPDY-SSL: true
X-SPDY-Status: active
X-SPDY-Compression: gzip
X-SPDY-Content-Encoding: deflate
X-SPDY-Connection: keep-alive

(response body)
(connection closed)

HTTP/2 - 2015

Inspirado pelo SPDY, o HTTP/2 foi lançado em 2015 e trouxe recursos essenciais para a web como a conhecemos atualmente. Ele baseou-se na versão lançada pelo Google e aprimorou alguns recursos.

Os principais recursos introduzidos pelo HTTP/2 foram:

Uso de formato binário em vez de texto.
Multiplexação.
Compressão de cabeçalhos utilizando o HPACK.
Server Push.
Priorização de solicitações.
Melhorias na segurança.

Aqui está um exemplo de como uma solicitação e resposta no HTTP/2 poderiam ser:

GET /api/example?param1=value1&param2=value2 HTTP/2
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Charset: utf-8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Referer: <https://www.example.com/home>
Cookie: session_id=1234567890; language=en_US
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Cache-Control: no-cache
Connection: keep-alive
Content-Type: application/json
DNT: 1
If-Match: "abcdef"
If-Modified-Since: Mon, 01 Jan 2023 00:00:00 GMT
If-None-Match: "xyz123"
If-Range: bytes=500-999
If-Unmodified-Since: Tue, 01 Jan 2023 00:00:00 GMT
Max-Forwards: 10
Pragma: no-cache
TE: trailers, deflate, gzip
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 192.168.0.1
X-Forwarded-Host: www.example.com
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Requested-With: XMLHttpRequest

Exemplo de resposta:

HTTP/2 200 OK
content-type: application/json
content-length: 124
cache-control: public, max-age=3600
date: Wed, 07 Jul 2023 12:00:00 GMT
server: ExampleServer/2.0

{
  "result": "success",
  "data": {
    "key1": "value1",
    "key2": "value2"
  },
  "message": "Request processed successfully"
}

HTTP/3 - 2021

A ultima versão lançada, e que usamos atualmente, é o HTTP/3, ele possuitodos os recursos das versões anteriores, porém utiliza QUIC invés de TCP para a parte da camada de transporte.

A maior motivação para que fosse trocado o TCP pelo QUIC, foi que por conta do HTTP/2 ser multiplexado, e o TCP ser executado em uma única conexão, todas as percas e retransmissão de pacotes que ocorrem na camada do TCP pode bloquear todos os outros fluxos.

Já o QUIC executa múltiplos fluxos e implementa as percas e retransmissão de pacotes independente para cara fluxo, ou seja, caso ocorra um erro, apenas o fluxo com dados naquele pacote irá ser bloqueado.

Em outubro de 2022, 26% de todos os sites estavam usando HTTP/3 .

Pudemos conhecer um pouco sobre as motivações que a CERN teve para dar inicio ao HTTP, sendo a base da web que conhecemos hoje.

Lembrando que o time da CERN reutilizou vários conceitos já existentes na época, trazendo uma nova perspectiva para nós como desenvolvedores, deixo a reflexão no ar.

Passei por cima de todas as atualizações mais impactantes para a evolução do HTTP que conhecemos hoje. Cada atualização é bem mais complexa do que eu apresentei, trouxe apenas alguns conceitos chaves.

No próximo artigo, irei introduzir o conceito de “DNS e como funciona”.

Fontes:

Everything you need to know about HTTP: https://cs.fyi/guide/http-in-depth

What is HTTP?: https://www.cloudflare.com/en-gb/learning/ddos/glossary/hypertext-transfer-protocol-http/

An overview of HTTP: https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview

Protocolo HTTP: Estrutura, solicitações, respostas, métodos e códigos de status: https://www.diegomacedo.com.br/protocolo-http-estrutura-solicitacoes-respostas-metodos-e-codigos-de-status/#google_vignette

Como funciona a internet? - Internet

Luiz Eduardo Prado Veltroni — Tue, 27 Jun 2023 12:28:11 +0000

Você está começando no mundo da web e quer entender melhor como a internet funciona? Como você digita um endereço no campo de busca do navegador, e ele te retorna uma página? Pensando nisso decidi criar uma série com cinco artigos introduzindo os principais temas para compreender melhor o mundo da internet.

Lembrando que todos os assuntos são bem mais complexos do que irei apresentar aqui, a ideia é te dar uma introdução para que você possa ter uma base e conhecer um pouco dos conceitos.

Todas as cinco partes serão baseadas no roadmap.sh criado por Kamran Ahmed, onde eu irei fazer um compilado de todo o conteúdo e resumir em artigos mais direcionados e exemplificado.

Iremos começar pelo “How does the internet work? / Como funciona a internet?”.

Início da Internet

A internet teve início durante a Guerra Fria, nos Estados Unidos. Como um projeto de pesquisa do Departamento de Defesa dos Estados Unidos, chamado ARPANET, na década de 1960. Foi desenvolvida como uma rede de computadores para compartilhamento de informações entre universidades e instituições de pesquisa. O objetivo era criar uma rede robusta e descentralizada que pudesse resistir a um possível ataque de seus inimigos, e mesmo assim poder transitar as informações sem perigo de perda, permitindo a troca de dados de forma eficiente.

A ideia é que eles pudessem trocar informações e documentos em vários pontos a qualquer momento, caso alguma dessas estruturas (computador) viesse a sofrer algum ataque, ou deixar de funcionar, os outros computadores ainda teria a capacidade de acessar aquele documento,

Ao longo do tempo, a internet evoluiu, expandindo-se para além das fronteiras acadêmicas e se tornando uma rede global acessível a todos, conectando pessoas, empresas e organizações em todo o mundo, abrindo as portas para o que nós temos hoje.

O que é uma rede

No mundo da internet, uma rede é um sistema de conexão entre diferentes dispositivos, como computadores, smartphones e servidores, que permite a troca de informações e recursos. É como uma teia de conexões que permite que esses dispositivos se comuniquem entre si.

Uma simples analogia, seria pensar em uma rede de telefones fixos em uma vizinhança. Cada casa tem um telefone e está conectada a outras casas por fios telefônicos. Se alguém em uma casa quer ligar para outra, ele discará o número do telefone daquela casa e a ligação será estabelecida através da rede de fios. Da mesma forma, na internet, os dispositivos estão conectados através de cabos, sinais sem fio ou até mesmo redes móveis, permitindo a comunicação entre eles.

Usando o exemplo do telefone, é como se cada roteador fosse uma rua, e cada dispositivo fosse uma casa. Em cada rua, nós temos diversas casas que se conversam entre si através de cabos, e existem diversas ruas que se conectam.

Atualmente, com o avanço da tecnologia e a proliferação de dispositivos conectados, a rede da internet se expandiu globalmente. É como se fosse uma rede mundial interconectada. Agora, podemos imaginar algo como um grande sistema de estradas, onde cada dispositivo é como um veículo na estrada. Esses dispositivos podem se comunicar com outros dispositivos em qualquer parte do mundo, enviando informações, compartilhando arquivos, transmitindo vídeos e muito mais. É uma rede global que conecta pessoas, empresas e serviços, permitindo a comunicação instantânea e o acesso a uma infinidade de recursos e informações.

Se quiser ler um pouco mais sobre Rede:
https://aws.amazon.com/pt/what-is/computer-networking/

Visão geral da Internet

A Internet é uma rede global que permite a comunicação e transferência de dados entre dispositivos conectados. Para entender como ela funciona, é importante conhecer alguns conceitos básicos. Vou explorar esses conceitos de forma clara e simples para aqueles que estão começando na área.

Vamos começar com o básico: a Internet é como uma superestrada que conecta todos os dispositivos do mundo. E o segredo por trás dessa conexão são dois heróis: o Protocolo de Internet (IP) e o Transmission Control Protocol (TCP). O IP é o guia que ajuda os pacotes de dados a encontrarem seu destino, enquanto o TCP garante que esses pacotes cheguem lá.

Para ter um melhor entendimento é interessante conhecer alguns conceitos que se repetem a todo momento, aqui vai alguns importantes.

Pacote: É uma pequena unidade de dados que a Internet envia pelos ares.
Roteador: É um dispositivo que direciona os pacotes de dados para o lugar certo, pulando de rede em rede.
Endereço IP: É como um RG da Internet, um identificador exclusivo para cada dispositivo conectado.
Nome de domínio: É um nome legível usado para identificar um site, como "google.com".
DNS: É o sistema responsável por traduzir nomes de domínio em endereços IP.
HTTP: É a linguagem dos navegadores e sites, que permite a transferência de dados.
HTTPS: É a versão criptografada do HTTP, que garante que a comunicação entre cliente e servidor seja segura e tranquila.
SSL/TLS: São protocolos de segurança usados para proteger nossas informações pessoais durante a navegação na Internet.

IP e DNS

Um endereço IP é como o endereço de uma casa, é o identificador único do seu dispositivo na Internet. Representado por uma série de números separados por pontos, como "192.168.1.1".

Os nome de domínio é o apelido charmoso que atribuímos aos sites. O DNS (Domain Name System) entra em ação para traduzir esses apelidos em endereços IP, por exemplo, "google.com" é um nome de domínio.

O fluxo que ocorre nos bastidores da internet é o seguinte:

Quando você digita um domínio na barra de busca do seu navegador, como por exemplo "https://www.google.com", o navegador envia uma solicitação a um servidor DNS, perguntando se ele tem o IP correspondente àquele domínio. Caso o servidor DNS não possua essa informação, ele busca em outros servidores DNS até encontrar o IP correto. Assim que o servidor encontra o IP, ele o retorna ao usuário para que possa se conectar ao site desejado.

Se quiser ler um pouco mais sobre IP e DNS: https://support.google.com/a/answer/2573637?hl=pt

HTTP e HTTPS

HTTP (Hypertext Transfer Protocol) e HTTPS (HTTP Secure) são dois dos protocolos mais usados em aplicativos e serviços baseados na Internet.

HTTP é o protocolo usado para transferir dados entre um cliente (navegador) e um servidor (site). Ao entrar em um site, o seu navegador realiza uma solicitação HTTP para o servidor, essa solicitação pode ser a própria página ou recursos como imagens, vídeos, etc. O trabalho do servidor é responder, com os recursos que foram solicitados pelo cliente.

HTTPS é uma versão mais segura do HTTP, que criptografa os dados transmitidos entre o cliente e o servidor usando SSL/TLS, com isso temos uma camada extra em questão de segurança, já que essa comunicação é realizada com a criptografia SSL/TLS, protegendo dados sensíveis, como é mostrado na imagem.

Se quiser ler um pouco mais sobre HTTP e HTTPS: https://www.alura.com.br/artigos/qual-e-diferenca-entre-http-e-https?gclid=Cj0KCQjw7uSkBhDGARIsAMCZNJsCrmh2CPNjpRzQFwRbetkjJbkd3oN0ab_7JS-idxXEKlHQJvTyO0EaApwxEALw_wcB

TCP/IP

O TCP/IP (Transmission Control Protocol/Internet Protocol) é um protocolo de comunicação utilizado pela maior parte dos aplicativos e serviços que nós temos hoje na internet, focando na entrega de dados confiáveis, ordenadas e com verificação de erros entre aplicativos executados em diferentes dispositivos.

Termos e conceitos chaves para entender melhor o TCP/IP:

Portas: São usadas para identificar o aplicativo ou serviço em execução em um dispositivo, cada aplicativo ou serviço recebe um número de porta exclusivo.
Sockets: São como fones de ouvido, conectando os endereços IP e as portas para uma conversa exclusiva entre aplicativos.
Conexões: São estabelecidas entre dois sockets quando dispositivos desejam se comunicar. Durante o processo de estabelecimento da conexão, são negociados parâmetros importantes.
Transferência de dados: Uma vez que a conexão está rolando, os dados fluem entre os aplicativos em pacotes com metadados, garantindo uma entrega de sucesso.

Se quiser ler um pouco mais sobre TCP/IP: https://tecnoblog.net/responde/o-que-e-tcp-ip/

SSL/TLS

SSL/TLS é um protocolo usado para criptografar os nossos dados que são transmitidos pela Internet. É usado para fornecer conexões seguras para aplicativos.

Termos e conceitos chaves para entender melhor o SSL/TLS:

Certificados: São usados para estabelecer a confiança entre cliente e servidor. Contêm informações sobre a identidade do servidor e são assinados por terceiros confiáveis.
Handshake: É o processo de troca de informações entre cliente e servidor para negociar a criptografia e outros parâmetros para a conexão segura.
Criptografia: Após a conexão segura ser estabelecida, os dados são criptografados usando o algoritmo acordado e transmitidos com segurança entre cliente e servidor.

Se quiser ler um pouco mais sobre SSL/TLS: https://rockcontent.com/br/blog/tls-ssl/

Dessa maneira chegamos ao fim desse artigo, falamos um pouco sobre alguns tópicos de como a internet é formada, o objetivo era apenas trazer alguns conceitos para que nós possamos nos aprofundar futuramente. No segundo artigo, irei trazer um pouco mais sobre “O que é HTTP”.

Fonte:

How does the Internet Work?: https://cs.fyi/guide/how-does-internet-work

The Internet: IP Addresses & DNS: https://www.youtube.com/watch?v=5o8CwafCxnU&ab_channel=Code.org

How does the Internet work?: https://developer.mozilla.org/en-US/docs/Learn/Common_questions/Web_mechanics/How_does_the_Internet_work

História da internet:
https://pt.wikipedia.org/wiki/Hist%C3%B3ria_da_Internet

O surgimento da internet: https://www.fatosdesconhecidos.com.br/o-surgimento-da-internet/

Git Stash - Git e Github

Luiz Eduardo Prado Veltroni — Sat, 01 Oct 2022 00:37:08 +0000

Você com certeza já se deparou com uma situação na qual sua responsabilidade é desenvolver/corrigir uma feature, e em algum momento surge uma urgência de última hora, em uma outra branch, mas e o seu código que ainda não está pronto para o commit, o que fazer com ele? Com essa situação em mente, o git stash vem para nos ajudar.

Git Stash

git stash arquiva (ou faz o stash) de alterações que você fez na cópia de trabalho durante um determinado período, para que você possa trabalhar em outra coisa, depois voltar e fazer a reaplicação mais tarde. O stashing é útil quando você precisa alternar com rapidez o contexto e trabalhar em outra coisa, mas está no meio da alteração de código e não está pronto para fazer commit.

Com o git stash é possível “salvar” suas alterações sem precisar realizar um commit (Lembrando que arquivos preparados e não preparados são incluídos no stash) para você utilizar em algum outro momento.

Criando um Stashes

Digamos que você realizou parte da sua task no arquivo index.html e criou o styles.css, porém foi pedido para você realizar uma correção em uma outra branch, podemos então criar o nosso primeiro Stash.

Antes do stash, podemos ver o status dos nossos arquivos:

$ git status

Changes not staged for commit:
modified: index.html

Untracked files:
new file: styles.css

Podemos ver que existe o index.html como modified e o nosso styles.css como new file, agora criaremos o nosso Stash:

$ git stash

Saved working directory and index state WIP on main: fe442e6 Delete comments on index.html

E rodando novamente o git status, ele nos mostra que não existe alterações/criações.

$ git status

On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

Nesse momento, você pode realizar alteração, criar novos commits, alternar branchs e executar quaisquer outras operações do Git. Quando estiver satisfeito, poderá “trazer” de volta o seu stash, explicarei mais a frente como realizar o git stash pop.

Lembrando que o stash só existe no local, e stashes não são enviados para o servidor remoto quando você realizar o push.

Trazendo as alterações com o pop

Nesse momento você já finalizou o que tinha que fazer em alguma outra ramificação do projeto, e está pronto para dar continuidade a sua antiga task, agora iremos ver como aplicar as alterações existentes no stash utilizando o git stash pop

Executamos o status para visualizarmos as alterações existentes:

$ git status

On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

E agora trazemos as alterações utilizando o pop:

$ git stash pop
On branch main

Changes not staged for commit:
modified: index.html

Untracked files:
new file: styles.css

Dropped refs/stash@{0} (04aa236313d158de0edbf4a9d50e84ed7c23b92c)

Executar o pop no stash aplica as alterações no projeto e as remove.

Uma outra flag interessante nesse sentido é o apply que irá aplicar as alterações, porém o stash ainda vai existir, caso você queria aplicar em alguma outra branch:

$ git stash apply
On branch main
Changes to be committed:

new file: style.css

Changes not staged for commit:

modified: index.html

Por padrão, o Git não vai fazer o stash de alterações feitas a arquivos ignorados ou não rastreados.

Gerenciar múltiplos stashes

Importante destacar, que você não fica limitado a apenas um único stash, você é capaz de criar múltiplos stathes. Sendo possivel visualizar todos os stashes criados utilizando a flag list:

$ git stash list
stash@{0}: WIP on main: 5002d47 our new homepage
stash@{1}: WIP on main: 5002d47 our new homepage
stash@{2}: WIP on main: 5002d47 our new homepage

Por padrão, os stashes são nomeados com "WIP" — Work in Progress (Trabalho em progresso), Branch e Commit que foi criado.

Uma boa prática existente para você criar os seus stashes a longo prazo sem se perder, ou ficar totalmente confuso, é a flag save ela permite nós passarmos uma string que seria o nome/descrição daquele stash.

$ git stash save "add style to our site"
Saved working directory and index state On main: add style to our site
HEAD is now at 5002d47 our new homepage

$ git stash list
stash@{0}: On main: add style to our site
stash@{1}: WIP on main: 5002d47 our new homepage
stash@{2}: WIP on main: 5002d47 our new homepage

Por padrão, git stash pop vai trazer o stash mais recente: stash@{0}

Podemos escolher qual stash aplicar, utilizando o seu identificador (stash@{number}):

$ git stash pop stash@{2}

Limpar seu stash

Se em determinado momento você decidir que um stash não será mais necessário, é possível excluir um ou mais stashes:

Para apagar um stash isolado:

$ git stash drop stash@{1}
Dropped stash@{1} (17e2697fd8251df6163117cb3d58c1f62a5e7cdb)

Ou você pode excluir todos:

$ git stash clear

Visualizar comparações de stash

Imagine uma situação onde você tem alguns stashes criados, e não se lembra o que tem exatamente naquele primeiro stash criado, para isso temos a flag show , vale lembrar que ele sempre vai mostrar por padrão o stash mais recente (stash@{0}):

$ git stash show
index.html | 1 +
style.css | 3 +++
2 files changed, 4 insertions(+)

Para visualizar um stash em especifico, basta passar o identificador dele:

$ git stash show *stash@{0}*
index.html | 3 +++
style.css | 1 +
2 files changed, 4 insertions(+)

Lembrando que ele mostra de uma forma resumida, podemos utilizar o -p (ou --patch) para uma inspeção mais detalhada.

Fazer stash em arquivos ignorados ou não rastreados

Um problema (ou não), é que o stash não irá ser aplicado em arquivos não rastreados (Arquivos criados que não passaram por nenhum commit), para resolver essa questão, podemos adicionar a flag -u (ou --include-untracked).

Você também pode incluir alterações para arquivos ignorados (Dentro do .gitignore), passando a flag -a ou --all).

Fonte:

https://git-scm.com/docs/git-stash

https://www.atlassian.com/br/git/tutorials/saving-changes/git-stash

Padronização com GitFlow - Git e Github

Luiz Eduardo Prado Veltroni — Thu, 12 May 2022 02:40:48 +0000

Depois que aprendemos a trabalhar com as Branchs e os Merges, é importantes nós criarmos alguns padrões e organização do projeto, para não ficar aquela bagunça no histórico. Com esse pensamento o Holandês Vincent Driessen teve a brilhante ideia de criar o GitFlow.
O Gitflow é apenas uma ideia abstrata do fluxo de trabalho normal do Git, ou seja, ele dita que tipos de branchs configurar e como realizar o merge.

Branchs e Merge

Antes de entendermos o GitFlow, é necessário termos dois conceito que são fundamentais, branch e merge bem claro, para isso sinta-se avontade de ler meus dois artigo onde eu explico bem isso, Conceito de Branch - Git e Github onde explico bem sobre a Branch, e Conceito de Merge - Git e Github onde falo sobre Merge.

Fluxo do GitFlow

Para ficar mais claro, podemos classificar o GitFlow em dois tipos de Branch:

Principais: São as Branch Master e Develop;
Suporte: São as conhecidas como Feature, Release e Hotfix.

Regras das branchs:

Master: Utilizada para receber os commits estáveis que foram desenvolvidos na Develop, digamos que são códigos prontos para produção.
Develop: A branch que irá desenvolver todas as novas Features, após revisar e estar estável, ela será responsavél por realizar um merge na Master.
Features: São as branchs criadas a partir da Develop que irão desenvolver uma funcionalidade especifica, fazendo Merge na Develop também.
Releases: Uma vez que se tem uma nova Feature incorporada na Develop, é preciso prepará-la para entrar em produção, o que não pode ser feito levando-a apenas para a Master, é preciso utilizar uma outra Branch de suporte, chamada Release.
Pode ser que apenas após a criação de um conjunto de novas Features que você tenha uma Release pronto. Porém, uma vez que essas Features estejam prontas na Develop, será possível uní-las em um Branch Release.
Hotfixes: São branches para realizar correçõs especificas e criticas que são encontradas em produção, criada a partir da Master, deve ser unida tanto com Develop quanto com a Master.

Após entender a base de todo conceito, existe uma ferramenta para auxiliar a criação e exclusão de branch, chamado GitFlow Extensão.

GitFlow Extensão:

O GitFlow Extensões é uma extensão que auxilia no desenvolvimentos de projetos que utilizam Git, ele tem como objetivo automatizar algumas funções repetivias no processo das branchss, o que ajuda a poupar algumas linhas no terminal.
Para começar a utilizar o GitFlow Extensões, depois de iniciar o Git com o comando git init, basta digitar:

$ git flow init

Ele dá a liberdade de você alterar o nome das Branch de produção, ou a develop, como mudar os prefixos das outras Branches, por exemplo:
Alterar a branch Feature para Feat, dando uma maior liberdade para cada pessoa/time.

Usando $ git flow init [-d] , ele aceita todos os nomes automaticamente.

Primeira feature:

Para criar a primeira Feature, o processo é extremamente simples:

$ git flow feature start <NomeDaBranch>

Com isso ele nos retorna algumas coisas, no Summary of actions:

Uma nova branch foi criada 'feature/formulairo' baseada na 'develop'.
Agora você está na branch 'feature/formulario'.

Encerrando a feature:

Após criar a primeira Feature, digamos que você já implementou e commitou todas as funcionalidades e agora precisa dar um Merge na Develop e excluir ela, para isso rodamos:

$ git flow feature finish <NomeDaBranch>

Voltando para o Summary of actions:, ele explica o que foi realizado:

A branch de feature 'feature/formulario' foi mesclada com a 'develop'.
Branch de feature 'feature/formulario' foi deletada localmente.
Agora você está na branch 'develop'.

Chegamos ao fim, com isso você será capaz de organizar a linha do tempo do seu projeto, a ideia do GitFlow não é fundamental para o desenvolvedor, mas ao longo do tempo, conforme o projeto escala e existem diversas pessoas trabalhando em conjunto ele ajuda a manter a clareza no projeto, e ajuda a padronizar a forma que é realizado o processo de branchs.

Cherry pick — Git e Github

Luiz Eduardo Prado Veltroni — Wed, 09 Mar 2022 04:05:00 +0000

As vezes precisamos pegar um commit individual que se encontra em uma outra branch, com alguma feature ou correção que aconteceu em paralelo, o Cherry pick faz exatamente isso, ele junta dois commits em uma linha do tempo, evitando de repente de realizar um Merge.

Cherry pick

Em alguns momentos nos vemos em uma situação onde estamos desenvolvendo em uma branch(chamaremos de Branch X), porém existe outro integrante do time que está trabalhando em uma task em outra branch (chamaremos de Branch Y), as duas estão sendo desenvolvidas juntas. O dev da branch Y encontrou e corrigiu um bug que impacta diretamente na task da branch X.

Ao invés de ter que realizar um commit e fazer um merge ou qualquer outra gambiarra (Não precisa mandar o código pelo privado) pode ser feito um commit da correção e o dev da branch X usa o Cherry pick para pegar apenas a correção e trazer para a sua linha do tempo.

Lembrando que o cherry pick não é bala de prata, as vezes realmente é melhor fazer um merge.

Cherry pick na prática

Antes de irmos para o Bash, é interessante esclarecer que é necessário ter duas branchs e pelo menos um commit na branch que você vai pegar o commit.

Vamos começar bem do início, precisamos criar uma branch:
git checkout -b feat/header

Realizar um commit:
git commit -am "Feat: create header"

Criar uma nova branch (a que vai receber o commit, no caso da branch feat/header).
git checkout -b feat/menu-hamburger

Imagine agora que o dev que está desenvolvendo na branch feat/header encontrou um problema e já corrigiu, e a pessoa que está na feat/menu-hamburger precisava ter acesso a essa correção.

Agora precisamos pegar o HASH (Identificador) do commit que queremos, para isso vamos na branch que está o commit:
git checkout feat/header

Rodamos um git log para mostrar os commit e seu respectivo HASH:
git log --oneline

Voltamos para a branch que ira receber o commit:
git checkout feat/menu-hamburger

E rodamos o tão famoso Cherry-pick, lembrando de passar o HASH:
git cherry-pick 68bbe92

Resolva os conflitos, se existirem

Pegar um conjunto de commit

Mas e se eu quiser pegar mais de um commit, será que dá? SIM!, o Cherry pick suporta esse tipo de ação.
Segue os mesmo passos do anterior, porém, invés de pegar apenas um HASH você precisa pegar o último e o primeiro (Calma, eu não digitei errado, o último realmente vem na frente) commit que você quer, e ira pegar todos que estiverem dentro dele, a sintaxe é extremamente fácil:

Devemos pegar os dois HASH (o ultimo e o primeiro):
Lembrando que o HASH-A (o ultimo) deve estar após o HASH-B (o primeiro), ou seja ser mais velho na linha do tempo.
git cherry-pick HASH-A HASH-B

Conflitos:

Caso você queira cancelar um Cherry pick, é simples, passe a flag —abort:
git cherry-pick --abort

Para continuar, use a flag —continue:
git cherry-pick --continue

E para pular, —skip:
git cherry-pick --skip

Nesse post vimos como o Cherry pick é extremamente poderoso e importante de conhecer, em algum momento você vai precisar usar, e ele vai salvar a sua vida. É importante identificar quando é melhor utilizar o Cherry pick e quando usar o Merge, mas fique tranquilo por que isso vem com o tempo.

Conceito de Merge — Git e Github

Luiz Eduardo Prado Veltroni — Thu, 13 Jan 2022 14:41:43 +0000

Após conhecermos a tão famosa Branch que tem como propósito dividir a linha original do desenvolvimento do projeto, precisamos "trazer" de volta para a branch main/master, dei uma breve explicação de como fazer isso em Conceito de branch, porém chegou a hora de se aprofundar no merge e resolver os possíveis conflitos que irão aparecer(uma hora ou outra).

Merge

O merge(mesclagem) é o jeito do Git de pegar duas branchs e unificar em apenas um histórico. O comando git merge permite que você pegue as linhas de desenvolvimento independentes criadas pelo git branch e junta elas em apenas uma ramificação.

É de extrema importância ter algo bem claro na hora de realizar um merge, sempre a branch que você está (HEAD) vai ser a que vai "receber" a branch, sendo atualizado para refletir a mesclagem, a branch alvo não sofre nenhum tipo de alteração.

git merge é usado sempre depois do git checkout para selecionar o branch atual que irá receber e com o git branch -d para excluir o branch alvo obsoleto.

Merge na prática

Vamos utilizar um exemplo prático, digamos que você desenvolveu um Header bem básico representado pela branch feat/header (Nomenclatura tirada do Git Flow, explicarei futuramente).

Depois de ter criado uma branch com git checkcout -b feat/header (Lembrando que a flag -b do checkout cria uma branch e já move para ela), realizamos as criações necessárias e commitamos o arquivo index.html com git commit -am "feat: header"(Lembrando que a flag -am adiciona os arquivos e já realiza o commit).

Agora o que precisamos fazer para juntar essa nova feature na branch principal, precisamos ir para a branch receptora, sempre atento para onde o HEAD está apontado, e realizamos o merge. Uma vez que a branch ficou obsoleta podemos excluir ela.

Resolvendo Conflitos

Durante o processo de criação e branchs e a junção com o merge, é possível que mais de um desenvolvedor edite a mesma linha de código, com isso o Git gera um conflito, por ter dois commits o Git não sabe qual utilizar, e não consegue resolver esse problema sozinho, é necessário que o usuário decida qual é o correto.

Digamos que você ficou responsável por editar um link do header e um colega recebeu uma task para alterar a logo do footer, porém acabou adicionando alguns caracteres sem querer no link que você está alterando.

Primeiro você cria uma nova branch de correção e realiza a alteração, cria um commit e mescla com a branch master, durante esse processo um colega adicionou o caractere acidental e realizou um commit na master.

Nossa alteração:

Acidente:

Você finalizou todas as alterações e da um git checkout master que será a branch receptora, e realiza o git merge fix/header, e acaba vendo um output no terminal CONFLICT, e repara que algo mudou no editor de texto (Visual Studio Code).

Terminal:

Visual Studio Code:

Reparamos que ele adicionou alguns caracteres:
<<<<<<< Branch receptora (HEAD)
>>>>>>> Branch de mesclagem (fix/header)
======= Separa as branchs, o de cima represente a branch recepctora e de baixo a de mesclagem.

E podemos ver que existe um menu (clicavel) acima do conflito, nele existe algumas opções rápidas que podemos realizar, as mais importantes são:

Accept Current Change: Irá aceitar a branch receptora, nesse caso ele iria manter os caracteres acidentais.
Accept Incoming Change: Irá aceitar a alteração realizada no header, nesse caso seria "Conheça nossa empresa"
Accpet Both Changes: Ele aceita as duas modificações, criando então duas linhas, uma com os caracteres e outra com as alterações.

No nosso caso queremos aceitar apenas o Accept Incoming Change para manter as alterações que realizamos na branch fix/header, podemos ver que nada muda, por que os arquivos conflitantes agora estão como "Unmerged patch", precisamos adicionar ele no próximo commit git add . e criar um commit de resolução git commit -m "resolve conflitos no header".

E pronto temos o nosso conflito mais comum de acontecer resolvido e já podemos excluir a branch obsoleta das modificações.

Conceito de Branch — Git e Github

Luiz Eduardo Prado Veltroni — Sun, 09 Jan 2022 03:07:01 +0000

Depois de conhecermos os 3 Estados dos arquivos rastreados pelo Git, conseguimos entender e criar o nosso Primeiro repositório no Github, já enviando os arquivos do projeto para o repositório remoto, agora precisamos entender um conceito um pouco mais avançado do Git, as Branchs.

O que são as Branchs?

As branchs(ramificações) é como se fosse uma linha independente de desenvolvimento, todo projeto precisa conter pelo menos uma que é criada automaticamente após o primeiro commit, chamada de main/master. Podemos criar novas ramificações principalmente quando precisamos adicionar uma nova funcionalidade, ou corrigir algum bug, sem interferir no desenvolvimento e andamento do projeto.

Podemos abstrair um pouco tudo isso imaginando a branch como uma "linha do tempo", possuímos a main/master onde o progresso de desenvolvimento ocorre naturalmente, ao criarmos uma nova branch criamos uma nova "linha do tempo" com o mesmo código da main, a diferença é que podemos realizar alterações tranquilamente, já que estamos em uma "linha do tempo" paralela.

Essa imagem ilustra bem o conceito, onde a Branch 1 e a Branch 2 podem ser uma nova feature ou uma correção/alteração e a master segue intacta, agora partiremos para o terminal Bash.

Branch na prática

Para começarmos, que tal nós visualizarmos as novas branchs existentes? no git bash podemos utilizar o comando:

$ git branch

Caso nenhuma branch tenha sido criada, só irá mostrar a main/master que vem por padrão, para criarmos uma nova é realmente simples:

$ git branch NomeDaBranch
(Lembrando que precisamos ter pelo menos um commit no projeto, para o git identificar qual é a branch principal).

Algo normal de acontecer na correria do dia a dia é criar branch com nome errado, para isso o Git tem um comando super simples para renomear uma branch.

$ git branch -m NovoNomeDaBranch

Aparentemente nada mudou, isso é por que você precisa "mover" para a branch criada, você ainda está na main/master, para irmos basta utilizar o comando checkout:

$ git checkout NomeDaBranch

Agora podemos realizar as nossas modificações no código sem interferir na versão principal.

Caso queira excluir a branch, uma vez que ela não será mais usada, lembrando que para isso precisamos estar "fora" da ramificação que vamos deletar.

$ git branch -d NomeDaBranch
ou
$ git branch -D NomeDaBranch

Ok, mas qual a diferença de -d para -D?
Ao usar o -d minúsculo, seria uma forma "segura", já que o Git irá impedir de excluir a ramificação se existirem mudanças não mescladas(Irei explicar um pouco a frente o que significa mesclagem).
E o -D maiúsculo seria ao contrario, ele força uma exclusão mesmo se houver mudanças não mescladas.

Merge

Chegou o momento mais esperado, você finalizou a task, corrigiu o bendito bug no header, e está usando uma branch separada fix/header, agora como podemos juntar essa "linha do tempo" com a ramificação principal? Bem simples, podemos utilizar o Merge.

Primeiro precisamos ir para a branch que queremos receber as alterações e em seguida mesclar as alterações com o merge:

$ git merge fix/header

Agora você conhece um dos principais conceitos do Git, muito utilizado quando existe mais de um desenvolvedor em um projeto, dessa maneira fica tudo bem divido evitando mexerem na mesma linha de código e criarem um conflito ou até pior...

Fontes:
https://www.hostinger.com.br/tutoriais/git-branch
https://git-scm.com/

Primeiro repositório — Git e Github

Luiz Eduardo Prado Veltroni — Thu, 06 Jan 2022 13:26:03 +0000

Um pouco sobre o que é Git e Github e como podemos criar repositórios remotos através de projetos já existentes ou até criar um do zero, após ler o artigo anterior ‘3 Estados dos arquivos — Git e Github’ que mostra os estados dos arquivos rastreados pelo Git.

Git é um sistema de controle de versão distribuído gratuito e de código aberto projetado para lidar com tudo, desde projetos pequenos a muito grandes com velocidade e eficiência.

Através deles podemos desenvolver projetos locais e manter eles guardados remotamente, e temos uma segurança na qual diversas pessoas podem contribuir simultaneamente no mesmo projeto, editando e criando novos arquivos e permitindo que os mesmos possam existir sem o risco de suas alterações serem sobrescritas.

Junto a ferramenta do Git temos a plataforma do Github, pense nele como um Cloud (nuvem) dos códigos, ele representa um serviço de hospedagem de repositório online. Ou seja, é uma rede planejada para projetos que utilizem o Git como controlador de versão.

Git:

Para começarmos a utilizar o Git, precisamos fazer o download dele. Link aqui e instale ele normalmente. E agora temos o tão famoso Git Bash que seria mais ou menos um ‘Prompt de comando’ do Git.

Use no Git bash o comando git --version para verificar se a instalação foi concluída.

Agora vamos configurar o seu Git local com a sua conta do Github (Não tem conta no Github? Crie uma aqui)

$ git config --global user.name SeuUsernameDoGitHub
$ git config --global user.email seuemail@gmail.com
$ git config --global core.editor SeuEditorDeTexto
$ git config --list

Uma explicação de cada comando:

Para definir o seu nome (ira aparecer no Github quando fizer um commit, e outras coisas),
Para definir o seu email (também ira aparecer nos commits),
Configurar o Editor de texto,
Visualizar se as alterações foram salvas com sucesso.

Github:

Agora que estamos com o nosso ambiente local com o Git instalado e configurado, chegou a hora de irmos para a ferramenta Github, primeiro vamos criar o primeiro repositório (projeto).

Clicar em ‘New’ na Dashboard do Github.

Nessa parte podemos criar algumas configurações do repositório (Elas podem ser alteradas futuramente, não se preocupe).

Repository name: O nome do repositório que ira aparecer no seu perfil.

Description: A descrição que ira mostrar quando abrirem o repositório (Escrita em Markdown pelo arquivo README.md).

Public/Private: Isso ira definir se outras pessoas poderão visualizar o projeto

Clicando em ‘Create repository’ seremos redirecionado para a seguinte página:

Sincronizando repositório remoto

Já temos o Git configurado e o repositório no Github criado, e agora o que falta? precisamos criar e enviar arquivos do nosso projeto local onde ele existe apenas no seu computador pessoal, para o novo projeto remoto que existe remotamente no Github, para isso vamos para a pasta do projeto, clique com direito em qualquer lugar e selecione a opção ‘Git Bash’ (No meu caso é uma pasta chamada Git no Desktop).

$ echo "# Estudo Git e Github" >> README.md

Criamos o arquivo README.md responsável pela documentação do projeto, o Github sempre ira ler ele (Markdown) e mostrar na tela inicial do repositório.

$ git init

Inicializamos o Git naquela pasta, ou seja a partir de agora ele irá rastrear todos os arquivos novos dessa pasta.

$ git add README.md

Diz ao Git adicionar o arquivo README.mdao estado de ‘Staged area’ basicamente o arquivo ainda está local porém está pronto para ser Commitado.

$ git commit -m "First commit"

É como se o Git tirasse uma foto de todos os arquivos que estão em ‘Staged area’ e guardasse em um bloco, com uma mensagem identificadora ‘First commit’ uma boa prática é conjugar o verbo no presente do indicativo, utilizando a terceira pessoa do singular (Mais tarde isso irá fazer mais sentido).

$ git branch -M main

Criamos e movemos para uma nova branch ‘main’

$ git remote add origin https://github.com/EduardooPV/git-e-github.git

Adicionamos um novo controle remoto

$ git push -u origin main

Estamos enviando todos os commits realizados localmente para o repositório remoto, se atualizarmos a página no Github veremos que agora existe um novo arquivo chamado README.md que nós criamos com o echo >>.

Extra: sempre use o $ git status para verificar o status dos seus comandos.

Por enquanto é isso, se você adicionar ou modificar arquivos na sua pasta que está sincronizada com o repositório remoto, você só precisara adicionar eles ao ‘Staged area’ usando o
$ git add . (O ponto adiciona todos os arquivos), após adicionar todos os arquivos desejados para formar um commit, use o comando $ git commit -m "Nome do commit", e mande suas alterações para o repositório remoto com $ git push.

Essa é a primeira parte de uma série de tutoriais sobre Git e Github, futuramente irei trazer novos conceitos mais avançados e até uma forma de padronizar seus commits e branchs utilizando um conceito bem famoso chamado Gitflow.

3 Estados dos arquivos — Git e Github

Luiz Eduardo Prado Veltroni — Thu, 06 Jan 2022 13:04:28 +0000

Chegou a hora de entendermos sobre os três estados dos arquivos dentro de um projeto, e como somos capazes de alterar o estado deles e até visualizar as modificações atuais comparado com o commit anterior.

1. Working directory (modified)

É o estado em que todo arquivo que foi adicionado, modificado ou removido, resulta em arquivo modificado, já que está diferente do estado atual, porém ele ainda não está dentro do próximo commit. Ou seja, o projeto está diferente comparado com a ultima versão.

2. Staging area (staged)

O arquivo só fica ‘preparado’ após executarmos o comando git add , resumindo o git já reconhece o arquivo que foi modificado e agora ele está na área de preparação e estará dentro do próximo commit.

3. Commit area (commited)

Agora que já temos todos os arquivos modificados e adicionados no Staged area, podemos formar um commit, com o seguinte comando git commit "Nome commit" , é importante lembrar que se existirem arquivos fora do Staged, ainda como modified ele não será adicionado no commit atual. Podemos formar um commit de diferentes maneiras, uma nova feature ou uma correção, depende da ocasião.
Podemos enviar para o Github com o comando git push e recomeça todo o ciclo novamente.

Restaurando arquivos

Já conhecemos o fluxo dos arquivos dentro do Git, podemos criar um cenário hipotético onde você ficou encarregado de realizar algumas modificações no projeto, você fez todas as alterações e adicionou os arquivos ao staged area com o git add . porém um arquivo foi de intruso e precisa ser adicionado em um outro commit, precisamos tirar ele usando o comando:

$ git restore --staged File.html

Esse comando irá retirar o arquivo ‘File.html’ do staged, ou seja, ele vai voltar para o inicio do processo e vai estar apenas como modified.

$ git restore --staged *.css

Remove todos os arquivos na staged que terminem com .css.

$ git restore .

Remove todos os arquivos.

Podemos também restaurar um ponto histórico exato usando o git restore --source porém é um conceito um pouco mais avançado.

Visualizando diferenças

Sabemos adicionar e remover os arquivos entre os estados, existe um comando bem interessante na hora que você está desenvolvendo algo e precisa visualizar as modificações que você realizou.

$ git diff

Ele permite ver as alterações que foram realizadas:

Nesse post apresentei alguns conceitos ainda iniciante porem fundamental para um bom desenvolvimento, são comando usado no dia a dia de um projeto. Importante você conhecer os três estados para saber quais arquivos vão para o próximo commit, ou quais arquivos precisam ser adicionados/removidos, também vimos uma forma de visualizar as alterações que foram realizadas sendo comparadas com as do commit anterior.

Fontes:
https://git-scm.com/book/pt-br/v2/Fundamentos-de-Git-Gravando-Altera%C3%A7%C3%B5es-em-Seu-Reposit%C3%B3rio

Introdução a testes unitários com Jest e Testing Library React.js

Luiz Eduardo Prado Veltroni — Wed, 05 Jan 2022 13:14:05 +0000

Nesse guia, eu trago uma introdução de teste unitários utilizando duas ferramentas, Jest e Testing Library no React.js

É de extrema importância a implementação de testes em seus projetos, principalmente naqueles que serão grandes, e que existem uma grande probabilidade de inclusão de novos desenvolvedores durante o processo de criação.

“No começo criar testes pode atrasar o desenvolvimento e não mostrar explicitamente a vantagem da criação desses testes, mas com o crescimento da aplicação ou sendo uma aplicação pequena mas muito importante, é essencial ter essa confiança de desenvolver sabendo que o código novo não vai afetar a funcionalidade do antigo e abranger várias situações que podem acontecer com o componente.”

Entendendo os testes

As vezes algumas dúvidas surgem, do tipo, como que eu irei testar um componente? O que eu preciso testar nele? Preciso checar o valor das variáveis? O foco desses testes não são checar todas as linhas e entranhas do código, você precisa testar o tem que acontecer com o componente, como se fosse realmente um usuário.
Um exemplo de linha de raciocínio de testes, sendo ele um <Button />, quais são as funcionalidades de um botão?:

Deve apareça na tela,
Deve ter um atributo (href, role, onClick, etc...),
Deve chamar uma função quando houver um click(onClick),
Deve estar desativado quando eu mandar desativado,
Deve estar ativo quando eu mandar ativado.

Criando nosso projeto

Para criar um projeto com tudo organizado e configurado, utilize o comando:

yarn create next-app --exemple with-jest with-jest-ap

Todos os testes terão uma extensão .test.jsx ou spec.jsx , é uma boa prática incluir todos em uma pasta na raiz do projeto chamada __tests__, agora para rodar o nosso primeiro teste que já vem implementado, basta digitar no console

yarn test

E Teremos um output parecido com esse:

Basta pressionar a tecla “a” e ele ia rodar no formato --watch passando esse parâmetro, é como se o teste ficasse assistindo toda alteração que é salva no projeto e ele roda os testes novamente, evitando o trabalho de ficar digitando yarn dev toda hora no console.

Testes na prática:

A estrutura base do teste ficaria mais ou menos assim:

describe('<Componente />', () => {
  it('should test', () => {
    expect()
  });
});

describe: seria um conjunto de testes de um mesmo componente (No caso o <Home />),
it: seria uma unidade de teste, uma boa prática começar com “should” para ficar mais intuitivo,
expect: espera que contem algo.

“Uma boa prática seria na parte do “describe” sempre colocar o nome do Componente <Home /> para ficar claro onde o teste falhou, já que nunca teremos dois componentes com o mesmo nome.”

Agora trazendo para um cenário um pouco mais real, iremos testar um componente <Button /> checando algumas coisas simples, como texto e atributo.

6- Importação necessárias para rodar os testes,
7- Importação do componente.
9- Agrupamento dos testes, descrever o componente para ficar fácil a identificação,
10- O teste em si, lembrando de sempre começar com should, para ficar intuitivo,
11- Utilizando o render() função para "renderizar" o componente,
13- Nós capturamos o componente através do
getByRole() e jogamos ele na variável button,
15- Chamamos expect() funcão para chegar se o button existe no documento com a função toBeInTheDocument().

E com isso encerro a primeira parte da introdução de testes unitários utilizando Jest e Testing Library no React.js. Claro que tudo isso é apenas um pedaço desse mundo gigante de testes no Front-end, essa introdução foi só para mostrar na pratica como podemos testar alguns componentes um pouco mais simples.

Fontes:
https://pt-br.reactjs.org/
https://jestjs.io/pt-BR/
https://testing-library.com/

Forem: Luiz Eduardo Prado Veltroni

O que é nome de domínio - Internet

Estrutura dos domínios

O que é TLD (Top-Level Domain):

O que é Label (ou componente):

Como ter um nome de domínio

Diferença entre nome de domínio e URL

DNS e como funciona - Internet

O que é DNS?

Como funciona o DNS?

E*tapas de uma pesquisa de DNS:*

O que é um resolvedor de DNS?

Servidor Raiz

Servidor TLD (Top-Level Domain)

Servidor Autoritativo

O que é cache de DNS? Onde ocorre o cache de DNS?

Cache de DNS do navegador

Cache de DNS no nível do sistema operacional (SO)

O que é HTTP - Internet

Motivação e criação do HTTP

HTTP/0.9 - 1991

HTTP/1.0 - 1996

HTTP/1.1 - 1999

SPDY - 2009

HTTP/2 - 2015

HTTP/3 - 2021

Como funciona a internet? - Internet

Início da Internet

O que é uma rede

Visão geral da Internet

IP e DNS

HTTP e HTTPS

TCP/IP

SSL/TLS

Git Stash - Git e Github

Git Stash

Criando um Stashes

Trazendo as alterações com o pop

Gerenciar múltiplos stashes

Limpar seu stash

Visualizar comparações de stash

Fazer stash em arquivos ignorados ou não rastreados

Padronização com GitFlow - Git e Github

Branchs e Merge

Fluxo do GitFlow

Regras das branchs:

GitFlow Extensão:

Primeira feature:

Encerrando a feature:

Cherry pick — Git e Github

Cherry pick

Cherry pick na prática

Pegar um conjunto de commit

Conflitos:

Conceito de Merge — Git e Github

Merge

Merge na prática

Resolvendo Conflitos

Conceito de Branch — Git e Github

O que são as Branchs?

Branch na prática

Merge

Primeiro repositório — Git e Github

Git:

Github:

Sincronizando repositório remoto

3 Estados dos arquivos — Git e Github

1. Working directory (modified)

2. Staging area (staged)

3. Commit area (commited)

Restaurando arquivos

Visualizando diferenças

Introdução a testes unitários com Jest e Testing Library React.js

Entendendo os testes

Criando nosso projeto

Testes na prática:

Etapas de uma pesquisa de DNS: