Forem: Guilherme Gomes

Primeiro mês usando Linux

Guilherme Gomes — Sun, 16 Mar 2025 07:48:26 +0000

Já se passou um mês desde que migrei para o Linux como meu sistema operacional. Então, decidi trazer alguns relatos sobre o porquê estou usando o Linux, qual distro utilizo neste meu início e o que mais estou gostando até agora.

❓ Por que escolhi o Linux?
Primeiramente, por curiosidade. Nós, que damos nossos primeiros passos na área de desenvolvimento, sempre ouvimos o quão vantajoso é usar o Linux.
Mas, particularmente, sempre tive vontade de aprender Linux, até pelos meus interesses em cybersecurity, usando o próprio Kali Linux na minha VM.
A minha vontade de migrar para o Linux sempre existiu; era só uma questão de tempo para isso acontecer.

❓ Qual distro utilizo atualmente ?
Atualmente, estou usando o Ubuntu como minha distro principal. Tenho vontade de migrar para outra distribuição futuramente (estou pensando no Arch), mas confesso que estou bem satisfeito e feliz com o Ubuntu, especialmente por ser meus primeiros dias com o Linux. Ele é bem simples e tem me ajudado muito neste começo.

❤️ O que mais gostei no linux ?
Minha jornada como desenvolvedor tem evoluído muito com o Linux, especialmente por estar 100% no terminal, o que torna tudo mais interessante e produtivo. Estou aprendendo a usar o Vim para aumentar minha produtividade (ainda apanhando bastante, kkkk) e aproveitando ao máximo o Docker e outras ferramentas.
No meu lado de cybersecurity, o Linux oferece mais segurança e uma integração mais natural com os comandos do Kali Linux, além de facilitar o uso de VMs e containers para meus testes e simulações.

Diretórios Linux: Entenda a Base do Sistema

Guilherme Gomes — Mon, 13 Jan 2025 19:10:00 +0000

Estrutura de Diretórios

`/` (Diretório raiz)

Diretório principal que contém todos os outros diretórios e arquivos do sistema.

`/bin`

Contém os comandos essenciais executáveis do sistema que podem ser utilizados por usuários. Exemplos:
cat, chgrp, chmod, cp, date, dd, df, echo, hostname, ln, more, mount, mv, ps, pwd, rm, rmdir, sed, su, uname, umount.

`/boot`

Contém os arquivos para inicialização do sistema.

O /boot inclui os setores de boot principal e arquivos de mapa de setor. Alguns exemplos:

Kernel: Componente central do sistema operacional, responsável por gerenciar os recursos do sistema. Serve como a ponte entre software e hardware.
Grub: Programa que carrega o sistema operacional quando o computador é ligado.

`/dev`

Contém arquivos para dispositivos. Aqui, encontramos arquivos que correspondem ao hardware e podem ser configurados para alterar o funcionamento de um determinado dispositivo.

`/etc`

Concentra arquivos de configuração do sistema.

`/home`

Diretórios pessoais dos usuários, onde ficam os dados dos usuários comuns do sistema. Cada usuário possui um subdiretório próprio. Para usuários que não são root, a escrita é permitida apenas dentro de seus respectivos subdiretórios.

`/lib`

Contém as bibliotecas utilizadas pelos programas.

`/mnt`

Diretório usado como ponto de montagem de dispositivos.

Equivalente: /media.

`/media`

Diretório vazio utilizado para montar dispositivos como CD-ROMs, DVDs e pendrives.

`/proc`

Armazena informações sobre o Kernel e processos. É um pseudo-sistema de arquivos, ou seja, não existe fisicamente no disco.

É possível ler dados e até alterar o comportamento do Kernel modificando o conteúdo de arquivos em /proc.

`/root`

Diretório home do superusuário (root). Dependendo da distribuição, pode ou não estar presente.

`/sbin`

Ferramentas de administração do sistema. Similar ao /bin, armazena binários essenciais. O "S" no nome indica "system binaries". Esses programas são geralmente acessíveis apenas pelo administrador do sistema.

`/tmp`

Diretório para arquivos temporários. Os arquivos armazenados aqui geralmente são apagados a cada reinicialização.

`/usr`

Contém arquivos pertencentes aos usuários. Alguns subdiretórios importantes:

/usr/bin: Ferramentas auxiliares, como interpretadores de programação (Perl, Python, etc.).
/usr/include: Cabeçalhos e bibliotecas da linguagem C.
/usr/local: Hierarquia para instalação de aplicativos locais no sistema.
/usr/share: Arquivos de leitura somente, independentes de arquitetura.
/usr/src: Pode conter arquivos de código-fonte de programas.

`/var`

Diretório usado para armazenar informações variáveis sobre o sistema.

HTTP Status Code

Guilherme Gomes — Sun, 20 Oct 2024 18:23:27 +0000

Quando um navegador faz uma solicitação a um serviço web, o servidor responde com um código de status HTTP, indicando o resultado da requisição. Para simplificar e automatizar o desenvolvimento da sua aplicação web, aqui está uma lista dos principais códigos de status HTTP que podem ser retornados.

1XX Information

Código	Descrição
100	Continue: O servidor recebeu parte da requisição e o cliente pode continuar enviando o restante.
101	Switching Protocols: O servidor está mudando o protocolo conforme solicitado pelo cliente.
102	Processing: O servidor recebeu a requisição e está processando, mas ainda sem resposta final.
103	Early Hints: O servidor sugere pré-carregamento de recursos enquanto a resposta final ainda está sendo processada.

2XX Success

Código	Descrição
200	OK: A requisição foi bem-sucedida e o servidor retornou o conteúdo esperado.
201	Created: A requisição foi bem-sucedida e resultou na criação de um novo recurso.
202	Accepted: A requisição foi aceita para processamento, mas não concluída.
203	Non-Authoritative Information: O conteúdo devolvido é modificado de uma fonte original.
204	No Content: A requisição foi bem-sucedida, mas não há conteúdo para enviar na resposta.
205	Reset Content: O servidor solicita que o cliente reinicie a exibição do documento sem conteúdo adicional.
206	Partial Content: O servidor está enviando parte do conteúdo, conforme a solicitação do cliente (usado para downloads).
207	Multi-Status: O corpo da mensagem contém informações sobre múltiplos recursos.
208	Already Reported: O recurso foi previamente mencionado em uma resposta anterior (usado em respostas WebDAV).
226	IM Used: O servidor completou a requisição usando uma instância do recurso com transformações.

3XX Redirection

Código	Descrição
300	Multiple Choices: Há várias opções para o recurso solicitado, e o cliente deve escolher uma.
301	Moved Permanently: O recurso foi movido permanentemente para uma nova URL.
302	Found: O recurso foi temporariamente movido para outra URL, mas no futuro pode voltar para a original.
303	See Other: O cliente deve usar uma URL diferente para obter o recurso, geralmente após uma requisição POST.
304	Not Modified: O recurso não foi modificado desde a última solicitação, então o cliente pode usar sua cópia em cache.
305	Use Proxy: O recurso solicitado deve ser acessado por meio de um proxy (não recomendado para uso atual).
306	Switch Proxy: Código não utilizado; reservado para uso futuro.
307	Temporary Redirect: A solicitação deve ser repetida com uma URL diferente, mas o método HTTP não deve ser alterado.
308	Permanent Redirect: Similar ao 301, mas garante que o método HTTP não seja alterado durante o redirecionamento.

4XX Client Error

Código	Descrição
400	Bad Request: A requisição foi malformada ou inválida, e o servidor não pôde processá-la.
401	Unauthorized: A requisição requer autenticação, e o cliente não a forneceu ou falhou ao se autenticar.
403	Forbidden: O servidor entendeu a requisição, mas está recusando permissão para atendê-la.
404	Not Found: O recurso solicitado não foi encontrado no servidor.
405	Method Not Allowed: O método HTTP usado não é permitido para o recurso solicitado.
408	Request Timeout: O servidor demorou muito para receber a requisição e a encerrou.
409	Conflict: A requisição não pode ser concluída devido a um conflito com o estado atual do recurso.
410	Gone: O recurso solicitado não está mais disponível e não será fornecido novamente.
429	Too Many Requests: O cliente enviou muitas requisições em um curto período de tempo, resultando em rate limiting.

5XX Server Error

Código	Descrição
500	Internal Server Error: O servidor encontrou uma condição inesperada que o impediu de atender a requisição.
501	Not Implemented: O servidor não suporta a funcionalidade necessária para atender a requisição.
502	Bad Gateway: O servidor recebeu uma resposta inválida ao tentar atuar como gateway ou proxy.
503	Service Unavailable: O servidor está temporariamente indisponível, geralmente devido a manutenção ou sobrecarga.
504	Gateway Timeout: O servidor, atuando como gateway ou proxy, não recebeu uma resposta a tempo.
505	HTTP Version Not Supported: O servidor não suporta a versão do protocolo HTTP usada na requisição.

Padrões e Nomenclaturas no Git: Um Guia Prático

Guilherme Gomes — Sun, 22 Sep 2024 20:16:35 +0000

Quando falamos sobre padrões e nomenclaturas no Git, é um ponto importante, embora não seja essencial. No entanto, seguir boas práticas, como manter um padrão consistente e utilizar nomes claros e descritivos nas branches, pode facilitar bastante o desenvolvimento em equipe e a manutenção do projeto.

Neste artigo, quero compartilhar um guia prático de versionamento e nomenclaturas que adotei e que tem sido útil no meu dia-a-dia!

Nomenclaturas para Commits

O commit semântico possui os seguintes elementos estruturais, que informam a intenção do seu commit:

feat: Indica que seu código está incluindo um novo recurso.

feat: adicionar funcionalidade de login com Google

fix: Indica que seu commit está solucionando um problema.

fix: corrigir erro 500 na página de perfil`

docs: Indica mudanças na documentação, como no README do seu repositório.

docs: atualizar instruções de instalação

test: Utilizado quando realizamos alterações em testes, seja criando, alterando ou excluindo testes unitários.

test: adicionar testes para a função de autenticação

build:Usado para modificações em arquivos de build e dependências.

build: atualizar dependências no package.json

perf: Identifica alterações de código relacionadas à performance.

perf: otimizar consulta ao banco de dados

style: Para alterações relacionadas a aspectos visuais ou de formatação do código.

style: corrigir formatação do código

refactor: Para melhorias na qualidade interna do código, sem alterar sua funcionalidade.

refactor: simplificar a lógica de validação

chore: Indica atualizações de tarefas de build, configurações de administrador, pacotes, etc.

chore: adicionar arquivo .gitignore

remove: Indica a exclusão de arquivos, diretórios ou funcionalidades obsoletas ou não utilizadas.

remove: remover código não utilizado da API

Nomenclaturas de Branch

Branch main

Esta branch contém a versão atual do software em produção. Ela está vinculada a uma pipeline que, a cada push, implementa automaticamente uma nova versão em produção.

Branch dev

Aqui se concentra o maior fluxo de trabalho e colaboração da equipe. As alterações feitas aqui provavelmente farão parte da próxima versão de lançamento.

Branch release

Esta branch é usada para preparar o lançamento de uma nova versão, contendo as funcionalidades desenvolvidas que serão implementadas em produção. O nome da branch geralmente segue o formato: release/v2.0.0.

Branch feature

Uma feature branch identifica o desenvolvimento de uma funcionalidade específica, como por exemplo: feature/nova-funcionalidade. Ela é uma cópia da branch dev, e várias feature branches podem existir simultaneamente, cada uma dedicada a uma funcionalidade diferente. Após a conclusão do desenvolvimento, a branch é finalizada e o merge é feito com a branch dev.

Branch hotfix

A hotfix branch é usada para corrigir bugs urgentes que não podem esperar pela próxima versão. Ela é uma cópia da branch main e segue o formato hotfix/v2.0.0-corrigir-falha-login. Após a correção, o merge é feito tanto na branch main quanto na dev para manter os repositórios atualizados.

Branch bugfix

A bugfix é usada para corrigir bugs de baixa urgência. Ela é uma cópia da branch dev e segue o formato bugfix/ajustar-estilo-pagina-inicial. Após a correção, o merge é feito na branch dev, e a correção será incluída na próxima release.

Seguir essas nomenclaturas e padrões não apenas melhora a organização do seu repositório, mas também facilita a colaboração e o entendimento das mudanças feitas ao longo do tempo. Espero que este guia prático ajude você!

Arquitentando projeto backend

Guilherme Gomes — Mon, 16 Sep 2024 20:18:44 +0000

Objetivo

Desenvolver um encurtador de URL eficiente e gratuito, adequado para empresas de todos os tamanhos. O encurtador oferece vantagens como a exclusão automática de links maliciosos e de spam, além de fornecer estatísticas detalhadas sobre o desempenho dos links criados, o que permite um acompanhamento completo das interações e acessos.

Vantagens de utilizar

Facilita o compartilhamento.
Melhora a experiência do usuário.
Acompanhamento de métricas -> Um encurtador de links pode registrar métricas de acesso. Como números de cliques, localização geo do usuário, dispositivo utilizado, etc.
Estética e Organização.
Prevenção contra quebras de link.
Uso de nomes Personalizados.
Redirecionamento Controlado -> URLs encurtadas podem ser redirecionadas a diferentes destinos conforme necessário. Podemos alterar o destino da URL encurtada sem alterar a URL original.

Arquitetando nosso projeto

Requerimentos

Dada uma URL longa gere uma URL curta única.
A url gerada não pode ser adivinhada.
Quando usuário acessa a url curta ele redireciona para a longa.

Escopo

Não precisamos nos preocupar com cadastro ou autenticação de usuário.
Considere usar um UUID para identificar um usuário.

Vários servidores (evita problemas quando algum servidor cair).
Load balancer (faz um gerenciamento das request feitas pelo usuário, escolhendo para qual servidor vai encaminhar).

Modelagem do nosso Banco de dados

URL → Representa a URL original e a URL encurtada, incluindo suas informações, data de criação, data de expiração(opcional) e número de cliques.

Click → Registra cada clique em uma URL encurtada, data do clique, incluindo endereço IP e o agente de usuário(software que o cliente está usando) para fins de análise.

A relação entre as tabelas urls e vé de um para muitos

urls (1) -- (N) clicks

1 URL pode ter N Cliques.

Cada registro na tabela clicks deve referenciar um registro na tabela urls usando o url_id.

Endpoints

**POST /urls*

Request body: {
    "original_url": "http://gguifedev.com"
}

Status code: 201
Reponse Body: {
    "hash": "x743Y44"
}

💡Endpoint registra url original e retorna um hash → Código que identifica a url encurtada.

*GET /:hash

Status code: 200
{
    "original_url": "http://gguifedev.com"
}

💡Redirect / Endpoint para redirecionar URLs encurtadas para seus destinos originais.

*POST /clicks

Request body: {
    "url_id": "aaaaaaaa-bbbb-1ccc-8ddd-eeeeeeeeeeee",
    "ip_address": "192.168.1.1",
    "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",
}

Status code: 201
{
    "id": 1234567890,  // BIGINT
    "url_id": "aaaaaaaa-bbbb-1ccc-8ddd-eeeeeeeeeeee",
    "clicked_at": "2024-09-10T12:34:56Z",
    "ip_address": "192.168.1.1",
    "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",
}

💡Endpoint usado para registrar um novo clique em uma URL encurtada.

*GET /clicks/:id

{
    "id": 1234567890,
    "url_id": "aaaaaaaa-bbbb-1ccc-8ddd-eeeeeeeeeeee",
    "clicked_at": "2024-09-10T12:34:56Z",
    "ip_address": "192.168.1.1",
    "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"
}

💡Endpoint que permite obter informações sobre um clique específico.

*GET /urls/clicks

[
    {
        "id": 1234567890,
        "url_id": "aaaaaaaa-bbbb-1ccc-8ddd-eeeeeeeeeeee",
        "clicked_at": "2024-09-10T12:34:56Z",
        "ip_address": "192.168.1.1",
        "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"
    },
    // ... mais cliques
]

💡Endpoint lista todos os cliques associados a uma URL encurtada específica.

Reinicio automático de uma aplicação Nodejs com Docker

Guilherme Gomes — Mon, 09 Sep 2024 22:46:07 +0000

Este Artigo tem objetivo agilizar o desenvolvimento de uma aplicação Nodejs sem ter a necessidade de subir o container a cada alteração feita no código.

Nodemon

Nodemon é uma ferramenta para Node.js que reinicia automaticamente a aplicação sempre que detecta alterações nos arquivos do projeto, facilitando o desenvolvimento. Para usá-lo, podemos instalar o nodemon como uma dependência global ou localmente no projeto. Depois, basta ajustar o script no package.json, trocando o comando node por nodemon para que ele gerencie a execução da aplicação automaticamente.

Instalação Global

npm install -g nodemon

Instalação Local

npm install --save-dev nodemon

package.json

{
  "scripts": {
    "start": "nodemon index.js"
  }
}

DockerFile

O Dockerfile é um arquivo de configuração onde definimos todas as intruções para criar uma imagem Docker. Essa imagem servirá como modelo para criação de containers.
Vamos realizar a criação de uma imagem do Docker onde será executado na aplicação, que irá seguir as definições do nosso Dockerfile.

# Usar a imagem base node:16-alpine
FROM node:16-alpine

# Definir o diretório de trabalho dentro do container
WORKDIR /app

# Copiar o arquivo package.json para o diretório de trabalho
COPY package*.json ./

# Instalar as dependências da aplicação
RUN npm install

# Copiar o restante dos arquivos da aplicação para o diretório de trabalho
COPY . .

# Expor a porta que a aplicação irá rodar (ex: 3000)
EXPOSE 3000

# Comando para iniciar a aplicação
CMD ["npm", "start"]

Docker-compose

Docker-compose é uma ferramenta que ajuda a definir e compartilhar aplicativos entre vários containers. Com o docker-compose, você pode definir todos os serviços que compõem a sua aplicação como (Servidores web, banco de dados, cache) em um único arquivo docker-compose.yml.

Vamos criar um arquivo docker-compose.yml para definir esses serviços e gerenciar eles com mais facilidade.

version: '3.8'  

services:
  app:
    image: node:16-alpine  
    working_dir: /app  
    volumes:
      - .:/app  
    ports:
      - "3000:3000"  
    environment:
      - NODE_ENV=development  
    depends_on:
      - db  
    command: npm start 

  db:
    image: mysql:8.0  
    environment:
      MYSQL_ROOT_PASSWORD: example  
      MYSQL_DATABASE: my_database  
    volumes:
      - db_data:/var/lib/mysql  

volumes:
  db_data:

version: '3.8': Especifica a versão do Docker Compose.
services:: Define os serviços da aplicação.
- app:: Serviço Node.js.
- image:: Usa a imagem node:16-alpine.
- working_dir:: Define o diretório de trabalho no container.
- volumes:: Sincroniza o diretório atual com o container.
- ports:: Mapeia a porta 3000 do host para o container.
- environment:: Define variáveis de ambiente, como NODE_ENV.
- depends_on:: Estabelece dependência do serviço db.
- command:: Executa o comando npm start.
- db:: Serviço MySQL.
- image:: Usa a imagem mysql:8.0.
- environment:: Configura a senha do MySQL e o banco de dados.
- volumes:: Monta um volume para persistência dos dados.
volumes:: Define o volume para armazenar dados do banco de dados.

Por fim, executamos o comando:

docker-compose up -d --build

Conclusão

Rodamos uma aplicação em Nodejs em um container Docker e, com a ajuda do nodemon, somo capazes de desenvolver nossa aplicação executada dentro do container sem a necessidade de subir o container toda vez que é feita alguma alteração.

LocalStorage, SessionStorage e Cookies

Guilherme Gomes — Mon, 02 Sep 2024 00:48:35 +0000

No desenvolvimento web, é de grande importância ter conhecimento e habilidade ao gerenciar os dados do lado do cliente. Muitos desenvolvedores utilizam localStorage, sessionStorage e cookies para armazenar esses dados no navegador do usuário. Embora esses três mecanismos tenham propósitos semelhantes, há diferenças em termos de capacidade, durabilidade e seus casos de uso. Neste artigo, vamos explorar essas diferenças.

1. LocalStorage: Armazenamento persistente no lado do cliente

Propósito: É usado para armazenar dados no cliente que persistem mesmo após o fechamento do navegador, sendo ideal para os dados que precisam ser mantidos entre múltiplas sessões.
Capacidade: Oferece um espaço de armazenamento considerável, geralmente 10MB por domínio.
Durabilidade: Os dados armazenados permanecem disponíveis até serem excluídos pelo usuário ou pela aplicação.
Exemplo: Suponha que você tenha um aplicativo de notas. Você pode usar o localStorage para salvar as notas do usuário para que elas sejam preservadas em todas as visitas.

2. SessionStorage: Armazenamento temporário com base na sessão

Propósito: Também armazena os dados do cliente, porém, a duração da sessão da página é limitada. Isso significa que os dados são apagados quando o usuário fecha a aba ou o navegador.
Capacidade: Oferece cerca de 5MB de armazenamento por domínio, suficiente para dados temporários.
Durabilidade: Os dados estão disponíveis apenas durante a sessão atual, torna-se perfeito para armazenar informações que não precisam persistir além da sessão atual.
Exemplo: Imagine um site de e-commerce que precisa armazenar temporariamente os itens adicionados ao carrinho de compras durante a navegação. Você pode usar o sessionStorage para garantir que, se o usuário navegar para outra página, os itens do carrinho não sejam perdidos.

3. Cookies: Armazenamento de pequenas porções de dados com interação ao servidor

Propósito: Cookies são usados para armazenar pequena porções de dados que precisam ser enviados para o servidor com solicitações HTTP. Eles são frequentemente usados para rastrear sessões de usuários, armazenar tokens de autenticação e lembrar configurações de usuário.
Capacidade: Limitado a 4KB por cookie, mas é possível armazenar múltiplos tokens.
Durabilidade: Cookies podem expirar ao final de uma sessão ou persistir por uma duração específica, o que torna eles versáteis.
Exemplo: Para implementar uma notificação de consentimento de cookies que só aparece uma vez, você pode usar cookies para armazenar a preferência do usuário.

Quando usar cada um desses mecanismos de armazenamento ?
LocalStorage: Use quando precisar armazenar grande quantidade de dados que devem persistir em várias sessões.
SessionStorage: Ideal para dados temporários que devem persistir apenas durante a sessão do usuário.
Cookies: Melhor para armazenar pequenas porções de dados que precisam ser enviados para o servidor com solicitações HTTP.

Conclusão
Entender as diferenças entre eles irá te ajudar muito na escolha certa para o uso em suas aplicações. Cada um tem suas próprias vantagens e limitações, tendo o conhecimento das diferenças irá ajudar você a construir aplicações mais eficientes para o usuário.
Tendo o conhecimento e dominando está ferramentas, você estará preparado para gerenciar o armazenamento de dados do lado do cliente em seu próximo projeto, trazendo uma experiência mais fluída para os seus usuários.

Linkedin Profile: Guilherme Gomes